|
检验项目 |
条款 |
标准要求 |
适用时：文件编号+文件名称+章节 |
不适用：注明不适用理由 |
|
GB 9706.1-2020医用电气设备 第1部分：基本安全和基本性能的通用要求 |
|
文档 |
14.2 |
第14章要求的文档应按照正式的文档控制程序，进行评审、批准、发布和更改 |
举例：见AABBCC软件开发生命周期计划，1章、文档控制程序。 |
|
|
风险管理计划 |
14.3 |
按4.2.2形成的风险管理计划应包括对PEMS确认计划（见14.11）的引用 |
|
|
|
PEMS开发生命周期 |
14.4 |
PEMS开发生命周期应文档化 |
|
|
|
PEMS开发生命周期应当包含一组已定义的里程碑 |
|
|
|
在每个里程碑，应确定将要完成的活动和验证这些活动的方法 |
|
|
|
应确定每个活动，包括其输入和输出 |
|
|
|
每个里程碑应识别在此里程碑结束前一定有完成的风险管理活动 |
|
|
|
应通过制定详细的活动、里程碑和进度表计划，来为特定的开发定制PEMS开发生命周期 |
|
|
|
PEMS开发生命周期应包括对文档的要求 |
|
|
问题解决
|
14.5 |
适当时，应在PEMS开发生命周期的所有阶段和活动内或相互间建立和维护一个文档化的问题解决体系 |
|
|
风险管理过程
已知和可预见危险的识别 |
14.6
14.6.1 |
在编制已知或可预见的危险（源）列表时，制造商应考虑那些与PEMS软件和硬件方面相关的危险（源），包括PEMS接入IT-网络、第三方来源组件和遗留子系统的危险（源） |
|
|
|
风险控制 |
14.6.2 |
为实现每个风险控制措施，应选择和确定合适的已确认的工具和程序。这些工具和程序应适用于确保每个风险控制措施能有效地降低已识别的风险 |
|
|
|
需求规格说明 |
14.7 |
对于PEMS及其各子系统（例如：PEMS），应有文档化的需求规格说明 |
|
|
|
系统或者子系统的需求规格说明，应包含并区分由其自身实施的任何基本性能和任何风险控制措施 |
|
|
|
体系结构 |
14.8 |
对于PEMS及其各子系统，应明确规定符合需求规格说明的体系结构 |
|
|
|
设计和实现 |
14.9 |
适当时，设计应分解为各子系统，每个子系统都有设计和测试规格说明 |
|
|
|
关于设计环境的描述数据应形成文档 |
|
|
|
验证 |
14.10 |
所有实现基本安全、基本性能或风险控制措施的功能都需要得到验证 |
|
|
应制定验证计划以表明这些功能是如何被验证的。计划应包括：
——在每个里程碑，对各个功能进行验证 |
|
|
|
——验证策略、活动、技术及执行验证人员的适当独立程度的选择和形成文档 |
|
|
|
——验证工具的选择和运用 |
|
|
|
——验证的覆盖准则 |
|
|
|
验证应根据验证计划执行。验证活动的结果应形成文档 |
|
|
|
PEMS确认 |
14.11
|
PEMS确认计划应当包含基本安全和基本性能的确认 |
|
|
|
PEMS确认采用的方法应形成文档 |
|
|
|
应根据PEMS确认计划实施PEMS确认。PEMS确认活动的结果应形成文档 |
|
|
|
全面负责PEMS确认的人员应独立于设计组。制造商应将独立性程度的解释说明形成文档 |
|
|
|
设计组成员不应承担其自己设计部分的确认工作 |
|
|
|
风险管理文档中应记录PEMS确认组成员和设计组成员之间的所有专业关系 |
|
|
|
修改 |
14.12 |
如果任何部分或者全部设计是对早期设计的修改，则作为全新设计适用本章所有条款，或任何早期设计文档的持续有效性应在文档化修改/更改程序下进行评估 |
|
|
|
当软件被修改时，YY/T 0664—2008中的4.3，第5章、第7章～第9章的要求也应适用于修改 |
|
|
|
预期接入IT-网络的PEMS |
14.13 |
如果PEMS预期接入未经PEMS制造商确认过的IT-网络，制造商为实现这样的连接应提供有效的说明，包括以下内容：
a)PEMS连接到IT-网络的目的 |
/ |
举例：不适用，本产品无需接入IT-网络。 |
|
b)与PEMS相连的IT-网络所要求的特性 |
|
|
|
c)与PEMS相连的IT-网络所需的配置 |
|
|
|
d)PEMS网络连接的技术规格说明，包括数据安全规格说明 |
|
|
|
e)在PEMS，IT-网络和IT-网络上的其他设备间的预期信息流，以及预期通过IT-网络的路由；和 |
|
|
|
f)为达到PEMS与IT-网络连接目的所需特性的IT-网络失效时的危险情况清单 |
|
|
在随附文件中，制造商应告知责任方：
——PEMS与包含其他设备的IT-网络的连接可能导致对患者、操作者、第三方带来以往没有识别的风险 |
|
|
|
——责任方宜识别、分析、评价和控制这些风险 |
|
|
|
——对IT-网络的后续修改可能引入新的风险，需要进行补充分析 |
|
|
——IT-网络的更改包括：
•IT-网络配置的更改 |
|
|
|
•与IT-网络连接的新增项 |
|
|
|
•与IT-网络连接中断的项 |
|
|
|
•与IT-网络连接的设备的更新 |
|
|
|
•与IT-网络连接的设备的升级 |
|
|
YY/T 0664-2020 医疗器械软件 软件生存周期过程 |
|
软件安全分级 |
4.3 |
软件安全分级应满足如下准则和要求:
a)制造商应根据软件系统在最不利情况下(如图3所示)促成的危险情况引发的对患者、操作者或其他人员伤害的风险，赋予每个软件系统一个软件安全级别(A、B或C) |
|
|
下列情况下软件系统的软件安全级别为A：
——软件系统不可能促成危险情况;或 |
|
|
|
——在考虑外部风险控制措施后，软件系统可能促成不导致不可接受风险的危险情况 |
|
|
下列情况下软件系统的软件安全级别为B：
——在考虑外部风险控制措施后，软件系统可能促成导致不可接受风险的危险情况，且导致的可能伤害是非严重损伤 |
|
|
下列情况下软件系统的软件安全级别为C：
——在考虑外部风险控制措施后，软件系统可能促成导致不可接受风险的危险情况，且导致的可能伤害是死亡或严重损伤 |
|
|
|
对于最初分类为软件安全级别B或C的软件系统，制造商可以实施软件系统外部附加风险控制措施(包括修改含有软件系统的系统体系结构)，并在随后为软件系统赋予新的软件安全级别 |
|
|
|
b）制造商应在风险管理文档中将赋予每个软件系统的软件安全级别形成文件 |
|
|
|
c)当一个软件系统分解为多个软件项，及当一个软件项又进一步分解为多个软件项时，此类软件项应继承原软件项(或软件系统)的软件安全级别，除非制造商以文件形式说明分类为不同软件安全级别的理由[根据4.3a)用"软件项"替换"软件系统"赋予的软件安全级别]。此类理由说明应解释新的软件项如何被隔离，以便可对其单独分级 |
|
|
|
d)如果以分解方式产生的软件项的安全级别与其原软件项不同，制造商应将每个此类软件项的软件安全级别形成文件 |
|
|
|
e)为符合本标准，当本标准应用于一组软件项时，制造商应使用此组中级别最高的软件项所要求的诸过程和任务，除非制造商在风险管理文档中将使用较低级别的理由说明形成文件 |
|
|
|
f)对每个软件系统，在赋予软件安全级别以前，均应应用C级要求 |
|
|
软件开发策划
软件开发计划 |
5.1
5.1.1 |
制造商应建立一项(或多项)软件开发计划，以便实施适合于拟开发软件系统的范围、规模和软件安全级别的软件开发过程相关活动。在计划中应完整地定义或引用软件开发生存周期模型 |
|
|
计划应说明下列各项：
a)用于软件系统开发的过程 |
|
|
|
b)各项活动和任务的交付物(包括文档) |
|
|
|
c)系统需求、软件需求、软件系统测试以及在软件中实施的风险控制措施之间的可追溯性 |
|
|
|
d)软件配置和变更管理,包括未知来源软件的配置项和用于支持开发的软件 |
|
|
|
e)软件问题解决方案，以处理在生弃周期各阶段的医疗器械软件，交付物和活动中所发现的问题 |
|
|
|
保持对软件开发计划的更新 |
5.1.2 |
适当时，制造商应随着开发的进行更新计划 |
|
|
|
引用系统设计和开发的软件开发计划 |
5.1.3 |
在软件开发计划中，制造商应
a)引用系统需求，作为软件开发的输入 |
|
|
|
b)包括或引用用于协调软件开发和系统开发所必需的规程以满足4.1的要求(例如系统的集成、验证和确认) |
|
|
|
软件开发标准、方法和工具的策划 |
5.1.4 |
制造商应在软件开发计划中包括或引用与C级软件项开发有关的:
a)标准: |
|
|
|
b)方法 |
|
|
|
c)工具 |
|
|
|
软件集成和集成测试的策划 |
5.1.5 |
制造商应在软件开发计划中包括或引用一项计划，以集成软件项(包括未知来源软件)并在集成过程中完成测试 |
|
|
|
软件验证策划 |
5.1.6 |
制造商应在软件开发计划中包括或引用下列验证信息:
a)要求验证的交付物 |
|
|
|
b)每个生存周期活动所要求的验证任务 |
|
|
|
c)对交付物讲行验证的里程碑硬 |
|
|
|
d)验证交物的验收准则 |
|
|
|
软件风险管理策划 |
5.1.7 |
制造商应在软件开发计划中包括或引用一项计划，以实施软件风险管理过程的活动和任务，包括与未知来源软件有关的风险的管理 |
|
|
|
文档的策划 |
5.1.8 |
制造商应在软件开发计划中包括或引用有关在软件开发生存周期中要生成的文件的信息，对每个已识别的文件或文件类型，应包括或引用如下信息:
a)标题、名称或命名约定 |
|
|
|
b)目的 |
|
|
|
c)开发、评审、批准和修改的规程和职责 |
|
|
|
软件配置管理策划 |
5.1.9 |
制造商应在软件开发计划中包括或引用软件配置管理信息，软件配置管理信息应包括或引用:
a)拟受控项的级别、型式、类别或清单 |
|
|
|
b)软件配置管理活动和任务 |
|
|
|
c)负责实施软件配置管理活动的一个或多个组织 |
|
|
|
d)这些组织和其他诸如软件开发或维护组织的关系 |
|
|
|
e)何时将这些项目置于配置控制之下 |
|
|
|
f)何时使用问题解决过程 |
|
|
|
拟受控的支持项 |
5.1.10 |
拟受控项应包括用于医疗器械软件开发并对医疗器械软件可能有影响的工具、项目或设置 |
|
|
|
验证前软件配置项的控制 |
5.1.11 |
制造商应进行策划以将软件配置项在验证之前置于配置管理控制之下 |
|
|
|
识别和避免常见软件缺陷 |
5.1.12 |
制造商应在软件开发计划中包括或引用以下规程:
a)基干所选的与其软件系统相关的编程技术，识别可能引入的缺陷类别 |
|
|
|
b)证实这些缺陷不会促成不可接受风险的形成文件的证据 |
|
|
软件需求分析
定义来自系统需求的软件需求并将其形成文件 |
5.2
5.2.1 |
对医疗器械的每个软件系统，制造商应定义来自系统级需求的软件系统需求并形成文件 |
|
|
|
软件需求的内容 |
5.2.2 |
若适用于医疗器械软件，制造商应在软件需求中包括:
a)功能和性能需求 |
|
|
|
b)软件系统的输人和输出 |
|
|
|
c)软件系统和其他系统之间的接口 |
|
|
|
d)软件驱动的报警、警告和操作者信息 |
|
|
|
e)信息安全需求 |
|
|
|
f)由软件实现的用户界面需求 |
|
|
|
g)数据定义和数据库需求 |
|
|
|
h)已交付医疗器械软件在一个或多个操作和维护现场的安装和验收需求 |
|
|
|
i)与操作和维护方面有关的需求 |
|
|
|
j)与IT-网络方面有关的需求 |
|
|
|
k)用户维护需求 |
|
|
|
1)法规要求 |
|
|
|
将风险控制措施纳入软件需求 |
5.2.3 |
制造商应将在软件中实施的风险控制措施包含在适当的医疗器械软件需求中 |
|
|
|
医疗器械风险分析的再评价 |
5.2.4 |
制造商应在建立了软件需求后对医疗器械风险分析进行再评价，并在适当时予以更新 |
|
|
|
更新需求 |
5.2.5 |
作为软件需求分析活动的结果，制造商应确保现有需求(包括系统需求)得到再评价，并在适当时予以更新 |
|
|
|
验证软件需求 |
5.2.6 |
制造商应对软件需求进行以下验证并形成文件:
a)实现了系统需求，包括那些与风险控制有关的需求 |
|
|
|
b)彼此不互相矛盾 |
|
|
|
c)避免使用含糊不清的术语表述 |
|
|
|
d)以允许建立测试准则和实施测试的术语描述 |
|
|
|
e)可被唯一识别 |
|
|
|
f)可追溯至系统需求或其他来源 |
|
|
软件体系结构设计
将软件需求转换为体系结构 |
5.3
5.3.1 |
制造商应将对医疗器械软件的需求转换为形成文件的体系结构，该体系结构描述软件的结构并识别所有软件项 |
|
|
|
为软件项接口开发体系结构 |
5.3.2 |
制造商应为软件项与软件项的外部组件(软件和硬件)之间，以及软件项之间的接口开发一个体系结构并将其形成文件 |
|
|
|
规定未知来源软件项的功能和性能需求 |
5.3.3 |
如果软件项被识别为未知来源软件，制造商应规定未知来源软件项预期用途所必需的功能和性能需求 |
|
|
|
规定未知来源软件项所要求的系统硬件和软件 |
5.3.4 |
如果软件项被识别为未知来源软件，制造商应规定为支持未知来源软件项正常运行所必需的系统硬件和软件 |
|
|
|
确定风验控制所必需的隔离 |
5.3.5 |
制造商应确定风险控制所必需的软件项之间的任何隔离，并说明如何确保隔离有效 |
|
|
|
验证软件体系结构 |
5.3.6 |
制造商应验证下列各项并形成文件：
a)软件体系结构实现系统和软件需求，包括与风险控制有关的需求 |
|
|
|
b)软件体系结构能够支持软件项之间、软件项与硬件之间的接口 |
|
|
|
c)医疗器械体系结构支持任何未知来源软件项的正常运行 |
|
|
软件详细设计
将软件细分为软件单元 |
5.4
5.4.1 |
制造商应将软件细分直至其呈现为软件单元 |
|
|
|
为每个软件单元开发详细设计 |
5.4.2 |
制造商应形成具有足够细节的设计文件，以正确实现每个软件单元 |
|
|
|
为接口开发详细设计 |
5.4.3 |
制造商应为软件单元与外部组件(硬件或软件)之间的任何接口，以及软件单元之间的任何接口形成具有足够细节的设计文件，以正确实现每个软件单元及其接口 |
|
|
|
验证详细设计 |
5.4.4 |
制造商应验证软件详细设计的下列各项并形成文件:
a)是否实现软件体系结构 |
|
|
|
b)是否与软件体系结构不相矛盾 |
|
|
软件单元的实现
实现每个软件单元 |
5.5
5.5.1 |
制造商应实现每个软件单元 |
|
|
|
建立软件单元的验证过程 |
5.5.2 |
制造商应为验证软件单元建立策略、方法和规程。在通过测试进行验证时，应评价测试规程的充分性 |
|
|
|
软件单元的验收准则 |
5.5.3 |
适当时，在集成为更大的软件项之前，制造商应为软件单元建立验收准则，并确保软件单元符合验收准则 |
|
|
|
附加的软件单元验收准则 |
5.5.4 |
当下列各项在设计中出现，适当时，制造商应包括附加的验收准则:
a)适当的事件序列 |
|
|
|
b)数据和控制流 |
|
|
|
c)所计划的资源分配 |
|
|
|
d)故障处理(错误界定、隔离和恢复) |
|
|
|
e)变量的初始化 |
|
|
|
f)自我诊断 |
|
|
|
g)存储管理和存储溢出 |
|
|
|
h)边界条件 |
|
|
|
软件单元的验证 |
5.5.5 |
制造商应实施软件单元验证并将结果形成文件 |
|
|
软件集成和集成测试
集成软件单元 |
5.6
5.6.1 |
制造商应按照集成计划(见5.1.5)集成软件单元 |
|
|
|
验证软件集成 |
5.6.2 |
制造商应验证软件单元已经按照集成计划(见5.1.5)集成到软件项和/或软件系统中，并保留此验证证据的记录 |
|
|
|
软件集成测试 |
5.6.3 |
制造商应按照集成计划(见5.1.5)测试集成后的软件项并将结果形成文件 |
|
|
|
软件集成测试的内容 |
5.6.4 |
对于软件集成测试,制造商应阐明集成的软件项是否按预期运行 |
|
|
|
评价软件集成测试规程 |
5.6.5 |
制造商应评价集成测试规程的充分性 |
|
|
|
进行回归测试 |
5.6.6 |
在软件项集成之后，制造商应进行适当的回归测试，以证实未将风险不可接受的缺陷引入到先前集成的软件中 |
|
|
|
集成测试记录的内容 |
5.6.7 |
制造商应:
a)将测试结果(通过/未通过和反常清单)形成文件 |
|
|
|
b)保留充分的记录，以使测试可重复 |
|
|
|
c)标明测试者的身份 |
|
|
|
使用软件问题解决过程 |
5.6.8 |
制造商应将软件集成和集成测试期间所发现的反常输人到软件问题解决过程 |
|
|
软件系统测试
为软件需求建立测试项 |
5.7
5.7.1 |
制造商应:
a)为软件系统测试建立并实施一组测试，表达为输入触发、预期输出、通过/未通过准则和规程，并覆盖全部软件需求 |
|
|
|
b)评价验证策略和测试规程的充分性 |
|
|
|
使用软件问题解决过程 |
5.7.2 |
制造商应将软件系统测试期间所发现的反常输入到软件问题解决过程 |
|
|
|
变更后再测 |
5.7.3 |
当在软件系统测试期间做出变更时，制造商应：
a)适当时，重复测试、实施经修改的测试或附加的测试，以验证纠正问题时所作变更的有效性 |
|
|
|
b)进行适当的测试，以证实没有引入非预期的副作用 |
|
|
|
c)实施7.4中规定的有关风险管理活动 |
|
|
|
评价软件系统测试 |
5.7.4 |
制造商应评价验证策略和测试规程的适宜性 |
|
|
制造商应验证：
a)所有的软件需求均经测试或以其他方式验证 |
|
|
|
b)软件需求与测试或其他验证之间的可追溯性均已记录 |
|
|
|
c)测试结果满足所要求的通过/未通过准则 |
|
|
|
软件系统测试记录的内容 |
5.7.5 |
为支持测试的可重复性，制造商应将以下内容形成文件:
a)引用的测试用例规程，该规程体现所要求的行动和预期结果 |
|
|
|
b)测试结果(通过/未通过和反常清单) |
|
|
|
c)被测试软件的版本 |
|
|
|
d)相关硬件和软件测试配置 |
|
|
|
e)相关测试工具 |
|
|
|
f)测试日期 |
|
|
|
g)负责执行测试和记录测试结果的人员的身份 |
|
|
软件在系统级别应用的发布
确保软件验证的完成 |
5.8
5.8.1 |
制造商应确保在软件发布之前已完成所有软件验证活动且已对其结果进行评价 |
|
|
|
将已知的剩余反常形成文件 |
5.8.2 |
制造商应将所有已知的剩余反常形成文件 |
|
|
|
评价已知的剩余反常 |
5.8.3 |
制造商应确保所有已知的剩余反常均得到评价，以确保其不会促成不可接受的风险 |
|
|
|
将所发布的版本形成文件 |
5.8.4 |
制造商应将要发布的医疗器械软件版本形成文件 |
|
|
|
将所发布软件的创建过程形成文件 |
5.8.5 |
制造商应将用创建所发布软件的规程和环境形成文件 |
|
|
|
确保活动和任务的完成 |
5.8.6 |
制造商应确保所有软件开发计划（或维护计划）中的活动和任务以及相关文档均完整齐全 |
|
|
|
将软件归档 |
5.8.7 |
制造商应将下列内容归档：
a)医疗器械软件和配置项 |
|
|
|
b)文档 |
|
|
|
存档时间至少为制造商规定的医疗器械软件寿命期或有关法规要求规定的时间中较长者 |
|
|
|
确保所发布软件的可靠交付 |
5.8.8 |
制造商应建立规程，以确保所发布的医疗器械软件能够可靠地交付到使用地点,而无损毁或未授权的变更。这些规程应说明包含医疗器械软件的媒介的生产和处置情况，适当时，包括:
——复制 |
|
|
|
——媒介标记 |
|
|
|
——包装 |
|
|
|
——防护 |
|
|
|
——存储 |
|
|
|
——交付 |
|
|
软件风险管理过程
促成危险情况的软件分析
识别可能促成危险情况的软件项 |
7
7.1
7.1.1 |
制造商应识别可能促成危险情况的软件项，危险情况在YY/T 0316的医疗器械风险分析活动(见4.2)中已识别 |
|
|
|
识别促成危险情况的潜在原因 |
7.1.2 |
制造商应识别上文所识别软件项促成危险情况的潜在原因 |
|
|
适当时，制造商应考虑的潜在原因包括:
a)不正确的或不完整的功能性规范 |
|
|
|
b)所识别的软件项功能性方面的软件缺陷 |
|
|
|
c)来自未知来源软件的失效或非预期结果 |
|
|
|
d)可能导致不可预知的软件运行的硬件失效或其他软件缺陷 |
|
|
|
e)可合理预见的误使用 |
|
|
|
评价已公开的未知来源软件反常清单 |
7.1.3 |
如果源于未知来源软件的失效或非预期结果是软件项促成危险情况的潜在原因,制造商至少应评价由供应商公开的、与在医疗器械中使用版本的未知来源软件项有关的任何反常清单，以确定是否有任何已知的反常导致了可能促成危险情况的事件序列 |
|
|
|
将潜在原因形成文件 |
7.1.4 |
制造商应在风险管理文档中将软件项促成危险情况的潜在原因形成文件(见YY/T 0316) |
|
|
风险控制措施
确定风险控制措施 |
7.2
7.2.1 |
对在风险管理文档中形成文件的软件项可能促成危险情况的每一种情况，制造商应按照YY/T 0316规定风险控制措施并形成文件 |
|
|
|
在软件中实施的风险控制措施 |
7.2.2 |
如果风险控制措施作为软件项功能的一部分来实施，制造商应：
a)在软件需求中包括风险控制措施 |
|
|
|
b)基于风险控制措施所控制的风险[见4.3 a)]，为有助于风险控制措施实施的每个软件项赋予软件安全级别 |
|
|
|
c)按照第5章开发软件项 |
|
|
风险控制措施的验证
验证风险控制措施 |
7.3
7.3.1 |
应对在7.2中形成文件的每个风险控制措施的实施进行验证并形成文件。制造商应评审风险控制措施，并确定其是否可能导致新的危险情况 |
|
|
|
将可追溯性形成文件 |
7.3.2 |
制造商应将软件危险(源)的可追溯性形成文件，适当时包括:
a)从危险情况到软件项 |
|
|
|
b)从软件项到特定的软件原因 |
|
|
|
c)从软件原因到风险控制措施 |
|
|
|
d)从风险控制措施到风险控制措施的验证 |
|
|
软件变更的风险管理
分析与医疗器械软件安全相关的变更 |
7.4
7.4.1 |
制造商应分析对医疗器械软件(包括未知来源软件)的变更以确定是否:
a)引入了促成危险情况另外的潜在原因 |
|
|
|
b)需要附加的软件风险控制措施 |
|
|
|
分析软件变更对现有风险控制措施的影响 |
7.4.2 |
制造商应分析对软件的变更，包括对未知来源软件的变更，以确定软件修改是否可能干扰现有的风险控制措施 |
|
|
|
基于分析实施风险管理活动 |
7.4.3 |
制造商应在这些分析的基础上实施7.1、7.2和7.3中所确定的相关风险管理活动 |
|
|
软件配置管理过程
配置标识
建立标识配置项的方法 |
8
8.1
8.1.1 |
制造商应根据5.1规定的开发和配置策划为拟受控的配置项及其版本的唯一性标识建立一个方案 |
|
|
|
标识未知来源软件 |
8.1.2 |
对于拟使用的每个未知来源软件配置项，包括标准库，制造商应将以下各项形成文件：
a)标题 |
|
|
|
b)制造商 |
|
|
|
c)未知来源软件的唯一标识符 |
|
|
|
标识系经配置文档 |
8.1.3 |
制造商应将组成软件系统配置的一组配置项及其版本形成文件 |
|
|
变更控制
批准变更请求 |
8.2
8.2.1 |
制造商应仅在对经批准的变更请求作出响应时才对按照8.1标识的需受控的配置项进行变更 |
|
|
|
实施变更 |
8.2.2 |
制造商应按变更请求中的规定实施变更。制造商应识别并实施因变更而需要重复的任何活动，包括对软件系统和软件项的软件安全级别的变更 |
|
|
|
验证变更 |
8.2.3 |
制造商应验证变更，包括重复因变更而失效的任何验证，并考虑5.7.3和9.7 |
|
|
|
为变更的可追溯性规定方法 |
8.2.4 |
制造商应保持以下各项之间关系和依赖性的记录:
a)变更请求 |
|
|
|
b)有关的问题报告 |
|
|
|
c)变更请求的批准 |
|
|
|
配置状态报告 |
8.3 |
制造商应保留包括系统配置在内的受控配置项历史的可检索记录 |
|
|
软件问题解决过程
编写问题报告 |
9
9.1 |
制造商应为医疗器械软件中发现的每个问题编写问题报告 |
|
|
|
问题报告应包括严重程度的说明(例如，对性能、安全或信息安全的影响)以及可能有助于解决问题的其他信息(例如，受影响的器械和受影响的支持性附件) |
|
|
|
调查问题 |
9.2 |
制造商应:
a)调查问题并在可能时识别问题的原因 |
|
|
|
b)利用软件风险管理过程评价问题与安全的相关性(见第7章) |
|
|
|
c)将调查和评价的结果形成文件 |
|
|
|
d)为纠正问题所需的措施创建一个或多个变更请求，或将不采取措施的理由形成文件 |
|
|
|
通知相关方 |
9.3 |
适当时，制造商应将存在的问题通知相关方 |
|
|
|
使用变更控制过程 |
9.4 |
制造商应按照变更控制过程的要求(见8.2)批准并实施所有变更请求 |
|
|
|
保持记录 |
9.5 |
制造商应保持问题报告及其解决情况的记录，包括对其验证的记录 |
|
|
|
适当时,制造商应更新风险管理文档 |
|
|
|
分析问题的趋势 |
9.6 |
制造商应对问题报告进行分析以从中发现问题的趋势 |
|
|
|
验证软件问题的解决 |
9.7 |
制造商应验证问题的解决以确定是否:
a)问题已得到解决，问题报告已关闭 |
|
|
|
b)不良趋势已得到扭转 |
|
|
|
c)变更请求已在适当的医疗器械软件和活动中实施 |
|
|
|
d)引人了其他问题 |
|
|
|
测试文档的内容 |
9.8 |
当在一项变更之后测试、再测试或回归测试软件项和系统时，制造商应在测试文档中包括:
a)测试结果 |
|
|
|
b)发现的反常 |
|
|
|
c)所测试软件的版本 |
|
|
|
d)相关硬件和软件的测试配置 |
|
|
|
e)相关的测试工具 |
|
|
|
f)测试日期 |
|
|
|
g)测试者的身份 |
|
|
