New Zealand MWS IG
1.1.5 - Release

New Zealand MWS IG - Local Development build (v1.1.5) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

## Compliance Testing Important Information

### Compliance testing process

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. NHI IG Version
   d. Test Script version
   e. FHIR release version (Get(Endpoint)/metadata)
   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 Patient, Search(Match) Patient)

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 an hpi-person-id (CPN) | 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. | The application will retry several times with an exponentially increasing delay | Recommended