药监系统官方培训 彭亮-医疗器械生产质量管理规范独立软件附录解读

国家药监局器审中心 彭亮2019.8 北京内容摘要 软件监管背景 软件工程基础 独立软件附录软件与医疗器械独立软件软件组件设备软件体系软件有源器械体外诊断无源器械医疗器械软件软件质量相关软件美国软件相关召回时间范围召回 软件软件召回 软件召回总数 召回数量 召回比重 同比增长 同比增长1983-1991 27921992-1998 31401999-2005*37711652424255.9%7.7%12.5%46.7%11.3%20.1%75.6%2005-2011 5792 112219.4%53.6%164%注：*含有软件医疗器械的召回33.7%与软件有关美国软件相关召回1983-1991 1992-1998 1999-2005 2005-2011类别19%18%23%10%11%14%5%34%24%19%5%33%35%8%49%19%13%8%放射类IVD 类心脏类其它类通用类呼麻类手术类9%10%8%13%1%7%3%0%1%1%软件监管背景 软件应用广泛，作用日趋重要，但质量问题突出 软件具有特殊性 软件没有物理实体，人为因素影响无处不在，测试不能穷尽所有情形 软件更新迅速频繁，轻微更新可能导致严重后果，而且存在退化问题 现有已知方法不能保证全部软件100%的安全性 软件质控原则 尽早质控、重点质控、全程质控 风险管理、质量管理和软件工程相结合软件生存周期 定义 软件产品从概念定义至停止使用的时间周期 典型阶段 包括：软件开发策划、软件需求分析、软件设计、软件编码、软件测试、软件发布、软件部署、软件维护、软件停运软件生存周期模型瀑布模型增量模型软件生存周期模型螺旋模型V模型软件生存周期过程 过程活动任务 基本过程 软件开发：开发策划、需求分析、设计、编码、测试 软件维护：软件更新/软件变更 风险管理：基于损害严重度分析，保证软件已知剩余缺陷风险均可接受 配置管理：识别配置项，控制变更 缺陷管理：软件缺陷修复属于设计变更软件风险管理 概述 软件本身不是危害，但会引发危害处境 软件风险管理通常基于损害严重度实施 软件失效表现为随机性，但实为系统性 软件组件孤立进行风险管理是不合适的 风险管理应贯穿于软件生存周期全过程 软件确认应保证软件已知剩余缺陷风险均可接受 常用方法 故障树分析（FTA）失效模式和效应分析（FMEA）软件可追溯性分析 定义 追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性 活动 需求分析：软件需求风险管理、软件需求产品需求 设计：软件设计软件需求 编码：源代码软件设计、源代码测试用例 验证测试：各级测试用例软件设计、系统测试软件需求、系统测试风险管理 确认测试：用户测试用户需求、用户测试风险管理软件可追溯性分析可追溯性分析报告示例需求IDRS1RS2RS3RS4RS5.设计IDDS1测试IDST1风险管理IDRM1DS2ST2RM2RM3DS3.ST3.RM4RM5.软件测试静态分析动态分析白盒测试黑盒测试单元测试集成测试系统测试内部测试用户测试第三方测试回归测试：用于确定软件变更没有产生不良影响的测试软件测试软件验证 定义 通过提供客观证据认定软件开发、软件维护某一阶段的输出满足输入要求 软件验证活动 源代码审核 静态分析、动态分析 白盒测试、黑盒测试 单元测试、集成测试、系统测试 评审软件确认 定义 通过提供客观证据认定软件满足用户需求和预期目的 软件确认活动 软件验证活动 软件可追溯性分析 用户测试 临床评价 评审软件确认原则 文档化的软件需求规范是软件确认基线 软件测试的能力是有限的，却是必须的 软件确认需要时间和精力，应尽早准备 软件确认应在软件生存周期过程中进行 软件确认需要通过计划来定义和控制 软件确认通过一系列工作程序实现 软件变更均应进行确认分析并回归测试 确认范围取决于软件复杂度和风险水平 确认应坚持“评审独立性”原则 制造商可选择确认活动，但付最终责任独立软件附录简介 适用范围 适用于独立软件，软件组件参照执行 涵盖网络安全、现成软件 核心文献 IMDRF/SaMD/N23、FDA软件确认指南 IEC 62304/82304-1、ISO 90003 实施要求 GMP规范+独立软件附录，2020.7.1正式实施 配套现场检查指导原则正在制定目录 范围和原则（2）特殊要求（32）人员（3）、设备（2）、设计开发（17）、采购（3）生产管理（2）、质量控制（1）、销售和售后服务（2）不良事件监测、分析和改进（2）术语（13）附则（2）人员 软件开发、测试、维护人员应当具备与岗位职责要求相适宜的专业知识、实践经验和工作能力 黑盒测试应当保证同一软件项的开发人员和测试人员不得互相兼任 用户测试人员应当具备适宜的软件产品使用经验，或经过培训具备适宜的软件产品使用技能设备 应当在软件生存周期过程持续提供充分、适宜、有效的软件开发和测试环境，包括软硬件设备、开发测试工具、网络等资源以及病毒防护、数据备份与恢复等保证措施 软件开发和测试环境维护应当形成文件，确定软件开发和测试环境定期验证、更新升级、病毒防护等活动要求，保持相关记录设计开发设计开发 应当结合软件生存周期模型特点建立软件生存周期过程控制程序并形成文件，确定软件开发策划、软件需求分析、软件设计、软件编码、验证与确认、软件更新、风险管理、缺陷管理、可追溯性分析、配置管理、文件与记录控制、现成软件使用、网络安全保证、软件发布、软件部署、软件停运等活动要求 软件生存周期过程质量保证活动要求应当与软件安全性级别相适宜 软件安全性级别仅可通过外部风险控制措施降低级别 软件版本变更应当符合软件版本命名规则的要求，软件版本变更应当与软件更新情况相匹配采购 现成软件采购应当形成文件，根据现成软件的类型、使用方式、对产品质量影响程度，确定分类管理、质量控制、供应商审核等活动要求 应当与供应商签订外包软件质量协议，明确外包软件需求分析、交付形式、验收方式与准则、设计开发文件交付、知识产权归属、维护等要求以及双方质量责任承担要求 云计算服务协议应当明确网络安全保证、患者数据与隐私保护等责任承担要求生产管理 软件发布应当形成文件，确定软件产品文件创建、软件产品与文件归档备份、软件版本识别与标记、交付形式评估与验证、病毒防护等活动要求，保证软件发布的可重复性 物理交付方式应当确定软件产品复制、许可授权以及存储媒介包装、标记、防护等要求，网络交付方式应当确定软件产品标记、许可授权、网络安全保证等要求质量控制 软件产品放行应当形成文件，确定软件版本识别、安装卸载测试、产品完整性检查、放行批准等活动要求，保持相关记录销售与售后服务 软件部署应当形成文件，确定交付、安装、设置、配置、用户培训等活动要求，保持相关记录 软件停运应当形成文件，确定停运后续用户服务、数据迁移、患者数据与隐私保护、用户告知等活动要求，保持相关记录不良事件监测、分析和改进 数据分析控制程序应当涵盖软件缺陷、网络安全事件要求 网络安全事件应急响应应当形成文件，确定网络安全事件风险管理、应急响应措施验证、用户告知、召回等活动要求，保持相关记录谢谢！