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

National Event Management Service (NEMS)

NEMS is used by applications that persist immunisation data locally, namely Practice Management Systems (PMS), to receive update and duplicate resolution event notifications.

Other solutions are expected to retrieve patient immunisation history as needed, so do not consume update event notifications from AIR via NEMS.

If your application requires NEMS, then request access when Onboarding. The AIR project team will reserve test HPI Organisation and Facility identifiers for your use.

Upon consuming a notification from the AIR, the PMS shall read the latest version of the immunisation event from AIR. 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.

NEMS Tests

</table>

Reference</td>	Test</td>	Test Data Input</td>	Compliance Test Evidence</td>	Mandatory</td> </tr> </thead>
AIR-Notif-1	GIVEN EITHER a new immunisation event created in the AIR portal (entered on behalf of the facility where given) or another PMS ('given elsewhere' for a patient enrolled at the practice) OR an update to an immunisation event in AIR not yet held in the Application AND the immunisation event created or updated has the patient's dormant NHI number AND the Application only has the patient's live NHI number recorded WHEN NEMS publishes the event to the organisation's queue with the Immunisation Update Topic THEN the Application performs a GET operation to fetch the record in the notification AND the Application persists the new record under the correct patient.	Set-up procedure: AIR Product team creates or updates an immunisation event with the dormant NHI number for a patient enrolled at the Application's facility. Run procedure: the Application processes events from its NEMS queue.	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 under the correct patient.	Mandatory (stateful clients)
AIR-Notif-2	GIVEN an update in AIR or another PMS to an immunisation event record held locally in the PMS that is not linked to AIR WHEN the event is emitted via NEMS to my queue with the Immunisation Update Topic THEN the Application performs a GET operation to fetch the record in the notification AND the Application links the local record using the AIR Identifier AND the Application updates the existing record.	Set-up procedure: AIR Product team updates an immunisation event that is was messaged prior to cut-over to APIs, or creates an exact copy in AIR of a record in the PMS. Run procedure: the Application processes events from its NEMS queue.	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.	Mandatory (stateful clients)
AIR-Notif-3	GIVEN an update in AIR or another PMS to an immunisation event record held locally in the PMS that is linked to AIR WHEN the event is emitted via NEMS to my queue with the Immunisation Update Topic THEN the Application performs a GET operation to fetch the record in the notification AND the Application updates the existing record.	Set-up procedure: AIR Product team updates a 'given elsewhere' immunisation event. Run procedure: the Application processes events from its NEMS queue.	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.	Mandatory (stateful clients)
AIR-Notif-4	GIVEN two immunisation records that were submitted using the Create API AND both events are linked to AIR AND the events have the same patient identifier and vaccine AND the events were completed on the same day NZ time AND the vaccine is not a double-dose vaccine AND the event records differ in other ways (any of route, body site, indication, dose number, health worker(s)) WHEN the status in AIR of one of the records has been changed to entered-in-error following administrative review AND NEMS has published an Immunisation Event Notification for the entered-in-error update AND NEMS has published a Duplicate Resolution event notification citing AIR Identifiers for the two records THEN the Application performs a GET operation to fetch the record in the IE notification AND the Application updates the corresponding record AND the Application closes any tasks created to resolve the Potential Duplicate DQ reported earlier.	Set-up procedure: the Application submits two records. The second record will return a Data Quality result indicating a Potential Duplicate. Note: if validation rules prevent the Application creating the required condition, then request that the AIR Test Analyst create the second record "on behalf of" the facility. Run procedure: the AIR Test Analyst updates one of the records to entered-in-error, resolving the Potential Duplicate DQ.	Send the AIR Identifiers of the two records. Send the x-correlation-ID header sent with the request and the AIR Identifier received from AIR. Send a screenshot showing the Immunisation record that was invalidated on resolution of the potential duplicate. Optionally, send a screenshot showing the task to resolve the potential duplicate (depends on solution).	Mandatory (stateful clients)