Merge branch 'master' into CDM_v5.2.0
This commit is contained in:
commit
1a146846c8
|
@ -1,4 +1,5 @@
|
|||
***OMOP Common Data Model v5.2 Specifications***
|
||||
|
||||
<br>*Authors: Christian Reich, Patrick Ryan, Rimma Belenkaya, Karthik Natarajan, Clair Blacketer*
|
||||
<br>*12 July 2017*
|
||||
|
||||
|
|
|
@ -36,5 +36,5 @@ Field|Required|Type|Description
|
|||
* 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’
|
||||
* Final diagnosis: 4230359 <EFBFBD> should also be used for <20>Discharge diagnosis<69>
|
||||
* Preliminary diagnosis: 4033240
|
|
@ -29,7 +29,7 @@ HL7/LOINC CDO is a standard for consistent naming of documents to support a rang
|
|||
|
||||
* **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)
|
||||
* **Setting:** Setting is an extension of CMS<EFBFBD>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)
|
||||
|
||||
|
@ -49,7 +49,7 @@ 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:
|
||||
#### 2. Represent CDO hierarchy in the Concept_Relationship table using the <EFBFBD>Subsumes<EFBFBD> <20> <20>Is a<> relationship pair. For example:
|
||||
|
||||
Field | Record 1 | Record 2
|
||||
:-- | :-- | :--
|
||||
|
@ -68,7 +68,7 @@ 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.
|
||||
* Use the <EFBFBD>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
|
||||
|
@ -92,14 +92,14 @@ Content | Description
|
|||
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
|
||||
55443322107 | Corresponds to LOINC LP172934-4, Subject Matter Domain <EFBFBD>= 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.
|
||||
* 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 <EFBFBD>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.
|
||||
|
||||
|
@ -108,7 +108,7 @@ Query below finds LOINC code for Dentistry Hygienist Outpatient Progress note (s
|
|||
```sql
|
||||
SELECT
|
||||
FROM Concept_Relationship
|
||||
WHERE relationship_id = ‘Has Member’ AND
|
||||
WHERE relationship_id = <EFBFBD>Has Member<65> AND
|
||||
(concept_id_1 = 55443322132
|
||||
OR concept_id_1 = 55443322175
|
||||
OR concept_id_1 = 55443322166
|
||||
|
@ -122,7 +122,7 @@ If less than 5 dimensions are available, `HAVING COUNT(n)` clause should be adde
|
|||
```sql
|
||||
SELECT
|
||||
FROM Concept_Relationship
|
||||
WHERE relationship_id = ‘Has Member’ AND
|
||||
WHERE relationship_id = <EFBFBD>Has Member<65> AND
|
||||
(concept_id_1 = 55443322132
|
||||
OR concept_id_1 = 55443322175
|
||||
OR concept_id_1 = 55443322146)
|
||||
|
|
|
@ -37,6 +37,6 @@ Field|Required|Type|Description
|
|||
* 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").
|
||||
* In the case where a patient died during admission (Visit_Occurrence.discharge_disposition_concept_id = 4216643 <EFBFBD>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 “Emergency Room and Inpatient Visit” was added (CONCEPT_ID 262).
|
||||
* 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 <EFBFBD>Emergency Room and Inpatient Visit<69> was added (CONCEPT_ID 262).
|
|
@ -27,7 +27,6 @@ Field|Required|Type|Description
|
|||
|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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue