Software as a medical device - life cycle
The life cycle of the medical device is a development process of the product, from its beginning to the end. The same applies to software that can represent a medical device (SaMD) or a medical device that has software as its part.
Establishing the security and efficiency of such products requires knowledge of what the software is supposed to do and demonstration that the use of it achieves expected purposes producing no intolerable risks.
The standard that provides a framework of life cycle processes with activities and tasks that are necessary for the safe design and maintenance of medical device software is EN 62304:2006/A1:2015 Medical device software – Software life-cycle processes.
This standard doesn’t specify an organizational structure for a manufacturer or which part of the company should perform a certain process, nor prescribe a specific life cycle model. This standard requires only that the processes be completed to establish compliance with it and to document the outcomes.
EN 62304 requires the following processes to be implemented:
- Software development
- Software maintenance
- Problem resolution
- Risk management
- Configuration management
Software development
Planning takes place at the beginning of software development. The manufacturer prepares a comprehensive software development plan, which must be regularly updated depending on development progress.
The manufacturer has to analyze the software requirements. This includes documenting requirements such as functional and capability requirements, interfaces between software and other systems, security requirements, user engineering requirements.
The manufacturer must design relevant software architecture and subsequently describe how he intends to implement and integrate the software.
So, software development has its own life cycle, and it is a process for planning, creating, testing, and deploying the software.
Software maintenance
The software maintenance process begins with maintenance planning that includes procedures for receiving and addressing feedback arising after the software release, criteria for determining when the feedback is considered a problem, procedures to evaluate and implement upgrades, bug fixes, etc.
IEC 62304 then requires an analysis of problems and changes that have occurred in the software. Also, it describes how changes must be applied and released.
Software risk management
The manufacturer shall focus on components that could contribute to a hazardous situation, which can be the direct result of software failure or the result of the failure of the implemented risk control measure.
The hazard identification is followed by a consideration of risk control measures and their verification. Manufacturers should consider and analyze the risks of software changes.
Software configuration management process
The manufacturer shall establish a structure for the identification of configuration items and their versions should be controlled. A comprehensive analysis of identification, documentation, and approval steps guarantees the manufacturer can find, adapt, and trace the best possible configuration.
Software problem resolution process
The manufacturer should report and investigate each problem detected in the software. Also, it should advise involved parties about them depending on the situation.
Problem report records should be kept and also trend analysis of software problems should be conducted.
IEC 62304 requires manufacturers to assign a software safety class to each software, according to possible effects on the patient, operators, or other people resulting from a hazard that software can cause. The standard specifies a 3-class model entailing of safety classes A, B, and C.
Manufacturers apply the processes described above depending on the corresponding safety class.
The implementation of the standard presumes that the manufacturer develops and maintains software as part of a quality and risk management system.