Reading a Transparency File is NP Complete

[imoldfella]

An arbitrary function cannot be efficiently described by its inputs and outputs. The first batch of actual files proves this is not simply an academic observation.

Two problem spots that pop up right away when you read the files are provider groups and bundles. (5 million providers = 2^5000000 groups).

The file described "GA BCBS Georgia PAR providers in-network file 1 of 2" is 42GB, decompressing to 296GB. Much has been made of how large these files are, but the problem is they are small compared to what they reasonably can be! With pretty reasonable pricing functions, a very small program could stream a valid transparency file that wouldn't end. You could never download this file, let alone reverse it to the pricing function that we want to be transparent.

One way to follow the intent of the legislation is to ask insurers to present their actual pricing function in one of a set of open source languages. Empirically we know these functions to be small and efficient since they can process millions of claims per day. These functions are written in well understood languages such as Java and COBOL. The transparency files could remain as interesting test artifacts, but they are not able to make industry pricing transparent.

[shaselton-usds]

Open sourcing claims processing systems would be a massive, near impossible undertaking -- the task's complexity would be incredible and for the Transparency in Coverage regulation way out of scope. TiC isn't describing the function, but standardizing the outputs to be used as inputs for innovation "functions".

CMS' claims system is well over 7 million lines of code written in multiple languages ran in niche environments. It isn't a stretch to imagine that no two claims processing systems are the same either.

I've heard of a couple projects out in the wild where people are trying to build a universal claims adjudication system but it remains theoretical from what I've seen. I see more business problems with this approach than technical, but I don't know too much about it.

[jhstafford]

COBOL or Java are the only choices? Lol. There are claims systems running on things like MUMPS and Pick Basic to name just two that I am aware of. Good look writing those conversions.

[imoldfella]

I think the key issue is that what we have does not seem workable in the context of the goal of transparency. The goal is clearly stated as "no surprises"; we must be able to derive a computable function that can produce the price of a proposed medical plan of treatment. Anything else is certainly going to lead to surprises. This is required in 2023 in order to price shoppable services.

I'm not saying that it should have been obvious from the start that the current TiC files would not work. I certainly did not predict what I found and everything looked super awesome right up until we got the actual files. Many things are NP Hard in theory but quite workable in practice. But now we have a great weight of evidence it is harder to brush away by saying everything else is impossible too.

And there are many other approaches. We could enforce limits on certain loops. Another approach would be to use a virtual machine, as the W3C ending up doing with webassembly after a few different trials there. There can be combined choices; retirement plans are often presented as "safe harbors" where you avoid a burden of proof if you can adopt some simple rules. If you can't live with those simplifications, then you are compelled to show that your solution is practical. Yet another approach would be to provide an api so that concrete pricing questions could be posed as they came up. I'm sure CMS considered most or all of these approaches before, none of them are unique. I was certainly not suggesting limiting to Cobol and Java. Mumps is fine with me personally.

Props to all the good work that has been done, but let's not give up in fatigue and accept that this is the best we can do. If it helps to make the argument I would be willing to create the never ending transparency stream although this seems close enough