Roadmap 2016/09

Below is the draft roadmap for Q4 2016 and Q1 2017. (Click to see the January 2016 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. For questions about any of the features below please contact us. The PKB blog has archives of past roadmap postings. In 2015 we doubled our developer team size and received $5 million investment to double the team again every year through 2018. (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. We want every page to load within a second. We are a long way away from this but we have also come a long way. Over the past year we set up parallel decryption infrastructure so that multiple virtual machines are able to decrypt in parallel the data points for a particular page, e.g. all the measurements or all the discussion messages.

This year we are making a number of optimisations:

• 1. Zero-downtime for upgrades as we roll out our clustering architecture.

  2. Shifting to a Advanced Encryption Standard (AES) algorithm from the current DESede (Triple DES). This is orders of magnitude faster, more secure and allows us to encrypt more data with a single key.

  3. Each page will be optimised to make fewer database queries. We will start with the most commonly used pages i.e. the dashboard, the discussions page, the patient summary page and the lab results page.

Stability

Last year we had focused on major architectural changes that support population-scale deployments with patient-controlled health information exchange. With these architectural changes complete, we are focusing on stability of the platform to allow a lot more automated testing every night for new code, which in turn allows upgrades to be more frequent and smaller.

GP system integration

Phase 1: Two GP practices are piloting EMIS integration with PKB: demographics, diagnoses, medications, allergies and appointments are copied daily for all patients' records into PKB. You can read more information in the PKB / EMIS PDES page.

In parallel we are working with HSCIC's GPSoC on the SystmOne client-side API, and after that we will work on INPS and Microtest's APIs.

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.

Phase 3: ultimately we want data to display inside the GP system's EHR. Not every GP system can cope with this at the moment, but our long-term approach to EHRs is to allow the user to stay within their chosen IT systems without having to log into PKB. If you would like to make PKB data available to your customers you can use our open API, a read / write REST API.

Publish and subscribe API

The pub-sub API allows third-party software to receive updates about a patient's record. For example, electronic health records software that uses our REST API will receive a copy of all new data about patients stored inside the EHR. This allows clinicians to receive in their chosen software updates about patients they are looking after. The updates will be from the patients directly and from other PKB customers looking after the same patients.

Paediatric patient management

PKB handles records about children differently from those about adults. This is to help professionals looking after the safety of children and to comply with local laws enforcing that protection.

Change of ownership at age 16

At age 15 and 9 months, PKB software sends an email to the child, their carers and the coordinators of all teams looking after the child. The message reminds all parties of the upcoming 16th birthday and the age at which most children have the capacity to control access to their record and all children should have their capacity assessed. Any coordinator can log in and formally assess to remove access of parents and if necessary switch the registration email address to that of the child (e.g. if the parent's email address had been used to register on behalf of the child). Read more about change of ownership at age 16.

Enforcing access to a child's record

Certain parties should always have access to the child's record regardless of the wishes of the child or the parents. A coordinator looking at the team page of the child can enforce access for these parties so that neither patient nor carers can stop sharing. Examples include the local family physician and pediatricians; both parents after a divorce; third parties directed by court order such as social workers. Read more about enforcing access to a child's record.

Freezing accounts to prevent access by non-professionals

A professional can temporarily remove access to the child's record by the child and their carers. This is useful during investigations into the safety of the child where a party with access to the record may be harming the child. While frozen the child cannot log into their record and the carers cannot access the child's record. Read more about freezing access.

Two-factor authentication

Professionals will have this first 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 and 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.

Patient opt-out

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.

New smartphone app

The new version will be a lot faster. The first release will be in October, after which we will expand the screens every month to ultimately match the PKB web site. This will mean most of the PKB web functionality will be available to users offline, without an internet connection. This is important when traveling abroad or underground, or even while inside a hospital with poor signal.

Designs for 2017

We have several designs based on customer requests. We will prioritise these based on roll-out scale, i.e. customers which will make use of these features with the most patients. If you would like to use one of the designs below please contact us.

Professional views

Professionals need to look at a lot of information on one screen in a patient's record. They are used to seeing lots of information tightly packed but they also typically have smaller screens than home users do. We are redesigning the professional view within PKB to make it more dense and with less white space.

The patient summary page will list the latest panels as well as the vitals signs from measurements.

Clicking on a panel will show the results.

The discussions page shows information about professional users in as few lines as possible to minimise vertical scrolling. Where a message is formal communication (e.g. a discharge letter or a clinic letter) rather than an online consultation the bottom of the page allows the user to enter their notes rather than send a reply.

The professional's schedule screen is also getting a makeover into a monthly view.

Symptoms

Earlier this year we updated the symptoms view to make it easier to document symptoms and clearer to see their changes over time. However, adding a new symptom to track is still too hard. This is the design we have for adding new symptoms, which is much closer to NHS Choices and other patient-friendly sites:

Measurements

Earlier this year we updated the measurements view to group data into vitals, exercise, diet and sleep. Although adding data from a device is easy, manually entering the data is still cumbersome. This is the deign to make it easier.