Claude Code in RStudio: bringing AI-assisted clinical programming to pharma

Overview and goals

The challenge

Clinical programmers in regulated pharma environments are among the most highly skilled, and most interrupted, professionals in data science. A single R job failure can cascade into hours of log triage. A poorly specified Statistical Analysis Plan (SAP) section can invalidate weeks of derivation work. A hardware tier mismatch can burn compute budget on jobs that time out before producing results.

These interruptions share a common characteristic: they require deep domain knowledge to diagnose but not the programmer's creative attention. They are, in other words, exactly the kind of repetitive expert task that AI coding assistants like Claude Code are designed to handle.

The solution

Claude Code is already available inside Domino workspaces as a terminal-based AI coding assistant for R and Python.

This blueprint shows how to close that gap by surfacing Claude directly inside RStudio as five point-and-click add-ins, scoped specifically to clinical programming tasks: log triage, code review against a Statistical Analysis Plan (SAP) section, derivation logic explanation, test generation, and hardware tier diagnosis. Rather than opening a free-form chat window, a programmer highlights the relevant code or log output, selects an add-in from the RStudio menu, and gets a scoped response back without ever leaving their editor.

How Claude Code integrates with RStudio for clinical programming

Understanding the architecture for clinical programming workflows

The dominoClaudeRus R package is a thin wrapper around the Claude Code CLI. When a programmer triggers an add in, the package reads the selected text from the RStudio editor, loads the appropriate prompt template, and passes both to the Claude binary via standard input (stdin). The response is rendered in the RStudio Viewer pane, and always echoed to the console as a fallback.

The R package logic, the prompt templates, and the add in behavior are entirely decoupled from the model provider, so none of them need to change when the backend changes. The only thing flowing out of the workspace is the explicit, programmer selected text plus a fixed template, never the full script, full dataset, or anything outside what was highlighted. Because the CLI is the single egress point, IT and security teams have one place to audit, log, or restrict traffic, rather than tracing calls scattered across the R codebase.

The LLM endpoint, whether that's the Anthropic API, Amazon Bedrock, or a self hosted Domino AI Gateway, is controlled entirely by Domino Environment Variables. The R code is identical regardless of which provider is active, and no code changes are needed to switch between providers.

Reviewing the five clinical programming add-ins

Deep-dive into the five clinical programming addins

A. Claude: Check R Logs

Select the R console output or job log, full or partial, and the add categorizes a breakdown rather than a wall of raw text: errors, their root causes, and specific fixes the programmer can apply directly, rendered in the Viewer pane.

The add in is also tuned to catch the failures that don't throw an error at all, the silent issues that are easy to miss in clinical programming because R will happily run to completion while quietly producing the wrong result. That includes NA coercions introduced during type conversion, factor levels dropped during a subset or merge, date fields parsed under the wrong format, and merge key mismatches that silently drop or duplicate rows instead of failing loudly. Because these issues surface downstream, often as a derivation that looks fine until QC, catching them at the log stage saves the hours of backtracking that would otherwise be needed to find where the data went wrong.

B. Claude: Inspect Data

Select a data frame name, or type one in when prompted, and the add in builds a structural summary of the dataset rather than sending any of the actual data to Claude. Behind the scenes, the package's summary builder collects only column names and R types, NA counts and percentages, and for numeric columns the min, max, mean, and standard deviation, never the underlying values themselves. For character and factor columns it captures only a count of unique values, and for date columns only a count of unique dates, with the actual dates explicitly redacted before anything leaves the workspace. No head() output, no sample rows, and no patient identifiers reach the LLM under any circumstance.

That structural summary is what gets passed to Claude, which returns a CDISC ADaM/SDTM quality report built entirely from metadata: naming convention gaps, missing expected variables, suspicious NA patterns, and type mismatches against what the dataset's naming suggests it should contain. The example below shows the CDISC ADaM quality report Claude returns for an ADSL dataset, built from structural metadata only. For a clinical programmer, this means a compliance check can run on a sensitive dataset without that dataset, or anything derived from its actual values, ever reaching an external endpoint.

C. Claude: R warnings

This add-in works in one of two modes, and detects which one to use automatically based on what the programmer has selected, with no separate menu choice required.

If the selection is a warning message, the add-in treats it as a diagnosis request: it returns a plain language explanation of what triggered the warning and a specific fix, rendered in the Viewer pane.

A programmer triaging a job log can select just the warning text and get an explanation without having the underlying script open at all. The same programmer, later in their derivation script, can select the offending line directly and have the fix applied in place, keeping the correction in the same file and context without breaking their workflow by switching tools.

If the selection is R code instead, the add-in switches to correction mode. It echoes the corrected code to the console first, then inserts that same correction directly back into the editor in place of the original selection, so the programmer has a console record of exactly what changed alongside the updated code in context for a quick visual review before continuing.

See a sample console view when R code is selected.

Review sample code changes made by Claude

D. Claude: Review SAP Section

Select a section of Statistical Analysis Plan (SAP) text, anything from a single endpoint definition to a full analysis section, and the add-in returns a structured review rather than a general summary. The review is framed specifically as an ICH E9 and CDISC ADaM check, the standards clinical derivation work is ultimately held to, rather than a generic read of the prose.

The output flags ambiguities in the selected text: language that could reasonably be interpreted more than one way once a programmer sits down to actually implement it. It also checks for missing specifications that SAP sections commonly omit but that derivation work depends on, including visit windows, how missing data should be handled, and population definitions. Where the text leaves a gap or a judgment call, the add in surfaces clarifying questions the programmer can raise with the biostatistician before programming begins, rather than making an assumption and discovering the mismatch only after derivation work is already underway.

This is meant to run before a single line of derivation code is written. Catching an ambiguous endpoint definition or an undefined visit window at this stage costs a few minutes of back and forth. Catching the same gap after weeks of programming, once it surfaces in QC or a data review, costs considerably more.

E. Claude: Generate Job Config

Unlike the other four add-ins, this one needs no selection at all. It reads the full active script in the editor and uses that as the basis for its recommendation, so a programmer can run it at any point while writing a derivation script without first deciding what to highlight.

The add-in returns a recommended Domino job configuration built from what the script actually does: a hardware tier sized to the script's apparent workload rather than a default guess, the environment variables the script will need to run correctly, the package dependencies it relies on, and any opportunities to parallelize parts of the work that are currently written to run sequentially.

This is particularly useful for programmers who are confident in R but less familiar with Domino's job configuration options, since it removes the guesswork around hardware tier selection that otherwise leads to either over-provisioned jobs burning unnecessary compute budget or under-provisioned jobs that time out before producing results, the exact failure mode this blueprint opens with.

Are these add-ins safe for regulated environments?

No patient data leaves the workspace

Claude Code CLI runs inside the Domino workspace container. The API call originates from within the customer's network perimeter. The package never opens an outbound connection itself.

The Inspect Data add-in sends only a structural summary to the LLM and never actual clinical data:

• Column names, R types, NA counts and percentages
• Numeric columns: min, max, mean, sd — no actual values
• Character/factor columns: unique value count only — no actual strings
• Date columns: unique date count only — actual dates explicitly redacted

Provider-agnostic: use your organization's approved LLM endpoint

Three backend options are supported with no R code changes, only Domino Environment Variables:

How can clinical teams take ownership of AI guidance?

Prompt templates are plain markdown files in inst/prompts/ — not compiled R code. Clinical teams can continuously refine the AI guidance themselves as they encounter new patterns, without involving the platform team and without triggering a CE rebuild.

A biostatistician can open the SAP review prompt on GitHub, edit it to include their organization's specific endpoint derivation standards, open a Pull Request, and have the improved prompt live for their whole team the same day — via the runtime override, before the next CE release.

Two ways to update prompts

• Via Pull Request (permanent): edit inst/prompts/*.md on GitHub → PR → merge → new release tag → CE rebuild
• Via runtime override (same-day, no rebuild): drop an .md file into clauderus-prompts/ in the Domino project root or set DOMINO_CLAUDERUS_PROMPTS_DIR as a Domino Environment Variable for a team-wide override

What does this mean for clinical programming teams?

The five dominoClaudeRus add-ins don't replace clinical programmers. They remove the low-value interruptions that fragment a programmer's day, such as log triage, pre-pipeline quality checks, SAP gap reviews, and job sizing. These add-ins make them one-click tasks instead of context switches.

The pattern is designed to grow with the team. Adding a new add-in is three files: a prompt template, a one-function R wrapper, and a line in the add-in registry. The prompt templates are reusable assets and belong to the clinical team, not the platform team.

Change management at a glance

• Prompt text only → No CE rebuild. Use project clauderus-prompts/ folder or PR to inst/prompts/.
• New add-in or R logic → Minor version bump. CE rebuild required.
• LLM provider switch → No code or version change. Update Domino Environment Variables only.