By Dr. David Hay, Product Strategist, Orion Health
Twitter:Â @OrionHealth
FHIR® or Fast Healthcare Interoperability Resources is an IT healthcare standard that will help to improve the day to day running of community medical practices and hospitals. FHIR can contribute to improving care of patients by providing timely access to their electronic healthcare record.
FHIR is one of the next generation HL7® standards in healthcare data integration, and is focused on decreasing interoperability costs, and unlocking technical innovation in healthcare. FHIR aims to speed application development and interoperability, plus boost information sharing in healthcare, especially on mobile platforms.
One of the features about FHIR is the way that the core specification can be adapted to suit the needs of a specific scenario – a process termed ‘profiling’.
In a way that is similar to HL7 version 2 (though much better controlled), FHIR defines a core set of elements for each resource, but makes it possible to add elements to the core resources to represent the specific items that are not defined by the specification. An example of this in New Zealand is the desire to add the tribal affiliations of the local Maori population – Hapu and Iwi – to the core ‘Patient’ resource. These additions are called ‘extensions’.
But where FHIR differs from HL7 version 2 is that there is a specific process to be followed in doing so, a process that ensures that the meaning of these additions can be understood by any recipient, and which supports the ability to re-use extensions where that makes sense, thus enhancing interoperability.
This process involves creating an ‘Extension Definition’ (technically a StructureDefinition resource) that describes in detail what an extension actually means. This definition is then referenced by an actual instance of the resource so that a recipient can easily find it – just by using their browser.
There are a number of things to think about when creating an extension definition, below are posts that discuss these in more detail:
- In the first post, we discuss the overall process in defining the extension definition.
- Next up, we think about the URL of the extension definition – where are we going to place it so that recipients can find it.
- And finally we describe some of the specific issues needed for coded datatypes.
However, one of the issues that early FHIR adopters face is how to deal with the different FHIR versions – especially when it comes to these ‘conformance’ resources such as a ValueSet or a StructureDefinition (used both in profiles and extension definitions). As described in the posts referenced above, these resources have a URL property that is a ‘canonical’ URL – it is globally unique and is used when the resource needs to be referenced by others – as when a profile needs to refer to an extension definition, or a coded element to the ValueSet that defines the potential values for it. We don’t want to have to change the URL when the FHIR version changes, but we do need to be able to host instances of the resource that are specific to the FHIR version.
One solution is to use a non-version specific URL as the canonical URL, and then use an HTTP ‘redirect’ to go from the version specific to the non-specific version. For example, if the Valueset URL was http://moh.govt.nz/fhir/ValueSet/iwi-1 (New Zealand Iwi’s) then we could host an STU2 version at http://moh.govt.nz/fhir/stu2/ValueSet/iwi-1, and have a redirect from http://moh.govt.nz/fhir/ValueSet/iwi-1 to that end point. Then when we released an STU3 version of the ValueSet, we could host it at http://moh.govt.nz/fhir/stu3/ValueSet/iwi-1, and change the http://moh.govt.nz/fhir/ValueSet/iwi-1 redirect to the new endpoint.
In that way, both versions remain available, yet the canonical version will always point to the most recent one. This does have the downside that if the redirect is changed, then a consumer will receive a different version to the one they are expecting and so could ‘break’. There’s no simple answer to this until the spec goes normative, and backwards compatibility is guaranteed – and a redirect becomes meaningless. Mitigations include not changing the redirect (and leaving it at the previous version) or requiring the client to always check the version (which is probably wise regardless).
A better alternative is the use of registries – effectively repositories of these conformance resources indexed by URL. When a client wishes to retrieve a referenced resource, they query the registry for that resource using the canonical URL, rather than resolving the link directly. The registry could expose its search at version specific endpoints, thus allowing the client to specify the version they require.
To learn more read this post where we examine this proposal in more detail and discuss ‘business versions’ of these resources.
This article was originally published on Orion Health and is republished here with permission.