MVP Design: COVID-19 out-patient monitoring
In late March, my friend Colm (a doctor at St. James’ Hospital in Dublin) asked me to help him use technology to solve a COVID-19 problem he was facing. How to make sure that coronavirus out-patients are monitored in the face of surging patient numbers and an already over-burdened medical staff.
Five weeks later, the solution has been in use for a month with patients in St. James’.
Here, I will describe what we did. Really it’s a short essay about design, MVPs and the merits of fast, simple product development.
The problem
The first COVID-19 case in Ireland was reported on 29th February. Planning begun in earnest shortly thereafter. The expectation was that hospitals would be overrun with cases and contingency plans would need to be put in place. This included re-assigning medical staff from other areas of the medical system to COVID-related care. Colm was one of these - he volunteered to put his PhD and teaching on hold to return to the frontline.
Adding new capacity was one of the highest impact actions available. But inefficiencies in the system were still present - reducing the effectiveness of individual staff and potentially getting in the way of patient care.
Standard practice was to have medical staff check-in with non-hospitalised patients regularly via phone call. The risk factors of the patient and the improvement or worsening of symptoms allows medical staff to determine how regularly they need to check in with patients and whether they need to come to the hospital.
This was done manually.
With skyrocketing patient numbers it is simply not possible to divert medical staff away from patients with critical needs. Colm recognised that this was unsustainable and would lead to bad patient outcomes, by:
diverting needed medical staff away from in-hospital patients to man the phones and
missed or delayed hospitalisation for patients who need hospital care urgently.
Was there a way we could outsource triage to the patients themselves? And only phone those most at-risk.
He suggested we build an app.
Suggested solution.
I avoided my inclination to jump straight to sketching wireframes and took a step back. Instead, I put in the effort to understand the problem in a bit more detail. I chose the pedantic approach and wrote up some product requirements. The original Product Requirements document is here.
My thinking was two-fold:
interrogate the assumptions
have something to share with my developer friends to help them understand the problem and hopefully convince them to get on board.
The write-up clarified a few things. Really what we needed was a tool that allows patients to remotely check-in and report their symptoms. Check-in needed to be scheduled, the data needed to be saved and we needed a way for doctors to make sure everyone had been assessed at the right time.
Everything else was nice-to-have.
Skateboards first.
One of the best lessons I’ve learned as a Product manager was not hard-won; I read it in a book.
Build skateboards before you build a car.
You deliver value as you go, and learn something along the way. Often, it turns out you don’t need the car at all. Sometimes skateboards are enough.
The principle sounds simple, but it’s hard to apply. Your brain and your stakeholders come to the table with imagined solutions. These imagined solutions are rarely the simplest.
Simple solutions can seem anti-climactic. Unworthy, almost.
In this case we had strict constraints. Time being the most pressing. Anything complicated would take too long to implement - the surge was imminent.
Simple would have to do.
MVP and prototype.
What was the simplest, most straightforward solution we could try?
It needed to be something that did not allow patients to fall between the cracks. It needed to be accessible to most individuals, and ensure that individuals sent updates on their condition on time.
We separated the three functions.
scheduling.
notifying the patient.
gathering the data.
Working backwards through the list, the data gathering component was most straightforward. Regardless of form-factor, patients would need to answer a series of questions. Essentially a questionnaire.
There are plenty of online survey tools. Typeform does the best job of creating a user experience that looks professional and is intuitive to use. To better understand the decision-flow, I mocked up a questionnaire based on the triage diagram from the NHS.
Next was notifying the patient.
We required maximal intrusiveness and maximal coverage. An app is great for intrusiveness - push notifications are hard to miss. They are sufficiently annoying to get your attention. They linger on the home screen until dealt with. But apps take time to build - and the market is divided between Android and iOS.
In terms of implementation, email would be easiest. But it’s problematic. Not everybody uses email frequently. Least of all when they’re sick. Email neither fulfils our coverage or intrusiveness requirements.
SMS is suitably intrusive and suitably common-place.
We had a prototype - a combination of SMS and Typeform questionnaire.
The last remaining piece of the puzzle was scheduling. Thankfully St. James’ already had an SMS service that allowed batch scheduling of text messages.
We had an end-to-end, functional prototype.
Deploy.
At this point I handed it back to Colm. He enrolled the IT team at St. James’ and got Ethics Committee approval to test. The questionnaire went through a few iterations and he added the hospital branding.
The IT team set up SMS scheduling and wrote the Typeform data to the Excel file being used to monitor out-patients’ symptoms.
St. James’ rolled out the service on 1st April. The first cohort of SMS’s began to flow, and the data began to trickle in.
Not long after, cases spiked in Dublin.
Response & Results
It’s been 4 weeks since the system went live - ~550 patients have responded to the questionnaire - typically taking 7 mins to complete.
The feedback has been overwhelmingly positive. There was even a few nice comments thrown in:
I feel much better now. Thank you for the survey. It’s a nice point of contact and has given me reassurance.
If there’s a lesson to be learned here, it’s that a prototype can be sufficient to solve a problem.
The skateboard worked. There was no need to build a car.
— — —
A detailed analysis of response rates and bias in design will be published next month.
If you would like to know more about the project or to get the templates to implement at your own hospital please don’t hesitate to get in touch, here.
— — —