HIPAA-compliant AI on patient data: de-identification, audit trails and model governance

Computational phenotyping, using algorithms over EHR data to define patient cohorts, has a failure mode nobody puts in the pitch deck. The pipeline works and the clinicians want it, but the monthly security review keeps reconvening around the same unanswered questions, the questionnaire has been stuck for weeks on a data-flow diagram nobody can produce, and the launch quarter quietly becomes next quarter. This post is about building the pipeline so the people whose job is to say no can say yes. One of these pipelines sits inside a post-acute care platform we built, so the practices here are ones we applied when we built it, not ones we recommend from a distance. Design compliance in on day one and it fits the schedule; retrofit it at the end and you're excavating decisions nobody wrote down.

Why do phenotyping pipelines get stuck in security and compliance review?

Because they concentrate exactly what reviewers are paid to worry about: bulk PHI extraction from the EHR, algorithmic decisions about patients nobody can quite explain, and outputs that are themselves sensitive. A list of patients flagged as "probable heart failure" is PHI with an inference attached, arguably more sensitive than the raw data it came from.

Most stalled reviews come down to four unanswered questions. What's the data posture (de-identified, limited data set, or full PHI), and where's the paperwork? Is access to cohort outputs role-scoped, or does "the analytics team share a database login"? If a regulator or IRB asks why a patient was in a cohort, can you answer with the algorithm version and input data? When the definition changes, who approved it and what got revalidated? None of these questions is difficult. What makes them difficult is hearing them for the first time in the review.

Teams with answers tend to clear review in weeks. Teams with a working demo and no answers enter a finding-remediation loop that can outlast the build. That's the pattern we described in why most healthcare apps fail HIPAA compliance: compliance treated as a final exam instead of a design input.

De-identification, limited data set, or identifiable PHI: which should your pipeline use?

Pick the least-identified data that still lets the phenotype work, then document why. That one decision drives most of your compliance surface. HIPAA gives you three postures, and they are not interchangeable:

• Fully de-identified data sits outside HIPAA, though state privacy law, FTC authority, and contracts can still reach it, via one of two routes. Under Safe Harbor (45 CFR 164.514(b)(2)), you strip all 18 enumerated identifiers (names, geography smaller than state, all date elements except year (with ages over 89 aggregated to "90 or older"), phone, email, SSN, MRN, device IDs, biometrics, full-face photos, and the rest) and have no actual knowledge the remainder could identify someone. Under Expert Determination (164.514(b)(1)), an expert with appropriate statistical and scientific knowledge determines that re-identification risk is "very small" and documents the methods and results. The catch: removing dates finer than year destroys the temporal sequences many phenotype algorithms depend on, like readmission intervals, medication timing, and lab trajectories. Lightest compliance load, often the wrong tool.
• A limited data set (164.514(e)) is the middle path most research-adjacent phenotyping wants. It may retain full dates and geography down to city, state, and ZIP (but no names, street addresses, MRNs, or other direct identifiers), and may only be disclosed for research, public health, or health care operations under a signed Data Use Agreement that restricts use, requires safeguards, and prohibits re-identification. A limited data set is still PHI. Teams get burned assuming "we removed names" means "HIPAA doesn't apply." It does.
• Identifiable PHI is what you need when the output must land back on an identified patient: flagging individuals for outreach, care management, or trial recruitment (Part 4), where IRB oversight adds its own layer. A Business Associate Agreement is not the basis for that use; it is the contract that covers a vendor handling PHI on the covered entity's behalf. The basis is one of HIPAA's permitted pathways: the covered entity's own treatment and operations authority, individual authorization, an IRB or Privacy Board waiver, or the preparatory-to-research provision, and the dossier should name which one. Where a vendor operates the pipeline, the BAA makes that vendor directly accountable for the Security Rule, and HITECH made that liability direct rather than merely contractual: full technical safeguards, encryption in transit and at rest, breach notification, the works. It's the heaviest posture, and the one operational use requires.

The decision reduces to a short flowchart:

The day-one move: decide the posture per pipeline stage. Development and tuning can often run on a limited data set; only the final scoring stage that produces an actionable patient list needs identified PHI. That split shrinks the identified-data footprint to one well-guarded component, and the review shrinks with it.

How do minimum necessary and role-based access apply to cohort tools?

HIPAA's minimum necessary standard (164.502(b)) reaches inside your pipeline, not only the front door, wherever it applies; it does not govern disclosures for treatment or uses under an individual's authorization, and de-identified data is outside it entirely. Apply data minimization as an engineering rule regardless: each role and stage should touch only the fields it needs. For a cohort tool that means at least three tiers: feature-extraction jobs read raw EHR data and nothing human-facing does; analysts building phenotype definitions work against the limited or de-identified tier and never see names; only the clinical end users acting on a cohort (the outreach nurse, the trial coordinator) see identified patients, and only theirs.

The most common failure mode is architectural: a single "research database" with full PHI and a shared credential, where minimum necessary exists as a policy PDF rather than as enforced access control, whether that enforcement lives in IAM, database grants, row and column controls, or application authorization. Reviewers can tell the difference in five minutes.

Enforce role-based access in the data layer instead: separate schemas per tier, per-user credentials, column-level controls on identifiers. That turns a policy claim into something an auditor verifies by reading your access grants. It also makes the next section possible: you can't attribute access that was never tied to an individual user. Pulling EHR data through governed, standards-based interfaces rather than ad-hoc extracts helps too: interoperability done properly gives you scoped, loggable access instead of a nightly full-table dump.

What audit trail does an algorithmic cohort decision need?

Every cohort membership should be reconstructable: this patient was included by this version of this algorithm, run at this time, over this snapshot of data, for these reasons. The Security Rule's audit-control requirement (164.312(b)) covers recording and examining activity in systems that contain or use ePHI; algorithmic cohorts need a second ledger the regulation doesn't spell out: provenance for the decision itself. We treat that ledger as mandatory, and regulators are heading the same way: FDA's predetermined change control plan (PCCP) guidance and ONC's HTI-1 source-attribute requirements for predictive decision support both turn on version-level accountability.

Concretely, log four things per run: the phenotype definition version (a content hash, not a filename), the code version, an identifier for the input data snapshot, and enough decision provenance to reproduce why each patient was included or excluded, such as cohort identifiers, reason codes, and source references, under defined retention and access rules.

That ledger is what answers the questions that otherwise become incidents: why did this patient get a recruitment call? Which patients were scored by the version that turned out to have a bug? When the algorithm changed in March, whose cohort status flipped? A team that answers those from a query has an audit trail; a team that answers by re-running old code from memory has a liability. And since you cannot reconstruct provenance you never captured, this is a day-one schema decision, not a hardening ticket. By the time anyone asks, the answer is either in the schema or it is gone.

What does governance look like for phenotype definitions?

Treat a phenotype definition the way a device manufacturer treats a design file: versioned, change-controlled, and revalidated on defined triggers. A phenotype definition is a clinical claim expressed in code: "these criteria identify diabetics" is an assertion about patients, and editing it is a clinical change, not a code change. Governance means three mechanisms:

Versioning. Every definition, including its value sets, logic, model weights, and thresholds, is versioned as one immutable unit, so "heart failure v2.3" means exactly one thing forever. Watch value sets especially: an upstream terminology update that silently adds codes to "your" value set is an unversioned change to your algorithm.

Change control. Changes ship through review, with a roster that matches the class of change: anything that alters clinical meaning, criteria, thresholds, or how the cohort is interpreted needs an informaticist or clinician to sign off, while an engineering-only change with identical outputs goes through technical review with regression evidence. Record what changed, why, who approved it, and the expected effect on cohort composition. A before/after count diff on a reference dataset is cheap, and it's exactly what a reviewer wants to see.

Revalidation triggers. Define in writing, in advance, which changes require an impact assessment and what level of revalidation each one triggers: a changed clinical criterion or model gets fuller chart revalidation, a changed diagnosis set gets a cohort diff plus targeted review, a terminology version bump with no affected concepts gets a documented impact assessment, and a refactor with identical outputs gets a regression test. An EHR migration, a new site or population, and unexplained drift in monitored cohort statistics sit at the top of that ladder. Why algorithms validated at one institution degrade at another is its own discipline, covered in our portability post (Part 3); the governance point is that triggers are pre-committed, so revalidation happens because the process fired, not because someone remembered.

What documentation do compliance reviewers actually want to see?

A validation dossier: written evidence that the algorithm was checked against clinical truth and someone is accountable for the result. This is the document that most changes a review's temperature, because it is evidence rather than assertion. Its core is a chart-review protocol and its results: how many charts were sampled and how, who reviewed them with what qualifications, the adjudication rule for disagreements, and the resulting sensitivity, specificity, and, above all, positive predictive value, since PPV tells a reviewer how many patients on the list actually belong there. Report it against a specific algorithm version and data snapshot, with confidence intervals and a stated performance floor ("outreach requires PPV ≥ 0.85; v2.3 measured 0.91 [0.86–0.95]").

Around that core, the dossier collects everything above: the data-posture decision, the authorization basis for any PHI, and whichever agreements actually apply (a Data Use Agreement for a limited data set, a BAA where a vendor is involved), the access-tier design, the audit-trail description, the change-control log, the revalidation triggers. Assembled as you build, it's a folder that fills itself. Assembled at review time, it's three months of forensic reconstruction. That's the same economics we keep encountering in getting healthcare AI into production: the decisions are unavoidable; the only choice is whether you make them cheaply at the start or expensively at the end.

We treat compliance review as the audience for a phenotyping program, not its enemy. Build the pipeline so the review is a walkthrough of decisions already made (posture, access, provenance, governance, validation) and the people paid to say no become the people who sign. None of this is legal advice; your counsel and privacy officer make those calls, and the engineering job is to hand them a system where saying yes is easy.