ADaM piloté par les métadonnées en R : metacore et metatools

Pilotez et vérifiez vos dérivations admiral depuis une seule spécification ADaM lisible par machine — ordre des variables, libellés, longueurs et terminologie contrôlée imposés par la spec, non codés à la main dans chaque programme

Un tutoriel complet et exécutable sur la programmation ADaM pilotée par les métadonnées en R. Apprenez ce que sont metacore et metatools (metacore détient la spécification ADaM sous forme d’objet lisible par machine, construit depuis un Define-XML ou une feuille de calcul de spec ; metatools applique et vérifie un jeu de données par rapport à elle), puis chargez la spécification ADSL pilote CDISC, inspectez ses métadonnées de variables et sa terminologie contrôlée, et validez un ADSL dérivé avec check_variables(), check_ct_data(), drop_unspec_vars(), order_cols() et sort_by_key() — sur des données d’exemple publiques pharmaverse, de sorte que chaque ligne s’exécute.

Date de publication

1 juillet 2026

Modifié

7 juillet 2026

AstucePoints clés
  • La spécification est l’unique source de vérité. Un jeu de données ADaM (Analysis Data Model) est défini par une spec — noms de variables, ordre, libellés, longueurs et terminologie contrôlée (CT) — que la même équipe livre aussi sous la forme du document Define-XML. La programmation pilotée par les métadonnées lit cette spec une seule fois et l’applique partout, au lieu de la coder en dur dans chaque programme.
  • metacore détient la spec ; metatools l’utilise. metacore transforme un fichier Define-XML ou une feuille de calcul de spécification en un seul objet R lisible par machine. metatools fournit les fonctions qui appliquent la spec à un jeu de données et vérifient le jeu de données par rapport à elle.
  • Chaque vérification tient en une ligne. check_variables() confirme que chaque variable spécifiée est présente (et qu’aucune superflue ne s’est glissée) ; check_ct_data() confirme que chaque valeur se situe dans sa terminologie contrôlée.
  • Conforme par construction. drop_unspec_vars() retire les colonnes hors spec, order_cols() les place dans l’ordre de la spec, sort_by_key() trie les lignes selon la séquence de clés, et add_labels() applique les libellés de la spec — de sorte que le jeu de données dérivé corresponde au Define-XML avec lequel il sera soumis.
  • C’est ce qui permet à ADaM de passer à l’échelle. Les dérivations admiral que vous écrivez à la main produisent les valeurs ; la spec metacore gouverne la structure. Ensemble, elles vous donnent un jeu de données d’analyse correct et conforme à travers des dizaines de jeux de données sans avoir à retaper les métadonnées à chaque fois.

Introduction

Dans les leçons précédentes de cette série, vous avez dérivé des jeux de données d’analyse à la main : l’ADSL au niveau sujet, l’ADLB de laboratoire et l’ADVS des signes vitaux. Chacun de ces programmes encodait discrètement une spécification — l’ensemble exact des variables, leur ordre, leurs libellés, leurs longueurs et les valeurs que chacune peut prendre. Vous avez tapé cette structure dans le code.

Cela ne passe pas à l’échelle. Une soumission réelle compte des dizaines de jeux de données ADaM, et la même spécification est aussi consignée dans le Define-XML — le document de métadonnées lisible par machine qui accompagne les données jusqu’au régulateur. Encoder la spec deux fois (une fois dans votre programme, une fois dans le Define-XML) est la façon dont un libellé dérive, un ordre de variables diverge ou une valeur sort de sa terminologie contrôlée (CT) — la liste de codes autorisés pour une variable, comme M/F pour SEX.

La programmation pilotée par les métadonnées supprime la duplication : lisez la spécification une seule fois dans un objet lisible par machine, puis faites en sorte que votre programme l’applique et la vérifie. Cette leçon utilise deux paquets pharmaverse conçus exactement pour cela — metacore et metatools — sur la spécification pilote publique du CDISC (Clinical Data Interchange Standards Consortium), de sorte que chaque ligne s’exécute telle qu’écrite.

Voici la spécification ADSL avec laquelle nous allons travailler, résumée directement depuis l’objet spec — 51 variables, regroupées par type :

Horizontal bar chart summarizing the CDISC pilot ADSL specification by variable type, read directly from the metacore spec object. Text variables dominate with 30, followed by integer with 15 and float with 6, for 51 variables in total. The chart is derived from the specification metadata itself, illustrating that the spec is a queryable object rather than a static document.

Ce diagramme en barres n’a pas été compté à la main — il a été calculé depuis l’objet spécification lui-même. À la fin de cette leçon, vous lirez des métadonnées comme celles-ci, et les utiliserez pour vérifier la conformité d’un jeu de données dérivé. Si « ADaM », « Define-XML » ou « CDISC » vous sont nouveaux, commencez par les standards CDISC, qui situent où la spécification et le Define-XML s’insèrent dans le pipeline.

Ce que sont metacore et metatools

Les deux paquets répartissent le travail proprement : l’un détient la spécification, l’autre agit sur elle.

metacore (CRAN · docs) lit une spécification — un fichier Define-XML ou une feuille de calcul de spécification — dans un seul objet R. Cet objet est une petite base de données des métadonnées, organisée en sept tables liées :

table metacore Ce qu’elle contient
ds_spec Informations au niveau du jeu de données (nom, structure, libellé).
ds_vars Quelles variables appartiennent à chaque jeu de données, plus l’ordre et la séquence de clés.
var_spec Métadonnées au niveau variable : libellé, type, longueur, format.
value_spec Métadonnées au niveau valeur : origine, type, et liens vers la CT et les dérivations.
derivations Le texte de dérivation de chaque variable.
codelist Terminologie contrôlée — les paires code/décode et les valeurs autorisées.
supp Métadonnées pour les variables qualificatives supplémentaires.

metatools (CRAN · docs) est la boîte à outils qui lit un objet metacore et soit construit de la structure dans un jeu de données, soit vérifie un jeu de données par rapport à la spec. Voici les fonctions que cette leçon utilise :

fonction metatools Ce qu’elle fait
build_from_derived() Extraire les colonnes « prédécesseur » directement des jeux de données sources pour démarrer un ADaM.
check_variables() Confirmer que le jeu de données a exactement les variables de la spec — aucune manquante, aucune en trop.
check_ct_data() Confirmer que chaque valeur se situe dans sa terminologie contrôlée.
drop_unspec_vars() Supprimer toute colonne absente de la spec.
order_cols() Réordonner les colonnes selon l’ordre des variables de la spec.
sort_by_key() Trier les lignes selon la séquence de clés de la spec.
add_labels() / add_variables() Appliquer les libellés de la spec ; ajouter les variables de la spec manquantes, correctement typées.

La répartition du travail est l’idée maîtresse : metacore est ce que le jeu de données doit être, metatools fait qu’un jeu de données le devienne et prouve qu’il l’est devenu.

Charger une spécification metacore

En pratique, vous construisez un objet metacore à partir de votre propre Define-XML ou feuille de calcul de spec. metacore lit un Define-XML avec les fonctions de lecture xml_to_*(), et une feuille de calcul de spécification de style Pinnacle 21 avec spec_to_metacore() :

# From a Define-XML file (the CDISC metadata exchange format):
library(xml2)
doc <- read_xml("define.xml")
xml_ns_strip(doc)
metacore(
  xml_to_ds_spec(doc), xml_to_ds_vars(doc), xml_to_var_spec(doc),
  xml_to_value_spec(doc), xml_to_derivations(doc), xml_to_codelist(doc)
)

# ...or directly from a specification spreadsheet:
spec_to_metacore("adam_spec.xlsx")

Pour que cette leçon s’exécute partout, nous utilisons l’objet de spécification ADaM prêt à l’emploi que metacore fournit pour l’étude pilote CDISC — le même essai synthétique que dérivent les leçons admiral. Il contient les specs de chaque jeu de données du pilote, donc le premier geste est de le restreindre à celui qui nous intéresse, ADSL (le Subject-Level Analysis Dataset — une ligne par sujet), avec select_dataset() :

library(metacore)
library(metatools)
library(dplyr, warn.conflicts = FALSE)
library(haven)

# The example ADaM spec object for the CDISC pilot (all datasets)
load(metacore_example("pilot_ADaM.rda"))

# Narrow to the ADSL specification
adsl_spec <- metacore %>% select_dataset("ADSL")
adsl_spec

adsl_spec contient maintenant uniquement les métadonnées ADSL, et son impression montre la structure du jeu de données et le nombre de variables. Chaque fonction metatools ci-dessous prend cet objet restreint.

Inspecter la spécification

Parce que la spec est un objet, et non un document statique, vous pouvez l’interroger. Deux vues importent le plus pendant la programmation : les métadonnées par variable et la terminologie contrôlée.

Les métadonnées de variable — libellé, type, longueur — se trouvent dans var_spec. C’est la source de vérité pour ce à quoi chaque colonne doit ressembler :

adsl_spec$var_spec %>%
  select(variable, type, length, label) %>%
  head(8)
# A tibble: 8 × 4
  variable type    length label                              
  <chr>    <chr>    <int> <chr>                              
1 STUDYID  text        12 Study Identifier                   
2 SUBJID   text         4 Subject Identifier for the Study   
3 SITEID   text         3 Study Site Identifier              
4 SITEGR1  text         3 Pooled Site Group 1                
5 ARM      text        20 Description of Planned Arm         
6 TRT01P   text        20 Planned Treatment for Period 01    
7 TRT01PN  integer      8 Planned Treatment for Period 01 (N)
8 TRT01A   text        20 Actual Treatment for Period 01

La terminologie contrôlée — les valeurs autorisées pour une variable codée — provient de get_control_term(). Demandez une variable et elle renvoie les valeurs autorisées (un simple vecteur de valeurs autorisées, ou une table code/décode pour une liste de codes). Voici la CT pour SEX, puis pour RACE :

get_control_term(adsl_spec, SEX)
# A tibble: 2 × 1
  code 
  <chr>
1 M    
2 F    
get_control_term(adsl_spec, RACE)
# A tibble: 5 × 2
  code                                      decode                              
  <chr>                                     <chr>                               
1 WHITE                                     WHITE                               
2 BLACK OR AFRICAN AMERICAN                 BLACK OR AFRICAN AMERICAN           
3 AMERICAN INDIAN OR ALASKA NATIVE          AMERICAN INDIAN OR ALASKA NATIVE    
4 ASIAN                                     ASIAN                               
5 NATIVE HAWAIIAN OR OTHER PACIFIC ISLANDER NATIVE HAWAIIAN OR OTHER PACIFIC IS…

SEX ne peut être que M ou F ; RACE a une liste de codes à cinq lignes. Ce sont les ensembles de valeurs exacts que check_ct_data() fera respecter dans un instant — la spec les définit une seule fois, et la vérification les relit directement.

Appliquer et vérifier un jeu de données par rapport à la spec

Voici maintenant la récompense. Nous prenons un ADSL dérivé — le jeu de données d’analyse fini que produit un programme comme la leçon ADSL — et le validons par rapport à la spécification. metatools fournit un ADSL dérivé exactement à cette fin :

adsl <- read_xpt(metatools_example("adsl.xpt"))
dim(adsl)
[1] 254  51

Vérifier que toutes les variables sont là

check_variables() compare les colonnes du jeu de données à la liste de variables de la spec. Si elles correspondent, il le dit ; si une variable manque ou qu’une variable inattendue est présente, il vous indique laquelle. Nous faisons apparaître son message :

adsl <- check_variables(adsl, adsl_spec)
No missing or extra variables

« No missing or extra variables » est le feu vert : l’ADSL dérivé a exactement les colonnes que la spec définit. Si un programme avait oublié TRTSDT, ou laissé traîner une colonne de travail, le message la nommerait — et vous corrigeriez la dérivation (ajouter la variable) ou la spec (si la variable n’a véritablement pas sa place), de sorte que les deux s’accordent. La fonction renvoie les données inchangées, elle s’insère donc directement dans un pipeline.

Vérifier que les valeurs sont dans leur terminologie contrôlée

check_ct_data() procède valeur par valeur : pour chaque variable dotée d’une liste de codes, il confirme que chaque valeur observée est autorisée. Sur un jeu de données conforme, il passe en silence — sauf pour le feu vert :

adsl <- check_ct_data(adsl, adsl_spec, omit_vars = c("AGEGR2", "AGEGR2N"))
✔ All controlled terminology checks passed

(omit_vars ignore AGEGR2/AGEGR2N ici pour une raison subtile : elles ont bien une terminologie contrôlée dans la spec, mais les données pilotes stockent les libellés décodés (p. ex. "18-64 years") tandis que check_ct_data() valide par rapport au code de la liste de codes ("18-64") — un décalage code/décode dans les données d’exemple, pas un défaut de spec.) La vérification passe car chaque valeur correspond déjà. Pour voir à quoi ressemble un échec — la raison même pour laquelle vous exécutez la vérification — nous corrompons délibérément une valeur, en écrivant "Male" dans SEX là où la CT n’autorise que M/F :

adsl_bad <- adsl
adsl_bad$SEX[1] <- "Male"          # not in the SEX code list (M / F)

invisible(check_ct_data(adsl_bad, adsl_spec, omit_vars = c("AGEGR2", "AGEGR2N")))
Warning: ✖ Invalid controlled terminology detected
ℹ Variable: SEX | Codelist: CL.SEX
ℹ Values not permitted 'Male'

L’avertissement nomme la variable (SEX), la liste de codes (CL.SEX) et la valeur fautive ('Male'). Voilà toute la valeur d’une vérification pilotée par les métadonnées : elle ne dit pas seulement « quelque chose ne va pas », elle pointe la cellule exacte et la règle qu’elle a enfreinte — de sorte que vous corrigiez la dérivation qui a produit "Male" (elle devrait donner M) avant que le jeu de données n’atteigne le Define-XML.

Conformer la structure à la spec

Passer les vérifications confirme que le contenu est correct. Trois autres fonctions metatools rendent la structure conforme — et chacune tient en une ligne.

drop_unspec_vars() retire toute colonne que la spec ne définit pas. Regardez-la supprimer une colonne de travail parasite :

adsl_extra <- adsl %>% mutate(SCRATCH = "temporary working column")

adsl_clean <- drop_unspec_vars(adsl_extra, adsl_spec)

"SCRATCH" %in% names(adsl_clean)   # dropped -> FALSE
[1] FALSE

order_cols() réordonne les colonnes selon l’ordre des variables de la spec — l’ordre que le Define-XML déclare et que le relecteur attend :

adsl_ordered <- order_cols(adsl, adsl_spec)
names(adsl_ordered)[1:8]
[1] "STUDYID" "USUBJID" "SUBJID"  "SITEID"  "SITEGR1" "ARM"     "TRT01P" 
[8] "TRT01PN"

sort_by_key() trie les lignes selon la séquence de clés de la spec (pour ADSL, USUBJID), de sorte que le jeu de données soit dans son ordre canonique :

adsl_final <- sort_by_key(adsl_ordered, adsl_spec)
adsl_final %>%
  select(USUBJID, TRT01P, AGE, SEX, RACE) %>%
  head(5)
# A tibble: 5 × 5
  USUBJID     TRT01P                 AGE SEX   RACE 
  <chr>       <chr>                <dbl> <chr> <chr>
1 01-701-1015 Placebo                 63 F     WHITE
2 01-701-1023 Placebo                 64 M     WHITE
3 01-701-1028 Xanomeline High Dose    71 M     WHITE
4 01-701-1033 Xanomeline Low Dose     74 M     WHITE
5 01-701-1034 Xanomeline High Dose    77 F     WHITE

Deux compagnons complètent les métadonnées : add_labels() applique les libellés de variables depuis la spec (afin que le jeu de données exporté porte les libellés du Define-XML), et add_variables() ajoute toute variable de la spec qu’une dérivation a manquée, correctement typée et vide — utile comme filet de sécurité avant les vérifications finales. Pour démarrer un ADaM depuis des données sources, build_from_derived() extrait les colonnes « prédécesseur » (les variables copiées directement d’une source SDTM — le Study Data Tabulation Model) directement des jeux de données sources, vous donnant un squelette typé et libellé sur lequel dériver le reste.

Pourquoi c’est ainsi qu’ADaM passe à l’échelle

Prenez du recul et voyez ce qui a changé. Dans les leçons à la main, la structure ADSL vivait à l’intérieur du programme : vous nommiez les variables, les ordonniez, les libelliez, et saviez — dans votre tête — quelles valeurs étaient légales. Ici, cette structure vit dans un seul objet de spécification, et le programme la lit :

  • la dérivation (admiral) produit les valeurs ;
  • la spécification (metacore) définit la structure ;
  • les vérifications (metatools) prouvent que les valeurs correspondent à la structure — automatiquement, de la même façon, pour chaque jeu de données.

Exécutez les trois mêmes vérifications sur ADLB, ADVS, ADAE et ADTTE et vous obtenez une conformité à l’échelle de la soumission sans retaper un seul libellé ni une seule liste de codes. Et parce que l’objet spec est construit à partir du même Define-XML que vous soumettez, les données et leur document de métadonnées ne peuvent silencieusement diverger — la vérification l’attraperait. Voilà ce qu’est la programmation pilotée par les métadonnées : la spec est l’unique source de vérité, et le jeu de données est conforme par construction.

🟢 Avec un agent IA

Demandez à Prova « comment construire un objet metacore depuis mon propre Define-XML et vérifier mon ADSL dérivé par rapport à lui avec metatools ? » — elle répond en s’appuyant sur les leçons de ce pilier, avec du code metacore/metatools exécutable que vous pouvez essayer sur les données d’exemple pharmaverse. The runtime is the judge. Demandez à Prova →

Problèmes fréquents

check_variables() signale une variable manquante que vous savez avoir dérivée. Le jeu de données et la spec sont en désaccord sur le nom de la variable, pas sur sa présence — une cause fréquente est une faute de frappe ou une différence de casse (trt01p vs TRT01P), ou une variable que la spec attend mais que votre programme a renommée. Lisez le message : il liste exactement quels noms manquent et lesquels sont en trop. Corrigez le côté qui est faux — d’ordinaire la dérivation, occasionnellement la spec.

check_ct_data() avertit à propos d’une valeur qui semble correcte. La terminologie contrôlée est exacte et sensible à la casse. "Male" n’est pas "M", "White" n’est pas "WHITE", et un espace de fin ("M ") échoue aussi. L’avertissement affiche la variable, la liste de codes et la valeur fautive exacte — faites correspondre cette valeur à son code autorisé dans la dérivation. Si la valeur est véritablement valide et que la spec est obsolète, mettez plutôt à jour la liste de codes de la spec ; l’important est que l’un des deux doive changer pour qu’ils s’accordent.

Une vérification a d’abord besoin que l’objet metacore soit restreint à un seul jeu de données. Les fonctions de vérification et de conformité de metatools attendent une spec pour un seul jeu de données. Si vous passez l’objet multi-jeux de données complet que vous avez chargé depuis Define-XML, restreignez-le d’abord avec metacore::select_dataset("ADSL") (comme nous l’avons fait avec adsl_spec), sinon les fonctions ne peuvent pas savoir de quel jeu de données utiliser les variables et les listes de codes.

Questions fréquentes

Cela signifie piloter vos dérivations ADaM depuis une seule spécification lisible par machine au lieu de coder en dur les noms de variables, l’ordre, les libellés, les longueurs et la terminologie contrôlée dans chaque programme. Vous lisez la spec une seule fois (avec metacore), dérivez les valeurs avec un outil comme admiral, puis appliquez et vérifiez la structure par rapport à la spec (avec metatools). La spécification — la même que celle livrée sous forme de Define-XML — devient l’unique source de vérité, de sorte que les données et leurs métadonnées ne peuvent diverger.

metacore détient la spécification : il lit un fichier Define-XML ou une feuille de calcul de spec dans un seul objet R de tables de métadonnées liées (variables, libellés, terminologie contrôlée, dérivations). metatools agit sur cet objet : ses fonctions appliquent la spec à un jeu de données (order_cols(), add_labels(), drop_unspec_vars()) et vérifient un jeu de données par rapport à elle (check_variables(), check_ct_data()). En bref, metacore est ce que le jeu de données doit être ; metatools fait qu’un jeu de données le devienne et prouve qu’il l’est devenu.

Utilisez les fonctions de lecture de metacore. Analysez le fichier avec xml2::read_xml() et xml_ns_strip(), puis appelez xml_to_ds_spec(), xml_to_ds_vars(), xml_to_var_spec(), xml_to_value_spec(), xml_to_derivations() et xml_to_codelist() dessus et assemblez les pièces avec metacore(). Pour une feuille de calcul de spécification de style Pinnacle 21, spec_to_metacore("spec.xlsx") le fait en un seul appel. Les deux vous donnent le même type d’objet metacore.

Restreignez votre objet metacore au jeu de données avec metacore::select_dataset(), puis appelez metatools::check_ct_data(data, spec). Il compare les valeurs de chaque variable codée à sa liste de codes et avertit avec le nom de la variable, la liste de codes et la valeur fautive exacte si quelque chose sort de la terminologie. Pour voir à l’avance les valeurs autorisées d’une variable, utilisez metacore::get_control_term(spec, VARNAME).

Oui — ils font des tâches différentes. admiral dérive les valeurs (dates de traitement, valeurs de référence, indicateurs, délai jusqu’à l’événement) ; metacore et metatools gouvernent et vérifient la structure (quelles variables, dans quel ordre, avec quels libellés et quelle terminologie contrôlée). Une construction typique utilise admiral pour les dérivations et metatools pour conformer et valider le résultat par rapport à la spec metacore. Ce sont des paquets pharmaverse complémentaires, pas des alternatives.

Testez vos connaissances

En partant de l’ADSL dérivé de cette leçon, supprimez la colonne TRT01P pour simuler une dérivation qui l’a oubliée, puis exécutez check_variables() par rapport à adsl_spec. Que rapporte la vérification, et quel côté corrigeriez-vous ?

Retirez la colonne avec select(-TRT01P), puis passez le résultat à check_variables() avec adsl_spec. Par défaut (strict = FALSE), la vérification avertit en cas de non-correspondance plutôt que de s’arrêter, ce qui garde le message facile à lire ; passez strict = TRUE pour faire d’une non-correspondance une erreur bloquante qui interrompt l’exécution.

adsl_missing <- adsl %>% select(-TRT01P)

check_variables(adsl_missing, adsl_spec, strict = FALSE)

La vérification signale TRT01P comme variable manquante — elle est dans la spécification mais pas dans le jeu de données. La correction se fait presque toujours du côté dérivation : rajoutez la dérivation de TRT01P pour que le programme produise la variable que la spec exige. Vous ne changeriez la spec que si TRT01P n’avait véritablement pas sa place dans ADSL — ce qui, pour le traitement planifié de la période 01, sera toujours le cas. Voilà la vérification qui gagne sa place : une variable oubliée est attrapée mécaniquement, avant que le jeu de données n’atteigne le Define-XML.

A. Que chaque variable de la spec est présente dans le jeu de données B. Que chaque valeur se situe dans la terminologie contrôlée de sa variable C. Que les colonnes sont dans l’ordre de la spec

B. check_ct_data() valide les valeurs par rapport à la terminologie contrôlée — il avertit lorsqu’une variable codée contient une valeur hors de sa liste de codes (comme "Male" là où seuls M/F sont autorisés). A est ce que fait check_variables(), et C est ce que fait order_cols(). Les trois sont des étapes distinctes, chacune d’une ligne : variables présentes, valeurs dans la terminologie, colonnes dans l’ordre.

Conclusion

La programmation ADaM pilotée par les métadonnées scinde un problème que vous résolviez autrefois dans un seul programme emmêlé en deux moitiés propres : la dérivation produit les valeurs, et la spécification gouverne la structure. metacore transforme votre Define-XML ou feuille de calcul de spec en un objet interrogeable ; metatools l’applique (drop_unspec_vars(), order_cols(), sort_by_key(), add_labels()) et — surtout — vérifie par rapport à elle (check_variables(), check_ct_data()). Chaque vérification tient en une ligne, lit la règle directement depuis la spec, et pointe la variable ou la valeur exacte qui l’enfreint. Faites-le une fois et c’est un joli rangement ; faites-le à travers chaque jeu de données ADaM d’une étude et c’est la différence entre espérer que vos données correspondent à leur Define-XML et savoir que c’est le cas. La spécification est l’unique source de vérité, et le jeu de données est conforme par construction.

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.

Leçons connexes

  • Créer ADSL en R avec admiral — la dérivation au niveau sujet dont cette spécification gouverne la structure ; le jeu de données naturel à vérifier en premier. · Construire ADLB et la structure BDS — le jeu de données au niveau paramètre que les trois mêmes vérifications conforment. · Les standards CDISC : CDASH, SDTM, ADaM, Define-XML — où la spécification et le Define-XML s’insèrent dans le pipeline CDISC. · Le passage de SAS à R en programmation clinique — pourquoi metacore et metatools remplacent les macros de métadonnées maintenues à la main.
  • Où cela s’insère : les fondations réglementaires et CDISC → construire ADaM avec admiral (ADSL → ADLB → ADVS → ADAE → ADTTE) → gouverner tous ces jeux de données avec une seule spécification (vous êtes ici) → produire les tableaux, listings et figures que chaque analyse livre. La programmation pilotée par les métadonnées est ce qui garde toute cette chaîne conforme à l’échelle.
Cette page vous a-t-elle été utile ?

Recevez les nouvelles leçons R & Python par e-mail

Pratique, reproductible, sans spam. Désinscription à tout moment.

Double opt-in. Nous ne partageons jamais votre e-mail.

Partager cette pageXLinkedInRedditHN

Réutilisation

Citation

BibTeX
@online{2026,
  author = {},
  title = {ADaM piloté par les métadonnées en R : metacore et metatools},
  date = {2026-07-01},
  url = {https://www.datanovia.com/learn/pharma-clinical/03-adam-admiral/metadata-driven-adam-metacore},
  langid = {fr}
}
Veuillez citer ce travail comme suit :
“ADaM piloté par les métadonnées en R : metacore et metatools.” 2026. July 1. https://www.datanovia.com/learn/pharma-clinical/03-adam-admiral/metadata-driven-adam-metacore.