FHIR 迁移和向后兼容性

Question

作为系统实施者，当我们从一个 FHIR 版本迁移到另一个版本时，我们会面临两难境地。我们开始使用 FHIR 0.0.81，然后于 2014 年 9 月 10 日移至 SVN 修订版 2833，以包含错误修复。按照建议，我们从 SVN 主干下载了 Java 代码，并按照FHIR Build Process page 上的说明进行操作。

FHIR 0.0.82 不兼容

现在 FHIR 0.0.82 已经可用，我们想升级到已发布的版本。然而，在下载 0.0.82 后，我们注意到主干 rev2833 中的一些资源（例如 Appointment）不在 0.0.82 版本中。这就引出了我们的第一个问题：

1. 如果主干不包含用于下一个版本的最新代码，它会包含什么？

2. 任何人都应该使用后备箱中的东西吗？

3. 是否有从中创建 0.0.82 的发布分支？

中继不兼容

由于我们的代码依赖于trunk上引入的资源，但0.0.82中不包含，我们必须继续直接从SVN签出FHIR。 2014 年 10 月 21 日，我们下载了 SVN 版本 3218 Java 代码。当我们将该代码集成到我们的系统中时，我们发现了许多兼容性问题。以下是其中一些：

1. 各种 Enum 值从小写变为大写，包括 Patient.AdministrativeGender 和 HumanName.NameUser。尽管遵循 Java 命名约定是个好主意，但更改基本数据类型会破坏编译。

2. 方法名称已更改，也会导致编译错误。我们还发现同时发生了名称更改。例如，在 HumanName 类中，旧的 setTextSimple(String) 现在是 setText(String)，而旧的 setText(StringType ) 现在是 setTextElement(StringType)。 setText() 的名称和参数类型都发生了变化，导致迁移容易出错，因为必须在每次使用时决定是更改方法还是更改其参数。

3. ResourceReference 资源类型已更改其类名。仅在 FHIR 模型包中，就有 61 个文件中的 859 个 ResourceReference 出现受到影响。这不包括影响其他 FHIR 包的更改，或影响我们的应用程序代码和数据库架构的更改。

4. 我们注意到 rev3218 主干代码中有几个新资源，包括 NewBundle。以前，我们建议捆绑包应该是资源，所以很高兴看到这种变化。但是，由于 trunk 不向后兼容 0.0.8x 版本，我不确定我们是否必须同时支持解析和组合 JSON 和 XML 包的新旧方式。

为了更好地说明问题，重要的是要认识到上述一些 FHIR 更改不仅会影响编译，而且很容易在运行时引入细微的错误。此外，FHIR 更改可能需要在某些应用程序中更改数据库架构和数据迁移。例如，我们的应用程序将 JSON 资源流保存在数据库中。将枚举值从“男性”更改为“男性”这样简单的事情需要更新现有数据库内容的迁移实用程序。

前进

我们正在大力投资 FHIR；我们希望它成功并作为标准被广泛采用。为了实现这一点，需要解决向后兼容性和版本迁移的问题。徒劳无功，任何可以阐明以下问题的信息都将推动我们前进：

1. 0.0.8x 行代码的目的是什么？它的目标用户是谁？

2. 主干代码的用途是什么？它的目标用户是谁？

3. 0.0.8x 的用户是否会迁移到主干代码库？

   1. 如果是这样，将使用什么迁移策略来解决代码库之间的许多不兼容问题？

4. 每个代码库中代码的弃用策略是什么？

5. 在主干代码的修订与修订之间可以预期到什么级别的向后兼容性？

6. 是否有 FHIR 路线图可供系统开发人员用来规划自己的开发周期？

谢谢， 富C

Answer 1

对于没有记录版本控制更多地影响 Java 参考实现的方式，我深表歉意。我会这样做的。我假设您熟悉这里的版本控制政策：http://hl7-fhir.github.io/history.html

目前有两个版本的 FHIR。第一个是 DSTU 1。这是 SVN（“dstu1”）中的一个分支，仅针对重要的错误报告进行更改。那里的参考实现得到维护并向后兼容。第二个版本是主干版本，我们正在为第二个 DSTU 版本做准备。 svn 目前非常不稳定 - 不断变化，我们有时会多次逆转变化，因为我们在委员会中考虑各种选项。此外，DSTU1 和主干之间有几个重大的重大变化，而且还会有更多变化。所以你不应该期望在 DSTU1 和中继之间切换会很轻松。实施者也不应该使用主干，除非他们真的是最前沿的（并且紧密连接，例如实施者的Skype频道）。当 trunk 稳定时，我们认为值得发布实施者测试版，我们会更新版本和版本历史，并在此处发布：http://hl7.org/implement/standards/FHIR-Develop/ 并为该版本发布 maven 包。

在trunk中，由于进行了很多更改，我们还将常量更改为大写，并翻转了get/set属性的生成方式。同意这是有代价的，但是从 DSTU1 切换到中继已经付出了代价。当我发布测试版（实际上很快）时，我将更新 Java 参考实现编号等等。请注意，Java 常量变为大写，但有线格式常量没有改变，因此存储的 json 流很好（尽管它们被规范中的许多其他更改破坏）

考虑到 DSTU 1 和主干之间的变化范围（目前还没有这些变化的列表，我必须在更新 Beta 版时做好准备），您应该期待为过渡进行大量返工。目前，我维护一个为两者实现服务器的单一源（在 Pascal 中，http://github.com/grahamegrieve/fhirserver），但我怀疑这种方法即将被 NewBundle 所代表的更改破坏。

所以，具体答案：

1. 0.0.8x 行代码的目的是什么？它的目标用户是谁？

支持现有 DSTU1 规范的用户

1. 主干代码的用途是什么？它的目标用户是谁？

准备成为 DSTU 2。它应该会在几周后开始变得更加稳定 - 一旦我们开始进行向后不兼容的更改，我们现在正努力完成尽可能多的更改

1. 是否会期望 0.0.8x 的用户迁移到主干代码库？

是的，当 DSTU 2 发布时，或者至少，当我们开始在为 DSTU2 准备的主干版本上进行连接马拉松时（第一个计划在 1 月进行）

4. 如果是这样，将使用什么迁移策略来解决代码库之间的许多不兼容问题？

将需要大量重写代码。当最终确定时，我们可能会发布用于将资源从 DSTU1 迁移到 DSTU2 的 xml 转换，但这甚至是不可能的

4a。每个代码库中代码的弃用政策是什么？

DSTU 1 非常保守。后备箱会稳定下来，但我们永远不会保证稳定性。 Beta 版本将是这些版本的时间点版本。

5. 在主干代码的修订与修订之间可以预期到什么级别的向后兼容性？

目前没有，真的。

6. 是否有 FHIR 路线图可供系统开发人员用来规划自己的开发周期？

嗯，除了上面提到的版本政策，还有这个：http://www.healthintersections.com.au/?p=2234（这是给你的，不是吗？）

Answer 2

作为对 Grahame 回复的补充：在规范的“文档”选项卡上，只有一个粗体链接 - Read Prior to Use。该页面试图说明 DSTU 版本既不保证向前也不向后兼容。它不能——DSTU 的全部目的是收集实施反馈，了解需要进行哪些实质性更改才能使标准在我们成为规范时准备好被锁定。如果我们承诺在 DSTU 中向前和向后兼容，那么无论我们在初稿中做出的决定是否正确，我们都会陷入困境。