This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Conformance Position on FHIR Versions

From HL7Wiki
Jump to navigation Jump to search

Background

FHIR is contemplating versions and how they should be managed at the resource level.

(Profiles can be versioned but this version is the version within the core FHIR version. This is really a history of the changes. )


General Observations

  • No simple solutions to this problem, restful services do not have an inherent solution
  • Versioning has not be thought about in FHIR in a consistent way
  • If the version is coded in the resource then there is a issue of knowing which version of FHIR to use to even parse the resource
  • Compatibility is directionaly dependent. (A different might be okay for receiving but not okay for the sender, and vice-versa.)
  • Expecting no changes is irrational.
  • Tooling is currently built around a single version but production systems must be able to support at least two versions, but in usually will need to support many more.
  • Persisting FHIR makes things difficult as well, the original version understood in the context will be lost once stored.
  • If a version can be encoded in a resource then it must be sent.

What is the reason for not having a version? There was a concern about technical errata. Small changes can cause communication issues.

  • Tracking versions has to be done even though it can be tedious

Idea about declaration between multiple resources. Compatibility declaration. Maybe there is a way to declare compatibility with multiple versions?

FHIR presents a new paradigm in comparison to HL7 v2 because the resource could be persisted. HL7 v2 messages were just to hold the data during transit.

What about major/minor versions? Might be hard to identify what is major vs minor. The FHIR standard is using a semantic versioning with three digits. FHIR is following this standard: [[1]] Here is more information on the history: [[2]]

The core issue is that resources can exist by themselves they can be separated from the profile that they were originally generated under.

  • If version was applied to meta data and this was applied to all Resources then all Data Types could have a version and this version could conflict with the version of the Resource that contains it.

Position

  • Somehow, someway there should be versioning. We don't have recommendation on how.
  • Recommending to put version in the standard Domain Resource meta data. Like to avoid sending version in data types.
  • Indicating version should be required.
Retrieved from "https://wiki.hl7.org/w/index.php?title=Conformance_Position_on_FHIR_Versions&oldid=138783"