Chapter 3: Anomaly & Outlier Detection
Finding the Weird Stuff
Here's a thing nobody tells you when you start working on healthcare data: most of the interesting problems are anomaly detection problems wearing different outfits.
Fraud detection? Anomaly detection. Patient safety monitoring? Anomaly detection. Lab quality control? Anomaly detection. Early warning systems for sepsis? Anomaly detection. Insider threat monitoring on EHR access logs? Also, you guessed it, anomaly detection. The specific techniques vary wildly, from dumb-simple threshold rules to neural networks trained on time-series embeddings, but the underlying question is the same: what does "normal" look like here, and which of these events isn't that?
That question is deceptively hard. It sounds like it should be a statistics 101 problem: compute a mean, compute a standard deviation, flag anything more than three standard deviations out. Done. Ship it. Except healthcare doesn't play by statistics 101 rules. The "normal" distribution of lab values varies by patient age, sex, medication history, and underlying conditions. The "normal" billing pattern for a pediatric cardiologist looks nothing like the "normal" billing pattern for a rural family practice. The "normal" vital signs trajectory for an ICU patient is literally different from the "normal" for that same patient on a general floor two days later. Every baseline is contextual, and getting the context wrong means your "anomalies" are just noise.
This is the chapter where we learn to find the weird stuff without crying wolf.
What Anomaly Detection Actually Is
At its core, anomaly detection is the practice of identifying observations that don't fit an expected pattern. The technical literature calls these outliers, novelties, or anomalies depending on who's writing and what flavor of statistical tradition they grew up in. For our purposes they're all the same thing: data points that warrant a second look because they don't match what the system expects to see.
There are three broad categories worth knowing about, because they drive very different architectural choices:
Point anomalies. A single observation that's unusual. A lab value that's physically implausible. A single claim for a procedure that's never been billed together with the associated diagnosis before. These are the easiest to detect because you're evaluating one data point at a time against a baseline. Most of the "simple" recipes in this chapter are primarily point anomaly problems.
Contextual anomalies. An observation that's normal in isolation but unusual in its context. A heart rate of 140 is fine during exercise, alarming at rest, expected during sepsis, and a red flag after surgery. The value alone doesn't tell you anything; you need the surrounding context (time of day, patient activity, recent interventions, comorbidities). Contextual anomaly detection is where most clinical monitoring lives, and it's substantially harder than point detection because you need a baseline model that accounts for the context dimensions.
Collective anomalies. A sequence or set of observations that together form an unusual pattern, even though each individual observation might look fine. A gradual drift in vital signs that predicts deterioration. A pattern of EHR access that doesn't match any single user's normal workflow but lights up when you look at it as a sequence. Epidemic detection works this way: no single case is an outlier, but the cluster is. These problems typically require time-series or graph-based methods and are the hardest to get right.
Most real healthcare anomaly problems are hybrids. Patient deterioration starts with point anomalies in vitals, becomes a collective anomaly when you consider the trajectory, and is fundamentally a contextual problem because the thresholds depend on the patient's baseline. That's why Recipe 3.7 (Patient Deterioration Early Warning) sits at the complex end of this chapter. You can't solve it with a single technique.
Why This Is Hard (Healthcare Edition)
Most anomaly detection tutorials use toy examples: credit card transactions, server log anomalies, manufacturing defect detection. Those problems are hard in their own ways, but healthcare has a specific flavor of difficulty that's worth calling out before we get into the recipes.
The Base Rate Is Brutally Low
True anomalies in healthcare are usually rare. Real fraud cases are a fraction of a percent of claims. True sepsis events are a small percentage of ICU admissions. Genuine EHR access breaches are buried in billions of legitimate access events. When your positive class is 0.1% of your data, even a 99% accurate classifier produces a flood of false positives. Ninety-nine percent accuracy sounds great in a demo. In production, it means reviewers are drowning in false alarms and start ignoring the system entirely.
This is the alert fatigue problem, and it's the single biggest reason anomaly detection systems fail in healthcare deployments. Not because the models aren't accurate. Because the precision-recall math is unforgiving when the base rate is this low. A system that catches 95% of fraud while generating 100 false positives for every true positive is worse than no system at all, because reviewers will stop looking. Every recipe in this chapter takes alert fatigue seriously. In some cases it's the primary design constraint.
Baselines Are Personal and Moving
"Compare against the average" is the classic anomaly detection heuristic and it falls apart fast in healthcare. The average heart rate across all patients is not a useful baseline for any specific patient. The average billing pattern across all providers is not a useful baseline for a pediatric oncologist. The average number of chart views per day is not a useful baseline for a nurse who just rotated onto a high-acuity unit.
You need personal baselines (this patient, this provider, this user), which means you need enough historical data per entity to establish what their normal looks like. New patients don't have baselines. New providers don't have baselines. Staff who changed roles don't have reliable baselines yet. Your anomaly detection system has to handle the cold-start problem gracefully, usually by falling back to cohort-level baselines (patients like this one, providers with this specialty and practice size) while building individual baselines over time.
And those baselines drift. Patients get older. Providers change practice patterns. Organizations change billing rules. A baseline trained six months ago may not reflect current normal. Continuous retraining, drift detection, and baseline refresh become operational requirements, not nice-to-haves.
"Rare" Isn't the Same as "Wrong"
A lot of anomaly detection systems implicitly assume that unusual equals bad. That's not how medicine works. A lab value three standard deviations from population norm might indicate a quality control failure, or it might indicate a genuine acute event that requires immediate intervention. A billing code that's rare for a provider might be fraud, or it might be a legitimate but unusual case. An access pattern that doesn't match historical norms might be an insider threat, or it might be a physician covering a colleague's panel during a sick day.
The difference between these cases is almost never in the data itself. It's in the context, the narrative, the workflow. Anomaly detection systems can surface candidates, but they rarely resolve them. That means you need review workflows, investigation capacity, and clear escalation paths baked into the architecture from day one. A recipe that produces a scored anomaly list without a plan for what happens next is not a finished product.
Adversaries Adapt
Some anomalies are produced by adversaries who are actively trying to avoid detection. Fraudsters learn which patterns get flagged and change their behavior. Malicious insiders test access boundaries to find what doesn't trigger alerts. This is a fundamentally different problem from passive outlier detection, and the techniques that work on non-adversarial data (simple statistical baselines, unsupervised clustering) can be gamed. Recipes 3.6 and 3.9 address adversarial settings explicitly.
Labels Are Scarce and Biased
Supervised anomaly detection (train a model on labeled examples of normal and anomalous) is the easiest approach when you have the labels. You rarely do in healthcare. Fraud labels come from investigations that took years to resolve. Sepsis labels come from chart review after the fact. Breach labels come from incidents that were detected (meaning the undetected ones aren't in your training data, which is a selection bias that quietly poisons your model). Most of the time you're working with unsupervised or semi-supervised methods and a small, biased label set for evaluation. That's not a reason to avoid the problem. It's a reason to be honest about what your model is learning and what it might miss.
The Techniques You'll See in This Chapter
The recipes pull from several technique families. Quick tour, because you'll see these names repeatedly:
Statistical methods. Z-scores, interquartile range (IQR) tests, control charts, moving averages, time-series decomposition. Cheap to compute, easy to explain, great for well-behaved data with known distributional properties. Where they fall down: high-dimensional data, non-Gaussian distributions, contextual anomalies. Start here when the data fits, don't force-fit them when it doesn't.
Distance and density methods. K-nearest neighbors, Local Outlier Factor (LOF), DBSCAN. These ask "is this point far from its neighbors in feature space?" No distributional assumptions required. Good for arbitrary-shaped normal regions. Downsides: they scale poorly with data size, and distance metrics get weird in high dimensions (the curse of dimensionality is a real thing, not just a meme).
Tree-based methods. Isolation Forest is the canonical example. Anomalies are easier to isolate in random tree splits than normal points are. Fast, handles mixed data types, works reasonably well out of the box. Downside: less interpretable than statistical methods, harder to tune than you'd expect.
Autoencoders and reconstruction-based methods. Train a neural network to compress and reconstruct normal data. Anomalies produce high reconstruction error because the model never learned to represent them efficiently. Great for high-dimensional data (medical imaging, complex EHR vectors). Downsides: needs a lot of data, needs a clean training set (if anomalies are in your training data, the model learns to reconstruct them too).
Time-series methods. ARIMA, state-space models, LSTMs, temporal convolutional networks. For detecting anomalies in sequences, forecasting expected values and flagging deviations, or identifying change points. Patient monitoring, billing pattern shifts, epidemic curves. Complex but sometimes unavoidable.
Graph and behavioral methods. For data that's inherently relational (provider-patient-claim graphs, user-resource access graphs), graph-based anomaly detection can surface patterns that feature-vector methods miss. Billing fraud rings, insider threat investigations, and outbreak contact tracing all benefit from graph approaches.
LLM-assisted anomaly detection (the new kid). This is worth flagging because it's a pattern you'll see increasingly in 2026 and beyond. Large language models can help with the context interpretation problem: given a flagged anomaly and its surrounding data, an LLM can generate a plain-language explanation of why it might be unusual, check it against clinical or billing rules encoded as natural language, and even draft investigation notes. They don't replace the detection pipeline, but they can substantially reduce the human time required to triage each alert.
You don't need all of these. You do need to know roughly when each one applies and why, so that when a recipe uses Isolation Forest rather than a neural autoencoder, you understand the tradeoff.
The Progression: Simple to Complex
This chapter is ordered by a combination of stakes, data complexity, and architectural difficulty. Here's the shape of the journey:
Recipes 3.1 to 3.2 (Simple). Well-defined problems with clear outcomes, low-stakes interventions, and abundant historical data. Duplicate claim detection and no-show pattern detection. The "did we catch it correctly?" question is easy to answer because the ground truth is observable (the claim really is or isn't a duplicate; the patient really did or didn't show up). These are your 4- to 8-week projects and a great place to demonstrate value before tackling harder problems. They're also excellent introductions to the operational patterns (review queues, feedback loops, threshold tuning) that you'll rely on for the complex recipes later.
Recipes 3.3 to 3.5 (Simple-Medium to Medium). Baselines become personal: provider-specific billing patterns, patient-specific lab history, pharmacy context. The data gets higher-dimensional. The stakes rise (medication errors, missed critical values). Real-time alerting starts to enter the picture. These are your two- to four-month projects. Plan for an operational dashboard and a clinician or analyst who owns the alerts.
Recipe 3.6 (Medium-Complex). Healthcare fraud/waste/abuse. This is where adversarial dynamics enter the picture and the cost of being wrong (in either direction) jumps significantly. Graph-based methods become genuinely useful here. Legal and compliance review becomes part of the architecture, not an afterthought. Budget a quarter to a half-year, and make sure your SIU (Special Investigations Unit) is involved from day one.
Recipes 3.7 to 3.8 (Complex). Direct clinical implications. Patient deterioration early warning and readmission risk detection. Minutes matter in one case, continuous monitoring matters in the other. You're integrating vital signs, labs, nursing notes, and sometimes patient-reported outcomes into a single scoring pipeline. FDA considerations may apply depending on how the output is used (decision support vs. autonomous action). These require clinical governance, validation on your own patient population, and often parallel running against the existing standard of care for months before go-live.
Recipes 3.9 to 3.10 (Complex). Cybersecurity access pattern anomalies and epidemic/outbreak detection. High-dimensional behavior spaces, adversarial dynamics (in 3.9), low signal-to-noise ratios, and coordination requirements that extend beyond your organization. These are the hardest recipes in the chapter, and frankly, they're included because they're important, not because most readers should start here. Organizations typically attempt these after they've built anomaly detection maturity on simpler problems.
You can read the chapter in order or jump to a specific recipe. If you're brand new to anomaly detection as a practice, starting with 3.1 and 3.2 will build the mental models that make the harder recipes easier to follow.
Key Architectural Patterns You'll See Repeatedly
A few patterns come up across multiple recipes. Calling them out here saves redundancy later:
Baseline-as-a-service. Personal baselines (per patient, per provider, per user) need to be built, stored, refreshed, and served at scoring time. Most recipes assume a feature store or equivalent baseline repository. The specific technology varies; the pattern is constant.
Confidence-gated review queues. Same pattern you saw in Chapter 1's OCR recipes, and for the same reason: the model is a first-pass filter, the human does the final call. The difference is that in anomaly detection, your review queue is the primary output. Getting this interface right (ranking, explanations, feedback capture) matters more than shaving another half-point of accuracy off the model.
Feedback loops as first-class components. Every alert that's reviewed generates a label: true positive, false positive, unclear. Those labels need to flow back into model retraining, threshold tuning, and rule refinement. Systems without feedback loops decay. The recipes include this pattern because it's not optional.
Explainability on every alert. When a clinician, reviewer, or investigator looks at a flagged case, they need to know why the system flagged it. "The model said so" is not acceptable. SHAP values, feature contributions, similar cases, or natural-language explanations (sometimes LLM-generated) are all used in the chapter depending on the use case. Pick one, commit to it, and build it into the alert payload.
Drift detection and model refresh. Baselines drift, models go stale, distributions shift. Monitoring that tracks prediction distribution shifts, feature distribution shifts, and alert rate changes is part of the operational infrastructure, not a nice-to-have. Several recipes include specific metrics to monitor.
Two-stage architectures. Fast, cheap first-pass detection (statistical rules or lightweight models) to reduce the data volume, followed by a slower, more sophisticated second-stage model on the candidate set. Common for high-throughput problems like claims review and EHR access monitoring. Lets you balance compute cost against detection quality.
Healthcare-Specific Considerations
Beyond the general anomaly detection challenges, healthcare adds texture:
PHI in training data and alerts. Anomaly detection models train on patient data. Alert payloads contain patient data. Every BAA, encryption, audit logging, and least-privilege concern from earlier chapters applies here. If an alert is sent to a reviewer's screen, that's PHI access and it needs to be logged. If model features include diagnoses or lab values, the feature store is PHI and needs the same controls as your EHR.
Bias and equity in detection. Anomaly detection systems can encode bias in subtle ways. A fraud detection model trained primarily on one type of provider may flag different types at higher rates, regardless of actual fraud risk. A clinical deterioration model trained on majority-population data may under-detect deterioration in underrepresented populations. Every complex recipe in this chapter notes specific bias concerns and where subgroup performance monitoring matters.
Regulatory exposure. Clinical anomaly detection (3.7, 3.8) may fall under FDA medical device regulation depending on how outputs are used. Fraud detection (3.6) has False Claims Act and investigative implications. Breach detection (3.9) ties directly to HIPAA breach notification requirements. The recipes flag these where relevant, but your legal and compliance teams should be partners from the requirements phase forward.
Workflow integration. An anomaly detection system that produces alerts nobody looks at is worse than no system: you now have documentation that you detected something and didn't act on it. Every recipe addresses the "so what happens when we flag something?" question. If your organization doesn't have capacity to review the alerts a system would generate, scope the system smaller. This is harder than it sounds and costs more projects than lack of technology does.
Investigation and audit trails. When an anomaly is flagged, acted on, or dismissed, that decision needs to be recorded with enough detail to reconstruct later. For fraud and breach cases, investigation records may be subpoenaed. For clinical cases, they may be part of risk management reviews. The architectures in this chapter treat the anomaly audit log as a first-class system, not a side effect of the alert pipeline.
A Note on Supervised vs. Unsupervised
Most of these recipes use a mix of supervised and unsupervised approaches, and the choice depends on label availability and problem structure. Don't assume you need one or the other before understanding your data situation:
- If you have reliable labels: supervised classifiers (gradient boosting, deep networks) usually outperform unsupervised methods because they learn what anomalies actually look like in your specific context.
- If you have no labels: unsupervised methods (Isolation Forest, autoencoders, clustering-based detection) let you surface candidates without predefined examples.
- If you have some labels (most common): semi-supervised approaches or unsupervised detection plus supervised re-ranking/triage models give you the best of both.
The recipes are explicit about which flavor they use and why. The chapter ends up with a mix because real healthcare problems do.
What You'll Build
By the end of this chapter, you'll have patterns for:
- Catching duplicate and suspicious claims before payment
- Identifying patients likely to no-show so you can intervene before the empty slot
- Flagging unusual billing patterns without harassing providers with legitimate practice variation
- Detecting medication dispensing anomalies that could harm patients
- Surfacing lab result outliers that indicate either collection errors or real acute events
- Building fraud detection pipelines that integrate with SIU investigation workflows
- Deploying early warning systems for clinical deterioration that respect alert fatigue as a real constraint
- Monitoring post-discharge trajectories to prioritize readmission prevention resources
- Detecting EHR access patterns that suggest insider threats or credential compromise
- Running syndromic surveillance for outbreak detection before official reporting catches up
Each recipe is self-contained, but the operational patterns compound. Organizations that build Recipe 3.1 well find that their review queue tooling, feedback loops, and drift monitoring infrastructure are directly reusable for Recipes 3.6 and 3.7. Treat the early recipes as capability-building, not just use-case-solving.
Alright. Let's go find the weird stuff.