OHDSI Home | Forums | Wiki | Github

Discrepancy in understanding the cost_type_concept_id

Vocabulary Users
#1

Currently there are three cost_type_concept_ids in the vocabularies noted here. However, these concept_ids do not represent the purpose of the cost_type_concept_id noted in the documentation here, under the Description column in the table. The cost_type_concept_id is supposed to represent the provenance of the ENTIRE cost record. I do see that under the Note section at the bottom of the page, the wording seems to contradict what is in the Description column of the table:

The COST table will store information reporting money or currency amounts. There are three types of cost data, defined in the cost_type_concept_id: 1) paid or reimbursed amounts, 2) charges or list prices (such as Average Wholesale Prices), and 3) costs or expenses incurred by the provider.
These concept_ids seem to represent what might be defined in the total_cost field? Instead of the entire cost record? Especially since I could see #1, #2, and #3 all existing on one cost record.

The purpose of the cost_type_concept_id is to help the analyst determine what the value might mean under the total_paid field - is it how much the payer paid? Is it how much the hospital paid? It gives the analyst the correct perspective to understand where the money flows.

I’m not sure who else is using these concept_ids but I propose we update the definitions to something more in line with the purpose of the field in the Cost Table. Oh, and we should also update the documentation :smile:

Or, have I misunderstood the purpose of the cost_type_concept_id?

2 Likes
#2

Hi. Thanks, @jenniferduryea for identifying this issue.

Unless I’m misunderstanding something, it seems to me the perspective (i.e. direction money is flowing) is being captured in two places in one cost table record. First in the fields total_charge (to patient for consuming the good/service), total_cost (to provider for providing the good/service), and total_paid (by patient for consuming good/service; flow is same direction as total_charge). Secondly, these three perspectives are repeated in the cost_type_concept_id field, where one record must be assigned one of the following values, 1) paid or reimbursed amounts, 2) charges or list prices (such as Average Wholesale Prices), and 3) costs or expenses incurred by the provider, although all three of these perspectives can be captured in a single record.

What are some alternative type concepts that can characterize “the provenance or the source of the COST data: Calculated from insurance claim information, provider revenue, calculated from cost-to-charge ratio, reported from accounting database, etc.”?

In my particular use case, concept_id=257 (Hospitalization Cost Record) would work well here, but it’s a procedure type so it doesn’t really fit in the cost_type_concept_id field.

Thoughts?

#3

@Christian_Reich - I agree here, I think the types are not correct.

I don’t think it would proper for us to use 257 in the PROCEDURE_COST table as a type, right?

@jenniferduryea - do you know a subset of what we would need? We need a “Hospital Cost Record”, maybe we need a “Claims Cost Record”.

#4

@ericaVoss I have to admit that I’m a little confused on what the cost_type_concept_id field is supposed to house. The original version of the Cost table had something that you and @jweave17 are looking for - a description of what the amount in the total_cost field is. However, I think that field was taken out because it was similar to an EAV model where the data tells you what is in the data. And OMOP CDM should not be an EAV model (per @Christian_Reich). So now the cost_type_concept_id is supposed to represent the provenance of the entire cost record. So I could see the following type_concept_ids (for the data you are looking at ETL’ing)

  • payer claim data (for records where paid_by_payer, total_charge, paid_by_patient are populated)
  • hospital accounting record (for records where total_cost is populated)
  • List price (for records where total_cost is populated)

Though the last two options are defining “total_cost” as a cost the hospital is incurring (the cost to the hospital).

For your data, where the total cost and the payment information is on one line, I would actually create two different cost records - one from payer data and one from hospital accounting data.

#5

Since cost and charge and amount paid are all captured in one row of the cost table, type_concept_ids shouldn’t house information that could duplicate or contradict any of these columns (e.g. a record with total_charge=1000 and cost_type_concept_id=‘costs or expenses incurred by the provider’), but it seems like this is the case at the moment. I’m less clear on the advantages and disadvantages of making cost/charge/amount paid on a single vs multiple lines. For my use case, it seems like one line per record would work (I have cost and charge data but no amount paid from hospital billing records) but I’d like to learn more about how this would or wouldn’t generalize to other use cases. Perhaps there’ll be few minutes to discuss on the CDM/vocab call tomorrow.

1 Like
#6

While @jenniferduryea and @clairblacketer are my people to go to for cost data - I too feel like the record house both incoming and outgoing payments, so why do we need to have the two records. Why can’t we have one and say where it was coming from (e.g. “Hospital Cost Record”).

@Christian_Reich & @rimma, I would like to steal a few minutes on today’s call to discuss this if possible.

#7

After reviewing your (@ericaVoss and @jweave17) comments, I believe we can capture all of your costs, charged, and paid amounts in one line using a cost_type_concept_id of “claims database” of some sort since all of that information comes from a claims database. We would have to add that cost_type_concept_id.

Strictly speaking, the “cost” variable does not come from raw claims data (as from the ANSI 837/835 file), but it is housed in, what researchers would categorize as, a “claims database”. So the cost_type_concept_id could refer to the provenance of the database as a whole. So you can have all of your cost variables under one cost record.

As to indicating the direction of the costs (or perspective), the total_paid and the payer_plan_period_id should define it. If you see an amount in the total_paid field, and there is data in the payer_plan_period_id, then that should tell the analyst that the payer represented in the payer_plan_period_id is the entity that actually PAID the provider the amount in the total_paid field. Then the total_charged field is what was charged to the payer. The paid_patient_copay, paid_patient_deductible, and paid_patient_coinsurance is the amount the payer stated what the patient is responsible for - but NOT what was actually paid. If you have data that shows what the patient actually paid to the provider, then that should be a separate cost record, the total_paid field should be populated with what the patient paid, and the payer_plan_period_id should either reference the patient (if applicable) or set to “0” as per the documentation. Please note that these fields come from claim standards (ANSI 837/835 specifications) because those are the only standards that exist at the moment. Even though this is very claims-centric, EHR cost data is also structured this way (most likely to gather information about patients from claims payments). The only issue I see is if accounting data is trying to be recorded in the CDM (aka a hospital’s Quicken entries). I’ll wait for the use case on this since I have a hard time seeing how accounting data relates to the patient, which is the whole point of the CDM.

The last outstanding issue I see is what to do with the existing cost_type_concept_ids since they do not seem to represent the provenance of cost data. Maybe retire them?

#8

@jenniferduryea:

I think you nailed it all. I hate to do that, but any chance you could summarize what exactly we should add to the cost_type_concept_id, and where the description of hte fields needs alteration?

Thanks so much.

#9

@jenniferduryea & @Christian_Reich,

I’d like to bring this up again . . . here is what I think the action items are.

  1. We need these at types:
  • Hospital Billing Record Cost
  • Cost from Claims Database
  • Accounting Data Cost
  • any other ideas?
  • Retire the current COST_TYPE_CONCEPT_IDs (see below signature)
  • Update the CDM Documentation Specification to reflect this
    • http://www.ohdsi.org/web/wiki/doku.php?id=documentation:cdm:cost
    • Description: “A foreign key identifier to a concept in the CONCEPT table for the provenance or the source of the COST data (e.g. from insurance claim information or from accounting database, etc).”
    • Convensions: (replace the first paragraph with this) “The COST table will store information reporting money or currency amounts. There are types of cost data, defined in the cost_type_concept_id. The defined fields are variables found in almost all U.S.-based claims data sources, which is the most common data source for researchers. Non-U.S.-based data holders are encouraged to engage with OHDSI to adjust these tables to their needs.”

Thank you,
@ericaVoss & @jweave17

COST TYPES TO RETIRE

SELECT *
FROM CONCEPT
WHERE VOCABULARY_ID = 'Cost Type'

5033	Cost incurred by the provider
5032	Amount charged to the patient or the payer by the provider, list price
5031	Amount paid by the patient or reimbursed by the payer
#10

@ericaVoss This is perfect and succinct. Thank you! @Christian_Reich please let us know how you want to proceed.

#11

@Christian_Reich let us know if you have any thoughts. Sorry we keep harassing you.

–@jweave17 & @ericaVoss

#12

You got it. Next release.

#13

Did these get released? Sorry I don’t have a current Vocabulary to check myself. I would like to know the CONCEPT_IDs and NAMES if possible.

Also, should I update the CDM documentation? See my note above from December. I’m assuming we are moving forward with this?

#14

Does this need to go into the land of Themis? @Gowtham_Rao could you weigh in?

#15

I think, there are two important fields in new cost table - cost_type_concept_id and cost_concept_id for the approved cost table in the development branch of omop cdm v5.3

cost_type_concept_id: domain_id = ‘Type Concept’, vocabulary = ‘Cost Type’, standard = ‘Y’, concept_class in (‘Type Concept’)

cost_concept_id: domain_id = ‘Cost’, vocabulary = ‘Cost’, standard = ‘Y’, concept_class in (‘Summary’, 'Detail)

cost_type_concept_id - is the provenance of the data. We introduced some new ones recently, but we could use more. Examples of what we have now are

image.png921×200 6.95 KB

Cost_concept_id - tells us what the cost is.

Legacy - that need to be deprecated in future

t