I worked at a healthcare/telemedicine company. In the previous case study, I touched on a company goal to merge two products together.
The two products in question were:
The first feature we ported over was the medical chart/consultation note. Authoring medical prescriptions was next.
There were a few issues:
I started the research with identifying which roles were involved in the workflow. This process took longer than expected because the medical team was a large network with different processes and a hierarchy structure.
There were primarily two types of roles:
The steps for the workflow were identified in the diagram below:
The process of sending a prescription was handled by faxing the document to a pharmacy. It was surprising but it made sense considering the fact that the healthcare industry is old and archaic. Pharmacies across Canada were not standardized to accept any other specific type of form.
The project was centered around porting over the authoring process to reduce license fees so the focus was on clinician tasks.
I had constantly been told by the medical team how inefficient and tedious the external tool was. Since I had no access to any usage data, I performed research by speaking to the medical director and other clinicians.
Focusing on the specific steps for a prescription:
The information architecture and data model was organized as follows:
There were several sections in the interface:
Two layouts stood out during early validation phases:
Limitations in the technology didn’t allow us to confirm clinician and patient information automatically. I made this step first because it would potentially require the clinician to ask follow up questions.
It was critical because if any of the information was incorrect, a pharmacy could immediately reject the prescription and we would be thrown in a tedious back and forth communication cycle to correct the issue.
We needed to integrate with an external database that stored and maintained all the prescribed drugs on the market. This was where I learned just how many variations of a drug exist. (a lot). This added some trade-offs on the experience because we couldn’t fully control the data model or the searching interface.
Documentation from the drug database
Once the drugs could be searched and added, the dosage was the next step. I went through several iterations trying to design the dosage layout. The existing tool had an awkward layout, resulting in clinicians occasionally creating a workaround by writing the full prescription in the ‘additional instructions’ textbox. We wanted to avoid this because if they weren’t using the inputs as intended, then none of the data would be formatted.
I designed something functional, but wasn’t convinced it was good enough at this stage because the experience was too manual.
There was a sudden shift in priorities and the feature needed to be released as soon as possible. The wireframes created up until this moment were the final designs used to create the feature.
It was quickly built and being used by clinicians. I knew it wasn’t good enough because we didn’t reach feature parity with the existing tool. Several micro features that improved efficiency weren’t included.
It’s one thing to have a strong intuition about the issues, but the main challenge was convincing leadership to allocate more resources to the project.
I tested the experience in the hopes of demonstrating why it needed more time and effort.
I held in-person user tests with doctors and our medical director. I had clinicians go through several of the flows.
The result of the in-person tests were rough. Clinicians are typically concerned about reducing the number of clicks, and the live demonstrations showed just how cumbersome the process was.
The feature barely worked and every time we tested it, a new bug would show up. There was a mountain of outstanding technical and design issues, however we only had capacity to address major blockers.
One of the positives to releasing early was the data we were able to collect. We now understood to a better degree the number of prescriptions and time to complete.
The average time was 7.2 minutes. It might seem reasonable, but when put in context of an entire consultation, it was far too long.
Seven minutes for this single event was too expensive. It was a significant problem and raised by our medical team so I began to iterate on the solution.
Every step of the process could be sped up. This was important for clinicians because their schedules are packed back-to-back with appointments. If one went over time, it created a cascading effect. When it came to prescriptions, there were 2 steps that had the most potential to be optimized:
I dug into the factors that led to this decision. Clinicians reported having roughly 60 drugs they most commonly prescribed simply because people consult for similar reasons. There were two standard methods when selecting a drug:
Favourites list
A clinician would start from a search bar that would show results from their favourites list. The challenges weren’t so much on the design side, but rather the technical implementation. The technical leads were concerned with creating new databases for each clinician because it often resulted in bloated duplicated information and decided it was too expensive.
We had a hypothesis that there was significant overlap between every favourites list. We compared several lists and discovered there was an ~80% overlap. Rather than creating the tools to manage favourites for each user, we came up with an approach for a global list as a compromise.
The concept above prioritized results from the global list and showed a preview of additional information.
In order to create this solution, I back-tracked a few steps to fill in some missing parts in the product. Specifically, a patient medication list. The list needed to be accurate and up-to-date, so the table was automatically filled with information each time a prescription was created.
There was also a scenario where patients were prescribed drugs elsewhere and it was important to store this information for a complete record. I added little verification badges to differentiate between drugs prescribed internally vs externally.
The list was located in the patient's profile, and we could use the information to speed up prescriptions.
Once the list was created, I could display parts of it inside the prescriber interface so that it would give clinicians more information to help their decision making:
This would save a lot of time because clinicians could select a previously prescribed drug and adjust according to any new circumstance.
Concept for renewing a prescription
Filling out the dose
Auto-filling was the best way to make the process quicker. The most comprehensive solution would gather information from several sources:
Up-to-date medical standards
Clinicians use documents called Monographs that contain up-to-date drug standards. A deeper integration with the external drug database was required for this option.
Saved preferences
An individual favourites list. From the previous conversations with tech leads, this option was immediately off the table due to technical challenges.
A previous prescription
This option was the easiest. The functionality was included with the ‘renewing a drug’ concept above.
Concept exploring the idea of auto-filling from an external database
High fidelity mockup
Unfortunately, the majority of the improvements were not prioritized. The medication list was created but nothing that directly affected the prescription flow was built. The medical team was disappointed. I imagine it was a difficult decision for leadership to make.
Despite the wasted effort, the feature was still built and fully adopted by the clinicians.
Recurring license fees saved
New behavioural metrics
A lesson I learned from this project was the importance of progress.
I was put in a difficult position where my work could not be completed or implemented correctly, and there was no time to fix the mistakes. The quality of the product suffered from the overwhelming pressure to move on. It was deemed complete when the feature was functional without even passing QA.
It was upsetting to see the feature remain in a state that I wasn’t proud of. I had to change my perspective by accepting how much of a project is within my control and understanding leadership is constantly forced to make trade offs for the sake of the business.
However, progress was made and when the spotlight returns to this feature it’ll be ready.
