Roadmap 2019/03

Below is the roadmap for 2019, updated March 2019. (Click to see the previous version). As usual, we adjusted priorities in response to the feedback of early adopter customers and we dig deeper into the details of each feature.

The feature category of the PKB blog has details on the features we've released. The PKB blog also has archives of past roadmap postings.

For questions about any of the features below please contact us. And if you are a developer, we're hiring!

Our developers' work is in four different streams:

tighter integration with General Practice electronic health records software
1. onboarding more professionals more quickly
2. modernising our user interface and its underlying programming interface
3. security improvements across the system

The picture below shows these improvements graphically (printable PDF here). You should interpret this as you do the London Underground map i.e. not for how close stations are to each other but a rough order of the stations in a line. Furthermore, we will not complete all this work in 2019, this is just all we are working on in 2019.

So below we have not put down the delivery dates of individual features – some features take a lot longer than others – but a rough order of the order of features in a development stream. Security improvements are woven into every one of the other three streams.

GP EHR integ

ration

By the end of 2018 PKB received data from GPs about more than 100,000 patients, and during 2019 we expect to receive millions of patients' records from GP systems. At the same time, health economies are switching from using PKB to show hospital data to showing all data from GP, hospital, and other institutions looking after the same patient. So PKB is investing heavily in GP integration, to show more data more quickly, and to allow transactions in PKB instead of GP portals.

One organisation sends data on behalf of many

At the moment any organisation can send its own data into PKB through the HL7 APIs. Imperial College Healthcare's Community cardiology and respiratory services send data from SystmOne into PKB using this HL7 API.

GPs can use this API to send data from their local CSV extracts. But GPs usually lack the IT resources to manage this.

Larger organisations working with the GPs – such as their local hospital or commissioning support unit – can do this work on behalf of the GPs. But sending each GP's data through a separate HL7 connection is burdensome.

The new HL7 API will allow aliasing, i.e. sending the data from multiple organisations in one connection, maintaining the source organisation information for each data point.

As PKB has gained regional contracts, including NHS Sustainability and Transformation Plan regions, Local Health and Care Record Exemplar areas, and national integrations, this functionality allows customers to send PKB more data more efficiently through centralised feeds.

Patient book GP appointment from PKB into EMIS

At the moment patients receive their hospital appointment information through the PKB HL7 API. Later in the year (see below) PKB will also show GP appointment information from EMIS.

Seeing appointments is one of the most popular features for patients. But patients also want to book appointments. And PKB's regional customers – using PKB as a true patient portal across GP and hospital – need the appointment booking to avoid using their GP portals and their hospital portals.

PKB and DrDoctor are completing their hospital appointment booking integration through the NHS Test Bed 2 programme in London.

The new GP appointment booking integration allows a patient logged into PKB to see available slots from their EMIS-using GP surgery, and then to directly choose and book. The patient can also change or cancel their GP appointments.

PKB imports EMIS data more quickly

At the moment PKB receives data about 300,000 patients from EMIS-using GP practices.

The data arrives overnight and PKB makes the data available through the user interface and the programming interface. PKB also notifies registered patients about the arrival of the new data from their GP. But in the next 12 months PKB's existing contracts mean 10x as much data will arrive. Furthermore, users in emergency departments want to see as much data as quickly as possible as they are work 24/7.

The improved EMIS import processing will show data more quickly. This through optimising data ingestion, skipping past data errors, and allowing processes to run on parallel servers.

PKB imports more EMIS data

At the moment PKB receives demographics, diagnoses, medications and allergies about all patients in an EMIS-using General Practice.

The new EMIS import processing will show appointments, consultations, referrals, test results, immunisations, and symptom observations. The patient can book, change and cancel appointments (see above). And unlike the GP portal Patient Online which releases test results manually and on a patient-by-patient basis, PKB releases test results automatically and at scale. The real-time release of test results is one of the most popular features for patients, and the automation of results release frees up GP and receptionist time.

Unfortunately free text narrative in consultations and care plans is still not available because EMIS – like all GP EHR vendors – does not release these.

Professional onboarding

PKB is a shared care record (allowing professionals to see data about their patient from across providers) as well as a patient portal (allowing the patient to see data from all their providers). In 2018 we worked on the timeline view to show the professional integrated data at a glance. In 2019 we aim to make it easier and faster for organisations to bring on all their professionals, and for those professionals to get a smoother more efficient experience.

Professional clicks less and sees more

1. Fewer email messages in spam folder through email service upgrade. A lot of email spam filters rely on the reputation of the organisation sending the data for sending spam. By moving to a higher reputation service, and tracking bouncebacks from incorrect addresses, PKB's messages are less likely to end up in spam folders.

2. Clearer email notifications for professionals, including making it easier for the professional to know which patient's record is affected.

3. One click from electronic health record to PKB through OAuth upgrade. PKB customers already have single sign-on from their EHRs such as Cerner and RiO with PKB's OAuth implementation. The new version makes it easier and faster for local IT departments and partner software developers to do this.

4. EMIS users see full demographics in new patient banner. Non-EMIS users already see the banner when they log into PKB, we are now making the same banner available in the EMIS-specific user interface.

5. Organisation default professional receiving no messages from patient. When PKB launched, most deployments were led by clinical champions who wanted to consult online with patients. As institution roll out PKB to all their employees, they find it easier to default to no messaging as most staff do not have a patient-facing online consultations role. This is what the new setting is for. Any professional can switch to being contactable (or back) through the existing PKB functionality.

Organisation's software automates more tasks for more data through integration APIs

1. PKB's programming interface will allow organisations to add, update and remove professionals. Organisations can then integrate their employee HR systems with PKB's user registration.

2. PKB will support multiple phone number types. This includes mobile phone numbers so organisations can onboard patients at scale through SMS invitations.

3. PKB will store General Practitioner details. This allows hospitals to track who to contact about a patient's progress.

Third-party software checks patient registration status through HL7 A19 query

Hospitals save hundreds of thousands of pounds per year when they stop posting letters and start logging patients into PKB to see these letters and the rest of their medical record.

The new HL7 A19 query will make it much faster for hospitals and their managed postage providers to check the registration status of all their patients. Checking the status is important to confirm that a patient has already successfully registered in PKB so does not need to receive a letter posted.

The current check happens on a patient-by-patient basis so checking hundreds of thousands of patients needs the same number of API calls, each of which has latency. By doing the check for all the patients in one call the response will be much faster.

Third-party software deletes or updates documents through HL7

The new HL7 API will allow deleting or updating documents.

This includes incorrect letters of letters incorrectly sent to PKB.

Corrections are another reason for shifting patients from paper to digital as postal letters cannot be deleted or updated.

Organisation restricts professionals' access to NHS Health and Social Care Network IP addresses

This new option will allow an organisation to configure its employees' access so that they can only log into PKB from a device that is on the HSCN network. (HSCN is the new name for the N3 network.)

This is for organisations who cannot integrate their electronic health record to PKB but still want to use NHS smart card 2-factor authentication for their staff. PKB already supports single sign-on from EMIS GP EHR, and OAuth 2.0 for hospital EHRs. Restricting to HSCN-connected devices means using devices that had smart card authentication.

Organisation newly treating patient automatically receives decryption keys from organisations already treating the patient

The new automatic provision of decryption keys means a customer of PKB treating a patient will automatically decryption keys for data from other PKB customers treating the patient. The newly treating customer organisation will still need to document the consent they have to access the patient's record i.e. implicit consent for direct care, explicit consent from asking the patient, or break-the-glass consent in an emergency.

But the decryption is automatic so there is no longer a need to fill out forms between information governance teams.

For comparison, organisation networks allow organisations in a network (e.g. an STP or nation) to automatically to share all decryption keys for all patients treated by any of the organisations in the network. Affiliate teams allow an organisation to share decryption keys manually on a patient-by-patient basis with another organisation. This new feature shares decryption keys automatically on a patient-by-patient basis.

Team based messaging allows messages to be sent to the team rather than individuals

This is a feature that has been high on the wishlist of many of our clinical teams. We will allow the creation of a messaging group within a team, like a group email address. Messages sent by patients will be received by everyone in the group. Group members will be able to easily see who else in the group has read the message. This avoids issues like delays due to individual recipients being on vacation, multiple individual recipients spending time looking at the same message.

Interface modernisation

PKB's developers are upgrading our graphical user interface as well as the application programming interface (API) through which the GUI shows, adds and edits data from the patient's record.

FHIR APIs for third-party integration

The new API complies with the new FHIR standard, and is more stable and secure. Most significantly, PKB is using this FHIR API to power the GUI, so third-party developers can rely on the same FHIR capabilities as PKB's developers are using themselves. We are implementing resources iteratively in response to prioritised requirements. We are excited about the possibilities of this for third-party developers and health economies to rely on the PKB record for openness and compliance with standards.

Single Page Application (SPAs) GUIs for the PKB app

We are migrating every screen to the new single page application (SPA). SPAs are common in modern consumer sites like Facebook and Twitter and we will bring these advantages to PKB's users. SPAs load more quickly as the user clicks around because the user remains in the same single page. The SPA loads only the necessary new parts of the page in response to the user's actions, rather than loading a completely new page with each click in the current PKB GUI.

SPAs are faster to write and easier to maintain for developers so the investment in rewriting the code will deliver more features more quickly in the future.

The SPA rewrite is the path to the PKB app. Sites like Facebook embed their web SPA code in a native mobile app. This means the native app can have the same functionality as the web version as they are the same code. We will do the same for the PKB, allowing us to add mobile-specific functionality: biometric logins, offline storage, and app store downloads. The rewrite will take most of 2019. In the second half of 2019 we will know timelines for delivery of the app.

Professional sees an overview of the patient in the timeline view

The first versions of the timeline view are on production and we will expand it throughout the year.

The timeline view shows more data more quickly about a patient's record, an at-a-glance view of what has happened to a patient.

The view automatically adjusts to screen size. It shows more months for wider screens like desktops and fewer months for narrower screens like mobile phones.

Professional users have the view first. It will eventually be available for patients and carers.

The view is completely powered by the new FHIR APIs and along with the patient banner is the first version of the new SPA code.

Measurements

The new FHIR API will provide read and write access to measurements.

The measurements functionality will be folded into the SPA GUI code.

In rewriting the code we will systematically fix a number of bugs.

We will also upgrade the device integration to more modern versions of their APIs and we expect this to also fix some bugs in synchronisation of from these devices.

Tests

The new FHIR API will provide read and write access to tests.

The tests functionality will be folded into the SPA GUI code.

In rewriting the code we will systematically fix a number of bugs.

We will also add a tabular view for test panels. This is alongside the existing line charts for tests and panels, and the tabular view for individual tests.

Symptoms

The new FHIR API will provide read and write access to symptoms.

The symptoms functionality will be folded into the SPA GUI code.

In rewriting the code we will systematically fix a number of bugs including those in the symptoms monitoring dashboard.

Patient home screen

The patient and carer home screens will be folded into the SPA GUI code.

We will add the timeline view, taking into account the existing notifications panel and patient-friendly language.

In rewriting the code we will systematically fix a number of bugs.

Professional home screen

The professional's patient summary page currently has SPA code inside it. We will shift all professional pages to appear inside an SPA container.

We will then remove individual pages' code and expand the SPA container to deliver the same functionality of these pages.

In rewriting the code we will systematically fix a number of bugs

Unread document reminders sent to the patient

We will add reminder notifications if a document in the patient record has remained unread. This is to help ensure that patients are not missing important communications e.g. copy of a discharge summary or an appointment letter. We expect that this will drive up the percentage of letters that are read electronically thus allowing organisations to make savings in postage costs.

Better email notifications to the patient

Security expansion

PKB will continue to expand its security infrastructure as we store more data for more patients across more regions.

Page updated

Report abuse