You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Entity-Relationship-Diagrams.page.md
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md
+10-8Lines changed: 10 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,16 +7,22 @@ topic: APP8-HowDoesItWork
7
7
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:
13
+
To support the workflows for this Application of the Standard the operations that need to be supported are:
14
14
15
15
<hr>
16
16
17
-
### Directing the Referral without a Service Discovery step
17
+
### Directing the Referral
18
18
19
-
<HardcodedendpointforeRS>
19
+
The referral request is directed to a broker in this Application, rather than directly to a healthcare service expected to engage with the patient. The broker negotiates the next step in patient’s care journey with them, offering options and allowing the decide how to proceed. Service discovery still occurs during the assessment the Sender performs but instead of selecting a service at this stage, it is pushed to the broker.
20
+
21
+
The Sender will establish the patient need, prepare a shortlist of healthcare services to support them and package these in the referral request. The request is from the Sender to the broker Receiver and then onto the selected healthcare service.
22
+
23
+
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.
24
+
25
+
NB - The definition of the broker NHSD-Target-Identifier has not yet been agreed.
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md
+11-9Lines changed: 11 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,34 +20,36 @@ There are two *coding* entries within *ServiceRequest.category* which are key to
20
20
1. Denotes the type of referral e.g. Transfer of care
21
21
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 {{pagelink:core-SPUseCaseCategories-1.3.1, text:use-case categories}}
24
-
25
-
*Please note that the use-case category 'referraltopharmacy' is now deprecated to allow for more granular use cases.*
23
+
). e.g. IAG to e-RS. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.3.1, text:use-case categories}}
26
24
27
25
### Encounter Resource
28
26
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.
29
27
30
28
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.
31
29
32
-
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 <ins>not</ins> 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.
30
+
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 <ins>not</ins> 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 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.
33
31
34
32
### CarePlan Resource
35
33
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'.
36
34
35
+
Careplan includes the shortlist of healthcare services, under CarePlan.activity.details.performer, for the broker to negotiate with the patient.
36
+
37
+
### Device Resource
38
+
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. The broker is supporting the patient in their next step, choosing a healthcare service to undertake their care.
39
+
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}}).
40
+
37
41
### Condition Resource
38
42
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.
39
43
40
-
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.
44
+
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.
41
45
42
46
### Task Resource
43
-
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*).
44
-
45
-
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.
47
+
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*) to the broker, while directing the next requested action (*Task*).
46
48
47
49
### Flag Resource
48
50
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.
49
51
50
-
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).
52
+
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).
51
53
52
54
When a BARS Receiver processes information in a Flag resource;
0 commit comments