Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@
|---------------------------------------|---------------------------------------------------------------------------------------------------------|
| Bug fixes and corrections |There have been several bug fixes and corrections in the guide, these includes typos, broken links or corrections.|
| Home page |The heading has been updated to make it clear to users that they are in the BaRS Implementation Guide, quick start guide link has been separated to improve direct navigation and content has been transformed based on user feedback|
| Deploy |New pages for Technical deployment have been added to support suppliers and providers through specific technical steps in their implementation journey.
| Deploy |New pages for Technical deployment have been added to support suppliers and providers through specific technical steps in their implementation journey.|
| Assure |Provided clarity on the expectations and limitation of the assurance process.|

<br>
<hr>
Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,15 @@
## {{page-title}}

Assurance is central to building a BaRS solution, inherent in both documentation and tooling.
Assurance is central to developing a BaRS compliant solution.

The assurance process exists to ensure solutions are compliant with the Standard and robust enough to interoperate with each other in a Live environment. The rationale for stringent assurance is to ensure solutions who have never engaged before will work with each other. BaRS is a truly interoperable Standard that will work across many areas of the Health & Care space and certain solutions may interact infrequently.
The assurance process ensures solutions adhere to the Standard and are compatible with each other when they integrate in the production environment. This guarantee of compatibility is essential to enable interoperability between healthcare systems, which BaRS supports and encourages through dynamic, real-time, service discovery.

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
* 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
* Regression testing of supplier solution to ensure that existing functionality has not been adversely affected
Original file line number Diff line number Diff line change
Expand Up @@ -16,4 +16,17 @@ Step 2: trust the Certificate Authorities (CA) mentioned below. For INT this wil
openssl x509 -in barsintreceiver.cer -text -noout
```

Step 3: The above steps enables access to the APIM platform. To authorise the access to the BaRS Proxy (which is hosted on the APIM Platform), you must provide the following to the BaRS Team (via email <england.bookingandreferralstandard@nhs.net>):

* App Name*
* App ID (PROD)*
* App ID (INT) (both App IDs are needed to connect to PROD)*
* App Description*
* Name of the Organisation
* ODS code of the Organisation
* Product Name (as stated in the SCAL or TCC)
* JWKS resource URL (if self hosting)
* KID for JWKS (if APIM host and defined in earlier steps)
* Public key (if APIM host and generated in earlier steps)

The starred (\*) items can be found by logging into the [Digital Onboarding Service](https://onboarding.prod.api.platform.nhs.uk) and selecting 'Environment access' under the *Introduction and onboarding* section.
Original file line number Diff line number Diff line change
@@ -1,3 +1,7 @@
---
topic: configure-endpoint-catalogue
---

## {{page-title}}

Every service receiving messages through BaRS will need their ServiceId and endpoint added to the BaRS Endpoint Catalogue. This enables the BaRS Proxy to direct messages to the service.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -9,5 +9,18 @@ This page is intended as guidance for all parties involved in deployments of BaR
</p>
</div>

This is an abbreviated deployment guide, focused exclusively on the technical steps, to connect and configure healthcare Service Providers utilising BaRS. It is aimed at Suppliers and Service Providers (Project Managers, Business Analysts, Application Delivery Specialists, etc.) connecting their solutions to the BaRS Proxy infrastructure and related components.

* Supplier installs BaRS compliant solution to Sender system environment
* {{pagelink:connect-as-a-sender, text:Connect Sender}} to BaRS Proxy
* Supplier install BaRS compliant solution to Receiver system environment
* {{pagelink:Connect-as-a-receiver, text:Connect Receiver}} to BaRS Proxy
* Identify or create Service profile(s) for the Receiving service(s) on the chosen national or proprietary Directory of Service*
* Provide detail of configured services and systems to BaRS Team to {{pagelink:configure-endpoint-catalogue, text:configure in the Endpoint Catalogue}}
* Test configuration between newly configured systems

\* If a Sender is to receive an asynchronous response from the Receiver, as part of the defined workflow, they will also require a Service profile. This will need configuration in the {{pagelink:configure-endpoint-catalogue, text:Endpoint Catalogue}} too.

NB- These steps apply to connecting and configuring systems to both the Integration (INT) and Production (PROD) environment.

<br>
Loading