唐春波,郭文明△,严静东,蔡荣杰,杨小燕
(1.南方医科大学网络中心,广东 广州 510515;2.南方医科大学南方医院信息科,广东 广州 510515)
根据调查显示,国内成人慢病患者占有率非常高,其死亡率高居榜首[1]。连续医疗护理方式在提高慢病患者生存质量,降低患者死亡率,降低医疗费用等方面有积极作用[2-5]。连续医疗依赖诊疗业务、信息和人际关系的连续[6],具体实现基于角色间的信息流通。将院内和院外两类不同诊疗护理领域的多方信息交互,是构建连续医疗生态圈的基础。主要有信息流、技术流方面的挑战。
从信息流看,医院和家庭之间的诊疗信息流不能构成一个闭环。患者只能获取纸质版出院医嘱、诊断报告等信息。医生通常用电话随访等方式获取患者院后诊疗信息。这些方式有易丢失、隐私泄露,执行效率低、可靠性低等缺陷。当患者转院诊疗时,医院和家庭之间信息流的断裂,进一步影响医院和医院之间信息流的闭环。目前,多数研究集中于院间或院后家庭照护系统间的集成[7],无法为“分级双环连续医疗”提供一个信息交互平台。
从技术上看,为解决异构系统集成的语法和语义互操作挑战[8-9],选择HL7的V2、V3作为数据、消息模型,并绑定SNOMED(the systematized nomenclature of human and veterinary medicine,SNOMED )、LOINC(logical observation identifiers names and codes,LOINC)等术语系统。为解决异构分布系统消息通信问题,选择SOAP(simple object access protocol,SOAP)WebService(大Web服务)为通用规范集成技术,XML为通用数据格式。从实践来看,基于SOAP的大Web服务是一种紧耦合的重量级协议。其消息的封装与解析给移动客户端带来负担。HL7 V2标准技术老旧,不容易定制、扩展,消息不适合跨机构传递。V3定义了互操作的通用模型,但实例庞大,实施非常困难。在资源紧缺的连续医疗生态圈内采用这些技术和标准以达到数据交互目标,工作量大、效率低、投入大等。
FHIR(快速医疗互操作性资源)是HL7继V2、V3后推出的标准规范。它将临床概念细粒度模型定义为“资源”,结构见图1[10]。资源由元素、叙述和扩展三部分构成。该标准规范具有如下特点:
(1) FHIR是面向开发者人员的:FHIR采用XML、UML等标准构建数据资源集合,以Web技术为通信基础标准。开发者熟悉这些技术,容易上手。
(2) FHIR是面向Web的:FHIR采用REST(representational state transfer,REST) WebService构建分布式资源数据集成机制。
(3) FHIR是面向移动终端技术:REST API技术支持构建轻量级移动客户端,非常适合院外移动健康护理。
FHIR标准是云计算、物联网、移动医疗等技术、概念融合产生的适合于当代医疗信息化的一个新规范。
图1 FHIR的资源结构
FHIR定义了三个与术语相关的资源来管理术语编码系统的值集、术语概念间的映射和系统的命名空间。能支持与必要的术语系统进行相互引用,解决资源中涉及到的疾病、药品、观测指标等语义操作问题[11]。
本研究首先对平台的关键技术和方法进行分析,并设计基于FHIR标准的数据集成平台简略架构。其次分析平台的应用情景以及实际的布署环境和效果图。最后指明设计方案的缺陷和不足,并提出进一步的研究方案。
数据集成平台涉及的逻辑功能组件多。在此,选择几个关键的组件进行研究。
参考其它标准使用,对FHIR标准进行本地化处理,进而支撑连续性医疗数据集成平台的搭建[12-13]。以Patient Resource为例,本地化一个资源,其示范见图2:
图2 FHIR的横型本地化
其中,Patient Resources的name标签添加FormerNameExt属性以标识患者的曾用名,主要用于患者的交叉索引获取完整的诊疗信息。添加PhysicalInformation Out属性标记患者带出院外的诊疗资料(如病历、胶片),该属性用于提示医生患者院外拥有的诊疗信息,非常适合院外诊治活动。连续医疗领域的核心信息模型,如医生、临床报告、患者管理等“资源”均需进行一定配置,这里不一一举例。
当前医院的医疗信息系统采用的都是非FHIR标准格式的信息模型,故当信息发送到数据集成平台时需进格式转化。转化过程采用ETL(extract-transform-load,ETL)模式[14]。
以V2消息为例。平台输入适配器从外部接收需存入平台的V2消息,信息提取器(V2.model.extractor)对其进行内容的提取,并使用XML解析编码类将V2格式转化为XML形式的数据结构。FHIR的适配器包含映射、过滤两个组件。映射组件将V2的XML 格式数据转为FHIR 资源的XML模型,该过程有个Validator类来验证FHIR XML模型的有效性。过滤组件则进行数据清洗,保持转化前后的数据一致性。当转化为FHIR的XML格式时使用EMF(Eclipse Modeling Framework)框架[15]进一步转化为FHIR类模型(POJO对象),最终写入数据库。见图3。
V3、CDA等其它的消息转换过程类似。需要注意的是要申明需转换消息的版本信息以使转化顺利进行。
数据集成平台通过广域网和其它系统进行对接,容易被黑客等攻击。平台采用SSL/TLS方式对HTTP进行安全增强外,并充分利用HTTP请求的Referer属性以防止外连接。为此提供了http://******.edu.cn/Frame/Login.htm和http://******.edu.cn/Frame/MainDefault.aspx?uid2=*****作为可靠的请求页面。同时为患者添加群、组两个字段,即PatientRepSafe=(S,G,F),其中S代表其它安全字段集合如角色,技术级别等。一般G和科室或者疾病对应,F则对应群里面的组。只有满足G、F字段的医护人员才能对患者的诊疗信息进行操作,这可以保护患者的隐私和信息安全。
当非FHIR格式的消息转化为FHIR类对象时,FHIR 构造器运用FHIR Java 参考实现(标准Java库实现FHIR)生成FHIR序列化的数据结构(XML or JSON)存入数据库。
其余逻辑类包含:(1)访问与交互模块。支撑可靠的Web服务客户端,用户能够安全可靠的访问资源并进行交付操作。
(2) 面向服务的应用程序接口(SOA API)。充分利用HTTP的可靠性和简化的CURD交互风格以及可缓存的能力,提高交互的效率。
(3)业务流程管理模块。可以快速、简便且不间断的修改和补充成新的业务流程。能够缩短服务集成的周期并降低投入。
图3 系统架构模型
连续医疗是医生和患者从院内到院外的一个诊疗活动过程,并伴随诊疗信息的流转(含纸质版)。电子化形式的信息流转见图4。
图4 数据集成平台在连续医疗中的应用场景
过程如下:
(1) 患者在医院配合医生进行诊疗,产生个人诊疗信息,存储在院内。
(2) 需连续诊疗的患者出院后,医生将其信息推入院后云服务平台。
(3) 医生在家庭为患者进行诊疗,通过移动终端访问平台中的诊疗信息辅助诊断。
(4) 医生将院后诊疗信息写入PHR后推入院后云服务平台。
(5) 平台中诊疗数据供有权限医院医护人员和患者使用。
其中(1) 和部分(4)过程主要通过局域网(LAN)完成信息的传输,(2) 、(3)、(5)和部分(4)则通过广域网(WAN)进行通信。通过这个院后数据集成平台,患者在医院和院外的诊疗信息形成一个闭环,为医生提供完整的诊疗信息。不仅能提高诊疗质量和效率,还方便患者本身随时了解自身的健康状况。
实际的数据集成平台搭建在Window Server 2012系统(RAM为128GB)上,Web服务器为Tomcat 7.0.72。其实际效果见图5:A图为电脑端采用搜狗游览器的显示效果;B图是移动客户端的显示效果,其环境为Android 4.0。试验平台布署在南方医科大学网络中心,与其对接的有南方医院等机构。平台试用三个月期间,相关科室医生和患者均使用满意。平台能够为院内外的医生提供患者院内外诊疗信息,明显提高其在院外诊疗服务的质量和效率。能够支撑患者随时随地获取诊疗信息。
图5平台支撑的客户端使用效果,其中A为医生使用电脑访问平台数据;B为移动终端访问患者平台内的诊疗信息
Fig5Theclientuseeffectsupportedbyplatform.theAisdoctorsusecomputeraccesspatient’sdiaguosisandtreatmentdatainplatform:andBusemobileterminals
针对连续医疗护理中,医院和家庭的诊疗信息流无法闭环的挑战。采用基于RESTful WebService 的 FHIR标准规范构建数据集成平台连接各系统。由于使用FHIR作为核心的信息模型,扩展部分即本地化的一些属性,会带来语义无法统一问题。同时我们发现当医生在院外为患者诊治时,治疗药物的获取方式是另外一个挑战。目前设想的是由医生和患者共同决定药品提供商和物流提供商。这需要将两个提供商的服务信息注册到数据集成平台,以供医生和患者协商选用。其中涉及到的物流和信息流是下一步的研究方向。
本研究采用FHIR作为信息标准搭建平台,与V2和V3相比,其数据细粒度更适合临床信息的表达,并且实施快捷,资源投入较少。而以RESTful WebService为服务集成和应用机制能减轻移动终端的负担。上述优势使该数据集成平台能够很好作为医院和医院外医疗护理信息系统间相互沟通的桥梁,支持连续性医疗护理高效安全可靠的进行。