IEC 62304—software lifecycle for medical devices explained

IEC 62304 is the international standard for medical device software lifecycle processes. It is not a software quality standard in the abstract sense—it is an engineering framework that defines what records a software development team must produce, and how those records connect to the safety classification of the software being built. The standard's requirements are, for the most part, things good software engineering teams do already. The discipline it imposes is in making that work visible, traceable, and defensible to regulators.

Software safety classes: the classification decision that shapes everything

IEC 62304 classifies software items into three safety classes based on the severity of the hazardous situation that would result from a software failure, assuming all risk control measures external to the software item are in place.

Class A applies when a software failure cannot contribute to a hazardous situation, or can contribute only to a situation that results in no injury. Class B applies when a software failure can contribute to a hazardous situation that results in non-serious injury. Class C applies when a software failure can contribute to a hazardous situation that results in serious injury or death.

The classification is not determined by the software itself—it is determined by the risk analysis. This is the structural link between IEC 62304 and ISO 14971. You cannot assign a software safety class without first identifying the hazardous situations the software participates in, evaluating the severity of potential harm, and confirming which risk controls are external to the software item. Teams that try to classify software before completing a meaningful hazard analysis typically discover they have underclassified it when a notified body or FDA reviewer probes the reasoning.

The practical consequence of classification is the set of process requirements that apply. Class A requires minimal lifecycle documentation—essentially a software system test plan and results. Class B adds requirements for software architectural design, software unit testing, and integration testing. Class C adds requirements for detailed software design documentation and unit-level code review or testing at the detailed design level. The jump from Class B to Class C is significant in terms of documentation burden. Getting the classification right at the start of the program—not late in development—is an engineering discipline decision, not a compliance decision.

The software development process

IEC 62304 defines a software development process with six required activities: software development planning, software requirements analysis, software architectural design, software detailed design, software unit implementation and verification, and software integration and integration testing.

None of these are foreign to experienced software engineers. The standard formalizes what a well-run software team does naturally. Software requirements analysis means writing requirements that are testable—specific enough that a test can confirm whether the requirement is satisfied. Architectural design means documenting the major components of the system and their interfaces at a level of detail sufficient to partition the system into software items for unit development and testing.

The area where teams most often create compliance gaps is in the traceability between levels. IEC 62304 requires that software requirements be traceable to software system tests, that architectural design be traceable to requirements, and that unit tests be traceable to detailed design. Traceability is not an abstract compliance exercise—it is the mechanism that lets you answer the question "what could go wrong if this function fails?" with engineering evidence rather than opinion.

SOUP management

Software of Unknown Provenance (SOUP) is any software item that is already developed and not developed for the purpose of being incorporated into the medical device. That includes open-source libraries, commercial off-the-shelf components, operating systems, and third-party APIs. SOUP management is one of the most practically demanding aspects of IEC 62304 for modern software teams, because contemporary medical device software is built on a significant SOUP stack.

IEC 62304 requires that SOUP items be identified by title, manufacturer, and version. It requires that the functional and performance requirements that the SOUP must meet be documented. It requires that known anomalies—bugs, errata, known limitations—be evaluated for their impact on the software item's ability to perform its intended function. And it requires that the potential impact of SOUP anomalies on safety be assessed within the risk management framework.

In practice, this means maintaining a SOUP inventory that is version-controlled, linked to the risk file, and updated when SOUP items are updated during development or post-market. Teams that manage dependencies through a package manager have the raw data—what they typically lack is the process that connects dependency updates to risk evaluation and design change review.

Configuration management and problem resolution

IEC 62304 requires a configuration management plan that identifies and documents the software items under configuration control, describes the method for uniquely identifying software items and versions, describes the method for tracking the status of software items, and describes the method for ensuring that only approved versions of software items are used. For teams using modern version control with branching strategies and release tagging, the technical infrastructure already exists. The gap is usually in the process—ensuring that build artifacts are reproducible, that release versions are locked before system testing, and that post-release changes go through the problem resolution process.

The problem resolution process (software maintenance under IEC 62304 clause 6) requires that software problems be evaluated for safety impact, that problems affecting safety be prioritized and resolved, and that changes made to resolve problems be subject to the same design control requirements as original development.

How MANKAIND supports the software development lifecycle

MANKAIND connects the software development lifecycle to the broader engineering record. When a software requirement is created in the platform, it is linked to the system-level design input it satisfies and to the risk items it participates in—giving the engineering team a live view of the traceability chain. When a SOUP item is added to the project, MANKAIND prompts the team to capture the functional requirements the SOUP must meet and surfaces the relevant anomaly evaluation workflow.

When a software change is initiated—whether a feature addition, a bug fix, or a SOUP update—MANKAIND evaluates its footprint across the requirement, risk, and design record and generates the change evaluation documentation that IEC 62304 and 820.30 require. The software development lifecycle stops being a documentation problem and becomes an engineering intelligence problem that the platform is built to handle.