CIGNA OPERATIONS: Data Capture 2.0
FULL PROJECT CASE STUDY | Cigna 2020
Cigna ingested claims information inefficiently as claims data was ingested after claims were paid off. At the time, complete, accurate, and timely data capture was a casualty of tradeoffs; if too much data was captured, it took too long, and cost too much. A technological solution was bought in to reduce such tradeoffs that would ingest claims data faster to more effectively progress claims that would reduce high costs. The goal as a UI/UX designer was to assist international markets with automizing Cigna’s claims ingestion process by creating an auto-populating form interface that users would validate claims data to cut down on ingestion time and accurately ingest the claims data.
DISCOVERY
RESULTS
Current User Flow: Users had an inconvenient work process where they first need to pull up an excel sheet that contains the currency format for every country. They referred to this excel sheet throughout the day to confirm the correct currency format. Then, they open the current data capture to transfer data manually from a non-readable PDF. If there are any issues during the data entry, they go and email the quality team for assistance.
Key Features that could make Data Capture 2.0 Successful:
Translations:
Non-transalated data / content is copy and pasted into google translate
Action options:
Complete, Hold, Pending, Auto-fill
Metric tracking of users:
User specialization:
Potential need for a guide:
Sign in, sign out, breaks: looking to capture time / productivity metrics
They have guidebooks for tools; may need to make one for data capture 2.0
Users are grouped by region to specialize in understanding regional data
(currency format, adress format, etc.)
Improvement Suggestions:
Auto-populated fields:
Some improvement suggestions from users that they would like to see in data capture 2.0:
More drop down selection fields:
Remove description field character limit:
Error Handling:
Incorporate Alt Code feature:
As users need to manually type out data, auto-populated fields would be ideal
Users wish to see more drop downs to avoid error & faster entry process
Description field currently has a limit of 250 characters. Often claims in Chinese are longer. This process can elongate data input time.
Data Capture 1.0 has features in preventing data input that may be off (example: billed amount). Insure that it is installed in data capture 2.0 as well with more fields with error handling features
Users currently need to google alt code options to use special characters / symbols. They would appreciate a feature that allows users to directly pick such characters / symbols
UPFRONT USER RESEARCH
The user research was conducted with caution as users were not aware that the majority of their job is going to be automized. To avoid causing fear of job loss, I conducted interviews with extensive prep with the UX research team. I was cautious of terminology and word phrasings.
The six user interviews were conducted with 45-minute sessions. As users were from India and not confident in their English response, their manager was also present.
Results concluded that the most crucial pain point was that the users currently have to transfer claims information from a non-readable PDF to an electric form manually. This manual process is prone to errors.
UI/UX GOAL
Assist DevOps in creating an interactive and user-friendly dashboard that is intended to monitor progress and determine where the major errors are blocking DevOps work.
TECHNOLOGIES
Salesforce Velocity, Figma, Zeplin
PROBLEM STATEMENT
INTENDED SOLUTION
In the past, complete, accurate, and timely data capture was a casualty of tradeoffs; if too much data was captured, it took too long, and cost too much. Technology can reduce such tradeoffs. Cigna needs such a technological solution that would ingest claims data faster to more effectively progress claims that would save Cigna high costs.
Capturing more data accurately will allow Cigna Global Health Benefits (CGHB) to improve affordability, demonstrate value to clients, become a whole health partner to customers, and win against emerging competitors. There is significant business value in capturing more data. My UI/UX role is to assist international markets with automizing Cigna’s claims ingestion process by creating an auto-populating form interface that users would validate claims data to cut down on ingestion time.
DESIGN
DATA CAPTURE 1.0
Below was how users were inputting claims data prior to Data Capture 2.0 project. The form lived in Microsoft Access. In this project, the majority of the features here were transferred to the Data Capture 2.0 work in addition to more data inputs & redesign of the interface.
REQUIREMENTS
the interface must be an auto-populated form
the interface must include a PDF view for data comparison with the claims document
the interface must live on Salesforce Velocity
must create claims form for all claim types (medical, pharmacy, dental & vision)
have action to:
(1) submit when complete
(2) Close to pause & temporarily exit (for meetings, breaks, etc.)
(3) Escalate claims with issues
POST-MVP
1. Statistics on user performance
2. Have a fixed header of information perhaps needed throughout the claims data entry process
3. Currency format & language translation incorporated into the interface
4. Dual monitor capability
COMPETITIVE ANALYSIS
We decided to go for a Turbo Tax feel of validating auto-populated data. I also looked into payment / registration forms to study designs around extensive forms.
Major Takeaways:
Steppers:
Form balance:
Data entry variety:
Required vs non required:
Indicate progress & awareness of form length; vertical vs horizontal design
There is a need for balance between not too many on each page vs not too many pages
There is a need for a bit of data entry variety (textbox, dropdown, etc.) enough to keep the user engaged but not too many that would tire out the user
There needs to be clarity around what information is needed in order to complete the claims form
Wireframing
Problem Solving with Design:
Top user challenges or changes vs design solutions:
Users have to transfer data from the PDF into the data capture interface manually as the PDF is non-readable:
Users have to physically switch between the PDF and data capture interface:
Users wish there was error handling:
Users have to refer to an excel with currency format information:
Managers of users want users to be aware of their own metrics (avg. time on claims data entry, etc):
The form was created to be auto-populated. Thus, the user’s job is to validate rather than data entry. Populated data with a low confidence level is marked to emphasize which data may need a closer look. The user has the ability to alter the data or input any missing data.
Incorporated a PDF view into the interface. As some users requested a dual monitor capability, we have designed the ability to have the PDF pop out as its own view. Thus, the user can drag the PDF view to create a dual monitor view.
Some restrictions were added to the form to help alert users of any possible error. An example is claims amount. The front end is designed to alert users if the number entered is an unusually high or low number.
An information icon is now placed next to any value amount data input to guide users on currency format.
The homepage allows users to access some metrics that would be beneficial in seeing their progress.
UI/UX Touches:
Changed terminology of action buttons:
In Data Capture 1.0, the action to “hold” indicated putting a claims data entry on pause due to an issue while “pending” indicated temporarily saving the claims data entry to go take a break, attend a meeting, etc. As the terminology is very similar and can get confusing, the action verbiage was changed. “Escalate” indicates escalating a claims data input issue to a manager. As the data would be auto-saved, “close” indicates temporarily putting the claims data entry on pause to return later. “By Pass” was added to pass through dummy forms that do not require much attention.
Added note-taking ability:
As users go through multiple claims data entries a day, recalling why certain claims were escalated can be difficult. We created a comment section in the fixed header to leaves any notes on recalling what the issue is with that claim.