We foster dialogue between data scientists and researchers in clinics and laboratories in order to drive excellence in health care research at Stanford.
About the Data Studio
The Data Studio is a collaboration between Spectrum (The Stanford Center for Clinical and Translational Research and Education) and the Department of Biomedical Data Science. The Data Studio is open to the Stanford community engaged in biomedical research. We expect it to have educational value for students and postdocs interested in biomedical data science. The Data Studio features DBDS faculty and staff who offer the following services: workshops, office hours, and one-to-one consultations. When you complete the Data Studio request form, our coordinator and consultants will work with you to choose the right service for your research project. Appointments may be requested by completing the required form.
Workshops are an extensive and in-depth consultation for a Medical School researcher based on research questions, data, statistical models, and other material prepared by the researcher with the aid of our facilitator. During the Data Studio Workshop, the researcher explains the project, goals, and needs. Experts in the related topic from across campus will be invited and contribute to the brainstorming. After the meeting, the facilitator will follow up, helping with immediate action items and summary of the discussion. Ultimately, we strive to pair each PI with a data scientist for long-term collaboration.Office Hours are brief consultations for Medical School researchers during the last session of each month. DBDS faculty are available to advise about your research questions. Consult the schedule below to complete the Office Hour registration form. Once you have registered, you will receive a calendar invitation with the date, time, and location of the session. Bring any data, prior analyses, or other materials that you have. Our consultants may even recommend your project for a Workshop if it is appropriate.
One-to-one consultations for Medical School researchers are available year-round. Our facilitator assigns each request to a data scientist with the relevant expertise.
Partners
General questions about statistical issues may be brought to the STAT390 Consulting Workshop. This is a class offered by the Department of Statistics during each academic quarter that is staffed by graduate students and directed by a faculty instructor. The service typically consists of a single meeting with the researcher to address a specific concern, such as planning of experiments and data analysis. For more information, consult the STAT390 Consulting Workshop web page.
Researchers who are members of the Stanford Cancer Institute (SCI) conducting research projects related to cancer may request assistance from the SCI Biostatistics Shared Resource.
The Genetics Bioinformatics Service Center (GBSC) offers an end-to-end bioinformatics consulting service (BaaS) that provides high performance computational infrastructure and cutting-edge bioinformatics services for the Stanford community. The team consults on genomics, transcriptomics, proteomics, epigenetics, and metabolomics projects, and also develop custom workflows. For consulting and hands-on bioinformatics help with your projects please reach out to gbsc-baas-team@lists.stanford.edu to set up an initial meeting.
Schedule
The Data Studio is held each Thursday from 3:00 until 4:30 pm during the fall, winter, and spring quarters of the academic year. Consult the schedule below for the location of each session. Students may participate by enrolling in BMDS 291 for an introduction to the art of statistical consultation and practicum working on projects with a biomedical researcher. All are welcome to attend. Click here to sign up for our mailing list.
The currently scheduled topic is listed below.
TITLE: Target Trial Emulation of Preoperative Anemia Optimization Strategies to Prioritize Prospective Randomized Trials
INVESTIGATORS:
Philip Chung (1)
Nima Aghaeepour (1)
Anil Panigrahi (1)
(1) Anesthesiology, Perioperative and Pain Medicine
DATE: Thursday, 1 October 2026
TIME: 3:00–4:30 PM
LOCATION: Room R358, Edwards Building, 300 Pasteur Drive, Stanford, CA
WEBPAGE: https://dbds.stanford.edu/data-studio/
ABSTRACT
The Data Studio Workshop brings together a biomedical investigator with a group of experts for an in-depth session to solicit advice about statistical and study design issues that arise while planning or conducting a research project. This week, the investigator(s) will discuss the following project with the group.
Introduction
Preoperative anemia identifies patients with reduced physiologic reserve. Reduced oxygen delivery may be particularly consequential in patients with cardiovascular or cerebrovascular disease. Building on the 2026 AHA scientific statement on anemia and patient blood management in cardiac surgery, we will study elective cardiac and noncardiac procedures to identify which patients, treatment strategies, and initiation times warrant prospective randomized evaluation. Whether correcting anemia improves cardiovascular or brain health remains a research question. [1]
We propose a prespecified family of target trial emulations (TTEs) using longitudinal Stanford electronic health records. A target trial emulation specifies the trial we would like to run and aligns eligibility, treatment strategies, follow-up, and analysis in observational data. It can generate useful comparative evidence under explicit causal assumptions; it does not reproduce randomization. The core policies concern new initiation of intravenous iron, oral iron, and selected iron plus erythropoiesis-stimulating agent strategies.
Hypothesis and aims
Hypothesis: Effects on cumulative allogeneic red blood cell (RBC) burden and hemoglobin recovery vary with treatment timing, baseline anemia phenotype, and planned procedure. Cardiovascular and brain health outcomes will remain secondary.
Aim 1. Estimate preoperative anemia policy effects and map their credibility. Aim 1a will compare clinically coherent initiation policies within planned-procedure populations using LTMLE (longitudinal targeted maximum likelihood estimation). Aim 1b will classify each population × policy contrast × outcome × follow-up window as Supported, Estimable but fragile, or Not credibly estimable and identify specific prospective trials to pursue. Contrasts with strong design credibility, treatment support, adequate effective sample size, and precise, robust estimates may also provide credible observational evidence of comparative effectiveness, subject to the stated causal assumptions.
Aim 2. Benchmark the full emulation framework against randomized evidence. Aim 2a will conduct prespecified PREVENTT, FIT, and ITACS emulations with trial-specific eligibility, treatments, outcomes, and follow-up. Aim 2b will assess design fidelity, statistical performance, and clinical concordance while comparing three patient representations. Each aim has a separate deliverable; Aim 1 does not depend on favorable benchmark agreement. [2–4]
Dataset
The Stanford Perioperative Data Ecosystem (SPeDE) combines STARR-OMOP longitudinal EHR data, Multicenter Perioperative Outcomes Group (MPOG) data, and Epic Clarity information, including blood product units and types. It covers anesthetic care from 2012 onward and includes laboratory values, medications, vital signs, notes, and diagnostic and billing codes across perioperative encounters. As of May 2026, the source contains approximately 380,000 patients and 670,000 anesthetic cases. These are source totals, not the eligible study sample; cohort and treatment counts require a feasibility audit.
SPeDE also contains cancelled cases, and case-event logs may recover prior scheduled dates. We will quantify recovery reliability before choosing the analytic cohort. Linked death records are available; other outcomes are principally institution-recorded. The PI maintains SPeDE with Stanford Research IT. Analyses will use the institutionally approved research environment; extract dates and governance details will be finalized.
Population and timing: Adults with planned elective index procedures and Hb <13 g/dL documented by eligibility. We propose a common baseline eight weeks (56 days) before the operation date known at baseline; a separate 30-day design is the feasibility fallback. Laboratory look-back is separate from baseline timing and uses only information available by baseline. Initiation windows are 0–1, >1–2, >2–4, and >4–8 weeks before the baseline planned date, operationalized as 0–7, 8–14, 15–28, and 29–56 days. Day-0 treatment must precede procedure start. Later procedures within the same 30-day episode contribute to outcomes rather than becoming new index cases.
Policies and strata: IV iron spans all four windows; oral-versus-IV comparisons prioritize the two earlier windows. A selected IV iron plus ESA comparison will be restricted to patients eligible for both strategies. Initiation means administered IV iron or ESA, or a new oral-iron prescription; it does not require future regimen completion. Chronic treatment is a prespecified baseline modifier and defines separate augmentation questions, rather than being treated as new initiation.
Outcomes: The primary outcome is cumulative allogeneic RBC burden. The proposed main policy analysis follows everyone from eligibility through baseline planned surgery date plus 30 days; a complementary surgical-episode analysis follows actual surgery plus 30 days and uses the planned-date horizon for cancellations. Key secondary outcomes are Hb recovery, a prespecified clinical cardiovascular composite, and postoperative delirium within 7 days. Mortality and surgery occurrence accompany RBC results. Exact outcome phenotypes and intercurrent-event rules remain to be locked.
Statistical models
LTMLE will combine sequential outcome regressions with treatment and censoring models to estimate mean outcomes under each policy. Structured clinical variables will be retained in every model. Three representations will be compared: clinical variables alone, clinical variables plus pooled EHR embeddings, and clinical variables plus temporally encoded EHR histories. Information must precede each modeled decision. Patient-level cross-fitting will separate model fitting from evaluation. Python is preferred for deep learning, with R targeting and inference considered after a longitudinal prototype. [5]
Important assumptions include adequately measured confounding, support for each policy along relevant histories, well-defined treatment versions, and defensible outcome ascertainment. Embeddings and LTMLE do not establish these assumptions. The detailed companion document provides the policy and population tables, equations, credibility algorithm, and the current proposed approach.
Statistical questions
These questions concern causal identification, estimation, uncertainty, and inference. Clinical specifications and implementation questions appear separately below. Bullets describe candidate directions for consultation.
1. How should time zero and initiation policies be defined to avoid timing bias?
Align eligibility, policy assignment, and follow-up at the proposed 56-day baseline; evaluate the separate 30-day design and implications for the target population.
Define the within-window initiation distribution and rules for intervening surgery, contraindications, and death. Assess sensitivity to narrower windows and uncertain scheduling histories.
2. Which estimands and observation models should be used?
Use a fixed planned-date horizon for the main policy analysis and actual-surgery follow-up for the complementary analysis; distinguish their estimands and selection assumptions.
Select Hb trajectory summaries and methods for informative measurement, missing outcomes, death, and surgery-dependent delirium observation. Address incomplete outside-institution care.
3. How should longitudinal effects and uncertainty be estimated?
Use LTMLE with outcome, treatment, censoring, and observation models; compare three representations with patient-level cross-fitting and shared clinical covariates.
Choose time resolution, nuisance-learning and tuning procedures, and inference for count outcomes and repeated episodes. Evaluate bias and interval coverage through simulation.
4. How should subgroup effects and procedure clusters enter inference?
Estimate prespecified interactions and subgroup policy means using shared nuisance models; avoid interpreting subgroup significance differences as interactions.
Assess cluster stability and treatment overlap. Address data-adaptive subgroup construction, small strata, and how overlap restriction changes the target population.
5. How should precision and credibility be calibrated?
Assess support, effective sample size, event information, influence concentration, clinically scaled precision, and robustness for each population × contrast × outcome × horizon.
Calibrate diagnostic thresholds in simulations. Evaluate the proposed three-tier algorithm and sensitivity analyses; clinical effect scales remain deferred pending clinical input.
6. How should multiplicity be controlled across the grid?
Define one false-discovery-rate family for core contrasts and formal outcomes, with RBC burden primary; specify its level and handling of nonestimable comparisons.
Use Benjamini–Hochberg (BH) if its dependence conditions hold, or Benjamini–Yekutieli (BY) for general dependence. Specify which Hb summary enters formal testing.
7. How should concordance with randomized trials be quantified?
Compare matched emulated and randomized effects using effect differences, uncertainty, and prespecified clinically meaningful concordance margins.
Assess estimator performance and representation differences with fixed target trials, simulation, and held-out diagnostics. Avoid tuning models to reproduce published trial effects.
Clinical specification questions
These choices require clinical input to define meaningful interventions, populations, and outcomes. They inform the statistical analysis but are not primarily statistical questions.
C1. Which treatments and contrasts are clinically appropriate?
Review the seven proposed priority contrasts, deferral until actual surgery or the baseline planned date, and clinical exceptions. Retain rescue transfusion in every arm.
Define pooled formulations, therapeutic doses, ESA indications and agents, iron/ESA ordering and lag, and subsequent usual care. Review any additional timing windows and future-trial priorities.
C2. Which clinical definitions and effect scales should be used?
Set laboratory recency, age-applicable anemia severity, iron-phenotype thresholds, chronic-use definitions, background treatment, and eligibility for augmentation comparisons.
Define cardiac and delirium phenotypes, Hb windows, whole-blood RBC conversion, and clinically meaningful effect scales. Adjudicate procedure-cluster labels and boundary cases.
Data and implementation questions
These questions concern whether the required data can be recovered and how the prespecified analysis will be executed reproducibly.
I1. Can the required cohort histories and outcomes be recovered?
Audit booking logs and cancellations; quantify eligible patients at 56 and 30 days, treatment by timing and procedure, laboratory coverage, and chronic-treatment history.
Extract administration and prescription records, dose and formulation, transfusions, death linkage, and delirium assessments. Validate phenotype extraction and document data coverage.
I2. How should the software and data pipeline be built?
Prototype Python nuisance models with R longitudinal targeting; define prediction interfaces, longitudinal data structures, patient identifiers, and reproducible execution.
Implement the selected temporal encoder and pooling scheme, patient-level fold assignments, training-only tuning, and leakage checks. Verify the pipeline against the statistical simulation specification.
I3. How should benchmark and credibility reviews be operationalized?
Retrieve PREVENTT, FIT, and ITACS protocols, supplements, and corrections; map eligibility, treatments, outcomes, and follow-up to SPeDE and record discrepancies.
Assign reviewers for design and measurement gates, retain evidence and reasons for each classification, and version the protocol and model specifications before comparative analysis.
ZOOM MEETING INFORMATION
Topic: BMDS 291A: Data Studio
Join from PC, Mac, Linux, iOS or Android: https://stanford.zoom.us/j/95373246516?pwd=2X8q3J22JJ5a5s46a7FVSepBz2PBBS.1
Password: 019839
Or iPhone one-tap (US Toll): +18333021536,,95373246516# or +16507249799,,95373246516#
Or Telephone:
Dial: +1 650 724 9799 (US, Canada, Caribbean Toll) or +1 833 302 1536 (US, Canada, Caribbean Toll Free)
Meeting ID: 953 7324 6516
Password: 019839
International numbers available: https://stanford.zoom.us/u/awM3GZjwI
Meeting ID: 953 7324 6516
Password: 019839
SIP: 95373246516@zoomcrc.com
Password: 019839
