软件的安全性级别.docx

《软件的安全性级别.docx》由会员分享，可在线阅读，更多相关《软件的安全性级别.docx（11页珍藏版）》请在第壹文秘上搜索。

1、4.3*软件的安全性级别a）制造商应按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个软件安全性级别（A、B或CI基于如下的严重度，应初步赋予软件相应安全性级别：A级：不可能对健康有伤害或损坏。B级：可能有不严重的伤害。C级：可能死亡或严重伤害。如果危害可能由软件系统未能象规定的那样想作用引起，则此项失效的概率应假定为100%o如果软件失效引起死亡或严重伤害的风险，随后由硬件风险控制措施降低到可接受水平（如YY/T0316所规定），或者降低失效后果或者降低由失效引起的死亡或严重伤害的概率,软件安全性级别可从C降低到B;如果软件失效引起的非严重伤害风险同样通过硬件风

2、险控制措施降低到可接收水平，软件安全性级别可从B降低到Aob）制造商应依据风险控制措施所控制的危害的可能影响，对实施风险控制措施起作用的每个软件系统赋于一个软件安全性级别。c）制造商应在风险管理文档中将赋于每个软件系统的软件安全性级别形成文档。d）当一个软件系统分解为软件项，及当一个软件项又进一步分解为几个软件项时，此类软件项应继承原软件项（或软件系统）的软件安全性级别，除非制造商以文件形式证明分类为不同的安全性级别的理由。此类理由说明应解释新的软件项是如何被分开的，以便可对其另行分级。e）如果以分解方式产生的软件项的安全级别和其源软件项不同，制造商应对每个软件项的软件安全级别形成文档。O为符

3、合本标准，无论特定级别的软件项是否需要一个过程，此过程是否有必要应用于一组软件项，制造商应使用此组中最高级别的软件项所要求的诸过程和任务，除非制造商在风险管理文档中有使用较彳氐级别的理由的说明文件。g）对每个软件系统，在赋于软件安全性级别以前，均应应用C级要求。注：在随后的要求中，对该项要求必须实施的软件安全性级别，以级形式标示于该要求之后。7*软件风险管理过程7.1 *促成危害处境的软件分析7.1.1 判定可能促成危害处境的软件项制造商应确定在YY/T0316的医疗器械风险分析活动（见4.2）中判定的可能危害处境的软件项。B、C级注：危害处境可能是软件失效的直接结果，或在软件中实施风险控制措

4、施失效的效果。7.1.2 判定促成危害处境的可能原因制造商应判定上面确定的软件项和促成危害处境可能原因。制造商应考虑的可能原因，适当时包括：a）不正确的或不完整的功能性说明；b）在已识别的软件项功能性中的软件缺陷；c）来自未知来源软件（SOUP）的失效或预期结果；d）可能导致不可预知的软件运行的硬件失效或其他软件缺陷，和；e）合理可预见的误用。B、C级7.1.3 评价公布的未知来源软件异常清单如果来自未知来源软件的失效或意外结果是促成危害处境的软件项要可能原因，制造商至少应评价未知来源软件项供应商公布的任何异常清单，此未知来源软件项与用于医疗器械的未知来源软件项的版本有关，以确定是否有任何导致

5、事件序列的异常，此事件序列会促成危害处境。B、C级7.1.4 将可能原因形成文档制造商应在风险管理文件中将软件项促成危害处境的可能原因形成文档。（见YY/T0316X7.1.5 将事件序列形成文档制造商应在风险管理文件中将可能导致在7.1.2中所判定的危害处境的事件序列形成文档。B、C级7.2 风险控制措施7.2.1 规定风险控制措施对于在管理文件中形成文档的每个促成软件项危害处境的可能原因，制造商应规定风险控制措施并形成文档。B、C级注：风险控制措施可以在硬件、软件、工作环境或用户说明书中实施。7.2.2 在软件中实施的风险控制措施如果风险控制措施作为软件项功能的一部分来实施，制造商应：a）

6、在软件需求中包括风险控制措施；b）基于风险控制措施所控制危害的可能影响，赋予软件项一个软件安全性级别;和C）按照第5章开发软件项。B、C级注：本要求为YY/T0316的风险控制要求提供补充的详细资料。7.3 风险控制措施的验证7.3.1 验证风险控制措施对于7.2中形成文档的每个风险控制措施的实施应进行验证，并将此验证形成文档。B、C级7.3.2 将任何新事件序列形成文档如果风险控制措施作为软件项实施，制造商应评价该风险控制措施，以判定可能导致危害处境的任何新的事件序列，并在风险管理文件中形成文档。B、C级7.3.3 将可追溯性形成文档制造商应将软件危害的可追溯性形成文档，适当时有：a）从危害

7、处境到软件项；b）从软件项到特定软件原因；C）从软件原因到风险控制措施，和；d）从风险控制措施到风险控制措施的验证。B、C级注：见YY/T0316风险管理报告。7.4 软件更改的风险管理7.4.1 分析医疗器械软件（包括未知来源软件）更改以确定是否:a）引入了促成危害处境的附加的可能原因，和；b）要求的附加软件风险控制措施。A、B、C级7.4.2 分析软件更改对现有风险控制措施的影响制造商应分析软件的更改，包括对未知来源软件的更改，以确定软件是否会干扰现有风险控制措施。B、C级7.43基于分析完成风险管理活动制造商应在这些分析的基5出上完成7.1、7.2和7.3中所确定的有关风险管理活动。B、

8、C级B.4.2风险管理软件开发充分地参与风险管理活动，以确保所有和医疗器械软件相关的合理可预见的风险得到考虑。要求制造商应用一个符合YY/T0316的风险管理过程,明确进进行医疗器械风险管理，而不要在本软件工程标准中规定一个合适的风险管理过程。由软件促成的危害引发的特定软件风险管理活动在第7章描述的支持过程中确定。B.7软件风险管理过程软件风险管理是整个医疗器械风险管理的一部分，孤立阐述是不充分的。本标准要求应用符合YY/T0316的风险管理过程。如YY/T0316所规定的那样，风险管理特别涉及到有关医疗器械使用的风险的有效管理的框架。YY/T0316的一部分属于控制与在风险分析中已识别的每个

9、危害有关的已识别的风险。本标准中的软件风险管理过程预期提供对软件（包括在风险分析期间识别的可能促成危害处境的软件，或用于控制医疗器械风险的软件）风险控制的附加要求。由于以下两个原因,软件风险管理过程包括在本标准中：a）本标准的预期读者需要理解他们在软件职责范围内对风险控制措施的最低要求：b）通用风险管理标准YY/T0316,在本标准中作为规范性引用文件而提供，不特别阐述软件的风险控制和在软件开发生存周期中风险控制的位置。软件风险管理是整个医疗器械风险管理的一部分。软件风险管理活动要求的计划、规程和文档可以是一系列的单独文档或单一文档，或者只要本标准中的所有要求已满足时，它们可以与医疗器械风险管

10、理活动相整合并编制成文档。8.7.1 促成危害处境的软件分析预期器械的危害分析将确定危害处境和相应的风险控制措施，以降低那些危害处境的概率和/或严重程度到可接收的水平。也预期将风险控制措施分配给将执行那些风险控制措施的软件功能。然而，不期望在软件体系结构形成之前识别所有的器械危害处境。在那时已知道在软件部件中如何实现软件功能，可以评价分配给软件功能的风险控制措施的实用性。在那时应当修订器械危害分析以包括： 已修订的危害处境； 已修订的风险控制措施和软件需求； 由软件引起的新的危害处境，如与人的因素有关的危害处境。软件体系结构应当包括划分软件部件的可信的策略，以使它们不以不安全的方式相互作用。4

11、.1.3软件风险管理过程的活动和任务的计划应有以下内容：4.1.3.1 软件的安全性级别a.按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个软件安全性级别（A、B或C）O基于如下的严重度，初步赋予软件相应安全性级别：A级：不可能对健康有伤害或损坏。B级：可能有不严重的伤害。C级：可能死亡或严重伤害。如果危害可能由软件系统未能象规定的那样想作用引起，则此项失效的概率应假定为100%ob.依据风险控制措施所控制的危害的可能影响，对实施风险控制措施起作用的每个软件系统赋于一个软件安全性级别。c.当一个软件系统分解为软件项，及当一个软件项又进一步分解为几个软件项时，此类

12、软件项应继承原软件项（或软件系统）的软件安全性级别，除非以文件形式证明分类为不同的安全性级别的理由。此类理由说明应解释新的软件项是如何被分开的，以便可对其另行分级。d.对每个软件系统，在赋于软件安全性级别以前，均应用C级要求。4.1.3.2 促成危害处境的软件分析判定可能促成危害处境的软件项确定在YY/T0316的医疗器械风险分析活动（见4.2）中判定的可能危害处境的软件项。判定促成危害处境的可能原因判定上面确定的软件项和促成危害处境可能原因。考虑的可能原因，适当时包括：a.不正确的或不完整的功能性说明；b.在已识别的软件项功能性中的软件缺陷；c.来自未知来源软件（SoUP）的失效或预期结果；d.可能导致不可预知的软件运行的硬件失效或其他软件缺陷；e.合理可预见的误用。