Add diagnosis code to negotiated price object

[sean-kates]

Adds in a field for diagnosis code, which is a differentiating feature for determining the correct rate.

[tdfow]

Can someone provide more information regarding this proposed schema change? What rules are being suggested to associate with it's use? Are there provider contracts that list out diagnosis code rates? Additional Information field is available for clarifying rates, so can someone clarify the reason for this proposal schema change?

[shaselton-usds]

@sean-kates Thanks for thoughts on this, but as @tdfow mentioned, can you give some background on this?

If it is helpful to include diagnosis code(s) as an optional attribute to further provide context to the rates/contracts, it'll be important to determine what impacts this would have in the size of the file.

[sean-kates]

@tdfow @shaselton-usds The impetus of this addition is that when speaking with payers about their MRFs, they mentioned that they didn't believe they could accurately distinguish between rates due to lack of diagnosis codes in the schema. This was brought up when showing two rates in the file with no differentiating factors across all the other fields.

"in_network" : [
      {
        "negotiation_arrangement": "ffs",
        "name": "DIAGNOSTIC COLONOSCOPY",
        "billing_code_type": "CPT",
        "billing_code_type_version": "2022",
        "billing_code": "45378",
        "description": "DIAGNOSTIC COLONOSCOPY",
        "negotiated_rates": [
          {
            "provider_references": [
                57989
            ],
            "negotiated_prices": [
                {
                    "negotiated_type": "negotiated",
                    "negotiated_rate": 676.00,
                    "expiration_date": "9999-12-31",
                    "service_code": ["01","06","08","12","19","20","22","99"],
                    "billing_class": "professional"
                }
            ]
          },
          {
            "provider_references": [
                57989
            ],
            "negotiated_prices": [
                {
                    "negotiated_type": "negotiated",
                    "negotiated_rate": 529.00,
                    "expiration_date": "9999-12-31",
                    "service_code": ["01","06","08","12","19","20","22","99"],
                    "billing_class": "professional"
                }
            ]
          }
        ]
      }
]

The two rates above were flagged as duplicates since the negotiated_type, expiration_date, service_code, and billing_class are the same across them but they have two different negotiated_rates.

I will circle back with the payer on exactly what diagnosis code(s) would be applied in each case, but that's what was explained as the differentiating factor in this example.

[tdfow]

If there are contracts that are based on diagnosis, there seems to be options to have ICD-10 codes be assigned the Billing Code type and the associated value.

Additionally, there is the additional information field where they can clarify the difference in the rate too.

I'm just not understanding why the proposed schema change would be needed, if they use either a different billing code type or the additional information to clarify.

(

International Classification of Diseases | ICD | ICD background -- | -- | -- International Classification of Diseases ICD [ICD background](https://en.wikipedia.org/wiki/International_Classification_of_Diseases)

[sean-kates]

@tdfow I guess I should be clearer when I say ICD-10, I'm talking ICD-10-CM (diagnosis) not ICD-10-PCS (procedures). The ICD-10-CM diagnosis code itself doesn't mean anything without the relationship to the billing_code. Having it's own rate record wouldn't make sense.

Take the ICD-10-CM code of E66.3 (overweight diagnosis). That can be added to any number of claims, not specific to one procedure. The case I'm trying to capture is when having this diagnosis can alter the rate of an procedure due to added complexity or risk. It's the same idea as billing_code_modifier in the current schema. The modifier is important in relation to the billing_code, but it doesn't mean anything by itself.

Let me try and wrangle a clearer example from a payer who is working through this.

Additionally, there is the additional information field where they can clarify the difference in the rate too.

Additional information is a free text field and therefore unusable if the data in them is needed for analysis. If there is a field/value that differentiates rates, IMO it shouldn't be left up to a free text field to capture it. It should be part of the schema so that this data can be used at scale. Free text fields are definitely a trigger for me 😄

[frishrash]

Relates to #633 as well.

There could be many different ways to define rates in real life contracts and it would be impossible and impractical to try to capture ALL of them. Think about case rates, conditions, carve outs, C-codes and J-codes that providers use the same code for different services/supplies, etc.

I think CMS needs to strike a balance there. IMHO adding dx codes will make things much more harder to generate and interpret. Keep in mind they are hierarchical in nature so another level of complexity right there.

I wish the additional_information field would have been utilized much more by payers, that could have shaped what common things are missing.