Applying Risk in the MedTech Software Development Process
Software as a medical product has become a widespread approach, both as part of an embedded device and as a standalone application. This makes it an integral part of the booming healthcare industry overall. Medical devices (hardware and software) must assess the risks that the device may not work as intended, potentially putting patients in harm’s way and possibly causing serious harm or even death.
Unlike hardware, software risks due to the manufacturing and distribution process are generally not an issue. Almost all software errors occur or can be discovered during the development of the product so the software development process a medical company uses deserves extra scrutiny. Note that the software requirements are a subset of those required for Programmable Electrical Medical Systems (PEMS), and additional requirements from IEC 60601-1 apply to this technology.
To address the software development risks, medical device manufacturers are best served by instituting software best practice activities per IEC 62304. The IEC 62304 standard defines the requirements for the medical software product lifecycle and relies on ISO 13485 for processes that identify customer needs and customer need/design validation.
All of the design activities are designed to reduce risk by clearly identifying the requirements for the product, the method the design uses to meet the product requirements, and confirmation that the product requirements have been met before the software is released. The software risk class is defined for each product and is based on product and software risk assessments, the effectiveness of the mitigations, and residual risk. Software risk classes range from the lowest risk (Class A) to the highest risk (Class C).
The software development activities listed above are similar to those for other types of development and the activities required for all medical software are listed below. The level of detail required for these activities changes based on the risk the software product presents and the applicability based on risk class is found in Table A.1 in the software standard.
Software Product Planning
Software Requirements Analysis
Software Implementation
Software System Verification
Software Release
Software Configuration Management
Software Problem Resolution
Software Maintenance Process, including Change Management
Once the software is verified at the system level, it can be released. Although a separate software release process can be used, generally it is best to leverage existing Document Control procedures and tools.
For higher risk/Class B software the activities added are listed below; note that these may be done for Class A software even if they are not required. It’s also necessary to do a certain amount of product/high-level risk analysis to determine the software class, so the risk management activities for Class B, C are software design and implementation-specific.
Control of Tools and Items used to Develop Software [Class B, C]
Software Architecture Design [Class B, C]
Identification of Detailed Software Units [Class B, C]
Software Unit Verification [Class B, C]
Software Integration and Verification [Class B, C]
Software Risk Management [Class B, C]
Document Software Release Process and Known Anomalies [Class B, C]
The highest level of risk/Class C software adds activities for:
Software Standards, Methods, and Tools planning [Class C]
Identify Architecture Segregation for Risk Control [Class C]
Software Detailed Design and Verification [Class C]
Additional Criteria for Software Unit Verification [Class C]
Legacy Software
Software products that were not created under IEC 62304 compliant processes can be assessed following the new Legacy Software provision in IEC 62304:2015. This path allows legacy software products to demonstrate compliance to IEC 62304.
Post-Market Assessment
Post-market assessment of the software is also required, and again it is generally best to leverage the existing company complaint/customer feedback and assessment processes and the escalation and trending activities, such as CAPA, associated with these to indicate software changes are needed. Subsequent releases of the software can use existing Change Control procedures and tools and may be combined with hardware updates for embedded devices.