Skip to content

v2.0 Planning

Jump to bottom
jwildfire edited this page Apr 16, 2020 · 10 revisions

Overview

safetyGraphics v2.0 will provide a streamlined refactor of the safetyGraphics app. Major planned changes include:

  • Multiple Domain support - The app will be updated to support multiple data domains.
  • Simplified Settings workflow - The settings workflow will simplified to focus on a shared data mapping framework for use across all charts. The Settings tab/module will be removed, and domain specific data mapping will be added to the data tab/module. Other chart-specific customizations (e.g. point colors) will be available in the charts tab or via command line configuration.
  • Fully modularized charts - We plan to expand upon the process for adding new charts to safetyGraphics that was introduced in v1.1. To support the simplified settings workflow, charts will need to provide default settings when the app is initialized (instead of using the settings generated from the settings tab).
  • Additional Shiny modularization and documentation - We will also revisit the modular framework for the app to better support multiple data domains and chart modularization. Code for the shiny modules will be moved from /inst/safetyGraphics_app to the core /R directory. All updated code will be documented using roxygen headers, and tested via testthat unit tests.

Future updates include:

  • Shared data filters - We plan to add a user interface that allows users apply participant-level data filters (race, age, gender) to all charts
  • Migrate charts to safetyCharts - The default charts themselves (currently saved in inst/htmlwidgets) will be migrated to safetyCharts
  • Settings tab/module - Add a settings module that adds transparency to both underlying metadata and default chart configurations.

Mock-ups

Here are some (very rough) mockups of the new UI.

03_29_12

Technical Details

Metadata updates

Simplify to a single metadata file called standardsMetadata that captures data mapping information using a (simplified) combination of information from the existing standardsMetadata and settingsMetadata objects. Notes:

  • Expected columns for the new metadata file include domain, text_key, label, and columns for each pre-loaded data standard.
  • Structure is one row per domain per expected column or field
  • Field level mapping will still be supported, but should be tied directly to the column using a -- separator. For example, if you are expecting a specific lab value to be found in measure_col (e.g. Total Bilirubin) then you would create a row for measure_col--{fieldName} (e.g measure_col--TB as opposed to an independent measure_values--TB used in v1.0)
  • Alternative: Metadata saved as an object (List or Tibble). Fields captured as a component (tibble list-column?) of each column, with the needed metadata structure.
  • The chartMetadata file will be removed from the core library. See the section below for a discussion of modular chart configuration.

Charting Process

Charts will work in a very similar fashion under the hood - safetyGraphics will still provide settings and data when a chart is rendered. Charts will still share a single source of data (managed by the safetyGraphics data module), but chart metadata and settings workflow will be modularized so that the settings and metadata for each chart will be associated with the chart itself (instead of coming from a centralized settings Module).

Notes:

  • Users should provide a list of charts when initializing the app. The charts listed should correspond to R functions that are loaded in the current session and take data and settings as inputs and produce output suitable for a shiny renderChart function.
  • Each chart may provide a default settings list saved as sg_[[chartname]]_default.RDA in a specified config folder. When a chart is rendered, the data mappings in the app will be merged on to this default object (overwriting the defaults), and then passed to the chart. An empty list is used if no default is provided.
  • Each chart may provide an 'onLoad' script (sg_[[chartname]]_onLoad.R that runs before the chart is rendered in shiny. This script should contain a function that takes dataIn and settingsIn as input (from the shiny app) and produce dataOut and settingsOut as outputs (which are then passed to the charting function). This script provides an environment where custom data and settings tweaks can be made prior to chart renderering.
  • In the future, we may want to provide an option for sg_[[chartname]]_validation.R scripts that produce static output that can be used to QC/validate interactive graphics.

Helper Functions

Assessment of all helper functions. Estimate = Keep 11 of 31 functions (35%)

Functions to keep and refactor

  • Package Infrastructure
    • safetyGraphics - K
    • safetyGraphicsApp - K
  • Metadata storage/management
    • standardsMetadata - K
    • addSetting - K
    • removeSettings - K
  • Charting - likely needs significant refactor
    • createChart - K
    • chartRenderer - K
  • Data Standard detection
    • detectStandard - K
    • evaluateStandard - K
    • hasColumn - K
    • hasField - K

Functions to remove

  • addChart - R - Assuming we get rid of the chart metadata this can go.
  • chartsMetadata - R
  • checkRequired - R - validation dependency
  • generateSettings - R
  • getSettingValue - R
  • removeCharts - R
  • setSettingsValue - R
  • trimData - R - We may want to keep this, but refactor to use a simple column list instead of the settings object as input. Might be easier just to write a new (much simpler version from scratch)
  • checkColumn - R - Part of the validation workflow, and can likely be removed.
  • generateShell - R
  • getSettingsMetadata - R
  • settingsMetadata - R
  • trimSettings - R
  • adlbc - R
  • checkField - R
  • getRequiredSettings - R
  • validateSettings - R
  • checkNumeric - R
  • getSettingKeys - R
  • textKeysToList - R

Vignettes

Clone this wiki locally