Demos
Personalized treatment pathways require data engineering more than better models. See what Roche, MiBA, and Guideline Central built to get there in production.
Personalized medicine matches treatment to a patient’s genomic, phenotypic, and treatment-history data rather than population averages, a goal clinicians have understood for decades. The barrier has never been conceptual. It is operational: a genomic profile sits in a sequencing database, treatment response in oncology notes, imaging findings in radiology reports, each in a different system and format, kept by a different clinical team. Assembling a usable patient profile from that scatter, inside a clinical decision’s timeframe, is a data-engineering problem before it is a modeling problem.
Why personalized medicine has stayed a data problem, not an idea problem
Ask any oncologist what data would change how they treat a specific patient and you get a fast, confident answer: mutation status, prior treatment lines and response, comorbidities, relevant guideline branch. What clinicians rarely get is that data assembled, reconciled, and current at the moment they need it. A 2025 review of AI-driven multi-omics integration in precision oncology found that “traditional reductionist approaches, reliant on single-omics snapshots or histopathological assessment alone, fail to capture” the interconnected biology that actually drives treatment response, and that batch effects, missing data, and the lack of external validation remain open problems for translating multi-omics data into clinical decisions (Hsu et al., 2025).
That is the pattern across personalized medicine generally: the relevant data usually exists somewhere. What’s missing is the infrastructure to pull it together reliably, on a timeline a clinician or a trial coordinator can actually use. Three production deployments, at a global diagnostics company, an oncology data analytics firm, and a clinical guidelines publisher, show what that infrastructure looks like when someone actually builds it.
How Roche builds oncology treatment timelines from six kinds of clinical documents
Roche Diagnostics Information Solutions built a pipeline, in collaboration with John Snow Labs, that constructs oncology patient timelines from radiology, pathology, clinical oncology, discharge summary, and progress notes spanning multiple languages and care settings. The pipeline decomposes the problem into five stages: chemotherapy event extraction, time-expression extraction, temporal-relation classification, time-expression normalization, and patient-level timeline refinement (Bonis, 2025).
The hard part isn’t extracting a chemotherapy mention from one note. It’s that the same treatment cycle shows up in the oncologist’s note, the pharmacy record, and the discharge summary, often with dates or drug names that don’t quite match. Reconciling those mentions into one canonical timeline requires merging redundant entries, inferring clinical state from sparse data, and interpreting temporal relationships correctly, not just running a named-entity model across each document separately. Once the timeline exists, Roche’s Navify platform uses a smart-navigation capability that aligns the patient’s profile with the relevant NCCN guideline section, surfacing that guideline content for the treating oncologist’s own review rather than issuing a recommendation itself. The distinction matters: the system narrows a large guideline document to the section that applies. The clinician still makes the call. Medical LLM models purpose-built for clinical entity and temporal extraction are what make that timeline reconstruction possible at the note volume a diagnostics company processes.
Why matching a patient to a trial needs relationships, not just entities
Meaningful Insights Biotech Analytics, known as MiBA, runs an oncology data pipeline that processed 1.4 million physician notes and roughly 1 million PDF reports and scans, extracting 113.6 million clinical entities and 29.2 million relationships across 25 relationship types, at entity-extraction and relationship-extraction F1 scores of 93% and 88% respectively (Bonis, 2026). The extracted graph powers matching oncology patients to clinical trial criteria.
Entity extraction alone can’t do that matching. A patient with a BRCA1 mutation is relevant to some trials. A patient with a BRCA1 mutation who has already received and progressed on a PARP inhibitor belongs to a narrower, different set of trials, and that distinction depends on the temporal and causal relationship between three facts, not just their individual presence in a note. Research on structuring trial eligibility criteria confirms why this is hard at scale: large-language-model-derived criterion clusters can compress complex eligibility text while retaining most of its classification value, but the underlying criteria remain dense, conjunctive, and hard to parse reliably from free text (Bornet et al., 2025). MiBA’s relationship-extraction layer, built on Healthcare NLP, is what turns a list of facts into a queryable structure. See how the same category of model supports knowledge graph construction from clinical text more broadly.
How Guideline Central matches unstructured patient cases to guideline content
Guideline Central’s platform uses John Snow Labs medical language models to answer detailed questions drawn from more than 35 medical societies and government agencies, including questions involving visual tables, flowcharts, and fine-grained diagnostic criteria. Given an unstructured text summary of a patient case, the system identifies the relevant guideline section, explains its reasoning, and links directly to the source (Reyes and Trambitas, 2025).
Taking free text as input, rather than requiring a clinician to fill out a structured form first, is a design decision that reflects how clinicians actually work. They write prose about patients; they don’t enumerate a patient’s characteristics against a predefined taxonomy before making a decision. A guideline-matching system that demands structured input adds a data-entry step that most clinical workflows won’t tolerate. One that reads the free-text note a clinician already wrote and surfaces the applicable guideline section fits into documentation as it already happens, without a workflow change.
Why domain-trained models outperform general LLMs on these specific tasks
The common thread across Roche, MiBA, and Guideline Central is domain specificity. Each deployment depends on models trained to understand clinical language, clinical relationships, and the logical structure of guidelines, tasks where general-purpose models have a documented, measurable gap.
On John Snow Labs’ published MedHELM results, a 13-task benchmark spanning clinical documentation, coding, safety, dialogue, and reasoning, its Medical LLM Medium model leads on 12 of the 13 tasks with a mean win rate of 77.78, against 73.56 for GPT-5.5, 72.06 for Claude Opus 4.8, and 71.61 for Gemini 3.5 Flash, with the widest margin, 15 points, on the Medec clinical-error-detection task (John Snow Labs, 2026). The peer-reviewed CLEVER study adds independent, blinded evidence: in a randomized evaluation, practicing physicians preferred John Snow Labs’ 8-billion-parameter Medical Model-Small over GPT-4o 45% to 92% more often across factuality, clinical relevance, and conciseness, judged across 500 clinical cases spanning internal medicine, oncology, and neurology (Kocaman et al., 2025). The same domain-specificity gap shows up on the privacy side of personalized medicine, where genomic and longitudinal records carry the most sensitive fields in a patient’s chart: on a 48-document expert-annotated benchmark, John Snow Labs’ healthcare-specific de-identification reached a 96% PHI F1-score, ahead of Azure (91%), AWS Comprehend Medical (83%), and GPT-4o (79%) (Kocaman et al., 2025).
None of these numbers say general-purpose models are unusable. They say model choice for a personalization pipeline has to be validated task by task, the same way Roche, MiBA, and Guideline Central validated theirs, not assumed from a model’s general reasoning benchmarks.
What the infrastructure actually requires in production
Personalized medicine demonstrations that work well in research settings tend to share a trait: the data was already curated before the AI system saw it. A data engineer or clinical informaticist had already linked records to the right patient, resolved conflicting information, mapped terminology to standard ontologies, and de-identified sensitive fields. The model looks good because someone already did the hard part.
Production deployment means doing that preparation continuously, on incoming data, at the scale of an actual clinical operation, across every note template, EHR system, and specialty vocabulary a health system or pharma company runs on. That is why Roche, MiBA, and Guideline Central built their data pipelines and their AI models together, not in sequence. Extraction, temporal reasoning, entity linking, and guideline structure were design requirements from the start, not patches applied after a model was trained on curated data and then pointed at production. A platform like Patient Journey Intelligence is built on that same premise: the pipeline that assembles a longitudinal, multi-source patient record is the product, and the model sits inside it rather than in front of it.
For teams evaluating what personalized medicine infrastructure their own organization would need, the diligence questions worth asking mirror the evidence above: what is relationship-extraction accuracy, not just entity-extraction accuracy; how is guideline logic represented, not just guideline text; and was the model validated on the specific task, not a general reasoning leaderboard.
See how Patient Journey Intelligence assembles a longitudinal, multi-source patient record from unstructured clinical documents, and what that pipeline looks like end to end.
Request a technical consultation scoped to your own note volume and data sources to get answers specific to your environment rather than benchmark averages.
Frequently asked questions
Why hasn’t AI delivered on personalized medicine sooner, given that the relevant patient data already exists?
The barrier has never been conceptual. Clinicians have long known what data personalizes a treatment decision. The problem is operational: genomic profiles, EHR notes, imaging findings, and treatment records sit in separate systems and formats, maintained by different teams, and assembling them within a clinical decision’s timeframe requires integration infrastructure that most organizations haven’t built as one coherent system (Hsu et al., 2025).
What makes matching a patient to a clinical trial or guideline harder than it sounds?
Eligibility rarely depends on isolated facts. A patient with a BRCA1 mutation who has also received and progressed on a PARP inhibitor qualifies for a different, narrower set of trials than a patient who simply carries the mutation. Capturing that kind of temporal and causal relationship across millions of documents is a different problem from listing diagnoses or medications, and it’s why eligibility-criteria text remains dense and hard to parse reliably even with LLM-assisted methods (Bornet et al., 2025).
Can general-purpose models like GPT-4o handle these clinical personalization tasks as well as healthcare-specific models?
The evidence says not consistently. On MedHELM, John Snow Labs’ Medical LLM Medium leads 12 of 13 clinical tasks against current GPT, Gemini, and Claude models (John Snow Labs, 2026), and in blinded physician evaluation its Medical Model-Small was preferred over GPT-4o 45% to 92% more often across factuality, relevance, and conciseness (Kocaman et al., 2025). On PHI detection, relevant to the sensitive genomic data personalized medicine depends on, a healthcare-specific model reached 96% F1 against GPT-4o’s 79% (Kocaman et al., 2025).
What does Roche’s Navify Smart Navigation actually do with NCCN guidelines?
After Roche’s pipeline reconstructs a patient’s oncology timeline from EHR data, Smart Navigation aligns that patient profile with the relevant section of NCCN clinical practice guidelines and surfaces it for the treating oncologist’s review (Bonis, 2025). It narrows a large guideline document to the applicable branch; the clinician still makes the treatment decision.
How does MiBA’s knowledge graph support clinical trial matching?
MiBA extracted 113.6 million clinical entities and 29.2 million relationships across 25 relationship types from 1.4 million physician notes and about 1 million PDF reports, at 93% entity-extraction and 88% relationship-extraction F1 (Bonis, 2026). Those relationships, not just the entities, are what let the system match a patient’s specific treatment history and biomarker status to a trial’s eligibility logic.
Why do personalized medicine AI systems that work well in research often struggle in production?
Research systems typically run on datasets a data engineer already curated: records linked to the right patient, terminology normalized, conflicts resolved, sensitive fields de-identified. Production requires doing that same work continuously, on incoming data, across the full variation of a real clinical environment, which most research demonstrations never show.
What distinguishes organizations that have successfully deployed personalized medicine AI from those that haven’t?
Roche, MiBA, and Guideline Central each built their data engineering pipeline and their AI models together, as one system, rather than developing a model on clean data and adapting it to production afterward. That upfront architectural decision, treating the pipeline itself as the product, is what separates deployments that hold up in production from research demonstrations that don’t.
