PKB is committed to implement full FHIR support. The support for all FHIR data points means third party developers can easily integrate with PKB to support a health economy’s full needs.

Current state of PKB APIs

We created PKB to allow the patient’s data to move from wherever it is to wherever it is needed whenever the patient wants it. Open, read-write APIs are a key part of this and PKB has provided these since 2012. This avoids lock-in for customers, improves innovation for patients. For example, in the Netherlands, RadboudUMC created CMyLife, a blood cancer management app. CMyLife tracks a patient’s biometrics, symptoms and medication usage using PKB’s APIs. It then titrates chemotherapy schedules to minimise side effects and thus increase medication usage to maximise the patient’s chances of beating their cancer. The app is now the standard for chronic myeloid leukaemia in the Netherlands.

PKB started providing access to some of the data through FHIR APIs since 2018.

PKB’s FHIR strategy

PKB is committed to implement support for both FHIR STU3 and R4. This is because while some customers in England and the Netherlands are still on STU3, most app developers prefer R4 and the US government has mandated FHIR 4. Our intention is that each customer can send data in the FHIR version they like.

PKB will support this by separating transmission and storage of data from processing and aggregation. Each customer integration will write to an isolated FHIR storage in PKB. 

This strategy eases integration, as customers with an existing body of data in FHIR format can replicate that into PKB without filtering or transforming it. Then PKB will aggregate that data into a view of the patient’s whole record — this will also be exposed as a read-only FHIR API. This aggregation process will be developed iteratively, focusing initially on conditions, medications and appointments. PKB’s own user interface will also be driven from this aggregate view.

PKB’s existing dataset will be migrated into FHIR storage and included in the aggregation process during this development.

Schedule

API availability is determined by customers’ abilities – as usual, we prioritise releasing the most data to the most patients. We are starting with FHIR STU3, prioritising the data sets from London’s Discovery Data Service as this will provide the GP records to patients treated in London. We are also scaling up early implementations of the questionnaires API used by Nottinghamshire’s GPs to remotely treat patients.

Patient: released

We released the Patient resource for FHIR STU3 on 09/2021. This allows organisations to send demographics data, including email addresses. When PKB receives the email address for a patient it sends an email message inviting the patient to register. This is a fast way to register patients using email addresses from NHS England’s Spine for example.

Conditions, medications and appointments: developing now

We are now working on the conditions, medications and appointments data that comes from GP systems. This is the first complex migration of clinical data so it will be the migration that uncovers the technical risks for other datasets. After this migration we will be able to provide further details about the migration for other APIs.

Questionnaires: released, expanding now

In 2020 PKB made questionnaire responses available for APIs. Nottinghamshire’s GPs, for example, pull the answers automatically to store them in SystmOne for local audit trails alongside PKB’s centralised audit trail.

We are now working on a FHIR API for the questionnaire itself. The API allows an organisation to tell PKB to send out a questionnaire to a patient. This is great for Patient-Initiated Follow-Up (PIFU). Sending out questionnaires for a patient to answer before an appointment allows identifying unnecessary appointments, and preparing better for necessary appointments. Sending out questionnaires after an appointment allows identifying patients who do need a follow-up and freeing up slots from those who do not.

Ultimately, PKB will support the following functionality in questionnaires:

1. Calculations: formulae that use the answers of different parts of the questionnaire to show a score.
2. Charting: showing different answers to the same questions over time in a patient’s record.
3. Analytics: showing patterns in the answers of all patients to the same questions.

Features that are not on our roadmap yet:

4. Scheduling: other systems have the information that triggers the schedule. For example the appointment booking system that knows the date of the appointment and the preferences of the team booking the appointment.
5. Decisions: interpreting and acting on the answers and scores of the patient is complex and specialised. Each pathway will have different rules for a small number of patients. Over time, new systems are evolving to manage these pathways. These had been limited in the past by the difficulty and expense of aggregating data and engaging patients, which PKB now takes care of.

APIs for new data types

Health economies can use PKB as an integration engine for data sets that are not yet displayed on PKB’s UI as we are implementing the aggregation layers for these data types. These will include safeguarding data, social history, family history and insurance claims.

Next steps

By the end of 2021 we will provide further details about how we are extending our FHIR support. In the meantime, if you have any projects that would benefit from FHIR API integration, do let your PKB success team project manager know, or contact us on the web.