000-医疗器械软件审核要点

《000-医疗器械软件审核要点》由会员分享，可在线阅读，更多相关《000-医疗器械软件审核要点（9页珍藏版）》请在金锄头文库上搜索。

1、CMD软件类产品和包含软件的产品 在审核过程中的关注点1、 感谢 CMD 平台、和 CMD 领导在审核安排中、让我接触了较多的软件企业、有一点点总结、分享经验的资本，在座的其实都是专家，不对 之处，欢迎指正、也欢迎讨论。 2、 感谢审核 4 组的小伙、美女姑晾们，给我这个曝光露脸机会。 我们 4 组长说了，谁鼓掌、谁笑，下个月就是谁上台哦。 -曾经在北京局/国家局的软件注册审评指导原则（监管文件）中，有一句话影像很深“软件看不见摸不着” ， 最近闸门 CMD 群也转发 CFDA 和 FDA 医疗器械软件注册要求的对比表（预热） ；就是 CFDA 药监-50 号通告附件医疗器械软件注 册技术审查

2、指导原则国家局审评中心写的，和美国 FDA 2005 年 5 月 11 日医疗设备内含软件-上市前提交文件内容指南我们在这不 讨论这个法规要求。 -和审核一样，我们考虑标准，高于法规要求，我觉得应该写“软件看得见摸不着” 。 因为他运行我们能见的到，软件就像电子文 档一样，在计算机中分门别类， 我们一般对文件控制包括： “创建、审批、发布、存档、阅读、修改、复制” 。 软件分源程序、可执行程序；源程序还真是就按电子文档管理（4.2.3）控制，源程序（就如硬件设备的电路图、PCB 图、组装图） ， 源程序的控制和电子文档管理（4.2.3）是一样一样的哈。源程序的“创建、审批、发布、存档、阅读、修

3、改”应保留相应的质量记录（4.2.4）-一般没 有。可执行程序：她具备产品属性、像一个硬件设备、有功能、能完成任务。但也是一个文件、也同时应包括创建、审批、发布、存档、 阅读、修改”的文件控制。软件的要素就如文件（4.2.3/4.2.4 要素）：包括： 1、唯一性编码（就是软件标识） - 没有唯一性编码（标识） 2、软件类型（如文件类型） 、 （如：数据库文件.db 、 编译器提供的头文件.h（未知源代码、或基本算法） 、配置CMD文件.cfg、系统文件.sys、 系统测试文件平台 （各种系统） 、 测试用例.tst ，可执行程序 EXE 非常多） 。 3、软件名称 ： 软件版本命名规则及发布

4、版本：在配置管理计划中有主版本和次版本、修订版本。未明确发布版本；4、软件版本（主版本+次版本（+ 或更新日期） ） 存储介质： 5、说明书： 缺少必要的警告说明、缺少详细的使用方法、缺少必要的技术参数、缺少安装调试说明、缺少运输和贮存环境条件的限制6、铭牌：有 Gost 盘、光盘标识：有，内容（不受控） 、光盘没有包装（药局给开具不合格）光盘版本有、但和实际用到的、说明书中的 、注册的、软件里面显示的不一致施工日志：（CRM 客户管理系统）电子版CMD附表：审核过程中的关注点 过程条款文件要求规程记录：（关注点）标准要求（CMD）法规要求 4.2.3/4.2.4软件控制程序软件编码规程源程序

5、（程序）归档记录（审批） 、发布报 告软件原始取得著作权证；一般：技术部负责人、 老板、保密6.2 包括:软件编程人员 能力评价、在评 价制度控制程序包括软件系统分析师、结构框架 师、详细设计编程（程序员） 、测试、等岗 位职责、系统工程师、测试工程师等证问题不大有要求6.3/7.5.2程序杀毒、清洁、系统 Gost 重新等规程 台账：还包括：计算机、程序烧录工具、 系统测试机：各种操作系统的模拟机器，有网络的：网络平台杀毒、清洁、系统 Gost 重新等记录 7.5.2 工具软件确认 - 软件狗型号为“MicroDog-CA ”不一致 - 今年软件狗全部改为 UMI 刻录软件 NERO、 Au

6、toSO 有确认文档。生产的安装包：有校 验软件； MD5Summar，有确认！软件狗制作工具软件： V1.2有管理 过程7.3.5/7.3.6/7.5.2 -查看： 工具软件、产品 软件的 确认程序软件确认 -规程、 指导书编程软件：JAA、C+； 编译软件：Microsoft VS。 BUG/需求管理软件是：Jira 管理软件； 测试：基本未用性能测试工具，回归测试、 黑盒测试记录，在 Testlink 和自动化 QTP 测试、 网络区域软件测试工具：loadrunner； 其他外来源-软件 确认计划、确认实施记录、确认报告。-关注软件验证（测试）和软件确认区别：这是 CMD 内部，讲一个

7、故事： 上海 QARA 群群主-经常举办“医疗器械软件验 证培训班” ，. 说完和变了改“软件验证有确认报告晚上 1：00 我睡了被 他打电话吵醒，非得 问我“软件验证、确 认有什么区别”说没 解决他睡不着。 -我当然没告诉它。有CMD和可用性培训班” ，还叫验证，培训人还不 少 美国美国 FDA：软件确认指南（：软件确认指南（2002）：软件“验证、确认和测试（VV 和 T）好像是单一的概念， -软件验证提供软件开发生存周期特定阶段的设计输出满足该阶段的所有特定要求的客观证据。软件验证寻找软件和其支持文件的 一致性、完整性、和正确性 -美国 FDA 进一步明确： 软件确认为“通过检查和规定软

8、件规范符合用户需求和预期使用的客观证据，和特定要求的实现通过软 件可被始终如一地完成来证实。软件确认典型地包括所有软件要求已经正确地和完整地实现并可追溯到系统要求的证据。- 软件验证和确认是很难的，因为开发者不能始终测试，很难知道多少证据是足够的。 在大的测试中，软件确认是开发（器械满 足软件自动化功能和器械特征的所有要求和用户预期）的“置信度级别”的问题。例如在规范文件中发现的缺陷，估计剩余缺陷， 测试覆盖范围，和其它技术等措施都用于在产品发货前开发一个可接受的置信度级别。 -置信度级别，为此需要的软件确认、验证和测试工作级别将依赖器械的自动化功能引起的安全性风险（危害）而变化。关于软件 的

9、安全性风险管理的附加指南见美国食品药品管理局的第 4 部分包含在医疗器械中的软件的上市前提交内容的指南，和国际标准 ISO/IEC14971-1 和 IEC60601-1-4，在附录 A 中引用。3.1.3 IQ/OQ/PQ - 按照安装鉴定（IQ） 、操作鉴定（OQ）和性能鉴定（PQ）来描述用户现场软件确认 6.4程序软件编程器、编译 器、服务器机房的 环境控制规程。NANA7.1 策划/ 4.2.1（DMR）产品软件发布报告软件 风险 管理 过程7.1 软件风险管 理控制程序规程IECTR80002.1 IECTR8002.3 7.3.1、可行性报告-，评审、批准；缺少配置管理 计划、风险

10、管理计划，缺少评审、验证、 确认等安排。 软件测试计划书和测试计划评审报 告软件 开发 过程 7.3.2需求规格说明书： 仅有软件需求分析报告 （需求说明书）未提出规格； 设计开发输入文件清单，缺少风险管理报 告（不是计划） ；CMD设计开发输入阶段评审；评审内容无体现 可用性、 医疗器械法规要求 提供 DICOM 符合性声明无中文版概要设计：没有7.3.3、7.3.4风险管理报告，安全性级别未明确。未评 审 -源代码、可执行程序在 SVN 软件服务器保留。 无：软件发布报告、包装图、标签图（光盘图） 7.3.7软件注册完成能不能变更？有 BUG，改进肯定可以，但应保持改进 的软件的子版本或更

11、新日期；新增加功能的更改、界面改变，问药监 局7.5刻盘： 电脑没标识维护随便刻录（笔记本电脑就带刻录机） 、刻录记录很简单、无版本号，有的：用 U 盘、受控，有的网上下载，不用刻录 7.5.3配置管理程序软件 生产 安装 过程 7.5.5库房：4 区、有帐卡物、温湿度（药局给同 方库房开不合格） 、柜子一个，标识，但无 温湿度控制、无帐卡 说明书：电子版，无最后发布版本的记录 光盘标识：不受控-公司遇到产品抽查，如何从库里提供一 套完整无误的软件？有软件7.5.1f）验收单-都有。但无安装细节、日志；CMD未记录医院的计算机网络环境和自己的 接口设置；软件版本、最后更新日期（子版本）；出差报

12、告（或日志）复杂-无重点、无规 定。质量保证报告、结项总结表； 实施方案：2014-09、有评审批准（客 户确认） 。有系统接口（HIS、LIS、PAS）清 单；查：数据接口清单：有，详细现场集成：（施工日志： 每周报。 数据库导入无错）有系统集成工作报告、系统集成测试报 告；各服务器的配置环境 7.3.7 维修不分保内保外、软件维护 过程软件 测试 过程8.2.4 测试计划： 包括 负责人、测试时间 和阶段（模块测试、 系统测试、集成测 试）测试计划：测试工具的选用与验证、测试 内容、测试预期结果和记录要求； 测试计划应：评审、批准、评审（应有问 题）应升版、记录； 工具： 白盒测试工具、黑

13、盒测试工具、性 能测试工具，另外还有用于测试管理（测 试流程管理、缺陷跟踪管理、测试用例管 理）的工具 代码进行测试，测试中发现的缺陷可以定 位到代码级，根据测试工具原理的不同， 又可以分为静态测试工具和动态测试工具 黑盒测试工具：主要为功能测试工具，黑 盒测试工具的一般原理是利用脚本的录制 (Record)/回放(Playback)，模拟用户的操作，系统测试包括各国 系统（WIN 系列） 兼容性、模拟网络平 台（兼容性）硬件、软件的建立CMD北京某公司被发补的问题：问题与答案1.软件描述文档应提供制造商原文？你是什么软件？你是否买了现货软件？2.项目 1.2 安全级别判断有误然后将被测系统的

14、输出记录下来同预先给 定的标准结果比较。 性能测试的工具包括有：性能测试工具， 如 Loadrunner、SilKPerformer 等， MercuryInteractive 8.38、BUG 管理过程 涉及条款：8.3 8.5 BUG 管理（问题解决）： 一个文件化的问 题解决系统应该建立和保持，该系统用于 解决医疗器械软件（PEMS）开发生命期内的个 活动和各个阶段内部的问题和阶段之间的 接口问题。 取决于产品类型，问题解决可以是： 作为 PEMS 软件开发生命期一部分，被形成 文件 使影响安全性和基本性能的已存在或可能 的问题被报告 包括每个问题的相关风险的评估 识别问题被关闭的必须满

15、足的标准 识别解决问题所要采取的行动BUG 管理 过程8.5CMD你是如何给定级别的，是否有说明？你是否是依据 预期用途和使用环境 来判别安全性级别？3.项目 1.3 体系结构图不完整，应提供全部模块的功能你要依据 SDRS 软件设计规格说明来写，包括： 组成模块、模块功能、模块关系、模块与外部接口关系以及用户界面。4.项目 1.4 应描述硬件关系和运行环境，网络环境，其中硬件关系应描述物理拓扑关系你的软件是独立软件，应说明通用计算机的类型和功能5.项目 2.1 内容有误描述医疗器械软件开发过程所用的语言、工具、方法和生存周期模型6.项目 2.6 应补缺陷数请列明开发阶段所发现的缺陷总数和剩余缺陷数即可。7.项目 2.7 内容有误描述软件版本号的命名规则，版本历史，列明软件在原产国本版本所有修订活动的版本号、类型、日期。8.测试报告 3-7 无结果不知什么内容？9.项目 3 核心算法不完整在 SDRS 中，技术部应清楚。CMD 目前优势：1、 预热：从闸门 CMD 群也转发 CFDA 和 FDA 医疗器械软件注册要求的对比表（预热）看， CMD 有很多对软件很熟悉的，对软件产品和企业有较多现场审核经验的老师； 2、 ISO/IEC80002-3 ：领导让翻译了一下，有幸接触了软件全过程的要求，基于风险； 3、 关于安全性级别： CFDA 和 FDA 有区别；软件模块的安全