Q&A: HANS WENNER
Dipl.-Ing. Hans Wenner is head of the Eurocat Institute for Certification and Testing in Rossdorf, Germany. Eurocat is a notified body under the Medical Devices Directive (93/42/EEC) and a certified software-testing laboratory according to DIN ISO/IEC 12119. Wenner earned his engineering degree at the Technical University of Darmstadt.
Q: Under the terms of the Medical Devices Directive (MDD), software can be considered a medical device and must, therefore, comply with the essential requirements. How should a manufacturer demonstrate compliance?
A: According to the MDD, software falls into the same class as the device that it drives and, as you mentioned, it consequently must show compliance with the essential requirements. The term software, however, does not actually appear in the essential requirements. The only reference can be found in Annex I, article 12.1, which states, "devices incorporating electronic programmable systems must be designed to ensure the repeatability, reliability, and performance of these systems according to the intended use. In the event of a single fault condition (in the system), appropriate means should be adopted to eliminate or reduce as far as possible consequent risks."
So the question becomes, how can repeatability, reliability, and performance be ensured in relation to the intended use? And the solution becomes clearer when one considers that software has different failure modes than hardware. All software errors are implemented during development, and to comply with the specified essential requirement it is necessary to control the development life cycle of the product. Appropriate documentation of the development process can be generated through EN 60601-1-4, the standard for programmable electronic medical systems (PEMS). It's important to note that you cannot test only the software in medical equipment--software and hardware cannot be looked at as separate entities.
Q: Various testing methods to show compliance are available. Is there one method that you favour?
A: Full testing is the most appropriate way to detect errors in a product. I should add that full testing does not mean checking every code--it refers to testing the entire development life cycle. That begins with the design specifications and ends with product validation after the system has been integrated. At the other end of the spectrum is audit-level testing, which audits the process of development and doesn't test the product itself. Product errors are rarely found using this method.
To determine a suitable test method, manufacturers should consider several factors. There's the expense involved, and full testing naturally will be the more costly. Then there's the method's effectiveness and, as I have already mentioned, full testing reveals the most errors. For a low-risk device, however, audit-level testing may be sufficient. Manufacturers should take into account how critical the product is and the number of units that will be produced, because the more units you have on the market, the more nonvoluntary "testers" you will have! And manufacturers should also consult their consciences.
Q:What about risk management? EN 60601-1-4 includes a risk management component, but smaller manufacturers may be reluctant to implement what they perceive as a complex task.
A: In my opinion, risk management, as it is described in the European standard, is a very useful tool. Adequate risk analysis and effective risk management can go a long way toward demonstrating compliance with the essential requirements.
For example, risk analysis results can be used to scale the volume of technical documentation. The risk estimation process that classifies a product's severity level as intolerable, ALARP [As Low As Reasonably Practicable], or broadly acceptable can determine how thoroughly the technical documents should trace the examined function. Where software is concerned, this may reveal that a cursory review of formal correctness may be sufficient to test a noncritical function of the program and that more time should be spent conducting a complete review, including intrusive testing, of the more critical functions. Risk analysis can help to organize and channel the available time to the functions that truly require in-depth testing.
For additional information, contact Eurocat Institute for Testing, Arheilger Weg 17, D-64380 Rossdorf bei Darmstadt, Germany; phone: +49 6154 699330; fax: +49 6154 699350.
