OHDSI Analytic Use Case Generator
Free research tool

OHDSI Analytic Use Case Generator

Turn a clinical idea into a well-formed observational research question, then get a quick read on whether it could run as an OHDSI network study. Fill in the blanks, trace where each part of the question is recorded, count it in your own OMOP data, review the feasibility scorecard, and build a set you can download.

Clinical characterization Population-level effect estimation Patient-level prediction
How to use this tool

This generator helps you phrase an observational research question in the standard OHDSI form, trace where each part of it is recorded, count it in your own OMOP data, and get a fast, structured read on whether it could run as a network study. Work through the stages in order, using the bar at the top of the builder or the Previous and Next buttons; the question and scorecard in the output panel update as you go. Then collect and download what you build.

The three use case families

Clinical characterization: describes a population, including who they are, what treatments they receive, and how often an outcome occurs. The descriptive foundation, and usually the most feasible starting point.
Population-level effect estimation: asks whether an exposure changes the risk of an outcome, on its own (safety surveillance) or against a comparator (comparative effectiveness).
Patient-level prediction: estimates the probability that a specific person will have a future outcome, given what is known at an index date.

It opens on the question and the feasibility scorecard, which is all a quick read needs. The data trace, the queries, and your site's counts are added from the foot of the question stage when you want them, and hidden again without losing anything.

Steps

  1. Write the question. Pick the use case type that matches what you want to learn; a one-line hint explains each. Then type your condition, drug, outcome, comparator, or time window. The question assembles live in the output panel, with each filled slot highlighted in its family color and empty slots shown in [brackets].
  2. Trace the data. Each part of your question appears as an element to trace, with the population, exposure, comparator, and outcome labeled by their role in the design. Search Athena for each concept and enter its ID (or paste its Athena link), name, and domain; if more than one standard concept fits, enter them all, or add an alternative set to compare two definitions. Choose where the information is usually recorded, such as a coded diagnosis, a lab value, a clinician's note, or a questionnaire, and check any rule that limits collecting or sharing it, such as the added protections for substance use disorder records. For a prediction question, add the predictors you would want at the index date as elements of their own. If the trace shows that the question depends on something recorded outside coded fields or covered by a restrictive rule, revise the question and record what changed. The same stage writes each concept set in the format ATLAS reads, so the work carries into a cohort definition instead of being retyped.
  3. Build the queries. Choose your database (SQL Server, PostgreSQL, Databricks, or an OHDSI SqlRender template) and schema names. The tool writes read-only queries: one checks each concept against your site's vocabulary, another counts the people with each concept set and its descendants, leaving small counts blank so they stay in your database. The same stage writes a prompt you can paste into an AI assistant, either one that queries your data, such as Databricks AI/BI Genie, or one that edits the SQL with you.
  4. Enter your site's counts. Paste each result grid back in, or type the counts. The tool reports what the counts show, including the target population against the comparator and the events available for a prediction model, compares the options if you made an alternative set, flags concepts that are missing or non-standard at your site, and builds a site feasibility report to share with the study team.
  5. Assess network feasibility. Set each drop-down to your best estimate. If you are unsure how to answer, open Not sure? How to check under the question for specific lookups to run in your own data and questions to ask a data holder, so the answer comes from evidence rather than a guess. The scorecard updates as you go: a banded meter, a next-step recommendation, and specific watch-outs and strengths tied to your answers. The drop-downs start at a moderate baseline; adjust them to your study. Notes from your data trace and site counts appear beside the matching questions; they inform your answer but never change a drop-down for you.
  6. Add to collection. Save the finished use case. Build as many as you like; each keeps its own question, data trace, site counts, design skeleton, OMOP domains, and feasibility read.
  7. Download. Export the whole set as a formatted HTML report, save and reload later as JSON, or print. Your collection also autosaves in this browser.

Reading the feasibility score

Strong candidateDraft a protocol and take it to an OHDSI workgroup or study-a-thon.
Feasible with planningTighten phenotypes and run data diagnostics on a few sites first.
Feasible but constrainedPilot on your own data and resolve the flagged constraints.
Low feasibility as scopedReshape the question; often a characterization framing is the feasible first step.

Watch-outs (▲) flag design risks to plan around; strengths (✓) confirm what already works in your favor. The read is a heuristic to guide scoping; it does not replace phenotype validation or formal protocol review.

Worked example: menopause

One question built all the way through, from a blank form to a site feasibility report, using menopause as the clinical example. It carries on from the vocabulary worked example on MCH·OMOP Live and uses the concept IDs from an ATHENA export taken 1 August 2026.

Loading it fills every stage: a population defined twice, once from the Observation-domain status concepts and once from the Condition-domain diagnosis concepts, three symptoms and conditions traced as elements of their own, the queries written for PostgreSQL, a set of counts already pasted in, and a scorecard answered to match. The counts are fabricated, so read them as an illustration of what the tool does with a result rather than as anything about menopause.

The vocabulary worked example

Loading replaces what is in the builder, including the database settings, and leaves your collection alone. Start over clears it again.

1

Write the question

— —
Research question

Study design skeleton

Likely OMOP CDM domains

Network-study feasibility

—
    Build several, then download them together below.

    Your collection

    0 use cases
    No use cases yet. Build one above and press Add to collection.

    The analytic use case structure, covering clinical characterization, population-level effect estimation, and patient-level prediction with each type's Mad Libs-style template, is adapted from the OHDSI Save Our Sisyphus (SOS) Challenge (OHDSI, 24 Jan 2023) and the Book of OHDSI. The feasibility read is a structured heuristic based on your own inputs: a starting point for scoping conversations, not a substitute for formal protocol development, phenotype validation (e.g., CohortDiagnostics / PheValuator), or review by an OHDSI workgroup. The rule summaries in the data trace stage describe US federal rules as of September 2026. They are not legal advice, and state law and institutional policy vary, so confirm each point with your IRB (institutional review board) or privacy office. The site queries produce crude counts for scoping; they are not cohort definitions.

    A free tool by Danielle Boyce, MPH, DPA · boycedatascience.com/research-tools Runs entirely in your browser. Nothing you enter leaves this page unless you open an Athena link, which sends that term or concept ID to Athena. The queries and the assistant prompt run only where you take them.