The Missing Standard

CDISC released the Population Pharmacokinetic (PopPK) Implementation Guide in 2023, giving the clinical programming community a clear structural blueprint for PK analysis datasets. But Exposure-Response (ER) modeling — which builds directly on PopPK outputs to characterize relationships between drug exposure, safety, and efficacy — has no equivalent standard.

The result is predictable: different studies, different variable names, different exposure metrics, different dataset structures. Every ER analysis team starts more or less from scratch. That makes cross-study pooling, automation, and programming more difficult than necessary, particularly with ever-quickening turnaround times in drug development.

A Framework Built on What We Already Have

ER datasets share a lot of structural DNA with PopPK datasets — numeric covariates, relative time variables, pharmacokinetic exposure metrics. That overlap is the starting point for this framework: extending CDISC ADaM principles already established for PopPK into the ER space.

Early discussions are underway with the CDISC ADaM working group about moving this framework forward as a Knowledge Article or Examples Document. The working group has expressed interest in positioning ER datasets as a subclass of ADPPK — grounding the framework within existing CDISC standards architecture and providing a clear lineage from the 2023 PopPK Implementation Guide. Nothing is formalized yet, but the direction is encouraging.

The result of the new framework is four specialized datasets, each targeting a different aspect of ER analysis:

Each dataset builds on standard ADaM datasets (ADSL, ADRS, ADTTE, ADAE, ADLB, ADVS) and incorporates PK parameters from ADPC/ADPP, producing analysis-ready datasets without additional data wrangling.

The framework was presented as paper DS12 at PHUSE US Connect 2026 in Austin, TX. The paper and slides are now available in the PHUSE archive.

Why the Pharmaverse Ecosystem?

The framework is implemented using {admiral}, {metacore}, {metatools}, and {xportr} — the same toolchain used across the pharmaverse for ADaM dataset development. That choice was intentional.

{admiral}’s modular derivation functions map naturally onto how ER datasets are built incrementally. Its assert_* functions catch errors at the point of derivation rather than burying them downstream. {metacore} keeps specs and code in sync. {metatools} provides utility functions for metadata management and validation. {xportr} handles CDISC compliance at the point of export.

The pharmaverse ecosystem did not just make implementation easier — it made the framework more trustworthy and maintainable. And because it is open-source, every improvement feeds back to the community.

The Examples Page

The working R code is now live on the pharmaverse examples site.

The ADER+ page covers all four datasets in a single tabbed page, with:

• A shared introduction explaining the ER framework and its relationship to the PopPK Implementation Guide
• Common derivations used across all four datasets
• Dataset-specific derivation code for ADER, ADEE, ADES, and ADTRR
• Full variable listings and metadata

The code uses {pharmaverseadam} as source data, making it immediately reproducible. Think of it as a template — a starting point you can adapt for your own studies.

We Need Your Feedback

This framework is a proposal, not a finished standard. Any formal ER ADaM standard would ultimately be owned and ratified by CDISC — the community can propose, pilot, and advocate, but the path to an official standard requires active collaboration with CDISC. The groundwork for that is community validation: pilot testing across therapeutic areas, working group discussion, and real-world use.

That means we need two kinds of input:

Clinical programmers — try the code. Does the derivation logic hold up? What edge cases are we missing? Open an issue or PR on the pharmaverse examples repository.

ER modelers and pharmacometricians — this one is especially for you. Does this dataset structure actually serve your modeling needs? Are the exposure metrics the right ones? Is the dataset grain appropriate for the analyses you run? You are the end users of these datasets, and your perspective is exactly what’s needed to make this framework scientifically sound, not just technically compliant.

The discussion is open. Let’s keep it going.

Introduction

AI coding assistants are becoming a natural part of how clinical R programmers work — autocompleting functions, suggesting test cases, drafting derivations. But out of the box, these agents know nothing about ADaM conventions, CDISC standards, or how the pharmaverse ecosystem fits together. They don’t know that analysis flag variables such as ANL01FL typically take "Y" or NA and not "N" They don’t know that {pharmaversesdtm} is the canonical source of test SDTM data, or that {xportr} is waiting downstream to turn your dataset into a submission-ready XPT file. AGENTS.md is a simple, open standard that changes that — and the {admiral} ecosystem now has infrastructure to generate and maintain these files automatically across every package in the family.

What Is AGENTS.md?

AGENTS.md is a plain markdown file you commit to your repository that gives AI coding agents the context they need to work correctly in your project. Think of it as a README for agents — while README.md tells a new developer what the project is, AGENTS.md tells an AI assistant how to work in it correctly.

The format is supported across the growing ecosystem of AI coding tools: OpenAI Codex, GitHub Copilot, Google’s Jules, Cursor, Aider, Gemini CLI, and more. One file, version-controlled alongside your code, works everywhere.

Why This Matters for the pharmaverse

ADaM derivations encode decades of CDISC regulatory expectations that don’t appear anywhere in the R syntax. The fact that ANL01FL is an analysis flag with specific derivation logic, that DTYPE = "LLOQ" imputation records follow specific rules — none of this is inferable from the code alone.

The {admiral} package also doesn’t exist in isolation. It operates in a pipeline that flows from {pharmaversesdtm} test data through admiral derivations, often guided by {metacore} specifications, and ultimately out through {xportr} to submission-ready XPT files. An agent writing admiral code without that context is like a new programmer who only knows the function they’re editing — not the system it belongs to.

An AGENTS.md in an admiral-family repository can communicate all of this before the agent writes a single line of code.

A First Step in the pharmaverse AI Strategy

The {admiral} team is actively discussing how to formalize its approach to AI-assisted development — what tools to encourage, what guardrails to put in place, and how to document AI’s role in the programming strategy. That conversation is still early, and deliberately so: the consensus is to gain real experience before locking in formal guidance.

The good news is that experience is already arriving, fast.

March 7, 2026 — the question arrives. PR #2996 landed from a new contributor, maxthecat2024, fixing poorly formatted warning messages in derive_param_computed(). The PR was thorough and well-structured — detailed before/after examples, snapshot test conversions, a fully completed checklist. It was also the kind of contribution that made the team wonder: was this an AI bot? We don’t know for certain, and ultimately it didn’t matter — the code was good and it got merged. But the question itself was telling.

March 17, 2026 — the reality arrives. PR #3010 was opened not by a human contributor, but by GitHub Copilot itself — the branch named copilot/enhance-examples-derive-vars-merged-summary, the author listed as Copilot. The PR enhanced documentation examples for derive_vars_merged_summary(), correctly picking up the admiral-specific @examplesx structured example pattern from the existing codebase — context that came directly from AGENTS.md.

But the PR also revealed an important limitation. Rather than running devtools::document() to regenerate the .Rd file, Copilot manually edited man/derive_vars_merged_summary.Rd directly — and its own PR description acknowledged this: “Manually updated to match roxygen2::roxygenize() output.” When a reviewer pointed this out, Copilot responded candidly: “R is not available in my sandbox environment, so I can’t execute devtools::document() directly. For future sessions, I understand the correct workflow.” A human reviewer ran devtools::document() outside the sandbox and pushed the correctly generated .Rd file in commit c855860.

This is an important nuance: the issue wasn’t that AGENTS.md was unclear — it was that Copilot’s execution environment simply didn’t have R available. No instruction, however well-written, can make an agent run a command it physically cannot execute. AGENTS.md can teach an agent the correct workflow; ensuring the environment supports that workflow is a separate, human-owned responsibility. That distinction matters as the community develops its AI strategy.

This two-week window tells the whole story. AI-assisted contributions are already arriving in the {admiral} repository. AGENTS.md is already helping agents understand project-specific conventions. And the gaps it exposes are already informing improvements. This is the feedback loop the community needs to build a thoughtful AI strategy — not speculation, but evidence.

AGENTS.md represents the first tangible infrastructure to come out of that thinking. Whether a contributor is a human using an AI assistant, an autonomous agent, or something in between — the code still needs to follow ADaM conventions and pharmaverse standards. AGENTS.md helps ensure it does.

If you have thoughts on what the broader strategy should look like, the discussion is open — join the conversation at admiraldev issue #547. The broader scientific open-source community is working through similar questions: rOpenSci recently published an AI policy that’s worth reading as a reference point for how these norms are taking shape. Notably, rOpenSci’s policy calls out agents.md directly in its software review submission template:

“If your repository includes an ‘agents.md’ file or equivalent, please provide a link, and describe how this has been used in the development of your package.”

That the broader open-source scientific community is already asking for AGENTS.md as part of peer review is a signal that this norm is catching on fast.

The Admiral Ecosystem Implementation

Rather than each package maintaining its own file by hand, the generation logic is centralized in {admiralci} and delivers a consistent, up-to-date file to every package that opts in. The workflow pulls together content from several sources:

• Programming strategy and unit testing guidelines from {admiraldev}
• Package-specific context from a YAML file in each repository (therapeutic area, related packages, relevant CDISC IGs)
• Ecosystem context describing how admiral-family packages fit into the broader pharmaverse pipeline
• ADaM fundamentals covering key variable conventions and controlled terminology patterns

The {admiral} AGENTS.md is substantial — over 1,300 lines of auto-generated context pulled directly from the {admiraldev} programming strategy, git usage, and R CMD check vignettes. It even includes a built-in verification mechanism: agents are instructed to add the comment # admiral guidelines loaded to the first line of every new R file they create, confirming the guidelines were actually read. It’s a small but clever way to make agent compliance observable during code review.

Here’s a simplified illustration of the kind of content the file contains:

# AGENTS.md — admiral

## Package Overview
{admiral} provides a toolbox for ADaM dataset construction in R,
following CDISC ADaM standards and pharmaverse conventions.

## ADaM Conventions
- Flag variables (ANL01FL, SAFFL, etc.) take values "Y" or NA
- PARAM/PARAMCD pairs must align with CDISC controlled terminology
- ASEQ must be derived as the last step before dataset finalization

## Ecosystem Context
- Test SDTM data: use {pharmaversesdtm} (CDISC pilot data)
- Downstream: datasets consumed by {xportr} for XPT transport files
- Metadata: {metacore}/{metatools} provide spec-driven variable control

## Unit Testing
- Use {testthat} with expect_dfs_equal() for dataset comparisons
- Every new function requires tests for typical use, edge cases, and errors

## Documentation
- Run devtools::document() to regenerate .Rd files — never edit man/ directly
- Update NEWS.md for any user-facing function changes

One practical note: AGENTS.md at the repository root triggers a NOTE in R CMD check, so the file is added to .Rbuildignore. It also lives in tests/testthat/ where testing-specific guidance is scoped closest to where it’s needed. Extension packages like {admiralonco}, {admiralvaccine}, and {admiralpeds} can layer their own context on top, adding therapeutic area-specific conventions without duplicating shared infrastructure content.

How to Adopt This in Your Package

If you maintain an admiral-family package, adoption is three steps:

1. Add a YAML configuration file to your repository with package-specific context (therapeutic area, related packages, relevant CDISC IGs)
2. Reference the reusable workflow from {admiralci} in your .github/workflows/ directory
3. Add ^AGENTS\.md$ to your .Rbuildignore

The workflow then runs on a schedule, pulling the latest content from {admiraldev} and your package YAML and committing an updated AGENTS.md automatically.

Resources

• AGENTS.md standard: https://agents.md
• {admiral} AGENTS.md (live): https://github.com/pharmaverse/admiral/blob/main/AGENTS.md
• {admiral} sync-admiralci-agents workflow (live): https://github.com/pharmaverse/admiral/blob/main/.github/workflows/sync-admiralci-agents.yml
• pharmaverse AI strategy discussion: https://github.com/pharmaverse/admiraldev/issues/547
• pharmaverse examples site: https://pharmaverse.github.io/examples/
• rOpenSci AI policy: https://ropensci.org/blog/2026/02/26/ropensci-ai-policy/

The humble View() and its limits

View() has served R programmers well for a long time — pass it a data frame, get a spreadsheet-style window. It even has a basic search bar for checking whether a value exists in your data. But the moment you need something more precise — filter by a specific column or combine conditions — you are back in your script.

Add to that: no side-by-side dataset comparison, no metadata inspection, and no way to carry your exploration into reproducible code. For day-to-day clinical data work — reviewing your clinical datasets, let’s say ADSL, cross-checking subject demographics against lab data in ADLB, doing a QC pass before analysis — these gaps add up.

What is dataviewR?

dataviewR is a Shiny-based interactive data viewer that works alongside View() as a companion — not a replacement. It launches directly in your RStudio Viewer pane, requires no Shiny code, and never modifies the datasets passed to it.

install.packages("dataviewR")

Features

dataviewR offers the following capabilities:

• Interactive Filtering — apply dplyr-style expressions directly in the app, no script changes needed. Supports %in%, is.na(), grepl(), and compound conditions — the same syntax you already write every day.

SEX == "F" & AGE > 65 & TRT01P == "Xanomeline High Dose"

• Reproducible Code Generation — hit “Generate R Code” and walk away with ready-to-use dplyr code from your interactions. Your exploration session feeds directly into your scripted workflow.

• Variable Metadata — inspect variable classes, labels and attributes without writing str() or attr() calls. Particularly useful for clinical datasets where CDISC-style labels are carried as R attributes.

See all of this in action:

Cross-Checking Multiple Datasets

But what if you need to look at more than one dataset at the same time? dataviewR handles that too — pass multiple datasets in a single call and each opens in its own tab within the same session. Switch between them, filter independently, and track a specific subject across datasets — the kind of check that comes up in every safety review.

library(dataviewR)
library(pharmaverseadam)

dataviewer(adsl, adlb)

Final Thoughts

That is dataviewR in a nutshell. Try it out and share your thoughts on GitHub or pharmaverse Slack!

Full documentation, vignettes, and clinical dataset examples are available at madhankumarnagaraji.github.io/dataviewR.

Why this matters for pharmaverse programmers

Clinical reporting is built on repeatable patterns for ADaM derivations, TLGs, and QC, but finding these patterns is a significant challenge. Relevant code is often scattered, and traditional keyword searches fail for non-standard logic because the underlying variable names and structural conventions differ from study to study. CSA directly addresses this root cause by using semantic retrieval to find code based on its conceptual intent, not just matching keywords (e.g: plain English query such as “derive ABLFL in ADLB using a pre-dose baseline rule and analysis-visit windows”). This means programmers can reliably discover, review, and reuse relevant patterns from across all repositories, saving substantial time and ensuring greater consistency in their work.

What we built?

CSA is a focused agent inside our Clinical Analysis Assistant. A user asks a question; we create an embedding of that query, apply optional metadata filters, search the vector database, and return the most relevant code chunks alongside their origins. CSA supports both SAS and R programs.

Behind the scenes, we index code from our repositories, split it into coherent chunks, and generate short summaries that describe what each piece of code does. We then convert these summaries into numerical representations called embeddings (or vectors), which capture their semantic meaning. This allows the system to find code based on the idea of what it does, not just keyword matching. We store these vectors in a specialized database (vector database) and retain rich metadata such as programming language, file name, repository, and study description. The interface displays both the results and the parameters used so retrieval stays transparent and audit-friendly.

Here is an example of chunk and its metadata stored in the vector database.

How it works

Example

What programmers can do today

With CSA, programmers can look up ADaM and TLG scripts by intent, such as “asking for an ADSL baseline flag with visit windowing” or “an AVALC mapping that treats missing values explicitly”. They can locate TLG programs described in plain English. For instance, a table that splits columns by treatment arm and summarizes AVAL with mean and standard deviation and then adapt a proven layout. They can also compare similar implementations across repositories to converge on a standard approach while maintaining confidence through clear provenance back to source.

Metrics and usage

Over the observation window (15th of September 2025 - 19th of October 2025), the Code Search Assistant (CSA) handled 791 questions from 45 unique users, averaging 42 ± 14 weekly conversations and 92 ± 43 weekly questions. Satisfaction signals were positive: the broader Clinical Analysis Assistant (CAA) scored 3.39/5 for usefulness (n = 174), while the CSA specifically was rated at ~4/5, indicating strong early traction among active users.

Limitations & what’s next

Today, CSA focuses on fast, trustworthy discovery. We are working on tighter IDE integration via MCP (Model Context Protocol - introduced by Anthropic) so you can search directly from your code editor (VSCode, RStudio, etc.). We also want to enable better study awareness so results are automatically filtered to the context of your study and clinical programming code. Finally, we are refining the data pipeline to continuously index changes without any manual effort and adding SDTM programs as well. These steps aim to make retrieval not only smarter but also more seamlessly woven into day-to-day programming.

OS Software Solutions Pillar

Firstly, if you’re reading this wondering what do we mean by a “pillar” then check our introductory blog here.

Our OS Software Solutions pillar aims to ensure the industry has a curated ecosystem of open source solutions* useful for reporting and submission of clinical data and analyses.

* R, python, or other languages

To achieve this we have agreed on 3 focus areas:

• Pharmaverse OSS suite – oversee what we include/exclude and monitor feedback and sustainability

• Our development teams – offer support, e.g. helping bring more contributors / hackathons

• Industry adoption – advising on pathways to increase industry usage, e.g. continued maintenance of our examples page

Hi pharmaverse community!

Big news from the council: after our late‑2025 strategy session, we’ve formalized the pharmaverse pillars for 2026 — a friendly framework to give clearer direction, focus effort, and help members plug in where they can make the biggest impact.

To start, we thought about…

The Smallest Contribution You’re Probably Not Making

You’ve used {admiral} to derive your ADSL. You’ve leaned on {metacore} to wrangle your metadata. You’ve validated your XPT files with {xportr} and scored your package risk with {riskmetric}. These tools have saved you hours, reduced errors, and helped you build CDISC-compliant submissions that you can be proud of.

So let me ask you a direct question: have you starred those repositories on GitHub?

If the honest answer is no, you’re not alone — and this post is for you.

What Is a GitHub Star, Really?

On the surface, a GitHub star looks like a simple bookmarking mechanism. You click the ⭐ button on a repository, and it gets added to your “starred” list for easy retrieval later. Simple enough.

But in the open-source world, stars are much more than bookmarks. They are a public signal of trust, adoption, and community health. They are the currency through which the broader developer ecosystem evaluates whether a project is worth its attention. And in the pharmaverse — where we are actively working to prove to regulators, IT departments, company leadership, and the broader pharmaceutical industry that open-source R tools are production-ready — that signal matters enormously.

Why Stars Matter More Than You Think

The Visibility Gap

Here’s the honest reality: pharmaverse packages are used far more than their star counts suggest. Many clinical programmers access these tools through internal environments where GitHub access is limited or indirect, deriving real value without ever navigating to the source repository. Stars only reflect the people who made it to the repo — and we can do better.

What You Can Do Right Now

If you use any of the following packages, please take 60 seconds and star their repositories:

You can also see many pharmaverse packages in action in the pharmaverse examples site pharmaverse/examples which you can also star!

Starring a repository requires a free GitHub account. If you don’t have one, creating one takes about two minutes and is well worth it — it also opens the door to participating more directly in the community through issue reports, discussions, and eventually contributions.

Make It a Habit

The best time to star a repository is when you first discover that a package solves a problem you have. The second best time is right now.

I’d encourage you to take a few minutes today to review which pharmaverse tools are part of your workflow and star the ones you haven’t yet. Then consider sharing this post with a colleague who you know depends on these tools but may not have thought about GitHub engagement before.

The pharmaverse has grown into something remarkable — a genuine, cross-industry collaboration that is reshaping how clinical data science is practiced. It runs on contributions, and those contributions take many forms. Code, documentation, issue reports, and conference presentations are all vital. But so is the quietest contribution of all: clicking ⭐ to say I use this, I value this, and I want it to keep growing.

✨ What’s New in 1.4.0

📦 Installation

You can install pharmaversesdtm 1.4.0 from CRAN:

install.packages("pharmaversesdtm")

Streamlining Our Pharmaverse Blog: Reducing Publishing Time with containers

As an active contributor to the pharmaverse blog, I’ve always appreciated the opportunity to share new insights and tools with our community. The pharmaverse blog has some interesting features for publishing. While the blog publishing process has been effective, I was wondering if there was a way to optimize our workflows. Currently, the CI/CD pipeline for publishing the blog typically took about 17 minutes to deploy a new post. Containers are always batted around as solutions. Unfortunately, I was unsure how to create a new container/image to meet my needs and relied on some straight install.packages() in the CI/CD pipeline. Luckily, I crossed paths with the fabulous Maciej Nasinski and we built a specific container for the publishing process for the pharmaverse blog, which allowed for a notable reduction in publishing time.

Below I will discuss how the pharmaverse container image has improved our blog’s publishing workflow, bringing our deployment time down to approximately 5 minutes. We are also interested in feedback on potential other uses of this container (like devcontainers) or building additional containers for certain purposes. For those interested, we would be happy to provide a tutorial on containers or get in touch if you have ideas or want to get involved!

The Previous Approach: Package Installation overhead

Our prior CI/CD (GitHub Actions) workflow for building and deploying the pharmaverse blog, while comprehensive, included a time-consuming step. It used the a straight “Install dependencies” step from the r-lib actions, which necessitated installing a range of pharmaverse specific R packages during each run. As we added more packages to the pharmaverse to the blog, this became really cumbersome!

The relevant section of our old build-deploy job highlighted this:

  build-deploy:
    # ... other configurations ...
    steps:
      # ... checkout and setup Quarto ...
      - name: Setup R
        uses: r-lib/actions/setup-r@v2
        with:
          use-public-rspm: true

      - name: Install dependencies
        uses: r-lib/actions/setup-r-dependencies@v2
        with:
          packages: |
            jsonlite
            tidyverse
            spelling
            janitor
            diffdf
            admiral
            admiralonco
            # ... and many, many more packages ...
            haven
      # ... other steps like install tinytex and publish ...

This “Install dependencies” step, involving a substantial list of pharmaverse packages, was a primary contributor to the 17-minute execution time. Each workflow run involved downloading and configuring these packages, extending the overall deployment duration.

Adopting the pharmaverse container image: An Efficient Alternative

The solution to this challenge came with the introduction of the pharmaverse container image: ghcr.io/pharmaverse/docker_pharmaverse:4.5.1. This container image was specifically designed for pharmaceutical data analysis, featuring over 40 essential pharmaverse packages pre-installed. These packages cover various functionalities, including CDISC ADaM/SDTM, clinical trial reporting, and regulatory submissions. Built upon the rocker/tidyverse image and incorporating R 4.5.1, it provides a pre-configured environment.

By integrating this image into our CI/CD pipeline (GitHub Actions), we could bypass the extensive package installation phase.

Here’s an overview of our updated build-deploy job:

  build-deploy:
    needs: Update-post-dates
    runs-on: ubuntu-latest
    container:
      image: "ghcr.io/pharmaverse/docker_pharmaverse:4.5.1"
    permissions:
      contents: write
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Configure Git safe directory
        run: git config --global --add safe.directory /__w/blog/blog

      - name: Set up Quarto
        uses: quarto-dev/quarto-actions/setup@v2
        with:
            version: 1.9.12

      # NOTE: Explicit R package installation is no longer required here.

      - name: Install tinytex
        run: quarto install tool tinytex

      - name: Mark repo directory as safe
        run: git config --global --add safe.directory /__w/blog/blog

      - name: Publish
        uses: quarto-dev/quarto-actions/publish@v2
        with:
          path: . # Path to your .qmd file
          target: gh-pages  # Target branch for GitHub Pages
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The outcome of this change has been a consistent reduction in publishing time. Our blog now publishes in approximately 5 minutes. Yay!

Wider Applications of the Pharmaverse Container Image

While this update directly benefits our blog’s publishing, the pharmaverse container image offers broader utility. It is a valuable resource for:

• Pharmaceutical data analysis: Supporting tasks related to ADaM, SDTM, and TLFs.
• Clinical trial programming: Assisting with regulatory submissions.
• Reproducible research: Providing a consistent and verifiable environment.
• Training & education: Offering a ready-to-use setup for educational purposes.
• CI/CD pipelines: Enhancing automated testing and reporting, as observed in our own workflow.
• Collaborative development: Facilitating consistent environments across teams.

Engaging with the Pharmaverse Community

The pharmaverse container image mage represents a collaborative effort within the life sciences industry to provide open-source tools. For those working with pharmaverse packages and R in development, research, or CI/CD contexts, exploring this image may offer practical advantages in efficiency and reproducibility.

Explore the pharmaverse container image repository: pharmaverse/docker_pharmaverse Discover more about Pharmaverse: pharmaverse.org

We acknowledge the contributions of the pharmaverse community and the Rocker Project for their support in developing these resources.

admiral 1.4 is here!

There’s nothing like a new {admiral} release to start the new year with a bang, and that’s exactly what we have for you with {admiral} 1.4! This release comes packed with few choice updates and some exciting new features (including our first AI integration!) that will undoubtedly improve your experience creating ADaMs in R. However, in line with our commitment to stability and maturity, we have once again reduced the number of breaking changes to an absolute minimum. Take a look at the rest of the blog post below to learn more about what to expect in {admiral} 1.4.

install.packages("admiral", repos = "https://cloud.r-project.org")

Installing package into '/home/runner/work/_temp/Library'
(as 'lib' is unspecified)

library(admiral)
library(tibble)

adpc_nfrlt <- tribble(
  ~USUBJID, ~VISITDY, ~PCTPT,           ~PCSTRESN,
  "001",    1,        "Pre-dose",       0.0,
  "001",    1,        "30M Post-dose",  5.2,
  "001",    1,        "1H Post-dose",   8.4,
  "001",    1,        "2H Post-dose",   12.1,
  "001",    1,        "4H Post-dose",   10.3,
  "001",    1,        "8H Post-dose",   6.8,
  "001",    1,        "24H Post-dose",  2.1
)

adpc_nfrlt %>%
  derive_var_nfrlt(
    new_var = NFRLT,
    new_var_unit = FRLTU,
    out_unit = "HOURS",
    tpt_var = PCTPT,
    visit_day = VISITDY
  )

# A tibble: 7 × 6
  USUBJID VISITDY PCTPT         PCSTRESN NFRLT FRLTU
  <chr>     <dbl> <chr>            <dbl> <dbl> <chr>
1 001           1 Pre-dose           0     0   HOURS
2 001           1 30M Post-dose      5.2   0.5 HOURS
3 001           1 1H Post-dose       8.4   1   HOURS
4 001           1 2H Post-dose      12.1   2   HOURS
5 001           1 4H Post-dose      10.3   4   HOURS
6 001           1 8H Post-dose       6.8   8   HOURS
7 001           1 24H Post-dose      2.1  24   HOURS

use_ad_template("adab")

What’s coming in admiral 1.5?

{admiral} is very much community driven, so please continue reaching out through Slack or GitHub if you have ideas or requests for enhancements to our package. {admiral} 1.5 is due to release in June 2026, and some current ideas for new content include improved Estimands documentation and ways to enable positive censoring within TTE derivations.

What is docorator?

The package name, {docorator}, signifies its core functionality: decorate and output. The package takes TLGs generated by popular R packages such as {gt} (and by extension {tfrmt} and {gtsummary}) and {ggplot2} and “decorates” them with custom headers, footers, etc. in production-ready outputs.

The {docorator} package is built on a foundation of reproducibility and flexibility through its multi-rendering framework. While the primary and most robust rendering engine is PDF (leveraging Rmarkdown/Quarto and LaTeX internally), basic RTF support is also available, with the underlying framework designed for expansion to other output formats in the future.

How docorator complements the pharmaverse

This package can be considered complementary to the pharmaverse packages {clinify} and {gridify}. It offers an additional option for R users seeking to meet organizational requirements for specific output types, as well as standardized headers, footers, margins, and sizing. A key feature of {docorator} is its PDF support with embedded table values. By rendering to PDF via RMarkdown/Quarto and LaTeX, the displayed values become embedded within the PDF document, which enhance traceability. For {gt} tables specifically, automated table scaling (i.e. column resizing) is applied by default to assist with fitting the display to the available space.

Example: PDF render

The process of rendering a display involves two main steps:

1. Create a docorator object: This step uses the as_docorator() function to add headers, footers, and other styling elements.

2. Render an output: A simple function call generates the final document.

Below is an illustrative example:

# This code assumes a display object called `t_demog` has been created
t_demog |>
  as_docorator(
    display_name = "t_demog",
    display_loc = "path/to/output/folder",
    header = fancyhead(
      fancyrow(left = "Study ABC123", center = NA, right = doc_pagenum()),
      fancyrow(left = "Safety Population", center = NA, right = NA),
      fancyrow(left = NA, center = "Demographic Summary", right = NA)
    ),
    footer = fancyfoot(
      fancyrow(left = "path/to/t_demog.R", right = doc_datetime())
    )
  ) |>
  render_pdf()

Note that headers and footers are specified via the header and footer arguments using the fancyhead() and fancyfoot() functions, respectively. These functions, inspired by (and for PDF, powered by) the fancyhdr LaTeX library, allow users to flexibly add multiple rows of headers and/or footers with left, center, and/or right aligned text. Rows of headers/footers are added via the fancyrow() function which has arguments for where the custom text should be added.

Here’s the result:

.

Example: multiple renders

In pharma, it’s very common for displays to be utilized across multiple reports, presentations, and various downstream systems. {docorator} is engineered for reuse, offering several powerful features:

1. Multi-render capability: Users can render to multiple output types using pipeable syntax.

# Continuing from the previous example:
t_demog |>
  as_docorator(
    display_name = "t_demog",
    display_loc = "path/to/output/folder",
    header = fancyhead(
      fancyrow(left = "Study ABC123", center = NA, right = doc_pagenum()),
      fancyrow(left = "Safety Population", center = NA, right = NA),
      fancyrow(left = NA, center = "Demographic Summary", right = NA)
    ),
    footer = fancyfoot(
      fancyrow(left = "path/to/t_demog.R", right = doc_datetime())
    )
  ) |>
  render_pdf() |>
  render_rtf() # This will generate both PDF and RTF outputs

2. The docorator object artifact:

Executing as_docorator() does not immediately render your display. Instead, it creates a docorator object that stores all relevant display information in an .rds file. This object serves as an artifact for future rendering or other downstream requirements. For the above example, t_demog.rds will be saved in the folder “path/to/output/folder” alongside the “t_demog.pdf” and “t_demog.rtf” output documents.

A note on LaTeX dependencies

As noted in its README, {docorator} requires a LaTeX installation for PDF rendering. If using {tinytex}, the TinyTeX bundle is recommended, which can be installed via the following code:

tinytex::install_tinytex(bundle = "TinyTeX")

Get in touch!

We encourage you to try {docorator} and provide any suggestions or report problems via the GitHub issues.

🔍 Pharmaverse Examples Highlights

If you’re navigating the world of clinical reporting with modern tooling or are curious about open-source tooling then the pharmaverse examples site is your one-stop-shop! This living collection of end-to-end examples showcases how open-source packages from the pharmaverse ecosystem work together to solve real clinical reporting challenges.

The site is organized into easy-to-navigate sections:

• SDTM examples like DM (Demographics), VS (Vital Signs), AE (Adverse Events).

• ADaM examples including ADSL (Subject Level), ADTTE (Time-to-Event) and ADVS (Vital Signs).

• TLG examples showing how to build demographic tables, adverse event summaries, and pharmacokinetic displays.

• Interactive content such as data visualization apps built with teal.

• Automated reporting of outputs via slides or docs.

• eSubmission for submission preparation.

• and so much more! - visit the site to see all the latest articles!

You can check out Pharmaverse examples in a bunch of different ways, and also offering translation in different spoken languages!

1. You can follow the examples step-by-step reading the code snippets and tracing the evolution of a set of representative data from end to end.

2. You can use our interactive setup using posit cloud that takes care of any environment set up allowing you to jump straight into exploration.

💬 Why It Matters

Open source thrives on collaboration, and the pharmaverse ecosystem embodies this by bringing developers and users together to share tools, workflows, and best practices. The Examples site is a bridge between learning and doing that helps guide users:

• Understand how packages fit together

• Forum to share how packages are used by different teams

• Work towards reproducible, end to end workflows

All of this contributes to faster, more reliable clinical reporting and supports the broader mission of shared problem solved across the industry.

🤝 How You Can Contribute

The pharmaverse examples site is a community-driven site that grows with contributions from developers and practitioners.

Here’s how you can get involved:

Introduction

{admiralneuro} joins the family as the latest {admiral} extension package. The package supports neurological disease areas, with the initial release of version 0.1.0 focusing on Alzheimer’s disease.

The package was born out of a collaboration between Eli Lilly, Roche, Cytel, GSK, and contributors from the wider industry. The package maintainer is Jian Wang (Eli Lilly).

Package Contents

In the 0.1.0 release, {admiralneuro} provides the following:

• Alzheimer’s-specific SDTM test data - this will be moved to {pharmaversesdtm} for the 0.2.0 release of {admiralneuro}
  • DM - Demographics dataset including age-appropriate Alzheimer’s patients
  • NV - Neurological exams dataset including amyloid and tau PET scans at baseline and two follow-up visits
  • SUPPNV- Supplemental neurological exams dataset including reference regions used for SUVR calculations
  • AG - Agents dataset including tracer details for amyloid and tau PET scans
• A brand-new function admiralneuro::compute_centiloid() that computes Centiloid values based on amyloid PET tracer, SUVR pipeline, and reference region
• Two template programs for ADAPET and ADTPET
• A corresponding Creating ADTPET and ADAPET Vignette

library(admiral)
library(admiralneuro)
library(dplyr)

adapet_example <- admiralneuro::admiralneuro_adapet %>%
  filter(PARAMCD == "SUVRBFBB")

adapet_example <- adapet_example %>%
  admiral::derive_param_computed(
    by_vars = c(
      get_admiral_option("subject_keys"),
      exprs(ADT, ADY, VISIT)
    ),
    parameters = c("SUVRBFBB"),
    set_values_to = exprs(
      AVAL = compute_centiloid(
        tracer = "18F-Florbetaben",
        pipeline = "BERKELEY FBB SUVR PIPELINE",
        ref_region = "Whole Cerebellum",
        suvr = AVAL
      ),
      PARAMCD = "CENTLD",
      PARAM = "Centiloid value derived from SUVR pipeline",
      AVALU = "CL"
    )
  )

use_ad_template("ADTPET", package = "admiralneuro")

use_ad_template("ADAPET", package = "admiralneuro")

Conclusion

We’re excited to share the first release of {admiralneuro}, and we hope it will be a valuable resource for those working in the Alzheimer’s disease space. We look forward to expanding the package in future releases to include alpha-synuclein pathology, a hallmark of Parkinson’s disease that is also found in other neurodegenerative conditions, including Alzheimer’s disease. We’ll also be adding functions to explore olfactory impairment, a fascinating early signal connected to both Parkinson’s disease and Alzheimer’s disease.

As with all pharmaverse packages, community feedback is not only welcomed but encouraged so that development remains in a direction that is relevant and useful! Please raise your feedback as issues or discussions in our GitHub repository or the pharmaverse slack.

Current challenges

Clinical trials face several challenges in their current state, which can be broadly categorized into three key areas:

Pharmaceutical Standards

The Clinical Data Interchange Standards Consortium (CDISC) provides globally accepted data standards, which are a set of guidelines and models used to standardize the collection, exchange, and analysis of clinical trial data. These standards aim to improve efficiency, data quality, and interoperability across various clinical research areas.

In this article specifically, the key CDISC Standards we are going to highlight are Clinical Data Acquisition Standards Harmonization (CDASH), Study Data Tabulation Model (SDTM) and Analysis Data Model (ADaM).

The Role of R in Clinical Trials

Nowadays, R is widely used in clinical trial analysis due to its flexibility, powerful statistical capabilities, and strong support for regulatory compliance. R provides:

• Robust Statistical Analysis used for survival analysis, mixed models, and Bayesian statistics.
• Data Cleaning & Transformation facilitated by specialized packages and modeling tools.
• Reproducibility & Open Source Solutions to ensure that clinical reports and submissions can be automated, reducing errors.
• Integration with CDISC Standards with the help of various R packages that can structure data according to SDTM and ADaM requirements.

Pharmaverse

Pharmaverse is a collaborative open-source ecosystem of tools for clinical trial data processing and regulatory compliance, currently consisting mainly of R packages but now also including emerging Python software. It provides resources that streamline the implementation of CDISC standards such as SDTM, ADaM, and Define-XML.

• Key Pharmaverse Packages:
  • {sdtm.oak} – Helps in structuring SDTM datasets.
  • {admiral} – Facilitates ADaM dataset creation.
  • {teal} – Builds interactive R/Shiny dashboards for exploratory clinical data analysis.
• Related R Packages:
  • {rtables} – Creates regulatory-compliant tables for clinical reports.
  • {tern} – Creates regulatory-compliant tables/graphs for clinical reports.

These are not the only packages that are used, but these are the ones that will be referenced within this blogpost.

Pharmaverse doesn’t have a dedicated CDASH package, but its metadata-driven approach means you can still work with CDASH concepts to connect source data collection to SDTM mapping.

A more comprehensive list of packages can be found here: https://pharmaverse.org/e2eclinical/

Data Pipeline

In Clinical Trial Reporting, the data pipeline could follow this standard:

The raw data from patients is collected according to CDASH guidelines, then processed with SDTM and ADaM standards to produce related Tables, Listings, and Graphs/Figures outputs that correspond to all aspects of a specific clinical trial.

Starting with the CDASH data from a study, the preparation process starts with {sdtm.oak} and {sdtmchecks} packages from the Pharmaverse in order to get them ready for SDTM formatted datasets.

Subsequently, ADaM standards are applied on this data using the {admiral} package, which can then be analysed and transformed into Tables, Listings, and Graphs/Figures using non-pharmaverse (but still related) packages such as {rtables} and {tern}.

The Pharmaverse contains some repositories with test data that can help visualize and make sense of this, namely pharmaversesdtm and pharmaverseadam.

There is also the {random.cdisc.data} package that can be used to generate randomized CDISC data for exploratory purposes.

More information about these datasets can be found in their respective documentation sites.

Tables, Listings, Graphs/Figures

The content of clinical trial reports contains 3 different types of outputs:

1. Tables
2. Listings
3. Graphs/Figures

These outputs play a vital part to summarize the results of a clinical trial during reporting. They can summarize safety, efficacy, and exploratory outcomes (such as biomarker analyses).

In the next sections, we will be using the datasets in the {random.cdisc.data} package to help create example outputs used in clinical trials reports. These will be split into two sections each, namely “Data Setup” and “Standard Output Generation”.

library(random.cdisc.data)
library(dplyr)
library(tern)

# Ensure character variables are converted to factors so that
# empty strings and NAs are explicit missing levels.

adsl <- df_explicit_na(cadsl)
adae <- df_explicit_na(cadae) %>%
  var_relabel(
    AEBODSYS = "MedDRA System Organ Class",
    AEDECOD = "MedDRA Preferred Term"
  ) %>%
  filter(ANL01FL == "Y")

# Define the split function
split_fun <- drop_split_levels

# Standard Table for AET02 --------------------------------------------------------------
lyt <- basic_table(show_colcounts = TRUE) %>%
  split_cols_by(var = "ACTARM") %>%
  add_overall_col(label = "All Patients") %>%
  analyze_num_patients(
    vars = "USUBJID",
    .stats = c("unique", "nonunique"),
    .labels = c(
      unique = "Total number of patients with at least one adverse event",
      nonunique = "Overall total number of events"
    )
  ) %>%
  split_rows_by(
    "AEBODSYS",
    child_labels = "visible",
    nested = FALSE,
    split_fun = split_fun,
    label_pos = "topleft",
    split_label = obj_label(adae$AEBODSYS)
  ) %>%
  summarize_num_patients(
    var = "USUBJID",
    .stats = c("unique", "nonunique"),
    .labels = c(
      unique = "Total number of patients with at least one adverse event",
      nonunique = "Total number of events"
    )
  ) %>%
  count_occurrences(
    vars = "AEDECOD",
    .indent_mods = -1L
  ) %>%
  append_varlabels(adae, "AEDECOD", indent = 1L)

result <- build_table(lyt, df = adae, alt_counts_df = adsl)

result

library(random.cdisc.data)
library(dplyr)
library(rlistings)

out <- cadae %>%
  select(AESOC, AEDECOD, AELLT, AETERM) %>%
  unique()

var_labels(out) <- c(
  AESOC = "MedDRA System Organ Class",
  AEDECOD = "MedDRA Preferred Term",
  AELLT = "MedDRA Lowest Level Term",
  AETERM = "Investigator-Specified\nAdverse Event Term"
)

# Standard Listing for AEL01 ------------------------------------------------------------
lsting <- as_listing(
  out,
  key_cols = c("AESOC", "AEDECOD", "AELLT"),
  disp_cols = names(out),
  main_title = "Listing of Preferred Terms, Lowest Level Terms, and Investigator-Specified Adverse Event Terms"
)

head(lsting, 20)

library(random.cdisc.data)
library(tern)
library(dplyr)
library(forcats)
library(nestcolor)

preprocess_adtte <- function(adtte) {
  # Save variable labels before data processing steps.
  adtte_labels <- var_labels(adtte)

  adtte <- adtte %>%
    df_explicit_na() %>%
    dplyr::filter(
      PARAMCD == "OS",
      ARM %in% c("B: Placebo", "A: Drug X"),
      SEX %in% c("M", "F")
    ) %>%
    dplyr::mutate(
      # Reorder levels of ARM to display reference arm before treatment arm.
      ARM = droplevels(forcats::fct_relevel(ARM, "B: Placebo")),
      SEX = droplevels(SEX),
      is_event = CNSR == 0,
      # Convert time to MONTH
      AVAL = day2month(AVAL),
      AVALU = "Months"
    ) %>%
    var_relabel(
      ARM = adtte_labels["ARM"],
      SEX = adtte_labels["SEX"],
      is_event = "Event Flag",
      AVAL = adtte_labels["AVAL"],
      AVALU = adtte_labels["AVALU"]
    )

  adtte
}

anl <- cadtte %>%
  preprocess_adtte()

# Standard Plot for FSTG02 -------------------------------------------------------
anl1 <- anl

df <- extract_survival_subgroups(
  variables = list(tte = "AVAL", is_event = "is_event", arm = "ARM", subgroups = c("SEX", "BMRKR2")),
  data = anl1
)

result <- basic_table() %>%
  tabulate_survival_subgroups(
    df = df,
    vars = c("n_tot", "n", "median", "hr", "ci"),
    time_unit = anl1$AVALU[1]
  )

result

plot <- g_forest(tbl = result)

plot

Conclusion

Clinical trial reporting remains fundamental to public trust and to the integrity of drug development. Nevertheless, the field continues to face persistent transparency deficits, escalating costs, and reproducibility challenges.

Adopting open standards and collaborative platforms—such as the Pharmaverse ecosystem—together with broader open-source initiatives in R and related technologies, offers a practical path forward. These approaches enable greater transparency, improved efficiency, and rigorous, standards-based data practices that strengthen the scientific foundation of clinical research. Consequently, the level of trust can be further enhanced, and public welfare can be assured.

Join us in part 2 of this series where we take a look at interactive clinical trials data analysis using packages that create custom shiny applications specifically for this space.

Resources

• Pharmaverse
• CDISC
• TLG Catalog

What is rtflite?

{rtflite} is a Python package designed specifically for generating TLFs in RTF format for clinical trial reporting. Inspired by the {r2rtf} it provides a programmatic interface to create highly customized TLFs that meet regulatory submission requirements. When used together with pkglite for Python, rtflite bridges the gap between Python’s data science ecosystem and the specialized requirements of clinical trial reporting and submission.

Major enhancements in rtflite 1.0.0

Acknowledgments

We acknowledge the pharmaverse community for feedback and contributions, the r2rtf team for architectural inspiration, and the uv project for simplifying Python environment management. uv is a fast, Rust-based tool that unifies dependency resolution, packaging, and isolated environments which helped saving our time in building, testing, and publishing Python packages. We also appreciate Claude Code for accelerating our AI-assisted development workflow. For project architecture, coding standards, and shared workflows, see our CLAUDE.md and contributing guidelines.

Disclaimer

This blog contains opinions that are of the authors alone and do not necessarily reflect the strategy of their respective organizations.

{metacore} and {metatools} have a new package maintainer

Hi, everyone! I’m Liam and I’m excited to announce that I have taken over as package maintainer for both {metacore} and {metatools} from Christina Fillmore. I work at GSK as a clinical programmer and I am coming to the end of my second year in the industry. This is my first experience working within the open-source world, but I am a regular user of pharmaverse packages and am keen to get more involved with the community.

Christina remains on-hand as a mentor and I’d like to thank both her and Ben Straub for the continued support before we dive into the details of {metacore}/{metatools} 0.2.0.

What’s new in metacore?

The goal of version 0.2.0 was to clarify the distinction between an imported Metacore spec, containing information about multiple datasets, and a subsetted spec containing information about just a single dataset (as achieved via metacore::select_dataset()).

We received a number of questions and issues raised where users were attempting to use a Metacore object containing metadata for multiple datasets in functions from {metatools} that were designed to take a single, subsetted specification. When developing datasets, the typical workflow is to be working on a single dataset at a time - so subsetting the Metacore object is the logical thing to do. The issue was that the approach to functions in {metatools} was inconsistent, with some functions permitting multiple specification metadata and others not.

Now, a Metacore object which has multiple datasets or one with a single dataset have been redesigned to be programmatically distinct, with the single dataset implemented as a subclass of Metacore called “DatasetMeta”.

From the users’ perspective there is one key change. A metadata object about a single dataset will be required for users to work with {metatools} functions, which have had their API harmonised to accept only subsetted Metacore objects (via metacore::select_dataset()).

The print statements of both combined and subsetted Metacore objects have been refined to better illustrate the differences between them and provide more helpful information to the user.

library(dplyr)

Attaching package: 'dplyr'

The following objects are masked from 'package:stats':

    filter, lag

The following objects are masked from 'package:base':

    intersect, setdiff, setequal, union

library(metacore)

Attaching package `metacore`

As of metacore 0.3.0 the `keep` variable in the `ds_vars` table has been renamed to `mandatory`. Please see release documentation for details.

library(metatools)
library(tibble)
library(haven)

load(metacore_example("pilot_ADaM.rda"))
metacore

── Metacore object contains metadata for 5 datasets ────────────────────────────

→ ADSL (Subject-Level Analysis Dataset)

→ ADADAS (ADAS-Cog Analysis)

→ ADLBC (Analysis Dataset Lab Blood Chemistry)

→ ADTTE (AE Time To 1st Derm. Event Analysis)

→ ADAE (Adverse Events Analysis Dataset)

ℹ To use the Metacore object with metatools package, first subset a dataset using `metacore::select_dataset()`

The metacore::select_dataset() function is now explicit about what is being selected:

adsl_spec <- select_dataset(metacore, "ADSL", quiet = TRUE)

Warning: The `quiet` argument of `select_dataset()` is deprecated as of metacore 0.3.0.
ℹ Please use the `verbose` argument instead.

Printing the subsetted object now provides more detailed information:

adsl_spec

── Dataset specification object for ADSL (Subject-Level Analysis Dataset) ──────

The dataset contains 51 variables

Dataset key: USUBJID

The structure of the specification object is:

→ codelist: character [16 x 4] code_id, name, type, codes

→ derivations: character [50 x 2] derivation_id derivation

→ ds_spec: character [1 x 3] dataset, structure, label

→ ds_vars: character [51 x 7] dataset, variable, key_seq, order, keep, core,
  supp_flag

→ supp: character [0 x 4] dataset, variable, idvar, qeval

→ value_spec: character [51 x 8] dataset, variable, code_id, derivation_id,
  type, origin, where, sig_dig

→ var_spec: character [51 x 6] variable, type, length, label, format, common

To inspect the specification object use `View()` in the console.

Functions that take a Metacore object as input will emit a helpful message if a subsetted object is not supplied.

ds_list <- list(DM = read_xpt(metatools_example("dm.xpt")))
create_var_from_codelist(data.frame(), metacore)

Error in `verify_DatasetMeta()`:
! The object supplied to the argument `metacore` is not a subsetted
  Metacore object. Use `metacore::select_dataset()` to subset metadata for the
  required dataset.

create_var_from_codelist()

metatools::create_var_from_codelist() now optionally allows the user to specify a codelist from which the new column should be generated. This is useful in situations like the one below where the user is trying to derive PARAM from PARAMCD but the codelist for the out_var (PARAM) does not contain the values of PARAMCD.

Example of default usage not providing the correct result:

adlbc_spec <- suppressMessages(select_dataset(metacore, "ADLBC", quiet = TRUE))
data <- tibble(PARAMCD = c("ALB", "ALP", "ALT"))
create_var_from_codelist(data, adlbc_spec, input_var = PARAMCD, out_var = PARAM, strict = FALSE)

# A tibble: 3 × 2
  PARAMCD PARAM
  <chr>   <chr>
1 ALB     <NA> 
2 ALP     <NA> 
3 ALT     <NA> 

By default, metatools::create_var_from_codelist() takes the codelist of the out_var as input. The user can now overwrite this default with a specific codelist (in this case PARAMCD below) to achieve the desired result.

create_var_from_codelist(data, adlbc_spec, input_var = PARAMCD, out_var = PARAM, codelist = get_control_term(adlbc_spec, PARAMCD), decode_to_code = FALSE)

# A tibble: 3 × 2
  PARAMCD PARAM                         
  <chr>   <chr>                         
1 ALB     Albumin (g/L)                 
2 ALP     Alkaline Phosphatase (U/L)    
3 ALT     Alanine Aminotransferase (U/L)

This function also provides a new option strict, which when set to TRUE (default) will issue a warning indicating any values in your input column that do not appear in the codelist.

data <- tibble(PARAMCD = c("ALB", "ALP", "ALT", "DUMMY1", "DUMMY2"))
x <- create_var_from_codelist(data, adlbc_spec, input_var = PARAMCD, out_var = PARAM, codelist = get_control_term(adlbc_spec, PARAMCD), decode_to_code = FALSE, strict = TRUE)

Warning: In `create_var_from_codelist()`: The following values present in the input
dataset are not present in the codelist: DUMMY1 and DUMMY2

create_cat_var()

metatools::create_cat_var() has been updated so that users can now specify to create a new variable from either the code or decode column of the controlled terminology. Previously, a codelist set-up like the one below would be evaluated from the code column only, leaving out the “years” text from the new variable.

Now, specifying the option create_from_decode = TRUE will allow you to create the variable based on the text in the decode column. If you are using this option to also create a numeric coded variable (in this case AGEGR2N), ensure your CT is set up so that the decode columns match.

dm <- read_xpt(metatools_example("dm.xpt"))
create_cat_var(dm, adsl_spec, AGE, AGEGR2, AGEGR2N, create_from_decode = TRUE) %>%
  select(USUBJID, AGE, AGEGR2, AGEGR2N) %>%
  head(5)

# A tibble: 5 × 4
  USUBJID       AGE AGEGR2      AGEGR2N
  <chr>       <dbl> <chr>         <dbl>
1 01-701-1015    63 18-64 years       1
2 01-701-1023    64 18-64 years       1
3 01-701-1028    71 65-80 years       2
4 01-701-1033    74 65-80 years       2
5 01-701-1034    77 65-80 years       2

This function now also provides a default strict = TRUE option, that issues a warning message if there are values in the reference column that do not fit into the categories in the controlled terminology. This can be disabled with strict = FALSE.

dm2 <- dm |>
  tibble::add_row(AGE = 15) |>
  tibble::add_row(AGE = 16)
x <- create_cat_var(dm2, adsl_spec, AGE, AGEGR2, create_from_decode = TRUE)

Warning: There are 2 observations in AGE that do not fit into the provided categories
for AGEGR2. Please check your controlled terminology.

Summary of Other Changes

• Fixed a bug where the presence of variables with VLM in the value_spec table would prevent variables of the same name in different datasets being populated in the value_spec table.

• metatools::build_from_derived() adds new options for the keep parameter that allow users to derive either all or only prerequisite columns from source datasets. Thanks to Matt Bearham for this amendment!

• metatools::combine_supp() now adds the label found in QLABEL to the QNAM columns that are derived from supplementary datasets. Thanks to Bill Denney for this amendment!

• metatools::check_variables() now provides a strict option that will issue a warning rather than throw an error when strict = FALSE.

• {cli} output is now used across both packages and messaging for various functions has been improved.

What’s next?

The next step for both packages will be working through and closing out issues from the backlog, updating the examples and vignettes, and improving the user experience via more informative messaging.

For {metacore}, there has been some interest in a UI to help users write custom specification readers for specs not in the standard P21 format. So this will be explored as well.

I hope to release the next update towards the end of the year, looking at an approximately 6-monthly release schedule going forward. Until then I encourage people to explore some of the new features and provide feedback on the changes through GitHub at the links below:

• Metacore

• Metatools

Thanks for reading!

Background

The {pharmaversesdtm} and {pharmaverseadam} packages have been available for some time, providing reusable examples for SDTM and ADaM datasets, respectively. However, one critical piece of the workflow was missing: the raw datasets that serve as the starting point for these examples.

Why now?

With the recent release of the {sdtm.oak} package — an open-source package that enables SDTM programming in R — we now have an opportunity to complete the picture. The new {pharmaverseraw} package fills this gap by providing example raw datasets that can be used as input for {pharmaversesdtm} datasets generation with {sdtm.oak}.

What is in {pharmaverseraw}?

The {pharmaverseraw} package v0.1.0 is out on CRAN. It is also available from the pharmaverse site at: https://pharmaverse.org/e2eclinical/developers/. It includes raw datasets for the following SDTM domains:

- AE: Adverse Events

- DS: Subject Disposition

- DM: Demographics

- EC/EX: Exposure

These raw datasets in {pharmaverseraw} package are intentionally designed to be:

• EDC agnostic: They are not tied to any specific Electronic Data Capture (EDC) system like Rave or Veeva.
• Standards agnostic: Some variables follow CDASH (Clinical Data Acquisition Standards Harmonization), while others do not. This reflects real-world data standards variability across companies.

The annotated case report forms corresponding to the raw datasets are also present in the inst\acrf folder. These PDF files illustrate how each raw variable aligns with SDTM expectations, offering insight into the mapping logic used in {sdtm.oak}.

How are these datasets created?

The datasets in {pharmaverseraw} were created through reverse engineering - we started with the finalized SDTM datasets in {pharmaversesdtm} and worked backward to construct plausible raw datasets that could reasonably result in those SDTM outputs. This approach ensures data consistency while allowing us to demonstrate the flexibility of {sdtm.oak} in handling raw data in different formats.

From raw to SDTM

Using {sdtm.oak}, you can take raw datasets from {pharmaverseraw} and apply SDTM mapping functions to map the target SDTM variables. There will be new SDTM examples published using this data later at: https://pharmaverse.github.io/examples/sdtm/

Below is an example snippet that shows how to use a raw AE dataset from {pharmaverseraw} and generate SDTM AE variables with {sdtm.oak}:

library(pharmaverseraw)
library(sdtm.oak)
library(dplyr)

# Read in raw data
ae_raw <- pharmaverseraw::ae_raw

# Derive oak_id_vars
ae_raw <- ae_raw %>%
  generate_oak_id_vars(
    pat_var = "PATNUM",
    raw_src = "ae_raw"
  )

# Map AETERM and AESDTH variables for AE domain
ae <-
  # Derive topic variable
  # Map AETERM using assign_no_ct, raw_var=IT.AETERM, tgt_var=AETERM
  assign_no_ct(
    raw_dat = ae_raw,
    raw_var = "IT.AETERM",
    tgt_var = "AETERM",
    id_vars = oak_id_vars()
  ) %>%
  # Map AESDTH using hardcode_no_ct and condition_add, raw_var=IT.AESDTH, tgt_var=AESDTH
  # If Yes then AESDTH = Y else Not submitted
  hardcode_no_ct(
    raw_dat = condition_add(ae_raw, IT.AESDTH == "Yes"),
    raw_var = "IT.AESDTH",
    tgt_var = "AESDTH",
    tgt_val = "Y",
    id_vars = oak_id_vars()
  ) %>%
  hardcode_no_ct(
    raw_dat = condition_add(ae_raw, IT.AESDTH != "Yes"),
    raw_var = "IT.AESDTH",
    tgt_var = "AESDTH",
    tgt_val = "Not Submitted",
    id_vars = oak_id_vars()
  )

Get involved

Similar to the other tools under pharmaverse umbrella, the {pharmaverseraw} package is open-source and community-driven. We welcome volunteers who are interested in contributing to the continued development and improvement of this package.

If you’d like to get involved, here are some ways you can help:

- Add new raw datasets: Take other SDTM domains from the {pharmaversesdtm} package and create corresponding raw datasets using R. This will help expand the coverage of the package.

- Create mock aCRFs for the raw datasets: Develop annotated case report forms (aCRFs) that illustrate how the raw variables are mapped to align with SDTM standards.

- Prepare documentation: For each raw dataset you create, include documentation that explains the data structure, variable definitions, and any relevant notes.

Whether you’re a programmer, CDISC expert, or clinical data manager, your contributions can make a meaningful impact. Visit the github repository to open up a issue or start a discussion.