Scope and Requirements

Scope Overview

This BaRS Application (Application 6) covers three use cases:

• CAD to CAD Out of Area referral
• CAD to CAD Call Assist Request
• CAD to CAD Mutual Aid Request

For the public beta phase ONLY the CAD to CAD Out of Area referral use case is mandatory.

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 to the service
• For CAD to CAD Out of Area referrals the Home AST should be selected using the incident location and nationally agreed polygons

Referral

• A referral Sender must interpret the Message Definition returned by the Receiver to check what use cases are supported before attempting to send a referral.
• Referral Sender must ONLY send a use case specific referral that matches the intended use context and is supported by the Receiver i.e. MessageDefinition.useContext where the system value = usecases-categories-bars is mutualaidrequest or callassistrequest or outofareareferral.
• 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 Sender must have the capability to send a referral at points in the call cycle that are appropriate for the acuity of the case
• The referral Sender must include incident location information
• The referral will contain primarily clinical information, indicating the need of the individual and should state the anticipated action required by the Receiving service
• 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
  • scene safety information
  • timing information to support the timely delivery of care and reporting
• For Call Assist and Mutual Aid requests the referral can be rejected by the referral Receiver if they can't meet the requirements specified in the request

Referral Response (Status Update)

• A referral response is sent by the referral Receiver back to the referral Sender to notify them of the current status of the case
• A Referral response update is used to communicate each change in status
• For Call Assist and Mutual Aid requests, the referral rejection is communicated in a referral response
• The Receiver must send a Referral Response to the referral Sender each time the Encounter Status changes

API-M

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

Constraints

• Supporting the use of Emergency Call Prioritisation Advisory Group (ECPAG) approved Clinical Decision Support Systems only (NHS Pathways, NHS Pathways Clinical Content Support (PaCCS) and Advanced Medical Priority Dispatch System (AMPDS))
• No guidance provided on display of referral information beyond the Principles for rendering BaRS Payload
• BaRS currently supports the communication of consent for direct care only
• Certificates for Receiving messages to use nhs.uk domains only
• Receiving endpoints are to be internet facing
• Clinical Constraints exist - See Hazard Log

Requirements

Service Discovery

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

Referral Request

• The referral Sender must specify the type of referral (use case) in the request
• The referral Receiver must have the ability to specify the use cases that they are able to receive.
• 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
• The referral Sender must send incident location information as part of their request
• The referral Sender should send scene safety information as part of their request
• Any new or existing safeguarding concerns, recorded as part of the assessment, must be included in the referral Sender's request
• The referral Sender should support the communication of a triage/assessment undertaken by a clinician without the support of a CDSS
• The referral Sender should identify where the triage/assessment has been undertaken by a clinician
• The referral Sender must make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
• 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
• 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

Update referral

• The referral Sender must be capable of updating any referral made by them, within the current consultation or after the consultation event
• The referral Sender must send a referral update each time critical information is added to the case
• The referral Sender must retrieve the referral to be updated from the referral Receiver prior to update to ensure they are working with the most up-to date version and the referral has not already been been completed, or is at a point in the workflow where it it must not be updated
• 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 updated or not
• Where the update was not successful, the Receiver must send an appropriate response. See failure scenarios for more detail.
• Where the update was not successful, the Sender must present an appropriate message to the end user. See failure scenarios for more detail.
• The referral Receiver must store all previous versions of the referral
• The referral Receiver must not be required to inform the patient of the updating of the referral.  Business/clinical responsibility for informing the patient must remain with the referral Sender

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
• Where the cancellation was not successful, the Receiver must send an appropriate response. See failure scenarios for more detail.
• Where the cancellation was not successful, the Sender must present an appropriate message to the end user. See failure scenarios for more detail.
• 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

Incident Location

• The referral Sender must include the incident location in the referral request
• The Incident Location must include a co-ordinate (Eastings/Northings, Lat/Long or what3words equivalent) or a property location identifier (UPRN, Address and Postcode)
• The referral Sender should send a UPRN for all addressable locations
• The referral Sender should state if the Incident Location is provisional or confirmed
• The referral Receiver must re-plot the location on receipt
• The referral Receiver must use the UPRN to identify a location and record this locally

Other Locations

• The Sender may include other locations in the referral request
• All locations must include a co-ordinate (Eastings/Northings, Lat/Long or what3words equivalent) or a property location identifier (UPRN, Address and Postcode)

Timings

• The referral Sender should send the time that BT Emergency Services answered the initial 999 call (BTStartTime)
• The referral sender should send the Call Connect time (T0)
• The referral sender should send the Call Connect Answer time (T1)
• The referral sender should send the Incident Location confirmation time (T2)
• The referral Sender must send the clock start time (T5)
• The referral Sender should send the time Cardiopulmonary Resuscitation (CPR) started for cases where CPR was undertaken by a bystander

Scene Safety

• The referral Sender should send scene safety information in the referral
• Where scene safety questions have not been asked, the Flag resource relating to scene safety must be populated with 'UNK' unknown.
• When the scene is unsafe the referral Sender must send the reason(s) for the scene being unsafe

Crew information

• The referral Sender should send information relevant to the ambulance crew in the referral

Call Log information

• The referral Sender should send Call Log information relevant to the referral Receiver in the referral

Agencies informed

• The referral Sender should send information about which external agencies (e.g. Police, Coastguard) have been informed and at what time

Contacts

• A minimum of one contact (patient or third party) with a contact method (phone, email, etc.) of phone must be provided in requests
• All contacts must have a rank
• 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

Reject referral

• For Call Assist and Mutual Aid requests, the referral Receiver must send a referral rejection when they cannot meet the requirements in the request
• On receipt of a Referral rejection the referral Sender must process and display the referral rejection
  
  

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 work. The following diagrams illustrate the workflows and interactions of the following use cases :

• CAD to CAD Out of Area referral
• CAD to CAD Call Assist Request
• CAD to CAD Mutual Aid Request

Actors

Out of area calls

Calls may be re-routed by the BT Emergency Call Service to an Ambulance Service Trust (AST) outside of the geographic area of the incident (the Call Receiving AST) for the following reasons:

• The BT Intelligent Routing Platform (IRP) re-routes the call if the AST in the geographic area of the incident (the Home AST) has insufficient Call Handlers available to answer the call within a given time frame
  • The Home AST has a 'buddying' arrangement with an out-of-area AST to take their calls under defined circumstances (e.g. system downtime, periods of surge)
  • A third party caller calls about a patient in another area
  • Calls where the incident is on the boundary between two ASTs

Call Assist Requests

• A Home AST may request support from a Supporting AST when they cannot send a resource to an incident within their geographic boundary of responsibility
• The Supporting AST may accept or reject this request
• If the Supporting AST rejects the request, the Home AST will make alternative arrangements
• If the Supporting AST accepts the request:
  • the Supporting AST is responsible for dispatching an appropriate resource within the time frame specified by the ARP Priority code
  • The Home AST may close the case on their CAD

Mutual Aid Requests

• A Home AST may request support from a Supporting AST when they cannot meet all of the resource requirements for an incident within their geographic boundary of responsibility.

• The Supporting AST may accept or reject this request

• If the Supporting AST rejects the request, the Home AST will make alternative arrangements

• If the Supporting AST accepts the request:

  • the Supporting AST is responsible for dispatching the requested resource within the time frame specified in the request
  • The Home AST remains responsible for the case and for dispatching the resources not specified in the request

  Note: The BaRS Referral may be used to support single patient Mutual aid requests. It is not intended to replace processes relating to Mutual Aid Requests to support Major Incidents with multiple patients.

This details a BaRS CAD to CAD Referral:

Receive Call

• When a call is re-routed by BT Emergency Services, call details are also sent electronically to the referral Sender via the Enhanced Information Service for Emergency Calls (EISEC) interface.
• For the Call Assist and Mutual aid use cases, the initial call may be received via BT Emergency Services EISEC interface or directly into the CAD e.g. Healthcare Professional (HCP) direct line

Create Case

• On receipt of this information the referral Sender's CAD creates a case that is subsequently further populated by system end users, the associated telephony system and other interfaced systems e.g. Clinical Decision Support Systems (CDSS) such as NHS Pathways and Advanced Medical Priority Dispatch System (AMPDS).

Pre Triage Sieve (PTS)

• On answering the call the referral Sender will undertake a Pre Triage Sieve (PTS) question set to facilitate the early identification of patients with a potentially life-threatening emergency, in order that immediate dispatch of an appropriate resource can take place at the earliest possible point in the call cycle. If a life-threatening emergency is identified by the PTS the referral Sender AST may make a BaRS referral at this point in the call cycle, and all subsequent information will be communicated in BaRS Referral updates (see Sending a BaRS Referral)

Reason for Call

• The referral Sender will capture a Reason for Call based on what the patient or their representative tells them. This may also be known as 'What's the Problem' text or the Presenting complaint.

Nature of Call (NOC)

• The referral Sender will capture a NOC code to facilitate the early identification of patients with a potentially life-threatening emergency. If a life-threatening emergency is identified by the NOC, the referral Sender AST may make a BaRS referral at this point in the call cycle, and all subsequent information will be communicated in BaRS Referral updates (see Sending a BaRS Referral below)

Confirm Location

• The referral Sender will record the location of the incident and confirm using Gazetteer services. This is undertaken at the earliest opportunity and may be prior or subsequent to PTS and NOC.

Record demographics

• The referral Sender will capture the patient's baseline demographics where possible. This may be followed up by a Personal Demographics Service (PDS) search later in the call cycle.

Complete Triage

• The referral Sender will complete a triage of the patient to determine the acuity of the case. This will typically be undertaken by a call handler on the Computer Aided Dispatch (CAD) system, using an approved Clinical Decision Support System (CDSS), such as NHS Pathways or AMPDS. This is the point at which the Referral Sender AST will make a BaRS referral for non-life threatening emergencies; all subsequent information captured will be communicated in BaRS Referral updates (see Sending a BaRS Referral below)

Sending a BaRS Referral

• The referral Receiver is identified based on nationally agreed polygons that set geographic boundaries of responsibility for each AST. Service discovery will use these polygons to ascertain the ServiceID of the referral Receiver.
• The Service ID is used to query the BaRS Endpoint Catalogue to identify the referral Receiver's CAD system's endpoint details
• The sender will check that the Receiver supports the intended Referral use case before sending.
• The referral Sender will send the BaRS Referral to the referral Receiver, which includes information required by the referral Receiver to continue the patent's clinical care. This will also include the JourneyID created at the patient's first contact.

Create Case

• The referral Receiver's CAD will create a new case (Encounter) on receipt of the BaRS Referral and populate it with the patient and clinical details provided in the referral

Acknowledge Receipt

• The referral Receiver will send an acknowledgement back to the referral Sender, when it has successfully processed the payload. If it fails to do this it will send a BaRS error code. See failure scenarios for more detail.

Status Update (Referral Response)

• The referral Receiver will send a series of status updates back to the referral Sender, to support tracking the progress of the case.

Continue updates

• If additional or changed information about the case is captured by the referral Sender, subsequent to sending the BaRS Referral, they may send a BaRS Referral Update to ensure that the referral Receiver has the most up to date information.
• If the referral Sender needs to cancel a Referral, for example the patient calls back and says they do not require an ambulance, they need to send a Cancellation.
• On receipt of a Referral Update, the referral Receiver will send an acknowledgement back to the Sending AST on when it has successfully processed the payload. If it fails to do this it will send a BaRS error code. See failure scenarios for more detail.

Manage Stack

• The referral Receiver will manage the case in accordance with the Ambulance Response Programme (ARP) Priority Level. This may include:
  • Dispatching an appropriate resource within the specified time frame
  • Validating the triage outcome
  • Referring onward to another care setting e.g. Emergency Department
• When the status of a case changes in the referral Receiver's CAD, a BaRS Status Update will be sent to the referral Sender so they are aware of the current case status.

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 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 operations with an additional step. Before beginning the standard pattern as described on the linked section, the referral Sender must perform a read of the referral to be cancelled, from the referral Receiver, prior to cancellation to ensure they are working with the most up-to date information and it has not already been actioned. 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" or "completed". 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, should be include. This is always defined within the relevent message definition.

If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral message can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above.

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>

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 400
		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.coding[0].code) //https://fhir.nhs.uk/CodeSystem/message-category-servicerequest
					{
						case "Referral":
							if (Careplan.status != "active" && CarePlan.intent != "plan" && Task.status != "requested")
							{
								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","in-progess")&& Encounter.class.code=="EMER")
							{ 
								switch(ServiceRequest.Category.coding[1].code)  //https://fhir.nhs.uk/CodeSystem/usecases-categories-bars
								{
									case "MutualAidRequest":
										RequestType = "Im Receiving a new Mutual Aid Request";
									case:"CallAssistRequest":
										RequestType = "Im Receiving a new Call Assist Request";
									case:"OutOfArea":
										RequestType = "Im Receiving a new Out of Area Request";
								}									
							}
							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.coding[0].code) //https://fhir.nhs.uk/CodeSystem/message-category-servicerequest
					{
						case "Referral":
							if(ServiceRequest.status.In("entered-in-error","revoked"))
							{RequestType = "im receiving a cancelled referral"}
							else if (Task.status != "requested")
							{
								RequestType = "unknown"
								OperationOutcome.issue.code = "invariant"//A content validation rule failed
								throw exception with "REC_BAD_REQUEST"
								then return  HTTP.ResponseCode 400
							}
							else if(!LocalServiceRequestData.ResourceId.Contains(ServiceRequest.id))//if ServiceRequest does not exist locally. 
							{
								RequestType = "unknown"
								OperationOutcome.issue.code = "not-found"//A content validation rule failed
								throw exception with "REC_NOT_FOUND"
								then return  HTTP.ResponseCode 400
							}
							else if(Encounter.Status.In("triaged","finished","in-progess")&& Encounter.class.code=="EMER")
							{ 
								switch(ServiceRequest.Category.coding[1].code)  //https://fhir.nhs.uk/CodeSystem/usecases-categories-bars
								{
									case "MutualAidRequest":
										RequestType = "Im Receiving a new Mutual Aid Request update";
									case:"CallAssistRequest":
										RequestType = "Im Receiving a new Call Assist Request update";
									case:"OutOfArea":
										RequestType = "Im Receiving a new Out of Area Request update";
								}									
							}
							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 (ServiceRequest.status == "active")
					{
						if (MessageHeader.reason.code == "new")
						{
							switch(ServiceRequest.Category.coding[0].code) //https://fhir.nhs.uk/CodeSystem/message-category-servicerequest
							{
								case "Referral":
								if(Encounter.Status.In("planned","finished","in-progess")&& Encounter.class.code=="EMER")
									{ 
										switch(ServiceRequest.Category.coding[1].code)  //https://fhir.nhs.uk/CodeSystem/usecases-categories-bars
										{
											case "999to999MutualAidRequest":
												RequestType = "Im Receiving a new Mutual Aid Request response";
											case:"999to999CallAssistRequest":
												RequestType = "Im Receiving a new Call Assist Request response";
											case:"999to999OutOfArea":
												RequestType = "Im Receiving a new Out of Area Request response";
											default:
												RequestType = "unknown"
												OperationOutcome.issue.code = "invariant"//A content validation rule failed
												throw exception with "REC_BAD_REQUEST"
												then return  HTTP.ResponseCode 400;
										}									
									}
								default:
								{
									RequestType = "unknown"
									OperationOutcome.issue.code = "invariant"//A content validation rule failed
									throw exception with "REC_BAD_REQUEST"
									then return  HTTP.ResponseCode 400;
								}
							}	
						}
						else (MessageHeader.reason.code == "update") // Not alpha
						{
							switch(ServiceRequest.Category.coding[0].code) //https://fhir.nhs.uk/CodeSystem/message-category-servicerequest
							{
								case "Referral":
								if(Encounter.Status.In("planned","finished","in-progess")&& Encounter.class.code=="EMER")
									{ 
										switch(ServiceRequest.Category.coding[1].code)  //https://fhir.nhs.uk/CodeSystem/usecases-categories-bars
										{
											case "999to999MutualAidRequest":
												RequestType = "Im Receiving a  Mutual Aid Request update response";
											case:"999to999CallAssistRequest":
												RequestType = "Im Receiving a  Call Assist Request update response";
											case:"999to999OutOfArea":
												RequestType = "Im Receiving a  Out of Area Request update response";
											default:
												RequestType = "unknown"
												OperationOutcome.issue.code = "invariant"//A content validation rule failed
												throw exception with "REC_BAD_REQUEST"
												then return  HTTP.ResponseCode 400;
										}									
									}
								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 (ServiceRequest.status == "revoked")
				{
					if(Encounter.Status.In("cancelled")&& Encounter.class.code=="EMER")
					{ 
						switch(ServiceRequest.Category.coding[1].code)  //https://fhir.nhs.uk/CodeSystem/usecases-categories-bars
						{
							case "999to999MutualAidRequest":
								RequestType = "Im Receiving a new Mutual Aid Request rejection";
							case:"999to999CallAssistRequest":
								RequestType = "Im Receiving a new Call Assist Request rejection";
							default:
								RequestType = "unknown"
								OperationOutcome.issue.code = "invariant"//A content validation rule failed
								throw exception with "REC_BAD_REQUEST"
								then return  HTTP.ResponseCode 400;
						}	
					}								
				}
				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;
				}	
				else 
				{
					RequestType = "unknown"
					OperationOutcome.issue.code = "invariant"//A content validation rule failed
					throw exception with "REC_BAD_REQUEST"
					then return  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)
						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'
				}
			}
	}	
}	

Payloads for Referrals

Referral Payload

The below details the specific guidance around the use of resources required to create a referral by the referral Sender. See ServiceRequest - Request Referral message definition for details of resources required for this payload.

Note that referral Senders will also have to build the capability to receive and process the Referral Response (Status update) payload.

MessageHeader Resource

For detailed information on the use of MessageHeader please refer to the Standard Pattern Message Header.

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'
• MessageHeader.focus - must reference the ServiceRequest FHIR resource
• MessageHeader.definition - must adhere to Referral Request Message definition

ServiceRequest Resource

The 'focus' resource in a referral is the ServiceRequest resource. When the request payload (bundle) is created by the Sender and processed by the Receiver, this is the starting point from which the request is understood. It provides either the detail and 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.

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. Out of area, Mutual Aid or Call Assist. Please refer to the guidance in use-case categories

Additionally, the ServiceRequest.category.text must be populated with details about the service request when the request is to support the Call Assist or Mutual Aid use cases.

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 carrier for the assessment, which established the need for the referral. This encounter should include a local human readable 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.

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 (200) to the Sender's request. This new 'planned' encounter will have an Identifier value, indicating the Receiver's local human readable reference. See the Entity Relationship Diagrams for reference. The human readable (Identifier) reference is a useful link for the services 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.

Incident Location Resource

The Incident Location resource is used to transfer details of the incident location.

When the Sender populates the Incident Location resource:

• They must populate the Location.extension with at least one property or non-property element from the following:

  • Unique Property Reference Number (UPRN)
  • Postcode Address Finder (PAF) key
  • Eastings/Northings
  • what3words

• They should also populate the Location.extension with the percentage accuracy of the location

• They should populate the Location.address for all property based locations

• They should populate Location.address.line which is a repeatable element, with the order in which lines should appear in an address label

• They should populate Location.name when there is a property name

• They should populate Location.address.text with a text representation of the full address (including the address name), with each line separated by a comma

When a the Receiver processes information in an Incident Location resource:

• They should consume and populate all address fields sent, into their system
• They must display all address fields sent by the Sender

Location Resource

The Location resource is used to transfer details of location types other than the Incident Location

When the Sender populates the Location resource:

• They must populate the Location.extension with at least one property or non-property element from the following:

  • Unique Property Reference Number (UPRN)
  • Postcode Address Finder (PAF) key
  • Eastings/Northings
  • what3words

• They should populate the Location.address for all property based locations.

• They should populate Location.address.line which is a repeatable element, with the order in which lines should appear in an address label

• They should populate Location.name when there is a property name

• They should populate Location.address.text with a text representation of the full address (including the address name), with each line separated by a comma

When a the Receiver processes information in a Location resource:

• They should consume and populate all address fields sent, into their system
• They must display all address fields sent by the Sender

Note: The Patient Address is communicated in in the Patient resource and would only be replicated in the Location resource if it is also a secondary location e.g. Rendezvous point

CarePlan Resource

The CarePlan resource is used in a Referral Request to communicate the Sender's 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 review what the previous assessment ascertained about the patient, and to inform any subsequent action.

Primarily, careplan.activity is the section which holds this information, whether it be coded or free text. The careplan.activity.outcomeCodeableConcept supports the transmission of AMPDS and Pathways coded outcomes and the clinical narrative. The element guidance for this resource below goes into the specific detail but, the Sender must include the following:

• The selected AMPDS dispatch code and triage summary, or
• The Pathways, Symptom Group (SG), Symptom Discriminator (SD) and Disposition (DX) codes, along with the Pathways consultation summary.
• Further clinical narrative, provided outside of the AMPDS or Pathways assessment, can also be included under this element using 'text'
• The Ambulance Response Programme (ARP) priority code

The CarePlan.period.start is used to transfer the clock start time for dispatch and must be populated populated with Clock start date/Time Definition as per AmbSys specification.

• The careplan.author.reference should be populated with a reference to the PractionerRole when a triage has been validated or an assessment has been undertaken by a clinician. The careplan.author.reference must not be populated if the user undertaking the triage/assessment is NOT a clinical user.

Flag (Scene safety)

The Flag (Scene Safety) resource is used to communicate safety information about the incident location. The Flag.subject is the Incident Location

When populating this resource, Senders must include both flag.category and flag.code values using the specific BaRS CodeSystems

When the scene is unsafe the Flag.code.text must be populated with the free text reason(s) that the scene is unsafe.

When a Receiver processes information in a Flag (Scene Safety) resource;

• they should populate a flag in their system schema, if their solution supports that flag
• they must display the information in the Flag (Scene Safety) resource (including Flag.category and Flag.code) 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.

Flag Resource

The Flag resource is used to communicate prospective warnings of potential issues when providing care to the patient. The Flag.subject may be the Patient (e.g. Safeguarding concern) or the Location (e.g. location specific alerts). The population of the Flag is optional as not all subjects will have relevant issues.

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

When a the Receiver processes information in a Flag resource;

• they should populate a flag in their system schema, if their solution supports that flag
• they must display the information in the Flag resource (including Flag.category and Flag.code) 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. 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 below to aid development:

• Where Birth Sex is communicated it must be transferred in a Referral Request using an 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.
• Where Estimated Age is communicated it must be conveyed in an Observation.

Consent

The level of consent currently supported by BaRS is for 'Direct Care' only. In emergency care use cases this is usually implied consent. A Referral Request must contain a Consent resource and it must adhere to the example provided under the BaRS FHIR assets.

Questionnaire

A Questionnaire is an organised collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. They may be simple flat lists of questions or can be hierarchically organised in groups and sub-groups, each containing questions. The Questionnaire defines the questions to be asked, how they are ordered and grouped, any intervening instructional text and what the constraints are on the allowed answers. The results of a Questionnaire can be communicated using the QuestionnaireResponse resource.

The Questionnaire resource is used to covey the Pre Triage Sieve and Nature of Call (NOC) questions and the potential responses as detailed below:

Pre Triage Sieve

This is an example of the Pre triage Sieve questionnaire.

Only the nationally agreed answers and associated codes in this table are valid to be sent. No locally defined responses can be sent.

Nature of Call (NOC)

Nature of call types are nationally agreed by ECPAG for ASTs using both AMPDS and NHS Pathways as their CDSS. Receivers MUST be able to process and display NOC types and their associated code for both NHS Pathways and AMPDS NOC types detailed below.

AMPDS NOC Types

This is an example of the Nature of Call questionnaire.

Only the nationally agreed answers and associated codes in this table are valid to be sent. No locally defined responses can be sent.

NHS Pathways NOC Types

This is an example of the Nature of Call questionnaire.

Only the nationally agreed answers and associated codes in this table are valid to be sent. No locally defined responses can be sent.

Questionnaire Response

The Questionnaire Response resource is used to convey the PTS and NOC responses given by the patient (or their representative).

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, as guided by the corresponding questionnaire. The item indicates a new answer, linkId must correspond with the questionnaire question linkId, forging the relationship between the questionnaire and questionnaireResponse, and answer contains any the value recorded. The questionnaireResponse.item.answer datatype must correspond with that defined in the questionnaire.item.answerOption.

We have published examples of Pre Triage Sieve and Nature of Call questionnaire responses.

Only the nationally agreed answers and associated codes in the associated Questionnaire are valid to be sent in the QuestionnaireResponse.

Condition

The Condition resource is used to encapsulate the overall 'problem' the referral intends to resolve for the patient. The detail provided here underpins the rationale for the CarePlan and is a central resource for the Receiver looking for information about the patient and reason for referral.

The Condition resource is used to transfer the Presenting complaint. This is also referred to as:

• The Reason for Call (text)
• What's the problem? (text)

The key information about the 'problem' is comprised of two components within this Application, condition.category and condition.code. The category is used to qualify the code value, providing additional context to interpret the issue identified. For example, in this Application, the category will stipulate this is a 'presenting complaint', highlighting the provenance of the 'problem' for the Receiver to start their consultation. This is in addition to other specific status fields on the resource.

Procedure

This resource is used to record the details of current and historical procedures performed on or for a patient. A procedure is an activity that is performed on, with, or for a patient as part of the provision of care.

The Procedure resource is used to communicate that Cardio Pulmonary Resuscitation by a bystander is being undertaken, and when it started.

Task

The Task is used to direct the next action(s) required by the Sender making the referral, when the assessment has been undertaken without using NHS Pathways or AMPDS CDSS. Task supports in fulfilling Careplan, which also references it. The narrative within the payload starts with the assessment performed by the Sender (Encounter), identifying a 'problem' (Condition) which a plan of care (CarePlan) is established to address. The Sender is unable to support the plan of care so transitions responsibility, via a referral (ServiceRequest), while directing the next requested action (Task).

This Application utilises two elements within Task to direct the activity and time-frame, using Task.code and Task.restriction.period.

Communication

The Communication resource is a conveyance of information from a sender to a receiver. The information can include encoded data, text and optionally a related Patient and a related Encounter.

In this application it is used to transfer Call Log information and Crew Notes.

Referral Cancellation Payload

The ability to cancel a referral is a core workflow in BaRS. For details on the use of the standard pattern for cancellation please see the following Standard Patterns - Cancellation.

Payloads for Responses

Referral Response Payload (Status update)

This section provides guidance on the use of key resources, for the Receiver to create a Referral Response (Status update) to return to the Sender. See ServiceRequest - Response message definition for details of resources required for this payload.

Note that Receivers will also have to build the capability to receive and process the Referral Request and Cancellation payloads

MessageHeader Resource

For detailed information on the use of MessageHeader please refer to the Standard Pattern - Message Header.

The MessageHeader resource in the Referral Response should have the following resource elements set as follows:

• MessageHeader.eventCoding - must be populated with 'servicerequest-response'
• MessageHeader.reasonCode - must be 'new'
• MessageHeader.focus - must reference the Responder's current Encounter FHIR resource
• MessageHeader.definition - must adhere to Referral Response Message definition.
• MessgeHeader.Response - must be the original request BundleID

ServiceRequest Resource

The ServiceRequest reflects that sent by the Requester, and maintains the active state of the referral. The ServiceRequest.status at this point would stay as 'active'.

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. Out of area, Mutual Aid or Call Assist. Please refer to the guidance in use-case categories

Encounter Resource

The Responder's current Encounter is the focus resource in the Referral Response. This was originally the 'planned' Encounter created by the Receiver in the synchronous response to the Referral Request.

This Encounter is used to represent the interaction between the patient and the Receiver healthcare service provider.

When sending an Referral Response the Receiver must:

• Include the Receiver's current Encounter as the focus resource of the Referral Response
• Include the current Encounter.status on the Receiver's current Encounter. This is to indicate to the Sender the progress of the case.

Referral Response Payload (Reject referral)

This section provides guidance on the use of key resources, for the Receiver to create an Referral Response (Status update) to return to the Sender in order to reject a Mutual Aid Request or Call Assist Request. See ServiceRequest - Response message definition for details of resources required for this payload.

This follows the payload for the Referral Response (Status Update) with minor changes to the guidance for the Encounter Resource:

Encounter Resource

When sending an Referral Response the Receiver must:

• Include the Receiver's current Encounter as the focus resource of the Referral Response
• Include the current Encounter.status on the Receiver's current Encounter. This is to indicate to the Sender where a Call Assist or Mutual Aid request has been rejected.
• Encounter.reasonCode to be included on the Receiver's current Encounter to provide the reason for rejection.

Referral Payload

Payload for requesting a referral, using Service Request

This payload is used to transmit all the necessary information that is required for Ambulance Service Trusts to accept a patient referred into their service.