Billing code reference groups

[jleberre10]

Hey, I posted about this in the Q&A section, but I think it's better suited for here.

The point of this idea is to reduce duplicate data when it comes to printing large groups of billing codes. In some contracts, many codes are bundled with the same very large group of other codes. For example, many codes can be bundled with every code of a different code type. That means that duplicate data is printed every time the list of all of these codes has to be printed for the bundled_codes array an In-Network object.

A schema change allowing the bundled_codes to reference a group of codes very similar to how provider group references work could drastically reduce file size for build that bundles by code type.

At the top of the file, a billing code group could be defined and assigned an ID. Then, whenever a code is being bundled with that all codes in that group, it's ID can just be referenced in the bundled_codes section. Since there are potentially thousands of billing codes in these groups, any time we can avoid printing the entire list would save space.

[shaselton-usds]

Thanks for the suggestion, @jleberre10!

This is interesting. How often are you seeing the same groups of items/services being included in multiple bundles? That is to say, "we have a core group of items and services that is included in each of our bundles".

Also, any information on how large these "core/shared" services (aka, how many) are that are typically included in bundles would be helpful too!

[jleberre10]

@shaselton-usds With the data I currently have access to I don't know how common it is across the board to re-use groups of services in bundling specifically. What I can say is that re-using groups in a non-bundled format is very common, so I would expect it to be common for bundling as well, and I know it happens at least sometimes, probably very often.

The size of these groups varies drastically, in the worst cases containing over 100,000 codes. These groups would usually be referencing all codes of one type, e.g. all procedures or all revenue codes. Most of the time these groups would be used as a "fallback line" on contracts, but they can be used for bundling as well. It is more common to see groups of codes contain 100-1000 codes.

While on the topic of bundling, there is another issue my team is running into. Currently, the schema requires a single code be listed for an in network object, and a list of bundled codes to be included in the object if they exist. The way that bundles are represented at health orgs doesn't line up with this approach. For most bundles, there is not single code that is the "priced" code while the rest are "bundled" codes. There is simply a bundle of codes.

For example, lets say some health plan prices a bundle of codes 100, 101, 102, and 103 at 50 dollars. It is not clear to us which code should be the "billing_code" and which would be listed under "bundled_codes". The problem becomes even worse when the bundle is built from multiple different groups of codes. There are bundles that priced when a claim contains at least one code from group A and at least one code from group B, and at lest one from group C. We don't have a way to represent complicated bundling in the schema.

So, there are multiple changes to the schema that could both reduce file size and more accurately represent how health plans price codes.

1. My original idea of allowing billing code reference groups
2. Allowing the "billing_code" object in the In-Network-Object to contain multiple billing codes. This could reduce duplicate data that is printed out when a large group of billing codes are all priced in the same way (like fallback lines), and help with representing bundles.
3. Allow multiple groups to be listed in the "bundled_codes" section, with the assumption that the bundle is only priced if at least one code from each group is included on a claim.

The first 2 changes would strictly increase flexibility without requiring any changes for health orgs that don't need/want them.
The third change is necessary to accurately represent bundles, and should only require health orgs to change their file IF they were not accurately representing bundles before (which is likely because there isn't a good way to do this now)

Considering the timeline, it would be tough to start a refactor for change 3 in time for V 1.0 of the schema, but it would be awesome to see some change to bundling in the future. Changes 1 and 2 can be implemented at any time as they can only help and do no harm.