Network Study Paint By Numbers

The study behind this walkthrough

The worked example is Estimating the risk of non-arteritic ischemic optic neuropathy (NAION) and diabetic retinopathy progression associated with semaglutide exposure, an OHDSI network study led by Cindy X. Cai (Wilmer Eye Institute, Johns Hopkins) with the OHDSI Eye Care and Vision Research Workgroup. It began as a safety question in the news, semaglutide and a rare blinding condition, and became a network study run across administrative claims and electronic health record databases, with results published in JAMA Ophthalmology in 2025.

Every artifact is public:

• The research protocol, including the full cohort definitions and concept sets in its appendix
• The study repository with the executable study package
• The published results (open access, JAMA Ophthalmology 2025)

Design details on this tab are reproduced from version 1 of that protocol as posted at ohdsi-studies.github.io/SemaglutideNaion, accessed August 2026. Concept IDs and thresholds may be revised over time, so verify anything you reuse against the live protocol and ATHENA.

The research question

The clinical concern was a single question: does semaglutide cause NAION? The protocol split it into separate questions, each with a stated population, exposure, comparator, and outcome:

1. Among patients with type 2 diabetes mellitus, is the risk for NAION higher among patients who use semaglutide as compared with a non-GLP-1 RA anti-diabetic medication?
2. Among patients with type 2 diabetes mellitus, is the risk for diabetic retinopathy progression higher among patients who use semaglutide as compared with a non-GLP-1 RA anti-diabetic medication?
3. Among patients with type 2 diabetes mellitus, is the risk for NAION higher among patients who use semaglutide as compared with other GLP-1 RA anti-diabetic medications?

Each is a population-level effect estimation question in the standard OHDSI form: a defined population, a defined exposure, a defined comparator, a defined outcome. The study also characterized NAION incidence in each exposure cohort before estimating anything, so a clinical characterization question sits underneath the estimation questions, and a self-controlled case series reuses the same cohorts as a second design.

The same study, run through the use case generator

If you had typed this study into the Analytic Use Case Generator before writing the protocol, it would have produced a use case per question. Here is what goes in each slot, taken from the protocol:

Filling the slots this way shows something the protocol text alone does not. The comparative effectiveness template gets instantiated once per comparator and outcome pair, which is how a short list of protocol questions becomes the much larger set of comparisons the study ran. The self-controlled case series has no template in the generator, because it contrasts exposed and unexposed time within the same people rather than comparing two cohorts.

Design and study population

The primary design is an active comparator, new-user cohort design. The population is adults 18 or older with type 2 diabetes mellitus; an indication cohort defines that population and excludes type 1 and secondary diabetes. The target is new users of semaglutide as second-line treatment after metformin. Comparators come in two flavors: within class (dulaglutide, exenatide) and across class (empagliflozin, sitagliptin, glipizide), and the protocol states these were chosen as the most commonly occurring medication within each class in the LEGEND-T2DM study. A self-controlled case series compares NAION incidence during exposed and unexposed time in the same people, which trades confounding-by-indication concerns for within-person assumptions.

The study period runs from December 1, 2017 to December 31, 2023. Analysis uses large-scale propensity scores with 1:1 matching and Cox models for the cohort comparisons, and Poisson regression for the self-controlled case series, executed through the Strategus pipeline calling HADES packages.

Concept sets

A concept set is the bridge between a clinical idea ("type 2 diabetes", "semaglutide") and the rows in an OMOP database. Each entry names a standard concept and two decisions: whether to include its descendants in the vocabulary hierarchy, and whether the entry is an exclusion that subtracts concepts from the set. The protocol appendix publishes every concept set as a table with exactly those columns, which is what an ATLAS export looks like.

The protocol appendix holds the same style of table for every other set the cohorts need: metformin, insulin, each comparator ingredient, and each competing drug class. Every clinical phrase in a cohort definition ("prior metformin", "no prior sulfonylurea", "no type 1 diabetes") is backed by its own named concept set.

Rather than doing that by hand, you can paste the finished set straight in. ATLAS offers two import routes, both on the Import tab of a concept set.

If a pasted JSON ever throws a DataTables warning about an unknown parameter, the JSON is missing a field that ATLAS's table expects. The concept identifier route avoids that class of problem, because ATLAS builds the concept records from the vocabulary rather than trusting the file.

ATHENA and the vocabulary, online and offline

ATHENA is the OHDSI vocabulary browser, and it is where the concept IDs above come from. The working pattern for filling a concept set:

1. Search the clinical term and filter to Standard Concepts = Standard; only standard concepts populate the *_concept_id fields your cohorts query.
2. Pick the right level: for drugs, the RxNorm Ingredient (semaglutide, 793143); for conditions, the SNOMED clinical finding (Diabetes mellitus, 201820). Descendants then do the fan-out to dose forms or subtypes.
3. Open the concept page and review its hierarchy and related concepts to decide what descendants will pull in and what needs excluding.
4. Record the concept ID, the source code, and the vocabulary in your concept set table, with the Excluded and Descendants flags decided deliberately.

ATHENA also distributes the vocabulary tables for download (an account is required, and some vocabularies such as CPT4 need a UMLS API key during the download step). Once loaded into a database, three tables answer almost everything: CONCEPT, CONCEPT_ANCESTOR, and CONCEPT_RELATIONSHIP. The queries below use the study's real concept IDs, so you can run them against any OMOP vocabulary and compare. Each task below is shown twice: the point-and-click path in ATLAS, and the SQL for a downloaded vocabulary. Use whichever fits how you work; they answer the same question.

Look up a concept from its source code

SELECT concept_id, concept_name, domain_id, vocabulary_id,
       concept_class_id, standard_concept, concept_code
FROM concept
WHERE vocabulary_id = 'RxNorm'
  AND concept_code = '1991302';   -- semaglutide; expect concept_id 793143

Resolve a concept set: descendants in, exclusions out

-- Type 2 diabetes as defined in the protocol:
-- Diabetes mellitus and descendants, minus T1DM, secondary, and gestational branches
SELECT DISTINCT c.concept_id, c.concept_name, c.vocabulary_id
FROM concept_ancestor ca
JOIN concept c ON c.concept_id = ca.descendant_concept_id
WHERE ca.ancestor_concept_id IN (201820, 443238, 442793, 4016045)
  AND c.invalid_reason IS NULL
  AND c.concept_id NOT IN (
        SELECT descendant_concept_id
        FROM concept_ancestor
        WHERE ancestor_concept_id IN
          (201254, 435216, 40484648, 40484649,
           195771, 761051, 43531009, 4024659)
      )
ORDER BY c.concept_name;

Find which source codes map to your standard concepts

-- Which ICD-10-CM (or other source) codes land on these standard concepts?
SELECT src.vocabulary_id, src.concept_code, src.concept_name,
       std.concept_id AS standard_concept_id, std.concept_name AS standard_name
FROM concept_relationship cr
JOIN concept src ON src.concept_id = cr.concept_id_1
JOIN concept std ON std.concept_id = cr.concept_id_2
WHERE cr.relationship_id = 'Maps to'
  AND cr.invalid_reason IS NULL
  AND std.concept_id IN (793143)   -- swap in any resolved standard IDs
ORDER BY src.vocabulary_id, src.concept_code;

Cohort logic

Here is the semaglutide exposure cohort from the protocol, laid out as the anatomy every ATLAS cohort definition shares. Read it top to bottom as a machine would.

The same structure repeats for each comparator with the drug names swapped. The logic is identical; only the concept sets change.

Anyone can save to the public demo and it is periodically reset, so treat what you find there as a teaching copy rather than the authoritative version. The protocol and the study repository are the record.

The outcome side gets the same rigor. NAION has two definitions, a specific one (two ischemic optic neuropathy diagnoses on separate days within 90 days, with the outcome date pulled earlier if preceded within 60 days by a visual field defect, optic disc disorder, optic neuritis, or optic disc edema) and a sensitive one (a single diagnosis with the same adjustments); both exclude giant cell arteritis and traumatic optic neuropathy. Rather than assuming these definitions work, the study measured their performance with PheValuator.

Windows of exposure and time-at-risk

Separate windows do separate jobs in this study, and keeping them distinct is the point:

• The washout window is the 365 days of continuous observation required before entry. It gives every subject enough visible history to establish "new user" and to build covariates.
• The lookback windows inside the inclusion rules (metformin up to 90 days before entry; class exclusions anytime before entry; the insulin rule's 30-day spans) each encode a specific clinical requirement.
• The time-at-risk is when outcomes count. The primary analysis is on-treatment: from cohort entry until a gap in exposure of more than 30 days, the end of continuous observation, or the end of the study period, whichever comes first. An intent-to-treat analysis is run as well, and a sensitivity analysis splits the study period into calendar windows (December 2017 to January 2020, February 2020 to June 2021, July 2021 to December 2023) because semaglutide uptake changed so much across those years.

Diagnostics and network feasibility

The feasibility work is a set of named diagnostics with numeric thresholds, set in advance and evaluated while blinded to results. A database contributes to the meta-analysis only if it passes.

Feasibility and diagnostic activities in the protocol

• CohortDiagnostics runs on every target, comparator, indication, and outcome cohort to check for measurement error before any estimation.
• PheValuator estimates sensitivity, specificity, and predictive values for both NAION phenotype definitions, replacing "we assume the codes are right" with measured performance.
• Negative controls: exposure-outcome pairs with no expected causal effect, adapted from LEGEND-T2DM through a data-driven algorithm plus expert review, used to estimate and calibrate residual bias.

Pass or fail thresholds for the cohort comparisons

The self-controlled case series has its own gates: a pre-exposure check and a time-trend check, each requiring p above 0.05, plus the same EASE bound. Because every site runs the identical Strategus study package, the network feasibility question becomes concrete: which databases have the cohorts, the follow-up, and the diagnostics results to clear these bars?

The protocol document

Everything above becomes a written protocol, and in OHDSI that protocol is public before the results exist. The SemaglutideNaion protocol is posted as a versioned HTML document, and its structure is the community's working template, so copy it:

• Front matter: abbreviations, responsible parties with institutional affiliations, and a disclosure that the study runs within OHDSI.
• Abstract: background, purpose, design, subjects, methods, and expected conclusions, written in the same shape a journal will later ask for.
• Amendments and milestones: empty sections held open, so later changes are recorded as amendments rather than quiet edits.
• Rationale and background: the trial and observational evidence that motivated the question, with citations.
• Study objectives: the questions restated as numbered objectives.
• Research methods: design, population, exposures, outcomes, covariates, and negative controls, each pointing at the cohort definitions.
• Data analysis plan: which HADES packages run, in what order, with the time-at-risk definition written out.
• Study diagnostics: the pass or fail thresholds, stated before any result is seen.
• Strengths and limitations, human subjects protection, dissemination plan: including that each site seeks its own IRB determination.
• Appendix: every cohort definition in full, printed as entry events, inclusion rules, exits, and concept set tables.

That appendix is what makes the protocol reproducible. A reader can rebuild every cohort from the document alone, without access to the authors' ATLAS instance.

Building and testing the study package

The protocol describes the study; the study package executes it. For this study that package is an R project in a public repository, generated from the OHDSI EmptyStudyRepository template, so its shape matches other network studies:

How a site tests before running

1. Set up R, RTools, RStudio, and Java following the HADES R Setup instructions.
2. Confirm that R can reach the OMOP CDM through DatabaseConnector, before touching the study code.
3. Download the package, open the project, and restore the environment with renv::restore(). The README warns this step is slow and asks you to reopen the project afterward.
4. Run the diagnostics specification first, by swapping which JSON the script loads. This generates the cohorts and their diagnostics without running the estimation.
5. Set minCellCount to your site's own censoring requirement before any results leave.
6. Run the full specification only once diagnostics look right.

Running it across the network

Execution is deliberately uneventful, which is the goal. Each site runs the same specification against its own CDM, writes results into a per-database folder as CSV files, inspects them, and uploads them to the coordinator. Nothing patient-level moves; the minimum cell count censors small counts at the source.

Once results arrive, the coordinator runs the evidence synthesis (evidenceSynthesis.R in this package) and applies the diagnostics gates set in the protocol. Databases that fail the thresholds are excluded from the meta-analysis, and that decision is made while blinded to the estimates. Results are published through the OHDSI results explorer, discussed on the community calls, presented at conferences, and written up as a manuscript.

This study reached the last of those stages: the findings appeared in JAMA Ophthalmology, and the repository badge moved to Results Available. A companion study on diabetic retinopathy followed from the same package.