第四节　HL7 FHIR 标准

一、HL7 FHIR的起源

HL7 V3 RIM标准自正式颁布至今已有十余年历史，在全球范围内，HL7 V3标准系列中只有CDA R2标准得到了广泛认可和应用，其他HL7 V3标准因为高度的复杂性、实施的高成本，以及较高的技术门槛被束之高阁，鲜见实践中的成功应用。CDA虽然应用广泛，但主要着重于临床文档的交换，应用场景局限；HL7 V2消息标准已有超过25年的历史，但由于自身设计的局限性，存在着许多固有问题，难以在标准内部解决；同时，在互联网技术和云计算快速发展的今天，移动医疗和基于云的医疗健康应用大量出现，医疗卫生用户希望在几天或几周内实现数据的汇交和集成，而不是传统的几个月或几年。目前的HL7 V2和V3标准很难有效支持这些新的要求，因此医疗卫生的信息交换需要一个新的、通用的、更好的标准。这就是快捷医疗保健互操作资源（fast healthcare interoperability resources，FHIR）出现的根本原因。FHIR［13］作为HL7创建的下一代标准框架，在继承了HL7 V2、V3和CDA各标准优点的同时，又利用了最新的互联网标准，并且高度重视实践性，因此受到了广泛的关注和大量的试验性应用。事实上FHIR可以满足之前所有的基本的HL7互操作性标准（HL7 V2、HL7 V3以及CDA）的要求。在许多实例中，在互操作易用性方面它能提供额外的好处。因此，FHIR逐渐取代部分或所有的现有这些标准是可能的。但目前市场如何快速实现这种转变仍然不清晰。在很大程度上，有可能大多数标准将在很长一段时间内与FHIR并存，也就是说它既可以作为单独的数据交换标准被使用，也可以与目前的其他广泛使用的标准（如CDA等）成为合作伙伴一起被使用。

FHIR标准由一系列基于资源（Resources）的模块化组件构成，通过常见的RESTful网络服务，实现跨科室、跨机构和跨地区的信息数据交换（包括临床数据、医疗保健相关的管理数据、公共卫生以及基础医学和科研数据等）。FHIR标准覆盖了医学和兽医学，支持各类医疗保健相关的应用场景，如住院治疗、长期照护、移动医疗、云端数据处理、基于EHR的数据共享以及大型医疗卫生机构内部的数据交换等，其目标是在不牺牲信息完整性的前提下，使标准的实施尽可能简单。FHIR通过利用现有的逻辑模型和理论模型，可以为医疗保健应用之间的数据交换提供一种一致的、易于实现的且严格的机制。它有一种内置的可追溯到HL7 RIM和其他重要的内容模型的机制。这就确保了在用户没有熟练掌握RIM或其他HL7 V3标准知识的条件下，可以对HL7之前已定义好的模型和最佳实践进行调整。

FHIR优于其他现存标准的原因体现在它在现有标准基础上的改进，包括：①高度重视实践，既快又易于实施（多个开发人员一天中可以有简单的工作接口）；②多个实施库，可供启动开发的多个实例；③规范使用不受任何限制；④可以使用出箱的基础资源的互操作性，也可以根据本地需求进行更改；⑤从HL7 V2和CDA进化发展而来，标准可以共存，也可以相互利用；⑥具有雄厚的Web标准基础，如XML、JSON、HTTP、OAuth等；⑦支持RESTful架构，也支持使用消息或文件的信息无缝交换；⑧简单易懂的规范；⑨一种可供开发人员使用的人类可读格式；⑩为保证正确性，通过严谨的形式化映射的基于实体的本体论分析。另外，FHIR还定义了一个简单的框架，以对现有资源进行扩展和调整，改变以往标准定制性扩展的缺点。所有的系统无论是如何开发的，都能够简单读懂这些外部扩展且使用同样的框架可以像检索其他资源一样检索到外部扩展定义。

另外，FHIR有三个描述与规范不同部分相关的稳定性和实施就绪度层次的描述性术语。①草案：该部分内容规范并不被认为是够完整或足够安全的实施规范，可能仍然存在问题或处于发展阶段。它作为一个潜在出版物，仍在征求操作协会或用户的意见和建议，并需要不断修改，以满足需求。②试用草案标准（DSTU）：它已是被修订、审查并决定作为官方实施的标准规范，但并未得到广泛应用，未来的版本将建立在此版本的基础上并可能进行根本性修改。③正式标准（normative edition）：正式标准在实践中得到了广泛的应用和检验，其内容被认为是稳定的，在未来的版本迭代中不会发生大的变化。目前最新版FHIR R4是正式版本，已于2018年12月发布，其中不同的资源（resources）有着不同的成熟度（0～5级，级别要高，意味着成熟度越高）。

二、HL7 FHIR资源介绍

FHIR规范定义了一系列的资源和一个处理资源的框架。医疗、管理、安全、术语服务等各类数据元素均以资源的形式来构建和呈现。FHIR资源的成熟度（FMM）分为7级，由低到高依次为：Draft（FMM 0）、FMM 1、FMM 2、FMM 3、FMM 4、FMM 5、Normative。Normative代表FHIR资源定义达到了最成熟的水平。在FHIR R4版中，FHIR中的资源分为5类。

1.基础类（foundation）

基础类资源为FHIR标准的应用实施、标准遵循程度验证、数据安全、数据结构化和代码化实现、医疗文书共享、数据检索和关联等核心的标准应用场景提供了基础性的支持（表8-4）。FHIR标准的落地实施，首先依赖于基础类资源的落地实施。

（1）基础类中的标准遵循度（conformance）子类：

为如何正确应用FHIR标准提供了各类资源支持。如它规定了基于不同版本的FHIR服务器如何声明能够提供的与资源相关的各类服务；StructureDefinition定义了如何描述FHIR资源、FHIR资源基本结构、数据类型及定义扩展机制等；OperationDefinition定义了如何实现计算机可执行的一个运算或查询语句等。

（2）基础类中的术语（terminology）子类：

为FHIR资源、逻辑运算、数据类型等如何实现与医学术语的关联、表达和应用提供了各类资源的支持。如CodeSystem提供了如何在FHIR中定义医学代码系统；ValueSet规定了如何定义基于代码的取值集合；ConceptMap为不同代码系统之间的临床概念关联映射提供了明确的实现方法

（3）基础类中的安全（security）子类：

为数据的全程可追溯性、数据采集和使用的（伦理）合规合法性及数据日志提供了资源支持。

（4）基础类中的文件（documents）子类：

为基于医疗文件的数据管理和交换提供了资源支持。Composition定义了如何在Bundle中将各类临床资源组合成一个有效的临床文件；DocumentManifest对一个或一组文件提供了元数据说明（文件的MetaData）等。

（5）基础类中的其他（other）子类：

对FHIR应用中的其他常见场景提供了资源支持。如Bundle用来交换含有多个资源集合的大的临床数据集合；Binary用来容纳大块的二进制字符性数据块（如文本、影像、PDF等）；OperationOutcome定义了系统如何传递警告、错误等异常信息。

2.基本类（base）

基本类资源定义了参与医疗卫生活动的各类基本资源（表8-5）。如人（医生、护士、患者等）、机构（医院、诊所、门诊等）、事件（住院、就诊、预约等）、物（药物、器械、消耗材料等）。

（1）基本类的个体（individuals）子类：

定义了医疗活动中的参与个体、医务人员、医疗行为中的角色、患者、自然人等。

（2）基本类的实体（entities）子类：

定义了医疗卫生活动中的一系列重要组成因素，如医疗卫生机构、医疗服务、地址、物质、器械等。

（3）基本类的流程（workflow）和管理（management）子类：

定义了与临床医疗服务相关的一些工作流程资源，如任务、就诊预约，医疗、护理、检查、手术操作或就诊计划，对诊疗、检查、评估等结果的核验，和医疗事件管理相关的资源，如就诊、住院诊疗过程等。

3.临床类（clinical）

临床类资源定义了医疗服务流程中所涉及的各类临床资源（表8-6）。包括诊断、临床观察、药物使用、检验、检查、手术和介入操作、精神生活和风险评估、各类医嘱和耗材等。

（1）临床类中的摘要（summary）子类：

包含了对患者病情、既往病史、手术等的总结。总结患者身份或病史的患者记录中的非过敏耐受、健康状况、手术过程通用资源（allergyintolerance，condition and procedure）；追溯患者亲属健康问题的家族史资源（familymemberhistory）；记录临床会诊、评估或检查所见等结论性的临床印象（clinicalimpression）等。

（2）临床类中的诊断（diagnostics）子类：

包含了与患者诊断有关的各类资源。其中，observation作为clinical资源类中唯一的一个正式版本的资源，用途极为广泛，从症状、体征、生命指征到实验室检查结果等，均可以用Observation资源作为数据的载体。

（3）临床类中的药物（medications）子类：

对各种临床用药和疫苗接种的场景提供了不同的FHIR资源支持。包括药物医嘱、药物发放、用药记录、药品记录、免疫接种记录、免疫接种推荐等。

（4）临床类中的疾病管理和健康照护（care provision）子类：

对疾病管理和健康照护相关的场景定义了不同的FHIR资源。包括：疾病或健康风险评估、护理和治疗计划、护理或康复目标，患者转诊、会诊申请，营养医嘱等资源。

（5）临床类中的请求和回复（request&response）子类：

覆盖了与医疗器械需求与提供、医疗耗材需求与提供，以及医患交流相关的资源。

4.保险支付类（financial）

包含了医疗保险、账单、支付及普遍性的保险支付类资源，如账户、收费明细、报销规定、保险计划等（表8-7）。

5.特殊类（specialized）

包含了针对特别场景和特定专业域的FHIR资源定义（表8-8）。如公共卫生和研究、医学定义、循证医学、医疗质量报告和测度、药品及药物作用相关的资源。

为便于理解，我们可以把资源想成是临床上使用的纸质表格，它定义了需要收集的临床和管理的信息，这些信息一旦收集起来，就可以进行分享。FHIR的资源为每一种临床信息定义了一个通用的表格模板，如过敏、药物处方各有自己的资源定义。FHIR数据可以被想成是一堆填好数值的表格（即资源实例）。资源实例描述了患者相关的信息（如人口学、疾病诊断和介入治疗等）和管理相关的信息（如主管医师、医院和就诊地理位置等）。每个FHIR资源都专注地定义了一个数据元素及相关数据元素，因此理论上讲，不同的FHIR资源可以相对独立地植入信息系统，快速实现基于FHIR标准的信息交换。

FHIR资源是信息交换中的基本单元，所有FHIR资源均拥有以下共同特征：URL形式的资源标识符、通用元数据、可读的摘要性描述、一组定义好通用数据元素，和支持医疗保健不同应用场景的扩展方法。FHIR资源可以用XML或JSON表示，目前的FHIR版本中（DSTU 2）共含有93个不同的资源类型，覆盖了临床、身份标识、工作流程、基础架构、标准符合性和财务领域。图8-16是JSON格式的FHIR患者资源的样例。

以图8-16实例作为说明案例，每一个FHIR资源包括如下内容。

1.resourceType（第2行）必备项，代表资源类型。

2.id（第3行）代表资源的标识符，一般在资源实例交换时出现，在资源实例创建时可以缺乏。

3.meta（第4行）可选项，一般都在资源实例中出现。

4.text（第5行）可选项，代表可供人阅读的内容，FHIR建议以XHTML格式予以表现。

5.extension（第6行）可选项，代表FHIR扩展框架所定义的扩展性资源。

6.data（第6行）可选项，代表资源类型定义的数据元素。

三、HL7 FHIR资源的交互

FHIR标准中对资源的操控是通过RESTful API支持的一组交互行为实现的。在RESTful框架中，交互直接通过HTTP请求或应答的服务器资源进行。API不直接处理验证、授权和查账征收，API将FHIR资源描述为一组操作（交互）资源，在这组操作资源中个体资源实例根据其类型被收集管理。服务器可以选择可用的交互资源，也可以选择它们所支持的资源类型。另外，服务器应提供指定支持的交互和资源的一致性申明。交互的定义为：VERB［base］/［type］/［id］｛？_format=［minetype］。

①“VERB”是交互的HTTP动词。②“［］”符号中的内容是强制性的，且将被字符串文字标识替换。③可能的插入值为base：URL服务根目录。④mime-type：mime：类型；type：资源类型名称（如“Patient”）。⑤id：资源的逻辑Id；vid：资源的版本Id。⑥compartment：区划名称。⑦parameters：定义为特定交互的URL参数。⑧“｛｝”符号中的内容是可选择的。

URL服务根目录是接口定义的所有资源的地址，URL服务根目录采用的形式是：http（s）：//server｛/path｝。path部分是可选择的，并不包含反斜杠。每种资源类型有一个位于/［type］（资源类型名称）处的管理器（或实体集），如Patient类型的资源管理器表示为：https：//server/path/Patient。另外每一个资源都有一系列相关的资源元数据元素映射向HTTP请求和响应。由上可知HTTPS是可选择的，但是医疗数据所有的生产交互都应该使用SSL以及适当的附加安全。FHIR还定义了一个OperationOutcome资源，用于确认特定的、详细的、可处理的错误信息。

FHIR资源正式的MIME类型是application/xml+fhir或application/json+fhir。正确的mime类型应该由客户端和服务器利用：XML：application/xml+fhir；JSON：application/json+fhir。然而未来支持各种实施限制，根据mime类型服务器应该支持可选择的_format参数以指定可选择的响应格式。作为_format参数、xml、text/xml、application/xml，以及 application/xml+fhir值应解释为FHIR定义的规范化XML格式。json、application/json及application/json+fhir值应解释为提供信息的JSON格式。另外应该允许html和text/html值的应用。对于所有的请求和响应体，FHIR采用UTF-8（表8-9、表8-10）。

具体的交互数据如表8-10所示。

除上述基本的交互行为外，FHIR标准还规定了RESTful API之外的其他交换方式，包括将一组资源组成文档或消息进行交换，或用其他形式的服务类型进行交换。

当然，在交互的过程中需要遵守一定的规则，批处理规则和事务处理规则。批处理和事务交互提交一系列行为，以在单个HTTP请求或响应的服务器上执行。作为批处理交互，不同条目之间不应该有相互依赖性，某一条目的成功或失败不应该改变其他资源内容的成败。服务器应该对这种情况进行验证。注意尽管处理顺序不应该影响已给的规则，但服务器会以同一顺序进行批处理操作作为规定的交易。作为事务处理，服务器会接受所有的行为并返回一个200型应答或拒绝所有的资源并返回一个HTTP 400或500型应答。如果提交的行为包中没有资源并不表示出现了错误，交互的结果并不是取决于交互中资源的顺序，一个资源只能在交互中出现一次。在事务处理中行为的处理有一个顺序：①处理任何删除（DELETE）交互；②处理任何后组式（POST）交互；③处理任何放置（PUT）交互；④处理任何获取（GET）交互。如果任何资源识别（包括从任何更新或删除条件中解决身份识别）重复1—3步，则交互失败。

四、HL7 FHIR标准总结

FHIR标准自2011年提出到现在走过了8年的时间。目前的版本（2018年12月）是Release 4（R4 正式版）。因为其采用了网络时代普遍应用的REST服务技术路线和资源，选择了开发人员熟悉的XML和JSON作为数据格式，在标准开发上遵循首先完成每个资源的基本数据属性及关系，实际应用中的特殊需要通过扩展机制予以支持的原则，并且强调标准的应用性，因此从一出现就得到了众多关注和大量的试验性应用。经过8年多的发展，以FHIR为基础的大量的医疗和移动医疗软件呈快速增长趋势，FHIR也不断走向成熟，2018年12月发布的FHIR R4正式版，为FHIR的广泛应用奠定了坚实的基础。

（李敬东）