Introduction
GP Connect's vision is to accelerate and extend data access to patients in an efficient way. Part of that accelerating work is patient-facing services (PFS), which enable seamless access of data for patients from Foundation System (FS) suppliers.
The overall design of PFS is based on the Access Record: Structured (ASR) API, implemented by existing and new market entrant (NME) Foundation System suppliers. Access to the new consumer PFS APIs would be managed through NHSD API Management Apigee gateway.
Access Record: Structured | Patient Facing Services
The Access Record: Structured Patient Facing Services (PFS) View Record capability enables PFS app suppliers to request and consume a patient’s GP record in a structured and coded format that is machine-readable. The data will be returned as per the patient’s GP record access levels set by their GP practice in their clinical system.
The data will be made available via a standard API. Structured data allows the PFS apps to import and process the patient data in whatever way it requires to best support the patient's viewing their data on the PFS apps.
Additional undertaking is made by GP Connect clinicians and technical modellers to advise on what is safe and useful to display for viewing by patients and citizens. This includes a breakdown of the relevant FHIR profiles and examination of each element with a safety rating and recommendation. You can find more information in PFS profiles.
Scope
The Access Record: Structured capability will expose data for a number of clinical areas. Currently supported medical record data items are:
- Allergies - are observations. They contain medical record data item properties.
- Medications - contain data about drugs prescribed to the patient.
- Immunisations - are observations. They contain medical record data item properties.
- Consultations - are patient’s interactions with the practice. A consultation may have a list of observations that were recorded during the consultation.
- Problems - contain data about medical problems.
- Investigations - are test results. Investigations can be, for example, height or weight, or a composite, like full blood count.
- Outbound referrals - are typically defined as a request for transfer of care or request to provide assessment, treatment or clinical advice on the care of a patient.
- Documents - are electronic records that provide evidence of medical care.
- Uncategorised data - is not a clinical area in its own right, it represents the remainder of the clinical record which is not covered by the other clinical areas. It should not be used as a clinical area in itself. It covers several clinical concepts such as procedures, family history, measurements and many more. They are not fully standardised as clinical areas in the source system.
The following profiles are not to be made available to consumers:
Diary entries are not considered clinically safe to share with patients/citizens via PFS. Diary entries imply that a clinical action ought to be taken in the future - it does not mean it will be or has been. Additionally, if they get marked as complete, it does not necessarily mean that the action was taken. It means that the need to do the item gets ticked off (not that it was done). The ambiguity around diary entries is considered a high risk and should not be shown via PFS.
Draft consultations are not considered clinically safe to share with patients/citizens via PFS. They are intended just as drafts - not all of the information captured is ready to be shared. This stays in the GP system and should not be outputted to the API endpoints.
Unfiled test results are not considered clinically safe to share with patients/citizens via PFS. Only filed test results should be returned - not all of the information captured is ready to be shared. This stays in the GP system and should not be outputted to the API endpoints.
Example scenarios
- A patient with multiple long-term conditions views their repeat medications list to be up to date about all the medications they take. They want to view their test results for their conditions as they undergo regular tests.
- Patients who have had multiple hospital admissions would like to view their documents and letters.
- Senior citizens want to view what was discussed in their consultation as they want to refer to what was discussed.
Getting started
Before starting development, read the following specifications and complete the prerequisite listed below.
Specifications
read about the directory of GP Connect specifications and associated artefacts
read the specification that outlines the data model used within GP Connect; the GP Connect Data Model | FHIR STU3 Representation also contains guidelines on how to populate each of the FHIR resources
Prerequisite
- providers must implement the GP Connect API 1.5.1-beta specification
Explore
try out the GP Connect Demonstrator system
optionally download the GP Connect Demonstrator Codebase to see how it works
download our PostMan collection and explore the GP Connect interactions