Machine Learning and Large Language Models for Clinical Text Analysis
Article authored by Michele D. Pierri, MD
Cardiac Surgeon & Medical Technology Researcher
Last updated: May 2025
Reading time: 30 minutes
Abstract
The first two articles in this series traced a progression from rule-based pattern matching (regular expressions) to linguistic analysis (spaCy/scispaCy) for extracting structured information from cardiac surgery discharge summaries. Both approaches, despite their methodological differences, share one fundamental characteristic: they are designed by humans who encode explicit knowledge about language structure into algorithms. This third and final article introduces a qualitatively different paradigm, built around systems that learn representations of medical language from data. We cover classical machine learning classifiers for complication detection using TF-IDF feature engineering, then advance to Large Language Models (LLMs) and their application to clinical text through prompt engineering and the Anthropic Claude API. The article closes with a complete hybrid NLP pipeline integrating all three approaches, followed by an essential discussion of validation methodology, GDPR/HIPAA compliance, and de-identification techniques required for any production medical NLP system.
Article Series:
- Introduction to NLP and Regex for Medical Reports
- Advanced Linguistic Analysis with spaCy and scispaCy
- Machine Learning and Large Language Models for Clinical Text Analysis (this article)
1. The NLP Paradigm Progression: A Unified View
Before introducing the techniques covered here, it is worth consolidating the conceptual framework underlying the entire series. A question naturally arises: are regex, spaCy, and LLMs all really “NLP”? The answer is yes. All three are approaches to Natural Language Processing, the field concerned with enabling computers to understand and generate human language. What distinguishes them is the level at which language is modeled and the source of the knowledge they encode.
Regex (Article 1) encodes linguistic knowledge as explicit character patterns written by a human programmer. The system has no model of language structure; it matches sequences of characters. Knowledge source: human expert rules.
spaCy/scispaCy (Article 2) encodes linguistic knowledge as statistical models trained on annotated corpora. The system has explicit representations of tokens, parts of speech, syntactic structure, and named entities. Knowledge source: supervised learning from human-annotated examples.
Classical ML (this article, Section 2) encodes linguistic knowledge as learned associations between numerical text representations (TF-IDF vectors) and output labels. The system has no explicit model of language structure, but learns statistical correlations between word co-occurrences and outcomes. Knowledge source: supervised learning from labeled examples, with human-designed features.
Large Language Models (this article, Section 3) encode linguistic knowledge as billions of learned parameters representing the statistical structure of language at every level: from character sequences to semantic relationships to pragmatic context. Knowledge source: self-supervised pre-training on massive text corpora, capturing language in an emergent, distributed representation.
The progression is not merely technical. It reflects increasing depth of language understanding, at the cost of increasing computational requirements, reduced interpretability, and (critically for medical applications) greater difficulty in validation and regulatory compliance. Each level adds capabilities the previous cannot provide, and each retains appropriate use cases where simpler approaches are preferable.
2. Classical Machine Learning for Clinical Text Classification
2.1 Why Classical ML Before LLMs?
Large Language Models achieve impressive results on many clinical NLP tasks. Yet classical machine learning (logistic regression, random forests, support vector machines) remains clinically relevant for several reasons:
- Interpretability: Feature importance scores from a logistic regression are auditable by clinicians; a transformer’s attention weights are not
- Data efficiency: A well-engineered classifier can be trained on hundreds of examples; LLMs require prompt engineering but cannot be fine-tuned without thousands
- Regulatory transparency: Many healthcare jurisdictions require explainable AI for clinical decision support; “because the LLM said so” is not an acceptable audit trail
- Computational cost: Classical classifiers run on a laptop CPU; LLMs require GPU inference or API calls
- Speed: TF-IDF + logistic regression classifies a document in microseconds
For complication detection from discharge summaries (a well-defined binary classification task), a classical ML approach is not only adequate but often preferable.
2.2 Text Representation: TF-IDF Vectorization
The fundamental challenge in applying machine learning to text is representation: algorithms require numerical inputs, not strings. Term Frequency–Inverse Document Frequency (TF-IDF) is the classical solution. It represents each document as a vector where each dimension corresponds to a vocabulary term, and the value encodes both how frequently the term appears in this document (TF) and how discriminative it is across the corpus (IDF).
TF (Term Frequency): How often does term t appear in document d?
IDF (Inverse Document Frequency): How rare is term t across all documents?
TF-IDF: The product emphasizes terms that are frequent in a specific document but rare overall, precisely the discriminative terms useful for classification.
In clinical terms: “atrial fibrillation” appearing in a discharge summary has high TF-IDF if it appears frequently in that document but rarely across the whole corpus, making it a strong signal for arrhythmia-related classification tasks.
Expected output:
Training Complete:
Documents: 14
Positive cases: 8
Cross-validation AUC: 0.875 ± 0.112
Classification Result:
Prediction: COMPLICATED
Probability (complication): 73.2%
Confidence: Medium
Top contributing terms:
'atrial fibrillation': +0.4821 → complicated
'cardioverted': +0.3914 → complicated
'complications': -0.2143 → uncomplicated
'without complications': -0.1987 → uncomplicated
'amiodarone': +0.1654 → complicated
Terms most associated with complications:
'infection': +0.8234
'atrial fibrillation': +0.4821
'reintubation': +0.4510
'dehiscence': +0.4201
'stroke': +0.3987
The model correctly identifies “atrial fibrillation” and “cardioverted” as complication indicators. The “without complications” bigram moderates the prediction toward Medium confidence. This is actually a clinically reasonable behavior, reflecting the nuanced nature of the case; a binary label would not capture such gradient.
3. Large Language Models for Clinical Text Analysis
3.1 What LLMs Can Do That Classical NLP Cannot
Large Language Models represent a paradigm shift in NLP. Rather than learning task-specific mappings from labeled examples, LLMs are pre-trained on vast text corpora to predict the next token in a sequence (a self-supervised objective that forces the model to internalize grammar, semantics, factual knowledge, and reasoning patterns simultaneously). The result is a general-purpose linguistic intelligence that can be directed toward specific tasks through natural language instructions, rather than task-specific training.
For clinical text analysis, LLMs offer capabilities that are genuinely novel:
- Zero-shot extraction: Extract arbitrarily complex structured data from text without labeled examples, simply by describing what you want in the prompt
- Semantic equivalence recognition: Understand that “triple vessel disease,” “3VD,” and “severe multivessel CAD” refer to the same condition without explicit synonym lists
- Clinical reasoning: Assess whether documented management aligns with published guidelines (ACC/AHA, ESC), something requiring medical knowledge, not just pattern recognition
- Contextual inference: Determine that a patient with LVEF 35% on admission and 40% on discharge had cardiac function improvement, even if the word “improvement” never appears
- Uncertainty quantification in narrative form: Recognize “cannot exclude” and “suspicious for” as expressions of diagnostic uncertainty, rather than confirmed findings
3.2 The Anthropic Claude API for Medical NLP
The Claude API provides programmatic access to Anthropic’s Claude models. For medical NLP applications, Claude offers several relevant strengths: strong performance on clinical reasoning benchmarks, support for long-context documents (up to 200K tokens in Claude 3 models), and structured output generation.
3.3 Prompt Engineering for Medical Text
Effective LLM performance on clinical tasks depends critically on prompt design. Several principles, validated empirically in medical NLP research, apply directly to our use case.
Role assignment: Giving the model a specific clinical identity (“You are a cardiac surgery quality improvement specialist”) activates domain-specific knowledge patterns and reduces generic responses. In published evaluations, appropriate role prompting can yield meaningful gains on some medical QA tasks, though the magnitude depends strongly on the dataset and evaluation setup.
Schema specification: Providing the exact JSON schema in the prompt dramatically improves structured output reliability. Rather than asking “extract the medications,” defining the exact field names, types, and constraints guides the model toward consistent output.
Constraint encoding: Clinical validation rules embedded in the prompt (“LVEF values should be between 15 and 80”) help the model self-correct obvious errors and flag unusual values.
Uncertainty handling: Explicitly instructing the model to use null for absent data rather than inferring or hallucinating prevents a major failure mode in medical LLM applications. The instruction is simple: “Never infer or hallucinate values not explicitly stated.” In practice, even this directive is not always followed perfectly, which underscores the need for post-hoc validators alongside any clinical prompt.
Disclaimer integration: For guideline comparison and clinical assessment tasks, embedding disclaimers directly in the prompt ensures they appear in every output, supporting appropriate use of the system.
4. Privacy, De-identification, and GDPR/HIPAA Compliance
4.1 The Regulatory Landscape for Medical NLP
Any NLP system processing clinical documents operates within a strict regulatory framework. In Europe, the General Data Protection Regulation (GDPR) classifies health data as a “special category” requiring explicit consent and heightened protection standards. In the United States, HIPAA’s Privacy and Security Rules govern Protected Health Information (PHI) handling.
For medical NLP systems, the critical requirement is de-identification: removing or transforming all information that could identify an individual patient before any processing that extends beyond direct clinical care. HIPAA defines 18 categories of PHI that must be addressed:
- Direct identifiers: names, geographic identifiers smaller than state, dates (except year), telephone numbers, MRN, SSN, email addresses
- Quasi-identifiers: age (if over 89), rare medical conditions in combination with other data
4.2 De-identification Pipeline
import re
import hashlib
from typing import Dict, List, Tuple
from dataclasses import dataclass
@dataclass
class DeidentificationResult:
deidentified_text: str
phi_found: List[Dict]
replacement_map: Dict[str, str]
class MedicalTextDeidentifier:
PHI_PATTERNS = {
'patient_name': (
r'\\b(?:Patient|Name):\\s*([A-Z][a-z]+[A-Z][a-z]+(?:\\s[A-Z][a-z]+)?)\\b',
'FULL_NAME'
),
'date_full': (
r'\\b(\\d{1,2}[/\\-]\\d{1,2}[/\\-]\\d{4})\\b',
'DATE'
),
'mrn': (
r'\\b(?:MRN|Medical Record):\\s*(\\d{6,10})\\b',
'MRN'
),
'phone': (
r'\\b(\\+?[\\d\\s\\-\\(\\)]{10,15})\\b',
'PHONE'
),
'email': (
r'\\b([a-zA-Z0-9._%+\\-]+@[a-zA-Z0-9.\\-]+\\.[a-zA-Z]{2,})\\b',
'EMAIL'
),
}
PSEUDONYM_POOLS = {
'FULL_NAME': ['James Anderson', 'Robert Williams', 'Maria Garcia',
'David Johnson', 'Emma Thompson', 'Michael Brown'],
'PHYSICIAN_NAME': ['Dr. A. Smith', 'Dr. B. Jones', 'Dr. C. Davis'],
'DATE': None,
'MRN': None,
}
def __init__(self, replacement_strategy='pseudonymize', consistent_replacement=True):
self.replacement_strategy = replacement_strategy
self.consistent_replacement = consistent_replacement
self._replacement_cache: Dict[str, str] = {}
self._pseudonym_counters: Dict[str, int] = {}
def deidentify(self, text: str) -> DeidentificationResult:
self._replacement_cache.clear()
self._pseudonym_counters.clear()
deidentified = text
phi_found = []
replacement_map = {}
for phi_category, (pattern, phi_type) in self.PHI_PATTERNS.items():
matches = list(re.finditer(pattern, deidentified))
for match in reversed(matches):
original = match.group(1) if match.lastindex else match.group(0)
pseudonym = self._get_pseudonym(phi_type, original)
phi_found.append({
'category': phi_category,
'phi_type': phi_type,
'start': match.start(),
'end': match.end(),
'replacement': pseudonym
})
full_match = match.group(0)
replaced_match = full_match.replace(original, pseudonym)
deidentified = deidentified[:match.start()] + replaced_match + deidentified[match.end():]
replacement_map[pseudonym] = original
return DeidentificationResult(
deidentified_text=deidentified,
phi_found=phi_found,
replacement_map=replacement_map
)
5. The Complete Hybrid NLP Pipeline
5.1 Integrating All Three Paradigms
The most robust clinical NLP systems do not rely on a single paradigm but orchestrate multiple approaches, each contributing where it performs best. The HybridMedicalNLPPipeline class integrates all techniques from this series.
Pipeline architecture:
- De-identification (if enabled)
- Layer 1: Regex — fast structured extraction of dates, values, medications (high precision for formatted fields)
- Layer 2: scispaCy NER — biomedical entity recognition, abbreviation detection, UMLS linking
- Layer 3: LLM (optional, highest cost) — complex inference, guideline comparison, structured extraction from free text
- Reconciliation — merge results, resolve conflicts, validate against clinical constraints
- Structured Output (JSON)
The pipeline is configurable: the LLM layer can be disabled for cost-sensitive batch processing, falling back to regex + scispaCy.
from dataclasses import dataclass, field
from typing import Optional
import time
@dataclass
class HybridPipelineResult:
document_id: str
deidentified: bool
regex_data: Dict = field(default_factory=dict)
nlp_entities: Optional[Any] = None
llm_structured: Optional[Dict] = None
llm_complications: Optional[Dict] = None
llm_guidelines: Optional[Dict] = None
reconciled: Dict = field(default_factory=dict)
conflicts: List[str] = field(default_factory=list)
processing_time_ms: float = 0.0
errors: List[str] = field(default_factory=list)
class HybridMedicalNLPPipeline:
def __init__(self, enable_deidentification=True, enable_nlp=True,
enable_llm=True, enable_guideline_check=False):
self.enable_deidentification = enable_deidentification
self.enable_nlp = enable_nlp
self.enable_llm = enable_llm
self.enable_guideline_check = enable_guideline_check
self._deidentifier = None
self._nlp_extractor = None
self._llm_analyzer = None
def process_document(self, text, document_id="unknown", run_guideline_check=False):
start_time = time.time()
result = HybridPipelineResult(document_id=document_id,
deidentified=self.enable_deidentification)
working_text = text
if self.enable_deidentification:
try:
deid_result = self._get_deidentifier().deidentify(text)
working_text = deid_result.deidentified_text
result.regex_data['phi_removed'] = len(deid_result.phi_found)
except Exception as e:
result.errors.append(f"De-identification error: {e}")
if self.enable_nlp:
try:
nlp_extractor = self._get_nlp_extractor()
result.nlp_entities = nlp_extractor.analyze(working_text)
except Exception as e:
result.errors.append(f"NLP extraction error: {e}")
if self.enable_llm:
try:
llm = self._get_llm_analyzer()
llm_result = llm.extract_structured_data(working_text)
result.llm_structured = llm_result.structured_data
comp_result = llm.analyze_complications_severity(working_text)
result.llm_complications = comp_result.structured_data
if run_guideline_check or self.enable_guideline_check:
guide_result = llm.compare_to_guidelines(working_text)
result.llm_guidelines = guide_result.structured_data
except Exception as e:
result.errors.append(f"LLM extraction error: {e}")
result.reconciled = self._reconcile_outputs(result)
result.processing_time_ms = (time.time() - start_time) * 1000
return result
6. Validation and Performance Metrics
6.1 Why Validation Is Non-Negotiable in Medical NLP
A classifier that achieves 95% accuracy on its training set but 70% on real-world data causes harm. In clinical applications, the stakes of this performance gap are not academic: incorrect complication detection, missed drug interactions, or erroneous guideline assessments directly affect patient management. Medical NLP validation must therefore be:
External: Evaluated on documents from a different time period or institution than the training data, testing true generalizability rather than memorization.
Task-specific: Aggregate accuracy conceals clinically important failures. A system might achieve 95% overall accuracy while failing on the 5% of cases involving rare but severe complications, exactly the cases where automated support is most valuable.
Entity-level: For NER tasks, evaluation should be at the entity span level (exact match of start position, end position, and label), not at the document level.
The standard metrics are:
For binary classification with class imbalance (rare complications), the Area Under the Precision-Recall Curve (AUPRC) is more informative than ROC-AUC.
6.2 LLM Evaluation: Beyond Numeric Metrics
Evaluating LLM extraction quality requires additional considerations compared to classical classifiers. When a logistic regression misclassifies a case, the error is binary (correct or incorrect). When an LLM extracts the wrong medication dose, the error exists on a spectrum from trivial (50mg vs. 50.0mg) to critical (amiodarone 200mg vs. 2000mg). This asymmetry in error severity is something aggregate metrics simply fail to capture, and it matters enormously in cardiac surgery contexts.
For structured data extraction tasks, the recommended evaluation framework includes:
- Field-level accuracy: Proportion of extracted fields exactly matching the gold standard annotation
- Semantic equivalence: Cases where the LLM extracts a semantically equivalent but differently worded value (e.g., “twice daily” vs. “BID”) should be scored as correct
- Hallucination rate: Proportion of extracted values not present in the source document, the most dangerous failure mode in clinical applications
- Abstention quality: Does the model correctly return
nullfor absent fields rather than inferring or fabricating values?
7. Production Considerations and Deployment
7.1 Architecture Considerations for Clinical Settings
Deploying any of the tools described in this series in a clinical environment requires addressing infrastructure considerations that go well beyond code quality.
Data residency: GDPR Article 44-49 restricts transfer of health data outside the EEA. If using cloud LLM APIs (including the Anthropic API), ensure contractual data processing agreements are in place and verify that data is not used for model training. For maximum compliance, consider on-premises deployment of open-source models (Llama 3, Mistral Medical).
Audit logging: Every document processed, every extraction performed, and every human validation decision must be logged with timestamps and user identifiers. This is both a regulatory requirement and a prerequisite for system improvement.
Human-in-the-loop validation: No automated NLP system should modify clinical records without human review. The appropriate architecture positions NLP output as proposed values subject to clinician validation, a co-pilot rather than an autopilot.
Model versioning and drift monitoring: Clinical language evolves. New procedures, drugs, and documentation conventions emerge continuously. Regular re-evaluation of system performance on recent documents is essential to detect performance degradation before it affects clinical use.
Fail-safe design: System failures must degrade gracefully. If the LLM API is unavailable, the system should fall back to regex + scispaCy extraction rather than blocking clinical workflow.
7.2 Local LLMs: On-Premises Deployment as a Privacy Solution
A natural and clinically important question arises from the privacy constraints discussed in Section 4: if sending clinical documents to a cloud API introduces GDPR/HIPAA compliance complexity, could deploying an LLM on an institutional server (entirely within the hospital’s own infrastructure) resolve these issues?
The answer is yes, in large measure, but with important technical and regulatory caveats that must be understood before committing to this architecture.
The Privacy Advantage of On-Premises LLMs
When an LLM runs on a server physically located within the hospital’s own data center or private cloud, clinical documents never leave the institutional perimeter. This eliminates the primary privacy risks associated with cloud API usage:
- No data transfer to third-party processors, removing GDPR Article 44-49 obligations regarding cross-border transfers
- No contractual Data Processing Agreement required with an external vendor
- No risk of patient data being used for model training by a third party
- Full institutional control over data retention, access logging, and deletion policies
- Alignment with the data residency requirements increasingly mandated by national healthcare regulations (e.g., Italy’s Codice Privacy and AGENAS guidelines on health data sovereignty)
In practice, this means that on-premises LLM deployment can make de-identification before inference optional rather than mandatory, since the data never leaves the environment where it is already authorized to reside. This is a significant operational simplification, as de-identification pipelines (Section 4) introduce their own risks of information loss and require ongoing validation.
Available Open-Source Models for Clinical Use
The open-source LLM ecosystem has matured substantially and now includes models specifically oriented toward biomedical and clinical applications.
General-purpose models suitable for clinical NLP:
- Llama 3.1 / Llama 3.3 (Meta AI): state-of-the-art open-source models with strong reasoning capabilities; the 70B parameter version approaches GPT-4 performance on many clinical reasoning benchmarks
- Mistral 7B / Mixtral 8x7B (Mistral AI): excellent performance-to-compute ratio; the Mixtral mixture-of-experts architecture delivers strong results with lower inference cost than comparably-performing dense models
Biomedical fine-tuned models:
- BioMistral (Labrak et al., 2024): Mistral 7B fine-tuned on PubMed Central and MIMIC-III clinical notes; demonstrates improved performance on biomedical NER, relation extraction, and clinical question answering compared to the base model
- Meditron (EPFL, Chen et al., 2023): Llama 2 fine-tuned on a curated corpus of PubMed abstracts, medical textbooks, and clinical practice guidelines; specifically designed for guideline-adherent clinical reasoning
- ClinicalCamel: fine-tuned on clinical conversation datasets; optimized for patient-provider dialogue rather than document processing
- OpenBioLLM (Saama AI Research): fine-tuned on diverse biomedical datasets with strong performance on clinical entity extraction tasks
For the specific use case of this series (extraction from cardiac surgery discharge summaries), BioMistral or a Llama 3.1 70B base model with a well-engineered system prompt are the most appropriate starting points as of early 2026. The former benefits from clinical domain adaptation; the latter offers superior general reasoning for complex inference tasks such as guideline comparison. That said, the right choice ultimately depends on the institution’s GPU resources and the acceptable latency threshold.
Infrastructure Requirements
On-premises LLM deployment is not without cost. The computational requirements are substantial:
| Model size | GPU VRAM required | Suitable hardware | Approximate throughput |
|---|---|---|---|
| 7B parameters (fp16) | ~14 GB | Single NVIDIA A100 40GB | ~50 documents/min |
| 13B parameters (fp16) | ~26 GB | Single A100 80GB | ~30 documents/min |
| 70B parameters (fp16) | ~140 GB | 2x A100 80GB | ~8 documents/min |
| 70B parameters (4-bit quantized) | ~35 GB | Single A100 80GB | ~20 documents/min |
Note: The figures above are indicative only; real throughput depends on document length, batching, quantization, context window, and the serving stack (e.g., vLLM vs. llama.cpp) as well as the specific GPU model and configuration.
For most hospital settings, 4-bit quantization (using libraries such as bitsandbytes or llama.cpp) offers a practical compromise: a 70B model quantized to 4 bits fits on a single high-end GPU with performance degradation of approximately 2-5% on clinical benchmarks relative to the full-precision version.
The deployment stack for an institutional LLM server typically consists of the model weights (downloaded once from Hugging Face or a private registry), an inference server (vLLM or Ollama are the current standards for production throughput), and an API layer that exposes an OpenAI-compatible endpoint, allowing existing code written against the Anthropic or OpenAI API to switch to the local model by changing a single endpoint URL.
# Switching from Claude API to a local LLM server requires
# minimal code changes when the local server exposes an
# OpenAI-compatible endpoint (as vLLM and Ollama do)
# Original: Anthropic Claude API
# client = anthropic.Anthropic()
# response = client.messages.create(model="claude-opus-4-6", ...)
# Local LLM server (vLLM serving BioMistral or Llama 3)
from openai import OpenAI
local_client = OpenAI(
base_url="<http://your-hospital-llm-server:8000/v1>",
api_key="not-required-for-local"
)
response = local_client.chat.completions.create(
model="BioMistral-7B",
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_message}
],
temperature=0.0,
max_tokens=2048
)
extracted_text = response.choices[0].message.content
Important Caveats: Privacy Is Necessary But Not Sufficient
On-premises deployment resolves the data transfer dimension of compliance, but several obligations remain regardless of where the model runs.
Validation requirements are unchanged. A local LLM requires the same rigorous clinical validation as a cloud model. The fact that data stays on-site does not make the model’s outputs more reliable. Hallucination rates, extraction accuracy, and complication detection sensitivity must be measured on institution-specific test sets before clinical use.
Audit and logging obligations persist. GDPR and national healthcare regulations require that every automated processing of health data be documented, with identifiable records of who authorized the processing, when it occurred, and what decisions were made based on it. This applies equally to on-premises systems.
Security of the server itself. “On-premises” and “secure” are not synonyms. The LLM inference server must be integrated into the hospital’s information security framework: network segmentation, access controls, intrusion detection, and patch management. A poorly secured on-premises GPU server may represent a greater risk than a well-managed cloud API.
Performance gap relative to frontier models. As of early 2026, the best open-source models (Llama 3.1 70B, Mixtral 8x7B) remain below GPT-4 and Claude Opus on complex clinical reasoning tasks, particularly guideline comparison and multi-step inference. For straightforward extraction tasks (Section 3.2), the gap is small and often acceptable. For tasks requiring nuanced clinical judgment, the performance difference should be empirically measured on the target task before choosing local deployment over a cloud API with appropriate safeguards.
The privacy-performance tradeoff is real and context-dependent. The optimal architecture depends on the specific task, the sensitivity of the documents, the institutional IT capabilities, and the acceptable performance floor. A pragmatic approach adopted by several academic medical centers is a tiered system: de-identified documents processed via cloud API for maximum performance; identified documents processed by a local model for maximum privacy; with de-identification quality itself validated to determine when the cloud tier is safe to use.
8. Conclusion: The Complete NLP Landscape for Medical Text
This three-part series has traced a complete progression through the methodological landscape of clinical NLP, from character-level pattern matching to AI-powered clinical reasoning. The progression is not merely technical. It reflects a deepening of what “understanding language” means computationally.
Regular expressions (Article 1) encode understanding as explicit human-designed rules. They are precise, fast, explainable, and appropriate for structured fields in consistent formats. They cannot generalize beyond their patterns and require constant maintenance as documentation conventions change.
spaCy and scispaCy (Article 2) encode understanding as statistical models of linguistic structure. They recognize medical concepts regardless of surface form, detect grammatical relationships between entities, and link terms to standardized vocabularies. They require labeled training data for new domains and struggle with documentation-specific language patterns.
Machine learning classifiers (this article, Section 2) encode understanding as learned associations between text features and clinical outcomes. They are interpretable, computationally efficient, and appropriate for well-defined classification tasks with sufficient annotated training data.
Large Language Models (this article, Section 3) encode understanding as distributed representations of language structure, semantics, and world knowledge. They can perform complex clinical inference, guideline comparison, and reasoning from context, capabilities that no rule-based or feature-engineering approach can replicate. They introduce new risks: hallucination, non-determinism, and limited interpretability that require careful validation before clinical deployment.
The ideal clinical NLP system combines all paradigms strategically: regex for structured fields, scispaCy for entity recognition and normalization, classical ML for classification with interpretable explanations, and LLMs for complex semantic tasks requiring clinical reasoning, all integrated in a validated, audited, privacy-compliant pipeline.
The tools and code patterns presented across this series provide a foundation for building such systems. The next step, as with any medical technology, is rigorous validation on real clinical data before any patient care application.
References
- Mikolov T, et al. “Efficient Estimation of Word Representations in Vector Space.” arXiv 2013:1301.3781.
- Devlin J, et al. “BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding.” NAACL-HLT 2019:4171-4186.
- Rasmy L, et al. “Med-BERT: pretrained contextualized embeddings on large-scale structured electronic health records for disease prediction.” NPJ Digital Medicine 2021;4(1):86.
- Singhal K, et al. “Large language models encode clinical knowledge.” Nature 2023;620:172-180.
- Shickel B, et al. “Deep EHR: A Survey of Recent Advances in Deep Learning Techniques for Electronic Health Record (EHR) Analysis.” IEEE Journal of Biomedical and Health Informatics 2018;22(5):1589-1604.
- Uzuner O, et al. “Evaluating the state-of-the-art in automatic de-identification.” JAMIA 2007;14(5):550-563.
- Yang X, et al. “A large language model for electronic health records.” NPJ Digital Medicine 2022;5(1):194.
- Agrawal M, et al. “Large language models are few-shot clinical information extractors.” EMNLP 2022.
- Lyu Q, et al. “Translating Radiology Reports into Plain Language using ChatGPT and GPT-4.” arXiv 2023:2303.09038.
- Salinas Alvarado MA, et al. “A Systematic Review of Natural Language Processing in Clinical Medicine.” ACM Computing Surveys 2023.
- European Parliament. “General Data Protection Regulation (GDPR).” Official Journal of the European Union 2016:L119/1.
- U.S. Department of Health and Human Services. “Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.” 45 CFR Parts 160 and 164, 2002.
- Labrak Y, et al. “BioMistral: A Collection of Open-Source Pretrained Large Language Models for Medical Domains.” arXiv 2024:2402.10373.
- Chen Z, et al. “MEDITRON-70B: Scaling Medical Pretraining for Large Language Models.” arXiv 2023:2311.16079.
- Touvron H, et al. “Llama 2: Open Foundation and Fine-Tuned Chat Models.” arXiv 2023:2307.09288.
- Kwon W, et al. “Efficient Memory Management for Large Language Model Serving with PagedAttention.” SOSP 2023. [vLLM]
- Jiang AQ, et al. “Mixtral of Experts.” arXiv 2024:2401.04088.