AI and SaMD
Software that supports a clinical decision and is regulated as a device in its own right. The dataset, the validation protocol and the change-control plan matter as much as the model.
- Devices we have built here
- Dermatology screening platforms, tele-consultation platforms, image classification, clinical AI tools.
Devices we have worked on
We name the type of device, not the client. Client work stays confidential.
- Diagnostic-support software built on a clinical data platform
What makes these devices hard
The dataset
Labelled by clinicians, representative of the people it will be used on.
Validation
A locked model tested on data it has never seen, to a written protocol.
Change control
A plan for how the model is retrained and when that is a new submission.
Cybersecurity
Patient data protected in transit, at rest and in the cloud.
Tell us these first
Useful in a first enquiry
- The clinical question, and who acts on the output
- The data you hold: size, source sites, devices and consent
- How the labels were made, and by whom
- Where it runs: phone, hospital system or cloud
- Whether the model should keep learning after release
Keep the test data apart from the build
Performance claims come from the test set, so it must stay apart from the data that built and tuned the model. Split by patient, not by image, so one person's scans never sit on both sides. Where possible, draw test data from other sites and devices, because a model can learn a hospital's scanner instead of the disease. Run the test once, on the locked model.
The path for a device like yours
Questions about AI and SaMD devices
Can our model keep learning after release?
It can be planned, but each change to a regulated model needs control. Some regulators accept a plan agreed in advance that sets which changes are allowed and how each is verified; other changes need a new submission. Many first releases use a locked model, which keeps the evidence simpler.
Is our software a medical device?
If it is intended to diagnose, monitor or guide treatment, it is likely to be. The intended use decides, not the technology. Its class follows the intended use and the classification rules; try the class and route tool.
Is a retrospective dataset enough evidence?
A retrospective study on independent data is often the start. Whether prospective evidence is also needed depends on the risk, the claim and the regulator. Plan the evidence against the intended use before labelling begins.
What does IEC 62304 ask of an AI team?
A documented software life cycle: requirements, architecture, verification, configuration and problem management, scaled to the software safety class. The model sits inside that life cycle, with its data and training recorded.
Software built for clinical use
Our programmes include diagnostic-support software built on a clinical data platform, designed by a team that also covers hardware, testing and regulatory work.
Standards that commonly apply
- IEC 62304Medical device software life cycle
- IEC 82304-1Health software product safety
- ISO 14971Risk management
- IEC 62366-1Usability engineering
The list for a given device, and the edition of each, is set in its regulatory plan.
Services that help here
Building a device in AI and SaMD?
Opens the contact form with the topic filled in. Nothing is sent until you press send.