Standards CDISC : CDASH, SDTM, ADaM et Define-XML
Ce qu’est chaque standard CDISC, le problème qu’il résout, qui le maintient, et comment les pièces s’articulent de la collecte des données à une soumission traçable
La carte d’orientation des standards CDISC. Découvrez ce qu’est chaque standard fondamental et comment ils s’emboîtent : CDASH pour la collecte, SDTM pour la tabulation, ADaM pour l’analyse, Define-XML pour les métadonnées et la traçabilité qui les enveloppent, plus Controlled Terminology (le vocabulaire partagé maintenu par NCI/EVS) et les guides de l’évaluateur cSDRG/ADRG. Inclut la distinction standard/implémentation et la place de l’Implementation Guide (IG).
- CDISC (le Clinical Data Interchange Standards Consortium) est l’organisation de normalisation ; ses standards fondamentaux sont les règles qui donnent à chaque essai la même forme de données — CDASH (collecte), SDTM (tabulation), ADaM (analyse), avec Controlled Terminology comme vocabulaire partagé et Define-XML comme métadonnées qui relient le tout.
- Ils forment une chaîne : CDASH normalise la collecte → SDTM tabule les données collectées en domaines → ADaM dérive les jeux de données prêts pour l’analyse → Define-XML décrit les jeux de données SDTM et ADaM pour qu’un évaluateur puisse remonter chaque valeur jusqu’à sa source.
- Un standard n’est pas votre jeu de données. Chaque standard comprend un modèle plus un Implementation Guide (IG) — les règles et les gabarits. Les jeux de données réels de votre étude sont l’implémentation ; c’est leur conformité à l’IG qui les rend conformes à CDISC.
- Controlled Terminology (listes de codes et valeurs autorisées) est maintenu par la CDISC Terminology Team avec NCI/EVS et publié trimestriellement — il fournit les valeurs codées normalisées qu’exigent SDTM et ADaM.
- Les guides de l’évaluateur — cSDRG (pour SDTM) et ADRG (pour ADaM) — sont des compagnons lisibles par l’humain, construits sur des modèles PHUSE, qui accompagnent les jeux de données, et non des standards CDISC eux-mêmes.
Introduction
Un évaluateur de la FDA ouvre votre soumission et y trouve un dossier de jeux de données, un define.xml, et un bref guide PDF. Il navigue dans l’ensemble — quel jeu de données contient les événements indésirables, ce que signifie chaque variable, comment une valeur dérivée a été calculée — sans jamais vous appeler. Il le peut parce que chaque élément suit une structure qu’il a déjà vue des centaines de fois.
Cette structure partagée, c’est CDISC. La leçon sur le flux de données des essais cliniques a suivi un point de données à travers le flux en cinq étapes (CRF → SDTM → ADaM → TLF → soumission) ; le contexte réglementaire a expliqué pourquoi les régulateurs rendent CDISC obligatoire ; le cadre des estimandes a couvert la façon dont la question clinique est définie. Cette leçon porte sur les standards eux-mêmes — ce que chacun est, le problème qu’il résout, qui le maintient, et comment ils s’articulent. C’est la carte d’orientation pour les séries pratiques SDTM et ADaM qui suivent.
Pas de code, pas de configuration — c’est une carte conceptuelle. Un diagramme de relations et deux tableaux de référence suffisent pour aborder les séries pratiques qui suivent.
Un standard n’est pas votre jeu de données
La distinction la plus utile d’emblée : un standard CDISC est un ensemble de règles, pas un fichier. Chaque standard fondamental est publié sous la forme de deux éléments qui fonctionnent ensemble :
- Un modèle — la structure abstraite (quelles classes de données existent, ce qu’est une variable, les règles fondamentales).
- Un Implementation Guide (IG) — les instructions concrètes : les domaines spécifiques, les variables, les règles métier et les exemples concrets auxquels vous vous conformez réellement. SDTM possède le SDTMIG, ADaM possède l’ ADaMIG, CDASH possède le CDASHIG. Ces standards fondamentaux sont répertoriés sur la page des standards fondamentaux de CDISC.
Il existe une relation un à un entre une version d’un modèle et une version de son IG, et chaque IG nomme la version du modèle pour laquelle il a été rédigé. Ainsi, lorsqu’on dit « nous sommes sur SDTMIG v3.4 », on nomme le cahier de règles que suivent les jeux de données.
Les dm.xpt, adsl.xpt réels de votre étude, et tout le reste, sont l’implémentation — les jeux de données construits selon ces règles. « CDISC-conformant » signifie que votre implémentation suit l’IG. Garder les deux distincts évite une confusion fréquente chez les débutants : SDTM n’est pas un fichier que vous possédez, c’est un standard auquel votre fichier se conforme.
Les standards, un par un
CDASH — le standard de collecte
CDASH (Clinical Data Acquisition Standards Harmonization) normalise la manière dont les données sont collectées sur le cahier d’observation. Il définit des standards de base pour l’organisation, le nommage et la description des variables que vous recueillez, afin que la collecte soit identique d’une étude et d’un promoteur à l’autre.
Il se compose du CDASH Model, du CDASHIG et d’une table de métadonnées. Point crucial, le CDASH Model est structuré pour s’aligner sur SDTM : il fournit des conventions de nommage et des métadonnées qui font correspondre proprement les champs collectés à leurs variables SDTMIG. C’est tout l’intérêt de cet alignement — collecter selon CDASH offre une traçabilité claire des données collectées vers SDTM, sans approximation à l’étape de mapping. Les CRF sont conçus selon CDASH par l’équipe de gestion des données.
SDTM — le standard de tabulation
SDTM (Study Data Tabulation Model) restructure les données collectées en une structure fixe, attendue par les régulateurs. Il organise les données en domaines — des tables normalisées identifiées par un code à deux lettres (DM données démographiques, AE événements indésirables, VS signes vitaux, LB analyses de laboratoire, EX exposition, et bien d’autres). Le SDTMIG fournit les modèles de domaines spécifiques, les hypothèses, les règles métier et les exemples auxquels vous vous conformez.
SDTM, c’est de la tabulation : un enregistrement fidèle et normalisé de ce qui a été observé, généralement une ligne par observation. Il n’est délibérément pas conçu pour les statistiques — son rôle est de rendre les données de n’importe quelle étude repérables au même endroit à chaque fois. C’est l’un des deux ensembles de jeux de données qu’un promoteur soumet, et il est généralement produit par des programmeurs cliniques ou statistiques.
ADaM — le standard d’analyse
ADaM (Analysis Data Model) prend les données SDTM normalisées et les transforme en jeux de données prêts pour l’analyse. CDISC définit ADaM comme le standard qui permet « la génération, la réplication et la revue efficaces des analyses statistiques des essais cliniques » et « la traçabilité entre les résultats d’analyse, les données d’analyse et les données représentées dans le Study Data Tabulation Model (SDTM) ». ADaM est construit avec SDTM comme source et Define-XML pour ses métadonnées — il s’inscrit pleinement dans le flux de bout en bout de CDISC.
Là où SDTM tabule, ADaM dérive : variables de traitement, indicateurs de population, valeur initiale, variation par rapport à la valeur initiale, fenêtres de visite. Il définit un petit ensemble de structures de jeux de données — ADSL (une ligne par sujet, l’ossature au niveau du sujet), BDS (Basic Data Structure, pour les mesures dans le temps) et OCCDS (Occurrence Data Structure, pour les événements tels que les événements indésirables). Le ADaMIG en détaille les règles. La traçabilité est la propriété déterminante d’ADaM — chaque valeur d’analyse doit pouvoir remonter jusqu’à sa source SDTM — et c’est la raison pour laquelle ADaM existe comme une étape distincte au lieu d’analyser SDTM directement. Vous exécutez les statistiques sur ADaM, pas sur SDTM.
Controlled Terminology — le vocabulaire partagé
Une structure normalisée n’est que la moitié du combat ; les valeurs doivent l’être aussi. CDISC Controlled Terminology est l’ensemble des listes de codes et valeurs autorisées utilisées avec les éléments de données dans les jeux de données définis par CDISC — le vocabulaire convenu pour des éléments comme le sexe, les unités, la sévérité et les codes d’analyses de laboratoire. C’est ce qui fait que « cet AE était sévère » désigne la même chose codée dans chaque étude.
Il est maintenu par la CDISC Terminology Team en collaboration avec les Enterprise Vocabulary Services (NCI/EVS) du National Cancer Institute, prend en charge tous les standards fondamentaux (SDTM, CDASH, ADaM, et SEND — le Standard for Exchange of Nonclinical Data), et est publié trimestriellement. Comme il fournit les valeurs qu’exigent la FDA et la PMDA (l’agence japonaise des produits pharmaceutiques et des dispositifs médicaux) dans les jeux de données conformes, utiliser la version actuellement applicable de la terminologie fait partie de la conformité — et non un détail accessoire.
Define-XML — les métadonnées qui relient le tout
Define-XML est un standard d’échange de données qui transmet des métadonnées décrivant la structure de vos jeux de données — variables, listes de codes, métadonnées au niveau des valeurs, et la manière dont chaque valeur dérivée a été calculée. Il fournit ces métadonnées pour les jeux de données de tabulation SDTM (et SEND) et les jeux de données d’analyse ADaM.
Define-XML est l’épine dorsale de la traçabilité, lisible par la machine : c’est par lui qu’un évaluateur remonte d’ un résultat figurant dans un tableau vers le jeu de données, la variable et la dérivation qui le sous-tend — sans ouvrir votre code. Il est exigé à la fois par la FDA et par les autorités réglementaires japonaises pour les jeux de données d’une soumission électronique, ce qui explique pourquoi « le define.xml » est mentionné dans le même souffle que les jeux de données qu’il décrit. (La même idée de relier les métadonnées, poussée jusqu’à l’automatisation complète tout au long du cycle de vie de l’étude, est l’objectif de l’initiative CDISC 360i — une automatisation pilotée par les standards et les métadonnées, de la conception jusqu’à la soumission.)
Les guides de l’évaluateur : cSDRG et ADRG
Un define.xml est lisible par la machine ; les évaluateurs reçoivent aussi un compagnon lisible par l’humain qui relate le contexte qu’un fichier de métadonnées ne peut pas restituer. Deux d’entre eux accompagnent les données :
- Le cSDRG (Clinical Study Data Reviewer’s Guide) — pour le package SDTM.
- L’ADRG (Analysis Data Reviewer’s Guide) — pour le package ADaM.
Chacun explique les décisions spécifiques à l’étude, les constats de conformité et tout ce dont un évaluateur a besoin pour lire les données correctement. Ce sont des livrables communautaires construits sur des modèles PHUSE, et non des standards CDISC eux-mêmes — une distinction qu’il vaut la peine de garder à l’esprit. Le modèle cSDRG a été examiné par la FDA et publié au Federal Register ; la FDA préfère son utilisation mais n’exige pas strictement le modèle, et un ADRG est recommandé dans le cadre d’une soumission d’analyse conforme aux standards.
Les standards CDISC en un coup d’œil
Un tableau de référence pour toute la famille — ce qu’il est, où il agit, et qui le maintient :
| Standard | Ce que c’est | Étape | Maintenu / produit par |
|---|---|---|---|
| CDASH | Règles de collecte des données sur le CRF, alignées sur SDTM | Collecte | CDISC |
| SDTM | Modèle de tabulation des données collectées en domaines fixes | Tabulation | CDISC |
| Controlled Terminology | Listes de codes et valeurs autorisées (le vocabulaire partagé) | SDTM et ADaM | CDISC Terminology Team + NCI/EVS |
| ADaM | Modèle de jeux de données dérivés, traçables et prêts pour l’analyse | Analyse | CDISC |
| Define-XML | Métadonnées lisibles par la machine décrivant les jeux de données | Enveloppe SDTM et ADaM | CDISC (standard d’échange de données) |
| cSDRG / ADRG | Guides de l’évaluateur lisibles par l’humain pour SDTM / ADaM | Soumission | Modèles PHUSE (rédigés par le promoteur) |
Les quatre premiers standards sont accessibles sous forme lisible par la machine via la CDISC Library, la source de métadonnées faisant autorité que lisent les outils pharmaverse.
La chaîne en une seule vue
Les relations ci-dessus s’énoncent facilement sous forme d’un petit tableau. Voici la chaîne comme une suite de liens entrée → sortie :
| Étape | Standard | Phase | Prend en entrée | Produit |
|---|---|---|---|---|
| 1 | CDASH | Collecte | CRF / conception de l’étude | collecte de données normalisée |
| 2 | SDTM | Tabulation | données CRF collectées | domaines de tabulation (DM, AE, VS, …) |
| 3 | ADaM | Analyse | domaines SDTM | jeux de données prêts pour l’analyse (ADSL, ADAE, …) |
| 4 | Define-XML | Métadonnées | jeux de données SDTM + ADaM | métadonnées de jeux de données lisibles par la machine |
Parcourez les colonnes Prend en entrée et Produit et le pipeline devient explicite : la sortie de chaque standard est l’entrée du suivant, et Define-XML prend les jeux de données SDTM et ADaM en entrée pour produire les métadonnées qui les décrivent. Controlled Terminology n’est pas une étape de cette chaîne — c’est le vocabulaire qui alimente les valeurs à l’intérieur des sorties SDTM et ADaM, ce qui explique pourquoi il figure sur des flèches en pointillés dans le diagramme plutôt que dans ce tableau ordonné.
Où cela s’inscrit
Ces leçons de fondations vous donnent le cadre ; le reste du pilier s’appuie dessus. Chaque standard fondamental nommé ici devient une série pratique — la programmation SDTM (construire les domaines DM, AE, VS, EX et appliquer Controlled Terminology), ADaM avec admiral (ADSL, puis les jeux de données BDS et OCCDS), et le travail de mise en package pour la soumission qui produit Define-XML et les guides de l’évaluateur. La prochaine leçon de cette série clôt les fondations avec le passage de SAS à R du secteur — pourquoi un pipeline R open-source est désormais une manière de premier ordre d’implémenter chaque standard que vous venez de découvrir. Là où une série pratique existe, le hub du pilier y renvoie.
Demandez à Prova « quelle est la différence entre SDTM et ADaM, et où se situe Define-XML ? » — elle répond en s’appuyant sur les leçons de ce pilier, avec du code R exécutable que vous pouvez essayer sur des données pharmaverse d’exemple. The runtime is the judge. Demandez à Prova →
Problèmes fréquents
Voici les glissements conceptuels qui font trébucher ceux qui découvrent les standards CDISC.
Traiter SDTM ou ADaM comme un fichier plutôt que comme un standard. « SDTM » est un modèle plus son IG — les règles. Votre dm.xpt est une implémentation de ces règles. Quand vous dites qu’un jeu de données « est SDTM », vous voulez dire qu’il se conforme au SDTMIG. Il en va de même pour ADaM. Confondre le cahier de règles et le fichier est la racine de la plupart des confusions initiales.
Confondre CDASH et SDTM. Les deux ont une forme de domaine et se ressemblent, mais ils agissent à des étapes différentes : CDASH normalise la collecte (le CRF), SDTM normalise la tabulation (le jeu de données de soumission). CDASH est conçu pour se mapper proprement vers SDTM — c’est tout l’objet de cet alignement — mais ce ne sont pas le même standard, et vous collectez selon l’un et soumettez l’autre.
Croire que les guides de l’évaluateur sont des standards CDISC. Le cSDRG et l’ADRG sont des documents construits sur des modèles PHUSE qui accompagnent les jeux de données ; ils ne font pas partie des standards fondamentaux CDISC. Ils relatent un contexte spécifique à l’étude qu’un define.xml ne peut pas restituer. Considérez-les comme des compagnons de soumission requis, et non comme un standard CDISC auquel vous « vous conformez ».
Questions fréquentes
CDISC signifie Clinical Data Interchange Standards Consortium. Ses standards fondamentaux sont CDASH (collecte des données), SDTM (tabulation) et ADaM (analyse), complétés par Controlled Terminology (le vocabulaire partagé) et Define-XML (les métadonnées des jeux de données). Ensemble, ils font en sorte que les données de chaque essai suivent la même structure pour que les régulateurs puissent examiner les soumissions de manière cohérente.
SDTM normalise les données collectées en domaines fixes pour la tabulation — un enregistrement fidèle de ce qui a été observé, généralement une ligne par observation. ADaM dérive de SDTM des jeux de données prêts pour l’analyse — avec des variables dérivées (indicateurs, valeur initiale, variation par rapport à la valeur initiale) et une traçabilité complète jusqu’à SDTM. Vous construisez SDTM pour organiser les données et ADaM pour les analyser ; vous exécutez les statistiques sur ADaM, pas sur SDTM.
Un standard est le cahier de règles — un modèle plus son Implementation Guide (IG) (le SDTMIG, l’ ADaMIG, le CDASHIG). Une implémentation, ce sont les jeux de données réels de votre étude, construits selon ces règles. « CDISC-conformant » signifie que l’implémentation suit l’IG. Il existe une relation un à un entre une version de modèle et sa version d’IG.
Controlled Terminology est l’ensemble des listes de codes et valeurs autorisées utilisées avec les éléments de données dans les jeux de données CDISC — le vocabulaire codé convenu (sexe, unités, sévérité, codes d’analyses de laboratoire, et plus encore). Il est maintenu par la CDISC Terminology Team en collaboration avec NCI/EVS (les Enterprise Vocabulary Services du National Cancer Institute) et publié trimestriellement, et il fournit les valeurs qu’exigent la FDA et la PMDA dans les jeux de données conformes.
Define-XML est un standard de métadonnées lisible par la machine qui décrit la structure de vos jeux de données SDTM et ADaM — variables, listes de codes, métadonnées au niveau des valeurs, et la manière dont les valeurs dérivées ont été calculées. C’est l’épine dorsale de la traçabilité : un évaluateur l’utilise pour remonter d’un résultat jusqu’à sa source sans ouvrir votre code. Il est exigé par la FDA et la PMDA pour chaque étude de chaque soumission électronique.
Ce sont les guides de l’évaluateur qui accompagnent les jeux de données : le cSDRG (Clinical Study Data Reviewer’s Guide) pour le package SDTM et l’ADRG (Analysis Data Reviewer’s Guide) pour le package ADaM. Ce sont des compagnons lisibles par l’humain du define.xml, qui relatent les décisions spécifiques à l’étude et les constats de conformité. Ils s’appuient sur des modèles PHUSE et ne sont pas des standards CDISC eux-mêmes.
Testez vos connaissances
Pour chaque description ci-dessous, nommez le standard CDISC (ou document) auquel elle se rapporte :
- « Les règles selon lesquelles une variable est nommée et collectée sur le cahier d’observation, alignées pour que les données se mappent proprement vers les jeux de données de tabulation. »
- « Le modèle qui organise les données observées en domaines à deux lettres comme DM, AE et VS — un enregistrement fidèle, généralement à une ligne par observation, de ce qui s’est passé. »
- « Les listes de codes et valeurs autorisées, maintenues avec NCI/EVS et publiées trimestriellement, qui fournissent les valeurs codées normalisées que les jeux de données doivent utiliser. »
- « Le fichier de métadonnées lisible par la machine, exigé par la FDA et la PMDA, qui permet à un évaluateur de remonter d’un résultat jusqu’à son jeu de données source et sa dérivation. »
Parcourez la chaîne : collecter → tabuler → analyser → décrire. Puis rappelez-vous le seul standard qui est un vocabulaire alimentant les jeux de données en valeurs, plutôt qu’une étape du pipeline.
- CDASH — le standard de collecte des données, structuré pour se mapper proprement vers SDTM.
- SDTM — le modèle de tabulation, organisant les données en domaines (DM, AE, VS, …).
- Controlled Terminology — le vocabulaire partagé, maintenu par la CDISC Terminology Team avec NCI/EVS et publié trimestriellement.
- Define-XML — les métadonnées de jeux de données lisibles par la machine, exigées pour les soumissions FDA et PMDA. (ADaM, le standard d’analyse, serait la réponse à « les jeux de données dérivés, prêts pour l’analyse, qui remontent jusqu’à SDTM ».)
A. « SDTM » est le nom d’un fichier précis (sdtm.xpt) que vous soumettez à la FDA. B. Un standard CDISC est un modèle plus un Implementation Guide ; les jeux de données de votre étude sont l’ implémentation qui s’y conforme. C. Le cSDRG et l’ADRG sont des standards fondamentaux CDISC au même titre que SDTM et ADaM.
B. Un standard est le cahier de règles (un modèle + son IG, par exemple le SDTMIG) ; vos jeux de données réels sont l’implémentation construite selon lui. A est faux — il n’existe pas de sdtm.xpt unique ; SDTM est le standard auquel se conforment vos jeux de données de domaines (dm.xpt, ae.xpt, …). C est faux — le cSDRG et l’ADRG sont des guides de l’évaluateur construits sur des modèles PHUSE, et non des standards CDISC.
Références
Sources primaires et faisant autorité pour les standards décrits ci-dessus :
- CDISC Foundational Standards (vue d’ensemble de la famille) : https://www.cdisc.org/standards/foundational
- CDASH (Clinical Data Acquisition Standards Harmonization) : https://www.cdisc.org/standards/foundational/cdash
- SDTM (Study Data Tabulation Model) : https://www.cdisc.org/standards/foundational/sdtm · SDTMIG : https://www.cdisc.org/standards/foundational/sdtmig
- ADaM (Analysis Data Model) : https://www.cdisc.org/standards/foundational/adam · ADaMIG v1.3 (définit ADSL et BDS) : https://www.cdisc.org/standards/foundational/adam/adamig-v1-3
- CDISC Controlled Terminology (listes de codes et valeurs autorisées, publié trimestriellement) : https://www.cdisc.org/standards/terminology/controlled-terminology · maintenu avec NCI/EVS : https://www.cdisc.org/partner/nci-evs
- Define-XML (standard de métadonnées d’échange de données ; exigé par la FDA et les autorités japonaises) : https://www.cdisc.org/standards/data-exchange/define-xml
- SEND (Standard for Exchange of Nonclinical Data) : https://www.cdisc.org/standards/foundational/send
- CDISC Library (référentiel de métadonnées lisible par la machine) : https://www.cdisc.org/cdisc-library
- CDISC 360i (initiative d’automatisation pilotée par les standards et les métadonnées) : https://www.cdisc.org/cdisc-360i
- PHUSE cSDRG Package (modèle de Clinical Study Data Reviewer’s Guide — un livrable PHUSE, non un standard CDISC) : https://advance.hub.phuse.global/wiki/spaces/WEL/pages/26806088/Clinical+Study+Data+Reviewer+s+Guide+cSDRG+Package.
- PHUSE ADRG Package (modèle d’Analysis Data Reviewer’s Guide — un livrable PHUSE, non un standard CDISC) : https://advance.hub.phuse.global/wiki/spaces/WEL/pages/26804660/Analysis+Data+Reviewer+s+Guide+ADRG+Package
Conclusion
Les standards CDISC forment une chaîne avec une enveloppe. CDASH normalise la manière dont les données sont collectées, SDTM les tabule en domaines fixes, ADaM dérive les jeux de données prêts pour l’analyse, et Controlled Terminology fournit les valeurs codées partagées qui circulent dans les deux — tandis que Define-XML décrit les jeux de données SDTM et ADaM pour qu’un évaluateur puisse remonter n’importe quelle valeur jusqu’à sa source, le cSDRG et l’ADRG relatant le reste. Gardez deux idées à l’esprit et toute la famille reste claire : la sortie de chaque standard est l’entrée du suivant, et un standard est le cahier de règles qu’implémentent les jeux de données de votre étude. Avec cette carte en main, les séries pratiques SDTM et ADaM à venir ne sont que le travail de construction de vrais jeux de données selon des règles que vous comprenez déjà.
Leçons connexes
- Flux de données des essais cliniques : du CRF à SDTM, ADaM, TLF et à la soumission — le pipeline que ces standards régissent, de bout en bout. · Contexte réglementaire : FDA, ICH, eCTD — pourquoi la FDA et la PMDA rendent ces standards obligatoires. · Estimandes (ICH E9(R1)) — le cadre qui décide quelles variables et analyses ADaM vous dérivez. · CDISC ADTTE pour la soumission réglementaire — un jeu de données ADaM concret (délai jusqu’à l’événement) construit et mis en package selon ces standards.
- Où cela s’inscrit : développement du médicament et flux de données → contexte réglementaire → estimandes (ICH E9(R1)) → les standards CDISC (vous êtes ici) → le passage de SAS à R — d’abord les concepts, puis les workflows pratiques SDTM, ADaM et TLF qui les implémentent.
Réutilisation
Citation
@online{2026,
author = {},
title = {Standards CDISC : CDASH, SDTM, ADaM et Define-XML},
date = {2026-06-30},
url = {https://www.datanovia.com/learn/pharma-clinical/01-regulatory-cdisc-foundations/04-cdisc-standards},
langid = {fr}
}
Comment les standards s’articulent
Les standards fondamentaux ne sont pas une liste plate — ils forment une chaîne dirigée avec une enveloppe. Lisez le diagramme comme le parcours des données d’un essai :
Les flèches pleines représentent le pipeline de données : CDASH façonne la manière dont les données sont collectées, SDTM les tabule, ADaM dérive ce qui est analysé. Les flèches en pointillés sont le tissu conjonctif : Controlled Terminology alimente les deux — SDTM et ADaM — en valeurs normalisées, et Define-XML les décrit tous deux pour que l’ensemble soit navigable et traçable. Saisissez cette image et chaque standard ci-dessous n’est qu’une boîte étiquetée.