As the HL7® Fast Healthcare Interoperability Resources (FHIR®) community grows, an increasing volume of FHIR information and a ballooning community of self-appointed FHIR experts are bursting onto the scene. This is a welcome sign of the emergence of a robust FHIR ecosystem, and we celebrate that.
Health IT is hard; as a technical domain, its complexity matches healthcare’s enormous size as an economic force. Because FHIR allows for exchanging just the data needed for a specific purpose, it makes exchanging healthcare data “easier” than the earlier interoperability standards. But note the quotes around the word easier. I didn’t say “easy,” because few things in healthcare are easy, and we are talking about our lives here. We must get it right.
In many ways, FHIR is a huge improvement, but it cannot change the fact that there are thousands of ways to combine hundreds of clinical data elements, and practitioners in one specialty need that data in a way that matches their clinical needs, whereas the same data needs to be packaged up for another clinical use case in a different way. The combinatorial explosion of granular FHIR payloads makes grokking FHIR much harder than just throwing a bloated CDA document over the wire as currently happens each day.
That tradeoff (smaller payloads, less clinical noise, and far less data over the wire–but more implementation complexity), is why FHIR is gaining so much traction. We would all like for it to be easier–and there are hundreds of the best minds in the world working hard to make that happen–but we aren’t there yet. Healthcare is complex.
Signal vs. Noise
Needing to filter out distracting noise from the valuable signal is an expected companion of the emerging FHIR ecosystem, and that need is becoming more obvious with each passing day. One could argue (correctly) that we are just now starting to see some FHIR adoption momentum building, so worrying about some noise is not a top priority. This is certainly true for us grizzled veterans of the FHIR community; we already know how to recognize the signal, and we have the scars to prove it.
FHIR newcomers, however, need that filtering–especially if we want their welcome to be productive and enjoyable.
Ask the Testers; They Have to Know
If you have worked on huge software systems, you have probably noticed that as the level of complexity grows, stakeholders increasingly turn to the testing team to understand how the system is really supposed to work. This isn’t because testers are inherently geniuses (although I have known some who are); it’s because to effectively test a system, you have to know it. All of it. Cold.
Of course, smart teams automate as much testing as possible, but building that automation (and validating it) requires the same insanely deep level of knowledge. This is why so many stakeholders discover and use the superpower of “go ask the testing team.”
I know what you are thinking:
“So how does this help me if I’m a newcomer to FHIR?”
The answer is:
“Ask to see the testing results.”
Wondering how the implementation of a FHIR IG is supposed to work? Ask for the testing results. If you get blank stares in return, you have just encountered noise. Keep looking for the signal.
Introducing our “FHIR Starter” Series
AEGIS.net is the team behind Touchstone, the leading FHIR testing platform to objectively measure whether FHIR implementations are conformant to the underlying FHIR specifications.
We’re the team who has to know how FHIR is supposed to work.
If you are new to the FHIR scene, we are writing this series of articles for you so that you can easily recognize the FHIR signal and filter the cacophony of noise.
Here is the evolving table of contents. Each entry will become a link as that article becomes available:
- Series introduction (this article).
- Key FHIR Concepts/”Hello World” Implementation Teaser
- About all those FHIR Implementation Guides (IGs)
- Implementation Foundational Choices
- Realistic Expectations for FHIR Initiatives
- (more TBD)
We won’t be inventing any new information in these articles, but we will be occasionally sharing our recommendations based on the testing results we have seen with hundreds of FHIR implementations and millions of transactions evaluated.
We will provide references to source materials (core FHIR specifications and FHIR IGs), and–most importantly–we will provide testing results as objective evidence that you can trust the information we are sharing.
One thought on “FHIR Starter #1”