Welcome to October’s instalment of our development blog.
FHIR API: Reaching a major milestone with appointments
FHIR is the global industry standard for passing healthcare data between systems. In November, we will have end-to-end support for appointments on our production server.
Each customer can already write clinical data in either STU3 or R4 versions of FHIR. To begin with, each customer could only read data they had stored in PKB. We are now combining data from different sources and via different formats to create an aggregated record for each patient. This is a complex task so we are doing it iteratively, one data set at a time, starting with appointments.
We migrated existing appointments to a FHIR store, and then implemented an aggregation process that combines new appointments from all sources into a single cohesive record. We are currently integrating a read-only FHIR endpoint and linking our web application to this aggregated record so that customers can retrieve appointments automatically or see them in their patients’ records. The appointments will be available with our regular features, for example privacy labels.
The end-to-end support for appointments is a significant milestone. We fully expected that migrating and aggregating the first data set would be both challenging and educational. We will apply what we’ve learned and work on other data sets in parallel, starting with conditions and medications.
You can read more about our FHIR development work on our product strategy webpage or our FHIR roadmap blog post.
Upcoming changes to carer invitations
Carers will not be able to add other carers to a patient’s record. Only patients, professionals and coordinators will be able to do so. This is to ensure that the clinical team can follow relevant safeguarding procedures for patients who lack capacity.
This change followed feedback from teams in which carers are an important part of the delivery of care, including sessions with paediatric and mental health teams.This is just one example of our safeguarding features, many of which currently apply to paediatric patient records and are being extended to all patient records, such as the expansion of the ‘Freeze record’ feature that we announced in our September development update.
HL7 API: Accepting medications with the same start date
Organisations will be able to send repeated medicines in an HL7 message that have the same start date but different end dates. We will no longer reject HL7 messages if they contain two medicines with the same medication substance and start date, but will instead only reject HL7 messages that have the same medication substance, start date and end date.
This change will allow Trusts to send medicines via HL7 for patients with more complex medication records. For example, where a patient is changing their dosage gradually under supervision.
