Page Properties | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
|
...
There is no single Standard across all GP systems for extracting the Electronic Patient Record (EPR) for PFS. Interface Mechanism 1 (IM1) is the current option for providing PFS APIs from Foundation Solutions. IM1 PFS interfaces, created by the Foundation Suppliers, are based on high level functional specifications rather than technical Standards aligned to interoperability Standards. PFS Consumers cannot integrate in a standardised way with Foundation Suppliers so undertake a separate development with each Supplier. Consumers must apply significant development time and effort to integrate with each differing bespoke API, which introduces technical complexity and inconsistency and negatively impacts New Market Entrants (NMEs) and innovation.
Some existing requirements have been refined due to these changes, and to ensure consistency with the wider Capabilities & Standards model.
Outline Plan
A number of new GP Connect (Patient Facing) APIs are being developed:
...
Summary of Change
Provider Solutions
Patient Information Maintenance - GP: E00166, E00170, E00171, E00172 and |
---|
E00174 updated |
---|
E00166 - manage Citizen Service |
|
So that Patients have access to Citizen Services Acceptance criterion 1: enable Citizen Service |
|
When the Health or Care Professional selects to enable Citizen Service |
Then |
Acceptance criterion 2: disable Citizen Service |
|
When |
Then |
|
Info |
---|
E00166 - Supporting Information
|
E00170 - manage Prescription Ordering Citizen Service access for a Patient and the Practice
As a Health or Care Professional
I want to be able to manage Patient access to the Prescription Ordering Citizen Service
So that I can manage Patient access to Prescription Ordering Citizen Service for Repeat Medication
Acceptance criterion 1: enable Patient access to the Prescription Ordering Citizen Service
Given the Health or Care Professional is permitted to configure access to Citizen Services
When they the Health or Care Professional selects to enable the Patient’s access to the Prescription Ordering Citizen Service
Then access to the Prescription Ordering Citizen Service is enabled for the Patient
Acceptance criterion 2: disable Patient access to the Prescription Ordering Citizen Service
Given the Health or Care Professional is permitted to configure access to Citizen Services
When they the Health or Care Professional selects to disable the Patient’s access to Prescription Ordering
Then access to the Prescription Ordering Citizen Service is disabled for the Patient
Acceptance criterion 3: enable Prescription Ordering Citizen Service for the Practice
Given the Health or Care Professional is permitted to enable a Citizen Service for the Practice
When they the Health or Care Professional selects to enable the Prescription Ordering Citizen Service for the Practice
Then the Prescription Ordering Citizen service is enabled for the Practice
Acceptance criterion 4: disable Prescription Ordering Citizen Service for the Practice
Given the Health or Care Professional is permitted to disable a Citizen Service for the Practice
When they the Health or Care Professional selects to disable the Prescription Ordering Citizen Service for the Practice
Then the Prescription Ordering Citizen Service is disabled for the Practice
E00170 - Additional Implementation Details
Solutions MUST comply with the following when implementing this Epic:
Suppliers of new services or Solutions:
GP Connect (Patient Facing) Prescriptions API (Provider requirements)
Suppliers of services or Solutions which ARE currently deployed into an operational environment:
IM1 - Interface MechanismStandard (Patient interface Provider requirements)
Info |
---|
E00170 - Supporting Information
|
E00171 - manage View Record Citizen Service
|
Info |
---|
E00171 - Supporting Information
|
E00172 - manage View Record Citizen Service
|
E00172 - Additional Implementation Details
Solutions MUST comply with the following when implementing this Epic:
Acceptance criterion 9: enable Prospective Access to the Full Record Access Level for a Patient |
Given the Health or Care Professional is permitted to configure access to Citizen Services When the Health or Care Professional selects to enable Prospective Access to the Full Record Access Level for |
Suppliers of new services or Solutions:
GP Connect (Patient Facing) Access Record API (Provider requirements)
Suppliers of services or Solutions which ARE currently deployed into an operational environment:
IM1 - Interface MechanismStandard (Patient interface Provider requirements)E00172 - Supporting Information
The start date determines the date from which the data made available goes back to, not whether the Service is offered/available by the Practice e.g. where the Full Record Access start date is set to 15th March 2015 and the Full Record Access is enabled (‘switched on’) by the Practice on the 1st April 2015a Patient Then the Health or Care Professional records a start date for data to be available from And the Prospective Access to the Full Record Access Level is enabled for the Patient Acceptance criterion 10: disable Prospective Access to the Full Record Access Level for a PatientGiven the Health or Care Professional is permitted to configure access to Citizen Services When the Health or Care Professional selects to disable Prospective Access to the Full Record Access Level for a Patient Then the Prospective Access to the Full Record Access Level is disabled for the Patient E00172 - Additional Implementation DetailsSolutions MUST comply with the following when implementing this Epic:
E00174 - configure access to elements of the Electronic Patient Record (EPR) in the View Record Citizen ServiceAs a Health or Care Professional I want to record that elements of the Electronic Patient Record (EPR) are Restricted from View Record So that elements recorded as Restricted from View Record are not displayed to Citizens via the View Record Citizen Service Acceptance criterion 1: record existing elements of the Electronic Patient Record (EPR) as Restricted from View Record Citizen Service upon reviewGiven the Health or Care Professional is permitted to review the Electronic Patient Record (EPR) When Then this element is recorded as Restricted from View Record And it is not displayed in Citizen Services Acceptance criterion 2: record elements of the Electronic Patient Record (EPR) as Restricted from View Record Citizen Service whilst entering informationGiven the Health or Care Professional is permitted to enter information into the Electronic Patient Record (EPR) When And the Health or Care Professional selects to record an element of this information as Restricted from View Record Then this element is recorded as Restricted from View Record And it is not displayed via the View Record Citizen Service Acceptance criterion 3: indicate Restricted from View Record elements to Health or Care ProfessionalsGiven the Health or Care Professional is permitted to view the Electronic Patient Record (EPR) And there are elements of the Electronic Patient Record (EPR) that have been recorded as Restricted from View Record When the Health or Care Professional selects to view the Electronic Patient Record (EPR) Then the Health or Care Professional can view that these elements are Restricted from View Record Acceptance criterion 4: update elements recorded as Restricted from View Record as available for View RecordGiven the Health or Care Professional is permitted to view the Electronic Patient Record (EPR) And there are elements of the Electronic Patient Record (EPR) that have been recorded as Restricted from View Record When the Health or Care Professional selects to record an element as available for View Record Then this element is recorded as available for the View Record Citizen Service And it is displayed via the View Record Citizen Service E00174 - Additional Implementation DetailsSolutions MUST comply with the following when implementing this Epic:
|
Interoperability Standard: Capability-independent interoperability Standards section updated |
---|
IM1 - Interface MechanismIM1 - Interface Mechanism is a mechanism for accessing data held in GP Systems (Systems providing one or more Capabilities as part of the GP IT Futures Contracting Vehicle. The interface mechanism facilitates three use-cases (Patient, Bulk and Practice) which are detailed within the IM1 page. A system or application is required to provide IM1 interfaces if
Where a GP Connect interface capability is available, Provider Suppliers would be expected to develop against that, rather than developing a new bespoke or proprietary interface. A system or application may wish to consume IM1 interfaces where they have a requirement to access data held in GP Systems and the Provider Solution does not offer a GP Connect interface. |
...