How do you design ML for healthcare?

In this article

1. Before you start
2. Why interviewers ask this
3. Designing ML for healthcare from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is part of the machine learning system design guide, and the metrics are explained on the confusion matrix page.

Why interviewers ask this

Healthcare is the domain where a generic machine learning design fails in specific, checkable ways. The interviewer wants to see that you know the data is regulated, the labels are late and noisy, the patients differ by hospital, and a wrong alert has a human cost. It appears as drift monitoring for a clinical model, genomic pipelines, matching patients to research studies and multimodal models over notes and variants.

A weak answer names a model and a cloud service. A strong answer starts with who acts on the output, counts the false alarms, treats privacy as a design constraint and explains how the model is validated at each site and updated safely. The neighbouring topics are distribution shift, since each hospital is a new distribution.

Designing ML for healthcare from first principles

In plain words

Positive predictive value

Positive predictive value is the share of a model's positive alerts that are true cases, so it answers "when the alert fires, how often is it right?" and depends on how common the condition is.

Calibration

Calibration is the match between a model's stated risk and what happens: among patients scored at 10 percent risk, about one in ten should truly have the condition.

Think of a triage nurse who has worked one hospital for years. She knows what a normal reading looks like there, who needs a second look and how many calls the ward can take. Move her to another hospital with different equipment and a different patient mix, and her instincts need rechecking. A model is the same: it learns one site's normal. The analogy breaks in one place, because a model cannot say it is unsure unless you build that in.

In one sentence, a healthcare ML system is a model plus the checks that show it is lawful, useful and safe for each hospital and each update.

Step 1: Define the clinical decision and the cost of errors

The first step writes down who acts on the output and what each kind of error costs. The input is the clinical question, such as "flag patients likely to deteriorate within a day"; the output is a decision, an owner, an action and a ranking of errors. A missed case and a false alarm cost different amounts, and a ward that can review only a few alerts a shift sets a hard limit on how many the system may send.

Decide whether the model advises a clinician or acts alone, because that changes the risk and the regulation. Choose a label that is available when you need it: a diagnosis code entered days later may differ from what clinicians knew at the time. What you now know: the decision, the owner and the error costs set every threshold later.

Step 2: Get the data lawfully and keep it de-identified

The second step builds the dataset under privacy rules. US regulation, in Title 45 of the Code of Federal Regulations (CFR), names two ways to de-identify health data: expert determination, where a qualified person documents that the risk of identifying anyone is very small, and Safe Harbor, which removes 18 listed types of identifier (45 CFR 164.514). Safe Harbor removes street address, city and county, and keeps only the year of a date. It keeps three ZIP (postal) code digits only for areas above 20,000 people.

Removing obvious fields is not enough when what remains can be combined. Sweeney found that 87 percent of the US population, 216 million of 248 million people, was unique on five-digit ZIP code, gender and date of birth (Sweeney, 2000). A synthetic population of 100,000 shows the mechanism: sex plus birth year leaves nobody unique, adding a ZIP code still leaves nobody unique, and adding the full birth date makes 95.7 percent unique.¹ What you now know: privacy is a property of the combination of fields, so list the quasi-identifiers before release.

Step 3: Count the alerts before you build

The third step turns a model's accuracy into the alerts a ward will actually receive. The input is the model's sensitivity and specificity and the condition rate; the output is the positive predictive value and the alerts per true case. Positive predictive value follows from Bayes' rule, where sens is sensitivity, spec is specificity and r is the condition rate:

The formula shows why the same model performs differently by ward: the false-alarm term grows with the number of healthy patients. With sensitivity 0.80 and specificity 0.90, and a condition rate of 2 percent, 1,000 patients produce 114 alerts of which 16 are true, so positive predictive value is 14.0 percent and a clinician sees 7.1 alerts for every real case.¹ The alert burden is arithmetic done before any model exists. A published case shows the stakes: an external validation of a widely deployed sepsis model covered 38,455 hospitalizations, 2,552 with sepsis, and reported an AUC of 0.63 and an alert, a score of 6 or higher, in 6,971 hospitalizations, or 18 percent (Wong et al., 2021).

Step 4: Validate on the patients and sites it will serve

The fourth step tests the model where it will run, not where it was built. The input is a held-out sample from each target site; the output is the ranking quality, the calibration and the alert rate per site. Ranking quality can look fine while calibration breaks, so report both. Size the sample by the positives, because sensitivity is estimated only from them. The Wald interval for a proportion gives the number of positives n needed for a margin of error h, with z of 1.96 (illustrative, for 95 percent confidence) and p the sensitivity you expect:

For p near 0.80, a margin of plus or minus 0.10 needs 62 positives and plus or minus 0.05 needs 246, so at a 2 percent condition rate that is 3,100 and 12,300 patients.¹ Validate again after any change to the lab, the device or the patient mix. What you now know: a validation plan states the sample, the metrics and the site.

Step 5: Deploy, monitor and update under regulation

The fifth step runs the model in the clinic and keeps it safe. The input is live patient data; the output is monitored predictions, a feedback path and a controlled way to change the model. Monitor the inputs, the score distribution, the alert rate and, when labels arrive, the calibration, and compare each against the validated baseline. Label delay means input and alert-rate checks come first; the anomaly-detection design page and machine learning operations (MLOps) practice cover the machinery.

For a model regulated as a device, the US Food and Drug Administration (FDA) describes a predetermined change control plan: a plan submitted with the marketing application that lists planned modifications, the method to develop and validate them and an assessment of their impact, so that each planned change does not need a new submission (FDA guidance, August 2025). What you now know: decide the update rules before launch, not after the first drift.

1 · Decision2 · Data3 · Alerts4 · Validate5 · OperateReplay

Step-by-step description

1. Name who acts and what errors cost.
2. Use only data the hospital may lawfully use.
3. Count the false alarms before building.
4. Test on the sites and patients served.
5. Monitor drift and change under rules.

• The alert burden in step three is arithmetic done before any model exists.
• Validation and monitoring repeat for every site and every update.

Worked example

The first example reuses Step 3 with illustrative inputs: a model with sensitivity 0.80 and specificity 0.90 screening 1,000 patients at three condition rates.¹

Text description of the diagram

• Positive predictive value is 14.0 percent at a 2 percent condition rate, 29.6 percent at 5 and 47.1 percent at 10.
• The model's sensitivity and specificity are the same in all three cases.

The second example moves one model across three synthetic sites of 30,000 patients each. The model is a logistic regression on one lab value, fitted on site A, with the alert threshold fixed so that 90 percent of healthy patients stay quiet at site A. Site B's assay reads half a standard deviation higher, and site C's lab adds noise.¹

The AUC gap between A and B is sampling noise: a constant offset in the lab value leaves the ranking unchanged. What breaks at site B is calibration, since the model predicts 16.1 percent average risk where 10.0 percent happens, and the fixed threshold flags twice as many patients.¹ At site C the extra noise lowers the AUC and also widens the spread of scores, so more patients cross the fixed threshold and the average predicted risk again exceeds what is observed.

Text description of the diagram

• At site B the mean predicted risk is 16.1 percent against 10.0 percent observed, and alerts rise from 14.4 to 28.5 percent.
• At site C a noisier lab lowers the AUC from 0.830 to 0.734.

Trade-offs and edge cases

The design trades sensitivity against alert volume, and model power against validation cost.

• Threshold and workload. A lower threshold finds more cases and floods the ward. Set it from the review capacity of Step 1, not from a default.
• Recalibrate or revalidate. A new site with a shifted lab can often be fixed by recalibrating the score, but the change is itself a model update and needs the same validation and, for a regulated device, the plan from Step 5.
• Late and noisy labels. A diagnosis code can arrive days later and reflect billing as much as truth, so monitor inputs and alert rate while waiting for labels; the real-time fraud detection design faces the same delay.
• Rare conditions. With a condition rate of 1 percent, validating to plus or minus 0.10 on sensitivity needs about 6,200 patients, so a single hospital may not have enough.
• Privacy and utility. Removing fields lowers re-identification risk and may remove the signal; weigh Safe Harbor against expert determination.
• Explanations. A clinician who cannot see why a patient was flagged may ignore the alert; show the main inputs next to the score.

How to answer it in an interview

The spoken structure is: the decision, the data, the alert arithmetic, per-site validation, then monitoring and updates.

Common mistakes

1. Choosing the model first. (wrong) "I would fine-tune a transformer on the notes." (right) Define the decision, the owner and the cost of errors, then pick the simplest model that works.
2. Quoting sensitivity alone. (wrong) "The model catches 80 percent of cases." (right) Add the condition rate and say how many alerts per true case a clinician will see.
3. Treating removed names as de-identified. (wrong) "We dropped the names, so it is anonymous." (right) Check the combinations of ZIP code, dates and sex that remain.
4. Reporting AUC as site validation. (wrong) "AUC is the same at the new hospital, so it transfers." (right) Check calibration and alert rate too; a shifted assay keeps the AUC and breaks both.
5. Shipping updates without a plan. (wrong) "We retrain monthly." (right) State the allowed changes, how each is validated and who approves it before launch.

Follow-up questions

How would you design a system to monitor model drift and data quality issues for a model deployed in an active clinical setting?

Track input distributions, missing-data rates, the score distribution and the alert rate against the validated baseline, and compare calibration as labels arrive. Alert a named owner on a sustained change and keep a rollback to the last validated version.

How would you design a pipeline to ingest, preprocess and run inference on high-throughput genomic sequencing data?

Treat it as a staged, restartable workflow: quality control of raw reads, alignment and variant calling, then feature extraction and inference, with each stage versioned and its output stored. Keep identifiers apart from sequence data and record the pipeline version with every result.

How would you design a service that matches patients to research studies using genomic and clinical criteria?

Turn each study's criteria into structured rules, match them against de-identified patient features and return a ranked list with the reasons. Send uncertain matches to a coordinator rather than deciding automatically.

How would you design a multimodal model that combines clinical text with genomic variants?

Encode each modality separately, fuse the representations, and handle missing modalities explicitly, since many patients have notes but no sequencing. Evaluate on patients with each combination of inputs, not only on those with everything.

What changes when the regulator treats the model as a medical device?

Changes need evidence and a plan. A predetermined change control plan lists the planned modifications and how each is validated, so approved updates do not each need a new submission.

Sources

1. 45 CFR 164.514: Other requirements relating to uses and disclosures of protected health information — Legal Information Institute, Cornell Law School (regulation text; page undated; read 2026-10-25), 25 Oct 2026
2. Simple Demographics Often Identify People Uniquely (Data Privacy Working Paper 3) — Carnegie Mellon University, Sweeney (2000), 1 Jan 2000
3. Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions — U.S. Food and Drug Administration (final guidance, August 2025), 1 Aug 2025
4. External Validation of a Widely Implemented Proprietary Sepsis Prediction Model in Hospitalized Patients — JAMA Internal Medicine (Wong et al., vol. 181, no. 8), 21 Jun 2021