Roadmap 2017/09

Roadmap‎ > ‎

Below is the roadmap for September 2017 to March 2018. (Click to see the March-August 2017 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.

For questions about any of the features below please contact us. The PKB blog has archives of past roadmap postings. And if you are a developer, we're hiring!

Performance

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.

Usability

In the past we built features iteratively to support different customers' go-live schedules. We tended to implement just enough of each feature to get a customer live. Our focus for now is on applying features completely and consistently.

Privacy labels

Privacy labels allow data to be hidden from users based on the permissions each user has received from the patient. We have now tested the four privacy labels (general, mental, sexual and social care) across different clinical situations. We know the model addresses the different needs of different individuals across a population. So we will now:

Apply display and editing of the labels to cover every data type with a consistent user interface
Apply automatic rules for privacy labels based on speciality, team and clinical codes
Incorporate the Data Protection Act by changing justification criteria
Incorporate the Data Protection Act by only allowing professionals to override a patient's previously expressed wish if they can document that they have received new instructions from the patient

Email notifications

PKB notifies users of events by email. The events include telling the patient about every change in the patient's record, and telling the professional about every message addressed to the professional. We gradually evolved the messages in response to the feedback of individual customers to balance patients' privacy (i.e. not divulging medical information in unencrypted email) against user convenience (providing actionable information in the user's inbox). We have not yet got the perfect balance on this, and users sometimes complain that they cannot understand what the messages mean or what to do about them. Our focus is on:

Text for patients that is easier to understand and act on
Control over frequency of notifications: some users want more notifications than once a day, others wanting to turn off notifications

Registration

Registration drives returns on investment. The more quickly more patients can register, the more savings more quickly for customers.

In August we launched the mass registration REST API allowing users to send letters to patients' homes with decryption tokens, so patients could register to see their record without seeing their clinical team.

Our focus is on making every part of the on-boarding experience smoother, including:

Registration workflow that reduces clicks and errors
Password resets that are easier for a patient while still not divulging private information to someone impersonating the patient
Automatically providing private keys to professionals with a proven relationship of care with a patient

Core platform user interface

We are focusing on getting rid of bugs and inconsistencies in the user interface of the core features:

Care plans
Messaging and consultations
Measurements and symptoms
Device integration
Appointments

The first one we will work on is the care plans functionality.

Care plans are critical to improving patients' ability to self-assess and self-manage, reducing the workload and improving the outcomes of clinical teams. Shared care planning is only possible with PKB and only PKB allows users from multiple institutions, along with patients and carers to edit the same care plan. No electronic health record system allows any users apart from employees of a single organisation to work on a patient's care plan, so none of them allows shared care planning.

Features

Disable sharing

At the moment a professional can act on behalf of a patient to share that patient's record with others. This is explicit consent (i.e. the professional asks the patient), or implicit consent (e.g. a referral) or during emergencies (e.g. if the patient is unconscious).

However some patients may not want this, for example celebrities and others who are highly privacy conscious. We are finalising a consent process with lead customers so that the patient's wishes are respected. When in place, no professionals or carers can access a patient's record. The patient's data remain in PKB, securely encrypted for whenever the patient want to access them directly. Full details are on our help wiki.

Timeline view

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.

The diagram below is indicative of the final version. Design and consultations are in progress with the customer who requested this, do contact us with your feedback.

Integrations

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 smartphone app and timeline 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 in maintenance mode

In August 2017 we completed Phases 1 and 2.

Phase 1: Two GP practices are piloting EMIS integration with PKB: demographics, diagnoses, medications, allergies are copied daily for all patients' records into PKB. You can read more information in the PKB / EMIS PDES page.
Phase 2: single-sign on with context switching from GP EHR to PKB. This means a GP using their EHR to look at a patient's record will see a link to PKB. The link will sign the GP into PKB using credentials already stored in the EHR system and display that patient's full record in PKB. So the GP can see the patient's non-GP data i.e. from hospital, social care and the patient.

For the following 6 months we will only work on bug fixes that we uncover from customer usage.
We do not expect to add other data types from EMIS but may do so as time permits, starting with appointments data. The other data types include:

appointments
care plan metadata
immunisations

England GP systems transactions

In the second half of 2018 we will integrate with the GPSoC APIs to allow appointment booking and prescription renewal in England's 4 GP systems.

For appointment booking, 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.

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.

App

We will focus our software development on mobile-optimised web pages rather than standalone smartphone apps. This allows us to have a single codebase for desktop and phones, and to ensure that phone users have full functionality.

It also allows us to migrate the front-end code to Progressive Web App (PWA) a more modern set of web technologies that allow faster development. Ultimately, PWA allows offline usage and quick creation of hybrid smartphone app versions, i.e. app store apps that use the web GUI source code.

The smartphone app version we released in March is a lot faster than previous versions and starts with discussions support. We will not update this version as we concentrate on PWA.

Below is our sequence of optimisation of screens for mobile usage.