IEC 62304 for SaMD — where classification arguments happen and what actually gets audited

If you've submitted SaMD to FDA or a notified body in the last two years, you know the argument. Classification.

Manufacturer wants Class B. Reviewer thinks Class C. The difference is hundreds of engineering hours in additional verification documentation, formal code coverage metrics, and unit-level design records. The debate is usually not about the harm severity itself — reviewers rarely dispute the ISO 14971 analysis at the top level. The debate is about whether the software safety classification maps correctly to the hazards the risk file identified, and whether risk controls elsewhere in the system legitimately lower the software's safety class.

This is where IEC 62304 discussions actually live. Not in the lifecycle model or the SOUP inventory, which are mechanical. In the classification call and the segmentation decisions that flow from it.

Safety class is a system-level argument, not a software property

IEC 62304 Section 4.3 is the clause that does the work. Software safety class is determined by the severity of harm a software failure could contribute to — after considering risk controls external to the software. That "after considering" is the operational lever.

A worked example. Infusion pump firmware computes a dose. Direct hazard: overdose, severe harm. Without external controls, the firmware is Class C. With an independent hardware dose limiter — an analog circuit that cannot be overridden in software — the software's contribution to the dose accuracy hazard is gated. If the limiter fails safe and the risk analysis supports it, the software safety class can legitimately drop to Class B.

The argument works when the external risk control is independent, testable, and documented. It fails when the "external control" is another software module in the same system, or when the risk analysis doesn't actually demonstrate independence. Reviewers dig into this. A classification that depends on claimed independence needs evidence showing independence is real.

Software safety class is not uniform across a system. IEC 62304 Section 4.3 explicitly allows per-software-item classification. A Class C device can contain Class A modules (scheduling, display formatting, log management) alongside Class C modules (therapy control, alarm generation, safety monitoring). The segmentation work is where programs either save substantial verification effort or give it back because the segmentation wasn't clean enough to defend.

The lifecycle processes — what actually gets documented

IEC 62304 defines processes, not a specific development methodology. Waterfall, iterative, agile all work provided the required artefacts get maintained. The standard describes what you must demonstrate; it doesn't prescribe how you develop.

Planning. Lifecycle model, development standards, deliverables, reviews. The planning document has to address how software items will be classified, how SOUP will be managed, how configuration management will be maintained. A plan that doesn't reflect the actual development approach is a finding.

Requirements. Functional, performance, security, usability, hazard-related. The hazard-related requirements are the ones that link to the ISO 14971 risk file. Every risk control implemented in software should appear as a software requirement. The traceability matrix — requirement to design element to test case — is the core IEC 62304 artefact.

Architecture and detailed design. Decomposition into software items, interfaces, safety classification at item level. The architecture document is where SOUP identification happens — every component not developed under your quality system is potentially SOUP and needs to be captured in the architecture before you can begin SOUP management.

Implementation and unit verification. For Class B and C, the standard requires documented unit verification. Class C adds coverage metrics — typically statement or branch coverage above a threshold the manufacturer justifies. The threshold is a manufacturer decision; reviewers will ask why it was chosen.

Integration testing. Test cases traceable to requirements. Results documented. Integration failures captured and dispositioned. In practice, the integration test records are what reviewers examine most closely — they're the evidence that the architecture actually works as specified.

System testing. Integrated software verified against full requirements set. Test cases, results, anomaly disposition. Test environment documented.

SOUP — where most teams accumulate debt

Software of Unknown Provenance is any software item not developed under your quality system. Open-source libraries, commercial components, operating systems, build tools, third-party frameworks, runtime environments. Modern software products are built substantially from SOUP.

IEC 62304 requires identifying all SOUP items, documenting their functional and performance requirements (what you expect them to do), documenting known anomalies, evaluating risk contribution, and for Class B and C software, documenting suitability testing.

The recurring problem is version management. Development teams add dependencies continuously. New library here, framework upgrade there. The SOUP registry either gets maintained manually — which breaks down past a few dozen components — or doesn't get maintained at all. By submission time, the SOUP inventory is incomplete, and reconstructing it from dependency manifests takes days of forensic work.

SOUP version changes are change events under the standard. A library upgrade from 4.2.1 to 4.2.2 is a SOUP change that requires re-evaluation of risk contribution and potentially additional verification. In an agile environment where dependencies update weekly, keeping the SOUP record current requires build-time automation. Manual tracking doesn't scale.

A practical SOUP inventory for a typical SaMD system contains 80–400 items. Of those, 5–20 are safety-relevant (used in code paths that implement risk controls or essential performance). The safety-relevant subset needs deeper documentation — version pinning, tested configurations, regression evidence when versions change.

The V&V cascade — why traceability matters structurally

Verification under IEC 62304 cascades from requirements through design through implementation to test. Each link has to be traceable. Every test result references the requirement it confirms. Every design element references the requirement it implements. Every requirement references its source in user needs or risk controls.

Reviewers examine the traceability matrix carefully. A matrix with gaps — requirements without test coverage, test cases without requirement references, requirements without design element mapping — generates Additional Information requests. Sometimes major ones that delay review by a quarter or more.

The matrix is usually the hardest artefact to maintain in a fragmented development environment. Requirements live in one tool. Design in another. Tests in a third. SOUP in a spreadsheet. The matrix that synthesises them is a separate artefact maintained manually.

What makes the matrix manageable at scale is treating traceability as a structural property of the engineering record, not a separate artefact. When requirements, design elements, tests, and SOUP items are connected objects in a shared data model, the matrix is a query, not a construction project. That's the architectural distinction that separates teams who generate traceability matrices in hours from teams who spend weeks reconstructing them at submission time.

What's changing for AI/ML-enabled SaMD

IEC 62304 was written for deterministic software. AI-enabled SaMD has failure modes the standard wasn't designed to address — model drift, distribution shift, data bias, confidence miscalibration. FDA's evolving guidance on AI/ML SaMD, the GMLP principles, and the PCCP framework all extend IEC 62304's expectations without rewriting the standard.

The practical impact: Class C is nearly default for AI components making clinical decisions, because the harm pathways are real and external risk controls are harder to argue. SOUP management expands to include ML frameworks (TensorFlow, PyTorch, etc.) as SOUP items with their own version and anomaly tracking. Requirements include model performance thresholds, not just functional correctness. V&V documentation includes dataset lineage, training procedures, and evaluation metrics that weren't part of the standard's original vocabulary.

How MANKAIND handles IEC 62304

Requirements, design elements, test cases, SOUP items, and risk controls are connected objects. When a requirement is created, the platform captures its source (user need, risk control, regulatory expectation) and scaffolds the verification approach. When a test case is written, it references the requirements it exercises. When a SOUP item is added to the build, it's automatically captured in the SOUP registry with version pinning. When a SOUP version changes, the platform surfaces which design elements may be affected.

The traceability matrix, the SOUP inventory, and the software development file aren't assembled at submission. They're rendered from the engineering record. For SaMD teams working on tight timelines, that's the difference between submission prep taking weeks or months.

Frequently asked questions about IEC 62304

What is IEC 62304?

IEC 62304 is the international standard that defines software lifecycle process requirements for medical device software. It applies to Software as a Medical Device (SaMD) and to software embedded in hardware medical devices. FDA recognises it as a consensus standard and the EU MDR and IVDR require it for CE marking.

What are the IEC 62304 safety classes (A, B, C)?

Software safety class is determined by the severity of harm a software failure could contribute to. Class A means no or negligible injury, Class B means non-serious injury, Class C means serious injury or death. Higher classes trigger more rigorous documentation and verification requirements.

What is SOUP in IEC 62304?

SOUP — Software of Unknown Provenance — is any software item that was not developed under your quality system. This includes open-source libraries, commercial components, operating systems, and third-party frameworks. IEC 62304 requires every SOUP item to be identified, risk-evaluated, and tracked through version changes.

Is IEC 62304 mandatory for SaMD?

Effectively yes. FDA recognises IEC 62304 as a consensus standard for medical device software, and the EU MDR and IVDR require compliance for CE marking. For any SaMD program, IEC 62304 documentation is a submission artifact — not optional.

How does IEC 62304 relate to ISO 14971?

Software safety classification under IEC 62304 is driven by the ISO 14971 hazard analysis. You cannot determine a software safety class without first evaluating the hazardous situations the software could contribute to and the severity of potential harm. The two standards are structurally linked.