The Problem With How We've Always Found Patients
For most of the history of clinical trials, patient identification has followed the same basic workflow: a coordinator pulls charts based on diagnosis codes, or screens referrals as they walk through the door, or relies on physicians to flag candidates they happen to remember. These methods share a common failure mode — they depend entirely on what a human happens to notice at the moment they're looking.
That dependency creates a structural enrollment bottleneck that no amount of recruitment advertising fully solves. A Phase III sponsor running a trial in non-small cell lung cancer doesn't have a shortage of eligible patients in the healthcare system. What they have is a shortage of the right mechanism to surface those patients reliably, at scale, before site bandwidth is consumed by unqualified screens.
EHR phenotyping is a fundamentally different approach to this problem — and sponsors who have deployed it are seeing enrollment velocity numbers that weren't achievable under coordinator-dependent identification alone.
What EHR Phenotyping Actually Means
The term "phenotype" in this context is borrowed from genomics but the concept applies cleanly to structured health records. A clinical phenotype is a computable definition of a patient state — not just a diagnosis code, but a pattern of codes, values, medications, procedures, and clinical notes that together define whether a patient plausibly meets a set of criteria.
A simple example: a protocol requiring "HbA1c ≥ 8.5% documented within 6 months, type 2 diabetes diagnosis, no prior insulin use, age 35-70." Coded as discrete ICD-10, LOINC, and RxNorm elements, this becomes a query that can run against a structured EHR repository and return a candidate list — without any coordinator having to manually review charts.
The more complex and clinically meaningful phenotypes involve natural language processing of physician notes, temporal logic (e.g., "diagnosis of condition X followed by lab value Y within a 90-day window"), and exclusion logic that catches contraindicated medications even when they're recorded as free-text. This is where the implementation difficulty lives, and where most off-the-shelf EHR query tools fall short of what a real inclusion/exclusion specification requires.
Structured Data vs. Unstructured: The Gap Most Tools Miss
EHR data at most health systems is roughly 40-60% structured — discrete fields, coded diagnoses, lab values, vitals. The remainder lives in clinical notes, radiology reports, pathology summaries, and discharge summaries. A phenotyping approach that ignores unstructured data will miss a large fraction of eligible patients, particularly in oncology, rare disease, and neurology where nuanced clinical characterization is often documented in narrative form rather than coded fields.
NLP-based criteria parsing addresses this gap by extracting clinical entities, negation, and temporal context from notes. The key performance indicators for NLP-based phenotype extraction — sensitivity (catching eligible patients) and positive predictive value (not flooding coordinators with false positives) — are fundamentally determined by how well the NLP model handles negation, family history attribution, and historical vs. current findings. These are not trivial NLP problems, which is why generic clinical NLP pipelines often require domain-specific fine-tuning to perform at the precision levels trial recruitment requires.
From Phenotype Signal to Enrollment Action
Consider a real-world scenario that illustrates the operational impact. An oncology-focused sponsor running a Phase II basket trial in KRAS-mutant solid tumors had been using coordinator-driven screening across six sites. Eighteen months in, enrollment was at 54% of target with no clear acceleration pathway. The fundamental problem: coordinators were screening based on diagnoses as patients came through the clinic, missing patients whose KRAS mutation status was documented in molecular pathology reports from prior treatment — reports that never surfaced in a routine diagnosis code query.
Deploying an EHR phenotype model that parsed both structured fields (tumor type ICD codes, oncology-specific LOINC codes) and unstructured pathology notes (entity extraction for "KRAS G12C," "KRAS G12D," "KRAS exon 2 mutation") against a three-year retrospective chart review identified over 200 additional candidate patients across those six sites who had never been presented to coordinators. Of those candidates, roughly 30% passed the eligibility pre-screening. That's a significant increment added to the active referral pipeline without changing the protocol or adding sites.
We're not saying EHR phenotyping alone closes enrollment gaps — site capacity, coordinator bandwidth, IRB timelines, and patient willingness are all independent constraints. But the identification layer is where most Phase II/III timelines hemorrhage the most, and it's also the layer most amenable to systematic improvement through better data utilization.
The Data Infrastructure Prerequisites
EHR phenotyping at scale requires that certain data infrastructure prerequisites be in place. The most commonly underestimated is FHIR R4 availability. Most major EHR platforms — Epic, Oracle Health (Cerner), Meditech Expanse — now expose FHIR R4 endpoints, but the completeness and update latency of those feeds varies substantially by health system configuration. A FHIR endpoint that only exposes administrative data or that refreshes on a 72-hour delay introduces matching lag that can cause a candidate to be enrolled in a competing trial before the referral is generated.
De-identification pipeline design is the second prerequisite that gets underestimated. A phenotyping system operating on data that flows to a sponsor or third-party matching platform must de-identify before export. The HIPAA Safe Harbor and Expert Determination methods for de-identification have specific requirements about which identifiers must be removed or transformed, and those requirements interact non-trivially with temporal phenotype logic that depends on exact dates. A "date shifted" EHR record maintains internal temporal consistency for relative intervals, but absolute date references (e.g., "enrolled in a prior clinical trial within 5 years") require careful handling to preserve eligibility logic accuracy.
What Sponsors Should Audit Before Deployment
Before deploying any EHR phenotyping-based recruitment solution, sponsors and their CRO partners should audit three things at each participating site:
- Structured data completeness: What percentage of patients with the target diagnosis have the relevant lab values, vital signs, and medication fields populated in structured form? In therapeutic areas like metabolic disease, cardiovascular, and diabetes, structured completeness is typically high (>75%). In oncology and neurology, it tends to be lower and supplemented heavily by unstructured notes.
- NLP training data relevance: If the phenotyping system uses NLP, was it trained on notes from comparable health system types? An NLP model trained predominantly on academic medical center notes will underperform at community oncology practices with different documentation patterns.
- EHR integration pathway: What is the specific API or data extract mechanism, and what is the realistic refresh rate? Near-real-time identification (hourly or daily) produces materially different enrollment outcomes than weekly batch extracts.
The Shift in Clinical Operations Thinking
The most important shift EHR phenotyping enables isn't technical — it's operational. When patient identification is proactive rather than reactive, the site coordinator role changes from gatekeeper to manager. Rather than screening hundreds of walk-ins or referrals of indeterminate quality, coordinators receive a pre-qualified candidate list and spend their time on consenting, scheduling, and retention. That reallocation of skilled coordinator time has a measurable downstream effect on screen failure rates and on coordinator burnout — a real and underreported driver of site underperformance.
Sponsors who treat EHR phenotyping as a data infrastructure question, rather than a recruitment marketing question, tend to get meaningfully different outcomes. The patients were always in the EHR. The question is whether your identification layer can find them before someone else's can.
As Phase II/III enrollment timelines continue to face pressure from compressed development timelines and increasing protocol complexity, phenotype-based identification is becoming a standard expectation rather than a competitive differentiator. The window to build that capability as a competitive advantage is narrowing.
