mz-health/OMOP
mz-health
/
OMOP
mirror of https://github.com/OHDSI/CommonDataModel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

CDM v6.0 updates to economics tables

This commit is contained in:
clairblacketer 2018-09-27 14:31:20 -04:00
parent c734c1784c
commit 37acf128f3
3 changed files with 58 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/Standardized-Derived-Elements.md
View File

@ -1,5 +1,3 @@
[COHORT](https://github.com/OHDSI/CommonDataModel/wiki/COHORT)
[COHORT_ATTRIBUTE](https://github.com/OHDSI/CommonDataModel/wiki/COHORT_ATTRIBUTE)
[DRUG_ERA](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_ERA)
[DOSE_ERA](https://github.com/OHDSI/CommonDataModel/wiki/DOSE_ERA)
[CONDITION_ERA](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_ERA)

93
Documentation/CommonDataModel_Wiki_Files/StandardizedHealthEconomicsDataTables/COST.md
View File

@ -1,59 +1,58 @@
The COST table captures records containing the cost of any medical entity recorded in one of the DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE or DEVICE_OCCURRENCE tables. It replaces the corresponding DRUG_COST, PROCEDURE_COST, VISIT_COST or DEVICE_COST tables that were initially defined for the OMOP CDM V5. However, it also allows to capture cost information for records of the OBSERVATION and MEASUREMENT tables.
The COST table captures records containing the cost of any medical entity recorded in one of the DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT tables.
The information about the cost is defined by the amount of money paid by the Person and Payer, or as the charged cost by the healthcare provider. So, the COST table can be used to represent both cost and revenue perspectives. The cost_type_concept_id field will use concepts in the Standardized Vocabularies to designate the source of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record that is responsible for the determination of the cost as well as some of the payments.
The information about the cost is defined by the amount of money paid by the Person and Payer, or as the charged cost by the healthcare provider. So, the COST table can be used to represent both cost and revenue perspectives. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record that is responsible for the determination of the cost as well as some of the payments.
Field|Required|Type|Description
:-----------------------------|:--------|:------------|:----------------------------------------------------
|cost_id |Yes|integer|A unique identifier for each COST record.|
|person_id |Yes|integer|A unique identifier for each PERSON.|
|cost_event_id |Yes|integer|A foreign key identifier to the event (e.g. Measurement, Procedure, Visit, Drug Exposure, etc) record for which cost data are recorded.|
|cost_domain_id |Yes|varchar(20)|The concept representing the domain of the cost event, from which the corresponding table can be inferred that contains the entity for which cost information is recorded.|
|cost_type_concept_id |Yes|integer|A foreign key identifier to a concept in the CONCEPT table for 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.|
|currency_concept_id |No|integer|A foreign key identifier to the concept representing the 3-letter code used to delineate international currencies, such as USD for US Dollar.|
|total_charge |No|float|The total amount charged by some provider of goods or services (e.g. hospital, physician pharmacy, dme provider) to payers (insurance companies, the patient).|
|total_cost |No|float|The cost incurred by the provider of goods or services.|
|total_paid |No|float|The total amount actually paid from all payers for goods or services of the provider.|
|paid_by_payer |No|float|The amount paid by the Payer for the goods or services.|
|paid_by_patient |No|float|The total amount paid by the Person as a share of the expenses.|
|paid_patient_copay |No|float|The amount paid by the Person as a fixed contribution to the expenses.|
|paid_patient_coinsurance |No|float|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 after the Person's deductible is exceeded.|
|paid_patient_deductible |No|float|The amount paid by the Person that is counted toward the deductible defined by the Payer Plan. paid_patient_deductible does contribute to the paid_by_patient variable.|
|paid_by_primary |No|float|The amount paid by a primary Payer through the coordination of benefits.|
|paid_ingredient_cost |No|float|The amount paid by the Payer to a pharmacy for the drug, excluding the amount paid for dispensing the drug. paid_ingredient_cost contributes to the paid_by_payer field if this field is populated with a nonzero value.|
|paid_dispensing_fee |No|float|The amount paid by the Payer to a pharmacy for dispensing a drug, excluding the amount paid for the drug ingredient. paid_dispensing_fee contributes to the paid_by_payer field if this field is populated with a nonzero value.|
|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. Record the payer_plan_id that relates to the payer who contributed to the paid_by_payer field.|
|amount_allowed |No|float|The contracted amount agreed between the payer and provider.|
|revenue_code_concept_id |No|integer|A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes.|
|revenue_code_source_value |No|varchar(50)|The source code for the Revenue code as it appears in the source data, stored here for reference.|
|drg_concept_id |No|integer|A foreign key to the predefined concept in the DRG Vocabulary reflecting the DRG for a visit.|
|drg_source_value |No|varchar(3)| The 3-digit DRG source code as it appears in the source data.|
|cost_event_field_concept_id |Yes| integer| A foreign key identifier to a concept in the CONCEPT table representing the identity of the field represented by COST_EVENT_ID |
|cost_concept_id | Yes| integer| A foreign key that refers to a Standard Cost Concept identifier in the Standardized Vocabularies belonging to the 'Cost' vocabulary. |
| cost_type_concept_id | Yes | integer | A foreign key identifier to a concept in the CONCEPT table for the provenance or the source of the COST data and belonging to the 'Cost Type' vocabulary |
| cost_source_concept_id | No | integer | A foreign key to a Cost Concept that refers to the code used in the source. |
| cost_source_value | No | varchar(50) | The source value for the cost as it appears in the source data|
| currency_concept_id | Yes | integer | A foreign key identifier to the concept representing the 3-letter code used to delineate international currencies, such as USD for US Dollar. These belong to the 'Currency' vocabulary |
| cost | Yes | float | The actual financial cost amount |
| incurred_date | Yes | date | The first date of service of the clinical event corresponding to the cost as in table capturing the information (e.g. date of visit, date of procedure, date of condition, date of drug etc). |
| billed_date | No | date | The date a bill was generated for a service or encounter |
| paid_date | No | date | The date payment was received for a service or encounter |
| revenue_code_concept_id | No | integer | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes belonging to the 'Revenue Code' vocabulary. |
| drg_concept_id | No | integer | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for DRG codes belonging to the 'DRG' vocabulary. |
| revenue_code_source_value | No | varchar(50) | The source value for the Revenue code as it appears in the source data, stored here for reference. |
| drg_source_value | No | varchar(50) | The source value for the 3-digit DRG source code as it appears in the source data, stored here for reference.
| 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. Record the payer_plan_id that relates to the payer who contributed to the paid_by_payer field. |
### Conventions
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. 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.
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) Payer is primary (coordination of benefit)
2) Payer is secondary (coordination of benefit)
3) Premium
One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the payer_plan_id field. Goods or services services not covered by a payer are indicated by 0 values in the amount_allowed and patient responsibility fields (copay, coinsurance, deductible) as well as a missing payer_plan_period_id. This means the patient is responsible for the total_charged value.
One cost record is generated for each money or currency amount associated with a record in one of the event tables. For example, a raw record that looks like this:
The cost information is linked through the cost_event_id field to its entity, which denotes a record in a table referenced by the cost_domain_id field:
|patient_id |cob |coins| copay| deduct| net| total_pay| pddate |proc_cd| procmod| revcode| svcdate|
:-------|:----------|:-------|:-----------|:----------|:-------|:-----------|:----------|:-------|:-----------|:----------|:----------|
|175127601| 0| 0 |22 |3| 88| 113| 2/28/2000 |82378 | | |1/1/2000|
cost_domain_id|corresponding CDM table
:-------------|:-------------------------
|Drug|DRUG_EXPOSURE|
|Visit|VISIT_OCCURRENCE|
|Procedure|PROCEDURE_OCCURRENCE|
|Device|DEVICE_EXPOSURE|
|Measurement|MEASUREMENT|
|Observation|OBSERVATION|
|Specimen|SPECIMEN|
Will create four lines in the COST table:
* cost_type_concept_id: The concept referenced in this field defines the source of the cost information, and therefore the perspective. It could be from the perspective of the payer, or the perspective of the provider. Therefore, "cost" really means either cost or revenue, and the direction of funds (incoming and outgoing) as well as the modus of its calculation is defined by this field.
* total_charged and total_cost: The cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio. This data is currently available for [NIS](https://www.hcup-us.ahrq.gov/db/nation/nis/nisdbdocumentation.jsp) datasets, or any other [HCUP](https://www.hcup-us.ahrq.gov/databases.jsp) datasets. See also cost calculation explanation from AHRQ [here](https://www.hcup-us.ahrq.gov/db/state/costtocharge.jsp).
* total_paid: This field is calculated using the following formula: paid_by_payer + paid_by_patient + paid_by_primary. In claims data, this field is considered the calculated field the payer expects the provider to get reimbursed for goods and services, based on the payer's contractual obligations.
* Drug costs are composed of ingredient cost(the amount charged by the wholesale distributor or manufacturer), the dispensing fee(the amount charged by the pharmacy and the sales tax). The latter is usually very small and typically not provided by most source data, and therefore not included in the CDM.
* paid_by_payer: In claims data, generally there is one field representing the total payment from the payer for the service/device/drug. However, this field could be a calculated field if the source data provides separate payment information for the ingredient cost and the dispensing fee in case of prescription benefits. If there is more than one Payer in the source data, several cost records indicate that fact. The Payer reporting this reimbursement should be indicated under the payer_plan_id field.
* paid_by_patient: This field is most often used in claims data to report the contracted amount the patient is responsible for reimbursing the provider for the goods and services she received. This is a calculated field using the following formula: paid_patient_copay + paid_patient_coinsurance + paid_patient_deductible. If the source data has actual patient payments then the patient payment should have its own cost record with a payer_plan_id set to 0 to indicate the the payer is actually the patient, and the actual patient payment should be noted under the total_paid field. The paid_by_patient field is only used for reporting a patient's responsibility reported on an insurance claim.
* paid_patient_copay does contribute to the paid_by_patient variable. The paid_patient_copay field is only used for reporting a patient's copay amount reported on an insurance claim.
* paid_patient_coinsurance does contribute to the paid_by_patient variable. The paid_patient_coinsurance field is only used for reporting a patient's coinsurance amount reported on an insurance claim.
* paid_patient_deductible does contribute to the paid_by_patient variable. The paid_patient_deductible field is only used for reporting a patient's deductible amount reported on an insurance claim.
* amount_allowed: This information is generally available in claims data. This is similar to the total_paid amount in that it shows what the payer expects the provider to be reimbursed after the payer and patient pay. This differs from the total_paid amount in that it is not a calculated field, but a field available directly in claims data. The field is payer-specific and the payer should be indicated by the payer_plan_id field.
* paid_by_primary does contribute to the total_paid variable. The paid_by_primary field is only used for reporting a patient's primary insurance payment amount reported on the secondary payer insurance claim. If the source data has actual primary insurance payments (e.g. the primary insurance payment is not a derivative of the payer claim and there is verification another insurance company paid an amount to the provider), then the primary insurance payment should have its own cost record with a payer_plan_id set to the applicable payer, and the actual primary insurance payment should be noted under the paid_by_payer field.
* revenue_code_concept_id: Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system.
* drg_concept_id: Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. Only the MS-DRG system should be used (mapped to vocabulary_id 'DRG) and all other DRG values should be mapped to 0.
cost_id |person_id| cost_event_id| cost_event_field_concept_id| cost_concept_id| cost_type_concept_id| cost_source_concept_id |currency_concept_id| cost| incurred_date| billed_date| paid_date |revenue_code_concept_id| drg_concept_id |revenue_code_source_value| drg_source_value |payer_plan_period_id
:-------|:-------|:-------|:-----|:----------|:-------|:------|:--------|:-------|:-----|:-------|:----|:-----|:-------|:----|:-----|:-------|:----
|1| 175127601| 1002| *TBD*| 1234| 5032| 0| 44818668| 22 |1/1/2000| |2/28/2000| 0 |0 | || 3045|
|2 |175127601| 1002| *TBD*| 2345| 5032| 0| 44818668| 3 |1/1/2000| |2/28/2000| 0 |0| || 3045|
|3 |175127601| 1002| *TBD*| 3456| 5032| 0| 44818668| 88 |1/1/2000| | 2/28/2000| 0 |0| || 3045|
|4 |175127601| 1002| *TBD*| 4567| 5032| 0| 44818668| 113 |1/1/2000| | 2/28/2000| 0 |0| || 3045|
No.|Convention Description
:--------|:------------------------------------
| 1 | The cost information is linked through the COST_EVENT_ID field to its entity, which denotes a record in a table referenced by the COST_EVENT_FIELD_CONCEPT_ID field.
| 2 | One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. |
| 3 | One cost record is generated for each money or currency amount associated with a record in one of the event tables. |
| 4 | The COST field represents the dollar amount, either incoming or outgoing |
| 5 | When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio. This data is currently available for [NIS](https://www.hcup-us.ahrq.gov/db/nation/nis/nisdbdocumentation.jsp) datasets, or any other [HCUP](https://www.hcup-us.ahrq.gov/databases.jsp) datasets. See also cost calculation explanation from AHRQ | 6 | In claims data, total paid is considered the calculated field the payer expects the provider to get reimbursed for goods and services, based on the payer's contractual obligations. |
| 7 | Drug costs are composed of ingredient cost(the amount charged by the wholesale distributor or manufacturer), the dispensing fee(the amount charged by the pharmacy and the sales tax). The latter is usually very small and typically not provided by most source data, and therefore not included in the CDM. |
| 8 | In claims data, generally there is one field representing the total payment from the payer for the service/device/drug. However, this field could be a calculated field if the source data provides separate payment information for the ingredient cost and the dispensing fee in case of prescription benefits. If there is more than one Payer in the source data, several cost records indicate that fact. The Payer reporting this reimbursement should be indicated under the PAYER_PLAN_ID field. |
| 10 | REVENUE_CODE_CONCEPT_ID: Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system.
| 11 | DRG_CONCEPT_ID: Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. Only the MS-DRG system should be used (mapped to vocabulary_id 'DRG) and all other DRG values should be mapped to 0. |

15
Documentation/CommonDataModel_Wiki_Files/StandardizedHealthEconomicsDataTables/PAYER_PLAN_PERIOD.md
View File

@ -4,14 +4,18 @@ Field|Required|Type|Description
:------------------------------|:--------|:------------|:----------------------------------------------
|payer_plan_period_id |Yes|integer|A identifier for each unique combination of payer, plan, family code and time span.|
|person_id |Yes|integer|A foreign key identifier to the Person covered by the payer. The demographic details of that Person are stored in the PERSON table.|
|contract_person_id |No|integer|A foreign key identifier to the person_id in person table, for the person who is the primary subscriber/contract owner for the record in the payer_plan_period table. Maybe the same person or different person, depending on who is the primary subscriber/contract owner.|
|payer_plan_period_start_date |Yes|date|The start date of the payer plan period.|
|payer_plan_period_end_date |Yes|date|The end date of the payer plan period.|
|payer_concept_id |No|integer|A foreign key that refers to a standard Payer concept identifier in the Standarized Vocabularies|
|payer_source_value |No|varchar(50)|The source code for the payer as it appears in the source data.|
|payer_source_concept_id |No|integer|A foreign key to a payer concept that refers to the code used in the source.|
|plan_concept_id |No|integer|A foreign key that refers to a standard plan concept identifier that represents the health benefit plan in the Standardized Vocabularies|
|plan_concept_id |No|integer|A foreign key that refers to a standard plan concept identifier that represents the health benefit plan in the Standardized Vocabularies.|
|plan_source_value |No|varchar(50)|The source code for the Person's health benefit plan as it appears in the source data.|
|plan_source_concept_id |No|integer|A foreign key to a plan concept that refers to the plan code used in the source data.|
|contract_concept_id |No|integer|A foreign key to a standard concept representing the reason justifying the contract between person_id and contract_person_id.|
|contract_source_value |No|integer|The source code representing the reason justifying the contract. Usually it is family relationship like a spouse, domestic partner, child etc.|
|contract_source_concept_id |No|integer|A foreign key to a concept that refers to the code used in the source as the reason justifying the contract.|
|sponsor_concept_id |No|integer|A foreign key that refers to a concept identifier that represents the sponsor in the Standardized Vocabularies.|
|sponsor_source_value |No|varchar(50)|The source code for the Person's sponsor of the health plan as it appears in the source data.|
|sponsor_source_concept_id |No|integer|A foreign key to a sponsor concept that refers to the sponsor code used in the source data.|
@ -21,5 +25,10 @@ Field|Required|Type|Description
|stop_reason_source_concept_id |No|integer|A foreign key to a stop-coverage concept that refers to the code used in the source.|
### Conventions
* Different Payers have different designs for their health benefit Plans. The PAYER_PLAN_PERIOD table does not capture all details of the plan design or the relationship between Plans or the cost of healthcare triggering a change from one Plan to another. However, it allows identifying the unique combination of Payer (insurer), Plan (determining healthcare benefits and limits) and Person. Typically, depending on healthcare utilization, a Person may have one or many subsequent Plans during coverage by a single Payer.
* Typically, family members are covered under the same Plan as the Person. In those cases, the payer_source_value, plan_source_value and family_source_value are identical.
No.|Convention Description
:--------|:------------------------------------
| 1 | Different Payers have different designs for their health benefit Plans. The PAYER_PLAN_PERIOD table does not capture all details of the plan design or the relationship between Plans or the cost of healthcare triggering a change from one Plan to another. However, it allows identifying the unique combination of Payer (insurer), Plan (determining healthcare benefits and limits) and Person. Typically, depending on healthcare utilization, a Person may have one or many subsequent Plans during coverage by a single Payer. |
| 2 | Typically, family members are covered under the same Plan as the Person. In those cases, the payer_source_value, plan_source_value and family_source_value are identical. |
| 3 | The contract_person_id is meant to refer to the owner of the plan, for instance, a parent who owns the plan under which the child is covered. Contract_person_id many times will be equal to person_id. |
| 4 | The fields contract_source_value and contract_concept_id justify the contract relationship.<br><ul><li>It is represented as the relationship from the person_id to contract_person_id. We will use SNOMED vocabulary of the Relationship Domain and Social Context concept class id (see [here](http://athena.ohdsi.org/search-terms/terms?vocabulary=SNOMED&domain=Relationship&conceptClass=Social+Context&page=1&pageSize=15&query=). For example:<br><ul><li>Person_id is the spouse ([4132413](http://athena.ohdsi.org/search-terms/terms/4132413)) of contract_person_id</li><li>person_id is the child ([4285883](http://athena.ohdsi.org/search-terms/terms/4285883)) of the contract_person_id</li></ul>