New Zealand HPI Implementation Guide, published by Te Whatu Ora. This guide is not an authorized publication; it is the continuous build for version 1.5.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7NZ/hpi/ and changes regularly. See the Directory of published versions

Compliance Testing Important Information

Compliance testing

Provide the following details in a test report and email to integration@health.govt.nz.

1. Tester details
   a. Organisation Name
   b. Application name and version
   c. HPI IG Version
   d. Test Script version
   e. FHIR release version
   f. Testing start date and time and end date and time
   g. Tester name and contact details
   h. List of operations included in your integration (eg Get Practitioner, Get Location, Search Location)

2. For each test supply screen shots of the user interface for:
   • the input data as entered in the integrating application (“the application”)
   • the output:
     • any error messages presented by the application
     • the confirmation or result of the request presented by the application
   • For update operations the state of the record pre-request should be included.
   • Note: If non-interactive, please provide JSON request (update / create) or response (get/search).
3. For each test supply a timestamp when each request is sent.

Compliance tests

Not all compliance tests in this implementation guide will be appropriate for every application. If there are tests that do not apply please discuss this with the integration team and where appropriate write a description in the compliance test submission why the particular test does not apply.

Mandatory vs Optional tests

• If there are tests below that are labelled mandatory but do fit the application's use case then please let us know why.
• Some tests are labelled mandatory if. These tests are Mandatory only if you are using this piece of data for your use case.

To request a template for the compliance tests either add a comment to your onboarding request form or reach out using the Enquiry form.

Security and Audit Assessment

All test messages will be assessed against the security criteria in the table below

Reference	Purpose	Input values	Expected outcome	Mandatory
Security 1	Credentials match those issued to the testing organisation and their orgID and appID are auditing correctly	Checked against all tests	Te Whatu Ora will check internal logs	Mandatory
Security 2	Sending user ID is an end user ID or a hpi-person-id	Checked against all tests	Te Whatu Ora will check internal logs	Mandatory
Security 3	Sending user ID changes when different end users are initiating the request (Please make sure a seperate user creates a request)	Checked against all tests	Te Whatu Ora will check internal logs	Mandatory
Security 4	Each request has a unique request id in the X-Correlation-Id field If present this will be returned in the response	Checked against all tests	Te Whatu Ora will check internal logs	Recommended

General tests

These tests apply to all integrations

Reference	Purpose – Demonstrate that the	Input values	Expected outcome	Mandatory / Optional / Recommended
General-1	Application can handle an HTTP 429 error in a graceful way	The application reaches its usage plan limit and is returned an HTTP 429 error. See Usage plans	The application will retry several times with an exponentially increasing delay	Recommended
General-2	Application can present the HPI terms of use to individual user's when the integrating application first goes live for an Organisation. A reference terms of use is supplied, or the HPI terms of use can be included as part of the application's terms of use.	See Terms Of Use	The application will display terms of use to the end user The application must store the end users acceptance of the terms	Recommended