[DRAFT] GP Connect (Patient Facing) User Management

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.

How to get a patient's permissions

There are two main use cases fulfilled by being able to retrieve the patient's permissions. The information available from the GET request on the permissions API can be used to:

  1. build a UI so only the elements the patient has access to are available
  2. present permissions to the patient so they can see what they do and do not have access to

Prerequisites

Consumer

The consumer must make a request to get a patient's permissions prior to making any other PFS API requests. This ensures that the patient has online access enabled, see New online patient access for additional details.

Supplier

The supplier must ensure the patient has online access enabled. This is performed during the authorisation process of the patient's request by the GP supplier system. See New online patient access for additional details.

Use case 1 - Build a UI

In the case of using the information about a patient's permissions to build a UI this will require the consuming application to understand what the different levels of access represent. To that end, the following image illustrates what information is available at the different levels for the medical record.

permission-levels-medical-record

The same information from the image in table format:

Level Information available
None No access
Summary Demographics, Medications, Allergies
Detailed Everything from Summary + All read/clinical codes, Immunistations, Health conditions, Test results, Consultations, Referrals
Documents Everything from Detailed + Documents
Full Everything from Documents + Free text

For the appointments and prescriptions services the information/features available at the different levels are illustrated below.

permission-levels-services

The same information from the image in table format, split into appointments and prescriptions:

Appointments

Service Level Information available
Appointments None No access
Appointments View View appointments
Appointments Manage Everything from View + Book and cancel appointments

Prescriptions

Service Level Information available
Prescriptions None No access
Prescriptions View. View appointments
Prescriptions Manage Everything from View + Request and cancel prescriptions

The consuming application should use this information to provider the best experience to the patient i.e. only display features and functionality within the UI that the patient has access to.

It might be useful to show the patient that there are additional features and functionality they could access but do not current have permission to do so. For example, the application might render sections of the medical record the patient could have access to but do not currently. This could be represented by displaying the sections but making them appear unavailable, potentially with a message informing the patient that they could request access to that area and directing them to the area of the application where they could make that request.

Use case 2 - Present permissions to patient

In the previous section the ability to convey what the patient has and has not got access to was mentioned. Using the information from the API it is possible to present the information to the patient rather than have the application convey the levels of access.

In order to do this in a way such that the levels of access make sense to patient the application would need to find a way to explain what the different permission levels represent and what each level provides access to. Ideally this would be done with a focus on the outcome the patient could expect e.g. if the patient wanted to see their test results they would need to have Detailed (coded record) access.

This is a challenging problem for consuming applications to solve and should ideally be done by learning about their patients, working out how best to express the ideas of permissions, access and how patients are able to best achieve their objectives.

Following on from the presentation of permission information to the patient is the ability to allow the patient to request changes to the permissions they have. See How to request a change to a patient's permissions for additional information.

back to top