Phenotype Definitions Are the Smallest Unit of Trustworthy Data

The most important thing in a health-data system is also the smallest: the definition. I mean the precise, computable answer to a question like what exactly counts as a patient with type 2 diabetes. In the OHDSI world that is called a phenotype, and the community treats it with the seriousness it deserves. A recent OHDSI weekly digest highlighted a community call, led by Patrick Ryan, on building shared understanding across phenotype development, alongside the launch of ATLAS 3.0, the open tooling where these definitions are built and shared. That focus is not academic housekeeping. It is the foundation of trust.

Here is the principle I keep coming back to. If two teams cannot agree on the computable definition of a condition, then every model, every report, and every dashboard they build on top of it is quietly arguing about different things. The definition is the smallest unit of trustworthy data, smaller than a record, smaller than a table. This is the deep end of interoperability: it is not enough for data to move, the definitions have to mean the same thing on both ends. Get that right and shared, and the whole stack above it can be trusted. Get it wrong, or leave it in one analyst's head, and nothing above it means what you think.

Modeling is the fun part, and it is also the part everyone rushes to. But a model trained on a fuzzy definition of the outcome learns a fuzzy thing. Before I let anyone build, I make sure the cohort is defined precisely: inclusion, exclusion, the exact codes, the time windows. That is what OHDSI phenotype work does in the open. It is slow, it feels like bureaucracy, and it is the single highest-leverage hour you can spend, because every downstream result inherits it.

A definition written in prose is a wish. A definition written as executable logic against a common data model is a fact you can test. If you cannot run the definition and count exactly who it captures, you do not really have one. Computable phenotypes, built in shared tooling like ATLAS, turn a vague clinical concept into something you can inspect, reproduce, and argue about with evidence instead of opinion.

Codes get revised, guidelines shift, and a definition that was right last year can silently drift. So I version phenotypes the way engineers version code: every change tracked, every result tied to the exact definition that produced it. Without that, you cannot tell whether a number moved because the world changed or because someone quietly edited the cohort. Versioning is how a definition stays trustworthy over time, not just at the moment it was written.

A definition can be computable, shared, and still wrong, capturing people it should not or missing people it should. So I validate: check the phenotype against clinical review, look at who it includes and excludes, and measure how well it actually identifies the condition. An unvalidated phenotype is a confident guess dressed as data. The OHDSI community publishes and reviews these definitions precisely so they are not taken on faith.

The worst place for a critical definition is inside one analyst's private script, undocumented and unshared. When they leave, the meaning leaves with them, and no one can reproduce the number. A phenotype developed and published in shared tooling is an asset the whole organization can reuse and trust. A private query is a liability with a single person's name on it. I move definitions out of private scripts and into shared, versioned, validated form as fast as I can.

Everything glamorous in health AI, the models, the predictions, the dashboards, sits on top of a definition someone had to pin down. When that definition is precise, computable, versioned, validated, and shared, the whole tower is trustworthy. When it is fuzzy or private, the tower looks fine and is quietly built on sand. So I start at the bottom, with the phenotype, and I treat agreeing on it as the real work, because it is. Communities like OHDSI have known this for years. The rest of health AI is catching up.