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
Or, have I misunderstood the purpose of the cost_type_concept_id?
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.
@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.
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.
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.
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?
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?
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.”
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
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
