医疗器械软件.doc

《医疗器械软件.doc》由会员分享，可在线阅读，更多相关《医疗器械软件.doc（24页珍藏版）》请在三一办公上搜索。

1、 医疗器械软件 Part3：软件生存周期过程（YY/T 0664）的过程参考模型Medical device software Part3：Process reference model of medical device software life cycle processes(IEC 62304) （标准草案） 目录引言III1 范围62 规范性引用63 术语和定义64 医疗器械软件生命周期过程64.1 软件开发过程64.1.1 软件开发计划64.1.2 软件需求分析74.1.3 软件体系架构设计84.1.4 软件详细设计84.1.5 软件单元的实现和验证94.1.6 软件集成和集成测试

2、94.1.7 软件系统测试104.1.8 软件发布104.2 软件维护114.2.1 目的114.2.2 输出114.3 软件风险管理114.3.1 目的114.3.2 输出114.4 软件配置管理124.4.1 目的124.4.2 输出124.5 软件问题解决134.5.1 目的134.5.2 输出13前 言1） IEC是一个国际性电工标准化机构，负责有关电气工程和电子工程领域中的国际标准化工作。IEC的宗旨是，促进电气、电子工程领域中标准化及有关问题的国际合作，增进国际间的相互了解。为实现这一目的，IEC出版包括国际标准，技术规范，技术报告，公开可用规范（PAS），以及指南等在内的各种出版

3、物。IEC的筹备工作获得了各技术委员会的认可，各IEC的国家组织也致力于此。各种国际化的，政府的非政府的组织与IEC共同参与这些筹备工作。IEC与国际化标准组织(ISO)紧密合作，根据协议规定的条件，两家组织达成共识。2） 由于每个技术委员会都会有来自于相关IEC国家技术委员会的代表，IEC对技术术语的正式承认或认可都会尽可能接近有关该问题的国际共识。3） IEC的出版物在国际范围有推荐性意义，并且在某种意义上被IEC国家技术委员会所接受。虽然尽力的确保IEC出版物技术内容的准确性，但是IEC对于终端用户的错误理解或者使用不承担任何责任。4） 为了提倡国际化统一，IEC国家委员会承担了以透明的

4、方式将IEC的出版物最大程度地应用到他们国家或者地区的出版物上。任何IEC标准和相应的国家或地区的出版物的分歧，应在后者清楚地表标明。5） IEC本身不会提供任何相应的认证程序。由独立的认证机构提供认证评估服务，并且在某些领域，颁发IEC的合格标志。IEC本身不会为任何独立认证机构提供的服务负责。6） 所有的用户需要确保他们获得的是最新版本的出版物。7） 对于IEC或者它的负责人，员工、雇员、代理包括个人专家和技术委员会的会员不承担任何责任和义务；IEC国家委员会对于任何直接或间接的人身伤害，财产损失，或者其他自然伤害不承担任何责任和义务；对于因使用或依赖次IEC出版物或者其他IEC出版物而产

5、生的成本（包括法律费用）和费用也不承担任何责任和义务。8） 需要关注的是本出版物中引用到的规范性参考文件。使用参考出版物对于本出版物的正确应用来说不可或缺的。9） 需要关注的是，IEC出版物的中提到的某些部分有可能涉及专利问题，但IEC对这些专利不承担任何责任。IEC技术委员会的主要宗旨是筹备国际标准。然而，当收集到各种不同形式的数据时， 技术委员会提出技术报告的出版物，通常被作为国际标准来进行发布，比如“技术发展水平”。IEC TR80002-3技术报告，是由62A子委员会（医用电气设备的通用要求IEC技术委员会62）和ISO技术委员会210（质量管理和医疗设备通用并行要求）的联合工作组筹备

6、的，它作为一个双logo的标准被发布。技术报告的内容基于以下两个文件：调查稿投票报告62A/918/DTR62A/928/RVC关于批准该技术报告的所有投票信息都可以从上表中的投票报告中获得。在ISO，技术报告是由16票中的14票投票通过而获得批准。这一出版物根据 ISO/IEC官方进行编写的，第二部分是根据ISO/IEC 24774进行编写的，对于过程描述的系统和软件工程的生命周期管理指南80002系列的所有部分的清单，可以在IEC网站上的名为“医疗器械软件”的文中找到。委员会确保，在IEC网站http:/webstore.iec.ch上标有一个稳定的日期，该时间与特定的出版物相关联， 对于

7、这个指定的日期，出版物可能会有以下几种情况：l 重新确认的；l 撤回的l 替代修订过的版本或者l 被修订的双语版本可能会在后续进行发布。引 言0.1 背景软件往往是医疗器械技术的一个组成部分。包含软件的医疗器械的安全性和有效性的建立，要求软件的设计不仅能够满足它的预期目标，而不引起任何不可接受的风险。按照一系列国际认可的软件开发实践方式，可以达到这一目标。 本技术报告(TR) 为医疗器械软件的安全设计和维护提供了生命周期过程的框架，称为过程参考模型（PRM）。此过程参考模型中的过程定义与ISO/IEC 24774：2001系统和软件工程的生命周期过程定义管理指南完全保持一致。 本技术报告介绍了

8、医疗器械软件开发的过程参考模型，该模型整合了IEC62304：2006以及ISO/IEC12207:2008国际标准的软件生命周期过程的要求。 本技术报告的宗旨是使得医疗器械软件的开发者将其应用于软件需求的开发上，使其能够遵循IEC 62304:2006医疗器械软件的安全性级别。每一个过程的输出对应的安全性级别在IEC62304：2006内都进行了定义。没有对应安全性级别的过程输出都仅基于ISO/IEC12207:2008。这些过程的输出，在达成过程目的的同时能提供有利的附加产物，这对于以安全为关键特性的软件开发很有价值。过程参考模型同时也可以作为通用基准，为不同的模型和方法提供过程评估，以确

9、保评估结果报告表达形式的一致性。 审查医疗器械软件过程的评估人员可以利用过程参考模型为IEC62304过程输出提供审核检查清单和报告。过程参考模型的过程定义由用于描述执行过程的高等级的整体目标，以及一系列用于展示过程目标成功实现的输出组成。这些过程的输出就是软件生命周期过程的要求。在任何过程定义中，过程输出是实现过程目标的充分必要条件。 医疗器械软件系统的制造商应按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个安全性级别（A，B，或C），具体可以参考标准IEC62304：2006。基于如下的严重度，应初步赋予软件相应安全性级别：A级：不可能对健康有伤害或者损坏B

10、级：可能有不严重的伤害C级：可能死亡或严重伤害0.2 技术报告组织此技术报告的编写遵循IEC62304标准的结构。附录A详细描述技术报告的开发过程。附录B提供IEC62304安全性级别条款与ISO/IEC12207:2008的映射关系。医疗器械软件开发过程参考模型的生命周期过程在过程名称，过程目标以及对应的过程输出中进行描述。在输出声明的结尾，标有ISO/IEC12207的输出源自于ISO/IEC12207:2008，在标准IEC62304中没有直接对应的要求。想要使用此过程参考模型来审核IEC62304要求的人员需要忽略仅基于ISO/IEC12207:2008而生成的输出。医疗器械软件医疗器

11、械软件生命周期过程的过程参考模型1 范围本技术报告为IEC 80002的一部分，描述了医疗器械的软件生命周期过程。医疗器械软件生命周期过程以及对应的安全性级别源自于IEC 62304:2006，他们与ISO/IEC 12207:2008的软件开发生命周期过程是一致的，与ISO/IEC 24774:2010也完全一致。这三个标准的内容为此技术报告提供了基础。此技术报告没有提及：现有相关标准覆盖到的领域，比如，用于构建本技术报告的四个标准相关的国际标准（见参考文献）；FDA指南文件；或者软件开发工具。此技术报告描述了医疗器械软件开发的过程参考模型， 仅限于IEC 62304:2006所描述的生命周

12、期过程，过程名称对应于IEC 62304:2006。附录B所提供的IEC 62304:2006（基于ISO/IEC 12207:1995）与ISO/IEC 12207:2008的映射关系，对说明两份标准之间的详细规范的关系是必不可少的。本技术报告不适宜作为监督检查或者认证评估活动的依据。2 规范性引用下列文件中的条款（部分或全部）通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。IEC 62304:2006 医疗器械软件 软件生命周期过程ISO/IEC 12207:2008 系统与软件工程 软件生命周期过程3 术语和定义本

13、文件的目的，术语和定义参考IEC 62304:2006。注：为了保持开发过程参考模型要求的一致性，需要遵循ISO/IEC 24774标准规定的指南。特定的软件风险管理过程使得软件开发人员在开发医疗器械软件的时候， 能够实现他们必须要达到的软件需求。此过程参考模型同样可以使得医疗器械软件开发人员确定要开发需求的具体安全性级别。本技术报告中描述的过程参考模型对软件风险管理的要求仅包含ISO 14971标准中的部分要求，该部分要求在IEC 62304标准中涉及到。为了更好地达到本技术报告的目的，在此使用的软件开发相关术语和定义都源自于标准IEC62304。4 医疗器械软件生命周期过程4.1 软件开发

14、过程4.1.1 软件开发计划4.1.1.1 目的软件开发计划的目的(IEC 62304,5.1)是为了建立计划，以便实施软件开发过程活动。4.1.1.2 输出软件开发计划的成功实施需要保证以下输出：a) 软件开发计划的建立是为了保证软件的开发适合于所开发软件系统的范围、规模以及软件安全性级别A，B，C级。注1 软件开发计划应包括开发过程的描述，过程输出交付物（包括文件），软件配置和变更管理（包括未知来源软件配置项和支持开发的软件），以及软件问题解决过程。b) 软件开发计划应说明如何在系统需求，软件需求，软件系统测试和风险控制措施之间建立可追溯性A，B，C级。c) 应保持软件开发计划在整个软件生

15、命周期中的持续更新A，B，C级 。d) 软件开发计划需要引用系统设计和系统开发A，B，C级 。e) 对于C级的软件，软件开发计划需要包含或者引用软件项的开发相关的标准，方法和工具C级。f) 软件开发计划需要包含或者引用软件单元的集成策略，包括对未知来源软件SOUP的集成。B，C级 g) 软件开发计划需要包括或者引用验证计划。A，B，C级 注2 验证计划包含了所有与相关文件一起完成的活动和任务。h) 软件开发计划需要包括或引用风险管理计划，包括对于未知来源软件的风险管理计划。A，B，C级 i) 软件开发计划需要包括或引用在整个软件生命周期过程中需要生成的文件的计划，以及在软件文件编写过程中使用到

16、的标准。A，B，C级 j) 软件开发计划需要包括或引用配置管理计划。A，B，C级 注3 软件配置管理计划包括或引用如下文件：i) 受控项的级别、类型、类别或列表；ii) 软件配置管理活动和任务；iii) 负责执行软件配置管理和活动的组织iv) 与其他组织的关系，比如软件开发，软件维护v) 何时将这些项目置于配置控制管理之下vi) 何时应用问题解决过程vii) 包含在其他软件产品或实体的软件配置项，比如未知来源软件k) 软件开发计划需要包含或引用在医疗器械软件开发中受控的支持项或设置。B，C级 l) 软件开发计划需要包含在验证软件配置项之前，使其处于形成文档的配置管理控制之下。B，C级 4.1.

17、2 软件需求分析4.1.2.1 目的软件需求分析(IEC 62304, 5.2)的目的是建立系统软件元素的需求。4.1.2.2 输出软件需求分析的成功实施需要确保以下：a) 定义指派的软件系统和接口的需求。A，B，C级 b) 分析软件需求的正确性和可测性。A，B，C级 c) 明确运行环境对于软件需求的影响。A，B，C级 d) 建立软件需求和系统需求之间的一致性和可追溯性。A，B，C级 e) 定义软件需求实施的优先次序。ISO/IEC 12207f) 现有的需求，包括系统需求，应根据软件需求分析的结果进行适当更新。A，B，C级 g) 软件需求的变更需要对成本，进度和技术影响进行评估。ISO/IE

18、C 12207h) 制定软件需求基线，并通知到所有受影响的各方。ISO/IEC 12207i) 软件需求应包含针对硬件失效、以及潜在软件缺陷所实施的软件风险控制措施。B，C级 注1软件架构实现了已识别的风险管理需求注2 基于可能造成的危害，为每个软件项制定相应的软件安全性级别j) 在建立软件需求时，应对医疗器械风险分析进行适当地再评估并更新。A，B，C级 4.1.3 软件体系架构设计4.1.3.1 目的软件架构设计(IEC 62304, 5.3)的目的是为了提供一种软件设计，该设计实现软件需求，并且可基于软件需求进行验证。4.1.3.2 输出软件体系架构设计的成功实施需要确保以下内容：a) 软

19、件体系架构设计的开发和基线，应描述实现软件需求的软件项，包括未知来源软件软件。B，C级b) 对于未知来源软件项，定义所有功能和性能需求，包括系统的硬件和软件需求。B，C级；注1 例如包括处理器的类型和速度，寄存器的类型和大小，系统软件类型，通信以及显示软件需求。c) 定义每个软件项的内部和外部的接口。B，C级d) 建立软件需求和软件设计之间的一致性和可追溯性。ISO/IEC 12207e) 对于风险控制，识别和确保软件项之间隔离的有效性是必要的。B，C级；注2 一种隔离的例子是通过将软件项运行在不同的处理器上。通过在处理器之间不共享资源来确保有效的隔离。f) 确保软件系统结构实现了系统和软件需

20、求，包括相关的风险控制措施。B，C级4.1.4 软件详细设计4.1.4.1 目的软件详细设计(IEC 62304, 5.4)的目的在于为软件的编码和测试提供足够详细的设计。4.1.4.2 输出软件详细设计的成功实施需要确保以下内容：a) 软件系统架构细化到软件单元；B，C级b) 开发软件项的每个软件单元的详细设计；B，C级c) 定义每个软件单元的外部接口；B，C级d) 建立软件详细设计、软件需求，和软件系统架构设计之间的一致性和可追溯性。ISO/IEC 12207e) 验证软件详细设计并形成文档，确保其实现软件体系结构，并且不和软件体系结构相矛盾。C级。4.1.5 软件单元的实现和验证4.1.

21、5.1 目的软件单元的实现和验证(IEC 62304, 5.5)的目的是生成可执行的软件单元来完全反映软件的设计。4.1.5.2 输出软件单元的实现和验证的成功实施需要确保以下内容：a) 实现由设计定义的软件单元A，B，C级 ；注1 对于开发A级医疗器械软件的开发人员，没有必要基于软件单元进行软件设计。b) 基于需求定义每个软件单元的验证过程B，C级 ；注2 当通过测试完成验证后，需要评价测试过程的正确性；c) 建立软件单元、软件需求，和软件设计之间的一致性和可追溯性。ISO/IEC 12207d) 在软件单元被集成到更大的软件项之前，建立软件单元的接受标准，并确保软件单元满足接受标准B，C级

22、 ；e) 对于C级医疗器械软件，建立补充的软件单元接受标准，并确保C级医疗器械软件满足接受标准C级f) 完成针对需求和设计的软件单元验证并形成文档B，C级 4.1.6 软件集成和集成测试4.1.6.1 目的软件集成和集成测试 (IEC 62304, 5.6)的目的是集成各软件单元形成集成的软件项，并与软件设计保持一致，证明在特定的或完成的操作平台上满足软件的功能性的和非功能性需求。4.1.6.2 输出软件集成和集成测试的成功实施需要确保以下内容：a) 集成软件单元B，C级 ；b) 运用定义的接受标准验证软件项B，C级 ；c) 将硬件项、软件项和人工操作的支持都被集成到系统中B，C级 ；d) 测

23、试集成的软件项，并记录集成测试的结果B，C级 ；注1在集成测试中要考虑的示例：i)软件所需的功能；ii）风险控制措施的实施iii)特定的计时和其他活动；iv）特定的内部和外部接口的功能，和v）包括可预见的误用在内的异常条件下的测试；注2集成测试允许测试重现性包括i)测试结果（通过/未通过和异常清单），以及ii)测试员身份信息。e) 软件项验证标准的制定需要确保其符合分配到各项的软件需求上B，C级 ；f) 建立软件设计和软件项之间的一致性和可追溯性ISO/IEC 12207；g) 当软件单元发生变更（包括关联的需求，设计和代码），需要制定回归策略，并用其重新验证软件项B，C级 ；h) 根据软件问

24、题解决过程管理在软件集成和集成测试过程中发现的异常B，C级 ；4.1.7 软件系统测试4.1.7.1 目的软件系统测试 (IEC 62304, 5.7)的目的是确认集成的软件系统符合定义的软件需求。4.1.7.2 输出软件系统测试的成功实施需要确保以下内容：a) 制定集成软件的接受标准，以证明其符合软件需求B，C级 ；注1建立一组测试，表达为输入触发，预期输出，通过/未通过的接受标准，以及执行软件测试的流程。b) 运用定义的接受标准验证软件项B，C级 ；注2：执行软件系统的测试，覆盖所有的软件需求。c) 根据软件问题解决过程管理在软件系统测试过程中发现的异常B，C级 ；d) 当软件项发生变更，

25、制定回归策略，并重新测试集成的软件B，C级 ；注3 通过回归策略，证明没有引入非预期的副作用。e) 在软件系统测试过程中软件项发生了变更，执行对应的风险管理活动B，C级 ；f) 验证软件系统测试B，C级 ；注4验证覆盖: i) 适当的验证策略和测试过程 ii) 对于软件需求的软件系统测试过程的可追溯性iii)在验证测试过程中覆盖所有的软件需求，以及iv)确保软件测试的结果符合通过/未通过的接受标准。g) 记录测试结果并允许测试的可重现性B，C级 ；注5 软件系统测试记录包括测试结果（通过/未通过以及异常清单）和测试者身份信息。4.1.8 软件发布4.1.8.1 目的软件发布 (IEC 6230

26、4, 5.8)的目的是确保每一个过程或项目对应的软件工作产品和/或服务完全实现了软件需求。4.1.8.2 输出软件发布的成功实施需要确保以下内容：a) 确保软件验证的完整性A，B，C级 ；注1验证活动包括软件发布前评估结果。注2 当重新发布软件产品（在进行问题修复或者软件变更的情况下），需要对所有安全性性级别的需求进行软件验证。b) 识别并记录已知的剩余异常B，C级 ；c) 确认所有已知剩余异常，以及其对于不可接受风险的潜在威胁进行了评估B，C级 ；d) 确定所有和文档相关的活动和任务的完整性B，C级 ；e) 向客户和其他涉及的各方公开验证活动的结果ISO/IEC 12207；4.2 软件维护

27、注1 本文件中的软件维护过程是标准ISO/IEC 152884特殊化维护过程。用户可以考虑声称遵循标准15288的过程，而非标准ISO/IEC12207:2008的过程。注2 本文件中的软件维护过程与标准ISO/IEC 147642兼容。4.2.1 目的软件维护过程(IEC 62304,Clause 6)的目的是为已交付的软件产品提供成本效益的支持。注：预交付软件维护活动包括界定交付后软件的运营，支持以及后勤计划。交付后活动包括软件修改，运营支持，比如培训或者提供技术支持。4.2.2 输出软件维护过程的成功实施需要确保以下内容：a) 根据发布策略，制定相应的维护策略来管理产品的修改，包括未知来

28、源软件项A，B，C级 ；注1：建立接受、记录、评估、解决以及跟踪问题报告和用户反馈的修改请求的过程。注2：使用风险管理过程和软件配置管理过程管理软件的变更和修改。注3：定义评价和实施升级，问题修复，补丁以及未知来源软件废弃的流程。b) 监控，记录和评估所有的反馈，来确保系统和软件的能够根据需要及时更新A，B，C级 ；c) 分析问题报告的安全性的影响A，B，C级 ；注4：评估每一个问题的报告，以确定是如何影响已发布的软件系统的安全。d) 识别现有系统变更对于组织，操作或者接口的影响A，B，C级 ；e) 评估和批准对于修改已发布软件系统包括关联文档的变更需求A，B，C级 ；f) 软件系统的修改需要

29、通知所有的影响方A，B，C级 ；注5：这些修正包括通知持续不变使用已发布的软件的后果，以及为已发布软件安装变更的指南。g) 修改软件的开发包含对应的测试，来确保没有影响需求A，B，C级 ；注6：与安全相关的软件变更需求由软件风险管理过程处理。h) 软件的升级移植至用户环境ISO/IEC 12207；4.3 软件风险管理4.3.1 目的软件风险管理(IEC 62304,Clause 7)的目的是确保所有的由软件引起的危害都得到了处置。4.3.2 输出软件风险管理过程的成功实施需要确保以下内容：a) 识别所有可能引起危害处境的软件项B，C级 ；注1:危害处境是软件失败直接导致的，或者在软件中实施的

30、风险控制措施失败而导致的。b) 识别所有可能引起危害处境的潜在原因B，C级 ；注2:潜在原因包括a)不正确或者不完整的功能规范。b)已识别软件项功能中的软件缺陷。c) 未知来源软件的失效或非预期结果。d) 硬件失效或者其他软件缺陷导致的不可预知的软件操作。以及d) 合理的可预见的误操作。c) 评估公布的未知来源软件的异常清单B，C级 ；注3：评估未知来源软件的异常清单，确定是否存在任何可以引发一些了事件而导致危害处境的异常。d) 记录所有可能引起危害处境的潜在原因B，C级 ；注4：在风险管理文件中记录潜在的原因。e) 记录可能导致危害处境的事件序列B，C级 ；注5在风险管理文件中记录潜在的原因

31、。f) 根据记录的每一个由软件项引起危害处境的潜在原因，定义对应的风险管理措施B，C级 ；注6：风险控制措施可以在硬件、软件、工作环境或者用户指令中实施。g) 风险控制措施与软件需求中的软件项功能一样进行实施，并且每个软件项分配安全性级别B，C级 ；注 7：基于风险控制措施控制下的危害可能性影响，对软件项分配相应的软件安全性级别。注 8：根据软件开发过程开发软件项。h) 验证执行的风险控制措施，并且记录验证结果B，C级 ；i) 评估已实施的风险控制措施以识别任何可能导致危害处境的新的事件序列B，C级 ；注 9：在风险管理文件中记录已识别的新事件序列。j) 建立并记录软件危害的的可追溯性B，C级

32、 ；注10 可追溯性来自a) 软件项的危害处境；b) 针对具体软件原因编制的软件项；c) 制定软件控制措施的软件原因；d)对风险控制措施的验证。k) 分析医疗器械软件的变更，来确认是否存在附加的潜在原因导致危害处境，需要引入附加的风险控制措施A，B，C级 ；l) 在已有的风险控制措施基础上，分析软件变更的影响，包括未知来源软件的变更B，C级 ；m) 基于软件变更的影响分析，执行相应的风险管理活动B，C级 ；4.4 软件配置管理注 软件配置管理过程来自标准ISO/IEC 12207：2008的项目过程组中的特殊化配置管理过程。4.4.1 目的软件配置管理过程(IEC 62304,Clause 8

33、)的目的是建立和维护过程或者项目中的软件项的完整性，并通知给相关各方。4.4.2 输出软件配置管理过程的成功实施需要确保以下内容：a) 识别，定义过程或者项目生成的配置项，并形成文档；A，B，C级 ；注1至于未知来源软件的配置项，记录配置项的细节，包括标题，制造商，以及每个未知来源软件配置项使用的未知来源软件的唯一标识。b) 将组成软件系统配置的一组配置项和版本形成文档A，B，C级 ；c) 实施配置项的修改，并将配置项的发布受控A，B，C级 ；注2在软件配置管理过程中对现有系统的修改进行管理时，配置项的变更的执行必须在变更请求获得批准后。注3实施和验证修改的软件项；保留评审记录，每一次的修改，

34、修改原因以及修改授权可以追溯。注4识别并执行作为变更结果需要的重复活动，包括软件系统和软件项安全性级别分类的变更。d) 告知受影响各方软件的修改和发布ISO/IEC 12207；e) 记录并报告软件项和修改的状态A，B，C级 ；注5 受控的配置项记录包括系统配置。f) 确保软件项的完整性和一致性ISO/IEC 12207；g) 配置项的存储，处理和交付进行受控B，C级 ；注6 创建发布软件的流程和环境，并文档化。注7 文档的存档时间要长于：设备的生命周期时间或相关法规要求规定的时间。注8 发布的软件版本形成文档。4.5 软件问题解决4.5.1 目的软件问题解决过程(IEC 62304,Clau

35、se 9)的目的是确保所有发现的问题能够被识别，分析，管理以及受控，直到解决为止。4.5.2 输出软件问题解决过程的成功实施需要确保以下内容：a) 根据问题的类型、范围和严重度，对问题进行记录，识别和划分等级A，B，C级 ；注1 问题报告包括实际或者潜在的不良事件，以及规范的偏差。注2 任何软件系统或者软件项的安全性级别的变更需要进行识别。b) 分析评估问题，以确定可接受的解决方案，并维护问题分析和评估的记录A，B，C级 ；注3创建纠正已识别问题所需措施的变更请求，否则记录未采取措施的理由。c) 使用软件风险管理过程，评估相关安全性问题。A，B，C级 ；注4评估的输出形成文档，并且创建已识别问

36、题纠正措施的变更请求，否则记录没有采取措施的理由，并形成文档。d) 通知相关各方已存在的问题A，B，C级 ；e) 遵循软件配置管理和软件系统测试过程，实施问题解决过程A，B，C级 ；注5 重复测试结果包括以下内容：i) 测试结果；ii) 发现的异常；iii) 测试的软件版本；iv) 相关硬件和软件的测试配置；v) 相关的测试工具；vi) 测试的日期；和vii) 测试员身份信息f) 维护问题报告，问题解决过程以及问题验证的记录。A，B，C级 ；注6 风险管理文件根据必要性进行更新g) 明确所有上报问题的状态和问题之间的趋势A，B，C级 ；注7 软件问题解决过程可以用来管理，跟踪和控制软件变更请求

37、。h) 遵循软件配置管理过程，跟踪问题关闭A，B，C级 ；注8 不良趋势需要扭转i) 在软件变更后，保留测试，重新测试以及回归测试的记录A，B，C级 ；注9 测试文档包括i) 测试结果；ii)发现的异常；iii)测试的软件版本号；iv) 相关的硬件和软件测试配置；v) 相关测试工具；vi) 测试日期，以及vii）测试人员身份信息。附录A(资料性附录)本技术报告的开发IEC 62304过程名称活动任务ISO/IEC 12207过程名称过程目的过程输出活动任务图A.1 说明了用于构建医疗器械软件开发过程参考模型的两份标准(IEC 62304：2006和ISO/IEC12207：2008)是如何在他

38、们的过程描述中进行要求介绍。IEC 62304：2006中的过程要求在活动层进行描述。IEC 62304：2006在过程目的声明中，不提供过程描述。在ISO/IEC12207：2008中，在过程的目的和输出描述完后，在活动和/或任务层描述要求。在这两份标准中，在一项活动或任务中描述的要求包含了许多不同结果的发展。基于ISO/IEC24774，过程输出本应该每次都是用一句话陈述一个要求。过程输出是在软件开发生命周期中实现这些要求的逻辑活动序列。图A.1 IEC 62304：2006和ISO/IEC12207：2008过程元素的要求在医疗器械软件开发的过程参考模型中，IEC 62304：2006软

39、件开发过程的要求直接映射到ISO/IEC12207：2008的过程输。如果存在映射到IEC62304要求的对应输出，那么在医疗器械软件开发的过程参考模型中需要同时采用它的安全性级别。对于没有对应安全性级别的过程输出，该过程输出是源自于ISO/IEC12207：2008而没有对应的IEC 62304：2008相关要求。IEC 62304：2006重日常使用的范例信息以与相应的过程输出的注释的方式包含在过程参考模型中。IEC 62304ISO/IEC 12207软件开发特定要求风险管理特定要求过程输出医疗器械软件开发PRM软件开发规范需求对比整合图 A.2医疗器械软件开发过程参考模型过程输出的发展

40、过程参考模型的范围仅限于IEC62304的过程。表A.1描述了IEC62304（12个过程）的10个过程直接映射到ISO/IEC12207：2008的过程中，剩余的两个过程软件开发计划和软件风险管理，没有直接映射到ISO/IEC12207中。表A.1 IEC 62304：2006和ISO/IEC12207：2008的过程的映射关系IEC 62304 过程对应的ISO/IEC12207：2008过程5.2软件需求分析软件需求分析5.3软件架构设计软件架构设计5.4软件详细设计软件详细设计5.5软件单元实现和验证软件构造5.6软件集成和集成测试软件集成5.7软件系统测试软件质量测试5.8软件发布软

41、件验证6软件维护软件维护8软件配置管理软件配置管理9软件问题解决软件问题解决附录B（资料性附录）IEC62304：2006与ISO/IEC 12207：2008之间的映射关系两份不同国际标准要求之间的映射的目的在于将不同的基本要求整合到一个基于参考过程模型的更精简的要求集合，能够将其应用在医疗器械软件开发的过程参考模型的发展。除了软件风险管理过程，大部分 62304的过程映射到ISO/IEC 12207:2008的对应部分。在对于对应过程的映射实施过程中，将反复比较和备忘的扎根理论方法作为系统方法应用到该过程中。反复比较是一个数据整合的迭代过程，在该过程中规范了特定数据的维度和属性。在每个过程

42、输出的最终映射达成一致之前，需要经过多次反复比较和备忘的迭代。表B.1描述了ISO/IEC 12207:2008和IEC 62304：2006的过程输出的映射结果。左边的第一和第二列分别为IEC 6230要求中的过程名称和条例号；表中的第三列是来自这些要求的过程输出序列清单。在接下来的三列中是与过程输出相关的安全性级别，为每个过程输出提供安全性级别能够帮助医疗器械软件开发者更好的识别专门适用于软件安全性级别的要求集。对应的ISO/IEC 12207的输出号和过程名称分别在第七和第八列中。表B.1 IEC 62304：2006过程参考模型和要求的过程输出，包括安全性级别，和ISO/IEC1220

43、7：2008要求之间的映射关系IEC 62304过程IEC 62304子条例医疗器械软件开发过程参考模型过程输出安全性等级ISO/IEC12207子条例ISO/IEC12207过程ABC5.1软件开发计划5.1.1(a),(b),(c),(d)(a) 软件开发计划的建立是为了保证软件的开发适合于所开发软件系统的范围、规模以及软件安全性级别7.1.1.2 a）软件实施 （7.1）5.1.1(c)(b)软件开发计划说明如何在系统需求，软件需求，软件系统测试，以及风险控制措施之间建立可追溯性5.1.2(c)应保持软件开发计划在整个软件生命周期中的持续更新5.1.3(d)软件开发计划需要引用系统设计和

44、系统开发5.1.4(e)对于C级的软件，软件开发计划需要包含或者引用软件项的开发相关的标准，方法和工具5.1.5(f)软件开发计划需要包含或者引用软件单元，包括未知来源软件的整合策略。7.1.6.2 a）5.1.6(g)软件开发计划需要包括或者引用验证计划7.1.4.2 a）,b)5.1.7(h)软件开发计划需要包括或引用风险管理计划，包括对于未知来源软件的风险管理计划5.1.8(i)软件开发计划需要包含或引用在整个软件生命周期过程中生成的文件的策略，以及在软件文件编写过程中用到的标准7.2.1.2 a）,b)5.1.9(j)软件开发计划需要包含或引用配置管理计划7.2.2.2 a）5.1.1

45、0(k)软件开发计划需要包含或引用在医疗器械软件开发中受控的支持项或设置。5.1.11(l)软件开发计划需要包含在验证软件配置项之前，使其处于形成文档的配置管理控制之下IEC 62304过程IEC 62304子条例医疗器械软件开发过程参考模型过程输出安全性等级ISO/IEC12207子条例ISO/IEC12207过程5.2软件需求分析5.2.1(a)定义指派的软件系统和接口的需求7.1.2.2 a)软件需求分析（7.1.2）5.2.6(a)-(e)(b)分析软件需求的正确性和可测性7.1.2.2 b)5.2.2(c)明确运行环境对于软件需求的影响7.1.2.2 c)5.2.6(f)(d)建立软件需求和系统需求之间的一致性和可追溯性7.1.2.2 d)(e)定义软件需求实施的优先次序7.1.2.2 e)5.2.5(f)现有的需求，包括系统需求，应根据软件需求分析的结果