This section describes the transaction needed for the cancellation of the notification.

Scope

Open

This transaction delivers a cancellation notification from the Sending GtK to the Receiving GtK based on the specified referral.

Use Case Roles

Actor: Sending GtK

Role: Sends Cancellation Notification Tasks on behalf of a referring user.

Actor: Receiving GtK

Role: Receives and processes Cancellation Notification Tasks

Referenced Standards

• HL7® FHIR® standard STU3 https://hl7.org/fhir/stu3

Messages

Request message

The Notification Cancellation request message is sent when the Sending GtK needs to send a cancellation of a previous Notification to the Receiving GtK. Just as the Notification message, the payload of this message consists of a FHIR® STU3 Task resource.

The Sending GtK can cancel a previous Notification using a conditional update interaction on the Task that represents that previous Notification. This is done by sending an HTTP PUT request to the Task endpoint of the Receiving GtK, where the value of Task.identifier of that previous Notification is included in the query parameters of the PUT request.

The media type of the HTTP body must be either application/fhir+json or application/fhir+xml.

When generating the Notification Cancellation message, the Sending GtK must set the Task attributes as specified in the table below. For complete information on constructing a FHIR® Task Resource, see https://hl7.org/fhir/stu3/task.html .

The Receiving GtK must accept both media types application/fhir+json and application/fhir+xml.

On receipt of the submission, the Receiving GtK must validate the resource and respond to the cancellation message according to the requirements specified in Notification response.

The Notification should trigger an event in the Receiving GtK to cancel any intended Pull interaction.

Persistence of the Notification Task as a FHIR® resource is not necessary.

Notification response

This message must be provided when a success or error condition needs to be communicated in response to an inbound Notification message. Success is only indicated once the Notification is received and completely processed.

To enable the Sending GtK to know the outcome of technical / syntactic processing of the Notification Task, the Receiving GtK must return either an empty body or an OperationOutcome resource. This body must be accompanied with the correct HTTP status code, e.g.:

• 200 OK – Notification received and not persisted.

• 201 Created – Notification received and persisted. In this case http-headers Location and Etag should be filled.

• 400 Bad Request – Notification could not be parsed or failed basic FHIR® validation rules.

• 404 Not Found – Resource type not supported, or wrong endpoint.

• 412 Precondition Failed – The processing of the Notification Task could not be finished, since the criteria were not selective enough.

• 422 Unprocessable Entity – The Notification Task resource violated applicable server business rules. This should be accompanied by an OperationOutcome resource providing additional detail.

Whether or not the resources in input can be retrieved shall not be a factor in the HTTP status.

The Sending GtK processes the response according to application defined rules.