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

Addition of death_datetime to all Person tables. Commit of documentation changes for the clinical data tables.

This commit is contained in:
clairblacketer 2018-09-27 11:46:34 -04:00
parent 86dbcec3e0
commit 4a03f4f9cd
24 changed files with 234 additions and 303 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/CommonDataModel_Wiki_Files/Background/Background.md
View File

@ -5,7 +5,7 @@
The Observational Medical Outcomes Partnership (OMOP) was a public-private partnership established to inform the appropriate use of observational healthcare databases for studying the effects of medical products. Over the course of the 5-year project and through its community of researchers from industry, government, and academia, OMOP successfully achieved its aims to:
- Conduct methodological research to empirically evaluate the performance of various analytical methods on their ability to identify true associations and avoid false findings
- Develop tools and capabilities for transforming, characterizing, and analyzing disparate data sources across the health care delivery spectrum
- Develop tools and capabilities for transforming, characterizing, and analysing disparate data sources across the health care delivery spectrum
- Establish a shared resource so that the broader research community can collaboratively advance the science
The results of OMOP's research has been widely published and presented at scientific conferences, including [annual symposia](https://www.ohdsi.org/events/2018-ohdsi-symposium/).

21
Documentation/CommonDataModel_Wiki_Files/Background/Data-Model-Conventions.md
View File

@ -31,7 +31,7 @@ Many tables contain equivalent information multiple times: As a Source Value, a
* Source Values contain the codes from public code systems such as ICD-9-CM, NDC, CPT-4 etc. or locally controlled vocabularies (such as F for female and M for male) copied from the source data. Source Values are stored in the *_SOURCE_VALUE fields in the data tables.
* Concepts are CDM-specific entities that represent the meaning of a clinical fact. Most concepts are based on code systems used in healthcare (called Source Concepts), while others were created de-novo (CONCEPT_CODE = 'OMOP generated'). Concepts have unique IDs across all domains.
* Source Concepts are the concepts that represent the code used in the source. Source Concepts are only used for common healthcare code systems, not for OMOP-generated Concepts. Source Concepts are stored in the *_SOURCE_CONCEPT_ID field in the data tables.
* Standard Concepts are those concepts that are used to define the unique meaning of a clinical entity. For each entity there is one Standard Concept. Standard Concepts are typically drawn from existing public vocabulary sources. Concepts that have the equivalent meaning to a Standard Concept are mapped to the Standard Concept. Standard Concepts are referred to in the CONCEPT_ID field of the data tables.
* Standard Concepts are those concepts that are used to define the unique meaning of a clinical entity. For each entity there is one Standard Concept. Standard Concepts are typically drawn from existing public vocabulary sources. Concepts that have the equivalent meaning to a Standard Concept are mapped to the Standard Concept. Standard Concepts are referred to in the <entity>_CONCEPT_ID field of the data tables.
Source Values are only provided for convenience and quality assurance (QA) purposes. Source Values and Source Concepts are optional, while Standard Concepts are mandatory. Source Values may contain information that is only meaningful in the context of a specific data source.
@ -42,28 +42,29 @@ Type Concepts (ending in _TYPE_CONCEPT_ID) and general Concepts (ending in _CONC
### Time span of available data
Data tables for clinical data contain a datetime stamp (ending in _DATETIME, _START_DATETIME or _END_DATETIME), indicating when that clinical event occurred. As a rule, no record can be outside of a valid OBSERVATION_PERIOD time period. Clinical information that relates to events that happened prior to the first OBSERVATION_PERIOD will be captured as a record in the OBSERVATION table as 'Medical history' (CONCEPT_ID = 43054928), with the OBSERVATION_DATETIME set to the first OBSERVATION_PERIOD_START_DATE of that patient, and the VALUE_AS_CONCEPT_ID set to the corresponding CONCEPT_ID for the condition/drug/procedure that occurred in the past. No data occurring after the last OBSERVATION_PERIOD_END_DATE can be valid records in the CDM.
* When mapping source data to the CDM, if time is unknown the default time of 00:00:00 should be chosen. If a time of 00:00:00 is given in the source data it should be shifted to 00:00:01.
### Content of each table
For the tables of the main domains of the CDM it is imperative that concepts used are strictly limited to the domain. For example, the CONDITION_OCCURRENCE table contains only information about conditions (diagnoses, signs, symptoms), but no information about procedures. Not all source coding schemes adhere to such rules. For example, ICD-9-CM codes, which contain mostly diagnoses of human disease, also contain information about the status of patients having received a procedure. The ICD-9-CM code V20.3 'Newborn health supervision' defines a continuous procedure and is therefore stored in the PROCEDURE_OCCURRENCE table.
### Differentiating between source values, source concept ids, and standard concept ids
### Differentiating between Source Values, Source Concept Ids, and Standard Concept Ids
Each table contains fields for source values, source concept ids, and standard concept ids.
Each table contains fields for Source Values, Source Concept Ids, and Standard Concept Ids.
* Source Values are fields to maintain the verbatim information from the source database, stored as unstructured text, and are generally not to be used by any standardized analytics.
* Source Values are fields to maintain the verbatim information from the source database, stored as unstructured text, and are generally not to be used by any standardized analytics. There is no standardization for these fields and these columns can be used as the local CDM builders see fit. A typical example would be an ICD-9 code without the decimal from an administrative claim as condition_source_value = '78702' which is how it appeared in the source.
* Source Concept Ids provide a repeatable representation of the source concept, when the source data are drawn from a commonly-used, internationally-recognized vocabulary that has been distributed with the OMOP Common Data Model. Specific use cases where source vocabulary-specific analytics are required can be accommodated by the use of the *_SOURCE_CONCEPT_ID fields, but these are generally not applicable across disparate data sources. The standard *_CONCEPT_ID fields are **strongly suggested** to be used in all standardized analytics, as specific vocabularies have been established within each data domain to facilitate standardization of both structure and content within the OMOP Common Data Model.
The following provide conventions for processing source data using these three fields in each domain:
When processing data where the source value is either free text or a reference to a coding scheme that is not contained within the Standardized Vocabularies:
- Map all source values directly to standard CONCEPT_IDs. Store these mappings in the SOURCE_TO_CONCEPT_MAP table.
- Map all Source Values directly to Standard CONCEPT_IDs. Store these mappings in the SOURCE_TO_CONCEPT_MAP table.
- If the source code is not mappable to a vocabulary term, the SOURCE_CONCEPT_ID field is set to 0
When processing your data where source value is a reference to a coding scheme contained within the Standardized Vocabularies:
When processing your data where Source Value is a reference to a coding scheme contained within the Standardized Vocabularies:
- Map all your source values to the corresponding CONCEPT_IDs in the source vocabulary. Store the result in the SOURCE_CONCEPT_ID field.
- Map all your Source Values to the corresponding CONCEPT_IDs in the Source Vocabulary. Store the result in the SOURCE_CONCEPT_ID field.
- If the source code follows the same formatting as the distributed vocabulary, the mapping can be directly obtained from the CONCEPT table using the CONCEPT_CODE field.
- If the source code uses alternative formatting (ex. format has removed decimal point from ICD-9 codes), you will need to perform the formatting transformation within the ETL. In this case, you may wish to store the mappings from original codes to SOURCE_CONCEPT_IDs in the SOURCE_TO_CONCEPT_MAP table.
- If the source code is not mappable to a vocabulary term, the SOURCE_CONCEPT_ID field is set to 0
@ -71,14 +72,14 @@ When processing your data where source value is a reference to a coding scheme c
- Each SOURCE_CONCEPT_ID can have 1 or more Standard CONCEPT_IDs mapped to it. Each Standard CONCEPT_ID belongs to only one primary domain but when a source CONCEPT_ID maps to multiple Standard CONCEPT_IDs, it is possible for that SOURCE_CONCEPT_ID to result in records being produced across multiple domains. For example, ICD-10-CM code Z34.00 'Encounter for supervision of normal first pregnancy, unspecified trimester' will be mapped to the SNOMED concept 'Routine antenatal care' in the procedure domain and the concept in the condition domain 'Primagravida'. It is also possible for one SOURCE_CONCEPT_ID to map to multiple Standard CONCEPT_IDs within the same domain. For example, ICD-9-CM code 070.43 'Hepatitis E with hepatic coma' maps to the SNOMED concept for 'Acute hepatitis E' and a second SNOMED concept for 'Hepatic coma', in which case multiple CONDITION_OCCURRENCE records will be generated for the one source value record.
- If the SOURCE_CONCEPT_ID is not mappable to any Standard CONCEPT_ID, the CONCEPT_ID field is set to 0.
- Write the data record into the table(s) corresponding to the domain of the Standard CONCEPT_ID(s).
- If the source value is mapped to a SOURCE_CONCEPT_ID but the SOURCE_CONCEPT_ID is not mapped to a Standard CONCEPT_ID, then the domain for the data record, and hence it's table location, is determined by the DOMAIN_ID field of the CONCEPT record the SOURCE_CONCEPT_ID refers to. The Standard CONCEPT_ID is set to 0.
- If the source value cannot be mapped to a SOURCE_CONCEPT_ID or Standard CONCEPT_ID, then direct the data record to the most appropriate CDM domain based on your local knowledge of the intent of the source data and associated value. For example, if the unmappable source value came from a 'diagnosis' table then, in the absence of other information, you may choose to record that fact in the CONDITION_OCCURRENCE table.
- If the Source Value is mapped to a SOURCE_CONCEPT_ID but the SOURCE_CONCEPT_ID is not mapped to a Standard CONCEPT_ID, then the domain for the data record, and hence it's table location, is determined by the DOMAIN_ID field of the CONCEPT record the SOURCE_CONCEPT_ID refers to. The Standard CONCEPT_ID is set to 0.
- If the Source Value cannot be mapped to a SOURCE_CONCEPT_ID or Standard CONCEPT_ID, then direct the data record to the most appropriate CDM domain based on your local knowledge of the intent of the source data and associated value. For example, if the unmappable Source Value came from a 'diagnosis' table then, in the absence of other information, you may choose to record that fact in the CONDITION_OCCURRENCE table.
Each Standard CONCEPT_ID field has a set of allowable CONCEPT_ID values. The allowable values are defined by the domain of the concepts. For example, there is a domain concept of 'Gender', for which there are only two allowable standard concepts of practical use (8507 - 'Male', 8532- 'Female') and one allowable generic concept to represent a standard notion of 'no information' (concept_id = 0).
There is no constraint on allowed CONCEPT_IDs within the SOURCE_CONCEPT_ID fields.
### Custom source_to_concept_maps
### Custom SOURCE_TO_CONCEPT_MAPs
When the source data uses coding systems that are not currently in the Standardized Vocabularies (e.g. ICPC codes for diagnoses), the convention is to store the mapping of such source codes to Standard Concepts in the SOURCE_TO_CONCEPT_MAP table. The codes used in the data source can be recorded in the SOURCE_VALUE fields, but no SOURCE_CONCEPT_ID will be available.

2
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md
View File

@ -12,7 +12,7 @@ Field|Required|Type|Description
| condition_start_datetime | Yes | datetime | The date and time when the instance of the Condition is recorded. |
| condition_end_date | No | date | The date when the instance of the Condition is considered to have ended. |
| condition_end_datetime | No | datetime | The date when the instance of the Condition is considered to have ended. |
| condition_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the Condition was recorded, the level of standardization, and the type of occurrence. |
| condition_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the Condition was recorded, the level of standardization, and the type of occurrence. These belong to the 'Condition Type' vocabulary |
| condition_status_concept_id | No | integer | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies reflecting the point of care at which the Condition was diagnosed. |
| 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. |

30
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/DEATH.md
View File

@ -1,21 +1,21 @@
The 'Death' domain contains the clinical event for how and when a Person dies. A Person can have up to one record if the source system contains evidence about the Death, such as:
As of OMOP CDM v6.0, the DEATH table has been deprecated in favor of storing the cause of death in the CONDITION_OCCURRENCE table, any observations relating to death stored in the OBSERVATION table, and a singular death date will be chosen and stored in the PERSON table.
The 'Death' domain contains the clinical events surrounding how and when a Person dies. A Person can have information in the source system containing evidence about the Death, such as:
* Condition Code in the Header or Detail information of claims
* Status of enrollment into a health plan
* Explicit record in EHR data
Field|Required|Type|Description
:-------------------------|:--------|:-----|:----------------------------------------------
| person_id | Yes | bigint | A foreign key identifier to the deceased Person. The demographic details of that Person are stored in the PERSON table. |
| death_date | No | date | The date the Person was deceased. If the precise date including day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day. |
| death_datetime | Yes | datetime | The date and time the Person was deceased. If the precise date including day or month is not known or not allowed, December is used as the default month, the last day of the month the default day, and midnight the default time.|
| death_type_concept_id | Yes | integer | A foreign key referring to the predefined Concept identifier in the Standardized Vocabularies reflecting how the Death was represented in the source data. |
| cause_concept_id | No | integer | A foreign key referring to a Standard Concept identifier in the Standardized Vocabularies belonging to the 'Condition" domain. |
| cause_source_value | No | varchar(50)| The source code for the cause of death 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.|
| cause_source_concept_id | No | integer | A foreign key to the Concept that refers to the code used in the source. Note, this variable name is abbreviated to ensure it will be allowable across database platforms. |
### Conventions
* Living patients should not contain any information in the DEATH table.
* Each Person may have more than one record of death in the source data. If a patient has clinical activity (e.g. prescriptions filled, labs performed, etc) more than 60+ days after death the ETL may want to drop the death record as it may have been falsely reported. If multiple records of death exist on multiple days the ETL may select the death that is deemed most reliable (e.g. death at discharge) or is latest.
* If the Death Datetime cannot be precisely determined from the data, the best approximation should be used.
* Valid Concepts for the CAUSE_CONCEPT_ID have domain_id='Condition'.
No.|Convention Description
:--------|:------------------------------------
| 1 | Living patients should not have a value in PERSON.DEATH_DATETIME, nor should they have any records relating to death either in the CONDITION_OCCURRENCE or OBSERVATION tables
| 2 | Only one death date per individual can be used. If a patient has clinical activity (e.g. prescriptions filled, labs performed, etc) more than 60+ days after death you may want to drop the death record as it may have been falsely reported. If multiple records of death exist on multiple days you may select the death that you deem most reliable (e.g. death at discharge) or select the latest death date.
| 3 | If multiple death records occur, the date and the person have to be the same, but the cause can be different. Can be reported by different sources as well.
| 4 | If PERSON.DEATH_DATETIME cannot be precisely determined from the data, the best approximation should be used.
| 5 | Any cause of death should be stored in the CONDITION_OCCURRENCE table, using the CONDITION_TYPE vocabulary with the DEATH_TYPE concept class.
| 6 | All observations relating to death should be stored in the OBSERVATION table, including the concept [4306655](http://athena.ohdsi.org/search-terms/terms/4306655).
| 7 | The DEATH_DATETIME in the PERSON table should not be used as the way to find all deaths<br><ul><li>`select * from PERSON where death_datetime is not null` should not be the practice</li><li>Rather, deaths should be found through the OBSERVATION table and the PERSON table is only used to determine which death date should be used in analysis</li></ul>

28
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/DEVICE_EXPOSURE.md
View File

@ -9,7 +9,7 @@ Field|Required|Type|Description
| device_exposure_start_datetime| No | datetime | The date and time the Device or supply was applied or used. |
| device_exposure_end_date | No | date | The date use of the Device or supply was ceased. |
| device_exposure_end_datetime | No | datetime | The date and time use of the Device or supply was ceased. |
| device_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Device Exposure recorded. It indicates how the Device Exposure was represented in the source data.|
| device_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Device Exposure recorded. It indicates how the Device Exposure was represented in the source data and belongs to the 'Device Type' domain.|
| unique_device_id | No | varchar(50)| A UDI or equivalent identifying the instance of the Device used in the Person. |
| quantity | No | integer | The number of individual Devices used in the exposure. |
| provider_id | No | integer | A foreign key to the provider in the PROVIDER table who initiated or administered the Device. |
@ -18,18 +18,16 @@ Field|Required|Type|Description
| device_source_value | No | varchar(50)| The source code for the Device as it appears in the source data. This code is mapped to a Standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.|
| device_source_concept_id | No | integer | A foreign key to a Device Concept that refers to the code used in the source.|
### Conventions
### Conventions
* The distinction between Devices or supplies and procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.
* For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field.
* Valid Device Concepts belong to the 'Device' domain. The Concepts of this domain are derived from the DI portion of a UDI or based on other source vocabularies, like HCPCS.
* A Device Type is assigned to each Device Exposure to track from what source the information was drawn or inferred. The valid vocabulary for these Concepts is 'Device Type'.
* The Visit during which the Device was first used is recorded through a reference to the VISIT_OCCURRENCE table.
* The Visit Detail during which the Device was first used is recorded through a reference to the VISIT_DETAIL table.
* The Provider exposing the patient to the Device is recorded through a reference to the PROVIDER table.
* When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are:
* Same Device
* Same DEVICE_EXPOSURE_START_DATETIME
* Same Visit Occurrence or Visit Detail
* Same Provider
* If a Device Exposure has a quantity of '0' in the source, this should default to '1' in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once.
No.|Convention Description
:--------|:------------------------------------
| 1 | The distinction between Devices or supplies and Procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.|
| 2 | For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field.|
| 3 | Valid Device Concepts belong to the 'Device' domain. The Concepts of this domain are derived from the DI portion of a UDI or based on other source vocabularies, like HCPCS.|
| 4 | A Device Type is assigned to each Device Exposure to track from what source the information was drawn or inferred. The valid vocabulary for these Concepts is 'Device Type'.|
| 5 | The Visit during which the Device was first used is recorded through a reference to the VISIT_OCCURRENCE table. |
| 6 | The Visit Detail during which the Device was first used is recorded through a reference to the VISIT_DETAIL table.|
| 7 | The Provider exposing the patient to the Device is recorded through a reference to the PROVIDER table.
| 8 | When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are:<br><ul><li>Same Device/Procedure</li><li>Same DEVICE_EXPOSURE_START_DATETIME</li><li> Same Visit Occurrence or Visit Detail</li><li>Same Provider</li><li>Same Modifier for Procedures</li><li>Same COST_ID</li></ul> |
| 9 | If a Device Exposure has a quantity of '0' in the source, this should default to '1' in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once. |

30
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/DRUG_EXPOSURE.md
View File

@ -17,12 +17,12 @@ Field|Required|Type|Description
|drug_exposure_end_date |No |date |The end date for the current instance of Drug utilization. Depending on different sources, it could be a known or an inferred date and denotes the last day at which the patient was still exposed to Drug. |
|drug_exposure_end_datetime |No |datetime |The end date and time for the current instance of Drug utilization. Depending on different sources, it could be a known or an inferred date and time and denotes the last day at which the patient was still exposed to Drug. |
|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.|
|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 and belongs to the 'Drug Type' vocabulary.|
|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 null. |
|quantity |No |float |The quantity of drug as recorded in the original prescription or dispensing record. |
|days_supply |No |integer |The number of days of supply of the medication as prescribed. This reflects the intention of the provider for the length of exposure. |
|sig |No |varchar(MAX)|The directions ("signetur") on the Drug prescription as recorded in the original prescription (and printed on the container) or dispensing record. |
|sig |No |varchar(MAX)|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 that refers to a Standard Concept identifier in the Standardized Vocabularies reflecting the route of administration and belonging to the 'Route' domain. |
|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.|
@ -35,15 +35,17 @@ Field|Required|Type|Description
### Conventions
* Valid Concepts for the DRUG_CONCEPT_ID field belong to the 'Drug' domain. Most Concepts in the Drug domain are based on RxNorm, but some may come from other sources. Concepts are members of the Clinical Drug or Pack, Branded Drug or Pack, Drug Component or Ingredient classes.
* Source drug identifiers, including NDC codes, Generic Product Identifiers, etc. are mapped to Standard Drug Concepts in the Standardized Vocabularies (e.g., based on RxNorm). When the Drug Source Value of the code cannot be translated into standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding source_concept_id and drug_source_value and a drug_concept_id of 0.
* The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the concept_class_id field of the Concept and are recorded in the following order of precedence: "Branded Pack", "Clinical Pack", "Branded Drug", "Clinical Drug", "Branded Drug Component", "Clinical Drug Component", "Branded Drug Form", "Clinical Drug Form", and only if no other information is available "Ingredient". Note: If only the drug class is known, the drug_concept_id should contain 0.
* A Drug Type is assigned to each Drug Exposure to track from what source the information was drawn or inferred from. The valid concept_class_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. Therefore, route information should be stored in standard drug concept_id (as a drug with corresponding Dose Form). The route_concept_id could be used for storing more granular forms e.g. 'Intraventricular cardiac'.
* 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.)
* Valid Condition Occurrence Type Concepts belong to the 'Condition Type' vocabulary in the 'Type Concept' domain.
No.|Convention Description
:--------|:------------------------------------
| 1 | Valid Concepts for the DRUG_CONCEPT_ID field belong to the 'Drug' domain. Most Concepts in the Drug domain are based on RxNorm, but some may come from other sources. Concepts are members of the Clinical Drug or Pack, Branded Drug or Pack, Drug Component or Ingredient classes. |
| 2 | Source drug identifiers, including NDC codes, Generic Product Identifiers, etc. are mapped to Standard Drug Concepts in the Standardized Vocabularies (e.g., based on RxNorm). When the Drug Source Value of the code cannot be translated into Standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding SOURCE_CONCEPT_ID and DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0.
| 3 | The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the CONCEPT_CLASS_ID field of the Concept and are recorded in the following order of precedence: 'Branded Pack', 'Clinical Pack', 'Branded Drug', 'Clinical Drug', 'Branded Drug Component', 'Clinical Drug Component', 'Branded Drug Form', 'Clinical Drug Form', and only if no other information is available 'Ingredient'. Note: If only the drug class is known, the DRUG_CONCEPT_ID field should contain 0.
| 4 | A Drug Type is assigned to each Drug Exposure to track from what source the information was drawn or inferred from. The valid CONCEPT_CLASS_ID for these Concepts is 'Drug Type'. |
| 5 | 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.|
| 6 | 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. Therefore, route information should be stored in DRUG_CONCEPT_ID (as a drug with corresponding Dose Form). The ROUTE_CONCEPT_ID could be used for storing more granular forms e.g. 'Intraventricular cardiac'.|
| 7 | The LOT_NUMBER field contains an identifier assigned from the manufacturer of the Drug product. |
| 8 | 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.|
| 9 | If possible, the prescribing or administering provider (physician or nurse) is recorded in the PROVIDER_ID field through a reference to the provider table.
| 10 | 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.)|
| 11 | When the native data suggests a drug exposure has a days supply less than 0, drop the record as unknown if a person has received the drug or not.|
| 12 | If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate.|

9
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/FACT_RELATIONSHIP.md
View File

@ -1,4 +1,4 @@
The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain (table), or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).
The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).
Field|Required|Type|Description
:-------------------------|:--------|:------------|:--------------------------------------------------------------
@ -9,6 +9,7 @@ Field|Required|Type|Description
|relationship_concept_id |Yes|integer|A foreign key to a Standard Concept ID of relationship in the Standardized Vocabularies.|
### Conventions
* All relationships are directional, and each relationship is represented twice symmetrically within the FACT_RELATIONSHIP table. For example, two persons if person_id = 1 is the mother of person_id = 2 two records are in the FACT_RELATIONSHIP table (all strings in fact concept_id records in the Concept table:
* Person, 1, Person, 2, parent of
* Person, 2, Person, 1, child of
No.|Convention Description
:--------|:------------------------------------
| 1 | All relationships are directional, and each relationship is represented twice symmetrically within the FACT_RELATIONSHIP table. For example, two persons if person_id = 1 is the mother of person_id = 2 two records are in the FACT_RELATIONSHIP table (all strings in fact concept_id records in the Concept table:<br><ul><li>Person, 1, Person, 2, parent of</li><li>Person, 2, Person, 1, child of</li></ul>|

41
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/MEASUREMENT.md
View File

@ -4,15 +4,15 @@ 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_concept_id|Yes|integer|A foreign key to the standard measurement concept identifier in the Standardized Vocabularies. These belong to the 'Measurement' domain, but could overlap with the 'Observation' domain (see #3 below).|
|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_datetime|No|datetime|The date and time of the Measurement. Some database systems don't have a datatype of time. To accommodate 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_time |No|varchar(10)|The time of the Measurement. This is present for backwards compatibility and will be deprecated in an upcoming version|
|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 <, <=, =, >=, >.|
|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. These belong to the 'Meas Type' vocabulary|
|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 <, <=, =, >=, > and these concepts belong to the 'Meas Value Operator' domain.|
|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.|
|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.). These belong to the 'Meas Value' domain|
|unit_concept_id|No|integer|A foreign key to a Standard Concept ID of Measurement Units in the Standardized Vocabularies that belong to the 'Unit' domain.|
|range_low|No|float|The lower limit of the normal range of the Measurement result. The lower range is assumed to be of the same unit of measure as the Measurement value.|
|range_high|No|float|The upper limit of the normal range of the Measurement. The upper range is assumed to be of the same unit of measure as the Measurement value.|
|provider_id|No|integer|A foreign key to the provider in the PROVIDER table who was responsible for initiating or obtaining the measurement.|
@ -25,16 +25,19 @@ Field|Required|Type|Description
### Conventions
* Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. For example, LOINC 1755-8 concept_id 3027035 'Albumin [Mass/time] in 24 hour Urine' is the lab test to measure a certain chemical in a urine sample.
* Even though each Measurement always have a result, the fields value_as_number and value_as_concept_id are not mandatory. When the result is not known, the Measurement record represents just the fact that the corresponding Measurement was carried out, which in itself is already useful information for some use cases.
* Valid Measurement Concepts (measurement_concept_id) belong to the 'Measurement' domain, but could overlap with the 'Observation' domain. This is due to the fact that there is a continuum between systematic examination or testing (Measurement) and a simple determination of fact (Observation). When the Measurement Source Value of the code cannot be translated into a standard Measurement Concept ID, a Measurement entry is stored with only the corresponding source_concept_id and measurement_source_value and a measurement_concept_id of 0.
* Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in value_as_concept), or a numerical value (value_as_number) with a Unit (unit_concept_id).
* Valid Concepts for the value_as_concept field belong to the 'Meas Value' domain.
* For some Measurement Concepts, the result is included in the test. For example, ICD10 concept_id 45595451 "Presence of alcohol in blood, level not specified" indicates a Measurement and the result (present). In those situations, the CONCEPT_RELATIONSHIP table in addition to the "Maps to" record contains a second record with the relationship_id set to "Maps to value". In this example, the "Maps to" relationship directs to 4041715 "Blood ethanol measurement" as well as a "Maps to value" record to 4181412 "Present".
* The operator_concept_id is optionally given for relative Measurements where the precise value is not available but its relation to a certain benchmarking value is. For example, this can be used for minimal detection thresholds of a test.
* The meaning of Concept 4172703 for '=' is identical to omission of a operator_concept_id value. Since the use of this field is rare, it's important when devising analyses to not to forget testing for the content of this field for values different from =.
* Valid Concepts for the operator_concept_id field belong to the 'Meas Value Operator' domain.
* The Unit is optional even if a value_as_number is provided.
* If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the range_high and range_low fields. Ranges have the same unit as the value_as_number.
* The Visit during which the observation was made is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
* The Provider making the observation is recorded through a reference to the PROVIDER table. This information is not always available.
No.|Convention Description
:--------|:------------------------------------
| 1 | Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. For example, LOINC 1755-8 concept_id 3027035 'Albumin [Mass/time] in 24 hour Urine' is the lab test to measure a certain chemical in a urine sample.|
| 2 | Even though each Measurement always have a result, the fields VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are not mandatory. When the result is not known, the Measurement record represents just the fact that the corresponding Measurement was carried out, which in itself is already useful information for some use cases.|
| 3 | Valid Measurement Concepts (MEASUREMENT_CONCEPT_ID) belong to the 'Measurement' domain, but could overlap with the 'Observation' domain. This is due to the fact that there is a continuum between systematic examination or testing (Measurement) and a simple determination of fact (Observation). When the Measurement Source Value of the code cannot be translated into a standard Measurement Concept ID, a Measurement entry is stored with only the corresponding SOURCE_CONCEPT_ID and MEASUREMENT_SOURCE_VALUE and a MEASUREMENT_CONCEPT_ID of 0.|
| 4 | Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). |
| 5 | Valid Concepts for the VALUE_AS_CONCEPT field belong to the 'Meas Value' domain. |
| 6 | For some Measurement Concepts, the result is included in the test. For example, ICD10 concept_id 45595451 'Presence of alcohol in blood, level not specified' indicates a Measurement and the result (present). In those situations, the CONCEPT_RELATIONSHIP table in addition to the 'Maps to' record contains a second record with the relationship_id set to 'Maps to value'. In this example, the 'Maps to' relationship directs to 4041715 'Blood ethanol measurement' as well as a 'Maps to value' record to 4181412 'Present'.|
| 7 | The OPERATOR_CONCEPT_ID is optionally given for relative Measurements where the precise value is not available but its relation to a certain benchmarking value is. For example, this can be used for minimal detection thresholds of a test.|
| 8 | The meaning of Concept 4172703 for '=' is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it's important when devising analyses to not to forget testing for the content of this field for values different from =.|
| 9 | Valid Concepts for the OPERATOR_CONCEPT_ID field belong to the 'Meas Value Operator' domain.|
| 10 | The Unit is optional even if a VALUE_AS_NUMBER is provided.|
| 11 | If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. Ranges have the same unit as the VALUE_AS_NUMBER.|
| 12 | The Visit during which the observation was made is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.|
| 13 | The Provider making the observation is recorded through a reference to the PROVIDER table. This information is not always available.|
| 14 | If there is a negative value coming from the source, set the VALUE_AS_NUMBER to NULL, with the exception of the following Measurements (listed as LOINC codes):<br><ul><li>1925-7 Base excess in Arterial blood by calculation</li><li>1927-3 Base excess in Venous blood by calculation</li><li>8632-2 QRS-Axis</li><li>11555-0 Base excess in Blood by calculation</li><li>1926-5 Base excess in Capillary blood by calculation</li><li>28638-5 Base excess in Arterial cord blood by calculation</li><li>28639-3 Base excess in Venous cord blood by calculation</li></ul>|

142
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/NOTE.md
View File

@ -2,131 +2,45 @@ The NOTE table captures unstructured information that was recorded by a provider
Field|Required|Type|Description
:--------------------|:--------|:------------|:--------------------------------------------------------
|note_id |Yes|integer|A unique identifier for each note.|
|person_id |Yes|integer|A foreign key identifier to the Person about whom the Note was recorded. The demographic details of that Person are stored in the PERSON table.|
|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|varchar(MAX)|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.|
|visit_occurrence_id |No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table when the Note was taken.|
|visit_detail_id |No|integer|A foreign key to the Visit in the VISIT_DETAIL table when the Note was taken.|
|note_source_value |No|varchar(50)|The source value associated with the origin of the Note|
|note_id |Yes|integer|A unique identifier for each note.|
|person_id |Yes|integer|A foreign key identifier to the Person about whom the Note was recorded. The demographic details of that Person are stored in the PERSON table.|
|note_event_id |No |integer|A foreign key identifier to the event (e.g. Measurement, Procedure, Visit, Drug Exposure, etc) record during which the note was recorded.|
|note_event_field_concept_id |No|integer|A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the field to which the note_event_id is referring. |
|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. These belong to the 'Note Type' vocabulary|
|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|varchar(MAX)|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.|
|visit_occurrence_id |No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table when the Note was taken.|
|visit_detail_id |No|integer|A foreign key to the Visit in the VISIT_DETAIL table when the Note was taken.|
|note_source_value |No|varchar(50)|The source value associated with the origin of the Note|
### Conventions
* 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 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.
No.|Convention Description
:--------|:------------------------------------
| 1 | The NOTE table contains free text (in ASCII, or preferably in UTF8 format) taken by a healthcare Provider.|
| 2 | The Visit during which the note was written is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.|
| 3 | The Provider making the note is recorded through a reference to the PROVIDER table. This information is not always available.|
| 4 | The type of note_text is CLOB or varchar(MAX) depending on RDBMS|
| 5 | 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)
* **Kind of Document:** Characterizes the general 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:
Each combination of these 5 dimensions rolls up to a unique LOINC code.
* 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
```
* 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.
* The full document ontology as it exists in the Vocabulary is too extensive to list here, but it is possible to explore through the ATHENA tool starting with the ['LOINC Document Ontology - Type of Service and Kind of Document'](http://athena.ohdsi.org/search-terms/terms/36209248) by walking through the 'Is a'/'Subsumes' relationship hierarchies.

38
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/NOTE_NLP.md
View File

@ -4,9 +4,9 @@ Field | Required | Type | Description
:------------------------------- | :-------- | :------------ | :---------------------------------------------------
|note_nlp_id | Yes | 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.|
|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.|
|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|
@ -19,32 +19,8 @@ Field | Required | Type | Description
### 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.
No.|Convention Description
:--------|:------------------------------------
| 1 | 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:<br><ul><li>Negation = true</li><li>Subject = [anything other than the patient]</li><li>Conditional = true/li><li>Rule_out = true</li><li>Uncertain = very low certainty or any lower certainties</li><li>A complete lack of modifiers would make Term_exists true.</li></ul><br>For the modifiers that are there, they would have to have these values:<br><ul><li>Negation = false</li><li>Subject = patient</li><li>Conditional = false</li><li>Rule_out = false</li><li>Uncertain = true or high or moderate or even low (could argue about low)</li></ul>|
| 2 | Term_temporal is to indicate if a condition is “present” or just in the “past”. The following would be past:<br><ul><li>History = true</li><li>Concept_date = anything before the time of the report</li></ul>|
| 3 | 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. |

33
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/OBSERVATION.md
View File

@ -20,17 +20,28 @@ Field|Required|Type|Description
|observation_source_concept_id|No|integer|A foreign key to a Concept that refers to the code used in the source.|
|unit_source_value|No|varchar(50)|The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|qualifier_source_value|No|varchar(50)|The source value associated with a qualifier to characterize the observation|
|observation_event_id| No | integer| A foreign key to an event table (e.g., PROCEDURE_OCCURRENCE_ID). |
|obs_event_field_concept_id| No | integer| A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies referring to the field represented in the OBSERVATION_EVENT_ID. |
|value_as_datetime| No | integer| The observation result stored as a datetime value. This is applicable to observations where the result is expressed as a point in time.|
### Conventions
* Observations differ from Measurements in that they do not require a standardized test or some other activity to generate clinical fact. Typical observations are medical history, family history, the stated need for certain treatment, social circumstances, lifestyle choices, healthcare utilization patterns, etc. If the generation clinical facts requires a standardized testing such as lab testing or imaging and leads to a standardized result, the data item is recorded in the MEASUREMENT table. If the clinical fact observed determines a sign, symptom, diagnosis of a disease or other medical condition, it is recorded in the CONDITION_OCCURRENCE table.
* Valid Observation Concepts are not enforced to be from any domain. They still should be Standard Concepts, and they typically belong to the "Observation" or sometimes "Measurement" domain.
* Observation can be stored as attribute value pairs, with the attribute as the Observation Concept and the value representing the clinical fact. This fact can be a Concept (stored in value_as_concept), a numerical value (value_as_number) or a verbatim string (value_as_string). Even though Observations do not have an explicit result, the clinical fact can be stated separately from the type of Observation in the value_as_ fields.
* It is recommended for observations that are suggestive statements of positive assertion should have a value of "Yes" (concept_id=4188539), recorded, even though the null value is the equivalent.
* Valid Concepts of the value_as_concept field are not enforced, but typically belong to the "Meas Value" domain.
* For numerical facts a Unit can be provided in the unit_concept_id.
* For facts represented as Concepts no domain membership is enforced.
* Note that the value of value_as_concept_id may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the "Maps to" record contains a second record with the relationship_id set to "Maps to value". For example, ICD9CM V17.5 concept_id 44828510 "Family history of asthma" has a "Maps to" relationship to 4167217 "Family history of clinical finding" as well as a "Maps to value" record to 317009 "Asthma".
* The qualifier_concept_id field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc.
* The Visit during which the observation was made is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
* The Provider making the observation is recorded through a reference to the PROVIDER table. This information is not always available.
No.|Convention Description
:--------|:------------------------------------
| 1 | Observations differ from Measurements in that they do not require a standardized test or some other activity to generate clinical fact. Typical observations are medical history, family history, the stated need for certain treatment, social circumstances, lifestyle choices, healthcare utilization patterns, etc. If the generation clinical facts requires a standardized testing such as lab testing or imaging and leads to a standardized result, the data item is recorded in the MEASUREMENT table. If the clinical fact observed determines a sign, symptom, diagnosis of a disease or other medical condition, it is recorded in the CONDITION_OCCURRENCE table. |
| 2 | Valid Observation Concepts are not enforced to be from any domain. They still should be Standard Concepts, and they typically belong to the 'Observation' or sometimes 'Measurement' domain. |
| 3 | Observations can be stored as attribute value pairs, with the attribute as the Observation Concept and the value representing the clinical fact. This fact can be a Concept (stored in VALUE_AS_CONCEPT), a numerical value (VALUE_AS_NUMBER), a verbatim string (VALUE_AS_STRING), or a datetime (VALUE_AS_DATETIME). Even though Observations do not have an explicit result, the clinical fact can be stated separately from the type of Observation in the VALUE_AS_* fields.
| 4 | It is recommended for Observations that are suggestive statements of positive assertion should have a value of 'Yes' (concept_id=4188539), recorded, even though the null value is the equivalent. |
| 5 | Valid Concepts of the VALUE_AS_CONCEPT field are not enforced, but typically belong to the 'Meas Value' domain.|
| 6 | For numerical facts a Unit can be provided in the UNIT_CONCEPT_ID.|
| 7 | For facts represented as Concepts no domain membership is enforced.|
| 8 | Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the 'Maps to' record contains a second record with the relationship_id set to 'Maps to value'. For example, ICD9CM V17.5 concept_id 44828510 'Family history of asthma' has a 'Maps to' relationship to 4167217 'Family history of clinical finding' as well as a 'Maps to value' record to 317009 'Asthma'. |
| 9 | The QUALIFIER_CONCEPT_ID field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc. |
| 10 | The Visit during which the Observation was made is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.|
| 11 | The Visit Detail during which the Observation was made is recorded through a reference to the VISIT_DETAIL table. This information is not always available.|
| 12 | The Provider making the observation is recorded through a reference to the PROVIDER table. This information is not always available. |
| 13 | When storing patient responses to survey questions, each record in the OBSERVATION table represents a single question/response pair and is linked to a specific survey/questionnaire using OBSERVATION.OBSERVATION_EVENT_ID and SURVEY_CONDUCT.SURVEY_CONDUCT_ID. |
| 14 | Each survey response record is the response to a specific question identified by the OBSERVATION_CONCEPT_ID. This concept ID is a unique question contained in the CONCEPT table. |
| 15 | An individual survey question can have multiple responses to a question (e.g. which of these items relate to you, a,b,c,...?). Each response is stored as a separate record in the OBSERVATION table.|
| 16 | The question / answer OBSERVATION record is linked to the patient questionnaire used for collecting the data using two new fields in the OBSERVATION table; OBS_EVENT_FIELD_CONCEPT_ID and OBSERVATION_EVENT_ID.<br><ul><li>OBS_EVENT_FIELD_CONCEPT_ID for any survey related observations contains the concept that refers to the field SURVEY_CONDUCT_ID and OBSERVATION_EVENT_ID contains the actual SURVEY_CONDUCT_ID of the specific survey</li><li>This construct can be used for other observation groupings</li></ul> |
| 17 | The OBSERVATION table can also store survey scoring results. Many validated PRO questionnaires have scoring algorithms (many of which proprietary) that return an overall patient score based on the answers provided.<br><ul><li>Survey scores are identified by their OBSERVATION_CONCEPT_ID and are linked back to the scored survey using the same EVENT_FIELD construct described above. In the name/value pair model, the name (question) is stored as OBSERVATION_CONCEPT_ID and the value (answer) is stored as OBSERVATION_AS_CONCEPT_ID where the answer is categorical and is defined as a concept in the concept table, OBSERVATION_AS_NUMBER where the answer is numeric, OBSERVATION_AS_STRING where the answer is a free text string or OBSERVATION_AS_DATETIME.</li></ul>|

19
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/OBSERVATION_PERIOD.md
View File

@ -6,14 +6,17 @@ Field|Required|Type|Description
|person_id|Yes|integer|A foreign key identifier to the person for whom the observation period is defined. The demographic details of that person are stored in the person table.|
|observation_period_start_date|Yes|date|The start date of the observation period for which data are available from the data source.|
|observation_period_end_date|Yes|date|The end date of the observation period for which data are available from the data source.|
|period_type_concept_id|Yes|Integer|A foreign key identifier to the predefined concept in the Standardized Vocabularies reflecting the source of the observation period information|
|period_type_concept_id|Yes|Integer|A foreign key identifier to the predefined concept in the Standardized Vocabularies reflecting the source of the observation period information, belonging to the 'Obs Period Type' vocabulary|
### Conventions
* One Person may have one or more disjoint observation periods, during which times analyses may assume that clinical events would be captured if observed, and outside of which no clinical events may be recorded.
* Each Person can have more than one valid OBSERVATION_PERIOD record, but no two observation periods can overlap in time for a given person.
* As a general assumption, during an Observation Period any clinical event that happens to the patient is expected to be recorded. Conversely, the absence of data indicates that no clinical events occurred to the patient.
* Both the _start_date and the _end_date of the clinical event has to be between observation_period_start_date and observation_period_end_date.
* No clinical data are valid outside an active Observation Period. Clinical data that refer to a time outside (diagnoses of previous conditions such as "Old MI" or medical history) of an active Observation Period are recorded as Observations. The date of the Observation is the first day of the first Observation Period of a patient.
* For claims data, observation periods are inferred from the enrollment periods to a health benefit plan.
* For EHR data, the observation period cannot be determined explicitly, because patients usually do not announce their departure from a certain healthcare provider. The ETL will have to apply some heuristic to make a reasonable guess on what the observation_period should be. Refer to the ETL documentation for details.
No.|Convention Description
:--------|:------------------------------------
| 1 | Each Person has to have at least one observation period.|
| 2 | One Person may have one or more disjoint observation periods, during which times analyses may assume that clinical events would be captured if observed|
| 3 | Each Person can have more than one valid OBSERVATION_PERIOD record, but no two observation periods can overlap in time for a given person.|
| 4 | As a general assumption, during an Observation Period any clinical event that happens to the patient is expected to be recorded. Conversely, the absence of data indicates that no clinical events occurred to the patient.
| 5 | Both the _START_DATE and the _END_DATE of the clinical event has to be between observation_period_start_date and observation_period_end_date. |
| 6 | Events CAN fall outside of an observation period though they should fall in a valid payer plan period, such as Medicare Part D, which can overlap an observation period. However, time outside of an observation period cannot be used to identify people. To ensure quality, events outside of an observation period should not be used for analysis. |
| 7 | For claims data, observation periods are inferred from the enrollment periods to a health benefit plan.|
| 8 | For EHR data, the observation period cannot be determined explicitly, because patients usually do not announce their departure from a certain healthcare provider. The ETL will have to apply some heuristic to make a reasonable guess on what the observation_period should be. Refer to the ETL documentation for details. |

28
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/PERSON.md
View File

@ -8,8 +8,9 @@ Field|Required|Type|Description
|month_of_birth|No|integer|The month of birth of the person. For data sources that provide the precise date of birth, the month is extracted and stored in this field.|
|day_of_birth|No|integer|The day of the month of birth of the person. For data sources that provide the precise date of birth, the day is extracted and stored in this field.|
|birth_datetime|No|datetime|The date and time of birth of the person.|
|race_concept_id|Yes|integer|A foreign key that refers to an identifier in the CONCEPT table for the unique race of the person.|
|ethnicity_concept_id|Yes|integer|A foreign key that refers to the standard concept identifier in the Standardized Vocabularies for the ethnicity of the person.|
|death_datetime|No|datetime|The date and time of death of the person.|
|race_concept_id|Yes|integer|A foreign key that refers to an identifier in the CONCEPT table for the unique race of the person, belonging to the 'Race' vocabulary.|
|ethnicity_concept_id|Yes|integer|A foreign key that refers to the standard concept identifier in the Standardized Vocabularies for the ethnicity of the person, belonging to the 'Ethnicity' vocabulary.|
|location_id|No|integer|A foreign key to the place of residency for the person in the location table, where the detailed address information is stored.|
|provider_id|No|integer|A foreign key to the primary care provider the person is seeing in the provider table.|
|care_site_id|No|integer|A foreign key to the site of primary care in the care_site table, where the details of the care site are stored.|
@ -23,10 +24,19 @@ Field|Required|Type|Description
### Conventions
* All tables representing patient-related Domains have a foreign-key reference to the person_id field in the PERSON table.
* Each person record has associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation. For example, the location or gender is expected to have a unique value per person, even though in life these data may change over time.
* Valid Gender, Race and Ethnicity Concepts each belong to their own Domain.
* Ethnicity in the OMOP CDM follows the OMB Standards for Data on Race and Ethnicity: Only distinctions between Hispanics and Non-Hispanics are made.
* Additional information is stored through references to other tables, such as the home address (location_id) or the primary care provider.
* The Provider refers to the primary care provider (General Practitioner).
* The Care Site refers to where the Provider typically provides the primary care.
No.|Convention Description
:--------|:------------------------------------
| 1 | All tables representing patient-related Domains have a foreign-key reference to the person_id field in the PERSON table.|
| 2 | Each person record has associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation. For example, the location or gender is expected to have a unique value per person, even though in life these data may change over time.
| 3 | The GENDER_CONCEPT_ID should store what is believed to be the biological or sex assigned at birth. If the data set does have gender identification information, this should be stored in the OBSERVATION table (using the gender concepts 8532-Female or 8507-Male in OBSERVATION_CONCEPT_ID).|
| 4 | If we do not know the month or day of birth, we do not guess. A person can exist without a month or day of birth. If a person lacks a birth year that person should be dropped.|
| 5 | Living patients should not have a value in PERSON.DEATH_DATETIME, nor should they have any records relating to death either in the CONDITION_OCCURRENCE or OBSERVATION tables
| 6 | Only one death date per individual can be used. If a patient has clinical activity (e.g. prescriptions filled, labs performed, etc) more than 60+ days after death you may want to drop the death record as it may have been falsely reported. If multiple records of death exist on multiple days you may select the death that you deem most reliable (e.g. death at discharge) or select the latest death date.
| 7 | If multiple death records occur, the date and the person have to be the same, but the cause can be different. Can be reported by different sources as well.
| 8 | If PERSON.DEATH_DATETIME cannot be precisely determined from the data, the best approximation should be used.
| 9 | The DEATH_DATETIME in the PERSON table should not be used as the way to find all deaths<br><ul><li>`select * from PERSON where death_datetime is not null` should not be the practice</li><li>Rather, deaths should be found through the OBSERVATION table and the PERSON table is only used to determine which death date should be used in analysis </li></ul>
| 10 | Valid Gender, Race and Ethnicity Concepts each belong to their own Domain.
| 11 | Ethnicity in the OMOP CDM follows the OMB Standards for Data on Race and Ethnicity: Only distinctions between Hispanics and Non-Hispanics are made.
| 12 | Additional information is stored through references to other tables, such as the home address (location_id) or the primary care provider.
| 13 | The Provider refers to the primary care provider (General Practitioner).
| 14 | The Care Site refers to where the Provider typically provides the primary care.

24
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/PROCEDURE_OCCURRENCE.md
View File

@ -10,8 +10,8 @@ Field|Required|Type|Description
|procedure_concept_id|Yes|integer|A foreign key that refers to a standard procedure Concept identifier in the Standardized Vocabularies.|
|procedure_date|Yes|date|The date on which the Procedure was performed.|
|procedure_datetime|No|datetime|The date and time on which the Procedure was performed.|
|procedure_type_concept_id|Yes|integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the procedure record is derived.|
|modifier_concept_id|No|integer|A foreign key to a Standard Concept identifier for a modifier to the Procedure (e.g. bilateral)|
|procedure_type_concept_id|Yes|integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the procedure record is derived, belonging to the 'Procedure Type' vocabulary.|
|modifier_concept_id|No|integer|A foreign key to a Standard Concept identifier for a modifier to the Procedure (e.g. bilateral). These concepts are typically distinguished by 'Modifier' concept classes (e.g., 'CPT4 Modifier' as part of the 'CPT4' vocabulary).|
|quantity|No|integer|The quantity of procedures ordered or administered.|
|provider_id|No|integer|A foreign key to the provider in the PROVIDER table who was responsible for carrying out the procedure.|
|visit_occurrence_id|No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Procedure was carried out.|
@ -22,11 +22,15 @@ Field|Required|Type|Description
### Conventions
* Valid Procedure Concepts belong to the "Procedure" domain. Procedure Concepts are based on a variety of vocabularies: SNOMED-CT, ICD-9-Proc, CPT-4, HCPCS and OPCS-4, but also atypical Vocabularies such as ICD-9-CM or MedDRA.
* Procedures are expected to be carried out within one day and therefore have no end date.
* Procedures could involve the application of a drug, in which case the procedural component is recorded in the procedure table and simultaneously the administered drug in the drug exposure table when both the procedural component and drug are identifiable.
* If the quantity value is omitted, a single procedure is assumed.
* The Procedure Type defines from where the Procedure Occurrence is drawn or inferred. For administrative claims records the type indicates whether a Procedure was primary or secondary and their relative positioning within a claim.
* The Visit during which the procedure was performed is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
* The Visit Detail during with the procedure was performed is recorded through a reference to the VISIT_DETAIL table. This information is not always available.
* The Provider carrying out the procedure is recorded through a reference to the PROVIDER table. This information is not always available.
No.|Convention Description
:--------|:------------------------------------
| 1 | Valid Procedure Concepts belong to the 'Procedure' domain. Procedure Concepts are based on a variety of vocabularies: SNOMED-CT, ICD-9-Proc, CPT-4, HCPCS and OPCS-4, but also atypical Vocabularies such as ICD-9-CM or MedDRA.
| 2 | Procedures are expected to be carried out within one day and therefore have no end date.
| 3 | Procedures could involve the application of a drug, in which case the procedural component is recorded in the procedure table and simultaneously the administered drug in the drug exposure table when both the procedural component and drug are identifiable.
| 4 | If the quantity value is omitted, a single procedure is assumed.
| 5 | The Procedure Type defines from where the Procedure Occurrence is drawn or inferred. For administrative claims records the type indicates whether a Procedure was primary or secondary and their relative positioning within a claim.
| 6 | The Visit during which the procedure was performed is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
| 7 | The Visit Detail during with the procedure was performed is recorded through a reference to the VISIT_DETAIL table. This information is not always available.
| 8 | The Provider carrying out the procedure is recorded through a reference to the PROVIDER table. This information is not always available.
| 9 | When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are:<br><ul><li>Same Procedure</li><li>Same PROCEDURE_DATETIME</li><li> Same Visit Occurrence or Visit Detail</li><li>Same Provider</li><li>Same Modifier for Procedures</li><li>Same COST_ID</li></ul> |
| 10 | If a Procedure has a quantity of '0' in the source, this should default to '1' in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once. |

5
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/SPECIMEN.md
View File

@ -19,4 +19,7 @@ Field|Required|Type|Description
|disease_status_source_value|No|varchar(50)|The information about the disease status as detailed in the source.|
### Conventions
* Anatomic site is coded at the most specific level of granularity possible, such that higher level classifications can be derived using the Standardized Vocabularies.
No.|Convention Description
:--------|:------------------------------------
| 1 | Anatomic site is coded at the most specific level of granularity possible, such that higher level classifications can be derived using the Standardized Vocabularies.

43
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/VISIT_DETAIL.md
View File

@ -5,44 +5,47 @@ Field|Required|Type|Description
:------------------------|:--------|:-----|:-------------------------------------------------
|visit_detail_id |Yes|integer|A unique identifier for each Person's visit or encounter at a healthcare provider.|
|person_id |Yes|integer|A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table.|
|visit_detail_concept_id |Yes|integer|A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies.|
|visit_detail_concept_id |Yes|integer|A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies belonging to the 'Visit' Vocabulary. |
|visit_detail_start_date |Yes|date|The start date of the visit.|
|visit_detail_start_datetime |No|datetime|The date and time of the visit started.|
|visit_detail_end_date |Yes|date|The end date of the visit. If this is a one-day visit the end date should match the start date.|
|visit_detail_end_datetime |No|datetime|The date and time of the visit end.|
|visit_detail_type_concept_id |Yes|Integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived.|
|visit_detail_type_concept_id |Yes|Integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived belonging to the 'Visit Type' vocabulary. |
|provider_id |No|integer|A foreign key to the provider in the provider table who was associated with the visit.|
|care_site_id |No|integer|A foreign key to the care site in the care site table that was visited.|
|visit_detail_source_value |No|string(50)|The source code for the visit as it appears in the source data.|
|visit_detail_source_concept_id |No|Integer|A foreign key to a Concept that refers to the code used in the source.|
|admitting_source_value | No|Varchar(50)| The source code for the admitting source as it appears in the source data.|
|admitting_source_concept_id |No |Integer |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.|
|admitted_from_source_value | No|Varchar(50)| The source code for the admitting source as it appears in the source data.|
|admitted_from_concept_id |No |Integer |A foreign key to the predefined concept in the 'Place of Service' Vocabulary reflecting the admitting source for a visit.|
|discharge_to_source_value | No| Varchar(50)| The source code for the discharge disposition as it appears in the source data.|
|discharge_to_concept_id |No | Integer |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
|discharge_to_concept_id |No | Integer |A foreign key to the predefined concept in the 'Place of Service' Vocabulary reflecting the discharge disposition for a visit.|
|preceding_visit_detail_id |No |Integer| A foreign key to the VISIT_DETAIL table of the visit immediately preceding this visit|
|visit_detail_parent_id | No |Integer|A foreign key to the VISIT_DETAIL table record to represent the immediate parent visit-detail record.|
|visit_occurrence_id | Yes |Integer|A foreign key that refers to the record in the VISIT_OCCURRENCE table. This is a required field, because for every visit_detail is a child of visit_occurrence and cannot exist without a corresponding parent record in visit_occurrence.|
### Conventions
* All conventions used in VISIT_OCCURRENCE apply to VISIT_DETAIL, some notable exceptions:
* A Visit Detail is an optional detail record for each Visit Occurrence to a healthcare facility. For every record in VISIT_DETAIL there has to be a parent VISIT_OCCURRENCE record.
* One record in VISIT_DETAIL can only have one VISIT_OCCURRENCE parent.
* A single VISIT_OCCURRENCE record may have many child VISIT_DETAIL records.
* Valid Visit Concepts belong to the "Visit" domain. Standard Visit Concepts are yet to be defined, but will represent a detail of the Standard Visit Concept in VISIT_OCCURRENCE.
* Handling of death: In the case when 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").
* Source Concepts from place of service vocabularies are mapped into these Standard Visit Concepts in the Standardized Vocabularies.
* At any one day, there could be more than one visit. VISIT_OCCURRENCE allows for more than one visit within a single day. VISIT_DETAIL is to be used to only capture details within the visit.
* One visit may involve multiple providers, in which case, in VISIT_OCCURRENCE, the ETL must specify how a single provider id is selected or leave the provider_id field null. VISIT_DETAIL allows for ETL to speicify multiple child records per visit occurrence - and each of these child records may represent different provider_ids.
* One visit may involve multiple Care Sites, in which case, in VISIT_OCCURRENCE, the ETL must specify how a single care_site id is selected or leave the care_site_id field null. VISIT_DETAIL allows for ETL to speicify multiple child records per visit occurrence - and each of these child records may represent different care_sites.
* Just like in VISIT_OCCURRENCE, records in VISIT_DETAIL may be sequentially related to each. These sequential relations are represented using preceding_visit_detail_id
* Unlike VISIT_OCCURRENCE, VISIT_DETAIL may have nested visits with hierarchial relationships to each other.
* Representation of US claim data: US claims data generally has two-levels. Header/summary data that summarizes the entire claim; Line/detail that details a claim. Detail is thus a child of the summary, and for every record in summary there is one or more records in detail. i.e. there will be atleast one FK link from VISIT_DETAIL to VISIT_OCCURRENCE.
All conventions used in VISIT_OCCURRENCE apply to VISIT_DETAIL, with some notable exceptions as detailed below
No.|Convention Description
:--------|:------------------------------------
| 1 | A Visit Detail is an optional detail record for each Visit Occurrence to a healthcare facility. For every record in VISIT_DETAIL there has to be a parent VISIT_OCCURRENCE record. |
| 2 | One record in VISIT_DETAIL can only have one VISIT_OCCURRENCE parent. |
| 3 | A single VISIT_OCCURRENCE record may have many child VISIT_DETAIL records. |
| 4 | Valid Visit Concepts belong to the 'Visit' domain. Standard Visit Concepts are yet to be defined, but will represent a detail of the Standard Visit Concept in VISIT_OCCURRENCE. |
| 5 | Handling of death: In the case when a patient died during admission (VISIT_DETAIL.DISCHARGE_TO_CONCEPT_ID = 4216643 'Patient died'), a record in the Observation table should be created with OBSERVATION_TYPE_CONCEPT_ID = 44818516 (EHR discharge status 'Expired').|
| 6 | Source Concepts from place of service vocabularies are mapped into these Standard Visit Concepts in the Standardized Vocabularies. |
| 7 | On any one day, there could be more than one visit. VISIT_OCCURRENCE allows for more than one visit within a single day. VISIT_DETAIL is to be used to only capture details within the visit.
| 8 | One visit may involve multiple Providers, in which case, in VISIT_OCCURRENCE, the ETL must specify how a single PROVIDER_ID is selected or leave the PROVIDER_ID field null. VISIT_DETAIL allows for the ETL to specify multiple child records per VISIT_OCCURRENCE - and each of these child records may represent different PROVIDER_IDs.|
| 9 | One visit may involve multiple Care Sites, in which case, in VISIT_OCCURRENCE, the ETL must specify how a single CARE_SITE_ID is selected or leave the CARE_SITE_ID field null. VISIT_DETAIL allows for the ETL to specify multiple child records per visit occurrence - and each of these child records may represent different CARE_SITEs.|
| 10 | Just like in VISIT_OCCURRENCE, records in VISIT_DETAIL may be sequentially related to each. These sequential relations are represented using PRECEDING_VISIT_DETAIL_ID.|
| 11 | Unlike VISIT_OCCURRENCE, VISIT_DETAIL may have nested visits with hierarchical relationships to each other. These relationships are represented using VISIT_DETAIL_PARENT_ID. |
| 12 | In US claims data Header/summary data that summarizes the entire claim and Line/detail that details a claim, detail is thus a child of the summary, and for every record in summary there is one or more records in detail. i.e. there will be at least one foreign key link from VISIT_DETAIL to VISIT_OCCURRENCE.
Example: an entire inpatient stay maybe one record in the VISIT_OCCURRENCE table. This may have one or more detail records such as ER, ICU, medical floor, rehabilitation floor etc. Each of these visit details may have different start/end date-times, different concept_ids and fact_ids. These would become separate records in VISIT_DETAIL with a FK link to VISIT_OCCURRENCE.
For example: an entire inpatient stay maybe one record in the VISIT_OCCURRENCE table. This may have one or more detail records such as ER, ICU, medical floor, rehabilitation floor etc. Each of these visit details may have different start/end date-times, different concept_ids and fact_ids. These would become separate records in VISIT_DETAIL with a FK link to VISIT_OCCURRENCE.
Each record within VISIT_DETAIL may be related to each other, sequentially –> ER leading to ICU leading to medical floor, leading to rehabilitation, or in hierarchical parent-child visit –> a visit for dialysis while in ICU.
Note the CONCEPT_ID for visit domain is 8, and it is shared between VISIT_OCCURRENCE and VISIT_DETAIL in OMOP CDM. The key deviation from VISIT_OCCURRENCE is
Note the domain is Visit, and it is shared between VISIT_OCCURRENCE and VISIT_DETAIL in OMOP CDM. The key deviation from VISIT_OCCURRENCE is
- self-referencing key: a new foreign key visit_detail_parent_id allows self referencing for nested visits.
- VISIT_DETAIL points to its parent record in the VISIT_OCCURRENCE table (visit_occurrence_id)

35
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/VISIT_OCCURRENCE.md
View File

@ -4,12 +4,12 @@ Field|Required|Type|Description
:------------------------|:--------|:-----|:-------------------------------------------------
|visit_occurrence_id|Yes|integer|A unique identifier for each Person's visit or encounter at a healthcare provider.|
|person_id|Yes|integer|A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table.|
|visit_concept_id|Yes|integer|A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies.|
|visit_concept_id|Yes|integer|A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies belonging to the 'Visit' Vocabulary.|
|visit_start_date|Yes|date|The start date of the visit.|
|visit_start_datetime|No|datetime|The date and time of the visit started.|
|visit_end_date|Yes|date|The end date of the visit. If this is a one-day visit the end date should match the start date.|
|visit_end_datetime|No|datetime|The date and time of the visit end.|
|visit_type_concept_id|Yes|Integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived.|
|visit_type_concept_id|Yes|Integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived belonging to the 'Visit Type' vocabulary.|
|provider_id|No|integer|A foreign key to the provider in the provider table who was associated with the visit.|
|care_site_id|No|integer|A foreign key to the care site in the care site table that was visited.|
|visit_source_value|No|varchar(50)|The source code for the visit as it appears in the source data.|
@ -22,21 +22,16 @@ Field|Required|Type|Description
### Conventions
* A Visit Occurrence is recorded for each visit to a healthcare facility.
* Valid Visit Concepts belong to the "Visit" domain.
* Standard Visit Concepts are defined as Inpatient Visit, Outpatient Visit, Emergency Room Visit, Long Term Care Visit and combined ER and Inpatient Visit. The latter is necessary because it is close to impossible to separate the two in many EHR system, treating them interchangeably. To annotate this correctly, the visit concept "Emergency Room and Inpatient Visit" (concept_id=262) should be used.
* Handling of death: In the case when 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").
* Source Concepts from place of service vocabularies are mapped into these standard visit Concepts in the Standardized Vocabularies.
* At any one day, there could be more than one visit.
* One visit may involve multiple providers, in which case the ETL must specify how a single provider id is selected or leave the provider_id field null.
* 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.
* 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.|Convention Description
:--------|:------------------------------------
| 1 | A Visit Occurrence is recorded for each visit to a healthcare facility. |
| 2 | Valid Visit Concepts belong to the 'Visit' domain. |
| 3 | Standard Visit Concepts are defined, among others, as Inpatient Visit, Outpatient Visit, Emergency Room Visit, Long Term Care Visit and combined ER and Inpatient Visit. The latter is necessary because it is close to impossible to separate the two in many EHR system, treating them interchangeably. To annotate this correctly, the visit concept 'Emergency Room and Inpatient Visit' (concept_id=262) should be used.
| 4 | Handling of death: In the case when a patient died during admission (VISIT_OCCURRENCE.DISCHARGE_TO_CONCEPT_ID = 4216643 'Patient died'), a record in the Observation table should be created with OBSERVATION_TYPE_CONCEPT_ID = 44818516 (EHR discharge status 'Expired').|
| 5 | Source Concepts from place of service vocabularies are mapped into these standard visit Concepts in the Standardized Vocabularies. |
| 6 | At any one day, there could be more than one visit. |
| 7 | One visit may involve multiple providers, in which case the ETL must specify how a single PROVIDER_ID is selected or leave the PROVIDER_ID field null. |
| 8 | 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.
| 9 | Visits are recorded in various data sources in different forms with varying levels of standardization. For example:<br><ul><li>Medical Claims include Inpatient Admissions, Outpatient Services, and Emergency Room visits.</li><li>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./li></ul> |
| 10 | In addition to the 'Place of Service' vocabulary the following SNOMED concepts for discharge disposition (DISCHARGE_TO_CONCEPT_ID) can be used:<br><ul><li>Patient died: 4216643</li><li>Absent without leave: 44814693</li><li>Patient self-discharge against medical advice: 4021968</li></ul> |
| 11 | PRECEDING_VISIT_ID can be used to link a visit immediately preceding the current visit. |

1
Impala/OMOP CDM impala ddl.txt
View File

@ -209,6 +209,7 @@ CREATE TABLE person
month_of_birth INTEGER ,
day_of_birth INTEGER ,
birth_datetime TIMESTAMP ,
death_datetime TIMESTAMP ,
race_concept_id INTEGER ,
ethnicity_concept_id INTEGER ,
location_id BIGINT ,

1
Netezza/OMOP CDM netezza ddl.txt
View File

@ -233,6 +233,7 @@ CREATE TABLE person
month_of_birth INTEGER NULL,
day_of_birth INTEGER NULL,
birth_datetime DATETIME NULL,
death_datetime DATETIME NULL,
race_concept_id INTEGER NOT NULL,
ethnicity_concept_id INTEGER NOT NULL,
location_id BIGINT NULL,

1
Oracle/OMOP CDM oracle ddl.txt
View File

@ -221,6 +221,7 @@ CREATE TABLE person
month_of_birth INTEGER NULL,
day_of_birth INTEGER NULL,
birth_datetime TIMESTAMP NULL,
death_datetime TIMESTAMP NULL,
race_concept_id INTEGER NOT NULL,
ethnicity_concept_id INTEGER NOT NULL,
location_id NUMBER(19) NULL,

1
ParallelDataWarehouse/OMOP CDM pdw ddl.txt
View File

@ -231,6 +231,7 @@ person (
month_of_birth INTEGER NULL,
day_of_birth INTEGER NULL,
birth_datetime DATETIME2 NULL,
death_datetime DATETIME2 NULL,
race_concept_id INTEGER NOT NULL,
ethnicity_concept_id INTEGER NOT NULL,
location_id INTEGER NULL,

1
PostgreSQL/OMOP CDM postgresql ddl.txt
View File

@ -232,6 +232,7 @@ CREATE TABLE person
month_of_birth INTEGER NULL,
day_of_birth INTEGER NULL,
birth_datetime TIMESTAMP NULL,
death_datetime TIMESTAMP NULL,
race_concept_id INTEGER NOT NULL,
ethnicity_concept_id INTEGER NOT NULL,
location_id INTEGER NULL,

1
Redshift/OMOP CDM redshift ddl.txt
View File

@ -218,6 +218,7 @@ CREATE TABLE person (
month_of_birth INTEGER NULL,
day_of_birth INTEGER NULL,
birth_datetime TIMESTAMP NULL,
death_datetime TIMESTAMP NULL,
race_concept_id INTEGER NOT NULL,
ethnicity_concept_id INTEGER NOT NULL,
location_id INTEGER NULL,

1
Sql Server/OMOP CDM sql server ddl.txt
View File

@ -221,6 +221,7 @@ CREATE TABLE person
month_of_birth INTEGER NULL,
day_of_birth INTEGER NULL,
birth_datetime DATETIME2 NULL,
death_datetime DATETIME2 NULL,
race_concept_id INTEGER NOT NULL,
ethnicity_concept_id INTEGER NOT NULL,
location_id BIGINT NULL,