Accessing health care and patient data
The Project Brief
As the UX/UI Designer at iPlato Healthcare, I was tasked with designing an ‘online triage’ solution for NHS GP practices that can be introduced into the Connect web app, as well as a patient information capture tool, as a way to comply with new NHS England requirements.
My Role
UX/UI Designer
The Team
Product Manager
iOS & Android devs
React developer
Backend developer
Duration
3 months
Launched
January 2021
The Problem
Due to COVID-19, the majority of GP surgeries disabled online appointment booking. They switched to telephone/video appointments or online triage tools that allowed patients to tell their practice what they needed help with and practice staff could then make a decision based on the information provided by the patient, whether medical or administrative assistance was required.
The disabling of appointments caused an issue for the myGP app. The primary feature of the app was booking Doctor appointments and with online appointments disabled, company’s which had digital products that provided online triage solutions increased in demand and myGP usage went down.
NHS CCGs that commissioned the iPlato products wanted us to quickly develop an online triage solution of our own, as well as a tool that allowed mass patient information gathering. Because of the pandemic, there was a requirement for GP practices to have up-to-date patient health data, such as smoking status, ethnicity, blood pressure and weight, which would then help with identifying at-risk groups within the GP’s patient list.
Research
First, we wanted to make sure we knew exactly what user problems we were trying to solve with these two different requirements.
Even though both of these requirements will involve patients being the primary users, the demand for these solutions comes from the clinicians and admin staff at GP surgeries. Myself and the Product Manager had a meeting where we listed all the questions we needed answering before zooming in on any potential solutions. The questions we had were sent out as a survey in order to build up some qual data and insights on online triage and patient questionnaires. We had some early assumptions that we needed to validate, so we also carried out interviews with clinicians and staff to see if they might come to similiar conclusions.
Screenshot of some of the survey answers
Findings
With the survey and interviews, our main aims were to figure out from a high-level how clinicians and admin staff have adapted their workflows as a result of the pandemic. Was their time being wasted on any low-impact tasks and what did they like/dislike about the current tools they were using?
The results validated some assumptions we already had, such as admin staff spending a lot of their time on telephone calls with patients that required simple admin queries, resulting in patients with medical issues having to wait instead of being prioritised.
Some new insights we got from the interviews was some feedback on the existing ‘Online Triage’ providers that were being used by practices, they were getting a lot of drop-offs and complaints from patients for being too complex and drawn out. A simpler Online Triage feature would be more beneficial, so we used this as a USP for our own triage solution.
User flows & Prototypes
Based on the survey, user interviews and competitor analysis, me and the Product Manager noted a number of requirements that would make up the two solutions. We then went through a process of evaluating impact vs effort for each one of those in order to decide what the MVP could look like and what can we bring in for later iterations.
I started working on some high-level user flows and options on how we could add these features to our products, as well as the information architecture on where these features could fit in to the practice-facing product Connect.
For the triage solution, we coined it Simple Triage, as a differentiator to other online triage solutions which were described as long-winded and complex by practice staff and patients. We wanted something that only asked a few of the most essential questions, so the patient didn’t need to spend a lot of their time answering questions and the GP didn’t have to read through a long PDF of unnecessary answers to find out what the patient needs help with.
Simple Triage requirements
The ability for patients to send out an Admin request, such as a Sick note or travel letter
The ability for patients send out a medical request and explain what medical issue they are having
Explain to patient in what situations they should contact emergency services instead of using the online triage service
The different paths a patient can take when using the Simple Triage feature
For the patient information gathering feature, we called it Patient Questionnaires. The Connect product already had the ability to send mass SMS within a feature called Campaigns. This seemed to be where it made the most sense to find the Patient Questionnaires feature, which we validated through the survey and tests.
From interviews with patients, we validated that most patients would go to the website of their practice in the first instance if they needed help and were looking for an alternative to calling in. Therefore we decided that the triage solution should be web-based and for patients not having to sign up to the myGP app. The web app is designed in React and I kept the same components and style between the Triage screens and the Questionnaires for consistency in style.
Patient Questionnaire requirements
The ability for Practice staff to create different patient groups so they can select which questionnaires they want to send to what patient group
The ability to select from a list of questionnaires, such as BMI, blood pressure, asthma and mental health
Patients can verify their identity using the myGP app or their DOB
The ability for the patient submissions to be received in an organised folder that can be exported
Questionnaire replies can be auto or manually saved into the patient’s medical record
User flow from setting up and sending a questionnaire to a patient list and then the patient receiving the questionnaire on their device
Performance & Feedback
During user testing of the Simple Triage feature, one of the issues we found was patients not looking to go down the appointment booking route for admin-related queries but instead look elsewhere in the myGP app. We tasked users during tests to look for a way to request a sick note from the practice when there are no appointments and from seeing the data, most users went to other areas of the app.
Final UI
I presented prototypes for Simple Triage and Patient Questionnaires to the Tech leads in order scope out how much development work was required for these solutions and if anything had to be set aside. We then went through the prototypes with the NHS clinician stakeholders to see if the solution could fit into their workflow. We received some feedback which we iterated on before handing over to developers.
Simple Triage
In order to keep the myGP app relevant during a time where usage decreased due to online appointments being disabled, we added the Simple Triage feature into the myGP app. This lead to GP’s promoting the myGP app again so patients can make use of the feature, instead of asking patients not to use it as there would be no appointments to book on there.
For the first version, patient requests were sent as an email to the practice. We had to do this in order to make the deadline for the feature. We knew this was not ideal and would put off a lot practices from using the feature. However, it allowed us to start trialing the feature early and get some feedback from both the patients and the practice staff.
I then later designed the functionality for the practice staff to view and action the patient requests within the Connect Inbox.
This allowed better management of the incoming patient requests rather than via email. This also had more room for new features, such as being able to interact with the patient through messages and keeping those interactions within a manageable area.
Patient Questionnaires
The questionnaires would sit inside the existing Campaigns feature, which was being used for sending out SMS to different patient demographics.
In terms of design, I had to comply with the existing PHP front-end components for speed of development on the practice-facing product Connect.
The patient-facing web app designs maintained the same style and components as Simple Triage, which can be seen below,
Retrospective
Due to time constraints in the early stages, we didn’t gather as much user research data as we could have, instead we had more time later once development already began on one of the features.
The addition of features into a product can feel a bit rushed. A better quality, long-term solution would require more development work but would pay off in the end in terms of usage.