HiRPM
Project status
Collaborators
Carmela Vittorio, MD
Ilya Sharkansky
Matthew Zarkos
Innovation leads
Funding
Innovation Accelerator Program
Opportunity
Many patients with chronic diseases require long-term use of systemic medications. While such medicines have significant benefits, they also have known risks and side effects. Lab monitoring of patients on long-term, high-risk medications is crucial for safety. Lapses in lab monitoring can result in adverse outcomes.
When we started this work, existing lab monitoring tools were inadequate, and patient non-adherence ranged from 7 to 30 percent. Monitoring patients on long-term, high-risk medications was non-standard, manual, tedious, and prone to error. Care team members spent hours reviewing charts, making calls to patients and laboratories, and managing hand-written lists. Additionally, approximately 30 percent of patients were self-discontinuing their medication, with providers sometimes unaware of the situation for months.
Intervention
HiRPM (High-Risk Patient Monitoring) is a comprehensive platform that automates the lab monitoring process and streamlines communication between clinicians, staff, patients, and laboratories. HiRPM sends reminders to patients when labs are due. When external laboratories return results, HiRPM converts incoming report faxes into PDF files and automatically distributes them to the care team. When patients are overdue for labs, HiRPM prompts clinicians to intervene.
Impact
HiRPM improves adherence rates, reduces the administrative burden placed on care teams, and decreases the cost associated with lab monitoring.
During the initial pilot, 100 percent of labs were completed on time, and result retrieval from laboratories external to Penn Medicine took only two minutes per patient, compared to 20. When applied to all dermatology patients requiring labs, time savings generated by HIRPM can result in $100,000 in annual savings for the health system.
HiRPM has been implemented at Penn Dermatology Radnor and scaled to Penn Dermatology PCAM.
Innovation Methods
Show me
Show me
Show me
Instead of relying on a verbal recount of experience, ask users to show you how they use a product or service. What people say they do is often quite different than what they do.
Observing users in action will help you understand the spectrum of experiences users can have with the same product or service.
Surveys, interviews, questionnaires, and focus groups don’t tell you what you need to know. Prompting users to show instead of tell often reveals what others have missed.
Show me
We conducted contextual inquiry in three divisions that monitored patient labs and discovered shared pain points.
We also observed various workarounds that provided insight into how our solution should function and revealed new opportunities. For example, we saw that some providers scheduled frequent follow-ups for the sole purpose of ensuring lab completion - a costly workaround that could be discontinued if our solution worked.
Fake back end
Fake back end
To validate our hypothesis that automating parts of the lab monitoring process could save time and increase patient adherence, we ran a fake back end pilot.
We monitored six patients for several weeks, mimicking proposed automated features such as lab reminder texts to patients.
Fake back end
It is essential to validate feasibility and understand user needs before investing in the design and development of a product or service.
A fake back end is a temporary, usually unsustainable, structure that presents as a real service to users but is not fully developed on the back end.
Fake back ends can help you answer the questions, "What happens if people use this?" and "Does this move the needle?"
As opposed to fake front ends, fake back ends can produce a real outcome for target users on a small scale. For example, suppose you pretend to be the automated back end of a two-way texting service during a pilot. In that case, the user will receive answers from the service, just ones generated by you instead of automation.
Fake front end
Fake front end
As we developed the HiRPM platform, we frequently put simple paper prototypes in front of our intended users to understand if and how they would use it.
This process helped us test new features, identify confusing interface elements, and de-risk assumptions quickly and at low cost.