在昨天的文章中，我們了解到醫療軟體的品質管理系統包含了ISO 14971 (醫療器材風險管理)、IEC 62304（醫療器材軟體生命週期流程)、IEC 62366-1（醫療器材人因與可用性工程），那麼，我們該如何以軟體開發者可執行的工程執行角度切入執行呢？衛福部食藥署（TFDA）提供了《醫療器材軟體製造業者品質管理系統指導文件》，我們可以從這份文件來一探究竟。

SaMD 與一般軟體最大的差異在於，一般軟體追求的是「快速上線、持續修正」，功能在上線之後如果遇到 bug，那就再出一版更新。但是 SaMD 的核心要求是「安全、有效與可追溯」。

依照此份指導文件，我們可以將其轉化成四個核心工程實踐：

1. 軟體開發生命週期（SDLC）必須標準化
2. 建立嚴格的「可追溯性矩陣（Traceability Matrix）」
3. 將「風險管理」融入代碼設計
4. 嚴格控管「SOUP(未知軟體)」與版本變更

一、軟體開發生命週期（SDLC）必須標準化

依照昨日介紹的 IEC 62304 標準，建立嚴謹的軟體生命週期管理，並將軟體需求規格（SRS）寫成文件，避免口頭傳達造成資訊落差。繪製清晰的系統架構圖，定義模組間的互動關係。
在開發前，需明確量化正確率、靈敏度、特異度與處理時間。

二、建立嚴格的「可追溯性矩陣（Traceability Matrix）」

將產品需求（PRD）對應到軟體需求（SRS），再對應到程式碼模組/函式，最後對應到測試案例 (Test Case)。
程式碼的異動需要能被追溯到需求或 bug。
原始碼（Git）、建置工具、CI/CD 流程與環境設定檔均為組態項目，需做到可追溯（Traceability）。
進入測試時，必須是獨立 QA 進行測試，避免校長兼撞鐘。

三、將「風險管理」融入程式碼設計

參考 ISO 14971 進行風險管理分析，醫療軟體在開發時，需要注意「病患與使用者的安全」，
例如：加上有效的異常處理，提高程式碼的容錯機制。涉及網路傳輸時，需要將資料傳送方式的風險也考量進入，使用加密傳輸。避免直接使用未加密的連線（如 Http)。

四、嚴格控管「SOUP(未知來源軟體)」與版本變更

程式碼中，所引用的所有第三方函式庫、框架... 都必須要列冊管理，並評估其潛在風險及漏洞。
產品進入確效階段時，程式碼就不能任意的改動，若真的需要修改，就需要變更申請、風險評估與重新驗證。
註：「確效階段（Validation Phase)」代表產品已經完成了內部工程師的研發與測試，正式進入「證明這套軟體確實符合預期醫療用途，且對病患是安全、有效」的法定官方驗證程序。

小結

SaMD 的品質管理是從開發前的風險評估，到開發時的可追溯矩陣，最後是上線前的測試，這一整個軟體開發 pipeline 或許與一般的軟體開發來說嚴格許多。但是由於 SaMD 是提供給醫療環境使用，我們需要以最高標準來看待釋出的軟體。如此才能夠避免軟體推出後，可能造成的風險。