Healthcare software will often benefit from several specialised components rather than asking one model to do every job. That does not mean more models are always better. A well-designed system might use one foundation model alongside retrieval, deterministic rules and human review; another might justify separate models for distinct tasks.
The architecture below is a proposed design framework, not a claim about an undisclosed Doctolib, OpenEvidence or iatroX implementation. Technical examples are grounded in public documentation checked on 15 October 2026.
The task is the starting point
Recognising speech, retrieving a source, interpreting a clinical question, checking a date and sending a message are different operations. A model that performs well on one should not automatically be selected for all of them.
A numerical comparison with explicit inputs may be best handled by ordinary code. A semantic judgement about whether a passage addresses a question may require a language model. A clinical recommendation requires appropriate information and evaluation beyond whether the output has the correct format.
The useful design question is not "which model is the smartest?" It is "which component can perform this defined task reliably, with understandable limits and an appropriate cost?"
A fictional consultation pipeline
Consider a fictional educational demonstration built from a synthetic consultation. A speech component produces a transcript. A separate process identifies speakers and preserves uncertainty. A retrieval service finds relevant guidance. A reasoning component drafts an explanation. Conventional software checks identifiers and prevents unapproved actions.
Each stage has a specific contract. The transcript is not proof that every clinically important question was asked. A retrieved passage is not proof that it supports the recommendation. A valid identifier is not proof that the clinical plan is appropriate.
The advantage of separating components is that each can be tested for its own job. The disadvantage is that errors and assumptions can travel between them. A modular diagram does not create reliability by itself.
Routing needs evidence too
A routing component decides which model or tool should handle a request. It can improve efficiency when simple tasks do not need an expensive, slower model. It can also send a complex task to an unsuitable component.
A proposed routing evaluation should include ambiguous requests, mixed administrative and clinical content, missing information and tasks outside the product's intended scope. The fallback should not simply be "ask a bigger model" if the real problem is absent information or lack of authority.
Routing decisions should be recorded with enough context to investigate errors. Otherwise, a supplier may know that the final output failed without understanding why the request reached the wrong component.
Deterministic rules are not obsolete
A model's flexibility is useful when language is variable. It is less compelling when the rule is explicit and the inputs can be checked. Date ordering, exact identifier matching and arithmetic should not become probabilistic merely because an AI platform is available.
The distinction also applies to permissions. The NCSC's December 2025 prompt-injection discussion explains why external content cannot safely be treated as a trusted instruction channel. A model should not decide that a persuasive document grants it a new right to send information or change a record.
A proposed clinical system can use a model to interpret a request while relying on conventional controls to enforce the permitted action. The model's confidence should not override those controls.
Evidence retrieval is a component, not an accuracy guarantee
Retrieval can supply relevant source material, but the system can still choose the wrong document, miss a qualification or combine passages into an unsupported conclusion. The test must therefore include the relationship between the retrieved text and the final claim.
iatroX publishes this comparison of system designs and includes its own reference approach, which must meet the same evidential standard. As described for September 2026, iatroX's methodology includes retrieval, ranking, citation grounding and checks. That illustrates a multi-stage reference design. It is not a disclosure that iatroX uses every component proposed here or proof that its answers are always correct.
The same scrutiny applies to other clinical products. A claim that a model is "grounded" should lead to questions about source selection, freshness, applicability and what happens when the necessary evidence is missing.
Several models can repeat one mistake
Suppose the transcript incorrectly attributes a family member's history to the fictional patient. A retrieval model, a reasoning model and a checking model may all produce internally consistent outputs from that mistaken premise.
Agreement is then not independent corroboration. The useful check needs access to the original evidence and a task designed to question the attribution. A second model that only sees the first model's summary may have no opportunity to identify the error.
This is why system evaluation cannot be replaced by adding component accuracy percentages together. Dependencies matter. A workflow can fail at the boundary between individually capable components, and a rare early error can have several downstream consequences.
Change management becomes a graph of dependencies
A model update can change what a downstream component receives. A prompt revision can alter terminology. A retrieval change can expose different evidence. A new schema can cause a previously valid output to be misinterpreted.
A proposed version register should connect each component to the tasks and evaluations that depend on it. Testing should examine both the changed component and the relevant handovers. A supplier should not assume that because a new model performs better on a general benchmark, the complete clinical workflow is unchanged or improved.
The MHRA's intended-purpose guidance provides a useful boundary for the product being assessed. The finished system and its claimed role matter, not merely the reputation of an upstream model.
Latency and cost should be measured at workflow level
A fast classifier may reduce processing time while increasing human review because its decisions are harder to interpret. A slower model may be acceptable for a background evidence task but unsuitable for an interactive consultation.
The appropriate comparison includes the time to a satisfactorily completed task, the rate of unresolved cases and the work needed to correct outputs. Token cost alone does not capture licensed evidence, engineering, clinical review or support.
A local deployment may offer control over some dependencies but require more operational capability. A managed service may simplify maintenance while introducing external reliance. These are architectural trade-offs, not a universal ranking of deployment models.
What buyers should ask to see
A buyer does not need every proprietary implementation detail to ask meaningful questions. Request the task boundaries, significant dependencies, tested configuration, change process and behaviour when a component fails. Ask how source evidence and consequential outputs remain inspectable.
DECIDE-AI is relevant to reporting early live clinical evaluation, including the human workflow. It does not endorse a particular number of models or replace task-specific testing.
The useful conclusion
For an engineering team, use additional models where they solve a defined problem better than a simpler design. For a clinical buyer, assess the complete workflow rather than the number of specialist components. For a clinician, remain alert to shared assumptions even when several systems appear to agree.
The future may favour orchestration of models, evidence and rules. The competitive advantage will come from making that combination dependable, not from calling it a medical supermodel or drawing more boxes on an architecture diagram.
Frequently asked questions
Are multiple models always more accurate than one?
No: additional components can introduce routing and handover failures or repeat shared mistakes. The complete system needs evaluation.
Should clinical calculations and permissions be delegated to a language model?
Explicit calculations and access rules often belong in checked conventional software. A model's fluent explanation or confidence does not validate arithmetic or grant authority.
What should happen when a specialist component is unavailable?
The system should make the limitation visible and follow a tested fallback or handback process. Silent substitution can change the evidence supporting the workflow.