What a year for healthcare price transparency! We’ve gone from an industry where identification or discussion of market rates was strictly and contractually forbidden, to one where rates data is public information, accessible to all (with a bit of processing help ;)). Excited to see how this impacts payer-provider contracting and patient decision making in 2023.
Serif Health continues to examine and refine data to identify quality issues, reduce noise, and ensure our customers can make great decisions with trustworthy information. Read on for details.
Key Highlights and processing notes for December:
- Taxonomy filtering available in our price dashboard and APIs
- Schema misuse leads to millions of ambiguous data points
- Erroneous modifiers in various MRF files
- Truncated leading zeros in TINs
Taxonomy filtering available in our price dashboard and APIs
We’re most excited to share the delivery of a highly requested feature from our customers - taxonomy filtering in all of our dashboard and API products. Building this feature required changing the processing pipeline, storage schema, API schema, and re-indexing all of our pricing data, so it was quite a lift, but the feature is critical for accurate price distributions and comparisons.
This is easiest to see with some visual examples. Let’s look at Optum Behavioral Health data in New York, for code 90837 - one of the most heavily billed mental health visit codes.
If we run a practice that’s exclusively prescribing physicians, and look at the data for 90837 without taxonomy filters, we would take a skewed viewpoint of the market, that the 50th percentile and mode reimbursement rate is $121.
Filtering down on NUCC Taxonomy code 2084P0800X - Psychiatry Physician, we see a median and mode of $161 - a substantial shift!
Much of the lower rate values come from 1041C0700X (Clinical Social Worker) and other taxonomy codes that, as we covered in our previous blog posts, have a tiered, lower reimbursement fee schedule set by the payers:
This new feature enables Serif Health to completely exclude rate data from NPIs whose taxonomy values are invalid and nonsensical, but appear in the MRF files (e.g. clinical social workers who have rates posted for CPT code 27447 which is a total knee replacement surgery). These are very common and documented by several different parties who've processed the MRFs.
Schema misuse leads to millions of ambiguous data points
As we ramped up our price file ingestion, we noticed that specific payers had rate counts percode that seemed excessive relative to the size of the networks (counted as unique NPI or EINs in the MRF file).
What we found with some payers (BCBS Tennessee, amongst others) was that their MRF files tended to list a single long array of negotiated_prices, and a single long array of provider_groups, instead of breaking these out into their constituent pairwise matches as dictated by the CMS schema.
For code 54900 (all professional fees, office visit, no modifiers), for example, BCBS Tennessee listed an array of 61 different negotiated rates and an array of 1799 provider groups. Most likely, different subsets of the 1799 provider groups should be matched to one of the 61 different rates, but with this data layout, the only assumption according to CMS’s schema is that all 1799 provider groups get each of the 61 prices - creating over one hundred thousand data points in Tennesee for a relatively rare procedure code.
For more common E&M codes, like 99214, this schema misuse would lead one to believe BCBS tennessee has millions of contracted rates in the state for this single procedure code:
We’ve reached out to BCBS Tennessee for comment on this, and to see if they can update their MRF generation logic to properly attribute rates to provider groups.
Erroneous modifiers in MRF files
One bug that’s had us chasing down raw MRFs this month involves modifiers. Specifically, modifiers that don’t make sense. We’ve seen several different payers write junk data into the modifier fields, causing us to fail to aggregate and index the information into distributions.
There’s the typical noise you’d expect from a data cleaning exercise - some BCBS associations are writing the string “EMPTY” into the field instead of leaving it blank:
Magellan is writing all possible values into the field as an array, rather than a price for each:
But the one that confused us the most was Florida Blue. When we didn’t see any BCBS rates in Florida for 99214 last month, we started investigating, and found that the payer appeared to be writing modifier “02” into every negotiated price block in their MRF files. There is no billing code modifier “02” that we can find documentation for; our guess is that this was intended to be written into the place of service code set to signify a telehealth visit but somehow accidentally wound up in the wrong field.
Again, we got in touch with the payer and are waiting to hear back.
Truncated leading zeros in EINs
One final head scratcher we tracked down to a source MRF issue - EINs with leading zeros seem to be truncated by various payers. One of our customers requested a competitive rate pull on EIN 04-*******. As we ran the extraction query, we got no results from several payers including UHC.
What we found when investigating this was that payers who handle the EIN field as a number (with the hyphen removed) are often dropping the leading zero from the number when writing it into the MRF file. Here’s a screenshot taken from a raw stream of UHC’s national P3 network file (last two digits redacted):
There’s six visible digits and we redacted two, but EINs can’t be 8 digits long - so for the other MRF processors out there, make sure to do a length check on the TIN and be ready to fix up missing zeros.
As always, if your healthcare organization can benefit from our market pricing data or our expertise working with MRF files, don’t be shy. Get in touch and book a meeting with our sales team today. We hope you’ll join us in a toast to a year of massive change in the healthcare industry - here’s to more transparent markets in 2023!
.png)
