医疗器械软件申报基本要求3.5DICOM简介全称医学数字成像与通信标准目的医学图像的传输概况由美国放射学会ACR和美国电子制造商协会NEMA制定1985年1.0版，1988年2.0版，1993年3.0版目前由九部分内容组成，扩展部分正在讨论认证通过DICOM符合性声明自我认证详细描述产品满足的DICOM内容医疗器械软件申报基本要求3.5HL7简介全称卫生信息交换标准目的医学文本信息的传输概况成立于1987年，1994成为美国国家标准局ANSI所授权的标准开发组织1987年1.0版，2000年2.4版，现已开发3.0版由触发事件、消息、段和字段组成认证非正式的自我声明医疗器械软件申报基本要求3.5DICOM与HL7医疗器械软件申报基本要求4软件监管情况综述FDA软件监管综述欧盟软件监管综述FDA与欧盟的比较我国软件监管现状医疗器械软件申报基本要求4.1FDA软件监管综述基本原则基于风险分级管理，不同级别不同要求所有软件统一要求，不再区分软件类型过程与结果相结合，质量体系与确认并重关注重点质量体系软件确认现成软件网络安全医疗器械软件申报基本要求4.1FDA指南与要求质量体系设计控制（820.30：1997）、人因工程（1996）采购控制（820.50）、纠正与预防措施（820.100）AAMISW68：2001=IEC62304：2006通用指南医疗器械软件通用指南（19981997=2005）医疗软件确认基本原则（1997=2002）医疗器械使用现成软件指南（1997=1999）内含现成软件医疗器械网络安全指南（2005）产品指南医疗影像管理器械指南（1983=2000）医疗器械软件申报基本要求4.1设计控制指南820.30（a）所有III类和II类医疗器械均应进行设计控制部分I类医疗器械应进行设计控制（i）软件操控的医疗器械；（ii）······820.30（g）设计确认应包含软件确认和风险分析820.30（j）每个制造商应对每类产品建立和维护DHFDHF应包含或引用开发符合计划和需求的必要记录医疗器械软件申报基本要求4.1设计控制指南评审通过文档化、全面的、系统的检查来评估需求的适当性和设计符合需求的能力，并识别问题验证通过检查和提供客观证据来认定规定需求已得到满足确认通过检查和提供客观证据来认定特定预期用途的需求已得到满足过程确认：通过客观证据确立一个过程能始终产出符合预期规格的结果或产品设计确认：通过客观证据确立器械规格符合用户需求和预期用途医疗器械软件申报基本要求4.1设计控制指南医疗器械软件申报基本要求4.1软件确认指南背景由于复杂性，软件开发过程比硬件更应严格控制软件工程比硬件工程需要更高级别的监管和控制适用范围作为医疗器械组件、部件或附件的软件本身是医疗器械的软件用于医疗器械生产的软件用于质量体系管理的软件典型活动质量策划、需求、设计、编码、内部测试、用户测试、维护变更医疗器械软件申报基本要求4.1软件确认指南文档化的软件需求规格是软件确认的基线软件测试的能力是有限的，却是必须的软件确认需要时间和精力，应当尽早准备软件确认应在软件生存周期过程中进行软件确认需要通过计划来定义和控制软件确认是通过一系列工作程序来实现的软件变更均应进行确认分析，并需回归测试确认范围取决于软件的复杂度和风险水平确认应坚持“评审独立性”的原则制造商可以选择确认活动，但应付最终责任医疗器械软件申报基本要求4.1软件通用指南适用范围固件或其他基于软件控制的医疗器械独立的应用软件安装在通用计算机的软件专用的硬件/软件医疗器械包含软件或为独立软件的医疗器械附件适用类型预上市通告（510K），包括传统、专用和简易方式预上市批准申请（PMA）研究器械豁免（IDE）人道主义器械豁免（HDE），包括修订和补充医疗器械软件申报基本要求4.1软件通用指南验证通过提供客观证据来认定某开发阶段的输出符合该阶段所有输入需求包括走查、静态分析、动态分析、代码检查、文档检查、单元测试、集成测试确认通过提供客观证据来认定软件符合用户需求和预期用途仅限于设计确认，不包括过程确认软件在真实或模拟使用环境中正确运行的检查，也包括质量策划、验证、可追溯性分析、配置管理等活动医疗器械软件申报基本要求4.1软件通用指南可追溯性名称：可追踪性、可跟踪性定义：在开发过程中两个或多个产品之间能建立关联的程度，特别是存在前后和主次关系的产品之间可追溯性分析追踪（