用好数据引擎，服务互联互通

在国家健康中国大战略的引导下，信息技术与医疗服务深度融合，随着国家对医疗信息化产业的政策加强和资源投入，信息化建设如火如荼。 面对各地医疗机构信息化水平发展不平衡，为实现国家大战略层面的跨机构、跨地域健康诊疗信息交互共享和医疗服务协同水平，国家卫生健康委统计信息中心开展国家医疗健康信息互联互通标准化成熟度测评工作。 通过以评促建、以评促优，来实现整体医疗信息化的提高和改善。 

然而，领先的建设理念和目标与现实存在的建设过程还存在一定差距，其中的不确定性依然存在。 医疗信息化互联互通建设目标和实际应用思路需要在建设中不断的弥合，这个过程会产生这样或者那样的困难和制约。 

互联互通的建设面临着诸多挑战 

1. 系统种类多，服务集成难   

对比国外的医疗机构信息化一体化程度高，承建商不多的情况，反观国内的医疗信息化建设，一家三甲医院的信息化系统基本都在几十个，有的大型医院甚至有100多个，完成一个业务涉及到不同厂商系统的协作运行，系统与系统之间信息必须共享，服务数量和种类繁多大大增加了集成难度。  

2. 接口异构多，协议适配难 

由于不同厂商采用的的开发语言和程序架构是不一样的，甚至有可能同一厂商不同系统的开发语言和程序架构也有可能不一样，当需要交互时就必须有一方需要妥协，进行大范围的适配接口改造，以适应另一方的接口协议要求，如： SOAP、HTTP、数据库等，该操作往往消耗大量的人力、物力和时间。 

3. 交互格式杂，格式统一难 

系统与系统之间服务实现了服务集成、接口适配，这仅仅是实现了系统之间的通信，就好比2个不同国家的人都能够说话，但是说的却是各自国家的语言，例如： 检验使用FHIR标准、检查使用HL7V2标准。 要实现互为理解，数据标准的转换就尤为重要，而每家医疗机构甚至每个厂商自有产品内部还没有统一，更何况全国上万家医疗机构和上千家的厂商。 数据标准转换统一就变得艰巨而又必须面对。 

4. 系统架构老，运行可用低 

现有运行的信息化系统其技术架构依旧采用的是很早期的设计，业务适应力和扩展性欠佳，更无法满足7*24小时的系统高可用运行。 依赖系统本身的架构改良和优化方法已显得捉襟见肘，只能利用医疗机构宏观HIT架构体系的建设来逐步弥补原有单体的系统架构不足。 

5. 云大物移智，基础支撑差 

如今医疗信息化不再是单纯的技术输出，更多是生态化的协作型应用，快速膨胀的微业务和精细化的场景，使得医疗机构需要对于这种信息化迭代具备很强的适应力。 而PaaS层的建设显得尤为重要，然而目前大多数医疗机构依然还是处于最原始甚至无的状态。 

善用互联引擎优秀特质服务互联互通建设 

数据引擎的是医疗信息平台整体功能的核心，承载着业务集成、数据集成、应用集成这三大集成功能的要素，是医疗信息平台核心业务的工作者和集成功能的实现者。 优秀的引擎中间件应具备以下几个特征： 
 

1. 对多种通信协议的支持 

在互联互通测评的标准要求中，以要达到的4级甲等为例，要实现集成临床服务系统至少13+、医疗管理集成至少7+、运营管理系统至少4+、外部机构4+，也就是说最终集成的院内系统至少要24个、外部系统至少也要4个。 在这么多的系统集成要求中，由于种种原因，我们没办法保证所有的系统商城都按照同样的通信协议进行交互。 会出现Webservice、http Restful、数据库等交互要求，通过数据引擎可以将各种通信协议的适配，打通系统与系统之间的通讯障碍。 

2. 对多种医疗标准的支持，包括HL7、CDA、FHIR等 

为了实现医疗业务的全面集成，适应不同医疗业务场景的数据标准，满足不同用户和实际工作中的使用要求，数据引擎附带很强的医疗属性，尤其在医疗标准上支持HL7、CDA、FHIR等一系列的信息医疗标准，并且能够提供相应的可视化标准处理工作界面提供给用户使用，以实现医疗标准在互联互通工作中的正常使用。 

3. 能提供快速易用的数据消息处理工具 

医疗行业的特殊性，使得其所拥有的数据类型繁多，快速上手、简单易用的消息处理工具，能够更灵活的应对互联互通复杂的场景。 在互联互通测评的要求中，就有要求实现标准化的数据集。 拥有开放性的内置脚本处理工具进行二次开发，能应对繁杂多变的数据标化工作。 

4. 具备能够负载7*24小时的高可用运行 

数据引擎承载着医院核心的、关键的、重要的业务功能运行，一旦数据引擎出现问题，则相关集成的业务全部瘫痪，对医院和患者造成的损失是不可预估的。 热备、集群、分布式云计算等方式都是数据引擎对于运行保障的架构部署方式，支持 7*24小时的不间断运行上，在出现运行异常和突发宕机等状况时，数据引擎能自我修复和调整，实现业务的连续性。 

利用数据引擎解决互联互通中核心的标化问题 

医院信息建设中，传统集成方式缺乏对医疗业务的理解，技术和业务割裂，很难实现真正意义上的互联互通，其根本是交互的数据缺乏临床标准数据的语义支撑，集成系统本身没办法进行本地化改造，导致集成引擎被用户所诟病。 

1. 解读 - 辅助数据标准解读，本地化快速融合 

对数据引擎内置数据集及CDA文档Schema进行理解和使用，为解决异构系统之间的业务语义集成降低了实施难度工作，针对项目情况以及用户建议进行适度改进，便能很好的消化成为医疗机构自我使用，不会造成水土不服。 

在互联互通测评工作中，标准的学习和解读是一个漫长的过程，许多人无法坚持，但是通过内置标准数据集和CDA功能，用户可以快速的解读标准，加快学习进度，使得互联互通测评工作进度得以快速向前推进，最终助力医疗信息标准在医院实际业务运用中实际落地。 

2. 实现 - 一体化处理实现数据标准化 

数据引擎工具能够解决的问题不是单单提供一个数据集成和CDA的转换功能，而是完整的一套从业务数据到数据集成，再到CDA文档的数据标准化流程解决方案，用户通过这一整套流程解决方案实现互联互通标准化。 

传统的集成方式更多采用功能拼凑来达到一个目的，其局限性只是为了完成某一个特定目标，不具备全局性和持续性，遇到新的要求和标准，用户只能另行采购达到标化要求，打补丁的方式会导致最终的建设成果不可靠，经不起外部需求的波动。 

数据引擎在CDR建设开始即对其中的数据元、值域、数据类型的工作进行标准化建设，通过自有的ETL功能将对标准过后的CDR进行数据抽取，在利用内置的数据集Schema处理工具对其数据进行数据集的构建，同时对流转数据又能够实现二次分发，最终形成临床意义上真正可评、可用的医疗数据。 

3. 改进 - 监督式自反馈标准改良 

数据引擎具有学习反馈能力，对已有的数据集进行不断的分析和学习，进而反向的督促用户去改善医院信息建设中存在的问题。 用户在被动接收到这些反馈后，能对实际流转的数据标准存在的不足和缺失及时进行修补和改进，通过可视化工具了解标准与标准之间的关系，从而进一步加强信息化工作者对标准的理解和处理，提高标准化评测和实际生产的融合。 

结语： 

互联互通标准测评中拥有众多的信息系统建设指标以及数据标准指标要求，数据集、CDA、SOA系统架构等对信息化的建设，都有很好的扩展性和灵活性，为医院信息化建设指明了前进的方向。 

由于测评方案推出的较晚，国内各厂商支持力度和理解度不够，医院信息化人员也不甚了解，还有医院自身还处在信息化基础建设的行进路上，更无暇新标准的学习消化。 

通过数据引擎协助完成标准化的建设，会节约学习时间，大大降低实施门槛，从而实现医疗信息化互联互通建设的软着陆。