IEC 62304 is an international standard that defines the life cycle requirements for medical device software. It provides a framework for the safe design and maintenance of software used in medical devices, ensuring that risks are managed effectively throughout the software’s life cycle. Its important to stress that 62304 discusses software in a medical medical (SIMD) , i.e. sofware that is intended to be part of a medical electrical equipment.
This article aims to help readers understand IEC 62304 by exploring it through the lens of the V-model—described in 60601 and other systems and software engineering standards. This approach makes it easier to see how IEC 62304 fits within the broader context of medical device development, especially in relation to standards like IEC 60601 (Electrical Saftey and Performance), ISO 14971 (Risk Management), and ISO 13485 (Quality Management Systems).
The V-Model from 60601
In the context of medical electrical equipment, IEC 60601 introduces the concept of Programmable Electrical Medical Systems (PEMS), which encompasses all programmable components that can affect the safety of the device. The V-model described in IEC 62304 is actually a specialization within this broader PEMS development process. Specifically, IEC 62304 focuses on the software aspects, treating Software as a Programmable Electrical Subsystem (PESS) under IEC 60601.
This means that while IEC 60601 addresses the overall safety and risk management of the entire medical device—including hardware, software, and their interactions—IEC 62304 zooms in on the software component, providing detailed requirements for its life cycle. The V-model in IEC 62304 ensures that software development and verification are systematically integrated into the larger PEMS process, supporting the overall safety objectives defined by IEC 60601.
The V-Model adapted in IEC 62304
62304 builds on the relationship between development and testing phases from 60601 . Before we dive into the V-Model, its a good idea to understand how to read it.
- In the V-Diagram above, the solid boxes represent activies or processes to be conducted , and the boxes on the arrows represent deliverables (documents code etc.) from these activties.
- The standard makes use of the term of plan and specifications. A good way to think about this is that a plan is how to do something wheras a specification is what is needed.
- Another duality is that of requirement specification and test specification. Every requirement needs a map back to one or more higher level requirements, and every test procedure must back to one or more requirement. In other words the raison d’être for a requirement is higher level requirements, and for test procedures its requirements.
- In the context of 60601 the left half of the V deals with requirements decomposition, and the right side deals with verification of each of the requirements. In a sense, at every level, each requirement needs to derive from an upper level requirement and needs to be verifiable or validateable via a verification test specification.
- In the context of 14971 the left half deals with Risk analysis and the right half deals with Risk Control during the development and maintenance phase.
- In the context of 13485, the various activities need to feed data bidirectionally about any problems observed during development or usage of the Medical Electrical device.
Activities carried out under the V-Model for 62304
1. Requirements Analysis (From User Needs, PEMS, and PESS)
This goal of this activity is to define software system requirements based on user-needs, system-level or subsystem requirements. This results in the creation of the Software-System Requirements Specification (Software SRS). Each requirement needs to (ideally) map to a PESS requirements specification, which in turn maps to a PEMS requirements Specification, which in turn needs to map to User needs. However, in practice, this is difficult as the software often directly interfaces with the User. In a practice, the Software SRS may directly derive from User needs, whereas the PEMS and PESS may be viewed as non-functional requirements or constraints.
This activity also needs to result in the creation of a subsystem test specification. While this is an activity outside the scope of 62304, its important to understand the intent. This test specification intends to map the how the Software SRS is meeting the upstream requirement, originating from the PESS or PEMS or User Needs. This also needs to document any test procedures to verify that the upstream requirements are met. These test procedures are at a higher level in that they do not directly verify the items of Software SRS. That direct verification will be done in other activities.
It is important to identify the source of each requirement—whether it stems from basic safety, essential performance (IEC 60601), or risk management (ISO 14971)—because this determines the level of rigor and documentation needed. Requirements unrelated to safety or performance and not posing risks to the users, such as those for advertising/branding or inventory management, may not require the same traceability or verification activities as those impacting patient safety or device performance.
2. Software Architecture Design
In this activity, the goal is to develop a high-level Software Architecture Specification that outlines the software’s structure.
Part of the activity is to identify software Units which are then grouped into software items, kind of like in a tree structure. In this analogy the, leaves are software units and internal nodes are software items. The root being the Software System is also a Software Item . The standard itself leaves the definition of what a software unit is to the Manufacturer. One could think of the unit could be a method, class, or library.
Apart from the specification, its a good idea to document the coding and documentation conventions and guidelines in as well. One may think of this combined document as the Software Architecture Design Document (Software ADD).
In essence this design activity results in an architecture specification and a plan on how it’s recommended to be implemented.
Its also a good idea to document the programming tools and the source code repository and the branching structure to be used etc.
Another aspect that should ideally be documented is the UI conventions, design language etc.
The UI designs like screens themselves may be seen as software units and composed into items.
This activity also needs to define a software test specification, or Software Integration Test Procedures (Software ITP). Ideally, each test procedure is mapped to one or more Software SRS requirements and vice versa.
The standard provides guidance on the usage of external software components referred to as SOUP, an abbreviation for Software of Unknown Provenance. Its useful to think of SOUP as a software Item.
SOUP refers to software components or products that were not developed according to the requirements of IEC 62304.
This includes third-party libraries, open-source modules, or legacy code where the development process and documentation are not fully known or controlled.
In IEC 62304, SOUP must be identified, assessed for potential risks, and managed appropriately. This involves evaluating how SOUP could impact the safety and effectiveness of the medical device software, and implementing risk controls as necessary. The use of SOUP is common, but it requires careful documentation and justification within the software development life cycle. One way to meet this is to document SOUP in the Software ADD and record test procedures in the Softwre ITP to verify that the SOUP meets requirements.
3. Software Detailed Design (Implementation)
In this activity, the goal is to create a detailed design for individual software units. The output of this is software implementaion, or the code itself. Care should be taken to implement and document as per the design and guidelines in the Software ADD. Also, its imporant to maintain copies of release versions of the software. It should be complete with documentation.
A best practice at this stage is to prepare unit test plans and, where possible, implement automated tests for each software unit. Care should be taken to test as necessary, as opposed to test driven development to test everything. Oftentimes, test maintenance should be simple.
4. Software Unit Verification
This activity is derived from the implementation and the test specification established during the earlier phases. The results of these tests should be documented and analyzed, with any issues or failures feeding forward into the risk control process. The output of this is the verified code, which would ideally be part of the source code repository, possibly on a separate branch.
5. Software Integration and System Verification
This activity involves mostly putting the Software System together and running the Integration Test Procedures. Often the integration test specification will contain regression test procedures which will test for any collateral changes.
6. PEMS Validation
While this could be considered out of scope of 62304, it is still essential to the development cycle is the Validation Step. It’s a good practice to have user validation either from sales teams or internal users to ensure that the system meets the user needs, and specifically the software needs which are documented to be tracked by the 62304 are being met.
As described before these will relate mostly to the essential performance of the device. The implicit saftey and risk aspects need to be validated if there is any impact or on a periodic basis.
Software teams are usually engage in a User Acceptance Testing (UAT) process. A more formalized approach with appropriate specification and documentation helps align this activity.
Conclusion
IEC 62304 provides a robust framework for the development of medical device software, ensuring safety and compliance. Whether using the V-model, the waterfall model, or agile methodologies, the standard can be adapted to suit different development approaches while maintaining its focus on being a subsystem of a PEMS (60601) as well as focus on risk management(14971) and quality assurance (13485).
