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.
Access all of our FHIR Resources.
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.
For further reading:
- What Piqued Our Interest at FHIR Dev Days 2020
- What the Heck Is a Connectathon?
- DaVinci Project Aims to Boost Payer-Provider Interoperability
®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.
