FHIR Healthcare Integration: An Architectural Guide for NZ Health Leaders
FHIR is often described as the future of healthcare integration. In reality, it is a powerful tool that only delivers value when applied with architectural discipline, governance, and clear ownership. This guide is written for NZ healthcare decision‑makers who need to understand where FHIR fits, where it does not, and how to avoid costly integration mistakes.
Book a 20-minute FHIR integration fit check
Executive architecture summary
- FHIR is a standard, not an integration strategy
- Profiles and governance matter more than APIs
- Most failed FHIR programmes fail due to ownership gaps, not technology
- Standards like Da Vinci succeed because they constrain behaviour, not data
The NZ healthcare integration reality
New Zealand healthcare environments typically operate across PAS, EMR, lab, radiology, and national services, often from multiple vendors and generations. HL7 v2 remains reliable for event‑driven workflows, while direct database access still exists in legacy estates. These patterns are not wrong, but they are brittle, difficult to govern, and risky when scaled.
FHIR introduces a modern, API‑driven approach, but it must coexist with existing integration patterns rather than attempting to replace them wholesale.
FHIR versus legacy integration patterns
- HL7 v2: Stable and predictable, but rigid and message‑centric
- Direct database access: Fast but high‑risk and difficult to audit
- FHIR APIs: Flexible, secure, and vendor‑neutral when governed correctly
In practice, mature healthcare architectures use all three, with FHIR reserved for use cases that benefit from standardised, reusable APIs.
FHIR profiles: where interoperability is won or lost
Raw FHIR resources are intentionally flexible. That flexibility is also their biggest risk. Without profiles, two systems can both be “FHIR‑compliant” and still be incompatible.
FHIR profiles constrain resources by defining required fields, allowed value sets, cardinality rules, and business expectations. They are not plumbing. They are governance.
Architecturally, profiles establish trust boundaries: they define what data means, not just how it is transported. Organisations that ignore profiling often experience version drift, vendor‑specific extensions, and escalating integration costs.
What the Da Vinci Project teaches us
The US‑based Da Vinci Project demonstrates how FHIR delivers value when paired with constrained implementation guides. Rather than exposing generic APIs, Da Vinci focuses on end‑to‑end workflows such as coverage discovery, prior authorisation, and clinical documentation exchange.
Its success lies in limiting variation. By defining what “good” looks like, Da Vinci enables automation at scale. While NZ does not directly adopt these guides, the architectural lesson is universal: interoperability improves when behaviour is constrained intentionally.
Security, governance, and operational ownership
Exposing FHIR APIs expands the attack surface of a healthcare organisation. Identity management, access control, audit logging, and lifecycle governance are essential. Security cannot be layered on after integration decisions are made.
Successful programmes assign clear ownership for FHIR endpoints, profiles, and versioning. Without this, integrations drift, clinical trust erodes, and risk accumulates silently.
Who this guidance is for
- CIOs and Digital Health leaders
- Enterprise and integration architects
- Health vendors integrating with NZ providers
Who it is not for
- Projects seeking a plug‑and‑play interface
- Programmes without governance ownership
- Requirements that simply state “make it FHIR”
Need architectural clarity?
We help NZ healthcare organisations design integration architectures that balance HL7, FHIR, and modern APIs while protecting clinical workflows and reducing long‑term risk.
Book a 20-minute FHIR integration fit check