back
BaRS Core Change Log
This page will list all changes to the BaRS Core.
- Indicates a change inspired by provider or supplier feedback.
| Key |
Description |
| non-breaking |
Non-breaking changed introduced to the standard since the last release |
| breaking |
Breaking changed introduced to the standard since the last release |
| correction |
Correction to the standard since the last release |
1.1.3
| Change |
Description |
Impact |
| Concurrent Core Versions |
Core Versions were split for concurrent versions. Command 'pagelink' could not render: Page not found. branches from previous 1.2.1 excluding feature additions 1.2.x (alpha). |
non-breaking |
| Content Negotiation documentation has been improved |
{{pagelink:core-content-negotiation, text:Content Negotiation} is now explicitly documented |
non-breaking |
| Standard Patterns for BaRS Operations - New Use-Cases Category section |
Describes the purpose and implementation of Use-case categories in BaRS workflows. |
non-breaking |
| Standard Pattern for Appointments - New |
Describes the purpose and implementation of Appointments |
non-breaking |
| Standard Pattern for DocumentReference - New |
Describes the purpose and implementation of DocumentReferences |
non-breaking |
| Core>Security and Authorisation>Authorsation - Removed NHSD-Requesting-Person HTTP Header |
NHSD-Requesting-Person is no longer used in the API Specification. |
non-breaking |
| Core>Security and Authorisation>Authorsation - Updated NHSD-Requesting-Practitioner HTTP Header |
NHSD-Requesting-Practitioner stated it was based on an Organization FHIR resource rather than the correct PractitionerRole. |
non-breaking |
| MessageDefintion and Capability Statement examples updated to reflect versioning |
The Capability Statement and Message Definition examples on Simplifier have been updated (and annotated) to accurately reflect how a supplier must implement versioning. |
non-breaking |
| Amended GET /Slot Failure Scenarios |
Corrected the required number of parameters, from three to two, to align with the API Spec |
correction |
Previous Releases
1.1.2
| Change |
Description |
Impact |
| Messge Definition Change for Referral |
BaRS Message Definition ServiceRequest - Request Referral, has had the following changes: optional Location (Incendent Location) resource, optional Questionaire resource, optional Communication and an optional Procedure resources have been added |
non-breaking |
| New Message Definition added |
BaRS Message Definition ServiceRequest - Response Referral Short, has been introduced to support short referral responses |
non-breaking |
| - Updated Capability Statement Example |
A full capability statement has been added as an example |
non-breaking |
| New Use Cases Categories BaRS |
New Use Cases Categories for BaRS have been added to support Application 6 |
non-breaking |
1.1.1
| Change |
Description |
Impact |
| MessageDefinitions updated |
MessageDefinitions updated to reflect Scene Safety flag as an optional element |
non-breaking |
| Flag Rejected services Code updated |
Flag Rejected services Code updated to SNOMED value and 111 to ED example amended |
non-breaking |
| Location and CDSS extensions updated |
Location and CDSS extensions have snapshot element removed, enabling the new fix from Firely to generate them automatically |
non-breaking |
1.1.0
| Change |
Description |
Impact |
| Changes to BaRS API Spec |
Multiple API SPEC changes were made requiring an uplift to the BaRS Core version. Details can be seen here: API Spec Change log v1.1.0 |
|
1.0.3
| Change |
Description |
Impact |
| Amended GET /Slot Failure Scenarios |
Corrected the required number of parameters, from three to two, to align with the API Spec |
correction |
| Concurrent Core Versions |
Core Versions were split for concurrent versions. Command 'pagelink' could not render: Page not found. branches from previous 1.2.1 excluding feature additions in 1.1.x and 1.2.x (alpha). |
non-breaking |
| Content Negotiation documentation has been improved |
{{pagelink:core-content-negotiation, text:Content Negotiation} is now explicitly documented |
non-breaking |
| Standard Patterns for BaRS Operations - New Use-Cases Category section |
Describes the purpose and implementation of Use-case categories in BaRS workflows. |
non-breaking |
| Core>Security and Authorisation>Authorsation - Removed NHSD-Requesting-Person HTTP Header |
NHSD-Requesting-Person is no longer used in the API Specification. |
non-breaking |
| Core>Security and Authorisation>Authorsation - Updated NHSD-Requesting-Practitioner HTTP Header |
NHSD-Requesting-Practitioner stated it was based on an Organization FHIR resource rather than the correct PractitionerRole. |
non-breaking |
| MessageDefintion and Capability Statement examples updated to reflect versioning |
The Capability Statement and Message Definition examples on Simplifier have been updated (and annotated) to accurately reflect how a supplier must implement versioning. |
non-breaking |
1.0.0
| Change |
Description |
Impact |
| Human readable referrences |
Human readable references, created as part of a referral or booking, must be clearly available to users in both Sending and Receiving systems. |
breaking |
| Caching Endpoints |
If caching of endpoints is supported. There must be a mechanism to clear this manually. |
breaking |
| Support for NHS Number statuses |
Support for either no NHS No, or an NHS No with a verification status of 'number-present-and-verified' only. |
breaking |
| Access Control |
The implementation of access control needs to be within the spirit of BaRS principles which is open, any to any unless explicitly denying a system access. |
non-breaking |
| Birth Sex |
Birth Sex is no longer required to be populated as part of the Patient resource and may be carried as an observation. If this is received it must be displayed. |
non-breaking |
| Only sending with BaRS |
Suppliers must amend their solution and not attempt to send ITK or other methods when BaRS is used. |
non-breaking |
| Physical architecture diagrams |
Physical architecture diagrams must be provided as part of the assurance process. |
correction |
| Monitoring & Alerting |
A mechanism for triggering alerts for persistent failures or errors. A threshold for repeated failures was required so that relevant stakeholders could be made aware of issues in real-time. |
correction |
| Failure dashboard |
The NHS dashboard has been updated for visibility of current state and potential issues for stakeholders in real time to aid in the tracking of issues. |
correction |
