IEC62304:2006軟體生命週期流程
IEC 62304:2006/AMD 1:2015軟體生命週期流程：醫療器材軟體必備的開發與維護框架
IEC 62304 軟體生命週期流程完整指南｜醫療器材軟體開發的國際標準
IEC 62304 是醫療器材軟體開發的核心標準。本文說明軟體生命週期流程、分類、文件與符合性要點，並提供落地導入技巧與常見問答。
一、IEC 62304 是什麼？為什麼醫療軟體必須遵循？
IEC 62304《醫療器材軟體—軟體生命週期流程》 是針對醫療器材軟體的 開發、維護與風險管理流程標準，要求企業在產品生命週期中 可追溯、可證明、可控管 軟體的安全與品質。
它不教你寫程式碼，而是要求：
你 怎麼開發軟體
你 如何確認軟體是安全的
你 怎麼維護、修正與更新版本
你 如何處理市場上真實出現的問題
一句話：IEC 62304 確保軟體不僅能運作，而且不會讓使用者陷入風險。
二、軟體分類：決定你要做到多嚴格
IEC 62304 最核心的第一步：確認軟體分類與風險
| 分類 | 風險描述 | 實例 | 要求 |
|---|---|---|---|
| Class A | 不造成危害 | 行政類 App、運動紀錄 | 最少量 |
| Class B | 可能造成非嚴重傷害 | 醫療感測軟體、HIS、監控介面 | 中等要求 |
| Class C | 可能造成死亡或嚴重傷害 | 植入式設備軟體、呼吸機控制、輸注泵控制 | 最嚴格、最高追溯 |
三、IEC 62304 軟體生命週期流程（完整架構）
IEC 62304 要求 從規劃到報廢，軟體全流程都有證據、可追溯、可驗證。
軟體生命週期六大核心流程：
軟體開發流程
需求（SRS）→ 架構 → 詳設 → 程式碼 → 單元 → 整合 → 系統測試
重點：需求與測試雙向追溯
軟體維護流程
修復 Bug、版本發布、紀錄分析
輸入：客訴、監視、CAPA、召回資料
軟體風險管理
與 ISO 14971 整合
軟體故障、資料異常、演算法誤判皆需納入
軟體組態管理
版本、庫、來源、開發環境可追溯
避免「我不知道這段程式誰改的」
軟體變更管理
任何修改都需重新評估風險與影響
不是寫完就算，要能控管更新成本
軟體問題解決流程（問題/事件/缺陷）
本質上就是 軟體版 CAPA
來源：客戶、測試、監管、臨床回饋
四、文件與追溯：IEC 62304 最難卻最關鍵
| 文件 | 角色 | 目的 |
|---|---|---|
| SRS 軟體需求規格書 | 需求源頭 | 為什麼要做 |
| 架構設計文件 | 系統骨架 | 怎麼做 |
| 單元 / 整合 / 系統測試報告 | 驗證 | 做對沒有 |
| 追溯矩陣（需求 ↔ 測試） | 稽核核心 | 可證明、可確認 |
| 缺陷處理紀錄 | 問題管理 | 防止重複出錯 |
| 版本紀錄 | 組態管理 | 記錄演進與責任 |
五、常見問答（FAQ）
Q1：我們只做醫材軟體一小部分，也要遵守 IEC 62304 嗎？
若客戶或公告機構要求，你 至少要能配合提供追溯與測試證據。
Q2：IEC 62304 與 ISO 13485、ISO 14971 有何關係？
ISO 13485 = 醫材品質系統骨架
ISO 14971 = 風險管理腦袋
IEC 62304 = 軟體開發與維護流程血液
三者需 整合 才算完整體系。
Q3：敏捷開發（Agile / Scrum）能做 IEC 62304 嗎？
可以，只要你 能留下追溯、測試證據與版本記錄。方法靈活，證據不可以。
Q4：文件一定要很厚嗎？
不必。一致性 + 追溯 + 可驗證 > 文件厚度
六、結語：IEC 62304 不是束縛，而是讓軟體「可維護、可信賴」的基準
醫療軟體不只是寫程式，它牽涉到 生命、風險、責任、合規。
IEC 62304 能確保你的軟體 不只跑得動，也能跑得安全、跑得久。
懂開發不是重點，能證明你是安全的，才算真正合規。
ODI MORGAN 如何協助你導入 IEC 62304？
ODI MORGAN 能提供：
IEC 62304 文件模板、追溯矩陣與版本流程
ISO 14971 × IEC 62304 風險整合與差距分析
敏捷開發 × 稽核證據保留方法
FDA / MDR / MDSAP 稽核問答演練與應對策略
導入 IEC 62304 的目的不是寫文件，而是「能交出證據、能通過稽核、能維護軟體」——找 ODI MORGAN，一次到位。
