Skip to contents

ctasapp

Interactive Shiny application for exploring results from the {ctas} (Clinical Timeseries Anomaly Spotter) R package. Provides drill-down visualizations of site-level outlier scores and subject-level time series data.

Installation

You can install the development version of ctasapp from GitHub with:

# install.packages("remotes")
remotes::install_github("IMPALA-Consortium/ctasapp")

Usage

Launch the app with bundled sample data:

Once the app is running, click Use Sample Data on the Data tab, then switch to the Fields tab to explore parameter-level timeseries and site outlier scores.

Configuration

The app ships with a default config.yml that controls colours, parameter icons, and which ctas features are pre-selected. To customise, copy the default config and pass your version to run_ctas_app():

# Copy the shipped default as a starting point
file.copy(
  system.file("config.yml", package = "ctasapp"),
  "my_config.yml"
)

# Edit my_config.yml to taste, then launch:
run_ctas_app(config = "my_config.yml")

The config file is YAML with three sections:

colors:
  score_breaks: [1.3, 3, 5, 10]
  plot: ["#9ED782", "#fed8019c", "#fed801", "#FEAA01", "#FF5858"]
  table: ["#FFFFFF", "#feed01", "#fed801", "#FEAA01", "#FF5858"]
  table_text: ["#1A1A1A", "#1A1A1A", "#1A1A1A", "#FFFFFF", "#FFFFFF"]
  query_no_change: "#a380e9"
  query_data_change: "#2790e0"

icons:
  range_normalized: flask
  numeric: chart-line
  categorical: water
  bar: chart-bar

features:
  default:
    - autocorr
    - average
    - sd

Any key you omit falls back to the built-in default.

AI Disclaimer

This package and documentation were developed with assistance from AI tools, including Cursor and Claude Opus 4.6. All AI-generated content has been reviewed.

Quality Control

Since {ctas} is designed for use in a GCP framework, we have conducted extensive quality control as part of our development process. In particular, we do the following during early development:

  • Unit Tests - Unit tests are written for all core functions, 100% coverage required. Lines that cannot be tested in a non-interactive context (e.g. Shiny reactive inputs, render callbacks, defensive guards that only fire inside a running app) are annotated with # nocov and excluded from the coverage metric. See the Contributor Guidelines for the full policy.
  • Workflow Tests - shiny::testServer() tests verify that Shiny module logic behaves as expected.
  • Function Documentation - Detailed documentation for each exported function is maintained with Roxygen.
  • Package Checks - Standard package checks are run using GitHub Actions and must be passing before PRs are merged.
  • Continuous Integration - Continuous integration is provided via GitHub Actions.
  • Code Formatting - Code is formatted with {styler} before each release.
  • Contributor Guidelines - Contributor guidelines including step-by-step processes for code development are provided as a vignette.

Parking

As development progresses, we will also conduct the following quality control steps:

  • Qualification Workflow - All assessments will be Qualified as described in a Qualification Workflow Vignette. A Qualification Report Vignette will be generated and attached to each release.
  • Code Review - Code review is conducted using GitHub Pull Requests (PRs), and a log of all PRs will be included in the Qualification Report Vignette.
  • Regression Testing - Extensive QC and testing will be done before each release.
  • End-to-End Tests - Browser-based tests using {shinytest2} will validate the full user interaction flow.