CN101052041A

CN101052041A - 医疗信息系统集成引擎

Info

Publication number: CN101052041A
Application number: CN 200710068477
Authority: CN
Inventors: 段会龙; 吕旭东; 赵晨晖; 刘济全; 陈照丹
Original assignee: Zhejiang University ZJU
Current assignee: Zhejiang University ZJU
Priority date: 2007-05-10
Filing date: 2007-05-10
Publication date: 2007-10-10

Abstract

本发明公开了一种医疗信息系统集成引擎，用于解决医疗机构中各异构医疗信息系统的集成互连问题，包括消息接收解析组件、工作流驱动组件和消息组织发送组件，消息解析组件接收来自各医疗信息系统的消息，对消息进行解析后产生对应的待处理事件，工作流驱动组件根据工作流驱动配置处理待处理事件，将待处理事件数据归档于医疗数据中心并产生待发送消息，消息组织发送组件组织待发送消息，并将待发送消息发送给对应的医疗信息系统。使用本发明医疗信息系统引擎，各异构医疗信息系统两两之间的集成问题变成了医疗信息系统与集成引擎的集成问题，减少了集成复杂度。

Description

医疗信息系统集成引擎

技术领域

本发明涉及医学信息领域，尤其是指一种医疗信息系统集成引擎。

背景技术

医疗机构是一个包含多科室的复杂机构，各科室业务具有很强的特异性，没有一个单独的医疗信息系统能满足整个医院所有科室信息管理的需求，为实现各异构医疗信息系统的信息共享和综合利用，医疗信息系统间的集成是关键。

国内在医疗信息系统集成的研究和应用上发展较慢，通常采用数据库共享或者中间数据库等方式。这些集成方式导致系统间耦合度较高，独立性较差，在实施过程中往往需要系统定制，难以推广。

在国外，基于HL7(Health Level Seven)、DICOM(Digital ImagingCommunication in Medicine)等标准通讯协议的集成技术已经研究并应用多年，但由于标准通讯协议定义上比较灵活，系统集成时仍需要定制，因而近几年发展起来的IHE(Integrating Healthcare Enterprise)技术框架(规范了如何应用HL7、DICOM等标准通讯协议进行集成)得到了各大系统厂商的广泛支持。由于医院存在大量的异构医疗信息系统，仅有标准通讯协议和IHE技术框架尚不能实现“即插即用”式的系统集成，一个新系统的加入需要和现有的系统逐一集成，随着系统数量的增加，接口数量成几何级数上升，集成代价很高，并且任一个系统的升级和更换需要与所有相关系统重新进行集成测试，维护成本很高，同时工作流的调整需要关联系统修改程序。另外，由于医疗数据在各信息系统内部分散存放，各系统提供Web页面或客户端软件的方式让用户浏览数据，用户需要学会操作各系统的客户端界面，并且需要在各系统客户端间不断地切换，操作复杂、学习难度较大，这种操作模式很大程度上制约了医疗数据的价值。

发明内容

本发明的提供了一种医疗信息系统集成引擎，以一种新的集成模式实现各异构医疗信息系统的集成，解决现有系统集成中存在的问题。

一种医疗信息系统集成引擎，通过HL7、DICOM标准通讯协议消息的接收、处理和发送来实现医疗信息系统之间的集成，其特征在于包括：

消息接收解析组件，用于接收、解析来自各医疗信息系统的消息，解析过程中，通过各医疗信息系统对应的字段映射机制和脚本程序，实现消息的字段映射和消息字段中数据元素的代码转换，屏蔽各医疗信息系统的差异，解析消息后对应产生一条待处理事件；

工作流驱动组件，以待处理事件的事件来源、事件类型等相关事件属性作为输入条件，根据工作流驱动配置，将事件信息保存到医疗数据中心，并触发产生若干条待发送消息；

消息组织发送组件，用于组织待发送消息，将待发送消息发送给对应的医疗信息系统，组织待发送消息过程中，通过各医疗信息系统对应的字段映射机制和脚本程序，实现待发送消息的字段映射和消息字段中数据元素的代码转换，屏蔽各医疗信息系统的差异；

消息解析组件接收来自各医疗信息系统的消息，对消息进行解析后产生对应的待处理事件，工作流驱动组件根据工作流驱动配置处理待处理事件，将待处理事件数据归档于医疗数据中心并产生待发送消息，消息组织发送组件组织待发送消息，并将待发送消息发送给对应的医疗信息系统。

所述的消息为符合HL7标准通讯协议的HL7消息或符合DICOM标准通讯协议的DICOM消息。HL7消息包括病人入院、出院、转院、检查申请、预约安排、检查状态变更通知、报告发布和收费通知等业务工作流信息。DICOM消息包括放射、超声、内窥镜及病理显微镜等影像设备类型的静态和动态DICOM图像的存储消息。

集成引擎基于HL7、DICOM消息方式与医疗信息系统集成，实现医疗信息系统的业务流程集成，并将所有医疗数据在数据中心集中归档，实现医疗数据集成。

所述的工作流驱动配置以XML文件形式表达。通过工作流驱动组件驱动业务流程，通过XML方式配置业务流程，通过修改工作流驱动配置XML文件实现工作流的动态调整。

通过本发明医疗信息系统集成引擎，各医疗信息系统间不再需要两两集成，只需要与系统集成引擎实现集成，单一系统的升级和更换不会影响其他系统；通过工作流驱动组件可实现业务流程的动态调整；所有医疗数据在医疗数据中心集中归档，可以基于此实现医疗数据的集成浏览。

附图说明

图1为本发明医疗信息系统集成引擎逻辑结构图；

图2为消息接收解析组件处理HL7消息的工作流程图；

图3为消息组织发送组件的工作流程图。

具体实施方式

如图1所示，一种医疗信息系统集成引擎，通过HL7、DICOM标准通讯协议消息的接收、处理和发送来实现医疗信息系统之间的集成，包括：

消息为符合HL7标准通讯协议的HL7消息或符合DICOM标准通讯协议的DICOM消息，DICOM消息包括放射、超声、内窥镜及病理显微镜等影像设备类型的静态和动态DICOM图像的存储消息。

HL7消息包括病人入院、出院、转院、检查申请、预约安排、检查状态变更通知、报告发布和收费通知等业务工作流信息。HL7标准通讯协议定义比较灵活，消息接收解析组件处理HL7消息的工作流程如图2所示，包含如下步骤：

(1)消息接收：捕获网络上的HL7消息，以文本方式存放在本机内存中；

(2)消息解析：解析本机内存中的HL7文本信息，按照信息段(Segment)、数据域(Data field)、数据元素(Component及Sub-component)的层次结构组织数据；

(3)字段映射：同一数据在不同系统的HL7消息中可能存在于不同信息段的不同数据域中，通过字段映射表实现字段映射，屏蔽系统差异；

(4)代码转换：HL7标准中有很多数据元素没有提供现成的数据定义表，因此不同系统中同一个数据可能用不同的代码表示(比如性别的代码：有的系统用M、F、O代表男、女、未知，有的系统用0、1、2代表男、女、未知)，通过加入Python脚本程序实现对不同系统代码的正确转换，最后将经过代码转换后的消息保存为XML文件；

(5)解码：有些HL7消息中包含二进制文件，比如报告发布的消息，由于HL7通讯协议规定传输的必须是ASCII中的可见字符，因此二进制文件在发送前作了编码转换，则需通过解码将转换成原始的二进制文件。

(6)将HL7消息以XML文件附加二进制文件方式存放在本地的代处理事件缓冲区中，作为一个待处理事件等待工作流驱动组件处理。

工作流驱动组件以待处理事件中的参数作为输入，根据工作流驱动配置，生成一条或多条待发送消息。工作流驱动配置以XML文件形式表达。

下面举个实例来说明工作流驱动配置文件的组织形式和工作流驱动过程，假设现在需要处理HIS(医院管理信息系统)系统的病人入院、病人姓名变更和检查申请消息，关联系统包括放射科RIS/PACS系统(RadSystem)、超声科信息系统(USSystem)，相应业务规则要求如下：

1)病人入院信息(A01)保存到医疗数据中心，不需要发送给其他系统；

2)病人姓名变更信息(A08)保存到医疗数据中心，并发送给放射科RIS/PACS系统(RadSystem)和超声科信息系统(USSystem)；

3)检查申请(O01)保存到医疗数据中心，当发往科室是放射科时，检查申请发送给放射科RIS/PACS系统(RadSystem)，当发往科室是超声科时，检查申请发送给超声科信息系统(USSystem)。

工作流驱动配置文件示例采用XML语言编写，具体语句为：

　　＜EventSource Name＝″HIS″＞

　　    ＜EventType Name＝″A01″＞

　　        ＜Activity Name＝″A01EventSave″ErrorAbort＝″True″/＞

　　＜/EventType＞

　　＜EventType Name＝″A08″＞

　　      ＜Activity Name＝″A08EventSave″ErrorAbort＝″True″/＞

　　      ＜Activity Name＝″HL7Message″Destination＝″RadSystem″Type＝″A08″/＞

　　      ＜Activity Name＝″HL7Message″Destination＝″USSystem″Type＝″A08″/＞

　　＜/EventType＞

　　＜EventType Name＝″O01″＞

　　      ＜Activity Name＝″O01EventSave″ErrorAbort＝″True″/>

　　      ＜RelatedDepartment Name＝″放射科″＞

　　           ＜Activity Name＝″HL7Message″Destination＝″RadSystem″Type＝″A01″/>

　　           ＜Activity Name＝″HL7Message″Destination＝″RadSystem″Type＝″O01″/＞

　　＜/RelatedDepartment＞

　　＜RelatedDepartment Name＝″超声科″＞

　　      ＜Activity Name＝″HL7Message″Destination＝″USSystem″Type＝″A01″/＞

　　      ＜Activity Name＝″HL7Message″Destination＝″USSystem″Type＝″O01″/＞

　　    ＜/RelatedDepartment＞

　　  ＜/EventType＞

　　＜/EventSource＞

其对应的工作流驱动组件处理过程如下：

1)接收到HIS系统的A01消息(病人入院信息)，在工作流XML配置文件中找到对应的操作为A01EventSave，这是系统内部预定义的操作，将A01消息中的相关信息保存到医疗数据中心。

2)接收到HIS系统的A08消息(病人姓名变更信息)，对应的第一个操作是A08EventSave，将A08消息中的相关信息保存到医疗数据中心，第二个操作是向RadSystem发送HL7A08消息，第三个操作是向USSystem发送HL7 A08消息。第一个操作的ErrorAbort属性是True，代表如果此操作失败，后续操作也取消。

3)接收到HIS系统的O01消息(检查申请)，对应的第一个操作是O01EventSave，将O01消息中的相关信息保存到医疗数据中心，接着再判断发往科室(RelatedDepartment)条件，如果是“放射科”，第二个和第三个操作分别是发送HL7 A01和HL7 O01消息给RadSystem，如果是“超声科”，第二个和第三个操作分别是发送HL7 A01和HL7 O01消息给USSystem。

消息组织发送组件负责组织待发送HL7消息并发送给对应的医疗信息系统。HL7消息的发送功能支持发送病人ADT(入院、出院和转院)、检查申请、预约安排、检查状态变更通知、报告发布和收费通知等业务工作流信息，HL7标准通讯协议定义比较灵活，处理HL7消息的工作流程如图3所示，包含获取消息相关数据、代码转换、字段映射、编码、消息组织和发送五个过程。

(1)获取消息相关数据：从医疗数据库中获取消息相关数据；

(2)代码转换：HL7标准中有很多数据元素没有提供现成的数据定义表，因此不同系统中同一个数据可能用不同的代码表示(比如性别的代码：有的系统用M、F、O代表男、女、未知，有的系统用0、1、2代表男、女、未知)，通过加入Python脚本程序实现代码转换，使不同系统都能识别代码的含义；

(3)字段映射：不同系统可能要求同一数据出现在HL7消息中不同信息段的不同数据域中，通过字段映射表实现字段映射，屏蔽系统差异；

(4)编码：有些HL7消息中包含二进制文件，比如报告发布的消息，由于HL7通讯协议规定传输的必须是ASCII中的可见字符，因此二进制文件在发送前需要进行编码转换；

(5)消息组织和发送：最后生成HL7消息，将经过代码转换、字段映射和编码的数据填入信息段的各数据域中，并发送给各信息系统。

集成引擎的DICOM消息处理包括接收放射、超声等科室系统的影像存储消息(DICOM Storage)，并提供DICOM影像查询和获取服务(DICOMQuery/Retrieve)，相关技术和产品已经非常成熟，因此不在本专利说明中详述。

Claims

1.一种医疗信息系统集成引擎，通过对消息的接收、处理和发送实现医疗信息系统之间的集成，其特征在于包括：

2.如权利要求1所述的医疗信息系统集成引擎，其特征在于：集成引擎基于HL7、DICOM消息方式与医疗信息系统集成，实现医疗信息系统的业务流程集成，并将所有医疗数据在数据中心集中归档，实现医疗数据集成。

3.如权利要求1所述的医疗信息系统集成引擎，其特征在于：通过工作流驱动组件驱动业务流程，通过XML方式配置业务流程，通过修改工作流驱动配置XML文件实现工作流的动态调整。