diff --git a/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg b/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg index f4152b9e..baa079cf 100644 --- a/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg +++ b/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg @@ -1,4 +1,4 @@ -
User
Sender
BaRS Proxy
Endpoint
Receiver
User
Sender
BaRS Proxy
Endpoint
Receiver
with ID
Find Patients Appointments
Get Appointment/ServiceRequest (ID)
Get Appointment/ServiceRequest (ID)
Appointment/ServiceRequest resource
Find Endpoint
Endpoint
Appointment/ServiceRequest resource
Show Appointments
Alt: with NHS No.
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Alt: with patient demographics
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Continue Cancellation workflow as outlined for use-case
\ No newline at end of file +
User
Sender
BaRS Proxy
Endpoint
Receiver
User
Sender
BaRS Proxy
Endpoint
Receiver
with ID
Find Patients Appointments
Get Appointment/ServiceRequest (ID)
Get Appointment/ServiceRequest (ID)
Appointment/ServiceRequest resource
Find Endpoint
Endpoint
Appointment/ServiceRequest resource
Show Appointments
Alt: with NHS No.
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Alt: with patient demographics
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Continue Cancellation workflow as outlined for use-case
\ No newline at end of file diff --git a/BaRS-Images/WorkFlows/CADOutOfArea-1.0.2.svg b/BaRS-Images/WorkFlows/CADOutOfArea-1.0.2.svg index 140734d3..8fde11f6 100644 --- a/BaRS-Images/WorkFlows/CADOutOfArea-1.0.2.svg +++ b/BaRS-Images/WorkFlows/CADOutOfArea-1.0.2.svg @@ -1,4 +1,4 @@ -

CAD to CAD Simplified Workflow - Use Case: Out of Area Referral (including IRP routed calls)

No
No
Update Transfer details
Scene safety update
Business
Ack HTTP
Response
Receive acknowledgment
BaRS HTTP
Response
BaRS Update
BaRS HTTP
Response
Yes 
Acknowledge receipt of case
Process case update
Business Ack
- Action
Triggered
Acknowledge receipt of update
Manage stack
Update demographics
Update triage
Update Location detaIs
Continue Updates
Yes
Suitable for dispatch
Suitable for Validation?
No
Yes
Yes
Home 999 AST
Suitable for Referral to CAS?
National Telephony
                                                 Receiving 999 AST
Route to available Trust
Record Demographics
Complete 999 Triage
Confirm Location
BT EISEC
Create case
Receive Call
Create case
Identify Home Trust
Transfer Case
BaRS Referral
Pre Triage Sieve
Reason for Call
Pre alert
Record Nature of Call
New Workflow
Existing BaRS Workflow
Close case
Continue Updates
No
Receive acknowledgment
Update MDT
Dispatch resource
Send for Validation
Refer to CAS
Existing Workflow
Pre alert
Business
Ack HTTP
Response
Pre alert
Home Trust available?
Yes
No
BAU workflow
Business Ack
- Action
Triggered
\ No newline at end of file +

CAD to CAD Simplified Workflow - Use Case: Out of Area Referral 

No
No
Update Transfer details
Scene safety update
Business
Ack HTTP
Response
Receive acknowledgment
BaRS HTTP
Response
BaRS Update
BaRS HTTP
Response
Yes 
Acknowledge receipt of case
Process case update
Business Ack
- Action
Triggered
Acknowledge receipt of update
Manage stack
Update demographics
Update triage
Update Location detaIs
Continue Updates
Yes
Suitable for dispatch
Suitable for Validation?
No
Yes
Yes
Home 999 AST
Suitable for Referral to CAS?
National Telephony
                                                 Receiving 999 AST
Route to available Trust
Record Demographics
Complete 999 Triage
Confirm Location
BT EISEC
Create case
Receive Call
Create case
Identify Home Trust
Transfer Case
BaRS Referral
Pre Triage Sieve
Reason for Call
Pre alert
Record Nature of Call
New Workflow
Existing BaRS Workflow
Close case
Continue Updates
No
Receive acknowledgment
Update MDT
Dispatch resource
Send for Validation
Refer to CAS
Existing Workflow
Pre alert
Business
Ack HTTP
Response
Pre alert
Home Trust available?
Yes
No
BAU workflow
Business Ack
- Action
Triggered
\ No newline at end of file diff --git a/CodeSystem/usecases-categories-bars.xml b/CodeSystem/usecases-categories-bars.xml index 45dac070..8a1651bb 100644 --- a/CodeSystem/usecases-categories-bars.xml +++ b/CodeSystem/usecases-categories-bars.xml @@ -122,6 +122,6 @@ - + \ No newline at end of file diff --git a/Examples/REFREQ01 - Referral Service Request New Full - 111 to ED.xml b/Examples/REFREQ01 - Referral Service Request New Full - 111 to ED.xml index 6053fd74..97703ca1 100644 --- a/Examples/REFREQ01 - Referral Service Request New Full - 111 to ED.xml +++ b/Examples/REFREQ01 - Referral Service Request New Full - 111 to ED.xml @@ -347,9 +347,9 @@ - - - + + + diff --git a/Examples/REFREQ02 - Referral Service Request New Full - 999 to CAS.xml b/Examples/REFREQ02 - Referral Service Request New Full - 999 to CAS.xml index 53309225..f94d91f4 100644 --- a/Examples/REFREQ02 - Referral Service Request New Full - 999 to CAS.xml +++ b/Examples/REFREQ02 - Referral Service Request New Full - 999 to CAS.xml @@ -327,8 +327,8 @@ - - + + diff --git a/Examples/REFREQ03 - Referral Service Request New Full - Primary Care to Community Pharmacy - Minor Illness.xml b/Examples/REFREQ03 - Referral Service Request New Full - Primary Care to Community Pharmacy - Minor Illness.xml index 99ac686c..dcc810a5 100644 --- a/Examples/REFREQ03 - Referral Service Request New Full - Primary Care to Community Pharmacy - Minor Illness.xml +++ b/Examples/REFREQ03 - Referral Service Request New Full - Primary Care to Community Pharmacy - Minor Illness.xml @@ -341,9 +341,9 @@ - - - + + + diff --git a/Examples/REFREQ04 - Referral Service Request - CAD Out of Area.xml b/Examples/REFREQ04 - Referral Service Request - CAD Out of Area.xml index b2cf19b0..28098d71 100644 --- a/Examples/REFREQ04 - Referral Service Request - CAD Out of Area.xml +++ b/Examples/REFREQ04 - Referral Service Request - CAD Out of Area.xml @@ -372,8 +372,8 @@ - - + + diff --git a/Examples/REFREQ05 - Referral Service Request - CAD Mutal Aid Request.xml b/Examples/REFREQ05 - Referral Service Request - CAD Mutal Aid Request.xml index d60113da..aca13558 100644 --- a/Examples/REFREQ05 - Referral Service Request - CAD Mutal Aid Request.xml +++ b/Examples/REFREQ05 - Referral Service Request - CAD Mutal Aid Request.xml @@ -367,8 +367,8 @@ - - + + diff --git a/Examples/REFREQ06 - Referral Service Request New Full - GP to BP - ABPM.xml b/Examples/REFREQ06 - Referral Service Request New Full - GP to BP - ABPM.xml index 1ca72324..617cfe8e 100644 --- a/Examples/REFREQ06 - Referral Service Request New Full - GP to BP - ABPM.xml +++ b/Examples/REFREQ06 - Referral Service Request New Full - GP to BP - ABPM.xml @@ -409,9 +409,9 @@ - - - + + + diff --git a/Examples/REFREQ07 - Referral Service Request New Full - GP to OC.xml b/Examples/REFREQ07 - Referral Service Request New Full - GP to OC.xml index bbc02f0a..a6af60ba 100644 --- a/Examples/REFREQ07 - Referral Service Request New Full - GP to OC.xml +++ b/Examples/REFREQ07 - Referral Service Request New Full - GP to OC.xml @@ -483,9 +483,9 @@ - - - + + + diff --git a/Examples/REFREQ8A - Referral Service Request - CAD Out of Area C1(1 of 4 - Initial).xml b/Examples/REFREQ8A - Referral Service Request - CAD Out of Area C1(1 of 4 - Initial).xml index 85124a43..7624de75 100644 --- a/Examples/REFREQ8A - Referral Service Request - CAD Out of Area C1(1 of 4 - Initial).xml +++ b/Examples/REFREQ8A - Referral Service Request - CAD Out of Area C1(1 of 4 - Initial).xml @@ -265,8 +265,8 @@ Message 1 - Intital Message - - + + diff --git a/Examples/REFREQ8B - Referral Service Request - CAD Out of Area C1(2 of 4 - Update).xml b/Examples/REFREQ8B - Referral Service Request - CAD Out of Area C1(2 of 4 - Update).xml index f12eb902..af581f7c 100644 --- a/Examples/REFREQ8B - Referral Service Request - CAD Out of Area C1(2 of 4 - Update).xml +++ b/Examples/REFREQ8B - Referral Service Request - CAD Out of Area C1(2 of 4 - Update).xml @@ -328,8 +328,8 @@ Message 2 - First update - - + + diff --git a/Examples/REFREQ8C - Referral Service Request - CAD Out of Area C1(3 of 4 - Update).xml b/Examples/REFREQ8C - Referral Service Request - CAD Out of Area C1(3 of 4 - Update).xml index e74e3fba..37fcea15 100644 --- a/Examples/REFREQ8C - Referral Service Request - CAD Out of Area C1(3 of 4 - Update).xml +++ b/Examples/REFREQ8C - Referral Service Request - CAD Out of Area C1(3 of 4 - Update).xml @@ -457,8 +457,8 @@ Message 3 - Second update - - + + diff --git a/Examples/REFREQ8D - Referral Service Request - CAD Out of Area C1(4 of 4 - Final Update).xml b/Examples/REFREQ8D - Referral Service Request - CAD Out of Area C1(4 of 4 - Final Update).xml index e62523cf..8c82a8dd 100644 --- a/Examples/REFREQ8D - Referral Service Request - CAD Out of Area C1(4 of 4 - Final Update).xml +++ b/Examples/REFREQ8D - Referral Service Request - CAD Out of Area C1(4 of 4 - Final Update).xml @@ -464,8 +464,8 @@ Message 4 - Final update - - + + diff --git a/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(1 of 3 - Initial).xml b/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(1 of 3 - Initial).xml index af073663..9cd6b251 100644 --- a/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(1 of 3 - Initial).xml +++ b/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(1 of 3 - Initial).xml @@ -293,8 +293,8 @@ Message 1 - Intital Message - - + + diff --git a/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(2 of 3 - Update).xml b/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(2 of 3 - Update).xml index f04d25d9..97bd8960 100644 --- a/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(2 of 3 - Update).xml +++ b/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(2 of 3 - Update).xml @@ -424,8 +424,8 @@ Message 2 - First update - - + + diff --git a/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(3 of 3 - Final Update).xml b/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(3 of 3 - Final Update).xml index a74202b9..f9ba5101 100644 --- a/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(3 of 3 - Final Update).xml +++ b/Examples/REFREQ9A - Referral Service Request - CAD Out of Area C2(3 of 3 - Final Update).xml @@ -430,8 +430,8 @@ Message 3 - Final update - - + + diff --git a/Examples/REFRESP01 - Referral Service Request Response New Full - ED to 111 Safeguarding DNA Feedback.xml b/Examples/REFRESP01 - Referral Service Request Response New Full - ED to 111 Safeguarding DNA Feedback.xml index dca7b022..db1e1e4b 100644 --- a/Examples/REFRESP01 - Referral Service Request Response New Full - ED to 111 Safeguarding DNA Feedback.xml +++ b/Examples/REFRESP01 - Referral Service Request Response New Full - ED to 111 Safeguarding DNA Feedback.xml @@ -348,8 +348,8 @@ - - + + diff --git a/Examples/REFRESP02- Referral Service Request Reponse Short - CAD Mutual Aid Rejection.xml b/Examples/REFRESP02- Referral Service Request Reponse Short - CAD Mutual Aid Rejection.xml index 6d7b325c..db79f09c 100644 --- a/Examples/REFRESP02- Referral Service Request Reponse Short - CAD Mutual Aid Rejection.xml +++ b/Examples/REFRESP02- Referral Service Request Reponse Short - CAD Mutual Aid Rejection.xml @@ -298,8 +298,8 @@ - - + + diff --git a/Examples/REFRESP03 - Referral Service Request Response - CAD Out of Area Response.xml b/Examples/REFRESP03 - Referral Service Request Response - CAD Out of Area Response.xml index 36c4f3ea..2ac324a2 100644 --- a/Examples/REFRESP03 - Referral Service Request Response - CAD Out of Area Response.xml +++ b/Examples/REFRESP03 - Referral Service Request Response - CAD Out of Area Response.xml @@ -289,8 +289,8 @@ - - + + diff --git a/Examples/SERVREQ01 - Service Request Update - Revoked.xml b/Examples/SERVREQ01 - Service Request Update - Revoked.xml index 8595fcd0..d0a1cf5c 100644 --- a/Examples/SERVREQ01 - Service Request Update - Revoked.xml +++ b/Examples/SERVREQ01 - Service Request Update - Revoked.xml @@ -187,7 +187,8 @@ - + + diff --git a/Examples/SERVREQ02 - Service Request Delete - Entered in error.xml b/Examples/SERVREQ02 - Service Request Delete - Entered in error.xml index efa3ed61..cfdb2b33 100644 --- a/Examples/SERVREQ02 - Service Request Delete - Entered in error.xml +++ b/Examples/SERVREQ02 - Service Request Delete - Entered in error.xml @@ -186,7 +186,8 @@ - + + diff --git a/Examples/VALREQ01 - Validation Service Request New Full - 999 to CAS.xml b/Examples/VALREQ01 - Validation Service Request New Full - 999 to CAS.xml index ba612191..b64aeb26 100644 --- a/Examples/VALREQ01 - Validation Service Request New Full - 999 to CAS.xml +++ b/Examples/VALREQ01 - Validation Service Request New Full - 999 to CAS.xml @@ -330,8 +330,8 @@ - - + + diff --git a/Examples/VALREQ02 - Validation Service Request Update Full - 999 to CAS Lower Priority.xml b/Examples/VALREQ02 - Validation Service Request Update Full - 999 to CAS Lower Priority.xml index f8a35e98..d884858e 100644 --- a/Examples/VALREQ02 - Validation Service Request Update Full - 999 to CAS Lower Priority.xml +++ b/Examples/VALREQ02 - Validation Service Request Update Full - 999 to CAS Lower Priority.xml @@ -316,7 +316,8 @@ - + + diff --git a/Examples/VALREQ03 - Validation Service Request New Full AMPDS - 999 to CAS.xml b/Examples/VALREQ03 - Validation Service Request New Full AMPDS - 999 to CAS.xml index 83066536..ce91b50f 100644 --- a/Examples/VALREQ03 - Validation Service Request New Full AMPDS - 999 to CAS.xml +++ b/Examples/VALREQ03 - Validation Service Request New Full AMPDS - 999 to CAS.xml @@ -305,7 +305,8 @@ - + + diff --git a/Examples/VALRESP01 - Validation Response HTTP Response Acknowledgment - CAS to 999 Planned (0 of 2).xml b/Examples/VALRESP01 - Validation Response HTTP Response Acknowledgment - CAS to 999 Planned (0 of 2).xml index f72dc798..3e8e4f04 100644 --- a/Examples/VALRESP01 - Validation Response HTTP Response Acknowledgment - CAS to 999 Planned (0 of 2).xml +++ b/Examples/VALRESP01 - Validation Response HTTP Response Acknowledgment - CAS to 999 Planned (0 of 2).xml @@ -349,7 +349,8 @@ - + + diff --git a/Examples/VALRESP01A - Validation Response New Interim - CAS to 999 In-progress (1 of 2).xml b/Examples/VALRESP01A - Validation Response New Interim - CAS to 999 In-progress (1 of 2).xml index 80c18c89..600a9d88 100644 --- a/Examples/VALRESP01A - Validation Response New Interim - CAS to 999 In-progress (1 of 2).xml +++ b/Examples/VALRESP01A - Validation Response New Interim - CAS to 999 In-progress (1 of 2).xml @@ -272,7 +272,8 @@ - + + diff --git a/Examples/VALRESP01B - Validation Response Update Full - CAS to 999 Finished (2 of 2).xml b/Examples/VALRESP01B - Validation Response Update Full - CAS to 999 Finished (2 of 2).xml index cfbdb844..9eedd3c9 100644 --- a/Examples/VALRESP01B - Validation Response Update Full - CAS to 999 Finished (2 of 2).xml +++ b/Examples/VALRESP01B - Validation Response Update Full - CAS to 999 Finished (2 of 2).xml @@ -361,7 +361,8 @@ - + + diff --git a/Examples/VALRESP02 - Validation Response New Full - CAS to 999 Finished.xml b/Examples/VALRESP02 - Validation Response New Full - CAS to 999 Finished.xml index 4264d83c..0b795362 100644 --- a/Examples/VALRESP02 - Validation Response New Full - CAS to 999 Finished.xml +++ b/Examples/VALRESP02 - Validation Response New Full - CAS to 999 Finished.xml @@ -372,8 +372,8 @@ - - + + diff --git a/Examples/VALRESP03 - Validation Response New Full - CAS to 999 Finished Inc New CADid Cat 1-2.xml b/Examples/VALRESP03 - Validation Response New Full - CAS to 999 Finished Inc New CADid Cat 1-2.xml index 20518e55..d770350d 100644 --- a/Examples/VALRESP03 - Validation Response New Full - CAS to 999 Finished Inc New CADid Cat 1-2.xml +++ b/Examples/VALRESP03 - Validation Response New Full - CAS to 999 Finished Inc New CADid Cat 1-2.xml @@ -413,7 +413,8 @@ - + + diff --git a/Examples/VALRESP04 - Validation Response Interim - Reject Validation Request.xml b/Examples/VALRESP04 - Validation Response Interim - Reject Validation Request.xml index a17a3c77..04b598f2 100644 --- a/Examples/VALRESP04 - Validation Response Interim - Reject Validation Request.xml +++ b/Examples/VALRESP04 - Validation Response Interim - Reject Validation Request.xml @@ -273,7 +273,8 @@ - + + diff --git a/Examples/VALRESP05 - Validation Response - Falls to 999 Finished copy.xml b/Examples/VALRESP05 - Validation Response - Falls to 999 Finished copy.xml index c5071581..e116fa61 100644 --- a/Examples/VALRESP05 - Validation Response - Falls to 999 Finished copy.xml +++ b/Examples/VALRESP05 - Validation Response - Falls to 999 Finished copy.xml @@ -365,8 +365,8 @@ - - + + diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Current-Releases.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Current-Releases.page.md index 86179d39..5cf5a0e4 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Current-Releases.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Current-Releases.page.md @@ -3,7 +3,7 @@ Product Link | Version | Handle | Phase | State | Release Date | Stability | Change Log Link -----------------------|---------|---------|----------|-----------------|--------------|------------|----------------- Implementation Guide | 1.9.0 | v1 | Live | Current Release | 02/07/2025 | Stable |{{pagelink:trn-General}} -[FHIR Package](https://simplifier.net/packages/uk.nhsdigital.bars.r4/1.35.0) | 1.35.0| v1 | Live | Current Release | 01/04/2025 | Stable | +[FHIR Package](https://simplifier.net/packages/uk.nhsdigital.bars.r4/1.35.0) | 1.36.0| v1 | Live | Current Release | 02/07/2025 | Stable | {{pagelink:design-core-1.1.6, text:BaRS Core}} | 1.3.0 | v1 | Live | Current Release | 02/07/2025 | Stable |{{pagelink:trn-core, text: BaRS Core Change Log}} [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0) | 1.3.0 | v1 | Live | Current Release | 02/07/2025 | Stable |{{pagelink:trn-api}} {{pagelink: build-testing, text: TKW}} | 1.0.19 | v1 | Live | Current Release | 28/03/2025 | Stable |{{pagelink:trn-tkw}} @@ -19,8 +19,7 @@ Implementation Guide | 1.9.0 | v1 | Live | Current Release | 02/07/ ### Overview of the release -Release 1.9.0 includes development of the {{pagelink:, text:}} guidance and supporting changes to the cancellation workflows, introduces a search capability to the Implementation Guide and.... -There have been improvements Application 6 use-case descriptons alongside bug fixes and corrections throughout the guide. +Release 1.9.0 includes development of changes and guidance to the cancellation workflows {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}} to support searches with demographics. Following user feedback, it also introduces a search capability to the Implementation Guide and simplifies versioning by reducing the concurrent versions of Core from three to two: 1.0.7 and 1.3.0. There have been improvements to Help and Support, Application 6 use-case descriptions alongside bug fixes and corrections throughout the guide. A clinical safety assessment of the scope of this release has determined that it has not significantly changed the clinical safety profile of the BaRS. No new hazards have been identified in this release. The latest version of the BaRS clinical safety case and hazard log can be downloaded from the  BaRS FHIR API onboarding support information page . diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP1/1.0.8.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP1/1.0.8.page.md index 01d5aced..f895401a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP1/1.0.8.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP1/1.0.8.page.md @@ -11,6 +11,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| | Implementation Guidance updated | encounter.class.display value corrected from "Emergency" to "emergency" | correction | |NHSD-Requesting-Practioner Examples updated | FHIRPractioner corrected to FHIRPractionerRole | correction | +| Simplified cancellation guidance | Updated cancellation guidance, for bookings and referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. | non-breaking | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP3/1.0.4.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP3/1.0.4.page.md index 9332c743..a6f5f110 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP3/1.0.4.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP3/1.0.4.page.md @@ -10,6 +10,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati | Change | Description | Impact | |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| | Implementation Guidance updated | patient.identifier.system Implementaton Guidance corrected | correction | +| Simplified cancellation guidance | Updated cancellation guidance, for referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. | non-breaking | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP4/1.2.3.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP4/1.2.3.page.md index 3c0083eb..0dcfac4c 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP4/1.2.3.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP4/1.2.3.page.md @@ -10,6 +10,10 @@ This is a minor "patch" with clarifications to limited areas of the Implementati | Change | Description | Impact | |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| | Implementation Guidance updated | patient.identifier.system Implementaton Guidance corrected | correction | +| Simplified cancellation guidance | Updated cancellation guidance, for validations, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. | non-breaking | +| Clarified cancellation payload guidance | Updated cancellation guidance, for validation, under 'Payloads for Requestors', clarifying a Validation can be considered as a type of 'referral' when reading Standard Pattern documentation. | non-breaking | + + diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP5/1.1.3.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP5/1.1.3.page.md index 96e1ab04..eba4a19a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP5/1.1.3.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP5/1.1.3.page.md @@ -16,6 +16,7 @@ This stable release (v1.1.3) of Application 5 sees minor corrections. | SNOMED Code Updated | The SNOMED Code used to define a minor illness referral has been updated from '1577041000000100-Community Pharmacist Consultation Service for minor illness (procedure)' to '2140231000000104-Referral to Community Pharmacy Pharmacy First Service (procedure)', as requested by Pharmacy First Programme Clinical Lead | correction | | Implementation Guidance updated | encounter.class.display value corrected from "Emergency" to "emergency" | correction | |NHSD-Requesting-Practioner Examples updated | FHIRPractioner corrected to FHIRPractionerRole | correction | +| Simplified cancellation guidance | Updated cancellation guidance, for referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. | non-breaking | ### Payload Change Log diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.5.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.5.page.md index 5d768935..a645d762 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.5.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.5.page.md @@ -10,7 +10,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati | Change | Description | Impact | |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| | Implementation Guidance updated | patient.identifier.system Implementaton Guidance corrected | correction | - +| Simplified cancellation guidance | Updated cancellation guidance, for bookings referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. | non-breaking | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP7/1.0.0-alpha.4.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP7/1.0.0-alpha.4.page.md index 80da906b..1e72fa3b 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP7/1.0.0-alpha.4.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP7/1.0.0-alpha.4.page.md @@ -10,8 +10,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati | Change | Description | Impact | |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| |NHSD-Requesting-Practioner Examples updated | FHIRPractioner corrected to FHIRPractionerRole | correction | - - +| Simplified cancellation guidance | Updated cancellation guidance, for bookings, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. | non-breaking | ### Payload Change Log diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md index f26c0deb..17800b2d 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md @@ -29,7 +29,7 @@ This payload is used to support a booking workflow and contains all the required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 1..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md index f516e179..ed4bcca7 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md @@ -15,7 +15,7 @@ To support the workflows for this Application of the standard the operations tha Making a referral for this Application follows the {{pagelink:core-SPComposites-1.3.0, text:standard pattern for BaRS composite operations}}. -The message definition that defines this payload for this Application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}} +The Message Definition that defines this payload for this Application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}} @@ -86,15 +86,13 @@ X-Correlation-Id = ### Cancel a Referral -To cancel a referral this Application follows the {{pagelink:core-SPComposites-1.3.0, text:standard pattern for BaRS composite operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the referral from the **receiver** as it may have changed locally. This is done by performing a "GET ServiceRequest by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy). +To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. -The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern}}. +The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} -The message definition that defines this payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} +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. -As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed. This is always defined within the relevent message definition. - -In addition the specific workflow parameters that are required are as follows: +In addition, the specific workflow parameters that are required are as follows:
@@ -251,7 +249,7 @@ X-Correlation-Id = Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}}. -The message definition that defines this payload for this Application is: [BARS Message Definition - Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-bars-messagedefinition-booking-request) +The Message Definition that defines this payload for this Application is: [BARS Message Definition - Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-bars-messagedefinition-booking-request) In addition to that the specific workflow parameters that are required are as follows: @@ -310,14 +308,12 @@ X-Correlation-Id = ``` ### Cancel a Booking -To cancel a booking this Application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the booking from the **receiver** as it may have changed locally. This is done by performing a "GET Appointment by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy). - -The response to this request will be the requested Appointment resource which should be checked for its current status to ensure it does not already have a status of "cancelled". If not, this version of the Appointment should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern}}. +To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. -The message definition that defines this payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled) +The Message Definition that defines the payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled) +If the update-to-cancel is taking place as part of a re-book routine, once the cancellation is complete, the new booking request can be sent. This step in the workflow would follow the same process as 'Make a Booking' detailed above. -As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed. This is always defined within the relevent message definition. In addition the specific workflow parameters that are required are as follows: diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md index db06533b..7ee66274 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md @@ -25,7 +25,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | | MUST | 0..1 | | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md index 505d44f0..4c0db6a4 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md @@ -25,7 +25,7 @@ Here is some placeholder text for the service request payload for this Applicati | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 1..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md index 78d225f7..e13da39f 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md @@ -25,11 +25,11 @@ This payload is used to support a booking workflow and contains all the required | Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | -|------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| +|------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|1.0.0-beta ------------------------------------------------------------------------------------------| | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 1..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Referral-Payload.page.md index da178b06..7abb1335 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Referral-Payload.page.md @@ -26,7 +26,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | |1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md index 15d3ec80..f6f0d1e5 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md @@ -32,7 +32,7 @@ To support the workflows for this application of the standard the operations tha Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}}. -The message definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}} +The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}

In addition to that the specific workflow parameters that are required are as follows: @@ -102,15 +102,11 @@ X-Correlation-Id = ### Cancel a Referral -To cancel a referral this application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, 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. This is done by performing a "GET ServiceRequest by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy). +To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. -The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked" or "completed". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:core-standardpattern-1.3.0, text:standard pattern}}. +The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} -The message definition that defines this payload for this application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} - -As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed, **should** be include. This is always defined within the relevent message definition. - -If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral message can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above. +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: diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Referral-Payload.page.md index 7c062b49..5fc02265 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Referral-Payload.page.md @@ -31,7 +31,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md index 37fd5a2e..f98155d1 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md @@ -70,7 +70,7 @@ To support the workflows for this application of the standard the operations tha Making a Validation Request for this application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}}. -The message definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Validation}} +The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Validation}}


@@ -142,15 +142,11 @@ X-Correlation-Id = ## Cancel Validation Request -To cancel a Validation Request this application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as described on the linked section, 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 or completed. This is done by performing a "GET ServiceRequest by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy). +To cancel a Validation Request this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. -The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked" or "completed". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:core-standardpattern-1.3.0, text:standard pattern}}. +The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} -The message definition that defines this payload for this application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} - -As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed, **should** be included. This is always defined within the relevant message definition. - -If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral message can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above. +If the update-to-cancel is taking place as part of a resend validation routine, once the cancellation is complete, the new validation request can be sent. This step in the workflow would follow the same process as 'Make a Validation Request' detailed above. In addition the specific workflow parameters that are required are as follows: diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Interim-Validation-Response-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Interim-Validation-Response-Payload.page.md index 9a3d0355..b9abbd9b 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Interim-Validation-Response-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Interim-Validation-Response-Payload.page.md @@ -33,7 +33,7 @@ This payload is used to inform the Requester that the validation assessment has | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md index 53c42366..52de63fb 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md @@ -102,7 +102,7 @@ The level of consent currently supported by BaRS is for 'Direct Care' only. In e ## Validation Cancellation Payload -The ability to cancel a Validation Request is a core workflow in BaRS. For details on the use of the standard pattern for cancellation please see the following {{pagelink:core-SPCancellation-1.3.0, text:Standard Patterns - Cancellation}}. +The ability to cancel a Validation Request is a core workflow in BaRS. For details on the use of the standard pattern for cancellation please see the following {{pagelink:core-SPCancellation-1.3.0, text:Standard Patterns - Cancellation}}. A Validation can be considered a type of 'referral' when reading the guidance.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Request-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Request-Payload.page.md index e73dae8b..17a8c412 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Request-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Request-Payload.page.md @@ -30,7 +30,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Response-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Response-Payload.page.md index 2a3a6db5..fc264548 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Response-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Validation-Response-Payload.page.md @@ -30,7 +30,7 @@ This payload is used to transmit the outcome of the validation assessment back t | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md index 9de967c0..e59a6f3e 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md @@ -164,7 +164,7 @@ When a service is chosen, the "Service ID" field in the DOS data will be used as Making a referral for this application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}}. -The message definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}} +The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}


@@ -236,15 +236,11 @@ X-Correlation-Id = ### Cancel a Referral -To cancel a referral this application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, 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. This is done by performing a "GET ServiceRequest by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy). +To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. -The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked" or "completed". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:core-standardpattern-1.3.0, text:standard pattern}}. +The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} -The message definition that defines this payload for this application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} - -As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed, **should** be include. This is always defined within the relevent message definition. - -If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral message can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above. +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: diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Referral-Payload.page.md index e7fc88fe..a124af7b 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Referral-Payload.page.md @@ -28,10 +28,9 @@ This payload is used to transmit all the necessary information that is required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | -| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | | Bundle.timestamp | the date that the content of the message was assembled. This date is not changed by middleware engines unless they add additional data that changes the meaning of the time of the message | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.entry(s) | Follow BaRS profile guidance for populating this element | MUST | 1..* | | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md index ba9fcd3a..1f4bc5da 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md @@ -120,7 +120,7 @@ To support the workflows for this application of the standard the operations tha Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}}. -The message definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}} +The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}

In addition to that the specific workflow parameters that are required are as follows: @@ -190,15 +190,11 @@ X-Correlation-Id = ### Cancel a Referral -To cancel a referral this application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as described on the linked section, 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. This is done by performing a "GET ServiceRequest by ID" call to the **Receiving** system's corresponding API endpoint (via the BaRS proxy). +To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. -The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked" or "completed". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:core-standardpattern-1.3.0, text:standard pattern}}. +The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} -The message definition that defines this payload for this application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}} - -As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed, **should** be include. This is always defined within the relevant message definition. - -If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral message can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above. +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: diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Referral-Payload.page.md index 699633e4..93188b30 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Referral-Payload.page.md @@ -30,7 +30,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | The Bundle resource is the container for the event message  https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Response-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Response-Payload.page.md index 0e0464ab..1e5849d2 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Response-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Response-Payload.page.md @@ -36,7 +36,7 @@ ONLY) | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md index 2af8e443..ad57f787 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md @@ -29,7 +29,7 @@ This payload is used to support a booking workflow and contains all the required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md index 25d3e2d6..4d91b503 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md @@ -80,7 +80,7 @@ X-Correlation-Id = Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}}. -The message definition that defines this payload for this Application is: [BARS Message Definition - Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-bars-messagedefinition-booking-request) +The Message Definition that defines this payload for this Application is: [BARS Message Definition - Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-bars-messagedefinition-booking-request) In addition to that the specific workflow parameters that are required are as follows: @@ -146,14 +146,11 @@ This diagram illustrates the workflow and interactions of a booking cancellation -To cancel a booking this Application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the booking from the **receiver** as it may have changed locally. This is done by performing a "GET Appointment by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy). +To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. -The response to this request will be the requested Appointment resource which should be checked for its current status to ensure it does not already have a status of "cancelled". If not, this version of the Appointment should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern}}. +The Message Definition that defines the payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled) -The message definition that defines this payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled) - - -As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource is altered. Any resources that are mandated due to contextual, linking or referential integrity reasons play a supporting role, although any resources that include elements that are being changed are included too. This is always defined within the relevant message definition. +If the update-to-cancel is taking place as part of a re-book routine, once the cancellation is complete, the new booking request can be sent. This step in the workflow would follow the same process as 'Make a Booking' detailed above. In addition the specific workflow parameters that are required are as follows: diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/Index.page.md index f65b2fb7..b557cfe7 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/Index.page.md @@ -19,11 +19,11 @@ These guides are designed to be used in conjunction with the documentation for { | Application | Use Cases | Current Release | Minimum API Spec | Minimum Core Version | | ----------------------------------------------------------------------------|--------------------------------------------------------------- | --------------- | --------------- | --------------- | -| {{pagelink:application1, text:Booking and Referrals into UEC (Application 1)}} |

111 - ED
111 - UTC
CAS - ED
CAS - UTC
999 - ED
999 - UTC
111 - SDEC
CAS - SDEC
999 - SDEC

| 1.0.7 | v1.0.0 | v1.0.0 | -| {{pagelink:application2, text: Booking and Referrals into UEC (Application 2)}} |

111 Online - ED
111 Online - UTC
S&R - ED
S&R - UTC

| 1.0.7 | v1.0.0 | v1.0.0 | -| {{pagelink:application3, text: Referral into UEC (Application 3)}} |

999-CAS Referral
| 1.0.3 | v1.0.0 | v1.0.0 | -| {{pagelink:application4, text: Referral into UEC for Validation (Application 4)}} |

999-CAS Validation

999 AST to Falls Lifting Service

999 AST to Community Services
| 1.2.2 | v1.0.0 | v1.0.0 | -| {{pagelink:application5, text: Referrals into Pharmacy (Application 5)}} |

Primary Care to Community Pharmacy (Pharmacy First)

Primary Care to Pharmacy Contraception (Oral Contraception)

Primary Care to Pharmacy Blood Pressure Check Service
| 1.1.2 | v1.1.0 | {{pagelink:design-core-1.3.0, text:v1.1.0}} | +| {{pagelink:application1, text:Booking and Referrals into UEC (Application 1)}} |

111 - ED
111 - UTC
CAS - ED
CAS - UTC
999 - ED
999 - UTC
111 - SDEC
CAS - SDEC
999 - SDEC

| 1.0.8 | v1.0.0 | v1.0.0 | +| {{pagelink:application2, text: Booking and Referrals into UEC (Application 2)}} |

111 Online - ED
111 Online - UTC
S&R - ED
S&R - UTC

| 1.0.8 | v1.0.0 | v1.0.0 | +| {{pagelink:application3, text: Referral into UEC (Application 3)}} |

999-CAS Referral
| 1.0.4 | v1.0.0 | v1.0.0 | +| {{pagelink:application4, text: Referral into UEC for Validation (Application 4)}} |

999-CAS Validation

999 AST to Falls Lifting Service

999 AST to Community Services
| 1.2.3 | v1.0.0 | v1.0.0 | +| {{pagelink:application5, text: Referrals into Pharmacy (Application 5)}} |

Primary Care to Community Pharmacy (Pharmacy First)

Primary Care to Pharmacy Contraception (Oral Contraception)

Primary Care to Pharmacy Blood Pressure Check Service
| 1.1.3 | v1.1.0 | {{pagelink:design-core-1.3.0, text:v1.1.0}} |


diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md index 9c93c1f2..6a6877b7 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md @@ -14,8 +14,8 @@ These guides are designed to be used in conjunction with the documentation for { | Application | Use Cases | Current Release | API Specification | Core Version | | ----------------------------------------------------------------------------|--------------------------------------------------------------- | --------------- | --------------- | --------------- | -| {{pagelink:application6, text: Referrals into an Ambulance Service Trust (Application 6)}} |

CAD to CAD Out of Area Referral
CAD to CAD Call Assist Request
CAD to CAD Mutual Aid Request | 1.0.0-beta.4 | API Spec v1.1.0 and above | {{pagelink:design-core-1.1.4, text:Core v1.1.0 and above}} | -| {{pagelink:application7, text: Bookings into GP Practice (Application 7)}} |

Appointments for Patient facing services into GP Practice | 1.0.0-alpha.3 | API Spec v1.1.0 and above | {{pagelink:design-core-1.1.4, text:Core v1.1.0 and above}} | +| {{pagelink:application6, text: Referrals into an Ambulance Service Trust (Application 6)}} |

CAD to CAD Out of Area Referral
CAD to CAD Call Assist Request
CAD to CAD Mutual Aid Request | 1.0.0-beta.5 | API Spec v1.1.0 and above | {{pagelink:design-core-1.1.4, text:Core v1.1.0 and above}} | +| {{pagelink:application7, text: Bookings into GP Practice (Application 7)}} |

Appointments for Patient facing services into GP Practice | 1.0.0-alpha.4 | API Spec v1.1.0 and above | {{pagelink:design-core-1.1.4, text:Core v1.1.0 and above}} | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Cancellation.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Cancellation.page.md index 6e9a88e2..55c98fb7 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Cancellation.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/Standard-Pattern-Composite-Messages/Cancellation.page.md @@ -57,7 +57,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | The Bundle resource is the container for the event message  https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 1..1 | | +| Bundle.meta.versionId | | MUST | 0..1 | | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/Logging.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/Logging.page.md index f82ac3f8..b7bc0ed6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/Logging.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/Logging.page.md @@ -22,7 +22,7 @@ The elements for a ServiceRequest are: The elements for an Appointment are: -* Appointent.serviceCategory.coding (usecases-categories-bars) +* Appointment.serviceCategory.coding (usecases-categories-bars) * Appointment.status * MessageHeader.eventCoding.code (message-event-bars) * MessageHeader.reason.coding.code (message-reason-bars) @@ -42,7 +42,7 @@ Example: ### Booking ``` - Appointent.serviceCategory.coding[usecases-categories-bars] | Appointment.status | MessageHeader.eventCoding.code | MessageHeader.reason.coding.code + Appointment.serviceCategory.coding[usecases-categories-bars] | Appointment.status | MessageHeader.eventCoding.code | MessageHeader.reason.coding.code ``` Example: ``` diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md index f5de480d..25dc3dac 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md @@ -11,7 +11,7 @@ You will find here a set of documentation, specifications and services that desc

> Expand for full Core directory -• {{pagelink:design-core-1.0.7 , text: Core 1.0.6}}
+• {{pagelink:design-core-1.0.7 , text: Core 1.0.7}}
  • {{pagelink:core-EndToEndWorkflow-1.0.7 , text:End to end workflow}}
    • {{pagelink:core-EndToEndWorkflow-ServiceDiscovery-1.0.7 , text:Service Discovery}}
    • {{pagelink:core-EndToEndWorkflow-BaRSAuth-1.0.7 , text:Authenticate with BaRS}}
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Standard-Pattern-Composite-Messages/Cancellation.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Standard-Pattern-Composite-Messages/Cancellation.page.md index 0277191c..88f82480 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Standard-Pattern-Composite-Messages/Cancellation.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Standard-Pattern-Composite-Messages/Cancellation.page.md @@ -327,6 +327,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | The Bundle resource is the container for the event message  https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under meta section which must be the same timestamp for each resource when created from new, but must be a later timestamp on updates, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 1..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This must be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/Logging.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/Logging.page.md index 07074fbb..60590682 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/Logging.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/Logging.page.md @@ -22,7 +22,7 @@ The elements for a ServiceRequest are: The elements for an Appointment are: -* Appointent.serviceCategory.coding (usecases-categories-bars) +* Appointment.serviceCategory.coding (usecases-categories-bars) * Appointment.status * MessageHeader.eventCoding.code (message-event-bars) * MessageHeader.reason.coding.code (message-reason-bars) @@ -42,7 +42,7 @@ Example: ### Booking ``` - Appointent.serviceCategory.coding[usecases-categories-bars] | Appointment.status | MessageHeader.eventCoding.code | MessageHeader.reason.coding.code + Appointment.serviceCategory.coding[usecases-categories-bars] | Appointment.status | MessageHeader.eventCoding.code | MessageHeader.reason.coding.code ``` Example: ``` diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md index 4dd1d828..4a3475b9 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md @@ -3,9 +3,6 @@ topic: design-core-1.3.0 ---