Times and dates are an integral part of the data generated in all clinical trials. At least one timing
variable
must be included in all
SDTM
subject-level domain data sets. Time and date variables are
numerically formatted
according to the following ISO 8601 standard:
YYYY-MM-DDThh:mm:ss
, where
|
•
|
YYYY
is the four-digit year,
|
|
•
|
MM
is the two-digit month (values rage from 01-12),
|
|
•
|
DD
is the two-digit day (values range from 01-31),
|
|
•
|
hh
is the two-digit hour (values range from 00-23)
|
|
•
|
mm
is the two-digit minutes (values range from 00-59), and
|
|
•
|
ss
is the two-digit seconds (values range from 00-59).
|
|
•
|
T, which
indicates that time information is included (omitted if no time component is included),
|
|
•
|
-
, which either separates the date elements or can be used to indicate missing date components
|
|
•
|
:
, which separates time elements,
|
|
•
|
/
, which can be used to separate the date components from the time components, and
|
|
•
|
P
, which serves as a duration indicator and precedes the date/time components representing the duration of an event or intervention.
|
Note
: Spaces are never allowed in any ISO 8601-formatted representations of dates/times.
Dates and times can be and are expressed as complete dates/times, partial date/times, or incomplete date/times. JMP Clinical recognizes each of these elements and handles partial or incomplete dates/times as described in the separate FAQ:
How does JMP Clinical handle partial or incomplete date and time information?
|
•
|
When a partial date identified (
xxDTC
for
LB
,
EG
or
VS
), an asterisk (*) is appended to the end of the finding name or test code. You should review the findings for the appropriately reported set of observations.
|
|
•
|
When the reference date (
RFSTDTC
) is partial, an asterisk is appended to the
AETERM
. You should review all reported dates, study days, and contents for correctness.
|
|
•
|
When the AE start date (
AESTDTC
) is partial, an asterisk is appended to the date in the narrative. You should review all contents of the narrative.
|
|
•
|
When the AE end date (
AEENDTC
) is partial, an asterisk is appended to the date in the narrative. You should review the final outcome and narrative header information for correctness.
|
|
•
|
When any of the dosing records have partial dates for
exstdtc
or
exendtc
, an asterisk is placed in the drug header that explains dose at time of the event, or the pre- or post-dose status. All text related to the drug should be reviewed.
|
|
•
|
When the date of completion or discontinuation (
DSSTDTC
) is partial, an asterisk is appended to the date in the narrative. You should review these dates for correctness.
|
|
•
|
When either or both of the start or stop dates (
CMSTDTC
or
CMENDTC
) for Concomitant medications are partial, an asterisk is appended to the end of
CMTERM
or
CMDECOD
(based on the selected analysis option). You should review the data for this medication for correctness.
|
Domains are evaluated for SDTM folder and ADaM folder. Domains from SDTM folder are named using the 2-letter code
XX
, where
XX
. can be any two letters. For example, the domain containing adverse event data is
AE
(the data set name).
Domains from ADAM always contain
AD
as the first two letters of the domain name. ADSL is constant while other letters following the
AD
identify the specific domain. For example,
ADAE
is the ADaM domain
AE
.
Domains are classified as findings if
XXTESTCD
is present, interventions if
XXTRT
is present, or events if
XXDECOD
is present. If domain type cannot be identified for a given folder, the domain is ignored.
In addition, Basic Data Structure (BDS) is supported for ADAM. If
PARAMCD
and either
AVAL
or
AVALC
are present, the domain is considered a findings domain. If other variables are present as above and the domain type cannot be identified, it is ignored. This is true even if
XXTESTCD
is present since it would not be clear whether to transform ADaM variables or use SDTM variables for the domain.
Supplemental domains (
SUPPxx
) can be used by JMP Clinical. However, because these domains lack the standard data needed for analysis,
SUPPxx
domains are recognized only when the main domains are present. For example,
SUPPAE
is recognized when
AE
is present but is ignored when
AE
is not found.
SUPP
, where all supplemental data is within one data set, is not supported.
Finally,
RELREC
is currently purposefully excluded, as it is not used in the system.
|
•
|
On Treatment. Those are events that begin on or after the first dose of any study drug until the last date of dosing plus the offset
1
for end of dosing
|
This macro can be applied to event domains (including
AE
and
CE
), intervention domains (including
CM
) and findings domains (including
VS
).
|
•
|
Partial dates impute to earliest day (1st), and earliest month (Jan). Dates that are completely missing are not imputed. Observations recorded in
MH
are assumed to have occurred prior to initial dosing.
|
|
•
|
If either
xx.xxTRTEM
or
xx.TRTEMFL
are present with a value of either
Yes
or
Y
, the event is considered as treatment emergent.
|
|
•
|
The start dates for dosing are determined from
ADSL
.TRTSDTM
. If
ADSL.TRTSDTM
is not present,
ADSL.TRTSDT
is used. If
ADSL.TRTSDT
is not present,
DM.RFXSTDTC
is used. If
DM.RFXSTDTC
is not present, the earliest date in
EX.EXSTDTC
is used. If
EX.EXSTDTC
is not present,
DM.RFSTDTC
is used.
|
|
•
|
The end dates for dosing are determined from
ADSL.TRTEDTM
. If
ADSL.TRTEDTM
is not present,
ADSL.TRTEDT
is used. If
ADSL.TRTEDT
is not present,
DM.RFXENDTC
is used. If
DM.RFXENDTC
is not present, the
latest
date in
EX.EXENDTC
is used. If
EX.EXENDTC
is not present,
DM.RFENDTC
is used.
|
|
•
|
For
AE
,
CM
, and
CE
, if the date listed is on or after the dosing start date, the event is considered treatment emergent.
|
|
•
|
Note
: All events are considered pre-treatment for those subjects not on treatment.
|
When running Findings reports,
JMP Clinical
looks for and appends the values from either
xxPOS or xxSPEC
to the test names in
xxTESTCD
and
xxTEST
. This enables you to analyze findings data when multiple findings test names are identical across the variables:
xxTESTCD
,
xxPOS
, and
xxSPEC
.
If test name values are still not unique across categories of
xxCAT
or
xxSCAT
(if they exist) after appending the prior variables, a numeric index is appended to non-unique tests so that reports can still be run and tests are not inappropriately combined.
Keys give us insight into the uniqueness of a record or data set row. The CDISC
SDTM Implementation Guide
defines the following terms:
|
•
|
Natural Keys
are one or more variables whose contents uniquely distinguish every record (row) in the data set. For example, each row of the DM domain should represent a different subject. The natural keys in this instance could be Study Identifier (
STUDYID
) and Unique Subject Identifier (
USUBJID
).
|
|
•
|
A
Surrogate Key
is an artificially established single-variable identifier that uniquely identifies rows. This could include any of the
xxSEQ
variables. For example, if the vital signs data set contained 200 records, the VSSEQ variable could be numbered 1 to 200 to uniquely identify the rows.
|
Alternatively,
xxSEQ
can be made part of a natural key so that
xxSEQ
can count from 1 to
n
i
, where
n
i
is the total number of records for a subject. Here the keys would be
STUDYID
,
USUBJID, and
xxSEQ
.
If you have ever used PROC CONTENTS, the output header for a data set contains various information about the data set. One of these pieces of information is “
SORTED: YES/NO
”. If the data set happens to be sorted (in other words,
YES
), then additional information is provided in the PROC CONTENTS output after the description of the data set variables. For example, PROC CONTENTS is used on the
DM
domain for Nicardipine, following row in the output:
Sortedby STUDYID USUBJID
is added to the metadata that is stored in the SAS formatted data set; the variables used for the data set sort is what JMP Clinical uses to define the keys for a study.
If the study domains lack the
SORTEDBY
metadata associated with the data sets, JMP Clinical attempts to derive the keys based on suggestions provided in the
SDTM Implementation Guide
. However, the keys generated might not be the optimal set for a given domain.
So that happens if the supplied keys do not define the records (rows) uniquely? When the study is first added to JMP Clinical, a duplicate report is provided for each affected domain that details the records (rows) that cannot be uniquely determined. These records (rows) are still labeled as
New
in JMP Clinical. However, any record-level notes that are system- or user-generated would be associated with two or more records. This might be OK if there are few duplicates to contend with, but any duplicates should be reviewed as potential data errors (data that was mistakenly entered twice). When the study data is updated and redundancies remain, JMP Clinical has no way to match these records. In other words, it cannot assess whether any changes were made to the records or not. Again, if there are few duplicates, these records (rows) can be reviewed at multiple snapshots for correctness.
|
1
|
When you first add a study, examine the duplicate report. Identify the keys for each domain and make sure any duplicates are kept to a minimum (ideally, not present). Otherwise, the reviewing functionality is not as useful as it ultimately could be. For example, if the vital signs (VS) domain was sorted only by
STUDYID
and
USUBJID
using the
PROC SORT
code above, all records for the subject would be considered duplications. This would include multiple tests (such as heart rate, systolic and diastolic blood pressures) or records belonging to different visits.
|
|
3
|
Try to choose the smallest number of variables possible to define the keys, and choose variables that are not likely to change values. If a record has a change in one of the variables that make up the keys, there would be no way to match the record to previous versions of the record. However, since all records have Unique Subject Identifier (
USUBJID
), it is possible to view all notes at the subject level. Refer to the
SDTM Implementation Guide
for recommendations.
|
|
4
|
Given (3), do not use terms that rely on medical coding as part of the keys (in other words,
AEDECOD
based on MedDRA or
CMDECOD
based on
WHODRUG
). There are two reasons for this. First, medical coding might not be immediately available. This provides an opportunity for a missing value of
AEDECOD
to change to a nonmissing coded term later on. Further, sometimes over the course of a study, coded terms might change based on new insights of the clinical team, so, you should use verbatim terms such as
AETERM
or
CMTRT
.
|
|
5
|
The
xxSEQ
variable or
STUDYID
,
USUBJID
, and
xxSEQ
set might be good keys to use since these values are unlikely to change. However, the
xxSEQ
variable must be carefully maintained so that the number never changes for a particular record. For example, suppose a
CM
data set contains two records:
|
It is important that any new records are tacked at the end (and to continue the sequence of
CMSEQ
). Alternatively, if a record is deleted:
The sequence number must be kept consistent (in other words, 1 can never be used again). If you tend to define
xxSEQ
as a straight 1 to
N
for all records or 1 to
n
i
for each subject without any concern for what the row is, using
xxSEQ
as a key is not a good choice.
|
6
|
Alternatively, a single non-CDISC variable can be included in each domain and added to the
SORTEDBY
metadata. A good choice might include a record-identifier variable output from any data management system.
|
See the
SDTM Implementation Guide
for more information.
How does JMP Clinical define various terms for risk-based monitoring?
2
Subjects are considered
RANDOMIZED
if there is at least one record from
DS
where the index ((
DS.DSDECOD
3
),
RANDOMIZED
) is true.
Depending on the available information, subjects are considered
SCREEN FAILURES
if:
|
•
|
|
•
|
the value in
DS.EPOCH
is
SCREENING
, the value in
DS.DSCAT
is
DISPOSITION EVENT,
and value in
DS.DECOD
is
COMPLETED
, or
|
|
•
|
To determine whether the subjects have
COMPLETED
the trial, a
The SAS WHERE Expression
can be included on the analysis dialog to select the appropriate
DS
records (this statement should also select the records that indicate whether a subject has alternatively
DISCONTINUED
or
WITHDRAWN
). If this
The SAS WHERE Expression
is supplied and the value in
DS.DSDECOD
is
COMPLETED
, the subject is considered to have completed the trial. Otherwise, based on the available variables, the subject is considered to have completed the trial only if
|
•
|
the value in
DS.EPOCH
is
TREATMENT
and the value in
DS.DSCAT
is
DISPOSITION EVENT
and the value in
DS.DSDECOD
is
COMPLETED
, or
|
|
•
|
|
•
|
Subjects are considered to have
DISCONTINUED
or
WITHDRAWN
when a
The SAS WHERE Expression
is supplied and
DS.DSDECOD
is
^=COMPLETED
. Otherwise, based on the available variables the subject is considered to have discontinued the trial if
|
•
|
the value in
DS.EPOCH
is
TREATMENT
and the value in
DS.DSCAT
is
DISPOSITION EVENT
and the value in
DS.DSDECOD
is
^= COMPLETED
, or
|
|
•
|
|
•
|
|
•
|
Date/Time of First Study Treatment (
DM.RFXSTDTC
) is nonmissing, or
|
|
•
|
If records are available for the subject in the
EX
domain, or
|
|
•
|
|
•
|
An AE is considered fatal if the value in either
AE.AEOUT
or is either FATAL or DEATH, or if the value in
AESDTH
is either
Y
or
YES
.
A subject is considered to have signed informed consent if there is a value for Date/Time of Informed Consent (
DM.RFICDTC
).
|
•
|
the value in Date/Time of Death (
DM.DTHDTC
) is nonmissing, or
|
|
•
|
|
•
|
the subject discontinued the trial with and the value in
DS.DSDECOD
is either
DEATH
or
DIED
or
DEAD
, or
|
|
•
|
|
•
|
If the value in
DS.DSDECOD
is either
DEATH
,
DIED
, or
DEAD
, then the subject is considered to have
Discontinued Due to Death
, or
|
|
•
|
|
•
|
If the value in
DS.DSDECOD
is either
LOST TO FOLLOW-UP
,
LOST TO FOLLOWUP
,
LOST TO FOLLOW UP
, or
LTFU
, then the subject is considered to be
Lost to Followup
, or
|
|
•
|
If the value in
DS.DSDECOD
is either
ADVERSE EVENT
or
AE
, then the subject is considered to have
Discontinued Due to Adverse Event
, or
|
|
•
|
If the value in
DS.DSDECOD
is either WITHDRAWAL BY SUBJECT,
SUBJECT WITHDRAWAL
,
WITHDREW CONSENT
, or
SUBJECT WITHDREW CONSENT
, then the
Patient Withdrew from Study
, or
|
|
•
|
If none of the conditions listed above apply, the subject is considered to have
Discontinued for Other Reasons
.
|
With
J
treatment comparisons of ordered (smallest to largest)
p
-values
p
(j)
, the FDR
p
-value (Benjamini and Hochberg, 1995
4
) for the
j
th
hypothesis is:
The reference line is drawn at the -log10 transformation of the maximum raw p-value where the corresponding FDR
p
-value is less than or equal to
.
.
where
is the
mean
,
median
or user-supplied
center value
. The quantity
equals
,
, and
, for
Direction of Risk Signals
equal to B, U, and L, respectively, and
is the value for the
i
t
h
site or country and the
j
th
risk indicator.
is the
mean
,
median
or user-supplied
center value
. The quantity
equals
,
, and
, for
Direction of Risk Signals
equal to B, U, and L, respectively, and
is the value for the
i
t
h
site or country and the
j
th
risk indicator.
It is acceptable to specify both yellow and red risk thresholds, one or no risk thresholds. When specifying only a moderate threshold, the
Red Percent of Center
is left missing in the risk threshold data set so that moderate risk is considered
. In instances where values do not meet the criteria for moderate or severe risk, the risk is considered mild (green). Note that for risk thresholds defined using the above criteria, no threshold colors are determined in instances where the
mean
,
median
or
center value
is calculated or set to zero.
. In instances where values do not meet the criteria for moderate or severe risk, the risk is considered mild (green). Note that for risk thresholds defined using the above criteria, no threshold colors are determined in instances where the
mean
,
median
or
center value
is calculated or set to zero.
, or
,
is defined as described above.
In this case, it is acceptable to specify both thresholds, one threshold, or no risk thresholds at all. When specifying only a moderate threshold, the
Red Magnitude
is left missing in the risk threshold data set so that moderate risk is
. In cases where neither moderate nor severe risk applies, the risk is considered mild (green).
. In cases where neither moderate nor severe risk applies, the risk is considered mild (green).
There are five overall risk indicators. These are either weighted averages or combinations of the individual risk indicators for which at least one risk threshold is defined, where both the
Weight for Overall Risk Indicator
and the
standard deviation
of the indicator > 0.
The first, or
Overall Risk Indicator
, incorporates all of the variables meeting these criteria into a single measure that signifies the overall risk and performance of a clinical site. This indicator is generated only when the
Weight for Overall Risk Indicator
exceeds 0 for at least one of the available risk indicators exhibiting variability. If none of the individual indicators have a
Weight for Overall Risk Indicator > 0,
then the corresponding
Overall Risk Indicator
is not generated.
Each of the other four overall indicators -
Enrollment Metrics
,
Disposition
,
Adverse Events
, and
Manually Entered
- combines subsets of the risk indicators based on
Category
in the risk weight data set. By default,
Category
matches how variables are grouped in Risk-Based Monitoring, with
Manually Entered
applied to all user-supplied risk indicators from
Update Study Risk Data Set
. If no indicators have a
Weight for Overall Risk Indicator
> 0 for a given category, then the corresponding overall indicator is not provided.
The
Weight for Overall Risk Indicator
(
w
j
) can either be missing (in this case, it is assumed to be zero) or greater than or equal to zero. The weights are self-normalizing in that each weight is divided by the sum of all weights for variables contributing to the particular overall indicator. The contribution of each indicator to an overall indicator is based on its weight, center value (either
mean
,
median
or user-provided
center value
,
), standard deviation (
), and direction. In general, the value for an overall indicator for the
i
th
site or country and the
j
th
risk indicator is defined as
, where
,
, or
when Direction equals B,U, or L, respectively. This can be interpreted as larger values imply greater risk. By default, all weights are assumed equal to one in the Default Risk Threshold data set, meaning that each variable contributes equally to each overall indicator.
), standard deviation (
), and direction. In general, the value for an overall indicator for the
i
th
site or country and the
j
th
risk indicator is defined as
, where
,
, or
when Direction equals B,U, or L, respectively. This can be interpreted as larger values imply greater risk. By default, all weights are assumed equal to one in the Default Risk Threshold data set, meaning that each variable contributes equally to each overall indicator.
To avoid confusion in this FAQ, variables are written as
domain.domain-variable
. For example, USUBJID from the DM domain is written as
DM.USUBJID
. When a term can be applied to multiple domains, "xx" is used to imply a two-letter domain code.
Note: Although variables are listed in uppercase in this document, JMP Clinical is case insensitive.
Benjamini, Y. and Y. Hochberg. (1995). Controlling the False Discovery Rate: A practical and powerful approach to multiple testing.
Journal of the Royal Statistical Society, Series B
57
: 289-300.