Scarlet assesses defined organisations, systems or medical devices under particular certification schemes and regulatory scopes. It does not issue an unrestricted endorsement of everything a healthcare AI brand might do. The first question is therefore not simply whether a supplier is certified, but what was assessed, under which framework, by which legal entity and for which intended use.
This guide reflects public information checked on 13 October 2026. Scarlet's published assessment information distinguishes management-system certification from medical-device conformity assessment. The distinction is essential when a clinician, founder or NHS buyer is shown a collection of badges without an explanation of their relevance.
A certification body is not the government regulator
In the European medical-device framework, notified bodies are organisations designated to perform specified conformity-assessment activities. Their designation and authorised scope matter; an organisation's general experience in technology is not a substitute for the appropriate authority. The European Commission describes this role and its oversight.
For Great Britain, the MHRA maintains a separate list of UK approved bodies. As checked on 13 October 2026, that list includes Scarlet NB UK Ltd. A UK approved-body entry should not be mistaken for an EU notified-body entry merely because the organisations share a brand.
The manufacturer remains responsible for its product. The assessor reviews the evidence required for the applicable route. The regulator has a different oversight role. An assessment can be important without making the assessor the designer, treating clinician or deploying organisation.
Establish the object of the claim
A management-system certificate concerns organisational processes within a defined scope. A medical-device assessment concerns the applicable requirements for a particular device or device family and its intended purpose. The documents may be related, but they do not establish identical conclusions.
For example, ISO/IEC 42001 addresses AI management systems, while ISO 13485 addresses quality-management systems for medical devices. A buyer should not translate either into a claim that every clinical response has been independently checked or that every module has market access.
Equally, not all software needs the same medical-device route. Qualification and classification depend on the applicable framework and the product's purpose. Some devices can follow routes without the same third-party involvement required for others. The MHRA's market-access guidance should be consulted for the actual case rather than assuming every health-related application requires one identical certificate.
Read a fictional certificate without overreading it
Imagine a fictional supplier, Example Clinical Systems Ltd, displaying an assessment document for a module called ReviewAssist. These names and the following entries are invented to demonstrate a reading method, not to reproduce a Scarlet certificate or imply an actual certification.
| Field to inspect | Fictional entry or question | Why it changes the interpretation |
|---|---|---|
| Legal entity | Example Clinical Systems Ltd | The trading brand may cover several companies |
| Assessment framework | Identify the specific regulation or management-system standard | Organisational processes and product conformity answer different questions |
| Product or activity | ReviewAssist, with a defined scope | A parent platform name may conceal narrower coverage |
| Intended use | Specialist review support in a stated setting | An unrelated triage use cannot be assumed to be included |
| Issuing body | Verify the legal entity and authorised scope | A recognisable logo alone is insufficient |
| Status and associated documents | Check validity, schedules and relevant changes | The cover page may omit consequential restrictions |
Treat this as a document-reading aid, not a universal specification of what every certificate must contain. Some details may be located in schedules, declarations, instructions or linked technical documentation rather than on the certificate itself.
Connect the document to the product on the screen
The next step is to ask how the assessed scope maps to the version being offered. A commercial platform may combine information retrieval, documentation, patient messaging and decision support. The buyer needs an intelligible explanation of which functions sit within the relevant assessment and which do not.
That explanation should identify meaningful dependencies. A separately described messaging function may still affect a device if it changes how its outputs reach a patient. The FDA's multiple-function device policy, a US framework reviewed here for comparison, illustrates why functions cannot always be assessed as isolated boxes: another function can affect the safety or effectiveness of the device function.
For a UK or European decision, apply the relevant local rules rather than importing the FDA's approach as law. The practical lesson travels more readily than the legal route: look at how the functions interact, not just how the sales page divides them.
Ask what the evidence says about people and settings
A valid assessment document does not mean the buyer can ignore the intended users, patient population or operating environment. A system evaluated with specialist users and particular inputs may require further consideration before use by a different workforce with incomplete records.
The MHRA's intended-purpose guidance emphasises clear specification of these boundaries. In a fictional example, software intended to support a specialist's interpretation should not be treated as a patient-facing diagnostic service simply because its interface can accept a patient's question.
Ask what uncertainty remains, which information the product requires and what users are expected to verify. Those questions help distinguish a limited but well-described product from a broad promise whose evidence is difficult to locate.
What remains after certification?
For an English NHS deployment, the supplier's assessment documents inform rather than replace the local clinical-risk work. DCB0129 and DCB0160 distinguish manufacture from deployment and use. Local configuration, staffing, training and contingencies can determine whether a manufacturer's assumptions hold.
The useful handover is therefore not just a certificate attachment. It includes the intended-use statement, applicable evidence, limitations, required controls, relevant change information and contacts for concerns. Not every internal document must be published openly, but the adopter needs enough usable information to make its own decision.
A clinician also needs a shorter operational explanation: what task the tool supports, when it should not be used, what checking is expected and how to report a problem. Technical assurance that never reaches the person using the product is an incomplete communication strategy.
Different readers should reach different next steps
A founder should establish the appropriate route and prepare evidence for the finished system. A procurement lead should verify scope and obtain a deployment-ready handover. A clinician should understand the actual limits of the tool available in their service, rather than attempting to infer them from badges.
As described on 13 October 2026, Insights by iatroX supports clinical safety and regulatory readiness. Such advice can help organise responsibilities and evidence, but cannot substitute for independent assessment where required. Scarlet's role and iatroX's advisory role should remain visibly distinct.
Frequently asked questions
Does Scarlet certify the AI model or the complete medical product?
The answer depends on the specific scheme and scope. For a medical-device claim, readers should establish which finished device, intended purpose and supporting documentation are covered rather than assume that a foundation model alone has been endorsed.
Is an ISO certificate the same as medical-device conformity assessment?
No. A management-system certificate addresses specified organisational processes, while product conformity concerns the applicable requirements for the device.
Can a certificate apply to every feature on a supplier's website?
Only the documented scope can establish what is covered. Additional functions, configurations or uses require examination rather than automatic extension of the claim.