[原创]关于HL7应用问题的看法

tianma

[这个贴子最后由tianma在 2002/12/18 07:33am 编辑]

最近刚学了一点HL7的基本内容，将学习过程中的一点看法写在这里，由于学得浅薄，观点也未必正确。期盼大家给予帮助和指正。
    HL7是位于网络第7层--应用层。从本质上来看，它确实属于数据交换的协议。
但由于它是应用层协议，它和实际应用关系非常密切。如各种事件和消息格式的定义就是直接作用于医疗过程。作为在成熟的医疗体系下建立的标准，它的的许多内容，特别是许多定义和编码对我们设计医疗系统很有帮助和启发，但它不能用来规范医疗系统。因为目的不同。HL7好像是交通规则，通过它可以了解高速公路的设施和管理，但不能按照它设计高速公路，因为他没有也不可能有平整度、高差和施工规范的规定。另外，交通规则涉及到所有交通设施，如立交桥高架桥等，在实际建路时则不一定都要建设。设计医疗系统也是这样。
    如ironstone所说，这个交换包括了数据传递外，还包括了事件和消息的交互。
不同的部门，甚至不同的机构之间，它们彼此完全独立、结构的定义可能完全不同，比如，医院用Caché ，而社保用oracle"医院用xml定义一个事件，而社保用记录和过程定义同一事件"医院用数字型定义一个字段，而社保用字符型定义同一个字段，其名称也不同。因此，医院和社保之间无法直接读取，更不用说交互操作了。只好各自作各种各样接口，有时根本就无法连接。
    有了HL7这个应用层协议，事情就好办了。通过hl7服务器，各医院之间、医院和社保之间可以像调用函数处理自己的系统一样，调用甚至进行处理操作（在权限内），而不需要考虑对方在一个什么系统里，如何实际执行具体的操作的。
    举一个不确当的比方。操不同的语言的人开国际会议，需要各自带许多语种的翻译。于是制定了有各种规则的世界语，这样大家可以用自己的语言进行思考，而统一用世界语来发言。这个世界语就是hl7。
    医院之间当然应该用hl7进行交换。医院内部各部分之间是否也要用hl7，要具体分析。如果同时用不同的软件系统，自然也要用hl7；而在同一软件内部则大可不必按hl7来搞。因为hl7为了不同系统的交换，定义相当复杂，效率自然不高。同一软件内部完全可以直接交换，为什么还要画蛇添足地也搞转换呢？按上面的比方，本国人之间何必用世界语交谈？即使要协调方言，也比大家都费劲学世界语说话要强呀
    虽然从理论上说，严格执行hl7标准的不同软件可以在同一环境下同时工作，但是由于存在着自定义事件和消息的衔接问题、例外处理问题、维护责任和故障定位问题...，特别是效率问题，这样的系统肯定难于使用和维护。所以还是要尽量选用单一软件为好。
    xml是hl7新选择的表达方式，因为它比文本表达更丰富、更直接。有朋友建议用XML文档来存贮标准编码，我感觉不太可行。XML是一种表达的格式，类似于文本文档、word文档、htm文档，是有外包装的商品。可以做一个大的包装，将很多商品都装在一起，但使用不方便。而数据库是货柜，是仓库，便于保存和检索。
    至于hl7的实际使用，我想应该是由专业公司按hl7标准做专门的商品化的hl7服务软件或中间件。his开发商则通过在应用程序内使用商品化的hl7服务软件来进行hl7的实际使用。his开发商自己做这个相当于为做一个应用而自己搞一个数据库系统一样愚蠢。
    因此，对于探索、研究、制定hl7标准的人、对于开发hl7服务软件或中间件的公司，hl7自然是研究目标。
    对于his开发商，它是hl7的真正应用者，但不是其积极推动者。
    如果hl7已成为必须遵守的标准，his开发商可以直接应用hl7服务软件甚至hl7服务器将自己的his加上hl7应用；如果hl7还不是必须遵守的标准，那么his开发商上hl7应用还有什么意义呢？它和谁交换呢？
    对于大而全的his开发商来说，hl7对它的用处不大。原因上面已说过了；对于单项应用的开发商来说，它有这个需求，因为有此标准它可以更容易和主系统衔接。
    至于医院，作为医疗软件的应用者，只要了解hl7的基本知识就行了。除非他想自己做系统。
   

sbf2000

tianma的分析比较深刻。有两点问题不知您如何看待：
1.对于his开发商，使用HL7的目的除了HL7是标准和为了进行数据交换外，还有其它目的吗？如规范自已的HIS系统研发，使用HL7作为HIS的系统分析参考，开发通用按应用领域划分的HIS子系统等。
2.如你举的例：XML相当于有包装的商品，而数据库是货柜仓库。对于一个商品，我们只要稍加包装，便于使用就行了，没必要一定放到货柜或仓库中。对于多个商品我们可以用货柜来存贮，但使用时还是以包装形式轻便。现在数据库有SQL语言，XML有XSLT、XPath等对数据进行保存和检索。当然，对于传统的C/S结构，有数据库支持的软件没必要一定用XML存贮标准编码，需对于基于XML开发软件，没有必要一定使用数据库，直接用XML存贮数据就可，还可以降低应用成本和维护成本。由于XML数据可以方便地以Web服务等方式集中管理和发布，有助于开发基于多层体系的软件，保证软件编码统一。也可把XML存贮编码数据与软件放在客户机上，有些可以单机使用的软件就没有必要一定使用网络。使用XML存贮编码数据还可以促进松藕合的分布式社区系统软件开发。

tianma

   HL7作为HIS的系统分析参考确实是非常重要的。HL7是基于比较成熟先进的的医疗体系而建立的标准。我们从中可以学到许多先进的理念和科学的方法。
    我感觉HL7子系统划分的方式和HIS子系统不完全相同，如财务系统。由于HL7是信息交换标准，所以它是以事件为中心，财务信息作为其中的属性或者说消息来处理的。而在HIS的财务子系统，财务信息是主体，它不依照医疗事件来处理，因此完全按照HL7来定义HIS子系统是有一定的困难的。
    我理解HL7规定的是不同系统间数据交换时的表达格式。它像一个庞大的展示柜，医疗系统的各个细节都被分别定义在固定的位置，而且规定了摆放方式。这个方式在低版本是文本格式，新版本是xml格式。
    在各自的HIS系统里，数据是如何被加工和储存的，使用何种格式，HL7并不关心。但只要进行系统间数据交换，就必须按HL7定义的固定位置，用规定的格式（文本格式或xml格式）表达出来。这就是HL7标准的本质。
    目前HIS系统大多基于数据库系统，用XML文档来存贮标准编码显然不方便，尤其是标准编码过于庞大时。不过如果整个HIS系统是基于XML（XSLT、XPath）的，用XML文档来存贮标准编码应该是合适的。这方面我不太清楚。
    实际上HL7并不规定实际的HIS系统是如何表达的。比如，HL7的2.3版的表达格式是文本，你的HIS系统并不需要用文本储存。无论你的系统用文本，用oracle，用foxpro，还是用Caché ，都不影响你用HL7进行数据交换。
随便乱说，请大家批评。

ironstone

两位的讨论都很深入，这几天因为出差去了，所以没有赶上和几位讨论。我基本上是同意tianma对HL7的理解。
但最后的观点还是不太同意。
“至于医院，作为医疗软件的应用者，只要了解hl7的基本知识就行了。除非他想自己做系统。”
我认为作为用户不仅要了解HL7的基本知识，还要深入了解HL7的实现和应用。虽然不用去了解具体在功能和编码上的事情。但深入了解这些可以避免受到产商的误导。
尤其是因为HIS已经是现有市场的既得利益者的时候。虽然市场竞争的结果是不思进取的公司会被淘汰，但是具体到某个公司某个个体来说，通常都只会考虑目前的利益。因此正如你所说：HIS产商是真正的应用者，但不是积极推动者。因此，他不会主动和医院去说可以进行系统的整合，可以利用HL7进行整合。
那么谁是最积极的推动者？一定是医院和新系统的开发商。而医院作为需求提出和验证方如果只是简单的提出说要实现系统之间的数据交换，这里可以有很多的技术和方案去实现这个目的。作为产商一定会选择对自己来说成本最低，最简单的方法，比如数据库同步的方法，或者就拖着，让医院选择自己的系统来扩大自己的利益。
同时因为HL7的开放性，会导致诸如tianma所说的那些问题。比如HL7没有规定应该采用什么通讯协议，只是遵循OSI，而OSI中可以包含很多协议。因此一个系统如果只支持UDP协议，但他也可以宣称支持HL7，而另一个系统也许是通过TCP/Ip来实现。这两个系统通讯的时候，必然会发生问题。
因此这些问题的出现，如果医院可以在进行招标的时候，明确的提出需求要求或者委托第三方提出需求要求，比如在两个系统中，进行通讯的时候，规定必须支持什么协议，采用什么方式进行数据交换的通讯，要达到什么样的目标，必须使用那些消息，那个消息应该在什么情况下被触发。必须要详细到这种情况下，才可能真正的实现到两个系统被整合。
而如果只是简单的提出需求，比如说Pacs和his，只能达到提出说：要实现pacs能够直接获取his中的病人基础数据等这样的需求，那么厂商可以同样使用dicom网关来实现，而且不用去定义什么消息，直接数据库对应就可以实现，只要达到数据同步就可以了。而要详细的话应该规定，必须采用HL7语法，当一个病人入院的时候，HIS必须发出ADT_A01传递病人基本信息，规定当HIS由影像医嘱的时候，必须通过什么方式发送SRM_S01给RIS系统进行预约，而ris必须回应srr。如果到这个程度了，我想这个医院的系统应该可以运行很流畅了。当然不能要求所有医院都有这样的人才，所以应该有第三方的HL7厂商提供咨询服务。

ironstone

此外关于xml的应用的问题，这里面有一个适应性的问题，应当视数据的复杂性来决定，如果数据类型较为简单，不应该滥用xml

tianma

[这个贴子最后由tianma在 2002/12/25 02:25pm 编辑]

ironstone言之有理。
    在选择医疗系统时，如何提出系统需求是一个非常重要的问题，也是一个比较困难的事。
    首先，由于采用招标方式，医院和厂商之间缺乏技术上的交流和沟通。而对医院来说，做一个准确详细的系统需求几乎是无法做到的，特别是初次做系统时，可能都不知道自己要做什么！即使是已使用医疗系统、对系统有一定研究的，大概也很少能做出ironstone所列举要求的系统需求分析。
    其次，在招标完成前，厂商也不会或不可能和你讨论这些技术细节。尽管他们的方案精美厚实，但实际内容并不多，在技术细节上更很少涉及。对于厂商谈判人员，尽管可能也是技术人员，但并不实际开发，所以他无法详细说明这些具体技术问题。不过，你的要求他都能答应，也会写入方案，只要能拿下单子就行。至于如何实现，那是开发部的事，和他没有关系。
    实际上，厂商对某一行业的应用，大多数都有固定的核心程序，拿下单子后，根据具体要求做一些修改 -- 他们称为本地化工作。如果不对核心程序作重要修改，系统很快能交付，运行也会很顺利；如果核心程序难以适应要求的修改，问题就大了，开发部通常只能采用变通的方法，除非万不得已，不会对核心程序作重要修改。而且，修改核心程序后，你得到的就不再是成熟的系统了。
    因此，选择医疗系统时，要着重了解演示和应用实例。如果有系统整合的要求，首先要看现有系统能否实现、效果如何。如果还没做到，那么它很难实现承偌。厂家的宣传是不足信的。你看，已有厂家称实现HL7应用了，可中国本地化的HL7的标准还没出来呢。难道它做的是英文系统？今后如何与别人整合？
    另外一个问题，是我们的系统需求要达到什么程度？目前系统需求大多非常简单，达不到基本要求。但如果做得过于详细，甚至包括系统分析部分内容，我认为也不妥。毕竟我们不能进行全面的系统分析，如果仅就某一具体的技术细节提出了要求，万一出现问题，厂商会理直气壮地指出是你提出的要求造成的，当然还能举出理由，使你有口难辨。尽管他当时也没考虑到。
    也可能自己的要求不完全合理或缺乏全面考虑。这点我是有过教训的。到后来才发现所坚持的做法，虽然合理方便，但影响效率。结果还得按厂商的要求改。
    我以为对其设计方案，采取提出问题，让对方解决的方法，要比自己提出办法要好。自己比较主动。
    实际上，到讨论设计方案阶段时，招标已结束，厂商也定下来了。这时才能讨论技术细节。
    当然，深入了解HL7和其他相关技术，能够更深刻的发现和提出问题。不过对一般医院的技术人员来说，可能还做不到这点。如果对HL7等了解不深，说不定反而会坏事。
    我赞成ironstone的想法，系统的选择和招标时，可以考虑由第三方的专业机构进行评估和咨询。
    关于系统整合，ironstone提的问题很重要。HL7和pacs等是应用层标准，当然要执行。但只有这些还不够，还有其他层的标准和协议，在系统整合时，不能仅考虑应用层的标准。

笑笑

“同一软件内部完全可以直接交换，为什么还要画蛇添足地也搞转换呢？”
现在不是提倡用松接口吗？如果直接交换是否存在一个系统稍微改动也会影响到另外的系统的问题呢？直接交换应该也只是权宜之计吧？望指教

tianma

内部转换和采用hl7转换的差别是很大的。
在系统内部调用时，对象的属性和方法都是已知的。系统可自动进行转换。
例如：门诊部要查ID号为001的病员是否住院，只要调用相应的函数来完成。
如 aa=fabc(ID号)
这里fabc（）可能是由住院处理程序提供的，ID号也在住院处理程序内有不同的定义。调用程序和被调用程序均是相对独立的。其中，ID号在运行中已经进行了程序之间的内部转换。
由于是在统一个系统内，函数的方法，ID号的涵义、数据类型、长度等属性都是明确而一致的，所以相关数据可以由系统直接转换成住院处理程序内所定义的变量，并进行处理。
但是，如果来自另外的系统，如医疗保险信息系统要做同样的查询，就无法使用上面的方式了。因为系统相互独立，一个系统需要知道另一系统发来的请求的确切含义：
要做什么？传入和传出那些变量？这些变量的涵义、类型、长度、单位是什么？
这就是所谓的交换协议。不同系统之间所用的“数据接口”，其主要部分就是这个协议。
交换协议可以是双方约定的，如目前的HIS和医保系统之间的接口。特点是直接在底层定义了要交换的对象，包括其属性和方法。就好象是中国人要和英国人交谈，要请一个英语翻译；和俄国人交谈，要请一个俄语翻译。其优点是运行效率高，缺点：1和双方的系统密切相关，一旦发生变动，将影响到两边的系统；2是多个系统交换就需要分别定义交换协议。
比较理想的方法是使用与底层无关的，应用层标准交换协议--HL7交换协议。在这里，交换信息统一采用固定的文本格式(包括xml格式)。同时定义了一套应用层面的属性。这些属性是对现实事件的描述，而不是编程时所用的具体的、实际处理时所用的属性。
如数据类型的定义，它并不是整型、实型这些底层属性，而是ID号、姓名、性别、地址这些实际的应用层属性。这意味着：HL7协议与计算机实际处理所用属性无关。双方可以根据这个协议自由定义计算机系统的底层属性。也就是说，不同系统只要使用HL7协议就可以相互交换数据，而不用搞专用接口了。就好像开国际会议，各人都不使用自己的语音和语法，统一用抽象的“世界语”发言，就可以不用大量的翻译了。
虽然HL7有效地解决了系统间的交换问题。但是应该看到，它的工作效率是很低的。
比如上面所举的住院查询事件，如果用HL7来解决，查询方首先要进行HL7格式转换,将各种各样的标识符、参数、参数属性组成一个或多个长长的字符串，发送到对方；
被查询方也要进行HL7格式转换,解析这个字符串，理解查询方的要求，并将参数转换为本系统所定义的数据类型，才能执行住院查询任务。最后，将结果再次转换成长长的字符串，返回对方；
查询方同样要对这个字符串解析，将结果转换为实际数据类型，才能知道查询结果。
经常会出现这样的情景：在一个任务处理过程中，实际操作只占任务的极小部分，大部分时间是在进行HL7转换。
尽管如此，跨系统交换时，首先考虑的是接口统一问题。HL7自然是最佳选择。
理论上，HL7协议也可以用于系统内部。但是，由于内部的交换是大量的、实时进行的，HL7的效率无法满足要求。更重要的是，同一个系统在系统设计时，对象的属性是必然是经过统一规划的，在系统内应该已知的属性，完全不需要转换到应用层协议然后再转回来这一过程（异系统间转换是无奈的选择）。至于内部子系统之间的独立性问题，也不能靠HL7协议解决。应采用面向对象技术，甚至可用过程和函数调用的方法来解决。
一管之见，请大家指正。

sbf2000

好久没有参与这样的讨论了，看了上面 tianma 的发言，看得出来了，他对HL7的应用已有非常明确的理解了，观点也十分正确，思路也非常清楚，对大家应该有很大启发和引导。
HL7在系统内部运用方面，我有一个观点想补充，或者是一个设想，那就是有没有可能利用HL7　V3的定义，构建一个HL7框架（HL7　Framework），用于构建系统内部的不同子系统的实现基础。我想这符合软件的面向对象、组件编程的发展趋势，可以实现不同软件开发商的产品有最大的交互能力。从而改变现在HIS系统的开发模式，从原来的一个软件公司要实现HIS的所有功能到每一个软件公司只实现HIS的某一功能，最终由医院的开发人员跟据需要完成的系统搭建和集成。这样，既实现了软件公司产品商品化的目的，又能实现医院HIS的定制要求，可谓两全其美。
希望大家进一步讨论。

ironstone

是的，tianma说的很对，其实HL7在单一的环境中，或者两两交换的环境中，并没有优势可言，其优势实在面对多对多的有一定不确定性的环境中才在维护技术和成本方面显示优势，而在技术上和效率上并不具有优势。
SBF2000说的，我理解是不是应该是HL7 v3方法学的具体应用，应该和IHE有点类似。IHE定义了最近一直在看一些IHE的资料，IHE通过事务和角色来描述基本的信息交换模块，这也是HL7 RIM中正在借鉴的方法。我翻译了一篇相关的文章，不过是介绍性的，并不深入PACS and IHE Help Solve EMR Implementation 下周一会给大家贴出来吧。

ironstone

已经翻译完了,希望大家看看,发表一下意见
http://bbs.miforum.net/cgi-bin/topic.cgi?forum=14&topic=162&show=0

tq

好文章呀！刚来这里，气氛很好！