FHIR is a grammar, not a guarantee
FHIR gives healthcare a shared vocabulary — Patient, Observation, DiagnosticReport, Appointment — and a modern, RESTful way to move it around. That's a genuine leap forward from the pipe-delimited era. But a shared grammar doesn't mean two systems agree on what a sentence means. The hard part of interoperability was never the transport; it's the semantics underneath.
We treat FHIR as the easy 20% and the mapping as the 80%. The spec tells you the shape of the data. Your clinic's reality tells you what actually goes in it.
Start from the workflow, not the resource
It's tempting to model every FHIR resource up front and build a pristine data layer before shipping anything. Don't. That project never finishes. Instead, pick the one workflow that hurts most — pulling results into a patient app, pushing an appointment to the EHR — and integrate just enough to make it work end to end.
Shipping one workflow teaches you more about the clinic's data than a month of modelling. Every subsequent integration is faster because you've already met the edge cases.
Most clinics still speak HL7 v2
For all the momentum behind FHIR, the interfaces already running in a clinic are overwhelmingly HL7 v2. Lab feeds, ADT messages, the link to the PACS — decades of working plumbing. A pragmatic integration bridges v2 and FHIR rather than pretending the old system doesn't exist or demanding it be replaced first.
We build translation layers that speak v2 to the legacy world and FHIR to the new one, so a modern patient app can consume old lab feeds without the clinic ripping anything out.
Test with real, messy data
Production data is never as clean as the examples in the spec. Names with characters the old system couldn't store, dates in three formats, codes that were free-typed a decade ago, duplicate patient records nobody merged. A FHIR integration that only works against sample bundles will fail on day one.
We test against de-identified real feeds from the start, so the surprises happen in staging, not in front of a clinician with a patient waiting.
Fail loudly, reconcile safely
In healthcare, silently dropping a message is worse than refusing it. If a result can't be mapped, someone needs to know — with enough context to fix it — rather than a lab value quietly disappearing. We design integrations that quarantine what they can't process, alert a human, and never guess at clinical data.
Idempotency matters just as much: feeds get replayed, messages arrive twice, systems reconnect after an outage. Every write is designed so a duplicate is a no-op, not a second appointment.
A pragmatic checklist
- Integrate one painful workflow end to end before generalising
- Bridge HL7 v2 rather than waiting for a full FHIR estate
- Validate against de-identified production data, not samples
- Quarantine and alert on anything unmappable — never drop it
- Make every write idempotent so replays are safe
Need this done right? Epica builds medical software end to end. Talk to us →