Anatomie d’une soumission eCTD : que contient un dossier de données d’étude clinique

Q: Qu’est-ce que le Module 5 de l’eCTD ?

L’eCTD (electronic Common Technical Document) est le format harmonisé d’une soumission réglementaire, et le Module 5 est la section qui contient les rapports d’étude clinique et les données d’étude. Pour un programmeur de données cliniques, c’est dans le Module 5 que se situe votre travail : le rapport d’étude clinique (CSR) de chaque étude côtoie ses jeux de données SDTM et ADaM, les métadonnées Define-XML, les guides de l’évaluateur cSDRG/ADRG et les programmes d’analyse ADaM. Les Modules 1 à 4 couvrent les informations administratives régionales, les résumés du CTD, la qualité (CMC) et les rapports non cliniques. Voir ICH M4.

Q: Qu’est-ce qu’un ADRG ?

L’ADRG (guide de l’évaluateur des données d’analyse) est un PDF qui accompagne les jeux de données ADaM et donne à l’évaluateur le contexte humain que les jeux de données seuls ne peuvent fournir : comment les jeux de données d’analyse ont été dérivés, les conventions d’analyse employées et toute décision propre à l’étude, ainsi que les métadonnées de résultats d’analyse. Son pendant SDTM, c’est le cSDRG (guide de l’évaluateur SDTM clinique). Tous deux suivent des modèles communautaires publiés par PHUSE et le CDISC — ce sont des livrables de l’industrie, non des formulaires de la FDA.

Q: Qu’est-ce que le format XPT (SAS Transport) ?

Le XPT est le SAS Transport Format (XPORT) version 5, le format d’échange exigé pour les jeux de données d’une soumission réglementaire — un format simple, ouvert et vieux de plusieurs décennies, enregistré par la Library of Congress. Son ancienneté impose des limites strictes : noms de variables ≤ 8 caractères, libellés ≤ 40, valeurs caractères ≤ 200, aucune compression. En R, le package xportr écrit un .xpt conforme et applique ces limites, de sorte qu’un jeu de données que vous exportez fait l’aller-retour vers les variables et libellés exacts spécifiés par les métadonnées.

La carte de ce que contient réellement une soumission réglementaire — les modules eCTD, l’arborescence du Module 5, les jeux de données SDTM et ADaM, le Define-XML et les guides de l’évaluateur qui composent le dossier de données clinique — avant de construire chaque pièce

Vous avez des jeux de données ADaM validés et un ensemble de tableaux, listings et figures. Cette leçon est la carte d’ensemble de ce qui vient ensuite : ce que contient réellement un dossier de données de soumission réglementaire et comment il est organisé. Découvrez les cinq modules eCTD (le Module 5 héberge les données d’étude clinique), l’arborescence du Module 5 pour les jeux de données SDTM et ADaM, les métadonnées Define-XML et les guides de l’évaluateur cSDRG/ADRG, le format d’échange SAS Transport (XPT) v5 dans lequel voyagent vos jeux de données, et la réalité de la soumission d’analyses fondées sur R — le tout ancré dans les pilotes FDA publics du R Consortium. Un exemple exécutable exporte un vrai jeu de données ADaM vers un fichier XPT v5 conforme, le livrable lui-même.

Date de publication

1 juillet 2026

Modifié

7 juillet 2026

Points clés

Une soumission est un dossier hautement structuré, pas un simple répertoire de fichiers. L’eCTD (electronic Common Technical Document) organise en cinq modules tout ce que reçoit une autorité de santé ; les données d’étude clinique se trouvent dans le Module 5.
Le dossier de données, ce sont les jeux de données plus les métadonnées pour les lire. Les jeux de données SDTM et ADaM sont livrés sous forme de fichiers XPT, chacun accompagné d’un fichier de métadonnées Define-XML, d’un guide de l’évaluateur rédigé pour l’humain (cSDRG pour le SDTM, ADRG pour l’ADaM) et — pour l’ADaM — des programmes d’analyse qui reproduisent les résultats.
Les jeux de données circulent au format SAS Transport (XPT) version 5. C’est le format d’échange exigé, assorti de limites strictes : noms de variables ≤ 8 caractères, libellés ≤ 40, valeurs caractères ≤ 200.
Vous pouvez produire un XPT conforme depuis R. Le package xportr écrit un fichier de transport v5 conforme et applique ces limites — cette leçon exporte un vrai jeu de données ADaM et le relit pour le prouver.
Les soumissions fondées sur R sont une réalité démontrée, pas une simple affirmation. Les pilotes publics du R Consortium ont soumis des packages R via la véritable passerelle de la FDA, et l’agence a mené à bien la revue statistique — une preuve de faisabilité, non une caution réglementaire d’un langage quelconque.

Introduction

Vous avez fait le plus dur. Les jeux de données SDTM (Study Data Tabulation Model) sont mappés, les jeux de données ADaM (Analysis Data Model) sont dérivés et double-programmés, et les tableaux, listings et figures — TLF en abrégé — correspondent au plan d’analyse statistique. À présent, le promoteur pose la question à laquelle répond cette série : que reçoit réellement la FDA, et comment est-ce organisé ?

La réponse n’est pas « un répertoire de fichiers .xpt ». Une soumission réglementaire est un dossier strictement structuré, afin que n’importe quel évaluateur, dans n’importe quelle agence, puisse ouvrir n’importe quelle étude et y retrouver les mêmes éléments aux mêmes endroits. Cette structure, c’est l’eCTD — l’electronic Common Technical Document — le format harmonisé défini par ICH M4 (la ligne directrice Common Technical Document de l’International Council for Harmonisation). Il classe une demande d’autorisation de mise sur le marché en cinq modules, et celui que vous construisez en tant que programmeur clinique est le Module 5 : les rapports d’étude clinique et leurs données d’étude.

Cette leçon est la carte que vous lisez avant d’assembler la moindre pièce. Elle couvre les modules eCTD, l’arborescence du Module 5, ce que contient le dossier de données, le format de transport dans lequel voyagent vos jeux de données, et la réalité de la soumission de R. Les leçons pratiques qui suivent construisent chaque partie ; voici d’abord la forme d’ensemble.

A folder-tree schematic of the eCTD Module 5 clinical data package. A dark root box reads m5/datasets/study-id/. It branches to two mid-level folders: tabulations/sdtm/ on the left and analysis/adam/ on the right. Below tabulations/sdtm/ a light box lists the SDTM deliverables: SDTM .xpt files in XPT v5, a define.xml with its define2-0-0.xsl stylesheet, and the cSDRG.pdf reviewer's guide. Below analysis/adam/ a light box for datasets holds the ADaM .xpt files in XPT v5, a define.xml with stylesheet, and the ADRG.pdf reviewer's guide; a second box beneath it, programs, holds the analysis programs as .r and .sas files. The visual point is that each standard, SDTM and ADaM, carries its own datasets plus its own metadata and reviewer's guide.

Chaque boîte de cette arborescence est quelque chose que vous construirez dans cette série. Le reste de cette leçon nomme chacune d’elles — en partant de la structure la plus externe, l’eCTD.

L’eCTD : cinq modules, dont l’un est le vôtre

L’eCTD est le format électronique d’une demande réglementaire. Ce n’est pas une convention de dépôt plaquée par-dessus la science — c’est la façon dont la science est organisée pour la revue, définie par le Common Technical Document (ICH M4) harmonisé afin que la FDA, l’EMA et la PMDA puissent toutes lire la même soumission. Il comporte cinq modules :

Module	Nom	Contenu
1	Informations administratives régionales	Formulaires propres à la région, lettre d’accompagnement et étiquetage. Ne fait pas partie du CTD harmonisé — il varie selon l’agence.
2	Résumés du CTD	L’aperçu clinique et le résumé clinique, ainsi que les résumés non cliniques.
3	Qualité	Chimie, fabrication et contrôles (CMC).
4	Rapports d’études non cliniques	Pharmacologie et toxicologie.
5	Rapports d’étude clinique + données d’étude	Le CSR (rapport d’étude clinique) et les jeux de données SDTM/ADaM, le Define-XML, les guides de l’évaluateur et les programmes d’analyse — le « dossier de données ».

Le Module 1 est régional ; les Modules 2 à 5 forment le CTD harmonisé partagé par toutes les agences. En tant que programmeur de données cliniques, c’est dans le Module 5 que se situe votre travail — précisément sa section « données d’étude », qui accompagne le CSR de chaque étude. Les attentes de la FDA concernant ces données d’étude sont énoncées dans le Study Data Technical Conformance Guide et le hub plus large Study Data Standards Resources, qui nomment les standards CDISC et le format de transport qu’une soumission doit utiliser.

L’arborescence du Module 5

À l’intérieur du Module 5, les données d’étude suivent une arborescence de dossiers conventionnelle, indexée par étude. L’imbrication exacte varie légèrement selon les exemples du guide de la FDA et les conventions des promoteurs — considérez l’arborescence ci-dessous comme la forme représentative (elle est cohérente avec le guide de conformité de la FDA et l’article communautaire PHUSE What You Need to Know About Submitting Data to the FDA (DS02)), non comme une règle universelle unique :

m5/datasets/<study-id>/
├── tabulations/sdtm/        SDTM datasets
│     dm.xpt, ae.xpt, vs.xpt, ...   (XPT v5)
│     define.xml + define2-0-0.xsl  (metadata + stylesheet)
│     csdrg.pdf                     (reviewer's guide for SDTM)
│
└── analysis/adam/
      ├── datasets/          ADaM datasets
      │     adsl.xpt, adae.xpt, adtte.xpt   (XPT v5)
      │     define.xml + define2-0-0.xsl    (metadata + stylesheet)
      │     adrg.pdf                        (reviewer's guide for ADaM)
      │
      └── programs/          analysis programs
            *.r  /  *.sas    (code that reproduces the TLFs)

Deux choses dans cette arborescence prennent les gens au dépourvu. Premièrement, chaque standard porte son propre define.xml — un pour le SDTM sous tabulations/sdtm/, un distinct pour l’ADaM sous analysis/adam/datasets/ — et non un unique fichier de métadonnées partagé. Deuxièmement, les promoteurs ne soumettent généralement pas les programmes de mapping SDTM, mais ils soumettent bien les programmes d’analyse ADaM et TLF sous analysis/adam/programs/, de sorte que les dérivations et les affichages sont reproductibles à partir des jeux de données soumis.

Ce que contient le dossier de données

Chaque dossier contient un petit ensemble figé de livrables. Voici la liste complète du contenu — les pièces que le reste de cette série vous apprend à construire :

Livrable	Format	Emplacement	Rôle
Jeux de données SDTM	XPT v5	`tabulations/sdtm/`	Les données d’essai collectées, standardisées selon le SDTMIG (SDTM Implementation Guide)
Jeux de données ADaM	XPT v5	`analysis/adam/datasets/`	Données prêtes pour l’analyse, dérivées selon l’ADaMIG (ADaM Implementation Guide)
Define-XML (SDTM)	XML + XSL	`tabulations/sdtm/`	Métadonnées lisibles par machine décrivant chaque variable SDTM
Define-XML (ADaM)	XML + XSL	`analysis/adam/datasets/`	Métadonnées ADaM, y compris la traçabilité jusqu’au SDTM
cSDRG	PDF	`tabulations/sdtm/`	Le guide de l’évaluateur SDTM clinique — le contexte humain des données SDTM
ADRG	PDF	`analysis/adam/datasets/`	Le guide de l’évaluateur des données d’analyse — le contexte d’analyse et les métadonnées de résultats
Programmes d’analyse	`.r` / `.sas`	`analysis/adam/programs/`	Le code qui reproduit les dérivations ADaM et les TLF

Quelques définitions, car ces acronymes reviennent tout au long de la série. Le Define-XML est un fichier de métadonnées lisible par machine — le dictionnaire de données de l’évaluateur — qui décrit chaque jeu de données et chaque variable pour qu’un outil puisse valider et parcourir les données ; il est livré avec une feuille de style (define2-0-0.xsl) qui l’affiche sous forme de page lisible. Les deux guides de l’évaluateur sont des documents rédigés pour l’humain : le cSDRG (guide de l’évaluateur SDTM clinique) décrit les jeux de données SDTM, et l’ADRG (guide de l’évaluateur des données d’analyse) décrit les jeux de données ADaM et la façon dont les analyses ont été menées. Tous deux suivent des modèles communautaires publiés par PHUSE et le CDISC — ce sont des livrables de l’industrie, non des formulaires établis par la FDA.

Le format de transport : SAS Transport (XPT) version 5

Vos jeux de données ne voyagent pas en .rds, .parquet ou .sas7bdat. Ils sont livrés en XPT — SAS Transport Format (XPORT) version 5 — le format d’échange exigé, nommé dans le guide de conformité de la FDA et enregistré comme format de préservation dans le registre des formats de la Library of Congress. C’est un format volontairement simple, vieux de plusieurs décennies, et c’est son ancienneté qui explique ses contraintes strictes :

Noms de variables ≤ 8 caractères (c’est pourquoi les noms de variables SDTM et ADaM sont courts — USUBJID, AVAL, TRTP).
Libellés de variables ≤ 40 caractères.
Valeurs caractères ≤ 200 caractères.
Aucune compression et aucun format SAS personnalisé.

Vous ne fabriquez pas un XPT à la main. En R, le package xportr (qui fait partie du pharmaverse) écrit un fichier de transport v5 conforme et applique ces limites au fil de l’eau. Le pipeline ci-dessous prend un vrai jeu de données ADaM au niveau sujet (ADSL, une ligne par sujet) issu de pharmaverseadam, y attache une spécification de métadonnées illustrative (le type d’information que porte un Define-XML — types, longueurs et libellés des variables), l’applique, puis écrit le fichier de transport. Lisez-le de haut en bas : xportr_type(), xportr_length() et xportr_label() fixent le type de stockage, la longueur et le libellé de chaque variable d’après la spécification, et xportr_write() émet le .xpt.

library(xportr)
library(pharmaverseadam)
library(haven)

adsl  <- pharmaverseadam::adsl
vars  <- c("STUDYID", "USUBJID", "SUBJID", "SITEID", "AGE", "SEX", "RACE", "ARM")
small <- adsl[1:15, vars]

# An illustrative metadata spec — the kind of information a real Define-XML carries
# for ADSL (variable types, lengths, and labels). Not an official spec; it shows what
# xportr reads to build a conformant transport file.
meta <- data.frame(
  dataset  = "ADSL",
  variable = vars,
  type     = c("character", "character", "character", "character",
               "numeric", "character", "character", "character"),
  format   = NA_character_,
  length   = c(20, 40, 10, 10, 8, 2, 20, 20),
  label    = c("Study Identifier", "Unique Subject Identifier",
               "Subject Identifier for the Study", "Study Site Identifier",
               "Age", "Sex", "Race", "Description of Planned Arm"),
  order    = 1:8,
  stringsAsFactors = FALSE
)

out <- file.path(tempdir(), "adsl.xpt")
small |>
  xportr_metadata(meta, domain = "ADSL") |>  # attach the spec first (xportr requires it)
  xportr_type()   |>                         # set each variable's storage type
  xportr_length() |>                         # apply the v5 length limits
  xportr_label()  |>                         # attach the <= 40-char labels
  xportr_write(path = out, strict_checks = FALSE)

file.exists(out)      # the transport file was written

[1] TRUE

file.info(out)$size   # its size in bytes

[1] 3840

Le fichier existe et pèse quelques kilo-octets — petit, mais ce .xpt est le livrable, l’objet exact qui atterrit dans analysis/adam/datasets/. Pour confirmer qu’il s’agit d’un vrai fichier de transport v5 lisible et non d’un blob opaque, relisez-le et inspectez-le :

library(haven)

back <- haven::read_xpt(out)

dim(back)                                  # 15 subjects x 8 variables, round-tripped

[1] 15  8

attr(back$STUDYID, "label")                # the label survived the transport

[1] "Study Identifier"

readBin(out, "character", n = 1)           # the v5 transport header signature

[1] "HEADER RECORD*******LIBRARY HEADER RECORD!!!!!!!000000000000000000000000000000  SAS     SAS     SASLIB  6.06    bsd4.2                          01JUL26:21:11:1501JUL26:21:11:15                                                                HEADER RECORD*******MEMBER  HEADER RECORD!!!!!!!000000000000000001600000000140  HEADER RECORD*******DSCRPTR HEADER RECORD!!!!!!!000000000000000000000000000000  SAS     adsl    SASDATA 6.06    bsd4.2                          01JUL26:21:11:1501JUL26:21:11:15                Subject Level Analysis                          HEADER RECORD*******NAMESTR HEADER RECORD!!!!!!!000000000800000000000000000000  "

Le jeu de données fait l’aller-retour vers 15 lignes sur 8 colonnes, le libellé de variable ("Study Identifier") est préservé, et les premiers octets du fichier sont l’en-tête de transport SAS HEADER RECORD*******LIBRARY HEADER RECORD!!!!!!! — la signature qui prouve qu’il s’agit d’un fichier de transport version 5 valide. Une remarque pour les vraies soumissions : nous avons passé strict_checks = FALSE ici pour que la démonstration s’affiche proprement ; une exécution de qualité soumission utilise strict_checks = TRUE, qui transforme les avertissements de longueur et de type de xportr en erreurs bloquantes, de sorte qu’un jeu de données non conforme ne puisse pas passer entre les mailles du filet.

Soumettre du R à un régulateur : ce que les pilotes ont réellement montré

Une question légitime découle de tout cela : une soumission construite en R — et non en SAS — peut-elle être envoyée à la FDA ? La réponse honnête et formulée avec précision est oui, cela a été fait publiquement, et il vaut la peine d’être attentif à ce que cela signifie et ne signifie pas.

Le R Submissions Working Group du R Consortium a mené une série de pilotes publics qui ont soumis des packages fondés sur R à la FDA via la véritable passerelle eCTD :

Pilote 1 a soumis les scripts R qui génèrent un ensemble de TLF ; il a été envoyé fin 2021 et la FDA a mené à bien sa revue statistique en 2022 — le premier exemple public fondé sur R (site du pilote 1, dépôt).
Pilote 2 a soumis une application R Shiny.
Pilote 3 a soumis un package R complet qui génère des jeux de données ADaM et des TLF — bâti exactement sur la chaîne d’outils qu’enseigne ce pilier (admiral, metacore/metatools et xportr). Il est passé par la passerelle eCTD et la FDA a rendu sa réponse en 2024 (synthèse du pilote 3, site du pilote 3).

Voici le cadrage prudent, car il est facile d’en dire trop. Ces pilotes démontrent la faisabilité et offrent à l’industrie un exemple public et fonctionnel d’une soumission entièrement en R que la FDA a examinée. Ils ne signifient pas que R est « approuvé par la FDA » ou « cautionné » — la FDA est agnostique vis-à-vis du logiciel. Elle n’approuve, ne cautionne, ni n’exige aucun langage de programmation particulier ; le promoteur est responsable de ses outils, de leur qualification et de ses résultats. Ce que les pilotes prouvent, c’est qu’un package fondé sur R peut satisfaire aux exigences de soumission — les formats, la structure de dossiers, la reproductibilité — que cette série vous apprend à respecter. Tous les documents des pilotes sont publics, ils font donc aussi office d’implémentation de référence de tout ce qui est cartographié ci-dessus.

Un outil qui mérite d’être connu par son nom ici : pkglite compacte tout un package R (ses scripts et sa structure) en un unique fichier texte brut, soumissible via l’eCTD comme un seul document, puis restaurable — le mécanisme qu’ont utilisé les pilotes pour empaqueter leur code R. Il se situe hors de l’exemple exécutable de cette leçon, mais vous le rencontrerez au moment d’assembler le paquet de soumission ; les dépôts des pilotes ci-dessus le montrent à l’œuvre.

La suite de cette série

Vous disposez à présent de la carte. Les leçons pratiques qui suivent construisent chaque boîte de l’arborescence en haut de cette page : exporter les jeux de données en XPT v5 conforme avec xportr, générer les métadonnées Define-XML, rédiger les guides de l’évaluateur cSDRG et ADRG, et empaqueter les programmes R pour l’eCTD avec pkglite — en assemblant, pièce par pièce, le dossier qu’ont soumis les pilotes du R Consortium. Chacune d’elles s’insère dans l’arborescence du Module 5 que vous venez de lire.

🟢 Avec un agent IA

Demandez à Prova « j’ai des jeux de données ADaM et des TLF validés — expliquez-moi précisément ce qui entre dans le dossier de soumission du Module 5 et où va chaque fichier. » — elle répond en s’appuyant sur les leçons de ce pilier, avec du code pharmaverse exécutable que vous pouvez essayer sur des données d’exemple. The runtime is the judge. Demandez à Prova →

Problèmes fréquents

Votre jeu de données dépasse les limites de longueur de XPT v5. SAS Transport v5 plafonne les noms de variables à 8 caractères, les libellés à 40 et les valeurs caractères à 200. Un nom de variable dérivée trop long (TREATMENT_GROUP), un libellé verbeux ou un champ en texte libre de plus de 200 caractères échoueront à la conformité. C’est pourquoi les noms de variables CDISC sont concis — concevez-les à la limite dès le départ. xportr signale ces violations, et l’exécution de xportr_write(..., strict_checks = TRUE) les transforme en erreurs bloquantes, de sorte qu’un jeu de données non conforme ne puisse pas être écrit par accident.

Vous livrez un seul define.xml pour toute la soumission. Chaque standard a besoin de son propre Define-XML : un pour le SDTM dans tabulations/sdtm/, un distinct pour l’ADaM dans analysis/adam/datasets/. Un unique fichier de métadonnées partagé — ou un define ADaM qui omet la traçabilité jusqu’au SDTM — est un constat de conformité fréquent. Construisez et validez les deux fichiers define indépendamment, chacun contre ses jeux de données respectifs.

Vous soumettez les mauvais programmes, ou aucun. Les promoteurs ne soumettent généralement pas les programmes de mapping SDTM, mais ils soumettent bien les programmes d’analyse ADaM et TLF (analysis/adam/programs/) pour que les dérivations et les affichages soient reproductibles. Omettre les programmes d’analyse, ou inclure du code de mapping SDTM qui n’a pas été demandé, manque dans les deux cas l’attendu — l’objectif est qu’un évaluateur puisse reproduire chaque résultat d’analyse soumis à partir des données ADaM soumises.

Questions fréquentes

Qu’est-ce que le Module 5 de l’eCTD ?

L’eCTD (electronic Common Technical Document) est le format harmonisé d’une soumission réglementaire, et le Module 5 est la section qui contient les rapports d’étude clinique et les données d’étude. Pour un programmeur de données cliniques, c’est dans le Module 5 que se situe votre travail : le rapport d’étude clinique (CSR) de chaque étude côtoie ses jeux de données SDTM et ADaM, les métadonnées Define-XML, les guides de l’évaluateur cSDRG/ADRG et les programmes d’analyse ADaM. Les Modules 1 à 4 couvrent les informations administratives régionales, les résumés du CTD, la qualité (CMC) et les rapports non cliniques. Voir ICH M4.

Que contient un dossier de données de soumission clinique ?

Le dossier de données du Module 5 contient, par étude : les jeux de données SDTM (données collectées, standardisées) et les jeux de données ADaM (données prêtes pour l’analyse), chacun sous forme de fichiers XPT v5 ; un fichier de métadonnées Define-XML pour chaque standard, avec sa feuille de style de rendu ; un cSDRG (guide de l’évaluateur SDTM clinique) et un ADRG (guide de l’évaluateur des données d’analyse) au format PDF ; et les programmes d’analyse (.r/.sas) qui reproduisent les tableaux, listings et figures. Le Study Data Technical Conformance Guide de la FDA précise les standards et formats qu’il doit utiliser.

Peut-on soumettre du R à la FDA ?

Oui — cela a été fait publiquement. Le R Submissions Working Group du R Consortium a soumis des packages fondés sur R via la véritable passerelle eCTD de la FDA, et la FDA a mené à bien la revue statistique (Pilote 1 ; Pilote 3 a soumis des jeux de données ADaM et des TLF générés avec admiral et xportr). Soyez précis sur ce que cela signifie : les pilotes démontrent la faisabilité, non que R serait « approuvé par la FDA ». La FDA est agnostique vis-à-vis du logiciel — elle n’approuve ni n’exige aucun langage ; le promoteur est responsable de ses outils, de leur qualification et de ses résultats. R peut satisfaire aux exigences de soumission, et les pilotes en sont un exemple concret et public.

Qu’est-ce qu’un ADRG ?

L’ADRG (guide de l’évaluateur des données d’analyse) est un PDF qui accompagne les jeux de données ADaM et donne à l’évaluateur le contexte humain que les jeux de données seuls ne peuvent fournir : comment les jeux de données d’analyse ont été dérivés, les conventions d’analyse employées et toute décision propre à l’étude, ainsi que les métadonnées de résultats d’analyse. Son pendant SDTM, c’est le cSDRG (guide de l’évaluateur SDTM clinique). Tous deux suivent des modèles communautaires publiés par PHUSE et le CDISC — ce sont des livrables de l’industrie, non des formulaires de la FDA.

Qu’est-ce que le format XPT (SAS Transport) ?

Le XPT est le SAS Transport Format (XPORT) version 5, le format d’échange exigé pour les jeux de données d’une soumission réglementaire — un format simple, ouvert et vieux de plusieurs décennies, enregistré par la Library of Congress. Son ancienneté impose des limites strictes : noms de variables ≤ 8 caractères, libellés ≤ 40, valeurs caractères ≤ 200, aucune compression. En R, le package xportr écrit un .xpt conforme et applique ces limites, de sorte qu’un jeu de données que vous exportez fait l’aller-retour vers les variables et libellés exacts spécifiés par les métadonnées.

Testez vos connaissances

À votre tour : placer les livrables dans le dossier

Vous avez terminé une étude et disposez de six éléments prêts à soumettre : (1) adsl.xpt, (2) le Define-XML SDTM, (3) l’ADRG, (4) ae.xpt (le jeu de données SDTM des événements indésirables), (5) le programme d’analyse qui produit les TLF d’efficacité, et (6) le cSDRG. À l’aide de l’arborescence du Module 5 de cette leçon, nommez le dossier auquel chacun appartient, et indiquez dans quel module eCTD se situe l’ensemble du dossier.

Indice

Il y a deux branches sous m5/datasets/<study-id>/ : tabulations/sdtm/ pour le standard SDTM et analysis/adam/ pour le standard ADaM (avec datasets/ et programs/ en dessous). Chaque standard conserve ses propres jeux de données, son propre Define-XML et son propre guide de l’évaluateur. Demandez-vous, pour chaque élément : est-ce du SDTM ou de l’ADaM, et est-ce un jeu de données, des métadonnées, un guide de l’évaluateur ou un programme ?

Solution

L’ensemble du dossier se situe dans le Module 5 de l’eCTD (rapports d’étude clinique et données d’étude). Au sein de m5/datasets/<study-id>/ :

ae.xpt (SDTM) ainsi que le Define-XML SDTM et le cSDRG → tabulations/sdtm/. Les trois appartiennent au standard SDTM : son jeu de données, ses métadonnées, son guide de l’évaluateur.
adsl.xpt (ADaM) ainsi que l’ADRG → analysis/adam/datasets/. Le jeu de données ADaM et son guide de l’évaluateur vivent ensemble (le Define-XML ADaM les y rejoindrait également).
Le programme d’analyse du TLF d’efficacité → analysis/adam/programs/. Les programmes d’analyse sont soumis pour qu’un évaluateur puisse reproduire les résultats à partir des données ADaM.

Le schéma à retenir : chaque standard — SDTM et ADaM — porte ses propres jeux de données plus ses propres métadonnées plus son propre guide de l’évaluateur, et les programmes d’analyse se placent à côté des données ADaM qu’ils produisent.

Vérification rapide : combien de fichiers Define-XML une soumission contenant à la fois du SDTM et de l’ADaM comporte-t-elle ?

A. Un seul define.xml partagé pour toute la soumission B. Deux — un pour le SDTM et un distinct pour l’ADaM C. Un par jeu de données (un define.xml pour dm.xpt, un autre pour ae.xpt, et ainsi de suite)

Afficher la réponse

B. Chaque standard porte son propre Define-XML : un sous tabulations/sdtm/ décrivant tous les jeux de données SDTM, et un distinct sous analysis/adam/datasets/ décrivant les jeux de données ADaM (y compris leur traçabilité jusqu’au SDTM). A est l’erreur fréquente — un unique fichier partagé est un constat de conformité. C est faux, car un Define-XML décrit tous les jeux de données de son standard, non un fichier par jeu de données.

Conclusion

Une soumission réglementaire est un dossier structuré, et le programmeur de données cliniques en détient une partie bien définie. L’eCTD classe la demande en cinq modules ; le Module 5 contient les données d’étude clinique ; et à l’intérieur, chaque standard — SDTM et ADaM — voyage sous forme de jeux de données XPT v5 aux côtés de ses propres métadonnées Define-XML et de son propre guide de l’évaluateur (cSDRG pour le SDTM, ADRG pour l’ADaM), avec les programmes d’analyse ADaM pour que les résultats se reproduisent. R peut produire chacun de ces livrables — l’exemple xportr ci-dessus a écrit un fichier de transport conforme, et les pilotes publics du R Consortium ont montré une soumission entièrement en R franchir la revue de la FDA. Retenez cette carte, et chaque leçon pratique qui suit est une boîte de l’arborescence : export, métadonnées, guides de l’évaluateur et paquet.

Note

Cette leçon est reproductible : chaque résultat de cette page a été produit par le code montré — copiez n’importe quel bloc et exécutez-le pour les reproduire. The runtime is the judge.

Références

ICH M4: The Common Technical Document — la structure harmonisée du CTD qu’implémente l’eCTD, y compris les cinq modules.
FDA Study Data Technical Conformance Guide et le hub Study Data Standards Resources — les attentes de la FDA sur les données d’étude soumises, les standards CDISC et le format de transport.
Solanki & Low, What You Need to Know About Submitting Data to the FDA (Paper DS02), PHUSE US Connect 2020 — une référence communautaire pour l’arborescence des données d’étude du Module 5.
SAS Transport Format (XPORT) V5 — Library of Congress format registry — le format d’échange XPT v5 et ses contraintes.
xportr (CRAN) — le package pharmaverse qui écrit des fichiers de transport XPT v5 conformes depuis R.
PHUSE — l’organisation communautaire qui publie les modèles de guide de l’évaluateur cSDRG et ADRG.
R Consortium R Submissions Working Group : groupe de travail · Pilote 1 (scripts TLF à la FDA) · Pilote 3 (package ADaM + TLF) — des soumissions publiques et évaluées fondées sur R, démontrant la faisabilité.

Leçons connexes

Le modèle de tabulation SDTM — la structure des jeux de données SDTM qui remplissent tabulations/sdtm/. · Créer l’ADSL en R avec admiral — construire le jeu de données d’analyse que cette leçon exporte en XPT. · Qualification de package R avec riskmetric — qualifier les packages (xportr, admiral) qui produisent le dossier. · Le flux de données de l’essai clinique — où se situe la soumission dans le pipeline plus large du développement du médicament.
Où cela s’inscrit : mapper les données SDTM et ADaM → les valider → assembler le dossier de soumission (vous êtes ici) → exporter en XPT, générer le Define-XML, rédiger les guides de l’évaluateur et empaqueter les programmes R dans les leçons qui suivent. · Assemblage du dossier de soumission — la série complète. · Pharma & Clinique — le pilier.

Cette page vous a-t-elle été utile ?

Réutilisation

CC BY-NC-SA 4.0

Citation

BibTeX

@online{2026,
  author = {},
  title = {Anatomie d’une soumission eCTD : que contient un dossier de
    données d’étude clinique},
  date = {2026-07-01},
  url = {https://www.datanovia.com/learn/pharma-clinical/07-submission-packaging/ectd-submission-anatomy},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“Anatomie d’une soumission eCTD : que contient un dossier de données d’étude clinique.” 2026. July 1. https://www.datanovia.com/learn/pharma-clinical/07-submission-packaging/ectd-submission-anatomy.