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
Please provide the following details in a test report and email it to integration@health.govt.nz.
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 |
Test Specifications are grouped as follows.
Base API Compliance Testing (below)
Search and Read Compliance Testing
Notifications Compliance Testing
Terminology Service Compliance Testing
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 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) |