人工智能醫療器械軟件生產質量管理體系特殊要求研究

李澍，王浩，王晨希，郝燁，李佳戈，李靜莉

中國食品藥品檢定研究院 醫療器械檢定所，北京 102629

引言

醫療器械產品從前期的設計開發、設計轉化、驗證和確認到后期的設計變更、不合格品控制等各個環節都應該進行嚴格把控，才能確保產品本身的安全有效，因此為了保證每個環節不出紕漏，每個醫療器械生產企業都要建立一套完整的醫療器械生產質量管理體系[1-2]。2019年7月，國家藥品監督管理局發布《醫療器械生產質量管理規范附錄獨立軟件》，旨在加強獨立軟件類醫療器械生產監管，規范獨立軟件生產質量管理[3]。該附錄已于2020年7月1日起實施。對于獨立軟件的設計與開發，附錄提出，設計與開發應結合軟件生命周期模型的特點，建立軟件生命周期過程控制程序等要求；在生產管理方面，附錄規定應確保軟件發布的可重復性。在質量控制方面，附錄規定軟件產品需要進行安裝和卸載測試、產品完整性檢查、發布批準等活動。在不良事件的監測、分析和改進方面，附錄規定數據分析和控制程序應涵蓋軟件缺陷和網絡安全事件要求，并保存相關記錄[4-5]。

獨立軟件附錄的特殊要求中需要引起關注的就是軟件的變更控制。目前，獨立軟件附錄要求：軟件更新應當形成文件，涵蓋現成軟件、網絡安全的變更控制要求，確定軟件更新請求評估、軟件更新策劃、軟件更新實施、風險管理、驗證與確認、缺陷管理、可追溯性分析、配置管理、文件與記錄控制、評審、用戶告知等活動要求，形成相關文件和記錄并經批準。軟件版本變更應當與軟件更新情況相匹配。驗證與確認應當根據軟件更新的類型、內容和程度實施相適宜的回歸測試、用戶測試等活動[6-8]。然而，和常規軟件不同，當前以大數據與深度學習為基礎的人工智能技術存在不可解釋性和不可理解性，在動態變化的環境，或者信息不完全、存在干擾與虛假信息時，人工智能系統的性能可能會顯著下降。同時，人工智能算法的靈敏度和準確性高度依賴訓練用測試數據集，數據集的變更會對人工智能系統的判斷結果產生很大的影響。因此，訓練用數據庫如何更新、產品如何迭代，以及這種更新和迭代是否允許、允許多大程度的變更、變更如何控制，這樣的監管問題一直是討論的焦點[9-11]。因此，生產企業及監管方有必要在獨立軟件附錄基礎上，進一步研究人工智能類醫療器械（Artificial Intelligence Medical Device，AIMD）生產質量管理的特殊要求。

1 AIMD產品生命周期不同階段及討論

在開發AIMD系統時，應根據其在開發生命周期中的階段對某些考慮因素進行最佳描述，并基于這些因素考慮相應的框架。ISO/IEC 62304軟件標準[12]針對產品開發生命周期的不同階段進行了定義和說明，因此，在考慮AIMD生產質量管理規范框架模型時，可以參考現有標準，并結合AIMD的特殊性，以便將這些考慮因素整合到現有的軟件開發過程中[13]。

將全生命周期（Total Product Lifecycle，TPLC）方法應用于軟件產品的管理對于基于AIMD產品來說尤其重要，因為它能夠在真實世界使用過程中進行適應和改變。在針對TPLC認證方法中，通過評估特定公司的質量體系和組織架構，并對其軟件開發、測試和產品性能監控的質量進行評價，保證產品在TPLC中是有效的，從而增強患者、護理人員、醫療保健專業人員和其他用戶對產品安全有效性的信心[14]。

為了充分實現AIMD學習算法的強大功能，同時實現其性能的持續改進和限制退化，可以基于以下一般原則平衡利益和風險，并評估基于AIMD的安全有效性：① 對質量體系和質量管理規范建立明確的期望；② 對必要的AIMD進行上市前審查，以合理保證其安全性和有效性。并為AIMD制造商建立明確的期望，以在整個生命周期內持續管理患者風險；③ 建議制造商持續監控AIMD產品，并在算法變更的開發、驗證和執行中納入風險管理方法；④ 使用上市后真實的再評價報告，提高產品對用戶和監管部門的透明度，以持續保證產品安全性和有效性。

1.1 制定計劃階段

軟件開發計劃顯然在確保產品質量方面起著重要作用。對于AIMD產品，需要在計劃階段，說明確保數據完整性、可靠性和有效性所需的處理步驟、確定良好輸入數據的定義、確定數據是單一來源還是多種來源、明確“持續”的訓練數據來源是否與最初開發產品時使用的來源的一致、使用的數據提取工具的說明、可接受性標準的說明、產品上市后驗收標準的差異性等[15-16]。

1.2 設計開發階段

設計開發與需求階段應針對以下內容進行考慮：① 質量保證方面。應規定AIMD訓練用和測試用數據集需要的檢查項目。例如，某些項目可能是獨立的測試用例，從而確保訓練數據的質量，其他項目可能是內置的測試項目，在某些質量檢查手段運行時發現質量問題；② 質量改進方面。為了在產品發布后更好地促進其安全有效，應該考慮添加有助于將來進行根本原因分析和功能改進的功能和需求。例如，為支持將來的根本原因分析，當在現場對AIMD系統進行更新時，應記錄數據、時間、數據源以及神經網絡加權因子等信息，該信息對可能快速跟蹤性能的重大變化非常有用。

1.3 上市后考慮因素

上市后活動應遵循上市后計劃進行考慮。AIMD的持續學習系統需要持續監控，以確保系統在預期性能范圍內運行。由于AIMD系統可以宣稱具有診斷功能，因此創建持續的受益-風險分析以針對AIMD性能和醫師診斷結果進行比較很有必要，因為兩者都會隨時間變化。同時，安裝階段應制定AIMD系統訓練數據的質量標準；應該驗證在安裝階段訪問的數據源是否符合這些標準（例如數據值、格式、類型等）。同時，版本控制對于AIMD系統而言特別重要，尤其是考慮到頻繁更新以及回滾到先前版本的可能性。

1.4 軟件維護與變更管理

在此產品生命周期階段，主要進行軟件更新（例如增加新功能）和變更維護（例如錯誤修復等）。對于AIMD系統，軟件更新可能是由于額外的訓練、持續更新，或者由制造商定義的定期更新。對于AIMD學習系統，變更速度可能比傳統的醫療器械軟件版本快得多。因此，在初始產品發布之前，應建立評估準則標準，以評估何時需要軟件更新。同時，在執行更新時應通知用戶，并清楚描述變更（例如導致變更的因素）。用戶應能夠拒絕算法更新或恢復到以前的算法版本。但是，這可能會導致在同一時間市場上存在多個有效算法版本，需要考慮如何跟蹤算法的投訴或其他問題。

2 AIMD質量管理規范框架討論

2.1 基于風險分類的AIMD監管思路

基于AIMD的軟件，在用于診斷、治療、緩解或預防疾病時，符合醫療器械的定義，屬于醫療器械的范疇。因此與其他軟件類醫療器械類似，AIMD的風險等級取決于預期用途在風險分類框架下對患者的影響。

根據國際醫療器械監管者論壇IMDRF的風險框架，可以確定以下兩個主要因素，用來說明AIMD的預期用途：① AIMD提供的信息對醫療決策的重要性（表1），該信息確定了AIMD提供信息的預期用途。例如用于治療或診斷、臨床決策、臨床通知等；② 醫療條件或環境的狀態，從而用于識別AIMD的預期使用者、疾病狀況以及人群。例如緊急、嚴重或非嚴重的醫療事件或狀況。

表1 IMDRF AIMD風險分類表決策重要性

需要注意的是，雖然AIMD取決于患者的風險分類，但由于人工智能算法的特殊性，因此風險也取決于從“鎖定”到“持續學習”的程度。“鎖定”算法是指每次提供相同輸入時都提供相同結果的算法。因此，“鎖定”算法將固定函數（例如靜態查找表、決策樹或復雜分類器）應用于給定的輸入集，這些算法可以使用手動過程進行更新和驗證。與“鎖定”算法相比，自適應算法（例如機器學習算法）使用定義的學習過程改變其行為。算法的自適應性使得對于給定的一組輸入，在實現改變之前和之后，輸出可能是不同的。這些算法變更通常是通過一個定義良好且可能完全自動化的過程來實現和驗證的，該過程旨在通過對新數據或附加數據的分析來提高算法性能。

適應過程可用于解決多種不同的臨床情況，例如在特定環境中優化性能（如基于當地患者群體）、基于設備的使用方式優化性能（如基于特定醫生的偏好）、通過收集更多臨床數據以提高性能、更改設備的預期用途等。適應過程包括兩個階段：學習和更新。算法“學習”如何改變自身的行為。例如，通過添加新的輸入類型或向已經存在的訓練數據庫中添加新的案例。當部署新版本的算法時，“更新”就會發生。因此，在時間A（更新前）和時間B（更新后）給定相同的輸入集，算法的輸出可能不同。

總體來說，將TPLC方法應用于軟件產品的監管對于基于AIMD來說尤其重要，因為它能夠在真實世界使用過程中進行適應和改變。在針對TPLC預認證方法中，通過評估相應公司的質量體系和組織架構，并對其軟件開發、測試和產品性能監控的質量進行合理評價，繼而保證產品在整個生命周期中都是有效的，從而對患者、護理人員、醫務人員和其他用戶提供產品安全有效的信心。因此，TPLC方法能夠對軟件產品從上市前的開發到上市后的性能進行評估和監控，并持續展示組織的優異性（圖1）。

圖1 基于全生命周期的AIMD要求框架

2.2 基于AIMD的修改和變更

AIMD可能有很多類型的修改，修改一般包括算法架構修改和使用新數據集重新訓練兩部分。修改類型通常分為三大類：① 性能更變，包括臨床和使用性能發生變化；② 輸入變更，算法使用的輸入及其與輸出的臨床關聯變化；③ 預期用途變更，AIMD的預期用途發生變化。

與性能相關的修改，不改變預期用途或增加新的輸入類型，這種類型的修改包括分析和臨床性能的改進。這些改進可以由許多更改引起，可能包括使用相同類型輸入信號的預期使用群體內的新數據集進行重新訓練、人工智能架構的改變或其他方式。對于這種類型的修改，制造商通常旨在更新用戶的性能，而不改變其產品的任何明確使用聲明。

與輸入相關的修改，不改變預期用途，這些類型的修改是改變人工智能算法使用輸入的修改。這些修改可能涉及對用于新類型輸入信號的算法的更改，但不會更改產品使用聲明。這些變化的例子有：擴展軟件與相同輸入數據類型的其他來源數據的兼容性（例如修改以支持與其他制造商的CT掃描儀兼容）；添加不同的輸入數據類型（例如將診斷心房顫動的輸入擴展到包括血氧飽和度數據）。

與預期用途相關的修改，這些類型的修改包括導致軟件提供的信息的重要性發生變化（例如從“輔助診斷”到“最終診斷”）。預期用途的修改也包括擴大預期患者群體（例如擴大至兒童群體）、預期疾病或條件（例如從一種癌癥到另一種癌癥的病變檢測）等。當然，所述的更改可能不是相互排斥的，一個軟件修改可能會導致輸入的變化和性能的變化；或者，性能更改可能會增加設備的臨床性能，進而影響預期用途等等。

3 討論

3.1 AIMD的可解釋性

基于AIMD系統關鍵的挑戰之一是對系統的可解釋性。在傳統的軟件開發項目中，促使人們對產品充滿信心的基本原因是可以理解的算法設計以及完善的、透明的驗證和確認工作。但是，對于AIMD系統，軟件工程師不會直接創建決策算法，并且在測試時可能將系統視為黑盒，所以這個部分并不容易實現。

目前，可解釋性在人工智能領域有新的含義和目的，通常指完全理解和記錄人工智能系統輸出、建議、預測或決策開發中所用邏輯、決策方法和數據源的必要性。對于某些不包括人工干預的高級人工智能系統，尤其是AIMD系統，這個概念成了問題。此外，隨著最近發布的歐盟GDPR法規，這種可解釋性的概念已具有新的形式化緊迫感。例如，根據這些法規，受影響的數據主體和用戶有權要求提供關于人工智能驅動輸出中涉及的邏輯等有意義的信息，以及在決策做出后提出質疑的能力。

3.2 基于AIMD的軟件的驗證和確認

AIMD系統的持續學習是關于學習、忘記和重新學習的過程。當系統完成持續學習時，就必然需要建立對系統操作和輸出的關系。驗證和確認為可信度和系統性能提供了證據。本文使用以下定義：驗證指“以正確的方式構建系統”，即證明系統正確實施且符合其質量標準（滿足技術要求）。確認指“構建正確的系統”，即證明系統執行任務的準確性的程度（滿足預期用途）。

針對AIMD的驗證，應定義與一致性、完整性、正確性和冗余概念相關的驗證方法，以實現異常檢測和/或錯誤消除，從而建立對系統的信心。開發者可以在知識庫中記錄他們擁有或獲得的專業知識，這將為AIMD系統算法的“可解釋性”奠定基礎。這是該過程的重要可交付成果，隨著算法的日趨成熟以及內容的性質，需要不斷修訂，預期它會成為具有非常復雜的科學和數學內容的高技術性文件，并且可能從數據科學家的角度編寫。

針對AIMD系統的確認。一般而言，確認是指通過檢查和提供客觀證據來證實設計的系統符合用戶需求和預期用途的過程。具體到AIMD，則是指通過使用獨立的參考標準來衡量系統性能的過程。參考標準可有多種來源，包括明確定義的基準事實（例如患者是否患有系統預測的疾病）、相關領域專家的共識（例如比較AIMD與病理學家對活檢標本的解讀）或臨床醫生做出的臨床決定。

3.3 AIMD應用場景示例

本節介紹了在醫療衛生系統中使用AIMD軟件的實際場景以及發生變更的實際情況。

3.3.1 肌電假體控制

肌電控制假肢是一種通過用戶自身肌肉產生的電信號實現控制的外部供電假肢。大多數假肢控制方法的局限性在于控制器無法隨時間推移適應患者及其意圖或使用模式的變化。因此，大多數假肢使用者無法在診所外獨立改善其肢體控制器。而AIMD配合機器學習，能夠了解并預測用戶意圖，并根據使用者反饋不斷改進控制。因此，需要針對每例患者對器械進行訓練，并使該器械在患者使用后仍可繼續學習。依據使用者培訓不同，每例患者的器械表現出來的性能可能有所不同，進而需要相應的魯棒性能評估方法。

3.3.2 基于AIMD分類的醫學影像篩查系統

AIMD系統已廣泛應用于醫學影像篩查。以胸部CT影像檢測肺癌為例，選擇了特定于深度學習架構進行初步訓練。該架構包括層數量、每一層卷積核大小、每一層卷積核的數量、每一層激活函數的類型、每一層應用梯度下降算法等。如果設計人員希望有更多數據可用時對AIMD架構進行再訓練，在訓練時，不僅神經網絡權值會發生變化，甚至整個架構都會發生變化。因此，權值/系數發生變化但其架構保持不變的AIMD和權值/系數和架構均發生變化的AIMD對持續學習的置信度和適應性均有顯著的差別。

4 總結

AIMD正處于蓬勃發展期，為臨床醫生提高醫療診斷效率和治療的可靠性提供了幫助，目前有許多AIMD正在臨床實踐中使用，因此，需要針對AIMD的需要建立動態穩健的質量管理模式，在縮短產品研發與驗證周期的同時，及時前瞻性地發現AIMD帶來的新的使用風險。本文討論了AIMD的質量管理體系框架，在此基礎上，討論了影響人工智能醫療器械質量的關鍵因素，設計變更和驗證確認環節的控制思路。并對人工智能醫療器械在質量評價過程中需重點關注的軟件可解釋性、評價方法和驗證和確認進行了討論。