Handling Multiple Visits in SDTM

Introduction

One of the most deceptively difficult parts of SDTM programming is visit handling.

At first glance, a visit seems straightforward. A clinical trial might define:

• Screening
• Baseline
• Week 4
• Week 8
• Week 12
• End of Treatment

The programmer can therefore create a simple mapping from source visit labels to SDTM variables.

Real clinical trial data are rarely that simple.

A subject may attend a scheduled Week 8 visit on Day 59 rather than Day 56. The subject may return two days later for an additional safety assessment. The subject may have an unscheduled visit because of an adverse event. A scheduled visit may be missed. A visit may span multiple calendar days. A subject may have more than one encounter associated with the same nominal study visit.

These situations create an important distinction between:

Understanding that distinction is fundamental to producing reliable SDTM datasets.

The Three Core Visit Variables

For many SDTM observation records, three variables form the basic representation of a visit:

• VISITNUM — numeric visit identifier used for sorting
• VISIT — descriptive visit name
• VISITDY — planned study day of the visit

CDISC defines VISITNUM as the clinical encounter number and VISIT as the protocol-defined description of the clinical encounter. VISITDY represents the planned study day of the visit.

VISIT Is Not the Same as Study Day

Consider a protocol-defined Week 8 visit.

The protocol may target Day 56.

The patient actually arrives on Day 59.

The resulting observation could contain:

VISITNUM = 4
VISIT    = "Week 8"
VISITDY  = 56
LBDY     = 59
LBDTC    = "2026-04-02"

The key distinction is:

This distinction is critical.

What Does "Multiple Visits" Actually Mean?

The phrase "multiple visits" can refer to several different situations.

These scenarios should not all be handled using the same programming rule.

The Most Important Distinction: Visit vs. Observation

Suppose a patient attends a Week 8 visit. During that encounter, the following are collected:

• Vital signs
• Laboratory samples
• ECG
• Physical examination
• Questionnaires

There is still only one clinical visit.

The fact that multiple records appear across SDTM domains does not mean that multiple visits occurred.

This is why VISITNUM is so important for cross-domain interpretation.

CDISC specifically describes visit variables as timing variables that can be used to link data across domains.

VISITNUM Is a Visit Identifier, Not a Record Counter

One of the most common mistakes is to increment VISITNUM every time another record appears.

Suppose a Week 8 visit contains:

Patient 001
Week 8
Blood pressure
Heart rate
Temperature
Weight
ECG
Chemistry panel

These observations do not require:

VISITNUM = 4
VISITNUM = 5
VISITNUM = 6
VISITNUM = 7
VISITNUM = 8
VISITNUM = 9

They can all belong to:

VISITNUM = 4
VISIT    = "Week 8"

The domain-specific sequence variable, such as VSSEQ or LBSEQ, distinguishes individual records within the domain.

A Simple Scheduled Visit Structure

Consider a protocol with the following planned schedule.

A subject does not necessarily attend on exactly those study days.

For example:

The visit identity can remain Week 4, Week 8, and Week 12.

The actual timing is represented separately.

VISITDY vs. --DY

This distinction deserves special attention because it causes frequent SDTM mapping errors.

Suppose:

and a scheduled Week 8 visit is planned for Day 57 but occurs on Day 60.

The record might contain:

VISITNUM = 4
VISIT    = "Week 8"
VISITDY  = 57
LBDTC    = "2026-03-01"
LBDY     = 60

The variables answer different questions:

How Study Day Is Calculated

SDTM study day is generally calculated relative to the sponsor-defined reference start date in DM, commonly RFSTDTC.

For an observation occurring on or after the reference date, a simplified conceptual calculation is:

For an observation occurring before the reference date:

Thus, if the reference date is January 1 and an observation occurs on January 1:

An observation on January 2 would be:

The exact reference-date definition should always follow the study's SDTM specification and applicable implementation guide.

Scheduled Visits and Visit Windows

Clinical protocols commonly define visit windows.

For example, Week 8 might be targeted for Day 57 with an allowed window of ±7 days.

Suppose the patient is evaluated on Day 63.

That does not automatically make the visit "Week 9."

The encounter can still be the protocol-defined Week 8 visit.

Actual Timing vs. Nominal Timing

This distinction can be represented conceptually as:

For example:

Protocol:
Week 8
Planned Day 57

Subject:
Actual visit Day 60

Laboratory:
Collected Day 60

SDTM:

VISITNUM = 4
VISIT    = "Week 8"
VISITDY  = 57
LBDY     = 60

Scheduled vs. Unscheduled Visits

An unscheduled visit is a genuine clinical encounter that was not part of the protocol-defined scheduled visit sequence.

Examples include:

• Evaluation of a new adverse event
• Unexpected clinical deterioration
• Repeat laboratory assessment requested by the investigator
• Additional safety evaluation
• Follow-up after an abnormal test
• Unplanned clinical contact requiring assessment

The SDTM structure supports descriptions of unplanned visits.

The Subject Visits domain can represent an unplanned visit and, in published SDTMIG versions, provides SVUPDES for describing what happened during an unplanned visit.

Example: An Unscheduled Visit

Suppose a subject attends:

Week 4       Day 29
Unscheduled  Day 35
Week 8       Day 57

A simplified SV structure might look like:

Decimal numbering is commonly useful when an unplanned visit needs to be inserted into the sequence between planned visits. CDISC explicitly notes that decimal numbering may be useful for inserting unplanned visits.

Unscheduled Does Not Mean "Outside the Visit Window"

This is one of the most important distinctions for programmers.

Suppose the protocol defines:

Week 8
Target Day 57
Window: Days 50–64

The subject arrives on Day 62.

This is still the scheduled Week 8 visit.

It is not necessarily an unscheduled visit.

By contrast, if the patient returns on Day 67 for an additional clinical encounter because of a new symptom, that encounter may be unplanned.

Multiple Visits With the Same Visit Name

Sometimes source data contain repeated labels such as:

Week 8
Week 8
Week 8

The programmer must determine whether these represent:

1. One visit with multiple observations
2. A repeated measurement within the same encounter
3. A second encounter related to the same nominal visit
4. An unscheduled visit incorrectly labeled by the source system

This cannot be solved reliably by simply counting records.

The source data, protocol, CRF design, and visit-definition metadata need to be considered together.

One Visit, Multiple Measurements

Consider three blood-pressure measurements taken during the same visit:

These are multiple observations.

They are not automatically three visits.

Variables such as sequence numbers, time-point variables, or other applicable domain variables may distinguish the records.

Visit vs. Time Point

A second major source of confusion is the distinction between a visit and a time point.

A visit describes a clinical encounter.

A time point can describe when a particular measurement occurred relative to another reference event.

For example, a pharmacokinetic visit might contain:

VISIT    = "Day 15"
VISITNUM = 5

PCTPTREF = "Dose"
PCTPT    = "PRE-DOSE"

PCTPT    = "30 MIN"
PCTPT    = "1 HOUR"
PCTPT    = "2 HOURS"
PCTPT    = "4 HOURS"

These are not necessarily five separate visits.

Example: Intensive PK Sampling

Suppose a patient attends a Day 15 PK visit. During the visit, samples are collected at:

• Pre-dose
• 30 minutes
• 1 hour
• 2 hours
• 4 hours
• 8 hours

The visit structure might therefore be:

The exact time-point variables depend on the domain and the applicable SDTM implementation guidance.

Subject Visits: The SV Domain

The Subject Visits domain provides a subject-level representation of actual visits.

It is different from simply looking at the VISIT variables scattered across LB, VS, EG, PE, QS, and other domains.

The SV domain can describe:

• Actual visit start dates
• Actual visit end dates
• Planned visit information
• Study day of the visit
• Unplanned visits
• Visit descriptions

CDISC describes SV as containing one record per subject visit per subject.

Key SV Variables

The published SDTM model describes SV as one record per subject visit and specifically allows the representation of unplanned subject visits.

Why SV Matters

Imagine the following data:

This provides a subject-level timeline of actual clinical encounters.

Multi-Day Visits

Not every visit occurs within a single calendar day.

Examples include:

• Inpatient treatment administration
• Extended safety monitoring
• Clinical observation periods
• Complex procedures
• Hospital-based assessments

Suppose a visit starts on Day 50 and ends on Day 53.

The SV record can represent both endpoints.

SVSTDTC = 2026-02-19
SVENDTC = 2026-02-22

SVSTDY  = 50
SVENDY  = 53

This is fundamentally different from creating four separate visits simply because the encounter spans four calendar days.

Which Date Should Be Used for an Observation?

A multi-day visit creates another important distinction.

Suppose:

SVSTDTC = 2026-02-19
SVENDTC = 2026-02-22

and a laboratory specimen is collected on February 21.

The laboratory observation's LBDTC should represent the actual collection date of the specimen, not simply the start date of the visit.

The observation can still carry the visit variables associated with the clinical encounter.

Missed Visits

A scheduled visit can be planned but never occur.

For example:

Week 4       Completed
Week 8       Missed
Week 12      Completed

A programmer should not create fabricated laboratory, vital-sign, or ECG records merely because the visit was scheduled.

Instead, the subject-visit representation and study-specific submission requirements determine how the missed visit is documented.

The FDA's current Study Data Technical Conformance Guide states a preference for submitting scheduled, whether or not they occurred, and unscheduled subject visits in a single SV dataset for clinical studies.

Trial Visits vs. Subject Visits

The SDTM framework distinguishes the planned trial structure from what actually happened to an individual subject.

The Trial Visits (TV) dataset describes planned visits.

The Subject Visits (SV) dataset describes actual subject visits.

CDISC describes TV as representing the planned order and number of visits in the trial, while SV describes the actual start and end dates for each subject's visit.

Why TV and SV Should Not Be Confused

Consider:

TV

VISITNUM   VISIT       VISITDY
1          Screening   -14
2          Baseline     1
3          Week 4      29
4          Week 8      57
5          Week 12     85

A particular subject might have:

SV

VISITNUM   VISIT       VISITDY   SVSTDY
1          Screening   -14       -12
2          Baseline     1          1
3          Week 4       29        31
4          Week 8       57        59
5          Week 12      85        --

The subject-specific data therefore preserve the difference between planned and actual participation.

Multiple Visits in a Treatment-Cycle Study

Oncology and other treatment studies often define visits by cycle and day.

For example:

Cycle 1 Day 1
Cycle 1 Day 8
Cycle 1 Day 15
Cycle 2 Day 1
Cycle 2 Day 8
Cycle 2 Day 15

A common mistake is to treat every occurrence of "Day 1" as the same visit.

They are not.

Cycle 1 Day 1 and Cycle 2 Day 1 are different clinical encounters.

Visit Names Must Be Consistent

Suppose source data contain:

C1D1
Cycle 1 Day 1
C01D01
Cycle1-Day1
Day 1 Cycle 1

These may all describe the same protocol-defined visit.

The SDTM mapping should normalize the source terminology into the study's defined SDTM visit convention.

For example:

VISIT = "Cycle 1 Day 1"
VISITNUM = 3

The source representation should remain traceable through the mapping and Define-XML metadata as appropriate.

Do Not Sort Visits Alphabetically

Consider:

Baseline
Cycle 1 Day 1
Cycle 1 Day 15
Cycle 1 Day 8
Cycle 2 Day 1
Screening
Week 12
Week 4
Week 8

Alphabetical ordering is clinically meaningless.

That is one reason VISITNUM exists.

A numeric visit identifier provides a standardized sorting mechanism.

Decimal VISITNUM Strategies

Decimal numbering can be useful when an unplanned visit occurs between two planned visits.

For example:

3.0   Week 4
3.1   Unscheduled
4.0   Week 8

The decimal value allows chronological sorting while retaining the planned visit sequence.

Another strategy could be:

3     Week 4
3.01  Unscheduled
4     Week 8

The specific convention is less important than consistency.

Multiple Unscheduled Visits

Suppose a subject has three unscheduled visits between Week 4 and Week 8.

The SDTM representation must preserve all genuine clinical encounters without mistaking repeated observations for additional encounters.

Visit Windows Should Usually Be Applied Before Mapping the Visit

A robust programming workflow separates:

1. Actual encounter identification
2. Protocol visit matching
3. Visit-window evaluation
4. SDTM visit assignment
5. Domain mapping

Conceptually:

Why Visit Assignment Should Not Be Based Solely on Date

Suppose:

Week 8 target day = 57
Week 12 target day = 85

Actual assessment = Day 62

A simple nearest-day algorithm could correctly classify Day 62 as Week 8.

But consider:

Week 8 window  = Days 50–64
Week 12 window = Days 78–92

Actual Day = 65

Day 65 is not automatically Week 12.

The subject may have had an unscheduled encounter.

This is why protocol-defined visit windows and source visit information should drive the mapping rather than a purely mathematical nearest-visit algorithm.

A Better Visit-Mapping Hierarchy

A robust hierarchy is:

1. Use explicit source-system visit information when reliable.
2. Map source visit labels to standardized protocol visit definitions.
3. Use protocol timing/window rules when deriving or resolving visits.
4. Use actual dates to populate actual timing variables.
5. Represent genuine unplanned encounters as unplanned visits.
6. Never create a new visit simply because multiple observations exist.

Example Source-to-SDTM Mapping

Example: Laboratory Data Across Multiple Visits

Suppose the source laboratory dataset contains:

USUBJID  Visit        PlannedDay  ActualDay  Test
001      Screening    -14         -13        ALT
001      Baseline       1           1        ALT
001      Week 4        29          31        ALT
001      Week 8        57          59        ALT
001      Unscheduled               65        ALT
001      Week 12       85          87        ALT

A reasonable SDTM representation could be:

The precise VISITNUM convention should be determined by the study's SDTM specification.

Repeated Assessments Within an Unscheduled Visit

Suppose the subject has two ALT results during the same unscheduled encounter.

Unscheduled Visit
Day 65

ALT = 92
ALT = 81

This does not automatically imply:

Unscheduled Visit 1
Unscheduled Visit 2

The source context should determine whether the measurements occurred during one encounter or two.

If both occurred during one encounter, they can share the visit assignment while being distinguished by the applicable laboratory record structure and sequence variables.

Same Visit, Different Collection Times

Consider an ECG collected at:

09:00
09:10
09:20

These can all belong to:

VISITNUM = 4
VISIT    = "Week 8"

The observation date/time variables preserve the actual collection times.

This is another reason not to use VISITNUM as a record identifier.

Visit Variables and Domain Sequence Variables

These serve different purposes.

Confusing these levels produces datasets that may look structurally plausible but do not accurately represent the underlying clinical data.

Visit-Level vs. Record-Level Uniqueness

Consider the following:

USUBJID = 001-001
VISITNUM = 4

That combination does not necessarily identify a unique laboratory record.

A single visit can contain many laboratory records.

For example:

001-001 / Visit 4 / Hemoglobin
001-001 / Visit 4 / ALT
001-001 / Visit 4 / AST
001-001 / Visit 4 / Creatinine

Therefore:

The correct uniqueness depends on the domain structure and its identifying variables.

Visit-Level Linking Across Domains

Suppose:

LB
USUBJID = 001
VISITNUM = 4
VISIT = Week 8

VS
USUBJID = 001
VISITNUM = 4
VISIT = Week 8

EG
USUBJID = 001
VISITNUM = 4
VISIT = Week 8

These records can be interpreted as observations associated with the same clinical encounter.

This cross-domain consistency is one of the most valuable properties of a well-designed SDTM visit structure.

Visit Consistency Across Domains

A common QC problem is:

LB:
VISITNUM = 4
VISIT = "Week 8"

VS:
VISITNUM = 4
VISIT = "Week 8"

EG:
VISITNUM = 4
VISIT = "W8"

Even if the records refer to the same encounter, inconsistent visit naming can create avoidable confusion.

The SDTM specification should establish a controlled convention for visit names and numbering.

Visit Mapping Table

A useful programming deliverable is a centralized visit-mapping table.

Centralizing this logic prevents different domains from independently deriving different visit values.

Why Centralized Visit Mapping Is Better

Suppose the LB programmer derives:

W8 → VISITNUM 4

while the VS programmer derives:

W8 → VISITNUM 5

The resulting datasets may each look internally consistent while being inconsistent with one another.

A shared mapping table eliminates this class of error.

Programming Pattern in SAS

A centralized visit lookup can be implemented with a SAS format, lookup dataset, or controlled mapping table.

data visit_map;
    length source_visit $30 visit $40 visit_type $15;
    input source_visit $ visitnum visitdy visit_type $;
    datalines;
SCR   1   -14 Scheduled
BL    2     1 Scheduled
W4    3    29 Scheduled
W8    4    57 Scheduled
W12   5    85 Scheduled
EOT   6   113 Scheduled
;
run;

Then the domain program can merge or look up the standardized values.

proc sort data=lb_source;
    by source_visit;
run;

proc sort data=visit_map;
    by source_visit;
run;

data lb_sdtm;
    merge lb_source(in=a)
          visit_map;
    by source_visit;

    if a;

    domain = "LB";
run;

SAS Example: Calculating Actual Study Day

A simplified implementation could be:

data lb_sdtm;
    set lb_source;

    if not missing(LBDTC) and not missing(RFSTDTC) then do;

        lb_date = input(substr(LBDTC,1,10), yymmdd10.);
        rf_date = input(substr(RFSTDTC,1,10), yymmdd10.);

        if lb_date >= rf_date then
            LBDY = lb_date - rf_date + 1;
        else
            LBDY = lb_date - rf_date;

    end;

    drop lb_date rf_date;
run;

Production code should account for the actual ISO 8601 precision and the study-specific reference-date rules rather than blindly truncating every date/time value.

R Example: Visit Mapping

The same concept can be implemented in R.

library(dplyr)

visit_map <- tibble::tribble(
  ~source_visit, ~VISITNUM, ~VISIT, ~VISITDY,
  "SCR",          1,         "Screening",       -14,
  "BL",           2,         "Baseline",          1,
  "W4",           3,         "Week 4",           29,
  "W8",           4,         "Week 8",           57,
  "W12",          5,         "Week 12",          85,
  "EOT",           6,         "End of Treatment",113
)

lb_sdtm <- lb_source %>%
  left_join(
    visit_map,
    by = "source_visit"
  )

R Example: Actual Study Day

library(dplyr)
library(lubridate)

lb_sdtm <- lb_sdtm %>%
  mutate(
    LBDTC_DATE = ymd(substr(LBDTC, 1, 10)),
    RFSTDTC_DATE = ymd(substr(RFSTDTC, 1, 10)),

    LBDY = if_else(
      LBDTC_DATE >= RFSTDTC_DATE,
      as.integer(LBDTC_DATE - RFSTDTC_DATE) + 1L,
      as.integer(LBDTC_DATE - RFSTDTC_DATE)
    )
  )

Deriving Unscheduled Visit Numbers

A useful strategy is to assign planned visits first and then assign unplanned encounters.

planned_visitnum <- c(
  "Week 4" = 3,
  "Week 8" = 4,
  "Week 12" = 5
)

# Example:
# Week 4        → 3
# Unscheduled   → 3.1
# Unscheduled   → 3.2
# Week 8        → 4

However, production implementation should derive these values from the study visit specification rather than simply incrementing decimal values in source order.

Do Not Use Visit Windows to Change Actual Dates

Suppose:

Planned Week 8 = Day 57
Actual collection = Day 61

The programmer should not change the laboratory date to Day 57.

Instead:

VISIT    = "Week 8"
VISITDY  = 57
LBDY     = 61
LBDTC    = actual collection date

The actual clinical data should remain actual.

Unscheduled Assessments Within a Scheduled Encounter

Another subtle situation occurs when a protocol visit contains an additional assessment that was not originally scheduled.

For example:

Week 8 Visit
Scheduled:
  CBC
  Chemistry
  Vital Signs

Additional:
  Repeat potassium measurement

The repeat potassium measurement may still belong to the Week 8 encounter if it occurred during that encounter.

The fact that the individual test was unscheduled does not necessarily mean the entire clinical encounter was an unscheduled visit.

Multiple Visits on the Same Calendar Day

It is possible for a subject to have more than one genuine clinical encounter on the same calendar day.

For example:

08:00  Scheduled treatment visit
15:00  Unscheduled clinical reassessment

The date alone cannot distinguish these encounters.

This is why visit identity and, where collected, actual date/time are important.

The resulting SV structure might conceptually contain:

When Two Encounters Share a Nominal Visit

A difficult source-data situation occurs when the source system labels two encounters as the same nominal visit.

For example:

Visit = Week 8
Encounter date = April 1

Visit = Week 8
Encounter date = April 3

The programmer should not automatically assign both records the same visit identifier simply because the source label is identical.

The key question is:

If they are two encounters, the study's visit-mapping convention should provide a way to represent them distinctly.

Visit Assignment and Source-System Data Quality

Electronic data-capture systems often provide visit labels automatically.

However, source visit labels may be:

• Missing
• Inconsistent
• Overwritten
• Entered manually
• Different between forms
• Different between vendors

Therefore, visit mapping should be treated as a data-integration problem, not just a variable-renaming exercise.

Multiple Vendors and Visit Harmonization

A study may receive:

• Laboratory data from one vendor
• ECG data from another vendor
• Imaging data from a central reader
• eCOA data from a separate platform
• Clinical data from the EDC

Each system may use different visit terminology.

For example:

These may or may not represent the same clinical encounter.

The programmer must reconcile the source-system definitions against the protocol and study visit metadata.

Do Not Infer Visit Equivalence From Labels Alone

"Visit 4" from one system does not necessarily mean the same thing as "Visit 4" from another.

The mapping should consider:

• Protocol-defined visit
• Planned study day
• Actual collection date/time
• Subject-level encounter information
• Source-system metadata
• Study-specific visit mapping rules

Visit Windows and Cross-Domain Consistency

Suppose the Week 8 visit occurs on Day 59.

The following records should generally share the same visit assignment when they belong to that encounter:

LB  VISITNUM = 4  VISIT = Week 8
VS  VISITNUM = 4  VISIT = Week 8
EG  VISITNUM = 4  VISIT = Week 8
PE  VISITNUM = 4  VISIT = Week 8

Their actual observation dates may differ if the assessments were performed at different times during the encounter.

Visit Windows Are Not the Same as Analysis Visits

This distinction becomes especially important when working with ADaM.

SDTM records preserve the collected clinical information.

ADaM may derive analysis visits based on protocol-defined windows or analysis rules.

For example:

SDTM:
Actual day = 59
VISIT = Week 8

ADaM:
Analysis visit = Week 8
Analysis day = 57
Window = predefined SAP rule

The exact derivation depends on the study.

Multiple Visits and Baseline

Baseline can be particularly complicated when multiple pre-treatment visits occur.

For example:

Screening Day -14
Screening Day -7
Baseline Day 1
Treatment Day 1

All of these may be distinct clinical encounters.

The SDTM dataset should preserve their visit identities.

ADaM may subsequently apply a rule such as "last nonmissing assessment before first dose" to identify an analysis baseline.

This illustrates why visit handling is foundational to traceability.

Multiple Visits and First Dose

A subject may have:

Visit 1: Screening
Visit 2: Baseline
Visit 3: Re-screening
Visit 4: Baseline
Visit 5: Treatment Day 1

The programmer should not assume that the first record labeled "Baseline" is necessarily the analysis baseline.

The protocol and analysis specifications determine how such cases are handled.

Re-Screening and Repeat Screening

Some studies allow subjects to fail screening and subsequently undergo re-screening.

This can create:

Screening
Screening
Re-Screening
Baseline

These encounters should not be collapsed merely because they have similar names.

The visit specification must determine whether they are separate encounters, repeat assessments, or another study-specific structure.

Screening Is Not Necessarily One Visit

Screening may span multiple encounters.

For example:

• Initial consent
• Medical history
• Laboratory testing
• Imaging
• Eligibility confirmation

Depending on the protocol and source data, these may occur during one visit or multiple encounters.

The programmer should model what actually occurred rather than assuming that everything before treatment is one encounter.

Visit Data From Multiple CRFs

One subject visit may generate records from many CRFs.

Visit 4
 ├── Vital Signs CRF
 ├── ECG CRF
 ├── Laboratory CRF
 ├── Physical Exam CRF
 └── Questionnaire CRF

The common visit metadata provide a mechanism for relating these observations to the same clinical encounter.

Visit Variables in Findings Domains

Findings domains such as LB, VS, EG, PE, QS, and others may contain visit variables.

The actual permitted variables and assumptions depend on the specific domain and implementation guide.

The programmer should therefore avoid assuming that every domain has exactly the same visit structure.

Visit Variables in Events and Interventions

Visit concepts can also be relevant to Events and Interventions domains where applicable.

For example, an adverse event may be recorded during a scheduled visit, but the event's actual onset date may occur elsewhere.

This is another reason not to interpret VISIT as the onset date.

The visit indicates the clinical encounter associated with collection or recording, while the event's own timing variables describe the event.

AE Example

Suppose a patient reports nausea during the Week 8 visit, but the nausea actually began on Day 55.

Conceptually:

VISIT    = Week 8
VISITNUM = 4

AESTDTC  = Day 55 date

AEDTC    = ...

AESTDY   = 55

The event was collected at a Week 8 encounter but began on an earlier day.

Multi-Day Visits and Event Timing

The distinction becomes even more important for inpatient encounters.

Suppose:

Visit:
Start Day 50
End Day 53

Adverse event:
Start Day 51
End Day 52

The event occurs within the visit but has its own timing.

Visit Variables Should Not Be Used as Surrogate Dates

A dangerous shortcut is:

if VISIT = "Week 8"
then use Week 8 planned date as observation date

This can overwrite actual clinical timing.

Instead:

VISIT    → clinical encounter
VISITDY  → planned visit day
--DTC    → actual observation/event/collection date
--DY     → actual study day

Handling Partial Visits

A subject may begin a visit but complete only part of the planned activities.

For example:

Week 12 visit
✓ Vital signs
✓ Physical examination
✗ Laboratory sample
✗ ECG
✗ Questionnaire

The visit still occurred.

The absence of an LB or EG record should not be interpreted as evidence that the entire visit was missed.

This is another reason SV can be useful for understanding whether a visit occurred independently of the individual domain records.

Visit-Level Completeness vs. Domain-Level Completeness

Unscheduled Visit vs. Unscheduled Assessment

This distinction deserves a direct comparison.

Visit Numbers Should Be Stable

A major objective of a good SDTM visit strategy is reproducibility.

If the same source data are processed twice, the visit assignments should not change simply because the input records happen to arrive in a different order.

Therefore, avoid algorithms such as:

sort source records by date
assign VISITNUM = 1, 2, 3, 4, ...

unless the study specification explicitly defines visits this way.

Such an approach may accidentally convert records into visits.

Chronological Order Is Not Always Visit Number

Suppose:

Screening planned Day -14
Screening performed Day -7
Baseline planned Day 1
Baseline performed Day 3

The actual chronology differs from the nominal visit days.

Yet the protocol visit sequence remains:

VISITNUM is therefore not simply an ordinal ranking of actual dates.

Visit Numbers and Protocol Sequence

The planned visit sequence should generally be stable across subjects unless the trial design explicitly varies by arm or other study factors.

This allows:

• Cross-subject sorting
• Cross-domain linking
• Visit-level reporting
• Traceability
• Quality-control checks

Arm-Specific Visits

Some trial designs have different visit schedules by treatment arm.

For example:

The Trial Visits structure can accommodate planned visits that vary by arm. CDISC explicitly describes TV as allowing a separate record per visit per arm when visit timing varies by arm.

Visit Mapping Should Consider Trial Design

A generic mapping such as:

VISITNUM 3 = Day 15

may be incorrect if different treatment arms have different planned schedules.

Instead, the mapping may need to consider:

ARMCD
+
VISITNUM
+
VISIT
+
VISITDY

This is particularly important in complex randomized or adaptive trial designs.

Epochs Are Not Visits

Another common conceptual mistake is confusing EPOCH with VISIT.

An epoch is a period of time in the trial, such as:

• Screening
• Treatment
• Follow-up

A visit is a clinical encounter within the study.

For example:

EPOCH = TREATMENT

Visit 3 = Week 4
Visit 4 = Week 8
Visit 5 = Week 12

Several visits can occur within the same epoch.

Visit vs. Element

Trial Elements represent planned periods or activities within the trial design, whereas visits represent clinical encounters.

For example:

Element:
Treatment

Visits:
Cycle 1 Day 1
Cycle 1 Day 8
Cycle 1 Day 15
Cycle 2 Day 1

The same treatment element can therefore contain many visits.

Visit Assignment in Longitudinal Data

A useful conceptual data model is:

Advanced Example: Complex Visit History

Consider a subject with the following actual history:

The most difficult record here is Day 59.

The source data must determine whether Day 59 represents:

1. A second encounter after Week 8
2. An extension of the Week 8 encounter
3. An unscheduled visit
4. A repeat laboratory collection during the same encounter

No purely mechanical algorithm can correctly determine this without the necessary source context.

The Programmer's Decision Tree

QC Rule: VISIT and VISITNUM Must Agree

A simple quality check is to identify subjects where one VISITNUM maps to multiple unrelated VISIT names.

For example:

VISITNUM = 4

Week 8
Cycle 2 Day 1
Unscheduled Visit

This may indicate a mapping problem.

A SAS check could be:

proc sql;
    create table visit_conflicts as
    select
        usubjid,
        visitnum,
        count(distinct visit) as n_visit_names
    from lb_sdtm
    group by usubjid, visitnum
    having calculated n_visit_names > 1;
quit;

The precise QC should account for the study's valid visit conventions, but unexpected combinations should be investigated.

QC Rule: VISIT Should Map Consistently to VISITNUM

The inverse check is also useful.

proc sql;
    create table visit_name_conflicts as
    select
        visit,
        count(distinct visitnum) as n_visitnum
    from lb_sdtm
    group by visit
    having calculated n_visitnum > 1;
quit;

Some studies may legitimately have repeated visit labels, so this is an investigative check rather than a universal error rule.

QC Rule: Planned Day Consistency

For planned visits, check that VISITDY is consistent with the study visit mapping.

proc sql;
    create table visitdy_check as
    select distinct
        visitnum,
        visit,
        visitdy
    from lb_sdtm
    order by visitnum;
quit;

Unexpected combinations should be compared against the study's TV and SDTM specifications.

QC Rule: Actual Day Should Agree With Actual Date

If:

LBDTC = 2026-03-01
RFSTDTC = 2026-01-01
LBDY = 60

then the programmer should independently verify the date arithmetic.

This catches errors caused by:

• Incorrect reference dates
• Off-by-one logic
• Time-zone handling
• Partial dates
• Incorrect date conversion

QC Rule: Actual Visit Dates Should Be Chronological

For SV:

SVSTDTC
SVENDTC

should be checked for logical consistency.

For example:

The same applies to subject-level chronological visit ordering.

QC Rule: SV Should Reconcile With Domain Visits

If an LB record contains:

USUBJID  = 001-001
VISITNUM = 4
VISIT    = Week 8

the corresponding subject visit should be evaluated for consistency.

A useful reconciliation is:

Unexpected visit combinations can reveal:

• Mapping errors
• Missing SV records
• Incorrect visit numbering
• Vendor integration problems
• Source-system inconsistencies

QC Rule: No Artificial Visits From Record Counts

A particularly useful conceptual QC is to compare:

against:

These values should not be expected to match.

One visit can generate hundreds of records.

Visit Mapping and Define-XML

The visit structure should be documented clearly in study metadata.

A reviewer should be able to understand:

• How visits were numbered
• How visit names were standardized
• How unplanned visits were represented
• How visit timing was derived
• How source-system visits mapped to SDTM

This documentation contributes to submission traceability and reviewability.

Visit Mapping and Annotated CRF

Visit variables should also be traceable to the data-collection structure.

For example, if the CRF contains:

Visit: Week 8
Visit Date: 03-Apr-2026

the annotated CRF and metadata should support understanding of how those source concepts become:

VISIT    = Week 8
VISITNUM = 4
VISITDY  = 57
SVSTDTC  = 2026-04-03

The actual derivation depends on the study implementation.

Common Mistake: VISITNUM = Visit Date

Some programmers are tempted to create:

VISITNUM = 20260403

This is incorrect conceptually.

VISITNUM is a clinical encounter number, not a date representation.

Common Mistake: VISIT = Study Day

Another problematic strategy is:

VISIT = "Day 59"

when the actual protocol-defined visit is Week 8.

The fact that the patient was seen on Day 59 does not necessarily redefine the visit.

Common Mistake: VISITDY = Actual Day

For the same example:

Planned Week 8 = Day 57
Actual collection = Day 59

Do not automatically create:

VISITDY = 59

when VISITDY is intended to represent the planned study day.

Instead:

VISITDY = 57
--DY    = 59

Common Mistake: Every Unscheduled Record Gets a New Visit

Suppose five laboratory tests are collected during one unscheduled encounter.

It is incorrect to create:

Unscheduled 1
Unscheduled 2
Unscheduled 3
Unscheduled 4
Unscheduled 5

simply because there are five records.

The visit is an encounter-level concept.

Common Mistake: Collapsing All Unscheduled Visits

The opposite error is:

All unscheduled encounters
→ VISITNUM = 99
→ VISIT = "Unscheduled"

This may destroy important distinctions between separate encounters.

If a subject has three genuine unscheduled visits, the submission should preserve those encounters according to the study's defined numbering strategy.

Common Mistake: Using Nearest Planned Day Without a Window Rule

Suppose planned visits are:

Day 29
Day 57
Day 85

and the observation occurs on Day 71.

The nearest planned visit is Day 57.

But that does not automatically mean the observation belongs to Week 8.

The actual protocol window and source encounter information must be considered.

Common Mistake: Treating Every Date as a Visit

A patient may have:

Lab collected Day 55
Lab collected Day 56
Lab collected Day 57

This does not automatically represent three visits.

They may represent:

• One multi-day encounter
• Multiple assessments within one visit
• Three separate encounters

The source context determines the answer.

Common Mistake: Ignoring Multi-Day Visits

If an inpatient encounter runs from Day 50 to Day 53, creating four visits would distort the subject's clinical history.

Use the appropriate start/end visit representation.

Common Mistake: Creating Visits From Analysis Windows

A statistical programmer may define:

Week 8 analysis window
Day 50–64

That does not mean every observation in Days 50–64 should be assigned a new clinical visit.

Analysis windows and clinical encounters are different concepts.

Visit Assignment in ADaM vs. SDTM

A useful distinction is:

A Complete Example

Consider a hypothetical clinical trial with:

Screening       Day -14
Baseline        Day 1
Week 4          Day 29
Week 8          Day 57
Week 12         Day 85
End of Treatment Day 113

Subject 001 has:

Screening       Day -12
Baseline        Day 1
Week 4          Day 31
Unscheduled     Day 35
Week 8          Day 59
Week 12         Missed
EOT             Day 108

A subject-level visit structure could conceptually look like:

This illustrates several important principles simultaneously:

• Actual visit timing can differ from planned timing.
• Unscheduled encounters can be inserted into the sequence.
• A missed planned visit does not require fabricated observations.
• End-of-treatment timing can differ from the nominal planned day.

Example Domain Records for the Same Subject

The Week 8 encounter might produce:

LB

USUBJID   VISITNUM   VISIT    VISITDY   LBDY
001       4          Week 8     57       59

VS

USUBJID   VISITNUM   VISIT    VISITDY   VSDY
001       4          Week 8     57       59

EG

USUBJID   VISITNUM   VISIT    VISITDY   EGDY
001       4          Week 8     57       59

This creates a coherent cross-domain representation of the encounter.

Advanced Issue: Visit and Partial Dates

Source data may contain incomplete dates.

For example:

2026-04
2026-04-??
2026-04-03

A programmer should not invent an exact study day merely to populate --DY.

The SDTM handling of incomplete dates should follow the applicable date representation rules and study specifications.

Visit information may still provide useful context even when the actual observation date is incomplete.

Visit and Date/Time Precision

An SDTM record may contain:

LBDTC = 2026-04-03T14:35

while another record may contain only:

LBDTC = 2026-04-03

The visit assignment should not be based on artificial precision that was not present in the source data.

Visit and Time Zones

Multi-site studies can introduce time-zone considerations when date/time values originate from systems using different conventions.

For clinical visit assignment, the study's data integration specification should define how source date/time values are standardized.

The important principle is:

Visit Metadata Should Be Version Controlled

Visit structures can change during a study.

For example:

• Protocol amendment adds a visit.
• Visit timing changes.
• Unscheduled assessment rules change.
• A treatment cohort follows a different schedule.

The SDTM programming metadata should therefore be version controlled.

Protocol Amendments

Suppose Version 1 of the protocol contains:

Week 8
Week 12

and Version 2 adds:

Week 10

The visit numbering strategy must be considered carefully.

Do not renumber historical visits simply because the protocol now contains an additional visit.

The mapping should reflect the applicable protocol and study metadata.

Visit Structure and Data Cutoff

At a data cutoff, a subject may have:

Week 8 completed
Week 12 ongoing
Week 16 planned but not yet occurred

The submission data should reflect what actually occurred within the relevant cutoff.

Future planned visits should not be represented as completed clinical encounters.

Visit Structure and Late Data

A laboratory result may arrive after the visit has already been processed.

The late arrival date is not necessarily the clinical collection date.

For example:

Specimen collected: March 1
Result received:    March 4
Visit:              Week 8

The laboratory observation's collection date remains March 1.

The visit should be associated with the clinical encounter on which the specimen was collected.

Visit Data and Vendor Transfers

Vendor data often arrive with their own visit variables.

For example:

Vendor:
VISIT = "V08"
VISIT_DATE = 2026-03-01

SDTM:
VISIT = "Week 8"
VISITNUM = 4
VISITDY = 57
LBDTC = 2026-03-01
LBDY = 60

The vendor's visit label should not automatically become the SDTM visit name.

It should be mapped through the study's standardized visit metadata.

Subject Visits as a Reconciliation Dataset

SV can serve as an important reconciliation point.

For example:

SV says:
Week 8 occurred on Day 59

LB says:
Week 8 laboratory collected Day 59

VS says:
Week 8 vital signs collected Day 59

EG says:
Week 8 ECG collected Day 59

The consistency across these datasets supports confidence in the visit structure.

A mismatch can indicate an issue that needs investigation.

Example Reconciliation Report

Subject 003 deserves investigation because the VS assessment occurs on Day 70, which may represent either:

• A legitimate separate encounter
• An unscheduled assessment
• A source-data issue
• A visit-mapping problem

The discrepancy should not automatically be corrected.

Visit Reconciliation Should Be Investigative

QC should identify unexpected patterns.

It should not automatically rewrite data.

Handling Multiple Visits in CDISC-Compliant Programming

A robust implementation can be summarized as:

Current Standard Context

For published SDTM implementation work, the version of SDTMIG being used for the study should be explicitly identified.

SDTMIG v3.4 is a published implementation guide and includes expanded Subject Visits guidance.

CDISC is also developing SDTMIG v4.0. As of the current CDISC standards roadmap, SDTMIG v4.0 remains under development/review rather than being the published implementation guide that should simply be substituted into every existing study.

The emerging v4.0 work includes changes to visit and subject-level structures, including an SV sequencing change discussed by CDISC in its 2026 SDTMIG v4.0 materials.

FDA Submission Considerations

The FDA's current Study Data Technical Conformance Guide states a preference for scheduled visits, including those that did not occur, and unscheduled visits to be submitted together in the SV dataset.

This makes SV particularly important for regulatory review because it gives the reviewer a consolidated subject-level representation of visit history.

How to Design a Visit Specification

A strong visit specification should include at least:

Recommended Visit Metadata Architecture

For complex studies, it is useful to separate planned visit metadata from subject-level encounter data.

TV_METADATA
-----------
VISITNUM
VISIT
VISITDY
ARMCD
EPOCH
WINDOW_START
WINDOW_END
VISIT_TYPE

        ↓

SUBJECT_VISITS
--------------
USUBJID
VISITNUM
VISIT
VISITDY
SVSTDTC
SVENDTC
SVSTDY
SVENDY
SVUPDES

        ↓

SDTM DOMAINS
------------
LB
VS
EG
PE
QS
AE
CM
...

This architecture makes the distinction between planned and observed information explicit.

Advanced Programming: Separating Visit Assignment From Domain Mapping

A strong SDTM programming architecture does not ask each domain programmer to independently determine what visit occurred.

Instead:

The standard visit layer becomes a reusable piece of study metadata.

This reduces:

• Cross-domain discrepancies
• Duplicated derivation logic
• Maintenance burden
• Protocol-amendment risk
• Vendor-integration errors

Example Reusable R Function

assign_visit <- function(data, visit_map) {

  data %>%
    left_join(
      visit_map,
      by = "source_visit"
    ) %>%
    mutate(
      VISITNUM = as.numeric(VISITNUM)
    )
}

lb_sdtm <- assign_visit(
  lb_source,
  visit_map
)

vs_sdtm <- assign_visit(
  vs_source,
  visit_map
)

eg_sdtm <- assign_visit(
  eg_source,
  visit_map
)

The important idea is not the specific R implementation.

The important idea is that the same visit metadata are reused across domains.

Example Reusable SAS Macro Pattern

%macro apply_visit_map(
    source=,
    output=,
    map=,
    key=source_visit
);

    proc sort data=&source out=_src;
        by &key;
    run;

    proc sort data=&map out=_map;
        by &key;
    run;

    data &output;
        merge _src(in=a)
              _map;
        by &key;

        if a;
    run;

%mend;

%apply_visit_map(
    source=lb_source,
    output=lb_sdtm,
    map=visit_map
);

Testing Multiple Visit Scenarios

A visit derivation program should be tested against deliberately difficult cases.

Visit Mapping Unit Tests

For complex studies, visit mapping can be tested like software.

test_that(
  "Week 8 maps correctly",
  {
    expect_equal(
      visit_map$VISITNUM[
        visit_map$source_visit == "W8"
      ],
      4
    )

    expect_equal(
      visit_map$VISITDY[
        visit_map$source_visit == "W8"
      ],
      57
    )
  }
)

Unit tests can be particularly useful when visit metadata change frequently.

Validation Checklist

Practical Visit QC Table

What Makes Multiple-Visit Programming Difficult?

The difficult part is rarely the syntax.

The difficult part is deciding what constitutes a visit.

A robust programmer must understand the difference between:

These concepts are related but are not interchangeable.

The Five-Level Mental Model

Most visit-related SDTM programming errors happen when these levels are collapsed into one.

Recommended Best Practices

1. Build visit metadata centrally. Do not hard-code visit definitions separately in every domain.
2. Separate planned from actual timing. Keep VISITDY distinct from actual study-day variables.
3. Do not equate records with visits. Multiple observations can belong to one encounter.
4. Use source encounter information whenever available. Date-only algorithms can misclassify complex visit histories.
5. Represent genuine unplanned encounters. Do not collapse multiple clinical encounters into one generic unscheduled visit.
6. Preserve actual observation dates. Never replace collected dates with nominal visit dates merely to simplify mapping.
7. Use SV as an important reconciliation layer. It provides a subject-level view of actual visits.
8. Separate SDTM from ADaM windowing. Do not force analysis visit logic into the tabulation dataset.
9. Test difficult edge cases. Include multi-day visits, missed visits, repeat encounters, and unscheduled visits in programming validation.
10. Document study-specific decisions. A visit structure should be understandable to another programmer and to a regulatory reviewer.

Quick Reference: VISIT Variables

Final Example: Putting Everything Together

Suppose the protocol defines:

Visit 1   Screening       Day -14
Visit 2   Baseline        Day 1
Visit 3   Week 4          Day 29
Visit 4   Week 8          Day 57
Visit 5   Week 12         Day 85

Subject 001 has:

Screening:
  Actual Day -12

Baseline:
  Actual Day 1

Week 4:
  Actual Day 31

Unscheduled:
  Actual Day 35
  Reason: rash

Week 8:
  Actual Day 59
  Visit spans Days 59–60

Week 12:
  Missed

The resulting subject-visit history conceptually becomes:

Now consider a Week 8 laboratory result collected on Day 60.

VISITNUM = 4
VISIT    = "Week 8"
VISITDY  = 57
LBDY     = 60
LBDTC    = actual collection date/time

The record communicates all four important concepts:

• Which encounter occurred
• What that encounter was called
• When that encounter was planned
• When the laboratory specimen was actually collected

The Most Important Concept

The central idea behind multiple-visit handling in SDTM is simple:

One visit can produce many SDTM records.

One subject can have many scheduled visits.

A subject can also have unscheduled visits, missed visits, repeated encounters, and multi-day visits.

The programmer's responsibility is to preserve those distinctions while maintaining a consistent standardized representation.

References

CDISC. Study Data Tabulation Model (SDTM) v1.7. Foundational standard documentation, including timing variables, Subject Visits, and Trial Visits.

CDISC. Study Data Tabulation Model Implementation Guide (SDTMIG) v3.4. Study Data Tabulation Model Implementation Guide for Human Clinical Trials, published November 29, 2021.

CDISC. When Did That Happen? A Brief Guide to Representing Timing in SDTM. CDISC Knowledge Base article discussing VISIT, VISITNUM, VISITDY, time points, epochs, and related timing concepts.

CDISC. SDTM Timing Variables for Pre-study Findings. CDISC Knowledge Base article discussing visit variables and actual collection dates for pre-study findings.

U.S. Food and Drug Administration. Study Data Technical Conformance Guide. Current FDA technical-conformance guidance, including recommendations for submission of scheduled and unscheduled subject visits in the SV domain.

CDISC. SDTMIG v4.0 Webinar Materials. 2026 materials describing changes under development/review for SDTMIG v4.0, including changes involving Subject Visits.