Skip to main content
Back to Blog

Healthcare Interoperability in 2025: From “SMART Apps” to TEFCA-Scale Exchange

December 19, 2025·5 min read

Professionalhealthcareinteroperabilityfhirsmarttefcacase-study

In 2012, I wrote an undergrad technical report on a simple idea: standardize the interface to clinical data, and you enable an app ecosystem that moves at software speed, even while healthcare moves at medical speed.

That idea is still right. What’s changed is scale and expectations:

  • We’re no longer debating whether digital records should exist.
  • We are debating how data should move safely, predictably, and with minimal “special‑case integration” across organizations.

In 2025, interoperability is less a standards debate and more a production discipline.

This post updates that 2012 perspective with what I’ve learned shipping integrations professionally, and with where the industry is heading now, from SMART‑on‑FHIR apps (the default “app contract”) to TEFCA (the emerging “network contract”).

TL;DR

  • FHIR standardizes the data model, SMART standardizes the app “front door.”
  • TEFCA is standardizing the network layer: shared governance + operational expectations.
  • “Plug‑and‑play” still breaks on profiles, auth edge cases, identity/consent, and reliability work.

The architectural problem hasn’t changed

Healthcare interoperability is still a three‑layer problem:

  1. Data representation: how we describe clinical concepts (resources, vocabularies, profiles).
  2. Transport: how data gets from one place to another (APIs, events, bulk exports, documents).
  3. Trust + governance: who is allowed to exchange what, under which rules, with which auditing expectations.

If you solve only one layer, you get a partial victory that feels like a loss in production.

Layered stack diagram: data representation at the bottom, transport in the middle, and trust and governance at the top, with examples like FHIR, APIs, and TEFCA.
Figure 1. Interoperability fails in production when any one layer is implicit instead of contractual.
LayerIf it’s underspecified, you get…
Data representation“We’re both using FHIR” but fields, profiles, and terminology don’t line up
TransportOne‑off plumbing (batch here, polling there, fragile retries everywhere)
Trust + governanceBespoke agreements and inconsistent access, even when the APIs exist and the network is “connected”

Why “FHIR + SMART” became the default app model

FHIR made clinical data more accessible to web and mobile developers by focusing on modern HTTP semantics and a resource model.

SMART App Launch layered on an authorization and launch experience so an app can be:

  • embedded in an EHR workflow, or
  • launched standalone with a known patient (or user) context.

In practice, the best part of SMART is not the acronym, it’s the repeatable contract:

  • a consistent OAuth2/OIDC‑based authorization flow,
  • a standardized set of launch context parameters,
  • conventions around scopes, audiences, and “who am I acting as?”

When you’re building a platform, this predictability matters as much as the data model.

Where the friction still is (and why it’s not “just standards”)

Even with standards, implementations differ. The integration cost shows up in the places that aren’t visible in demos.

1) “Same standard, different profiles”

FHIR is intentionally extensible. That’s power, but it creates variability.

What works in production:

  • profile‑driven contracts (e.g., “we support these profiles, not all of FHIR”),
  • conformance testing and contract tests,
  • a pragmatic support matrix rather than wishful universality.

2) Authorization is where good integrations go to die

SMART depends on OAuth2/OIDC patterns that are straightforward on paper and messy in enterprise reality:

  • token lifetimes, refresh behavior, and clock skew
  • scope interpretation differences
  • user vs system context (and “what can this app do without a human?”)
  • proxy/gateway behavior in front of identity providers

This is why integration teams end up caring deeply about security details.

3) “Exchange” isn’t just request/response

For many use cases, exchange is not a single REST call:

  • bulk data exports for analytics (and long‑running jobs)
  • subscription/event flows
  • document exchange and reconciliation
  • patient‑mediated flows

Production interoperability is multi‑modal.

4) Identity and consent are the silent fourth rail

You can have “perfect” APIs and still fail:

  • mismatched patient identities across systems
  • inconsistent consent policies and local legal interpretation
  • missing provenance (“who said this, when, and under what context?”)

This isn’t glamorous work, but it’s where safety and trust actually live.

The governance layer: why TEFCA matters

If you want interoperability at national scale, you need a mechanism to reduce one‑off contracting and bespoke trust. That’s where TEFCA comes in: a framework and common agreement intended to enable exchange through participating networks under a shared set of rules.

A useful mental model:

  • SMART makes it easier for an app to connect to a system.
  • TEFCA aims to make it easier for a network to exchange with a network, reliably, under common governance.

TEFCA is interesting from an engineering perspective because it operationalizes the missing “layer 3” that standards alone don’t provide:

  • common policies, dispute processes, and operational requirements
  • shared expectations for auditing and compliance
  • a way to “flow down” obligations so trust is portable across participants

Exchange purposes make the “why” contractual

In TEFCA, “use cases” are formalized as Exchange Purposes, the reason information can be requested or shared. Today, TEFCA authorizes six:

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

This sounds bureaucratic until you ship software: defining the “why” is how you keep exchange auditable and defensible.

TEFCA is already operational, and scaling

As of November 17, 2025, the TEFCA RCE reported 10,600+ organizations live on TEFCA, representing 60,000+ unique connections, and 115M+ documents exchanged since December 2023.

That doesn’t mean interoperability is “solved”, but it does mean governance‑backed exchange is moving from theory to infrastructure.

TEFCA’s technical path: start with what exists, add what’s next

A subtle but important point: TEFCA didn’t try to jump straight to a pure‑FHIR world.

Early TEFCA exchange has intentionally built on existing, widely deployed infrastructure (IHE‑based exchange of C‑CDA content) to avoid disrupting current workflows, while TEFCA governance and technical specs evolve to support FHIR‑based exchange at scale.

That’s the right tradeoff for a national‑scale program: stability first, modernization continuously.

Regulation is making “API timelines” real

The CMS Interoperability and Prior Authorization Final Rule (CMS‑0057‑F) is a good example of the industry’s shift from nice-to-have standards to must‑operate systems: CMS notes that impacted payers must implement some provisions by January 1, 2026, and have until primarily January 1, 2027 to meet the rule’s API requirements.

In other words: the contracts are increasingly backed by deadlines.

A practical takeaway: build for reliability, not demos

If I’m designing an interoperability platform today, I prioritize:

  • observability by default (logs, traces, synthetic checks, “what changed?” timelines)
  • clear contracts (profiles, scopes, error semantics, versioning, deprecation policy)
  • auth as a first‑class subsystem (token lifecycle, replay protection, audit events)
  • partner enablement (documentation that is runnable, not aspirational)
  • safe failure modes (timeouts, retries, idempotency, backpressure)

These are the same habits that improved response times and SLA adherence in my support engineering leadership roles, because interoperability is a production discipline, not a standards debate.

Further reading

Related Articles

Comments

Join the discussion. Be respectful.