US healthcare interoperability changed more between 2024 and 2026 than in the decade before. TEFCA, the national framework for exchanging records between networks, went from five designated networks to eleven and from a few million documents to hundreds of millions. CMS's Interoperability and Prior Authorization Final Rule (CMS-0057-F) set hard dates for payer FHIR APIs. And a July 2025 White House initiative created "CMS Aligned Networks" and a pledge to "kill the clipboard".
If you build software that touches US providers or payers, from an Indian or Gulf development centre or from inside the US, these three threads decide what your product must support. SMART on FHIR is the thread that ties them together for app developers.
This guide explains each piece as of late 2026, what is live versus planned, and what product teams should build. For FHIR fundamentals, see our HL7 FHIR integration guide.
TEFCA: from launch to real volume
The Trusted Exchange Framework and Common Agreement (TEFCA) was called for in the 21st Century Cures Act of 2016. The Common Agreement was published in January 2022 and exchange went live on 12 December 2023 with the first designated Qualified Health Information Networks (QHINs).
According to the ASTP/ONC TEFCA history page:
- There are now 11 QHINs: CommonWell Health Alliance, eClinicalWorks, eHealth Exchange, Epic Nexus, Health Gorilla, Kno2, KONZA, MedAllies, Netsmart, Oracle Health Information Network and Surescripts. Oracle's designation came on 28 November 2025.
- About 10 million documents were exchanged before 2025, rising to 464 million by the end of 2025.
- Over 71,000 sites or organisations participate through the QHINs.
- There are six exchange purposes: Treatment, Payment, Health Care Operations, Public Health, Government Benefits Determination and Individual Access Services (IAS).
| TEFCA concept | What it means in practice |
|---|---|
| QHIN | A network designated to exchange with other QHINs under common rules |
| Participant / Subparticipant | Organisations that connect through a QHIN, such as health systems or vendors |
| Exchange purpose | The legal reason for a query, which controls who must respond |
| IAS | Patients requesting their own records through an app they choose |
Most TEFCA exchange today still uses document-based IHE profiles under the hood. FHIR-based exchange is on the roadmap, and individual access through apps has been the hardest exchange purpose to scale; industry coverage in 2026 describes ongoing work and provider concerns about it.
CMS-0057-F: the payer API deadlines
CMS finalised the Interoperability and Prior Authorization rule in January 2024. It applies to Medicare Advantage organisations, state Medicaid and CHIP programmes (fee-for-service and managed care) and qualified health plans on the federally facilitated exchanges. Traditional Medicare fee-for-service is not covered, and drugs are excluded from the prior authorisation API requirements.
The timeline has two stages:
| Date | Requirement |
|---|---|
| 1 January 2026 | Prior authorisation decisions within 72 hours for expedited and 7 calendar days for standard requests; specific denial reasons |
| 31 March 2026 | First public reporting of prior authorisation metrics (for calendar year 2025) |
| 1 January 2027 | Patient Access API enhancements, Provider Access API, Payer-to-Payer API and Prior Authorization API, all FHIR-based |
The 2027 APIs are where product work concentrates:
- Provider Access API: in-network providers can retrieve claims, encounter and clinical data for attributed patients.
- Payer-to-Payer API: when a patient changes plans, the new payer can retrieve data from the old one, with patient permission.
- Prior Authorization API: providers can learn whether authorisation is required, what documentation is needed, submit the request and receive the decision, through FHIR.
The prior authorisation API is built around the HL7 Da Vinci implementation guides (Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support). For EHR and practice management vendors, supporting these on the provider side is how your users benefit from what payers are being required to build.
The CMS Health Tech Ecosystem and Aligned Networks
On 30 July 2025, CMS and the White House launched the Health Tech Ecosystem initiative. Twenty-one networks pledged to meet the CMS Interoperability Framework criteria to become CMS Aligned Networks, seven EHR vendors pledged to help "kill the clipboard", and eleven health systems and providers committed to take part (CMS EHR early adopters).
Key ideas in the framework:
- Kill the clipboard: providers accept patient data electronically, for example through QR codes, SMART Health Cards or SMART Health Links carrying FHIR bundles, instead of making patients fill forms with their history.
- Self-attestation: networks attest that they meet the criteria and agree to review if they do not.
- Payer data: payers make claims data available to aligned networks, consistent with the Patient and Provider Access API standards.
- CMS participation: CMS planned to respond to patient and provider queries and share Blue Button claims data through aligned networks from early 2026.
This is voluntary, pledge-based policy rather than regulation, but it signals clearly where federal pressure is going: patient-mediated, FHIR-based exchange.
SMART on FHIR: how apps plug in
SMART on FHIR is the standard that lets an app launch inside an EHR (or standalone), authenticate with OAuth 2.0 and OpenID Connect, and read or write FHIR data with scoped permissions. It is what makes the APIs above usable by third-party apps.
What changed recently:
- The ONC HTI-1 final rule adopted SMART App Launch v2 for certified health IT, with v1 no longer accepted for certification from 1 January 2026. Version 2 brings granular scopes, PKCE and other security improvements.
- US Core 6.1.0 is the HTI-1 baseline for the data profiles certified APIs must support.
- Version 2.2 of SMART App Launch has been proposed for future certification requirements.
For app developers, the practical consequences:
- Support SMART v2 scopes (for example patient/Observation.rs) and fall back sensibly where an EHR still offers v1 behaviour.
- Use PKCE and handle token refresh properly; many production failures are auth issues, not data issues.
- Map to US Core profiles and test against real EHR sandboxes, because each vendor's implementation differs in the details.
- For population-level data, use Bulk FHIR (Flat FHIR) with backend services authorisation rather than per-patient calls.
What this means if you build healthcare software
| If you build... | Priority work for 2026-27 |
|---|---|
| Patient-facing apps | SMART v2 standalone launch, Patient Access APIs, SMART Health Links, IAS via a QHIN partner |
| Provider-side apps (clinical, RCM) | SMART EHR launch, US Core 6.1.0, Da Vinci prior auth support |
| Payer systems | CMS-0057-F APIs by 1 January 2027, metrics reporting, aligned network participation |
| EHR or practice management | Certification to HTI-1, clipboard-free intake, TEFCA connectivity through a QHIN |
| Analytics / population health | Bulk FHIR, Provider Access API consumption, data quality pipelines |
Building for the US from India
Many US health IT products are built by teams in India, including ours in Kochi. The standards work is the same wherever you sit, but a few practical points matter:
- HIPAA obligations travel with the data. If your team accesses PHI, a Business Associate Agreement and HIPAA-grade controls apply, regardless of location. Most offshore teams should work with synthetic or de-identified data and US-hosted environments.
- Use public sandboxes heavily. EHR vendor sandboxes, Inferno and synthetic data generators let you build and test most functionality without touching real PHI.
- Design for certification from the start. Retrofitting SMART v2, audit logging and US Core conformance late is far more expensive than building it in.
Our healthcare integration and healthcare software development teams build FHIR APIs and SMART apps this way, and the same patterns serve ABDM and UAE exchange work, since all three are converging on FHIR R4.
Common mistakes when building for US interoperability
- Building against the spec, not the implementations. The FHIR and SMART specifications leave room for interpretation. Real EHR implementations differ in supported scopes, search parameters and extensions. Plan time for each target EHR.
- Ignoring app registration and review. Getting your SMART app registered and approved in an EHR vendor's marketplace or with each health system can take longer than building it. Start those conversations early.
- Treating prior authorisation as a payer-only problem. The 2027 Prior Authorization API helps providers only if their EHR or practice management system can call it. Provider-side vendors have as much work to do as payers.
- Pulling everything, every time. Per-patient API calls for population analytics are slow and fragile. Use Bulk FHIR for population data and cache sensibly.
- No plan for data quality. Data arriving through TEFCA or payer APIs is only as good as its source. Deduplication, code mapping and provenance tracking are part of the job; our guide to healthcare data analytics covers the basics.
- Hard-coding today's versions. US Core, SMART and the Da Vinci guides are versioned and will move. Keep version-specific mapping in a separate layer so an upgrade is a change, not a rewrite.
Lessons for India and the Gulf
The US experience is worth watching from India and the UAE for two reasons. First, the direction is the same: national networks, FHIR APIs and patient-mediated sharing. ABDM's consent manager and NHCX, and the UAE's connected exchanges, follow a similar logic. Second, the US shows that deadlines and certification drive adoption far more than voluntary standards. The jump in TEFCA volume followed years of regulatory groundwork.
Conclusion
US interoperability in 2026 rests on three pillars: TEFCA for network-to-network exchange, now at hundreds of millions of documents across 11 QHINs; CMS-0057-F for payer FHIR APIs, with the main API deadline on 1 January 2027; and SMART on FHIR as the way apps connect, with v2 now the certification baseline. The voluntary CMS Aligned Networks layer adds pressure towards patient-mediated, clipboard-free exchange.
For builders, the to-do list is concrete: SMART v2, US Core 6.1.0, Da Vinci prior authorisation, Bulk FHIR and a QHIN partner. If you need a team to build or extend FHIR capabilities for the US market, contact us.
Frequently asked questions
What is TEFCA?
TEFCA, the Trusted Exchange Framework and Common Agreement, is the US national framework for exchanging health information between networks. Exchange went live on 12 December 2023, and there are now 11 designated QHINs.
How much data has been exchanged through TEFCA?
According to ASTP/ONC, about 10 million documents were exchanged before 2025 and 464 million by the end of 2025, with over 71,000 sites or organisations participating through the QHINs.
What are the CMS-0057-F deadlines?
Prior authorisation decision timeframes of 72 hours for expedited and 7 calendar days for standard requests applied from 1 January 2026. The Patient Access, Provider Access, Payer-to-Payer and Prior Authorization FHIR APIs are due by 1 January 2027.
Who must comply with CMS-0057-F?
Medicare Advantage organisations, state Medicaid and CHIP programmes, and qualified health plans on the federally facilitated exchanges. Traditional Medicare fee-for-service is not covered, and drugs are excluded from the prior authorisation API requirements.
What is SMART on FHIR?
SMART on FHIR is a standard that lets apps launch inside or alongside an EHR, authenticate with OAuth 2.0 and OpenID Connect, and access FHIR data with scoped permissions. The ONC HTI-1 rule made SMART App Launch v2 the certification baseline, with v1 no longer accepted from 1 January 2026.
What are CMS Aligned Networks?
They are networks that pledged, under the CMS Health Tech Ecosystem initiative launched on 30 July 2025, to meet the CMS Interoperability Framework criteria. Twenty-one networks made the initial pledge, alongside EHR vendors committing to clipboard-free patient data intake.
