Last updated January 15, 2018
One of my favorite things to complain about in the last few years has been the dark patterns used by health insurers. Why?
The only thing scarier than maliciously designing a user experience that tricks a user into sharing their email contacts with you is designing an experience that tries to prevent them from accessing healthcare.
Dark patterns, dark algorithms, dark user experiences, what is that? You might ask. I will define them as the following for this piece:
Dark pattern - anything designed for malintention
Dark algorithm - an algorithm that is designed as a dark pattern
Dark UX - a user flow on the internet that is designed as a dark pattern
All of these patterns are designed intentionally, or if not, are the act of serious neglect. It was also super hard to aggregate these as recurring issues because there is no central place to discuss these issues and their prevelance, since sickness is taboo.
Ok cool, so how do these manifest in health insurance, you might ask? Here are a few ways I have aggregated from friends and colleagues. Keep in mind that if you can delay groups' of people's treatments by rejecting their claim and pushing them back even half a month, you, as a health insurance company, can save million of dollars a year. Your customer, whose employer or they themselves paid you in time, might be sick and in pain or dying, but oh well.
1. Making claim submission impossible or nearly impossible by hiding the claim submission page
I'd really love a good investigation into how health insurance uses dark UX to deny benefits, I say as I go into the developer panel to find the link to submit my claims since @UHC hid the button. pic.twitter.com/M4QXPb7lLg— JB Rubinovitz (@rubinovitz) December 31, 2017
Hey, it's me! I was trying to submit some claims last minute at the end of the year and the button disappeared. Since A/B testing is pretty common across industry at this point, and fairly easy to do, I am wondering how prevelant this is.
This is an example of dark ux, since it is hiding a button from the user so their user experience becomes: I cannot submit my health claims, instead of just letting them have healthcare.
2. Routinely denying claim submissions of a certain size
Every time Scott submits 5 months of claims at a time, half are denied. When he submits them monthly, they are all paid.
So, my laugh cry scenario here is that they statistically set/just have variables in the code base that say claims spanning a certain amount of time are denied. E.g.
# if number of months the claims span is greater than 4 if claim_month_span > 4: # set half of the claims to rejected rejected = claims[:len(claims)//2] # set the other half to accepted accepted = claims[len(claims)//2+1:] # YOLO. oh wow that's in bad taste, sorry. return (accepted, rejected)
OR there is some really terribly built fraud detection algorithm that is setting its sensitivity too high since there are no consequences for rejecting a bunch of claims for no reason. Also, guess who is going to get penalized by this heighted sensitivity? Your outliers, your sickest folks. It's actually very convenient for an insurer's bottom line to not pay that much attention to the algorithm's false positives here.
3. Saying the customer has other insurance and rejecting their claims
Every couple of years, I have to pay a bunch out of pocket and apologize to doctors when my insurance company decides that I have other coverage I don't have, and denies all my claims until I can ask them around three separate times to reprocess them.
Such denials would be devestating if I did not have the privilege of having savings, and would discourage me from using my benefits.
This is again something I wonder about being hard coded. I have no idea how they come to this conclusion, or if there's an algorithm that uses it to pad their bottom line.
If you have any insight into what is going on here, or have more to add, you can find me @rubinovitz.