軟體不是危害：拆解 IEC TR 80002-1 的風險評估邏輯
當校正通知「軟體延遲」，FDA 卻列為最高風險等級
2025 年 3 月，Becton, Dickinson and Company（BD）針對旗下 Alaris 輸液幫浦系統的 Systems Manager 與 Care Coordination Engine（CCE）Infusion Adapter 軟體發出更正通知。更深入去看問題，來自於系統回應延遲，導致自動排程請求（APR）在佇列裡累積，使用者可能看到過期的劑量或速率參數被載入幫浦。
FDA 把這起更正案列為 Class I，也就是最嚴重的等級。雖然截至公告當時沒有任何受傷或死亡通報，但 FDA 認定持續使用未更正的軟體「可能造成嚴重傷害或死亡」。
風險矩陣是為機械設計的，不是為程式碼
ISO 14971 的風險評估架構，骨子裡是為了機電產品設計的：找出可能失效的元件，估計它的失效機率（通常有歷史故障率或加速老化測試可以參考），再乘上失效後果的嚴重度，得出一個風險分數，決定要不要進一步做風險控制。這套邏輯在馬達、電池、機械結構上運作得很好，因為這些東西會磨損、會疲勞、失效模式相對有限，長期使用資料也累積得夠多。
軟體完全不是這麼回事。程式碼不會磨損，昨天測試一百萬次都正常的功能，今天在某個特定的資料組合下還是可能出錯—不是因為它「老化」了，而是因為那個特定路徑之前沒被觸發過。TR 80002-1 明講，軟體異常「不會像硬體那樣隨機發生」，因此傳統的失效機率估算方法在軟體上站不住腳。這也是為什麼很多 QA/RA 團隊拿著行之有年的風險矩陣範本硬套進軟體專案時，會發現「發生機率」那一欄永遠填不出讓人信服的數字，最後只能憑感覺打分。
危害、事件序列、危害情境：TR 80002-1 拆解的三段式邏輯
TR 80002-1 :2009 引用 ISO 14971 對 HAZARD（危害）與 HARM（傷害）的定義，並補上一個關鍵中間環節：危害要變成傷害，中間一定要經過「事件序列」，把人暴露在危害之下，形成「HAZARDOUS SITUATION（危害情境）」。順序是：危害存在 → 一連串事件發生 → 形成危害情境 → 造成傷害。電能、熱能、懸吊重物是典型的危害，因為它們本身具備物理傷害能力，接觸到就可能受傷。
軟體不符合這個定義。接觸軟體本身不會讓人受傷，所以軟體不是危害。但軟體常常是那個把既有危害轉變成危害情境的「事件」。80002-1舉了一個眼科植入物的例子：危害是電能，如果控制電流的軟體演算法有限制、或軟體本身出現異常，就可能讓輸出電流過高，病患的眼睛因此暴露在過高電流下（危害情境），造成嚴重灼傷甚至失明（傷害）。電能這個危害本來就存在於裝置設計裡，軟體只是那個觸發序列的環節。
軟體異常估不出機率，所以風險評估要換一把尺
TR 80002-1 給的建議並不是「放棄估算機率」，而是把重心換到「盡可能找出軟體會以哪些方式異常、進而促成危害情境」，然後主要依傷害的嚴重度來決定風險等級與控制優先順序。這代表風險分析要花更多力氣在異常辨識，例如可以使用故障樹分析（FTA）來分析：雖然 FTA 本身不呈現事件序列，但可以用來標示出哪些節點如果被正確的風控措施擋下，就能阻止危害情境成立。
風控措施要分層：設計、防護、資訊
找出異常路徑之後，TR 80002-1 沿用 ISO 14971 的三層風控優先順序：本質安全設計優先於防護措施，防護措施優先於安全資訊。
落到軟體上，本質安全設計包括拿掉不必要的功能、簡化架構以避免容易導致危害情境的事件序列、限制記憶體配置方式、使用受限的程式語言結構；防護措施則強調獨立性，例如治療功能與防護功能分別跑在不同處理器上，避免同一個故障同時擊倒兩者；安全資訊則是最後一道防線，包括畫面警示、使用手冊、教育訓練。
給開發團隊的提醒：矩陣matrix不是萬能
不少醫材軟體團隊在建立風險管理檔案時，習慣沿用公司既有的硬體風險矩陣範本，只是把「元件失效」改成「軟體異常」，機率欄位還是要求填一個數字。TR 80002-1 提醒的方向，是把「填機率」轉向「畫出從異常到危害情境的路徑」，產出的風控措施會更貼近實際的失效模式。
值得一提的是，IEC 62304（軟體生命週期流程標準）目前正在進行 Edition 2 的大幅修訂，根據已流出的草案內容，新版把風險管理的定位進一步拉高到產品／系統層級，而不是內建在軟體開發流程裡，呼應的正是 TR 80002-1 十幾年前就在講的邏輯，軟體本身不是危害，風險管理不能脫離系統整體來看。
新版標準的細節仍可能在正式發布前調整，但這個方向說明了一件事：「軟體不是危害，而是促成危害情境的事件」這套判斷邏輯，仍然是目前業界持續在強化的核心原則。
參考來源：
IEC/TR 80002-1:2009, Medical device software – Part 1: Guidance on the application of ISO 14971 to medical device software — IEC Webstore：https://webstore.iec.ch/en/publication/7488
FDA — Infusion Pump Software Correction: Becton, Dickinson and Company (BD) Issues Correction for BD Alaris Systems Manager and Care Coordination Engine Infusion Adapter Software（2025/3/20）：https://www.fda.gov/medical-devices/medical-device-recalls-and-early-alerts/infusion-pump-software-correction-becton-dickinson-and-company-bd-issues-correction-bd-alaris
ISO 14971:2019, Medical devices — Application of risk management to medical devices — ISO.org：https://www.iso.org/standard/72704.html
IEC 62304 Edition 2（2026 草案）風險管理定位變化相關報導 — Sensaco：https://sensaco.com/iec-62304-edition-2-2026-process-rigor-levels-and-alignment-with-risk-cybersecurity-ai-explained/
BD Alaris更正案媒體報導（發布日：2025/3/24）— 24×7 Magazine：https://24×7mag.com/standards/fda-updates/recalls/bd-issues-correction-infusion-pump-software/
