Below is the draft roadmap for June 2018 to December 2018. (Click to see the September 2017 to March 2018 roadmap.)
As usual, final delivery timelines will change in response to the feedback of early adopter customers and as our developers dig deeper into the details of each feature. We will post updates on the feature category of the PKB blog.
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. 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.
Our approach is to optimise the whole platform that affects every single page rather than making changes to individual pages.
PKB provides APIs for mass registration of patients using letters to each patient’s home and kiosks in outpatient clinics.
Next we will complete the APIs for read receipts so that providers can be sure that the patient has seen the appointment (something not possible with the paper appointment letters PKB replaces). We will also 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.
After that we will improve the user interface for coordinators and professionals to know which patients have yet to register. The user interface should make it easier to prompt these patients to register but ultimately our plan is to automate the prompting and reminders.
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. If you would like to take part in the design 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.
We have completed testing with 2-factor authentication with PKB employees. Professionals will have this next for added security.
Eventually we will provide the option for patients who can choose to switch on the added security without affecting usability for most patients. We already have this working for internal staff at PKB as we test for usability.
To switch on the functionality the user needs to download the Google Authenticator smartphone app for their iOS or Android device.
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.
HL7 API uplift
Our HL7 API allows customers to send large amounts of data into PKB from their institutional electronic health records systems. Our focus is on making the existing APIs complete and easy to use. We will
Fill in gaps in core functionality e.g. deletions flow
Document API and PKB data model
Comply with standards e.g. code sets
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.
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.
EMIS direct integration additional data
In December 2018 PKB will support:
consultations metadata (EMIS does not provide free text data)
Test results support will arrive in March 2019.
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.
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.
Here are the proof-of-concept videos for integration with DrDoctor and SwiftQueue:
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.
For prescription renewal, a "Renew prescription" button will appear for any patients linked to a GP practice with GPSoC APIs switched on. Clicking the button will allow the patient to request the renewal which PKB will communicate using the GPSoC APIs.
Cross-Enterprise Document Sharing (XDS)
PKB will support the XDS standards-based specification for managing the sharing of documents between healthcare providers.
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 London's Healthy London Partnership (HLP) and the Dutch government's 2020 XDS plans.
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. Below is our sequence of further optimising screens for mobile usage.
Ability to view appointment details
Ability to add appointments selecting participants to include
Earlier versions will focus on the patient seeing their results
FHIR compliant API for lab tests
Ability to view results in summary view (all tests)
Ability to drill down to selected results
Caching for offline viewing
Later versions allow adding 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
Caching for offline viewing
FHIR-compliant API for symptoms
Add symptoms requested by clinical team
View symptom history
Select and add from complete set of symptoms