Revue clinique interactive avec teal : créer des applications de données d’essais cliniques en R

Q: Qu’est-ce que teal en R ?

teal est un package R issu du projet NEST de Roche (partie de pharmaverse) pour construire des applications web interactives qui explorent les données d’essais cliniques. Son titre CRAN est « Exploratory Web Apps for Analyzing Clinical Trials Data ». Vous construisez une application teal en donnant à init() vos données et une liste de modules (des vues d’analyse préconçues) ; teal fournit le panneau de filtres partagé, l’UI et une piste reproductible Show R code. Il est construit sur Shiny mais vous épargne d’écrire du Shiny brut.

Q: Comment construire une application de revue clinique en R ?

Utilisez teal avec teal.modules.clinical. Enveloppez vos jeux de données ADaM avec cdisc_data(), listez les modules cliniques voulus — par exemple tm_t_summary() pour la démographie et tm_g_km() pour une courbe de Kaplan-Meier — passez-les à init(data =, modules = modules(...)), et lancez avec shinyApp(app$ui, app$server). Configurez chaque module avec choices_selected() pour que les relecteurs puissent changer les variables depuis l’application en cours d’exécution. Vous assemblez l’application à partir de modules au lieu de coder l’UI et le serveur à la main.

Q: Qu’est-ce que teal.modules.clinical ?

C’est le package R compagnon qui livre des modules teal cliniques préconçus, construits sur le moteur de tableaux rtables/tern. Il inclut la démographie (tm_t_summary), Kaplan-Meier (tm_g_km), les tableaux d’événements indésirables (tm_t_events), les forest plots (tm_g_forest_tte), MMRM (tm_a_mmrm), les tableaux de délai jusqu’à l’événement (tm_t_tte), la régression de Cox (tm_t_coxreg) et davantage. Vous ajoutez ces modules à la liste modules() d’une application teal et vous les configurez avec des specs choices_selected() — vous ne programmez pas les sorties vous-même.

Assemblez une application de revue interactive pour les données d’essais cliniques à partir de modules préconçus au lieu d’écrire du Shiny à la main — le modèle mental de teal (données + modules + un panneau de filtres partagé), le code init() et teal.modules.clinical

teal est le framework Roche/NEST pour construire des applications interactives de revue et d’exploration des données d’essais cliniques. Cette leçon explique ce qu’est teal, son modèle mental — des données plus une liste de modules plus un panneau de filtres partagé, assemblés avec init() — et comment teal.modules.clinical vous fournit des sorties cliniques préconçues (démographie, Kaplan-Meier, événements indésirables, forêt, MMRM). Elle parcourt le code qui assemble une application, montre à quoi ressemble une application en cours d’exécution avec un schéma d’architecture et une démo en direct, et situe teal dans le workflow de revue clinique face à l’écriture d’une application Shiny sur mesure à la main.

Date de publication

1 juillet 2026

Modifié

7 juillet 2026

Points clés

teal vous permet d’assembler une application de revue clinique, pas d’en écrire une à la main. teal (en minuscules — le package R) est un framework fondé sur Shiny issu du projet NEST de Roche (une suite de packages R pour le reporting clinique) — partie de pharmaverse, l’écosystème R open source de reporting clinique — pour construire des applications interactives qui explorent les données d’essais cliniques.
Chaque application teal, c’est trois choses : données + modules + un panneau de filtres. Vous donnez à init() vos jeux de données, une liste de modules (des vues d’analyse autonomes), et il câble un panneau de filtres partagé — la barre latérale qui sous-ensemble tous les modules à la fois — puis vous la lancez avec shinyApp().
teal.modules.clinical livre les sorties cliniques standard préconçues. Démographie (tm_t_summary), Kaplan-Meier (tm_g_km), événements indésirables (tm_t_events), forest plots (tm_g_forest_tte), MMRM (tm_a_mmrm) — vous les configurez, vous ne les codez pas de zéro.
Une application teal en cours d’exécution vous donne la reproductibilité gratuitement. Chaque vue a un bouton Show R code qui émet le R exact qui l’a produite — l’application de revue est auditable, pas une boîte noire.
teal complète vos tableaux, listings et figures (TLF) statiques. Les sorties de soumission restent fixes ; teal est là où un moniteur médical explore les données de manière interactive avant et autour de ces sorties.

Introduction

Vous avez construit les jeux de données ADaM (Analysis Data Model) d’une étude, et voilà qu’un moniteur médical veut fouiller dedans : sous-ensembler au bras de traitement, voir la courbe de Kaplan-Meier de ce sous-groupe, ouvrir le tableau des événements indésirables, filtrer sur les patients de plus de 65 ans, puis revérifier la démographie. Chacune de ces demandes est raisonnable, et chacune est une petite application Shiny sur mesure si vous la construisez à la main — une nouvelle UI, un nouveau serveur réactif, un nouveau filtre, pour chaque analyste, pour chaque étude.

teal existe pour vous l’éviter. teal est un framework fondé sur Shiny — sa description CRAN est « Exploratory Web Apps for Analyzing Clinical Trials Data » — open-sourcé par F. Hoffmann-La Roche / Genentech sous le nom de projet NEST et désormais partie de pharmaverse. Au lieu d’écrire du Shiny brut, vous assemblez une application à partir de pièces préconçues : donnez-lui vos données, choisissez les modules d’analyse voulus, et teal vous donne une application complète avec un panneau de filtres partagé et une sortie reproductible.

Cette leçon explique ce qu’est teal, son modèle mental, le code qui assemble une application avec teal.modules.clinical, à quoi ressemble une application en cours d’exécution, et où elle s’insère dans le workflow de revue clinique.

A schematic of the teal application shell, drawn as a browser window with four labeled regions. Across the top, a dark navy toolbar labelled 'teal app' carries three chips on the right: a 'Dataset ADSL' chooser, a 'Show R code' button, and an '+ Add to Report' button. Down the left side, a light-azure 'Filter Data panel' contains an 'Active Data Summary' box reading 'ADSL 95 / 306 rows' and two stacked filter cards, 'ARM' and 'SEX' — the shared sidebar that subsets every module at once. The large main pane on the right has a row of three module tabs, 'Demographics', 'Kaplan-Meier', and 'Adverse Events', above an output area labelled 'Module output — reactive to the filter panel'. The visual point is that a teal app is data plus a list of modules plus one shared filter panel: filtering on the left updates every module tab, and Show R code makes each view reproducible.

Ce qu’est teal

teal est un framework pour construire des applications web interactives par-dessus Shiny (le framework d’applications web de R), visant spécifiquement l’exploration des données d’essais cliniques. Deux idées le rendent digne d’être appris :

Vous assemblez, vous n’écrivez pas. Une application Shiny brute vous fait écrire vous-même la mise en page de l’UI, la logique du serveur réactif et le filtrage des données. teal vous donne tout cela sous forme de pièces réutilisables — vous choisissez les morceaux et vous les connectez. L’unité que vous connectez est un module : une vue d’analyse autonome (un tableau, un graphique, un listing) qui sait se rendre à partir des données de l’application.
Il est conçu pour les données cliniques. teal comprend les données au format CDISC (Clinical Data Interchange Standards Consortium) — il peut prendre des jeux de données ADaM clés par sujet, câbler un panneau de filtres qui respecte cette structure, et (via le package compagnon teal.modules.clinical) déposer des modules qui produisent les sorties cliniques standard qu’un relecteur attend.

teal a été open-sourcé par F. Hoffmann-La Roche / Genentech, construit par leur équipe Insights Engineering sous le nom de projet NEST (une suite de packages R pour le reporting clinique), et fait partie de la famille pharmaverse de packages R cliniques open source. Parce que c’est un framework Roche sans équivalent dans la stack R de base, c’est le bon outil à saisir ici — inutile de bricoler à la main une application de revue quand teal existe. La documentation complète se trouve sur le site du package teal et sur CRAN.

Le modèle mental : données + modules + un panneau de filtres

Chaque application teal, ce sont les trois mêmes ingrédients, combinés par une seule fonction :

Données — un ou plusieurs jeux de données, enveloppés pour que teal puisse les suivre et les filtrer.
Modules — une liste des vues d’analyse que vous voulez dans l’application.
Un panneau de filtres — la barre latérale partagée que teal construit pour vous ; y filtrer sous-ensemble chaque module à la fois.

Vous les combinez avec teal::init(data =, modules =), qui renvoie un objet application Shiny, et vous la lancez avec shinyApp(). Voici la plus petite application teal possible — la forme de démarrage (c’est exactement ce que fait tourner la démo publique ci-dessous) :

library(teal)

app <- init(
  data = teal_data(IRIS = iris, MTCARS = mtcars),
  modules = modules(example_module())
)

shinyApp(app$ui, app$server)

Lisez-la de haut en bas. teal_data() enregistre deux jeux de données (IRIS et MTCARS) pour que teal puisse les filtrer et suivre leur provenance. modules() contient la liste des vues — ici un seul example_module(), un module de démonstration intégré. init() assemble l’application, et shinyApp() la fait tourner. Voilà une application teal complète et fonctionnelle en cinq lignes : pas de code UI, pas de serveur réactif, pas de logique de filtrage écrite à la main. teal a tout fourni.

Les pièces que vous permutez pour faire une vraie application sont l’enveloppe de données et la liste de modules. Pour des données cliniques, vous permutez teal_data() pour cdisc_data() (qui comprend les clés CDISC), et vous permutez le module de démonstration pour les modules cliniques de la section suivante.

Note

Le code teal de cette page est illustratif et conforme à l’API, mais il n’est pas exécuté ici — teal est une application Shiny complète, pas quelque chose qui tourne dans une page statique. Pour le voir en direct, installez teal et exécutez ces extraits dans une session R locale, ou ouvrez l’application de démonstration de la section suivante.

teal.modules.clinical : les modules cliniques préconçus

Le package teal.modules.clinical est une bibliothèque de modules teal prêts à l’emploi pour les sorties cliniques standard, construits sur le même moteur rtables/tern qui produit les tableaux de soumission. Vous n’écrivez pas ces vues — vous les configurez. Les plus courants :

Module	Ce qu’il produit
`tm_t_summary`	Tableau de synthèse / démographique (une Table 1)
`tm_g_km`	Graphique de survie de Kaplan-Meier (KM)
`tm_t_events`	Tableau des événements indésirables (AE) — décomptes des événements indésirables
`tm_t_events_summary`	Tableau de synthèse des événements indésirables
`tm_g_forest_tte`	Forest plot pour un critère de délai jusqu’à l’événement
`tm_a_mmrm`	Analyse MMRM (modèle mixte pour mesures répétées)
`tm_t_tte`	Tableau de délai jusqu’à l’événement (estimations de survie)
`tm_t_coxreg`	Tableau de régression de Cox

Important

tm_t_events est le tableau des événements indésirables, pas un module de délai jusqu’à l’événement. Le tableau de délai jusqu’à l’événement est tm_t_tte et le graphique de Kaplan-Meier est tm_g_km. Le _events dans le nom signifie événements indésirables — ne confondez pas les deux quand vous choisissez un module.

Voici une application clinique : un module, un tableau démographique, construit sur un vrai jeu de données ADaM d’exemple au niveau sujet (tmc_ex_adsl, livré avec le package). Notez la forme de la configuration — les modules cliniques prennent des specs choices_selected() (un ensemble de colonnes autorisées plus la sélection par défaut), pas des noms de colonnes bruts, pour que le relecteur puisse changer les variables depuis l’application en cours d’exécution :

library(teal.modules.clinical)

ADSL <- tmc_ex_adsl   # an example subject-level ADaM dataset shipped with the package

app <- init(
  data = cdisc_data(
    ADSL = ADSL,
    code = "ADSL <- tmc_ex_adsl"   # the code that recreates the data — teal reports it
  ),
  modules = modules(
    tm_t_summary(
      label    = "Demographic Table",
      dataname = "ADSL",
      arm_var  = choices_selected(choices = c("ARM", "ARMCD"), selected = "ARM"),
      summarize_vars = choices_selected(
        choices  = c("SEX", "RACE", "BMRKR2", "EOSDY", "DCSREAS", "AGE"),
        selected = c("SEX", "RACE")
      )
    )
  )
)

shinyApp(app$ui, app$server)

Deux choses à remarquer. cdisc_data() remplace teal_data() — il enregistre le jeu de données ADaM avec ses clés CDISC pour que le panneau de filtres sous-ensemble correctement par sujet. Et l’argument code = enregistre comment les données ont été fabriquées : teal le garde dans la piste reproductible de l’application, pour que le bouton Show R code puisse remettre au relecteur le script complet qui recrée chaque vue.

Pour faire grandir l’application, vous ajoutez d’autres modules à la liste modules() — un tm_g_km() pour la courbe de Kaplan-Meier, un tm_t_events() pour le tableau des AE, un tm_g_forest_tte() pour un forest plot — chacun configuré avec le même motif choices_selected(). Chacun devient un onglet dans l’application en cours d’exécution, et tous répondent à l’unique panneau de filtres partagé.

À quoi ressemble une application teal en cours d’exécution

Le schéma en haut de cette leçon est la coquille de l’application. Parcourez ses quatre régions, car elles sont toute l’interface :

Le panneau de filtres (à gauche). teal le construit pour vous à partir des données. Son Active Data Summary montre combien de lignes survivent aux filtres actuels par rapport au total (p. ex. ADSL 95 / 306), et en dessous se trouve une carte de filtre par variable que vous exposez — faites glisser un curseur ou cochez une catégorie et chaque module se met à jour à la fois. Ce filtrage partagé est la fonctionnalité que vous devriez sinon écrire à la main en Shiny brut.
Les onglets de modules (volet principal). Chaque module de votre liste modules() est un onglet — Démographie, Kaplan-Meier, Événements indésirables. Cliquez sur un onglet pour voir cette analyse, rendue à partir des données actuellement filtrées.
Le sélecteur de jeu de données + les sélecteurs de variables. Parce que vous avez passé des specs choices_selected(), le relecteur peut changer la variable de traitement ou les variables résumées depuis l’application — pas de code, pas de relance.
Show R code / Add to Report. Chaque vue porte un bouton Show R code qui émet le R exact qui l’a produite (la garantie de reproductibilité), et un bouton + Add to Report qui collecte les vues dans un rapport téléchargeable via teal.reporter.

Le moyen le plus rapide de sentir le modèle est d’en ouvrir une en direct :

Lancez une application teal en direct

Ouvrez la démo teal de base ▸ — une instance teal publique faisant tourner l’application de démarrage sur les données d’exemple iris et mtcars. C’est une démo basique, pas une application clinique, mais elle montre la coquille exacte décrite ici : le panneau de filtres à gauche, les onglets de modules dans le volet principal, le sélecteur de jeu de données et le bouton Show R code. Filtrez à gauche et regardez le module se mettre à jour ; cliquez sur Show R code pour voir le script reproductible que teal a généré.

Où teal s’insère dans le workflow de revue clinique

Vos sorties de soumission — les tableaux, listings et figures (TLF) — sont fixes : un ensemble défini de sorties programmées, validées et versionnées. teal est la couche interactive autour d’elles. Un moniteur médical ou un statisticien utilise une application teal pour explorer — découper par sous-groupe, vérifier une courbe pour une population filtrée, retrouver les événements indésirables d’un patient — avant, pendant et après la production des sorties formelles. Les deux sont complémentaires : les TLF statiques sont l’enregistrement ; teal est le bac à sable.

Face au Shiny écrit à la main, teal gagne sa place sur trois points :

Modules préconçus. teal.modules.clinical vous donne les vues démographie, KM, AE, forest et MMRM prêtes à l’emploi — vous configurez, vous ne les codez pas.
Un panneau de filtres partagé. teal génère la barre latérale de filtrage des données et l’applique à travers chaque module. En Shiny brut, vous écririez cette réactivité vous-même, par application.
Reproductibilité intégrée. Show R code rend chaque vue auditable — essentiel quand un relecteur en contexte réglementé doit faire confiance à ce qu’une application lui montre.

Le compromis est qu’une application teal est une session R/Shiny en cours d’exécution, pas un artefact statique comme le reste des sorties de ce pilier. Elle a besoin d’un serveur Shiny (ou d’une session R locale) pour tourner — ce qui est exactement pourquoi cette leçon livre le code sous forme d’extraits illustratifs plus une démo hébergée, plutôt qu’une application en direct intégrée.

🟢 Avec un agent IA

Demandez à Prova « Assemble une application teal pour mes données ADaM avec un tableau démographique et un module Kaplan-Meier — montre-moi l’appel init(), l’enveloppe cdisc_data(), et la configuration de tm_t_summary et tm_g_km. » — elle répond en s’appuyant sur les leçons de ce pilier, avec du code teal conforme à l’API que vous pouvez exécuter dans une session R locale. The runtime is the judge. Demandez à Prova →

Problèmes fréquents

Essayer d’écrire du Shiny à la main à l’intérieur de teal. teal est un framework d’assemblage — vous passez une liste de modules à init(), vous n’écrivez pas de fonctions ui/server comme vous le feriez pour une application Shiny brute. Si vous vous surprenez à écrire des blocs renderPlot() et reactive(), prenez du recul : saisissez un module existant de teal.modules.clinical (ou le teal.modules.general généraliste), ou enveloppez votre logique personnalisée dans un module avec teal::module() — ne contournez pas le framework.

Étiqueter à tort tm_t_events comme délai jusqu’à l’événement. Le _events dans tm_t_events signifie événements indésirables, et le module construit un tableau d’AE (événements indésirables). Le tableau de délai jusqu’à l’événement est tm_t_tte, et le graphique de survie de Kaplan-Meier est tm_g_km. Choisir tm_t_events quand vous vouliez une analyse de survie est une erreur de débutant courante — vérifiez la référence du module avant de le câbler.

S’attendre à ce qu’une application teal soit statique comme le reste du package. Contrairement à un tableau rtables ou à une figure survminer, une application teal est une application Shiny en direct : elle a besoin d’une session R en cours d’exécution ou d’un serveur Shiny. Vous ne pouvez pas l’intégrer dans un rapport statique ou une page indexable — vous la déployez (shinyapps.io, Posit Connect, ou un serveur Shiny interne) ou vous la faites tourner localement. Prévoyez une cible d’hébergement, pas un fichier.

Questions fréquentes

Qu’est-ce que teal en R ?

teal est un package R issu du projet NEST de Roche (partie de pharmaverse) pour construire des applications web interactives qui explorent les données d’essais cliniques. Son titre CRAN est « Exploratory Web Apps for Analyzing Clinical Trials Data ». Vous construisez une application teal en donnant à init() vos données et une liste de modules (des vues d’analyse préconçues) ; teal fournit le panneau de filtres partagé, l’UI et une piste reproductible Show R code. Il est construit sur Shiny mais vous épargne d’écrire du Shiny brut.

Comment construire une application de revue clinique en R ?

Utilisez teal avec teal.modules.clinical. Enveloppez vos jeux de données ADaM avec cdisc_data(), listez les modules cliniques voulus — par exemple tm_t_summary() pour la démographie et tm_g_km() pour une courbe de Kaplan-Meier — passez-les à init(data =, modules = modules(...)), et lancez avec shinyApp(app$ui, app$server). Configurez chaque module avec choices_selected() pour que les relecteurs puissent changer les variables depuis l’application en cours d’exécution. Vous assemblez l’application à partir de modules au lieu de coder l’UI et le serveur à la main.

teal vs Shiny : quelle est la différence ?

Shiny est le framework d’applications web R généraliste — vous écrivez vous-même l’UI et le serveur réactif. teal est un framework construit sur Shiny pour un travail précis : explorer les données d’essais cliniques. teal vous donne des modules d’analyse préconçus, un panneau de filtres partagé, une gestion des données consciente de CDISC et une piste de reproductibilité Show R code, le tout assemblé par init(). Choisissez Shiny brut pour une application entièrement personnalisée ; choisissez teal quand vous voulez des vues standard de revue clinique assemblées vite et de façon reproductible.

Qu’est-ce que teal.modules.clinical ?

C’est le package R compagnon qui livre des modules teal cliniques préconçus, construits sur le moteur de tableaux rtables/tern. Il inclut la démographie (tm_t_summary), Kaplan-Meier (tm_g_km), les tableaux d’événements indésirables (tm_t_events), les forest plots (tm_g_forest_tte), MMRM (tm_a_mmrm), les tableaux de délai jusqu’à l’événement (tm_t_tte), la régression de Cox (tm_t_coxreg) et davantage. Vous ajoutez ces modules à la liste modules() d’une application teal et vous les configurez avec des specs choices_selected() — vous ne programmez pas les sorties vous-même.

Puis-je déployer une application teal ?

Oui. Une application teal est un objet application Shiny standard, elle se déploie donc partout où Shiny se déploie : shinyapps.io, Posit Connect, Shiny Server, ou un conteneur interne. init() renvoie une application avec $ui et $server, et shinyApp(app$ui, app$server) la fait tourner — le même objet que vous déployez. Parce qu’une application teal a besoin d’une session R en direct, elle est hébergée et exécutée, pas intégrée comme un fichier statique.

Testez vos connaissances

À votre tour : ajoutez un module Kaplan-Meier à une application teal clinique

En partant de l’application démographique ci-dessus, ajoutez un module Kaplan-Meier (KM) pour un jeu de données de délai jusqu’à l’événement. Le module KM est tm_g_km() ; il a besoin d’un dataname pointant vers un jeu de données ADaM de délai jusqu’à l’événement (un jeu de données de type ADTTE — un enregistrement d’analyse par sujet par critère) et d’un arm_var. Ajoutez-le à la liste modules() pour que l’application en cours d’exécution gagne un second onglet.

Indice

Les modules vont dans la liste modules() passée à init() — séparez-les par des virgules. Enregistrez le second jeu de données dans cdisc_data() aux côtés d’ADSL, puis ajoutez tm_g_km(label = ..., dataname = "ADTTE", arm_var = choices_selected(...)) comme second élément de modules(). Comme chaque module clinique, tm_g_km() prend des specs choices_selected(), pas des noms de colonnes bruts.

Solution

library(teal.modules.clinical)

ADSL  <- tmc_ex_adsl
ADTTE <- tmc_ex_adtte   # an example time-to-event ADaM dataset shipped with the package

app <- init(
  data = cdisc_data(
    ADSL  = ADSL,
    ADTTE = ADTTE,
    code  = "ADSL <- tmc_ex_adsl\nADTTE <- tmc_ex_adtte"
  ),
  modules = modules(
    tm_t_summary(
      label    = "Demographic Table",
      dataname = "ADSL",
      arm_var  = choices_selected(choices = c("ARM", "ARMCD"), selected = "ARM"),
      summarize_vars = choices_selected(
        choices  = c("SEX", "RACE", "AGE"),
        selected = c("SEX", "RACE")
      )
    ),
    tm_g_km(
      label    = "Kaplan-Meier Plot",
      dataname = "ADTTE",
      arm_var  = choices_selected(choices = c("ARM", "ARMCD"), selected = "ARM")
    )
  )
)

shinyApp(app$ui, app$server)

L’application a maintenant deux onglets — le tableau démographique et la courbe de Kaplan-Meier — et les deux répondent à l’unique panneau de filtres partagé. Ajouter une vue d’analyse signifie ajouter un élément de plus à modules() ; vous ne touchez jamais à une fonction UI ou serveur.

Vérification rapide : quels sont les trois ingrédients d’une application teal ?

A. Une fonction UI, une fonction serveur et un bloc reactive() que vous écrivez à la main. B. Des données (via teal_data()/cdisc_data()), une liste de modules et un panneau de filtres partagé — assemblés par init(). C. Un fichier .qmd statique, un objet rtables et un Define-XML.

Afficher la réponse

B. Une application teal, c’est données + modules + un panneau de filtres, combinés par init() et lancés avec shinyApp(). A décrit du Shiny brut — le code que teal écrit pour vous. C décrit des artefacts de soumission statiques, qui sont un autre travail : teal est la couche d’exploration interactive, pas une sortie statique.

Conclusion

teal transforme « construire une application de revue pour cette étude » d’un projet Shiny sur mesure en un travail d’assemblage : donnez à init() vos données, listez les modules voulus, et teal fournit le panneau de filtres partagé, l’UI et une piste reproductible Show R code. Avec teal.modules.clinical, ces modules sont les sorties cliniques standard déjà construites — démographie, Kaplan-Meier, événements indésirables, forêt, MMRM — configurées avec des specs choices_selected() plutôt que codées de zéro. Il se place autour de vos tableaux, listings et figures fixes comme la couche d’exploration interactive, et parce que c’est un framework Roche/pharmaverse sans équivalent dans la stack de base, c’est le bon outil à saisir quand un relecteur a besoin d’explorer les données d’essais cliniques.

Note

Le code teal de cette page est illustratif et conforme à l’API — il n’est pas exécuté dans cette leçon statique, parce qu’une application teal est une application Shiny complète plutôt qu’un bloc de code exécutable. Pour le voir fonctionner, installez teal et teal.modules.clinical et exécutez ces extraits dans une session R locale, ou ouvrez la démo en direct ci-dessus.

Références

Documentation du package teal — le framework : init(), teal_data(), le panneau de filtres, et comment écrire votre propre module.
teal sur CRAN — « Exploratory Web Apps for Analyzing Clinical Trials Data ».
Documentation de teal.modules.clinical — les modules cliniques préconçus (tm_t_summary, tm_g_km, tm_t_events, tm_g_forest_tte, tm_a_mmrm, et davantage).
teal.modules.clinical sur CRAN — le package des modules cliniques.
pharmaverse — l’écosystème de packages R open source pour le reporting clinique auquel teal et teal.modules.clinical appartiennent.
Application de démo teal de base — une instance teal publique montrant la coquille de l’application sur les données d’exemple iris/mtcars.

Leçons connexes

Le tableau démographique avec rtables — la Table 1 statique que tm_t_summary produit de manière interactive ; le même moteur rtables en dessous. · La figure de Kaplan-Meier avec survminer — la courbe de survie derrière le module tm_g_km. · Le tableau des événements indésirables — le tableau d’AE que tm_t_events construit. · Construire le jeu de données ADTTE de délai jusqu’à l’événement — l’ADaM de délai jusqu’à l’événement qu’un module tm_g_km lit. · Créer l’ADSL avec admiral — le jeu de données au niveau sujet qu’une application de revue teal filtre.
Où cela s’insère : dériver les jeux de données ADaM → programmer les tableaux, listings et figures fixes → assembler une application de revue teal interactive autour d’eux (vous êtes ici). · Revue clinique avec teal — 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 = {Revue clinique interactive avec teal : créer des applications
    de données d’essais cliniques en R},
  date = {2026-07-01},
  url = {https://www.datanovia.com/learn/pharma-clinical/06-teal-review-apps/interactive-clinical-review-teal},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“Revue clinique interactive avec teal : créer des applications de données d’essais cliniques en R.” 2026. July 1. https://www.datanovia.com/learn/pharma-clinical/06-teal-review-apps/interactive-clinical-review-teal.