IEC 62304 is the standard defining the software development lifecycle for medical device software. It specifies the processes a manufacturer must follow — planning, requirements, architecture, detailed design, implementation, integration, system testing and release — and scales the rigour of those processes to a software safety classification of A, B or C.
Classification is made per software item, and since Amendment 1 it is determined by the hazard that could result after external risk control measures are taken into account. That has real commercial consequence: a hardware interlock or an independent monitoring channel can legitimately drop a component from Class C to Class B, and the difference in required documentation is substantial.
Architecture is therefore a regulatory lever, not only an engineering one. Segregating the safety-relevant part of a system into a small, well-isolated item is how teams keep Class C scope small enough to sustain over years.
SOUP is where most projects underestimate the work. Every third-party dependency needs a stated purpose, functional and performance requirements it must satisfy, the hardware and software environment it requires, and a documented process for reviewing published anomalies against your own use of it.
Class A means no injury or damage to health is possible. Very little clinical software qualifies once you reason honestly about where a wrong output could lead, and an optimistic classification is the first thing a reviewer stress-tests.
A lockfile is not a SOUP list. The standard wants each component identified with a version, a stated purpose, the requirements it must meet, and evidence that known anomalies have been reviewed against how you actually use it.
Requirement-to-test traceability produced by tooling as you work costs almost nothing. Reconstructed afterwards from memory, it costs weeks and convinces no one.
Software of unknown provenance: any component you did not develop under the standard. In practice that means essentially every third-party and open-source dependency, plus commercial libraries and sometimes code your own team wrote before the QMS existed. Each needs a stated purpose, requirements it must satisfy, and ongoing review of published anomalies.
Class A where no injury is possible, B where non-serious injury is possible, and C where death or serious injury is possible — judged on the worst credible harm after external risk control measures are taken into account. Most clinical software lands in B or C once you reason honestly about a wrong output.
Yes, and this is the standard’s most useful commercial lever. Since Amendment 1, classification considers external risk controls, so a hardware interlock or an independent monitoring channel can legitimately drop an item from C to B. Segregating safety-relevant code into a small, well-isolated item keeps Class C scope sustainable — provided the segregation is justified and verified.
Working out how IEC 62304 applies to what you are building is usually the first conversation.
Get in touch →