FHIR Profile versioning and version control
- Randy Nonay
- Topic Author
- Offline
- Posts: 85
4 years 4 months ago #6106
by Randy Nonay
Replied by Randy Nonay on topic FHIR Profile versioning and version control
Thanks all for the responses. Clears up things a bit
Please Log in or Create an account to join the conversation.
- Radhika Verma
- Offline
- Posts: 15
4 years 4 months ago #6105
by Radhika Verma
Replied by Radhika Verma on topic FHIR Profile versioning and version control
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
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.
- Joel Francis
- Offline
- Posts: 169
4 years 4 months ago #6104
by Joel Francis
Replied by Joel Francis on topic FHIR Profile versioning and version control
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
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.
- Lloyd Mckenzie
- Offline
- Posts: 132
4 years 4 months ago #6103
by Lloyd Mckenzie
Replied by Lloyd Mckenzie on topic FHIR Profile versioning and version control
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.
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.
- Randy Nonay
- Topic Author
- Offline
- Posts: 85
4 years 4 months ago #6102
by Randy Nonay
FHIR Profile versioning and version control was created 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
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.