HL7 FHIR

The healthcare interoperability standard defining how clinical data is structured and exchanged over modern web APIs.

Industry & Domain

FHIR defines clinical concepts as resources — Patient, Observation, Condition, MedicationRequest — exchanged as JSON or XML over REST. That made healthcare integration approachable to developers who had never seen HL7 v2's pipe-delimited messages, and it is why almost all new healthcare integration work targets it.

The standard being modern does not make integration simple. FHIR permits extensive profiling, so two compliant systems can represent the same clinical fact differently; vendors implement different subsets; and access is gated by scopes and consent frameworks such as SMART on FHIR. In practice, building against FHIR means building against a specific vendor's interpretation of it and discovering the gaps during integration rather than from the specification.

In practice

A product integrated with two EHR vendors using the same FHIR resources. One returned medication data as MedicationRequest, the other as MedicationStatement with different fields populated. Both were compliant. The reconciliation logic ended up larger than the feature it supported.

Where teams get it wrong

  • Assuming FHIR compliance means two systems represent data the same way.
  • Building against the specification instead of against the target vendor's implementation.
  • Underestimating scopes, consent and the SMART on FHIR authorisation layer.
  • Treating optional fields as reliably present.
  • Designing interfaces that assume complete records, which real data rarely is.

( Learn more )

Related terms

All terms

Defined by Mara Bureau LLP. Last reviewed . Corrections: hello@mara.ink.

( You may ask )

Questions about HL7 FHIR

Didn’t find your answer?

Ask us directly — a designer replies within one business day.

Contact us
  • A healthcare interoperability standard that models clinical concepts as resources exchanged over REST APIs in JSON or XML — the modern successor to HL7 v2 messaging, and the target for most new healthcare integration.

  • Profiling and optionality mean two compliant systems can represent the same fact differently, vendors implement different subsets, and authorisation runs through scopes and consent frameworks layered on top.

( Contact )

What problems are we solving?

At our core, we believe in delivering high-quality designs in days, not weeks.

What do you need?

( Contact )

What problems are we solving?

At our core, we believe in delivering high-quality designs in days, not weeks.

What do you need?