Mounika Konidala 

SUMMARY:

EOB is an explanation of benefits statement sent by a health insurance company to covered individuals explaining what medical treatments and/or services were paid for on their behalf. For our EOB statement, we have a very good (92%) NPS score, but unfortunately, we receive a lot of calls from users to understand the statement.  As a response to the high volume of calls received from customers, I built a team to analyze the reasons behind it and define user requirements to reduce the no of calls come into the support center. I conducted research from user interviews to prototyping and usability testing, I helped shape the user vision and execution of user requirements aligned with the business goals.

 

THE CHALLENGE

We realized our explanation of benefits statement were problematic and we receive a huge volume of calls to our customer service with a lot of questions. They were confusing to read; it wasn’t clear how much was due, when it was due, whether or not you were behind on your payments, or what to do if you needed help. So we got high-level support and set out on a journey to redesign our EOB using a human-centered design process.

 

TEAM

Our team consisted of designers, content writer, market analyst and me. Each team member participate in all activities, and I paid special attention to developing our strategy and optimizing copy

 

Our objective:

to create a more legible, understandable, ‘less terrifying’ EOB statement and reduce the volume of calls we receive on that topic

 

PROCESS:

1. DISCOVERY

1.1 User Interview:

To kick off our project, our team of designers and writers did some guerrilla usability testing of the existing EOB with internal employees (who are users to our insurance). Usability issues were widespread. For example, no one realized this is not a bill, who’s the provider, and the next steps they have taken after receiving the statement, and what they have to do if there are a denial and bill date didn’t draw people’s attention. We learned about many problematic terms, like ‘codes used in the statement,’ that cause confusion.  

We also spoke with the phone and in-person customer service representatives who help our customers with questions; they had many insights for us.

 

1.2 Survey:

We then realized our customer support representatives have so much of information to share with us. So we decided to have a broader audience response and conducted a survey with them

 

We received a response from 200 customer support representatives who shared their thoughts on the current design and type of questions from users or user concerns in the current design

 

Survey Process:

Step 1: Determine the research objectives: In this step where I have analyzed the goals and what type of data do we need to understand end-user challenges. I have created a research plan based on the kick off meeting and shared it with stakeholders to show the plan.

 

Step 2: Recruiting: This step is challenging as we have some constraints on the type of people we use for the research sessions. I went back and forth with the member service teams to get a solid list of people with different health plans and dental plans. I have a major break down for the dental and health plan because of a slight variation in the EOB statements that we sent it to end users

 

Step 3:  Write the first survey draft

I always believe that iterating and testing the survey before sending to a larger sample size helps me to achieve the desired results. Before showing the survey to anyone, I created a survey checklist to make sure the questions I asked makes sense to the participant. Here are a few things that I'll keep in mind:

• Group similar questions?

• Are the questions appropriate for the audience?

• Are the questions easy to understand?

• Did I avoid questions with two concepts?

• Are rating scales balanced?

• Do I include “don’t know” options when relevant?

• Did I practice this survey before sharing it? (ideally with a smaller sample size?)

• Did I keep my participants in mind throughout the whole survey design?

• Did I avoid double negatives?

• Have I used open-ended questions?

• Have I asked why?

 

Step 4: Send the survey to participants

I used a SurveyMonkey tool for this research session and shared it via email to participants.

 

Step 5: Wait for a couple of weeks to see the number of responses I receive from participants. I have received a 90% response rate within a couple of weeks from participants and this tells me how our customer support people desperately need a change in our EOB statement

 

Step 6: Analyze the data 

As I have a combination of both Qualitative and quantitative data, It took me a week to analyze the data and provide a readout to the stakeholders.

 

Results from Survey:

 

The amount of the data related to the lack of explanatory text around the claim numbers and denied claims. Here are a couple of high severity issues:

 

1. The highest percentage of calls received from customers are on “Type of Service” and “Denial codes”.

2. Users reach out to customer service with a lot of questions on “Notes at the bottom” and “The claim details table” sections.

 

 

2. DEFINE

2.1 Brainstorming session with stakeholders:

We then gathered inspirational examples of EOB statements we liked from our competitors and posted them up on the walls of our studio. We also took a detailed look at some articles provided on the EOB statement on the internet.  

 

Insights & Strategy:

One of the biggest problems customer service folks described is that customers have a huge confusion in the type of service we mentioned in the statement.

- For example, we mentioned a lab visit, office visit as a surgery in the type of service section which confuses users.

- If there are 2 claims on the same statement, it’s hard for users to understand which claims belong to which date, but it causes endless confusion for users.

- When we send EOB's before we processed the claim and after processed stage, then our customers don’t understand why they receive 2 statements for the same bill.

- Patients often receive two bills for the same visit or service: one from the “Hospital” (for anything related to using the facilities, like lab work or costs related to staying at the hospital) and one from the “Insurance” (claim explanation.)  This confusion can cause patients to call us to confirm the details on the statement even though we mentioned it’s not a bill. 

 

Here is the EOB statement with multiple claims — you can see why people get confused, especially if these bills arrive in the mail at different points in time:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

- The print is too small

- Hard to read and scan the content 

- Claim number and ID number didn’t stand out 

- It's not clear if the claim is denial 

- Font & contrast issues; our font was too small for low vision folks

- Language inconsistency & insurance jargon; “Coinsu ; Copay” was especially confusing

 

I can not share some important other insights due to the NDA process

 

Quotes:

 

"One common question about EOB's is it states the type of service as 'surgery' and the member calls and asks what that is and it is always just for blood draw but seeing surgery on the EOB concerns them.”

 

“One of the biggest challenges is what the charges were for their services. This is especially true for our members who go to a lot of doctors for a lot of different things, it becomes confusing to them.”

 

3.DEVELOP

I have enough data to come up with a prototype that satisfies our end user and as well as our organization goals

 

Design strategy

- Start with a summary of key numbers; follow with the details

- Use color and contrast to call out the most important elements

- Make the EOB statement less terrifying and clear details

 

3.1 Prototyping and sketching:

Armed with our insights and principles, we went back to our studio and started sketching up quick prototypes. We kicked off by running a two-day ‘design sprint,’ a focused period of time in which we create a prototype, test it with real people and learn from it. We spent a day brainstorming and sketching out concepts based on our prior research and insights. 

 

After consolidating our favorite ideas, we are in the process of having a discussion internally to implement the new design and how it works in the real environment. we have cycled through many more versions of design during the brainstorming session with stakeholders

 

Key features of the new design include:

• Strong use of color to identify ‘type’ of service and claim details 

• 'This is not a bill' statement and date of service are strongly highlighted with color

• Account summary is better highlighted

• ‘Next steps in the process’ is clearer

• Font size and contrast were increased throughout

 

Result: People like it!

 

We’ve had very positive feedback from the stakeholders when they first saw the new design. The following quotes are from three different people:

 

- "So much better! Easy to scan, more friendly."

- "It’s easier to read and understand."

- "I like the summary. It’s easy to see how much is due and what to do as the next step."

 

Next steps

Work in progress! Our next step is to conduct a prototype testing with end users to make sure if they understand the information and easy to read.

 

And in parallel, We’re currently in the process of working with our claims department to bring this new bill design to life. This is one of the most challenging parts of the process because it depends on coordinating many diverse groups of people — in addition to our claims department who creates and mails our bills, we also need to work with the printing and need to change our current printers to give life to our new design.

 

We are keeping our eye on the ultimate goals of reducing confusion, making our bill less terrifying, increasing our rate of payment and reducing the number of folks we send to collections. We can’t wait to share the final design once it’s launched.