Thema 3.5 — Lieferlebenszyklen

In einem Satz: Ein Lieferlebenszyklus ist die Abfolge von Phasen und Entscheidungstoren – Discovery, Alpha, Beta, Live und schließlich Außerbetriebnahme –, durch die sich ein digitaler Service bewegt, mit klinischer Sicherheit, Informationsgovernance und Assurance in jede Phase eingewoben statt am Ende angeflanscht.

Warum das in Gesundheit und Pflege wichtig ist#

Ein Lebenszyklus ist die Art, wie eine Organisation eine Idee in einen sicheren Live-Service verwandelt und ihn schließlich verantwortungsvoll außer Betrieb nimmt. In Gesundheit und Pflege trägt jeder Übergang gesetzliches und klinisches Gewicht: Sie können kein System einsetzen, das die Patientenversorgung berührt, ohne Safety Case, und Sie können keine vertraulichen Patientendaten ohne Rechtsgrundlage und abgeschlossene Datenschutz-Folgenabschätzung (DPIA) verarbeiten. Ein Lebenszyklus, der diese als Papierkram am Projektende behandelt, erzeugt Services, die spät, unsicher oder beides sind.

Der Einsatz ist asymmetrisch. Eine Konsumenten-App, die einen Fehler ausliefert, ärgert Nutzende; eine gemeinsame Patientenakte, die einen Fehler ausliefert, kann einem Kliniker die Allergien der falschen Patientin zeigen. Deshalb bettet der NHS das GOV.UK-Phasenmodell und die Standards des klinischen Risikomanagements DCB0129 und DCB0160 in denselben Lebenszyklus ein. Den Lebenszyklus richtig zu gestalten ist keine Governance-Nettigkeit – es ist der Mechanismus, durch den Sicherheit, Gerechtigkeit und Wert für öffentliches Geld tatsächlich geliefert statt bloß versprochen werden.

Führungskräfte brauchen den Lebenszyklus auch, weil er Fortschritt lesbar macht. Benannte Phasen und Tore lassen einen Vorstand sehen, wo ein Service steht, welche Evidenz existiert und welche Entscheidung ansteht – und ersetzen den Nebel von „es ist fast fertig“ durch eine vertretbare, gestufte Zusage öffentlicher Gelder.

Kernkonzepte#

Das Phasenmodell: Discovery → Alpha → Beta → Live. Die Servicestandards von NHS und GOV.UK definieren vier Phasen. Discovery (siehe Thema 3.4 — Discovery-Phasen) versteht das Problem. Alpha baut Wegwerf-Prototypen, um zu testen, ob eine Lösung funktionieren könnte, und die riskantesten Annahmen abzubauen. Beta baut den echten, erst privaten, dann öffentlichen Service auf Produktionsinfrastruktur und iteriert mit echten Nutzenden in wachsendem Maßstab. Live betreibt den Service im Dauerbetrieb, weiter iterierend, bis er außer Betrieb genommen wird. Die Phasen sind eine Rampe zur Risikominderung: Jede bindet mehr Geld und setzt mehr Nutzende aus, gerechtfertigt durch Evidenz der vorherigen.

Kontinuierliche Iteration, kein Fließband. Die Phasen sind kein Wasserfall in eine Richtung. Ein Service in der Beta kann für eine schwierige Funktion zur Alpha zurückschleifen; ein Live-Service iteriert kontinuierlich. Der Wert des Modells sind seine Tore, nicht ein Versprechen, dass Arbeit in eine Richtung fließt.

Agil, Wasserfall und Hybrid. Der Wasserfall legt den Umfang im Voraus fest und schreitet der Reihe nach fort – nur geeignet, wo Anforderungen wirklich stabil und erkennbar sind (eine Rechenzentrumsmigration, eine angeordnete regulatorische Änderung). Agil liefert in kleinen Inkrementen, prüft und passt an – geeignet für die Unsicherheit nutzerorientierter Services. Hybrid ist die ehrliche Realität der meisten großen Gesundheitsprogramme: agile Produktteams, die innerhalb eines Meilenstein- und Finanzierungsrahmens arbeiten, den die Organisation und ihre Aufsichten verlangen. Stimmen Sie die Methode auf die Unsicherheit ab, nicht auf die Mode.

Service-Assessments und Standard-Tore. An den Übergängen zwischen Phasen – besonders von Alpha zu Beta und vor dem öffentlichen Start – stehen NHS- und GOV.UK-Services einem Service-Assessment gegenüber: einem unabhängigen Gremium, das die Arbeit an den Punkten des Service Standard prüft (Nutzerbedürfnis, Barrierefreiheit, Sicherheit, Zuverlässigkeit, Team, Technologiewahl). Das Bestehen ist das Tor zu mehr Ausgaben und mehr ausgesetzten Nutzenden. Das Assessment ist evidenzbasierte Peer-Review, kein Gummistempel.

Klinische Sicherheit und Informationsgovernance als Fäden im Lebenszyklus. DCB0129 (für den Hersteller/Lieferanten) und DCB0160 (für die einsetzende Gesundheits- oder Pflegeorganisation) verlangen ein klinisches Risikomanagementsystem, ein Gefährdungsprotokoll (Hazard Log) und einen Bericht zum klinischen Safety Case, freigegeben von einem benannten, geschulten Clinical Safety Officer (CSO). Informationsgovernance verlangt eine Rechtsgrundlage, eine DPIA und die Einhaltung der Caldicott-Prinzipien. Beides sind Fäden, die durch Discovery, Alpha, Beta und Live laufen – keine Tore am Ende.

Außerbetriebnahme. Ein Lebenszyklus hat ein Ende. Einen Service sicher außer Betrieb zu nehmen – Daten nach Aufbewahrungsrecht migrieren oder archivieren, Nutzende umleiten, Klinikpersonal benachrichtigen und Akten bewahren – ist eine eigene Phase und eine der am meisten vernachlässigten.

Bewährte Praktiken#

1. Nutzen Sie die Phasen als Tore zur Risikominderung, nicht als Kalendermeilensteine. Lassen Sie die Entscheidung jeder Phase lauten: „Gibt es genug Evidenz, um die nächste Tranche an Geld und Nutzenden zu rechtfertigen?“ Eine Phase, die endet, weil der Termin kam, statt weil die Evidenz vorliegt, hat den Sinn des Tors übersprungen.

2. Weben Sie klinische Sicherheit ab der Alpha ein, nicht erst vor Live. Ernennen Sie einen Clinical Safety Officer und eröffnen Sie das Gefährdungsprotokoll, sobald eine Lösungsgestalt existiert. In der Alpha erkannte Gefährdungen sind billig wegzudesignen; beim Go-live gefundene sind eine startblockierende Krise. Der Safety Case reift zusammen mit dem Service, sodass die Freigabe nach DCB0129/0160 eine Zusammenfassung bereits geleisteter Arbeit ist, keine Hektik.

3. Beginnen Sie die DPIA und IG-Arbeit in der Discovery und halten Sie sie lebendig. Datenflüsse, Rechtsgrundlage und Caldicott-Erwägungen prägen die Architektur; bringen Sie sie also ans Licht, solange die Architektur noch weich ist. Eine nach dem Bau geschriebene DPIA ist eine Dokumentationsübung; eine, die neben dem Design entsteht, senkt tatsächlich Risiko und verhindert Nacharbeit.

4. Automatisieren Sie den Weg in die Produktion mit CI/CD und DevOps. Continuous Integration und Continuous Delivery – automatisierte Build-, Test- und Bereitstellungspipelines – lassen ein Team kleine, umkehrbare Änderungen sicher und oft ausliefern. In einem sicherheitskritischen Bereich ist die Fähigkeit, eine Korrektur in Minuten auszurollen und sauber zurückzunehmen, selbst eine Sicherheitskontrolle. Koppeln Sie sie mit Überwachung, Alarmierung und Infrastructure as Code, damit der Live-Service beobachtbar und reproduzierbar ist.

5. Stimmen Sie die Methode auf die Unsicherheit ab. Nutzen Sie agil, wo Nutzerbedürfnisse ungewiss sind und die Discovery Sie noch Dinge lehrt; akzeptieren Sie wasserfallartige Sequenzierung nur, wo Anforderungen wirklich fest sind und das Risiko der Änderung gering ist. Seien Sie ausdrücklich, dass Sie einen Hybrid betreiben – agile Teams innerhalb eines Programmrahmens –, statt vorzugeben, eine Methode regiere alles, was niemanden täuscht und alle frustriert.

6. Behandeln Sie das Service-Assessment als Designwerkzeug, nicht als Prüfung. Holen Sie Prüfende für Assurance, klinische Sicherheit, Sicherheit und Barrierefreiheit früh und oft hinzu, damit das formale Assessment einen bereits nach Standard gebauten Service bestätigt. Teams, die den Standard erst in der Woche vor dem Assessment kennenlernen, scheitern langsam und teuer; Teams, die ihn verinnerlichen, bestehen als Nebenprodukt.

7. Iterieren Sie weiter in Live – und statten Sie es aus. Ein Service hört nicht auf, ein Team zu brauchen, wenn er live geht. Live ist, wo reale Nutzung die letzten Ungerechtigkeiten, die seltenen, aber ernsten klinischen Randfälle und die Barrierefreiheitslücken offenlegt. Finanzieren Sie ein ständiges Produktteam für die Betriebslebensdauer des Services (siehe Thema 5.0 — Produktgeführte Arbeit); ein Live-Service ohne Team ist technische Schuld, die klinisches Risiko ansammelt.

8. Planen Sie die Außerbetriebnahme, bevor Sie sie brauchen. Entscheiden Sie beim Bau, wie der Service dereinst außer Betrieb genommen wird: Datenaufbewahrung und -migration nach Aktenmanagementrecht, Umleitung der Nutzenden, Benachrichtigung des Klinikpersonals und Archivierung von Safety Case und Prüfspur. Eine ungeplante Stilllegung lässt Daten und Nutzende gestrandet zurück; eine geplante ist eine kontrollierte, prüfbare Phase.

Fragen zur Diskussion im Team#

1. Werden unsere Phasentore wirklich von Evidenz gesteuert, oder sind sie still zu Terminen in einem Plan geworden? Der ganze Wert des Modells Discovery–Alpha–Beta–Live liegt darin, dass jeder Übergang nur dann mehr Geld bindet und mehr Nutzende aussetzt, wenn die Evidenz der vorherigen Phase es rechtfertigt; sobald ein Tor feuert, weil das Quartal endete statt weil die Evidenz vorliegt, senkt die Rampe kein Risiko mehr und wird zum „Wasserfall im agilen Kostüm“. Diese Frage bittet ein Team, auf seine letzten Übergänge ehrlich zu blicken und zu fragen, was geschehen wäre, hätte die Evidenz „noch nicht“ gesagt – gab es Raum zu halten, eine Beta für eine schwierige Funktion zur Alpha zurückzuschleifen, oder war der Go-live-Termin politisch unverrückbar? Die zu debattierende Spannung liegt zwischen dem Bedürfnis der Organisation nach lesbaren, gremiengeplanten Meilensteinen und der Realität, dass sichere Services im Tempo der Evidenz laufen; hybride Lieferung lebt genau in dieser Reibung. Konkrete Ansätze umfassen, die konkrete Entscheidung und die Evidenz zu benennen, die am nächsten Tor fällig sind, zu prüfen, ob „Sprints“ den Umfang tatsächlich ändern oder nur einem festen Plan folgen, und zu fragen, wer ohne Karriererisiko befugt ist, ein Tor zu verzögern. Eine gute Antwort kann auf einen realen Fall verweisen, in dem Evidenz den Plan veränderte, und artikulieren, welche Evidenz die nächste Zusage öffentlicher Gelder und Nutzender rechtfertigen – oder blockieren – würde.

2. Sind klinische Sicherheit und Informationsgovernance lebendige Fäden durch jede Phase, oder Papierkram, den wir vor Live abschließen wollen? In Gesundheit und Pflege sind die DPIA und die Arbeit zum klinischen Risiko nach DCB0129/0160 keine Freigaben am Projektende, sondern Fäden, die Architektur und Design ab der Alpha prägen müssen, denn eine früh weggedesignte Gefährdung ist billig, während eine beim Go-live entdeckte eine startblockierende Krise ist – oder schlimmer, ein Druck, den Safety Case durchzuwinken. Diese Frage bringt ans Licht, ob ein benannter, geschulter Clinical Safety Officer und ein offenes Gefährdungsprotokoll existieren, sobald eine Lösungsgestalt erscheint, und ob die DPIA und die Analyse der Rechtsgrundlage in der Discovery begannen, als die Datenflüsse noch weich genug zum Ändern waren. Der zu debattierende Zielkonflikt ist die gefühlte Bremse, dies kontinuierlich zu tun, gegenüber den weit größeren Kosten und dem klinischen Risiko einer Nachrüstung, besonders bei kleineren Teams oder Startups, bei denen noch keine Aufsicht zusieht, die DCB0129-Pflicht den Hersteller aber unabhängig davon trifft. Überlegen Sie konkrete Evidenz: Zeigt das Gefährdungsprotokoll in der Alpha gefundene und gemilderte Gefährdungen, liest sich der Safety Case wie eine Zusammenfassung bereits geleisteter Arbeit, und führt die DPIA auf reale Designentscheidungen zurück? Eine ehrliche Antwort unterscheidet ein Team, das seinen Safety Case zusammen mit dem Service reifen lässt, von einem, das auf eine Dokumentationshektik im Monat vor dem Start zusteuert.

3. Wie wird dieser Service in Live betrieben und schließlich außer Betrieb genommen – und wer ist dafür finanziert? Lebenszyklen haben einen langen Schwanz, den Organisationen routinemäßig unterfinanzieren: Live ist, wo reale Nutzung die letzten Ungerechtigkeiten, seltene, aber ernste klinische Randfälle und Barrierefreiheitslücken offenlegt, und es braucht ein ständiges Produktteam, Überwachung und schnelle, umkehrbare Bereitstellung statt eines Teams, das sich beim Go-live auflöst und den Service verrotten und still klinisches Risiko ansammeln lässt. Ebenso vernachlässigt ist die Außerbetriebnahme – einen Service nach Aufbewahrungsrecht stilllegen, Daten migrieren oder archivieren, Nutzende umleiten, Klinikpersonal benachrichtigen und Gefährdungsprotokoll sowie Prüfspur bewahren –, die für ein nationales System ein großes Programm eigenen Rechts ist, kein Nachgedanke, wenn der Ersatz eintrifft. Die zu debattierende Spannung sind jährliche Finanzierungszyklen und der Druck, ein Projekt beim Start für „fertig“ zu erklären, gegenüber der Verantwortung über die gesamte Lebensdauer, die ein sicherer Service tatsächlich verlangt. Nützliche Ansätze umfassen, ob eine CI/CD-Pipeline mit Überwachung und schnellem Rollback als Live-Sicherheitskontrolle behandelt wird, ob ein Bereitschafts- und Iterationsbudget die Go-live-Feier überlebt und ob ein Ausstiegsplan beim Bauen geschrieben statt in Panik improvisiert wurde. Eine gute Antwort benennt, wer den Service über seine Betriebslebensdauer verantwortet, und beschreibt eine kontrollierte, prüfbare Stilllegung statt der Hoffnung, dass sich jemand später darum kümmert.

4. Wann haben wir zuletzt das Scheitern eines Prototyps uns stoppen lassen – und bauen wir noch Dinge zum Wegwerfen? Die Alpha existiert, um die riskantesten Annahmen billig abzubauen, was bedeutet, dass ein gescheiterter Wegwerf-Prototyp seine Aufgabe erfüllt hat: Er hat eine kostspielige Lehre erkauft, bevor Produktionsgeld und echte Patientinnen und Patienten gebunden wurden. Diese Frage prüft, ob ein Team die Alpha wirklich als Wegwerf-Lernen behandelt oder still dazu übergegangen ist, seinen ersten Prototyp zum späteren Produkt zu polieren, weil das Verwerfen von Code verschwenderisch wirkt – die Falle versunkener Kosten, die eine Phase der Risikominderung in eine teure, blind eingegangene Verpflichtung verwandelt. Die aufzudeckende Spannung ist der Druck, „etwas zum Zeigen zu haben“ und jede geschriebene Zeile wiederzuverwenden, gegenüber der Disziplin, zu beweisen, dass eine Lösung funktionieren könnte, bevor man die echte auf Produktionsinfrastruktur baut. Konkrete Ansätze umfassen zu fragen, welche Annahmen die letzte Alpha tatsächlich testete, ob je ein Prototyp aufgrund der Evidenz aufgegeben wurde und ob der Build der privaten Beta Wegwerf-Code wiederverwendete, der nach Produktionsstandard neu hätte geschrieben werden müssen. Eine ehrliche Antwort kann auf eine bestimmte Annahme verweisen, die ein Prototyp tötete oder bestätigte, und Lernartefakte, die das Team zu verwerfen bereit war, von dem abgesicherten Code unterscheiden, den es nun in Live betreibt.

5. Betreiben wir einen ehrlichen Hybrid, oder mehrere getarnte Methoden, die einander still widersprechen? Die meisten großen Gesundheitsprogramme sind wirklich hybrid – agile Produktteams, die innerhalb eines Meilenstein- und Finanzierungsrahmens arbeiten, den die Organisation und ihre Aufsichten verlangen –, und das Versagen ist nicht der Hybrid selbst, sondern vorzugeben, er sei reines Agil oder reiner Wasserfall, sodass die beiden Logiken an jedem Tor ungesteuert kollidieren. Diese Frage bittet ein Team zu benennen, wo die festen, sequenzierten Zusagen tatsächlich sitzen (Finanzierungstranchen, regulatorische Meilensteine, Integrations-Freezes) und wo die echte Iteration stattfindet, statt „agil“ und „den Plan“ je das ganze Programm beanspruchen und alle frustrieren zu lassen. Der zu debattierende Zielkonflikt ist das legitime Bedürfnis der Organisation nach vorhersehbaren Meilensteinen und prüfbaren Ausgaben gegenüber dem Bedürfnis des Lieferteams, den Umfang anhand von Evidenz zu ändern; der ehrliche Zug ist, die Nähte explizit zu machen, sodass beides eingeplant werden kann. Nützliche Ansätze umfassen, ob die Neupriorisierung des Backlogs den Kontakt mit dem Programmplan je überlebt, ob Lieferanten für festen Umfang beauftragt, aber zu iterativem Arbeiten aufgefordert werden und ob die Berichterstattung, die ein Vorstand sieht, dazu passt, wie die Arbeit wirklich getan wird. Eine gute Antwort beschreibt einen bewusst gestalteten Hybrid mit benannten Fixpunkten und benannten flexiblen Räumen, kein Durcheinander, in dem Methode zum Schein beansprucht wird.

6. Wie gut wissen wir, was ein Live-Service gerade tatsächlich mit seinen Nutzenden macht – und würden wir Schaden bemerken, bevor sie ihn meldeten? Ein Live-Gesundheitsservice ist nur so sicher wie seine Beobachtbarkeit: Überwachung, Alarmierung und die Instinkte der klinischen Sicherheit, die eine Kennzahl in eine Gefährdung verwandeln, machen den Unterschied, ob man einen Mangel bei veralteten Daten in Minuten abfängt oder Wochen später aus einem Vorfallbericht erfährt. Diese Frage prüft, ob das Team den Service in der Produktion sehen kann – Fehlerraten, Integrationsausfälle, Barrierefreiheits-Abbrüche, die Gerechtigkeitslücken, die nur reale Nutzung offenbart – und ob jemand die Dashboards mit klinischem Risiko im Blick beobachtet, nicht nur die Infrastrukturverfügbarkeit. Die Spannung sind Kosten und Disziplin ordentlicher Beobachtbarkeit und Bereitschaft gegenüber der stillen Annahme „keine Nachricht ist eine gute Nachricht“, sobald ein Service live ist, was in einem sicherheitskritischen Bereich der Weg ist, auf dem stiller Schaden sich ansammelt. Konkrete Ansätze umfassen, ob das Gefährdungsprotokoll aus Live-Vorfällen aktualisiert wird, ob Alarme auf klinische Auswirkungen statt nur auf Serverzustand abgebildet sind und ob ein schlechter Release erkannt und zurückgenommen werden kann, bevor er viele Patientinnen und Patienten erreicht. Eine ehrliche Antwort beschreibt konkrete Signale, die das Team beobachtet, einen realen Vorfall, den die Überwachung fing (oder verpasste), und wie Live-Evidenz in die nächste Iteration zurückfließt.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein NHS-Gemeinde-Trust ersetzt ein Altsystem aus Papier und Tabellenkalkulation für die Besuchsplanung der Gemeindekrankenschwestern. Aus der Discovery (Thema 3.4) kommend, tritt das Team in die Alpha ein und baut zwei Wegwerf-Prototypen, um die riskantesten Annahmen zu testen: dass Pflegekräfte ein Telefon in den Wohnungen der Patientinnen und Patienten nutzen werden und dass sich der Plan in die elektronische Patientenakte integrieren lässt. Ein Clinical Safety Officer wird am ersten Tag der Alpha ernannt und eröffnet ein Gefährdungsprotokoll; eine frühe Gefährdung – ein veralteter Plan, der einen bereits von einer Kollegin erledigten Besuch zeigt – treibt eine Designentscheidung, den Echtzeit-Synchronisierungsstatus anzuzeigen. Die in der Discovery begonnene DPIA markiert, dass Standortdaten von Alleinarbeitenden eine definierte Rechtsgrundlage und Aufbewahrungsgrenze brauchen.

Beim Service-Assessment von Alpha zu Beta prüft ein unabhängiges Gremium Barrierefreiheit (Pflegekräfte mit Sehbeeinträchtigungen), Sicherheit und die Begründungen des Teams. Der Service besteht mit Maßnahmen. In der privaten Beta nutzen zehn Pflegekräfte das echte System auf Produktionsinfrastruktur; eine CI/CD-Pipeline lässt das Team täglich ausliefern und einen schlechten Release in unter zehn Minuten zurücknehmen. Die Nutzung offenbart ein Gerechtigkeitsproblem – Zeitarbeitskräfte ohne Trust-Geräte –, das zu einem browserbasierten Rückfall führt. Die öffentliche Beta skaliert auf drei Ortsteile; der Bericht zum klinischen Safety Case wird abgeschlossen und vor dem breiteren Rollout nach DCB0160 freigegeben.

Der Service geht Live mit einem ständigen Produktteam, Überwachungs-Dashboards und einem Bereitschaftsplan. Achtzehn Monate später, als der Trust eine regionale Plattform übernimmt, wird der Plan planmäßig außer Betrieb genommen: Daten nach dem Aufbewahrungsplan migriert, Pflegekräfte umgeschult und umgeleitet, Gefährdungsprotokoll und Safety Case für die Prüfung archiviert. Jeder Übergang war eine durch Evidenz gestützte Entscheidung, kein Termin in einem Gantt-Diagramm.

Sektorperspektiven#

Startup#

Der Lebenszyklus eines Startups ist verdichtet und weitgehend selbst gesteuert: Es gibt kein unabhängiges Service-Assessment-Gremium, sodass die Disziplin der Tore Alpha–Beta–Live selbst auferlegt sein muss, oder sie kollabiert zu „kontinuierlich ausliefern und hoffen“. Der Vorteil ist, dass ein kleines Team von Tag eins an echtes CI/CD betreiben und schneller iterieren kann als jede große Stelle. Die Gefahr ist, die Fäden der klinischen Sicherheit und der DPIA still fallen zu lassen, weil noch keine Aufsicht zusieht – ein fataler Fehler in der Gesundheit, wo DCB0129-Pflichten den Hersteller unabhängig von der Unternehmensgröße treffen und eine unbeherrschte Gefährdung sowohl das Produkt als auch das Unternehmen beenden kann. Startups sollten die Absicht des Phasenmodells – Evidenz vor Exposition – auch ohne Zeremonie übernehmen und, sobald eine Lösungsgestalt existiert, einen Clinical Safety Officer (oft anteilig) ernennen.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik – begegnet dem Lebenszyklus meist als Einsetzender statt als Bauender: Er beschafft oder konfiguriert das System eines Lieferanten, sodass die DCB0160-Einsatzfreigabe und eine lokale DPIA ihm zufallen, auch ohne eigenes Digitalteam. Die Phasen gelten weiterhin, aber verdichtet und ausgelagert: „Alpha“ ist ein beaufsichtigter Pilot an einigen echten Patientinnen und Patienten, „Beta“ ein gestufter Rollout über die Praxis, und Live ist Regelbetrieb, in dem die Updates des Lieferanten kontinuierlich und weitgehend außerhalb der Kontrolle der Praxis eintreffen. Die Organisation muss einen Clinical Safety Officer benennen (oft eine klinische Partnerin, die die Rolle zusätzlich zu einem Alltagsjob übernimmt) und ein Gefährdungsprotokoll dafür führen, wie das System lokal genutzt wird, denn die DCB0129-Arbeit des Herstellers deckt die spezifischen Risiken des Einsatzes nicht ab. Bei knappem Geld und ohne eigene IT ist die realistische Disziplin, sich auf die Absicherung des Lieferanten zu stützen und dabei die wenigen Entscheidungen zu verantworten, die nur lokales Wissen treffen kann – wer geschult wird, was der Rückfall ist, wenn das System ausfällt, und wie Patientendaten in diesem konkreten Umfeld fließen.

Großunternehmen#

Ein NHS Trust oder großer Lieferant betreibt den Lebenszyklus in seiner vollständigsten, am stärksten abgesicherten Form: formale Service-Assessments, ein benannter Clinical Safety Officer, DCB0160-Einsatzfreigabe, Change Advisory Boards und ein jährlicher Finanzierungszyklus, in den die agile Arbeit passen muss. Die charakteristische Herausforderung ist der Hybrid – agile Lieferteams, die innerhalb eines Programm- und Meilensteinrahmens arbeiten, den die Organisation und ihre Prüfenden verlangen – und das klassische Versagen ist „Wasserfall im agilen Kostüm“, wo Tore still zu Kalenderterminen werden. Großunternehmen haben die Ressourcen, CI/CD, Beobachtbarkeit und ständige Produktteams ordentlich zu betreiben, doch organisatorische Trägheit und Altintegration bremsen die Bereitstellung oft auf Kriechtempo. Die Rechenschaft ist breit und der Wirkungsradius groß; die gestufte Rampe von der privaten Beta zu Live ist daher keine optionale Klugheit, sondern wesentliche Risikokontrolle.

Regierung#

Eine nationale Stelle liefert unter dem vollen Service Standard, veröffentlichten Service-Assessments, Ausgabenkontrollen und parlamentarischer Kontrolle, sodass jedes Phasentor zugleich ein Punkt öffentlicher Rechenschaft ist. Lebenszyklen sind hier lang und die Exposition riesig – ein Live-Service für den ganzen NHS kann Millionen berühren –, was den Einsatz bei der gestuften Rampe, der Absicherung der klinischen Sicherheit und der Außerbetriebnahme der Altsysteme erhöht, die ersetzt werden. Beschaffungsregeln und mehrjährige Finanzierungsvereinbarungen prägen, was „agil“ in der Praxis bedeuten kann, und die Stilllegung eines nationalen Systems (mit seinen Jahrzehnten an Akten und gesetzlichen Aufbewahrungspflichten) ist ein großes Programm eigenen Rechts. Der Zielkonflikt ist Assurance versus Geschwindigkeit: Lieferung der Regierung ist stark getort, was Sicherheit und öffentliches Geld schützt, aber bewusste Anstrengung verlangt, Teams am Iterieren zu halten, statt in Big-Design-Up-Front zurückzufallen.

Häufige Fehlermuster#

• Wasserfall im agilen Kostüm. Das Team fährt „Sprints“, doch Umfang, Termine und Design wurden alle im Voraus festgelegt; Iteration ist Theater. Gegenmittel: Evidenz an jedem Tor den Plan wirklich verändern lassen.
• Sicherheit und IG am Ende angeflanscht. Safety Case und DPIA werden im Monat vor dem Go-live geschrieben, blockieren den Start oder werden, schlimmer, unter Druck durchgewinkt. Gegenmittel: Gefährdungsprotokoll und DPIA in der Alpha eröffnen und kontinuierlich reifen lassen.
• Der Big-Bang-Start. Der Service überspringt private/öffentliche Beta und geht direkt in den vollen Rollout und setzt jeden Nutzenden unbewiesener Software aus. Gegenmittel: die gestufte Rampe nutzen; Exposition mit Evidenz wachsen lassen.
• Der aufgegebene Live-Service. Das Lieferteam löst sich beim Go-live auf; der Service verrottet, und klinisches Risiko sammelt sich still an. Gegenmittel: ein ständiges Produktteam für die Betriebslebensdauer finanzieren.
• Assessment-Büffeln. Standards werden ignoriert, bis das Assessment naht, dann oberflächlich erfüllt. Gegenmittel: Assurance- und klinische Prüfende kontinuierlich einbeziehen.
• Kein Ausstiegsplan. Der Service wird in Panik stillgelegt, wenn sein Ersatz eintrifft, und lässt Daten und Nutzende gestrandet zurück. Gegenmittel: Außerbetriebnahme als erstklassige Phase planen.

Reifegradmodell#

Checkliste#

• Der Service hat eine explizite aktuelle Phase (Discovery / Alpha / Beta / Live) und eine benannte nächste Entscheidung.
• Phasenübergänge sind an Evidenz gebunden, nicht an Termine.
• Ein Clinical Safety Officer ist ernannt und ein Gefährdungsprotokoll ist ab der Alpha offen (DCB0129/0160).
• Eine DPIA und Bewertung der Rechtsgrundlage (Caldicott, UK GDPR) begannen in der Discovery und werden aktuell gehalten.
• Die Liefermethode ist auf das Maß an Unsicherheit abgestimmt, und jede Hybrid-Vereinbarung ist explizit.
• Service-Assessments sind geplant, und Prüfende für Assurance/Sicherheit/Barrierefreiheit sind früh eingebunden.
• Eine CI/CD-Pipeline mit Überwachung und schnellem Rollback besteht vor der öffentlichen Beta.
• Der Service wird Nutzenden in einer gestuften Rampe ausgesetzt (private Beta → öffentliche Beta → Live), nicht im Big Bang.
• Ein ständiges Produktteam ist für die Betriebslebensdauer des Services finanziert (siehe Thema 5.0).
• Ein Plan zur Außerbetriebnahme deckt Datenaufbewahrung/-migration, Umleitung der Nutzenden und Archivierung von Sicherheits- und Prüfakten ab.

Zentrale Quellen#

• GOV.UK Service Manual — die Phasen eines agilen Projekts (Discovery, Alpha, Beta, Live) und der Government Service Standard.
• NHS England — NHS Service Standard und NHS Digital Service Manual; NHS-Service-Assessments.
• NHS England Digital — DCB0129 (Clinical Risk Management: its Application in the Manufacture of Health IT Systems) und DCB0160 (its Application in the Deployment and Use of Health IT Systems).
• NHS England — Absicherung der digitalen klinischen Sicherheit; die Rolle des Clinical Safety Officer, Gefährdungsprotokoll und Bericht zum klinischen Safety Case.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• Die britischen Caldicott-Prinzipien; Data Protection Act 2018 / UK GDPR und Datenschutz-Folgenabschätzungen.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• Praxis von DevOps und Continuous Delivery (z. B. die DORA-Fähigkeiten: Continuous Integration, Bereitstellungsautomatisierung, Überwachung); Leitlinien des GOV.UK Service Manual zu Continuous Delivery und zum Betrieb eines Services.

Referenzen#

1. Systems development life cycle — Wikipedia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health