Wann Gesundheitssoftware als Medizinprodukt gilt

Für ein Team, das Gesundheitssoftware entwickelt, verändert die Antwort auf diese Frage Dauer und Kosten des Projekts. Derselbe Code kann je nachdem, wie das Produkt beschrieben wird, einen sehr unterschiedlichen Compliance-Aufwand mit sich bringen.

Stellen Sie sich zwei Anwendungen vor. Beide nehmen vom Nutzer eingegebene Symptome entgegen, führen einen Algorithmus aus und geben eine Liste zurück. Der Code ist nahezu identisch. Die eine unterliegt dem Medizinprodukterecht, die andere nicht.

Den Unterschied macht der Beschreibungstext im App-Store. Die erste sagt: "informiert anhand Ihrer Symptome über mögliche Zustände". Die zweite sagt: "wertet Ihre Symptome aus und zeigt die wahrscheinliche Diagnose an". Dieser zweite Satz macht das Produkt zu einem mit Diagnosezweck angebotenen Produkt, und damit greifen Risikoklassifizierung, Konformitätsbewertung, technische Dokumentation, klinische Bewertung und Verpflichtungen zur Überwachung nach dem Inverkehrbringen.

Das ist der teuerste und am leichtesten vermeidbare Fehler, den ich in Projekten der Gesundheitstechnologie sehe. Die Produktbeschreibung schreibt das Marketingteam, niemand denkt an die rechtliche Folge, und das Produkt gerät in ein Konformitätsregime, das nie übernommen werden sollte.

Die Zweckbestimmung ist ein Rechtstext

Die daraus folgende praktische Regel lautet: Die Produktbeschreibung muss mit derselben Sorgfalt wie eine Datenschutzerklärung verfasst werden und vor Veröffentlichung eine rechtliche Prüfung durchlaufen.

Diese Prüfung darf sich nicht auf die Store-Beschreibung beschränken. Die Überschrift auf der Website, der Satz im Werbevideo, die Aussage in der Verkaufspräsentation und die Formulierung im Support-Dokument können dasselbe Ergebnis herbeiführen. Haben Sie an einer Stelle "stellt Diagnosen" geschrieben, nimmt das Schreiben von "dient nur Informationszwecken" an anderer Stelle diese Aussage nicht zurück.

Die Entscheidung muss von vornherein getroffen werden. Soll das Produkt ein Medizinprodukt sein, wird der von diesem Regime geforderte Prozess von Anfang an aufgebaut und als Kostenposten in die Planung aufgenommen. Soll es das nicht sein, muss die Wahrung dieser Grenze in jedem Text zur Regel der Produktentwicklung werden.

Die Zugriffsarchitektur bei Gesundheitsdaten

Artikel 6 des Gesetzes Nr. 6698 zählt Gesundheitsdaten zu den besonderen Kategorien personenbezogener Daten und unterwirft ihre Verarbeitung engeren Voraussetzungen. Die technische Entsprechung dieser Einordnung bleibt in den meisten Projekten unvollständig.

Das Bild, das ich häufig sehe, ist dieses. Die Anwendung läuft, Daten werden gespeichert, aber im System kann jeder alles sehen. Der Entwickler kann in die Produktionsdatenbank schauen, das Support-Team kann Patientenakten öffnen, die Führungskraft kann in Berichten Rohdaten sehen. Das bedeutet, dass der Zugriff nicht beschränkt ist, und das lässt sich bei einer Prüfung schwer verteidigen.

Der richtige Aufbau beginnt mit rollenbasiertem Zugriff, endet dort aber nicht. Jeder Zugriff muss protokolliert werden, das Protokoll muss zeigen, wer ihn zu welchem Zweck vorgenommen hat, und ein ungewöhnlicher Zugriff muss auffallen können. Öffnet jemand mitten in der Nacht eine Patientenakte, muss das im System sichtbar sein.

Die Testumgebung ist ein eigenes Thema. Mit echten Patientendaten zu testen, ist die verbreitetste und riskanteste Gewohnheit in der Gesundheitstechnologie. Mit maskierten oder synthetischen Daten zu arbeiten, beseitigt dieses Risiko weitgehend und ist technisch nicht schwer umzusetzen.

Klinische Entscheidungsunterstützung und Verantwortung

KI-gestützte Entscheidungsunterstützungssysteme werfen die Frage auf, wer verantwortlich ist. In der Praxis ist die sichere Ausgestaltung, dass das System einen Vorschlag erzeugt und die endgültige Entscheidung der zuständigen Gesundheitsfachperson überlassen bleibt.

Damit diese Ausgestaltung nicht bloß auf dem Papier bleibt, müssen drei Aufzeichnungen gemeinsam geführt werden. Der vom System erzeugte Vorschlag, die Eingaben, auf denen dieser Vorschlag beruht, und die von der Gesundheitsfachperson getroffene endgültige Entscheidung. Werden alle drei getrennt geführt, lassen sie sich später nicht mehr zuordnen; werden sie gar nicht geführt, lässt sich nicht zeigen, wo die Verantwortung liegt.

Es lohnt sich, hierzu eine Kennzahl hinzuzufügen. Verfolgt werden sollte, wie oft die Gesundheitsfachperson den Vorschlag des Systems ablehnt. Nähert sich diese Quote null, ist die menschliche Aufsicht formal geworden, und an diesem Punkt trifft faktisch das System die Entscheidung selbst. Diese Feststellung kann in einer Verantwortungsdiskussion entscheidend sein.

Gesundheitsfernversorgung

Gesundheitsfernversorgung wird im Rahmen der Vorschriften des Gesundheitsministeriums durchgeführt. Welche Leistungen aus der Ferne erbracht werden dürfen, Dokumentationspflichten und die Grenzen der Leistung werden in untergesetzlichen Vorschriften festgelegt. Da sich diese Vorschriften im Laufe der Zeit ändern können, muss beim Produktentwurf der jeweils aktuelle Text herangezogen werden.

Der unveränderliche Grundsatz lautet: Situationen, die eine persönliche Untersuchung erfordern, können nicht aus der Ferne behandelt werden. Eine Fernversorgungsanwendung muss eine diese Grenze überschreitende Anfrage erkennen und weiterleiten können. Dass das System sagen kann "bitte wenden Sie sich für diesen Fall an eine Ärztin oder einen Arzt", ist kein Usability-Merkmal, sondern eine rechtliche Notwendigkeit.

Beim Start eines Projekts

In Projekten der Gesundheitstechnologie ist die im ersten Meeting zu beantwortende Frage nicht, was das Produkt tun wird, sondern als was es sich ausgibt. Jede Codezeile, die geschrieben wird, bevor diese Frage beantwortet ist, kann nach dem falschen Regime geschrieben worden sein.

Die zweite Frage betrifft das Datenmodell. Welches Datum ist wirklich erforderlich, wer darf es sehen, wo wird der Zugriff protokolliert und was geschieht, wenn der Zweck entfällt. Die Antwort auf diese vier Fragen bestimmt unmittelbar den Entwurf der Tabellen, und eine nachträgliche Änderung erfordert die Migration bestehender Patientendaten und schafft dadurch sowohl ein technisches als auch ein rechtliches Problem.