The problematic case of medical software?

The sector software manufacturers had in fact been expecting a clarifying word from the Medical Devices Expert Group (MDEG) of the European Commission this spring. The committee had wanted to comment on the placement of medical software into the various risk classes.  

At least since the amendment of the German Medical Devices Act (MPG) in March 2010 complaints have been aired concerning the lack of classification criteria and readily comprehensible examples for the functional separation. But the document hoped for has failed to materialize for the time being because the responsible parties could not agree on a common line of attack.

The representatives of the German Länder had differing opinions on the amount of leeway to be given to manufacturers deciding on placement into the risk classes. Because the discussions have taken on this fundamental character, there will not be any changes before the next session of the MDEG at the end of November.

Until that time, each manufacturer, working with its advisors, must determine the classification according to the intended purpose that it gives this product. Although the fact that the word “software” has been included in the wording of the law has not actually resulted in much of a change, this step fundamentally only clarifying that the manufacturers of standalone software must naturally also comply with the MPG, the discussions of, for example, whether or not the HIS (hospital information system) is a medical device continue.

Christoph Isele, head of the MPG work group at Bundesverband Gesundheits-IT (bvitg) is of the opinion that the question of whether or not the HIS already goes a half a millimetre beyond the limits of the MPG at some point or other is not at all as critical as the question of which functions a modern, attractive HIS needs and how it can provide relief for physicians. He justifies his reasoning as follows: “Usually when new functionalities are developed, there is an endeavour to better support the doctors in their work. This alone is enough to cause the number of software products whose intended purpose falls into the regulated area to inevitably increase.”

A decision tree from the COCIR (European Coordination Committee of the Radiological, Electromedical and Healthcare IT Industry) is extolled as a good foundation and currently the best decision-making aid for manufacturers seeking to determine if their products should be considered as medical devices. Reading through the document, one is amazed at its simplicity (Example: decision step 3: If the software drives, monitors the performance of or influences the use of a medical device, it is a medical device or an accessory to a medical device; the software is to be treated as a medical device, and must consequently bear a CE mark and be subjected to the associated regulations).

This can be seen as an aid for those who are not even sure where to start. The difficulties in the assignments often result from the fact that the intended use of products is not well described or to adequate precision. This is also comparatively difficult for software products. A patient stretcher manufacturer surely has it easier. This often imprecise intended use of software is one of the reasons that manufacturers of very similar software sometimes come to different evaluations when running through this decision tree.

A salient example: Documentation software for intensive care medicine: If the manufacturer comes from the documentation area, it can be that it gathers that its product is not a medical device. A manufacturer from the monitoring area, who already has medical devices in its range, can decide that its product is indeed a medical device, although the two programs offer similar functionalities. Different intended purposes lead to such different assessments even if the functionalities are very similar.

Medical device or not: ultimately what is important is that the software works. The blog of Professor Dr. Christian Johner from the Institut für IT im Gesundheitswesen (www.ehealthkarriere.de) presents some disconcerting information. In his entry for 29 March 2011, entitled “Are you trying to kill us”, he counted how many reports of software errors were received at Germany’s Federal Institute for Drugs and Medical Devices (BfArM) between March 3 and March 25, 2011: there were between one and three reports a day.

His comment on this: “I would not be surprised if the risks caused by incorrect medical devices soon exceed the risks due to hospital infections.” He sees quality assurance that is just as excessive as it is useless as the cause, and explains, “Standards like IEC 62304 really demand only an absolute minimum, but it appears that even this minimum level is not being attained.”

Software errors are difficult to rule out, because there are more alternatives for input and output possibilities than with mechanical or electromechanical medical devices. A radiation device that applies a dose that is too low in a certain protocol is beset with a software error that is extremely difficult to detect. In answer to the question of how much imagination a manufacturer has to summon up in order to avoid such errors or foreseeable improper use of medical devices, Christoph Isele explains, “Manufacturers will not be able to offer one-hundred percent reliability, even if they make every attempt to balance the intended purpose and risk analysis with the everyday work of those using their medical devices.”

His personal opinion is that clinic employees who actively think about what they are doing are at least as important as a manufacturer’s risk analysis. “Because the products are integrated into complex and heterogeneous environments, there is a possibility of errors that the manufacturer has not foreseen – and conversely, the integration can result in additional uses or greater efficiency that is urgently needed. Keeping the patients safe from injuries requires an active dialogue between users and manufacturers.”

Ramona Riesterer

German Summary

Die Softwarehersteller der Branche hatten in diesem Frühjahr eigentlich auf ein klärendes Wort der Medical Devices Expert Group (MDEG) der Europäischen Kommission gewartet. Das Gremium hatte sich zur Einordnung medizinischer Software in die verschiedenen Risikoklassen äußern wollen. Spätestens seit der Novellierung des Medizinproduktegesetzes (MPG) im März 2010 wird aus der Praxis moniert, dass Klassifizierungskriterien als funktionale Abgrenzung mit nachvollziehbaren Beispielen fehlen. Doch das erhoffte Dokument kam vorerst nicht zustande, weil sich die Zuständigen nicht auf eine gemeinsame Stoßrichtung einigen konnten. Der deutschsprachige Beitrag ist nachzulesen auf www. meditec-international.com/medi0311soft