A platform can contain educational functions and functions intended to support clinical decisions. The appropriate assessment starts with what each function is for, not a single label applied to the whole website. An examination tutor, a general reference search and a patient-specific recommendation may sit behind one login while raising different questions.
This article offers a practical function-mapping framework, not a regulatory classification of a particular product. Public UK and US sources were checked on 19 September 2026. Their legal frameworks are not interchangeable, and a conclusion in one jurisdiction should not be exported to another without analysis.
Describe a purpose that can be inspected
"AI for doctors" is too broad to assess. Describe the intended user, task, input, output and setting. An original example would be: a medical student answers a fictional examination question, then receives guided prompts intended to improve understanding. Another would be: a clinician enters information about a current patient and receives a recommended next action.
The examples do not establish a legal boundary by themselves. They show why the task needs to be described before that boundary can be assessed. Ask what claims the supplier makes, how the interface encourages use and what supporting information the user receives.
Do not rely solely on a footer saying "educational use" if the surrounding product claims and workflow point elsewhere. Equally, do not assume that a clinical topic makes every teaching activity a medical-device function. Intended purpose and actual product design require a coherent account.
Build a function map before drawing a conclusion
| Function description | Questions to investigate |
|---|---|
| Fictional question practice | Is the output teaching, assessment feedback or advice for an actual patient? |
| General reference retrieval | What information is provided, and can its basis be inspected? |
| Patient-specific interpretation | Which patient data influence the output and what decision is supported? |
| Recording professional learning | Does it document activity or claim to assess competence? |
| Workflow action | Does the software only display information or initiate an action? |
This is an original analytical map, not a regulatory decision table. A row is the beginning of an assessment, not an exemption category. One function can also affect another, for example when a shared retrieval service supplies both educational explanations and clinical answers.
Record the dependencies. A change to the shared source pipeline might affect more than one user-facing function, even if only one feature is advertised as updated. Architecture and intended purpose are related descriptions, but they are not the same thing.
The US example: functions can differ within one product
The FDA's clinical decision support FAQs, as checked, explicitly discuss products containing both device functions and other functions. They also explain that the clinical decision support guidance is not the only relevant policy and that non-device status, enforcement discretion and regulated device functions are distinct considerations.
That matters because a simplistic question such as "Does it satisfy every non-device CDS criterion?" may not complete the analysis. The FDA directs developers to additional guidance and its policy navigator. An educational article should preserve that nuance rather than manufacture a one-step test for every medical AI product.
The practical implication is to ask a supplier for its function-specific rationale and the sources on which it relies. Do not infer that a registration or authorisation associated with one component automatically covers every feature under the same brand.
The UK example: keep the local framework visible
The MHRA's software and apps guidance collection, checked on 19 September 2026, is an appropriate starting point for UK questions about medical-device software. Use the relevant current guidance and obtain qualified advice for the actual intended purpose and route to market.
A US explanation of non-device CDS should not be presented as the UK test. Nor should a UK conformity or registration statement be translated into US clearance terminology. Keep the jurisdiction beside the claim whenever a product's regulatory position is discussed.
For a procurement team, request the exact product, manufacturer, intended purpose and supporting documentation. A badge without those details cannot answer whether the proposed deployment falls within the documented scope.
A fictional mixed-platform assessment
Imagine a service with a revision bank, a simulated patient and a clinical reference workspace. The revision bank uses fictional vignettes. The simulator provides feedback about a practice encounter. The reference workspace is marketed for clinicians asking questions during care.
The initial function map should keep those purposes separate. Then examine whether data or outputs move between them. Can users import real records into the simulator? Does feedback claim to certify readiness for independent practice? Does the reference answer lead directly to an order? Each question may change the assessment required.
The fictional exercise does not establish that these capabilities exist in iatroX. It shows why a platform-wide slogan cannot replace a documented review. If the service adds a new patient-specific workflow, revisit the map rather than assume the earlier assessment still answers the new question.
Apply the distinction to iatroX without overclaiming
This article is published by iatroX and includes its own mixed reference-and-learning proposition. The public clinical AI standards, checked on 19 September 2026, distinguish static editorial, dynamic reference and educational functions. The September product brief also separates questions, Tutor, simulations and CPD records.
Those descriptions are useful inputs to an assessment. They are not a substitute for reviewing the precise function, claims and intended deployment. Clinician-reviewed simulation cases do not amount to examining-body endorsement, and a professional learning record does not establish formal accreditation or clinical competence.
For a learner choosing revision support, assess the learning task and accessibility. For a clinician using reference information, inspect sources and appropriate boundaries. For an institution deploying patient-related decision support, request the relevant regulatory and safety evidence. The right question changes with the function.
Frequently asked questions
Does an educational disclaimer settle a product's regulatory status?
No. The intended purpose, claims, inputs, outputs and relevant jurisdiction need to be assessed together.
Can one platform contain functions with different regulatory considerations?
Yes. The FDA explicitly discusses multiple-function products, although the analysis must follow the applicable local framework.
Does this article classify every iatroX feature?
No. It explains a function-by-function assessment method and does not replace a documented product-specific regulatory review.
Explore function-specific clinical AI assurance with iatroX Insights →