Patient Flags Service - Reasonable Adjustments (RA) Flag
- Charlotte Kaye
- Michael France (Unlicensed)
- Jenna Bennett (Unlicensed)
Ā
ID | RM133 |
|---|---|
Version | 1.0.1 |
Type | Roadmap Item |
Contracting Vehicle(s) |
Title | Patient Flags Service - Reasonable Adjustments Flag |
|---|---|
Description | Enable national sharing and management of Patients Reasonable Adjustments Flag via the Patient Flags Service - FHIR API |
Date Added | May 2, 2025 |
Standards and Capabilities | |
Change Route | Managed Capacity - Other |
Change Type | New |
Status | Draft |
Publication Date | TBC |
Effective Date | TBC |
Incentives / Funding | No |
Incentive / Funding Dates | N/A |
Background
The Patient Flags Service utilises the Patient Flags Service - FHIR API to facilitate the national sharing, retrieval and maintenance of flags associated with a Patient. Flags supported by the Patient Flags Service - FHIR API are:
Reasonable Adjustments (RA)
Female Genital Mutilation (FGM)
Child Protection - Information Sharing (CP-IS)
The Patient Flags Service - FHIR API can be used to return all flags that are associated with a Patient (for example, it can return that a Patient has an RA Flag and an FGM Flag) or it can be used to return a specific flag and any supporting resources for that flag (for example, it can return the existence of the RA Flag for a given Patient together with supporting resources such as impairments, adjustments and underlying conditions); or that no RA Flag exists for that Patient.
The Patient Flags Service - FHIR API will include extending support for additional flags.
Outline Plan
This Roadmap Item introduces the Patient Flags Service - FHIR API and the Reasonable Adjustments (RA) Flag.
Two further Roadmap Items will introduce additional Patient Flags. These are:
RM236 Patient Flags Service - Child Protection - Information Sharing (CP-IS) Flag.
RM258 Patient Flags Service - Female Genital Mutilation (FGM) Flag.
Suppliers must upload all locally collected Reasonable Adjustments Flags via the POST/BulkUpload endpoint or another agreed bulk upload method before initiating use of the Patient Flags Service - FHIR API. All records in the bulk upload must be validated and synchronised with the Personal Demographic Service (PDS) before submission to the POST/BulkUpload endpoint (or other agreed bulk upload method) to ensure that the record submitted has the correct Patient identifier. The POST/BulkUpload endpoint (or other agreed bulk upload method) will not perform any Patient validation checks and will commit the changes submitted in the file.
Suppliers are to use the Digital onboardingĀ process for this Patient Flags Service - FHIR API.Ā
Supplier Solutions must be fully compliant with this change by the Effective Date.
Summary of Change
Patient Information Maintenance - GP: MUST Epic added |
E00622 - Patient Flags ServiceAs a Health or Care Professional I want the Solution to be integrated with the Patient Flags Service So that I can manage and view Patient Flags and their supporting resources Acceptance criterion 1: update Patient Flag within Patient Flags Service based on Patient informationGiven the Health or Care Professional is permitted to manage the Patient Flag When the Health or Care Professional selects to update a Patient Flag on a Patientās Electronic Patient Record (EPR) Then the Patient Flag details are updated on the Patientās Electronic Patient Record (EPR) And any supporting resource for the Patient Flag is updated And the Patient Flag data is sent to the Patient Flags Service Acceptance criterion 2: update Patient Flag on a Patients Electronic Patient Record (EPR) based on data within the Patient Flags ServiceGiven the Health or Care Professional is permitted to manage the Patient Flag When the Health or Care Professional selects to update the Electronic Patient Record (EPR) based on data received from the Patient Flags Service Then the Patient Flag is updated on the Patientās Electronic Patient Record (EPR) And any supporting resource for the Patient Flag is updated Acceptance criterion 3: reject Patient Flag update from Patient Flags ServiceGiven the Health or Care Professional is permitted to manage the Patient Flag When the Health or Care Professional selects to reject the Patient Flag update Then the Patient Flag data is updated on the Patient Flags Service Acceptance criterion 4: display Patient FlagGiven the Health or Care Professional is permitted to manage the Patient Flag When the Health or Care Professional selects to view a Patientās Electronic Patient Record (EPR) Then the Patient Flag is displayed And any supporting resource for the Patient Flag is displayed E00622 - Additional Implementation DetailsSolutions MUST comply with the following when implementing this Epic:
E00622 - Supporting Information
|
Patient Information Maintenance - GP: MUST Epic updated |
E00255 - display Patient Alerts for Electronic Patient Records (EPRs)As a Health or Care Professional I want Patient Alerts to be displayed for Electronic Patient Records (EPRs) So key characteristics relating to the Patient are indicated to Health or Care Professionals Acceptance criterion 1: display Patient Alert in Electronic Patient Records (EPRs)Given the Health or Care Professional is permitted to view Electronic Patient Records (EPRs) When the Health or Care Professional selects to view a Patientās Electronic Patient Record (EPR) And a Patient Alert is recorded for that Patient's Electronic Patient Record (EPR) Then the Patient Alert is displayed E00255 - Supporting Information
|
Patient Information Maintenance - GP: MUST Epic updated |
E00195 - manage manual Patient Alerts for Electronic Patient Records (EPRs)As a Health or Care Professional I want to manually manage Patient Alerts for Electronic Patient Records (EPRs) So key characteristics relating to the Patient are indicated to Health or Care Professionals Acceptance criterion 1: create a manual Patient Alert for Electronic Patient Records (EPRs)Given the Health or Care ProfessionalĀ isĀ permitted to manage Patient Alerts for Electronic Patient Records (EPRs) When the Health or Care Professional selects to create a Patient Alert for a Patientās Electronic Patient Record (EPR) Then the Patient Alert is created Acceptance criterion 2: view manual Patient Alerts for Electronic Patient Records (EPRs)Given the Health or Care ProfessionalĀ isĀ permitted to view Electronic Patient Records (EPRs) When the Health or Care Professional selects to view a Patientās Electronic Patient Record (EPR) And a manual Patient Alert is recorded for that Patient's Electronic Patient Record (EPR) Then the Patient Alert is displayed Acceptance criterion 3: remove a manual Patient Alert for Electronic Patient Records (EPRs)Given the Health or Care Professional isĀ permitted to manage Patient Alerts for Electronic Patient Records (EPRs) When the Health or Care Professional selects to remove a Patient Alert from an Electronic Patient Record (EPR) Then the Patient Alert is removed E00195 - Supporting Information
|
Patient Information Maintenance - GP: MUST Epic updated |
E00196 - manage automatic Patient Alerts for Electronic Patient Records (EPRs)As a Health or Care Professional I want Patient Alerts to be automatically displayed for Electronic Patient Records (EPRs) So key characteristics relating to the Patient are indicated to Health or Care Professionals automatically Acceptance criterion 1: create automatic Patient Alerts for Electronic Patient Records (EPRs)Given the Health or Care Professional is permitted to manage automatic Patient Alerts for Electronic Patient Records (EPRs) When the Health or Care Professional selects to create an automatic Patient Alert for Electronic Patient Records (EPRs) Then they can specify the criteria for the Patient Alert to be displayed And the automatic Patient Alert is created Acceptance criterion 2:Ā view configuration for automatic Patient Alerts for Electronic Patient Records (EPRs)Given the Health or Care Professional is permitted to manage automatic Patient Alerts for Electronic Patient Records (EPRs) When the Health or Care Professional selects to view the configuration of an automatic Patient Alert for Electronic Patient Records (EPRs) Then the configuration for the automatic Patient Alert is displayed Acceptance criterion 3: amend automatic Patient Alerts for Electronic Patient Records (EPRs)Given the Health or Care Professional is permitted to manage automatic Patient Alerts for Electronic Patient Records (EPRs) When the Health or Care Professional selects to amend an automatic Patient Alert for Electronic Patient Records (EPRs) Then the automatic Patient Alert is amended Acceptance criterion 4: view automatic Patient Alerts for Patients for Electronic Patient Records (EPRs)Given there are automatic Patient Alerts created for Electronic Patient Records (EPRs) When the Health or Care Professional selects to view a Patientās Electronic Patient Record (EPR) And the criteria for an automatic Patient Alert is met Then the Patient Alert is displayed for that Patientās Electronic Patient Record (EPR) Acceptance criterion 5: delete automatic Patient Alerts for Electronic Patient Records (EPRs)Given the Health or Care Professional is permitted to manage automatic Patient Alerts for Electronic Patient Records (EPRs) When the Health or Care Professional selects to delete an automatic Patient Alert for Electronic Patient Records (EPRs) Then the automatic Patient Alert is deleted And is no longer displayed for Patients E00196 - Supporting Information
|
Patient Flags Service: new Standard added |
New Standard added, see Full Specification. |
Full Specification
The updated Patient Information Maintenance - GP Capability will be added at a later date. Proposed changes can be viewed in the Summary of Change above.
Patient Flags Service Standard
Assurance Approach
Suppliers will be assessed against Epic E00622 as per the Capability Assessment process and this will be a high level assessment based on the Acceptance Criteria defined.
Technical Assurance for Patient Flags Service - FHIR API will be driven through the established Digital Onboarding approach. The Patient Flags Service - FHIR API will be available to test in the INT path to live test environment to support testing the Patient Flags Service - FHIR API endpoints.
In addition, GP Practice systems suppliers would need to provide self-certification statements that they have ensured through their internal testing / assurance activities that the Reasonable Adjustments flag and supporting resources recorded for a patient in the GP Practice system is provisioned to recipient consuming systems through the Digital Services for Integrated Care (DSIC) interoperability standards such as GP2GP, SCR, IM1 and GP Connect and also that this data gets migrated in GP Practice migrations through the data extracts.
Additional clinical assurance will be required to mitigate any clinical risks associated with the implementation and clinical safety assurance process will have to be followed in addition to the above assurance for the clinical safety report and clinical hazard logs as per the DCB0129 standard.
The Authority will need confirmation from the Patient Flags team that the bulk upload of Reasonable Adjustments (RA) Patient Flags data has been completed.