第三节　HL7 V3 RIM 和CDA R2标准

一、HL7 V3 RIM

为解决HL7 V2消息标准存在的不足，HL7自1996年开始了HL7 Version 3（简称HL7 V3）的设计和开发。2003年7月，HL7颁布了第1版经过美国国家标准局（ANSI）认证的V3标准，截至目前，HL7 V3最新版可以在HL7官方的HL7 Version 3 Product Suite网站［7］获取。HL7 V3标准的基本特点是以模型来构建临床信息及信息交换场景，并由此生成计算机可使用的以XML形式表现的消息和医疗文书，HL7 V3全部标准均来源于基于通用建模语言（Unified Modeling Language，UML）规范的综合医学信息模型，即HL7参照性（医学）信息模型（HL7 Reference Information Model，HL7 RIM［8］）。HL7 RIM目标是覆盖医疗健康领域信息表达和交换的全部需要，其范围不局限于临床信息，也包括行政、财政、公共医疗保健、管理和安全等领域。HL7 RIM是HL7 V3的各类标准的基础和源头。因为HL7 RIM是一个覆盖全部医疗健康领域的信息模型，因此它具有高度的抽象性，它通过6个核心类（back-bone classes）、相应的衍生类，类间的关系，以及与医学代码的耦合绑定，形成了抽象化的RIM模型。RIM模型中的6个核心类分别为：医疗事件（act）、参与方（participation）、实体（entity）、角色（role）、事件关系（actrelationship）、角色关系（rolelink），如彩图8-8所示。RIM模型的6个核心类分别采用不同颜色的背景色，便于识别和阅读。

HL7 ROM采用统一建模语言UML的类图表示，包含类名、属性和属性表示的数据类型（有关数据类型的详细内容请见本书第九章第三节）。彩图8-8中，核心类与子类是泛化（衍生）关系，核心类之间是双向关联关系，核心类之间关联关系的基数表示可以重复出现的次数。例如，0表示不出现；1表示出现1次；*表示可出现任意次；0..1表示可以不出现或出现1次，0..*表示可以不出现或出现任意次；1..*表示可以出现任意次，但至少1次。

1.医疗事件（act）

代表了在医疗卫生管理和服务过程中的已实施的或计划实施的需要记录在医疗文书中的各种医疗活动、事件、处置，和措施等。在医疗健康领域常见的医疗事件子类（又称衍生类）有：临床观察（clinical observation）、健康评估（assessment of health condition）、医疗目标（healthcare goals）、治疗服务（treatment services）（如药物治疗、手术、物理治疗、心理治疗、化疗等）、辅助、监护、护理照料（assisting，monitoring or attending）、对患者或亲人提供培训和教育服务（training and education services to patients and their next of kin）、公证服务（notary services）（如立遗嘱、编辑和维护文件档案）、编辑和维护文件档案（editing and maintaining documents）等。

2.参与方（partici pation）

代表了医疗事件的相关参与方，如对于一台外科手术来说，参与方涉及谁做了手术、手术患者是谁、手术是在哪个手术室完成的等。在医疗健康领域常见的参与方子类（又称衍生类）有：①行为的执行者，如外科医生、做体检的护士、做CT检查的影像科医生等；②行为的对象，如患者、仪器等；③行为实施地点；④负责人、共同签署人、目击证人、病史申诉者；⑤收件人、信息接收者等。

3.实体（entity）

代表了与医疗行为相关的物理存在的人或物（如自然人、医院建筑、医疗仪器、组织等）。实体类有四个子类（又称衍生类），包括：①生命体类（living subject），是指有生命的，如人类、动物、生物；②材料类（material），指无生命的，如容器、床单、药品等；③组织类（organization），代表组织、机构等，如公司和机构、政府部门、保险公司等；④地点类（place），指物理地点，如城市、医院、病房、诊所等。

4.角色（role）

代表了实体在参与到医疗卫生事件中时所扮演的角色，如自然人作为一个实体，在参与到医疗卫生事件中时，角色可能是医生，但在生病的情形下，角色则转换为患者。角色类有四个子类（又称衍生类），包括：①进入类（access），指给身体治疗用药或排出物质（分泌物、尿液）到体外的设备所担当的角色；②雇员类（Employee），雇员所担当的角色；③有资格证的专业实体类（licensed entity），如医务辅助人员的培训文凭等；④患者类（patient），指接受医疗服务的生命体所担当的角色。

5.事件关系（act relationship）

代表了医疗事件之间的关系，例如急性阑尾炎的诊断与阑尾切除术这两个医疗事件之间的关系为因果关系；一次肝功能测试由6个测试项构成：丙氨酸氨基转移酶（ALT）、碱性磷酸酶（ALP）、门冬氨酸氨基转移酶（AST）、胆红素、白蛋白、总蛋白，那么肝功能测试和6个测试之间的事件关系为构成；医生现在不能给患者做手术，患者正在发高烧，在该事件中事件关系定义为先决条件，原行为是不能给患者做手术，目标行为是患者正在发高烧。

6.角色关系（rolelink）

代表了个体角色之间而不是实体之间的关系。如进入类（给身体用药治疗角色——阿莫西林）角色与患者角色之间的依赖关系，当患者角色结束，给身体用药治疗的角色也就随之结束。

图8-9显示了参与方、角色、实体的衍生类。

HL7 RIM版本持续更新，新版本会调整或更新旧版本的局部内容，但整体框架稳定不变。HL7 RIM是一个的高度抽象的信息模型，这决定了基于RIM模型为不同的医学专业领域设计临床信息模型时，需要结合临床专业的特点和需要，对RIM模型进行改进，对其中不符合专业实际的信息和数据关系进行调整，并创建符合专业域业务和信息要求的新的衍生类，经此过程创建域消息信息模型（domain message information model，DMIM）和具化消息信息模型（refined message information model，RMIM），如图8-10所示。

域消息信息模型（DMIM）是RIM的一个子集，它包括一组完全扩展的类克隆、属性和关系，用于为任何特定的域创建用于信息交换的消息及特定域的信息模型。例如“病历/结构化文档”域使用的数据类与“患者管理”域使用的数据类有很大的不同。那么，这两个域的DMIM也将是很不相同的，尽管这两个域都是从RIM派生而来。

与HL7 V3标准中的其他模型一样，域消息信息模型是一个显示类之间关系的图，但它使用由HL7开发的图形和符号规则来进一步约束RIM核心类的特定语义结构。HL7图形和符号约定简化了一些关系约定，使图表更小、更简洁，并以可视方式传递更多信息。理解图形约定和符号是理解如何阅读DMIM的关键。用于DMIM的相同的图形和符号约定也用于RMIMS。 HL7定义的图形和符号约定可以参考图8-11所示的文件。

域消息信息模型覆盖了医学专业域内的主要数据分类、各数据项目的属性、数据类间的关系和参与方等，但尚未细化到在应用层面的消息定义。为使域消息信息模型转化为可供数据交换和软件研发使用的具体化消息信息模型，我们需要对域信息模型中各个类的属性的数据类型、基数值、类间的关系，以及对应的值集进行明确的定义，形成更具体、可转化为软件功能模块的信息模型，经此过程创建的信息模型，称为具化消息信息模型（refined message information model，RMIM）。

下面部分所介绍的CDA信息模型，可以理解为是一个源于RIM，专门用于规范医疗文档结构化和实现文档共享目标的RMIM模型。

具化消息信息模型（RMIM）用于表示在DMIM模型中，从一个根类或多个根类开始的，序贯连接相关数据类，针对医学专业域内具体应用场景而定义的消息信息模型，此模型可以直接转化为用于交换的消息内容。每个RMIM都是DMIM的一个子集，并且只包含组成从RMIM根类的派生出的类、属性和关联。

如图8-12所示，HL7 V3在医疗卫生管理和服务各专业领域内的信息模型及实施标准的建立通过6个核心类的扩展和RIM→DMIM→RMIM→HMD的概要模型到专业域模型的具体化而完成。HL7 RIM同时还包括数据类型模型（data type model）和术语模型（vocabulary model）。

HL7 V3数据类型模型（data type）定义了数据类型的标准，术语模型则定义了由HL7负责维护的医学概念领域（concept domain）、代码系统（code system）、代码集（value set）和代码（code）等。限于篇幅，在此不做介绍，本书第九章相关部分会对这些主题进行介绍。

二、HL7 V3 CDA介绍

HL7临床文档架构（clinical document architecture，CDA）［9］标准是一个文档标注标准，它详细规范了临床文档（如出院总结、过程记录、程序报告等）的结构和语义以支持文档的交换，是HL7 V3标准的一种，由HL7结构文档技术委员会（Structure Document Technical Committee，SDTC）负责开发和维护。美国国家标准局（ANSI）于2000年批准了HL7 CDA第1版（CDA Release One，CDA R1），使得CDA R1成为第一个起源于HL7 RIM，通过对HL7 RIM的进一步约束和细化而产生的支持临床文档交换的标准。HL7 CDA第2版（CDA Release Two，CDA R2）于2005年得到美国国家标准局（ANSI）批准认证，在美国开始正式使用；2009年，CDA R2得到国际标准组织（ISO）的认证，成为ISO标准（ISO/HL7　27932：2009）［10］。自2005年CDA R2标准面世至今，在世界范围内得到广泛的认可和应用，今天大家提及和应用的CDA标准，均默指为CDA R2标准，也是本节的主题。

（一）CDA概述

临床文档具备以下特点。

1.存续性（persistence）

一个临床文档在法律规定的时间内应当不被更改的持续保存。

2.保管方（stewardship）

一个临床文档应当有一个可以信赖的保管方。

3.法律效力（potential for authentication）

一个临床文档的内容可以具备法律效力。

4.语境（context）

一个临床文档的内容基于临床文档所描述的上下文语境。

5.完整性（wholeness）

一个临床文档的真实、准确性基于全部文档内容，而不是部分内容。

6.可读性（human readability）

一个临床文档必须是可读的。

一个CDA文档是具备以上临床文档特点的定义清晰、完整的信息客体，由文字、图像、声音，和其他多媒体内容组成。

HL7 CDA文档是以可扩展标记语言（extensible markup language，XML）的编码方式存在，其中的数据可以直接被计算机通过XML软件工具进行处理。HL7 CDA使用HL7 V3　数据类型，它的数据关系继承了HL7 RIM的数据关系定义。CDA标准有丰富、灵活的内容呈现方法，通过对文档级（document level）、章节级（section level）和条目级（entry level）、模板（template）数据元素的约束和详细定义，通用的CDA标准可以被进一步具体化和个性化，以支持不同类型的临床文档。

HL7 CDA标准具有明确的范围：为交换而定义的临床文档标准。在文档交换场景之外的内容及数据格式规范（如如何保存CDA文档）不属于HL7 CDA标准的范畴，CDA标准也不对如何创建和管理CDA文档进行规定或指导。

CDA标准的建立是为了支持在不同系统中交换不同技术复杂度的可读性文档，提供独立于传输和存储机制的病患医疗记录标准，同时具有良好的适应性，能够快速设计。因此为实现这些目标，CDA标准遵循的设计原则包括：①遵循XML标准、HL7 RIM；②尽量降低技术门槛；③设计过程中仅考虑最小需求；④与专业需求相一致；⑤必须保证CDA文档是人可读的，可以使用通用的XML浏览器、打印驱动以及CDA样式表等手段来实现；⑥支持开发标准。

（二）CDA主要构成

CDA文档的以〈Clinical Document〉开头，〈Clinical Document〉是CDA XML文档的根元素。它包含一个文档头（header）和一个文档体（body）。文档头位于〈Clinical Document〉和〈structured Body〉之间，对文档进行标识和分类，同时提供文档的所属患者、参与医生、就诊情况、签名等信息。文档体包含报告内容，可以是非结构化的，也可以是结构化的。结构化的内容位于〈structured Body〉元素内，并具体分布在不同的章节（section）或子章节（nested section）中。

CDA文档的章节内容包含在〈section〉元素内，每个章节可以包含一个文字叙述部分（narrative block）、任意数量的条目（entry）以及外部参考（external reference）。章节中的文字叙述部分位于〈section〉下的〈text〉元素内，通过转化，它应当形成适当的文本格式以供人阅读。与文字叙述部分相对应的结构化和使用标准术语代码的内容则位于〈section〉下的〈entry〉元素内，供计算机程序进行处理（如决策支持、医疗质量分析等）。在同一个〈section〉下，〈entry〉包含的结构化、代码化的内容与〈text〉包含的描述性内容通常具有一致的含义。在多大程度上对文档内容进行结构化和代码化处理取决于对数据颗粒度水平的要求程度，对全部内容进行结构化和代码化处理通常没有必要，CDA文档的接收者通常也不需要解析和处理全部的结构化和代码化的CDA条目。

在实际应用中，CDA文档交换双方或许会添加不同的条目、使用不同的模板，和支持不同的临床文件类型。针对不同情况，CDA标准都可以较简单、灵活地予以支持。比如，CDA文档可以简单到只包含叙述性自由文本而没有任何结构化内容，也可以复杂详尽到全部内容均为结构化和代码化，以支持深度的计算机数据分析和挖掘。CDA的条目可以包含子条目和引用外部参考。外部参考的引用通常是在CDA条目中完成，它可以引用CDA文档以外的内容，比如图像、手术操作或临床观察结果等。图8-13显示了CDA文档的主要构成，包括〈section〉下的两个〈observation〉CDA条目和一个〈substance Administration〉条目，其中〈substance Administration〉条目中有包括了一个〈supply〉的子条目。

如HL7 RIM起源中所介绍的，HL7 RIM是HL7 V3的基石，它作为终极的最权威的信息模型规范，指导、控制和验证医学健康各个领域的专业化的HL7 V3标准。对通用HL7 RIM进行继承、约束，并开发具体医学领域的V3标准的方法学在HL7开发框架（HL7 Development Framework，HDF）文件中有清晰的阐述［11］，CDA R2对象模型正是基于HL7医学信息标准开发框架（HDF）所规范的流程从HL7 RIM模型中继承和约束而来。通过HL7 XML工具，CDA R2对象模型和其中的数据类型、数据关系被自动转化为CDA XML Schema。CDA中的文字叙述部分则通过手工的方式定义了对应的XML Schema。图8-14列出了HL7 CDA R2相关的XML Schema文件。

（三）HL7 V3数据类型和术语

数据类型规定了HL7 RIM各类所含属性可携带的数据的结构和格式，并对其取值集合及赋值产生影响。虽然一些简单的数据类型没有太多内在的语义内容（如Integer、Timestamp），但HL7同时也规定了一些复杂的数据类型，比如General Timing Specification（GTS）数据类型，支持复杂的时间表达；Concept Description（CD）数据类型，支持后组式（Post-Coordination）概念表达（即自术语系统中将多个代码组合在一起来代表一个具体的概念）。CDA中的一些XML元素的属性（如ClinicalDocument.code　和SubstanceAdministration.routeCode）支持用HL7定义的代码或HL7认可的医学术语系统（LOINC、SNOMED CT、ICD等）中的代码来表示临床概念，与这些属性相关联的代码集（valueSet）提供了可选代码。代码集有CNE（Coded No Extensions）和　CWE（Coded With Extensions）两种类型。CNE型的代码集表示相关联的XML元素的属性的值只能从代码集中选择；CWE型的代码集表示在必要时，相关联的XML元素的属性的值可以从代码集外选择。

CDA中通过使用CD数据类型可以支持后组式概念表达。例如：SNOMED CT定义了一个“蜂窝组织炎”概念，一个“发现部位”属性，一个“足部”概念，这三个SNOMED CT代码结合在一起，在Observation.code中即可创造出后组式概念表达“｛蜂窝组织炎，发现部位=足部｝　=足部蜂窝组织炎”，此后组式概念表达也可以简单地通过一个SNOMED CT代码“足部蜂窝组织炎”来表达。虽然HL7 V3 CD数据类型提供了结合多个代码进行概念表达的方法，但需要依赖于标准术语系统本身的规则去决定哪些代码可以被结合在一起以及恰当的后组式表达格式。

（四）CDA R2对象模型

CDA R2对象模型是CDA标准的技术图示，它沿用了HL7 RIM的模型表达和标注规范，提供了详细的CDA中每个类的约束和精炼的呈现。

1.CDA R2文档头

CDA文档头为整个文档设置了语境，使临床文档能够在机构内、机构间互相交换，以方便临床文档管理和方便将个体患者临床文档整合进患者终身电子医疗记录。CDA模型的起始点是ClinicalDocument类，ClinicalDocument类包括许多属性，比如代表文档唯一标识符的ClinicalDocument.id；代表文档种类的ClinicalDocument.code（用LOINC术语系统中的文档代码表示病史和体检报告、出院小结和病程记录等）；代表文本创建时间的effectiveTime；代表文件保密级别的confidentiality-Code等。CDA R2的文档头还定义了相关的各类参与者，如认证者（authenticator）、作者（author）、就诊参与方（encounter participant）、法律认证者（legalAuthenticator）、执行者（performer）等。

2.CDA R2文档体

文档体包含临床报告内容，可以是非结构化的纯文本报告形式，以NonXMLBody元素表示；也可以是结构化内容，以StructuredBody表示。StructuredBody含有一或多个章节（Section）组分。Section类包括很多属性，如Section.id代表章节的唯一标识；Section.code代表章节的类别，可以通过使用LOINC术语系统的不同代码来代表诸如主诉、过敏反应、家族史等类别；Section.title表示一个章节的名称；Section.text则包含该章节的可读性内容，文档作者需要保证它的准确性、真实性和可读性。章节中可以有任意个数的条目（entry），条目用来代表结构化、代码化的内容。条目包括以下各类。

（1）Act：

继承于HL7 RIM Act类，当其他条目类均不适用于表示一个临床概念时，则用Act表示。

（2）Encounter：

继承于HL7 RIM的PatientEncounter类，表示各类就诊，包括随访及患者转诊。

（3）Observation：

继承于HL7 RIM的Observation类，表示代码化或其他的临床观察项目和结果。

（4）ObservationMedia：

继承于HL7 RIM的Observation类，表示临床文档中的多媒体内容。

（5）Organizer：

继承于HL7 RIM Act类，表示性质相似或有关联的一组数据。

（6）Procedure：

继承于HL7 RIM Procedure类，表示临床手术或介入性操作。

（7）RegionOfInterest：

继承于HL7 RIM的Observation类，表示在影像中需要特别注意的部分。

（8）SubstanceAdministration：

继承于HL7 RIM SubstanceAdministration类，表示与药物相关的各类临床事件，如用药史、药物医嘱、发药等。

（9）Supply：

继承于HL7 RIM的Supply类，表示一方提供给另一方的材料或物件。

条目类同样包括很多属性，如id、时间、类型代码、值、参与者等。条目彼此之间可以有语义关联，如“急性阑尾炎”诊断（Observation）导致了“阑尾切除术”手术（Procedure）。条目间逻辑关联关系的建立通过entryRelationship实现，entryRelationship的属性typeCode通过采用不同的HL7定义的关联关系代码，可以较为准确地代表各类逻辑关联关系。如typeCode的值为CAUS时，即代表一个事件导致了另一个事件的产生；当值为SAS时，即代表了一个事件发生于另一个事件之后；当值为COMP时，即代表一个对象包含着另一个对象。图8-15表示了一个包含entryRelationship的处方CDA样例。

CDA R2是一个临床文档架构，而不是某类具体临床文档的格式、内容标准规范。因此，HL7结构化文档技术委员会（SDTC）采用了CDA实施指南（CDAimplementationGuide，CDA IG）来规范具体的临床文档的格式，内容，及医学代码关联，有代表性的CDA IG是继续医疗护理文档（continuity of care document，CCD）。

三、HL7 V3 CDA R2标准总结

CDA R2代表了HL7 V3走向语义互操作能力（semantic interoperability）的坚实一步，为临床文档的交换提供了可实施的标准。因为CDA R2的小巧（仅包含6个XSD文件）及清晰的使用场景（仅支持），使得它从问世至今，在全世界范围内得到广泛的应用。美国的电子病历有意义使用（EHR meaningful use）法案中，强制要求了基于CDA R2标准的临床文档交换和获取。自2011年起，HL7结构化文档技术委员会（SDTC）开始了将已有的CDA实施指南进行统一梳理、融合的工作，并在此基础上产生了统一的CDA临床文档库（consolidated CDA，CCDA）实施指南［12］，为CDA的落地实施提供了更好的支持。CDA R2基于HL7 RIM模型，采用XML作为交换格式，对国际化应用有很好的支持，同时支持标准医学代码在不同数据水平上的关联，与HL7 V2消息标准对比，有了长足的进步，但同时有学习时间较长、实施成本较高，以及在其他非临床文档领域过度使用等问题。