YY/T 0664-2008
基本信息
标准号： YY/T 0664-2008
中文名称：IEC 62034 : 2006 医疗器械软件软件生存周期过程
标准类别：医药行业标准(YY)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：7145812
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YY/T 0664-2008/IEC 62034 : 2006.Medical device software-Software life cycle processes.
1.1 目的
YY/T 0664规定了医疗器械软件的生存周期要求。在本标准中描述的一-组过程 、活动和任务,为医疗器械软件生存周期过程建立了共同的框架。
1.2 "应用范围.
YY/T 0664适用于医疗器械软件的开发和维护。
当软件本身是医疗器械,或当软件是最终医疗器械的嵌人部分或组成部分时,本标准适用于该医疗器械软件的开发和维护。
YY/T 0664不覆盖医疗器械的确认和最终发行，即使当该医疗器械完全由软件组成时。
1.3与其他标准的关系
在开发医疗器械时，本医疗器械软件生存周期标准和其他适用的标准共同使用。本标准和其他相关标准之间的关系见附录C示bzfxw.com
1.4 符合性
符合本标准意指按照软件安全性级别,实施在本标准中确定的所有过程、活动和任务。
注:对每项要求所赋予的软件安全性级别在标准要求之后的正文中确定。
用检查本标准所要求的所有文档(包括风险管理文档和对软件安全性级别所要求的过程、活动和任务的评定)的方法来确定符合性。见附录D.
注1:此种评定可以由内部的或外部的审核来实现。
注2:即使规定了要完成的过程、活动和任务.实施这些过程和执行这些活动和任务的方法是灵活的.
注3:在任何包含“适当时(as apoprate)"的要求没有完成时.为说明理由而形成文档对于本评定是必要的。
注4:本标准中用术语“符合(compliance )”的地方,GB/T 8566中用术语“符合(conformance)".
2。规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。
YY/T0316医疗器械风险 管理对医疗器械的应用(YY/T 0316- 2008 ,1SO 14971:200 ,IDT)
3 "术语和定义
下列术语和定义适用于本标准。
3.1
活动activity
-组中单个或多个相互关联或相互作用的任务。
3.2
异常anomaly
1.1 目的
YY/T 0664规定了医疗器械软件的生存周期要求。在本标准中描述的一-组过程 、活动和任务,为医疗器械软件生存周期过程建立了共同的框架。
1.2 "应用范围.
YY/T 0664适用于医疗器械软件的开发和维护。
当软件本身是医疗器械,或当软件是最终医疗器械的嵌人部分或组成部分时,本标准适用于该医疗器械软件的开发和维护。
YY/T 0664不覆盖医疗器械的确认和最终发行，即使当该医疗器械完全由软件组成时。
1.3与其他标准的关系
在开发医疗器械时，本医疗器械软件生存周期标准和其他适用的标准共同使用。本标准和其他相关标准之间的关系见附录C示bzfxw.com
1.4 符合性
符合本标准意指按照软件安全性级别,实施在本标准中确定的所有过程、活动和任务。
注:对每项要求所赋予的软件安全性级别在标准要求之后的正文中确定。
用检查本标准所要求的所有文档(包括风险管理文档和对软件安全性级别所要求的过程、活动和任务的评定)的方法来确定符合性。见附录D.
注1:此种评定可以由内部的或外部的审核来实现。
注2:即使规定了要完成的过程、活动和任务.实施这些过程和执行这些活动和任务的方法是灵活的.
注3:在任何包含“适当时(as apoprate)"的要求没有完成时.为说明理由而形成文档对于本评定是必要的。
注4:本标准中用术语“符合(compliance )”的地方,GB/T 8566中用术语“符合(conformance)".
2。规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。
YY/T0316医疗器械风险 管理对医疗器械的应用(YY/T 0316- 2008 ,1SO 14971:200 ,IDT)
3 "术语和定义
下列术语和定义适用于本标准。
3.1
活动activity
-组中单个或多个相互关联或相互作用的任务。
3.2
异常anomaly
标准图片预览
标准内容
ICS11.040
中华人民共和国医药行业标准
YY/T0664—2008/IEC62034:2006医疗器械软件
软件生存周期过程
Medical devicesoftware-Software life cycle processes(IEC62034:2006.IDT)
2008-04-25发布
数码防伪
国家食品药品监督管理局
2009-06-01实施
“目的
·应用范围
与其他标准的关系
符合性
*规范性引用文件
*术语和定义
总要求
质量管理体系
·风险管理
·软件的安全性级别
软件开发过程
·软件开发策划
·软件需求分析
·软件体系结构设计
“软件详细设计
*软件单元的实现和验证bZxz.net
·软件集成和集成测试
软件系统测试
“软件发行
软件维护过程
·制定软件维护计划
问题和修改分析
“修改的实施
软件风险管理过程
促成危害处境的软件分析
风险控制措施·
风险控制措施的验证·
软件更改的风险管理
*软件配置管理过程
·配置标识
·更改控制
配置状态记录
软件问题解决过程
准备问题报告
研究间题
KANIKAca-
YY/T0664-—2008/IEC62034:20064
YY/T0664—2008/IEC62034:20069.3
通知相关方·
应用更改控制过程·
保持记录
9.6分析问题的趋势，
验证软件间题的解决
9.8测试文档内容
附录A（资料性附录）
附录B（资料性附录）
附录C（资料性附录）
附录D（资料性附录）
参考文献
本标准要求的理由说明
对本标准规定的指南
与其他标准的关系
实施·
图1软件开发过程和活动概示
图2软件维护过程和活动概示
软件项划分示例
关键性医疗器械标准和本标准的关系图C2
软件作为V模型的一部分
本标准同GB4793的应用
软件安全性级别要求摘要
GB/T8566中规定的开发（模型）策略与YY/T0287—2003的关系·
与YY/T03162008的关系
与IEC60601-1的关系
与IEC60601-1-4的关系
与GB/T8566的关系
未经质量管理体系认证的小型制造商的检查表18
YY/T0664-2008/IEC62034.2006
本标准等同采用IEC62304：2006《医疗器械软件软件生存周期过程》（英文版）。IEC62304:2006医疗器械软件软件生存周期过程》给出了在第3章中定义的术语索引，本标准将该索引删除。
本标准中带星号（*）的条款表示在附录B中有关于该条款的指南。IEC623042006《医疗器械软件软件生存周期过程》（英文版）中的术语和附录C部分引用ISO14971：2000条款，由于ISO14971：2007版已经发布，本标准中引用YY/T0316—2008/ISO14971：2007的相应部分。
本标准的附录A、附录B、附录C和附录D均为资料性附录。本标准由国家食品药品监督管理局医疗器械司提出。本标准由医疗器械质量管理和通用要求标准化技术委员会（SAC/TC221)归口。本标准起草单位：医疗器械质量管理和通用要求标准化技术委员会，北京国医械华光认证有限公司。
本标准主要起草人：秦树华、陈志刚、米兰英、武俊华、李慧民。KANIKAca-
YY/T0664—2008/IEC62034:2006引
软件往往是医疗器械技术的一个组成部分。建立包括软件的医疗器械的安全性和有效性，要求有软件预期用途的知识，并要证实软件的使用在没有引起任何不可接受的风险的情况下完成预期口的。本标准为医疗器械软件的安全设计和维护提供了包括必要活动和任务的生存周期过程的框架。本标准为每个生存周期过程规定了要求。每个生存周期过程进一步划分为一组活动，多数活动又进一步划分为一组任务。
作为主要的基础，设想医疗器械软件是在质量管理体系（见41）和风险管理体系（见4.2）之内开发和维护的。国际标准YY36很好地描述了风险管理过程。因此本标准只是利用规范性引用文件YY/T0316这个有利条件
对软件需要增加一些较小补充的风险管理要求，特别是与危害有关的软件影响因素的识别。这些要求汇总并纳人第7章作为软件风险管理过程。在风险管理过程的危害判定活动中，确定软件是否为危害的影响因素。在确定软件是否是影响因
素时，需要考虑可能自教间接造成的危害（例如：提供可能导致给子不当治疗的误导信息）。使用软件来控制风险的决策，在风险管理过程的风险控制活动中做出本标准要求的软件风险管理过程必须包含在按照YY/T0316建立的医疗器械风险管理过程之中，软件开发过程出销
干活动组成
这些活动见图，并在第
章中描述。因为现场的许多事故是和医疗器械系统的服务战维护有关，包括不适当的软件更新和升级。软件维护过程被认为和软件开发过程一样重要。软件维过程和软件开发过程很相似。见图2和第6章的描述。a
顾客需求
软件开
发策划
软件需
求分析
缺件体系
结构设计
本保准范用之外的活动
系统开发活动（包括热险普理】7软件风险管理
软件详
细设计
软件单元
实施和验证
8软件配置管理
9软件问题解决
软件开发过程和活动概示
软件集成和
巢成测试
显各需求
得到满足
软件系
统测试
制定软件
维护计划
继护要求
问题和经改
软体系
结构设计
本标准范围之外的活动
系统维护活动（包括风险管理）7软件风险管理
软件群细
软料单元
实尴和验证
6.3实施修改
8软件配置管理
9软件间愿解决
YY/T0664--2008/1EC62034:2006要求得到
软件集成和
集成测试
图2软件维护过程和活动概示
软件系统
本标准确定开发安全的医疗器械软件必需考虑的两个补充过程，即软件配置管理过程（第8章）和软件间题解决过程（第9章）。
本标准不为制造商规定组织结构，或组织的哪一部分完成哪个过程、活动或任务。本标准只要求完成过程、活动或任务以确定符合本标准。本标准并不规定要形成的文件的名称，格式或明确的内容。本标准要求任务文件，但如何组合编排这些文件的决定留给标准的使用者来做。本标准并不规定特定的生存周期模型。本标准的使用者负责为软件项目选择生存周期模型，并将本标准中的过程、活动和任务映射在该模型上。附录A提供本标推各章的理由说明。附录B提供本标准规定的指南。对丁本标准：
，“应（shall)”意思是为符合本标准，符合一项要求是强制性的；，“应当（should）意思是为符合本标准，符合一项要求是推荐性的但不是强制性的；“可（may）”用于描述达到符合一项要求的许可方式：，“建立（establish）”意思是规定、形成文档和实施；和·本标准中术语“适当时（asappropriate）”与要求的过程、活动、任务或输出一起使用时，意指制造商应使用该过程活动、任务或输出，除非制造商能以文件形式说明不这样做的合理性。KANKAca=
1范围
医疗器械软件
YY/T0664—2008/IEC62034:2006软件生存周期过程
1.1目的
本标准规定了医疗器械软件的生存周期要求。在本标准中描述的一组过程、活动和任务，为医疗器械软件生存周期过程建立了共同的框架。1.2应用范围
本标准适用于医疗器械软件的开发利维护。当软件本身是医疗器械，或当软件是最终医疗器械的嵌入部分或组成部分时，本标唯适用于该医疗器械软件的开发和维护。
本标准不覆盖医疗器械的确认和最终发行，即使当该医疗器械完全由软件组成时。1.3与其他标准的关系
在开发医疗器械时，本医疗器械软件生存周期标准和其他适用的标准共同使用。本标准和其他相美标准之间的美系见附*C所ww.bzfxw.com1.4符合性
符合本标准意指按照软件安全性级别，实施在本标准中确定的所有过程、活动和任务。注：对每项要求所赋予的软件安全性级别在标难要求之后的正文中确定。用检查本标准所要求的所有文档（包括风险管理文档和对软件安全性级别所要求的过程、活动和任务的评定)的方法来确定符合性。见附录D。注1：此种评定可以由内部的或外部的审核来实现。注2：即使规定了要完成的过程、活动和任务，实施这些过程和执行这些活动和任务的方法是灵活的。注3：在任何包含“适当时（assppropriate）\的要求没有完成时，为说明理由而形成文档对于本评定是必要的。注4：木标准中用术语\符合（compliance）\的地方，GB/T8566中用术语“符合（canformance)\。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标难的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。YY/T0316医疗器械风险管理对医疗器械的应用（YY/T0316-2008,ISO14971：2007,IDT）3术语和定义
下列术语和定义适用于本标准。3.1
活动activity
一组中单个或多个相互关联或相互作用的任务。3.2
异常anomaly
任何偏离于所预期的需求说明书、设计文件、标准等的情况，或任何偏离于一些人员的感知或经验的情况。异常可能在（但不限）对软件产品或适用文件进行评审、测试、分析、编辑或使用过程中发现。[IEEE1044：1993.定义3.1]
YY/T0664—2008/IEC62034:20063.3
体系结构architecture
系统或组件的组织结构。
[IEEE610.12.1990]
更改要求changerequest
对软件产品进行更改所做的形成文档的说明3.5
configurationitem
配置项
能在给定的基准点上单独标识的实体。注：基于GB/T8566-2007，定义3.6。3.6
交付物
deliverable
一项活动或任务的要求结果或输出（包括文件）。3.7
evaluation
系统地确定一个实体项日满足其规定准则的程度。[GB/T8566—2007.定义3.9]
损害harm
对人体健康的实际伤害或损坏，或是对财产或环境的损坏。[ISO/1EC导则51:1999，定义3.3]3.9
危害hazard
损害的潜在源。
TISO/IEC导则51：1999.定义3.53.10
manufacturer
制造商
在上市和/或投入服务前，对医疗器械的设计、制造、包装或作标记、系统的装配或者改装医疗器械负有责任的自然人或法人，不管上述工作是由他自已或由第三方代其完成。［YY/T0316—2008.定义2.8]
医疗器械medical device
制造商的预期用途是为下列一个或多个特定目的用于人类的，不论单独使用或组合使用的仪器设备、器具、机器、用具、植人物、体外试剂或校准物、软件、材料或者其他相似或相关物品。这些目的是：
疾病的诊断、预防、监护、治疗或者缓解；损伤的诊断、监护、治疗、缓解或者补偿；解剖或生理过程的研究，替代、调节或者支持；支持或维持生命；
妊娠控制：
医疗器械的消毒；
通过对取自人体的样本进行体外检查的方式来提供医疗信息。2
KANIKAca-
YY/T0664-2008/IEC62034:2006
其作用于人体体表或体内的主要设计作用不是用药理学，免疫学或代谢的手段获得，但可能有这些手段参与并起一定辅助作用。
注1：本定义由全球协调工作组（GHTF）制定。见参考目录[151。（YY/T0287—2003）【YY/T0287—2003，定义3.7]
注2：每个国家用于法规的定义中会有一些区别3.12
医疗器械软件medicaldevicesoftware旨在包括在被开发的医疗器械内的已开发的软件系统，或者预期本身用作医疗器械而开发的软件系统。
问题报告problemreport
使用者或其他利益相关人员认为对顶期使用不安全、不适当或是违反规范的软件产品的实际或潜在特性的记录。
注1：本标准不要求每个问题报告都导致软件产品更改。在有误解、错误或可忽略事件时，制造商可拒绝问题报告。注2：间题报告可以涉及已发行的软件产品或仍在开发中的软件产品。注3：本标准要求制造商对涉及已发行产品的问题报告，实施额外的决策制定步骤（见第6章），以确保管理活动的识别和实施。
过程process
一组将输人转化为输出的相五关联或相互作用的活动。【GB/T19000:2000，定义3.4.1]注，术语“活动包括资源的使用，3.15
回归测试regression lesting
要求用于确定系统组件的更改没有对功能性、可靠性或性能产生不良影响，并且没有引入另外的缺陷的测试。
［1SO/IEC90003:2004，定义3.11]3.16
风险risk
损害严重度和其发生概率的结合。[ISO/IEC导则51:1999定义3.2]
风险分析risk analysis
系统运用可得资料，判定危害并估计风险［ISO/IEC导则51:1999定义3.10]3.18
riskcontrol
风险控制
作出决策并实施措施，以便降低风险或把风险维持在规定水平的过程。『YY/T03162008定义2.19]
风险管理riskmanagement
用于风险分析、评价、控制和监视工作的管理方针、程序及其实践的系统运用。[YY/T0316—2008定义2.22]
YY/T0664—2008/IEC62034:20063.20
风险管理文档riskmanagementfile由风险管理产生的一组记录和其他文件。YY/T0316—2008定义2.23]
安全性safety
免除于不可接受的风险
[1SO/IEC导则51：1999定义3.1]3.22
保密安全security
对信息和数据的保护，这样，未经授权的人员或系统不能阅读或修改它们，不能拒绝授权人员或系统对它们的访问。
【GB/T8566-2007定义3.25］
serious injury
严重伤害
直接或间接导致下列结果的伤害或疾病：a）危及生命；
b）造成人体功能的永久性损害或人体结构的永久性损坏，或c）需要内科或外科介人以防止人体功能的永久性损害或人体结构的永久性损伤。注：永久性损害意味着人体结构或功能的不可恢复的损害或伤害，微不足道的损害或伤害除外。3.24
软件开发生存周期模型
software development lifecyclemodel跨越软件从定义需求到制作发行这时间段的概念结构，其：识别包括在软件产品开发中的过程、活动和任务，描述活动和任务之间的顺序和依赖关系，和识别经验证的规定交付物完整性的里程碑。注：基于GB/T85662007，定义3.113.25
软件项softwareitem
计算机程序中任一可识别的部分。『ISO/IEC90003:2004，定义3.14，经修正的注：三个术语标明软件分解。顶级是软件系统。底级是不能进一步分解的软件单元。包括顶层和底层的所有组合层面，可以称为软件项。软件系统则由一个或多个软件项组成，而每个软件项由一个或多个软件单元或可分解的软件项组成。提供软件项和软件单元的定义和大小是制造商的责任。3.26
软件产品softwareproduc
-组计算机程序、规程以及可能的相关文档和数据。IGB/T8566-2007定义3.26]
软件系统soffwaresystem
编制以完成特定功能或一组功能的软件项的整合体。3.28
软件单元softwareunit
不可再分的软件项。
注：软件单元可用于软件配置管理或测试的目的。4
KAKAca
YY/T0664-2008/1EC62034:2006
未知来源软件（缩写SoUP）SOuUPsoftwareofunknownprovenance（acronym）已经开发且通常可得到的，并且不是为用以包含在医疗器械内而开发的软件项（也通称为成品软件），或以前开发的、不能得到其开发过程足够记录的软件。3.30
系统system
由一个或多个过程，硬件，软件、设施和人员组成的集合体，提供满足规定需求或目标的能力。［GB/T8566—2007.定义3.31
任务task
需要做的单项工作。
可追潮性
traceability
在开发过程中的两个或多个产品间能建立关联的程度。[1EEE610.12:1990]
验证verification
通过提供客观证据对规定要求已得到满足的认定。注1，“已验证”一词用于表示相应的状态。［GB/T190002000,定义3.8.4]
注2：在设计和开发中，验证涉及检查给定活动的结果以确定该项活动符合规定要求的过程3.34
版本version
某一配置项的已标识了的实例。注1：软件产品某版本的修改产生一个新版本，但要求软件配置管理活动。注2:基于GB/T8566-2007定义3.37。4总要求
质量管理体系
医疗器械软件制造商应证实其有能力提供持续满足顾客和适用的法规要求的医疗器械软件。注1：可通过利用符合下列要求的质量管理体系，证实此能力：YY/T0287L7].或
国家质量管理体系标准，或
国家法规要求的质量管理体系。注2：适用于软件的质量管理体系要求的指南见ISO/IEC90003[11]4.2风险管理
制造商应使用符合YY/T0316的风险管理过程。4.3软件的安全性级别
a）制造商应按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个软件安全性级别(A，B或C)。基于如下的严重度，应初步赋予软件相应安全性级别：A级：不可能对健康有伤害或损坏。B级：可能有不严重的伤害。
YY/T0664-2008/IEC62034.2006
C级：可能死亡或严重伤害。
如果危害可能由软件系统未能象规定的那样起作用引起，则此项失效的概率应假定为100%。如果软件失效引起死亡或严重伤害的风险，随后由硬件风险控制措施降低到可接受水平（如YY/T0316所规定），或者降低失效后果或者降低由失效引起的死亡或严重伤害的概率，软件安全性级别可从C降低到B：如果软件失效引起的非严重伤害风险同样通过硬件风险控制措施降低到可接收水平，软件安全性级别可从B降低到A。b）制造商应依据风险控制措施所控制的危害的可能影响，对实施风险控制措施起作用的每个软件系统赋子一个软件安全性级别。制造商应在风险管理文档中将赋予每个软件系统的软件安全性级别形成文档。e
当一个软件系统分解为软件项，及当一个软件项又进一步分解为几个软件项时，此类软件项应继承原软件项（或软件系统）的软件安全性级别，除非制造商以文件形式证明分类为不同的此理由说明应解释新的软件项是如何被分开的，以便可对其另行分级。安全性级别的理由。
如果以分解方式产生的款件项的安全级别和其源软件项不同，制造商应对每个软件项的软件e
安全级别形成文档
为符合本标准
项，制造商应
无论持定级别的软件项是否脂要一个过程，此过程是者有必要应用于一组软件此组中最高级别的软件项所要求的诸过程和任务，除非制造商在风险管理文档中有使用较低级别的理的说明文件g）对每个软件系统，在赋子软件安全性级别以前，均应应用C级要求。注：在随后的要求
软件开发过程
5.1软件开发策划
5.1.1软件开发计划
该项要求必须实施的软件安全性级别，以级形武标示于该要求之后。
制造商应制定5多项）软件并发计划，以便实施适备十所并发软件系统的范围、规模和软件安一个（或多个）计划中应完整地规定或引用软件开发生存周期模全性级别的软件开发运程的活动。在型。计划应说明下列
用于软件系统开爱的过程（见注4）a)
各项活动和任多付物（包括文件）；系统需求、软件需求实件系统测试和在软件中实施的风险控制措施之间的可追溯性；软件配置和更改管，包括末知来源软件配置项和用于支持开发的软件：和在生存周期每个阶段的软件产品交付物和活动中发现的用于处理问题的软件问题解决方案。TAB.C级
注1：软件开发生存周期模型可依照软件系统每个软件项的软件安全性分级为不同的软件项识别不同的要素（过程、活动、任务和交付物）。
注2：这些活动和任务可以重叠或相互作用，可选代或循环地完成。其意图并不意味应当使用特定的生存周期模型。
注3：本标准中其他过程和开发过程分开描述，这并不意味着它们必领作为单独的活动和任务来实施。其他过程的活动和任务可以整合到开发过程中。注4：软件开发计划可以参考现有的过程或规定新过程。注5：软件开发计划可以整合到一个全系统的开发计划中：5.1.2保持软件开发计划更新
在适当时，制造商应在开发进行的同时更新计划，[AB.C级]
KAiKAca
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国医药行业标准
YY/T0664—2008/IEC62034:2006医疗器械软件
软件生存周期过程
Medical devicesoftware-Software life cycle processes(IEC62034:2006.IDT)
2008-04-25发布
数码防伪
国家食品药品监督管理局
2009-06-01实施
“目的
·应用范围
与其他标准的关系
符合性
*规范性引用文件
*术语和定义
总要求
质量管理体系
·风险管理
·软件的安全性级别
软件开发过程
·软件开发策划
·软件需求分析
·软件体系结构设计
“软件详细设计
*软件单元的实现和验证bZxz.net
·软件集成和集成测试
软件系统测试
“软件发行
软件维护过程
·制定软件维护计划
问题和修改分析
“修改的实施
软件风险管理过程
促成危害处境的软件分析
风险控制措施·
风险控制措施的验证·
软件更改的风险管理
*软件配置管理过程
·配置标识
·更改控制
配置状态记录
软件问题解决过程
准备问题报告
研究间题
KANIKAca-
YY/T0664-—2008/IEC62034:20064
YY/T0664—2008/IEC62034:20069.3
通知相关方·
应用更改控制过程·
保持记录
9.6分析问题的趋势，
验证软件间题的解决
9.8测试文档内容
附录A（资料性附录）
附录B（资料性附录）
附录C（资料性附录）
附录D（资料性附录）
参考文献
本标准要求的理由说明
对本标准规定的指南
与其他标准的关系
实施·
图1软件开发过程和活动概示
图2软件维护过程和活动概示
软件项划分示例
关键性医疗器械标准和本标准的关系图C2
软件作为V模型的一部分
本标准同GB4793的应用
软件安全性级别要求摘要
GB/T8566中规定的开发（模型）策略与YY/T0287—2003的关系·
与YY/T03162008的关系
与IEC60601-1的关系
与IEC60601-1-4的关系
与GB/T8566的关系
未经质量管理体系认证的小型制造商的检查表18
YY/T0664-2008/IEC62034.2006
本标准等同采用IEC62304：2006《医疗器械软件软件生存周期过程》（英文版）。IEC62304:2006医疗器械软件软件生存周期过程》给出了在第3章中定义的术语索引，本标准将该索引删除。
本标准中带星号（*）的条款表示在附录B中有关于该条款的指南。IEC623042006《医疗器械软件软件生存周期过程》（英文版）中的术语和附录C部分引用ISO14971：2000条款，由于ISO14971：2007版已经发布，本标准中引用YY/T0316—2008/ISO14971：2007的相应部分。
本标准的附录A、附录B、附录C和附录D均为资料性附录。本标准由国家食品药品监督管理局医疗器械司提出。本标准由医疗器械质量管理和通用要求标准化技术委员会（SAC/TC221)归口。本标准起草单位：医疗器械质量管理和通用要求标准化技术委员会，北京国医械华光认证有限公司。
本标准主要起草人：秦树华、陈志刚、米兰英、武俊华、李慧民。KANIKAca-
YY/T0664—2008/IEC62034:2006引
软件往往是医疗器械技术的一个组成部分。建立包括软件的医疗器械的安全性和有效性，要求有软件预期用途的知识，并要证实软件的使用在没有引起任何不可接受的风险的情况下完成预期口的。本标准为医疗器械软件的安全设计和维护提供了包括必要活动和任务的生存周期过程的框架。本标准为每个生存周期过程规定了要求。每个生存周期过程进一步划分为一组活动，多数活动又进一步划分为一组任务。
作为主要的基础，设想医疗器械软件是在质量管理体系（见41）和风险管理体系（见4.2）之内开发和维护的。国际标准YY36很好地描述了风险管理过程。因此本标准只是利用规范性引用文件YY/T0316这个有利条件
对软件需要增加一些较小补充的风险管理要求，特别是与危害有关的软件影响因素的识别。这些要求汇总并纳人第7章作为软件风险管理过程。在风险管理过程的危害判定活动中，确定软件是否为危害的影响因素。在确定软件是否是影响因
素时，需要考虑可能自教间接造成的危害（例如：提供可能导致给子不当治疗的误导信息）。使用软件来控制风险的决策，在风险管理过程的风险控制活动中做出本标准要求的软件风险管理过程必须包含在按照YY/T0316建立的医疗器械风险管理过程之中，软件开发过程出销
干活动组成
这些活动见图，并在第
章中描述。因为现场的许多事故是和医疗器械系统的服务战维护有关，包括不适当的软件更新和升级。软件维护过程被认为和软件开发过程一样重要。软件维过程和软件开发过程很相似。见图2和第6章的描述。a
顾客需求
软件开
发策划
软件需
求分析
缺件体系
结构设计
本保准范用之外的活动
系统开发活动（包括热险普理】7软件风险管理
软件详
细设计
软件单元
实施和验证
8软件配置管理
9软件问题解决
软件开发过程和活动概示
软件集成和
巢成测试
显各需求
得到满足
软件系
统测试
制定软件
维护计划
继护要求
问题和经改
软体系
结构设计
本标准范围之外的活动
系统维护活动（包括风险管理）7软件风险管理
软件群细
软料单元
实尴和验证
6.3实施修改
8软件配置管理
9软件间愿解决
YY/T0664--2008/1EC62034:2006要求得到
软件集成和
集成测试
图2软件维护过程和活动概示
软件系统
本标准确定开发安全的医疗器械软件必需考虑的两个补充过程，即软件配置管理过程（第8章）和软件间题解决过程（第9章）。
本标准不为制造商规定组织结构，或组织的哪一部分完成哪个过程、活动或任务。本标准只要求完成过程、活动或任务以确定符合本标准。本标准并不规定要形成的文件的名称，格式或明确的内容。本标准要求任务文件，但如何组合编排这些文件的决定留给标准的使用者来做。本标准并不规定特定的生存周期模型。本标准的使用者负责为软件项目选择生存周期模型，并将本标准中的过程、活动和任务映射在该模型上。附录A提供本标推各章的理由说明。附录B提供本标准规定的指南。对丁本标准：
，“应（shall)”意思是为符合本标准，符合一项要求是强制性的；，“应当（should）意思是为符合本标准，符合一项要求是推荐性的但不是强制性的；“可（may）”用于描述达到符合一项要求的许可方式：，“建立（establish）”意思是规定、形成文档和实施；和·本标准中术语“适当时（asappropriate）”与要求的过程、活动、任务或输出一起使用时，意指制造商应使用该过程活动、任务或输出，除非制造商能以文件形式说明不这样做的合理性。KANKAca=
1范围
医疗器械软件
YY/T0664—2008/IEC62034:2006软件生存周期过程
1.1目的
本标准规定了医疗器械软件的生存周期要求。在本标准中描述的一组过程、活动和任务，为医疗器械软件生存周期过程建立了共同的框架。1.2应用范围
本标准适用于医疗器械软件的开发利维护。当软件本身是医疗器械，或当软件是最终医疗器械的嵌入部分或组成部分时，本标唯适用于该医疗器械软件的开发和维护。
本标准不覆盖医疗器械的确认和最终发行，即使当该医疗器械完全由软件组成时。1.3与其他标准的关系
在开发医疗器械时，本医疗器械软件生存周期标准和其他适用的标准共同使用。本标准和其他相美标准之间的美系见附*C所ww.bzfxw.com1.4符合性
符合本标准意指按照软件安全性级别，实施在本标准中确定的所有过程、活动和任务。注：对每项要求所赋予的软件安全性级别在标难要求之后的正文中确定。用检查本标准所要求的所有文档（包括风险管理文档和对软件安全性级别所要求的过程、活动和任务的评定)的方法来确定符合性。见附录D。注1：此种评定可以由内部的或外部的审核来实现。注2：即使规定了要完成的过程、活动和任务，实施这些过程和执行这些活动和任务的方法是灵活的。注3：在任何包含“适当时（assppropriate）\的要求没有完成时，为说明理由而形成文档对于本评定是必要的。注4：木标准中用术语\符合（compliance）\的地方，GB/T8566中用术语“符合（canformance)\。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标难的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。YY/T0316医疗器械风险管理对医疗器械的应用（YY/T0316-2008,ISO14971：2007,IDT）3术语和定义
下列术语和定义适用于本标准。3.1
活动activity
一组中单个或多个相互关联或相互作用的任务。3.2
异常anomaly
任何偏离于所预期的需求说明书、设计文件、标准等的情况，或任何偏离于一些人员的感知或经验的情况。异常可能在（但不限）对软件产品或适用文件进行评审、测试、分析、编辑或使用过程中发现。[IEEE1044：1993.定义3.1]
YY/T0664—2008/IEC62034:20063.3
体系结构architecture
系统或组件的组织结构。
[IEEE610.12.1990]
更改要求changerequest
对软件产品进行更改所做的形成文档的说明3.5
configurationitem
配置项
能在给定的基准点上单独标识的实体。注：基于GB/T8566-2007，定义3.6。3.6
交付物
deliverable
一项活动或任务的要求结果或输出（包括文件）。3.7
evaluation
系统地确定一个实体项日满足其规定准则的程度。[GB/T8566—2007.定义3.9]
损害harm
对人体健康的实际伤害或损坏，或是对财产或环境的损坏。[ISO/1EC导则51:1999，定义3.3]3.9
危害hazard
损害的潜在源。
TISO/IEC导则51：1999.定义3.53.10
manufacturer
制造商
在上市和/或投入服务前，对医疗器械的设计、制造、包装或作标记、系统的装配或者改装医疗器械负有责任的自然人或法人，不管上述工作是由他自已或由第三方代其完成。［YY/T0316—2008.定义2.8]
医疗器械medical device
制造商的预期用途是为下列一个或多个特定目的用于人类的，不论单独使用或组合使用的仪器设备、器具、机器、用具、植人物、体外试剂或校准物、软件、材料或者其他相似或相关物品。这些目的是：
疾病的诊断、预防、监护、治疗或者缓解；损伤的诊断、监护、治疗、缓解或者补偿；解剖或生理过程的研究，替代、调节或者支持；支持或维持生命；
妊娠控制：
医疗器械的消毒；
通过对取自人体的样本进行体外检查的方式来提供医疗信息。2
KANIKAca-
YY/T0664-2008/IEC62034:2006
其作用于人体体表或体内的主要设计作用不是用药理学，免疫学或代谢的手段获得，但可能有这些手段参与并起一定辅助作用。
注1：本定义由全球协调工作组（GHTF）制定。见参考目录[151。（YY/T0287—2003）【YY/T0287—2003，定义3.7]
注2：每个国家用于法规的定义中会有一些区别3.12
医疗器械软件medicaldevicesoftware旨在包括在被开发的医疗器械内的已开发的软件系统，或者预期本身用作医疗器械而开发的软件系统。
问题报告problemreport
使用者或其他利益相关人员认为对顶期使用不安全、不适当或是违反规范的软件产品的实际或潜在特性的记录。
注1：本标准不要求每个问题报告都导致软件产品更改。在有误解、错误或可忽略事件时，制造商可拒绝问题报告。注2：间题报告可以涉及已发行的软件产品或仍在开发中的软件产品。注3：本标准要求制造商对涉及已发行产品的问题报告，实施额外的决策制定步骤（见第6章），以确保管理活动的识别和实施。
过程process
一组将输人转化为输出的相五关联或相互作用的活动。【GB/T19000:2000，定义3.4.1]注，术语“活动包括资源的使用，3.15
回归测试regression lesting
要求用于确定系统组件的更改没有对功能性、可靠性或性能产生不良影响，并且没有引入另外的缺陷的测试。
［1SO/IEC90003:2004，定义3.11]3.16
风险risk
损害严重度和其发生概率的结合。[ISO/IEC导则51:1999定义3.2]
风险分析risk analysis
系统运用可得资料，判定危害并估计风险［ISO/IEC导则51:1999定义3.10]3.18
riskcontrol
风险控制
作出决策并实施措施，以便降低风险或把风险维持在规定水平的过程。『YY/T03162008定义2.19]
风险管理riskmanagement
用于风险分析、评价、控制和监视工作的管理方针、程序及其实践的系统运用。[YY/T0316—2008定义2.22]
YY/T0664—2008/IEC62034:20063.20
风险管理文档riskmanagementfile由风险管理产生的一组记录和其他文件。YY/T0316—2008定义2.23]
安全性safety
免除于不可接受的风险
[1SO/IEC导则51：1999定义3.1]3.22
保密安全security
对信息和数据的保护，这样，未经授权的人员或系统不能阅读或修改它们，不能拒绝授权人员或系统对它们的访问。
【GB/T8566-2007定义3.25］
serious injury
严重伤害
直接或间接导致下列结果的伤害或疾病：a）危及生命；
b）造成人体功能的永久性损害或人体结构的永久性损坏，或c）需要内科或外科介人以防止人体功能的永久性损害或人体结构的永久性损伤。注：永久性损害意味着人体结构或功能的不可恢复的损害或伤害，微不足道的损害或伤害除外。3.24
软件开发生存周期模型
software development lifecyclemodel跨越软件从定义需求到制作发行这时间段的概念结构，其：识别包括在软件产品开发中的过程、活动和任务，描述活动和任务之间的顺序和依赖关系，和识别经验证的规定交付物完整性的里程碑。注：基于GB/T85662007，定义3.113.25
软件项softwareitem
计算机程序中任一可识别的部分。『ISO/IEC90003:2004，定义3.14，经修正的注：三个术语标明软件分解。顶级是软件系统。底级是不能进一步分解的软件单元。包括顶层和底层的所有组合层面，可以称为软件项。软件系统则由一个或多个软件项组成，而每个软件项由一个或多个软件单元或可分解的软件项组成。提供软件项和软件单元的定义和大小是制造商的责任。3.26
软件产品softwareproduc
-组计算机程序、规程以及可能的相关文档和数据。IGB/T8566-2007定义3.26]
软件系统soffwaresystem
编制以完成特定功能或一组功能的软件项的整合体。3.28
软件单元softwareunit
不可再分的软件项。
注：软件单元可用于软件配置管理或测试的目的。4
KAKAca
YY/T0664-2008/1EC62034:2006
未知来源软件（缩写SoUP）SOuUPsoftwareofunknownprovenance（acronym）已经开发且通常可得到的，并且不是为用以包含在医疗器械内而开发的软件项（也通称为成品软件），或以前开发的、不能得到其开发过程足够记录的软件。3.30
系统system
由一个或多个过程，硬件，软件、设施和人员组成的集合体，提供满足规定需求或目标的能力。［GB/T8566—2007.定义3.31
任务task
需要做的单项工作。
可追潮性
traceability
在开发过程中的两个或多个产品间能建立关联的程度。[1EEE610.12:1990]
验证verification
通过提供客观证据对规定要求已得到满足的认定。注1，“已验证”一词用于表示相应的状态。［GB/T190002000,定义3.8.4]
注2：在设计和开发中，验证涉及检查给定活动的结果以确定该项活动符合规定要求的过程3.34
版本version
某一配置项的已标识了的实例。注1：软件产品某版本的修改产生一个新版本，但要求软件配置管理活动。注2:基于GB/T8566-2007定义3.37。4总要求
质量管理体系
医疗器械软件制造商应证实其有能力提供持续满足顾客和适用的法规要求的医疗器械软件。注1：可通过利用符合下列要求的质量管理体系，证实此能力：YY/T0287L7].或
国家质量管理体系标准，或
国家法规要求的质量管理体系。注2：适用于软件的质量管理体系要求的指南见ISO/IEC90003[11]4.2风险管理
制造商应使用符合YY/T0316的风险管理过程。4.3软件的安全性级别
a）制造商应按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个软件安全性级别(A，B或C)。基于如下的严重度，应初步赋予软件相应安全性级别：A级：不可能对健康有伤害或损坏。B级：可能有不严重的伤害。
YY/T0664-2008/IEC62034.2006
C级：可能死亡或严重伤害。
如果危害可能由软件系统未能象规定的那样起作用引起，则此项失效的概率应假定为100%。如果软件失效引起死亡或严重伤害的风险，随后由硬件风险控制措施降低到可接受水平（如YY/T0316所规定），或者降低失效后果或者降低由失效引起的死亡或严重伤害的概率，软件安全性级别可从C降低到B：如果软件失效引起的非严重伤害风险同样通过硬件风险控制措施降低到可接收水平，软件安全性级别可从B降低到A。b）制造商应依据风险控制措施所控制的危害的可能影响，对实施风险控制措施起作用的每个软件系统赋子一个软件安全性级别。制造商应在风险管理文档中将赋予每个软件系统的软件安全性级别形成文档。e
当一个软件系统分解为软件项，及当一个软件项又进一步分解为几个软件项时，此类软件项应继承原软件项（或软件系统）的软件安全性级别，除非制造商以文件形式证明分类为不同的此理由说明应解释新的软件项是如何被分开的，以便可对其另行分级。安全性级别的理由。
如果以分解方式产生的款件项的安全级别和其源软件项不同，制造商应对每个软件项的软件e
安全级别形成文档
为符合本标准
项，制造商应
无论持定级别的软件项是否脂要一个过程，此过程是者有必要应用于一组软件此组中最高级别的软件项所要求的诸过程和任务，除非制造商在风险管理文档中有使用较低级别的理的说明文件g）对每个软件系统，在赋子软件安全性级别以前，均应应用C级要求。注：在随后的要求
软件开发过程
5.1软件开发策划
5.1.1软件开发计划
该项要求必须实施的软件安全性级别，以级形武标示于该要求之后。
制造商应制定5多项）软件并发计划，以便实施适备十所并发软件系统的范围、规模和软件安一个（或多个）计划中应完整地规定或引用软件开发生存周期模全性级别的软件开发运程的活动。在型。计划应说明下列
用于软件系统开爱的过程（见注4）a)
各项活动和任多付物（包括文件）；系统需求、软件需求实件系统测试和在软件中实施的风险控制措施之间的可追溯性；软件配置和更改管，包括末知来源软件配置项和用于支持开发的软件：和在生存周期每个阶段的软件产品交付物和活动中发现的用于处理问题的软件问题解决方案。TAB.C级
注1：软件开发生存周期模型可依照软件系统每个软件项的软件安全性分级为不同的软件项识别不同的要素（过程、活动、任务和交付物）。
注2：这些活动和任务可以重叠或相互作用，可选代或循环地完成。其意图并不意味应当使用特定的生存周期模型。
注3：本标准中其他过程和开发过程分开描述，这并不意味着它们必领作为单独的活动和任务来实施。其他过程的活动和任务可以整合到开发过程中。注4：软件开发计划可以参考现有的过程或规定新过程。注5：软件开发计划可以整合到一个全系统的开发计划中：5.1.2保持软件开发计划更新
在适当时，制造商应在开发进行的同时更新计划，[AB.C级]
KAiKAca
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。