医学信息标准化与标准

§4.4　医学信息标准化与HL7标准

全世界医学界信息处理技术得到飞速发展，医院信息系统也跃上了一个新的台阶，医学信息标准化的问题越来越成为制约信息产业飞速发展的瓶颈，没有信息标准化，任何软件产品的大范围推广都有困难，不同部门间的信息交换也只是梦想。

世界发达国家多年来进行医学信息标准化的工作，取得了令人瞩目的成绩。有许多标准已经被广泛承认与应用，值得我们借鉴，我国医院信息标准化的工作尽管起步晚、进步慢，但也取得了一些成绩。

一、医学信息标准化

1．信息标准化的定义

信息标准化狭义上是指信息表达上的标准化，实质上就是在一定范围内人们能共同使用的对某类、某些或者某个客体抽象的描述与表达；广义上的信息标准化不仅涉及信息元素的表达，而且涉及整个信息处理：包括信息传递与通信、数据流程、信息处理的技术与方法以及信息处理设备等方面。信息标准化具有以下特点：

（1）完整性与唯一性：无论一个还是一组客体，在标准化代码中都应该有且仅有一个确定的代码与其对应。

（2）科学性：人们对某一个客体的分类编码的完成往往依赖于对该客体的本质的认识，是人类长期观察、研究、实践、活动的总结。

（3）权威性：信息标准化工作往往是由具有　行政管理权威的部门制定(或者委托专业技术部门)和颁布的，在一定的范围内是强制执行。

（4）实用性：标准的制定要掌握好科学与应用的关系；要调整好该标准可能存在的不同户之间的矛盾；要合理照顾现实环境与远景发展的需求。

（5）可扩展性与可维护性：标准建立之后并不是一成不变的。相反它需要随着客观情况的变化而补充、修改，否则该标准就会因落后而无法使用。

医院信息标准化，是指统一名称、统一概念、统一分类、统一编码，它是信息迅速交流的基础。HIS的开发特别是通用系统的难点就是标准不统一，如疾病、药品、人员、器材、财务、检验等。因此对医院信息进行科学的分类与编码是计算机信息处理系统能有效发挥作用的前提和基础。信息代码分类标准原则上要求尽量采用国际标准、国内标准、颁布标准、全市统一标准。如物资设备编码在卫生部颁发标准的基础上应用到HIS中；疾病编码由国内统一ICD码制定；药品编码采用国家药品管理局、卫生部、解放军卫生部组织有关单位共同完成。

HIS的标准化包括数据字典的标准化和接口的标准化两部分。

首先是要求统一HIS数据字典的内部编码，尤其是医保部门对此要求十分强烈，从原则上看，字典应该标准化。但在实际使用中，根本无法实现100％的标准化。例如药品编码，政府不可能24小时实时维护统一的药品编码，医院新药使用前只能使用自定义扩充码，一旦国家公布了标准编码，该自定义码也不能修改，否则数据库中数据将发生混乱。因此，卫生部新颁布的《医院信息系统基本功能规范》中规定：为确保数据规范，信息分类编码应符合我国法律、法规、规章及有关规定，对已有的国标、行业标准及部标的数据字典，应采用相应的有关标准。使用允许用户扩充的标准，应严格按照该标准的编码原则扩充。在标准出台后应立即改用标准编码，如果技术限制导致已经使用的系统不能更换字典，必须建立自定义字典与标准编码字典的对照表，并开发相应的检索和数据转换程序。

其次，是对HL7的实现。HL7一般有两大类实现方法：通常采用点对点通信的方法实现不同系统对接，另外还可以采用HL7服务器（HL7 Server）的方法实现。HL7 Server实际是应用服务器，提供HL7接口和数据存储能力，形成基于HL7的中心数据库。在需要互联的系统数量较多的时候，这种方式可以简化接口数量，提高系统的可靠性；缺点是增加系统建设费用。

二、HL7标准简介

随着国内医疗体制改革的加快，医疗界国际交流日益加强，信息交换显得尤其重要。在现有的HIS系统中，各医院采用不同开发商的系统，硬件环境也不尽相同，这种异质系统平台和非标准信息格式阻碍了各系统（医院与医院，医院与上级部门，医院与保险公司）之间的信息交流，更不用说国际上的交流。

HL7是满足这种需要的信息高速公路。HL7的使命是为了达成临床上跨平台的应用，主要目的是发展各类医疗信息系统间，如临床、银行、保险、管理、行政及检验等各项电子资料的标准。它支援医疗服务如临床病患护理、管理，提供信息交换，管理和整合的标准，让各类医疗信息系统间的交互变得简单畅通。

HL7经过十几年的发展，已经成为国际标准和发展趋势，HL7使医疗提供机构信息系统自动化、标准化，是继续发展和有效竞争的关键所在。

1．HL7标准简介

HL7由Health Level Seven，Inc.（美国）制定和维护，用于在不同的医疗系统之间进行医疗数据传递的标准。“Level Seven”是指ISO（International Standards Organization）组织发布的OSI（communications model for Open Systems Interconnection）模型的最高层，如图4.3所示。该标准于1987年产生，最新版本为2003年6月发布2.5版本，正在制定以XML方式表达的V3.0版本。

图4.3　HL7的工作模型

HL7组织（Health Level Seven，Inc.）成立于1987年，是非盈利性组织，从事卫生保健环境临床和管理电子数据交换的标准开发。在2 200多个会员中，超过500个团体会员，包括了医疗方面90％的信息系统供应商。目前HL7组织在全球有近20个成员国，除美国外，还有阿根廷、澳大利亚、加拿大、中国、捷克斯洛伐克、芬兰、德国、印度、日本、韩国、立陶宛、荷兰、新西兰、南非、瑞士、土耳其和英国。

1994年，HL7获得ANSI（American National Standards Institute ，美国国家标准学会）授权认可，成为美国医疗方面的标准化组织之一。HL7组织目前（截至2002年12月为止）设立了21个技术委员会（Technical Committees），15个特殊兴趣委员会（Special Interest Groups，SIGs）。

HL7标准的发展过程可通过图4.4得到初步的了解。

网上有很多HL7相关资料，下面给出了一些网址：

（1）http://www.hl7.org/　　HL7官方网站。

（2）http://www.kestral.com.au/hl7v3/　澳大利亚HL7组织。

图4.4　HL7标准的发展历史

（3）http://teufel.informatik.med.uni-giessen.de/hl7xml/　　提供了一个免费将HL7v2.4转换成XML的引擎。

（4）http://www.oemig.de/　　　对HL7感兴趣的个人站点。

（5）http://www.drpacific.com/　太平洋医信公司，国内介绍HL7较多的公司，可提供HL7培训。

2．HL7的实际应用功能

（1）数据交换功能

HL7是应用层，位于网络第7层。从本质上来看，它属于数据交换的协议。但由于它是应用层协议，它和实际应用关系非常密切。如各种事件和消息格式的定义就是直接作用于医疗过程。作为在成熟的医疗体系下建立的标准，它的许多内容，特别是许多定义和编码对设计医疗系统很有帮助和启发，但它不能用来规范医疗系统。HL7好像是交通规则，通过它可以了解高速公路的设施和管理，但不能按照它设计高速公路，因为他没有也不可能有平整度、高差和施工规范的规定。另外，交通规则涉及到所有交通设施，如立交桥高架桥等，在实际建路时则不一定都要建设。设计医疗系统也是这样。

数据交换除了数据传递外，还包括了事件和消息的交互。不同的部门，甚至不同的机构之间，它们彼此完全独立，系统结构的定义可能完全不同，比如，医院用Caché(由美国InterSystems公司发布，是一个用于高性能事务应用的后关系型数据库管理系统)，而社保用Oracle；医院用数字型定义一个字段，而社保用字符型定义同一个字段，其名称也不同。因此，医院和社保之间无法直接读取，更不用说交互操作了。只好各自作各种各样接口，有时根本就无法连接。有了HL7这个应用层协议，事情就好办了。通过HL7服务器，各医院之间、医院和社保之间可以像调用函数处理自己的系统一样，调用甚至进行处理操作（在权限内），而不需要考虑对方在一个什么系统里，如何实际执行具体的操作的。

（2）医疗系统之间的整合

HL7定义了很多事件、消息，使用HL7可以使得医院系统之间的效率和管理状况可以得到实时的沟通。曾有国内专家认为，HL7协议医院完全没有必要去了解，就如同TCP/IP协议一样，医院不了解，也在使用。然而并非如此。TCP/IP协议是应用于医学方面的技术协议，是底层协议，而HL7则完全是医疗方面的应用协议，两个出发点和落脚点是不一样的。在建设HIS系统时，医院必须要有很熟悉HL7的人，或者委托很熟悉的人，才能够应用的更加顺利。

（3）作为HIS的系统分析参考

HL7是基于比较成熟先进的医疗体系而建立的标准。如果都采用了这样的标准来规范临床医学和管理信息格式，则HIS系统的通用性和交互能力就越强，以后医院信息系统之间的互连成本就会降低，也说明HIS系统的长远发展越好。

在美国及越来越多的欧洲国家，HL7被用作医疗系统中文字及数字信息的标准接口。而HL7在国内的应用还未见报道，这是因为囊括医院各管理模块的综合型HIS产品还是市场的主流。但是，随着医院信息系统由管理为中心向以病人为中心的临床信息系统（CIS）转变，随着专业化细分的发展，以HL7标准实现系统互联将成为必然趋势。

3．HL7的主要内容

HL7 2.4版本是2000年的版本。包括15个章节，4个附录，共1400多页。它的主要内容如下：

CH01 Introduction　　HL7概述介绍

CH02 Control　　消息定义及交换协议控制

CH03 Patient Administration　　病人管理

CH04 Order Entry　　医嘱

CH05 Query　　查询

CH06 Financial Management　　财务管理

CH07 Observation Reporting　　观察报告

CH08 Master Files　　主文件

CH09 Medical Records/Information Management (Document Management)　　　医疗纪录/信息管理（文档管理）

CH10 Scheduling　　计划

CH11 Patient Referral　　病人转诊

CH12 Patient Care　　病人照护

CH13 Clinical Laboratory Automation　　临床试验室自动化

CH14 Application Management　 应用程序管理

CH15 Personnel Management　　个人管理

AppendixA Data Definition Tables　　数据定义表

AppendixB Lower Layer Protocols　　底层协议

AppendixC Version 2.4 BNF Message Descriptions　　2.4BNF

消息描述

AppendixD Glossary　　术语表

4．HL7的几个基本概念

触发事件（trigger events）：当现实世界中发生的事件产生系统间数据流动的需求，则称其为触发事件。如：病人的入、出、转院（ADT）在HL7中对应ADT事件。

消息（message）：是系统间数据传输的最小单位，由一组有规定次序的段组成。每个消息都用一个消息类型来表示其用途。HL7共归纳了84种消息类型。每个事件对应一个消息，如病人入院对应ADT_A01消息。HL7采用消息传递方式实现不同模块之间的互联。

段（segments）：是数据字段的一个逻辑组合。HL7共有110个消息段，每个段都用一个唯一的三字符代码所标识，这个代码称作段标识。用于界定其内容或功能，如message header(MSH)，event type(EVN)，patient ID(PID)。消息段分为必需、可选和可重复三种类型。

字段（fields）：是一个字符串。是段的最小组成单位。字段需定义其位置、长度、数据类型、选择类型和重复性等。

表（Table）：表可分为HL7标准表和用户自定义表两种。其中HL7标准表为HL7规定必须使用的表，标准表有118个；用户自定义表为HL7推荐使用的表，共有185个。

下面是一个HL7消息示例：

5．Admit/visit notification-event A01 (admitted patient)

MSH|^～\＆|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.4|〈cr〉***消息头段

EVN|A01|198808181123||〈cr〉　　　****消息事件段

PID|1||PATID1234^5^M11^ADT1^MR^MCM～123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M||C|1200 N ELM STREET^^GREENSBORO^NC^27401?1020|GL|(919) 379?1212|(919)271？3434||S||PATID12345001^2^M10 ^ADT1^AN^A|123456789|987654^NC|〈cr〉　　　****病人标识段

NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN〈cr〉　　　****相关

PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|〈cr〉　　　****病人就诊段

这段消息表示如下含义：病人William A. Jones III 于1988年8月18号上午11时23分由外科医生J. Lebauer (#004777)收治入院，他被分配到2012病房01号床位2000号护理单元。这条信息于同一天病人入院后三分钟由MCM的ADT1系统送往MCM的LABADT系统。

6．HL7引擎

为了支持实现HL7，一些公司开发了HL7引擎，通常是一组支持HL7通信的过程调用函数或控件，应用程序按照HL7引擎的约定提供参数，模块之间的通信则由HL7引擎完成。典型的HL7通信是一种点对点方式，如图4.5所示。近年来，为了解决系统的复杂度问题，HL7服务器解决方案呈现增长趋势。HL7服务器作为系统集成的中心节点（如图4.6所示），与多个子系统互联，可以大大简化多个系统互联的接口数量。但是，HL7服务器本身的复杂度决定了这种方式只有在十分复杂、异构模块众多的情况下才适于使用。

图4.5　点对点互联

图4.6　服务器解决方案