In our last few posts, we discussed the requirements around basic safety and essential performance as well as risk management in the development of medical devices. But these are just the start of ensuring the compliance of a medical device. In this post, we will discuss IEC 62304, medical device software – software life cycle processes.
A company may tell you that they understand the ins and outs of regulatory compliance in outsourced product development, but do they really? Anyone who has done the research on any of the regulatory requirements knows that they are detailed and full of depth. The “consolidated version” of one of the documents is over 176 pages! A deep understanding of regulatory, its impact on product development, and what it takes to comply requires years of working on these types of projects and a dedication to truly understand what is needed to bring a medical device to market.
As an example, IEC 62304 deals with “Medical device software – Software lifecycle processes.” This detailed document addresses the critical role that software plays in modern medical devices. Software often controls the functionality of the device and in many ways contributes to safety and performance. Properly functioning software becomes critical to the medical device. IEC 62304 has been implemented to ensure that software is developed to standards.
At a high level, IEC 62304 provides guidance in the following software development process areas:
- Development – This section addresses points such as the need to have a plan for development that is regularly updated and defines the components of the development of the software, how verification will be done, as well as the plans for risk management and proper documentation. It further identifies guidance for design, integration testing and system testing, as well as the release process.
- Maintenance – Maintenance addresses items that would typically be needed post go-live of the software. What is the maintenance plan, how will problems be addressed and how will modifications be identified and implemented.
- Risk Management – Risk Management highlights the need to identify any hazards the software could case, address how those risks should be mitigated, and ensure that the mitigation strategies are appropriate, extending to any software changes.
- Configuration Management – The configuration management section addresses requirements such as the need to identify configuration areas of the software, how change control will be managed, and the documentation needed.
- Resolution/Defects Management – This section discusses the requirements around problem resolution and any defects in the software. At a high level, it identifies the need for problem reports, an investigation process that includes the appropriate stakeholders. In addition, the section notes the need for change control and documentation, as well as analysis of any recurring issues.
This high-level overview only scratches the surface of what is required for compliance with IEC 62304. Companies that speak confidently about their 62304 expertise need to prove a level of depth in each of the above areas and prove that they have processes in place that are compliant to 62304. In the coming months, we’ll be exploring each of these areas in greater details.
To learn more about Resolution and our Quality Systems, visit www.resolutiondev.com