Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

ID

RM204

Version

1.0.0

Type

Roadmap Item

Frameworks

Title

GP Connect (Patient Facing) APIs Change 1 - Prescriptions FHIR API

Description

Requirements relating to the new GP Connect (Patient Facing) Prescriptions - FHIR API

Date Added

Standards and Capabilities

Patient Information Maintenance - GP, Prescription Ordering - Citizen, IM1 - Interface Mechanism, Interoperability Standard

Change Route

TBC

Change Type

New

Status

Draft

Publication Date

TBC

Effective Date

TBC

Incentives / Funding

TBC

Incentive / Funding Dates

TBC

Background

Patient Facing Services (PFS) ensure that Citizens (Patients and their Proxies) have the tools to access information and services digitally, so they can more actively participate in managing their own health and care. GP Connect PFS APIs allow all Patients and their Proxies to view a Patient’s detailed Electronic Patient Record (EPR), order their repeat Prescriptions, and book/manage their health and care Appointments.  

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.

Current infrastructure is not aligned with latest FHIR Standards and there are multiple APIs (from NHS Digital which Suppliers need to update and develop), which cause development backlogs with Suppliers. If the GP Connect PFS APIs follow the current design for the STU3 Access Recorded Structured API, the Supplier application tier will need to perform more complex transformation on data from the API to prepare it for mobile app consumption. This additional complexity makes it harder for Suppliers to deliver Solutions and introduces more areas where errors can result in data loss.

However, if the GP Connect PFS APIs are designed to better support usage in mobile apps, following REST API design pattern for example, the Supplier will be able to pass through requests and responses without change to the mobile app. This approach minimises unnecessary complexity for the Supplier Solution, reduces scope for error, and is overall simpler and quicker to deliver. Therefore, this is the direction Suppliers are being asked to take.

GP Connect PFS APIs will align with the NHS Digital Technical API strategy and provide the NHS and Suppliers with a ubiquitous interoperability Standard that meets the future record sharing needs of all stakeholders. By introducing interoperability Standards, we can drive the interoperability market forward by reducing the number of options that Suppliers need to take through NHS Digital product assurance. It will increase innovation and reduce the burden on Suppliers to develop with a burgeoning market.

For the Patient, it will give them real-time access to their record, enabling them to manage their own care more easily through an enhanced offering of Patient Facing Apps enabled by GP Connect PFS APIs for viewing their Electronic Patient Record (EPR), ordering Prescriptions, and managing Appointments.

Outline Plan

A number of new GP Connect PFS APIs are being developed:

  • Prescriptions Management

  • User Management

  • Get Record

Based on current GP Connect PFS API specifications, Prescription Management is the specification that meets the latest requirement and Standard. This is therefore the API that Suppliers are being asked to develop first.

The other GP Connect PFS API specifications will continue to be uplifted so that they all adhere to the future specifications that are deemed appropriate and fit for purpose. The requirements for these APIs will be added via separate Roadmap Items, to be delivered by Suppliers at a later date.

This Roadmap Item will establish that:

  • Incumbent Provider Solutions MUST deliver GP Connect (Patient Facing) Prescriptions - FHIR API and continue to support IM1 (Patient Interface)

  • Incumbent Consumer Solutions may deliver either IM1 or GP Connect (Patient Facing) Prescriptions - FHIR API, this will be driven by what is supported by the Provider Solution

  • NME Consumer Solutions MUST only deliver GP Connect (Patient Facing) Prescriptions - FHIR API

Summary of Change

Full Specification

The updated Patient Information Maintenance - GP, Prescription Ordering - Citizen, GP Connect (Patient Facing APIs) Prescriptions Standard, IM1 - Interface Mechanism and Interoperability Standard will be added at a later date. Proposed changes can be viewed in the Summary of Change above.

Assurance Approach

The Assurance Approach for Providers and Consumers will be provided at a later date.

  • No labels