工业和FDA员工指南和医疗器械所含软件的上市前提交内容指南

36/36工业和FDA员工指南和医疗器械所含软件的上市前提交内容指南工业和FDA员工指南

医疗器械所含软件的上市前提交内容指南

文件发布日期：2005年5月11日

本文件取代5月29日发布的《医疗器械所含软件的上市前提交内容指南》，

1998年，以及血液建立计算机软件的上市前通知提交者审阅指南，于1997

年1月13日发布。

有关与CDRH管制的设备有关的本文档的问题，请致电（301）796-6325与LindaRicci联系。有关本文档中有关受以下法规管制的设备的问题CBER请致电（301）827-6136与LindaWeir联系。

前言

（一）公众意见

意见和建议可随时提交给美国食品药品管理局药物管理部门，邮编为5630FishersLane，1061室，（HFA305），马里兰州罗克维尔，邮政编码20852。提交意见时，请参阅该指导文件的确切名称。在下次修改或更新该文件之前，FDA不得对评论采取行动。

（二）额外副本

基德

其他副本可以从Internet上找到：/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM089543.htm，您也可以发送电子邮件请求至dsmica@接收指南的电子副本或将传真请求发送到301-847-8149以接收纸质副本。请使用文件编号（337）识别您所要求的指南。

克贝尔

可以从传播，培训和制造商协助办公室（HFM-40），1401RockvillePike，Rockville，MD20852-1448或致电1-800-835-4709或301-827-1800获得本指南的其他副本，或通过/cber/guidelines.htm.

工业和FDA员工指南

医疗器械所含软件的上市前提交内容指南

（一）介绍

本指南文档旨在向业界提供有关我们建议您将其包括在软件设备的上市前提交中的文档的信息，这些文档包括独立的软件应用程序和包含软件的基于硬件的设备。本文档是不断努力以更清楚地陈述我们的建议并确保它们随着技术进步而保持最新的结果。该文档还合并为先前包含在两个指南文档中的一个指南建议。

（二）减轻负担

本指导文档中确定的问题代表了我们认为应在设备上市之前应解决的问题。在制定指南时，我们仔细考虑了机构决策的相关法定标准。我们还考虑了您遵循指南并解决我们发现的问题可能会带来的负担。我们认为，我们已经考虑了解决指导文件中提出的问题的负担最小的方法。但是，如果您认为解决问题的方法不那么繁重，则应遵循指南“解决最轻负担问题的建议方法”中概述程序，/cdrh/modact/leastburdensome.html.FDA的指导文件（包括本指南）没有确立法律上可执行的责任。相反，指南描述了原子能机构当前对某个主题的想法，除非被引述了特定的监管或法规要求，否则应仅将其视为建议。在原子能机构指导中使用“应”一词的意思是建议或推荐某事，但不是必需的。

（三）范围

就本文档而言，我们将包含一个或多个软件组件，零件或附件，或仅由软件组成的设备称为“软件设备”，包括：1、固件和用于基于软件控制医疗设备的其他方式；2、独立软件应用程序；3、旨在安装在通用计算机中的软件；4、专用的硬件/软件医疗设备；附件包含医疗软件或由软件组成的医疗设备附件。本指南适用于软件设备，无论将软件交付给最终用户的方式如何，无论是工厂安装，第三方供应商安装，现场安装还是升级。本指南未涵盖的软件包括为制造或其他过程控制功能而设计的软件，但不适用于设备。有关更多信息或澄清您设备的要求，请联系负责的FDA审查部门。本指南文档适用于软件设备的所有上市前提交内容，包括：

1、上市前通知（510（k）），包括传统，特殊和缩写提交；

2、上市前批准申请（PMA）；

3、器械免试（IDE）；

4、人道主义设备豁免（HDE），包括修订和补充。

（四）与其他文件的关系

1、FDA指导文件我们希望本文档可以补充其他现有的指导文档，这些文档提供与软件相关的建议。例如，对于与设备有关的软件（包括作为独立设备或作为组件，零件或附件的软件），我们建议您还参考指南“软件验证的一般原理”ii设备）。如果您的设备使用现成的软件，我们建议您参考“医疗设备中现成的软件使用指南”iii。软件设备的制造商应根据质量体系法规iv（QS法规）（21CFR第820部分）的要求创建和维护与软件有关的文档。与其他提供建议的FDA指导文件一样，请注意，遵循本指南的建议并不能代替遵守QS法规。2、与软件相关的共识标准与软件有关的共识标准的出现有助于提高软件开发和文档编制的一致性和质量，特别是在诸如风险评估和管理等关键活动方面。在可能的情况下，我们将本指南中的术语和建议与与软件相关的共识标准（例如ISO14971v和AAMISW68。vi）进行协调。

（五）术语

1、验证与确认本文档使用QS法规中定义的术语“验证”和“验证”（也称为“V＆V”）。iv验证“是指通过检查并提供客观证据证明已满足指定要求的确认。”21CFR820.3（aa）。在软件开发环境中，软件验证可以确认特定开发阶段的输出满足该阶段的所有输入要求。软件测试是旨在确认软件开发输出满足其输入要求的几种验证活动之一。其他验证活动包括：1、穿行；2、各种静态和动态分析；3、代码和文件检查；4、模块级测试；5、集成测试。

设计验证“是指通过客观证据确定设备规格符合用户需求和预期用途。”21CFR820.3（z）（2）。在本文档中，术语“验证”的使用仅限于设计验证，并且不包括21CFR820.3（z）（1）中定义的过程验证。设计验证的一个组成部分是软件验证。

软件确认是指通过客观证据证明软件符合用户的需求和设备的预期用途。软件验证是成品设备设计验证的一部分。它涉及检查软件在其实际或模拟使用环境中是否正常运行，包括在适当情况下集成到最终设备中。

软件验证高度依赖于先前在软件开发生命周期的每个阶段完成的全面软件测试和其他验证任务。好的软件工程的规划，验证，可追溯性，配置管理和许多其他方面都是重要的活动，它们共同有助于支持软件已验证的结论。

2、轻伤和重伤

就本文档而言，我们使用轻伤一词是指不符合21CFR803.3（bb）（1）中定义的重伤定义的任何轻伤。该法规将严重伤害定义为以下伤害或疾病：

i.威胁生命；

ii.导致身体功能的永久性损害或身体结构的永久性损害；

iii.必须采取医学或外科手术干预措施，以防止身体功能永久受损或对身体结构造成永久损坏。就本文档而言，术语“永久性”定义为“对身体结构或功能的不可逆转的损害或损害，不包括琐碎的损害或损害。”21CFR803.3（bb）（2）。

关注程度

（一）介绍

我们建议您在上市前提交的文件中包含的文档通常取决于设备的关注级别。在本指导文件中，“关注等级”是指设备可能因设备故障，设计缺陷，直接或间接地对患者或操作者造成或造成的伤害严重性的估计值。或者仅通过将该设备用于其预期用途即可。我们建议您描述软件在引起，控制和/或减轻可能导致患者或操作人员受伤的危险中的作用，因为这也是确定设备适当关注级别的因素。我们建议您为软件设备提交的文档范围与与设备相关的关注级别成正比。关注级别仅在此上下文中定义，与设备分类（I，II或III类）或危害或风险分析本身无关。

（二）主要，中度或次要关注级别

以下各节提供了用于确定可能适合您的软件设备的关注级别的建议以及应为每个关注级别提交的文档建议。我们建议您在减轻相关危害之前确定关注级别。换句话说，在没有缓解措施的情况下，应通过危害分析来驱动“关注级别”，而不管缓解措施对单个危害的影响如何。FDA建议您在提交的文件中说明对软件设备确定的关注级别。可以是以下定义的“主要”，“中等”或“次要”。我们还建议您描述您如何达到此关注级别。关注程度基于与设备功能相关的软件的操作如何影响患者或操作员，效果可以是直接的或间接的。

1、重大的如果故障或潜在缺陷可能直接导致患者或操作人员死亡或重伤，我们认为关注级别为“重大”。如果故障或潜在缺陷可能通过不正确或延迟的信息或通过护理人员的行动而间接导致患者或操作人员死亡或重伤，则关注级别也为“严重”。

2、中等我们认为，如果失败或潜在的设计缺陷可能直接对患者或操作人员造成轻伤，则关注的程度是“中等”。如果故障或潜在缺陷可能通过不正确或延迟的信息或通过护理人员的行动而间接给患者或操作者造成轻伤，则关注的程度也应为中等。

3、次要我们认为，如果故障或潜在的设计缺陷不太可能对患者或操作者造成任何伤害，则关注的程度是次要的。

4、确定关注程度我们提供了以下关键问题，以帮助您确定关注级别。我们建议您在减轻任何危害之前评估关注级别；也就是说，您应该针对这些问题评估软件设备，就好像您没有实施危害缓解措施一样。

如果任何问题的答案为“否”，则继续下一个问题。如稍后将更详细地讨论的那样，我们建议您在提交的意见中包括得出结论的基础。在所有情况下，我们建议您在软件设备故障可能带来的最坏的，合理的可预见的临床后果的背景下评估关注程度。

表1主要关注程度

如果以下任何一个问题的答案为“是”，则该软件设备的关注级别可能很重要。1.该软件设备是否有资格作为血液建立计算机软件？

（血液建立计算机软件被定义为旨在用于制造血液和血液成分或维护血液建立人员用于决定供血者是否适合以及输血或血液成分是否适合输血的数据的软件产品或进一步制造。）2.软件设备是否打算与药物或生物制剂组合使用？3.软件设备是否是具有重大关注级别的医疗设备的附件？4.在减轻危害之前，软件设备的故障会导致患者或设备用户死亡或重伤吗？例如：

a.软件设备控制着维持生命或维持生命的功能吗？

b.

软件设备是否控制可能导致死亡或严重伤害的潜在有害能量的传递，例如放射治疗系统，除颤器和消融发生器？c.软件设备是否控制治疗或疗法的交付，以使错误或故障可能导致死亡或严重伤害？

d.

软件设备是否提供诊断信息，该信息直接决定治疗或治疗的决定，如果使用不当，可能会导致严重的伤害或死亡？

e.

对于需要进行医疗干预的潜在威胁生命的情况，软件设备是否提供生命体征监测和警报？

表2中等关注程度

如果软件设备不是主要关注级别，并且以下任何一个问题的答案为是，则关注级别可能中等。

1.软件设备是否是关注程度中等的医疗设备的附件？2.在减轻危害之前，软件设备的故障是否会对设备的患者或用户造成轻微伤害？3.软件设备的故障或潜在的设计缺陷是否可能导致错误诊断或延迟提供适当的医疗服务，从而可能导致轻伤？

如果以上表1和表2中所有问题的答案均为“否”，则关注程度为“小”。

FDA的审查部门可以讨论您对软件设备的关注级别的任何疑问。如果您认为设备的关注级别是“重大”，并且您之前尚未针对此类软件设备提交过上市前提交的文件，我们建议您在提交文件之前与FDA的适当部门联系以讨论您的软件设备。

与软件有关的文档

您在上市前提交的文件中提供的与软件相关的文档应与软件设备的预期用途，关注级别以及提交的类型相一致。本节介绍了我们建议您根据关注程度（包括表3）在上市前提交的文件。但是，如果设备可用，则应遵循设备特定指南中的建议。通常，您提交的文件中提供的文档应：1、描述您设备的设计；2、记录如何实施设计；3、演示如何测试设计实施生产的设备；4、表明您已正确识别危害并有效管理风险；5、提供可追溯性，以将设计，实施，测试和风险管理链接在一起。表3总结了我们建议您提交的文档的类型和范围。我们的建议与设备的关注级别有关。这些建议基于您对QSR（包括设计控制）的有效实施和管理。iv我们认为，我们建议提交的文档通常与您在开发软件设备期间通常生成的文档相同。因此，在经过适当管理和记录的医疗设备软件开发环境中，您为响应本指南中的建议而提交的文档可能是产品开发文档的副本。我们在表3的下面的部分中解释建议提交的文档。在某些情况下，建议的关注级别文档可以采用陈述形式的形式；其他文档（例如软件需求规范）很可能是复制到提交中的独立文档。

表3.基于关注级别的文档

软件说明文件小问题适度的关注主要关注关注程度表示关注级别的声明，以及对该级别的理由的描述。软体说明功能和软件操作环境的概述。设备危害分析以表格形式描述已识别的硬件和软件危害，包括严重性评估和缓解措施。软件需求规范（SRS）SRS的功能要求摘要。完整的SRS文档。建筑设计图提交中不需要任何文档。功能单元和软件模块的详细描述。可能包括状态图和流程图。软件设计规范（SDS）提交中不需要任何文档。软件设计规范文档。可追溯性分析需求，规范，已识别的危害和缓解措施以及验证和确认测试之间的可追溯性。软件开发环境说明提交中不需要任何文档。软件生命周期开发计划摘要，包括配置管理摘要和软件生命周期开发计划摘要。在开发过程中生成的带注释的控制文档列表。包括软件说明文件小问题适度的关注主要关注

保养组态活动。管理和维护计划文件。验证和软件说明说明验证功能测试的V＆V

活动的V＆V

活动文档计划，通过/失败标准和结果。单元，集成和系统级别。系统级别的测试协议，包括通过/失败标准和测试结果。单元，集成和系统级别。单元，集成和系统级测试协议，包括通过/失败标准，测试报告，摘要和测试结修订级别历史修订历史记录日志，包括发行版本号和日期。未解决的异常没有剩余软件异常的列表，（缺陷或缺陷）提交中需要提供文档。并附有对安全性或有效性的影响的解释，包括操作员的使用和人为因素。

关注程度

我们建议您指出在缓解措施生效之前确定的软件设备的关注级别。我们建议您明确说明三个关注级别中的哪个级别适合您的设备，并包括决定依据的文档。我们还建议您的文件使您的决策过程对FDA显而易见。

（一）软体说明

我们建议您提供由软件控制的设备功能的全面概述，并描述预期的操作环境。通常，我们建议您以段落格式提供信息，并突出显示主要的或对操作有重要意义的软件功能。软件说明应包括以下信息：

1、程式语言；

2、硬件平台；

3、操作系统（如果适用）；

4、使用现有软件（如果适用）。

如果您的设备使用现成的软件，请参阅FDA指导文件“医疗设备中现成的软件使用指南”iii。如果此信息包含在另一个文档（例如，软件需求规范）中，则您的提交应在该信息所在的提交中包含注释和对该文档的引用。

（二）设备危害分析

我们建议您为所有软件设备提交设备危害分析。设备危害分析应考虑与设备预期用途相关的所有设备危害，包括硬件和软件危害。我们建议您以表格形式提供信息，并为每个已识别的危害提供一个选项行。

该文档可以是从全面的风险管理文档中提取与软件相关的项目的形式，例如ISO14971中描述的“风险管理摘要”。v在此格式下，每个行项目应包括：

1、危险事件的识别；

2、危害的严重性；

3、危害原因；

4、控制方法（例如，警报，硬件设计）；

5、采取的纠正措施，包括对设备设计/要求的各个方面的说明，以消除减少或警告危险事件；

6、验证控制方法是否正确实施。

进行危害分析时，建议您解决所有可预见的危害，包括因故意或无意滥用设备而造成的危害。

（三）软件需求规范

软件需求规范（SRS）记录了软件需求。这通常包括软件的功能，性能，界面，设计，开发和其他要求。实际上，该文档描述了软件设备应该执行的操作。

SRS中将包括的一些典型要求的示例是如下面所描述的。对于被标识为“次要关注级别”的软件设备，我们建议您仅提供SRS中的“摘要功能要求”部分，其中包括现成软件的标识。对于被标识为主要或中等关注级别的软件设备，我们建议您提供完整的SRS文档。

（四）硬体需求

硬件要求通常包括：1、微处理器；2、存储设备；3、传感器；4、能源；5、安全特性；6、通信。

（五）编程语言要求

编程语言要求包括程序大小要求或限制，以及有关内存泄漏管理的信息。

（六）接口要求

接口要求通常包括系统组件之间的通信和与用户的通信，例如：1、打印机；2、显示器；3、键盘；4、鼠标。

（七）软件性能和功能要求

软件性能和功能要求包括用于治疗，诊断，监测，警报，分析和解释的算法或控制特征，并在必要时提供全文参考或支持的临床数据。软件性能和功能要求可能还包括：1、设备因软件而受到的限制；2、内部软件测试和检查；3、错误和中断处理；4、故障检测，容限和恢复特征；5、安全要求；6、时间和内存要求；7、如果适用，可以识别现成的软件。

（八）建筑设计图

该文档通常是软件设备中主要功能单元之间的关系的流程图或类似描述，包括与硬件和数据流（例如网络）的关系。通常没有必要在本文档中包含每个函数调用和模块。但是，应该有足够的信息以允许就功能和软件设备的预期用途来审查软件的组织。

对于中等和主要关注级别的设备，诸如状态图之类的详细信息可能有助于清楚地描述软件功能单元之间的关系。如果体系结构设计图包含在另一个文档（例如SRS）中，则应在提交的内容中包括对此的声明以及对提交中体系结构设计图的位置的引用。

（九）软件设计规范

软件设计规范（SDS）描述了软件设备要求的实现。根据SRS和SDS之间的关系，SRS描述了软件设备将执行的操作，而SDS描述了如何实现SRS中的要求。

SDS中提供的信息应足以确保创建软件设备的软件工程师所做的工作清晰明确，并且具有最少的临时设计决策。

SDS可能包含对其他文档的引用，例如详细的软件规格。但是，您提交的文档应本身提供足够的信息，以便可以从预期用途，功能，安全性和有效性方面审查软件要求的实施计划。

（十）可追溯性分析

可追溯性分析将您的产品设计要求，设计规格和测试要求链接在一起。它还提供了一种方法，可以将识别出的危害与缓解措施的实施和测试联系在一起。

我们建议您在这些活动和相关文档中提交明确的可追溯性，以供审核，因为它们对于有效的产品开发以及对我们对产品设计，开发和测试以及减轻危害的理解至关重要。

可追溯性分析通常包括一个矩阵，其中包含用于需求，规格和测试的行项目，以及指向减轻危害的指标。只需通过共享组织即可记录可追溯性具有通用编号方案的结构；但是，我们建议您包括一些机制，例如用于指导审阅者提交的信息的矩阵。

（十一）软件开发环境说明

对于“中等和主要关注的软件设备”，提交的内容应包括软件开发生命周期计划的摘要。

此摘要应描述发起人的软件开发生命周期以及管理各种生命周期活动的适当过程。对于“主要关注的软件设备”，该文档还应该包括在软件开发过程中生成的控制/基线文档的带注释的列表以及软件编码标准的列表或说明。

如其他地方所述，配置或变更管理是软件开发的关键方面。初始市场发布后对软件设备的更改应受到积极控制，并具有确定的规范和测试计划，包括在适当的情况下明确定义的回归测试。

开发环境的描述应提供有关配置管理和维护计划的信息，以解决软件开发生命周期的这些方面。对于“主要关注级别”设备，建议您提供足够的详细信息，以使您对配置管理和维护计划有透彻的了解。

对于中等关注级别的设备，建议您仅提供配置管理和维护计划的摘要。

（一）验证和确认文件

本文档前面介绍的术语“验证”和“验证”是指软件设备测试的两个阶段。本部分根据关注级别，建议您应在软件设备的上市前提交中包括的测试文档类型。

（二）次要关注设备对于次要级别的设备，我们建议您提交有关系统或设备级别测试以及适当时集成测试的文档。提交的文档应包括系统或设备级别的测试通过/失败标准以及测试结果的摘要。

（三）中等程度的关注设备

对于中等关注级别的设备，我们建议您提交验证和验证活动以及这些活动的结果的摘要列表。我们还建议您提交通过/失败标准。您应确保可追溯性分析有效地将这些活动和结果链接到您的设计要求和规格。

（四）主要关注设备

对于“主要关注级别”设备，我们建议您提交以上“中等关注级别”设备推荐的信息，以及未通过的任何测试的描述。

我们还建议您包含针对失败的测试所做的任何修改，以及结果证明该修改有效的文档。您提交的文件中提供的文档应包括单元集成测试的示例以及结果的摘要。

（十二）修订级别历史

您的提交应包括在产品开发过程中生成的软件修订历史。这通常采用行项目表的形式，列出了开发周期中软件的主要更改，包括日期，版本号以及相对于先前版本的版本更改的简要说明。

列表中的最后一个条目应该是要合并到已发布设备中的最终版本。该条目还应包括软件的测试版本与发行版本之间的任何差异，以及对差异对设备安全性和有效性的潜在影响的评估。

（十三）未解决的异常（缺陷或缺陷）

对于中等和主要关注级别的软件设备，提交的内容应包括所有未解决的软件异常的列表。对于每个异常，我们建议您指出：

1、问题；

2、对设备性能的影响；

3、任何纠正问题的计划或时间表（如果适用）。

我们建议您为每个项目添加注释，说明异常对设备安全性或有效性的影响，包括操作员的使用情况和人为因素。通常，此列表可以作为变更控制板或类似机制的输出生成，用于评估和处理未解决的软件异常。

我们建议您将此列表适当地传达给最终用户，以帮助设备正常运行。在所有可行的情况下，您都应包括任何缓解措施或未解决异常的可能解决方法；该建议尤其适用于血液建立计算机软件。

（十四）特殊510（k）计划

要使售前提交的产品符合特殊510（k）计划的审查资格，该设备应是您拥有的510（k）已清除设备的修改，修改时不得更改设备的预期用途或基础科学技术vii。

在Special510（k）中，您应遵循本指南中有关提交文档的建议，但仅提交与提示提交的修改相关的文档。例如，在Special510（k）中提交要求和规范的文档时，文档应侧重于修改，并且不一定包含整个设备的所有要求和规范。

我们建议您提交执行的回归测试，以验证和验证修改。我们建议您提交测试计划，通过/失败标准和摘要结果，而不是测试数据。在所有情况下，与软件有关的文档的类型和您提供的详细程度应适合于与设备有关的修改所涉及的关注级别。

由于特殊510（k）提交依赖于您对设计控件的符合性声明，因此我们认为，您必须完成声明所依赖的测或其他活动，才能正确提交特殊510（k）（请参阅第514（c）节）联邦食品，药品和化妆品法案（Act）（21USC360d（c）（1）（B））（1）（B）。

（十五）510（k）缩写程序

简略510（k）提交必须包括21CFR807.87中标识的必需元素。在缩写510（k）中，FDA可能认为本指南中推荐的文档内容为21CFR807.87（f）或（g）含义内的适当支持数据。因此，我们建议您提交本指南中描述的文档。viii如果您选择在设备设计或测试的任何部分依赖FDA认可的标准，则可以包括：1、声明将在产品上市之前进行测试并符合指定的接受标准；2、要么符合标准的声明。ix由于符合性声明基于测试结果，因此我们认为您必须在完成标准描述的测试后才能正确提交符合性声明。有关更多信息，请参阅该法令的第514（c）（1）（B）节和FDA指南“在等效性确定中使用标准”。x

如果您声明符合为您的软件设备推荐特定测试或测试方法的标准，我们建议您提交合格/不合格标准和相关测试结果的文档以及一致性声明。我们还建议您列出与标准中指定的测试和测试方法的偏差，并根据对软件设备的安全和有效性的影响来解释这些偏差。FDA认可的共识标准列表可在CDRH网站上找到。xi

其他主题

1、风险评估与管理背景软件开发生命周期和风险管理活动不当或不当，软件设备的不当使用或操作错误可能导致各种潜在的故障或设计缺陷。其中包括不安全或无效的能量，药物输送以及维持生命或维持生命的功能。传递错误或不完整的信息会导致诊断或选择错误的治疗或疗法，这也是与某些软件设备相关的潜在故障。因此，与潜在的故障或设计缺陷相关的风险是软件设备审查期间要考虑的问题。风险评估和关注程度如前所述，您对与软件设备相关的风险的评估应有助于您确定适当的关注级别。我们还建议您考虑具有相同通用类型或预期用途的其他设备的关注级别。如果您认为不同的关注级别适合您的设备，建议您提交详细的理由说明。

2、风险管理

与软件设备相关的风险在整个连续过程中从可忽略不计到非常严重。总体而言，FDA将风险视为伤害严重程度及其发生概率的乘积。但是，软件故障本质上是系统性的，因此无法使用传统的统计方法确定发生的可能性。

因此，我们建议