From Individual Cases to Comparative Evidence: A Roadmap for AI-Driven Decision Support in Healthcare

The Process, Step by Step

1. Doctor logs data — vitals, diagnosis, labs, medications, interventions, entered as part of routine care.
2. Longitudinal follow-up — the same case is tracked over time, not just at a single encounter.
3. Similar-case bucketing — cases are grouped by diagnosis, so comparable patients can be compared.
4. Variation analysis — differences in management are surfaced, along with the reasons behind them (which may range from sound clinical judgment to resource constraints — "man, money, machine, evidence, eminence," etc.).
5. Case-based insight as evidence — patterns from the comparison are turned into practical, evidence-backed suggestions.

Goal: demonstrate AI's effectiveness in Indian healthcare through a concrete, replicable feedback loop — not a general claim, but a specific one built from local data.

Where This Sits in the Broader AI Landscape

Not all "AI in healthcare" is the same kind of tool, and conflating them causes confusion about what to expect. A few useful distinctions:

• Broad vs. narrow AI — general-purpose reasoning versus tools built for one disease or one decision.
• System 1 vs. System 2 AI — fast, pattern-matching support versus slower, deliberate, structured reasoning.
• Multimodal vs. single-disease-specific vs. ultra-narrow — different scopes create impact in different ways.

And maturity varies just as much as scope:

• Some tools are FDA-approved and demonstrably efficient.
• Some are approved but suffer from alert fatigue in practice.
• Some are useful but haven't reached formal approval.
• Some are useful mainly as learning aids — broadening a trainee's thinking or extending practice opportunity.
• Some, frankly, are not useful at all.

Any given tool's value depends on where it sits on both axes — scope and maturity — within the larger ecosystem it's deployed in.

Two Worked Examples of "Process 5" (Case-Based Insight)

To ground the concept, two demonstrations were shared, both using LLM-based evidence synthesis on real case report data pulled from PubMed.

1. Snake bite — ASV decision node Twelve case reports analyzed around a single critical decision-making node: the use of Anti-Snake Venom (ASV) in snakebite management. This example is most suited to intervention-related insight — comparing what was done and what followed. → View the analysis

2. Nested analysis across five case reports A nested index built from five case reports, better suited to diagnostic decision-making rather than intervention choice. → View the analysis

Together, these illustrate the same underlying method applied to two different kinds of clinical decisions — what to do, and what it is.

Caveats Worth Stating Plainly

• LLMs have real limitations, and those don't disappear because the data is structured.
• Existing high-value tools remain strong — textbooks, guidelines, clinical pathways, current CDSS tools, and the judgment of experienced evidence-based practitioners already cover most of the high-impact decision nodes in patient care. Large-scale case-based analytics is unlikely to frequently overturn decisions these tools already handle well.
• The realistic value-add is acceleration, not replacement: this approach can help identify a much larger number of decision nodes worth studying, and build clearer, faster evidence around them — supplementing existing high-value tools rather than competing with them.

Extending the Method: Narrative and FHIR-Enabled Case Records

The two worked examples above used free-text case reports from PubMed. The same method extends naturally to two data sources most hospitals already have, in different states of readiness.

Narrative case records — discharge summaries, progress notes, WhatsApp-style case discussions, free-text case reports — carry the clinical reasoning itself: why a decision was made, not just what was ordered. An LLM can be pointed at a cluster of narrative records for the same diagnosis to:

• Pull out the specific critical decision node in question (e.g., "was ASV given, and at what threshold?") across every record in the cluster.
• Build a nested analysis — index the shared decision structure, then drill into each case to see how it played out, surfacing both the pattern and the exceptions.
• Highlight diagnostic pattern similarity and variation — which presentations were called the same diagnosis, where the diagnostic reasoning diverged, and what distinguished the cases that turned out differently.

FHIR-enabled case records add the structured layer this whole proposal is built on — vitals, medication orders, lab results, and diagnoses as coded, comparable fields rather than prose. This is what makes true cross-provider, cross-case comparison tractable at scale: once records share a common structure, an LLM (or simpler analytics) can bucket cases by diagnosis, align timelines, and compare intervention-to-outcome across dozens or hundreds of cases instead of the handful a manual case series allows.

The most powerful version combines both: FHIR-structured fields for the comparative scaffolding (who got what, when, with what result) plus narrative text for the reasoning layer (why that choice was made, what alternatives were considered). Structured data tells you what happened and how fast; narrative data tells you why, and that "why" is often where the transferable clinical insight actually lives. Together, they let the same critical-decision-node and nested-analysis approach used on the snakebite and five-case examples run at a scale no single clinician could review by hand — turning scattered individual cases into a searchable evidence base specific to a hospital's own patient population.

Keep the Human Mind as the Guardrail

None of this changes the caveat already stated above — it reinforces it. Scaling the method to more records and more structure doesn't remove the underlying weaknesses of LLMs: they can misread nuance, overgeneralize from a small or skewed cluster, or surface a confident-sounding pattern that doesn't actually hold up. The larger the dataset, the easier it becomes to mistake volume for validity.

So the design principle stays fixed as this scales:

• LLMs are for speed — pulling the decision node out of a hundred records, building the nested comparison, drafting the first-pass synthesis — work that would take a clinician-researcher weeks to do by hand.
• Human clinical judgment is for validity — deciding whether the surfaced pattern is real, clinically sound, and safe to act on; deciding whether a "variation in management" reflects better care, worse care, or just different but reasonable care under different constraints.

The goal is not an AI that tells clinicians what to do. It's an AI that does the tedious comparative work fast enough that experienced, evidence-based practitioners can spend their limited time doing what only they can do: judging whether the pattern is trustworthy before it becomes a recommendation.

Where Ontologies Like SNOMED CT and LOINC Add Another Layer

FHIR structure solves format — the same fields in the same shape across records. Ontologies solve meaning — making sure two records that say the same clinical thing are actually recognized as saying the same thing.

• SNOMED CT codes diagnoses, findings, and procedures. Without it, "snake bite envenomation," "venomous snakebite," and a dozen local free-text phrasings for the same condition sit in the data as if they were different things. With it, every case in the bucket is provably the same diagnosis before any comparison starts, and related concepts (a specific complication, a specific finding) can be matched by their place in the ontology's hierarchy rather than by exact wording.
• LOINC codes labs and observations the same way — so a "WBC count" ordered at one facility and a "total leukocyte count" ordered at another are recognized as the same measurement, comparable on the same axis, at the same timepoints, across providers.

For this proposal specifically, ontology-coded records sharpen every step of the process:

• Bucketing (step 3) becomes exact rather than approximate — cases are grouped by a shared SNOMED CT concept, not by fuzzy text matching on diagnosis strings.
• Variation analysis (step 4) becomes cleaner — when interventions and labs are LOINC/SNOMED-coded, "different management" can be distinguished from "differently worded but identical management," which is a major source of false variation in narrative-only data.
• Nested and critical-decision-node analysis gets more precise — a decision node like "ASV threshold" can be defined once as an ontology concept and then reliably located across every case, rather than re-identified by the LLM each time from free text.
• Cross-hospital and literature comparison becomes possible — ontology-coded local data can be compared against ontology-coded external evidence (published case series, national registries) on equal terms, which is what ultimately lets a hospital's internal recommendation be checked against, and contribute to, the wider evidence base.

In short: FHIR gives the comparison a common shape, ontologies give it a common language. Together they reduce how much of the LLM's work is "figuring out if these two things are the same" and let it spend more of its speed advantage on the actual comparative reasoning — while the human guardrail described above still governs whether the resulting pattern is trusted.

Biases This Approach Can Still Carry — Even With Clean, Coded Data

Structuring the data well (FHIR, SNOMED CT, LOINC) removes noise — mismatched formats and mismatched terminology. It does not remove bias — the reasons real-world management varies that have nothing to do with which intervention is actually better. A hospital acting on these patterns without naming these risks first could end up encoding its existing distortions as "evidence."

• Small or unrepresentative sample size — a single hospital's case count for a given diagnosis may be too small for the "fastest/best outcome" comparison to be statistically meaningful, especially once cases are split further by severity, comorbidity, or subtype. A pattern from 15 cases can look as confident as a pattern from 1,500 if the output isn't explicit about sample size.
• Defensive practice — clinicians may order extra tests, prolong admission, or choose a more cautious intervention primarily to limit liability risk, not because it's clinically superior. If defensive choices correlate with slightly better measured outcomes (more monitoring catches more problems), the system could end up recommending "practice defensively" as if it were the clinically optimal intervention.
• Overtreatment or undertreatment norms — some departments or individual clinicians may systematically over-intervene (more drugs, more procedures) or under-intervene (resource-constrained wards, high patient load) as a standing local norm rather than a case-by-case decision. Either norm will show up in the data as "the management pattern here," indistinguishable from a considered clinical choice unless flagged.
• Financial reality of the patient population — choice of drug, length of stay, and which investigations get done are often shaped by what a patient or family can actually afford, not by what the treating clinician would choose with no constraint. An outcome that looks worse may reflect a cheaper substitute drug or a shorter stay driven by cost, not weaker clinical decision-making — and the reverse is equally possible, where a costlier option looks superior mainly because it was affordable to a wealthier subgroup.
• Referral and severity bias — a tertiary center's "cases" for a diagnosis are often the ones too complex or too late-presenting for smaller facilities to manage, which skews outcome comparisons against any hospital that receives more referred, sicker patients.
• Provider-level confounding — a specific senior clinician's cases may cluster around a specific intervention simply because that is their practice pattern, not because it was independently chosen per case; comparing "interventions" across providers can end up quietly comparing providers instead.
• Missing or incomplete documentation — logging depends on what clinicians actually enter; busier shifts, emergency cases, or less digitally-fluent departments may under-document specific fields, silently underrepresenting exactly the cases most likely to have important outcome variation.
• Survivorship and follow-up loss — patients who default from follow-up, transfer elsewhere, or are lost to the longitudinal record are not random; if sicker or poorer patients are disproportionately lost to follow-up, the tracked outcomes will look better than reality.
• Temporal drift — practice patterns, drug availability, and even diagnostic criteria change over time; pooling cases across several years without accounting for when they occurred can blend outdated and current practice into a single misleading "pattern."

None of this is a reason to abandon the approach — it's the reason the earlier caveats matter as much as they do. Any output from this system should carry its confounders alongside its conclusion (sample size, provider spread, time range, cost context), not present a clean "recommended intervention" stripped of the conditions that produced it. This is exactly why the human clinical mind stays the guardrail: only a clinician with local context can tell the difference between "this intervention works better" and "this is what get chosen for patients who can afford it, at the hospital that sees the sickest cases, documented by the clinicians who had time to log it."

Why This Matters

This isn't a pitch for AI as a diagnostic oracle. It's a proposal to treat a hospital's own longitudinal case data as an underused evidence base — and to use LLMs to do the comparative work of surfacing which interventions, for which diagnoses, actually produce the best outcomes fastest, with the evidence to back the recommendation. Starting with the most structured data (vitals, orders, meds) is a deliberate choice to make the first version tractable and convincing before extending to messier, more narrative clinical reasoning.

Demo - https://avi33tbtt.github.io/CKD-Case-Study/