What Foundation Models Mean for Medicine

Foundation models change the unit of development. Instead of training a separate model from the beginning for each task, developers pretrain one model on broad data and adapt it through prompting, fine-tuning, retrieval, tools, or smaller task-specific components. The same base can support summarization, image interpretation, coding, risk estimation, or patient communication.

Reuse creates possibility, not clinical permission. Every intended use still has a population, input, and output. It has a user, setting, comparator, consequence, and failure mode. A general benchmark measures selected capabilities under test conditions. Clinical value depends on the complete versioned system and how people act on it.

What makes a model foundational#

Pretraining teaches a model patterns from a broad corpus before a narrow downstream task is specified. A language model learns statistical structure across text, a vision model learns representations from images, and other models learn from electrocardiograms, pathology slides, genomic sequences, longitudinal records, or paired text and images. The task comes later.

Adaptation can be lightweight. A prompt provides instructions and context without changing model weights. Retrieval supplies selected documents at runtime. Fine-tuning updates weights using task data. Tool use connects the model to calculators, databases, or workflow actions. A product may combine all four.

The term foundation points to reuse across applications, but it does not imply that the model understands medicine as a clinician does, that its training data are complete, or that every output has a traceable factual basis. It also does not specify model size. A smaller domain model can be foundational if it supports many downstream tasks. “Generalist medical AI”, the related research vision in which one system handles multiple data types and tasks with limited task-specific labeling, is a direction of development, not evidence that current products can safely perform open-ended clinical work.

A model is not the same as a product#

The base model is only one component. A clinical system includes prompts, system instructions, and retrieval indexes. It includes filters, user interface, and authentication. It includes data mappings, output formatting, and alert logic. It includes human review and the downstream action. Any component can change performance.

For example, a base model may summarize notes well in a curated test. A deployed summarizer can still fail because it receives truncated records, merges patients, mishandles copied text, omits recent results, or presents uncertain statements as verified facts, and interface placement may encourage you to accept the summary without opening the record.

Product claims must therefore name the task. “Assists qualified clinicians by drafting a discharge summary from specified chart sections for review” is testable. “Understands the patient” is not. The intended user, decision, and timing should be explicit. So should data sources and required verification. Validation of the base model is not automatically inherited by every product built on it. A well-controlled narrow application may still be useful even if the same model is unreliable for unrelated questions.

Benchmarks measure capability, not clinical benefit#

Benchmark datasets offer standardized comparisons, but their meaning depends on construction. Public test items may appear in training data. Multiple-choice formats can reward cue recognition rather than safe reasoning. Curated images can omit poor quality, rare disease, devices, or workflow artifacts.

Accuracy averaged across a dataset can hide asymmetric harm; a 95% score may include confident errors in the 5% where mistakes are most consequential, and the average will not tell you which 5%. It can also conceal subgroup gaps, low performance on uncommon cases, or failure when information is missing.

Benchmark performance often evaluates the model alone. Clinical performance involves a person using an interface under time pressure. Automation bias can make an incorrect suggestion more harmful than no suggestion: a plausible line on the screen, arriving while you are already behind, is one you are likelier to accept. At other times, a useful output may be ignored because it arrives late or creates extra work.

Patient outcomes require another link: the recommended action must itself improve care. Better note extraction may reduce workload without changing health outcomes, which can still be valuable. A diagnostic aid needs evidence not just of accuracy but of how it changes testing, treatment, delays, harms, and equity.

Generative outputs have distinctive failure modes#

Generative models produce plausible sequences, not database lookups guaranteed to be true. They can invent facts, citations, dates, measurements, or rationales. The confidence of the wording is a poor guide to whether the output is correct.

They are also sensitive to prompt phrasing, context order, irrelevant content, and hidden instructions embedded in documents. Long records can exceed context limits or dilute key facts. Repeated runs may differ. Updates to a hosted model can change behavior even when the application code does not.

Shortcut learning occurs when a model relies on site-specific markers, scanner patterns, note templates, or coding habits rather than the intended clinical signal. Data leakage occurs when target information, duplicates, future events, or test items enter training or evaluation. Both can create impressive but fragile results.

Bias can arise from who is represented, how labels were assigned, and which historical practices are encoded. A model can reproduce unequal referral, undertreatment, or documentation patterns. Group averages alone may miss intersectional or rare failure modes.

Retrieval helps, but it does not verify#

Retrieval-augmented generation connects a model to selected documents. It can improve currency, provide local policy, and make citations possible. Its performance depends on the indexed corpus, chunking, and search method. It depends on ranking, permissions, and update schedule.

A system may retrieve an outdated guideline, an irrelevant passage, or a document for the wrong population. It may omit a contraindication located elsewhere. The generator may then misstate a correctly retrieved source or combine incompatible recommendations.

Citations can be decorative rather than evidentiary. Evaluation should check whether each citation exists, supports the exact claim, matches the version and date, and was available to the model, and the clinician using the system should be able to open that source in context. Retrieval can also cross access boundaries if permissions are not enforced at query time, so sensitive records, internal policies, and licensed content need governance for indexing, retention, audit, and deletion.

Fine-tuning and prompting shift, not erase, risk#

Fine-tuning can improve style, terminology, or task behavior. It can also reduce performance elsewhere, reinforce label error, memorize sensitive examples, or create a false sense of specialization. The provenance, consent basis, representativeness, and quality of fine-tuning data matter.

Prompting can constrain format and require uncertainty statements. Guardrails can block some unsafe outputs. Yet prompts are software dependencies that deserve version control and adversarial testing. A safety instruction that works on ordinary inputs may fail with conflicting text or an unexpected language.

Human review is not a universal fix. A reviewer needs time, access to the source data, the domain skill to see the error, and a clear duty to verify; if outputs are usually correct, your vigilance can fall. If they are frequently wrong, the system creates workload rather than reducing it. The relevant question is not whether a human is somewhere in the loop. It is whether the workflow makes meaningful review possible before harm, defines accountability, and records what the user saw and changed.

Intended use determines the regulatory question#

In the United States, the label “AI” or “foundation model” does not determine whether software is a medical device. The specific software function, intended use, and claims matter. So do the users and the role in diagnosis, treatment, prevention, or clinical decision support.

FDA's final Clinical Decision Support Software guidance, issued in January 2026, explains criteria for certain functions that may fall outside the device definition, and among the considerations is whether a healthcare professional can review the basis for a recommendation rather than relying primarily on it. Patient- or caregiver-facing functions and device functions require separate analysis.

FDA's guidance on lifecycle management and marketing submissions for AI-enabled device software functions was still draft guidance from January 2025 as of this article's review date, and draft guidance describes current proposals, not binding final requirements. FDA also maintains a public list of authorized AI-enabled medical devices, but inclusion applies to a specific device and use, not to every use of its underlying model.

Regulation is only one floor. A non-device administrative tool can still create privacy, discrimination, security, billing, or safety risks. Health systems remain responsible for procurement, validation, access control, monitoring, and incident response under applicable law and policy.

Evidence should follow the intended use#

A credible evaluation starts with a locked version and a prespecified protocol. It defines eligible cases, source data, and reference standard. It defines comparator, missing-data handling, and primary outcomes. It defines subgroups and clinically meaningful performance thresholds.

Random train-test splitting is often insufficient when records from the same patient, institution, or time period appear in both sets; external testing across sites, devices, languages, and later calendar periods can reveal shift. Calibration matters for risk outputs; sensitivity and specificity alone do not tell you whether the predicted probabilities can be trusted.

TRIPOD+AI provides reporting guidance for prediction-model studies, including transparent description of data, methods, performance, and limitations. Reporting quality does not prove low bias, but it makes appraisal possible.

Early prospective evaluation can begin in silent mode, where outputs do not affect care. This tests data pipelines and local performance. A live study then evaluates human use, workflow, safety, and outcomes. DECIDE-AI offers guidance for reporting early-stage clinical evaluation of AI decision support.

Multimodal systems add integration risk#

A multimodal model may combine radiology, pathology, and notes. It may combine laboratory values, waveforms, and genomics. In theory, this resembles the way clinicians integrate evidence. In practice, each modality has its own missingness, timing, and scale. Each has its own quality and governance.

The system must know which image belongs to which patient and episode, whether a laboratory value was final, and whether a note describes current or historical disease, and contradictions need explicit handling. A model that silently privileges fluent text over a definitive test can synthesize the wrong conclusion.

Missing modality patterns can themselves be biased. The absence of a test may reflect access, clinician choice, or disease severity. Treating “not measured” as “normal” can systematically disadvantage groups with less complete data. Evaluation should include modality ablation, corrupted inputs, mismatched timing, unavailable data, and conflicting evidence. A smooth answer is not proof that the integration was sound.

Privacy, security, and provenance#

Clinical data may contain direct identifiers, rare combinations, family information, and sensitive inferences. De-identification reduces but does not eliminate reidentification risk. Sending data to an external model can create retention, location, subcontractor, and secondary-use questions.

Security testing must include prompt injection, data extraction, unauthorized tool calls, model or index tampering, and denial of service; least-privilege access and separation between suggestion and action reduce the blast radius of failure.

Training and retrieval content also raise copyright, licensing, consent, and provenance questions. A generated answer may blend sources without attribution. Documentation should state what data categories were used, under what authority, and which sources support clinical claims. Audit logs need to preserve model version, prompt or workflow version, retrieved materials, output, user action, and relevant timestamps while respecting privacy, because without versioned records nobody can reconstruct an incident reliably.

Monitoring after launch#

Performance can drift as populations, coding, devices, disease prevalence, and care pathways change. Vendor updates can create abrupt shifts. Monitoring should include data quality, missingness, and calibration. It should include error classes, subgroup performance, and use rates. It should include overrides, delays, complaints, and downstream outcomes.

Alert thresholds need owners and actions. A dashboard without an investigation pathway is observation, not governance. Teams should define when to pause use, revert a version, notify users, correct records, or report an incident.

Predetermined change-control plans can support managed modifications for authorized devices when applicable, but they do not turn every future change into an approved one: the authorized plan, device scope, and regulatory conditions govern.

Local monitoring cannot detect every rare harm quickly. Structured user reporting, periodic chart review, external evidence surveillance, and cross-site learning can complement automated metrics.

A disciplined adoption sequence#

Start with a bounded problem where a model has a plausible advantage and a safe failure path. Define what the system must never do. Compare it with the workflow you actually have, including time, cost, and burden, rather than with an imaginary error-free baseline.

Test offline, then prospectively without influencing care, then in a controlled live setting when justified. Include intended users and affected patients in design. Evaluate accessibility, language, contestability, and what happens when the model is wrong.

Scale only after evidence supports the next context. A model validated for drafting radiology impressions is not thereby validated for triage. A system tested at an academic center is not automatically safe in a small clinic. Every extension is a new claim with some degree of new uncertainty.

Foundation models may reduce the cost of building useful medical software and enable genuinely new forms of assistance. Their breadth also makes boundaries easy to blur. The safest interpretation is a specific one: name the versioned product, the task, the setting, the user, the evidence, and the control structure you are actually being offered, then judge that use on its own merits.

Sources#

1. Perspective on generalist medical artificial intelligence
2. FDA information on artificial intelligence-enabled medical devices
3. FDA final guidance on Clinical Decision Support Software
4. FDA draft guidance on AI-enabled device software lifecycle management
5. TRIPOD+AI reporting guideline
6. DECIDE-AI early clinical evaluation guideline

This article is educational and does not endorse a model, product, clinical use, or regulatory pathway.