壁が破られたとき — Safety-IIで医療システムを設計する

無視されている95%

2014年、Erik Hollnagelは安全科学者の思考を静かに変えた一冊の本を出版しました^[1]。彼の主張はシンプルでありながら示唆に富んでいました。安全の分野は、物事がうまくいかない少数のケースを何十年も研究してきた一方で、物事がうまくいく圧倒的多数のケースをほぼ完全に無視してきたというものです。

彼は従来のアプローチをSafety-Iと呼びました。故障モードを特定し、防御を構築し、悪い結果を防ぐという手法です。すべてのチェックリスト、すべてのフェイルセーフ、すべての「本当にいいですか？」ダイアログの基盤です。そしてそれは機能します。機能しない場合を除いて。

代替案であるSafety-IIは、異なる問いから出発します。物事がなぜ時々失敗するかではなく、なぜ通常は成功するかを問うのです。その答えは「良い防壁を築いたから」ではありません。「人々が適応するから」です。看護師は臨機応変に対応します。医師はプロトコルが合わないときにプロトコルから逸脱します。物流スタッフは誰も計画していなかった回避策を見つけます。

Safety-Iはこの変動を問題として扱います。Safety-IIはそれをレジリエンスの主要な源泉として扱います。

Safety-I思考を打ち砕いたシナリオ

私たちはxGridを開発していました。Raspberry Piデバイス上でオフライン動作する災害医療ロジスティクスプラットフォームです。開発初期のデザインは完全にSafety-I的でした。バーコードスキャン、本人確認、複数段階の確認ダイアログ、ロールベースのアクセス制御です。

そして私たちは机上演習を実施しました。シナリオは次の通りです。

8つの医療ステーションのうち3つが同時に避難を強いられます。避難の瞬間、以下の作業が進行中でした：

• 厳格な監視連鎖（chain of custody）が求められる輸血
• 中断して別の場所で再開しなければならない手術
• ステーション間を輸送中で再配分が必要な医薬品

私たちのSafety-Iシステムは個々のチェックを問題なく処理しました。処理できなかったのは、状況そのものでした。システムは安定した運用条件を前提としていました。現実はその正反対を突きつけました。

通常条件でエラーを防ぐだけでなく、異常条件で人々が成功することを積極的に支援するものが必要でした。

学んだ4つの原則

1. 不確実性を見える化する

ソフトウェア設計における本能は、クリーンで自信に満ちた情報を提示することです。修飾語のない数値。緑か赤かのステータスインジケーターで、黄色は決して使いません。

災害シナリオにおいて、この自信は危険です。在庫データが3日間同期されていない場合、最後に確認された数量をあたかも最新のように表示すれば、誤った判断につながります。看護師はシステムが12単位と表示しているため、実地棚卸を省略するかもしれません。実際には4単位かもしれません。

xGridはすべてのデータポイントに鮮度メタデータ（freshness metadata）を付与します。同期が閾値を超えると、インターフェースにstale（古い）マーカーが明示されます。これはバグの表示ではありません。正直さのシグナルです。オペレーターに「この数値は間違っている可能性があります。行動する前に確認してください」と伝えます。

不確実性を認めるシステムは、それを隠すシステムよりも信頼に値します。ユーザーは、データを信頼すべきでないときにそう教えてくれるからこそ、システムを信頼するようになります。

2. 許容的ではなく、優雅に機能低下させる

システムが緊急モードに入ると、設計者はジレンマに直面します。すべてをロックダウンして重要な業務をブロックするリスクを取るか、すべてを開放してエラーのリスクを取るか。

ほとんどのシステムはどちらか一方の極端を選びます。xGridはどちらも選びません。

緊急モードでは、必須でない入力項目を省きます。住所欄、保険番号、詳細なアレルギー文書 — すべてスキップ可能です。しかし、3つの確認ステップはシステムの状態にかかわらず必須のままです：

• 患者の本人確認
• 薬品名と投与量の確認
• 血液製剤の交差適合試験（cross-match）の確認

設計哲学は次の通りです。プレッシャー下の人々は自然にステップを飛ばします。これは人間の行動の欠陥ではなく、適応です。システムの役割は、待てるステップを飛ばすことを許可しながら、待てないステップを飛ばすことを不可能にすることです。

3. 記録は学習のために設計する、責任追及のためではなく

xGridにおけるすべてのハンドオフは記録を生成します。すべての調剤、すべての転送、すべての在庫移動です。データは完全なイベントタイムラインを再構成できるほど詳細です。

しかし私たちは、ほとんどの監査システムが見落としている特定の目的のために記録システムを設計しました。成功から学ぶことであり、失敗からだけではありません。

あるケースを考えてみてください。特に円滑な避難の後、記録は、ある看護師が避難命令の3分前に血液製剤データを自分のスマートフォンに先行してスキャンしていたことを示していました。これはどのプロトコルにもありませんでした。臨機応変な判断でした。そしてそれは受入ステーションでの再スキャンを15分短縮しました。

Safety-Iはこれを決して発見しません。なぜならSafety-Iは何かが間違ったときにのみ調査するからです。Safety-IIは日常的に調査します。成功の原因は失敗の原因と同じくらい理解する価値があるからです。その看護師の臨機応変な対応は、現在推奨ワークフローの一部となっています。

4. ルールを破る合法的な方法を提供する

通常の調剤プロセス：医師が処方し、薬剤師が検証し、看護師が確認し、調剤する。3つのゲート。堅実なSafety-Iです。

災害の現実：医師は20人の患者をトリアージ中。薬剤師は別のステーション。患者は出血中。看護師は止血薬を今すぐ必要としています。

もしシステムが「処方なし、調剤なし」と言えば、看護師はそれを回避する方法を見つけます。紙のメモ、口頭指示、薬品棚への直接アクセスです。薬は投与されます。システムには何も記録されません。

xGridは24時間緊急オーバーライド（break-glass）を提供します。看護師は緊急認可を発動できます。システムはその行動を記録し、緊急認可済みとタグ付けし、レビュー対象としてフラグを立てます。完全な監査証跡とともに業務は続行されます。

これは安全性の回避ではありません。安全性の機能です。システムが最も危険なことは、人々をシステムの外で働くよう強いることです。なぜならそうすると、すべての可視性が失われるからです。合法的で記録されたルール違反は、見えない回避策よりも無限に安全です。

検証結果：Patient I

私たちのE2Eテストスイートには、Patient I — 統合テスト（Consolidation Test）が含まれています。最も厳しい条件で検証するよう設計されています。

設定：8ステーション、3ステーションが同時に強制避難。避難中の状況：

• 輸血中（監視連鎖を維持する必要あり）
• 手術進行中（中断し、ISBARハンドオフで記録し、搬送し、再開する必要あり）
• ステーション間で医薬品輸送中（残存ステーションへの再配分が必要）

結果：

検証項目	結果
転送を通じて患者のアイデンティティが保持された	合格
血液の監視連鎖が維持され、新ステーションで交差適合試験を実施	合格
完全なISBARハンドオフ記録とともに手術が再開された	合格
統合されたすべてのステーション間で在庫が照合された	合格
34ステップ実行、34合格、データ損失ゼロ	合格

これが実践におけるSafety-IIの姿です。シナリオは「避難を防ぐ」ことではありません。それは不可能です。シナリオは「避難を成功させる」ことです。すべてのデータポイントが生き残りました。すべてのハンドオフが記録されました。すべての安全ゲートが重要な箇所で保持され、必要な箇所では譲歩しました。

代替ではなく補完

Safety-IIは防壁に反対するものではありません。xGridには依然としてバーコードスキャン、本人確認、投与量チェック、ロールベースのアクセス制御があります。これらのSafety-Iメカニズムは、予防可能なエラーを防ぎます。

Safety-IIはそれ以外のすべてを扱います。条件が通常の手順には劣悪すぎる場合、プロトコルが存在しないリソースを前提としている場合、教科書の答えが目の前の状況に合わない場合です。

安定した環境では、Safety-Iは通常十分です。災害環境では、それは必要ですが十分ではありません。

壁は必ず破られます。重要なのは、その後に何が起きるかです。

---

関連記事: ウォークアウェイテスト — 開発者がいなくなっても生き続けるソフトウェアの設計

---

参考文献

1. Hollnagel E. Safety-I and Safety-II: The Past and Future of Safety Management. Ashgate Publishing; 2014. DOI