Below is the roadmap for June 2018 to March 2019 updated November 2018. (Click to see the original version). As usual, we adjusted priorities in response to the feedback of early adopter customers and we dug deeper into the details of each feature.
Features released or in progress
We are continuing our focus on speed of page loading times. The more quickly PKB can show information to the user, the more often users choose to access the information which makes the patient's care more accurate and safe. You can monitor current page load speed on pkbstatus.com. Our approach is to optimise the whole platform that affects every single page rather than making changes to individual pages.
In May 2018 we switched to AES encryption with a faster algorithm for storing and retrieving data: showing 5,000 test results used to take 5,000 1 ms decryption transactions, now it takes just one such 1 ms transaction.
Through September and October 2018 we optimised the way that our database stores and returns clinical data. This has resulted in further improvements in data retrieval times across all pages but particularly those with large numbers of data points such as measurements and tests.
In September 2018 we optimised our HL7 QRY A19 in response to issues encountered by customers. Previously the query was timing out when very large numbers of patients were returned (hundreds of thousands). The query now copes with this.
Mass registration and e-documents
PKB provides APIs for mass registration of patients using letters to each patient’s home and kiosks in outpatient clinics.
In November we released a FHIR compliant REST API for read receipts to allow senders of electronic documents to check whether the document has been opened by the patient. Providers can therefore be sure that the patient has seen the appointment (something not possible with the paper appointment letters PKB replaces).
We will switch on email reminders for appointments at 2 days and 2 weeks before each appointment to reduce the number of patients who do miss their appointments.
The timeline view on the home page of a patient's record will combine data from multiple other pages all plotted against a horizontal x-axis. We will start with the professional's view of the patient's record and eventually add to the patient's view.
At the moment the discussions view shows past interactions with the health care systems, including secure messaging, clinic visits and hospital admissions. The calendar view shows appointments, defaulting to future ones and needing scrolling for past ones. Furthermore professionals and patients alike want to see their encounters and appointments alongside medical data such as symptoms, measurements, test results and care plans.
The timeline view will do this, giving a fast overview with click-throughs to details.
We rolled out a new patient banner on all pages to improve the professional's view of the patient's demographics as well as a summary of the privacy labels the patient is sharing with the professional.
The timeline view will be released in phases in December 2018 and January 2019.
FHIR REST API
The current REST API uses PKB's proprietary syntax. As part of the timeline and Single Page Application web user interface upgrades we will improve the REST APIs for accessing most data points in PKB. During the rewrite of the internal code, we will update the syntax to match FHIR standards wherever they are available.
We have released several resources to production including Patient, Practitioner, Consent, Organization, DocumentReference. The new patient banner and timeline view are retrieving data using the FHIR REST API. The initial focus has been on releasing the resources required to support the UI but we will cover all data types in PKB. Progress can be followed here.
REST API for single sign-on uplift
This allows users of other systems (e.g. electronic health records) to sign into PKB without needing PKB credentials. A number of customers already use this. Our focus is on making integration faster and easier for third-party vendors to make SSO available to their users.
We have streamlined our single sign on flow and fixed issues with single sign on which were affecting professionals who moved teams after initially pairing. Customers are able to single sign on to the PKB patient record from several systems including Cerner, RiO and Lorenzo.
EMIS direct integration performance improvement
As we are processing increasing volumes of GP EMIS data every night we will optimise the performance of the import process. This allows entire CCGs to send all their GPs' data in a big bang approach while minimising the time for new data to appear in the PKB record.
Over the past 6 months we have optimized the import process to allow us to grow from 3 practices live at the start of the year to over 20 now and over 100 in the next few months; from retrieving data from one EMIS sftp server to retrieving data from all six servers.
Mobile-optimized web UI
Starting with the timeline view, we are migrating our front-end code to Single Page Application (SPA) a more modern set of web technologies that allow faster development. It also makes the front-end faster because only parts of a page load in response to the user's clicks, rather than loading a new page with each click. Ultimately, SPA allows offline usage and quick creation of hybrid smartphone app versions, i.e. app store apps that use the web GUI source code.
PKB already works well on different screen sizes, adjusting the display from smartphones to tablets to large desktops. We are further optimising key screens for mobile usage.
FHIR compliant API for appointments
Add new appointments selecting participants to include and view appointment details
FHIR compliant API for lab tests
Ability to view results in summary view (all tests)
Ability to drill down to selected results
Ability to add test results via manual entry incl. photo / doc attachment capture
FHIR-compliant API for radiology
Ability to view and add radiology reports
FHIR-compliant API for symptoms
Add symptoms requested by clinical team
View symptom history
Select and add from complete set of symptoms
Features moved to January to June 2019 roadmap
Development on these features will continue into 2019.
We will expand the current care planning functionality to fully support the PRSB's national digital care and support plan standard. Care and support planning is a defined process which helps people set their own aims and objectives. It helps to identify their strengths and assets, and the support that they need to achieve them. The care and support plan should demonstrate how the person’s aims and goals will be met.
The lead providers to co-develop this standard were North West London's CCGs, who also use PKB for their Care Information Exchange, an integrated digital care record and patient portal. In liaison with the Care Information Exchange team we have produced our designs for the next iteration of our care plan functionality which complies with PRSB standards and beyond that supports the rich functionality our customers are asking for. If you would like to take part in the design and early roll out of the new functionality, please contact us.
The PRSB's standard identifies the "Care and support plan" as a new and critical part of the IDCR, along with the "About me" section and the "Contingency plan(s)" sections.
PKB's existing disease-specific care plan functionality will fit into the contingency plans section, with PKB's green, amber and red framework instructing patient and professionals what to do in different situations. PKB will add the holistic care and support plan section with structured workfow for tracking goals, tasks and contacts.
EMIS direct integration additional data
From Q1 2019 we will add support for:
consultations metadata (EMIS does not provide free text data)
PKB is integrating the major appointment booking systems: the "Book appointment" button will appear on the appointments page. By default, this will allow the patient to manually request an appointment from a team by listing three slots that the patient is available in for the team to consider. The team can manually book the appointment using their local booking system. The team can either manually add the appointment to the patient's record through the PKB web user interface, or automatically add it through the HL7 API with an integration.
If any of the teams is in a GP practice with GPSoC APIs switched on, PKB will show the available appointment slots from the GP's system and allow the patient to book the appointment. PKB will add the appointment to the patient's record and the GP's system, again using the GPSoC APIs.
Here are the proof-of-concept videos for integration with DrDoctor and SwiftQueue:
Features deferred for now
We have adjusted our priorities based on feedback from customers and the following items won't be worked on before end-March 2019. If these, or other features, are a priority for you please let us know.
We have a prototype 2-factor authentication in place which has completed testing with with PKB employees. However our customers have informed us that their priority is to get their professionals viewing the PKB record via single sign on from their organisation EHRs.
This remains an important feature for professionals not using single sign on and for patients and we will pick it up again in the future.
Cross-Enterprise Document Sharing (XDS)
We are hearing from customers that a bi-directional FHIR compliant REST API with support for a messaging paradigm is a more immediate priority for them e.g. this may be the approach for One London. We will be focussing on this approach first. Architectural discussions are ongoing (see here for more detail). There is, of course, much overlap with the XDS standards-based specification for managing the sharing of documents between healthcare providers and PKB will offer this in the future as below.
The first step will be to make data from PKB available to others through the MHD profile. PKB will respond to ITI-78 compliant calls for patient record discovery. PKB will also respond to ITI-67 Find Document References and ITI-68 Retrieve Document compliant calls. Authentication will be handled via OAuth2. The MHD profile means using FHIR APIs, and PKB has already started making these available and will complete the work for these data points:
After this, PKB will support displaying data from other health care providers in the PKB GUI. This allows PKB to fit into health care economies like the Dutch government's 2020 XDS plans.