MDCG 2023-4 zu Kombinationen von MDSW und Hardware

Die MDCG hat im Oktober 2023 eine Leitlinie MDCG 2023-4 veröffentlicht mit dem Titel „Medical Device Software (MDSW) – Hardware combinations – Guidance on MDSW intended to work in combination with hardware or hardware components”.

Kritikpunkt 1: Unklarer „Scope“ der MDCG 2023-4

Die Überschrift weckt den Eindruck, als ginge es um (alle) Typen von Kombinationen aus Hardware und Medical Device Software (MDSW). Das beträfe

• Hardware, die Teil des gleichen Medizinprodukts wie die Software ist,
• ebenso wie Hardware, die Teil eines anderen Medizinprodukts ist, und
• handelsübliche Hardware, die kein Medizinprodukt ist, wie PCs, Tablet und Smartphones.

Der erste Satz der Einleitung bestärkt diese Vermutung. Doch der zweite Satz spricht über „smart phones and wearable digital products“.

Dann schreiben die Autoren im Kapitel „Scope“, dass es um Hardware ginge, welche die Daten sammelt („incorporating the data collection element“). Gleichzeitig schließen sie Desktop-PCs und Cloud-Computing-Plattformen aus. Das ist überraschend, denn damit wären beispielsweise die Ultraschallgeräte, welche oft auf Desktop-PCs aufsetzen und Sensoren nutzen, vom Scope ausgenommen. Weshalb?

Wahrscheinlich haben die Autoren tragbare Hardware im Fokus, die eine Sensorik enthält, welche Daten für die MDSW liefert.

Die klinische Bewertung schließt die Leitlinie aus ihrem Scope aus. Dennoch adressiert sie diesen Aspekt und fordert „demonstrate clinical evidence for all intended configurations“.

Kritikpunkt 2: Unklare Zielsetzung und -erreichung

Was die eigentliche Zielsetzung der Leitlinie ist, bleibt unklar. Sie behauptet, dass sie Hilfestellung dabei geben wolle, welche „specific regulatory considerations apply“. Doch wirklich (neue) Antworten liefert sie nicht. Dass ein Hersteller die Konformität mit der MDR nachweisen muss, dürfte bekannt sein. Die Leitlinie verweist meist nicht einmal auf die entsprechenden Abschnitte der MDR. Hinweise auf Normen, z. B. zur Interoperabilität, fehlen ganz.

Die Leitlinie nennt keine Liste an spezifischen Fragen, welche sie beantworten will. Daher ist es nicht einfach zu beurteilen, welche Ziele sie erreichen will und ob sie diese erreicht hat.

Kritikpunkt 3: Diskussionswürdige Aussagen

Beispiel 1

Die von der Leitlinie diskutierte „Option 2“ beinhaltet den Fall, dass eine Hardware-Komponente als Teil eines Medizinprodukts in den Verkehr gebracht wird („as an integral part of a medical device“ – s. Punkt c) auf Seite 6).

Mit Bezug zu dieser Option 2 heißt es auf Seite 7:

„the MDSW manufacturer may rely on the compliance of that hardware or hardware component with the MDR, in particular compliance with the GSPRs, when used in line with its intended purpose, under the intended normal conditions of use.“

Das stimmt in dieser Allgemeingültigkeit nicht. Zum einen hat eine Hardware-Komponente gemäß Option 2 Punkt c) überhaupt keine Zweckbestimmung im Sinne der MDR.

Zum anderen kann sich der Hersteller gerade nicht darauf verlassen, dass die Komponente auch in einem anderen Kontext konform ist. Beispielsweise lässt sich die elektromagnetische Verträglichkeit einer Komponente ohne die umgebende Hardware eines Produkts gar nicht beurteilen.

Beispiel 2

Die „Option 3“ beschreibt den Fall, dass der MDSW-Hersteller eine Hardware verwendet, die kein Medizinprodukt oder Zubehör ist. Laut dieser Leitlinie wird der Hersteller verantwortlich für die „safety, performance and reproducibility of the hardware or hardware component in its combined use with the MDSW in all intended configurations.“

Wird damit der Hersteller einer App verantwortlich für die elektrische Sicherheit des Smartphones? Der Text erweckt den Eindruck.

An anderer Stelle verweisen die Autoren auf den vierten Abschnitt des Artikels 22 der MDR. Dessen Anforderungen sind aber nicht identisch mit den Anforderungen, welche die Leitlinie bei Option 3 nennt.

Beispiel 3

Die Beispiele unterscheiden, ob die Hersteller der Hardware und die Hersteller der MDSW-App dieselbe Entität sind. Das ist aber aus regulatorischer Sicht weitgehend unerheblich. Die MDR unterscheidet dies auch nicht. Entscheidend sind vielmehr die Fragen, ob

• die Hardware und die Software als ein oder als zwei Produkte in den Markt gebracht werden und
• die Hardware bzw. die Software als Medizinprodukt, als Zubehör oder als Nicht-Medizinprodukt in den Markt gebracht werden.

Interessanterweise fassen die regulatorischen Bewertungen in Kapitel 5) die beiden Fälle (gleiche bzw. verschiedene Entität) auch wieder zusammen. Aber weshalb wurden sie dann so explizit und so ausführlich differenziert?

Beispiel 4

Bei der Option 3 verpflichtet die Leitlinie die Hersteller zu einer Post-Market Surveillance, welche die Nicht-Medizinprodukte-Hardware(komponenten) einschließt. Diese Forderung ist valide. Sie ist aber genauso zutreffend für Hardware(komponenten), die Teile des Medizinprodukts sind. Denn in sehr vielen Fällen kaufen die Medizinproduktehersteller die Hardware(komponenten) zu. Damit könnte dieser Abschnitt zu falschen Schlussfolgerungen führen.

Kritikpunkt 4: Unklarer Nutzen

Eine Leitlinie sollte die Fragen beantworten, die in Audits und Tech-File-Reviews zu Diskussionen führen, wie beispielsweise:

• Wie leitet man ab, wie viele Konfigurationen der „Plattformen“ getestet werden müssen? Bezüglich welcher Aspekte darf man die Hardware als Blackbox betrachten? Es ist unmöglich, alle Typen an Smartphones in allen Hardware-Konfigurationen mit allen Versionen von Betriebssystemen und allen möglichen Kombinationen von parallel installierter Software zu testen.
• Was sind typische Gefährdungen von mobiler Hardware mit Sensorik, die im Risikomanagement betrachtet werden sollten?
• Welche Anforderungen an das Betriebssystems und welche diesbezüglichen Prüfungen werden erwartet? Bei den Mobile Devices, die im Fokus der Leitlinie stehen, greifen Hersteller meist gerade nicht direkt auf die Sensoren zu, sondern nutzen entsprechende APIs des Betriebssystems.
• In welchen Fällen muss ein MDSW-Hersteller die Biokompatibilität, die elektrische, mechanische und thermische Sicherheit von handelsüblichen Mobilgeräten verifizieren? Diskussionen über die Anwendbarkeit der IEC 60601-Familie bei Mobile Apps sind keine Seltenheit.
• Wie kann ein gesetzeskonformes Monitoring der Hardware (z. B. Smartphones) aufgesetzt werden? Welche Informationen sind besonders relevant? In welcher Frequenz sollen diese erhoben werden?
• Welchen Einfluss hat eine bestehende CE-Kennzeichnung der Hardware (z. B. gemäß Funkanlagen-Richtlinie RED) auf die Verifizierungsmaßnahmen dieser Hardware?
• Wann reichen Performance-Daten bei der klinischen Bewertung nicht(!) aus? Da die Leitlinie die „clinical evidence“ für alle(!) Kombinationen explizit fordert, wäre eine Antwort hilfreich.
• Welchen Unterschied macht es, wenn die Hersteller der Hardware und der Software nicht die gleiche Entität sind?

Kritikpunkt 5: Unzureichende Abstraktion und innere Logik

Leitlinien sind keine wissenschaftlichen Arbeiten. Aber einige Grundkonzepte sollten sie übernehmen:

• Klare Fragestellung
• Beschreibung der Methodik
• Präzise und korrekte Ergebnisse
• Nachvollziehbare Erläuterung, wie die Autoren zu diesen Ergebnissen kommen

Die Leitlinie MDCG 2023-4 erfüllt diese Anforderungen nicht in einem ausreichenden Maß. Sie macht es den Lesenden sehr schwer zu folgen. Beispielsweise führt sie sehr breit vier Beispiele aus. Als Lesende versucht man, die Unterschiede und Gemeinsamkeiten dieser Beispiele herauszufinden.

	A. External hardware component (e.g., sensor embedded in a dermal patch) providing input data to a MDSW app		B. Hardware component incorporated within a smartphone or wearable connected to a MDSW app on smartphone or wearable
#	1) Manufacturer of hardware component and MDSW app are the same entity	2) Manufacturer of hardware component and MDSW app are different entities	1) Manufacturer of hardware component incorporated within a wearable and MDSW app are the same entity	2) Manufacturer of wearable and MDSW app are different entities
1	Example: Manufacturer X places on the market a dermal patch that incorporates a sensor intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.	Example: Manufacturer X places on the market a dermal patch that incorporates a sensor intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.	Example: Manufacturer Z places on the market a wearable (e.g., watch) that incorporates a sensor that is intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.	Example: Manufacturer Z places on the market a wearable (e.g. watch) that incorporates a sensor intended or capable of collecting and relaying data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.
2	Upon purchase of the dermal patch, users download the MDSW app also placed on the market by Manufacturer X on a smartphone and connect the two (patch and smartphone app).	Manufacturer Y places on the market a MDSW app claimed to be compatible with the dermal patch of manufacturer X (or claimed to use input data provided by patches or sensors similar to the patch of Manufacturer X).	Upon purchase of the wearable, users are prompted to download (or activate) MDSW app also placed on the market by Manufacturer Z on their smartphone and/or wearable.	Users can download a variety of MDSW apps placed on the market by different MDSW app manufacturers. Manufacturer D claims that their MDSW app achieves its intended medical purpose through receiving data from the sensor integrated in the wearable placed on the market by Manufacturer Z.
3	Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user.	Collected data by the sensor are transmitted to the smartphone MDSW app for further analysis and calculations.	Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user.	Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user.
4	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.
5	The app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.	The MDSW app displays the calculated and monitored physiological parameters and conducted analysis to the user and/or transmits this information directly to the healthcare professional.	The app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.	The MDSW app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.

Es wäre hilfreich gewesen, ein(!) Beispiel zu nennen und dann die Unterschiede zu diskutieren, wenn die Hardware als Medizinprodukte bzw. Zubehör und als Nicht-Medizinprodukt in den Verkehr gebracht wird. Das hätte nicht nur zu weniger Text, sondern auch zu mehr Verständlichkeit beigetragen. Die Lesenden von MDCG-Leitlinien sind zu solch einer Abstraktion fähig.

Die Unterscheidung, ob die Hersteller der HW und der MDSW die gleichen Entitäten sind, nimmt viel Platz ein, verwirrt und wird in der Diskussion der regulatorischen Konsequenzen nicht aufgegriffen.

Die Unterscheidung, ob die HW und MDSW als ein Produkt oder zwei Produkte in den Verkehr gebracht werden, muss nicht diskutiert werden. Denn der erste Fall entspricht einem „normalen Medizinprodukt“ und ist durch die MDR abgedeckt.

Kritikpunkt 6: Formales

Ein Dokument, das als Datum nur Monat und Jahr angibt, würden Benannte Stellen den Herstellern wahrscheinlich nicht durchgehen lassen. Aber wenn diese Information stimmt und bei Änderungen auch geändert wird, sollten wir das Dokument eindeutig identifizieren können.

Das Dokument basiert wahrscheinlich auf der gleichen Formatvorlage wie andere MDCG-Dokumente. Das schafft zwar eine Konsistenz, repliziert aber das unschöne Layout mit unglücklichen Einrückungen bei den Überschriften bzw. in der Inhaltsangabe und führt zu einer Formatierung, welche die Hierarchie der Überschriften nur schwer erkennen lässt.

Positiv anzumerken ist, dass das Dokument scheinbar ein Lektorat durchlaufen hat. Grammatik und Rechtschreibung stimmen bis auf Kleinigkeiten.

Fazit

Die MDCG hat weder sich noch den Herstellern und Benannten Stellen einen Gefallen mit der Leitlinie MDCG 2023-4 getan.

Die Leitlinie schafft kaum zusätzliche Klarheit, verwirrt sogar und dient nicht als Ausweis einer präzisen Argumentationsführung. „Stand der Technik“ ist diese Argumentation nicht.

Benannte Stellen sind gut beraten, eine Konformität mit dieser Leitlinie in Audits und bei Prüfungen der technischen Dokumentation nicht(!) einzufordern. Denn damit würden sie sich die mangelnde gedankliche Schärfe zu eigen machen.