Stream: implementers
Topic: Inter-version interoperability
AbdulMalik Shakir (Oct 28 2019 at 22:46):
I have a question regarding the ability for FHIR implementations based upon different FHIR releases, in particular, STU 3 and R4.
Are the following assumptions correct?:
- The profiles included in an IG must all be based upon the same version of FHIR
- Extensions and constraints can be used to bridge known gaps or inconsistencies between base resources in different versions of FHIR
- An implementation can draw from different IGs based upon different versions of FHIR and take advantage of defined extensions and constraints to bridge any gaps or inconsistencies in the different versions of FHIR.
- A FHIR server can support only one version of FHIR at a time.
- An implementer implementing multiple versions of FHIR will need to use multiple FHIR servers, at least one for each version.
These questions/assumptions are related to the BSeR IG. We have implementers interested in both the current balloted version of BSeR based upon FHIR STU3 and the next release of BSeR that will be based upon FHIR R4.
Grahame Grieve (Oct 28 2019 at 22:49):
- at present this is true as a tooling limitation but there's ways to work around that. in the future this will be resolved and an IG will be able to constrain multiple versions
- true.
- true if the developer is prepared to do the work
- not true - please read http://hl7.org/fhir/versioning.html
- also not true, depending on how you implement
Lloyd McKenzie (Oct 29 2019 at 03:23):
One thing that is true is that solutions supporting multiple versions for a single data repository will need to perform different mappings to convert between the versions they support and whatever their internal persistence layer looks like. In some cases, differences between FHIR releases for certain resources may make that challenging.
Last updated: Apr 12 2022 at 19:14 UTC
