Was ist Software als Medizinprodukt? SaMD-Compliance-Guide

Software als Medizinprodukt (SaMD) ist jedes Programm, das eine medizinische Aufgabe eigenständig erfüllt, ohne Teil eines physischen Geräts zu sein. Eine App, die das Foto eines Muttermals auswertet und auf ein mögliches Melanom hinweist, passt in diese Beschreibung. Der Code, der einen MRT-Scanner steuert, fällt nicht darunter, weil er Teil der Hardware ist.

Diese Unterscheidung entscheidet weit mehr über Ihr Produkt, als Sie vielleicht erwarten. Sie bestimmt, welche Aufzeichnungen Sie führen, welche Tests Sie nachweisen müssen und in manchen Märkten sogar, ob Sie überhaupt verkaufen dürfen. Viele Teams stellen sich diese Frage nicht selbst. Sie hören sie zuerst von einem Investor, einem Klinikeinkäufer oder einem Anwalt.

Eine offene Anmerkung, bevor es weitergeht: Dieser Artikel ist keine rechtliche oder regulatorische Beratung. Redwerk übernimmt Softwareentwicklung für Healthcare IT, während die Klassifizierung Ihres Produkts und die Einreichung bei der FDA in die Hände einer qualifizierten Beratung gehören. Wir bauen die Lösung und stehen bei jeder Prüfung und jedem Audit an Ihrer Seite, in enger Zusammenarbeit mit Ihrem Team, damit die Compliance vollständig ist. Wir verlinken durchgehend die offiziellen Dokumente, damit Sie die Quelle selbst lesen können und sich nicht auf unsere Zusammenfassung verlassen müssen.

Was folgt, ist die technische Hälfte des Bildes. Sie erfahren, was als SaMD gilt, wie die Risikokategorien aufgebaut sind und was ein konformer Build von den Menschen verlangt, die den Code schreiben.

Was als Software als Medizinprodukt gilt

Die FDA und das International Medical Device Regulators Forum, meist zu IMDRF abgekürzt, definieren den Begriff als “Software, die für einen oder mehrere medizinische Zwecke bestimmt ist und diese Zwecke erfüllt, ohne Teil eines Hardware-Medizinprodukts zu sein.”

Daraus ergeben sich zwei Fragen:

• Erfüllt das Produkt einen medizinischen Zweck, hilft es also beim Diagnostizieren, Behandeln, Vorbeugen oder Überwachen einer Krankheit oder eines Zustands?
• Erfüllt es diese Aufgabe eigenständig und nicht als Komponente in einem Gerät?

Zweimal Ja bedeutet: Sie fallen in den Anwendungsbereich.

Drei bekannte Gruppen fallen unter die Definition:

• Bildanalyse-Tools, die eine Aufnahme messen oder interpretieren und den Befund an die Radiologie zurückgeben
• Klinische Entscheidungsunterstützung, die eine Diagnose, eine Dosierung oder einen Behandlungsweg vorschlägt
• Bestimmte Health-Monitoring-Apps, insbesondere solche, die Sensordaten auslesen und Nutzende vor einem konkreten Krankheitsbild warnen

Die dritte Gruppe überrascht die meisten. Ein Herzfrequenzwert allein ist nur eine Zahl. Sobald ein Produkt jedoch das Muster interpretiert und jemandem mitteilt, dass eine Rhythmusstörung vorliegen könnte, hat es medizinisches Terrain betreten.

Zwei Arten von Gesundheitssoftware bleiben außerhalb der Definition, und beide sind kommerziell relevant. Die erste ist alles, was in die Kernfunktion eines Geräts eingebaut ist. Firmware in einer Infusionspumpe fällt als Teil dieser Hardware unter die Regeln, nicht als eigenständiges Produkt. Die zweite ist administrative Technik: Abrechnungssysteme, Terminplanung, Personaleinsatzplanung und Aktenverwaltung berühren alle Patientendaten, ohne eine klinische Aussage zu treffen. Diese Tools tragen dennoch Datenschutzpflichten. Sie sind außerdem ein häufiges Ziel für robotergesteuerte Prozessautomatisierung im Gesundheitswesen, die wir separat behandeln.

Wann eine Wellness-App zum Medizinprodukt wird

Am deutlichsten wird die Grenze an einem Produkt, das direkt daneben liegt. Redwerk hat Pridefit neu aufgebaut und betreut die App weiterhin: eine Fitness-App im Abomodell für die LGBTQIA+ Community, mit Coaching-Plänen, persönlichen Challenges und Leistungstracking. Sie verarbeitet täglich Gesundheitsdaten und verändert bewusst das Verhalten ihrer Nutzenden.

Nichts davon macht sie zu einem regulierten Produkt. Pridefit erhebt keinen Anspruch, etwas zu diagnostizieren oder zu behandeln, und bleibt damit auf der Seite des allgemeinen Wellness. Geben Sie derselben App eine neue Funktion, die die Trainingsdaten auswertet und vor einem möglichen Herzproblem warnt, und die Lage ändert sich sofort. Zwischen einem Wellness-Tool und einem regulierten Produkt kann ein einziger Satz in Ihrem Marketingtext liegen.

Wie die SaMD-Klassifizierung funktioniert

Die SaMD-Klassifizierung beginnt nicht bei Ihrem Technologie-Stack oder Ihrer Unternehmensgröße. Sie beginnt mit zwei Fragen nach den Folgen, und die Antworten ergeben zusammen eine Risikokategorie.

Die erste Frage: Wie viel Gewicht hat das Ergebnis Ihres Produkts in einer klinischen Entscheidung?

• Informiert das klinische Management, die Klinik nutzt das Ergebnis also als einen Input unter mehreren
• Steuert das klinische Management, das Ergebnis prägt also den nächsten Schritt in der Versorgung
• Behandelt oder diagnostiziert, das Produkt selbst liefert also den Befund oder die Therapie

Die zweite Frage: Wie groß ist die Gefahr, in der die Patientin oder der Patient bereits ist?

• Nicht schwerwiegend, eine falsche Antwort führt hier kaum zu dauerhaftem Schaden
• Schwerwiegend, eine Verzögerung oder ein Fehler kann hier zu echten Verletzungen führen
• Kritisch, ein falsches Ergebnis kann hier zum Tod oder zu irreversiblen Schäden beitragen

Beide Antworten zusammen führen in eine von vier IMDRF-Kategorien, I am unteren und IV am oberen Ende. Die Skala beschreibt, wie viel Risiko Ihr Produkt trägt, und nicht mehr.

Beachten Sie, wie dieselbe Fähigkeit je nach Kontext im Raster wandert. Ein Tool, das das klinische Management steuert, landet in einer harmlosen Situation bei I und in einem lebensbedrohlichen Notfall bei III. Ihre Feature-Liste allein wird Ihnen nie sagen, wo Sie stehen.

FDA-Klassen vs. IMDRF-Kategorien: Was jeweils entschieden wird

Zwei getrennte Systeme zur SaMD-Klassifizierung arbeiten mit ähnlichen Zahlen, und jedes beantwortet eine andere Frage. Sie zu verwechseln ist der häufigste Fehler, den Teams hier machen.

Die IMDRF-Kategorien haben Sie oben bereits kennengelernt. Die SaMD-Anforderungen der FDA laufen auf einer eigenen Spur, aufgebaut auf drei Klassen, die abbilden, wie viel Aufsicht ein Produkt braucht:

• Klasse I umfasst die Produkte mit dem geringsten Risiko, und die meisten brauchen überhaupt keine Einreichung vor dem Markteintritt.
• Klasse II liegt in der Mitte und erfordert in der Regel eine 510(k)-Meldung, die belegt, dass Ihr Produkt einem bereits zugelassenen gleichwertig ist.
• Klasse III trägt das höchste Risiko und durchläuft die anspruchsvollste Prüfung, die die Behörde kennt.

Etwas wirklich Neues, zu dem es kein Gegenstück gibt, geht seinen eigenen Weg, weil es keinen Vergleichsmaßstab gibt. Die Klasse Ihres Produkts ergibt sich aus seiner Zweckbestimmung und dem Schaden, den es anrichten könnte, nicht daraus, wie es gebaut wurde.

So vergleichen sich die beiden Systeme auf einen Blick:

Keine der beiden Skalen sollten Sie allein durcharbeiten. Nutzen Sie die Kategorien, um Ihr Risiko zu verstehen, und lassen Sie die US-Klassifizierung dann von einer regulatorischen Fachperson bestätigen. Der Digital Health Policy Navigator der FDA ist ein sinnvoller Einstieg zum Nachlesen vor diesem Gespräch. Die Anforderungen unterscheiden sich außerdem je Markt und ändern sich über die Zeit, prüfen Sie also nach, statt zu vermuten.

Was die Entwicklung konformer SaMD-Software erfordert

Das kommt auf ein Engineering-Team zu, das Software als Medizinprodukt baut, und hier gewinnt oder verliert ein Entwicklungspartner seinen Platz. Das meiste davon ist in jedem ernsthaften Projekt gute Praxis, in reguliertem Umfeld wird es jedoch verpflichtend, und Sie müssen es belegen. Die FDA erwartet, dass die gesamte Arbeit in einem Qualitätsmanagementsystem (QMS) stattfindet: dokumentierte Prozesse plus Nachweise, dass Sie sie jedes Mal eingehalten haben. Ihre Guidance zur klinischen Bewertung beschreibt, wie Sie zeigen, dass das Produkt leistet, was Sie versprechen.

Vier Praktiken tragen in der SaMD-Softwareentwicklung das Gewicht:

• Nachvollziehbarkeit. Jemand sollte eine Zeile in Ihrer Spezifikation auswählen und ihr zur Design-Entscheidung folgen können, die sie beantwortet hat, zum Code, der sie umsetzt, und zum Test, der ihre Funktion belegt, und diesen Weg dann von einem Testergebnis aus rückwärts gehen. Nachvollziehbarkeit kostet fast nichts, wenn Sie sie ab dem ersten Sprint mitbauen, und ist brutal teuer, wenn Sie sie später rekonstruieren müssen. Genau um dieses Problem herum wurde IEC 62304 geschrieben.
• Dokumentation, die während der Arbeit entsteht. Regulierte Projekte brauchen früh eine klare Spezifikation, denn alles, was am Ende zusammengeschrieben wird, beschreibt, was das Team gern gebaut hätte. Anforderungen zuerst zu schreiben bringt außerdem Meinungsverschiedenheiten zutage, solange sie noch günstig zu klären sind. Aus demselben Grund gibt es unsere Services für funktionale Spezifikationen auch für nicht regulierte Kunden.
• Ein Nachweis, nicht nur Tests. Jedes ernsthafte Team testet. Der schwierigere Teil ist, jedes Mal festzuhalten, was passiert ist: welche Version geprüft wurde, wer den Test ausgeführt hat, welche Anforderung er abgedeckt hat und wie das Ergebnis aussah. Genau diesen Nachweis verlangt eine prüfende Stelle, und niemand kann ihn Monate später aus dem Gedächtnis nachbilden. Ihn während der Entwicklung zu pflegen ist die Aufgabe unserer Quality-Assurance-Beratung, und das braucht Planung von Anfang an.
• Datenschutz und Sicherheit, zusätzlich zu den Produktregeln. Jedes Produkt, das Patientendaten berührt, trägt Pflichten, die neben den Medizinprodukteregeln laufen und sie nicht ersetzen. In den USA bedeutet das meist HIPAA. Die Schritte sind bekannt: Daten bei der Übertragung und im Ruhezustand verschlüsseln, Zugriff nach Rolle beschränken, protokollieren, wer was gesehen hat, und Ihre Dienstleister auf denselben Standard verpflichten. Unsere HIPAA-Compliance-Checkliste für Healthcare-Software geht jeden Punkt durch. Planen Sie Sicherheit außerdem als dauerhafte Pflicht ein, mit einem Weg, Schwachstellen zu finden und Fixes über die gesamte Lebensdauer des Produkts auszuliefern, statt einer einzigen Prüfung vor dem Launch.

In einem Software-Development-Audit erfahren Sie, ob diese vier Praktiken tatsächlich eingehalten wurden. Als Redwerk die Codebasis hinter Adoorabelle, einem mobilen Marktplatz, geprüft hat, kam die Bewertung auf 80 Findings. Zwei davon sind für reguliertes Arbeiten am wichtigsten: Das Projekt hatte keine Entwicklertests, und es führte keine Aktivitätsprotokolle. Beides zu vermissen ist in gewöhnlicher kommerzieller Software teuer. In einem regulierten Produkt kann es jedoch verhindern, dass es Patienten überhaupt erreicht. Sie können nicht zeigen, für welche Anforderung ein Stück Code geschrieben wurde, und Sie können nicht belegen, dass es funktioniert.

Typische SaMD-Beispiele nach Risikokategorie

Abstrakte Kategorien sind schwer zu greifen, deshalb hier SaMD-Beispiele, geordnet von niedrigerem zu höherem Risiko. Betrachten Sie sie als Illustration des Musters, nicht als Einordnung eines konkreten Produkts:

• Niedrigeres Risiko: Tools, die eine Entscheidung in einer nicht dringlichen Situation informieren. Eine Symptom-Nachschlage-App, die einer Patientin hilft, einen Hautausschlag vor dem Termin zu beschreiben, informiert, ohne etwas zu entscheiden. Ganz außerhalb des Rahmens ist ein allgemeiner Fitness-Tracker gar nicht reguliert, weil er keine klinische Aussage trifft.
• Mittleres Risiko: Produkte, deren Ergebnis die Versorgung wirklich prägt. Dazu gehört Software, die die Medikationsliste eines Patienten prüft und eine gefährliche Wechselwirkung markiert und damit den nächsten klinischen Schritt steuert. Das Gleiche gilt für ein Tool, das eingehende Fälle triagiert und dringende in der Warteschlange nach vorn zieht, wobei deren Schweregrad es im Raster weiter nach oben schiebt.
• Höheres Risiko: Produkte, die direkt diagnostizieren oder behandeln, besonders in kritischen Zuständen. Bildgebungssoftware, die einen vermuteten Schlaganfall erkennt und das Bereitschaftsteam alarmiert, ist ein bekanntes Beispiel. Ebenso jede Anwendung, die eine Strahlentherapiedosis berechnet, wo ein Fehler irreversible Folgen hat.

Das Muster ist über alle drei Stufen hinweg gleich. Das Risiko steigt, wenn die Antwort des Produkts menschliches Urteil ersetzt statt es zu stützen, und es steigt erneut, wenn der Patient weniger Spielraum hat, einen Fehler zu überleben.

Wo ein Entwicklungspartner hilft, und wo nicht

Ob Ihr Produkt als Software als Medizinprodukt gilt, in welche Kategorie es fällt und was Sie einreichen müssen, sind regulatorische Fragen. Diese Fragen sollte eine qualifizierte Beratung beantworten. Als Entwicklungsunternehmen können wir Ihr Produkt nicht klassifizieren, und Sie sollten bei jedem Anbieter skeptisch sein, der das Gegenteil behauptet.

Ob Ihr Produkt jedoch die Nachweise liefern kann, die eine Behörde sehen will, ist eine Engineering-Frage, und dabei können wir helfen. Die Antwort ergibt sich aus dem Code, den Tests und der Dokumentation, die Sie schon haben. Genau das leistet ein Software-Audit, und es ist meist der günstigste erste Schritt.

Die meisten Teams, die in Schwierigkeiten geraten, sind ohne regulatorischen Plan gestartet. Sie haben ein Gesundheitsprodukt schnell ausgeliefert, Kunden gefunden und dann die Klassifizierungsfrage von einem Einkäufer gehört. Wenn das nach Ihrem Unternehmen klingt, sprechen Sie mit uns über Ihr Healthcare-Software-Projekt und finden Sie heraus, wo Ihr Code und Ihre Dokumentation wirklich stehen.

FAQ

Sehen Sie sich an, wie wir die Project Science-Software von Complete Network geprüft und eine 80-prozentige Steigerung der Wartbarkeit des Codes erreicht haben

Bitte geben Sie Ihre Geschäfts-E-Mail-Adresse ein ist keine Geschäfts-E-Mail

Fallstudie herunterladen