# Consent, authorization, and the minimum necessary rule in practice
A cardiology research team emails the data office: "We need the full EHR (Electronic Health Record) export for every patient who had a cardiac catheterization in the last three years. All fields. By Friday." The clinical lead is a co-author. The IRB (Institutional Review Board, the committee that approves human research) letter is attached.
Do you run that query? No. Not as written. Let us unpack why, and what a compliant pull actually looks like.
Under HIPAA (the US Health Insurance Portability and Accountability Act of 1996, enforced by the Department of Health and Human Services Office for Civil Rights, "OCR"), PHI (Protected Health Information, meaning identifiable health data) can move for different reasons through different doors. Confusing the doors is the most common governance failure.
When a patient signs standard intake forms, they consent to their data being used for TPO: Treatment, Payment, and healthcare Operations. A cardiologist pulling a patient's own chart to plan a stent procedure is treatment. No extra paperwork needed.
Key point: treatment consent does not cover research. The catheterization study is research, not treatment. Door 1 is closed here.
Research on identifiable PHI generally requires a signed HIPAA authorization: a specific, written permission from each patient that names the study, the data used, who receives it, and an expiration. This is stricter than consent. It is opt-in and study-specific.
So if the cardiology team wants identifiable records, they need either a signed authorization from each patient, or a formal waiver.
The IRB can grant a waiver of authorization when getting individual sign-off is impractical (for example, a retrospective study of 4,000 old catheterization cases, many patients now unreachable) and the privacy risk is low. The waiver must be documented. That attached IRB letter is what you check first: does it explicitly grant a waiver, and does it specify the data scope?
If the letter approves the study but is silent on a waiver, you go back and ask. Do not assume.
Two structures let research proceed with far less friction.
De-identified data. If you strip identifiers so a patient cannot reasonably be re-identified, the data is no longer PHI, and HIPAA authorization rules do not apply. HIPAA gives two methods:
Limited Data Set (LDS). A middle path. You may keep some dates and geographic detail (useful for a time-series cardiology study) but remove direct identifiers. An LDS requires a Data Use Agreement (DUA): a signed contract restricting how the recipient uses and re-shares the data.
For our cardiology team, ask: do they need patient names and full addresses? Almost never. Do they need admission dates and age to model outcomes over time? Probably. That points to an LDS with a DUA, not a full identifiable pull.
The OCR's official guidance on de-identification is worth bookmarking: HHS de-identification guidance.
If any patients are in the EU, or the data crosses into an EU institution, the GDPR (General Data Protection Regulation, in force since 2018, enforced by national Data Protection Authorities) applies. Health data is a "special category" needing an explicit legal basis. Research is a recognized basis, but you still need safeguards: data minimization, purpose limitation, and often a DPIA (Data Protection Impact Assessment, a documented risk review). The vocabulary differs from HIPAA, but the instinct is identical: collect the least, protect the most.
🎬 [VIDEO: "HIPAA and Research: Authorization vs Waiver" - youtube.com - a concise walkthrough of when research needs signed authorization versus an IRB waiver]
Here is the part governance teams skip. HIPAA's minimum necessary standard says: use or disclose only the PHI needed for the specific purpose. This is not a policy poster. It is a constraint you enforce in the SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → itself.
"All fields" fails minimum necessary by default. The study protocol lists the variables it needs. Your query should return exactly those, and nothing more.
Compare the naive request with a scoped pull:
-- REJECTED: violates minimum necessary
SELECT * FROM encounters WHERE procedure_code IN ('93458','93459');
-- SCOPED: only protocol-approved fields, LDS-style,
-- direct identifiers dropped, dates kept per DUA
SELECT
hash_id AS study_subject_id, -- pseudonymized key
year_of_birth,
sex,
admission_date, -- allowed in LDS
procedure_code,
lvef_percent, -- cardiac ejection fraction
readmission_30d_flag
FROM encounters
WHERE procedure_code IN ('93458','93459') -- cath codes
AND consent_or_waiver_status = 'APPROVED' -- gate on legal basis
AND admission_date >= '2023-01-01';Notice four controls baked in:
1. **No SELECT *.** Every column is a deliberate, protocol-justified choice.
2. `hash_id` instead of name or MRN. Direct identifiers replaced with a pseudonymized key. The re-identification mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → is held separately, under access control.
3. A legal-basis gate (consent_or_waiver_status = 'APPROVED'). Records without a documented basis are never returned.
4. A date floor matching the approved study window. Not "everything since forever."
Minimum necessary is a data engineering discipline, not just a legal one.
Knowledge check
1. A cardiologist pulls up a patient's own chart to plan an upcoming stent procedure. Under which legal basis does this data use fall?
2. Why is the cardiology research team's request NOT covered by the patients' standard treatment consent, even though the clinical lead is a co-author?
3. What best explains why an IRB waiver of authorization exists as a separate pathway from individual authorization?
4. Select ALL correct answers about a valid HIPAA authorization for research on identifiable PHI.
Select all the correct answers.
5. Select ALL correct answers describing why the data office should NOT run the request 'all fields, every catheterization patient, three years' as written.
Select all the correct answers.
Governance is only real if it is verifiable after the fact. Run these:
Before any export leaves, diff the returned columns against the IRB-approved variable list. A one-line reconciliation: approved fields minus returned fields should be empty, and returned fields minus approved fields should be empty. If the query returns home_phone and the protocol never asked for it, block the release.
Every PHI access should be logged: who, what, when, which patient set, under which legal basis. HIPAA's Security Rule requires audit controls. When OCR investigates a breach, the log is your evidence. No log, no defense.
A simple monthly audit query: list all research exports, the requesting user, row count, and whether a DUA or authorization ID is attached. Any row with a null legal basis is an incident.
Sample completed pulls. For each, ask a reviewer: "Could this study have answered its question with fewer fields or coarser data?" If full birth dates were released where year of birth would do, that is a finding. Document it and tighten the template.
For anything labeled de-identified, confirm the method. Safe Harbor pulls should contain none of the 18 identifiers, so run an automated scan for date-of-birth patterns, ZIP codes, and free-text notes (notes often leak names). Free-text is the classic hiding place for PHI; scan or exclude it.
Authorizations and DUAs expire. Keep a register with dates. When an authorization lapses, downstream use must stop. An annual review catches datasets that outlived their legal basis.
Here is the decision, cleanly:
"All fields by Friday" becomes "approved fields under a DUA, logged, with year-of-birth instead of full dates." Same study, a fraction of the risk.
SELECT *, return only protocol-approved columns, pseudonymize identifiers, and gate on a documented legal basis.