EHR interoperability is the ability of electronic health records to exchange data with other systems and use what they receive: between providers, with patients' apps, with payers, with public health and with the software that extends the record. In the United States it now rests on a small set of named standards and rules, and most of the remaining work is engineering rather than policy.
This EHR interoperability guide covers what interoperability means, why it matters now, the layers it is built from, the networks and rules that connect EHRs, how to build for it, best practices, common mistakes and your build plan.
What is EHR interoperability?
Making your EHR data move?
Agnotic builds EHR interoperability: FHIR APIs and facades, HL7 v2 interfaces, document exchange and network connections, with the rules designed in.
EHR interoperability is the capacity of an electronic health record to send, receive and make use of health information with other systems in a way that preserves meaning: the same patient, the same medication, the same result, understood on both sides. It covers APIs for apps, document exchange between organizations, message feeds for events, population-level exports and participation in national networks.
Four levels of interoperability
- Foundational: Systems can connect and move data at all, securely.
- Structural: Data arrives in an agreed format, such as a FHIR resource, an HL7 v2 message or a C-CDA document.
- Semantic: Both sides interpret the data the same way, through shared code systems such as SNOMED CT, LOINC and RxNorm and shared profiles such as US Core.
- Organizational: Governance, policy, consent and trust agreements that let organizations exchange, which networks such as TEFCA provide.
Why does EHR interoperability matter now?
- Certified APIs are standard: Under ONC criterion 170.315(g)(10) and the HTI-1 rule, certified EHRs expose a FHIR API supporting USCDI v3, US Core 6.1.0, SMART App Launch 2.0 and Bulk Data Access from January 1, 2026.
- The data set keeps growing: USCDI, maintained by ASTP/ONC, defines the data classes and elements certified systems must support. Version 3 is the certification baseline and newer versions are published yearly.
- Blocking is prohibited: The information blocking rules at 45 CFR Part 171 restrict practices by providers, EHR developers and networks that interfere with access, exchange or use of electronic health information.
- A national network is live: TEFCA, the Trusted Exchange Framework and Common Agreement, connects Qualified Health Information Networks under a Common Agreement, and HHS announced in June 2026 that more than one billion health records had been exchanged through the network.
- Payers must join: Under CMS-0057-F, impacted payers must offer Patient Access, Provider Access, Payer-to-Payer and Prior Authorization FHIR APIs, with payer-to-payer and prior authorization APIs due by January 1, 2027.
- Everything is exportable: ONC criterion 170.315(b)(10) requires certified health IT to export all electronic health information for one patient or a whole population in a documented, computable format.
What are the layers of EHR interoperability?
The diagram stacks the layers from transport to governance and names the standard at each one. Every working integration touches all of them, whether the team notices or not.
- Transport and security: HTTPS and OAuth 2.0 for APIs, MLLP for HL7 v2, Direct for secure messaging, with TLS and audit logging throughout.
- Format: FHIR R4 resources for APIs, HL7 v2 messages for events such as admissions, orders and results, C-CDA documents for transitions of care.
- Content: USCDI data classes with US Core profiles, so a Condition or Observation carries the same required elements everywhere.
- Vocabulary: SNOMED CT, LOINC, RxNorm, ICD-10-CM and CVX, so codes mean the same thing on both sides.
- Identity: Patient matching across organizations, and identity for users and apps through SMART App Launch.
- Governance: Consent, data use agreements and network participation, which TEFCA and the information blocking rules now frame nationally.
Which path for which job
Use the FHIR API when an app needs specific data about a patient or a cohort, and SMART App Launch when it runs in a user's context. Use HL7 v2 feeds when you need events as they happen, such as an admission or a result. Use C-CDA documents and network queries when you need another organization's record for a transition of care. Use Bulk Data when you need a population for analytics or quality measures.
Networks and the last mile
TEFCA and the vendor networks that connect to it give an EHR a way to find and fetch records from organizations it has never integrated with directly. The last mile is still local: the received document has to be reconciled into the chart, the patient matched, and the data coded so it counts. That reconciliation work is where most interoperability projects spend their time.
Patient matching is the quiet failure
Most interoperability failures are identity failures: two records for one patient, or one record for two. Match on several identifiers with confidence thresholds, route doubtful matches to a person, and log every merge and split so they can be undone. The best exchange attaches the wrong result to the wrong patient if matching is weak.
Conformance testing and the yearly cycle
US Core and USCDI change on a yearly cadence, and certified EHRs update with them. Test against the published US Core profiles and ONC's Inferno test kits, keep mappings versioned, and re-run conformance tests when a partner upgrades. Interoperability is maintained, not achieved.
How do teams build EHR interoperability step by step?
- 1. Name the exchanges: Who needs what data, when, and in which direction, as a list of use cases.
- 2. Pick the path per use case: FHIR API, SMART app, HL7 v2 feed, document exchange, bulk data or network query.
- 3. Profile to US Core and USCDI: Map your data model to the required elements and code systems.
- 4. Build identity first: Patient matching rules, SMART authorization and audit logging.
- 5. Implement and test conformance: Against US Core, Inferno test kits and partner test environments.
- 6. Connect the networks: Direct addresses, vendor networks or TEFCA participation through a QHIN, with the agreements signed.
- 7. Reconcile on receipt: Workflows that bring external data into the chart with clinician review where needed.
- 8. Monitor and version: Interface health, API errors and the yearly USCDI and US Core updates.
What are EHR interoperability best practices?
- Standards over custom: FHIR, HL7 v2, C-CDA and X12 as published, with profiles instead of local variants.
- Code everything: Structured, coded data at capture, with the original text kept alongside.
- Match patients deliberately: Several identifiers, confidence thresholds and human review of doubtful matches.
- Least privilege for apps: Scopes limited to the resources the use case needs.
- Reconcile, do not dump: External documents reviewed and merged, not appended as attachments nobody reads.
- Monitor every interface: Volume, latency and errors with alerts, because silent failures are the norm.
- Track the calendar: USCDI versions, US Core updates, TEFCA changes and the payer API dates.
The practices above are what makes exchanged data usable. The mistakes below are why so much exchanged data is never used.
What are the common mistakes with EHR interoperability?
- Connectivity declared as interoperability: Data arrives and nobody reconciles it into the chart.
- Free text everywhere: Problems and results stored without codes, so they cannot be exchanged or counted.
- Patient matching by name and birth date alone: Duplicates and merges that corrupt records.
- Custom formats: Point-to-point interfaces that break when either side upgrades.
- Ignoring information blocking: Policies or fees that delay access, exchange or use.
- No one watching the feeds: Interfaces that stop for days before anyone notices.
What does EHR interoperability mean for your build plan?
- Use cases and paths: Each exchange is a design, build and test item with a standard attached.
- Profiling: US Core and USCDI mapping of your data model.
- Identity: Patient matching and SMART authorization.
- Networks: Agreements and onboarding for Direct, vendor networks or TEFCA.
- Reconciliation: Workflows and screens for external data.
- Operations: Monitoring, conformance re-testing and yearly standards updates.
For the integration methods themselves, our EHR integrations guide covers vendors and costs, and our FHIR integration guide covers the API in depth.
How Agnotic can help
Agnotic Technologies is a software development services company. We build EHR interoperability for digital health companies and health systems: FHIR APIs and facades profiled to US Core, SMART on FHIR apps, HL7 v2 interfaces and engines, C-CDA and network exchange, bulk data pipelines, patient matching and the reconciliation workflows that make received data usable, with HIPAA safeguards designed in. The standards are set. We make them work in your systems.
Build your EHR interoperability with Agnotic
Explore our EHR integration services or browse more articles in our EHR integration hub.
Related reading on Agnotic
Go deeper on the standards, networks and integration topics covered in this guide.
Sources
- ASTP/ONC: Standardized API for patient and population services, 170.315(g)(10)
- ASTP/ONC: United States Core Data for Interoperability (USCDI)
- 45 CFR Part 171: Information blocking
- ASTP/ONC: Trusted Exchange Framework and Common Agreement (TEFCA)
- HHS: TEFCA network passes one billion health records exchanged
- CMS: Interoperability and Prior Authorization final rule (CMS-0057-F)
- ASTP/ONC: Electronic health information export, 170.315(b)(10)
- HL7: US Core Implementation Guide
