為開發(fā)人員認(rèn)證醫(yī)療器件簡化iec 62304兼容步驟

1、為開發(fā)人員認(rèn)證醫(yī)療器件簡化為開發(fā)人員認(rèn)證醫(yī)療器件簡化IEC62304兼容步驟兼容步驟關(guān)鍵詞：為開發(fā)人員認(rèn)證醫(yī)療器件簡化IEC62304兼容步驟時間：2011110914:15:37來源：中電網(wǎng)■LDRA公司AnilKumar現(xiàn)在，利用高級醫(yī)療器械比以往任何時候都更有助于醫(yī)療從業(yè)人員輕松、準(zhǔn)確地做出診斷。然而，他們對器械的依賴程度也引發(fā)了確保器械安全性和質(zhì)量的擔(dān)憂。值得注意地是，醫(yī)療器械嚴(yán)重依賴第三方和早期軟件，亦即“未知系譜的軟件（SO

2、UP）”。該SOUP構(gòu)成了新發(fā)展的基礎(chǔ)，其現(xiàn)在可能符合新醫(yī)療器械要求或者政府推行的現(xiàn)代編碼標(biāo)準(zhǔn)、客戶需求或者僅僅是開發(fā)組織內(nèi)的持續(xù)改進(jìn)政策。在滿足新標(biāo)準(zhǔn)和進(jìn)一步開發(fā)新功能的同時，對利用SOUP價值的需要提出了它自己的獨特挑戰(zhàn)。FDA于1992至1998年間對3140次醫(yī)療器件召回事件進(jìn)行的分析顯示，其中有242次（占7.7%）可歸因于軟件故障。在所有軟件召回事件中，192次（占79%）是因軟件升級后引入的軟件缺陷而起。產(chǎn)品升級過程中引入

3、的高誤差率讓政府醫(yī)療器械機(jī)構(gòu)不僅要集中精力開發(fā)新產(chǎn)品，還要關(guān)注后期維護(hù)和軟件變更對現(xiàn)有系統(tǒng)的影響。因此，很多公司改變方法，改善軟件過程，采用歐盟和美國近期簽署的醫(yī)療產(chǎn)品設(shè)計標(biāo)準(zhǔn)IEC62304。IEC62304引進(jìn)了一種基于風(fēng)險的合規(guī)性結(jié)構(gòu)，可以確保醫(yī)學(xué)應(yīng)用符合其風(fēng)險評估適用標(biāo)準(zhǔn)的要求。該合規(guī)性結(jié)構(gòu)可以分成A~C類，其中C類軟件故障可能導(dǎo)致死亡或重傷。IEC62304軟件開發(fā)生命周期IEC62304著眼于軟件開發(fā)過程，定義了大部分軟件開

4、發(fā)與驗證活動。該過程包括軟件開發(fā)規(guī)劃、需求分析、架構(gòu)設(shè)計、軟件設(shè)計、單元實現(xiàn)與驗證、軟件集成與集成測試、系統(tǒng)測試和軟件發(fā)布之類的活動。該標(biāo)準(zhǔn)不僅概括了開發(fā)生命周期的各個階段的要求，還顧及了維護(hù)過程、軟件變更對現(xiàn)有系統(tǒng)的影響和實現(xiàn)軟件變更所涉及的風(fēng)險。IEC62304還直接從規(guī)劃、需求分析、架構(gòu)設(shè)計、維護(hù)和風(fēng)險管理階段開始詳細(xì)介紹了SOUP項目的作用。EIC62304和SOUP的數(shù)據(jù)組合也可能會使用先前未使用的代碼路徑，從而產(chǎn)生意料之外的

5、結(jié)果。圖1中的綠點曲線表示對SOUP代碼進(jìn)行增強(qiáng)時使用的代碼。為了克服這種潛在弱點，需要進(jìn)行詳細(xì)的結(jié)構(gòu)覆蓋率分析，以確保早期軟件內(nèi)不存在未使用的代碼。IEC62304要求測試早期軟件的功能覆蓋率和結(jié)構(gòu)覆蓋率，還要詳細(xì)分析增加這類軟件可能引入的風(fēng)險。功能覆蓋率確保軟件能夠按照系統(tǒng)設(shè)計要求運(yùn)行，而結(jié)構(gòu)覆蓋率則確保使用了所有代碼并且能夠正常運(yùn)行。IEC62304要求整合到醫(yī)療器械設(shè)計中的所有SOUP項目均符合功能和性能要求規(guī)范。醫(yī)療器械制造商

6、需要確保任意SOUP項目的正常運(yùn)行，還要保證它們符合功能和性能要求。IEC62304軟件開發(fā)過程始于軟件開發(fā)規(guī)劃，包括所用SOUP項目的詳細(xì)計劃。這些細(xì)節(jié)介紹了如何將SOUP項目整合到現(xiàn)有系統(tǒng)中、如何管理SOUP相關(guān)風(fēng)險和軟件配置、以及變更管理如何影響系統(tǒng)。緊接著是軟件需求管理、架構(gòu)設(shè)計、集成測試、系統(tǒng)測試、風(fēng)險管理、維護(hù)和變更管理階段。在軟件開發(fā)生命周期的各個階段，都需要保持所有階段之間的可追蹤性。傳統(tǒng)的軟件開發(fā)觀點表明了各個階段如何

7、進(jìn)入下一個階段，可能還帶有前幾個階段的反饋信息，以及配置管理與過程的周邊架構(gòu)?？勺粉櫺员灰暈楦鱾€階段間關(guān)系的一部分。然而，很少規(guī)定記錄跟蹤鏈路的機(jī)制。實際上，雖然由于先進(jìn)工具技術(shù)投資，各個階段都能夠有效實施，但是這些工具很少能夠自動提高階段間可追蹤性。因此，在整個項目進(jìn)行的過程中，其間鏈路的維護(hù)就變得越來越差。最終的結(jié)果就是需求與設(shè)計之間的交叉檢驗缺失或者流于表面，以及最終系統(tǒng)的機(jī)能不全。為了獲得真正的自動可追蹤性，則需要需求跟蹤矩陣（