HL7 FHIR R4 in production — what nobody tells you
FHIR R4 gets you a common data model, not plug-and-play interoperability — the hard parts are identity, terminology, versioning and the gap between what the spec allows and what each vendor actually implements.
By WASS Interoperability practice
Pitfall 1: assuming FHIR means interoperable
FHIR R4 standardises resource shapes and a REST API. It does not standardise which resources a vendor exposes, which fields they populate, how they handle search, or how they represent the same clinical fact. Two conformant servers can be mutually unintelligible in practice.
The fix is to treat every partner endpoint as a distinct dialect: capture a capability statement, write a conformance test suite against their sandbox, and keep a per-partner adapter rather than one universal client.
Pitfall 2: patient identity
The moment you connect two systems you have two patient identifiers for the same person and no guarantee they agree on name spelling, date of birth or address. Cross-system matching is a probabilistic problem, and getting it wrong merges or splits records.
Use an explicit identity service with a deterministic pass (national identifiers where available) followed by a probabilistic pass with a human review lane for the ambiguous middle. Never auto-merge above a confidence threshold without an audit trail and a reversal path.
Pitfall 3: terminology drift
If you accept free-text where a code belongs, you will get "BP", "b.p.", "blood pressure" and "hypertension" in the same field within a month. Downstream analytics and CDS then silently miss cases.
Stand up a terminology server (SNOMED CT, LOINC, RxNorm / local equivalents) and validate codes at ingestion. Reject or quarantine unmapped values instead of storing them.
Pitfalls 4–6: versioning, bulk data, and the audit surface
Version skew: partners upgrade their FHIR server on their own schedule. Contract-test against each partner in CI so an upgrade that changes search semantics fails your pipeline, not a clinician's screen.
Bulk export ($export) is the right tool for population data but it is asynchronous, rate-limited and returns NDJSON you have to reconcile against your incremental feed. Design for both from the start.
Every FHIR read is a potential disclosure. Audit logging, consent enforcement and SMART scopes are not add-ons — they are the reason a health network will let you connect at all.
Frequently asked questions
- Is FHIR R4 enough for full EMR interoperability?
- No. FHIR R4 provides a shared data model and API, but identity reconciliation, terminology binding, per-vendor conformance and consent enforcement all still have to be built on top.
- How long does a FHIR integration take?
- For a single well-documented partner endpoint, roughly 4–8 weeks. Multi-partner networks are typically a 3-month engagement because each endpoint behaves differently.
- Should we replace our HL7 v2 interfaces with FHIR?
- Usually not immediately. A transformation layer that exposes FHIR on top of existing HL7 v2 feeds lets you modernise consumers without touching systems that already work.
Work with the team that wrote this
Book a scoping call
Share your project goals and schedule a conversation with our team.
A clear next step
Free 30-minute discovery callGood projects start with a conversation.
Share your goals and the problem you want to solve. We’ll help you plan a useful starting point.
- 01Tell us your goal
- 02Explore the right fit
- 03Plan the next step
Your form will appear here
We’re preparing the questions for your project. You can complete them without leaving this page.