IEC 62304 是醫療器材軟體生命週期過程的國際標準（2006 年版＋2015 年修訂 A1），規範軟體開發計畫、需求、架構、實作、驗證、發布與維護的全流程要求。核心機制是軟體安全分級：依故障可能造成的傷害把軟體分為 Class A（無傷害）、B（非重傷）、C（重傷或死亡），等級越高、流程與文件要求越嚴——而分級的依據正是 ISO 14971 的危害分析。對智慧醫療業者最現實的兩個戰場：SOUP（來源不明軟體，含開源元件）的管制——每個第三方元件都要識別、評估與監控，這與 SBOM 及資安漏洞管理直接相連；以及敏捷開發與 62304 文件要求的調和——做得到，但需要方法。
安全分級決定一切
Class A/B/C 直接決定需要哪些開發活動與文件深度。分級做錯方向都昂貴：分高了徒增成本，分低了在審查時被打回更痛。分級判定須以 14971 危害分析為依據並文件化——這是 62304 導入的第一個關鍵交付。
SOUP 與軟體供應鏈
現代醫材軟體大量使用開源與第三方元件，62304 要求對 SOUP 建立需求、評估與異常監控。實務上這就是 SBOM＋漏洞情資監測的常設機制——與 IEC 81001-5-1 及 EU CRA 的要求天然銜接，一套機制三處出證。積穗科研自身管線即每日產製與監測 SBOM，方法論可直接移轉。
與 13485／81001-5-1 的關係
62304 是 13485 設計管制在軟體域的具體化；81001-5-1 再疊上資安活動（威脅建模、資安測試、漏洞處理）。三者共用生命週期骨架，整合導入避免三套平行文件的災難。
対象となる企業
- SaMD 與醫療 App 開發商
- 醫材內嵌軟體（韌體）團隊
- 使用大量開源元件、需建立 SOUP 管制的業者
- 採敏捷開發、需與法規文件要求調和的團隊
よくある質問
我們的 App 算不算醫材軟體？
取決於宣稱用途：診斷、治療、監測等醫療目的即可能構成 SaMD 而適用 62304。健康促進類則可能豁免。建議先做法規定性，再決定流程投資。
敏捷開發和 62304 衝突嗎？
不衝突，但需要設計：以迭代產出累積 62304 要求的文件證據（需求追溯、驗證紀錄），業界已有成熟的敏捷×62304 對映實務。關鍵是把文件當開發產出物，而非事後補作業。
SOUP 管制要做到多細？
每個 SOUP 元件需識別版本、功能與效能需求、已知異常監控管道。實務最低配備是自動化 SBOM 產製＋漏洞情資訂閱＋評估紀錄——手工 Excel 維護在元件數量上百後必然失守。
62304 有認證嗎？
無獨立認證制度，符合性透過 13485 稽核與各市場技術文件審查驗證。輔導目標是讓開發流程證據經得起公告機構與 FDA 檢視。