為醫療設備爭取上市批準是一項艱辛的任務，制造商必須放眼于純技術性質以外的挑戰，集中精力培養以軟件為基礎的醫療設備開發所需的環境和文化。具體來說，應該考慮十項醫療設備構建和審批的重要前提，但這些前提經常被人忽略。

　　1、安全文化

　　缺乏安全文化普及的公司，不太可能生產出安全的醫療產品。安全文化不僅僅是允許工程師提出有關安全問題的文化，而且也是鼓勵他們從安全的角度去考慮每一個決定的文化。一個程序員可能會有這樣的問題：“我可以用A技術或B技術來編寫這個信息交換，但是對如何平衡A的較好性能和B的較高可靠性沒有把握”，并且知道應該和誰來討論這個決定。而我們必須培養這種文化，來鼓勵程序員思考此類問題。

　　2、專家

　　我們需要專家。定義一個安全系統必須做什么，并確認它達到了安全要求，都需要專門的培訓和經驗。安全系統一定要簡潔，設計一個簡潔的系統對于任何工程師而言都是最大的挑戰。

　　歸根結底，還是需要相關領域的專家（包括行業專家、系統架構師、軟件設計師、流程專家、程序員和驗證專家等）來確定要求，選擇合適的設計模式并建立、驗證系統。

　　這樣的專業知識是昂貴的，因為它來自經驗而非課堂：大學計算機工程本科課程很少涉及嵌入式軟件開發，而教授如何創建足夠可靠性嵌入式系統的課程更是鳳毛麟角。

　　足夠可靠性：

　　1）沒有哪個系統是絕對可靠的，我們必須了解如何讓系統實現足夠的可靠性。

　　2）接受足夠的可靠性能減少開發費用，并為我們提供可驗證安全指標的方式。

　　3）如果我們不了解怎樣才算足夠可靠，就可能設計出一個復雜的系統，從而故障百出且容易崩潰。

　　自上世紀九十年代中期以來，軟件設計模式和技術有了很大的進步，但是許多設計人員尚未接觸到這些變化。圖1顯示的是醫療監測設備參考設計每小時故障概率的圖表詳情。借此找出風險所在并準確統計故障概率往往需要高深的專業知識。

　　
圖1 醫療監測設備參考設計每小時故障概率的圖表

　　3、流程

　　IEC 62304注重流程，沒有良好的流程，我們無法證明系統達到了它的安全要求。

　　對于目前基本上難以衡量的一些內容來說，良好的流程是一個可衡量的相關因素。衡量一個流程是否被遵循比較容易；而評估設計和代碼的質量是否良好就困難得多。雖然不能說一個好的流程就能保證好產品，但好產品不可能源自低劣的流程則是一個眾所周知的十事實。

　　IEC 62304 列出開發醫療設備所需的流程，不是因為這些流程能夠確保安全的產品，而是因為：

　　A. 它們提供了可以對開發參數進行評估的環境。例如，良好的測試流程有助于測試覆蓋率的統計。沒有這一流程，則不可能對測試覆蓋率作出任何申明。

　　B. 它們可提供用以保存安全案例證據鏈的架構。回顧性地生成安全案例是可能的，但是昂貴，而且一定會需要重新生成曾存在于項目開發過程中那些未被保留的證據。

　　4、明確的要求

　　安全指標必須闡明可靠性的程度，以及達到這些程度的限制條件。

　　FDA已經認識到“展示設計和生產常規的間接流程數據的合理性 ”不足以表明軟件的安全性， “注重于展示特定產品設備安全性的設備保證措施”也必不可少。這種展示包含于安全案例中，也反映了上述論題，即優質流程的目的不是保證優質產品，而是提供用以評估證據的環境。

　　每一個安全案例主要都會提出類似“這一系統將在條件C下，以可靠性B的水平，來操作A，如果不能做A，它會轉移到概率為P的設計安全狀態下”這樣的聲明。這一聲明及其相應的注意事項都會被列在系統安全手冊中，以便用于系統更高層次的安全案例中。

　　一個系統的可靠性是指其持續且 及時準確回應各種情況的能力：是可用性（及時響應要求的頻率）和可靠性（這些響應的正確率）的結合。

　　安全案例聲明系統的可靠性指標，提供達標的證據。可靠性指標的局限性和指標本身一樣重要。例如，一個醫療成像系統可以滿足IEC 61508 SIL3要求，實現不超過8小時的持續工作，8小時后系統必須重置（更新）。由于成像過程通常是短暫的，所以這一限制不會造成不便，哪怕這個系統一天要用 24小時。

　　5、系統失效

　　沒有哪個系統對漏洞免疫，特別是Heisenbugs— 那些“曇花一現”，而當我們尋找它們的時候又“消失無蹤”的神秘漏洞， ；失效狀況終究會發生：我們要建立的系統必須能夠恢復常態或進入其設計安全狀態。

　　表1 缺陷、錯誤和故障分析表

　　既然所有的系統都將包含缺陷，而缺陷可能導致故障，一個安全系統就必須包含多道防線：

　　安全關鍵型流程的獨立——找出哪些部件有安全關鍵性，設計時務必保證其不受其它零部件的影響。

　　防止缺陷演變為錯誤——盡管理想的解決途徑是識別并消除代碼故障，但是實際上很難做到。要小心Heisenbug，保證軟件的設計能夠發現和封閉缺陷，以免它們演變成錯誤。

　　防止錯誤演變為故障——相對于軟件來說，諸如復制和多樣化這樣的技術更適用于硬件，然而謹慎使用依然能夠奏效。

　　故障檢測和恢復——在許多系統中，轉移到預定義的設計安全狀態，并將恢復任務留給更高層次的系統（比如人）是可行的。有些系統則不能如此操作，所以系統必須恢復或重啟。一般而言，在不明確環境中企圖恢復，不如選擇帶有快速復原的crash-only模式。

　　6、驗證

　　測試不足以證明可靠性；需要其他方法來補充：形式化設計、統計分析和回顧性設計驗證等。

　　測試的設計是通過引發錯誤和故障來間接地找出設計或實施中的缺陷。測試的首要作用是對發現和孤立Bohrbug，即一種即便在調試程序應用時仍保持不變的連續重現的漏洞。但是測試在面對Heisenbug時作用較小，因為同一缺陷在每次發生時表現為不同的錯誤。

　　
圖2 一臺醫療監測設備系統級故障樹細節

　　在圖2所示的醫療監測設備系統級故障樹中，使用的貝葉斯網絡，可以天衣無縫地地融入采用貝葉斯技術的安全案例之中。

　　要證明我們的系統滿足其安全要求，我們必須采用包括測試在內的多種手段：

　　靜態分析-——受到包括FDA在內的多家機構的推薦，靜態分析對于定位可疑代碼十分有價值。它包含針對編碼標準的語法檢查、故障概率估計、針對代碼指令的正確驗證，以及符號執行（靜態/動態混合）。

　　實地使用和曾用數據——對建立可靠性指標至關重要，使用時間和該段時間內的故障情況的搜集應該貫穿整個產品生命周期：樣本越多，我們對提出的指標也就越有信心。

　　故障輸入——故意輸入故障既可以檢驗用來處理錯誤檢測的代碼，還可以幫助預估剩余故障的數目。和隨機測試分析一樣，故障輸入的結果需要細致的統計分析。

　　形式化和半形式化的設計驗證——傳統上是在執行前完成，設計驗證也可回顧性執行。

　　7、COTS和SOUP

　　無論是COTS，甚或是SOUP，只要這個部件有足夠證據來支持系統的整體安全案例，就可以采用。

　　建立一個安全軟件系統的最佳途徑通常不是完全自力更生，因為這樣所承擔的風險要比建立一個采用選定COTS（commercial off-the-shelf，商業成品）零部件的系統要大。建立操作系統、通信棧和數據庫需要專門的知識，而相應的COTS也許會有上千萬小時的使用歷史優勢。

　　雖然如此，對醫療設備開發者來說，COTS軟件通常是SOUP（software of uncertain provenance，不確定出處軟件），因而應該謹慎對待。IEC 61508和IEC 62304都假定SOUP會被用到。關鍵在于要有充足的可靠證據來量化SOUP對系統安全指標的影響。

　　這些證據將包括在實地使用數據、故障歷史記錄和其他歷史數據。我們應該要求獲得源代碼和測試計劃，這樣可以利用靜態代碼分析工具來檢驗軟件。供應商還應該提供用來構建軟件的詳細流程，或者是外部審核員的聲明，肯定這些流程適用于IEC 62304設備。

　　8、經認證的零部件及其供應商

　　具備安全認證的零部件，比如通過IEC 61508認證的操作系統，可以加速開發和驗證，有助于加快審準步伐。

　　如果使用COTS，采用獲得相關批準的零部件很有幫助。諸如FDA、MHAR、加拿大衛生部以及其他國家的同等部門的組織所審批的不是這些零部件，而且面向市場的整個系統或設備；即便如此，獲得類似IEC 61508或IEC 62304認證的零部件可以簡化審批流程，縮短上市時間。

　　要獲得認證，a）這些零部件必須在一個流程和質量管理都到位的環境中進行開發，b）它們必須經過合理的測試和驗證，c） COTS軟件供應商必須提供所有必要的文檔，來支持最終設備獲得批準。

　　9、審核員

　　審核員是我們的朋友，要盡早與他們合作。

　　在安全軟件開發的世界中，認證審核員是我們的朋友。他們知道我們要如何建立獲得認證的流程，也能幫助我們構建安全案例。越早讓審核員參與項目幫助我們，日后需要修改的地方就越少，開發周期的效率也越高。

　　在把證據加入安全案例之前，同審核員探索所提出的安全案例論點架構尤為有用。如果用類似GSN或BBN這樣的形式化構架來表達論點，清晰地將論點架構從證據中分離出來，那么我們就可以問審核員：“若我們給出該論點的證據，你能滿意嗎？”這可以減少審核過程中的意外。

　　10、產品發布不是終點

　　我們對安全系統所肩負的責任不會因產品發布而終結；它將一直持續到最后一個設備和最后一個系統的功成身退。

　　以下數字雖然有點陳舊，但是有說服力：軟件的更新會影響其完整性：FDA在1992-1998年間的一項研究表明，在3140個召回器件中，有242個（7.7%）是由于軟件故障。其中192個（幾乎占80%）的故障是由軟件維護中引入的缺陷引起。

　　換句話說，這些缺陷是在設備進入市場之后引入的。因此，我們用以確保軟件達到其安全要求的流程必須包括軟件的整個生命周期，包括修復和更新。