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

Updates for CDM v5.2

clairblacketer 2017-07-27 14:35:48 -04:00
parent 9f3d0de09d
commit 99b7081ed4
15 changed files with 220 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Home.md

@ -1,4 +1,5 @@
***OMOP Common Data Model v5.1.1 Specifications***
***OMOP Common Data Model v5.2 Specifications***
<br>*Authors: Christian Reich, Patrick Ryan, Rimma Belenkaya, Karthik Natarajan, Clair Blacketer*
<br>*12 July 2017*
@ -44,6 +45,7 @@ Welcome to the Common Data Model wiki! This wiki houses all of the documentation
<br>[CONDITION_OCCURRENCE](wiki/CONDITION_OCCURRENCE)
<br>[MEASUREMENT](wiki/MEASUREMENT)
<br>[NOTE](wiki/NOTE)
<br>[NOTE_NLP](wiki/NOTE_NLP)
<br>[OBSERVATION](wiki/OBSERVATION)
<br>[FACT_RELATIONSHIP](wiki/FACT_RELATIONSHIP)
<br>

8
StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md

@ -16,8 +16,10 @@ Field|Required|Type|Description
| stop_reason | No | varchar(20) | The reason that the condition was no longer present, as indicated in the source data. |
| provider_id | No | integer | A foreign key to the Provider in the PROVIDER table who was responsible for capturing (diagnosing) the Condition. |
| visit_occurrence_id | No | integer | A foreign key to the visit in the VISIT table during which the Condition was determined (diagnosed). |
| condition_source_concept_id | No | integer | A foreign key to a Condition Concept that refers to the code used in the source. |
| condition_source_value | No | varchar(50) | The source code for the condition as it appears in the source data. This code is mapped to a standard condition concept in the Standardized Vocabularies and the original code is stored here for reference. |
| condition_source_concept_id | No | integer | A foreign key to a Condition Concept that refers to the code used in the source. |
| condition_status_source_value | No | varchar(50) | The source code for the condition status as it appears in the source data. |
| condition_status_concept_id | No | integer | A foreign key to the predefined concept in the standard vocabulary reflecting the condition status | |
### Conventions
@ -32,3 +34,7 @@ Field|Required|Type|Description
* Diagnoses or problems recorded in an EHR.
* The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Typical values include "Discharged", "Resolved", etc. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.
* Condition source codes are typically ICD-9-CM, Read or ICD-10 diagnosis codes from medical claims or discharge status/visit diagnosis codes from EHRs.
* Presently, there is no designated vocabulary, domain, or class that represents condition status. The following concepts from SNOMED are recommended:
* Admitting diagnosis: 4203942
* Final diagnosis: 4230359 <20> should also be used for <20>Discharge diagnosis<69>
* Preliminary diagnosis: 4033240

7
StandardizedClinicalDataTables/DRUG_EXPOSURE.md

@ -14,8 +14,9 @@ Field|Required|Type|Description
|drug_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the Drug concept.|
|drug_exposure_start_date|Yes|date|The start date for the current instance of Drug utilization. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration procedure was recorded.|
|drug_exposure_start_datetime|No|datetime|The start date and time for the current instance of Drug utilization. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration procedure was recorded.|
|drug_exposure_end_date|No|date|The end date for the current instance of Drug utilization. It is not available from all sources.|
|drug_exposure_end_date|Yes|date|The end date for the current instance of Drug utilization. It is not available from all sources.|
|drug_exposure_end_datetime|No|datetime|The end date and time for the current instance of Drug utilization. It is not available from all sources.|
|verbatim_end_date|No|date|The known end date of a drug_exposure as provided by the source|
|drug_type_concept_id|Yes|integer| A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Drug Exposure recorded. It indicates how the Drug Exposure was represented in the source data.|
|stop_reason|No|varchar(20)|The reason the Drug was stopped. Reasons include regimen completed, changed, removed, etc.|
|refills|No|integer|The number of refills after the initial prescription. The initial prescription is not counted, values start with 0.|
@ -23,8 +24,6 @@ Field|Required|Type|Description
|days_supply|No|integer|The number of days of supply of the medication as recorded in the original prescription or dispensing record.|
|sig|No|clob|The directions ("signetur") on the Drug prescription as recorded in the original prescription (and printed on the container) or dispensing record.|
|route_concept_id|No|integer|A foreign key to a predefined concept in the Standardized Vocabularies reflecting the route of administration.|
|effective_drug_dose|No|float|Numerical value of Drug dose for this Drug Exposure record.|
|dose_unit_concept_ id|No|integer|A foreign key to a predefined concept in the Standardized Vocabularies reflecting the unit the effective_drug_dose value is expressed.|
|lot_number|No|varchar(50)|An identifier assigned to a particular quantity or lot of Drug product from the manufacturer.|
|provider_id|No|integer|A foreign key to the provider in the provider table who initiated (prescribed or administered) the Drug Exposure.|
|visit_occurrence_id|No|integer|A foreign key to the visit in the visit table during which the Drug Exposure was initiated.|
@ -41,7 +40,7 @@ Field|Required|Type|Description
* A Drug Type is assigned to each Drug Exposure to track from what source the information was drawn or inferred from. The valid domain_id for these Concepts is "Drug Type".
* The content of the refills field determines the current number of refills, not the number of remaining refills. For example, for a drug prescription with 2 refills, the content of this field for the 3 Drug Exposure events are null, 1 and 2.
* The route_concept_id refers to a Standard Concepts of the "Route" domain. Note: Route information can also be inferred from the Drug product itself by determining the Drug Form of the Concept, creating some partial overlap of the same type of information. However, the route_concept_id could resolve ambiguities of how a certain Drug Form is actually applied. For example, a "Solution" could be used orally or parentherally, and this field will make this determination.
* The Effective Drug Dose and the Dose Unit Concepts are provided in cases when dose information is explicitly provided, as it is typically for pediatric and chemotherapeutic treatments. The domain_id for the Dose Unit Concept is "Unit". Note: this information can only be present if the Drug contains a single active ingredient. Combination products which have doses for each ingredient need to be recorded as separate records.
* The lot_number field contains an identifier assigned from the manufacturer of the Drug product.
* If possible, the visit in which the drug was prescribed or delivered is recorded in the visit_occurrence_id field through a reference to the visit table.
* If possible, the prescribing or administering provider (physician or nurse) is recorded in the provider_id field through a reference to the provider table.
* The drug_exposure_end_date denotes the day the drug exposure ended for the patient. This could be that the duration of drug_supply was reached (in which case drug_exposure_end_date = drug_exposure_start_date + days_supply -1), or because the exposure was stopped (medication changed, medication discontinued, etc.)

114
StandardizedClinicalDataTables/NOTE.md

@ -7,7 +7,11 @@ Field|Required|Type|Description
|note_date |Yes|date|The date the note was recorded.|
|note_datetime|No|datetime|The date and time the note was recorded.|
|note_type_concept_id|Yes|integer|A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the type, origin or provenance of the Note.|
|note_class_concept_id| Yes| integer| A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the HL7 LOINC Document Type Vocabulary classification of the note.|
|note_title |No| varchar(250)| The title of the Note as it appears in the source.|
|note_text|Yes|RBDMS dependent text|The content of the Note.|
|encoding_concept_id |Yes |integer| A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the note character encoding type|
|language_concept_id |Yes |integer |A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the language of the note|
|provider_id|No|integer|A foreign key to the Provider in the PROVIDER table who took the Note.|
|note_source_value|No|varchar(50)|The source value associated with the origin of the note|
|visit_occurrence_id|No|integer|Foreign key to the Visit in the VISIT_OCCURRENCE table when the Note was taken.|
@ -16,4 +20,112 @@ Field|Required|Type|Description
* The NOTE table contains free text (in ASCII, or preferably in UTF8 format) taken by a healthcare Provider.
* The Visit during which the note was written is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
* The Provider making the note is recorded through a reference to the PROVIDER table. This information is not always available.
* The type of note_text is CLOB or string(MAX) depending on RDBMS
* The type of note_text is CLOB or varchar(MAX) depending on RDBMS
* note_class_concept_id is a foreign key to the CONCEPT table to describe a standardized combination of five LOINC axes (role, domain, setting, type of service, and document kind). See below for description.
### Mapping of clinical documents to Clinical Document Ontology (CDO) and standard terminology
HL7/LOINC CDO is a standard for consistent naming of documents to support a range of use cases: retrieval, organization, display, and exchange. It guides the creation of LOINC codes for clinical notes. CDO annotates each document with 5 dimensions:
* **Kind of Document:** Characterizes the generalc structure of the document at a macro level (e.g. Anesthesia Consent)
* **Type of Service**: Characterizes the kind of service or activity (e.g. evaluations, consultations, and summaries). The notion of time sequence, e.g., at the beginning (admission) at the end (discharge) is subsumed in this axis. Example: Discharge Teaching.
* **Setting:** Setting is an extension of CMS<4D>s definitions (e.g. Inpatient, Outpatient)
* **Subject Matter Domain (SMD):** Characterizes the subject matter domain of a note (e.g. Anesthesiology)
* **Role:** Characterizes the training or professional level of the author of the document, but does not break down to specialty or subspecialty (e.g. Physician)
Each combination of these 5 dimensions should roll up to a unique LOINC code. For example, Dentistry Hygienist Outpatient Progress note (LOINC code 34127-1) has the following dimensions:
* According to CDO requirements, only 2 of the 5 dimensions are required to properly annotate a document: Kind of Document and any one of the other 4 dimensions.
* However, not all the permutations of the CDO dimensions will necessarily yield an existing LOINC code.2 HL7/LOINC workforce is committed to establish new LOINC codes for each new encountered combination of CDO dimensions. 3
Automation of mapping of clinical notes to a standard terminology based on the note title is possible when it is driven by ontology (aka CDO). Mapping to individual LOINC codes which may or may not exist for a particular note type cannot be fully automated. To support mapping of clinical notes to CDO in OMOP CDM, we propose the following approach:
#### 1. Add all LOINC concepts representing 5 CDO dimensions to the Concept table. For example:
Field | Record 1 | Record 2
:-- | :-- | :--
concept_id | 55443322132 | 55443322175
concept_name | Administrative note | Against medical advice note
concept_code | LP173418-7 | LP173388-2
vocabulary_id | LOINC | LOINC
#### 2. Represent CDO hierarchy in the Concept_Relationship table using the <20>Subsumes<65> <20> <20>Is a<> relationship pair. For example:
Field | Record 1 | Record 2
:-- | :-- | :--
concept_id_1 | 55443322132 | 55443322175
concept_id_2 | 55443322175 | 55443322132
relationship_id | Subsumes | Is a
#### 3. Add LOINC document codes to the Concept table (e.g. Dentistry Hygienist Outpatient Progress note, LOINC code 34127-1). For example:
Field | Record 1 | Record 2
:-- | :-- | :--
concept_id | 193240 | 193241
concept_name | Dentistry Hygienist Outpatient Progress note | Consult note
concept_code | 34127-1 | 11488-4
vocabulary_id | LOINC | LOINC
#### 4. Represent dimensions of each document concept in Concept_Relationship table by its relationships to the respective concepts from CDO.
* Use the <20>Member Of<4F> <20> <20>Has Member<65> (new) relationship pair.
* Using example from the Dentistry Hygienist Outpatient Progress note (LOINC code 34127-1):
concept_id_1 | concept_id_1 | relationship_id
:-- | :-- | :--
193240 | 55443322132 | Member Of
55443322132 | 193240 | Has Member
193240 | 55443322175 | Member Of
55443322175 | 193240 | Has Member
193240 | 55443322166 | Member Of
55443322166 | 193240 | Has Member
193240 | 55443322107 | Member Of
55443322107 | 193240 | Has Member
193240 | 55443322146 | Member Of
55443322146 | 193240 | Has Member
Where concept codes represent the following concepts:
Content | Description
:---------- | :--------------------------------------------------------------------
193240 | Corresponds to LOINC 34127-1, Dentistry Hygienist Outpatient Progress note
55443322132 | Corresponds to LOINC LP173418-7, Kind of Document = Note
55443322175 | Corresponds to LOINC LP173213-2, Type of Service = Progress
55443322166 | Corresponds to LOINC LP173051-6, Setting = Outpatient
55443322107 | Corresponds to LOINC LP172934-4, Subject Matter Domain <20>= Dentistry
55443322146 | Corresponds to LOINC LP173071-4, Role = Hygienist
Most of the codes will not have all 5 dimensions. Therefore, they may be represented by 2-5 relationship pairs.
#### 5. If LOINC does not have a code corresponding to a permutation of the 5 CDO encountered in the source, this code will be generated as OMOP vocabulary code.
* Its relationships to the CDO dimensions will be represented exactly as those of existing LOINC concepts (as described above). If/when a proper LOINC code for this permutation is released, the old code should be deprecated. Transition between the old and new codes should be represented by <20>Concept replaces<65> <20> <20>Concept replaced by<62> pairs.
#### 6. Mapping from the source data will be performed to the 2-5 CDO dimensions.
Query below finds LOINC code for Dentistry Hygienist Outpatient Progress note (see example above) that has all 5 dimensions:
```sql
SELECT
FROM Concept_Relationship
WHERE relationship_id = <20>Has Member<65> AND
(concept_id_1 = 55443322132
OR concept_id_1 = 55443322175
OR concept_id_1 = 55443322166
OR concept_id_1 = 55443322107
OR concept_id_1 = 55443322146)
GROUP BY concept_ID_2
```
If less than 5 dimensions are available, `HAVING COUNT(n)` clause should be added to get a unique record at the intersection of these dimensions. n is the number of dimensions available:
```sql
SELECT
FROM Concept_Relationship
WHERE relationship_id = <20>Has Member<65> AND
(concept_id_1 = 55443322132
OR concept_id_1 = 55443322175
OR concept_id_1 = 55443322146)
GROUP BY concept_ID_2
HAVING COUNT(*) = 3
```

50
StandardizedClinicalDataTables/NOTE_NLP.md Normal file

@ -0,0 +1,50 @@
The NOTE_NLP table will encode all output of NLP on clinical notes. Each row represents a single extracted term from a note.
Field | Required | Type | Description
:------------------------------- | :-------- | :------------ | :---------------------------------------------------
note_nlp_id | Yes | Big Integer | A unique identifier for each term extracted from a note.
note_id | Yes | integer | A foreign key to the Note table note the term was extracted from.
section_concept_id | No | integer | A foreign key to the predefined Concept in the Standardized Vocabularies representing the section of the extracted term.
snippet | No | varchar(250) | A small window of text surrounding the term.
offset | No | varchar(50) | Character offset of the extracted term in the input note.
lexical_variant | Yes | varchar(250) | Raw text extracted from the NLP tool.
note_nlp_concept_id | No | integer | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the normalized concept for the extracted term. Domain of the term is represented as part of the Concept table.
note_nlp_source_concept_id | no | integer | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system
nlp_system | No | varchar(250) | Name and version of the NLP system that extracted the term.Useful for data provenance.
nlp_date | Yes | date | The date of the note processing.Useful for data provenance.
nlp_date_time | No | datetime | The date and time of the note processing. Useful for data provenance.
term_exists | No | varchar(1) | A summary modifier that signifies presence or absence of the term for a given patient. Useful for quick querying. *
term_temporal | No | varchar(50) | An optional time modifier associated with the extracted term. (for now “past” or “present” only). Standardize it later.
term_modifiers | No | varchar(2000) | A compact description of all the modifiers of the specific term extracted by the NLP system. (e.g. “son has rash” ? “negated=no,subject=family, certainty=undef,conditional=false,general=false”).
### Conventions
**Term_exists**
Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false:
* Negation = true
* Subject = [anything other than the patient]
* Conditional = true
* Rule_out = true
* Uncertain = very low certainty or any lower certainties
A complete lack of modifiers would make Term_exists true.
For the modifiers that are there, they would have to have these values:
* Negation = false
* Subject = patient
* Conditional = false
* Rule_out = false
* Uncertain = true or high or moderate or even low (could argue about low)
**Term_temporal**
Term_temporal is to indicate if a condition is “present” or just in the “past”.
The following would be past:
* History = true
* Concept_date = anything before the time of the report
**Term_modifiers**
Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers. A list of allowable modifiers (e.g., signature for medications) and their possible values will be standardized later.

1
StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md

@ -9,6 +9,7 @@
[CONDITION_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE)
[MEASUREMENT](https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT)
[NOTE](https://github.com/OHDSI/CommonDataModel/wiki/NOTE)
[NOTE_NLP](https://github.com/OHDSI/CommonDataModel/wiki/NOTE_NLP)
[OBSERVATION](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION)
[FACT_RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP)

12
StandardizedClinicalDataTables/VISIT_OCCURRENCE.md

@ -14,6 +14,11 @@ Field|Required|Type|Description
|care_site_id|No|integer|A foreign key to the care site in the care site table that was visited.|
|visit_source_value|No|string(50)|The source code for the visit as it appears in the source data.|
|visit_source_concept_id|No|Integer|A foreign key to a Concept that refers to the code used in the source.|
|admitting_source_concept_id| |Integer |No |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.|
|admitting_source_value |Varchar(50)| No| The source code for the admitting source as it appears in the source data.|
|discharge_to_concept_id| Integer |No |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
|discharge_to_source_value| Varchar(50)| No| The source code for the discharge disposition as it appears in the source data.|
|preceding_visit_occurrence_id |Integer| No |A foreign key to the VISIT_OCCURRENCE table of the visit immediately preceding this visit|
### Conventions
@ -28,3 +33,10 @@ Field|Required|Type|Description
* Visits are recorded in various data sources in different forms with varying levels of standardization. For example:
* Medical Claims include Inpatient Admissions, Outpatient Services, and Emergency Room visits.
* Electronic Health Records may capture Person visits as part of the activities recorded depending whether the EHR system is used at the different Care Sites.
* In addition to the "Place of Service" vocabulary the following SNOMED concepts for discharge disposition can be used:
* Patient died: 4216643
* Absent without leave: 44814693
* Patient self-discharge against medical advice: 4021968
* In the case where a patient died during admission (Visit_Occurrence.discharge_disposition_concept_id = 4216643 <20>Patient died<65>), a record in the Death table should be created with death_type_concept_id = 44818516 (<28>EHR discharge status "Expired").
* PRECEDING_VISIT_ID can be used to link a visit immediately preceding the current visit
* Some EMR systems combine emergency room followed by inpatient admission into one visit, and it is close to impossible to separate the two. To annotate this visit type, a new visit concept <20>Emergency Room and Inpatient Visit<69> was added (CONCEPT_ID 262).

10
StandardizedDerivedElements/CONDITION_ERA.md

@ -1,8 +1,10 @@
A Condition Era is defined as a span of time when the Person is assumed to have a given condition.
Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence. Combining individual Condition Occurrences into a single Condition Era serves two purposes:
* It allows aggregation of chronic conditions that require frequent ongoing care, instead of treating each Condition Occurrence as an independent event.
* It allows aggregation of multiple, closely timed doctor visits for the same Condition to avoid double-counting the Condition Occurrences.
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.
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
:----------------------------|:--------|:------------|:----------------------------------
@ -16,7 +18,7 @@ Field|Required|Type|Description
### Conventions
* Condition Era records will be derived from the records in the CONDITION_OCCURRENCE table using a standardized algorithm.
* Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval.
The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers.
The Condition Era Start Date is the start date of the first Condition Occurrence.
The Condition Era End Date is the end date of the last Condition Occurrence.
* The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers.
* The Condition Era Start Date is the start date of the first Condition Occurrence.
* The Condition Era End Date is the end date of the last Condition Occurrence.
* Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.

6
StandardizedDerivedElements/Standardized-Derived-Elements.md

@ -1,3 +1,9 @@
[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)
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:

3
StandardizedHealthEconomicsDataTables/COST.md

@ -24,6 +24,8 @@ Field|Required|Type|Description
|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|string(50)|The source code for the Revenue code as it appears in the source data, stored here for reference.|
|drg_concept_id| integer| No |A foreign key to the predefined concept in the DRG Vocabulary reflecting the DRG for a visit.|
|drg_source_value| varchar(3)| No| The 3-digit DRG source code as it appears in the source data.|
### 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.
@ -54,3 +56,4 @@ cost_domain_id|corresponding CDM table
* 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.

3
StandardizedHealthEconomicsDataTables/Standardized-Health-Economics-Data-Tables.md

@ -1 +1,4 @@
[PAYER_PLAN_PERIOD](https://github.com/OHDSI/CommonDataModel/wiki/PAYER_PLAN_PERIOD)
[COST](https://github.com/OHDSI/CommonDataModel/wiki/COST)
These tables contain cost information about healthcare. They are dependent on the healthcare delivery system the patient is involved in, which may vary significantly within a country and across different countries. However, the current model is focused on the US healthcare system.

4
StandardizedHealthSystemDataTables/Standardized-Health-System-Data-Tables.md

@ -1,3 +1,7 @@
[LOCATION](https://github.com/OHDSI/CommonDataModel/wiki/LOCATION)
[CARE_SITE](https://github.com/OHDSI/CommonDataModel/wiki/CARE_SITE)
[PROVIDER](https://github.com/OHDSI/CommonDataModel/wiki/PROVIDER)
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:

2
StandardizedVocabularies/DRUG_STRENGTH.md

@ -10,6 +10,7 @@ Field|Required|Type|Description
|numerator_unit_concept_id|No|integer|A foreign key to the Concept in the CONCEPT table representing the identifier for the numerator Unit for the concentration of active ingredient.|
|denominator_value|No|float|The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.).|
|denominator_unit_concept_id|No|integer|A foreign key to the Concept in the CONCEPT table representing the identifier for the denominator Unit for the concentration of active ingredient.|
|box_size|No|integer|The number of units of Clinical of Branded Drug, or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient|
|valid_start_date|Yes|date|The date when the Concept was first recorded. The default value is 1-Jan-1970.|
|valid_end_date|Yes|date|The date when the concept became invalid because it was deleted or superseded (updated) by a new Concept. The default value is 31-Dec-2099.|
|invalid_reason|No|varchar(1)|Reason the concept was invalidated. Possible values are 'D' (deleted), 'U' (replaced with an update) or NULL when valid_end_date has the default value.|
@ -26,3 +27,4 @@ Field|Required|Type|Description
* Sometimes, one Ingredient is listed with different units within the same drug. This is very rare, and usually this happens if there are more than one Precise Ingredient. For example, 'Penicillin G, Benzathine 150000 UNT/ML / Penicillin G, Procaine 150000 MEQ/ML Injectable Suspension' contains Penicillin G in two different forms.
* Sometimes, different ingredients in liquid drugs are listed with different units in the denominator_unit_concept_id. This is usually the case if the ingredients are liquids themselves (concentration provided as mL/mL) or solid substances (mg/mg). In these cases, the general assumptions is made that the density of the drug is that of water, and one can assume 1 g = 1 mL.
* All Drug vocabularies containing Standard Concepts have entries in the DRUG_STRENGTH table.
* There is now a Concept Class for supplier information whose relationships can be found in CONCEPT_RELATIONSHIP with a relationship_id of 'Has supplier' and 'Supplier of'

2
_Footer.md

@ -1 +1 @@
***OMOP Common Data Model v5.1.1 Specifications***
***OMOP Common Data Model v5.2 Specifications***

1
_Sidebar.md

@ -38,6 +38,7 @@
* [CONDITION_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE)
* [MEASUREMENT](https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT)
* [NOTE](https://github.com/OHDSI/CommonDataModel/wiki/NOTE)
* [NOTE_NLP](https://github.com/OHDSI/CommonDataModel/wiki/NOTE_NLP)
* [OBSERVATION](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION)
* [FACT_RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP)