Merge branch 'develop' into v10-tweaks-CGD

Author: cda69

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Current-Releases.page.md

@@ -3,7 +3,7 @@
 Product Link           | Version | Handle  | Phase    | State           | Release Date | Stability  | Change Log Link
 -----------------------|---------|---------|----------|-----------------|--------------|------------|-----------------
 Implementation Guide   | 1.10.0   | v1      | Live     | Current Release | 12/11/2025 | Stable     |{{pagelink:trn-General}}
-[FHIR Package](https://simplifier.net/packages/uk.nhsdigital.bars.r4/1.35.0) | 1.37.0| v1      | Live     | Current Release | 12/11/2025  | Stable     |
+[FHIR Package](https://simplifier.net/packages/uk.nhsdigital.bars.r4/1.37.0) | 1.37.0| v1      | Live     | Current Release | 12/11/2025  | Stable     |
 {{pagelink:design-core-1.3.1, text:BaRS Core}}              | 1.3.1   | v1      | Live     | Current Release | 12/11/2025   | Stable     |{{pagelink:trn-core, text: BaRS Core Change Log}}
 [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_3_0)    | 1.3.0   | v1      | Live     | Current Release | 12/11/2025  | Stable     |{{pagelink:trn-api}}
 {{pagelink: build-testing, text: TKW}}  | 1.0.21   | v1      | Live     | Current Release | 12/11/2025   | Stable     |{{pagelink:trn-tkw}}
@@ -19,8 +19,9 @@ Implementation Guide   | 1.10.0   | v1      | Live     | Current Release | 12/11
 
 ### Overview of the release
 
-Release 1.10.0 includes a change to the accepted NHS number verification statuses included in the BaRS standard for applications 1-4. It also includes details of a standard pattern for updates and clarifications to the BaRS Foundation Standard, alongside bug fixes and corrections throughout the guide.  
-Following user feedback, the content in About BaRS, steps for technical deployment and instructions for connecting to our environments are restructured and simplified.
+Release 1.10.0 includes a change to the accepted multiple NHS number verification statuses across BaRS, seeing a major version increment for Applications 1, 2, 3 & 4. The Appointment Management Foundation Standard has been revised and simplified, including extending the use Document Reference Standard Pattern to update the Registry (National Record Locator), alongside bug fixes and corrections throughout the guide.
+There have been further minor changes to the current beta, Application 6, following discussion with the BaRS Community involved, and the scope and responsibilities during Assurance have been described.
+Finally, following user feedback, the content in About BaRS, steps for technical deployment and instructions for connecting to our environments are restructured and simplified.
 
 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 <a href= "https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/onboarding-support-information#hazard-log-and-clinical-safety-case-report-cscr-" target="_blank"> BaRS FHIR API onboarding support information page </a>.
 

guides/Live-ImplementationGuide-BaRS/Home/Assure/Assure/Assure.page.md

@@ -6,10 +6,10 @@ The assurance process ensures solutions adhere to the Standard and are compatibl
 
 The purpose of assurance is to:
 * Validate conformance to the requirements and specifications of the Standard
-* Assess higher-risk and/or complex workflow scenarios, to ensure technical and clinical readiness
+* Assess higher-risk and/or complex workflow scenarios, ensuring patient safety and technical and clinical readiness
 * Serve as a final quality assurance checkpoint prior to deployment to Production
 
 There are limitations to this (self) assurance process, which does **not** extend to: 
 * Validation of every individual workflow scenario or minor message variation within an assured solution
-* Review of all message content against the Standard, either visually or through tooling. This **must** be included in supplier's functional testing 
+* Review of all message content against the Standard, either visually or through tooling. This **must** be included in the supplier's functional testing 
 * Regression testing of supplier solution to ensure that existing functionality has not been adversely affected

guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Connect-as-a-receiver.page.md

@@ -11,7 +11,7 @@ BaRS uses TLS-MA to communicate with Receiving endpoints. Receiving endpoints ne
 
 ### How to connect to the BaRS proxy as a Receiver:
 
-Step 1: Apply for your domain [apply for a new nhs.uk domain](https://digital.nhs.uk/services/networking-addressing/apply-for-an-nhs.uk-domain-for-websites-and-web-applications).  You must complete Section 5: For website or application records visible on the public internet.
+Step 1: Apply for your domain [apply for a new nhs.uk domain](https://digital.nhs.uk/services/networking-addressing/apply-for-an-nhs.uk-domain-for-websites-and-web-applications).  You must complete Section 5: For domain names visible only on the public internet 
 
 Step 2: Request a certificate under the NHS Root CA. The FQDN must be an nhs.uk address.
 There are different certificate chains for INT and PROD:
@@ -30,6 +30,7 @@ Create the *.csr, use the following command:</br>
 openssl req -new -key private.key -out request.csr
 ```
 **Note:** <small>_Generate the CSR with only the common name field populated, which must match the FQDN. All other fields can remain blank. The email field MUST be blank. Please note FQDNs MUST be in the .nhs.uk domain as we can only issue certificates in this domain._</small>
+
 Step 4: Send the .csr file to be signed by NHS England and get the client certificate. To do this, follow these environment specific steps:
 
 <br> 
@@ -60,21 +61,22 @@ Step 3: Email <england.bookingandreferralstandard@nhs.net> with Receiver URL for
 Step 1: Send the .csr to <dir@nhs.net>, indicating this is for a BaRS Receiver endpoint
 
 Formats for FQDN on PROD:
+
 * Supplier hosted (multi-tenanted) solutions ‘**BaRS-PROD-\<ODS Code\>.\<Supplier name\>.thirdparty.nhs.uk**’
 
-* Service Provider  hosted (on-premise) solutions‘**BaRS-PROD-\<ODS Code\>.\<Provider name\>.nhs.uk**’
+* Service Provider  hosted (on-premise) solutions ‘**BaRS-PROD-\<ODS Code\>.\<Provider name\>.nhs.uk**’
 
 Step 2: Receive certificate from DIR Team
 
 Step 3: Email <england.bookingandreferralstandard@nhs.net> with Receiver URL for BaRS/API-M to add to the Endpoint Catalogue
 
-Step 4: Make changes to your [firewall exceptions](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Deploy/Technical-deployment\Firewallexceptions) to receive messages from the BaRS proxy.
+Step 4: Make changes to your {{pagelink:firewall-exceptions, text:firewall exceptions}} to receive messages from the BaRS proxy.
 
 <br> 
 
 
 #### Installing and configuring your application to use the certificate
-Step 1: INT and PROD copy the cert text inlcuding `-----BEGIN CERTIFICATE` as the first line and `END CERTIFICATE-----` as the last. Save this text locally as a file called barsinreceiver.cer (change the name to suit).
+Step 1: INT and PROD copy the cert text including `-----BEGIN CERTIFICATE` as the first line and `END CERTIFICATE-----` as the last. Save this text locally as a file called barsinreceiver.cer (change the name to suit).
 
 Step 2: Create a .pfx file so you can serve HTTPS (TLS) endpoints. You can use the command below to export a *.pfx file from the *.key file you made earlier (when you made the *.csr file) along with the *.cer file you were emailed.
 
@@ -86,7 +88,7 @@ Step 3: Create a password for your .pfx file.
 
 Step 4: Make configuration changes to reference the *.pfx file and password
 
-(C# example, Other launguages will vary but be similar)
+(C# example, Other languages will vary but be similar)
 
 ``` c#
 

guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Connect-as-a-sender.page.md

@@ -4,11 +4,11 @@ topic: connect-as-a-sender
 
 ## {{page-title}}
 
-API-M provides the [security model](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/application-restricted-restful-apis-signed-jwt-authentication) for BaRS. 
+APIM provides the [security model](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/application-restricted-restful-apis-signed-jwt-authentication) for BaRS. 
 
 To connect to the BaRS proxy as a sender follow these steps:
 
-Step 1: follow the NHS Developer authenitication and authorisation process [NHS Developer authentication and authorisation](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/user-restricted-restful-apis-nhs-login-separate-authentication-and-authorisation#step-1-register-your-application-with-nhs-login)
+Step 1: follow the NHS Developer authentication and authorisation process [NHS Developer authentication and authorisation](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/user-restricted-restful-apis-nhs-login-separate-authentication-and-authorisation#step-1-register-your-application-with-nhs-login)
 
 Step 2: trust the Certificate Authorities (CA) mentioned below. For INT this will be downloadable from http://pki.nhs.uk/int/G2/auth/NHSINTAuthG2.crt 
 ( you can examine the .cer file if you have one )

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: DocumentReference Standard Pattern}} 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 respository, 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

guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/Appointment-StandardPattern/Reschedule-Existing-Booking.page.md

@@ -13,7 +13,7 @@ Steps to Reschedule:
 * Select a new slot
 * Update the resource with the new slot. NB: Only the .slot element of the resource must be updated
 * Perform a [PATCH](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#patch-/Appointment/-id-) operation using the id of the appointment to /Appointment/\{id\}
-* Once processed, the Receiver of the booking must [update (PUT)](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/DocumentReference/-id-) the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-Receiver-1.3.1, text: Document Reference Standard Pattern - Receiver}}. The principle update to the pointer is to change the .context element to alter the slot time - 
+* Once processed, the Receiver of the booking must [update (PUT)](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/DocumentReference/-id-) the pointer in the central Registry, as described in {{pagelink:core-StandardPattern-document-reference-Receiver-1.3.1, text: Document Reference Standard Pattern - Receiver}}. The principal update to the pointer is to change the .context element to alter the slot time - 
 
 ```json
 "context": {

guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Introduction.page.md

@@ -5,12 +5,12 @@ topic: core-StandardPattern-document-reference-Introduction-1.3.1
 # Standard Pattern - DocumentReference
 
 <div markdown="span" class="alert alert-warning" role="alert"><i class="fa fa-warning"></i><b>Important:  Release information</b>
-<p>This Section of the Implementation Guide is currently a preview, in an Alpha state and subject to change. There is only currently support for Appointment (booking) pointers.</p>
+<p>This section of the Implementation Guide is currently a preview, in an Alpha state and subject to change. There is currently only support for Appointment (booking) pointers.</p>
 </div>
 
 ## Introduction
 
-There is functionality in BaRS to accommodate the use of pointers (DocumentReference resources), to locate existing bookings and referrals from a central Registy.
+There is functionality in BaRS to accommodate the use of pointers (DocumentReference resources), to locate existing bookings and referrals from a central Registry.
 
 This section will walk you through the process of using FHIR DocumentReferences, from the central Registry, to find and retrieve bookings and referrals held at Receiver services.
 

guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Receiver-DocumentReference.md

@@ -38,7 +38,7 @@ The second identifier of note is the Receiving service who own the resource. The
 	}
 ```
 
-The third identifier (currently optional) relates to the product-id, system '*https://fhir.nhs.uk/id/product-id*'. This is forth coming functionality and further detail on its utility will follow but [working documentation] (https://github.com/NHSDigital/nhse-epr-integration/blob/main/pages/appendix1.md) is being actively updated.
+The third identifier (currently optional) relates to the product-id, system '*https://fhir.nhs.uk/id/product-id*'. This is forthcoming functionality and further detail on its utility will follow but [working documentation] (https://github.com/NHSDigital/nhse-epr-integration/blob/main/pages/appendix1.md) is being actively updated.
 
 ```json
 "identifier": [
@@ -103,14 +103,14 @@ After saving, the DocumentReference will be assigned a unique id (e.g., Document
 To ensure that the DocumentReference was created successfully, retrieve it using its [id](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference/-id-) or [search](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference) for it using relevant parameters. Make sure to validate the returned DocumentReference to confirm that all the contents are accurate.
 
 ### Updating a DocumentReference
-A DocumentReference can be updated by performing a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/DocumentReference/-id-) request with the updated resource to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A Read operation must be performed prior to this to ensure that the new DocumentReference is the most up to date.
+A DocumentReference can be updated by performing a [PUT](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#put-/DocumentReference/-id-) request with the updated resource to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A read operation must be performed prior to this to ensure that the new DocumentReference is the most up to date.
 
 **Note**: A Receiver can only update DocumentReference resources that they created and own.
 
 ### Delete a DocumentReference
-A DocumentReference can be removed by performing a [DELETE](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#delete-/DocumentReference/-id-) request to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A Read operation must be performed prior to this to ensure that the action is appropriate.
+A DocumentReference can be removed by performing a [DELETE](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#delete-/DocumentReference/-id-) request to the /DocumentReference endpoint on the BaRS proxy with the appropriate DocumentReference.id. A read operation must be performed prior to this to ensure that the action is appropriate.
 
-**Note**: A Receiver can only delete DocumentReference resources that they created and own.
+**Note**: A Receiver can only delete DocumentReference resources they created and own.
 
 <a href="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/DocumentReference/BaRS_NRL_Write_Sequence-1.1.0.svg" target="_blank">
 <img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/DocumentReference/BaRS_NRL_Write_Sequence-1.1.0.svg" ></img></a>

guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.1/DocumentReference-StandardPattern/Sender-DocumentReference.md

@@ -10,7 +10,7 @@ The FHIR DocumentReference resource represents a reference to a clinical documen
 ### Step 2: Search for the booking or referral pointer (DocumentReference)
 FHIR DocumentReference resources holding pointers for BaRS bookings and referrals are stored in a central Registry, within NRL (National Record Locator), as decribed above, and interrogated through the [BaRS API DocumentReference](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0#get-/DocumentReference).
 
-To find a booking or referral location, you need to search for the appropriate DocumentReference resource from the Registry, using search parameters. It is mandatory to include the subject:identifier (the patient's NHS number), other parameters can be used to filter the response further e.g type of document (booking and referral). 
+To find a booking or referral location, you need to search for the appropriate DocumentReference resource from the Registry, using search parameters. It is mandatory to include the subject:identifier (the patient's NHS number). Other parameters can be used to filter the response further e.g type of document (booking and referral). 
 
 ### Step 3: Inspect the booking or referral pointer (DocumentReference)
 Once you retrieve the Document Reference(s) (pointers) from the search, inspect the returned resources to identify the one you need. Look for relevant metadata, as described below, to confirm the correct resource.
@@ -37,7 +37,7 @@ The second identifier, required to make the subsequent request for the booking o
 	}
 ```
 
-The third identifier (currently optional) relates to the product-id, system '*https://fhir.nhs.uk/id/product-id*'. This is forth coming functionality and further detail on its utility will follow but [working documentation] (https://github.com/NHSDigital/nhse-epr-integration/blob/main/pages/appendix1.md) is being actively updated.
+The third identifier (currently optional) relates to the product-id, system '*https://fhir.nhs.uk/id/product-id*'. This is forthcoming functionality and further detail on its utility will follow but [working documentation] (https://github.com/NHSDigital/nhse-epr-integration/blob/main/pages/appendix1.md) is being actively updated.
 
 ```json
 "identifier": [

guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/Firewallexceptions.md

@@ -1,3 +1,7 @@
+---
+topic: firewall-exceptions
+---
+
 ## {{page-title}}
 
 BaRS receivers need to configure firewall exceptions for both Integration (INT) and Production (PROD) environments.