NZ Shared Digital Health Record API
1.1.6 - 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.1.6 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.1.6
Draft as of 2024-04-15 Computable Name: SDHRCapabilityStatement

NZ Shared Digital Health Record API Capability Statement

Raw OpenAPI-Swagger Definition file | Download

NZ Shared Digital Health Record API

  • Implementation Guide Version: 1.1.6
  • 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. Must be a JSON object with: use (one of usual, official, temp, secondary, old), system (must be https://standards.digital.health.nz/ns/hpi-person-id), and a non-empty value
purposeOfUse Yes Exactly one of [ "TREAT", "ETREAT" ]. 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)
orgIdentifier Yes The HPI Organisation Number for the organisation in which the API consumer application is deployed. Must match the format G[A-Z0-9]{5}-[A-Z] (e.g. G00001-G)
facilityIdentifier Yes The HPI Facility identifier for the facility where the record is being sourced / accessed. Must match the format F[A-Z0-9]{5}-[A-Z] (e.g. FZZ999-B)
Requests with system context
Context property Mandatory Value
userIdentifier Yes The oAuth clientId of the system submitting data to the API
secondaryIdentifier No (forbidden) Must not be included in system-context requests
purposeOfUse Yes Must be exactly [ "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 for the organisation in which the API consumer application is deployed. Must match the format G[A-Z0-9]{5}-[A-Z] (e.g. G00001-G)
facilityIdentifier Yes The HPI Facility identifier for the facility. Must match the format F[A-Z0-9]{5}-[A-Z] (e.g. FZZ999-B)

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

ewogICJ1c2VySWRlbnRpZmllciI6ICJwbXMtaWQtMTIzIiwKICAidXNlclJvbGUiOiAiUFJPViIsCiAgInNlY29uZGFyeUlkZW50aWZpZXIiOiB7CiAgICAidXNlIjogIm9mZmljaWFsIiwKICAgICJzeXN0ZW0iOiAiaHR0cHM6Ly9zdGFuZGFyZHMuZGlnaXRhbC5oZWFsdGgubnovbnMvaHBpLXBlcnNvbi1pZCIsCiAgICAidmFsdWUiOiAiOTlaWlpTIgogIH0sCiAgInB1cnBvc2VPZlVzZSI6IFsKICAgICJUUkVBVCIKICBdLAogICJ1c2VyRnVsbE5hbWUiOiAiQmV2ZXJseSBDcnVzaGVyIiwKICAib3JnSWRlbnRpZmllciI6ICJHMDAwMDEtRyIsCiAgImZhY2lsaXR5SWRlbnRpZmllciI6ICJGWlo5OTktQiIKfQ==

Decoded JSON

{
  "userIdentifier": "pms-id-123",
  "userRole": "PROV",
  "secondaryIdentifier": {
    "use": "official",
    "system": "https://standards.digital.health.nz/ns/hpi-person-id",
    "value": "99ZZZS"
  },
  "purposeOfUse": [
    "TREAT"
  ],
  "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 or participation denial. See global denial and global denial due to patient-deceased opt-out.
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 or participation denial. See OperationOutcome-APIError-Unauthorised, global denial, and global denial due to patient-deceased opt-out.
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
404 NOT FOUND Yes The update target does not exist. Updating a missing resource does not create it
409 CONFLICT Yes A concurrent write or resource lock prevented the operation
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-systeminteraction.
  • Supports the transactioninteraction.
  • Supports the batchinteraction.
Summary of System-wide Operations
ConformanceOperationDocumentation
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:

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. When participationIndicator is false, SDHR records the facility opt-out and archives the patient's active contributed resources from the supplied facility. Archived resources are not returned by normal search or read interactions. For an opt-in request using pull-based acquisition, the PMS may set enrolledPatient to true to indicate that the patient is enrolled at the supplied facility and that a historic load should be triggered. If enrolledPatient is omitted, the API updates consent without triggering a historic load. When a historic load is scheduled, the returned OperationOutcome includes the informational sdhr-historic-load-scheduled issue. This confirms scheduling, not successful completion. The issue is absent when no load is scheduled, including an unchanged repeated request. See historic-load scheduling outcome. 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 linked group of patients 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:

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. For a global opt-in request, one or more patient parameters may be supplied. Multiple patient parameters are only supported when all supplied NHIs are already linked in the same NHI group and the request supplies the complete linked group. Multiple patient parameters are not supported for global opt-out requests. When hnzParticipationIndicator is false, SDHR requires hnzOptOutReasonCode, records the global opt-out reason, and archives the patient's active contributed resources across all facilities. Archived resources are not returned by normal search or read interactions. When the recorded reason is patient-deceased, subsequent resource read or search requests rejected by the global consent check return HTTP 403 with the deceased global-denial OperationOutcome: "Patient data is unavailable in the Shared Digital Health Record as they are deceased." This is not the response to a successful $hnz-participate request; see global participation denial API behaviour. For a global opt-in request where the patient is enrolled with a provider, the request may include the enrolled provider facilityId and must then include pmsIdentifier. Sourcing from this facility requires the patient to be already opted in at that facility. If the facility preference is absent or opted out, global opt-in still succeeds without sourcing records, changing facility participation, or locking that facility. When sourcing is eligible, a historic load is scheduled only for pull-based acquisition. Other acquisition methods use an enrolment-data email instead. If facilityId is omitted, pmsIdentifier must also be omitted and no historic load is scheduled. When a historic load is scheduled, the returned OperationOutcome includes the informational sdhr-historic-load-scheduled issue. This confirms scheduling, not successful completion. The issue is absent when no load is scheduled, including an unchanged repeated request. See historic-load scheduling outcome. The operation will return an OperationOutcome resource indicating the result of the operation.

SHALL$hnz-domain-participate

Records one or more domain choices on exactly one patient's Consent through authorised Health NZ channels. Supply one patient and one domains parameter with named boolean parts. Linked Consents are unchanged; any linked domain deny blocks access for the group. Global participation remains managed through $hnz-participate.

SHALL$hnz-participation-status

This operation retrieves a patient's Shared Digital Health Record participation status. 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 returns whether the patient is participating in the service, the global opt-out reason when applicable, whether enrolment information was found, and whether the patient has active, archived, or any records available in the service. The scope of the status returned is the API consumer, for example an HPI Facility where patient data is held.

This operation requires the SMART on FHIR scope https://fhir-ig.digital.health.nz/sdhr/OperationDefinition/SDHRHNZParticipationStatusOperation.

For an example response payload for this operation see:

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-participation-status).

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 a Parameters resource containing the patient reference and participation status indicators.

SHALL$participation-status

This operation allows Shared Electronic Health Record (SEHR) systems to retrieve a patient's Shared Digital Health Record participation status.

For an example response payload for this operation see:

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/$participation-status).

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. This operation requires the SMART on FHIR scope https://fhir-ig.digital.health.nz/sdhr/OperationDefinition/SDHRParticipationStatusOperation. The operation returns a Parameters resource containing only hnzParticipationIndicator. A patient with no recorded global participation preference is considered to be participating and returns true.

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 TypeProfileRSUCDSearches_include_revincludeOperations
AllergyIntolerancehttps://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRAllergyIntoleranceyyyyypatient, category, clinical-status, code, identifier, recorder, severity, clientlastupdated, _lastUpdated, patient
Conditionhttps://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRConditionyyyyypatient, category, code, encounter, identifier, onset-date, severity, subject, highlighted, long-term-condition, clientlastupdated, _lastUpdated, patientCondition:encounter
AuditEventhttps://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRAuditEvent
Additional supported profiles:
  SDHRAuditEvent		$verification-samples, $verification-submissions
Observationhttps://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRObservationyyyyypatient, category, code, date, encounter, identifier, performer, status, subject, value-concept, value-date, value-quantity, value-string, clientlastupdated, _lastUpdated, patient
Immunizationhttps://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRImmunizationyypatient, date, location, vaccine-code, target-disease, status, status-reason, product, _sort, patient
MedicationRequesthttps://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRMedicationRequestyypatient, identifier, status, code, location, _count, ct, authoredon, _sort, _revinclude, patientMedicationDispense:prescription
MedicationDispensehttps://fhir-ig.digital.health.nz/sdhr/StructureDefinition/SDHRMedicationDispenseyypatient, identifier, status, code, location, _count, ct, whenprepared, whenhandedover, _sort, _include, patientMedicationDispense:prescription
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
ConformanceParameterTypeDocumentation
SHALLpatientreference

MANDATORY Who the sensitivity is for Patient

SHALLcategorytoken

Must be one of

SHALLclinical-statustoken

Must be one of

SHALLcodetoken

Code that identifies the allergy or intolerance AllergyIntolerance Code ValueSet

SHALLidentifiertoken

A unique identifier assigned to this resource.

SHALLrecorderreference

Who recorded the sensitivity AllergyIntolerance.recorder

SHALLseveritytoken

mild | moderate | severe (of event as a whole).

SHALLclientlastupdateddate

The ClientLastUpdated extension value. This date parameter can also be used with _sort=clientlastupdated or _sort=-clientlastupdated.

SHALL_lastUpdateddate

When the resource version last changed

Combined Search Parameters
ConformanceParametersTypes
SHALLpatientreference
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
ConformanceParameterTypeDocumentation
SHALLpatientreference

MANDATORY Who has the condition?

SHALLcategorytoken

The category of the condition

SHALLcodetoken

The code for the condition

SHALLencounterreference

Encounter associated with the condition

SHALLidentifiertoken

A unique identifier assigned to this resource.

SHALLonset-datedate

Date the condition started

SHALLseveritytoken

The severity of the condition

SHALLsubjectreference

Who has the condition?

SHALLhighlightedtoken

Search for conditions flagged as highlighted in the SDHRCondition profile

SHALLlong-term-conditiontoken

Search for conditions flagged as long term in the SDHRCondition profile

SHALLclientlastupdateddate

The ClientLastUpdated extension value. This date parameter can also be used with _sort=clientlastupdated or _sort=-clientlastupdated.

SHALL_lastUpdateddate

When the resource version last changed.

Combined Search Parameters
ConformanceParametersTypes
SHALLpatientreference
Base System Profile
SDHRAuditEvent
Profile Conformance
SHALL
Reference Policy

Supported Profiles

SDHRAuditEvent

Interaction summary

    Documentation

    AuditEvent supports DRAFT custom operations for data viewer application verification workflows.

    Extended Operations
    ConformanceOperationDocumentation
    SHALL$verification-samples

    Returns sampled AuditEvent resources that are still outstanding for verification by the authenticated data viewer application. Successful requests return a searchset Bundle, which may be empty. Supports optional _count and _getpagesoffset query parameters for paging. Generic AuditEvent interactions are not supported.

    SHALL$verification-submissions

    DRAFT OPERATION: Accepts a Parameters payload containing one or more verification decisions for sampled AuditEvent resources.

    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
    ConformanceParameterTypeDocumentation
    SHALLpatientreference

    MANDATORY Who the observation is for Patient

    SHALLcategorytoken

    The classification of the type of observation

    SHALLcodetoken

    Describes what was observed. Sometimes this is called the observation 'name'

    SHALLdatedate

    Observation.effective Obtained date/time. If the obtained element is a period, a date that falls in the period

    SHALLencounterreference

    The Encounter resource associated with the Observation.

    SHALLidentifiertoken

    A unique identifier assigned to this resource.

    SHALLperformerreference

    Who performed the observation

    SHALLstatustoken

    The status of the observation

    SHALLsubjectreference

    The subject that the observation is about

    SHALLvalue-concepttoken

    The value of the observation, if the value is a CodeableConcept

    SHALLvalue-datedate

    The value of the observation, if the value is a date or period of time

    SHALLvalue-quantityquantity

    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)

    SHALLvalue-stringstring

    The value of the observation, if the value is a string, and also searches in CodeableConcept.text

    SHALLclientlastupdateddate

    The ClientLastUpdated extension value. This date parameter can also be used with _sort=clientlastupdated or _sort=-clientlastupdated.

    SHALL_lastUpdateddate

    When the resource version last changed.

    Combined Search Parameters
    ConformanceParametersTypes
    SHALLpatientreference
    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
    ConformanceParameterTypeDocumentation
    SHALLpatientreference

    MANDATORY Who the immunization is for Patient

    SHALLdatedate

    Vaccination (occurrence) date. Comparators eq, ge, gt, le, lt are supported; two date parameters may be combined for a range.

    SHALLlocationreference

    Facility (HPI) where the vaccination was administered.

    SHALLvaccine-codetoken

    Vaccine product administered. Supports system|code or bare code, and the :text modifier for name search.

    SHALLtarget-diseasetoken

    Disease targeted by the vaccination (protocolApplied.targetDisease, SNOMED).

    SHALLstatustoken

    Immunisation event status. Records with status entered-in-error are excluded from search results.

    SHALLstatus-reasontoken

    Reason a vaccination was not administered.

    SHALLproducttoken

    Administered product from the AIR administered-product extension, distinct from vaccine-code. Supports system|code or bare code, and :text for case-insensitive substring matching against text or coding display.

    SHALL_sortstring

    Sort by occurrence date: date for ascending or -date for descending. Default: -date.

    Combined Search Parameters
    ConformanceParametersTypes
    SHALLpatientreference
    Base System Profile
    SDHRMedicationRequest
    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
    ConformanceParameterTypeDocumentation
    SHALLpatientreference

    MANDATORY Who the prescription is for Patient

    SHALLidentifiertoken

    NZePS prescription-item business identifier (SCID plus item sequence number). Dispenses for the same prescription item share this identifier; it is distinct from the MDR dispense resource id.

    SHALLstatustoken

    Status filter, limited to active, on-hold, completed and stopped. If no permitted status remains, the result is empty.

    SHALLcodetoken

    Medication code, forwarded unchanged to MDR for matching.

    SHALLlocationreference

    Facility search value, forwarded unchanged to MDR for matching.

    SHALL_countnumber

    Integer from 0 to 1000. With _count=0, the response contains Bundle.total and no medication entries. Otherwise Bundle.total is omitted.

    SHALLctstring

    Continuation token returned in the next-page URL in Bundle.link. Request that URL to retrieve the next page; it includes ct and the search parameters.

    SHALLauthoredondate

    Prescription date filter.

    SHALL_sortstring

    Sort by authoredon or -authoredon. Default: -authoredon. Invalid values, repeated parameters and multiple sort fields return HTTP 400.

    SHALL_revincludestring

    MANDATORY Supply MedicationDispense:prescription so prescriptions and dispenses can be assessed together for confidentiality and facility opt-outs. Missing or unsupported values return HTTP 400.

    Combined Search Parameters
    ConformanceParametersTypes
    SHALLpatientreference
    Base System Profile
    SDHRMedicationDispense
    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
    ConformanceParameterTypeDocumentation
    SHALLpatientreference

    MANDATORY Who the dispense is for Patient

    SHALLidentifiertoken

    NZePS prescription-item business identifier (SCID plus item sequence number). Dispenses for the same prescription item share this identifier; it is distinct from the MDR dispense resource id.

    SHALLstatustoken

    Status filter, limited to completed. If no permitted status remains, the result is empty.

    SHALLcodetoken

    Medication code, forwarded unchanged to MDR for matching.

    SHALLlocationreference

    Facility search value, forwarded unchanged to MDR for matching.

    SHALL_countnumber

    Integer from 0 to 1000. With _count=0, the response contains Bundle.total and no medication entries. Otherwise Bundle.total is omitted.

    SHALLctstring

    Continuation token returned in the next-page URL in Bundle.link. Request that URL to retrieve the next page; it includes ct and the search parameters.

    SHALLwhenprepareddate

    Dispense preparation date filter.

    SHALLwhenhandedoverdate

    Dispense handover date filter.

    SHALL_sortstring

    Sort by whenprepared or whenhandedover, optionally prefixed with - for descending order. Default: -whenprepared. Invalid values, repeated parameters and multiple sort fields return HTTP 400.

    SHALL_includestring

    MANDATORY Supply MedicationDispense:prescription so prescriptions and dispenses can be assessed together for confidentiality and facility opt-outs. Missing or unsupported values return HTTP 400.

    Combined Search Parameters
    ConformanceParametersTypes
    SHALLpatientreference