Regulatory glossary

IEC 62304: Medical Device Software Life Cycle, Explained

IEC 62304 is the standard for medical device software life cycle processes. It applies to software that is itself a device, SaMD, and to software embedded in one.

The standard does not tell you how to write software. It tells you which activities have to happen, be planned, and be recorded, and how much of that scales with how badly things go if the software fails.

Software safety classification

Everything else follows from the class, so this is the first decision and the one worth getting right.

Two things about this that catch people.

The class depends on the hazard the software can contribute to, assessed before considering external risk controls. A hardware interlock can lower the class, but only if it is genuinely independent of the software.

And the class is assigned to the software system, then to each item. Items can be classified separately where they are properly segregated, so a Class C system does not force Class C rigour on every module. Segregation has to be real and documented, not merely architectural intent.

The processes

• Development planning, kept current as the design changes.
• Requirements analysis, including functional, performance, interface and risk control requirements.
• Architectural design, required for Class B and C.
• Detailed design, required for Class C.
• Unit implementation and verification, with acceptance criteria for Class B and C.
• Integration and integration testing for Class B and C.
• Software system testing for all classes.
• Software release, with known residual anomalies documented and evaluated.

Alongside these run four processes that do not stop at release: maintenance, risk management, configuration management, and problem resolution.

The maintenance process is the one most often missing. A released device still needs a defined way to receive feedback, analyse it, and decide whether a change is a modification requiring the development process again.

SOUP

Software of Unknown Provenance is any software item already developed and generally available, that was not developed to be part of your device, or for which adequate records of its development are not available.

In practice: every open source library, every third-party SDK, the operating system.

For each SOUP item you have to identify it and its version, specify the functional and performance requirements you rely on, specify the hardware and software it needs, and evaluate its published known anomalies for whether they can contribute to a hazardous situation.

That last one is the requirement teams skip. Pulling a dependency means reading its open issue list with your own risk file in hand, and doing it again when you upgrade.

How it fits with ISO 14971 and SaMD

IEC 62304 does not define its own risk framework. It requires a risk management process conforming to ISO 14971 and hands the software questions to it: which hazardous situations can this software contribute to, what controls reduce them, and are those controls verified.

So the two are read together. The risk file identifies what the software could cause. The safety class sets how much process rigour that justifies. The documentation is the evidence both happened.

Where it goes wrong

• Class assigned optimistically. Choosing Class A because a hardware interlock exists, without demonstrating the interlock is independent.
• Segregation claimed, not shown. Separate classes for separate items requires documented segregation, not just separate directories.
• SOUP list assembled once. A dependency list generated at submission and never regenerated is wrong by the next release.
• Anomalies not evaluated. Listing SOUP without assessing its known issues meets the letter of nothing.
• Maintenance process absent. Common in teams who treat release as the end of the project rather than the start of the maintenance phase.
• Requirements that are not testable. Every requirement has to be verifiable, and "the interface shall be intuitive" is not.