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! PerformanceWe 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. UsabilityIn 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 labelsPrivacy 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:
Email notificationsPKB 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:
RegistrationRegistration 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:
Core platform user interfaceWe are focusing on getting rid of bugs and inconsistencies in the user interface of the core features:
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. FeaturesDisable sharingAt 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 viewThe 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. IntegrationsOur 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
FHIR REST APIThe 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 upliftThis 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 modeIn August 2017 we completed Phases 1 and 2.
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:
England GP systems transactionsIn 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. AppWe 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. Appointments
Test resultsEarlier versions will focus on the patient seeing their results
Later versions allow adding results
Symptoms
|
Roadmap >