Modern medical devices have shifted from standalone hardware to integrated software systems. This embedded logic is no longer a secondary feature; it is the primary engine driving clinical performance and patient safety. As technologies like Artificial Intelligence, cloud-based diagnostics, and robotic-assisted surgery become more prevalent, software complexity scales, and with it, the potential for systematic failures.
To mitigate risks, IEC 62304 was established as the framework for medical software development. Its basic premise is that security must be integral to software architecture. It should not be an add-on introduced during the testing phase. The norm focuses on a process-oriented approach to safety, focusing on risk-informed decisions and bidirectional traceability from start to finish. Because it is recognized by both the U.S. FDA and the EU’s MDR, it guarantees that medical software aligns with top-tier international benchmarks.
What is IEC 62304?
The architecture of IEC 62304 is designed to operate within a broader ecosystem of quality and risk management standards. It assumes that the manufacturer operates under a comprehensive Quality Management System (QMS), usually aligned with ISO 13485, and utilizes a robust risk management process consistent with ISO 14971.
IEC 62304 addresses the lifecycle processes of software for medical devices, which include development, maintenance, risk management, configuration management, and problem resolution.
The standard distinguishes between several key entities in the software hierarchy. The software system is the highest level of development that is subjected to final system-level verification and release protocols. Software items are any identifiable parts of the software system, allowing for modular risk classification and architectural segregation. Finally, software units are the lowest level of decomposition, a primary target for unit verification and detailed design in Class C devices.
The standard provides a set of requirements that software needs to fulfill, based on the safety class it is assigned.
What is IEC 62304 software classification?
Software safety classification defines the compliance requirements for each IEC 62304 software item. While FDA device classes (Class I, II, or III) consider both safety and effectiveness, IEC 62304 software classification is determined strictly by the severity of potential harm. It assumes a failure will occur regardless of its probability.
Based on this worst-case scenario, the standard assigns the software system one of three labels. Manufacturers may lower a software’s safety classification by implementing external hardware risk controls. These independent measures must effectively prevent any software failure from resulting in patient harm.
What are class A, class B, and class C devices?
In the world of medical device software, IEC 62304 breaks everything down into three safety classes, depending on how much harm a glitch could actually cause.
- Class A is for the low-stakes stuff. Software that simply can’t cause any physical harm or health damage. Since the risk is minimal, the requirements are too. You focus on basic lifecycle documentation and system-level testing, which helps get these non-critical utilities to market much faster.
- Class B covers software that might cause a minor, non-serious injury. Here, the documentation is more of a middle ground. You need a clearly defined architecture, and you have to run (and record) unit-level tests to show that every component is doing exactly what it’s supposed to do.
- Class C is the most critical tier. We’re talking about software where a failure could literally be a matter of life or death, or at least cause a very serious injury. Because the stakes are that high, Class C requires the most intense scrutiny. You have to document the design of every single software unit and prove “full code coverage” – basically making sure there’s no “dead code” or untested paths hiding in the system.
By segregating critical control algorithms from user interfaces allows for varied software safety classifications. This modularity limits high-intensity testing and documentation to the most critical system components.
How the V-Model supports IEC 62304 compliance
Once we have establish the software safety classes, we apply the appropriate development rigor. We implement a V-model framework to ensure all Class B or C requirements are met. This process guarantees that every high-risk item is thoroughly tested. It provides a structured approach to mapping development activities against their corresponding verification tasks and guarantees bidirectional traceability.
The V-model represents the software lifecycle in three primary stages: design, implementation, and verification. Left side involves decomposing system specifications into granular software requirements. These requirements then transition into an architectural design consisting of specific software units.
At the lowest point of the “V” lies implementation, where the actual coding takes place, strictly following the previously established specifications. The final verification phase is represented by the right side of the letter “V.” It focuses on the integration of parts and their verification. This is where the V-model truly shines for IEC 62304 compliance, as it enforces the rule that every level of specification on the left must have a corresponding level of testing on the right.
Software of Unknown Provenance (SOUP) in Medical Devices
In the world of modern software, developers rarely start with a blank canvas. To move faster and build more effectively, they often lean on established foundations like Windows or Linux, or pull from the vast world of open-source libraries. In the language of IEC 62304, these third-party building blocks are known as Software of Unknown Provenance (SOUP). Because these components weren’t born within a manufacturer’s specific Quality Management System (QMS), they enter the device as “black boxes.” Without the same rigorous design controls as the rest of the code, their inclusion creates a risk that we have to systematically manage to keep patients safe.
To manage risks properly, developers create a Software Bill of Materials (SBOM) as a master inventory of the supply chain. Specifically, for every piece of SOUP included, the SBOM records the title, manufacturer, source, and exact version. Beyond a simple list, each component requires its own defined performance boundaries. Developers must define the exact resources like processor speed, memory, or bandwidth the SOUP needs to thrive. This ensures the component is operating in the environment it was designed for, preventing the unexpected crashes that happen when a system runs out of breath.
Integrating these external tools is an ongoing commitment to risk management. Manufacturers have to stay vigilant, constantly evaluating known bugs or anomalies tied to their SOUP to see if they pose a threat to the person using the device. If a known flaw could lead to a system failure, the manufacturer’s job is to build “safety nets” or architectural mitigations within their own code. This prevents a failure in the SOUP from ever reaching the patient and causing clinical harm.
IEC 62304 lifecycle process phases
While we often visualize the standard through the V-model, the actual work happens in distinct, sequential phases. The rigor of each phase depends entirely on the software’s safety class. The goal here is a “safety-first” engineering mindset building quality from the start rather than trying to “test” bugs out of the product at the very end.
The Software Development Plan
The Software Development Plan (SDP) defines the lifecycle model, deliverables, and specific tasks. For Class B and C devices, the SDP must specify testing tools and integration strategies. Following the SDP, the Software Requirements Analysis phase derives technical requirements from system-level needs. IEC 62304 requires these requirements to be unambiguous, identifiable, and testable. During this phase, developers must establish a bidirectional traceability matrix linking requirements to system hazards or clinical needs.
Software Architectural Design
Following the requirement phase, the team moves into Software Architectural Design, which defines the structure and the interfaces between software items. For class B and C, documenting the data flow is mandatory. This step ensures the use of safe architectural principles, allowing developers to effectively segregate high-risk modules from low-risk utilities. For Class C devices, the standard extends this rigor into Software Detailed Design. This requires developers to explicitly define how the smallest functional units of code will operate.
Software Unit Implementation and Verification
The final phases transition from design into execution and mathematical proof. During Software Unit Implementation and Verification, developers write the code and test those individual, granular units. Next comes Software Integration Testing to prove that the interconnected architectural modules communicate safely without causing memory leaks or data drops.
Software System Testing
Software System Testing is conducted to prove the assembled product meets all original requirements without introducing clinical hazards. These final verification stages require specific test protocols, anomaly tracking, and strict release checklists based on safety class. Consequently, navigating these requirements successfully requires a well-documented approach.
Benefits of IEC 62304 implementation
While following all the requirements can seem daunting and it is almost impossible to introduce a medical device to the market without implementing IEC 62304, it also has its benefits. Foremost, it significantly streamlines the regulatory audit process by structuring documentation exactly in the way it is expected by MDR and FDA.
Thanks to that, manufacturers experience shorter audit times and faster path to market. Compliance with IEC 62304 requires modular architecture and early-stage design, which improve overall code quality and maintainability. This effectively reduces technical debt, making future updates and bug fixes much easier to implement over the device’s lifecycle.
Finally, the inherent focus on the worst-case scenario risk assessments provides verifiable paper trail of proactive safety measurements, which lowers legal and financial risk by proving that patient safety was engineered into software from the very beginning.
Frequently Asked Questions
IEC 62304 ensures good code quality and proper testing, while ISO 13485 is a medical device quality management system that defines how to build and maintain the software. In order for the device to make it to the market both standards must align with each other.
Yes, Agile development can be used with IEC 62304, since the standard defines what tasks must be performed, but it doesn’t dictate how or in what specific sequence they must be executed.
Yes. If your mobile application meets the regulatory definition of a medical device, it is classified as Software as a Medical Device (SaMD), and IEC 62304 strictly applies to its development just as it would for hardware-embedded software.
Looking for a medical software development partner?
Navigating IEC 62304 compliance is a non-negotiable part of bringing medical software to life, but it doesn’t have to stall your innovation. At WizzDev, we provide the specialized engineering support needed to align your design and development with strict regulatory standards. Our expertise includes the development of embedded systems and secure cloud integrations, focusing on system reliability and compliance.
We manage technical requirements of the standard, including software architecture, bidirectional traceability, and unit and integration testing. Whether you are whiteboarding a new prototype from scratch or need a partner to refine an existing project, we provide the technical and regulatory support necessary to guide your product safely through every stage of the development lifecycle.
