A recent post from the FHIR Product Director Grahame Grieve has announced that Release 3 of FHIR has been published, and is now available at hl7.org/FHIR. What does this mean, and what’s the impact on you?
To understand this, let’s take a step back and think about where has FHIR has come from.
Born out of frustration with how standards development was proceeding; from the very beginning FHIR has been focused on the needs of the implementer. This is addressed in a number of ways: from the use of common technologies, keeping the core artifacts (resources) small and understandable, to providing an easy to understand profiling mechanism to adapt them – but most importantly the encouragement (even nurturing) of a community around it.
It is this community that is the most potent part of FHIR. Rather than a single organization (however experienced) developing a standard for use by implementers, it has been developed from the very beginning by the community that is actually using it. Grahame put it succinctly in the blog referred to above:
“the FHIR specification is very much the living record of the community of users who share the experience of trying to solve problems with it”
One of the impacts of this collaboration is that the specification is continually enhanced and extended as a result of real implementer experience – people come across a problem, the community proposes an enhancement that solves it, and the specification is updated. New requirements are identified (Decision Support, Clinical Quality Measures, WorkFlow, Terminology) and the specification is then extended to include them.
However, there is a potential problem with this approach – how can you develop against a specification that is always changing? The solution (at least in the case of FHIR) is to have periodic ‘waypoints’ – fixed versions of the specification that remain unchanged, and against which implementers can develop and deploy with confidence. These have been called DSTU (Draft Standard for Trial Use) or STU (Standard for Trial Use) in the past, but now are simply referred to as a Release to reflect that it is fit for real use.
There’s a lot of process (and a huge amount of work) around determining what goes into these fixed versions, and each one is more complete – with content less likely to change – than the previous one.
That last point – less likely to change – is worth calling out. One of the consequences of continually refining something is that they can, and do change! Indeed, HL7 has been very explicit that at this stage of development, resources and other artifacts WILL change, and potentially in a way that ‘breaks’ systems using older versions.
This raises the obvious question: Should you wait until it is finished? That could work if you don’t need to share any information right now (or get it from someone else) but if you do need to interoperate, then waiting is not an option. You could develop your own specification, and try to persuade others to use it (good luck with that!), but at some point you are going to have to change. By joining the community now, and taking advantage of all the knowledge that has gone into FHIR you will minimize the impact of that change. You will also be helping to make the specification better!
To help with this, each resource has a ‘maturity level’ associated it that reflects how much it has been ‘exercised’ by the community. The higher the number the more it has been used ‘in the field’ so the greater the confidence that we have got it right. At some time (likely the next release) we’ll see some of the resources become ‘normative’ which means that any change to them will be ‘backwards compatible’ – whatever changes may be made to them in the future won’t stop an application being able to use them.
So the fact that FHIR is now at the 3rd release, that the scope continues to expand, and that a number of the resources now have a high maturity level reflects just how much work has gone into it, how good it has become at representing ‘real world’ concepts, and how close it is to the point where new releases won’t ‘break’ older ones.
If your business is healthcare interoperability, there isn’t really any better option.