update days supply convention to v5.3 and v6.0

This commit is contained in:
Maxim Moinat 2023-12-09 10:57:32 +01:00
parent 4a764dcca1
commit 46e13a1a3c
No known key found for this signature in database
GPG Key ID: 94EA516FB6174455
2 changed files with 2 additions and 2 deletions

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,"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,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

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

View File

@ -101,7 +101,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,"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,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

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
101 procedure_occurrence procedure_occurrence_id Yes bigint 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
102 procedure_occurrence person_id Yes bigint 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
103 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
104 procedure_occurrence procedure_date No 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
105 procedure_occurrence procedure_datetime Yes 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
106 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
107 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. If not available, set to 0. [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