Healthcare Interoperability: From SMART Apps to TEFCA-Scale Exchange
6 min readUpdated
In 2012, I wrote an undergraduate report around a simple idea: standardize access to clinical data, and software can move faster around the EHR.
The idea held up. The architecture around it became more complete.
FHIR now gives implementers a resource and exchange model. SMART App Launch defines reusable authorization and discovery patterns. TEFCA adds nationwide network governance and technical obligations.
None of those layers makes an integration plug-and-play by itself. Production still fails at the seams: profiles, identity, authorization, local policy, and operations.
TL;DR
- FHIR defines healthcare data resources and exchange behavior. It does not guarantee that every server supports the same profiles or search surface.
- SMART App Launch standardizes OAuth 2.0-based app authorization, launch context, scopes, and capability discovery.
- TEFCA establishes a network-of-networks under shared legal, governance, and technical rules.
- TEFCA is operational infrastructure now, not a future proposal. Its adoption numbers have changed quickly.
- The remaining work is mostly contract and operations work: conformance, identity, consent, observability, and safe failure handling.
The mental model: three contracts
Healthcare interoperability is easiest to reason about as three contracts:
- Data: Which resources, profiles, terminology, and required fields do both sides understand?
- Connection: How do systems discover, authorize, query, push, and receive data?
- Trust: Who may exchange information, for which purpose, under which operating rules?
| Contract | Standards help with | They do not settle automatically |
|---|---|---|
| Data | Resources, profiles, terminology bindings | Local extensions, optionality, data quality |
| Connection | REST behavior, launch, scopes, discovery | Registration, environment quirks, uptime |
| Trust | Permitted exchange and participant obligations | Every local consent or access decision |
The layers overlap. They should not be collapsed into one slogan.
What FHIR and SMART actually standardize
FHIR covers much more than a JSON shape. It defines resources, REST interactions, search, operations, conformance artifacts, and other exchange patterns.
It also permits variation by design. A server can support a subset of resources, profiles, and search parameters. That flexibility is why CapabilityStatements and implementation guides matter.
SMART App Launch 2.2 builds an app contract on top of FHIR. Its current published guide defines:
- user-facing EHR and standalone launch;
- backend-service authorization;
- OAuth 2.0-based scopes and authorization;
- launch context, such as the selected patient; and
- discovery through
.well-known/smart-configuration.
One correction to the shorthand I often hear: SMART is OAuth 2.0-based, but OpenID Connect is a declared capability, not a universal synonym for SMART.
The repeatable flow is valuable. It lets an app discover endpoints and supported features before constructing an authorization request.
Yet important setup remains outside the standard flow. The SMART launch guide notes that client registration can occur out of band. Institutional policy still determines the user's underlying permissions.
That is where “works against the sandbox” can diverge from “works at this hospital.”
Where app integrations still break
Profiles differ
“Both sides use FHIR R4” is only a starting point. The useful contract names the profiles, extensions, terminology versions, and required elements.
I prefer a small support matrix over a claim of universal FHIR support.
Authorization has environment-specific edges
Common failure points include:
- a redirect URI registered in one environment but not another;
- scopes advertised differently from scopes granted;
- clock skew or token-lifetime assumptions;
- user-context and backend-service flows being treated as interchangeable; and
- an intermediary changing headers or audience values.
The answer is not custom authentication. It is conformance testing around discovery, registration, token handling, and authorization failures.
Exchange is not only request and response
Real systems mix several delivery modes:
- interactive reads and writes;
- long-running bulk exports;
- subscriptions or event delivery;
- document exchange; and
- reconciliation after delayed or duplicate delivery.
Every mode needs its own idempotency, retry, timeout, and audit contract.
Identity and policy remain local
An API can return valid FHIR resources and still leave hard questions open:
- Do these records refer to the same person?
- May this requester access this information for this purpose?
- What provenance travels with transformed or aggregated data?
- What happens when policy differs across organizations?
Standards provide vocabulary and mechanisms. They do not erase organizational responsibility.
What TEFCA adds
The Trusted Exchange Framework and Common Agreement (TEFCA) addresses the network contract.
A useful distinction is:
- SMART helps an application connect to a FHIR system.
- TEFCA helps participating networks exchange under common rules.
ONC describes TEFCA as a framework built around a Common Agreement, a Trusted Exchange Framework, and a QHIN Technical Framework. Qualified Health Information Networks (QHINs) connect participants and subparticipants through that network-of-networks.
The Common Agreement is a legal contract among QHINs. The technical framework covers topics such as patient identity resolution, authentication, and performance measurement.
Exchange purpose is part of the request
TEFCA requires an Exchange Purpose to explain why information is requested. ONC currently lists six initial purposes:
- Treatment
- Payment
- Health Care Operations
- Public Health
- Government Benefits Determination
- Individual Access Services
Those categories do not grant every requester every record. They establish a governed reason for exchange, while applicable law and participant obligations still apply.
The network is live and growing
The scale is no longer theoretical. As of August 30, 2026, the Recognized Coordinating Entity (RCE) homepage reported:
- more than 23,000 organizations live on TEFCA;
- more than 100,000 unique connections; and
- more than 1.5 billion documents shared since December 2023.
These are program-reported adoption counts, not an independent measure of completeness or clinical value. I treat them as evidence of network activity, not evidence that interoperability is solved.
TEFCA is not one payload format
TEFCA started from deployed document-exchange infrastructure and continues to add FHIR-based paths. The RCE's Common Agreement page says Version 2 work advanced FHIR-based exchange.
That incremental path is sensible. A national network has to preserve working exchange while modernizing its interfaces.
Policy has moved from encouragement to deadlines
The CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F, is a concrete example.
CMS says impacted payers had operational requirements beginning in 2026. API implementation requirements generally begin January 1, 2027, with exact dates depending on payer type.
Those APIs include changes to Patient Access plus Provider Access, Payer-to-Payer, and Prior Authorization capabilities.
The engineering implication is straightforward: conformance, partner onboarding, and production operations need lead time. A compliance date is not a sensible first load test.
How I design for this now
I use the three-contract model as a delivery checklist.
Data contract
- Publish the exact profiles and terminology versions.
- Validate realistic fixtures, including missing and repeated data.
- Version transformations and preserve provenance.
Connection contract
- Test discovery and authorization in each environment.
- Define errors, retries, timeouts, and idempotency.
- Exercise bulk, event, and document flows separately.
Trust contract
- Carry purpose and actor context into audit records.
- Keep identity decisions explicit and reviewable.
- Document which obligations belong to the platform and which remain local.
Observability connects all three. I want a traceable answer to four questions: what arrived, what changed, what was sent, and under which contract version?
A reference implementation: fi-fhir
My fi-fhir project is a public reference implementation, not evidence that every healthcare environment behaves the same way.
It turns the contract model into inspectable artifacts:
- Source Profiles describe how a feed should be parsed and normalized.
- Parsers cover HL7v2, CSV/flat files, EDI X12, CDA/CCDA, and FHIR input.
- A canonical event layer separates source format from workflow decisions.
- FHIR R4 mapping and validation make output assumptions testable.
- Browser tools expose profile validation, pipeline stages, and mapping behavior.
The project still has deliberate boundaries. Profile authoring, terminology governance, and production-specific policy remain integration work.
That is the point. Standards reduce unnecessary variation; they do not remove the need to model the variation that remains.
Takeaways
My 2012 thesis was incomplete, not wrong.
Standardized interfaces helped create an app model. Shared governance is creating a national network model. The next gains come from making each local contract observable and testable.
If I were starting an interoperability platform today, I would invest early in:
- profile-level conformance tests;
- authorization and registration diagnostics;
- identity and provenance workflows;
- replay-safe delivery; and
- contract-aware observability.
The demo is the easy part. The product is the system that keeps working when the data, partner, policy, and network do not line up perfectly.
Further reading
Related Articles
Comments
Join the discussion. Be respectful.