From “Must Support” to Measurable Interoperability: Why FHIR Obligations Are a Necessary Next Step 

Interoperability in healthcare has never been a lack-of-standards problem. We have specifications. We have profiles. We have Implementation Guides that run hundreds of pages deep.

And yet, anyone who has ever implemented FHIR at scale knows the uncomfortable truth: two systems can both be “FHIR compliant” and still fail to interoperate in practice. 

One of the quiet reasons behind that gap is conformance ambiguity. And at the center of that ambiguity sits a deceptively simple flag: Must Support. 

For years, Must Support has been the primary mechanism to express expectations beyond cardinality. It was meant to signal importance. To say: this element matters. But what it actually meant—what a system had to do with that element—was often left to interpretation. 

FHIR Obligations are the community’s answer to that problem. Not as a replacement, but as an evolution. And more importantly: as a way to move interoperability from well-intended narrative to measurable behavior.

The hidden cost of ambiguity 

The original definition of Must Support was intentionally flexible. An implementation “shall provide support for the element in some meaningful way.” That flexibility made FHIR broadly adoptable, but it also created a structural weakness. 

Because what is “meaningful” depends on perspective. 

• Does a server need to store the element?
• Must it be returned on read?
• Should it be searchable?
• Is displaying it enough?
• What about clients versus servers? 

None of that was encoded in the profile itself. Instead, implementers had to dig through narrative sections—often actor-specific, sometimes inconsistent, and always human-readable. 

This worked. But it didn’t scale. 

As FHIR adoption accelerated—across countries, domains, and vendors—the cost of interpretation grew. Profiles became harder to test. Implementations became harder to compare. And conformance drift became almost inevitable. 

At that point, interoperability stops being a technical problem and becomes a trust problem.

Why narrative conformance doesn’t hold up anymore 

Narrative conformance has two structural limitations: 

1. It’s not machine-readable. You cannot reliably test narrative intent. Automated tooling can validate structure, cardinality, and terminology bindings—but not behavioral expectations hidden in prose. 

2. It fragments responsibility. The same profile often means different things to different actors, but that logic lives outside the StructureDefinition. The result: parallel interpretations, duplicated profiles, or extensive “out-of-band” agreements. 

The irony is that we already solved this problem conceptually. FHIR’s entire conformance language is built on RFC 2119 keywords—MUST, SHOULD, MAY. The issue was never the lack of normative vocabulary. It was the lack of structure. 

That’s exactly where FHIR Obligations come in.

Obligations: Making intent explicit 

FHIR Obligations take what Must Support implied and make it explicit, coded, and testable. 

Instead of saying “this element is important” and explaining why elsewhere, a profile can now state—directly on the element: 

• What behavior is expected (e.g. SHALL populate, SHOULD display)
• For which actor (producer, consumer, server, client)
• Under what conditions (via FHIRPath filters)
• In which process or workflow context 

All of this lives inside the StructureDefinition. Where conformance belongs. 

The result is not more rigidity, but more precision. A single profile can express different expectations for different actors without multiplying variants or relying on external documentation. 

And critically: these expectations are machine-readable.

From compliance to evidence 

This is where the shift becomes strategic. 

FHIR Obligations do not change core FHIR validation. They don’t affect resource instances. But they enable behavioral validation—the ability for tooling to verify whether a system actually does what it claims. 

For testing frameworks, this is a breakthrough. 

Instead of checking “does this element exist,” we can now test: 

• Does the server populate this element when acting as a responder?
• Does the client handle and process it when present?
• Are required behaviors consistent across workflows? 

Interoperability stops being an assumption and becomes something you can prove. 

That matters not just for vendors, but for national programs, regulators, and large-scale ecosystems that need predictable outcomes, not best-effort interpretations.

Obligations and must support – not either/or 

One important point often gets misunderstood: FHIR Obligations do not replace Must Support. 

In fact, best practice is the opposite. Any element with an Obligation should also be marked Must Support. 

Why? Because Must Support remains the compatibility signal for systems and tools that don’t yet understand Obligations. It acts as a safety net—ensuring that the importance of the element is still visible, even if the detailed semantics are not. 

Think of Must Support as the headline. 

Obligations are the fine print that finally got standardized. 

Together, they create profiles that are both backward-compatible and future-proof.

Adoption is already happening 

Although FHIR Obligations are currently at trial-use status, adoption tells a different story. 

National and regional initiatives across Europe, Canada, Australia, Germany, and Austria are already using Obligations to define actor-specific behavior in their core specifications. Within organizations like HL7 International and Firely, the direction is clear: conformance needs to be explicit if interoperability is going to scale. 

“Trial-use” here doesn’t mean experimental. It means the community is actively shaping something it already relies on.

The bigger picture 

FHIR Obligations represent a maturity step for the ecosystem. 

They acknowledge that interoperability is not just about data models, but about behavior. Not just about syntax, but about expectations. And not just about documentation, but about verifiability. 

If we want to move from “FHIR-compliant” to “FHIR-interoperable,” this evolution is not optional. It’s necessary. 

If you are authoring or maintaining FHIR profiles today, ask yourself one question: Are my conformance rules explicit enough to be tested without explanation? If the answer is no, it’s time to look beyond narrative—and start designing for measurable interoperability.

Explore the Full Analysis
To dive deeper into the rationale, structure, and real-world application of FHIR Obligations, read our whitepaper, Refining Conformance: An Analysis of the Evolution from Must Support to FHIR Obligations.