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

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

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

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

　　IEC 62304軟件開發生命周期

　　IEC 62304著眼于軟件開發過程，定義了大部分軟件開發與驗證活動。該過程包括軟件開發規劃、需求分析、架構設計、軟件設計、單元實現與驗證、軟件集成與集成測試、系統測試和軟件發布之類的活動。

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

　　EIC 62304和SOUP

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

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

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

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

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

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

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

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

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

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

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

　　需求跟蹤與SOUP

　　需求跟蹤矩陣是一種用于管理和跟蹤需求的習慣做法，在管理軟件需求和系統所用SOUP項目方面起著重要作用。RTM能夠通過醫療器械應用的架構設計在與SOUP有關的高級需求之間實現可追蹤性（圖2）。

　　圖2 需求跟蹤矩陣（RTM）在開發生命周期模型中起著重要作用，即使是在SOUP項目是系統的一部分的時候。各個階段的典型產物都直接與需求矩陣相連，各個階段的變更都會自動更新RTM。

　　為了確保SOUP能夠滿足IEC 62304規定的系統級要求，醫療器械制造商需要規定：

　　? 預期用途所需的SOUP項目的功能和性能要求

　　? 讓SOUP項目正常運行所需的系統硬件和軟件的生產規范

　　? 證明醫療器械架構能夠讓任意SOUP項目正常運行所需的詳情

　　大多數情況下，SOUP項目是作為源代碼提供的，但是不帶設計文件，這樣就很難分析它們。使用現代測試工具有助于實現早期代碼設計可視化。

　　不論它是否應用于語句模塊、進程（或類）、應用和/或系統，現代測試工具提供的系統可視化設施功能都非常強大。應用和系統實體的分層示意圖如圖3a內的靜態調用圖所示；圖3b內的靜態流程圖展示了整個程序模塊的控制流程。利用彩色編碼圖對于了解SOUP極有好處。這類調用圖和流程圖只是綜合分析代碼內使用的所有參數和數據對象的一部分優勢。

　　圖3 靜態調用圖（a）和流程圖（b）以圖形的形式分別說明了代碼的結構和邏輯。

　　需求管理和跟蹤已經證明了它們在軟件開發生命周期內的優勢，能夠確保實現所有需求和所有開發成果都可以追溯到一個或多個需求。同樣的，需求管理與跟蹤可以保證根據系統要求添加和驗證SOUP項目。

　　RTM在架構設計和SOUP項目之間實現了可追蹤性。由于這些項目都包含在源代碼內并且現在需要按照IEC 62304的要求進行系統級合規性測試，所以代碼驗證就成了制造商的責任。

　　大多數SOUP項目都不嚴謹，從而為系統集成商提高了嚴格驗證與風險分析要求。由于SOUP驗證非常耗時，所以開發人員一開始通常需要滿足一系列編碼標準，再逐漸采用其他規則。雖然測試工具只辨別而不糾正代碼內存在的違規之處和本征誤差，但是它們確實通過指出問題所在而加快了代碼糾正速度。

　　IEC 62304希望醫療器械制造商評估SOUP項目供應商提供的軟件異常列表，以便確定已知異常是否會引發事件，進而導致出現危險情形。

　　測試工具的靜態分析能力能夠確定異常及其對軟件系統的影響。如果確定了SOUP供應商提供的列表以外的任何其他異常，則應告知相應供應商以解決問題。

　　靜態分析和異常糾正完成后，進行動態分析（包括系統、集成度和單元測試）以便驗證SOUP項目的功能和結構覆蓋率。雖然全系統功能測試提供了SOUP項目的功能簡介，但是它不測試所有代碼路徑。測試工具確定使用過的軟件部分，并且重點突出需要注意的區域，要對這些區域進行單元測試以便保證各個單元都能夠獨立運行。

　　進行功能測試與結構覆蓋率分析能夠確保使用了所有代碼路徑和驗證了多個單元之間的接口。它還有助于確保系統能夠按照設計要求運行，即使集成了SOUP項目。值得注意的是，IEC 62304要求SOUP項目驗證遵循軟件規劃期間制定的集成計劃，再一次表明IEC 62304強調的重點在于確保醫療軟件升級不會引入誤碼。

　　根據先前制定的測試計劃，RTM在對SOUP項目進行的各種分析之間實現了可追蹤性。該測試計劃包括有待執行的測試用例以及基于系統要求的預期結果。利用RTM，項目經理可以評估整合的SOUP項目的影響以及它們如何影響系統安全。

　　SOUP項目維護

　　醫療器械行業的很多意外都與醫療器械系統的服務或維護有關，包括軟件更新和升級不當。在這里，SOUP項目還起著重要作用，因為這些項目由不同的供應商提供并且需要驗證。

　　在IEC 62304中，軟件維護過程和軟件開發過程一樣重要。強調維護旨在抑制產品發布以后（如軟件維護期間）引入的高醫療器械軟件缺陷率。

　　維護過程要求，制造商監控組織內部和用戶提供的已發布產品相關的反饋信息。必須記錄和分析該反饋信息，以便確定是否存在問題。發現問題時，應編寫和分析問題報告，以便確定SOUP項目是否增加了問題的嚴重性。如果SOUP就是問題所在，則必須將該問題傳達給相應的供應商，以便通過升級或補丁來解決問題。

　　IEC 62304要求制造商制定規程，以便評估和實現SOUP項目升級、漏洞修復、補丁和報廢。必須分析和驗證每個升級、漏洞修復和補丁，以便確定這些升級是否引入了其它潛在的、可能導致出現危險情形的因素。一如往常，必須確定是否需要采取其它軟件風險控制措施。

　　維護期間，要求制造商分析SOUP項目變更，以便確定軟件修訂是否會干擾現有的風險控制措施。制造商必須制定獨特的配置項目和版本識別機制。對于使用的各種SOUP配置項目，制造商需要記錄標題、SOUP制造商名稱和獨特的SOUP標志符。該標識符可以確定醫療器械軟件內包含的軟件配置項目及其版本。

　　通過采用IEC 62304的高級軟件過程，公司能夠更好地開發安全的產品，避免代價高昂的召回，確保相同的開發過程能夠鞏固維護和升級過程。