- A computable phenotype is an executable definition of a patient group — explicit logic over diagnosis codes, medications, labs, and time, not a clinician's impression.
- EHR data is shaped by billing and workflow, so a lone diagnosis code is weak evidence; good phenotypes triangulate across several independent signals.
- Phenotypes are validated like diagnostic tests: run the algorithm, sample the flagged patients, review charts, and measure positive predictive value.
- Versioned, deterministic phenotype definitions can be shared, tested, and audited; ad-hoc SQL on a laptop cannot.
On this page
Ask three analysts to pull "all the patients with type 2 diabetes" from the same hospital database, and you will get three different lists. One filters on a diagnosis code. One adds metformin prescriptions. One remembers that metformin is also prescribed for polycystic ovary syndrome and starts writing exceptions. All three lists are defensible. None of them agree.
Multiply that by every condition, every site, and every study, and you have one of the quietest problems in medical research: before anyone can study patients, someone has to find them. Finding them is harder than it sounds.
Why a diagnosis code is weak evidence
A diagnosis code in an electronic health record does not mean the person has the disease. It means someone had a reason to record the code — and the reasons are many.
EHR data is shaped by billing and workflow, not by research questions. A code can mark a confirmed diagnosis, a suspicion being ruled out, the justification for a referral, a problem-list entry copied forward long after it stopped being true, or a coder's best fit for reimbursement. Validation studies that check code-only definitions against actual charts routinely find both kinds of error: flagged patients who never had the condition, and unmistakable cases the codes missed because care happened across town or the condition hid under a neighboring label.
For some conditions the gap is tolerable. For others it swallows the study. Interstitial cystitis is a diagnosis of exclusion with no confirmatory test; patients often collect years of other labels before the right one lands in a chart, which is one reason research on it has been so hard.
What a computable phenotype actually is
A computable phenotype is an executable definition of a patient group: explicit logic over diagnosis codes, medications, laboratory results, procedures, and time, written so that a machine — not anyone's judgment on the day — decides who is in.
Computably phenotyped, "type 2 diabetes" stops being a phrase and becomes a specification: at least two outpatient codes from a defined list on separate days, or one inpatient code; or a hemoglobin A1c at or above 6.5%; or a prescription from a defined medication class — minus patients with type 1 codes, minus gestational windows, minus metformin-only patients who also carry a polycystic ovary syndrome code. Every clause written down. Every threshold explicit. Run it twice and get the same answer. Hand it to another hospital and get a comparable one.
The discipline has a lineage. The eMERGE network — an NIH-funded consortium that linked biobanks to EHRs across the United States — spent years building phenotype algorithms that had to work at many institutions at once, and shared them through PheKB, the Phenotype KnowledgeBase. The durable lesson was not that phenotyping is easy. It was that phenotype definitions are scientific instruments, and instruments get shared, versioned, and tested.
The anatomy of a phenotype definition
Most phenotypes are assembled from the same five ingredients, and most phenotype failures trace back to one of them.
| Ingredient | Example | What goes wrong without care |
|---|---|---|
| Diagnosis codes | Two type 2 diabetes codes on separate days | Rule-out and copied-forward codes inflate the cohort |
| Medications | A prescription mapping to metformin in RxNorm | Drugs reused across conditions create false positives |
| Lab results | A1c at or above 6.5% under the right LOINC code | Unit mismatches and missing results skew who qualifies |
| Temporal logic | Codes at least 30 days apart, labs before the index date | One noisy encounter impersonates chronic disease |
| Exclusions | No type 1 code, no gestational window | Lookalike conditions contaminate the result |
Notice how much of that table is vocabulary work. Codes, drugs, and labs each live in their own coding system, and a phenotype that travels between sites has to speak all of them. That is the job of SNOMED, LOINC, ICD-10, and RxNorm — and of common data models like OMOP, which give phenotype logic a standard set of tables to run against anywhere.
How you know a phenotype works
You validate a phenotype the way you validate a diagnostic test: run it, sample the patients it flagged, have clinicians read their charts, and measure how often the algorithm was right.
The headline number is positive predictive value — of the patients selected, the fraction who truly have the condition. Well-built published phenotypes report PPV, and the strong ones sit above 90 percent. Sensitivity — how many true cases the definition finds — matters just as much and is harder to measure, because nobody hands you the list of patients the algorithm missed. Validation is also stubbornly local: a definition tuned at an academic medical center can degrade at a community hospital with different coding habits, which is why serious networks revalidate before they trust, and why data quality is something you measure rather than assume.
A phenotype without a validation story is an opinion with a WHERE clause.
Versioned and deterministic, or it does not count
What separates a phenotype from an ad-hoc query is not sophistication. It is accountability.
An analyst's one-off SQL lives in a file on a laptop. It has no version, no tests, and no answer — six months later — to the question "which definition produced this cohort?" A phenotype engine treats definitions as artifacts: identified, versioned, validated, and executed deterministically, so the same definition over the same data yields the same cohort, with a record of every run. The OHDSI community built its tooling around precisely this idea — cohort definitions expressed in a standard, shareable format that any site on the common data model can execute without translation.
The stakes run past reproducibility. Eligibility criteria for a trial registered on ClinicalTrials.gov are a phenotype. A regulator examining a real-world-evidence submission is examining a phenotype. An ethics board approved a specific definition, not whatever the query drifted into afterward. From question to dataset, the cohort definition is the load-bearing wall.
This is also where Mithras Health has planted its flag. On the platform, finding patients is the job of a deterministic phenotype engine: definitions are versioned artifacts, executed over consented records kept as FHIR R4 with OMOP views for research, and every run lands in an append-only audit trail. A locally hosted AI can help a researcher draft or refine a definition — but the engine decides who matches, never the model, and no cohort below the k ≥ 5 floor leaves the gate.
Medicine will keep saying "patients with X" in plain English, and records will keep being messy — both are permanent conditions. The craft lives in between: definitions precise enough to execute, honest enough to validate, and stable enough to audit. Get that right, and two researchers who disagree about a cohort can finally disagree productively. They are at last looking at the same definition.
Appendix · questions
Questions, answered
What is a computable phenotype?
Why not just use diagnosis codes to find patients?
How is a computable phenotype validated?
What is PheKB?
The patient-mediated research-data platform for chronic disease — 28 conditions, worldwide consented sources, one auditable spine. Join the launch list.
The sun is rising on chronic-disease research.
One email when we launch — and nothing else. Patients, researchers, sponsors, and programs all start here.