I am conducting an HRU (Healthcare Resource Utilization) analysis focused on the cost associated with a patient population across different domains and subcategories.
I have been able to link various domain tables to the cost table using the cost_event_id.
Where I am encountering some confusion is with the Visit domain.
I can link the visit_occurrence table to the cost table by matching visit_occurrence_id = cost_event_id, and I can also link the visit_detail table to the cost table by matching visit_detail_id = cost_event_id.
In some cases, I’ve found that cost records exist for both tables. I’m trying to determine whether the cost for the Visit domain is drawn from both tables and, if so, what the difference is between them. I did some digging but could not find good OMOP documentation on cost table.
It sounds like you’re working with an existing CDM, so in this case I think the only way to answer your question would be to review the specifications for this specific OMOP conversion and find out which table was used as the reference for visit costs. It can only be one or the other, because as you’ve noted, there is no way to distinguish the IDs of the 2 visit tables in cost_event_id.
The VISIT_DETAIL description might be helpful in understanding the purpose of this table vs VISIT_OCCURRENCE: OMOP CDM v5.4.
Great question! The confusion regarding visit_occurrence vs. visit_detail in the Cost table is a common one, and something we have discussed extensively in the Health Economics & Value Assessment (HEVA) workgroup. .
The Core Concept: “Header” vs. “Line” Level
In the context of claims data (and we can generalize this idea to EHRs), the distinction between these two tables often mirrors the structure of a medical claim:
Visit Occurrence (visit_occurrence_id): Represents the Header level of a claim or the “Macro” visit (e.g., an entire Inpatient Stay or a single Outpatient claim).
Cost Context: Costs linked here are typically the aggregate or bundled costs for the entire encounter.
Visit Detail (visit_detail_id): Represents the Line level of a claim or the “Micro” visit (e.g., a specific day in the ICU, a specific ward transfer, or a specific service line item on a claim).
Cost Context: Costs linked here are the granular, itemized costs for specific components of the visit.
“Three Governing Principles”
In HEVA discussions, we outlined three principles to standardize how costs are represented. Applying these will solve your double-counting mystery:
1. Visit-Centric Architecture
All financial data must link to a clinical context, with the VISIT_OCCURRENCE table as the central hub. If a cost can be pinned to a specific moment or sub-encounter (like a bed day), it goes to visit_detail. If it applies to the stay as a whole (like a DRG payment), it goes to visit_occurrence.
2. Terminal Provenance (The ‘Where’)
The cost record must reflect the “immediate and final source.” i.e. no reinterpretation, no guessing. If it is not in the source data, it is not in the CDM.
Interpretation: If your source data provides a “Total Claim Paid Amount” (Header), that maps to visit_occurrence. If the source provides “Line Item Paid Amount” (Detail), that maps to visit_detail.
Crucial Note: In many datasets, both exist. The Header cost is often the sum of the Line costs, but not always (due to bundled payments, header-level adjustments, or flat fees).
3. Semantic Accuracy (The ‘What’)
Use cost_concept_id to strictly define if the value is “Charged”, “Paid”, “Allowed”, etc.
The Solution for your HRU Analysis
You must NOT sum them together, or you will double-count.
You are not to sum visit_detail records with visit_occurrence records. There is no guarantee that the sum of the visit_detail items equals the cost of the visit_occurrence. (There is also no guarantee that sum of allowed + paid = charged); this is practically impossible and almost never seen in source data.