NHS Digital Message API

openapi: 3.2.0
info:
  description: This API forms part of the Booking and Referral Standard (BaRS).
  version: 1.0.0
  title: Booking and Referral Message API
  termsOfService: https://developer.nhs.uk/apis/uec-appointments
  contact:
    email: uec.appointmentbooking@nhs.net
    url: https://developer.nhs.uk/apis/uec-appointments
    name: NHS Digital
  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
servers:
- url: https://sandbox.api.service.nhs.uk/booking-and-referral/FHIR/R4
  description: Sandbox Server
- url: https://int.api.service.nhs.uk/booking-and-referral/FHIR/R4
  description: Production
- url: https://api.service.nhs.uk/booking-and-referral/FHIR/R4
  description: Integration Server
security:
- OAuth_Token: []
tags:
- name: Message
paths:
  /$process-message:
    parameters:
    - $ref: '#/components/parameters/TargetIdentifier_HParam'
    - $ref: '#/components/parameters/RequestId_HParam'
    - $ref: '#/components/parameters/CorrelationId_HParam'
    - $ref: '#/components/parameters/RequestingOrganisation_HParam'
    - $ref: '#/components/parameters/RequestingPractitioner_HParam'
    - $ref: '#/components/parameters/RequestingDevice_HParam'
    - $ref: '#/components/parameters/Accept_HParam'
    - $ref: '#/components/parameters/use-context_HParam'
    post:
      tags:
      - Message
      summary: Process a message
      description: '### Using $process-message

        The inherent flexibility of the various workflows supported by BaRS is facilitated by the $process-message endpoint. The example in the "Try this API" feature for this endpoint is a referral request.


        ### Function

        | Function| API Call|Description

        | ---- | ---- | ---- |

        | Making a referral request | POST /$process-message | The sender will POST a FHIR Bundle, including the FHIR resources defined in MessageDefinition requested previously, the ''focus'' being a ServiceRequest resource, supported by Encounter, Observation, Flag etc. The MessageHeader resource will indicate the activity required through use of ''event'', ''reason'' and ''focus'' data elements. The MessageHeader resource will indicate the activity required. An example of this can be found here.|

        | Respond to a referral | POST /$process-message | A receiver wanting to respond to a request will direct their response to the Sender''s $process-message endpoint, reversing the previous request/response roles. All implementers (senders or receivers) of BaRS must build a $process-message endpoint to be able to support the asynchronous workflows which involve such feedback responses. An example of this can be found here.|

        | Cancelling a referral | POST /$process-message | An updated payload request ensuring the status of the service request is set to ''revoked'', as a minimum.An example of this can be found here.|

        | Making a booking | POST /$process-message | Once a slot has been identified, the sender makes a request to book through the $process-message endpoint. The receivers MessageDefinition defines the required FHIR resources and must including reference to the service request, if applicable. The MessageHeader resource will indicate the activity required.An example of this can be found here.|

        | Respond to a booking | POST /$process-message | A sender may receive a response to a booking they''ve made, for example, where a patient fails to attend. The original receiver (now the sender, in effect) will respond to the original sender (now the receiver) with an updated payload to reflect the current state of the booking e.g. DNA.|

        | Cancelling a booking (and rebook) | POST /$process-message | An updated payload request ensuring the status of the appointment is set to ''cancelled'', as a minimum.|


        for more information on processing requests, please see the guidance within our End-to-End Workflow documentation.'
      operationId: processMessage
      requestBody:
        description: Message Details
        required: true
        content:
          application/fhir+json:
            schema:
              $ref: '#/components/schemas/MessageBundle'
            example:
              $ref: examples/process_message/POST-body.json
          application/fhir+xml:
            schema:
              $ref: '#/components/schemas/MessageBundle'
      responses:
        '200':
          description: Success
          content:
            application/fhir+json:
              schema:
                $ref: '#/components/schemas/MessageBundle'
              example:
                $ref: examples/process_message/POST-success.json
            application/fhir+xml:
              schema:
                $ref: '#/components/schemas/MessageBundle'
          headers:
            X-Correlation-Id:
              description: The X-Correlation-Id from the request header, if supplied, mirrored back.
              schema:
                type: string
                format: uuid
                example: 9562466f-c982-4bd5-bb0e-255e9f5e6689
            X-Request-Id:
              description: The X-Request-Id from the request header, if supplied, mirrored back.
              schema:
                type: string
                format: uuid
                example: c1ab3fba-6bae-4ba4-b257-5a87c44d4a91
        4XX:
          $ref: '#/components/responses/4XX-BARS'
        5XX:
          $ref: '#/components/responses/5XX-BARS'
components:
  parameters:
    CorrelationId_HParam:
      name: X-Correlation-Id
      description: The X-Correlation-Id for the request header, when supplied, mirrored back by the receiver.
      required: true
      in: header
      schema:
        type: string
        format: uuid
        example: 9562466f-c982-4bd5-bb0e-255e9f5e6689
    RequestingOrganisation_HParam:
      name: NHSD-End-User-Organisation
      description: "Requesting Organization described in an object based on a FHIR 'Organization' resource (Standard Base64 encoded JSON).\nDifferent BaRS Applications may have different standards and requirements for the Access Control which these headers are used for. \nIn the example given an ODS code and the Organisation name is provided. Other identifiers are permitted if required. \n"
      required: true
      in: header
      schema:
        $ref: '#/components/schemas/RequestingOrganisationToken'
    Accept_HParam:
      name: Accept
      description: The Accept Header must also contain the version of the API required.
      in: header
      required: true
      schema:
        type: string
        example: "'application/fhir+json; version=1.0.0'        \n"
    RequestingPractitioner_HParam:
      name: NHSD-Requesting-Practitioner
      description: 'Requesting Practitioner described in an object based on a FHIR ''PractitionerRole'' resource (Standard Base64 encoded JSON).


        This item is not mandatory, however if the information is available it must be included in the request. Only in the event that it is not available, should it be omitted.


        The example given shows a General Practitioner and their SDS Role profile Id.

        '
      required: false
      in: header
      schema:
        $ref: '#/components/schemas/RequestingPractitionerToken'
    RequestingDevice_HParam:
      name: NHSD-Requesting-Software
      description: "Requesting Software described in an object based on a FHIR 'Device' resource (Standard Base64 encoded JSON).\nDifferent BaRS Applications may have different standards and requirements for the Access Control which these headers are used for. \n\nThe identifier used, though arbitrary, should be consistent across instances of a product, the name and version of the product should also be accurate and consistent.\n"
      required: true
      in: header
      schema:
        $ref: '#/components/schemas/RequestingSoftwareToken'
    RequestId_HParam:
      name: X-Request-Id
      description: The X-Request-Id for the request header, when supplied, mirrored back by the receiver.
      required: true
      in: header
      schema:
        type: string
        format: uuid
        example: c1ab3fba-6bae-4ba4-b257-5a87c44d4a91
    use-context_HParam:
      name: use-context
      description: This header is for usage statistics for the BaRS Proxy for NHS England.
      in: header
      required: true
      schema:
        type: string
        example: "a4t2|validation|servicerequest-response|new  \n"
    TargetIdentifier_HParam:
      name: NHSD-Target-Identifier
      description: The identifier of the Target system. A Base64 encoded object containing value and system properties.
      required: true
      in: header
      schema:
        $ref: '#/components/schemas/TargetIdentifier'
  responses:
    5XX-BARS:
      description: "Below are examples of potential HTTP status codes and their associated error codes, which could be returned in the event of a fault. \nGuidance on error handling within BaRS can be found [here](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Design/Design--Core#Error-handling).\n\n| HTTP status | Error code                 | Description |\n| ----------- | -------------------------- | --------------------------------------------- |\n| 500         | REC_SERVER_ERROR           | The receiver server has encountered an Error processing the request. |\n| 500         | PROXY_SERVER_ERROR         | Proxy Error. |\n| 501         | SEND_NOT_IMPLEMENTED       | The Request was not recognized. |\n| 501         | REC_NOT_IMPLEMENTED        | The Receiver did not recognize the request. |\n| 501         | PROXY_NOT_IMPLEMENTED      | The Proxy did not recognize the request. |\n| 503         | REC_UNAVAILABLE            | The Receiver was unavailable to service the request.|\n| 503         | PROXY_UNAVAILABLE          | The Proxy was unavailable to service the request. |\n"
      content:
        application/fhir+json:
          schema:
            $ref: '#/components/schemas/OperationalOutcome'
          example:
            $ref: examples/500-REC.json
      headers:
        X-Correlation-Id:
          description: The X-Correlation-Id from the request header, if supplied, mirrored back.
          schema:
            type: string
            format: uuid
            example: 9562466f-c982-4bd5-bb0e-255e9f5e6689
        X-Request-Id:
          description: The X-Request-Id from the request header, if supplied, mirrored back.
          schema:
            type: string
            format: uuid
            example: c1ab3fba-6bae-4ba4-b257-5a87c44d4a91
    4XX-BARS:
      description: "Below are examples of potential HTTP status codes and their associated error codes, which could be returned in the event of a fault. \nGuidance on error handling within BaRS can be found [here](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Design/Design--Core#Error-handling).\n\n| HTTP status | Error code                 | Description |\n| ----------- | -------------------------- | --------------------------------------------- |\n| 400         | SEND_BAD_REQUEST           | The API was unable to process the request. |\n| 400         | REC_BAD_REQUEST            | The Receiver has responded stating the message was malformed. |\n| 401         | SEND_UNAUTHORIZED          | The API deemed you unauthorized to make this request. |\n| 401         | REC_UNAUTHORIZED           | The receiver deemed you unauthorized to make request. |\n| 403         | SEND_FORBIDDEN             | Missing or Expired Token. |\n| 404         | PROXY_NOT_FOUND            | No related people exist for given NHS number. |\n| 404         | REC_NOT_FOUND              | Patient record for given NHS number has been invalidated and not superseded by another NHS number. |\n| 405         | SEND_METHOD_NOT_ALLOWED    | HTTP Verb is not correct for this scenario.|\n| 405         | REC_METHOD_NOT_ALLOWED     | Receiver does not allow this.|\n| 405         | PROXY_METHOD_NOT_ALLOWED   | Proxy does not allow this.|\n| 406         | SEND_NOT_ACCEPTABLE        | Senders message had an incorrect content type defined for a response.|\n| 408         | REC_TIMEOUT                | The downstream domain processing has not completed within the configured timeout period. |\n| 409         | SEND_CONFLICT              |  |\n| 409         | REC_CONFLICT               |  |\n| 409         | PROXY_CONFLICT             |  |\n| 422         | SEND_UNPROCESSABLE_ENTITY  | Message was not malformed but deemed unprocessable. |\n| 422         | REC_UNPROCESSABLE_ENTITY   | Message was not malformed but deemed unprocessable. |         \n| 422         | PROXY_UNPROCESSABLE_ENTITY | Message was not malformed but deemed unprocessable. |         \n| 429         | SEND_TOO_MANY_REQUESTS     | The user has sent too many requests in a given amount of time|\n| 429         | REC_TOO_MANY_REQUESTS      | The user has sent too many requests in a given amount of time|\n"
      content:
        application/fhir+json:
          schema:
            $ref: '#/components/schemas/OperationalOutcome'
          example:
            $ref: examples/400-SEND.json
      headers:
        X-Correlation-Id:
          description: The X-Correlation-Id from the request header, if supplied, mirrored back.
          schema:
            type: string
            format: uuid
            example: 9562466f-c982-4bd5-bb0e-255e9f5e6689
        X-Request-Id:
          description: The X-Request-Id from the request header, if supplied, mirrored back.
          schema:
            type: string
            format: uuid
            example: c1ab3fba-6bae-4ba4-b257-5a87c44d4a91
  schemas:
    OperationalOutcome:
      $ref: schemas/OperationalOutcome.yaml
    MessageBundle:
      $ref: schemas/MessageBundle.yaml
    TargetIdentifier:
      $ref: schemas/TargetIdentifier.yaml
    RequestingPractitionerToken:
      $ref: schemas/RequestingPractitioner.yaml
    RequestingOrganisationToken:
      $ref: schemas/RequestingOrganisation.yaml
    RequestingSoftwareToken:
      $ref: schemas/RequestingSoftware.yaml
  securitySchemes:
    OAuth_Token:
      type: http
      scheme: bearer