Design an AI-Powered Medical Diagnosis Assistant — System Design Interview Practice

Interview prompt

Design a clinician-assistance platform that analyzes DICOM medical images and structured symptoms, produces evidence-linked suggestions with calibrated uncertainty, and preserves clinical oversight and privacy.

• Define patient/study identity, DICOM ingestion, clinical context, consent, model/version, evidence, uncertainty, review, and audit records.
• Never present an unreviewed suggestion as a diagnosis; handle missing context, out-of-distribution images, bias, calibration, and urgent escalation.
• Separate protected data ingestion from preprocessing, inference, clinician review, EHR integration, training, and immutable audit storage.
• Explain PHI minimization, access controls, validation, rollback, downtime procedures, observability, and safe no-result behavior.

Requirements and scale assumptions

• Ingest and validate DICOM studies and permitted clinical context, run versioned analysis, and return findings, evidence regions, confidence, and limitations.
• Support clinician review/override, symptom/context entry, FHIR/EHR exchange, worklists, urgent flags, and complete provenance.
• Enforce consent and role access, preserve audit trails, retract/reprocess results, delete according to policy, and operate safely during outages.
• Meet validated per-condition sensitivity/specificity targets and expose uncertainty; keep routine study turnaround within the clinical SLA.
• Process 1M studies per month with strict tenant/PHI isolation without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 1M studies/month across 500 hospitals with PHI isolation
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 1M studies/month; 500 hospitals — Capacity assumption that drives partitioning and backpressure.
• Latency target: clinical SLA tracked; uncertainty exposed — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Signed source studies, clinical context, and clinician-approved reports are authoritative; model outputs are advisory.
• Async boundary: At-least-once workers — Keep Use specialized vision models for medical imaging, Implement DICOM-compatible image processing pipelines, Use FHIR standards for EHR integration off the synchronous path.

Key entities

• DatasetVersiondatasetId, version, schemaHash, qualityStatus, lineage, createdAt

  Immutable ai powered medical diagnosis assistant input version used for reproducible training, evaluation, or replay.

• FeatureSnapshotentityId, featureSetVersion, eventTime, values, sourceWatermarks

  Point-in-time ai powered medical diagnosis assistant features with source watermarks so online and offline values can be compared.

• TrainingRunrunId, datasetVersion, codeVersion, metrics, artifactUri, status

  Audited ai powered medical diagnosis assistant run that records data, code, dependency, and evaluation lineage.

• ModelVersionmodelId, version, stage, schema, qualityGates, endpoint

  A promotable ai powered medical diagnosis assistant model version with rollout state, contract, and rollback metadata.

Data flow

1. 1. Register and validate training dataThe ai powered medical diagnosis assistant gateway records an immutable dataset version, schema, lineage, quality status, and privacy disposition.
2. 2. Build point-in-time featuresFeature workers join ai powered medical diagnosis assistant inputs using event-time watermarks, prevent leakage, and publish the same feature contract for training and serving.
3. 3. Train and evaluate asynchronouslyThe orchestrator schedules ai powered medical diagnosis assistant runs with checkpointed artifacts, reproducible environments, and metrics tied to the exact input versions.
4. 4. Gate and serve a model versionA registry compares ai powered medical diagnosis assistant quality, bias, safety, and compatibility gates before canary or production rollout with an immediate rollback pointer.
5. 5. Monitor drift and learn from feedbackOnline inference records latency, errors, drift, and delayed labels so ai powered medical diagnosis assistant retraining is evidence-driven rather than triggered by guesswork.

Deep dives and trade-offs

• Reproducibility and leakage preventionPin ai powered medical diagnosis assistant data, feature, code, dependency, and model versions for every run. Use point-in-time joins and quarantine failed quality or privacy checks before training. Keep raw inputs and artifacts immutable so a result can be replayed after a dependency changes.
• Safe promotion and serving contractsSeparate ai powered medical diagnosis assistant model registration from deployment and require signed artifacts plus schema compatibility. Use shadow traffic, canaries, rollback pointers, and per-version latency/error budgets. Return model version and feature freshness so clients can explain or reproduce a prediction.
• Drift, feedback, and costMeasure feature drift, prediction drift, label delay, and segment-level quality for ai powered medical diagnosis assistant rather than only aggregate accuracy. Sample expensive inference and cap retraining concurrency with an explicit GPU or compute budget. Keep human corrections and delayed labels linked to the original prediction and model version.
• Batch versus online featuresPrefer a shared feature contract with batch backfills and a low-latency online serving path for decisions that need freshness. Two independently defined transformations create training-serving skew and hard-to-debug regressions.
• Synchronous versus asynchronous inferenceKeep interactive ai powered medical diagnosis assistant inference synchronous within a strict budget and queue large or expensive jobs. A request path that waits for model loading, enrichment, or retraining turns downstream slowness into an outage.
• Global model versus segment modelsStart with one versioned model and add segment-specific models only when quality or policy evidence justifies the operational cost. Many simultaneously active versions multiply monitoring, rollback, and data-lineage burden.