You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: vignettes/checks/plausibleAfterBirth.Rmd
+2-1
Original file line number
Diff line number
Diff line change
@@ -18,9 +18,10 @@ output:
18
18
19
19
## Description
20
20
The number and percent of records with a date value in the **cdmFieldName** field of the **cdmTableName** table that occurs prior to birth.
21
+
Note that this check replaces the previous `plausibleTemporalAfter` check.
21
22
22
23
## Definition
23
-
This check verifies that events happen after birth. This check is only run on fields where the **PLAUSIBLE_AFTER_BIRTH** parameter is set to **Yes**. The birthdate is taken from the `person` table, either the `birth_datetime` or composed from `year_of_birth`, `month_of_birth`, `day_of_birth` (taking 1st month/1st day if missing).
24
+
This check verifies that events happen after birth. The birthdate is taken from the `person` table, either the `birth_datetime` or composed from `year_of_birth`, `month_of_birth`, `day_of_birth` (taking 1st month/1st day if missing).
24
25
25
26
-*Numerator*: The number of records with a non-null date value that happen prior to birth
26
27
-*Denominator*: The total number of records in the table with a non-null date value
The number and percent of records with a date value in the @cdmFieldName field of the @cdmTableName table that occurs after death.
21
+
The number and percent of records with a date value in the **cdmFieldName** field of the **cdmTableName** table that occurs more than 60 days after death.
22
+
Note that this check replaces the previous `plausibleDuringLife` check.
22
23
23
24
24
25
## Definition
26
+
A record violates this check if the date is more than 60 days after the death date of the person, allowing administrative records directly after death.
25
27
26
-
-*Numerator*:
27
-
-*Denominator*:
28
-
-*Related CDM Convention(s)*:
29
-
-*CDM Fields/Tables*:
30
-
-*Default Threshold Value*:
28
+
-*Numerator*: The number of records where date in **cdmFieldName** is more than 60 days after the persons' death date.
29
+
-*Denominator*: Total number of records of persons with a death date, in the **cdmTableName**.
30
+
-*Related CDM Convention(s)*: -Not linked to a convention-
31
+
-*CDM Fields/Tables*: This check runs on all date and datetime fields.
32
+
-*Default Threshold Value*: 1%
31
33
32
34
33
35
## User Guidance
34
-
36
+
Events are expected to occur between birth and death. The check `plausibleAfterbirth` checks for the former, this check for the latter.
37
+
The 60-day period is a conservative estimate of the time it takes for administrative records to be updated after a person's death.
38
+
By default, both start and end dates are checked.
35
39
36
40
### Violated rows query
37
41
```sql
38
-
42
+
SELECT
43
+
'@cdmTableName.@cdmFieldName'AS violating_field,
44
+
cdmTable.*
45
+
FROM @cdmDatabaseSchema.@cdmTableName cdmTable
46
+
JOIN @cdmDatabaseSchema.death de
47
+
ONcdmTable.person_id=de.person_id
48
+
WHERE cdmTable.@cdmFieldName IS NOT NULL
49
+
AND CAST(cdmTable.@cdmFieldName ASDATE) > DATEADD(day, 60, de.death_date)
39
50
```
40
51
41
-
42
52
### ETL Developers
53
+
Start dates after death are likely to be source data issues, and failing this check should trigger investigation of the source data quality.
54
+
End dates after death can occur due to derivation logic. For example, a drug exposure can be prescribed as being continued long after death.
55
+
In such cases, it is recommended to update the logic to end the prescription at death.
43
56
44
57
45
58
### Data Users
46
-
59
+
For most studies, a low number of violating records will have limited impact on data use as it could be caused by lagging administrative records.
60
+
However, it might signify a larger data quality issue.
61
+
Note that the percentage violating records reported is among records from death persons and such might be slightly inflated if comparing to the overall population.
The number and percent of records with a value in the @cdmFieldName field of the @cdmTableName that occurs after the date in the @plausibleStartBeforeEndFieldName.
21
+
The number and percent of records with a value in the **cdmFieldName** field of the **cdmTableName** that occurs after the date in the **plausibleStartBeforeEndFieldName**.
22
+
Note that this check replaces the previous `plausibleTemporalAfter` check.
22
23
23
24
24
25
## Definition
26
+
This check is attempting to apply temporal rules within a table, specifically checking that all start dates are before the end dates. For example, in the VISIT_OCCURRENCE table it checks that the VISIT_OCCURRENCE_START_DATE is before VISIT_OCCURRENCE_END_DATE.
27
+
The start date can be before the end date or equal to the end date. It is applied to the start date field and takes the end date field as a parameter. Both date and datetime fields are checked.
25
28
26
-
-*Numerator*:
27
-
-*Denominator*:
28
-
-*Related CDM Convention(s)*:
29
-
-*CDM Fields/Tables*:
30
-
-*Default Threshold Value*:
29
+
-*Numerator*: The number of records where date in **cdmFieldName** is after the date in **plausibleStartBeforeEndFieldName**.
30
+
-*Denominator*: The total number of records with a non-null start and non-null end date value
31
+
-*Related CDM Convention(s)*: -Not linked to a convention-
32
+
-*CDM Fields/Tables*: This check runs on all start date/datetime fields with an end date/datetime in the same table. It also runs on the cdm_source table, comparing `source_release_date` is before `cdm_release_date`.
33
+
-*Default Threshold Value*:
34
+
- 0% for the observation_period, vocabulary (valid_start/end_date) and cdm_source tables.
35
+
- 1% for other tables with an end date.
31
36
32
37
33
38
## User Guidance
34
-
39
+
If the start date is after the end date, it is likely that the data is incorrect or the dates are unreliable.
35
40
36
41
### Violated rows query
37
42
```sql
38
-
43
+
SELECT
44
+
'@cdmTableName.@cdmFieldName'AS violating_field,
45
+
cdmTable.*
46
+
FROM @schema.@cdmTableName cdmTable
47
+
WHERE cdmTable.@cdmFieldName IS NOT NULL
48
+
AND cdmTable.@plausibleStartBeforeEndFieldName IS NOT NULL
49
+
AND cdmTable.@cdmFieldName > cdmTable.@plausibleStartBeforeEndFieldName
39
50
```
40
51
41
-
42
52
### ETL Developers
53
+
There main reason for this check to fail is often that the source data is incorrect. If the end date is derived from other data, the calculation might not take into account some edge cases.
43
54
55
+
Any violating checks should either be removed or corrected. In most cases this can be done by adjusting the end date:
56
+
- With a few exceptions, the end date is not mandatory and can be left empty.
57
+
- If the end date is mandatory (notably visit_occurrence and drug_exposure), the end date can be set to the start date if the event. Make sure to document this as it leads to loss of duration information.
58
+
- If this check fails for the observation_period, it might signify a bigger underlying issue. Please investigate all records for this person in the CDM and source.
59
+
- If neither the start or end date can be trusted, pleaes remove the record from the CDM.
44
60
45
-
### Data Users
61
+
Make sure to clearly document the choices in your ETL specification.
46
62
63
+
### Data Users
64
+
An start date after the end date gives negative event durations, which might break analyses.
65
+
Especially take note if this check fails for the `observation_period` table. This means that there are persons with negative observation time. If these persons are included in a cohort, it will potentially skew e.g. survival analyses.
0 commit comments