FHIR is here… But not quite here yet: What TEFCA data really looks like today

If you spend any time in healthtech circles, you’ve probably heard some variation of: “TEFCA is live! QHINs are exchanging data via FHIR! Interoperability is solved!”

The truth is more nuanced, and far more important for anyone building patient or provider applications on top of TEFCA’s nationwide exchange. Yes, FHIR is coming. Yes, FHIR pipes are being turned on. But no, not all “FHIR data” flowing under TEFCA today is actually FHIR-native.

And if you don’t know the difference, you’ll quickly find yourself wondering why the data you’re getting through a beautifully spec-compliant FHIR API still feels like it stepped out of 2014.

Let’s break down what’s actually happening inside TEFCA’s QHIN network - minus the hype - plus the context you need.

TEFCA Launched on Legacy Rails

When TEFCA went live, it didn’t magically replace the national health information infrastructure overnight. It leaned on what already existed: IHE profiles and, overwhelmingly, C-CDA document exchange (C-CDA 2.1 if you’re keeping score).

Think of it like upgrading a city’s public transit map without rebuilding the tracks. TEFCA is modernizing the network, but trains still run on legacy rails in many places.

Here’s the key point:

Most data exchanged today across QHINs still originates as C-CDA or HL7 V2/V3, even when it’s delivered to you as “FHIR.”

That’s because many QHINs and EHRs still store and transmit clinical data in legacy formats. So when a FHIR request comes in, the system does an “on-demand transformation”, essentially converting older document formats into FHIR resources right before sending them out.

Is it real FHIR? Technically yes.

Is it native FHIR? Usually not.

FHIR Wrappers vs FHIR-Native Data

Everyone loves FHIR because it promises granular, modular, API-driven data: individual observations, nicely coded medications, discrete notes, structured histories, clear relationships between encounters, care teams, devices, labs, procedures, you name it.

But when the underlying source is a legacy document (C-CDA), you end up with something more like:

• the appearance of FHIR

• wrapped around the limitations of a document-era architecture

Here’s what that means in practice:

1. Loss of granularity

FHIR lets you capture tiny details such as panel-level labs, metadata on observations, provenance, device calibration, and narrative relationships.

Legacy data often can’t represent all that, so the FHIR version gets “flattened.”

2. Semantic loss

Some C-CDA fields simply don’t map cleanly to FHIR. You may see:

• omitted metadata

• collapsed structures

• generic values instead of coded terminology

• ambiguous links between data elements

You can feel it when you work with the data. It’s FHIR-shaped, not FHIR-structured.

3. Document baggage

Even in FHIR, legacy-derived content often acts like a document:

• bundled

• narrative-block-heavy

• inconsistent across EHRs

• hard to parse without heavy post-processing

4. Attachments and reports get messy

Visit notes, imaging results, and procedure documents often arrive as base64 blobs with incomplete metadata or unclear clinical context, again, an artifact of C-CDA inheritance rather than a FHIR limitation.

So What Data Are You Actually Getting Under TEFCA?

Here’s the simplest way to think about it:

FHIR-native responses are growing, primarily from more modern EHR stacks or networks that have embraced FHIR internally. But for now, they are still the minority

Why This Matters

Whether you’re powering patient apps, HIE integrations, care coordination platforms, or analytics, the origin of the data affects what you can do with it.

For Patient-Facing Apps

Expect inconsistencies.

Two patients may authenticate through TEFCA, both “via FHIR,” yet the content behind the scenes may differ wildly in structure and richness depending on their provider’s system.

For Provider-Facing Tools

Clinical decision support and longitudinal data features may require extra normalization layers to compensate for missing metadata or flattened structures.

For Automation, AI, and Advanced Analytics

Legacy-derived FHIR can be a bottleneck:

• harder to break into discrete events

• sloppy relationships between resources

• gaps in structured coding

For Interoperability Strategy

Relying solely on “FHIR-compatible” language can set false expectations.

The pipeline is standardizing, the payload is not fully standardized yet.

The Path Forward: TEFCA’s FHIR Future

The ONC and the RCE have clearly signaled that FHIR support - both query and response - is mandatory moving forward. Over time, native FHIR will become the common language across QHINs.

But we’re not there yet.

Today, TEFCA operates in a hybrid world:

• FHIR is growing, but not universal

• Legacy still powers most back-end exchanges

• Data is mapped on-the-fly into FHIR envelopes

• Uneven richness and consistency depending on source systems

FHIR is the future. Legacy is the present. TEFCA sits in the overlap.

The trick is acknowledging that reality so you can build for it, not pretend it’s already solved.

Final Takeaway:

If you remember one thing from this article, let it be this:

“FHIR” doesn’t guarantee that the underlying data is natively FHIR.

Under TEFCA today, most QHIN-delivered FHIR responses are still wrapped versions of C-CDA or HL7 content.

They’re useful. They’re interoperable. They move the industry forward.

But they’re not yet the fully granular, high-fidelity FHIR data model that modern health apps dream of.

We’re getting there, just not as fast as the marketing makes it seem.