The medication reconciliation user interface, as part of a patient's electronic health record.
While employed as a senior product designer at One Medical—a primary care doctor's office owned by Amazon—I provided research and design for a new medication reconciliation feature. Working with physicians, nurses, and healthcare providers, I designed the user experience in 1 month, which was launched in less than 2 months, and saw a 33% usage increase in just 6 weeks after launch.
Background
After a decade of serving a youthful and healthy patient population, One Medical purchased a healthcare company that served Medicare patients. The Practice Management product team needed to update One Medical's proprietary electronic health record (EHR) software with new features to adequately care for this unique population. To comply with standards of care for Medicare patients, providers would need to perform a medication reconciliation by explicitly performing a reconcile action in the EHR, a feature that was missing.
“Medication reconciliation is the process of comparing a patient's medication orders to all of the medications that the patient has been taking” (Barnsteiner, 2008). At One Medical, a primary care provider (PCP) or nurse simply did this by having a conversation with a patient and asking what medications they took. The provider then recorded a list of medications disclosed by the patient in the EHR. There was no explicit action for the provider to confirm that they completed a reconciliation.
Goals
One Medical prepared to migrate this new Medicare patient population over to their proprietary EHR. To do so, the EHR needed to enable an explicit medication reconciliation action. We defined the problem by asking: how might we enable providers to perform a medication reconciliation? There were three design goals to consider.
1. Define requirements for compliance with the Center for Medicare and Medicaid Services (CMS) standards for Transitional Care Management.
2. Design and test solutions with providers.
3. Complete mockups for development.
CMS Requirements
Working with stakeholders who managed senior health and population health, we obtained an understanding of requirements. Thankfully, the requirements were simple and clear: provide an attestation of who performed the reconciliation and when. However, different stakeholders wanted additional features that complicated the user experience. My task was to test the various recommendations with actual users and providers.
Nine moderated user tests with various types of clinicians.
Design and Test
Feature design was relatively straight forward, using patterns and components from the design system, such as a time stamp and a button. Collaborating with another designer and the product manager, we focused the design to include four separate features. Over two days, I conducted nine moderated user tests with three physicians, three nurses, a pharmacist, a physician's assistant, and a health coach. Tests featured clickable prototypes created in Figma, followed by semi-structured interviews. The four features we tested included:
1. A button to perform the action of “Reconcile,” with an associated time stamp.
2. A drop-down selection next to the “Reconcile” button allowing users to select a reconciliation type.
3. A banner indicating an annual past-due reminder.
4. A user details pop-over about who performed the reconciliation.
The tests took 30–40 minutes and were recorded via Zoom. Participants were not provided additional compensation or incentives for their time.
Features tested during moderated user testing.
Findings
Nearly all participants found the new features easy to use, simple, and useful. All participants reacted positively to three of the four features. However there was general disagreement among participants on the need to specify a type of reconciliation, such as between “Routine care” and “Post-discharge medication review” types. About half of the participants thought this distinction was unnecessary. Others thought this distinction was important.
Additionally, there was general confusion about the protocol governing how often the feature should be used. Most participants suggested that it should be used every time they saw a patient and nearly all said they would use it regularly. But subtle details about medication management suggested problems with regularly reconciling medications.
Mockups for Development
Given the controversy over the drop-down for reconciliation type, we cut it from the scope. Clinical advice indicated it was not necessary and the CMS standard did not require it. Though it provided value, we decided to revisit it in a future iteration that included an integration with different data sources (such as Surescripts). I then prepared an annotated Figma file for developers, marked "Ready for dev."
Figma file marked "Ready for dev" with annotations.
Launch!
It only took 2 months of development before we launched. After six weeks, with little internal communication, we saw an immediate adoption followed by a steady increase in usage, a 33% increase in usage over those first six weeks!
Though we could not correlate this feature with patient safety data, the adoption rate indicated that providers were eager to use this feature, not because it was required for CMS standards of care but because it was a necessary part of patient care in general.
Initial usage was a small proportion of appointments but increased steadily, 33% over 6 weeks.
The drop-off at Mar. 11 is due to incomplete data for the week.