IG Dev 2

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Infrastructure/Index.page.md

@@ -0,0 +1,5 @@
+---
+topic: infrastructure
+---
+
+# {{page-title}}

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Infrastructure/Infrastructure.page.md

@@ -0,0 +1,27 @@
+---
+topic: infrastructure
+---
+
+# Infrastructure
+
+The infrastructure components defined as parts of BaRS are offered for use as a set of centralised services that can support workflows and simplify integration between systems.
+
+There are two elements to this infrastructure:
+
+- **a routing proxy** that enables systems to connect to each other in a scalable way that does not require each side to have pre-configured direct connections
+- a set of enabling **discovery services** that allow BaRS clients to "discover" events, tasks and requests that have been made using BaRS compliant systems from a number of contexts
+
+The routing proxy is the main infrastructure component of BaRS and is hosted and maintained on the centralised NHS API Management platform. It is comprised of several components but, from a developer perspective, it can be thought of as a proxy. All requests are routed through it, it brokers the endpoint for a given service (on behalf of a Sender) and delivers the request to the Receiver. It can support both national and regional scale service service discovery tools. The BaRS Proxy supports scalable, dynamic interoperability and lowers the barrier of entry.  This centralised infrastructure handles the burden of establishing endpoints and connectivity; a Sender need only communicate with the BaRS proxy and a Receiver only needs to accept requests from it.
+
+Components of BaRS centralised infrastructure are as follows:
+
+| Component             | Description  |
+|-----------------------|--------------|
+| BaRS  Proxy API       | Senders direct all requests to this Proxy API for all requests.  |   
+| Endpoint   catalogue  | A component that holds service identifiers and their corresponding physical addresses. It is capable of supporting national and local directory of services or even standalone   endpoints configured within a single system. Providers will be able to manag their endpoints via an API. |
+
+
+
+                                                                                                                                                                                                                                                                         |
+
+<hr>

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Infrastructure/toc.yaml

@@ -0,0 +1,8 @@
+- name: Index
+  filename: Index.page.md
+- name: Principles and prerequisites
+  filename: Principles-and-prerequisites.page.md
+- name: Principles for rendering BaRS payloads
+  filename: Principles-for-rendering-BaRS-payloads.page.md
+- name: Principles for integration systems
+  filename: Principles-for-Integration-systems.page.md

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/toc.yaml → guides/Live-ImplementationGuide-BaRS/Home/Analysis/toc.yaml

@@ -2,9 +2,14 @@
   filename: About-BaRS
 - name: BaRS Principles and Prerequisites
   filename: BaRS-Principles-and-Prerequisites
+- name: Content Negotiation
+  filename: Content-Negotiation
+- name: Infrastructure
+  filename: Infrastructure 
 - name: Releases
   filename: Releases
+- name: Roles and responsibilities
+  filename: RolesAndResponsibilities.md
 - name: Versioning
   filename: Versioning.guide.md
-- name: Content Negotiation
-  filename: Content-Negotiation
+

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md

@@ -57,7 +57,7 @@ When a BARS Receiver processes information in a Flag resource;
 
 * they **should** populate a flag in their system, if their solution supports that flag
 * they **must** display the information in the Flag resource in a way that supports the associated workflow (i.e. the relevant end users can see it and act upon it)
-* rendering of Flag information must be in line with the {{pagelink:Home/About-BaRS/BaRS-Principles-and-Prerequisites/Principles-for-rendering-BaRS-payloads.page.md, text:Principles for rendering BaRS Payload }}.
+* rendering of Flag information must be in line with the {{pagelink:Home/Analysis/BaRS-Principles-and-Prerequisites/Principles-for-rendering-BaRS-payloads.page.md, text:Principles for rendering BaRS Payload }}.
 
 ### Observation 
 The Observation resource is used to carry assertions supporting the assessment performed by the Sender. In the BaRS UEC Applications, Senders **should** add clinical notes to the Careplan resource rather than Observation, especially where they expect a Receiver to act upon the information. 

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md

@@ -57,7 +57,7 @@ When a BARS Receiver processes information in a Flag resource;
 
 * they **should** populate a flag in their system, if their solution supports that flag
 * they **must** display the information in the Flag resource in a way that supports the associated workflow (i.e. the relevant end users can see it an act upon it)
-* rendering of Flag information must be in line with the {{pagelink:Home/About-BaRS/BaRS-Principles-and-Prerequisites/Principles-for-rendering-BaRS-payloads.page.md, text:Principles for rendering BaRS Payload }}.
+* rendering of Flag information must be in line with the {{pagelink:Home/Analysis/BaRS-Principles-and-Prerequisites/Principles-for-rendering-BaRS-payloads.page.md, text:Principles for rendering BaRS Payload }}.
 
 ### Observation 
 The Observation resource is used to carry assertions supporting the assessment performed by the Sender. In the BaRS UEC Applications, Senders **should** add clinical notes to the Careplan resource rather than Observation, especially where they expect a Receiver to act upon the information. 

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/Payloads.page.md

@@ -53,7 +53,7 @@ When a BARS Receiver processes information in a Flag resource;
 
 * they **should** populate a flag in their system, if their solution supports that flag
 * they **must** display the information in the Flag resource in a way that supports the associated workflow (i.e. the relevant end users can see it and act upon it)
-* rendering of Flag information must be in line with the {{pagelink:Home/About-BaRS/BaRS-Principles-and-Prerequisites/Principles-for-rendering-BaRS-payloads.page.md, text:Principles for rendering BaRS Payload }}.
+* rendering of Flag information must be in line with the {{pagelink:Home/Analysis/BaRS-Principles-and-Prerequisites/Principles-for-rendering-BaRS-payloads.page.md, text:Principles for rendering BaRS Payload }}.
 
 ### Consent 
 In the BaRS UEC Applications the level of consent is stipulated to be for 'Direct Care' only. A referral **must** contain a Consent resource and it **must** adhere to the [example](https://simplifier.net/NHSBookingandReferrals/8fc39b95-89a6-45fb-914f-1458a10e9e14/~json) provided under the BaRS FHIR assets. 

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

@@ -11,18 +11,18 @@ This page is intended as guidance for all parties involved in deployments of BaR
 
 Implementing a solution requires good knowledge of the environment being deployed to, allowing a plan to be established to check all conditions are met for success. This section covers deployment, along with the necessary checks to prove functionality, to fully test end-to-end capable {{pagelink:Home/Build/Testing-and-Environments, text:environments}}. 
 
-When deploying a solution there are many threads to pull together. The developed solution is one part of this but the local environment it is to be deployed into must also be prepared, as well as  confirming workflow and functionality behave as expected. The fundamental steps will include completing {{pagelink:Home/Build/Testing-and-Environments/Onboarding.page.md, text:BaRS Onboarding}}, upgrading solutions, configuration and testing.
+When deploying a solution there are many threads to pull together. The developed solution is one part of this but the local environment it is to be deployed into must also be prepared, as well as  confirming workflow and functionality behave as expected. The fundamental steps will include completing {{pagelink:Home/Build/Testing-and-Environments/Index.page.md, text:Connecting to environments}}, upgrading solutions, configuration and testing.
 
 The overall aim is take a solution and enable it in an environment (INT or Production) to work with other deployed solutions. 
 
 #### Prerequisites
-In almost all {{pagelink:applications, text:BaRS Applications}}, a solution will act as a Sender and Receiver and need to perform all {{pagelink:Home/Build/Testing-and-Environments/Onboarding.page.md, text:onboarding}} steps. 
+In almost all {{pagelink:applications, text:BaRS Applications}}, a solution will act as a Sender and Receiver and need to perform all {{pagelink:Home/Build/Testing-and-Environments/Index.page.md, text:Connecting to environments}} steps. 
 
 Onboarding must occur for each environment independently; the process is similar for each but the steps must be replicated. 
 
 #### Configuration
 The core steps to complete technical setup in an environment are:-
-* complete {{pagelink:Home/Build/Testing-and-Environments/Onboarding.page.md, text:onboarding}} for the desired environment
+* complete {{pagelink:Home/Build/Testing-and-Environments/Index.page.md, text:Connecting to environments}} for the desired environment
 * install supplier solution in the given Solution Environment (See Testing section)
 * perform any configuration steps to enable BaRS (and related workflows) in the solution 
 * provide service identifier* to be configured in the Endpoint Catalogue (BaRS related component)

guides/Live-ImplementationGuide-BaRS/Home/Deploy/Deploy/KeyDeploymentActivities.page.md

@@ -20,11 +20,11 @@ Business change activities will typically involve:
 - benefits management and realisation
 
 ## Solution Deployment and Configuration
-In almost all {{pagelink:applications, text:BaRS Applications}}, a solution will act as a Sender and Receiver and need to perform all {{pagelink:Home/Build/Testing-and-Environments/Onboarding.page.md, text:onboarding}} steps.
+In almost all {{pagelink:applications, text:BaRS Applications}}, a solution will act as a Sender and Receiver and need to perform all {{pagelink:Home/Build/Testing-and-Environments/Index.page.md, text:Connecting to environments}} steps.
 
 Onboarding must occur for each environment independently; the process is similar for each but the steps must be replicated.
 The core steps to complete technical setup in an environment are:
-- complete {{pagelink:Home/Build/Testing-and-Environments/Onboarding.page.md, text:onboarding}} for the desired environment
+- complete {{pagelink:Home/Build/Testing-and-Environments/Index.page.md, text:Connecting to environments}} for the desired environment
 - install supplier solution in the given Solution Environment (See Testing section)
 - perform any configuration steps to enable BaRS (and related workflows) in the solution
 - provide service identifier* to be configured in the Endpoint Catalogue (BaRS related component)

guides/Live-ImplementationGuide-BaRS/Home/FHIR-Assets/Index.page.md

@@ -7,3 +7,35 @@ topic: fhir_assets
 </br>
 
 The complete directory of FHIR assets can be found on <a href="https://simplifier.net/NHSBookingandReferrals/~introduction" target="_blank">the simplifier project page</a>
+
+**Profiles**
+
+Profiles are the base for the standard and come from two sources: 
+
+- **UK Core**
+specifies a set of constraints and/or extensions to specific base HL7 FHIR resources to enable consistent information flows within the UK, to improve health and care outcomes for all citizens
+
+- **BaRS**
+specifies additional constraints and/or extensions to UK core profiles, that are common for all BaRS Applications
+
+**Cardinalities**
+
+All attributes defined in FHIR have a cardinality measure defined.  This is the minimum and maximum number of times the data element can appear in any instance of the resource type. Failure to conform to the cardinality of a FHIR attribute will lead to a FHIR validation failure. Visit [cardinality in FHIR](https://hl7.org/fhir/conformance-rules.html) for more details. 
+
+**Necessity**
+
+Necessity indicates whether an element is required for the business process to be successful. Visit [Requirement Levels](https://datatracker.ietf.org/doc/html/rfc2119) for definitions.
+
+**Implementation guidance**
+
+Implementation guidance describes how FHIR is utilised and regulated by BaRS to support interoperable business processes.  Guidance includes generating bundles, building BaRS Application workflows and for individual FHIR resource elements. 
+
+**Message definitions**
+
+Message definitions are a key aspect of BaRS. They define the content of payloads in each Application. BaRS payloads are built to ensure the message to the receiving service includes everything needed to progress the patient journey. The receiver defining the request they receive is a BaRS design principle. {{pagelink:principles_prerequesites, text:BaRS principles and prerequisites}}
+
+**Application**
+
+BaRS Applications define workflows and payloads. They can support any number of use-cases with the same requirements. Suppliers build and are assured for specific Applications. As BaRS grows Applications are expected to include more use-cases, supporting re-use of both the BaRS Application and supplier development.    
+
+<hr>

guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md

@@ -1,32 +1,35 @@
 
 ### Booking and Referral Standard Implementation Guide
 
-This guidance takes you through how to implement the Booking and Referral Standard (BaRS) and gain accreditation. 
+Welcome to the BaRS Implementation guide.
 
-This guide is designed for anyone involved at any stage of going live with BaRS including developers, business analysts and product owners.
+Here you will find a step-by-step guide to help you prepare for implementing BaRS and complete the assurance process.
 
-Before starting implementation, we recommend reading the following information:
+Step 1: {{pagelink:Analysis, text:Analysis}}
+A group of pages to support you to understand what is required to implement BaRS successfully. 
+These include principles and prerequisites, infrastructure, roles and responsibilities and content negotiation.
 
-* {{pagelink:about_bars, text:About BaRS}} and {{pagelink:quick-start-guide, text:quick start guide}} 
-* {{pagelink:design-core-1.3.1, text:End to end workflow }} 
-* {{pagelink:Home/Applications/BaRS-Applications, text:BaRS Applications}} 
-* {{pagelink:core-StandardPattern-appointment-1.3.1, text:Standard Appointment Management (use-case agnostic)}}
-* {{pagelink:build-testing, text:Tooling}} 
+Step 2: {{pagelink:design-core-1.3.1, text:BaRS Core }}
+Familiarise yourself with the core elements of BaRS including end-to-end workflow, security and authorisation, and error handling.
 
-<br>
-<hr>
-<br>
+Step 3: {{pagelink:Home/Applications/BaRS-Applications, text:BaRS use cases and applications}} 
+Decide which use case and Application will meet your needs by exploring workflows and payloads.
 
-The implementation guide is divided into sections:
+Step 4: {{pagelink:fhir_assets, text:FHIR Assets}} 
+Supporting information about the use of FHIR to implement the standard and gain access to BaRS FHIR assets including examples, bundles and CodeSystems.
+
+Step 5: {{pagelink:build-testing, text:Testing and environments}}
+Understand how to connect to the BaRS environments; sandbox, integration and production. Find out how to access the testing tool (TKW). 
+
+Step 6: {{pagelink:assure, text:Gain Assurance}}
+Understand and complete the assurance process using the supplier conformance assessment list (SCAL). Follow steps to create an account with the Digital Onboarding Service.
+
+Step 7: {{pagelink:deploy, text:Deployment Toolkit}}
+Use the deployment toolkit to carry out the necessary checks to prove functionality and to fully test end-to-end capable
+environments ready to go live. 
+
+
+For an overview of the booking and referrals standard visit the [NHSE website](https://digital.nhs.uk/services/booking-and-referral-standard). 
 
-* {{pagelink:about_bars}} provides essential background and guiding principles along with prerequisites
-* {{pagelink:design-core-1.3.1, text:BaRS Core}} provides a core set of functionality across version of Core
-* {{pagelink:Home/Applications/BaRS-Applications,text:BaRS Application summaries}} provides links to implementation guides for released BaRS applications
-* {{pagelink:build-testing}} provides information about testing and environments
-* {{pagelink:assure}} describes guidance for the assurance process
-* {{pagelink:deploy}} provides the deployment toolkit
-* {{pagelink:fhir_assets}}, a link to the complete directory of FHIR assets
-* {{pagelink:help}} provides a link to support requests
-* {{pagelink:ReportanIncident}} describes how to report a live service incident for suppliers and providers live with BaRS