Medical device software development is the lifecycle for software that is a medical device (SaMD) or that sits inside one (SiMD): IEC 62304, design controls, the Design History File, Class A/B/C. It is how the software is built. It is not how you pick a vendor, not the device Phase 0–5, and not a software-validation manual.
If you meant how to choose a vendor → medical device software development companies. If you meant software testing → medical device software testing. If you meant software validation → medical device software validation. If you meant device development process → medical device development process. If you meant device design V&V → medical device verification and validation. If you meant IQ / OQ / PQ → medical device validation process. If you meant FDA 510(k) / PMA / De Novo → FDA medical device approval process.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the 62304 / validation / vendor house.
SaMD vs SiMD
| Software as a Medical Device (SaMD) | Software in a Medical Device (SiMD) | |
|---|---|---|
| Job | Performs a medical function on its own | Controls or supports a hardware device |
| Runs on | General-purpose platforms — phone, PC, server | The hardware it ships with |
| Examples | AI on a chest X-ray; mole-scoring app; dosage calculator that is the device | Infusion-pump firmware; pacemaker logic; CT control software |
| File looks at | The software’s performance, safety, clinical claims | The system: hardware + software and the interface |
If the software performs a medical function, it is a medical device. There is no consumer-app shortcut. The class of the device is still the FDA tree on 698; this page is the software lifecycle inside that file.
IEC 62304, design controls, DHF
Two frames sit on the same spine. FDA design controls (21 CFR 820.30) say: inputs, outputs, review, verification, validation, transfer, changes — written down. IEC 62304 is the software-lifecycle standard in that family: planning, requirements, architecture, implementation, integration, test, release, maintenance. ISO 13485 is the QMS that holds the procedures — that how-to is 699 QMS.
The word that binds them is traceability. A radiologist need — “measure a tumour to ±0.5 mm” — becomes a software requirement, an architecture decision, a function, and a test. Break the chain and the auditor stops. The Design History File is that story for the software (and for the device it sits in). Device-level V-model and 820.30 as the job live on device verification and validation. Here the DHF is the software trail: user needs and design inputs, architecture and code as outputs, reviews, software V&V records, transfer into the release.
Class A, B, C
| IEC 62304 class | If the software fails | Rigor |
|---|---|---|
| A | No injury possible | Lightest lifecycle. Educational display with no clinical action. |
| B | Non-serious injury possible | Architecture, unit and integration evidence. Lifestyle advice off a glucose reading can land here. |
| C | Death or serious injury possible | Full process. Radiation-therapy control. Diagnostic imaging that sets treatment. |
Over-classify and you drown in paper. Under-classify and the file is a gap. The class is a harm argument, not a marketing label. SOUP (software of unknown provenance — an OS, a library you did not write) still sits in the risk file even when you did not author it.
ISO 14971 for software, and security
ISO 14971 is the risk method. For software you need both levels: the system hazard (“wrong measurement → wrong diagnosis”) and the software failure mode that feeds it (“the segmentation function reports 12 mm as 8 mm”). Draw that line or you cannot pick the test. The device-level risk how-to is ISO 14971.
Cybersecurity is now a safety control, not an IT ticket. Threat-model in design, not after freeze. Vulnerability management (your code and the SOUP). Secure coding. A pre-market pen-test on the interfaces that will exist in the field. FDA’s premarket and postmarket cybersecurity guidance expects that evidence in the file.
Software V&V as a chapter, not the whole job
Verification: did we build the software to the spec. Validation: did we build the right software for the intended use. That pair, as a lifecycle activity, belongs here so the DHF traces. The test layers (unit / integration / system, automation for regression) are medical device software testing. Intended-use validation, GPSV, the validation pack — medical device software validation. Device design V&V (V-model, 820.30 as the job) stays on 699 502. Process validation (IQ / OQ / PQ) stays on 699 501.
AI / ML in the device is still 62304 software plus a predetermined change control plan if the model is allowed to learn after clearance. Bias in the training set is a patient-safety issue. That is a constraint on this lifecycle, not a second article on “AI devices.”
FAQ
IEC 62304 versus FDA guidance?
62304 is the how-to for the software process. FDA still wants the proof: risk file, V&V, traceability. Follow 62304 and you generate most of that proof as you go. The 510(k) / PMA choice is 698.
Can you be agile?
Yes, if a story is not done until the DHF row is updated. Documentation bolted on after sprint 18 is how audits fail. Verification inside the sprint; validation at the releases that claim intended use.
What kills SaMD projects?
Treating it like a consumer app and wrapping a QMS around a finished build. Fuzzy user needs, so nothing is testable. Cybersecurity left as a patch. All three are process failures on this page, not vendor-selection failures on 493.