醫療器械創新網
序號及項目 |
舊版 |
新版 |
1指導原則的地位 |
本指導原則是醫療器械軟件的通用指導原則 |
本指導原則是數字醫療（Digital Health）指導原則體系的基礎指導原則，亦是醫療器械軟件的通用指導原則 |
2.范圍 |
本指導原則適用于醫療器械軟件的注冊申報，包括第二類、第三類醫療器械產品，適用的軟件開發方式包括自主開發、部分采用現成軟件和全部采用現成軟件。 |
本指導原則適用于醫療器械軟件的注冊申報，包括第二、三類獨立軟件和含有軟件組件的醫療器械（包括體外診斷醫療器械）；適用于自研軟件、現成軟件的注冊申報。 本指導原則也可用作醫療器械軟件、質量管理軟件的體系核查參考。 |
3.主要概念 |
/ |
醫用中間件是醫療器械軟件正常運行所必需的，故作為醫療器械軟件的組成部分予以考慮。 |
/ |
有些支持軟件（如VTK、ITK）自帶算法庫，醫療器械軟件開發過程已將算法庫相關內容集成于自身內部，故醫療器械軟件正常運行需要這些支持軟件的支持。 |
|
/ |
必備軟件:醫療器械軟件正常運行所必需的其他的醫療器械軟件及醫用中間件 |
|
/ |
外部軟件環境:正常運行所必需的系統軟件、通用應用軟件、通用中間件、支持軟件 |
|
4.生存周期 |
A級提供軟件開發生存周期計劃摘要，描述開發各階段的劃分情況和工作任務。B級在A級基礎上提供配置管理計劃摘要和維護計劃摘要，描述所用的工具和流程。C級在B級基礎上提供設計歷史文檔集索引表（DHF）。 生存周期也可提交制造商軟件生存周期過程文件或YY/T 0664《醫療器械軟件軟件生存周期過程》等過程標準的核查表，用于替代相應描述。 |
軟件生存周期（又稱軟件生命周期）是指軟件系統從概念定義至停止使用的時間周期，包括軟件開發策劃、軟件需求分析、軟件設計、軟件編碼、軟件測試、軟件發布、軟件部署、軟件維護、軟件停運等階段。 |
5.生存周期模型 |
/ |
軟件生存周期模型是指一組包含過程、活動和任務的框架，跨越從軟件需求分析到軟件停運的軟件生存周期過程，每個過程可細分為若干活動，每個活動又可細分為若干任務。 |
6.軟件驗證 |
驗證是指通過提供客觀證據認定軟件某開發階段的輸出滿足輸入要求，包括代碼檢查、設計評審、測試等質量保證活動。 |
軟件驗證是指通過提供客觀證據認定軟件開發、軟件維護某一階段的輸出滿足輸入要求。軟件驗證包括源代碼審核、靜態和動態分析/測試、單元測試、集成測試、系統測試、設計評審等系列活動，是軟件確認的基礎。 |
7.軟件測試 |
A級提供系統測試、用戶測試的計劃和報告摘要，描述測試的條件、工具、方法、通過準則和結果。B級提供系統測試、用戶測試的計劃和報告，概述開發各階段的驗證活動，描述所用的工具、方法和任務。 |
軟件測試是軟件質量保證的基本措施，也是軟件驗證、軟件確認的重要方法，從不同角度有不同分類方法。 單元測試是對軟件單元進行測試，通常采用白盒測試.集成測試是對軟件項（由若干軟件單元組成，即軟件模塊）進行測試，白盒測試、黑盒測試、灰盒測試相結合；系統測試是對軟件系統（由若干軟件項組成）進行測試，通常采用黑盒測試，其從測試內容角度又可分為功能測試、性能測試、并發測試、壓力測試、接口測試、內存測試、兼容性測試、用戶界面測試、安裝卸載測試、安全測試等。 內部測試是指注冊申請人實施的測試，包括單元測試、集成測試、系統測試，白盒測試、黑盒測試、灰盒測試相結合；用戶測試是指預期用戶在真實或模擬使用場景對軟件系統進行測試，采用黑盒測試；第三方測試是指第三方機構對軟件系統進行測試，通常采用黑盒測試。 回歸測試是指用于確定軟件更新沒有產生不良影響且未引入風險不可接受新缺陷的軟件測試。 |
8.軟件確認 |
確認是指通過提供客觀證據認定軟件滿足用戶需求和預期用途，通常是指在真實或模擬使用環境進行的用戶測試。 |
軟件確認是基于過程控制的設計確認，包括用戶測試、臨床評價、設計評審等系列活動，即要保證軟件滿足用戶需求和預期用途，又要確保軟件已知剩余缺陷的風險均可接受。 |
9.軟件可追溯分析報告 |
C級在B級基礎上提供可追溯性分析報告（追溯需求規范、設計規范、測試、風險管理的關系表）。 |
注冊申請人應建立軟件可追溯性分析過程，規范軟件可追溯性分析相關活動要求，以保證軟件驗證、軟件確認的質量?？紤]到行業實際情況，源代碼追溯分析活動追溯至軟件單元（列明名稱）即可。 |
10.軟件完整版本和UDI |
/ |
從醫療器械唯一標識（UDI）角度，軟件完整版本屬于生產標識（PI）的組成部分。 |
11.?檢測報告 |
檢測報告提供軟件版本界面照片或列明軟件版本信息，有用戶界面的軟件體現軟件發布版本、軟件完整版本，無用戶界面的軟件體現軟件完整版本。說明書注明軟件發布版本。 |
|
12.軟件算法 |
核心算法是指實現軟件核心功能（軟件在預期使用環境完成預期用途所必需的功能）所必需的算法，包括但不限于成像算法、后處理算法和人工智能算法。其中成像算法是指用于獲取醫學圖像或數據的算法，后處理算法是指改變原始醫學圖像或數據產生新臨床信息的算法，人工智能算法是指采用人工智能技術進行醫學圖像或數據分析的算法。 算法類型包括公認成熟算法和全新算法。其中公認成熟算法是指源自公開文獻資料、原理簡單明確、上市多年且無不良事件的算法，而全新算法是指源自臨床研究、科學研究的新算法。 |
軟件算法從重要性角度可分為核心算法和非核心算法，其中核心算法是指實現軟件核心功能所必需的算法，反之即為非核心算法。 從復雜性角度可分為簡單算法和復雜算法，前者原理簡單明確或基于成熟公式，后者通?；谀Ｐ脱芯?，存在諸多假設條件且影響因素較多，同時二者在算法規模、參數數量、運算速度等方面亦存在差異。從可解釋性角度可分為白盒算法和黑盒算法，前者可與現有知識建立關聯，后者難與現有知識建立關聯，前者可解釋性優于后者。 |
12.軟件功能 |
/ |
軟件功能從不同角度出發有不同分類方法。從重要性角度可分為核心功能和非核心功能，其中核心功能是指軟件在預期使用場景完成預期用途所必需的功能，反之即為非核心功能。 從技術特征角度大體上可分為處理功能、控制功能、安全功能，其中處理功能是指加工醫療器械數據（即醫療器械產生的用于醫療用途的客觀數據）或基于模型計算（如輻射劑量模型、藥代模型）的功能，控制功能是指控制/驅動醫療器械硬件運行的功能，安全功能是指保證醫療器械安全性的功能。 處理功能從數據流角度又可分為前處理功能和后處理功能，前者是指采集人體解剖、生理信息生成醫療器械數據過程的處理功能，后者是指利用醫療器械數據生成診療信息或進行醫療干預過程的處理功能;?后處理功能從復雜性角度又可分為簡單功能和復雜功能，前者是指對現有醫療信息進行操作而非生成新醫療信息的功能，后者是指生成新醫療信息的功能; 從監管范圍角度可分為醫療器械功能和非醫療器械功能，其中醫療器械功能是指可用作醫療器械界定依據的軟件功能，反之即為非醫療器械功能，實現醫療器械功能所必需的患者信息管理功能屬于醫療器械功能。二者盡量通過模塊化設計予以拆分，若在技術上無法拆分需將非醫療器械功能作為醫療器械軟件的組成部分予以整體考慮。 |
13.?軟件用途 |
軟件用途通?？煞譃檩o助決策和非輔助決策，其中輔助決策是指通過提供診療活動建議輔助用戶（如醫務人員、患者）進行醫療決策;僅提供醫療參考信息而不進行醫療決策即為非輔助決策. 實時性角度均可細分為實時和非實時，前者風險通常高于后者。故軟件功能從軟件用途角度又可分為輔助決策類功能和非輔助決策類功能、實時功能和非實時功能。 |
|
14安全性級別確定依據 |
軟件安全性級別應結合軟件的預期用途、使用環境和核心功能（軟件在預期使用環境完成預期用途所必需的功能）進行判定。其中預期用途主要考慮軟件的臨床用途（如診斷、治療、監護、篩查等）和重要程度（如重要作用、輔助作用、補充作用等），使用環境主要考慮軟件的使用場所（如醫院、家庭等）、疾病類型（如嚴重性、緊迫性、傳染性等）、患者人群（如成人、兒童、老年、女性等）和用戶類型（如專業用戶、普通用戶、患者等），核心功能主要考慮軟件的功能類型（如控制驅動、處理分析等）、實現方法（如CT圖像重建采用濾波反投影算法還是迭代算法，異常識別采用常規圖像處理算法還是人工智能算法等）和復雜程度（如算法規模、參數數量、運算速度等）。 |
軟件安全性級別可結合軟件的預期用途、使用場景、核心功能進行綜合判定。其中，預期用途主要考慮軟件的用途類型（如治療、診斷、監護、篩查）、重要程度（如重要作用、參考作用、補充作用）、緊迫程度（如危重情形、嚴重情形、普通情形）、成熟程度（成熟、全新）等因素，使用場景主要考慮軟件的使用場所（如門診、手術、住院、急救、家庭、轉運、公共場所）、疾病特征（如嚴重性、緊迫性、傳染性）、適用人群（如成人、兒童、老人、孕婦）、目標用戶（如醫務人員、患者）等因素，核心功能主要考慮軟件的功能類型（如重要程度、技術特征、復雜程度、成熟程度）、核心算法（如重要程度、復雜程度、可解釋性、成熟程度）、輸入輸出（輸入數據如醫學圖像、生理參數、體外診斷等數據，輸出結果如處理、測量、分析等結果）、接口（如應用程序接口（API）、數據接口、產品接口）等因素。 |
15.?全生命周期質控 |
/ |
上市前開展充分有效的軟件驗證與確認活動，識別軟件可預見的風險并將其降至可接受水平。上市后繼續開展軟件質量保證工作，結合用戶投訴、不良事件和召回等情況識別前期未預見的風險，并采取必要措施保證軟件質量；同時，基于軟件更新需求的評估，實施軟件更新活動以滿足用戶新需求，并開展與之相適宜的軟件驗證與確認活動，以保證軟件更新質量；此外，軟件停運考慮用戶告知與后續服務、數據遷移、患者數據與隱私保護等要求。 |
16軟件更新 |
軟件版本控制中的各種更新。 |
需考慮現成軟件組件和外部軟件環境的更新，并開展外部軟件環境更新的影響評估工作。 |
17.?質量管理軟件 |
/ |
質量管理軟件是指醫療器械質量管理所用的應用軟件，非醫療器械軟件，無需申報注冊。質量管理軟件與醫療器械軟件在技術層面具有相同之處，故可參照醫療器械軟件相關要求考慮質量管理軟件的確認要求。 質量管理軟件參照醫療器械軟件可分為類獨立軟件和類軟件組件，前者包括設計開發所用軟件、流程管理所用軟件等，后者包括生產設備所含軟件、檢驗設備所含軟件等。 |
18.獨立軟件注冊單元劃分 |
不同預期用途的獨立軟件應作為不同注冊單元，按照預期用途大體上可分為治療計劃類、診斷類、監護類和信息管理類。 |
不同預期用途的獨立軟件作為不同注冊單元，按照預期用途可分為輔助決策類和非輔助決策類，每類又可細分為治療、診斷、監護、篩查等情形。 |
19.檢測單元劃分原則 |
獨立軟件檢測單元原則上與注冊單元相同 有多個運行環境或多個發布版本，則每個互不兼容的運行環境（含云計算）或每個互不涵蓋的發布版本均需作為一個檢測單元。 |
獨立軟件檢測單元原則上與注冊單元相同 有多個運行環境或多個發布版本，則每個互不兼容的運行環境（含云計算）或每個互不涵蓋的發布版本均需作為一個檢測單元。 若軟件核心功能相同但核心算法類型不同，則每類核心算法所對應的核心功能均需檢測（檢測對象為核心功能而非核心算法）。 同理，若軟件核心功能相同但核心算法類型不同，則每類核心算法所對應的核心功能均需檢測。 |
20.臨床評價 |
獨立軟件應依據《醫療器械臨床評價技術指導原則》提交臨床評價資料，不適用條款說明理由。對于采用人工智能算法實現的功能（如計算機輔助檢測、分類和診斷等CAD類功能），應提交基于臨床試驗的臨床評價資料。 制造商可以選取已上市醫療器械產品所含的同類軟件功能進行實質等同對比。 |
獨立軟件通常基于軟件功能進行臨床評價，必要時可基于軟件算法進行臨床評價。臨床評價需結合獨立軟件的預期用途和成熟度予以綜合考慮，可選擇已上市醫療器械所含同類軟件功能進行同品種醫療器械比對。 非輔助決策類軟件功能基于核心功能進行同品種醫療器械比對。全新的核心算法、核心功能、預期用途原則上均需開展臨床評價。簡單操作類、單純流程優化類軟件功能可通過非臨床證據予以評價。 輔助決策類軟件功能基于核心算法進行同品種醫療器械比對，所選同品種醫療器械的臨床證據原則上需基于臨床試驗（含回顧性研究，下同）。全新的核心算法、核心功能、預期用途原則上均需開展臨床試驗。臨床試驗若采用陽性對照設計，可選擇預期用途相同且核心算法或核心功能等同的獨立軟件進行對照。 |
21.網絡安全 |
/ |
醫療器械網絡安全需從網絡安全角度綜合考慮信息安全和數據安全。醫療器械軟件若具備電子數據交換、遠程訪問與控制、用戶訪問三種功能當中一種及以上功能，均需考慮網絡安全問題，具體要求詳見醫療器械網絡安全相關指導原則。 |
22.?人因與可用性 |
/ |
建議加強醫療器械軟件用戶界面的人因設計以提升可用性，將用戶錯誤使用的風險降至可接受水平，具體要求詳見醫療器械人因設計相關指導原則。 |
23.?互操作性 |
/ |
互操作性（又稱互用性）是指醫療器械與其他醫療器械或通用設備通過電子接口交換并使用信息的能力。其中電子接口包含硬件接口和軟件接口，信息包括但不限于醫學圖像、生理參數、體外診斷等數據和控制指令。 互操作性重點關注醫療器械軟件的接口設計及其風險，接口包括內部接口和外部接口，前者是指軟件模塊之間的接口，后者是指供用戶調用的接口，分體式醫療器械各獨立部分的內部接口視為外部接口，如服務器與客戶端、主機與從機的內部接口。從用戶角度出發軟件接口若無明示均指外部接口。 注冊申請人需考慮軟件接口的需求分析、風險管理、驗證與確認、維護計劃等活動要求，以及說明書與標簽的設計要求。 注冊申請人可單獨提交一份互操作性研究資料，內容包括基本信息、需求規范、風險管理、驗證與確認、維護計劃；亦可在自研軟件研究報告相關條款中體現軟件接口要求， |
24.?測量功能 |
/ |
測量功能（又稱量化、定量功能）可分為圖形學測量功能、客觀物理測量功能，前者基于圖形學間接反映客觀事物的測量結果，后者直接反映客觀事物的測量結果。無論何種測量功能均需結合測量的誤差、不確定度等因素，明確測量準確性指標，如線性度、精度、重復性、再現性、范圍限值、顯示誤差等。 注冊申請人需提供測量準確性的研究資料，并在說明書中向用戶告知。此外，客觀物理測量還需在產品技術要求中明確準確性指標，圖形學測量還需在說明書中提供關于測量準確性的警示信息。 |
25．遠程訪問與控制 |
/ |
對于遠程訪問與控制（含遠程維護與升級）功能，需明確相關功能的性能指標要求和網絡安全要求，具體要求詳見醫療器械網絡安全相關指導原則。 注冊申請人需在軟件研究資料、網絡安全研究資料中提供相應研究資料，在產品技術要求中明確性能指標要求，并在說明書中向用戶告知相應功能的使用要求（含網絡安全）。 |
26.?非醫療器械功能 |
/ |
醫療器械軟件若在技術上能夠拆分非醫療器械功能，即采用模塊化設計區分醫療器械功能和非醫療器械功能，則產品結構組成不應包含非醫療器械功能模塊，說明書若含有非醫療器械功能應予以刪除或注明為非醫療器械功能，產品技術要求不應含有非醫療器械功能。 醫療器械軟件若在技術上無法拆分非醫療器械功能，需將非醫療器械功能作為自身組成部分予以整體考慮，重點關注非醫療器械功能對于醫療器械軟件的影響及其風險。 |
27.?植入物產品設計軟件 |
/ |
由于植入式醫療器械風險較高，植入物產品設計軟件屬于質量管理軟件，故可參照嚴重級別的成品軟件、自研軟件要求提交軟件研究資料， |
28.?異常處理 |
/ |
異常處理（Exception handling）用于處理軟件出現的異常狀況，及時將軟件異常信息告知用戶，以采取風險控制措施保證安全有效性。 |
29.?功能安全與軟件可靠性 |
/ |
考慮到行業實際情況，功能安全、軟件可靠性暫不要求，待時機成熟時納入考量。建議注冊申請人參考相關標準要求加強功能安全、軟件可靠性的設計工作，若已開展相應工作可在軟件研究資料中予以提供。 |
30.?GB/T 25000.51實施要求 |
獨立軟件寫入產品技術要求，“使用質量”不適用。 軟件組件不要求。 |
GB/T 25000.51適用于醫療器械軟件，其中“產品說明要求”、“用戶文檔集要求”適用于說明書，“軟件質量要求”適用于軟件本身，同時“使用質量”不適用。 在技術要求中刪除GB/T 25000.51，注冊申請人需在軟件研究資料中提交GB/T 25000.51自測報告，亦可提交自檢報告或檢驗報告代替自測報告. 軟件組件也應按GB/T 25000.51進行檢測。 |
31.?進口醫療器械軟件 |
/ |
進口醫療器械軟件若存在中外差異，如語言差異、軟件功能刪減、適用范圍縮減等，需在軟件研究資料中提交本次申報軟件與原產國獲準上市版本軟件的中外差異說明材料。 |
32軟件研究報告 |
軟件描述文檔 軟件標識 物理拓撲 需求規范：A級提供需求規范摘要，B，c級需要軟件需求規范文檔 驗證與確認：A級提供測試計劃與報告摘要，B，c級需要測試計劃與報告文檔 可追溯性分析：C級提供可追溯分析報告 臨床評價 |
自研軟件研究報告 增加：HASH值，刪除：適用范圍、禁忌癥 增加：必備軟件的物理連接關系 A,B,C級均需提供軟件需求規范文檔 A,B,C級均需提供測試計劃與報告全文 A,B,C均需要提交可追溯分析報告 刪除臨床評價 增加：結論描述 |
33.?外部軟件環境評估報告 |
外部軟件環境評估報告用于醫療器械軟件外部軟件環境（含云計算）的評估，適用于醫療器械軟件的初次發布和再次發布，內容框架詳見表3，包括安全性級別、軟件標識、功能用途、運行環境、風險管理、驗收管理、維護計劃、結論，詳盡程度取決于軟件安全性級別。 |
|
34.獨立軟件產品技術要求 |
2.1.1?處理對象 明確軟件的處理對象類型，如圖像（如CT、MRI、X-ray、PET、US等）、數據（如心電、血壓、血氧、血糖等） |
2.1.3?輸入輸出 明確軟件的輸入數據類型（如醫學圖像、生理參數、體外診斷等數據）、輸出結果類型（如處理、測量、分析等結果）。 |
|
2.1.3?數據接口 明確軟件的通用數據接口（如Dicom、HL7）、產品接口（可聯合使用的獨立軟件、醫療器械硬件） |
2.1.4?接口 明確軟件供用戶調用的應用程序接口（API）、數據接口（含傳輸協議、存儲格式，如DICOM、HL7、JPG、PNG、私有協議與格式）、產品接口（可聯合使用的其他醫療器械獨立軟件、醫療器械硬件產品）。 |
|
|
2.1.4?特定軟硬件 明確軟件完成預期用途所必備的獨立軟件、醫療器械硬件 |
2.1.5?必備軟硬件 明確軟件正常運行所必需的其他的醫療器械獨立軟件（名稱、型號規格、發布版本）及醫用中間件（名稱、型號規格、發布版本）、醫療器械硬件產品（名稱、型號規格）。 |
|
/ |
2.1.11用戶差錯防御 明確軟件對導致嚴重后果的用戶操作錯誤的防御能力。 |
|
|
2.2?質量要求 符合GB/T 25000.51第5章要求 |
/ |
|
35說明書 |
說明書應符合相關的法規、規范性文件、國家標準、行業標準的要求，體現軟件全部功能（包含安全功能），明確軟件發布版本。 |
說明書逐項說明每個軟件接口的預期用戶、使用場景、預期用途、技術特征、使用限制、故障應對措施。根據風險控制要求，標簽明確關鍵軟件接口的技術特征、使用限制。 明確軟件發布版本。 說明書必要時需明確外部軟件環境所含全部現成軟件的交付、安裝、設置、配置、更新以及使用限制、警示提示等內容。 |
