Hey all! With Signal out the door and the spring healthcare conference circuit wrapping up, it’s time for another riveting round of MRF Processing Notes. 

I love a good food analogy, and this blog post will cater to the cheese heads out there. Specifically, Swiss cheese - a term we use to describe MRFs that are missing substantial contents of the MRF month over month. It retains the shell of a compliant MRF but with so many holes you can’t get the complete pricing picture for entities that matter.

Before we dive into some holey cheese, wanted to hit the March summary highs and lows:

1. Aetna and Cigna are back in full. In February, Aetna’s pricing content dropped enough to be noticeable and Cigna’s file was missing enormous amounts of data. Both are back across the board for March.
2. Horizon’s arrived. We blogged about Horizon’s underreporting back in the early days of our processing notes blogs. The EPO came in fuller in January and the Trad / Indemnity network looks a lot more robust for March.
3. BCBS VT, MedCost and others are suffering from Change. Change Healthcare’s MRF hosting is offline as they remediate their cyberattack. While I doubt MRF hosting service is what led to the issues, they clearly have bigger fish to fry until the 15th when supposedly all of their services will come back online. Curious to see if that includes MRF hosting. 
4. Zip files are becoming popular. This is not a good trend. We’re seeing lots of mid-tier networks shifting their compression format from .gz to .zip, which is a significantly worse format for large-file data integrity and irritating to work with in automation tooling. 

Florida B̶l̶u̶e̶ Swiss Cheese

Ignore how tortured the section title is - let’s get to the good part and see how Florida Blue has been pushing gappy MRF files for the past few months, despite the metrics for their network looking ostensibly consistent over time. 

We’d already talked about how Florida Blue’s MRF contents jumped off a cliff back in September with respect to unique EIN & NPI entities represented in the Blue Options file…while magically getting bigger in terms of unpacked file size.

Compare August:

To September:

Since then, we’ve seen some pretty big bounces in file size and price count. Here’s November:

Then a drop in December:

And back up February:

You’re probably wondering how a plan can generate 154 million followed by 390 million prices followed by 220 million month over month over month for the same provider set. So have we, and so have consumers of their price transparency disclosures.

Slicing the Swiss

From a size perspective, it's clear some data in the file is bouncing around. So let’s explore the Florida Blue PPO data in our data warehouse, where we can directly query the data via SQL queries, and see where the holes are. I set the lookback window to 8 months for this analysis, dating to the last month the Florida Blue PPO file had a seemingly representative unique EIN / NPI count.

‍

Let’s look at 99213, one of the most commonly billed codes in the US healthcare system, and a billing code most entities are eligible to be contracted for:

SELECT network_year_month, count(*) as hits from parquetrates where payer = 'florida-blue' and network_name = 'blue-options-ppo' and code = '99213' group by network_year_month order by network_year_month;

‍

Ostensibly, for Florida Blue’s entire PPO network in Florida, there’s only 2101 total contracted rates for 99213, dropping to under a thousand for several months and now just above that amount?

Another way to visualize the rate counts is by looking at the unique entities who are listed with a 99213 rate, month over month. Sorting all EINs in the file and comparing the first ten EINs month over month who have a reported rate for 99213: 

SELECT ein, count(ein) from parquetrates where payer = 'florida-blue' and network_name = 'blue-options-ppo' and network_year_month='202311' and code = '99213' group by ein order by ein LIMIT 10;

While it stands to reason some EINs might be left out, most entities in healthcare networks can bill visit codes, contracted rates don’t change that quickly, and reporting all contracted rates for all parties is required. So there's no reason a payer should be skipping 99213 for most entities in the file. By color coding the EINs that appear across multiple months, we can see how scattered and inconsistent the overlap is:

Only one EIN in the first 10 consistently appeared with an in-network 99213 rate over all three months - a great sign you’re looking at some holey cheese. 

Ok, final way to slice the Swiss - let’s hold a single EIN constant and look at code count for the entity month over month. And let’s pick an entity so big any reasonable consumer should agree should have full coverage in a PPO network - Orlando Health, ein 591726273, whose own ‘insurance we accept’ page lists Blue Options PPO as an in-network plan. (https://www.orlandohealth.com/patients-and-visitors/patient-financial-resources/financial-information-prior-to-care/insurances-we-accept/hb-insurances-we-accept)

The query looks like this:

SELECT network_year_month, ein, count(ein) from parquetrates where payer = 'florida-blue' and network_name = 'blue-options-ppo' and ein = '591726273' group by network_year_month, ein order by network_year_month asc;

‍

With this kind of sparseness and inconsistency, it is effectively impossible for consumers to understand pricing for one of the biggest healthcare providers in Florida by looking at Florida Blue’s latest MRF.

Takeaways

Now that we have hard proof Florida Blue is generating a Swiss Cheese MRF, it raises some questions.

How did Florida Blue build a system that generates an MRF with such inconsistency?

Internal theories include only documenting rates that had a paid claim in the previous month, only documenting rates that change month over month, and finally, perhaps just a bad bug for their MRF generation vendor. 

How do we get them to fix this?

We reached out to Florida Blue with this data and actually got a response from their PR team: ‘Thank you for letting us know about the data.  We will share with our internal teams.’ Will update this post with any details as we get them.

What does this mean from a processing and usability perspective? 

It means specific and targeted analyses (either at a code or entity level) for a payer like this requires converging data longitudinally across months in order to get to a usable data set. For our clients, it means we’re now having to retain old MRFs and pull and run data across multiple months whenever anyone asks for a data pull. In Signal, we’ve actively retained old months with higher data volume alongside the latest files to try and boost the hit rate for searches. 

And for readers, who might be asking “What do I do if I want pricing intelligence in Florida?”

Pragmatically, Serif Health has a complete library of Florida Blue and Molina MRF data dating back to January 2023, so if you’re trying to gap fill these plans for a benchmarking or entity analysis and we can provide historical data to help, get in touch. We can do a longitudinal pull across 2023 to help you try and answer questions.

Thanks for reading, and have a great March!

‍