TOOLS / AI TOOLS

AI tools for RWE

Tools that treat evidence work the way evidence work deserves: decisions documented, code auditable, and patient-level data nowhere near a language model. Statuses below are honest. If something says "in development," it is not vaporware; it is just unfinished.

Study Designer

WORKING PROTOTYPE

A local-first decision workspace that turns an RWE question into an explicit, reviewable design brief. It recommends a starting architecture, surfaces unresolved assumptions, and exports Markdown and JSON without sending study information to a server.

Open Study Designer → NO LOGIN · NO UPLOAD · BROWSER-LOCAL DRAFT
  • Question before method. Population, strategies, outcome, horizon, and measure are made explicit first.
  • Recommendations stay reviewable. The tool explains its suggested design and records any analyst override.
  • Open decisions remain visible. Completeness is never presented as scientific validity or submission readiness.
01
QuestionDecision, population, strategies, outcome, measure
02
DesignTime zero, eligibility, follow-up, estimand
03
Data & biasObservability, algorithms, confounding, diagnostics
04
ReviewOpen decisions, ownership, Markdown and JSON

RWE Coding Copilot

IN DEVELOPMENT

A coding copilot that lives beside SAS, RStudio, and Python, not inside them. Give it your protocol, SAP, and codebook, and it does the thing most analysts skip under deadline pressure: it interviews you about every analytic decision the SAP leaves ambiguous before a single line of code exists.

1 → Structured spec Builds an analysis spec from your documents. You confirm it; the machine does not guess silently.
2 → Decision interview Date inclusivity, washout, censoring, grace periods: a fixed checklist of the decisions that quietly change results.
3 → Annotated code Copy-ready SAS, R, and Python where every decision-dependent line cites its decision id.
4 Audit guide A timestamped Analytic Decision Guide from an append-only log. Your future QC reviewer says thanks.
rwe-copilot ingest my-study/ protocol.docx sap.docx codebook.xlsx rwe-copilot confirm my-study/ # review spec.yaml first rwe-copilot interview my-study/ # the part your SAP forgot

Bring your own key: works with any OpenAI-compatible endpoint (OpenRouter, a company gateway, local Ollama). Inputs are document text and codebook metadata only. The tool generates code; it never connects to data.

Structured Literature Reviewer

IN DESIGN

Protocol-driven literature review with the boring parts done properly: explicit search strategy, screening criteria you set up front, extraction into evidence tables, and citations that are verified rather than hallucinated. The goal is a review you could hand to a methodologist without flinching.

  • Search you can reproduce. The query, databases, and date ranges are recorded as part of the output.
  • Verified references. Every citation is resolved against the source record before it appears in a table.
  • Evidence tables, not vibes. Endpoints, populations, designs, and limitations extracted into a structure you can sort and audit.

The lab

Experiments built on personal time. They earn a place here when they hold up under real workloads, and they come down when they do not. Currently running: a pipeline that drafts and red-teams study documents — protocols, SAPs, and manuscripts — against a panel of adversarial reviewer personas. More to come.

The safety rules these tools live by

—

No patient-level data, ever. Models see documents and metadata. Code runs where your data lives, under your governance, like it always has.

—

Your keys, your endpoint. Bring your own key and route through whatever gateway your organization already trusts.

—

Every decision on the record. Append-only decision logs and annotated code. If a reviewer asks "why this washout window," there is an answer with a timestamp.

—

The human signs the analysis. These tools draft, structure, and check. They do not replace the analyst's judgment or their accountability.

Want early access or to argue about any of this? Get in touch →

Suggest a tool

What should exist that does not? Describe the RWE/HEOR task you wish a tool handled — the more specific the workflow, the better. Suggestions that survive scrutiny end up in the lab.