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 Nzhts Tests

Health NZ Terminology Service

The Health NZ Terminology Service (NZHTS) provides standard codes and display values used by all applications that present or create immunisation data. While many read-only use cases can use display or text values contained within FHIR resources from the AIR, any application sending data to the AIR shall use terms and concept properties specified in the NZHTS to avoid validation failures.

Terms are grouped according to likelihood, frequency and impact of changes. Subscriber applications shall synchronise frequently and infrequently changing terms with NZHTS on a regular cadence (typically nightly) using the NZHTS APIs. Vendors are required to perform manual validation prior to changes being applied. Detailed requirements are available on request to the AIR project team.

If your application requires the NZHTS, then request access when Onboarding.

As no Terminology Service sandbox is available, compliance may be obtained via demonstration in the vendor’s environment and planning for production validation testing (PVT). To do this, arrange a Teams call with the AIR project team. This will be recorded.

NZHTS Compliance Tests

Reference	Test	Test Data Input	Compliance Test Evidence	Mandatory / Optional / Recommended
AIR-Term-1	GIVEN my application is a consumer of the immunisation and NZHTS APIs AND a new Vaccine Product available in NZ is added to the value set AND the Vaccine Product is used on a new immunisation record WHEN a Create API call is made to create the immunisation event THEN the immunisation record specifies the new Vaccine Product.	Vaccine Product newly available in NZ.	If suitable terminology data is not available in the Production NZHTS, then demonstrate connectivity to the NZHTS separately from the feature consuming changed values in a test environment. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR. Send screen shots demonstrating approval process. Send a screenshot showing that the Immunisation record was created using the new vaccine.	Mandatory
AIR-Term-2	GIVEN my application is a consumer of the immunisation and NZHTS APIs AND an approved change to Vaccine Product properties AND the Vaccine Product is used on a immunisation record WHEN the user uses the changed Vaccine Product THEN the application displays or makes available the updated properties.	Vaccine Product with changed Display and Indications.	If suitable terminology data is not available, then demonstrate connectivity and functionality separately as above. Send screen shots demonstrating approval process and UI behaviour change when Vaccine Product properties are updated. Send a screenshot showing that the Immunisation record was created using the changed terms. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR.	Mandatory
AIR-Term-3	This test only applies to applications that support Administered Products (TPUU items in the NZULM). GIVEN my application is a consumer of the immunisation and NZHTS APIs AND an immunisation record with attributes not conforming with an Administered Product's properties WHEN the user attempts to save the record THEN the application requires the user to confirm the non-conformant values AND if confirmed then a Create API call is made to create the immunisation event. Repeat the test performing an Update request.	Immunisation Event with no diluent batch or expiry date for an Administered Product that requires a diluent. Immunisation Event with body site not among those available for the Administered Product.	If suitable terminology data is not available, then demonstrate connectivity and functionality separately as above. Send screen shots demonstrating approval process and UI behaviour change when Vaccine Product properties are updated. Send a screenshot showing that user was required to confirm the anomalous data entry. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR.	Mandatory (conditional)
AIR-Term-4	GIVEN my application is a consumer of the immunisation and NZHTS APIs AND an approved change made to "infrequently changing" value set AND a changed value in the value set is used on a immunisation record WHEN a Create API call is made to create the immunisation event THEN the immunisation event contains the changed value.	Changed entry in value set in the "infrequently changing" list.	Use an 'infrequently updated' value set that changed recently. If suitable terminology data is not available, then demonstrate connectivity and functionality separately as above. Send screen shots demonstrating approval process and UI behaviour change when the PMS is updated. Send a screenshot showing that the Immunisation record was created using the changed terms. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR.	Recommended
AIR-Term-5	GIVEN my application is a consumer of the immunisation and NZHTS APIs AND an immunisation record with event date not conforming with a Vaccine Product's properties WHEN the user attempts to save the record THEN the application requires the user to confirm the non-conformant date AND if confirmed then a Create API call is made to create the immunisation event. Repeat the test performing an Update request.	Immunisation event with today's date for a vaccine no longer available in NZ, with batch, body site and route (statusReason GIVEN, not HSTGIVN). Vaccine Product codes meeting this requirement: 04, 06, 09, 44, 103, 116, 127, 160, 208, 210, 99003, 99013	If suitable terminology data is not available, then demonstrate connectivity and functionality separately as above. Send screen shots demonstrating approval process and UI behaviour change when Vaccine Product properties are updated. Send a screenshot showing that user was required to confirm the anomalous data entry. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR.	Recommended
AIR-Term-6	GIVEN my application is a consumer of the immunisation and NZHTS APIs AND a Vaccine Product is added to the set of Overseas vaccines AND the Vaccine Product is used on a new immunisation record with statusReason GIVNOS WHEN a Create API call is made to create the immunisation event THEN the immunisation record specifies the changed Vaccine Product.	Vaccine Product now available Overseas. Body Site, Route, batch details are optional.	If suitable terminology data is not available in the Production NZHTS, then demonstrate connectivity to the NZHTS separately from the feature consuming changed values in a test environment. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR. Send a screenshot showing that the Immunisation record was created using the Overseas vaccine.	Recommended
AIR-Term-7	This test applies if the Application supports Historical vaccinations. GIVEN my application is a consumer of the immunisation and NZHTS APIs AND a Vaccine Product is added to the set of Historical vaccines AND the Vaccine Product is used on a new immunisation record with statusReason HSTGIVN WHEN a Create API call is made to create the immunisation event THEN the immunisation record specifies the changed Vaccine Product.	Vaccine Product now available for Historical events. Body Site, Route, batch details are optional.	If suitable terminology data is not available in the Production NZHTS, then demonstrate connectivity to the NZHTS separately from the feature consuming changed values in a test environment. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR. Send a screenshot showing that the Immunisation record was created using the Historic vaccine.	Recommended (conditional)
AIR-Term-8	This test applies if the Application supports Administered Products. GIVEN my application is a consumer of the immunisation and NZHTS APIs AND an Administered Product available in NZ requires diluent AND the Administered Product is used on a new immunisation record AND the user does not provide diluent batch details WHEN the user attempts to save the record THEN the Application requests confirmation AND if confirmed then a Create API call is made to create the immunisation event. Repeat the test supplying a Body Site not in the set expected for the Administered Product.	Administered Product that requires diluent.	If suitable terminology data is not available, then demonstrate connectivity and functionality separately as above. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR. Send a screenshot showing that the user was required to confirm the anomalous data entry.	Recommended (conditional)