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.2.1
| 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 |
Previous Releases
1.2.0
| 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.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 |