Patient Segmentation

What is patient segmentation?

Patient segmentation groups a population by clinical risk, care needs, social circumstances or engagement, so each group can receive a suited intervention. It combines claims, EHR and patient-reported data with rules or models, and its output is a list of patients per segment that a care program can act on.

The value lies in the action, not the label. A segment that does not change who gets a call, a device, a visit or an education message is a report, and reports rarely change outcomes.

Segments also change over time. A patient moves between groups after a hospital stay, a new diagnosis or a change in housing, so segmentation has to run on a schedule and track movement.

Segmentation versus risk stratification

Risk stratification ranks patients by the likelihood of an outcome, such as an admission or a high cost year. Segmentation groups patients by what they need, which may or may not track with risk.

The two work together. A high-risk tier from a risk model can be split into segments, such as patients who need medication support, patients who need transport help and patients who need closer vital sign monitoring, each with a different program.

Keep them separate in the data model. Store the risk score and its model version on one side, and segment membership with its rule version on the other, so a change in one does not silently change the other.

Decide early which one leads. Programs with fixed capacity often rank by risk first and then segment the top of the list by need, while programs built around a specific service, such as transport help, start from the need and use risk only to set priority within it.

Which data feeds a segmentation model?

Segmentation draws on six kinds of data, and each carries its own lag and gaps. Know when each one is updated before relying on it.

• Claims: Diagnoses, procedures, pharmacy fills and costs across providers, complete but often weeks or months behind.
• EHR clinical data: Problem lists, medications, labs, vital signs and encounters, current but limited to the organization's own systems.
• Utilization events: Admissions, discharges and emergency visits from ADT feeds or health information exchanges, which signal sudden changes in need.
• Social needs: Screening results and coded social factors. In ICD-10-CM, categories Z55 to Z65 code social determinants of health such as housing, food and transport problems, as CMS describes in its Z code resources.
• Device and remote data: Readings from home blood pressure cuffs, scales or glucose meters for patients already monitored.
• Engagement: Portal use, missed appointments, response to outreach and stated preferences for contact.

Z codes are often underused in practice, so a segment that depends on them will miss many patients with real social needs. Pair coded data with screening answers stored as structured observations.

Joining these sources is its own task. Claims, EHR and device records often use different patient identifiers, so the pipeline needs a matching step with clear rules for uncertain matches. A wrong merge puts one patient's risk on another patient's record.

Which methods fit which question?

Pick the simplest method that answers the program's question. Rules suit eligibility, scores suit ranking, and clustering suits discovering groups no one has defined yet.

• Rules: Clear criteria, such as a diagnosis plus a recent reading above a threshold. Easy to explain and audit, and right for program eligibility.
• Published risk scores: Established indices for readmission or frailty, useful when the population matches the one the score was built on.
• Predictive models: Trained models that rank patients by the chance of an outcome, useful at scale but needing validation, monitoring and subgroup checks.
• Clustering: Unsupervised methods that find groups with similar patterns, useful for research and program design but hard to use directly for enrollment.
• Clinician review: A final list checked by a nurse or care manager, who removes patients the data misjudged and adds ones it missed.

Most programs start with rules and add a model once they have outcome data to train and test it. A model built before the program has run has nothing local to learn from.

How do you build a segmentation pipeline?

Build it in six steps, from the program's goal to a monitored, repeatable job. Each step should produce something a clinical owner can review.

• 1. Define the action: Name the program each segment feeds and the capacity it has, such as the number of monitoring devices or care manager hours.
• 2. Write the criteria: Draft segment definitions with clinical owners, in plain language first and then as code.
• 3. Assemble the data: Build a patient-level table from claims, EHR, ADT and screening data, with the date each value was last updated.
• 4. Run and review: Produce the first lists, have clinicians review a sample from each segment, and adjust criteria where they disagree.
• 5. Publish to workflow: Send segment lists into the tools staff use, such as a care management worklist or the monitoring platform's enrollment queue.
• 6. Monitor and revise: Track segment sizes, movement between segments, enrollment rates and outcomes, and version every change to the criteria.

Step 1 keeps the program honest. A segment of several thousand patients is not useful to a team that can enroll a few hundred, so the criteria must fit the capacity or rank patients within the segment.

How do segments drive monitoring and outreach?

Segments drive action when they arrive as tasks with an owner and a due date. A list in a spreadsheet tends to stall after the first week.

In FHIR terms, a segment can be published as a Group resource listing its members, and each outreach step as a Task assigned to a care team member. The monitoring platform reads new members, offers enrollment and records the result.

• Enrollment: Patients in a monitoring segment get an offer, consent capture and device shipment through one tracked workflow.
• Intensity: Segments set review frequency and alert thresholds, so high-need patients get closer attention without flooding staff with alerts for stable ones.
• Outreach channel: Engagement data picks text, call or portal message for each patient, based on stated preference.
• Exit rules: Each segment has rules for leaving it, such as a stable period of readings, so capacity frees up for new patients.

Record why each patient joined a segment. When a care manager calls a patient, a short reason such as a recent admission plus two high readings makes the conversation specific, and it lets staff spot a wrong inclusion before the call.

What fairness and privacy limits apply?

Segmentation that decides who gets care resources must not discriminate. Under Section 1557, 45 CFR 92.210 bars covered entities from discriminating on the basis of race, color, national origin, sex, age or disability through the use of patient care decision support tools.

In practice, test every rule and model for differences in who is selected across groups, and look for proxies. Past cost is a common example, because it can reflect access to care rather than need.

Privacy shapes the pipeline too. Limit the segmentation dataset to the fields the criteria use, restrict who can see full lists, and keep a log of which lists were sent where.

Write the fairness checks into the release process for each new criteria version. A short report per release, showing selection rates by group and any changes from the previous version, gives compliance staff something concrete to review.

Where segmentation programs go wrong

• Stale data: Claims-based segments miss a recent admission, and the patient most in need is not contacted for weeks.
• Cost as a proxy for need: A model trained on cost ranks patients with less access to care as lower risk than they are.
• No capacity check: Segments are larger than staff can serve, and outreach becomes random within the list.
• Unversioned criteria: Rules change without a record, and trend reports compare segments that no longer mean the same thing.
• No feedback loop: Enrollment and outcome results never return to the segmentation team, so criteria never improve.
• Lists outside workflow: Segment lists live in reports staff must open separately, and they go unused.
• Duplicate outreach: Two programs select the same patient from overlapping segments, and the patient gets competing calls in the same week.

Each of these is a design gap rather than a data science problem. Fresh event data, need-based inputs, capacity limits, versioned rules, outcome feedback, worklist delivery and a single owner per patient close them.

How Agnotic can help

Segmentation only pays off when its lists reach the staff and tools that act on them. Agnotic Technologies builds that path for care programs and digital health teams: patient-level data assembly from claims, EHR, ADT and screening data, versioned segment rules and models, fairness checks, and integration into monitoring enrollment and care management worklists.

For remote patient monitoring programs, Agnotic connects segments directly to enrollment, device setup and alert thresholds, so the people chosen are the people monitored.

Sources

• CMS Office of Minority Health: SDOH data with ICD-10-CM Z codes (Z55 to Z65)
• 45 CFR 92.210: Nondiscrimination in the use of patient care decision support tools
• HL7 FHIR R4: Group resource