2.2 FHIR版本管理策略
2.2.1 FHIR标准制定过程
FHIR标准在不断地发展和迭代，本节主要介绍HL7标准的制定流程。
HL7标准生成过程有五个不同的阶段，不同阶段的稳定性和完成度不同。各阶段如下：
草案阶段：不完整或者还没有经过审查的内容。
存在明显问题或仍处于“开发”阶段。它作为占位符会包含在出版物中，以征求社区的反馈或让实施者对可能包含在未来版本中的功能有一些了解。有兴趣的实施者可以进行尝试，自担风险。草案阶段的内容在经过投票、审核和更正后，会提升至试用阶段。
试用阶段：该内容已经过充分审查，被认定可以在生产系统中使用。
它已经通过投票并被批准为官方标准，但是还没有在生产环境中实际使用过，FHIR的未来版本可能不兼容试用阶段版本的内容，存在可能进行重大更改的风险，而且会存在一些偶发性的问题，但是有实施经验的人能够解决这些问题。
规范阶段：此内容已在各种生产环境中进行审查和实施。内容是稳定且被确定受FHIR版本间兼容性规则的约束。
成熟阶段：此阶段内容会提供典型示例目录、注册表、示例和实施者建议信息。
作废阶段：规范的这一部分已经过时，可能会在未来的版本中作废，实施者后续需避免使用。
2.2.2 FHIR成熟度等级
FHIR规范v4.0.1给所有制品（artifact）都分配了一个“成熟度级别”，称为FMM（以著名的CMM等级命名）。我们可以使用FMM级别来判断制品的先进程度，并作为其稳定性的依据。FMM级别定义如下：
| 草案 (0) | 资源或规程（制品）已在当前编译中发布，单制品依然存在问题或仍处于“开发”阶段。 |
|---|---|
| FMM1 | 工作组认为该制品已基本完成并已准备好实施。对于资源、规程和实施指南，FHIR管理组已批准基础资源/配置文件/IG的提案。 |
| FMM2 | PLUS制品已成功测试和支持至少三个独立开发的系统之间的互操作性支持大部分的数据范围(至少80%的核心数据元素)使用和业务场景内的数据交互。这些互操作性结果必须已报告给FMG并被FMG接受。 |
| FMM3 | PLUS+制品已被工作组验证为符合一致性资源质量指南；经过一轮正式投票；在跟踪器中记录了至少10条不同的实施者评论，这些评论来自至少3个组织，导致至少一个实质性变化。 |
| FMM4 | 此外，制品已经在其范围内进行了测试，在正式出版物中发布（例如Trial-Use），并在多个原型项目中实现。同样，负责的工作组保障制品足够稳定，需要实施者咨询后续非向后兼容的更改。 |
| FMM5 | 该制品已在FMM1+（即试用级别）的两个正式发布的发布周期中发布，并已在一个以上国家/地区的至少5个独立生产系统中实施。 |
| 规范性 | 该制品目前为止被认为是稳定的。 |
成熟度水平与稳定性密切相关；成熟度级别越高，执行的控制就越多，以限制对资源的重大更改。
示例：针对FHIR v4.0.1版本包含资源中，提供了按照成熟度等级的分类。
其中，“患者”资源（Patient）成熟度等级是N，“消息头”资源（MessageHeader）成熟度等级是4级等。
2.2.3 FHIR版本和版本控制
（1）FHIR版本发布周期
FHIR的版本发布周期大约在18-24个月之间，此周期主要基于与实施者协商、开发和审查新内容、正式投票和协调所需的时间，以及将早期版本的实施者反馈合并到后续版本中。有时为了满足实施者的需要，可能会在较短的时间内发布有限范围的版本。
FHIR有一个单一的开发版本，遵循HL7管理的开发周期。每个主要的开发周期都通过多次正式投票结束，然后发布新的规范。在版本控制方面，每个发布的规范都是开发主干的一个分支，随着HL7维护发布的规范，它本身可能会发生进一步的变化，不过一般仅限于必要的技术更正或安全修复。
（2）FHIR版本说明
FHIR的每个新版本发布都会分配有一个唯一的版本号。每个FHIR版本都是一个由4部分组成的字符串标识，即：发布版本、主要版本、次要版本、修订版本（publication.major.minor.revision）。
| 发布版本 | 当 HL7对FHIR更新的规范发布时增加，例如 FHIR 的试用版本或正式版本 第一次试用对应的发布版本是0 FHIR试用版本(试行标准草案，DSTU)第二次发布是1 FHIR试用版本(试行标准草案，DSTU)第三次发布是3（根据实施者的要求跳过“2”以对齐主要数字） |
|---|---|
| 主要版本 | 每次进行重大更改时递增 当新的发布版本产生时，它在发布中重置为0，在开发分支中重置为 1 由于HL7不会将重大更改作为对已发布规范的技术更正，因此这些FHIR版本始终具有版本号 X.0.n.r 由于开发版本是持续分析、辩论、投票和反复修改的主题，试行标准（STU） 内容预计会发生重大变化 |
| 次要版本 | 每次生成包含一个或多个实质性更改的官方快照版本时递增 每当主要版本更改时重置为 0 快照版本在年度HL7工作组会议（及其相关联的connectathon测试大会）之前大约6周生成，但它们也可以为其它主要connectathon测试大会或满足实施者要求生成。 |
| 修订版本 | 构建规范的GIT版本的哈希值，用于跟踪发布或工具问题 对于当前构建，每天进行多次更改，通常由实施社区提交的更改请求驱动 出版物修订号仅在进行技术更正时发生变化 |
2.2.4 如何识别多个版本
对规范的持续更改意味着实施者必须能够确定在他们的上下文中使用哪个版本并相应地实施。有 3 种方法可以确定正在使用的 FHIR 版本：
- 适用能力声明CapabilityStatement中的fhirVersion元素
- 适用于资源的MIME类型的fhirVersion参数
- 在资源本身上指定版本的配置文件
（1）能力声明中的fhirVersion元素
FHIR版本适用于整个交互，而不仅仅是资源。mime类型的语义、RESTful URL、搜索参数和整体交互都绑定到特定的FHIR版本。资源版本必须与整体交互一致。如果没有先就版本达成一致，客户端/服务器（或者，对于消息传递，发送方/接收方）不可能进行连贯的对话。交互的版本在CapabilityStatement资源中指定。
（2）Mime类型参数
处理FHIR版本之间变化的常见策略是对不同版本使用不同的端点。例如 http://acme.com/fhir/r2 和 http://acme.com/fhir/r3 。但是，这意味着同一记录具有不同的身份。如果客户端使用fhirVersion mime 类型参数指定要支持的版本，则服务器可以在同一端点上支持多个版本：
GET [基础]/元数据
接受：application/fhir+json；fhirVersion=3.0
这是一个返回CapabilityStatement的请求。如果返回错误，或者返回的功能语句具有不同的fhirVersion (这意味着服务器不支持 fhirVersion 参数）。
（3）资源的版本配置文件
在某些情况下，应用程序可能会处理没有携带mimetype版本参数的资源。
当没有其它选择时，读取资源的应用程序必须扫描资源以确定版本，然后将资源读取为正确的版本。
{ "resourceType" : "病人",
“元”：{
“个人资料”：[“http://hl7.org/fhir/3.0/StructureDefinition/Patient”]
}
}
2.2.5 版本之间的变更原则
版本的更新规则目的是确保符合现有规范的应用程序也符合后续版本。变量的类型主要有：
- 重大变更 是指先前符合要求的应用程序不再符合更新的规范的更改；
- 实质性变更 是引入新功能的更改 - 更改规范以创建新功能 - 但不会使未更改的现有应用程序不符合要求；
- 非实质性变更 不应导致任何符合要求的应用程序发生更改。例如，部分重新编号、更正断开的链接、更改样式、修复拼写错误以及提供不改变规范含义的说明。此外，这包括被判断为不会对合规应用程序产生任何更改预期的更正。
处于草案或试用状态的内容可能会因版本而异，但须遵守“成熟度等级”中描述的规则。一旦制品达到规范状态，特定规则就会围绕版本间兼容性发挥作用。这些规则具有向前和向后兼容性，旨在允许实现在使用不同版本的FHIR 的系统之间交换数据时，使用FHIR接口并安全地处理FHIR资源的内容。
- 向前兼容性
向前兼容性意味着与旧版本一致的内容将与未来版本保持一致。一旦成为规范，FHIR的规则就会尝试强制执行前向兼容性。但是，这并不能保证所有旧系统都能与未来系统实现互操作。
- 向后兼容性
向后兼容性意味着未来版本创建的实例能与已有版本实现互操作。系统遵循一些策略，以增加实现互操作性的概率。当处理来自未知规范版本系统的内容，并希望最大限度地向后兼容时，应用程序应该：
- 忽略意外的元素（新元素永远不会是修饰元素）；
- 忽略对无法识别的资源的引用；
- 忽略必需和可扩展绑定中无法识别的代码，除非它们出现的元素是修饰符；
- 忽略无法识别的搜索条件；
- 使用适当的错误代码响应对意外URL的HTTP命令。
- 兼容规则示例
FHIR核心规范或HL7国际发布的实施指南中的制品成为规范以后，所有的变更都必须遵从兼容性规则。以下为部分规则示例：
| 类别 | 允许的更改 |
|---|---|
| 资源 | 可能会引入新的制品资源。现有资源的名称不会更改 |
| 制品（资源、配置文件、代码系统等） | 可能会引入新的制品，包括新的资源和数据类型。现有制品不会更改任何可计算的标识符（例如资源名称）。制品可能会被弃用 |
| 元素 | 可以在资源和数据类型结构中的任何位置引入新的可选元素和/或内容（例如 XML 属性等），前提是它们不构成“isModifier”元素。但是，以前存在的数据元素的名称、路径和含义不会改变。这意味着资源名称不会更改，分配给配置文件中的切片和其他元素的名称也不会更改。 |
| 基数 | 最小元素基数不会改变。仅在可以安全忽略除第一次重复之外的所有元素的情况下，上基数可能会从 1 更改为 * 。请注意，这可能会更改某些语法（例如 JSON）中元素的路径。这可能意味着为重复项目分配了一个顺序，或者没有关于保留哪个元素的偏好。对于意外元素，系统应遵循上述规则。 |
| 值集和代码系统 | 对于非不可变值集： 具有枚举代码列表并具有“固定”绑定的值集可能会引入其他代码，但永远不会删除代码，尽管它们可能已被弃用。 使用过滤器的值集可能会放松或收紧过滤器以适应对底层代码系统的更改。可以调整 StableDates 和引用的代码系统和值集版本以指向较新的版本。 代码的定义和显示值可能会改变，但不会改变对使用先前定义或名称捕获的数据的合理解释。 抽象代码可以具体化。具体代码不会抽象。 |
| 数据类型 | 不会删除数据类型，可能会引入新的数据类型。在现有元素上声明的类型不会被删除或更改，除非特殊情况string可以更改为markdown。仅当这些元素是可选的（最小基数=0）时，才可以将其他数据类型添加到已经表示为数据类型选择的元素。 |
2.2.6 查看版本变更内容
自2014年9月30日发布DSTU1（试用标准草案初稿）之后，主要的版本如下表所示：
| 2014年9月30日 | 0.0.82 | DSTU1（试用标准草案初稿） |
|---|---|---|
| 2015年10月24日 | 1.0.0 | DSTU2（试行标准草案第二稿） |
| 2017年2月21日 | 3.0.0 | 第 3 版（STU - 试用标准） |
| 2018年12月27日 | 4.0.0 | 第 4 版（第 1 版规范内容 + 试用开发） |
我们可以通过FHIR发展历程 查看自DSTU1之后不同版本之间的主要差异。如果想了解更详细的信息以及所有内容的历史变更记录，则可以访问HL7 GitHub
2.2.7 资源的跨版本转换
许多实现需要将资源从一个FHIR版本转换为另一个版本。一旦资源变得成熟、稳定，就不需要从过去的版本向前转换资源。然而，转换回旧版本带来了挑战，因为新版本可能会添加旧版本中不存在的其它元素。
尚未稳定的资源会出现更复杂的问题。如果应用程序使用了不太稳定的资源，它们不仅存在新需求的新元素问题，还可能会以兼容或不兼容的方式发生变化，并且可能需要将过去版本的数据元素向前传递以允许无缝往返。
为了帮助实施者解决这个问题，在任何FHIR版本中定义的任何元素都会自动分配一个扩展URL，该URL唯一标识该元素并且可以在相关FHIR版本中使用。可以自动派生元素的扩展 URL：
http://hl7.org/fhir/[version]/StructureDefinition/extension-[路径]
其中[version]来自：
| FHIR DSTU2 | 1.0 |
|---|---|
| FHIR R3 (STU3, 或R3) | 3.0 |
| FHIR R4（此版本） | 4.0 |
此方法可用于所有版本的FHIR，请注意，此扩展框架仅适用于DSTU2及之后的版本。[Path] 实际上是元素的相关 StructureDefinition中的ElementDefinition.id，例如以下URL：
http://hl7.org/fhir/4.0/StructureDefinition/extension-Bundle.signature
http://hl7.org/fhir/3.0/StructureDefinition/extension-Patient.animal.species
http://hl7.org/fhir/1.0/StructureDefinition/extension-ValueSet.extensible
2.2.8 未来版本的发布计划
在规范版本实施的同时，下一个版本的开发将继续进行。下一个版本将根据实施经验和正在进行的开发工作，在当前版本的基础上提供额外的说明、资源、配置文件和质量提升。它还将包含对FHIR问题跟踪器提出的问题的修复。
FHIR的下一个主要出版物将是第5版。第5版将包括更多的规范性内容，包括更多的临床内容。而临床知识/推理、护理计划和财务资源，可能会依然保持在试用级别。
在可预见的未来，将会有更多的FHIR版本发布，频率在18到24个月之间。HL7将继续专注于通过发布实施指南和简介来提供额外的指导，以便在国际层面达成共识。
（撰写人：薛颜波）