YY/T 0664-2020
基本信息
标准号： YY/T 0664-2020
中文名称：替YY/T 0664-2008 医疗器械软件软件生存周期过程
标准类别：医药行业标准(YY)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：40112822
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YY/T 0664-2020代替YY/T 0664-2008.Medical device software- -Software life cycle processes.
3。 术语和定义
下列术语和定文适用于本文件。
3.1
活动activity :-组单个或多个相互关联或相互作用的任务。
3.2
反常anomaly与基于需求规范.设计文件和标准等的预期,成人的认知或经验相偏离的任何情况。反常司能但不限F在医疗器械软件成适用文档的评审.测试.分析.编译/编辑成使用过程中发现。
注:改写IEEE 144199，定又3.1.
3.3
体系结构arehitecture系统或组件的组织结构。[IEEE 610.12; 1990]
3.4
变更请求change request拟对医疗器械软件所做变更的形成文件的说明。
3.5
配置项conOguration item在给定参考点上能够唯一- 标识的实体。佳，改写1S0/IEC 127.20080定义4.7。
3.6
交付物deliverable对一项活动或任务所要求的结果或输出(包括文档)。
3.7
评价evaluation对一个实体满足其规定准则的程度的系统性确定。[ISO/IEC 12207;2008.定又4.12]
3.8
伤害harm对人体的损伤或对人体健康的损害,或对财产或环境的损害。[YY/T 0316-- 2016.定 义2.2]
3.9
危险(源) hazard可能导致伤害的潜在根源。[YY/T 0316- 2016.定义2.3]
3.10
制造商manufacturer以其名义制造顶期可用的医疗8械井负有医疗器械设计和/或制造责任的自然人或法人，无论此医.
3。 术语和定义
下列术语和定文适用于本文件。
3.1
活动activity :-组单个或多个相互关联或相互作用的任务。
3.2
反常anomaly与基于需求规范.设计文件和标准等的预期,成人的认知或经验相偏离的任何情况。反常司能但不限F在医疗器械软件成适用文档的评审.测试.分析.编译/编辑成使用过程中发现。
注:改写IEEE 144199，定又3.1.
3.3
体系结构arehitecture系统或组件的组织结构。[IEEE 610.12; 1990]
3.4
变更请求change request拟对医疗器械软件所做变更的形成文件的说明。
3.5
配置项conOguration item在给定参考点上能够唯一- 标识的实体。佳，改写1S0/IEC 127.20080定义4.7。
3.6
交付物deliverable对一项活动或任务所要求的结果或输出(包括文档)。
3.7
评价evaluation对一个实体满足其规定准则的程度的系统性确定。[ISO/IEC 12207;2008.定又4.12]
3.8
伤害harm对人体的损伤或对人体健康的损害,或对财产或环境的损害。[YY/T 0316-- 2016.定 义2.2]
3.9
危险(源) hazard可能导致伤害的潜在根源。[YY/T 0316- 2016.定义2.3]
3.10
制造商manufacturer以其名义制造顶期可用的医疗8械井负有医疗器械设计和/或制造责任的自然人或法人，无论此医.
标准图片预览
标准内容
ICS11.040.01;35.240.80
中华人民共和国医药行业标准
YY/T0664—2020
代替YY/T06642008
医疗器械软件
软件生存周期过程
Medicaldevice software-Software lifecycleprocesses（IEC623042015.MOD）
2020-09-27发布
湖涂服资真供
国家药品监督管理局
2021-09-01实施
?目的
应用范围
与其他标准的关系
符合性
规范性引用文件
术语和定义
总要求
质量管理体系
·风险管理·
·软件安全分级
遗留软件
软件开发过程
软件开发策划
软件需求分析
软件体系结构设计
软件详细设计
软件单元的实现
软件集成和集成测试
“软件系统测试
软件在系统级别应用的发布
软件维护过程
建立软件维护计划
问题和修改分析
修改的实施
软件风险管理过程
?促成危险情况的软件分析
风险控制措施
风险控制措施的验证
软件变更的风险管理
·软件配置管理过程
8.1配置标识
8.2变更控制
配置状态报告
YY/T0664—2020
YY/T0664—2020
软件问题解决过程
编写问题报告
调查问题
通知相关方
使用变更控制过程
保持记录
分析问题的趋势
验证软件问题的解决
测试文档的内容
附录A（资料性附录）
附录B（资料性附录）
附录C（资料性附录）
附录D（资料性附录）
参考文献
本标准要求的理由说明·
关于本标准条款的指南
与其他标准的关系
软件开发过程和活动图示
软件维护过程和活动图示
赋予软件安全级别
危险（源）、事件序列、危险情况和伤害关系的图示（源于YY/T0316—2016的附录E）29软件项划分示例
法规视角
现成软件与未知来源软件、遗留软件之间的关系重要医疗器械标准与本标准的关系软件作为V模型的一部分
YY/T0664与IEC61010-1联合应用按软件安全级别的要求汇总
ISO/IEC12207中规定的开发（模型）策略与YY/T0287—2017的关系
与YY/T0316—2016的关系
与IEC60601-1的关系
与ISO/IEC12207：2008的关系
用于未经质量管理体系认证的小型制造商的检查表30
本标准按照GB/T1.1—2009给出的规则起草。言
YY/T0664—2020
本标准代替YY/T0664—2008《医疗器械软件牛软件生存周期过程》，与YY/T0664—2008相比，除编辑性修改外主要技术变化如下：纳入国际标准IEC62304：2006/AMD1:2015的修正内容，这些修正内容涉及的章条已通过在其外侧页边空白位置的垂直双线（II）进行了标示。主要修订内容包括：?
删除了术语“软件产品”（2008年版的3.26），用医疗器械软件”（见3.11)代替“软件产品”增加了“危险情况”（见3.33）、“遗留软件”（见3.34）、“发布”（见3.35）、“剩余风险”（见3.36）、“风险估计”（见3.37）、“风险评价”（见3.38）的术语和定义；修改了“软件安全分级”的要求（见4.3，2008年版的4.3）；增加了“图3赋予软件安全级别”（见4.3）；增加了“遗留软件”的要求（见4.4）；增加了“识别和避免常见软件缺陷”的要求（见5.1.12）；修改了“验证软件集成”的要求（见5.6.2，2008年版的5.6.2）；修改了条款适用的软件安全级别（见5.7.1、5.7.2、5.7.3、5.8.1、5.8.2、5.8.7、5.8.8，2008年版的5.7.1、5.7.2、5.7.3、5.8.1、5.8.2、5.8.7、5.8.8)；修改了“评价软件系统测试”的要求（见5.7.4，2008年版的5.7.4）；修改了“软件系统测试记录的内容”（见5.7.5，2008年版的5.7.5）；删除了“将事件序列形成文档”的要求（2008年版的7.1.5）；删除了“将任何新事件序列形成文档”的要求（2008年版的7.3.2)；修改了“编写问题报告”的要求（见9.1，2008年版的9.1）；修改了“软件安全分级”的指南（见附录B.4.3，2008年版附录B.4.3）；增加了“遗留软件”的指南（见附录B.4.4）。修改了术语“异常”为“反常”（见3.2，2008年版的3.2）。修改了术语“危害”为“危险（源）”（见3.9，2008年版的3.9）。修改了术语“安全性”为“安全”（见3.20，2008年版的3.21），全文用“安全”代替“安全性”。修改了术语“严重伤害”为“严重损伤”（见3.22，2008年版的3.23）。由于翻译对部分内容进行的修改。本标准使用重新起草法修改采用IEC62304：2015《医疗器械软件软件生存周期过程》。本标准与IEC62304：2015相比较存在技术性差异，这些差异涉及的条款已通过在其外侧页边空白位置的垂直单线（I）进行了标示。主要技术性差异及原因如下：关于规范性引用文件，本标准做了具有技术性差异的调整，以适应我国的技术条件，调整的情况集中反映在第2章“规范性引用文件”中，具体调整如下：。用等同采用国际标准的YY/T0316代替ISO14971。针对删除了的术语、条款或列项中涉及“不使用”的内容，相应序号（包括表序号）顺延，以符合GB/T1.1的规定，确保技术内容的确定和文本结构的协调统一；修改了术语“制造商（见3.10）”的定义，以便与YY/T0287一2017标准保持一致；删除了术语“医疗器械”，因医疗器械法规和YY/T0287一2017中均对“医疗器械”有定义，本标准不再重复；
YY/T0664-—2020
修改了术语“过程（见3.13）\“验证（见3.31)”的定义，以便与GB/T19000-—2016保持一致；修改了术语“回归测试”（见3.14)的定义，以便与ISO/IEC/IEEE90003：2018保持一致；修改了术语“损害”（见2008年版的3.8）为“伤害”（见3.8），并修改了定义，以便与YY/T0316—2016保持-致；
修改了术语“保密安全”（见2008年版的3.22）为“信息安全”（见3.21），并修改了定义，以便与ISO/IEC/TEEE12207：2017保持一致；将“软件以外的风险控制措施”“软件系统以外的风险控制措施”“不在软件系统内（以外）实施的风险控制措施”“（软件系统）以外的风险控制措施”统一修改为“外部风险控制措施”（见4.3和图3），以便与法规保持一致；修改了8.2.2注/8.2.3注中“5.1.1e)”为\5.1.1d)”，基于标准上下文，纠正编辑性错误；增加了附录B.4.5法规视角，以便理解标准和法规要求；删除了图3中IEC标注，图中内容与IEC62304:2015存在技术性变化；修改了附录C中表C.1和表C.2，以便分别与YY/T0287-—2017和YY/T03162016保持致；
删除了附录C.4.7，因IEC60601-1-4已废止；删除了第3章中定义的术语索引，不使用。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由国家药品监督管理局提出、本标准由全国医疗器械质量管理和通用要求标准化技术委员会（SAC/TC221)归口。本标准起草单位：北京国医械华光认证有限公司、中国食品药品检定研究院、国家药品监督管理局医疗器械技术审评中心、北京怡和嘉业医疗科技股份有限公司、东软医疗系统股份有限公司、上海微创医疗器械（集团）有限公司、深圳迈瑞生物医疗电子股份有限公司、上海西门子医疗器械有限公司、康泰医学系统（秦皇岛）股份有限公司、北京推想科技有限公司。本标准主要起草人：刘荣敏、吕建英、郑佳、彭亮、陈兴文、王志强、李勇、殷骏、高云琼、李学勇、陈宽、李朝晖、王美英、许慧雯、陈蓓、严佳玲、杨智明、王少康、邵玉波、韦晓洁。本标准所代替标准的历次版本发布情况为：YY/T0664-2008。
YY/T0664—2020
软件通常是医疗器械技术的一个组成部分。建立包含软件的医疗器械的安全和有效性，要求有软件预期用途的知识，并要证实软件的使用在没有引起任何不可接受的风险的情况下实现预期目的。本标准为医疗器械软件的安全设计和维护提供了一个生存周期过程框架，包括必要的活动和任务。本标准为每个生存周期过程规定了要求。每个生存周期过程由一组活动组成，多数活动又由一组任务组成。
作为主要的基础，这里设定医疗器械软件是在质量管理体系（见4.1）和风险管理体系（见4.2）之内开发和维护的。风险管理过程已在YY/T0316中得到很好地阐述。因此本标准通过直接对YY/T0316的规范性引用，利用了该有利条件。对软件来说少量附加的风险管理要求是必要的，特别是在识别与危险（源）有关的软件影响因素方面。将这些要求加以汇总并纳入第七章作为软件风险管理过程。
在风险管理过程的危险（源）识别活动中确定软件是否为危险情况的促成因素。在确定软件是否是促成因素时，需要考虑可能由软件间接造成的危险情况（例如：通过提供可能导致给予不适当治疗的误导性信息）。在风险管理过程的风险控制活动中做出使用软件来控制风险的决定。本标准要求的软件风险管理过程必须包含在按照YY/T0316建立的医疗器械风险管理过程之中。软件开发过程由若干活动组成。这些活动如图1所示，并在第5章中描述。因为现场的许多事件与医疗器械系统的服务或维护有关，包括不适当的软件更新和升级，软件维护过程被视为与软件开发过程一样重要。软件维护过程和软件开发过程很相似，如图2所示和第6章的描述。顾客需求
软件开
发策划
软件需
求分析
软件体系
结构设计
本标准范围之外的活动
系统开发活动（包括风险管理）7软件风险管理
软件详
细设计
软件单元
的实现
8软件配置管理
9软件间题解决
软件集成和
集成测试
图1软件开发过程和活动图示
顾客需求
得到满足
软件系
统测试
软件发布
YY/T0664-—2020
维护要求
制定软件
维护计划
间题和修改
软件体系
结构设计
本标准范围之外的活动
系统维护活动（包括风险管理）7软件风险管理
软件详细
软件单元
的实现
6.3修改的实施
8软件配置管理
9软件问题解决
软件集成和
集成测试
软件维护过程和活动图示
请求得到
软件系统
软件发布
本标准为开发安全的医疗器械软件规定了两个必不可少的附加过程，即软件配置管理过程（见第8章）和软件问题解决过程（见第9章）。对于本标准发布前的软件设计，本标准增加了处理遗留软件的要求，以帮助制造商符合标准进而满足法规要求。软件安全级别的变更包括对要求的说明和对软件安全级别的更新，以纳人基于风险的方法。
本标准不为制造商规定组织结构，或组织的哪一部分完成哪个过程、活动或任务。本标准只要求完成过程、活动或任务以建立对本标准的符合性。本标准不指定要形成文档的名称、格式或明确的内容。本标准要求编制任务文档，但如何组合编排这些文档的决定留给标准的使用者本标准不指定特定的生存周期模型。本标准的使用者负责为软件项目选择生存周期模型，并将本标准中的过程、活动和任务映射在该模型上。附录A为本标准各章提供理由说明。附录B为本标准各条款提供指南。对于本标准：
。“应（shall)”意指为符合本标准，符合一项要求是强制性的。。“宜（should）\意指为符合本标准，符合一项要求是推荐性的但不是强制性的。。“可（may)\用于描述符合一项要求的一种允许的方式。·“建立（establish）”意指规定、形成文件并实施本标准中术语“适当时（asappropriate)”与要求的过程、活动、任务或输出一起使用时，意指制造商应使用该过程、活动、任务或输出，除非制造商能以文件形式说明不这样做的合理理由。本标准中带星号（）的条款表示在附录B中有关于该条款的指南。M
1范围
1.1目的
医疗器械软件
软件生存周期过程
YY/T0664—2020
本标准为医疗器械软件规定了生存周期要求。本标准中描述的一组过程、活动和任务，为医疗器械软件生存周期过程建立了共同的框架1.2
“应用范围
本标准适用于医疗器械软件的开发和维护。医疗器械软件包括本身是医家器械的软件或是最终医疗器械的嵌入部分或组成部分的软件。注1：本标准可用本身是医疗器械的软件的开发和维护，然而，在该类型软件能够投人使用之前，还需要在系统级上进行需加的严发活动。本标准不覆盖这些系统级活动，相关要求可参见IEC2304-了预期应用于软件的过程孩类软件可在处理器上执行或通过在处理器上运行的其他本标准描述
软件（例如解释器）执行。
无论使用可种等久存储设备存储软刻如：硬盘、光盘、承灰内有或闪存本标准均适用。无论使月何种交付方法交
付软件例如：通
理移送
EEPROM）等物
只读存储器
本标准
本标准
不覆盖医疗器械的确认和最终发注2：如果医疗器械包含拟在
的要求（见.1.2)。
执行的嵌
网络或
使该医
款件，则
子邮件传输或光盘
本身术
付方法
闪存或带电可擦除编程
视为医疗器械软件。
器械完全由软件组成。
腺准的要
软件，包括有关未知来源软件
鑫用手缘
注3：在软供和医疗器械能够摄人便用之前，需要费在系统级上进律确认和其他并发活动，本标准不盖这些系统级活动，参见相关产品标准如601E1.3与其他标准的关系
在开发医疗器械时，本医疗器械软件生存周期标准和其他适用的标准共同使用本标准与其他相
关标准之间的关系参见附录
1.4符合性
符合本标准意指按照软件安全级别实施在本标准中确定的所有过程、活动和任务。注1：为每项要求赋予的软件安全级别在正文中标注在该项要求之后。通过对本标准所要求的所有文档（包括风险管理文档）的检查和对软件安全级别所要求的过程、活动和任务的评定来确定符合性。注2：此种评定可通过内部或外部的审核来进行注3：尽管要完成特定的过程、活动和任务，但实施这些过程和执行这些活动和任务的方法具有灵活性。注4：若任何包含\适当时（asappropriate）\的要求未实施，为说明理由而形成的文档对于本评定是必要的。注5：本标准中用术语\符合性（compliance）”之处，在ISO/IEC12207中用术语\符合性（conformance）\。注6有关遗留软件的符合性，见4.4，2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文YY/T0664-—2020
件。凡是不注日期的引用文件，其最新版本（包括所有修改单）适用于本文件。风险管理对医疗器械的应用（YY/T0316—2016，ISO14971：2007更正YY/T0316医疗器械
版，IDT)
术语和定义
下列术语和定义适用于本文件
activity
组单个或多个相互关联或相互作用的任务。3.2
anomaly
与基于需求规范、设计文件和标准等的预期，或人的认知或经验相偏离的任何情况。反常可能但不限于在医疗器械软件或适用文档的评审、测试、分析、编译/编辑或使用过程中发现。注：改写IEEE1044:1993，定义3.13.3
体系结构
architecture
系统或组件的组织结构。
[IEEE610.12:1990]
变更请求
change request
拟对医疗器械软件所做变更的形成文件的说明。3.5
配置项
configuration item
在给定参考点上能够唯一标识的实体注：改写ISO/IEC12207：2008，定义4.73.6
交付物
deliverable
对一项活动或任务所要求的结果或输出（包括文档）。3.7
evaluation
对一个实体满足其规定准则的程度的系统性确定。［SO/IEC12207：2008，定义4.12]3.8
伤害harm
对人体的损伤或对人体健康的损害，或对财产或环境的损害。［YY/T0316—2016.定义2.2]
危险（源）
hazard
可能导致伤害的潜在根源
［YY/T0316—2016，定义2.3]
制造商
manufacturer
以其名义制造预期可用的医疗器械并负有医疗器械设计和/或制造责任的自然人或法人，无论此医2
YY/T0664-—2020
疗器械的设计和/或制造是由该自然人或法人进行或由另外的一个或多个自然人或法人代表其进行。注1：此“自然人或法人\对确保符合医疗器械预期可用或销售的国家或管辖区的所有适用的法规要求负有最终法律责任，除非该管辖区的监管机构（RA）明确将该责任强加于另一自然人或法人。注2：在其他GHTF指南文件中说明了制造商的责任。这些责任包括满足上市前要求和上市后要求，比如不良事件报告和纠正措施通知。
注3：上述定义中所指的“设计和/或制造”可包括医疗器械的规范制定、生产、制造、组装、加工、包装、重新包装、标记、重新标记、灭菌、安装或再制造：或为了医疗日的而将多个器械（可能包括其他产品）组合在一起。注4：假如组装或修改不改变医疗器械的预期用途，该医疗器械已经由另一自然人或法人按照使用说明书提供给个体患者，组装或修改医疗器械的任何自然人或法人不是制造商。注5：不是以原制造商的名义更改医疗器械的预期用途或改进医疗器械的任何自然人或法人·使器械以其名义提供使用，宜认为是改进后的医疗器械的制造商注6：不覆盖或改变现有标记，只将自已的地址和联系方式加在医疗器械上或包装上的授权代表、经销商或进口商，不被认为是制造商。
注7：纳人医疗器械法规要求的附件，负责设计和/或制造该附件的自然人或法人被认为是制造商。［YY/T0287—2017，定义3.10]
医疗器械软件
medical devicesoftware
旨在集成到正在开发的医疗器械中的已开发的软件系统，或者预期作为医疗器械使用的软件系统3.12
问题报告
problem report
使用者或其他利益相关人员认为对预期使用不安全、不适当或违反规范的医疗器械软件实际或潜在特性的记录。
注1：本标准不要求每个问题报告都引起对医疗器械软件的变更。制造商可拒绝误导性的、误判的或无关紧要事件的问题报告。
注2：间题报告可能与已发布的医疗器械软件或仍在开发中的医疗器械软件有关。注3：本标准要求制造商对涉及已发布产品的间题报告实施额外的决策步骤（见第6章），以确保监管措施的识别和实施。
process
利用输入实现预期结果的相互关联或相互作用的一组活动。注1：过程的“预期结果\称为输出，还是称为产品或服务，随相关语境而定。注2：一个过程的输人通常是其他过程的输出：而一个过程的输出又通常是其他过程的输人。注3：两个或两个以上相互关联和相互作用的连续过程也可作为一个过程。注4：组织通常对过程进行策划，并使其在受控条件下运行，以增加价值。注5：不易或不能经济地确认其输出是否合格的过程，通常称之为“特殊过程”注6：这是ISO/IEC导则第1部分ISO补充规定的附件SL中给出的ISO管理体系标准中通用术语及核心定义之，最初的定义已经被改写，以避免过程和输出之间循环解释，并增加注1～注5。［GB/T19000—2016，定义3.4.1]3.14
tregressiontesting
回归测试
在对测试项或其运行环境修改后进行的测试，以确定是否出现回归失效注：回归测试用例集的充分性取决于所测试的测试项，以及对该测试项或其运行环境的修改。[ISO/IEC/IEEE90003：2018，定义3.6］3.15
风险risk
伤害发生的概率和该伤害严重度的组合。3
YY/T0664—2020
[YY/T0316—2016，定义2.16]
风险分析riskanalysis
系统地运用现有信息确定危险（源）和估计风险的过程［YY/T0316—2016，定义2.17]
riskcontrol
风险控制
作出决策并实施措施，以便降低风险或把风险维持在规定水平的过程。［YY/T0316—2016.定义2.19]
风险管理
risk management
用于风险分析、评价、控制工作的管理方针程序及其实践的系统运用。注：改写YY/T0316
风险管理文档
由风险管理
［YY/T031
安全saety
2016，定义22.删除了“和监视”riskmanagementfile
组记录和其他文件
2016，定
免除了不可接受的风险的
YY/T316
2016，定
信息安全
security
防止蓄意破坏或强制失效保密性完整性，所有这些属#均有保证性的同题注：改写1SO/C/IE#E1220
严重损伤
serious injur
导致下列结果的损伤或疾病
危及生命：
得性和可核否性四个属性的组合，吸第五个属性可用造成人体功能的永久性损击或人体结构的水久性损坏需要内科或外科介人以防止人体功能的永久性损售或人体结构的永久性损坏。注：永久性损害意味着人体结构或功能不可逆的损害或损坏，微不足道的损害或损坏除外。3.23
softwaredevelopment life cyclemodel软件开发生存周期模型
贯穿从需求定义到发布的软件生存周期的概念结构，其：识别医疗器械软件开发中包含的过程、活动和任务；描述活动和任务之间的顺序和依赖关系；识别特定交付物完整性验证时机的里程碑。注：改写ISO/IEC12207：1995，定义3.11。3.24
软件项
softwareitem
计算机程序中任何可识别的部分，例如：源代码、目标代码、控制代码、控制数据或这些项的集合。4
YY/T0664—2020
注1：三个术语描述软件分解。顶层是软件系统：最底层不能进一步分解的是软件单元。该结构的所有层级，包括顶层和底层，都可以称为软件项，软件系统则由一个或多个软件项组成，而每个软件项由一个或多个软件单元或可分解的软件项组成。提供软件项和软件单元的粒度是制造商的责任。注2：改写GB/T19003—2008，定义3.14和ISO/1EC12207：2008，定义4.41。3.25
softwaresystem
软件系统
有组织的、经集成的软件项组合，以完成某个特定功能或一组功能。3.26
软件单元softwareunit
不可再分的软件项。
注：软件单元的粒度由制造商定义（公见5,3)。3.27
牛softwareofunknownprovenance;SOUP未知来源软件
已经开发且通常得到件且不是为包含到医疗器械内而开发的软件项（也称为“成品软件”）或以前开发的、不能得到其开发过程足够记录的软件项。注：医疗器械软件系统本身不能声称是未知来源软件，3.28
system
由一个或多个过程、硬件
软性，设施和天员组成的集合体提供满足规定带求或目标的能力。注：改写ISO/EC12207：204此内容来自标准下载网
需要完成的单项工作。
可追溯性
tryceability
开发过程的两或多个
［IEEE6102:1980]
交付物间能够建立关联巧程度
注：开发过程交达物的示例包括：需求、体系结构、风险控制措施等。3.31
验证verification
通过提供客观证据对规要求已得到满已的认注1：验证所需的客观证据可以是检验结果或其他形式的确定结果，妞夏换方法进行计算或文件评审。注2：为验证所进行的活动有时被称为鉴定过栓注3：“已验证”一词用于表明相应的状态。[GB/T19000—2016.定义3.8.12
注4：在设计和开发中，验证涉及检查给定活动的结果的过程以确定该项活动与规定要求的符合性。3.32
版本version
一个配置项已标识的实例
注1：对医疗器械软件的某版本进行修改会产生一个新版本，需要对修改实施配置管理措施。注2：改写ISO/IEC12207：2008，定义4563.33
危险情况hazardous situation
人员、财产或环境暴露于一个或多个危险(源)中的情形。5
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国医药行业标准
YY/T0664—2020
代替YY/T06642008
医疗器械软件
软件生存周期过程
Medicaldevice software-Software lifecycleprocesses（IEC623042015.MOD）
2020-09-27发布
湖涂服资真供
国家药品监督管理局
2021-09-01实施
?目的
应用范围
与其他标准的关系
符合性
规范性引用文件
术语和定义
总要求
质量管理体系
·风险管理·
·软件安全分级
遗留软件
软件开发过程
软件开发策划
软件需求分析
软件体系结构设计
软件详细设计
软件单元的实现
软件集成和集成测试
“软件系统测试
软件在系统级别应用的发布
软件维护过程
建立软件维护计划
问题和修改分析
修改的实施
软件风险管理过程
?促成危险情况的软件分析
风险控制措施
风险控制措施的验证
软件变更的风险管理
·软件配置管理过程
8.1配置标识
8.2变更控制
配置状态报告
YY/T0664—2020
YY/T0664—2020
软件问题解决过程
编写问题报告
调查问题
通知相关方
使用变更控制过程
保持记录
分析问题的趋势
验证软件问题的解决
测试文档的内容
附录A（资料性附录）
附录B（资料性附录）
附录C（资料性附录）
附录D（资料性附录）
参考文献
本标准要求的理由说明·
关于本标准条款的指南
与其他标准的关系
软件开发过程和活动图示
软件维护过程和活动图示
赋予软件安全级别
危险（源）、事件序列、危险情况和伤害关系的图示（源于YY/T0316—2016的附录E）29软件项划分示例
法规视角
现成软件与未知来源软件、遗留软件之间的关系重要医疗器械标准与本标准的关系软件作为V模型的一部分
YY/T0664与IEC61010-1联合应用按软件安全级别的要求汇总
ISO/IEC12207中规定的开发（模型）策略与YY/T0287—2017的关系
与YY/T0316—2016的关系
与IEC60601-1的关系
与ISO/IEC12207：2008的关系
用于未经质量管理体系认证的小型制造商的检查表30
本标准按照GB/T1.1—2009给出的规则起草。言
YY/T0664—2020
本标准代替YY/T0664—2008《医疗器械软件牛软件生存周期过程》，与YY/T0664—2008相比，除编辑性修改外主要技术变化如下：纳入国际标准IEC62304：2006/AMD1:2015的修正内容，这些修正内容涉及的章条已通过在其外侧页边空白位置的垂直双线（II）进行了标示。主要修订内容包括：?
删除了术语“软件产品”（2008年版的3.26），用医疗器械软件”（见3.11)代替“软件产品”增加了“危险情况”（见3.33）、“遗留软件”（见3.34）、“发布”（见3.35）、“剩余风险”（见3.36）、“风险估计”（见3.37）、“风险评价”（见3.38）的术语和定义；修改了“软件安全分级”的要求（见4.3，2008年版的4.3）；增加了“图3赋予软件安全级别”（见4.3）；增加了“遗留软件”的要求（见4.4）；增加了“识别和避免常见软件缺陷”的要求（见5.1.12）；修改了“验证软件集成”的要求（见5.6.2，2008年版的5.6.2）；修改了条款适用的软件安全级别（见5.7.1、5.7.2、5.7.3、5.8.1、5.8.2、5.8.7、5.8.8，2008年版的5.7.1、5.7.2、5.7.3、5.8.1、5.8.2、5.8.7、5.8.8)；修改了“评价软件系统测试”的要求（见5.7.4，2008年版的5.7.4）；修改了“软件系统测试记录的内容”（见5.7.5，2008年版的5.7.5）；删除了“将事件序列形成文档”的要求（2008年版的7.1.5）；删除了“将任何新事件序列形成文档”的要求（2008年版的7.3.2)；修改了“编写问题报告”的要求（见9.1，2008年版的9.1）；修改了“软件安全分级”的指南（见附录B.4.3，2008年版附录B.4.3）；增加了“遗留软件”的指南（见附录B.4.4）。修改了术语“异常”为“反常”（见3.2，2008年版的3.2）。修改了术语“危害”为“危险（源）”（见3.9，2008年版的3.9）。修改了术语“安全性”为“安全”（见3.20，2008年版的3.21），全文用“安全”代替“安全性”。修改了术语“严重伤害”为“严重损伤”（见3.22，2008年版的3.23）。由于翻译对部分内容进行的修改。本标准使用重新起草法修改采用IEC62304：2015《医疗器械软件软件生存周期过程》。本标准与IEC62304：2015相比较存在技术性差异，这些差异涉及的条款已通过在其外侧页边空白位置的垂直单线（I）进行了标示。主要技术性差异及原因如下：关于规范性引用文件，本标准做了具有技术性差异的调整，以适应我国的技术条件，调整的情况集中反映在第2章“规范性引用文件”中，具体调整如下：。用等同采用国际标准的YY/T0316代替ISO14971。针对删除了的术语、条款或列项中涉及“不使用”的内容，相应序号（包括表序号）顺延，以符合GB/T1.1的规定，确保技术内容的确定和文本结构的协调统一；修改了术语“制造商（见3.10）”的定义，以便与YY/T0287一2017标准保持一致；删除了术语“医疗器械”，因医疗器械法规和YY/T0287一2017中均对“医疗器械”有定义，本标准不再重复；
YY/T0664-—2020
修改了术语“过程（见3.13）\“验证（见3.31)”的定义，以便与GB/T19000-—2016保持一致；修改了术语“回归测试”（见3.14)的定义，以便与ISO/IEC/IEEE90003：2018保持一致；修改了术语“损害”（见2008年版的3.8）为“伤害”（见3.8），并修改了定义，以便与YY/T0316—2016保持-致；
修改了术语“保密安全”（见2008年版的3.22）为“信息安全”（见3.21），并修改了定义，以便与ISO/IEC/TEEE12207：2017保持一致；将“软件以外的风险控制措施”“软件系统以外的风险控制措施”“不在软件系统内（以外）实施的风险控制措施”“（软件系统）以外的风险控制措施”统一修改为“外部风险控制措施”（见4.3和图3），以便与法规保持一致；修改了8.2.2注/8.2.3注中“5.1.1e)”为\5.1.1d)”，基于标准上下文，纠正编辑性错误；增加了附录B.4.5法规视角，以便理解标准和法规要求；删除了图3中IEC标注，图中内容与IEC62304:2015存在技术性变化；修改了附录C中表C.1和表C.2，以便分别与YY/T0287-—2017和YY/T03162016保持致；
删除了附录C.4.7，因IEC60601-1-4已废止；删除了第3章中定义的术语索引，不使用。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由国家药品监督管理局提出、本标准由全国医疗器械质量管理和通用要求标准化技术委员会（SAC/TC221)归口。本标准起草单位：北京国医械华光认证有限公司、中国食品药品检定研究院、国家药品监督管理局医疗器械技术审评中心、北京怡和嘉业医疗科技股份有限公司、东软医疗系统股份有限公司、上海微创医疗器械（集团）有限公司、深圳迈瑞生物医疗电子股份有限公司、上海西门子医疗器械有限公司、康泰医学系统（秦皇岛）股份有限公司、北京推想科技有限公司。本标准主要起草人：刘荣敏、吕建英、郑佳、彭亮、陈兴文、王志强、李勇、殷骏、高云琼、李学勇、陈宽、李朝晖、王美英、许慧雯、陈蓓、严佳玲、杨智明、王少康、邵玉波、韦晓洁。本标准所代替标准的历次版本发布情况为：YY/T0664-2008。
YY/T0664—2020
软件通常是医疗器械技术的一个组成部分。建立包含软件的医疗器械的安全和有效性，要求有软件预期用途的知识，并要证实软件的使用在没有引起任何不可接受的风险的情况下实现预期目的。本标准为医疗器械软件的安全设计和维护提供了一个生存周期过程框架，包括必要的活动和任务。本标准为每个生存周期过程规定了要求。每个生存周期过程由一组活动组成，多数活动又由一组任务组成。
作为主要的基础，这里设定医疗器械软件是在质量管理体系（见4.1）和风险管理体系（见4.2）之内开发和维护的。风险管理过程已在YY/T0316中得到很好地阐述。因此本标准通过直接对YY/T0316的规范性引用，利用了该有利条件。对软件来说少量附加的风险管理要求是必要的，特别是在识别与危险（源）有关的软件影响因素方面。将这些要求加以汇总并纳入第七章作为软件风险管理过程。
在风险管理过程的危险（源）识别活动中确定软件是否为危险情况的促成因素。在确定软件是否是促成因素时，需要考虑可能由软件间接造成的危险情况（例如：通过提供可能导致给予不适当治疗的误导性信息）。在风险管理过程的风险控制活动中做出使用软件来控制风险的决定。本标准要求的软件风险管理过程必须包含在按照YY/T0316建立的医疗器械风险管理过程之中。软件开发过程由若干活动组成。这些活动如图1所示，并在第5章中描述。因为现场的许多事件与医疗器械系统的服务或维护有关，包括不适当的软件更新和升级，软件维护过程被视为与软件开发过程一样重要。软件维护过程和软件开发过程很相似，如图2所示和第6章的描述。顾客需求
软件开
发策划
软件需
求分析
软件体系
结构设计
本标准范围之外的活动
系统开发活动（包括风险管理）7软件风险管理
软件详
细设计
软件单元
的实现
8软件配置管理
9软件间题解决
软件集成和
集成测试
图1软件开发过程和活动图示
顾客需求
得到满足
软件系
统测试
软件发布
YY/T0664-—2020
维护要求
制定软件
维护计划
间题和修改
软件体系
结构设计
本标准范围之外的活动
系统维护活动（包括风险管理）7软件风险管理
软件详细
软件单元
的实现
6.3修改的实施
8软件配置管理
9软件问题解决
软件集成和
集成测试
软件维护过程和活动图示
请求得到
软件系统
软件发布
本标准为开发安全的医疗器械软件规定了两个必不可少的附加过程，即软件配置管理过程（见第8章）和软件问题解决过程（见第9章）。对于本标准发布前的软件设计，本标准增加了处理遗留软件的要求，以帮助制造商符合标准进而满足法规要求。软件安全级别的变更包括对要求的说明和对软件安全级别的更新，以纳人基于风险的方法。
本标准不为制造商规定组织结构，或组织的哪一部分完成哪个过程、活动或任务。本标准只要求完成过程、活动或任务以建立对本标准的符合性。本标准不指定要形成文档的名称、格式或明确的内容。本标准要求编制任务文档，但如何组合编排这些文档的决定留给标准的使用者本标准不指定特定的生存周期模型。本标准的使用者负责为软件项目选择生存周期模型，并将本标准中的过程、活动和任务映射在该模型上。附录A为本标准各章提供理由说明。附录B为本标准各条款提供指南。对于本标准：
。“应（shall)”意指为符合本标准，符合一项要求是强制性的。。“宜（should）\意指为符合本标准，符合一项要求是推荐性的但不是强制性的。。“可（may)\用于描述符合一项要求的一种允许的方式。·“建立（establish）”意指规定、形成文件并实施本标准中术语“适当时（asappropriate)”与要求的过程、活动、任务或输出一起使用时，意指制造商应使用该过程、活动、任务或输出，除非制造商能以文件形式说明不这样做的合理理由。本标准中带星号（）的条款表示在附录B中有关于该条款的指南。M
1范围
1.1目的
医疗器械软件
软件生存周期过程
YY/T0664—2020
本标准为医疗器械软件规定了生存周期要求。本标准中描述的一组过程、活动和任务，为医疗器械软件生存周期过程建立了共同的框架1.2
“应用范围
本标准适用于医疗器械软件的开发和维护。医疗器械软件包括本身是医家器械的软件或是最终医疗器械的嵌入部分或组成部分的软件。注1：本标准可用本身是医疗器械的软件的开发和维护，然而，在该类型软件能够投人使用之前，还需要在系统级上进行需加的严发活动。本标准不覆盖这些系统级活动，相关要求可参见IEC2304-了预期应用于软件的过程孩类软件可在处理器上执行或通过在处理器上运行的其他本标准描述
软件（例如解释器）执行。
无论使用可种等久存储设备存储软刻如：硬盘、光盘、承灰内有或闪存本标准均适用。无论使月何种交付方法交
付软件例如：通
理移送
EEPROM）等物
只读存储器
本标准
本标准
不覆盖医疗器械的确认和最终发注2：如果医疗器械包含拟在
的要求（见.1.2)。
执行的嵌
网络或
使该医
款件，则
子邮件传输或光盘
本身术
付方法
闪存或带电可擦除编程
视为医疗器械软件。
器械完全由软件组成。
腺准的要
软件，包括有关未知来源软件
鑫用手缘
注3：在软供和医疗器械能够摄人便用之前，需要费在系统级上进律确认和其他并发活动，本标准不盖这些系统级活动，参见相关产品标准如601E1.3与其他标准的关系
在开发医疗器械时，本医疗器械软件生存周期标准和其他适用的标准共同使用本标准与其他相
关标准之间的关系参见附录
1.4符合性
符合本标准意指按照软件安全级别实施在本标准中确定的所有过程、活动和任务。注1：为每项要求赋予的软件安全级别在正文中标注在该项要求之后。通过对本标准所要求的所有文档（包括风险管理文档）的检查和对软件安全级别所要求的过程、活动和任务的评定来确定符合性。注2：此种评定可通过内部或外部的审核来进行注3：尽管要完成特定的过程、活动和任务，但实施这些过程和执行这些活动和任务的方法具有灵活性。注4：若任何包含\适当时（asappropriate）\的要求未实施，为说明理由而形成的文档对于本评定是必要的。注5：本标准中用术语\符合性（compliance）”之处，在ISO/IEC12207中用术语\符合性（conformance）\。注6有关遗留软件的符合性，见4.4，2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文YY/T0664-—2020
件。凡是不注日期的引用文件，其最新版本（包括所有修改单）适用于本文件。风险管理对医疗器械的应用（YY/T0316—2016，ISO14971：2007更正YY/T0316医疗器械
版，IDT)
术语和定义
下列术语和定义适用于本文件
activity
组单个或多个相互关联或相互作用的任务。3.2
anomaly
与基于需求规范、设计文件和标准等的预期，或人的认知或经验相偏离的任何情况。反常可能但不限于在医疗器械软件或适用文档的评审、测试、分析、编译/编辑或使用过程中发现。注：改写IEEE1044:1993，定义3.13.3
体系结构
architecture
系统或组件的组织结构。
[IEEE610.12:1990]
变更请求
change request
拟对医疗器械软件所做变更的形成文件的说明。3.5
配置项
configuration item
在给定参考点上能够唯一标识的实体注：改写ISO/IEC12207：2008，定义4.73.6
交付物
deliverable
对一项活动或任务所要求的结果或输出（包括文档）。3.7
evaluation
对一个实体满足其规定准则的程度的系统性确定。［SO/IEC12207：2008，定义4.12]3.8
伤害harm
对人体的损伤或对人体健康的损害，或对财产或环境的损害。［YY/T0316—2016.定义2.2]
危险（源）
hazard
可能导致伤害的潜在根源
［YY/T0316—2016，定义2.3]
制造商
manufacturer
以其名义制造预期可用的医疗器械并负有医疗器械设计和/或制造责任的自然人或法人，无论此医2
YY/T0664-—2020
疗器械的设计和/或制造是由该自然人或法人进行或由另外的一个或多个自然人或法人代表其进行。注1：此“自然人或法人\对确保符合医疗器械预期可用或销售的国家或管辖区的所有适用的法规要求负有最终法律责任，除非该管辖区的监管机构（RA）明确将该责任强加于另一自然人或法人。注2：在其他GHTF指南文件中说明了制造商的责任。这些责任包括满足上市前要求和上市后要求，比如不良事件报告和纠正措施通知。
注3：上述定义中所指的“设计和/或制造”可包括医疗器械的规范制定、生产、制造、组装、加工、包装、重新包装、标记、重新标记、灭菌、安装或再制造：或为了医疗日的而将多个器械（可能包括其他产品）组合在一起。注4：假如组装或修改不改变医疗器械的预期用途，该医疗器械已经由另一自然人或法人按照使用说明书提供给个体患者，组装或修改医疗器械的任何自然人或法人不是制造商。注5：不是以原制造商的名义更改医疗器械的预期用途或改进医疗器械的任何自然人或法人·使器械以其名义提供使用，宜认为是改进后的医疗器械的制造商注6：不覆盖或改变现有标记，只将自已的地址和联系方式加在医疗器械上或包装上的授权代表、经销商或进口商，不被认为是制造商。
注7：纳人医疗器械法规要求的附件，负责设计和/或制造该附件的自然人或法人被认为是制造商。［YY/T0287—2017，定义3.10]
医疗器械软件
medical devicesoftware
旨在集成到正在开发的医疗器械中的已开发的软件系统，或者预期作为医疗器械使用的软件系统3.12
问题报告
problem report
使用者或其他利益相关人员认为对预期使用不安全、不适当或违反规范的医疗器械软件实际或潜在特性的记录。
注1：本标准不要求每个问题报告都引起对医疗器械软件的变更。制造商可拒绝误导性的、误判的或无关紧要事件的问题报告。
注2：间题报告可能与已发布的医疗器械软件或仍在开发中的医疗器械软件有关。注3：本标准要求制造商对涉及已发布产品的间题报告实施额外的决策步骤（见第6章），以确保监管措施的识别和实施。
process
利用输入实现预期结果的相互关联或相互作用的一组活动。注1：过程的“预期结果\称为输出，还是称为产品或服务，随相关语境而定。注2：一个过程的输人通常是其他过程的输出：而一个过程的输出又通常是其他过程的输人。注3：两个或两个以上相互关联和相互作用的连续过程也可作为一个过程。注4：组织通常对过程进行策划，并使其在受控条件下运行，以增加价值。注5：不易或不能经济地确认其输出是否合格的过程，通常称之为“特殊过程”注6：这是ISO/IEC导则第1部分ISO补充规定的附件SL中给出的ISO管理体系标准中通用术语及核心定义之，最初的定义已经被改写，以避免过程和输出之间循环解释，并增加注1～注5。［GB/T19000—2016，定义3.4.1]3.14
tregressiontesting
回归测试
在对测试项或其运行环境修改后进行的测试，以确定是否出现回归失效注：回归测试用例集的充分性取决于所测试的测试项，以及对该测试项或其运行环境的修改。[ISO/IEC/IEEE90003：2018，定义3.6］3.15
风险risk
伤害发生的概率和该伤害严重度的组合。3
YY/T0664—2020
[YY/T0316—2016，定义2.16]
风险分析riskanalysis
系统地运用现有信息确定危险（源）和估计风险的过程［YY/T0316—2016，定义2.17]
riskcontrol
风险控制
作出决策并实施措施，以便降低风险或把风险维持在规定水平的过程。［YY/T0316—2016.定义2.19]
风险管理
risk management
用于风险分析、评价、控制工作的管理方针程序及其实践的系统运用。注：改写YY/T0316
风险管理文档
由风险管理
［YY/T031
安全saety
2016，定义22.删除了“和监视”riskmanagementfile
组记录和其他文件
2016，定
免除了不可接受的风险的
YY/T316
2016，定
信息安全
security
防止蓄意破坏或强制失效保密性完整性，所有这些属#均有保证性的同题注：改写1SO/C/IE#E1220
严重损伤
serious injur
导致下列结果的损伤或疾病
危及生命：
得性和可核否性四个属性的组合，吸第五个属性可用造成人体功能的永久性损击或人体结构的水久性损坏需要内科或外科介人以防止人体功能的永久性损售或人体结构的永久性损坏。注：永久性损害意味着人体结构或功能不可逆的损害或损坏，微不足道的损害或损坏除外。3.23
softwaredevelopment life cyclemodel软件开发生存周期模型
贯穿从需求定义到发布的软件生存周期的概念结构，其：识别医疗器械软件开发中包含的过程、活动和任务；描述活动和任务之间的顺序和依赖关系；识别特定交付物完整性验证时机的里程碑。注：改写ISO/IEC12207：1995，定义3.11。3.24
软件项
softwareitem
计算机程序中任何可识别的部分，例如：源代码、目标代码、控制代码、控制数据或这些项的集合。4
YY/T0664—2020
注1：三个术语描述软件分解。顶层是软件系统：最底层不能进一步分解的是软件单元。该结构的所有层级，包括顶层和底层，都可以称为软件项，软件系统则由一个或多个软件项组成，而每个软件项由一个或多个软件单元或可分解的软件项组成。提供软件项和软件单元的粒度是制造商的责任。注2：改写GB/T19003—2008，定义3.14和ISO/1EC12207：2008，定义4.41。3.25
softwaresystem
软件系统
有组织的、经集成的软件项组合，以完成某个特定功能或一组功能。3.26
软件单元softwareunit
不可再分的软件项。
注：软件单元的粒度由制造商定义（公见5,3)。3.27
牛softwareofunknownprovenance;SOUP未知来源软件
已经开发且通常得到件且不是为包含到医疗器械内而开发的软件项（也称为“成品软件”）或以前开发的、不能得到其开发过程足够记录的软件项。注：医疗器械软件系统本身不能声称是未知来源软件，3.28
system
由一个或多个过程、硬件
软性，设施和天员组成的集合体提供满足规定带求或目标的能力。注：改写ISO/EC12207：204此内容来自标准下载网
需要完成的单项工作。
可追溯性
tryceability
开发过程的两或多个
［IEEE6102:1980]
交付物间能够建立关联巧程度
注：开发过程交达物的示例包括：需求、体系结构、风险控制措施等。3.31
验证verification
通过提供客观证据对规要求已得到满已的认注1：验证所需的客观证据可以是检验结果或其他形式的确定结果，妞夏换方法进行计算或文件评审。注2：为验证所进行的活动有时被称为鉴定过栓注3：“已验证”一词用于表明相应的状态。[GB/T19000—2016.定义3.8.12
注4：在设计和开发中，验证涉及检查给定活动的结果的过程以确定该项活动与规定要求的符合性。3.32
版本version
一个配置项已标识的实例
注1：对医疗器械软件的某版本进行修改会产生一个新版本，需要对修改实施配置管理措施。注2：改写ISO/IEC12207：2008，定义4563.33
危险情况hazardous situation
人员、财产或环境暴露于一个或多个危险(源)中的情形。5
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。