Roadmap 2019/11
Below is the roadmap for 2019, updated November 2019. (Click to see the previous version). As usual, we adjusted priorities in response to the feedback of early adopter customers and as we dug deeper into the details of each feature.
We will shortly publish our 2020 roadmap. Subscribe to our blog to receive a notification.
The feature category of the PKB blog has details on the features we've released. The 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 plan for 2019 was to focus on these four streams:
tighter integration with General Practice electronic health records software
onboarding more professionals more quickly
modernising our user interface and its underlying programming interface
security improvements across the system
The plan at the start of they year is shown in the graphic below. As we stated at the time "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."
Functionality released in 2019
PKB imports EMIS data more quickly
We improved our EMIS import processing to keep pace with the increasing volumes of data we are receiving and expect to receive going forward.
In the next 12 months PKB's existing contracts mean 10x as much data will arrive.
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. Clinicians, such as those in emergency departments, have access to this data 24/7.
Patient can book GP appointments from PKB into EMIS
At the moment patients receive their hospital appointment information through the PKB HL7 API. 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.
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. Read our blog for more details on this feature.
One organisation sends data on behalf of many
(In Progress)
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.
*NEW* Organisation works with app or device provider to collect and send data on their patients
We had several requests for this in 2019 and so extended the planned aliasing functionality described above in order to meet this demand. Clinical teams already work with 3rd party app providers and connected devices to gather useful clinical information about their patients. Partner HL7 aliasing allows the clinical team to permission these partners to send data into the PKB record so that this data is viewable by the patient, carers and other teams involved in clinical care. There are some very interesting workflows that this enables such as early discharge with remote monitoring. Case studies are available here.
Team based messaging allows messages to be sent to the team rather than individuals
This is a feature that has been high on the wish list of many of our clinical teams. In the first version we will allow teams to be configured so that all members receive a copy of every message. They can also configure a shared external inbox for notifications to be sent
This avoids issues like delays due to individual recipients being on vacation, multiple individual recipients spending time looking at the same message.
Additional functionality such as multiple messaging groups for a team, granular read status of messages can be added in subsequent iterations based on feedback.
Â
Patient registration status check allows sending e-letters for registered patients thus reducing costs
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.
We extended our HL7 A19 query to 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.
Third-party software deletes or updates documents through HL7
We added a new HL7 API to allow deleting or updating documents.
This includes incorrect letters or letters sent to the wrong patient.
Corrections are another reason for shifting patients from paper to digital as postal letters cannot be deleted or updated.
Â
Â
Professional sees an overview of the patient in the timeline view
In 2019 we completed and released the first phase of timeline view for professionals to get 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 our new FHIR APIs and along with the patient banner is the first part of the GUI built on a more modern architecture (SPA).
Work in progress - continues into 2020
*NEW* Patient orders EMIS GP repeat prescriptions via PKB
We added this as a new priority during the year. The most commonly used functionalities in tethered GP portals are appointment booking and repeat prescriptions. We had already planned to add appointment booking but quickly realised that we also need prescription reordering to allow patients to use the PKB
record as the single portal.
Patients will be able to request a repeat prescription, select pharmacy of choice and view the progress of requests. See our blog post for more details.
*NEW* PKB integrates with NHS Login and the NHS App
NHS Login makes it easier for patients to prove their identity and gain access to digital health services. We are actively working with NHS Digital to allow patients to log in to their PKB record using NHS Login.
In addition, PKB will integrate with the NHS App to give patients access to the full functionality of their record within the NHS App. This is much deeper than the standard NHS App functionality, including
GP record diagnoses, medications, allergies
GP transactions for appointment booking and prescription renewal for EMIS-using GPs
hospital data including appointments, test results, radiology reports, clinic letters, discharge letters care plans
online consultations with free text and structured questionnaire secure messaging
symptom tracking
device integration including over 100 wearables for tracking activity, blood pressure, weight and glucose
shared care planning
consent management
This uses the NHS App's "NHS front door" policy to show data from primary, secondary, tertiary, community, mental health and social care. The patient also receives data from across the UK from other customers treating the patient allowing borderless care
Support for 20 languages
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.
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.
In 2019 we prioritised development of the resources required for our own GUI and some specific external use cases. We remain committed to building a complete read write API for all of our data and work will continue in 2020.
Single Page Application (SPAs) GUIs for the PKB web application
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. This work also helps us build a native mobile app in the future.
We've already started with the patient banner and timeline view. In 2020 plan to address other screens starting with navigation and home screens.
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 and improve usability and accessibility.
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 and improve usability and accessibility.
Security improvements
This is a continuous ongoing effort to expand our security infrastructure as we store more data for more patients across more regions.
Features 'rolled over'
As expected we didn't get to everything in 2019. We're currently finalising our 2020 road map. We'll review the priority of these items again in light of what our customers are asking us for. Subscribe to our blog to be notified about the new roadmap.
PKB imports more EMIS GP data
At the moment PKB receives demographics, diagnoses, medications and allergies about all patients in an EMIS-using General Practice.
We will extend this to import processing will show appointments, consultations, referrals, test results, immunisations, and symptom observations. 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). 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.
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.
Clearer email notifications for professionals, including making it easier for the professional to know which patient's record is affected.
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.
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.
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
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.
PKB will support multiple phone number types. This includes mobile phone numbers so organisations can
onboard patients at scale through SMS invitations.
PKB will store General Practitioner details. This allows hospitals to track who to contact about a patient's progress.
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.
Â
Â
Â
TITLE
LAST MODIFIED
PKB_roadmap.pdf
5/19/21
Tom Pick
Â
PKB customer sites: deploy | developer | information governance | procurement | manual
© Patients Know Best, Ltd. Registered in England and Wales Number: 6517382. VAT Number: GB 944 9739 67.
This API specification and design is licensed under a Creative Commons Attribution 4.0 International License.