+
+ +
+
+ + + +
+
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/API-Spec-Change-Log/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/API-Spec-Change-Log/toc.yaml index b4aa6d5d..2907f26d 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/API-Spec-Change-Log/toc.yaml +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/API-Spec-Change-Log/toc.yaml @@ -2,6 +2,8 @@ filename: Index.page.md - name: Global filename: Global.page.md +- name: 1.4.1 + filename: 1.4.1.page.md - name: 1.4.0 filename: 1.4.0.page.md - name: 1.3.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.4.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.4.0.page.md index 4318fd11..391947e9 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.4.0.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.4.0.page.md @@ -2,13 +2,17 @@ topic: TRN-Core-1.4.0 --- +
-### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.4.1.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.4.1.page.md new file mode 100644 index 00000000..f5ad8847 --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.4.1.page.md @@ -0,0 +1,14 @@ +--- +topic: TRN-Core-1.4.1 +--- + +## {{page-title}} + +| Change | Description | Impact | +|------------------------------------------|----------------------------------------|---------------------------------| +| API version increment | API Spec version incremented from v1.4.0 to v1.4.1 | Non-breaking | + +
+
+ +### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml index 20a73de4..e6607ee7 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/toc.yaml @@ -1,5 +1,7 @@ - name: Index filename: Index.page.md +- name: 1.4.1 + filename: 1.4.1.page.md - name: 1.4.0 filename: 1.4.0.page.md - name: 1.3.1 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.11.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.11.0.page.md index 0e3768e2..75accbc6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.11.0.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.11.0.page.md @@ -1,3 +1,7 @@ + +
-### Previous Releases + diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.11.1.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.11.1.page.md new file mode 100644 index 00000000..c4a46105 --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.11.1.page.md @@ -0,0 +1,13 @@ +### 1.11.1 + +## Implementation Guide Changes + +| Change | Description | +|---------------------------------------|---------------------------------------------------------------------------------------------------------| +| Bug fixes and corrections |There have been several bug fixes and corrections in the guide, these includes typos, broken links or corrections.| +| About BaRS renamed to Analysis |Following user research into the experience of using the Implementation Guide, About BaRS is renamed Analysis to support users to locate information they need.| + +
+
+ +### Previous Releases diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/toc.yaml index 58d65f6b..5d0a9935 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/toc.yaml +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/toc.yaml @@ -1,5 +1,7 @@ - name: Index filename: Index.page.md +- name: 1.11.1 + filename: 1.11.1.page.md - name: 1.11.0 filename: 1.11.0.page.md - name: 1.10.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.7.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.7.page.md index b5fb41b3..0f8b01a6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.7.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.7.page.md @@ -1,3 +1,6 @@ + +
-### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.8.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.8.page.md new file mode 100644 index 00000000..492d393b --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.8.page.md @@ -0,0 +1,27 @@ +## {{page-title}} +This is a minor "patch" with clarifications to limited areas of the Implementation Guidance and examples for v1.0.0-beta.8 + +### Application Change Log + + +
+ + +| Change | Description | Impact | +|-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| +| +| Implementation guidance updated | patient.id implementation guidance corrected | correction | + + +### Payload Change Log + + +| FHIR Element | Previous | Current | Other | Referral/Booking | Rationale | Impact | +|------------------------------------------------------|----------|------------|---------|------------------|-------------------------------------------------------------------------------------------------|----------| +| tbc | tbc | tbc | Update | Referral Request |Bug fix | correction | + + +
+
+ +### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/toc.yaml index b84064b5..8af32737 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/toc.yaml +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP6/toc.yaml @@ -1,5 +1,7 @@ - name: Index filename: Index.page.md +- name: 1.0.0-beta.8 + filename: 1.0.0-beta.8.page.md - name: 1.0.0-beta.7 filename: 1.0.0-beta.7.page.md - name: 1.0.0-beta.6 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.2.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.2.page.md new file mode 100644 index 00000000..eba5b4e9 --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.2.page.md @@ -0,0 +1,24 @@ +## {{page-title}} + + +This is a pre-release of v1.0.0-alpha.2 - Referrals into a broker for Healthcare Service selection + +
+ + +### Application Change Log + + +| Change | Description | Impact | +|-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| +| Application 8 released | Referrals into a broker for Healthcare Service selection| | + +### Payload Change Log + + +| FHIR Element | Previous | Current | Other | Referral/Booking | Rationale | Impact | +|------------------------------------------------------|----------|------------|---------|------------------|-------------------------------------------------------------------------------------------------|----------| +| | | | | | | | + +
+
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/toc.yaml index e6ac267d..4b623dd6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/toc.yaml +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/toc.yaml @@ -1,4 +1,6 @@ - name: Index filename: Index.page.md +- name: 1.0.0-alpha.2 + filename: 1.0.0-alpha.2.page.md - name: 1.0.0-alpha filename: 1.0.0-alpha.page.md diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md index 2c793779..ba4ff6f6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md @@ -24,7 +24,7 @@ The extensions ALPHA, BETA or RC (Release Candidate) will be used to indicate th An appreciation of the components involved in a released version must be understood when building solutions. These separate components come together under the umbrella of a given overall version but the components themselves are also versioned. This published implementation guide denotes the 'overall version' referenced. Components involved in an overall version:- -* **{{pagelink:design-core-1.4.0, text:Core}}**: BaRS Core components - API Spec, Endpoint Catalogue etc. +* **{{pagelink:design-core-1.4.1, text:Core}}**: BaRS Core components - API Spec, Endpoint Catalogue etc. * **[Package](https://simplifier.net/NHSBookingandReferrals/~packages)**: FHIR package * **{{pagelink:applications, text:Application}}**: the use cases i.e. '111 to ED' * **{{pagelink:fhir_assets, text:FHIR Assets}}**: MessageDefinitions and profiles 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 8bc9ee26..a4db5c9d 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 @@ -13,7 +13,7 @@ To support the workflows for this Application of the standard the operations tha ### Make a Referral -Making a referral for this Application follows the {{pagelink:core-SPComposites-1.4.0, text:standard pattern for BaRS composite operations}}. +Making a referral for this Application follows the {{pagelink:core-SPComposites-1.4.1, 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}} @@ -86,7 +86,7 @@ X-Correlation-Id =
### Error Handling -* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}} +* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional -* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}} +* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md index e13ae3c7..f9526996 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md @@ -13,7 +13,7 @@ To support the workflows for this Application of the standard the operations tha ### Make a Referral -Making a referral for this Application follows the {{pagelink:core-standardpattern-1.4.0, text:standard pattern for BaRS Composite Messages}}. +Making a referral for this Application follows the {{pagelink:core-standardpattern-1.4.1, text:standard pattern for BaRS Composite Messages}}. The message definition that defines this payload for this Application is: {{link:https://fhir.nhs.uk/MessageDefinition/bars-message-servicerequest-request-referral}} @@ -140,7 +140,7 @@ X-Correlation-Id =
### Error Handling -* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}} +* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional -* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}} +* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
\ No newline at end of file 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 c56c0b2a..af695c9d 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 @@ -30,7 +30,7 @@ To support the workflows for this application of the standard the operations tha ### Make a Referral -Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.4.0, text:standard pattern for BaRS Composite Messages}}. +Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.4.1, text:standard pattern for BaRS Composite Messages}}. The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
@@ -102,7 +102,7 @@ X-Correlation-Id =
@@ -142,7 +142,7 @@ X-Correlation-Id =
@@ -236,7 +236,7 @@ X-Correlation-Id =
@@ -190,7 +190,7 @@ X-Correlation-Id =
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md
index 607d4250..5d89bce5 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Index.page.md
@@ -21,10 +21,10 @@ topic: Application8
111 Online - ED | 2.0.0 | v1.0.0 | v1.0.0 |
| {{pagelink:application3, text: Referral into UEC (Application 3)}} | 999-CAS Referral 999-CAS Validation 999 AST to Falls Lifting Service 999 AST to Community Services Primary Care to Community Pharmacy (Pharmacy First) Primary Care to Pharmacy Contraception (Oral Contraception) Primary Care to Pharmacy Blood Pressure Check Service Primary Care to Community Pharmacy (Pharmacy First) Primary Care to Pharmacy Contraception (Oral Contraception) Primary Care to Pharmacy Blood Pressure Check Service
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Scope-and-Requirements.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Scope-and-Requirements.page.md
index dd1638a6..f082c06f 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Scope-and-Requirements.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Scope-and-Requirements.page.md
@@ -56,15 +56,15 @@ The payloads and workflow have been designed to support these services. Other {{
* The referral Receiver **must** clearly identify any included safeguarding concern to the end user
* The referral Receiver **must** accurately represent information made by the Sender to the end user
* The referral Sender **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
-* Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-* Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+* Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+* Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
**Update referral**
* The referral Sender **must** be capable of updating any referral made by them, within the current consultation or after the consultation event
* The referral Sender **must** retrieve the referral to be updated from the referral Receiver prior to update to ensure they are working with the most up-to date version and it has not already been completed
* The referral Sender **must** provide visible confirmation to the end user of the status returned by the referral Receiver, i.e. whether the original referral was successfully updated or not
-* Where the update was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-* Where the update was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+* Where the update was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+* Where the update was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
* The referral Receiver **must** store all previous versions of the referral
* The referral Receiver **must not** be required to inform the patient of the updating of the referral. Business/clinical responsibility for informing the patient must remain with the referral Sender
@@ -73,8 +73,8 @@ The payloads and workflow have been designed to support these services. Other {{
* The referral Sender **must** be capable of cancelling any referral made by them, within the current consultation or after the consultation event
* The referral Sender **must** retrieve the referral to be cancelled from the referral Receiver prior to cancellation to ensure they are working with the most up-to date version and it has not already been completed
* The referral Sender **must** provide visible confirmation to the end user of the status returned by the referral Receiver, i.e. whether the original referral was successfully cancelled or not
-* Where the cancellation was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-* Where the cancellation was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+* Where the cancellation was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+* Where the cancellation was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
* The referral Receiver **must** store all previous versions of the referral
* The referral Receiver **must not** be required to inform the patient of the cancellation of the referral. Business/clinical responsibility for informing the patient must remain with the referral Sender
@@ -106,11 +106,11 @@ The payloads and workflow have been designed to support these services. Other {{
### Error Handling
-* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}}
+* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional
-* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}}
+* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
\ No newline at end of file
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 b40c2603..fe46487f 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
@@ -68,7 +68,7 @@ To support the workflows for this application of the standard the operations tha
## Make a Validation Request
-Making a Validation Request for this application follows the {{pagelink:core-standardpattern-1.4.0, text:standard pattern for BaRS Composite Messages}}.
+Making a Validation Request for this application follows the {{pagelink:core-standardpattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Validation}}
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md
index 9baa15c4..17617880 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md
@@ -17,7 +17,7 @@ For Interim Validation Response example bundles see:
### MessageHeader Resource
-For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.0, text:Standard Pattern - Message Header}}.
+For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.1, text:Standard Pattern - Message Header}}.
The MessageHeader resource in the Interim Validation Response should have the following resource elements set as follows:
* **MessageHeader.eventCoding** - **must** be populated with 'servicerequest-response'
@@ -66,7 +66,7 @@ example bundles see:
* For additional example bundles please check [BaRS Example Bundles](https://simplifier.net/nhsbookingandreferrals/~resources?category=Example&exampletype=Bundle&sortBy=LastUpdateDate_desc)
### MessageHeader Resource
-For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.0, text:Standard Pattern - Message Header}} for more information.
+For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.1, text:Standard Pattern - Message Header}} for more information.
The MessageHeader resource in the Interim Validation Response should have the following resource elements set as follows:
* **MessageHeader.eventCoding** - **must** be populated with 'servicerequest-response'
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Scope-and-Requirements.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Scope-and-Requirements.page.md
index e9f139d8..463baf39 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Scope-and-Requirements.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Scope-and-Requirements.page.md
@@ -79,14 +79,14 @@ For this application we will be referring to the actors as 'Requester' and the '
* The Responder **must** clearly identify any included safeguarding concern to the end user
* The Responder **must** accurately represent information made by the Sender to the end user
* The Requester **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
-* Where the Validation Request was not successful, the Responder **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail
-* Where the Validation Request was not successful, the Requester **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail
+* Where the Validation Request was not successful, the Responder **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail
+* Where the Validation Request was not successful, the Requester **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail
**Update Validation Request**
* The Requester **must** be capable of updating any Validation Request made by them, within the current consultation or after the consultation event
* The Requester **must** retrieve the Validation Request to be updated from the Responder prior to update, to ensure they are working with the most up-to date version and the validation request has not already been completed, or is at a point in the workflow where it must not be updated
* The Requester **must** provide visible confirmation of the status returned by the Responder to the end-user, i.e. whether the original Validation Request was successfully updated or not
-* If the update fails, the Responder **must** respond with the most appropriately aligned error. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail
+* If the update fails, the Responder **must** respond with the most appropriately aligned error. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail
* The Responder **must** store all previous versions of the Validation Request
* The Requester **must not** be required to inform the patient of the updating of the Validation Request. Business/clinical responsibility for informing the patient must remain with the Requester
* The Requester **should not** send updates after receiving an Interim Response
@@ -147,11 +147,11 @@ For this application we will be referring to the actors as 'Requester' and the '
### Error Handling
-* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}}
+* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional
-* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}}
+* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
\ No newline at end of file
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 0d8393d5..bee92c9d 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
@@ -162,7 +162,7 @@ When a service is chosen, the "Service ID" field in the DOS data will be used as
### Make a Referral
-Making a referral for this application follows the {{pagelink:core-standardpattern-1.4.0, text:standard pattern for BaRS Composite Messages}}.
+Making a referral for this application follows the {{pagelink:core-standardpattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Payloads.page.md
index 0901b80b..8af112ce 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Payloads.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Payloads.page.md
@@ -5,7 +5,7 @@ topic: APP5-Payloads
## {{page-title}}
### MessageHeader Resource
-{{pagelink:core-SPMessageHeader-1.4.0, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
+{{pagelink:core-SPMessageHeader-1.4.1, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
The MessageHeader resource for the Referral Request should have the following resource elements set as follows:
* **MessageHeader.eventCoding** - **must** be populated with 'servicerequest-request'
@@ -20,7 +20,7 @@ There are two *coding* entries within *ServiceRequest.category* which are key to
1. Denotes the type of referral e.g. Transfer of care
2. Denotes the use case and must be populated with the relevant use case from [use-case CodeSystem](
https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars
-). e.g. Primary Care to Community Pharmacy. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.0, text:use-case categories}}
+). e.g. Primary Care to Community Pharmacy. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.1, text:use-case categories}}
*Please note that the use-case category 'referraltopharmacy' is now deprecated to allow for more granular use cases.*
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Scope-and-Requirements.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Scope-and-Requirements.page.md
index f502d9c3..aa6334bd 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Scope-and-Requirements.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Scope-and-Requirements.page.md
@@ -64,15 +64,15 @@ The payload and workflow have been designed to support this service. Other {{pag
- The referral Sender **should** include the service type when requesting a Blood Pressure service e.g. single check or monitoring over a period (ABPM)
- The referral Sender **should** include the current oral contraception medication a patient is prescribed when requesting a Oral Contraception service, if requesting ongoing (repeat) supply
- The referral Sender **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user so they can share with the patient/third party
-- Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-- Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+- Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+- Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
- Update to amend a referral request is not supported. If a referral Sender wishes to change information in a request they **must** follow the re-refer workflow
**Cancel referral**
- The referral Sender **must** be capable of cancelling any referral made by them, within the current consultation or after the consultation event
- 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
-- Where the cancellation was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-- Where the cancellation was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+- Where the cancellation was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+- Where the cancellation was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
- The referral Receiver **must** store all previous versions of the referral
- The referral Receiver **must not** be required to inform the patient of the cancellation of the referral. Business/clinical responsibility for informing the patient remains with the referral Sender
@@ -80,8 +80,8 @@ The payload and workflow have been designed to support this service. Other {{pag
- The referral Sender **must** be capable of re-referring within the current consultation or after the consultation event
- If the patient recontacts the sending service after the sender's consultation has been completed, the patient **should** be reassessed prior to attempting to re-refer
- The referral Sender **should** revoke the original referral prior to making a re-referral, whether within the current consultation or after the consultation event
-- Where the re-referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-- Where the re-referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+- Where the re-referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+- Where the re-referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
- The referral Receiver **must not** be required to inform the patient of the cancellation, incurred as part of the re-refer process. Business/clinical responsibility for informing the patient remains with the referral Sender
**Contacts**
@@ -99,9 +99,9 @@ The payload and workflow have been designed to support this service. Other {{pag
### Error Handling
-- Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}}
+- Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional
-- Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}}
+- Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
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 83593c16..85750b0c 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
@@ -92,7 +92,7 @@ Note: The BaRS Referral may be used to support single patient Mutual aid request
- The referral Receiver's CAD will create a new case (Encounter) on receipt of the BaRS Referral and populate it with the patient and clinical details provided in the referral
### Acknowledge Receipt
-- The referral Receiver will send an acknowledgement back to the referral Sender, when it has successfully processed the payload. If it fails to do this it will send a BaRS error code. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+- The referral Receiver will send an acknowledgement back to the referral Sender, when it has successfully processed the payload. If it fails to do this it will send a BaRS error code. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
### Status Update (Referral Response)
- The referral Receiver will send a series of status updates back to the referral Sender, to support tracking the progress of the case.
@@ -100,7 +100,7 @@ Note: The BaRS Referral may be used to support single patient Mutual aid request
### Continue updates
- If additional or changed information about the case is captured by the referral Sender, subsequent to sending the BaRS Referral, they may send a BaRS Referral Update to ensure that the referral Receiver has the most up to date information.
- If the referral Sender needs to cancel a Referral, for example the patient calls back and says they do not require an ambulance, they need to send a Cancellation.
-- On receipt of a Referral Update, the referral Receiver will send an acknowledgement back to the Sending AST on when it has successfully processed the payload. If it fails to do this it will send a BaRS error code. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+- On receipt of a Referral Update, the referral Receiver will send an acknowledgement back to the Sending AST on when it has successfully processed the payload. If it fails to do this it will send a BaRS error code. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
### Manage Stack
- The referral Receiver will manage the case in accordance with the Ambulance Response Programme (ARP) Priority Level. This may include:
@@ -118,7 +118,7 @@ To support the workflows for this application of the standard the operations tha
## Make a Referral
-Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.4.0, text:standard pattern for BaRS Composite Messages}}.
+Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
Application 5 v1.2.0
- v1.1.x
- v1.11.0
+ v1.1.x
+ v1.11.1
v1.1.0
-
@@ -52,7 +52,7 @@ This application supports the use of the following use cases:
### Overview
-This page provides guidance for implementing the Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.0.7, text:BaRS Core implementation guide}} and Payload Definitions when developing to the standard.
+This page provides guidance for implementing the Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.4.1, text:BaRS Core implementation guide}} and Payload Definitions when developing to the standard.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Referrals.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Referrals.page.md
index 13f77bdb..a07753f5 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Referrals.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Referrals.page.md
@@ -17,7 +17,7 @@ For example Referral bundles please see:
* For additional example bundles please check [BaRS Example Bundles](https://simplifier.net/nhsbookingandreferrals/~resources?category=Example&exampletype=Bundle&sortBy=LastUpdateDate_desc)
### MessageHeader Resource
-For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.0, text:Standard Pattern Message Header}}.
+For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.1, text:Standard Pattern Message Header}}.
The MessageHeader resource for the Referral Request should have the following resource elements set as follows:
* **MessageHeader.eventCoding** - **must** be populated with 'servicerequest-request'
@@ -32,7 +32,7 @@ There are two *coding* entries within *ServiceRequest.category* which are key to
1. Denotes the type of referral e.g. Transfer of care
2. Denotes the use case and must be populated with the relevant use case from [use-case CodeSystem](
https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars
-). e.g. Out of area, Mutual Aid or Call Assist. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.0, text:use-case categories}}
+). e.g. Out of area, Mutual Aid or Call Assist. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.1, text:use-case categories}}
Additionally, the *ServiceRequest.category.text* **must** be populated with details about the service request when the request is to support the Call Assist or Mutual Aid use cases.
@@ -251,7 +251,7 @@ In this application it is used to transfer Call Log information and Crew Notes.
## Referral Cancellation Payload
-The ability to cancel a referral 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.4.0, text:Standard Patterns - Cancellation}}.
+The ability to cancel a referral 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.4.1, text:Standard Patterns - Cancellation}}.
Application 6 v1.0.0-beta.7
+ Application 6 v1.0.0-beta.8
v1.1.x
- v1.11.0
+ v1.11.1
v1.1.0
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Responses.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Responses.page.md
index 3b3c9b54..233e8d11 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Responses.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Payloads-for-Responses.page.md
@@ -18,7 +18,7 @@ For Referral Response example bundles see:
### MessageHeader Resource
-For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.0, text:Standard Pattern - Message Header}}.
+For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.1, text:Standard Pattern - Message Header}}.
The MessageHeader resource in the Referral Response should have the following resource elements set as follows:
* **MessageHeader.eventCoding** - **must** be populated with 'servicerequest-response'
@@ -34,7 +34,7 @@ There are two *coding* entries within *ServiceRequest.category* which are key to
1. Denotes the type of referral e.g. Transfer of care
2. Denotes the use case and must be populated with the relevant use case from [use-case CodeSystem](
-https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars) e.g. Out of area, Mutual Aid or Call Assist. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.0, text:use-case categories}}
+https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars) e.g. Out of area, Mutual Aid or Call Assist. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.1, text:use-case categories}}
### Encounter Resource
The Responder's current *Encounter* is the focus resource in the Referral Response. This was originally the 'planned' Encounter created by the Receiver in the synchronous response to the Referral Request.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Scope-and-Requirements.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Scope-and-Requirements.page.md
index 80dda7c0..9878c5bd 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Scope-and-Requirements.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Scope-and-Requirements.page.md
@@ -76,16 +76,16 @@ The payloads and workflow have been designed to support these services. Other {{
* The referral Sender **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
* The referral Receiver **must** clearly identify any included safeguarding concern to the end user
* The referral Receiver **must** accurately represent information made by the Sender to the end user
-* Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-* Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail
+* Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+* Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail
**Update referral**
* The referral Sender **must** be capable of updating any referral made by them, within the current consultation or after the consultation event
* The referral Sender **must** send a referral update each time critical information is added to the case
* The referral Sender **must** retrieve the referral to be updated from the referral Receiver prior to update to ensure they are working with the most up-to date version and the referral has not already been been completed, or is at a point in the workflow where it it must not be updated
* The referral Sender **must** provide visible confirmation to the end user of the status returned by the referral Receiver, i.e. whether the original referral was successfully updated or not
-* Where the update was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-* Where the update was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+* Where the update was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+* Where the update was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
* The referral Receiver **must** store all previous versions of the referral
* The referral Receiver **must not** be required to inform the patient of the updating of the referral. Business/clinical responsibility for informing the patient must remain with the referral Sender
@@ -94,8 +94,8 @@ The payloads and workflow have been designed to support these services. Other {{
* The referral Sender **must** be capable of cancelling any referral made by them, within the current consultation or after the consultation event
* The referral Sender **must** retrieve the referral to be cancelled from the referral Receiver prior to cancellation to ensure they are working with the most up-to date version and it has not already been completed
* The referral Sender **must** provide visible confirmation to the end user of the status returned by the referral Receiver, i.e. whether the original referral was successfully cancelled or not
-* Where the cancellation was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-* Where the cancellation was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+* Where the cancellation was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+* Where the cancellation was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
* The referral Receiver **must** store all previous versions of the referral
* The referral Receiver **must not** be required to inform the patient of the cancellation of the referral. Business/clinical responsibility for informing the patient must remain with the referral Sender
@@ -154,11 +154,11 @@ The payloads and workflow have been designed to support these services. Other {{
### Error Handling
-* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}}
+* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional
-* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}}
+* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
\ No newline at end of file
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 84d7046d..64d8f443 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
@@ -78,7 +78,7 @@ X-Correlation-Id = 
-To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.4.0, text:standard pattern for BaRS cancellation}}.
+To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.4.1, text:standard pattern for BaRS cancellation}}.
The Message Definition that defines the payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled)
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Payloads.page.md
index a416eaaa..eeb46550 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Payloads.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Payloads.page.md
@@ -6,7 +6,7 @@ topic: APP7-Payloads
The specific guidance around the use of key FHIR resources is described below.
### MessageHeader Resource
-{{pagelink:core-SPMessageHeader-1.4.0, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
+{{pagelink:core-SPMessageHeader-1.4.1, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
The MessageHeader resource for the Booking Request should have the following resource elements set as follows:
* **MessageHeader.eventCoding** - **must** be populated with 'booking-request'
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Scope-and-Requirements.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Scope-and-Requirements.page.md
index b2a856c1..ac43f79e 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Scope-and-Requirements.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Scope-and-Requirements.page.md
@@ -61,8 +61,8 @@ The payloads and workflow have been designed to support these services. Other {{
**Booking**
* Where a national identifier is included, it **must** have a [verification status](https://simplifier.net/hl7fhirukcorer4/valueset-ukcore-nhsnumberverificationstatus) of 'Number present and verified' or 'Number present but not traced', otherwise, the referral Sender **must not** include it in the request
-* Where the booking was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
-* Where the booking was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
+* Where the booking was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
+* Where the booking was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
* If included in the synchronous HTTP response, the booking Sender **must** make available the human readable identifier for the booking to the end user
* Update to amend a booking request is **not** supported. If a booking Sender wishes to change information in a request they **must** follow the re-book workflow
@@ -100,11 +100,11 @@ The payloads and workflow have been designed to support these services. Other {{
### Error Handling
-* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}}
+* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional
-* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}}
+* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md
index 4b581e42..1cb93d3f 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/How-does-it-work.page.md
@@ -34,7 +34,7 @@ Directing the referral request will still engage the same BaRS mechanisms; utili
### Make a Referral
-Making a referral for this application follows the {{pagelink:core-standardpattern-1.4.0, text:standard pattern for BaRS Composite Messages}}.
+Making a referral for this application follows the {{pagelink:core-standardpattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
-
@@ -46,7 +46,7 @@ This application supports the use of the following use cases:
### Overview
-This page provides guidance for implementing the Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.4.0, text:BaRS Core implementation guide}} and [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.0) when developing to the standard.
+This page provides guidance for implementing the Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.4.1, text:BaRS Core implementation guide}} and [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1) when developing to the standard.
### Data model endorsements
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md
index 49e76f80..8aebc38f 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Payloads.page.md
@@ -5,7 +5,7 @@ topic: APP8-Payloads
## {{page-title}}
### MessageHeader Resource
-{{pagelink:core-SPMessageHeader-1.4.0, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
+{{pagelink:core-SPMessageHeader-1.4.1, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
The MessageHeader resource for the Referral Request should have the following resource elements set as follows:
* **MessageHeader.eventCoding** - **must** be populated with 'servicerequest-request'
@@ -20,7 +20,7 @@ There are two *coding* entries within *ServiceRequest.category* which are key to
1. Denotes the type of referral e.g. Transfer of care
2. Denotes the use case and must be populated with the relevant use case from [use-case CodeSystem](
https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars
-). e.g. AG to e-RS. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.0, text:use-case categories}}
+). e.g. AG to e-RS. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.4.1, text:use-case categories}}
### Encounter Resource
The Encounter is used to represent the interaction between a patient and healthcare service provider. It links with numerous other resources, to reflect the assessment performed.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md
index 29cd1640..375b829f 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Scope-and-Requirements.page.md
@@ -60,8 +60,8 @@ The payload and workflow have been designed to support these services. Other {{p
- The referral Receiver **must** clearly identify any included safeguarding concern to the end user
- The referral Receiver **must** accurately represent information made by the Sender to the end user.
- The referral Sender **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
-- Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail
-- Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail
+- Where the referral was not successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail
+- Where the referral was not successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail
- The referral Sender **must** indicate consent to share (for Direct Care) to the Receiver
- The referral Sender **must** indicate the urgency (using the [agreed codesystem](https://simplifier.net/nhsbookingandreferrals/bars-broker-priority-status)) of the request to the Receiver
@@ -71,9 +71,9 @@ The payload and workflow have been designed to support these services. Other {{p
### Error Handling
-- Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}}
+- Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
### Non Functional
-- Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}}
+- Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
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 eaf270df..0700d7e5 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
@@ -13,7 +13,7 @@ This page provides a catalogue of implementation guides that have been developed
-These guides are designed to be used in conjunction with the documentation for {{pagelink:design-core-1.4.0}}.
+These guides are designed to be used in conjunction with the documentation for {{pagelink:design-core-1.4.1}}.
@@ -23,7 +23,7 @@ These guides are designed to be used in conjunction with the documentation for {
| {{pagelink:application2, text: Booking and Referrals into UEC (Application 2)}} | Application 8 v1.0.0-alpha
- v1.1.x
- v1.11.0
- v1.1.0
+ Application 8 v1.0.0-alpha.2
+ v1.1.x
+ v1.11.1
+ v1.4.x
111 Online - UTC
S&R - ED
S&R - UTC
| 2.0.0 | v1.0.0 | v1.0.0 |
| {{pagelink:application4, text: Referral into UEC for Validation (Application 4)}} |
| 2.0.0 | v1.0.0 | v1.0.0 |
-| {{pagelink:application5, text: Referrals into Pharmacy (Application 5)}} |
| 1.2.0 | v1.3.0 | {{pagelink:design-core-1.4.0, text:v1.3.0}} |
+| {{pagelink:application5, text: Referrals into Pharmacy (Application 5)}} |
| 1.2.0 | v1.3.0 | {{pagelink:design-core-1.4.1, text:v1.3.0}} |
@@ -180,12 +180,16 @@ Table detailing active versions of the latest Applications in Production (or cur
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Index.page.md
new file mode 100644
index 00000000..22960e11
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Index.page.md
@@ -0,0 +1,3 @@
+---
+topic: core-StandardPattern-appointment-1.4.1
+---
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Initial-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Initial-Booking.page.md
new file mode 100644
index 00000000..8a0d4ff3
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Initial-Booking.page.md
@@ -0,0 +1,56 @@
+---
+topic: core-StandardPattern-appointment-booking-1.4.1
+---
+
+## Appointment Resource
+
+Below are examples of each of the described interactions. The appointment resource adheres to the [UKCore-Appointment](https://simplifier.net/HL7FHIRUKCoreR4/UKCore-Appointment) definition.
+
+Any operations that modify an existing resource must perform a read before a write, as outlined below.
+
+### Book
+Making an initial booking through Appointment Management Foundation, outside of the prescribed BaRS Applications, must follow the workflow outlined using the discete [booking endpoints](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#post-/Appointment).
+
+If undertaking a booking within the context of an Application, the guidance stated there takes precedence over this documentation. NB: BaRS Applications are likely to utilise the [$process-message](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#post-/$process-message) endpoint (contact BaRS Team for guidance on use outside of the published Applications - 
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Introduction.page.md
new file mode 100644
index 00000000..9d84d288
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Introduction.page.md
@@ -0,0 +1,50 @@
+---
+topic: core-StandardPattern-appointment-Introduction-1.4.1
+---
+
+# Standard Pattern - Appointments
+
+
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md
new file mode 100644
index 00000000..edb3ffba
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md
@@ -0,0 +1,94 @@
+---
+topic: core-StandardPattern-appointment-reschedule-1.4.1
+---
+
+### Reschedule
+
+The Reschedule operation supports amending the slot a booking is made against. The slot is the only element capable of being changed as part of the reschedule operation, if either the .status or .reasonCode require amendment, the {{pagelink:core-StandardPattern-appointment-update-1.4.1, text:Update}} operation can be followed, otherwise, the {{pagelink:core-StandardPattern-appointment-rebook-1.4.1, text:Rebook}} operation.
+
+Steps to Reschedule:
+
+* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/Appointment/-id-) operation using the .id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, a search of the Registry can be undertaken following the {{pagelink:core-StandardPattern-document-reference-Sender-1.4.1, text: Document Reference Standard Pattern - Sender}}. NB: If a match cannot be obtained using this method the process of updating must be performed manually
+* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/Slot) from the service
+* Select a new slot
+* Update the resource with the new slot. NB: Only the .slot element of the resource must be updated
+* Perform a [PATCH](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#patch-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}
+* Once processed, the Receiver of the booking must [update (PUT)](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#put-/DocumentReference/-id-) the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-Receiver-1.4.1, text: Document Reference Standard Pattern - Receiver}}. The principal update to the pointer is to change the .context element to alter the slot time -
+
+```json
+"context": {
+ "period": {
+ "start": "2025-02-12T12:30:30+00:00",
+ "end": "2025-02-12T12:40:30+00:00"
+ }
+}
+```
+
+
+In this example the Appointment resource is with the existing slot, and updated with the newly selected slot.
+
+resource returned:
+```json
+{
+ "resourceType": "Appointment",
+ "id":"aca94bdb-2e38-4399-9ece-2ba083ce65b5",
+ "meta": {
+ "lastUpdated": "2024-01-11T15:01:30.8185338+00:00",
+ "profile": [
+ "https://fhir.hl7.org.uk/StructureDefinition/UKCore-Appointment"
+ ]
+ },
+ "status": "booked",
+ "slot": [
+ {
+ "reference": "Slot/265a53d7-1d21-4fc6-a5b7-761f650e75eb"
+ }
+ ],
+ "description": "Reason for calling",
+ "start": "2025-02-12T10:00:30+00:00",
+ "end": "2025-02-12T10:10:30+00:00",
+ "created": "2024-10-08T15:01:30+00:00",
+ "participant": [
+ {
+ "actor": {
+ "reference": "Patient/788660eb-d2c9-4773-abd4-318484673fb2"
+ },
+ "status": "accepted"
+ }
+ ]
+}
+```
+
+Request Body
+
+```json
+{
+ "resourceType": "Appointment",
+ "id":"aca94bdb-2e38-4399-9ece-2ba083ce65b5",
+ "meta": {
+ "lastUpdated": "2024-01-11T15:01:30.8185338+00:00",
+ "profile": [
+ "https://fhir.hl7.org.uk/StructureDefinition/UKCore-Appointment"
+ ]
+ },
+ "status": "booked",
+ "slot": [
+ {
+ "reference": "Slot/deb4c4b3-870b-4599-84df-5e54cef7afda"
+ }
+ ],
+ "description": "Reason for calling",
+ "start": "2025-02-12T12:30:30+00:00",
+ "end": "2025-02-12T12:40:30+00:00",
+ "created": "2024-10-08T15:01:30+00:00",
+ "participant": [
+ {
+ "actor": {
+ "reference": "Patient/788660eb-d2c9-4773-abd4-318484673fb2"
+ },
+ "status": "accepted"
+ }
+ ]
+}
+```
+
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Update-Existing-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Update-Existing-Booking.page.md
new file mode 100644
index 00000000..01142588
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Update-Existing-Booking.page.md
@@ -0,0 +1,92 @@
+---
+topic: core-StandardPattern-appointment-update-1.4.1
+---
+
+### Update
+
+Steps to update:
+
+* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/Appointment/-id-) operation using the .id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, a search of the Registry can be undertaken following the {{pagelink:core-StandardPattern-document-reference-Sender-1.4.1, text: Document Reference Standard Pattern - Sender}}. NB: If a match cannot be obtained using this method the process of updating must be performed manually
+* Update the Appointment resource as required. There is only currently support to alter .status and .reasonCode. NB: The .slot element of the resource must not be updated, if an alternative slot is required either the {{pagelink:core-StandardPattern-appointment-reschedule-1.4.1, text:Reschedule}} or {{pagelink:core-StandardPattern-appointment-rebook-1.4.1, text:Rebook}} processes must be followed
+* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}
+
+resource returned:
+```json
+{
+ "resourceType": "Appointment",
+ "id":"aca94bdb-2e38-4399-9ece-2ba083ce65b5",
+ "meta": {
+ "lastUpdated": "2024-01-11T15:01:30.8185338+00:00",
+ "profile": [
+ "https://fhir.hl7.org.uk/StructureDefinition/UKCore-Appointment"
+ ]
+ },
+ "status": "booked",
+ "reasonCode": [
+ {
+ "coding": [
+ {
+ "system": "http://snomed.info/sct",
+ "code": "165342003",
+ "display": "Patient declined laboratory test (situation)"
+ }
+ ]
+ }
+ ],
+ "description": "Reason for calling",
+ "created": "2024-10-08T15:01:30+00:00",
+ "participant": [
+ {
+ "actor": {
+ "reference": "Patient/788660eb-d2c9-4773-abd4-318484673fb2"
+ },
+ "status": "accepted"
+ }
+ ]
+}
+```
+
+Request Body
+
+```json
+{
+ "resourceType": "Appointment",
+ "id": "aca94bdb-2e38-4399-9ece-2ba083ce65b5",
+ "meta": {
+ "lastUpdated": "2024-01-11T15:01:30.8185338+00:00",
+ "profile": [
+ "https://fhir.hl7.org.uk/StructureDefinition/UKCore-Appointment"
+ ]
+ },
+ "status": "booked",
+ "reasonCode": [
+ {
+ "coding": [
+ {
+ "system": "http://snomed.info/sct",
+ "code": "165332000",
+ "display": "Laboratory test requested (situation)"
+ }
+ ]
+ }
+ ],
+ "slot": [
+ {
+ "reference": "Slot/deb4c4b3-870b-4599-84df-5e54cef7afda"
+ }
+ ],
+ "description": "Reason for calling",
+ "start": "2024-02-12T12:30:30+00:00",
+ "end": "2024-02-12T12:40:30+00:00",
+ "created": "2024-10-08T15:01:30+00:00",
+ "participant": [
+ {
+ "actor": {
+ "reference": "Patient/788660eb-d2c9-4773-abd4-318484673fb2"
+ },
+ "status": "accepted"
+ }
+ ]
+}
+```
+
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/toc.yaml
new file mode 100644
index 00000000..4c87031c
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/toc.yaml
@@ -0,0 +1,14 @@
+- name: Index
+ filename: Index.page.md
+- name: Introduction
+ filename: Introduction.page.md
+- name: Initial Booking
+ filename: Initial-Booking.page.md
+- name: Update a Booking
+ filename: Update-Existing-Booking.page.md
+- name: Cancel a Booking
+ filename: Cancel-Booking.page.md
+- name: Reschedule a Booking
+ filename: Reschedule-Existing-Booking.page.md
+- name: Rebook Methods
+ filename: Rebook-Methods.page.md
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/BaRS-FHIR-Usage/Bundle.page.md
new file mode 100644
index 00000000..c054d39d
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/BaRS-FHIR-Usage/Bundle.page.md
@@ -0,0 +1,14 @@
+---
+topic: core-FHIRUsage-bundle-1.4.1
+---
+
+## Bundle
+
+The use of the FHIR bundle in BaRS primarily supports the use of $process-message. It is also used as follows:
+
+- When $process-message is initiated, a sender packages up numerous FHIR resources (MessageHeader, Patient, ServiceRequest etc.), the bundle will include everything needed by a receiver to process the request being made.
+- The $process-message endpoint is capable of receiving different types of request. The sender indicates the the action required by specifying in the MessageHeader resource, for example: booking or servicerequest, the operation, whether it be 'new' or 'update' and central FHIR resource from which to make sense of the bundle, the 'focus'.
+- A bundle type of 'searchset' is also used in BaRS when a receiver responds to a senders request for available slots, in the booking workflow. A receiver responds by bundling FHIR resources (HealthcareService, Schedule, Slot(s) etc.) related to particular HealthcareService which a sender will unpack and process to display service availability to a user.
+
+
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/DocumentReference-StandardPattern/Receiver-DocumentReference.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/DocumentReference-StandardPattern/Receiver-DocumentReference.page.md
new file mode 100644
index 00000000..a23e8d4c
--- /dev/null
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/DocumentReference-StandardPattern/Receiver-DocumentReference.page.md
@@ -0,0 +1,118 @@
+---
+topic: core-StandardPattern-document-reference-Receiver-1.4.1
+---
+
+# {{page-title}}
+
+## Creating a DocumentReference.
+
+The FHIR DocumentReference resource allows you to create a reference to a clinical document or resource. This section describes the process of creating a FHIR DocumentReference (pointer) for a booking or referral resource on the central Registry. A DocumentReference will be created when a Receiver accepts a booking or referral. Each booking or referral request processed requires a distinct DocumentReference on the Registry.
+
+
+### Step 1: Identify the booking or referral to create a pointer for
+When a Receiver processes a request for a booking (Appointment) or referral (ServiceRequest), the next step in the workflow is to create a pointer for the newly created resource (Appointment or ServiceRequest) on the central Registry. This will be undertaken via a POST [DocumentReference](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#post-/DocumentReference) request to the BaRS Proxy.
+
+
+### Step 2: Set content of the DocumentReference (pointer)
+Create a new instance of the DocumentReference resource and populate the relevant fields. Key fields to include are as follows:
+
+**identifier:** The DocumentReference needs several identifiers which allow the booking or referral to be located at a Receiver service.
+
+The resource .id of the booking (Appointment) or referral (ServiceRequest) (created by the Receiver when processing the request) must be set in the 'value' element of an Identifier, clarified by the system '*https://fhir.nhs.uk/Id/BaRS-Identifier*'.
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/BaRS-Identifier",
+ "value": "8c63d621-4d86-4f57-8699-e8e22d49935d"
+ }
+```
+
+The second identifier of note is the Receiving service who own the resource. The 'system' indicates the Service Discovery tool and the 'value', the identifier. In the code snippet below, the system '*https://fhir.nhs.uk/Id/dos-service-id*' indicates the Receiver service is on the Urgent and Emergency Care Directory of Services (UEC DoS) as service 2000072491. The Sender of any request will use the 'system' and 'value' here to build the base64 encoded HTTP Header NHSD-Target-Identifier, as defined for the [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/Appointment/-id-) or [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/ServiceRequest/-id-).
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/dos-service-id",
+ "value": "2000072491"
+ }
+```
+
+The third identifier (currently optional) relates to the product-id, system '*https://fhir.nhs.uk/id/product-id*'. This is forthcoming functionality and further detail on its utility will follow but [working documentation] (https://github.com/NHSDigital/nhse-epr-integration/blob/main/pages/appendix1.md) is being actively updated.
+
+```json
+"identifier": [
+ {
+ "system": "https://fhir.nhs.uk/Id/product-id",
+ "value": "P.GH7-4TY"
+ }
+```
+
+**type:**, within the DocumentReference resource, indicates whether the pointer is for a booking or referral. BaRS currently only supports bookings (749001000000101) and referrals (736253002), described using SNOMED codes.
+
+```json
+"type": {
+ "coding": [
+ {
+ "system": "https://snomed.info/ict",
+ "code": "749001000000101"
+ }
+ ]
+}
+```
+
+**subject:** specifies the subject of the DocumentReference, which will be the patient associated with the Resource. The patient's NHS number must be used to identify them, as outlined below.
+
+```json
+"subject": {
+ "identifier": {
+ "system": "https://fhir.nhs.uk/Id/nhs-number",
+ "value": "9556274839"
+ }
+},
+```
+
+**custodian:** Set the author of the DocumentReference, which will be the ODS code for the organisation writing the DocumentReference resource entry.
+
+```json
+ "custodian": {
+ "identifier": {
+ "system": "https://fhir.nhs.uk/Id/ods-organization-code",
+ "value": "A1001"
+ }
+ }
+```
+
+**context:** MUST include a period set to the Appointment start and end times.
+
+```json
+"context": {
+ "period": {
+ "start": "2025-02-12T12:30:30+00:00",
+ "end": "2025-02-12T12:40:30+00:00"
+ }
+}
+```
+
+### Step 3: Save and Transmit the DocumentReference (pointer)
+Once all the necessary fields are populated, perform a [POST](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#post-/DocumentReference) of the DocumentReference to the /DocumentReference endpoint on the BaRS proxy. This will create a DocumentReference in the NRL.
+
+After saving, the DocumentReference will be assigned a unique id (e.g., DocumentReference/12345). This can be used to reference or [retrieve](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/DocumentReference/-id-) the DocumentReference in the future.
+
+### Step 4: Verify the DocumentReference
+To ensure that the DocumentReference was created successfully, retrieve it using its [id](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/DocumentReference/-id-) or [search](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#get-/DocumentReference) for it using relevant parameters. Make sure to validate the returned DocumentReference to confirm that all the contents are accurate.
+
+### Updating a DocumentReference
+A DocumentReference can be updated by performing a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#put-/DocumentReference/-id-) request with the updated resource to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A read operation must be performed prior to this to ensure that the new DocumentReference is the most up to date.
+
+**Note**: A Receiver can only update DocumentReference resources that they created and own.
+
+### Delete a DocumentReference
+A DocumentReference can be removed by performing a [DELETE](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#delete-/DocumentReference/-id-) request to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A read operation must be performed prior to this to ensure that the action is appropriate.
+
+**Note**: A Receiver can only delete DocumentReference resources they created and own.
+
+
