London Ambulance CAD und Patientensicherheits-Verantwortung

Zusammenfassung

Der London Ambulance Service setzte am 26. Oktober 1992 ein noch unvollständiges Betriebsmodell vollständig im Live-Betrieb ein. Die Untersuchung stellte unfertige und unzureichend getestete Software, ungetestete Volllast-Resilienz und Ausweichverfahren, unzuverlässige Status- und Standortdaten, Kommunikationsengpässe, inkonsistente Schulungen, schwache Benutzerverantwortung und eine Kontrollraumänderung fest, die vertraute Papier- und menschliche Korrekturwege beseitigte.
Die Ereignisse vom 26. und 27. Oktober müssen von dem Absturz am 4. November unterschieden werden. Nach Darstellung der Untersuchung versagte der Computer an den ersten beiden Tagen im engeren technischen Sinne nicht; interagierende Design- und Betriebsdefekte erzeugten die Symptome von Systemausfall und inakzeptabler Verzögerung. Am 4. November verursachte ein kleiner Programmierfehler tatsächlich einen Absturz, und ein unzureichend getesteter automatischer Wechsel stellte den Dienst nicht sicher.
Verantwortlichkeit folgt aus praktischer Kontrolle über Bereitschaftsnachweise. Lieferanten schuldeten wahrheitsgemäße Implementierung und Qualitätsnachweise; das LAS-Management kontrollierte Anforderungen, Integration, Schulung, Ausweichverfahren und Umstellung; der Vorstand und die regionale Gesundheitsbehörde kontrollierten die Überprüfung; Minister trugen die öffentliche Aufsicht. Besatzungen und Kontrollraumnutzer waren wesentliche Quellen operativer Nachweise, nicht eine bequeme Erklärung für ein System, das vorhersehbare Unvollkommenheit ignorierte.
Die Untersuchung lehnte die Automatisierung nicht ab. Sie kam zu dem Schluss, dass LAS und die Öffentlichkeit von CAD profitieren könnten, empfahl eine weitere Planung und schlug einen schrittweisen Weg vor. Spätere Forschungen zur Wende des Dienstes weisen ebenfalls auf Benutzereinbeziehung, realistische Zeitpläne, Prototyping, gründliche Tests, einfache phasenweise Implementierung, Infrastrukturvertrauen und Vertrauen als Reparaturmechanismen hin.

Notfall-Einsatzleitung ist ein Zustandsschätzungsproblem

Ein Notfall-Einsatzleitsystem muss mehr wissen, als ob sein Softwareprozess läuft. Es muss wissen, dass ein Anruf verstanden wurde, dass der Einsatzort nutzbar ist, dass ein bestimmter Krankenwagen verfügbar ist, dass sein aufgezeichneter Standort glaubwürdig ist, dass eine Alarmierungsnachricht die Besatzung erreicht hat und dass die nächste Statusaktualisierung der Besatzung an die Leitstelle zurückgegeben wurde. Es muss dieses Betriebsbild kohärent halten, während sich Nachfrage, Geografie und menschliche Umstände ändern.

Eine überzeugende Demonstration bei geringer Last kann nicht beweisen, dass das Bild während einer schwierigen Schicht erhalten bleibt.

Der Untersuchungsbericht über den London Ambulance Service beschrieb vier Kernkommandofunktionen: Entgegennahme und Überprüfung von Anrufen, Identifizierung einer geeigneten Ressource, Kommunikation der Alarmierung und Verwaltung der Standorte von Rettungsmitteln. Das geplante computergestützte Einsatzleitsystem verband diese Funktionen mit einem Gazetteer, Kartendarstellung, mobilen Datenterminals, automatischer Fahrzeugortung, Funkkommunikation und Managementinformationen. Jede Komponente konnte lokal plausibel erscheinen, während das Gesamtbild falsch war.

Ein Standortfix konnte alt sein, ein Fahrzeug konnte seinen Status geändert haben, eine Datennachricht konnte fehlschlagen oder ein Anruf konnte in eine Warteschlange zurückkehren, ohne dass ein Controller den Grund sah.

Deshalb ist der Ausfall von 1992 nicht angemessen als eine schlechte Anwendung beschrieben. CAD wurde zur Kontrollfläche des Dienstes: der Ort, an dem unvollkommene Meldungen von Anrufern, Besatzungen, Funkgeräten und Datenbanken in Entscheidungen über reale Krankenwagen umgewandelt wurden. Seine Bereitschaft hing daher von der gesamten Einsatzleitungsinstitution ab. Die Softwarequalität war wichtig, aber auch die Kommunikationskapazität, die Raumaufteilung, die Personalausstattung, die Schulung, die Arbeitspraktiken, die Ausnahmebehandlung und die Befugnis, einen Übergang zu stoppen, wenn diese Elemente nicht übereinstimmten.

Diese Rahmung schützt den Fall auch vor einer anti-automatisierung Schlussfolgerung. Der manuelle Einsatzprozess hatte ernsthafte Einschränkungen. Papier-Unterlagen bewegten sich physisch durch den Kontrollraum; Zuteilende waren auf Karten, Funkberichte und geführte Fahrzeugaufzeichnungen angewiesen; Sprachkanäle konnten in Warteschlangen stehen; die Identifizierung doppelter Anrufe beruhte auf Gedächtnis und Urteilsvermögen. Die Untersuchung stellte breite Unterstützung für den Einsatz von Technologie zur Verbesserung des Dienstes fest. Das Versagen war nicht der Ehrgeiz zu automatisieren.

Es war die Zulassung, dass die Automatisierung lebende Autorität ausübt, bevor die Institution überzeugende Nachweise dafür hatte, dass ihr Betriebszustand, ihre Mitarbeiter und ihre Wiederherstellungspfade bereit waren.

Das Projekt versuchte, die Automatisierungslücke in einem Schritt zu überbrücken

LAS hatte bereits versucht, die Kommando- und Kontrollsysteme zu computerisieren. Ein früherer Versuch begann in den 1980er Jahren und wurde 1990 nach Belastungstests, die zeigten, dass die erwartete Nachfrage nicht bewältigt werden konnte, abgebrochen. Die Ersatzbemühungen begannen mit einer neuen Systemanforderungsspezifikation, die vom Herbst 1990 bis Februar 1991 erstellt wurde. Verträge folgten später im Jahr 1991, und die vollständige Implementierung war ursprünglich für Januar 1992 geplant. Die Geschichte hätte Systemlast, sich ändernde Anforderungen und Integrationsrisiken zu zentralen Akzeptanzfragen machen sollen.

Das neue Konzept war ambitionierter als eine computerisierte Anrufannahmehilfe. LAS strebte ein weitgehend automatisiertes System an, bei dem die Mehrheit der Anrufe einen computergenerierten Vorschlag für den am besten geeigneten Krankenwagen erhalten würde. Nur komplexe Fälle würden einen spezialisierten Zuteiler erfordern. Die automatische Fahrzeugortung und mobile Daten würden das Ressourcenbild speisen; Anrufnehmer konnten einen Vorfall bis zur Zuteilung bearbeiten; der Einsatz würde schließlich in ganz London und nicht über das vertraute Divisionsmodell erfolgen.

Die Untersuchung charakterisierte den beabsichtigten Wechsel von einem vollständig manuellen Prozess zur vollständigen Automatisierung in einer Phase als Hochrisikosprung.

Die Anforderungsarbeit hatte auch Schwächen bei der Verantwortlichkeit und den Grenzen. Die Spezifikation war detailliert und vorschreibend, aber es gab wenig frühzeitige Einbeziehung der Rettungsmannschaften, deren Arbeit sich ändern würde. Schnittstellen zu bestehenden Kommunikations- und anderen LAS-Systemen waren nicht vollständig definiert, und die Untersuchung fand keine Hinweise auf eine formelle Genehmigung der Anforderungsspezifikation. Ein präzises Dokument kann immer noch unvollständig sein, wenn die Personen, Schnittstellen und Betriebsannahmen, die den Erfolg bestimmen, es nicht akzeptiert haben.

Anforderungen in einem sicherheitskritischen Dienst sind nicht abgeschlossen, wenn Funktionen aufgelistet sind. Sie müssen festlegen, wie sich das System verhält, wenn ein Fahrzeug keine Meldung macht, wenn die Funkabdeckung schlecht ist, wenn zwei Anrufer einen Vorfall unterschiedlich melden, wenn eine Besatzung ein anderes Fahrzeug benutzt, wenn eine Workstation gesperrt ist oder wenn eine Warteschlange den sichtbaren Bildschirmbereich überschreitet. Sie müssen auch festlegen, welche Nachweise es erlauben, dass jeder Automatisierungsschritt eine bestehende menschliche Kontrolle ersetzt.

LAS spezifizierte einen leistungsstarken idealen Arbeitsablauf, band diesen Arbeitsablauf jedoch nicht an die unvollkommenen Bedingungen, unter denen er arbeiten müsste.

Nahezu perfekte Daten waren keine sichere Betriebsannahme

Die Untersuchung identifizierte wiederholt die Abhängigkeit des Systems von nahezu perfekten Fahrzeugortungs- und Statusinformationen. Wenn das System wüsste, wo sich jeder Krankenwagen befindet und was jede Besatzung tut, könnten automatisierte Vorschläge nützlich sein. Wenn nicht, könnte es selbstbewusst eine Ressource empfehlen, während eine nähere oder geeignetere außerhalb seines aufgezeichneten Bildes existierte. Der Zuteilungsalgorithmus musste nicht mathematisch kaputt sein, damit die operative Antwort falsch war.

Es gab viele gewöhnliche Wege zu einem unvollkommenen Zustand. Eine Besatzung könnte unter Einsatzdruck einen Statusknopf verpassen oder falsch timen. Eine Übertragung könnte auf einen Funkloch oder einen überlasteten Kanal treffen. Ein mobiles Terminal könnte einen erfolgreichen Austausch anzeigen, während ein Kontrollbildschirm einen anderen Status enthielt. Kennungen könnten fehlen oder vertauscht sein. Eine Besatzung könnte ein anderes als das aufgezeichnete Fahrzeug benutzen. Die Ortungsausrüstung und -installation könnte unzuverlässig sein.

Einige Mitarbeiter könnten das System auch falsch oder absichtlich falsch benutzt haben, aber die Untersuchung fand keine direkten Beweise, die die breite Zuschreibung des Managements von CAD-Problemen auf vorsätzlichen Missbrauch stützen, und behandelte ein solches Verhalten allenfalls als einen von vielen Beiträgen.

Stattdessen vervielfachte Unvollkommenheit die Arbeit. Ein falscher Zustand erzeugte schlechte Vorschläge und Ausnahmenachrichten. Ungelöste Ausnahmen erzeugten weitere Ausnahmen. Abgedeckte Anrufe konnten zur Aufmerksamkeitsliste zurückkehren, wenn der erwartete Statuszyklus unvollständig war. Als die Listen wuchsen, verschwanden Nachrichten aus dem Blickfeld, die Verarbeitung verlangsamte sich, und die Mitarbeiter hatten weniger Zeit, den Zustand zu korrigieren, der die Nachrichten verursachte. Verzögerungen veranlassten Bürger, erneut anzurufen, was die Arbeit an der Front des Systems erhöhte.

Die Betriebslast war daher endogen: Die Reaktion des Systems auf unvollkommene Daten erzeugte mehr Nachfrage nach denselben begrenzten Personen und Kanälen.

Dieser Rückkopplungsmechanismus ist das Herz des Falles. Datenqualität war keine Haushaltsmetrik, die nach dem Start repariert werden konnte. Sie bestimmte, welchen Krankenwagen der Dienst zu senden glaubte. Die Ausnahmekapazität war keine nebensächliche Benutzeroberflächenpräferenz. Sie bestimmte, ob die Bediener die Wahrheit schneller wiederherstellen konnten, als Fehler akkumulierten. Wahrheit der Anforderungen bedeutete, nachzuweisen, dass der Dienst realistische Raten von fehlenden, verspäteten und widersprüchlichen Informationen überleben konnte, nicht zu dokumentieren, dass ideale Eingaben ideale Ausgaben erzeugen würden.

Beschaffung machte Zeit und Preis zu einem Teil des technischen Designs

Die Beschaffung folgte den ständigen Finanzanweisungen der regionalen Gesundheitsbehörde, einschließlich offener Ausschreibungen und einer Vermutung zugunsten des günstigsten Angebots, sofern keine guten Gründe dagegen sprachen. Die Untersuchung fand nicht, dass die formellen Regeln einfach ignoriert worden waren. Sie stellte fest, dass die Regeln wenig qualitative Anleitung für eine größere Informationstechnologie-Beschaffung gaben und mehr Wert auf den Preis als darauf legten, ob ein Lieferant und ein integriertes Design die Arbeit sicher durchführen konnten.

Fünfunddreißig Unternehmen bekundeten zunächst Interesse, und siebzehn reichten Vorschläge für das gesamte System oder Teile davon ein. Viele potenzielle Lieferanten äußerten Bedenken hinsichtlich des geplanten Zeitplans für die vollständige Implementierung. Ihnen wurde mitgeteilt, dass dieser nicht verhandelbar sei. Obwohl ein Bewertungsprotokoll funktionale Fähigkeit, Durchsatz, Benutzerfreundlichkeit und Resilienz bewertete, stellte die Untersuchung fest, dass die Unfähigkeit, die vollständige Anforderung oder Frist zu erfüllen, ein Angebot effektiv ausschloss.

Der Zeitplan fungierte daher als übergeordnete technische Anforderung: Entwürfe, die die Notwendigkeit einer längeren Erprobung oder Phasen einräumten, waren benachteiligt.

Der Hauptlieferant war klein und übernahm ein Projekt, das größer war als seine bisherige Arbeit. Dennoch kam die Untersuchung auch zu dem Schluss, dass unter den auferlegten Zeitbeschränkungen und der Breite der Anforderungen kein Softwarehaus eine funktionierende Lösung hätte liefern können. Diese Feststellung blockiert die bequeme Geschichte eines einzigartig mangelhaften Anbieters.

Andere Lieferanten hatten verspätete Komponenten und technische Probleme; LAS besaß das ehrgeizige Konzept, die Frist, die Integrationsumgebung und den Live-Betrieb; regionale Beschaffungsregeln prägten die Auswahl; und die Projektleitung musste entscheiden, ob die gelieferten Nachweise ausreichend waren.

Der Vertrag ließ auch die Projektmanagement-Verantwortung unklar. LAS erwartete, dass der Hauptlieferant die gesamte Integration verwaltet, aber der Vertrag wies diese Rolle nicht klar zu, und der Lieferant hatte Schwierigkeiten, seinen eigenen Beitrag zu verwalten. LAS-Personal übernahm standardmäßig mehr Kontrolle. In einem Sicherheitssystem mit mehreren Lieferanten ist ein unklarer Integrator ein Betriebsdefekt. Jemand muss das End-to-End-Verhalten über CAD-Software, Hardware, Funkschnittstellen, Ortungsdienste und mobile Terminals verantworten.

Die Beschaffung kann nicht einfach Komponenten kaufen und hoffen, dass sich Verantwortlichkeit dort einstellt, wo ihre Nahtstellen aufeinandertreffen.

Projektmanagement verwandelte Druck in optimistische Zusicherungen

LAS wählte die PRINCE-Projektmanagementmethode, aber weder der Dienst noch die Lieferanten brachten umfangreiche Erfahrung in deren Anwendung mit. Die Untersuchung fand kein ordnungsgemäß strukturiertes IT-Exekutivkomitee, Projektboard, Projektmanagementteam und Assurance-Team, wie es die Methode vorsah. Es gab in einer frühen Phase keine Vollzeit-Teilnehmer von LAS, der Projektplan ließ keinen Raum für Überprüfung und Revision, und in Besprechungen festgehaltene Bedenken wurden nicht zuverlässig in Entscheidungen oder eskalierte Nachweise umgesetzt.

Die Projektberichterstattung beruhte oft auf optimistischen Zusicherungen. Lieferanten berichteten über Fortschritte; Geschäftsführer beruhigten den LAS-Vorstand und die South West Thames Regional Health Authority; bekannte Probleme wurden als behoben beschrieben. Ein interner Überprüfungsbericht vom März 1992 forderte Volumentests der Kommunikation, eine unterzeichnete Implementierungsstrategie, kontrollierte Softwareänderungen und eine Überprüfung der Schulung. Er wurde dem Vorstand nicht vorgelegt, wie der Vorstand es verlangt hatte.

Der anschließende Bericht des Geschäftsführers sagte, es gebe keine Hinweise darauf, dass die vollständige Software sich als unzuverlässig erweisen würde. Die Untersuchung antwortete mit einem dauerhaften Sicherheitsprinzip: Fehlen von Hinweisen auf Unzuverlässigkeit ist keine positive Gewissheit, dass ein missionskritisches System funktionieren wird.

Die Änderungskontrolle schwächte die Evidenzbasis weiter. Der Liefernehmer nahm manchmal angeforderte Softwareänderungen außerhalb des formellen Projekt-Problemberichts-Prozesses vor. Zuvor getesteter Code konnte sich daher ändern, ohne dass die gesamte Projektgruppe davon wusste, und neue Defekte konnten eindringen. Bis zum 26. Oktober waren 1.513 Problemberichte erstellt worden, 81 waren noch offen. Zwei davon befanden sich in der Kategorie des Dienstes für schwere Beeinträchtigung, die den Betrieb in der realen Umgebung verhinderte, und 44 in einer Kategorie, die mit schlechterem Dienst für Patienten verbunden war.

Die vollständige Bereitstellung wurde fortgesetzt, während die eigene Problemklassifikation von LAS immer noch schwerwiegende Betriebsfehler verzeichnete.

Der Vorstand und die RHA sahen weiterhin Schwierigkeiten, aber keiner von ihnen beauftragte die unabhängige, eingehende technische Überprüfung, die das Muster gerechtfertigt hätte. Auf Distanz gehaltene Governance wurde zum passiven Empfang von Managementvertrauen. Ein Vorstand muss keine Software debuggen, aber er muss lesbare Bereitschaftsnachweise fordern: integrierte Testergebnisse, nicht gelöste schwerwiegende Defekte, Abschluss der Schulung, Ausweichproben, Kommunikationskapazität, Benutzerabnahme und eine unterschriebene Entscheidung, die festlegt, wer Nein sagen kann.

Ohne dieses Material wird die Aufsicht zu einer Kette, die Optimismus nach oben und nicht Risikowahrheit übermittelt.

Tests simulierten nie den vollständigen Einsatzleitdienst

Funktionstests und Belastungstests wurden während des gesamten Projekts diskutiert. Die ersten Versuche im Januar 1992 waren nicht schlüssig, da die Software unvollständig war und nicht alle Komponenten verfügbar waren. In den folgenden Monaten wurden Teile von CAD, Ortungsverfolgung und Kommunikation getestet, aber die Untersuchung stellte fest, dass das gesamte integrierte System nie als Ganzes getestet wurde. Ständige Änderungen an Software, mobilen Daten, Ortungstechnik und der Funkschnittstelle führten dazu, dass es keine stabile Basislinie gab, der eine vollständige Dienstprobe vertrauen konnte.

Die Lücken beschränkten sich nicht auf die Codeabdeckung. Die Hardware-Resilienz unter Volllast war nicht nachgewiesen. Der Wechsel zu einem zweiten Dateiserver war nicht ausreichend getestet worden. Das Kommunikationsvolumen war vor der Implementierung nicht systematisch berechnet worden. Die Folgen verspäteter oder fehlender Fahrzeugzustände wurden nicht mit realistischen Raten dargestellt. Testszenarien injizierten nicht ausreichend die Standortinkonsistenzen und Kommunikationsausfälle, die im realen Londoner Betrieb auftreten. Das System wurde daher gegen eine sauberere Welt getestet als die, die es kontrollieren sollte.

Realistische Last ist mehr als eine Zielzahl von Anrufen pro Stunde. Sie umfasst die Form der Nachfrage und die durch Fehler erzeugte Arbeit: Schichtwechsel, bei denen sich viele Besatzungen anmelden, Funküberlastung, doppelte Anrufe, Anrufer, die eine Ankunftsschätzung wünschen, Fahrzeuge mit veraltetem Status, Terminals, die erneut versuchen, Bediener, die Zuteilungen korrigieren, und Ausnahmen, die weitere Ausnahmen erzeugen. Sie umfasst die kognitive Last von Listen, die über den Bildschirm hinausgehen, und die Verzögerung, die entsteht, wenn die Ressourcensuche auf entferntere Krankenwagen ausgeweitet wird.

Ein System kann eine synthetische Transaktionsrate bestehen und an der Arbeitslast scheitern, die es für Menschen erzeugt.

Der Bereitstellungspfad bot warnende Hinweise. Nachdem die Januar-Frist versäumt wurde, wurden die computerisierte Anrufannahme und der Gazetteer mit ausgedruckten Vorfalldaten für die manuelle Zuteilung und Sprachalarmierung eingeführt. Diese teilweise Nutzung brachte Vorteile, aber Bildschirme sperrten sich, Server fielen gelegentlich aus, und ein Vorfall wurde einmal in einem Druckerpuffer zurückgehalten, als ein Drucker ausgeschaltet war. Spätere Divisionsversuche zeigten unvollständige Statusberichte, unzuverlässige Standortfixe, Kommunikationsüberlastung, mobile-Terminal-Probleme und Vorschlagsfehler.

Dies waren keine Gründe, die Technologie aufzugeben. Es waren Testergebnisse, die den Fortschritt hätten steuern sollen.

Funk und Fahrzeugstatus bildeten einen sicherheitskritischen Regelkreis

Das Ressourcenbild des Systems hing von einer Schleife ab, die von Besatzungen und Fahrzeugen über mobile Terminals, Funkinfrastruktur und Schnittstellensoftware in CAD und dann durch Alarmierungsnachrichten zurück führte. Die Untersuchung stellte fest, dass die Auswirkungen von CAD auf die Kommunikationsinfrastruktur nicht ordnungsgemäß und systematisch berücksichtigt worden waren. Es gab keine formale Berechnung, wie das neue System die vorhandene Kommunikation belasten würde.

Ein Vorschlag, die Funknetzkapazität nach der vollständigen Implementierung zu überprüfen, kehrte die erforderliche Reihenfolge um; die Kapazität musste nachgewiesen werden, bevor der Dienst davon abhing.

Die Betriebsumgebung machte perfekte Kommunikation unwahrscheinlich. London umfasste Funklöcher, fahrende Fahrzeuge und Spitzenzeiten. Bei Schichtwechseln konnten sich anmeldende Besatzungen Kanäle überlasten. Fehlgeschlagene oder verspätete Statusübertragungen hinterließen bei CAD ein veraltetes Bild. Ein Terminal und ein zentraler Bildschirm konnten aufgrund von Problemen in Bestätigungsroutinen unterschiedlicher Meinung sein.

Sprachverkehr, der zur Lösung von Unsicherheiten verwendet wurde, konnte selbst zu Überlastung führen, während die Einschränkung von Sprache die menschliche Gegenkontrolle beseitigen konnte, die falsche oder doppelte Zuteilungen aufdeckte.

Die automatische Fahrzeugortung hatte analoge Grenzen. Städtische Übertragung und Standortbestimmung konnten gelegentlich falsch sein, selbst wenn die Komponente weitgehend brauchbar war. Die vorausschauende Sicht der Untersuchung war nicht, dass die Ortungstechnologie verworfen werden musste. Es war, dass CAD die unvollkommenen Standortinformationen, die eine solche Technologie unweigerlich liefern würde, erkennen und sicher handhaben musste. Zuverlässigkeit an der Komponentengrenze erforderte daher ein unsicherheitsbewusstes Systemverhalten, nicht ein Versprechen, dass die Komponente niemals unsicher sein würde.

Am 26. Oktober verbesserte die Anweisung, die Sprachkommunikation zu minimieren, die gemeldete Rate erfolgreicher Datenalarmierungen. Doch falsche oder mehrfache Zuteilungen wurden ohne Sprachkontakt weniger wahrscheinlich korrigiert. Dies veranschaulicht, warum eine lokale Metrik in die richtige Richtung gehen kann, während die Systemsicherheit schlechter wird. Mehr als erfolgreich markierte Nachrichten bewiesen nicht, dass die Leitstelle ein korrektes Bild hatte oder dass die beabsichtigte Besatzung tatsächlich zum beabsichtigten Vorfall unterwegs war.

Die gleiche Lektion gilt für die Statusmeldung der Besatzung. Das Drücken einer Folge von Tasten war keine isolierte Benutzerpflicht; es war Teil einer Rückkopplungskontrolle. Schulung, Schnittstellendesign, Einsatzdruck, Gerätezustand, Funkabdeckung und Vertrauen beeinflussten sie alle. Wenn das Management unvollständigen Status hauptsächlich als Verhalten der Belegschaft darstellte, gewichtete es die Systembedingungen, die korrekte Meldung erschwerten, und die Designpflicht, sicher zu degradieren, wenn die Meldung fehlschlug, zu gering.

Die Compliance der Front-Line konnte die Eingabe verbessern, aber sie konnte ein Design nicht heilen, das instabil wurde, wenn die Eingabe weniger als ideal war.

Schulung und Benutzerverantwortung waren Teil des Systems

Die Untersuchung stellte fest, dass die Mitarbeiter dem Einsatz von Informationstechnologie zur Verbesserung der Rettungsdienste im Allgemeinen positiv gegenüberstanden. Ihr mangelndes Vertrauen richtete sich gegen das aktuelle System und die Art und Weise seiner Einführung. Das ist wichtig, weil es das Klischee einer Belegschaft zurückweist, die sich grundsätzlich gegen Automatisierung wehrt. Die Menschen hatten gesperrte Bildschirme, inkonsistente Fahrzeuginformationen, fehlgeschlagene Übertragungen und sich ändernde Verfahren erlebt. Misstrauen war teilweise eine Beobachtung über operative Nachweise.

Die Schulung war unvollständig und inkonsistent. Einige fand lange vor der verzögerten Implementierung statt, sodass Fähigkeiten vor dem Einsatz verfielen. Ständige Softwareänderungen machten Schulungsmaterialien und erlernte Routinen instabil. Das Kontrollraumpersonal wurde auf unterschiedliche Kompetenzniveaus geschult, aber die Abdeckung variierte. Besatzungen und Kontrollraumpersonal wurden weitgehend getrennt geschult, obwohl ein erfolgreicher Einsatz von jeder Seite verlangte zu verstehen, wie ihre Handlungen die andere Seite beeinflussten.

Die Untersuchung schlug gemeinsame Elemente vor, damit beide den gemeinsamen Regelkreis und den Druck auf jede Rolle verstehen konnten.

Die vollständige Implementierung veränderte auch die physische und soziale Betriebsumgebung. Der Kontrollraum wurde neu konfiguriert. Ressourcenzuteiler wurden von Funkern und Ausnahmebearbeitern getrennt. Die Mitarbeiter arbeiteten an ungewohnten Positionen, ohne die Papierreserve, die während des Teilbetriebs verwendet wurde, und mit weniger Zugang zu Kollegen, mit denen sie zuvor Probleme gelöst hatten. Eine technisch unveränderte Anwendung wurde in ein neu verändertes Arbeitssystem gestellt. Das Testen der alten Raumaufteilung konnte die neue nicht beweisen.

Benutzerverantwortung wird manchmal auf Einstellung oder Change-Kommunikation reduziert. In diesem Fall hatte sie eine schärfere Sicherheitsbedeutung. Die Benutzer brauchten eine legitime Rolle bei Anforderungen, Terminaldesign, Betriebsverfahren, Proben und Abnahme. Sie mussten sehen, dass Fehler behoben wurden, und darauf vertrauen, dass die Meldung eines Problems eine Frist ändern konnte. Ohne diese Autorität wird „Buy-in" zu einem Druck, eine bereits getroffene Entscheidung zu unterstützen.

Das Management erwartete auch, dass CAD Änderungen in den Arbeitspraktiken durchsetzt, einschließlich der Auswahl von Ressourcen und der Bewegung über Stationsbereiche hinweg. Die Untersuchung beschrieb das System als eine operative Zwangsjacke, in der die Mitarbeiter dennoch versuchten, lokale Flexibilität zu bewahren. Software kann vereinbarte Änderungen unterstützen, aber sie kann keine Zustimmung herstellen oder situatives Wissen durch Spezifikation auslöschen.

Wenn eine Besatzung ein anderes Fahrzeug nimmt oder lokale Mitarbeiter eine bessere Ressource identifizieren, muss das System entweder die gültige Praxis aufnehmen oder die Institution muss die Praxis durch Konsultation, Schulung und verantwortliche Betriebspolitik ändern, bevor die Automatisierung davon abhängt.

26. und 27. Oktober führten zu einem Ausfall ohne engen technischen Absturz

Am 26. Oktober 1992 um 07:00 Uhr stellte LAS zum ersten Mal auf den vollständigen, ganz London umfassenden Einsatz des vorgesehenen Systems um. Der Code hatte sich in den vorangegangenen Wochen nicht plötzlich geändert. Die entscheidenden Änderungen waren betrieblicher Natur: keine Papieraufzeichnungen oder Aktivierungsboxen als Backup, ein neu konfigurierter Kontrollraum, getrennte Rollen, automatisierte Vorschläge als Zuteilungsbasis und Anrufnehmer, die einige Ressourcen zuweisen konnten.

Kontrollen, die den Mitarbeitern während des teilmanuellen Betriebs geholfen hatten, unzuverlässige Informationen auszugleichen, wurden gleichzeitig entfernt.

Die Untersuchung stellte ausdrücklich fest, dass weder das CAD-System noch seine Benutzer bereit waren. Die Software war unvollständig, unzureichend optimiert und nicht vollständig getestet. Die Hardware-Resilienz unter Volllast und der Ausweich auf einen zweiten Server waren ungetestet. Mobile-Daten-Übertragungsprobleme blieben bestehen; das Vertrauen in die automatische Ortung war eingeschränkt; die Mitarbeiter waren nicht alle vollständig geschult; und das Design war nicht gegen genügend ungenaue oder unvollständige Informationen getestet worden.

Die ausschließliche Verwendung computergenerierter Ressourcenzuteilungen unter diesen Bedingungen war nach dem Urteil der Untersuchung eine hochriskante Entscheidung.

Als die Aktivität von einer leichten frühen Last zunahm, hielt das System korrekte Status- und Standortdaten für weniger Fahrzeuge vor. Der neue Raum und Arbeitsablauf machten menschliche Korrekturen schwieriger. Bei weniger scheinbar verfügbaren Ressourcen wurden Vorschläge weniger geeignet und Suchvorgänge reichten weiter. Falsche, doppelte oder verzögerte Zuteilungen erzeugten mehr Ausnahmen. Abgedeckte Anrufe kehrten zur Aufmerksamkeit zurück, wenn ihre erwartete Zustandssequenz unvollständig war. Warteschlangen bauten sich auf, die Verarbeitung verlangsamte sich, und Nachrichten scrollten über den sichtbaren Bildschirm hinaus.

Bediener, die mehr Arbeit hatten, hatten weniger Kapazität, den zugrunde liegenden Zustand zu reparieren.

Die öffentliche Schleife verstärkte dann die interne. Verspätete oder nicht abgedeckte Vorfälle veranlassten Anrufer, erneut anzurufen. Doppelte Meldungen und Rückrufe erhöhten das Telefonvolumen. Zu wenige Anrufnehmer und ein sich verlangsamendes System verlängerten die Antwortzeiten, was weitere Anrufe und weitere Verzögerungen erzeugen konnte. Die Untersuchung wies die Behauptung zurück, dass der 26. und 27. Oktober in Bezug auf Vorfälle oder transportierte Patienten außergewöhnlich beschäftigt waren. Ein Großteil des scheinbaren Anstiegs ergab sich aus nicht identifizierten Duplikaten und Rückrufen als Reaktion auf Verzögerungen.

Diese Chronologie stützt zwei Aussagen, die zusammenbleiben müssen. Erstens stürzte das Computersystem am 26. und 27. Oktober im engeren technischen Sinne nicht ab. Es führte im Großen und Ganzen das aus, wofür es entwickelt worden war. Zweitens akkumulierten sich Design- und Betriebsmängel, bis der Dienst die Symptome eines Systemausfalls zeigte, einschließlich inakzeptabler Reaktionsverzögerungen. Nur zu sagen, dass der Computer „weiterlief", würde die Prozessverfügbarkeit mit erfolgreicher Notfallkontrolle verwechseln. Zu sagen, dass er technisch abgestürzt sei, würde den lehrreicheren Ausfallmechanismus auslöschen.

Für die Patientensicherheit ist die Konsequenz ohne eine nicht gestützte Behauptung von Verletzten klar. Notrufe verzögerten sich, Krankenwagenankunftszeiten wurden manchmal inakzeptabel, und das Kontrollpersonal konnte kein verlässliches Bild von Vorfällen und Ressourcen aufrechterhalten. Ein sicherheitskritischer Dienst hatte seine rechtzeitige Befehlsevidenz verloren. Die Gefahr entstand, bevor eine endgültige Zählung der Schäden erstellt werden konnte: Patienten und Anrufer waren der Unsicherheit ausgesetzt, ob Hilfe zugeteilt war, ob sie sich bewegte und wann sie eintreffen würde.

Die Umstellungsentscheidung ist daher das zentrale Verantwortungstor. Führungskräfte wussten von unvollständiger Software, offenen schwerwiegenden Problemen, Kommunikationsbedenken, Schulungslücken, Misstrauen und ungetesteten Ausweichverfahren. Sie standen auch unter legitimem Druck, die Leistung zu verbessern. Druck erklärt, warum ein frühes Ergebnis attraktiv war; er beweist keine Bereitschaft. Der Entscheidungsträger brauchte die Autorität, Nachweise über das angekündigte Datum zu stellen, und eine Aufzeichnung, die zeigt, welche Akzeptanzbedingungen erfüllt waren.

Die Untersuchung konnte nicht verstehen, warum die vollständige Implementierung mit so vielen bekannten Mängeln fortgesetzt wurde.

Der Absturz am 4. November war ein anderer Fehler

Nach den Problemen vom 26. und 27. Oktober kehrte die Steuerung zu einer halbmanuellen Anordnung zurück, die der früheren weitgehend ähnelte. Anrufe und Standortsuche nutzten noch den Computer, Vorfallsdetails wurden ausgedruckt, Menschen identifizierten Ressourcen, und die Alarmierung konnte CAD, einen Stationsdrucker oder mobile Daten nutzen. Sprachkanäle halfen, Missverständnisse zu klären. Die Mitarbeiter fühlten sich mit dieser Kombination wohler, und sie arbeitete mit angemessenem Erfolg bis in die frühen Morgenstunden des 4. November.

Kurz nach 02:00 Uhr am 4. November verlangsamte sich das System und sperrte dann. Die Untersuchung führte diesen tatsächlichen Absturz auf einen kleinen Programmierfehler zurück, der etwa drei Wochen zuvor eingeführt worden war. Code im Zusammenhang mit der Alarmierung verbrauchte eine kleine Menge Serverspeicher, ohne ihn freizugeben; wiederholte Nutzung erschöpfte schließlich den verfügbaren Speicher.

Die Untersuchung kritisierte Nachlässigkeit und unzureichende Qualitätssicherung bei Codeänderungen, stellte aber auch fest, dass der Fehler durch konventionelle Programmierer- oder Benutzertests allein wahrscheinlich nicht zu finden gewesen wäre.

Die Unterscheidung ist wichtig, weil sie verhindert, dass der gesamte Fall auf diesen Fehler reduziert wird. Der Speicherdefekt erklärte nicht die Rückkopplungsschleifen vom 26. und 27. Oktober. Er sollte auch nicht zu einer Moralkeule gegen einen einzelnen Programmierer werden. Ein kritischer Dienst verfügt über Änderungsprüfung, unabhängige Qualitätssicherung, Überwachung, Kapazitätsalarme und Wiederherstellung, gerade weil ein kleiner lokaler Defekt entkommen kann. Die Verantwortung liegt darin, warum ein Defekt ohne Erkennung zu einem Dienstverlust akkumulieren konnte und warum die Wiederherstellung ihn nicht eindämmte.

Der automatische Wechsel zu einem Backup-Server bewahrte den Betriebsmodus nicht. Die Ausweichlösung war für das beabsichtigte papierlose System spezifiziert worden, während Drucker als temporäres Hilfsmittel nach der versäumten ursprünglichen Frist hinzugefügt worden waren. Die Auswirkung eines Serverausfalls auf diese druckerbasierte Konfiguration war nicht getestet worden, und die Untersuchung fand keinen Hinweis darauf, dass der automatische Wechsel selbst ausreichend nachgewiesen worden war.

Als der Absturz auftrat, erfassten die Mitarbeiter Anrufe mit Sprachaufzeichnungen und kehrten zur vollständig manuellen, papierbasierten Steuerung zurück. Die Betriebsstörung war durch die geringe nächtliche Last begrenzt, nicht durch eine erfolgreich nachgewiesene technische Wiederherstellung.

Verantwortlichkeit folgte praktischer Kontrolle über das Tor

Der Lieferant kontrollierte das Implementierungsdetail, die Codequalität, die Fortschrittsberichterstattung und die Nachweise, dass Änderungen wie behauptet funktionierten. Er schuldete disziplinierte Konfigurationskontrolle und ehrliche Offenlegung, wenn der Zeitplan seine Kapazität überstieg. Aber der Lieferant kontrollierte nicht den gesamten Dienst, wählte nicht jede Anforderung aus, schulte nicht jeden Benutzer, besaß nicht den Funkbestand oder hatte nicht die alleinige Befugnis, CAD im gesamten Londoner Raum in Betrieb zu nehmen. Die Verantwortung des Lieferanten ist real und begrenzt.

Das LAS-Führungsmanagement kontrollierte den Ehrgeiz, den Zeitplan, den Integrationskontext und die Entscheidung zum Fortschritt. Es kontrollierte, ob Papier- und Sprachsicherungen verfügbar blieben, ob die Schulung abgeschlossen war, ob der Betrieb neue Verfahren akzeptiert hatte und ob ein erfahrener unabhängiger Projektmanager und eine Qualitätsfunktion eingebunden waren. Die Tatsache, dass Manager unter Druck hart arbeiteten, hebt diese Kontrollen nicht auf. Es macht explizite Bereitschaftskriterien wichtiger, da persönliches Engagement sonst mit objektiver Sicherheit verwechselt werden kann.

Die Projekt- und Betriebsleitung musste Komponentenberichte in eine End-to-End-Aussage übersetzen. Das bedeutete, offene Probleme, Softwareversionen, Kommunikationsleistung, Standortgenauigkeit, Personalausstattung, Raumkonfiguration und Ausweichergebnisse abzugleichen. Eine benannte Umstellungsbefugnis musste diese Nachweise sehen, unabhängige technische und Benutzereinwände hören und ein eindeutiges Recht auf Verzögerung haben. Wenn niemand sowohl das Systembild als auch die Stoppbefugnis hat, kann das Projekt fortschreiten, weil jeder Teilnehmer annimmt, dass ein anderer Teilnehmer das Restrisiko trägt.

Der LAS-Vorstand kontrollierte die Governance-Prüfung. Die Untersuchung stellte fest, dass er ein irreführendes Maß an Beruhigung über die relevante Erfahrung des Lieferanten erhielt und keine negativen Referenzinformationen erhielt. Allgemeiner akzeptierte er Führungszusicherungen, während keine unabhängige Überprüfung den wahren Zustand des Projekts testete. Die Vorstandsverantwortung erforderte nicht, dass die Mitglieder Programmierwerkzeuge auswählten.

Sie erforderte, dass sie fragten, ob ein bahnbrechendes Notfallkontrollsystem unabhängige Sicherheit, realistische Belastungsergebnisse, getestete Ausweichverfahren und explizite ungelöste Risiken hatte.

South West Thames RHA verwaltete LAS auf Distanz. Formelle Beschaffungsregeln wurden eingehalten, und LAS suchte keine regionale technische Hilfe. Dennoch stieß die RHA wiederholt auf Bedenken und akzeptierte Zusicherungen, dass sie gelöst würden. Die Untersuchung kam zu dem Schluss, dass die Verantwortungslinien auf dem Papier sicher aussahen, aber nicht genügend Informationen für den Vorstand oder die Region lieferten, um ihre Verantwortlichkeiten auszuüben. Aufsicht auf Distanz kann nicht bedeuten, Distanz zu Nachweisen zu wahren, wenn der delegierte Dienst sicherheitskritisch ist.

Die ministerielle Verantwortung operierte auf einer anderen Ebene. Das Parlament war nicht der primäre technische Ermittler, und Aussagen, die während parteipolitischer Debatten gemacht wurden, sollten nicht als Feststellungen über Softwareursachen behandelt werden. Hansard zeigt jedoch die öffentliche Rechenschaftskette. Am 28. Oktober kündigte die Staatssekretärin direkte Sprachunterstützung, eine externe Untersuchung und regelmäßige Berichterstattung von der amtierenden LAS-Führung über die RHA und das NHS-Management an, damit die Minister informiert blieben.

Nachdem der Untersuchungsbericht im Februar 1993 vorgelegt wurde, fragte sie, ob die Rechenschaftspflicht gegenüber den Ministern robust genug sei, forderte Vorschläge zur Stärkung und wies auf Pläne für einen IT-Direktor und eine stufenweise CAD-Implementierung hin.

Das Personal an der Front kontrollierte spezifische Handlungen wie die Meldung des Status und die Reaktion auf Alarmierungen, aber es hatte keine gleichberechtigte Kontrolle über Beschaffung, Testumfang, Raumgestaltung oder Umstellung. Ihre Erfahrung war auch ein Nachweis, den Führungskräfte nutzen mussten. Die Behandlung von Besatzungen als bloß widerständig verwandelte Warnungen über Terminals, Funknachrichten und betriebliche Eignung in eine Verhaltenserzählung.

Verantwortlichkeit erfordert die Unterscheidung zwischen der Pflicht eines Benutzers, einem funktionierenden Verfahren zu folgen, und der Pflicht des Managements, nachzuweisen, dass das Verfahren und die Technologie sicher bleiben, wenn gewöhnliche menschliche und Kommunikationsfehler auftreten.

Patientensicherheitsrisiko erfordert keine erfundene Todeszahl

Der Londoner Fall wird oft mit einer bestimmten Anzahl von Todesfällen nacherzählt, die auf verspätete Krankenwagen zurückgeführt werden. Die Untersuchung liefert eine strengere Grenze. Sie stellte fest, dass nur Gerichte für Todesfälle feststellen könnten, ob eine Verzögerung einen Tod verursacht habe, und dass kein Gericht in den damals betrachteten Fällen zu dem Schluss gekommen sei, dass die verspätete Ankunft eines Krankenwagens den Tod eines Patienten verursacht habe. Die parlamentarische Antwort vom Februar 1993 wiederholte diese Position.

Diese Feststellung darf nicht zu „niemand starb", „niemand wurde verletzt" oder „der Fehler war harmlos" ausgeweitet werden. Es ist eine Aussage darüber, was Gerichte über die Ursache festgestellt hatten, nicht eine Zählung aller Ergebnisse. Die Untersuchung betonte auch die Belastung durch Verzögerungen bei der Annahme, Disposition und Ankunft. Sie stellte eine inakzeptable Antwortleistung und einen degradierten Notdienst fest. Das sind ausreichende Gründe für eine Patientensicherheitsanalyse.

Sicherheitsverantwortung beginnt mit der Exposition gegenüber unkontrolliertem Risiko, nicht nur mit einem nachgewiesenen tödlichen Endpunkt. Wenn die Leitstelle nicht weiß, ob ein Vorfall abgedeckt ist, wenn eine Alarmierung dupliziert oder verzögert wird oder wenn Anrufe sich häufen, weil frühere Anrufer keine zuverlässige Antwort erhalten haben, haben Führungskräfte die Nachweise verloren, die zum Schutz der Patienten erforderlich sind. Die Unsicherheit selbst ist betrieblich folgenreich. Eine spätere rechtliche oder klinische Kausalitätsfeststellung ist nicht erforderlich, bevor die Institution sie untersuchen und reparieren muss.

Sorgfältige Sprache bei Opfern verbessert auch die Kausalanalyse. Eine dramatische Zahl kann die Aufmerksamkeit von den Kontrollen ablenken, die nachweislich dokumentiert sind. Die Untersuchung stützt eine solide Darstellung von gestörten Anrufen, inakzeptablen Verzögerungen, unzuverlässigen Zuteilungen, öffentlicher Belastung und beschädigtem Vertrauen. Diese Feststellungen machen das Bereitschaftsversagen schwerwiegend, ohne Behauptung in Tatsache zu verwandeln.

Ausweichverfahren und Umstellungsbefugnis waren Governance-Kontrollen

Die LAS-Erfahrung zeigt, warum Kontinuitätspläne zusammen mit dem Primärsystem entworfen werden müssen. Papierreserve, Sprachkontakt, Stationswissen und manuelle Zuteilung waren nicht einfach alte Methoden, die außerhalb der Technologie warteten. Während des Teilbetriebs ermöglichten sie es den Menschen, schlechte Zustände zu erkennen, Urteilsvermögen auszuüben und Vorfälle sichtbar zu halten. Ihre Beseitigung veränderte die Fehlertoleranz des gesamten Dienstes. Diese Änderung benötigte einen eigenen Akzeptanznachweis.

Ein degradierter Modus muss festlegen, was ihn auslöst, wer ihn erklärt, welche Funktionen fortgesetzt werden, wie laufende Vorfälle abgeglichen werden und wie die Mitarbeiter wissen, welcher Datensatz maßgeblich ist. Er muss bei realistischer Last geprobt werden. Das Umschalten von Servern ist nur eine Ebene. Wenn Drucker, Terminals, Warteschlangen oder Arbeitszuteilung nach dem Wechsel anders funktionieren, kann die technische Verfügbarkeit das Kommando nicht bewahren. Wenn das Personal keine vollständige Vorfallsliste wiederherstellen kann, ist die Ausweichlösung fehlgeschlagen, selbst wenn die Hardware online ist.

Die Umstellungsbefugnis ist der Punkt, an dem diese Kontrollen verbindlich werden. Die Entscheidung sollte anhand vordefinierter Nachweise getroffen werden: kein ungelöstes Problem, das eine schwere Dienstbeeinträchtigung verursachen könnte; stabile Konfiguration; integrierter Volllasttest; Fehlerinjektion über Funk, Ortung und Terminals; aktuelle Rollenschulung und beobachtete Kompetenz; Benutzer- und Betriebsabnahme; besetzte Ausnahmekapazität; und nachgewiesener Übergang zu und von manuellen oder halbmanuellen Modi.

Jede nicht erfüllte Bedingung sollte einen benannten Risikoverantwortlichen und einen aufgezeichneten Grund haben, warum die Exposition akzeptabel ist.

Die Befugnis muss auch in der Lage sein, ohne organisatorische Bestrafung zu stoppen. Die Untersuchung beschrieb eine Kultur, in der Fristen als starr und schwer anfechtbar wahrgenommen wurden. Ein nur auf dem Organigramm existierender No-Go-Pfad ist keine betriebliche Kontrolle. Führungskräfte müssen technischen und frontseitigen Widerspruch schützen, die schriftliche Behandlung von Einwänden verlangen und verhindern, dass öffentliche Daten oder versunkene Kosten stillschweigend die Akzeptanzschwellen verändern.

Reparaturnachweise zeigten, dass Automatisierung Autorität verdienen konnte

Die erste CAD-Empfehlung der Untersuchung war, dass LAS die Planung eines computergestützten Einsatzleitsystems fortsetzen sollte. Sie stellte einhellige Unterstützung für Technologie fest, die den Rettungsdienst verbessern könnte, und beschrieb den Papierprozess als ineffizient. Ihr Zukunftsplan erforderte ein System, das an die vereinbarte Organisationsstruktur und Verfahren angepasst ist, zuverlässig und widerstandsfähig mit getestetem Backup, von Management und Mitarbeitern getragen, in einem Zeitplan eingeführt, der Konsultation, Qualitätssicherung, Tests und Schulung ermöglicht, und schrittweise bereitgestellt.

Die vorgeschlagene Sequenz verband zunehmende Autorität mit zunehmendem Nachweis. Eine erste Zwischenphase konnte die computerisierte Anrufannahme und Gazetteer-Funktionen wiederherstellen, jedoch erst nach einer Überprüfung der Softwarequalität, Tests, verbessertem Druck und Umschulung. Vorfallsdetails blieben menschlichen Zuteilern verfügbar. Eine zweite Phase sollte zuverlässige Fahrzeugortung und Status verfügbar machen, während menschliche Zuteiler noch Ressourcen auswählten. Sie erforderte eine spezielle Kommunikationsüberprüfung und besseres Vertrauen in die Infrastruktur.

Erst nach Akzeptanz und Erfahrung dieser Phase sollte die Alarmierung von Sprache auf mobile Daten umgestellt werden. Computergenerierte Ressourcenvorschläge könnten zunächst Vorschläge für menschliche Zuteiler sein. Anrufnehmer würden die Zuteilungsbefugnis erst erhalten, wenn Vorschläge, Kommunikation und der zugrunde liegende Zustand Vertrauen erworben hätten. In jeder Phase sollten Resilienz, Notfallplanung und Ausweichverfahren dem Bedarf an ständigem Dienst entsprechen. Dies war keine langsame Lieferung um ihrer selbst willen.

Jede Phase isolierte eine Behauptung, die unter Live-Bedingungen beobachtet werden konnte, bevor die nächste Abhängigkeit hinzugefügt wurde.

Die Reparatur der Governance begleitete die technische Phasierung. Die Untersuchung empfahl einen erfahrenen Projektmanager, ein Projektunterkomitee des Vorstands mit Vertretung aus dem gesamten Dienst, mögliche Beratung durch erfahrene Externe und einen IT-Direktor mit direktem Zugang zum Vorstand. Sie forderte auch eine bessere qualitative Beschaffungsberatung, eine Kommunikationsüberprüfung und eine offene Berichterstattung über die Antwortleistung an öffentliche Stellen und Londoner Abgeordnete. Diese Maßnahmen brachten Nachweise dorthin, wo die Autorität sie sehen und darauf reagieren konnte.

Hansard hält die öffentliche Seite dieser Reparatur fest. Im Februar 1993 sagte die Regierung, ein IT-Direktor werde die stufenweise Implementierung überwachen und stärkere Linien von LAS über die RHA zu den Ministern anstreben. Im Oktober berichtete eine schriftliche Antwort über neue NHS-Richtlinien zur effektiven Beschaffung von Informationssystemen und regelmäßige regionale Berichte über die Umsetzung der Untersuchungsempfehlungen, einschließlich des zukünftigen CAD.

Parlamentarische Aussagen beweisen nicht, dass jede Reparatur funktioniert hat, aber sie zeigen, dass die technische Bereitschaft zu einer expliziten Angelegenheit der institutionellen Aufsicht geworden war.

Eine spätere peer-reviewte Fallstudie beschrieb eine viel erfolgreichere LAS-CAD-Implementierung als eine Wende. Ihr Vergleich identifizierte Managementaufmerksamkeit für Benutzerbedürfnisse, Benutzereinbeziehung, größere Ressourcen, einen entspannteren, akzeptanzgetriebenen Zeitplan, Infrastrukturprojekte, die Vertrauen aufbauten, Partizipation und Prototyping, gründliche Tests, phasenweise und einfache Implementierung und Vertrauensbildung. Diese Ergebnisse sind eine Sekundäranalyse des späteren Programms, kein Ersatz für den Untersuchungsbericht von 1992.

Sie beweisen auch nicht, dass eine Intervention den späteren Erfolg verursacht hat. Organisatorische Wendepunkte haben viele Einflüsse, und die späteren Bedingungen unterschieden sich. Ihr Wert ist vergleichend: Die spätere Implementierung adressierte fast alle Kategorien, die problematisch gewesen waren. Der Kontrast zeigt, wie Reparatur aussieht, wenn sie in Betriebsbedingungen ausgedrückt wird, nicht in Slogans. Benutzer nehmen teil; Infrastruktur verdient Vertrauen; Tests sind gründlich; die erste Implementierung ist einfacher; der Zeitplan folgt der Akzeptanz; Vertrauen wächst durch gelieferte Nachweise.

Institutionelle Legitimität hängt vom beobachtbaren Einsatzleitungszustand ab

Notdienste bitten die Öffentlichkeit, Entscheidungen zu vertrauen, die Anrufer nicht überprüfen können. Ein Anrufer sieht nicht die Zuteilungswarteschlange, den Funkverkehr oder die Statusdatenbank. Institutionelle Legitimität hängt daher davon ab, dass der Dienst intern nachweist und öffentlich erklärt, dass diese verborgenen Mechanismen ein zuverlässiges Kommando bewahren. Wenn der Dienst nicht sagen kann, ob ein Krankenwagen wirklich verfügbar ist oder ob eine Alarmierung angekommen ist, scheitert das Vertrauen aus einem bestimmten Grund.

Verantwortlichkeit ist keine kollektive Schuld nach einem Ausfall. Sie ist die vorherige Zuweisung von Pflichten, Nachweise zu erbringen, zu hinterfragen und darauf zu reagieren. Der Implementierer beweist die Komponente. Der Integrator beweist den Dienst. Der Betrieb beweist, dass die Arbeit ausgeführt werden kann. Die Führung schützt Zeit, Ressourcen und Stoppbefugnis. Der Vorstand hinterfragt die Bereitschaft unabhängig. Aufsichtsbehörden fordern transparente Leistung und Reparatur.

Der London Ambulance Service machte CAD zu einem Test für die Patientensicherheitsverantwortung, weil die Einsatzautomatisierung autoritativ werden durfte, während ihr Bild des Dienstes fragil blieb. Die dauerhafte Antwort war nicht, den Computer abzulehnen. Es war, die Autorität konditional zu machen: Keine Automatisierung kontrolliert echte Anrufe, Besatzungen und Krankenwagen, bis die Institution zeigen kann, wie sie unter Last wahrheitsgemäß bleibt, wie Menschen sie wiederherstellen, wenn sie es nicht ist, und wer die Macht hat, zu stoppen, wenn die Nachweise unzureichend sind.