Beyond FHIR Compliance: The Interoperability Standard Behind US Core

• April 03, 2026

The Problem US Core Was Built to Solve

Today, US Core is the foundation that certified EHRs in the US are expected to align with, defining how clinical data is structured, accessed, and exchanged across systems. But US Core did not emerge in isolation. It exists because something fundamental was not working. The US Core Implementation guide has steadily expanded from 24 profiles in 2019 to over 50 today, not by accident, but in response to real gaps in interoperability, where FHIR defined the building blocks but left critical implementation decisions open.

Understanding that gap and how the industry closed it, changes how you design integrations entirely. To see why, we need to start with FHIR.

Why FHIR Was a Breakthrough and Still Not Enough

FHIR was a major step forward for healthcare interoperability.

For the first time, healthcare data could be queried, retrieved, and integrated using standard web technologies. EHR vendors moved quickly to adopt it. Epic supported FHIR. Cerner supported FHIR. Athenahealth supported FHIR.

And yet, real-world integrations kept breaking. The reason was structural.

FHIR defines the building blocks, resources and elements, but it does not define how they must be used. It does not mandate which resources are required, which terminology systems must be followed, how APIs should behave, or how authorization should be implemented.

As a result, implementations varied widely.

Two systems could both be FHIR-compliant and still fail to exchange data reliably, because each made different choices within the same standard.

This led to consistent challenges across the ecosystem:

1. Inconsistent data representation, driven by differing terminology and coding standards
2. Limited API accessibility, with many systems not exposing usable endpoints
3. Unpredictable integration behavior, due to variations in API design and responses
4. Lack of structured access to clinical data, especially unstructured notes and documents

FHIR compliance had become a credible claim. It was not a guarantee of interoperability. The industry did not need another standard. It needed consistency in how FHIR was implemented.

How the Industry Made FHIR Work: Argonaut Project

To address this gap, the industry came together to define a more consistent approach to FHIR implementation.

This effort became the Argonaut Project.

Formed in 2014 as a private-sector initiative, Argonaut brought together leading EHR vendors, providers, and payers to align on how FHIR should be used in practice.

Rather than changing the FHIR standard, Argonaut focused on reducing variability. It defined a common set of expectations for:

1. Which FHIR resources should be used
2. How key clinical data elements should be structured
3. Which terminology standards should be followed
4. How APIs should behave, including search, responses, and error handling

As a result, interoperability decisions now belong in product strategy and platform architecture, not just implementation or delivery teams. Vendors that continue to treat interoperability as “integration work” will struggle to scale under HTI-4 expectations.

The goal was simple:

make FHIR implementations consistent enough to enable real interoperability.

Argonaut also emphasized open APIs, ensuring that patient data could be accessed securely and reliably by authorized third-party applications.

This was not a theoretical exercise. It was a working agreement between the organizations building and using healthcare systems.

And it laid the foundation for what would later be formalized by HL7 as the US Core Implementation Guide.

How Argonaut Became US Core

Argonaut did not try to solve interoperability in theory. It solved it by aligning the right players.

In US healthcare, a small number of EHR vendors control the majority of the market. When they move in a direction, the entire ecosystem follows, from health systems to third-party vendors to integration partners.

Argonaut used this dynamic deliberately.

Argonaut used this dynamic deliberately. It brought together Epic, Cerner, Athenahealth, Allscripts, Meditech, leading health systems like Beth Israel Deaconess Medical Center and Mayo Clinic, and major payers into a single working group. Any agreement reached by this group would not remain a proposal. It would become the standard in practice.But alignment at this level is not automatic , especially among competitors.

Three factors made it possible:

1. First, the cost of fragmentation was too high.

   Broken integrations were impacting vendors, providers, and patients alike.

2. Second, regulation was coming.

   The 21st Century Cures Act made it clear that data access mandates were inevitable.

3. Third, the alternative was worse.

   If the industry did not define the standard, regulators would with far less flexibility.

Argonaut gave the industry a way to move first. The output was not just a specification. It was a working interoperability contract.

That contract became:

1. US Core profiles — defining what data must be shared
2. SMART on FHIR — standardizing authorization
3. Clinical Notes guidance — making unstructured data accessible via APIs

These were not theoretical improvements. They were implementable, testable, and adopted across the ecosystem. This is the connection most integration teams never make

The US Core profiles you work with today are not just part of FHIR. They are the direct output of this industry alignment, formalized later through regulation and certification.

And that is what made interoperability real.

Key How Interoperability Moved from Standard to Enforcement

What began as a private-sector initiative is now enforced at a federal level.

1. Argonaut aligned early FHIR implementations.
2. HL7 formalized them.
3. ONC made them part of certification.
4. CMS enforces them through participation and reimbursement.

What started as guidance is now regulation.

The 21st Century Cures Act Final Rule made this explicit. All ONC-certified systems must:

1. Support FHIR R4 APIs
2. Conform to US Core
3. Enable SMART on FHIR
4. Provide access without information blocking

Non-compliance is not optional, it carries penalties.

With HTI-1 (2024), the baseline moved again to US Core 6.1.0 and USCDI v3.

The direction is clear.

The interoperability floor is now regulated and it keeps rising. But regulation does not guarantee uniform implementation.

And that is where real-world interoperability begins to diverge.

Adoption Reality: The Three Tiers

Understanding the power chain is one thing. Knowing what it looks like in practice when you are onboarding a new client integration is another. Not all EHRs are equal, even within a mandated compliance landscape.

Adoption sits across three distinct tiers.

Tier 1 is the mandated baseline. Every ONC certified EHR must expose FHIR R4 APIs conforming to US Core. This surface is guaranteed across certified systems.

Tier 2 is where SMART on FHIR app ecosystems operate. Epic, Oracle Health and Athena all run on this layer. ONC data shows FHIR app adoption grew from 49% in 2021 to 64% in 2024. But depth varies significantly across vendors.

Tier 3 is where adoption drops sharply. Bulk FHIR and CDS Hooks are meaningful only at top tier EHRs. Most mid market systems are years behind.

Understanding these tiers is critical. Because while the interoperability floor is guaranteed, the ceiling still varies and your architecture needs to account for both.

The Foundation Behind Scalable Interoperability

There is a distinction that separates integration teams that scale from those that do not. It is not the size of the team or the sophistication of the tooling. It is whether they are building integrations or building interoperability infrastructure.

Building Integrations

This is how most teams start. Each EHR is treated as a separate problem. One connector for Epic. Another for Cerner. Another for Athena.

Each with its own:

1. Authorization logic
2. Query patterns
3. Data mappings
4. Edge cases

It works initially. But with every new client, the effort repeats. Scaling becomes linear with engineering effort.

Building Interoperability Infrastructure

A different approach starts with a different assumption. That US healthcare now has a canonical interoperability layer, defined, enforced, and continuously expanding.

Instead of building per-EHR integrations, the architecture is designed around that layer.

1. A common data model aligned to US Core
2. Standardized API interaction patterns
3. Reusable authorization flows
4. Configurable vendor-specific adaptations 

In this model, a new client does not require new engineering.
It requires configuration.

A 2026 CHIME Foundation survey found that 47% of health CIOs cited the cost of initial and ongoing integration as their biggest barrier to interoperability. Only 16% reported that their core EHR provides vendor agnostic interoperability today.

And the cost of getting this wrong is real. Custom integrations built outside this model accumulate technical debt with a compliance clock attached. Every regulatory update requires rework. Industry estimates place integration costs between $50,000 and $500,000 per project, with large-scale implementations exceeding $1 million.

he problem is structural, not technical. And the solution is architectural.
This is where Argonaut alignment becomes important.

It is not just about FHIR conformance. It extends into:

1. Your data model 
2. Your authorization patterns
3. Your query design
4. Your population data strategy 

When this foundation is right, onboarding a new EHR client becomes a configuration exercise, not an engineering project. Scaling from five clients to fifty does not multiply your integration team. It multiplies your configurations.

The ecosystem is also moving in a clear direction.

Initiatives like Da Vinci (payer-provider workflows), Gravity (social determinants of health), and The Sequoia Project (trusted data exchange frameworks) are extending the same interoperability model across new domains. These are not separate efforts. They are expansions of the same foundation.

The question is no longer how to integrate with each EHR.

The question is whether your architecture is built on the layer every EHR is being forced to align with.

Conclusion

US Core profiles did not emerge from a committee.

They came out of a deliberate, industry-led effort to make FHIR work in practice , one that brought key players together and created an agreement later formalized and enforced by regulators.

For MSPs, HIT vendors, and AI healthcare startups, this fundamentally changes how integration should be approached. The focus is no longer on connecting to individual systems, but on aligning with the model those systems are required to follow.

At KPi-Tech, we help organizations design their interoperability layer on this foundation from the start, so the work done for one client becomes reusable across many.

If you are looking to move beyond point-to-point integrations and build for scale, we would be glad to connect.