David Hay on FHIR® Standards
In my self-appointed role as 'FHIR® evangelist' (some would say 'FHIR® Fanatic') at Rhapsody and HL7® New Zealand I'm often asked 'what is FHIR®, and why should I care?'
Rather than trying to explain each time, I'm going to write a short post here, so I can refer people to it, rather than trying to remember all the good points at the time.
So, what is FHIR®?
- FHIR® (Fast Health Interoperability Resources) is the latest interoperability standard from HL7®, following on from Version 3. (Strictly speaking it builds on rather than replacing v3, but also pulls in ideas from other organizations such as openEHR or IHE).
- FHIR® has the fundamental concept of “Resources”, where a resource is the basic unit of interoperability – the smallest 'thing' that makes sense to talk about – such as a Patient, a Condition (Problem) or a Practitioner.
- Resources have a number of common characteristics, including:
- A small number of 'core' properties that most (80%) of systems currently support. Each property is a specific data type (although some resources allow more than one datatype to be used for a property)
- A standard extension mechanism that allows implementers to add new properties in a safe and discoverable way. (This is the lesson of version 2)
- An 'identity' by which it can be saved, located & retrieved
- A human readable component that summarizes the data in the resource for a human to read (This is the lesson of CDA).
- Resources can be re-used across interoperability paradigms. You could receive (or save) a resource via a REST service, and then package it in a Message or include it in a Document.
- There is a built in versioning system. Each resource can have multiple versions, and there are mechanisms to retrieve the history of a specific resource, and/or a specific version.
- The specification itself is on-line, and fully hyperlinked. You can link through from resource, to a property, to the datatype of that property. Where a particular terminology or code set has been defined for a property, you can hyperlink to that dataset. (Terminologies are a bit more tricky to link to).
Why should you care?
- FHIR® has been built with the needs of the Implementer in mind. We try to be as simple as possible, but no simpler.
- This extends to the use of connectathons, where developers can try out ideas before being included in the specification.
- Standard tooling can be used.
- You can use XML or JSON representation. Each resource has a specific validation schema / schematron (again, a lesson from CDA)
- All the artifacts (including the schema) are automatically built using a build process (similar to a software build). This significantly improves the overall quality of the specification.
- Each resource has multiple examples that show how the resource can be used. The resources themselves are 'round-tripped' from XML -> JSON ->XML and validated as part of the build process to ensure accuracy.
- FHIR® (especially the JSON representation) is great for mobile development There are a number of open-source clients to make it even easier to use
- There are also some test servers to test your work out on.
- Lots of other people are looking very closely at FHIR®
Well, I hope I've answered the question, and you can follow my blog here if you want to learn more about FHIR®.
®Health Level Seven, HL7, FHIR and the FHIR [FLAME DESIGN] are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. The use of these trademarks does not reflect HL7's endorsement.