Healthcare Interoperability: Standards, Rules, and What Compliance Actually Requires

Interoperability in US healthcare stopped being a technical aspiration some years ago. It is now a regulated obligation with defined actors, named exceptions, and financial consequences attached. Most of the current difficulty sits in knowing which rule applies to you, and what counts as a defensible reason to decline a request.

Healthcare interoperability helps systems, devices, and applications exchange, interpret, and act on health data across organizational boundaries.

Key takeaways

• Healthcare interoperability refers to the ability of different systems, devices, and applications to exchange, interpret, and act on health data across organizational boundaries.
• It spans four levels, and most programmes succeed at the first two while stalling at the third.
• Information blocking is prohibited for defined actors, with a set of regulatory exceptions that permit declining a request in specified circumstances.
• TEFCA is voluntary, and participating changes what counts as information blocking through a specific exception.
• Obligations differ materially between providers, health IT developers, networks, and payers.
• Enforcement is real, with disincentives reaching Medicare reimbursement and quality programme scoring.
• The hardest problems in practice are semantic and organizational rather than technical.

What is healthcare interoperability?

It is the ability of different systems, devices, and applications to exchange, interpret, and act on health data across organizational boundaries.

Healthcare interoperability refers to the capacity for health information to move between organizations and systems in a form the receiving party can actually use. Not simply transmitted, but understood and actionable.

In the US it is governed by a layered stack: regulation including HIPAA, the 21st Century Cures Act, and CMS payer rules, national frameworks and networks including TEFCA, Carequality, and CommonWell, and technical standards including HL7, FHIR, X12, DICOM, NCPDP, and IHE profiles.

That layering is why interoperability questions rarely have a single answer. Whether you must share something depends on who you are, what is being requested, how it is being requested, and which exception might apply.

What are the four levels of interoperability?

Foundational, structural, semantic, and organizational, as defined by HIMSS.

The distribution of difficulty surprises people. Moving a message is largely solved. Making the receiving system understand that a sodium result from one lab means the same thing as a sodium result from another, with the same units and reference ranges, is not.

Organizational interoperability is the level least discussed and increasingly the binding constraint. Two organizations can both support FHIR and still be unable to exchange because they lack an agreement permitting it.

Which standards govern health data exchange?

HL7 for messaging, FHIR for APIs, USCDI for content, plus domain-specific standards for claims, imaging, and pharmacy.

USCDI deserves attention because it defines the content expectation rather than the transport mechanism. Supporting FHIR while exposing a subset of USCDI satisfies the technical standard and not the substantive one.

Version matters throughout. Two organizations supporting different USCDI versions or different FHIR releases will find gaps that neither considers their problem.

What regulations apply, and to whom?

Obligations differ by entity type, and assuming the provider rules apply to everyone is a common error.

HIPAA governs privacy and security of protected health information and permits disclosure for treatment, payment, and operations. It is frequently cited as a reason not to share data, and in most of those cases incorrectly.

The 21st Century Cures Act added the obligation to share. That shift is the one organizations have found hardest culturally: HIPAA set conditions on disclosure, and the Cures Act prohibits unreasonable interference with it.

What is information blocking?

A practice by a defined actor that is likely to interfere with the access, exchange, or use of electronic health information, except as required by law or permitted by an exception.

The definition is deliberately broad. It covers practices rather than only refusals, which means delay, friction, fees, and technical restriction can all qualify depending on circumstance.

Intent matters and differs by actor type. For health IT developers and networks, the standard considers whether the actor knew or should have known the practice was likely to interfere. For providers, the standard considers whether the provider knew the practice was unreasonable and likely to interfere.

Who counts as an actor

Three categories are covered: healthcare providers, health IT developers of certified health IT, and health information networks and health information exchanges.

Organizations outside these categories are not directly subject to the prohibition, though they are frequently affected by it through their partners and vendors.

What are the exceptions to information blocking?

A defined set of circumstances in which declining or limiting a request is permitted, grouped by whether they involve not fulfilling a request or the manner of fulfilling it.

Two things matter more than memorizing the list.

First, exceptions are affirmative defences rather than general permissions. Relying on one means being able to demonstrate the specific conditions were met, which requires documentation created at the time rather than reconstructed afterwards.

Second, the content and manner exception is the one most used in practice. It allows fulfilling a request differently from how it was made, which is how most organizations handle requests for formats they do not support.

What is TEFCA, and is it mandatory?

TEFCA is a voluntary nationwide framework for health information exchange, built on networks called QHINs.

The Trusted Exchange Framework and Common Agreement establishes a nationwide structure for sharing health information. It has two components: the Trusted Exchange Framework setting out principles, and the Common Agreement establishing the terms participants sign up to.

Qualified Health Information Networks form the backbone. QHINs connect to each other using TEFCA’s technical standards, and participants connect through a QHIN rather than negotiating individually with every counterparty.

What participation offers:

• A single on-ramp: One agreement rather than many bilateral arrangements.
• Nationwide reach: Access to participants connected through any QHIN.
• Defined exchange purposes: Treatment, payment, operations, public health, individual access, and government benefits determination.
• Standardized terms: Consistent legal and technical conditions rather than negotiated variation.

Participation is voluntary. The practical calculation is whether your current exchange arrangements already reach the organizations you need, and whether the administrative simplification justifies the commitment.

What is the TEFCA Manner Exception?

It allows an actor to limit how it fulfils requests to TEFCA alone, without that limitation counting as information blocking.

This is recent, specific, and mostly covered by law firms rather than by vendors or trade publications.

Normally, restricting the manner in which you share electronic health information risks being treated as information blocking. The TEFCA Manner Exception provides that limiting exchange to TEFCA is not information blocking when specified conditions are met.

The conditions as finalized require that both the actor and the requestor are TEFCA participants, that the requestor is capable of the requested access, exchange, or use via TEFCA, and that fees and licensing terms meet the applicable conditions.

One limitation matters considerably in practice. The exception is available only where the request is not made using the API standards adopted in regulation, which includes FHIR API standards. A FHIR-based request cannot be redirected to TEFCA on these grounds.

The strategic effect is to make TEFCA participation more attractive. An organization inside TEFCA can rationalize its exchange pathways in a way that one outside it cannot.

TEFCA, Carequality, or CommonWell: which network?

They are not alternatives in the way the question implies, and most large organizations touch more than one.

The networks have been converging rather than competing, with connections established between them and participants frequently reachable through more than one route.

The practical question is rarely which to choose. It is which routes your EHR vendor already supports, which your key exchange partners use, and whether TEFCA participation adds reach you do not already have.

What are the consequences of non-compliance?

Disincentives that reach reimbursement and quality programme scoring, applied differently by actor type.

• Healthcare providers face disincentives established by CMS, applied through the programmes they participate in. For clinicians, that has meant consequences within the Promoting Interoperability performance category. For hospitals, consequences attach to meaningful EHR user status.
• Health IT developers of certified health IT face consequences including certification bans and civil monetary penalties.
• Health information networks and exchanges face civil monetary penalties.

Enforcement has intensified since the disincentive structures were finalized, and the practical risk is no longer theoretical.

Because specific penalty mechanisms and amounts have been revised more than once, confirm the current position against CMS and ASTP/ONC sources rather than relying on secondary summaries, including this one.

What does the CMS Interoperability Framework change?

It adds a voluntary commitment layer alongside the regulatory requirements, with aligned networks as the delivery mechanism.

CMS has established a framework inviting private sector organizations to commit voluntarily to interoperability goals, with networks meeting its criteria recognized as CMS Aligned Networks.

The stated goals include patients being able to access their electronic health information through applications of their choice wherever it resides on the network, and providers having access to that information except where law restricts it.

Aligned networks are expected to provide or facilitate access using FHIR APIs conforming to adopted standards. The framework aligns conceptually with TEFCA, and there is overlap in participation, with some aligned networks also operating as QHINs.

This is a recent and evolving area. Treat current participation figures and criteria as subject to change, and verify before relying on them in planning.

Where do interoperability programmes actually stall?

At the semantic and organizational levels, after the technical work is complete.

• Semantic divergence: Records arrive structurally valid and clinically ambiguous because local codes, units, or value sets differ.
• Patient matching: Records cannot be attached to the right person without a shared identifier, which does not exist nationally.
• Data quality in received records: Incoming data is often less complete or less current than the receiving organization assumes.
• Workflow integration: External records that arrive but are not surfaced where clinicians work produce no clinical benefit.
• Organizational agreements: Consent, data use terms, and participation agreements take longer than the technical connection.
• Vendor roadmaps: Capability you need may exist in a later release you are not on.

The pattern worth recognizing is that none of these are solved by better standards adoption. They are solved by terminology management, identity strategy, workflow design, and legal agreement, which sit outside most interoperability programme plans.

What does achieving interoperability require in practice?

Certified technology, network participation, enabled APIs, and the identity and terminology work underneath all of it.

1. Determine your obligations by entity type: Provider, developer, network, and payer requirements differ, and some organizations are more than one.
2. Deploy and maintain certified health IT where your programme participation requires it.
3. Enable required APIs to the adopted standards and content specifications, not only to the transport standard.
4. Decide your network participation: TEFCA, existing frameworks, or both, based on who you need to reach.
5. Establish patient identity strategy: Matching approach and expected match rate, since exchange without identity produces unusable records.
6. Govern terminology centrally: Mapping maintained in one place rather than per interface.
7. Document exception reliance: When you decline or limit a request, record the conditions at the time.

Step seven is routinely skipped and is the one that matters if a complaint is ever investigated. An exception you cannot evidence is not an exception you can rely on.

How do obligations differ for payers?

CMS-regulated plans carry API requirements that providers do not.

• Patient Access API: Making claims, encounter, and clinical data available to members through third-party applications of their choosing.
• Provider Directory API: Publishing provider network information in a standardized, publicly accessible form.
• Payer-to-payer exchange: Transferring member data when individuals move between plans.
• Prior authorization requirements: API-based processes and associated timelines and transparency obligations.

Applicability depends on plan type and programme. Medicare Advantage, Medicaid managed care, CHIP managed care, and qualified health plans on federal exchanges have been within scope of various requirements, with timelines that have shifted.

Confirm current scope and effective dates against CMS directly. This area has seen more revision than any other in the interoperability stack.

How does LatentView support interoperability initiatives?

Through the data engineering and analytics work that sits underneath exchange, rather than regulatory advisory.

Compliance obligations are a legal and regulatory matter. What organizations typically need alongside that is the capability to actually use the data once it flows.

LatentView works across three areas:

• Data foundations: Data Engineering is one of four core service lines, supported by Databricks Gold Tier partnership and a Center of Excellence staffed by 400 data engineers.
• Terminology and identity: The mapping and matching work that determines whether exchanged records are usable once received.
• Healthcare analytics: Within the Healthcare and Life Sciences practice, including Patient 360 work with the International Myeloma Foundation spanning foundation operations and the patient journey, recognized with a Minsky Award.

Regulatory interpretation and compliance determinations should come from counsel, not from an analytics partner.

Where to start

Establish which obligations apply, assess the gap honestly, then sequence technical and organizational work together.

• Map your obligations By entity type, programme participation, and plan type where relevant. Many organizations are subject to more than one set.
• Assess current capability against required standards, content specifications, and API conditions rather than against general FHIR support.
• Decide network participation based on reach you need rather than on framework preference.
• Fix identity and terminology in parallel with technical enablement, since neither resolves itself afterwards.
• Build exception documentation into process so reliance is evidenced at the time, not reconstructed later.

Most health organizations can now exchange data and still cannot use what arrives. Records come in with local codes, uncertain identity, and no place in the workflow where a clinician would see them. Closing that gap takes terminology management, identity resolution, and analytics engineering, which is what LatentView’s data engineering services are built for.

FAQs

1. What is healthcare interoperability?

It is the ability of different health systems, devices, and applications to exchange, interpret, and act on data across organizational boundaries, governed by a combination of technical standards and federal regulation.

2. What are the four levels of interoperability?

Foundational, structural, semantic, and organizational, as defined by HIMSS. Foundational covers transmission, structural covers format, semantic covers shared meaning, and organizational covers governance, policy, and workflow.

3. Is TEFCA mandatory?

No. TEFCA participation is voluntary. Participating changes what counts as information blocking in certain circumstances through the TEFCA Manner Exception, which makes it strategically relevant rather than required.

4. What counts as information blocking?

Any practice by a healthcare provider, certified health IT developer, or health information network that is likely to interfere with access, exchange, or use of electronic health information, unless required by law or covered by a regulatory exception.

5. What is the difference between HL7 and FHIR?

HL7 v2 is a messaging standard underpinning most existing hospital interfaces. FHIR is a newer standard defining resources and a REST API, and it is the standard adopted in US interoperability regulation.