Aotearoa Immunisation Register (AIR) FHIR Implementation Guide
2.7.0 - ci-build New Zealand

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

CapabilityStatement: AIR FHIR Server Capability Statement

Official URL: https://standards.digital.health.nz/fhir/air/CapabilityStatement/AIRCapabilityStatement Version: 2.7.0
Draft as of 2023-02-14 Computable Name: AIRCapabilityStatement

The Aotearoa Immunisation Register (AIR) FHIR v4.0.1 API

Raw OpenAPI-Swagger Definition file | Download

AIR FHIR Server Capability Statement

  • Implementation Guide Version: 2.7.0
  • FHIR Version: 4.0.1
  • Supported Formats: json
  • Published on: 2023-02-14
  • Published by: Te Whatu Ora

Note to Implementers: FHIR Capabilities

Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

FHIR RESTful Capabilities

Mode: server

Security
Enable CORS: yes
Security services supported: OAuth
Summary of System-wide Interactions
  • Supports the transactioninteraction.
Summary of System-wide Operations
ConformanceOperationDocumentation
SHALL$process-message

POST| [base]/$process-message| http://hl7.org/fhir/OperationDefinition/MessageHeader-process-message| system/MessageHeader.u

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCH-ISearches_include_revincludeOperations
Immunizationhttps://standards.digital.health.nz/fhir/air/StructureDefinition/air-immunizationyyyypatient, protocolApplied.targetDisease, status-reason:not-in, status:not-in, data-quality*, Immunization.patient, Immunization.performer.actor, Immunization.location$upsert, $bulk-update
Patienthttps://standards.digital.health.nz/fhir/air/StructureDefinition/air-patienty$update-state, $reassign-schedules, $patient-history
Base System Profile
AIR Immunization
Profile Conformance
SHALL
Reference Policy

Interaction summary
  • Supports
    create

    POST|[base]/Immunization/|The "create" operation is used to create a new immunisation event. This method performs validation checks to ensure that the event is valid before it is created.

        Returns either the created Immunization record or if there were any issues with the create, the  response will contain an OperationOutcome resource array. The OperationOutcome resource has an informational issue indicating that the create operation failed. The issue array of the OperationOutcome resource would contain additional issues with appropriate severity and code values.|system/Immunization.c
    read

    GET|[base]/Immunization/[id]|The "read" operation is used to read an immunisation event. This method takes an immunisation event id and returns back the FHIR resource for the immunization event.|system/Immunization.r

    update

    PUT|[base]/Immunization/[id]| The "update" operation is used to update an existing immunisation event. This method checks if the immunisation event with the given ID exists, and if it does, it updates the event with the new details provided. The method also performs validation checks to ensure that the updated event is valid before it is saved.

        Returns either the the updated immunisation record or an OperationOutcome if there were any issues with the update.

    On success - returns the updated immunisation record. data quality issues will be identified and sent as part of the response in the meta section of the resource.

    On Fail - if there were any issues with the update, the response will contain an OperationOutcome resource array. The OperationOutcome resource has an informational issue indicating that the update operation failed. The issue array of the OperationOutcome resource would contain additional issues with appropriate severity and code values.|system/Immunization.u
    history-instance

    GET|[base]/Immunization/[id]_history|The _history interaction is used to return all the versions of an immunization event including the data quality. This method takes an immsot_id and returns back the FHIR bundle, which is a collection of immunization event resources where each resource in the bundle represents a version.|system/Immunization.r, air-admin/Immunization.r

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

NHI number of the patient

SHALLprotocolApplied.targetDiseasetoken

Vaccine-preventable disease being targeted by an immunisation.

SHALLstatus-reason:not-intoken

Exclude immunisation events with specified status reason codes

SHALLstatus:not-intoken

Exclude immunisation events with specified statuses

SHALLdata-qualityspecial

Query search for immunisation events with data quality issues. Restricted to admin users.

Combined Search Parameters
ConformanceParametersTypes
 patientreference
 patient(+protocolApplied.targetDisease+status-reason:not-in+status:not-in)reference(+token+token+token)
Extended Operations
ConformanceOperationDocumentation
SHALL$upsert

Update or add an immunisation event

SHALL$bulk-update

Update or add immunisation events in bulk.

Base System Profile
AIR Patient Profile
Profile Conformance
SHALL
Reference Policy

Interaction summary
  • Supports
    read

    GET|[base]/Patient/[id]|Read the current state of an ImmSOT Consumer. Consumer state held in ImmSOT is returned as a FHIR AIR Patient. When an optional header "origin-nhi-version" is included which contains the NHI version, the API will check if it is the same NHI version we have stored in ImmSoT database for the Consumer. If it is the same, we return the current data we have in ImmSoT database. If it is not the same, we do a Consumer sync with NHI and update the data we have in ImmSoT database and then return this updated data in the response.|system/Patient.r, air-test/Patient.r

Extended Operations
ConformanceOperationDocumentation
SHALL$update-state

Update the current state of an ImmSOT Consumer. Updates the Consumer state and/or sub status only. Input is the Consumer version previously read (used for operation optimistic locking) and the desired Consumer state. At least one of state and subStatus must be specified. If state or subStatus is not specified, then these attributes will not be updated. Setting subStatus to null will clear the current sub status. A 412 Preconditioned Failed will be returned if the version received in the payload does not match the server version.

SHALL$reassign-schedules

Reassign immunisation schedules for a patient. Cancels the existing schedules and then creates a new set of schedules based on the new onboarding date. Input is the new onboarding date.

SHALL$patient-history

Fetch all the versions of an ImmSOT Patient/Consumer.

FHIR Messaging Capabilities

Messaging Capability

Supported Message(s)

ModeDefinition
senderMessageDefinition[http://hl7.org.nz/fhir/MessageDefinition/UpdateImmunisationRequestMessageDefinition|2.7.0]
senderMessageDefinition[http://hl7.org.nz/fhir/MessageDefinition/UpdateImmunisationResponsetMessageDefinition|2.7.0]