Thema 6.4 — Governance und Assurance

Governance existiert, um Ihnen zu helfen, gute, schnelle, sichere Entscheidungen zu treffen und – sich selbst, Ihrem Vorstand und der Öffentlichkeit – zu belegen, dass ein digitaler Dienst verantwortungsvoll betrieben wird; behandeln Sie sie daher als Ermöglicher der Lieferung, nicht als Steuer darauf.

Warum das in Gesundheit und Pflege wichtig ist#

In den meisten Sektoren kostet schwache Governance Geld und Ruf. In Gesundheit und Pflege kann sie Leben kosten, Ungleichheit verfestigen und das öffentliche Vertrauen untergraben, von dem das ganze System abhängt. Eine schlecht gesteuerte Änderung an einem klinischen System kann einen Dosierungsfehler zu Tausenden Patientinnen und Patienten fortpflanzen, bevor jemand es bemerkt; ein ungesteuerter Datenfluss kann die Vertraulichkeit der verletzlichsten Menschen verletzen, denen Sie dienen; ein nicht abgesicherter Go-live kann einen Dienst festschreiben, der still jene ausschließt, die Versorgung am meisten brauchen. Der Einsatz ist der Grund, warum „wie Sie arbeiten“ eine Frage der klinischen Sicherheit, der Gleichstellung und des Vertrauens ist, nicht bloß der Effizienz.

Zugleich hat Governance in Gesundheit und Pflege einen wohlverdienten Ruf, langsam, ritualisiert und von der Lieferung abgekoppelt zu sein. Teams sitzen durch Vorstandssitzungen, die bereits getroffene Entscheidungen abnicken, füllen Vorlagen aus, die niemand liest, und sehen gelbe Risiken in der Woche vor einer Überprüfung auf Grün springen, nur um danach spektakulär zu scheitern. Das ist das Paradox, das Sie auflösen müssen. Die Antwort ist nicht weniger Governance oder mehr; es ist verhältnismäßige Governance, die mit Risiko und Wert skaliert, klaren Menschen klare Rechenschaft gibt und ehrliche Information schnell genug erzeugt, um darauf zu handeln. Dieses Thema zeigt, wie Sie das aufbauen und wie Sie unabhängige Assurance darauf schichten, damit die Rechenschaftspflichtigen – und die Öffentlichkeit – sicher sein können, dass die Kontrollen tatsächlich funktionieren. Es verbindet sich eng mit Thema 1.6 — Klinische Sicherheit und Risikomanagement, Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit, Thema 5.3 — Enterprise-Projektportfoliomanagement (EPPM) und Thema 10.4 — Sichtbarkeit für die Geschäftsführung und leitende Führungskräfte.

Kernkonzepte#

Governance ist das System aus Entscheidungsrechten, Rechenschaft und Aufsicht, durch das eine Organisation lenkt und kontrolliert, was sie tut. In der digitalen Gesundheit und Pflege managen Sie eigentlich drei sich überlappende Governance-Domänen zugleich. Corporate Governance umfasst die Verwaltung der Organisation als Ganzes durch den Vorstand – Finanzen, Strategie, Risiko und Rechtspflichten. Klinische Governance ist der Rahmen, durch den Gesundheitsorganisationen dafür rechenschaftspflichtig sind, Qualität und Sicherheit der Versorgung fortlaufend zu verbessern. Informationsgovernance umfasst, wie die Organisation Daten rechtmäßig, sicher und ethisch handhabt. Ein digitaler Dienst berührt alle drei; steuern Sie nur eine, werden Sie von den anderen überrascht.

Rechenschaft an einer einzelnen Stelle ist das Rückgrat guter Governance. Die Senior Responsible Owner (SRO) ist die eine benannte Person, die persönlich dafür rechenschaftspflichtig ist, dass ein Programm oder Großprojekt seine Ziele erreicht und seine Nutzen realisiert – eine von der britischen Regierung populär gemachte, aber universell nützliche Rolle. Entscheidungsrechte unterhalb der SRO werden über eine Verantwortungszuordnungsmatrix explizit gemacht, üblicherweise in der RACI-Form (Responsible, Accountable, Consulted, Informed – durchführend, rechenschaftspflichtig, konsultiert, informiert), die die zwei klassischen Fehler verhindert: „alle dachten, jemand anderes verantwortet es“ und „alle versuchten, es zu verantworten“.

Assurance ist von Governance verschieden. Governance ist der Akt des Lenkens und Entscheidens; Assurance ist unabhängige, objektive Bestätigung, dass Governance und Kontrollen tatsächlich wie beabsichtigt funktionieren. Das dominante Denkmodell sind die „drei Verteidigungslinien“: Die erste Linie ist das operative Management, das Risiko im Tagesgeschäft besitzt und managt; die zweite Linie sind Aufsichtsfunktionen (Risiko, Compliance, klinische Sicherheit, Informationsgovernance), die Richtlinien setzen und hinterfragen; und die dritte Linie ist die interne Revision, von beiden unabhängig und dem Vorstand berichtend. Externe Regulierer und Prüfer bilden eine faktische vierte Linie.

Zwei weitere Konzepte halten das System zusammen. Risikobereitschaft (Risk Appetite) ist Menge und Art des Risikos, das die Organisation im Streben nach ihren Zielen zu akzeptieren bereit ist; ohne sie ist Eskalation willkürlich. Und das Risikologbuch – oft zu einem RAID-Log (Risks, Assumptions, Issues, Dependencies) erweitert, gebaut auf derselben Disziplin wie ein Risikoregister – ist die Arbeitsakte, die eine Lieferung ehrlich hält. Überprüfungspunkte liefert gestufte Assurance wie ein Phase-Gate-Prozess und, in der britischen Regierung, Gateway-artige Überprüfungen der Infrastructure and Projects Authority (IPA). Über dem Niveau jedes einzelnen Projekts sitzt das Enterprise Risk Management, die organisationsweite Disziplin, die Risiken zu identifizieren und zu managen, die die ganze Organisation an der Erreichung ihrer Ziele hindern könnten, statt digitales, klinisches, finanzielles, Cyber- und operatives Risiko als getrennte Silos zu behandeln.

Bewährte Praktiken#

1. Benennen Sie eine rechenschaftspflichtige SRO und meinen Sie es ernst. Ernennen Sie eine einzelne, ausreichend senior positionierte Person, die persönlich für das Ergebnis rechenschaftspflichtig ist, die Befugnis hat, Entscheidungen zu treffen, und lange genug beim Programm bleibt, um zur Rechenschaft gezogen zu werden. Schreiben Sie ihre Rechenschaft in das Mandat (Terms of Reference) und in ihre Ziele. Widerstehen Sie der Versuchung, Rechenschaft über ein Komitee zu verteilen – Komitees beraten und entscheiden gemeinsam, können aber nicht rechenschaftspflichtig sein, denn geteilte Rechenschaft ist abwesende Rechenschaft.

2. Gestalten Sie Governance nach Risiko und Wert, nicht nach dem Kalender. Ein kleines, risikoarmes internes Werkzeug braucht nicht denselben Vorstand, dieselben Tore und denselben Papierkram wie eine regionsweite elektronische Patientenakte. Legen Sie Stufen fest, sodass risikoarme, wertarme Arbeit durch leichtgewichtige Governance auf Teamebene fließt, während risikoreiche oder wertvolle Arbeit formale Gremien und unabhängige Überprüfung nach sich zieht. Veröffentlichen Sie die Schwellen, damit Teams wissen, in welcher Stufe sie sind, und sich selbst bedienen können. Verhältnismäßigkeit verhindert, dass Governance zum Engpass wird, den Teams umgehen.

3. Schreiben Sie Mandate, die Entscheidungsrechte klären. Jedes Gremium sollte ein kurzes Mandatsdokument haben, das Zweck, Mitgliedschaft, Beschlussfähigkeit, welche Entscheidungen es treffen kann, was es nur empfehlen kann und was darüber hinaus eskalieren muss, nennt. Koppeln Sie das mit einer RACI, damit wiederkehrende Entscheidungstypen – Architekturentscheidungen, klinische Freigabe, Budgetfreigabe, Go-live-Genehmigung – eine benannte rechenschaftspflichtige Verantwortliche haben. Mehrdeutige Entscheidungsrechte sind die häufigste Ursache von Governance-Drift, bei der sich Sitzungen vermehren, weil niemand sicher ist, wer tatsächlich Ja sagen kann.

4. Trennen Sie Assurance von Governance und nutzen Sie die drei Linien. Lassen Sie nicht zu, dass die Menschen, die ein Programm liefern, die einzigen sind, die dessen Sicherheit bestätigen. Stellen Sie sicher, dass die zweite Linie – klinische Sicherheitsbeauftragte, Leitungen der Informationsgovernance, Cybersicherheit – eine unabhängige Stimme hat und bei Bedarf über den Kopf der SRO hinweg eskalieren kann und dass die interne Revision das ganze System periodisch prüft. Diese Trennung verwandelt optimistische Selbstberichte in glaubwürdige Assurance und ist in den meisten Gesundheitssystemen eine regulatorische Erwartung, keine Nettigkeit.

5. Nutzen Sie integrierte Assurance und gestufte Überprüfungspunkte. Statt unkoordinierte Überprüfungen zu beauftragen, planen Sie einen integrierten Assurance- und Freigabeplan, der klinische Sicherheit, Informationsgovernance sowie technische und kommerzielle Überprüfungen an denselben Entscheidungspunkten ausrichtet. Übernehmen Sie Gateway-artige Überprüfungen an den Übergängen, die zählen – vor der Bindung von Geld, vor dem Aufbau, vor dem Go-live –, nach dem Vorbild der IPA-Gateway-Reviews und, für öffentlich zugängliche digitale Dienste, der vom Government Digital Service (GDS) begründeten und vom NHS angepassten Service-Assessments. Ein gutes Tor ist eine unterstützende Herausforderung, die die nächste Phase entschärft, keine Prüfung, die man austrickst.

6. Machen Sie Risikobereitschaft explizit und lassen Sie sie Eskalation treiben. Vereinbaren Sie auf Vorstandsebene, wie viel Risiko Sie in jeder Domäne tragen wollen – Patientensicherheit, Daten, Lieferung, Finanzen, Reputation – und drücken Sie es konkret genug aus, dass ein Team erkennen kann, ob ein bestimmtes Risiko innerhalb oder außerhalb der Bereitschaft liegt. Koppeln Sie dann die Eskalation an die Bereitschaft: Alles außerhalb der Bereitschaft steigt automatisch auf, mit benannter Verantwortlicher und Entscheidungsfrist. Das stoppt die zwei Fehlermodi, dass Trivia den Vorstand verstopfen und ernste Risiken still in einer Tabelle liegen.

7. Führen Sie ein lebendes RAID-Log und ein Board Assurance Framework. Pflegen Sie ein RAID-Log, das in jedem Lieferzyklus überprüft wird, jeder Eintrag verantwortet, datiert, bewertet und aktiv bearbeitet – kein Friedhof veralteter gelber Posten. Pflegen Sie auf Organisationsebene ein Board Assurance Framework (BAF), das Ihre wichtigsten strategischen Risiken auf die vorhandenen Kontrollen und die Assurance abbildet, dass diese Kontrollen funktionieren, und Lücken sichtbar macht, wo Sie sich auf Hoffnung verlassen. Das BAF lässt einen Vorstand auf einer Seite sehen, ob seine wichtigsten Ziele tatsächlich geschützt sind.

8. Berichten Sie ehrlich und töten Sie Governance-Theater. Bestehen Sie auf offenen Statusberichten, die schlechte Nachrichten früh zutage fördern, und schützen Sie die Menschen, die sie überbringen. Achten Sie auf „Wassermelonen-Berichte“ – außen grün, innen rot –, bei denen Dashboards bis zum Moment des Scheiterns grün bleiben; kontern Sie, indem Assurance-Funktionen und Lieferleitungen über dieselben Fakten berichten. Streichen Sie jede Sitzung, Vorlage oder jeden Bericht, die keine Entscheidung verändern. Governance, die Dokumente erzeugt, auf die niemand handelt, ist keine Vorsicht, sondern als Sorgfalt verkleidete Verschwendung.

9. Managen Sie Risiko auf Unternehmensebene, nicht nur auf Projektebene. Führen Sie ein Enterprise-Risikoregister auf Vorstandsebene und eine schriftliche Erklärung zur Risikobereitschaft, die digitales, klinisches, finanzielles, Cyber- und operatives Risiko verbinden, statt jedes in seinem eigenen Silo zu behandeln. Viele Risiken, die digitale Gesundheitsdienste tatsächlich versenken – ein alternder Bestand an Altsystemen, ein Cyberangriff, Überabhängigkeit von einem einzelnen Lieferanten –, durchziehen jedes Projekt und gehören keinem; geben Sie jedem übergreifenden Risiko daher eine benannte leitende Verantwortliche und einen Platz im Register. Das ist der Unterschied zwischen dem Wissen, dass Ihre Programme je ungefähr auf Kurs sind, und dem Wissen, ob die Organisation als Ganzes innerhalb ihrer Bereitschaft liegt.

10. Aggregieren Sie dieselben Risiken zum Vorstand hinauf, ohne sie zu beschönigen. Verdrahten Sie Ihre drei Verteidigungslinien so, dass ein von einem Liefer-Team gesehenes Risiko erkennbar zum Enterprise-Register aufsteigt, nicht auf jeder Ebene in beruhigende Sprache umverpackt. BAF und Enterprise-Register sind nur so ehrlich wie die Berichterstattung darunter; hüten Sie sich also vor dem Wassermelonen-Effekt, bei dem Gelb auf dem Weg nach oben zu Grün wird, und machen Sie es zur Routine, übergreifende Risiken – Altsysteme, Cyber, Lieferantenkonzentration – zu eskalieren, die kein einzelnes Projekt besitzt. Ein Vorstand, der nur aggregierte, aufgeweichte Zahlen sieht, kann die Risiken, die am meisten zählen, nicht steuern.

Fragen zur Diskussion im Team#

1. Wo ist Rechenschaft an einer einzelnen Stelle bei unserer wichtigsten digitalen Arbeit wirklich klar, und wo ist sie eine bequeme Fiktion? Gehen Sie Ihre drei wichtigsten Initiativen durch und fragen Sie bei jeder, wer dem Vorstand persönlich Rede und Antwort stünde, wenn sie scheiterte. Lautet die ehrliche Antwort „der Vorstand“, „das Programm“ oder ein Name, der sich ständig ändert, haben Sie eine Lücke. Prüfen Sie, ob die benannte SRO tatsächlich die Befugnis und Zeit hat, die die Rolle verlangt, oder eine Galionsfigur ist, während echte Entscheidungen anderswo fallen. Bedenken Sie, ob Rechenschaft durch eine Matrix untergraben wird, in der die SRO die Menschen, die liefern, nicht anweisen kann. Besprechen Sie, wie Kontinuität geschützt wird, wenn SROs weiterziehen, denn Rechenschaft, die mit jeder Reorganisation zurückgesetzt wird, ist keine Rechenschaft. Das Ziel ist nicht, Einzelne zu beschuldigen, sondern sicherzustellen, dass, wenn etwas schiefgeht, eine befähigte Person es in Ordnung zu bringen verantwortet.

2. Ist unsere Governance verhältnismäßig, oder wenden wir schwergewichtigen Prozess auf risikoarme Arbeit an und umgekehrt? Bilden Sie Ihre aktuellen Gremien, Tore und Freigabeschritte auf das tatsächliche Risiko und den Wert dessen ab, was sie durchläuft. Suchen Sie die risikoarme Änderung, die sechs Wochen auf ein monatlich tagendes Gremium wartete, und die risikoreiche klinische Änderung, die auf eigenes Wort eines Teams durchrutschte. Fragen Sie, ob Teams Governance umgehen, weil sie zu langsam ist – was selbst ein ernstes Risikosignal ist. Bedenken Sie, ob Sie klare Stufen und Schwellen veröffentlicht haben oder ob alles aus Vorsicht auf maximales Zeremoniell zurückfällt. Debattieren Sie, wo Sie Entscheidungen sicher delegieren könnten, um schneller zu werden, und wo Sie gefährlich leicht waren. Das Ziel ist ein System, in dem das Gewicht der Governance sichtbar dem Gewicht des Risikos folgt.

3. Woran würden wir merken, ob unsere Berichterstattung uns die Wahrheit sagt? Besprechen Sie konkrete jüngste Beispiele, in denen ein Status mit wenig Vorwarnung von Grün auf Rot sprang, und fragen Sie, was die Frühsignale waren und warum sie nicht auftauchten. Prüfen Sie, ob Lieferleitungen und Assurance-Funktionen aus denselben Fakten oder aus getrennten, bequem abweichenden Versionen berichten. Bedenken Sie, was sozial und beruflich mit jemandem geschieht, der hier einen roten Status meldet – wird sie bedankt oder bestraft? Fragen Sie, ob Ihr Vorstand unabhängige Assurance neben dem eigenen Bericht des Managements sieht oder nur Letzteres. Untersuchen Sie, ob Ihre Dashboards Dinge messen, die Probleme vorhersagen, oder nur Dinge, die leicht grün zu machen sind. Der Zweck ist, eine Kultur aufzubauen, in der ehrliche schlechte Nachrichten schnell reisen, denn ein Governance-System, das schlechte Nachrichten nicht hören kann, kann nicht steuern.

4. Haben wir unsere Risikobereitschaft konkret genug aufgeschrieben, dass ein Team danach handeln kann, oder ist sie ein Slogan? Nehmen Sie ein aktuelles Risiko in einem Ihrer Programme und fragen Sie, ob die Menschen, die ihm am nächsten sind, anhand Ihrer erklärten Bereitschaft erkennen könnten, ob es innerhalb oder außerhalb der Linie liegt. Die meisten Organisationen haben eine Erklärung zur Risikobereitschaft, die sich gut liest und nichts entscheidet – „wir verfolgen einen ausgewogenen Ansatz zum Risiko“ sagt keiner Klinikerin, ob ein unentdeckter Mangel der Allergieanzeige tolerierbar ist. Besprechen Sie, ob Bereitschaft je Domäne ausgedrückt wird – Patientensicherheit, Daten, Lieferung, Finanzen, Reputation –, denn eine einzelne globale Zahl verbirgt, dass Sie womöglich null Bereitschaft für Mängel der klinischen Sicherheit und echte Bereitschaft für Terminverzug haben. Prüfen Sie, ob Eskalation tatsächlich an die Bereitschaft gekoppelt ist, sodass alles außerhalb automatisch mit benannter Verantwortlicher und Frist aufsteigt, statt davon abzuhängen, dass jemand sich entscheidet, es zu melden. Bedenken Sie, wem die Bereitschaft gehört und wie oft sie neu aufgesucht wird, denn eine einmal gesetzte und nie überprüfte Bereitschaft driftet aus dem Gleichschritt mit der realen Welt. Eine ehrliche Antwort nennt eine jüngste Entscheidung, die die Erklärung zur Bereitschaft wirklich prägte, und räumt ein, wo die Erklärung derzeit zu vage ist, um zu greifen.

5. Haben unsere Tore und Assurance-Überprüfungen tatsächlich Zähne, oder segeln scheiternde Programme hindurch? Schauen Sie auf Ihre letzten Gateway- oder Service-Assessment-Überprüfungen und fragen Sie, ob eine davon die Arbeit stoppte, pausierte oder wesentlich umformte – hat jedes Programm jedes Tor bestanden, sind Ihre Tore beinahe sicher Theater. Besprechen Sie, ob Überprüfungen als unterstützende Herausforderung behandelt werden, die die nächste Phase entschärft, oder als Prüfung, die man austrickst, mit einem kuratierten Evidenzpaket, um ein Bestehen zu sichern. Bedenken Sie, ob klinische Sicherheit, Informationsgovernance, technische und kommerzielle Assurance an denselben Entscheidungspunkten eintreffen oder als Streuung unkoordinierter Überprüfungen, die Teams erschöpfen, ohne Vertrauen hinzuzufügen. Prüfen Sie, welche Befugnis eine Torprüferin tatsächlich hat: Kann sie einen Go-live anhalten, und wird sie gestützt, wenn sie es tut, oder überstimmt sie kommerzieller Druck? Untersuchen Sie, ob die Menschen, die liefern, faktisch auch die sind, die absichern – denn ein Tor, das von den Optimisten geführt wird, ist keine Assurance. Das Ziel ist eine Überprüfung, die ein ernstes Problem nicht überleben könnte, denn ein Tor, an dem nie etwas scheitert, sind Kosten ohne Kontrolle dahinter.

6. Welche der Risiken, die uns tatsächlich versenken könnten, gehören keinem einzelnen Projekt, und wer besitzt sie? Listen Sie die Ausfälle auf, die Ihre digitalen Dienste am ehesten stoppen – ein alternder Bestand an Altsystemen, ein Cyberangriff, Überabhängigkeit von einem Lieferanten, eine Belegschaft, die die neuen Werkzeuge nicht bedienen kann – und fragen Sie bei jedem, in wessen Register es steht. Diese übergreifenden Risiken sind gerade deshalb gefährlich, weil sie allen und damit niemandem gehören und durch die Ritzen der Governance auf Projektebene fallen. Besprechen Sie, ob Sie ein Enterprise-Risikoregister auf Vorstandsebene führen, das digitales, klinisches, finanzielles, Cyber- und operatives Risiko verbindet, oder jedes in seinem eigenen Silo, blind für die anderen, gemanagt wird. Bedenken Sie, ob ein von einem Liefer-Team gesehenes Risiko erkennbar zum Vorstand aufsteigt oder auf jeder Ebene von Rot über Gelb zu Grün aufgeweicht wird, bis der Vorstand nur Beruhigung sieht. Prüfen Sie, ob jedes übergreifende Risiko eine benannte leitende Verantwortliche mit der Befugnis hat, über Programme hinweg zu handeln. Eine ehrliche Antwort stellt sich der Lücke zwischen dem Wissen, dass jedes Programm ungefähr auf Kurs ist, und dem Wissen, ob die Organisation als Ganzes innerhalb ihrer Bereitschaft liegt.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) führt eine gemeinsame Patientenakte ein, die Klinikpersonal über Krankenhäuser, Hausarztpraxis und Sozialpflege hinweg eine einheitliche Sicht auf jede Patientin gibt. Sie ist hochwertig und risikoreich: Sie berührt klinische Entscheidungen, verknüpft sensible Daten über Organisationen hinweg und bedient eine Bevölkerung mit großer Streuung im digitalen Zugang.

Anfangs ist die Rechenschaft trübe. Drei Chief Information Officers fühlen sich je teilweise verantwortlich, ein Lieferant treibt den Zeitplan, und der Programmvorstand aus achtzehn Personen verbringt seine Sitzungen damit, Updates zu empfangen, statt zu entscheiden. Die Berichterstattung ist grün. Dann taucht ein Beinahe-Vorfall auf: Eine in einem System erfasste Medikamentenallergie wird in einem anderen nicht angezeigt, und eine Klinikerin verordnet beinahe ein Arzneimittel, gegen das die Patientin allergisch ist.

Die Geschäftsführungen nehmen dies zum Wendepunkt und bauen die Governance neu auf. Sie ernennen eine SRO – eine Chief Medical Officer mit der Seniorität, das Programm zu lenken, und dem Standing, den Lieferanten zu hinterfragen. Sie schreiben das Mandat des Vorstands neu, kürzen ihn auf die Entscheidenden und fügen eine RACI an, sodass klinische Sicherheitsfreigabe, Genehmigung der Informationsgovernance und Go-live-Freigabe je eine benannte rechenschaftspflichtige Verantwortliche haben. Die Risikobereitschaft wird explizit gemacht: null Bereitschaft für unentdeckte Mängel der klinischen Sicherheit, begrenzte Bereitschaft für Terminverzug. Diese einzelne Erklärung ordnet alles neu.

Assurance wird von der Lieferung getrennt. Die klinische Sicherheitsbeauftragte und die Leitung der Informationsgovernance berichten unabhängig und können über die SRO hinweg an die Geschäftsführungen eskalieren; die Arbeit an der gemeinsamen Akte wird in das Board Assurance Framework jedes Partners aufgenommen. Ein integrierter Assurance-Plan setzt drei Tore – vor weiterem Aufbau, vor dem Pilot, vor dem vollen Rollout –, jedes kombiniert klinische Sicherheit, Informationsgovernance sowie technische und Barrierefreiheits-Überprüfungen, im Geiste der IPA-Gateway-Reviews und NHS-Service-Assessments. Das RAID-Log wird vierzehntägig überprüft, der Mangel der Allergieanzeige ist als rotes Issue mit benannter Verantwortlicher und festem Lösungsdatum protokolliert.

Das erste Tor ist unbequem: Das Prüfteam findet, dass der Sicherheitsfall dünner ist, als die grünen Berichte nahelegten, und der Rollout wird um vier Wochen pausiert. Es ist genau die Wassermelone, die die alte Berichterstattung verborgen hatte. Weil die Pause vor dem Pilot statt nach dem Go-live geschieht, kommt keine Patientin zu Schaden, der Lieferant behebt die Datenzuordnung, und der schließliche Rollout ist langsamer im Start, aber weit sicherer und vertrauenswürdiger. Governance verlangsamte die Lieferung nicht; sie verhinderte ein Scheitern, das sie ganz gestoppt hätte.

Sektorperspektiven#

Startup#

Ein Health-Tech-Startup braucht selten Vorstände und Gateway-Reviews, aber es braucht früh das Wesentliche, denn Regulierer, Käufer und Investoren werden fragen. Benennen Sie eine rechenschaftspflichtige Gründerin oder Führungskraft für klinische Sicherheit und eine für Datenschutz, führen Sie ein leichtes RAID-Log und schreiben Sie Ihre Risikobereitschaft auf, auch wenn es nur eine Seite ist. Die Falle ist, Governance als etwas zu behandeln, das man später aufsetzt; das Nachrüsten von Belegen für sichere, rechtmäßige Entscheidungen über ein sich schnell bewegendes Produkt ist schmerzhaft und manchmal unmöglich. Bauen Sie die minimal tragfähige Governance, die ein ernsthafter NHS-Käufer erkennen würde, und lassen Sie sie mit Ihnen wachsen, statt über Nacht von nichts zu Bürokratie zu springen.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – trägt dieselben gesetzlichen Pflichten zu klinischer Sicherheit und Datenschutz wie ein großer Trust, aber ohne Prüfungsausschuss, ohne interne Revision und oft ohne eigenes IT-Personal, sie zu führen. Die Governance-Disziplin ist hier radikale Verhältnismäßigkeit: eine benannte Person, die für klinische Sicherheit rechenschaftspflichtig ist, und eine für Informationsgovernance (in einer sehr kleinen Organisation kann das dieselbe leitende Klinikerin oder derselbe Partner sein), eine einseitige Risikobereitschaft und ein kurzes RAID-Log, das wirklich überprüft statt abgelegt wird. Stützen Sie sich auf die Frameworks, die Ihre Regulierer ohnehin erwarten – das Data Security and Protection Toolkit, CQC-Anforderungen und alle Pflichten zur klinischen Sicherheit, die Ihre Lieferanten erfüllen müssen –, und lassen Sie die Assurance Ihrer Softwarehersteller (deren DCB0129-Sicherheitsfälle, deren Zertifizierungen) Arbeit leisten, die Sie selbst nicht leisten können. Die realistische Falle ist nicht Governance-Theater, sondern Governance-Vernachlässigung: sichere, rechtmäßige Entscheidungen, informell getroffen und nie aufgezeichnet, sodass Sie bei einem Vorfall oder einer Inspektion nicht zeigen können, was Sie entschieden und warum. Halten Sie den Belegpfad leicht, aber real, denn für ein kleines Unternehmen ist das Ziel vertretbare Entscheidungen mit schmalem Budget, keine Governance-Maschine, die Sie nicht besetzen können.

Großunternehmen#

Ein großer Anbieter oder Lieferant hat bereits Vorstände, Prüfungsausschüsse und interne Revision; das Risiko im Großunternehmen ist daher das Gegenteil des Startups: zu viel Governance, schlecht integriert, Theater erzeugend. Konsolidieren Sie überlappende Gremien, veröffentlichen Sie Verhältnismäßigkeitsstufen und integrieren Sie klinische, Informations-, technische und kommerzielle Assurance in einen einzigen Plan, damit Teams einem stimmigen Satz von Toren statt einem Dutzend unkoordinierter Überprüfungen gegenüberstehen. Stellen Sie sicher, dass die drei Verteidigungslinien wirklich unabhängig sind und dass die interne Revision digitale Lieferung periodisch prüft, nicht nur Finanzen. Der Gewinn ist, eine bestehende, teure Governance-Maschine in eine zu verwandeln, die sichere Entscheidungen tatsächlich beschleunigt.

Regierung#

Nationale und regionale Stellen – NHS England, ICBs, ihm nahestehende Stellen – arbeiten unter gesetzlicher Rechenschaft, öffentlichen Ausgabenkontrollen und formalen Assurance-Regimen wie IPA-Gateway-Reviews und den Ausgabenkontroll- und Service-Assessment-Prozessen der Regierung. Hier ist die SRO-Rolle kodifiziert und persönlich gegenüber dem Parlament oder seinen Entsprechungen rechenschaftspflichtig, und Transparenz ist eine Pflicht, keine Wahl. Die Disziplin ist, diese vorgeschriebene Governance verhältnismäßig zu machen und die vielen externen Assurance-Anforderungen so aufeinander abzustimmen, dass sie die Lieferung informieren, statt sie nur im Nachhinein zu prüfen. Gut gemacht, ist Governance im öffentlichen Sektor ein Vorbild der Rechenschaft; schlecht gemacht, ist sie der Ursprung des „Governance-Theaters“, das der ganze Sektor fürchtet.

Häufige Fehlermuster#

• Rechenschaft durch Komitee. Keine einzelne SRO; wenn etwas schiefgeht, zeigen alle zur Seite, und nichts wird verantwortet.
• Governance-Theater. Vorstände, die empfangen statt entscheiden, Vorlagen, die niemand liest, und Tore, die Prüfungen zum Bestehen sind statt echter Entschärfung.
• Wassermelonen-Berichte. Der Status bleibt grün bis zum Moment des Scheiterns, weil schlechte Nachrichten unwillkommen sind und Lieferberichte von der Assurance unangefochten bleiben.
• Ein Prozess für alle. Schwergewichtige Governance auf triviale Arbeit angewandt, die Teams zum Umgehen treibt, während wirklich riskante Arbeit leicht durchrutscht.
• Von der Lieferung vereinnahmte Assurance. Die Menschen, die den Dienst bauen, sind die einzigen, die bestätigen, dass er sicher ist; Optimismus bleibt ungeprüft.
• Veraltete RAID-Logs. Risiken einmal protokolliert und nie bearbeitet; gelbe Posten, die vor einer Überprüfung still auf Grün springen, ohne dass sich darunter etwas ändert.
• Domänenblindheit. Die Lieferung gut steuern, aber die Dimension klinische Sicherheit, Informationsgovernance oder Gleichstellung verpassen, bis sie zur Krise wird.
• Tortheater ohne Zähne. Überprüfungspunkte, die Arbeit nie tatsächlich stoppen oder umformen, sodass scheiternde Programme durch jedes Tor segeln.

Reifegradmodell#

Checkliste#

• Jede große Initiative hat eine benannte, ausreichend senior positionierte, befähigte SRO.
• Jedes Gremium hat ein aktuelles Mandat, das Entscheidungsrechte, Beschlussfähigkeit und Eskalation nennt.
• Eine RACI weist jedem wiederkehrenden Entscheidungstyp eine benannte rechenschaftspflichtige Verantwortliche zu.
• Governance-Stufen skalieren mit Risiko und Wert, und die Schwellen sind veröffentlicht.
• Die drei Verteidigungslinien sind vorhanden, mit einer unabhängigen Stimme der zweiten Linie, die eskalieren kann.
• Ein integrierter Assurance-Plan richtet klinische, informationsgovernance-bezogene, technische und kommerzielle Überprüfungen an gestuften Toren aus.
• Risikobereitschaft ist je Domäne aufgeschrieben, und Eskalation ist daran gekoppelt.
• Ein lebendes RAID-Log wird in jedem Lieferzyklus überprüft, jeder Eintrag verantwortet und datiert.
• Ein Board Assurance Framework bildet Hauptrisiken auf Kontrollen und die Assurance ab, dass diese Kontrollen funktionieren.
• Lieferung und Assurance berichten aus denselben Fakten, und das Überbringen schlechter Nachrichten ist sicher.
• Jede Sitzung, Vorlage und jeder Bericht, die Sie behalten, verändert eine reale Entscheidung.

Zentrale Quellen#

• Infrastructure and Projects Authority (IPA), Principles for Project Success und Leitlinien zu Gateway-/Assurance-Reviews — UK Cabinet Office / HM Treasury.
• NHS England, Clinical Risk Management Standards (DCB0129 und DCB0160) — für die klinische Governance von Gesundheits-IT (siehe auch Thema 1.6).
• Institute of Internal Auditors (IIA), The IIA's Three Lines Model (Aktualisierung 2020) — die maßgebliche Darstellung des Drei-Linien-Ansatzes.
• HM Treasury, The Orange Book: Management of Risk — Principles and Concepts — Risikobereitschaft, Kontrollen und Assurance in britischen öffentlichen Stellen.
• NHS England / ehemaliger Government Digital Service, Service Standard und Leitlinien zu Service-Assessments — Assurance öffentlich zugänglicher digitaler Dienste.
• UK Corporate Governance Code — Financial Reporting Council — Vorstandsrechenschaft und interne Kontrolle.

Referenzen#

1. Governance — Wikipedia — https://en.wikipedia.org/wiki/Governance
2. Corporate governance — Wikipedia — https://en.wikipedia.org/wiki/Corporate_governance
3. Clinical governance — Wikipedia — https://en.wikipedia.org/wiki/Clinical_governance
4. Information governance — Wikipedia — https://en.wikipedia.org/wiki/Information_governance
5. Senior responsible owner (Executive sponsor) — Wikipedia — https://en.wikipedia.org/wiki/Senior_responsible_owner
6. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
7. Assurance services — Wikipedia — https://en.wikipedia.org/wiki/Assurance_services
8. Internal audit (Three Lines model) — Wikipedia — https://en.wikipedia.org/wiki/Internal_audit
9. Risk appetite — Wikipedia — https://en.wikipedia.org/wiki/Risk_appetite
10. Risk register — Wikipedia — https://en.wikipedia.org/wiki/Risk_register
11. Phase-gate process — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
12. Infrastructure and Projects Authority — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_and_Projects_Authority
13. The IIA's Three Lines Model — Institute of Internal Auditors — https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/
14. The Orange Book: Management of Risk — Principles and Concepts — HM Treasury — https://www.gov.uk/government/publications/orange-book
15. Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems (DCB0160) — NHS England — https://digital.nhs.uk/services/clinical-safety
16. Service Standard — Government Digital Service / GOV.UK — https://www.gov.uk/service-manual/service-standard
17. The UK Corporate Governance Code — Financial Reporting Council — https://www.frc.org.uk/library/standards-codes-policy/corporate-governance/uk-corporate-governance-code/
18. Enterprise risk management — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_risk_management