您当前的位置:检测资讯 > 法规标准
嘉峪检测网 2021-11-11 14:07
工业和 FDA 员工指南
医疗器械所含软件的上市前提交内容指南
文件发布日期:2005 年 5 月 11 日
本文件取代 5 月 29 日发布的《医疗器械所含软件的上市前提交内容指南》,
1998 年,以及血液建立计算机软件的上市前通知提交者审阅指南,于 1997
年 1 月 13 日发布。
有关与 CDRH 管制的设备有关的本文档的问题,请致电(301)796-6325 与Linda Ricci 联系。有关本文档中有关受以下法规管制的设备的问题CBER 请致电(301)827-6136 与Linda Weir 联系。
前言
(一)公众意见
意见和建议可随时提交给美国食品药品管理局药物管理部门,邮编为 5630 Fishers Lane,1061 室,(HFA 305),马里兰州罗克维尔,邮政编码 20852。提交意见时,请参阅该指导文件的确切名称。在下次修改或更新该文件之前,FDA 不得对评论采取行动。
(二)额外副本
基德
其他副本可以从Internet 上找到:http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM089543.htm,您也可以发送电子邮件请求至dsmica@fda.hhs.gov 接收指南的电子副本或将传真请求发送到 301-847-8149 以接收纸质副本。请使用文件编号(337)识别您所要求的指南。
克贝尔
可以从传播,培训和制造商协助办公室(HFM-40),1401 Rockville Pike,Rockville,MD 20852-1448或致电1-800-835-4709 或 301-827-1800获得本指南的其他副本,或通过http://www.fda.gov/cber/guidelines.htm.
工业和 FDA 员工指南
医疗器械所含软件的上市前提交内容指南
(一)介绍
本指南文档旨在向业界提供有关我们建议您将其包括在软件设备的上市前提交中的文档的信息,这些文档包括独立的软件应用程序和包含软件的基于硬件的设备。本文档是不断努力以更清楚地陈述我们的建议并确保它们随着技术进步而保持最新的结果。该文档还合并为先前包含在两个指南文档中的一个指南建议。
(二)减轻负担
本指导文档中确定的问题代表了我们认为应在设备上市之前应解决的问题。在制定指南时,我们仔细考虑了机构决策的相关法定标准。我们还考虑了您遵循指南并解决我们发现的问题可能会带来的负担。
我们认为,我们已经考虑了解决指导文件中提出的问题的负担最小的方法。但是,如果您认为解决问题的方法不那么繁重,则应遵循指南“解决最轻负担问题的建议方法”中概述程序 , http://www.fda.gov/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 法规)(21 CFR 第 820 部分)的要求创建和维护与软件有关的文档。与其他提供建议的FDA 指导文件一样,请注意,遵循本指南的建议并不能代替遵守 QS 法规。
2、与软件相关的共识标准
与软件有关的共识标准的出现有助于提高软件开发和文档编制的一致性和质量,特别是在诸如风险评估和管理等关键活动方面。在可能的情况下,我们将本指南中的术语和建议与与软件相关的共识标准(例如 ISO 14971v 和 AAMI SW68。vi)进行协调。
(五)术语
1、验证与确认
本文档使用 QS 法规中定义的术语“验证”和“验证”(也称为“ V&V”)。iv验证“是指通过检查并提供客观证据证明已满足指定要求的确认。” 21 CFR 820.3(aa)。
在软件开发环境中,软件验证可以确认特定开发阶段的输出满足该阶段的所有输入要求。软件测试是旨在确认软件开发输出满足其输入要求的几种验证活动之一。其他验证活动包括:
1、穿行;
2、各种静态和动态分析;
3、代码和文件检查;
4、模块级测试;
5、 集成测试。
设计验证“是指通过客观证据确定设备规格符合用户需求和预期用途。” 21 CFR 820.3(z)(2)。在本文档中,术语“验证”的使用仅限于设计验证,并且不包括 21 CFR 820.3(z)(1)中定义的过程验证。设计验证的一个组成部分是软件验证。
软件确认是指通过客观证据证明软件符合用户的需求和设备的预期用途。软件验证是成品设备设计验证的一部分。它涉及检查软件在其实际或模拟使用环境中是否正常运行,包括在适当情况下集成到最终设备中。
软件验证高度依赖于先前在软件开发生命周期的每个阶段完成的全面软件测试和其他验证任务。好的软件工程的规划,验证,可追溯性,配置管理和许多其他方面都是重要的活动,它们共同有助于支持软件已验证的结论。
2、轻伤和重伤
就本文档而言,我们使用轻伤一词是指不符合 21 CFR 803.3(bb)(1)中定义的重伤定义的任何轻伤。该法规将严重伤害定义为以下伤害或疾病:
i. 威胁生命;
ii. 导致身体功能的永久性损害或身体结构的永久性损害;
iii. 必须采取医学或外科手术干预措施,以防止身体功能永久受损或对身体结构造成永久损坏。就本文档而言,术语“永久性”定义为“对身体结构或功能的不可逆转的损害或损害, 不包括琐碎的损害或损害。” 21 CFR 803.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.基于关注级别的文档
软件说明文件 |
小问题 |
适度的关注 |
主要关注 |
关注程度 |
表示关注级别的声明,以及对该级别的理由的描述。 |
||
软体说明 |
功能和软件操作环境的概述。 |
||
设备危害分析 |
以表格形式描述已识别的硬件和软件危害,包括严重性评估和缓解措施。 |
||
软件需求规范 (SRS) |
SRS 的功能要求摘要。 |
完整的 SRS 文档。 |
|
建筑设计图 |
提交中不需要任何文档。 |
功能单元和软件模块的详细描述。可能包括状态图和流程图。 |
|
软件设计规范 (SDS) |
提交中不需要任何文档。 |
软件设计规范文档。 |
|
可追溯性分析 |
需求,规范,已识别的危害和缓解措施以及验证和确认测试之间的可追溯性。 |
||
软件开发环境说明 |
提交中不需要任何文档。 |
软件生命周期开发计划摘 要,包括配置管理摘要和 |
软件生命周期开发计划摘要。在开发过程中生成的带注释的控制文档列表。包括 |
软件说明文件 |
小问题 |
适度的关注 |
主要关注 |
保养 |
组态 |
||
活动。 |
管理和维护计 划文件。 |
||
验证和 |
软件 |
说明 |
说明 |
验证 |
功能测试 |
的V&V 活动 |
的V&V 活动 |
文档 |
计划,通过/ 失败标准和结果。 |
单元,集成和系统级 别。 系统级别的测试协议,包括通过/失败标准和测试结果。 |
单元,集成和系统级别。 单元,集成和系统级测试协议, 包括通过/失败标准,测试报告, 摘要和测试结 |
修订级别历史 |
修订历史记录日志,包括发行版本号和日期。 |
||
未解决的异常 |
没有 |
剩余软件异常的列表, |
|
(缺陷或缺陷) |
提交中需要提供文档。 |
并附有对安全性或有效性的影响的解释,包括操作员的使用和人为因素。 |
关注程度
我们建议您指出在缓解措施生效之前确定的软件设备的关注级别。我们建议您明确说明三个关注级别中的哪个级别适合您的设备,并包括决定依据的文档。我们还建议您的文件使您的决策过程对FDA显而易见。
(一)软体说明
我们建议您提供由软件控制的设备功能的全面概述,并描述预期的操作环境。通常, 我们建议您以段落格式提供信息,并突出显示主要的或对操作有重要意义的软件功能。软件说明应包括以下信息:
1、程式语言;
2、 硬件平台;
3、操作系统(如果适用);
4、使用现有软件(如果适用)。
如果您的设备使用现成的软件,请参阅 FDA 指导文件“医疗设备中现成的软件使用指南”iii。如果此信息包含在另一个文档(例如,软件需求规范)中,则您的提交应在该信息所在的提交中包含注释和对该文档的引用。
(二)设备危害分析
我们建议您为所有软件设备提交设备危害分析。设备危害分析应考虑与设备预期用途相关的所有设备危害,包括硬件和软件危害。我们建议您以表格形式提供信息, 并为每个已识别的危害提供一个选项行。
该文档可以是从全面的风险管理文档中提取与软件相关的项目的形式,例如ISO 14971 中描述的“风险管理摘要”。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。
在 Special 510(k)中,您应遵循本指南中有关提交文档的建议,但仅提交与提示提交的修改相关的文档。例如,在 Special 510(k)中提交要求和规范的文档时,文档应侧重于修改,并且不一定包含整个设备的所有要求和规范。
我们建议您提交执行的回归测试,以验证和验证修改。我们建议您提交测试计划,通过/失败标准和摘要结果,而不是测试数据。在所有情况下,与软件有关的文档的类型和您提供的详细程度应适合于与设备有关的修改所涉及的关注级别。
由于特殊 510(k) 提交依赖于您对设计控件的符合性声明,因此我们认为,您必须完成声明所依赖的测或其他活动,才能正确提交特殊 510(k)(请参阅第 514(c)节)联邦食品,药品和化妆品法案(Act)(21 USC 360d(c)(1)(B))(1)(B)。
(十五)510(k)缩写程序
简略 510(k)提交必须包括 21 CFR 807.87 中标识的必需元素。在缩写 510(k)中, FDA 可能认为本指南中推荐的文档内容为 21 CFR 807.87(f)或(g)含义内的适当支持数据。因此,我们建议您提交本指南中描述的文档。viii
如果您选择在设备设计或测试的任何部分依赖 FDA 认可的标准,则可以包括:
1、声明将在产品上市之前进行测试并符合指定的接受标准;
2、要么 符合标准的声明。ix
由于符合性声明基于测试结果,因此我们认为您必须在完成标准描述的测试后才能正确提交符合性声明。有关更多信息,请参阅该法令的第 514(c)(1)(B)节和 FDA 指南“在等效性确定中使用标准”。x
如果您声明符合为您的软件设备推荐特定测试或测试方法的标准,我们建议您提交合格/不合格标准和相关测试结果的文档以及一致性声明。我们还建议您列出与标准中指定的测试和测试方法的偏差,并根据对软件设备的安全和有效性的影响来解释这些偏差。FDA 认可的共识标准列表可在CDRH 网站上找到。xi
其他主题
1、风险评估与管理
背景
软件开发生命周期和风险管理活动不当或不当,软件设备的不当使用或操作错误可能导致各种潜在的故障或设计缺陷。其中包括不安全或无效的能量,药物输送以及维持生命或维持生命的功能。
传递错误或不完整的信息会导致诊断或选择错误的治疗或疗法,这也是与某些软件设备相关的潜在故障。因此,与潜在的故障或设计缺陷相关的风险是软件设备审查期间要考虑的问题。
风险评估和关注程度
如前所述,您对与软件设备相关的风险的评估应有助于您确定适当的关注级别。我们还建议您考虑具有相同通用类型或预期用途的其他设备的关注级别。如果您认为不同的关注级别适合您的设备,建议您提交详细的理由说明。
2、风险管理
与软件设备相关的风险在整个连续过程中从可忽略不计到非常严重。总体而言, FDA 将风险视为伤害严重程度及其发生概率的乘积。但是,软件故障本质上是系统性的,因此无法使用传统的统计方法确定发生的可能性。
因此,我们建议您基于故障导致的危害的严重性来估计软件设备的风险,并假设故障会发生。我们还建议您使用共识标准(例如 ISO 14971)中描述的风险识别和控制技术。
3、软件变更管理
对软件修订版的设计,开发,测试和版本控制与在上市前提交的软件中开发和测试的软 件一样重要。我们认为,本领域中发生的大多数与软件相关的设备问题,包括与软件相关的设备召回,都发生在运行自上市前审查以来已修订的软件的设备上。
在某些情况下, 不需要 FDA 审查的修订会导致不良事件和召回。xii 我们认为,这表明需要仔细控制软件的修订。
4、血液建立计算机软件
在血液建立计算机软件的上市前提交中,您应提交《用户手册》的完整副本,因为该手册将提供给用户,包括但不限于所有限制的描述。
此外,如果用户手册中未解决这些问题,则应提交将提供给用户的文档,以描述所有未解决的异常或软件缺陷以及相应的解决方法。
5、未知谱系软件(SOUP)
提交者可能已从第三方获得了软件设备中包含的某些或全部软件。该软件随附的文档类 型和质量可能相差很大。可能难以获得足够文档的软件称为“未知谱系软件”或“ SOUP”。
如本 SOUP 指南中所述,您可能难以获取,生成或重构适当的设计文档。因此,我们建议您解释软件的来源以及软件文档的周围情况。
此外,您的危害分析应涵盖与SOUP 相关的风险,即缺少或不完整的文档或缺乏先前测试的文档。尽管如此,仍然需要您负责设备的适当测试以及提供软件测试计划和结果的适当文档。
6、病毒防护软件
随着设备之间的联系日益紧密,因此暴露于外部信息环境中,旨在保护信息系统(包括软件设备)免受有害或恶意代码(“病毒”,“蠕虫”等)侵害的软件应用程序正变得越来越普遍。
与病毒防护软件的安装和测试有关的问题不在本文档的范围之内。您可以联系 CDRH 合规办公室以获取有关此主题的更多信息。
7、接口,网络和网络基础结构
如上所述,通过用于与特定设备交换特定数据的点对点接口以及通过连接到局域网和广域网以及 Internet,软件设备之间的互连越来越多。
虽然没有将诸如电话线,局域网和宽带连接之类的数据交换和通信基础设施作为医疗设备进行管理,但与这些运营商的连接会影响软件设备的运行,有时会产生不利影响。
一个示例是连接到局域网并且在网络接口出现问题时停止正常运行的软件设备。我们建议您的软件设计应同时考虑设备随附的接口的功能和责任,尤其是危害分析和缓解措施应涵盖这些问题。
8、组合产品
通常,当设备组件符合软件设备的定义时,本指南的建议将适用于组合产品的设备组件(例如药品设备和生物制剂设备组合)。有关更多信息,您可以联系组合产品办公室或FDA 审查部门,该部门将对您的组合产品进行牵头审查。
来源:Internet