Healthcare Interoperability & Compliance Guide (2026)

Healthcare interoperability sounds like a technical problem. It isn't — or at least, not primarily. The technical standards (HL7, FHIR, DICOM, X12) have existed for decades, and the tools to use them are mature. What makes interoperability hard in 2026 is that every layer of the stack is regulated— and those regulations interact in ways that can quietly sink a product launch if you don't know the terrain.

This pillar guide is the non-technical-leader companion to our deep pillars on Mirth Connect, HL7 v2, FHIR R4, and EHR integration. Where those guides tell you how to move healthcare data, this one tells you what rules you must follow, which frameworks to certify against, which networks to join, and which standards beyond HL7/FHIR you cannot avoid.

1. What Is Healthcare Interoperability?

Healthcare interoperability is the ability of different health information systems, devices, and applications to access, exchange, integrate, and cooperatively use data in a coordinated manner — within and across organizational, regional, and national boundaries.

In plain terms: when a patient moves from primary care to a specialist to a hospital to a pharmacy, every one of those systems needs to see the same patient record, the same medications, the same allergies, the same recent labs. Every time that data is incomplete or wrong, a clinical mistake becomes more likely — and every time that data is shared without proper authorization, a HIPAA violation becomes more likely. Interoperability is the discipline of solving both problems at once.

The US healthcare interoperability ecosystem in 2026 is the result of 30+ years of standards development, two major federal laws, several voluntary frameworks, and two national data-exchange networks — layered on top of each other, sometimes harmoniously, sometimes not. Understanding the full picture lets you choose where to focus your own compliance and engineering investment.

2. The Four Layers of Interoperability

The Healthcare Information and Management Systems Society (HIMSS) defines four levels of interoperability. The model is useful because most integration projects succeed at the lower layers and fail at the upper ones.

Level	What It Covers	Example
1. Foundational	Two systems can transmit data to each other.	MLLP connection established; HTTP handshake succeeds.
2. Structural	Data format is preserved; fields are parseable.	ADT^A01 is received and all segments parse correctly.
3. Semantic	Both systems assign the same meaning to the data.	"K" in PID-8 means "unknown sex" on both ends.
4. Organizational	People and processes around the data are coordinated.	The clinician acts on the received discharge summary.

Most projects ship level 2 interoperability and claim victory. The clinical and regulatory value lives at level 3 and level 4. Budget your integration work — and your compliance posture — accordingly.

3. HIPAA: The Floor, Not the Ceiling

The Health Insurance Portability and Accountability Act of 1996, and specifically its Privacy Rule (2003), Security Rule (2005), Breach Notification Rule (2009), and subsequent HITECH Act amendments, is the baseline legal requirement for handling protected health information (PHI) in the United States.

3.1 Who is covered

Covered entities — health plans, healthcare clearinghouses, and most healthcare providers.
Business associates — any person or company that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Nearly every healthtech vendor falls here.

3.2 The Security Rule's technical safeguards

What your integration layer actually must implement:

Access control — unique user identifiers, emergency access procedures, automatic logoff, and ideally encryption at rest and in transit.
Audit controls — mechanisms to record and examine activity in systems that use PHI.
Integrity controls — verification that PHI has not been altered or destroyed.
Transmission security — protecting PHI as it moves across networks (effectively: TLS).

In practice, a defensible HIPAA posture for an integration platform includes:

TLS 1.2+ on every listener and sender (see section 17 of our HL7 integration guide).
Named user accounts with role-based access control.
Audit logs shipped to a SIEM and retained for six years.
Encryption at rest on all storage containing PHI.
Documented breach notification playbook.
Executed Business Associate Agreement (BAA) with every covered entity you serve.

3.3 HIPAA is necessary but not sufficient

A common mistake is treating HIPAA as the endpoint of compliance. It is the legal floor. Customers, payers, and regulators increasingly expect attestations beyond HIPAA — HITRUST CSF, SOC 2 Type II, PCI-DSS for payment flows, and others covered below.

4. The ONC 21st Century Cures Act

The 21st Century Cures Act, signed into law in 2016, and the subsequent ONC Final Rule published in 2020, are the two most consequential US regulations for modern healthcare interoperability since HIPAA.

The core mandates:

Certified EHRs must expose FHIR R4 APIs conformant to the US Core Implementation Guide.
Patient access APIs must be available without special effort, fees, or contracts for the patient.
Information blocking is prohibited (see section 5).
APIs must support bulk data access per the FHIR $export operation for population-level use cases.

If you are building a patient-facing application, the Cures Act is on your side — it is the reason every major EHR now has a FHIR API your app can use. If you are an IT developer certified under the ONC Health IT Certification Program, the Cures Act is what you are audited against. More detail in our FHIR R4 Integration Complete Guide.

5. Information Blocking

Information blocking — under the Cures Act — is any practice by a health IT developer, health information network, or healthcare provider that is likely to interfere with access, exchange, or use of electronic health information (EHI), except as required by law or covered by a specific regulatory exception.

5.1 The eight exceptions

Regulation defines eight exceptions where information blocking is permitted. They fall into two groups:

Exceptions for NOT fulfilling requests:

Preventing Harm
Privacy
Security
Infeasibility
Health IT Performance

Exceptions for procedures, fees, and licensing:

Content and Manner
Fees
Licensing

Each exception has specific conditions. "We don't want to" is not among them. Simply being unable to fulfill a request on technical grounds does not automatically qualify — the exception must actually fit.

5.2 Penalties are real

The HHS Office of the Inspector General can impose civil monetary penalties of up to $1 million per violationon IT developers and health information networks. Providers are subject to "appropriate disincentives" from CMS, which in practice has meant reductions in Medicare reimbursement for hospitals found to have engaged in information blocking.

If you are a health IT developer or health information network, information blocking policy and supporting technical controls belong in your compliance program from day one — not as an afterthought.

6. CMS Payer Interoperability Rules

A separate line of federal rulemaking has put similar obligations on payers.

CMS Interoperability and Patient Access Final Rule (2020) — requires Medicare Advantage, Medicaid, and ACA-marketplace payers to expose Patient Access FHIR APIs, Provider Directory APIs, and Payer-to-Payer data exchange.
CMS Advancing Interoperability and Improving Prior Authorization Final Rule (2024) — requires impacted payers to provide Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization FHIR APIs with specific deadlines through 2027.

If your product sells to or exchanges data with payers, these rules are directly relevant. Plan for FHIR R4 endpoints implementing the Da Vinci and HL7 US Core profiles that CMS specifies.

7. HITRUST CSF

HITRUST CSF (Common Security Framework) is a certifiable framework developed by the HITRUST Alliance that incorporates and harmonizes HIPAA, ISO 27001, NIST, PCI-DSS, GDPR, and many other authoritative sources into a single auditable control set.

7.1 Why it matters

Large health systems and payers increasingly require HITRUST certification as a prerequisite for vendor contracts. A HITRUST-certified vendor saves the customer from assessing HIPAA controls themselves. That means certification can measurably shorten enterprise sales cycles.

7.2 Levels of assessment

e1 (1-year) — a limited assessment for lower-risk engagements.
i1 (1-year) — a fixed set of prescribed controls.
r2 (2-year) — the classical HITRUST risk-based assessment, covering a tailored control set based on your organization's profile.

7.3 Realistic investment

A first-time r2 assessment typically takes 6–12 months and costs $150K–$500K all-in (consulting, tooling, assessor fees, internal time). Ongoing maintenance is lighter but continuous. For many healthtech products, this is a worthwhile investment that directly unblocks enterprise deals.

8. SOC 2 in Healthcare Context

SOC 2 (Service Organization Control 2) is an audit framework from the AICPA covering five trust service criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

SOC 2 is not healthcare-specific — it originated as a general-purpose attestation for cloud service providers. But nearly every healthcare enterprise expects a SOC 2 Type II report in vendor due diligence, often alongside (not instead of) HITRUST.

Practical notes:

Type I attests that controls are designed effectively at a point in time. Useful for new companies; limited credibility on its own.
Type II attests that controls operated effectively over a period (typically 6–12 months). This is what buyers actually want to see.
SOC 2 overlaps heavily with HIPAA Security Rule and HITRUST — you rarely design two control programs, you design one and report it through multiple lenses.

9. TEFCA and the Trusted Exchange Framework

TEFCA — the Trusted Exchange Framework and Common Agreement — is the federally overseen national-scale health information exchange framework established under the Cures Act. It went operational in late 2023.

9.1 How it works

Organizations called Qualified Health Information Networks (QHINs) interconnect to form a nationwide exchange. Participants (hospitals, payers, labs, health apps) connect to a QHIN and, through it, can exchange data with participants of other QHINs nationwide.

9.2 What's exchanged

TEFCA supports six defined "exchange purposes":

Treatment
Payment
Health Care Operations
Individual Access Services
Public Health
Government Benefits Determination

TEFCA traffic initially flowed primarily over IHE-based document exchange (XDR, XCA), with FHIR-based exchange rolling out as a second production phase.

9.3 Why it matters

TEFCA is the long-term replacement for the patchwork of private networks (Carequality, CommonWell, eHealth Exchange) that previously provided national exchange. By 2027–2028, TEFCA is likely to be the default path for nationwide data retrieval. If you are building anything that relies on cross-organizational patient data, TEFCA should be on your product roadmap.

10. Carequality and CommonWell

Before TEFCA, two private networks dominated cross-organizational exchange in the US.

10.1 Carequality

A national trust framework connecting health IT vendors, HIEs, payers, and providers. Carequality defines legal agreements and technical specifications allowing participants to exchange data without individual one-to-one contracts.

10.2 CommonWell Health Alliance

A not-for-profit trade association founded by major EHR vendors (originally Cerner, McKesson, Allscripts, athenahealth, Greenway, RelayHealth) to enable cross-EHR patient record lookup.

10.3 How they interrelate

In 2016 Carequality and CommonWell signed an agreement enabling bidirectional exchange between their networks. Together they cover the vast majority of US healthcare data exchange that existed before TEFCA. Most EHR vendors participate in at least one, and connecting to their network through your EHR is often a one-click operation for the customer.

Both networks continue to operate in parallel with TEFCA. Over time TEFCA is expected to absorb most of their workload, but for now any comprehensive interoperability strategy should consider all three.

11. IHE Profiles: XDS, PIX, PDQ, and More

IHE (Integrating the Healthcare Enterprise) is an initiative that publishes implementation profiles — practical, testable specifications that combine existing standards (HL7, DICOM, FHIR, W3C) into well-defined workflows.

The profiles you are most likely to encounter:

XDS.b (Cross-Enterprise Document Sharing) — document sharing via a registry/repository model. Underpins most regional HIE document exchange.
XCA (Cross-Community Access) — federated queries across XDS affinity domains.
PIX (Patient Identifier Cross-Referencing) — linking patient identifiers across systems.
PDQ (Patient Demographics Query) — searching for patients by demographics.
ATNA (Audit Trail and Node Authentication) — audit logging and certificate-based authentication.
XDR (Cross-Enterprise Document Reliable Interchange) — direct SOAP-based document exchange.
mHealth Application (PIXm, PDQm) — FHIR-based successors of PIX and PDQ for mobile contexts.

If you are connecting to a state HIE, participating in TEFCA, or exchanging C-CDA documents across organizations, IHE profiles are almost certainly involved.

12. X12 EDI: The Payer Standard

Every financial transaction between providers and payers in the United States is governed by X12 EDI — electronic data interchange transactions standardized by the Accredited Standards Committee X12.

The transactions that matter most:

Transaction	Purpose
270	Eligibility, coverage, or benefit inquiry
271	Eligibility, coverage, or benefit response
276	Claim status request
277	Claim status response
278	Authorization request/response
820	Payroll deduction and premium payment
834	Benefit enrollment and maintenance
835	Health care claim payment / remittance advice
837	Health care claim (P for professional, I for institutional, D for dental)

HIPAA mandates X12 versions (currently 5010) for most of these transactions. If your product sells to payers, processes claims, does benefits eligibility, or handles enrollment, X12 is unavoidable.

Mirth Connect handles X12 natively alongside HL7 and FHIR, which is why many platforms that process both clinical and financial data consolidate on a single engine.

13. DICOM: The Medical Imaging Standard

DICOM (Digital Imaging and Communications in Medicine) is the standard for storing, transmitting, and displaying medical imaging — X-rays, CT, MRI, ultrasound, and more.

Key DICOM services:

C-STORE — store an image in a PACS (Picture Archiving and Communication System).
C-FIND — search for studies in a PACS.
C-MOVE / C-GET — retrieve images.
WADO-RS / WADO-URI — web-based retrieval of DICOM data.
DICOMweb — modern REST-based DICOM services.

DICOM has its own transport (DIMSE over TCP), its own coordinate system, and its own metadata vocabulary — almost none of which overlaps with HL7 or FHIR. A typical radiology integration uses HL7 ORM for orders, HL7 ORU for reports, and DICOM for the actual images.

14. NCPDP: The Pharmacy Standard

NCPDP (National Council for Prescription Drug Programs) publishes the standards used in US pharmacy transactions.

Key NCPDP standards:

Telecommunication Standard — real-time pharmacy claim adjudication with payers.
SCRIPT Standard — electronic prescribing between prescribers and pharmacies.
Formulary and Benefit Standard — formulary information exchange.

E-prescribing in the US is NCPDP SCRIPT end-to-end. If your product touches prescribing workflows, you will encounter it. For e-prescribing to controlled substances (EPCS), additional DEA requirements apply on top.

15. State-Level Rules You Cannot Ignore

Federal law is only one layer. US states have their own rules, and some are stricter.

California — CCPA and CPRA privacy obligations, plus specific rules for mental health, substance use, and reproductive health data (AB 352).
Texas — Texas Medical Records Privacy Act (HB 300) is broader than HIPAA in several places, including training and breach notification.
New York — SHIELD Act extends data protection duties; New York State Public Health Law governs certain data flows.
Washington — My Health My Data Act (2024) significantly expands consumer rights and consent requirements for consumer health data.
State HIEs — many states (NY, CA, IN, MD, MI, and others) operate designated HIEs with their own participation agreements and technical requirements.

Do not assume federal compliance covers state requirements. Identify every state in which you operate or in which your users reside, and map state-level requirements alongside federal ones.

16. Compliance Architecture Patterns That Work

Across hundreds of implementations, a handful of architectural patterns consistently produce defensible compliance postures.

16.1 Segmented PHI environment

Keep the PHI-bearing environment (integration engine, FHIR server, databases, logging) in its own cloud account or subscription, with dedicated IAM, dedicated networking, and a dedicated BAA with the cloud provider. Non-PHI systems (marketing, internal tools) live elsewhere. The boundary is explicit and auditable.

16.2 Minimum necessary by default

The HIPAA Privacy Rule's "minimum necessary" principle is both a legal requirement and an architectural discipline. At the integration layer, strip fields you don't need downstream; in Mirth Connect this happens in transformers. In FHIR, it happens in the scopes you request (see our FHIR R4 Integration Complete Guide section on SMART).

16.3 Centralized audit logging

Every PHI access event — read, write, delete, export — gets logged to a central, tamper-evident log store (Splunk, Elastic, Sumo Logic, a cloud-native equivalent). Retention is six years minimum.

16.4 Keyed, per-tenant encryption

For multi-tenant platforms, encrypt each customer's data with a tenant-specific KMS key. Compromises are then bounded; tenant-specific revocation is possible without affecting others.

16.5 Continuous compliance tooling

Drata, Vanta, Secureframe, Tugboat Logic, and similar tools continuously monitor controls and produce evidence automatically. They are now standard in most new healthtech compliance programs — both SOC 2 and HITRUST assessors accept evidence produced by them.

16.6 Incident playbooks that have been rehearsed

A breach notification plan that has never been tabletop-tested will fail under pressure. Rehearse at least annually.

17. Common Pitfalls

Ten failure modes we see repeatedly in compliance reviews.

No BAA with a cloud provider before launching on PHI.
Plaintext PHI in application logs — leaks through log aggregators, developer laptops, incident investigations.
Shared admin accounts — no individual accountability, immediate audit finding.
Long-lived access tokens without rotation.
Missing audit logs on read operations (writes get logged; reads are routinely missed).
Unencrypted backups stored outside the protected environment.
Untracked data flows — data leaks to analytics tools, marketing tools, or debug services that no one notices.
Third-party SDKs that include PHI in telemetry by default.
Missing information-blocking policies on the product side.
No formal data retention and disposal schedule.

Each of these is a finding we've seen at multiple clients. Each is avoidable with deliberate architecture.

18. When to Bring in Compliance and Interoperability Experts

You should bring in specialists when any of the following applies:

You are pursuing HITRUST certification for the first time — a first-time HITRUST effort without experienced guidance frequently runs 2–3x over budget.
You are preparing for ONC certification — the Health IT certification process has specific, technical test harnesses that benefit from experienced hands.
You are designing a new platform that will handle PHI and need a compliance-native architecture, not a retrofit.
A major customer or partner has requested an audit, attestation, or SIG questionnaire response your team is not equipped to handle.
You are joining TEFCA or Carequality and need the legal, technical, and operational readiness work done in parallel.
A production interface is failing in a way that touches audit logs, consent, or BAA boundaries.

Our services team combines engineering, compliance, and interoperability expertise — which for PHI-bearing platforms is rare. We handle HL7 integration programs, FHIR integration services and FHIR development solutions, Epic and Cerner integrations, Mirth FHIR server hosting, and 24/7 production support through our Mirth helpdesk. Every engagement begins with an NDA and, where applicable, a BAA.

19. Frequently Asked Questions

What is healthcare interoperability?

Healthcare interoperability is the ability of different health systems, devices, and applications to exchange, interpret, and cooperatively use patient data. It spans four levels — from basic network connectivity to fully coordinated clinical workflow — and is governed by a combination of standards (HL7, FHIR, DICOM, X12, NCPDP, IHE) and regulations (HIPAA, ONC Cures Act, CMS rules).

Is HIPAA compliance enough?

HIPAA is the legal floor for handling PHI in the United States. It is necessary, but most enterprise healthcare customers now expect additional attestations — HITRUST CSF, SOC 2 Type II, and often state-specific controls. For products that do cross-organizational exchange, ONC Cures Act compliance and information-blocking policies are additionally required.

What is the difference between Carequality and TEFCA?

Carequality is a private, industry-run trust framework for cross-organizational exchange that has operated since the mid-2010s. TEFCA is a federally established national framework that went operational in late 2023 and is expected to be the long-term replacement for Carequality and similar networks. The two currently coexist, and many EHRs participate in both.

Do I need to join TEFCA?

If you need nationwide cross-organizational data access — patient record lookup across care settings, population-level data retrieval, public health reporting — TEFCA is becoming the default path. Smaller products with a single-tenant or single-region scope may not need TEFCA yet but should keep it on their roadmap.

What are the main regulatory frameworks for healthcare data in the US?

HIPAA (baseline), the ONC 21st Century Cures Act (information blocking, certified EHR APIs), CMS Interoperability and Prior Authorization Rules (payer obligations), state privacy laws (CCPA, Texas HB 300, Washington MHMDA, New York SHIELD, among others), HITRUST CSF (voluntary certification), SOC 2 (voluntary audit), and PCI-DSS (for payment-card flows).

What is information blocking?

Information blocking is any practice by a health IT developer, health information network, or healthcare provider that is likely to interfere with access, exchange, or use of electronic health information — except as required by law or covered by one of eight regulatory exceptions. Civil monetary penalties for IT developers can reach $1 million per violation.

Is FHIR enough for interoperability?

FHIR covers clinical and administrative data exchange very well and is the default for new APIs. It does not replace X12 (for payer transactions), DICOM (for medical imaging), or NCPDP (for pharmacy). Comprehensive interoperability typically requires all four, orchestrated through an integration engine like Mirth Connect.

What's the difference between HITRUST and SOC 2?

HITRUST is healthcare-specific and harmonizes HIPAA with other regulations and frameworks into a single certifiable control set. SOC 2 is general-purpose, based on the AICPA trust service criteria, and is widely used across industries. Most mature healthcare platforms end up with both — SOC 2 Type II for general cloud-service assurance and HITRUST CSF for healthcare-specific assurance.

How do I start a compliance program?

Scope your environment first (what systems handle PHI?), execute BAAs with every cloud provider and subprocessor, establish minimum HIPAA Security Rule controls, then layer HITRUST or SOC 2 based on which customers you serve. Continuous-compliance tooling (Drata, Vanta, Secureframe) pays for itself quickly. Most new programs take 6–12 months to reach a first attestation.

Healthcare Interoperability & Compliance: The Complete Guide (2026)

Table of Contents