OHDSI Home | Forums | Wiki | Github

Coordination benefits and new cost table

I think I understand what needs to be done, but I just want to make sure.
The old paid_by_coordination_benefits column represents payments made by a secondary insurer. The new cost table assigns all costs to the specific payer. So if I was going to convert the old 5.0 cost tables to the 5.01 cost table, besides the converting the original cost record, I would need to make a new cost record to record the secondary payment and reference that to the same cost_event_id ( procedure_occurrence_id, for example ). This would also use a different payer_plan_id or null, if unknown.

Actually, I do have a specific question.

When creating the entry for the secondary benefits record, would we add/duplicate the paid_patient_copay,paid_patient_coinsurance, etc values or would that just be in the primary payer record?

For example, if we are just getting a claims feed from a single payer and they just have an amount for the coordination_benefits, would the secondary payer record just contain the cost for the corrdination_benefits and none of the other information from the primary payer record. They would be linked to the same cost_event_id.

Good question @Richard_Starr! I would just create an entry for the primary payer with specific amounts relevant to the primary payer record. The secondary benefits record will only contain cost information reported by the secondary payer record. Do not duplicate amounts for fear of double-counting costs.

Internally, we (Outcomes Insights) have had this discussion before about where to add the coordination of benefits (COB) amount when looking at Medicare claims. The coordination of benefits (COB) amount is reported by one payer and tells the user the COB amount is what was paid by the primary payer. For example, if Medicare was a secondary payer for a patient, the COB amount would report how much was paid from the primary payer for the patient’s service and then the amount_paid would be how much Medicare paid for the service as a secondary payer. Because the COB amount is reported by the one payer (i.e. Medicare) without any confirmation from the other payer, and the analyst generally doesn’t know what the other payer is for that patient, the COB amount is reported on the same Cost record as the Medicare payment record. A second cost record is only created if the cost information is reported directly from that other payer.

So when converting your cost data, you should keep you information on one cost record unless you have confirmation from the secondary/other payer of their payment and adjustment.

Hope that helps!

1 Like

Thanks @jenniferduryea!

Right now, I am not as concerned with the “correctness” of the data, but it looked like it would be really easy to duplicate the costs. I am just converting the published synpuf OMOP dataset to the generic cost table so we can develop our applications on both types of cost tables.

But understanding the proper way to treat this value will help in our “original” conversions of claims datasets. It looks like I should drop the COB amount since that is coming from medicare and not the specific other payer. If we were getting feeds from multiple payers and able to match the claims, then I could connect the primary and secondary cost records.

Thanks for your help.

1 Like

Friends:

This is ugly. I understand that claims databases work this way, but for anybody who hasn’t got a PhD in claims databases all this is utterly confusing. Just imagine folks from abroad. The term “coordination of benefits” alone has nothing to do with what it actually means (“contribution paid by another payer”).

Do you think it is time to tidy this up further? Before the cost tables are getting used much more in tools and analytics?

@Christian_Reich I’m not sure if your comment suggests the name of the field “coordination-of-benefits” is confusing, or if the storing the field in the CDM is confusing.

Just some background, the coordination_of_benefits_amt field is based on payment standards from ANSI 835 specifications. It does exist and anyone who has worked with payment information from US claims data would/should see this field. Though the name/terminology is vague, it is standard vocabulary in claims data. I believe the CDM documentation defines the field.

Though I tend to be a stickler for details, I am open to renaming the field or even dropping the field if people do not find it useful. I think this depends on the use cases from health economists. Most of the health econ studies we publish are just based on the amount paid by the payer to give the audience a payer-perspective. But if health economists are using the “amount allowed” (i.e. the amount reimbursed to the physician/hospital, regardless of the payer) to determine the cost of the service, users would have to use the coordination-of-benefit field (as they would have to add the amt_paid, all patient responsibility fields, and coordination-of-benefit fields).

t