Chapter 13: Knowledge Graphs & Clinical Reasoning

Teaching Computers What Doctors Already Know

Medicine is a graph problem. Not in the "everything is a graph if you squint hard enough" sense that graph database vendors love to pitch, but in a genuinely structural way. A drug treats a disease. That disease has symptoms. Those symptoms overlap with other diseases. The drug interacts with other drugs. Those other drugs are prescribed for conditions that share genetic risk factors with the original disease. And the physician navigating all of this holds a mental model of these relationships that took a decade of training to build.

Here's what fascinates me about this: we've spent billions digitizing healthcare data into rows and columns (EHRs, claims databases, registries) and then we ask questions that fundamentally require understanding relationships between things. "What are the therapeutic alternatives for this patient given their other medications and allergies?" That's not a table lookup. That's a graph traversal. And we've been forcing relational databases to answer graph questions for decades, usually with seven-way JOINs that make your DBA cry.

Knowledge graphs give us a way to represent medical knowledge the way it actually works: as a web of typed relationships between concepts. A drug treats a condition. A condition manifests-as a symptom. A gene encodes a protein that is-target-of a drug. These aren't just labels on foreign keys. They're semantically meaningful connections that enable reasoning you simply cannot do with flat tables.

What Knowledge Graphs Actually Are

Let me be precise here, because "knowledge graph" has become one of those terms that means whatever the vendor selling it wants it to mean.

A knowledge graph is a structured representation of knowledge as a network of entities (nodes) connected by typed relationships (edges). Each node represents a concept (a drug, a disease, a gene, a procedure) and each edge represents a specific relationship between two concepts ("treats," "causes," "interacts-with," "is-a-subtype-of"). Both nodes and edges can carry properties: a "treats" relationship might have properties like evidence level, effective dosage range, or the clinical trial that established the relationship.

The "knowledge" part distinguishes these from generic graph databases. A social network is a graph, but it's not a knowledge graph. Knowledge graphs specifically encode domain knowledge: facts, relationships, and rules that represent expert understanding of a field. In healthcare, that means encoding the kind of information that lives in a physician's head, in clinical guidelines, in pharmacology textbooks, and in the accumulated evidence of clinical research.

The "graph" part is the data model. Instead of tables with rows and columns, you have nodes and edges. Instead of JOINs, you have traversals. Instead of "find all rows where column X matches value Y," you ask "starting from this node, follow all 'treats' edges, then from those nodes follow all 'interacts-with' edges, and tell me what you find." The query pattern mirrors how clinicians actually think about medical relationships.

Why Healthcare Is Uniquely Suited to Graph Representations

Most industries can benefit from graph databases. Healthcare practically demands them. Here's why:

The Ontology Problem Is Already Solved (Mostly)

Healthcare has spent decades building formal ontologies. These are structured vocabularies with defined hierarchical and associative relationships. The major ones:

SNOMED CT (Systematized Nomenclature of Medicine, Clinical Terms): The most comprehensive clinical terminology, with over 350,000 concepts organized in a polyhierarchy (concepts can have multiple parents). SNOMED CT doesn't just list terms; it defines relationships between them. "Pneumonia" is-a "Lower respiratory tract infection" which is-a "Respiratory disorder." "Amoxicillin" has-mechanism-of-action "Beta-lactam antibacterial." These relationships are machine-readable and designed for exactly the kind of graph-based reasoning we're talking about.

RxNorm: The standard vocabulary for clinical drugs in the US. It normalizes drug names across different naming systems (brand names, generic names, ingredient names) and defines relationships between them. "Lipitor 20mg tablet" has-ingredient "atorvastatin" which is-a "HMG-CoA reductase inhibitor." RxNorm is what makes it possible to ask "what other statins could this patient take?" without manually maintaining equivalence tables.

ICD-10-CM/PCS (International Classification of Diseases): The coding system used for diagnoses and procedures. Its hierarchical structure (chapters, blocks, categories, subcategories) is inherently a tree, and the cross-references between codes form a graph. "E11.65" (Type 2 diabetes with hyperglycemia) has relationships to "E11" (Type 2 diabetes) and to "R73.9" (Hyperglycemia, unspecified) that encode clinical knowledge about disease relationships.

LOINC (Logical Observation Identifiers Names and Codes): The standard for laboratory and clinical observations. It defines what was measured, how it was measured, and what specimen was used. The relationships between LOINC codes encode knowledge about which tests are clinically equivalent, which are panels containing other tests, and which are refinements of broader categories.

CPT (Current Procedural Terminology): Procedure codes with hierarchical relationships that encode what procedures are components of other procedures, what procedures are alternatives to each other, and what procedures are typically performed together.

The point is: healthcare didn't need to invent an ontology to build knowledge graphs. The ontologies already exist, are actively maintained by standards bodies, and are used in production systems worldwide. What's been missing is the infrastructure to reason over these ontologies computationally, at scale, in real time.

Relationships Are the Whole Point

In most domains, relationships between entities are secondary to the entities themselves. In healthcare, the relationships are the knowledge. Knowing that "metformin" exists as a drug is trivial. Knowing that metformin treats type 2 diabetes, is contraindicated in severe renal impairment, interacts with contrast dye, has a mechanism of action involving hepatic glucose production, and is first-line therapy per ADA guidelines: that's the knowledge that matters. And all of it is relational.

Multi-Hop Reasoning Is Clinically Necessary

Clinical decision-making routinely requires following chains of relationships. "This patient is on warfarin. They need an antibiotic for a UTI. Which antibiotics interact with warfarin? Of those that don't, which are appropriate for UTIs? Of those, which are covered by this patient's formulary?" That's a four-hop graph traversal. In a relational database, it's a nightmare of subqueries. In a graph, it's a natural path-finding operation.

Knowledge Evolves Continuously

Medical knowledge isn't static. New drug interactions are discovered. Guidelines get updated. New genetic associations are published. A knowledge graph can incorporate new edges and nodes without restructuring the entire schema. You don't need a database migration to add a new relationship type; you just add edges of a new type. This flexibility is critical in a domain where the knowledge base changes weekly.

The Spectrum of Graph Complexity in Healthcare

Not every knowledge graph use case requires building a comprehensive medical ontology from scratch. The recipes in this chapter are ordered from simple to complex, and the progression is worth understanding:

Simple (Recipes 13.1-13.2): Take an existing structured dataset (a drug formulary, a provider directory) and model it as a graph. The relationships are explicit in the source data. The value comes from enabling graph-style queries (traversals, path-finding, similarity) on data that was previously trapped in flat tables. These are "graph your existing data" patterns.

Medium (Recipes 13.3-13.6): Integrate multiple data sources into a unified graph, often combining standard ontologies (SNOMED, RxNorm, ICD) with institutional data. The relationships come partly from standards and partly from inference or clinical rules. These patterns enable reasoning that crosses traditional data silos: connecting diagnoses to procedures to drugs to guidelines in a single queryable structure.

Complex (Recipes 13.7-13.10): Build and maintain knowledge graphs where the relationships themselves are uncertain, evolving, or distributed across organizations. Evidence-graded relationships from literature. Federated queries across institutional boundaries. Concept normalization across heterogeneous terminologies. These are the patterns where graph technology intersects with NLP, machine learning, and distributed systems.

The Technical Landscape

Graph databases and knowledge graph tooling have matured significantly in the last five years. A few things worth knowing before diving into the recipes:

Property graph vs. RDF: Two competing data models. Property graphs (used by Neo4j, Amazon Neptune in its Gremlin mode, and most modern graph databases) treat nodes and edges as first-class objects that can carry arbitrary key-value properties. RDF (Resource Description Framework) represents everything as subject-predicate-object triples and is the foundation of the Semantic Web standards. Healthcare ontologies like SNOMED CT are natively distributed in RDF. In practice, you'll often need to work with both: RDF for ingesting standard ontologies, property graphs for application-level queries. Neptune supports both, which turns out to be genuinely useful in this domain.

SPARQL vs. Gremlin vs. Cypher: The query languages. SPARQL queries RDF graphs and is the standard for querying ontologies. Gremlin is a traversal-based language for property graphs (think of it as "start here, walk this path, collect what you find"). Cypher (Neo4j's language, also supported by Neptune via openCypher) is a pattern-matching language that reads more like SQL. Each has strengths; the recipes will use whichever is most natural for the specific use case.

Graph embeddings and GNNs: The intersection of knowledge graphs and machine learning. Graph Neural Networks can learn vector representations of nodes based on their neighborhood structure, enabling similarity search, link prediction (predicting missing relationships), and node classification. This is where knowledge graphs stop being just a query tool and become a feature source for ML models.

Ontology alignment and mapping: The unsexy but critical problem of connecting different terminologies. SNOMED CT uses one set of concepts; ICD-10 uses another; your EHR vendor uses a third. Mapping between them is a many-to-many problem with semantic nuances that automated tools handle imperfectly. Recipe 13.8 tackles this head-on.

What You'll Build

This chapter progresses from "put your existing data in a graph and query it better" to "build a reasoning engine over distributed medical knowledge." Here's the arc:

Recipes 13.1-13.2 get you comfortable with graph modeling in healthcare. You'll take familiar data (formularies, provider directories) and see how graph representations enable queries that would be painful or impossible in relational databases.

Recipes 13.3-13.4 introduce standard medical ontologies as graph structures. You'll work with ICD hierarchies and drug interaction databases, learning how to ingest, query, and maintain these knowledge bases.

Recipes 13.5-13.6 apply graph-based reasoning to clinical workflows. Clinical pathways become traversable decision trees. Care gap identification becomes an ontological reasoning problem. This is where graphs start enabling things that weren't practical before.

Recipes 13.7-13.8 tackle the harder problems of uncertain knowledge and cross-terminology mapping. Disease-gene-drug relationships with evidence levels. Concept normalization across SNOMED, ICD, CPT, and LOINC.

Recipes 13.9-13.10 push into the frontier: extracting knowledge from literature and federating queries across organizational boundaries. These are architecturally complex patterns that combine NLP, graph databases, and distributed systems.

The Honest Setup

I'll be upfront about something: knowledge graphs in healthcare have been "about to revolutionize everything" for roughly fifteen years. The technology is genuinely powerful, and the use cases are real, but the gap between a compelling demo and a production system that clinicians actually use is wider than most vendors will admit.

The hard parts aren't the graph database. Neptune, Neo4j, and their peers are mature, performant, and well-documented. The hard parts are:

Data quality and completeness. Your graph is only as good as the data you put in it. If your drug interaction database is missing entries, your system will confidently tell clinicians there's no interaction when there is one. That's worse than not having the system at all.
Maintenance and currency. Medical knowledge changes. Ontologies get updated. New drugs get approved. If your knowledge graph isn't continuously maintained, it becomes a liability. Stale medical knowledge is dangerous medical knowledge.
Clinical workflow integration. A beautiful knowledge graph that nobody queries is an expensive hobby. The value comes from embedding graph-powered insights into the workflows where clinicians make decisions: the EHR, the CPOE system, the care management platform.
Performance at clinical speed. A graph query that takes 30 seconds is useless in a clinical workflow. Multi-hop traversals on large graphs need careful optimization: indexing strategies, query planning, caching, and sometimes pre-computation of common paths.

Every recipe in this chapter addresses these challenges explicitly. We're not building demos; we're building systems that need to work reliably, at speed, with real clinical data, in production.

Let's start with the simplest pattern: taking a drug formulary and making it navigable as a graph.

→ Recipe 13.1 — Drug Formulary Navigation