Zocdoc Insurance Eligibility
Zocdoc Insurance Eligibility
̌
Zocdoc Insurance Eligibility
role
Product design, User research, Product strategy, Roadmap definition + prioritization
TEAM
Product Manager, UX Researcher, Product Marketer, Engineering Manager, Engineers (x7), QA
timeline
October — December 2021
January — March 2022
Background
Zocdoc is a healthcare marketplace that helps connect patients with qualified providers across a range of specialities. Our patient-first approach has created a more accessible and personalized healthcare experience for millions of patients across the United States.
Overview
When we launched our Payment product in June 2021, we did so with the intention of creating a product that facilitated all of a practices’ pre-appointment needs within a cohesive system. Following the launch of Payments, we recognized that practices still needed to leave the Intake/Payment flows to verify patients’ insurance eligibility, coverage, and benefits—necessary pieces of information to determine payment obligations (copay, deductible, etc.) for their visit. Practices typically use third-party tools to do this; however, they find these workflows to be cumbersome and the interfaces outdated.
OPPORTUNITY
Adding insurance eligibility checks to the Intake/Payments products could increase utilization of these tools while providing practices with a single system for all of their pre-appointment needs, as this feature would directly output what is owed by the patient for their upcoming appointment.
Challenge
How can we create a feature to facilitate insurance eligibility checks within our existing Intake and Payment products?
Business goal
Establish Zocdoc as a legitimate player in the pre-appointment space
User Goal
Create a single system for all of our beta practices’ pre-appointment needs
Round 1: Generative Research
Goals
Gain a better understanding of the pre-appointment workflow for practices when it comes to insurance information, so we can design the right inputs and outputs for insurance eligibility checks.
Methodology
1:1 interviews with 6 practice users from practices that accept insurance
Learned about their overall insurance eligibility process
Assessed inputs and outputs needed for eligibility using lofi designs
LOFI DESIGNS Tested
What we found
Practices generally follow a similar process when it comes to insurance eligibility
The inputs and outputs practices must have and that are nice to have
Practices looked to get basic identification information (patient name, DOB) and insurance information (carrier name, member ID) to check eligibility; however, collecting this information ahead of appointments is a source of stress for most practices.
““Especially for patients that book late, it can be a race against time to check this information. It can be especially hard when the patient is in the actual waiting room as you are trying to get this information””
Platforms practices currently use can cause usability frustrations due to their outdated and non-user friendly nature
““I pretty much just can’t stand Availity and Navinet. They’re not user friendly and keep getting more complicated. If there was a simpler way to do this, I would probably be more apt to do it before sending it to the biller.” ”
Round 2: Evaluative Research
Our first round of research indicated that in order for us to become a part of practices’ insurance verification processes, we need to not only provide proper inputs and outputs, but retain the ease and usability of the Intake.
That said, I conducted a round of evaluative research of a proposed end-to-end experience within Intake, in which participants would review intake information, run an eligibility check, and send a payment request to a patient. In doing so, we aimed to understand practices’ needs, expectations, and impressions of this experience and how it could impact their existing insurance verification workflows.
Methodology
1:1 interviews with 5 practice users from practices using Intake that accept insurance
Briefly discussed their existing insurance eligibility process
Evaluated their impressions and reactions to proposed designs via a usability test
Designs Evaluated
Task #1: Viewing Intake information + Running an eligibility check
Task #2: Requesting a payment
Synthesis in Miro
Interview Summaries
Current Insurance Verification + Eligibility Workflows: Themes + Learnings
Design Evaluation: Reactions + Feedback
What we found
Practices rely on a series of systems/tools to run verification and eligibility checks—there is no single source of truth.
Practices are comfortable with their current workflows, but relayed a willingness to try something new as long as it could decrease the amount of time spent on this workflow, reduce the amount of systems/tools involved, and provide accurate information.
The timeline of when checks occur varies, but is deliberate, as practices want to make sure the information is as accurate as possible for the patient’s visit.
Eligibility checks and copay collection are not necessarily conducted in a linear workflow, as practices prefer to collect copays either the morning of the appointment or right after the appointment, in case the patient cancels or no-shows.
Information accuracy is a key priority for practices, noting that some carriers only trust claims that came from their respective website and that our system may not be the only one they use for these checks.
Practices viewed our proposal as a supplementary, not centralizing system. Though they loved the concept of this system, practices noted using it as a supplementary system if their EHR or the insurance websites didn’t render clear results, rather than it being their only source of truth.
What this tells us
Despite some friction, practices are very comfortable in their existing workflows.
They were excited by this concept and the potential of having a more centralized system, but questioned the accuracy of the information we’d provide, the use cases it could cover, and if this would really reduce the number of systems they use.
Post-Research
Following the research, it was clear we needed to better understand and identify what specific user pain points we could solve with this feature so that we could determine the best way to drive adoption. Due to delivery deadlines, my product manager took on the task of clearly identifying the feature’s value props and goals as I began incorporating feedback into the designs.
Designs
Kicking off insurance verification
Once a patient’s insurance cards have been submitted, practices can kick off eligibility checks from within the patient details view in the Intake hub.
Entering patient information
The patient’s name and date of birth would be pre-populated and the practice user would be required to fill in the other information in order to see the report. In future phases, we plan to leverage optical character recognition (OCR) to automatically extract information from the patient’s insurance card to reduce the chance of manual input errors.
Coverage and benefits report
Once the patient’s information is entered, practices can view a robust coverage and benefits report, highlighting plan information, patient and subscriber information, and coverage details—all details we heard were critical for practices.
Requesting a payment
Practices can request payments from patients directly from within the report. Based on our research, in future phases, we planned to surface this information in other areas of the product and add in the ability to schedule a payment to be sent on a specific date, as we learned that the moment when practices are checking eligibility isn’t necessarily the same as when they want to send a payment request.
Product + Use Case Pivot
As my product manager was identifying value props and better defining product goals, we received a request from company leadership that completely pivoted the focus of the project. Leadership requested we make eligibility checks available to every practice on Zocdoc, with the hope that this would improve the quality of bookings received on our platform. “Booking Quality” would now be a core company focus in order to decrease the amount of canceled appointments, often caused by the practice not being able to verify patients’ insurance information received from Zocdoc at the time of booking.
Considerations
We had designed this feature only for the Intake/Payment use case
All of our research thus far had been in the lens of the Intake/Payment use case
The team building out our eligibility API flagged that they would not be able to output the full eligibility report we had tested in research—information which was viewed as critical for Intake practices. We would therefore have to abandon going after the Intake/Payment use case entirely
Based on the API spect, only the top 3 carriers (Cigna, Aetna, and UnitedHealthcare, which account for ~40% of Zocdoc bookings) would be eligible for these checks upon release
We would need to redesign the entire flow for the Zocdoc marketplace use case
We would likely not have time to conduct more research prior to releasing this feature due to deadlines
(New) Challenge
How can we create a feature to facilitate insurance eligibility checks for all appointments booked on Zocdoc?
(New) Business goal
Improve the quality of bookings on Zocdoc
(New) User Goal
Reduce the number of cancelled and “no-show” appointments
Current Product for Zocdoc Marketplace
Rather than kicking this flow off in Intake, it now begins in the appointment card on the practice’s calendar. The appointment card is where practices are going to confirm appointments, view patient details, and gather insurance information—so I felt it would be an appropriate place for the eligibility flow and information to live.
Automatic Eligibility Checks
For appointments booked with one of our accepted carriers and with an available member ID, an automatic check can be run at the time of booking and will show as “Active” or “Inactive.”
Viewing a Report
Practice users can view an existing report by selecting “View report” from within the appointment card. Note that this report shows less information than what we had originally tested due to constraints in the API.
Manual Eligibility Checks
For appointments where the patient’s insurance coverage could not be automatically verified, practice users will be able to manually run a check by selecting “Request eligibility.”
Running or Updating a Report
In running a new report or updating an existing one, practice users will be able to enter and update all of the appropriate inputs. To reduce the amount of errors from manual entries, we will pre-fill as much of this information as we can.
Performance + Impact
In late May 2022, we launched this feature in an A/B test. Between the test and control groups we saw…
…but there is still more work to do
In sharing these designs with enterprise clients in an unrelated round of research, we received feedback similar to what we heard in our original research with Intake practices: While reception to insurance information and “active” status was positive, many felt without more details on deductibles and copayments, this would not really impact their workflow or save them time.
““You did the work for me! This is perfect [...] but that’s not enough information. It doesn’t have a deductible, copay. We still need to use Availity. It’s nice to look at, but I still need to use my portal.””
What’s next?
Working with the API team to expedite surfacing the missing information (patient and subscriber information and coverage details) into the eligibility report. Once this occurs, we can bring this feature into Intake, hopefully using it as a driver for both Intake and Payment adoption
Takeaways
When developing a new feature, it is critical to determine product goals and values early on
Alignment across all key stakeholders is necessary for successful product scoping
The product development process can serve up many challenges, making it even more important to advocate for the best user experience
Research acts as a strong source of truth for why we should or should not pursue something
