在昨天的文章中，我們介紹 IEC 62304 軟體安全等級，評估產品在預期使用及可合理預見的使用情境中，可能如何造成傷害。不過，我們在軟體開發時，會發現軟體的運行有問題、不符合規格，我們通常稱為 bug ，需要先說明的是列出軟體的風險，並不是與找出軟體的 Bug 相同，這兩件事情指的是不同的事情。
軟體的 Bug，指的是軟體的問題，而醫療軟體的風險管理指的是需要管理如果軟體出問題時會造成的危害。換句話說，軟體的 Bug 可以看作是軟體沒有按照規劃的設計執行，沒有產生出預期的結果，我們需要將其修正成符合規格。但是風險管理則是，我們評估這個軟體在使用時，若遇到某些情境，是否會危害使用者。
範例：一個 SaMD App 匯入體溫時，把華氏數值當成攝氏數值顯示。「單位處理錯誤」是軟體問題。如果匯入時就擋下資料，事件不會走到使用者面前；如果畫面把錯誤數值當成有效紀錄顯示，使用者又依此理解身體狀態，就形成值得分析的危害情境。後續是否造成傷害，還取決於使用者如何依賴資訊、是否重新量測，以及有沒有其他防護。
可以用一條因果鏈整理：
起始事件／失效 → 事件序列 → 人員暴露於危害的情境 → 可能傷害
風險分析不能把「Bug = 傷害」，也不能因為尚未收到傷害通報，就認定風險不存在。ISO 14971:2019 提供醫療器材風險管理的完整過程，涵蓋風險識別、估計、評估、控制及上市後資訊；若本產品適用該標準，仍須依實際預期用途與組織程序執行。
假設情境：外部資料標示體溫為華氏，App 卻當成攝氏值保存或顯示。具體數字、合理範圍和臨床後果仍須依產品、裝置與使用情境確認。
| 要問的事 | 此案例的初步答案 |
|---|---|
| 起始事件 | 匯入流程錯讀或遺失體溫單位。 |
| 事件序列 | 華氏值被當成攝氏值保存或顯示 → 畫面未揭露單位錯誤 → 使用者相信該數值有效。 |
| 危害情境 | 使用者依賴單位錯置的紀錄理解身體狀態或變化趨勢。 |
| 可能傷害 | 在需要重新量測或尋求協助的情境中採取不適當行動；是否成立，仍須依使用情境確認。 |
| 可考慮的控制 | 匯入時同時處理數值與單位；僅轉換支援的單位；缺單位或不支援時標示不可判讀，不納入趨勢。 |
| 查證方式 | 用攝氏、華氏、缺單位、不支援單位及轉換邊界的合成資料測試匯入、保存與顯示。 |
| 這張表比「修正單位 Bug」多了兩件事：指出何時會讓人誤解，並把控制措施變成可以查證的行為。測試通過只能證明指定行為做到了；實際使用者是否能理解「不可判讀」，還要在預期使用情境中評估。 |
下表的候選風險路徑。每列都要回頭核對真實產品宣稱、使用者任務、裝置特性及資料流；控制措施也只是設計候選，尚未實作或驗證。這裡不用任意填入「高／中／低」分數：風險估計與可接受準則必須先由產品的風險管理計畫定義，軟體失效機率也不宜憑空量化。IMDRF 指出，軟體錯誤輸出可造成直接或間接傷害，且軟體失效機率的量化方法尚無廣泛共識。IMDRF 軟體風險文件，§5.2
| ID／起始事件 | 事件序列 → 危害情境 → 可能傷害 | 候選控制措施 | 後續查證方式 |
|---|---|---|---|
| R-01 單位誤配 | 匯入值與單位不一致 → 畫面呈現錯誤數值語意 → 使用者誤讀趨勢 → 可能作出不適當的後續決定。 | 輸入資料同時保存數值、單位與來源；只接受支援的轉換；不明單位拒收或標示不可判讀。 | 用支援／不支援單位、缺單位及轉換邊界資料測試；核對顯示值與原始資料。 |
| R-02 時間錯誤 | 量測時間錯置 → 舊紀錄看似最新 → 使用者依賴過時資料 → 可能延誤更新量測或適當協助。 | 保留量測時間與同步時間；時間不可信時清楚標示，且不以「最新」排序。 | 跨時區、改時鐘、延遲同步案例；檢查資料順序與不可信狀態。 |
| R-03 病人誤配 | 上傳時綁錯帳號或在切換使用者後沿用前一人的資料 → 他人紀錄出現在目前病人頁面 → 照護者依錯誤對象理解趨勢 → 可能延誤正確對象的照護。 | 寫入時驗證病人識別與授權；切換對象時清除舊畫面狀態；顯示紀錄所屬對象與來源。 | 兩名合成病人交錯上傳、切換及重試；檢查後端歸屬與前端顯示均未交叉。 |
| R-04 同步延遲 | 離線後同步失敗 → 舊資料仍顯示且沒有更新狀態 → 使用者以為紀錄已更新 → 可能忽略需要重新量測或聯繫照護者的情境。 | 明示最後成功同步時間；區分裝置本地紀錄與伺服器紀錄；失敗時不顯示已同步。 | 斷網、逾時、重試及恢復網路案例；核對狀態與實際持久化結果。 |
| R-05 AI 提示超出適用範圍（未實作） | 假設日後加入資料變化提示，模型遇到未驗證族群或裝置資料仍輸出肯定語句 → 使用者把提示當成可靠醫療判斷 → 可能延誤適當評估。 | 先界定適用資料、族群與輸出邊界；不符合條件時不輸出結論，顯示無法判定；禁止診斷或治療語句。 | 若功能真的開發，建立適用／不適用合成資料、輸出限制及無法判定案例；另規劃獨立的使用情境與模型表現評估。 |
R-03 涉及資料存取與病人識別，之後還要接上權限和資安分析；R-05 只是為後續 AI 單元預留一條思考路徑，不代表目前 App 有 AI 功能。這些情境中提到的「可能傷害」也不是病情門檻或個人醫療建議。五條路徑也不能直接推導出 IEC 62304 安全等級；正式分類仍要依完整產品情境與風險管理紀錄判定。
假設 R-01 對無法確認單位的資料加上「不可判讀」標示，我們至少還要回答四個問題：
同一項控制也可能帶來新問題：過度阻擋資料，可能讓使用者看不到仍有參考價值的歷史紀錄。因此，改完一個 Bug 並不自動關閉整條風險路徑。驗證控制已實作、確認其降低風險的效果，以及評估新風險，都是不同工作。ISO 14971 的風險管理過程也會持續利用生產與上市後資訊更新分析。
風險管理與 Bug 處理相互關聯，但處理的問題不同。Bug 可能是風險路徑的起點，風險也可能來自正常使用或使用錯誤。我們可以用「起始事件／失效 → 事件序列 → 危害情境 → 可能傷害」梳理問題如何影響使用者，再依預先訂定的準則評估風險、選擇控制措施。修復 Bug 或列出控制措施都不是終點；還須查證措施已實作、評估其效果與殘餘風險，才能對產品安全性作出有依據的判斷。
iThome鐵人賽
看影片追技術