Share this page:

file FHIR Profile versioning and version control

  • Posts: 84
3 years 10 months ago #6106 by Randy Nonay
Thanks all for the responses. Clears up things a bit :)

Please Log in or Create an account to join the conversation.

  • Posts: 15
3 years 10 months ago #6105 by Radhika Verma
Thanks Lloyd for your quick response!

Hi Randy,

As Lloyd mentioned, the version mentioned with the uri under meta.profile is the version of the structured definition of a specific profile.

In case of eReferral, the v1.0.0 is the version that corresponds to the current version of the Implementation Guide. This version may change as the spec (structured definitions or value sets) evolves with time. So, if in the future there is another evolved version of a profile this version will upgrade to say v1.0.1 or v1.1.0 (depending on the nature of change - major/minor)

The other version number (meta.versionId) is a 'server' assigned number.
Hope it helps!

Kindest,
Radhika

Please Log in or Create an account to join the conversation.

  • Posts: 169
3 years 10 months ago #6104 by Joel Francis
Hi Randy,

When using a profile, one would use the canonical URL of that profile in the meta.profile tag. But if the StructureDefinition being conformed to were to change over time one would need to specify a version that your resource would correspond to. Hence the e-referral steam elected to have the version in the URI. This means as the profile evolved, the URI would change with the corresponding version and one could easily tell looking at the resource URI which version of the StructureDefinition it was conforming to

The meta.versionid is used to give the resource being worked on context and not the profile that it is conforming to and is usually assigned by the server. The version in the URI is the implementer version and if there none present it means you are using the most up to date version or at least that is the understanding.

Thanks,

Joel

Please Log in or Create an account to join the conversation.

  • Posts: 132
3 years 10 months ago #6103 by Lloyd Mckenzie
meta.versionId indicates the server version for the resource you're looking at. Every time you update the resource, the versionId changes - and you may need to specify the versionId as an eTag when updating or deleting to prevent collisions. It is specific to the record on a single server. If an Observation is copied to a different server, it'll get a distinct id and will have a distinct 'version' history - reflecting the creates and updates on *that* server.

The version referenced in a canonical URL is something different. It corresponds to the StructureDefinition.version, ValueSet.version, etc. The 'version' element appears only on infrastructure and other knowledge resources. It represents the "business version" or "release" of the resource. For example the "2019A" release of a profile. That profile release might be updated multiple times (with distinct meta.versionIds for each version in the resource history), but would still have the same ValueSet.version. You might also have multiple resource instances (each with their own history) that share the same canonical URL that live on a given server. For example, a registry might host the the 2019A release, the 2019B release and the 2020 release of the same profile - and all of those could potentially get updated - to make technical corrections, to revise status (e.g. 2019A gets deprecated and 2020 gets changed from draft to active). And multiple servers might have a copy of the 2019A release of the value set.

When you reference a resource by canonical URL (as happens with meta.profile, but also lots of other places), you have the option of specifying a particular business version. If you don't, then the presumption is the 'current' business version, though it's not always obvious which version is 'current' given that there's no mandatory scheme for business version.

Please Log in or Create an account to join the conversation.

  • Posts: 84
3 years 10 months ago #6102 by Randy Nonay
Hi,

I'm looking to get some feedback on profile versioning.

I notice in the Ontario eReferral FHIR spec, the verion for various profiles and resources seems to be included in the URI, for example:
For Messageheader, meta.profile = ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-MessageHeader|1.0.0

But looking at FHIR specifications, it typically is included in the meta.versionId element. So the above would be expressed as:
meta.profile = "ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-MessageHeader"
meta.versionId="1.0.0"

Which way is the recommended approach for FHIR?
Thanks for any tips!

Randy

Please Log in or Create an account to join the conversation.

InfoCentral logo

Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.