I want to comment on an old article from Modern Healthcare (December 2014) regarding the problems insurers were having with provider directories for consumers. I am usually symapthetic to insurers complaints that the biggest issue with provider directories are providers. Providers tend not to respond to information requests unless claims payments are under threat, and directory data is almost never tied to the payment of claims. However, there is one insurer in Utah whose problem is a horrendous data structure where perfect information from providers will still produce piss poor directories.
I’m professionally pissed as I spent most of my early insurance career working on provider plumbing. This is basic stuff:
Josh Nelson, vice president of provider network development with Utah co-op Arches Health Plan, said the company’s software differentiates doctors by tax ID number. But doctors often use the same number across different practices, and Arches sometimes wants doctors to be in-network at some locations but not others.
“There are a lot of cardiologists in the Salt Lake Valley,” Nelson said. “We don’t want them all. But if we choose those few that operate in Park City, the system enters all the locations they practice in. … it defeats the purpose of a narrow network.”
I am seeing several big problems here in these two paragraphs. The first is that individual providers do not seem to have their own unique identifier. It seems that their model is based on contracting with a tax ID (TIN) and then assuming every doc only works at a single TIN. A large percentage of providers will work at muliple TINs.
For instance my kids’ pediatrician works at ABC Kid Care during the day, and moonlights at the local pediatric hospital ER one weekend a month. He can and does bill for work done at both tax IDs, and Mayhew Insurance pays him differently for the work depending on what TIN he uses. A friend is a CRNP, she works at a local PCP office during the day and does Monday-Wednesday evenings at the local urgent care. These scenarios are common.
Secondly, they are not creating address level/door level intermediate level IDs. A doctor can work at multiple Tax IDs at multiple offices. My orthopedist works at his private practice which has two distinct offices. One is in the center of the region, another is in the North exurbs. He also works at the major local teaching hospital. That hospital has two seperate teaching clinics that he is involved in. One is located at the East Campus, while the other is located in the main campus. He works at four seperate offices for two seperate tax IDs. This should be accounted for.
Finally, it does not seem like there is a product differentiator for each provider-TIN or provider-Site-TIN combination. This is basic stuff, and I have minimal sympathy for Arches Health Plan because they were building from scratch and did not have to retrofit narrow network slice and dice assumptions atop of previous broad network plumbing so that both systems could work at the same time.
They could have built their system from scratch and done it the right way.
RSA
It sounds as though they did not do even a minimal amount of analysis before diving into the implementation of their system.
Valdivia
Though I rarely comment on them I always learn so much from your posts. Just wanted to say that and thank you.
WereBear
As a fellow database professional myself… don’t get me started.
WereBear
Strangely enough, few do.
It costs money and they are unknowing of how it all works. It’s like a boss of mine who would say, “Just slap these things together and we’ll have merged them!”
shawn
Good post. A little tip for folks, most insurance companies (at least the major one I work for) won’t do a standard printed directory because they become obsolete – especially from year to year (and partly for the reasons you gavein the post) – and people were using year old directories to find in network doctors and then getting upset to find they were now out of network. We can print a current list of say dermatologists but it comes with a disclaimer that is is only current for so many days. I can’t stress enough to people how important it is to check BEFORE you go to make sure that a doctor, even a known doctor you have been using with no problems in the past, is still in network. Staying In Network is so important in keeping you costs as low as possible. They still might not be actually low but going out of network is like getting a speeding ticket – you’re just giving money away for no benefit what so ever. It might suck to have to find a new doctor but it’s better than paying 2,3,5,10x the cost to go to your old one.
askew
This post basically sums up the never-ending pain in the ass that providers cause me in my job since I work with provider data all day long.
As a patient, this is why it pisses me off when I’m told that we should all manage our health care better by checking to see if someone is in-network or out-of-network. The directories are out of date, they change constantly and if they are wrong we still get screwed with an out-of-network charge.
The next health care fix the government should do is force insurers to make the network providers more transparent and to not change them throughout a policy year.
Davebo
@WereBear:
I’m with you there! Cheese and Rice! What is the first rule of relational database development????
You got your protons, you got your croutons, and you got your morons.
Richard Mayhew
@RSA: More likely, provider plumbing is arcane knowledge and directories are not seen as a core mission critical deliverable, so in the mad rush to get the Co-op started, it fell down the priority list. So the launch provider plumbing was a “Good Enough but not actually right” solution with the eventual intent of “fixing things” in a couple of years.
I’ve seen that happen at other points in my career and the “fix”is five year late, and has to deal with half a dozen functional but Rube Goldberg-esque work-arounds that solved immediate problems.
Richard Mayhew
@askew: Agreed on making networks more transparent, current and accurate (probable enforced through decent sized fines for avoidable fuck-ups)… not sure if making a provider stay in network for the entire plan year would be ideal — as it shifts more negoatiating leverage to the provider than it does not….
shawn
@askew: Richard alluded to this in the OP but providers often do things without updating the insurance company and we are left with bad information. The only thing we could do is call every provider every day to make sure they are still alive and not retired and seeing existing members and seeing new members. That is not practical. As I said (and I think we posted at the exact same time so you may not have seen) most of us don’t do traditional directories anymore for these reasons.
RSA
@WereBear:
“Wait, software costs money? But I just download whatever I need from the Internet for free.”
Right, I was forgetting how easy it is to under-scope a project in time, complexity, and money.
WereBear
LOL!
Walker
Ahh, schema design problems. So many stories. The games industry loves to retrofit schemas in horrible ways so that they do not have to migrate their DB.
Initially Ultimate Online had an attribute to track when a monster paralyzed you. But they also used it to temporarily paralyze you when you cast a spell, so that you could not cast spells infinitely fast. The problem is that the designers who first created the attribute wanted to make sure you could not get attacked while paralyzed, so any damage frees you. Which means that taking damage allows you to cast spells infinitely fast.
That exploit caused cursed items to become very, very popular.
Mandalay
@Richard Mayhew:
Completely OT, but I thought this conversation between Luis Lang – the former Republican with no health insurance but with serious health problems – and Harold Pollack was interesting. Not because it revealed anything interesting per se, but because Lang gave a first hand account of his misconceptions and problems arising from not getting health insurance.
It would be great if some enterprising Democrats could work out how to snappily explain what it took Lang a very long time to understand: that he was being shafted by the Republican state government of South Carolina rather than the federal government or the ACA.
askew
@shawn:
The problem ends up then that the patient gets screwed because the directory wasn’t updated. As long as the insurance company honors the in-network rates based on whatever the directory showed online as of date of service I’m fine. But, insurance companies make retroactive changes to these directories and fuck over patients when doing so.
J R in WV
@WereBear: I was a software guy for various types of activities for many years, and one of the parts of that I was best at was data modeling.
With two others we created a data model for environmental regulatory data. It was complicated. A data model for health care providers (one that doesn’t get into actual details of clinical data, at least) just doesn’t sound that difficult.
One of my best days was flying to New York for a vacation with Mrs J. We sat separately, and the guy I sat with had a Databases for Idiots book, which I had to ask about. Turned out he was working in an industry we had analyzed and implemented, and when I told him where I had worked, he spontaneously said, “You guys have the best organized, most available data in the country!”
What a way to start your vacation in the Big Apple! Maybe my best Airline travel ever…
Not being able to track people and their various addresses, that’s just weak. But then there are many really good coders who cannot organize data structures for beans. We did buy a good modeling tool as we started to rebuild new systems for the agency, which did make it easier, but still, even on a white board…. with “DO NOT ERASE!!” on it.
sigaba
Tax IDs/SSNs as primary keys must die.
OTOH they want a system where (1) a provider can belong to many different networks and (2) can identify himself in the paperwork quickly without having to remember 20 different identifiers. If you were designing the system from the ground up you’d have all the insurance providers harmonize their record identifiers. But that would probably be socialism :)
Richard mayhew
@sigaba: type 1 npi replaces SSN… Type 2 npi too unstructured so it does not replace tin/ein
@J R in WV: agreed, it is not too complicated, just requires time to think through all relevant scenarios
WereBear
@J R in WV: That’s the thing. It’s complicated, but not difficult, ya know?
BruceJ
Sounds like someones brother-in-law got the contract for database support because ‘i used access once upon a time, and can spell SLQ”…
Grumpy Code Monkey
@Davebo:
Don’t talk about relational database development.
Been there, done that, although not in this particular context. Have absolutely no desire to do it again.
Richard mayhew
@BruceJ: I am morbidly curious if they tried to do this in Excel with vlookups. If my hunch on how the data is structured is close to right, it could be done in Excel…,
And don’t knock Access, I’ve tortured it to do things that should never be done on a consumer database for mission critical functions…. Not wise but it worked well enough until it could be done right
lahke
PLEASE run spell check! It’s Separate! SepArate. SepARATe. That’s with “A RAT” in the middle.