diff --git a/docs/cdm54.html b/docs/cdm54.html
index 85e613d..c473f3e 100644
--- a/docs/cdm54.html
+++ b/docs/cdm54.html
@@ -3898,13 +3898,15 @@ 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.
+fields.
Negative values are not allowed. If the source has
+negative days supply the record should be dropped as it is unknown if
+the patient actually took the drug. 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.
User Guide
NA
ETL Conventions
@@ -11169,7 +11190,9 @@ PERSON drug_concept_idTable Description
A Condition Era is defined as a span of time when the Person is assumed to have a given condition. Similar to Drug Eras, Condition Eras -are chronological periods of Condition Occurrence. Combining individual -Condition Occurrences into a single Condition Era serves two +are chronological periods of Condition Occurrence and every Condition +Occurrence record should be part of a Condition Era. Combining +individual Condition Occurrences into a single Condition Era serves two purposes:
SELECT * FROM CONCEPT WHERE VOCABULARY_ID = 'CDM' AND CONCEPT_CLASS = 'CDM'
SELECT vocabulary_version from vocabulary where vocabulary_id = 'None'
Table Description
-The COHORT table contains records of subjects that satisfy a given -set of criteria for a duration of time. The definition of the cohort is -contained within the COHORT_DEFINITION table. It is listed as part of -the RESULTS schema because it is a table that users of the database as -well as tools such as ATLAS need to be able to write to. The CDM and -Vocabulary tables are all read-only so it is suggested that the COHORT -and COHORT_DEFINTION tables are kept in a separate schema to alleviate -confusion.
+The subject of a cohort can have multiple, discrete records in the +cohort table per cohort_definition_id, subject_id, and non-overlapping +time periods. The definition of the cohort is contained within the +COHORT_DEFINITION table. It is listed as part of the RESULTS schema +because it is a table that users of the database as well as tools such +as ATLAS need to be able to write to. The CDM and Vocabulary tables are +all read-only so it is suggested that the COHORT and COHORT_DEFINTION +tables are kept in a separate schema to alleviate confusion.
User Guide
NA
ETL Conventions
diff --git a/rmd/cdm53.Rmd b/rmd/cdm53.Rmd index b8076ce..5794dc1 100644 --- a/rmd/cdm53.Rmd +++ b/rmd/cdm53.Rmd @@ -19,7 +19,7 @@ library(stringr) ``` -Below is the specification document for the OMOP Common Data Model, v5.3 (previously v5.3.1). Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the [forums](https://forums.ohdsi.org/) or the [github issue](https://github.com/ohdsi/CommonDataModel/issues) page. +Below is the specification document for the OMOP Common Data Model, v5.3 (previously v5.3.1). Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). All tables should be instantiated in a CDM instance but do not need to be populated. Similarly, fields that are not required should exist in the CDM table but do not need to be populated. Should you have questions please feel free to visit the [forums](https://forums.ohdsi.org/) or the [github issue](https://github.com/ohdsi/CommonDataModel/issues) page. *__Special Note__ This documentation previously referenced v5.3.1. During the OHDSI/CommonDataModel Hack-A-Thon that occurred on August 18, 2021 the decision was made to align documentation with the minor releases. Hot fixes and minor.minor release can be found through the searching of tags.* diff --git a/rmd/cdm54.Rmd b/rmd/cdm54.Rmd index 69318ee..bce109f 100644 --- a/rmd/cdm54.Rmd +++ b/rmd/cdm54.Rmd @@ -19,7 +19,7 @@ library(stringr) ``` -This is the specification document for the OMOP Common Data Model, v5.4. **This is the latest version of the OMOP CDM.** Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the [forums](https://forums.ohdsi.org/) or the [github issue](https://github.com/ohdsi/CommonDataModel/issues) page. +This is the specification document for the OMOP Common Data Model, v5.4. **This is the latest version of the OMOP CDM.** Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). All tables should be instantiated in a CDM instance but do not need to be populated. Similarly, fields that are not required should exist in the CDM table but do not need to be populated. Should you have questions please feel free to visit the [forums](https://forums.ohdsi.org/) or the [github issue](https://github.com/ohdsi/CommonDataModel/issues) page. ### Current Support for CDM v5.4