Prototyping is rooted in the fundamental.
I love IDEO.org’s Design Kit description of the process: it “makes sure that you’re building only enough to test your idea, and that you’re right back in there making it better once you’ve gotten the feedback you need.”
Whether facing a specific programmatic design challenges or thinking about broad, systematic health care problems, it’s easy to get bogged down with the big picture. But rapid prototyping gives us permission to be scrappy — to temporarily put aside those problems that seem too large to even begin tackling, and create solutions that are just enough.
To get some concrete examples, I sat down with Ray Pedden, our Strategy & Innovation consultant, to give me the lowdown on how some of our grantees have successfully prototyped technology solutions over the years in our Technology Hub.
Define your problem and measures with a systems perspective.
San Francisco General Hospital (SFGH) serves a population that’s more diverse than most, with many patients primarily speaking a non-English native language. Faced with low levels of medication adherence for post-discharge patients (leading to more frequent readmissions), the Hub team at SFGH wondered… What if we gave medication instructions to patients at low literacy level in their native language? Would that not just improve medication adherence, but also decrease patient education time and readmissions?
The team took this question and partnered with Polyglot, a platform that generates easy-to-understand medication dosing information in more than 20 languages and delivers it to patients either via hard copy or through a patient portal. The SFGH team followed a small group of 27 patients that were discharged from the hospital on medication, and measured their medication adherence over 90 days. At the end of the pilot, they found that medication adherence improved, readmissions decreased by 47 percent, and patient educators spent less time on medication counseling.
When designing your rapid prototype, make sure you’re not just looking at the direct measure (medication adherence), but also related outcomes and workflows (readmission and medication counseling) peripherally touched by that measure.
Pilots don’t need to be long to produce valuable insights.
San Mateo Medical Center had an issue with colonoscopies being scheduled, but not actually conducted. This is because patients frequently arrived at their appointments not having completed several specific preparation steps. As a result, both the patient’s time and the appointment slot ended up wasted.
San Mateo designed a short, two-week pilot testing a smartphone app that guides patients through the dietary and medication steps to properly prepare for a colonoscopy appointment. The two-week pilot wasn’t intended to completely solve the problem of unprepared colonoscopy patients; rather, it helped to highlight both the biggest pain points and impacts should the team decide to continue testing and implementing the app.
The San Mateo team learned that patients needed help getting the app downloaded on their phones, and needed in-clinic coaching. Another potential barrier was that some areas of the clinic lacked Wi-Fi and cellular signals. And, unintentionally, they discovered that their nurses greatly appreciated the process, as they found themselves spending less compliance outreach to patients over the phone.
Don’t worry if the first prototype is primitive or inelegant.
Remember – it doesn’t have to be perfect to get started. Community Health Center Network (CHCN), an integrated managed services organization based in Alameda County, was determined to begin addressing social determinants of health through community health worker (CHW) outreach to their highest-risk patients. To identify these high-risk, high-cost patients and provide the CHWs a list, the team at CHCN started building a homegrown basic case management solution in Excel that was connected to their claims and data warehouse. After demonstrating success within one care team, they scaled up from this Excel-based solution to an enterprise solution with Welkin Health.
Before starting your rapid prototype pilot, make sure you have answers to these four questions:
1. Have I clearly defined my problem?
2. What am I going to measure?
3. Is my pilot just long or developed enough to measure what I need for the next step? (We recommend test durations of several days up to a maximum of three months)
4. Do I have the right people — end users and stakeholders — involved?
In short, focus on the fundamental, (temporarily) put the big picture aside, make sure the right people are involved, and get out there and start testing!
Find this useful or interesting? We’re constantly sharing stuff like this. Sign up to receive our newsletter to stay in the loop.
