When Your Life Depends on Software

Transcription

1 Published on Quality Digest ( Home > Content When Your Life Depends on Software IEC imposes requirements on software for medical devices. We re all aware of the importance of safety testing for medical products, both for implantable devices and external devices used to monitor or sustain us when we re in the hospital. In the past, emphasis has been on the hardware-safety aspects of external medical equipment. Are they foolproof? Are there built-in safety mechanisms that prevent the device from causing harm through electrical shock or other forms of electrical or electronic malfunction? Until a few years ago, little thought was given to the software that is an increasingly crucial part of these devices. Over time, however, the software that controls many electronic diagnostic and life-critical electronic equipment has grown in importance, to the point where a software failure could be just as catastrophic, and life threatening, as a hardware failure. A software crash on your laptop simply means a reboot. A software crash on a piece of equipment helping to keep a patient alive is another problem altogether.

2 Fortunately, the issue has not gone unnoticed. In 2006, the International Electrotechnical Commission (IEC) published IEC Medical device software-- Software life-cycle processes. As described by the IEC, the standard: Defines the life-cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life-cycle processes. Applies to the development and maintenance of medical device software when software is itself a medical device or when software is an embedded or integral part of the final medical device. This standard does not cover validation and final release of the medical device, even when the medical device consists entirely of software. The Medical Device Directive falls short The number of medical electronics products that contain or wholly consist of software-- from built-in software to large image processing systems--is growing steadily. However, the regulatory situation concerning software in medical electronics is confusing. In the European Union s Medical Device Directive (MDD), there are only a few references among the more important requirements that can be directly attributed to software. But there are also a number of requirements that may be perceived as being indirectly applicable to software. There have been some recent revisions to the MDD that will clarify certain matters. One such change is the new introductory phrase to clause 12.1a of Annex 1: For products that contain software or that are in themselves medical software, the software must be validated in accordance with the latest recognized knowledge within the area and with consideration given to the principles of development life cycle, risk handling, validation and control. But what is the latest recognized knowledge? IEC 62304: an extension of the ISO standards The IEC standard for software life cycle processes may offer a partial answer to the question. This standard describes the framework for life cycle processes, with activities and information that are necessary for the safe design and maintenance of medical software. Though not described as a formal requirement, the standard nonetheless assumes that development and maintenance take place within the framework of a quality management system and a risk management system. Basically, this means that the software developer must be in compliance with ISO Medical devices--quality management systems--requirements for regulatory purposes, and ISO Medical devices--application of risk management to medical devices. The IEC standard further develops the requirements in the stated standards and reinforces, or adds, new requirements.

3 There is also reference to the third edition of IEC Medical electrical equipment--part 1: General requirements for basic safety and essential performance. IEC includes and adds to the requirements regarding programmable electrical medical systems per section 14 of IEC As far as we can see, there are no conflicting requirements, meaning that IEC can be used to show fulfillment of corresponding requirements in the third edition of IEC No special model The IEC standard does not apply only to software development. Because many incidents involving software can be attributed to service, maintenance, unsuitable updates, and upgrades, the standard also contains requirements within these areas. The software maintenance process is regarded as being just as important as the development process. The standard also identifies two other equally important processes: configuration handling and problem handling. As with all system- oriented standards, no special organizational structure is described, nor is it specified that any particular development model is to be employed. It is up to the manufacturer to select a suitable development model and ensure that it contains the processes, activities, and information that the standard requires. Classification of software An interesting aspect of IEC is that it is the manufacturer s responsibility to classify the software with regard to safety. The standard specifies three classes based on the danger to which the software can expose patients, operators, or other persons. The classification is therefore based on risk management and the seriousness of the injuries the software may cause: Class A: No serious injuries or ill health can arise. Class B: No serious injuries are possible. Class C: Death or serious injuries are possible. Serious is defined as injury or illness that is directly or indirectly life-threatening, results in permanently diminished bodily function or permanent injury to a body structure, or requires medical or surgical treatment to prevent permanent impairment or injury. Hardware provides protection Another condition mentioned in IEC is that if a dangerous situation can arise as a result of a software fault, the likelihood that the fault will arise is considered to be 100 percent. Thus, the measures that are taken based on risk management must focus upon reducing the consequences of such a fault arising. In reality, the only way of reducing the probability is to build in protection in the form of hardware. The classification may also be lowered by including safety in the form of hardware. In the case that no safety class has been defined for the software or a part of the software, the highest class applies. This classification is then used to determine which of the

4 standards requirements are relevant in terms of application. Higher classes mean additional, tougher requirements. If the software consists of different parts, each of those parts has to be classified. The total classification for the system is then the highest class of any of its parts. Development and maintenance The descriptions and requirements of the various processes are numerous and detailed. The development and maintenance process similarities are striking. More or less the same activities are to be carried out, regardless of whether they concern a new development or a modification of existing software. Even the smallest bug fix must follow the same process. Development models that treat corrections and bug fixes often follow completely different procedures from those that apply to new development. This may be the reason that many discovered errors are due to defects that have been introduced after the original product has been released. There are configuration-handling requirements, for both new development and maintenance, which aim to constantly track the versions that exist at both the system level and in included subsystems or software components. Tracing the versions of software that have been released, and which components/subsystems are included, must always be possible. Reconnecting released software Monitoring feedback from the use of released software is included in the IEC requirement for issue- resolution processes. It is a direct parallel to the requirements that are present in the MDD. There is also a connection to the requirements of reporting to authorities and vigilance, by means of the manufacturer s obligation to inform the user and authorities about problems in released software and the consequences of continued unaltered use, as well as to inform them of any available upgrades of the software (including how the user can gain access to and install them). This is well in line with the latest edition of MEDDEV revision 5-- Guidelines on a medical devices vigilance system. Conclusion IEC will be a useful and much needed complement to ISO and ISO Software manufacturers should implement the requirements in the beginning phases of new product development. This is critical. As the software industry has learned, the key to reliable software lies in the design and development phase. Unlike hardware products, it is virtually impossible to verify software after the fact. This article was adapted from the original article that appeared in the Swedishlanguage Intertek publication MedTech Info (Issue 3, 2007). Article 2009 Quality Digest Magazine. All Rights Reserved.

5 Home the Insider Videos Magazine Resources Search Subscribe Advertise About Us Source URL (retrieved on 11/04/2009):