“What’s in a name? That which we call a rose/ By any other name would smell as sweet.”

–William Shakespeare, Romeo and Juliet

If you attended the ISPOR International conference in May, you couldn’t have missed that the most common phrase used in a session title was “artificial intelligence.” No surprise there, given how thoroughly AI had dominated the headlines for the last 6 months.

Probably because I didn’t want to write yet again about AI, I noticed another frequently used phrase in the session titles: “computable phenotype.” While it hasn’t exactly entered the popular discourse the way “AI” has, “computable phenotype” has been mentioned in several FDA documents relevant to ISPOR members, including the 2021 Guidance on using EHR and claims data to support regulatory decision-making.

So what is a computable phenotype, and what makes it worth discussing?

The FDA document referred to above references this online definition from the NIH: “a clinical condition or characteristic that can be ascertained by means of a computerized query to an EHR system or clinical data repository using a defined set of data elements and logical expressions.”

Not all that enlightening, is it?

If you have designed, conducted, or even read RWD research, you have encountered a computable phenotype.

For example, we recently conducted a study examining the use of antiviral drugs to treat influenza in a Medicare population. We defined our population as, “Medicare…beneficiaries at least 66 years of age with …at least one outpatient medical claim with an ICD-10-CM diagnosis code for influenza … during the period of October through March of each year.” Said another way, our population definition is a computable phenotype for “older people with influenza” for use in claims data.

A computable phenotype can also be called an operational definition or an algorithm.

Why the buzz about such a mundane concept? Probably because people love to make things sound more complicated than they are. Over the last two decades, my primary research work has gone from “analyzing insurance claims” to “examining big data” to “developing real world evidence,” without ever changing at all!

But new words can be helpful. There’s no denying the increasing importance of RWD in the FDA’s thinking and the rapidly expanding universe of data sources. (The number of new data vendors with a presence at ISPOR was remarkable.) When all we had was insurance claims, there was no need to call our inclusion and exclusion criteria anything but, well, “inclusion and exclusion criteria.”

Now that there are large, secondary data sets from a diversity of sources, a properly framed computable phenotype serves a practical purpose. It is a “meta” definition that can be applied in multiple dissimilar data sources. The FDA Sentinel system, for example, relies on claims from multiple payers, EHR from multiple vendors, as well as registry and other data. A broadly applicable computable phenotype for “older people with influenza” would have to be usable in all those different sources, so could not rely solely on age and ICD-10 codes, like ours did.

At least conceptually, then, the phrase “computable phenotype” might be useful, but just adopting this new terminology won’t do anything useful for the community of those who develop and use RWD research.

A computable phenotype, like any patient identification algorithm, is only useful to the extent that it is valid.

That is, how likely is a computable phenotype for “older people with influenza” to actually identify the population of interest? What proportion of the patients in our study had another kind of viral upper respiratory infection? As I’ve written about before, in most cases, the answer is “no one knows.”

I believe that the hard work of validating computable phenotypes will be the primary challenge for RWD researchers over the next decade. If we are able to make progress on this problem, generations of researchers, clinicians, and ultimately patients stand to reap significant benefits.