Update files for pdf conversion
parent
e4f56c1e05
commit
0928989fae
|
@ -28,3 +28,4 @@ The advantage of this approach lies in the preservation of codes and relationshi
|
|||
Below is an entity-relationship diagram highlighting the tables within the Vocabulary portion of the OMOP Common Data Model:
|
||||
|
||||
![Vocabulary entity-relationship diagram](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?cache=&w=900&h=714&tok=3c9ce1&media=documentation:cdm:vocabulary_tables.png)\
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
The device exposure domain captures information about a person’s exposure to a foreign physical object or instrument that which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).
|
||||
The device exposure domain captures information about a person's exposure to a foreign physical object or instrument that which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).
|
||||
|
||||
Field|Required|Type|Description
|
||||
:------------------------------|:--------|:------------|:--------------------------------------------
|
||||
:--------------------------------|:--------|:------------|:--------------------------------------------
|
||||
|device_exposure_id|Yes|integer|A system-generated unique identifier for each Device Exposure.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the Person who is subjected to the Device. The demographic details of that person are stored in the Person table.|
|
||||
|device_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the Device concept.|
|
||||
|
|
|
@ -8,7 +8,7 @@ Drug Exposure is inferred from clinical events associated with orders, prescript
|
|||
* Drugs administered as part of a Procedure, such as chemotherapy or vaccines.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:---------------------------|:--------|:------------|:------------------------------------------------
|
||||
:------------------------------|:--------|:------------|:------------------------------------------------
|
||||
|drug_exposure_id|Yes|integer|A system-generated unique identifier for each Drug utilization event.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the person who is subjected to the Drug. The demographic details of that person are stored in the person table.|
|
||||
|drug_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the Drug concept.|
|
||||
|
|
|
@ -1,14 +1,14 @@
|
|||
The MEASUREMENT table contains records of Measurement, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person's sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:-------------------------------|:--------|:------------|:------------------------------------------------
|
||||
:----------------------------------|:--------|:------------|:------------------------------------------------
|
||||
|measurement_id|Yes|integer|A unique identifier for each Measurement.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the Person about whom the measurement was recorded. The demographic details of that Person are stored in the PERSON table.|
|
||||
|measurement_concept_id|Yes|integer|A foreign key to the standard measurement concept identifier in the Standardized Vocabularies.|
|
||||
|measurement_date|Yes|date|The date of the Measurement.|
|
||||
|measurement_datetime|No|datetime|The date and time of the Measurement. Some database systems don't have a datatype of time. To accomodate all temporal analyses, datatype datetime can be used (combining measurement_date and measurement_time [forum discussion](http://forums.ohdsi.org/t/date-time-and-datetime-problem-and-the-world-of-hours-and-1day/314))|
|
||||
|measurement_type_concept_id|Yes|integer|A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the provenance from where the Measurement record was recorded.|
|
||||
|operator_concept_id|No|integer|A foreign key identifier to the predefined Concept in the Standardized Vocabularies reflecting the mathematical operator that is applied to the value_as_number. Operators are <, ≤, =, ≥, >.|
|
||||
|operator_concept_id|No|integer|A foreign key identifier to the predefined Concept in the Standardized Vocabularies reflecting the mathematical operator that is applied to the value_as_number. Operators are <, <=, =, >=, >.|
|
||||
|value_as_number|No|float|A Measurement result where the result is expressed as a numeric value.|
|
||||
|value_as_concept_id|No|integer|A foreign key to a Measurement result represented as a Concept from the Standardized Vocabularies (e.g., positive/negative, present/absent, low/high, etc.).|
|
||||
|unit_concept_id|No|integer|A foreign key to a Standard Concept ID of Measurement Units in the Standardized Vocabularies.|
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----------------------------|:--------|:------------|:-------------------------------------------------------
|
||||
:----------------------------------|:--------|:------------|:------------------------------------
|
||||
|observation_id|Yes|integer|A unique identifier for each observation.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the Person about whom the observation was recorded. The demographic details of that Person are stored in the PERSON table.|
|
||||
|observation_concept_id|Yes|integer|A foreign key to the standard observation concept identifier in the Standardized Vocabularies.|
|
||||
|
|
|
@ -4,7 +4,7 @@ The PROCEDURE_OCCURRENCE table contains records of activities or processes order
|
|||
* Electronic Health Records that capture procedures as orders.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:------------------------|:--------|:------------|:----------------------------------------
|
||||
:--------------------------|:--------|:------------|:----------------------------------------
|
||||
|procedure_occurrence_id|Yes|integer|A system-generated unique identifier for each Procedure Occurrence.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the Person who is subjected to the Procedure. The demographic details of that Person are stored in the PERSON table.|
|
||||
|procedure_concept_id|Yes|integer|A foreign key that refers to a standard procedure Concept identifier in the Standardized Vocabularies.|
|
||||
|
|
|
@ -15,4 +15,5 @@
|
|||
These tables contain the core information about the clinical events that occurred longitudinally during valid Observation Periods for each Person, as well as demographic information for the Person.
|
||||
Below provides an entity-relationship diagram highlighting the tables within the Standardized Clinical Data portion of the OMOP Common Data Model:
|
||||
|
||||
![Clinical data entity-relationship diagram](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?media=documentation:cdm:standard_clinical_data_tables.png)\
|
||||
![Clinical data entity-relationship diagram](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?media=documentation:cdm:standard_clinical_data_tables.png)\
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
The COHORT table contains records of subjects that satisfy a given set of criteria for a duration of time. The definition of the cohort is contained within the COHORT_DEFINITION table. Cohorts can be constructed of patients (Persons), Providers or Visits.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:--------------------|:--------|:------------|:----------------------------
|
||||
|cohort_definition_id|Yes|integer|A foreign key to a record in the COHORT_DEFINITION table containing relevant Cohort Definition information.|
|
||||
|subject_id|Yes|integer|A foreign key to the subject in the cohort. These could be referring to records in the PERSON, PROVIDER, VISIT_OCCURRENCE table.|
|
||||
|cohort_start_date|Yes|date|The date when the Cohort Definition criteria for the Person, Provider or Visit first match.|
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
The COHORT_ATTRIBUTE table contains attributes associated with each subject within a cohort, as defined by a given set of criteria for a duration of time. The definition of the Cohort Attribute is contained in the ATTRIBUTE_DEFINITION table.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:---------------------|:--------|:------------|:------------------------------
|
||||
|cohort_definition_id|Yes|integer|A foreign key to a record in the [COHORT_DEFINITION](https://github.com/OHDSI/CommonDataModel/wiki/COHORT_DEFINITION) table containing relevant Cohort Definition information.|
|
||||
|subject_id|Yes|integer|A foreign key to the subject in the Cohort. These could be referring to records in the PERSON, PROVIDER, VISIT_OCCURRENCE table.|
|
||||
|cohort_start_date|Yes|date|The date when the Cohort Definition criteria for the Person, Provider or Visit first match.|
|
||||
|
|
|
@ -5,7 +5,7 @@ Similar to Drug Eras, Condition Eras are chronological periods of Condition Occu
|
|||
For example, consider a Person who visits her Primary Care Physician (PCP) and who is referred to a specialist. At a later time, the Person visits the specialist, who confirms the PCP’s original diagnosis and provides the appropriate treatment to resolve the condition. These two independent doctor visits should be aggregated into one Condition Era.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:----------------------------|:--------|:------------|:----------------------------------
|
||||
|condition_era_id|Yes|integer|A unique identifier for each Condition Era.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the Person who is experiencing the Condition during the Condition Era. The demographic details of that Person are stored in the PERSON table.|
|
||||
|condition_concept_id|Yes|integer|A foreign key that refers to a standard Condition Concept identifier in the Standardized Vocabularies.|
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:--------------------|:--------|:------------|:---------------------------
|
||||
|dose_era_id|Yes|integer|A unique identifier for each Dose Era.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the Person who is subjected to the drug during the drug era. The demographic details of that Person are stored in the PERSON table.|
|
||||
|drug_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the active Ingredient Concept.|
|
||||
|
@ -16,9 +16,10 @@ Field|Required|Type|Description
|
|||
* Dose Form information is not taken into account. So, if the patient changes between different formuations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.
|
||||
* The daily dose is calculated for each DRUG_EXPOSURE record by calculating the total dose of the record and dividing by the duration.
|
||||
* The total dose of a DRUG_EXPOSURE record is calculated with the help of the DRUG_STRENGTH table containing the dosage information for each drug as following:
|
||||
|
||||
|
||||
|
||||
| 1 | Tablets and other fixed amount formulations |
|
||||
|:----|:----|
|
||||
|:-----------------|:-----------------------------------------|
|
||||
||*Example: Acetaminophen (Paracetamol) 500 mg, 20 tablets.*|
|
||||
| DRUG_STRENGTH | The denominator_unit is empty |
|
||||
| DRUG_EXPOSURE | The quantity refers to number of pieces, e.g. tablets |
|
||||
|
@ -27,14 +28,14 @@ Field|Required|Type|Description
|
|||
||*`Acetaminophen dose = 20 x 500mg = 10,000mg`*|
|
||||
|
||||
| 2 | Puffs of an inhaler |
|
||||
|:----|:----|
|
||||
|:-----------------|:-----------------------------------------|
|
||||
||Note: There is no difference to use case 1 besides that the DRUG_STRENGTH table may put {actuat} in the denominator unit. In this case the strength is provided in the numerator.|
|
||||
| DRUG_STRENGTH | The denominator_unit is {actuat}|
|
||||
| DRUG_EXPOSURE | The quantity refers to the number of pieces, e.g. puffs |
|
||||
| `Ingredient dose=`|`quantity x numerator_value [numerator_unit_concept_id]`|
|
||||
|
||||
| 3 | Quantified Drugs which are formulated as a concentration |
|
||||
|:-----|:-----|
|
||||
|:-----------------|:-----------------------------------------|
|
||||
||*Example: The Clinical Drug is Acetaminophen 250 mg/mL in a 5mL oral suspension. The Quantified Clinical Drug would have 1250 mg / 5 ml in the DRUG_STRENGTH table. Two suspensions are dispensed.*|
|
||||
| DRUG_STRENGTH | The denominator_unit is either mg or mL. The denominator_value might be different from 1. |
|
||||
| DRUG_EXPOSURE | The quantity refers to a fraction or, multiple of the pack. |
|
||||
|
@ -43,7 +44,7 @@ Field|Required|Type|Description
|
|||
||*`Acetaminophen dose = 2 x 1250mg = 2500mg`*|
|
||||
|
||||
| 4 | Drugs with the total amount provided in quantity, e.g. chemotherapeutics |
|
||||
|:----|:----|
|
||||
|:-----------------|:-----------------------------------------|
|
||||
||*Example: 42799258 "Benzyl Alcohol 0.1 ML/ML / Pramoxine hydrochloride 0.01 MG/MG Topical Gel" dispensed in a 1.25oz pack.*|
|
||||
| DRUG_STRENGTH | The denominator_unit is either mg or mL.|
|
||||
||*Example: Benzyl Alcohol in mL and Pramoxine hydrochloride in mg*|
|
||||
|
@ -55,7 +56,7 @@ Field|Required|Type|Description
|
|||
||*Note: The analytical side should check the denominator in the DRUG_STRENGTH table. As mg is used for the second ingredient the factor 1000 will be applied to convert between g and mg.*|
|
||||
|
||||
| 5 | Compounded drugs |
|
||||
|:----|:----|
|
||||
|:-----------------|:-----------------------------------------|
|
||||
||*Example: Ibuprofen 20%/Piroxicam 1% Cream, 30ml in 5ml tubes.*|
|
||||
| DRUG_STRENGTH | We need entries for the ingredients of Ibuprofen and Piroxicam, probably with an amount_value of 1 and a unit of mg.|
|
||||
| DRUG_EXPOSURE | The quantity refers to the total amount of the compound. Use one record in the DRUG_EXPOSURE table for each compound.|
|
||||
|
@ -66,7 +67,7 @@ Field|Required|Type|Description
|
|||
||*Note: The analytical side determines that the denominator for both ingredients in the DRUG_STRENGTH table is mg and applies the factor 1000 to convert between mL/g and mg.*|
|
||||
|
||||
| 6 | Drugs with the active ingredient released over time, e.g. patches |
|
||||
|:----|:----|
|
||||
|:-----------------|:-----------------------------------------|
|
||||
||*Example: Ethinyl Estradiol 0.000833 MG/HR / norelgestromin 0.00625 MG/HR Weekly Transdermal Patch*|
|
||||
| DRUG_STRENGTH | The denominator units refer to hour.|
|
||||
||*Example: Ethinyl Estradiol 0.000833 mg/h / norelgestromin 0.00625 mg/h*|
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:---------------------|:--------|:------------|:----------------------------
|
||||
|drug_era_id|Yes|integer|A unique identifier for each Drug Era.|
|
||||
|person_id|Yes|integer|A foreign key identifier to the Person who is subjected to the Drug during the fDrug Era. The demographic details of that Person are stored in the PERSON table.|
|
||||
|drug_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the Ingredient Concept.|
|
||||
|
@ -23,4 +23,5 @@ Field|Required|Type|Description
|
|||
* The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling.
|
||||
* The choice of a standard Persistence Window of 30 and the non-stockpiling assumption is arbitrary, but has been shown to deliver good results in drug-outcome estimation. Other problems, such as estimation of drug compliance, my require a different or drug-dependent Persistence Window/stockpiling assumption. Researchers are encouraged to consider creating their own Drug Eras with different parameters as Cohorts and store them in the COHORT table.
|
||||
|
||||
![](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?w=800&tok=5ebf4b&media=documentation:cdm:drugera.jpg)
|
||||
![](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?w=800&tok=5ebf4b&media=documentation:cdm:drugera.jpg)\
|
||||
|
|
@ -1,4 +1,5 @@
|
|||
These tables contain information about the clinical events of a patient that are not obtained directly from the raw source data, but from other tables of the CDM.
|
||||
Below provides an entity-relationship diagram highlighting the tables within the Standardized Derived Elements portion of the OMOP Common Data Model:
|
||||
|
||||
![](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?media=documentation:cdm:standardized_derived_elements_3.png)
|
||||
![](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?media=documentation:cdm:standardized_derived_elements_3.png)\
|
||||
|
|
@ -3,7 +3,7 @@ The COST table captures records containing the cost of any medical entity record
|
|||
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.|
|
||||
|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|string(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.|
|
||||
|
@ -33,7 +33,7 @@ One cost record is generated for each response by a payer. In a claims databases
|
|||
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:
|
||||
|
||||
cost_domain_id|corresponding CDM table
|
||||
:----|:----
|
||||
:-------------|:-------------------------
|
||||
|Drug|DRUG_EXPOSURE|
|
||||
|Visit|VISIT_OCCURRENCE|
|
||||
|Procedure|PROCEDURE_OCCURRENCE|
|
||||
|
@ -45,7 +45,7 @@ cost_domain_id|corresponding CDM 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.
|
||||
* 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.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.
|
||||
|
||||
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.|
|
||||
|payer_plan_period_start_date|Yes|date|The start date of the payer plan period.|
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:--------------------------------|:--------|:------------|:------------------------
|
||||
|care_site_id|Yes|integer|A unique identifier for each Care Site.|
|
||||
|care_site_name|No|varchar(255)|The verbatim description or name of the Care Site as in data source|
|
||||
|place_of_service_concept_id|No|integer|A foreign key that refers to a Place of Service Concept ID in the Standardized Vocabularies.|
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:----------------------|:--------|:------------|:--------------------------------------------
|
||||
|location_id|Yes|integer|A unique identifier for each geographic location.|
|
||||
|address_1|No|varchar(50)|The address field 1, typically used for the street address, as it appears in the source data.|
|
||||
|address_2|No|varchar(50)|The address field 2, typically used for additional detail such as buildings, suites, floors, as it appears in the source data.|
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
The PROVIDER table contains a list of uniquely identified healthcare providers. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.
|
||||
|
||||
Field|Required|Type|Description
|
||||
:----|:----|:-----|:-----
|
||||
:-------------------------|:--------|:------------|:-------------------------------------
|
||||
|provider_id|Yes|integer|A unique identifier for each Provider.|
|
||||
|provider_name|No|varchar(50)|A description of the Provider.|
|
||||
|npi|No|varchar(20)|The National Provider Identifier (NPI) of the provider.|
|
||||
|
|
|
@ -1,4 +1,5 @@
|
|||
These tables describe the healthcare provider system responsible for administering the healthcare of the patient, rather than the demographic or clinical events the patient experienced.
|
||||
Below provides an entity-relationship diagram highlighting the tables within the Standardized Health System portion of the OMOP Common Data Model:
|
||||
|
||||
![](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?w=800&tok=82724f&media=documentation:cdm:standard_health_system_data_tables.png)
|
||||
![Health system tables entity-relationship diagram](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?w=800&tok=82724f&media=documentation:cdm:standard_health_system_data_tables.png)\
|
||||
|
|
@ -5,3 +5,4 @@ All metadata about the data should be derived from the data themselves. However,
|
|||
Below provides an entity-relationship diagram highlighting the tables within the Standardized Metadata portion of the OMOP Common Data Model:
|
||||
|
||||
![Metadata entity-relationship diagram](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?media=documentation:cdm:standard_meta_data.png)\
|
||||
|
Loading…
Reference in New Issue