In this article
Before you start
This page belongs to the machine learning operations (MLOps) interview questions path and assumes you know how a model is trained, as covered in machine learning algorithms.
Why interviewers ask this
A pipeline that trains on patient data fails a review when its designer cannot say where the patient data stops. Health-tech system design questions use this topic to see whether a candidate treats privacy as architecture or as a checklist item added at the end.
A weak answer says "we encrypt everything and sign a contract with the cloud vendor." A strong answer draws a boundary, says which stages sit inside it, names how data leaves it, and says what the contract does not cover. A Staff-level answer adds the awkward parts: logs that leak, free-text notes, and the open question of whether a trained model is itself sensitive.
The rest of this page builds that answer from zero. It is educational background on United States rules, not legal advice, and a real system needs review by a privacy lawyer or expert.
Clinical ML pipeline HIPAA design from first principles
- Business associate agreement
- A business associate agreement (BAA) is a contract that binds a vendor handling electronic protected health information (ePHI) for a covered entity to safeguard it, including the requirements of the HIPAA Security Rule. A cloud or ML platform vendor that creates, receives, maintains or transmits ePHI needs one, as the U.S. Department of Health and Human Services (HHS) cloud guidance explains.
- De-identification
- De-identification is the process of changing health information so that it no longer identifies an individual, using one of the two methods HIPAA recognises. Data that passes is no longer PHI, but the HHS de-identification page says the risk of linking it back is very small, not zero.
In plain words
Picture a hospital records room. Everything with a patient's name stays inside. The door is locked, a visitor log records who enters, and every contractor who works inside signs an agreement. Analysts never enter. They work from redacted photocopies in another building.
The analogy breaks in one place. A photocopy can still identify a person through a combination of details, such as age, town and visit date. Privacy risk comes from combinations, not only from names.
In one precise sentence: a clinical ML pipeline keeps PHI in a small contracted zone, removes identity at a documented boundary, and lets models touch only data from the far side of it.
Step 1: Classify every field as PHI or not
HIPAA covers covered entities, meaning providers that transact electronically, clearinghouses and health plans, and the business associates that work for them (HHS guidance, updated March 2026). In a pipeline, the first job is a data map. For each field in each feed, ask whether it identifies, or could reasonably identify, a patient.
Input: the raw feeds from the electronic health record (EHR) system, claims files and devices. Output: a field-level map that marks every field as PHI or not and names the covered entity whose data it is. Keep the map in version control beside the schema, because the data platform under ML changes often and every change can add a field. Classify every field as PHI or not before any design choice.
Step 2: De-identify with Safe Harbor or Expert Determination
HIPAA offers two de-identification methods, and data that meets either one is no longer PHI (HHS de-identification guidance). Safe Harbor is the method that removes the 18 identifier types listed in the Code of Federal Regulations (CFR) rule on de-identification, 45 CFR § 164.514, and requires that the organisation has no actual knowledge that what remains could identify someone. Expert Determination is the method in which a qualified expert finds that the risk is very small that the data could identify a person, alone or combined with other reasonably available information, and documents the methods and results.
Input: PHI records. Output: records with no direct identifiers. One rule is easy to miss: a replacement code must not be derived from or related to information about the patient. A hash of a medical record number (MRN) is derived from patient data, so it does not qualify. A random code, with its lookup table kept inside the PHI zone, fits the rule. De-identify at the boundary with Safe Harbor or Expert Determination.
Step 3: Sign a BAA and limit access inside the PHI zone
Every vendor that creates, receives, maintains or transmits ePHI for you is a business associate, so each one needs a BAA. The HHS cloud guidance says this holds even when the vendor stores only encrypted data and holds no key, and that the provider is directly liable under the HIPAA Rules as well as by contract.
The contract does not finish the job. Covered entities and business associates must each run their own risk analysis of threats to the confidentiality, integrity and availability of ePHI. Then apply the minimum necessary standard. Minimum necessary is the rule that a covered entity takes reasonable steps to limit uses, disclosures and requests of PHI to what the purpose needs (HHS privacy standards). The regulation adds that an entire medical record may not be used, disclosed or requested unless specifically justified (164.514(d)(5)). Define roles and give each only its fields. Sign a business associate agreement with every vendor that touches PHI.
Step 4: Train in a clean zone and serve in a contracted one
Training needs patterns, not identities. Train, tune and experiment on de-identified data in a separate cloud account and network from the PHI zone. HIPAA does not require de-identification before training: a covered entity may use PHI for its own health care operations, and a research use needs patient authorisation or a waiver from an Institutional Review Board (IRB) or privacy board (45 CFR § 164.506, § 164.512(i)). De-identifying first is a design choice that keeps training outside the contracted zone.
Serving differs. A live prediction request carries a real patient's data, so the serving path sits in the PHI zone with a BAA, access control and audit logs. How long PHI lives there depends on your choice among batch, streaming and real-time inference, and on how you isolate workloads, for example with Kubernetes for ML infrastructure.
Whether model weights or embeddings trained on PHI are themselves PHI is an open question: the sources reviewed for this page contain no authoritative HHS statement on it. Treat the model registry as sensitive until an expert says otherwise.
Step 5: Log, audit and re-check risk after every change
Logs and traces are where PHI leaks. A prompt, a feature value or an error message can carry a patient's details into a tool outside the contracted zone. The Security Rule's technical safeguards cover access control, audit controls, integrity, authentication and transmission security, so every access to the PHI zone should leave an audit log entry.
Apply the ideas of large language model (LLM) observability with scrubbing: trace cost, latency and quality, and strip or tokenise patient details before a record reaches a dashboard. Watch for drift after deployment using aggregate statistics from de-identified data where you can. Gate releases through continuous integration and delivery for ML and LLM apps so a new field or vendor triggers a privacy review. Log, audit and re-check risk after every pipeline change.
Step-by-step description
- Mark every field as PHI or not.
- Remove identity at the boundary.
- A BAA for each vendor, least access.
- Train clean, serve in the PHI zone.
- Log, audit and re-check risk.
- Classify every field as PHI or not before any design choice.
- De-identify at the boundary with Safe Harbor or Expert Determination.
- Sign a business associate agreement with every vendor that touches PHI.
- Train on de-identified data in a clean zone and serve live PHI in a contracted zone.
- Log, audit and re-check risk after every pipeline change.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Take an illustrative design with eight stages. The table marks which stages hold PHI. Five of eight stages handle PHI, two work on de-identified data and one is an open question.1 Training is the smaller part of the risk: ingestion, serving and monitoring still touch real patients.
| Stage | Data status | Main control |
|---|---|---|
| Ingest from the EHR | PHI | BAA, encryption, minimum necessary |
| Identify PHI | PHI | Field allow-list, audit logs |
| De-identify or tokenise | PHI in, clean out | Documented method |
| Feature store | De-identified | Role-based access |
| Train | De-identified | Separate clean account |
| Model registry | Open question | Treat as sensitive |
| Serve | PHI | BAA, access control, audit logs |
| Monitor | PHI | Scrub logs, audit logs |
Text description of the diagram
- Five of eight stages handle PHI.
- Two stages work on de-identified data.
Now see why generalising matters. Suppose a region has 1,000,000 patients, 1,000 zip codes, births spread over 91 years at 365 days each, and 2 sexes (all illustrative). The raw combination of zip code, full birth date and sex has 66,430,000 possible cells, so a typical cell holds about 0.015 patients and nearly everyone sits alone in theirs.1
Safe Harbor generalises. It keeps the first three digits of a zip code only if that area holds more than 20,000 people, and ages over 89 collapse into 90 or older (45 CFR § 164.514). Take ten illustrative three-digit areas, two at or under 20,000 people, which merge into one area coded 000. That leaves 9 areas, 91 ages and 2 sexes, which is 1,638 cells with about 611 patients each on average.1 The threshold is strict: an area of exactly 20,000 people is merged, and one of 20,001 is kept.1
| Quantity | Value (computed from illustrative inputs) |
|---|---|
| Cells before: zip code, full birth date, sex | 66,430,000 |
| Average patients per cell before | about 0.015 |
| Cells after: merged three-digit area, age, sex | 1,638 |
| Average patients per cell after | about 611 |
| Possible values of a seven-digit record number | 10,000,000 |
Real data is not spread evenly, so rare combinations remain; Expert Determination measures actual groups for that reason. The last row explains the hash rule: every one of the 10,000,000 possible seven-digit record numbers can be hashed and tabulated, so the hash can be reversed by lookup.1
Trade-offs and edge cases
Safe Harbor is simple to audit but blunt. It removes 18 identifier types, including every date element except the year (45 CFR § 164.514). A model that needs the time between two visits loses its signal. Expert Determination needs a documented expert analysis, and it can keep more detail when the expert finds the risk very small for the anticipated recipient. The HHS guidance states that no specific degree or certification defines an expert.
A limited data set is PHI without 16 direct identifiers, and dates and town may stay. It stays PHI, needs a data use agreement, and may be used only for research, public health or health care operations (164.514(e)). A limited data set stays PHI and needs a data use agreement, so check with counsel that your purpose qualifies.
Text description of the diagram
- Safe Harbor removes 18 identifier types.
- Expert Determination needs a documented expert analysis.
- A limited data set stays PHI and needs a data use agreement.
Edge cases:
- Free text. Clinical notes hide names and dates in sentences. The HHS guidance has a section on free-text fields. Treat notes as PHI until a tested scrubbing step and an expert say otherwise.
- Residual risk. Both methods leave a risk that is very small but not zero (HHS), so keep the clean zone access-controlled anyway.
- Vendors that de-identify. A business associate may de-identify PHI on a covered entity's behalf only if the BAA authorises it.
- Vendor scope. A BAA covers the services it names, so check each vendor's own list of eligible services.
- Training inside the PHI zone. It keeps full signal, but it puts the feature store, experiments and model registry under the BAA and audit controls.
- Other laws. State privacy laws and rules of the Food and Drug Administration (FDA) for clinical software sit outside HIPAA and are not covered here.
How to answer it in an interview
Design a pipeline that trains a model on hospital patient records under HIPAA.
I start by classifying every field as protected health information or not, and I draw a boundary. Inside it, ingestion, de-identification, serving and logs run under a business associate agreement with each vendor, with minimum-necessary access, encryption and audit logs. At the boundary I de-identify with Safe Harbor or an expert's documented determination, and I never use a hash of the record number as the code. Training, the feature store and experiments sit outside, on de-identified data. The trade-off is lost detail, such as dates, so I would ask an expert whether richer features are allowed, or train inside the PHI zone if the use qualifies as operations or approved research.
The spoken structure: draw the boundary, say what runs inside, say how data leaves it, then name the trade-off.
Common mistakes
- "Encrypted data in the cloud means no BAA." (wrong) The provider is still a business associate without the key. (right) "Every vendor that handles ePHI gets a BAA, encrypted or not."
- "We signed a BAA, so we are compliant." (wrong) The contract makes the vendor liable but does not do your risk analysis. (right) "The BAA is one control; I still analyse risk and configure access."
- "We removed the name, so it is de-identified." (wrong) Safe Harbor needs all 18 identifier types removed, dates and record numbers included. (right) "I follow the full list or get a documented expert determination."
- "Hashing the record number gives a safe pseudonym." (wrong) The code is derived from patient data. (right) "I use a random code, and keep the lookup table in the PHI zone."
- "The test environment is out of scope." (wrong) The rules attach to the data, not to the label on the environment. (right) "Test data is either de-identified or treated as PHI."
Follow-up questions
Does a business associate agreement make my ML pipeline HIPAA compliant?
No. A BAA makes the vendor contractually and directly liable, but you must still run a risk analysis and configure your own controls, as the HHS cloud guidance describes.
Do I need a BAA if the cloud provider only stores encrypted data?
Yes. The HHS cloud guidance treats a provider that maintains ePHI as a business associate even when it cannot read the data. Lacking the key does not remove the obligation.
Is a hash of the medical record number de-identified?
No. The rule says a code must not be derived from or related to information about the individual, and a hash is derived from the record number. Use a random code and keep the mapping inside the PHI zone.
Is a model trained on patient data itself PHI?
Whether a trained model is itself PHI is unsettled. The sources reviewed for this page contain no authoritative HHS statement, so a cautious design restricts the registry and asks an expert, and an answer should say plainly that the point is open.
Where do monitoring and drift checks fit in a HIPAA pipeline?
Monitoring that sees live requests sits in the PHI zone and needs scrubbed logs. Drift checks on aggregate statistics from de-identified data can run in the clean zone; see model drift.
- Split the pipeline into a contracted PHI zone and a clean zone, and decide where data crosses.
- De-identify with Safe Harbor or a documented Expert Determination; a code derived from patient data does not count.
- Every vendor that touches ePHI needs a BAA, and the BAA does not replace your own risk analysis.
- Serving and monitoring handle live PHI, so they stay in the contracted zone with scrubbed logs.
- De-identified data still carries a small risk, so keep controls on the clean zone too.
Sources
- Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the HIPAA Privacy Rule — U.S. Department of Health and Human Services, Office for Civil Rights, 20 Mar 2026
- 45 CFR § 164.514 - Other requirements relating to uses and disclosures of protected health information — eCFR (U.S. Government Publishing Office and National Archives), 22 Oct 2026
- 45 CFR § 164.506 - Uses and disclosures to carry out treatment, payment, or health care operations — eCFR (U.S. Government Publishing Office and National Archives), 30 Dec 2016
- 45 CFR § 164.512 - Uses and disclosures for which an authorization or opportunity to agree or object is not required — eCFR (U.S. Government Publishing Office and National Archives), 25 Jun 2024
- Guidance on HIPAA & Cloud Computing — U.S. Department of Health and Human Services, Office for Civil Rights, 26 Oct 2026
- Standards for Privacy of Individually Identifiable Health Information (minimum necessary) — U.S. Department of Health and Human Services, Office for Civil Rights, 26 Oct 2026
