The Cloud Export and the 'QI' Label
A cardiology service line wants to build a 30-day heart-failure readmission model. They ask your analytics team to export eight years of data on roughly 54,000 patients - name, medical record number, date of birth, admission and discharge dates, ZIP code, and structured diagnosis fields - to a cloud machine-learning vendor's US-East region for a 12-month pilot. The vendor's contract is a standard self-service SaaS subscription with no business associate agreement; its terms allow using customer data to improve its models. The service line chief says the project is 'quality improvement, so we don't need the IRB,' but the team plans to present the results at a national meeting and submit a manuscript. Separately, a cardiology fellow has asked for a CSV extract to their personal email address so they can 'work on it at home over the weekend.'
1. What must be in place before any data leave the organization?
Read the worked answer
This export fails on several independent controls, each sufficient to block it.
1. Business associate status. A vendor that receives PHI to build a model on your behalf is a business associate. A BAA is required. Self-service SaaS terms that permit vendor model improvement are incompatible with a BAA unless the agreement constrains that use - and the current terms explicitly allow it. This alone stops the pilot.
2. Minimum necessary. Name and MRN are almost certainly not needed for modeling; admit/discharge dates, age, ZIP3, and diagnosis fields probably are. Strip direct identifiers unless a specific analytic requirement justifies each one, and document the justification.
3. De-identification route. Safe Harbor de-identification removes dates and full ZIP - but readmission timing requires dates, so Safe Harbor is not viable. The realistic path is a limited data set with a data use agreement: it retains dates and ZIP, strips direct identifiers, and binds the recipient against re-identification and further disclosure. The alternative is expert determination, which requires a documented statistical justification and is harder to defend for a model-training export.
4. Technical and contractual controls. Encryption in transit and at rest, role-based access, audit logging, named users, a prohibition on secondary use, a retention/destruction clause, and a breach notification obligation.
Nothing leaves until the BAA and DUA are executed and the extract is minimized.
2. How do you resolve the 'it's QI, not research' claim?
Read the worked answer
The label is not the service line's to assign, and the stated intent settles the question.
The regulatory test distinguishes QI from research by intent and dissemination: QI is designed to improve local care and is generally not intended to produce generalizable knowledge; research is designed to contribute to generalizable knowledge. This project fails the QI test on two stated facts - a planned national presentation and a manuscript submission. Both are dissemination of generalizable findings.
Who decides. The IRB (or the organizational unit formally delegated to make the determination), not the service line chief. Submit a QI-versus-research determination request with the protocol, the data elements, and the dissemination plan. If it is research, you need IRB approval plus either HIPAA authorization from 54,000 patients - impractical - or an IRB waiver of authorization, which requires justification of minimal risk, impracticability, and a plan to protect identifiers.
Practical note. A waiver is often obtainable for retrospective data with a limited data set and a destruction plan, but it must be granted before the export. Building the model first and seeking a retroactive determination is a finding in any audit and, if the work is federally funded, a reportable event.
Document the determination and attach it to the data request. The documentation is what protects the analyst who ran the extract.
3. The fellow wants a CSV emailed to a personal address. What is your response, and what should the organization have in place so the answer does not depend on who is asked?
Read the worked answer
The answer is no, delivered without ambiguity: a patient-level file containing dates of birth and MRNs sent to a personal email account is unencrypted ePHI outside the organization's control. That is a reportable breach risk and a policy violation regardless of intent.
Offer a workable alternative in the same breath, because a flat refusal invites workarounds: a provisioned analytics workspace or VDI session with a de-identified extract, an approved secure file-transfer channel, and a documented approval path for a limited data set. Most 'shadow export' behavior is driven by friction, not malice.
Organizational controls so the answer is consistent:
- A clear policy defining ePHI handling, personal-account prohibition, and sanctions, with annual attestation.
- Role-based access so that analysts receive only the fields their approved request requires - the fellow should not have had DOB and MRN in an extract at all.
- A data request and approval workflow with a named data steward per domain and a documented business justification.
- Audit logging on query and export activity, with periodic review and a mechanism that flags large extracts.
- A de-identification service available before the request, so the default path is the compliant one.
Treat this as a governance design problem rather than a discipline problem: if the compliant path is slower and harder than the non-compliant one, people will take the non-compliant one.