Merge branch 'master' into CDM_v5.2.0

This commit is contained in:
clairblacketer 2017-07-20 11:22:49 -04:00 committed by GitHub
commit 1a146846c8
5 changed files with 11 additions and 11 deletions

View File

@ -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*

View File

@ -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

View File

@ -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 CMSs 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)

View File

@ -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).

View File

@ -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.