Chapter 4: Recommendation & Personalization

Making Healthcare Feel Like It's For You

Here's a sentence that should make anyone who works in healthcare twitch: "We sent the reminder. They didn't show."

Somewhere in that sentence is a no-show rate, a missed revenue opportunity, a clinician with a gap in their schedule, and, more importantly, a patient who didn't get the care they needed. And somewhere behind that sentence is a reminder system that sent a text message to a 74-year-old who uses a flip phone, or an email to someone whose inbox has 40,000 unread messages, or a voicemail to someone who hasn't checked voicemail since 2019. The system technically did its job. The system also utterly failed at its job. Both of those things are true at the same time.

This is the chapter about fixing that particular flavor of failure. And dozens of others like it.

Personalization in healthcare is the practice of treating a single patient (or provider, or population segment) as an individual rather than as a row in a spreadsheet. In retail, personalization is about selling more stuff to the right people. "You bought hiking boots, you'll probably like this backpack." Low stakes. A missed recommendation costs you a sale. Amazon built a trillion-dollar business on this pattern, and the math is well-understood: collaborative filtering, content-based filtering, matrix factorization, two-tower neural networks, a dozen variations, all iterating on the same core idea of "find patterns in what similar users did and extrapolate."

Healthcare personalization uses the same mathematical toolkit. The stakes, the data, and the ethics are completely different.

What "Personalization" Actually Means Here

When a retail recommender gets it wrong, you scroll past and forget. When a healthcare recommender gets it wrong, the failure modes get interesting fast:

  • A care gap prioritization model nudges a patient toward a colonoscopy when the urgent issue is their uncontrolled blood pressure
  • A wellness program recommender steers a diabetic patient toward a generic weight loss program instead of the diabetes-specific one their plan actually covers
  • A treatment response predictor suggests a therapy that worked for "similar patients" but those similar patients were all 20 years younger and didn't have the same kidney function
  • An adherence intervention targets a patient for extra reminders when the actual barrier is that they can't afford the medication

Each of those is a recommendation problem. Each of them has a perfectly functional ML model under the hood. And each of them can fail in ways that affect outcomes, widen disparities, or quietly erode trust in the whole system.

So the frame for this chapter is: the algorithms are (mostly) not the hard part. The hard parts are everything around the algorithms.

The chapter covers ten recipes, ordered from "you can ship this in a quarter" to "this is research-grade and you need a clinical informatics board to approve it." The spread is intentional. Most organizations land somewhere in the first half of the list, and they land there because the second half requires a level of data, governance, and organizational maturity that's genuinely rare. That's fine. Recipe 4.1 (appointment reminder channel optimization) and Recipe 4.2 (patient education content matching) pay for themselves quickly and build the infrastructure you'll need later. Treat them as capability investments, not just point solutions.

What You'll See in This Chapter

A quick scan of the progression, so you can find the right entry point:

Recipes 4.1 to 4.2 (Simple). Channel and content recommendations. The stakes are low, the success metric is obvious (did the patient open it, show up, engage?), and A/B testing is straightforward. These are your three-to-four-month projects and a great first taste of operational recommender infrastructure.

Recipe 4.3 (Simple-Medium). Provider directory search ranking. Where personalization starts colliding with fairness: how you rank providers affects how patients flow to them, and algorithmic ranking choices can have material effects on access equity.

Recipes 4.4 to 4.6 (Medium). Wellness programs, medication adherence interventions, and care gap prioritization. Now you're predicting not just preference but behavioral response, and the downstream decisions affect how limited resources (program slots, outreach calls, clinical attention) get allocated. Budget a full quarter plus governance time.

Recipe 4.7 (Medium-Complex). Care management program enrollment. This is where rationing gets explicit: programs have capacity, patients have needs, and your recommender is choosing. The ethical weight of that choice needs to be designed into the system, not bolted on after.

Recipes 4.8 to 4.10 (Complex). Treatment response prediction, personalized care plan generation, and dynamic treatment regime recommendation. Direct clinical impact. Regulatory exposure. Counterfactual reasoning. These recipes are in the chapter because they represent where the field is heading, but they are not where you start, and most organizations will need partnerships with research institutions or vendors to attempt them responsibly.

Why Healthcare Personalization Is Hard (And Different)

A few things separate healthcare personalization from the retail playbook. Calling these out now, because every recipe bumps into at least one of them.

The Goal Isn't Engagement, It's Outcomes

Retail recommenders optimize for clicks, purchases, and time-on-platform. Healthcare recommenders that optimize the same way produce patients who engage with the app but get worse care. That mismatch sounds obvious when you write it down, and yet it's easy to fall into because engagement is measurable in days and outcomes are measurable in years. If your dashboard tracks "messages opened" and "content viewed" and nothing further downstream, your model will slowly drift toward whatever grabs attention rather than whatever helps. (This is the same pathology that turned social media recommenders into outrage engines. The math doesn't care what it's optimizing for; you have to care.)

The recipes in this chapter are pointed about what the right objective is for each use case. Sometimes it's a proxy metric (show rate, completion rate, enrollment rate) because the true outcome is too slow to learn from. When that's the case, the recipe says so, and it talks about how to avoid Goodhart's Law (when a measure becomes a target, it stops being a good measure).

Personal Baselines, Again

You saw this theme in Chapter 3, and it reappears here with a different flavor. "Patients who liked this also liked" is a weak signal when "liked" is poorly defined for health-related content. A patient who opened three articles about diabetes is not necessarily similar to another patient who opened three articles about diabetes: their baseline health literacy, their disease stage, their preferred learning modality, and their social context may be entirely different. Population-level collaborative filtering is a starting point, not an ending point. Most of the more sophisticated recipes in this chapter use some flavor of personal feature engineering (prior engagement patterns, response to specific intervention types, social determinants of health) that retail recommenders generally don't need.

The Cold Start Problem Has Teeth

Retail cold start is annoying. New user, no history, you show them popular items. In healthcare, the cold start patient is often the most important patient: the new diagnosis, the new enrollee, the patient who just transitioned from pediatric to adult care. You can't wait six months to personalize their care. You need reasonable defaults, cohort-level fallbacks, and a clear path for the model to update quickly as you collect signals. Every recipe addresses cold start explicitly because it's not a nice-to-have in this domain.

Fairness Is Not Optional

If your recommender gives some patient populations fewer or worse recommendations, you have built a system that widens healthcare disparities. That's not a theoretical concern. There's well-documented history of healthcare algorithms (risk stratification scores, for one notable and widely-cited example) being found to systematically underpredict need for some patient populations, not because the algorithms were "biased" in some abstract sense, but because they were trained on proxies (like healthcare spending) that encoded existing disparities in access to care.

Every complex recipe in this chapter includes a fairness consideration: which populations might be underserved, what proxies are in the feature set, and how subgroup performance is monitored. You do not get to skip this section. "We'll add fairness checks later" is how you end up on the front page of the newspaper.

Personalization implies inference about what a patient wants or will do. But patients are not Netflix viewers. They have explicit preferences about their care, they have the right to change their minds, and they have the right not to be nudged in directions they didn't sign up for. The recipes in this chapter distinguish between personalization that a patient would welcome (sending appointment reminders through their preferred channel) and personalization that requires explicit consent (enrolling them in a care management program based on risk scoring). Getting that line right is partly a legal question and partly an ethical one; the recipes flag where it matters and point at what "explicit" needs to look like.

Feedback Loops Are Slow and Noisy

In retail, you know within minutes whether the recommendation worked. In healthcare, the real outcome (did this patient have a better year because you recommended this intervention?) may take twelve to eighteen months to observe, and by the time you see it, the model has been retrained four times, the care team has changed, and the patient has moved to a new plan. The recipes in this chapter are honest about this: they lean on short-horizon proxies (engagement, completion, intermediate clinical markers) while being explicit that those proxies are not the actual goal. Long-horizon evaluation is built into the operational pattern, but you run it on a slower cadence than the model iteration cadence.

Regulatory Exposure Ramps Fast

Recipes 4.1 through 4.4 are generally in "operational tooling" territory: not FDA-regulated, not subject to significant external oversight beyond HIPAA. Recipes 4.5 through 4.7 start bumping into payer contracting, CMS quality measures, and state-level regulations around care management. Recipes 4.8 through 4.10 are at or near the FDA's expanding interest in AI-driven clinical decision support, and the regulatory posture is still evolving. Where a recipe sits on that spectrum, it says so. Your legal and compliance teams need to be partners from the scoping phase, not reviewers at the end.

The Technique Families You'll See

The recipes pull from several technique families. Quick map, because you'll see these names repeatedly:

Rule-based recommendation. Explicit "if-then" logic. "Patient has diabetes plus HbA1c > 9, recommend the intensive diabetes management program." Transparent, auditable, clinically reviewable. Doesn't scale when the rules multiply, and doesn't learn from feedback, but it's the right starting point for many use cases and often the right long-term answer for high-stakes decisions where explainability matters more than sophistication.

Content-based filtering. Recommend items that are similar to items the patient has engaged with, based on item features. "Patient read three articles tagged 'newly diagnosed diabetes type 2'; recommend more articles with that tag at a similar reading level." Works well for curated content libraries and cold-start scenarios because it doesn't need a user history for similar users.

Collaborative filtering. Recommend items based on what similar users chose. Classic matrix factorization, neighborhood methods, or modern two-tower neural architectures. Requires a reasonably dense interaction history and suffers on cold start. Useful when you have scale and when "users who did X also did Y" is a meaningful pattern.

Learning-to-rank (LTR). Given a pool of candidates and a context (query, patient, moment), learn to order them. Gradient-boosted trees (LambdaMART) and neural ranking models both live here. The natural fit for Recipe 4.3 (provider search) and for reordering any candidate list with rich context features.

Uplift / causal modeling. Instead of "who is most likely to have outcome Y," ask "who will be most affected by intervention X." This is the right frame for Recipes 4.5 and 4.7: you don't want to target the people who are guaranteed to succeed (they'd have succeeded anyway) or guaranteed to fail (they won't respond); you want to target the people whose outcome depends on whether they get the intervention. Uplift modeling is underused in healthcare and genuinely valuable when limited resources are being allocated.

Contextual bandits. A middle ground between pure offline recommendation and full reinforcement learning. The model chooses actions, observes outcomes, and learns over time, while balancing exploration (try something new to learn) and exploitation (use what works). Great for Recipe 4.1 (channel optimization) because feedback is fast and stakes are low. Less appropriate when you can't ethically randomize.

Reinforcement learning / dynamic treatment regimes. The deep end of the pool, and Recipe 4.10 is where it lives. Sequential decisions under uncertainty with delayed rewards. Requires counterfactual reasoning (what would have happened if we'd chosen differently) and very large, clean longitudinal datasets. Rarely deployed in clinical care today; active area of research.

LLM-assisted personalization (the new kid, again). LLMs can help generate personalized content (tailored education, visit summaries, conversational interfaces) and can serve as the reasoning layer that combines structured recommender output with patient context. The pattern you'll see in Recipes 4.2 and 4.9: an ML recommender picks the items, an LLM tailors the presentation. You get the auditability of the recommender and the fluency of the LLM, while keeping the LLM from freelancing on the actual clinical choices.

You don't need all of these for any one recipe. You do need to recognize them when you see them, because the choice of technique family drives the architecture, the data requirements, and the evaluation strategy.

Key Architectural Patterns You'll See Repeatedly

A few patterns compound across the chapter, so calling them out here saves repetition later:

Candidate generation plus re-ranking. Almost every recipe at the medium-complexity level and above uses a two-stage architecture: a fast, cheap first stage that narrows the item pool to a few dozen candidates, and a slower, smarter second stage that re-ranks them using richer context. This is the same pattern retail recommenders use at scale, and it translates cleanly to healthcare.

Feature stores and personal baselines. The same feature-store infrastructure you built for Chapter 3's anomaly baselines is reusable for personalization. Patient-level features, provider-level features, interaction histories. One store, multiple consumers.

Human-in-the-loop, still. Same pattern as Chapters 1, 2, and 3. Most healthcare personalization recipes generate recommendations that a human reviews, approves, or contextualizes before they reach the patient. The recommender is a productivity tool for staff, not a decision-maker. The recipes are explicit about where the human sits in the workflow and what they actually look at.

Explainability as a first-class output. "The system recommended program X" is not enough. Clinicians, care managers, and sometimes patients themselves need to know why. Feature contributions, similar cases, natural-language rationales (sometimes LLM-generated from the recommender's output). Every recipe that reaches a clinician includes an explainability payload.

Fairness monitoring as ongoing operations. Subgroup performance metrics are not a launch checklist item; they are a dashboard that someone looks at monthly. The recipes include specific metrics to monitor, specific cohorts to track, and specific thresholds that should trigger a review.

Consent and preference capture. Patient-stated preferences override inferred preferences. If a patient said "don't text me," no amount of "but the model thinks SMS has 3 percent higher response rate for this cohort" overrides that. The architectures treat explicit preferences as hard constraints, not soft features.

Feedback loops at multiple time horizons. Short loops (was the message opened?) feed model iteration. Long loops (did this cohort's outcomes improve?) feed program-level evaluation and occasional re-architecture. Running both is non-negotiable for anything beyond the simplest recipes.

Healthcare-Specific Considerations

Beyond the architectural patterns, a few considerations recur:

PHI everywhere. Recommender inputs, outputs, and logs all contain PHI. BAAs, encryption, audit trails, access controls: everything from earlier chapters still applies. A recommendation log is a patient data log.

Cohorts are not stereotypes. Cohort-level fallbacks are useful for cold start, but they can also encode assumptions about groups of patients that are statistically valid at the population level and offensive at the individual level. The recipes flag where this matters and suggest ways to avoid it (for example, using cohort fallbacks only for initial defaults and retraining to individual baselines quickly).

Care team context matters. A recommendation to a patient without context to their care team can lead to conflicting messages or duplicated interventions. Integration with the care team's workflow (visible recommendations, flagging when multiple recommendations target the same patient, coordinating timing) shows up in the more operationally mature recipes.

Social determinants of health (SDOH). Several recipes include SDOH data: transportation, housing stability, food security, financial strain. These features are enormously predictive and enormously sensitive. The recipes note where SDOH data is used, where it could encode bias, and where additional governance is warranted.

Equity-specific outcomes monitoring. Beyond "is the model accurate on average," you track "is it accurate and fair across the populations we serve." For some use cases, that means reporting stratified metrics to regulators, to quality committees, or to the communities the system serves. Plan for that reporting up front; retrofitting it is painful.

What You'll Build

By the end of this chapter, you'll have patterns for:

  • Choosing the right channel and timing for patient reminders so more people actually show up for care
  • Matching patients to educational content that's relevant, appropriate in reading level, and likely to be read
  • Ranking provider search results in a way that respects both patient preferences and access equity
  • Steering patients toward wellness programs they'll actually complete, not just enroll in
  • Targeting adherence interventions to the patients most likely to respond, so limited outreach capacity goes further
  • Prioritizing which care gaps to close first for a given patient, given their clinical picture and behavioral patterns
  • Allocating finite care management program slots to the patients who will benefit most from them
  • Predicting treatment response using cohorts of similar patients, with honest uncertainty quantification
  • Generating personalized care plans that combine structured recommendations with LLM-assisted tailoring
  • Exploring (cautiously, with appropriate guardrails) the research frontier of adaptive, sequential treatment recommendations

Each recipe is self-contained, but the infrastructure compounds. The feature store you build for Recipe 4.1 powers Recipes 4.4 and 4.5. The preference capture you implement for Recipe 4.1 is reused everywhere. The fairness monitoring dashboard you stand up for Recipe 4.3 extends naturally to every subsequent recipe. Treat the early recipes as capability investments. The later ones will be easier, faster, and safer because of them.

One last thing before we dive in: personalization in healthcare works best when it feels invisible. The patient who gets reminded in their preferred channel, the clinician who sees the right care gaps surfaced at the right moment, the care manager whose outreach list is prioritized by who will actually respond. Nobody says "wow, that was a great recommendation algorithm." They say "this system just works for me." That's the goal. If the system feels like it's recommending at you, the personalization failed, regardless of how good the AUC was.

Alright. Let's make healthcare feel like it's actually for them.

→ Recipe 4.1: Appointment Reminder Channel Optimization