Yes, a medical device can potentially use a third-party large language model, but eligibility and adequate evidence depend on the finished product and the applicable assessment route. Buying model access does not transfer the manufacturer's responsibility to the model supplier, and a strong general benchmark does not validate a particular clinical workflow.
Scarlet discusses this possibility in its third-party LLM article published on 9 December 2025. That is a useful starting point for developers, not a promise that any application built around a commercial model will obtain certification. The regulatory and technical sources in this guide were checked on 13 October 2026.
The product is larger than the model
Consider a fictional tool that helps a specialist prepare a structured interpretation of a clinical record. The model is only one component. The system also selects information, retrieves documents, supplies instructions, determines what the user sees and controls whether any output can leave the review screen.
Changing one of those components could alter the meaning or consequences of the output without replacing the underlying model. An assessment therefore needs a description of the complete intended workflow, not just a model name and a provider's benchmark chart.
The MHRA's intended-purpose guidance makes the clinical task, users, population and setting central to the product description. Those boundaries should drive the architecture and evaluation, rather than being added after a broadly capable assistant has been built.
A fictional architecture with explicit responsibilities
The following is an editorial design example, not a certified architecture or a description of iatroX's implementation.
| Component | Proposed responsibility | Evidence question |
|---|---|---|
| Record selection | Establish the correct encounter and authorised inputs | Can patient and encounter context become mixed? |
| Retrieval | Supply relevant, current source material | Are important exceptions retained? |
| Model call | Produce a bounded draft from the supplied material | How does it behave with missing or conflicting information? |
| Output controls | Prevent unsupported actions and preserve review status | Can a draft escape through another interface? |
| Clinician review | Assess applicability and revise the proposal | Can users identify consequential errors? |
| Release and monitoring | Record the approved version and investigate concerns | Can an affected output be traced after a change? |
The table deliberately separates a model's capabilities from permissions. A model that can generate an instruction should not thereby gain authority to execute it. Likewise, a user interface that labels something a draft should have corresponding controls over release, not merely reassuring wording.
What the manufacturer needs to control
Control does not necessarily mean owning every component. It means understanding the dependency sufficiently to support the device's claims and manage the consequences of change. A proposed supplier register should identify the service used, the selected model or version arrangement, relevant configuration, support commitments and known limitations.
A founder should ask what the supplier can change, how notification works and whether the deployed version can be identified afterwards. The answer may differ between a fixed local component and an externally managed service. Neither architecture is automatically safer; each creates different responsibilities.
Scarlet's published discussion of third-party models identifies dependency risks including changes and availability. The practical response is not to claim complete control where it does not exist. It is to specify the remaining uncertainty, limit the product accordingly and establish a response when an assumption fails.
Evidence must concern the finished clinical task
A general medical knowledge score can be useful background. It cannot establish whether this application retrieves the right record, preserves uncertainty or helps its intended users make an appropriate decision.
The joint good machine learning practice principles emphasise representative evidence, appropriate testing and the human-AI team. An evaluation plan should therefore include the information actually available in the intended workflow, the expected users and the consequences of plausible failures.
For the fictional specialist tool, suitable proposed tests include a missing document, conflicting historical accounts, an ambiguous patient statement and a source that concerns a different population. The outcome should not be limited to whether the final prose looks plausible. Reviewers should assess which unsupported assumptions survive, what users notice and whether the workflow remains within its boundaries.
No results are claimed for these tests. They are a specification for evidence to generate before making stronger product claims.
Limited supplier disclosure is a problem to manage, not conceal
A manufacturer may not have access to every detail of a foundation model's training. That does not justify inventing assurances about representativeness, source rights or subgroup performance. Nor does it mean that testing the integrated product becomes pointless.
Document what is known, what is contractually supported and what remains uncertain. Then ask whether those gaps can be addressed through appropriate system evaluation and controls, whether they restrict the intended purpose, or whether they make the proposed dependency unsuitable.
The decision should be specific. A bounded drafting function and an autonomous treatment function would not reasonably require identical evidence merely because both call the same underlying model. Conversely, a narrow interface does not establish that the clinical consequences are narrow.
Plan for a model change before one arrives
Imagine that the fictional supplier announces a replacement model. It preserves the output format but changes how strongly it resolves conflicting information. A technical integration test might pass while the clinical behaviour changes materially.
The release process should compare the new system against the claims and failure modes already identified. It should consider retrieval, prompts, output controls and user interaction, not only the model endpoint. The joint predetermined change-control principles emphasise bounded modifications, evidence and lifecycle management; they are not permission for arbitrary future updates.
Whether a proposed change falls within an accepted plan or needs additional assessment depends on the applicable jurisdiction and arrangements. The manufacturer should establish that position rather than asking a hospital to infer it from a release note.
A fallback must preserve the product's limits
If the model service becomes unavailable, switching silently to a different model could invalidate assumptions about behaviour. Returning a less-supported answer as if nothing changed can also mislead the reviewer.
A proposed fallback might disable the affected function, keep unfinished work identifiable and direct staff to the established non-AI route. Another may use an already evaluated alternative within defined limits. The choice should be justified by evidence, not solely by a desire to maintain an uninterrupted interface.
For an English NHS deployment, this connects supplier development work with local responsibilities under DCB0129 and DCB0160. The hospital needs to know what will happen, who will be informed and how clinical work continues.
Certification readiness starts with an honest dependency story
The strongest submission is not one that pretends the manufacturer built everything. It is one that explains the finished device, the external dependencies, the evidence supporting its claims and the controls addressing what can go wrong.
As described on its Insights page on 13 October 2026, iatroX offers clinical safety and readiness support. That can help structure a product-level argument, but does not replace the assessor's independent decision or establish certification for iatroX itself.
Frequently asked questions
Does using a third-party LLM automatically prevent certification?
No, but the manufacturer must establish the appropriate route and adequate evidence for the finished device. Supplier dependence does not remove responsibility for the product's claims and controls.
Is a model's medical benchmark enough to validate an application?
No. The integrated workflow, intended users, information, safeguards and clinically important failure modes need relevant evaluation.
Can a certified product switch models whenever a better one appears?
A model change needs assessment through the applicable change process. A predefined plan, where accepted, covers specified modifications and conditions rather than unlimited substitution.