What Medicine Can Teach Us About Shipping Machine Learning
Notes on a peer-reviewed tour of ML, neural networks and deep learning in healthcare — FDA-cleared realities, the limitations section everyone should read, and the practices worth stealing for any high-stakes system.
Most of what I read about AI in healthcare is either a press release or a panic attack. So when I came across a properly sober, peer-reviewed walkthrough — "What Is Machine Learning, Artificial Neural Networks and Deep Learning? — Examples of Practical Applications in Medicine" — I ended up reading it twice and taking notes. This post is those notes, filtered through the eyes of someone who builds software systems rather than diagnoses patients: what the paper actually says, and what it quietly teaches anyone shipping ML into any high-stakes domain.
The taxonomy, finally stated cleanly
The paper's first service is untangling three terms that get used as synonyms at conferences. Machine learning is the umbrella: systems that learn decision rules from data instead of being hand-programmed. Artificial neural networks are one family of ML models — the layered, weighted kind I unpacked in my neural networks explainer. Deep learning is what we call those networks once the hidden layers stack up. Every DL model is an ANN; every ANN is ML; the reverse doesn't hold. Five minutes with that Venn diagram would improve half the vendor pitches I've sat through.
What I appreciated is that the authors give the classical methods their due before reaching for the deep stuff: k-nearest neighbors, linear and logistic regression, Naive Bayes, support vector machines, AdaBoost. These aren't museum pieces. On small, structured clinical datasets — and much medical data is small and structured — a well-validated logistic regression is interpretable, auditable, and often embarrassingly competitive.
Where depth earns its keep
The paper cites a drug formulation study where a deep network reached roughly 85% predictive accuracy against 80% for a shallower one. Five points may sound like an incremental win; in a clinical or pharmaceutical pipeline it's the kind of gap that changes what's viable. But the more interesting pattern in their application survey is which shape of problem goes deep:
- Imaging — radiology, dermatology, pathology slides — is CNN territory, because the signal lives in spatial patterns no one can hand-feature.
- Signals over time — ECG rhythms, patient monitoring — reward architectures built for sequences.
- Generative and reconstruction tasks — the paper tours autoencoders, U-Nets, GANs, transformers and reinforcement learning — map to drug discovery, image segmentation and treatment planning.
And this isn't speculative: the review points at FDA-cleared deployments, from atrial fibrillation detection on a consumer watch to echocardiogram analysis for heart failure assessment. The technology has crossed from "paper" to "product" in specific, validated niches — a phrase worth savoring: specific, validated niches, not "medicine, generally".
The limitations section is the best part
Academic papers hide their gold in the limitations, and this one lists exactly the four issues I've watched sink real-world ML projects far from any hospital:
- Labeling is the expensive part. Supervised learning needs experts to annotate data, and expert time is the scarcest resource in any domain. (Swap "radiologist" for "senior fraud analyst" and the sentence survives intact.)
- Interpretability is not optional in high-stakes settings. A clinician — or a regulator, or a payments auditor — needs more than a confident number. If the decision can't be explained, plan for a human-in-the-loop or a simpler model.
- Privacy shapes architecture. Medical data can't be shoveled into whatever cloud is cheapest. Data governance decisions come before model decisions — a lesson every industry with regulated data (I see you, fintech) relearns periodically.
- Bias rides in with the training data. A model trained on one population underperforms silently on another. "Silently" is the operative word — this is a monitoring problem as much as a training problem.
What I'd steal for non-medical systems
Reading medical AI literature as a systems engineer is oddly clarifying, because medicine is forced to do properly what the rest of us do casually. The transferable practices:
- Validation against a held-out reality, not a vibe. Clinical models face external validation cohorts. Your churn model deserves at least a time-split backtest before anyone acts on it.
- Deployment as a regulated release, not a notebook push. Versioned models, documented training data, rollback paths. If the FDA can demand it, your change-management process can too.
- Confidence thresholds with human escalation. The watch doesn't diagnose; it flags for a doctor. Most business ML should ship with the same humility — auto-act on the certain cases, route the murky ones to people.
- Monitor the population, not just the accuracy. Drift in the input distribution is the earliest warning you get. Log predictions and features (see centralized logging); the dashboards pay for themselves the first time reality shifts.
My takeaway
The honest summary of the paper isn't "AI will replace doctors" or "AI is hype". It's that machine learning is becoming medical infrastructure — narrow, validated, monitored, and embedded in workflows that keep humans accountable. That's also, I'd argue, exactly the standard the rest of the software industry should hold its own ML features to. Fewer magic demos; more boring, validated pipelines. Medicine got there first because it had to.
Building an ML-assisted feature where wrong answers have real cost? The design patterns above are precisely what I help teams put in place — let's have that conversation before the model meets production.
