軟件的安全性級別

1、4.3 *軟件的安全性級別a）制造商應按照軟件系統(tǒng)引起的危害對于患者、操作者或其他人員的可能影響，賦 予每個軟件系統(tǒng)一個軟件安全性級別（A、B或C）?；谌缦碌膰乐囟?，應初步賦予軟件相應安全性級別：A級：不可能對健康有傷害或損壞。B級：可能有不嚴重的傷害。C級：可能死亡或嚴重傷害。如果危害可能由軟件系統(tǒng)未能象規(guī)定的那樣想作用引起，則此項失效的概率應假定為 100%。如果軟件失效引起死亡或嚴重傷害的風險，隨后由硬件風險控制措施降低到可接受水平 （如YY/T 0316所規(guī)定），或者降低失效后果或者降低由失效引起的死亡或嚴重傷害的概率， 軟件安全性級別可從C降低到B；如果軟件失效引起的非嚴重傷害風險

2、同樣通過硬件風險控 制措施降低到可接收水平，軟件安全性級別可從B降低到A。b）制造商應依據(jù)風險控制措施所控制的危害的可能影響，對實施風險控制措施起作 用的每個軟件系統(tǒng)賦于一個軟件安全性級別。c）制造商應在風險管理文檔中將賦于每個軟件系統(tǒng)的軟件安全性級別形成文檔。d）當一個軟件系統(tǒng)分解為軟件項，及當一個軟件項又進一步分解為幾個軟件項時， 此類軟件項應繼承原軟件項（或軟件系統(tǒng)）的軟件安全性級別，除非制造商以文 件形式證明分類為不同的安全性級別的理由。此類理由說明應解釋新的軟件項是 如何被分開的，以便可對其另行分級。e）如果以分解方式產(chǎn)生的軟件項的安全級別和其源軟件項不同，制造商應對每個軟 件項的軟

3、件安全級別形成文檔。f）為符合本標準，無論特定級別的軟件項是否需要一個過程，此過程是否有必要應 用于一組軟件項，制造商應使用此組中最高級別的軟件項所要求的諸過程和任務， 除非制造商在風險管理文檔中有使用較低級別的理由的說明文件。g）對每個軟件系統(tǒng)，在賦于軟件安全性級別以前，均應應用C級要求。注：在隨后的要求中，對該項要求必須實施的軟件安全性級別，以級形式標示 于該要求之后。7 *軟件風險管理過程*促成危害處境的軟件分析判定可能促成危害處境的軟件項制造商應確定在YY/T 0316的醫(yī)療器械風險分析活動（見4.2）中判定的可能危害處境 的軟件項。B、C 級注：危害處境可能是軟件失效的直接結果，或在

4、軟件中實施風險控制措施失效的效果。判定促成危害處境的可能原因制造商應判定上面確定的軟件項和促成危害處境可能原因。制造商應考慮的可能原因，適當時包括：a）不正確的或不完整的功能性說明；b）在已識別的軟件項功能性中的軟件缺陷；c）來自未知來源軟件（SOUP）的失效或非預期結果；d）可能導致不可預知的軟件運行的硬件失效或其他軟件缺陷，和；e）合理可預見的誤用。B、C 級7.1.3評價公布的未知來源軟件異常清單如果來自未知來源軟件的失效或意外結果是促成危害處境的軟件項要可能原因，制造商 至少應評價未知來源軟件項供應商公布的任何異常清單，此未知來源軟件項與用于醫(yī)療器械 的未知來源軟件項的版本有關，以確定

5、是否有任何導致事件序列的異常，此事件序列會促成 危害處境。B、C 級7.1.4將可能原因形成文檔制造商應在風險管理文件中將軟件項促成危害處境的可能原因形成文檔。（見YY/T 0316）。7.1.5將事件序列形成文檔制造商應在風險管理文件中將可能導致在7.1.2中所判定的危害處境的事件序列形成文 檔。B、C 級7.2風險控制措施7.2.1規(guī)定風險控制措施對于在管理文件中形成文檔的每個促成軟件項危害處境的可能原因，制造商應規(guī)定風險 控制措施并形成文檔。B、C 級注：風險控制措施可以在硬件、軟件、工作環(huán)境或用戶說明書中實施。在軟件中實施的風險控制措施如果風險控制措施作為軟件項功能的一部分來實施，制造

6、商應：a）在軟件需求中包括風險控制措施；b）基于風險控制措施所控制危害的可能影響，賦予軟件項一個軟件安全性級別；和c）按照第5章開發(fā)軟件項。B、C 級注：本要求為YY/T 0316的風險控制要求提供補充的詳細資料。7.3風險控制措施的驗證驗證風險控制措施對于7.2中形成文檔的每個風險控制措施的實施應進行驗證，并將此驗證形成文檔。B、C 級將任何新事件序列形成文檔如果風險控制措施作為軟件項實施，制造商應評價該風險控制措施，以判定可能導致危 害處境的任何新的事件序列，并在風險管理文件中形成文檔。B、C 級將可追溯性形成文檔制造商應將軟件危害的可追溯性形成文檔，適當時有：a）從危害處境到軟件項；b）

7、從軟件項到特定軟件原因；c）從軟件原因到風險控制措施，和；d）從風險控制措施到風險控制措施的驗證。B、C 級注：見YY/T 0316風險管理報告。7.4軟件更改的風險管理7.4.1分析醫(yī)療器械軟件（包括未知來源軟件）更改以確定是否：a）引入了促成危害處境的附加的可能原因，和；b）要求的附加軟件風險控制措施。A、B、C 級分析軟件更改對現(xiàn)有風險控制措施的影響制造商應分析軟件的更改，包括對未知來源軟件的更改，以確定軟件是否會干擾現(xiàn)有風 險控制措施。B、C 級基于分析完成風險管理活動制造商應在這些分析的基礎上完成7.1、7.2和7.3中所確定的有關風險管理活動。B、C 級B.4.2 風險管理軟件開發(fā)

8、充分地參與風險管理活動，以確保所有和醫(yī)療器械軟件相關的合理可預見的風 險得到考慮。要求制造商應用一個符合YY/T 0316的風險管理過程，明確進進行醫(yī)療器械風險管理， 而不要在本軟件工程標準中規(guī)定一個合適的風險管理過程。由軟件促成的危害引發(fā)的特定 軟件風險管理活動在第7章描述的支持過程中確定。B.7 軟件風險管理過程軟件風險管理是整個醫(yī)療器械風險管理的一部分，孤立闡述是不充分的。本標準要求應 用符合YY/T 0316的風險管理過程。如YY/T 0316所規(guī)定的那樣，風險管理特別涉及到有關 醫(yī)療器械使用的風險的有效管理的框架。YY/T 0316的一部分屬于控制與在風險分析中已識 別的每個危害有關

9、的已識別的風險。本標準中的軟件風險管理過程預期提供對軟件（包括在 風險分析期間識別的可能促成危害處境的軟件，或用于控制醫(yī)療器械風險的軟件）風險控制 的附加要求。由于以下兩個原因，軟件風險管理過程包括在本標準中：a）本標準的預期讀者需要理解他們在軟件職責范圍內(nèi)對風險控制措施的最低要求：b）通用風險管理標準YY/T 0316,在本標準中作為規(guī)范性引用文件而提供，不特別闡 述軟件的風險控制和在軟件開發(fā)生存周期中風險控制的位置。軟件風險管理是整個醫(yī)療器械風險管理的一部分。軟件風險管理活動要求的計劃、規(guī)程 和文檔可以是一系列的單獨文檔或單一文檔，或者只要本標準中的所有要求已滿足時，它們 可以與醫(yī)療器械風

10、險管理活動相整合并編制成文檔。B.7.1促成危害處境的軟件分析預期器械的危害分析將確定危害處境和相應的風險控制措施，以降低那些危害處境的概 率和/或嚴重程度到可接收的水平。也預期將風險控制措施分配給將執(zhí)行那些風險控制措施 的軟件功能。然而，不期望在軟件體系結構形成之前識別所有的器械危害處境。在那時已知道在軟件 部件中如何實現(xiàn)軟件功能，可以評價分配給軟件功能的風險控制措施的實用性。在那時應當 修訂器械危害分析以包括：已修訂的危害處境；已修訂的風險控制措施和軟件需求；由軟件引起的新的危害處境，如與人的因素有關的危害處境。軟件體系結構應當包括劃分軟件部件的可信的策略，以使它們不以不安全的方式相互作

11、用。4. 1. 3軟件風險管理過程的活動和任務的計劃應有以下內(nèi)容：4. 1. 3. 1軟件的安全性級別按照軟件系統(tǒng)引起的危害對于患者、操作者或其他人員的可能影響，賦予每個軟件系 統(tǒng)一個軟件安全性級別（A、B或C）?；谌缦碌膰乐囟?，初步賦予軟件相應安全性級別：A級：不可能對健康有傷害或損壞。B級：可能有不嚴重的傷害。C級：可能死亡或嚴重傷害。如果危害可能由軟件系統(tǒng)未能象規(guī)定的那樣想作用引起，則此項失效的概率應假定為 100%。b .依據(jù)風險控制措施所控制的危害的可能影響，對實施風險控制措施起作用的每個軟 件系統(tǒng)賦于一個軟件安全性級別。當一個軟件系統(tǒng)分解為軟件項，及當一個軟件項又進一步分解為幾個軟件項時，此 類軟件項應繼承原軟件項（或軟件系統(tǒng)）的軟件安全性級別，除非以文件形式證明分 類為不同的安全性級別的理由。此類理由說明應解釋新的軟件項是如何被分開的，以便 可對其另行分級。對每個軟件系統(tǒng)，在賦于軟件安全性級別以前，均應用C級要求。4. 1. 3. 2促成危害處境的軟件分析判定可能促成危害處境的軟件項確定在