FHIR in Practice

I spent two years at Cerner (now Oracle Health) building FHIR-compliant clinical APIs. The spec is 3,000+ pages. The reality is muddier than the spec suggests.

What the spec gets right

FHIR (Fast Healthcare Interoperability Resources) solves a real problem: healthcare data is trapped in silos, and every system speaks a different language. FHIR provides:

• A standard data model (Resources: Patient, Observation, Encounter, etc.)
• A standard API (RESTful, with search, pagination, and versioning)
• A standard terminology binding (LOINC, SNOMED, ICD-10)

This is genuinely valuable. Before FHIR, integrating two hospital systems meant months of custom HL7v2 message mapping.

What the spec glosses over

• Partial conformance — Every vendor implements a different subset of FHIR. The spec says “SHALL support,” the vendor says “we will get to it.”
• Extension sprawl — The spec is extensible by design. In practice, this means every implementation has custom extensions that break interoperability.
• Performance at scale — The spec does not prescribe how to serve 50K requests per day with sub-200ms latency. That is an engineering problem, not a standards problem.
• Temporal complexity — Clinical data has bi-temporal semantics: when did it happen vs. when did we learn about it. The spec acknowledges this but most implementations punt on it.

The takeaway

Standards are necessary but not sufficient. The real engineering happens in the gap between the specification and production. This is true for FHIR, and it is true for every other standard I have worked with.