Electronic Health Record Sharing: Interoperability Guide

Sharing electronic health records across systems means reconciling at least four standards: HL7 FHIR R4 for API-based exchange, C-CDA R2.1 for document-based transfer, HL7 v2.x for legacy messaging, and DICOM for imaging. USCDI v3 defines the minimum data set US providers must make shareable, and TEFCA establishes the governance layer through Qualified Health Information Networks. When a record moves between Epic and Cerner/Oracle Health, it's typically through Carequality's framework wrapping C-CDA documents over IHE XCA profiles. When it moves to a patient's phone app, it's through SMART on FHIR with OAuth 2.0.

The Standards Stack You're Actually Working With

Health record interoperability looks like a standards salad because it is one. Here's what each layer does:

HL7 v2.x — pipe-delimited messages from the 1990s, still the workhorse for lab orders, ADT (admit/discharge/transfer) feeds, and order management inside a hospital. Not suitable for cross-organization sharing.
C-CDA R2.1 — structured XML documents representing a patient summary, discharge summary, or referral note. The backbone of Direct messaging and most HIE exchange.
HL7 FHIR R4 — RESTful resources (Patient, Observation, Condition, MedicationRequest) exchanged over HTTPS with JSON or XML. The modern layer, required by ONC Cures Act rules for certified EHRs.
DICOM — imaging standard, moves through its own pipes (DIMSE, DICOMweb).
USCDI v3 — the required data classes and elements every certified EHR must expose, including clinical notes, social determinants, and sexual orientation/gender identity.

When you "share an EHR," you're really sharing fragments from each layer, stitched into the right format for the receiver.

FHIR APIs and the Information Blocking Rule

The ONC's 21st Century Cures Act Final Rule (45 CFR Part 171) makes information blocking a prohibited practice starting May 2020, with civil money penalties up to $1 million per violation for certain actors under the 2023 HHS final rule. The technical requirement: certified EHR technology must expose a FHIR R4 API supporting the USCDI data set.

For a developer integrating with Epic, Cerner, athenahealth, or eClinicalWorks, that means:

Register an app in the vendor's developer portal (Epic on FHIR, Cerner Code, athenahealth Developer Portal).
Use SMART on FHIR launch sequence with OAuth 2.0 and PKCE.
Request scopes like patient/*.read or specific resources.
Receive JSON bundles on HTTPS.

The practical gotcha: API scopes, rate limits, and production access vary wildly between vendors. Epic's production access requires a signed Payer-Provider or specialty-app agreement. Cerner's sandbox is faster to access but has different auth flows.

C-CDA: Still the Default for Cross-Organization Summaries

Despite FHIR's rise, most cross-organization record exchange still ships C-CDA documents. A Continuity of Care Document (CCD) under C-CDA R2.1 typically runs 200 KB-2 MB of XML with embedded HTML for human readability. Key templates:

CCD (Continuity of Care Document)
Discharge Summary
Referral Note
Consultation Note
Progress Note

These flow through Direct messaging (S/MIME over SMTP) or query-based HIE exchange. The receiving EHR parses the XML and ingests structured elements into the local record. Parsing quality varies — some EHRs ingest problem lists cleanly but drop social history. Data reconciliation stays a manual step at most clinics.

TEFCA, QHINs, and the National Network Strategy

The Trusted Exchange Framework and Common Agreement (TEFCA), finalized by ONC in January 2022 and operational since 2023, creates a network-of-networks. Qualified Health Information Networks (QHINs) like eHealth Exchange, Epic's Carequality bridge, and Health Gorilla connect to each other through the Common Agreement.

From the sending clinician's perspective, TEFCA means: query once, reach participants across QHINs, for Treatment, Payment, Health Care Operations, Public Health, Government Benefits Determination, Individual Access Services, and Coverage use cases.

From the IT director's perspective, TEFCA means a governance layer on top of existing IHE profiles, not a new protocol to implement.

When APIs Fail and You Need a File Transfer

Despite all the standards, clinicians regularly need to move a file that doesn't fit any API. Examples:

A 300 MB PDF bundle of scanned paper records from before the clinic went electronic
A research dataset in SAS or Stata format for a retrospective review
A set of wound photos from home health that don't need to clutter the image server
Legal hold records for a pending malpractice case

For these, you fall back to encrypted file transfer. The requirements: HIPAA-compliant (BAA signed), AES-256-GCM encryption at rest, TLS 1.3 in transit, audit logging, and link expiration. Whether that tool is a built-in Epic feature, a hospital-approved enterprise service, or an ad-hoc browser-based transfer depends on your governance.

HexaTransfer offers the ad-hoc pathway with client-side encryption before upload. Try it at hexatransfer.com — free, no account, 10 GB max. Log the transfer in your standard audit record so you can account for it later.

Patient Matching and the Identity Problem

Sharing a record requires knowing it's the right patient. The US has no national patient identifier (thanks to a 1998 appropriations rider that's been renewed every year since), so identity resolution relies on probabilistic matching on name, date of birth, sex, address, and phone. The Sequoia Project's Patient Matching Framework recommends at least 7 demographic attributes for cross-organization matching.

Match rates in production networks run 70-95% depending on data quality. Miss rates translate to missing records at the point of care and duplicate records cluttering the downstream chart. Many QHINs now add referential matching through third-party databases to boost accuracy.

For file-level transfers, always include patient identifiers in the filename or a cover sheet — MRN, date of birth, and at least one additional identifier. Don't rely on the clinician to know which patient "Jane-S-MRI.dcm" belongs to.

Consent, Segmentation, and 42 CFR Part 2

Not all records share equally. 42 CFR Part 2 restricts sharing of substance use disorder records from federally-assisted programs, with higher consent requirements than general HIPAA authorization. After the 2024 SAMHSA rule aligning Part 2 more closely with HIPAA, a single patient consent can enable broader sharing, but the records still need to carry a prohibition on redisclosure notice.

Behavioral health, HIV, genetic, and reproductive health records often have state-specific sharing rules. California AB 254 on reproductive and gender-affirming care added 2023 protections. New York's state HIE has data segmentation for sensitive categories.

If your transfer tool can't honor segmentation — can't flag which parts of a document need extra consent — don't use it for mental health records. Use it for the orthopedic follow-up packet.

Audit and Accounting of Disclosures

HIPAA's Accounting of Disclosures (45 CFR 164.528) gives patients the right to a list of disclosures made in the prior 6 years. For treatment disclosures, there's an exception, but payment, operations, and permitted-purpose disclosures still have to be tracked.

Your transfer system's audit log feeds this accounting. Capture:

Timestamp in UTC
Sender and recipient organizations
Purpose code (TREATMENT, PAYMENT, OPERATIONS, AUTHORIZATION, etc.)
Data categories transferred
Patient ID

If you rely on a generic file-sharing tool that only logs "user X uploaded file Y," you'll scramble when a patient requests an accounting.

Small Practices and the Resource Gap

A 3-provider primary care practice doesn't have a CIO. They have an office manager who handles IT alongside billing. They still have to produce USCDI-compliant records on demand, sign BAAs with every vendor, and handle information blocking complaints. The practical approach:

Use an EHR (athenahealth, Elation, DrChrono) that handles Direct, FHIR, and patient API out of the box.
Pick one ad-hoc encrypted transfer tool with a BAA for everything the EHR can't send.
Document the workflow in a one-page SOP.
Train every staff member on the two tools they'll use weekly.

Electronic health record sharing isn't a single-vendor problem to solve. It's a layered workflow to maintain. Get the standards right where you can, and have a clean encrypted fallback for the cases that standards don't cover.