documentation:next_cdm:add_person_to_cost
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| documentation:next_cdm:add_person_to_cost [2017/03/12 20:12] – gowtham_rao | documentation:next_cdm:add_person_to_cost [2017/07/10 16:43] (current) – clairblacketer | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Add Person_id and (financial) Dates to Cost Table ====== | + | ====== |
| + | ===Proposals are now being tracked as github issues=== | ||
| + | [[https:// | ||
| **Proposal Owner:** Gowtham Rao, Chris Knoll, Klaus Bonadt | **Proposal Owner:** Gowtham Rao, Chris Knoll, Klaus Bonadt | ||
| Line 14: | Line 15: | ||
| **1. Add Person_id to Cost table** | **1. Add Person_id to Cost table** | ||
| - | * **Design justification: | + | * **Design justification: |
| * **Discussion for and against:** However, adding the person id and date will further de-normalize the OMOP CDM Schema. Local deployments of OMOP may add person_id on their own. This was countered by: but that will fail the standardization principle. The query optimizer may not leverage a hashing column if the column isn't applied in the query - standard OHDSI applications will not use person_id if it is not a standard OMOP CDM standard. While trying to calculate an average cost of something by person from the cost table, we have to go to the drug_exposure table, join back to cost (on the domain=" | * **Discussion for and against:** However, adding the person id and date will further de-normalize the OMOP CDM Schema. Local deployments of OMOP may add person_id on their own. This was countered by: but that will fail the standardization principle. The query optimizer may not leverage a hashing column if the column isn't applied in the query - standard OHDSI applications will not use person_id if it is not a standard OMOP CDM standard. While trying to calculate an average cost of something by person from the cost table, we have to go to the drug_exposure table, join back to cost (on the domain=" | ||
| + | * **Data integrity checks:** To avoid the possibility of database integrity conflicts, e.g. the person_id passed through the event table might be different from the one in the COST table. We need to add it to the constraints (slow), a warning in the description or data quality tools like ACHILLES HEELS, which should watch that kind of thing. | ||
| - | **Proposal details (add billed_datetime, | + | **2. Add incurred_date, |
| - | * Add two new datetime fields in the cost table. billed_datetime and paid_datetime | + | * Add three new datetime fields in the cost table. billed_datetime and paid_datetime |
| + | * Incurred_date or service_date (match event table) - This is in-line with the design principle. | ||
| * Both fields are optional (Required = No), they are date time fields (Type = DateTime - following OMOP conventions) | * Both fields are optional (Required = No), they are date time fields (Type = DateTime - following OMOP conventions) | ||
| * Costs are associated with a visit_occurrence, | * Costs are associated with a visit_occurrence, | ||
| Line 25: | Line 28: | ||
| * Incurred date is the date of the service. They are captured in the respective visit, procedure etc. | * Incurred date is the date of the service. They are captured in the respective visit, procedure etc. | ||
| * Billed date and paid date are not captured in OMOP CDM. Use cases for these are listed below | * Billed date and paid date are not captured in OMOP CDM. Use cases for these are listed below | ||
| - | * | ||
| **Use cases:** | **Use cases:** | ||
| Line 48: | Line 50: | ||
| + | **3. Leverage cost_type_concept_id and remove cost type columns ** | ||
| + | * Proposed structure of new table is below | ||
| + | * The key idea here is that instead of making each cost-type a column (i.e. wide representation), | ||
| + | * cost_type_concept_id will be used to identify standard cost types: total_charge, | ||
| + | * Should cost_domain_id be an integer or string? Currently it is a string. | ||
| - | ^ Field ^ Required | + | ^ Field ^ Required |
| - | | cost_id | + | | cost_id |
| - | | person_id | + | | person_id |
| - | | cost_event_id | + | | cost_event_id |
| - | | cost_domain_id | + | | cost_domain_id |
| - | | cost_type_concept_id | + | | cost_type_concept_id |
| - | | currency_concept_id | + | | currency_concept_id |
| - | | cost_amount_type_concept_id | + | | total_cost |
| - | | cost_amount | + | | incurred_date |
| - | | billed_datetime | + | | incurred_datetime |
| - | | paid_datetime | + | | billed_datetime |
| - | | revenue_code_concept_id | + | | paid_datetime |
| - | | drg_concept_id | + | | revenue_code_concept_id |
| - | | revenue_code_source_value | + | | drg_concept_id |
| - | | drg_source_value | + | | revenue_code_source_value |
| + | | drg_source_value | ||
documentation/next_cdm/add_person_to_cost.1489349561.txt.gz · Last modified: by gowtham_rao
