Reporting code combinations that are required to produce a rate

[whiteck]

The current schema does not allow for the reporting of combinations of codes that may be required in order to produce a rate. There are multiple examples in which Revenue codes are combined with a CPT, HCPC, or DRG in order to produce a rate on a facility contract. EX: Revenue code 0333 with CPT code 61796 has a rate, in order to obtain that rate both codes must be present. The schema is only set up to represent 1:1 matches that produce a rate. How do you suggest we represent those code combinations?

FYI - This would not be considered a bundle based on the definition and examples though it is possible that schema set up could be utilized, it just wouldn't be marked as a bundle, but rather a fee for service or per diem, or case rate, if those were available.

[rgouldkc]

We have a similar situation for Institutional pricing, both Inpatient and Outpatient. Our can be based on Revenue codes (singly or a range), ICD Procedure codes (singly or a range), ICD Diagnosis codes(singly or a range) and CPT/HCPCS codes (singly or a range). These codes can be combined in any combination. For example one or a range of revenue codes only, or one or a range of revenue codes with one or a range of ICD Procedure codes, or one or a range of revenue codes with one or a range of ICD Diagnosis codes, etc. The combinations of any of the code types that come in to play are one of the code types at a minimum in combination with none to all of the other code types. Granted some of the combinations set up might never happen but that doesn't preclude them from being set up from a system perspective if they were contracted that way.
I initially thought using one of the code sets such as an ICD Procedure code then listing all Revenue codes, ICD Diagnosis codes, and CPT/HCPCS codes that were involved with the rate would be the way to go. But after further thought I believe that would lead to confusion as it would probably imply that all the other codes would need to be in play for that rate when it's really a situation of for that ICD procedure and any of the other codes or a code in a range are present the rate applies.
Generating data for all the possible code combinations while possible would undoubtedly lead to a significant amount of data.

[Orange-1234]

We have Facility contracts as well that require the combination of a specific Revenue Code and CPT to produce a rate. Has there been any further clarification or thoughts on this issue/question?

[rgouldkc]

My thought is leaning toward using LOCAL as a code type and making something up.

[RLTx1391]

Any thoughts on this @shaselton-usds ?

[rakeshkatte]

We have the same situation and we have decided to report the pricing based on the CPT as the primary code and the other code types we are populating them as part of the additional info node. Per one of the prev discussions, CMS will review the usage of the additional info node and come up with ways to normalize these into the schema in a later version. So, we thought that's the best way to represent this data.

…

On Wed, 6 Apr 2022, 14:19 RLTx1391, ***@***.***> wrote: Any thoughts on this @shaselton-usds <https://github.com/shaselton-usds> ? — Reply to this email directly, view it on GitHub <#356 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIJ2FFNEYHSPSDCUAXCJTSTVDX5WBANCNFSM5L7KRUMQ> . You are receiving this because you are subscribed to this thread.Message ID: <CMSgov/price-transparency-guide/repo-discussions/356/comments/2519278 @github.com>

[shaselton-usds]

@Orange-1234 @rgouldkc @RLTx1391 @rakeshkatte --

Thanks for the patience. As you've noted, the current schema is typically built around the concept of a single billing code negotiated arrangements. For the scenarios you've described, I'd recommend @rakeshkatte's approach. If there is a primary billing code, use that for the billing_code and billing_code_type and then populate additional_information with the other codes that are apart of the arrangement for context.

If this scenario is common, adding support for multiple codes will make sense but we will hold off on that development for the time being. Until then, please leverage additional_information.

[bws1105]

What should we do with the Allowed Amounts file where there is no Additional_Information field?