NZ Shared Digital Health Record API
1.0.1 - release

NZ Shared Digital Health Record API, published by Health New Zealand. This guide is not an authorized publication; it is the continuous build for version 1.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/tewhatuora/fhir-sdhr/ and changes regularly. See the Directory of published versions

## CapabilityStatement: NZ Shared Digital Health Record API

Official URL: https://fhir-ig.digital.health.nz/sdhr/CapabilityStatement/SDHRCapabilityStatement | Version: 1.0.1
Draft as of 2024-04-15 | Computable Name: SDHRCapabilityStatement

NZ Shared Digital Health Record API Capability Statement

Raw OpenAPI-Swagger Definition file | Download

Profile: Capability Statement profile for use with the Health New Zealand Te Whatu Ora OpenAPI spec converter

## NZ Shared Digital Health Record API

- Implementation Guide Version: 1.0.1
- FHIR Version: 4.0.1
- Supported Formats: `application/fhir+json`
- Published on: 2024-04-15 01:15:23+0000
- Published by: Health New Zealand

> 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`

### Request-Context custom header

All FHIR API requests MUST include the HNZ request context custom header which supplies identifiers for the health user and organisation, or system behind the API request.

This context is supplied using the 'Request-Context' custom HTTP header in the form of a base64-encoded JSON object. The value of the header has differing forms based on the type of request being made, namely whether it is in a user context (e.g. a clinical user searching for patient records), or a system context (e.g. a system submitting data to the API in a bulk load scenario).

#### Requests with user context

Context property | Mandatory | Value
--- | --- | ---
`userIdentifier` | Yes | The userid of the user as authenticated by the PMS/health application
`secondaryIdentifier` | Yes | The secondary identifier for the user - this MUST be the end users Common Person Number (aka HPI Practitioner identifier) of the practitioner using the application where available. Otherwise, any secondary identifier that is held for the user
`purposeOfUse` | Yes | One of [ "PATRQT", "TREAT", "ETREAT", "FAMRQT", "RECORDMGT" ]. For descriptions of the values, see Audit Events
`userFullName` | Yes | Full name of the user of the PMS/health application.
`userRole` | Yes | Role of the user of the PMS/health application. Set to `"PROV"` (Provider) or `"PAT"` (Patient)
`orgIdentifier` | Yes | The HPI Organisation Number (aka HPI Organisation identifier) for the organisation in which the API consumer application is deployed
`facilityIdentifier` | Yes | The HPI Facility identifier for the facility where the record is being sourced / accessed.

#### Requests with system context

Context property | Mandatory | Value
--- | --- | ---
`userIdentifier` | Yes | The oAuth clientId of the system submitting data to the API
`purposeOfUse` | Yes | [ "RECORDMGT" ]. For descriptions of the values, see Audit Events
`userFullName` | Yes | Name of the PMS/health application.
`userRole` | Yes | Role of the PMS/health application. Set to `"110150"` (Application)
`orgIdentifier` | Yes | The HPI Organisation Number (aka HPI Organisation identifier) for the organisation in which the API consumer application is deployed
`facilityIdentifier` | Yes | HPI identifier for the facility where the user is located

A schema definition and examples for `Request-Context` can be found here

#### Example Request-Context Header Payload for a clinical user searching for a patient's Conditions

Base64 Encoded

    ewogICJ1c2VySWRlbnRpZmllciI6ICJwbXMtaWQtMTIzIiwKICAidXNlclJvbGUiOiAiUFJPViIsCiAgInNlY29uZGFyeUlkZW50aWZpZXIiOiB7CiAgICAidXNlIjogIm9mZmljaWFsIiwKICAgICJzeXN0ZW0iOiAiaHR0cHM6Ly9zdGFuZGFyZHMuZGlnaXRhbC5oZWFsdGgubnovbnMvaHBpLXBlcnNvbi1pZCIsCiAgICAidmFsdWUiOiAiOTlaWlpTIgogIH0sCiAgInB1cnBvc2VPZlVzZSI6IFsKICAgICJQT1BITFRIIgogIF0sCiAgInVzZXJGdWxsTmFtZSI6ICJCZXZlcmx5IENydXNoZXIiLAogICJvcmdJZGVudGlmaWVyIjogIkcwMDAwMS1HIiwKICAiZmFjaWxpdHlJZGVudGlmaWVyIjogIkZaWjk5OS1CIgp9

Decoded JSON

    {
      "userIdentifier": "pms-id-123",
      "userRole": "PROV",
      "secondaryIdentifier": {
        "use": "official",
        "system": "https://standards.digital.health.nz/ns/hpi-person-id",
        "value": "99ZZZS"
      },
      "purposeOfUse": [
        "POPHLTH"
      ],
      "userFullName": "Beverly Crusher",
      "orgIdentifier": "G00001-G",
      "facilityIdentifier": "FZZ999-B"
    }

#### Example Request-Context Header Payload for a system submitting data to the API, where there is no end user

Base64 Encoded

    ewogICAgInVzZXJJZGVudGlmaWVyIjogIjFiODIwMGQ3LTNhOGMtNGZiNi04ZTVjLWNlYzQ1NDA5OTlkNSIsCiAgICAidXNlclJvbGUiOiAiMTEwMTUwIiwKICAgICJwdXJwb3NlT2ZVc2UiOiBbCiAgICAgICAgIlJFQ09SRE1HVCIKICAgIF0sCiAgICAidXNlckZ1bGxOYW1lIjogIlNhbXBsZSBQTVMgSW50ZWdyYXRpb24gQXBwbGljYXRpb24iLAogICAgIm9yZ0lkZW50aWZpZXIiOiAiRzAwMDAxLUciLAogICAgImZhY2lsaXR5SWRlbnRpZmllciI6ICJGWlo5OTktQiIKfQ==

Decoded JSON

    {
        "userIdentifier": "1b8200d7-3a8c-4fb6-8e5c-cec4540999d5",
        "userRole": "110150",
        "purposeOfUse": [
            "RECORDMGT"
        ],
        "userFullName": "Sample PMS Integration Application",
        "orgIdentifier": "G00001-G",
        "facilityIdentifier": "FZZ999-B"
    }

### Mandatory search parameters

All FHIR API search requests must include the HNZ mandatory search parameters. These are listed in the Combined Search Parameters section of each resource below.

### Error status codes

#### Read (GET) Operation Statuses

Code | Meaning | Description
--- | --- | ---
200 | OK | The request was successful, and the response body contains the representation requested
302 | FOUND | A common redirect response; you can GET the representation at the URI in the Location response header
304 | NOT MODIFIED | Your client's cached version of the representation is still up to date
400 | BAD REQUEST | Missing or bad `Request-Context` custom header; FHIR request payload does not validate against Implementation Guide
401 | UNAUTHORIZED | The supplied credentials, if any, are not sufficient to access the resource
403 | FORBIDDEN | Insufficient privilege to access the requested FHIR resource/operation
404 | NOT FOUND | The requested representation was not found. Retrying this request is unlikely to be successful
429 | TOO MANY REQUESTS | Your application is sending too many simultaneous requests
500 | SERVER ERROR | An internal server error prevented return of the representation response
503 | SERVICE UNAVAILABLE | We are temporarily unable to return the representation. Please wait and try again later

#### Search (GET) Operation Statuses

Code | Meaning | OperationOutcome in response? | Description
--- | --- | --- | ---
200 | OK | Yes, When there are additional messages about a match result | The request was successful, and the response body contains the representation requested
302 | FOUND | No | A common redirect response; you can GET the representation at the URI in the Location response header
400 | BAD REQUEST | Yes | Missing or bad `Request-Context` custom header;<br>FHIR request payload does not validate against Implementation Guide
401 | UNAUTHORIZED | Yes | The supplied credentials, if any, are not sufficient to access the resource
403 | FORBIDDEN | Yes | Insufficient privilege to access the requested FHIR resource/operation. See OperationOutcome-APIError-Unauthorised
429 | TOO MANY REQUESTS | No | Your application is sending too many simultaneous requests
500 | SERVER ERROR | No | An internal server error prevented return of the representation response
503 | SERVICE UNAVAILABLE | No | The server is temporarily unable to return the representation. Please wait and try again later

#### Update or Create (POST or PUT) Operation Statuses

Code | Meaning | OperationOutcome in response? | Description
--- | --- | --- | ---
200 | OK | Yes, When there are additional messages about an operation | The request was successful, and the response body contains the representation requested
201 | CREATED | No | The request was successful, and the response body contains the representation created
400 | BAD REQUEST | Yes | Missing or bad `Request-Context` custom header;<br>FHIR request payload does not validate against Implementation Guide
401 | UNAUTHORIZED | Yes | The supplied credentials, if any, are not sufficient to access the resource
403 | FORBIDDEN | Yes | Insufficient privilege to access the requested FHIR resource/operation. See OperationOutcome-APIError-Unauthorised
429 | TOO MANY REQUESTS | Yes | Your application is sending too many simultaneous requests
500 | SERVER ERROR | Yes | An internal server error prevented return of the representation response
503 | SERVICE UNAVAILABLE | No | The server is temporarily unable to return the representation. Please wait and try again later

### Non existent API endpoints

When a consumer attempts to call a non-existent API end point, respond with a 501 Not Implemented status code.

### API Rate Limits

API rate limiting is enforced on a per client basis, and the status of the rate limit is communicated via the following HTTP response headers:

Header name | Description
--- | ---
x-ratelimit-remaining | The amount of available quota
x-ratelimit-limit | The maximum available requests per window
x-ratelimit-reset | The remaining time, in milliseconds, until a new window starts

The API client MUST monitor these headers and ensure that they do not exceed the quota expressed in the `x-ratelimit-limit` header before the time window expressed in `x-ratelimit-reset`. If the rate limit is exceeded, the API will respond with a 429 Too Many Requests status code and the Rate Limit OperationOutcome.

Usage plan | Rate limits
--- | ---
SDHR Gold | 400 requests per second, per client
SDHR Silver | 50 requests per second, per client
SDHR Bronze | 10 requests per second, per client

Where the rate limit is exceeded as part of normal operations, the API client can request an increased quota by contacting the SDHR service desk portal.

Security
Enable CORS: yes
Security services supported: `SMART-on-FHIR`

> OAuth 2.0 - Client Credential flow.

Summary of System-wide Interactions

- Supports the `search-system`interaction.
- Supports the `transaction`interaction.
- Supports the `batch`interaction.

Summary of System-wide Operations

Conformance | Operation | Documentation
--- | --- | ---
SHALL | $participate | This operation allows a patient to choose to participate in the Shared Digital Health Record service. This operation should be used by data providers in the Shared Digital Health Record ecosystem such as Patient Management Systems (PMS) or Electronic Health Record (EHR) systems. It can be used to indicate whether the patient wishes to participate, whether any resources are withheld, and the reason for participation. The scope of this operation is the API consumer - e.g. an HPI Facility where patient data is held. Scenarios where this operation might be used include: A patient has opted in to the Shared Digital Health Record service and appropriate data will be shared from the data holder to the service. A patient chooses not to participate in the Shared Digital Health Record service and informs their healthcare provider of this choice. A patient has one or more confidential records, held at their healthcare provider, that are withheld from the service. A patient has previously withheld records but has now released them to the Shared Digital Health Record service. For example payloads that might be used with this operation see: Parameters resource for total non-participation : This example shows how to indicate that a patient does not wish to participate in the Shared Digital Health Record service (has opted out). Parameters resource for participation : This example shows how to indicate that a patient wishes to participate in the Shared Digital Health Record service, where previously opted out (opt-in). Parameters resource for partial participation with withheld records : This example shows how to indicate that a patient has some confidential records that are withheld from the Shared Digital Health Record service. Parameters resource for releasing withheld records : This example shows how to indicate that a patient has previously withheld records but has now released them to the Shared Digital Health Record service. To make a request to this operation the API Consumer must POST a `Parameters` payload to the operation URL (e.g. `POST https://api.sdhr.digital.health.nz/s2s/$participate`). The operation is idempotent, meaning that multiple requests with the same parameters will have the same effect as a single request. The operation is expected to be called by a healthcare provider on behalf of the patient, and the patient must be identified by their NHI. The operation will return an OperationOutcome resource indicating the result of the operation.
SHALL | $hnz-participate | This operation allows a patient to choose to participate in the Shared Digital Health Record service via HNZ assisted channels. This operation should only be used by HNZ channels. Scenarios where this operation might be used include: A patient has opted in to the Shared Digital Health Record service by contacting Health NZ via appropriate digital or assisted channels. A patient chooses not to participate in the Shared Digital Health Record service and informs Health NZ of this choice via appropriate digital or assisted channels. For example payloads that might be used with this operation see: Parameters resource for total non-participation : This example shows how to indicate that a patient does not wish to participate in the Shared Digital Health Record service (has opted out). Parameters resource for participation : This example shows how to indicate that a patient wishes to participate in the Shared Digital Health Record service. To make a request to this operation the API Consumer must POST a `Parameters` payload to the operation URL (e.g. `POST https://api.sdhr.digital.health.nz/s2s/$hnz-participate`). The operation is idempotent, meaning that multiple requests with the same parameters will have the same effect as a single request. The operation is expected to be called by a Health NZ channel system on behalf of the patient, and the patient must be identified by their NHI. The operation will return an OperationOutcome resource indicating the result of the operation.

### 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 Type | Profile | R | S | U | C | D | Searches | `_include` | `_revinclude` | Operations
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
AllergyIntolerance | https://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRAllergyIntolerance | y | y | y | y | y | patient, category, clinical-status, code, identifier, recorder, severity, clientlastupdated, _lastUpdated, patient |  |  |
Condition | https://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRCondition | y | y | y | y | y | patient, category, code, encounter, identifier, onset-date, severity, subject, highlighted, long-term-condition, clientlastupdated, _lastUpdated, patient | `Condition:encounter` |  |
Observation | https://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRObservation | y | y | y | y | y | patient, category, code, date, encounter, identifier, performer, status, subject, value-concept, value-date, value-quantity, value-string, clientlastupdated, _lastUpdated, patient |  |  |
Immunization | https://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRImmunization | y | y |  |  |  | patient, patient |  |  |

#### Resource Conformance: unspecifiedAllergyIntolerance

Base System Profile
SDHRAllergyIntolerance
Profile Conformance
SHALL
Reference Policy

Interaction summary

- Supports `read`, `create`, `update`, `search-type`, `delete`.

Documentation

> Note that the supported interactions of the API will vary per API Consumer, depending on the consuming system's role.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | MANDATORY Who the sensitivity is for Patient
SHALL | category | `token` | Must be one of food medication environment biologic AllergyIntolerance Category ValueSet
SHALL | clinical-status | `token` | Must be one of active inactive resolved AllergyIntolerance Clinical Status ValueSet
SHALL | code | `token` | Code that identifies the allergy or intolerance AllergyIntolerance Code ValueSet
SHALL | identifier | `token` | A unique identifier assigned to this resource.
SHALL | recorder | `reference` | Who recorded the sensitivity AllergyIntolerance.recorder
SHALL | severity | `token` | mild | moderate | severe (of event as a whole).
SHALL | clientlastupdated | `date` | The ClientLastUpdated extension value. This date parameter can also be used with `_sort=clientlastupdated` or `_sort=-clientlastupdated`.
SHALL | _lastUpdated | `date` | When the resource version last changed

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient | `reference`

#### Resource Conformance: unspecifiedCondition

Base System Profile
SDHRCondition
Profile Conformance
SHALL
Reference Policy

Interaction summary

- Supports `read`, `create`, `update`, `search-type`, `delete`.

Documentation

> Note that the supported interactions of the API will vary per API Consumer, depending on the consuming system's role.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | MANDATORY Who has the condition?
SHALL | category | `token` | The category of the condition
SHALL | code | `token` | The code for the condition
SHALL | encounter | `reference` | Encounter associated with the condition
SHALL | identifier | `token` | A unique identifier assigned to this resource.
SHALL | onset-date | `date` | Date the condition started
SHALL | severity | `token` | The severity of the condition
SHALL | subject | `reference` | Who has the condition?
SHALL | highlighted | `token` | Search for conditions flagged as highlighted in the SDHRCondition profile
SHALL | long-term-condition | `token` | Search for conditions flagged as long term in the SDHRCondition profile
SHALL | clientlastupdated | `date` | The ClientLastUpdated extension value. This date parameter can also be used with `_sort=clientlastupdated` or `_sort=-clientlastupdated`.
SHALL | _lastUpdated | `date` | When the resource version last changed.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient | `reference`

#### Resource Conformance: unspecifiedObservation

Base System Profile
SDHRObservation
Profile Conformance
SHALL
Reference Policy

Interaction summary

- Supports `read`, `create`, `update`, `search-type`, `delete`.

Documentation

> Note that the supported interactions of the API will vary per API Consumer, depending on the consuming system's role.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | MANDATORY Who the observation is for Patient
SHALL | category | `token` | The classification of the type of observation
SHALL | code | `token` | Describes what was observed. Sometimes this is called the observation 'name'
SHALL | date | `date` | Observation.effective Obtained date/time. If the obtained element is a period, a date that falls in the period
SHALL | encounter | `reference` | The Encounter resource associated with the Observation.
SHALL | identifier | `token` | A unique identifier assigned to this resource.
SHALL | performer | `reference` | Who performed the observation
SHALL | status | `token` | The status of the observation
SHALL | subject | `reference` | The subject that the observation is about
SHALL | value-concept | `token` | The value of the observation, if the value is a CodeableConcept
SHALL | value-date | `date` | The value of the observation, if the value is a date or period of time
SHALL | value-quantity | `quantity` | The value of the observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)
SHALL | value-string | `string` | The value of the observation, if the value is a string, and also searches in CodeableConcept.text
SHALL | clientlastupdated | `date` | The ClientLastUpdated extension value. This date parameter can also be used with `_sort=clientlastupdated` or `_sort=-clientlastupdated`.
SHALL | _lastUpdated | `date` | When the resource version last changed.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient | `reference`

#### Resource Conformance: unspecifiedImmunization

Base System Profile
SDHRImmunization
Profile Conformance
SHALL
Reference Policy

Interaction summary

- Supports `read`, `search-type`.

Documentation

> Note that the supported interactions of the API will vary per API Consumer, depending on the consuming system's role.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | MANDATORY Who the immunization is for Patient

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient | `reference`