Caretracker
Patient tracking software that helps physicians keep track of their high-risk patients
Background
PBACO is a population health startup that helps physicians to provide better care for their patients and reduce their healthcare expenses. Thousands of our physician's high-risk patients are not being routinely seen, leading to untreated chronic illnesses and higher medical bills. Our organization's previous way of handling this issue was very inefficient, involving consecutive face-to-face meetings and paper reports that would often get lost. To solve this, we set out to create a streamlined solution that informs physicians of their high-risk patients and ensures that they have been properly seen.
My role
As product support manager, I was responsible for the user research, end-to-end interface design, product documentation and was the primary line of support for both employees and clients.
Features
Curated list of high-risk patients
Our company analyzes millions of lines of patient claims data and other sources to identify high risk patients. Caretracker displays these lists to practices for them to act on.
Closed-loop care system
Patients are handled through a system of scheduling, follow-ups and confirmations to make sure that each patient reaches each step of the process and doesn’t leave the cycle of care until fully resolved.
Built-in Management features
Caretracker was designed so that scheduling can be distributed among multiple users, from office staff to remote call centers. User activity can be monitored to a very specific level in real-time.
Data Upload functionality
Corporate customers have the ability to upload their own sets of patient data directly to the portal based on their own unique criteria for high risk patients.
Process
Early Project Work
Before I joined the project, the management team had difficulty getting stakeholder approval. Their proposed ideas only reflected internal workflows and didn't incorporate input from physicians and their office staff, who would be the primary users.
Early Caretracker mockup created by the management team
If we were going to get this project approved, we would have gain a deep understanding of our targeted users.
Identifying user and business needs
There were a variety of business and user needs that the Caretracker needed to meet. I conducted several interviews with leadership, department teams, physicians and office staff in order to get a better idea of their workflows.
These are some key findings that determined what we needed to focus on:
User Findings
Patients often cancel or don't show up to appointments
Scheduling patients is complex, and there are a variety of reasons why a patient does not show up for a scheduled visit. Patients will often go unseen for long periods of time unless the practice proactively follows up with them.
Practices have their own scheduling priorities
Every office has their own priorities that determines how they schedule patients. The tool needed to be able to adapt to several different scheduling preferences.
Business Findings
Current way of communicating with physicians is inefficient
The existing method of informing a physician of their high-risk patient involved lots of meetings and paper documents. As seen below, the process is time-consuming, inefficient, and ripe for optimization.
Difficult to measure work being done
There is no good way to track in real-time whether high-risk patients are being scheduled until several months after the fact when claims data is released. This is too long to wait, especially for high-risk individuals.
Work must be distributable
Physicians and their staff often lack resources to properly schedule their high-risk patients. The work must be able to be efficiently outsourced to other parties so that the patients get the attention they need.
Now that we knew what we needed to focus on, it was time to create a solution that would fit our business and user needs.
Planning
Users
There are three principle user groups that this product is designed for:
Workflow
We wanted to create a closed loop system, meaning that patients who are put into the software are systematically followed-up with until after their office visit can be verified. To achieve this, we created three categories to separate patients into: open, pending and closed, as seen below.
We used the general workflow as a blueprint when determining the interface. By necessity, the overall workflow increased in size and scale in order to accommodate the complexities of patient scheduling and tracking.
Finally, once we had all of the workflows mapped out, we decided on a navigation layout that would best fit everything in. It would be built as a section of our existing web platform for providers, which was already widely distributed.
Design
Sketches
Now that the research, main features and workflows had been figured out, it was time to create sketches and wireframes to give form to the project.
Layout sketches for Open tab and Update Status window
Sketches for data upload window
Sketches for statistics view and user roles
Development and Production
The approved workflows and mockups were given to external developers who we worked with over the next six months to build the Caretracker. There were two weeks left at the end for user testing, where several technical and workflow issues were uncovered. However, as we needed to ship the product, many of these issues had to be addressed in future version updates.
Closing Thoughts
Reflection
This was the largest project I had worked on to-date and I was really grateful that we were finally able to bring this to production and see it have a visible impact on getting more of our high-risk patients scheduled. Our initial production version wasn't perfect, but it was a vast improvement over the previous way of doing things, and it is something that will continue to improve with future updates.
Things I would've done differently
I would’ve incorporated user testing much earlier into the project. A few weeks at the end is very little time to identify and fix all of the issues that could come up, and this contributed to the project's delayed timeline. Of course, it's impossible to predict absolutely everything in the planning phase, but doing so would've saved a lot of time and met more of our user's needs from the get go. Nevertheless, these were valuable lessons that I've since incorporated into subsequent projects.