A certification claim should follow its documented scope, not the width of a platform's navigation menu. An assessment covering one clinical AI function does not automatically establish the status of every other feature, integration or future release sold under the same brand. Buyers need to identify the assessed product and understand how its functions interact.
This is not an argument that every tab requires a separate certificate. The appropriate boundary depends on the product and applicable framework. The regulatory sources in this article were checked on 13 October 2026, and the platform below is entirely fictional.
A platform can contain several different propositions
Imagine a fictional product called ClinicDesk. It offers consultation documentation, a general reference search, patient-specific triage support, a draft prescribing workflow and patient messaging. Its homepage displays a medical-device badge beside the platform name.
A hospital buyer reasonably asks what that badge covers. The answer cannot be inferred from the fact that all functions share a login. It needs to be established from the relevant documents, intended-purpose statement and configuration being proposed.
The MHRA's intended-purpose guidance connects the product claim to its function, users, population and environment. That makes feature-level clarity useful, although the eventual regulatory assessment may concern a combined system rather than isolated components.
Map function, purpose and evidence before status
The following is an editorial assessment worksheet. It does not assign a regulatory classification to the fictional functions and should not be used to classify a real product without the necessary analysis.
| Fictional function | Intended-purpose question | Evidence to locate | Status question |
|---|---|---|---|
| Documentation | Does it preserve an encounter or add clinical interpretation? | Meaning preservation, review and record-entry evaluation | Is this function within the documented assessment? |
| Reference search | Is it general information or patient-specific decision support? | Source support, limits and intended users | Which claim, if any, is being made about its regulatory status? |
| Triage support | What decision does it influence and for whom? | Relevant population and workflow evaluation | Does the assessment cover this precise use? |
| Prescribing workflow | Does it draft, recommend or execute? | Authorisation and complete-pathway testing | Are those actions within the assessed boundary? |
| Messaging | What content and recipients can it select? | Identity, review, delivery and correction evidence | Does its interaction with a device function alter the assessment? |
Begin with these questions before assigning reassuring labels. A superficially administrative function can affect a consequential workflow, while a health-related educational function should not be assumed to have the same purpose as patient-specific treatment software.
The important boundary may be between functions
Suppose ClinicDesk's fictional triage module produces a recommendation for clinician review. Its messaging module automatically converts that recommendation into a patient communication. Even if the messaging feature is described as administrative, its behaviour may change the consequences of the triage function.
The FDA's multiple-function device guidance, issued in July 2020, addresses how another function can affect the safety or effectiveness of a device function. This is a US policy, not a substitute for British or European classification. It provides a useful reminder that a product cannot always be understood by assessing each module without its connections.
A local buyer should therefore inspect the transitions. Which output becomes another function's input? Does human approval remain attached to the correct version? Can a changed recommendation leave an earlier message queued for release? Those are proposed test questions, not allegations about a named platform.
A management-system badge answers another question
ClinicDesk might also display an AI management-system or quality-management certificate. Those can provide relevant assurance about organisational processes within scope. They do not, by themselves, establish the conformity or clinical performance of every feature.
ISO/IEC 42001 concerns AI management systems, while ISO 13485 concerns quality-management systems for medical devices. A buyer should identify the certified entity and activities rather than treat these standards as alternative ways to say that every output is medically correct.
Equally, product conformity should not be dismissed as mere badge collection. The problem is not the existence of certificates, but communicating different assessments as though they all establish the same unlimited conclusion.
A truthful platform claim can still be concise
A more useful fictional website statement would identify the assessed module and direct readers to its scope, while describing the other functions separately. For example: "The assessment documentation concerns the Review module for the specified professional use; contact us for the scope and applicable configuration."
That is an illustrative communication approach, not approved regulatory wording. The real statement should match the actual documentation. It should not imply that a feature is outside regulation merely because it is not included in the certificate being advertised.
The joint transparency principles support providing users with information relevant to the intended use, limitations and changes. A precise explanation is more useful than a footer that forces clinicians to reconstruct the boundary from unrelated documents.
Expansion requires a fresh look at the claim
A platform may start with clinician-reviewed drafting and later add automatic sending. The development team might regard this as a small usability improvement because the generated text is unchanged. The consequence of an error, however, may be different when the output reaches a patient before review.
The assessment should consider the changed intended purpose, permissions and workflow, together with the applicable change process. The joint predetermined change-control principles concern bounded modifications and their evidence, not unrestricted expansion under the protection of an earlier assessment.
The same applies when a product moves into a different patient population or professional role. A shared model and interface do not make the evidence automatically transferable.
Give local users the boundary they actually need
For an English NHS deployment, the adopter should connect the supplier's scope to its own configuration and controls under the relevant clinical-risk management standards. Staff need to know which features are available locally, what checking is required and which actions remain prohibited.
A practical local inventory might record each enabled function, its purpose, relevant evidence, required human role and escalation route. It should be maintained when permissions or workflows change. An organisation-wide announcement that the platform is approved is less useful if individual teams then enable different functions without review.
This article is published by iatroX, whose reference, education and advisory activities should be subject to the same discipline. As described on 13 October 2026, Insights by iatroX offers safety and readiness support; that description does not imply certification of every iatroX function. The standard should be a clear connection between the claim made, the evidence available and the exact work being undertaken.
Frequently asked questions
Does every feature need its own medical-device certificate?
Not necessarily. The relevant assessment boundary depends on the product, interacting functions and applicable regulatory route, rather than the number of interface features.
Can an uncertified feature affect an assessed device function?
It can affect the overall safety argument if it changes inputs, outputs or consequences. The relationship needs examination rather than an assumption that separate product labels make the functions independent.
What should a buyer request after seeing a platform-wide certification badge?
Request the relevant legal entity, assessment framework, product scope and mapping to the proposed configuration. Ask specifically which functions and uses the documentation supports.