App 8 Index and Scope and Requirements

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md

@@ -31,18 +31,23 @@ topic: Application8
 
 This application supports the use of the following use cases:
 
-| Use Case                                                                                                                                                                      | Name |  Code |
-|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------|-------|
-| Referrals from A&G into eRS                                                                                                                 | A&G to eRS | a8t1 |
+|Use case                                                                        | Name | Code|
+|--------------------------------------------------------------------------------|------|------|
+| Improved Advice and Guidance to electronic-Referral Service (e-RS)| IAG to e-RS  | A8T1 |
+| 111Online to electronic-Referral Service (e-RS)| 111online to e-RS  | A8T2 |
+| NHS.UK to electronic-Referral Service (e-RS)| nhs.uk to e-RS  | A8T3 |
 
 
 ## Introduction
 
 ### Overview
 
-This page provides guidance for implementing the Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.0.7, text:BaRS Core implementation guide}} and API Specification when developing to the standard. 
+This page provides guidance for implementing the Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.3.1, text:BaRS Core implementation guide}} and API Specification when developing to the standard. 
 
 ### Data model endorsements
 
-TBC
+NHS England teams within Referrals and Appointments, Digitial Urgent and Emergency Care and the National Pathway for Self-Referrals have co-produced the Application 8 standard to facilitate interoperability between existing systems for referral pathways.  
+
+This page provides guidance for implementing the Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.3.1, text:BaRS Core implementation guide}} and Payload Definitions when developing to the standard.
+
 <hr />

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md

@@ -6,49 +6,65 @@ TOPIC: APP8-ScopeAndRequirements
 
 ### Scope Overview
 This BaRS Application (Referrals from Advice and Guidance to eRS broker, Application 8) supports the following use case(s) ONLY:
-- Advice and Guidance referring into eRS
+* Improved Advice and Guidance to electronic-Referral Service (e-RS)
+* 111Online to electronic-Referral Service (e-RS)
+* NHS.UK to electronic-Referral Service (e-RS)
 
-The payload and workflow have been designed to support this service. Other {{pagelink:applications, text:BaRS Applications}} offer scope for alternative use cases.
+
+
+The payload and workflow have been designed to support these services. Other {{pagelink:applications, text:BaRS Applications}} offer scope for alternative use cases.
 
 ### Functional Scope
-**Directing the referral (without Service Discovery)**
-- Direct to eRS static value 
+
+**Service Discovery**
+- Establishing a service, or service shortlist, for onward care is a mandatory step in the workflow
+
+
+**Directing the referral (independent of Service Discovery)**
+- Direct to predefined value representing the broker 
 
 **Referral**
 - A referral in this Application is a request for care, on behalf of an individual, from a sending service to a broker 
 - 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)
 - A list of healthcare services which can support the patient/client need are offered to the broker to direct the next step in care
+* 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
+    * timing information to support the timely delivery of care and reporting
+
 
 **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 {{pagelink:principles_prerequesites, text:Principles for rendering BaRS Payload}}
-- Consent within BaRS will be for Direct-Care only 
+- 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
 - 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
 - No digital support to remove or cancel a referral are offered (this would need to be achieved manually)
-- Where an Online Consultation or other self assessment tool is used to refer, the referral must be verified by a human representative of the sending organisation before the request is made
+- The service discovery tool for establishing services for onward care must be the [e-RS Service Search API A010](https://digital.nhs.uk/developer/api-catalogue/e-referral-service-fhir#post-/STU3/HealthcareService/$ers.searchHealthcareServicesForPatient)
 
 ### Requirements
 
-**Directing a referral** 
-- The service **must** support a unique identifier which the Sender is configured with to engage in the BaRS referral workflow
+**Service Discovery** 
+- Where more than one service is shortlisted, the maximum number of services allowed on a given shortlist is 20.
 
-**Referral** 
-- TBC
-
-**Contacts** 
-- A minimum of one contact (patient or third party) with a contact method (phone, email, etc.) of <ins>phone</ins> **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
+**Referral**
+- The referral Receiver **must** accept the referral request regardless of whether the patient is known to the service provider
+- The referral Receiver **must** only accept potential patients who do **<ins>have</ins>** a national validated identifier e.g. NHS Number
+- The national identifier  **must** have a [verification status](https://simplifier.net/hl7fhirukcorer4/valueset-ukcore-nhsnumberverificationstatus) of 'Number present and verified'  otherwise, the referral Sender **must <ins>not</ins>** include it 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 <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.3.1, text:failure scenarios}} for more detail
+- Where the referral was <ins>not</ins> successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.3.1, text:failure scenarios}} for more detail
+- The referral Sender **must** indicate consent to share (for Direct Care) to the Receiver 
+- The referral Sender **must** indicate the urgency (using the agreed codeset) of the request to the Receiver 
 
 
 ### Audit