From ebde8ea28e8c367cd4946a1f8d44ea5209dc2421 Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 3 Jul 2026 09:46:02 +0100 Subject: [PATCH 01/25] JIRA 4790 Master Banner cchanges IG, Core and Package numbers updated --- guides/Live-ImplementationGuide-BaRS/guide.yaml | 2 +- guides/Live-ImplementationGuide-BaRS/styles/NHSD/master.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/guide.yaml b/guides/Live-ImplementationGuide-BaRS/guide.yaml index 3a15d068..cb856228 100644 --- a/guides/Live-ImplementationGuide-BaRS/guide.yaml +++ b/guides/Live-ImplementationGuide-BaRS/guide.yaml @@ -1,5 +1,5 @@ title: NHS Booking and Referral Standard description: FHIR Implementation Guide for the NHS Booking and Referral Standard -version: 1.11.1 +version: 1.12.0 style-root: project style-name: NHSD diff --git a/guides/Live-ImplementationGuide-BaRS/styles/NHSD/master.html b/guides/Live-ImplementationGuide-BaRS/styles/NHSD/master.html index 4f5cb766..38baef57 100644 --- a/guides/Live-ImplementationGuide-BaRS/styles/NHSD/master.html +++ b/guides/Live-ImplementationGuide-BaRS/styles/NHSD/master.html @@ -162,7 +162,7 @@ data-uipath="document.title"> {{guide-title}} -
Guide v{{ guide-version }} | Core v1.4.1 | Package v1.40.0
+
Guide v{{ guide-version }} | Core v1.5.0 | Package v1.41.0
From c16978f0c4991b86550c036338311f0352fd850d Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 3 Jul 2026 10:11:23 +0100 Subject: [PATCH 02/25] JIRA 4789/4801 Current release update Previous releases updated Versioning Matrix updated and applied to current release/applications/pre-release applications --- .../Releases/Current-Releases.page.md | 45 +++++++++---------- .../Releases/Previous-Releases.page.md | 34 ++++++++++++++ .../Applications/Index.page.md | 26 +++++------ .../BaRS-Pre-releases/Index.page.md | 28 ++++++------ 4 files changed, 83 insertions(+), 50 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md index c043b55b..a6a26252 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md @@ -1,28 +1,28 @@ -## Current Release 1.11.1 +## Current Release 1.12.0 Product Link | Version | Handle | Phase | State | Release Date | Stability | Change Log Link -----------------------|---------|---------|----------|-----------------|--------------|------------|----------------- -Implementation Guide | 1.11.1 | v1 | Live | Current Release | 19/05/2026 | Stable |{{pagelink:trn-General}} -[FHIR Package](https://simplifier.net/packages/uk.nhsdigital.bars.r4/1.40.0) | 1.40.0| v1 | Live | Current Release | 19/05/2026 | Stable | -{{pagelink:design-core-1.4.1, text:BaRS Core}} | 1.4.1 | v1 | Live | Current Release | 19/05/2026 | Stable |{{pagelink:trn-core, text: BaRS Core Change Log}} -[API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1) | 1.4.1 | v1 | Live | Current Release | 19/05/2026 | Stable |{{pagelink:trn-api}} +Implementation Guide | 1.12.0 | v1 | Live | Current Release | 16/07/2026 | Stable |{{pagelink:trn-General}} +[FHIR Package](https://simplifier.net/packages/uk.nhsdigital.bars.r4/1.41.0) | 1.41.0| v1 | Live | Current Release | 16/07/2026 | Stable | +{{pagelink:design-core-1.5.0, text:BaRS Core}} | 1.5.0 | v1 | Live | Current Release | 16/07/2026 | Stable |{{pagelink:trn-core, text: BaRS Core Change Log}} +[API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.5.0) | 1.5.0 | v1 | Live | Current Release | 16/07/2026 | Stable |{{pagelink:trn-api}} {{pagelink: build-testing, text: TKW}} | 1.0.21 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-tkw}} -{{pagelink:application1, text:BaRS-APP1}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app1,text:BaRS APP1 Change Log}} -{{pagelink:application2, text:BaRS-APP2}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app2,text:BaRS APP2 Change Log}} +{{pagelink:application1, text:BaRS-APP1}} | 2.1.0 | v1 | Live | Current Release | 16/07/2026 | Stable |{{pagelink:trn-app1,text:BaRS APP1 Change Log}} +{{pagelink:application2, text:BaRS-APP2}} | 2.1.0 | v1 | Live | Current Release | 16/07/2026 | Stable |{{pagelink:trn-app2,text:BaRS APP2 Change Log}} {{pagelink:application3, text:BaRS-APP3}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app3,text:BaRS APP3 Change Log}} {{pagelink:application4, text:BaRS-APP4}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app4,text:BaRS APP4 Change Log}} {{pagelink:application5, text:BaRS-APP5}} | 1.2.0 | v1 | Live | Current Release | 26/03/2026 | Stable |{{pagelink:trn-app5,text:BaRS APP5 Change Log}} {{pagelink:application6, text:BaRS-APP6}} | 1.0.0-beta.8 | beta | | Current Release | 19/05/2026 | Pre-Release |{{pagelink:trn-app6,text:BaRS APP6 Change Log}} {{pagelink:application7, text:BaRS-APP7}} | 1.0.0-alpha.4 | alpha | | Current Release | 02/07/2025 | Pre-Release |{{pagelink:trn-app7,text:BaRS APP7 Change Log}} -{{pagelink:application8, text:BaRS-APP8}} | 1.0.0-alpha.2 | alpha | | Current Release | 19/05/2026 | Pre-Release |{{pagelink:trn-app8,text:BaRS APP8 Change Log}} +{{pagelink:application8, text:BaRS-APP8}} | 1.0.0-alpha.3 | alpha | | Current Release | 16/07/2026 | Pre-Release |{{pagelink:trn-app8,text:BaRS APP8 Change Log}} ### Overview of the release -Release 1.11.1 of the BaRS Implementation Guide is a patch release including an additional encounter.status value for Application 6 CAD to CAD Out of Area Referral, published with supporting documentation. BaRS Core version is uplifted to 1.4.1 in line with an update to the BaRS FHIR API OAS file. Updates to the BaRS FHIR API OAS file are limited to changes relating to internal endpoint catalogue management and do not affect supplier development. +Release 1.12.0 of the BaRS Implementation Guide is a minor release including an additional optional FHIR resource for Related Person in the payloads for Applications 1 and 2. Message definitions and examples in Simplifer are updated to support this change. Use case category codes have been updated to support senders in implementing the change effectively, following supplier feedback. Minor changes are applied to the implmentation guidance for Application 8 following consulation at alpha stage. BaRS Core version is uplifted to 1.5.0 in line with an update to the BaRS FHIR API OAS file. -Also included in this release are minor changes to BaRS Application 8 and bug fixes and corrections throughout the guide. +Also included in this release are minor changes and 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 . @@ -73,6 +73,10 @@ Table detailing active versions of the latest Applications in Production (or cur Application 1 v2.0.0 v1.10.0 + + Application 1 v2.1.0 + v1.12.0 + Application 2 v1.0.1 v1.1.0 @@ -102,7 +106,10 @@ Table detailing active versions of the latest Applications in Production (or cur v1.10.0 - Application 3 v1.0.0 + Application 2 v2.0.0 + v1.12.0 + + Application 3 v1.0.0 v1.4.0 @@ -183,10 +190,6 @@ Table detailing active versions of the latest Applications in Production (or cur Application 5 v1.2.0 v1.11.0 - - Application 6 v1.0.0-beta.7 - v1.11.0 - Application 6 v1.0.0-beta.8 v1.11.1 @@ -198,14 +201,10 @@ Table detailing active versions of the latest Applications in Production (or cur 1.0.0 - Application 8 v1.0.0-alpha - v1.11.0 - v1.4.0 - 1.4.x - - - Application 8 v1.0.0-alpha.2 - v1.11.1 + Application 8 v1.0.0-alpha.3 + v1.12.0 + v1.5.0 + 1.5.x diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Previous-Releases.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Previous-Releases.page.md index b875b3b4..3f24eca2 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Previous-Releases.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Previous-Releases.page.md @@ -1,5 +1,39 @@ ## {{page-title}} +
+
+ +Product Link | Version | Handle | Phase | State | Release Date | Stability | Change Log Link +-----------------------|---------|---------|----------|-----------------|--------------|------------|----------------- +Implementation Guide | 1.11.1 | v1 | Live | Current Release | 19/05/2026 | Stable |{{pagelink:trn-General}} +[FHIR Package](https://simplifier.net/packages/uk.nhsdigital.bars.r4/1.40.0) | 1.40.0| v1 | Live | Current Release | 19/05/2026 | Stable | +{{pagelink:design-core-1.4.1, text:BaRS Core}} | 1.4.1 | v1 | Live | Current Release | 19/05/2026 | Stable |{{pagelink:trn-core, text: BaRS Core Change Log}} +[API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1) | 1.4.1 | v1 | Live | Current Release | 19/05/2026 | Stable |{{pagelink:trn-api}} +{{pagelink: build-testing, text: TKW}} | 1.0.21 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-tkw}} +{{pagelink:application1, text:BaRS-APP1}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app1,text:BaRS APP1 Change Log}} +{{pagelink:application2, text:BaRS-APP2}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app2,text:BaRS APP2 Change Log}} +{{pagelink:application3, text:BaRS-APP3}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app3,text:BaRS APP3 Change Log}} +{{pagelink:application4, text:BaRS-APP4}} | 2.0.0 | v1 | Live | Current Release | 12/11/2025 | Stable |{{pagelink:trn-app4,text:BaRS APP4 Change Log}} +{{pagelink:application5, text:BaRS-APP5}} | 1.2.0 | v1 | Live | Current Release | 26/03/2026 | Stable |{{pagelink:trn-app5,text:BaRS APP5 Change Log}} +{{pagelink:application6, text:BaRS-APP6}} | 1.0.0-beta.8 | beta | | Current Release | 19/05/2026 | Pre-Release |{{pagelink:trn-app6,text:BaRS APP6 Change Log}} +{{pagelink:application7, text:BaRS-APP7}} | 1.0.0-alpha.4 | alpha | | Current Release | 02/07/2025 | Pre-Release |{{pagelink:trn-app7,text:BaRS APP7 Change Log}} +{{pagelink:application8, text:BaRS-APP8}} | 1.0.0-alpha.2 | alpha | | Current Release | 19/05/2026 | Pre-Release |{{pagelink:trn-app8,text:BaRS APP8 Change Log}} + + + +### Overview of the release + +Release 1.11.1 of the BaRS Implementation Guide is a patch release including an additional encounter.status value for Application 6 CAD to CAD Out of Area Referral, published with supporting documentation. BaRS Core version is uplifted to 1.4.1 in line with an update to the BaRS FHIR API OAS file. Updates to the BaRS FHIR API OAS file are limited to changes relating to internal endpoint catalogue management and do not affect supplier development. + +Also included in this release are minor changes to BaRS Application 8 and 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/Applications/BaRS-Applications/Applications/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/Index.page.md index 0700d7e5..69b1abf3 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 @@ -30,6 +30,7 @@ These guides are designed to be used in conjunction with the documentation for { ## Versioning Matrix + Table detailing active versions of the latest Applications in Production (or currently being built to) and their supporting Implementation Guide, Core and API versions @@ -72,6 +73,10 @@ Table detailing active versions of the latest Applications in Production (or cur + + + + @@ -101,7 +106,10 @@ Table detailing active versions of the latest Applications in Production (or cur - + + + + @@ -182,10 +190,6 @@ Table detailing active versions of the latest Applications in Production (or cur - - - - @@ -197,14 +201,10 @@ Table detailing active versions of the latest Applications in Production (or cur - - - - - - - - + + + + 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 5c592187..2fc5bc36 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 @@ -27,6 +27,7 @@ Our Beta Deployment Guide can be found here {{pagelink:betadeploymentguide}}. ## Versioning Matrix + Table detailing active versions of the latest Applications in Production (or currently being built to) and their supporting Implementation Guide, Core and API versions
Application 1 v2.0.0 v1.10.0
Application 1 v2.1.0v1.12.0
Application 2 v1.0.1 v1.1.0v1.10.0
Application 3 v1.0.0Application 2 v2.0.0v1.12.0
Application 3 v1.0.0 v1.4.0
Application 5 v1.2.0 v1.11.0
Application 6 v1.0.0-beta.7v1.11.0
Application 6 v1.0.0-beta.8 v1.11.11.0.0
Application 8 v1.0.0-alphav1.11.0v1.4.01.4.x
Application 8 v1.0.0-alpha.2v1.11.1Application 8 v1.0.0-alpha.3v1.12.0v1.5.01.5.x
@@ -69,6 +70,10 @@ Table detailing active versions of the latest Applications in Production (or cur + + + + @@ -98,7 +103,10 @@ Table detailing active versions of the latest Applications in Production (or cur - + + + + @@ -179,10 +187,6 @@ Table detailing active versions of the latest Applications in Production (or cur - - - - @@ -194,14 +198,10 @@ Table detailing active versions of the latest Applications in Production (or cur - - - - - - - - + + + + @@ -210,4 +210,4 @@ Table detailing active versions of the latest Applications in Production (or cur -
Application 1 v2.0.0 v1.10.0
Application 1 v2.1.0v1.12.0
Application 2 v1.0.1 v1.1.0v1.10.0
Application 3 v1.0.0Application 2 v2.0.0v1.12.0
Application 3 v1.0.0 v1.4.0
Application 5 v1.2.0 v1.11.0
Application 6 v1.0.0-beta.7v1.11.0
Application 6 v1.0.0-beta.8 v1.11.11.0.0
Application 8 v1.0.0-alphav1.11.0v1.4.01.4.x
Application 8 v1.0.0-alpha.2v1.11.1Application 8 v1.0.0-alpha.3v1.12.0v1.5.01.5.x
+ \ No newline at end of file From ca73053ffce03e03cd136df56a9131a4b9022bef Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 3 Jul 2026 10:16:11 +0100 Subject: [PATCH 03/25] JIRA 4801 Application banners updated for Apps 1,2,8 --- .../Applications/BaRS-APP1/Index.page.md | 4 ++-- .../Applications/BaRS-APP2/Index.page.md | 4 ++-- .../Applications/BaRS-APP8/Index.page.md | 8 ++++---- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Index.page.md index d56cd154..b488deca 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Index.page.md @@ -19,9 +19,9 @@ topic: Application1 - Application 1 v2.0.0 + Application 1 v2.1.0 v1.0.x - v1.10.0 + v1.12.0 v1.0.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Index.page.md index a95e53b8..8bb08cf1 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Index.page.md @@ -20,9 +20,9 @@ topic: Application2 - Application 2 v2.0.0 + Application 2 v2.1.0 v1.0.x - v1.10.0 + v1.12.0 v1.0.0 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 ca4bd8b2..e4a060b9 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 - Application 8 v1.0.0-alpha.2 - v1.1.x - v1.11.1 - v1.4.x + Application 8 v1.0.0-alpha.3 + v1.1.x + v1.12.0 + v1.5.x From 9079e4ea20c96fc233a5d20fb0569a828515e4e0 Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 3 Jul 2026 11:44:13 +0100 Subject: [PATCH 04/25] NBRS-4800 Change log pages added for IG, Core, App1, App2, App8 Previous versions demoted toc files updated --- .../BaRS-Core/1.4.1.page.md | 6 ++++- .../BaRS-Core/1.5.0.page.md | 14 +++++++++++ .../BaRS-Core/toc.yaml | 2 ++ .../1.11.1.page.md | 9 ++++++- .../1.12.0.page.md | 12 +++++++++ .../Implementation-Guide-Change-Log/toc.yaml | 2 ++ .../TRN-APP1/2.0.0.page.md | 7 +++++- .../TRN-APP1/2.1.0.page.md | 25 +++++++++++++++++++ .../Technical-Release-Notes/TRN-APP1/toc.yaml | 2 ++ .../TRN-APP2/2.0.0.page.md | 8 ++++-- .../TRN-APP2/2.1.0.page.md | 24 ++++++++++++++++++ .../Technical-Release-Notes/TRN-APP2/toc.yaml | 2 ++ .../TRN-APP8/1.0.0-alpha.2.page.md | 7 ++++++ .../TRN-APP8/1.0.0-alpha.3.page.md | 24 ++++++++++++++++++ .../Technical-Release-Notes/TRN-APP8/toc.yaml | 2 ++ 15 files changed, 141 insertions(+), 5 deletions(-) create mode 100644 guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.5.0.page.md create mode 100644 guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.12.0.page.md create mode 100644 guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.1.0.page.md create mode 100644 guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.1.0.page.md create mode 100644 guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md 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 index f5ad8847..5c3849db 100644 --- 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 @@ -2,13 +2,17 @@ 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/1.5.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.5.0.page.md new file mode 100644 index 00000000..9bbc2ea7 --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.5.0.page.md @@ -0,0 +1,14 @@ +--- +topic: TRN-Core-1.5.0 +--- + +## {{page-title}} + +| Change | Description | Impact | +|------------------------------------------|----------------------------------------|---------------------------------| + + +
+
+ +### 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 e6607ee7..6898df76 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.5.0 + filename: 1.5.0.page.md - name: 1.4.1 filename: 1.4.1.page.md - name: 1.4.0 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 index e6f8ed10..2ba0d44e 100644 --- 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 @@ -1,3 +1,7 @@ +
+ +
+ ### 1.11.1 ## Implementation Guide Changes @@ -6,7 +10,10 @@ |---------------------------------------|---------------------------------------------------------------------------------------------------------| | Bug fixes and corrections |There have been several bug fixes and corrections in the guide, these includes typos, broken links or corrections.| +

+

+
+
-### Previous Releases diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.12.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.12.0.page.md new file mode 100644 index 00000000..b7781b45 --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.12.0.page.md @@ -0,0 +1,12 @@ +### 1.12.0 + +## 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.| + +
+
+ +### 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 5d0a9935..c52d3dd8 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.12.0 + filename: 1.12.0.page.md - name: 1.11.1 filename: 1.11.1.page.md - name: 1.11.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.0.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.0.0.page.md index f454e9d0..d9d1c01e 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.0.0.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.0.0.page.md @@ -1,3 +1,6 @@ +
+
+ ## {{page-title}} This is a major release with a significant change to the Implementation Guidance and examples for v2.0.0. The changes are detailed in the change log. @@ -21,7 +24,9 @@ This is a major release with a significant change to the Implementation Guidance | Patient.identifier.extension.valueCodeableConcept.coding.code | This SHOULD be populated. Where used this MUST either be number-present-and-verified or no NHS number MUST be sent, no other status is valid | This SHOULD be populated. Where used this MUST be 'number-present-and-verified' or 'number-present-but-not-traced', else no NHS number MUST be sent. No other statuses are permitted. | Update | Booking Request |Accommodate NHS No. Requirement | breaking | | Patient.identifier.extension.valueCodeableConcept.coding.display | This SHOULD be populated. Where used this MUST either be populated with 'Number present and-verified' no other status is valid | This SHOULD be populated. Where used this MUST be populated with 'Number present and verified' or 'Number present but not traced'. No other statuses are permitted. | Update | Booking Request |Accommodate NHS No. Requirement | breaking | +
+
+
-### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.1.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.1.0.page.md new file mode 100644 index 00000000..f92ddfcc --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/2.1.0.page.md @@ -0,0 +1,25 @@ +## {{page-title}} +This is a minor release with a change to the Implementation Guidance and examples for v2.1.0. The changes are detailed in the change log. + +### Application Change Log + + +
+ + +| Change | Description | Impact | +|-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| +| Added FHIR resource RelatedPerson | Enhanced payload with addition of Related Person to carry Next of Kin details | Addition | + +### Payload Change Log + + +| FHIR Element | Previous | Current | Other | Referral/Booking | Rationale | Impact | +|------------------------------------------------------|----------|------------|---------|------------------|-------------------------------------------------------------------------------------------------|----------| + + + +
+
+ +### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/toc.yaml index 13b877d7..2361d202 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/toc.yaml +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP1/toc.yaml @@ -1,5 +1,7 @@ - name: Index filename: Index.page.md +- name: 2.1.0 + filename: 2.1.0.page.md - name: 2.0.0 filename: 2.0.0.page.md - name: 1.0.8 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.0.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.0.0.page.md index f454e9d0..fb989b98 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.0.0.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.0.0.page.md @@ -1,3 +1,6 @@ +
+
+ ## {{page-title}} This is a major release with a significant change to the Implementation Guidance and examples for v2.0.0. The changes are detailed in the change log. @@ -21,7 +24,8 @@ This is a major release with a significant change to the Implementation Guidance | Patient.identifier.extension.valueCodeableConcept.coding.code | This SHOULD be populated. Where used this MUST either be number-present-and-verified or no NHS number MUST be sent, no other status is valid | This SHOULD be populated. Where used this MUST be 'number-present-and-verified' or 'number-present-but-not-traced', else no NHS number MUST be sent. No other statuses are permitted. | Update | Booking Request |Accommodate NHS No. Requirement | breaking | | Patient.identifier.extension.valueCodeableConcept.coding.display | This SHOULD be populated. Where used this MUST either be populated with 'Number present and-verified' no other status is valid | This SHOULD be populated. Where used this MUST be populated with 'Number present and verified' or 'Number present but not traced'. No other statuses are permitted. | Update | Booking Request |Accommodate NHS No. Requirement | breaking | +
+
+
- -### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.1.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.1.0.page.md new file mode 100644 index 00000000..3123fb89 --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/2.1.0.page.md @@ -0,0 +1,24 @@ +## {{page-title}} +This is a minor release with a change to the Implementation Guidance and examples for v2.1.0. The changes are detailed in the change log. + +### Application Change Log + + +
+ + +| Change | Description | Impact | +|-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| +| Added FHIR resource RelatedPerson | Enhanced payload with addition of Related Person to carry Next of Kin details | Addition | + +### Payload Change Log + + +| FHIR Element | Previous | Current | Other | Referral/Booking | Rationale | Impact | +|------------------------------------------------------|----------|------------|---------|------------------|-------------------------------------------------------------------------------------------------|----------| + + +
+
+ +### Previous Releases \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/toc.yaml index 5a6c3a54..2937ea43 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/toc.yaml +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP2/toc.yaml @@ -1,5 +1,7 @@ - name: Index filename: Index.page.md +- name: 2.1.0 + filename: 2.1.0.page.md - name: 2.0.0 filename: 2.0.0.page.md - name: 1.0.8 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 index 66f7b2c7..d7fec032 100644 --- 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 @@ -1,3 +1,6 @@ +
+
+ ## {{page-title}} @@ -27,5 +30,9 @@ This is a pre-release of v1.0.0-alpha.2 - Referrals into a broker for Healthcare | Task.code.coding.code | This MUST be populated with the Code (SNOMED) of action by the Pharmacy Service | This MUST be populated with the Code (SNOMED) of action | Update | Referral Response |Change | non-breaking | | Task.code.coding.display | This MUST be populated with the human readable Display (SNOMED) of action by the Pharmacy Service | This MUST be populated with the human readable Display (SNOMED) of action | Update | Referral Response |Change | non-breaking | + +
+
+

diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md new file mode 100644 index 00000000..f37caec2 --- /dev/null +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md @@ -0,0 +1,24 @@ +## {{page-title}} + + +This is a pre-release of v1.0.0-alpha.3 - Referrals into a broker for Healthcare Service selection + +
+ + +### Application Change Log + + +| Change | Description | Impact | +|-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| + + +### 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 4b623dd6..3b7d6839 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,5 +1,7 @@ - name: Index filename: Index.page.md +- name: 1.0.0-alpha.3 + filename: 1.0.0-alpha.3.page.md - name: 1.0.0-alpha.2 filename: 1.0.0-alpha.2.page.md - name: 1.0.0-alpha From 42b555f8817d7a07a74e93a28844dd9fa469d443 Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 3 Jul 2026 13:31:20 +0100 Subject: [PATCH 05/25] Changes requested App8 version matrix 1.11.1 --- .../Home/Analysis/Releases/Current-Releases.page.md | 6 +++--- .../Implementation-Guide-Change-Log/1.11.1.page.md | 2 +- .../BaRS-Applications/Applications/Index.page.md | 6 +++--- .../Home/Applications/BaRS-Pre-releases/Index.page.md | 6 +++--- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md index a6a26252..336b7098 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Current-Releases.page.md @@ -202,9 +202,9 @@ Table detailing active versions of the latest Applications in Production (or cur Application 8 v1.0.0-alpha.3 - v1.12.0 - v1.5.0 - 1.5.x + v1.12.0 + v1.5.0 + 1.5.x 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 index 2ba0d44e..12172e25 100644 --- 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 @@ -1,6 +1,6 @@
-
+
### 1.11.1 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 69b1abf3..43ee6113 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 @@ -202,9 +202,9 @@ Table detailing active versions of the latest Applications in Production (or cur Application 8 v1.0.0-alpha.3 - v1.12.0 - v1.5.0 - 1.5.x + v1.12.0 + v1.5.0 + 1.5.x 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 2fc5bc36..a7f62b7c 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 @@ -199,9 +199,9 @@ Table detailing active versions of the latest Applications in Production (or cur Application 8 v1.0.0-alpha.3 - v1.12.0 - v1.5.0 - 1.5.x + v1.12.0 + v1.5.0 + 1.5.x From 10a371fdd401baa53cee45c948a3bc7dc1b6b7d0 Mon Sep 17 00:00:00 2001 From: Derek Dreyer <56388818+d-dreyer@users.noreply.github.com> Date: Fri, 3 Jul 2026 13:54:07 +0100 Subject: [PATCH 06/25] NBRS-4831 - Update Use Case Category CodeSystem Updated the BaRS use case category code system to add "default" use cases per sender for apps 1, 2 and 4. --- CodeSystem/usecases-categories-bars.xml | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/CodeSystem/usecases-categories-bars.xml b/CodeSystem/usecases-categories-bars.xml index 11fab27e..957071d3 100644 --- a/CodeSystem/usecases-categories-bars.xml +++ b/CodeSystem/usecases-categories-bars.xml @@ -60,6 +60,18 @@ + + + + + + + + + + + + @@ -76,6 +88,14 @@ + + + + + + + + @@ -92,6 +112,10 @@ + + + + From a15a164901632a8a8bf27e6598f845ba1bffa2db Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 3 Jul 2026 14:18:14 +0100 Subject: [PATCH 07/25] NBRS-4779 Changes made to Referral Payload for App 8 Changes reflected in App 8 change log --- .../TRN-APP8/1.0.0-alpha.3.page.md | 9 +++++++-- .../Applications/BaRS-APP8/Referral-Payload.page.md | 12 ++++++------ 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md index f37caec2..0005d3d4 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md @@ -11,14 +11,19 @@ This is a pre-release of v1.0.0-alpha.3 - Referrals into a broker for Healthcare | Change | Description | Impact | |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| - +| Patient Identifier Resource | Updates to Referral Payload Implementation Guidance for multiple elements to improve clarity.|correction ### Payload Change Log | FHIR Element | Previous | Current | Other | Referral/Booking | Rationale | Impact | |------------------------------------------------------|----------|------------|---------|------------------|-------------------------------------------------------------------------------------------------|----------| - +| Patient.identifier.system | This SHOULD be populated with namespace for the Identifier. | This MUST be populated with namespace for the Identifier. | Update | Referral Response |Change | correction | +| Patient.identifier.value | This SHOULD be populated with a human readable patient identifier. When used this MUST be populated with the NHS number when available.If no NHS number is available this SHOULD be populated with the Local patient identifier. | This MUST be populated with a human readable patient identifier. When used this MUST be populated with the NHS number when available. | Update | Referral Response |Change | correction | +| Patient.identifier.extension.url | This SHOULD be populated. Where used this MUST be populated with Structure Definition 'https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus' - FIXED VALUE | This MUST be populated. Where used this MUST be populated with Structure Definition 'https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus' - FIXED VALUE | Update | Referral Response |Change | correction | +| Patient.identifier.extension.valueCodeableConcept.coding.system | This SHOULD be populated. Where used this MUST be populated with CodeSystem - 'https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus' - FIXED VALUE | This MUST be populated with CodeSystem - 'https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus' - FIXED VALUE | Update | Referral Response |Change | correction | +| Patient.identifier.extension.valueCodeableConcept.coding.code | This SHOULD be populated. Where used this MUST be 'number-present-and-verified' or 'number-present-but-not-traced', else no NHS number MUST be sent. No other statuses are permitted. | This MUST be populated. This MUST be 'number-present-and-verified' only. No other statuses are permitted. | Update | Referral Response |Change | correction | +| Patient.identifier.extension.valueCodeableConcept.coding.display | This SHOULD be populated. Where used this MUST be populated with 'Number present and verified' or 'Number present but not traced'. No other statuses are permitted. |This MUST be populated. This MUST be populated with 'Number present and verified'. No other statuses are permitted. | Update | Referral Response |Change | correction |

diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md index 9788f2d2..4300418f 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md @@ -237,15 +237,15 @@ This payload is used to transmit all the necessary information that is required | Patient.meta.profile | This MUST be populated. Follow UK Core guidance for populating this element | MUST | 1..1 | https://fhir.hl7.org.uk/StructureDefinition/UKCore-Patient | | Patient.meta.LastUpdate | This MUST be populated. 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 | | Patient.identifier | | MUST | 0..* | | -| Patient.identifier.system | This SHOULD be populated with namespace for the Identifier | MUST | 1..1 | https://fhir.nhs.uk/Id/nhs-number | -| Patient.identifier.value | This SHOULD be populated with a human readable patient identifier. When used this MUST be populated with the NHS number when available.If no NHS number is available this SHOULD be populated with the Local patient identifier. | MUST | 1..1 | 3478526985 | +| Patient.identifier.system | This MUST be populated with namespace for the Identifier | MUST | 1..1 | https://fhir.nhs.uk/Id/nhs-number | +| Patient.identifier.value | This MUST be populated with a human readable patient identifier. When used this MUST be populated with the NHS number when available. | MUST | 1..1 | 3478526985 | | Patient.identifier.extension | This extension is used to record the NHS number Verification status | MUST | 0..* | | -| Patient.identifier.extension.url | This SHOULD be populated. Where used this MUST be populated with Structure Definition 'https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus' - FIXED VALUE | MUST | 1..1 | https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus | +| Patient.identifier.extension.url | This MUST be populated. Where used this MUST be populated with Structure Definition 'https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus' - FIXED VALUE | MUST | 1..1 | https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus | | Patient.identifier.extension.valueCodeableConcept | | MUST | 0..1 | | | Patient.identifier.extension.valueCodeableConcept.coding | | MUST | 0..* | | -| Patient.identifier.extension.valueCodeableConcept.coding.system | This SHOULD be populated. Where used this MUST be populated with CodeSystem - 'https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus' - FIXED VALUE | MUST | 0..1 | https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus | -| Patient.identifier.extension.valueCodeableConcept.coding.code | This SHOULD be populated. Where used this MUST be 'number-present-and-verified' else no NHS number MUST be sent. No other statuses are permitted. | MUST | 0..1 | number-present-and-verified | -| Patient.identifier.extension.valueCodeableConcept.coding.display | This SHOULD be populated. Where used this MUST be populated with 'Number present and verified'. No other statuses are permitted. | MUST | 0..1 | Number present and verified | +| Patient.identifier.extension.valueCodeableConcept.coding.system | This MUST be populated with CodeSystem - 'https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus' - FIXED VALUE | MUST | 0..1 | https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus | +| Patient.identifier.extension.valueCodeableConcept.coding.code | This MUST be populated. This MUST be 'number-present-and-verified' only. No other statuses are permitted. | MUST | 0..1 | number-present-and-verified | +| Patient.identifier.extension.valueCodeableConcept.coding.display | This MUST be populated. This MUST be populated with 'Number present and verified'. No other statuses are permitted. | MUST | 0..1 | Number present and verified | | Patient.name | | SHOULD | 0..* | | | Patient.name.use | Follow UK Core guidance for populating this element | SHOULD | 0..1 | official | | Patient.name.text | Follow UK Core guidance for populating this element | SHOULD | 0..1 | Mrs Julie Jones | From eaa65db921bc4d0ddd04aa75ef80fe23aa57585f Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 3 Jul 2026 14:26:52 +0100 Subject: [PATCH 08/25] NBRS-4758 Added link for Hazard Log Added definitions text Edited typo to improve readability --- .../TRN-APP8/1.0.0-alpha.3.page.md | 1 + .../BaRS-APP8/Scope-and-Requirements.page.md | 9 +++++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md index 0005d3d4..0344d6dd 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/TRN-APP8/1.0.0-alpha.3.page.md @@ -12,6 +12,7 @@ This is a pre-release of v1.0.0-alpha.3 - Referrals into a broker for Healthcare | Change | Description | Impact | |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------| | Patient Identifier Resource | Updates to Referral Payload Implementation Guidance for multiple elements to improve clarity.|correction +| Scope and Requirements | Minor text changes and link to Hazard Log added|correction ### Payload Change Log 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 375b829f..c9dcfaef 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 @@ -42,13 +42,18 @@ The payload and workflow have been designed to support these services. Other {{p - BaRS currently supports the communication of consent for direct care only - Certificates for Receiving messages to use nhs.uk domains only - Receiving endpoints are to be internet facing -- Clincial Constraints exist - See Hazard Log +- Clincial Constraints exist - See [Hazard Log](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/onboarding-support-information#downloads) - No element level 'updates' to requests are supported. A new request must be generated to change information in the referral request - No digital support to remove or cancel a referral are offered (this would need to be achieved manually) - The service discovery tool for establishing services for onward care must be the [e-RS Service Search API A010](https://digital.nhs.uk/developer/api-catalogue/e-referral-service-fhir#post-/STU3/HealthcareService/$ers.searchHealthcareServicesForPatient) ### Requirements +Definitions used in these requirements: +- The referral Sender is the system/organisation making the referral request +- The referral Receiver is the system/organisation the referral is being sent to, in this specific case - the broker (e-RS) +- The end user is a person in an organisation using BaRS + **Service Discovery** - Where more than one service is shortlisted, the maximum number of services allowed on a given shortlist is 20. @@ -56,7 +61,7 @@ The payload and workflow have been designed to support these services. Other {{p - The referral Receiver **must** accept the referral request regardless of whether the patient is known to the service provider - The referral Receiver **must** only accept potential patients who **have** a national validated identifier e.g. NHS Number - The national identifier **must** have a [verification status](https://simplifier.net/hl7fhirukcorer4/valueset-ukcore-nhsnumberverificationstatus) of 'Number present and verified'. -- Any new or existing safeguarding concern, recorded as part of the assessment, **must** be included in the referral Sender's request +- Any new or existing safeguarding concern, recorded as part of the assessment, **must** be included in the referral request - The referral Receiver **must** clearly identify any included safeguarding concern to the end user - The referral Receiver **must** accurately represent information made by the Sender to the end user. - The referral Sender **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user From 5e0995d888a8d0eb4a77f0a640c60d3cc65e7851 Mon Sep 17 00:00:00 2001 From: luci-davies Date: Tue, 7 Jul 2026 09:10:35 +0100 Subject: [PATCH 09/25] Changes requested --- .../Applications/BaRS-APP8/Referral-Payload.page.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md index 4300418f..4be5caed 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP8/Referral-Payload.page.md @@ -238,9 +238,9 @@ This payload is used to transmit all the necessary information that is required | Patient.meta.LastUpdate | This MUST be populated. 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 | | Patient.identifier | | MUST | 0..* | | | Patient.identifier.system | This MUST be populated with namespace for the Identifier | MUST | 1..1 | https://fhir.nhs.uk/Id/nhs-number | -| Patient.identifier.value | This MUST be populated with a human readable patient identifier. When used this MUST be populated with the NHS number when available. | MUST | 1..1 | 3478526985 | +| Patient.identifier.value | This MUST be populated with a human readable patient identifier. This MUST be populated with the NHS number. | MUST | 1..1 | 3478526985 | | Patient.identifier.extension | This extension is used to record the NHS number Verification status | MUST | 0..* | | -| Patient.identifier.extension.url | This MUST be populated. Where used this MUST be populated with Structure Definition 'https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus' - FIXED VALUE | MUST | 1..1 | https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus | +| Patient.identifier.extension.url | This MUST be populated. This MUST be populated with Structure Definition 'https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus' - FIXED VALUE | MUST | 1..1 | https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus | | Patient.identifier.extension.valueCodeableConcept | | MUST | 0..1 | | | Patient.identifier.extension.valueCodeableConcept.coding | | MUST | 0..* | | | Patient.identifier.extension.valueCodeableConcept.coding.system | This MUST be populated with CodeSystem - 'https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus' - FIXED VALUE | MUST | 0..1 | https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatus | From 31b0ca6e870f1121178653b8d1fcf51d23b10442 Mon Sep 17 00:00:00 2001 From: Derek Dreyer <56388818+d-dreyer@users.noreply.github.com> Date: Tue, 7 Jul 2026 09:32:24 +0100 Subject: [PATCH 10/25] Spelling Error Corrections Made updates to multiple pages that duplicated the same spelling/grammar errors. --- .../1.0.1.page.md | 6 ++--- .../1.8.1.page.md | 2 +- .../Home/Analysis/Versioning.guide.md | 16 +++++++------- .../BaRS-APP1/Booking-Request-Payload.page.md | 14 ++++++------ .../BaRS-APP2/Booking-Request-Payload.page.md | 16 +++++++------- .../BaRS-APP3/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP3/Payloads.page.md | 2 +- .../BaRS-APP4/How-does-it-work.page.md | 4 ++-- .../BaRS-APP4/Payloads-for-Responders.page.md | 2 +- .../BaRS-APP6/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP6/Index.page.md | 2 +- .../BaRS-APP7/Booking-Request-Payload.page.md | 22 +++++++++---------- .../Core/1-0-7/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 4 ++-- .../Core/1-4-0/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1-4-1/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Core/1.0.4/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Core/1.0.5/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Core/1.0.6/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1.1.4/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1.1.5/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 4 ++-- .../Core/1.1.6/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1.2.0/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1.2.1/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1.2.2/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 4 ++-- .../Core/1.3.0/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 4 ++-- .../Core/1.3.1/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Helpandsupport/Glossary/Index.guide.md | 2 +- .../Releases/Release-Notes.guide.md | 2 +- .../1.0.1.page.md | 6 ++--- .../Home/About-BaRS/Versioning.guide.md | 2 +- .../BaRS-APP1/Booking-Request-Payload.page.md | 16 +++++++------- .../BaRS-APP2/Booking-Request-Payload.page.md | 16 +++++++------- .../BaRS-APP3/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP3/Payloads.page.md | 2 +- .../BaRS-APP4/How-does-it-work.page.md | 2 +- .../BaRS-APP4/Payloads-for-Responders.page.md | 2 +- .../BaRS-APP6/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP6/Index.page.md | 2 +- .../BaRS-APP7/Booking-Request-Payload.page.md | 16 +++++++------- .../BaRS-Core/BaRS-FHIR-usage.page.md | 2 +- .../Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Introduction.page.md | 2 +- .../Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md | 2 +- .../Home/Helpandsupport/Glossary.guide.md | 2 +- 57 files changed, 117 insertions(+), 117 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md index 857b594f..73051ea9 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md @@ -9,10 +9,10 @@ | Change | Description | |--------------------------------------------------|----------------------------------------------------------------------------------------------------------| | Fixed issue with menu in Design/BaRS Core | The "Failure Scenarios" subsection had an erroneous entry in left-hand navigation. This has been removed | -| Updated release notes structure | This change was to accomodate historical releases by hiding them in an expander | +| Updated release notes structure | This change was to accommodate historical releases by hiding them in an expander | | Improved release notes navigation | a "back" button was added to each of the release note detail sections | | Updated FHIR assets section | Simplified approach with a link out to the full Simplifier project | -| TKW - Updated context description | Now includes detail of deployment on INT and rationale adopting this appraoch | +| TKW - Updated context description | Now includes detail of deployment on INT and rationale adopting this approach | | TKW - Corrected sentinel values | Some sentinel values for referencing UserTest DoS were out of date and did not return | | TKW - Updated Response scenarios | Added the sentinel values, under the Scenarios section, to elicit responses for interim and full Validation responses | | TKW - Added table of DoS Service Ids | Table of DoS Service Ids and how to obtain them to use as sentinel values for TKW Scenarios | @@ -20,7 +20,7 @@ | BARS-UEC-1 Application | Corrected how elements ServiceRequest.supportInfo and CarePlan.supportingInfo must be populated | | BARS-UEC-2 Application | Corrected how elements ServiceRequest.supportInfo and CarePlan.supportingInfo must be populated | | Fixed broken or incorrect links on "Home Page" | Some links were linking to the wrong page | -| Help and Support - fixed broken external links | Some external linkswere broken or still "boiler plate" links | +| Help and Support - fixed broken external links | Some external links were broken or still "boiler plate" links | | Updated Change Log naming | Change Log names have been changed to more in line with the rest of the change log names | | Updated wording on releases | Wording of guidance around support for new releases of Core was updated to provide more clarity | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.1.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.1.page.md index ab95eb27..e14968ab 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.1.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.1.page.md @@ -11,7 +11,7 @@ | Existing use case categories have been corrected where needed | existing use case categories have been corrected where required | | BaRS Core addition of use context header | HTTP header for auditing and logging has been added to assist with NHSE reporting. | | Bug fixes and corrections |There have been several bug fixes and corrections in the guide, these includes typos, broken links or corrections.| -| Improvements to the the Build Section | Several improvements to the Testing and Environments pages | +| Improvements to the Build Section | Several improvements to the Testing and Environments pages | | Application 6 TKW changes | Application 6 is now available in the TKW |

diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md index ba4ff6f6..5b11d772 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md @@ -8,7 +8,7 @@ The Booking and Referral Standard (BaRS) will follow [Semantic Versioning](https Full details can be found at the [Semantic Versioning](https://semver.org/) site, key points outlined below: #### Major version -The major version is incremented when an incompatible changes are made, i.e. a non backwards compatible change. +The major version is incremented when incompatible changes are made, i.e. a non backwards compatible change. #### Minor version The minor version increments when changes are made in a backwards compatible manner. @@ -39,14 +39,14 @@ Breaking change will always be considered before being implemented, the overhead ### **For the Core elements of BaRS (BaRS Core) suppliers will be expected to revise their solution to support a MAJOR release within six months from the version release date** -Note: Major releases of BaRS Core will be NO LESS than SIX MONTHS from the preceeding major release +Note: Major releases of BaRS Core will be NO LESS than SIX MONTHS from the preceding major release

{{render:versioning.png}}
-Compatibilty is verified dynamically during workflows through the 'version' element defined on the Capability Statement and Message Definitions. Senders and Receivers should operate on the highest version they are both compatible with and negoitate down, where possible. +Compatibility is verified dynamically during workflows through the 'version' element defined on the Capability Statement and Message Definitions. Senders and Receivers should operate on the highest version they are both compatible with and negotiate down, where possible. A Sender **must** check the returned 'version' in these resources before proceeding to make requests of a Receiver. For version 1.0.0 **only** versions within the major version v1.0.0 should be considered compatible (1.0.0 extensions excluded):- @@ -61,7 +61,7 @@ A Receiver **should** check the version a Sender is expecting interoperate on by ### Pre-release Labels -These labels will be taken from the GDS (Goverment Digital Services) development process stages, and will be one of: +These labels will be taken from the GDS (Government Digital Services) development process stages, and will be one of: * **Discovery**: a Feasibility study. A 'No code' development. Designed to find out what users are trying to achieve, any constraints, improvement opportunities @@ -69,11 +69,11 @@ These labels will be taken from the GDS (Goverment Digital Services) development * **Private Beta**: Working version and test with invited users. Handle real transactions and work at scale. ‘Invite only’ or regional. Must Pass assessment by business and technical SME’s -* **Public Beta**: All users can participate. Version unlikely to change substantially, but still needs further testing by a wider group of implementors before becoming live +* **Public Beta**: All users can participate. Version unlikely to change substantially, but still needs further testing by a wider group of implementers before becoming live * **Live**: The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements -* **Retiring**: Implementors notified that the service is discontinued and not to be used for new developments +* **Retiring**: Implementers notified that the service is discontinued and not to be used for new developments
@@ -88,7 +88,7 @@ APIs should have the ability to route traffic based on the version header as sho -API Versioning between entities is fairly loose, only the major versioning differences would case a failure. with the exception of new endpoints which will be gated by minor versioning. The diagram below shows desired behavior in all versioning negotiations at the API. +API Versioning between entities is fairly loose, only the major versioning differences would case a failure. with the exception of new endpoints which will be gated by minor versioning. The diagram below shows desired behaviour in all versioning negotiations at the API. @@ -102,7 +102,7 @@ The CapabilityStatement, coupled with the Accept header can define what version ### MessageDefinition (step 3) -The serviceID will help dictate what MessageDefinitions are returned and ensure they are specifiic to the service being queried. The version of the MessageDefinitions returned would be linked to the version of the Use case. The use case is identified using the useContext element. +The serviceID will help dictate what MessageDefinitions are returned and ensure they are specific to the service being queried. The version of the MessageDefinitions returned would be linked to the version of the Use case. The use case is identified using the useContext element. For example, a service could service multiple applications covered by a single message definition, of varying versions. They would then choose the version of the message definition most appropriate for the use case. Knowing, from Service Discovery, that the Receiver accepts that type of referral and that it requires that version of the messageDefinition. 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 c945ddf8..676f2f94 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 @@ -24,7 +24,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | 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 | @@ -51,7 +51,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.nhs.uk/StructureDefinition/BARSMessageHeader-booking-request, hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | MessageHeader | https://simplifier.net/nhsbookingandreferrals/barsmessageheaderbookingrequest-duplicate-2 | | 1..1 | | | MessageHeader.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | @@ -170,7 +170,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Patient | https://simplifier.net/hl7fhirukcorer4/ukcore-patient | | 1..1 | | | Patient.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 9589fb37-87a2-48d8-968f-b371429208a8 | @@ -245,7 +245,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Organization , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Organization | https://simplifier.net/hl7fhirukcorer4/ukcore-organization | | 2..* | | | Organization.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 5d897313-c62d-4e7e-92b7-b2199804fed3 | @@ -268,7 +268,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Practitioner | https://simplifier.net/hl7fhirukcorer4/ukcore-practitioner | |0..* | | | Practitioner.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 51182cb1-b199-4222-85f5-16d5428f6358 | @@ -297,7 +297,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | PractitionerRole | https://simplifier.net/hl7fhirukcorer4/ukcore-practitionerrole | | 0..* | | | PractitionerRole.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | @@ -326,7 +326,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-HealthcareService , hybrid}} -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | HealthcareService | https://simplifier.net/hl7fhirukcorer4/ukcore-healthcareservice | | 1..1 | | | HealthcareService.id | This MUST be populated with the value retrieved for the resource via the GET /Sot request. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | 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 68d28e36..a587be97 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 @@ -24,7 +24,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | 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 | @@ -51,7 +51,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.nhs.uk/StructureDefinition/BARSMessageHeader-booking-request, hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | MessageHeader | https://simplifier.net/nhsbookingandreferrals/barsmessageheaderbookingrequest-duplicate-2 | | 1..1 | | | MessageHeader.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | @@ -108,7 +108,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Appointment | https://simplifier.net/hl7fhirukcorer4/ukcore-appointment

This resource will be used to communicate information about an appointment. | | 1..1 | | | Appointment.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 3713c8fc-dbcf-4f90-bacf-89d99e434e9b | @@ -171,7 +171,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Patient | https://simplifier.net/hl7fhirukcorer4/ukcore-patient | | 1..1 | | | Patient.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 9589fb37-87a2-48d8-968f-b371429208a8 | @@ -246,7 +246,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Organization , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Organization | https://simplifier.net/hl7fhirukcorer4/ukcore-organization | | 2..* | | | Organization.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 5d897313-c62d-4e7e-92b7-b2199804fed3 | @@ -269,7 +269,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Practitioner | https://simplifier.net/hl7fhirukcorer4/ukcore-practitioner | |0..* | | | Practitioner.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 51182cb1-b199-4222-85f5-16d5428f6358 | @@ -298,7 +298,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | PractitionerRole | https://simplifier.net/hl7fhirukcorer4/ukcore-practitionerrole | | 0..* | | | PractitionerRole.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | @@ -327,7 +327,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-HealthcareService , hybrid}} -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | HealthcareService | https://simplifier.net/hl7fhirukcorer4/ukcore-healthcareservice | | 1..1 | | | HealthcareService.id | This MUST be populated with the value retrieved for the resource via the GET /Sot request. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | 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 af695c9d..11da3c80 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 @@ -16,7 +16,7 @@ This workflow details a referral into a CAS from a 999 Ambulance Service Trust ( - Prior to referral the 999 AST will undertake a triage of the patient to determine the acuity of the case. This will typically be undertaken by a call handler on the Computer Aided Dispatch system (CAD) using an approved Clinical Decision Support System (CDSS) such as NHS Pathways or AMPDS. For cases with a non-ambulance disposition (CAT5), local business rules will be applied to determine if the case meets the requirement for referral to a CAS for consultation. - For cases requiring a referral to CAS, a suitable CAS is identified based on the patient’s clinical need and location. Service discovery will use local directories or UEC DOS to ascertain the Service ID - The Service ID is used to query the BaRS endpoint catalogue to identify the receiving CAS system's endpoint details. This process is happening in the background that Senders and Receivers do not need to manage. -- The 999-AST will send the referral to the CAS via the BaRS Proxy, including the information required by a CAS Clinician to continue the patent's clinical care. This will also include the Journey ID created at the patient's first contact. +- The 999-AST will send the referral to the CAS via the BaRS Proxy, including the information required by a CAS Clinician to continue the patient's clinical care. This will also include the Journey ID created at the patient's first contact. - The CAS system will acknowledge the referral on receipt, after which the case may be closed by the 999 AST on the CAD. It should be noted that Duty of care is passed from the 999 AST with the referral and is considered accepted by the CAS on receipt of the acknowledgement. - Prior to the consultation the case will typically be posted to a queue for prioritisation, based on information in the referral. This may be based on the call back time, determined locally or nationally based on the triage outcome codes. E.g. Where cases have a Pathways disposition (Dx) these are prioritised in accordance with the criteria specified in the IUC CAS service specification which sets out call-back times by Dx code. - The CAS Clinician will contact the patient, or their representative, utilising information in the referral message, then undertakes a consultation which may include a triage. The consultation will be informed by the clinical information sent by the referring service. This will be recorded in the CAS system. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md index bca71813..ed0dfe6c 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md @@ -46,7 +46,7 @@ When a BARS Sender populates the Location resource: * what3words * They **should** populate the *Location.address* for all property based locations. -* They **should** populate *Location.address.line* which is a repeatable element, with the the order in which lines should appear in an address label +* They **should** populate *Location.address.line* which is a repeatable element, with the order in which lines should appear in an address label * They **should** populate *Location.name* when there is a property name * They **should** populate *Location.address.text* with a text representation of the full address (including the address name), with each line separated by a comma 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 fe46487f..82459aa9 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 @@ -7,7 +7,7 @@ topic: APP4-HowDoesItWork This section describes how the primary operations used in this application work. -Application 4 supports complex workflows which include enabling the the Requester to: +Application 4 supports complex workflows which include enabling the Requester to: * Refer a patient for a specified activity to be carried out within a stated timescale (breach time) * Receive notification of if the referral has been rejected or accepted and is in progress (Interim Validation Response) * Retrieve the case by cancelling the referral @@ -38,7 +38,7 @@ This details a 999 Ambulance Service Trust (Requester) Referral into the followi - Prior to making a Validation Request, the Requester will undertake a triage of the patient to determine the acuity of the case. This will typically be undertaken by a call handler on the Computer Aided Dispatch (CAD) system, using an approved Clinical Decision Support System (CDSS) such as NHS Pathways or AMPDS. For cases with an ambulance disposition, local business rules will be applied to determine if the case meets the requirement for validation by a CAS clinician, Falls Community service Healthcare Professional (HCP). For cases requiring clinical validation in a CAS, this will usually be Ambulance Response Programme (ARP) priority C3 and C4 cases, but may include C2 segmentation cases, subject to local agreements between the 999 AST and the CAS. - A suitable Responder service is identified, based on the patient’s clinical need and location. Service discovery will use local directories or UEC DOS to ascertain the ServiceID - The Service ID is used to query the BaRS Endpoint Catalogue to identify the Receiver's endpoint details. -- The Requester will send the Validation Request to the Responder, which includes information required by an appropriate HCP to continue the patent's clinical care. This will also include the JourneyID created at the patient's first contact. +- The Requester will send the Validation Request to the Responder, which includes information required by an appropriate HCP to continue the patient's clinical care. This will also include the JourneyID created at the patient's first contact. - The Responder will acknowledge the Validation Request on receipt. - On receipt of the Acknowledgement (synchronous response), the Requester may move the case to a 'pending' stack. If the case exceeds the validation breach time before a validation response is received, a fail-safe process should be implemented to ensure that an ambulance is dispatched within the time frame determined by the original triage outcome. - If additional or changed information about the case is captured by the Requester subsequent to sending the Validation Request, but prior to receiving an Interim Validation Response or Validation Response, they may send a Validation Request Update to ensure that the Responder has the most up to date information. 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 17617880..425dfe64 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 @@ -104,7 +104,7 @@ When a BARS Responder populates the Location resource: * what3words * They **should** populate the *Location.address* for all property based locations. -* They **should** populate *Location.address.line* which is a repeatable element, with the the order in which lines should appear in an address label +* They **should** populate *Location.address.line* which is a repeatable element, with the order in which lines should appear in an address label * They **should** populate *Location.address.name* when there is a property name * They **should** populate *Location.address.text* with a text representation of the full address (including the address name), with each line separated by a comma 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 f6fcac63..ce5599d6 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 @@ -90,7 +90,7 @@ Note: The BaRS Referral may be used to support single patient Mutual aid request - The referral Receiver is identified based on nationally agreed polygons that set geographic boundaries of responsibility for each AST. Service discovery will use these polygons to ascertain the ServiceID of the referral Receiver. - The Service ID is used to query the BaRS Endpoint Catalogue to identify the referral Receiver's CAD system's endpoint details - The sender will check that the Receiver supports the intended Referral use case before sending. -- The referral Sender will send the BaRS Referral to the referral Receiver, which includes information required by the referral Receiver to continue the patent's clinical care. This will also include the JourneyID created at the patient's first contact. +- The referral Sender will send the BaRS Referral to the referral Receiver, which includes information required by the referral Receiver to continue the patient's clinical care. This will also include the JourneyID created at the patient's first contact. ### Create Case - 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 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md index 59ceddcc..cd58e2a8 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md @@ -61,7 +61,7 @@ This page provides guidance for implementing the Referral Standard (BaRS) specif The referral information data model is based on user research with NHS 111 service providers, 999 Ambulance Service Trusts, Clinical Assessment Services and clinical and administrative Emergency Department staff. We carried out this research in parallel with the [Professional Records Standards Body (PRSB)](https://theprsb.org/) who examined the wider brief of 'referrals from NHS 111 to any other care setting' -For the CAD to CAD use case, the data model was agreed by the CAD to CAD Reference Group following a period of user research involving site visits, Reference Group workshops and desk research. This was endorsed by the CAD to CAD Working Group and shared with the the following organisations: +For the CAD to CAD use case, the data model was agreed by the CAD to CAD Reference Group following a period of user research involving site visits, Reference Group workshops and desk research. This was endorsed by the CAD to CAD Working Group and shared with the following organisations: * National Ambulance Programme Board (NAPB) * National Ambulance Advisory Group (NAAG) 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 ad57f787..f110c7ea 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 @@ -24,7 +24,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | 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 | @@ -51,7 +51,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.nhs.uk/StructureDefinition/BARSMessageHeader-booking-request, hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | MessageHeader | https://simplifier.net/nhsbookingandreferrals/barsmessageheaderbookingrequest-duplicate-2 | | 1..1 | | | MessageHeader.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | @@ -108,7 +108,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Appointment | https://simplifier.net/hl7fhirukcorer4/ukcore-appointment | | 1..1 | | | Appointment.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 3713c8fc-dbcf-4f90-bacf-89d99e434e9b | @@ -146,7 +146,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Slot , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Slot | This resource will be used to communicate information about the slot. The Slot resource retrieved via the GET /Slot request and MUST be returned how it was received

https://simplifier.net/hl7fhirukcorer4/ukcoreslot | | 1..1 | | | Slot.id | Id returned as part of the GET /Slot response | Must | 1..1 | e267afc4-4310-4549-b66a-5bc4db08f09b | @@ -181,7 +181,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Schedule , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Schedule | This resource will be used to communicate information about the schedule. The Schedule resource retrieved via the GET /Slot request and MUST be returned how it was received

https://simplifier.net/hl7fhirukcorer4/ukcoreschedule | | 1..1 | | | Schedule.id | Id returned as part of the GET /Slot response | Must | 1..1 | e267afc4-4310-4549-b66a-5bc4db08f09b | @@ -197,7 +197,7 @@ This payload is used to support a booking workflow and contains all the required | Schedule.serviceCategory.coding.code | This MUST be populated with the code of the 'service' | MUST | 0..1 | 17 | | Schedule.serviceCategory.coding.display | This MUST be populated with the display of the 'service' | MUST | 0..1 | General Practice | | Schedule.actor | UKCore | Must | 1..* | | -| Schedule.actor.referrence | This MUST be populated with the Healthcare Service, PractitionerRole, Practitioner in seperate actors. | Must | 0..1 | 6daaadd8-56e0-4d74-8350-1632331c5452 | +| Schedule.actor.referrence | This MUST be populated with the Healthcare Service, PractitionerRole, Practitioner in separate actors. | Must | 0..1 | 6daaadd8-56e0-4d74-8350-1632331c5452 | @@ -213,7 +213,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Patient | https://simplifier.net/hl7fhirukcorer4/ukcore-patient | | 1..1 | | | Patient.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 9589fb37-87a2-48d8-968f-b371429208a8 | @@ -288,7 +288,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Organization , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Organization | https://simplifier.net/hl7fhirukcorer4/ukcore-organization | | 2..* | | | Organization.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 5d897313-c62d-4e7e-92b7-b2199804fed3 | @@ -311,7 +311,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Practitioner | https://simplifier.net/hl7fhirukcorer4/ukcore-practitioner | |0..* | | | Practitioner.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 51182cb1-b199-4222-85f5-16d5428f6358 | @@ -340,7 +340,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | PractitionerRole | https://simplifier.net/hl7fhirukcorer4/ukcore-practitionerrole | | 0..* | | | PractitionerRole.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | @@ -369,7 +369,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-HealthcareService , hybrid}} -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | HealthcareService | https://simplifier.net/hl7fhirukcorer4/ukcore-healthcareservice | | 1..1 | | | HealthcareService.id | This MUST be populated with the value retrieved for the resource via the GET /Sot request. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-0-7/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-0-7/BaRS-FHIR-Usage/Bundle.page.md index f20df435..10119ec8 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-0-7/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-0-7/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.0.7 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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-0/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-0/Appointment-StandardPattern/Introduction.page.md index be392d9a..a39676a3 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-0/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-0/Appointment-StandardPattern/Introduction.page.md @@ -12,7 +12,7 @@ topic: core-StandardPattern-appointment-Introduction-1.4.0 The [BaRS API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir) suite can be used where there is no specific use-case supported by the {{pagelink:Home/Applications/BaRS-Applications, text:Applications}} to fulfil generic Appointment workflows, referred to as Appointment Management Foundation. This section outlines the functionality supported, workflows involved and how these correspond with the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.0). -This includes using {{pagelink:core-StandardPattern-document-reference-1.4.0, text: Standard Pattern DocumentReference}} to write pointers for bookings to a central respository, commonly referred to as the Registry. +This includes using {{pagelink:core-StandardPattern-document-reference-1.4.0, text: Standard Pattern DocumentReference}} to write pointers for bookings to a central repository, commonly referred to as the Registry. The Appointment Management Foundation is based on {{pagelink:design-core-1.4.0, text:BaRS Core}} and an understanding of the central tenets is essential before beginning. This includes: - * {{pagelink:core-EndToEndWorkflow-1.4.0, text:End to end workflow }} - how Senders and Receivers, interacting through the central Proxy, negotiate compatibility and engage @@ -32,7 +32,7 @@ The ability to - ## Interface -The following table describes how the BaRS API accomodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.0#put-/Appointment/-id-) endpoint +The following table describes how the BaRS API accommodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.0#put-/Appointment/-id-) endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-0/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-0/BaRS-FHIR-Usage/Bundle.page.md index e33390d5..7e32c8fb 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-0/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-0/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.4.0 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1-4-1/Appointment-StandardPattern/Introduction.page.md index 9d84d288..a8b7f52d 100644 --- 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 @@ -32,7 +32,7 @@ The ability to - ## Interface -The following table describes how the BaRS API accomodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#put-/Appointment/-id-) endpoint +The following table describes how the BaRS API accommodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.4.1#put-/Appointment/-id-) endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| 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 index c054d39d..bc2adc85 100644 --- 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 @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.4.1 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.0.3/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md index 4e4619c9..92a8089a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.0.3 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.0.4/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.4/BaRS-FHIR-Usage/Bundle.page.md index dcd04063..7198474c 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.4/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.4/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.0.4 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.0.5/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.5/BaRS-FHIR-Usage/Bundle.page.md index 682576b1..440ab4d6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.5/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.5/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.0.5 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.0.6/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/BaRS-FHIR-Usage/Bundle.page.md index 6b16268c..d6406baa 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.6/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.0.6 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.1.3/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.3/Appointment-StandardPattern/Introduction.page.md index d5d1d4b5..5e43741d 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.3/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.3/Appointment-StandardPattern/Introduction.page.md @@ -19,7 +19,7 @@ There are 4 capabilities that are required surrounding appointments. This sectio ## interface -The following table describes how the BaRS API accomodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint +The following table describes how the BaRS API accommodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md index 8eff433a..faf8fce3 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.1.3 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.1.4/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.4/Appointment-StandardPattern/Introduction.page.md index f57a7e76..4e5268f3 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.4/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.4/Appointment-StandardPattern/Introduction.page.md @@ -19,7 +19,7 @@ There are 4 capabilities that are required surrounding appointments. This sectio ## interface -The following table describes how the BaRS API accomodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint +The following table describes how the BaRS API accommodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.4/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.4/BaRS-FHIR-Usage/Bundle.page.md index 780ea678..8024be81 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.4/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.4/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.1.4 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.1.5/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.5/Appointment-StandardPattern/Introduction.page.md index 4339eada..64c298a6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.5/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.5/Appointment-StandardPattern/Introduction.page.md @@ -19,7 +19,7 @@ There are 4 capabilities that are required surrounding appointments. This sectio ## interface -The following table describes how the BaRS API accomodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint +The following table describes how the BaRS API accommodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.5/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.5/BaRS-FHIR-Usage/Bundle.page.md index 10197a7d..1fce08b4 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.5/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.5/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.1.5 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.1.6/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md index 87abf1ef..2d5f4b94 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md @@ -12,7 +12,7 @@ topic: core-StandardPattern-appointment-Introduction-1.1.6 The [BaRS API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir) suite can be used where there is no specific use-case supported by the {{pagelink:Home/Applications/BaRS-Applications, text:Applications}} to fulfil generic Appointment workflows, referred to as Appointment Management Foundation. This section outlines the functionality supported, workflows involved and how these correspond with the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0). -This includes using {{pagelink:core-StandardPattern-document-reference-1.1.6, text: DocumentReference Standard Pattern}} to write pointers for Appointments to a central respository, commonly referred to as the Registry. +This includes using {{pagelink:core-StandardPattern-document-reference-1.1.6, text: DocumentReference Standard Pattern}} to write pointers for Appointments to a central repository, commonly referred to as the Registry. The Appointment Management Foundation is based on {{pagelink:design-core-1.1.6, text:BaRS Core}} and an understanding of the central tenets is essential before beginning. This includes: - * {{pagelink:core-EndToEndWorkflow-1.1.6, text:End to end workflow }} - how Senders and Receivers, interacting through the central Proxy, negotiate compatibility and engage @@ -29,7 +29,7 @@ There are four functions that are required surrounding appointments. This sectio ## Interface -The following table describes how the BaRS API accomodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#put-/Appointment/-id-) endpoint +The following table describes how the BaRS API accommodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#put-/Appointment/-id-) endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/BaRS-FHIR-Usage/Bundle.page.md index 7aed2236..0384fdff 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.1.6 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.2.0/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.0/Appointment-StandardPattern/Introduction.page.md index 326b9e09..043c862f 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.0/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.0/Appointment-StandardPattern/Introduction.page.md @@ -19,7 +19,7 @@ There are 4 capabilities that are required surrounding appointments. This sectio ## interface -The following table describes how the BaRS API accomodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint +The following table describes how the BaRS API accommodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.0/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.0/BaRS-FHIR-Usage/Bundle.page.md index 111a7d46..813bf264 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.0/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.0/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.2.0 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.2.1/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.1/Appointment-StandardPattern/Introduction.page.md index 9c60096f..ceeff656 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.1/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.1/Appointment-StandardPattern/Introduction.page.md @@ -19,7 +19,7 @@ There are 4 capabilities that are required surrounding appointments. This sectio ## interface -The following table describes how the BaRS API accomodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint +The following table describes how the BaRS API accommodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.1/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.1/BaRS-FHIR-Usage/Bundle.page.md index fec47005..a72b6604 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.1/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.1/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.2.1 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.2.2/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Introduction.page.md index 2151eafc..fdcf076a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Introduction.page.md @@ -29,7 +29,7 @@ There are four functions that are required surrounding appointments. This sectio ## Interface -The following table describes how the BaRS API accomodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) endpoint +The following table describes how the BaRS API accommodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/BaRS-FHIR-Usage/Bundle.page.md index b5d049ea..53b6aa7d 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.2.2 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.3.0/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Introduction.page.md index 701614b0..b4f33576 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Introduction.page.md @@ -12,7 +12,7 @@ topic: core-StandardPattern-appointment-Introduction-1.3.0 The [BaRS API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir) suite can be used where there is no specific use-case supported by the {{pagelink:Home/Applications/BaRS-Applications, text:Applications}} to fulfil generic Appointment workflows, referred to as Appointment Management Foundation. This section outlines the functionality supported, workflows involved and how these correspond with the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0). -This includes using {{pagelink:core-StandardPattern-document-reference-1.3.0, text: DocumentReference Standard Pattern}} to write pointers for Appointments to a central respository, commonly referred to as the Registry. +This includes using {{pagelink:core-StandardPattern-document-reference-1.3.0, text: DocumentReference Standard Pattern}} to write pointers for Appointments to a central repository, commonly referred to as the Registry. The Appointment Management Foundation is based on {{pagelink:design-core-1.3.0, text:BaRS Core}} and an understanding of the central tenets is essential before beginning. This includes: - * {{pagelink:core-EndToEndWorkflow-1.3.0, text:End to end workflow }} - how Senders and Receivers, interacting through the central Proxy, negotiate compatibility and engage @@ -29,7 +29,7 @@ There are four functions that are required surrounding appointments. This sectio ## Interface -The following table describes how the BaRS API accomodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) endpoint +The following table describes how the BaRS API accommodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/BaRS-FHIR-Usage/Bundle.page.md index cf054ebc..bf5476f0 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.3.0 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.3.1/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Introduction.page.md index 3d370d27..0707650f 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Introduction.page.md @@ -12,7 +12,7 @@ topic: core-StandardPattern-appointment-Introduction-1.3.1 The [BaRS API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir) suite can be used where there is no specific use-case supported by the {{pagelink:Home/Applications/BaRS-Applications, text:Applications}} to fulfil generic Appointment workflows, referred to as Appointment Management Foundation. This section outlines the functionality supported, workflows involved and how these correspond with the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0). -This includes using {{pagelink:core-StandardPattern-document-reference-1.3.1, text: Standard Pattern DocumentReference}} to write pointers for bookings to a central respository, commonly referred to as the Registry. +This includes using {{pagelink:core-StandardPattern-document-reference-1.3.1, text: Standard Pattern DocumentReference}} to write pointers for bookings to a central repository, commonly referred to as the Registry. The Appointment Management Foundation is based on {{pagelink:design-core-1.3.1, text:BaRS Core}} and an understanding of the central tenets is essential before beginning. This includes: - * {{pagelink:core-EndToEndWorkflow-1.3.1, text:End to end workflow }} - how Senders and Receivers, interacting through the central Proxy, negotiate compatibility and engage @@ -32,7 +32,7 @@ The ability to - ## Interface -The following table describes how the BaRS API accomodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) endpoint +The following table describes how the BaRS API accommodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) endpoint and the [/Appointment/\{id\}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/BaRS-FHIR-Usage/Bundle.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/BaRS-FHIR-Usage/Bundle.page.md index ed470960..6c4b9ce2 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.3.1 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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/Helpandsupport/Glossary/Index.guide.md b/guides/Live-ImplementationGuide-BaRS/Home/Helpandsupport/Glossary/Index.guide.md index 479c4787..634ffcfb 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Helpandsupport/Glossary/Index.guide.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Helpandsupport/Glossary/Index.guide.md @@ -5,7 +5,7 @@ topic: glossary ## Glossary

-Below is a non exhaustive list of terms used throughout the BaRS documentation. +Below is a non-exhaustive list of terms used throughout the BaRS documentation.

|Term / Abbreviation | What it stands for | diff --git a/guides/Training-guide-BARS/Home/About-BaRS/Releases/Release-Notes.guide.md b/guides/Training-guide-BARS/Home/About-BaRS/Releases/Release-Notes.guide.md index 998577d7..998c514a 100644 --- a/guides/Training-guide-BARS/Home/About-BaRS/Releases/Release-Notes.guide.md +++ b/guides/Training-guide-BARS/Home/About-BaRS/Releases/Release-Notes.guide.md @@ -1,4 +1,4 @@ ## Releases -This section contains the release notes for the various elements of the booking and referral standard. In the table below you will find information about each element and links the the detailed change logs. +This section contains the release notes for the various elements of the booking and referral standard. In the table below you will find information about each element and links the detailed change logs. diff --git a/guides/Training-guide-BARS/Home/About-BaRS/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md b/guides/Training-guide-BARS/Home/About-BaRS/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md index 857b594f..73051ea9 100644 --- a/guides/Training-guide-BARS/Home/About-BaRS/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md +++ b/guides/Training-guide-BARS/Home/About-BaRS/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.0.1.page.md @@ -9,10 +9,10 @@ | Change | Description | |--------------------------------------------------|----------------------------------------------------------------------------------------------------------| | Fixed issue with menu in Design/BaRS Core | The "Failure Scenarios" subsection had an erroneous entry in left-hand navigation. This has been removed | -| Updated release notes structure | This change was to accomodate historical releases by hiding them in an expander | +| Updated release notes structure | This change was to accommodate historical releases by hiding them in an expander | | Improved release notes navigation | a "back" button was added to each of the release note detail sections | | Updated FHIR assets section | Simplified approach with a link out to the full Simplifier project | -| TKW - Updated context description | Now includes detail of deployment on INT and rationale adopting this appraoch | +| TKW - Updated context description | Now includes detail of deployment on INT and rationale adopting this approach | | TKW - Corrected sentinel values | Some sentinel values for referencing UserTest DoS were out of date and did not return | | TKW - Updated Response scenarios | Added the sentinel values, under the Scenarios section, to elicit responses for interim and full Validation responses | | TKW - Added table of DoS Service Ids | Table of DoS Service Ids and how to obtain them to use as sentinel values for TKW Scenarios | @@ -20,7 +20,7 @@ | BARS-UEC-1 Application | Corrected how elements ServiceRequest.supportInfo and CarePlan.supportingInfo must be populated | | BARS-UEC-2 Application | Corrected how elements ServiceRequest.supportInfo and CarePlan.supportingInfo must be populated | | Fixed broken or incorrect links on "Home Page" | Some links were linking to the wrong page | -| Help and Support - fixed broken external links | Some external linkswere broken or still "boiler plate" links | +| Help and Support - fixed broken external links | Some external links were broken or still "boiler plate" links | | Updated Change Log naming | Change Log names have been changed to more in line with the rest of the change log names | | Updated wording on releases | Wording of guidance around support for new releases of Core was updated to provide more clarity | diff --git a/guides/Training-guide-BARS/Home/About-BaRS/Versioning.guide.md b/guides/Training-guide-BARS/Home/About-BaRS/Versioning.guide.md index 227a532f..f92070c8 100644 --- a/guides/Training-guide-BARS/Home/About-BaRS/Versioning.guide.md +++ b/guides/Training-guide-BARS/Home/About-BaRS/Versioning.guide.md @@ -8,7 +8,7 @@ The Booking and Referral Standard (BaRS) will follow [Semantic Versioning](https Full details can be found at the [Semantic Versioning](https://semver.org/) site, key points outlined below: #### Major version -The major version is incremented when an incompatible changes are made, i.e. a non backwards compatible change. +The major version is incremented when incompatible changes are made, i.e. a non backwards compatible change. #### Minor version The minor version increments when changes are made in a backwards compatible manner. diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md index 234ddc60..e65afe74 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md @@ -24,7 +24,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | 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 | @@ -50,7 +50,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.nhs.uk/StructureDefinition/BARSMessageHeader-booking-request, hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | MessageHeader | https://simplifier.net/nhsbookingandreferrals/barsmessageheaderbookingrequest-duplicate-2 | | 1..1 | | | MessageHeader.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | @@ -107,7 +107,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Appointment | https://simplifier.net/hl7fhirukcorer4/ukcoreappointment | | 1..1 | | | Appointment.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 3713c8fc-dbcf-4f90-bacf-89d99e434e9b | @@ -165,7 +165,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Patient | https://simplifier.net/hl7fhirukcorer4/ukcorepatient | | 1..1 | | | Patient.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 9589fb37-87a2-48d8-968f-b371429208a8 | @@ -240,7 +240,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Organization , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Organization | https://simplifier.net/hl7fhirukcorer4/ukcoreorganization | | 2..* | | | Organization.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 5d897313-c62d-4e7e-92b7-b2199804fed3 | @@ -263,7 +263,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Practitioner | https://simplifier.net/hl7fhirukcorer4/ukcorepractitioner | |0..* | | | Practitioner.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 51182cb1-b199-4222-85f5-16d5428f6358 | @@ -292,7 +292,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | PractitionerRole | https://simplifier.net/hl7fhirukcorer4/ukcorepractitionerrole | | 0..* | | | PractitionerRole.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | @@ -321,7 +321,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-HealthcareService , hybrid}} -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | HealthcareService | https://simplifier.net/hl7fhirukcorer4/ukcorehealthcareservice | | 1..1 | | | HealthcareService.id | This MUST be populated with the value retrieved for the resource via the GET /Sot request. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md index 6cdc2af0..6a027d83 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md @@ -24,7 +24,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | 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 | @@ -50,7 +50,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.nhs.uk/StructureDefinition/BARSMessageHeader-booking-request, hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | MessageHeader | https://simplifier.net/nhsbookingandreferrals/barsmessageheaderbookingrequest-duplicate-2 | | 1..1 | | | MessageHeader.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | @@ -107,7 +107,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Appointment | https://simplifier.net/hl7fhirukcorer4/ukcoreappointment | | 1..1 | | | Appointment.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 3713c8fc-dbcf-4f90-bacf-89d99e434e9b | @@ -165,7 +165,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Patient | https://simplifier.net/hl7fhirukcorer4/ukcorepatient | | 1..1 | | | Patient.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 9589fb37-87a2-48d8-968f-b371429208a8 | @@ -240,7 +240,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Organization , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Organization | https://simplifier.net/hl7fhirukcorer4/ukcoreorganization | | 2..* | | | Organization.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 5d897313-c62d-4e7e-92b7-b2199804fed3 | @@ -263,7 +263,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Practitioner | https://simplifier.net/hl7fhirukcorer4/ukcorepractitioner | |0..* | | | Practitioner.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 51182cb1-b199-4222-85f5-16d5428f6358 | @@ -292,7 +292,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | PractitionerRole | https://simplifier.net/hl7fhirukcorer4/ukcorepractitionerrole | | 0..* | | | PractitionerRole.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | @@ -321,7 +321,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-HealthcareService , hybrid}} -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | HealthcareService | https://simplifier.net/hl7fhirukcorer4/ukcorehealthcareservice | | 1..1 | | | HealthcareService.id | This MUST be populated with the value retrieved for the resource via the GET /Sot request. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md index 8a36ed22..7049155d 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md @@ -16,7 +16,7 @@ This workflow details a referral into a CAS from a 999 Ambulance Service Trust ( - Prior to referral the 999 AST will undertake a triage of the patient to determine the acuity of the case. This will typically be undertaken by a call handler on the Computer Aided Dispatch system (CAD) using an approved Clinical Decision Support System (CDSS) such as NHS Pathways or AMPDS. For cases with a non-ambulance disposition (CAT5), local business rules will be applied to determine if the case meets the requirement for referral to a CAS for consultation. - For cases requiring a referral to CAS, a suitable CAS is identified based on the patient’s clinical need and location. Service discovery will use local directories or UEC DOS to ascertain the Service ID - The Service ID is used to query the BaRS endpoint catalogue to identify the receiving CAS system's endpoint details. This process is happening in the background that Senders and Receivers do not need to manage. -- The 999-AST will send the referral to the CAS via the BaRS Proxy, including the information required by a CAS Clinician to continue the patent's clinical care. This will also include the Journey ID created at the patient's first contact. +- The 999-AST will send the referral to the CAS via the BaRS Proxy, including the information required by a CAS Clinician to continue the patient's clinical care. This will also include the Journey ID created at the patient's first contact. - The CAS system will acknowledge the referral on receipt, after which the case may be closed by the 999 AST on the CAD. It should be noted that Duty of care is passed from the 999 AST with the referral and is considered accepted by the CAS on receipt of the acknowledgement. - Prior to the consultation the case will typically be posted to a queue for prioritisation, based on information in the referral. This may be based on the call back time, determined locally or nationally based on the triage outcome codes. E.g. Where cases have a Pathways disposition (Dx) these are prioritised in accordance with the criteria specified in the IUC CAS service specification which sets out call-back times by Dx code. - The CAS Clinician will contact the patient, or their representative, utilising information in the referral message, then undertakes a consultation which may include a triage. The consultation will be informed by the clinical information sent by the referring service. This will be recorded in the CAS system. diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md index 23c04c2a..78fdf96d 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md @@ -46,7 +46,7 @@ When a BARS Sender populates the Location resource: * what3words * They **should** populate the *Location.address* for all property based locations. -* They **should** populate *Location.address.line* which is a repeatable element, with the the order in which lines should appear in an address label +* They **should** populate *Location.address.line* which is a repeatable element, with the order in which lines should appear in an address label * They **should** populate *Location.name* when there is a property name * They **should** populate *Location.address.text* with a text representation of the full address (including the address name), with each line separated by a comma diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md index ed14501e..018dc236 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md @@ -16,7 +16,7 @@ This details a 999 Ambulance Service Trust (AST) Referral into Clinical Assessme - Prior to making a Validation Request, the 999 AST will undertake a triage of the patient to determine the acuity of the case. This will typically be undertaken by a call handler on the Computer Aided Dispatch (CAD) system, using an approved Clinical Decision Support System (CDSS) such as NHS Pathways or AMPDS. For cases with an ambulance disposition, local business rules will be applied to determine if the case meets the requirement for validation by a CAS clinician. This will usually be Ambulance Response Programme (ARP) priority C3 and C4 cases, but may include C2 segmentation cases, subject to local agreements between the 999 AST and the CAS. - For cases requiring clinical validation, a suitable CAS is identified based on the patient’s clinical need and location. Service discovery will use local directories or UEC DOS to ascertain the ServiceID - The Service ID is used to query the BaRS Endpoint Catalogue to identify the receiving CAS system's endpoint details. -- The 999-AST will send the Validation Request to the CAS, which includes information required by a CAS Clinician to continue the patent's clinical care. This will also include the JourneyID created at the patient's first contact. +- The 999-AST will send the Validation Request to the CAS, which includes information required by a CAS Clinician to continue the patient's clinical care. This will also include the JourneyID created at the patient's first contact. - The CAS system will acknowledge the Validation Request on receipt. - On receipt of the Acknowledgment (synchronous response), the 999 AST CAD may move the case to a 'pending' stack. If the case exceeds the validation breach time before a validation response is received, a fail-safe process should be implemented to ensure that an ambulance is dispatched within the time frame determined by the original triage outcome. - If additional or changed information about the case is captured by the 999 AST subsequent to sending the Validation Request, but prior to receiving an Interim or Final Validation Response, they may send a Validation Request Update to ensure that the CAS has the most up to date information. diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md index 398459fa..9816047a 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Responders.page.md @@ -90,7 +90,7 @@ When a BARS Responder populates the Location resource: * what3words * They **should** populate the *Location.address* for all property based locations. -* They **should** populate *Location.address.line* which is a repeatable element, with the the order in which lines should appear in an address label +* They **should** populate *Location.address.line* which is a repeatable element, with the order in which lines should appear in an address label * They **should** populate *Location.address.name* when there is a property name * They **should** populate *Location.address.text* with a text representation of the full address (including the address name), with each line separated by a comma diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md index c4312783..263b3d3a 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md @@ -89,7 +89,7 @@ Calls may be re-routed by the BT Emergency Call Service to an Ambulance Service - The referral Receiver is identified based on nationally agreed polygons that set geographic boundaries of responsibility for each AST. Service discovery will use these polygons to ascertain the ServiceID of the referral Receiver. - The Service ID is used to query the BaRS Endpoint Catalogue to identify the referral Receiver's CAD system's endpoint details - The sender will check that the Receiver supports the intended Referral use case before sending. -- The referral Sender will send the BaRS Referral to the referral Receiver, which includes information required by the referral Receiver to continue the patent's clinical care. This will also include the JourneyID created at the patient's first contact. +- The referral Sender will send the BaRS Referral to the referral Receiver, which includes information required by the referral Receiver to continue the patient's clinical care. This will also include the JourneyID created at the patient's first contact. ### Create Case - 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 diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md index b3dc571b..9f455a01 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/Index.page.md @@ -59,7 +59,7 @@ This page provides guidance for implementing the Referral Standard (BaRS) specif The referral information data model is based on user research with NHS 111 service providers, 999 Ambulance Service Trusts, Clinical Assessment Services and clinical and administrative Emergency Department staff. We carried out this research in parallel with the [Professional Records Standards Body (PRSB)](https://theprsb.org/) who examined the wider brief of 'referrals from NHS 111 to any other care setting' -For the CAD to CAD use case, the data model was agreed by the CAD to CAD Reference Group following a period of user research involving site visits, Reference Group workshops and desk research. This was endorsed by the CAD to CAD Working Group and shared with the the following organisations: +For the CAD to CAD use case, the data model was agreed by the CAD to CAD Reference Group following a period of user research involving site visits, Reference Group workshops and desk research. This was endorsed by the CAD to CAD Working Group and shared with the following organisations: * National Ambulance Programme Board (NAPB) * National Ambulance Advisory Group (NAAG) diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md index 2763a05c..60801b4f 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Booking-Request-Payload.page.md @@ -24,7 +24,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | 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 | @@ -50,7 +50,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.nhs.uk/StructureDefinition/BARSMessageHeader-booking-request, hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | MessageHeader | https://simplifier.net/nhsbookingandreferrals/barsmessageheaderbookingrequest-duplicate-2 | | 1..1 | | | MessageHeader.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | @@ -107,7 +107,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Appointment | https://simplifier.net/hl7fhirukcorer4/ukcoreappointment | | 1..1 | | | Appointment.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 3713c8fc-dbcf-4f90-bacf-89d99e434e9b | @@ -165,7 +165,7 @@ This payload is used to support a booking workflow and contains all the required -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Patient | https://simplifier.net/hl7fhirukcorer4/ukcorepatient | | 1..1 | | | Patient.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 9589fb37-87a2-48d8-968f-b371429208a8 | @@ -240,7 +240,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-Organization , hybrid}}

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Organization | https://simplifier.net/hl7fhirukcorer4/ukcoreorganization | | 2..* | | | Organization.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | | 5d897313-c62d-4e7e-92b7-b2199804fed3 | @@ -263,7 +263,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Practitioner | https://simplifier.net/hl7fhirukcorer4/ukcorepractitioner | |0..* | | | Practitioner.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 51182cb1-b199-4222-85f5-16d5428f6358 | @@ -292,7 +292,7 @@ This payload is used to support a booking workflow and contains all the required

-| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | PractitionerRole | https://simplifier.net/hl7fhirukcorer4/ukcorepractitionerrole | | 0..* | | | PractitionerRole.id | This MUST only be populated with an id generated by the Receiver in the synchronous HTTP response. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | @@ -321,7 +321,7 @@ This payload is used to support a booking workflow and contains all the required {{tree:https://fhir.hl7.org.uk/StructureDefinition/UKCore-HealthcareService , hybrid}} -| Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | +| Data Item | Implementation Guidance | Necessity | Cardinality UKCore | Example Value(s) | |------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | HealthcareService | https://simplifier.net/hl7fhirukcorer4/ukcorehealthcareservice | | 1..1 | | | HealthcareService.id | This MUST be populated with the value retrieved for the resource via the GET /Sot request. | MUST | 1..1 | 1801e180-e6a1-4753-8a55-ab2d1cff6549 | diff --git a/guides/Training-guide-BARS/Home/Applications/BaRS-Core/BaRS-FHIR-usage.page.md b/guides/Training-guide-BARS/Home/Applications/BaRS-Core/BaRS-FHIR-usage.page.md index 7b3f5055..c1b8b857 100644 --- a/guides/Training-guide-BARS/Home/Applications/BaRS-Core/BaRS-FHIR-usage.page.md +++ b/guides/Training-guide-BARS/Home/Applications/BaRS-Core/BaRS-FHIR-usage.page.md @@ -40,7 +40,7 @@ You must implement a $process-message endpoint to be compliant with BaRS because 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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.

\ No newline at end of file diff --git a/guides/Training-guide-BARS/Home/Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md b/guides/Training-guide-BARS/Home/Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md index 4e4619c9..92a8089a 100644 --- a/guides/Training-guide-BARS/Home/Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Training-guide-BARS/Home/Core/1.0.3/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.0.3 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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/Training-guide-BARS/Home/Core/1.1.3/Appointment-StandardPattern/Introduction.page.md b/guides/Training-guide-BARS/Home/Core/1.1.3/Appointment-StandardPattern/Introduction.page.md index d5d1d4b5..5e43741d 100644 --- a/guides/Training-guide-BARS/Home/Core/1.1.3/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Training-guide-BARS/Home/Core/1.1.3/Appointment-StandardPattern/Introduction.page.md @@ -19,7 +19,7 @@ There are 4 capabilities that are required surrounding appointments. This sectio ## interface -The following table describes how the BaRS API accomodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint +The following table describes how the BaRS API accommodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| diff --git a/guides/Training-guide-BARS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md b/guides/Training-guide-BARS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md index 8eff433a..faf8fce3 100644 --- a/guides/Training-guide-BARS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md +++ b/guides/Training-guide-BARS/Home/Core/1.1.3/BaRS-FHIR-Usage/Bundle.page.md @@ -7,7 +7,7 @@ topic: core-FHIRUsage-bundle-1.1.3 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'. +- The $process-message endpoint is capable of receiving different types of request. The sender indicates 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/Training-guide-BARS/Home/Helpandsupport/Glossary.guide.md b/guides/Training-guide-BARS/Home/Helpandsupport/Glossary.guide.md index d7b54d4b..5e69965b 100644 --- a/guides/Training-guide-BARS/Home/Helpandsupport/Glossary.guide.md +++ b/guides/Training-guide-BARS/Home/Helpandsupport/Glossary.guide.md @@ -1,7 +1,7 @@ ## Glossary

-Below is a non exhaustive list of terms used throughout the BaRS documentation. +Below is a non-exhaustive list of terms used throughout the BaRS documentation.

|Term / Abbreviation | What it stands for | From 5ce02e9096ea3a29e3bf4638874f7df596b88323 Mon Sep 17 00:00:00 2001 From: luci-davies Date: Tue, 7 Jul 2026 10:28:53 +0100 Subject: [PATCH 11/25] NBRS-4740 Text changed as required. --- .../BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md | 2 +- .../BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md index 39822351..7f25da40 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md @@ -41,7 +41,7 @@ The Encounter is used to represent the interaction between a patient and healthc In the initial referral request, the Sender will include an Encounter resource as the container for their assessment, which established the need for the referral. This encounter **should** include a reference to the Sender's assessment under *encounter.identifier*. Additionally, the *encounter.episodeOfCare* **must** be populated with a 'Journey ID' reference which can be used in subsequent referrals to allow the audit of the route a patient took through service providers to resolve their initial request for care. -A second Encounter resource is used to transfer the human readable reference of the newly created referral, at the Receiver side. When a referral request is made, the Receiver **should** include a new, secondary, encounter resource with the status of 'planned' in their synchronous HTTP response to the Sender's request. This new 'planned' encounter will have both an Id and an Identifier value, indicating the Receiver's human readable and local references, respectively. This secondary, 'planned', encounter is not mandatory and has a cardinality of 0..1, unlike the primary encounter resource (1..1)(See the Entity Relationship Diagram for reference). The human readable (Identifier) reference is intended to allow Senders to provide something to the patient which they can take between services to support consistent joined up care, although, it is also a useful link for the services themselves to use when discussing a patient's transition of care. The local (Id) reference is not intended to be human readable but rather machine readable. +A second Encounter resource is used to transfer the human readable reference of the newly created referral, at the Receiver side. When a referral request is made, the Receiver **should** include a new, secondary, encounter resource with the status of 'planned' in their synchronous HTTP response to the Sender's request. This new 'planned' encounter will have both an id and an identifier value, representing the Receiver's local reference and human readable reference respectively. This secondary, 'planned', encounter is not mandatory and has a cardinality of 0..1, unlike the primary encounter resource (1..1)(See the Entity Relationship Diagram for reference). The human readable (Identifier) reference is intended to allow Senders to provide something to the patient which they can take between services to support consistent joined up care, although, it is also a useful link for the services themselves to use when discussing a patient's transition of care. The local (Id) reference is not intended to be human readable but rather machine readable. ### CarePlan Resource The CarePlan resource is used in a referral request to communicate the assessment triage outcome and any associated clinical information, based on the assessment performed by the Sender. The Receiver will utilise the detail in this resource to summarise what the previous assessment ascertained about the patient, to be used in any subsequent consultation with the patient. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md index bc6cf479..20cdb759 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md @@ -41,7 +41,7 @@ The Encounter is used to represent the interaction between a patient and healthc In the initial referral request, the Sender will include an Encounter resource as the container for their assessment, which established the need for the referral. This encounter **should** include a reference to the Sender's assessment under *encounter.identifier*. Additionally, the *encounter.episodeOfCare* **must** be populated with a 'Journey ID' reference which can be used in subsequent referrals to allow the audit of the route a patient took through service providers to resolve their initial request for care. -A second Encounter resource is used to transfer the human readable reference of the newly created referral, at the Receiver side. When a referral request is made, the Receiver **should** include a new, secondary, encounter resource with the status of 'planned' in their synchronous HTTP response to the Sender's request. This new 'planned' encounter will have both an Id and an Identifier value, indicating the Receiver's human readable and local references, respectively. This secondary, 'planned', encounter is not mandatory and has a cardinality of 0..1, unlike the primary encounter resource (1..1)(See the Entity Relationship Diagram for reference). The human readable (Identifier) reference is intended to allow Senders to provide something to the patient which they can take between services to support consistent joined up care, although, it is also a useful link for the services themselves to use when discussing a patient's transition of care. The local (Id) reference is not intended to be human readable but rather machine readable. +A second Encounter resource is used to transfer the human readable reference of the newly created referral, at the Receiver side. When a referral request is made, the Receiver **should** include a new, secondary, encounter resource with the status of 'planned' in their synchronous HTTP response to the Sender's request. This new 'planned' encounter will have both an id and an identifier value, representing the Receiver's local reference and human readable reference respectively. This secondary, 'planned', encounter is not mandatory and has a cardinality of 0..1, unlike the primary encounter resource (1..1)(See the Entity Relationship Diagram for reference). The human readable (Identifier) reference is intended to allow Senders to provide something to the patient which they can take between services to support consistent joined up care, although, it is also a useful link for the services themselves to use when discussing a patient's transition of care. The local (Id) reference is not intended to be human readable but rather machine readable. ### CarePlan Resource The CarePlan resource is used in a referral request to communicate the assessment triage outcome and any associated clinical information, based on the assessment performed by the Sender. The Receiver will to utilise the detail in this resource to summarise what the previous assessment ascertained about the patient, to be used in any subsequent consultation with the patient. From 18c716520c04a5ad56455a7ea966f4e160dfccd7 Mon Sep 17 00:00:00 2001 From: luci-davies Date: Tue, 7 Jul 2026 10:31:46 +0100 Subject: [PATCH 12/25] NBRS-4808 Related Person heading and text added to apps 1 +2 payload narrative --- .../BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md | 4 ++++ .../BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md index 7f25da40..03d3e19f 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md @@ -79,6 +79,10 @@ Using a nested set of *questionnaireResponse.item*, *questionnaireResponse.linkI ### Consent In the BaRS UEC Applications the level of consent is stipulated to be for 'Direct Care' only. A referral **must** contain a Consent resource and it **must** adhere to the [example](https://simplifier.net/NHSBookingandReferrals/8fc39b95-89a6-45fb-914f-1458a10e9e14/~json) provided under the BaRS FHIR assets. +### Related Person  + +Related Person is used to carry information about the patient's Next of Kin and their contact details.  This is different to 3rd party contact details which are carried in the Patient resource. +