FHIR gets treated as a checkbox in a lot of healthcare software conversations: does the system support it, yes or no. That framing misses where the actual work is.
We haven't shipped a named healthcare case study yet, and we're not going to claim one we don't have. What we can speak to honestly is what FHIR interoperability actually takes to build well, and it's a core part of what we cover with healthcare clients in early scoping.
Key takeaways
- 87% of certified US health IT developers support FHIR-based APIs (ONC), and support among large EHR vendors is now near-universal, FHIR is the default expectation, not a nice-to-have.
- USCDI v3 became the mandated baseline data set for certified health IT products in 2026 (ONC), which changes what 'interoperable' actually has to mean for a new build.
- Supporting FHIR is not the same as being interoperable. A system that exposes a FHIR API without mapping its own data model cleanly to FHIR resources technically complies and practically doesn't help anyone.
- The real work is the data model underneath the API, not the API standard itself, that is where most integration projects actually stall.
01How standard FHIR actually is now
According to ONC, the US Office of the National Coordinator for Health Information Technology, 87% of certified health IT developers now support FHIR-based APIs, with support among large EHR vendors close to universal. FHIR app adoption in outpatient settings climbed from 49% in 2021 to 64% in 2024.
That momentum has a regulatory floor under it now: USCDI v3 became the mandated baseline data set for certified health IT products starting in 2026, per ONC. A new system entering this space isn't choosing whether to support FHIR, that decision was effectively made for the industry already.
87%
Share of certified US health IT developers that support FHIR-based APIs (ONC)
Supporting FHIR is not the same as being interoperable.
02Where "we support FHIR" claims fall apart
Exposing a FHIR-shaped API endpoint is the easy part. The actual work is mapping your system's own data model, patient records, appointments, clinical notes, cleanly onto FHIR's resource structure so the data that comes out actually means what the receiving system expects it to mean.
A system that technically returns FHIR-formatted JSON but maps its internal fields loosely or inconsistently passes a superficial compliance check and fails the moment a real receiving system tries to use the data for anything clinical.
03What we build
A data model designed with FHIR resource mapping in mind from the start, not retrofitted after the schema is already set. Clear, documented mapping between internal fields and the FHIR resources they correspond to, so the "interoperable" claim is actually true, not just technically defensible.
Version-aware handling as USCDI and FHIR themselves evolve (FHIR R6 entered ballot in late 2025, per HL7's own release cycle), so the system does not need a rebuild every time the standard moves.
04What not to do
Don't treat FHIR support as a checkbox to satisfy in a sales conversation. If the underlying data model isn't mapped properly, the claim creates a worse problem than not claiming it: a receiving system that trusts data which doesn't mean what it says.
We haven't built integrations against every major EHR vendor's specific FHIR implementation, vendors vary in how strictly they follow the spec. If your project needs a named EHR integration, say so early, that shapes the actual scope.
05Getting started
Map your own data model against FHIR's core resource types before committing to a timeline. This is where the real scope of an interoperability project lives, not in the API layer itself.
Name the specific systems you need to exchange data with. "FHIR-compliant" in the abstract matters less than "correctly exchanges patient records with this specific EHR."
Plan for the standard to keep evolving. USCDI and FHIR both move on a real release cadence, build the mapping layer to be updated, not replaced, each time.
Frequently asked questions
No. Exposing a FHIR-shaped API is the easy part. Real interoperability depends on how cleanly your internal data model maps to FHIR's resource structure, which is where most of the actual engineering work happens.
Not every version, but you do need a plan for versioning. FHIR R5 is current with R6 in ballot, and USCDI itself updates on its own cycle (v3 mandated for 2026 certified products). Build the mapping layer to be updated, not rebuilt, each time.
Naming the specific systems you need to exchange data with and mapping your own data model against the relevant FHIR resources before writing integration code. That scoping work determines the real timeline, not the API standard itself.