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

closes #595

This commit is contained in:
Clair Blacketer 2024-03-28 12:54:26 -04:00
parent d9dfaff735
commit 4e90a3529e
3 changed files with 433 additions and 420 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
docs/cdm54.html
View File

@ -821,15 +821,15 @@ birth_datetime
<td style="text-align:left;">
</td>
<td style="text-align:left;">
This field is not required but highly encouraged. For data sources that
provide the precise datetime of birth, that value should be stored in
this field. If birth_datetime is not provided in the source, use the
following logic to infer the date: If day_of_birth is null and
month_of_birth is not null then use the first of the month in that year.
If month_of_birth is null or if day_of_birth AND month_of_birth are both
null and the person has records during their year of birth then use the
date of the earliest record, otherwise use the 15th of June of that
year. If time of birth is not given use midnight (00:00:0000).
This field is not required but highly encouraged for data sources that
provide the precise datetime of birth. If birth_datetime is not provided
in the source, use the following logic to infer the date: If
day_of_birth is null and month_of_birth is not null then use the first
of the month in that year. If month_of_birth is null or if day_of_birth
AND month_of_birth are both null and the person has records during their
year of birth then use the date of the earliest record, otherwise use
the 15th of June of that year. If time of birth is not given use
midnight (00:00:0000).
</td>
<td style="text-align:left;">
datetime
@ -3893,10 +3893,18 @@ days_supply
<td style="text-align:left;">
</td>
<td style="text-align:left;">
Days supply of the drug. This should be the verbatim days_supply as
given on the prescription. If the drug is physician administered use
duration end date if given or set to 1 as default if duration is not
available.
The number of days of supply of the medication as recorded in the
original prescription or dispensing record. Days supply can differ from
actual drug duration (i.e. prescribed days supply vs actual
exposure).”,“The field should be left empty if the source data does not
contain a verbatim days_supply, and should not be calculated from other
fields.<br><br>Negative values are not allowed. Several actions are
possible: 1) record is not trustworthy and we remove the record
entirely. 2) we trust the record and leave days_supply empty or 3)
record needs to be combined with other record (e.g. reversal of
prescription). High values (&gt;365 days) should be investigated. If
considered an error in the source data (e.g. typo), the value needs to
be excluded to prevent creation of unrealistic long eras.
</td>
<td style="text-align:left;">
integer
@ -14477,14 +14485,19 @@ No
class="section level3 tabset tabset-pills">
<h3 class="tabset tabset-pills">source_to_concept_map</h3>
<p><strong>Table Description</strong></p>
<p>The source to concept map table is a legacy data structure within the
OMOP Common Data Model, recommended for use in ETL processes to maintain
local source codes which are not available as Concepts in the
Standardized Vocabularies, and to establish mappings for each source
code into a Standard Concept as target_concept_ids that can be used to
populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table
is no longer populated with content within the Standardized Vocabularies
published to the OMOP community.</p>
<p>The source to concept map table is recommended for use in ETL
processes to maintain local source codes which are not available as
Concepts in the Standardized Vocabularies, and to establish mappings for
each source code into a Standard Concept as target_concept_ids that can
be used to populate the Common Data Model tables. The
SOURCE_TO_CONCEPT_MAP table is no longer populated with content within
the Standardized Vocabularies published to the OMOP community.
<strong>There are OHDSI tools to help you populate this table; <a
href="https://github.com/OHDSI/Usagi">Usagi</a> and <a
href="https://github.com/ohdsi/Perseus">Perseus</a>. You can read more
about OMOP vocabulary mapping in <a
href="https://ohdsi.github.io/TheBookOfOhdsi/ExtractTransformLoad.html#step-2-create-the-code-mappings">The
Book of OHDSI Chapter 6.3</a>.</strong></p>
<p><strong>User Guide</strong></p>
<p>NA</p>
<p><strong>ETL Conventions</strong></p>

4
inst/csv/OMOP_CDMv5.3_Field_Level.csv
View File

@ -100,7 +100,7 @@ drug_exposure,refills,No,integer,This is only filled in when the record is comin
drug_exposure,quantity,No,float,NA,"To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is 'Has dose form'. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160.
Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see [how to calculate drug dose](https://ohdsi.github.io/CommonDataModel/drug_dose.html) for more information.
",No,No,NA,NA,NA,NA,NA
drug_exposure,days_supply,No,integer,"The number of days of supply of the medication as recorded in the original prescription or dispensing record. Days supply can differ from actual drug duration (i.e. prescribed days supply vs actual exposure).","The field should be left empty if the source data does not contain a verbatim days_supply, and should not be calculated from other fields. Negative values are not allowed. Several actions are possible: 1) record is not trustworthy and we remove the record entirely. 2) we trust the record and leave days_supply empty or 3) record needs to be combined with other record (e.g. reversal of prescription). High values (>365 days) should be investigated. If considered an error in the source data (e.g. typo), the value needs to be excluded to prevent creation of unrealistic long eras.",No,No,NA,NA,NA,NA,NA
drug_exposure,days_supply,No,integer,The number of days of supply of the medication as recorded in the original prescription or dispensing record. Days supply can differ from actual drug duration (i.e. prescribed days supply vs actual exposure).,"The field should be left empty if the source data does not contain a verbatim days_supply, and should not be calculated from other fields.<br><br>Negative values are not allowed. Several actions are possible: 1) record is not trustworthy and we remove the record entirely. 2) we trust the record and leave days_supply empty or 3) record needs to be combined with other record (e.g. reversal of prescription). High values (>365 days) should be investigated. If considered an error in the source data (e.g. typo), the value needs to be excluded to prevent creation of unrealistic long eras.",No,No,NA,NA,NA,NA,NA
drug_exposure,sig,No,varchar(MAX),This is the verbatim instruction for the drug as written by the provider.,"Put the written out instructions for the drug as it is verbatim in the source, if available.",No,No,NA,NA,NA,NA,NA
drug_exposure,route_concept_id,No,integer,NA,The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain.,No,Yes,CONCEPT,CONCEPT_ID,Route,NA,NA
drug_exposure,lot_number,No,varchar(50),NA,NA,No,No,NA,NA,NA,NA,NA
@ -316,7 +316,7 @@ cost,drg_concept_id,No,integer,NA,NA,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
cost,drg_source_value,No,varchar(3),Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups.,NA,No,No,NA,NA,NA,NA,NA
drug_era,drug_era_id,Yes,integer,NA,NA,Yes,No,NA,NA,NA,NA,NA
drug_era,person_id,Yes,integer,NA,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
drug_era,drug_concept_id,Yes,integer,The Concept Id representing the specific drug ingredient.,NA,No,Yes,CONCEPT,CONCEPT_ID,Drug,Ingredient,NA
drug_era,drug_concept_id,Yes,integer,The drug_concept_id should conform to the concept class 'ingredient' as the drug_era is an era of time where a person is exposed to a particular drug ingredient.,NA,No,Yes,CONCEPT,CONCEPT_ID,Drug,Ingredient,NA
drug_era,drug_era_start_date,Yes,date,NA,"The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure.",No,No,NA,NA,NA,NA,NA
drug_era,drug_era_end_date,Yes,date,NA,"The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules:
For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information.

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
100 procedure_occurrence procedure_occurrence_id Yes integer The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled. Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. Yes No NA NA NA NA NA
101 procedure_occurrence person_id Yes integer The PERSON_ID of the PERSON for whom the procedure is recorded. This may be a system generated code. NA No Yes PERSON PERSON_ID NA NA NA
102 procedure_occurrence procedure_concept_id Yes integer The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records whose source values map to standard concepts with a domain of "Procedure" should go in this table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Procedure&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Procedure NA NA
103 procedure_occurrence procedure_date Yes date Use this date to determine the date the procedure occurred. If a procedure lasts more than a day, then it should be recorded as a separate record for each day the procedure occurred, this logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM. No No NA NA NA NA NA
104 procedure_occurrence procedure_datetime No datetime NA This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
105 procedure_occurrence procedure_type_concept_id Yes integer This field can be used to determine the provenance of the Procedure record, as in whether the procedure was from an EHR system, insurance claim, registry, or other sources. Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. If a procedure is recorded as an EHR encounter, the PROCEDURE_TYPE_CONCEPT would be 'EHR encounter record'. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
106 procedure_occurrence modifier_concept_id No integer The modifiers are intended to give additional information about the procedure but as of now the vocabulary is under review. It is up to the ETL to choose how to map modifiers if they exist in source data. These concepts are typically distinguished by 'Modifier' concept classes (e.g., 'CPT4 Modifier' as part of the 'CPT4' vocabulary). If there is more than one modifier on a record, one should be chosen that pertains to the procedure rather than provider. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&conceptClass=HCPCS+Modifier&vocabulary=CPT4&vocabulary=HCPCS&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID NA NA NA
316 cdm_source cdm_source_abbreviation No varchar(25) The abbreviation of the CDM instance. NA No No NA NA NA NA NA
317 cdm_source cdm_holder No varchar(255) The holder of the CDM instance. NA No No NA NA NA NA NA
318 cdm_source source_description No varchar(MAX) The description of the CDM instance. NA No No NA NA NA NA NA
319 cdm_source source_documentation_reference No varchar(255) NA NA No No NA NA NA NA NA
320 cdm_source cdm_etl_reference No varchar(255) NA Put the link to the CDM version used. No No NA NA NA NA NA
321 cdm_source source_release_date No date The release date of the source data. NA No No NA NA NA NA NA
322 cdm_source cdm_release_date No date The release data of the CDM instance. NA No No NA NA NA NA NA

4
inst/csv/OMOP_CDMv5.4_Field_Level.csv
View File

@ -100,7 +100,7 @@ drug_exposure,refills,No,integer,This is only filled in when the record is comin
drug_exposure,quantity,No,float,NA,"To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is 'Has dose form'. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160.
Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see [how to calculate drug dose](https://ohdsi.github.io/CommonDataModel/drug_dose.html) for more information.
",No,No,NA,NA,NA,NA,NA
drug_exposure,days_supply,No,integer,NA,Days supply of the drug. This should be the verbatim days_supply as given on the prescription. If the drug is physician administered use duration end date if given or set to 1 as default if duration is not available.,No,No,NA,NA,NA,NA,NA
drug_exposure,days_supply,No,integer,NA,"The number of days of supply of the medication as recorded in the original prescription or dispensing record. Days supply can differ from actual drug duration (i.e. prescribed days supply vs actual exposure)."",""The field should be left empty if the source data does not contain a verbatim days_supply, and should not be calculated from other fields.<br><br>Negative values are not allowed. Several actions are possible: 1) record is not trustworthy and we remove the record entirely. 2) we trust the record and leave days_supply empty or 3) record needs to be combined with other record (e.g. reversal of prescription). High values (>365 days) should be investigated. If considered an error in the source data (e.g. typo), the value needs to be excluded to prevent creation of unrealistic long eras.",No,No,NA,NA,NA,NA,NA
drug_exposure,sig,No,varchar(MAX),This is the verbatim instruction for the drug as written by the provider.,"Put the written out instructions for the drug as it is verbatim in the source, if available.",No,No,NA,NA,NA,NA,NA
drug_exposure,route_concept_id,No,integer,NA,The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain.,No,Yes,CONCEPT,CONCEPT_ID,Route,NA,NA
drug_exposure,lot_number,No,varchar(50),NA,NA,No,No,NA,NA,NA,NA,NA
@ -334,7 +334,7 @@ cost,drg_concept_id,No,integer,NA,NA,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
cost,drg_source_value,No,varchar(3),Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups.,NA,No,No,NA,NA,NA,NA,NA
drug_era,drug_era_id,Yes,integer,NA,NA,Yes,No,NA,NA,NA,NA,NA
drug_era,person_id,Yes,integer,NA,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
drug_era,drug_concept_id,Yes,integer,The Concept Id representing the specific drug ingredient.,NA,No,Yes,CONCEPT,CONCEPT_ID,Drug,Ingredient,NA
drug_era,drug_concept_id,Yes,integer,The drug_concept_id should conform to the concept class 'ingredient' as the drug_era is an era of time where a person is exposed to a particular drug ingredient.,NA,No,Yes,CONCEPT,CONCEPT_ID,Drug,Ingredient,NA
drug_era,drug_era_start_date,Yes,date,NA,"The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure.",No,No,NA,NA,NA,NA,NA
drug_era,drug_era_end_date,Yes,date,NA,"The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules:
For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information.

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
100 procedure_occurrence procedure_occurrence_id Yes integer The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled. Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. Yes No NA NA NA NA NA
101 procedure_occurrence person_id Yes integer The PERSON_ID of the PERSON for whom the procedure is recorded. This may be a system generated code. NA No Yes PERSON PERSON_ID NA NA NA
102 procedure_occurrence procedure_concept_id Yes integer The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records whose source values map to standard concepts with a domain of "Procedure" should go in this table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Procedure&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Procedure NA NA
103 procedure_occurrence procedure_date Yes date Use this date to determine the date the procedure started. This is meant to be the **start date** of the procedure. It will be renamed in a future version to **PROCEDURE_START_DATE**. No No NA NA NA NA NA
104 procedure_occurrence procedure_datetime No datetime NA If the procedure has a start time in the native date, use this field to house that information. This will be renamed in a future version to **PROCEDURE_START_DATETIME**. No No NA NA NA NA NA
105 procedure_occurrence procedure_end_date No date Use this field to house the date that the procedure ended. This is meant to be the end date of the procedure. It is not required and for most cases will be the same as the PROCEDURE_START_DATE. No No NA NA NA NA NA
106 procedure_occurrence procedure_end_datetime No datetime Use this field to house the datetime that the procedure ended. This is meant to house the end datetime of the procedure and will most often be used in conjunction with the procedure_start_datetime to determine the length of the procedure. No No NA NA NA NA NA
334 episode episode_number No integer For sequences of episodes, this is used to indicate the order the episodes occurred. For example, lines of treatment could be indicated here. Please see [article] for the details of how to count episodes. No No NA NA NA NA NA
335 episode episode_object_concept_id Yes integer A Standard Concept representing the disease phase, outcome, or other abstraction of which the episode consists. For example, if the EPISODE_CONCEPT_ID is [treatment regimen](https://athena.ohdsi.org/search-terms/terms/32531) then the EPISODE_OBJECT_CONCEPT_ID should contain the chemotherapy regimen concept, like [Afatinib monotherapy](https://athena.ohdsi.org/search-terms/terms/35804392). Episode entries from the 'Disease Episode' concept class should have an episode_object_concept_id that comes from the Condition domain. Episode entries from the 'Treatment Episode' concept class should have an episode_object_concept_id that scome from the 'Procedure' domain or 'Regimen' concept class. No Yes CONCEPT CONCEPT_ID Procedure, Regimen NA NA
336 episode episode_type_concept_id Yes integer This field can be used to determine the provenance of the Episode record, as in whether the episode was from an EHR system, insurance claim, registry, or other sources. Choose the EPISODE_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
337 episode episode_source_value No varchar(50) The source code for the Episdoe 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. NA No No NA NA NA NA NA
338 episode episode_source_concept_id No integer A foreign key to a Episode Concept that refers to the code used in the source. Given that the Episodes are user-defined it is unlikely that there will be a Source Concept available. If that is the case then set this field to zero. No Yes CONCEPT CONCEPT_ID NA NA NA
339 episode_event episode_id Yes integer Use this field to link the EPISODE_EVENT record to its EPISODE. Put the EPISODE_ID that subsumes the EPISODE_EVENT record here. No Yes EPISODE EPISODE_ID NA NA NA
340 episode_event event_id Yes integer This field is the primary key of the linked record in the database. For example, if the Episode Event is a Condition Occurrence, then the CONDITION_OCCURRENCE_ID of the linked record goes in this field. Put the primary key of the linked record here. No No NA NA NA NA NA