當牆壁被打穿時 — Safety-II 如何改變我們設計醫療系統的方式

兩種安全觀

想像你在設計一間醫院的藥局系統。傳統做法是列出所有可能出錯的地方，然後逐一設防：

• 藥品可能發錯 → 加一道掃碼確認
• 劑量可能算錯 → 加一道自動檢查
• 病人可能認錯 → 加一道身份核對

這叫 Safety-I：找出失敗模式，建立防線。它有效，幾十年來拯救了無數生命。

但它有一個盲點：它只研究出錯的 5%，忽略了做對的 95%。

2014 年，丹麥安全科學家 Erik Hollnagel 提出了一個不同的框架——Safety-II。它問的問題不是「事情怎麼會出錯」，而是：

在資源不足、壓力爆表、流程被打亂的情況下，人們是怎麼成功完成工作的？

答案往往不是「因為他們遵守了 SOP」，而是「因為他們即興調整了」。Safety-II 的核心洞察是：安全不是防線的厚度，而是系統適應變化的能力。

在災難現場，Safety-I 不夠用

我們在設計 xGrid 時，一開始也是 Safety-I 思維：加確認、加檢查、加防線。直到我們跑了第一次全場景演練，才意識到問題。

場景：三個醫療站同時撤離。撤離當下——

• 有病人正在輸血，血品監管鏈不能斷
• 有手術正在進行，必須中斷、轉運、在新站恢復
• 有藥品正在站間轉運，需要重新分配到倖存的站

Safety-I 的思路是「防止撤離發生」或「確保撤離不會在這些時間點發生」。但在真實災難中，你無法控制什麼時候要撤。砲彈不會等你手術做完。

我們需要的不是更厚的牆壁，而是當牆壁被打穿時，幫助人們繼續完成任務的能力。

這就是 Safety-II。

xGrid 的四個 Safety-II 設計原則

原則一：誠實的不確定性

大多數系統會把「不知道」藏起來。庫存數量三天沒同步？畫面上還是顯示上次的數字，沒有任何警示。使用者以為資料是即時的，根據過期資料做了決定。

xGrid 不這麼做。我們在資料上標記新鮮度（freshness metadata）。超過閾值沒同步的資料，畫面上直接標示 stale（過時）。護理師看到「過時」二字，會知道要做額外確認——去現場數一下、打電話問一下、掃 QR code 同步一下。

顯示「我不確定」比顯示一個可能錯誤的數字更安全。

這是 Safety-II 的典型設計：不是消除不確定性（你做不到），而是讓不確定性可見，讓人類可以基於正確的資訊做判斷。

原則二：優雅降級，保留安全門檻

斷網了。三台站掛了。緊急模式啟動。

很多系統在緊急模式下會做兩件事之一：要嘛整個停擺（「請聯繫 IT 部門」），要嘛完全放飛（關掉所有檢查以求速度）。兩者都是危險的。

xGrid 的緊急模式走中間路線：簡化操作路徑，但保留關鍵確認步驟。

具體來說：

• 非必要的欄位可以跳過（地址、保險號碼、過敏細節）
• 但病人身份確認 → 保留
• 藥品名稱和劑量確認 → 保留
• 血品交叉配對確認 → 保留

邏輯是：在壓力下，人們會自然地想跳過步驟來加快速度。系統的職責不是阻止他們加快速度，而是確保他們在加快速度時不會跳過致命的步驟。

原則三：為學習而紀錄，不是為究責

xGrid 記錄每一次交班（ISBAR handoff）、每一次轉運、每一次藥品發放、每一次庫存異動。紀錄的顆粒度很細，細到你可以重建整個事件的時間線。

但這些紀錄的目的不是「出了事好追究」。Safety-II 框架裡，紀錄的目的是從日常成功中學習。

為什麼那次撤離這麼順利？紀錄顯示，護理師在撤離前 3 分鐘就先把血品資料掃進手機了。這不在 SOP 裡，但她的即興判斷救了 15 分鐘。下次我們要不要把這寫進 SOP？

Safety-I 只在出事後才去翻紀錄。Safety-II 在一切順利時也翻紀錄——因為成功的原因和失敗的原因一樣值得研究。

原則四：破窗授權（Break-Glass）

正常流程：藥品發放需要醫師處方 → 藥師確認 → 護理師核對 → 發藥。三道關卡，非常 Safety-I。

災難現場：醫師在處理大量傷患，開不出電子處方。藥師在另一個站。護理師手上有一個正在失血的病人，需要止血藥，現在。

如果系統堅持「沒有處方就不能發藥」，結果就是護理師繞過系統（在紙上寫、口頭喊、直接從藥櫃拿），然後系統裡什麼紀錄都沒有。

xGrid 提供 24 小時緊急覆寫模式。護理師可以啟動緊急授權，系統會：

1. 允許操作繼續
2. 記錄「此操作使用緊急授權」
3. 標記為待審核

不是繞過安全，而是承認現實。在災難現場，標準流程有時就是行不通。Safety-II 的態度是：與其假裝人們會遵守所有規則，不如設計一個讓「打破規則」也能被安全記錄和追蹤的機制。

Patient I：34 步驟，零資料遺失

理論講完了，來看數據。

我們的 E2E 測試套件中有一個場景叫 Patient I — Consolidation Test，專門測試 Safety-II 原則在最壞情況下的表現：

設定：8 個醫療站，3 個被迫撤離。撤離同時進行中的操作：

• 血品輸注（監管鏈不能斷）
• 手術進行中（需要中斷、ISBAR 交班、轉運、在新站恢復）
• 藥品站間轉運（需要重新分配）

驗證結果：

檢驗項目	結果
病人身份跨站保留	通過
血品監管鏈完整 + 新站交叉配血	通過
手術在新站恢復 + 完整 ISBAR 紀錄	通過
庫存跨站對帳	通過
總計：34 步驟，34 通過，0 資料遺失	通過

這就是 Safety-II 在真實（模擬）場景中的價值：不是「防止撤離」，而是讓撤離順利完成。

Safety-II 不是取代 Safety-I

最後一個重要的澄清：Safety-II 不是說「不要防線了」。掃碼確認、劑量檢查、身份核對——這些 Safety-I 的防線仍然重要，xGrid 全部都有。

Safety-II 是在 Safety-I 之上，加了一層：當防線不夠用時，系統怎麼幫助人們適應？

xGrid 兩者都做。但如果只能選一個——在災難現場，我們選 Safety-II。

因為在那種環境裡，牆壁一定會被打穿。問題不是能不能撐住，而是穿了之後怎麼辦。

---

延伸閱讀：閃人測試 — 如果開發團隊明天消失，你的系統還能活嗎？