数据传输与集成标准

（一）医疗健康信息传输与交换标准（HL7）

1．概述 医疗健康信息传输与交换标准，简称HL7（health level seven），属于数据通信和信息共享标准类型。HL7组织成立于1987年，是一个非赢利的标准开发组织，其标准主要用于与卫生保健计算机系统有关的临床、银行、保险、管理、行政及检验等信息的交换。HL7通信协议（protocol）汇集了不同厂商用来设计应用软件之间接口的标准格式，它允许各个医疗机构不同的系统之间，进行一些重要资料的通信。通信协议的设计同时保留相当的弹性，使得一些特定需求资料的处理维持相容性。

HL7组织参考了国际标准组织（international standards organizations，ISO），采用开放式系统互联（open system interconnection，OSI）的通信模式，将HL7纳入最高的一层，也就是应用层。它的规范提供了如关联性的分类、有效检查的产生、结构性交换资料的机制与协商等功能。

在OSI的概念性模型中，通信软件和硬件的功能被划分成7层。HL7标准主要是针对第7层，即应用层上的问题。这些问题包括交换数据的定义、交换的时间控制以及在应用之间某种特定应用错误的传递。而在必要的时候，也会提及有关OSI模型较低层的协议，以帮助使用者理解标准的来龙去脉。

HL7V 2.4版已经于2000年12月6日被批准为ANSI的标准。HL7V 2.X版标准的发展过程可通过图4-5得到初步的了解。

图4-5 HL7V 2.X标准发展示意

2．HL7 V3.0标准 在2.X版本获得广泛应用之后，从2000年开始，HL7标准组织开始了HL7标准3.0版本的讨论、制定和编撰工作，3.0版本是一套与2.X版本不同且并行发展的新的标准体，目前仍处于发展和完善过程中。

HL7标准3.0版本采用了类似DICOM标准的面向对象的发展方式，并最大限度地减少了标准定义和规范内容的可选项成分，其基本目标是建立一套定义明确和执行机制可验证的标准体系，并提供对医学信息系统提供商产品的标准遵从能力的确认方式。相对于2.X版本序列，HL7标准3.0版本提供了几点关键的改善机制：

（1）采用参考信息模型（reference information model，RIM）的消息产生机制：RIM定义了大量的应用于产生HL7消息（messages）的类（class）属性，以及对这些对象类关系的定义和规范。由于RIM的数据模型严格地限制了不明确性和可变性，这被作为HL7标准3.0版本应用的关键特征。

（2）支持XML（extensible markup language）以加强和改善医学系统间的互操作能力：HL7标准3.0版本发展了一套XML兼容的临床文档体系规范，即病案体系架构（patient record architecture，PRA），作为医疗文档的交换模型。应用PRA，可以将HL7消息内容嵌入XML，再经XML内容产生消息，并与其他XML兼容的医学系统间交换、处理消息和文档。

（3）应用交互模型（interaction model，IM）获取信息流和定义软件应用角色：IM包括了每一个医学软件应用所需要的触发事件、消息格式和数据元定义，可以用于产生可测试的标准，拟确认和验证系统的标准遵从性。

HL7建模和方法学委员会为HL7 V3.0版的制定规定了一整套以统一建模语言（UML）为代表的信息模型的建模方法。图4-6简要给出了建立消息的方法与步骤。第一步是通过对现实世界的业务流程分析获得Use Case模型，第2步是建立参考信息模型，第3步是建立类之间关系的信息交互模型，第4步是进行消息设计获得等级消息描述，最后是消息交换实现技术的说明。

图4-6 HL7 V3.0的消息开发方法框架

3．HL7标准的内容 HL7标准的内容主要包括如下。

（1）一般查询接口在内的所有接口的总体结构。

（2）患者管理（入院、出院、转院和登记注册）。

（3）医嘱录入。

（4）患者账户（账单）系统。

（5）作为可识别的数据元素来传送的临床数据观察，比如实验室结果。

（6）与普通参考文件（主文件）同步的通用接口。

（7）医疗信息管理。

（8）患者和资源安排。

（9）两个医疗机构之间患者转诊的消息。

（10）支持问题导向病历交流的患者医疗信息，为在计算机信息系统中应用临床路径提供解决方案。

（11）患者护理。

（12）临床实验室自动化。

（13）应用管理。

（14）人事管理。

（15）财务管理。

HL7采用消息传递方式实现不同软件模块之间的互连。不同格式的应用程序数据，首先按照HL7标准的语法规则，转换成各个系统都可以识别的标准数据格式——HL7标准的规则消息（目前多采用XML文档格式）；然后按照一定的网络传输协议，通过符合FTP/TCP/IP等协议的数据表或以E-mail的方式传送到接收方。接收系统应用层在接收到数据表后，回传数据传输的应答消息，并对接收到的数据进行有效性验证；消息通过有效性验证后送到应用程序，再按照HL7标准的规则进行解析，将消息转换为应用程序可以识别的数据，从而完成不同系统之间的数据交换和互通互连。

（二）医学数字成像和通信标准（DICOM）

1．概述 DICOM是Digital Imaging and Communication of Medicine的缩写，是美国放射学会（american college of radiology，ACR）和美国电器制造商协会（national electrical manufacturers association，NEMA）组织制定的专门用于医学图像的存储和传输的标准。经过10多年的发展，该标准已经被医疗设备生产商和医疗界广泛接受，在医疗仪器中得到普及和应用，带有DICOM接口的计算机断层扫描（CT）、磁共振（MRI）、心血管造影和超声成像设备大量出现，在医疗信息系统数字化、网络化中发挥了重要的作用。

DICOM是随着图像化、数字化的医疗设备的普及和医院管理信息系统，特别是PACS和远程医疗系统的发展应运而生的。当CT和MR等设备生成高质量的、形象直观的图像在医疗诊断中广泛使用时，由于不同的生产商不同型号的设备产生的图像各自采用了不同的格式，使得不同的设备之间的信息资源难以互相使用，医院PACS系统的实施具有很大的困难。为此，美国放射学会和美国电器制造商协会在1983年成立了专门委员会，开始制定用于医学图像存储和通信的标准。经过2年开发，1985年发布了ACR-NEMA 1.0版，随后又颁布了2个修改版本，1988年颁布了ACR-NEMA 2.0版，由于技术上不成熟，这些规范并没有被广泛采用。但是这些努力吸引了国际上许多著名的医学影像设备制造商的关注及参与。1993年，在ACR-NEMA 2.0标准的基础上，增加了通讯方面的规范，同时按照影像学检查信息流特点的E-R模型，重新修改了图像格式中部分信息的定义，制定了DICOM 3.0标准。DICOM标准的制订与完善，提供与制造商无关的数字图像及其相关的通信和存储功能的统一格式，实现了医学影像信息的交换，推动了远程放射学系统、促进了PACS的研究与发展。由于DICOM的开放性与互联性，使得PACS与其他医学信息系统（HIS、RIS等）的集成成为可能。目前这个标准已经被世界上主要的医学影像设备生产厂商接受，已经成为事实上的工业标准。

2．DICOM标准的组成 DICOM3.0标准是由多文档组成，截至2004年，共分为以下18个部分。

第1部分：引言和概述（introduction and overview）。简要介绍了DICOM标准的产生及其组成，并对其他部分的内容作了简介。

第2部分：兼容性（conformance）。详细说明了DICOM的兼容概念，同时给出了在开放互联方面对遵守该协议的设备必须实现的基本DICOM规定，包括选择的信息对象、服务类以及消息传递等。

第3部分：信息对象定义（information object definitions）。规定了使用DICOM标准进行通讯时信息对象的定义，包括普通信息对象和复合信息对象。

第4部分：服务类规范（service class specification）。对一些类的服务类进行了定义，给出了用于数字化交流的操作行为的抽象定义，即定义使用DICOM进行通讯的服务类别。

第5部分：数据结构和编码规定（data structure and encoding）。定义了信息对象类和服务类的数据结构和编码。

第6部分：数据字典（data dictionary）。包括对所有DICOM数据元素以及它们对应的标识符、值类型、数据类型和使用要求。

第7部分：信息交换（message exchange）。定义了DICOM命令的结构（命令结合相关数据），同时也定义了DICOM应用实体间的协议握手方式。

第8部分：信息交换的网络通讯支持（network communication support for message exchange）。说明在网络中DICOM如何使用TCP/IP和OSI网络传输协议。

第9部分：信息交换的点对点通讯支持（point-to-point communication support for essage exchange）。说明点对点传输支持应用DICOM协议进行数据交换和服务器与网络上层协议。

第10部分：介质存储文件格式（media storage and file format for data interchange）。提供了一个用于不同类型医学影像之间数据交换及不同物理介质相关信息交换的框架。

第11部分：介质存储应用框架（media storage application profiles）。说明将医学影像信息存储于可移动介质的模式。

第12部分：数据交换用存储方案和介质格式（storage function and media formats for data interchange）。描述了如何便利医疗环境中数字影像计算机间的内部信息交换。

第13部分：打印管理的点对点通讯支持（print management point-to-point communication）。详细说明打印提供者在点对点联接情况下支持DICOM打印管理所必需的服务和协议。

第14部分：灰度图像显示函数（grayscale standard display function）。详细说明了灰度图像的标准显示调整，它提供了一些样例方法，说明如何调整灰度图像与显示系统。

第15部分：安全性和系统管理概述（security and system management profiles）。说明了具体应用所应遵循安全策略的兼容方式。

第16部分：映射资源目录（content mapping resource）。

第17部分：信息解释（explanatory information）。

第18部分：Web获取DICOM永久对象（Web access to DICOM persistent objects，WADO）。

DICOM这几部分文档既相互独立，又相互联系，规定了患者（patient）、研究（study）、序列（series）、图像（image）4个层次的医学图像信息结构，以及由它们组成的信息对象（information object）、采用服务类用户/服务类提供者（Service Class User/Service Class Provider）概念组成的服务/对象对（service/object pair）、支持点对点（PPP）和TCP/IP网络通讯协议。

3．DICOM信息模型 DICOM标准为了解决在不同的地点、不同设备制造商、不同国家等复杂的网络环境下的医学影像存储和传输的问题而制定了自己的语义和语法。语义是指交换信息的具体含义。DICOM用一对整数表示，称为标记（Tag），用数据字典给出详细的定义和解释。另外用UID的方法给出惟一标志。语法则是指信息组成的规则。在DICOM中，数据种类相当多，被分成各个层次，有信息对象定义（IOD）、消息（Message）、命令集、数据集、数据元素、传输语法等。只有通信双方按约定的统一的方法组织数据，才可能准确获得对方传输的信息。

DICOM图像信息模型是从放射科处理图像的方式中衍生出来的，它是基于来自不同形态方式上的假设。图像从多种形态上被收集到患者的病历中。患者病历中的图像是以检查的类型（与图像系列有一定的关系）排序。每一种形态类型的用户对这些排序都有自己的术语，如检查、运行、扫描、切片等。当不同来源的图像数据集合到一个单一的环境中，必须将不同来源的图像数据排序，这仅在所有图像数据依照同一个信息模型构造时才有可能。

DICOM信息模型主要有4个层次，分别是患者（patient）、研究（study）、序列（series）和图像（image）层次。这4个层次分别对应了相关类型的信息的生成阶段和不同来源。在PACS中图像的归档和显示都应遵循这个结构层次。

（1）患者层次：患者IOD封装了该患者相关的人口学信息，1个患者可以有多次研究。

（2）研究层次：研究层次是信息模型中最重要的层次。一个研究是某个特定类型检查请求的结果。在1个放射科中所有活动都围绕着研究的正确处理。在研究层次上，保持着标识信息，并可以包含有与该研究有关的医院管理信息系统中的信息引用。

（3）序列层次：在研究层次下收集了所有的图像序列。序列层次标识了生成图像的形态类型、序列生成的日期、检查类型的细节和使用的设备。序列是来自某一设备类型有关图像的集合。图像组合到序列中的方式取决于它们的临床用途。而图像在形态上是如何获取对分组并不重要。但是不同的属性将获取标识，并在显示图像时表现出来。

（4）图像层次：信息模型的最低层次是图像层次，每个图像包含获取和位置以及图像数据本身。这取决于方法的类型。图像层次包含有1幅（单幅）、2幅（双屏）或某些设备采集的运动图像（多帧图像）。

4．DICOM网络的层次模型 DICOM标准要实现医学影像可靠高效地传送到期望的目的计算机中，就要在成熟的标准化的网络环境基础上增加对医学影像的支持，而不是从最低层开始定义，这样就可以直接利用现有的网络硬件和软件资源，促进DICOM标准的开发和应用。

在DICOM标准的制定中，主要采用了在实际中广泛使用的TCP/IP协议和影响较大的OSI网络协议，作为对DICOM网络支持的基础。在这2个协议之上分别定义了DICOM自己的基于消息的信息交换的上层协议DIMSE（dicom message service element）。为保持与以前版本的兼容，仍保留了点对点打印的支持。

应用程序与DICOM应用实体之间的应用程序接口（API）并不是在DICOM标准中说明，而决定于实现。一般这个API提供了对其他应用的连接，构造和处理SOP实例并传送到远方应用等这类函数。

对应用层，对应用实体提供了两组服务：联系控制协议（ACSE）和DICOM消息协议（DIMSE），它们都必须对DICOM实现有效。ACSE是一个标准的OSI协议。DIMSE的DICOM服务，是应用实体中提供的服务的一部分。

在DICOM 3.0版本中，点对点环境是为保持与以前版本的兼容而保留的。DICOM网络模型如图4-7所示。

图4-7 DICOM网络模型

（三）医疗信息系统集成框架（IHE）

1．IHE基本概念 IHE定义了一个技术框架，该技术框架从系统交互的观点出发，把所有医疗临床过程抽象成一个个医疗集成规范。每个集成规范由一系列角色（actor）和事务（transaction）组成，每一个集成规范都表达了特定的信息管理来响应相应的临床需要。

（1）角色：是某个信息系统或者某信息系统的一个组成部分，它可以产生、管理或处理临床信息或操作信息。因此，对于每一个完整的信息系统来说，该系统可能包括1个或者多个角色。在IHE技术框架中，角色并未被直接指定为特定的产品（如医院信息系统HIS、放射信息系统RIS、医学图像归档和通讯系统PACS或成像设备），而是完全从医疗环境中直接抽象出来的功能组件，具体的信息系统或设备对应哪些角色则由厂商和用户来具体决定。

（2）事务：是指在角色之间通过标准的消息进行相互作用与通讯。通常情形下，一个特定的事务执行过程必定与两个角色相关联。IHE定义的事务，通常对应的是医学信息系统或信息系统组件间按标准定义的信息服务或信息处理机制的执行和实施过程。而且，IHE事务定义更进一步强化了这些标准定义的服务和处理机制在应用方面的特异性，以确保实现系统间更高水平的结合性和互操作性。

（3）集成规范：是IHE技术框架的核心，其定义由相关的IHE角色以及各个角色之间相互作用的一组事务构成。在IHE技术框架中，每一个集成规范都与一个或相互关联的一组特定的医学信息化环境中的集成问题相关联，并基于现行的医学相关标准，如DICOM和HL7的定义与执行机制，建立针对这类集成问题的处理过程和解决方案。

IHE集成规范为医疗机构和医学信息系统提供商之间的沟通和交互提供了一套通用的技术语汇，使医疗机构和医学信息系统提供商都能基于特定的集成规范在一个共通的平台上描述其需求和产品特征。这一点对于作为用户的医院尤其有价值。因为，医院只需要将主要的精力关注于其感兴趣的IHE集成规范及其需求内容，而不必预先熟悉和确认IHE技术框架中定义的具体Actors和Transactions。在医院引进新系统设备、升级原有设备系统或者进行新需求规划设计时，合理地选择和应用相关的IHE集成规范，将有利于评估和确认各种设备和系统与医院信息化建设需求的符合程度，比如在同一个医院信息环境中协同工作的2个信息系统能够支持同一个IHE集成规范，即意味着这个集成规范所包含的相关集成能在这2个信息系统间存在实现的基础。

IHE技术框架的集成规范一般由3方面组成。

内容规范：内容规范描述了对某种特定类型内容对象的创建、存储、管理、获取和使用。

工作流规范：工作流规范描述了对工作流的管理，如提供工作列表、汇报/监控工作项目的进展和完成情况等，在整个流程中所涉及的内容对象的创建在内容规范中规定。

底层构造规范：底层构造模型描述科室共性的问题，如基本安全模型和放射信息访问模型。

2．IHE技术框架 医疗集成模型integration profile（IP）=角色（actor）+事务（transaction）。

（1）IHE集成模型（Integration Profiles）：IHE集成模型定义了为满足特殊医疗需求的所有集成功能，描述了临床信息和工作流程需求，并定义了满足这些需求的角色和事务，如图4-8所示。

（2）IHE角色（actors）：把产生、管理或操作信息的信息系统或应用程序抽象为医疗功能单元，即角色。每个角色支持一套IHE事务，实际的医疗信息系统可能包含一个或多个角色。

（3）IHE事务（transactions）：事务是指角色间的信息交互，该交互基于现有标准（HL7和DICOM）实现。每个事务都定义了所对应的特定标准及细节信息。

3．IHE与DICOM、HL7之间的关系 IHE并不是定义新的集成标准，而是着眼于支持现有的成熟标准（例如DICOM和HL7等），使这些标准相互结合从而满足特定的临床需要。图4-9表示了DICOM、HL7、IHE各自的适用范围和相互关系。DICOM是医学影像信息存储和表达的标准，解决的是格式问题。HL7是信息交换的标准，解决的是不同系统间的信息通信问题。IHE是工作流程的标准，解决的是不同的IT系统间的协同工作问题。

图4-8 IHE集成模型

图4-9 IHE与DICOM、HL7之间的关系

在实际使用中，IHE技术框架在不同的地方分别使用了DICOM或HL7的标准来实现IHE流程。这三者的关系如下。

（1）IHE以现有标准为基础。单一的标准（如DICOM、HL7等）不能解决医疗系统之间的交互问题，IHE的前提条件是承认现有标准并且遵从它们，并在它们的基础上规范数据交互流程，满足一定的临床需求。IHE技术框架根据需要，在不同的地方使用了DICOM或HL7的标准实现IHE流程，总体来说，在PACS、RIS和放射设备互联中主要使用DICOM标准，在与HIS互联中主要使用HL7。但是，在IHE所定义的集成模型中，对于这些标准的使用并没有严格的界限，而是根据实际使用的功能决定，比如IHE的Scheduled Workflow模型，结合了HL7中规定的ADT和医嘱预约，DCIOM中规定的预约、Worklist、状态提醒以及存储协议等功能。

（2）在具体执行的时候，首先考虑到应该满足一定的标准（如DIOM、HL7等），其次才是符合IHE技术框架。由于IHE所定义的各种角色、事务和模型都是基于现行的标准，IHE定位在制定一套规范的流程，并通过DICOM、HL7等消息系统实现这种流程，以实现不同系统的集成。因此，生产商不能一味追求IHE的集成性而去违背现行的各项标准。

（3）从发展过程中来说，在应用IHE的时候，如果发现了现行标准有缺陷，IHE协会应负责将这一问题反馈给标准协会，加以修正。

（4）从今后的发展情况来看，HL7为各个独立的系统和生产商提供了一个通用的界面和数据交流规则，IHE则指导了如何把各个独立的系统相集成、形成一个即插即用型的医疗解决方案。IHE的根本目的是保证所有涉及诊断的患者信息的正确性以及可用性，从系统间相互交互的角度定义了医疗环境中各个组件的功能，从当前的发展情况来看，它是基于HL7和DICOM定义了一系列的组件，有效地规定了各个集成系统间的信息交互问题。就这个方面来说，对于医学信息系统中重要的PACS系统，今后的发展趋势之一是PACS系统将和HL7、IHE相集成。

总之，可以从这个角度理解IHE和各标准之间的联系：不同的HIS/PACS/RIS/LIS等复杂系统的工作流程和用户界面都不同。HL7解决了在这些不同的系统间制定统一的框架并在各个系统间实现数据的正确传递。IHE解决医疗信息系统间缺乏统一的交互过程，通过IHE将这些独立的HIS/PACS/RIS/ LIS集成起来，形成一个即插即用的医疗解决方。IHE最终目的不仅仅是一个可操作的系统，而是一个整体的解决方案、策略。