為開(kāi)發(fā)人員認證醫療器件簡(jiǎn)化IEC 62304兼容步驟

現在，利用高級醫療器械比以往任何時(shí)候都更有助于醫療從業(yè)人員輕松、準確地做出診斷。然而，他們對器械的依賴(lài)程度也引發(fā)了確保器械安全性和質(zhì)量的擔憂(yōu)。

值得注意地是，醫療器械嚴重依賴(lài)第三方和早期軟件，亦即“未知系譜的軟件（SOUP）”。該SOUP構成了新發(fā)展的基礎，其現在可能符合新醫療器械要求或者政府推行的現代編碼標準、客戶(hù)需求或者僅僅是開(kāi)發(fā)組織內的持續改進(jìn)政策。在滿(mǎn)足新標準和進(jìn)一步開(kāi)發(fā)新功能的同時(shí)，對利用SOUP價(jià)值的需要提出了它自己的獨特挑戰。

FDA于1992至1998年間對3140次醫療器件召回事件進(jìn)行的分析顯示，其中有242次（占7.7%）可歸因于軟件故障。在所有軟件召回事件中，192次（占79%）是因軟件升級后引入的軟件缺陷而起。產(chǎn)品升級過(guò)程中引入的高誤差率讓政府醫療器械機構不僅要集中精力開(kāi)發(fā)新產(chǎn)品，還要關(guān)注后期維護和軟件變更對現有系統的影響。

因此，很多公司改變方法，改善軟件過(guò)程，采用歐盟和美國近期簽署的醫療產(chǎn)品設計標準IEC 62304。IEC 62304引進(jìn)了一種基于風(fēng)險的合規性結構，可以確保醫學(xué)應用符合其風(fēng)險評估適用標準的要求。該合規性結構可以分成A~C類(lèi)，其中C類(lèi)軟件故障可能導致死亡或重傷。

IEC 62304軟件開(kāi)發(fā)生命周期

IEC 62304著(zhù)眼于軟件開(kāi)發(fā)過(guò)程，定義了大部分軟件開(kāi)發(fā)與驗證活動(dòng)。該過(guò)程包括軟件開(kāi)發(fā)規劃、需求分析、架構設計、軟件設計、單元實(shí)現與驗證、軟件集成與集成測試、系統測試和軟件發(fā)布之類(lèi)的活動(dòng)。

該標準不僅概括了開(kāi)發(fā)生命周期的各個(gè)階段的要求，還顧及了維護過(guò)程、軟件變更對現有系統的影響和實(shí)現軟件變更所涉及的風(fēng)險。IEC 62304還直接從規劃、需求分析、架構設計、維護和風(fēng)險管理階段開(kāi)始詳細介紹了SOUP項目的作用。

EIC 62304和SOUP

可重新用于新器件開(kāi)發(fā)的SOUP軟件已流行起來(lái)，因為醫療器械現在傾向于采用通用嵌入式硬件，以及操作系統，面向USB、以太網(wǎng)或制圖的器件驅動(dòng)器、文件系統、網(wǎng)絡(luò )堆棧等。在醫療器械中使用SOUP有其優(yōu)勢，因為制造商可以將精力集中在應用軟件上。

然而，由于應用需要運行專(zhuān)用功能，所以醫療器械內的SOUP增加了挑戰難度。大多數SOUP模塊都由第三方供應商提供，而他們不遵守任何軟件過(guò)程和軟件標準，甚至不記錄代碼。雖然它解決了平臺挑戰，但SOUP是在緊迫的時(shí)間表內開(kāi)發(fā)而來(lái)，并且強調的是生產(chǎn)率，而不是標準兼容性。在進(jìn)行系統測試以便檢驗功能性時(shí)，SOUP項目通常表現出代碼覆蓋率極差的特點(diǎn)，并且留下了很多未使用的代碼路徑。圖1中的藍色曲線(xiàn)代表進(jìn)行了功能測試的代碼。采用該代碼時(shí)，不同的數據和情形有可能第一次使用很多未經(jīng)測試的路徑，從而產(chǎn)生意料之外的結果。圖1中的紅點(diǎn)曲線(xiàn)表示現場(chǎng)運行應用時(shí)使用的代碼。

圖1 傳統功能測試可能無(wú)法檢驗代碼的很多部分。藍色曲線(xiàn)表示傳統功能測試使用的代碼；紅點(diǎn)曲線(xiàn)表示應用現場(chǎng)運行時(shí)使用的代碼；綠點(diǎn)曲線(xiàn)表示代碼增強，其傾向于使用先前未遇到的數據組合，從而出現進(jìn)入先前未使用路徑的可能性。

歐洲軟件和系統提案之“利用經(jīng)驗驅動(dòng)測試（PET）檢驗誤碼性能”計劃調查了這種現象，并且同意采用的代碼通常帶有很多誤碼的觀(guān)點(diǎn)。PET旨在將發(fā)布后報告的漏洞數量減少50%和將每找出一個(gè)漏洞所耗費的測試工作時(shí)間縮短40%。有意思的是，PET超過(guò)了該標準，將報告的漏洞數減少了75%，將測試效率提高了46%。PET的發(fā)現表明可以利用較新的測試方法（如靜態(tài)和動(dòng)態(tài)分析）找出大量漏洞，即使代碼已經(jīng)通過(guò)了功能系統測試并于隨后發(fā)布。

那么，可以采用先前通過(guò)功能測試的SOUP做進(jìn)一步測試。即使它運行良好，代碼的某些部分也可能未曾使用過(guò)，即使是產(chǎn)品正在現場(chǎng)使用的時(shí)候。如果SOUP代碼需要作進(jìn)一步開(kāi)發(fā)以便于后來(lái)的修訂或新應用，那么先前從未碰到的數據組合也可能會(huì )使用先前未使用的代碼路徑，從而產(chǎn)生意料之外的結果。圖1中的綠點(diǎn)曲線(xiàn)表示對SOUP代碼進(jìn)行增強時(shí)使用的代碼。

為了克服這種潛在弱點(diǎn)，需要進(jìn)行詳細的結構覆蓋率分析，以確保早期軟件內不存在未使用的代碼。IEC 62304要求測試早期軟件的功能覆蓋率和結構覆蓋率，還要詳細分析增加這類(lèi)軟件可能引入的風(fēng)險。功能覆蓋率確保軟件能夠按照系統設計要求運行，而結構覆蓋率則確保使用了所有代碼并且能夠正常運行。

IEC 62304要求整合到醫療器械設計中的所有SOUP項目均符合功能和性能要求規范。醫療器械制造商需要確保任意SOUP項目的正常運行，還要保證它們符合功能和性能要求。

IEC 62304軟件開(kāi)發(fā)過(guò)程始于軟件開(kāi)發(fā)規劃，包括所用SOUP項目的詳細計劃。這些細節介紹了如何將SOUP項目整合到現有系統中、如何管理SOUP相關(guān)風(fēng)險和軟件配置、以及變更管理如何影響系統。

緊接著(zhù)是軟件需求管理、架構設計、集成測試、系統測試、風(fēng)險管理、維護和變更管理階段。在軟件開(kāi)發(fā)生命周期的各個(gè)階段，都需要保持所有階段之間的可追蹤性。

傳統的軟件開(kāi)發(fā)觀(guān)點(diǎn)表明了各個(gè)階段如何進(jìn)入下一個(gè)階段，可能還帶有前幾個(gè)階段的反饋信息，以及配置管理與過(guò)程的周邊架構?？勺粉櫺员灰暈楦鱾€(gè)階段間關(guān)系的一部分。然而，很少規定記錄跟蹤鏈路的機制。

實(shí)際上，雖然由于先進(jìn)工具技術(shù)投資，各個(gè)階段都能夠有效實(shí)施，但是這些工具很少能夠自動(dòng)提高階段間可追蹤性。因此，在整個(gè)項目進(jìn)行的過(guò)程中，其間鏈路的維護就變得越來(lái)越差。最終的結果就是需求與設計之間的交叉檢驗缺失或者流于表面，以及最終系統的機能不全。為了獲得真正的自動(dòng)可追蹤性，則需要需求跟蹤矩陣（RTM）。RTM是各個(gè)項目的核心，是很多開(kāi)發(fā)標準（包括IEC 62304）的關(guān)鍵所在。