Product designer (myself), product manager, tech lead, team of engineers
Problem
Urgent care clinics facing too many duplicate patient charts in their EMRs
Solution
Alert staff when there is a potential duplicate chart and provide a means to triage it
Outcome
9% of bookings were duplicates avoided for initial pilot partner
background
What is Solv?
Solv Health is a two-sided marketplace connecting patients to local urgent care clinics near them. Solv’s product suite includes a consumer-facing mobile app where patients can find and book urgent care appointments near them; as well as B2B software that helps urgent care businesses, from SMB sizes all the way to enterprise level, optimize their clinic’s workflow.
Definitions
I’ll be referring to these terms frequently throughout the case study.
EMR
Acronym for Electronic Medical Record. Digital database of of all patient records in one practice. Contains the medical and treatment history of patients.
RPA
Acronym for Robotic Process Automation. Streamlines workflows by performing repetitive tasks. Solv’s EMR RPA moves patient information from Solv into the clinic’s EMR by utilizing the patient’s demographic information to match to an existing patient record.
EMR RPA match criteria risks
If the match criteria is too loose, it runs the risk of matching to the incorrect patient, resulting in major HIPAA violations for the practice. If the match criteria is too strict, it runs the risk of creating duplicate patient charts in the EMR. Solv has erred on the side of stricter match criteria utilizing “exact match” in an effort to avoid HIPAA violations. However this has led us to the problem we are trying to solve...
Project overview
Problem
Because of it’s strict match criteria, Solv’s RPA is creating duplicate patient charts in urgent care clinic’s EMRs. Duplicate patient charts must be manually reconciled by the urgent care’s front desk staff, this is a costly, time-consuming process.
Solution
Introduce a prompted manual intervention before the new patient chart is created. This will allow urgent care front desk staff to intervene early on preventing the creation of duplicate charts.
Objective
Our overall objective with this project initiative was to improve partner Net Promoter Scores (NPS) and ease partner tension. Prior to this we had at least two partners had requested to disable their Solv RPA’s, creating a missed opportunity for Solv to demonstrate value. We also had one partner threaten to churn as too many duplicate charts posed a patient safety risk for them.
Constraints
Limited engineering resources One of the best practices is to employ probabilistic matching (which could account for nick names, misspellings, or typos). However, rewriting the RPA’s match criteria was out of scope for the time being.
Time constraint In an effort to ship a workable solution quickly to unhappy partners, we were aiming for a low-lift minimum valuable product solution.
Outcome
In just the first five days of rollout, 20% of bookings were successfully prevented duplicates for our initial pilot partner. We measured this by tracking how many times a booking was either assigned to an existing chart, or had been reconciled and re-triggered.
Process
User personas
Due to the nature of Solv’s two-sided marketplace, this product improvement would affect more than one of Solv’s personas. Although Faith would ultimately become the end user of this feature improvement, a lot of important product decisions considered the motives of our Chris and Mary personas as well.
Mary
Mother, urgent care consumer
Patient safety issue for Mary
If a duplicate patient chart is created when a chart already exists, the provider will not have historical context on the patient and may make potentially detrimental medical decisions.
end user
Faith
Urgent care front desk staff
Operational issue for Faith
Patient chart errors are often discovered during Revenue Cycle Management when insurance claims are denied due to incorrect patient information. The clinic’s billing team must have Faith reconcile EMR records when errors are found which can become an intensive manual process.
Chris
Urgent care CEO/Owner, decision maker
Cost issue for Chris
A 2018 study found that it can cost an organization approximately $50 - $96 per duplicate record, which includes the cost to reconcile records and re-file the claim. One of Solv’s partners even has an entire team dedicated to resolving duplicate charts.
decision-maker
Design rationale
Problem
Rationale
Feature requirement
Problem
Costly for our urgent care partners to reconcile patient charts during the Revenue Cycle Management stage.
Rationale
Provide opportunity for chart reconciliation to happen earlier in the process before it becomes a costly, time-consuming effort.
Feature requirement
Locate within Patient Queue Management stage
Problem
Solv’s RPA is not yet smart enough to automate decision-making that should be done manually.
Rationale
Faith knows the ins and outs of the clinic’s patients and operations. Rather than automatically creating a new chart when an exact match is not found, defer to Faith for next steps.
Feature requirement
Workflow-integrated alert
Triage modal with clear next steps
Problem
Existing implementation usability issues:
Lacks transparency
All integration errors displayed with the same hierarchy, making it difficult to decipher between higher and lower priority errors
Lacks an in-app solution to triage errors
Rationale
The UI should accurately reflect the integrations conceptual model or how it operates under the hood.
Feature requirement
More nuanced representation of integration operations
Differentiation between higher and lower priority errors
Actionable, easy-to-learn triage process
Rewriting the RPA workflow
Our first course of action was to rewrite the RPA workflow to discontinue automatically creating new charts. The new proposed workflow would instead notify Faith of any bookings that did not have an exact match to an existing patient chart.
Existing RPA workflow
Proposed RPA workflow
Establishing the transfer conceptual model
Using information from the Development team’s technical deep-dive, I mapped out a diagram of the transfer process, distinguishing between the nuanced transactions that made up a transfer and their order of operations. This would help me inform the UI design to accurately relay this conceptual model to Faith.
Transfer process diagram
Holistic user flow
Once I’d obtained an understanding of the conceptual model I could then piece together the holistic user flow, marking Solv’s automated RPA tasks and when manual user intervention was needed.
Holistic user flow
How will this look from Faith’s perspective?
In the case where Solv’s RPA cannot automatically establish a link to an EMR patient chart, we will need the urgent care’s front desk staff, or our Faith persona, to intervene. To illustrate what this experience will look like from the user’s perspective I mapped out Faith’s user story within the context of her daily patient management process.
Faith's user story
1
Faith signs in to Solv to begin daily patient management
2
Faith navigates to the Queue to see bookings scheduled for the day
3
Faith sees a booking for Jenny Douglas with an “EMR transfer pending” error
4
Faith clicks on the error message opening the patient facesheet to the EMR transfer tab
5
From the triage modal, Faith knows she needs to establish a link to an EMR patient chart
6
Faith goes to the clinic’s EMR software and searches the database for that patient
7
Faith finds a patient named Jennifer Douglas with the same birth date, phone number, and address
8
Faith can assume this is a patient match and pastes the corresponding patient ID into Solv’s triage modal
9
Faith selects “Resume EMR transfer” and a link is successfully established. A duplicate chart has been avoided!
Solutions
New UI intervention integrated into Faith’s daily workflow
A significant part of Faith’s responsibilities involve patient management, including tasks such as patient check-in, verifying insurance information, queue flow, and more. All these functions can be done in Solv’s software via the Queue. Here, Faith is already accustomed to finding and resolving errors related to address validation, so naturally it made sense to align with existing patterns and place the EMR transfer alerts within the same footprint.
Queue
Showcasing Solv’s integration functionality
EMR integration is one of Solv’s major differentiators. This call for more robust EMR product functionality served as an ideal opportunity to increase visibility around the power of Solv integrations. Previously, EMR transfer errors were contained to a tiny footprint within the patient facesheet header. There was a need for a new, more distinct, in-product solution encompassing all things EMR integrations-related. We decided to create a new tab within the patient facesheet dedicated to EMR transfers.
Facesheet header (before)
Facesheet header (after)
New triage modal
Incorporating some of the design principles discussed earlier, the triage modal needed to guide users toward the appropriate course of action and convey the implications of each action. Clear messaging and radio selectors help users quickly diagnose and triage the issue.
Knowing that Faith’s all have their own unique workflow, the modal was designed to be flexible enough to accommodate several workflow habits. Some users may prefer to update discrepant patient information, while others may opt for a quick manual override.
Facesheet > EMR Transfer tab (transfer pending)
Multitasking interactions
EMR transfers often take 1-2 minutes to run. This is precious time that Faith can spend doing other patient management tasks. Faith can rest assured knowing she will receive toast notifications of live transfer status updates.
Facesheet > EMR Transfer tab (transfer in progress)
Secondary transactions dashboard
The secondary transactions dashboard is designed to reflect the systems image established previously. Once the initial patient link has been established, Faith will see the corresponding EMR patient ID number as well as the status of all secondary transactions and when they occurred.
Facesheet > EMR Transfer tab (transfer successful)
Self-service troubleshooting
While Solv strives to maintain a reliable RPA, some unforeseen circumstances, such as a clinic’s EMR temporarily going down, may cause the RPA to lose connection. In these circumstances, secondary transaction failures may occur. Now, Faith has the ability to resend the transfer or manually move information into the EMR and dismiss the error.
Facesheet > EMR Transfer tab (media transfer failed)
Designing for resilience
While not ideal, there is the possibility that Faith may mistakenly match a patient to the incorrect EMR patient chart. In this case, she’ll need a way to sever the one-way link between Solv and the EMR. While this will not undo any transfers that happened previously, this action will stop any more information from transferring to the EMR.
Facesheet > EMR Transfer tab (unlinking)
Providing historical context
In the event that a situation like the above occurs, historical context will be important. This will allow Faith to retrace steps of the transfer history and, if necessary, correct information in the EMR.
Facesheet > EMR Transfer tab (status history)
post-launch
Impact
In just the first five days of rollout:
20% of total bookings were successfully prevented duplicates
Of bookings that would have had new charts created prior to the product update, 70% would have been erroneous
Cost savings of approximately $3,850-$7,392 (based off of $50-$96 cost per duplicate record)
Takeaways
The technical deep dive was crucial in shaping my understanding of how integrations operated and therefore impacted the designs as well. During our project team retro, we recognized that performing the deep dive prior to active development would have been far more efficient, saving us considerable time on iterating and leading us to the best solution faster. Moving forward, I’ve learned technical projects such as these require collaboration with the eng team and/or tech lead earlier in the process prior to designing to “get a look under the hood” so to speak.
As a team, we struggled to balance Minimum Valuable Product with timeline urgency leading to a lot of scope creep. Relying on incremental phases helped us better manage this balance and ultimately work towards a better overall experience.
