A级医疗器械软件生存周期评估报告标准要求.docx

1、A级医疗器械软件生存周期评估报告标准要求软件生存周期评估报告1、评价对象2、执行标准YY/T 0664-2008 IDT IEC 62034:20063、评价过程根据标准的第项评价，软件安全等级为 A,适用条款见下表 A级序列。具体细节见下页:举 和 条A饗X*坝弟四章全辭fl!求XXX5. 1 &!. kS. I.lk5. frXXX.1 & &. I. 10 . 1. L1XX丄L 1Xi 2 5, 2. Z 監監轧2,$* 2. 5XX冥5” 2. 3XX5. 3 x 3, 1 二 U 工 Ll.k 3- 4 3-1 6XX乩3. &X5. 4 5. 1, 1X冥工 I. 2.Sa 1.

2、3,5. 1, 4X工 二 S. 1XXX5. S. 2 S.XXX$X乩E 仝萍鉴审XXS.7 金澤吿审X冥久吕 5. S. 1XXXIl S. r S- K. 2,5. a 1.5 5.5. ft. 15,5. A. T h 5.XXAr 1 R 1XXXtLi? b. Z. 1 .6 Z. 2.6 2上 5XXX札a.”X冥瓦X 鱼邦監*XXX7. t 令部冬求xX7-2金邯左求XX7. i鱼邦豐*XX7, A 7,仇 1XXX7. LK I.5XXifi x 0 个轉亶*XX%永q 金带疋醸XX;Clause-V-f-H早节Requireme nts标准要求Result测试结果Verd

3、ict判定4总要求质量管理体系医疗器械软件制造商应证实其有能力提供持 续满足顾客和适用的法规要求的医疗器械软Clause早节Requireme nts标准要求Result测试结果Verdict判定件。风险管理制造商应使用符合 YY/T 0316 （ISO 14971）的风险管理过程。软件的安全性级别a)制造商应按照软件系统引起的危害对于患者、 操作者或其他人员的可能影响， 赋于每个软件系统一个软件安全性级别（A、B或C）。b)制造商应依据风险控制措施所控制的危害的 可能影响。对实施风险控制措施起作用的每个 软件系统赋予一个软件安全性级别。c)制造商应在风险管理文档中将赋予每个软件 系统的软件安

4、全性级别形成文档。d)当一个软件系统分解为软件项，及当一个软件 项又进一步分解为几个软件项时，此类软件项 应继承原软件项（或软件系统）的软件安全性 级别，除非制造商以文件形式证明分类为不同 的安全性级别的理由。此类理由说明应解释新 的软件项是如何被分开的，以便可对其另行分 级。e)如果以分解方式产生的软件项的安全级别和 其源软件项不同，制造商应对每个软件项的软 件安全级别形成文档。Clause早节Requireme nts标准要求Result测试结果Verdict判定f)为符合本标准，无论特定级别的软件项是否需 要一个过程，此过程是否有必要应用于一组软 件项，制造商应使用此组中最高级别的软件项

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

6、用于支持开发的软件；和e)在生存周期每个阶段的软件产品、交付物和活 动中发现的用于处理问题的软件问题解决方Clause早节Requireme nts标准要求Result测试结果Verdict判定案。5.1.2保持软件开发计划更新在适当时，制造商应在开发进行的同时更新计戈叽5.1.3引用系统设计和开发的软件开发计划a)制造商应在软件开发计划中引用系统需求， 作为软件开发的输入b)制造商应在软件开发计划中包括或引用用于 协调软件开发和为满足必需的设计开发确认 的规程。5.1.6软件验证策划制造商应在软件开发计划中包括或引用下列验证信息a)需要验证的交付物b)每个生存周期活动所要求的验证任务c)对交

7、付物进行验证的里应碑，和d)验证交付物的验收准则5.1.7软件风险管理策划制造商应在软件开发计划中包括或引用实施 软件风险管理过程的活动和任务的计划， 包括与未知来源软件有关的风险的管理 .5.1.8文档策划制造商应在软件开发计划中包括或引用有关Clause早节Requireme nts标准要求Result测试结果Verdict判定在软件开发生存周期中所形成文档的信息。 对每个已识别的文挡或文档类型， 应包括或引用如下信息：a)标题、名称或命名约定；Pb)目的；c)文件的预期阅读者；和d)开发、评审、批准和修改的程序和职责。5.1.9软件配置管理策划制造商应在软件开发计划中包括或引用软件配置管

8、理信息。软件配置管理信息应包括或引用：a)受控项目的级别、型式、类别或清单；b)软件配置管理活动和任务；c)负责进行软件配置管理和活动的组织；d)他们和其他组织的关系，诸如软件开发或维护；e)当将这些项目处于配置控制之下时；和f)何时应用问题解决过程。软件需求分析5.2.1由系统需求确疋软件需求并形成文档。对每个医疗器械软件系统，制造商应从系统层面需求中确疋软件系统需求并形成文档。5.2.2软件需求内容Clause早节Requireme nts标准要求Result测试结果Verdict判定在使用与医疗器械软件，制造商应在软件需求 中包括：a)功能和能力需求；b)软件系统的输入和输出；c)软件系

9、统和其他系统之间的接口；d)软件控制的报警、警告和操作者信息；e)保密安全需求；f)对人为错误敏感的适用性工程要求和培训；g)数据定义和数据库需求；h)对已交付的医疗器械软件在操作和维护的一个或多个地点的安装和验收要求；i)与操作和维护方法有关的要求；j)要编制的用户文档；k)用户维护要求；和；l)法规要求。5.2.4医疗器械风险分析的再评价制造商应在制疋并适当更新软件需求时， 对医 疗器械风险分析进行再评价。5.2.5更新系统需求制造商应确保对现有的需求包括系统需求 )进行再评价和适当时更新，作为软件需求分析 活动的结果。5.2.6验证软件需求Clause早节Requireme nts标准要

10、求Result测试结果Verdict判定制造商应对软件需求进行验证并形成文档。a)实施包括有关风险控制在内的系统需求；b)需求不互相矛盾；c)避免使用含糊不清的术语表示；d)用表述的术语来制定测试准则和实施测试， 以确定是否满足测试准则；e)可以进行唯一性标识；和；f)对于系统要求或其他来源是可追溯的。软件单元的实现和验证5.5.1制造商应实现每个软件单元。软件发行584将发行的版本形成文档。6软件维护过程制定软件维护计划制造商应为进行维护过程的活动和任务，制定 一项（或多项）软件维护计划，计划应说明以 下内容：a)用于以下目的的规程：接收形成文档评价解决过程，和：跟踪。Clause早节Req

11、uireme nts标准要求Result测试结果Verdict判定医疗器械软件发行后引起的反馈；b)是否将反馈作为问题加以考虑的准则；c)软件风险管理过程的应用；d)应用软件冋题解决过程以分析和解决在医疗器械软件发行后出现的问题；e)应用软件配置管理过程 （第8章）管理对现有 系统的更改：和f)评价并实施未知来源软件 （SOUP下列事项的规程：升级缺陷修复补丁和；废弃问题和修改分析6.2.1形成文档并评价反馈621.1监控反馈制造商应从其组织内部和用户两方面监控对 对已发行的软件产品的反馈。621.2形成文档并评价反馈反馈应形成文档并进行评价，以决定其对已发 行的软件产品安全性有何种影响，是否有必要 对已发行的软件产品进行更改以解决问题。621.3评价问题报告对安全性的影响Clause早节Requireme nts标准要求Result测试结果Verdict判定应对每个问题报告进行评价，以确定已发行的 软件产品是否存在问题。任何这样的问题应以 问题报告的形式记录（见第9章）。问题报告 应包括实际的或潜在的不良事件和对规范的 偏离。622应用软件问题解决过程制造商应利用软件冋题解决过程（见第 9章）阐明问题报告。624更改请求的批准制造商应评价并批准修改已发行软件产品的 经批准的更改请求。6.2.5联系用户和