[原创]HL7的应用模式探讨

zhuzhu

这是本人的一点心得，最近成文，所以请各位专家指教
HL7的应用模式探讨
摘要：本文深入介绍了HL7的两种应用模式，并对HL7在国内本地化的过程中存在问题进行了一些探讨。
主题词：HL7
目前HL7在国内经过某些公司一段时间的宣传造势、培训普及，已经开始逐步为国内医疗信息市场所认识和了解，但如何在实际应用中，如何使用HL7标准，目前在国内还缺乏很多的认识和实践。
HL7的发展和简单介绍，已有很多相关的文献资料，在此不介绍。从原理上来理解，HL7标准协议就是一种数据交换协议，并不涉及底层的通讯协议，而这个协议的实质简单的说有些类似于CSV这样的字符串文本协议，定义了相应的字段和含义，当然这个协议要比CSV要复杂一些，但本质是一致。可要实现HL7应用则并不是简单的应用数据交换协议就可以了。此外，在HL7的数据交换中暗含了美国的医疗习惯和医疗管理模式的应用，因此单从这个方面上来说，HL7的应用就不是一个纯粹的技术，如：TCP/IP协议等技术性协议的应用。
在数据通讯方面，有两种层次的数据交换应用。第一层次数据交换应用，是对现有信息进行处理，只是“交换”现有的系统中存在的信息数据。在这个层次上，各个系统所考虑的是，如何获取其他系统的数据来完成本系统内部的功能，并不考虑是否需要提供交互的数据给其他系统或者接收其他系统的需要进行交互的数据进行处理。比如在不同系统之间交换采集到的病人姓名、性别、地址、ID等数据，或者是医嘱、费用等结果信息数据。在这个层次不能交换各种业务过程信息，也不能进行系统和系统之间的交互。比如不同系统之间的预约过程以及预约完成状况的了解等等这些业务过程的实现。注意：这里是“交换”而不是“交互”。
第二种层次的是基于不同系统之间进行整合的数据通讯，其目的达到不同系统之间的无缝连接而进行的数据通讯和数据交换应用。在这个层次的数据交换不仅要交换各种结果信息，同时还要交换各种过程信息，从而达到系统之间的交互目的。应用的原则是：在需要的时候获取需要的信息数据。这正是HL7定义了众多的事件和消息格式的原因。
基于以上两个层次的数据交换方式，对应基于HL7的数据交换也存在两种方式。一种Engine方式，主要目的是使得用户原有正在使用运行的不能替换的系统具有HL7的通讯能力。这种方式主要应用于系统之间较为简单的数据交换，参与数据交换的系统明确，交换的数据信息量少，投资小，系统之间不需要进行交互的情况。这种方式可以不对原有系统的各个应用终端，如各种工作站等进行HL7改造，而只是相当于在整个系统中增加了一个新的通讯处理处理模块来支持HL7的处理，利用这个通讯模块来对系统之间的数据库进行数据操作，达到数据同步的目的。从而使得应用系统的工作站终端可以从数据库中获取其他系统所提供的数据。其主要缺点是：由于系统内的各个应用模块终端并不具有HL7消息的处理能力，因此，无法实现系统与系统之间的实时数据处理，以及应用终端的查询请求等应用。
Ready方式是在整个系统中，在各个应用终端已经对HL7的接口协议进行了设计和处理，各个终端都应当可以接收和处理HL7消息，并进行相关的处理。在理论上可以达到系统和系统之间的实时交互，可以相互主动地在“需要的时候”获取对方可以提供的数据信息。当然，这种方式属于理想的方式，适合于在厂商开发新系统时，从更高的应用角度，进行前瞻性的设计，有利于在多系统应用环境中的应用整合。
从本质上来说，这两个层次在技术上和协议处理上两者是一致的，诸如在技术上对HL7消息机制的处理。如：消息编码，解码；通讯过程的处理上，数据传输、加密、验证等等，只是在实现的方法略有差别而已。但两者在应用层次上就存在着质的飞跃。为了更好的说明，可以假设实际应用来说明这两种层次的数据交换达到的不同效果。
我们以HIS和RIS/PACS之间的数据交换来说明Engine方式的实现：需求产生的起源在于一个病人要去放射科进行检查的时候，为了识别这个病人的信息，放射科需要录入病人的基本信息，而这些信息在住院管理系统中已经全部录入系统了，因此，放射科的这些工作相当于重复的录入工作，由此产生了两个系统之间需要进行的数据交换。但这种交换主要是属于单向的，数据由HIS流向RIS/PACS，以HIS的数据库为数据源。
如果两个系统均采用Engine方式来实现数据交换。其流程是：HIS系统定时将数据库中PACS所需要的数据信息发送到RIS/PACS，并根据病人在数据库中的状态记录，定义其事件消息类型，如入院、出院等，但这种消息类型的定义并没有实时交换的意义，而只是为了传送病人状态，以方便对方系统进行处理而已。这种交换方式只是两个后台数据库之间的数据交换，实际上类似于数据库数据同步的功能。因此，对于各工作站端点的操作人员来说其只能被动的接受数据库中已有数据进行处理，其不能够主动去实现查询、病人位置通知等数据处理操作，也不能做到实时进行数据交换，不能做到在医疗过程中进行系统之间的交互，如：实现通过HIS实时向RIS/PACS下达预约的请求消息，并从RIS/PACS直接获取病人预约信息，在这种情况下需要等到从预约处拿回预约通知单才能够知道具体的预约时间。换句话说，这种方式，只是被动接受其他系统中传送过来的数据，而不是主动去获取数据。
如果我们要主动获取数据，该如何实现呢？或者说主动获取数据有什么意义呢？我们可以设想一个比较复杂的数据交换过程，比如下一个实例：
一个心脏外科病人在胸外科住院，该胸外科应用了供临床医生使用的工作站系统。该病人需要实施心脏手术，在术前、术后需要进行心脏三位片（心脏正位片、左前斜位、右前斜位）的摄片，进行术前、术后的对比。而这个时候在这两次摄片的预约和执行过程中可能出现几种情况：
1、病人在指定的预约时间，因为某种原因不能进行前往放射科进行摄片，需要更改预约时间；
2、在病人预约的排队等候拍片的过程中，由于心功能差或者机器故障，无法实行送检的摄片预约，取消预约，改为床旁摄片预约或更改预约时间；
3、在摄片过程中由于病人情况出现问题，取消了第二、三摄片，更改预约时间；
4、在摄片过程中发现需要进行增强摄片（也许不适用于心三位片）；
5、在摄片当时发现摄片效果不理想，重新摄片；
6、在回到科室后发现摄片效果不理想，进行重新摄片；
7、如果病人对预约的时间有特别要求，或者其中某个操作需要指定某个医师执行，要与放射科协商预约时间。
如果两个系统都是采用第一种方式，在各个工作站（包括胸外科的医生工作站、影像科室的）并没有考虑如何和其他系统进行交互，也就是说在工作站不能处理HL7消息，，那么作为病人的主管医师，必须等候到病人将此以上状况的变更带回到病房，或者与放射科之间进行电话联络，才能够知道摄片的进行状态和结果。
而如果两个系统都是以Ready状态实现，那么当RIS系统中对病人的执行状态进行修改的时候，则会发送相应的预约修改状态的消息传送给病房的医师，并且所有的过程都可以记录在系统中，医师可以随时通过系统了解一个病人目前在其他系统中的状态。甚至，如果一个医院要达到一个更高的服务水准，达到诸如星级宾馆的服务水准：病人在到达医院的任何一个地点，接受某项服务的时候，都有医护人员可以了解该病人的状态，并及时主动为其服务，而不是病人去等待。在这种情况下，医院内整体的信息流动和系统交互就显得十分必要了。
当然，从这个假设中也可以看出，如果要实现Ready状态的诊疗过程设想在国内并不能够获得完全的实现。主要是因为国内和国外的医疗体制存在巨大的差异。比如在美国就诊基本上都需要预约，没有预约是很难见到相关的医生。而在国内医院基本上是以医院为主导，病人自己进行预约和等候的过程。而且在国内的就诊习惯上，尚处于一种垄断的卖方市场，对于病人在就诊的行为上是没有进行选择的权利的，如要求在某段时间内就诊。同时国内医院的管理水平也还属于粗放式的经营方式，即：是完全被动的利用医疗设备、医疗资源去提供各种服务，尚没有达到要主动更好的为病人提供服务的层次，对于病人的就诊来说，医疗市场上属于卖方市场。如果医院的管理还没有达到精益管理经营的层次，那么要用HL7来实现医院内各个信息系统的整合，是如同要在国内不正规的企业内实现ERP一样艰难。比如：要达到可以精益管理，必须能够采用计算机来完全管理所有设备的使用状态和运行，包括人员物资的调配，虽然为这些设备以及人员提供标记、识别ID等，在技术上来说是很简单的，但是能否具体在管理上实现这样的管理方法，则很难保证了。
这里与上一个实例的差别在于：前者只是传递一些静态的短期内不会进行变动的数据或者结果信息，诸如病人姓名、性别等信息，在这个实例中HIS是一个主要的数据源，其地位与RIS是不对等的，RIS系统中病人的数据只是HIS的一个子集，因此可以采用Engine方式实现数据库同步以及数据库的操作。
而在第二个实例中，这两个系统是两个对等的系统进行系统之间的交互，需要传递的除了静态的信息以外，还有很多过程状态的信息。由此可见，Engine方式是HL7的一种简单的应用，其并不关心系统与系统之间的交互，以及系统之间的交互过程。
由上述讨论我们可以知道，对于HL7的应用研究也存在两个大的方面：一个就是HL7本身的技术性研究，诸如：消息格式如何编码解码、如何支持多种通讯协议、如何进行数据转换等方面，这些是可以由专业的HL7开发公司进行开发；另一个方面的研究就是如何应用HL7的数据信息来提高医院的管理能力，或者是加强专业系统的厂商功能，这是在前一步的基础上的更深一层次的研究。考虑到HL7应用是基于美国较为先进的医院管理模式，因为其医院的管理模式已经由粗放的经营模式改变为精细管理，而且对病人的服务水准也非常的高，而这些在国内当前阶段是很难达到这样的应用水平，但这并不意味着我们并不需要去研究HL7。因为在国内很多医院中已经开始有不同的应用系统在使用了，诸如HIS、PACS、RIS、LIS，而且除了这些系统级的应用外，还有各种医学仪器，如：心电图、电子化检验仪器等等，这些仪器中也有很多都是可以通过HL7这个协议进行传输和整合的。在目前阶段虽然不能做到完全整合，但我们可以通过初级的应用，如：应用Engine的方式来解决不同系统之间重复录入的问题等等，逐步获得相关的经验，建立适合国内情况的本地模型和协议，协同医院的管理水平的提升，最终达到逐步实现各个系统的整合。
同时，从另一个方面来说，在美国、日本等信息化投资较早的国家来说，目前最大的问题就是不同系统之间的整合。如果国内医院要避免像美国那样最终因为在医院内使用过多的系统而导致系统整合困难问题或者应用成本过高的问题，在现在就必须提高医院方面的认识，提高他们对系统整合的认识和深入了解，并逐步接受HL7的概念，积极参与到HL7标准的研究、制定和推广中，而这对国内医疗信息产业来说，将会是一个漫长的过程。

tianma

我的观点：
1 Engine方式和Ready方式的差别仅仅在于：Engine方式将hl7解析工作放在应用系统之外；而Ready方式则集成在应用系统内部。
    两种方式都可以达到不同系统之间的无缝连接而进行的数据通讯和数据交换应用。同样都可以实现主动查询或主动发送操作。关键在于hl7的应用深度。
2 没必要强求用hl7的模式来组织医疗系统。正如zhuzhu所说，在HL7的数据交换中暗含了美国的医疗习惯和医疗管理模式的应用。因此，往往会以为为应用HL7就要按hl7来组织系统。但这并不是必需的。HL7协议只是交换标准，未必是合适的医疗管理模式。况且，我们的医疗管理模式不同，照搬是行不通的。只能作为我们的参考。
    如楼上所举的摄片过程的例子，其中重要过程是预约。我们的医院通常不用预约的方式，就不能照搬上面的做法。可以考虑在摄片过程中主动向his查询信息；摄片完成后主动发送结果信息或消息（标志）。当然，也可以由his发起这一过程。这样，不用国外通常的预约过程，也同样完成了系统间的交互。总之，同一事件可以有不同的方法，不必机械套用。
3 即使在HL7 Ready系统内，也不一定要按hl7的模式运作。如PACS系统，内部都是采用专用的处理方式，格式通常采用PACS，只是在对外的接口上才使用HL7标准。
4 尽管采用不同系统的整合有时是不可避免的，但要尽可能采用单一系统或相近的系统。系统间的交互通常是复杂而低效的。我们曾看到，专用子系统所带来的优势，有时竟被系统间交换的瓶颈所抵消。甚至得不偿失！

sbf2000

我认为：
1.Engine方式的实现并不Ready方式容易，只是Engine方式可以使现有的系统向HL7 Ready过渡。
2.Ready方式是HL7应用首选的方式，现在开发HIS系统的公司大都已完成第一版HIS的开发工作，而第二版或第三版由于软件技术的发展，不管是体系结构还是数据结构都将有很大变化。与其受前版的一些弱点干扰还不如重新构造HL7 Ready的HIS。
3.现在Ready方式还难以实现，原因是还没有我国本地化的HL7标准。因此，现阶段研究HL7本地化的意思比研究HL7应用方式更实际。

乖乖兔

楼上两位的讨论非常的精彩,探讨了HL7标准的两种应用模式.Engine方式是在系统的外部挂上一个hl7通讯模块来负责将数据格式化为HL7消息,以实现两个系统之间的通信.Ready方式是生产厂家在系统设计的时候就已经考虑到了hl7标准,系统内部已经提供了hl7接口.但是两者都能不同系统之间的无缝连接.在我国当前的情况看来,因为许多系统已经成型,再对其进行hl7的改造代价太大,所以hl7 Engine方式是比较恰当的一种方式.

dreamaster

ready方式的好处不只体现在应用中，在开发中过程中也可以从中受益，比如，某一现有系统是按照hl7组织消息传递的，那么，在开发新的模块时，就可以向此原有系统发送hl7消息来请求相应的服务，而不必关心操作时怎样具体完成的，这样就有效的利用了原有系统，达到了系统功能复用的目的。

tianma

     如果是我做一个HL7 Ready的his系统，系统对外连接当然要完全符合HL7标准。
系统内的处理也会注意参考HL7的思路，但不会在内部按照hl7组织消息传递。
    在自己的系统内，要读/写一个纪录，直接操作就是了，为什么还要将原始数据先解析为hl7定义的xml格式，以满足hl7组织消息传递标准，然后再解析回原始数据进行具体操作？
    hl7定义的xml或字符串是数据表达格式，无法进行实际的处理（如运算），通常还要将它转换成实例变量后才能进行实际处理。所以，在单一系统内，将处理过程中间的数据按照hl7组织消息传递是没有必要的。
    为什么要hl7？ 因为存在不同的系统，其数据的定义格式、编码等各不相同，无法进行交换，所以人为规定一个统一的表达格式。
    在同一系统内，数据的定义本来就是统一而明确的，完全可以直接使用，为什么还要多此一举，按照hl7组织消息传递？
    hl7体现出来的先进的医疗管理理念是我们要认真吸取的，但不是说要直接把数据交换格式当成我们数据处理格式。
   我们知道，hl7是手段，不是目的。

arbol

看了上面的分析，感觉很精彩，对我现在的工作帮助很大，我现在的思路感觉和engine的思路接近，但重在转发，一个人做太痛苦了。一步一步慢慢来吧

zhuzhu

谢谢大家对拙作的关注。大家的讨论对我进一步的思考也有很多帮助。就大家的讨论，我会继续阐述一下我的想法，但我不太习惯于论坛这种只言片语的交流，所以我会具体的写下来。主要针对：
1、两种方式对原有系统的具体改造体现在哪里？
2、为什么我认为Engine方式不能够实现系统的交互？
3、HL7对构建一个新系统的参考价值在哪里

arbol

关注对于Engine方式实现系统交互的讨论，希望再次见到你的长篇文章。
热切关注中。。。。

JB

在美国也会由公司在很小的题目上大张旗鼓，为其产品的小小优越性造势的情况。每年都要出些新的东西嘛，但 DICOM 和 HL7 都已经是过去时了。
这里我只是想让大家实际点。我再三强调：HL7 是设计来与第三家产品交换数据的格式，而且仅仅是个格式。另外，不象 DICOM, HL7 没有一个 Conformance 这种概念。也就是说，没有 “符合 HL7 标准的产品”这种定义和说法。
要说你公司的产品支持 HL7 2.4。你需要说明什么？
一、接口：1) Inbound, 2) Outbound, 3) Query ...
   具体的： 说明这些是通过什么实现的？ Socket 用那个 port? Message "Start" 和 "End" 标记是什么? 用 HTTP，怎么用 (CGI)？
二、Messages: ADT (那些? 起什么作用? 比如说 ADT08 用来干吗？)
              ORM (那些? 各起什么作用?)
              ORU (哪些? 各起什么作用?)
              QRD (怎么用?)
              ...
针对每一类里的每个 Message 列出个表来，每一个 field (特别是 required) 可能的内容是什么，可以空白吗？不是 required fields 用了哪些？
只有当两个产品需要对话，而且真正开始对话了才能证明 HL7 有用场了。
楼上 zhuzhu 所举的 RIS 例子是很典型的 HL7 的应用例子。
=====================
1、病人在指定的预约时间，因为某种原因不能进行前往放射科进行摄片，需要更改预约时间；
2、在病人预约的排队等候拍片的过程中，由于心功能差或者机器故障，无法实行送检的摄片预约，取消预约，改为床旁摄片预约或更改预约时间；
3、在摄片过程中由于病人情况出现问题，取消了第二、三摄片，更改预约时间；
4、在摄片过程中发现需要进行增强摄片（也许不适用于心三位片）；
5、在摄片当时发现摄片效果不理想，重新摄片；
6、在回到科室后发现摄片效果不理想，进行重新摄片；
7、如果病人对预约的时间有特别要求，或者其中某个操作需要指定某个医师执行，要与放射科协商预约时间。
===========================
对上述 7 个环节，可能牵涉到四台设备：HIS、RIS、PACS Broker 和 CR (举个例)。PACS broker 的功能是 HL7 -> DICOM Modalith Worklist 的转换闸。
就拿我 1997 在 Texas Children\'s Hospital 调机时用到的实际例子：Cerner HIS, IDX RIS, Mitra PACS Broker 和 Agfa ADR CR。
1。病人基本资料可能是 ADT 从 HIS 送到 RIS 的。
2。排拍片和更换时间是 RIS 通过 ORM 和 ORU 告诉 PACS Broker 的。
3。拍片时 CR 用 DICOM Modality Worklist query “PACS Broker” 取得当天的资料。
另外，CR 可以在不同时间用 DICOM Performed Procedure Step 告诉“PACS Broker” 拍片开始了、进行中和结束了。“PACS Broker” 在用 HL7 ORU 转告 RIS。做完还可以将诊断报告送给 HIS。 不过当时大家还没有用到这些东西。
1999 年我们到了同一家医院安装试用 Siemens/Acuson 的 Sequoia。那时这些功能就具备全了。

徐州四院

正如楼上 zhuzhu 所说。
=====================
在这个层次的数据交换不仅要交换各种结果信息，同时还要交换各种过程信息，从而达到系统之间的交互目的。应用的原则是：在需要的时候获取需要的信息数据。这正是HL7定义了众多的事件和消息格式的原因。
====================
看来你的确理解了HL7的真谛，Engine方式只能是过渡，就像中文之星对于WINDOWS一样；而HL7 Ready是发展的必然。这要看你代表的是哪一方的利益，是公司的还是医院的，毕竟目前双方的利益冲突>both winner。
建议你关注一下“工作流”技术，把过程逻辑分离出来，用工作流引擎来驱动，实现应用系统之间的实时通信。
回过头来看看，目前国内有几家公司能做到这一点？抑或是不愿去做到这一点？个中原由仔细体会以下就能明白为什么现在是“Engine”的天下。

hotrain

[这个贴子最后由hotrain在 2003/05/02 07:51pm 第 1 次编辑]

看完大家的讨论，我深感受教，我自己是一个RIS的管理员，也兼管部分PACS。我也想写点有关HIS的小程序，就是在HIS是否在HL7上下功夫上犹豫。下面提提我的看法：
做HIS时，是不是在内部不用考虑太多？（主要是按要求HL7的标准来写）实际上我们医院用的HIS（还不完善）系统到现在有3-4年了，但是还没有在HL7上下大功夫。
就如上面某君所言，系统内部不用都做HL7标准，在系统出口的部分再去做HL7是不是更能体现一个系统的优越性？就我所知，我院用的PACS和RIS都是按自己的标准在内部做的，在相互访问的时候才有所改变。在具体使用的时候，医师，技术人员，检查医师是不会去管你这个系统是不是支持HL7，他就需要使用方便，有需要的所有信息，这些在国际上来说就每个医院有自己的要求。一个医院的数字化，或者说信息化，必定有自己的特点，这个在国内的医院尤其明显。
对于上面讨论的Engine和Ready两种方式，我不知道是不是我个人理解有误，但是我院的系统间访问都是由信息的需要者去向信息的提供者主动发出请求来获取信息，这在上面的论述中是不是Ready的方式？如果是的话，那怎么还说“现在是“Engine”的天下”？

JB

hotrain 说的一点没错，医师、技师、检验师才不管内部是不是支持 HL7。他们要求的是怎么能提高他们的工作效率，而不是给他们增加工作。另外，HL7 标准并不定义一个 HIS 的内部设计，其实它与内部设计没有关系，也不是专为 HIS 定义的。
因为你们的系统是内部设计自己用的，唯一的要求就是实用、维护简单。有时间写点 VB 和 ODBC 的小管理工具。有兴趣写写 HL7 的接口、目的是学习。
一个有实用价值的项目：做个 RIS 到 DICOM worklist 的 gateway。先看看 CT,MRI,CR,Ultrasound 之类的设备有没有 Worklist 的功能。如果 RIS 全是中文， 这个 gateway 要有中文到拼音的自动翻译。

ironstone

是的，对于系统的应用者来说，并不关心内部的设计，就好像我们用word并不关心word程序的设计，但对于厂商和医院的投资管理者来说，就需要考虑这个东西，毕竟这和他们的成本投入是有关系的。

kangzhihong

我在《美国卫生信息工作标准HL7——跨医疗卫生体系信息交换理论入门》一书中看到了论坛中的内容，版主能不能介绍一下ZHOUZHOU和JB是何方神圣。