Aotearoa Immunisation Register (AIR) FHIR Implementation Guide (API-V2)
2.0.0-SNAPSHOT - ci-build New Zealand

Aotearoa Immunisation Register (AIR) FHIR Implementation Guide (API-V2) - Local Development build (v2.0.0-SNAPSHOT) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Compliance Testing Base API Tests

Compliance Testing Important Information

Compliance Testing Process

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

  1. Tester Details
    • Organisation Name
    • Application name and version
    • Application HSAPP ID (if applicable)
    • AIR FHIR IG Version
    • Test Script Version
    • Testing Start Date and Time and End Date and Time
    • Tester Name and Contact Details
    • List of Operations Included in Your Integration (e.g., AIR Read, AIR Write)
  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)
  3. For each test supply a timestamp when each request is sent.

Test Data

AIR uses test identifiers from the NHI UAT environment. Do not update/change any of the immunisation data or NHI records in the table below. These consumers and related data are reserved for these compliance tests.

Vendors integrating with Write APIs (Create, Update, Upsert) will be provided NHI numbers for their testing.

To access a list of NHI test identifiers follow this link and search for text NHI Test Data. To specifically test the new NHI number format, go to Upcoming Changes to the NHI and download the spreadsheet under the heading 'Change to the check digit algorithm'.

NHI Number (reserved) Description
ZMM7002 Full set of completed childhood immunisations (no anomalies) +ZDH3912
ZUA48EH No immunisation events
ZMM8521 Full set of statuses & status reasons
ZJM9567 Travel vaccinations
ZKC4641 Vaccinations with data quality issues - 3 events
ZHZ9215 Vaccinations with maximum characters: vaccine source text field has 255 char, lotNumber is 50 char, body site is 18 char.
Also has Data Quality issues including: body site code, route code, unrecognised vaccine code, vaccine batch exp date, vaccine diluent exp date.
ZMM8637 Multiple events that cannot display on a single page - can also use ZMM7002
ZDH3343 (D)
ZDH3351 (D)
ZDH3335 (L)
Live NHI with at least 2 dormant NHIs associated to it
Can also use ZAT2518 (D) ZAT2496 (L)
ZFE35PQ Restricted Access - immunisation history is redacted
ZXE24NV New format NHI (7 digits, Mod23 check sum)
ZHS7524 Historic immunisations, from a period with data that does not comply to current standards
ZAA0547 DOD 2016-05-12, has Imms prior to 2016, DOB is 1954-11-01
ZDH3769 Minimum Data - ISD
ZDH3513 Max data - all fields are populated
ZKL2308 Has selection of not-done and status reasons, incl 1 entered-in-error
ZDH3572 Has mix of status and status reasons: not-done (DPC / DMC / RESCHO), GIVNOS (given overseas), HSTGIVN (Historic)
ZHZ9398 Has dose 98 representing null dose number
ZDH3513 Has dose 99 representing early-life Dose 0
Description Link
Health NZ Aotearoa Immunisation Register – Immunisation API https://www.tewhatuora.govt.nz/health-services-and-programmes/digital-health/digital-services-hub/explore-apis-digital-services/aotearoa-immunisation-register-immunisation-api
How to access Health NZ Digital Services Hub https://www.tewhatuora.govt.nz/health-services-and-programmes/digital-health/digital-services-hub/consumer-onboarding
AIR FHIR Implementation Guide https://healthnz-prm.gitlab.io/air/air-api-fhir-ig/index.html

Compliance Test Structure

Test Specifications are grouped as follows.

Base API Compliance Testing (below)

  • Base tests apply to all types of request to AIR APIs.

Search and Read Compliance Testing

  • These tests apply to all applications accessing immunisation data.

Write Compliance Testing

  • Write API tests apply to all requests that change immunisation data in the AIR.

Notifications Compliance Testing

  • The National Event Management System (NEMS) is used by applications that hold immunisation data locally, namely Practice Management Systems (PMS), to receive update and duplicate resolution event notifications.

Terminology Service Compliance Testing

  • The NZHTS provides standard codes, value sets and concept maps used by all applications that present or create immunisation data. Any application sending data to the AIR shall use terms and concept properties specified in the NZHTS to avoid validation failures. Subscriber applications shall synchronise terms with NZHTS on a regular cadence (typically nightly) using the NZHTS APIs.

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 (conditional). These tests apply only if you are using this data or functionality for your use case.

  • A template for reporting compliance test results is available here: AIR_Compliance - Template v1.2.docx

  • For further information, either add a comment to your onboarding request form or reach out using the Enquiry form.

Base Tests

Base API tests apply to all types of request to AIR APIs. For server end points refer to the Open API Specification available under the Support menu in this IG. Use the UAT end points for Compliance Testing.

Reference Requirement Purpose Test Test Data Input Compliance Test Output Mandatory
AIR-Base-1 RBAC: Role-Based Access Control (RBAC) The application demonstrates the ability to ensure only authorised users are allowed to access clinical immunization information. 1a. GIVEN my application is a subscriber to the immunisation history (Search Immunisation) API
And I am an authorised user with an authenticated application
And I am classified as registered workforce or working on behalf of a person classified as registered workforce
WHEN I navigate to view immunisation history information
THEN an API call can be made
And the Application displays Immunisation history information

1b. GIVEN my application is a subscriber to the immunisation history (Search Immunisation) API
And I am an authorised user with an authenticated application
And I am NOT classified as registered workforce or working on behalf of a person classified as registered workforce
WHEN I navigate to view immunisation history information
THEN an API call can NOT be made
And the Application does NOT display Immunisation history information
And the application displays a message stating that authorisation has failed.
1a. Subscriber's Application calls the Immunisation History (Immunisation Search) API and passes the NHI number to the API only when a user authorised to view AIR immunisation data is logged in to the Application.

1b. Subscriber's Application logged in user is NOT authorised to view AIR immunisation data.
1a. Screenshot/s showing the subscriber's application screen/s displaying the Immunisation History information only when an authorised user who is classified as registered workforce or working on behalf of a person classified as registered workforce is logged in to the Application.

1b. Screenshot/s showing the same application screen/s NOT displaying the Immunisation History information when the user logged in to the Application does not have authorisation, with the authorisation failure message that is displayed to the user, or other evidence they are denied access. Web application screen shots should include the URL attempted to be accessed, showing spoofing attempt failing.
Mandatory
AIR-Base-2 Request context header appropriately populated The Request-Context HTTP header is populated in each request/API call with correct information as specified in the Request-Context.json schema GIVEN my application is a subscriber to the immunisation history (Search Immunisation) API
WHEN an API call is made
THEN the Request-Context header properties are populated as specified in the schema and base-64 encoded. The schema is defined in:
https://github.com/tewhatuora/schemas/blob/main/json-schema/Request-Context.json

Te whatu ora will validate your request and verify it includes the request context information.
The subscriber's Application sets the following fields in the Request-Context HTTP header:
userIdentifier: the subscriber's Application logged in user.
facilityIdentifier: the HPI-F code assigned to the Facility
secondaryIdentifier: If the person triggering the request is not registered with any New Zealand health body on the list provided, values must remain empty (empty string).
userRole and purposeOfUse are also required.

For detail on each attribute see README.md and Developer Guide
Send a screenshot showing the logged in user
Send the context-header in plain text including userIdentifier, facilityIdentifier and secondaryIdentifier, for example:
        {
          "userIdentifier":"pms-user-id-123",
          "userRole":"PROV",
          "secondaryIdentifier":{
              "use":"official",
              "system":"https://standards.digital.health.nz/ns/medical-council-id",
              "value":"RA99Z"
          },
          "purposeOfUse":[
              "POPHLTH"
          ],
          "userFullName":"Beverly Crusher"
        }
        
Mandatory
AIR-Base-3 Credentials: ensure the value assigned to userIdentifier reflects the Application's logged-in user userIdentifier within the Request-Context changes when different end users are initiating the request GIVEN my application is subscribed to the Immunisation History (Search Immunisation) API
WHEN a new API call is made
THEN the sending user's userIdentifier must correspond to the currently logged-in user.
Repeat the above Test AIR-Base-2 with a different user being logged to the subscriber's application. Send a screenshot showing the logged in user
Send the X-Correlation-ID and the value that have been set for the userIdentifier field in the context-header
Mandatory
AIR-Base-4 Credentials: Universally Unique ID (UUID) in the Correlation ID Each request has a UUID in the X-Correlation-ID field
If present this will be returned in the response
GIVEN my application is a subscriber to the immunisation history (Search Immunisation) API
WHEN an API call is made
THEN a universally unique ID is present in the X-Correlation-Id HTTP header
Subscriber application sets the x-correlation-id to a unique auto generated value (ideally GUID) in API calls, for example the previous two tests AIR-Base-2 and AIR-Base-3 should set the x-correlation-id to different unique values. Send x-correlation-id or screenshot that shows them for each API request/call, for example the previous two tests AIR-Base-2 and AIR-Base-3 should have set the x-correlation-id to different unique values. Mandatory
AIR-Base-5 Error Handling and messages to end users The application has robust error handling and ensures meaningful, friendly error messages are displayed. GIVEN my application is a subscriber to the immunisation history (Search Immunisation) API
WHEN an API call is made
And an error occurs
THEN a meaningful, friendly message is displayed
And if possible the message provides instruction on what the user needs to do.

User experience should be tailored according to user needs. The OperationOutcome diagnostics text could be displayed to the end user for generic error-handling.
Send an Immunisation Search Request for an invalid NHI (e.g. "ZZZ0B12") Send a Subscriber's Application screenshot showing the message displayed to the end user with the Application window displayed when the error occurred. Mandatory
AIR-Base-6 Application can appropriately handle rate limiting (HTTP 429) The application has robust error handling and ensures meaningful, friendly error messages are displayed. GIVEN my application is a subscriber to the immunisation history (Search Immunisation) API
WHEN an API call is made and the application receives 429 error code having reached its usage plan limit
THEN the application handles this gracefully by informing the user to wait few seconds or it displays an hourglass icon as a way of backing off before sending another request.

User experience should be tailored according to user needs. The OperationOutcome diagnostics text could be displayed to the user for generic error-handling.
The application reaches its usage plan limit and it receives HTTP 429 response code then it handles this gracefully, for example informing the user to wait few seconds, or displaying an hourglass icon as a way of backing off before sending another request. Please provide estimates and evidence where available of peak API request rates and volumes, to ensure your application is assigned the correct rate-limiting tier by HNZ - by default rate limiting will be set at Bronze level (1 request per second, 10,000 requests per day). Also,
Either
Send a Subscriber's Application screenshot showing the message displayed to the end user with the Application window displayed when the error occurred.
OR
State that you are aware that AIR APIs have rate limiting and that you do not expect the number of requests that your application will make to exceed the AIR plan limit you are requesting.
Mandatory (no test evidence required but it is Mandatory the application handle this)