Regulated SDLC: A Primer on IEC 62304

If your team comes from the world of traditional tech, you are masters of the modern Software Development Lifecycle (SDLC). You move fast, iterate quickly, and deploy seamlessly. But as you transition into creating Software as a Medical Device (SaMD), you encounter a new landscape governed by regulations and standards. The most important of these is IEC 62304.

At first glance, this standard can feel like a rigid set of rules designed to slow you down. But that’s the wrong way to look at it. Instead, think of IEC 62304 as a professional framework for building high-stakes software. It’s the difference between building a garden shed and constructing a suspension bridge. Both are valid structures, but one carries a much higher burden of safety and requires a more rigorous, documented process to ensure it performs as intended without causing harm.

This guide will demystify IEC 62304 and provide a clear, digestible roadmap for aspiring SaMD companies.

The Core Principle: Patient Safety

Why can’t you just use your existing agile process and ship code? The answer is simple: patient safety. When software can influence a diagnosis, deliver a therapy, or alert a clinician to a life-threatening event, the consequences of a bug are no longer just a bad user experience. They can lead to serious injury or death.

IEC 62304, recognized by the FDA, the EU, and other global regulatory bodies, provides a harmonized framework to ensure that medical device software is developed, tested, and maintained in a way that prioritizes safety and effectiveness. It isn't a prescriptive "how-to" manual but a set of required processes and objectives. Your goal is to integrate these processes into your SDLC, providing the evidence that you have built a safe and reliable product.

First Step: Determine Your Software Safety Classification

Everything in IEC 62304 flows from one critical starting point: the Software Safety Classification. This classification is based on the potential harm a software failure could cause. The more potential for harm, the more rigorous the requirements.

Class A: No potential for injury or damage to health is possible.
*Example:* A medical dictionary app or software that anonymously collects performance data for analysis.
*Requirements:* The lightest level of documentation is required.

Class B: Non-serious injury is possible.
*Example:* Software that analyzes a medical image to help a clinician spot anomalies. A failure could lead to a missed or delayed diagnosis, but it’s unlikely to cause immediate, serious harm.
*Requirements:* A significant step up from Class A, requiring more detailed design, testing, and risk management documentation.

Class C: Death or serious injury is possible.
*Example:* Software that controls the radiation dose in a radiotherapy machine or an algorithm that calculates and drives insulin delivery in an insulin pump.
*Requirements:* The most stringent level. This demands a comprehensive, meticulously documented process across the entire SDLC.

Your first regulatory task is to perform this risk-based analysis and formally declare your software’s safety class. This decision will dictate the scope of work for your entire project.

The Key Processes of IEC 62304

The standard is organized into several key clauses, but the heart of it lies in the processes that map directly to the software lifecycle.

1. Software Development Process (Clause 5)

This is the core of the standard, detailing the step-by-step activities required to build the software.

Software Development Planning: Before you write a single line of code, you must create a plan. This plan outlines the entire scope of the development effort, including the processes you'll follow, the deliverables you'll create, the standards you'll adhere to, and how you'll manage configuration and risk.

Software Requirements Analysis: This is where you define *what* the software must do. These are not just feature lists. Requirements must be clear, unambiguous, testable, and traceable. You need to detail everything from functional behavior and user inputs to security needs and performance benchmarks.

Architectural Design: Once you know *what* to build, you define *how* you will structure it. The architecture describes the major components of your software, how they interact with each other, and how they interface with hardware or third-party software. This high-level design must also address how you will mitigate risks identified in your analysis.

Detailed Design (Required for Class B & C): Here, you break down the high-level architecture into the specifics of each software unit. This is the level of detail a developer needs to implement a component without ambiguity.

Software Unit Implementation and Verification: This is the coding phase. As each unit is built, it must be verified. This usually means unit testing. The goal is to prove that the code you wrote correctly implements its detailed design.

Software Integration and Integration Testing: After individual units are verified, you begin combining them into larger components and subsystems. Integration testing ensures that these units "play nicely" together and that data passes between them correctly.

Software System Testing: This is the final testing phase of the fully integrated software. The goal here is to verify that the software meets the original requirements defined at the start of the project. This is the ultimate proof that you built what you set out to build.

Software Release: Before you can release the software, you must perform a final check to ensure all development, verification, and risk control activities are complete and documented.

2. Software Maintenance Process (Clause 6)

For medical devices, the lifecycle doesn't end at launch. The maintenance process is just as regulated as the initial development. You must establish a formal process for handling post-market feedback, including bug reports and feature requests. Any change, no matter how small, must be evaluated for its impact on safety and may require you to go back through the entire development process for that specific change.

3. Software Risk Management Process (Clause 7)

While ISO 14971 is the overarching standard for risk management for medical devices, IEC 62304 requires a specific focus on software risk. This is not a one-time activity. Risk management must be integrated into every stage of the SDLC.

Your process should include:

Analyzing software for potential hazards.
Implementing and verifying risk control measures (e.g., defensive coding, alarms, logic checks).
Evaluating any residual risk.
Analyzing the risk of any third-party software, known as SOUP (Software of Unknown Provenance).

4. Configuration Management Process (Clause 8)

This is more than just using Git. You must have a robust system to control all documentation and code. Every item, from a requirement document to a source code file, must be uniquely identified and placed under version control. This ensures traceability and creates an unimpeachable record of your entire project, which is critical for regulatory submissions and audits.

5. Problem Resolution Process (Clause 9)

You need a formal system for documenting, evaluating, and resolving problems discovered during development and after release. For each problem (or bug), you must assess its impact on safety and document the corrective actions taken. This process ensures that issues are not simply fixed and forgotten, but are handled with the appropriate level of rigor.

Can We Still Be Agile?

Yes, absolutely. IEC 62304 defines the *what*, not the *how*. You can absolutely use an Agile or Scrum methodology, but it must operate within the regulated framework.

Think of it this way: Your overall project can follow the V-Model of verification and validation, ensuring traceability from requirements to release. Within that framework, you can execute development in Agile sprints. Each sprint can have its own cycle of detailed design, implementation, and unit testing. The key is that the required documentation and formal reviews (like approving requirements before development) are treated as integral parts of the sprint definition of "done."

The Bottom Line: Documentation is Evidence

In a regulated industry, if it isn't documented, it didn't happen. Every step described above must generate a corresponding record. This documentation is not just bureaucracy; it is the auditable evidence that you have followed a robust process to build a safe product.

Embarking on your first SaMD project is a significant undertaking, but IEC 62304 provides the structure needed for success. By embracing its principles as a framework for excellence, you can build innovative software that not only meets regulatory requirements but also safely and effectively serves patients and clinicians.

---

*Navigating the regulated SDLC can be complex. If your team needs guidance on implementing IEC 62304, contact our experts to learn how we can help you build a compliant and efficient development process.*