Information for IT vendors and developers

Purpose

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. 

Audience

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.

Scope

These principles cover the Health Identity systems:

• National Health Index (NHI) – Patient Identity
• Health Practitioner Index (HPI) – Practitioners, Organisations, Facilities, Services, and Teams

Related Documents

This document should be used in conjunction with integration guidance, compliance requirements, and technical specifications provided for each web service. 

1. The NHI & HPI are the master sources of identity information in the health sector for patients, practitioners, organisations, facilities, services, and teams.
   
   
2. Integrating systems should use the NHI & HPI to obtain and confirm national identifiers to support identity functions within their systems.
   
   
3. The NHI & HPI should be updated first before integrating systems which should then synchronise with the updated master data sources.
   
   
4. 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.
   
   
5. Any data retrieved from the NHI & HPI should be considered potentially out of date as soon as it is retrieved.
   
   
6. 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.
   
   
7. 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.
   
   
8. 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.
   
   
9. 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.
   
   
10. 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).
    
    
11. 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.
    
    
12. 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).
    
    
13. 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.
    
    
14. Integrators should follow the design standards and patterns detailed in the Common Web Services Technical Specification.