Scope and Requirements

Scope Overview

This BaRS Application (Referrals into Community Pharmacy, Application 5) supports the following use case(s) ONLY:

• Primary Care to Community Pharmacy (Pharmacy First)
• Primary Care to Pharmacy Contraception (Oral Contraception for supply of initial or repeat prescriptions for Combined Oral Contraceptive (COC) or Proestogen Only Pill (POP))
• Primary Care to Pharmacy Blood Pressure Check Service

The payload and workflow have been designed to support this service. 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. However, the NHS England Directory of Services supports this application and futher details are provided in the 'Find a Service' section
• The service must be configured within the BaRS infrastructure (Endpoint Catalogue) before requests can be made

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 of the receiving service
• The referral will contain primarily clinical information, indicating the need of the individual and must state the anticipated action required by the receiving service (see Task FHIR resource)

API-M

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

Constraints

• No guidance is provided on the display of referral information beyond the Principles for rendering BaRS Payload
• 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
• Clincial Constraints exist - See Hazard Log
• No element level 'updates' to requests are supported. A new request must be generated to change information in the referral request
• Where an Online Consultation tool is used to refer, the referral must be verified by a human representative of the sending organisation before the request is made
• Referrals to the Oral Contraception service must adhere to the published policy specification
• Referrals to the Blood Pressure service must adhere to the published policy specification

Requirements

Service Discovery

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

Referral

• Clinical and non-clinical users must be capable of making referrals
• 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 have a verification status of 'Number present and verified' or 'Number present but not traced', otherwise, the referral Sender must not include it in the request
• Any new or existing Individual Requirements e.g. needle phobia, wheelchair access etc., recorded as part of the assessment, must be included in the referral Sender's request
• The referral Receiver must clearly identify any included Individual Requirements to the end user
• The referral Receiver must accurately represent information made by the Sender to the end user
• The referral Receiver must display the Sender organisation name and identifier (Note - This organisation may not be the patient's registered GP Surgery.)
• The referral Sender must include the Pharmacy Service that the request is intended for (from the defined list)
• The referral Sender must indicate consent to share (for Direct Care) to the Receiver
• The referral Sender should indicate the urgency (providing timeframe within which included actions are expected to take place) of the request to the Receiver
• The referral Sender must indicate novel medications, established during the latest assessment and not available on existing records, to the Receiver
• The referral Sender must indicate novel allergies, established during the latest assessment and not available on existing records, to the Receiver
• The referral Sender must indicate localised Special Patient Notes (SPNs) to the Receiver, if they hold any for the patient
• The referral Sender must include the sending organisation type (organization.type in FHIR) to indicate the referral entry method into a Receiver
• The referral Sender should include the Body Mass Index (BMI) of the patient being referred
• The referral Sender should include the service type when requesting a Blood Pressure service e.g. single check or monitoring over a period (ABPM)
• The referral Sender should include the current oral contraception medication a patient is prescribed when requesting a Oral Contraception service, if requesting ongoing (repeat) supply
• The referral Sender must make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user so they can share with the patient/third party
• 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 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 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
• 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 remains with the referral Sender

Re-refer

• The referral Sender must be capable of re-referring within the current consultation or after the consultation event
• If the patient recontacts the sending service after the sender's consultation has been completed, the patient should be reassessed prior to attempting to re-refer
• The referral Sender should revoke the original referral prior to making a re-referral, whether within the current consultation or after the consultation event
• Where the re-referral was not successful, the Receiver must send an appropriate response. See failure scenarios for more detail.
• Where the re-referral was not successful, the Sender must present an appropriate message to the end user. See failure scenarios for more detail.
• 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 remains 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 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 work. This diagram illustrates the workflow and interactions of a referral request:

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

Find a Service

The BaRS referral process as shown above does not include guidance on how a user should determine if a referral to Pharmacy is appropriate for the patient. It is the responsibility of the referring organisaton to ensure patients are pre-screened by GP Practice staff (care navigators or clinicians) prior to beginning the referral process, using their own judgement or an appropriate triage tool.

Directory of Services API

Pharmacy services are profiled on the Directory of Services (DoS).

For this application, systems should use the Directory of Services - Urgent and Emergency Care - REST API.

Details on how to develop to use this API and onboard to use it in production, are provided in the links above.

For this application the Service Type search will be used: Search by Service Type | docs-dos-api (developer.nhs.uk).

Guidance on how to call the DoS API

This API supports a search by location (e.g. the patient's current location). Note that the DoS API used does not support the concept of searching for services that are open within a given timeframe, however the results from DOS include all opening times. The service search results should be filtered to those that are open in the timeframe required for the referral. The filtered results should be displayed back to the user, in order to allow them to choose with the patient where they want to go.

The search parameters to be used are as follows:

Guidance on service search and which services to display

When a service is chosen, the "Service ID" field in the DOS data will be used as the Receiver Service Identifier to then initiate the referral as per the following sections.

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 PractitionerRole (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 cancellation.

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

If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral request 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 PractitionerRole (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 PractitionerRole (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)
						{
							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'
				}
			}
	}	
}	

Payloads

MessageHeader Resource

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

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 'focus' 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. Primary Care to Community Pharmacy. Please refer to the guidance in use-case categories

Please note that the use-case category 'referraltopharmacy' is now deprecated to allow for more granular 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 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 (200) to the Sender's request. This new 'planned' encounter will have both an Id and an Identifier value, indicating the Receiver's local reference and human readable one, respectively. This secondary, 'planned', encounter is not mandatory (cardinality of 0..1), unlike the primary encounter resource (1..1) (See the Entity Relationship Diagrams 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 next steps in care, linking both the 'problem' identified (Condition resource, careplan.addresses), following the assessment performed by the Sender, and the required action to move the patient's issue to resolution (Task resource, careplan.activity.reference). 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. This overall clinical narrative and assessment output is included in this resource, under element careplan.outcomeCodeableConcept.text, as 'freetext'.

Condition Resource

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 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.

Task Resource

The Task is used to direct the next action(s) required by the Sender making the referral. 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 timeframe, using Task.code and Task.restriction. The code will be a fixed value, indicating that a consultation is being request of the 'Community Pharmacist Consultation Service for minor illness' (Pharmacy First), dictating the action should take place within twenty-four hours, under the restriction.period element. The patient is responsible for attending the pharmacy so the timeframe is a guide, indicating when the request is expected to occur. The pharmacist will only contact the patient if they have concerns based on the referral content.

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.

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.

Referral Payload

Payload for requesting a referral, using Service Request

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