diff --git a/BaRS-Images/EntityMaps/EntityMapIAGtoeRSReferralRequest-1.0.0-alpha.svg b/BaRS-Images/EntityMaps/EntityMapIAGtoeRSReferralRequest-1.0.0-alpha.svg new file mode 100644 index 00000000..4247ad1b --- /dev/null +++ b/BaRS-Images/EntityMaps/EntityMapIAGtoeRSReferralRequest-1.0.0-alpha.svg @@ -0,0 +1,4 @@ + + + +FHIR BundleIdGUID_1FHIR MessageHeaderFullUrlurn:uuid:GUID_2eventCodingservicerequest-request*reasonnew**focusurn:uuid:GUID_4 (ServiceRequest)destinationurn:uuid:GUID_5 (Organisation)senderurn:uuid:GUID_6 (Organisation)source.endpoint'<system>/<value>' ++FHIR OrganisationFullUrlurn:uuid:GUID_5IdGUID_002FHIR OrganisationFullUrlurn:uuid:GUID_6IdGUID_001FHIR ServiceRequestFullUrlurn:uuid:GUID_4IdGUID_003categoryreferral***category
a8t1****
subjecturn:uuid:GUID_9 (Patient)basedOnurn:uuid:GUID_29 (CarePlan)encounterurn:uuid:GUID_10 (Encounter)requesterurn:uuid:GUID_11 (Practitioner)performerurn:uuid:GUID_35 (Device)
FHIR PatientFullUrlurn:uuid:GUID_9IdGUID_004identifier3478526985 (NHS Number)FHIR EncounterFullUrlurn:uuid:GUID_10IdGUID_005identity(local system encounter ref)subjecturn:uuid:GUID_9 (Patient)episodeOfCareGUID_13FHIR PractitionerFullUrlurn:uuid:GUID_11IdGUID_006FHIR PractitionerRoleFullUrlurn:uuid:GUID_12IdGUID_007practitionerurn:uuid:GUID_11 (Practitioner)FHIR ConsentFullUrlurn:uuid:GUID_22IdGUID_013patienturn:uuid:GUID_9 (Patient)
Key: - 

Mandatory Resource
Receiver defined value (in http response)
Optional Resource
Resources
* https://simplifier.net/nhsdigitalspine/message-events
** https://simplifier.net/nhsdigitalspine/message-reason-servicerequest
*** https://simplifier.net/nhsdigitalspine/message-category-servicerequest
**** https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars

+ Support for numerous valueSets
++ The Sender must populate the 'NHSD-Target-Identifier' value a Receiver needs to populate in order to send a response to them via the BaRS API

NB - All data elements note in FHIR resources must be included, if the resource is used. Other data elements will also be include - See Application Implementation Guidance for full detail.
Text
Entity map of FHIR Resources for BaRS ServiceRequest - Referral Request - IA&G to eRS
Sender defined value 
= 1 mandatory
= 0 or *
= 0 or 1
FHIR CarePlanFullUrlurn:uuid:GUID_29IdGUID_020subjecturn:uuid:GUID_9 (Patient)encounterurn:uuid:GUID_10 (Encounter)activity.detail.performer[(HealthcareService(s))]addressesurn:uuid:GUID_31 (Condition)activity.referenceurn:uuid:GUID_32 (Task)FHIR Encounter (Receiver new)FullUrlurn:uuid:GUID_30IdGUID_021identity(local system encounter ref)statusplannedsubjectGUID_004episodeOfCareGUID_13
Receiver included resource in http response only
FHIR OrganisationFullUrlurn:uuid:GUID_5IdGUID_002FHIR TaskFullUrlurn:uuid:GUID_32IdGUID_023statusrequestedintentordercode
792891000000102|Inbound referral
encounterurn:uuid:GUID_10 (Encounter)
FHIR ConditionFullUrlurn:uuid:GUID_31IdGUID_022subjecturn:uuid:GUID_9 (Patient)encounterurn:uuid:GUID_10 (Encounter)clincalStatusactiveverificationStatusprovisionalcategory33962009 | Presenting complaintcode (freetext)HerniaFHIR HealthcareServiceFullUrlurn:uuid:GUID_33IdGUID_024FHIR HealthcareServiceFullUrlurn:uuid:GUID_34IdGUID_025FHIR HealthcareServiceFullUrlurn:uuid:GUID_28IdGUID_019
Array of HealthcareServices (Min 1, Max 20)
FHIR DeviceFullUrlurn:uuid:GUID_35IdGUID_026deviceName.nameeRSdeviceName.typeuser-friendly-nameownerurn:uuid:GUID_5
\ No newline at end of file diff --git a/BaRS-Images/WorkFlows/Internal-Broker-IAG-To-e-RS-1.0.0-alpha.svg b/BaRS-Images/WorkFlows/Internal-Broker-IAG-To-e-RS-1.0.0-alpha.svg new file mode 100644 index 00000000..f23dad51 --- /dev/null +++ b/BaRS-Images/WorkFlows/Internal-Broker-IAG-To-e-RS-1.0.0-alpha.svg @@ -0,0 +1,4 @@ + + + +                                   Sender
Referral to 
e-RS?
Referral
Service Discovery
Yes
Alternate flow
No
Receiver
e-RS informs patient/client of HCS options
Acknowledge Referral
Patient/client reviews options 
Next action
New Workflow
Existing Workflow
Selects Healthcare Service
Makes referral from e-RS
Receive acknowledgment
Close case
Sender Assessment complete
Internal Broker - IAG to e-RS
End
Shortlist Healthcare Services (HCS)
Direct referral to e-RS
\ No newline at end of file diff --git a/BaRS-Images/WorkFlows/Internal-Broker-SelfReferral-To-e-RS-1.0.0-alpha.svg b/BaRS-Images/WorkFlows/Internal-Broker-SelfReferral-To-e-RS-1.0.0-alpha.svg new file mode 100644 index 00000000..7c7dea03 --- /dev/null +++ b/BaRS-Images/WorkFlows/Internal-Broker-SelfReferral-To-e-RS-1.0.0-alpha.svg @@ -0,0 +1,4 @@ + + + +                                   Sender
Referral to 
e-RS?
Referral
Service Discovery
Yes
Alternate flow
No
Receiver
e-RS informs patient/client of HCS option
Acknowledge Referral
Next action
New Workflow
Existing Workflow
Selects Healthcare Service
Makes referral from e-RS
Receive acknowledgment
Close case
Sender Assessment complete
Internal Broker - 111 Online and nhs.uk to e-RS (Self referral)
End
Select Healthcare Service (HCS)
Direct referral to e-RS
\ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Entity-Relationship-Diagrams.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Entity-Relationship-Diagrams.page.md index f6aad729..960815bb 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Entity-Relationship-Diagrams.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Entity-Relationship-Diagrams.page.md @@ -8,10 +8,10 @@ topic: APP8-EntityRelationshipDiagram Entity maps detail the relationship of the resources and elements within resources in the payloads.

-The below diagram details the ServiceRequest - Referral Request - +The below diagram details the ServiceRequest - Referral Request - Improved Advice and Guidance to e-RS (a8t1|IAG to e-RS)

- +


diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md index 519418cb..9b6b989b 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md @@ -4,19 +4,31 @@ topic: APP8-HowDoesItWork ## {{page-title}} -This section describes how the primary operations used in this application work. This diagram illustrates the workflow and interactions of a referral request: +This section describes how the primary operations used in this Application work. + +This diagram illustrates the workflow and interactions of a referral request where healthcare options are offered to a patient by a clinician:
- + + +The Application also supports a self-referral workflow: +
+ -To support the workflows for this application of the standard the operations that need to be supported are: +To aid the workflows for this Application of the Standard the operations that need to be supported are:
-### Directing the Referral without a Service Discovery step +### Directing the Referral + +The referral request is directed to a broker in this Application, rather than directly to the healthcare service expected to engage with the patient. The broker negotiates the next step in the patient’s care journey, offering optional healthcare services and allowing them to choose how to proceed. Service discovery still occurs during the assessment, undertaken by the Sender, but, instead of selecting a service at this stage, selection happens later in the workflow with the broker. + +The Sender will establish the patient need, identify a specific service or prepare a shortlist of healthcare services to support them, and package these in the referral request. The request is sent from the Sender to the broker (Receiver) and then onto the selected healthcare service (through [e-RS](https://digital.nhs.uk/services/e-referral-service) ). - +Directing the referral request will still engage the same BaRS mechanisms; utilising the NHSD-Target-Identifier. However, the Receiver is a consistent, known entity, rather than dynamically established during workflow. + +*NB - The definition of the broker NHSD-Target-Identifier has not yet been agreed.* ### Make a Referral @@ -77,7 +89,7 @@ In addition to that the specific workflow parameters that are required are as fo Additionally the HTTP request header would be: ``` -NHSD-Target-Identifier = {Receiver Service Identifier} +NHSD-Target-Identifier = {Receiver (Broker) Service Identifier} X-Request-Id = X-Correlation-Id = NHSD-End-User-Organisation = {FHIR Organisation (Base64 Encoded)} @@ -92,10 +104,6 @@ X-Request-Id = X-Correlation-Id = ``` -### Cancel a Referral - - - ### Bundle Processing - detailed @@ -323,6 +331,8 @@ Receive_Request ``` +*NB - Cancel and/or Update of the referral request are not yet supported in this Application* +
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md index 8246506b..bbab6e3a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md @@ -20,34 +20,36 @@ There are two *coding* entries within *ServiceRequest.category* which are key to 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]( https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars -). e.g. Primary Care to Community Pharmacy. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.3.1, text:use-case categories}} - -*Please note that the use-case category 'referraltopharmacy' is now deprecated to allow for more granular use cases.* +). e.g. IAG to e-RS. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.3.1, text:use-case categories}} ### 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 {{pagelink:APP5-EntityRelationshipDiagram}} 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. +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 {{pagelink:APP8-EntityRelationshipDiagram}} for reference). The human readable (Identifier) reference is intended to allow Senders to provide a reference to the patient which they can take between services to support consistent joined up care. It is also useful 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. ### 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'. +Careplan includes the shortlist of healthcare services, under CarePlan.activity.details.performer, for the broker to negotiate with the patient. + +### Device Resource +Device has been introduced in Application 8 because the Sender is not directing their request to a specific healthcare service but rather an internal broker. We are defining the broker (Receiver) as a FHIR Device resource. The broker is supporting the patient in their next step, choosing a healthcare service to undertake their care. +In the BaRS payload, the Device is consider the performer of this next step and this is reflected in the FHIR bundle narrative by referencing Device under ServiceRequest.performer (see {{pagelink:APP8-EntityRelationshipDiagram}}). + ### 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. +The key information about the 'problem' is comprised of two components, *condition.category* and *condition.code*. The category is used to qualify the code value, providing additional context to interpret the issue identified. For example, the category will stipulate this is a 'presenting complaint', highlighting the provenance of the 'problem' to the Receiver. ### 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. +The Task is used to direct the next action(s) required by the Sender making the referral. Task supports in fulfilling Careplan. The Careplan resource will reference the Task. 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*) to the broker, while directing the next requested action (*Task*). ### 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](https://simplifier.net/nhsbookingandreferrals/~resources?category=CodeSystem&sortBy=DisplayName). +BaRS Senders **should** populate Flag resources and **should** make adequate provision in their solution to support key flags in BaRS Application workflows, for example, Additional Patient Information. When populating this resource, Senders **must** include both *flag.category* and *flag.code* values using the specific [BaRS CodeSystems](https://simplifier.net/nhsbookingandreferrals/~resources?category=CodeSystem&sortBy=DisplayName). When a BARS Receiver processes information in a Flag resource; diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md index cc57046f..81f61229 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md @@ -3,9 +3,9 @@ topic: APP8-ReferralPayload --- ## {{page-title}} -### Payload for requesting a referral, using Service Request +### Payload for generating a referral to a broker, for a patient to select their next healthcare service from shortlist, 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. +This payload is used to transmit all the necessary information that is required for an internal broker, such as e-RS, to reveiw a shortlist of healthcare services with a patient and decided the next step in their care journey.