区域医疗卫生系统的接口规范、接口类型和接口设计方式

Struggle

企业服务总线

数据交换服务总线（ESB）是整个区域医疗信息平台的技术核心，通过ESB模式实现各种数据交换的需求。应用系统通过服务总线暴露和调用服务，通过总线实现数据复制、抽取、转换、加载（ex-tract & transformation & loading，ETL）和联邦。ESB 提供：安全服务网关、协议/消息转换、服务组装、服务动态路由、数据复制、数据ETL、数据联邦、统一服务错误处理等关键技术组件。同时，总线能够与服务注册库配合，实现服务的注册管理、动态查找。采用总线架构模式，可以避免服务的硬绑定和硬连接，实现服务消费方和服务提供方的松耦合。
1. 服务请求方 在ESB构架中，服务请求方为发起请求的应用系统，通过ESB提供的源适配器，将请求消息发送到入点的前置服务器的发送队列。
源适配器为发送方应用系统与ESB数据中间交换总线的桥梁，适应目前医疗行业业务系统所采用的系统平台和开发语言有较大差异，各种平台，上都有对应的源适配器，支持C、COM、JAVA等不同开发环境。
2. 消息中间件 消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。
在消息队列（message queue，MQ）中，队列分为很多种类型，其中包括本地队列、远程队列、模板队列、动态队列、别名队列等。本地队列又分为普通本地队列和传输队列，普通本地队列是应用程序通过API对其进行读写操作的队列；传输队列可以理解为存储-转发队列，如将某个消息交给MQ系统发送到远程主机，而此时网络发生故障，MQ将把消息放在传输队列中暂存，当网络恢复时，再发往远端目的地。
远程队列是目的队列在本地的定义，它类似一个地址指针，指向远程主机上的某个目的队列，它仅仅是个定义，不真正占用磁盘存储空间。根据应用逻辑划分，ESB主要划分成发送和接收两种队列：①发送队列；②接收队列。
3. 服务提供方 SOA设计中将应用系统对外提供的实现了特定的、可标志的一组（业务）功能称为服务。除了业务功能，ESB 内配置的服务还实现中心管理接口，以及参与环境的边界配置、操作和监视。

数据接口设计

（一）数据接口规范
1. 信息基础设施规范
（1）前置设备规范：要求各接入单位应具备相应的前置设备，该设备应能支持以下两方面的服务功能：前置设备应为部署区域平台提供的数据交换前置程序提供相应的硬件基础支持，性能指标应符合区级平台进行数据交换的相关技术要求。
（2）网络设备规范：各单位可以依照自身的网络条件选择通过虚拟专用网络（virtual private net-work，VPN）或专网的方式实现本地网络同区域平台中心网络间的连接。各单位应该根据所选择具体接入方案选用所需要的各类网络设备。但在制订方案时应保障以下两点：
1）各接入单位的各类数据交换前置设备，应连接在独立的网络接入交换机设备上，保障数据交换前置区级网络的独立性。
2）各接入单位应具有独立的防火墙设备，由区域卫生平台利用该设备制订数据交换前置区域网络、区域卫生平台中心网络、各接入单位内部网络间访问规则。
2. 前置端应用支撑技术规范
（1）前置端应用支撑技术要求：为确保整个区域医疗服务平台技术方案的统一性、数据采集稳定性、应用维护的便利性，在此对前置设备上所部署的各类软件系统进行统一规范要求。
（2）操作系统规范要求：要求前置端的操作系统在安装时对系统管理员账号进行统一设置管理，对其密码设置强度应有统一要求，避免由于密码强度过低导致的安全问题。
（3）数据库应用：根据数据交换技术方案要求，在前置端需要部署相应的数据库应用软件，由该软件负责上传数据文件的队列缓存、文件索引、文件存储、文件备份等功能。
（4）代理服务器：根据数据交换技术方案要求，在前置端需要为所部署的接口应用提供相应的Http服务功能，为后续的前置端应用功能部署提供相应的基础服务支撑。
需要补充说明的是，由于数据接口应用的要求，在安装过程中除正常安装IIS服务标准功能模块外，还需要配置IIS反向代理模块功能。另外，出于安全考虑，相应IIS互联网信息服务及IIS反向代理模块功能所涉及的访问端口和管理端口应统一进行设定和管理。
（5）远程管理服务：为了满足中心对前置设备维护、管理的需要，在前置设备上部署、设置相应远程管理服务应用功能，便于中心端的管理人员利用此类服务对前置设备进行管理和维护。另外，考虑到安全方面的问题，远程管理服务所涉及的访问端口应统一进行设定。
3. 中心端应用支撑技术规范
（1）数据库应用：数据库平台方面，要求中心端选用大型商业数据库软件作为其数据库应用服务软件。该数据库平台应能支持Windows、LINUX或UNIX操作系统。
（2）应用支撑系统：应用服务器软件选择上，要求中心端选用商业应用服务器软件作为其应用服务器软件。该应用服务器软件应能支持Windows、LINUX 或UNIX操作系统。
（3）其他应用平台功能：要求中心端提供消息队列服务相关应用服务功能，为前置端的数据异步上传提供应用服务支持。要求中心端提供ETL应用服务功能，为中心端的数据处理、数据集的建立提供必要的基础应用服务支持。需要补充说明的是，该ETL应用服务功能应对XML数据具备较强的支持能力。
（二）数据接口类型
1. 数据采集接口 通过数据采集接口可以将接口文档规定的医疗相关的数据上传至区域平台。数据采集范围主要包括医疗数据和公共卫生数据的采集。
医疗数据来源于各家医院的内部信息系统（如HIS、LIS、RIS、CIS系统）。医疗业务涵盖门诊类业务和住院类业务。门诊类业务是指普通门诊、急诊、专家门诊、特需门诊、专科门诊；住院类业务是指：普通住院、急诊观察、特需住院。病人是指获得医疗服务的人，包括医保卡、社保卡以及健康卡等就诊人员。医疗数据采集主要包括病人基本信息、病人就诊履历、实验室检验报告、影像诊断报告、住院相关病历、门诊/住院诊断报告等。
公共卫生数据是在疾病预防控制中心、妇幼保健所等专业公共卫生机构的日常业务中产生的，主要包含健康档案管理、预防保健管理、康复管理、健康教育管理、妇幼保健等信息。
2. 健康卡服务接口 居民健康卡服务接口是为了让接入区域医疗平台的机构通过接口改造，实现区域内健康卡在跨医疗机构的通用，可在医院前端完成健康卡的发卡、换卡、挂失、注销等流程。
3. 健康档案调阅服务接口 健康档案调阅服务是医疗机构间信息共享的一个典型应用，各医疗机构通过动态链接库或统一资源定位符（uniform resource locator，URL）方式等直接接入健康档案调阅服务，URL调阅采用自检（power on self test，POST）方式，在医院前端调阅病人以往的健康状况、就诊记录及检验检查报告。
4. 机构间会诊接口 机构间会诊，又称院间会诊、医生外出会诊，医生经过所在医疗机构批准，为其他医疗机构特定的病人开展职业范围内的诊疗活动。
5. 双向转诊接口 社区卫生服务机构与区域大中型综合医院、专科医院签订协议，让一般常见、多发的小病在社区卫生服务机构治疗，大病则转向二级以上的大医院，在大医院确诊后的慢性病治疗和手术后的康复则可转至社区卫生服务机构。双向转诊规范基层与上级（大中型医疗机构）之间病人的有序流动。
6. 转诊预约接口 对于转诊预约的情况，转诊系统将与预约系统通过转诊ID进行关联。接入单位系统把系统中相关数据整理汇总后通过接口调用传递给平台接口。平台根据传入的参数，预设生成转诊单。转诊系统接口方式整合社区诊间预约功能，在生成的转诊单界面上提供查询转入方医院医生门诊排班表及预约功能。通过接口集成，在医院前端可以直接发起门诊转诊、入院转诊、康复转诊、住院转诊。
（三）数据接口方式
1. 中间数据库 通过定义一套对接双方需要的中间数据库表结构，将各系统的信息数据转存到该中间库中，平台通过一定的间隔时间进行整表或增量的同步更新，从而实现数据共享和交互。通过中间数据库方式进行数据共享，对接双方不需要直接访问，甚至不需要知道对方的数据库，只需要按照定义的中间库表结构提供或获取数据信息，实现数据共享对接。通过中间库进行数据共享具有快速高效、保证数据完整性和安全性等优点。
2. 动态链接（dynamic link library，DLL）库 动态链接是把一些经常会共用的代码（静态链接的OBJ程序库）制作成动态链接档，当可执行文件调用到DLL档内的函数时，Windows 操作系统才会把DLL档加载至存储器内，DLL档本身的结构就是可执行文件，当程序需求函数才进行链接。通过动态链接方式存储器浪费的情形将大幅降低。
由于医院HIS多数采用C/S架构的系统，通过动态链接库可以方便医院HIS系统调用实时性较强的接口，并嵌入到自身的业务系统中，有利于平台和医院之间的数据交互和整合,提高使用者的用户体验，同时也能降低医院HIS系统的改造难度和改造周期。
3. Web服务接入 Web服务（Web service）是SOA架构和云计算的基础，主要用以支持网络间不同机器的互动操作，通过提供应用程序接口（API），在满足相关协议（RPC、SOAP、Restful）的基础上执行客户所提交服务的请求。Web 服务具有平台无关、编程语言无关等优点，而且软件之间耦合度非常低，部署和开发也很灵活，是未来软件开发的趋势。区域医疗平台的数据接口最好是通过Web服务接入的方式，在定义好接口的基础上对接双方可以各自进行开发、调试，大大提高接口开发的效率。
4. 事件驱动架构（event- driven architecture，EDA） EDA是一种低耦合、可分布式的架构。EDA首先需要定义出一系列事件，以及每个事件的发生者和接收者。当某个事件触发，发生者会向平台发送一条消息（event- log），对此事件感兴趣的接收者会针对这条消息执行相关的业务逻辑或回调函数，完成对此事件的处理。EDA通常采用发布/订阅机制实现。EDA提高了对不断变化的业务需求的响应，最大限度地减少了对现有业务应用的影响，大大增强不同系统间协同快速响应和解决问题的能力。


数据接入方案

为了实现各医疗卫生业务数据能够与区域医疗服务平台实现联动，需要在医疗卫生机构部署数据交换前置服务部件，以数据交换适配器的方式实现各分区医疗卫生信息系统（HIS、 LIS、PACS、社区卫生系统等）的集成接入，按照SOA的设计理念，被集成系统需要与数据交换平台交互的功能组件、数据组件将被封装成“服务”，屏蔽被集成系统所采用的具体技术及其实现方式，以标准的接口方式与数据组件将被封装成“服务”，屏蔽被集成系统所采用的具体技术及其实现方式，以标准的接口方式与数据交换平台衔接。同时根据需要部署前置数据库，进行交换数据的前置缓存。各个应用系统通过与服务总线ESB实现消息交互。通过在业务系统端安装相应的软件适配器，实现与消息交换中心的信息交互。适配器由软件模块、软件配置文件、应用编程接口等组成。
在消息总线系统的整体设计架构中，各个具体的业务系统通过Adapter连接到消息交换平台收发业务数据。适配器起着耦合消息交换平台与具体业务系统的作用。在方案中有3种适配器:标准适配器、专用适配器和商用适配器91。标准适配器是由标准的Adapter Kernel 和API组成。Adapter Kernel实现和消息交换中心的消息交互和对消息的实时监控，并提供将消息分发到应用系统的功能。API是为应用系统提供的一套标准接口，具有足够的扩展性，可以灵活地嵌人到业务流程中，同时将与业务无关的通讯配置定义与业务代码隔离。
第一步：接入单位生成数据文件
接入机构按照数据规范中的相关数据接口准备数据，然后使用转换程序按照相关XML结构定义语言（XML schema definition，XSD）描述生成XML，并调用CA中心提供的签名程序对XML签名并生成含签名值的XML，使用文档注册程序把含签名的XML注册在前置设备。
第二步：前置程序验证数据文件
前置设备首先会验证文档签名，如通过后返回机构文档注册程序成功标志，表明此文档顺利提交；否则返回失败及失败原因，程序接收到错误信息后，根据错误信息代码及描述对文档或数据重新处理后再次提交，直到成功。
在对XML进行数字签名时，必须符合XML.数字签名标准（XMLDSIG）。对XML签名内容范围为整个文档内容（包含注释），概要算法为SHA1,转换方式为ENVELOPED，这样在对整个文档进行引用并生成摘要值的时候，< Signature>元素不会被计算在内。
第三步：前置程序上传数据文件
前置设备在对所接收到的数据文件进行验证后，将根据各类数据文件的注册类型分别选择采用实时数据上传或定时批量数据上传的方式，将通过验证的数据文件提交给区域平台的数据接收服务端。
第四步：区域平台接收数据文件
区域医疗平台的数据接收服务端收到上传数据后，利用区域平台本身自有的应用服务功能对上传数据文件进行处理，并统一存储到核心业务库中，为区域平台的其他业务应用提供统一的数据基础。
第五步，区域平台数据错误反馈
区域医疗平台在接收上传数据的过程中对各类上传数据的关联性、本次上传数据和历史上传数据的关联性进行验证。并将验证结果通过相应的应用功能反馈给接入单位，方便接入单位进一步提高所提供业务信息的数据质量。

来源：https://www.toutiao.com/article/704182********23912
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！