Stream: implementers
Topic: How to distinguish pacakge versions in API?
Pieter Edelman (Jan 10 2020 at 11:45):
Our Nictiz FHIR materials are currently published as a single big FHIR package, containing conformance resource both for specific information standards (use cases like medication process, self measurments, gp data, etc.) as well as for their common core. However, we're would like to split out the information standards in separate packages, which then depend on a single "base package". This can be very elegantly achieved using the FHIR packaging mechanism and would allow for different release cycles for different standards, where some of the information standards depend on the newest version of the base package while others can be kept at an older version until there is need and/or a suited time slot for upgrading.
However, it's unclear to me how to deal with these different versions in the API.
Suppose for example that I have a FHIR server which implements two different information standards, let's call them A and B. Both of their packages have a dependency on the same base package, but standard A requires version 1 while standard B requires version 2. And suppose the Patient profile in version 1 is not compatible with version 2 of the base package. How can a FHIR client that interacts with the server negotiate the version of the Patient profile to use? Is there a way for the client to ask for a specific version? And is there a way for the server to know what version to serve?
I've seen several threads on this topic, but as of yet no clear guidance emerges.
Grahame Grieve (Jan 10 2020 at 11:56):
that's because there is no clear guidance possible. A server cannot server 2 incompatible views of the same data with coherence in any general case. Only by careful and lucky coding on a per case basis
Last updated: Apr 12 2022 at 19:14 UTC
