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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）V模型縮略語(yǔ)及模型：

A.需求的垂直分解；

B.需求的水平驗(yàn)證與確認(rèn)；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

職責(zé)定義：

需求管理團(tuán)隊(duì)至少包括以下職能代表：

系統(tǒng)工程師

項(xiàng)目經(jīng)理

臨床專家/醫(yī)生

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

研發(fā)工程師

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

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

B.在需求迭代過程中，需求管理團(tuán)隊(duì)成員需要做好需求的評(píng)審，確保正確的需求被吸納，不明確的需求被適時(shí)糾正。

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

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

A.軟件功能的迭代

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

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

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

（3）軟件測(cè)試的迭代：

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

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