Overview

The mighty framework introduces a declarative paradigm to building ADaM datasets, emphasizing what you need rather than how to create it. This shift enables users to focus on the structure, derivations, and intent of your datasets while abstracting away tedious implementation details.

Important mighty is a work-in-progress, so expect the documentation and functionality to change.

Why mighty?

Declarative Specification

With mighty, you specify exactly what belongs in your ADaM datasets—including columns, derivations, and row transformations—and point to existing code implementations (or your own custom ones) that handle the actual data manipulations. Mighty orchestrates and compiles these instructions into executable ADaM programs.

Single Source of Truth

Mighty ensures metadata required for your define.xml always matches the code implementation. Components and specifications are consolidated into a single representation, ensuring any changes automatically propagate throughout your ADaM programs and keeping documentation synchronized with implementation.

Dependency Analysis

Mighty tracks column and row dependencies for every derivation, analyzing the dependency topology among actions to determine execution order. This ensures that derived variables are created in the correct sequence, with prerequisite calculations completed before dependent operations. Dependency validation alerts you when required columns are missing, or if cyclic dependencies are detected, to aide debugging.

Missing Data Analysis

Identification of discrepancies between specified ADaM requirements and available SDTM/ADaM data, enables generation of executable programs that gracefully adapt to current data availability. See vignette("missing_data_analysis") for more details.

Example: Deriving COMPLSFL in ADSL

To illustrate mighty’s declarative paradigm, consider the following example where we define and derive the variable COMPLSFL for the ADSL domain. This column indicates whether the subject’s end-of-study status is “COMPLETED.”

id: ADSL
label: Subject-Level Analysis Dataset
class: SUBJECT LEVEL ANALYSIS DATASET
structure: One record per subject

keys:
  - USUBJID
  - STUDYID

population:
  base:
    - domain: DM
      depends: NA
      filter: NA
  global:
    - filter: NA
      depends: NA

columns:
  - id: USUBJID

  - id: STUDYID

  - id: EOSSTT

  - id: COMPLSFL
    component:
      id: der_complsfl

This specification uses the mighty.metadata format with these main sections:

The COMPLSFL column points to the code component called der_complsfl.

Code components

Code components can either be validated standard components or custom (un-validated) components. In this example der_complsfl is a standard component.

The id field holds the name of the component, not a file path. Mighty looks it up in the component repositories listed under repos in _mighty.yml (see vignette("mighty_config")). To use a custom component, add the directory that contains it to repos and refer to it by its name or file name:

# _mighty.yml
repos:
  - github::NovoNordisk-OpenSource/mighty.standards/components
  - path/to/custom/components

  - id: COMPLSFL
    component:
      id: der_complsfl.R

Custom components are R scripts (.R) or Mustache templates (.mustache) that adhere to a few simple rules. See vignette("code_components") for more details.

As mighty matures, more of these components will be pre-defined and ready for use, so fewer components would need to be defined by the user. Standard components are provided by mighty.standards, while mighty.component provides utilities for rendering both standard and custom components.

See vignette("adam_specification") for more details on the ADaM Specification data model.

For now, let’s assume der_complsfl doesn’t exist and we have to write it ourselves:

#' @title Completion Status Flag Calculation
#'
#' @description This script adds a `COMPLSFL` column to the input data frame,
#' indicating whether a subject's end-of-study status is marked as "COMPLETED".
#'
#' @type column
#'
#' @origin Derived
#'
#' @method Set to "Y" when EOSSTT is "COMPLETED", otherwise "N".
#'
#' @depends ADSL EOSSTT
#'
#' @outputs COMPLSFL
#' @code

# Add a new column COMPLSFL based on the EOSSTT value
ADSL <- ADSL |> dplyr::mutate(
  COMPLSFL = dplyr::case_when(
    EOSSTT == "COMPLETED" ~ "Y",  # Mark "Y" if EOSSTT is "COMPLETED"
    TRUE                  ~ "N"   # Mark "N" otherwise
  )
)

How it works

mighty processes three key inputs to automatically generate ADaM programs:

  1. ADaM domain specifications - Define structure and requirements for analysis datasets
  2. Code components - Reusable building blocks referenced in specifications
  3. Data availability context - Information about which SDTM/ADaM domains and columns are currently available

The package intelligently orchestrates the execution order of derivations, parameters, and imputations, organizing these operations into structured, production-ready ADaM programs.

Note: Code components can be sourced from mighty.standards (processed via mighty.component) or defined as custom user components, depending on project requirements.

See vignette("adam_specification") for more details on ADaM specifications, vignette("mighty_config") for study metadata configuration, and vignette("connect_to_data") for more details on how source data is retrieved in the rendered programs.

The mighty ecosystem

The mighty framework consists of these complementary packages:

Note: All packages in the mighty ecosystem are currently under active development and are subject to change. Package names, features, and functionality may evolve as the ecosystem matures.

Installation

Install the development version from GitHub:

# Using pak (recommended)
# pak::pak("NovoNordisk-OpenSource/mighty")
install.packages("mighty", repos = c('https://novonordisk-opensource.r-universe.dev', 'https://cloud.r-project.org'))