A health system recently tried to pull a patient's full record from a partner system through its FHIR server, and the connection itself worked fine — authentication succeeded, requests went through, data came back. What came back, though, was a fraction of the patient's actual history: some vitals, a handful of lab results, but nothing close to the complete picture that should have been there. The rest of the record existed somewhere in the system. It simply wasn't structured in a way that FHIR could reach it.

This happens more often than most vendors like to admit, and it points to a distinction that matters more than it sounds like it should: the difference between a system that supports FHIR and a system that was built on FHIR.

Two claims that sound the same and aren't

FHIR (Fast Healthcare Interoperability Resources) is the current standard for exchanging health data, and it's increasingly the standard that interoperability mandates point to directly. Ask almost any EHR or health IT vendor today whether their system "does FHIR," and the answer will be yes — and that answer is usually true, while still not being the whole story.

Most of the platforms healthcare runs on today were built years, sometimes decades, before FHIR existed. Their data lives in older formats — HL7 v2, CDA, CCD, custom relational schemas — and FHIR was layered on top afterward as a translation step. When a request comes in, the system maps whatever fields it can into FHIR resources and returns those, while the rest of the record stays exactly where it was: intact and accessible internally, but never converted into the format being requested.

That's FHIR-compliant, and for a lot of use cases, it's genuinely enough. It's not the same claim as FHIR-native, where every piece of data in the system is a FHIR resource from the moment it's created rather than translated into one on request. The difference rarely shows up when things are working normally day to day. It shows up during an integration, a migration, or an urgent data pull, exactly when someone has assumed that "supports FHIR" means "all the data is there" and discovers it actually means "some of it is."

Why the gap exists

This isn't a story about vendors cutting corners so much as it is about architecture. A system built on a relational database designed in the 1990s or 2000s wasn't structured around FHIR resources in the first place — it was structured around whatever made sense at the time, under entirely different assumptions about how data would eventually need to move. Adding FHIR support to a system like that means building a mapping layer on top: this database field corresponds to this FHIR element, this table to that resource type. Mapping layers are useful, but they're partial by nature. Fields that don't map cleanly get left out, simplified, or handled as free text, and over years those gaps accumulate in exactly the places no one thought to check.

None of this shows up in a sales conversation, a spec sheet, or even most certifications. It shows up in production, when a health system goes looking for a specific data point and finds out it never made the trip from the old format to the new one.

What FHIR-native actually looks like

HiiveCare is built on Medplum, which was designed as a FHIR-native platform from the ground up. That means the data model itself is FHIR — there's no separate internal format that gets translated on the way out, and a patient record isn't stored one way internally and exposed another way externally. It's a FHIR resource at rest, not just at the API boundary, which means every piece of clinical data in HiiveCare — encounters, medications, care team assignments, documents — is fully portable by default, not portable only for the fields that happened to get mapped correctly.

That's a meaningfully different guarantee than FHIR compliance, and like most architectural differences, it's invisible right up until the moment it isn't: a new integration, a system migration, an audit, a partner asking for a specific data element nobody thought to plan for in advance.

The interoperability mandates aren't going away

Federal interoperability rules have made FHIR the baseline expectation for health data exchange, and that expectation is only becoming more specific over time, not less. Systems that treat FHIR as something added on will keep running into new edge cases where the mapping falls short, one exception at a time. Systems built on FHIR from the start don't have that problem to discover, because there's no gap between what the architecture promises and what it actually stores.

For teams evaluating a care management platform, the useful question isn't whether it supports FHIR. Nearly everything will say yes to that. The more useful question is where the data actually lives, and whether "FHIR-native" is describing the foundation the system was built on, or a layer painted over something else.