本指導原則旨在指導制造商提交醫(yī)療器械軟件注冊申報資料，同時規(guī)范醫(yī)療器械軟件的技術審評要求。
本指導原則是對醫(yī)療器械軟件的一般性要求，制造商應根據醫(yī)療器械軟件的特性提交注冊申報資料，判斷指導原則中的具體內容是否適用，不適用內容詳述理由。制造商也可采用其他滿足法規(guī)要求的替代方法，但應提供詳盡的研究資料和驗證資料。
本指導原則是在現行法規(guī)和標準體系以及當前認知水平下、并參考了國外法規(guī)與指南、國際標準與技術報告制定的。隨著法規(guī)和標準的不斷完善，以及認知水平和技術能力的不斷提高，相關內容也將適時進行修訂。
本指導原則是對制造商和審查人員的指導性文件，不包括審評審批所涉及的行政事項，亦不作為法規(guī)強制執(zhí)行，應在遵循相關法規(guī)的前提下使用本指導原則。
本指導原則針對軟件的特殊性，在現行法規(guī)要求下進一步明確了對醫(yī)療器械軟件的要求，特別是對軟件更新、軟件版本的要求。本指導原則是醫(yī)療器械軟件的通用指導原則，其他涉及軟件醫(yī)療器械產品的指導原則可在本指導原則基礎上進行有針對性的調整、修改和完善。
本指導原則適用于醫(yī)療器械軟件的注冊申報，包括第二類、第三類醫(yī)療器械產品，適用的軟件開發(fā)方式包括自主開發(fā)、部分采用現成軟件和全部采用現成軟件。
醫(yī)療器械軟件包括獨立軟件和軟件組件。獨立軟件：作為醫(yī)療器械或其附件的軟件；軟件組件：作為醫(yī)療器械或其部件、附件組成的軟件。
獨立軟件應同時具備以下三個特征：具有一個或多個醫(yī)療用途，無需醫(yī)療器械硬件即可完成預期用途，運行于通用計算平臺。獨立軟件包括通用型軟件和專用型軟件，其中通用型軟件基于通用數據接口與多個醫(yī)療器械產品聯合使用，如PACS、中央監(jiān)護軟件等；而專用型軟件基于通用、專用的數據接口與特定醫(yī)療器械產品聯合使用，如Holter數據分析軟件、眼科顯微鏡圖像處理軟件等。
軟件組件應同時具備以下兩個特征：具有一個或多個醫(yī)療用途，控制（驅動）醫(yī)療器械硬件或運行于專用（醫(yī)用）計算平臺。軟件組件包括嵌入式軟件和控制型軟件，其中嵌入式軟件（即固件）運行于專用（醫(yī)用）計算平臺，控制（驅動）醫(yī)療器械硬件，如心電圖機所含軟件、腦電圖機所含軟件等；而控制型軟件運行于通用計算平臺，控制（驅動）醫(yī)療器械硬件，如CT圖像采集工作站軟件、MRI圖像采集工作站軟件等。
軟件組件也可兼具處理功能。專用型獨立軟件可單獨注冊，也可隨醫(yī)療器械產品注冊，此時視為軟件組件。
軟件沒有物理實體，在開發(fā)和使用過程中人為因素影響無處不在，軟件測試由于時間和成本的限制不能窮盡所有情況，所以軟件缺陷無法避免。同時，軟件更新頻繁且迅速，輕微更新也可能導致嚴重后果，而且還存在退化問題（即每修復若干個缺陷就會產生一個新缺陷），所以軟件缺陷無法根除。因此，軟件缺陷可視為軟件的固有屬性之一，軟件的質量問題不容忽視。
鑒于軟件的特殊性，醫(yī)療器械軟件只有綜合考慮風險管理、質量管理和軟件工程的要求才能保證安全性與有效性。
醫(yī)療器械軟件的風險水平采用軟件安全性級別（YY/T 0664《醫(yī)療器械軟件 軟件生存周期過程》）進行分級，軟件安全性級別基于軟件損害嚴重度分為：
A級：不可能對健康有傷害和損壞；
B級：可能有不嚴重的傷害；
C級：可能死亡或嚴重傷害。
軟件安全性級別應結合軟件的預期用途、使用環(huán)境和核心功能（軟件在預期使用環(huán)境完成預期用途所必需的功能）進行判定。其中預期用途主要考慮軟件的臨床用途（如診斷、治療、監(jiān)護、篩查等）和重要程度（如重要作用、輔助作用、補充作用等），使用環(huán)境主要考慮軟件的使用場所（如醫(yī)院、家庭等）、疾病類型（如嚴重性、緊迫性、傳染性等）、患者人群（如成人、兒童、老年、女性等）和用戶類型（如專業(yè)用戶、普通用戶、患者等），核心功能主要考慮軟件的功能類型（如控制驅動、處理分析等）、實現方法（如CT圖像重建采用濾波反投影算法還是迭代算法，異常識別采用常規(guī)圖像處理算法還是人工智能算法等）和復雜程度（如算法規(guī)模、參數數量、運算速度等）。
軟件安全性級別也可根據風險管理所確定的風險等級進行判定，軟件安全性級別與風險等級的分級可以不同，但二者存在對應關系，因此可根據風險等級來判定軟件安全性級別。
制造商應在采取風險緩解措施之前判定軟件安全性級別，并結合質量管理體系要求，建立與軟件安全性級別相匹配的軟件生存周期過程，包括軟件開發(fā)過程、軟件維護過程、配置管理過程、風險管理過程和問題解決過程。同時，制造商可采用良好軟件工程實踐完善質量管理體系要求，保證軟件質量。另外，制造商應保證軟件自身的信息安全，確保健康數據的保密性、完整性和可得性。
制造商應基于軟件安全性級別提交相應注冊申報資料。注冊申報資料均源自軟件生存周期過程所形成的文件資料，詳盡程度取決于軟件的安全性級別和復雜程度。
獨立軟件和軟件組件盡管在結構和功能上有所不同，風險情況也不盡相同，但軟件生存周期過程基本一致，故二者注冊申報資料要求的基本原則相同，具體要求有所差異。
軟件描述文檔基于YY/T 0664《醫(yī)療器械軟件 軟件生存周期過程》予以制定，用于自主開發(fā)醫(yī)療器械軟件的產品注冊。軟件描述文檔包括基本信息、實現過程和核心算法（詳見表1）。
（一）基本信息
1. 軟件標識
明確軟件的名稱、型號規(guī)格、發(fā)布版本、制造商和生產地址。軟件組件標識為制造商質量控制所用標識。
2. 安全性級別
明確軟件安全性級別（A級、B級、C級），詳述確定理由。
3. 結構功能
依據軟件設計規(guī)范（SDS）提供體系結構圖和用戶界面關系圖（如適用）。
體系結構圖用于圖示組成模塊之間、組成模塊與外部接口之間的關系，依據體系結構圖描述組成模塊（注明選裝、模塊版本）的功能、模塊關系和外部接口。
用戶界面關系圖用于描述用戶界面之間的關系，依據用戶界面關系圖（如不適用則為體系結構圖）描述臨床功能模塊（注明選裝、模塊版本）的功能和模塊關系。
4. 硬件拓撲
依據軟件設計規(guī)范（SDS）提供物理拓撲圖，圖示并描述軟件（或組成模塊）、通用計算機、醫(yī)療器械硬件之間的物理連接關系。
5. 運行環(huán)境
明確軟件運行所需的硬件配置、軟件環(huán)境和網絡條件。其中硬件配置包括處理器、存儲器和外設器件，軟件環(huán)境包括系統(tǒng)軟件、支持軟件和安全軟件，網絡條件包括網絡架構（BS、CS）、網絡類型（廣域網、局域網、個域網）和帶寬。
6. 適用范圍
獨立軟件描述軟件的適用范圍，軟件組件描述醫(yī)療器械產品的適用范圍。進口醫(yī)療器械軟件描述原產國情況。
7. 禁忌癥
獨立軟件描述軟件的禁忌癥或使用限制，軟件組件描述醫(yī)療器械產品的禁忌癥或使用限制。進口醫(yī)療器械軟件描述原產國情況。
8. 注冊歷史
獨立軟件描述中國注冊情況（列明歷次注冊的發(fā)布版本和注冊證號）和原產國注冊情況（如適用，列明歷次注冊的日期、發(fā)布版本和管理類別），在其它主要國家和地區(qū)的注冊情況也可提供。軟件組件描述醫(yī)療器械產品的注冊情況。
（二）實現過程
1. 開發(fā)概述
明確軟件開發(fā)所用的語言、工具和方法，其中工具描述支持軟件（含開源軟件）和應用軟件（第三方軟件）的名稱、完整版本和供應商。同時明確開發(fā)人員數量、開發(fā)時間、工作量（人月數）和代碼行總數。
2. 風險管理
依據風險管理相關標準提供軟件風險分析報告和軟件風險管理報告，風險管理資料另附原始文件。軟件組件提供醫(yī)療器械產品的風險管理資料。
3. 需求規(guī)范
A級提供軟件需求規(guī)范（SRS）關于軟件功能的要求，B級和C級提供軟件需求規(guī)范全文。軟件需求規(guī)范另附原始文件。軟件組件如無單獨的軟件需求規(guī)范，可提供醫(yī)療器械產品的需求規(guī)范。
4. 生存周期
A級提供軟件開發(fā)生存周期計劃摘要，描述開發(fā)各階段的劃分情況和工作任務。B級在A級基礎上提供配置管理計劃摘要和維護計劃摘要，描述所用的工具和流程。C級在B級基礎上提供設計歷史文檔集索引表（DHF）。
生存周期也可提交制造商軟件生存周期過程文件或YY/T 0664《醫(yī)療器械軟件 軟件生存周期過程》等過程標準的核查表，用于替代相應描述。
5. 驗證與確認
驗證是指通過提供客觀證據認定軟件某開發(fā)階段的輸出滿足輸入要求，包括代碼檢查、設計評審、測試等質量保證活動。確認是指通過提供客觀證據認定軟件滿足用戶需求和預期用途，通常是指在真實或模擬使用環(huán)境進行的用戶測試?？勺匪菪苑治鍪侵缸粉櫺枨笠?guī)范、設計規(guī)范、源代碼、測試、風險管理之間的關系，分析已識別關系的正確性、一致性、完整性和準確性。
A級提供系統(tǒng)測試、用戶測試的計劃和報告摘要，描述測試的條件、工具、方法、通過準則和結果。B級提供系統(tǒng)測試、用戶測試的計劃和報告，概述開發(fā)各階段的驗證活動，描述所用的工具、方法和任務。C級在B級基礎上提供可追溯性分析報告（追溯需求規(guī)范、設計規(guī)范、測試、風險管理的關系表）。
系統(tǒng)測試和用戶測試的計劃和報告另附原始文件。測試報告關于測試記錄的內容可以提供一個測試記錄樣例和完整的測試記錄清單。驗證活動也可提交制造商軟件質量保證計劃文件，用于替代相應描述。
6. 缺陷管理
A級描述缺陷管理的工具和流程，明確軟件本次注冊已知的缺陷總數和剩余缺陷數。B級和C級在A級基礎上列明已知剩余缺陷情況，證明全部已知剩余缺陷的風險均是可接受的。已知剩余缺陷情況可另附原始文件。
7. 更新歷史
A、B、C級均應描述軟件版本命名規(guī)則，明確軟件版本的全部字段及字段含義，確認軟件完整版本和軟件發(fā)布版本。
A級列明軟件本次注冊與前次注冊之間歷次軟件更新的完整版本、日期和類型。B級在A級基礎上詳述歷次軟件更新的具體更新內容。C級列明軟件歷次注冊時歷次軟件更新的完整版本、日期、類型和具體更新內容。
進口醫(yī)療器械軟件描述原產國的更新情況，首次產品注冊描述軟件開發(fā)階段的更新情況。更新歷史可另付原始文件。
8. 臨床評價
臨床評價資料另附原始文件。
（三）核心算法
依據軟件設計規(guī)范（SDS）和說明書列明核心算法的名稱、類型、用途和臨床功能。
核心算法是指實現軟件核心功能（軟件在預期使用環(huán)境完成預期用途所必需的功能）所必需的算法，包括但不限于成像算法、后處理算法和人工智能算法。其中成像算法是指用于獲取醫(yī)學圖像或數據的算法，后處理算法是指改變原始醫(yī)學圖像或數據產生新臨床信息的算法，人工智能算法是指采用人工智能技術進行醫(yī)學圖像或數據分析的算法。
算法類型包括公認成熟算法和全新算法。其中公認成熟算法是指源自公開文獻資料、原理簡單明確、上市多年且無不良事件的算法，而全新算法是指源自臨床研究、科學研究的新算法。
核心算法詳盡程度取決于安全性級別和算法類型。當安全性級別為A級時，公認成熟算法和全新算法均列明算法的名稱、類型、用途和臨床功能。當安全性級別為B級和C級時，公認成熟算法列明算法的名稱、類型、用途和臨床功能，全新算法在公認成熟算法基礎上提供安全性與有效性的驗證資料。
表1 軟件描述文檔框架
| 描述文檔 | A級 | B級 | C級 | ||
| 基本信息 | 軟件標識 | 明確軟件名稱、型號規(guī)格、發(fā)布版本、制造商和生產地址。 | |||
| 安全性級別 | 明確軟件安全性級別，詳述確定理由。 | ||||
| 結構功能 | 依據體系結構圖描述軟件組成模塊，依據用戶界面關系圖描述軟件臨床功能模塊。 | ||||
| 硬件拓撲 | 依據物理拓撲圖描述軟件、通用計算機和醫(yī)療器械硬件的物理連接關系。 | ||||
| 運行環(huán)境 | 明確軟件運行所需的硬件配置、軟件環(huán)境和網絡條件。 | ||||
| 適用范圍 | 明確軟件的適用范圍，進口軟件描述原產國情況。 | ||||
| 禁忌癥 | 明確軟件的禁忌癥或使用限制，進口軟件描述原產國情況。 | ||||
| 注冊歷史 | 明確軟件在中國和原產國的注冊情況。 | ||||
| 實現過程 | 開發(fā)概述 | 明確開發(fā)語言、工具、方法，以及人員、時間、工作量、代碼行數。 | |||
| 風險管理 | 提供風險管理資料。 | ||||
| 需求規(guī)范 | 提供需求規(guī)范的功能要求。 | 提供需求規(guī)范全文。 | |||
| 生存周期 | 提供開發(fā)生存周期計劃摘要。 | 提供開發(fā)生存周期計劃、配置管理計劃和維護計劃的摘要。 | 提供開發(fā)生存周期計劃、配置管理計劃和維護計劃的摘要，以及設計歷史文檔集索引表。 | ||
| 驗證與確認 | 提供系統(tǒng)測試、用戶測試的計劃與報告摘要。 | 概述開發(fā)各階段的驗證活動，提供系統(tǒng)測試、用戶測試的計劃與報告。 | 概述開發(fā)各階段的驗證活動，提供系統(tǒng)測試、用戶測試的計劃與報告，以及可追溯性分析報告。 | ||
| 缺陷管理 | 描述缺陷管理流程，明確已知的缺陷總數和剩余缺陷數。 | 描述缺陷管理流程，明確已知的缺陷總數和剩余缺陷數，列明已知剩余缺陷情況。 | |||
| 更新歷史 | 明確版本命名規(guī)則，列明本次與前次注冊之間歷次軟件更新的完整版本、日期和類型。 | 明確版本命名規(guī)則，列明本次與前次注冊之間歷次軟件更新的完整版本、日期、類型和具體更新內容。 | 明確版本命名規(guī)則，列明歷次注冊時歷次軟件更新的完整版本、日期、類型和具體更新內容。 | ||
| 臨床評價 | 提供臨床評價資料。 | ||||
| 核心算法 | 列明算法的名稱、類型、用途和臨床功能。 | 公認成熟算法列明算法的名稱、類型、用途和臨床功能，全新算法在公認成熟算法基礎上提供安全性與有效性的驗證資料。 | |||
（一）基本考量
醫(yī)療器械軟件更新是指制造商在整個軟件生存周期過程中對軟件所做的任一修改。軟件更新類型從不同角度出發(fā)有不同劃分方法。從更新的結果和影響角度出發(fā)，軟件更新可分為：
1. 重大更新：影響到醫(yī)療器械安全性或有效性的軟件更新；
2. 輕微更新：不影響醫(yī)療器械安全性與有效性的軟件更新。
從更新的目的和范圍角度出發(fā)，軟件更新可分為增強類更新和糾正類更新，其中增強類更新又可分為適應型更新和完善型更新，糾正類更新又可分為糾正型更新和預防型更新（改自GB/T 20157《信息技術 軟件維護》）：
1. 適應型更新：醫(yī)療器械軟件上市后，為適應新的運行環(huán)境而進行的軟件更新；
2. 完善型更新：醫(yī)療器械軟件上市后，為改變功能、性能等軟件屬性而進行的軟件更新；
3. 糾正型更新：醫(yī)療器械軟件上市后，為修正軟件已知缺陷而進行的軟件更新；
4. 預防型更新：醫(yī)療器械軟件上市后，為修正軟件潛在未知缺陷以避免出現運行故障而進行的軟件更新。
同時，有兩種特殊情況需要考慮：
1. 構建（Build）：是指軟件編譯生成一個工作版本，符合軟件更新的定義，通過質量管理體系進行控制，申報資料要求與糾正類更新相同。下文如無特別說明，糾正類更新均包含構建；
2. 涉及召回：包括軟件更新導致醫(yī)療器械召回、召回處理措施所引發(fā)的軟件更新，這兩種情況均屬于重大更新，應按照醫(yī)療器械召回的相關法規(guī)處理，不屬于本指導原則討論范圍。
本指導原則關注軟件的安全性與有效性，將軟件更新分為：
1. 重大軟件更新：影響到醫(yī)療器械安全性或有效性的增強類更新，即重大增強類軟件更新；
2. 輕微軟件更新：不影響醫(yī)療器械安全性與有效性的增強類更新和糾正類更新，即輕微增強類軟件更新和糾正類軟件更新。
（二）重大軟件更新
根據定義，凡是影響到醫(yī)療器械安全性或有效性的軟件更新均為重大軟件更新。具體而言，軟件更新如影響到醫(yī)療器械的預期用途、使用環(huán)境或核心功能均為重大軟件更新。
本指導原則所述重大軟件更新包括以下情形之一：
1. 適應型軟件更新：軟件運行平臺跨越互不兼容的計算平臺（包括硬件和軟件），如操作系統(tǒng)軟件由Windows變?yōu)閕OS，32位計算平臺變?yōu)?4位計算平臺、常規(guī)計算平臺變?yōu)橐苿佑嬎闫脚_等，而系統(tǒng)軟件和支持軟件的補丁一般不視為重大軟件更新，除非影響到醫(yī)療器械的安全性或有效性。
2. 完善型軟件更新：影響到用戶臨床決策（包括決策能力、決策結果、決策流程和用戶臨床行動），或者影響到人員安全（包括患者、用戶和其他相關人員），包括但不限于：
（1）臨床功能改變，如新增臨床應用、新增運行模式、采用新核心算法等；
（2）軟件輸出結果改變，如醫(yī)學圖像或數據質量改變、用戶界面增加臨床信息等；
（3）用戶使用習慣改變，如用戶原有臨床工作流程改變、用戶界面布局改變等；
（4）影響到患者安全，如采用新的軟件安全標準、用戶界面增加報警信息等。
而核心算法運算速度的單純性提高、臨床工作流程的可配置化（即用戶可以保留原有臨床工作流程）、用戶界面的文字性修改，除非影響到醫(yī)療器械的安全性或有效性,一般不視為重大更新。
3. 其他軟件更新：軟件的安全性級別、體系結構、用戶界面關系或物理拓撲發(fā)生改變。
重大軟件更新的范圍會隨著認知水平與技術能力的提高、不良事件與召回事件的分析進行動態(tài)調整。
（三）軟件更新要求
醫(yī)療器械軟件發(fā)生重大軟件更新應進行許可事項變更，而發(fā)生輕微軟件更新通過質量管理體系進行控制，無需進行注冊變更，待到下次注冊（注冊變更和延續(xù)注冊）時提交相應申報資料。
已注冊的醫(yī)療器械軟件在后續(xù)注冊（注冊變更和延續(xù)注冊）時應根據軟件更新情況提交相應申報資料：
1. 重大軟件更新
軟件發(fā)生重大軟件更新應提交軟件更新描述文檔，包括基本信息、實現過程和核心算法（詳見表2）。
表2 軟件更新描述文檔框架
| 軟件描述文檔 | 申報要求 | |
| 基本信息 | 軟件標識 | 明確軟件本次注冊情況，如改變詳述更新內容。 |
| 安全性級別 | 明確軟件本次注冊情況，如改變詳述更新理由并按更新后的安全性級別提交資料。 | |
| 結構功能 | 明確軟件本次注冊情況，如改變詳述更新內容。 | |
| 硬件拓撲 | 明確軟件本次注冊情況，如改變詳述更新內容。 | |
| 運行環(huán)境 | 明確軟件本次注冊情況，如改變詳述更新內容。 | |
| 適用范圍 | 明確軟件本次注冊情況，如改變詳述更新內容。 | |
| 禁忌癥 | 明確軟件本次注冊情況，如改變詳述更新內容。 | |
| 注冊歷史 | 明確軟件本次注冊情況。 | |
| 實現過程 | 開發(fā)概述 | 明確軟件本次注冊情況，如改變詳述更新內容。 |
| 風險管理 | 提供更新部分的風險管理資料，包含對整體的影響分析。 | |
| 需求規(guī)范 | 提供更新部分的需求規(guī)范。 | |
| 生存周期 | 提供軟件維護流程和配置管理流程。 | |
| 驗證與確認 | 提供更新部分的驗證與確認資料，包含對整體影響的確認。 | |
| 缺陷管理 | 提供缺陷管理流程，明確本次注冊已知剩余缺陷情況。 | |
| 更新歷史 | 明確版本命名規(guī)則，詳述軟件具體更新內容。 | |
| 臨床評價 | 提供更新部分的臨床評價資料。 | |
| 核心算法 | 提供更新部分的核心算法。 | |
2. 輕微軟件更新
軟件發(fā)生輕微軟件更新時，輕微增強類軟件更新同樣應提交軟件更新描述文檔，而糾正類軟件更新應提交軟件更新情況說明、回歸測試計劃與報告、新增已知剩余缺陷情況說明。
軟件同時發(fā)生多種類型的軟件更新，應按照風險從高原則提交申報資料，即同時發(fā)生重大軟件更新和輕微軟件更新則按照重大軟件更新處理，同時發(fā)生增強類軟件更新和糾正類軟件更新則按照增強類軟件更新處理。
醫(yī)療器械軟件的重新開發(fā)（即制造商棄用原有軟件）不屬于軟件更新，應按照醫(yī)療器械產品注冊的要求提交申報資料。
（一）基本考量
軟件沒有物理實體，只能通過狀態(tài)管理保證質量，而軟件版本用于標識軟件狀態(tài)，控制軟件更新，進而保證軟件質量，因此軟件版本與軟件是相互對應的表里關系，即軟件版本是軟件標識不可或缺的組成部分，也是實現醫(yī)療器械軟件可追溯性的重要工具。
制造商無論采用何種名稱和形式（如修訂號、構建號、發(fā)布日期等），只要用于標識軟件狀態(tài)均視為軟件版本。制造商制定軟件版本命名規(guī)則除了考慮醫(yī)療器械產品自身特點、質量管理體系要求之外，還要考慮監(jiān)管的要求，即軟件版本命名規(guī)則能夠區(qū)分軟件更新類型，可以確認軟件完整版本和軟件發(fā)布版本：
1. 軟件完整版本：體現重大增強類軟件更新、輕微增強類軟件更新、糾正類軟件更新和構建（如適用）；
2. 軟件發(fā)布版本：軟件發(fā)行所用的標識版本，僅體現重大增強類軟件更新（即重大軟件更新）。
軟件發(fā)布版本發(fā)生改變應進行許可事項變更，軟件完整版本發(fā)生改變但軟件發(fā)布版本未變無需進行注冊變更。例如，軟件版本命名規(guī)則為X.Y.Z.B，其中X表示重大增強類軟件更新，Y表示輕微增強類軟件更新，Z表示糾正類軟件更新，B表示構建，則軟件完整版本為X.Y.Z.B，軟件發(fā)布版本為X，此時X發(fā)生變化應進行許可事項變更，而Y、Z和B發(fā)生變化無需進行注冊變更。
軟件版本命名規(guī)則同樣遵循風險從高原則，即不能區(qū)分重大軟件更新和輕微軟件更新則按照重大軟件更新處理，不能區(qū)分增強類軟件更新和糾正類軟件更新則按照增強類軟件更新處理。
（二）軟件版本要求
制造商應出具軟件版本命名規(guī)則真實性聲明，明確軟件版本的全部字段及字段含義，確認軟件完整版本和軟件發(fā)布版本。
制造商應在說明書中明確軟件發(fā)布版本。
對于獨立軟件（含專用型獨立軟件視為軟件組件的情況）和控制型軟件組件，制造商應在登錄界面、主界面、“關于”或“幫助”等界面體現軟件完整版本和軟件發(fā)布版本。
（一）基本考量
隨著信息技術的快速發(fā)展，醫(yī)療器械產品使用現成軟件的情況越來越普遍，但現成軟件不能完全滿足醫(yī)療器械產品的預期用途，而且制造商未對現成軟件進行完整生存周期控制，因此使用現成軟件風險相對較高。由于要對醫(yī)療器械產品最終的安全性與有效性負責，制造商應采用基于風險的方法保證現成軟件的質量和安全。
現成軟件分為：
1. 成品軟件：已開發(fā)且通?？傻玫降模圃焐涛催M行完整生存周期控制的軟件，包含商業(yè)軟件和免費軟件；
2. 遺留軟件：制造商以前開發(fā)但現在不能得到足夠開發(fā)記錄的軟件；
3. 外包軟件：制造商委托第三方開發(fā)的定制軟件。
目前，本指導原則所述的現成軟件僅限于應用軟件，今后將在適當時機下擴至系統(tǒng)軟件和支持軟件。但制造商應保證系統(tǒng)軟件和支持軟件的質量和安全。
（二）現成軟件要求
醫(yī)療器械軟件的開發(fā)方式不同，采用的現成軟件類型不同，軟件質量保證措施也不同，注冊申報資料亦有所差異。
1. 部分采用現成軟件
對于部分采用現成軟件的方式，三種現成軟件的要求相同，制造商均應在軟件描述文檔相應條款中描述（詳見表3）。
表3 部分現成軟件框架
| 安全性級別 | A級 | B級 | C級 |
|
軟件描述 文檔條款 |
軟件標識、結構功能、風險管理、驗證與確認、更新歷史。 | 軟件標識、結構功能、需求規(guī)范、風險管理、生存周期、驗證與確認、缺陷管理、更新歷史、核心算法。 | |
（1）軟件標識
A、B、C級明確現成軟件的名稱、型號規(guī)格、發(fā)布版本、供應商和生產地址。
（2）結構功能
A、B、C級注明組成模塊、臨床功能模塊所用現成軟件的名稱、發(fā)布版本和類型。
（3）風險管理
A、B、C級提供現成軟件的風險管理資料。
（4）需求規(guī)范
B級和C級提供現成軟件的需求規(guī)范資料。
（5）生存周期
B級和C級在開發(fā)生存周期計劃、配置管理計劃和維護計劃中明確現成軟件的要求。
（6）驗證與確認
A、B、C級提供現成軟件的驗證與確認資料。
（7）缺陷管理
B級和C級明確現成軟件的缺陷管理流程和已知剩余缺陷情況。
（8）更新歷史
A、B、C級明確現成軟件的版本命名規(guī)則。
（9）核心算法
B級和C級列明現成軟件核心算法的名稱（或編號）、用途和臨床功能，全新臨床功能提供安全性與有效性的驗證資料。
2. 全部采用現成軟件
對于全部采用現成軟件的方式，三種現成軟件的要求有所不同：
（1）成品軟件：制造商應提供外購合同復印件或聲明、軟件描述文檔（不適用條款說明理由），成品軟件如已在中國上市提供注冊證復印件；
（2）遺留軟件：制造商應提供遺留軟件證明性文件（如YY/T 0664或IEC 62304實施之前的注冊證或上市批書復印件）、軟件描述文檔（不適用條款說明理由）、上市后臨床評價資料；
（3）外包軟件：制造商應提供外包合同復印件或聲明、軟件描述文檔（不適用條款說明理由）。
（三）現成軟件更新要求
現成軟件的更新類型、更新注冊要求和風險從高原則與自主開發(fā)軟件相同，注冊申報資料要求與自主開發(fā)軟件有所差異。
現成軟件發(fā)生重大軟件更新時，應參照自主開發(fā)軟件重大軟件更新要求提交現成軟件更新描述文檔，不適用條款說明理由?，F成軟件發(fā)生輕微軟件更新時，輕微增強類軟件更新同樣應提交現成軟件更新描述文檔，而糾正類軟件更新與自主開發(fā)軟件糾正類軟件更新要求相同。
對于部分采用現成軟件的情況，自主開發(fā)的軟件發(fā)生更新按照自主開發(fā)軟件更新要求提交相應申報資料，現成軟件發(fā)生更新按照現成軟件更新要求提交相應申報資料。
（四）現成軟件版本要求
現成軟件版本同樣要考慮監(jiān)管要求和遵循風險從高原則?，F成軟件供應商的軟件版本命名規(guī)則如符合監(jiān)管要求，制造商可直接采用現成軟件供應商的版本命名規(guī)則。
制造商應在軟件版本命名規(guī)則真實性聲明中明確現成軟件的版本命名規(guī)則、完整版本和發(fā)布版本。
（一）注冊單元劃分原則
1. 獨立軟件
獨立軟件的注冊單元以管理類別、預期用途、處理對象和臨床功能模塊作為劃分原則。
（1）不同管理類別的獨立軟件應作為不同注冊單元，在無法分割的情況下可作為一個注冊單元并按照較高管理類別注冊申報。
（2）不同預期用途的獨立軟件應作為不同注冊單元，按照預期用途大體上可分為治療計劃類、診斷類、監(jiān)護類和信息管理類。
（3）不同處理對象的獨立軟件應作為不同注冊單元，按照處理對象大體上可分為圖像類和數據類。
（4）對于功能龐大復雜的獨立軟件，應依據臨床功能模塊的類型和數量劃分注冊單元，每個注冊單元所含模塊的數量應適中。按照模塊功能可分為平臺功能軟件和特定功能軟件，其中平臺功能軟件作為軟件平臺提供基本功能和共用功能，支持多種模式的圖像或數據，而特定功能軟件運行于平臺功能軟件并提供特定功能，支持單一模式的圖像或數據，或實現某一特定預期用途。
例如，某PACS包含數十個獨立的臨床功能模塊，并含有CAD類模塊，可以拆分為一個平臺功能軟件和多個特定功能軟件，其中CAD類模塊應作為單獨的注冊單元。
2. 軟件組件
軟件組件不符合醫(yī)療器械的定義，不宜單獨注冊申報，應隨醫(yī)療器械產品注冊申報，注冊單元與醫(yī)療器械產品相同。
專用型獨立軟件視為軟件組件時，要求與軟件組件相同。
（二）檢測單元劃分原則
檢測單元是指同一注冊單元內用于檢測的代表產品。
1. 獨立軟件
獨立軟件的檢測單元原則上與注冊單元一致，但如有多個運行環(huán)境或多個發(fā)布版本，則每個互不兼容的運行環(huán)境或每個互不涵蓋的發(fā)布版本均應作為一個檢測單元。
2. 軟件組件
軟件組件的檢測單元原則上與醫(yī)療器械產品一致，但醫(yī)療器械產品如包含多個軟件組件或多個發(fā)布版本的軟件組件，則每個軟件組件或每個發(fā)布版本的軟件組件均應作為一個檢測單元，除非檢測單元完整覆蓋注冊單元全部情況。
專用型獨立軟件視為軟件組件時，檢測單元原則上與軟件組件相同，但如有多個運行環(huán)境，則每個互不兼容的運行環(huán)境均應作為一個檢測單元。
本指導原則未提及的注冊申報資料應符合《關于公布醫(yī)療器械注冊申報資料要求和批準證明文件格式的公告》的要求。
（一）產品注冊
1. 產品名稱與結構組成
（1）獨立軟件
產品名稱應為通用名稱，并符合相關法規(guī)、規(guī)范性文件的要求，可以結合人體部位（如胸部、心臟等）、臨床科室（如骨科、神經外科等）、處理對象（如CT圖像、MRI圖像、心電數據等）和功能用途（如計劃、處理、CAD等）進行命名。
結構組成應包括物理組成和邏輯組成，其中物理組成描述軟件的存儲介質或交付方式，如光盤、U盤、預裝于計算機交付或網絡下載交付等；邏輯組成描述軟件的臨床功能模塊，包括服務器（如適用）和客戶端，注明選裝和模塊版本。
（2）軟件組件
軟件組件無相應要求。
專用型獨立軟件視為軟件組件時，軟件名稱與獨立軟件要求相同，結構組成應明確軟件的名稱、型號規(guī)格和發(fā)布版本。
2. 軟件研究資料
制造商應單獨提供一份軟件描述文檔，具體要求詳見第三節(jié)。
鑒于進口醫(yī)療器械軟件不一定在中國同步注冊，即該軟件在境外已多次注冊變更但在中國為首次產品注冊，此時軟件描述文檔應涵蓋申報范圍內的全部研究資料。
3. 軟件版本
制造商應單獨出具一份軟件版本命名規(guī)則真實性聲明，具體要求詳見第五節(jié)。
對于獨立軟件（含專用型獨立軟件視為軟件組件的情況）和控制型軟件組件，注冊檢測報告應包含軟件完整版本和軟件發(fā)布版本的界面照片。對于進口醫(yī)療器械軟件，制造商應提供此發(fā)布版本軟件在原產國獲準上市的證明性文件。
4. 產品技術要求
（1）獨立軟件
獨立軟件產品技術要求應在“產品型號/規(guī)格及其劃分說明”中明確軟件的名稱、型號規(guī)格、發(fā)布版本和版本命名規(guī)則，而“性能指標”分為通用要求、質量要求、專用要求和安全要求，其中通用要求應根據軟件自身特性進行規(guī)范，質量要求應符合GB/T 25000.51《軟件工程 軟件產品質量要求與評價（SQuaRE） 商業(yè)現貨（COTS）軟件產品的質量要求與測試細則》的要求，專用要求應符合相關性能標準（如放射治療）的要求，安全要求應符合相關安全標準（如報警、放射治療）的要求。
獨立軟件產品技術要求模板詳見附錄I。
（2）軟件組件
軟件組件應在醫(yī)療器械產品技術要求中進行規(guī)范，其中“產品型號/規(guī)格及其劃分說明”應明確軟件的名稱、型號規(guī)格、發(fā)布版本、版本命名規(guī)則、運行環(huán)境（控制型軟件組件適用，包括硬件配置、軟件環(huán)境和網絡條件），而“性能指標”應明確軟件全部臨床功能綱要。
專用型獨立軟件視為軟件組件時，要求與軟件組件相同（運行環(huán)境適用）。
5. 臨床評價資料
（1）獨立軟件
獨立軟件應依據《醫(yī)療器械臨床評價技術指導原則》提交臨床評價資料，不適用條款說明理由。對于采用人工智能算法實現的功能（如計算機輔助檢測、分類和診斷等CAD類功能），應提交基于臨床試驗的臨床評價資料。
制造商可以選取已上市醫(yī)療器械產品所含的同類軟件功能進行實質等同對比。
（2）軟件組件
軟件組件應與醫(yī)療器械產品整體開展臨床評價工作，提交醫(yī)療器械產品的臨床評價資料。軟件組件的處理功能可隨醫(yī)療器械產品進行臨床評價，也可單獨進行臨床評價，此時要求與獨立軟件相同。
專用型獨立軟件視為軟件組件時，要求與軟件組件的處理功能相同。
6. 現成軟件（如適用）
現成軟件的申報要求和版本要求詳見第六節(jié)。
7. 說明書
說明書應符合相關的法規(guī)、規(guī)范性文件、國家標準、行業(yè)標準的要求，體現軟件全部功能（包含安全功能），明確軟件發(fā)布版本。
（二）許可事項變更
1. 變更情況聲明
明確軟件和現成軟件（如適用）的版本命名規(guī)則、完整版本、發(fā)布版本和發(fā)布版本變更情況。
2. 軟件研究資料
醫(yī)療器械許可事項變更應根據軟件更新情況提交軟件變化部分對產品安全性與有效性影響的研究資料：
（1）涉及重大軟件更新：單獨提交一份軟件更新描述文檔，具體要求詳見第四節(jié)；
（2）涉及輕微增強類軟件更新：單獨提交一份軟件更新描述文檔，具體要求詳見第四節(jié)；
（3）僅發(fā)生糾正類軟件更新：提交糾正類軟件更新申報資料，具體要求詳見第四節(jié)；
（4）未發(fā)生軟件更新：出具真實性聲明。
3. 產品技術要求
（1）獨立軟件
獨立軟件產品技術要求應體現軟件更新情況，包括“產品型號/規(guī)格及其劃分說明”、“性能指標”和“附錄”。
（2）軟件組件（如適用）
醫(yī)療器械產品技術要求應體現軟件更新情況，包括“產品型號/規(guī)格及其劃分說明”中的軟件信息、“性能指標”中的軟件要求。
專用型獨立軟件視為軟件組件時，要求與軟件組件相同。
4. 現成軟件（如適用）
醫(yī)療器械許可事項變更應根據現成軟件更新情況提交軟件變化部分對產品安全性與有效性影響的研究資料：
（1）涉及重大軟件更新：單獨提交一份現成軟件更新描述文檔，具體要求詳見第六節(jié)；
（2）涉及輕微增強類軟件更新：單獨提交一份現成軟件更新描述文檔，具體要求詳見第六節(jié)；
（3）僅發(fā)生糾正類軟件更新：提交糾正類軟件更新申報資料，具體要求詳見第四節(jié)；
（4）未發(fā)生軟件更新：出具真實性聲明。
5. 說明書（如適用）
說明書應體現軟件全部功能（包含安全功能），明確軟件發(fā)布版本，提供變化情況說明。
（三）延續(xù)注冊
1. 產品未變化聲明
明確軟件和現成軟件（如適用）的版本命名規(guī)則、完整版本和發(fā)布版本。
2. 產品分析報告（如適用）
根據已注冊醫(yī)療器械軟件在后續(xù)注冊時應提交軟件更新資料的要求，醫(yī)療器械延續(xù)注冊產品分析報告第（六）項應提交相應軟件更新資料：
（1）涉及輕微增強類軟件更新：單獨提交一份軟件更新描述文檔、現成軟件更新描述文檔，具體要求詳見第四節(jié)、第六節(jié)；
（2）僅發(fā)生糾正類軟件更新：提交糾正類軟件更新申報資料，具體要求詳見第四節(jié)。
3. 特殊情形
本次注冊如涉及重大軟件更新，前次注冊所批準的事項可以延續(xù)注冊。
[1]《醫(yī)療器械注冊管理辦法》（國家食品藥品監(jiān)督管理總局令第4號）
[2]《醫(yī)療器械說明書和標簽管理規(guī)定》（國家食品藥品監(jiān)督管理總局令第6號）
[3]《醫(yī)療器械召回管理辦法（試行）》（衛(wèi)生部令第82號）
[4] 國家食品藥品監(jiān)督管理總局關于發(fā)布醫(yī)療器械產品技術要求編寫指導原則的通告（國家食品藥品監(jiān)督管理總局通告2014年第9號）
[5] 國家食品藥品監(jiān)督管理總局關于公布醫(yī)療器械注冊申報資料要求和批準證明文件格式的公告（國家食品藥品監(jiān)督管理總局公告2014年第43號）
[6] 國家食品藥品監(jiān)督管理總局關于實施《醫(yī)療器械注冊管理辦法》和《體外診斷試劑注冊管理辦法》有關事項的通知(食藥監(jiān)械管[2014]144號)
[7] 國家食品藥品監(jiān)督管理總局關于發(fā)布醫(yī)療器械臨床評價技術指導原則的通告（國家食品藥品監(jiān)督管理總局通告2015年第14號）
[8] GB/T 13702-1992《計算機軟件分類代碼》
[9] GB/T 18492-2001《信息技術 系統(tǒng)及軟件完整性級別》
[10] GB/T 11457-2006《信息技術 軟件工程術語》
[11] GB/T 20157-2006《信息技術 軟件維護》
[12] GB/T 19003-2008《軟件工程 GB/T 19001-2000應用于計算機軟件的指南》
[13] GB/T 25000.51-2010《軟件工程 軟件產品質量要求與評價（SQuaRE） 商業(yè)現貨（COTS）軟件產品的質量要求與測試細則》
[14] YY 0637-2013《醫(yī)用電氣設備 放射治療計劃系統(tǒng)的安全要求》
[15] YY 0709-2009《醫(yī)用電氣設備 第1-8部分：安全通用要求 并列標準 醫(yī)用電氣設備和醫(yī)用電氣系統(tǒng)中報警系統(tǒng)的測試和指南》
[16] YY 0721-2009《醫(yī)用電氣設備 放射治療記錄與驗證系統(tǒng)的安全》
[17] YY 0775-2010《遠距離放射治療計劃系統(tǒng) 高能X(γ）射束劑量計算準確性要求和試驗方法》
[18] YY 0831.1-2011《γ射束立體定向放射治療系統(tǒng) 第1部分：頭部多源γ射束立體定向放射治療系統(tǒng)》
[19] YY 0832.1-2011《X射線放射治療立體定向及計劃系統(tǒng) 第1部分：頭部X射線放射治療立體定向及計劃系統(tǒng)》
[20] YY/T 0287-2003《醫(yī)療器械 質量管理體系法規(guī)要求》
[21] YY/T 0316-2008《醫(yī)療器械 風險管理對醫(yī)療器械的應用》
[22] YY/T 0664-2008《醫(yī)療器械軟件 軟件生存周期過程》
[23] YY/T 0708-2009《醫(yī)用電氣設備 第1-4部分：安全通用要求 并列標準 可編程醫(yī)用電氣系統(tǒng)》
[24] YY/T 0887-2013《放射性粒籽植入治療計劃系統(tǒng)劑量計算要求和試驗方法》
[25] YY/T 0889-2013《調強放射治療計劃系統(tǒng)性能和試驗方法》
[26] FDA, Do It by Design - An Introduction to Human Factors in Medical Devices, December, 1996
[27] FDA, Deciding When to Submit a 510(k) for a Change to an Existing Device, January 10, 1997
[28] FDA, Reviewer Guidance for a Premarket Notification Submission for Blood Establishment Computer Software, January 13,1997
[29] FDA, Design Control Guidance for Medical Device Manufacturers, March 11, 1997
[30] FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 29,1998
[31] FDA, Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices, September 9,1999
[32] FDA, Guidance for the Submission of Premarket Notifications for Medical Image Management Devices, July 27, 2000
[33] FDA, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002
[34] FDA, Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software, January 14, 2005
[35] FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 11, 2005
[36] FDA, Guidance for Industry and FDA Staff - Modifications to Devices Subject to Premarket Approval (PMA) - The PMA Supplement Decision, December 11, 2008
[37] FDA, Guidance for Industry and Food and Drug Administration Staff - Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Notification [510(k)] Submissions, July 3, 2012
[38] FDA, Guidance for Industry and FDA Staff - Clinical Performance Assessment: Considerations for Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Approval (PMA) and Premarket Notification [510(k)] Submissions, July 3, 2012
[39] FDA, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices - Guidance for Industry and Food and Drug Administration Staff, October 2, 2014
[40] FDA, Mobile Medical Applications - Guidance for Industry and Food and Drug Administration Staff, February 9, 2015
[41] FDA, Medical Device Data Systems, Medical Image Storage Devices and Medical Image Communications Devices - Guidance for Industry and Food and Drug Administration Staff, February 9, 2015
[42] FDA, General Wellness: Policy for Low Risk Devices - Draft Guidance for Industry and Food and Drug Administration Staff, January 20, 2015
[43] MEDDEV 2.7/1 Rev.3, Clinical evaluation: Guide for manufacturers and notified bodies, December 2009
[44] MEDDEV 2.7/4, Guidelines on Clinical investigations: a guide for manufacturers and notified bodies, December 2010
[45] MEDDEV 2.1/6, Qualification and Classification of standalone software, January 2012
[46] NB-MED/2.2/Rev4, Software and Medical Devices, March 29, 2010
[47] Team-NB, Frequently Asked Questions related to the Implementation of EN 62304:2006 with respect to MDD 93/42/EEC, April 5, 2013
[48] IEC 62366 Ed1.1:2014, Medical devices - Application of usability engineering to medical devices
[49] IEC/TR 80002-1:2009, Medical device software - Part 1: Guidance on the application of ISO 14971 to medical device software
[50] IEC80001-1:2010, Application of risk management for IT-networks incorporating medical devices - Part 1: Roles,responsibilities and activities
[51] IEC/TR 80001-2-1:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-1: Step-by-step risk management of medical IT-networks – Practical applications and examples
[52] IEC/TR 80001-2-2:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-2: Guidance for the disclosure and communication of medical device security needs, risks and controls
[53] IEC/TR 80001-2-3:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-3: Guidance for wireless networks
[54] IEC/TR 80001-2-4:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-4: Application guidance - General implementation guidance for healthcare delivery organizations
[55] IEC 62304 am1, Medical device software - Software life cycle processes
[56] IEC 82304-1, Health Software - Part 1: General requirements for product safety
[57] IEC/TR 80002-2, Medical device software - Part 2: Validation of software for regulated processes
[58] IMDRF/UDI WG/N7FINAL:2013, UDI Guidance: Unique Device Identification of Medical Devices,December18, 2013
[59] IMDRF/SaMD WG/N10FINAL:2013, Software as a Medical Device: Key Definitions, December18, 2013
[60] IMDRF/SaMD WG/N12FINAL:2014, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations,September18, 2014
附錄I
醫(yī)療器械產品技術要求編號：
產品名稱
1. 產品型號/規(guī)格及其劃分說明
1.1 軟件型號規(guī)格
1.2 軟件發(fā)布版本
1.3 版本命名規(guī)則
明確軟件完整版本的全部字段及字段含義
2. 性能指標
2.1 通用要求
2.1.1 處理對象
明確軟件的處理對象類型，如圖像（如CT、MRI、X-ray、PET、US等）、數據（如心電、血壓、血氧、血糖等）
2.1.2 最大并發(fā)數
明確軟件的最大并發(fā)用戶數、患者數
2.1.3 數據接口
明確軟件的通用數據接口（如Dicom、HL7）、產品接口（可聯合使用的獨立軟件、醫(yī)療器械硬件）
2.1.4 特定軟硬件
明確軟件完成預期用途所必備的獨立軟件、醫(yī)療器械硬件
2.1.5 臨床功能
依據說明書明確軟件全部臨床功能綱要（注明可選）
2.1.6 使用限制
依據說明書明確軟件的使用限制
2.1.7 用戶訪問控制
明確軟件的用戶訪問控制管理機制
2.1.8 版權保護
明確軟件的版權保護技術
2.1.9 用戶界面
明確軟件的用戶界面類型
2.1.10 消息
明確軟件的消息類型
2.1.11 可靠性
明確軟件出錯后數據保存與恢復能力
2.1.12 維護性
明確軟件向用戶提供的維護信息類型
2.1.13 效率
明確軟件在典型配置條件下完成典型臨床功能所需的時間
2.1.14 運行環(huán)境
明確軟件運行所需的硬件配置、軟件環(huán)境和網絡條件，包括服務器（如適用）和客戶端的要求
2.2 質量要求
符合GB/T 25000.51第5章要求
2.3 專用要求 （如適用）
注：依據相應標準條款逐條描述
2.3.1 YY 0775（如適用）
……
2.4 安全要求 （如適用）
注：列明相應安全標準名稱即可
2.4.1 YY 0709（如適用）
2.4.2 YY 0637（如適用）
2.4.3 YY 0721（如適用）
……
3. 檢驗方法
3.1 通用要求符合性檢驗
通過檢查說明書、實際操作驗證2.1的符合性。
3.2 質量要求符合性檢驗
依據GB/T 25000.51第7章方法驗證2.2的符合性。
3.3 專用要求檢驗方法（如適用）
3.3.1依據YY 0775的方法進行檢驗（如適用）。
……
3.4 安全要求檢驗方法（如適用）
3.4.1 依據YY 0709的方法進行檢驗（如適用）。
3.4.2 依據YY 0637的方法進行檢驗（如適用）。
3.4.3 依據YY 0721的方法進行檢驗（如適用）。
……
4. 術語（如適用）
4.1 ……
4.2 ……
……
（分頁）
附錄
1.體系結構圖及必要注釋
2.用戶界面關系圖及必要注釋
3.物理拓撲圖及必要注釋
一、編寫目的和依據
本指導原則旨在指導制造商提交醫(yī)療器械軟件注冊申報資料，同時也規(guī)范醫(yī)療器械軟件的技術審評要求。
本指導原則是在現行法規(guī)和標準體系以及當前認知水平下、并參考了國外法規(guī)與指南、國際標準與技術報告制定的，特別是借鑒了IMDRF相關工作組（SaMD、UDI）的文件。隨著法規(guī)和標準的不斷完善，以及認知水平和技術能力的不斷提高，相關內容也將適時進行修訂。另外，為了保證可讀性，本指導原則的部分內容有意留有冗余信息。
二、有關內容說明
軟件沒有物理實體，具有特殊性。為了達到監(jiān)管目的同時促進行業(yè)發(fā)展，本指導原則在現行法規(guī)框架下針對軟件的特殊性進一步明確了軟件的監(jiān)管要求，特別是對軟件更新、軟件版本的要求。
本指導原則是醫(yī)療器械軟件的通用指導原則，其他涉及軟件醫(yī)療器械產品的指導原則可在本指導原則基礎上進行有針對性的調整、修改和完善。
軟件只有結合風險管理、質量管理和軟件工程的要求才能保證質量，因此良好的軟件生存周期過程對于保證軟件質量至關重要。制造商應基于YY/T 0664-2008《醫(yī)療器械軟件 軟件生存周期過程》建立起與軟件安全性級別相匹配的軟件生存周期過程，并作為自身質量管理體系的組成部分。
軟件描述文檔于2010年12月1日（YY/T 0708-2009《醫(yī)用電氣設備 第1-4部分：安全通用要求 并列標準 可編程醫(yī)用電氣系統(tǒng)》實施時間）開始要求，基于近五年的實施情況和反饋意見進行了修改和調整。部分條款名稱進行了文字性修改，以保證用語更規(guī)范更準確，具體為：“產品標識”改為“軟件標識”，“硬件關系”改為“硬件拓撲”，“上市歷史”改為“注冊歷史”，“開發(fā)綜述”改為“開發(fā)概述”、“需求規(guī)格”改為“需求規(guī)范”、“修訂歷史”改為“更新歷史”。同時，部分條款內容也進行了修改和調整，具體為：“結構功能”強化了用戶界面關系圖和臨床功能模塊的要求；“適用范圍”和“禁忌癥”明確進口軟件描述原產國的情況，刪除了適用人群的要求；“注冊歷史”強化了原產國的要求，不再強調美國、歐盟和日本的情況；“開發(fā)概述”刪除了生存周期模型和控制文檔總數的要求；“需求規(guī)范”簡化了A級軟件的要求；“生存周期”將“各階段輸入輸出文檔”改為“設計歷史文檔集索引表（DHF）”，細化了附件要求；“驗證與確認”刪除了單元測試覆蓋率和集成測試集成策略的要求，簡化了測試報告的申報資料要求，C級軟件增加了可追溯性分析報告的要求，驗證活動細化了附件要求；“更新歷史”強化了更新具體內容的要求；“核心算法”范圍與IMDRF保持一致，同時為了避免涉及商業(yè)秘密并參考IMDRF要求將“原理”改為“臨床功能”，A級軟件統(tǒng)一了公認成熟算法和全新算法的要求。
軟件可追溯性分析是保證軟件質量的重要技術手段，美國和歐盟均要求全面開展軟件可追溯性分析工作。考慮到境內制造商存在一定實施難度，故本指導原則僅對C級軟件進行了要求，A級和B級軟件未做要求。但從技術發(fā)展趨勢而言，今后將在適當時機要求制造商全面開展軟件可追溯性分析工作。
重大軟件更新和輕微軟件更新不存在清晰明確的劃分界線，需要具體情況具體分析。本指導原則綜合考慮監(jiān)管目標和行業(yè)發(fā)展的關系，基于現有的認知水平、技術能力和監(jiān)管資源明確了重大軟件更新的范圍，今后會隨著認知水平與技術能力的提高、不良事件與召回事件的分析動態(tài)調整重大軟件更新的范圍。
軟件沒有物理實體，只能通過狀態(tài)管理保證質量。軟件版本用于標識軟件狀態(tài)和控制軟件更新，與軟件是相互對應的表里關系，即軟件版本是軟件標識不可或缺的組成部分，因此可以基于軟件版本實現軟件監(jiān)管目的，特別是對軟件更新的監(jiān)管，但前提是軟件版本命名規(guī)則是真實有效的。
本指導原則所述現成軟件僅包含應用軟件,暫不包含系統(tǒng)軟件和支持軟件。這是基于當前技術審評側重的考慮，并不意味制造商可以放棄對系統(tǒng)軟件和支持軟件的質量管理，現成軟件的范圍今后將在適當時機下擴至系統(tǒng)軟件和支持軟件。同時，也是基于現成軟件僅包含應用軟件的考慮，現成軟件的軟件描述文檔增加了核心算法的要求，但內容進行了簡化；對于全部采用遺留軟件的開發(fā)方式，增加了上市后臨床評價資料的要求。
獨立軟件目前尚無醫(yī)療器械產品標準，產品技術要求暫以通用軟件產品標準GB/T 25000.51-2010《軟件工程 軟件產品質量要求與評價（SQuaRE） 商業(yè)現貨（COTS）軟件產品的質量要求與測試細則》作為參考，但由于該標準不是醫(yī)療器械產品標準，相應要求不能完全滿足監(jiān)管要求，因此產品技術要求模板進行了適當調整。今后，獨立軟件產品技術要求模版將隨著國家標準和行業(yè)標準的實施情況進行調整。
醫(yī)療器械軟件功能眾多，難以統(tǒng)一臨床評價要求。本指導原則依據《醫(yī)療器械臨床評價技術指導原則》明確了軟件臨床評價的一般原則，制造商應根據相關法規(guī)、規(guī)范性文件的要求并結合軟件自身特性開展相應的臨床評價工作。
說明書是評價軟件質量的重要依據，因此說明書應真實、準確和完整的體現軟件當前狀態(tài)。由于軟件更新情況復雜，某些情況下僅依靠說明書的變化內容無法評估軟件當前狀態(tài)，特別是對重大軟件更新。因此，軟件更新仍需提交軟件當前狀態(tài)下的全部說明書，并提交變化情況說明，除非軟件更新內容未在說明書中體現。
隨著網絡技術的快速發(fā)展，越來越多的醫(yī)療器械具有聯網功能，信息安全問題隨之產生，近來美國和歐盟均加強了醫(yī)療器械信息安全的監(jiān)管要求?？紤]到信息安全并不限于軟件，我國醫(yī)療器械信息安全監(jiān)管工作尚處于起步階段，本指導原則對軟件的信息安全提出了原則性要求，今后將在適當時機下單獨制定醫(yī)療器械信息安全技術審查指導原則。
三、起草單位
國家食品藥品監(jiān)督管理總局醫(yī)療器械技術審評中心。
編輯：網絡 TAG：/2015年第50號/醫(yī)療器械軟件注冊
京公網安備 11010502043733號??京ICP備16013397號-1??XML地圖 ?網站地圖?熱門TAG?2018最新《醫(yī)療器械分類目錄》
