医疗器械软件审核要点演示教学.docx

医疗器械软件审核要点演示教学.docx

《医疗器械软件审核要点演示教学.docx》由会员分享，可在线阅读，更多相关《医疗器械软件审核要点演示教学.docx（19页珍藏版）》请在冰豆网上搜索。

医疗器械软件审核要点演示教学

医疗器械软件审核要点

软件类产品和包含软件的产品

在审核过程中的关注点

1、感谢CMD平台、和CMD领导在审核安排中、让我接触了较多的软件企业、有一点点总结、分享经验的资本，在座的其实都是专家，不对之处，欢迎指正、也欢迎讨论。

2、感谢审核4组的小伙、美女姑晾们，给我这个曝光露脸机会。

我们4组长说了，谁鼓掌、谁笑，下个月就是谁上台哦。

-------------------------------------------------------------------------------------

曾经在北京局/国家局的软件注册审评指导原则（监管文件）中，有一句话影像很深“软件看不见摸不着”，

最近闸门CMD群也转发CFDA和FDA医疗器械软件注册要求的对比表（预热）；就是CFDA药监-50号通告附件《医疗器械软件注册技术审查指导原则》国家局审评中心写的，和美国FDA2005年5月11日《医疗设备内含软件-上市前提交文件内容指南》我们在这不讨论这个法规要求。

-和审核一样，我们考虑规范，高于法规要求，我觉得应该写“软件看得见摸不着”。

因为他运行我们能见的到，软件就像电子文档一样，在计算机中分门别类，我们一般对文件控制包括：

“创建、审批、发布、存档、阅读、修改、复制…”。

软件分源程序、可执行程序；源程序还真是就按电子文档经管（4.2.3）控制，源程序（就如硬件设备的电路图、PCB图、组装图），源程序的控制和电子文档经管（4.2.3）是一样一样的哈。

源程序的“创建、审批、发布、存档、阅读、修改…”应保留相应的质量记录（4.2.4）--一般没有。

可执行程序：

她具备产品属性、像一个硬件设备、有功能、能完成任务。

但也是一个文件、也同时应包括创建、审批、发布、存档、阅读、修改…”的文件控制。

软件的要素就如文件（4.2.3/4.2.4要素）：

包括：

1、唯一性编码（就是软件标识）--没有唯一性编码（标识）

2、软件类型（如文件类型）、（如：

数据库文件.db、编译器提供的头文件.h（未知源代码、或基本算法）、配置文件.cfg、系统文件.sys、系统测试文件平台（各种系统）、测试用例.tst，可执行程序EXE…..非常多）。

3、软件名称：

软件版本命名规则及发布版本：

在ＳＶＮ配置经管计划中有主版本和次版本、修订版本。

未明确发布版本；

4、软件版本（主版本+次版本（+或更新日期））

存储介质：

5、说明书：

缺少必要的警告说明、缺少详细的使用方法、缺少必要的技术参数、缺少安装调试说明、缺少运输和贮存环境条件的限制

6、铭牌：

有Gost盘、光盘标识：

有，内容（不受控）、光盘没有包装（药局给开具不合格）

光盘版本有、但和实际用到的、说明书中的、注册的、软件里面显示的不一致

施工日志：

（CRM客户经管系统）电子版

附表：

审核过程中的关注点

过程

条款

文件要求

规程

记录：

（关注点）

规范要求（CMD）

法规要求

经管过程

4.2.3/4.2.4

软件控制程序

软件编码规程…

源程序（程序）归档记录（审批）、发布报告

软件原始取得著作权证；

一般：

技术部负责人、老板、保密

6.2

包括:

软件编程人员

能力评价、在评价制度

控制程序包括软件系统分析师、结构框架师、详细设计编程（程序员）、测试、等岗位职责、系统工程师、测试工程师等证

问题不大

有要求

6.3/7.5.2

程序

杀毒、清洁、系统Gost重新等规程

台账：

还包括：

计算机、程序烧录工具、

系统测试机：

各种操作系统的模拟机器，

有网络的：

网络平台

杀毒、清洁、系统Gost重新等记录

7.5.2工具软件确认

---软件狗型号为“MicroDog-CA”不一致---今年软件狗全部改为UMI

刻录软件NERO、AutoSO有确认文档。

生产的安装包：

有校验软件；MD5Summar，有确认！

软件狗制作工具软件：

V1.2

有

7.3.5/7.3.6/7.5.2

--查看：

工具软件、产品软件的确认程序

软件确认---规程、指导书

编程软件：

JAA、C++；

编译软件：

MicrosoftVS。

BUG/需求经管软件是：

Jira经管软件；

测试：

基本未用性能测试工具，回归测试、黑盒测试记录，在Testlink和自动化QTP测试、

网络区域软件测试工具：

loadrunner；

其他外来源--软件

确认计划、确认实施记录、确认报告。

---关注软件验证（测试）和软件确认区别：

这是CMD内部，讲一个故事：

上海QARA群群主----经常举办“医疗器械软件验证培训班”，….说完和变了改“软件验证和可用性培训班”，还叫验证，培训人还不少…

有确认报告

晚上1：

00我睡了被他打电话吵醒，非得问我“软件验证、确认有什么区别”说没解决他睡不着。

---我当然没告诉它。

有

美国FDA：

软件确认指南（2002）：

软件“验证、确认和测试（VV和T）好像是单一的概念，

--软件验证提供软件开发生存周期特定阶段的设计输出满足该阶段的所有特定要求的客观证据。

软件验证寻找软件和其支持文件的一致性、完整性、和正确性

--美国FDA进一步明确：

软件确认为“通过检查和规定软件规范符合用户需求和预期使用的客观证据，和特定要求的实现通过软件可被始终如一地完成来证实。

软件确认典型地包括所有软件要求已经正确地和完整地实现并可追溯到系统要求的证据。

---软件验证和确认是很难的，因为开发者不能始终测试，很难知道多少证据是足够的。

在大的测试中，软件确认是开发（器械满足软件自动化功能和器械特征的所有要求和用户预期）的“置信度级别”的问题。

例如在规范文件中发现的缺陷，估计剩余缺陷，测试覆盖范围，和其它技术等措施都用于在产品发货前开发一个可接受的置信度级别。

----置信度级别，为此需要的软件确认、验证和测试工作级别将依赖器械的自动化功能引起的安全性风险（危害）而变化。

关于软件的安全性风险经管的附加指南见美国食品药品经管局的第4部分包含在医疗器械中的软件的上市前提交内容的指南，和国际规范ISO/IEC14971-1和IEC60601-1-4，在附录A中引用。

3.1.3IQ/OQ/PQ

---按照安装鉴定（IQ）、操作鉴定（OQ）和性能鉴定（PQ）来描述用户现场软件确认

6.4

程序

软件编程器、编译器、服务器机房的环境控制规程。

NA

NA

软件风险经管过程

7.1策划/4.2.1（DMR）

产品软件发布报告

7.1软件风险经管

控制程序

规程

IECTR80002.1

IECTR8002.3

软件开发过程

7.3.1、

可行性报告--，评审、批准；缺少配置经管计划、风险经管计划，缺少评审、验证、确认等安排。

《软件测试计划书》和测试计划评审报告

7.3.2

需求规格说明书：

仅有软件需求分析报告（需求说明书）未提出规格；

设计开发输入文件清单，缺少风险经管报告（不是计划）；

设计开发输入阶段评审；评审内容无体现可用性、ＵＩ、　医疗器械法规要求

提供DICOM符合性声明—无中文版

概要设计：

没有

7.3.3、7.3.4

风险经管报告，安全性级别未明确。

未评审

--源代码、可执行程序在SVN软件服务器保留。

无：

软件发布报告、包装图、标签图（光盘图）

7.3.7

软件注册完成能不能变更？

有BUG，改进肯定可以，但应保持改进的软件的子版本或更新日期；

新增加功能的更改、界面改变，问药监局

软件生产安装过程

7.5

刻盘：

电脑没标识维护

随便刻录（笔记本电脑就带刻录机）、刻录记录很简单、无版本号，有的：

用U盘、受控，有的网上下载，不用刻录

7.5.3

《配置经管程序》

7.5.5

库房：

4区、有帐卡物、温湿度（药局给同方库房开不合格）、柜子一个，标识，但无温湿度控制、无帐卡

说明书：

电子版，无最后发布版本的记录

光盘标识：

不受控

---公司遇到产品抽查，如何从库里提供一套完整无误的软件？

有

软件维护过程

7.5.1f）

验收单--都有。

但无安装细节、日志；

未记录医院的计算机网络环境和自己的接口设置；

软件版本、最后更新日期（子版本）；

出差报告（或日志）复杂--无重点、无规定。

质量保证报告、结项总结表；

实施方案：

2014-09、有评审批准（客户确认）。

有系统接口（HIS、LIS、PAS）清单；查：

数据接口清单：

有，详细

现场集成：

（施工日志：

每周报。

数据库导入无错）

有系统集成工作报告、系统集成测试报告；各服务器的配置环境

7.3.7

维修不分保内保外、软件

软件测试过程

8.2.4

测试计划：

包括负责人、测试时间和阶段（模块测试、系统测试、集成测试）

测试计划：

测试工具的选用与验证、测试内容、测试预期结果和记录要求；

测试计划应：

评审、批准、评审（应有问题）应升版、记录；

工具：

白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试经管（测试流程经管、缺陷跟踪经管、测试用例经管）的工具

代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具

黑盒测试工具：

主要为功能测试工具，黑盒测试工具的一般原理是利用脚本的录制（Record）/回放（Playback），模拟用户的操作，然后将被测系统的输出记录下来同预先给定的规范结果比较。

性能测试的工具包括有：

性能测试工具，如Loadrunner、SilKPerformer等，MercuryInteractive

系统测试—包括各国系统（WIN系列）兼容性、模拟网络平台（兼容性）

硬件、软件的建立

BUG经管过程

8.3

8、BUG经管过程涉及条款：

8.38.5

BUG经管（问题解决）：

一个文件化的问题解决系统应该建立和保持，该系统用于解决

医疗器械软件（PEMS）开发生命期内的个活动和各个阶段内部的问题和阶段之间的接口问题。

取决于产品类型，问题解决可以是：

作为PEMS软件开发生命期一部分，被形成文件

使影响安全性和基本性能的已存在或可能的问题被报告

包括每个问题的相关风险的评估

识别问题被关闭的必须满足的规范

识别解决问题所要采取的行动

8.5

北京某公司被发补的问题：

问题与答案

1.软件描述文档应提供制造商原文？

你是什么软件？

你是否买了现货软件？

2.工程1.2安全级别判断有误

你是如何给定级别的，是否有说明？

你是否是依据预期用途和使用环境来判别安全性级别？

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有区别；

软件模块的安全性级别：

外部文件：

普通软件—信息工业化部--软件产品登记证、著作权证、软件企业证

1、GB-T16260.1/2/3/4-2006软件工程产品质量第1部分：

质量模型第2部分：

外部度量第3部分：

内部度量第4部分：

使用质量的度量

2、GB-T25000.1-2010软件工程软件产品质量要求与评价GB-T25000.51-2010软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求和测试细则

医院用软件：

His、Ris、挂号、收费系统护士/大夫观片显示屏

1、卫生部：

医院信息系统基本功能规范-2015包括：

临床诊疗部分药品经管部分。

经济经管部分（挂号、住院）；综合经管与统计分析部分；外部接口部分。

2、DICOM3.0规范符合性声明

3、卫生部电子病历评级规范（HC3i）

软件医疗器械：

1、DICOM3.0规范符合性声明

2、YY/T0664-2008软件医疗器械软件生存周期过程；

3、IEC/TR80002.1/2/3软件医疗器械风险经管

4、药监-50号通告附件医疗器械软件注册技术审查指导原则