Healthcare Interoperability Explained: HIE, TEFCA, USCDI, Cures Act

What Healthcare Interoperability Means

Healthcare interoperability is the ability of different health IT systems, devices, and applications to exchange patient data across organizational boundaries and to use that data with its meaning intact. In practice it means a lab result ordered in one EHR, a discharge summary written at a hospital, and a medication list held by a pharmacy can all reach a clinician or the patient in a form their software can read and act on, without anyone retyping it.

The term has a legal definition in the United States. Section 4003 of the 21st Century Cures Act defines interoperable health IT as technology that enables the secure exchange and use of electronic health information without special effort on the part of the user, allows complete access, exchange, and use of all electronically accessible health information for authorized use under applicable law, and does not constitute information blocking. That definition is why the topic is no longer only an engineering concern. It is a compliance obligation for hospitals, clinicians, health IT developers, and exchange networks.

A useful way to hold the whole subject in your head is to see it as five layers that all have to work at once.

• Transport: the pipe that moves bytes between systems, whether MLLP over a VPN, HTTPS, or encrypted email.
• Structure: the format of what moves, such as an HL7 v2 message, a C-CDA document, or a FHIR resource.
• Meaning: the code systems that make a glucose result or a penicillin allergy mean the same thing on both ends.
• Trust and policy: the agreements, identity proofing, consent rules, and audit requirements that let two organizations exchange data legally.
• Regulation: the federal rules from ONC and CMS that decide what is mandatory, by when, and what happens when an actor refuses to share.

This guide walks each layer, then finishes with the architecture and a buyer checklist. Where a neighboring topic has its own depth page on this site, such as the HL7 vs FHIR comparison, we link to it instead of repeating it.

The Four Levels of Interoperability

HIMSS, the Healthcare Information and Management Systems Society, publishes the definition most of the industry uses. Its 2019 revision describes four levels of interoperability: foundational, structural, semantic, and organizational. The first three are technical. The fourth, added in that revision, recognizes that data does not move between hospitals because the software can talk. It moves because two organizations agreed on governance, policy, and legal terms that let it.

Most integration projects reach the structural level quickly and then stall at semantic. An interface can deliver a perfectly formed HL7 v2 message whose result field contains a local lab code that the receiving system has never seen. The data arrived, it parsed, and it is still unusable for decision support or quality reporting. When a buyer asks a vendor whether a product is interoperable, the honest follow up is: at which level, and for which data.

The Standards Stack and Terminologies

No single standard covers healthcare. Different transactions grew up in different decades under different standards bodies, and a working hospital runs all of them at once. HL7 International maintains HL7 v2, C-CDA, and FHIR. ASC X12 maintains the administrative transactions HIPAA mandates under 45 CFR Part 162. NCPDP maintains the pharmacy standards, the DICOM Standards Committee under NEMA maintains imaging, and IHE International publishes profiles that describe how to combine the others for a specific job.

The most common question a buyer asks is whether FHIR replaces HL7 v2. The short answer is no, they coexist, and the long answer with the tradeoffs is on our HL7 vs FHIR page. For this guide it is enough to know that v2 dominates event messaging inside the hospital, C-CDA dominates document exchange between organizations, and FHIR dominates anything an app, a patient, or a payer touches through an API.

Terminologies: the vocabularies that make data mean the same thing

Structure standards say where the code goes. Terminologies say what the code is. The United States uses a handful of them, each with a steward and a job.

• SNOMED CT (SNOMED International): clinical findings, disorders, procedures, and body structures. Over 350,000 active concepts. Used for problems, allergies, and procedure documentation.
• LOINC (Regenstrief Institute): laboratory tests, clinical observations, and document types. Over 100,000 terms. Required for lab results and vital signs in USCDI.
• RxNorm (National Library of Medicine): normalized names for clinical drugs, linking NDC codes and drug knowledge bases. Required for medications.
• ICD-10-CM and ICD-10-PCS (CDC NCHS and CMS): diagnosis and inpatient procedure codes used for billing and public health, with roughly 70,000 diagnosis codes updated each October 1.
• CPT (American Medical Association): procedures and services for professional billing, with HCPCS Level II from CMS for supplies and drugs.
• CVX (CDC): vaccine administered codes, paired with MVX manufacturer codes, used in immunization registries.
• UCUM (Regenstrief Institute): units of measure, so mg/dL and mmol/L are unambiguous in a lab result.

USCDI, covered below, is where these bind together. Each USCDI data element names the vocabulary it must use, and the HL7 US Core FHIR profiles carry those bindings into the (g)(10) API that every certified EHR now exposes.

Health Information Exchange: Regional HIEs, National Networks, and Direct

Health information exchange is both an activity and an organization. As an activity, it is the electronic movement of clinical information between organizations. As an organization, an HIE is a regional or statewide nonprofit or public entity that operates the shared infrastructure: a record locator, a document repository, a master patient index, and an event notification service. Examples include CRISP in Maryland, the Indiana Health Information Exchange, Manifest MedEx in California, and HEALTHeLINK in western New York. Several states now call these health data utilities to reflect a broader mandate that includes public health reporting and payer data.

Regional HIEs mostly exchange C-CDA documents using IHE XDS.b and XCA, and push HL7 v2 ADT messages as encounter notifications. Those notifications became a federal requirement when CMS made them a hospital Condition of Participation effective May 1, 2021: hospitals, psychiatric hospitals, and critical access hospitals must send electronic admission, discharge, and transfer notifications to a patient's primary care practitioner and post acute providers.

Three national networks connect providers regardless of geography. eHealth Exchange grew out of the Nationwide Health Information Network program and connects federal agencies such as the VA, the Department of Defense, and the Social Security Administration with health systems and regional HIEs. CommonWell Health Alliance, founded in 2013 by a group of EHR vendors, runs a record locator service and connects its members through their EHRs. Carequality, launched in 2016 by The Sequoia Project, is a trust framework rather than a network: implementers such as Epic Care Everywhere, athenahealth, and NextGen connect to each other under shared rules. CommonWell and Carequality bridged in 2018, so a query from one can reach the other.

Direct Secure Messaging

Direct is the push alternative to query based exchange. Created through the ONC Direct Project in 2010, it uses S/MIME encrypted email between Direct addresses that look like ordinary email addresses but route through accredited Health Information Service Providers. DirectTrust accredits the HISPs and maintains the trust bundle. Direct is what a referring physician uses to send a C-CDA to a specialist, and it is the transport behind the transitions of care measures in the Promoting Interoperability program. It works everywhere, it is simple, and it cannot answer a question. You have to know who to send to.

Exchange outside the United States

Other countries skipped the voluntary network phase and built national platforms with mandatory participation. Saudi Arabia runs NPHIES, a FHIR based national platform for insurance claims and clinical exchange under the Council of Health Insurance. Abu Dhabi runs Malaffi, the Department of Health HIE that every licensed facility connects to. Dubai runs NABIDH, the Dubai Health Authority exchange with its own connection standards and audits. The European Union adopted the European Health Data Space regulation in 2025 to do something similar across member states. The technical stack is familiar to anyone who knows FHIR and IHE. The governance is very different, and that is the part that decides timelines.

TEFCA: One Common Agreement for National Exchange

The Trusted Exchange Framework and Common Agreement, TEFCA, is the federal answer to the patchwork of networks above. Section 4003(b) of the Cures Act directed ONC to develop a trusted exchange framework of principles and a common agreement that networks could sign. ONC selected The Sequoia Project as the Recognized Coordinating Entity to operate it, published Common Agreement version 1 in January 2022, and paired it with a QHIN Technical Framework that specifies the exchange mechanics.

The structure has three tiers. Qualified Health Information Networks, or QHINs, sign the Common Agreement directly and route queries to each other. Participants such as health systems, HIEs, and EHR vendors connect through a QHIN. Subparticipants such as individual practices connect through a Participant. The first five QHINs were designated on December 12, 2023: eHealth Exchange, Epic Nexus, Health Gorilla, KONZA National Network, and MedAllies. CommonWell Health Alliance and Kno2 were designated in early 2024, and more followed. Because Epic, Oracle Health, and the major networks all participate, a large share of US patient records is reachable through TEFCA today.

Every TEFCA transaction states an Exchange Purpose, and each purpose carries its own rules on who must respond.

• Treatment: provider to provider queries for patient care. Response is required.
• Individual Access Services: a patient, through a credentialed app, requesting their own records. Response is required, and the identity proofing rules are strict.
• Payment and Health Care Operations: payer and operational uses under HIPAA. Phased in as required purposes over time.
• Public Health: reporting to and queries from public health agencies.
• Government Benefits Determination: agencies such as the Social Security Administration verifying eligibility.

Version 1 exchange was document based, using IHE XCA and XCPD to find a patient and pull C-CDA documents. Common Agreement version 2.0, published in April 2024, added the framework for FHIR based exchange, where a Participant can query FHIR endpoints discovered through the QHIN directory instead of pulling whole documents. That roadmap matters for anyone building on TEFCA: the endpoints, security profiles such as UDAP, and consent handling for FHIR exchange are still maturing, while document exchange is production grade now. If you are building a single integration layer that must talk to Epic, Oracle Health, and a QHIN at once, the pattern is described on our EHR integration layer page.

USCDI: The Data Every Certified System Must Exchange

The United States Core Data for Interoperability, USCDI, is the standardized set of health data classes and data elements that certified health IT must be able to exchange. It is adopted in regulation at 45 CFR 170.213 and replaced the older Common Clinical Data Set. ONC publishes a draft version each January and a final version each July, and anyone can propose new elements through the ONDEC submission process. Publication and regulatory adoption are separate steps: a version only becomes mandatory when a certification rule points to it.

USCDI v3, the version in force for certification today, contains around twenty data classes. The core clinical set is patient demographics, problems, medications, allergies and intolerances, immunizations, laboratory tests and results, vital signs, procedures, clinical notes, diagnostic imaging reports, encounter information, care team members, goals, assessment and plan of treatment, and health concerns. Around it sit the administrative and contextual classes: health insurance information, provenance, unique device identifiers, and health status assessments, which is where the social determinants of health elements live.

Two practical notes. First, USCDI names the data, and the HL7 US Core Implementation Guide is how that data is expressed in FHIR, so a vendor claiming USCDI support on a FHIR API should be able to name the US Core version it conforms to. Second, ONC also maintains USCDI+, a set of domain extensions for public health, quality measurement, cancer registries, behavioral health, and maternal health, which federal agencies use for their own programs and which sometimes preview what enters the base USCDI later.

The 21st Century Cures Act, Information Blocking, and ONC Certification

The 21st Century Cures Act was signed on December 13, 2016. Title IV of the law is the part that reshaped health IT: it defined interoperability, prohibited information blocking, directed ONC to create TEFCA, and told ONC to require standardized APIs in certified health IT. ONC implemented those provisions in the Cures Act Final Rule, published May 1, 2020, which added the information blocking regulations at 45 CFR Part 171 and updated the certification criteria at 45 CFR Part 170.

Information blocking is a practice by a covered actor that is likely to interfere with the access, exchange, or use of electronic health information, unless the practice is required by law or covered by an exception. Three groups are actors: health care providers, developers of certified health IT, and health information networks or exchanges. The rules applied from April 5, 2021. Until October 6, 2022 the definition of electronic health information was limited to the USCDI v1 elements; since then it covers all electronic protected health information in a HIPAA designated record set. The rule established eight exceptions in two groups.

• Exceptions for not fulfilling a request: Preventing Harm, Privacy, Security, Infeasibility, and Health IT Performance.
• Exceptions for how a request is fulfilled: Manner (originally Content and Manner), Fees, and Licensing.
• Added later: HTI-1 introduced a TEFCA Manner exception in 2024, and HTI-3, finalized in December 2024, added Protecting Care Access and Requestor Preferences.

Enforcement arrived in two pieces. The HHS Office of Inspector General final rule of June 2023 set civil money penalties of up to $1 million per violation for health IT developers, health information networks, and HIEs, with enforcement starting September 1, 2023. Providers are handled differently. The HHS disincentives final rule of June 2024 applies through Medicare programs: a hospital found to have committed information blocking loses 75 percent of its annual market basket update under the Promoting Interoperability Program, a MIPS eligible clinician scores zero in the Promoting Interoperability performance category, and an accountable care organization can be barred from the Medicare Shared Savings Program for at least one year.

The other half of the rule is the API mandate. Certification criterion 45 CFR 170.315(g)(10), standardized API for patient and population services, requires FHIR R4, the US Core profiles, SMART App Launch for authorization, and the Bulk Data Access specification, and every certified EHR had to have it by December 31, 2022. A companion criterion, (b)(10), requires an export of all electronic health information for a single patient or a whole population. Together these are what make a patient app, a payer, or an outside developer able to pull data from Epic, Oracle Health, athenahealth, or MEDITECH through a documented interface rather than a custom feed.

ONC certification and the HTI rules

The ONC Health IT Certification Program is voluntary in law and mandatory in practice, because Medicare payment programs require certified technology. ONC Authorized Certification Bodies test products against the criteria and list them on the Certified Health IT Product List. Since the Cures Act rule, certification also carries Conditions and Maintenance of Certification that bind the developer, not just the product: no information blocking, published API terms, real world testing, and attestations. In July 2024 the office was renamed the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health IT, written ASTP/ONC, and it now also oversees HHS wide AI and data policy.

The certification rules since then carry HTI numbers. HTI-1, finalized in December 2023, adopted USCDI v3 with a January 1, 2026 deadline, replaced the clinical decision support criterion with a decision support interventions criterion that requires transparency about predictive algorithms, and added the Insights Condition for reporting on how certified technology is used. HTI-2, proposed in July 2024, was ambitious: USCDI v4, new payer and public health criteria, and expanded API requirements. Only a narrow slice, mainly the TEFCA governance provisions, was finalized in December 2024. HTI-3, finalized the same month, carried the two new information blocking exceptions above. Buyers should treat anything beyond USCDI v3 and the current (g)(10) criterion as a roadmap item until a final rule sets a date.

Related Guides

These guides cover the neighboring concepts this article refers to, each written in the same answer first format.

• Radiology Information System (RIS) Explained: RIS vs PACS vs EHR: how the RIS, PACS, VNA and EHR divide the imaging workflow.
• HIPAA Privacy Rule vs Security Rule: What Each Covers, Who Complies: what the Privacy Rule and Security Rule each govern and who must comply.
• What Is Prior Authorization? Process, Timelines and the 2026 Rules: the prior authorization process, turnaround rules and electronic PA standards.
• Social Determinants of Health (SDOH): Definition, Examples and Data: the five SDOH domains, Z codes and the Gravity Project data standards.

CMS Interoperability Rules: Patient Access, Provider Directory, Payer to Payer, and Prior Authorization

ONC regulates the software. CMS regulates the payers and providers that take federal money, and it uses that position to require interoperability of its own. The CMS Interoperability and Patient Access final rule, CMS-9115-F, published in May 2020, applies to Medicare Advantage organizations, Medicaid and CHIP fee for service and managed care plans, and qualified health plan issuers on the federally facilitated exchanges. The CMS Interoperability and Prior Authorization final rule, CMS-0057-F, finalized January 17, 2024, extends it with new APIs and, for the first time, hard deadlines on prior authorization decisions.

The 2027 APIs are where most of the engineering sits. The Provider Access API lets an in network provider pull a patient's claims, encounter, and clinical data from the payer through Bulk Data. The Payer to Payer API moves a member's history to a new plan when they switch, with the member's opt in. The Prior Authorization API uses the HL7 Da Vinci Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support guides so an EHR can ask whether authorization is needed, gather the documentation, and submit, all in FHIR. Note that the HIPAA X12 278 transaction is still the legally mandated format for the authorization request itself, and CMS granted an enforcement discretion so payers can accept the FHIR request without a 278 behind it. That detail shapes how a payer or a vendor should architect the flow, and it is a common source of confusion in FHIR integration planning.

SMART on FHIR and CDS Hooks: How Apps Plug Into the EHR

SMART on FHIR is the authorization and app launch framework that lets a third party application run against an EHR's FHIR API with the user's permission. It began as the SMART Health IT project at Boston Children's Hospital and Harvard Medical School, and is now the HL7 SMART App Launch Implementation Guide. Technically it is OAuth 2.0 for authorization and OpenID Connect for identity, with healthcare specific scopes and a launch context that tells the app which patient and which encounter the clinician is looking at. The (g)(10) criterion requires it, so every certified EHR supports it, which is why one app can be written once and launched inside Epic, Oracle Health, athenahealth, or MEDITECH.

• EHR launch vs standalone launch. In an EHR launch the clinician clicks the app inside the EHR, which passes a launch token and the FHIR server address so the app opens on the right patient. In a standalone launch the user opens the app on its own, picks the EHR, and signs in; a patient using a personal health app is the typical case.
• Scopes. Scopes such as patient/Observation.rs, user/*.cruds, launch/patient, openid, fhirUser, and offline_access define exactly what the app may read or write and for whom. SMART version 2 replaced the older read and write verbs with granular create, read, update, delete, and search letters.
• Backend services and Bulk Data Access. For system to system use with no user present, a client authenticates with a signed JWT using an asymmetric key pair and receives a token for system scopes. That is how the FHIR Bulk Data Access specification works: a $export request on a Patient, Group, or the whole system returns NDJSON files asynchronously, which is how payers, registries, and analytics platforms pull populations.

CDS Hooks is the companion HL7 specification for the other direction. Instead of the user launching an app, the EHR calls an external decision support service at defined moments in the workflow: patient-view when a chart opens, order-select and order-sign when a clinician orders, encounter-start and encounter-discharge around visits. The service receives context and optional prefetched FHIR data and returns cards, which are short messages with a source, an optional suggestion the clinician can accept, and an optional link that launches a SMART app for more detail. Version 2.0, published in 2022, added a feedback endpoint so the service learns whether its cards were accepted or overridden. Together, SMART on FHIR and CDS Hooks are how most clinical AI now reaches the point of care without living inside the EHR vendor's code.

Practical Architecture, Common Failure Points, and a Buyer Checklist

A working interoperability architecture is a set of shared services that every interface uses, not a pile of point to point connections. The same six components show up in a health system, a payer, and a digital health vendor, differing only in scale and in which one is bought versus built.

• Integration engine. Receives HL7 v2, C-CDA, X12, and flat files, transforms them, routes them, and retries them. Mirth Connect, Rhapsody, and InterSystems HealthShare are the common choices; Redox and similar services offer the same function as a hosted network.
• FHIR server or clinical data repository. Stores data as FHIR resources and exposes the REST API, search, and $export. Open source HAPI FHIR and its commercial sibling Smile CDR, Firely Server, Microsoft Azure Health Data Services, Google Cloud Healthcare API, and AWS HealthLake all fill this role; the cloud services add HL7 v2 and DICOM stores alongside FHIR.
• Master patient index. Links the same person across source systems using deterministic and probabilistic matching, exposed through IHE PIX and PDQ or FHIR Patient $match. The United States has no national patient identifier, and a rider in every HHS appropriations bill since 1999 blocks HHS from creating one, so matching quality is a permanent engineering problem.
• Consent management. Records who may see what, enforced at query time. This is where HIPAA, state laws on sensitive categories, and 42 CFR Part 2 for substance use disorder records meet. The SAMHSA Part 2 final rule of February 2024 aligned Part 2 more closely with HIPAA, with compliance required by February 16, 2026. The FHIR Consent resource is the usual representation.
• Terminology service. Validates and maps codes using the FHIR terminology operations $lookup, $validate-code, $expand, and $translate. Ontoserver and Snowstorm are common servers; the NLM Value Set Authority Center is the source for value sets used in quality measures and USCDI.
• Identity and authorization. An OAuth 2.0 authorization server that implements SMART App Launch and, for TEFCA FHIR exchange, the UDAP security profiles for dynamic client registration and certificate backed identity.

Where interoperability projects fail

• Patient matching. Duplicate and overlaid records poison every downstream use. Budget for data quality work on demographics before the first interface goes live.
• Local codes. A lab that sends its own test codes instead of LOINC delivers structurally valid, semantically useless data. Mapping is unglamorous and it is most of the work.
• Document bloat. C-CDA documents that include every problem and result since 2009 make the receiving clinician ignore them. Constrain what you send.
• Version drift. An HL7 v2 feed with custom Z segments, a FHIR server on an old US Core version, or an X12 companion guide the payer changed without notice. Interfaces need owners and monitoring, not just a go live.
• Consent as an afterthought. Bolting Part 2 or state sensitivity rules onto a finished exchange usually means turning the exchange off until it is fixed.
• Treating certification as the finish line. A certified (g)(10) API proves the vendor passed a test. It does not prove the data behind it is complete, current, or coded.

A checklist for the health IT buyer

• Which USCDI version and which US Core version does the product support, and is it listed on the CHPL with the (g)(10) and (b)(10) criteria?
• For each data class you need, is the data exposed at the semantic level, meaning coded in SNOMED CT, LOINC, and RxNorm, or only as text?
• Which national networks can it reach, and through which QHIN? Ask for the TEFCA Exchange Purposes it supports and whether FHIR based exchange is live or planned.
• Does it support SMART App Launch for both EHR and standalone launch, SMART version 2 scopes, and backend services for Bulk Data?
• How does it handle patient matching, and what match rate does it measure against your own data, not a demo set?
• How are consent, 42 CFR Part 2, and state sensitive data rules enforced at query time, and can you see the audit log?
• What are the API fees and licensing terms, and do they fit the Fees and Licensing exceptions under the information blocking rule?
• For payers: what is the delivery plan for the January 1, 2027 Provider Access, Payer to Payer, and Prior Authorization APIs, and which Da Vinci guide versions?
• Who owns the interface after go live, how is it monitored, and what is the process when a trading partner changes a version?

If those questions get clear answers, the product is interoperable in the sense that matters. If they get a brochure, you have learned something too. When the answer is that no single product covers the mix of EHRs, payers, and networks you need to reach, the usual remedy is a shared integration layer that normalizes to FHIR once and serves every consumer from there, which is the approach described on our universal EHR integration layer page.