Back to Insights

Why General-Purpose LLMs Fall Short in Clinical Documentation

By Robert Lugowski · · 8 min read
Why General-Purpose LLMs Fall Short in Clinical Documentation

I want to be clear about something before going further: this is not an argument that large language models have no place in clinical applications. They clearly do. Summarization of patient histories, drafting prior authorization letters, translating complex medical information for patients: these are tasks where modern LLMs perform well enough to be genuinely useful. The argument here is more specific, and it matters because clinical teams are increasingly being asked to evaluate whether an LLM-based product can replace a structured extraction pipeline for research-grade use.

It cannot, at least not yet, and not for the reasons that usually get cited. The issue is not safety broadly or hallucination in general. It is the specific failure modes that compound in structured extraction tasks at scale: negation handling, dose ambiguity, assertion inconsistency, and the absence of a stable output schema. Understanding these failure modes is how you evaluate a claim that "our product uses GPT-4 to extract entities from your EHR notes."

The Negation Problem Is Not Solved

Clinical text is full of negated findings. "No chest pain." "She denies shortness of breath." "The CT showed no evidence of pulmonary embolism." In a single cardiology note, there may be more negated findings than affirmed ones. For a summarization task, an LLM can handle negation well because the output is prose and a paraphrase that reverses a negation is detectable in review. For structured extraction, a negated finding produces a binary output error: the condition is either included in the extraction as affirmed, or it is not. There is no prose to catch the mistake.

We tested several general-purpose LLMs on a set of negation-dense cardiology notes in 2024, using prompts designed to instruct careful negation handling. Across multiple prompt formulations, negation recall (correctly identifying that a condition was negated rather than affirmed) ranged from roughly 75% to 85% depending on the LLM and prompt design. That is not bad for a single note reviewed by a human. At 10,000 notes, a 15-25% error rate on negated conditions means thousands of false inclusions in a cohort. For a study that requires clean cohort membership, that error rate is disqualifying.

By contrast, purpose-built clinical NLP systems trained specifically on negation detection in clinical text, using architectures tuned for the task and evaluated against annotated negation corpora, consistently achieve negation accuracy above 92% on diverse note types. The gap is not philosophical; it is a consequence of training data and task-specific optimization.

Output Schema Instability

Structured extraction requires structured output. Every extraction run on 500 notes needs to return the same output format: entity type, entity text, assertion status, source sentence, confidence score, document date. When a downstream analysis pipeline expects a CSV with those columns, any variation in column naming, field representation, or row structure is a pipeline break.

General-purpose LLMs are probabilistic text generators. Even with a well-designed system prompt specifying output format, the actual output format varies. Extra explanatory text appears. JSON fields are renamed between runs. Confidence scores that were requested as floats are returned as strings or as adjectives. Lists of medications are sometimes returned as comma-separated inline text rather than separate rows. None of these variations are the LLM being wrong about the clinical content; they are the LLM varying in how it represents that content.

There are engineering approaches that reduce this variance. Constrained generation, output parsers, schema validation, retry loops with format correction. These work, and if you are building a production system on top of an LLM, you are likely implementing some version of them. But the result is a fragile layer of format enforcement sitting on top of a text generator that was not optimized to produce stable structured output. Every edge case in note format or content is a potential new failure mode in the parsing layer.

The Dose Ambiguity Issue

Medication extraction looks straightforward until you encounter real clinical documentation. "Continue Lasix 40 in the morning, 20 at night" requires knowing that Lasix is furosemide, that the dosing is asymmetric, and that the units are milligrams despite not being stated. "Metformin 1000 BID with meals, hold if contrast" encodes a dose, a frequency, a route implication, and a conditional hold instruction in twelve words. "D/C amlodipine, switch to nifedipine ER 30" records a discontinuation and a new prescription in a single sentence.

General-purpose LLMs handle these reasonably well on individual examples. Where they underperform is on the long tail of clinical shorthand, unusual formatting, and dose units that are implied rather than stated. In a corpus of 10,000 notes from a health system that has been using the same EHR for eight years, there are documentation patterns that reflect that specific EHR's template structure, that specific specialty's conventions, and those specific clinicians' individual habits. A model trained on diverse clinical text handles the common cases; the long tail requires domain adaptation.

We are not saying this is a fundamental limitation that cannot be addressed. Fine-tuning LLMs on clinical text does improve medication extraction substantially. The question for a team evaluating a product is whether the vendor has done that domain adaptation for the specific entity types and note types the team is working with, or whether "uses a large language model" is doing more marketing work than technical work in their description.

At-Scale Consistency

Perhaps the most important failure mode for RWE applications is consistency across a large run. An extraction that performs at F1 of 0.87 on average, but with variance between 0.65 and 0.95 across individual notes, is not suitable for a study where cohort membership must be consistently defined. Variance that cancels out in the aggregate still produces misclassified individual patients, and those misclassifications are not uniformly distributed. They tend to cluster around notes with specific structural features, specific jargon densities, or specific clinical complexity patterns. That clustering creates systematic bias, not random noise.

Purpose-built clinical NLP systems achieve lower average performance on raw text than large general-purpose LLMs on many individual examples. That is simply true. What they provide is tighter variance and more predictable failure modes. When a structured extraction system fails, it tends to fail in ways that can be characterized, instrumented for, and corrected. When an LLM-based extraction fails, it tends to produce plausible-looking output that requires reviewing the source note to identify as an error. For high-volume, low-human-review-rate workflows, which describe most operational RWE pipelines, predictable failures are significantly better than plausible errors.

Where LLMs Actually Help in the Stack

The honest answer is that LLMs and structured extraction are not in competition for the same use case. LLMs are better at generating prose outputs from notes, handling novel input formats, and producing human-readable summaries of what was extracted. Structured extraction systems are better at the precise, consistent, schema-stable, assertion-aware extraction that research pipelines require.

The sensible architecture is to use structured extraction for the core extraction pipeline and LLMs for the tasks where prose flexibility is more valuable than structural precision: generating plain-language summaries for review, drafting exception reports for chart reviewers, explaining why a particular note was flagged for human attention. That combination gets more out of both technologies than treating them as interchangeable alternatives for the same task.

CliniNote is built around the structured extraction side of that architecture. We are not claiming that LLMs cannot improve over time for this use case; they probably will. We are saying that for the specific requirement of consistent, schema-stable, research-grade entity extraction from clinical notes today, domain-specific systems trained and evaluated on clinical text outperform general-purpose LLMs in the ways that matter most to the teams running these studies.

Ready to extract structured evidence from your clinical notes?