自1987年以来，Health Level Seven (HL7) 一直在编制医疗保健信息交换标准及相关标准。这些年来，该组织已经编制了数量众多的标准家族——其中有许多在世界范围内用于实现医疗保健数据共享的自动化以及改善患者照护服务。FHIR的编制旨在做到在毫不知晓其他这些技术规范的情况下也易于实施。不过，无论是在运用源于实践的最佳方法（或者说规范做法）方面，还是在努力避免既往工作的一些缺陷方面，FHIR的确都吸取利用了过去的经验教训。

PS：
除了如下所述的主要标准家族，HL7还编制了许许多多的实施指南（implementation guide，IG）。其中，有些实施指南的知名度已经与标准家族本身旗鼓相当。如下所提出的关于每个标准家族的一般性指导原则，应当同时也适用于基于相应标准的所有实施指南。例如，关于CDA的那些指导原则，也将适用于联合型CDA（Consolidated CDA，CCDA）、连续性照护文档（Continuity of Care Document，CCD）以及其他的CDA概貌（profile，规范）。
这里，尽管我们阐述的重点是FHIR与其他HL7标准之间的关系，但实际上同时也存在着FHIR与非HL7标准之间的关系。一些FHIR资源提供了对于源自其他标准的功能性的直接实施。此类标准包括DICOM（参见 FHIR 成像检查资源 ImagingStudy）和IHE（例如，安全事件资源 SecurityEvent 和文档引用资源 DocumentReference）。
许多FHIR资源是从其他标准那里提取的需求，或者是提供了与其他标准的映射关系。一些资源还额外提供了作为其实施注解组成部分的，关于如何将其与外部技术规范配合使用的指导。另外，HL7维基网站还提供了专门的维基页面，用于记录更多关于配合使用FHIR与外部技术规范的指导。
FHIR技术规范本身能够满足过去所有主要的HL7互操作性标准（V2、V3和CDA）所涵盖的那些需求。从互操作性的难易程度上来说，在很多情况下，FHIR技术规范还额外提供了若干的好处/优势。因此说，FHIR技术规范还是有可能能够逐步取代一些或者所有这些标准的。不过，目前尚不清楚市场究竟会多快（或者，甚至是否会）促成这样一种迁移转变。很可能出现的情况就是，大多数这些标准将会并存相当长一段时间。只要HL7会员们需要，HL7就会致力于持续不断地将已有的标准维护下去。

第2版 HL7 标准
第2版 HL7 标准（HL7 Version 2，HL7 V2）乃是HL7的第一项信息交换标准。尽管在各种各样的其他背景下也会使用HL7 V2，但在世界各地的住院环境下，它目前是采纳最为广泛的杰出标准之一。HL7 V2采用的是由种种可再用区段（segment，段）所构成的消息（message，报文）。此类消息用于在发送方与接收方系统之间传输与医疗保健服务相关的信息，以及用于调用相关的行为（如患者的转移、检验项目的申请等等）。此外，HL7 V2还支持基于通知的单向通讯，并且也支持查询及其他工作流程。

与 HL7 V2 之间的异同点
基于事件
FHIR支持与HL7 V2消息传输结构类似的，基于事件的消息传输范式（messaging paradigm，消息传输模式）（尽管与HL7 V2不同的是，FHIR还支持包括文档在内的其他范式、REST架构以及其他的服务模型）。参见FHIR消息标头（消息头，报文标头）资源MessageHeader。

粒度
HL7 V2的“区段（Segment，段）”结构提供的是可再用的数据块，且大致对应于FHIR之中关于资源的概念。然而，无法对HL7 V2区段进行独立操作和处理。而且，并不是所有的HL7 V2区段都具有FHIR资源所具有的独立标识的那些特性。因为在适用范围和扩展方法方面的差异，HL7 V2区段和数据类型常常与大多数实施工作并不使用的（或者，甚至是并不理解的）那些数据元混杂在一起。
可以将若干个区段组合成所谓“分组（group）”的重复性和/或可选性集合，用于表示完整的医疗保健业务对象。例如，OMP（Pharmacy/Treatment Order Message，药房/治疗医嘱消息）的医嘱组件“Order”之中就包括下列区段：
一个ORC区段：用于处理当前医嘱的工作流程特征
一个RXO区段：用于处理药房所特有的医嘱特征
可选性的TQ1和TQ2区段：用于描述当前医嘱的时间特征（timing）
可选性的NTE 区段：用于处理当前医嘱的呈现或者补充注释
可选性的RXR 区段：用于描述相应的途径信息
其他区段……
HL7 V2在粒度方面的方法强调了信息“模式”的再用。例如，时间特征和途径信息本身单独存在时并没有什么用处，但其在许多情况下却是有用的。因为三级嵌套的限制，对于那些否则会嵌套过深的数据结构来说，不同的区段也是必不可少的。FHIR则在可再用性方面采取了不同的方法，侧重于那些可独立加以维护的对象。除了ORC区段的一些工作流程特征是由FHIR医嘱/指令资源Order来处理外，FHIR药物处方资源MedicationPrescription涵盖了上述区段的所有特征信息。FHIR药物处方资源MedicationPrescription本身并不简单，其中包含并非简单数据类型的嵌套式结构，分别用于表达剂量要求、药物配发要求等等信息。

可扩展性
HL7 V2利用“Z-区段”提供了一种扩展机制。在事先未经发送方人工解释的情况下，此类扩展的含义晦涩难懂，并不透明。依据HL7 V2的规定，此类扩展本来就应当局限于那些并不会影响“标准”区段含义的数据元。FHIR扩展则可以在扩展能够改变其他元素含义的情况下使用（例如，引入一个针对某项记录的否定标志）。此外，可以通过解析负责定义相应扩展的URI，来发现FHIR扩展的含义。这种URI方法同时也保证了不同的独立系统所创建的扩展之间不会发生冲突。而对于Z-区段，这方面却是一个问题。

版本之间的兼容性
对于向前和向后兼容性的保持，HL7 V2规定有严格的过程。只能将内容添加到已有字段、组件等等的末尾。FHIR承诺具有类似的兼容性规则。在未来的新版本当中，FHIR实例内通向特定元素的路径将会保持不变。在FHIR试行期间，将会制定关于处理“新增”元素的具体规则（是否予以忽略，是否检查“必须理解标志”等等）。

人工可读性
一般来说，HL7 V2实例并不为所交换的内容提供人工可读型的版本。有些系统可能会利用NTE区段来为消息有效载荷的全部或部分内容提供人工可读型呈现形式。但关于究竟何时或是否出现这种形式的规则，却是不同地点/场所所特有的。FHIR要求为每个资源都提供人工可读型内容。

更新行为
HL7 V2数据的交换通常采用的是“快照”模式——通过发送已经填入新数据的相应实例的完整副本来传输更新。不过，有些HL7 V2区段和消息支持更为复杂的交换——其中，仅仅发送的是发生了变更的数据，并且采用代码或特殊取值来表示究竟出现的是哪种变更（比如，添加某个地址，删除某个名称等等）。“开箱即用式”/现成的FHIR在发挥功能时则仅仅采用快照模式。尽管可以利用修饰型扩展ModifierExtensions来引入与HL7 V2等价的行为，但这样就会造成种种的互操作性问题，并且会用到那些在相应消息传输范式范围之外会造成困难的资源。

可选性与概貌
在国际标准的层次上，HL7 V2和FHIR所提供的灵活性相互类似。大多数数据元都是可选性的。不过，二者之间还存在着两处差别。从核心技术规范之中究竟收录什么样的元素来说，FHIR资源要显得有限得多——只是绝大多数系统将会支持的那些元素。HL7 V2之中则往往倾向于收录许多只有在非常局限的情况下才会用到的元素。对于此类情况，FHIR则是使用扩展。HL7 V2和FHIR二者都提供了用于定义概貌的正式机制，从而为运用相应的技术规范提供指导。不过，HL7 V2机制目前并未得到广泛使用。FHIR概貌则变成了其方法学的一个不可或缺的基本组件，并且被构建在相应的工具当中，从而提高了对其加以采用的可能性。

关于与 HL7 V2 之间互操作性的考虑事项
映射
HL7 V2互操作性所面临的最大难题之一就是其实施工作的变异问题。即使是在相似业务环境下处理的是完全相同的场景，所支持的数据元也可能各不相同，甚至在特定实例之中特定数据元的放置位置也可能变幻不定。因此，要在国际层次上，或者甚至是在区域层次上，在HL7 V2与FHIR之间确定出协调一致的映射规则，是件不太现实的事情。所提供的FHIR映射关系只是可供着手加以考虑的起点，但是总的来说，映射工作还是需要依据不同实施项目的具体情况来分别进行。

扩展
对于HL7 V2元素，其中一些将会被映射到FHIR核心之上，但大部分则不会。对于FHIR核心并不支持的HL7 V2元素，将需要利用相应的扩展来共享相应的信息。如果有兴趣，HL7则可能会选择发布和维护针对那些并不作为FHIR核心技术规范组成部分而加以支持的HL7 V2元素的扩展。在定义本地扩展之前，应当搜索FHIR扩展注册库。如果时间允许，应当与相应的HL7工作组取得联系，请求定义额外所需的但当前尚缺的HL7 V2扩展。如果时间不允许，应用程序则可以自行定义扩展，但应当针对日后HL7是否会/何时会定义相应扩展，制定出相应的迁移计划。对于Z-区段，应当将相应的URI定义成为负责定义相应Z-区段的系统/环境所特有的（比如，http://acme.org/fhir/extensions/consent），而不是基于相应Z-区段本身的名称（因为可能存在名称相同而含义不同的Z-区段）（比如，http://hl7.org/ZAC）。

资源标识
HL7 V2消息常常会引用那些既往消息之中已被引用过的对象。在将这些消息转换为FHIR的时候，就需要将此类引用指向相同的资源URI。在HL7 V2消息之中，并不是所有的HL7 V2消息对象都具有标识符，因此，在某种程度上，这样做就可能成问题。对于FHIR交易，目前有一种处理这种问题的方法。不过，目前还没有解决在消息传输环境下采用这种方法所带来的后果。作为早期实施工作的组成部分，就需要实施者探索他们自己的策略。

合并引用和资源
HL7 V2消息实例还可能会数次引用同一“对象”。例如，含有患者用药史的消息之中很可能包括有对于同一临床医生和门诊/医院的多次引用。在某些情况下，针对特定对象所采集的那些数据可能会在所有各次的使用当中完全相同，而在其他一些情况下，此类信息则可能会有所不同。例如，发送方系统可能会传输的是适合于既往记录的历史性电话号码以及适用于新生记录的现用电话号码。或者，消息设计可能会允许在相应消息的不同部分当中表达不同数量的细节信息，或者说，发送方应用程序可能会只是设计用于在相应消息的不同部分当中传输不同数量的细节信息（比如，传送下达医嘱的医生的电话号码，而不传送数据录入医生的）。在转换到FHIR时，对于同一“对象”的所有引用一般都会具有同一资源标识符，并且在相应实例之中仅仅引用一次——并备有所需要的/现成可用的，完整的一套信息。然而，这就造成了如下两个难题：

转换软件如何识别出特定消息之中的两个部分何时引用的是同一对象？有些引用可能具有唯一性标识符或名称，足以用来确认是“同一对象”，但其他的则可能并非如此——尽管若干特征属性（attribute）所构成的其他某种组合可能足以达到此目的。这样，就需要开展转换工作的实施者来确定具体的规则。
如果数据存在多个版本，究竟应当采用那套数据——或者，是否应当利用不同的历史标识符来发送多个历史版本？如果是后一种情况，这些版本的“次序”如何呢？如果可以依据相应消息之中的数据来确定这些版本的次序（比如，假设既往医嘱具有“较为陈旧的”人口统计学信息/个人基本信息），则可以针对录入更新的元素，指定相应的日期，以表明相对次序。如果无法确定次序，那就难于将这些数据合并成单独一个资源，或者是采用多个资源来表示它们。
被标识型资源与被包含型资源
每条HL7 V2消息将映射至多个资源实例——往往是数十个，甚至是数百个资源实例。为了保持与HL7 V2消息传输范式之间的一致性，通常会在网络上将所有的资源数据作为相应FHIR消息的组成部分加以发送（这将是RESTful实施项目的典型情况），而不是采用引用的形式加以发送。不过，FHIR提供有两种不同的方式，用于将资源作为相应消息捆束（message bundle）的组成部分加以传输：要么是将其作为“经过全面标识的”资源加以发送（在原子型纲要<atom feed>之中作为带有各自标识的直接条目<direct entries>，并且能够作为不同独立交易的主体对象），要么是将其作为被包含型资源（contained resource）加以发送，也就意味着，只是相对于另一资源对它们加以了标识，无法单独对它们本身进行获取或其他方式的操作处理。对于一个要加以全面标识的资源，HL7 V2到FHIR的转换过程就需要确定出究竟存在或者必须存在哪些数据元。在某些情况下，这项确定工作是在映射时完成的，而在其他情况下，则可能要取决于特定实例的内容。例如，其中仅仅含有一个姓名（|^{Smith^{John|）的XCN（Extended}} composite ID number and name data type）就没有包含足够的信息，无法将这位医师与任何其他的John Smith区别开来，因此需要将其作为包含型资源，而带有|12345^{Smith^{John|的XCN一般则可以，尽管会需要转换过程知晓关于该标识符的适用范围及管理过程。}}

生成人工可读型内容
FHIR要求每个资源都具有一个人工可读型的叙述部分，且其中包含的是所有与人工决策制定相关的信息。在从HL7 V2进行转换的时候，就会需要开发者（很可能在临床医生的指导下）确定出，究竟应当呈现消息之中的什么信息以及如何生成这些内容。

空值与更新方式
在HL7 V2之中，“动作（action）”代码可以用来确定特定的区段究竟表示的是所要新增的，还是所要更新的，还是所要删除的信息。为了标明某个所要删除的字段，可以采用“空值”（即两个连续的英文双引号，且不含任何其他字符）来填充字段。一般来说，会将所忽略的元素或重复解释为“保持现有数据不变”。相比而言，FHIR的方法则是要求所有的数据都以特定快照的形式存在。系统则或者是需要从逻辑上发展改进，以便能够生成每个资源的完整快照，或者是需要引入修饰型扩展，以便允许类似于HL7 V2的行为。

第3版 HL7 标准 (及 ISO 21090)
第3版 HL7 标准（HL7 Version 3，HL7 V3）是HL7的下一代消息传输标准。它首次引入了共同的参考信息模型（Reference Information Model，RIM）、数据类型模型、一套词表以及一种正式的标准制定方法学。而且，作为用于共享医疗保健信息的消息传输的备选架构，HL7 V3还引入了对于“文档”的使用（参见下文之中与CDA之间的比较）。尽管“V3”这条术语在名义上同时涵盖消息传输和文档，但其通常指的是“V3消息传输”。目前，ISO已经将那些作为HL7 V3基础的数据类型作为ISO 21090的内容加以采纳。HL7 RIM也已被采纳为一项ISO标准。

HL7 V3消息传输标准已经获得许多大型项目的采用，尤其是在电子健康档案（electronic health record，EHR）方面，尽管其尚未达到HL7 V2的那种市场占有率（市场渗透率）。同时，其他尚未全面采用HL7 V3方法学的标准制定组织（SDO）和项目也采用了HL7 RIM和ISO 21090数据类型。这里所提供的大多数评论意见和指导原则也将适用于此类解决方案。

与 HL7 V3 之间的异同点
参考模型
HL7 RIM的采用乃是HL7 V3方法学的核心特征，并且在HL7 V3的技术规范和有线格式（wire format）当中，HL7 RIM也居于核心地位。HL7 V3实例之中的所有数据元派生自要么是RIM，要么是那些ISO数据类型。在FHIR当中，对于大多数资源和数据类型元素来说，情况也是如此，但并非全部。一些资源（概貌资源Profile、符合性资源Conformance、取值集合资源ValueSet等等）处理的是那些超出了RIM适用范围的内容。在少数情况下，对于那些目前在HL7 V3数据类型模型之中并不支持的FHIR数据类型，已经做出了相应的调整。预期在下一版本的HL7 V3数据类型模型之中将会支持此类变更。二者的主要区别在于，FHIR有线格式并不是由RIM映射关系来驱动的。这样，就造就了简洁且直观得多的实例。在绝对不了解HL7 RIM的情况下，实施FHIR也是可能的事情。

代码
HL7 V3在相当大程度上依赖于编码型特征属性（coded attributes）来传达实例的含义。有关的例子包括classCode、moodCode、determinerCode等等。这些特征属性的允许代码处在HL7的严格控制之下。FHIR之中也具有那些局限于使用FHIR技术规范所定义代码的特征属性——即那些采用代码数据类型code的特征属性。不过，它们一般仅限于那些带有业务含义的特征属性——如状态、联系方式类型等等。

FHIR和HL7 V3二者均利用取值集合来规定在特定语境下可以用于不同特征属性的那些套代码。然而，在FHIR里面，取值集合ValueSet只是又一种类型的资源而已，而这就意味着，就像任何其他的数据那样，可以将其作为特定实例的组成部分加以发送。概貌资源Profile、符合性资源Conformance以及其他元层次资源（meta-level resource，元级资源）的情况也是如此。

粒度与引用
HL7 V3模型分为三种主要的类型，即包装器（wrapper，封装器）、有效载荷（payload）以及通用消息元素类型（Common Message Element Type，CMET）。这些类型的模型可以组合成不同的交互活动（interaction），用于定义可以一次性在网络上（over the wire）传送的那套内容。在某些情况下，每种这些类型模型的粒度都会精确地对应于FHIR资源的粒度，但情况并非总是如此。HL7 V3模型的划分依据的是关于重复利用的期望值或者说可能性。FHIR模型的划分则依据的是，是否认为它们所表达的对象能够“独立”。在HL7 V3之中，可以存在众多的模型，用来表达相同的基础性医疗保健服务信息构造。例如，在HL7国际（HL7 International）层面上，对于“患者”这一概念，就有10个不同的CMET。而且，有些消息载荷模型还会在不采用CMET的情况下直接表示患者概念。在HL7分会（HL7 affiliates）及其他的HL7 V3实施者所建立的HL7 V3模型里面，还存在着进一步的变异。这些不同的CMET分别有着各自的Schema，并且还可能采用不同的元素名称、不同的嵌套层数以及不同的约束条件。然而，对于FHIR来说，则只有一个患者资源Patient。针对于患者资源，可以创建出许许多多的概貌，但它们所采用的将全都是同一Schema，并且支持相同的有线格式。

约束式设计
HL7 V3之中的设计方法学属于是一种“约束式设计（design by constraint，渐进约束式设计）”。其基本思想就是，采用HL7 RIM来表达任何种类的医疗保健通讯所需的所有数据。所有其他的数据模型只是对HL7 RIM加以约束限制，从而反映特定领域空间的需求。首先是国际层面的约束，而进一步的细化约束则发生在具体的国家/地区、项目以及最终具体的实施项目当中。随着模型变得距离实施者越来越近，模型也会变得越来越不抽象，或者说变得越来越具象。其结果就是，HL7 V3模型倾向于在其覆盖范围和能力方面显得极为宽泛，同时又有某种程度的抽象。HL7 V3模型需要具备这些特点，以便保证相应模型所涵盖的相应空间之中所有可能的实施工作都能成为针对该模型的正规约束。而且，每个模型都会产生其各自的Schema，并且在大多数情况下，经过约束的那些Schema并不是严格地有线兼容（strictly wire-compatible with，在有线格式上严格地兼容）所约束模型的那些Schema。

FHIR采取的则是不同的方法。FHIR资源并没有试图去表达特定空间之中所可能用到的所有数据元。在相应资源的适用范围内，只有预期“大多数”实施项目会加以采用的那些数据元，才会被视为相应核心资源定义的组成部分（这种方法有时又被称为“80/20法则<80% rule，Pareto principle，二八定律，80律>”——假如大约80%负责维护该资源的系统将会支持特定元素，那么，该元素就会成为核心的组成部分）。对于所有其他的数据元，预期则会采用扩展的方式加以处理。概貌则既用于约束各种资源，也用于定义适合于缩小实施空间的扩展。对于某种特定的资源，在所有的概貌之间，则保持了有线格式互操作性（wire format interoperability）。

语境传导
当在人与人之间传送医疗保健信息的时候，可以依据语境推断出许多的数据。例如，如果报告封面上标有一位“作者”，那么，一般就会推断，该报告之中的每项陈述都是由这同一个人所编写的。当需要采用计算机来分析数据时，无论是对于查询、决策支持，还是其他分析来说，这种推理都会变得更具挑战性。因此，HL7 V3方法学提供了三种不同的机制，以便允许数据模型规定如何在不同的模型之间传播“语境”信息，好让计算机明确知道那些人类通常凭直觉即可理解的东西。FHIR选择的是另一种途径。在FHIR之中，并不传导任何语境信息——所有的信息都是明确的。假如一份关于某位患者的报告之中含有100项全都是关于这同一位患者的观察结果，则每项观察结果之中都会包括一条指向该患者的引用。不过，这种方法相对容易些，因为那只是条引用而已——一个标识符，并且可能还有一个简短的显示取值。这种方法的好处之一就是，可以安全地利用和检查分析每个资源，而无须关心当时传输相应资源时所处的语境如何。每个资源实例的含义都是完全自包含的（self-contained，独立的）。

空值类型
在医疗保健领域，数据出现未知、无法获得和使用、具有例外取值或者是由于其他原因而超出“正常”取值范围的取值，乃是相当常见的情况。为了处理这个问题，HL7 V3对于其各种模型之中的几乎每个特征属性（attribute）和数据类型属性（data type property），都引入了一个称为“空值类型（null flavor，空值品种，空值花色，空值种类）”的概念。在发送数据时，这些编码型的空值类型可以取代通常所发送的关于相应特征属性、关联关系或数据类型属性的那些数据，或者是作为它们的附加数据。关于空值类型的例子包括关于“Unknown”（未知）、“Not asked”（未询问）、“Positive infinity”（正无穷大）、“Trace amount”（痕量）、“Masked”（已遮掩）、“Other”（其他）之类的概念。除非将一个元素明确标记为“必填型（mandatory，必备型）”——即不允许使用任何的空值类型，这些空值类型则绝对可以出现在任何位置上。

FHIR对于这一问题的处理方法则有所不同。只有在那些预期大多数系统将会需要空值类型的情况下，才会在其核心技术规范当中引入空值类型。在需要的时候，也只是局限于那些适合于相应元素的空值类型。

关于与 HL7 V3 之间互操作性的考虑事项
RIM映射关系的使用
大多数资源元素和数据类型属性之中都包括有指向RIM的映射关系。这些映射关系用于两种目的。首先，它们有助于依据HL7的那些参考模型来定义FHIR语义，从而有利于保证那些负责定义数据元的工作组对于每个元素的含义具有良好一致的理解。同时，它们还可以为那些可能正在指望实现HL7 V3与FHIR之间迁移或映射的HL7 V3技术规范实施者们提供指导。不过，对于后一种用处，重要的一点就是要理解RIM映射关系的一些局限性。RIM是一种语言，允许采用许许多多不同的方式，并且以不同的粒度和表现力，来表达同一“概念”。因此，将RIM元素映射到核心FHIR元素，是件完全可能的事情，即使是它的RIM表达形式在某种程度上有别于映射关系之中所描述的样子。此外，并不是所有的V3模型都遵循建模规范，因此，如果相应的信息并未得到很好的表达的话，有些看似与某个FHIR元素建立了映射关系的数据元，实际上可能会并没有映射。所以，应当将RIM映射关系作为一种指南，而不是绝对的东西，而且，必须在所映射的V3技术规范的语境下进行映射。（参见下文之中“抽象模型”一节。）

HL7 V3扩展
尽管HL7 V3方法学的核心是“约束式设计”，但其还是事先为扩展的运用做了准备——要么是采用某个外来命名空间，要么是采用某个特殊的特征属性加以标记。当在HL7 V3与FHIR进行转换的时候，就会需要考虑到对于此类扩展的使用。作为一条规则，大多数HL7 V3扩展都将映射到FHIR扩展，因为HL7 V3约束式设计原则指出，在FHIR之中有资格作为“核心”的任何东西，均已成为基础HL7 V3技术规范的组成部分。

抽象模型
正如前面所提到的那样，在HL7国际层面上所创建的许多HL7 V3模型都相当抽象。因而，此类模型可以用来表达种类繁多的事情，并且，常常还可以采取种类繁多的不同表达方式。这就使此类技术规范与FHIR（或是任何其他技术规范）之间映射关系的定义工作变得相当棘手。对于实际工作当中HL7 V3与FHIR之间的互操作性，就会需要在更为具体的，更接近于实施层面的消息技术规范、实施指南和/或模板的层面之上来建立映射关系。例如，鉴于CDA模型（译者注：CDA R-MIM 模型）右半部分的表现力，将不可能将CDA完全地映射到FHIR。不过，将联合式CDA（Consolidated CDA，CCDA）模板映射到FHIR之上，则是相当可能完成的事情。

语境传导
如上所述，HL7 V3模型依赖于语境传导——隐含地或明确地对其加以控制。在将其转换到FHIR的时候，将需要把相应的语境信息传递到每个资源之中。

更新模式
在HL7 V3实例里面，与FHIR的方法类似，对于更新的处理一般采用的是快照模式——如果任何信息发生了变化，则会发送整个记录，包括那些经过修改的数据元。不过，HL7 V3方法学的确支持引入更新模式属性“updateMode”，从而对于特定实例的全部或部分内容，允许仅仅发送那些变更信息。采用updateMode属性来标记每个元素重复，以表明究竟是要对相应元素加以添加、删除，还是更新等等。额外的updateMode属性允许对更新进一步加以控制。与上述关于HL7 V2的讨论一样，将会需要实施者为每个资源生成完整的快照，或者是需要引入修饰型扩展，以便允许类似于HL7 V3的行为。

其他考虑事项
关于FHIR与HL7 V2之间互操作性的大多数实施考虑事项，同样也适用于HL7 V3，尤其是：扩展（Extensions）、独立型与被包含型资源（Independent vs. Contained resources）、资源标识（Resource Identification）、引用及资源的合并（Merging references and resources）以及人工可读型内容的生成（Generating human-readable content）。

临床文档架构
临床文档架构（Clinical Document Architecture，CDA）是目前采纳最为广泛的HL7 V3标准。CDA不但提供了其中含有关于相应文档（文书，医疗文书）的元数据的标准化标头（header，头，文件头），而且还能够携带种类繁多的，采用章节（section，小节）的形式加以组织的临床内容。CDA文档内容既可以是PDF之类未经编码的文件，也可以复杂到实现完全编码的V3结构化文档实例。

注意：不但可以利用FHIR组合式文档（组合式文书）资源Composition来创建文档，也可以借助于FHIR文档引用资源DocumentReference，把CDA文档本身作为一种二进制附件（就像XDS的做法那样），将FHIR用于交换传统的CDA R2文档。
与 CDA 之间的异同点
以临床文档为关注焦点
顾名思义，临床文档架构（Clinical Document Architecture）局限于“临床”方面的用例。CDA模型并不支持交换那些不被视为具有临床相关性（clinical relevance）的内容，如财务信息等，并且局限于那些与患者有关的文档（文书、医疗文书）。在某些情况下，为了摆脱这种限制，人们就会创建诸如HL7结构化产品标签（Structured Product Labeling，SPL）标准、非患者特异性CDA样技术规范之类的技术规范。FHIR文档对于其内容则没有任何限制，并且可以具有并非患者的其他主体对象（subject）。

人工可读性方法
CDA与FHIR二者均要求内容具有人工可读性，并且规定了关于如何呈现人工可读型文本的具体规则。CDA当中的一个细微差别就是，其人工可读型部分是针对章节（section，小节）而定义的，而对于FHIR，此类文本则是关于相应章节所指向的那个资源的。不过，事实上，这种差别并没有造成任何实际的差别。另一个区别就是，对于FHIR来说，人工可读型特征并不局限于其文档——它是由相应资源本身来驱动的。如果文档所编纂的是若干已有的资源，在呈现方法方面，这种特点则可能会造成灵活性的轻微降低。

临床陈述与资源
在CDA之中，文档“内容”的表达采用的是一种错综复杂而又极其抽象的模型，而该模型的基础是HL7的“临床陈述（Clinical Statement）”项目。其目的就是，让实施者能够采用任何的严格程度和粒度，去表达几乎任何的临床概念（实际上，CDA模型之中存在着若干的内在局限，使得对于某些临床概念的表达成为具有挑战性的难题）。为了表达任何一点临床信息，首先都需要具备RIM建模方面的专业经验。关于如何采用“开箱即用”或者说现成的方式来表达诸如变态反应（过敏）、外科手术或血压之类的事物，并不一件显而易见的事情。要支持互操作性，模板必不可少。其次，在不同的情况下，可以采用不同的方式来为常用的临床概念建模，而且，情况往往也是如此。然而，在采用FHIR时，对于特定消息之中的所有临床（和非临床）内容的处理，采用的方法都是引用已有的资源定义。有了这些资源，关于如何采用“开箱即用”或者说现成的方式来表达变态反应（过敏）和血压之类常见结构，就变得明确清晰；而且，这些资源同时也保证了，用于表达核心内容的方式只有一种。不过，这的确也造成了相应的限制，即为了共享内容，必须首先是已经定义了合适的资源。在FHIR编制工作的早期阶段，在尚未定义合适的标准资源的情况下，就可能需要用到其他资源Other。

模板与概貌
如前所述，为了理解实例的含义，CDA要依赖于模板的存在。尽管理论上可以通过查看RIM特征属性和代码来确定相应的含义，但实际情况就是，这样做往往并不安全，也是不够的。同样，为了定义含义，几乎每个CDA实例之中都包括有众多的模板标识符特征属性templateId取值，并且它们分散在整个实例当中。在采用FHIR的时候，含义是由相应的资源来定义的。概貌可用于定义扩展，但其绝不会修改核心元素的含义。可以利用标签（tags），在实例内部声明那些在构建特定实例过程中所用到的概貌。不过，此类声明并不是必不可少。

置标语言/标记语言
对于叙述型内容，CDA定义有其自己的XML语法，且大致依据的是HTML。FHIR则采用的是经过约束的一套XHTML，且在某种程度上比CDA置标方法更具表现力。从FHIR到CDA的转换将需要把这些约束考虑在内（或者是为相应的文档提供完整呈现的版本）。

关于与 CDA 之间互操作性的考虑事项
CDA属于是V3技术规范的一种类型。因此，所有适用于V3的考虑事项，同时也适用于CDA。此外，如下是CDA实施工作所特有的主题。

映射什么
如上所述，CDA模型（译者注：CDA R-MIM 模型）的右半部分（临床内容）属于是一个抽象模型。尽管可以合理地将CDA标头（header，头）映射到HL7 FHIR的组合式文档（组合式文书）资源Composition和相关资源之上，但FHIR与CDA之间的映射工作的进行还是应当在模板层面上而不是CDA技术规范本身的层面上。

人工可读型内容的粒度划分
在采用FHIR时，仅仅对位于每个章节（小节）根节点层次上的那些资源，才有叙述（narrative）部分。而在采用CDA时，每个章节（小节）都存在叙述部分。通常，这就意味着，CDA和FHIR之中的叙述部分将会彼此对应起来。不过，在某些情况下，一个章节（小节）还会包含若干其他的子章节（子小节，sub-section）。在CDA之中，此类的“容器型”的章节（小节）可以具有叙述部分。而在FHIR之中，它们则不能这样。如果要转换的话，应用程序将需要备有某种用来处理这种情况的方式。

分散元素到人工可读型部分的链接
为了保证语义可追溯性（semantic traceability），FHIR和CDA都允许在叙述部分的文本与文档编码型部分之中分散的具体元素之间建立链接关系。如果在FHIR和CDA之间进行转换的话，同时也需要对这些链接关系加以转换。不过，让这方面变得更加复杂的事实就是，在这两部技术规范之间，上述链接关系可以出现的粒度有所不同。在CDA之中，这种链接关系仅仅可以出现在章节（小节）层次之上或者是几个条目类型之一的层次之上。在采用FHIR时，这种链接关系则可以出现在任何层次之上，包括具体的数据类型组件，甚至是扩展的组成部分。从CDA到FHIR的转换将是直截了当的，而其反方向则会出现信息损失。

其他 HL7 标准
HL7还编制了许多其他并不像上述标准那样与FHIR之间存在大幅度重叠的标准。之所以重叠较少，主要是因为这些标准并不是仅仅侧重于信息交换。不过，还是值得在此对它们加以简要提及：

EHR 功能模型
EHR 功能模型（EHR Functional Model，EHR-FM）技术规范规定了电子健康档案（Electronic Health Record，EHR）系统的许多功能行为。FHIR是一项医疗保健信息交换标准，可用于满足其中的一些功能行为。关于FHIR适合于EHR-FM的详情，请参见这里。

语境管理技术规范
语境管理技术规范（Context Management Specifications，CCOW）是一项标准，允许彼此独立的系统对同一台工作站上的语境加以同步化，为该工作站的用户提供无缝界面（比如，确保协调一致的用户身份认证、对于同一患者的信息的显示、对于同一医嘱的信息的显示等等）。理论上，FHIR资源可作为CCOW实施技术的替代手段来使用，但关于适合于这么做的业务用例目前还不清楚。CCOW概貌之中包括HL7 V2映射关系。当在基于FHIR的系统之中确定CCOW链接关系的时候，这些映射关系可以用来帮助确定那些等价的FHIR数据元。

注释：CCOW原本是HL7临床语境对象工作组（Clinical Context Object Workgroup）英文名称的首字母缩略语。
阿登语法
阿登语法（Arden Syntax）是一种用于定义决策支持规则的语言。这些规则将会提及/引用那些作为相应决策制定过程组成部分来使用的数据元。不过，该技术规范并没有规定对这些数据元如何加以标识。FHIR元素和扩展标识符则可以为相关数据元的标识提供一种机制。

虚拟病历
虚拟病历（Virtual Medical Record，VMR）是HL7正在编制的一份技术规范草案，也旨在用于决策支持领域。其定义的是一种逻辑病历（logical medical record），并且可以依据它来构建决策支持规则。目前，该模型是一个专门为VMR创建的自定义模型（custom model）。不过，HL7的决策支持工作组正在评价将FHIR作为VMR技术规范未来版本结构的可能性。

来源：http://wiki.hl7.org.cn:81/index.php/FHIR%E4%B8%8E%E5%85%B6%E4%BB%96HL7%E6%A0%87%E5%87%86%E4%B9%8B%E9%97%B4%E7%9A%84%E5%85%B3%E7%B3%BB