Thema 1.6 — Klinische Sicherheit und Risikomanagement

In einem Satz: Klinische Sicherheit ist die disziplinierte, belegte Praxis, die Wege zu finden, auf denen Ihre digitale Technologie Patientinnen und Patienten schaden könnte, und diese Gefährdungen zu beherrschen, bevor sie jemanden erreichen – Sicherheit, die von der ersten Skizze an eingeplant ist, nicht kurz vor dem Go-live angeflanscht.

Warum das in Gesundheit und Pflege wichtig ist#

In den meisten Branchen ist ein Softwarefehler eine Unannehmlichkeit: Eine Seite lädt nicht, eine Bestellung wird verdoppelt, ein Bericht kommt zu spät. In Gesundheit und Pflege kann dieselbe Fehlerklasse töten. Ein Medikationsfeld, das ein Dezimalkomma abschneidet, ein Ergebnisbildschirm, der die falsche Patientin zeigt, ein Triage-Algorithmus, der still aufhört, ein Symptom zu markieren, eine Integration, die unbemerkt Allergiedatensätze verliert – jedes ist ein Softwarefehler, und jedes ist zugleich eine klinische Gefährdung, die schwere Schäden oder den Tod verursachen kann. Deshalb ist klinische Sicherheit keine Qualitätsnettigkeit, die auf gute Softwareentwicklung aufgesetzt wird; sie ist eine eigenständige, regulierte Disziplin mit eigenen Standards, Rollen und Nachweisen.

Der Einsatz ist asymmetrisch und oft unsichtbar. Wenn ein digitales System funktioniert, sieht niemand den Schaden, den es verhindert hat; wenn es versagt, kann der Schaden katastrophal, verzögert und über Tausende Patientinnen und Patienten verteilt sein, bevor jemand ein Muster bemerkt. Diese Kombination – hohe Folgen, geringe Sichtbarkeit, großer Wirkungsradius – bedeutet, dass Sie sich weder darauf verlassen können, dass Nutzende Probleme abfangen, noch darauf, dass Vorfälle Ihnen alles beibringen. Sie müssen proaktiv über Schaden nachdenken, vor dem Einsatz, und weiter darüber nachdenken, solange das System live ist. Im Vereinigten Königreich ist dieses proaktive Nachdenken nicht optional: NHS-Organisationen und ihre Lieferanten sind vertraglich und beruflich verpflichtet, nationale Standards des klinischen Risikomanagements anzuwenden und ihre Arbeit belegen zu können. Das richtig zu tun ist untrennbar von Evidenz (siehe Thema 1.3 — Evidenzbasierte Entscheidungen), von Informationsgovernance und Cybersicherheit (siehe Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit) und davon, wie Sie Services betreiben, sobald sie live sind (siehe Thema 3.8 — Servicemanagement und Live-Betrieb).

Kernkonzepte#

Patientensicherheit und Risikomanagement. Patientensicherheit ist die Verhütung, Verringerung, Meldung und Analyse von Schaden für Patientinnen und Patienten durch Versorgung. Klinisches Risikomanagement wendet die allgemeine Disziplin des Risikomanagements – Risiken identifizieren, bewerten, priorisieren und beherrschen – auf die besondere Frage an, wie ein Gesundheits-IT-System zu Patientenschaden beitragen könnte. Die beiden nationalen Standards, die dies in England regeln, sind DCB0129 und DCB0160 (DCB steht für Data Coordination Board; es handelt sich um Standards des Standardisation Committee for Care Information / SCCI, verbindlich nach dem Health and Social Care Act 2012). DCB0129 legt Pflichten auf den Hersteller oder Lieferanten eines Gesundheits-IT-Systems; DCB0160 legt Pflichten auf die Gesundheitsorganisation, die es einsetzt und nutzt. Sie ergänzen sich: Der saubere Safety Case eines Lieferanten erfüllt nicht die Pflicht eines einsetzenden Trusts, die Gefährdungen zu bewerten, die durch seine eigene Konfiguration, seinen Arbeitsablauf und seinen Kontext entstehen.

Der Clinical Safety Officer (CSO). Beide Standards verlangen einen benannten, geeignet qualifizierten und erfahrenen Clinical Safety Officer – eine registrierte, aktuell praktizierende Klinikerin oder einen Kliniker mit anerkannter Schulung in klinischer Sicherheit –, der die Aktivitäten des klinischen Risikomanagements verantwortet und den Safety Case persönlich freigibt. Die CSO-Rolle ist eine Kompetenzanforderung, keine Amtsbezeichnung, die man der Person zuweisen kann, die gerade frei ist. Der CSO bestätigt, dass Gefährdungen identifiziert und auf ein akzeptables Niveau beherrscht wurden; es ist ein berufliches Urteil mit beruflicher Verantwortlichkeit.

Die Artefakte des klinischen Risikomanagements. Drei Dokumente verankern die Disziplin. Die Akte des klinischen Risikomanagements (Clinical Risk Management File) ist der Container für alle Sicherheitsnachweise eines Systems. Das Gefährdungsprotokoll (Hazard Log) ist das lebendige Register jeder identifizierten Gefährdung, ihrer Ursachen, Folgen, Risikobewertung, Kontrollen und Restrisiken. Der klinische Safety Case ist die strukturierte, durch Nachweise gestützte Argumentation, dass das System für seinen vorgesehenen Zweck in seinem vorgesehenen Kontext akzeptabel sicher ist – begleitet von einem Safety-Case-Bericht, der die Argumentation zur Freigabe zusammenfasst. Das ist kein Papierkram um seiner selbst willen; so wird Sicherheitsargumentation explizit, überprüfbar und dauerhaft.

Gefährdungsanalyse: Identifikation, Analyse, Bewertung, Beherrschung. Die Kernschleife lautet: Gefährdungsidentifikation (systematisch vorstellen, wie das System zu Schaden beitragen könnte – durch Workshops, klinische Durchgänge, Fehlermodusanalyse), Risikoanalyse (Schwere des Schadens und Eintrittswahrscheinlichkeit abschätzen), Risikobewertung (das geschätzte Risiko mit Akzeptanzkriterien vergleichen) und Risikobeherrschung (Maßnahmen einführen – Designänderungen, Warnungen, Schulung, Verfahren –, um inakzeptables Risiko zu senken, dann das Restrisiko neu bewerten). Das Risiko wird so weit wie vernünftigerweise praktikabel gesenkt (ALARP): Sie beherrschen weiter, bis eine weitere Senkung in grobem Missverhältnis zum erzielten Nutzen stünde.

Regulierung von Medizinprodukten, die MHRA und Software as a Medical Device (SaMD). Manche digitale Gesundheitstechnologie ist ein reguliertes Medizinprodukt. Software mit medizinischem Zweck – diagnostizieren, verhüten, überwachen, vorhersagen, behandeln – kann selbst ein Medizinprodukt sein: Software as a Medical Device (SaMD). Im Vereinigten Königreich reguliert die Medicines and Healthcare products Regulatory Agency (MHRA) Medizinprodukte einschließlich SaMD, und der Softwarelebenszyklus-Standard IEC 62304 regelt, wie solche Software entwickelt werden muss. Zu entscheiden, ob Ihre Technologie ein reguliertes Produkt ist, ist eine Schwellenfrage mit großen Folgen und getrennt von – wenn auch neben – dem klinischen Risikomanagement nach DCB0129/0160.

Die Digital Technology Assessment Criteria (DTAC). DTAC ist die nationale Basis, mit der NHS- und Sozialfürsorge-Organisationen digitale Produkte vor der Beschaffung bewerten, und deckt klinische Sicherheit (Nachweis der DCB0129-Konformität), Datenschutz, technische Sicherheit, Interoperabilität und Nutzbarkeit ab. Sie ersetzt das klinische Risikomanagement nicht; sie prüft, dass ein Lieferant es durchgeführt hat.

Human Factors und Sicherheitskultur. Human Factors (Ergonomie) ist die wissenschaftliche Untersuchung, wie Menschen unter realen Bedingungen mit Systemen interagieren – Müdigkeit, Unterbrechung, kognitive Belastung, Alarmmüdigkeit. Der meiste digitale Schaden entsteht nicht durch „falschen“ Code, sondern durch Designs, die die sichere Handlung schwer und die unsichere leicht machen. Sicherheitskultur ist das organisatorische Bekenntnis, Risiken ohne Schuldzuweisung aufzudecken, zu melden und daraus zu lernen – der Unterschied zwischen einem Team, das Beinahe-Vorfälle verbirgt, und einem, das sie für Verbesserung auswertet.

Vorfallmeldung und Lernen. In England ist Learn from Patient Safety Events (LFPSE) der nationale Dienst zur Erfassung von Patientensicherheitsereignissen, und das Patient Safety Incident Response Framework (PSIRF) legt fest, wie NHS-Organisationen auf Vorfälle reagieren und daraus lernen – mit Betonung verhältnismäßiger, systembasierter Ursachenanalyse statt Schuldzuweisung. Live-Systeme erzeugen neue Gefährdungen; klinische Sicherheit setzt sich daher nach dem Go-live fort, indem Vorfallrückmeldungen in das Gefährdungsprotokoll fließen.

Bewährte Praktiken#

1. Ernennen Sie einen kompetenten Clinical Safety Officer und geben Sie ihm echte Befugnis. Benennen Sie für jedes System im Geltungsbereich eine registrierte, praktizierende Klinikerin mit anerkannter Schulung in klinischer Sicherheit als CSO und stellen Sie sicher, dass ihre Freigabe ein echtes Tor ist, kein am Vortag des Starts erreichter Gummistempel. Der CSO muss „noch nicht“ sagen können und gehört werden – das heißt, seine Zeit, seine Unabhängigkeit und sein Standing beim Programmgremium zu schützen. Ein CSO, der vom Lieferdruck überstimmt wird, ist eine Governance-Fiktion.

2. Führen Sie die Gefährdungsidentifikation früh durch, mit Klinikpersonal im Raum. Beginnen Sie Gefährdungsworkshops in Discovery und Design, nicht vor dem Go-live, denn die billigsten und wirksamsten Kontrollen sind Designänderungen, die vor dem Bau erfolgen (siehe Thema 3.5 — Lieferlebenszyklen). Holen Sie Klinikpersonal an der Front, nicht nur Analysten, denn es weiß, wie die Arbeit wirklich abläuft – die Unterbrechungen, die Umgehungen, die Art, wie ein Bildschirm um 3 Uhr morgens gelesen wird. Gehen Sie realistische klinische Szenarien durch und fragen Sie unablässig: „Wie könnte dieses System dazu beitragen, dass eine Patientin geschädigt wird?“

3. Führen Sie ein lebendiges Gefährdungsprotokoll, kein Dokument für den Starttag. Behandeln Sie das Gefährdungsprotokoll als dauerhaftes Register, das in der Discovery beginnt und nie schließt, solange das System live ist. Jede Gefährdung hält ihre Ursachen, den möglichen Schaden, die anfängliche Risikobewertung, die angewandten Kontrollen und das Restrisiko nach Kontrollen fest. Wenn ein Vorfall, eine Änderung oder ein Beinahe-Vorfall eine neue Gefährdung offenbart, tritt sie in das Protokoll ein und durchläuft dieselbe Schleife – das Protokoll ist das Gedächtnis Ihrer Sicherheitsargumentation.

4. Lassen Sie die einsetzende Organisation DCB0160 verantworten, auch bei einem konformen Lieferanten. Der DCB0129-Safety-Case eines Lieferanten deckt das Produkt wie gebaut ab; er kann nicht abdecken, wie Sie es konfigurieren, welche Arbeitsabläufe Sie darum herum legen oder welche Ihrer Populationen es nutzen. Führen Sie Ihre eigene DCB0160-Bewertung für lokale Gefährdungen durch – Integration mit Ihren anderen Systemen, Ihre Datenqualität, Ihre klinischen Pfade – und halten Sie Ihr eigenes Gefährdungsprotokoll. Anzunehmen, die Absicherung des Lieferanten decke Ihren Kontext ab, ist eine verbreitete und gefährliche Abkürzung.

5. Machen Sie Risikokontrolle verhältnismäßig und ziehen Sie Design Warnungen vor. Ordnen Sie Kontrollen nach Stärke: die Gefährdung wegzudesignen (Einschränkungen, Voreinstellungen, erzwingende Funktionen) schlägt eine Bildschirmwarnung, die wiederum eine Zeile im Schulungshandbuch schlägt. Reservieren Sie die schwerste Absicherung für die Gefährdungen mit den höchsten Folgen und wenden Sie leichteren, schnelleren Prozess auf wirklich risikoarme Änderungen an – Verhältnismäßigkeit ermöglicht, dass Sicherheit mit der Lieferung Schritt hält. Senken Sie das Risiko auf ALARP und halten Sie fest, warum das Restrisiko akzeptabel ist.

6. Gestalten Sie für Human Factors und respektieren Sie Alarmmüdigkeit. Gehen Sie davon aus, dass Nutzende beschäftigt, unterbrochen und mustererkennend sind, und gestalten Sie so, dass die sichere Handlung die leichte, voreingestellte ist. Hüten Sie sich vor Alarmüberlastung: Eine Warnung, die zu oft auslöst, wird ignoriert; jede zusätzliche Warnung muss sich daher ihren Platz verdienen, sonst schwächt sie die, die zählen. Usability-Tests unter realistischen Bedingungen sind eine Aktivität der klinischen Sicherheit, nicht nur eine Designnettigkeit.

7. Bestimmen Sie Ihren regulatorischen Status bewusst. Fragen Sie früh, ob Ihre Software die Definition eines Medizinprodukts oder SaMD erfüllt, und wenn ja, beziehen Sie MHRA-Anforderungen und IEC 62304 von Anfang an ein, statt die Pflicht spät zu entdecken. Falsche Klassifizierung ist in beide Richtungen teuer – ein nicht registriertes Produkt ist ein rechtliches und Sicherheitsversagen, während das Überklassifizieren eines einfachen Werkzeugs knappe Absicherungskapazität verschwendet. Holen Sie im Zweifel regulatorischen Rat ein und dokumentieren Sie die Begründung.

8. Nutzen Sie DTAC als Untergrenze, nicht als Ziellinie. Behandeln Sie die Digital Technology Assessment Criteria als Mindest-Eingangsprüfung für jedes beschaffte digitale Produkt, die bestätigt, dass klinische Sicherheit, Datenschutz, Sicherheit, Interoperabilität und Nutzbarkeit adressiert wurden. Das Bestehen von DTAC bedeutet, dass ein Lieferant die Arbeit geleistet hat; es bedeutet nicht, dass das Produkt in Ihrem Kontext sicher ist – koppeln Sie es daher mit Ihrer eigenen DCB0160-Bewertung und Live-Überwachung.

9. Schließen Sie die Schleife von Live-Vorfällen in das Gefährdungsprotokoll. Verdrahten Sie Ihre Vorfallmeldung – LFPSE-Einreichungen, PSIRF-Untersuchungen, lokale Beinahe-Vorfall-Meldungen – zurück in das klinische Risikomanagement, sodass realer Schaden und Beinahe-Vorfälle Ihre Gefährdungen und Kontrollen aktualisieren. Ein Safety Case, der nach dem Go-live nie wieder betrachtet wird, verrottet, weil Live-Systeme, Integrationen und klinische Praxis alle driften (siehe Thema 3.8 — Servicemanagement und Live-Betrieb). Lernen ist systembasiert und schuldbewusst, keine Suche nach jemandem, den man bestrafen kann.

10. Bauen Sie eine gerechte, meldende Sicherheitskultur. Machen Sie es sicher und erwartet, Beinahe-Vorfälle zu melden und einen Start aus Sicherheitsgründen anzufechten, denn Gefährdungen, von denen Sie nie hören, sind Gefährdungen, die Sie nicht beherrschen können. Führungskräfte setzen diesen Ton, indem sie auf schlechte Nachrichten mit Neugier und Verbesserung statt mit Schuldzuweisung reagieren und die Vorsicht des CSO als wertvoll statt hinderlich behandeln. Kultur ist der Nährboden, von dem jede andere Praxis hier abhängt.

Fragen zur Diskussion im Team#

1. Wo in unserem aktuellen Portfolio verlassen wir uns auf die Sicherheitsabsicherung eines Lieferanten, um Risiken abzudecken, die tatsächlich uns gehören? Diese Frage lotet die Teilung zwischen DCB0129 und DCB0160 aus, die Teams routinemäßig verwischen. Der DCB0129-Safety-Case eines Lieferanten behandelt das Produkt wie hergestellt, doch sobald Sie es konfigurieren, mit Ihren anderen Systemen verbinden, lokale Arbeitsabläufe darum legen und es auf Ihre spezifische Patientenpopulation richten, führen Sie Gefährdungen ein, die der Lieferant nie bewertet hat und nicht bewerten konnte. Die ehrliche Spannung: Ihre eigene DCB0160-Bewertung kostet knappe klinische und analytische Zeit, und es ist verlockend, die saubere Absicherung eines Lieferanten und ein bestandenes DTAC als ausreichend zu behandeln. Gehen Sie einen laufenden oder bevorstehenden Einsatz durch und fragen Sie konkret: Wer ist unser benannter CSO dafür, haben wir ein eigenes Gefährdungsprotokoll, und welche Gefährdungen entstehen allein aus unserem lokalen Kontext statt aus dem Produkt selbst? Eine gute Antwort benennt konkrete Systeme, bei denen die lokale Bewertung dünn ist, unterscheidet Produktgefährdungen von Einsatzgefährdungen und verpflichtet sich, Letztere zu verantworten, statt anzunehmen, sie seien abgedeckt.

2. Wie verhältnismäßig ist unser Prozess der klinischen Sicherheit – begraben wir risikoarme Änderungen unter Papierkram, während Änderungen mit hohen Folgen aus Schwung durchrutschen? Das Thema argumentiert, Absicherung solle mit dem klinischen Risiko skalieren: schwerste Prüfung für die Gefährdungen mit den höchsten Folgen, leichterer und schnellerer Prozess, wo das Risiko wirklich gering ist. Diese Frage prüft, ob Ihre Organisation tatsächlich kalibriert oder eine einzige stumpfe Einstellung anwendet. Beide Fehlrichtungen sind real und teuer – ein durchgängig schwerer Prozess erzieht Teams dazu, klinische Sicherheit als bürokratische Steuer zu sehen und zu umgehen, während ein durchgängig leichter Prozess eine Änderung an einer Medikationsdosis-Berechnung mit demselben Aufwand passieren lässt wie eine Änderung an einer Hilfeseite. Die subtilere Gefahr ist, dass Schwung, nicht Risiko, die Prüfung bestimmt: Ein Vorzeigeprogramm mit Aufmerksamkeit der Führungsebene kann eine Aura der Unausweichlichkeit erwerben, die den CSO davon abhält, „noch nicht“ zu sagen. Untersuchen Sie zwei oder drei jüngere Änderungen deutlich unterschiedlichen Risikos und fragen Sie, ob der Aufwand dem Schadenspotenzial entsprach und ob sich jemand imstande fühlte, das prominente Vorhaben zu bremsen. Eine ehrliche Antwort räumt ein, wo der Prozess in eine der Richtungen falsch kalibriert ist, und behandelt Verhältnismäßigkeit als vertretbares, explizites Urteil statt als Reflex.

3. Als bei einem unserer digitalen Systeme beinahe etwas schiefging, was geschah danach tatsächlich – und würde eine Klinikerin an der Front sagen, es sei sicher gewesen, es anzusprechen? Diese Frage untersucht Sicherheitskultur und die Schleife des Vorfalllernens, wo erklärte Bekenntnisse auf die Realität treffen. Klinische Sicherheit hängt davon ab, von Beinahe-Vorfällen zu hören, doch Menschen melden nur, wenn sich das Melden sicher und lohnend anfühlt und sie sehen, dass es zu Veränderung führt statt zu Schuldzuweisung. Die Spannung: Unter Liefer- und Reputationsdruck ist der Instinkt, einen Beinahe-Vorfall wegzuerklären, schnell zu schließen und weiterzumachen – besonders, wenn sein vollständiges Aufdecken einen Start verzögern oder eine leitende Förderin blamieren würde. Der systembasierte, schuldbewusste Ansatz von PSIRF existiert gerade deshalb, weil die Suche nach einem Einzelnen, dem man die Schuld gibt, die benötigten Meldungen unterdrückt und die realen, systemischen Ursachen verfehlt. Verankern Sie die Diskussion an einem konkreten jüngeren Beinahe-Vorfall oder Vorfall: Wurde er erfasst, gelangte er in das Gefährdungsprotokoll, wurde eine verhältnismäßige Untersuchung durchgeführt, und hat sich tatsächlich etwas geändert? Eine gute Antwort ist offen darüber, ob sich das Melden sicher anfühlte, unterscheidet echtes Lernen von Papierabschluss und benennt konkrete Verhaltensweisen, die Führungskräfte annehmen, damit die nächste Person, die eine Gefährdung sieht, sich äußert.

4. Haben wir ehrlich bestimmt, welche unserer Produkte regulierte Medizinprodukte sind – und wer ist für diese Entscheidung verantwortlich? Der regulatorische Status ist eine Schwellenfrage mit überproportionalen Folgen, und es ist leicht, sie unbeantwortet zu lassen, weil die Antwort unbequem sein kann. Software, die diagnostiziert, vorhersagt, überwacht oder behandelt, kann selbst Software as a Medical Device sein und zieht MHRA-Pflichten und den Lebenszyklus-Standard IEC 62304 nach sich – getrennt von und zusätzlich zum klinischen Risikomanagement nach DCB0129/0160. Die Spannung wirkt in beide Richtungen: Unterklassifizieren lässt Sie ein nicht registriertes Produkt ausliefern, ein rechtliches und Sicherheitsversagen, das im großen Maßstab katastrophal auftauchen kann, während das Überklassifizieren eines einfachen Verwaltungswerkzeugs knappe Absicherungskapazität verbrennt, die Sie anderswo brauchten. Die Gefahr ist, dass die Klassifizierung zwischen Rollen fällt – Klinikpersonal nimmt an, die Entwickler hätten entschieden, Entwickler nehmen an, das Regulatory- oder Kommerzielle Team habe entschieden, und niemand hat die Begründung tatsächlich aufgeschrieben. Betrachten Sie konkret die Produkte Ihres Portfolios, die der Grenze am nächsten liegen – alles mit einer Triage-Regel, einem Risikowert, einem Alarmalgorithmus – und fragen Sie, wer die Produktfeststellung traf, auf welcher Grundlage und ob sie dokumentiert und bei Funktionsänderungen erneut betrachtet wird. Eine ehrliche Antwort benennt die Grenzprodukte, verweist für jedes auf eine festgehaltene, vertretbare Begründung und ist offen, wo die Entscheidung nie wirklich getroffen wurde.

5. Designen wir Gefährdungen weg, oder sammeln wir still Warnungen und Alarme an, die unser Klinikpersonal bereits zu ignorieren gelernt hat? Das Thema ordnet Kontrollen nach Stärke – die Gefährdung wegzudesignen schlägt eine Bildschirmwarnung, die eine Zeile im Schulungshandbuch schlägt –, doch Warnungen sind der Weg des geringsten Widerstands, weil eine Warnung hinzuzufügen schnell geht und verantwortungsvoll wirkt, während einen Arbeitsablauf neu zu gestalten langsam und umstritten ist. Mit der Zeit summiert sich diese Neigung zu Alarmmüdigkeit: So viele Warnungen lösen aus, dass Klinikpersonal an allen vorbei mustererkennt, auch an der, die zählt, sodass jede neue Warnung die Sicherheit tatsächlich senken kann. Die eigentliche Spannung ist, dass jede unnötige Warnung einen Förderer hat, der sie nach einem Vorfall in gutem Glauben hinzugefügt hat, was Warnungen politisch schwer entfernbar macht, selbst wenn sie das System verschlechtern. Human Factors ist hier die Disziplin – so zu gestalten, dass die sichere Handlung die leichte, voreingestellte für eine beschäftigte, unterbrochene Nutzerin ist, die um 3 Uhr morgens einen Bildschirm liest –, und Usability-Tests unter realistischen Bedingungen sind eine Aktivität der klinischen Sicherheit, keine Designnettigkeit. Untersuchen Sie ein System, das Ihre Teams tatsächlich nutzen, und fragen Sie, wie vielen Warnungen ein Kliniker bei einer typischen Aufgabe begegnet, welche davon das Verhalten wirklich ändern und wo eine erzwingende Funktion oder eine bessere Voreinstellung eine Warnung ganz hätte ersetzen können. Eine gute Antwort widersteht dem Reflex, noch eine Warnung hinzuzufügen, behandelt Alarmlast als messbare Gefährdung eigenen Rechts und ist bereit, Warnungen zu entfernen, die sich ihren Platz nicht mehr verdienen.

6. Wie wissen wir, während unsere Live-Systeme, Integrationen und klinischen Pfade über die Zeit driften, dass unser Safety Case noch trägt? Klinische Sicherheit endet nicht beim Go-live; Live-Systeme erzeugen neue Gefährdungen, und die Welt um ein System bewegt sich weiter – eine vorgelagerte Integration ändert ihre Daten, ein klinischer Pfad wird neu gestaltet, ein Lieferant liefert ein Update, eine neue Patientenkohorte beginnt, das Werkzeug zu nutzen. Ein vor zwei Jahren freigegebener Safety Case beschreibt ein System und einen Kontext, die es womöglich nicht mehr gibt; die Frage ist also, ob Ihr Gefährdungsprotokoll ein lebendiges Register ist oder ein Dokument, das einmal unterzeichnet und dem Verrotten überlassen wurde (siehe Thema 3.8 — Servicemanagement und Live-Betrieb). Die Spannung: Sicherheitsargumentation nach dem Start zu pflegen konkurriert mit neuer Lieferung um dieselbe knappe CSO- und klinische Zeit, und Drift ist schleichend und unsichtbar auf eine Weise, die selten Aufmerksamkeit erhält, bis etwas versagt. Konkrete Ansatzpunkte sind Änderungskontrolle, die die Gefährdungsbewertung erneut auslöst, wenn sich Konfiguration oder Integrationen ändern, periodische Überprüfung der Gefährdungen mit den höchsten Folgen und Überwachung, die eine still verfallende Kontrolle tatsächlich erkennen würde. Wählen Sie ein System, das ein Jahr oder länger live ist, und fragen Sie, wann seine Gefährdungen zuletzt überprüft wurden, was sich seit der Freigabe darunter verändert hat und wer bemerken würde, wenn eine Schlüsselkontrolle aufhörte zu funktionieren. Eine ehrliche Antwort unterscheidet Systeme mit echtem laufendem Sicherheitsmanagement von solchen, die auf einem veralteten Safety Case dahingleiten, und verpflichtet sich zu einem verhältnismäßigen Überprüfungstakt, gebunden an reale Änderung statt allein an den Kalender.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) setzt ein gemeinsames E-Überweisungswerkzeug ein, mit dem Hausärztinnen und Hausärzte Patientinnen und Patienten direkt in Gemeindedienste überweisen können, mit einem eingebauten Triage-Regelwerk, das dringende Fälle in eine schnellere Warteschlange leitet. Ein lieferorientierter Ansatz würde den DCB0129-Safety-Case des Lieferanten nehmen, DTAC bestehen und live gehen, um einen vom Vorstand versprochenen Termin zu halten.

Stattdessen ernennt das Programm einen praktizierenden Hausarzt mit Schulung in klinischer Sicherheit zum Clinical Safety Officer und eröffnet zu Beginn des Designs eine Akte des klinischen Risikomanagements und ein Gefährdungsprotokoll. Frühe Gefährdungsworkshops mit Hausärztinnen, Gemeindepflegekräften und Verwaltungskräften fördern mehrere Gefährdungen zutage, die der produktbezogene Fall des Lieferanten nie berührte – alle aus dem lokalen Einsatz entstehend. Die schlimmste: Die Triage-Regeln wurden gegen die eigenen Servicedefinitionen des ICS konfiguriert, und ein Zuordnungsfehler könnte eine dringende Hautkrebs-Überweisung in eine Routine-Dermatologie-Warteschlange mit mehrwöchiger Wartezeit leiten. Diese Gefährdung wird als hohe Schwere, plausible Wahrscheinlichkeit bewertet.

In der Risikokontroll-Schleife bevorzugt das Team Design vor Warnungen. Es fügt eine erzwingende Funktion hinzu, sodass ein dringendes klinisches Kennzeichen von der Routing-Logik nicht still überschrieben werden kann, einen Abgleichsbericht, den eine Klinikerin täglich prüft, und – am niedrigsten in der Hierarchie – einen Schulungshinweis. Das Restrisiko wird neu bewertet und als akzeptabel und ALARP beurteilt; der CSO hält fest, warum. Weil das Werkzeug nur leitet und nicht selbst diagnostiziert, bewertet das Team, dass es die SaMD-Schwelle nicht erreicht, dokumentiert diese Begründung und legt sie ab. Human-Factors-Tests entdecken ein separates Problem: Eine übereifrige „Doppelüberweisung“-Warnung löst so oft aus, dass Hausärztinnen sie bereits ignorieren; sie wird deshalb so umgestaltet, dass sie nur bei echten Duplikaten auslöst.

Beim Go-live wird der DCB0160-Safety-Case vom CSO freigegeben, nicht vom Programmdirektor. Drei Wochen später offenbaren eine LFPSE-Meldung und ein von einer Empfangskraft markierter Beinahe-Vorfall eine neue Gefährdung – ein Freitextfeld, über das dringende Informationen eingeschmuggelt werden, die das Routing nie sieht. Unter PSIRF läuft eine verhältnismäßige, systembasierte Überprüfung, die Gefährdung tritt in das Protokoll ein, eine Designänderung wird terminiert und eine Übergangskontrolle noch in derselben Woche eingewiesen. Der Safety Case ist eine lebendige Argumentation, und die Aufzeichnung zeigt genau, wie über jede Gefährdung nachgedacht wurde – was eine Inspektorin, ein Coroner oder ein neuer CSO in zwei Jahren brauchen wird.

Sektorperspektiven#

Alle schulden dieselbe Pflicht, klinisches Risiko zu beherrschen, doch Maschinerie, Anreize und Druck unterscheiden sich stark je nach Organisation.

Startup#

Ein Startup der digitalen Gesundheit begegnet klinischer Sicherheit oft als Beschaffungstor: Ein NHS-Käufer verlangt DTAC und einen DCB0129-Safety-Case, und es gibt Hektik. Der gewinnende Zug ist, klinisches Risikomanagement vom ersten Sprint an einzubauen – ein Gefährdungsprotokoll neben dem Backlog, ein erreichbarer Clinical Safety Officer (oft beauftragt statt angestellt, aber wirklich kompetent und befähigt) –, denn einen Safety Case nachträglich auf ein fertiges Produkt zu setzen ist langsam, teuer und wenig überzeugend. Gründerinnen und Gründer müssen sich zudem ehrlich und früh der SaMD-Frage stellen, denn mitten im Skalieren zu entdecken, dass das Produkt ein nicht registriertes Medizinprodukt ist, ist ein existenzielles rechtliches und Sicherheitsrisiko. Gut gemacht werden ausgereifte Artefakte der klinischen Sicherheit zu einem kommerziellen Vorteil, der NHS-Verkaufszyklen verkürzt.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim, ein ambulanter Pflegedienst, eine Einzelstandort-Klinik oder ein kleiner Health-Tech-Lieferant jenseits der Phase ohne Umsatz – trägt bei Einsatz und Konfiguration digitaler Systeme dieselbe DCB0160-Pflicht wie ein großer Trust, aber ohne jede Reservekapazität, sie zu erfüllen. Es gibt selten einen eigenen CSO oder Sicherheitsanalysten auf der Gehaltsliste; der praktische Weg ist daher, eine kompetente, praktizierende Klinikerin auf Vertragsbasis einzukaufen und ein schlankes, aber echtes Gefährdungsprotokoll zu führen, statt so zu tun, als gelte die Pflicht nicht. Die schärfsten lokalen Gefährdungen sind meist Konfigurations- und Arbeitsablaufgefährdungen – wie die gemeinsame Akte eingerichtet ist, wie dringende Kennzeichen behandelt werden, wie die Umgehungslösung einer Teilzeit-Verwaltungskraft zum Routingrisiko wird –, genau die Gefährdungen, die der DCB0129-Fall eines Lieferanten nie abdeckt. Verhältnismäßigkeit ist hier der Freund des kleinen Anbieters: Konzentrieren Sie die wenige Absicherungszeit, die Sie haben, auf die Gefährdungen mit den höchsten Folgen, nutzen Sie DTAC und den Safety Case des Lieferanten als Untergrenze bei der Produktwahl und stützen Sie sich auf geteilte Ressourcen wie die Unterstützung für klinische Sicherheit des ICS, statt den ganzen Apparat allein aufzubauen.

Großunternehmen#

Ein NHS Trust oder ICS trägt doppelte Verantwortung: Er setzt Systeme anderer unter DCB0160 ein und baut oder konfiguriert oft eigene unter DCB0129 stark. Das charakteristische Versagen ist institutionell – ein Vorzeigeprogramm für die elektronische Patientenakte, dessen Go-live-Termin politisches Gewicht hat, sodass die Vorsicht des CSO still als Hindernis behandelt wird. Das Korrektiv ist strukturell: dem CSO Unabhängigkeit und ein echtes Vetorecht geben, ein lebendiges Gefährdungsprotokoll über den gesamten Bestand statt eines Regals mit Starttag-Dokumenten führen und das Lernen aus LFPSE und PSIRF als ständigen Prozess in das klinische Risikomanagement zurückverdrahten. Im Großunternehmensmaßstab sind die größten Gefährdungen Integrations- und Konfigurationsgefährdungen, die keine Lieferantenabsicherung abdeckt; lokale Verantwortung ist daher nicht verhandelbar.

Regierung#

Eine nationale Stelle – NHS England, die MHRA, DHSC, NICE – setzt die Standards, die andere erfüllen müssen, sodass ihre Arbeitsweisen das ganze System prägen: DCB0129/0160, DTAC und die SaMD-Regulierung sind Instrumente der Sicherheit im Bevölkerungsmaßstab. Entscheidungen hier ziehen regulatorische, parlamentarische und öffentliche Kontrolle an, und ein national vorgeschriebenes System mit latenter Gefährdung verteilt diesen Schaden über Millionen, bevor jemand das Muster sieht. Die Pflichten sind in veröffentlichten Standards explizit gemachte Verhältnismäßigkeit, Transparenz über Restrisiko und ein aktuell gehaltener Regulierungsrahmen, während Technologie – besonders KI – ihn überholt (siehe Thema 8.4 — Governance von KI und aufkommenden Technologien). Das besondere Risiko in dieser Größenordnung ist systemisch: Eine Technologie im ganzen Bestand auf dünner Sicherheitsevidenz vorzuschreiben, verfestigt eine Gefährdung überall zugleich.

Häufige Fehlermuster#

• Sicherheit am Ende angeflanscht. Einen Safety Case in der Woche vor dem Go-live erstellen, um ein Tor zu erfüllen. Gegenmittel: das Gefährdungsprotokoll in der Discovery eröffnen; die größten Gefährdungen wegdesignen.
• Lieferantenabsicherung mit lokaler Sicherheit verwechselt. Einen DCB0129-Fall und ein bestandenes DTAC als Deckung Ihres Einsatzes behandeln. Gegenmittel: die eigene DCB0160-Bewertung und das lokale Gefährdungsprotokoll verantworten.
• CSO als Gummistempel. Ein Clinical Safety Officer ohne Zeit, Unabhängigkeit oder Befugnis, „noch nicht“ zu sagen. Gegenmittel: die Rolle schützen und die Freigabe zu einem echten Tor machen.
• Totes Gefährdungsprotokoll. Ein Dokument, das einmal geschrieben und nach dem Start nie wieder betrachtet wird. Gegenmittel: lebendig halten; Vorfälle und Änderungen einspeisen.
• Alarmüberlastung. So viele Warnungen, dass Klinikpersonal alle ignoriert, auch die lebenswichtigen. Gegenmittel: Human-Factors-Design; jede Warnung muss sich ihren Platz verdienen.
• Schuldkultur. Einzelne für Beinahe-Vorfälle bestrafen, sodass Meldungen versiegen. Gegenmittel: eine gerechte, systembasierte Kultur im Einklang mit PSIRF.
• Verpasste regulatorische Schwelle. SaMD ausliefern, ohne es als reguliertes Produkt zu erkennen. Gegenmittel: den Medizinproduktestatus früh bewerten und dokumentieren.

Reifegradmodell#

Checkliste#

• Ein kompetenter, praktizierender, geschulter Clinical Safety Officer ist für jedes System benannt, mit Zeit und Befugnis, „noch nicht“ zu sagen.
• Für jedes System im Geltungsbereich existieren eine Akte des klinischen Risikomanagements, ein lebendiges Gefährdungsprotokoll und ein klinischer Safety Case.
• Die Gefährdungsidentifikation begann in der Discovery, mit Klinikpersonal an der Front im Raum.
• Die einsetzende Organisation hat ihre eigene DCB0160-Bewertung durchgeführt, nicht nur den DCB0129-Fall des Lieferanten akzeptiert.
• Risikokontrollen bevorzugen Wegdesignen vor Warnungen vor Schulung, mit auf ALARP gesenktem und begründetem Restrisiko.
• Der Status als Medizinprodukt / SaMD wurde bewertet und dokumentiert, und MHRA-/IEC-62304-Pflichten wurden dort einbezogen, wo relevant.
• DTAC wurde als Untergrenze abgeschlossen, gekoppelt mit lokalem klinischem Risikomanagement.
• Human-Factors- und Usability-Tests unter realistischen Bedingungen wurden durchgeführt; die Alarmlast ist beherrscht.
• Live-Vorfälle (LFPSE) und PSIRF-Lernen speisen das Gefährdungsprotokoll als ständigen Prozess.
• Beinahe-Vorfälle zu melden und einen Start aus Sicherheitsgründen anzufechten ist sichtbar sicher und erwartet.

Zentrale Quellen#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — Clinical Safety Officer training und Leitlinien zum klinischen Risikomanagement.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MHRA — Leitlinien Software and Artificial Intelligence (AI) as a Medical Device.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — Dienst Learn from Patient Safety Events (LFPSE).
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• Weltgesundheitsorganisation — Global Patient Safety Action Plan 2021–2030.

Referenzen#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan