diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md index 6b178574..0cc0d7b9 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md +++ b/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. +
\ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md index 4e26934e..793eee49 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md +++ b/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 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 +**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 **have** 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 not** 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 not 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 not 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