Details the Cancel an Appointment interaction

Use case

A consuming system wishes to cancel an Appointment which was previously booked.

Security

  • Utilises a JSON Web Token (JWT) to transmit Consumer system identity and authorisation details.
  • Is routed through the SSP (Spine secure Proxy)
  • Utilises TLS Mutual Authentication for system level authentication.

Request

The request body is sent using an http PUT method.

The body is a valid Appointment resource which conforms to the relevant profile. NB The appointment resource **MUST be retrieved from the Provider system in order to ensure that no data is lost.**, for full details of the payload body, see the Appointment resource details.

  • Provider systems SHOULD store previous versions of the resource to defend against any such loss of data.
  • Provider systems SHOULD reject cancellation requests where differences (other than those specified) are detected between the original and updated resource.

Response

Success

Where the request succeeded, the response MUST include a status of 200 OK. The response MUST include a Location header giving the absolute URL of the created Appointment. This URL MUST remain stable, and the resource SHOULD support RESTful updates using a PUT request to this URL. The response body MUST include the updated Appointment, this resource MUST include the newly assigned id of the resource.

Failure

  • If the request fails because of a business rule (for example if differences are detected between the existing and updated Appointment), the response MUST include a status of 422 Unprocessable Entity as described here. This SHOULD be accompanied by an OperationOutcome resource providing additional detail.
  • If the request fails because the request body failed validation against the relevant profiles, the response MUST include a status of 422 Unprocessable Entity as described here. This SHOULD be accompanied by an OperationOutcome resource providing additional detail.

  • If the request fails because either no valid JWT is supplied or the supplied JWT failed validation, the response MUST include a status of 403 Forbidden. This SHOULD be accompanied by an OperationOutcome resource providing additional detail.

  • If the request fails because the request body was simply invalid, the response MUST include a status of 400 Bad Request.
  • If the request fails because of a server error, the response MUST include a status of 500 Internal Server Error.

Failure responses with a 4xx status SHOULD NOT be retried without taking steps to address the underlying cause of the failure.

Failure responses with a 500 status MAY be retried.