New Zealand HPI Implementation Guide
1.3.1 - Release

New Zealand HPI Implementation Guide - Local Development build (v1.3.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. 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