***how to populate variables in demographics domain in sdtm

In SDTM, the Demographics (DM) domain contains subject-level information such as sex,
race, age, and other key demographic details. This data is typically derived from case report
forms (CRFs) and other clinical trial data sources.

Steps to Populate Variables in the DM Domain:

1. Identify Source Data

 The DM domain is primarily derived from the Subject Information or Demographics

CRF.
 It may also require data from enrollment records and external sources like electronic
health records.

2. Map Required Variables

The SDTM DM domain includes standard variables. Below are the key ones and how to derive them:

Variable
Label Derivation / Mapping
Name
STUDYID Study Identifier Populate with the study protocol number.
Domain
DOMAIN Always set to "DM".
Abbreviation
USUBJID
Unique Subject A concatenation of STUDYID, SITEID, and SUBJID (e.g., XYZ-
Identifier 1001-0005).
Subject Identifier
SUBJID Taken directly from the CRF.
for Study
RFSTDTC Reference Start Date Derived from informed consent date or first exposure date.
RFENDTC Reference End Date Derived from last visit date or last known status.
SITEID Study Site Identifier Taken from the CRF.
Extracted from the CRF, or calculated as RFSTDTC -
AGE Age
BRTHDTC.
AGEU Age Units Usually "YEARS".
Collected directly from the CRF (e.g., "M" for Male, "F" for
SEX Sex
Female).
Coded based on study protocol requirements (e.g., "WHITE",
RACE Race
"BLACK", "ASIAN").
Collected as per regulatory guidelines (e.g., "HISPANIC OR
ETHNIC Ethnicity
LATINO", "NOT HISPANIC OR LATINO").
Description of Study
ARM Derived from randomization dataset.
Arm
ARMCD Study Arm Code Shorter version of ARM.
COUNTRY Country of Subject Taken from the CRF.
 Variable
Label Derivation / Mapping
Name
BRTHDTC Birth Date Derived from CRF (format: YYYY-MM-DD).

3. Apply Data Transformations in SAS

Here’s a simple SAS program to populate some DM domain variables:

sas
CopyEdit
data DM;
set source.demographics; /* Source dataset */

length STUDYID $20 DOMAIN $2 USUBJID $30 SUBJID $10 SITEID $10 AGEU $5 SEX
$1 RACE $20;

STUDYID = "XYZ123";
DOMAIN = "DM";
USUBJID = catx("-", STUDYID, SITEID, SUBJID);
RFSTDTC = input(RFSTDAT, yymmdd10.); /* Convert start date */
RFENDTC = input(RFENDAT, yymmdd10.); /* Convert end date */

AGEU = "YEARS";
if BRTHDTC ne . then AGE = int((RFSTDTC - BRTHDTC)/365.25); /* Calculate
Age */

keep STUDYID DOMAIN USUBJID SUBJID SITEID RFSTDTC RFENDTC AGE AGEU SEX
RACE ETHNIC ARM ARMCD COUNTRY BRTHDTC;
run;

4. Validate and QC

 Check for missing values in required fields.

 Verify that all date formats follow ISO 8601 (YYYY-MM-DD).
 Ensure that USUBJID is unique for each subject.

 Cross-check AGE with BRTHDTC and RFSTDTC.

Real-Time Scenario Example:

Scenario: A subject is enrolled in a clinical trial, and their demographic data is collected as follows:

CRF Data Value

Study ID XYZ123
Site ID 1001
Subject ID 0005
Birth Date 1980-06-15
 CRF Data Value
Sex Male
Race Asian
Ethnicity Not Hispanic or Latino
Informed Consent Date 2023-05-10
Country USA

The derived DM dataset will look like:

STUDYI DOMAI USUBJI SUBJI SITEI RFSTD AG AGE SE RAC ETHNI COUNT
D N D D D TC E U X E C RY
NOT
XYZ123
2023-05- YEAR ASIA HISPAN
XYZ123 DM -1001- 0005 1001 43 M USA
10 S N IC OR
0005
LATINO

Assumptions for the Demographics (DM) Domain in SDTM

The Demographics (DM) domain in SDTM is a special-purpose domain that contains subject-
level information, such as age, sex, race, and study arm. Below are the key assumptions when
creating the DM domain:

1. General Assumptions

1. One Record per Subject

o The DM domain must contain only one record per subject (USUBJID).

o If multiple records exist, there is likely a data issue.

2. Mandatory in Every Study

o The DM domain must be included in every SDTM dataset submission.

o It serves as the foundation for linking other subject-level datasets.

3. USUBJID Must Be Unique Across the Study

o USUBJID should be a globally unique identifier for each subject across all sites
and studies.
o It is usually formed by concatenating STUDYID, SITEID, and SUBJID.
2. Assumptions Related to Variables

4. Dates Must Follow ISO 8601 Format

o All date variables (RFSTDTC, RFENDTC, BRTHDTC) should be in ISO 8601 format
(YYYY-MM-DD).

5. Age Should Be Consistent with Birth Date

o If AGE is provided, it should be consistent with BRTHDTC and RFSTDTC.
o AGE = int((RFSTDTC - BRTHDTC) / 365.25)

6. ARM and ARMCD Must Align with Study Design

o ARM (Treatment Group Description) and ARMCD (Short Code) should align with the
study protocol and randomization schedule.
7. Sex, Race, and Ethnicity Should Follow CDISC Standards
o SEX: Should be M (Male), F (Female), or U (Unknown).

o RACE: Must follow standard values like WHITE, BLACK, ASIAN, OTHER.

o ETHNIC:
Should be HISPANIC OR LATINO or NOT HISPANIC OR
LATINO.
8. Subjects Who Did Not Start the Study Must Still Have a DM Record
o Even if a subject was screened but not randomized, they should still have a DM
record with appropriate ARMCD = "SCRNFAIL" (Screen Failure).

9. Country Information Should Be Captured

o COUNTRY should be populated with the subject’s study site country.

3. Assumptions on Data Integrity and QC

10. Cross-Validation with Other Domains

 RFSTDTC should match the first recorded date in the Exposure (EX) domain, if
applicable.
 If a subject has an Exposure (EX) record, they should have a non-missing RFSTDTC.

11. Handling of Missing Data

 Missing AGE or BRTHDTC should be carefully reviewed for protocol deviations.

  Unknown SEX or RACE should be rare and must be justified.

12. Subjects Who Discontinue Must Have a Record in Disposition (DS) Domain

 If a subject discontinues early, they should have a corresponding record in the

Disposition (DS) domain.

how to populate variables in ds domain in sdtm

ChatGPT said:

In SDTM (Study Data Tabulation Model), the Disposition (DS) domain is used to capture
protocol milestones, subject disposition, and other relevant events. It includes information such
as screening status, study completion status, and reasons for discontinuation.

Steps to Populate Variables in DS Domain

1. Identify the Data Sources

 Raw datasets (e.g., Enrollment logs, Subject Status datasets, Disposition logs)
 Protocol-defined milestones (e.g., Randomization, Treatment, Completion)
 EDC (Electronic Data Capture) system exports

2. Required DS Domain Variables and How to Populate Them

Variable Description Source Example Value

STUDYID Study Identifier Raw Data ST12345
DOMAIN SDTM Domain Abbreviation Assigned Value DS
USUBJID Unique Subject Identifier Raw Data ST12345-001
Sequence Number (Unique
DSSEQ Derived (Auto-increment) 1, 2, 3...
within a subject)
Disposition Event
DSTERM CRF/Disposition logs COMPLETED, WITHDRAWN
Description
Standardized Disposition COMPLETED, WITHDRAWN
DSDECOD Controlled Terminology
Term BY SUBJECT
DSCAT Disposition Category CRF/Protocol DISPOSITION EVENT
Disposition Date (ISO 8601
DSSTDTC Raw Data 2025-02-28
Format)
 Variable Description Source Example Value
Derived (DSSTDTC -
DSDY Study Day of Disposition 15
RFSTDTC + 1)

3. Derivation Rules for Key Variables

 DSSEQ: Assign unique sequence numbers per subject.

sas
CopyEdit
proc sort data=ds_raw; by USUBJID DSSTDTC; run;
data ds;
set ds_raw;
by USUBJID;
if first.USUBJID then DSSEQ = 1;
else DSSEQ + 1;
run;
 DSDECOD: Map DSTERM values to controlled terminology.
 DSDY: Calculate relative study day.

sas
CopyEdit
DSY = DSSTDTC - RFSTDTC + 1;

4. Validate the Data

 Ensure all required fields (STUDYID, USUBJID, DSTERM, DSSTDTC) are populated.
 Confirm consistency with controlled terminology for DSDECOD.

 Verify that dates follow ISO 8601 format (YYYY-MM-DD).

Example DS Domain Dataset

STUDYI DOMAI USUBJI DSSE DSSTDT DSD

DSTERM DSDECOD DSCAT
D N D Q C Y
ST123- COMPLETE COMPLETE DISPOSITIO 2025-03-
ST12345 DS 1 30
01 D D N EVENT 10
WITHDRAW
ST123- WITHDRAW DISPOSITIO 2025-02-
ST12345 DS 1 N BY 15
02 N N EVENT 28
SUBJECT

Real-Time Scenario
 Scenario:
A subject is randomized on 2025-02-01, withdraws on 2025-02-20, and the study database
records WITHDRAWN as the reason.

Derived Data:

 DSDECOD: WITHDRAWN BY SUBJECT

 DSSTDTC: 2025-02-20

 DSDY: 20 - 1 + 1 = 20

Skip to content

ChatGPT

Share

You said:
assumpions of disposition domain

ChatGPT said:

In SDTM (Study Data Tabulation Model), the Disposition (DS) domain captures information about
subjects’ protocol milestones, such as screening status, treatment discontinuation, study completion,
and withdrawal reasons. When working with the DS domain, the following assumptions should be
considered:

1. One Record per Subject per Milestone/Event

 A subject may have multiple records in the DS domain, each representing different disposition
events (e.g., screening failure, study completion, treatment discontinuation).
 Each record should have a unique DSDECOD (Disposition Term) and DSTERM (Reported Term).
2. DSDECOD Standardization
 The DSDECOD variable must contain standardized terms from controlled terminology (e.g.,
"COMPLETED," "DISCONTINUED," "SCREEN FAILURE").
 DSTERM represents the reported term from the CRF (Case Report Form).
3. Relationship with Study Epochs and Phases
 Disposition events should align with study epochs (e.g., Screening, Treatment, Follow-up).
 The variable EPOCH can be derived based on study design.
4. Disposition Reason (DSCAT and DSSCAT Usage)
 DSCAT (Disposition Category) categorizes records (e.g., "DISPOSITION EVENT," "PROTOCOL
MILESTONE").
  DSSCAT (Disposition Subcategory) further specifies reasons (e.g., "REASON FOR
DISCONTINUATION").
5. Linkage to Other Domains
 The DS domain is related to Demographics (DM) for overall study status.
 Disposition status at study completion should match DM.RFSTDTC (Reference Start
Date) and DM.RFENDTC (Reference End Date) for consistency.
6. Handling of Discontinued Subjects
 If a subject discontinues, the disposition date (DSSTDTC) should reflect when the event
occurred.
 Reasons for discontinuation should be captured using DSTERM and mapped to a
standard DSDECOD value.
7. Controlled Terminology Compliance
 SDTM mandates controlled terminology for disposition terms. The sponsor should use CDISC-
defined values for DSDECOD and DSCAT whenever applicable.

Would you like an example of how to structure DS domain data in SAS or SQL?

You said:
yes

ChatGPT said:

Here’s an example of how to structure the Disposition (DS) domain data using both SAS and SQL.

1. Sample DS Domain Data

STUDYID USUBJID DSSEQ DSDECOD DSTERM DSCAT

STUDY01 101 1 SCREEN FAILURE Did not meet eligibility DISPOSITION EVENT SCREENING

STUDY01 102 1 COMPLETED Completed study as planned DISPOSITION EVENT STUDY CO

STUDY01 103 1 DISCONTINUED Lost to follow-up DISPOSITION EVENT REASON FO

 Skip to content
ChatGPT
Share

You said:
assumptions of adverse events domain
ChatGPT said:

In the Adverse Events (AE) domain of SDTM, several assumptions ensure consistency,
accuracy, and regulatory compliance when handling adverse event data. Here are the key
assumptions:

1. General Assumptions
 The AE domain captures all adverse events (AEs) occurring during the study, including
pre-treatment, on-treatment, and post-treatment AEs.
 AEs are independent of the investigational product unless explicitly specified.
 Only unique AEs should be recorded, meaning the same event should not be duplicated
unless it reoccurs after resolution.
 AEs should be coded using a standard dictionary such as MedDRA (Medical
Dictionary for Regulatory Activities).

2. Structural Assumptions
 Each row in the AE dataset represents one adverse event per subject (i.e., a subject may
have multiple records if they experience multiple events).
 Start and end dates must be provided if available, and missing dates should be handled
appropriately (e.g., imputed using SDTM conventions).
 The AE term (AETERM) should be captured verbatim as reported by the investigator
before dictionary coding.
 AE relationship (AEREL), severity (AESEV), seriousness (AESER), and outcome
(AEOUT) should be populated based on study protocol definitions.

3. Handling of AE Timing and Severity

 The start and end dates of AEs should be consistent with the exposure period of the
subject.
 If an AE is ongoing at the time of reporting, it should have a missing end date and be
flagged accordingly.
 Severity (AESEV) should follow a standard scale (e.g., mild, moderate, severe).
 Causality assessment (AEREL) should be recorded to indicate whether the event is
related to the study treatment.
 Serious adverse events (SAEs) must be flagged (AESER = "Y") as per regulatory
guidelines.

4. Relationship with Other Domains

 The AE domain is linked to the EX (Exposure) domain to analyze treatment-emergent
adverse events (TEAEs).
 It may also be linked to the MH (Medical History) domain to check if the AE is related
to pre-existing conditions.
 If a subject discontinues due to an AE, it should be linked to the DS (Disposition)
domain.
 Lab-related AEs may have corresponding records in the LB (Laboratory) domain.

5. Specific SDTM Implementation Guidelines

 AE recurrence should be handled by creating a new record for each episode.
 If an AE has multiple severity changes, each change should be recorded as a separate
entry with updated severity levels.
 In cases of missing or partial AE dates, imputation rules should be applied as per
CDISC guidelines.
 Pre-existing conditions should not be recorded as AEs unless they worsen during the
study.

Skip to content
ChatGPT
Share

You said:
how to populate variables in disposition domain in sdtm
ChatGPT said:

The Disposition (DS) domain in SDTM is used to capture information about the subject’s
disposition (e.g., study completion, discontinuation, or protocol deviations). It includes details
about study milestones such as screening, randomization, treatment discontinuation, and study
withdrawal.

Key Variables in DS Domain and How to Populate Them:

Variable Label How to Populate
STUDYID Study Identifier Assigned study ID (same across all domains)

DOMAIN Domain Abbreviation Always "DS"

USUBJID Unique Subject Identifier Unique identifier for the subject

 Variable Label How to Populate
DSSEQ Sequence Number Sequential number (1,2,3…) per subject to differentiate records

DSTERM Disposition Term The event term (e.g., "COMPLETED," "WITHDRAWN," "LOST TO FOLL

DSDECOD Standardized Disposition Term SDTM-controlled terminology (e.g., "COMPLETED," "ADVERSE EVENT,"

DSCAT Category of Disposition "DISPOSITION EVENT", "PROTOCOL MILESTONE", "OTHER EVENT

DSSTDTC Date/Time of Disposition Date of disposition event (ISO 8601 format, e.g., "2023-08-15")

EPOCH Epoch of the event (e.g., "SCREENING", "TREATMENT", "FOLLOW-UP")

DSSPID Sponsor-defined Identifier Tracking identifier from raw data (if applicable)

Steps to Populate DS Domain:

1. Extract Data from Source (e.g., Raw datasets, CRF forms, SDTM DM domain)
 Identify records where subjects completed or discontinued the study.
 Identify reasons for discontinuation (e.g., "Adverse Event," "Lost to Follow-Up").
 Identify key protocol milestones (e.g., Screening, Randomization, Study
Completion).
2. Standardize Event Terms using Controlled Terminology
 Map raw disposition reasons to DSTERM and DSDECOD using CDISC-
controlled terms.
3. Determine DSSTDTC (Date of Event)
 Extract the date of the disposition event from the raw dataset.
 Ensure the date is in ISO 8601 format (YYYY-MM-DD).
4. Assign the Correct EPOCH
 Use study design information to determine which epoch the event occurred in.
5. Generate DSSEQ
 Assign a unique sequence number per subject to distinguish multiple records.

Example DS Dataset (Populated)

 STUDYID DOMAIN USUBJID DSSEQ DSTERM DSDECOD
ABC123 DS 101 1 COMPLETED COMPLETED

ABC123 DS 102 1 ADVERSE EVENT ADVERSE EVENT

ABC123 DS 103 1 LOST TO FOLLOW-UP LOST TO FOLLOW-UP

Real-Time Scenario
Scenario: A subject was randomized but later withdrew due to an adverse event on 2025-01-15.

1. Extract the disposition data from raw datasets.

2. Map the reason for withdrawal to "ADVERSE EVENT" (DSTERM) using CDISC
terms.
3. Identify the date the event was recorded (DSSTDTC = "2025-01-15").
4. Determine the Epoch (TREATMENT).
5. Assign Sequence Numbers per subject.

This results in the following DS record:

STUDYID DOMAIN USUBJID DSSEQ DSTERM DSDECOD

ABC123 DS 102 1 ADVERSE EVENT ADVERSE EVENT DISPOS

Skip to content
ChatGPT
Share

You said:
assumptions of adverse events domain in sdtm
ChatGPT said:

The Adverse Events (AE) domain in SDTM is used to capture and standardize adverse event
data in clinical trials. The assumptions for the AE domain are as follows:
 1. General Assumptions:
 The AE domain includes all adverse events that occur during the study, whether related
or unrelated to the treatment.
 Each row represents one adverse event occurrence for a subject.
 The timing variables (e.g., AESTDTC, AEENDTC) indicate when the AE started and
ended.
 The severity, seriousness, causality, and outcome of the AE are captured.

2. Key Variable Assumptions:

 AEDECOD (Standardized Adverse Event Term):
 Uses MedDRA (Medical Dictionary for Regulatory Activities) coding.
 Should not be modified manually; it should match the MedDRA term
corresponding to the investigator-reported term (AETERM).
 AETERM (Reported Term):
 Captures the verbatim term from the investigator or source document.
 AESEV (Severity):
 Usually follows a grading scale like mild, moderate, severe or CTCAE
(Common Terminology Criteria for Adverse Events).
 AESER (Serious Event Flag):
 Coded as "Y" (Yes) if the event meets the criteria of seriousness (e.g., death,
hospitalization).
 AEREL (Causality Assessment):
 Indicates the investigator’s assessment of the relationship between the AE and
study treatment.
 AEACN (Action Taken):
 Specifies what actions were taken due to the AE (e.g., dose reduced, drug
withdrawn).
 AEOUT (Outcome of AE):
 Indicates if the AE resolved, worsened, or resulted in death.

3. Timing Considerations:
 AESTDTC (Start Date of AE) and AEENDTC (End Date of AE):
 Should be in ISO 8601 format (YYYY-MM-DD or YYYY-MM-DDThh:mm:ss).
 If AE is ongoing at the time of reporting, AEENDTC may be missing.
 AEENRF (End Relative to Reference):
 Used when AE end date is missing, indicating if the event was ongoing at the end
of the study.
 AESTDY / AEENDY (Study Day of AE Start and End):
 Calculated based on RFSTDTC (Reference Start Date of the Subject).

4. Relationship with Other Domains:

 Links to EX (Exposure Domain) if related to study drug.
 Can be related to CM (Concomitant Medications) if treatment was given for the AE.
 Can be associated with DS (Disposition Domain) if AE led to study discontinuation.

5. Additional Considerations:
 Duplicate AEs should be avoided – separate occurrences of the same AE should have
distinct records.
 AE that starts before study treatment begins is still recorded if relevant to the study.
 Ongoing AEs at the end of the study should be flagged properly.
 Uncoded AETERM should not be used in AEDECOD – all events should be mapped
to MedDRA term

Skip to content

ChatGPT

Share

You said:
how to populate variables in adverse events domain in sdtm

ChatGPT said:

In SDTM, the Adverse Events (AE) domain is used to capture information about adverse events
experienced by study subjects. Below is a step-by-step guide on how to populate key variables in the AE
domain.

1. Identify Source Data

Typically, the adverse events data comes from the CRF (Case Report Form) and sponsor-defined
adverse event coding dictionaries (e.g., MedDRA).

Common source datasets:

 Raw AE dataset: Contains collected AE data (e.g., RAW.AE).
 Medical Dictionary Data: Standard dictionaries like MedDRA provide terms (Preferred Term,
System Organ Class).

2. Mapping Key Variables in AE Domain

SDTM Variable Label Mapping/Derivatio

STUDYID Study Identifier Assign study identifier.

DOMAIN Domain Abbreviation Assign "AE".

USUBJID Unique Subject Identifier Concatenate study ID + site ID + subject ID.

AESEQ Sequence Number Assign a unique sequential number per subject.

AETERM Reported Term for the AE Directly from the CRF (verbatim term).

AEMODIFY Modified Reported Term Can be derived if any modifications are needed.

AEDECOD Dictionary-Derived Term Assign the Preferred Term (PT) from MedDRA.

AESOC System Organ Class Assign System Organ Class (SOC) from MedDRA.

AESEV Severity/Intensity Map Mild/Moderate/Severe as per protocol.

AESER Serious Event "Y" if serious, otherwise "N".

AEREL Causality Captured from CRF ( Not Related, Possible, etc.).

AEACN Action Taken with Study Treatment Captured from CRF ( Drug Withdrawn, Dose Reduce
 SDTM Variable Label Mapping/Derivatio

AEOUT Outcome of AE Derived from CRF ( Recovered, Fatal, etc.).

AESTDTC Start Date/Time of AE Convert to ISO 8601 format (YYYY-MM-DD).

AEENDTC End Date/Time of AE Convert to ISO 8601 format (YYYY-MM-DD).

AEONGO Ongoing Derive (Y if AE is ongoing, otherwise N).

AEENRF End Relative to Reference Period If AEONGO='Y', assign "ONGOING".

AESDTH Results in Death "Y" if AEOUT='Fatal', else "N".

AECONTRT Concomitant Treatment Given "Y" if any treatment was given for AE, else "N".

AETOXGR Toxicity Grade Map per CTCAE (if applicable).

3. Example SAS Code for AE Mapping

Here’s a SAS program to derive key variables in the AE domain:

sas
CopyEdit
data sdtm.AE; set raw.ae; /* Assign study-level variables */ STUDYID =
"XYZ123"; DOMAIN = "AE"; USUBJID = catx("-", STUDYID, SITEID, SUBJID); /*
Unique sequence number */ AESEQ = _N_; /* Adverse event terms */ AETERM =
AE_TERM; AEMODIFY = AE_TERM_MODIFIED; AEDECOD = AE_PREFERRED_TERM; AESOC =
AE_SYSTEM_ORGAN_CLASS; /* Severity and seriousness */ AESEV = AE_SEVERITY;
AESER = ifc(AE_SERIOUS="Yes", "Y", "N"); /* Relationship, action taken, and
outcome */ AEREL = AE_RELATIONSHIP; AEACN = AE_ACTION_TAKEN; AEOUT =
AE_OUTCOME; /* Dates conversion to ISO 8601 */ if AE_START_DATE ne . then
AESTDTC = put(AE_START_DATE, yymmdd10.); if AE_END_DATE ne . then AEENDTC =
put(AE_END_DATE, yymmdd10.); /* Ongoing AE flag */ if AEONGOING = "Yes" then
do; AEONGO = "Y"; AEENRF = "ONGOING"; end; else do; AEONGO = "N"; AEENRF =
 ""; end; /* Death-related flags */ AESDTH = ifc(AEOUT = "Fatal", "Y",
"N"); /* Concomitant treatment given */ AECONTRT = ifc(AE_TREATMENT_GIVEN =
"Yes", "Y", "N"); /* Assign toxicity grade if available */ AETOXGR =
AE_TOXICITY_GRADE; /* Keep necessary SDTM variables */ keep STUDYID DOMAIN
USUBJID AESEQ AETERM AEMODIFY AEDECOD AESOC AESEV AESER AEREL AEACN AEOUT
AESTDTC AEENDTC AEONGO AEENRF AESDTH AECONTRT AETOXGR; run;

4. Real-Time Scenarios and Interview Tips

1. How do you handle missing start or end dates?
 If AESTDTC is missing, check other datasets (e.g., EX for exposure start date).
 If AEENDTC is missing, check if the AE is ongoing ( AEONGO="Y").
2. What if an AE started before the study but worsened during the study?
 Capture the first onset date (AESTDTC), and specify AEENRF="BEFORE" if applicable.
3. How do you determine the relationship between AE and Study Drug?
 The investigator assesses the relationship (e.g., "Related", "Not
Related", "Possible").
4. What happens if an AE is still ongoing at the last visit?
 Set AEONGO="Y" and AEENDTC as missing.
5. How do you map MedDRA terms in SDTM?
 Use a MedDRA dictionary lookup to assign AEDECOD and AESOC.

5. Summary
 Identify and extract adverse event data from raw datasets.
 Ensure proper ISO 8601 date format conversion.
 Derive severity, seriousness, outcome, and treatment action.
 Use MedDRA coding for AEDECOD and AESOC.
 Handle missing or ongoing AEs properly.
 Validate data against SDTM rules (e.g., AEDECOD must not be missing).

Skip to content
ChatGPT
Share

You said:
how to populate variables in concomittent medicaion omain sdtm
ChatGPT said:

In SDTM, the Concomitant Medications (CM) domain is used to capture information about
medications taken by a subject during a clinical study, except for investigational products. Here’s
how you can populate key variables in the CM domain:

1. Required Variables in CM Domain

Variable Description
STUDYID Study Identifier

DOMAIN Always "CM"

USUBJID Unique Subject Identifier

CMSEQ Sequence Number (Unique per subject)

CMTRT Reported Name of the Medication

CMDECOD Standardized Medication Name (e.g., from WHO-DD)

CMCAT Category of Medication (if applicable)

CMDOSE Dose per administration

CMDOSU Unit of Dose (e.g., mg, mL)

CMDOSTXT Dose description if free text

CMDOSFRQ Frequency of dosing (e.g., BID, QD)

CMROUTE Route of administration (e.g., Oral, IV)

CMSTDTC Start Date/Time of Medication (ISO 8601)

CMENDTC End Date/Time of Medication (ISO 8601)

 Variable Description
CMONGO Ongoing Medication Indicator (Y/N)

CMINDC Indication for Medication

2. Steps to Populate Variables

Step 1: Extract Medication Data from CRF

 Locate medication data collected in CRF (e.g., Concomitant Medication Log).

 Identify variables that map to SDTM.

Step 2: Standardize Medication Names

 Map CMTRT (as reported by the site) to CMDECOD (coded term from WHO-DD
dictionary).

Step 3: Assign Start and End Dates

 Convert collected dates into ISO 8601 format.

 If only the year is collected, populate as YYYY.
 If only the year and month are collected, populate as YYYY-MM.

Step 4: Handle Ongoing Medications

 If medication is still ongoing, set CMONGO = "Y" and leave CMENDTC blank.

Step 5: Populate Dose and Route Information

 Extract dose, unit, and frequency.

 Convert textual values into standard values (e.g., "once daily" → "QD").

Step 6: Generate CMSEQ

 Assign a unique sequence number for each record per subject.

 3. Example of Populated CM Dataset
STUDYID DOMAIN USUBJID CMSEQ CMTRT CMDECOD CMDOSE
ABC123 CM 101-001 1 Ibuprofen Ibuprofen 200 m

ABC123 CM 101-001 2 Lipitor Atorvastatin 10 m

4. Real-Time Scenarios
Scenario 1: Missing End Date

 If the medication is ongoing, keep CMENDTC blank and set CMONGO = "Y".

Scenario 2: Partial Dates in CRF

 If only year is collected → 2023 (instead of full date).

 If year & month → 2023-05.

Scenario 3: Free Text Dose

 If a subject reports "Take as needed," populate CMDOSTXT = "As needed" and

leave CMDOSE/CMDOSU blank.

Scenario 4: Medication with Unknown Route

 If the route is unknown, CMROUTE = "UNKNOWN".

Scenario 5: Mapping Issues

 If a medication does not have a coded term in WHO-DD, CMDECOD remains blank.

Would you like a SAS example code to derive the CM domain? 🚀

You said:
es
ChatGPT said:

Here’s a SAS example code to derive the CM (Concomitant Medications) domain from raw
data:

SAS Code for CM Domain:

Expected Output
STUDYID DOMAIN USUBJID CMSEQ CMTRT CMDECOD CMDOSE
ABC123 CM 101-001 1 Ibuprofen Ibuprofen 200

ABC123 CM 101-001 2 Lipitor Atorvastatin 10

ABC123 CM 101-002 3 Metformin Metformin 500

ABC123 CM 101-003 4 Amoxicillin Amoxicillin 250

/* Step 1: Read Raw Data */

data raw_cm;

infile datalines dlm=',' dsd;

input USUBJID $ CMTRT $ CMDOSE CMDOSU $ CMDOSFRQ $ CMROUTE $ CMSTDTC $ CMENDTC $;

datalines;

101-001,Ibuprofen,200,mg,BID,Oral,2023-01-15,2023-01-20

101-001,Lipitor,10,mg,QD,Oral,2022-12-01,

101-002,Metformin,500,mg,BID,Oral,2023-02,

101-003,Amoxicillin,250,mg,TID,Oral,,
;

run;

/* Step 2: Standardize Medication Names using WHO-DD (for example) */

data cm_decoded;

set raw_cm;

length CMDECOD $40 CMONGO $1;

/* Mapping CMTRT to CMDECOD */

if CMTRT = "Ibuprofen" then CMDECOD = "Ibuprofen";

else if CMTRT = "Lipitor" then CMDECOD = "Atorvastatin";

else if CMTRT = "Metformin" then CMDECOD = "Metformin";

else if CMTRT = "Amoxicillin" then CMDECOD = "Amoxicillin";

else CMDECOD = ""; /* Keep blank if no dictionary match */

/* Step 3: Handle Ongoing Medications */

if CMENDTC = "" then CMONGO = "Y"; else CMONGO = "N";

/* Convert Partial Dates to ISO Format */

if length(CMSTDTC) = 4 then CMSTDTC = catx('-', CMSTDTC, "01-01");

else if length(CMSTDTC) = 7 then CMSTDTC = catx('-', CMSTDTC, "01");

if length(CMENDTC) = 4 then CMENDTC = catx('-', CMENDTC, "01-01");

else if length(CMENDTC) = 7 then CMENDTC = catx('-', CMENDTC, "01");

run;

/* Step 4: Assign Sequence Number */

data cm_final;

set cm_decoded;

length STUDYID $10 DOMAIN $2 CMSEQ 8;

STUDYID = "ABC123";

DOMAIN = "CM";

CMSEQ = _N_; /* Assign sequential numbers */

run;

/* Step 5: Display Final Output */

proc print data=cm_final noobs;

var STUDYID DOMAIN USUBJID CMSEQ CMTRT CMDECOD CMDOSE CMDOSU CMDOSFRQ CMROUTE
CMSTDTC CMENDTC CMONGO;

run;

Skip to content
ChatGPT
Share

You said:
assumpions of concommittent medication domain in sdtm
ChatGPT said:

In SDTM (Study Data Tabulation Model), the Concomitant Medication (CM) domain is
used to capture information about medications that a subject is taking in addition to the
investigational product during the study. When working with the CM domain, certain
 assumptions and guidelines should be followed to ensure data standardization and compliance.
Here are the key assumptions:

Assumptions for the CM (Concomitant Medication) Domain in SDTM

1. Definition & Purpose
 The CM domain captures medications taken by the subject before or during the
study, except for those administered as part of the study treatment (which would be recorded in
the EX domain).
2. One Record per Medication Course
 Each row represents a distinct course of medication use (from start to end date)
for a subject.
 If a subject stopped and restarted the same medication, it should be recorded as
separate records with different start dates.
3. Standardized Dictionary Coding (e.g., WHO-DD, MedDRA)
 Medications should be coded using a standardized dictionary, typically WHO
Drug Dictionary (WHO-DD).
 Variables like CMDECOD (Standardized Medication Name) should be used
for analysis.
4. Start & End Dates (CMSTDTC & CMENDTC)
 If exact dates are unknown, partial dates are allowed (e.g., YYYY-MM or
YYYY).
 If the medication is ongoing at the time of data collection, CMENRF (End Date
Reference) should be set to "ONGOING."
5. Route, Dose, and Frequency Standardization
 CMROUTE (Route of administration) and CMDOSFRQ (Dosing frequency)
should follow CDISC controlled terminology.
 CMDOSU (Dose Units) should be in standardized units (e.g., mg, mL).
6. Prior & Concomitant Medication Classification
 If a medication started before the study and continued during the study, it is
considered prior and concomitant.
 If a medication started after the study drug, it is only concomitant.
7. Handling Concomitant Medications in EDC (Electronic Data Capture)
 Investigators should document all relevant medications at screening and
throughout the study.
 Data should be mapped correctly from the EDC to the SDTM dataset.
8. Linking to Other Domains
 CM can be linked to Adverse Events (AE) if a medication was taken to treat an
adverse event (CMLNKID can be used for linking).
 It can also be associated with Medical History (MH) if the medication is related to
a pre-existing condition.
9. Use of Supplemental Qualifiers (SUPPCM)
 If additional details about a medication are collected but do not fit in standard CM
variables, they should be stored in SUPPCM.

Example of CM Dataset Structure

STUDYID USUBJID CMTRT CMDECOD CMSTDTC CMENDTC C
XYZ-123 1001 Aspirin Aspirin 2023-01-05 2023-02-15 Oral

XYZ-123 1001 Metformin Metformin 2023-02-01 Ongoing Oral

XYZ-123 1002 Ibuprofen Ibuprofen 2023-03-10 2023-03-12 Oral

Skip to content
ChatGPT
Share

You said:
assumptions of exposure domain in sdtm
ChatGPT said:

In SDTM (Study Data Tabulation Model), the Exposure (EX) domain is used to capture
information about the study treatment that a subject actually received. The assumptions for the
EX domain are:

1. One Record per Subject per Dosing Interval (if applicable)

 If dosing is planned in intervals (e.g., daily, weekly), then each record should represent
one dosing event or interval.
 For continuous exposure (e.g., an infusion), the start and end times should be captured.

2. Captures Actual Exposure, Not Planned Treatment

 The EX domain should contain actual treatment administration details, not what was
planned (which is in the TA (Trial Arms) and TX (Trial Elements) domains).
 If a subject missed a dose, no record should be present in EX for that dose.
 3. Capturing Dose Amount, Units, and Frequency
 EXDOSE: The actual dose administered.
 EXDOSU: The unit of dosing (e.g., mg, mL).
 EXDOSFRM: The formulation (e.g., tablet, injection).
 EXROUTE: The route of administration (e.g., oral, intravenous).
 EXFREQ: The frequency (e.g., QD, BID).

4. Handling Partial or Missed Doses

 If only part of a dose was administered, the EXDOSE should reflect the actual amount
given.
 If a subject completely missed a dose, there should be no record in EX (unless a
protocol deviation is recorded elsewhere).

5. Start and End Dates Must Be Captured

 EXSTDTC (Start Date/Time of Exposure)
 EXENDTC (End Date/Time of Exposure) for non-instantaneous treatments (e.g.,
infusions).
 For drugs taken at a single time point (e.g., a single tablet), EXENDTC may be the same
as EXSTDTC.

6. Consistency with Other Domains

 Should align with planned treatment in the TA and TX domains.
 Should not contradict records in AE (Adverse Events), CM (Concomitant
Medications), or EC (Exposure as Collected).

7. Units and Dosing Regimens Should Be Standardized

 Standard terminology should be used for dosing frequency, route, and formulation.
 EXTRT (Treatment Name) should match what is used in the Trial Design domain

Skip to content
ChatGPT
Share

You said:
how to populate variables in exposure domain in stm
ChatGPT said:
 In the Exposure (EX) domain of SDTM, we capture details about the study drug administration,
including dosage, frequency, route, and treatment duration. Populating variables in the EX
domain requires mapping raw clinical trial data (from EDC or CRF) into standardized SDTM
format.

Step-by-Step Approach to Populating Variables in EX Domain:

1. Identify Source Data

 The EX domain is typically derived from drug administration records collected in raw
datasets such as:
 Dosing CRF (Electronic Case Report Form)
 Medication logs
 IVRS (Interactive Voice Response System)
 Drug accountability records

2. Populate Key Variables

Below are some essential EX domain variables and how they are populated:

Variable Description Derivation / Example

STUDYID Study Identifier "XYZ-123" (Same for all subjects in the study)

DOMAIN Domain Abbreviation "EX" (Constant value)

USUBJID Unique Subject ID Concatenation of study ID, site ID, and subject number (e.g., "XYZ-123-

EXSEQ Sequence Number Sequential number (1, 2, 3, etc.) per subject

EXTRT Treatment Name "Drug A", "Placebo", etc.

EXDOSE Dose Administered Captured from the dosing CRF (e.g., "10 mg")

EXDOSU Dose Units "mg", "mL", "IU", etc.

EXDOSFRM Dose Form "Tablet", "Capsule", "Injection", etc.

EXDOSFRQ Dosing Frequency "QD" (once daily), "BID" (twice daily), "TID" (three times daily)

EXROUTE Route of Administration "Oral", "IV", "Subcutaneous", etc.

 Variable Description Derivation / Example
EXSTDTC Start Date/Time of Dosing Date in ISO 8601 format (YYYY-MM-DDThh:mm:ss)

EXENDTC End Date/Time of Dosing Date in ISO 8601 format (YYYY-MM-DDThh:mm:ss)

EXADJ Dose Adjustment "Y" if dose modified, else "N"

EXREASND Reason for Dose Not Given "Missed Visit", "Adverse Event", "Withdrawal", etc.

3. Example of EX Dataset
Let's assume subject 1001 took a drug orally for 3 days:

STUDYID DOMAIN USUBJID EXSEQ EXTRT EXDOSE EXDOSU

XYZ-123 EX XYZ-123-1001 1 Drug A 10 mg Tabl

XYZ-123 EX XYZ-123-1001 2 Drug A 10 mg Tabl

XYZ-123 EX XYZ-123-1001 3 Drug A 10 mg Tabl

4. Handling Special Cases

✅ Handling Partial or Missing Dates

 If only year and month are available (YYYY-MM), set unknown components as "--".
 Example: EXSTDTC = "2025-03--"
 If only year is available (YYYY), format as "YYYY----".
 Example: EXSTDTC = "2025----"

✅ Handling Subjects Who Missed a Dose

 If the subject missed a dose due to an Adverse Event (AE) or any other reason:
 Set EXDOSE = 0
 Capture reason in EXREASND
 Example:

ini
CopyEdit
USUBJID = "XYZ-123-1002"
EXSEQ = 4
EXDOSE = 0
EXREASND = "Adverse Event"

✅ Handling Dose Modifications

 If a subject had a dose change, add a new record with the updated dose and flag
adjustment in EXADJ.
raw;
E8601DT.); keep STUDYID DOMAIN USUBJID EXSEQ EXTRT EXDOSE EXDOSU EXDOSFRM
EXDOSFRQ EXROUTE EXSTDTC EXENDTC; run;

Skip to content
ChatGPT
Share

You said:
assumptions of vital signs domain in sdtm
ChatGPT said:

In SDTM, the Vital Signs (VS) domain is used to store subject-level vital sign measurements
such as blood pressure, heart rate, temperature, and respiratory rate. When working with the VS
domain, certain assumptions must be followed to ensure compliance with CDISC standards.
Here are the key assumptions:

1. Each record represents a single vital sign measurement.

 Each row in the VS dataset should capture one specific vital sign measurement at a given
time for a subject.

2. Standard Naming and Coding Conventions Apply.

 The variable VSTESTCD (Vital Signs Test Code) holds short test codes (e.g., SYSBP
for systolic blood pressure).
 The variable VSTEST (Vital Signs Test Name) provides a more descriptive test name
(e.g., "Systolic Blood Pressure").
 CDISC-controlled terminology should be used for VSTESTCD and VSTEST values.
 3. Measurement Units Must Be Standardized.
 The variable VSSTRESU (Standard Units) should contain standardized measurement
units (e.g., mmHg for blood pressure, bpm for heart rate).
 The original collected unit (VSORRESU) may be different, but it should be converted to
a standard unit in VSSTRESU.

4. The Timing of Measurements is Important.

 The timing of the measurement must be captured using appropriate timing variables
like VSDTC (Date/Time of Collection).
 If relevant, variables like VSTPT (Planned Time Point Name) and VSTPTNUM
(Planned Time Point Number) should be used to define scheduled time points.

5. Unplanned and Unscheduled Assessments Should Be Captured.

 If a vital sign was taken outside of scheduled visits, it should still be included,
and VSPERF (Vital Signs Performed Indicator) should indicate whether the measurement was
performed.
 VISITNUM (Visit Number) and VISIT (Visit Name) can be used to define the visit.

6. Handling of Missing Data.

 If a vital sign measurement was planned but not collected, VSPERF should be "N" (No),
and VSORRES, VSSTRESC, and VSSTRESN should be null.
 If collected but below detection limits, use appropriate conventions like "BLQ" (Below
the Limit of Quantification).

7. Relationship to Other Domains.

 If a vital sign is linked to an exposure (EX) or an adverse event (AE), RELREC (Related
Records dataset) should be used to establish the relationship.

8. Source of Data Should Be Clearly Identified.

 If vital signs are collected from multiple sources (e.g., manually recorded vs. electronic
devices), VSSPID (Sponsor-Defined Identifier) or VSLOC (Location of Measurement) can
be used to differentiate them.

9. Handling of Derived Values.

 Directly measured values should be stored in VSORRES.
 If derived values are included (e.g., Mean Arterial Pressure calculated from Systolic and
Diastolic BP), they should be clearly documented, usually as supplemental qualifiers
(SUPPVS).

Skip to content

ChatGPT

Share

You said:
how to populate variables in vital signs domain in sdtm domain

ChatGPT said:

In SDTM, the Vital Signs (VS) domain is used to store vital sign measurements such as blood pressure,
heart rate, temperature, and respiratory rate. Here’s how you can populate variables in the VS domain
step by step:

Step 1: Identify Source Data

The vital signs data is usually collected from CRF (Case Report Forms) or electronic health records (EHR).
It contains measurements for different visits and time points.

Example source data:

USUBJID VISIT VSDTC SYSBP DIABP PULSE TEMP

101 BASELINE 2024-01-01T08:00 120 80 72 37.0

101 WEEK 4 2024-02-01T08:30 122 82 70 36.8

 USUBJID VISIT VSDTC SYSBP DIABP PULSE TEMP

Step 2: Map Source Data to SDTM Variables

Now, let’s map this source data to SDTM variables.

SDTM Variable Description Mapping

STUDYID Study Identifier Assigned by study protocol

DOMAIN Domain Abbreviation "VS"

USUBJID Unique Subject Identifier From source

VSSEQ Sequence Number Auto-generated

VSTESTCD Vital Signs Test Short Name Predefined list (e.g., SYSBP, DIABP, PULSE, TEMP, RESP)

VSTEST Vital Signs Test Name Predefined list (e.g., Systolic Blood Pressure, Diastolic Blood Pr

VSORRES Original Result From source

VSORRESU Original Units e.g., "mmHg" for blood pressure, "bpm" for pulse, "°C" for tem

VSSTRESC Standardized Result in Character Same as VSORRES if no transformation needed

VSSTRESN Standardized Numeric Result Numeric conversion of VSORRES

 SDTM Variable Description Mapping

VSSTRESU Standardized Units Same as VSORRESU

VSSTAT Status "NOT DONE" if missing

VSREASND Reason Not Done If VSSTAT = "NOT DONE"

VSDTC Date/Time of Measurement ISO 8601 format (YYYY-MM-DDThh:mm)

VSPOS Position of Measurement SUPINE, SITTING, STANDING, etc.

VISITNUM Visit Number Mapped from Visit

VISIT Visit Name Mapped from Visit

Step 3: Transform Data into SDTM Format

Example Transformed SDTM Dataset:

STUDYID DOMAIN USUBJID VSSEQ VSTESTCD VSTEST VSO

ABC123 VS 101 1 SYSBP Systolic Blood Pressure 120

ABC123 VS 101 2 DIABP Diastolic Blood Pressure 80

ABC123 VS 101 3 PULSE Pulse Rate 72

ABC123 VS 101 4 TEMP Body Temperature 37.0

 STUDYID DOMAIN USUBJID VSSEQ VSTESTCD VSTEST VSO

ABC123 VS 101 5 RESP Respiratory Rate 16

Step 4: Generate SDTM Dataset Using SAS Code

Here’s an example SAS program to create the VS domain dataset:

sas
CopyEdit
data VS; set source_data; length STUDYID $10 DOMAIN $2 USUBJID $20 VSTESTCD
$10 VSTEST $50 VSORRES $10 VSORRESU $10; STUDYID = "ABC123"; /* Study ID */
DOMAIN = "VS"; VSSEQ = _N_; /* Auto-generated sequence */ VSDTC = VSDATE; /*
Ensure it's in ISO 8601 format */ /* Mapping Vital Signs */ array tests{5} $
SYSBP DIABP PULSE TEMP RESP; array testcds{5} $ ('SYSBP', 'DIABP', 'PULSE',
'TEMP', 'RESP'); array testnames{5} $ ('Systolic Blood Pressure', 'Diastolic
Blood Pressure', 'Pulse Rate', 'Body Temperature', 'Respiratory Rate'); array
units{5} $ ('mmHg', 'mmHg', 'bpm', '°C', 'breaths/min'); do i = 1 to 5; if
tests{i} ne . then do; VSTESTCD = testcds{i}; VSTEST = testnames{i}; VSORRES
= put(tests{i}, best.); VSORRESU = units{i}; VSSTRESN = tests{i}; VSSTRESU =
VSORRESU; output; end; end; drop i SYSBP DIABP PULSE TEMP RESP; run;

Step 5: Validate and QC the Dataset

After creating the dataset:

1. Check for missing values – Ensure no key variables like USUBJID, VSTESTCD, VSDTC are missing.
2. Verify unit consistency – Ensure VSSTRESU matches the expected standard units.
3. Ensure correct ISO 8601 format for data

Skip to content
ChatGPT
Share
 You said:
assumptions of inclusion and exclusions criteria in sdtm
ChatGPT said:

In SDTM (Study Data Tabulation Model), inclusion and exclusion criteria are crucial for
defining the study population. These criteria are typically documented in the IE
(Inclusion/Exclusion) domain and are based on protocol requirements. Here are some key
assumptions associated with inclusion and exclusion criteria in SDTM:

1. Assumptions for Inclusion Criteria

 Eligibility Confirmation: Inclusion criteria define the conditions a subject must meet to
be eligible for the study.
 Recorded at Screening: Inclusion criteria are assessed at the screening visit or before
enrollment.
 Subject-Level Criteria: These criteria apply at the subject level rather than visit-specific.
 Standard Representation: Inclusion criteria are represented in the IE domain
with IETESTCD = "INCL" and IETEST describing the specific criterion.
 Yes/No Assessment: Typically, IECAT (Category) is "INCLUSION,"
and IEORRES (Original Result) contains "Y" (Yes) if met or "N" (No) if not met.

2. Assumptions for Exclusion Criteria

 Preventing Participation: Exclusion criteria describe conditions that disqualify a subject
from the study.
 Medical/Clinical Conditions: Usually, these involve medical history, concomitant
medications, or lab results that could interfere with study outcomes.
 Applied Before Randomization: Assessed before randomization or study drug
administration.
 Standard Representation: Exclusion criteria are also captured in the IE domain,
with IETESTCD = "EXCL" and IECAT = "EXCLUSION."
 Rule-Based Determination: If an exclusion criterion is met (IEORRES = "Y"), the
subject is typically ineligible.

3. Handling Violations in SDTM

 If a subject violates inclusion/exclusion criteria but is still enrolled, these are
documented in the Deviations (DV) domain rather than the IE domain.
 Protocol deviations (DVTERM) describe what specific criterion was violated.

4. Mapping to SDTM Domains

 IE Domain: Captures inclusion and exclusion criteria assessments.
 DV Domain: Captures protocol deviations related to inclusion/exclusion violations.
 DS Domain (Disposition): May contain reasons for screen failures (DSDECOD =
"SCREEN FAILURE") if a subject does not meet eligibility.

5. Common Real-Time Scenarios

 Scenario 1: A subject does not meet an inclusion criterion but is still enrolled—this is
recorded in the DV domain.
 Scenario 2: A subject is excluded due to a medical condition—this is captured in
the IE domain.
 Scenario 3: A subject fails screening due to an exclusion criterion—this is reflected in
the DS domain with DSTERM = "Did not meet eligibility criteria."

Skip to content
ChatGPT
Share

You said:
how to popualate variables in inclusion and exclusion criteria omain sdtm
ChatGPT said:

In SDTM, the Inclusion/Exclusion Criteria (IE) Domain is used to capture whether a subject
meets the inclusion and exclusion criteria for a clinical trial. The IE domain follows a standard
structure with key variables that need to be populated accurately. Below is a step-by-step guide
on how to populate variables in the IE domain.

Key Variables in the IE Domain

Variable Label Description
STUDYID Study Identifier Unique study identifier.

DOMAIN Domain Abbreviation Always "IE" for the Inclusion/Exclusion Criteria domain.

USUBJID Unique Subject Identifier Unique identifier for each subject.

Specifies whether the criterion is "INCLUSION CRITERI

IECAT Inclusion/Exclusion Category CRITERIA".
 Variable Label Description
Inclusion/Exclusion Test Short
IETESTCD Name A short version of the criterion (e.g., "AGE", "MEDCOND

Descriptive version of the criterion (e.g., "Age Requiremen

IETEST Inclusion/Exclusion Test Name Condition").

IEORRES Original Result The subject's actual result (e.g., "Not Met", "Met").

IESTRESC Standardized Result Standardized result (e.g., "Y" for met, "N" for not met).

IESTAT Inclusion/Exclusion Status Populated if the test was not performed (e.g., "NOT DON

IESEV Severity Optional variable to specify severity if applicable.

IEDTC Date/Time of Criterion Evaluation Date when the inclusion/exclusion criterion was assessed.

VISITNUM, VISIT,
VISITDY Visit Information If applicable, visit when the criterion was assessed.

Steps to Populate the IE Domain

1. Extract Inclusion/Exclusion Criteria
 These are usually defined in the protocol under the eligibility criteria section.
2. Assign Inclusion or Exclusion Category (IECAT)
 If a criterion defines who can participate in the study → "INCLUSION
CRITERIA"
 If a criterion defines who cannot participate → "EXCLUSION CRITERIA"
3. Assign a Meaningful Test Code and Name (IETESTCD, IETEST)
 Example:
 If a subject must be between 18-65 years, use:
 IETESTCD = "AGE"
 IETEST = "Age Requirement"
4. Populate Results (IEORRES, IESTRESC)
 If the subject meets the criterion, assign:
 IEORRES = "Met"
 IESTRESC = "Y"
 If the subject does not meet the criterion:
 IEORRES = "Not Met"
 IESTRESC = "N"
5. Provide the Date of Assessment (IEDTC)
 Use the date when the eligibility was confirmed (e.g., Screening Visit Date).
6. Handle Missing Assessments (IESTAT)
 If a criterion was not assessed, assign:
 IESTAT = "NOT DONE"

Example Dataset for IE Domain

STUDYID DOMAIN USUBJID IECAT IETESTCD IETEST
STUDY01 IE 1001 INCLUSION CRITERIA AGE Age Requirement

STUDY01 IE 1001 EXCLUSION CRITERIA MEDCOND No Serious Medical Conditi

STUDY01 IE 1002 INCLUSION CRITERIA AGE Age Requirement

STUDY01 IE 1002 EXCLUSION CRITERIA PREG Not Pregnant

Real-Time Scenario
Scenario:

A clinical study requires:

1. Subjects must be between 18-65 years old.

2. Subjects must not have a serious medical condition.
3. Female subjects must not be pregnant.

Data Processing in SAS

You can populate the IE domain using PROC SQL or DATA STEP in SAS.

sas
CopyEdit
data ie; set source_data; /* Assuming source_data contains eligibility results
*/ length STUDYID $10 DOMAIN $2 USUBJID $20 IECAT $30 IETESTCD $10 IETEST $50
IEORRES $10 IESTRESC $1 IEDTC $10; DOMAIN = "IE"; STUDYID = "STUDY01"; IEDTC =
put(screening_date, yymmdd10.); /* Inclusion Criteria: Age Requirement */
IECAT = "INCLUSION CRITERIA"; IETESTCD = "AGE"; IETEST = "Age Requirement"; if
age >= 18 and age <= 65 then do; IEORRES = "Met"; IESTRESC = "Y"; end; else
do; IEORRES = "Not Met"; IESTRESC = "N"; end; output; /* Exclusion Criteria:
Serious Medical Condition */ IECAT = "EXCLUSION CRITERIA"; IETESTCD =
"MEDCOND"; IETEST = "No Serious Medical Condition"; if serious_med_cond = "No"
then do; IEORRES = "Met"; IESTRESC = "Y"; end; else do; IEORRES = "Not Met";
IESTRESC = "N"; end; output; run;

Key Takeaways
✔ IE domain is crucial in determining subject eligibility.
✔ Accurate mapping of inclusion/exclusion criteria from protocol is required.
✔ Ensure correct values for IEORRES and IESTRESC.
✔ Missing data handling using IESTAT if the criterion was not assessed.
✔ SAS coding can be used to automate the population of IE data.