Introduction to CDISC Standards

1. Introduction: What Is CDISC?

The Clinical Data Interchange Standards Consortium (CDISC) develops standards that help organizations collect, structure, exchange, analyze, and submit clinical research data in consistent ways.

The easiest way to understand CDISC is to stop thinking of it as a single dataset format. CDISC is a family of interconnected standards covering different parts of the clinical-research data lifecycle.

That distinction matters. A clinical database, an SDTM submission dataset, an ADaM analysis dataset, and a Define-XML metadata file all serve different purposes. CDISC provides standards that help these pieces fit together.

2. Why Do Clinical Trials Need Standards?

Imagine that three sponsors collect the same laboratory measurement. One calls the variable WBC, another calls it WHITE_CELL, and another stores it as a free-text value such as White Blood Cells.

A human may understand that these represent the same clinical concept. A computer cannot safely assume that they do.

Standards create a common language for concepts such as:

• subjects and study identifiers;
• adverse events;
• laboratory results;
• vital signs;
• exposure to study treatment;
• concomitant medications;
• disposition;
• demographics;
• analysis populations; and
• statistical analysis variables.

3. The CDISC Standards Family

CDISC describes its standards as a suite rather than one monolithic standard. The major concepts a new clinical programmer should understand are:

There are also therapeutic-area standards, which extend the foundational standards for disease-specific data, and other standards covering areas such as data exchange, questionnaires, protocol representation, and nonclinical data.

4. The End-to-End CDISC Data Flow

A useful mental model is to follow a single data point from collection to analysis and submission.

Running alongside these layers are controlled terminology and metadata. Define-XML documents the structure and metadata of the submitted datasets, while controlled terminology provides standardized values where applicable.

5. CDASH: Standardizing Data Collection

CDASH stands for Clinical Data Acquisition Standards Harmonization. It focuses on standardizing how clinical data are collected.

Think of CDASH as being close to the case report form (CRF) and electronic data-capture process.

CDASH addresses concepts such as:

• standardized questions and prompts;
• variable names and labels;
• data types;
• expected values;
• mapping targets;
• controlled terminology;
• implementation guidance; and
• relationships between collected data and downstream SDTM representation.

6. Why CDASH Matters to Programmers

A programmer might initially think that CDASH is primarily a data-management concern. In practice, early standardization can reduce downstream ambiguity.

If the data are collected with standardized concepts and clear mappings, the eventual SDTM transformation becomes easier to understand and validate.

CDASH also supports traceability: the relationship between what was collected and what eventually appears in a standardized submission dataset is clearer.

7. SDTM: The Study Data Tabulation Model

SDTM stands for Study Data Tabulation Model. It provides a standard structure for organizing clinical-study observations.

SDTM is often the first CDISC standard that clinical programmers encounter because regulatory submissions commonly contain SDTM datasets.

The central concept is the observation. An SDTM record represents an observation about a subject, event, intervention, finding, or another standardized concept.

8. SDTM Domains

SDTM datasets are commonly organized into domains. A domain generally represents a coherent category of observations.

Therapeutic-area and supplemental structures extend the standardization for more specialized data.

9. SDTM Observation Classes

One of the most important SDTM concepts is the observation class. A beginner can think of the main classes as:

This structure provides a conceptual framework for deciding how an observation should be represented.

10. SDTM Variables: Identifiers, Timing, and Results

SDTM variables have defined roles. Some identify the subject or record; others describe the observation, its timing, or its result.

For example, in a findings domain such as laboratory data, you may encounter concepts corresponding to:

• the subject identifier;
• the test performed;
• the original result;
• the standardized result;
• the unit;
• the reference range; and
• the date/time of the assessment.

11. A Small SDTM Example

Consider three laboratory observations for one subject:

STUDYID  USUBJID  LBTESTCD  LBTEST          LBORRES  LBORRESU  LBDTC
ABC001   ABC-001  HGB       Hemoglobin      13.2     g/dL      2026-01-15
ABC001   ABC-001  WBC       White Blood     6.8      10^9/L    2026-01-15
ABC001   ABC-001  ALT       Alanine Amino.  22       U/L       2026-01-15

The exact variables, labels, controlled terminology, and implementation details depend on the applicable SDTM and implementation-guide requirements. The example is intentionally simplified.

12. SDTM Is Not the Analysis Dataset

This is one of the most important concepts for new programmers.

SDTM is optimized for standardized representation of observations. It is not necessarily optimized for every statistical analysis.

Suppose an efficacy analysis needs:

• baseline value;
• post-baseline value;
• change from baseline;
• treatment indicator;
• analysis population flag;
• analysis visit;
• analysis window;
• parameter;
• criterion flags; and
• other analysis-specific variables.

Those requirements are where ADaM becomes important.

13. ADaM: Analysis Data Model

ADaM stands for Analysis Data Model. ADaM provides standards for analysis datasets and their metadata.

CDISC describes ADaM as supporting clear, consistent, and predictable analysis datasets that can be understood and implemented efficiently.

14. Common ADaM Structures

Not every study needs every structure, and the exact implementation depends on the analysis requirements.

15. ADSL: The Subject-Level Analysis Dataset

ADSL is often the first ADaM dataset a programmer learns.

It typically contains one record per subject and can contain variables needed to define treatment, population membership, demographic characteristics, and other subject-level analysis information.

STUDYID  USUBJID  TRT01P        TRT01PN  SAFFL  ITTFL  AGE  SEX
ABC001   ABC-001  Drug A             1     Y      Y     62   F
ABC001   ABC-002  Placebo            0     Y      Y     58   M
ABC001   ABC-003  Drug A             1     Y      Y     71   M

The exact variable set is study-specific and should be driven by the analysis plan and applicable ADaM guidance.

16. BDS: The Basic Data Structure

BDS is commonly used when multiple records per subject are needed for analysis parameters and visits.

For example, a change-from-baseline analysis of a laboratory endpoint might have records such as:

USUBJID  PARAMCD  PARAM              AVISIT   AVAL  BASE  CHG  PCHG
ABC-001  HGB      Hemoglobin         Baseline 13.2  13.2  0.0   0.0
ABC-001  HGB      Hemoglobin         Week 4   12.7  13.2 -0.5  -3.8
ABC-001  HGB      Hemoglobin         Week 8   13.5  13.2  0.3   2.3

This structure is convenient because the data are organized around an analysis parameter and analysis timing.

17. Change From Baseline in ADaM

Suppose:

and the post-baseline analysis value is:

Then the change from baseline is:

and percentage change is:

The important point is not the arithmetic itself. It is that the analysis dataset explicitly represents the derivations needed to reproduce the statistical analysis.

18. Define-XML: Metadata for the Data

Define-XML is a data-exchange standard used to describe the metadata associated with clinical-trial datasets.

Think of it as the data dictionary plus machine-readable metadata for the submitted datasets.

Metadata can describe items such as:

• dataset names;
• variable names;
• variable labels;
• data types;
• variable roles;
• origins;
• controlled terminology;
• computational methods;
• value-level metadata; and
• relationships among metadata objects.

19. Controlled Terminology

Controlled Terminology (CT) provides standardized values and codelists used with CDISC data.

For example, a variable may need a standardized representation of sex, race, treatment route, assessment result, or another controlled concept.

Controlled terminology is not simply a list of abbreviations. It provides standardized semantic values so that equivalent concepts are represented consistently.

20. Therapeutic-Area Standards

Foundational standards provide the common framework. Therapeutic-area standards extend that framework for disease-specific concepts.

Examples can include oncology, diabetes, cardiovascular disease, respiratory disease, and other therapeutic areas as standards mature.

A therapeutic-area standard can provide disease-specific variables, examples, relationships, and implementation guidance while retaining the common CDISC framework.

21. Data Exchange Standards

CDISC also maintains standards concerned with exchanging and representing information between systems.

For a beginner, the key distinction is:

• Foundational standards establish core models and structures.
• Data exchange standards support structured interchange between systems.
• Therapeutic-area standards extend the framework for specific diseases.
• Controlled terminology standardizes values and semantic meaning.

22. How the Standards Work Together

23. Traceability: One of the Most Important Concepts

Traceability means that an important analysis result can be followed backward through the analysis dataset and standardized clinical data to its source.

For example:

That analysis dataset can then feed:

• summary tables;
• figures;
• listings;
• statistical models;
• time-to-event analyses;
• response analyses; and
• other outputs in the clinical study report.

24. SDTM vs. ADaM: A Practical Comparison

25. An Example: Adverse Events

Suppose a subject experiences headache.

The operational database may contain a site-entered term, dates, severity, seriousness, action taken, and outcome.

In SDTM AE, those observations are represented using standardized variables and conventions.

An analysis dataset such as ADAE may then add analysis-specific concepts such as treatment-emergent flags, analysis periods, or analysis population indicators.

/* Conceptual ADAE-style derivation */
if TRTEMFL = "Y" and SAFFL = "Y" then
    ANL01FL = "Y";

The exact derivation must come from the study's SAP, ADaM specifications, and applicable standards—not from a generic rule invented for every study.

26. An Example: Laboratory Data

Consider a hemoglobin measurement.

27. An Example: Vital Signs

Suppose a subject has systolic blood pressure measured at baseline and Week 4.

USUBJID  VSTESTCD  VSTEST                    VISIT     VSSTRESN  VSSTRESU
ABC-001  SYSBP     Systolic Blood Pressure   BASELINE      132    mmHg
ABC-001  SYSBP     Systolic Blood Pressure   WEEK 4        124    mmHg

An analysis dataset could derive:

and potentially include additional analysis variables such as analysis flags or treatment information.

28. What Is a Dataset Specification?

A dataset specification is the detailed implementation document used by programmers and data teams to construct a dataset.

It may define:

• dataset and variable names;
• labels;
• types;
• lengths;
• origins;
• derivation algorithms;
• controlled terminology;
• source variables;
• join keys;
• sorting rules;
• predecessor datasets; and
• validation expectations.

29. What Is an Annotated CRF?

An annotated case report form (aCRF) connects the clinical data-collection form to the standardized SDTM representation.

It helps reviewers understand where collected data map into the submitted datasets.

For example, an annotated field might indicate that a blood-pressure collection field maps to the appropriate SDTM VS variable.

30. What Is Define.xml?

In regulatory submission discussions, you will often hear “define.xml.” This refers to the XML metadata deliverable created according to the Define-XML standard.

It describes the submitted datasets and variables in machine-readable form and can document computational methods and terminology.

It is therefore not merely a prettier data dictionary. It is a structured metadata artifact intended for machine processing and regulatory review.

31. Why Metadata Matters

Suppose you see this variable:

AVAL = 12.4

What does 12.4 mean?

• Hemoglobin?
• Weight?
• Change from baseline?
• A laboratory value?
• A composite score?

Without metadata, the number has little meaning.

Metadata provides the context needed to understand the variable, including its label, parameter, unit, origin, derivation, and role.

32. Controlled Terminology and Semantic Interoperability

Standards work only if the values themselves have consistent meaning.

Consider two datasets:

Dataset A: SEX = "F"
Dataset B: SEX = "Female"

A human can infer equivalence. A data-processing system needs an explicit, standardized convention.

Controlled terminology provides that common semantic layer.

33. CDISC Terminology Is Not the Same as Every Medical Coding Dictionary

This distinction is important.

Clinical trials may also use terminology systems such as MedDRA, WHO Drug, SNOMED CT, LOINC, or other controlled vocabularies depending on the use case.

CDISC standards can reference or integrate with external terminology systems. CDISC Controlled Terminology itself is the set of standardized expressions used with CDISC-defined data structures.

34. CDISC and Regulatory Submissions

For U.S. submissions, FDA requirements and supported versions should always be checked against the current FDA Data Standards Catalog and current technical-conformance guidance.

CDISC identifies Controlled Terminology, SEND, SDTM, ADaM, and Define-XML among the CDISC standards required or supported for applicable FDA submissions.

35. The FDA Perspective

The FDA's technical-conformance guidance explains how standardized study data should be prepared for submission and review. It also emphasizes that SDTM and SEND alone do not always provide the structure needed to understand all analyses, which is why ADaM analysis datasets are important.

This reinforces a central CDISC principle:

Both are valuable because they answer different questions.

36. What Does a Regulatory Submission Contain?

A submission can contain many study-data artifacts. At a high level, reviewers may encounter:

• SDTM datasets;
• ADaM datasets;
• Define-XML metadata;
• annotated CRF documentation;
• reviewer guides;
• analysis outputs;
• programs and supporting documentation where applicable; and
• other submission components required by the relevant authority.

The precise submission package depends on the regulatory authority, application type, study, and current technical requirements.

37. Common SDTM Domains to Learn First

If you are learning clinical programming, start with a small group of high-frequency domains.

38. The Importance of USUBJID

USUBJID is the unique subject identifier used across many CDISC datasets.

It is one of the most important keys in clinical-trial programming because subject-level data need to be linked across domains.

DM:
USUBJID = ABC-001

AE:
USUBJID = ABC-001

LB:
USUBJID = ABC-001

ADSL:
USUBJID = ABC-001

These repeated identifiers allow data from different domains and analysis datasets to be related.

39. Study-Level and Subject-Level Keys

CDISC datasets use combinations of identifiers depending on the domain and record structure.

Common concepts include:

• STUDYID — study identifier;
• DOMAIN — domain code;
• USUBJID — unique subject identifier;
• domain-specific sequence variables such as AESEQ; and
• timing variables that distinguish repeated observations.

40. Sorting and Keys

Correct sorting is not merely cosmetic.

Dataset order can support review, reproducibility, and downstream processing. Domain-specific implementation guidance should be followed rather than applying a generic sort rule to every dataset.

41. Timing Variables

Clinical observations occur at specific points in time. CDISC provides standardized approaches to representing timing.

Examples include concepts such as:

• study day;
• date/time of collection;
• planned study day;
• visit;
• visit number; and
• relative timing.

Time is especially important for longitudinal analyses, adverse events, exposure, and time-to-event endpoints.

42. ISO 8601 Dates

Clinical datasets frequently use ISO 8601-compatible date and datetime representations.

2026-01-15
2026-01-15T09:30
2026-01-15T09:30:00

Partial dates can occur in clinical data, and the handling of incomplete dates is an important implementation and analysis issue. Never invent missing date components without an explicit, justified rule.

43. Missing Data in CDISC

Missing data require careful treatment.

A blank value is not necessarily equivalent to zero, “none,” “not done,” or “not applicable.”

44. Derived Variables

Many analysis variables are derived rather than directly collected.

Examples include:

• change from baseline;
• percentage change;
• treatment-emergent flags;
• analysis population flags;
• baseline flags;
• analysis visit;
• analysis windows;
• time-to-event variables; and
• response criteria.

Derived variables should have documented algorithms and sufficient metadata to support reproducibility.

45. Example: Baseline Flag

Suppose several observations occur before and after treatment.

The analysis specification may define which observation is baseline. A programmer might then create a baseline flag such as:

if ABLFL = "Y" then BASE = AVAL;

This is only illustrative. The actual baseline selection rule may depend on timing, assessment quality, treatment exposure, visit windows, and the study's analysis plan.

46. Example: Analysis Visit

Operational data may contain dates and nominal visits that do not align perfectly with the planned analysis schedule.

An ADaM dataset may therefore contain an analysis visit variable based on a prespecified windowing algorithm.

if 15 <= ADY <= 43 then AVISIT = "Week 4";
else if 44 <= ADY <= 71 then AVISIT = "Week 8";

47. CDISC Is Not a Statistical Methodology

CDISC standardizes data representation. It does not tell you whether your primary endpoint should be analyzed using a t-test, ANCOVA, Cox model, mixed model, logistic regression, or another method.

The statistical methodology comes from the protocol, SAP, estimand framework, regulatory expectations, and scientific context.

48. CDISC Is Not a Substitute for the SAP

The Statistical Analysis Plan specifies how endpoints and analyses will be performed. CDISC standards specify how data and metadata are structured and represented.

These documents interact but serve different purposes.

49. CDISC and Data Quality

Standards do not automatically make data high quality.

Instead, they make it easier to identify inconsistencies because the expected structure and meaning are explicit.

Validation can then examine:

• required variables;
• permissible values;
• controlled terminology;
• data types;
• relationships;
• timing;
• duplicate records;
• referential consistency; and
• metadata consistency.

50. Standardization vs. Transformation

One of the hardest beginner concepts is understanding that standardization is not the same thing as simply renaming columns.

Suppose the source database has:

PATIENT_ID
LAB_NAME
RESULT
UNIT
DATE_COLLECTED

Creating:

USUBJID
LBTEST
LBORRES
LBORRESU
LBDTC

may be necessary, but it does not by itself establish a compliant SDTM representation.

The programmer must also consider domain structure, variable roles, controlled terminology, timing, identifiers, derivations, origins, and applicable implementation guidance.

51. What Does “Required / Expected / Permissible” Mean?

Implementation guides distinguish variable expectations.

The exact rules depend on the applicable standard and implementation guide.

52. Why You Should Not Invent SDTM Variables

SDTM is a controlled standard. A sponsor should not simply invent a new variable name because it would be convenient.

If the standard does not provide an appropriate variable, the correct approach may involve another standard structure, supplemental representation, or a documented alternative depending on the circumstance.

53. Supplemental Qualifiers

Supplemental structures exist for certain sponsor-defined variables that cannot appropriately be represented in the standard domain variables.

They should not be treated as a universal escape hatch for poor mapping decisions.

54. Study Data Reviewer's Guide

A Study Data Reviewer's Guide (SDRG) provides contextual information to help reviewers understand study data and submission-specific implementation decisions.

It can explain areas such as:

• study-specific conventions;
• data anomalies;
• submission decisions;
• special data handling;
• known limitations; and
• important relationships among submitted artifacts.

55. ADaM Metadata and Traceability

ADaM is not merely a convenient analysis table. Its metadata should communicate how analysis variables are defined and derived.

For example, a derived analysis variable might conceptually be:

The derivation should be sufficiently documented so another programmer or reviewer can understand the calculation.

56. A Practical ADaM Example

data adlb;
  set sdtm_lb;

  if not missing(LBSTRESN) then AVAL = LBSTRESN;

  /* Example only: baseline and change rules must be study-specific. */
  if ABLFL = "Y" then BASE = AVAL;

  if not missing(AVAL) and not missing(BASE) then
    CHG = AVAL - BASE;
run;

This is a programming illustration, not a universal derivation algorithm.

57. R Example: Reading and Checking a CDISC-Style Dataset

library(dplyr)

lb_check <- adlb |>
  select(
    USUBJID,
    PARAMCD,
    AVISIT,
    AVAL,
    BASE,
    CHG
  ) |>
  mutate(
    CHECK_CHG = AVAL - BASE,
    DIFF = CHG - CHECK_CHG
  ) |>
  filter(abs(DIFF) > 1e-10)

This type of independent recalculation is a useful quality-control technique for derived analysis variables.

58. R Example: Checking Subject-Level Uniqueness

adsl |>
  count(USUBJID) |>
  filter(n > 1)

For ADSL, unexpected duplicate subject records may indicate a programming or data-structure problem.

59. R Example: Checking Controlled Values

adsl |>
  count(SEX)

allowed_sex <- c("F", "M", "U", "UNDIFFERENTIATED")

adsl |>
  filter(!SEX %in% allowed_sex)

The exact permissible values should come from the applicable controlled terminology rather than being invented locally.

60. SAS Example: Basic SDTM Domain QC

proc sort data=sdtm.ae out=ae_check;
  by studyid usubjid aeseq;
run;

proc sort data=ae_check nodupkey;
  by studyid usubjid aeseq;
run;

This illustrates one simple structural check. It is not sufficient validation for an AE domain.

61. SAS Example: Derivation QC

data qc;
  set adam.adlb;

  qc_chg = aval - base;

  if not missing(chg) and not missing(qc_chg) then
    diff = chg - qc_chg;

  if abs(diff) > 1e-10;
run;

The QC program should be independently designed where practical, rather than simply duplicating the production algorithm line-for-line.

62. Validation Is More Than Running a Validator

Automated validation tools are valuable, but a successful validation process also requires human review.

A robust approach includes:

• structural checks;
• terminology checks;
• metadata checks;
• cross-dataset checks;
• programming QC;
• clinical review;
• statistical review; and
• review of submission-specific warnings and explanations.

63. Common CDISC Programming Errors

1. Using an old implementation guide without checking applicability.
2. Ignoring controlled terminology versions.
3. Assuming source variable names map one-to-one to SDTM.
4. Creating analysis variables without documenting derivations.
5. Failing to preserve traceability.
6. Using incorrect baseline rules.
7. Mixing nominal and actual timing.
8. Converting missing values to zero.
9. Adding sponsor variables where standard structures exist.
10. Assuming an automated validator proves clinical correctness.

64. Common Conceptual Mistakes

65. CDISC and Clinical Programmers

A clinical programmer may interact with CDISC at nearly every stage of the analysis workflow.

Typical responsibilities can include:

• reviewing source data;
• mapping source data to SDTM;
• programming SDTM domains;
• deriving ADaM datasets;
• creating Define-XML metadata;
• running validation checks;
• creating tables, listings and figures;
• performing independent QC; and
• supporting submission questions.

66. CDISC and Biostatisticians

Biostatisticians do not necessarily need to become SDTM mapping specialists, but they should understand how their analysis requirements affect the data model.

For example, a statistician specifying a baseline analysis should understand:

• what constitutes baseline;
• which population is analyzed;
• which visit is analyzed;
• how missing data are handled;
• how derived endpoints are constructed; and
• how the analysis dataset will support the planned model.

67. CDISC and Data Managers

Data managers are particularly important to the CDASH and source-data side of the process.

Standardized collection can reduce downstream transformation and mapping complexity.

68. CDISC and Statistical Programmers

Statistical programmers often sit at the intersection of source data, SDTM, ADaM, and reporting.

A programmer therefore benefits from understanding not only syntax, but also the semantic purpose of each standard.

69. A Practical Learning Sequence

70. A Worked Mini-Example

Suppose a subject has systolic blood pressure collected at baseline and Week 4.

The standardized clinical observation might be represented in SDTM VS.

The analysis representation could contain:

Then an analysis output might report the mean change from baseline across subjects.

The chain is therefore:

71. The Difference Between Data and Metadata

Data are the observations.

Metadata describe the observations.

Both are necessary for meaningful data exchange.

72. Version Management

CDISC standards are living standards. New versions, implementation guides, terminology packages, corrections, and public-review updates can appear over time.

For that reason, every production study should have a clearly documented standards baseline.

73. Current Standards Change

At the time this tutorial was prepared, CDISC's public standards pages showed active development and public review activity for several foundational standards, while controlled terminology continued to receive scheduled updates.

For example, CDISC reported a March 27, 2026 controlled-terminology update and a Define-XML v2.1.11 update published April 6, 2026. These examples illustrate why production teams should verify the applicable release rather than relying on a static tutorial alone.

74. Regulatory Requirements vs. CDISC Standards

Another subtle distinction is between a CDISC standard and a regulatory requirement to use a particular standard/version.

CDISC develops and maintains standards. Regulatory agencies specify which standards and versions are accepted or required for particular submissions.

Therefore:

The regulatory requirement depends on the agency, submission type, study context, and applicable guidance/catalog.

75. What Should a New Programmer Memorize?

Very little should be memorized mechanically. Instead, learn the conceptual map:

76. Mini Knowledge Check

77. A Practical CDISC Checklist

78. The Three Questions to Ask When You See a CDISC Dataset

When someone hands you a dataset, ask:

1. What is this dataset trying to represent?
2. Who is the intended user?
3. What standard defines its structure and meaning?

Those three questions often prevent major conceptual mistakes.

79. The Most Important Mental Model

Imagine a clinical trial as a long chain:

CDISC standards provide a common language across important parts of that chain.

80. Final Takeaways

If you remember only a few ideas from this tutorial, remember these:

1. CDISC is a family of standards, not a single dataset.
2. CDASH focuses on data acquisition.
3. SDTM focuses on standardized clinical-data tabulation.
4. ADaM focuses on analysis-ready data and traceability.
5. Define-XML describes dataset and variable metadata.
6. Controlled terminology standardizes values and meaning.
7. Therapeutic-area standards extend the framework for disease-specific concepts.
8. Regulatory requirements depend on the applicable authority and submission context.
9. Version control is essential.
10. Traceability is one of the central goals of a well-designed clinical-data environment.

References and Further Reading

Clinical Data Interchange Standards Consortium (CDISC). CDISC Standards.
Clinical Data Interchange Standards Consortium (CDISC). Study Data Tabulation Model (SDTM).
Clinical Data Interchange Standards Consortium (CDISC). Analysis Data Model (ADaM).
Clinical Data Interchange Standards Consortium (CDISC). Clinical Data Acquisition Standards Harmonization (CDASH).
Clinical Data Interchange Standards Consortium (CDISC). Define-XML.
Clinical Data Interchange Standards Consortium (CDISC). Controlled Terminology.
U.S. Food and Drug Administration. Study Data Technical Conformance Guide. June 2026.
U.S. Food and Drug Administration. Data Standards Catalog.