PDS FHIR API technical conformance: restricted access mode

As part of the onboarding process for the PDS FHIR API, you need to show that your software meets our requirements.

This API has two access modes, each with different authentication methods and functionality. The access mode your software product uses affects which criteria you need to meet.

The access modes are:

• restricted access mode
• healthcare worker access mode

This page explains the technical requirements for restricted access mode.

During onboarding, you need to tell us:

• what the care setting is for your product
• what your product does and how it does it
• what information your product gets from PDS
• what your product does with that information
• what API endpoints your product uses

Care settings

Find out about care settings in the context of the NHS healthcare ecosystem.

Use cases of PDS FHIR API

Find out about use cases.

Use cases for PDS in restricted access mode include:

• searching for a single patient using search criteria to trace a patient in PDS (unique matches only)
• getting a single patient's details based on their NHS number

Use cases that are not supported in restricted access mode include:

• searching for multiple patient results
• updating patient details

Find out about end users in the context of the NHS healthcare ecosystem.

For restricted access mode, you will not have an end user present at all if it is a simple use case, such as an application looking up a single patient's details based on an NHS number. 

Requirements

If there is an end user, you must ensure they are suitably authorised and authenticated locally to view demographic data, typically using Role Based Access Controls (RBAC).

Find out about using local patient databases (or indexes).

Requirements

Keep the local patient database up to date

If you get patient data from PDS and store it locally, you must keep it up to date. This is important for data quality and to protect sensitive patients. If a patient is classified as sensitive, it's important not to share location details from PDS before they were sensitive. 

Sync any local copy of a patient record with PDS after significant events

You must sync any local copy of a patient record with PDS after any of the following significant events. 

1. The start of an episode

Including: 

• registering or reception at a GP surgery 
• reception at an outpatient clinic 
• the beginning of any episode of unscheduled care where patient identity is known 
• referral for assessment in Social Care where consent to access NHS data has been given 

2. Before using patient communication information

Including:

• using locally-stored patient telephone numbers or addresses 
• sending correspondence to a patient 

3. Before inpatient admission and discharge

Including: 

• the generation of messages containing new or changed demographics to downstream, local systems 
• updating any information for the patient on Spine, including any update of PDS itself 

4. Before getting any clinical or medication information stored on external Spine services

Including e-RS, SCR, GP2GP and EPS. This can exclude retrievals of clinical data during an episode of inpatient care.

Continue to provide care if syncing fails

When syncing fails at one of these key events, local systems must continue to be able to provide care for a patient. 

Warn the end user of key field changes

When there is an interactive user, in addition to the use of the version ID or manual comparison of fields, if the local system detects that changes have happened to the key fields on PDS (for example, death notification status has been set or gender changed), the user must be informed. 

Allow the end user to check key field changes

Interactive users must be given the chance to check and reject a change in the key fields (death notification status and gender) when synced with PDS. 

Accept key field changes if no end user is present

Where there is no interactive user, or when the interactive user has read-only access to the system and the records have previously been synced, the system must accept updates to key fields from PDS. 

Find out about sensitive patients, sometimes called restricted patients.

Requirements

Do not display sensitive patient flags

If a sensitive flagged record is returned in a trace, the flag must not be displayed to the user on a search results screen.

Do not display sensitive patient addresses, telecoms, related persons, GP practice or pharmacy data

If a patient is classified as sensitive, do not share location details you might have got from PDS and cached locally before they became sensitive. So, if a sensitive patient record is returned from PDS, the local system must not show: 

• patient addresses 

• telecoms information 

• related persons

• GP practice or pharmacy data 

Find out about superseded patient records.

Requirements

Warn the end user of a superseded patient record

When there is an interactive user and they get a superseded patient's details from PDS, the local system must warn the user that the local record is wrongly identified. 

The warning must tell the user that the NHS number has been replaced and that the patient should be told

The warning message shown by the local system must tell the user that the: 

• NHS number being used has been replaced 

• patient should be told of the replacement NHS number

Replace the NHS number for a superseded patient record

When the local database gets a superseded record code and the new NHS number is not present on another record in the local database, the old NHS number must be replaced with the new NHS number.

Refer superseded record confusion cases to local back office

When the local database gets a superseded record code and the new NHS number is present on another record in the local database, then the superseded record must continue to be used for the purposes of this episode of care and the local back office must be told. 

Find out about invalidated patient records.

Requirements

Warn the end user of an invalidated patient record

When there is an interactive user and they get an invalid NHS number code from PDS, the local system must warn users accessing the patient’s record that the local record is wrongly identified.

The warning must tell the user that the NHS number is no longer valid

The warning message shown by the local system must tell the user that: 

• the NHS number is no longer valid 

• the record is being referred to the local back office for processing 

• all demographic and clinical information for this patient should be treated with caution until the processing is complete 

Continue to give the required warnings to the end user

The local system must mark the record so that every time it is accessed all users are made aware that: 

• there are data anomalies on the record which could constitute a clinical risk 
• the anomalies might be related to the clinical as well as the demographic record 

De-couple an invalidated patient record from PDS

When the local system gets an invalid NHS number code, the wrongly identified local record must be de-coupled from PDS. 

De-coupling stops the local record from further syncing until it has been re-coupled and the version ID reset to zero. It should also trigger a task for the local back office to fix the local record so it can be found on PDS. 

Find out about contact details data quality.

You'll need to agree to these terms of service in order to use the PDS FHIR API, as part of our digital onboarding process.

To get started, send us an email at [email protected].