Updated 21 October 2026.
A clinical AI platform can look like one product while containing several distinct functions. Recording an encounter, suggesting a code and answering a clinical question may share an interface, but they produce different outputs and create different opportunities for harm. Their proximity on a screen does not make them interchangeable for assessment.
Tandem is a useful example because it has announced Class IIa positions for its Coding Assistant, AI Scribe and Clinical Decision Support. The important next question is not whether three announcements add up to a stronger company-wide badge. It is how the functions are defined, connected and maintained as a platform.
Map the functions before reviewing the certificates
An organisation should begin with the work it expects the platform to perform. What information enters each function? What output does it produce? Who reviews it? Where does it go next? What decisions might rely on it? These questions establish a practical map of the proposed deployment.
The product documentation should then be matched to that map. The relevant declaration of conformity, intended purpose and instructions for use need to cover the function actually being purchased. A roadmap presentation should not silently enlarge the scope of an assessed product.
This matters particularly when new capabilities appear within an existing interface. Users may reasonably assume that everything under the same brand has been assessed in the same way. Suppliers and deploying organisations should make the boundaries sufficiently clear that a new button does not become an unexamined extension of clinical authority.
Different functions need different performance evidence
For a documentation function, evaluation may focus on whether the record faithfully represents the encounter, including important omissions and changes in meaning. For coding, the assessment should consider whether the suggested code is supported by the information and suitable for the relevant coding system and task.
For evidence support, the questions concern source selection, applicability, representation of uncertainty and the relationship between the answer and the supporting material. A platform can have strengths in one area without establishing equivalent performance in another.
Combining the functions introduces further questions. If a coding suggestion relies on a generated note, an earlier omission may affect the later result. If an evidence answer uses that same note as context, the system may interpret a generated representation rather than the complete encounter. The whole workflow therefore needs attention alongside its individual components.
Shared components can create shared failure modes
A common model, retrieval service or terminology component may support several functions. Updating it could affect more than one output, even when the visible change is presented as a narrow improvement. The organisation should know how the supplier identifies those dependencies and assesses potential consequences.
This is a general architectural risk, not an allegation that Tandem has experienced a particular failure. A hypothetical change that improves note concision could remove information needed by another downstream function. A retrieval update could improve one type of answer while changing behaviour for another speciality.
Good change management should therefore be connected to the dependency map. The question is not merely whether a version number changed, but which clinical behaviours might have changed and what evidence supports continued use. Testing only the feature named in a release announcement can miss wider effects.
Personalisation adds configuration that needs to remain understandable
Tandem's Adaptive Notes announcement describes adaptation to editing preferences. The published explanation concerns writing style, not an unrestricted system teaching itself new clinical recommendations. That distinction should remain visible when organisations discuss adaptive clinical AI.
Even bounded personalisation creates questions about configuration. Can the clinician inspect or reset preferences? Can the organisation understand whether a difference in output comes from the base product, a template or an individual setting? How are changes tested against factual fidelity?
The aim is not to prohibit personalisation. A note that fits the user's style may reduce avoidable editing. The aim is to prevent convenience features from making the behaviour of a clinical tool impossible to explain, reproduce or investigate when something goes wrong.
Local documents create an additional source-management responsibility
A platform using locally supplied protocols depends partly on the organisation's content governance. The supplier cannot make an outdated protocol current merely by retrieving it accurately. Responsibility for approval, review and withdrawal should therefore be assigned explicitly.
The interface should help users distinguish local instructions from wider evidence and identify the document version being used. Where sources conflict, the behaviour should be understood rather than discovered incidentally during a difficult consultation.
This is one reason a product-level certificate cannot answer every deployment question. The platform, configuration, local information and clinical workflow together determine how the service operates. Procurement should examine those relationships without assuming that every local decision becomes the manufacturer's responsibility or that every supplier responsibility transfers to the clinician.
The UK's policy direction recognises the function problem
The National Commission's recommendations on AI regulation include a function-based approach to multifunction AI products. The government's October response sets out its intended direction. These developments are relevant to platforms that combine capabilities, but recommendations and commitments should not be presented as a fully implemented new licensing system.
The separate CE-recognition decision concerns recognition of qualifying conformity assessments for Great Britain. It does not resolve every question about the relationships between modules, configurations and future product changes.
For buyers, the practical response is to keep a current product-and-function record rather than wait for a future framework to answer everything. That record can connect the purchased functions, evidence, applicable documentation, local settings and agreed change-notification arrangements.
A useful platform assurance pack should explain the whole service
The most helpful supplier material would allow a clinical organisation to trace a workflow from input to output and identify the relevant controls. It would explain module boundaries, dependencies, review points and failure handling in language that clinical and technical teams can both use.
The organisation then needs its own deployment assessment, informed by applicable clinical risk-management standards. Staff should understand what the system does, what it does not do and where responsibility passes between people and software. That understanding needs refreshing when the workflow changes.
This article is published by iatroX, whose reference and education functions also need to be understood according to their specific purposes. The principle is not unique to a large platform: a feature's convenience or proximity to another feature should never substitute for clarity about its role.
Tandem's expanding suite makes the issue particularly visible. The strongest platform is not the one whose marketing implies that every function has become equally assured. It is the one that can explain its boundaries and maintain dependable relationships between its parts as the product evolves.
Frequently asked questions
Does one certificate automatically cover every feature under a clinical AI brand?
That should not be assumed. The relevant product documentation, intended purpose and scope need to be checked against the functions and configuration being deployed.
Can an update to one module affect another module?
It can where functions share components or depend on one another's outputs. Suppliers and deploying organisations should understand those dependencies and the associated testing arrangements.
Has the UK already implemented a completely new multifunction AI licensing system?
The Commission's recommendations and government response describe a reform direction. They should not be treated as evidence that every proposed licensing mechanism is already in force.
Understand the purpose behind each tool
Read how iatroX's clinical and learning functions work to distinguish reference, tutoring and practice before choosing the tools for your needs.