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

• Narrative Content
• XML
• JSON
• TTL

OperationDefinition: SDHRHNZParticipateOperation

Official URL: https://fhir-ig.digital.health.nz/sdhr/OperationDefinition/SDHRHNZParticipateOperation				Version: 1.1.6
Active as of 2026-10-20				Computable Name: HNZParticipate

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:

• Parameters resource for total non-participation (patient choice) : This example shows a global opt-out using reason patient-choice.
• Parameters resource for total non-participation (patient deceased) : This example shows a global opt-out using reason patient-deceased.
• Parameters resource for total non-participation (imported external consent) : This example shows a global opt-out using reason imported-external-consent.
• Parameters resource for participation : This example shows how to indicate that a patient wishes to participate in the Shared Digital Health Record service.
• Parameters resource for linked group participation : This example shows how to indicate that all patients in a linked NHI group wish 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. 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 records the global opt-out reason (hnzOptOutReasonCode) 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.