IRB and Compliance Errors That Can Derail Student Projects

Most student research projects don’t fail because the idea is bad. They fail because someone ignored IRB and compliance rules and only realized it when it was too late.

(See also: Common Authorship Mistakes That Burn Bridges With Mentors for more details.)

If you remember nothing else, remember this: no amount of good data can rescue a project that was done without proper approval and compliance. You can’t “fix it later.” You can’t “ask forgiveness instead of permission.” In research involving humans, that mindset kills manuscripts, jobs, and sometimes careers.

You’re entering a world where process matters as much as results. Let’s go through the most common IRB and compliance mistakes premeds and medical students make—and how to avoid blowing up your own project before it ever makes it to publication.

---

Mistake #1: Assuming “It’s Just a Student Project, So IRB Doesn’t Matter”

This is the classic beginner error. Deadly and completely avoidable.

The Wrong Assumption

Students often think:

• “It’s only a quality improvement project.”
• “We’re just doing a chart review.”
• “It’s for a class, not real research.”
• “We’re not publishing—just a poster at school day.”

That logic sounds harmless. It is not.

If your project involves data about humans, you should never assume it’s exempt from oversight.

What Happens When You Skip IRB?

The usual scenario:

• You collect months of data “for a project.”
• Near the end, someone suggests turning it into a publication.
• A journal or conference asks: “Was this IRB-approved?”
• You answer: “No, we didn’t think we needed it.”
• Outcome: automatic rejection. And your mentor is not thrilled.

Worse scenarios:

• Your institution views it as noncompliant research.
• You may be barred from using the data at all.
• Your name gets quietly added to the list of “students who don’t follow procedure.”

You don’t want that label.

How to Avoid This

1. Ask early, in writing.
   Email your institution’s IRB office with a brief description and ask if formal review or an exemption is needed. Keep their response.

2. Use your institution’s “Is this human subjects research?” tool if available.
   Many IRBs have decision trees or online forms. Don’t guess.

3. Never rely on hallway advice.
   “My friend said chart reviews don’t need IRB” is not a policy. Get official clarification.

If you’re unsure whether IRB applies, treat that uncertainty as a red flag, not an excuse.

---

Mistake #2: Starting Data Collection Before IRB Approval Is Final

This one ends careers before they even start. It’s also shockingly common.

The Deadly Sequence

Students often:

1. Submit an IRB protocol.
2. Get “pending” or “modifications required.”
3. Start the project anyway “to save time.”
4. Assume the IRB will approve eventually and backdate mentally.

Here’s the uncomfortable truth: any data collected before IRB approval is usually unusable.

Journals, conferences, and IRBs all see the same bright red line:

• No human subjects research activities (recruitment, consent, data collection, access to identifiable records) before official IRB approval date.

If you do it anyway, you’ve created noncompliant data that may be permanently tainted.

Common Rationalizations (Don’t Fall for These)

• “We’re just piloting the process.”
  If you’re collecting real data from real patients, it’s not a harmless “pilot” without oversight.

• “The risk is minimal, so it’s fine.”
  The level of risk doesn’t erase the requirement for review.

• “We already know they’ll approve it.”
  You don’t know that. Even if they would have, they can’t retroactively approve what’s already happened.

How to Avoid This

• Wait for the official approval letter.
  Not an email saying “looks good,” not a verbal “should be fine”—you need the document with the approval date and protocol number.

• Clarify what you can do while waiting.
  Often you can:

  • Build data collection tools
  • Draft surveys (but not send them)
  • Plan workflows But you cannot:
  • Recruit subjects
  • Access identifiable data for research
  • Perform study interventions

• Ask your mentor directly:
  “Has the IRB approval letter for this specific protocol number been issued yet?”
  Don’t accept vague answers.

If there’s any doubt, don’t touch the data.

---

Mistake #3: Misunderstanding “De-Identified,” “Anonymous,” and “Retrospective”

Students love to say “it’s de-identified” as if that magically removes all oversight requirements. That’s not how it works.

The Terminology Trap

Here are the critical distinctions most students blur:

• Anonymous
  No one, including the research team, can ever link the data back to a person. Not through codes, not through a master list, not through login IDs. Truly unlinked.

• De-identified
  Direct identifiers (name, MRN, DOB, etc.) have been removed, but:

  • Data may still be coded
  • Someone (often a data manager) may hold a key This can still be considered human subjects research.

• Retrospective
  Data collected in the past, usually from existing records.
  Retrospective does not mean “no IRB needed” by default.

Mislabeling your project to avoid IRB is a giant red flag.

Typical Student Errors

• Calling a data set “anonymous” when there’s a code linking each record to the patient.
• Assuming any retrospective chart review = exempt from IRB.
• Ignoring the fact that some combinations of data points (age + rare disease + hospital unit) can re-identify individuals even without names.

Compliance Consequences

Journals are increasingly strict:

• Many now ask:
  • Was the study IRB approved?
  • Was a waiver of consent granted for retrospective use of medical records?
• If you answer no or can’t document it, your paper dies.

If your institution audits your project and finds you accessed identifiable data for research without proper determination, you may:

• Lose permission to collect more data
• Be unable to present or publish
• Damage your PI’s relationship with the IRB

How to Avoid This

• Have the IRB formally classify your study.
  They can decide:

  • Not human subjects research
  • Exempt
  • Expedited
  • Full review

• Be honest and complete in describing the data.
  Include:

  • Who will access it
  • How it’s stored
  • Whether any coding/keys exist
  • Whether the data is fully anonymized

• Don’t make your own regulatory calls.
  Your job is not to outsmart the IRB; your job is to comply with it.

---

Mistake #4: Poor Handling of PHI and Data Security

You can design a perfect study and still blow everything by mishandling Protected Health Information (PHI).

Common Student Behaviors That Are Not Okay

• Emailing spreadsheets containing:

  • MRNs
  • DOBs
  • Names from personal or unsecured email accounts.

• Storing data:

  • On personal laptops with no encryption
  • In Google Drive, Dropbox, or iCloud not approved by your institution
  • On USB drives that float between computers

• Taking screenshots of EHR data and sending them in group chats or messaging apps.

All of this can violate HIPAA and institutional policy. One file sent the wrong way can trigger a reportable breach.

Why This Matters for You

You might think: “The institution will be in trouble, not me.” That’s naïve.

Consequences can include:

• Being removed from the project
• Being banned from future research at that institution
• Not being allowed to access the EHR for research again
• A “problem” note in your file that’s invisible to you but visible to program leadership
• In extreme cases, professionalism concerns that follow you into residency applications

How to Avoid This

• Only use institution-approved storage and tools.

  • Secure servers
  • IRB-approved REDCap instances
  • Institution-provided encrypted laptops or drives

• Use your institutional email exclusively for research data.
  Don’t forward PHI to Gmail, Outlook, or personal accounts “just for convenience.”

• Ask your mentor explicitly:
  “Where exactly should I store the dataset?”
  “What’s the approved way to transfer data between us?”

If you feel tempted to “just send it quickly” another way, that temptation is your warning.

---

Mistake #5: Treating Consent as a Script Instead of a Process

Consent isn’t a checkbox or a piece of paper. It’s an ethical obligation and a legal requirement.

What Students Commonly Mess Up

• Rushing the consent process because they’re behind schedule or “just need more subjects.”
• Not using the IRB-approved consent form or language.
• Altering or “simplifying” consent language without re-submitting to the IRB.
• Failing to document consent properly, especially with:
  • Oral consent
  • Electronic consent
  • Waivers of written consent

And the worst one:

• Coercing participation—subtly or overtly—especially with:
  • Your own classmates
  • Patients who see you as part of their clinical care team
  • Subordinates (e.g., premeds or undergrads you help supervise)

Real-World Impact

If a participant later complains:

• “I didn’t understand I was in a study.”
• “I felt pressured to say yes.”
• “I didn’t know my data would be used this way.”

Your IRB can:

• Suspend the study
• Require corrective actions
• Restrict your involvement in research
• Inform your dean’s office

Your reputation as a trustworthy researcher can be damaged overnight.

How to Avoid This

• Use only IRB-approved materials as written.
  Don’t invent your own consent form because “this seems clearer.”

• Learn and follow the consent documentation rules for your specific project:

  • Who can obtain consent?
  • Is verbal consent allowed?
  • Do subjects get a copy?
  • How is consent stored?

• Watch your tone and position.
  When approaching participants:

  • Make clear that their care or evaluation will not be affected if they say no.
  • Avoid recruitment during vulnerable moments (e.g., right after bad news).

If you ever feel like you’re “talking someone into it,” step back. That feeling is your warning signal.

---

Mistake #6: Ignoring Amendments and “Scope Creep”

Your project will evolve. That’s normal. What’s not okay is letting it drift far from the approved protocol without notifying the IRB.

How Scope Creep Happens

You start with:

• A simple retrospective review of adult patients with condition X at one hospital.

Six weeks later, someone suggests:

• Expanding to:
  • Additional hospitals
  • Pediatric patients
  • New variables (mental health diagnoses, substance use)
• Adding follow-up surveys
• Including identifiable follow-up phone calls

Suddenly the real project looks nothing like what the IRB approved.

The Dangerous Mindset

Students tell themselves:

• “It’s basically the same study.”
• “We’re just adding a few variables.”
• “It’s still low-risk.”

That judgment is not yours to make. Once you change:

• Sites
• Population
• Methods
• Data collected
• Who has access to what

You may need a protocol amendment, or even a new protocol.

What Can Go Wrong

If discovered:

• Data collected under unapproved conditions may be unusable.
• Your PI may insist on dropping all data collected after unapproved changes.
• Journals can question the integrity of your methods when they see mismatches between what was approved and what you did.

How to Avoid This

• Before changing anything substantive, ask:
  “Does this require an amendment to the IRB?”
  Let your PI or IRB office answer, not you.

• Treat each change like a potential compliance event.

  • New survey or instrument? Ask.
  • New data elements from the chart? Ask.
  • New population added? Definitely ask.

• Keep a record of what version of the protocol you’re following and when amendments were approved.

If you can’t clearly say “yes, this activity is covered under the currently approved protocol,” pause and clarify.

---

Mistake #7: Assuming Your Mentor “Has It Covered”

This one is subtle and dangerous. Many students assume: “My PI is experienced. They’ll handle the IRB stuff.” That assumption can backfire on you personally.

The Reality

Yes, the PI carries ultimate responsibility. However:

• Students are the ones:
  • Extracting data
  • Contacting participants
  • Handling spreadsheets
  • Transporting files

You’re the person most likely to commit a hands-on violation, even if unintentionally.

Also, not every faculty member is as organized or compliant as you’d hope. Some are:

• Too busy to maintain perfect documentation.
• Sloppy with updates and amendments.
• Used to “how things used to be done.”

If you blindly trust that everything is clean, you can be dragged into a mess you didn’t create.

Warning Signs Your Project May Be Out of Compliance

• No one can produce:

  • The current IRB approval letter
  • The most recent protocol
  • The approved consent form

• When you ask about IRB coverage, you get:

  • “Oh yeah, we got that years ago.”
  • “It’s exempt; don’t worry.”
  • “This is just QI, we don’t need IRB.”

• You’re told to:

  • Use your personal laptop for PHI
  • Email identifiable data casually
  • Reuse data from “old projects” without clear approval

How to Protect Yourself

• Politely insist on clarity.
  “Just so I’m sure I’m doing everything right, could I see the IRB approval letter for this protocol?”

• Document your questions.
  Email is your friend:

  • “To confirm, is [this activity] covered under IRB protocol #XXXX with current approval dates?”

• If something feels off, discreetly consult the IRB office.
  Phrase it as:

  • “I want to be sure I’m following policy as a student on this project. Can you help me understand…?”

You’re not throwing your PI under the bus; you’re protecting yourself, your subjects, and your institution.

---

Mistake #8: Failing to Plan for Authorship and Data Ownership Early

This isn’t just about fairness. It’s also a compliance issue.

Where Students Get Burned

• Using data from one project for a “new” analysis without:

  • IRB approval for the new use
  • PI permission

• Assuming:

  • “I collected this data, so I can use it however I want.”
  • “I can take this dataset with me to another institution for my next project.”

Data from human subjects isn’t yours. It belongs to:

• The institution
• Governed by the IRB protocol under which it was collected

Using it outside that framework can be a breach of both ethics and policy.

What This Can Cost You

• A mentor unwilling to support you in the future
• Co-authors or institutions contesting your right to publish
• IRB concerns about secondary analysis without approval

How to Avoid This

• Ask about data ownership on day one.
  “Who owns this data, and under what conditions can it be reused or reanalyzed?”

• Clarify authorship and future projects early.
  Not just verbally — in some labs, expectations get written down.

• Treat every new analysis as potentially needing IRB review.
  Especially if:

  • New questions are being asked
  • Different variables are being linked
  • Data is leaving the original institution

If you want to avoid painful conflicts at the end, have awkward conversations at the beginning.

---

Mistake #9: Forgetting That IRB Responsibilities Don’t End After Data Collection

Students often mentally “check out” of compliance once the last subject is enrolled. That’s naïve.

Your Ongoing Obligations

Under most IRB protocols, the research team must:

• Submit continuing review reports or confirm ongoing status.
• Report:
  • Adverse events
  • Protocol deviations
  • Complaints
• Maintain proper records for a defined period.

If you vanish the moment your poster is done, you might leave your mentor holding a partially documented, noncompliant mess.

How to Avoid This

• Know what reporting your project requires and when.
• Keep your research files organized, so that:
  • If the IRB or auditor asks questions later, your mentor can answer them.
• Don’t disappear without handing off your responsibilities.
  Especially if you’re the one who knows:
  • Where original data is stored
  • How ID codes map to subjects
  • What exactly was done, and when

Think beyond your own CV line. Protect the project’s long-term integrity.

---

Final Thoughts: The Non-Negotiables

If you want your student research to actually see the light of day — posters, publications, letters of recommendation that mention “strong research integrity” — you cannot treat IRB and compliance as background noise.

The three core points to tattoo on your brain:

1. Never start or change human subjects work without explicit IRB determination or approval. Guessing or assuming is how promising projects die quietly.
2. Handle PHI and consent as if every action could be audited later — because it might be. If you’d be nervous seeing a screenshot of your process on a big screen, don’t do it.
3. Don’t rely on “someone else has it covered.” Ask questions, get documentation, and protect yourself by understanding exactly what’s been approved and what hasn’t.

Your ideas, effort, and time are too valuable to lose over preventable IRB and compliance mistakes.