chartDoc
Patient Management Platform
Overview
chartDoc™ Patient Management Platform was designed to be an alternative healthcare solution for paper-based medical practices or practices that could not effort larger EHR systems. In this case study I’ll be focusing on the role of the front office staff and the design decisions I arrived at. It’s important to note that the solutions shown here were for an MVP to get to market quickly, and we made the decision to roll out in “dark mode” as a competitive advantage.
Taking notes on my iPad from the waiting area.
Observations & Interviews
For in-person observation, I had access to 2 medical practices that allowed me to observe the flow of patients (from the waiting area only) of their respective practices and also conduct 10-15 minute interviews with their front office staff members.
One practice consisted of two primary care physicians and the second consisted of eighteen brain and spine physicians.
Findings:
The two-physician practice only had one office location, whereas the eighteen-physician practice had six locations, but one was considered “the primary” location. This meant the receptionists needed to schedule a patient appointment with the right physician on the right day the physician was in a specific location.
The two-physician practice had two front office staff members with one or two medical assistants helping out in between getting the patients setup in the exam rooms (capturing chief complaints and vital signs) and refilling prescriptions. The eighteen-physician practice had six front office staff members, but their tasks were very focused and specific. Two performing just scheduling, two performing patient in-take and accepting payments, and two arranging procedures/scans, etc.
In both scenarios, a medical assistant would call the patient from the waiting area into the exam room. I also noticed they only used the patient’s first name when doing so, due to HIPPA laws.
Staff members who schedule appointments, refill prescriptions or schedule procedures spend a lot of time on the phone. Those refilling prescriptions or scheduling scans/procedures are typically on hold with the pharmacies or imaging centers for 10-15 minutes.
The process of receiving lab/radiology reports via fax creates tremendous overhead for the front office staff.
Practices that still call via phone to confirm appointments creates additional overhead for the front office staff.
Problem Statement
“Office staff are asked to perform multiple tasks while interacting with patients at the same time. Much of their time is spent both on the phone and computer while multi-tasking other physical responsibilities which can cause them to leave the main reception area. This constant multi-tasking can cause stress and burnout, and create long delays for patients waiting to see their physicians.”
Empathy Map
To keep the lens focused on the user during the ideation phase, I created an Empathy Map with insights from my observations and interviews.
Use Cases and Tasks
After my foundational research, I created a comprehensive list of tasks that the front office staff perform on a daily basis. I then converted these task into specific user stories.
Rapid Prototyping
Due to the speed of the project, I used rapid prototyping techniques. This was done with pen and paper, and allowed me to very quickly draw many different iterations of each screen. I would then compare them to identify areas that worked well, or rethink groupings of important calls to action (CTA).
Patient Flow
The Patient Flow screen is the first screen every users lands on after logging into the system, regardless of what their role is. It allows any user to drag and drop patients through the different stages of a typical office visit.
Patient Scheduling
Front office staff can easily show/hide which physicians they are scheduling patients for. Additionally, the patient appointments change color to match which stage they are in based on the Patient Flow screen.
Creating Appointments
Clicking an available time slot opens a modal window which easily allows the receptionist to schedule new patients, existing patients or block out time for a physician. Dragging an existing appointment from column to column automatically changes the assigned physician, office location and time slot.
Appointment Details
The Appointment Details screen provides all CTAs necessary to reschedule or delete an appointment, as well as CTAs for all actions to check in patients when they arrive at the office.
Checking Out
The Checking Out screen can be accessed from either the Patient Flow or Scheduling screens and notifies the front office staff if the physician has requested a follow-up appointment and the reason. Additionally it allows for practices that take payment post-exam.
Findings From Usability Testing
I was able to conduct task-based usability testing with 5 participants using InVision prototypes.
The findings revealed:
All participants found the minimal approach to navigation very appealing and had no issues finding the areas they needed to perform their tasks.
Two participants struggled because they were unfamiliar with a drop and drop interface. This could have been an artifact of conducting user testing with static prototypes, but it also made me redesign the drag and drop UI (add drag handles and drop zones) to be more obvious. Once we had a fully functioning prototype they found it very intuitive and easy to use.
On the scheduling screen, all participants did not pick up on the fact that dragging a patient appointment from one doctor’s time slot to another doctor’s time slot automatically re-assign which doctor/office location the patient was going to see. They all clicked on the appointment with the expectation of having to manually change the physician and/or location.
All users liked that they could complete most of their tasks from either the “Patient Flow” tab or the “Scheduling” tab, although this was not obvious at first. To alleviate this issue, I added first time “unboxing” coach marks to both tabs to make this more obvious.
Design Assets for Dev Teams
After comparing redlining and asset creation across Adobe XD, InVision and Zeplin, I felt that Zeplin offered the most accurate CSS with a very easy UI for the development teams to quickly learn and leverage.
Components Library and Style Guide
Although Adobe CC was the primary design tool for most of the project, I switched to Figma to build out the style guide and components library. The sharable design library, interactive and variant components, and multi-designer collaboration makes it effortless for any new product designer to easily work with.