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:
- Build a UI so only the elements the patient has access to are available.
- 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.
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.
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.