基于J2EE的延伸护理系统的设计与实现

黄云霞++王丹志

摘要：现阶段，护理服务仅局限于患者住院阶段，仅有3%的医院会提供院外的延伸护理服务，且大多局限于通过电话、短信等形式进行，这种双盲的交流形式很容易导致信息不对称，从而产生诸多问题。为了减少传统的延伸护理服务模式所带来的问题，提升患者出院后的康复效果，本文提出了将互联网技术应用于延伸护理服务环节，并引申出“健康日记”、“健康秘书”等全新的理念，通过建立护理人员与患者的个性服务关系来实现对患者专业化、精细化的全方位护理服务。系统采用SpringMVC+Spring+Hibernate相结合的框架进行开发，融合了CDN加速、DES传输加密以及实时通讯等技术，并针对移动平台进行优化以适应更为广阔的用户群体。目前，本系统已经在北京301医院代谢综合征科室进行了试验性应用，并取得了良好的效果。

关键词：计算机应用；延伸护理；健康秘书；J2EE架构

中图分类号：TP311

文献标识码：A

DOI： 10.3969/j.issn.1003-6970.2016.01.009

0 引言

延伸护理服务是通过一系列的护理措施用以确保患者在不同的健康照护场所（如从医院到家庭）及同一健康照护场所（如医院的不同科室）受到不同水平的协作性与连续性的照护，通常是患者出院后，专业的护理人员为其制定合理的康复护理方案，并进行后续的随访与指导，帮助患者早日康复，提高患者的生活质量及幸福指数。

延伸护理服务逐步信息化经历了一个漫长的历程，国内外也都做了相应的探索。2000年左右美国开始构建延续护理概念模型，提出了延续护理的两个核心要素：1、针对个体的卫生服务；2、服务时间上的延续性。与此同时，美国、西班牙等国针对延伸护理服务也研发了相应的信息系统，用于保存患者健康档案，为其提供及时有效的服务。

中国在延伸护理的信息化研究上起步较晚，2002年香港理工大学黄金月教授才将延伸护理模式引入香港，并提出了4C模式，主要应用电话随访和家庭访视，对出院的糖尿病、冠心病、肾衰晚期、COPD患者进行护理服务。2011年中国再次提出，延续性护理是“十二五”时期重点工作任务。

在“互联网加”这个大背景下，秉承“病前院外、线上线下、随时随地”的理念，解决传统的电话、短信、上门随访等护理服务模式，本文将互联网技术与护理服务结合起来，采用B/S结构，设计了一套能够帮助患者在出院后可以随时随地更加方便地享受护理服务的系统，以缓解中国护理资源的紧张，更好地提升患者的康复效果。本文将从系统需求分析、系统架构设计、关键技术于创新点以及数据库设计做等方面做重点阐述。

l 系统需求分析

传统观念上，患者出院后就意味着医患关系的结束，但是据调查研究，很多患者在出院后仍有很高的健康照护要求，尤其是患者糖尿病、慢性心力衰竭、脑卒中、消化性溃疡等慢性病患者。由于这些患者在出院康复期间缺乏合理的康复方案及优质的护理服务，使得症状不能得到有效的控制，进而极大降低了患者的生活质量及幸福指数，同时使得再次入院、急诊门诊的使用率大大升高。因此，在慢性病护理需求日益增加的今天，设计开发一套完整的延伸护理系统是非常有必要的。

本系统的主要用户是出院患者及专业护理人员，通过“健康秘书”的关系将护士与患者关联，每个患者可以添加多个护士为健康秘书，同时每个健康秘书可以为多个患者服务。患者与护士建立了个性化服务关系后，护士便可查看患者的电子病历、身体监测数据并为其制定合理的干预方案，患者按照干预方案进行每天的饮食、作息、运动等生活方式的调整并向系统反馈每天的方案执行情况，通过双方即时的信息交流，护士便可精确地掌握患者的信息，在必要情况下可进行上门随访服务，极大程度上体现了延伸护理的综合性、延续性、协调性和合作性。整个系统的业务模型如图1所示：

通过该系统，使得延续护理不再受场所、时间等的限制，括宽了延伸护理的横向及纵向层次，满足了患者出院后的照护需求，缓解了医护资源的紧张，提高了整个社会的医疗健康满意度。

2 系统架构设计

本文采用基于Web的J2EE三层体系结构，基于B/S模式，使用Spring MVC、Spring、Hibernate相结合的开发框架实现系统的设计与开发。J2EE三层体系包括表示层、业务逻辑层、数据访问层，表示层主要采用Spring MVC结合Java Servlet API的方式实现，主要负责页面的展示、接收请求、分发请求。业务逻辑层主要是对数据层进行操作，对数据逻辑层进行处理。数据访问层也称为持久层，由Hibemate实现，主要由数据访问工厂层、数据访问接口层、自定义查询层和临时层共同组成，主要负责对数据库的访问。本系统的整体架构图如图2所示：

这三种框架相结合，完整地实现了J2EE的三层架构。采用此体系架构，开发人员只需关注整个结构中的某一层，能够有效降低层与层之间的依赖并有便于各层的独立标准化，通过各层之间的低耦合性、各层逻辑的高复用性，有利于整个系统的架构设计及业务变化的分离，从而实现了便捷、高效、安全、稳定的企业级系统应用。本系统的整体架构图如图2所示：

其次，本系统中部分页面采用Freemarker进行视图的渲染，对于处理大量判断、日期金额这些复杂页面而言，性能要优于传统的JSP，同时它对JSP标签支持良好，并且采用严格的MVC分离，使得系统结构更加清晰，页面渲染更加友好。

3 关键技术与创新点

本系统在研发的过程中应用了大量的新型互联网技术，并针对其应用场景进行了适应化的创新，以使其在系统模块中产生更大的效能。本文主要对系统所使用的CDN视频分布式加速技术、基于TCP长连接的实时通讯技术以及DES传输加密技术及其创新点进行阐述。

3.1 CDN视频分布式加速技术

传统的视频服务器主要是由一台集中式视频服务器为用户提供视频服务，这种视频服务器部署起来相对简单并且便于对视频资源进行集中管理。但是，集中式的管理注定会带来集中式的访问压力，从而影响用户体验。这种劣势在本系统这种用户分布范围比较广泛的应用平台将会体现的更为显著。因此，本文在原始的视频流服务器的架构的基础上提出了基于分布式缓存的视频CDN加速技术。其应用架构如图3所示：

为了让每一个用户分布区域享受到最快速的视频服务，在每一个用户相对集中的分布区域架设相应的Load Balance Server（负载均衡服务器），通过这些服务器将各地区的请求进行分析，选择对于目前地区访问速度最快的视频服务器进行接入，极大程度的加快了访问速度，提升了用户体验。与此同时，分库策略也使得网站整体性能得以提升。

当然，此处所提及的创新点所带来的问题便是搭建成本以及维护成本的大幅增加，架构进一步复杂化，对开发人员以及维护人员提出了更高的要求。在实际的系统开发过程中对于其利弊因素需要进行权衡，选取一种折中的实现方案。

3.2 基于TCP长连接的实时通讯技术

以往，对于网络通讯都是采用“邮件”式的异步通讯机制，即每次都是通过用户主动请求的形式拉取相应的消息。而对于本系统这种对于消息实时性要求较高的应用场景，这种方式显然不太合理。例如，保健护士在通知患者需要在1小时内完成相关的训练时，异步通讯所造成的延时将造成患者不能及时了解到护士的安排从而错过最佳的恢复时机。

本文则将主要应用于C/S架构上的TCP长连接技术应用于B/S架构中，以实现Web端的实时通讯，其实现方式如图4所示：

浏览器端的应用通过post请求方式向服务器请求建立TCP长连接，如果连接超时则服务器向浏览器返回一个空包，浏览器接受到空包之后继续向服务器发送请求。这一举措有两个目的：一是为了让服务器能够判断当前用户是否还在线——如果联系两个间隔没有收到该用户发送的心跳包则认为用户处于离线状态；二是为了达到消息实时性的要求，这时候服务器只需要在有消息要通知客户的时候准备好消息，等到下一个心跳包到来的时候直接将其返回给用户。这样也就实现了消息推送的效果。

由于浏览器往往建立在有线网络的状况下，所以这种方式实现的推送机制相较于移动网络将会更加稳定。另外，由于采用了心跳方式的长连接建立机制，其对于网络带宽的需求将会降低不少。

3.3 DES传输加密技术

在加密技术的选择上，本文针对RSA加密和DES加密进行了对比分析。RSA加密是一种非对称加密技术，侧重于数据的安全性，但是加密速度相对较慢，DES加密则是一种对称加密机制，由于加密处理速度较快，因此适用于本系统这种对于速度要求较高并且加密内容比较长的场景。

当然，为了弥补采用DES加密传输所带来的安全性问题。本文创新性的提出了融合DES加密-DES+MD5加密算法，所有的通讯协议内容采用DES进行加密，而协议所包裹的数据则采用MD5进行加密。由于服务器主要解析相应的借口协议以处理相应的逻辑，对于数据主要做存储操作，所以这一改进不仅大大增加了数据的安全性，还没有增加服务器的解密压力。DES加解密相关的代码如下所示：

加密代码：

private static byte[] encrypt （byte[] data. byte[] key）throws Exception{

SecureRandom sr= new SecureRandom（）；

DESKeySpec dks= new DESKeySpec （key）；

SecretKeyFactory keyFactory=SecretKeyFac-tory.getlnstance （DES）；

SecretKey securekey=keyFactory.generateSecret（dks）；

Cipher cipher= Cipher.getlnstance （DES）；

cipher.init （Cipher.ENCRYPT___ MODE. securekey.sr）；

return cipher.doFinal （data）；

）

解密代码：

private static byte[] decrypt （byte[] data. byte[] key）throws Exception{

SecureRandom sr= new SecureRandom（）；

DESKeySpec dks= new DESKeySpec （key）；

SecretKeyFactory keyFactory=SecretKeyFac-tory.getlnstance （DES）；

SecretKey securekey=keyFactory.generateSecret（dks）；Cipher cipher=Cipher.getlnstance （DES） ；cipher.init （Cipher.DECRYPr MODE， securekey， sr）return cipher.doFinal （data） ；

4 数据库设计

在大型交互型网站的数据库设计上需要考虑的因素包含并发性以及可扩展性等因素。本系统所选取的数据库为MySql。在考虑可扩展性时对于两种方案进行了分析：Scale-up（纵向扩展）以及Scale-out（横向扩展）。纵向扩展是一种通过提升机器的性能进行扩展的方案，而横向扩展则是通过增加处理节点从而对数据库性能进行补充的方案。通过分析比对，横向扩展对于互联网应用这类高并发性的情况更为适用。

本系统数据库表包含基本交互式系统所要求的数据表，例如权限表、用户表等等。整个系统数据库总共包含128张表，下面仅将本系统比较核心的两个模块所涉及的表进行介绍。

（1）干预方案模块设计

干预方案是本系统的核心内容，也是护士为患者提供服务最关键的内容。其数据表设计如下所示：

干预方案是延伸护理系统的核心内容，是护患沟通的一个及时有效的方案。通过干预方案护士可以在线上直接为患者量身定制每天的饮食、运动方案，让患者就算在院外也可以享受到院内般的科学指导。

本系统中，每一位患者可以添加多位护士作为其私人保健专家，所以每位患者将会有不同护士为其制定的干预方案，所以针对每位患者需要有一张表用于存储其所拥有的干预方案列表，方案列表主要用来存储患者用户每一天需要进行的任务，这些任务都是由患者的私人护士进行维护，私人护士在了解患者相应的康复情况后需要根据患者的身体状况为其制定干预方案，干预方案表如表1所示：

通过查询语句：

SELECT * FROM T_INTERVENTION—PLANWHERE PATIENT_ ID=“123456789”

可以查询出该患者所拥有的所有的干预方案，然后患者用户可以选择其中任意一个干预方案，终端就通过该方案的方案ID向后台请求方案的详细信息，后台需要到干预项目表中查询相应方案的详细信息。

（2）监测数据模块设计

健康监测作为干预方案的重要实施环节，在本系统中的作用也是十分重要的。而监测模块最为重要的两张数据表是监测项目表以及监测数据历史表。

监测项目表是用来存储干预方案中所提及的所有检测项目的一张数据表，它主要存储检测项目的计量单位、参考范围以及适用性别等信息。例如对于糖尿病患者所关注的血糖指标，需要在这张表中存储血氧的计量单位-mmol/L，参考范围为3.9-6.1mmol/L，对任意性别和年龄都适用，因此这两项分别存储为2男女皆可和0年龄无影响。检测数据表的结构如下所示：

监测项目表在提示患者用户进行数据以及对于监测历史数据进行是否异常判断时都是非常有用的。后端可以通过查询监测项目表中的项目将结果反馈给前端让其做相应的用户交互界面显示，以提示患者正确的上传监测数据。

5 系统功能实现与测试

根据文章的系统需求分析，延伸护理系统的整体功能设计如图5所示：

整个系统的用户分为患者及护士，主要通过建立“健康秘书”关系将两者相连接，进而建立个性化延伸护理服务关系。

5.1 患者端功能

对于患者而言，主要包括4大功能：

（1）基本信息管理：包括患者的个人账号、身份证等自然信息的查询、修改，用户密码修改，金币使用明细查询，电子病历、体检报告等健康档案的管理。健康档案的安全性、存储方便性、时效性等优点极大程度上方便了护患双方的信息共享。

（2）测评管理：经过咨询专业的护理团队，系统提供了一套完整的身体评估方案，得出了分析身体状况需要提供的数据指标以及测试项目，并针对每一个项目设置了评分值及权重，患者仅需按照要求进行填写，系统充分运用大数据分析的思想，即刻就能得出其身体处于何种状态并提供一套权威的监测报告。测评数据如图6所示：

（3）健康秘书管理：本系统的核心之处就在于建立护士与患者的服务关系。患者可以指定与自身疾病相符合的专业护理人员为自己的健康秘书，经护士同意后，便可享受护士的专业化、精细化的护理服务。

（4）干预方案管理：在患者出院后需要延伸护理服务的情况下，健康秘书根据患者的电子病历、身体评估报告等为其量身制定干预方案，并以健康日记的形式体现出来。健康日记展示了患者每天需要完成的任务及注意事项。健康日记作为延伸护理服务的核心实现，对其如何实现做了更深入的研究。

对于健康日记，设定了一种可扩展的数据结构，可以支持通用的模板及个性化方案的制定，并以符合用户使用习惯的时间轴模式的日记界面显示，横轴代表日期，可以显示30天的时间记录，纵轴为时间轴，由时间节点及节点任务组成。节点数量可以动态调节，节点任务可以按需增加，文字、视频、图片、网页等任务内容格式不限。并支持动态的设定监测数据功能。

5.2 护士端功能

对于护士而言，主要包括3大功能：

（1）基本信息管理：包括护士的个人账号、个人基本信息的修改，个人主页（疾病擅长、个人简介、职称等）的管理，个人绩效查询，个人金币收入查询等。

（2）患者管理护士同意成为患者的健康秘书后，便可在该菜单下查询自己所服务的患者，并能够查询患者的基本个人信息、电子病历、身体评估报告、干预方案执行情况等，能够及时精确得了解患者的身体状况。并能够通过即时通讯模块与患者进行交流，充分体现了延伸护理的时效性。

（3）干预方案管理：系统提供了针对不同疾病、不同地域、不同年龄阶段等的各种健康模板方案，护士作为健康秘书，需要根据患者的病情及康复情况来制定方案，可以自己设定方案，也可根据模板提供的内容进行合理的修改，图7为护士配置方案的界面。

5.3 系统测试

对于一个系统来说，测试是必不可少的环节，也是正式应用前最重要的环节。针对本系统，主要做了兼容性测试、功能测试、性能测试。

（1）兼容性测试：针对目前较为流行的浏览器IE6-IE11，Firefox，chrome，safari，360浏览器都逐一测试了各页面及数据的显示效果，基本上都与原型设计中的效果相一致，实现了良好的兼容性，满足了用户的交互性能要求。唯一的不足是由于IE6渲染技术古老，且用户使用数量也较少，系统在该浏览器中显示效果不是很好，需要做进一步兼容性改进。

（2）功能测试：针对两类用户，分别测试了其注册、登录以及登录后的功能操作。并主要对系统中涉及到两个角色的业务流程做了重点测试，比如：健康秘书为患者制定干预方案的流程等。无论是功能点的测试还是业务流程的测试，都能很好的实现。

（3）性能测试：对于一个复杂的，用户数量庞大的系统，高并发是极其重要的因素。通过模拟测试，本系统实现了5万用户的高并发量，防止了高峰期段系统的瘫痪，能够很好的满足用户的日常需求。

总之，该系统的测试结果合格，可以投入使用，对于一些无关紧要的细节bug，今后会在做进一步的改进。

6 结论

本系统将互联网技术应用于延伸护理系统，成功解决了传统护理模式所带来的一系列问题。本系统目前已经在北京301医院代谢综合征科室进行了试验性应用，很好的满足了糖尿病人需要长期监测身体指标及长期饮食指导的需求，取得了良好的护理效果。将互联网技术应用于糖尿病等慢性疾病的延伸护理过程中在很大程度上也减少了医疗资源的浪费，缓解了患者就医难，路途远的烦恼，同时很大程度上也推进了医疗信息化的进步。相信，会有更多的医院采用本系统或者类似的延伸护理系统为患者提供服务，提升患者的康复效果，提高患者的幸福指数。