Why is phenotyping difficult in OHDSI? Blame the concept set expression and vocabulary

Today, I want to discuss a known but perhaps less spoken about problem, inspired by the recent forum post from @Chris_Knoll (Using the ‘Mapped’ function of concept set expressions).

I am a big fan of the OHDSI Cohort Definition model (i.e., the CIRCE model) and the ATLAS UI for cohort definition as it provides an elegant framework for defining entry events, inclusion rules, and exit criteria. However, I often find myself not appreciating the limitations of its concept set expression, the structure of the OMOP vocabulary tables (concept_ancestor and concept_relationship), and the sometimes-painfully ambigious distinctions between standard vs. non-standard concepts.

I believe we must improve these foundational elements. We need to reduce the inherent ‘difficulty’ in phenotyping, minimize the need for ‘vocabulary SQL acrobatics’, and escape the recurring ‘version nightmares’.

1. Complex Concept Sets are Unavoidable

Let’s start with an obvious point: we cannot avoid using complex concept set expressions. Relying solely on a conceptId plus its descendants is rarely sufficient (Sorry, @Christian_Reich ). This is because of the polyhierarchy in concept_ancestor, simply pulling in all descendants often introduces specificity errors. Lets call this established and not debate this.

2. CIRCE Concept Set Expression does not support the concept_relationship thus ignores laterality

If we agree that complex expressions are necessary, the next question is: Do our tools support building them effectively, or are we forced into complex acrobatics?

Currently, the concept set expression model in CIRCE supports only two modes of traversal:

1. Hierarchy (Vertical): Using includeDescendants, which queries the pre-computed concept_ancestor table. This is fast and powerful for parent-child relationships.
2. Mapping (Limited Horizontal): Using includeMapped. This is an occasionally used acrobatic maneuver strictly limited to the hardcoded 'Maps to' relationship in concept_relationship (as discussed in the forum link above from @Chris_Knoll ).

This limitation means that the rich, ‘lateral’ ontological relationships stored in concept_relationship—such as ‘Has causative agent’, ‘Has finding site’, or ‘Has active ingredient’—are essentially locked away from us within the ATLAS/CIRCE framework. We cannot use them to define our concept sets.

3. Example: The Challenge of DILI (Drug-Induced Liver Injury)

Complex phenotypes like DILI perfectly illustrate this difficulty. The clinical idea is straightforward:

Find conditions representing liver injury that are NOT caused by other specific etiologies like viruses, alcohol, or physical obstruction.

Currently, we solve this using cohort definition acrobatics—perhaps 10 inclusion rules requiring exactly 0 occurrences of hepatic viruses within -7 to +7 days of the hepatitis event, etc. We do this because the entry event concept set cannot leverage laterality; it can only navigate parent-child relationships.

What we should be able to ask the vocabulary is: “Show me all descendants of ‘Liver Injury’ that DO NOT have a ‘Caused by’ relationship to a descendant of ‘Virus’ or ‘Alcohol’.”

Because CIRCE concept set expression cannot traverse the ‘Caused by’ relationship, we are forced into a painful, manual workaround:

• Manual Curation: We must painstakingly search the vocabulary for every pre-coordinated concept that implies a non-drug cause (e.g., “Alcoholic hepatitis,” “Acute viral hepatitis B,” “Obstructive biliary disease”).
• Brittle Exclusion List: We then add this long, manually curated list to the “Excluded Concepts” panel. Its brittle because the concept set expression does not automatically add any updates to our clinical idea on what may be causing the disease.

This workaround is not just tedious; it’s the primary source of the “difficulty” and “version nightmares” I mentioned. It is error-prone (leading to low recall or specificity errors), and the list becomes obsolete with the next vocabulary update, requiring the entire manual process to be repeated. And do not get me started on the added complexity of non-standard ICD10CM/ICD9CM code mapping.

4. Why This Matters for the Future – because the community is solving this phenotyping is difficult problem.

I am hearing about many innovations being built on top of the existing concept_ancestor structure and the current CIRCE model—for example, using generative AI or vector embedding-based semantic search to build concept set expressions.

Perhaps these approaches will succeed, and we can continue to rely solely on concept_ancestor without using the concept_relationship. But perhaps we are overlooking a solution that already exists within our ontology (i.e., laterality) and hamstringing these new tools by building them on an incomplete foundation.

This is even more critical in domains like cancer phenotyping, where laterality is essential for distinguishing key characteristics:

• Origin/Status: Primary (originating in the lung) vs. Secondary (metastasis from elsewhere).
• Morphology: Malignant (cancerous) vs. Benign.
• Histology: Non-Small Cell Lung Cancer (NSCLC) vs. Small Cell Lung Cancer (SCLC).
• Location: Lower respiratory tract (lung/bronchus) vs. Upper respiratory tract.

To achieve robust, reproducible, and scalable phenotyping, we need tools that can navigate the full richness of our vocabulary, not just the hierarchy.

There are many ways to tackle this problem – if we agree this is a problem. Maybe we should dream big – rethink this completely and adopt labeled property knowledge graphs and throw away the concept_ancestor and concept_relationship (making us AI/LLM ready). Maybe we should not blindly put any concept that does not have equivalence as non-standard (e.g. ICD10CM codes that do not have 1:1 equivalence mapping) and do lossy mapping but instead make them snomed extensions and make them standard with proper descendants. Maybe we should do a breaking change to circe to support knoweldge graphs instead of SQL.

A little more about the two OMOP vocabulary tables: concept_relationship and concept_ancestor. concept_relationship provides the foundational, direct links between concepts. concept_ancestor is a derived optimization table specifically designed to handle complex hierarchies.

Concept Relationship (https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_relationship)
The concept_relationship table stores the direct, asserted relationships (fundamental truths, axioms) between two concepts, as defined by the source vocabularies (e.g., SNOMED CT, RxNorm, LOINC) or curated by the OHDSI community vocabulary team. It defines how two concepts are related. It bridges different vocabulary domains (e.g., linking a condition to a drug that treats it) and different source terminologies (‘Maps to’, e.g., mapping ICD-10 to SNOMED). It only stores immediate relationships. If A is related to B, and B is related to C, this table stores (A-B) and (B-C), but not (A-C). It captures many relationships e.g., ‘Has active ingredient’, ‘Has finding site’, ‘Has causative agent’ via relationship_id with hierarchical relationships represented using ‘Is a’.

Concept Ancestor (https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor)
The concept_ancestor table is derived from the hierarchical relationships (‘Is a’) present in concept_relationship. It represents the transitive closure of the vocabulary hierarchies. Its purpose is to provide a pre-calculated lookup of all hierarchical lineages. It stores beyond immediate relationships, i.e., If A is a B, and B is a C, concept_ancestor explicitly stores (A-B), (B-C), and (A-C)—but only in a hierarchical context (i.e., derived from ‘Is a’). It does not include non-hierarchical relationships like ‘Maps to’ or ‘Has ingredient’. Since it is a derived table from hierarchical relationships, it is limited to ‘Is a’ relationships between valid and standard concepts. By precalculating, the concept_ancestor transforms complex hierarchical traversals into simple, efficient JOIN operations. Without concept_ancestor, concept_relationship table based queries will require a complex and slow recursive CTE.

In summary, concept_relationship is difficult to query using SQL for deep relationships because of the explosion of CTEs and recursiveness. Concept_ancestor is an elegant workaround to achieve the goal of transforming complex hierarchical traversals into simple, efficient JOIN operations. However, concept_ancestor is limited to ‘Is a’/‘subsumes’ relationship_id, standard concepts (and classification?), and valid concepts.

In reality, concept_ancestor is a pragmatic choice designed to achieve the OHDSI mission of network studies on multiple DBMS with computational efficiency. It achieves this by using pre-computed content where possible. OHDSI tools (Circe) do not support the dynamic generation of complex SQL to traverse the concept_relationship table. Further, SQL-based queries that are overtly complex are likely to have performance issues and potentially fail over the multiple DBMS that OHDSI network studies would like to support.

But because it only supports a limited set of relationship_id (‘Is a’/‘Subsumes’) and because OHDSI tools do not support the richness of the concept_relationship, we can’t leverage these in the Cohort Definitions. Obviously, ‘Has causative agent’ is a special relationship_id that does not represent a parent-child/ancestor relationship.

The above is just one explanation as to why phenotyping is difficult. This difficulty is further explained by:

• Standard/non-standard: We attempt to pick standard vs non-standard based on some quality judgments like whether a code follows principles like non-redundancy, atomicity, compositionality, clarity and unambiguity etc., but vocabulary creators have to make pragmatic decisions to balance expressive power and practical usability. Do we know how good is our classification of standard/non-standard. If we get a list of ICD codes as the source of truth, we waive it off as being inferior—probably because the effort to create a ‘standard’ based concept set expression is a pain, and it is so much easier to start a concept set expression from scratch.
• Mapping choices: if we declare a code to be standard and a code to be non-standard, then we have to map them. If a non-standard code has a meaning that is not equivalent to a standard code, then we map in a lossy way to a broader standard concept. This, while intuitive, causes headaches in concept set expression building because selecting a descendant will increase the probability of pulling codes in unexpected ways.

I think this problem may be succinctly described as the SQL Expressivity Gap. This gap is fundamentally a mismatch between the query language (SQL) and the underlying data structure (an ontology, which is inherently a graph). Graph databases (e.g., Labeled Property Graphs or LPGs) and their associated query languages (e.g., Cypher) are explicitly designed to handle the interconnected nature of ontological data.

In theory, they offer significant advantages over SQL in this domain:

• Expressivity and Intuition: Graph languages can express complex biomedical criteria much more intuitively by directly mirroring the ontological structure.
• Conciseness: A query traversing multiple relationship types that might require dozens of JOINs in SQL can often be represented in a few lines of Cypher.
• Maintainability and Transparency: Simpler expressions enhance readability and reduce the overhead associated with maintaining and validating concept sets, particularly across vocabulary updates.
• LLM Compatibility: The pattern-matching syntax of graph languages aligns well with the capabilities of Large Language Models (LLMs), suggesting significant potential for accelerated, AI-assisted phenotype development.

Illustrative Use Case: DILI

Continuing with the example of Drug-Induced Liver Injury (DILI):

“Create a concept set representing liver injury Concept IDs that are NOT caused by other specific etiologies like viruses, alcohol, or physical obstruction.”

In the current SQL/Circe paradigm, we resort to “vocabulary acrobatics”: manually curating extensive, brittle lists of pre-coordinated concepts (e.g., “Alcoholic hepatitis”) for exclusion. This list requires constant maintenance as the vocabulary evolves.

In a graph paradigm, this requirement can be expressed directly against the ontology: “Select all descendants of ‘Liver Injury’ that DO NOT possess a ‘Has causative agent’ relationship to any descendant of ‘Virus’ or ‘Alcohol’.”

A simplified conceptual Cypher query:

// Find all concepts descending from 'Liver Injury'
MATCH (injury:Concept)-[:IS_A*]->(:Concept {name: 'Liver Injury'})
// Ensure that the injury concept does not have a causative agent
// that descends from 'Virus' or 'Alcohol'
WHERE NOT EXISTS {
    MATCH (injury)-[:HAS_CAUSATIVE_AGENT]->(cause)
    WHERE (cause)-[:IS_A*]->(:Concept {name: 'Virus'})
       OR (cause)-[:IS_A*]->(:Concept {name: 'Alcohol'})
}
RETURN injury.concept_id

This approach is declarative, robust to vocabulary updates, and directly reflects the clinical intent. While concept_ancestor facilitates efficient hierarchical queries using SQL by pre-calculating the transitive closure of the ‘Is a’ relationships, it cannot support the lateral, axiomatic filtering required here.

Specifically, the concept_ancestor table cannot execute the following logic:

// === AXIOMATIC (Lateral) Filtering - Exclusion Criteria ===
// Filter the candidate set by excluding specific etiologies. This is where
// we overcome the SQL Expressivity Gap by utilizing asserted axioms.
WHERE NOT EXISTS {
    // Step 2a: LATERAL Traversal
    // We traverse from the condition (injury) to its asserted cause using the
    // 'HAS_CAUSATIVE_AGENT' relationship. This is the critical lateral link
    // (stored in concept_relationship) that is generally inaccessible in standard
    // ATLAS/Circe concept set definitions.
    MATCH (injury)-[:HAS_CAUSATIVE_AGENT]->(cause)

    // Step 2b: HIERARCHICAL Traversal on the Cause
    // Verify if that identified 'cause' is a descendant of 'Virus' OR 'Alcohol'.
    WHERE (cause)-[:IS_A*]->(:Concept {name: 'Virus'})
       OR (cause)-[:IS_A*]->(:Concept {name: 'Alcohol'})
}


Integrating Graph Queries within the CIRCE Model