Cost table spec improvement and interest in health economics

[Vojtech_Huser (Vojtech (Vojta) Huser)]

We are looking for OHDSIers from community who could give us feedback as we try do develop columns User Guide and ETL Conventions for the COST table.

In larger context, like this post (or reply) if you have some cost data (is your source or target (=CDM) data) and possibly have some health economics research use cases (research questions).

Missing documentation for cost fields in v5.4 and v5.3

@Gowtham_Rao

[Vojtech_Huser (Vojtech (Vojta) Huser)]

We can perhaps re-use examples and instructions from old v3 of OMOP

https://forums.ohdsi.org/uploads/default/original/1X/2d8b44ea1ee0f9f70427dd2c7332335b8eb6a073.docx

pasting it here

Procedure Cost

The Procedure Cost table captures the cost of a Procedure performed on a Person. The information about the cost is only derived from the amounts paid for the Procedure. This is in contrast to the Drug Cost data which also contain information about the cost.

In addition, Disease Reference Groups, Ambulatory Payment Classifications and Revenue codes are captured. Finally, a reference to the health plan information in the Payer Plan Period table is stored in the record.

Field	Required	Type Precision	Standard	Description
procedure_cost_id	Yes	integer		A system-generated unique identifier for each procedure cost record.
procedure_occurrence_id	Yes	integer		A foreign key identifier to the procedure record for which cost data are recorded.
paid_copay	No	number(8,2)		The amount paid by the person as a fixed contribution to the expenses. Copay does not contribute to the out_of_pocket expenses.
paid_coinsurance	No	number(8,2)		The amount paid by the person as a joint assumption of risk. Typically, this is a percentage of the expenses defined by the payer plan (policy) after the person’s deductible is exceeded.
paid_toward_deductible	No	number(8,2)		The amount paid by the person that is counted toward the deductible defined by the payer plan (policy).
paid_by_payer	No	number(8,2)		The amount paid by the payer (insurer). If there is more than one payer, several procedure_cost records indicate that fact.
paid_by_coordination_benefits	No	number(8,2)		The amount paid by a secondary payer through the coordination of benefits.
total_out_of_pocket	No	number(8,2)		The total amount paid by the person as a share of the expenses, excluding the copay.
total_paid	No	number(8,2)		The total amount paid for the expenses of the procedure.
disease_class_concept_id	No	integer	DRG,

APC|A foreign key referring to a standard concept identifier in the vocabulary for disease classes, such as DRGs and APCs.|
|revenue_code_concept_id|No|integer|HCFA|A foreign key referring to a standard concept identifier in the vocabulary for revenue codes.|
|payer_plan_period_id|No|integer||A foreign key to the payer_plan_period table, where the details of the payer, plan and family are stored.|
|disease_class_source_value|No|string(50)||he source code for the disease class as it appears in the source data, stored here for reference.|
|revenue_code_source_value|No|string(50)||The source code for the revenue code as it appears in the source data, stored here for reference.|

Business Rules

Each Procedure Occurrence may have any number of corresponding records in the Procedure Cost table, but typically it is none (cost data not captured) or one (one payment per Procedure). They are linked directly through the Procedure Occurrence ID field.

The amounts paid are:

• Copay – a fixed amount to be paid by the Person
• Coinsurance – a relative amount of the total paid by the Person
• Deductible – an amount of money paid by the Person before the Payer starts contributing
• Primary Payer – the amount the primary Payer pays towards the total
• Coordination of Benefits – the amount a secondary Payer or Family Plan pays towards the total
• Out of Pocket = Copay + Coinsurance + Deductible
• Total – the total amount paid for the procedure

The amounts in various payment components should equal the total, so Copay + Coinsurance + Deductible + Primary Payer + COB = Total Paid. In reality, this is not always reflected in the source data. It is up to the ETL to determine how to deal with quality problems in the data.

There are important indicators for the amount paid that are determined through the health plan design:

• DRG – Diagnosis-related Group for hospital inpatients
• APC – Ambulatory Payment Classification for hospital outpatients
• Revenue Codes – determining what service within a provider is charging for the service

All these data are captured as Source Values and Concept IDs referring to the Vocabulary.

Finally, the health plan of the Person that is determined by these numbers is referred to through the Payer Plan Period ID (see below).

Example of a Loaded Table

The select three example drug claims are represented as following:

• Example 1: Outpatient, biopsy of orbital lesion, copay $20, coinsurance $48, no deductible, insurance $92, no coordination of benefits, total of $160
• Example 2: Outpatient, myocardial perfusion imaging (SPECT), no patient pay, insurance $207.76, coordination of benefits $394.24, total of $602.00
• Example 3: Inpatient, total abdominal hysterectomy, coinsurance $1,299.97, deductible $300, insurance $3,033.29, no coordination of benefits, total of $4,633.26, DRG 369 (Menstrual and Other Female Reproductive System Disorders), Revenue Code 360 (Operating Room Services - General Classification)
• Example 4: Inpatient, total abdominal hysterectomy, no copay or coinsurance, total of $2,671.14 paid through deductible, DRG 359 (Uterine and Adnexa Procedure For Non-Malignancy without Complications, Comorbidities), Revenue Code 0360 (Operating Room Services - General Classification)

Field	Example 1	Example 2	Example 3	Example 4
procedure_cost_id	integer foreign key	integer foreign key	integer foreign key	integer foreign key
procedure_occurrence_id	integer foreign key	integer foreign key	integer foreign key	integer foreign key
paid_copay	20	0	0	0
paid_coinsurance	48	0	1299.97	0
paid_toward_deductible	0	0	300	2671.14
paid_by_payer	92	207.76	3033.29	0
paid_by_coordination_benefits	0	394.24	0	0
total_out_of_pocket	48	0	1599.97	2671.14
total_paid	160	602	4633.26	2671.14
disease_class_concept_id			38000667	38000657
revenue_code_concept_id			38003208	38003208
payer_plan_period_id	integer foreign key		integer foreign key	integer foreign key
disease_class_source_value			369	359
revenue_code_source_value			0360	0360

We need guidance on values for

• cost.cost_domain_id
• cost.cost_type_concept_id

@clairblacketer

If a cost row does not have a corresponding event in CDM (e.g., row in procedure table) - we need guidance on how to deal with cost_event_id being required.

Capitation cost rows will never have a linked event. (monthly capitation on patient level) (paid by plan even if no event in patient life occurs)

[katy-sadowski]

Indicating my interest, and linking these 2 other relevant threads for reference (both of which I’ve followed with interest but haven’t had time to fully process/respond). I think this all rolls up into a larger discussion around better support for health economics research in OMOP.

Vocab Request - Additional Type Concepts for Claims Provenance

Hello all, this is my first time requesting vocab modifications (but it does tie back to some previous forum conversations, linked below), so I apologize if I’m missed anything, posted in the wrong place, etc. Please see below and advise on next steps. My goal: Annotate records with provenance showing that they are from a particular claim type and include the “open”/“closed” adjudication status. As an example, a specific record may come from a “closed professional claim line” or an “open dent…

How to Differentiate Closed Claims data sets from Open Claims data sets

I’m working on the modelling / etl for healthcare claims data to OMOP. The data set has a mix of open claims (claims submitted by the providers, pre-adjudication) and closed claims (adjudicated claims provided by the payers). I’m stuck on how to differentiate the open claims vs closed claims data in OMOP, which is important information to provide to researchers because closed claims are generally viewed as higher quality. 1st plan: I was initially thinking that I could use the cost_type_conc…

Regarding:

@Vojtech_Huser

If a cost row does not have a corresponding event in CDM (e.g., row in procedure table) - we need guidance on how to deal with cost_event_id being required.

We’ve also experienced issues related to representing cost for source records with one-to-many standard concept mappings. Properly modeling this data feels like a scenario in which a many-to-many relationship is unavoidable, and/or in which we fundamentally rethink the objects at play.