Faites-nous part de vos impressions sur le Serveur terminologique, et aidez-nous à améliorer nos services! Vous avez jusqu’au 3 décembre 2024 pour répondre au sondage. Votre avis nous intéresse! En savoir plus >

Partager :

file FHIR Profile versioning and version control

  • Messages : 85
il y a 4 ans 4 mois #6106 par Randy Nonay
Thanks all for the responses. Clears up things a bit :)

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 15
il y a 4 ans 4 mois #6105 par 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

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 169
il y a 4 ans 4 mois #6104 par 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

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 132
il y a 4 ans 4 mois #6103 par 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.

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 85
il y a 4 ans 4 mois #6102 par 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

Connexion ou Créer un compte pour participer à la conversation.

Logo d'InfoCentral

La santé numérique à votre service

 

Transformer les soins de santé au Canada grâce aux technologies de l'information sur la santé.