diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/About-BaRS.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/About-BaRS.page.md
index 0ec91f08..e2dc2e6e 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/About-BaRS.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/About-BaRS.page.md
@@ -1,67 +1,8 @@
# {{page-title}}
-The NHS Booking and Referral standard (known as BaRS) is a **framework standard** for interoperability.
-
-- BaRS offers a **universal** standard way to **digitise workflows** that support all cross service patient journeys in the NHS
-- It is based on [FHIR R4]( https://hl7.org/fhir/R4/) and fully supports [UK Core]( https://simplifier.net/hl7fhirukcorer4)
-- It is a set of instructions, rules and guidance on how to use the building blocks of FHIR to **digitise workflows**
-- This provides a **framework** for suppliers to build solutions in a way that **guarantees compatibility**
-
-The majority of cross service flows in the NHS can be loosely defined as referrals however, there are many more formal definitions of referrals and BaRS is intended to support all of them and more. The primary goal is to create a framework that suppliers can operate within to share information about a patient, with some sort of directive or request for further care or tasks. This can optionally be supported by an appointment (e.g. the reservation of resource for an event at a specific time/place).
-
-
-## Summary of the key features
-
-In order to achieve this, BaRS has adopted the approach of standardising everything that can and should be standardised whilst creating a safe space for solutions to have the necessary flexibility to support all flows whilst maintaining compatibility.
-
-There are three main "layers" that make up the framework within BaRS:
-
-The **first** is the transport layer (referred to as BaRS Core). This is all the things that define the way two systems "talk" to each other and this layer is absolutely standardised. All systems will implement these things exactly the same way.
-
-**Second** there is the "workflow" layer. This allows a specific BaRS compliant solution to support a particular patient journey. The *way* a workflow is articulated is standardised and each particular workflow is made up of a combination of underlying standard operations (defined in the "transport layer") in a particular sequence.
-
-**Third** there is the Payload layer. The "payloads" are collections of FHIR resources that make up the set of information that is required for the receiving system to complete or deliver the intended service or task that is being requested.
-
-The workflow and payload elements can be predefined or completely dynamic, enabled by the inbuilt content negotiation mechanism, as required by the needs of each specific use case and the sophistication of the systems implementing compliant solutions.
-
-The documentation for BaRS is separated into three groups (or "products"):
-
-- {{pagelink:design-core-1.0.7}} is the foundation containing all the things *everyone* has to do regardless of what flows BaRS is being used to support
-
-- {{pagelink:Applications}}, *apply* the standard to a specific problem and build on this to support specific use cases
-
-- {{pagelink:prereleases}}, this is the same as above but for applications that are in a *pre-release* state, so not generally available until private/public beta is complete.
-
-
-
-## Foundation Principles
-
-During the design and development of the standard, all key decisions are being tested against a set of foundation principles. These were set out at the beginning as a way to ensure that the vision for BaRS is delivered and all decisions are guided by this vision.
-
-**Low Barrier to Entry**
-
-There is little point for a standard with the ambition and scope of BaRS being so difficult to implement that no one actually does. Therefore all decisions are made with the intention of making it as easy as possible for **all** suppliers to build solutions quickly and easily.
-
-**Any-to-Any Connectivity**
-
-From the beginning it has been very important to ensure that all solutions are easily scalable and it is possible to interoperate with another system without any prior knowledge or pre-configuration inplace. So that all interactions are:
-
-- live and "on-the-fly"
-- all information is available in realtime from the source
-- there is no prior knowledge required for transmission
-- there is no requirement for anything to use "point-to-point" interactions (although this approach is supported when approriate)
-
-**Universality**
-
-The primary vision for BaRS has always been to create one standard way of supporting movement of patients and their information accross services. Therefore all decisions have this idea at their heart. Research has allowed us to model the primary, high level steps as a sequence of discrete uncoupled processes that are the same every time these flows happen.
-
-Additionally, in order to support all possible variations of these flows, the receiver *must* dictate the "payload".
-
-Rather than the traditional approach of the sender sending everything they know, for the reciever to have to filter out everything they do not need to know, the reciever gets to state what they need to know to do the thing that is being requested of them. No more, no less.
-
-Finally, all decisions are tested against as many obscure and exotic "what-if" scenarios as possible. The intention is to avoid building a standard that only works in one care setting but not another.
-
-If you have come to this implementation guide directly it might be helpful to read some information about the program that is responsible for developing and maininting this standard, please see here: [Booking and Referral Standard (BaRS)](https://digital.nhs.uk/services/booking-and-referral-standard "Booking and Referral Standard (BaRS)")
+The NHS Booking and Referral standard (BaRS) Implementation Guide is intended as a resource to support product and development teams in their BaRS development journey. You can find out more about what BaRS is, how it works, who it's for and which system suppliers are already assured or working on their development on the [BaRS NHS Service Catalogue](https://digital.nhs.uk/services/booking-and-referral-standard) pages.
+
+This section provides information to help you use the Implementation Guide.
## Combining the elements together
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 55e9fb8f..2e6fd5ed 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
@@ -19,7 +19,7 @@ topic: Application4
111 - ED
111 - UTC
CAS - ED
CAS - UTC
999 - ED
999 - UTC
111 - SDEC
CAS - SDEC
999 - SDEC
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: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
111 Online - ED
111 Online - UTC
S&R - ED
S&R - UTC
| 2.0.0 | v1.0.0 | v1.0.0 | +| {{pagelink:application3, text: Referral into UEC (Application 3)}} |
999-CAS Referral
| 2.0.0 | 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
| 2.0.0 | 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.1, text:v1.3.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 37f7bfe1..549e25c4 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
@@ -6,7 +6,7 @@ topic: prereleases
This section contains implementation guides for applications that are currently in a pre-release state.
-They are offered as a preview of a developing guide for information only. They are not intended to be used until the completed v1.0.0 version of a guide is released
If you are interested in developing a BaRS compliant solution right now for a use case covered by one of these guides, please use the contact form here and the team will be in touch +They are offered as a preview of a developing guide for information only. They are not intended to be used until the completed v1.0.0 version of a guide is released.
If you are interested in developing a BaRS compliant solution right now for a use case covered by one of these guides, please use the contact form here and the team will be in touch. These guides are designed to be used in conjunction with the documentation for {{pagelink:design-core}}. @@ -14,7 +14,7 @@ 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.3.0 and above | {{pagelink:design-core-1.1.4, text:Core v1.3.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.6 | 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}} |
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Connect-as-a-receiver.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Connect-as-a-receiver.page.md
index f4359b0c..ea3ceb80 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Connect-as-a-receiver.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Connect-as-a-receiver.page.md
@@ -6,15 +6,16 @@ topic: Connect-as-a-receiver
BaRS uses TLS-MA to communicate with Receiving endpoints. Receiving endpoints need a certificate under the NHS Root CA to facilitate TLS-MA. The receiver needs to follow these steps to access Integration (INT) and Production (PROD) environments.
-To connect to the BaRS proxy as a receiver follow these steps:
+### 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 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
- * [INT Certificate](https://digital.nhs.uk/services/path-to-live-environments/integration-environment#rootca-and-subca-certificates) chains (**Note:** _these may be out of date_)
- * [PROD Certificate](https://digital.nhs.uk/services/path-to-live-environments/live-environment) chains (**Note:** _these may be out of date_)stered, you can then begin the process to obtain your certificate by generating a certificate request.
-The fully qualified domain name (FQDN) is equal to the certificate name (CN) by convention.
+There are different certificate chains for INT and PROD:
+* [INT Certificate](https://digital.nhs.uk/services/path-to-live-environments/integration-environment#rootca-and-subca-certificates) chains (**Note:** _these may be out of date_)
+* [PROD Certificate](https://digital.nhs.uk/services/path-to-live-environments/live-environment) chains (**Note:** _these may be out of date_)
+
+Your domain must be registered before you begin the process to obtain your certificate generating a certificate request. The fully qualified domain name (FQDN) is equal to the certificate name (CN) by convention.
Step 3: Create a Certificate Signing Request (*.csr). This is the file you will send to us so we can generate a signed certificate for your endpoints. Create a private key; a password is optional.
```
@@ -29,28 +30,36 @@ openssl req -new -key private.key -out request.csr
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:
#### Client certificate: Integration (INT)
+
Step 1: Contact ITOC to make a [Combined endpoint and service registration request](https://digital.nhs.uk/services/path-to-live-environments/path-to-live-forms/combined-endpoint-and-service-registration-request)
{{render:Onboarding FORM.png}}
- In the form:
- * Select Create/renew a certificate only (No endpoint)
- * Specify Integration environment
- * FQDN must match your domain and CN on the cert e.g. '**BaRS-INT-\
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/DirectoryOfServiceConfiguration.md b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/DirectoryOfServiceConfiguration.md
index ea7d32f2..7aeda3a1 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/DirectoryOfServiceConfiguration.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/DirectoryOfServiceConfiguration.md
@@ -1,14 +1,6 @@
## {{page-title}}
-**Note:** **Receiver Firewall Amendments** - Requests from the BaRS API Proxy will originate from **INT** on **35.197.254.55** & **35.246.55.143** and **PROD** on **34.89.0.111** & **34.89.69.6**.
-
-If the provider operates within Urgent and Emergency Care (UEC), they are likely to have a UEC Directory of Services (DoS) entry. DoS leads must configure Service Providers who wish to use BaRS in the standard way, as the service dictates, but their DoS ID will also need to exist in the BaRS Endpoint Catalogue.
-Steps to configure the provider on the BaRS Endpoint Catalogue:-
-- note the Service ID on DoS
-- Obtain API endpoint details for the service from the Supplier or Provider
-- Email bookingandreferralstandard@nhs.net with both pieces of information from above, stating the environment to be configured (INT or Prod).
-You should include the proposed dates for testing (if known) to allow the urgency of the request to be set
-
-**Note**: - CareConnect configuration must be maintained alongside the BaRS configuration. This is so senders who are not yet BaRS compliant can still work with CareConnect and GP Connect.
+If the Receiving provider operates within Urgent and Emergency Care (UEC), they are likely to have a UEC Directory of Services (DoS) entry. DoS leads must configure Service Providers who wish to use BaRS in the standard way, as the service dictates, but their DoS ServiceId will also need to exist in the BaRS Endpoint Catalogue.
+Find out more about the [Directory of Service](https://digital.nhs.uk/services/directory-of-services-dos#top)
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/toc.yaml b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/toc.yaml
index f4bcfd0d..32f70d07 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/toc.yaml
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Deploy/Technical-deployment/toc.yaml
@@ -1,8 +1,10 @@
- name: Index
filename: Index.page.md
-- name: Technical deployment
- filename: Technicaldeployment.page.md
+- name: Technical Deployment
+ filename: TechnicalDeployment.page.md
- name: DoS Configuration
filename: DirectoryOfServiceConfiguration.md
-- name: Firewall exceptions
- filename: Firewallexceptions.md
\ No newline at end of file
+- name: BaRS Endpoint Catalogue
+ filename: BaRSEndpointCatalogue.md
+- name: Firewall Exceptions
+ filename: FirewallExceptions.md
\ No newline at end of file
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md b/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md
index c6a718fc..d949f92e 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md
@@ -16,6 +16,7 @@ Before starting implementation, we recommend reading the following information:
+
The implementation guide is divided into sections:
* {{pagelink:about_bars}} provides essential background and guiding principles along with prerequisites