Which Open Medical AI Models Can You Actually Deploy in a Clinic?

Our answer  — All of them, and none of them — depending on what you do next. Every major open medical model, including MedGemma, MeditronFO and Meditron-3, carries an explicit disclaimer that its developers have not validated it for clinical use.That does not prevent you from building a healthcare product on one. It means the validation burden transfers entirely to you, and regulators in all three major markets treat you, not the model publisher, as the manufacturer.

---

The question most stack pages skip

Search for open medical LLM comparisons and you will find benchmark tables — MedQA, MedMCQA, MedXpertQA, parameter counts, throughput. Useful engineering information, and almost entirely beside the point for anyone deploying into a clinical environment.

Over 50 LLMs now claim medical capabilities, but researchers have rigorously validated fewer than a dozen on clinical benchmarks. Marketing claims blur into research results.

Three questions determine whether a model is deployable. 

Benchmarks answer none of them.

1. What does the licence permit commercially? Open weights and open licence are not the same thing. Several of the best-performing medical models carry gated or restricted licences.
   
2. What does the publisher say about clinical use? This is the one that catches teams late. Every major open medical model states, in its own documentation, that its developers have not validated it for clinical use.Not one is an off-the-shelf clinical component.
   
3. Can you audit how someone built it? Nobody could answer this third question usefully until May 2026.It does now, and for regulated deployment it may matter more than the first two.

---

The distinction that changed in May 2026: open weight is not fully open

Almost every model marketed as “open” in healthcare is open-weight. The developers publish the parameters; they do not publish the data provenance, curation procedures and generation pipelines that determine model behaviour.

For a research team that is a nuisance. For anyone assembling a clinical safety case it is a structural problem, because you cannot document the provenance of a system whose training data you have never seen.

Fully Open models expose the complete training stack end to end. Until May 2026 none existed in medicine.

MeditronFO changed that. Published by EPFL’s Laboratory for Intelligent Global Health & Humanitarian Response Technologies, it comprises a clinician-audited training corpus, a reproducible data construction and training framework, and a use-aligned evaluation protocol. All code — data preparation, decontamination, training, evaluation — plus corpus provenance and hardware logs are under open licence. Decontamination logs justify each sample removal. Synthetic examples are traceable to their prompts, seed exemplars and teacher outputs, with full rejection sampling history.

Researchers used the framework to “medicalise” several fully open base models including OLMo, EuroLLM and Apertus, the Swiss model developed by EPFL and ETH Zurich.

Two things make it more than an academic curiosity.

The performance is competitive, not compromised. LLM-as-a-judge evaluators prefer Gemma-3-27B-MeditronFO over MedGemma-27B in 58.6% of pairwise evaluations, and it outperforms MedGemma-27B on HealthBench, 58% against 55.9%.OLMo-2-32B-MeditronFO gained 1.7 percentage points on medical average (51.5% to 53.2%); EuroLLM-22B-MeditronFO gained 0.66 points.

Clinicians were participants, not consumers. Through MOOVE (Massive Open Online Validation and Evaluations), clinicians contribute throughout — curating training data, validating outputs, flagging safety concerns, auditing training material.

Note: what this does and does not solve. 

It does not remove the clinical-use disclaimer, and it does not validate someone else’s job. What it does is make the pipeline inspectable, which is the difference between a safety case that rests on a vendor’s assurance and one that rests on evidence you can examine yourself.

---

The models compared

Model	Params	Licence	Openness	Publisher’s clinical status	Practical use
MedGemma 1.5	4B multimodal	HAI-DEF terms (gated)	Open weight	“Isn’t yet clinical-grade”	Best open multimodality per parameter; ~91% MedQA
MedGemma 1	4B; 27B	HAI-DEF terms (gated)	Open weight	Same	27B for text-heavy workloads
MeditronFO	Varies by base (OLMo-2-32B, EuroLLM-22B, Gemma-3-27B)	Open (pipeline and weights)	Fully open	Research pipeline; not a validated clinical device	Auditable deployments; regulated environments
Meditron-3	8B, 70B	Llama 3.1 Community	Open weight	Research-only; not validated for medical use	Base model for adaptation; not instruction-tuned
gpt-oss-120b	~117B total (MoE)	Apache 2.0	Open weight	General-purpose	Best self-hostable clinical text reasoning; one 80GB GPU
gpt-oss-20b	~21B total, ~3.6B active	Apache 2.0	Open weight	General-purpose	Orchestration; workstation-budget pilots; 128k context
Baichuan-M2-32B	32B	Open weight	Open weight	Medical-tuned	Medical alternative on lighter hardware
II-Medical-8B	8B	Open weight	Open weight	Research	Severely resource-constrained deployments
BioMistral	7B	Apache 2.0	Open weight	Research/biomedical	Licence simplicity; now benchmark-trailing
Whisper large-v3 / v3-turbo	1.55B	MIT	Open weight	OpenAI advises against high-risk domains	ASR; requires hallucination mitigation
MedASR	105M	HAI-DEF terms	Open weight	Foundational model for fine-tuning	58% relative WER reduction vs Whisper Large-v3

---

What each model is genuinely good for

MedGemma — the strongest general-purpose starting point

Google’s Health AI Developer Foundations programme publishes MedGemma, a collection of Gemma 3 variants trained for medical text and image comprehension. MedGemma 1 offers a 4B multimodal variant and 27B text-only and multimodal variants. Google released MedGemma 1.5 on 13 January 2026 as a 4B multimodal instruction-tuned model with improved medical reasoning, medical records interpretation and image interpretation.

Google reports MedGemma 1.5 at approximately 91% on MedQA, surpassing Med-PaLM 2’s 86.5% from 2023. On internal benchmarks it reached 61% accuracy on CT disease classification against 58% for MedGemma 1, and 65% on MRI disease finding against 51%.

Note the absolute imaging numbers rather than the deltas. Figures in the low-to-mid sixties are exactly why Google’s own guidance says the model “isn’t yet clinical-grade and will likely require further fine-tuning.”

For medical imaging plus text — X-ray, CT, pathology, EHR — nothing else open comes close on multimodality per parameter.

Two constraints before committing. Users must accept the HAI-DEF terms of use to gain access; this is not Apache 2.0 and needs a licensing review rather than an assumption. And Google flags that it has not evaluated or optimised MedGemma for multi-turn applications, and that MedGemma may be more sensitive to specific prompts than base Gemma 3.

Google also raises a caveat most publishers omit: data contamination. A model of this size may have encountered related medical content during pre-training, potentially overstating its ability to generalise. Google’s recommendation is to validate on datasets not publicly available. That is a meaningful cost line in any evaluation plan.

MeditronFO — the auditable option

Choose it when your deployment sits in a regulated environment where you will need to evidence training provenance, or where an ethics committee, notified body or internal governance function will ask questions that “the vendor says it is fine” does not answer.

Do not choose it expecting a validated clinical component. It is a research pipeline that produces auditable models. The clinical-use burden is unchanged.

Watch for the practical cost of auditability. Having the decontamination logs is only valuable if someone on your team reads them, and that is a real line in the evaluation budget.

Meditron-3 — powerful, and explicitly not for clinical use

Meditron is a suite of clinical LLMs from the OpenMeditron initiative, co-designed with clinicians and humanitarian practitioners, with deliberate emphasis on limited-resource and humanitarian settings, neglected populations and diseases. The Meditron-3 collection spans seven models built on four different base model families: Meditron3-70B and Meditron3-8B (trained on Llama 3.1 base models), Meditron3-Qwen2.5-7B and Meditron3-Qwen2.5-14B (built on Qwen2.5), Meditron3-Phi4-14B (built on Phi-4), and Meditron3-Gemma2-2B and Meditron3-Gemma2-9B (built on Gemma2).

The model card is unusually direct. The model card describes Meditron-3 as “a research-only model to study and evaluate the potential of LLMs in enhancing clinical decision-making,” and under direct use, it states: “Meditron-3 is a research-only model. It is not validated for medical use.” The disclaimer states in capitals that developers do not intend the information for clinical decision-making and do not intend it for use in the diagnosis or treatment of patients.

The earlier Meditron documentation puts the reasoning plainly: while designed to encode medical knowledge from high-quality evidence, it “is not yet adapted to deliver this knowledge appropriately, safely, or within professional actionable constraints,” with a recommendation against deployment in medical applications without extensive use-case alignment and additional testing, specifically including randomised controlled trials in real-world practice settings.

One practical detail that catches teams: Meditron-3 models have not been fine-tuned or instruction-tuned. They are foundation models intended for downstream adaptation via RLHF, DPO or similar. A team expecting instruction-following behaviour out of the box will find the model does not behave as they assumed. This remains true as of August 2026 — no instruction-tuned variant has been released.

Licensing varies by base model and is worth checking carefully before use. The Llama 3.1-based models (70B and 8B) carry the Llama 3.1 Community License, which has its own conditions and is not equivalent to Apache 2.0. The Qwen2.5-based variants (7B and 14B), by contrast, are released under Apache 2.0. Teams evaluating Meditron-3 for downstream adaptation should check the specific licence attached to whichever base model they pick, since the collection isn’t licensed uniformly.

The gpt-oss family — the workhorses

gpt-oss models are not medical, and that is the point. General-purpose open-weight reasoning models under Apache 2.0, built as mixtures of experts.

gpt-oss-120b is the best text-based clinical reasoning you can self-host, and it runs on a single 80GB GPU. Where the task is reasoning over clinical text rather than interpreting images, it is frequently the stronger choice over a medical-specific model — a conclusion that surprises teams who assume domain tuning always wins.

gpt-oss-20b has roughly 21B total parameters with only about 3.6B active at inference, and a 128k context window. A deployment-focused evaluation found it delivered roughly 31.8% higher decode throughput and about 31.7% lower peak VRAM than a comparable dense 32B model, precisely because so few parameters are active per token. On a single GPU in a clinic server room, that is the difference between viable and not.

OpenAI positions these for agentic workflows with instruction following, tool use and adjustable reasoning effort, and notes explicitly that they enable deployment on-premises or in private clouds where data security and privacy requirements are strict.

In practice: a good orchestration and reasoning layer, with medical-specific models called for tasks that need domain knowledge.

The lighter medical options

Baichuan-M2-32B is a medical-tuned alternative for lighter hardware than gpt-oss-120b requires. Worth noting that its headline benchmark score is self-reported and has not been independently reproduced.

II-Medical-8B is an 8B reasoning model that punches above its weight, and is the reasonable choice for severely resource-constrained deployments.

MedGemma 4B and gpt-oss-20b both run on hardware your IT department already owns, which makes them the sensible pilot pair before anyone buys a GPU server.

BioMistral — and a correction to our previous position

BioMistral is a 7B open model built on Mistral with continued pretraining on PubMed Central open-access text, supporting multilingual biomedical question answering, released under Apache 2.0.

Version 1 of this article recommended it more warmly than the current evidence supports. The 2023–24 wave of small medical fine-tunes — Meditron, OpenBioLLM, BioMistral, PMC-LLaMA — has largely been overtaken by frontier generalists and large reasoning models. The 2026 fully-open Meditron replication put it plainly: the small medical specialists now trail even general-purpose Qwen2.5-32B on aggregate medical benchmarks.

They still matter in two niches. Fully-auditable pipelines where every training token must be documented, and severely resource-constrained deployments.

If you are starting fresh in 2026, start elsewhere. BioMistral’s Apache 2.0 licence remains genuinely useful where licence simplicity outweighs capability — and if your model becomes part of an FDA- or Health Canada-regulated device, the licence also has to survive your regulatory documentation and change-control plan. Apache 2.0 and MIT make that conversation short.

Whisper — the one that needs the most care

Whisper large-v3 and v3-turbo remain the most widely adopted open ASR models, MIT-licensed, and genuinely strong at general transcription. No v4 exists as of August 2026. They also have a documented failure mode unusually badly matched to clinical audio.

OpenAI trained Whisper on around 680,000 hours of weakly supervised internet audio. Because the training process did not manually curate that data, it sometimes paired segments with no meaningful speech with arbitrary text, teaching the model to produce fluent output for non-speech input. The result is that Whisper generates coherent but entirely fabricated transcription when given silence, background noise or music.

The peer-reviewed picture, from Koenecke et al., presented at ACM FAccT 2024:

• Audio from Carnegie Mellon’s AphasiaBank was split into 13,140 ten-second segments. 187 contained hallucinations — approximately 1% of cases.
• Rates were 1.7% for speakers with aphasia against 1.2% for speakers without.
• Around 38–40% of hallucinations were judged harmful, with roughly half of the concerning ones alluding to violence, sexual innuendo or demographic stereotypes.
• Documented fabrications included an invented medication, “hyperactivated antibiotics,” and unprompted racial commentary inserted into a neutral transcript.
• The researchers did not observe the same behaviour in commercial ASR from Google, Amazon, AssemblyAI or RevAI.

Conflicting figures, disclosed rather than resolved. The ~1% rate comes from controlled ten-second clinical segments. A University of Michigan researcher reported hallucinations in eight of every ten transcriptions of public meeting audio, and a developer reported them in almost every one of 26,000 generated transcripts. Those are not the same measurement — different audio, different segment lengths, different definitions of a hallucination. The honest summary is that the rate is highly sensitive to audio conditions, and consultation audio, with its natural pauses, sits toward the bad end.

There is a further environmental factor worth knowing. Benchmarking published in February 2026 found reverberation consistently degrades Whisper performance across all model sizes, with the WER penalty ranging from 2.31 to 15.50 percentage points depending on model. Large-v3 showed the smallest penalty; tiny the largest. Consulting rooms are hard-surfaced, often small, and frequently reverberant.

Three things follow for anyone building clinical documentation on Whisper.

OpenAI’s own position is a design input. Its disclosures recommend against using Whisper in decision-making contexts where accuracy flaws lead to outcome flaws, and against high-risk domains. Deploying it anyway is a defensible engineering decision, but only if the team documents the mitigations — and that documentation is what a DCB0129 clinical safety case or a TGA risk file will ask for.

Voice activity detection is not optional. Since silence is a primary trigger, VAD preprocessing plus hallucination filtering measurably reduces error. Published work on filtering approaches makes the goal explicit: avoiding catastrophic outputs rather than marginal accuracy gains.

Never delete the source audio. One widely deployed clinical scribe erases original recordings for stated data-safety reasons, which makes its transcripts impossible to verify against ground truth. A former OpenAI engineer’s assessment of that design was blunt: you cannot catch errors if you remove the ground truth. Retention has its own privacy cost, and that trade-off belongs in the DPIA — but it should be a decision, not a default.

MedASR — now with published evidence

MedASR is a foundational speech-to-text model published by Google under Health AI Developer Foundations, pre-trained on 5,000 hours of clinical audio, designed to be fine-tuned for specialised contexts and paired with models like MedGemma to automate clinical documentation.

This has moved from promotional claim to published paper since version 1 of this article. A preprint submitted to Interspeech (arXiv 2605.16555, 15 May 2026) describes a 105M-parameter Conformer architecture achieving a 58% relative WER reduction on Eye Gaze compared to Whisper Large-v3, while enabling on-device deployment and pseudo-streaming inference.

Two caveats on the numbers. A separate promotional figure of “4.6% WER on radiology dictation, outperforming Whisper v3 Large by 5x” circulates on a MedASR marketing page; it is a different benchmark from the peer-reviewable Eye Gaze figure and we would not put it in a business case. And at 105M parameters against Whisper’s 1.55B, MedASR is roughly fifteen times smaller — which is an argument for on-device deployment as much as accuracy.

Clinical-domain pretraining is the direct answer to Whisper’s internet-derived priors. Evaluate it head to head against Whisper on your own audio, particularly for accented speech and disfluency, rather than assuming either wins.

---

The point nobody makes: you are the manufacturer

Here is where model selection stops being an engineering question.

Every model above disclaims clinical validation — including MeditronFO. It is tempting to read those disclaimers as the publisher’s problem, a legal formality attached to someone else’s software. Regulators read them the opposite way.

The TGA’s February 2026 guidance addresses this directly: if you incorporate a large language model into a product with a medical purpose, you are the manufacturer and carry full regulatory responsibility — not OpenAI, not Google, not EPFL, not the foundation model provider. The same logic runs through the MHRA and FDA frameworks, both of which assign obligations to whoever places the product on the market under a stated intended purpose.

So the disclaimers are not a warning that these models are unusually risky. They are an accurate description of an allocation that would apply anyway. The publisher validated nothing for your use case; you will.

Which turns “which model is best?” into a much more tractable question: what does your intended purpose require you to validate, and which model gives you the shortest path to validating it? A model that scores three points lower on MedQA but ships with a permissive licence, predictable behaviour and an auditable training pipeline may be the faster route to a defensible product.

That last clause is new in this version, and it is the practical consequence of MeditronFO existing. Auditability is now a variable you can trade against raw capability. Twelve months ago it was not.

If your product’s intended purpose keeps it outside device regulation entirely — transcription, summarisation, drafting for clinician review — the validation burden is lighter but does not vanish. NHS England expects suppliers to detail guardrails and intended use precisely because a generative product can be prompted beyond its stated purpose.

---

Why the deployment model is a compliance decision

There are two ways to run AI in a healthcare product, and the choice is not primarily technical.

Cloud API — Claude, GPT, Gemini. Strongest general capability, no infrastructure burden, fastest to build. Requires that patient data may lawfully leave your infrastructure and reach a third-party processor, with appropriate contractual cover.

Self-hosted open weights — MedGemma, MeditronFO, gpt-oss, served on-premise or in a private cloud. Lower ceiling on raw capability, real infrastructure cost, more validation work. No patient data transmitted to a third-party API.

The determining factors are usually data residency requirements, NHS Data Security and Protection Toolkit obligations, jurisdictional data protection rules, and internal information governance policy — none of which are engineering decisions and all of which vary by organisation.

This is why we do not open engagements with a recommendation. The team establishes which model applies during the Discovery Workshop against the actual compliance environment, because getting it wrong in either direction is expensive: an unnecessary on-premise deployment burns budget and caps capability, while a cloud deployment that breaches data residency creates a governance incident.

And frequently the honest answer is cloud. A clinic with no data residency constraint, operating in a jurisdiction that permits third-party processing under a signed agreement, generally gets a better product faster from a cloud API. On-premise is a response to a constraint, not a virtue.

---

The architecture that makes the choice reversible

If the deployment model depends on compliance context, and compliance context varies per engagement, then hard-coding a model provider is a design error.

We build our stack accordingly:

• Backend — Python (FastAPI) and Node.js.
• Frontend — React.
• Deployment — AWS, GCP, Azure or Render, chosen per engagement.
• Orchestration — LangChain and LangGraph, model-agnostic by design.
• Integration — API-first, HL7 and FHIR.

The property that matters is the fourth. The same workflow runs against a cloud API or a locally hosted model without a rebuild. When an organisation’s governance position changes — and it does, particularly as DSPT requirements and internal policy evolve — the model swaps and the workflow survives.

That is a hedge against a specific and common failure: a product architected around one provider’s API, then required to move on-premise, then effectively rewritten. The rewrite is not the expensive part. Re-validating a rewritten clinical workflow is.

The arrival of MeditronFO makes this hedge more valuable, not less. A team that built model-agnostically in 2025 can evaluate a fully open pipeline in 2026 as a configuration change. A team that hard-coded one provider is looking at a rebuild to access an option that did not exist when they started.

One caution on orchestration frameworks generally. Multi-step agent workflows make the audit question harder, not easier, because an action may be several inferences removed from the human who authorised the sequence. Whatever framework you use, the audit trail needs to capture which step took which action under whose authority. We cover why in agentic AI regulation.

---

A model selection checklist

Seven questions, in the order that saves the most rework.

1. What is the intended purpose, in one sentence? This determines device classification, which determines the validation burden, which determines how much model capability you actually need.
   
2. Can patient data lawfully leave your infrastructure? Answer this before evaluating any model. It eliminates roughly half the options immediately.
   
3. What does the licence permit commercially? Apache 2.0 (gpt-oss, BioMistral) and MIT (Whisper) are straightforward. HAI-DEF terms (MedGemma, MedASR) and Llama Community Licences (Meditron-3) need review.
   
4. Will anyone need to audit how someone trained the model? If a notified body, ethics committee or internal governance function will ask, a fully open pipeline is worth real capability trade-off. If not, do not pay for auditability you will never use.
   
5. Is the model instruction-tuned? Meditron-3 is not. Building against a base model as though it were instruction-tuned is a common and costly assumption.
   
6. What is the documented failure mode, and how will you detect it? Whisper hallucinates on silence and degrades in reverberant rooms. Generative models produce content beyond intended purpose under user prompting. Teams know both, can mitigate both, and choosing a different model fixes neither.
   
7. What will you validate on, and does it exist yet? Google’s own contamination warning points at this: public benchmarks may overstate generalisation. Held-out data from your own environment is the only real answer, and assembling it is usually the longest lead time in the project.

---

The KastHunt view

The interesting thing about the current open medical model landscape is not that the models are weak. Several are strong, and MedGemma 1.5 in particular closed real ground in January.

It is that every one of them is honest about not being a clinical component, and the market discussion mostly ignores that in favour of benchmark tables. The gap between “scores well on MedQA” and “safe to put in front of a patient” is the entire engineering programme, and it does not appear in any comparison chart.

What has changed since we first published this is narrower than the news coverage suggests, and more important. MeditronFO does not make open models clinically validated. It makes one of them inspectable — and for anyone who has tried to write a clinical safety case around a model whose training data is a black box, that is the constraint that was actually binding.

Our own position follows from that, with one addition. Choose the model that minimises the distance to a defensible validation, not the one that tops a leaderboard. Keep the orchestration layer model-agnostic so a compliance change is a configuration change. Ask early whether anyone will need to audit the training pipeline, because that answer now changes the shortlist. And treat every publisher disclaimer as an accurate statement of where the work sits rather than a formality to click through — because when a regulator asks who validated this for clinical use, the honest answer is going to be you.

---

Frequently asked questions

Can you use open-source medical LLMs in a real clinical product? Yes, but every major open medical model states it is not validated for clinical use. That does not prohibit building on them; it means the validation burden sits with whoever places the product on the market. Regulators in the UK, US and Australia treat the product manufacturer, not the model publisher, as responsible.

What is the difference between an open-weight and a fully open model? An open-weight model publishes its parameters but withholds data provenance, curation procedures and generation pipelines. A fully open model publishes the complete training stack end to end. Until MeditronFO in May 2026, no fully open medical specialist model existed. The distinction matters for regulated deployment because you cannot document the provenance of training data you have never seen.

What is MeditronFO? Fully Open Meditron, published by EPFL in May 2026, is the first fully open pipeline for building clinical decision support LLMs. It comprises a clinician-audited training corpus, a reproducible data construction and training framework, and a use-aligned evaluation protocol, with all code, corpus provenance, decontamination logs and hardware logs under open licence.

Is MeditronFO better than MedGemma? On the published comparisons, LLM-as-a-judge evaluators prefer Gemma-3-27B-MeditronFO over MedGemma-27B in 58.6% of pairwise evaluations, and it scores 58% against 55.9% on HealthBench. But “better” depends on the task — MedGemma 1.5 remains substantially stronger on medical multimodality, and nothing open comes close to it on imaging per parameter. MeditronFO’s distinguishing property is auditability, not raw capability.

Is MedGemma free to use commercially? MedGemma is open-weight but not Apache-licensed. Google’s Health AI Developer Foundations terms of use govern its use, and Hugging Face requires users to accept those terms before granting access. Any commercial deployment should include a licence review rather than assuming permissive terms.

Is MedGemma ready for clinical use? Google states that MedGemma “isn’t yet clinical-grade and will likely require further fine-tuning.” It also warns of possible data contamination in benchmark evaluation and recommends validating on datasets not publicly available.

Can Meditron-3 be used in a medical product? Its model card states that Meditron-3 is a research-only model and that the developers have not validated it for medical use, and that they do not intend the information for clinical decision-making, diagnosis or treatment. Earlier Meditron documentation recommends against deployment without extensive use-case alignment and additional testing, specifically including randomised controlled trials in real-world settings.

Is Meditron-3 instruction-tuned?No. Meditron-3 models are foundation models; the developers have not fine-tuned or instruction-tuned them. The developers intend them for downstream adaptation using techniques such as RLHF or DPO. As of August 2026, no one has released an instruction-tuned variant.

Are the older medical fine-tunes like BioMistral still worth using? Largely superseded.Frontier generalists and large reasoning models have overtaken the 2023–24 wave of small medical fine-tunes — Meditron, OpenBioLLM, BioMistral, PMC-LLaMA — and a 2026 fully-open Meditron replication found they now trail even general-purpose Qwen2.5-32B on aggregate medical benchmarks. They remain relevant in two niches: fully-auditable pipelines, and severely resource-constrained deployments.

Which open medical models have permissive licences? gpt-oss-20b and gpt-oss-120b are Apache 2.0, BioMistral is Apache 2.0, and Whisper is MIT. Health AI Developer Foundations terms of use govern MedGemma and MedASR, and the Llama 3.1 Community License governs Meditron-3. If your model becomes part of an FDA- or Health Canada-regulated device, the licence has to survive your regulatory documentation and change-control plan — Apache 2.0 and MIT make that conversation short.

What is the best open model for clinical text reasoning I can self-host? gpt-oss-120b, running on a single 80GB GPU, is currently the strongest self-hostable option for text-based clinical reasoning. Baichuan-M2-32B is a medical-tuned alternative on lighter hardware, though its benchmark score is self-reported and not independently reproduced. For medical imaging plus text, MedGemma 1.5 has no open equal on multimodality per parameter.

Is Whisper safe for medical transcription? OpenAI’s own disclosures recommend against using Whisper in decision-making contexts where accuracy flaws lead to outcome flaws, and in high-risk domains. Research presented at ACM FAccT 2024 found fabricated content in roughly 1% of transcriptions, higher for speakers with aphasia, with around 38–40% of hallucinations judged harmful. It can be used with mitigation, but the mitigations must be documented.

Why does Whisper hallucinate? OpenAI trained it on roughly 680,000 hours of weakly supervised internet audio that no one manually curated. Because of that, the training pipeline sometimes paired segments with no meaningful speech with arbitrary text, teaching the model to produce fluent output for non-speech input. Silence, background noise and music are the main triggers — and pauses are a normal feature of clinical conversation.

Is there a Whisper v4? No. As of August 2026, large-v3 and large-v3-turbo remain the current releases. Benchmarking published in February 2026 also found reverberation degrades Whisper across all model sizes, with WER penalties from 2.31 to 15.50 percentage points — relevant because consulting rooms are frequently reverberant.

How do you reduce Whisper hallucinations in clinical audio? Voice activity detection preprocessing to remove non-speech segments, filtering of known hallucination phrases, and retaining source audio so transcripts can be verified against ground truth. Published work on these approaches frames the objective as avoiding catastrophic outputs rather than marginally improving word error rate.

What is MedASR and is it better than Whisper? MedASR is a 105M-parameter Conformer speech-to-text model published by Google under Health AI Developer Foundations, pre-trained on 5,000 hours of clinical audio. A preprint submitted to Interspeech reports a 58% relative WER reduction on Eye Gaze compared to Whisper Large-v3, while enabling on-device deployment. At roughly fifteen times smaller than Whisper Large-v3, it is also considerably cheaper to serve. Evaluate both on your own audio rather than assuming either wins.

Should we run AI on-premise or use a cloud API? It depends on whether patient data may lawfully leave your infrastructure — data residency requirements, NHS DSPT obligations, jurisdictional data protection law and internal governance policy determine that. Where no such constraint applies, a cloud API generally produces a better product faster. On-premise is a response to a constraint rather than an inherently safer choice.

Who is liable if an open model we deployed makes an error? The product manufacturer. The TGA’s guidance is explicit that incorporating a large language model into a product with a medical purpose makes you the manufacturer with full regulatory responsibility, not the foundation model provider. Publisher disclaimers describe this allocation rather than creating it.

Does using an open model avoid medical device regulation? No. Classification depends on the intended purpose of your product, not on which model powers it. All three regulators apply technology-agnostic tests based on what the software is intended to do.

What does model-agnostic architecture actually mean? That we separate the workflow layer from the model provider, so the same workflow can run against a cloud API or a locally hosted model without rebuilding. It matters because compliance context determines deployment model, and compliance context changes — and because new options like fully open pipelines arrive faster than most teams can rebuild their products.

---

Sources

Model cards and publisher documentation

• Google — MedGemma model card and MedGemma 1 model card, Health AI Developer Foundations
• Google — MedGemma overview and Health AI Developer Foundations blog (MedASR, MedGemma 1.5 release, 13 January 2026)
• OpenMeditron / EPFL — Meditron3-8B and Meditron3-70B model cards
• EPFL LLM Team — meditron-70b model card; epfLLM/meditron repository
• OpenAI — gpt-oss-120b and gpt-oss-20b model card (Apache 2.0)
• BioMistral — model documentation (Apache 2.0, PubMed Central pretraining)

Peer-reviewed and technical

• Theimer-Lienhard X et al. — Fully Open Meditron: An Auditable Pipeline for Clinical LLMs, arXiv 2605.16215, 15 May 2026 (v2, 29 May 2026)
• EPFL — EPFL launches the world’s first fully open medical LLMs, June 2026
• MedASR: An Open-Source Model for High-Accuracy Medical Dictation, arXiv 2605.16555, 15 May 2026 (submitted to Interspeech)
• Koenecke A et al. — Careless Whisper: Speech-to-Text Hallucination Harms, ACM Conference on Fairness, Accountability and Transparency, 2024
• Sellergren et al. — MedGemma technical report, arXiv 2507.05201, 2025
• Investigation of Whisper ASR Hallucinations Induced by Non-Speech Audio, arXiv 2501.11378
• GPT-OSS-20B: A Deployment-Centric Analysis, arXiv 2508.16700
• Goswami M — Whisper-RIR-Mega: A Paired Clean-Reverberant Speech Benchmark, arXiv 2603.02252, February 2026

Regulatory

• TGA — Artificial intelligence (AI) and medical device software regulation, 5 February 2026
• NHS England — Guidance on the use of AI-enabled ambient scribing products in health and care settings, Version 3, 29 July 2026

Reporting

• Science (AAAS) — AI transcription tools ‘hallucinate,’ too
• Healthcare Brew; Associated Press coverage of Whisper in clinical deployment

---