中国标准英文版 数据库收录: 159759 更新: 2022-05-03

YY/T 0664-2020

标准搜索结果: 'YY/T 0664-2020'
标准号码内文价格美元第2步交付天数标准名称相关标准状态
YY/T 0664-2020 英文版 980 购买 3分钟内自动发货[PDF],有增值税发票。 医疗器械软件 软件生存周期过程 YY/T 0664-2020 有效

   
基本信息
标准编号 YY/T 0664-2020 (YY/T0664-2020)
中文名称 医疗器械软件 软件生存周期过程
英文名称 Medical device software -- Software life cycle processes
行业 医药行业标准 (推荐)
中标分类 C30
国际标准分类 11.040.01; 35.240.80
字数估计 64,656
发布日期 2020-09-27
实施日期 2021-09-01
旧标准 (被替代) YY/T 0664-2008
起草单位 北京国医械华光认证有限公司、中国食品药品检定研究院、国家药品监督管理局医疗器械技术审评中心、北京怡和嘉业医疗科技股份有限公司、东软医疗系统股份有限公司、上海微创医疗器械(集团)有限公司、深圳迈瑞生物医疗电子股份有限公司、上海西门子医疗器械有限公司、康泰医学系统(秦皇岛)股份有限公司、北京推想科技有限公司
归口单位 全国医疗器械质量管理和通用要求标准化技术委员会(SAC/TC 221)
标准依据 国家药品监督管理局公告2020年第108号
提出机构 国家药品监督管理局
发布机构 国家药品监督管理局

YY/T 0664-2020
Medical device software - Software life cycle processes
ICS 11.040.01;35.240.80
C30
中华人民共和国医药行业标准
代替YY/T 0664-2008
医疗器械软件 软件生存周期过程
(IEC 62304:2015,MOD)
2020-09-27发布
2021-09-01实施
国家药品监督管理局 发 布
目次
前言 Ⅲ
引言 Ⅴ
1 范围 1
1.1 *目的 1
1.2 *应用范围 1
1.3 与其他标准的关系 1
1.4 符合性 1
2 *规范性引用文件 1
3 *术语和定义 2
4 *总要求 6
4.1 *质量管理体系 6
4.2 *风险管理 6
4.3 *软件安全分级 6
4.4 *遗留软件 8
5 软件开发过程 9
5.1 *软件开发策划 9
5.2 *软件需求分析 11
5.3 *软件体系结构设计 13
5.4 *软件详细设计 13
5.5 *软件单元的实现 14
5.6 *软件集成和集成测试 15
5.7 *软件系统测试 16
5.8 *软件在系统级别应用的发布 17
6 软件维护过程 18
6.1 *建立软件维护计划 18
6.2 *问题和修改分析 18
6.3 *修改的实施 19
7 *软件风险管理过程 19
7.1 *促成危险情况的软件分析 19
7.2 风险控制措施 20
7.3 风险控制措施的验证 20
7.4 软件变更的风险管理 20
8 *软件配置管理过程 21
8.1 *配置标识 21
8.2 *变更控制 21
8.3 *配置状态报告 22
9 *软件问题解决过程 22
9.1 编写问题报告 22
9.2 调查问题 22
9.3 通知相关方 22
9.4 使用变更控制过程 22
9.5 保持记录 22
9.6 分析问题的趋势 23
9.7 验证软件问题的解决 23
9.8 测试文档的内容 23
附录A(资料性附录) 本标准要求的理由说明 24
附录B(资料性附录) 关于本标准条款的指南 26
附录C(资料性附录) 与其他标准的关系 39
附录D(资料性附录) 实施 55
参考文献 57
图1 软件开发过程和活动图示 Ⅴ
图2 软件维护过程和活动图示 Ⅵ
图3 赋予软件安全级别 7
图B.1 危险(源)、事件序列、危险情况和伤害关系的图示(源于YY/T 0316-2016的附录E) 29
图B.2 软件项划分示例 30
图B.3 法规视角---现成软件与未知来源软件、遗留软件之间的关系 32
图C.1 重要医疗器械标准与本标准的关系 39
图C.2 软件作为V模型的一部分 42
图C.3 YY/T 0664与IEC 61010-1联合应用 48
表A.1 按软件安全级别的要求汇总 25
表B.1 ISO/IEC 12207中规定的开发(模型)策略 26
表C.1 与YY/T 0287-2017的关系 40
表C.2 与YY/T 0316-2016的关系 41
表C.3 与IEC 60601-1的关系 43
表C.4 与ISO/IEC 12207:2008的关系 49
表D.1 用于未经质量管理体系认证的小型制造商的检查表 55
医疗器械软件 软件生存周期过程
1 范围
1.1 *目的
本标准为医疗器械软件规定了生存周期要求。本标准中描述的一组过程、活动和任务,为医疗器械
软件生存周期过程建立了共同的框架。
1.2 *应用范围
本标准适用于医疗器械软件的开发和维护。医疗器械软件包括本身是医疗器械的软件或是最终医
疗器械的嵌入部分或组成部分的软件。
注1:本标准可用于本身是医疗器械的软件的开发和维护。然而,在该类型软件能够投入使用之前,还需要在系统
级上进行附加的开发活动。本标准不覆盖这些系统级活动,相关要求可参见IEC 82304-1[11]。
本标准描述了预期应用于软件的过程,该类软件可在处理器上执行或通过在处理器上运行的其他
软件(例如解释器)执行。
无论使用何种持久存储设备存储软件(例如:硬盘、光盘、永久内存或闪存),本标准均适用。
无论使用何种交付方法交付软件[例如:通过网络或电子邮件传输,或光盘、闪存或带电可擦除编程
只读存储器(EEPROM)等物理移送],本标准均适用。软件交付方法本身不视为医疗器械软件。
本标准不覆盖医疗器械的确认和最终发布,即使该医疗器械完全由软件组成。
注2:如果医疗器械包含拟在处理器上执行的嵌入式软件,则本标准的要求适用于该软件,包括有关未知来源软件
的要求(见8.1.2)。
注3:在软件和医疗器械能够投入使用之前,需要在系统级上进行确认和其他开发活动。本标准不覆盖这些系统级
活动,可参见相关产品标准(如IEC 60601-1[6],IEC 82304-1[11]等)。
1.3 与其他标准的关系
在开发医疗器械时,本医疗器械软件生存周期标准和其他适用的标准共同使用。本标准与其他相
关标准之间的关系参见附录C。
1.4 符合性
符合本标准意指按照软件安全级别,实施在本标准中确定的所有过程、活动和任务。
注1:为每项要求赋予的软件安全级别在正文中标注在该项要求之后。
通过对本标准所要求的所有文档(包括风险管理文档)的检查和对软件安全级别所要求的过程、活
动和任务的评定来确定符合性。
注2:此种评定可通过内部或外部的审核来进行。
注3:尽管要完成特定的过程、活动和任务,但实施这些过程和执行这些活动和任务的方法具有灵活性。
注4:若任何包含“适当时(asappropriate)”的要求未实施,为说明理由而形成的文档对于本评定是必要的。
注5:本标准中用术语“符合性(compliance)”之处,在ISO/IEC 12207中用术语“符合性(conformance)”。
注6:有关遗留软件的符合性,见4.4。
2 *规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件项应继承原软件项(或软件系统)的软件安全级别,除非制造商以文件形式说明分类为不同
软件安全级别的理由[根据4.3a)用“软件项”替换“软件系统”赋予的软件安全级别]。此类理
由说明应解释新的软件项如何被隔离,以便可对其单独分级。
d) 如果以分解方式产生的软件项的安全级别与其原软件项不同,制造商应将每个此类软件项的
软件安全级别形成文件。
e) 为符合本标准,当本标准应用于一组软件项时,制造商应使用此组中级别最高的软件项所要
求的诸过程和任务,除非制造商在风险管理文档中将使用较低级别的理由说明形成文件。
f) 对每个软件系统,在赋予软件安全级别以前,均应应用C级要求。
注:在随后的章条中,对每一特定要求所适用的软件安全级别,以 [级]的形式标注于该要求之后。
4.4 *遗留软件
4.4.1 概述
针对遗留软件,作为应用第5章~第9章的替代方案,可按照4.4.2~4.4.5所述证实遗留软件的符
合性。
4.4.2 风险管理活动
根据4.2的要求,制造商应:
a) 评定来自该组织内部和/或用户的有关遗留软件事件和/或险肇事件的任何反馈,包括生产后
信息;
b) 实施与继续使用遗留软件相关的风险管理活动,并考虑以下方面:
---在整个医疗器械体系结构中遗留软件的集成;
---作为遗留软件一部分实施的风险控制措施是否持续有效;
---与遗留软件继续使用相关的危险情况的识别;
---遗留软件促成危险情况的潜在原因的识别;
---针对遗留软件促成危险情况的每个潜在原因,确定风险控制措施。
4.4.3 差距分析
基于遗留软件的软件安全级别(见4.3),制造商应根据5.2、5.3、5.7和第7章的要求对可获得的交
付物进行以下差距分析:
a) 制造商应评定可获得的交付物是否持续有效;
b) 识别到差距之处,制造商应针对缺失的交付物和相关活动,评价弥补措施对风险的潜在降低;
c) 基于此评价,制造商应确定拟创建的交付物和拟执行的相关活动。交付物至少应为软件系统
测试记录(见5.7.5)。
注:该差距分析宜确保对遗留软件所实施的风险控制措施包含在软件需求中。
4.4.4 差距关闭活动
差距关闭活动涉及如下内容:
a) 制造商应建立并执行生成所识别的交付物的计划。若可获得,可使用客观证据生成所需的交
付物,而不执行5.2、5.3、5.7和第7章所要求的活动;
注:关于如何处理已识别差距的计划可包含在软件维护计划中(见6.1)。
b) 该计划应阐述问题解决过程的使用要求,以便按照第9章处置在遗留软件和交付物中发现的
问题;
c) 对遗留软件的变更应按照第6章进行。
4.4.5 使用遗留软件的理由
制造商应基于4.4的输出将遗留软件的版本连同继续使用遗留软件的理由形成文件。
注:根据本标准,满足4.4的要求即可使用遗留软件。
5 软件开发过程
5.1 *软件开发策划
5.1.1 软件开发计划
制造商应建立一项(或多项)软件开发计划,以便实施适合于拟开发软件系统的范围、规模和软件安
全级别的软件开发过程相关活动。在计划中应完整地定义或引用软件开发生存周期模型。计划应说明
下列各项:
a) 用于软件系统开发的过程(见注4);
b) 各项活动和任务的交付物(包括文档);
c) 系统需求、软件需求、软件系统测试以及在软件中实施的风险控制措施之间的可追溯性;
d) 软件配置和变更管理,包括未知来源软件的配置项和用于支持开发的软件;
e) 软件问题解决方案,以处理在生存周期各阶段的医疗器械软件、交付物和活动中所发现的
问题。
[A、B、C级]
注1:软件开发生存周期模型可根据软件系统的每个软件项的软件安全级别为不同的软件项识别不同的要素(过
程、活动、任务和交付物)。
注2:这些活动和任务可以重叠或相互作用,可迭代或循环地完成。其意图并非暗示宜使用特定的生存周期模型。
注3:在本标准中将其他过程与开发过程分开描述。这并非暗示其他过程必须作为单独的活动和任务来实施。可
将其活动和任务整合到开发过程中。
注4:软件开发计划可以引用现有的过程或定义新过程。
注5:可将软件开发计划整合到整个系统的开发计划中。
5.1.2 保持对软件开发计划的更新
适当时,制造商应随着开发的进行更新计划。[A、B、C级]
5.1.3 引用系统设计和开发的软件开发计划
在软件开发计划中,制造商应:
a) 引用系统需求,作为软件开发的输入;
b) 包括或引用用于协调软件开发和系统开发所必需的规程以满足4.1的要求(例如系统的集成、
验证和确认)。
[A、B、C级]
注:如果软件系统是一个独立的系统(纯软件器械),在软件系统需求和系统需求之间可能没有区别。
5.1.4 软件开发标准、方法和工具的策划
制造商应在软件开发计划中包括或引用与C级软件项开发有关的:
a) 标准;
b) 方法;
c) 工具。
[C级]
5.1.5 软件集成和集成测试的策划
制造商应在软件开发计划中包括或引用一项计划,以集成软件项(包括未知来源软件)并在集成过
程中完成测试。[B、C级]
注1:将集成测试和软件系统测试合并到一项单一的计划和一组活动中是可接受的。
注2:见5.6。
5.1.6 软件验证策划
制造商应在软件开发计划中包括或引用下列验证信息:
a) 要求验证的交付物;
b) 每个生存周期活动所要求的验证任务;
c) 对交付物进行验证的里程碑;
d) 验证交付物的验收准则。
[A、B、C级]
5.1.7 软件风险管理策划
制造商应在软件开发计划中包括或引用一项计划,以实施软件风险管理过程的活动和任务,包括与
未知来源软件有关的风险的管理。[A、B、C级]
注:见第7章。
5.1.8 文档的策划
制造商应在软件开发计划中包括或引用有关在软件开发生存周期中要生成的文件的信息。对每个
已识别的文件或文件类型,应包括或引用如下信息:
a) 标题、名称或命名约定;
b) 目的;
c) 开发、评审、批准和修改的规程和职责。
[A、B、C级]
注:文档配置管理考虑的因素见第8章。
5.1.9 软件配置管理策划
制造商应在软件开发计划中包括或引用软件配置管理信息。软件配置管理信息应包括或引用:
a) 拟受控项的级别、型式、类别或清单;
b) 软件配置管理活动和任务;
c) 负责实施软件配置管理活动的一个或多个组织;
d) 这些组织和其他诸如软件开发或维护组织的关系;
e) 何时将这些项目置于配置控制之下;
f) 何时使用问题解决过程。
[A、B、C级]
注:见第8章。
5.1.10 拟受控的支持项
拟受控项应包括用于医疗器械软件开发并对医疗器械软件可能有影响的工具、项目或设置。[B、C
级]
注1:此类项目的示例包括编译器/汇编器的版本、生成文件、批处理文件和特定的环境设置。
注2:见第8章。
5.1.11 验证前软件配置项的控制
制造商应进行策划以将软件配置项在验证之前置于配置管理控制之下。[B、C级]
5.1.12 识别和避免常见软件缺陷
制造商应在软件开发计划中包括或引用以下规程:
a) 基于所选的与其软件系统相关的编程技术,识别可能引入的缺陷类别;
b) 证实这些缺陷不会促成不可接受风险的形成文件的证据。
注:有关促成危险情况的缺陷或原因类别的示例参见YY/T 1406.1-2016的附录B。
[B,C级]
5.2 *软件需求分析
5.2.1 定义来自系统需求的软件需求并将其形成文件
对医疗器械的每个软件系统,制造商应定义来自系统级需求的软件系统需求并形成文件。[A、B、
C级]
注:如果软件系统是一个独立的系统(纯软件器械),在软件系统需求和系统需求之间可能没有区别。
5.2.2 软件需求的内容
若适用于医疗器械软件,制造商应在软件需求中包括:
a) 功能和性能需求;
注1:示例包括:
---性能(如软件的目的、时序要求);
---物理特性(如编码语言、平台、操作系统);
---软件运行的计算环境(如硬件、存储容量、处理单元、时区、网络基础设施);
---与升级或多种未知来源软件或其他器械版本的兼容性需求。
b) 软件系统的输入和输出;
注2:示例包括:
---数据特性(如数字的、字母数字的、格式);
---范围;
---约束;
---默认值。
c) 软件系统和其他系统之间的接口;
d) 软件驱动的报警、警告和操作者信息;
e) 信息安全需求;
注3:示例包括:
---与敏感信息泄露有关的需求;
---身份验证;
---授权;
---审核跟踪;
---通信的完整性;
---系统信息安全/恶意软件防护。
f) 由软件实现的用户界面需求;
注4:示例包括与以下内容有关的需求:
---对人工操作的支持;
---人机交互;
---对人员的约束;
---需要人员集中注意力的区域。
注5:有关可用性工程需求的信息参见IEC 62366-1[10]和其他标准(如IEC 60601-1-6[8])。
g) 数据定义和数据库需求;
注6:示例包括:
---表单;
---匹配;
---功能。
h) 已交付医疗器械软件在一个或多个操作和维护现场的安装和验收需求;
i) 与操作和维护方法有关的需求;
j) 与IT-网络方面有关的需求:
注7:示例包括以下相关内容:
---已联网的报警、警告和操作者信息;
---网络协议;
---网络服务不可用时的处置。
k) 用户维护需求;
l) 法规要求。
注8:a)~l)中的需求可重叠。
[A、B、C级]
注9:所有这些需求在软件开发之初可能无法得到。
注10:在其他标准中,ISO/IEC 25010[14]提供可能对定义软件需求有用的质量特性信息。
5.2.3 将风险控制措施纳入软件需求
制造商应将在软件中实施的风险控制措施包含在适当的医疗器械软件需求中。[B、C级]
注:这些需求在软件开发之初可能无法得到,且可能随着软件的设计和风险控制措施的进一步确定而变化。
5.2.4 医疗器械风险分析的再评价
制造商应在建立了软件需求后对医疗器械风险分析进行再评价,并在适当时予以更新。
[A、B、C级]
5.2.5 更新需求
作为软件需求分析活动的结果,制造商应确保现有需求(包括系统需求)得到再评价,并在适当时予
以更新。[A、B、C级]
5.2.6 验证软件需求
制造商应对软件需求进行以下验证并形成文件:
a) 实现了系统需求,包括那些与风险控制有关的需求;
b) 彼此不互相矛盾;
c) 避免使用含糊不清的术语表述;
d) 以允许建立测试准则和实施测试的术语描述;
e) 可被唯一识别;
f) 可追溯至系统需求或其他来源。
[A、B、C级]
注:本标准不要求使用正式规范的语言。
5.3 *软件体系结构设计
5.3.1 将软件需求转换为体系结构
制造商应将对医疗器械软件的需求转换为形成文件的体系结构,该体系结构描述软件的结构并识
别所有软件项。[B、C级]
5.3.2 为软件项接口开发体系结构
制造商应为软件项与软件项的外部组件(软件和硬件)之间,以及软件项之间的接口开发一个体系
结构并将其形成文件。[B、C级]
5.3.3 规定未知来源软件项的功能和性能需求
如果软件项被识别为未知来源软件,制造商应规定未知来源软件项预期用途所必需的功能和性能
需求。[B、C级]
5.3.4 规定未知来源软件项所要求的系统硬件和软件
如果软件项被识别为未知来源软件,制造商应规定为支持未知来源软件项正常运行所必需的系统
硬件和软件。[B、C级]
注:示例包括处理器类型和速度、存储器类型和大小、系统软件类型、通信和显示软件需求。
5.3.5 确定风险控制所必需的隔离
制造商应确定风险控制所必需的软件项之间的任何隔离,并说明如何确保隔离有效。[C级]
注:一个隔离的示例是将软件项在不同的处理器上运行。隔离的有效性可通过处理器间不共享资源来保证。当软
件体系结构设计可确保有效性时,也可应用其他隔离手段(参见B.4.3)。
5.3.6 验证软件体系结构
制造商应验证下列各项并形成文件:
a) 软件体系结构实现系统和软件需求,包括与风险控制有关的需求;
b) 软件体系结构能够支持软件项之间、软件项与硬件之间的接口;
c) 医疗器械体系结构支持任何未知来源软件项的正常运行。
[B、C级]
注:可使用体系结构至软件需求的可追溯性分析来满足要求a)。
5.4 *软件详细设计
5.4.1 将软件细分为软件单元
制造商应将软件细分直至其呈现为软件单元。[B、C级]
注:某些软件系统未进一步细分。
5.4.2 为每个软件单元开发详细设计
制造商应形成具有足够细节的设计文件,以正确实现每个软件单元。[C级]
5.4.3 为接口开发详细设计
制造商应为软件单元与外部组件(硬件或软件)之间的任何接口,以及软件单元之间的任何接口形
成具有足够细节的设计文件,以正确实现每个软件单元及其接口。[C级]
5.4.4 验证详细设计
制造商应验证软件详细设计的下列各项并形成文件:
a) 是否实现软件体系结构;
b) ......
相关标准:     YY/T 0595-2020     YY/T 0616.7-2020

英文版PDF:   YY/T 0616.1-2016  YY/T0616.1  YYT0616.1   YY/T 0595-2020  YY/T0595  YYT0595   YY/T 0313-2014  YY/T0313  YYT0313   YY 1057-2016  YY 1057  YY1057
   
       隐私   ·  优质产品   ·  退款政策   ·  公平交易   ·  关于我们
宁德梧三商贸有限公司 (营业执照期限:2019-2049年. 纳税人识别号:91350900MA32WE2Q2X)
对公账号开户银行:中国建设银行 | 账户名称:宁德梧三商贸有限公司 | 账户号码:35050168730700000955
本公司专职于中国国家标准行业标准英文版