From f2b0c810db720657b26b6f024613ef5a0e1b12de Mon Sep 17 00:00:00 2001 From: Carl De'ath <74620667+cda69@users.noreply.github.com> Date: Tue, 1 Jul 2025 09:32:30 +0100 Subject: [PATCH 1/2] API1.0.7-Update --- .../API-Spec-Change-Log/1.0.0.page.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/API-Spec-Change-Log/1.0.0.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/API-Spec-Change-Log/1.0.0.page.md index 6604130d..536ce5e6 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/API-Spec-Change-Log/1.0.0.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/API-Spec-Change-Log/1.0.0.page.md @@ -5,6 +5,15 @@ ### Change Log +### in BaRS 1.9.0 + +| Change | Description | Impact | +|----------------------------------------------|---------------------------------------------------------------------|--------| +| Fixed incorrect character display on GET /Slot description | Character display for a double quote was illegible. Version 1.0.7 | correction | + +
+
+ ### in BaRS 1.8.1 | Change | Description | Impact | From 6e00e982c6613d7020bfce3faef28a37572fca3f Mon Sep 17 00:00:00 2001 From: Carl De'ath <74620667+cda69@users.noreply.github.com> Date: Tue, 1 Jul 2025 15:34:36 +0100 Subject: [PATCH 2/2] APILinksUpdate --- .../Elements-of-the-Standard.page.md | 2 +- .../About-BaRS/Quick-Start-Guide.page.md | 4 ++-- .../Content-Negotiation/Mechanism.page.md | 2 +- .../BaRS-APP1/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP1/Index.page.md | 2 +- .../BaRS-APP2/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP2/Index.page.md | 2 +- .../Applications/BaRS-APP3/Index.page.md | 2 +- .../Applications/BaRS-APP4/Index.page.md | 2 +- .../BaRS-APP7/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP7/Index.page.md | 6 ++--- .../Applications/Index.page.md | 16 +++++++------- .../BaRS-Pre-releases/Index.page.md | 10 ++++----- .../Environments.page.md | 2 +- .../End-to-end-workflow/BaRS-FHIR-API.page.md | 4 ++-- .../End-to-end-workflow/HTTP-Header.page.md | 2 +- .../Introduction.page.md | 2 +- .../Cancel-Booking.page.md | 4 ++-- .../Initial-Booking.page.md | 8 +++---- .../Introduction.page.md | 22 +++++++++---------- .../Rebook-Methods.page.md | 16 +++++++------- .../Update-Existing-Booking.page.md | 4 ++-- .../End-to-end-workflow/BaRS-FHIR-API.page.md | 4 ++-- .../End-to-end-workflow/HTTP-Header.page.md | 2 +- .../Interface.md | 2 +- .../Introduction.md | 2 +- .../Home/Core/1.3.0/Index.page.md | 4 ++-- .../Cancellation.page.md | 2 +- .../Introduction.page.md | 2 +- 29 files changed, 68 insertions(+), 68 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Elements-of-the-Standard.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Elements-of-the-Standard.page.md index 1bb5f555..73f5313e 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Elements-of-the-Standard.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Elements-of-the-Standard.page.md @@ -10,7 +10,7 @@ BaRS documentation is as follows: |----------------------------------|------------------------------------------------------------------------------------------------------------| | [BaRS homepage]( https://digital.nhs.uk/services/booking-and-referral-standard) | An overview of the BaRS programme, the benefits of the standard and status of supplier development | | Implementation guide (this site) | You will need to use both the BaRS Core page and the BaRS Applications page specific to your use case. | -| [API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) | The specification for integrating with optional BaRS central infrastructure +| [API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) | The specification for integrating with optional BaRS central infrastructure diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Quick-Start-Guide.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Quick-Start-Guide.page.md index 086e4033..1788bc42 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Quick-Start-Guide.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Quick-Start-Guide.page.md @@ -8,7 +8,7 @@ We recommend reading the following documentation as part of the discovery stage * {{pagelink:definitions_key_terms, text:Definition of key terms}} * {{pagelink:design-core-1.0.7, text:BaRS Core}} * {{pagelink:applications, text:BaRS Applications}} -* [BaRS FHIR API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) +* [BaRS FHIR API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) ### Onboarding {{pagelink:Home/Build/Testing-and-Environments/Onboarding.page.md, text:Onboarding}} with our platform is a self-service process. This step is required to make requests of the BaRS API and have requests forwarded to your endpoint, as a Receiver. This **must** occur on both Integration (INT) and Production environments. The {{pagelink:Home/Build/Testing-and-Environments/Onboarding.page.md, text: full step-by-step onboarding guide}} can be followed by any solution on either environment. @@ -25,7 +25,7 @@ BaRS includes several {{pagelink:applications, text:BaRS Application (use cases) ### API Spec -The BaRS [API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) provides detail of the structure of endpoints. The specification allows you to 'Try this API', calling endpoints to view anticipated responses. This is a purely technical document and must be read in conjunction with implementation guidance to build a compliant solution. +The BaRS [API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) provides detail of the structure of endpoints. The specification allows you to 'Try this API', calling endpoints to view anticipated responses. This is a purely technical document and must be read in conjunction with implementation guidance to build a compliant solution. ### Security All {{pagelink:core-Security-1.0.7, text:security}} is provided through our platform. There are two methods for securing interactions via BaRS API: diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Content-Negotiation/Mechanism.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Content-Negotiation/Mechanism.page.md index d1aae8c3..f9bd2be4 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Content-Negotiation/Mechanism.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Content-Negotiation/Mechanism.page.md @@ -75,7 +75,7 @@ The Use-Case-Category is a codeSystem that defines the use case for the message, #### Service -The Service describes if the MessageDefinition is applicable for this service. This is something that should be implied by the query parameter for GET /MessageDefinition, which acts as a filter. This capability is already described on the Get MessageDefinition page. +The Service describes if the MessageDefinition is applicable for this service. This is something that should be implied by the query parameter for GET /MessageDefinition, which acts as a filter. This capability is already described on the Get MessageDefinition page. ### Version The same SemVer rules are applied to the MessageDefinition versions. It could be the case that multiple MessageDefinitions are returned and in this scenario a Sender should select the closest version to their own from a Minor Revision and Patch perspective. If a Major version difference is detected then the Sender cannot continue unless another option is available in the response. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md index 977a2562..78e4d7cf 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md @@ -191,7 +191,7 @@ During a referral workflow where booking is required, there are two separate pro The first part of this process involves the **sender** making a request to the **receiver** for slots that match the search criteria. This is a "searching" request that requires the response body to include a "searchset" bundle resource. -The search parameters are defined on the BaRS API specification documentation. +The search parameters are defined on the BaRS API specification documentation. 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 c8c6ac65..70b481fd 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 @@ -22,7 +22,7 @@ topic: Application1 Application 1 v1.0.8 v1.0.x v1.9.0 - v1.0.0 + v1.0.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md index cf62bc52..2c7c4450 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md @@ -88,7 +88,7 @@ During a referral workflow where booking is required, there are two separate pro The first part of this process involves the **sender** making a request to the **receiver** for slots that match the search criteria. This is a "searching" request that requires the response body to include a "searchset" bundle resource. -The search parameters are defined on the BaRS API specification documentation. +The search parameters are defined on the BaRS API specification documentation. 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 cfddb2d5..9dfb296f 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 @@ -23,7 +23,7 @@ topic: Application2 Application 2 v1.0.8 v1.0.x v1.9.0 - v1.0.0 + v1.0.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Index.page.md index e740464d..ef17d03e 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Index.page.md @@ -22,7 +22,7 @@ topic: Application3 Application 3 v1.0.4 v1.0.x v1.9.0 - v1.0.0 + v1.0.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Index.page.md index 22744dcb..029d0d52 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Index.page.md @@ -20,7 +20,7 @@ topic: Application4 Application 4 v1.2.3 v1.0.x v1.9.0 - v1.0.0 + v1.0.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md index 4d91b503..bc27ce20 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md @@ -22,7 +22,7 @@ During a referral workflow where booking is required, there are two separate pro The first part of this process involves the **sender** making a request to the **receiver** for slots that match the search criteria. This is a "searching" request that requires the response body to include a "searchset" bundle resource. -The search parameters are defined on the BaRS API specification documentation. +The search parameters are defined on the BaRS API specification documentation. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Index.page.md index 85257baf..294c3a49 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/Index.page.md @@ -22,9 +22,9 @@ topic: Application7 Application 7 v1.0.0-alpha.4 - v1.0.x - v1.9.0 - v1.0.0 + v1.0.x + v1.9.0 + v1.3.0 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 b557cfe7..6334887a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/Index.page.md @@ -19,11 +19,11 @@ These guides are designed to be used in conjunction with the documentation for { | Application | Use Cases | Current Release | Minimum API Spec | Minimum Core Version | | ----------------------------------------------------------------------------|--------------------------------------------------------------- | --------------- | --------------- | --------------- | -| {{pagelink:application1, text:Booking and Referrals into UEC (Application 1)}} |

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

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

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

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

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

999-CAS Validation

999 AST to Falls Lifting Service

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

Primary Care to Community Pharmacy (Pharmacy First)

Primary Care to Pharmacy Contraception (Oral Contraception)

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

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

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

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

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

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

999-CAS Validation

999 AST to Falls Lifting Service

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

Primary Care to Community Pharmacy (Pharmacy First)

Primary Care to Pharmacy Contraception (Oral Contraception)

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

@@ -46,7 +46,7 @@ Table detailing active versions of the latest Applications in Production (or cur Application 1 v1.0.1 v1.1.0 v1.0.0 - 1.0.0 + 1.0.0 Application 1 v1.0.3 @@ -136,7 +136,7 @@ Table detailing active versions of the latest Applications in Production (or cur Application 5 v1.0.0-beta.4 v1.4.0 v1.1.0 - 1.1.0 + 1.3.0 Application 5 v1.0.0 @@ -166,7 +166,7 @@ Table detailing active versions of the latest Applications in Production (or cur Application 7 v1.0.0-alpha.4 v1.9.0 v1.0.0 - 1.0.0 + 1.0.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md index 6a6877b7..04b36140 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md @@ -14,8 +14,8 @@ These guides are designed to be used in conjunction with the documentation for { | Application | Use Cases | Current Release | API Specification | Core Version | | ----------------------------------------------------------------------------|--------------------------------------------------------------- | --------------- | --------------- | --------------- | -| {{pagelink:application6, text: Referrals into an Ambulance Service Trust (Application 6)}} |

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

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

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

Appointments for Patient facing services into GP Practice | 1.0.0-alpha.4 | API Spec v1.3.0 and above | {{pagelink:design-core-1.1.4, text:Core v1.3.0 and above}} | @@ -43,7 +43,7 @@ Table detailing active versions of the latest Applications in Production (or cur Application 1 v1.0.1 v1.1.0 v1.0.0 - 1.0.0 + 1.0.0 Application 1 v1.0.3 @@ -133,7 +133,7 @@ Table detailing active versions of the latest Applications in Production (or cur Application 5 v1.0.0-beta.4 v1.4.0 v1.1.0 - 1.1.0 + 1.3.0 Application 5 v1.0.0 @@ -163,7 +163,7 @@ Table detailing active versions of the latest Applications in Production (or cur Application 7 v1.0.0-alpha.4 v1.9.0 v1.0.0 - 1.0.0 + 1.0.0 diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Environments.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Environments.page.md index 4e37c582..c66b24ea 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Environments.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Environments.page.md @@ -1,6 +1,6 @@ ## {{page-title}} -The principle environment for development and testing is the INT (integration) environment. This is a like-live environment, harnessing full security and functionality that can expect to be encountered in Production. In addition, the [BaRS API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) links to the Sandbox environment, which is capable of demonstrating the key functionality but without the security overhead. +The principle environment for development and testing is the INT (integration) environment. This is a like-live environment, harnessing full security and functionality that can expect to be encountered in Production. In addition, the [BaRS API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) links to the Sandbox environment, which is capable of demonstrating the key functionality but without the security overhead. [Path-to-Live](https://digital.nhs.uk/services/path-to-live-environments#environments) has full details of all available testing environments and the functionality they offer. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/BaRS-FHIR-API.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/BaRS-FHIR-API.page.md index 075dc114..46a45014 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/BaRS-FHIR-API.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/BaRS-FHIR-API.page.md @@ -4,11 +4,11 @@ topic: core-EndToEndWorkflow-API-1.0.7 ## BaRS FHIR API -The [BaRS FHIR API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) supports all functionality with receiver APIs for both booking and referrals. Once an access token has been obtained, the sender can start making requests of the API. +The [BaRS FHIR API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.0.7) supports all functionality with receiver APIs for both booking and referrals. Once an access token has been obtained, the sender can start making requests of the API. Note: With every API request the sender must include the HTTP header parameter 'NHSD-Target Identifier'. -You can find details for each endpoint in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0). +You can find details for each endpoint in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.0.7).


\ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/HTTP-Header.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/HTTP-Header.page.md index 74de5983..7d09f1ac 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/HTTP-Header.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/End-to-end-workflow/HTTP-Header.page.md @@ -4,7 +4,7 @@ topic: core-EndToEndWorkflow-HTTPHeader-1.0.7 ## {{page-title}} -The BaRS API specifies several additional headers, many of which are items described in a standard Base64 encoded object (JSON). Their purpose and usage are described below. Examples can be found in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0). +The BaRS API specifies several additional headers, many of which are items described in a standard Base64 encoded object (JSON). Their purpose and usage are described below. Examples can be found in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.0.7).

\ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Transactional-integrity/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Transactional-integrity/Introduction.page.md index 38d69107..ae19f961 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Transactional-integrity/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Transactional-integrity/Introduction.page.md @@ -6,7 +6,7 @@ topic: Core-TransactionalIntegrity-introduction-1.0.7 Transactional integrity is employed to ensure data integrity is maintained between two parties. It helps ensure that the success or failure of a message is known and can be confirmed. -There are two existing header items for requests currently available to allow BaRS to meet transactional integrity requirements. They are listed below with their intended uses. The [BaRS API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) contains example values for these entries. +There are two existing header items for requests currently available to allow BaRS to meet transactional integrity requirements. They are listed below with their intended uses. The [BaRS API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.0.7) contains example values for these entries. | Header | Requirement | Description | Value | |------------------|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------|----------------------------| diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Cancel-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Cancel-Booking.page.md index 70cd1ac2..302334ce 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Cancel-Booking.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Cancel-Booking.page.md @@ -6,9 +6,9 @@ topic: core-StandardPattern-appointment-cancel-1.3.0 To cancel an appointment: -* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, the read can be undertaken with [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment), using the {{pagelink:core-SPFindResource-1.3.0, text:find resource}} workflow, and selecting the .id by the matching the required resource. NB: If a match cannot be performed, using this method, manual processes should be engaged. +* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, the read can be undertaken with [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment), using the {{pagelink:core-SPFindResource-1.3.0, text:find resource}} workflow, and selecting the .id by the matching the required resource. NB: If a match cannot be performed, using this method, manual processes should be engaged. * Set the Appointment.status value to "cancelled" -* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} +* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} resource returned: ```json diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Initial-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Initial-Booking.page.md index 3b1ad0e8..e598dc14 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Initial-Booking.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Initial-Booking.page.md @@ -9,13 +9,13 @@ Below are examples of each of the described interactions. The appointment resour Any operations that modify an existing resource must perform a read before a write. GET /Appointment/\{id\} ### Book -The method for the initial booking of an appointment depends on the {{pagelink:Home/Applications/BaRS-Applications, text:Application}} specific guidance within BaRS. Within BaRS Applications, making a booking will involve building a FHIR bundle and making a POST to the [$process-message](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#post-/$process-message) endpoint. Alternatively, booking an appointment can be used outside of use-cases supported by a BaRS Application, to fulfil a generic Appointment Management Foundation workflow against the discete [booking endpoints](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#post-/Appointment), either way, the typical sequence of events is: +The method for the initial booking of an appointment depends on the {{pagelink:Home/Applications/BaRS-Applications, text:Application}} specific guidance within BaRS. Within BaRS Applications, making a booking will involve building a FHIR bundle and making a POST to the [$process-message](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/$process-message) endpoint. Alternatively, booking an appointment can be used outside of use-cases supported by a BaRS Application, to fulfil a generic Appointment Management Foundation workflow against the discete [booking endpoints](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment), either way, the typical sequence of events is: * {{pagelink:core-EndToEndWorkflow-ServiceDiscovery-1.3.0, text:Select the service}} to book an appointment with. -* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/metadata). -* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Slot). +* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/metadata). +* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot). * Select a slot. -* Send a Request to [book an appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#post-/Appointment) in that slot +* Send a Request to [book an appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) in that slot Request Body 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 1ef58ef6..701614b0 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 @@ -10,7 +10,7 @@ topic: core-StandardPattern-appointment-Introduction-1.3.0 ## Introduction -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_2_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. @@ -29,18 +29,18 @@ 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 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 | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| -| [List](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/DocumentReference) | /DocumentReference | GET | Using the {{pagelink:core-StandardPattern-document-reference-Introduction-1.3.0, text:DocumentReference}} pattern, a list of existing appointments for a patient can be viewed with the central Registry. | -| [View](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) | /Appointment/\{id\} | GET | This action, using the id from the List capability, will allow that specific Appointment Resource to be [retrieved](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) from the healthcare service who owns it. | -| [View (Search)](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment) | /Appointment | GET | If the Appointment.id is not known, the Sender can perform a look up based the patient national identifier (NHS No.) or demographics (Name (as defined by [FHIR](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/2834389 )), Date of Birth, Home Address Postcode). This returns a (FHIR) bundle of resources for the specific Appointment Resource to be [retrieved](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment) from the healthcare service who owns it. See {{pagelink:core-SPCancellation-1.3.0, text:Cancellation}} for further detail.| -| [Get Slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Slot) | /Slots | GET | Obtain a list of available booking slots from a specified receiving system using the [GET /Slots endpoint](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Slot) | -| [Book](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#post-/Appointment) | /Appointment or /$process-message | POST | This will be a POST operation, with a BaRS Application /$process-message is typically used, outside of supported use cases /Appointment is adopted.| -| [Cancel](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) | /Appointment/\{id\} | PUT| The cancel of a booking will be setting the status of the appointment to "cancelled". Cancel is also possible using /$process-message | -| [Update](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) | /Appointment/\{id\} | PUT / PATCH| An update to an appointment will be a direct update to the existing resource | -| [Rebook](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#post-/Appointment) | Composite of Cancel and then Book | Composite | Requesting a new booking and then cancelling the existing one will constitute a rebook | +| [List](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference) | /DocumentReference | GET | Using the {{pagelink:core-StandardPattern-document-reference-Introduction-1.3.0, text:DocumentReference}} pattern, a list of existing appointments for a patient can be viewed with the central Registry. | +| [View](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) | /Appointment/\{id\} | GET | This action, using the id from the List capability, will allow that specific Appointment Resource to be [retrieved](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) from the healthcare service who owns it. | +| [View (Search)](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment) | /Appointment | GET | If the Appointment.id is not known, the Sender can perform a look up based the patient national identifier (NHS No.) or demographics (Name (as defined by [FHIR](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/2834389 )), Date of Birth, Home Address Postcode). This returns a (FHIR) bundle of resources for the specific Appointment Resource to be [retrieved](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment) from the healthcare service who owns it. See {{pagelink:core-SPCancellation-1.3.0, text:Cancellation}} for further detail.| +| [Get Slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot) | /Slots | GET | Obtain a list of available booking slots from a specified receiving system using the [GET /Slots endpoint](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot) | +| [Book](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) | /Appointment or /$process-message | POST | This will be a POST operation, with a BaRS Application /$process-message is typically used, outside of supported use cases /Appointment is adopted.| +| [Cancel](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) | /Appointment/\{id\} | PUT| The cancel of a booking will be setting the status of the appointment to "cancelled". Cancel is also possible using /$process-message | +| [Update](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) | /Appointment/\{id\} | PUT / PATCH| An update to an appointment will be a direct update to the existing resource | +| [Rebook](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#post-/Appointment) | Composite of Cancel and then Book | Composite | Requesting a new booking and then cancelling the existing one will constitute a rebook | -In line with the BaRS standard all operations used to modify a resource must be preceded by a read of the resource by means of a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) operation. +In line with the BaRS standard all operations used to modify a resource must be preceded by a read of the resource by means of a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Rebook-Methods.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Rebook-Methods.page.md index 4c3caf6a..7d4efb33 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Rebook-Methods.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Rebook-Methods.page.md @@ -31,12 +31,12 @@ The method for the subsequent booking of an appointment depends on the Applicati Alternatively, rebooking an appointment can be used outside of use-cases supported by a BaRS Application, to fulfil a generic Appointment workflow, either way, the typical sequence of events using PUT or POST is: * {{pagelink:core-EndToEndWorkflow-ServiceDiscovery-1.3.0, text:Select the service}} to book an appointment with. -* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/metadata). -* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Slot). +* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/metadata). +* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot). * Select a slot. -* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, the read can be undertaken with [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment), using the {{pagelink:core-SPFindResource-1.3.0, text:find resource}} workflow, and selecting the .id by the matching the required resource. NB: If a match cannot be performed, using this method, manual processes should be engaged. +* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, the read can be undertaken with [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment), using the {{pagelink:core-SPFindResource-1.3.0, text:find resource}} workflow, and selecting the .id by the matching the required resource. NB: If a match cannot be performed, using this method, manual processes should be engaged. * Set the Appointment.status value to "cancelled" -* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} +* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} Request Body @@ -79,12 +79,12 @@ Request Body Using PATCH: * {{pagelink:core-EndToEndWorkflow-ServiceDiscovery-1.3.0, text:Select the service}} to book an appointment with. -* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/metadata). -* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Slot). +* Confirm BaRS [Capabilities](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/metadata). +* [Request Available slots](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Slot). * Select a slot. -* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} +* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} * Set the Appointment.status value to "cancelled" -* Perform a [PATCH](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#patch-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} +* Perform a [PATCH](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#patch-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} ```json { diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Update-Existing-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Update-Existing-Booking.page.md index b7e4ea2f..699303a4 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Update-Existing-Booking.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Appointment-StandardPattern/Update-Existing-Booking.page.md @@ -6,9 +6,9 @@ topic: core-StandardPattern-appointment-update-1.3.0 To update an appointment: -* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, the read can be undertaken with [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment), using the {{pagelink:core-SPFindResource-1.3.0, text:find resource}} workflow, and selecting the .id by the matching the required resource. NB: If a match cannot be performed, using this method, manual processes should be engaged. +* Perform a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}. Alternatively, if the .id is not known, the read can be undertaken with [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/Appointment), using the {{pagelink:core-SPFindResource-1.3.0, text:find resource}} workflow, and selecting the .id by the matching the required resource. NB: If a match cannot be performed, using this method, manual processes should be engaged. * Amend or append the resource as required. -* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} +* Perform a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\} In this example a placeholder was created, and updated when the slot is selected. This is a hypothetical scenario. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/BaRS-FHIR-API.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/BaRS-FHIR-API.page.md index 6e989944..755866eb 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/BaRS-FHIR-API.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/BaRS-FHIR-API.page.md @@ -4,11 +4,11 @@ topic: core-EndToEndWorkflow-API-1.3.0 ## BaRS FHIR API -The [BaRS FHIR API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) supports all functionality with receiver APIs for both booking and referrals. Once an access token has been obtained, the sender can start making requests of the API. +The [BaRS FHIR API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) supports all functionality with receiver APIs for both booking and referrals. Once an access token has been obtained, the sender can start making requests of the API. Note: With every API request the sender must include the HTTP header parameter 'NHSD-Target Identifier'. -You can find details for each endpoint in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0). +You can find details for each endpoint in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0).

\ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/HTTP-Header.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/HTTP-Header.page.md index 968b2a81..86cc60fa 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/HTTP-Header.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/End-to-end-workflow/HTTP-Header.page.md @@ -5,7 +5,7 @@ topic: core-EndToEndWorkflow-HTTPHeader-1.3.0 ## {{page-title}} -The BaRS API specifies several additional headers, many of which are items described in a standard Base64 encoded object (JSON). Their purpose and usage are described below. Examples can be found in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0). +The BaRS API specifies several additional headers, many of which are items described in a standard Base64 encoded object (JSON). Their purpose and usage are described below. Examples can be found in the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0).

\ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Interface.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Interface.md index 5ace955e..050725f1 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Interface.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Interface.md @@ -4,7 +4,7 @@ topic: core-StandardPattern-Endpoint-Interface-1.3.0 # Interface -The Interface for managing the 3 resources relating to an "endpoint" is detailed below and is part of the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0) for Core 1.2.0 and above. +The Interface for managing the 3 resources relating to an "endpoint" is detailed below and is part of the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) for Core 1.2.0 and above. ## Request and Response diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Introduction.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Introduction.md index 31cba703..8c176ab2 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Introduction.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/EndpointCatalogue-StandardPattern/Introduction.md @@ -27,7 +27,7 @@ This version of core is strictly a preview of what is currently in development f # Standard Pattern - Endpoints -BaRS employs an endpoint catalogue to match Target Identifiers with a stored endpoint. Target Identifiers are provided in a header which is descripted in the [API Spec](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0) The following pages will describe how these entries can be managed, outside of the onboarding process. +BaRS employs an endpoint catalogue to match Target Identifiers with a stored endpoint. Target Identifiers are provided in a header which is descripted in the [API Spec](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) The following pages will describe how these entries can be managed, outside of the onboarding process. The BaRS endpoints will utilise not only service ids and a physical endpoint, but data describing the healthcare service, the provider of that service and the organization which manages and/or supplies the endpoint in question. This information will be stored using 3 FHIR resources which appropriately describe [Endpoints](http://hl7.org/fhir/R4/endpoint.html), [HealthcareServices](http://hl7.org/fhir/R4/healthcareservice.html) and [Organizations](http://hl7.org/fhir/R4/organization.html). diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md index ea92e514..1151567b 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md @@ -15,7 +15,7 @@ topic: design-core-1.3.0 v1.3.0 v1.8.2 - v1.3.0 + v1.3.0 @@ -245,7 +245,7 @@ This version of core is strictly a preview of what is currently in development f -BaRS employs an endpoint catalogue to match Target Identifiers with a stored endpoint. Target Identifiers are provided in a header which is descripted in the [API Spec](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0) The following pages will describe how these entries can be managed, outside of the onboarding process. +BaRS employs an endpoint catalogue to match Target Identifiers with a stored endpoint. Target Identifiers are provided in a header which is descripted in the [API Spec](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) The following pages will describe how these entries can be managed, outside of the onboarding process. The BaRS endpoints will utilise not only service ids and a physical endpoint, but data describing the healthcare service, the provider of that service and the organization which manages and/or supplies the endpoint in question. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md index 1ba8681c..5af822fe 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md @@ -7,7 +7,7 @@ topic: core-SPCancellation-1.3.0 The ability to reverse a digital request, by performing a cancellation, whether booking or referral, is a core workflow within BaRS. It completes the digital workflow, supports genuine interoperability and removes the need for manual intervention by service providers. -There are two potential routes for performing a cancellation of a booking or referral, dependending on Supplier implementation (see - Capability Statement (GET /metadata) for supported methods), either via $process-message or directly against the single resource (RESTfully). Where $process-message is used a stripped back request containing only the specific resources a Receiver requires to the fulfil the update are included. There are separate MessageDefinitions involved when engaged in the respective [referral](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionservicerequestrequestcancelled/~json) and [booking](https://simplifier.net/NHSBookingandReferrals/MessageDefinition-BARSMessageDefinitionBookingRequestCancelled/~json) cancellation workflows. Alternatively, where a RESTful pattern for updating a single resource is followed, the independent endpoints for [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.2.2-alpha#put-/Appointment/-id-) and [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.2.2-alpha#put-/ServiceRequest/-id-) support the update process. This workflow follows {{pagelink:core-StandardPattern-appointment-1.3.0 , text:Standard Pattern - Appointments}}. +There are two potential routes for performing a cancellation of a booking or referral, dependending on Supplier implementation (see - Capability Statement (GET /metadata) for supported methods), either via $process-message or directly against the single resource (RESTfully). Where $process-message is used a stripped back request containing only the specific resources a Receiver requires to the fulfil the update are included. There are separate MessageDefinitions involved when engaged in the respective [referral](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionservicerequestrequestcancelled/~json) and [booking](https://simplifier.net/NHSBookingandReferrals/MessageDefinition-BARSMessageDefinitionBookingRequestCancelled/~json) cancellation workflows. Alternatively, where a RESTful pattern for updating a single resource is followed, the independent endpoints for [booking](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/Appointment/-id-) and [referral](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/ServiceRequest/-id-) support the update process. This workflow follows {{pagelink:core-StandardPattern-appointment-1.3.0 , text:Standard Pattern - Appointments}}. It is a prerequisite, when performing a cancellation, to read (GET) the booking or referral to be cancelled, following the {{pagelink:core-SPFindResource-1.3.0, text:find resource}} steps. This ensures the Sender has the key values to build the request and verifies they can proceed with the workflow. The Sender **must** only make a cancellation request if the entity being cancelled has a status which means it is still current; 'active' in the case of a referral (ServiceRequest) and 'booked' for a booking (Appointment). This ensures the Sender has the latest version of the resource they are about to change or, if it is no longer current (because its been actioned by the Receiver), allows the Sender to advise the end user so an alternative (often manual) workflow can be started. The Receiver **must not** process a cancellation request for a booking or referral which is not current, instead they **must** return an appropriate {{pagelink:core-ErrorHandling-1.3.0, text:error}} response. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Transactional-integrity/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Transactional-integrity/Introduction.page.md index f5c13d94..67fbd9cb 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Transactional-integrity/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Transactional-integrity/Introduction.page.md @@ -6,7 +6,7 @@ topic: Core-TransactionalIntegrity-Introduction-1.3.0 Transactional integrity is employed to ensure data integrity is maintained between two parties. It helps ensure that the success or failure of a message is known and can be confirmed. -There are two existing header items for requests currently available to allow BaRS to meet transactional integrity requirements. They are listed below with their intended uses. The [BaRS API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) contains example values for these entries. +There are two existing header items for requests currently available to allow BaRS to meet transactional integrity requirements. They are listed below with their intended uses. The [BaRS API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0) contains example values for these entries. | Header | Requirement | Description | Value | |------------------|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------|----------------------------|