Interoperability in Healthcare

What is interoperability in healthcare?

Interoperability in healthcare is the ability of providers, payers, labs, public health agencies and patient apps to exchange electronic health information and use it without losing meaning. In the United States it is shaped by USCDI, the ONC (ASTP) certification API, information blocking rules in 45 CFR Part 171, TEFCA and the CMS-0057-F payer API rule.

Each of those instruments answers a different question. USCDI says which data elements must be exchangeable. The certification program says how certified health IT exposes them. Part 171 says who may not get in the way. TEFCA says how networks trust each other. CMS-0057-F says what health plans must publish to patients, providers and other plans.

Moving bytes is the easy part. Organizations tend to fall short on the rules: they ship an API that holds the wrong data set, block a request they were obliged to honor, or join a network without the privacy controls its terms expect.

Which federal rules set the baseline for exchange?

Five federal instruments define most of the baseline. Each binds a different group, so start by reading each one against your own role.

• USCDI: ASTP/ONC maintains the United States Core Data for Interoperability, a standardized set of data classes and elements for nationwide exchange, and publishes new versions through an annual public process.
• Certified API: 45 CFR 170.315(g)(10) requires certified health IT to offer a standardized API for patient and population services, built on HL7 FHIR R4, US Core, SMART App Launch and Bulk Data. It is a read API; writing data back needs the EHR vendor's own write APIs or an HL7 v2 interface.
• Information blocking: 45 CFR Part 171 applies to health care providers, developers of certified health IT, and health information networks or exchanges. It prohibits practices likely to interfere with access, exchange or use of electronic health information, unless an exception applies.
• Payer APIs: CMS-0057-F requires impacted payers to meet prior authorization decision timeframes of 72 hours for expedited and 7 calendar days for standard requests from 1 January 2026, and to stand up Prior Authorization, Provider Access and Payer-to-Payer APIs from 1 January 2027.
• TEFCA scale: HHS announced in June 2026 that more than one billion health records had been exchanged through the Trusted Exchange Framework and Common Agreement.

The Patient Access API that payers already run comes from an earlier rule, CMS-9115-F (2020). CMS-0057-F adds to it rather than creating it, so a payer roadmap should treat the 2027 work as an extension of an existing endpoint.

Who counts as an actor under information blocking?

Only three kinds of organization are actors under Part 171: health care providers, developers of certified health IT, and health information networks or exchanges. A startup that sells a scheduling app and holds no certified product is usually not an actor, although its provider customers are.

The rule is written as a prohibition, not a feature list. Blocking or delaying access, exchange or use of electronic health information can be information blocking unless an exception applies. The regulation sets out exceptions such as privacy, security, infeasibility and manner, each with its own conditions.

For engineering teams, the practical effect is documentation. When a system refuses or narrows a request, the reason has to be traceable to a written policy that matches an exception. Teams that record the decision, the requester, the data requested and the policy applied are in a far better position than teams that rely on memory.

• Privacy: a request held back because the patient asked for a restriction, or because consent is missing, should log the consent record it relied on.
• Security: a refusal tied to a security concern should point to a written, consistently applied security policy, not an ad hoc call.
• Infeasibility: if a format or interface truly cannot be supported, the written response and its timing matter as much as the technical reason.
• Manner: offering the data another way, such as a standard API instead of a custom extract, is often the path that keeps a team inside the rule.

How does TEFCA change national exchange?

TEFCA replaces many bilateral data-sharing agreements with one Common Agreement and a set of designated networks. Qualified Health Information Networks (QHINs) are the central connection points, and participants reach the rest of the country through the QHIN they sign with.

The Sequoia Project serves as the Recognized Coordinating Entity, which develops and maintains the Common Agreement under an ONC contract. Terms flow down from the Common Agreement to QHINs, then to their participants and subparticipants, so a clinic connecting through a vendor still inherits obligations it should read.

ASTP/ONC lists six initial exchange purposes: treatment, payment, health care operations, public health, government benefits determination and individual access services. Each purpose changes who may ask and what a responder must return, so the purpose code on a query is a policy decision, not a technical default.

Individual access services deserve extra care. An app that queries on a patient's behalf through TEFCA takes on privacy and security duties under the Common Agreement, including for apps that are not covered by HIPAA. Product teams planning that route should budget for identity proofing and consent design before any query code is written.

What CMS-0057-F asks of payers and their partners

CMS-0057-F moves prior authorization and payer data sharing onto standard FHIR APIs. Impacted payers include Medicare Advantage organizations, Medicaid and CHIP programs and their managed care plans, and Qualified Health Plan issuers on the federally facilitated exchanges.

• Decision timeframes: 72 hours for expedited and 7 calendar days for standard prior authorization requests, starting 1 January 2026, with public reporting of prior authorization metrics. Exchange QHP issuers are not subject to the timeframes.
• Prior Authorization API: lets a provider system find out whether authorization is needed, what documentation is required, and submit the request.
• Provider Access API: gives in-network providers access to claims and clinical data for attributed patients.
• Payer-to-Payer API: moves a member's data to a new plan when the member changes coverage and opts in.
• Implementation guides: CMS recommends the HL7 Da Vinci CRD, DTR and PAS guides for prior authorization, but they are recommended, not required.

The rule does not govern X12 270/271 eligibility checks; those stay under the HIPAA transaction standards. Provider-side vendors should expect payers to ask them to support the FHIR prior authorization flow, but the duty in the rule sits with the payer.

Where does the cloud fit in an interoperability program?

The cloud is where most organizations now host the endpoints these rules require. Each layer of a hosted exchange hub maps to a specific obligation, which is a useful way to check that nothing has been missed.

• Network connections: TEFCA queries through a QHIN, HIE feeds and Direct messaging terminate here, so the Common Agreement terms and partner agreements apply to this layer.
• Identity and terminology: patient matching and code mapping decide whether a USCDI element is actually usable when it arrives, which is the point of the content baseline.
• FHIR APIs: certified (g)(10) endpoints and CMS-0057-F payer APIs are published from this layer, with SMART App Launch authorization in front of them.
• Business associate terms: a cloud host that stores ePHI is a business associate even when it cannot view the data, according to HHS guidance on HIPAA and cloud computing, so the agreement with the host belongs in the program plan.

The future of interoperability in healthcare points the same way. TEFCA has a published roadmap toward FHIR-based exchange, payer APIs arrive in 2027, and ONC keeps adding USCDI versions. A hosting design that can add new endpoints without rework is worth more than one tuned for today's feeds.

Who must do what: obligations by role

Use this checklist to sort which rules bind your organization before scoping any build. Many organizations hold more than one role.

• 1. Health care provider: you are an actor under Part 171; patients may direct your data to an app of their choice; your certified EHR supplies the (g)(10) API, and you decide how its access is granted.
• 2. Certified health IT developer: you are an actor; you must support the (g)(10) API to the adopted US Core and SMART App Launch versions; your API terms and fees fall under information blocking review.
• 3. Impacted payer: CMS-0057-F timeframes apply from 2026 and the new APIs from 2027; the Patient Access API from CMS-9115-F stays in place; Da Vinci guides are your choice.
• 4. Health information network or exchange: you are an actor; if you are a QHIN or a QHIN participant, Common Agreement terms govern purposes, responses and security.
• 5. Digital health app without certified technology: usually not an actor; if you serve providers as a business associate, HIPAA applies through the contract; if patients choose you directly, the FTC Health Breach Notification Rule may apply instead.
• 6. Every role: write down which exchange purposes you send and answer, how you match patients, and how a refusal is documented.

How Agnotic can help

Mapping the rules is the first deliverable on an interoperability program, and the hosting design follows from it. Agnotic Technologies builds and operates the cloud side for clients: FHIR API hosting for certified and payer endpoints, HL7 v2 and C-CDA intake, QHIN and HIE connections, and the logging that lets a team show why a request was answered or refused.

Agnotic works as the client's engineering team, so the client keeps ownership of policy decisions such as exchange purposes and exceptions, while Agnotic builds the controls that enforce them.

Sources

• ASTP/ONC: United States Core Data for Interoperability (USCDI)
• ASTP/ONC: Standardized API for patient and population services, 45 CFR 170.315(g)(10)
• 45 CFR Part 171: Information blocking regulations
• CMS: Interoperability and Prior Authorization Final Rule (CMS-0057-F)
• ASTP/ONC: Trusted Exchange Framework and Common Agreement (TEFCA)
• HHS: TEFCA network passes one billion health records exchanged
• HHS OCR: The access right, health apps and APIs
• HHS OCR: Guidance on HIPAA and cloud computing