隨著最近幾年很多傳統(tǒng)互聯(lián)網(wǎng)企業(yè)開始積極布局醫(yī)療市場，國內(nèi)涌現(xiàn)不少AI+醫(yī)療公司，也積極參與到醫(yī)療器械這個朝陽產(chǎn)業(yè)中。

但現(xiàn)實總是機遇和挑戰(zhàn)并存，從傳統(tǒng)企業(yè)直接跨入醫(yī)療器械行業(yè)，總會帶來水土不服的地方。筆者大體總結(jié)原因如下：

1.傳統(tǒng)行業(yè)由于沒有醫(yī)療器械行業(yè)背景，對醫(yī)療器械行業(yè)標(biāo)準(zhǔn)和法規(guī)理解不深刻，運用過去對傳統(tǒng)軟件開發(fā)的經(jīng)驗，來照搬做醫(yī)療器械軟件開發(fā)，可能會在法規(guī)和標(biāo)準(zhǔn)的符合性方面存在一些問題；

2.AI是最近幾年才開始應(yīng)用于醫(yī)療器械軟件，當(dāng)前業(yè)界關(guān)于軟件開發(fā)的指導(dǎo)標(biāo)準(zhǔn)和法規(guī)，在面臨AI這個新事物時，面臨不適用或部分不適用的風(fēng)險。

簡言之，當(dāng)前沒有金標(biāo)準(zhǔn)或成熟標(biāo)準(zhǔn)供大家參照學(xué)習(xí)。如何在應(yīng)用AI技術(shù)的同時，能確保器械的安全和有效，是整個行業(yè)甚至包括監(jiān)管機構(gòu)的待解難題。困難再多，企業(yè)也要弄潮而上。如何用傳統(tǒng)的開發(fā)模式來適應(yīng)醫(yī)療行業(yè)的新要求，是很多企業(yè)的困惑。筆者在閱讀動脈網(wǎng)前期的一篇文章《人工智能醫(yī)療器械創(chuàng)新合作平臺會議在博鰲召開，一文讀懂人工智能醫(yī)療器械審評審批常見問題》之后，也想以傳統(tǒng)敏捷軟件開發(fā)模式來適應(yīng)醫(yī)療器械獨立軟件的開發(fā)為例，分享些實戰(zhàn)經(jīng)驗。

一、AI醫(yī)療行業(yè)GMP現(xiàn)狀

當(dāng)前國內(nèi)醫(yī)療器械軟件開發(fā)可以參照的標(biāo)準(zhǔn)和法規(guī)有7月12日國家藥品監(jiān)督管理總局發(fā)布《醫(yī)療器械生產(chǎn)質(zhì)量管理規(guī)范附錄獨立軟件》(下文統(tǒng)一簡稱為：軟件GMP)和IEC62034-2015《醫(yī)療器械軟件 軟件生存周期過程》標(biāo)準(zhǔn)。由于AI醫(yī)用獨立軟件管理類別屬于Ⅲ類醫(yī)療器械，其軟件安全等級為Class C，GMP對其產(chǎn)品追溯性和變更控制的要求較高。

產(chǎn)品在立項時就需要定義清楚產(chǎn)品需求，可預(yù)見的是需求不能輕易變更，另外對需求的實現(xiàn)及驗證要遵循嚴(yán)格的流程要求。但是，這恰恰和軟件的迭代和敏捷開發(fā)方式有相悖的地方。當(dāng)然，敏捷開發(fā)模型是一種成熟的模型，有其優(yōu)點：

（1）團隊在使用敏捷開發(fā)模式的情況下，迭代周期和大家的目標(biāo)比較統(tǒng)一，敏捷開發(fā)模型可以提升團隊自主管理能力，信息傳遞比較及時，每天都會同步信息。

（2）敏捷開發(fā)模型里面，產(chǎn)品按照每個迭代去驗收，每個迭代工作成果都需要經(jīng)過演示，如果在演示中意見不同，可以及時暴露并修正，提測頻率較高，減少開發(fā)和測試的等待時間。敏捷開發(fā)模型對項目進度只有零或一百分，著重團隊承諾，不強調(diào)個人能力，更關(guān)注整個團隊的績效，重視對外部承諾和內(nèi)部承諾等等。

（3）敏捷中的風(fēng)險管理關(guān)注于項目風(fēng)險如進度、版本質(zhì)量、人員風(fēng)險等等。

（4）敏捷中關(guān)注迭代過程的持續(xù)改進，例如需求評審不充分，溝通信息不同步。

簡言之, 敏捷更關(guān)注項目的生命周期。而軟件GMP的要求更關(guān)注于產(chǎn)品生命周期，從產(chǎn)品立項到產(chǎn)品退市，著力于整個產(chǎn)品生命周期的管控。

其次,敏捷模型更適用于軟件類產(chǎn)品的開發(fā)控制，不太適用于硬件的開發(fā)。原因是軟件可以快速交付可用的功能，但是硬件的特性決定了功能的實現(xiàn)具有集成性。只是造出一個其中部件，實現(xiàn)不了具體的功能，不能滿足定義的功能需求。并且敏捷的需求是漸進明細，不是一開始就能明確下來，有一個迭代完善的過程（見章節(jié)3論述）。在人員這一塊，敏捷不支持人員兼職或項目并行，必須是串行。

總之，按照GMP的要求，制造商需關(guān)注產(chǎn)品的全生命周期，關(guān)注于研發(fā)過程質(zhì)量保證，采購質(zhì)量管理，生產(chǎn)質(zhì)量控制，銷售和售后及上市后的質(zhì)量跟蹤保證等活動。

我們也可以從風(fēng)險控制角度來看傳統(tǒng)敏捷軟件開發(fā)模式和GMP要求的差異：在敏捷中的風(fēng)險管理則關(guān)注于項目風(fēng)險如進度，版本質(zhì)量，人員風(fēng)險等等，而在GMP中風(fēng)險管理更多關(guān)注產(chǎn)品本身的風(fēng)險，其風(fēng)險管理貫穿于軟件的整個生命周期。

二、AI醫(yī)療行業(yè)GMP實踐策略

鑒于大多數(shù)軟件研發(fā)項目采用敏捷開發(fā)模型，如何讓軟件敏捷開發(fā)模式能滿足軟件GMP的要求？筆者認為，可以從YY/T 0664《醫(yī)療器械軟件 軟件生存周期過程》標(biāo)準(zhǔn)中尋求解決之道。那就是深刻理解V模型的項目管理理念，把每個V模型的階段靈活植入迭代開發(fā)的過程，對每個階段的交付物（各企業(yè)可結(jié)合自身項目開發(fā)流程階段）進行嚴(yán)格控制，以符合軟件GMP的要求。為了便于讓多數(shù)的讀者理解，先簡單介紹下V模型。

（1）V模型縮略語及模型：

A.需求的垂直分解；

B.需求的水平驗證與確認；

C.與風(fēng)險相關(guān)的需求需追溯到源代碼；

（2）開發(fā)過程中融合規(guī)則：

A.產(chǎn)品架構(gòu)分為三層：系統(tǒng)，子系統(tǒng)，單元模塊。

B.設(shè)計規(guī)范及單元測試：對于各個單元模塊可以采用敏捷開發(fā)，快速的迭代sprint，對于單元模塊對應(yīng)的單元測試規(guī)范及單元測試報告（自測）在軟件開發(fā)程序變動更新1/3以上或者自我定義，就要啟動單元模塊對應(yīng)的設(shè)計規(guī)范，單元測試規(guī)范及單元測試報告等DHF文件的升版和發(fā)布。

C.集成測試：對于各個單元模塊集成的測試，偏重在功能層面的測試；對于集成測試類型分為三種情況：全部測試、部分測試、缺陷測試；對于每次迭代的測試，測試組負責(zé)更新并發(fā)布測試規(guī)范及測試報告。

D.系統(tǒng)測試：對于系統(tǒng)測試主要集中在產(chǎn)品功能、性能、安全等全面的測試；對于每次迭代的測試，測試組負責(zé)更新升版發(fā)布測試規(guī)范及測試報告。

（3）測試過程中融合規(guī)則，示例如下：

三、AI醫(yī)療行業(yè)GMP實踐解惑

介紹了V模型，讀者會問，這和敏捷開發(fā)有什么聯(lián)系？以需求的迭代和詳細設(shè)計迭代為例說明：

（1）需求的定義，我們當(dāng)然可以應(yīng)用敏捷開發(fā)（迭代）的思想。

項目開發(fā)前期，一般產(chǎn)品經(jīng)理可以根據(jù)客戶需求，形成產(chǎn)品的基本需求，我們可以初步稱之為市場需求。然后基于此，需求RS向下分解（RS→FS），形成了最初的需求基線(直觀為DHF需求文檔，最初版本)。在后續(xù)項目推進過程中，項目組成員可以參與進來豐富需求。比如，RA（regulatory affair）補充法規(guī)和標(biāo)準(zhǔn)的需求，臨床專家/醫(yī)生補充臨床需求，服務(wù)工程師補充服務(wù)需求，研發(fā)工程師補充開發(fā)需求等等，均可以逐步迭代進來，不斷壯大RS需求和FS需求。直至RS→FS完全定義清楚并形成最終的需求基線和最終的版本。

有的企業(yè)，在詳細設(shè)計階段仍然在進行需求的迭代，筆者認為只要做好相應(yīng)的變更控制和軟件的配置管理（比如：需求基線和軟件版本基線控制），也是符合軟件GMP和IEC62304要求的。因篇幅所限，筆者不再贅述。

現(xiàn)向大家介紹一種需求的迭代管理模式：

需求的迭代變更管理流程圖

職責(zé)定義：

需求管理團隊至少包括以下職能代表：

系統(tǒng)工程師

項目經(jīng)理

臨床專家/醫(yī)生

設(shè)計質(zhì)量保證（QA）

研發(fā)工程師

法規(guī)注冊工程師（RA）

A.從上圖可以看出，需求的迭代變更是變更控制的一種，迭代的過程包括定義需求（制定計劃）→利益相關(guān)者輸入需求→需求追溯關(guān)系矩陣建立→需求基線形成→變更（迭代）→需求（制定計劃）→…… 循環(huán)迭代的過程。

B.在需求迭代過程中，需求管理團隊成員需要做好需求的評審，確保正確的需求被吸納，不明確的需求被適時糾正。

（2）詳細設(shè)計的迭代控制

當(dāng)需求定義清楚，項目可以推進入下一階段，詳細設(shè)計階段。筆者簡單簡紹兩種迭代過程：

A.軟件功能的迭代

軟件工程師可以采用敏捷的開發(fā)模式，先實現(xiàn)核心模塊的功能，然后逐步的擴展功能，直至把DS中所有的要求實現(xiàn)。工程師可把敏捷的方式運用到極致，只要能做好軟件版本的迭代和基線控制（可參考IEC62304-章節(jié)8軟件的配置管理過程），以滿足V模型和軟件GMP的要求。比如，F(xiàn)S的需求能完全轉(zhuǎn)化為DS（設(shè)計規(guī)范）并被追溯，DS能追溯到源代碼，反之亦然。

B.修復(fù)bug，發(fā)布補丁的迭代過程

解決的過程可以參照如下的流程，如下圖：

（3）軟件測試的迭代：

IEC62304中能直接體現(xiàn)迭代的思想的實例就是回歸測試（IEC62304 –章節(jié)5.6），如果軟件代碼進行了重新編譯、軟件版本的升級，為了證明原功能仍然正�；蛭匆�入新的缺陷，此時進行部分回歸或全回歸測試就顯得非常必要。

綜述，只要能真正理解對醫(yī)療器械的監(jiān)管要求——制造商必須確保器械的安全和有效性。在實際開發(fā)中，靈活把敏捷開發(fā)模式融入V模型中，敏捷模型也能在醫(yī)療器械軟件開發(fā)中煥發(fā)生命力，游刃有余。可以這樣講，法規(guī)和標(biāo)準(zhǔn)并不反對企業(yè)使用敏捷迭代或某一固定開發(fā)模型，只要制造商能對其進行合理的控制以滿足相應(yīng)標(biāo)準(zhǔn)和法規(guī)的要求，就是適用的方法。