ロンドン救急サービス CAD と患者安全の説明責任

概況

ロンドン救急サービス（London Ambulance Service）は、1992年10月26日に未完成の運用モデルを本稼働させた。調査では、未完了で十分にテストされていないソフトウェア、未テストのフルロード耐性とフォールバック、信頼性の低いステータスと位置情報、通信の制約、一貫性のない訓練、弱いユーザーオーナーシップ、そして慣れた紙と人間による修正経路を排除した管制室の変更が明らかになった。
10月26日と27日の出来事は、11月4日のクラッシュとは区別されなければならない。調査報告によると、初日の2日間は狭い技術的意味でのコンピュータ障害は発生していない。相互作用する設計上の欠陥と運用上の欠陥が、システム障害と容認できない遅延の症状を生み出した。11月4日には、軽微なプログラミングエラーが実際にクラッシュを引き起こし、十分にテストされていなかった自動切り替えはサービスを維持できなかった。
説明責任は、準備エビデンスに対する実質的な管理に従う。サプライヤーは真実の実装と品質エビデンスを負っていた。LAS 経営陣は要件、統合、訓練、フォールバック、切り替えを管理していた。取締役会と地域保健当局は監視を管理していた。大臣は公的監督を担っていた。隊員と管制室ユーザーは運用エビデンスの重要な情報源であり、予測可能な不完全性を前提としないシステムの都合の良い説明ではなかった。
調査は自動化を拒否しなかった。LAS と国民が CAD から利益を得られる可能性があると結論づけ、継続的な計画を推奨し、段階的な道筋を提案した。その後のサービス改善に関する研究も、ユーザーの関与、現実的なタイミング、プロトタイピング、徹底的なテスト、シンプルな段階的実装、インフラへの信頼、そして信頼の修復メカニズムを指摘している。

緊急指令は状態推定問題である

緊急指令システムは、ソフトウェアプロセスが動作しているかどうかだけでなく、通報が理解されたこと、インシデントの場所が使用可能であること、特定の救急車が利用可能であること、その記録された位置が信頼できること、動員メッセージが隊員に届いたこと、隊員の次のステータス更新が管制に返ってきたことを把握しなければならない。需要、地理、人的状況が変化する中で、その運用状況を一貫して維持しなければならない。低負荷での説得力のあるデモンストレーションでは、困難なシフトの間も状況が正しいままであることを証明できない。

ロンドン救急サービスの調査では、4つの中核的な指揮機能が説明された。すなわち、通報の受信と確認、適切なリソースの特定、動員の通信、救急車リソースの位置管理である。意図されたコンピュータ支援指令システムは、これらの機能を地名辞典、地図作成、モバイルデータ端末、自動車両位置情報、無線通信、管理情報に接続した。各コンポーネントは局所的には妥当に見えても、統合された状況が間違っている可能性があった。位置情報が古い場合、車両のステータスが変わった場合、データメッセージが失敗した場合、または通報が理由も分からずにキューに戻る場合があった。

これが、1992年の障害が単なる不良アプリケーションとして十分に説明されない理由である。CAD はサービスの制御面（control surface）になりつつあった。すなわち、通報者、隊員、無線、データベースからの不完全な報告が実際の救急車に関する決定に変換される場である。したがって、その準備状態は指令機関全体に依存していた。ソフトウェアの品質は重要だったが、通信容量、部屋のレイアウト、人員配置、訓練、作業慣行、例外処理、そしてこれらの要素が一致しない場合に移行を停止する権限も重要だった。

この枠組みはまた、反自動化の結論から事例を守る。手動指令プロセスには深刻な限界があった。紙のインシデントフォームは管制室を物理的に移動していた。割り当て担当者は地図、無線報告、維持された車両記録に依存していた。音声チャネルは待ち行列が発生する可能性があった。重複通報の特定は記憶と判断に依存していた。調査では、技術を利用してサービスを改善することへの幅広い支持が確認された。失敗は自動化への野心ではなかった。機関がその運用状態、人材、復旧経路が準備できているという説得力のあるエビデンスを持つ前に、自動化に生きた権限を行使させることだった。

プロジェクトは自動化ギャップを一度に越えようとした

LAS は以前にも指揮統制のコンピュータ化を試みていた。1980年代に開始された初期プロジェクトは、負荷テストで予想需要を満たせないことが判明し、1990年に中止された。後継の取り組みは、1990年秋から1991年2月にかけて作成された新しいシステム要件仕様から始まった。契約は1991年後半に交わされ、完全実装は当初1992年1月とされていた。この経緯から、システム負荷、要件変更、統合リスクが中心的な受入質問になるべきだった。

新しいコンセプトは、コンピュータ化された通報受付支援よりも野心的だった。LAS は、大多数の通報に最も適切な救急車をコンピュータが提案する、ほぼ完全に自動化されたシステムを追求した。複雑なケースのみが専門の割り当て担当者を必要とした。自動車両位置情報とモバイルデータがリソース状況を提供し、通報受付担当者は割り当てまでインシデントを処理でき、指令は最終的にロンドン全体で、従来の管区モデルではなく運用されることになっていた。調査では、完全に手動のプロセスから一度に完全自動化への移行は、高リスクの飛躍であると特徴づけられた。

要件作業には、オーナーシップと境界の弱点もあった。仕様は詳細かつ規範的だったが、業務が変わる救急車隊員の早期関与はほとんどなかった。既存の通信システムや他の LAS システムとのインターフェースは完全には定義されておらず、調査では要件仕様の正式な署名の証拠は見つからなかった。成功を決定づける人材、インターフェース、運用想定が受け入れていない場合、正確な文書でも不完全であり得る。

安全重要サービスにおける要件は、機能がリストアップされた時点で完了するものではない。車両が報告しない場合、無線カバレッジが悪い場合、2人の通報者が1つのインシデントを異なるように報告する場合、隊員が別の車両を使用する場合、ワークステーションがロックする場合、キューが画面の表示可能領域を超える場合に、システムがどのように動作するかを指定しなければならない。また、各自動化ステップが既存の人間による制御を置き換えることを可能にするエビデンスも明記しなければならない。LAS は強力な理想的なワークフローを指定したが、そのワークフローを運用せざるを得ない不完全な条件に結びつけなかった。

ほぼ完全なデータは安全な運用想定ではなかった

調査は繰り返し、システムがほぼ完全な車両位置とステータス情報に依存していることを指摘した。システムがすべての救急車の位置とすべての隊員の行動を把握していれば、自動提案は有用であり得る。もし把握していなければ、より近くまたはより適切なリソースが記録された状況の外に存在する場合でも、自信を持ってリソースを推奨する可能性があった。割り当てルーチンは数学的に壊れている必要はなく、運用上の答えが間違っている可能性があった。

不完全な状態に至る通常の経路は多数あった。隊員はインシデントのプレッシャーの下でステータスボタンを逃したり、タイミングを誤ったりする可能性があった。送信が無線の不感地帯や混雑したチャネルに遭遇する可能性があった。モバイル端末は成功した交換を示す一方で、制御画面は別のステータスを保持する可能性があった。コールサインが欠落したり、入れ替わったりする可能性があった。隊員が記録されたものとは別の車両を使用する可能性があった。位置情報機器と設置は信頼性が低い可能性があった。一部のスタッフがシステムを誤って、または故意に使用した可能性もあるが、調査では、CAD の問題を故意の誤用に広く帰する経営陣の主張を直接支持する証拠は見つからず、そのような行動は多くの中の一つの要因として扱った。

代わりに、不完全さが作業を増大させた。不正確なステータスは不適切な提案と例外メッセージを生み出した。未解決の例外はさらに多くの例外を生成した。カバーされた通報は、期待されるステータスサイクルが完了しない場合、注意リストに戻る可能性があった。リストが増えるにつれて、メッセージは視界から外れ、処理は遅くなり、スタッフはメッセージを引き起こした状態を修正する時間が減った。遅延は一般市民が再度電話する原因となり、システムの前面で作業が追加された。したがって、運用負荷は内生的だった。すなわち、不完全なデータに対するシステムの応答が、同じ制約された人材とチャネルに対してより多くの需要を生み出した。

このフィードバックメカニズムが事例の核心である。データ品質は、稼働後に修正できるハウスキーピング指標ではなかった。それは、サービスがどの救急車を派遣できると信じているかを左右した。例外処理能力は、マイナーなユーザーインターフェースの好みではなかった。それは、オペレーターがエラーが蓄積するよりも速く真実を回復できるかどうかを決定した。要件の真実は、理想的な入力が理想的な出力を生み出すことを文書化することではなく、サービスが現実的な率の欠落、遅延、矛盾した情報に耐えられることを実証することを意味していた。

調達は時間と価格を技術設計の一部にした

調達は地域保健当局の定款財務指示に従い、公開入札と、反対する十分な理由がない限り最低入札を優先する推定を含んでいた。調査では、正式な規則が単に無視されたわけではないと認定した。規則は主要な情報技術調達に対して質的な指針をほとんど与えず、サプライヤーと統合設計が安全に作業を遂行できるかどうかよりも価格に重点を置いていた。

35社が当初関心を示し、17社がシステムの全部または一部の提案を提出した。多くの候補サプライヤーは、計画された完全実装のスケジュールに懸念を表明した。彼らはそれは交渉の余地がないと告げられた。評価プロトコルは機能能力、スループット、ユーザビリティ、耐性をランク付けしたが、調査では、完全な要件または期限を満たせないことが実質的に入札を除外したことが判明した。したがって、スケジュールは高次の技術要件として機能した。すなわち、より長い証明または段階の必要性を認める設計は不利になった。

主要サプライヤーは小さく、過去の業務よりも大きなプロジェクトを引き受けた。しかし、調査はまた、課せられた時間的制約と要件の広さの下では、どのソフトウェアハウスも実行可能なソリューションを提供できなかったと結論づけた。この発見は、一意に欠陥のあるベンダーという都合の良い話を阻止する。他のサプライヤーも遅延コンポーネントと技術的問題を抱えていた。LAS は野心的なコンセプト、期限、統合環境、ライブサービスを所有していた。地域調達規則は選択を形成していた。プロジェクトリーダーシップは、提供されたエビデンスが十分かどうかを決定しなければならなかった。

契約はまた、プロジェクト管理責任を曖昧にした。LAS は主要サプライヤーが全統合を管理することを期待したが、契約はその役割を明確に割り当てず、サプライヤーは自身の貢献を管理するのに苦労した。LAS 職員はデフォルトでより多くの管理権を引き受けた。マルチサプライヤーの安全システムでは、曖昧な統合者は運用上の欠陥である。誰かが CAD ソフトウェア、ハードウェア、無線インターフェース、位置情報サービス、モバイル端末にわたるエンドツーエンドの振る舞いを所有しなければならない。調達は単にコンポーネントを購入し、それらの接合部で説明責任が生まれることを期待することはできない。

プロジェクト管理はプレッシャーを楽観的な保証に変換した

LAS は PRINCE プロジェクト管理手法を選択したが、サービスもサプライヤーもそれを適用した実質的な経験を持っていなかった。調査では、手法が想定するような適切に構成された IT executive committee、project board、project management team、assurance team は存在しなかったと認定した。早期段階にフルタイムの LAS 参加者はおらず、プロジェクト計画はレビューと改訂の余地を許さず、会議で記録された懸念は確実に決定に変換されたり、エスカレーションされたりしなかった。

プロジェクト報告はしばしば楽観的な保証に依存していた。サプライヤーは進捗を報告した。エグゼクティブディレクターは LAS 取締役会と South West Thames Regional Health Authority を安心させた。既知の問題は是正されていると説明された。1992年3月の内部レビューは、通信の大量テスト、署名された実装戦略、管理されたソフトウェア変更、訓練のレビューを求めた。これは取締役会が要求したにもかかわらず、取締役会に提出されなかった。最高経営責任者のその後の報告書は、完全なソフトウェアが信頼性を証明しないという証拠はないと述べた。調査は耐久性のある安全原則で答えた。信頼性の欠如の証拠がないことは、ミッションクリティカルなシステムが機能するという積極的な保証ではない。

変更管理はさらにエビデンスベースを弱めた。サプライヤーは、正式な Project Issue Report プロセス外で要求されたソフトウェア変更を行うことがあった。したがって、以前にテストされたコードは、プロジェクトグループ全体が知らないうちに変更される可能性があり、新しい欠陥が入り込む可能性があった。10月26日までに1,513件の問題報告が提出され、81件が未解決のままであった。そのうち2件は、サービスが実際の環境での運用を妨げる深刻な劣化のカテゴリーにあり、44件は患者へのサービス低下に関連するカテゴリーにあった。LAS 自身の問題分類が依然として深刻な運用上の欠陥を記録しているにもかかわらず、完全展開が進められた。

取締役会と RHA は継続的な困難を目にしたが、どちらもその状況に値する独立した詳細な技術レビューを委託しなかった。アームズレングスのガバナンスは、経営陣の自信の受動的な受け入れになった。取締役会はソフトウェアをデバッグする必要はないが、読み取り可能な準備エビデンスを要求しなければならない。統合テスト結果、未解決の高重大性欠陥、訓練完了、フォールバックリハーサル、通信容量、ユーザー受入、そして誰がノーと言えるかを特定する署名付き決定である。その資料がなければ、監視はリスクの真実ではなく、楽観主義を上に伝達するチェーンになる。

テストは完全な指令サービスをリハーサルしなかった

機能テストと負荷テストはプロジェクトを通じて議論された。1992年1月の最初の試みは、ソフトウェアが不完全で全てのコンポーネントが利用できなかったため、決定的ではなかった。その後の数ヶ月で、CAD、位置追跡、通信の一部がテストされたが、調査では完全な統合システムが全体としてテストされることはなかったと認定された。ソフトウェア、モバイルデータ、位置技術、無線インターフェースへの継続的な変更により、完全なサービスリハーサルを信頼できる安定したベースラインは存在しなかった。

ギャップはコードカバレッジに限定されなかった。フル負荷下でのハードウェア耐性は未証明だった。セカンドファイルサーバーへの切り替えは十分にテストされていなかった。通信量は実装前に体系的に計算されていなかった。車両ステータスの遅延や欠落の結果は現実的な率で表現されていなかった。テストスクリプトは、実際のロンドン運用で発生することが知られている位置の不一致や通信障害を十分に注入していなかった。したがって、システムは制御を求められた世界よりもクリーンな世界に対してテストされた。

現実的な負荷は、1時間あたりのターゲット通報数以上のものである。これには需要の形状とエラーによって生成される作業が含まれる。シフト変更で多くの隊員がログオンする、無線の混雑、重複通報、到着見積もりを求める通報者、古いステータスの車両、再試行する端末、割り当てを修正するオペレーター、さらなる例外を生み出す例外。これには、画面を超えて移動するリストの認知負荷と、リソース検索がより遠くの救急車に拡大するときに発生する遅延が含まれる。システムは合成トランザクション率に合格しても、人間に課す作業負荷には失敗する可能性がある。

展開経路は警告のエビデンスを提供した。1月の期限が過ぎた後、コンピュータ化された通報受付と地名辞典が導入され、手動割り当てと音声指令用に印刷されたインシデント詳細が提供された。この部分的な使用は利益をもたらしたが、画面がロックし、サーバーが時々障害を起こし、プリンターがオフのときにインシデントがプリンターバッファーに保持されたことがあった。後の管区トライアルは、不完全なステータス報告、信頼性の低い位置情報、通信過負荷、モバイル端末の問題、提案エラーを露呈した。これらは技術を放棄する理由ではなかった。これらは進行を制御すべきテスト結果だった。

無線と車両ステータスは安全重要制御ループを形成した

システムのリソース状況は、隊員と車両からモバイル端末、無線インフラ、インターフェースソフトウェアを経て CAD に入り、動員メッセージを通じて戻ってくるループに依存していた。調査では、CAD が通信インフラに与える影響が適切かつ体系的に考慮されていなかったことが判明した。新しいシステムが既存の通信にどのように負荷をかけるかを示す正式な計算はなかった。完全実装後の無線ネットワーク容量のレビュー提案は、必要な順序を逆転させた。容量はサービスがそれに依存する前に示されなければならなかった。

運用環境は完全な通信を非現実的にした。ロンドンには無線不感地帯、移動する車両、ピーク時間が含まれていた。シフト変更時には、ログオンする隊員がチャネルを混雑させる可能性があった。失敗した、または遅延したステータス送信は、CAD に古い状況を残した。端末と中央画面は、確認ルーチンの問題のために不一致になる可能性があった。不確実性を解決するために使用される音声トラフィックは、それ自体が混雑を追加する可能性があり、音声を制限すると、誤った重複割り当てを露呈する人間のクロスチェックが除去される可能性があった。

自動車両位置情報にも類似の限界があった。都市部の送信と位置推定は、コンポーネントが広く使用可能であっても、時々誤る可能性があった。調査の将来志向の見解は、位置技術を放棄すべきということではなかった。CAD が、そのような技術が必然的に提供する不完全な位置情報を認識し、安全に処理しなければならないということだった。したがって、コンポーネント境界での信頼性には、コンポーネントが不確かにならないという約束ではなく、不確実性を認識したシステム応答が必要だった。

10月26日、音声通信を最小限にする指示は、成功したデータ動員の報告率を改善した。しかし、誤ったまたは複数の割り当ては、音声連絡なしでは修正される可能性が低かった。これは、局所的なメトリクスが正しい方向に動きながら、システムの安全性が悪化する理由を示している。成功とマークされたメッセージの増加は、管制が正しい状況を保持していることや、意図された隊員が実際に意図されたインシデントに向かっていることを証明しなかった。

同じ教訓は、隊員のステータス報告にも当てはまる。ボタンの連続押下は孤立したユーザー業務ではなかった。それはフィードバック制御の一部だった。訓練、インターフェース設計、インシデントプレッシャー、機器状態、通信カバレッジ、信頼がすべて影響を与えた。経営陣が不完全なステータスを主に労働力の行動として framing したとき、正しい報告を困難にするシステム条件と、報告が失敗したときに安全に劣化する設計義務を過小評価した。最前線のコンプライアンスは入力を改善できるが、入力が理想的でないたびに不安定になる設計を治すことはできなかった。

訓練とユーザーオーナーシップはシステムの一部だった

調査では、スタッフは概して情報技術を救急サービス改善に使用することに対して肯定的であることが判明した。彼らの自信の欠如は、現在のシステムとその導入方法に向けられていた。これは、自動化に原則的に抵抗する労働力という戯画を否定するため重要である。人々はロックされた画面、一貫性のない車両情報、失敗した送信、変更される手順を経験していた。不信は部分的には運用エビデンスに関する観察だった。

訓練は不完全で一貫性がなかった。一部は遅延実装のかなり前に行われ、使用前にスキルが低下することを許した。絶え間ないソフトウェア変更により、訓練教材と学習されたルーチンは不安定になった。管制室職員は異なる能力レベルに訓練されたが、カバレッジはばらつきがあった。隊員と管制室スタッフは主に別々に訓練されたが、成功した指令には各側が自身の行動が他方にどのように影響するかを理解する必要があった。調査は、両者が共有制御ループと各役割へのプレッシャーを理解できるように、共同要素を提案した。

完全実装はまた、物理的および社会的な運用環境を変えた。管制室は再構成された。リソース割り当て担当者は無線オペレーターおよび例外修正者から分離された。スタッフは、部分運用中に使用された紙のバックアップなしで、馴染みのない位置で働き、以前に問題を解決していた同僚へのアクセスが減少した。技術的に変更されていないアプリケーションが、新たに変更された作業システム内に配置された。古い部屋の配置をテストしても、新しいものを証明できなかった。

ユーザーオーナーシップは時として態度や変更コミュニケーションに還元される。このケースでは、より鋭い安全上の意味があった。ユーザーは、要件、端末設計、運用手順、リハーサル、受入において正当な役割を必要としていた。彼らは欠陥が解決されるのを見て、問題を報告することで期限が変更されることを信頼する必要があった。その権限がなければ、「buy-in」は既に行われた決定を支持するプレッシャーになる。

経営陣はまた、CAD が勤務慣行の変更を強制することを期待していた。これにはリソースの選択とステーションエリア間の移動が含まれる。調査は、システムを、スタッフが依然として局所的な柔軟性を試みる運用上の straitjacket と表現した。ソフトウェアは合意された変更をサポートできるが、合意を製造したり、状況知識を仕様で消去したりすることはできない。隊員が別の車両を取ったり、地元スタッフがより良いリソースを特定したりする場合、システムは有効な慣行に対応するか、機関が自動化がそれに依存する前に、協議、訓練、説明責任のある運用方針を通じて慣行を変更しなければならない。

10月26日と27日は狭い技術的クラッシュなしに失敗を生み出した

1992年10月26日07:00、LAS は初めて意図されたシステムの完全なロンドン全体での使用に移行した。コードは前の数週間で突然変更されていなかった。決定的な変更は運用上のものだった。すなわち、バックアップとしての紙の記録や起動ボックスなし、再構成された管制室、分離された役割、割り当ての基礎としての自動提案、通報受付担当者が一部のリソースを割り当てることができること。半手動運用中にスタッフが信頼性の低い情報を補うのに役立っていた制御が、一緒に除去された。

調査は、CAD システムもそのユーザーも準備ができていなかったと明確に述べた。ソフトウェアは不完全で、十分に調整されておらず、完全にはテストされていなかった。フルロードハードウェア耐性とセカンドサーバーへのフォールバックは未テストだった。モバイルデータ送信の問題は残っていた。自動位置情報への信頼は限定されていた。スタッフは全員完全に訓練されていなかった。設計は不正確または不完全な情報に対して十分にテストされていなかった。その状態でコンピュータ生成のリソース割り当てのみを使用することは、調査の判断では高リスクの決定だった。

活動が軽い初期負荷から増加するにつれて、システムはより少ない車両に対して正しいステータスと位置を保持した。新しい部屋とワークフローは人間による修正を困難にした。利用可能と思われるリソースが少なくなるにつれて、提案は不適切になり、検索はより遠くに及んだ。誤った、重複した、または遅延した割り当ては、より多くの例外を生み出した。カバーされた通報は、期待される状態シーケンスが完了しないと注意に戻った。キューが構築され、処理が遅くなり、メッセージは表示画面を超えてスクロールした。より多くの作業に直面するオペレーターは、根本的な状態を修復する余裕が減った。

公衆向けループはその後、内部ループを激化させた。遅延した、またはカバーされていないインシデントは、通報者が再度電話する原因となった。重複報告とコールバックは電話量を増加させた。少なすぎる通報受付担当者と遅くなるシステムは応答時間を延長し、それがさらなる通報と遅延を生成する可能性があった。調査は、10月26日と27日がインシデント数や患者輸送数において例外的に忙しかったという主張を否定した。見かけの増加の多くは、遅延への応答として生じた未確認の重複とコールバックから来ていた。

この経過は、一緒に維持されなければならない2つの声明を支持する。第一に、10月26日と27日には、狭い技術的意味ではコンピュータシステムはクラッシュしなかった。それは広く設計されたことを実行した。第二に、設計と運用の欠陥が蓄積され、サービスはシステム障害の症状、すなわち容認できない応答遅延を示した。コンピュータが「動き続けた」とだけ言うことは、プロセスの可用性を成功した緊急制御と誤認するだろう。技術的にクラッシュしたと言うことは、より教訓的な障害メカニズムを消去するだろう。

患者安全にとって、結果は裏付けのない死傷者の主張なしに明確である。緊急通報は遅延し、救急車の到着時間は時として容認できなくなり、管制スタッフはインシデントとリソースの信頼できる状況を維持できなかった。安全重要サービスはタイムリーな指揮エビデンスを失っていた。危険は害の最終的なカウントが確立される前に生じていた。患者と通報者は、助けが割り当てられたかどうか、それが移動しているかどうか、いつ到着するかについて不確実性にさらされていた。

したがって、切り替え決定は中心的な説明責任のゲートである。リーダーは、不完全なソフトウェア、未解決の重大な問題、通信の懸念、訓練のギャップ、不信、未テストのフォールバックについて知っていた。彼らはまた、パフォーマンスを改善するという正当なプレッシャーに直面していた。プレッシャーは早期の結果が魅力的である理由を説明する。それは準備状態を証明しない。決定の所有者は、発表された日付よりもエビデンスを優先する権限と、どの受入条件が満たされたかを示す記録を必要としていた。調査は、なぜこれほど多くの既知の不完全さをもって完全実装が進められたのか理解できなかった。

11月4日のクラッシュは別の障害だった

10月26日と27日の問題の後、制御は以前のものと広く同じ半手動の取り決めに戻った。通報と位置検索は依然としてコンピュータを使用し、インシデント詳細は印刷され、人間がリソースを特定し、動員には CAD、ステーションプリンター、モバイルデータを使用できた。音声チャネルは誤解の解決に役立った。スタッフはこの組み合わせに快適さを感じ、11月4日の早朝まで合理的に成功裏に運用された。

11月4日02:00過ぎに、システムは遅くなり、その後ロックした。調査はこの実際のクラッシュを、約3週間前に導入された軽微なプログラミングエラーに起因するとした。動員に関連するコードが少量のサーバーメモリを解放せずに消費し、繰り返し使用により利用可能なメモリを枯渇させた。調査は、コード変更の周りの不注意と不十分な品質保証を批判すると同時に、その障害は従来のプログラマーまたはユーザーテストだけでは発見される可能性が低いことも指摘した。

この区別は重要である。なぜなら、事例全体をそのエラーに還元することを防ぐからである。メモリ欠陥は10月26日と27日のフィードバックループを説明しなかった。また、一人のプログラマーに関する道徳物語になるべきではない。重要なサービスには、小さな局所的な欠陥が逃れる可能性があるからこそ、変更レビュー、独立した品質保証、監視、容量アラーム、復旧が存在する。説明責任は、なぜ一つの欠陥が検出されずにサービス損失に蓄積され、なぜ復旧がそれを封じ込めなかったのかにある。

バックアップサーバーへの自動切り替えは動作モードを維持しなかった。フォールバックは意図されたペーパーレスシステム用に指定されていたが、プリンターは当初の期限が過ぎた後、一時的な方便として追加されていた。プリンターベースの構成に対するサーバー障害の影響はテストされておらず、調査では自動フォールバック自体が適切に証明されたという記録は見つからなかった。クラッシュが発生したとき、スタッフは音声録音を使用して通報を処理し、完全に手動の紙ベースの制御に戻った。運用の混乱は、低い夜間負荷によって制限されたのであって、成功裏に実証された技術的復旧によってではない。

説明責任はゲートに対する実質的な管理に従った

サプライヤーは実装の詳細、コード品質、進捗報告、変更が主張通りに動作したというエビデンスを管理していた。それは規律ある構成管理と、スケジュールが能力を超えた場合の正直な開示を負っていた。しかし、サプライヤーはサービス全体を管理しておらず、すべての要件を選択せず、すべてのユーザーを訓練せず、無線資産を所有せず、CAD をロンドン全体の運用に配置する一方的な権限を持っていなかった。サプライヤーの説明責任は現実的で限定的である。

LAS エグゼクティブ経営陣は、野心、スケジュール、統合コンテキスト、前進の決定を管理していた。それは、紙と音声の安全策が利用可能かどうか、訓練が完了しているかどうか、運用が新しい手順を受け入れているかどうか、経験豊富な独立プロジェクトマネージャーと品質機能が関与しているかどうかを管理していた。経営陣がプレッシャーの下で懸命に働いていたという事実は、これらの管理を除去しない。それは、個人的なコミットメントが客観的な保証と誤認される可能性があるため、明確な準備基準をより重要にする。

プロジェクトと運用のリーダーシップは、コンポーネント報告をエンドツーエンドの主張に変換しなければならなかった。それは、未解決の問題、ソフトウェアバージョン、通信パフォーマンス、位置精度、人員配置、部屋構成、フォールバック結果を調整することを意味した。指名された切り替え権限者は、そのエビデンスを見て、独立した技術的およびユーザーの異議を聞き、遅延する明確な権利を持っていなければならなかった。もし誰もシステム状況と停止権限の両方を持っていなければ、すべての参加者が別の参加者が残存リスクを所有していると想定するため、プロジェクトは前進できる。

LAS 取締役会はガバナンス監視を管理していた。調査では、取締役会が関連するサプライヤー経験について誤解を招く安心感を受け取り、不利な参照情報を受け取らなかったことが判明した。より広く言えば、独立したレビューがプロジェクトの真の状態をテストしないまま、経営陣の保証を受け入れていた。取締役会の説明責任は、メンバーがプログラミングツールを選択することを要求しなかった。それは、先駆的な緊急制御システムに独立した保証、現実的な負荷結果、テストされたフォールバック、明示的な未解決リスクがあるかどうかを尋ねることを要求した。

South West Thames RHA は LAS をアームズレングスで管理していた。正式な調達規則は守られ、LAS は地域の技術支援を求めなかった。しかし、RHA は繰り返し懸念に直面し、それらが解決されるという保証を受け入れていた。調査は、説明責任の線は紙の上では安全に見えたが、取締役会や地域がその責任を行使するのに十分な情報を生み出さなかったと結論づけた。委任されたサービスが安全重要である場合、アームズレングスの監視はエビデンスからの距離を意味することはできない。

大臣の責任は別のレベルで機能した。議会は主要な技術調査機関ではなく、政党論争中の発言はソフトウェア因果関係に関する発見として扱われるべきではない。ハンサードは公的説明責任の連鎖を示している。10月28日、国務長官は直接音声サポート、外部調査、RHA および NHS 管理を通じた暫定 LAS リーダーシップからの定期的な報告を発表し、大臣が情報を得られるようにした。調査が1993年2月に報告した後、彼女は大臣への説明責任が十分に強固かどうか疑問を呈し、それを強化する提案を求め、IT ディレクターと段階的 CAD 実装の計画に言及した。

最前線のスタッフは、ステータスの報告や動員への応答などの特定の行為を管理していたが、調達、テスト範囲、部屋設計、切り替えに対する同等の管理権を共有していなかった。彼らの経験はまた、リーダーが使用する必要のあるエビデンスだった。隊員を単に抵抗的として扱うことは、端末、無線メッセージ、運用適合性に関する警告を行動の物語に変換した。説明責任は、実行可能な手順に従うユーザーの義務と、通常の人的および通信エラーが発生した場合に手順と技術が安全であることを証明する経営陣の義務を区別することを要求する。

患者安全リスクには発明された死者数は必要ない

ロンドンの事例は、遅延した救急車に起因する特定の死者数とともにしばしば再話される。調査はより厳密な境界を提供する。遅延が死亡を引き起こしたかどうかを決定できるのは検死官裁判所のみであり、当時検討された事例では、検死官裁判所が救急車の遅延到着が患者の死亡を引き起こしたと結論づけたことはないと述べた。1993年2月の議会応答もその立場を繰り返した。

その発見は、「誰も死ななかった」、「誰も害を受けなかった」、「失敗は無害だった」に拡大されてはならない。それは検死官が因果関係について結論づけたことに関する声明であり、すべての結果の国勢調査ではない。調査はまた、応答、派遣、到着の遅延によって引き起こされる苦痛を強調した。それは容認できない応答パフォーマンスと低下した救急サービスを記録した。これらは患者安全分析の十分な根拠である。

安全説明責任は、証明された致命的なエンドポイントだけでなく、制御されていないリスクへの曝露から始まる。制御がインシデントがカバーされているかどうか、動員が重複または遅延しているかどうか、または以前の通報者に信頼できる回答がないために通報が蓄積しているかどうかを知らない場合、リーダーは患者を保護するために必要なエビデンスを失っている。不確実性自体が運用上重要である。機関がそれを調査し修復する前に、後の法的または臨床的因果関係の発見は必要ない。

慎重な死傷者言語はまた、因果分析を改善する。劇的な犠牲者数は、最も感情的に顕著な申し立てに注意を引き、明らかに文書化された管理から遠ざける可能性がある。調査は、混乱した通報、容認できない遅延、信頼性の低い割り当て、公衆の苦痛、損なわれた信頼の堅牢な説明を支持する。これらの発見は、申し立てを事実に変換することなく、準備の失敗を深刻なものにする。

フォールバックと切り替え権限はガバナンス管理だった

LAS の経験は、継続性計画がプライマリシステムと並行して設計されなければならない理由を示している。紙のバックアップ、音声連絡、ステーション知識、手動割り当ては、単に技術の外で待機している古い方法ではなかった。部分運用中、それらは人々が悪い状態を検出し、判断を行使し、インシデントを可視化することを可能にした。それらを除去することは、サービス全体の障害耐性を変えた。その変更には独自の受入ケースが必要だった。

劣化モードは、何がそれをトリガーするか、誰がそれを宣言するか、どの機能が継続するか、進行中のインシデントがどのように調整されるか、スタッフがどの記録が権威あるかをどのように知るかを明記しなければならない。それは現実的な負荷でリハーサルされなければならない。サーバーの切り替えは一つの層にすぎない。プリンター、端末、キュー、作業割り当てが切り替え後に異なる動作をする場合、技術的可用性は指揮を維持しない可能性がある。スタッフが完全なインシデントリストを回復できない場合、ハードウェアがオンラインであってもフォールバックは失敗している。

切り替え権限は、それらの管理が拘束力を持つポイントである。決定は事前定義されたエビデンスに照らして行われるべきである。深刻なサービス劣化が可能な未解決の問題がないこと、安定した構成、フルロード統合テスト、無線、位置、端末にわたる障害注入、現在役割の訓練と観察された能力、ユーザーおよび運用受入、人員配置された例外容量、手動または半手動モードへの移行と復帰の実証。満たされていない条件には、指名されたリスク所有者と、なぜ曝露が許容されるかの記録された理由が伴うべきである。

権限はまた、組織的罰なしに停止できなければならない。調査は、期限が硬直的で挑戦しにくいと認識されていた文化を説明した。組織図にのみ存在するノーゴールートは運用制御ではない。リーダーは技術的および最前線の異議を保護し、異議の文書化された処分を要求し、公的な日付やサンクコストが黙って受入しきい値を変更するのを防ぐ必要がある。

修復エビデンスは自動化が権限を獲得できることを示した

調査の CAD に関する最初の推奨は、LAS がコンピュータ支援指令システムの計画を継続すべきであるというものだった。それは、救急サービスを改善できる技術への unanimous support を発見し、紙のプロセスを非効率的と説明した。その将来計画は、合意された組織構造と手順に適合したシステム、信頼性と耐性がありテストされたバックアップを持つシステム、経営陣とスタッフが所有するシステム、協議、品質保証、テスト、訓練を可能にするスケジュールで導入され、段階的に展開されるシステムを要求した。

提案されたシーケンスは、権限の増加を証明の増加に結びつけた。暫定的な第一フェーズは、ソフトウェア品質レビュー、テスト、より強力な印刷、再訓練の後にのみ、コンピュータ通報受付と地名辞典機能を復元できた。インシデント詳細は人間の割り当て担当者に利用可能のまま残された。第二フェーズは、信頼性の高い車両位置とステータスを利用可能にするが、人間の割り当て担当者が依然としてリソースを選択する。それは専門的な通信レビューとインフラへのより良い自信を必要とした。

そのフェーズの受入と経験の後でのみ、動員は音声からモバイルデータに移行する。コンピュータリソース提案はまず人間の割り当て担当者への提案となる。通報受付担当者は、提案、通信、根本的な状態が自信を得た場合にのみ、割り当て権限を受け取る。すべての段階で、耐性、コンティンジェンシープランニング、フォールバックは、絶え間ないサービスの必要性に一致しなければならなかった。これはそれ自体のための遅い納品ではなかった。各フェーズは、次の依存関係が追加される前に、ライブ条件下で観察できる主張を隔離した。

ガバナンス修復は技術的段階分けに伴った。調査は、経験豊富なプロジェクトマネージャー、サービス全体の代表を持つ取締役会プロジェクト小委員会、経験豊富な外部者の可能な助言、取締役会への直接アクセスを持つ IT ディレクターを推奨した。また、より良い定性的調達ガイダンス、通信レビュー、公的機関およびロンドン議員への応答パフォーマンスの公開報告も求めた。これらの措置は、権限がエビデンスを見て行動できる場所にエビデンスを置いた。

ハンサードはその修復の公的側面を記録している。1993年2月、政府は IT ディレクターが段階的実装を監督し、LAS から RHA を経て大臣へのより強力なラインを求めると述べた。10月、書面回答は、効果的な情報システム調達に関する新しい NHS ガイダンスと、将来の CAD を含む調査勧告の実装に関する定期的な地域報告を報告した。議会の声明はすべての修復が機能したことを証明しないが、技術的準備が制度的監視の明確な事項になったことを示している。

後の査読付きケーススタディは、はるかに成功した LAS CAD 実装をターンアラウンドとして説明した。その比較は、ユーザーニーズへの経営陣の注意、ユーザーの関与、より多くのリソース、受入によって駆動されるよりリラックスしたタイムライン、自信を構築するインフラプロジェクト、参加とプロトタイピング、徹底的なテスト、段階的でシンプルな実装、信頼構築を特定した。これらの発見は、後のプログラムの二次分析であり、1992年の調査報告の代わりではない。

また、一つの介入が後の成功を引き起こしたことを証明しない。組織的ターンアラウンドには多くの影響があり、後の条件は異なっていた。それらの価値は比較にある。後の実装は、問題があったほぼすべてのカテゴリーに対処していた。対比は、修復がスローガンではなく運用条件で表現されたときにどのように見えるかを示している。ユーザーが参加する。インフラが自信を得る。テストは徹底的である。最初の実装はよりシンプルである。タイミングは受入に従う。信頼は提供されたエビデンスを通じて成長する。

制度的正当性は観察可能な指令状態に依存する

緊急サービスは、公衆が検査できない決定を信頼するよう求める。通報者は割り当てキュー、無線交換、ステータスデータベースを見ることはない。したがって、制度的正当性は、サービスが内部的に証明し、公的に説明することに依存する。すなわち、それらの隠されたメカニズムが信頼できる指揮を維持することを。サービスが救急車が本当に利用可能かどうか、または動員が届いたかどうかを伝えられないとき、信頼は理由をもって失敗する。

説明責任は障害後の集団的責任ではない。それは、エビデンスを生成し、挑戦し、行動するための事前の任務の割り当てである。実装者はコンポーネントを証明する。統合者はサービスを証明する。運用は作業が実行可能であることを証明する。リーダーシップは時間、リソース、停止権限を保護する。取締役会は独立して準備状態を検証する。監視機関は透明なパフォーマンスと修復を要求する。

ロンドン救急サービスは、指令自動化がサービスの状況が依然として脆弱である間に権威を持つことを許されたため、CAD を患者安全の説明責任テストにした。耐久性のある答えはコンピュータを拒否することではなかった。権限を条件付きにすることだった。すなわち、自動化は、機関が負荷下でどのように真実を保つか、人がそうでないときにどのように回復するか、誰がエビデンスが不足したときに停止する力を持つかを示すまで、実際の通報、隊員、救急車を制御しない。

概況