19.1 可编程医用电气系统(PEMS)文档自查表（GB9706.1-2020）2.docx

1、可编程医用电气系统(PEMS)自查表检验项目条款标准要求适用时：文件编号+文件名称+章节不适用：注明不适用理由GB 9706.1-2020医用电气设备 第1部分：基本安全和基本性能的通用要求文档14.2第14章要求的文档应按照正式的文档控制程序，进行评审、批准、发布和更改举例：见AABBCC软件开发生命周期计划，1章、文档控制程序。风险管理计划14.3按4.2.2形成的风险管理计划应包括对PEMS确认计划（见14.11）的引用PEMS开发生命周期14.4PEMS开发生命周期应文档化PEMS开发生命周期应当包含一组已定义的里程碑在每个里程碑，应确定将要完成的活动和验证这些活动的方法应确定每个活动

2、，包括其输入和输出每个里程碑应识别在此里程碑结束前一定有完成的风险管理活动应通过制定详细的活动、里程碑和进度表计划，来为特定的开发定制PEMS开发生命周期PEMS开发生命周期应包括对文档的要求问题解决14.5适当时，应在PEMS开发生命周期的所有阶段和活动内或相互间建立和维护一个文档化的问题解决体系风险管理过程已知和可预见危险的识别14.614.6.1在编制已知或可预见的危险（源）列表时，制造商应考虑那些与PEMS软件和硬件方面相关的危险（源），包括PEMS接入IT-网络、第三方来源组件和遗留子系统的危险（源）风险控制14.6.2为实现每个风险控制措施，应选择和确定合适的已确认的工具和程序。这

3、些工具和程序应适用于确保每个风险控制措施能有效地降低已识别的风险需求规格说明14.7对于PEMS及其各子系统（例如：PEMS），应有文档化的需求规格说明系统或者子系统的需求规格说明，应包含并区分由其自身实施的任何基本性能和任何风险控制措施体系结构14.8对于PEMS及其各子系统，应明确规定符合需求规格说明的体系结构设计和实现14.9适当时，设计应分解为各子系统，每个子系统都有设计和测试规格说明关于设计环境的描述数据应形成文档验证14.10所有实现基本安全、基本性能或风险控制措施的功能都需要得到验证应制定验证计划以表明这些功能是如何被验证的。计划应包括：在每个里程碑，对各个功能进行验证验证策略、

4、活动、技术及执行验证人员的适当独立程度的选择和形成文档验证工具的选择和运用验证的覆盖准则验证应根据验证计划执行。验证活动的结果应形成文档PEMS确认14.11PEMS确认计划应当包含基本安全和基本性能的确认PEMS确认采用的方法应形成文档应根据PEMS确认计划实施PEMS确认。PEMS确认活动的结果应形成文档全面负责PEMS确认的人员应独立于设计组。制造商应将独立性程度的解释说明形成文档设计组成员不应承担其自己设计部分的确认工作风险管理文档中应记录PEMS确认组成员和设计组成员之间的所有专业关系修改14.12如果任何部分或者全部设计是对早期设计的修改，则作为全新设计适用本章所有条款，或任何早期

5、设计文档的持续有效性应在文档化修改/更改程序下进行评估当软件被修改时，YY/T 06642008中的4.3，第5章、第7章第9章的要求也应适用于修改预期接入IT-网络的PEMS14.13如果PEMS预期接入未经PEMS制造商确认过的IT-网络，制造商为实现这样的连接应提供有效的说明，包括以下内容：a)PEMS连接到IT-网络的目的/举例：不适用，本产品无需接入IT-网络。b)与PEMS相连的IT-网络所要求的特性c)与PEMS相连的IT-网络所需的配置d)PEMS网络连接的技术规格说明，包括数据安全规格说明e)在PEMS，IT-网络和IT-网络上的其他设备间的预期信息流，以及预期通过IT-网络

6、的路由；和f)为达到PEMS与IT-网络连接目的所需特性的IT-网络失效时的危险情况清单在随附文件中，制造商应告知责任方：PEMS与包含其他设备的IT-网络的连接可能导致对患者、操作者、第三方带来以往没有识别的风险责任方宜识别、分析、评价和控制这些风险对IT-网络的后续修改可能引入新的风险，需要进行补充分析IT-网络的更改包括：IT-网络配置的更改与IT-网络连接的新增项与IT-网络连接中断的项与IT-网络连接的设备的更新与IT-网络连接的设备的升级YY/T 0664-2020 医疗器械软件 软件生存周期过程软件安全分级4.3软件安全分级应满足如下准则和要求:a)制造商应根据软件系统在最不利情

7、况下(如图3所示)促成的危险情况引发的对患者、操作者或其他人员伤害的风险，赋予每个软件系统一个软件安全级别(A、B或C)下列情况下软件系统的软件安全级别为A：软件系统不可能促成危险情况;或在考虑外部风险控制措施后，软件系统可能促成不导致不可接受风险的危险情况下列情况下软件系统的软件安全级别为B：在考虑外部风险控制措施后，软件系统可能促成导致不可接受风险的危险情况，且导致的可能伤害是非严重损伤下列情况下软件系统的软件安全级别为C：在考虑外部风险控制措施后，软件系统可能促成导致不可接受风险的危险情况，且导致的可能伤害是死亡或严重损伤对于最初分类为软件安全级别B或C的软件系统，制造商可以实施软件系统

8、外部附加风险控制措施(包括修改含有软件系统的系统体系结构)，并在随后为软件系统赋予新的软件安全级别b）制造商应在风险管理文档中将赋予每个软件系统的软件安全级别形成文件c)当一个软件系统分解为多个软件项，及当一个软件项又进一步分解为多个软件项时，此类软件项应继承原软件项(或软件系统)的软件安全级别，除非制造商以文件形式说明分类为不同软件安全级别的理由根据4.3a)用软件项替换软件系统赋予的软件安全级别。此类理由说明应解释新的软件项如何被隔离，以便可对其单独分级d)如果以分解方式产生的软件项的安全级别与其原软件项不同，制造商应将每个此类软件项的软件安全级别形成文件e)为符合本标准，当本标准应用于一

9、组软件项时，制造商应使用此组中级别最高的软件项所要求的诸过程和任务，除非制造商在风险管理文档中将使用较低级别的理由说明形成文件f)对每个软件系统，在赋予软件安全级别以前，均应应用C级要求软件开发策划软件开发计划5.15.1.1制造商应建立一项(或多项)软件开发计划，以便实施适合于拟开发软件系统的范围、规模和软件安全级别的软件开发过程相关活动。在计划中应完整地定义或引用软件开发生存周期模型计划应说明下列各项：a)用于软件系统开发的过程b)各项活动和任务的交付物(包括文档)c)系统需求、软件需求、软件系统测试以及在软件中实施的风险控制措施之间的可追溯性d)软件配置和变更管理,包括未知来源软件的配置

10、项和用于支持开发的软件e)软件问题解决方案，以处理在生弃周期各阶段的医疗器械软件，交付物和活动中所发现的问题保持对软件开发计划的更新5.1.2适当时，制造商应随着开发的进行更新计划引用系统设计和开发的软件开发计划5.1.3在软件开发计划中，制造商应a)引用系统需求，作为软件开发的输入b)包括或引用用于协调软件开发和系统开发所必需的规程以满足4.1的要求(例如系统的集成、验证和确认)软件开发标准、方法和工具的策划5.1.4制造商应在软件开发计划中包括或引用与C级软件项开发有关的:a)标准:b)方法c)工具软件集成和集成测试的策划5.1.5制造商应在软件开发计划中包括或引用一项计划，以集成软件项(

11、包括未知来源软件)并在集成过程中完成测试软件验证策划5.1.6制造商应在软件开发计划中包括或引用下列验证信息:a)要求验证的交付物b)每个生存周期活动所要求的验证任务c)对交付物讲行验证的里程碑硬d)验证交物的验收准则软件风险管理策划5.1.7制造商应在软件开发计划中包括或引用一项计划，以实施软件风险管理过程的活动和任务，包括与未知来源软件有关的风险的管理文档的策划5.1.8制造商应在软件开发计划中包括或引用有关在软件开发生存周期中要生成的文件的信息，对每个已识别的文件或文件类型，应包括或引用如下信息:a)标题、名称或命名约定b)目的c)开发、评审、批准和修改的规程和职责软件配置管理策划5.1

12、.9制造商应在软件开发计划中包括或引用软件配置管理信息，软件配置管理信息应包括或引用:a)拟受控项的级别、型式、类别或清单b)软件配置管理活动和任务c)负责实施软件配置管理活动的一个或多个组织d)这些组织和其他诸如软件开发或维护组织的关系e)何时将这些项目置于配置控制之下f)何时使用问题解决过程拟受控的支持项5.1.10拟受控项应包括用于医疗器械软件开发并对医疗器械软件可能有影响的工具、项目或设置验证前软件配置项的控制5.1.11制造商应进行策划以将软件配置项在验证之前置于配置管理控制之下识别和避免常见软件缺陷5.1.12制造商应在软件开发计划中包括或引用以下规程:a)基干所选的与其软件系统相

13、关的编程技术，识别可能引入的缺陷类别b)证实这些缺陷不会促成不可接受风险的形成文件的证据软件需求分析定义来自系统需求的软件需求并将其形成文件5.25.2.1对医疗器械的每个软件系统，制造商应定义来自系统级需求的软件系统需求并形成文件软件需求的内容5.2.2若适用于医疗器械软件，制造商应在软件需求中包括:a)功能和性能需求b)软件系统的输人和输出c)软件系统和其他系统之间的接口d)软件驱动的报警、警告和操作者信息e)信息安全需求f)由软件实现的用户界面需求g)数据定义和数据库需求h)已交付医疗器械软件在一个或多个操作和维护现场的安装和验收需求i)与操作和维护方面有关的需求j)与IT-网络方面有关

14、的需求k)用户维护需求1)法规要求将风险控制措施纳入软件需求5.2.3制造商应将在软件中实施的风险控制措施包含在适当的医疗器械软件需求中医疗器械风险分析的再评价5.2.4制造商应在建立了软件需求后对医疗器械风险分析进行再评价，并在适当时予以更新更新需求5.2.5作为软件需求分析活动的结果，制造商应确保现有需求(包括系统需求)得到再评价，并在适当时予以更新验证软件需求5.2.6制造商应对软件需求进行以下验证并形成文件:a)实现了系统需求，包括那些与风险控制有关的需求b)彼此不互相矛盾c)避免使用含糊不清的术语表述d)以允许建立测试准则和实施测试的术语描述e)可被唯一识别f)可追溯至系统需求或其他

15、来源软件体系结构设计将软件需求转换为体系结构5.35.3.1制造商应将对医疗器械软件的需求转换为形成文件的体系结构，该体系结构描述软件的结构并识别所有软件项为软件项接口开发体系结构5.3.2制造商应为软件项与软件项的外部组件(软件和硬件)之间，以及软件项之间的接口开发一个体系结构并将其形成文件规定未知来源软件项的功能和性能需求5.3.3如果软件项被识别为未知来源软件，制造商应规定未知来源软件项预期用途所必需的功能和性能需求规定未知来源软件项所要求的系统硬件和软件5.3.4如果软件项被识别为未知来源软件，制造商应规定为支持未知来源软件项正常运行所必需的系统硬件和软件确定风验控制所必需的隔离5.3

16、.5制造商应确定风险控制所必需的软件项之间的任何隔离，并说明如何确保隔离有效验证软件体系结构5.3.6制造商应验证下列各项并形成文件：a)软件体系结构实现系统和软件需求，包括与风险控制有关的需求b)软件体系结构能够支持软件项之间、软件项与硬件之间的接口c)医疗器械体系结构支持任何未知来源软件项的正常运行软件详细设计将软件细分为软件单元5.45.4.1制造商应将软件细分直至其呈现为软件单元为每个软件单元开发详细设计5.4.2制造商应形成具有足够细节的设计文件，以正确实现每个软件单元为接口开发详细设计5.4.3制造商应为软件单元与外部组件(硬件或软件)之间的任何接口，以及软件单元之间的任何接口形成

17、具有足够细节的设计文件，以正确实现每个软件单元及其接口验证详细设计5.4.4制造商应验证软件详细设计的下列各项并形成文件:a)是否实现软件体系结构b)是否与软件体系结构不相矛盾软件单元的实现实现每个软件单元5.55.5.1制造商应实现每个软件单元建立软件单元的验证过程5.5.2制造商应为验证软件单元建立策略、方法和规程。在通过测试进行验证时，应评价测试规程的充分性软件单元的验收准则5.5.3适当时，在集成为更大的软件项之前，制造商应为软件单元建立验收准则，并确保软件单元符合验收准则附加的软件单元验收准则5.5.4当下列各项在设计中出现，适当时，制造商应包括附加的验收准则:a)适当的事件序列b)

18、数据和控制流c)所计划的资源分配d)故障处理(错误界定、隔离和恢复)e)变量的初始化f)自我诊断g)存储管理和存储溢出h)边界条件软件单元的验证5.5.5制造商应实施软件单元验证并将结果形成文件软件集成和集成测试集成软件单元5.65.6.1制造商应按照集成计划(见5.1.5)集成软件单元验证软件集成5.6.2制造商应验证软件单元已经按照集成计划(见5.1.5)集成到软件项和/或软件系统中，并保留此验证证据的记录软件集成测试5.6.3制造商应按照集成计划(见5.1.5)测试集成后的软件项并将结果形成文件软件集成测试的内容5.6.4对于软件集成测试,制造商应阐明集成的软件项是否按预期运行评价软件集

19、成测试规程5.6.5制造商应评价集成测试规程的充分性进行回归测试5.6.6在软件项集成之后，制造商应进行适当的回归测试，以证实未将风险不可接受的缺陷引入到先前集成的软件中集成测试记录的内容5.6.7制造商应:a)将测试结果(通过/未通过和反常清单)形成文件b)保留充分的记录，以使测试可重复c)标明测试者的身份使用软件问题解决过程5.6.8制造商应将软件集成和集成测试期间所发现的反常输人到软件问题解决过程软件系统测试为软件需求建立测试项5.75.7.1制造商应:a)为软件系统测试建立并实施一组测试，表达为输入触发、预期输出、通过/未通过准则和规程，并覆盖全部软件需求b)评价验证策略和测试规程的充

20、分性使用软件问题解决过程5.7.2制造商应将软件系统测试期间所发现的反常输入到软件问题解决过程变更后再测5.7.3当在软件系统测试期间做出变更时，制造商应：a)适当时，重复测试、实施经修改的测试或附加的测试，以验证纠正问题时所作变更的有效性b)进行适当的测试，以证实没有引入非预期的副作用c)实施7.4中规定的有关风险管理活动评价软件系统测试5.7.4制造商应评价验证策略和测试规程的适宜性制造商应验证：a)所有的软件需求均经测试或以其他方式验证b)软件需求与测试或其他验证之间的可追溯性均已记录c)测试结果满足所要求的通过/未通过准则软件系统测试记录的内容5.7.5为支持测试的可重复性，制造商应将

21、以下内容形成文件:a)引用的测试用例规程，该规程体现所要求的行动和预期结果b)测试结果(通过/未通过和反常清单)c)被测试软件的版本d)相关硬件和软件测试配置e)相关测试工具f)测试日期g)负责执行测试和记录测试结果的人员的身份软件在系统级别应用的发布确保软件验证的完成5.85.8.1制造商应确保在软件发布之前已完成所有软件验证活动且已对其结果进行评价将已知的剩余反常形成文件5.8.2制造商应将所有已知的剩余反常形成文件评价已知的剩余反常5.8.3制造商应确保所有已知的剩余反常均得到评价，以确保其不会促成不可接受的风险将所发布的版本形成文件5.8.4制造商应将要发布的医疗器械软件版本形成文件将

22、所发布软件的创建过程形成文件5.8.5制造商应将用创建所发布软件的规程和环境形成文件确保活动和任务的完成5.8.6制造商应确保所有软件开发计划（或维护计划）中的活动和任务以及相关文档均完整齐全将软件归档5.8.7制造商应将下列内容归档：a)医疗器械软件和配置项b)文档存档时间至少为制造商规定的医疗器械软件寿命期或有关法规要求规定的时间中较长者确保所发布软件的可靠交付5.8.8制造商应建立规程，以确保所发布的医疗器械软件能够可靠地交付到使用地点,而无损毁或未授权的变更。这些规程应说明包含医疗器械软件的媒介的生产和处置情况，适当时，包括:复制媒介标记包装防护存储交付软件风险管理过程促成危险情况的软

23、件分析识别可能促成危险情况的软件项77.17.1.1制造商应识别可能促成危险情况的软件项，危险情况在YY/T 0316的医疗器械风险分析活动(见4.2)中已识别识别促成危险情况的潜在原因7.1.2制造商应识别上文所识别软件项促成危险情况的潜在原因适当时，制造商应考虑的潜在原因包括:a)不正确的或不完整的功能性规范b)所识别的软件项功能性方面的软件缺陷c)来自未知来源软件的失效或非预期结果d)可能导致不可预知的软件运行的硬件失效或其他软件缺陷e)可合理预见的误使用评价已公开的未知来源软件反常清单7.1.3如果源于未知来源软件的失效或非预期结果是软件项促成危险情况的潜在原因,制造商至少应评价由供应

24、商公开的、与在医疗器械中使用版本的未知来源软件项有关的任何反常清单，以确定是否有任何已知的反常导致了可能促成危险情况的事件序列将潜在原因形成文件7.1.4制造商应在风险管理文档中将软件项促成危险情况的潜在原因形成文件(见YY/T 0316)风险控制措施确定风险控制措施7.27.2.1对在风险管理文档中形成文件的软件项可能促成危险情况的每一种情况，制造商应按照YY/T 0316规定风险控制措施并形成文件在软件中实施的风险控制措施7.2.2如果风险控制措施作为软件项功能的一部分来实施，制造商应：a)在软件需求中包括风险控制措施b)基于风险控制措施所控制的风险见4.3 a)，为有助于风险控制措施实施

25、的每个软件项赋予软件安全级别c)按照第5章开发软件项风险控制措施的验证验证风险控制措施7.37.3.1应对在7.2中形成文件的每个风险控制措施的实施进行验证并形成文件。制造商应评审风险控制措施，并确定其是否可能导致新的危险情况将可追溯性形成文件7.3.2制造商应将软件危险(源)的可追溯性形成文件，适当时包括:a)从危险情况到软件项b)从软件项到特定的软件原因c)从软件原因到风险控制措施d)从风险控制措施到风险控制措施的验证软件变更的风险管理分析与医疗器械软件安全相关的变更7.47.4.1制造商应分析对医疗器械软件(包括未知来源软件)的变更以确定是否:a)引入了促成危险情况另外的潜在原因b)需要

26、附加的软件风险控制措施分析软件变更对现有风险控制措施的影响7.4.2制造商应分析对软件的变更，包括对未知来源软件的变更，以确定软件修改是否可能干扰现有的风险控制措施基于分析实施风险管理活动7.4.3制造商应在这些分析的基础上实施7.1、7.2和7.3中所确定的相关风险管理活动软件配置管理过程配置标识建立标识配置项的方法88.18.1.1制造商应根据5.1规定的开发和配置策划为拟受控的配置项及其版本的唯一性标识建立一个方案标识未知来源软件8.1.2对于拟使用的每个未知来源软件配置项，包括标准库，制造商应将以下各项形成文件：a)标题b)制造商c)未知来源软件的唯一标识符标识系经配置文档8.1.3制造商应将组成软件系统配置的一组配置项及其版本形成文件变更控制批准变更请求8.28.2.1制造商应仅在对经批准的变更请求作出响应时才对按照8.1标识的需受控的配置项进行变更实施变更8.2.2制造商应按变更请求中的规定实施变更。制造商应识别并实施因变更而需要重复的任何活动，包括对软件系统和软件项的软件安全级别的变更验证变更8.2.3制造商应验证变更，包括重复因变更而失效的任何验证，并考虑5.7.3和9.7为变更的可追溯性规定方法8.2.4制造商应保持以下各项之间关系和依赖性的记录:a)变更请求b)有关的问题报告c)变更请求的批准配置状态报告8.3制造商应保留包括系统配置在内的受控