You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/About-BaRS.page.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ The workflow and payload elements can be predefined or completely dynamic, enabl
26
26
27
27
The documentation for BaRS is separated into three groups (or "products"):
28
28
29
-
- {{pagelink:design-core-1.0.6}} is the foundation containing all the things *everyone* has to do regardless of what flows BaRS is being used to support
29
+
- {{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
30
30
31
31
- {{pagelink:Applications}}, *apply* the standard to a specific problem and build on this to support specific use cases
*[BaRS FHIR API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0)
12
12
@@ -16,10 +16,10 @@ We recommend reading the following documentation as part of the discovery stage
16
16
Full details of the security model adopted by the platform can be found under the [security](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/application-restricted-restful-apis-signed-jwt-authentication) section.
17
17
18
18
### Design
19
-
The following sections provide the essential information needed to design and build a BaRS compliant solution. BaRS is devised in a way to support re-use of functionality across multiple uses cases, to this end the implementation guidance is split into {{pagelink:design-core-1.0.6, text:BaRS Core}} and {{pagelink:applications, text:BaRS Application}} sections. All solutions **must** build the Core and add the specific requirements of the Application to support the given use case. BaRS Core is not sufficient on its own, an Application will always be required.
19
+
The following sections provide the essential information needed to design and build a BaRS compliant solution. BaRS is devised in a way to support re-use of functionality across multiple uses cases, to this end the implementation guidance is split into {{pagelink:design-core-1.0.7, text:BaRS Core}} and {{pagelink:applications, text:BaRS Application}} sections. All solutions **must** build the Core and add the specific requirements of the Application to support the given use case. BaRS Core is not sufficient on its own, an Application will always be required.
20
20
21
21
### End-to-end workflow
22
-
When developing against the standard, understanding the {{pagelink:core-EndToEndWorkflow-1.0.6, text:end-to-end workflow}} is key. This section of the guide describes how a solution interacts with the BaRS API, along with the assumptions and expectations of Senders and Receivers. These are the roles suppliers will adopt when building a solution. This guide is written predominantly from the perspective of the request; the Sender and Receiver of the request. However, if the BaRS Application include a response workflow these roles swap, the Sender becoming the Receiver and vice versa.
22
+
When developing against the standard, understanding the {{pagelink:core-EndToEndWorkflow-1.0.7, text:end-to-end workflow}} is key. This section of the guide describes how a solution interacts with the BaRS API, along with the assumptions and expectations of Senders and Receivers. These are the roles suppliers will adopt when building a solution. This guide is written predominantly from the perspective of the request; the Sender and Receiver of the request. However, if the BaRS Application include a response workflow these roles swap, the Sender becoming the Receiver and vice versa.
23
23
24
24
BaRS includes several {{pagelink:applications, text:BaRS Application (use cases)}}, each of which supports multiple use cases that share a common workflow and data model.
25
25
@@ -28,15 +28,15 @@ BaRS includes several {{pagelink:applications, text:BaRS Application (use cases)
28
28
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.
29
29
30
30
### Security
31
-
All {{pagelink:core-Security-1.0.6, text:security}} is provided through our platform. There are two methods for securing interactions via BaRS API:
31
+
All {{pagelink:core-Security-1.0.7, text:security}} is provided through our platform. There are two methods for securing interactions via BaRS API:
32
32
* senders will [generate an access token](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/application-restricted-restful-apis-signed-jwt-authentication#how-this-pattern-works) from the platform and use this to authenticate with the BaRS API. Additionally, requests will include HTTP header values identifying the organisation, software and user, which are passed through the BaRS API to Receivers who apply their own access control to the request based on the headers content.
33
33
* for Receivers accepting requests, the BaRS API secures the connection with the Receiver using Transport Layer Security Mutual Authentication (TLS MA), using an [NHS Root CA issued certificate](https://digital.nhs.uk/services/path-to-live-environments/live-environment#rootca-and-subca-certificates). The HTTP header values (as described above) are also passed through. This provides the Receiver with sufficient information to accept or reject the request without having to inspect the payload body.
34
34
35
35
#### Error Handling
36
-
{{pagelink:core-ErrorHandling-1.0.6, text:Error handling}} is an important part of the standard for two key reasons:
36
+
{{pagelink:core-ErrorHandling-1.0.7, text:Error handling}} is an important part of the standard for two key reasons:
37
37
38
38
* to ensure workflow is as smooth and seamless as possible, the error responses returned **must** be clear to allow the appropriate next action to take place, for example, to include a missing element of information (highlighted by the error response).
39
-
* there are several levels of interactions occurring from the Sender, through BaRS API to the Receiver and clearly identifying where the fault lies is important for swift resolution. All implementations **must** adhere to the {{pagelink:core-ErrorHandling-1.0.6, text:error handling guidance}} which is part of the {{pagelink:assure, text:assurance}} process.
39
+
* there are several levels of interactions occurring from the Sender, through BaRS API to the Receiver and clearly identifying where the fault lies is important for swift resolution. All implementations **must** adhere to the {{pagelink:core-ErrorHandling-1.0.7, text:error handling guidance}} which is part of the {{pagelink:assure, text:assurance}} process.
Release 1.8.2 includes development of the {{pagelink:core-StandardPattern-appointment-1.1.6, text:Appointment Management Foundation}} guidance and supporting changes to the API specification.
23
-
There have been improvements to use-context HTTP header guidance and developer onboarding advice, alongside bug fixes and corrections throughout the guide. Application 5 TKW Receiver scenarios are now documented.
22
+
Release 1.9.0 includes development of the {{pagelink:, text:}} guidance and supporting changes to the cancellation workflows, introduces a search capability to the Implementation Guide and....
23
+
There have been improvements Application 6 use-case descriptons alongside bug fixes and corrections throughout the guide.
24
24
25
25
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 <ahref= "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>.
26
26
@@ -63,6 +63,10 @@ Table detailing active versions of the latest Applications in Production (or cur
0 commit comments