Healthcare Interoperability in NZ: What the Standards Don't Tell You
New Zealand's health system is in a significant transition period. The move to Health New Zealand / Te Whatu Ora, national platform investment, and regional consolidation are reshaping what interoperability means for local teams. This is not a primer on FHIR. It is a practical view of what NZ clinical IT teams are actually dealing with.
The NZ Interoperability Landscape in 2025
The creation of Health New Zealand / Te Whatu Ora as a single national health authority was not merely an administrative reorganisation. It changed the integration obligations of every provider operating within the publicly-funded system. Where the former District Health Board structure produced 20 separate IT environments — each with their own vendor relationships, interface estates, and governance — the national authority model is pushing toward consolidated standards, shared platforms, and common connectivity expectations.
In practice, the three national platforms that matter most for day-to-day integration work are the National Health Index (NHI), the Health Provider Index (HPI), and the National Enrolment Service (NES). These are not new. What has changed is the expectation that regional systems connect to them consistently, that connections are verified, and that data quality is maintained at source rather than corrected downstream. For many legacy estates, that expectation has arrived ahead of the technical readiness to meet it.
The dominant clinical platforms across NZ public health remain TrakCare (widely deployed across former DHB environments), HealthShare (used for a range of clinical and administrative integration scenarios), and Orion Health (a long-standing NZ vendor with significant national data platform presence). These systems are mature, deeply embedded, and built primarily around HL7 v2 messaging patterns. Understanding the interoperability challenge in NZ means understanding how these platforms behave, where they fall short, and what connection to national services actually requires in their context.
The FHIR direction is real. Te Whatu Ora has made clear that new national API connections should be FHIR-based, and there is genuine investment in NZ FHIR profiles and implementation guides. However, the gap between where NZ is headed and where most regional estates actually sit today is substantial. The majority of operational clinical messaging across NZ hospitals — ADT events, order messages, result delivery, referral workflows — runs on HL7 v2. That is not changing within a five-year horizon for most sites, and any integration strategy that ignores this is not a strategy; it is a wishlist.
Regional variation compounds the picture. Former DHB estates carried their own integration middleware, their own interface catalogues, and their own approaches to national platform connectivity. Consolidation has not yet resolved this. What exists across many NZ hospital environments today is a patchwork of HL7 v2 interfaces in active production, some FHIR-capable endpoints in pilot or limited deployment, and national platform connections of varying maturity and reliability.
What NHI and HPI Integration Actually Involves
The National Health Identifier is the cornerstone of patient identity in NZ. Every person who receives health services in New Zealand is assigned an NHI number, and that number is the primary patient matching key across all NZ clinical systems. This sounds straightforward until you work in it.
Correct NHI integration is not simply a matter of storing an NHI number in a field. It requires real-time NHI lookup at the point of registration or admission — not reliance on a locally-held MRN or a previously verified NHI from a prior encounter. It requires graceful handling of lookup failure: what happens when the NES connection is unavailable, when the patient presents without verifiable identity, or when the returned NHI does not match the locally-held record? And it requires that the verified NHI is propagated downstream — to ordering systems, to lab, to radiology, to external referral recipients — so that downstream patient matching relies on the correct national identifier rather than a local surrogate.
Common NHI integration errors seen in NZ environments include: duplicate NHI records created because admission staff bypassed the lookup step; unverified NHI records where the lookup occurred but the result was not confirmed against identity documents; and NHI lookup failures at admission that silently defaulted to local MRN-only workflows, breaking the chain of national patient identity downstream. In a TrakCare or HealthShare environment, the integration mechanisms for NHI lookup are established, but the operational discipline to use them consistently — and the monitoring to detect when they are not — is frequently absent.
The Health Provider Index serves a parallel function for provider identity. HPI numbers identify individual health practitioners and the organisations they work for, and they are increasingly required for accurate attribution of clinical events — particularly where national reporting, e-prescribing, or cross-organisational referral workflows are involved. In practice, HPI is consumed at the application layer in most NZ clinical systems, surfaced through practitioner lookup against the national register. The integration challenge is less about the API connection and more about keeping local practitioner records synchronised with the national register and ensuring HPI is populated correctly in outbound messages.
The FHIR Adoption Reality in NZ
FHIR is being used in NZ health today — but not uniformly, and not for the workflows that most clinical staff interact with daily. The clearest examples of live FHIR deployment are patient portals (where consumer-facing apps use FHIR APIs to surface appointment, medication, and results data), new national API connections being built under the Te Whatu Ora platform programme, and greenfield vendor integrations where FHIR was specified from the outset. These are real, but they represent a small portion of the total integration surface in any NZ hospital environment.
HL7 v2 remains the operational standard for the core clinical workflow events that matter most: patient admissions, discharges, and transfers (ADT); laboratory order and result messaging (ORM/ORU); radiology workflow; and inpatient medication events. These interfaces are deeply embedded in the middleware layers of TrakCare and HealthShare environments. Replacing them with FHIR equivalents is not a technical decision; it is a programme of work that requires clinical validation, interface re-engineering, testing cycles, and go-live governance. For most NZ estates, that work is not funded, not scheduled, and not in the near-term roadmap.
The governance gap around FHIR in NZ is significant. NZ FHIR profiles exist — the NZ Base Implementation Guide and related artefacts published under the HL7 NZ organisation provide a baseline. But real-world conformance to these profiles varies substantially between implementations. Systems claiming FHIR capability often mean they can expose or consume FHIR-formatted data, not that they conform to any specific NZ profile or that their implementation has been validated against one. Without conformance testing infrastructure and a clear expectation of what "NZ-compliant FHIR" means in practice, profile drift accumulates and interoperability between FHIR-capable systems cannot be assumed.
The operational reality for most NZ hospitals is a dual estate: HL7 v2 interfaces handling the bulk of clinical messaging, and FHIR endpoints supporting specific newer use cases. Maintaining both patterns simultaneously is not free. It requires integration middleware capable of handling both, staff who understand both, documentation that covers both, and governance that owns both. Organisations that have invested in FHIR for new connections without assessing what that means for their existing integration team's capacity and skills are finding this out the hard way.
The Interoperability Problems NZ Teams Bring to Us
The following are not hypothetical scenarios. They represent the patterns that recur across NZ health integration engagements.
Interface estates with no documentation, no runbooks, no clear ownership. A former DHB environment may have 80 to 150 active interfaces. In many cases, there is no current interface catalogue, no record of what each interface does or which version of the message spec it implements, no documented failure mode or escalation path, and no named owner responsible for its ongoing operation. When something breaks — or when a platform upgrade threatens to break it — the absence of this information becomes an immediate delivery risk.
FHIR initiatives launched without profiling governance or conformance testing. A programme commits to FHIR for a new application integration. The vendor delivers a FHIR API. The implementation goes live. Six months later, it becomes apparent that the API does not conform to any published NZ profile, that the resource structures diverge from what the next integration partner expects, and that there is no process for managing FHIR versioning as the programme evolves. The cost of retrofitting governance onto a live FHIR implementation is substantially higher than building it in at the start.
National platform connections required before programmes are technically ready. Reporting obligations, funding conditions, or programme timelines create pressure to connect to NHI, HPI, or NES before the local system is ready to handle the connection correctly. The result is connections that are technically live but operationally unreliable — NHI lookups that succeed intermittently, HPI data that is not propagated correctly, or NES enrolment workflows that bypass the correct verification steps. These issues do not always surface immediately, but they compound over time.
Go-live pressure with integration readiness not confirmed. The clinical go-live date is fixed. The integration readiness assessment has not been completed. Interface testing is partially done. The NHI lookup has passed in a test environment but has not been validated under realistic load. The downstream systems have not signed off their end of the integration. Go-live proceeds anyway. In this scenario, the clinical risk is real, and the recovery effort post-go-live — debugging live interfaces, correcting patient matching errors, rebuilding trust with clinical users — is consistently more expensive than the investment in readiness that was skipped.