Service versioning of the fhir services


We have implemented lot of resources like Patient, Procedure, Medication Order and many others … and these services being common are consumed by multiple development projects in our organization. Currently we have one release schedule and are maintaining one library or version of the code for services in production. Off late we have seen a demand in usage of the FHIR resources we have built and there are multiple requirements to enhance the resources from various projects. Each of these projects have a different release schedule and we see a need that we need some kind of version controlling mechanism of web services where we have multiple versions of the services made available so the applications using them are isolated. One layman approach is to have different version of the code deployed on the servers with different URL’s which would bring up issues in merging code after releases, retest for regression and duplication of code.
Is there a cleaner way to implement version controlling so as FHIR service developers we concentrate on developing the functionality and release them in versions so the consumer applications can pick and choose the version they are compliant with. We are looking for some dynamic solution like identifying the version to be picked in the url by appending a “/v1” may be…

Any best practices/tools available for api management followed in the industry, innovative approaches are welcome…

Ravi Kuchi

The FHIR spec itself says nothing about this. You’ve mentioned the 2 approaches that most implementers take (e.g. and vs and But the way version surfaces on the API is separate to how you manage the code (e.g. all my servers are compiled from the same code base)