Generated Narrative: CapabilityStatement SDHRCapabilityStatement 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.0 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", "POPHLTH", "TREAT", "ETREAT", "PUBHLTH", "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 [binary] 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 [binary] 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; 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; 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-systeminteraction. Supports the transactioninteraction. Supports the batchinteraction. 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, _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, _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, _lastUpdated, patient Resource Conformance: supported AllergyIntolerance 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 _lastUpdated date When the resource version last changed Combined Search Parameters Conformance Parameters Types SHALL patient reference Resource Conformance: supported Condition 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 _lastUpdated date When the resource version last changed. Combined Search Parameters Conformance Parameters Types SHALL patient reference Resource Conformance: supported Observation 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 _lastUpdated date When the resource version last changed. Combined Search Parameters Conformance Parameters Types SHALL patient reference
Health New Zealand Digital Services Hub API Access and Use Agreement
NZ Shared Digital Health Record API Capability Statement
Health NZ | Te Whatu Ora NZ Shared Digital Health Record API
### 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", "POPHLTH", "TREAT", "ETREAT", "PUBHLTH", "RECORDMGT" ]. For descriptions of the values, see [Audit Events](https://fhir-ig.digital.health.nz/auditevents/ValueSet-purposeofuse.html) | | `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](https://fhir-ig.digital.health.nz/auditevents/ValueSet-purposeofuse.html) | | `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](https://github.com/tewhatuora/schemas/blob/main/json-schema/Request-Context.json) #### Example Request-Context Header Payload for a clinical user searching for a patient's Conditions **Base64 Encoded** ``` [binary] ``` **Decoded JSON** ```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** ``` [binary] ``` **Decoded JSON** ```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; 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](./OperationOutcome-APIError-Unauthorised.html)| |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; 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](./OperationOutcome-APIError-Unauthorised.html)| |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](./OperationOutcome-OperationOutcomeRateLimitExceeded.json.html). | **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.
Note that the supported interactions of the API will vary per API Consumer, depending on the consuming system's role.
MANDATORY Who the sensitivity is for [Patient](http://hl7.org/fhir/R4/patient.html)
Must be one of * food * medication * environment * biologic [AllergyIntolerance Category ValueSet](http://hl7.org/fhir/ValueSet/allergy-intolerance-category)
Must be one of * active * inactive * resolved [AllergyIntolerance Clinical Status ValueSet](http://hl7.org/fhir/R4/valueset-allergyintolerance-clinical.html)
Code that identifies the allergy or intolerance [AllergyIntolerance Code ValueSet](http://hl7.org/fhir/ValueSet/allergyintolerance-code)
A unique identifier assigned to this resource.
Who recorded the sensitivity [AllergyIntolerance.recorder](http://hl7.org/fhir/R4/allergyintolerance-definitions.html#AllergyIntolerance.recorder)
mild | moderate | severe (of event as a whole).
Search for conditions flagged as highlighted in the SDHRCondition profile
Search for conditions flagged as long term in the SDHRCondition profile
**MANDATORY** Who the observation is for [Patient](http://hl7.org/fhir/R4/patient.html)
The classification of the type of observation
Describes what was observed. Sometimes this is called the observation 'name'
Observation.effective Obtained date/time. If the obtained element is a period, a date that falls in the period
The Encounter resource associated with the Observation.
The subject that the observation is about
The value of the observation, if the value is a CodeableConcept
The value of the observation, if the value is a date or period of time
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)
The value of the observation, if the value is a string, and also searches in CodeableConcept.text
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](./Parameters-ParametersDoNotParticipate.html) : 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](./Parameters-ParametersParticipate.html) : 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](./Parameters-ParametersParticipateRecordWithheld.html) : 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](./Parameters-ParametersParticipateRecordReleased.html) : 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.
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](./Parameters-ParametersHNZParticipateOptOut.html) : 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](./Parameters-ParametersHNZParticipateOptIn.html) : 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.