FHIR Integration in the Real World: Lessons from Building a Surgical Platform for NZ/AU

FHIR looks simple in a slide deck. Resources, RESTful endpoints, a shared vocabulary — plug the hospital in and data flows. Then you build a real platform that has to pull a patient's record from a live clinical system in New Zealand, assemble it into a surgical case view, and be trusted by a surgeon the morning of an operation. That is where the standard stops being a diagram and starts being an engineering discipline.

We learned this building OpBook360, a surgical coordination platform serving providers across New Zealand and Australia. Here is what standards-based interoperability actually costs, and why the tempting shortcut is the one that eventually breaks you.

Why point-to-point integration fails

The first instinct on any integration project is to wire directly to the source system. The EHR exposes an endpoint, you write code that speaks to it, data moves. It works in a demo. It works for one hospital.

Then you add a second hospital running a different EHR, and you write a second bespoke integration. Then a third. Now every source has its own auth model, its own data shape, its own outages, and its own upgrade schedule — and all of that leaks directly into your application code. A field rename upstream becomes a production incident downstream. Your business logic is now entangled with the quirks of five vendors. This is the N-times-M problem, and it does not scale; it accumulates.

Point-to-point is not wrong because it is inelegant. It is wrong because it puts the volatility of external systems in direct contact with the parts of your product that must stay stable.

The layer that saves you: adapters and a gateway

The architecture that survives contact with real hospitals separates concerns into two layers.

Adapters sit at the edge, one per source system. An adapter's only job is to speak the native dialect of a specific EHR and translate it into clean, canonical FHIR resources. All the ugliness — the vendor's authentication dance, its non-standard date formats, its idiosyncratic way of representing an allergy — is absorbed and contained here. When a vendor changes something, exactly one adapter changes. Nothing else moves.

A FHIR gateway sits behind the adapters and presents a single, consistent, standards-conformant interface to the rest of the platform. The application never talks to an EHR. It talks to the gateway, and the gateway always speaks proper FHIR. This is what lets you add hospital number six without touching a line of surgical-workflow code.

The quirks the spec does not warn you about

Standards describe the ideal. Deployed systems describe reality, and the two diverge in instructive ways.

Working with an EHR like Elixir in the New Zealand market surfaced the usual real-world friction: resources that are technically valid but semantically thin, optional fields that your workflow treats as required, and code systems that are almost — but not quite — the ones you expected. A "conformant" response can still be unusable if a critical clinical value lives in an extension the spec left open to interpretation.

The lesson is that FHIR conformance is a floor, not a guarantee. You still have to validate, reconcile terminologies, and handle the case where a field you depend on simply is not populated. The adapter layer is where all of that defensive work belongs.

Staged data flow into a case view

A surgical case view is an aggregate. It is not one FHIR resource; it is a patient's demographics, their conditions, their medications, prior procedures, and pre-operative assessments, assembled into a single clinical picture. We built this as a staged flow rather than a live join:

• Ingest — adapters pull source data and normalize it into canonical FHIR resources.
• Reconcile — resources are validated, de-duplicated, and terminology-mapped at the gateway.
• Assemble — the platform composes the case view from reconciled resources, applying surgical-workflow logic.
• Serve — the surgeon sees a stable, complete view, insulated from whatever the source system was doing at that moment.

Staging matters because clinical source systems are not built to be queried live under surgical time pressure. Decoupling ingestion from presentation is what makes the platform dependable when it counts.

What actually takes

Real interoperability is less about the FHIR spec and more about the discipline around it: isolate volatility at the edges, present one clean interface inward, treat conformance as the starting line, and never let a vendor's Tuesday become your production Wednesday. Get that architecture right, and adding the next hospital becomes a configuration exercise instead of a rebuild.