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-alpha
Change |
Description |
Impact |
Payload business requirement definition added to Processing Requests |
Provided explanation on the business requirement level for elements within a payload and how they are defined by RFC 2119 |
non-breaking |
Update guidance for patient.Id under Referral Cancellation |
Implementation Guidance was incorrect for element. |
non-breaking |
Typo against patient.meta.lastUpdated under Referral Cancellation |
Element name was incorrect. Recectified typo. |
non-breaking |
Update guidance for patient.Id under Booking Cancellation |
Implementation Guidance was incorrect for element. |
non-breaking |
Typo against patient.meta.lastUpdated under Booking Cancellation |
Element name was incorrect. Recectified typo. |
non-breaking |
Booking Cancellation ERD link incorrect |
Booking Cancellation ERD previously lauched Referral Cancellation ERD when clicked. This has been resolved to point to the Booking Cancellation ERD. |
non-breaking |
Addition of HTTP header for Logging and Auditing |
Logging and auditing header added to all versions of Core. |
non-breaking |
1.1.5
Change |
Description |
Impact |
Payload business requirement definition added to Processing Requests |
Provided explanation on the business requirement level for elements within a payload and how they are defined by RFC 2119 |
non-breaking |
Update guidance for patient.Id under Referral Cancellation |
Implementation Guidance was incorrect for element. |
non-breaking |
Typo against patient.meta.lastUpdated under Referral Cancellation |
Element name was incorrect. Recectified typo. |
non-breaking |
Update guidance for patient.Id under Booking Cancellation |
Implementation Guidance was incorrect for element. |
non-breaking |
Typo against patient.meta.lastUpdated under Booking Cancellation |
Element name was incorrect. Recectified typo. |
non-breaking |
Booking Cancellation ERD link incorrect |
Booking Cancellation ERD previously lauched Referral Cancellation ERD when clicked. This has been resolved to point to the Booking Cancellation ERD. |
non-breaking |
Addition of HTTP header for Logging and Auditing |
Logging and auditing header added to all versions of Core. |
non-breaking |
1.0.5
Change |
Description |
Impact |
Payload business requirement definition added to Processing Requests |
Provided explanation on the business requirement level for elements within a payload and how they are defined by RFC 2119 |
non-breaking |
Update guidance for patient.Id under Referral Cancellation |
Implementation Guidance was incorrect for element. |
non-breaking |
Typo against patient.meta.lastUpdated under Referral Cancellation |
Element name was incorrect. Recectified typo. |
non-breaking |
Update guidance for patient.Id under Booking Cancellation |
Implementation Guidance was incorrect for element. |
non-breaking |
Typo against patient.meta.lastUpdated under Booking Cancellation |
Element name was incorrect. Recectified typo. |
non-breaking |
Booking Cancellation ERD link incorrect |
Booking Cancellation ERD previously lauched Referral Cancellation ERD when clicked. This has been resolved to point to the Booking Cancellation ERD. |
non-breaking |
Addition of HTTP header for Logging and Auditing |
Logging and auditing header added to all versions of Core. |
non-breaking |
Previous Releases
1.1.4
Change |
Description |
Impact |
Corrections to 1.0.x API Spec |
API Spec Updates Can be viewed in the API Spec Change Log. |
|
Corrections to Standard Patterns for Appointments |
Missing features and capabilities (List, view and GET Slots) have now been documented in Standard Patterns for Appointments |
correction |
1.0.4
Change |
Description |
Impact |
Corrections to 1.0.x API Spec |
API Spec Updates Can be viewed in the API Spec Change Log. |
correction |
1.2.0-alpha
Important: Versioning information - Preview
This version of core is strictly a preview of what is currently in development for 1.2.0 and should not be built against.
Change |
Description |
Impact |
Preview Standard Pattern for Endpoints - New |
Describes the purpose and implementation of Endpoints |
non-breaking |
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 |
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 |