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

Added THEMIS references to conventions in wiki files

This commit is contained in:
clairblacketer 2018-10-04 13:27:33 -04:00
parent 840690d21f
commit 351ea98b77
24 changed files with 156 additions and 102 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,5 +1,9 @@
There are a number of implicit and explicit conventions that have been adopted in the CDM. Developers of methods that run against the CDM need to understand these conventions.
### General conventions of schemas
New to CDM v6.0 is the concept of schemas. This allows for more separation between read-only and writeable tables. The clinical data, event, and vocabulary tables are in the 'CDM' schema and tables that need to be manipulated by web-based tools or end users have moved to the 'Results' schema. Currently the only two tables in the 'Results' schema are COHORT and COHORT_DEFINITON, though likely more will be added over the course of v6.0 point releases.
### General conventions of data tables
The CDM is platform-independent. Data types are defined generically using ANSI SQL data types (VARCHAR, INTEGER, FLOAT, DATE, DATETIME, CLOB). Precision is provided only for VARCHAR. It reflects the minimal required string length and can be expanded within a CDM instantiation. The CDM does not prescribe the date and datetime format. Standard queries against CDM may vary for local instantiations and date/datetime configurations.
@ -20,7 +24,7 @@ Notation|Description
### Representation of content through Concepts
In CDM data tables the meaning of the content of each record is represented using Concepts. Concepts are stored with their CONCEPT_ID as foreign keys to the CONCEPT table in the Standardized Vocabularies, which contains Concepts necessary to describe the healthcare experience of a patient. If a Standard Concept does not exist or cannot be identified, the Concept with the CONCEPT_ID 0 is used, representing a non-existing or unmappable concept.
In CDM data tables the meaning of the content of each record is represented using Concepts. Concepts are stored with their CONCEPT_ID as foreign keys to the CONCEPT table in the Standardized Vocabularies, which contains Concepts necessary to describe the healthcare experience of a patient. If a Standard Concept does not exist or cannot be identified, the Concept with the CONCEPT_ID 0 is used, representing a non-existing or un-mappable concept.
Records in the CONCEPT table contain all the detailed information about it (name, domain, class etc.). Concepts, Concept Relationships and other information relating to Concepts is contained in the tables of the Standardized Vocabularies.
@ -42,7 +46,7 @@ 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.
* 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 ([THEMIS issue #10](https://github.com/OHDSI/Themis/issues/10)).
### Content of each table
@ -52,28 +56,28 @@ For the tables of the main domains of the CDM it is imperative that concepts use
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. 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 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 ([THEMIS issue #15](https://github.com/OHDSI/Themis/issues/15)).
* 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.
- If the source code is not mappable to a vocabulary term, the SOURCE_CONCEPT_ID field is set to 0
- Map all Source Values to the corresponding Standard CONCEPT_IDs. Store the CONCEPT_IDs in the TARGET_CONCEPT_ID field of the SOURCE_TO_CONCEPT_MAP table.
- If a CONCEPT_ID is not available for the source code, the TARGET_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:
- Map all your Source Values to the corresponding CONCEPT_IDs in the Source Vocabulary. Store the result in the SOURCE_CONCEPT_ID field.
- Find all CONCEPT_IDs in the Source Vocabulary that correspond to your Source Values. 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
- If the source code is not found in a vocabulary, the SOURCE_CONCEPT_ID field is set to 0
- Use the CONCEPT_RELATIONSHIP table to identify the Standard CONCEPT_ID that corresponds to the SOURCE_CONCEPT_ID in the domain.
- 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.
- If the SOURCE_CONCEPT_ID is not mappable to any Standard CONCEPT_ID, the <entity>_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 has 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 <entity>_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 un-mappable 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). This 'no information' concept should be used when there is no mapping to a standard concept available or if there is no information available for that field. The exceptions are MEASUREMENT.VALUE_AS_CONCEPT_ID, OBSERVATION.VALUE_AS_CONCEPT_ID, MEASUREMENT.UNIT_CONCEPT_ID, OBSERVATION.UNIT_CONCEPT_ID, MEASUREMENT.OPERATOR_CONCEPT_ID, and OBSERVATION.MODIFIER_CONCEPT_ID, which can be NULL if the data do not contain the information ([THEMIS issue #11](https://github.com/OHDSI/Themis/issues/11)).

12
Documentation/CommonDataModel_Wiki_Files/Frequently-Asked-Questions.md
View File

@ -31,9 +31,13 @@ Year_of_birth, month_of_birth, day_of_birth and birth_datetime are all fields in
Standard Concepts are used to denote all clinical entities throughout the OMOP common data model, including gender, race, and ethnicity. Source values are mapped to Standard Concepts during the extract, transform, load (ETL) process of converting a database to the OMOP Common Data Model. These are then stored in the Gender_concept_id, Race_concept_id and Ethnicity_concept_id fields in the Person table. Because the standard concepts span across all clinical domains, and in keeping with Cimino’s ‘Desiderata for Controlled Medical Vocabularies in the Twenty-First Century’, the identifiers are unique, persistent nonsematic identifiers. Gender, for example, is stored as either 8532 (female) or 8507 (male) in gender_concept_id while the original value from the source is stored in gender_source_value (M, male, F, etc)..
**7. Are there conditions/procedures/drugs or other domains that should be masked or hidden in the CDM?
The masking of information related to a person is dependent on the organization's privacy policies and may vary by data asset ([THEMIS issue #21](https://github.com/OHDSI/Themis/issues/21)).
**7. How is time-varying patient information such as location of residence addressed in the model?**
The OMOP common data model has been pragmatically defined based on the desired analytic use cases of the community, as well as the available types of data that community members have access to. Currently in the model, 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 primary care provider is expected to have a unique value per person. Typically, the most recent information is chosen though it is up to the person performing the transformation which value to store. The LOCATION_HISTORY table captures the changes in these data over time.
The OMOP common data model has been pragmatically defined based on the desired analytic use cases of the community, as well as the available types of data that community members have access to. Prior to CDM v6.0, each person record had associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation, like location and primary care provider. With the release of CDM v6.0, the Location_History table is now available to track the movements of people, care sites, and providers over time. Only the most recent location_id should be stored in the Person table to eliminate duplication, while the person's movements are stored in Location_History.
Something like marital status is a little different as it is considered to be an observation rather than a demographic attribute. This means that it is housed in the Observation table rather than the Person table, giving the opportunity to store each change in status as a unique record.
@ -79,10 +83,12 @@ Yes, that is the beauty of the community! If you find a mapping in the vocabular
**15. What if I have source codes that are specific to my site? How would these be mapped?**
We have a tool called [Usagi](https://github.com/OHDSI/Usagi) (pictured below) that is designed to create mappings between coding systems and the Vocabulary Standard Concepts by using concept names and synonyms to find potential matches.
In the OMOP Vocabulary there is an empty table called the Source_to_concept_map. It is a simple table structure that allows you to establish mapping(s) for each source code with a standard concept in the OMOP Vocabulary (TARGET_CONCEPT_ID). This work can be facilitated by the OHDSI tool [Usagi](https://github.com/OHDSI/Usagi) (pictured below) which searches for text similarity between your source code descriptions and the OMOP Vocabulary and exports mappings in a SOURCE_TO_CONCEPT_MAP table structure. Example Source_to_concept_map files can be found [here](https://github.com/OHDSI/ETL-CDMBuilder/tree/master/man/VOCABULARY_ADDITIONS). These generated Source_to_concept_map files are then loaded into the OMOP Vocabulary's empty Source_to_concept_map prior to processing the native data into the CDM so that the CDM builder can use them in a build.
![](https://github.com/OHDSI/CommonDataModel/blob/master/Documentation/CommonDataModel_Wiki_Files/Usagi.png)
If an source code is not supported by the OMOP Vocabulary, one can create a new records in the CONCEPT table, however the CONCEPT_IDs should start >2000000000 so that it is easy to tell between the OMOP Vocabulary concepts and the site specific concepts. Once those concepts exist CONCEPT_RELATIONSHIPS can be generated to assign them to a standard terminologies, USAGI can facilitate this process as well ([THEMIS issue #22](https://github.com/OHDSI/Themis/issues/22)).
**16. How are one-to-many mappings applied?**
If one source code maps to two Standard Concepts then two rows are stored in the corresponding clinical event table.

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

@ -13,13 +13,13 @@ Field|Required|Type|Description
| 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. 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. |
| condition_status_concept_id | Yes | 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. |
| visit_occurrence_id | No | integer | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Condition was determined (diagnosed). |
| visit_detail_id | No | integer | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed). |
| condition_source_value | No | varchar(50) | The source code for the Condition as it appears in the source data. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. |
| condition_source_concept_id | No | integer | A foreign key to a Condition Concept that refers to the code used in the source. |
| condition_source_concept_id | Yes | integer | A foreign key to a Condition Concept that refers to the code used in the source. |
| condition_status_source_value | No | varchar(50) | The source code for the condition status as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference. |

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

@ -11,8 +11,8 @@ The 'Death' domain contains the clinical events surrounding how and when a Perso
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.
| 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 ([THEMIS issue #6](https://github.com/OHDSI/Themis/issues/6)).
| 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 ([THEMIS issue #5](https://github.com/OHDSI/Themis/issues/5)).
| 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).

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

@ -5,8 +5,8 @@ Field|Required|Type|Description
| device_exposure_id | Yes | bigint | A system-generated unique identifier for each Device Exposure. |
| person_id | Yes | bigint | A foreign key identifier to the Person who is subjected to the Device. The demographic details of that Person are stored in the PERSON table. |
| device_concept_id | Yes | integer | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies belonging to the 'Device' domain. |
| device_exposure_start_date | Yes | date | The date the Device or supply was applied or used. |
| device_exposure_start_datetime| No | datetime | The date and time the Device or supply was applied or used. |
| device_exposure_start_date | No | date | The date the Device or supply was applied or used. |
| device_exposure_start_datetime| Yes | 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 and belongs to the 'Device Type' domain.|
@ -16,7 +16,7 @@ Field|Required|Type|Description
| visit_occurrence_id | No | integer | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Device was used. |
| visit_detail_id | No | integer | A foreign key to the visit detail record in the VISIT_DETAIL table during which the Device was used. |
| 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.|
| device_source_concept_id | Yes | integer | A foreign key to a Device Concept that refers to the code used in the source.|
### Conventions
@ -29,5 +29,5 @@ No.|Convention Description
| 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. |
| 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>[THEMIS issue #27](https://github.com/OHDSI/Themis/issues/27) |
| 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 ([THEMIS issue #26](https://github.com/OHDSI/Themis/issues/26)). |

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

@ -23,13 +23,13 @@ Field|Required|Type|Description
|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. |
|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. |
|route_concept_id |Yes |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.|
|visit_occurrence_id |No |integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Drug Exposure was initiated.|
|visit_detail_id |No |integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Drug Exposure was initiated.|
|drug_source_value |No |varchar(50)|The source code for the Drug as it appears in the source data. This code is mapped to a Standard Drug concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|drug_source_concept_id |No |integer|A foreign key to a Drug Concept that refers to the code used in the source.|
|drug_source_concept_id |Yes |integer|A foreign key to a Drug Concept that refers to the code used in the source.|
|route_source_value |No |varchar(50)|The information about the route of administration as detailed in the source.|
|dose_unit_source_value |No |varchar(50)|The information about the dose unit as detailed in the source.|
@ -46,6 +46,6 @@ No.|Convention Description
| 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.|
| 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_DATETIME = DRUG_EXPOSURE_START_DATETIME + DAYS_SUPPLY -1 day), 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 ([THEMIS issue #24](https://github.com/OHDSI/Themis/issues/24)).|
| 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 ([THEMIS issue #14](https://github.com/OHDSI/Themis/issues/14)).|

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

@ -5,8 +5,8 @@ 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. 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 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_date|No|date|The date of the Measurement.|
|measurement_datetime|Yes|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. 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.|
@ -19,7 +19,7 @@ Field|Required|Type|Description
|visit_occurrence_id|No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Measurement was recorded.|
|visit_detail_id|No|integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Measurement was recorded. |
|measurement_source_value|No|varchar(50)|The Measurement name as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.|
|measurement_source_concept_id|No|integer|A foreign key to a Concept in the Standard Vocabularies that refers to the code used in the source.|
|measurement_source_concept_id|Yes|integer|A foreign key to a Concept in the Standard Vocabularies 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.|
|value_source_value|No|varchar(50)|The source value associated with the content of the value_as_number or value_as_concept_id as stored in the source data.|
@ -40,4 +40,4 @@ No.|Convention Description
| 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>|
| 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> [THEMIS issue #16](https://github.com/OHDSI/Themis/issues/16) |

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

@ -6,8 +6,8 @@ Field|Required|Type|Description
|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_date |No|date|The date the note was recorded.|
|note_datetime |Yes|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.|

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

@ -4,12 +4,12 @@ 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 | Yes | integer | A foreign key to the predefined Concept in the Standardized Vocabularies representing the section of the extracted term.|
|snippet | No | varchar(250) | A small window of text surrounding the term.|
|offset | No | varchar(50) | Character offset of the extracted term in the input note.|
|lexical_variant | Yes | varchar(250) | Raw text extracted from the NLP tool.|
|note_nlp_concept_id | No | integer | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the normalized concept for the extracted term. Domain of the term is represented as part of the Concept table.|
|note_nlp_source_concept_id | No | integer | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system|
|note_nlp_concept_id | Yes | 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 | Yes | integer | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system|
|nlp_system | No | varchar(250) | Name and version of the NLP system that extracted the term.Useful for data provenance.|
|nlp_date | Yes | date | The date of the note processing.Useful for data provenance.|
|nlp_datetime | No | datetime | The date and time of the note processing. Useful for data provenance.|

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

@ -5,8 +5,8 @@ Field|Required|Type|Description
|observation_id |Yes|integer|A unique identifier for each observation.|
|person_id |Yes|integer|A foreign key identifier to the Person about whom the observation was recorded. The demographic details of that Person are stored in the PERSON table.|
|observation_concept_id |Yes|integer|A foreign key to the standard observation concept identifier in the Standardized Vocabularies.|
|observation_date|Yes|date|The date of the observation.|
|observation_datetime|No|datetime|The date and time of the observation.|
|observation_date|No|date|The date of the observation.|
|observation_datetime|Yes|datetime|The date and time of the observation.|
|observation_type_concept_id|Yes|integer|A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the type of the observation.|
|value_as_number|No|float|The observation result stored as a number. This is applicable to observations where the result is expressed as a numeric value.|
|value_as_string|No|varchar(60)|The observation result stored as a string. This is applicable to observations where the result is expressed as verbatim text.|
@ -17,11 +17,11 @@ Field|Required|Type|Description
|visit_occurrence_id|No|integer|A foreign key to the visit in the VISIT_OCCURRENCE table during which the observation was recorded.|
|visit_detail_id|No|integer|A foreign key to the visit in the VISIT_DETAIL table during which the observation was recorded.|
|observation_source_value|No|varchar(50)|The observation code as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|observation_source_concept_id|No|integer|A foreign key to a Concept that refers to the code used in the source.|
|observation_source_concept_id|Yes|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. |
|obs_event_field_concept_id| Yes | 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

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

@ -17,6 +17,6 @@ No.|Convention Description
| 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. |
| 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. [THEMIS issue #23](https://github.com/OHDSI/Themis/issues/23) |
| 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. |

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

@ -16,11 +16,11 @@ Field|Required|Type|Description
|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.|
|person_source_value|No|varchar(50)|An (encrypted) key derived from the person identifier in the source data. This is necessary when a use case requires a link back to the person data at the source dataset.|
|gender_source_value|No|varchar(50)|The source code for the gender of the person as it appears in the source data. The person’s gender is mapped to a standard gender concept in the Standardized Vocabularies; the original value is stored here for reference.|
|gender_source_concept_id|No|Integer|A foreign key to the gender concept that refers to the code used in the source.|
|gender_source_concept_id|Yes|Integer|A foreign key to the gender concept that refers to the code used in the source.|
|race_source_value|No|varchar(50)|The source code for the race of the person as it appears in the source data. The person race is mapped to a standard race concept in the Standardized Vocabularies and the original value is stored here for reference.|
|race_source_concept_id|No|Integer|A foreign key to the race concept that refers to the code used in the source.|
|race_source_concept_id|Yes|Integer|A foreign key to the race concept that refers to the code used in the source.|
|ethnicity_source_value|No|varchar(50)|The source code for the ethnicity of the person as it appears in the source data. The person ethnicity is mapped to a standard ethnicity concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|ethnicity_source_concept_id|No|Integer|A foreign key to the ethnicity concept that refers to the code used in the source.|
|ethnicity_source_concept_id|Yes|Integer|A foreign key to the ethnicity concept that refers to the code used in the source.|
### Conventions
@ -28,8 +28,8 @@ 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.|
| 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)[THEMIS issue #32](https://github.com/OHDSI/Themis/issues/32).|
| 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([THEMIS issue #30](https://github.com/OHDSI/Themis/issues/30)).|
| 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.
@ -38,5 +38,6 @@ No.|Convention Description
| 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). When the primary provider is unknown for a person then leave the PROVIDER_ID blank.
| 13 | The Provider refers to the primary care provider (General Practitioner). When the primary provider is unknown for a person then leave the PROVIDER_ID blank ([THEMIS issue #36](https://github.com/OHDSI/Themis/issues/36)).
| 14 | The Care Site refers to where the Provider typically provides the primary care. When care site for the primary provider is unknown then leave the CARE_SITE_ID blank.
| 15 | It is not required that all subjects from the raw data be carried over to the CDM, in fact removing people that are not of high enough quality may help researchers using the CDM. Example scenarios to remove subjects include: a person’s year of birth or age are unreasonable (e.g. born in year 0, 1800, 2999 or just lacking a year of birth), person lacks health benefits in claims database (i.e. thus you do not have a complete picture of their record), or raw data states that the person may not be of high research quality (e.g. CPRD will actually suggest which people not to use within research). Removal of a patient is not required and should be made in consideration of the raw data source. Reasons for removal of persons should be documented in the ETL documentation and METADATA table (insert row in METADATA where metadata.name='count of removed persons' and metada.value_as_string='xyz' where xyz is a number (e.g., 12). <br> An ETL should not delete persons who contribute time however have no health care utilization (e.g. an individual enrolled in insurance but does not visit a doctor or pharmacy). This individual will contribute to analysis however as a healthy / non-care seeking individual ([THEMIS issue #9](https://github.com/OHDSI/Themis/issues/9)).|

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

@ -8,16 +8,16 @@ Field|Required|Type|Description
|procedure_occurrence_id|Yes|integer|A system-generated unique identifier for each Procedure Occurrence.|
|person_id|Yes|integer|A foreign key identifier to the Person who is subjected to the Procedure. The demographic details of that Person are stored in the PERSON table.|
|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_date|No|date|The date on which the Procedure was performed.|
|procedure_datetime|Yes|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, 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).|
|modifier_concept_id|Yes|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.|
|visit_detail_id|No|integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Procedure was carried out.|
|procedure_source_value|No|varchar(50)|The source code for the Procedure as it appears in the source data. This code is mapped to a standard procedure Concept in the Standardized Vocabularies and the original code is, stored here for reference. Procedure source codes are typically ICD-9-Proc, CPT-4, HCPCS or OPCS-4 codes.|
|procedure_source_concept_id|No|integer|A foreign key to a Procedure Concept that refers to the code used in the source.|
|procedure_source_concept_id|Yes|integer|A foreign key to a Procedure Concept that refers to the code used in the source.|
|modifier_source_value|No|varchar(50)|The source code for the qualifier as it appears in the source data.|
### Conventions
@ -32,5 +32,5 @@ No.|Convention Description
| 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. |
| 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> [THEMIS issue #27](https://github.com/OHDSI/Themis/issues/27) |
| 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 ([THEMIS issue #26](https://github.com/OHDSI/Themis/issues/26)).|

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

@ -6,12 +6,12 @@ Field|Required|Type|Description
|person_id|Yes|integer|A foreign key identifier to the Person for whom the Specimen is recorded.|
|specimen_concept_id|Yes|integer|A foreign key referring to a Standard Concept identifier in the Standardized Vocabularies for the Specimen.|
|specimen_type_concept_id|Yes|integer|A foreign key referring to the Concept identifier in the Standardized Vocabularies reflecting the system of record from which the Specimen was represented in the source data.|
|specimen_date|Yes|date|The date the specimen was obtained from the Person.|
|specimen_datetime|No|datetime|The date and time on the date when the Specimen was obtained from the person.|
|specimen_date|No|date|The date the specimen was obtained from the Person.|
|specimen_datetime|Yes|datetime|The date and time on the date when the Specimen was obtained from the person.|
|quantity|No|float|The amount of specimen collection from the person during the sampling procedure.|
|unit_concept_id|No|integer|A foreign key to a Standard Concept identifier for the Unit associated with the numeric quantity of the Specimen collection.|
|anatomic_site_concept_id|No|integer|A foreign key to a Standard Concept identifier for the anatomic location of specimen collection.|
|disease_status_concept_id|No|integer|A foreign key to a Standard Concept identifier for the Disease Status of specimen collection.|
|anatomic_site_concept_id|Yes|integer|A foreign key to a Standard Concept identifier for the anatomic location of specimen collection.|
|disease_status_concept_id|Yes|integer|A foreign key to a Standard Concept identifier for the Disease Status of specimen collection.|
|specimen_source_id|No|varchar(50)|The Specimen identifier as it appears in the source data.|
|specimen_source_value|No|varchar(50)|The Specimen value as it appears in the source data. This value is mapped to a Standard Concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|unit_source_value|No|varchar(50)|The information about the Unit as detailed in the source.|

41
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/SURVEY_CONDUCT.md Normal file
View File

@ -0,0 +1,41 @@
# SURVEY
The SURVEY table is used to store an instance of a completed survey or questionnaire. It captures details of the individual questionnaire such as who completed it, when it was completed and to which patient treatment or visit it relates to (if any). Each SURVEY has a SURVEY_CONCEPT_ID, a concept in the CONCEPT table identifying the questionnaire e.g. EQ5D, VR12, SF12. Each questionnaire should exist in the CONCEPT table. Each SURVEY can be optionally related to a specific patient visit in order to link it both to the visit during which it was completed and any subsequent visit where treatment was assigned based on the patient's responses.
Field | Required | Type | Description
:----------------|:-----------------|:------------|:-----------------------------------|
SURVEY_CONDUCT_ID | Yes | integer | Unique identifier for each completed survey.
PERSON_ID | Yes | integer | A foreign key identifier to the Person in the PERSON table about whom the survey was completed.
SURVEY_CONCEPT_ID | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the name and identity of the survey.
SURVEY_START_DATE | No | date | Date on which the survey was started.
SURVEY_START_DATETIME | No | datetime | Date and time the survey was started.
SURVEY_END_DATE | Yes | date | Date on which the survey was completed.
SURVEY_END_DATETIME | No | datetime | Date and time the survey was completed.
PROVIDER_ID | No  | integer  | A foreign key to the provider in the provider table who was associated with the survey completion.
ASSISTED_CONCEPT_ID | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies indicating whether the survey was completed with assistance.
RESPONDENT_TYPE_CONCEPT_ID | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the respondent type. Example: Research Associate, Patient.
TIMING_CONCEPT_ID | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies that refers to a certain timing. Example: 3 month follow-up, 6 month follow-up.
COLLECTION_METHOD_CONCEPT_ID | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the data collection method (e.g. Paper, Telephone, Electronic Questionnaire).
ASSISTED_SOURCE_VALUE | No | varchar(50) | Source value representing whether patient required assistance to complete the survey. Example: “Completed without assistance”, ”Completed with assistance”.
RESPONDENT_TYPE_SOURCE_VALUE | No| varchar(100) | Source code representing role of person who completed the survey.
TIMING_SOURCE_VALUE | No | varchar(100) | Text string representing the timing of the survey. Example: Baseline, 6-month follow-up.
COLLECTION_METHOD_SOURCE_VALUE | No | varchar(100) | The collection method as it appears in the source data.
SURVEY_SOURCE_VALUE | No | varchar(100) | The survey name/title as it appears in the source data.
SURVEY_SOURCE_CONCEPT_ID |Yes| integer | A foreign key to a predefined Concept that refers to the code for the survey name/title used in the source.
SURVEY_SOURCE_IDENTIFIER | No | varchar(100) | Unique identifier for each completed survey in source system.
VALIDATED_SURVEY_CONCEPT_ID | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the validation status of the survey.
VALIDATED_SURVEY_SOURCE_VALUE | No | integer | Source value representing the validation status of the survey.
SURVEY_VERSION_NUMBER | No | varchar(20) | Version number of the questionnaire or survey used.
VISIT_OCCURRENCE_ID | No | integer | A foreign key to the VISIT_OCCURRENCE table during which the survey was completed
RESPONSE_VISIT_OCCURRENCE_ID | No | integer  | A foreign key to the visit in the VISIT_OCCURRENCE table during which treatment was carried out that relates to this survey.
### Conventions
No.|Convention Description
:--------|:------------------------------------
| 1 | Patient responses to survey questions are stored in the OBSERVATION table. Each record in the OBSERVATION table represents a single question/response pair and is linked to a specific SURVEY/questionnaire using OBSERVATION.DOMAIN_OCCURRENCE_ID and SURVEY.SURVEY_OCCURRENCE_ID.
| 2 | Each 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.
| 3 | 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.
| 4 | The question / answer observation record is linked to the patient questionnaire used for collecting the data using two new fields in the OBSERVATION table; DOMAIN_ID and DOMAIN_OCCURRENCE_ID.<br><ul><li>DOMAIN_ID for any survey related observations contains the text ‘Survey’ and DOMAIN_OCCURRENCE_ID contains the SURVEY_OCCURRENCE_ID of the specific survey.</li><li>This domain construct can be used for other observation groupings.</li></ul>|
| 5 | 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 DOMAIN construct described.
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>|

13
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md
View File

@ -1,17 +1,18 @@
[PERSON](https://github.com/OHDSI/CommonDataModel/wiki/PERSON)
[OBSERVATION_PERIOD](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION_PERIOD)
[SPECIMEN](https://github.com/OHDSI/CommonDataModel/wiki/SPECIMEN)
[DEATH](https://github.com/OHDSI/CommonDataModel/wiki/DEATH)
[VISIT_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE)
[VISIT_DETAIL](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_DETAIL)
[VISIT_DETAIL](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_DETAIL)
[CONDITION_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE)
[DRUG_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE)
[PROCEDURE_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE)
[DRUG_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE)
[DEVICE_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DEVICE_EXPOSURE)
[CONDITION_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE)
[MEASUREMENT](https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT)
[NOTE](https://github.com/OHDSI/CommonDataModel/wiki/NOTE)
[NOTE_NLP](https://github.com/OHDSI/CommonDataModel/wiki/NOTE_NLP)
[OBSERVATION](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION)
[NOTE_NLP](https://github.com/OHDSI/CommonDataModel/wiki/NOTE_NLP)
[SURVEY_CONDUCT](https://github.com/OHDSI/CommonDataModel/wiki/SURVEY_CONDUCT)
[OBSERVATION](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION)
[SPECIMEN](https://github.com/OHDSI/CommonDataModel/wiki/SPECIMEN)
[FACT_RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP)
These tables contain the core information about the clinical events that occurred longitudinally during valid Observation Periods for each Person, as well as demographic information for the Person.

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

@ -6,19 +6,19 @@ 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 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_start_date |No|date|The start date of the visit.|
|visit_detail_start_datetime |Yes|datetime|The date and time of the visit started.|
|visit_detail_end_date |No|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 |Yes|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 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.|
|visit_detail_source_concept_id |Yes|Integer|A foreign key to a Concept that refers to the code used in the source.|
|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.|
|admitted_from_concept_id |Yes |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 |Yes | 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.|

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

@ -5,18 +5,18 @@ 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 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_start_date|No|date|The start date of the visit.|
|visit_start_datetime|Yes|datetime|The date and time of the visit started.|
|visit_end_date|No|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|Yes|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 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.|
|visit_source_concept_id|No|integer|A foreign key to a Concept that refers to the code used in the source.|
|admitting_source_concept_id |No |integer |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.|
|visit_source_concept_id|Yes|integer|A foreign key to a Concept that refers to the code used in the source.|
|admitting_source_concept_id |Yes |integer |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.|
|admitting_source_value | No|varchar(50)| The source code for the admitting source 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 |Yes | integer |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
|discharge_to_source_value | No| varchar(50)| The source code for the discharge disposition as it appears in the source data.|
|preceding_visit_occurrence_id | No |integer|A foreign key to the VISIT_OCCURRENCE table of the visit immediately preceding this visit|

8
Documentation/CommonDataModel_Wiki_Files/StandardizedHealthEconomicsDataTables/COST.md
View File

@ -10,15 +10,15 @@ Field|Required|Type|Description
|cost_event_field_concept_id |Yes| integer| A foreign key identifier to a concept in the CONCEPT table representing the identity of the field represented by COST_EVENT_ID |
|cost_concept_id | Yes| integer| A foreign key that refers to a Standard Cost Concept identifier in the Standardized Vocabularies belonging to the 'Cost' vocabulary. |
| cost_type_concept_id | Yes | integer | A foreign key identifier to a concept in the CONCEPT table for the provenance or the source of the COST data and belonging to the 'Cost Type' vocabulary |
| cost_source_concept_id | No | integer | A foreign key to a Cost Concept that refers to the code used in the source. |
| cost_source_concept_id | Yes | integer | A foreign key to a Cost Concept that refers to the code used in the source. |
| cost_source_value | No | varchar(50) | The source value for the cost as it appears in the source data|
| currency_concept_id | Yes | integer | A foreign key identifier to the concept representing the 3-letter code used to delineate international currencies, such as USD for US Dollar. These belong to the 'Currency' vocabulary |
| cost | Yes | float | The actual financial cost amount |
| incurred_date | Yes | date | The first date of service of the clinical event corresponding to the cost as in table capturing the information (e.g. date of visit, date of procedure, date of condition, date of drug etc). |
| billed_date | No | date | The date a bill was generated for a service or encounter |
| paid_date | No | date | The date payment was received for a service or encounter |
| revenue_code_concept_id | No | integer | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes belonging to the 'Revenue Code' vocabulary. |
| drg_concept_id | No | integer | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for DRG codes belonging to the 'DRG' vocabulary. |
| revenue_code_concept_id | Yes | integer | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes belonging to the 'Revenue Code' vocabulary. |
| drg_concept_id | Yes | integer | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for DRG codes belonging to the 'DRG' vocabulary. |
| revenue_code_source_value | No | varchar(50) | The source value for the Revenue code as it appears in the source data, stored here for reference. |
| drg_source_value | No | varchar(50) | The source value for the 3-digit DRG source code as it appears in the source data, stored here for reference.
| payer_plan_period_id | No | integer | A foreign key to the PAYER_PLAN_PERIOD table, where the details of the Payer, Plan and Family are stored. Record the payer_plan_id that relates to the payer who contributed to the paid_by_payer field. |
@ -36,7 +36,7 @@ No.|Convention Description
| 7 | Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax). |
| 8 | In claims data, generally there is one field representing the total payment from the payer for the service/device/drug. However, this field could be a calculated field if the source data provides separate payment information for the ingredient cost and the dispensing fee in case of prescription benefits. If there is more than one Payer in the source data, several cost records indicate that fact. The Payer reporting this reimbursement should be indicated under the PAYER_PLAN_ID field. |
| 10 | REVENUE_CODE_CONCEPT_ID: Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system.
| 11 | DRG_CONCEPT_ID: Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. Only the MS-DRG system should be used (mapped to vocabulary_id 'DRG) and all other DRG values should be mapped to 0. |
| 11 | DRG_CONCEPT_ID: Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. Only the MS-DRG system should be used (mapped to vocabulary_id 'DRG) and all other DRG values should be mapped to 0 ([THEMIS issue #19](https://github.com/OHDSI/Themis/issues/19)). |
The COST table will store information reporting money or currency amounts. There are three types of cost data, defined in the COST_TYPE_CONCEPT_ID:

20
Documentation/CommonDataModel_Wiki_Files/StandardizedHealthEconomicsDataTables/PAYER_PLAN_PERIOD.md
View File

@ -7,22 +7,22 @@ Field|Required|Type|Description
|contract_person_id |No|integer|A foreign key identifier to the person_id in person table, for the person who is the primary subscriber/contract owner for the record in the payer_plan_period table. Maybe the same person or different person, depending on who is the primary subscriber/contract owner.|
|payer_plan_period_start_date |Yes|date|The start date of the payer plan period.|
|payer_plan_period_end_date |Yes|date|The end date of the payer plan period.|
|payer_concept_id |No|integer|A foreign key that refers to a standard Payer concept identifier in the Standarized Vocabularies|
|payer_concept_id |Yes|integer|A foreign key that refers to a standard Payer concept identifier in the Standarized Vocabularies|
|payer_source_value |No|varchar(50)|The source code for the payer as it appears in the source data.|
|payer_source_concept_id |No|integer|A foreign key to a payer concept that refers to the code used in the source.|
|plan_concept_id |No|integer|A foreign key that refers to a standard plan concept identifier that represents the health benefit plan in the Standardized Vocabularies.|
|payer_source_concept_id |Yes|integer|A foreign key to a payer concept that refers to the code used in the source.|
|plan_concept_id |Yes|integer|A foreign key that refers to a standard plan concept identifier that represents the health benefit plan in the Standardized Vocabularies.|
|plan_source_value |No|varchar(50)|The source code for the Person's health benefit plan as it appears in the source data.|
|plan_source_concept_id |No|integer|A foreign key to a plan concept that refers to the plan code used in the source data.|
|contract_concept_id |No|integer|A foreign key to a standard concept representing the reason justifying the contract between person_id and contract_person_id.|
|plan_source_concept_id |Yes|integer|A foreign key to a plan concept that refers to the plan code used in the source data.|
|contract_concept_id |Yes|integer|A foreign key to a standard concept representing the reason justifying the contract between person_id and contract_person_id.|
|contract_source_value |No|integer|The source code representing the reason justifying the contract. Usually it is family relationship like a spouse, domestic partner, child etc.|
|contract_source_concept_id |No|integer|A foreign key to a concept that refers to the code used in the source as the reason justifying the contract.|
|sponsor_concept_id |No|integer|A foreign key that refers to a concept identifier that represents the sponsor in the Standardized Vocabularies.|
|contract_source_concept_id |Yes|integer|A foreign key to a concept that refers to the code used in the source as the reason justifying the contract.|
|sponsor_concept_id |Yes|integer|A foreign key that refers to a concept identifier that represents the sponsor in the Standardized Vocabularies.|
|sponsor_source_value |No|varchar(50)|The source code for the Person's sponsor of the health plan as it appears in the source data.|
|sponsor_source_concept_id |No|integer|A foreign key to a sponsor concept that refers to the sponsor code used in the source data.|
|sponsor_source_concept_id |Yes|integer|A foreign key to a sponsor concept that refers to the sponsor code used in the source data.|
|family_source_value |No|varchar(50)|The source code for the Person's family as it appears in the source data.|
|stop_reason_concept_id |No|integer|A foreign key that refers to a standard termination reason that represents the reason for the termination in the Standardized Vocabularies.|
|stop_reason_concept_id |Yes|integer|A foreign key that refers to a standard termination reason that represents the reason for the termination in the Standardized Vocabularies.|
|stop_reason_source_value |No|varchar(50)|The reason for stop-coverage as it appears in the source data.|
|stop_reason_source_concept_id |No|integer|A foreign key to a stop-coverage concept that refers to the code used in the source.|
|stop_reason_source_concept_id |Yes|integer|A foreign key to a stop-coverage concept that refers to the code used in the source.|
### Conventions

2
Documentation/CommonDataModel_Wiki_Files/StandardizedHealthSystemDataTables/CARE_SITE.md
View File

@ -4,7 +4,7 @@ Field|Required|Type|Description
:--------------------------------|:--------|:------------|:------------------------
|care_site_id|Yes|integer|A unique identifier for each Care Site.|
|care_site_name|No|varchar(255)|The verbatim description or name of the Care Site as in data source|
|place_of_service_concept_id|No|integer|A foreign key that refers to a Place of Service Concept ID in the Standardized Vocabularies.|
|place_of_service_concept_id|Yes|integer|A foreign key that refers to a Place of Service Concept ID in the Standardized Vocabularies.|
|location_id|No|integer|A foreign key to the geographic Location in the LOCATION table, where the detailed address information is stored.|
|care_site_source_value|No|varchar(50)|The identifier for the Care Site in the source data, stored here for reference.|
|place_of_service_source_value|No|varchar(50)|The source code for the Place of Service as it appears in the source data, stored here for reference.|

2
Documentation/CommonDataModel_Wiki_Files/StandardizedHealthSystemDataTables/LOCATION_HISTORY.md
View File

@ -5,7 +5,7 @@ The LOCATION HISTORY table stores relationships between Persons or Care Sites an
Field|Required|Type|Description
:------------------------------|:--------|:------------|:----------------------------------------------
|location_id |Yes|integer|A foreign key to the location table.|
|relationship_type_concept_id |No|varchar(50)|The type of relationship between location and entity.|
|relationship_type_concept_id |Yes|varchar(50)|The type of relationship between location and entity.|
|domain_id |Yes|varchar(50)|The domain of the entity that is related to the location. Either PERSON, PROVIDER, or CARE_SITE.|
|entity_id |Yes|integer|The unique identifier for the entity. References either person_id, provider_id, or care_site_id, depending on domain_id.|
|start_date |Yes|date|The date the relationship started.|

8
Documentation/CommonDataModel_Wiki_Files/StandardizedHealthSystemDataTables/PROVIDER.md
View File

@ -6,15 +6,15 @@ Field|Required|Type|Description
|provider_name|No|varchar(255)|A description of the Provider.|
|npi|No|varchar(20)|The National Provider Identifier (NPI) of the provider.|
|dea|No|varchar(20)|The Drug Enforcement Administration (DEA) number of the provider.|
|specialty_concept_id|No|integer|A foreign key to a Standard Specialty Concept ID in the Standardized Vocabularies.|
|specialty_concept_id|Yes|integer|A foreign key to a Standard Specialty Concept ID in the Standardized Vocabularies.|
|care_site_id|No|integer|A foreign key to the main Care Site where the provider is practicing.|
|year_of_birth|No|integer|The year of birth of the Provider.|
|gender_concept_id|No|integer|The gender of the Provider.|
|gender_concept_id|Yes|integer|The gender of the Provider.|
|provider_source_value|No|varchar(50)|The identifier used for the Provider in the source data, stored here for reference.|
|specialty_source_value|No|varchar(50)|The source code for the Provider specialty as it appears in the source data, stored here for reference.|
|specialty_source_concept_id|No|integer|A foreign key to a Concept that refers to the code used in the source.|
|specialty_source_concept_id|Yes|integer|A foreign key to a Concept that refers to the code used in the source.|
|gender_source_value|No|varchar(50)|The gender code for the Provider as it appears in the source data, stored here for reference.|
|gender_source_concept_id|No|integer|A foreign key to a Concept that refers to the code used in the source.|
|gender_source_concept_id|Yes|integer|A foreign key to a Concept that refers to the code used in the source.|
### Conventions

11
Documentation/CommonDataModel_Wiki_Files/_Sidebar.md
View File

@ -29,18 +29,19 @@
**[Standardized Clinical Data Tables](https://github.com/OHDSI/CommonDataModel/wiki/Standardized-Clinical-Data-Tables)**
* [PERSON](https://github.com/OHDSI/CommonDataModel/wiki/PERSON)
* [OBSERVATION_PERIOD](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION_PERIOD)
* [SPECIMEN](https://github.com/OHDSI/CommonDataModel/wiki/SPECIMEN)
* [DEATH](https://github.com/OHDSI/CommonDataModel/wiki/DEATH)
* [VISIT_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE)
* [VISIT_DETAIL](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_DETAIL)
* [PROCEDURE_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE)
* [DRUG_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE)
* [DEVICE_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DEVICE_EXPOSURE)
* [CONDITION_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE)
* [DEATH](https://github.com/OHDSI/CommonDataModel/wiki/DEATH)
* [DRUG_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE)
* [PROCEDURE_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE)
* [DEVICE_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DEVICE_EXPOSURE)
* [MEASUREMENT](https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT)
* [NOTE](https://github.com/OHDSI/CommonDataModel/wiki/NOTE)
* [NOTE_NLP](https://github.com/OHDSI/CommonDataModel/wiki/NOTE_NLP)
* [SURVEN_CONDUCT](https://github.com/OHDSI/CommonDataModel/wiki/SURVEY_CONDUCT)
* [OBSERVATION](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION)
* [SPECIMEN](https://github.com/OHDSI/CommonDataModel/wiki/SPECIMEN)
* [FACT_RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP)
**[Standardized Health System Data Tables](https://github.com/OHDSI/CommonDataModel/wiki/Standardized-Health-System-Data-Tables)**