Vector Search and Knowledge Graphs in Clinical Research: From Patient Matching to Regulatory Retrieval

Introduction

Across more than 530,000 registered studies on ClinicalTrials.gov ^[1] and the sparse enrollment numbers that accompany most of them lies a structural problem the field has been reluctant to name directly: the way clinical research finds patients, literature, and relevant precedent is still largely keyword-driven, siloed, and brittle under the weight of biomedical complexity. Research from the Tufts Center for the Study of Drug Development (Tufts CSDD) consistently finds that approximately 11% of activated investigative sites fail to enroll a single patient in global Phase II and III trials, with a further 37% under-enrolling against their targets ^[2],[9]. This is not primarily a supply problem. It is a matching problem. A patient described in an EHR as "insulin-resistant type 2 diabetic with stage 3 chronic kidney disease" and a trial requiring "T2DM with eGFR 30-59" are, conceptually, the same candidate. Basic keyword search without synonym expansion or ontology support often misses that connection; vector search and knowledge graphs are designed to handle it reliably at scale.

This article examines how these two technologies, applied individually and in combination, are changing the operational logic of clinical research, from patient pre-screening and site selection to regulatory document retrieval and drug repurposing hypothesis generation.

Why Graph Structures Complement Relational Schemas for Biomedical Reasoning

Clinical trial data has a shape that flat relational schemas handle poorly when the goal is inference rather than retrieval. A protocol does not just describe a study; it encodes relationships between a target condition, a mechanism of action, prior evidence, biomarker requirements, and safety exclusions. Those relationships are not flat, they are nested, directional, and semantically weighted. A study drug may inhibit a receptor, which regulates a pathway, which is implicated in three distinct disease phenotypes, which appear under 14 different ICD-10 codes. A well-normalized SQL schema can store all of those facts. What it cannot do efficiently is traverse the relationships between them in a single query, particularly when the traversal needs to respect ontological hierarchies and synonymy across terminologies.

The AACT database, which provides structured access to ClinicalTrials.gov data, represents a serious effort at accessibility, but as Chen et al. (2022) demonstrated in Scientific Reports, a relational schema is poorly suited for inferring knowledge from existing trial data ^[22]. Their Clinical Trials Knowledge Graph (CTKG) reformulated trial data as a graph of medical entities, including studies, drugs, conditions, adverse events, and outcomes, connected by typed edges. In their framework, a node representing a drug is not simply a string; it is a vertex in a network where its relationships to conditions, prior study outcomes, and adverse event profiles are all directly queryable. That structural difference is what enables inference, not just retrieval.

Biomedical knowledge graphs more broadly have become the organizing framework for this kind of reasoning. SNOMED CT, the most widely used clinical terminology system in healthcare, encodes approximately 358,000 clinical concepts in a polyhierarchical structure and is itself a knowledge graph in the formal sense: a collection of triples of the form (head entity, relation, tail entity) ^[3]. The Unified Medical Language System, per the 2026AA release from the National Library of Medicine, contains approximately 3.53 million concepts and 18.06 million unique concept names from 195 source vocabularies, including SNOMED CT, organized under standardized Concept Unique Identifiers that map synonymous terms to the same node ^[4]. Terms like "myocardial infarction," "heart attack," and "MI" resolve to a single CUI, which means a query against a UMLS-backed graph is inherently synonym-aware.

Vector Search: What It Is and Why It Matters for Clinical Data

Vector search, also called semantic or similarity search, works by converting text into dense numerical representations, called embeddings, and retrieving results based on their proximity in a high-dimensional vector space rather than their textual overlap with a query. Two phrases that share no words but encode the same clinical meaning will appear close together in a well-trained embedding space. Two phrases that share the same words but mean different things will appear far apart.

The practical consequence for clinical research is substantial. A 2024 study published in Cureus and indexed on PubMed Central embedded EHR documents into a vector database using OpenAI's ada-002 model and then queried them using trial eligibility criteria ^[5]. Using GPT-4 in combination with this retrieval architecture, the system achieved an accuracy of 0.87, sensitivity of 0.85, and specificity of 0.89 in determining patient eligibility against structured criteria, evaluated on a 40-patient subset of the n2c2 2018 clinical NLP challenge dataset. The same approach using GPT-3.5 Turbo on the larger 202-patient test set achieved 0.81 accuracy. Neither model was given the full EHR; the vector database identified which sections of the record were semantically relevant to each criterion and passed only those sections to the language model for assessment.

This matters operationally because clinical notes are verbose. A single patient's longitudinal EHR may contain hundreds of documents spanning years of care. Passing entire records to a language model is computationally expensive and prone to the well-documented "lost in the middle" problem, where models fail to attend to evidence buried deep in long contexts ^[6]. Chunking records into semantically coherent segments and indexing them in a vector database solves the context problem without discarding relevant evidence.

GraphRAG: When Vector Search Meets Graph Structure

Retrieval-Augmented Generation (RAG) chains a retrieval step to a language model generation step, feeding the model only what is relevant rather than expecting it to generate from memory. Vector-indexed RAG is now reasonably well-established in healthcare; a 2025 PRISMA-guided review in AI synthesized 30 studies on RAG in clinical domains, finding strong evidence for its utility in diagnostic support, EHR summarization, and medical question answering ^[7].

Graph-enhanced RAG, or GraphRAG, extends this by replacing or augmenting the vector index with a knowledge graph. The difference is not merely architectural. A vector store can retrieve the most semantically similar documents to a query. A knowledge graph can traverse relationships, connecting a symptom to its differential diagnoses, those diagnoses to their treatment options, those treatments to the trials studying them, and those trials to their eligibility criteria, all in a single query path that encodes clinical logic rather than just textual similarity.

A November 2025 preprint evaluated this directly. Asgari et al. compared three approaches for guideline-based clinical decision support in chronic kidney disease management: a baseline GPT-4o model, a vector-indexed RAG pipeline, and a GraphRAG pipeline ^[8]. Each system answered nine clinically relevant questions for a synthetic cohort of 70 CKD patients. GraphRAG achieved the highest patient-specificity by leveraging multi-hop relationships across a knowledge graph derived from NICE CKD guidelines. However, it scored lower on clarity, as graph-retrieved guideline excerpts sometimes obscured key recommendations behind long, traversal-heavy outputs. The preprint's conclusions are appropriately cautious: GraphRAG shows particular strengths when patient-specific tailoring requires multi-hop reasoning, but effective deployment will require disciplined content management, transparent validation pipelines, and integration within established clinical governance frameworks ^[8].

Patient Matching: Where the Operational Gains Are Clearest

Patient recruitment failure is the proximate cause of most trial delays. As the Tufts CSDD data cited above indicates, a significant fraction of activated sites never enroll a qualifying patient ^[2], and the problem is compounded by the semantic gap between how patients are documented in EHRs and how eligibility criteria are written in trial protocols. Those two vocabularies rarely align at the surface level, and the mismatch accumulates across thousands of potential candidates.

Vector search addresses this problem by enabling semantic matching between EHR-derived patient profiles and trial eligibility criteria that are written in clinical rather than administrative language. A 2026 Nature Communications paper describing the TrialMatchAI system outlined a modular RAG architecture that parses eligibility criteria, embeds patient data, classifies potential candidates, and re-ranks them for human review ^[10]. Built on fine-tuned open-source LLMs, the system processes demographics, comorbidities, and biomarker data against inclusion and exclusion criteria, with the RAG architecture ensuring that its reasoning is anchored in retrieved trial content rather than model memory. The paper explicitly frames TrialMatchAI as a recommendation system: outputs are ranked candidates for investigator review, not autonomous enrollment decisions.

A separate 2025 survey on LLM-assisted recruitment published on arXiv synthesized the design space more broadly, noting that early approaches represented both trials and patients as feature vectors and that contemporary systems extend this with LLM-based criterion parsing and staged screening pipelines ^[11]. The consistent finding across published studies is that vector-based pre-screening can meaningfully reduce the manual review pool by surfacing candidates most likely to meet inclusion criteria ^[10],[11]. That said, precision about scope matters: these are pre-screening support tools, not clinical decision-making systems. They surface candidate patients for coordinator review; they do not enroll, randomize, or exclude patients without human confirmation. The distinction matters both operationally and regulatorily, because the validation burden and human oversight requirements differ significantly depending on where in the enrollment workflow an AI system operates.

Limitations That Implementation Teams Should Understand

Three constraints deserve explicit acknowledgment. First, embedding models are trained on corpora with known demographic and institutional biases; a model trained primarily on English-language EHR data from large academic medical centers may produce systematically lower similarity scores for clinical concepts documented differently at community sites or in non-English health systems. Second, ontologies like UMLS and SNOMED CT are versioned resources: the relationships encoded in version N may change in version N+1, which requires explicit version control policies and regression testing protocols for any production system. Third, EHR data quality is heterogeneous. Sparsely documented patients may generate misleading eligibility assessments not because the retrieval architecture failed but because the underlying data does not reflect their actual clinical status.

Knowledge graphs add a layer that pure vector approaches cannot: hierarchical reasoning over medical ontologies. A patient coded in an EHR using an ICD-10 code for a disease subtype may be eligible for a trial that specifies the parent condition. A UMLS or SNOMED-backed knowledge graph can traverse that hierarchy in milliseconds; a keyword system or a vector search operating on raw text cannot, unless the ontological relationship was explicitly encoded in the training corpus of the embedding model. This is precisely the gap that Harvard Medical School's ClinVec project addresses. The preprint, by Johnson, Gottlieb, Shaham et al. (Harvard Medical School and Clalit Research Institute, 2024), introduces ClinGraph, a clinical knowledge graph integrating eight EHR-based vocabularies, and derives 153,166 clinical code embeddings from it using a graph transformer ^[12]. The authors demonstrate that injecting these knowledge-grounded embeddings into language models produces measurable improvements in medical question answering across clinical benchmarks, including substantial gains in specialty areas like hematology and ophthalmology where standard code embeddings underperform.

Site Selection: Knowledge Graphs as Feasibility Intelligence

Site selection is where knowledge graphs have the most underexplored potential in clinical operations. The conventional feasibility model asks sites to self-report their patient populations against a protocol's target criteria, which produces estimates that are frequently optimistic and rarely verified against real-world EHR distributions.

A knowledge graph built over site-level data, connecting sites to their documented patient populations, to those populations' condition and comorbidity profiles, to prior trial participation history, and to investigator publication records in the relevant therapeutic area, transforms feasibility from a survey exercise into a queryable inference problem. A sponsor asking "which sites in the Northeast have at least 200 patients with relapsed/refractory DLBCL who have not received CAR-T therapy" is asking a graph traversal question. The answer requires traversing site-to-patient edges, patient-to-diagnosis edges, diagnosis-to-treatment history edges, and treatment-to-exclusion edges in a single query path. A relational schema can store all of this data, but at the semantic depth that complex eligibility logic requires, multi-join traversal across partially overlapping clinical terminologies becomes expensive and increasingly imprecise. Graph databases are purpose-built for exactly this access pattern.

This is the structural logic behind FHIR-connected patient matching platforms, which read EHR data in a standardized format and query it against trial criteria. When such platforms are backed by a knowledge graph that understands the hierarchical relationships between FHIR codes, ICD-10 categories, and trial-specific biomarker definitions, the precision of the match improves substantially relative to systems that operate on code-level exact matching.

Drug Repurposing and Hypothesis Generation

Knowledge graph embeddings have found perhaps their most mature clinical application in drug repurposing, the identification of new therapeutic uses for approved compounds. The DRKG (97,238 entities, 5,874,261 triplets ^[23]) was designed from the outset as a substrate for computational drug repurposing: it integrates data from DrugBank, Hetionet, GNBR, String, IntAct, and DGIdb, and its pretrained TransE embeddings allow a query about a target disease to retrieve ranked drug candidates by scoring the likelihood of a (compound, treats, disease) triple. A 2024 review by Perdomo-Quinteiro and Belmonte-Hernandez in Briefings in Bioinformatics surveying KG methods for drug repurposing covered TransE-based approaches on DRKG among other embedding methods, and noted growing interest in approaches that combine KG embeddings with language models to generate natural-language explanations of predicted drug-disease relationships ^[13].

The regulatory implication is concrete. A sponsor entering a Phase II trial with a repositioned compound needs to justify the mechanistic rationale to regulators. A system that can articulate the specific protein-pathway-disease relationships that support the repurposing hypothesis produces an output that is both scientifically defensible and traceable to primary evidence in a curated biomedical graph. A 2023 study in Scientific Reports applied knowledge graph embeddings to COVID-19 drug repurposing and showed that the KG embedding approach was competitive with experimental evidence in identifying candidates that later received investigational attention ^[14].

At the disease-target level, a 2022 paper in BMC Bioinformatics found that task-driven knowledge graph filtering, selecting only the subgraph edges most predictive for a given repurposing task, improved prioritization accuracy compared to using the full heterogeneous graph ^[15]. This is an important methodological point: the completeness of a biomedical knowledge graph is not always a virtue. Irrelevant edges introduce noise, and precision in edge selection matters for downstream performance.

Regulatory Document Retrieval and Cross-Document Consistency

The application of vector search to regulatory documents has received less attention than its application to patient data, but the operational problem is equally concrete. A regulatory submission package for a complex drug program may include thousands of pages across a protocol, an Investigator's Brochure, a DSUR, a Benefit-Risk Assessment, and a Clinical Study Report. Ensuring terminological consistency across these documents, verifying that defined terms are used uniformly, that dosing language in the protocol matches the IB, and that adverse event terminology aligns with MedDRA throughout, is a task that manual review handles poorly at scale.

Vector search over a regulatory document corpus can surface semantically similar passages across documents and flag those where the wording diverges despite the shared clinical referent. This is a retrieval task, not a generation task, and it maps to the architecture's core strengths: identifying near-duplicates, near-synonyms, and near-contradictions in a large unstructured corpus. A published precedent exists in a related domain: a 2025 study introduced VeriFact (Chung et al., arXiv:2501.16672, subsequently published in NEJM AI), an AI system that decomposes EHR documents into atomic claim propositions, indexes them in a vector database using the BAAI/bge-m3 multilingual embedding model (with both dense semantic and sparse lexical retrieval), and then uses an LLM-as-a-Judge to verify whether each proposition is supported by the patient's underlying medical record ^[16]. VeriFact achieved up to 92.7% agreement with a denoised clinician ground truth, exceeding average clinician fact-checking agreement of 88.5%. The application to regulatory documents is an architectural analogy rather than direct evidence from a regulatory submission context, but the underlying retrieval logic is the same. The same architecture applied to regulatory documents could provide automated consistency checking at a depth that no manual QC workflow can sustain.

Knowledge graphs provide the ontological backbone that makes this consistency checking clinically meaningful rather than merely lexical. A system that knows, via UMLS, that "peripheral neuropathy," "PN," and "sensory neuropathy" are semantically overlapping terms can check whether their usage in a regulatory package is consistent not just within each term but across the cluster of related concepts. This is the difference between spell-checking and semantic quality assurance.

Regulatory and Documentation Considerations

The joint FDA-EMA principles for good AI practice in drug development, published in January 2026 following a bilateral meeting in April 2024 and building on EMA's AI Reflection Paper adopted by CHMP and CVMP in September 2024, explicitly extend to AI-enabled clinical trial design and patient recruitment ^[17]. The principles are principles-based rather than prescriptive, but they establish that AI systems used in evidence generation, including those using knowledge graphs and vector retrieval for patient matching or literature synthesis, must be subject to lifecycle governance and human oversight.

The EMA's 2024 Reflection Paper, referenced in the joint principles, sets explicit requirements across development phases, including that sponsors clearly specify how an AI model will be used, identify potential risks, quantify those risks, and document a plan to evaluate the model under defined conditions ^[18]. For knowledge graph-based patient matching tools, this translates practically into requirements for documented ontology provenance, version control of the underlying knowledge base, and validation studies demonstrating that the retrieval logic performs as intended in the target patient population.

The EU AI Act (Regulation (EU) 2024/1689) adds a compliance dimension that sponsors and vendors should assess carefully before deploying graph-based eligibility matching systems in EU trials. Under Article 6(1) of the Act, an AI system that constitutes or functions as a safety component of a product regulated by EU harmonized product legislation, including the Medical Device Regulation (MDR, 2017/745) and the In Vitro Diagnostic Regulation (IVDR, 2017/746), is classified as high-risk if the underlying product requires a third-party conformity assessment by a Notified Body ^[21]. AI-enabled medical devices and IVDs that require Notified Body conformity assessment under MDR or IVDR would generally satisfy this pathway, depending on their intended use, device class, and whether they are placed on the EU market or put into service within the EU. Standalone clinical trial eligibility matching tools that do not carry a CE mark as medical devices may not automatically fall into the high-risk category under Article 6(1), but under Article 6(4) of the Act, providers who conclude their system falls outside the high-risk classification must still document that assessment before placing the system on the market or putting it into service. Documentation requirements under the Act overlap substantially with ICH E6(R3)'s framework for vendor qualification and oversight, meaning sponsors who already maintain thorough AI vendor due diligence processes under GCP have a viable path to structured compliance with both frameworks.

The Architecture in Practice: What Hybrid Systems Look Like

The most capable systems in production today do not choose between vector search and knowledge graphs; they combine them. A 2026 Frontiers in Digital Health paper by Thio, Lewis, Denaxas, and Dobson (University College London) describing the MediGRAF system embedded free-text clinical documents using OpenAI's text-embedding-3-small model to generate 1,536-dimensional vector representations, stored the resulting embeddings as properties of nodes in a Neo4j graph database, and then executed queries that combined graph traversal with vector similarity search using cosine similarity scoring ^[19]. The graph handled structured relationships between patients, conditions, medications, and encounters; the vector layer handled retrieval from free-text notes where the relevant content was expressed in natural language rather than coded form.

For clinical trial applications, this architecture maps naturally onto the problem: coded EHR data, including ICD-10 codes, LOINC lab values, and RxNorm medication codes, traversed via a knowledge graph; free-text clinical notes and prior study reports retrieved via vector similarity; language model reasoning applied only after the retrieval layer has narrowed the context to what is clinically relevant.

The Data Distillery Knowledge Graph (preprint, Ahooyi et al., 2025; also indexed in PMC), built for the NIH Common Fund Data Ecosystem, applies a version of this logic at the translational research scale. It integrates clinical standards including ICD-10, SNOMED, and DrugBank via UMLS, and links them to genomics data using ontologies including HPO, GENCODE, and ClinVar, supporting informatics queries across use cases including biomarker discovery and regulatory variant analysis ^[20]. The modular architecture allows new datasets and schema extensions to be added without rebuilding the entire graph, which is the property that makes such systems sustainable over the multi-year timelines of clinical development programs.

How Kitsa Fits Into This Problem

Kitsa's KScreener platform uses FHIR-connected workflows to match patients against trial eligibility criteria (kitsa.ai), which positions it directly at the intersection of structured EHR data and trial protocol logic. The move toward knowledge graph-backed matching, where UMLS and SNOMED ontologies inform how patient codes are mapped to protocol-defined eligibility concepts, is the natural next architectural layer for any FHIR-based pre-screening system that needs to handle the semantic complexity of real-world clinical data. KScribe, Kitsa's AI-native regulatory document generation platform (kitsa.ai/regulatory-document-generation), similarly benefits from the vector retrieval architecture described above: cross-document consistency checking and terminology alignment across a regulatory package are retrieval problems that a semantically indexed document corpus handles more reliably than manual review. Both product descriptions are based on Kitsa's published product documentation.

A Concrete Example: Cross-Document Consistency in a Regulatory Package

Consider a sponsor submitting a regulatory package for a Phase III oncology trial. The protocol defines the primary endpoint as "progression-free survival (PFS) as assessed by blinded independent central review (BICR)." The Clinical Study Report describes the same endpoint as "PFS determined by investigator assessment." The Investigator's Brochure references "radiographic PFS." The DSUR interim safety update tables use "rPFS."

Each phrase is intelligible in isolation. Across the four documents, they create a terminological inconsistency that a regulatory reviewer will flag. Manual QC across a submission package of several thousand pages cannot catch every instance of this kind of drift. A vector-indexed retrieval system, built over the full regulatory corpus, can: it surfaces all passages semantically related to the primary endpoint and flags diverging phrasings for medical writing review. A UMLS-backed knowledge graph layer adds a further check, identifying that "progression-free survival" and "rPFS" are semantically equivalent concepts under shared ontological coverage, while "investigator assessment" and "BICR" are definitionally distinct assessment methods, making the inconsistency clinically meaningful rather than merely typographic.

Implementation Guidance: A Validation Checklist for Sponsors and CROs

Before deploying any vector search or knowledge graph system in a GCP-regulated context, teams should work through the following before go-live:

Key Takeaways

• •Relational schemas are well-suited for tabular clinical data storage, but graph databases are purpose-built for traversing multi-hop relationships across typed edges, which is the access pattern that complex clinical trial eligibility logic requires.
• •Tufts CSDD research consistently finds that approximately 11% of activated investigative sites fail to enroll a single patient in global Phase II and III trials, with 37% under-enrolling; the underlying cause is frequently a matching problem, not a patient supply problem.
• •Vector search enables semantic matching between EHR-derived patient data and trial eligibility criteria expressed in clinical natural language, achieving accuracy rates above 0.87 in published patient screening studies when combined with language models. These systems function as pre-screening support tools; they surface candidates for human coordinator review and do not make enrollment decisions autonomously.
• •GraphRAG, which combines knowledge graph traversal with vector retrieval, outperforms vector-only RAG on patient-specificity for multi-step clinical reasoning tasks, as demonstrated in the Asgari et al. 2025 preprint on CKD guideline adherence. The same study found GraphRAG scored lower on clarity, as graph traversal can return lengthy guideline excerpts that obscure key recommendations; this trade-off has direct implications for deployment design.
• •The Drug Repurposing Knowledge Graph (DRKG), per its primary documentation by Ioannidis et al. (2020), encodes 97,238 biomedical entities across 13 entity types and 5,874,261 triplets across 107 relationship types ^[23]; knowledge graph embedding-based systems can use this resource to generate explainable drug-disease predictions with traceable reasoning paths that support regulatory justification.
• •The UMLS 2026AA release from the National Library of Medicine contains approximately 3.53 million concepts from 195 source vocabularies; SNOMED CT provides approximately 358,000 formally structured clinical concepts. Both are versioned resources requiring explicit version control policies in any production clinical system.
• •The EU AI Act's high-risk classification pathway most directly applicable to clinical AI tools is Article 6(1), which covers AI embedded in or constituting medical devices subject to MDR/IVDR Notified Body review. Standalone trial eligibility pre-screening tools may not automatically qualify as high-risk, but under Article 6(4) providers must document their non-high-risk assessment before placing the system on the market or putting it into service.

FAQ

References

Related Articles

Suggested internal links: KScribe: AI Regulatory Document Generation | FHIR and LLMs in Patient Recruitment for Clinical Trials | Fine-Tuned Clinical LLMs vs. General-Purpose Models | Agentic AI in Clinical Protocol Development | AI Governance Frameworks for Clinical Trial Sponsors (FDA, EMA, ICH)