Service
Medical-Device Software & SaMD
Take software through ISO 13485 and the Software as a Medical Device lifecycle, from risk classification and IEC 62304 to clinical evaluation and CE/UKCA or FDA, including AI/ML-enabled features.
Building software that has to pass as a medical device
When your software is the medical device, or sits inside one, the bar changes. You need a quality system regulators recognise, a development lifecycle you can evidence, and a clinical and risk case that stands up to scrutiny. We help teams build software that meets that bar without grinding delivery to a halt, drawing on years of shipping regulated medical systems for manufacturers and health providers.
Where this helps
- ISO 13485 quality management: establishing or right-sizing a quality management system for software, with design controls, document and change management, and the records an auditor expects.
- Software as a Medical Device (SaMD) lifecycle: classifying intended use and risk, then running an IEC 62304 software lifecycle (architecture, units, integration, problem resolution) proportionate to the safety class.
- Risk management: hazard analysis and risk controls aligned to ISO 14971, traced through requirements, design, and verification.
- Clinical evaluation and usability: assembling the clinical evidence and human-factors work (IEC 62366) that support safety and performance claims.
- Routes to market: preparing technical documentation for CE/UKCA under the medical-device regulations, or a 510(k)/De Novo path with the FDA, and working effectively with notified bodies and auditors.
- Interoperability done safely: building on healthcare standards (HL7/FHIR, DICOM, SNOMED CT) without compromising the safety case.
AI and machine learning in the device
ML-enabled features don't fit the old "freeze it and ship it" model, and the regulators know it. We help you bring AI into a SaMD responsibly:
- Good Machine Learning Practice: data governance, representativeness, and bias control treated as part of the design history, not an afterthought.
- Predetermined change-control plans: describing in advance how a model may learn and update post-deployment, and the limits within which it stays within its cleared intended use.
- Verification you can defend: reference datasets, performance thresholds, and held-out evaluation that make a model's behaviour evidence, not anecdote.
- Post-market surveillance of model performance: monitoring for drift and degradation in the real world, with a route to act when performance moves.
How it works
We start from the intended use and the real risk, agree the lightest credible path to compliance, and embed alongside your engineers so the quality system is something they can live with rather than route around. The output is software that is genuinely safer, and a documentation trail that makes approval a formality rather than a fire drill.