Scope and Requirements

Scope Overview

This BaRS Application (Application 1) covers only use cases:

• 111 (telephony) to ED
• 111 (telephony) to UTC
• IUC CAS to ED
• IUC CAS to UTC
• AST to ED (Pathways only)
• AST to UTC (Pathways only)
• 111 to SDEC
• CAS to SDEC
• AST to SDEC (Pathways only)

The payloads and workflow have been designed to support these services. Other BaRS Applications offer scope for alternative use cases.

Functional Scope

Service Discovery

• Establishing a service to direct requests to is a mandatory step in the workflow
• There is no restriction on the service discovery tools used. Any are capable of being supported whether national or proprietary
• The service must be configured within the BaRS infrastructure (Endpoint Catalogue) before requests can be made

Slot Management

• Booking slots are the responsibility and ownership of Receivers to maintain and offer to Senders
• All slot requests must occur in real-time without caching by either Senders or Receivers
• The returned slots should contain sufficient information for Senders to know what they are booking i.e. have a clear 'type', indicate the role and/or gender of the individual performing on behalf of the service, within any given slot

Booking

• Allowing bookings for a service is a method of managing capacity
• A booking may indicate the exact time an individual can expect to be seen by or is expected to arrive at the service, as is traditionally understood when an 'appointment' is made. Alternatively, the booking timeframe could indicate a range through which the individual may be seen by the service
• The slot the booking is made against may also indicate the type of booking e.g. face-to-face or over the phone and the role of the person who will engage with the individual on behalf of the service
• Bookings are an administrative aspect of the workflow and should not contain clinically pertinent information

Referral

• A referral is a request for care on behalf of an individual from one service to another
• The referral can be sent without having to establish the capacity the service offers
• The referral will contain primarily clinical information, indicating the need of the individual and should state the anticipated action required by the Receiving service
• A referral can be made independent of booking but, where a booking is made as part of the same workflow, they must be linked
• Supporting information, other than the assessment, is expected to be included in a referral, if collected, including:
  • new or existing safeguarding concerns
  • locally held Special Patient Notes
  • external information sources used during initial assessment prior to referral
  • list of any services rejected prior to the Receiving service being selected, including reason for rejection

API-M

• All requests and response associated with BaRS must occur through the BaRS API Proxy

Constraints

• Supporting use of NHS Pathways and NHS Pathways Clinical Content Support (PaCCS) Clinical Decision Support Systems only
• All Service IDs in First of Type (FoT) will be those of Urgent and Emergency Care (UEC) Directory of Services (DoS)
• DoS 'attributes' for controlling Booking into services are to remain honoured (see "how does it work" section below for more information)
• No guidance provided on display of referral information beyond the Principles for rendering BaRS Payload.
• No additional guidance provided on Slot display for Booking
• Consent within BaRS will be for Direct-Care only
• Certificates for Receiving messages to use nhs.uk domains only.
• Receiving endpoints are to be internet facing.
• Limited Search Slot parameters for Booking - Schedule.actor:healthcareService, Start (range), (slot) status
• Clincial Constraints exist - See Hazard Log
• No element level 'updates' to requests. A new request must be generated to change information in a booking or referral request

Requirements

Service Discovery

• The service must support a unique identifier which the Sender extracts to engage in booking and referral workflows

Slot display

• The schedule and related slot(s) must contain the actual geographic location (e.g address) of the booking, rather than generic details of the location of the overall service provider.
• The slot must contain details of the start/end times of the available slots
• The available slot(s) must be capable of being retrieved from any booking Receiver, regardless of the relationship that the sending user’s organisation has with the receiving service
• Where there are no available slots, the booking Receiver must send an appropriate response to indicate this not merely reply with an empty response
• Where there are no available slots, the booking Sender must present an appropriate message to the end user
• The booking Receiver must return available slots without requiring to know the potential patient details
• Where the booking Receiver has a number of schedules available to fulfil a request (say, when 2 or more clinicians are delivering surgeries at the same site) they must return all of those slots as part of the initial response
• If provided, in addition to Healthcare Service, Schedule and Slot, the booking Sender must display Delivery Channel and Practitioner Role, Name and Gender
• Booking Receivers must not default the Delivery Channel value
• A booking Sender must not assume a booking Receiver will return requested _includes e.g. Location
  • Booking Sender must handle a Slot response without non mandatory FHIR resources
  • Booking Sender must handle a Slot response with FHIR resources not requested

Booking

• The booking Receiver must accept the booking request regardless of whether the patient is known to the service provider
• The booking Receiver must accept potential patients who do not have a national validated identifier e.g. NHS Number.
• Where a national identifier is included, it must be 'traced and verified', otherwise, the referral Sender must not include the national indentifier in the request
• Where the booking was not successful, the Receiver must send an appropriate response. See failure scenarios for more detail.
• Where the booking was not successful, the Sender must present an appropriate message to the end user. See failure scenarios for more detail.
• If included in the synchronous HTTP response, the booking Sender must make available the human readable identifier for the booking to the end user
• The booking Sender must send accompanying clinical information in a BaRS referral request
  • The booking Sender must reference the booking in the BaRS referral request (where the booking is made first in the workflow)
  • The booking Receiver must link the explicitly related booking and referral requests
• Update to amend a booking request is not supported. If a booking Sender wishes to change information in a request they must follow the re-book workflow

Cancel booking

• The booking Sender must be capable of cancelling any booking made by them, within the current consultation or after the consultation event
• The booking Sender must retrieve the booking to be cancelled from the booking Receiver prior to cancellation to ensure they are working with the most up to date version and it has not already been completed
• The booking Sender must provide visible confirmation to the end user of the status returned by the booking Receiver, indicating whether the original booking was successfully cancelled or not
• If the cancellation fails the booking Receiver must respond with the most appropriately aligned error
• The booking Receiver must store all previous versions of the booking, including cancellations
• The booking Receiver must not be required to inform the patient of the cancellation of the booking.  Business/clinical responsibility for informing the patient must remain with the booking Sender
• Any referral, sent as part of a booking, should be decoupled from the booking when cancelled and not be assumed to be a referral in its own right i.e. to ensure 'booking only' services are appropriately updated

Rebook

• The booking Sender must be capable of rebooking within the current consultation or after the consultation event
• If a callback occurs after the consultation has been completed, prior to attempting a rebook the patient should be reassessed
• The booking Sender must cancel the original booking prior to making the new booking, whether within the current consultation or after the consultation event
• The booking Sender must provide visible confirmation to the end user of the status returned by the Receiver, indicating whether the original booking was successfully cancelled and the new booking made
• The booking Receiver must not be required to inform the patient of the cancellation, incurred as part of the rebooking process. Business/clinical responsibility for informing the patient must remain with the booking Sender
• The new booking must not link to any originally linked referral, rather a new referral must be made and the original 'revoked'

Booking outside assessment outcome timeframe

• The booking Sender must allow clinical users to book outside the assessment outcome timeframe
• The booking Sender must present a notification to non-clinical users and prompt to seek clinical approval to book outside the assessment outcome timeframe
• The booking Sender must store sufficient audit information to show where a patient has been booked outside their assessment outcome timeframe

Referral requires booking (Require-Booking services)

• The booking Sender must stop the end users from making a referral if no booking has been made when the “RequireBooking” service attribute is present against the DoS service
• The booking Sender must present an appropriate warning message to the end user, indicating the specific service requirements
• The booking Sender must allow the referral to be sent when a booking is made
• The end user must be allowed to select an alternative service, if they are unable to proceed with "RequireBooking" service

Referral

• The referral Receiver must accept the referral request regardless of whether the patient is known to the service provider
• The referral Receiver must accept potential patients who do not have a national validated identifier e.g. NHS Number.
• Where a national identifier is included, it must be 'traced and verified', otherwise, the referral Sender must not include in the request
• Any new or existing safeguarding concern, recorded as part of the assessment, must be included in the referral Sender's request
• The referral Receiver must clearly identify any included safeguarding concern to the end user
• The referral Receiver must accurately represent information made by the Sender to the end user
• The referral Sender must make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
• Where the referral was not successful, the Receiver must send an appropriate response. See failure scenarios for more detail.
• Where the referral was not successful, the Sender must present an appropriate message to the end user. See failure scenarios for more detail.
• The referral Sender must include reference to any accompanying BaRS booking related to the referral
  • The referral Sender's request must be referenced in the BaRS booking request (where the referral is made first in the workflow)
  • The referral Receiver must link the explicitly related booking and referral requests
• Update to amend a referral request is not supported. If a referral Sender wishes to change information in a request they must follow the re-refer workflow

Cancel referral

• The referral Sender must be capable of cancelling any referral made by them, within the current consultation or after the consultation event
• The referral Sender must retrieve the referral to be cancelled from the referral Receiver prior to cancellation to ensure they are working with the most up-to date version and it has not already been completed
• The referral Sender must provide visible confirmation to the end user of the status returned by the referral Receiver, i.e. whether the original referral was successfully cancelled or not
• If the update fails the referral Receiver must respond with the most appropriately aligned error
• The referral Receiver must store all previous versions of the referral
• The referral Receiver must not be required to inform the patient of the cancellation of the referral.  Business/clinical responsibility for informing the patient must remain with the referral Sender
• Any booking, sent as part of a referral, should be decoupled from the referral when cancelled. It may be linked in any subsequent re-refer workflow

Re-refer

• The referral Sender must be capable of re-referring within the current consultation or after the consultation event
• If a callback occurs, after the consultation has been completed, prior to attempting a re-refer the patient should be reassessed
• The referral Sender should revoke the original referral prior to making a new re-referral, whether within the current consultation or after the consultation event
• The referral Sender must provide visible confirmation to the end user of the status returned by the Receiver, i.e. whether the original referral was successfully revoked and the new referral made
• The referral Receiver must not be required to inform the patient of the cancellation, incurred as part of the re-refer process.  Business/clinical responsibility for informing the patient must remain with the referral Sender

Contacts

• A minimum of one contact (patient or third party) with a contact method (phone, email, etc.) of phone must be provided in booking and referral requests
• All contacts must have a rank associated with them
• There must be only one contact with a rank of 1
• All contacts must have at least one contact method (phone, email, etc.)
• All contact methods must have a rank
• There must be only one contact method with a rank of 1
• The contact ranked 1 and the contact method ranked 1 must be the primary callback for the request

Audit

• Sufficient information around any activity through the API and subsequent BaRS workflow must be persisted to aid support incidents and audit requirements
  
  

Error Handling

• Suppliers must adhere to the error handling guidance
  
  

Non Functional

• Suppliers must adhere to the non functional requirements

How does it work?

This section describes how the primary operations used in this Application works. This diagram illustrates the workflow and interactions of a referral request and booking process:

To support the workflows for this Application of the standard the operations that need to be supported are:

Make a Referral

Making a referral for this Application follows the standard pattern for BaRS composite operations.

The message definition that defines this payload for this Application is: BARS Message Definition ServiceRequest - Request Referral

In addition to that the specific workflow parameters that are required are as follows:

Additionally the HTTP request header would be:

NHSD-Target-Identifier = {Receiver Service Identifier}
X-Request-Id = <GUID_000001>
X-Correlation-Id = <GUID_000002>
NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)}
NHSD-Requesting-Practitioner = {FHIR Practitioner (Base64 Encoded)} 
NHSD-Requesting-Software =  {FHIR Device (Base64 Encoded)}

The HTTP response header would be:

X-Request-Id = <GUID_000001>
X-Correlation-Id = <GUID_000002>

Cancel a Referral

To cancel a referral this Application follows the standard pattern for BaRS composite operations with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the referral from the receiver as it may have changed locally. This is done by performing a "GET ServiceRequest by ID" call to the receiving system's corresponding API endpoint (via the BaRS proxy).

The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the standard pattern.

The message definition that defines this payload for this Application is: BARS Message Definition ServiceRequest - Request - Cancelled

As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed. This is always defined within the relevent message definition.

In addition the specific workflow parameters that are required are as follows:

Additionally the HTTP request header for the GET ServiceRequest would be:

NHSD-Target-Identifier = {Receiver Service Identifier}
X-Request-Id = <GUID_107>
X-Correlation-Id = <GUID_108>
NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)}
NHSD-Requesting-Practitioner = {FHIR Practitioner (Base64 Encoded)} 
NHSD-Requesting-Software =  {FHIR Device (Base64 Encoded)}

The HTTP response header for the GET ServiceRequest would be:

X-Request-Id = <GUID_107>
X-Correlation-Id = <GUID_108>

the HTTP request header for the POST $process-message would be:

NHSD-Target-Identifier = {Receiver Service Identifier}
X-Request-Id = <GUID_000003>
X-Correlation-Id = <GUID_000002>
NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)}
NHSD-Requesting-Practitioner = {FHIR Practitioner (Base64 Encoded)} 
NHSD-Requesting-Software =  {FHIR Device (Base64 Encoded)}

The HTTP response header for the POST $process-message would be:

X-Request-Id = <GUID_000003>
X-Correlation-Id = <GUID_000002>

Search for slots

During a referral workflow where booking is required, there are two separate processes that need to be undertaken sequentially. The first is to search for slots and once a slot has been selected, a booking can be made.

The first part of this process involves the sender making a request to the receiver for slots that match the search criteria. This is a "searching" request that requires the response body to include a "searchset" bundle resource.

The search parameters are defined on the BaRS API specification documentation.

Additionally the HTTP request header for the GET Slots would be:

NHSD-Target-Identifier = {Receiver Service Identifier}
X-Request-Id = <GUID_00001>
X-Correlation-Id = <GUID_00002>
NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)}
NHSD-Requesting-Practitioner = {FHIR Practitioner (Base64 Encoded)} 
NHSD-Requesting-Software =  {FHIR Device (Base64 Encoded)}

The HTTP response header for the GET Slots would be:

X-Request-Id = <GUID_00001>
X-Correlation-Id = <GUID_00002>

Make a booking

Making a booking for this Application follows the standard pattern for BaRS operations.

The message definition that defines this payload for this Application is: BARS Message Definition - Booking Request

In addition to that the specific workflow parameters that are required are as follows:

Additionally the HTTP request header would be:

NHSD-Target-Identifier = {Receiver Service Identifier}
X-Request-Id = <GUID_00003>
X-Correlation-Id = <GUID_00002>
NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)}
NHSD-Requesting-Practitioner = {FHIR Practitioner (Base64 Encoded)} 
NHSD-Requesting-Software =  {FHIR Device (Base64 Encoded)}

The HTTP response header would be:

X-Request-Id = <GUID_00003>
X-Correlation-Id = <GUID_00002>

Cancel a Booking

To cancel a booking this Application follows the standard pattern for BaRS operations with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the booking from the receiver as it may have changed locally. This is done by performing a "GET Appointment by ID" call to the receiving system's corresponding API endpoint (via the BaRS proxy).

The response to this request will be the requested Appointment resource which should be checked for its current status to ensure it does not already have a status of "cancelled". If not, this version of the Appointment should be used when re-submitting the modified resource in the POST bundle as described in the standard pattern.

The message definition that defines this payload for this Application is: BARS Message Definition - Cancel Booking Request

As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed. This is always defined within the relevent message definition.

In addition the specific workflow parameters that are required are as follows:

Additionally the HTTP request header for the GET Appointment would be:

NHSD-Target-Identifier = {Receiver Service Identifier}
X-Request-Id = <GUID_00004>
X-Correlation-Id = <GUID_00002>
NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)}
NHSD-Requesting-Practitioner = {FHIR Practitioner (Base64 Encoded)} 
NHSD-Requesting-Software =  {FHIR Device (Base64 Encoded)}

The HTTP response header for the GET Appointment would be:

X-Request-Id = <GUID_00004>
X-Correlation-Id = <GUID_00002>

the HTTP request header for the POST $process-message would be:

NHSD-Target-Identifier = {Receiver Service Identifier}
X-Request-Id = <GUID_00006>
X-Correlation-Id = <GUID_00002>
NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)}
NHSD-Requesting-Practitioner = {FHIR Practitioner (Base64 Encoded)} 
NHSD-Requesting-Software =  {FHIR Device (Base64 Encoded)}

The HTTP response header for the POST $process-message would be:

X-Request-Id = <GUID_00006>
X-Correlation-Id = <GUID_00002>

Bundle Processing - detailed

Below is a pseudo code example of how a bundle could be processed based on the above workflow variables:

Receive_Request
{
	initialise_variable "messageType" 
	initialise_variable "MessageReason" 
	initialise_variable "RequestType"
	
	//HTTP_Headers
	{
		if (HttpHeaders is null || HttpHeaders not Guid )
			OperationOutcome.issue.code = "invalid"
			throw exception with "REC_BAD_REQUEST"
			then return with HTTP.ResponseCode 400
		else if (HttpHeaders.RequestId == RequestId.AlreadyReceived)
			OperationOutcome.issue.code = "duplicate"
			throw exception with "REC_CONFLICT"
			then return with HTTP.ResponseCode 409
	}
	//Bundle
	{
		if(Bundle.meta.versionID is null)
			OperationOutcome.issue.code = "invariant"
			throw exception with "REC_BAD_REQUEST"
			then return with HTTP.ResponseCode 422
		else if!(Bundle.meta.versionID in versionID.supported)
			OperationOutcome.issue.code = "not-supported"
			throw exception with "REC_UNPROCESSABLE_ENTITY"
			then return with HTTP.ResponseCode 422
	}
	//Contents;
	{
		switch(MessageHeader.eventCoding)
		{
			case "servicerequest-request":
				if (MessageHeader.reason.code == "new" && ServiceRequest.status == "active")
					{
						switch(ServiceRequest.Category)
						{
							case "Referral":
								if (Careplan.status != "completed")
								{
									RequestType = "unknown"
									OperationOutcome.issue.code = "invariant"//A content validation rule failed
									throw exception with "REC_BAD_REQUEST"
									then return  HTTP.ResponseCode 400
								}
								else if(Encounter.Status.In("triaged","finished"))
									RequestType = "Im Receiving a new Referral"
								else
									RequestType = "unknown"
									OperationOutcome.issue.code = "invariant"//A content validation rule failed
									throw exception with "REC_BAD_REQUEST"
									then return  HTTP.ResponseCode 400
								break;
							default:
								RequestType = "unknown"
								OperationOutcome.issue.code = "invariant"//A content validation rule failed
								throw exception with "REC_BAD_REQUEST"
								then return  HTTP.ResponseCode 400;
						}
					}
				else if (MessageHeader.reason.code == "update")
					{
						switch(ServiceRequest.category)
						{
							case "Referral":
								if(ServiceRequest.status.In("entered-in-error","revoked"))
								{RequestType = "im receiving a cancelled referral"}
								else
								{
									RequestType = "unknown"
									OperationOutcome.issue.code = "invariant"//A content validation rule failed
									throw exception with "REC_BAD_REQUEST"
									then return  HTTP.ResponseCode 400								
								}
								break;
							default:
								RequestType = "unknown"
								OperationOutcome.issue.code = "invariant"//A content validation rule failed
								throw exception with "REC_BAD_REQUEST"
								then return  HTTP.ResponseCode 400;
						}
					}
				else
				{
					RequestType = "unknown"
					OperationOutcome.issue.code = "invariant"//A content validation rule failed
					throw exception with "REC_BAD_REQUEST"
					then return  HTTP.ResponseCode 400}
				break;
			case "servicerequest-response":
				if (MessageHeader.Response is null )
				{
						RequestType = "Invalid servicerequest-response"
						OperationOutcome.issue.code = "invariant"//A content validation rule failed
						throw exception with "REC_BAD_REQUEST"
						then return  HTTP.ResponseCode 400;
				}
				else if ( !Message.Response.identifier.existsLocally())
				{
						RequestType = "none or invalid response ID"
						OperationOutcome.issue.code = "not-found"//A content validation rule failed
						throw exception with "REC_NOT_FOUND"
						then return  HTTP.ResponseCode 404;
				}
				switch (ServiceRequest.Category)
					{
						case "Referral":
							if (ServiceRequest.status == "revoked" && MessageHeader.reason.code == "new")
							{ RequestType = "im receiving a Safeguarding DNA response (noshow)" } 
							else
							{
								RequestType = "unknown"
								OperationOutcome.issue.code = "invariant"//A content validation rule failed
								throw exception with "REC_BAD_REQUEST"
								then return  HTTP.ResponseCode 400;
							}
							break;
						default:
							RequestType = "unknown"
							OperationOutcome.issue.code = "invariant"//A content validation rule failed
							throw exception with "REC_BAD_REQUEST"
							then return  HTTP.ResponseCode 400;
					}
			case "booking-request":
				if (MessageHeader.Reason.code== "new" && Appointment.Status == "booked")
					if(slot.IsFree())
					{RequestType = "Im Receiving a new booking.";}
					else
					{
						OperationOutcome.issue.code = "conflict"
						throw exception with "REC_CONFLICT"
						then return with HTTP.ResponseCode 409
					}
				else if (MessageHeader.Reason.code == "update")
					MessageHeaderIsUpdate = true;
					switch (Appointment.Status)
					{
						case "cancelled":
							RequestType = "Im Receiving a booking cancellation."
							break						
						case "entered-in-error":
							RequestType = "Im Receiving a booking cancellation."
							break
						default:
							OperationOutcome.issue.code = "invariant"//A content validation rule failed
							throw exception with "REC_BAD_REQUEST"
							then return with HTTP.ResponseCode 400;
							break;
					}
				else
				{
					OperationOutcome.issue.code = "invariant"//A content validation rule failed
					throw exception with "REC_BAD_REQUEST"
					then return with HTTP.ResponseCode 400;
				}
				break;
			case "booking-response":
						OperationOutcome.issue.code = "invariant"//A content validation rule failed
						throw exception with 'REC_BAD_REQUEST'
						then return with HTTP.ResponseCode 400
						break;
			default:
				OperationOutcome.issue.code = "invariant"//A content validation rule failed
				throw exception with 'REC_BAD_REQUEST'
				then return with HTTP.ResponseCode 400
				break;
		}
		
	}
    //Submit
	{
		
		if (Message == "update")
		{
			if (currentLocalData.LastUpdated > originaRequest.ReceivedDate)
			{
				OperationOutcome.issue.code = "conflict"
				throw exception with 'REC_CONFLICT'
				then return with HTTP.ResponseCode 409
				break;
			}		
			foreach (Entry in Bundle)
			{
				if (currentLocalData.Item.exists)
				{
					if (currentLocalData.LastUpdated > originaRequest.Received)
					{
						OperationOutcome.issue.code = "conflict"
						throw exception with 'REC_CONFLICT'
						then return with HTTP.ResponseCode 409
						break;
					}
					if(Entry.LastUpdated > currentLocalData.Item.meta.LastUpdated && Entry.fullUrl = currentLocalData.Item.fullUrl)
						currentLocalData.Item = Entry.Item
						Entry.SubmitWith(currentLocalData.Item.meta.LastUpdated == Entry.LastUpdated )
					else
						ignore
				}
				else
					Entry.SubmitWith(currentLocalData.Item.meta.LastUpdated == Entry.LastUpdated )					
			}
			Submit(currentLocalData.Bundle.meta.LastUpdated = Bundle.Meta.LastUpdated)
			return HTTP.ResponseCode 200 'OK'
		}
		else
			{
				foreach(Entry in Bundle)
				{
					Entry.SubmitWith(currentLocalData.Item.meta.LastUpdated == Entry.LastUpdated )
					Submit(currentLocalData.Bundle.meta.LastUpdated = Bundle.Meta.LastUpdated)
					return HTTP.ResponseCode 200 'OK'
				}
			}
	}	
}	

How bookings and referrals map to services in UEC workflows

Background

It is common for healthcare IT systems to present a single API endpoint that is shared between multiple healthcare services - this is particularly common where a system is centrally-hosted and multi-tenanted, or where an organisation has a single IT system that is used to provide multiple healthcare services.

For example, an NHS provider organisation, 'Trumpton Community Hospital', which provides several healthcare services available to urgent emergency care services, including an NHS 111 call centre, an Out of Hours (OOH) GP service, an Urgent Treatment Centre (UTC) and an Emergency Department. The OOH GP service may offer two sub-services on DoS: OOH GP Telephone Consultations, and OOH GP Face to face Consultations.

Each of the above would be represented in the DoS as discrete services.

Some service discovery tools (such as the UEC Directory of Services (DoS)) list services at the granular healthcare service level i.e. for each of the above example healthcare services, the DoS will have one or more service records defined. It is these individual service records that are presented to users when searching the DoS.

When a system making a booking (e.g. NHS 111) requests available slots from a healthcare service, it needs to identify exactly which healthcare service it is targeting. This will allow receiving systems to correctly route requests and filter the responses to be relevant to the specific request.

A Key concept here is that it is the receiver of appointments that controls what is returned. The system making the booking does NO filtering, just showing all the slots that are returned.

Use Healthcare Service ID to filter slot requests to specific healthcare services

A search parameter of the HealthcareService (an intrinsic part of FHIR RESTful search) will be sent.

As a sender, include the ID of the healthcare service as a parameter

As a sender, include a search parameter specifying the Service Discovery tool ID of the healthcare service to which the query is directed.

As a receiver, use the healthcare service ID to filter the slots returned in your response

As a system receiving bookings and referrals and providing slots, ensure that only the appropriate slots are returned slots in your response, honouring the request.

Filtering is based on the HealthcareService specified in the query (to filter slots provided by that specific service), along with a date/time range and the 'status' of the slot i.e. either 'free' or 'busy'.

Support for booking only services

Some services that are profiled on the Urgent Care Directory of Services are commissioned as "booking only" services. This means that these services will only accept a referral if a booking has also been made for that patient.

If no appointment is available then a referral should not be made.

To achieve this, a "service attribute" is configurable against services. This will allow the service to be flagged as "booking only". Therefore if this attribute is present on the service all consumer systems should withhold referrals. The DoS API documentation for this can be found here.

Workflow

An example workflow showing how this might be implemented is illustrated below:

Example xml returned:

When requesting DoS service details with "CheckCapacitySummary" DoS API call, there is a section in the returned message for the additional attributes:

<ns1:attributes>
  <attribute>
    <dataType>string</dataType>
    <name>requirebooking</name>
    <description>The service only accepts referrals with an accompanying booked appointment.</description>
    <value>true</value>
  </attribute>
</ns1:attributes>

This attribute will have three possible states:

• not present
• present and false
• present and true

For the first two cases, it can be assumed that referrals can be made without a booking. Only if the attribute is present and true should a referral be withheld if there has been no booking.

Payloads

The specific guidance around the use of key FHIR resources is described below.

MessageHeader Resource

Standard Patterns for BaRS Operations explains in detail how the MessageHeader resource must be used.

The MessageHeader resource for the Booking Request should have the following resource elements set as follows:

• MessageHeader.eventCoding - must be populated with 'booking-request'
• MessageHeader.reasonCode - must be 'new' or 'update'
• MessageHeader.focus - must reference the Appointment FHIR resource
• MessageHeader.definition - must adhere to Booking Request Message definition

The MessageHeader resource for the Referral Request should have the following resource elements set as follows:

• MessageHeader.eventCoding - must be populated with 'servicerequest-request'
• MessageHeader.reasonCode - must be 'new' or 'update'
• MessageHeader.focus - must reference the ServiceRequest FHIR resource
• MessageHeader.definition - must adhere to Referral Request Message definition

ServiceRequest Resource

The primary resource in a referral is the ServiceRequest resource. When the request 'message bundle' is created by the Sender and processed by the Receiver, this is the starting point from which the referral is understood. It provides either the detail or references to all key FHIR resources, for example, the Patient, Encounter and Careplan. The guidance for this resource below provides more granular, element level, detail. A key point when a Sender builds the referral FHIR 'message bundle' is to ensure the MessageHeader.focus references the ServiceRequest resource.

There are two coding entries within ServiceRequest.category which are key to driving workflow:

1. Denotes the type of referral e.g. Transfer of care
2. Denotes the use case and must be populated with the relevant use case from use-case CodeSystem. e.g. 111 - ED. 999 - UTC, CAS - SEDEC. Please refer to the guidance in use-case categories

An important function of the ServiceRequest resource is to link the booking and referral when they are related in a workflow. If the booking is successfully made before the referral, the Sender will have the Appointment.Id value (from the synchronous HTTP response) and this must be included as a relative reference, under ServiceRequest.supportingInfo, in the referral request. The element ServiceRequest.supportingInfo may also be used to provide reference to other resources in the request i.e. Rejected Services. This is outlined in the element guidance below.

Appointment

The primary resource in a booking is the Appointment resource. When the request 'message bundle' is created by the Sender and processed by the Receiver, this is the starting point from which the booking is understood. It provide either the detail or references to all key FHIR resources. When a Sender builds the booking FHIR 'message bundle' they must ensure the MessageHeader.focus references the Appointment resource.

An important function of the Appointment resource is to link the booking and referral when they are related in a workflow. If the referral is successfully made before the booking, the Sender will have the ServiceRequest.Id value (from the synchronous HTTP response) and this must be included as a relative reference, under Appointment.basedOn, in the booking request.

Encounter Resource

The Encounter is used to represent the interaction between a patient and healthcare service provider. It links with numerous other resources, to reflect the assessment performed.

In the initial referral request, the Sender will include an Encounter resource as the container for their assessment, which established the need for the referral. This encounter should include a reference to the Sender's assessment under encounter.identifier. Additionally, the encounter.episodeOfCare must be populated with a 'Journey ID' reference which can be used in subsequent referrals to allow the audit of the route a patient took through service providers to resolve their initial request for care.

A second Encounter resource is used to transfer the human readable reference of the newly created referral, at the Receiver side. When a referral request is made, the Receiver should include a new, secondary, encounter resource with the status of 'planned' in their synchronous HTTP response to the Sender's request. This new 'planned' encounter will have both an Id and an Identifier value, indicating the Receiver's human readable and local references, respectively. This secondary, 'planned', encounter is not mandatory and has a cardinality of 0..1, unlike the primary encounter resource (1..1)(See the Entity Relationship Diagram for reference). The human readable (Identifier) reference is intended to allow Senders to provide something to the patient which they can take between services to support consistent joined up care, although, it is also a useful link for the services themselves to use when discussing a patient's transition of care. The local (Id) reference is not intended to be human readable but rather machine readable.

CarePlan Resource

The CarePlan resource is used in a referral request to communicate the assessment triage outcome and any associated clinical information, based on the assessment performed by the Sender. The Receiver will utilise the detail in this resource to summarise what the previous assessment ascertained about the patient, to be used in any subsequent consultation with the patient.

Primarily, careplan.activity is the section which holds this information, whether it be coded or free text. The careplan.activity.outcomeCodeableConcept is malleable enough to support the transmission of Pathways coded outcomes as well as clinical narrative. The element guidance for this resource below goes into the specific detail but, fundamentally, the Sender must include the selected Pathway, Symptom Group, Symptom Discriminator and Disposition (DX) code, along with the Pathways Assessment report. Further clinical narrative, provided outside of the Pathways assessment, can also be included under this element using 'text'.

Flag Resource

The Flag resource is used to communicate prospective warnings of potential issues when providing care to the patient. The population of the Flag Resource is optional as not all subjects will have relevant issues.

BaRS Senders should populate Flag resources and should make adequate provision in their solution to support key flags in BaRS Application workflows, for example, Safeguarding, for this Application. When populating this resource, Senders must include both flag.category and flag.code values using the specific BaRS CodeSystems.

When a BARS Receiver processes information in a Flag resource;

• they should populate a flag in their system, if their solution supports that flag
• they must display the information in the Flag resource in a way that supports the associated workflow (i.e. the relevant end users can see it and act upon it)
• rendering of Flag information must be in line with the Principles for rendering BaRS Payload.

Observation

The Observation resource is used to carry assertions supporting the assessment performed by the Sender. In the BaRS UEC Applications, Senders should add clinical notes to the Careplan resource rather than Observation, especially where they expect a Receiver to act upon the information.

There are specific instances where an Observation must be used to convey information and examples are provided to aid development:

• Birth Sex must be transferred in a referral using Observation. This information should only be transferred when considered clinically relevant and it is not considered as demographic information, as administrative gender would be. It should not be included as an extension on the patient resource, as described in UK Core.
• Estimated Age must be conveyed in an Observation.

QuestionnaireResponse

QuestionnaireResponse is optionally used to carry structured data in BaRS UEC Applications, specifically, to communicate:

• references to external sources of clinical information, looked up during the Sender's assessment
• Special Patient Notes (SPNs) held locally by the Sender and linked to the patient. Typically, this information is not available to retrieve from other sources and, therefore, must be included in its entirety.
• any Rejected Services by the patient prior to selection on the Receiver service

The extension questionnaireresponse-reason must be populated to indicate which data is contained within, as outlined in the resource element guidance below.

Using a nested set of questionnaireResponse.item, questionnaireResponse.linkId and questionnaireResponse.answer complex structured data can be generated and processed, by the Sender and Receiver, respectively. The element guidance for this resource below goes into detail but, essentially, the item and linkId can be continually nested to convey various types of information. The item indicates a new element, linkId provide the number of elements (within the item) and answer contains any the value, supported by many different data types.

Consent

In the BaRS UEC Applications the level of consent is stipulated to be for 'Direct Care' only. A referral must contain a Consent resource and it must adhere to the example provided under the BaRS FHIR assets.

Payload for requesting a referral, using Service Request

This payload is used to transmit all the necessary information that is required for an urgent or emergency care service to accept a patient referred into their service.