Analyse des britischen KI-Rahmenwerks im Gesundheitswesen: Produktpflichten

Die langweiligste Art, wie KI im Krankenhaus scheitert, ist zugleich die teuerste: Ein Tool funktioniert in einem Pilotprojekt gut genug, und nach der Einführung kann niemand sagen, wer es überwacht. MobiHealthNews berichtet, dass ein Vorschlag einer britischen Kommission zur Regulierung von KI im Gesundheitswesen eine Überwachung über den gesamten Lebenszyklus, die Meldung von KI-Sicherheitsvorfällen, strengere Cybersicherheitsanforderungen und Schulungen für Nutzer fordert. Das ist keine Aufforderung, einen dickeren Ordner mit Richtlinien zu kaufen. Es ist ein Hinweis darauf, dass die betriebliche Oberfläche von KI im Gesundheitswesen Teil des Produkts wird.

Ein Vorschlag mit zwei regulatorischen Uhren

MobiHealthNews beschreibt den britischen Rahmen für KI im Gesundheitswesen als vorgeschlagen, und die Berichterstattung nennt kein Datum für die Durchsetzbarkeit. Das ist wichtig, denn vorgeschlagen ist nicht dasselbe wie durchsetzbar, eine Unterscheidung, die in Konferenzrunden oft verschwindet. Legal Nodes sagt, dass das Vereinigte Königreich an einem sektorspezifischen Rahmen arbeitet, der sich auf bestehende Regulierungsbehörden stützt, damit diese maßgeschneiderte Regeln für KI im Gesundheitswesen festlegen. Parallel dazu sagt Tandem Health, dass der EU AI Act, Verordnung EU 2024/1689, im März 2024 vom Europäischen Parlament angenommen und im Juli 2024 im Amtsblatt der Europäischen Union veröffentlicht wurde, während Legal Nodes sagt, dass die meisten KI-Tools im Gesundheitswesen in die Hochrisikokategorie fallen, wobei die Regeln ab Februar 2025 anwendbar werden und wichtige Fristen bis Juli 2025 reichen.

Die praktische Folge ist vertraut: Anbieter und Krankenhäuser im Vereinigten Königreich bereiten sich möglicherweise auf einen nationalen sektoralen Rahmen vor, während sie zugleich in das EU-System verkaufen, daraus einkaufen oder sich daran messen. Die vernünftige Antwort ist nicht, so zu tun, als wären die beiden Systeme identisch. Sie besteht darin, Nachweise einmal zu erstellen und sie dann sorgfältig den jeweiligen Anforderungen zuzuordnen: Dokumentation für Medizinprodukte, KI-Governance, klinische Sicherheitsprüfung, Datenschutzunterlagen und Absicherung der Beschaffung.

Monitoring gehört in die Produktakte

ASCO AI in Oncology berichtet, dass die Health AI Partnership einen AI Vendor Disclosure Framework für Gesundheitssysteme vorgeschlagen hat. Dieser deckt ab, was ein Tool tut, wie es getestet wurde, was mit den Daten der Organisation passiert, was die Integration erfordert, was es kostet und wer es nach der Einführung überwacht. Diese letzte Frage ist der Punkt, an dem viele Pilotprojekte zu Beschaffungsproblemen werden. Wenn Monitoring nicht bepreist, personell besetzt und technisch unterstützt wird, hat das Krankenhaus ein Versprechen gekauft, hinter dem kein Dashboard steht.

Für Anbieter sollte das Lebenszyklus-Monitoring daher entwickelt werden, bevor das Vertriebsteam eine Einführung verspricht. Ein Vertrag sollte den vorgesehenen Zweck, die vorgesehenen Nutzer, betroffene Bevölkerungsgruppen, Testnachweise, Zusagen zum Umgang mit Daten und die Verantwortung für das Monitoring nach der Einführung benennen können, denn das sind die Fragen, die Beschaffungsteams laut ASCO stellen sollen. Für Krankenhäuser gilt derselbe Punkt umgekehrt: Akzeptieren Sie keine Demonstration als Nachweis dafür, dass das Tool in Ihrer Umgebung sicher betrieben werden kann. Fragen Sie, wer Leistungssignale erhält, wer die Nutzung pausieren kann und was der Anbieter bereitstellen muss, wenn sich das System ändert.

Vorfälle, Cyberkontrollen und Schulungen sind keine Nebenaufgaben

MobiHealthNews berichtet, dass der britische Vorschlag die Meldung von KI-Sicherheitsvorfällen, strengere Cybersicherheitsanforderungen und Nutzerschulungen fordert. Klar gelesen bedeutet das: Incident Response kann nicht erst beginnen, wenn eine Ärztin oder ein Arzt in einer Besprechung Bedenken äußert. Produkte müssen Untersuchungen, Sicherheitsprüfungen und Eskalationen so unterstützen, dass klinische Teams, Informations-Governance-Teams und Lieferantenteams sie tatsächlich nutzen können. Das Gesetz liefert vielleicht noch nicht jede einzelne Vorgabe, aber in der Beschaffungsakte werden leere Felder nicht gut aussehen.

Layer3 Labs weist darauf hin, dass Gesundheitsdaten nach der britischen und der EU-DSGVO besondere Kategorien personenbezogener Daten sind, ihre Verarbeitung standardmäßig verboten ist und Organisationen sowohl eine Bedingung nach Artikel 9 als auch eine Rechtsgrundlage nach Artikel 6 benötigen, bevor sie KI mit Patienten- oder Gesundheitsdaten betreiben. Der Leitfaden verweist außerdem auf KI-spezifische Pflichten rund um Datenschutz-Folgenabschätzungen, Anbieter-Verträge, internationale Übermittlungen und automatisierte Entscheidungen. In der Praxis sind die Meldung von Vorfällen und Cybersicherheit mit der Datenschutz-Compliance verbunden, nicht nur benachbart dazu. Wenn ein Anbieter nicht erklären kann, wohin Gesundheitsdaten gehen, was in den Auftragsverarbeitungsbedingungen steht und wie Offshore-Zugriffe kontrolliert werden, hat das Gespräch über KI-Sicherheit bereits ein Datenschutzproblem bekommen.

Abgrenzungsdebatten werden enger

Digital Colliers sagt, dass die erste regulatorische Frage für Anbieter von KI im Gesundheitswesen in Europa lautet, ob das System ein Medizinprodukt ist. Dabei wird darauf hingewiesen, dass KI, die für Diagnose, Behandlung oder Überwachung von Krankheiten oder Verletzungen oder für klinische Entscheidungsfindung vorgesehen ist, in der EU normalerweise so eingestuft wird. Legal Nodes sagt separat, dass der EU AI Act die meisten KI-Tools im Gesundheitswesen in die Hochrisikokategorie einordnet. Das sind keine identischen Prüfungen, und genau das ist die lästige Schwierigkeit. Ein Produkt kann gleichzeitig einer Medizinprodukteanalyse, Pflichten nach dem AI Act, DSGVO-Pflichten und der Prüfung durch die Krankenhausbeschaffung unterliegen.

Die sinnvolle Vorbereitung ist daher nüchtern. Halten Sie eine Erklärung zum vorgesehenen Zweck bereit, die Produkt-, Regulierungs- und Vertriebsteams nicht stillschweigend umschreiben können. Pflegen Sie Testnachweise, die Population und Umgebung benennen, nicht nur die Kennzahl. Bauen Sie Nutzerschulungen in die Einführung ein, besonders wenn das Tool klinische oder betriebliche Entscheidungen beeinflusst. Beobachten Sie den nächsten Schritt des britischen Vorschlags, aber warten Sie nicht bis zur ersten Durchsetzungsmaßnahme, um festzustellen, dass Monitoring, Meldung, Sicherheit und Schulung in den Release-Plan hätten eingebaut werden müssen.