Demos
LLMs write fluent clinical text but don’t reliably normalize or verify it. See the evidence for why knowledge graphs remain essential to clinical AI.
Terminology models return the same code for the same term every time; general-purpose LLMs don’t. Grounding LLM output in normalized, verified relationships is what makes clinical AI reasoning consistent and traceable.
An estimated 80% of clinical data lives in unstructured text, discharge summaries, consult notes, pathology and radiology reports, invisible to the analytics systems, quality programs, and research platforms that depend on structured, computable data (John Snow Labs, 2026). Large language models can read that text and generate plausible reasoning from a single prompt, but a terminology-resolution model returns the same code for the same term every time, while a general-purpose LLM is non-deterministic by design (Kocaman, 2025). Structured knowledge is not being replaced. It is doing work an LLM alone cannot.
This is a case for why that structured layer gets more important as LLMs improve, not a build guide. John Snow Labs’ Terminology Server is what makes that structured layer production-ready today: more than 350,000 SNOMED CT concepts and 95,000-plus LOINC observations resolved with sub-second, repeatable responses (John Snow Labs, 2026). For the step-by-step implementation, extracting entities, running relation extraction, and constructing the graph in Neo4j, see building a clinical knowledge graph from clinical text with Healthcare NLP.
Why can’t an LLM alone provide reliable clinical knowledge?
A clinical knowledge graph is a network of entities, diseases, drugs, procedures, genes, lab findings, and the explicit relationships between them. A relationship in a knowledge graph is asserted, not inferred: drug A is contraindicated for condition B, procedure C is indicated for patients with risk factors D and E. Every edge traces to a source and applies consistently no matter how a query is phrased.
A knowledge graph asserts relationships explicitly, including which combinations are contraindicated, rather than inferring them fresh on every query.
An LLM works differently. It generates text by predicting the next token from patterns in its training data, which produces strong results for common clinical scenarios with abundant examples. On rare interactions, edge cases, and multi-parameter clinical measurements, that same statistical process produces plausible-sounding output without a reliable way to flag when it is wrong. This is exactly where the gap between GPT-4o and an open-source LLM widened in a 2025 evaluation of large language models mapping medical terms to ontology concepts: GPT-4o reached 93.75% precision, while Llama 3.3 70B managed only 19.19% on the same task, with both models weakest on complex, multi-parameter measurements (Mavridis et al., 2025). Model choice on this task is not a rounding error. It determines whether the output is usable at all.
Grounding LLM output in a knowledge graph directly addresses this. A 2025 peer-reviewed study built a query-checking algorithm that validated LLM-generated queries against a biomedical knowledge graph before returning an answer, correcting 172 of 999 initially wrong responses for an average accuracy gain of 14.95 percentage points (Pusch and Conrad, 2025). The improvement came entirely from checking generated answers against explicit, structured relationships rather than trusting the model’s first output.
Why does normalization determine whether AI reasoning is reliable?
Before any model can reason across a patient’s history, the data in that history has to refer to the same concepts consistently. A record might contain “metformin,” “Glucophage,” and “metformin HCl,” all the same medication, or “type 2 diabetes,” “T2DM,” and “non-insulin-dependent diabetes mellitus,” all the same condition documented differently across encounters. Without normalization to a standard terminology, RxNorm for medications, ICD-10 for diagnoses, SNOMED CT for clinical concepts, LOINC for lab observations, an LLM reasoning over that record is working with inconsistently labeled input.
Metformin, Glucophage, and metformin HCl all resolve to one RxNorm code – normalization is what lets a system recognize they’re the same medication every time.
This problem scales with the size and heterogeneity of the data set. A single-site deployment with consistent documentation has a manageable normalization task. A multi-site health system with legacy EHR platforms and decades of historical records does not, and prompting an LLM harder does not close that gap. The RxNorm comparison cited above tested exactly this: 79 annotated clinical documents mapped against ground truth, with Healthcare NLP’s resolver reaching 82.7% top-3 accuracy against Amazon Comprehend Medical’s 55.8% and GPT-4’s 8.9%, the last of which could only return a single candidate code per term (Santas, 2024). Healthcare NLP’s normalization models map clinical entities to ICD-10, SNOMED CT, LOINC, and RxNorm as a systematic pipeline step, which is what makes an entity usable for knowledge graph-backed reasoning in the first place. That determinism advantage compounds at production scale: the Terminology Server resolves against more than 350,000 SNOMED CT concepts and 95,000-plus LOINC observations with sub-second, repeatable responses, the same term returning the same code on every call (John Snow Labs, 2026).
How do physician notes become a queryable knowledge graph?
Normalized entities are the input. Relationships are what make the graph useful. Which drug was prescribed for which condition, which symptom preceded which diagnosis, how a patient’s lab values trended across a treatment course: most of this lives in unstructured text, not in structured EHR fields. Extracting it systematically, at scale, is what separates a knowledge graph that represents a patient’s actual clinical history from one that only reflects what happened to be captured in a dropdown menu.
MiBA’s production pipeline turned 1.4 million physician notes into 29.2 million relationships – one extraction, reused across trial matching, adverse event detection, and outcome analysis.
MiBA’s oncology data pipeline shows what that extraction looks like in production. Processing 1.4 million physician notes and roughly 1 million PDF reports and scans, the pipeline extracted 113.6 million entities and 29.2 million relationships across 25 distinct relationship types, reaching a combined 93% F1 score for entity extraction and 88% F1 for relationship extraction (Bonis, 2026). Those relationships, linking clinical entities across time, anatomy, and cause, are what powered oncology patient matching against clinical trial criteria, which required knowing not just that a patient had a diagnosis, but how that diagnosis related to treatments received and disease progression over time. An LLM reading raw notes at query time could not reconstruct that relational structure reliably at this scale; a knowledge graph built once from systematic relation extraction can be queried against repeatedly.
Where do knowledge graphs and LLMs work together in production?
Guideline alignment, matching an individual patient’s profile against clinical guideline criteria, is where the combination pays off most directly, and it needs both layers: a structured representation of what a guideline says, and language understanding flexible enough to interpret how a specific patient’s record says it.
Roche’s Navify Oncology Clinical Hub illustrates one version of this. Patient data extracted from clinical notes is mapped to structured models that index National Comprehensive Cancer Network guideline content, and the platform’s Smart Navigation feature aligns a given patient’s data with the most relevant NCCN guideline section automatically (Bonis, 2025). Guideline Central, working with John Snow Labs’ Medical LLMs, takes a related approach: the platform maps an unstructured patient case summary to the correct guideline and the specific relevant section, drawing on content from roughly 50 medical societies and government agencies, and explains its recommendation with a direct link to the guideline text it used (Devine, 2025). Both systems make the basis for a recommendation reviewable, because the reasoning is grounded in explicit guideline content rather than emerging from an opaque generation step.
Two production systems reach the same architecture independently: ground the match in structured guideline content, and the recommendation stays traceable to its source.
That auditability is not a nice-to-have. As the EU AI Act’s high-risk classification applies to most clinical AI tools, providers face a direct obligation to generate clear, meaningful explanations of automated decisions and to log updates, retraining, and modifications for audit review (Dennstädt et al., 2026). A recommendation traceable to a specific guideline section or a specific coded relationship satisfies that requirement in a way a paragraph of LLM-generated justification, however coherent, does not.
What should health systems build first?
The architectural implication is straightforward: treat normalization as a foundational pipeline step, not something bolted on after extraction. Every entity pulled from clinical text should be resolved to a standard concept identifier as part of extraction, because that resolution is what makes the entity usable for knowledge graph-backed reasoning and cross-patient analytics later.
Treat relation extraction as shared infrastructure, too. MiBA’s 29.2 million relationships were not built for one application; they support trial matching, adverse event detection, and longitudinal outcome analysis from the same underlying asset (Bonis, 2026). Building it once and reusing it across projects compounds in value the way any shared data asset does. And design LLM workflows with graph grounding in mind from the start, so outputs can be checked against verified relationships instead of trusted on the first pass. For a closer look at where the two layers meet, see why the future of clinical AI is hybrid.
Structured knowledge is the layer that makes clinical AI accountable: verified relationships, consistent normalization, and reasoning a clinical reviewer or compliance team can actually trace. LLMs are the layer that makes it usable: flexible language understanding across the diversity of how clinicians actually write. Health systems building clinical AI infrastructure now get more durable results treating both as required, not optional. For teams evaluating this architecture for their own environment, request a technical walkthrough of Healthcare NLP and the Terminology Server scoped to your note volume and terminology coverage.
Frequently asked questions
What is a clinical knowledge graph? A clinical knowledge graph is a structured network of medical entities, diseases, drugs, procedures, genes, and lab findings, connected by explicit, sourced relationships such as “drug A is contraindicated for condition B.” Unlike a relational database with a fixed schema, a knowledge graph represents relationships themselves as first-class, queryable data, which is what lets reasoning over it stay consistent and traceable regardless of how a question is phrased.
Why do LLMs need structured knowledge grounding for clinical use? LLMs generate output by predicting text patterns from training data, which works well for common scenarios and degrades on rare conditions, edge cases, and multi-parameter measurements without a reliable signal of when it has gone wrong. In one ontology-mapping evaluation, that gap ran from 93.75% precision for GPT-4o down to 19.19% for an open-source alternative on the same task (Mavridis et al., 2025). Grounding generated answers in a knowledge graph gives a mechanism for checking them before they reach a clinician.
How does normalization support knowledge graph-backed reasoning? Normalization maps different names for the same clinical concept, different drug brand names, different diagnosis phrasings, to a single standard code in RxNorm, ICD-10, SNOMED CT, or LOINC. Without it, a knowledge graph cannot recognize that two expressions in a patient’s record refer to the same entity, and reasoning over the record produces inconsistent results. In a head-to-head RxNorm mapping test, a purpose-built resolver reached 82.7% top-3 accuracy against 55.8% for Amazon Comprehend Medical and 8.9% for GPT-4 (Santas, 2024).
What does relation extraction contribute to a clinical knowledge graph? Relation extraction identifies clinical relationships embedded in unstructured text, which drug treated which condition, which finding preceded which diagnosis, that structured EHR fields typically do not capture. MiBA’s pipeline extracted 29.2 million relationships across 25 types from 1.4 million physician notes at an 88% F1 score, enabling oncology trial matching that required relational context unavailable from structured fields alone (Bonis, 2026).
How are health systems combining knowledge graphs and LLMs in production today? Roche’s Navify Oncology Clinical Hub maps extracted patient data to structured NCCN guideline content and surfaces the most relevant guideline section automatically (Bonis, 2025). Guideline Central, working with John Snow Labs’ Medical LLMs, matches unstructured patient case summaries to specific guideline sections across roughly 50 medical societies and links directly to the source text for review (Devine, 2025).
Why does explainability matter for regulatory compliance in clinical AI? Under the EU AI Act, most clinical AI tools fall into the high-risk category, which obligates providers to give clear, meaningful explanations of automated outputs and to log updates and modifications for audit review (Dennstädt et al., 2026). A recommendation traced to a specific coded relationship or guideline section satisfies that obligation directly; a fluent LLM-generated justification without a traceable source does not.
Does using a knowledge graph slow down an LLM-based clinical AI system? Checking generated output against a knowledge graph adds one validation step on top of the existing model. In practice it improves reliability without a separate slower pipeline: the query-checking approach that corrected 172 of 999 wrong answers in one study ran as a lightweight verification layer over existing LLM output (Pusch and Conrad, 2025).
