Medical Device Software Development:

Transcription

1 Intertek Cleeve Road, Leatherhead, Surrey KT22 7SB UK

2 Medical software Many electrical medical devices are like household appliances in some ways and in particular the way in which technology is used to provide a user interface and the way in which the operation of the device is controlled. The overriding technology in this respect is, of course, computers. Computer hardware reliability has its issues but being hardware can be handled in traditional ways of design and verification of the design by test. Software on the other hand is a relatively immature technology and therefore verification is not as robust as traditional methods. New methods of design and verification have had to be developed. A home computer crash is frustrating and a work server crash similarly, but perhaps with more consequences; but both are somehow expected, and therefore somewhat acceptable. But when a medical device fails to maintain life support or provides an erroneous diagnosis; this is clearly less acceptable. It is essential therefore that software for medical applications is developed in a disciplined manner. IEC Medical device software, software life cycle processes is the process standard that governs the development of software for medical devices. Standardisation Regulation of software in medical devices has lacked pace compared with the automotive, aeronautical and military industries. However, in 2006 the publication of IEC62304 became a major milestone in addressing this problem, providing a safety standard for the design, compilation and maintenance of medical software. It was derived from ISO/IEC12207 Systems and software engineering Software life cycle processes, but was tailored to the medical device sector, in particular by focussing on safety issues. IEC62304 defines the life-cycle requirements for medical device software, and states: 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. 1

3 This standard does not cover validation and final release of the medical device, even when the medical device consists entirely of software. The latter refers to the fact that validation is applicable to the final medical device and so is out of the remit of this standard. One crucial requirement of this standard is that the software life cycle development processes must be within a manufacturer s quality management system. IEC62304 has become the globally accepted standard for demonstrating safe design of software in medical devices and EN62304 (which is identical to IEC62304) is a harmonised standard in the EU and helps manufacturers meet part of their obligations under the EU Medical Devices Directive. Applicability IEC : 1 - Medical electrical equipment -Part 1: General requirements for basic safety and essential performance is referred to since, unless the software is standalone, it will be part of an electrical medical device and so compliance with this standard will be seen to be mandatory. IEC states that IEC62304 does not apply to Class A software; a sensible approach from a risk management viewpoint. For a medical device containing software, IEC62304 is a mandatory standard and applies to a Programmable Electrical Medical System (PEMS). A PEMS is defined as containing a Programmable Electrical SubSystem (PESS), and a PESS is defined as containing a Central Processing Unit (CPU). It is noteworthy that Programmable Logic Controllers (PLC) or Field Programmable Gate Arrays (FPGA) do not usually contain a CPU and therefore IEC62304 is not applicable to medical devices containing only these. Of course development of software to manufacture PLCs and FPGAs must be controlled but this is an ISO13485 issue rather than an IEC device issue. 2

4 Software Classification Classification of the software is required and is based on the consequences of a software fault: 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. Most medical device software in low to medium risk devices will be Class B. It is unlikely that Class A software will be used. Risk Management A medical device manufacturer must perform risk management and part of this is assessing probabilities of the occurrence of faults and their consequences. It is generally accepted that errors may lurk in software no matter how much testing is performed and so to be safe failure should be considered as so likely as to be considered normal rather than a fault condition. IEC62304 states that if death or serious injury can occur from a software fault then the software is Class C, which then clearly needs redundancy or hardware protection to prevent the hazardous situation arising. Further, IEC requires that medical devices must be safe in single fault conditions, but also that combinations of faults must be considered. It is possible to have modules of different classification within a complete software system: SOFTWARE SYSTEM / (CLASS C) X (CLASS A) Y (CLASS C) W (CLASS B) Z (CLASS C) IEC724/06 3

5 The system is classified as Class C because there are Class C modules, but the lower class modules can be developed with less effort if they do not impact on the operation the Class C software in any way. Design and Verification The manufacture s quality system is required to have a problem resolution process which is a recognition that errors in the design of software are likely to be more common than those in hardware design. Software of Unknown Providence (SOUP) is allowed but must be dealt with appropriately. In particular it has to be considered that failure is a normal condition and so there must be other software or hardware protection systems in place. Legacy software can be considered as SOUP, and a proposed revision of IEC62304 addresses this aspect specifically. As with all process standards, documentation is crucial; compliance with IEC62304 can only be established by detailed study of such documentation. 1) The software development plan, integration plan, including testing, verification plan, risk management plan and software configuration management plan must all be documented. 2) The software requirements including risk control measures must be documented and verified. 3) The software architecture including description of software items and how they interface must be described and verified; this must be detailed down to software units (that which is not subdivided into other items). 4) Additional software unit acceptance criteria are required for Class C software. 5) Test results on software units and their integration must be documented and must verify the plan, and regression testing must be performed when software items are integrated into previously integrated software. 6) Configuration management must be performed and documented and there are readily available computer programs that are suitable for this. Of course this process must be part of the quality management system as are any processes concerning software design and test. Rubbish in rubbish out always applies, but good quality in rubbish out must be avoided by the use of good quality validated software development tools. IEC requires that software development and test tools are suitably 4

6 validated. This often causes manufacturers concern since these validation requirements are not specified. However the use of industry standard packages is generally acceptable. System Processes A large proportion of safety alerts recently have been attributed to usability and this is a crucial concern in software design. IEC62366 application of usability engineering to medial devices, must therefore be considered alongside IEC/ EN IEC , IEC62304, ISO14971 and IEC62366 are all intrinsically linked and should be controlled under an ISO13485 system. Relationship of key medical device standards to IEC

7 Summary It is difficult to avoid following IEC62304 when developing medical device software, whether it be standalone or embedded in a medical device. The standard is both globally accepted and is also a harmonised European Standard locally. There is little in the standard that is revolutionary and most software manufacturers should already be following similar processes, and therefore conversion to IEC62304 should not be a huge task. Informative Annex B to IEC62304 offers guidance on application of the standard and gives good background information. A more recent standard, IEC/TR Guidance on the application of ISO14971 to medical device software will also be helpful. Annex C is a comprehensive description of the links to the other standards mentioned above. Annex D offers a simplified way of integrating requirements of IEC62304 with ISO13485 for small companies with a respectively simple quality system. For more information on specific testing and certification information, please contact Intertek at WORLDLAB, icenter@intertek.com, or visit our website at This publication is copyright Intertek and may not be reproduced or transmitted in any form in whole or in part without the prior written permission of Intertek. While due care has been taken during the preparation of this document, Intertek cannot be held responsible for the accuracy of the information herein or for any consequence arising from it. Clients are encouraged to seek Intertek s current advice on their specific needs before acting upon any of the content. 6