醫療軟體在開發階段，我們前面談過許多需要注意的部分。

收到需求時，需要盤點風險，透過需求追溯矩陣，串起需求、風險控制、設計與測試證據，確認控制措施是否落實，並評估剩餘風險。

開發完成之後，除了查證需求是否正確實作，還要依產品用途安排必要的確效與使用評量，確認預期使用者在預期條件下能安全完成相關任務，再依發布程序審查與放行。

醫療軟體發布後還要監看哪些訊號？

如果使用者沒有主動回報 bug，我們有機會發現嗎？

監控項目可以分成三組：

• 功能與服務： 當機、同步失敗、摘要服務逾時，以及錯誤發生在哪些版本與裝置。
• 資料與摘要： 缺值比例、日期覆蓋不足、單位不明、摘要核對失敗，以及退回固定模板的比例。
• 外部資訊： 使用者回饋、模型供應商更新通知、第三方套件弱點公告。

如果我們將問題修復後就馬上上線，可能會遇到嚴重的合規問題：

1. 缺少影響分析：例如我們修補了 A 功能，可能就會破壞 B 功能的風險控制邏輯。
2. 版本失去追溯性：如果沒有更新組態記錄，我們就難以確認各版本包含哪些程式、套件與模型；要追查有哪些使用者安裝了受影響的版本，還需要發布、配送或部署紀錄。
3. 無形中觸碰到法規（若修改涉及 AI）：AI 模型在使用上都有預期用途，如果我們在這次 hotfix 修改中調整了 AI 的用途，就會與原本宣告的預期用途不符。若修改涉及預期用途、適用對象、規格或效能，應先評估是否需要辦理變更登記或重新申請查驗登記，完成適用程序後再發布。

事件處理流程：

參考 IEC 62304 第 9 章：軟體問題解決流程

1. 準備問題報告 (Prepare Problem Reports)：記錄問題的詳細描述、發現環境、受影響的軟體版本與組件，開立正式的「問題報告（Problem Report, PR）」。
2. 調查問題 (Investigate the Problem)：進行根因分析，並連結 ISO 14971 風險管理，評估該問題是否會影響醫療器材的安全性、臨床有效性，或引發潛在的危害情境。
3. 通知相關方 (Advise Relevant Parties)：依問題影響與組織程序，視情況通知相關方；是否需要向主管機關通報，另依事件性質與適用法規判斷。
4. 使用變更控制流程 (Use Change Control Process)：不允許私自改代碼。必須開立「變更請求（Change Request, CR）」，依組織的變更控制程序，由指定權責人員審查核准後方可實施。
5. 維護審查紀錄 (Maintain Records)：保留問題報告、解決方式與查證紀錄，並視情況更新風險管理檔案。會議及簽核可作補充。
6. 分析問題趨勢 (Analyse Problems for Trends)：定期分析所有異常。若某類 Bug 重複出現，應採取系統性預防措施改善開發流程。
7. 驗證問題解決 (Verify Resolution)：確認 Bug 已被修復，並執行回歸測試（Regression Testing），查證問題解決方式，確認變更已正確實施、相關不良趨勢已改善，並透過適當測試檢查是否引入額外問題。
8. 測試文件內容 (Test Documentation Contents)：列出測試結果、發現的異常、受測軟體版本、硬體／軟體組態、測試工具、日期及測試人員識別。通過判準可另外保留。

flowchart TD
    A[收到回報或監控訊號] --> B[留下問題紀錄與版本資訊]
    B --> C[評估安全影響與處理優先順序]
    C --> K[依問題影響與適用法規通知相關方或通報]
    C --> D[採取必要的暫時措施並持續評估]
    D --> E[調查原因與受影響範圍]
    E -. 調查中持續評估通知需求 .-> K
    E --> F[決定處理方案並評估變更影響]
    F --> G[核准變更、修正、重測與發布審查]
    G --> H[部署並確認受影響範圍的處理結果]
    H --> I{符合事先訂定的結案條件？}
    I -->|否| C
    I -->|是| J[保留證據並結案，持續監控]

必要的通知或通報可以與調查同步進行，不必等根因完全查明後才開始。

第三方套件出現弱點時，怎麼處理？

收到第三方套件的弱點公告後，先對照套件清單（SBOM），確認產品是否使用了受影響版本，以及實際使用路徑是否符合漏洞可被利用的條件。接著評估可能影響哪些資料與功能、是否需要先採取暫時措施，再安排套件修補與相關功能的回歸測試。處理過程要保留受影響版本、風險評估、修補與測試紀錄，並依問題影響及適用要求決定通知或通報方式。可參考 TFDA《適用於製造業者之醫療器材網路安全指引》。

AI 模型再訓練與效能飄移

對於包含 AI/ML 模組的 SaMD，上市後的監控重點包含「模型效能衰退與再訓練」：

若 AI 模型在上市之後，發現在特定族群上的靈敏度下降，應先確認樣本數、參考標準、資料品質、前處理與裝置差異，調查原因後，再決定是否需要重新訓練。效能下降不一定代表資料或概念飄移。重新訓練後，還要用獨立測試資料比較新舊版本，檢查其他情境與族群的表現是否退步。可參考 IMDRF GMLP 原則 3、4、8、10。

模型更新後，即使預期用途沒有改變，仍要評估規格、效能與適用族群等變更，以及適用的法規程序。若已有核准的預定變更控制計畫（PCCP），也要確認更新符合核定範圍與條件。臺灣的 PCCP 必須在執行前經主管機關核准，不能只靠內部計畫自行認定可以變更。可參考 TFDA PCCP 申請要點暨撰寫說明指引。

若使用自行管理的模型檔（如 .onnx），更新後應記錄檔案版本與 SHA-256，並同步更新 Model Inventory 與 Model Card 版本紀錄；若使用外部模型服務，則記錄可取得的模型版本、設定與變更資訊。

更新影響檢查表

小結

醫療軟體在上市之後的跟版，每一次的版本，都需要將新增的部分以及影響到的部分重新評估過一遍。做好風險控管，並透過適當的查證與測試，檢查修復是否引進新的問題。

另外，如果需要重新訓練模型，要確保模型是否有按照原本的預期用途來訓練。

除了遵守內部 QMS 的變更控制，也要依修改內容與原核准範圍，評估需要完成哪些法規程序，不能只用預期用途有沒有改變來判斷。

醫療軟體改版時，需要留下變更影響、風險控制、查證結果與發布放行的依據。

即使需要緊急發布 hotfix，也要依變更影響完成必要的風險評估、查證與放行程序，保留處理紀錄；不必每次重做全部開發活動。

醫療軟體最重要的，就是在發行前一定要將風險完整了解、盤點過一遍，這樣上市之後的風險就可以降得比較低。

如果真的在上市之後發生問題需要修改，千萬不可以投機，還是需要遵照原本的流程，重新評估風險、落實必要的控制措施並加以查證，避免修正舊問題時引入新問題。

Take Away：即使是緊急修補，也要說清楚改了什麼、影響哪些版本，以及用哪些證據確認修正結果。