Thema 1.0 — Arbeitsweisen in der digitalen Gesundheit und Pflege

In einem Satz: Arbeitsweisen sind die bewusst gewählten, gemeinsamen Gewohnheiten – wie Sie Teams organisieren, Entscheidungen treffen, Risiken steuern und Wert liefern –, die es einer Organisation der Gesundheit und Pflege ermöglichen, Absichten in sichere, gerechte, evidenzbasierte Ergebnisse für Patientinnen, Patienten und Bürgerinnen und Bürger zu verwandeln.

Warum das in Gesundheit und Pflege wichtig ist#

Jede Organisation hat Arbeitsweisen, ob gewählt oder geerbt. In der digitalen Gesundheit und Pflege sind die geerbten meist falsch für die Aufgabe: Sie wurden für Projekte im Stil des Bauwesens mit festem Umfang gebaut, nicht für adaptive Services, die klinische Sicherheit, gesetzliche Pflichten und öffentliche Gelder berühren. Sie richtig aufzusetzen ist keine Nettigkeit für das Backoffice; es ist der Unterschied zwischen einer gemeinsamen Patientenakte, der Klinikerinnen und Kliniker vertrauen, und einer, die ungenutzt bleibt.

Gesundheit und Pflege sind in einer Weise besonders, die jede Praxis in diesem Buch prägt. Sicherheit ist nicht verhandelbar – ein Fehler in einem digitalen Service kann Patientinnen und Patienten schaden, weshalb das klinische Risikomanagement (siehe Thema 1.6 — Klinische Sicherheit und Risikomanagement) die gesamte Lieferung durchzieht und nicht nachträglich aufgesetzt wird. Gerechtigkeit zählt, weil ein Service, der nur für digital Versierte funktioniert, gesundheitliche Ungleichheiten vergrößert; die Core20PLUS5-Bevölkerungsgruppen und Menschen mit eingeschränktem digitalem Zugang müssen mitgedacht werden, statt wegdesignt zu werden. Gesetzliche Pflichten – die Verpflichtung des NHS zu umfassender Versorgung, das Datenschutzrecht, die Schweigepflicht – begrenzen, was Sie mit Daten tun dürfen und wie Sie konsultieren müssen. Öffentliche Gelder verlangen verhältnismäßige Ausgabenkontrolle und nachweisbaren Nutzen. Und fast nichts wird von einer Stelle allein geliefert: Partnerschaft über Integrated Care Systems (ICS), Kommunalverwaltungen, Anbieter der Sozialfürsorge und Lieferanten hinweg ist der Normalzustand.

Diese vier Kräfte – Sicherheit, Gerechtigkeit, Pflicht, Geld – sind der Grund, warum Sie nicht einfach ein Regelwerk der Konsumententechnologie kopieren können. Sie brauchen Arbeitsweisen, die agil und rechenschaftspflichtig, schnell und sicher, nutzerzentriert und bevölkerungsgerecht sind.

Kernkonzepte#

Arbeitsweisen wirken auf drei Ebenen. Auf der Teamebene sind es die täglichen Praktiken: Stand-ups, Nutzerforschung, iterative Lieferung, Pairing. Auf der Organisationsebene ist es das Betriebsmodell – wie Strategie zu Wertströmen, Fähigkeiten, Finanzierung und Entscheidungsrechten wird (siehe Thema 1.1 — Das Betriebsmodell). Auf der Systemebene ist es die Art, wie unabhängige Organisationen sich aufeinander abstimmen: gemeinsame Standards, Interoperabilität und gemeinsame Governance über ein ICS hinweg. Dieses Buch bewegt sich bewusst über alle drei Ebenen.

Nutzerzentriertes Design bedeutet, von den Bedürfnissen der Menschen auszugehen, die einen Service nutzen – Patientinnen und Patienten, Angehörige, Klinikpersonal, Verwaltungskräfte –, statt von einer angenommenen Lösung. Der britische Government Digital Service (GDS) und der NHS haben dies in Servicestandards festgeschrieben: Verstehen Sie die Nutzenden und ihre Bedürfnisse, bevor Sie bauen, und testen Sie fortlaufend mit echten Nutzenden.

Agile, iterative Lieferung bedeutet, früh einen funktionierenden Service vor echte Nutzende zu bringen, zu lernen und sich anzupassen – statt alles im Voraus zu spezifizieren. Das NHS Digital Service Manual stellt klar, dass agile, nutzerzentrierte Arbeitsweisen das Risiko verringern, das Falsche zu bauen. Agilität ist hier ebenso eine Risikomanagementstrategie wie eine Liefermethode.

Multidisziplinäre Teams (MDTs) vereinen in einem befähigten Team die Mischung an Fähigkeiten, die ein Service braucht: Produkt- und Liefermanagement, Nutzerforschung und Design, Softwareentwicklung, klinische und informationsgovernancebezogene Expertise sowie operatives Wissen. Der NHS-Servicestandard verlangt Teams, die multidisziplinäre Fähigkeiten und Perspektiven umfassen – einschließlich des Zugangs zu spezialisiertem klinischem, rechtlichem oder politischem Input. Das MDT ist das Atom der digitalen Lieferung; die meisten Fehlschläge lassen sich auf eine am Tisch fehlende Disziplin zurückführen.

Produkt statt Projekt. Ein Projekt hat einen Anfang, ein Ende und eine Übergabe; ein Produkt wird über seine gesamte Lebensdauer finanziert und betreut. Der Wechsel vom Projekt- zum Produktdenken (siehe Thema 1.1 und Thema 5.0 — Produktgeführte Arbeit) verändert Finanzierung, Teams und Verantwortlichkeit, und er passt zu Gesundheitsleistungen – die langlebig sind und sich ständig weiterentwickeln – weit besser als einmalige Projekte.

Bewährte Praktiken#

1. Beginnen Sie bei den Nutzerbedürfnissen, belegt durch Forschung. Bevor Sie sich auf einen Bau festlegen, verstehen Sie, wer die Nutzenden sind, was sie zu tun versuchen und wo der aktuelle Service sie im Stich lässt. Finanzieren Sie eine Discovery (siehe Thema 3.4 — Discovery-Phasen) und behandeln Sie „wir haben angenommen“ als Warnsignal. Nutzerbedürfnisse, nicht interne Präferenzen, sind der Anker für jede spätere Entscheidung.

2. Bauen Sie multidisziplinäre, befähigte und stabile Teams. Stellen Sie die volle Mischung an Fähigkeiten zusammen – einschließlich klinischer Sicherheit und Informationsgovernance – und geben Sie dem Team die Befugnis, innerhalb klarer Leitplanken zu entscheiden. Halten Sie Teams rund um einen Service zusammen, statt sie an jeder Projektgrenze aufzulösen; stabile Teams sammeln das Fach- und Sicherheitswissen an, das Gesundheitsleistungen verlangen.

3. Arbeiten Sie offen und iterieren Sie in kleinen Schritten. Liefern Sie dünne Scheiben, messen Sie und justieren Sie nach. Kleine, häufige Releases sind sicherer als Big-Bang-Einführungen, weil Probleme auftauchen, solange sie noch klein sind, und weil die Prüfung durch klinische Sicherheit und Informationsgovernance mit dem Wandel Schritt halten kann, statt zu einem Tor am Ende zu werden.

4. Machen Sie Sicherheit und Gerechtigkeit von Tag eins an zu erstklassigen Themen. Führen Sie das klinische Risikomanagement (DCB0129/DCB0160) und die Gleichstellungs- bzw. Gesundheitsungleichheitsanalyse parallel zur Lieferung durch, nicht als Freigaben am Ende. Fragen Sie früh, wer ausgeschlossen oder geschädigt werden könnte, und gestalten Sie für die schwierigsten Fälle – assistierte digitale Wege, Barrierefreiheit (WCAG) und Offline-Rückfalloptionen.

5. Entscheiden Sie mit Evidenz und halten Sie die Entscheidung fest. Unterscheiden Sie klinische Evidenz (wirkt es und ist es sicher?) von Lieferevidenz (bauen wir es gut und wird es genutzt?), und führen Sie ein schlankes Entscheidungsprotokoll, damit die Begründung Personalwechsel überdauert (siehe Thema 1.3 — Evidenzbasierte Entscheidungen). Evidenz schlägt die Meinung der bestbezahlten Person.

6. Gestalten Sie für Interoperabilität und Wiederverwendung. Daten aus Gesundheit und Pflege müssen sicher zwischen Organisationen fließen; bauen Sie auf offenen Standards (HL7 FHIR, SNOMED CT) und verwenden Sie Plattformen wieder, statt sie neu zu erfinden (siehe die „dünnste tragfähige Plattform“ in Thema 1.1 und Thema 4.3 — Interoperabilität und Datenstandards). Ein Service, der keine Daten teilen kann, ist ein Silo, das darauf wartet, ein Risiko zu werden.

7. Steuern Sie verhältnismäßig. Stimmen Sie das Gewicht der Absicherung auf die Höhe des Risikos ab. Klinische Änderungen mit hohem Risiko verdienen tiefgehende Prüfung; inhaltliche Änderungen mit geringem Risiko sollten nicht wochenlang auf ein Gremium warten. Verhältnismäßige Governance hält Sie sicher und schnell zugleich.

8. Arbeiten Sie offen. Teilen Sie Pläne, Entscheidungen, Roadmaps und – wo es sicher ist – Code, damit Partner, Klinikpersonal und Öffentlichkeit sehen können, wie und warum Entscheidungen fallen. Offenheit schafft Vertrauen, verringert Doppelarbeit in einem fragmentierten System und lädt zu Widerspruch ein, bevor sich Fehler in Live-Services verfestigen. In Gesundheit und Pflege ist Transparenz darüber, was ein Service mit Daten tut und warum, selbst eine Vertrauens- und Sicherheitspraxis.

9. Gestalten Sie für die lange Frist und für die Übergabe. Digitale Services im Gesundheitswesen überdauern die Teams und Verträge, die sie bauen; halten Sie deshalb Entscheidungen fest, vermeiden Sie undokumentiertes „Heldenwissen“ und gestalten Sie für die Menschen, die den Service über Jahre betreiben und verändern werden (siehe Thema 10.3 — Wissensmanagement und Dokumentation). Behandeln Sie Nachhaltigkeit – von Team, Technologie und Finanzierungsmodell – als erstklassige Randbedingung, nicht als Nachgedanken.

Fragen zur Diskussion im Team#

1. Wo sind unsere derzeitigen Arbeitsweisen geerbt statt gewählt, und welche geerbte Gewohnheit kostet uns am meisten an Sicherheit, Gerechtigkeit oder verschwendeten Ausgaben? Diese Frage erzwingt eine ehrliche Bestandsaufnahme der Praktiken, die niemand beschlossen hat, denen aber alle folgen – Programmfinanzierung mit festem Umfang, Projektteams, die aufgelöst und neu aufgebaut werden, Governance, die erst beim Go-live einbezogen wird. Sie ist wichtig, weil geerbte Gewohnheiten meist unsichtbar bleiben, bis man sie benennt, und in Gesundheit und Pflege echte Kosten verursachen: eine gemeinsame Akte, der Klinikpersonal nicht vertraut, einen Service, der Core20PLUS5-Bevölkerungsgruppen ausschließt, oder den Neubau derselben Login-Infrastruktur mit öffentlichem Geld. Der Spannungspunkt für die Debatte ist, dass geerbte Arbeitsweisen gerade deshalb sicher wirken, weil sie vertraut und prüfbar sind; sie abzuschaffen sieht daher nach dem Eingehen eines Risikos aus statt nach dem Beseitigen eines Risikos. Verankern Sie die Diskussion in konkreten Artefakten – schauen Sie sich Ihre letzten drei Business Cases an, die Fluktuation Ihrer Teams zwischen Projekten und den Zeitpunkt, zu dem die klinische Sicherheit erstmals einbezogen wurde –, statt Meinungen auszutauschen. Eine gute Antwort benennt ein bis zwei konkrete Gewohnheiten mit Belegen für ihre Kosten, unterscheidet die erhaltenswerten von denen, die Ergebnisse aktiv schädigen, und verpflichtet sich zu einer Änderung, für die eine leitende Person die Verantwortung übernimmt.

2. Verfügen unsere Teams tatsächlich über die volle multidisziplinäre Fähigkeitsmischung – einschließlich klinischer Sicherheit und Informationsgovernance – innerhalb des Teams, oder sind diese Disziplinen weiterhin als Tore am Ende angeflanscht? Das Thema argumentiert, das MDT sei das Atom der digitalen Lieferung und die meisten Fehlschläge gingen auf eine am Tisch fehlende Disziplin zurück; diese Frage prüft daher, ob das Prinzip in Ihrer Organisation real oder nur ein Anspruch ist. Sie ist wichtig, weil ein Clinical Safety Officer oder Caldicott Guardian, der erst beim Go-live einbezogen wird, entweder Nacharbeit oder unsichere Abkürzungen erzwingt, während jemand, der ab Woche eins eingebettet ist, ein lebendiges Gefährdungsprotokoll führt, das die Lieferung taktet. Der Zielkonflikt, den es lohnt anzusprechen, sind Kosten und Knappheit: Spezialisierte klinische, rechtliche und IG-Zeit ist tatsächlich begrenzt, sodass „jeden in jedes Team einbetten“ mit realen Ressourcengrenzen kollidiert und das Team entscheiden muss, wo anteilige oder geteilte Rollen akzeptabel sind und wo nicht. Betrachten Sie einen aktuellen Service und kartieren Sie, wer tatsächlich im ständigen Team sitzt und wer als externe Freigabe konsultiert wird, und prüfen Sie, ob das Team innerhalb von Leitplanken entscheiden darf oder ständig eskalieren muss. Eine ehrliche, gute Antwort ist konkret dazu, welche Disziplinen fehlen oder geliehen sind, räumt die Ressourcenspannung offen ein und schlägt ein konkretes Modell – Vollzeit, anteilig oder auf Abruf – vor, um die Lücke zu schließen, ohne die Knappheit wegzureden.

3. Wann haben wir einen digitalen Service als Projekt mit Übergabe behandelt statt als Produkt, das über seine gesamte Lebensdauer betreut wird, und was hat uns das an verlorenem Fach- und Sicherheitswissen gekostet? Produkt statt Projekt ist eine der tragenden Verschiebungen des Themas, und diese Frage lässt das Team erkennen, wo es noch auf Abschluss statt auf Kontinuität finanziert und besetzt. Sie ist wichtig, weil Gesundheitsleistungen langlebig sind und sich ständig weiterentwickeln; ein an der Projektgrenze aufgelöstes Team nimmt genau das angesammelte klinische und operative Wissen mit, das einen Service sicher hält, und „Pilot-Fegefeuer“ ist das wiederkehrende Symptom. Die eigentliche Spannung ist finanzieller und struktureller Art: Produktfinanzierung erfordert ständige Budgets und stellt das jährliche, zeitlich begrenzte Antragsmodell infrage, um das Finanzwesen und Governance herum gebaut sind – es ist also ebenso ein Gespräch über Geld und Verantwortlichkeit wie über Lieferung. Betrachten Sie einen konkreten Service, der eine Übergabe durchlaufen hat – verfolgen Sie, was aus seinem Gefährdungsprotokoll, seiner Nutzerforschung und seinem Team wurde – und wägen Sie das gegen die Disziplin ab, die Produktfinanzierung verlangt. Eine gute Antwort benennt einen konkreten Fall, beziffert oder charakterisiert zumindest das verlorene Wissen und ist offen darüber, welche organisatorischen Hürden (Finanzierungszyklen, Ressourcenregeln, Governance-Strukturen) sich bewegen müssten, damit dauerhafte Produktteams zur Norm werden.

4. Wer wird durch die von uns gebauten Services am ehesten ausgeschlossen oder geschädigt, und können wir zeigen, wo wir zuerst für diese Menschen gestaltet haben statt zuletzt? Das Thema besteht darauf, dass Gerechtigkeit nicht verhandelbar ist und dass ein Service, der nur für digital Versierte funktioniert, gesundheitliche Ungleichheiten vergrößert; diese Frage prüft also, ob „für die schwierigsten Fälle gestalten“ gelebte Praxis oder Parole ist. Sie ist wichtig, weil Ausschluss in Gesundheit und Pflege keine Unannehmlichkeit ist, sondern ein Schaden für Sicherheit und Zugang: Die Core20PLUS5-Bevölkerungsgruppen, Menschen mit eingeschränktem digitalem Zugang, geringer Gesundheitskompetenz oder ohne Smartphone sind genau die Menschen mit dem größten Bedarf, und ein Service, der sie wegdesignt, konzentriert den Schaden dort, wo er am wenigsten verkraftbar ist. Der Spannungspunkt ist, dass das Gestalten für die Ränder vorab Zeit und Geld kostet – assistierte digitale Wege, Barrierefreiheit nach WCAG, Offline- und nichtdigitale Rückfallwege, Übersetzung – und diese Kosten sich leicht aufschieben lassen, wenn ein Liefertermin naht und die selbstsichere Mehrheit das Ding bereits nutzen kann. Betrachten Sie einen echten Service und fragen Sie, wer in der Stichprobe seiner Nutzerforschung ist, ob eine Gleichstellungs- und Gesundheitsungleichheitsanalyse tatsächlich eine Designentscheidung geprägt hat und was mit jemandem geschieht, der nicht online gehen kann oder will. Eine ehrliche Antwort benennt die gefährdeten Gruppen für diesen Service, zeigt mindestens eine konkrete für sie getroffene Designentscheidung und ist offen darüber, wo das Team unter Druck Inklusion geopfert hat und wie es diesen Kompromiss beim nächsten Mal verteidigen würde.

5. Wo erfinden wir Infrastruktur neu, die bereits existiert, und wo würde das Bauen auf offenen Standards und die Wiederverwendung gemeinsamer Plattformen tatsächlich verändern, was wir ausliefern? Das Gestalten für Interoperabilität und Wiederverwendung ist eine der bewährten Praktiken des Themas, und diese Frage lässt das Team dem Sog zum Maßgeschneiderten begegnen statt zur Wiederverwendung – dem Login, den Benachrichtigungen, der Aktenintegration, die ein Dutzend anderer Teams ebenfalls gebaut hat. Sie ist wichtig, weil in einem fragmentierten System jede neu erfundene Komponente öffentliches Geld ist, das doppelt ausgegeben wird, und ein neues Silo, das Daten nicht sicher austauschen kann; umgekehrt ist das Bauen auf HL7 FHIR und SNOMED CT und die Wiederverwendung der dünnsten tragfähigen Plattform das, was einen Service überhaupt erst durch die Beschaffung bringt und über ein ICS hinweg Daten teilen lässt. Der eigentliche Zielkonflikt ist, dass Wiederverwendung Abhängigkeit bedeutet: Eine gemeinsame Plattform kann langsamer, weniger zugeschnitten oder von der Roadmap eines anderen bestimmt sein, sodass das Team die Reibung einer gemeinsamen Komponente gegen die langfristigen Kosten und Risiken eines maßgeschneiderten Silos abwägen muss. Untersuchen Sie einen aktuellen Bau und listen Sie auf, was wirklich neu ist und was eine bestehende Plattform, einen Standard oder eine offene Komponente dupliziert, und prüfen Sie, ob „das können wir nicht wiederverwenden“ eine belegte Randbedingung oder eine ungeprüfte Annahme ist. Eine gute Antwort unterscheidet die Teile, die sich zu bauen lohnen, von denen, die sich wiederzuverwenden lohnen, ist ehrlich über Reife und Governance der angebotenen Plattformen und legt sich für alles, was Daten austauschen muss, auf offene Standards fest.

6. Wie stimmen wir das Gewicht unserer Governance auf die Höhe des Risikos ab, und wo ist die Absicherung derzeit entweder zu schwer für risikoarme Änderungen oder zu leicht für risikoreiche? Verhältnismäßige Governance ist eine tragende Idee dieses Themas – klinische Änderungen mit hohem Risiko verdienen tiefgehende Prüfung, während inhaltliche Änderungen mit geringem Risiko nicht wochenlang auf ein Gremium warten sollten –, und diese Frage prüft, ob die Organisation die Absicherung am Risiko kalibriert oder einen einzigen stumpfen Prozess auf alles anwendet. Sie ist wichtig, weil falsch eingestellte Governance in beide Richtungen schadet: Ein schweres Einheitstor lässt Teams Änderungen bündeln und bremst genau die Iteration, die Services sicher hält, während eine durchgängig leichte Hand eine wirklich riskante klinische Änderung ohne die nötige Prüfung durch klinische Sicherheit und Informationsgovernance durchlässt. Der Spannungspunkt ist, dass Verhältnismäßigkeit Urteilsvermögen erfordert und Urteilsvermögen für Gremien und Prüfende unbequem ist, die eine einzige verpflichtende Checkliste leichter verteidigen können als einen risikogestuften Weg. Schauen Sie, wie Ihre letzten zwölf Änderungen abgesichert wurden, sortieren Sie sie nach tatsächlichem klinischem und Datenrisiko und sehen Sie, ob der Aufwand dem Risiko oder dem Kalender folgte. Eine ehrliche Antwort nennt konkrete Beispiele für Über- und Unter-Governance, schlägt klare Kriterien für die Risikostufung von Änderungen vor und benennt, wer die Befugnis hat, die Stufe festzulegen, und dafür Rechenschaft trägt.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System möchte Klinikpersonal an drei Akutkrankenhäusern (Trusts), in Gemeindediensten und in der kommunalen Sozialfürsorge eine gemeinsame Patientenakte bereitstellen. Der alte Weg würde ein Programm mit festem Umfang beauftragen, jeden Bildschirm im Voraus spezifizieren und spät integrieren.

Stattdessen bildet das ICS ein multidisziplinäres Team: eine Produktmanagerin, einen Delivery Manager, eine Nutzerforscherin, einen Interaktionsdesigner, zwei Entwickler, eine Clinical Safety Officer und einen Verantwortlichen für Informationsgovernance, mit Zugang zu einem Caldicott Guardian und einer Fachkraft der Sozialfürsorge. Sie führen eine achtwöchige Discovery durch und beobachten, wie eine Gemeindekrankenschwester, ein Chefarzt der Notaufnahme und eine Sozialarbeiterin heute tatsächlich versuchen, Informationen zu finden. Sie entdecken, dass der eigentliche Schmerz nicht „keine Daten“ ist, sondern „Daten, deren Aktualität sie nicht trauen können“.

Das Team liefert eine schmale Alpha aus: reiner Lesezugriff auf Allergien, Medikation und den aktuellen Status des Versorgungsplans für einen klinischen Pfad, mit einem sichtbaren Stempel „zuletzt aktualisiert“. Die klinische Sicherheit läuft parallel; ab Woche eins wird ein Gefährdungsprotokoll geführt. Sie messen, ob Klinikpersonal aufhört, andere Teams anzurufen, um Informationen zu bestätigen. Erst wenn diese dünne Scheibe sich als wertvoll und sicher erweist, weiten sie die Akte aus – finanziert als fortlaufendes Produkt, nicht als abgeschlossenes Projekt.

Sektorperspektiven#

Dieselben vier Kräfte – Sicherheit, Gerechtigkeit, Pflicht, Geld – wirken auf jede Organisation, doch die Arbeitsweisen, die ihnen begegnen, verschieben sich mit Größe, Finanzierung und Rechenschaftspflicht.

Startup#

Ein kleines Unternehmen der digitalen Gesundheit steht und fällt mit Fokus, weshalb seine Arbeitsweisen aus Notwendigkeit schlank sind: ein multidisziplinäres Team, flache Entscheidungsfindung und täglicher Kontakt mit Nutzenden. Die Beschränkung ist die Finanzierungsdauer (Runway), nicht Stellenregeln; daher wird Discovery in Wochen gemessen und Evidenz günstig gesammelt – eine Handvoll klinischer Interviews, ein klickbarer Prototyp, ein ehrliches Gefährdungsprotokoll, geführt von einer anteilig tätigen Clinical Safety Officer. Die Gefahr besteht darin, Sorgfalt bei Sicherheit und Informationsgovernance zu überspringen, um einen Investorenmeilenstein zu erreichen; die Disziplin, die einer Prüfung standhält, behandelt DCB0129 und eine Datenschutz-Folgenabschätzung als Eintrittskriterien für einen Piloten, nicht als aufgeschobenen Papierkram, bis ein Trust danach fragt. Interoperabilität von Tag eins an (FHIR, SNOMED CT) ist zudem ein kommerzieller Vorteil, denn ein Startup, das keine Daten austauschen kann, wird nie die NHS-Beschaffung passieren.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder ein ambulanter Pflegedienst, eine Einzelstandort-Klinik oder ein bescheidener Health-Tech-Lieferant jenseits der Phase ohne Umsatz – trägt dieselben Sicherheits-, Gerechtigkeits-, Pflicht- und Geldzwänge wie ein großer Trust, aber mit einem Bruchteil der Fähigkeit, ihnen zu begegnen. Arbeitsweisen müssen hier radikal verhältnismäßig sein: Es gibt selten ein eigenes Digital- oder IG-Team, sodass das „multidisziplinäre Team“ oft eine Handvoll Menschen mit mehreren Hüten ist, plus eine geteilte oder ausgelagerte Ressource für klinische Sicherheit und Datenschutz. Die Falle ist die Annahme, die gesetzlichen Pflichten skalierten mit der Organisation nach unten – das tun sie nicht; klinische Sicherheit nach DCB0129/DCB0160, eine Datenschutz-Folgenabschätzung und Barrierefreiheit gelten weiterhin vollständig, auch wenn eine einzelne Praxismanagerin für alles verantwortlich ist. Die praktische Disziplin besteht darin, sich stark auf Wiederverwendung statt Eigenbau zu stützen: akkreditierte Standardsysteme einzuführen, von Lieferanten DTAC-Konformität und offene Standards (FHIR, SNOMED CT) zu verlangen und nationale sowie ICS-bereitgestellte Plattformen zu nutzen, sodass Sicherheit, Interoperabilität und Informationsgovernance geerbt statt mit knappen Mitteln neu erfunden werden.

Großunternehmen#

Ein NHS Trust oder ICS hat das umgekehrte Problem: reichlich Prozess und fragmentierte Zuständigkeit. Arbeitsweisen bedeuten hier ebenso sehr Verlernen – Programmgewohnheiten mit festem Umfang aufgeben, Projektteams, die aufgelöst und neu aufgebaut werden, stilllegen – wie das Einführen neuer Praktiken. Rechenschaft ist formal und persönlich (eine Senior Responsible Owner, ein Caldicott Guardian, Freigabe der klinischen Sicherheit auf Vorstandsebene); der Gewinn liegt also darin, diese Rollen im Lieferteam zu verankern, statt sie als Tore anzuflanschen. Ein großer Health-Tech- oder Pharma-Lieferant sieht sich dem Spiegelbild gegenüber: hohe technische Reife, aber Distanz zur klinischen Realität an der Front, die multidisziplinäre Teams mit echter Zeit von Klinikpersonal schließen sollen.

Regierung#

Eine nationale oder lokale öffentliche Stelle – NHS England, DHSC, UKHSA, eine Kommunalverwaltung – setzt die Standards, nach denen alle anderen arbeiten, sodass ihre Arbeitsweisen nach außen ausstrahlen. Ihre Rechenschaft gilt gegenüber dem Parlament und der Öffentlichkeit, was die Messlatte für Transparenz, Ausgabenkontrolle und Gerechtigkeit hebt: Ein Servicestandard, ein veröffentlichter Assurance-Weg und Core20PLUS5-Pflichten sind Instrumente dieser Rechenschaft, keine optionalen Extras. Das Risiko in dieser Größenordnung ist, zentral für einen Durchschnittsbürger zu gestalten, den es nicht gibt, und eine Lösung vorzuschreiben, bevor der lokale Bedarf verstanden ist. Das Gegenmittel ist dieselbe nutzerzentrierte, iterative Disziplin wie überall, angewandt mit einer Neigung dazu, offene Standards und wiederverwendbare Plattformen zu setzen, auf denen föderierte Organisationen aufbauen können – das System zu steuern, nicht nur einen Service zu liefern.

Häufige Fehlermuster#

• Lösung zuerst. Sich auf ein benanntes Produkt festlegen, bevor der Bedarf verstanden ist. Gegenmittel: Discovery finanzieren und Nutzerbedürfnisse zum Eintrittskriterium für den Bau machen.
• Governance als spätes Tor. Klinische Sicherheit und Informationsgovernance werden erst beim Go-live konsultiert und erzwingen Nacharbeit oder unsichere Abkürzungen. Gegenmittel: beide ab Tag eins im Team verankern.
• Projektfluktuation. Teams aufbauen und wieder abreißen und dabei hart erarbeitetes Fach- und Sicherheitswissen verlieren. Gegenmittel: Produktfinanzierung und dauerhafte Teams.
• Pilot-Fegefeuer. Endlose Piloten, die nie skalieren, weil Akzeptanz, Schulung und Business Change nie mit Ressourcen ausgestattet wurden (siehe Thema 8.1 — Veränderungsmanagement). Gegenmittel: den Weg zur Skalierung vor dem Piloten planen.
• Gerechtigkeit als Nachgedanke. Für die selbstsichere Mehrheit gestalten und die Menschen ausschließen, die Versorgung am meisten brauchen. Gegenmittel: zuerst für die schwierigsten Fälle gestalten.

Reifegradmodell#

Checkliste#

• Jeder Service hat ein benanntes, stabiles multidisziplinäres Team mit Kompetenzen in klinischer Sicherheit und Informationsgovernance.
• Kein Bau beginnt ohne belegte Nutzerbedürfnisse aus der Discovery.
• Klinisches Risikomanagement (DCB0129/DCB0160) läuft ab Tag eins, mit einem lebendigen Gefährdungsprotokoll.
• Eine Gerechtigkeits- bzw. Gesundheitsungleichheitsanalyse wurde durchgeführt, und assistierte digitale Wege existieren.
• Die Lieferung erfolgt in kleinen, häufigen, messbaren Scheiben.
• Entscheidungen werden festgehalten und unterscheiden klinische von Lieferevidenz.
• Services werden nach offenen Interoperabilitätsstandards gebaut und verwenden gemeinsame Plattformen wieder.
• Das Gewicht der Governance ist auf das Risiko abgestimmt und dem Team bekannt.
• Es gibt einen finanzierten Weg vom Piloten zur Skalierung, einschließlich Schulung und Veränderung.

Zentrale Quellen#

• NHS digital service manual — NHS service standard und seine Punkte, darunter „Use agile ways of working“ und „Create a team that includes multidisciplinary skills and perspectives“ (service-manual.nhs.uk).
• GOV.UK Service Manual und der Government Service Standard — Government Digital Service (gov.uk/service-manual).
• NHS England / NHSX — Digital Technology Assessment Criteria (DTAC).
• Standards zur klinischen Sicherheit DCB0129 und DCB0160 (NHS England / ehemals NHS Digital).
• NICE — Evidence Standards Framework for digital health technologies (nice.org.uk).
• NHS England — Ansatz Core20PLUS5 zur Verringerung gesundheitlicher Ungleichheiten.

Referenzen#

1. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
2. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
3. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
4. Iterative and incremental development — Wikipedia — https://en.wikipedia.org/wiki/Iterative_and_incremental_development
5. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
6. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
7. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
8. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
9. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Government Service Standard — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/service-standard
13. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
14. Clinical Risk Management: DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
15. Evidence Standards Framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
16. Core20PLUS5 — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/