醫療器械獨立軟件研發體系與敏捷項目開發模式的融合實踐
隨著最近幾年很多傳統互聯網企業開始積極布局醫療市場，國內涌現不少AI+醫療公司，也積極參與到醫療器械這個朝陽產業中。
但現實總是機遇和挑戰并存，從傳統企業直接跨入醫療器械行業，總會帶來水土不服的地方。筆者大體總結原因如下：
1.傳統行業由于沒有醫療器械行業背景，對醫療器械行業標準和法規理解不深刻，運用過去對傳統軟件開發的經驗，來照搬做醫療器械軟件開發，可能會在法規和標準的符合性方面存在一些問題；
2.AI是最近幾年才開始應用于醫療器械軟件，當前業界關于軟件開發的指導標準和法規，在面臨AI這個新事物時，面臨不適用或部分不適用的風險。
簡言之，當前沒有金標準或成熟標準供大家參照學習。如何在應用AI技術的同時，能確保器械的安全和有效，是整個行業甚至包括監管機構的待解難題。困難再多，企業也要弄潮而上。如何用傳統的開發模式來適應醫療行業的新要求，是很多企業的困惑。筆者在閱讀動脈網前期的一篇文章《人工智能醫療器械創新合作平臺會議在博鰲召開，一文讀懂人工智能醫療器械審評審批常見問題》之后，也想以傳統敏捷軟件開發模式來適應醫療器械獨立軟件的開發為例，分享些實戰經驗。
一、AI醫療行業GMP現狀
當前國內醫療器械軟件開發可以參照的標準和法規有7月12日國家藥品監督管理總局發布《醫療器械生產質量管理規范附錄獨立軟件》(下文統一簡稱為：軟件GMP)和IEC62034-2015《醫療器械軟件 軟件生存周期過程》標準。由于AI醫用獨立軟件管理類別屬于Ⅲ類醫療器械，其軟件安全等級為Class C，GMP對其產品追溯性和變更控制的要求較高。
產品在立項時就需要定義清楚產品需求，可預見的是需求不能輕易變更，另外對需求的實現及驗證要遵循嚴格的流程要求。但是，這恰恰和軟件的迭代和敏捷開發方式有相悖的地方。當然，敏捷開發模型是一種成熟的模型，有其優點：
（1）團隊在使用敏捷開發模式的情況下，迭代周期和大家的目標比較統一，敏捷開發模型可以提升團隊自主管理能力，信息傳遞比較及時，每天都會同步信息。
（2）敏捷開發模型里面，產品按照每個迭代去驗收，每個迭代工作成果都需要經過演示，如果在演示中意見不同，可以及時暴露并修正，提測頻率較高，減少開發和測試的等待時間。敏捷開發模型對項目進度只有零或一百分，著重團隊承諾，不強調個人能力，更關注整個團隊的績效，重視對外部承諾和內部承諾等等。
（3）敏捷中的風險管理關注于項目風險如進度、版本質量、人員風險等等。
（4）敏捷中關注迭代過程的持續改進，例如需求評審不充分，溝通信息不同步。
簡言之, 敏捷更關注項目的生命周期。而軟件GMP的要求更關注于產品生命周期，從產品立項到產品退市，著力于整個產品生命周期的管控。
其次,敏捷模型更適用于軟件類產品的開發控制，不太適用于硬件的開發。原因是軟件可以快速交付可用的功能，但是硬件的特性決定了功能的實現具有集成性。只是造出一個其中部件，實現不了具體的功能，不能滿足定義的功能需求。并且敏捷的需求是漸進明細，不是一開始就能明確下來，有一個迭代完善的過程（見章節3論述）。在人員這一塊，敏捷不支持人員兼職或項目并行，必須是串行。
總之，按照GMP的要求，制造商需關注產品的全生命周期，關注于研發過程質量保證，采購質量管理，生產質量控制，銷售和售后及上市后的質量跟蹤保證等活動。
我們也可以從風險控制角度來看傳統敏捷軟件開發模式和GMP要求的差異：在敏捷中的風險管理則關注于項目風險如進度，版本質量，人員風險等等，而在GMP中風險管理更多關注產品本身的風險，其風險管理貫穿于軟件的整個生命周期。
二、AI醫療行業GMP實踐策略
鑒于大多數軟件研發項目采用敏捷開發模型，如何讓軟件敏捷開發模式能滿足軟件GMP的要求？筆者認為，可以從YY/T 0664《醫療器械軟件 軟件生存周期過程》標準中尋求解決之道。那就是深刻理解V模型的項目管理理念，把每個V模型的階段靈活植入迭代開發的過程，對每個階段的交付物（各企業可結合自身項目開發流程階段）進行嚴格控制，以符合軟件GMP的要求。為了便于讓多數的讀者理解，先簡單介紹下V模型。
（1）V模型縮略語及模型：
A.需求的垂直分解；
B.需求的水平驗證與確認；
C.與風險相關的需求需追溯到源代碼；
（2）開發過程中融合規則：
A.產品架構分為三層：系統，子系統，單元模塊。
B.設計規范及單元測試：對于各個單元模塊可以采用敏捷開發，快速的迭代sprint，對于單元模塊對應的單元測試規范及單元測試報告（自測）在軟件開發程序變動更新1/3以上或者自我定義，就要啟動單元模塊對應的設計規范，單元測試規范及單元測試報告等DHF文件的升版和發布。
C.集成測試：對于各個單元模塊集成的測試，偏重在功能層面的測試；對于集成測試類型分為三種情況：全部測試、部分測試、缺陷測試；對于每次迭代的測試，測試組負責更新并發布測試規范及測試報告。
D.系統測試：對于系統測試主要集中在產品功能、性能、安全等全面的測試；對于每次迭代的測試，測試組負責更新升版發布測試規范及測試報告。
（3）測試過程中融合規則，示例如下：
三、AI醫療行業GMP實踐解惑
介紹了V模型，讀者會問，這和敏捷開發有什么聯系？以需求的迭代和詳細設計迭代為例說明：
（1）需求的定義，我們當然可以應用敏捷開發（迭代）的思想。
項目開發前期，一般產品經理可以根據客戶需求，形成產品的基本需求，我們可以初步稱之為市場需求。然后基于此，需求RS向下分解（RS→FS），形成了最初的需求基線(直觀為DHF需求文檔，最初版本)。在后續項目推進過程中，項目組成員可以參與進來豐富需求。比如，RA（regulatory affair）補充法規和標準的需求，臨床專家/醫生補充臨床需求，服務工程師補充服務需求，研發工程師補充開發需求等等，均可以逐步迭代進來，不斷壯大RS需求和FS需求。直至RS→FS完全定義清楚并形成最終的需求基線和最終的版本。
有的企業，在詳細設計階段仍然在進行需求的迭代，筆者認為只要做好相應的變更控制和軟件的配置管理（比如：需求基線和軟件版本基線控制），也是符合軟件GMP和IEC62304要求的。因篇幅所限，筆者不再贅述。
現向大家介紹一種需求的迭代管理模式：
需求的迭代變更管理流程圖
職責定義：
需求管理團隊至少包括以下職能代表：
系統工程師
項目經理
臨床專家/醫生
設計質量保證（QA）
研發工程師
法規注冊工程師（RA）
A.從上圖可以看出，需求的迭代變更是變更控制的一種，迭代的過程包括定義需求（制定計劃）→利益相關者輸入需求→需求追溯關系矩陣建立→需求基線形成→變更（迭代）→需求（制定計劃）→…… 循環迭代的過程。
B.在需求迭代過程中，需求管理團隊成員需要做好需求的評審，確保正確的需求被吸納，不明確的需求被適時糾正。
（2）詳細設計的迭代控制
當需求定義清楚，項目可以推進入下一階段，詳細設計階段。筆者簡單簡紹兩種迭代過程：
A.軟件功能的迭代
軟件工程師可以采用敏捷的開發模式，先實現核心模塊的功能，然后逐步的擴展功能，直至把DS中所有的要求實現。工程師可把敏捷的方式運用到極致，只要能做好軟件版本的迭代和基線控制（可參考IEC62304-章節8軟件的配置管理過程），以滿足V模型和軟件GMP的要求。比如，FS的需求能完全轉化為DS（設計規范）并被追溯，DS能追溯到源代碼，反之亦然。
B.修復bug，發布補丁的迭代過程
解決的過程可以參照如下的流程，如下圖：
（3）軟件測試的迭代：
IEC62304中能直接體現迭代的思想的實例就是回歸測試（IEC62304 –章節5.6），如果軟件代碼進行了重新編譯、軟件版本的升級，為了證明原功能仍然正常或未引入新的缺陷，此時進行部分回歸或全回歸測試就顯得非常必要。
綜述，只要能真正理解對醫療器械的監管要求——制造商必須確保器械的安全和有效性。在實際開發中，靈活把敏捷開發模式融入V模型中，敏捷模型也能在醫療器械軟件開發中煥發生命力，游刃有余。可以這樣講，法規和標準并不反對企業使用敏捷迭代或某一固定開發模型，只要制造商能對其進行合理的控制以滿足相應標準和法規的要求，就是適用的方法。
分享
請輸入評論內容...
請輸入評論/評論長度6~500個字
圖片新聞
