8 Ethics

We often work with sensitive health data from vulnerable populations — people whose information and trust we can’t take lightly. We have to produce good science and protect the people whose data we use. Those aren’t separate obligations.

8.1 Research Ethics and Responsible Conduct of Research

Responsible conduct of research (RCR) covers how we design studies, handle data, run analyses, and report findings. The short version: don’t cut corners, and document what you do. In computational epidemiology, this means:

Design and planning: Being thoughtful about research questions and methods upfront. Don’t retrofit a hypothesis to fit your results.
Data stewardship: Handling data carefully — research participants and institutions gave us access, and we owe them rigor. We document our analyses, maintain data integrity, and report findings honestly — including null results and limitations.
Authorship and attribution: Being clear about contributions and honest about who did what. Co-authors take responsibility for the work we publish together.
Reproducibility: Writing code and documentation that allows others (and our future selves) to understand and verify our work. If somebody wants to check our work, they should be able to. This builds trust in our science.

Fabrication, falsification, and plagiarism can be career-ending.¹ They also make it harder for everyone else to get their work taken seriously.

8.2 Human Subjects and IRB

Many projects in this lab involve human subjects or their data. We have a legal and ethical obligation to protect participants and minimize risks.

Here’s what this means for you:

If you’re designing a study involving human subjects, surveys, interviews, or human-derived data, we need IRB approval before you begin. This is non-negotiable.
We submit protocols through Stanford’s eProtocol system. I’ll help you with this, but it requires thinking carefully about: Who are your participants? What are the risks? How will you protect confidentiality? What informed consent (if any) do they receive?
Some projects may qualify for expedited review, exemption, or a human subjects determination if they involve minimal risk or existing data without identifiers. But that’s for the IRB to decide, not us.
You should always use the data with the lowest risk surface for answering your question. If ecological or public-use deidentified data will answer the question, use that. If you need individual-level data, but it can be deidentified, use that. So on and so forth. We only use RIF or identifiable data in rare circumstances when it is necessary to answer our research question.

Even if you think a project doesn’t need IRB oversight, check with me or the IRB.

8.3 Data Privacy and Security

We handle sensitive health data. This is a privilege and a responsibility. We often access these data through the Center for Population Health Sciences or the US Census Bureau. When doing so, you must adhere to the rules of the data provider, without exception.

More generally, here’s how we approach data privacy:

HIPAA and Protected Health Information (PHI):

If we’re working with data from healthcare systems, patient records, or anything derived from patients, it likely contains PHI (Protected Health Information). HIPAA rules apply.
We only access and use PHI for purposes explicitly approved in our IRB protocol. No side analyses, no exploratory work with restricted data unless approved.

Restricted Data Enclaves:

Some of our data lives in restricted data enclaves — secure computing environments where you can access sensitive data without downloading it to your laptop. This can be PHS’s secure data environment or the US Census Bureau’s FSRDC. Always adhere to the rules of the data and computational environment.

General data security practices:

Use strong passwords. Use multi-factor authentication on accounts with sensitive data.
Your laptop should always be encrypted.
Don’t email health data or identifiable information.
Document what data you have, where it lives, who can access it, and when you’ll delete it. Data retention timelines matter legally and ethically.
De-identify or aggregate data whenever possible for analyses and papers.

AI tools are “somewhere else,” too

Never paste PHI, identifiable, DUA-restricted, or enclave data into a general AI tool — even a Stanford-approved one. A tool being approved for a class of data is not permission for your dataset, and the data provider’s terms and your IRB always win. For PHI, the only approved destination is Stanford Health Care Secure GPT. See What data goes in which tool for the full rules.

Data breaches happen. If you suspect you’ve exposed sensitive data — even accidentally — tell me immediately. Don’t panic or hide it. We’ll figure out what happened and what to do next.

8.4 Conflicts of Interest

We all have lives outside the lab. The issue is when those outside interests could bias our research or create divided loyalties. Stanford takes this seriously.

Financial conflicts: If you receive funding, consulting fees, stock, or other payments from companies related to your research, disclose it. This includes work outside Stanford.
Personal relationships: Close relationships with collaborators can create dynamics that affect research judgment. Be transparent about these.
Other commitments: If you’re doing significant outside work, we should talk about how it fits with your lab responsibilities.

You’ll fill out a conflict of interest form when needed. This isn’t about accusing you of wrongdoing — it’s about transparency so we can sort out any conflicts before they become problems. Many conflicts can be managed; the problem is hiding them.

Always err on the side of overdisclosure.

8.5 AI and LLM Use in Research

Three things I’ll always expect

AI use in research is changing fast. This policy will adapt as we learn more, but I will always expect three things:

you are responsible for your work,
you disclose your AI use, and
you assume anything you put into an AI tool will be made public.

Large language models and AI tools are increasingly part of how we work and do research. They can help with code, writing, and analysis — but they hallucinate, produce subtle errors in code, and make it harder to reproduce your work if you’re not careful.

Further, in computational epidemiology, writing is thinking and coding is researching. Those activities are difficult but necessary components of the research process. Outsourcing them to AI will generally lead to poorer research products because literally writing down your arguments helps you strengthen them and coding and running into errors will help you understand your data.

That said, AI can be genuinely useful. It is good at helping with many of the mechanical parts of research — cleaning up syntax, reformatting a table, translating, polishing prose you’ve already reasoned through. It can be a handy teaching aid — you can ask it to explain why one coding approach was faster or how to implement a new statistical procedure (which you then actually do yourself). It can be an analytic tool — we have projects where we use LLMs as tools to classify text for us or to extract data from PDFs or complex JSON objects. The problem is outsourcing the thinking. When you transfer that responsibility to an AI by letting it draft an argument, interpret a result, or reason through a bug, you skip the friction that makes learning stick, the science sound, and your arguments smooth.

8.5.1 The clear rules

Most of your AI use will come down to your objectives, your judgment, and our conversations. However, there are some uses of AI that are absolutely non-negotiable.

Never:

Put work you’re reviewing into an AI tool. Not a manuscript submission, not a grant application, not a study protocol. Nothing you’re reviewing for a journal, funder, or colleague should be run through an LLM. This is a confidentiality issue, and most funders and journals explicitly prohibit it.²
Paste restricted data into a tool that isn’t cleared for it. No PHI, identifiable, or DUA-restricted data, and nothing from a secure compute environment, goes into an AI tool unless the tool is explicitly approved for that data and your data use agreement allows it. When in doubt, ask me.
List AI as an author. It can’t take responsibility for the work, so it can’t be an author. AI use is always disclosed and never named as a coauthor on a paper.

Always:

Use our approved tools for lab work. Stanford’s enterprise and education tools, not your personal or free accounts. Free tiers often train on whatever you give them access to.
Verify everything. AI makes mistakes and makes things up. You are responsible for every number, citation, and line of code, whether or not an AI touched it.
Disclose your use (more in the next subsections).
Respect other people’s choices. Get a collaborator’s OK before running their work through an AI. Some people don’t want an early project anywhere near one for fear of getting scooped; some grants contain data the author won’t put through a tool. We respect that.

8.5.2 What data goes in which tool

First, the data provider’s terms and your IRB protocol always win. Many of our data use agreements — CMS, Census, state health departments, data brokered through PHS — forbid sending data to any third party, and that includes a Stanford-approved, contract-covered AI vendor. A tool being approved for a class of data is not permission for your dataset. And data in a secure enclave (the FSRDC, the PHS secure environment) never leaves the enclave through an AI tool — not the data, not preliminary output, nothing. When you are unsure whether a dataset can go into a tool, ask me before you paste, not after.

For other cases, Stanford classifies data as Low, Moderate, or High risk. Two things are worth remembering — unpublished research data is Moderate, and anything identifiable or containing PHI is High. If a dataset mixes levels, it takes the highest level present.

Here’s where our data can go, as of July 2026. Stanford revises this often, so confirm against the current guidance before you rely on it.

Data	Where it can go
Public / already published	Any approved tool; public or free tools are fine (but assume anything you type becomes public)
Low or Moderate risk (incl. unpublished data, code, drafts)	Stanford enterprise/education tools only (ChatGPT Edu, Gemini Enterprise, Claude, or the AI Playground); never personal or free accounts
High risk (identifiable, not PHI)	Only a Stanford tool explicitly approved for High-risk data, and only if your DUA and IRB allow it — ask me first
PHI / clinical data	Stanford Health Care Secure GPT only; never public tools, and never a general tool unless it is explicitly cleared for PHI

When in doubt, ask.

8.5.3 Disclosing AI use

If you used AI in a meaningful way, say so. Spellcheck, grammar checks, or reformatting references have never needed disclosure, and using AI for the same tasks doesn’t either. But once AI helps shape your research question, generate text, write analytic code, etc., you should disclose it.

To make this a bit more concrete, here’s approximately how I would grade AI use (as of July 2026):

What AI helped with	Example	What to do
Fix grammar, spelling, formatting	Cleaning up typos, reflowing a table	No disclosure needed
Polish or translate prose you wrote	Tightening readability of your own draft	Worth disclosing to a journal
Find or summarize literature	Triaging papers you then read yourself	Verify every citation, and disclose if you cite one of those papers or it informed your thinking
Write or debug analytic code	Copilot drafts a function you review and test	Disclose the tool and version in the code, cover letter, and potentially acknowledgements
Process data as a tool	Classifying free text, extracting from PDFs/JSON	Disclose in Methods, with your validation approach
Generate or alter a figure/image	AI creates or edits an image	Don’t do it
Draft scientific text	AI writes an argument or a whole section	Not illegal, but please don’t do it
Interpret results or produce numbers	AI decides what a finding means, or generates statistics	Don’t do it

If you want a more formal way to think this through, GAIDeT — the Generative AI Delegation Taxonomy — breaks the research process into stages (conceptualization, literature review, methodology, data analysis, writing, supervision, ethical review) and can generate a standard disclosure statement.³ As of now, we don’t require GAIDeT or other formal disclosure mechanisms, but we may in the future. I think they’re just good practice.

When you disclose, record four things: the tool, its version, when you used it, and what you used it for. For example — “Claude 4.8 was used to optimize the primary simulation functions,” or “We used GPT-5 (OpenAI, June 2026) to classify free-text responses; two authors validated a random sample.”

Where the disclosure goes depends on the journal. Some want it in the Methods, some in the Acknowledgments, some in the cover letter, some in a standalone declaration before the references. Always check the journal’s requirements — and because they differ, that’s one more reason to use a formal disclosure tool.

To give you some examples, I looked up a handful of journal and publisher policies (as of July 2026):

Journal / publisher	Where disclosure goes	AI-generated images	Notable
JAMA Network	Acknowledgment (writing) or Methods (study)	Disclose	Exempts basic grammar/spelling/reference tools
NEJM / NEJM AI	Cover letter + manuscript	—	NEJM AI actively encourages disclosed LLM use
The Lancet	Standalone declaration above references	Not allowed	AI only for language/readability, not analysis
AJE	Cover letter + Methods or Acknowledgements	Disclose	“Will screen for” AI in author lists
IJE	Declaration at the end of the text	Disclose	Author remains fully liable
BMJ	Methods; also a question in the submission form	Disclose	—
Nature / Springer Nature	Methods	Restricted	Copy-editing is exempt from disclosure
Science	Cover letter + Methods/Acknowledgments	Needs editor permission	Reversed its 2023 outright ban
Elsevier journals	Standalone declaration above references	Not allowed	Reviewers may not use AI at all

Always check the journal for updated policies.

8.5.4 Working with AI coding assistants

A coding assistant (Copilot, Claude Code, ChatGPT) is one of the most useful and dangerous ways to use AI. Useful, because it can generate your code infrastructure quickly. Dangerous, because it writes plausible code that is subtly wrong and often overengineers code (beyond the needs of reproducible scientific code) that quickly adds insurmountable technical debt to your project. Importantly, these agentic tools can interact with your environment — read files, run commands, make network calls — not just suggest.

A few simple practices can keep you safe:

Read it before you run it. Never run or commit code you don’t understand. Scientific coding is about interpretability, debuggability, and readability. Optimizing for speed or being clever is rarely useful in an academic setting.
Pay attention to what a coding agent can reach. Don’t give an agent access to sensitive data, credentials, or API keys, and don’t blindly click through its permission prompts.
Stay inside the data rules. Everything in What data goes in which tool applies here too — an assistant working in your repo is still a tool you’re feeding data.

8.5.5 Why I’m cautious

There’s a lot of space in this lab manual dedicated specifically to AI. It may be helpful for me to be explicit about why I’m cautious and skeptical of widespread AI use in academic settings.

The work is the learning. In science, writing is thinking. You have to write down your arguments to identify their weaknesses and logical gaps. Similarly, struggling with debugging code is how you learn to write better code and find issues with your data. The friction is the point, and the work is how you get better. You are here to get better. Some studies suggest AI use can improve what you produce while quietly eroding what you learn (Bastani et al. 2025; see Further Reading). Here, your job is not to produce but to learn. My goal is for you to become the person who can catch the model’s mistakes.

AI output isn’t reproducible. The same prompt often gives different answers. Models frequently get updated and deprecated. AI-assisted code is reproducible because you keep and rerun the actual analytic code. AI-generated results are not. Use AI to help you write code you then run deterministically — never to produce the result directly.

AI can insert bias into your science. We study health inequities. LLMs are trained on data and text that carry the same biases we study — they have been shown to reproduce debunked, race-based medicine (Omiye et al. 2023). They also tend to perform worse for the populations we care most about, echoing the algorithmic bias already documented across health care (Obermeyer et al. 2019). A model that confidently reproduces a biased assumption will inevitably insert that bias into your paper.

8.5.6 A moving target

Rules about AI use are shifting quickly as AI capabilities and our understanding of them change. When rules disagree (e.g., between journals, funders, the IRB, a DUA, or Stanford), follow the strictest one and contact me so we can sort it out. Treat this text as a living, likely out-of-date, document.⁴

8.6 Questions and Concerns

Ethics questions don’t have perfect answers. If you’re unsure about something, talk to me. It’s always better to have the conversation than to second-guess yourself later.

Or at least they should be. If you’re ever unsure about research practices, ask me.↩︎
NIH prohibits generative AI in the peer review of grant applications (NOT-OD-23-149); NSF prohibits uploading proposal content in merit review. Most journals say the same.↩︎
Suchikova et al. (2025), “GAIDeT (Generative AI Delegation Taxonomy),” Accountability in Research, doi:10.1080/08989621.2025.2544331. The declaration generator is at https://panbibliotekar.github.io/gaidet-declaration/.↩︎
Last reviewed: July 2026. If a tool, link, or rule here is out of date, tell me and we’ll fix it.↩︎