CLINICAL TRIAL RECRUITMENT
80% of clinical trials miss enrollment timelines. The bottleneck is not patient supply. It is matching precision. Generic AI reads words. Ontology-driven systems reason about medical concepts, parse exception clauses, and produce audit trails that hold up to regulatory scrutiny.
$800K/day
Lost sales per day of trial delay
Tufts CSDD, 2024
80%
Of trials fail enrollment timelines
Industry consensus, 2025
$1,200
Average cost per screen failure
Antidote.me, 2025
We build custom matching systems that reason about eligibility using SNOMED-CT ontology graphs and deterministic logic. For pharma sponsors, CROs, and academic medical centers running complex trials where screen failure rates and enrollment delays are measured in millions.
The industry spent the last five years replacing keyword search with LLMs. That fixed the easy cases. It did not fix the cases that actually matter.
A Phase III anticoagulant trial excludes patients who have had "cardiac catheterization." A patient's EHR contains a note describing a "central venous catheter placement" performed in the ICU for IV medication access.
What generic AI does:
Sees "catheter" + "venous" + proximity to cardiovascular terms. Vector similarity score is high. Patient flagged as ineligible. An eligible patient is lost.
What ontology-driven matching does:
Maps both to SNOMED-CT concept IDs. Cardiac catheterization (SCTID: 41976001) is under "Procedure on heart." Central venous catheterization (SCTID: 392230005) is under "Catheterization of vein." Different branches. Patient is eligible.
This is not an edge case. It represents an entire class of errors where procedures, conditions, or medications share vocabulary but differ medically. Published evaluations confirm AI models make this exact "cardiac catheterization equals central venous puncture" error (Fierce Biotech, 2025). Multiply by hundreds of criteria across dozens of trials, and you have a systematic eligibility leak that no amount of prompt engineering fixes.
Ontological Blindness
LLMs process text by token proximity, not medical hierarchy. "Coronary angiography" and "peripheral angiography" score similarly because they share the word "angiography." SNOMED-CT knows one is a cardiac procedure and the other is a vascular access procedure.
Exception Clause Fragility
"Exclude patients with hypertension unless well-controlled on stable medication for 3+ months." LLMs see "hypertension" and either exclude (losing an eligible patient) or include (missing the temporal check). Protocols now average 27+ criteria, many with nested conditionals (IQVIA, 2026).
Non-Deterministic Output
Run the same patient through an LLM-based matcher twice with slightly different context windows. You may get different results. Clinical trials require 100% reproducible audit trails. Regulators need to know exactly why each patient was included or excluded.
Pull this up in your next vendor evaluation meeting. Every platform has strengths. The question is which gaps matter for your protocol complexity.
| Platform | What They Actually Do | Data Access | Where It Breaks Down |
|---|---|---|---|
| Tempus (incl. Deep 6 AI) | LLM-based Patient Query agent reads unstructured notes, scores against criteria. 94% accuracy on evaluated queries. 750+ provider sites post-Deep 6 acquisition. | Proprietary genomic + clinical data. Tempus network sites. | Probabilistic matching without ontological grounding. Limited to Tempus network for data access. No formal reasoning trace for regulatory audit. |
| IQVIA (IQVIA.ai) | Unified agentic AI platform (March 2026) with NVIDIA. Largest healthcare datasets globally. End-to-end from feasibility to enrollment. | 250M+ patient records. Pharma relationships spanning decades. | Broad but generic matching. Platform-first approach may not handle your specific protocol nuances. Heavy integration requirements for custom workflows. |
| Medidata (Dassault) | AI Study Build for Rave EDC. CTMS leader. 500+ AI-supported studies. Strong EDC-to-matching pipeline. | Trial data from Rave platform. Limited direct EHR access. | Matching is a feature within a larger CTMS, not the core focus. Rave API limitations push most teams to batch ETL rather than real-time matching. |
| TriNetX | Real-world data network for feasibility and cohort identification. 250M+ patient records across health systems. | Federated network model. Structured data focus. | Strong for feasibility, weaker on unstructured note parsing. Network membership required for data access. |
| ConcertAI (ACT) | Agentic AI platform launched Feb 2026. Claims 10-20 month timeline reduction. Oncology-focused real-world data. | Proprietary oncology datasets. Roche-adjacent ecosystem. | New platform, limited production track record. Oncology-centric; less depth in other therapeutic areas. |
| Big 4 / Large SIs | Implement and integrate platforms. Configure Medidata, Veeva, Oracle Clinical One. Project management and change management. | Client data via engagement. | They implement platforms, not build intelligence. No ontology engineering or custom matching capability. Engagements run $500K-$5M+ with 6-12 month timelines for integration alone. |
| Internal Build | Clinical informatics team builds matching rules or fine-tunes models against specific protocols. | Full EHR access. No data-sharing concerns. | Clinical informaticists are scarce and expensive. Ontology maintenance (SNOMED updates biannually, MedDRA quarterly) requires dedicated headcount. Most internal builds plateau at keyword matching with some NLP. |
Every platform above uses some form of NLP or LLM matching. None publicly implement neuro-symbolic reasoning with SNOMED-CT ontology graphs for deterministic eligibility evaluation. That gap is where clinical precision lives.
Each capability addresses a specific failure mode in current matching systems. These are not product features. They are custom-built components tailored to your protocol portfolio, EHR environment, and regulatory requirements.
We build matching systems where the eligibility decision is computed, not predicted. The LLM extraction layer converts clinical notes into SNOMED-CT concept IDs using constrained decoding that forces SCTID output. The knowledge graph (Neo4j) stores 350,000+ medical concepts with their hierarchical relationships. The symbolic reasoner evaluates eligibility by traversing the graph: Is the patient's procedure a subtype of the excluded procedure? The answer is deterministic.
We reach for SAKT-style constrained decoding when clinical notes are messy (ICU notes, handwritten transcriptions) because forcing the model to output valid SCTIDs at generation time catches hallucinated medical entities before they enter the reasoning pipeline. For well-structured EHR data (FHIR resources with coded fields), we bypass the LLM entirely and map directly to the ontology.
Trial protocols are not boolean checklists. They are normative statements with obligations, permissions, and prohibitions that interact through exception clauses and temporal constraints. We parse protocols into formal deontic logic, decomposing "exclude X unless Y within Z timeframe" into computable operations.
The parser handles temporal ensemble logic for duration calculations ("no PCI within 12 months"), medication interaction chains via CYP enzyme pathway traversal in the knowledge graph ("any drug interacting with CYP3A4"), and nested conditional logic that standard NLP pipelines flatten into wrong answers. Each parsed criterion produces a formal logic specification that the reasoner executes against patient phenotypes.
Patient data stays within your firewall. The neural extraction layer runs as a locally deployed clinical language model (fine-tuned on your institution's note patterns). The knowledge graph and symbolic reasoner run on-premise. FHIR R4 input adapters connect to Epic (via App Orchard endpoints), Oracle Health (Millennium FHIR APIs), or other certified EHR systems.
We architect for HIPAA BAA compliance from day one: audit logging on every patient data access, minimum necessary access controls, role-based permissions aligned with your IRB protocols, and de-identification capabilities for any aggregate data that needs to move between systems. Protected health information never touches an external API.
Matching output that lives in a separate system is matching output that gets ignored. We build connectors that push ranked patient-trial matches directly into Medidata Rave, Veeva Vault CTMS, or Oracle Clinical One. Site coordinators see results in the tools they already use, not in another dashboard to check.
Output maps to CDISC SDTM IE (Inclusion/Exclusion) domain format, so recruitment data is structured for regulatory submission from day one. No downstream data cleaning or reconciliation required. The pipeline also handles local lab code normalization (LOINC mapping) to reconcile site-specific reference ranges against protocol-defined thresholds.
SNOMED-CT provides the foundation. We build the therapeutic depth on top. For oncology: PD-L1 expression levels mapped to specific assay thresholds (22C3 vs SP263 vs SP142), BRCA1/2 variant classifications (pathogenic vs VUS vs benign per ACMG guidelines), EGFR mutation subtypes (exon 19 deletion vs L858R vs T790M), ALK rearrangement status, TNM staging with AJCC 8th edition mapping, and prior regimen histories with line-of-therapy attribution.
Each ontology is validated against 10-15 real protocols from your trial portfolio before going live. Validation means running the system against completed trials where enrollment outcomes are known and measuring concordance with the human gold standard. We maintain ontologies as SNOMED-CT updates biannually and MedDRA updates quarterly, so concept mappings stay current.
Walk through a single patient evaluation for a Phase III oncology trial. This is the process that runs for every patient-criterion pair.
The locally deployed clinical LLM reads the patient's unstructured notes. A physician wrote: "Pt completed 4 cycles carboplatin/pemetrexed, last infusion 03/2025. PD-L1 TPS 45% (22C3). ECOG 1." The model extracts entities using constrained decoding that forces valid SNOMED-CT and LOINC outputs: MedicationAdministration: carboplatin (SCTID: 386905003), pemetrexed (SCTID: 409342003). Finding: PD-L1 45% (LOINC: 85146-3). Finding: ECOG PS 1.
Extracted entities are mapped to the knowledge graph. "Carboplatin" resolves to the platinum-based antineoplastic agent branch. The graph knows carboplatin is-a alkylating agent, is-a platinum compound, interacts-with CYP2C8. If the protocol excludes "prior platinum therapy," the graph traversal confirms carboplatin qualifies. If it excludes "prior immunotherapy," the graph confirms carboplatin does not. No ambiguity.
Protocol criterion: "No prior systemic therapy for advanced disease, unless adjuvant/neoadjuvant therapy completed > 12 months before randomization." The parser decomposes: Prohibition(prior systemic therapy) EXCEPT Permission(adjuvant OR neoadjuvant) AND Temporal(completion_date + 12 months < randomization_date). The reasoner checks: carboplatin/pemetrexed was administered. Was it adjuvant? The graph checks the disease stage at time of treatment. Was the interval sufficient? Last infusion March 2025, randomization April 2026 = 13 months. Result: ELIGIBLE (exception clause satisfied, temporal constraint met).
The system outputs a composite score. Deterministic criteria (ontological matches, temporal calculations) get binary confidence. Ambiguous criteria (unclear note phrasing, missing data) get a probability score with the specific ambiguity flagged. The reasoning trace for each criterion is stored: which SCTID was matched, which graph traversal was performed, which logic operation produced the result. This trace goes directly into CDISC SDTM IE domain format and into the coordinator's CTMS view.
Key distinction from platform AI:
At no point does the system ask an LLM "is this patient eligible?" The LLM reads text. The ontology resolves meaning. The logic engine computes eligibility. Each layer has a defined job and a verifiable output. When a coordinator sees "eligible" or "excluded," they can trace exactly why, down to the SNOMED concept ID and graph relationship that determined the outcome.
Three phases, 14-20 weeks total. Each phase has a defined deliverable and a decision point before proceeding.
Phase 1: Weeks 1-4
Decision point: proceed to build, adjust scope, or determine a platform is the better fit. We will tell you if it is.
Phase 2: Weeks 5-16
Phase 3: Weeks 17-20
Ongoing: SNOMED-CT updates biannually, MedDRA quarterly. We maintain or hand off with documentation.
Answer six questions about your current recruitment operations. The assessment identifies where your matching pipeline is leaking eligible patients and which improvements would have the highest ROI for your specific situation.
1. What is your current screen failure rate across active trials?
Tempus Patient Query and IQVIA's matching tools use large language models to read clinical notes and score relevance against trial criteria. This works well for straightforward criteria but breaks down on ontological distinctions. When a protocol excludes "cardiac catheterization" and a patient record mentions "central venous catheter placement," an LLM operating on vector similarity sees two catheter procedures involving the cardiovascular system and flags a match. A SNOMED-CT-grounded system recognizes these sit on entirely different branches of the procedure hierarchy (SCTID 41976001 vs. 392230005) and correctly rules the patient eligible.
The practical difference shows up in screen failure rates. LLM-based matching typically achieves 85-94% accuracy on well-structured criteria, but drops to 70-80% on protocols with complex ontological distinctions, temporal logic, or exception clauses. Ontology-driven matching maintains 95%+ accuracy across all criterion types because the eligibility decision is computed by a symbolic reasoner, not predicted by a language model.
The other structural difference is auditability. An LLM produces a relevance score. Our system produces a reasoning trace: patient has SCTID X, criterion requires not-SCTID Y, X is-not-a-subtype-of Y per SNOMED hierarchy, therefore eligible. That trace is what regulatory affairs teams need for FDA submission documentation.
Yes, and this is a core architectural principle, not an afterthought. The neuro-symbolic architecture separates the neural layer (LLM for entity extraction) from the symbolic layer (knowledge graph and logic solver). Both can run entirely within your firewall.
The LLM extraction layer deploys as a local model, typically a fine-tuned clinical language model running on your infrastructure or a secure private cloud instance. It never sends raw patient text to external APIs. The knowledge graph (Neo4j or equivalent) and SNOMED-CT ontology sit on-premise. FHIR R4 is the input standard. For Epic environments, we build against the FHIR R4 endpoints available through App Orchard, pulling Patient, Condition, Procedure, and MedicationAdministration resources. For Oracle Health (Cerner), the integration uses their Millennium FHIR APIs.
The extraction layer processes clinical notes locally, maps entities to SCTIDs, and the symbolic reasoner evaluates eligibility against protocol criteria. Protected health information never leaves your secure environment. We architect for HIPAA BAA compliance from day one, including audit logging, minimum necessary access controls, and de-identification capabilities for any data that does need to move between systems.
The architecture works for any therapeutic area because SNOMED-CT covers 350,000+ medical concepts. The variable is ontology depth, meaning how many domain-specific mappings, synonyms, and hierarchical relationships are pre-configured for your specific protocols.
Oncology is where we start most engagements because the criteria are the most complex: biomarker requirements (PD-L1 expression levels, BRCA1/2 mutation status, EGFR variants), staging systems (TNM, AJCC 8th edition), prior regimen histories with temporal constraints, and performance status scores. A production-ready oncology ontology covering the top 50 biomarkers, 200+ treatment regimens, and standard staging systems takes 6-8 weeks to build and validate.
Cardiovascular and CNS are the next most common. Cardiovascular ontology focuses on procedure hierarchies (the cardiac catheterization distinction is just one of dozens), medication interaction chains via CYP enzyme pathways, and lab value ranges with site-specific reference adjustments. CNS adds subjective endpoint handling and cognitive assessment score mapping.
Rare disease is technically the most challenging because SNOMED coverage can be thin for ultra-rare conditions. We supplement with Orphanet ontology mappings and build custom concept extensions that feed back into the graph. Setup for a rare disease therapeutic area runs 8-12 weeks. Each ontology is validated against real protocol criteria from your trial portfolio before going live.
This is where deterministic logic outperforms probabilistic language models most clearly. Standard NLP treats eligibility criteria as text to be interpreted. We treat them as formal logic to be computed.
Take a real criterion: "Exclude patients with hypertension, unless well-controlled on stable medication for at least 3 months." An LLM sees the word "hypertension" and must decide from context whether to exclude. It gets this right most of the time, but "most of the time" means losing eligible patients on every trial.
Our parser decomposes this into deontic operators. Prohibition: hypertension present. Permission condition: hypertension AND controlled (BP below 140/90 per protocol definition) AND stable medication (same antihypertensive regimen) AND temporal constraint (3+ months duration). The system then queries the patient's medication history from the knowledge graph, identifies the antihypertensive, checks the prescription start date, calculates the duration delta against the screening date, and verifies blood pressure readings within the observation window. Each step produces a verifiable output.
The same logic handles chains like "no prior chemotherapy unless neoadjuvant therapy completed more than 6 months ago" by checking the therapy intent attribute (neoadjuvant vs. adjuvant vs. palliative), the end date, and the temporal delta. These are not edge cases. IQVIA data shows protocols now average 27+ eligibility criteria, many with nested conditionals. A single mishandled exception clause per protocol, across hundreds of patients screened, compounds into dozens of lost enrollments.
A typical engagement runs three phases over 14-20 weeks. Phase 1 (3-4 weeks) is a recruitment operations audit: we analyze your current screen failure rates, map your EHR data landscape, review 10-15 representative protocols from your trial portfolio, and identify the specific criterion types causing the most false positives and missed matches. This phase delivers a technical architecture document and an ROI model based on your actual data.
Phase 2 (8-12 weeks) is the build: ontology development for your priority therapeutic area, LLM fine-tuning on your clinical note patterns, knowledge graph construction, symbolic reasoner configuration, and FHIR integration with your EHR environment. Phase 3 (3-4 weeks) is validation: retrospective testing against completed trials where enrollment outcomes are known, accuracy benchmarking, and coordinator workflow integration.
Cost depends on scope. A single-therapeutic-area build with one EHR integration typically runs $180K-$350K. Multi-therapeutic or multi-site deployments scale with ontology breadth and integration complexity. For comparison, Tempus and IQVIA platform licenses run $200K-$500K+ annually with per-patient or per-trial fees on top.
The fundamental economic difference is ownership. A platform license is recurring spend with vendor lock-in. A custom build is an asset you own, maintain, and extend. For organizations running 20+ trials annually, the custom build typically breaks even against platform licensing within 18 months, with the additional advantage of matching accuracy tuned to your specific protocol complexity.
The FDA's January 2026 updated Clinical Decision Support guidance is the relevant framework here. The key question is whether the system makes autonomous clinical decisions or supports human decision-making.
Our architecture is designed for the CDS exemption under 21st Century Cures Act Section 3060. The system meets all four exemption criteria: it is not intended to acquire, process, or analyze medical images or signals; it displays the basis for recommendations (the full reasoning trace); it is intended for healthcare professionals with independent review capability; and it does not replace clinical judgment in making eligibility determinations.
In practice, this means the system outputs ranked patient-trial matches with confidence scores and reasoning traces. A site coordinator or clinical research associate reviews each match before any patient contact. The system never auto-enrolls.
That said, FDA's interpretation of CDS scope continues to shift. If your organization plans to use matching output to automatically exclude patients without human review, the system may cross into device territory requiring 510(k) clearance or De Novo classification. We recommend engaging FDA's Digital Health Center of Excellence early in the design phase. We build the regulatory documentation, including the CDS exemption justification, intended use statement, and clinical evaluation report, as a standard deliverable in Phase 1.
The research behind this solution page. For the full technical architecture, ontology design rationale, and clinical validation approach.
Complete technical analysis of the neuro-symbolic architecture, SNOMED-CT integration, deontic logic framework, and GraphRAG implementation for clinical trial patient matching.
A 40% screen failure rate across 10 trials means roughly $480K in wasted screening costs annually, before counting the enrollment delays.
We start with a 3-4 week recruitment operations audit. You get an architecture document, an ROI model built on your actual screen failure data, and a clear answer on whether a custom build makes sense for your trial portfolio.