How health systems find the right patients in their EHR data

The email arrives from a trial sponsor: how many of your patients have moderate-to-severe COPD with two exacerbations in the past year? The research director knows what the honest answer costs. Weeks of coordinators pulling charts, a spreadsheet nobody fully trusts, and a number with no accuracy estimate attached.

That scramble is stranger than it sounds, because 99.4% of U.S. non-federal acute care hospitals ran a certified EHR in 2024. The answer already sits in a database; what's missing is a defensible way to ask. Computational phenotyping is the discipline that closes that gap. It's quietly becoming the difference between health systems that monetize their clinical data and those that just store it.

What is a computable phenotype?

A computable phenotype is a precise, executable definition of a patient population: a set of rules or a model that a computer can run against EHR data to answer "which of our patients actually have condition X?" It takes the judgment a clinician would apply one chart at a time and encodes it once, so it runs against every chart, every day.

The word "phenotype" comes from research, but the business translation is simple: a phenotype is a patient list you can defend. That doesn't mean "everyone with a diabetes billing code." It means "patients with one inpatient E11.x (type 2 diabetes) diagnosis, or any two of the following within 24 months: an outpatient E11.x diagnosis, an A1c ≥ 6.5%, a diabetes medication other than metformin alone," a definition specific enough that when a trial sponsor, a payer, or a quality auditor asks how the list was built, you can show them.

That defensibility is the whole point. Billing codes exist to get claims paid, not to describe patients, and raw billing-code queries misfire accordingly: rule-out visits, resolved conditions, documentation that lives only in the notes. Our breakdown of phenotyping approaches, later in this series, makes that case in depth.

Why should a health system executive care about patient cohort identification?

Because four of the most valuable things a health system can do with its data (recruit for trials, close care gaps, manage risk contracts, and build registries) all start with the same unglamorous step: finding the right patients, accurately, at scale. Get cohort identification wrong and everything downstream is built on sand. Get it right once, as shared infrastructure, and every downstream program can draw on it instead of paying to rebuild it. Run those four programs in silos and you're funding four teams to answer the same question, and none of them can show their work.

Clinical trial recruitment

Low recruitment is the leading cause of early trial termination. That failure costs both sides: sponsors lose protected revenue for every month a launch slips, and health systems lose the per-patient revenue and repeat business that come with being a site that delivers. Sites that run eligibility criteria as computable phenotypes against their live EHR can flip the economics: instead of coordinators hand-screening charts, the system produces a ranked list of likely-eligible patients as soon as the study opens. We go deep on how this works, and what it's worth per enrolled patient, in our companion piece on trial recruitment with computational phenotyping (Part 4).

Care-gap closure

Every quality program (HEDIS, Stars, ACO quality measures) is at bottom a phenotype problem: compute the denominator the measure spec defines (who should have gotten the screening, the statin, the follow-up), compute the numerator (who did), and work the difference. Systems that rely on claims-based gap lists from payers are working stale, incomplete data with months of lag. A phenotype running against your own EHR can find the gap far earlier, while there's still time in the measurement year to close it. That's revenue, because Stars ratings and quality withholds are dollars.

Risk stratification for value-based contracts

In calendar year 2024, 44.9% of U.S. healthcare payments flowed through value-based arrangements, and in the prior year's HCP-LAN measurement (calendar year 2023), 28.5% carried downside risk. Under those contracts, you make money by knowing which patients are trending toward high cost, earlier than the claims data shows it. That's a two-part system: phenotypes identify who belongs in which clinical population, and predictive models estimate what happens to them next.

Teams that skip the first part and train models on billing-code cohorts get models that confidently predict outcomes for the wrong patients. Phenotyping is the data-quality floor under every risk model you'll ever build.

Registry building

Disease registries, whether for accreditation, device surveillance, research partnerships, or pharma data collaborations, have traditionally been fed by manual abstraction: nurses reading charts and keying fields. A computable phenotype plus automated data extraction turns a registry from a perpetual staffing cost into a pipeline, and turns your accumulated clinical data into an asset that research partners will pay to access. For a sense of the scale this unlocks, see our piece on big data in healthcare.

How do phenotyping algorithms actually work?

At a high level, we group the approaches into four working families. (The academic literature often collapses them into two, rule-based versus machine-learned; we split by what each costs to build and defend, because that's the axis a buyer decides on.)

Rule-based phenotypes encode explicit clinical logic (codes, labs, meds, temporal windows); they're transparent and auditable, which regulators and clinicians like.

NLP-based approaches pull signal out of clinical notes, where an enormous share of phenotype-relevant detail lives: symptoms, severity, smoking status, ejection fractions. We've written about NLP in healthcare more broadly.

Machine-learning phenotypes trade some transparency for the ability to find patients rules would miss.

And LLM-based approaches are the newest entrant, promising faster development at the cost of harder validation.

Most production systems combine families rather than picking one; the post-acute care platform we built does the same. Choosing among them is still a decision with real trade-offs, and it's the subject of our full breakdown of rules vs. NLP vs. ML vs. LLM phenotyping approaches (Part 2).

Whichever family you choose, the pipeline around the algorithm looks the same. Data in, definition applied, accuracy measured, cohort put to work:

One warning worth stating here: a phenotype that performs beautifully at the institution that built it routinely degrades when moved to a different EHR, coding culture, or patient population. If you're planning to use a published algorithm or deploy across multiple sites, read our piece on phenotype portability and multi-site validation (Part 3) before you trust anyone's reported accuracy numbers, including your own vendor's.

Should you build phenotyping capability or buy it?

Buy the commodity layers; build (with help) the layer that touches your data and your workflows, because that's where off-the-shelf products consistently underdeliver. The decision logic:

Buying works when your need matches a vendor's pre-built content: standard HEDIS measures, common-condition registries, a trial-matching platform for the study designs it already supports. If a product's existing phenotype library covers your use case and its accuracy claims survive validation on your data, buying is faster and cheaper.

Building wins when the phenotype is the differentiator: rare or complex conditions, sponsor-specific eligibility criteria, post-acute populations that mainstream vendors ignore, or any case where the cohort feeds a revenue-bearing decision you can't afford to get wrong. It also wins when you need the phenotype to live inside your workflow, firing inside the EHR as clinical decision support rather than sitting in a report someone has to remember to run.

The trap is the unexamined middle: buying a platform, discovering its phenotypes were validated on someone else's population, and quietly assigning two analysts to hand-fix its output forever. If you're going to pay for accuracy, demand the validation evidence; if you're going to build, budget for validation as a first-class deliverable, not a nice-to-have. If your analysts have to correct every cohort by hand, you built it anyway, and paid twice.

What does a development partner actually contribute?

Three things that determine whether a phenotyping effort produces a defensible asset or an unusable one-off.

EHR integration that survives contact with reality. Phenotypes are only as fresh as the data feeding them. A partner who has done this before builds on standards (FHIR APIs, bulk data export, and the rest of the interoperability stack) so cohorts update continuously from Epic, Cerner, or a post-acute EHR instead of from a quarterly extract, and so the pipeline doesn't collapse at the next EHR upgrade.

Validation against chart review. This is the step that separates engineering from wishful thinking: clinicians review a statistical sample of the algorithm's output against the actual charts, and the phenotype ships with measured sensitivity and positive predictive value, numbers you can hand to a sponsor, a payer, or an IRB. We treat the validation protocol as part of the deliverable; a cohort without an accuracy number is a liability with a UI. The phenotyping platform we built runs in production in skilled nursing, where a detection the staff can't trace to evidence simply gets ignored, so every cohort membership carries its supporting evidence and a confidence score.

HIPAA-compliant pipelines from day one. Phenotyping pipelines concentrate PHI by design (that's their job), which means access controls, minimum-necessary scoping, audit trails, and de-identification paths have to be architected in, not bolted on. Retrofitting compliance is where most healthcare software projects go to die; we've written a full companion piece on PHI governance for phenotyping pipelines (Part 5) covering what auditors and privacy officers will ask for.

The pattern across all three: computational phenotyping is a data engineering discipline with a clinical validation requirement and a compliance boundary, not a data science project that happens to touch the EHR. That's why the teams that succeed pair clinical informatics judgment with production software practices.