How FHIR Enables Healthcare Interoperability

Interoperability is often discussed as a single property, but it is clearer to break it into levels. A widely used framework from HIMSS describes four:

FHIR is strongest at the first two levels. It replaced bespoke interfaces and older message formats with a web-native API (see HL7 v2 vs FHIR for the contrast) and a common resource model. Semantic and organizational interoperability depend on choices made around FHIR, which is why two FHIR-based systems can still fail to understand each other.

FHIR is often equated with its RESTful API, but the specification defines several exchange paradigms built on the same resources. Choosing the right one for each use case matters as much as choosing the right resources.

Most real-world architectures mix these. A health system might expose a REST API for apps, run bulk exports for analytics, and exchange documents with external networks. Platforms that bridge these patterns are covered on the healthcare interoperability companies page.

A FHIR resource can carry a code from any code system. Interoperability depends on agreeing which. The main clinical terminologies in FHIR exchange are:

• SNOMED CT: a comprehensive clinical terminology for problems, findings, procedures and more. Use requires a licence, which is free in member countries such as the US through the national release centre.
• LOINC: identifiers for laboratory tests, clinical measurements and survey instruments, commonly used in Observation.code.
• RxNorm: normalized names and identifiers for clinical drugs in the US, used in medication resources.
• ICD-10-CM and other classifications, often used alongside SNOMED CT for billing and reporting.
• UCUM for units of measure in Quantity values.

Implementation guides bind elements to value sets drawn from these systems, and a terminology server can validate codes, expand value sets and translate between systems with operations such as $validate-code and $translate. Mapping local codes to standard ones is frequently the largest single task in a data interoperability project.

The United States Core Data for Interoperability (USCDI), maintained by ONC (now operating as ASTP/ONC), is a standardized set of data classes and elements, such as allergies, problems, medications, laboratory results and clinical notes, that must be exchangeable. It is versioned and expands over time. USCDI does not specify a format.

The HL7 US Core implementation guide supplies the format: FHIR R4 profiles, search requirements and terminology bindings that represent USCDI. ONC's certification program for health IT requires certified API technology to support US Core and SMART App Launch, and the HTI-1 final rule advanced that baseline to USCDI v3 with corresponding newer versions of US Core and SMART. Because certified EHRs implement US Core, it has become the common denominator for US clinical FHIR exchange.

The 21st Century Cures Act directed ONC to define information blocking: practices by health care providers, certified health IT developers, and health information networks or exchanges that are likely to interfere with access, exchange or use of electronic health information, unless an exception applies. ONC's regulations define the actors, the scope of electronic health information and a set of exceptions, such as those for preventing harm, privacy, security and infeasibility.

The rules do not require FHIR as such, but standards-based APIs are the most practical way to show that data is accessible. Combined with certification requirements, this pushes providers and vendors toward exposing FHIR APIs that third-party apps can use.

CMS has used its regulatory authority over Medicare Advantage organizations, Medicaid and CHIP programs and certain qualified health plan issuers to require FHIR APIs on the payer side. The Interoperability and Patient Access final rule (CMS-9115-F) required a Patient Access API, letting members retrieve claims and clinical data through apps of their choice, and a Provider Directory API.

The Interoperability and Prior Authorization final rule (CMS-0057-F) builds on that with a Provider Access API, a Payer-to-Payer API and a Prior Authorization API, along with enhancements to Patient Access, with most API requirements beginning in January 2027. These APIs are built on R4 and HL7 implementation guides, including several from the Da Vinci project, which brings payers into the same FHIR ecosystem as providers.

The Trusted Exchange Framework and Common Agreement (TEFCA), established under the Cures Act, creates a nationwide governance layer for exchange between networks. Designated Qualified Health Information Networks (QHINs) connect to each other under a common agreement administered by a Recognized Coordinating Entity, and participants connect through a QHIN.

TEFCA exchange initially relied on established document-based query standards. ONC and the Recognized Coordinating Entity have published a FHIR roadmap, and later versions of the Common Agreement add support for FHIR-based exchange. TEFCA is a clear example of organizational interoperability: the technical standards exist, and the framework supplies the trust, policy and governance needed to use them at scale.

FHIR is international, and many countries publish national base profiles and guides. At the international level, the International Patient Summary (IPS) implementation guide defines a minimal, specialty-agnostic patient summary for unplanned and cross-border care, represented as a FHIR document Bundle. It is designed to be reused as a foundation by national and regional projects.

For organizations operating in several countries, the lesson is to design around profiles rather than base resources and to expect a different core guide in each market. A FHIR consulting partner with regional experience can shorten that learning curve.