FHIR IGs: The “G” is for GUIDE. So let’s do that!

Are we really publishing guides for implementation?

If we want to buy a newly built house, we have a few options. The most common is choosing a standard floor plan from a community of houses being built by a mass-production builder. “Mass-production” means “build a few configurations (plans) many times to make each build most cost-effective.” This is why buying a new home from a mass-production builder costs less; they already know how to build each floor plan, because they have done it many times, so they can offer a better price.

Custom home builders, on the other hand, specialize in building many different floor plans, but fewer times each. They (and their crews) have to climb a steep learning curve for each project, so it takes longer, and that additional time translates into higher costs. A big part of that cost is financial risk; there is a much greater risk of unforeseen costs and the need for rework when building something unfamiliar. Custom homes can cost two to five times more than production homes for the same size house. Ouch!

Custom home builders reduce this risk by relying on detailed architectural guidance. The blueprints (house plans) specify what to build, and it takes some construction domain expertise to read them.

The architectural guidance, in contrast, describes how to build–tailored to the unique characteristics of the house plan (blueprints) and the building site.

In the absence of this detailed architectural guidance, the cost of custom homes would be much higher, and the quality of those pricey custom homes would be lower.

FHIR IGs are like Blueprints for Custom Homes

FHIR implementation guides (IGs) are relatively new; in fact, many are being written for the first time. That means that the system(s) they describe have been built very few (if any) times. This creates a “custom home” learning curve.

FHIR IG authors are talented domain experts in the healthcare use case(s) described by their IG, and many are experienced system builders. We are all lucky that these talented and dedicated domain experts spend the time to create and update FHIR IGs. However, we shouldn’t expect perfection, and they aren’t mind-readers.

These FHIR IG “blueprint” creators need feedback to ensure their work will translate into functional and frictionless IGs. Ways the healthcare implementation community can provide feedback include reading the FHIR Standards, underlying specifications, FHIR IG’s, and profiles as they are balloted and published–and this happens.

However, despite significant efforts for outreach by the Health Level Seven (HL7), the Office of the National Coordinator (ONC) and the Centers for Medicaid and Medicare (CMS) implementers continue to experience gaps in maturity and “implementability” of FHIR IGs.

FHIR Blueprint: Check! Implementation Guidance: Missing

Frequent gaps:

Reference Implementations (RIs) not providing full coverage of the specified IG functionality.
Implementations use the (incorrect) IG’s and FHIR Validation services for message validation.

Frequently heard: “Implementing FHIR, FHIR IGs, and numerous STU versions remains open to interpretation based on the implementation team experience, mind-reading ability, and attention to detail.”

Wait! Mind-reading ability?

Right. Just like FHIR IG authors cannot read the minds of implementers, implementers cannot be expected to read the minds of those IG authors. In the absence of detailed “how to implement” guidance, implementers have to guess about the nuances of and ambiguities in the FHIR IG.

It is this guessing that drives much of the variations we see in IG implementations.

“Nature Abhors a Vacuum”

Philosophers may argue about this postulate attributed to Aristotle, but implementers readily seek answers wherever they can find them.

In our interactions with implementers struggling with their IG implementations, they ask for guidance from our Touchstone testing platform support team and other Touchstone community members.

Implementer: “Can you please fix your Test Script? It must be broken, because we are failing to pass the test.”
Implementer: “My implementation used to pass these tests, but now it fails. Are the tests broken?”

Sometimes, our test is indeed “broken,” because our interpretation of the FHIR IG differs from what the IG authors meant. Once we spend the time to align interpretations with the IG authors and sponsoring HL7 workgroup, we quickly adjust our test to match the consensus interpretation.

Did you notice how prevalent interpretation is in this process?

Perhaps due to competitive concerns (or perhaps just because they are not happy about the idea of sharing their issues publicly), FHIR Implementation teams choose to not make their questions or failures public. In fact, they seek assurances from us that their questions and test failures are not publicly shared, and we honor that.

G is for Guidance; T is for Testing

If you are thinking that more guidance is needed, you are correct. Such guidance would create a virtuous cycle:

Describing how to implement requires more clarity of thought about what to implement. The act of creating implementation guidance (the “how”) will improve the core IG content (the “what”).
When implementers understand how something will be tested, they understand how to implement it–without having to interpret, guess or attempt mind-reading.
Creating this guidance drives out ambiguity. This inherently improves the “implementability” of the IG.

The IG authoring community currently struggles to identify the level of maturity within the implementation community, including the level of IG implementation coverage prior to publishing versions of STU or ultimately going FINAL. This poses a significant risk to the entire implementation community if an IG has not been fully vetted by the wide industry for which the IG is being published. A small mistake like “Purpose of Use” vs “Purpose for Use” has had lasting effects within the US Healthcare Information Exchange – which could have been avoided with more industry testing prior to “Publishing” a final version.

“Test,” as in the verb.

Running a set of tests as a final step before saying “we are done” is better than nothing–but just barely. Similarly, testing single IGs or individual FHIR message exchanges in isolation also introduces significant risk. Events like the HL7 FHIR Connectathons in the future will need to provide event-based technologies such as an integrated ecosystem when combinations of IG implementations can be tested within healthcare workflows around care coordination. Supporting Burden-Reduction, or Prior-Auth to name a few use cases.