How Does Data Interoperability Work in an EHR? FHIR, C-CDA, and Direct Messaging Explained

TL;DR

• EHR interoperability is not one standard. It is three standards that solve different problems: FHIR for real-time API queries, C-CDA for structured clinical documents, and Direct messaging for secure transport between organizations. Most transitions of care use all three at different points.
• FHIR answers the question "give me this specific data element now." C-CDA answers "send me the whole clinical summary for this visit." Direct messaging answers "move that summary from my organization to yours without email being intercepted."
• ONC certification under the 21st Century Cures Act treats these as distinct criteria: the standardized FHIR API (g)(10), transitions of care with C-CDA (b)(1), and Direct secure transport (h)(1). A product can pass one and still leave real gaps in the others.
• The real gap is rarely the transport. It is what happens after the data arrives. A C-CDA that lands as an unparsed attachment in an inbox is technically interoperable and clinically useless. Thyra is an AI-powered EHR that resolves inbound FHIR, C-CDA, and Direct messaging data into the same patient context its Smart Inbox, Longitudinal AI Scribe, CGM viewer, and orders already use, and can run alongside an existing EHR through a SMART on FHIR overlay.

When a patient moves from a hospital to your endocrinology clinic, their data has to travel too. That transfer looks simple from the outside and is not. Behind a single referral, three different interoperability standards are usually doing three different jobs, and each one has its own failure mode. Understanding which standard does what is the difference between an IT administrator who can evaluate a vendor honestly and one who is trusting a demo.

What does data interoperability actually mean in healthcare?

Data interoperability is the ability of two systems to exchange clinical data and use it, not just receive it.

The Healthcare Information and Management Systems Society (HIMSS) describes levels of interoperability, from foundational (systems can send and receive) to semantic (both systems interpret the meaning the same way). The distinction matters because most failures are not connectivity failures. The message arrives; the receiving system just cannot reliably parse its codes or place it into a workflow. That semantic gap is where interoperability usually breaks.

Why do three standards exist instead of one?

Three standards exist because moving data involves three separable problems: querying it, packaging it, and transporting it.

The cleanest way to hold them apart is by the job each does: FHIR is a query standard, C-CDA is a document standard, and Direct messaging is a transport standard. They are not competitors, and choosing between them is usually the wrong frame. A single transition of care often uses Direct messaging to move a C-CDA document while a clinician separately uses a FHIR API to pull a specific lab result in real time. The better question for an IT administrator is not "which standard does this vendor support" but "does this vendor support the right standard at each step, and does the data become usable once it lands."

The quickest way to keep the three straight is to match each to the clinical question it answers best.

How does FHIR work?

FHIR (Fast Healthcare Interoperability Resources) is an API standard that lets one system request specific, structured clinical data elements from another in real time.

Instead of exchanging whole documents, FHIR breaks clinical data into discrete resources: Patient, Observation, MedicationRequest, Condition, AllergyIntolerance, and dozens more. Each resource is retrievable over a standard REST API, so an application can ask for exactly one patient's most recent hemoglobin A1c rather than downloading an entire chart. FHIR Release 4 (R4) is the version the Office of the National Coordinator (ONC) requires for certified EHRs under the standardized API criterion, the constraints are defined by the HL7 US Core Implementation Guide, and the required data elements are governed by the United States Core Data for Interoperability (USCDI). Under ONC's HTI-1 final rule, USCDI v3 became the required baseline for certified health IT as of January 1, 2026, expanding the standardized data classes an EHR must exchange. For population-level needs, the FHIR Bulk Data specification, sometimes called Flat FHIR, exports many patients at once rather than one query at a time.

What is SMART on FHIR?

SMART on FHIR is the authorization layer that lets a third-party application securely connect to an EHR's FHIR API using standard OAuth 2.0 and OpenID Connect.

FHIR defines how data is shaped. SMART on FHIR defines how an app is trusted to read or write it, which scopes it is granted, and how the user's identity is confirmed. This is what makes an overlay model possible. An application can launch inside or alongside an existing EHR, request scoped access to the FHIR API, and operate on live data without a full rip-and-replace migration. For a deeper treatment of the underlying resource model, see why FHIR R4 is the foundation for modern EHR interoperability.

Where does FHIR fall short?

FHIR is excellent for granular, real-time queries and weaker for conveying a complete, human-readable narrative of a single encounter.

If a clinician needs the discharge summary of a specific hospitalization, assembling it from individual FHIR resources is awkward. That is the job a document standard does better, which is why C-CDA has not disappeared even as FHIR adoption has grown.

How does C-CDA work?

C-CDA (Consolidated Clinical Document Architecture) is an XML standard for packaging a complete clinical document, such as a Continuity of Care Document, so it is both human-readable and machine-parsable.

A C-CDA document carries a full snapshot: problems, medications, allergies, results, immunizations, and a readable narrative, all in a structured format the receiving system can ingest. C-CDA Release 2.1 defines document templates such as the Continuity of Care Document, the Referral Note, and the Discharge Summary, and each section carries coded entries using standard vocabularies: SNOMED CT for problems, RxNorm for medications, LOINC for labs. This is the standard most transitions of care rely on. When a hospital discharges a patient to your clinic, the summary that follows is usually a C-CDA. Under ONC's certification program, exchanging these documents is tested as the transitions-of-care criterion (b)(1), and the required content is again governed by USCDI.

Why do C-CDA documents so often arrive as clinical noise?

C-CDA documents fail in practice when the receiving system stores them as attachments instead of resolving their contents into the chart.

A structurally valid C-CDA can still be useless if it lands in an inbox as a multi-page document that a clinician has to open, scroll, and manually reconcile against the existing record. The data is technically present. The workflow to act on it is not. This is the semantic-and-workflow gap in its most common form, and it is why "we support C-CDA" is a claim that deserves a follow-up question: does the inbound document reconcile allergies, medications, and problems into the patient's live record, or does it just sit there. The distinction between storing data and assembling a usable clinical picture is the same one covered in AI safety and governance in clinical workflows.

How does Direct messaging work?

Direct Secure Messaging, often shortened to Direct messaging, is a secure transport standard, similar in feel to encrypted email, that moves clinical content such as a C-CDA between organizations without exposing it in transit.

Direct messaging addresses look like email addresses but run over S/MIME encryption with X.509 certificates and trust bundles, typically brokered by Health Information Service Providers (HISPs) and anchored by accreditation bodies such as DirectTrust. A referring physician can push a C-CDA to a specialist's Direct messaging address, and a Message Disposition Notification confirms delivery, so both sides can trust that the sender is verified and the content was not intercepted. Under ONC certification, Direct messaging transport is tested separately as the (h)(1) criterion, and inter-HISP exchange depends on both organizations sharing a common trust bundle.

How do FHIR, C-CDA, and Direct messaging fit together in one referral?

In a typical referral, Direct messaging transports a C-CDA document, while FHIR handles the real-time queries that happen before and after.

Consider Emily, an endocrinologist receiving a new diabetes patient from a hospital. The discharge team sends a C-CDA summary to her clinic's Direct messaging address. That is C-CDA content over Direct messaging transport. Before the visit, her EHR uses a FHIR query to pull the most recent A1c and creatinine values so she is not reading stale numbers. That is FHIR. Three standards, one clinical event, each doing the job it is best at.

What are the most common ways interoperability fails in practice?

Most interoperability failures happen after a valid message arrives, at the point where the receiving system has to reconcile it, not at the point of transport.

Connectivity is rarely the hard part anymore. National data supports this. ONC data briefs built on the American Hospital Association IT Supplement have consistently found that while roughly seven in ten hospitals electronically send and receive summary-of-care records, only about four in ten report that clinicians often have that outside information available and actually use it at the point of care. The exchange happened. The integration did not. The recurring failures cluster in a few predictable places, and knowing them is what lets an IT administrator pressure-test a vendor claim.

• Unmapped local codes. A sending hospital labels a problem with a local or proprietary code instead of SNOMED CT, so the receiving system cannot match it to an existing problem and either drops it or creates a duplicate. This is the single most common reason a structurally valid C-CDA does not reconcile cleanly.
• Medication vocabulary mismatch. Medications coded in NDC on one side and RxNorm on the other do not line up automatically, which produces duplicate or unrecognized medication entries that a clinician then reconciles by hand.
• Narrative without structured entries. Some C-CDA sections carry a human-readable narrative block but no coded entries underneath. The document looks complete to a person and is nearly empty to the parser.
• USCDI version drift. A sender built to USCDI v1 and a receiver expecting v3 will exchange documents that validate but omit newer data classes, so the gap is silent rather than an error.
• Trust bundle mismatches on Direct messaging. Two organizations can both support Direct messaging and still fail to exchange because their HISPs do not share a common trust bundle, which surfaces as a bounced message rather than a clinical alert.
• FHIR scope misconfiguration. A SMART on FHIR app granted the wrong scopes either cannot read the resource it needs or, worse, is over-provisioned, which is a governance and audit problem rather than a data problem.

What is a practical decision rule for evaluating interoperability?

The decision rule is simple: ask the vendor to show a live inbound exchange and watch what the record looks like sixty seconds after the data lands.

If a C-CDA arrives and its medications, allergies, and problems appear as reconciled, coded entries in the patient record, the interoperability is real. If it arrives as a document you have to open and retype, the vendor has foundational interoperability but not the semantic layer that makes it clinically useful. The same test applies to FHIR: a granted scope should produce a specific, coded value in context, not a raw payload a human has to interpret. Passing a certification criterion proves the capability exists in a test harness. It does not prove the data becomes usable in your clinic's workflow, which is why the live demonstration matters more than the checklist.

Why does interoperability matter more for endocrinology and primary care?

Endocrinology and primary care are longitudinal and data-dense, so they feel interoperability gaps more acutely than episodic specialties.

A diabetes patient generates A1c trends, CGM summaries, renal function, lipids, medication changes, and messages across many encounters and often several organizations. Each transition is a chance for data to arrive as an unreconciled document or not arrive at all. When that happens, the clinician rebuilds context by hand, and the after-hours workload grows. The interoperability problem and the inbox-burden problem are the same problem viewed from two angles, a pattern explored in why after-hours clinician work is an operational risk problem.

For Linda, a healthcare IT administrator, a checkbox that says "C-CDA supported" means little. The operational question is whether inbound medications and allergies reconcile into the record and whether every inbound and AI-assisted action is logged, which maps directly to the auditability concerns in any serious ONC certification evaluation.

How Thyra approaches interoperability

Thyra treats FHIR, C-CDA, and Direct messaging as inputs into a single clinical context rather than as separate inboxes.

Thyra is a full EHR for endocrinology and primary care that can run alongside an existing system through a SMART on FHIR overlay. Its design goal for interoperability is that inbound data resolves into the same record the clinician is already working in, so a reconciled C-CDA or a new FHIR result becomes an action rather than another document to triage. For teams weighing whether to start with an overlay or a full migration, the tradeoffs are covered in when it makes sense to try an overlay instead of switching EHRs.

Frequently Asked Questions

How does data interoperability work with FHIR, C-CDA, and Direct messaging?

They work together by dividing the job. FHIR is an API standard for querying specific, structured data elements in real time. C-CDA is a document standard for packaging a complete clinical summary that is both human-readable and machine-parsable. Direct messaging is a secure transport standard that moves content such as a C-CDA between organizations. A single transition of care commonly uses Direct messaging to send a C-CDA while FHIR handles the live lookups around it, so the standards are complementary rather than competing.

Is FHIR replacing C-CDA?

Not entirely, and not soon. FHIR is better for granular, real-time queries, while C-CDA is better for conveying a complete, human-readable narrative of an encounter. Many workflows, especially transitions of care, still depend on document exchange, and ONC certification continues to test both. The practical trend is convergence, where FHIR-based document and bulk-data capabilities grow, but most organizations will exchange both formats for years.

What is the difference between Direct messaging and a FHIR API?

Direct messaging is about transport and FHIR is about data access. Direct messaging securely pushes content from one organization to another, like an encrypted message with a verified sender. A FHIR API lets a system or app pull specific data elements on demand. Direct messaging moves a package; FHIR answers a question. A complete interoperability strategy uses both, because pushing a summary at a transition and querying a value in real time are different needs.

How is interoperability tested for ONC certification?

The ONC Health IT Certification Program under the 21st Century Cures Act tests these capabilities as separate criteria. The standardized API is criterion (g)(10) and is FHIR-based. Transitions of care using C-CDA are criterion (b)(1). Direct secure transport is criterion (h)(1). Because they are distinct, a product can be certified for one and still have real limitations in another, which is why IT administrators should ask which specific criteria a vendor holds rather than accepting a general interoperability claim.

Why does a valid C-CDA sometimes still fail clinically?

Because structural validity does not guarantee workflow usability. A C-CDA can be perfectly formed and still land as an attachment that a clinician must open and manually reconcile. The data is present but not integrated. Real interoperability is measured by whether inbound problems, medications, and allergies reconcile into the live patient record, not by whether the document passed a schema check. This is the semantic and workflow layer where most interoperability value is won or lost.

About the Author

Jean Jacques Nya Ngatchou, MD is a board-certified endocrinologist and the founder of Thyra, an AI-powered EHR for specialty and primary care workflows. He previously practiced at Optum and completed his endocrinology fellowship at the University of Washington. Thyra is backed by INSEAD AI Venture Lab and Google Cloud for Startups.

References

1. Office of the National Coordinator for Health IT (ONC). ONC Health IT Certification Program and the 21st Century Cures Act Final Rule.
2. ONC / ASTP Data Briefs on hospital interoperability, drawn from the American Hospital Association IT Supplement (send, receive, find, and integrate measures).
3. ONC HTI-1 Final Rule (2024), establishing USCDI v3 as the certification baseline effective January 1, 2026.
4. HL7 International. FHIR Release 4 (R4) specification and US Core Implementation Guide.
5. HL7 International. Consolidated CDA (C-CDA) Release 2.1 Implementation Guide.
6. DirectTrust. Direct secure messaging standards and trust framework.
7. United States Core Data for Interoperability (USCDI) data classes and elements.
8. Healthcare Information and Management Systems Society (HIMSS). Interoperability in Healthcare definitions.
9. Why FHIR R4 Is the Foundation for Modern EHR Interoperability — https://thyrahealth.com/blog/2026/01/fhir-r4-foundation/
10. ONC Certification: What New EHR Vendors Need to Know in 2026 — https://thyrahealth.com/blog/2025/12/onc-certification-new-ehr-vendors-2026/