FHIR 中文版

1.26.1 HL7 Version 2

HL7 version 2 (V2) 是HL7第一部信息交换标准，也是其中应用最广，在住院部信息系统中最出名的一部，尽管也有用在其他一些场合。 HL7 V2 使用由可复用的区段构建的消息来实现收发系统的信息通信和触发特定的行(转诊/转科、实验室检验申请等)。同时也支持通过通知实现单向通信以支持查询和其他工作流。

1.26.1.1 与V2标准的异同

事件驱动: FHIR和V2一样支持事件驱动的消息模式(与V2不同的在于FHIR还支持其他诸如文档、REST和其他服务模型)。参考Message Header 资源.

颗粒度: HL7 V2中的 "Segment" 结构与FHIR中的resources类似，都是可复用的数据块. 然而，V2的区段无法单独操作。另外，不是所有的区段都有FHIR资源独立标识的特征。由于在扩展上范围和方法的差异，V2区段和数据类型常常和数据元混杂在一起，大多数开发中都无法重用和理解。

Segments/区段可以组合成可重复的/或者可选的集合，称之为”组”，来表达所有的业务对象。例如， OMP (药房/治疗医嘱消息)中的 "医嘱"部分包含:

ORC区段，针对的是医嘱相关的工作流方面的数据
RXO 区段，针对的是医嘱相关的药房方面的数据
可选的TQ1 和 TQ2 区块描述医嘱的时间
可选的 NTE 区段，针对的是医嘱的渲染和其他额外信息
可选的 RXR 区块描述路径信息
等等.

V2中针对粒度的方法强调的是对"信息模式"的复用 .比如，时间和路径信息单独没有意义，但是在很多时候是有价值的。由于三层嵌套的限制，也需要单独的区块，否则嵌套的层次就太深了。FHIR针对复用性采用了不同的方法，关注的是可以独立维护管理的对象。 MedicationPrescription 资源中包含了上述的所有方面，除了ORC中一些针对工作流的内容，则是由 Order 资源来处理. MedicationPrescription 资源本身很复杂，包含了用法和配发的嵌套结构等等，这些本身就不是简单的数据类型。

扩展性: HL7 V2 中扩展机制是通过使用"Z-segments"实现的.
在没有发送方事先的人为解释之前这些扩展的含义是不透明的。扩展本应是仅限于那些不会影响标准区段含义的数据项。
另一方面，FHIR中的扩展上可以出现在任意的层次上(包括数据类型内部)。 ModifierExtensions 可能用在扩展会改变其他元素数据含义的情况下 (比如引入记录的逆指标). 最后，FHIR扩展的含义是通过定义扩展的URI来确定 . 这种URI的方式也确保了不同系统定义的扩展不会冲突(Z-区段就存在这类问题)

版本内的兼容性: 对于维护向前向后的兼容性，HL7 version 2有严格的流程。只有在现有字段、组件的末尾才能新增内容。应用程序应忽略意外内容或重复。FHIR中也有类似的兼容性规则。一个元素在FHIR实例中的路径在以后的版本中将不会变化，在试行版过程中会开发针对新增元素的一些特殊规则(如忽略，核对是否有“必须理解”的标记)

人可读性: 一般而言，HL7 V2实例不提供交换内容的人可读的版本。而一些系统可能会使用NTE区段来提供人可读的整个消息或部分消息内容，这些规则因机构而异。FHIR要每个资源都要有人可读的部分。

更新机制: HL7 V2数据一般是以 "snapshot" 模式来交换的——通过传输一份完整的赋值后的数据实例来实现更新，然而，V2中的一些区段和消息支持更复杂的交换，只有当已经发送了交换的消息之后，用一些编码或特殊值来标识这类交换已经发生了(诸如添加地址、移除姓名)。FHIR中只支持snapshot模式，而 ModifierExtensions 的使用可能会引入与V2类似的内容，这样做会带来互操作性的问题，会使得资源脱离了消息的范式难以利用

可选性 & 规范: 在国际标准的层面上，HL7 V2 和 FHIR都提供了相同程度上的灵活度，大多数数据元素是可选的，然而有两点不同。
FHIR资源中对于哪些元素要包含在核心表中有更多限制——只有大多数系统支持的这类数据元。HL7 V2倾向于包含哪些旨在很少场景下会用到的数据元。FHIR 利用扩展来处理这些情况。V2和FHIR都提供了正式的机制来定义规范，也就是如何来使用标准的建议。然而 V2的机制并没有得到广泛应用 . FHIR 规范是方法论的一个基本组件，内置在工具包里，提高了应用的可能性。

1.26.1.2 基于V2实现系统互操作性需要考虑的因素

1、映射: HL7 V2互操作性最大的难点在于实现的多样性。甚至是类似的业务环境中，同样场景的处理，所支持的数据元也有差异，某个数据元在数据实例中的位置也各不相同。因此，在国际层面或者区域层面上，定义出V2与FHIR之间一致性映射规则是不现实的。FHIR中的映射提供了一个起点，但具体的映射需要结合实现中的具体情况。

2、扩展: 尽管一些V2元素可以对应到FHIR的核心元素中来，但大多数是不能的。当FHIR核心模型不支持某个V2元素时，就需要扩展来共享此类信息。如果有必要的话，HL7可能会选择发布和维护专门针对FHIR核心模型中不支持的V2元素的扩展。在定义本地扩展之前应先在FHIR扩展注册库中查询。如果时间允许的话，考虑联系相关的HL7工作组来定义那些需要却没有的额外的V2扩展。如果时间不允许的话，应用程序可以现行自己定义扩展，但应考虑如果将来HL7定义了之后的技术迁移计划。对于Z区段而言，应当采用针对定义Z区段的某个系统的URI (如 http://acme.org/fhir/extensions/consent)而不是Z区段的名称 (如. http://hl7.org/ZAC).

3、资源标识 : V2消息常常会引用之前消息中已经存在的对象。当消息与FHIR之间进行转换时，这些引用应当指向资源的同一个URI。考虑到不是所有V2消息对象都有标识符，这可能存在一些问题。使用FHIRtransactions是解决此类问题的一种方法.然而，这种方法在使用消息的环境中会产生哪些后果还有有得到验证。早期应用中，开发人员需要自行选择自己的策略。

4、 引用和资源的合并 : V2消息实例可能会引用同一个对象很多次。比如，一个包含了患者用药史的消息可能会包含很多次对同一个医生、医院的引用。尽管在一些情况下，某个对象的数据应该是一样的，在某些情况下，这些信息可能是不同的。比如，在既往的记录中发送系统可能只发送了以往的电话号码，而新的记录则会包含现在的电话号码。另外，消息模式可能会允许消息的不同部分详细程度各异，或者发送系统在设计时可能只是发送消息的不同部分详细程度各异的信息(比如，给下医嘱的医生电话号码，而数据录入人员则不需要)。当要转换成FHIR时，对同一个对象的所有引用一般而言只有一个单独的资源标识符，在实例中也只会被引用一次，其中包含了所有的信息。这带来了两个问题：

1. 转换程序如何识别一个消息的两部分引用的是同一个对象？  尽管一些引用可能会有唯一标识符或者名称，我们可以确定是同一个对象，其他则不然——尽管可能组合一些属性也能确定。具体原则需要由开发人员来确定。    
2. 如果数据存在多个版本，应该使用哪个——或者应该发送不同历史记录id的多个版本？ (如果是后裔中清空，版本的顺序应该是怎样的？ 消息中的数据能否确定版本的顺序 (比如 assuming older order dates have &quot;older&quot;  demographics), 在entry的updated元素中应该指定日期来确定顺序，如果不能确定顺序，就很难将数据整合进一个资源中去或者表达多个资源的数据。

5、可标识资源 vs. 内嵌资源 : 每个 HL7 V2 消息能改对应到多个资源实例——通常是10个或者是100个资源实例。为了保持与V2消息模式的一致性，所有资源数据一般是作为FHIR消息的一部分来发送的，而不是向RESTFUL实现中作为引用来发送的。然而，资源作为消息 bundle的一部分，FHIR有2种传输方式: 既可以以“完整可标识”资源来发送(atom feed中的entry，包含了各自的标识，也可以作为单个transaction的对象)，或者是作为内嵌资源来发送，也就是说只是相对其他资源才是可标识的，自己本身是不能检索或者操作的。V2到FHIR的转换过程需要确定要完整的标识一个资源，哪些数据元必须出现。在一些情况下，在映射的时候就完成了这样的工作。举个例子，XCN包含了一个名称 (|^Smith^John|)所包含的信息不足以将其与其他的 John Smith进行区分, 因此需要内嵌资源，而 XCN |12345^Smith^John|就能做到,尽管还需要转换过程能够了解标识的范围和管理流程。

6、生成人可读的内容: FHIR要求每个资源都要有人可读的内容 narrative ，包含那些与人决策相关的所有信息. 当从V2转换成FHIR时，开发人员需要确定渲染消息中的哪些内容(可能需要医生的协助)以及如何生成这些内容。

7、空值和更新模式 : 在HL7 V2里面, "action"编码能够确定特定区段中的信息是否要新增、更新或者删除。 Fields可以用 "null" (一组不包含其他字符的双引号) 来表示这个field可以被删除。省略一个元素或者重复一个元素常常理解为”保持现有数据不变“。这与FHIR中要求所有数据都是快照的方法不同，系统要么需要内建逻辑来生成每个资源的完整快照，要么是引入扩展修饰符来提供类似V2的机制。