National Health Index (NHI)
The NHI holds a unique identifier for each individual, as well as the source of truth for key demographic information for an individual.
This section contains information for developers about integration of NHI interfaces, the onboarding process, NHI number validation routines, test data available in the compliance environment, and the upcoming NHI number format change.
Please read the ‘Web Services Integration - Health Identity Design Principles’ prior to starting your integration with the NHI.
The NHI FHIR API is available now. See the NHI FHIR implementation guide.
To view other API’s and digital services available, head to the Hira marketplace.
The HL7v3 (SOAP) and HL7v2 (Legacy) NHI Interface information has been archived, but may be accessed if required by emailing firstname.lastname@example.org
NHI onboarding process
All health providers listed in Schedule 2 of the Health Information Privacy Code and software vendors will be given access to all the NHI FHIR API operations in the HIP Compliance environment for testing and training after completing the on-boarding process.
Click here for more information.
Access to NHI operations is available to all health providers listed in Schedule 2 of the Health Information Privacy Code.
NHI number validation routines
NHI Test identifiers
NHI records Mod23
NHI number format change
Health Provider Index (HPI)
The HPI consists of 4 indexes or data sets:
- HPI Practitioner – holds identity and registration details for over 170,000 practitioners.
- HPI Organization – holds identity and contact details of over 12,000 organizations providing healthcare
- HPI Facility (Location resource) - holds identity, location and contact details of over 11,000 facilities or places where healthcare is provided.
- HPI PractitionerRole – holds the relationship details of practitioners to the places where they work and the organizations they work for, and the role they have there.
This section contains information for developers about integration of HPI interfaces, the onboarding process, HPI number validation routines, and test data available in the compliance environment.
Please read the ‘Web Services Integration - Health Identity Design Principles principles’ prior to starting your integration with the HPI.
HPI onboarding process
All organisations and software vendors will be given access to all the HPI API operations in the HIP Compliance environment for testing and training after completing the on-boarding process described below.
Access to HPI Organisation and HPI Facility Search and Get interactions is available to all health providers, responsible authorities and organisations who provide supporting services to health providers and responsible authorities.
Health providers and responsible authorities with existing HPI Data Access and Provision Agreements will be given access to Get and Search Practitioner under those agreements. This includes Districts, ACC and health agencies employing practitioners to deliver health services e.g. Laboratories.
Health providers without an agreement wanting access to Get, Search, Update and Create Practitioner and any organisations wanting access to PractitionerRole Get, Search, Create and Update operations will need to apply to Te Whatu Ora. The application will be assessed by Te Whatu Ora's sector digital channels. If granted, an access agreement may be required prior to credentials being issued to production.
HPI identifiers validation routines
HPI Practitioner (CPN) Test Data
HPI Organisation and Facility Test Data
National Medical Warning system (MWS)
MWS is a value-added service closely aligned with the National Health Index. It is designed to warn healthcare providers of the presence of any known risk factors that may be important when making clinical decisions about patient care.
The MWS comprises the following features:
- medical warnings incorporating adverse medical reactions and significant medical conditions (MWS)
This section contains information for developers about integration to the MWS interface, the MWS data dictionary, and the onboarding process.
MWS Data dictionary
MWS onboarding process
For information about onboarding to the national MWS please email email@example.com
Health Care Events (HCE)
Healthcare event summaries are derived from event reports to the National Minimum Dataset and are therefore restricted to hospital events. The summary includes the facility (hospital) the person was in, the dates the person was in hospital, and the principal diagnosis causing admission to hospital. There is a field in the National Minimum Dataset that can prevent a summary from passing to HCE when absolute confidentiality is required.
Information about HCE’s is included in the MWS data dictionary:
HCE onboarding process
For information about onboarding to the HCE service please email firstname.lastname@example.org
National Enrolments Service
The National Enrolment Service is designed to provide a single source of truth for patient enrolments with their healthcare provider organisation e.g. general practice. It does this my maintaining a relationship between the patient identifier (NHI number), the enrolling organisation (HPI Organisation ID) and the facility where health care is provided (HPI facility ID).
This section contains information for developers about integration to the National Enrolments Service SOAP interface and the onboarding process.
National Enrolments Service interfaces
Access to the SOAP National Enrolments Service is available by emailing email@example.com
The National Enrolments Service FHIR API is on the Health Identity product backlog for more information on expected timeframes please contact firstname.lastname@example.org
A subset of the National Enrolment service information for a patient is returned in the NHI FHIR API GET response. For more information click here.
National Enrolments Service onboarding process
For information about onboarding to the National Enrolments Service please email email@example.com
The National Entitlements Service is designed to provide information on entitlements available to a patient. This includes information on Community Service Cards and High User Heath Cards, with other entitlements planned for future releases.
This section contains information for developers about integration to the National Entitlements Service SOAP interface and the onboarding process.
Patient Entitlements interfaces
Patient Entitlements onboarding process
For information about onboarding to the National Entitlements Service please email firstname.lastname@example.org
Te Whatu Ora's Address Validation Service (eSAM)
eSAM is Te Whatu Ora's Address Validation Web Services. eSAM is used to support accurate and standardised Address and Geospatial data within health sector applications.
This section contains information for developers about integration to the eSAM SOAP interface and the onboarding process.
The specifications, Integration Guide and User Guide for the Health-e-Address validation service are available to download.
We would appreciate you sending an email to HI_Administration@moh.govt.nz to advise that you have downloaded them and have an interest in integrating these services.
eSAM onboarding process
Please complete this form to apply for Address Service access authorisation or amend details of existing access and return to email@example.com
Web Services Integration - Health Identity Design Principles
This section lists principles for the use of the Health Identity web services. These principles must be applied by vendors and providers developing applications so that the Health Identity systems are used in a manner which aligns with Te Whatu Ora's strategic approach to using identity information in the sector and minimises risks to information security and privacy.
Applications accessing Te Whatu Ora's Health Identity systems and not aligning with these principles or not meeting compliance requirements based on these principles may not be granted access to the production environments.
This document is aimed at software vendors and healthcare providers developing systems integrating with the health identity web services. They should be understood by anyone involved in procuring, designing, developing, and implementing solutions that integrate with the health identity services.
These principles cover the Health Identity systems:
- National Health Index (NHI) – Patient Identity
- Health Practitioner Index (HPI) – Practitioners, Organisations, Facilities, Services, and Teams
This document should be used in conjunction with integration guidance, compliance requirements, and technical specifications provided for each web service.
- The NHI & HPI are the master sources of identity information in the health sector for patients, practitioners, organisations, facilities, services, and teams.
- Integrating systems should use the NHI & HPI to obtain and confirm national identifiers to support identity functions within their systems.
- The NHI & HPI should be updated first before integrating systems which should then synchronise with the updated master data sources.
- All NHI & HPI data should be retrieved via the provided API services in a JIT (Just-In- Time) manner when the data is used. The current APIs should not be used to perform bulk retrieval of data and integrations should be designed in a way that does not impact service performance.
- Any data retrieved from the NHI & HPI should be considered potentially out of date as soon as it is retrieved.
- Integrating systems are responsible for initiating any synchronisation of data held by the NHI & HPI. The integrating system is responsible for the persistence of the synchronisation state should this be required.
- Integrating systems must meet the compliance requirements provided to integrators before access to production systems is given and must continue to meet the compliance requirements throughout those systems’ lifecycle.
- Integrating systems must provide audit details to NHI & HPI APIs as outlined in the compliance requirements. For any person-identifiable data this includes identifying the individual user accessing the data (using their CPN) and the health provider they are working for.
- Te Whatu Ora will resolve identity conflicts where they are discovered, but integrating systems should be designed in a way that encourages and allows users to ensure NHI & HPI data is current and accurate.
- Integrators are responsible for ensuring they meet the security and privacy requirements applicable to managing patient-identifiable health information in New Zealand. Currently this includes the guidance and obligations specified in the Health Information Security Framework (HISF) and Health Information Privacy code (HIPC).
- Access requests are managed and approved by Te Whatu Ora to ensure that HIPC and operational requirements are met. Only those organisations for which Te Whatu Ora has agreed channels to report back and resolve data quality issues may be granted update access. Te Whatu Ora reserves the right to suspend or terminate access if data quality is compromised.
- It is the integrator's responsibility to authenticate, authorise, and audit their own users’ access to the HPI & NHI (see circles of trust model in documentation).
- Te Whatu Ora will support the current version of the API and the previous version (n – 1) at any point. It is the integrator’s responsibility to upgrade to supported versions of the API to maintain currency.
- Integrators should follow the design standards and patterns detailed in the Common Web Services Technical Specification.