Stream: implementers
Topic: Dealing with standard updates
Hugo Soares (Mar 17 2016 at 15:30):
Say you build a FHIR Server based on dstu2.
Has a FHIR early adopter these questions bug me:
- How would you deal with standard updates for dstu3 ?
- Is there something built-in to the standard that eases the upgrade?
- Will the process of moving between different standard versions always envolve a Client and Server migration?
Lloyd McKenzie (Mar 17 2016 at 17:37):
For right now, the answer is "we're still in the trial space" - so there's no guarantee of backward compatibility. And HL7 is constrained in what we can do in providing tools to ease migration by being a volunteer organization. Some of the reference implementation implementers are working to make support for multiple versions more straight-forward, but it's a fair bit of work. Because the versions will almost certainly not be backward compatible, joint migration of client and server would be necessary to move (though typically the server will choose to support multiple versions and the clients will migrate when they're ready - possibly encouraged by a sunset clause.
Lloyd McKenzie (Mar 17 2016 at 17:38):
Do note that as resources become more mature (see the FMM maturity levels), it becomes harder for HL7 to make non-backward compatible changes without the consent of the existing implementer community. That doesn't mean it can't happen, but it becomes less likely - and is more likely to be recognized as a "necessary cost".
Grahame Grieve (Mar 17 2016 at 18:21):
one thing to add: we anticipate that at some stage, we will start imposing basckwards compatibility rules on assets with a sufficiently high maturity model rating (>5), and then client and server will be able to evolve independently.
Last updated: Apr 12 2022 at 19:14 UTC
