In the past decade, software has quietly rewritten entire industries — healthcare and automotive among the most consequential. Doctors, patients, and ordinary people benefit directly from digital advances. But where human safety is involved, every industry carries its own standards, and they vary country to country. ISO 26262 governs functional safety in vehicles; ISO 14971 governs the software-and-hardware combination in medical devices. SaMD sits squarely in that high-stakes territory.
01So what exactly is SaMD?
Smartphones, social platforms, and the sharing economy reshaped how we live and work — and they’re driving extraordinary advances in medicine too: 3D printing, point-of-care diagnostics, robotics, bioinformatics, synthetic biology, genomics. Among the most exciting is software capable of performing complex medical functions on its own. We call it Software as a Medical Device (SaMD).
Precisely: SaMD is software intended for a medical purpose that is not part of a medical device’s hardware. It can diagnose illness, recommend therapy, and support clinical management — running on general-purpose platforms.
02And what it is not
The boundary matters, because it determines whether the full weight of medical-device regulation applies. Software that controls or is embedded in hardware is generally not SaMD.
Is SaMD
- App detecting arrhythmia from heart rhythm
- Software estimating drug dosage from patient data
- Software analysing MRI images to diagnose stroke
Is not SaMD
- Electronic health record (EHR) systems
- Software that operates a pacemaker
- Software controlling an infusion pump’s motors
The throughline: SaMD serves a medical purpose without being tied to one specific device.
03Why compliance is non-negotiable
Compliance isn’t bureaucracy for its own sake. It does three concrete things:
| Protects patients | Improves satisfaction and reduces harm by enforcing proper practice and safety. |
|---|---|
| Enforces controls | Aligns both external regulation and internal quality controls into one system. |
| Proves safety & efficacy | Demonstrates the software does what it claims — and does it without unacceptable risk. |
To put that into practice you assess risk severity — SaMD categorisation. Taking into account the software’s function and its safety implications, you classify it into risk tiers that then dictate how rigorous your process must be.
04The two standards that govern SaMD
Two primary standards do the heavy lifting — one for how you build, one for how you run the organisation.
| IEC 62304 | Governs the software development lifecycle — evaluating the safety and risk of your development processes. |
|---|---|
| ISO 13485 | Governs quality management across the organisation, with patient safety at its centre. |
ISO 13485 asks you to implement processes compliant with the regulatory requirements of your target markets, using a risk-based approach. Beyond the standard ISO requirements, it sets out key provisions:
- A risk-based approach to overseeing all relevant processes across the organisation.
- Quality objectives plus management reviews to ensure they’re actually executed.
- Explicit definition of the resources needed to sustain the Quality Management System — infrastructure, people, and work environment.
- Comprehensive product planning: quality requirements, documentation, handling procedures, traceability, and the Software Maintenance Plan.
- Ongoing monitoring, measurement, analysis, and improvement to keep the QMS conformant and effective.
05The gaps regulators cite most
Bodies like the FDA repeatedly flag the same three weaknesses:
| Design controls | Inadequate or undocumented control over how the software is designed and changed. |
|---|---|
| CAPA | Weak corrective and preventive action processes. |
| Complaint handling | Poor capture and resolution of customer complaints. |
The fixes are habits more than documents:
- Traceability — link product features to architecture, then to code and test tasks, so nothing ships unverified.
- Complaint discipline — receive, log, and track every complaint to resolution against an SLA, with feedback to the customer.
- Root-cause rigour — analyse with 5-Why, Pareto, or Fishbone, share findings with the team, and document corrective (CA) and preventive (PA) actions thoroughly.
06When to apply what
Once categorisation and standards are set, timing is the next question. ISO 13485 together with IEC 62304 should be meticulously applied for SaMD classified as Type II(b) and higher. For SaMD at Type II(a) and below, there may be scope for more adaptable compliance — proportionate to the lower risk.
Ultimately, as a solution provider in the medical field, the imperative never changes: prioritise human safety in every decision to develop and deploy SaMD.
- EU Medical Device Regulation (MDR)
- ISO 13485 — Medical devices: Quality management systems
- FDA — Medical Devices regulation
- IEC 62304 — Medical device software lifecycle processes
Disclaimer: the above reflects my own understanding, views, and reading of publicly available SaMD content (references above) and should not be construed as professional or regulatory advice.