diff --git a/Home.md b/Home.md index f0f4acf..dc39568 100644 --- a/Home.md +++ b/Home.md @@ -1,4 +1,5 @@ -***OMOP Common Data Model v5.1.1 Specifications*** +***OMOP Common Data Model v5.2 Specifications*** +
*Authors: Christian Reich, Patrick Ryan, Rimma Belenkaya, Karthik Natarajan, Clair Blacketer*
*12 July 2017* @@ -44,6 +45,7 @@ Welcome to the Common Data Model wiki! This wiki houses all of the documentation
[CONDITION_OCCURRENCE](wiki/CONDITION_OCCURRENCE)
[MEASUREMENT](wiki/MEASUREMENT)
[NOTE](wiki/NOTE) +
[NOTE_NLP](wiki/NOTE_NLP)
[OBSERVATION](wiki/OBSERVATION)
[FACT_RELATIONSHIP](wiki/FACT_RELATIONSHIP)
diff --git a/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md b/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md index 8006806..e20471d 100644 --- a/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md +++ b/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 @@ -31,4 +33,8 @@ Field|Required|Type|Description * ICD-9-CM Secondary Diagnoses from inpatient and outpatient Claims * 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. \ No newline at end of file + * 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 � should also be used for �Discharge diagnosis� + * Preliminary diagnosis: 4033240 \ No newline at end of file diff --git a/StandardizedClinicalDataTables/DRUG_EXPOSURE.md b/StandardizedClinicalDataTables/DRUG_EXPOSURE.md index 4023d4e..23eac5b 100644 --- a/StandardizedClinicalDataTables/DRUG_EXPOSURE.md +++ b/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. \ No newline at end of file + * 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.) \ No newline at end of file diff --git a/StandardizedClinicalDataTables/NOTE.md b/StandardizedClinicalDataTables/NOTE.md index d26c68c..d03178d 100644 --- a/StandardizedClinicalDataTables/NOTE.md +++ b/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�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 �Subsumes� � �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 �Member Of� � �Has Member� (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 �= 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 �Concept replaces� � �Concept replaced by� 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 = �Has Member� 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 = �Has Member� AND + (concept_id_1 = 55443322132 + OR concept_id_1 = 55443322175 + OR concept_id_1 = 55443322146) + GROUP BY concept_ID_2 + HAVING COUNT(*) = 3 +``` \ No newline at end of file diff --git a/StandardizedClinicalDataTables/NOTE_NLP.md b/StandardizedClinicalDataTables/NOTE_NLP.md new file mode 100644 index 0000000..cf53f30 --- /dev/null +++ b/StandardizedClinicalDataTables/NOTE_NLP.md @@ -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. diff --git a/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md b/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md index efff4a4..50e95cd 100644 --- a/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md +++ b/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) diff --git a/StandardizedClinicalDataTables/VISIT_OCCURRENCE.md b/StandardizedClinicalDataTables/VISIT_OCCURRENCE.md index a156d7b..bb0b30b 100644 --- a/StandardizedClinicalDataTables/VISIT_OCCURRENCE.md +++ b/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 @@ -27,4 +32,11 @@ Field|Required|Type|Description * One visit may involve multiple Care Sites, in which case the ETL must specify how a single care_site id is selected or leave the care_site_id field null. * 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. \ No newline at end of file + * 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 �Patient died�), a record in the Death table should be created with death_type_concept_id = 44818516 (�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 �Emergency Room and Inpatient Visit� was added (CONCEPT_ID 262). \ No newline at end of file diff --git a/StandardizedDerivedElements/CONDITION_ERA.md b/StandardizedDerivedElements/CONDITION_ERA.md index 4bf8789..bde5595 100644 --- a/StandardizedDerivedElements/CONDITION_ERA.md +++ b/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. diff --git a/StandardizedDerivedElements/Standardized-Derived-Elements.md b/StandardizedDerivedElements/Standardized-Derived-Elements.md index 8b2d151..cb81a0e 100644 --- a/StandardizedDerivedElements/Standardized-Derived-Elements.md +++ b/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: diff --git a/StandardizedHealthEconomicsDataTables/COST.md b/StandardizedHealthEconomicsDataTables/COST.md index b2c9cb3..5e98c1a 100644 --- a/StandardizedHealthEconomicsDataTables/COST.md +++ b/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. @@ -53,4 +55,5 @@ cost_domain_id|corresponding CDM table * 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. \ No newline at end of file + * 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. \ No newline at end of file diff --git a/StandardizedHealthEconomicsDataTables/Standardized-Health-Economics-Data-Tables.md b/StandardizedHealthEconomicsDataTables/Standardized-Health-Economics-Data-Tables.md index 26289dd..74f963a 100644 --- a/StandardizedHealthEconomicsDataTables/Standardized-Health-Economics-Data-Tables.md +++ b/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. diff --git a/StandardizedHealthSystemDataTables/Standardized-Health-System-Data-Tables.md b/StandardizedHealthSystemDataTables/Standardized-Health-System-Data-Tables.md index a0d9d80..97db3c9 100644 --- a/StandardizedHealthSystemDataTables/Standardized-Health-System-Data-Tables.md +++ b/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: diff --git a/StandardizedVocabularies/DRUG_STRENGTH.md b/StandardizedVocabularies/DRUG_STRENGTH.md index c0f8f84..92fbd51 100644 --- a/StandardizedVocabularies/DRUG_STRENGTH.md +++ b/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.| @@ -25,4 +26,5 @@ Field|Required|Type|Description * If the strength is provided in % (volume or mass-percent are not distinguished) it is stored in the numerator_value/numerator_unit_concept_id field combination, with both the denominator_value and denominator_unit_concept_id set to NULL. If it is a Quantified Drug the total amount of drug is provided in the denominator_value/denominator_unit_concept_id pair. E.g., the 30 G Isoconazole 2% Topical Cream is provided as 2% / in Clinical Drug and Clinical Drug Component, and as 2% /30 G. * 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. \ No newline at end of file + * 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' \ No newline at end of file diff --git a/_Footer.md b/_Footer.md index 6230684..0d10ef6 100644 --- a/_Footer.md +++ b/_Footer.md @@ -1 +1 @@ -***OMOP Common Data Model v5.1.1 Specifications*** \ No newline at end of file +***OMOP Common Data Model v5.2 Specifications*** \ No newline at end of file diff --git a/_Sidebar.md b/_Sidebar.md index 07b394a..5743af0 100644 --- a/_Sidebar.md +++ b/_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)