Viele Änderungen der Medizinprodukteverordnung (MDR) betreffen alle Hersteller von Medizinprodukten. Einige dieser Änderungen wenden sich besonders an Hersteller, deren Produkte Software enthalten oder Standalone-Software sind. Lesen Sie, was diese Hersteller beachten sollten.
Dieser Artikel beschreibt die Anforderungen der MDR an Medizinprodukte, die Software enthalten oder Software sind. In einem weiteren Artikel finden Sie einen Vergleich der Anforderungen von MDR und IVDR an Software.
1. MDR: Geänderte Definitionen und Klassifizierung im Vergleich zur MDD
a) Software, Medizinprodukt, Zubehör
Software, die der Vorhersage oder Prognose von Krankheiten dient, zählt als Medizinprodukt. Das stellt die neue Begriffsdefinition der „Medical Device Regulation“ klar.
Software zählt weiterhin als aktives Medizinprodukt. In Zwischenentwürfen der MDR war das nicht mehr der Fall gewesen.
Software kann (wieder) ein Zubehör sein. Das war eigentlich immer so, war aber in einer unglücklichen Übersetzung aus dem MPG verschwunden.
b) MDR zur Software-Klassifizierung
Die Klassifizierungsregeln haben sich ebenfalls geändert. Regel 11 besagt Folgendes:
Software, die dazu gedacht ist, Informationen zur Verfügung zu stellen, die wiederum genutzt werden (sollen/dürfen), um Entscheidungen mit Bezug zu Diagnosen oder Behandlungen zu treffen, fällt in die Klasse IIa. Ausnahmen:
Die Software könnte direkt oder indirekt verursachen
- den Tod oder irreversible schwere Gesundheitsstörungen: Dann fällt die Software in Klasse III.
- eine ernste Gesundheitsstörung oder eine Operation: Dann fällt die Software in Klasse IIb.
Software, die dazu gedacht ist, physiologische Prozesse zu überwachen, fällt in Klasse IIa. Ausnahme: Wenn Veränderungen von Vitalparametern zur unmittelbaren Gefahr für den Patienten werden können, ist die Software in Klasse IIb einzuordnen.
Jede andere Software fällt in Klasse I.
Eine Diskussion der Regel 11 zeigt die Schwierigkeit, welche die Formulierung für Hersteller bedeuten:
Mit dieser Definition fällt nahezu jede Software in die Klassen IIa und höher.
Ein weiterer Artikel beleuchtet die wenigen Fälle von Standalone-Software der Klasse I.
Es gilt weiterhin, dass Software, die ein anderes Medizinprodukt kontrolliert oder beeinflusst, in die gleiche Klasse wie das Medizinprodukt fällt, und dass Standalone-Software unabhängig zu klassifizieren ist.
2. Grundlegende Anforderungen der MDR an Software
a) Kompatibilität und Interoperabilität
Die Medizinprodukteverordnung MDR fordert, dass durch mangelnde Kompatibilität von Medizinprodukten keine Risiken entstehen dürfen. Sie nennt in diesem Kontext explizit die Software.
Die gleiche Forderung stellt die MDR bezüglich der Interoperabilität:
Devices that are intended to be operated together with other devices or products shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe.
Sie finden hier die MDR-Definition und Erläuterung des Begriffs Interoperabilität.
Wörtlich schreibt die MDR im Anhang I mit den grundlegenden Anforderungen:
Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts;
b) IT-Sicherheit, Mobile Plattformen
Ganz neu hat die MDR im Anhang I ein Kapitel eingefügt: Electronic programmable systems – Devices that incorporate electronic programmable systems and software that are devices in themselves.
Die bisherige, grundlegende Anforderung hat die Verordnung um den fett markierten Text ergänzt:
Bei Produkten, die Software enthalten oder bei denen es sich um medizinische Software an sich handelt, muss die Software entsprechend dem Stand der Technik validiert werden, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements, einschließlich Informationssicherheit, der Validierung und Verifizierung zu berücksichtigen sind.
Ganz neu ist auch die Forderung bezüglich Mobilgeräten:
Devices that are intended to be operated together with other devices or products shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe.
Eine weitere Forderung betrifft ebenfalls die IT-Sicherheit: Die Hersteller müssen die Mindestanforderungen an die Hardware, IT-Netzwerke und Maßnahmen bezüglich IT-Sicherheit bestimmen, einschließlich Schutz gegen nicht autorisierten Zugriff.
Die Videotrainings in der Johner Academy beschreiben Schritt für Schritt, wie Hersteller die IT-Sicherheit ihrer Produkte erreichen und die regulatorischen Anforderungen an die IT-Sicherheit erfüllen können.
3. Anforderungen an die Technischen Dokumentation von Software
Falls anwendbar, müssen die Hersteller die Software als Teil der Technischen Dokumentation beschreiben. Weiter müssen sie detaillierte Informationen beilegen, u. a. die Software-Verifizierung und Software-Validierung.
Die MDR versteht den Begriff Software Validation nicht nur als Validierung im Sinne einer klassischen Prüfung, ob die Zweckbestimmung erreicht werden kann, sondern (wie die FDA) als alle Maßnahmen der Software-Qualitätssicherung. Insbesondere benennt die MDR als Inhalte einer Technischen Dokumentation:
- Software Design
- Software-Entwicklungsprozess
- Software-Verifizierung
- Software-Validierung (jetzt im engeren Sinn)
- Weitere Tests (in der Firma und in einer simulierten oder echten Gebrauchsumgebung)
- Informationen zur Laufzeitumgebung wie unterschiedliche Hardware-Konfigurationen, Betriebssysteme usw.
4. Weitere Anforderungen
a) Unique Device Identification
Die (Standalone-)Software unterliegt wie alle Medizinprodukte der Anforderung nach eindeutiger Identifikation durch eine Unique Device Identification (UDI).
Lesen Sie in diesem Artikel mehr zur UDI und Umsetzung bei Software. Die MDR stellt für Medical-Device-Software konkrete Anforderungen.
b) Anforderungen an die Benannten Stellen
Die MDR stellt konkrete Forderungen an die Benannten Stellen, insbesondere an deren Kompetenz. So schreibt die Medizinprodukteverordnung im Anhang:
The qualification criteria shall refer to the scope of the notified body’s designation […] providing sufficient level of detail for the required qualification […]. Specific qualification criteria shall be defined at least for the assessment of the pre-clinical evaluation, clinical evaluation, […], functional safety, software, packaging, […].
Diese Forderung betrifft Sie zumindest indirekt: Sie werden verstärkt auf kompetente Auditoren stoßen.
5. Fazit und Zusammenfassung
Im Vergleich zu den EU-Richtlinien stellen die EU-Verordnungen MDR und IVDR mehr spezifische Anforderungen an Software, unabhängig davon, ob die Software das Medizinprodukt oder ein Teil eines Medizinprodukts ist.
Allerdings sind diese Anforderungen noch unkonkret, sodass Auditoren und Reviewer harmonisierte Normen heranziehen, insbesondere die IEC 62304 für die Konformitätsprüfung.
Für bestimmte Software-Systeme existieren weitere Anforderungen, etwa IT-Security-Anforderungen an vernetzte Medizinprodukte oder Anforderungen an Medizinprodukte, welche Verfahren der künstlichen Intelligenz wie maschinelles Lernen verwenden.
Das Johner Institut hilft allen Herstellern, weltweit die regulatorischen Anforderungen an Medizinprodukte und IVD zu erfüllen, welche Software sind oder enthalten:
- Software-Prozesse gesetzeskonform und effizient gestalten
- Nichtkonformitäten in Prozessen, Produkten und Dokumenten finden und beseitigen
- Entwicklungsteams schulen und weiterbilden
Änderungshistorie
- 2024-11-12: Artikel aktualisiert und neu strukturiert. Verlinkungen ergänzt.
- 2017-11-17: Erste Version des Artikels publiziert
Sehr geehrter Herr Johner,
aktuell diskutiere ich mit einem PACS-Hersteller über die potentielle Klasse nach MDR. In den aktuellen Diskussionen wird für jegliche Standalone-SW die Regel 11 herangezogen. Beim Blick auf die Regel 11 ist es nun müßig darüber zu diskutieren, ob Patienten durch
Fehlfunktionen eines PACS zu Tode kommen können oder nicht.
Allerdings wird in den emotionalen Diskussionen um die Regel 11 die Durchführungsvorschrift 3.3 übersehen, welche gegenüber der MDD (Anwendungsregel 2.3) folgendermaßen erweitert wurde:
„Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, wird derselben Klasse zugerechnet wie das Produkt.
Ist die Software von anderen Produkten unabhängig, so wird sie für sich allein klassifiziert.“
Der zweite Satz ist neu und scheint auf die Regel 11 zu verweisen. Meiner Meinung muss bei Standalone-SW unterschieden werden in
1) SW unabhängig eines anderen Medizinproduktes, z.B. App zur Empfängnissregelung oder App zur AMTS
und
2) SW abhängig von anderen Medizinprodukten, z.B. PACS oder Bestrahlungsplanung (ohne Modalität keine Befundung mit PACS, ohne Bestrahlungsanlage keine Applikation eines Bestrahlungsplanes)
Nach meiner Interpretation der Durchführungsvorschrift 3.3, Satz 2, bezieht sich Regel 11 nur auf SW der Kategorie 1, also z.B. nicht auf PACS und Bestrahlungsplanung.
Demnach zieht bei der Kategorie 2 weiterhin Durchführungsvorschrift 3.3, d.h. PACS wird klassifiziert in der höchsten Klasse der unterstützen Modalitäten, also IIb. Ebenso bliebe ein Bestrahlungsplanungssystem Klasse IIb.
Eine Stellungnahme Ihrerseits zu obigen Ausführungen wäre interessant.
Mit freundlichen Grüßen,
Mark Hastenteufel
Sehr geehrter Herr Hastenteufel,
danke für Ihre wichtigen Gedanken! Ich stimme Ihnen völlig zu, dass der zweite Satz auf die Regel 11 zielt.
Bei der Abhängigkeit muss man zwischen mit und ohne Kontrolle und Steuerung unterscheiden. Eine Software, die beispielsweise die Daten von einem anderen MP holt und (nur) visualisiert, ist abhängig von diesem MP. Sie steuert es aber nicht.
Bei einem PACS hängt es von der Zweckbestimmung ab.
Meiner Vermutung nach, wird man Regeln finden müssen, um die Regel 11 wieder abzuschwächen. Ob dies in Form einer MEDDEV geschehen wird, weiß ich nicht. Dass man ein PACS aber auch künftig in IIb klassifiziert, halte ich für sehr wahrscheinlich.
Viele Grüße, Christian Johner
Sehr geehrter Herr Johner
Folgende Situation:
Ein auf dem Markt bestehendes Produkt fällt nach MDD in die Klasse 1 (Selbstdeklaration). Nach den neuen Zertifizierungsregeln der MDR (Software) fällt es in die Klasse 2a (Zertifizierung durch Notified Body).
Wie sehen die Übergangsfristen für das Produkt aus?
Wie lange darf das unveränderte Produkt auf dem Markt bleiben?
Muss bei einem Softwareupdate nach Mai 2020 das Produkt in jedem Falle neu nach MDR zertifiziert werden?
Besten Dank!
Sehr geehrter Herr Trepp,
das ist eine spannende Frage. Generell ist eine Bereitstellung der unveränderten Software weiter erlaubt. Wie groß eine Änderung sein darf ist nicht genau geregelt. Ich würde mich daran orientieren, was die MDR als eine Änderung bezeichnet, die so klein ist, dass sie nur eine Änderung der UDI-PI, aber nicht der UDI-DI bedingt.
Eine weitere Diskussion finden Sie hier.
Bei Rückfragen einfach melden.
Viele Grüße, Christian Johner
Sehr geehrter Herr Johner,
aktuell ist eine Software in der Entwicklung die dafür da ist, bestimmte pathologische Muster in Bildern die über Endoskopie generiert werden zu erkennen.
Die Software kann Bilder mit Befund markieren, was das medizinische Personal auch sehen kann. Jedoch hat dieses immer noch vollen Zugriff auf alle Bilder die generiert wurden.
Würden Sie diese Software überhaupt als Medizinprodukt definieren? (Die Software sammelt keine Daten und gibt auch keine alternativen zur selbstständigen Entscheidung vor, funktioniert mehr wie ein elektronisches Buch/Lexikon).
Wenn ja, würde diese dann in die Klasse IIa nach Regel 11 fallen?
Mit freundlichen Grüßen,
Ömer Tekin
Sehr geehrter Herr Tekin,
wenn der Zweck der SW darin besteht, dass sie pathologische Muster in Bildern erkennen soll, dann ist diese Software ein Medizinprodukt gemäß Definition. Gemäß Regel 11 fällt sie mindestens in die Klasse IIa. Ohne genaueres Verständnis des Kontexts ist das nicht zu entscheiden.
Viele Grüße, Christian Johner
Sehr geehrter Herr Johner
Eine Rückfrage:
Ist es also richtig, dass das unter obigem Kommentar Nr. 3. genannte Produkt (ohne wesentliche Änderung) bis Mai 2025 als Klasse I unter MDD auf dem Markt verkauft werden darf obwohl es unter MDR ein Klasse IIa Produkt ist? Also Art. 120 (4) der MDR zur Geltung kommt?
Art. 120 (4) Produkte, die vor dem 26. Mai 2020 gemäß den Richtlinien 90/385/EWG und 93/42/EWG rechtmäßig in Verkehr gebracht wurden, und Produkte, die ab dem 26. Mai 2020 aufgrund einer Bescheinigung gemäß Absatz 2 des vorliegenden Artikels in Verkehr gebracht wurden können bis zum 27. Mai 2025 weiter auf dem Markt bereitgestellt oder in Betrieb genommen werden.
Wir haben auch schon gegenteilige Aussagen hierzu gehört. Z.B. müssen gemäss NAKI FAQ Nr. 13 Klasse I mit Geltungsbeginn (Mai 2020) der MDR entsprechen, mit Ausnahme Klasse I mit Messfunktion oder in sterilem Zustand, welche noch eine gültige MDD Bescheinigung verfügen.
Sehr geehrter Herr Trepp,
jetzt verstehe ich Ihre ursprüngliche Frage. Sie haben Recht: Für ein Produkt, für das ab der MDR eine Bescheinigung einer benannten Stelle benötigt, kann sich der Hersteller nicht auf die Übergangsfrist berufen. Sie zitieren völlig zutreffend die entsprechende Stelle im NAKI-FAQ.
Danke für die wichtige Nachfrage, die mir diese Klarstellung ermöglicht!
Viele Grüße, Christian Johner
Lieber Herr Johner
Entschuldigen Sie die erneute Nachfrage, um Missverständnisse zu vermeiden.
Das bedeutet konkret, dass das genannte Softwareprodukt, welches nach MDD Klasse I (Selbstdeklaration) und nach MDR Klasse IIa ist:
– auf Mai 2020 eine MDR Zertifizierung durch einen Notified Body benötigt?
– ab Mai 2020 nicht mehr auf dem Markt verkauft werden darf?
Herzlichen Dank für die Klarstellung.
Lieber Herr Johner,
wie würden Sie das Produkt mit folgender Zweckbestimmung klassifizieren: „Es wird eine mobile Applikation mit modalerem Aufbau für Morbus Parkinson Patienten entwickelt und implementiert. Die Applikation dient dabei dem klinischen und telemedizinischen Einsatz zur interdisziplinären Datenerfassung und -kumulation, wobei kognitive und motorische Parameter erfasst werden. Die Applikation soll zur medizinischen Überwachung von Parkinson Patienten eingesetzt werden. Im weiteren Verlauf wird die Applikation dem Anwender und dem Klinikpersonal Empfehlungen geben, ob eine Vorstellung beim behandelnden Arzt notwendig ist.“
Ich freue mich auf Ihre baldige Rückmeldung
Vielen Dank im Voraus
Mit freundlichen Grüßen
Ali Elhosh
Sehr geehrter Herr Elhosh,
danke für die spannende Frage! Sie bitten um eine baldige Rückmeldung. Okay.
Sie schildern sowohl Funktionalitäten also auch Zweckbestimmungen. Es sind v.a. die Zweckbestimmungen, aus denen auf die Qualifikation als MP oder eben Nicht-MP geschlossen werden kann. Bei den Funktionalitäten müsste man noch den Zweck klären.
Die Zweckbestimmung „Überwachung von Parkinson-Patienten“ würde ich als eine Überwachung einer Krankheit verstehen. Damit wäre das Produkt per definitionem ein Medizinprodukt.
Die Empfehlung für oder wider einer Vorstellung bei einem Arzt würde ich tendenziell auch so einschätzen, dass Sie der Behandlung von Patienten dient und damit ebenfalls zu einer Qualifikation als Medizinprodukt führt. Das ist aber eher ein Graubereich.
Beste Grüße, Christian Johner
Sehr geehrter Herr. Prof. Dr. Johner,
erstmal vielen Dank für Ihre schnelle Rückmeldung und die informative Erklärung.
Würden Sie zustimmen, wenn an dieses App laut der Zweckbestimmung, die Risikoklasse IIa zugewiesen wird?
Vielen Dank im Voraus
Mit freundlichen Grüßen
Ali Elhosh
Das hängt davon ab, welches Regelwerk Sie anwenden: Unter der MDD wahrscheinlich Klasse I, unter der MDR in Verbindung mit MDCG 2019-11 wahrscheinlich Klasse IIa.
Sehr geehrter Herr Prof. Johner
Ich erlebe regelmässig Diskussionen über Medizinprodukte, welche nicht mehr supportete Betriebssysteme aufweisen (bspw. Ultraschallgerät)
Wie sieht hier die rechtliche Lage aus? Ist der Produkthersteller nicht in der Pflicht, sein Medizinprodukt und damit auch das integrierte Betriebssystem, auf einem aktuellen Stand der Technik zu halten? Damit einhergehend muss er doch auch seine Medizinprodukte, welche ein nicht mehr supportetes Betriebssystem aufweisen, aus eigener Initiative heraus Upgraden (und auch allfällige Kosten tragen) ? Oder wie sieht hier die regulatorische Situation aus?
Besten Dank für Ihre Rückmeldung.
Sehr geehrter M.B.,
der Hersteller ist verpflichtet, Risiken auch nach der Inverkehrbringung zu minimieren.
Wenn durch ein veraltetes Betriebssystem die Risiken höher sind als sie das mit einem aktualisierten Betriebssystem wären, wäre das ein Verstoß gegen die gesetzlichen Pflichten.
Wer die Kosten für dieses Update trägt, legt der Gesetzgeber nicht fest. Der Hersteller hat auch die Möglichkeit, das Produkt vom Markt zu nehmen.
Beste Grüße, Christian Johner