Software as a Medical Device (SaMD): Application of Quality Management System
文件编号: IMDRF/SaMD WG/N23FINAL:2015
官方来源
https://www.imdrf.org/documents/software-medical-device-samd-application-quality-management-system
INFO
This content has been machine-translated from the English original.
全文
软件为医疗器械 (SaMD)：质量管理体系的应用
Document Number: IMDRF/SaMD WG/N23FINAL:2015
Source: https://www.imdrf.org/documents/software-medical-device-samd-application-quality-management-system
IMDRF/SaMD WG/N23 最终版：2015
最终文档
国际医疗器械监管论坛
标题： 软件为医疗器械 (SaMD)：质量管理体系的应用
编写组: IMDRF 软件为医疗器械 工作组
日期： 2015年10月2日
东志幸·富米，IMDRF主席
本文件由国际医疗器械监管论坛制作。 本文件的复制或使用不受限制；但是，将本文件（或其中一部分）纳入其他文件中，或将其翻译成其他语言，并不代表国际医疗器械监管论坛的认可。
© 2015年 国际医疗器械监管论坛 版权所有。
目录
1.0 简介 4
2.0 范围 5
3.0 参考文献 7
4.0 定义 7
5.0 SaMD 质量管理原则 8
6.0 SaMD 领导力和组织支持 10
6.1 组织内的领导力和责任 10
6.2 人员和基础设施的管理 10
6.2.1 人员 11
6.2.2 基础设施和工作环境 11
7.0 SaMD 生命周期支持流程 12
7.1 产品规划 12
7.2 风险管理：以患者安全为导向的过程 13
7.3 文档和记录控制 15
7.4 配置管理和控制 15
7.5 流程和产品的测量、分析和改进 16
7.6 管理外包流程、活动和产品 17
8.0 SaMD 实现和使用流程 19
8.1 要求管理 19
8.2 设计 21
8.3 开发 22
8.4 验证和确认 23
8.5 部署 24
8.6 维护 26
8.7 停用 (退役或生命周期结束活动) 27
附录 A：将医疗器械法规映射到 IMDRF/SaMD WG/N23 29
前言
本文件由国际医疗器械监管论坛 (IMDRF) 制作，IMDRF 是一组来自世界各地的医疗器械监管者的自愿团体。 本文件在开发过程中接受了广泛的咨询。
本文件不受任何限制，可以复制、分发或使用；但是，将本文件（或其任何部分）纳入其他文件，或将其翻译成其他语言，并不代表国际医疗器械监管论坛（IMDRF）的认可或支持。
简介
国际医疗器械监管论坛（IMDRF）旨在建立对医疗用途（特别是针对特定类型的医疗用途软件）的共同理解。IMDRF“软件作为医疗器械”工作组（WG）将此类软件定义为“软件作为医疗器械”（SaMD），具体参见_IMDRF/SaMD WG/N10_文件《软件作为医疗器械（SaMD）：关键定义》；该文件为建立共同术语奠定了基础，并为制造商和监管机构定义了SaMD。
SaMD工作组还提供了基于对患者和公众健康的影响的SaMD类型分类框架，具体参见_IMDRF/SaMD WG/N12_文件《软件作为医疗器械：可能的风险分类框架及其相关考虑》。 该框架为对SaMD进行分类，采用基于SaMD提供的信息对医疗决策的重要性以及SaMD所使用的医疗状况或条件相结合的标准，从而建立了一种共同的方法。
_IMDRF/SaMD WG/N12_文件还强调了质量管理在确保SaMD的安全性、有效性和性能方面的普遍考虑，以及作为确保SaMD可预测性和质量的关键。
质量管理系统 (QMS) 原则，对于许多工业领域，可以在 ISO 9000 系列标准中找到。此外，还有各种当前行业软件开发生命周期方法、指南和标准，这些标准涵盖了软件工程质量实践的许多方面的最佳实践。这些原则是组织（无论规模大小，从小型企业到跨国公司）保持和控制产品质量的良好实践的基础。
在医疗器械领域，通常被认为是遵循 QMS 要求是用于减少和管理与患者安全相关的意外结果的一种控制措施。医疗器械的 QMS 要求由监管机构在其法规和国际标准 ISO 13485— 医疗器械—质量管理系统—用于监管目的 中定义。
在软件行业，良好的软件质量和工程实践被用于控制软件产品的质量。这些实践可以很容易地与医疗器械 QMS 要求的通用原则相对应，尤其是在将患者安全作为重点时。
本文重点介绍了良好的软件质量和工程实践，并强调了医疗器械质量原则，这些原则应适当纳入，以实现有效的 SaMD QMS。
本文是 IMDRF/SaMD WG/N10 和 N12 文档的补充，进一步促进了监管机构和行业的用语、方法和共同思考的融合。
范围
本文件的目标是提供有关如何将现有的标准化的和普遍接受的质量管理系统（QMS）实践应用于SaMD的指导。此外，本文件的目的是：
告知读者关于SaMD的特定实践。 假设读者遵循普遍接受的软件生命周期流程[1]，并且可能不熟悉医疗器械的QMS；
提供有关如何应用QMS来管理负责交付SaMD产品和管理SaMD生命周期支持流程（产品规划；风险管理；文档和记录控制；配置管理和控制；流程和产品的测量、分析和改进；以及管理外包流程、活动和产品）以及SaMD实现和使用流程（需求管理、设计、开发、验证和确认、部署、维护和退役）的指导；
从患者安全、临床环境以及技术和系统环境的考虑角度，突出SaMD的实现和使用流程，这些流程应被解决，以确保SaMD的安全、有效性和性能；
帮助制造商和监管机构达成对将医疗器械质量管理系统要求应用于SaMD的共同理解和术语；以及
补充IMDRF的SaMD框架，该框架包含在《IMDRF/SaMD WG/N12》中找到的风险分类和相应的考虑因素。
本文件 intended for the following audience:
开发者（包括个人和/或团体）以及希望成为SaMD开发者的群体；
软件开发组织（大型或小型），采用良好的软件质量和工程实践，并且可能并不熟悉医疗器械的质量管理体系（QMS）要求；以及
在已建立的医疗器械质量体系中工作的组织（部门/部门），旨在沟通医疗器械质量体系实践与软件开发实践之间的联系。
文档组织和内容：
使用的术语旨在让软件行业熟悉，并说明典型的软件工程活动（例如，确定要求）如何转化为医疗器械质量管理体系中（例如，识别设计输入）所使用的等效活动，这些活动用于管理、设计、开发、实施、监控和支持 SaMD（软件为医疗用途）；
各部分按软件工程生命周期方法中常见的流程和活动以及组织整体的领导和管理流程进行组织；
SaMD 的生命周期支持流程（第 7 节）和实现和使用流程（第 8 节）包括必要的考虑因素，以解决与患者安全、临床环境以及 SaMD 的技术和系统环境相关的方面；
为了突出一些关键要点，提供了使用两个虚构公司——Magna（大型组织）和 Parva（小型初创公司）的示例；
参考 ISO13485:2003，这是一项目前在医疗器械行业中发布的质量管理体系（QMS）标准。
应用范围：
本文提供的 QMS 应用指导适用于根据 IMDRF/SaMD WG/N10 定义的 SaMD，但不适用于其他类型的软件；
本文侧重于 SaMD，无论其采用的技术和/或平台（移动应用程序、云、服务器等）。
本文件不旨在：
提供关于如何实施良好软件质量和工程实践或实施 QMS 的指导；以及
修改、重复或与医疗器械法规或标准中阐述的 QMS 原则相矛盾。
与法规要求和技术标准的关系：
本文件不取代或创建新的 QMS 标准、软件质量和工程实践或法规；相反，它强调了成功的软件组织常用的某些常见做法和术语；
本文件不旨在取代或与个体监管辖区要求的医疗器械立法、法规或程序相冲突；
本文件不是关于软件风险管理实践的教程；相反，它强调了贯穿软件生命周期过程和活动中的风险管理原则，这些原则对于 SaMD 的安全、有效性和性能至关重要；
本文中所强调的活动不旨在取代或与与软件风险管理活动或软件开发实践相关的技术或流程标准的内容和/或开发相冲突，但可能为这些过程和活动提供输入。
参考文献
IMDRF/SaMD WG/N10 - 软件作为医疗器械 (SaMD): 关键定义。
IMDRF/SaMD WG N12 - 软件作为医疗器械: 风险分类和相应考虑的可能框架。
ISO 13485:2003 – 质量管理系统 – 适用于监管目的的要求。
定义
本文件不引入任何新的定义，而是依赖于以下内容：
SaMD 的定义，如在 IMDRF/SaMD WG/N10 中所定义。
通常在标准和法规中，与医疗器械的质量管理系统 (QMS) 相关的术语。
软件质量和工程实践中使用的术语和词汇。
SaMD 质量管理原则
医疗器械的 QMS 原则允许根据医疗器械的类型、产品对患者的风险、组织规模、用于制造的技术或自动化程度以及制造商确定的其他因素来调整活动，以控制质量并确保医疗器械的安全有效运行。
SaMD 的制造，即仅为软件的产品，主要基于软件开发生命周期的活动，通常借助自动化软件开发工具（如构建自动化、使用源代码管理工具等）。这些自动化活动在某些情况下可以替代硬件产品制造中常见的离散或有目的的活动（例如，将设计转移到生产）。然而，为 QMS 提供结构和支持生命周期流程和活动，仍然适用于并对控制 SaMD 的质量至关重要。
一个有效的 SaMD QMS 应该包括以下原则：
建立组织结构，提供领导、问责制和治理，并配备足够的资源，以确保 SaMD 的安全、有效和性能（图 1 中的外圈）；
一套可扩展的 SaMD 生命周期支持流程，适用于组织规模，并在所有实现和使用过程中保持一致（图 1 中的中间圆）；以及
一套适用于 SaMD 类型[2]和组织规模的实现和使用流程；并考虑到确保 SaMD 安全、有效和性能所需的重要要素（图 1 中的最内圆）。
图 1：SaMD 质量管理原则：领导和组织支持、流程和活动
上述三项原则不应被视为组织中独立运行的流程系列。相反，有效的质量管理体系（QMS）应建立三项原则之间的明确关系（参见下方的图 2）：
领导和组织支持的治理结构应为 SaMD 生命周期支持流程提供基础；以及
SaMD 生命周期支持流程应应用于 SaMD 的实现和使用流程。
图 2：质量管理原则之间的关系
本节中介绍的概念与 ISO 13485:2003 的第 4 条和第 5 条相关。
SaMD 的领导和组织支持
组织中的领导力和责任
组织的管理层负责所有与 SaMD 生命周期流程相关的活动的领导和治理，包括定义战略方向、责任、权限和沟通，以确保 SaMD 的安全有效运行。
领导力和组织支持
SaMD 实现和使用流程
SaMD 生命周期支持流程
组织领导层还负责实施 QMS，这可能包括制定质量政策、质量目标以及以客户为中心的特定项目计划。
治理结构应为创建和建立适当流程提供支持，这些流程对于维持质量目标和政策[3]至关重要。
此外，治理还应包括系统性验证已建立质量管理体系有效性的活动，例如进行 QMS 内部审计。对 QMS 审计结果的管理审查，是确保已建立的 QMS 适合、充分且有效，并可以根据需要进行必要的调整的工具。
例如：Magna 和 Parva 的管理层都有责任确保已建立 QMS，并将必要的患者安全考虑纳入 QMS 中，并在进入 SaMD 市场时进行管理。在 Magna 的情况下，公司拥有组织结构，将首席医疗官指定为负责这些方面的负责人。在 Parva 的情况下，公司指定软件开发经理负责纳入必要的患者安全方面。
本部分介绍的概念与 ISO 13485:2003 的第 5 条和第 8.2.2 条相关。
资源和基础设施管理
资源管理的目的是提供适当的资源（包括人员、工具、环境等），以确保 SaMD 生命周期流程和活动能够满足法规和客户要求，从而有效运行。
本部分介绍的概念与 ISO 13485:2003 的第 6 条相关。
人员
重要的是确保参与 SaMD 项目的人员具备胜任工作的能力。对于 SaMD，这样的团队应具备技术和软件工程方面的专业知识，包括对软件使用临床方面的理解。
例如：两家公司都认识到确保有具备相应能力的员工的重要性。在 Magna 的情况下，员工的技能基础较为广泛，通过扩展现有的内部培训和教育项目来弥补 SaMD 技能差距。而 Parva 则通过寻找其他来源，如临时招聘和外部培训项目来弥合技能差距。
本部分介绍的概念与 ISO 13485:2003 的第 6.1 条和第 6.2 条相关。
基础设施和工作环境
基础设施，如设备、信息、通信网络、工具以及物理场所等，应在 SaMD 生命周期流程中得到充分利用。 这种基础设施用于支持 SaMD 的开发、生产和维护，因此需要提供和维护。
[术语表 - 在这些术语出现时，请使用这些确切的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
对于 SaMD，这可能包括识别并提供支持 SaMD 实现和使用流程的软件开发和测试环境。 这可能包括提供一个模拟预期使用环境的测试环境，以及支持在整个生命周期过程中管理各种软件配置的工具，例如，在开发过程中对源代码的版本管理。
随着工作环境变得越来越虚拟，集体基础设施环境的可靠性和稳定性是一个重要考虑因素（例如，对第三方网络和设备的依赖）。
例如：两家公司都需要特定的环境，以确保在这些不同的基础设施环境中代码和数据的完整性。 在 Magna 的情况下，现有的计算机网络和安全的建筑物访问直接用于 SaMD 的开发。 在 Parva 的情况下，开发环境由合格的服务提供商托管，确保代码和数据的完整性是他们与提供商之间的服务协议的一部分。
本节中介绍的概念与 ISO 13485:2003 的第 6.3 条和第 6.4 条相关。
SaMD 生命周期支持流程
一个组织的质量管理体系 (QMS) 应该建立和管理围绕支持 SaMD 生命周期活动的流程。
领导力和组织支持
SaMD 实现和使用流程
SaMD 生命周期支持流程
本节涉及适用于 SaMD 整个生命周期的重要流程，无论 SaMD 的预期用途如何（即，SaMD 提供的信息对医疗决策的重要性以及医疗状况或情况的状态）。
[术语表 - 在这些术语出现时，请使用这些确切的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
有许多可用的方法来实施 SaMD 的生命周期流程。这些流程通常被调整以应对 SaMD 产品和项目的复杂性和规模（例如，在推出新产品或进行升级时），需要进行创建。
本部分讨论的元素是常见的流程和活动，应在 SaMD 的整个生命周期中加以考虑，无论组织采用的具体软件产品开发方法或方法。
适当实施明确结构化且一致可重复的决策流程，可以使 SaMD 组织对努力减少患者安全风险和促进患者安全有所信心。
产品规划
规划的目标是为产品开发生命周期提供路线图。这源于质量原则，即通过对项目（如计划-执行-检查-行动）进行有条理和严格的管理，可以获得更好的结果。
产品规划包括定义阶段、活动、责任和为开发 SaMD 所需的资源。重要的是要理解，规划不是静态的——当获得新信息或达到里程碑时，需要进行更新。
IMDRF/SaMD WG/N12 确定，对于 SaMD，充分理解社会技术[4]环境（临床视角）和技术和系统环境（软件视角）在规划中非常重要，因为不充分的考虑可能导致错误的、不准确的和/或延迟的诊断和治疗。[5]
SaMD 的生命周期流程的实施应充分了解并根据 IMDRF/SaMD WG/N12 识别的 SaMD 类型进行调整。
示例：两家公司都进行产品规划，以确定哪种操作系统最适合其 SaMD 应用程序。规模较大的 Magna 公司选择将其应用程序构建为在五大主流移动操作系统上运行，因为该公司有资源来在多个平台上开发。而较小的 Parva 公司则选择开发在目前市场领先的平台上，这是由于该公司资源有限。对于 Parva 和 Magna 而言，这一规划阶段可以使每家公司能够有意识地分配资源。
本部分介绍的概念与 ISO 13485:2003 的第 5.4 条、第 7.1 条和第 7.3.1 条相关。
风险管理：以患者安全为重点的过程
IMDRF/SaMD WG/N12 提供了一个框架，用于根据对患者和公众健康的潜在影响对 SaMD 进行分类。利用 IMDRF/SaMD WG/N12 中的基础分类，适当的风险管理可以提高 SaMD 的安全、有效性和性能。 这种风险管理过程应贯穿 SaMD 的整个生命周期。
从事通用软件开发的组织，会持续监控和管理软件项目的进度和预算风险。 同样，SaMD 组织也应监控和管理在所有生命周期过程中，对患者和用户的风险。
对于 SaMD，产品风险应基于其预期用途、正常使用和合理可预见的误用，以及 SaMD 的使用环境。 与 SaMD 患者安全风险相关的常见考虑因素包括，由于 SaMD 的非物理特性，SaMD 的更新、复制和分发是否容易，以及 SaMD 组织提供的这些更新是否可以被其他人安装。
在本文档的背景下，风险管理采用基于风险的方法来保障患者安全。[6] 具体来说，与质量管理体系（QMS）相关，应考虑以下要点：
识别危害；
评估并评估相关的风险；
采取控制风险的措施；以及
采用方法来监测实施的控制风险措施的有效性。
例如，有助通过多个维度（例如：）来绘制危害来源：
基于用户的
该 SaMD 产品是否适用于所有预期用户？例如，对于老年用户或患有周围神经病变的患者，是否存在视觉敏锐度带来的危害？该设备是在临床或家庭环境中使用的吗？
基于应用的
如果某个软件定义医疗器械（SaMD）应用可以在任何设备上使用，或者是否应该将其限制在某些设备上，从而有助于降低用户风险？
基于设备
该设备（例如智能手机）具有较小的屏幕，是否适合其预期用途？ 较小的屏幕是否能够同时显示大量信息，而不会导致信息丢失或使用户操作变得复杂，从而影响患者安全？
基于环境的
当存在环境干扰（例如，使用中断、背景噪音、网络连接中断）时，SaMD产品的持续使用（以及因此而产生的安全性）是否受到影响？
基于安全性的
是否正在进行分析，以评估 SaMD 产品软件代码在制造、维护和使用过程中面临的安全威胁？ 这种分析是否还包括，例如，入侵检测、渗透测试、漏洞扫描和数据完整性测试，以最大限度地减少系统和患者的风险？
软件风险管理需要对安全和安全风险进行平衡评估。 安全风险可能会影响由 SaMD 处理的数据的保密性、完整性和可用性。 在考虑保护设备安全时，制造商应确保安全风险控制不应优先于安全考虑。
示例：Magna 和 Parva 都了解在其 SaMD 生命周期中进行系统性风险管理活动的重要性。Magna 设有专门部门，其成员确保产品的风险在可接受的范围内，包括考虑患者伤害。Parva 决定对 SaMD 开发者进行风险管理培训，并利用这些知识，他们共同确保产品的风险在可接受的范围内，包括考虑患者伤害。以上两种方法都确保进行必要的风险管理活动。
本部分介绍的概念与 ISO 13485:2003 第 7.1 条相关。
文档和记录控制
记录用于提供证明在 QMS 或 SaMD 生命周期流程中取得的成果或执行的活动，以及对未执行的任何 QMS 或 SaMD 生命周期流程的理由。记录可以是纸质或电子形式。
对于 SaMD 生命周期流程，文档控制和记录管理可以使组织内部和外部（包括外包合同商、客户等）的用户更容易共享和协作，以参与与 SaMD 生命周期流程相关的各种活动。文档控制和记录管理还可以帮助沟通和保留关于为什么做出某些决定的理由，例如与患者安全或风险管理相关的决策。
用于证明 QMS 符合性的记录应得到适当的标识、存储、保护和保留一段时间。以下是一些在 QMS 系统中管理和维护适当文档的方法：
在使用前审查和批准文档；
确保适用的文档的当前版本在使用点可用，以帮助防止使用过时的文档；
保持过时的文档一段时间；
控制文档，防止未经授权或意外的更改；以及
在 SaMD 的整个生命周期流程中维护和更新文档。
例如：在 Magna 和 Parva 的情况下，重要的是在 SaMD 的生命周期流程中管理和控制文档。文档并不意味着官僚主义；相反，它是推动 SaMD 项目中可追溯性、可重复性、可扩展性和可靠性的基础。Magna 采用已建立的文档流程和技术，包括在 SaMD 的整个生命周期流程中使用可用的商业需求管理工具。Parva 重新利用其源代码控制软件，使公司能够以受控的方式管理其文档。
本部分介绍的概念与 ISO 13485:2003 第 4.2 条相关。
配置管理和控制
对配置项（包括源代码、发布版本、文档、软件工具等）的控制，对于在 SaMD 的整个生命周期中保持配置的完整性和可追溯性至关重要。
对 SaMD 以及其支持的设计和开发进行系统性的文档记录，包括健全且记录的配置和变更管理流程，对于识别其组成部分、提供对其所做的变更历史记录以及使软件的先前版本得以恢复/重建（即，SaMD 的可追溯性）是必要的。
对于 SaMD，配置也是一个重要的考虑因素，以确保 SaMD 正确安装和集成到临床环境中。这些信息使用户能够决定，例如，SaMD 是否可以与现有硬件和网络一起使用，是否需要建立不同的程序和培训，或者是否需要获得新的或重新配置现有硬件。
在 SaMD 配置的管理中，通常使用软件工具来管理源代码、发布、文档、部署、维护等。在 SaMD 中，配置管理的概念及其复杂性因 SaMD 将运行的环境的多样性而增强；使用合适的工具和技术至关重要。
例如：对于 Magna 和 Parva，配置管理的重要性已经得到了充分的理解。在两种情况下，公司的患者可以通过多个设备（例如，智能手机、PC 和平板电脑）访问 SaMD 产品，每个设备都需要特定的配置和用户体验优化。对多设备访问的需求强调了建立健全且文档化的配置管理流程的重要性，以确保产品线中各种配置的完整性和可追溯性。
本部分介绍的概念与 ISO 13485:2003 的第 4.2.3 条、第 4.2.4 条、第 7.3.7 条、第 7.5.1 条和第 7.5.3 条相关。
流程和产品的测量、分析和改进
对软件产品和流程的质量特征的测量，用于管理和改进产品实现和使用。对关键因素的有效测量，通常与与风险相关的方面有关，可以帮助识别实现安全有效的 SaMD 所需的能力。在 SaMD 生命周期过程、活动和任务之前、期间和之后，都有机会进行监测、测量和分析，以改进，并旨在客观地证明 SaMD 的质量。包括监测、测量和分析质量数据的市场后监督，可以包括记录和跟踪投诉、解决技术问题、确定问题原因和采取行动、识别、收集、分析和报告产品开发的关键质量特征。对于 SaMD，通过客观测量证明流程正在遵循，本身并不能保证软件质量，就像仅仅监测软件质量并不能保证流程目标得以实现。对于 SaMD 流程和产品的测量、分析和改进至关重要的方面包括：
基于明确的责任和预先确定的活动对 SaMD 和其生命周期流程进行评估，包括使用领先和滞后安全指标以及收集和分析适当的质量数据。对这些数据的分析，例如分析客户投诉、问题报告、错误报告、不符合产品要求的报告、服务报告以及流程和产品的趋势，应用于评估 SaMD 的质量以及 SaMD 生命周期流程的质量，并确定这些流程是否可以改进。对于 SaMD，客户投诉可能是组织应分析的主要质量数据来源。
当流程未正确执行或SaMD未满足其指定要求时，可能需要进行更正和纠正措施（即，存在不符合要求的流程或产品）。
不符合要求的SaMD应被隔离，以防止意外使用或交付。应分析已发现的不符合情况，并采取措施消除已发现的不符合情况（即，更正）；以及识别和消除已发现的不符合情况的原因（即，纠正措施），以防止未来再次发生。在某些情况下，可能会发现潜在的不符合情况，并采取诸如安全措施和流程变更等措施，以防止不符合情况的发生（即，预防性措施）。
针对SaMD不符合情况的原因采取的行动，以及针对潜在SaMD不符合情况采取的行动，应在SaMD发布前进行验证/验证，并进行有效性评估。
从对过去项目的分析中，包括对SaMD生命周期流程的内部或外部审计结果，可以用于提高SaMD的安全性、有效性和性能。制造商还应建立收集主动和被动市场后监测信息的流程，以便做出适当的决定，以关系到未来的发布。
在产品进入市场后，重要的是在市场后监测中保持警惕，以应对有意和无意的安全威胁。
示例：客户反馈是监控产品性能并使其在一段时间内不断改进的重要组成部分。Magna 和 Parva 都在开发其新的、改进版本的 SaMD。Magna 拥有一个专门部门，该部门独立工作，但与销售、市场和产品开发部门合作，正式调查其庞大的客户群，以获得有关产品性能的见解。在 Parva 的情况下，公司邀请部分早期采用者和客户进入办公室，进行圆桌讨论，以获得类似的反饋。两家公司还使用嵌入式分析工具，以了解客户在使用其各自产品时的行为。此外，两家公司也定期审查和评估客户投诉，以识别趋势和潜在的改进领域。根据对各种来源数据的审查，Magna 和 Parva 都重新设计了其 SaMD，以解决客户反馈、投诉和任何新的/更新的临床证据中识别出的常见问题。
本部分介绍的概念与 ISO 13485:2003 的第 7.2.3 条、第 7.3.7 条、第 7.5.1.1 条、第 8.1 条、第 8.2 条、第 8.3 条、第 8.4 条和第 8.5 条相关。
管理外包流程、活动和产品
一个有效的 QMS 系统会考虑到并确保 SaMD 的质量，尤其是在将流程、活动或产品外包时（即，不完全由内部进行/制造）。
一个组织可以选择外包其 SaMD 的不同部分、活动或产品，这取决于其内部的优势和能力。 类似地，一个组织可以采购商业标准产品（COTS）或另一个 SaMD，以便将其集成到其 SaMD 中。 在这两个情况下，理解、保持控制并管理这些外包流程、活动或产品的影响，对于提供安全有效的 SaMD 至关重要。
一个 SaMD 组织，例如，可以外包客户服务作为一项流程，或者外包特定 SaMD 模块的开发活动。 类似于任何外包策略，以下内容通常通过合同条款来实现，以确保对提供服务和产品的信心，从而管理或减轻 SaMD 的患者安全风险：
了解潜在外包供应商的能力和能力；
明确说明外包供应商的角色和责任；
详细定义外包流程、活动或产品的质量要求；
明确规定交付成果、中间检查的频率以及与供应商相关的审计标准；以及
选择并评估合适的供应商，以提供安全有效的 SaMD。
当一个 SaMD 组织计划采购 COTS 产品（例如，用于集成到其 SaMD 的第三方数据库），或采购另一个 SaMD 作为模块进行集成时，以下是一些示例，可以帮助理解这些决策的影响，并帮助管理对 SaMD 的影响：
了解 COTS 产品的能力和局限性，可以帮助管理 SaMD 的风险、设计选择以及所需的验证和确认范围；
了解 COTS 制造商采用的更新、改进或纠正其产品的流程/方法/频率，应用于指导 COTS 产品的选择，以及对 SaMD 制造商的 QMS 流程和活动可能产生的影响。
例如：Magna 和 Parva 历史上一直使用开源代码或其他 COTS 代码作为产品开发的一部分。 在 SaMD 的开发中，Magna 和 Parva 都必须正确验证和验证开源代码或 COTS 代码的集成。 在适当的情况下，也必须正式评估、记录和定期审计供应商，以确保符合 QMS 要求。 这两家公司还负责监控和管理 COTS 中的潜在缺陷，这些缺陷可能会对 SaMD 的整体风险做出贡献，并可能对 SaMD 所在的更大系统构成威胁。 无论使用哪种类型的代码以及谁提供代码，Magna 和 Parva 最终对 SaMD 的安全性和性能负责。
本部分介绍的概念与 ISO 13485:2003 的第 7.4、7.4.1、7.4.2、7.4.3 和第 8.5.1 条相关。
SaMD 实现和使用流程
本部分识别了组织在制造 SaMD 时应在方法中识别的关键生命周期流程[7]。
领导力和组织支持
SaMD 实现和使用流程
SaMD 生命周期支持流程
以下是本部分各项活动中应考虑的重要方面。
第 7.0 节中关于 SaMD 生命周期支持流程（产品规划；风险管理：以患者安全为重点的方法；文档和记录控制；配置管理和控制；流程和产品测量、分析和改进；管理外包流程和产品）应贯穿 SaMD 的实现和使用过程。
本节重点介绍了在软件工程生命周期方法（流程、活动、任务等）中常见的，对于有效的 SaMD QMS 至关重要的活动。
本节中呈现的活动应无论采用何种方法都应包含。 材料的呈现并不意味着在 SaMD 项目中以串行方式或作为独立的阶段执行这些活动；相反，这些活动应被视为在采用的任何开发方法中需要解决的元素。
本节中提出的概念与 ISO 13485:2003 第 7 条相关。
需求管理
制定适当的需求有助于确保 SaMD 能够满足在社会技术环境中（包括用户和患者的需求）的需求。 这些临床需求应明确阐述，并且与 SaMD 的预期用途（根据“医疗环境或状况”和“SaMD 提供的信息对医疗决策的影响”以及 IMDRF SaMD WG N12 识别的对患者和公众健康的潜在影响）相符，并记录在案。
这是一个以客户为导向的过程，需要清晰、并且经常重复的客户互动，以了解用户需求。这些用户需求随后会被转化为要求。 经过充分记录的要求，可以指导设计周期中的测试活动。 还有其他来源的，包括监管或非客户指定的性能要求。
患者安全和临床环境考虑
SaMD 在各种临床和家庭使用环境中得到应用，因此，除了功能性要求外，还存在需要考虑患者/用户安全的要求。 一些要求来源于风险管理过程，该过程评估对患者和用户的风险，并可能识别出缓解措施，这些措施会成为要求的一部分。
还需要考虑 SaMD 中使用的数据的完整性，这可能导致特定的要求，以确保数据的安全，并防止敏感数据丢失或损坏。[8]
SaMD 的要求通常需要包含额外的、具体的升级要求，这些要求应考虑对系统周边组件的潜在影响，以及与客户的适当通知和协调。[9]
技术和系统环境考虑
SaMD 运行在底层平台和操作系统上，通常由第三方提供，这些平台的和操作系统的功能应作为要求的一部分，因为这些平台和操作系统可能成为潜在的危害来源。
要求也可能需要定义系统的一些非功能性方面，例如与硬件平台相关的服务或性能要求，这些硬件平台可能托管 SaMD 或与更广泛的环境进行连接/网络。
要求应与利益相关者（患者、临床医生、最终用户等）在 SaMD 的使用过程中一起制定。
注意： 随着开发人员更好地了解 SaMD 在临床环境中的功能以及客户如何使用它，要求可能会发生变化。因此，重要的是将可用性工程原则应用于软件的成型开发和测试，以确保要求已适当转化为设计输入。
例如：定义和维护要求对于确保产品满足其预期用途至关重要。对于 Magna 和 Parva，要求旨在明确定义各自 SaMD 产品中需要开发的范围。在 Magna 的情况下，跨职能的产品团队利用现有的文档模板来记录要求，并利用现有的文档审查流程来批准要求的使用。在 Parva 的情况下，使用屏幕截图、草图和快速原型来完善和记录 SaMD 功能的产品要求。在两种情况下，要求都是以一种方式记录，以确保满足用户、患者和监管要求。
本部分介绍的概念与 ISO 13485:2003 的第 7.2.1、7.2.2、7.2.3、4.2 和 7.1d 条款相关。
设计
该设计活动的目的是，根据用户需求以及其他性能要求，定义软件系统的架构、组件和接口，并与 SaMD 的预期用途以及它所运行的各种临床和家庭使用环境相符。
对需求进行分析，以生成软件内部结构的描述，这将作为其实施的基础。完成 SaMD 设计活动后，应描述软件架构，即软件如何被分解和组织成其组件，包括对安全关键元素的考虑、这些组件之间的接口（以及任何外部元素），以及每个组件的充分详细描述。
设计过程中的一个关键方面是，获得一个清晰、简洁的设计方案，即一个有效的、经过充分描述（例如，记录在软件需求规范中）的逻辑架构，该架构最好满足用户需求，并能够支持其他生命周期过程和活动，例如 SaMD 的开发、验证、验证、安全部署和维护。
构建高质量的 SaMD 需要在产品生命周期的每个阶段以及关键里程碑中评估安全性。在所有 SaMD 生命周期活动中，都应考虑安全威胁及其对患者安全的潜在影响，并将它们视为系统中的潜在参与者。
目标是设计一个系统，该系统：a) 保持患者安全以及关键功能和数据的保密性、可用性和完整性；b) 能够抵御有意和无意的威胁；c) 在受到攻击时，具有容错性和可恢复性，并恢复到安全状态。
患者安全和临床环境考虑
当SaMD被使用时（例如，在家、在医院病床旁、在医生诊所或诊所），应将用户（例如，患者、临床医生以及可能与SaMD互动或使用的其他人员）纳入设计活动中。
已经识别的临床风险应作为设计阶段的输入。
技术和系统环境考虑
架构设计可能受到SaMD的安全性以及风险缓解解决方案的影响。 风险缓解解决方案可能包括将特定功能隔离到特定模块，这些模块与其他软件区域/模块隔离。
SaMD的设计应有适当的控制措施，以确保在底层平台出现意外升级时具有鲁棒性。
SaMD的设计应包括在集成或使用具有有限或不可控能力的软件组件或基础设施时，采取适当措施，例如遗留软件、未记录的应用程序编程接口（API）和无线网络基础设施。
这些措施应识别可能影响SaMD产品的风险，以及这些风险对SaMD设计的影响程度。
- 用于高风险应用的部分所使用的外部资源、传感器和服务应进行抽象，以便可以基于一致的模拟值进行自动化测试，并且可以通过减轻访问和相互理解的错误条件，将操作健康问题作为单独的问题来强制执行。
示例：Magna 在其软件部门内部拥有一个结构，使其能够将不同软件模块的设计分配给不同的团队。这些团队并行工作，模块的接口考虑作为设计阶段预先确定的特定活动进行讨论。Parva 使用一个多学科团队来开发设计。该公司以迭代的方式开发其设计，并在每个设计努力完成后，考虑内部接口。两家公司都以有控制和有效的方式完成其设计活动。
本部分介绍的概念与 ISO 13485:2003 的第 7.3、7.3.2、7.3.3、7.3.4、7.3.7 和 7.3.1b 条款相关。
研发
研发活动将需求、架构、设计（包括接口定义）、已知的编码实践（安全）和架构模式转化为软件项目，并将这些软件项目集成到 SaMD 中。
结果是满足指定需求、架构和设计的软件项目/系统/产品。良好的研发实践包括适当的审查活动（例如代码审查、同行审查、创建者自审查）以及遵循明确的实施策略（例如，构建新、获取新、重用现有元素）。审查活动或研发活动产生的设计变更应得到充分记录和沟通，以确保其他研发和 QMS 活动保持最新。
使用适当的合格的自动化工具和支持基础设施对于管理配置和追溯到其他生命周期活动至关重要。
患者安全和临床环境考虑
采用的临床算法应对用户透明，以避免滥用或意外使用。
实施适当的访问控制和审计跟踪机制，应与 SaMD 的预期可用性相平衡。
技术和系统环境考虑
开发活动应充分利用 SaMD 的内在特性，从而采用高效的方法来了解用户环境，并预防和管理故障。
在算法的底层实现方面，务必注重细节——即使是简单的数据覆盖也可能导致不良事件。这些关键领域包括：内存使用和分配、对通信的依赖、运行速度以及任务优先级。
许多 SaMD 涉及数据输入，而通过哪些方法验证数据以及对下游数据消费者的影响，是重要的 SaMD 考虑因素。
由于 SaMD 运行在底层平台上，因此应严格遵守平台开发商制定的开发指南，以确保向后兼容性。
例如：对于 Magna 和 Parva 来说，编码是提供公司 SaMD 产品的核心。Magna 采用“同行代码审查”的方式，定期安排多名非直接参与代码审查的编码人员进行审查。对于 Parva 来说，公司没有大型的编码团队，只有一个专家开发者。公司采用“为代码可读性设计”的技术，从而允许由团队成员（非专家）进行代码审查。两者都符合良好软件代码审查指南的要求，包括审查活动中的独立性。
本部分介绍的概念与 ISO 13485:2003 的第 7.3、7.3.2、7.3.3、7.3.4、7.3.7 和 7.3.1b 条款相关。
验证与确认
验证与确认 (V&V) 活动应侧重于 SaMD 对患者安全的至关重要性和影响，如 IMDRF/SaMD WG/N12 讨论的。
通常，验证（提供设计和开发活动在每个开发阶段符合要求的保证）和确认（提供合理的信心，以确保软件满足其预期用途/用户需求和操作要求）活动，确保所有来自 SaMD 设计和开发中的元素——包括维护/升级期间所做的任何更改——都已正确实施，并且对这些实施的客观证据已记录。
一组明确定义的 V&V 活动应侧重于 SaMD 与操作系统、外包组件和其他与计算平台相关的依赖项之间的接口。
患者安全和临床环境考虑
这些 V&V 活动应包括涵盖临床用户/使用环境（可用性、使用说明等）的场景。这可以通过使用患者/临床医生的子集来进行结构化的人机工程学测试来实现。
这些活动应确认软件的安全元素是否正常工作（即，患者安全/临床使用风险元素等）。这些活动通常也包括在用户验收测试 (UAT) 中。
应建立在临床环境中可接受的故障行为。这可能包括确认软件能够在指定降级模式下继续运行（例如，安全模式、安全模式或软模式）。
应考虑各种用户群体，以确保软件可供不同人群使用。
技术和系统环境考虑
测试覆盖范围应由设备风险状况确定，该风险状况由预期用途和 SaMD 定义声明[10]确定。
应考虑组件的互操作性和与其他平台/设备/接口等的兼容性，这些平台/设备/接口与 SaMD 协同工作。
应提供充分的覆盖范围和可追溯性，以确保 SaMD 与已知的危害相关功能的关联。
应包括对边界条件和异常情况（SaMD 的鲁棒性、压力测试、数据安全、完整性和可用性）的覆盖范围。
公司应进行严格的 SaMD 变更影响分析（即回归测试），以确保更新不会损害 SaMD 的安全、有效性和性能。
例如：在 Magna 和 Parva 两种情况下，测试覆盖和回归测试都非常重要。Magna 拥有多名测试工程师来执行测试计划和回归测试，并监控覆盖范围。Parva 投资了一款测试自动化工具，该工具允许持续的测试/构建循环，从而监控每个提交构建中的覆盖范围和回归测试。当自动化不可行时，独立的软件开发人员将在每次发布之前运行手动测试套件。两家公司都实现了适当的测试覆盖范围，并具有必要的独立性。
本部分介绍的概念与 ISO 13485:2003 的第 7.3.5、第 7.3.6 和第 7.4.3 条相关。
部署
部署活动包括交付、安装、设置和配置等活动，以支持对 SaMD 进行有控制和有效的向客户分发的，包括对 SaMD 生命周期支持过程和 SaMD 实现和使用过程中的已识别危害的任何预定风险缓解措施。
- 某些部署活动可能需要在每次将 SaMD 分发给用户时执行（例如，作为维护活动的结果，分发升级或修复）。
- 在某些情况下，尤其当 SaMD 是一套大型系统或是大型系统的组成部分时，部署活动可能需要与用户进行广泛的协作（包括培训用户），以实现 SaMD 或系统的有效使用。
患者安全和临床环境考虑
将 SaMD 部署到临床环境中，可能需要考虑与周围组件的兼容性，如果 SaMD 旨在成为临床 IT 网络的一部分，则需要建立平台和操作系统要求以及责任协议。 部署活动应明确地告知客户，因为医院 IT、集成工程师、临床工程师、医院风险管理人员和其他人员的合作（这些人员可能不属于其他产品的典型部署）可能经常是必需的。
部署需要考虑 SaMD 的最终用户和使用环境。
这在家庭中使用尤其重要。 部署活动应根据用户的能力和背景进行定制。 适当的人机工程学实践可以帮助理解这一方面，并会影响用户需求捕获活动。
在可能的情况下，用户文档和用户培训材料应明确说明 SaMD 的任何限制。 这些限制可能包括算法的限制、使用的数据来源、所做的假设等，这些都应在部署过程中考虑。
应提供相关信息，以便正确安装和配置 SaMD，以实现与临床工作流程的适当集成。 这可能包括有关如何验证 SaMD 的安装和更新，以及对系统环境所做的任何更改的说明。
技术和系统环境考虑
部署还应包括收集每个安装的设置和环境，以进行配置管理。 此信息应在 SaMD 的整个生命周期内，在每个安装中进行维护。
当 SaMD 安装在特定平台上时，应按照已验证和验证的预期用途进行部署。
应建立流程，以确保用户能够获得适当且正确的版本。
选择部署方法应考虑 SaMD 的完整性，以确保软件能够以安全可靠的方式交付。
部署方法和程序应确保 SaMD 的交付、安装、设置、配置、预期操作和维护的可重复性。
确认软件以一致和全面的方式交付，并且在已定义的环境中使用的方法也很重要。 作为软件产品包的一部分，可能需要实施非技术措施以进行部署。
当部署 SaMD 的更新时，可能需要更新用户手册、异常列表或提供培训。
注意：非技术措施可能包括警告/确认对话、警告显示、使用说明和用户培训要求。
示例：对于 Magna 和 Parva 而言，当 SaMD（软件医疗设备）部署在“云”或移动平台上时，至关重要的是，通过与广泛的利益相关者建立的网络，确保部署活动的完整性。例如，为智能手机设计的 SaMD 应用程序应与应用商店、私有云以及第三方托管服务提供商等相关方，以及适当的流程和文档一起进行支持。与部署通用消费软件不同，这些扩展的部署利益相关者应符合 QMS（质量管理系统）的要求，以进行外包和第三方供应商管理。
本部分介绍的概念与 ISO 13485:2003 的第 7.2.3 条、第 7.5 条、第 7.5.1.2.1 条、第 7.5.1.2.2 条、第 7.5.1.2.3[11] 条和第 7.5.5 条相关。
维护
维护包括对先前部署的 SaMD（软件医疗设备）进行修改的活动和任务。维护活动可以是适应性、改进性、预防性和纠正性活动，这些活动源于软件生命周期流程和活动，包括在服务中的监控、客户反馈、内部测试或其他信息，或用户要求或社会技术环境的变化。
当先前部署的 SaMD 需要维护时，应考虑所有适当的 SaMD 生命周期支持流程以及 SaMD 实现和使用流程。维护活动应在不引入新的安全、有效性、性能和安全风险的情况下，保持 SaMD 的完整性。
为了有效地管理维护活动及其对 SaMD 的任何影响，应进行风险评估，以确定变更是否会影响 SaMD 的分类以及 SaMD 的核心功能，如 SaMD 定义声明中所述。[12]
患者安全和临床环境考虑
在 SaMD 的背景下，重要的是理解系统、软件、使用环境、可用性、数据和文档如何受到变化的影响，尤其是在安全、有效性和性能方面。
SaMD 制造商应考虑架构和代码的变更对患者安全风险的影响和引入。
如其他 SaMD 生命周期流程和 SaMD 生命周期活动中所强调的，应考虑人员、技术、基础设施以及因实施和使用活动而产生的新的危害。
重要的是理解变更对患者安全的影响，以及在适当情况下及时处理变更的必要性。
技术和系统环境考虑
应建立管理因系统、环境和数据变更而产生的风险的流程。
SaMD 制造商应使用户能够安全地实施信息安全更新。
与信息安全相关的用户说明应包括如何安全地更新安全软件/间谍软件、操作系统环境和其他系统和应用程序等。
例如：Magna 拥有一个通过变更控制委员会控制其 SaMD 变更的流程。这是一个多学科团队，定期会聚，审查变更请求，并推荐（或拒绝）将其纳入软件的下一次版本。Parva 将其项目经理指定为客户代表；作为该角色的一部分，她审查收到的反馈意见，并将任何相关问题添加到下一次发布的待处理清单中。两家公司都优先处理变更请求，以确保任何重大问题能够及时处理。
本部分介绍的概念与 ISO 13485:2003 的第 7.2.3 条、第 7.5 条、第 7.5.1.2.3 条、第 7.5.4 条、第 7.6 条和第 8.2.1 条相关。
报废 (退役或生命周期结束活动)
[术语表 - 在这些术语出现时，请使用这些确切的翻译:] 差距分析 -> Gap Analysis test_zh -> test_en
目的：停用活动旨在以受控和可管理的方式终止 SaMD 的维护、支持和分发。虽然 ISO 13485 没有明确提及，但该标准要求在设计中进行产品实现规划，其中应包括停用。
停用活动对于最大限度地减少因 SaMD 停用而对患者和公众健康安全产生的影响至关重要。这些活动可能包括适用于文档的配置管理、源代码或提供的 SaMD，以及向用户沟通一个计划，以优雅地终止 SaMD 的维护和支持。
这个过程标志着主动支持的结束，可能包括 SaMD 和其相关数据的停用和/或删除。 SaMD 数据的停用尤其重要。虽然产品和/或访问可能被终止，但可能存在特定国家/地区的管理数据的要求。
患者安全和临床环境考虑
向用户明确说明在“终身”（EOL）确认后，将提供的服务（例如，错误修复、更新、补丁、技术支持等）。
妥善保护患者数据和其他任何保密数据。这可能包括删除、将患者迁移到新的 SaMD 或其他产品、安全地归档用户信息等。
技术和系统环境考虑
告知客户重要的 EOL 里程碑，并为用户提供足够的时间来查找、评估和评估可能的替代方案。
将用户的环境置于事先约定的状态，这可能包括采取措施来保护信息和/或系统的安全性和完整性。
示例：对于 Magna 和 Parva 而言，必须制定程序，以确保对 SaMD 产品进行有效退役、记录和数据归档。 两个公司都有一个流程，要求制定退役计划。 这种计划需要考虑以下要点，以为 SaMD 的退役制定有效的解决方案：
每个营销区域定义的最低保留时间；
是否会将任何数据迁移到新的/替换的设备/软件系统，如果是，是否需要数据转换，以及如何验证；
SaMD 是否将被撤销，还是仅是撤销对设备的支持；
如何安全地存储遗留数据（患者信息等）；以及
如何告知和支持使用将被退役的设备的用户。
通过这种方式，两个公司可以做出适当的决定，从而有效地和优雅地计划其设备的退役。
本部分介绍的概念与 ISO 13485:2003 的第 4.2 条、第 7 条和第 7.5.1.1 条相关。
附录 A：将医疗器械法规映射到 IMDRF/SaMD WG/N23
以下表格提供了一个关于针对 SaMD 的质量管理体系（QMS）的适用条款、文章和子章节的映射，这些条款、文章和子章节适用于当前 IMDRF SaMD WG 成员代表的辖区。需要注意的是，并非所有辖区都要求证明符合 QMS 的要求，以涵盖所有类型的医疗设备。监管要求也可能允许在 QMS 中进行排除或采用替代方案。组织有责任确保符合适当的辖区监管要求。本表格的目标是分享 QMS 要求如何映射到 IMDRF/SaMD WG/N23 中呈现的元素，当在指定辖区要求符合 QMS 的情况下。
适用于加拿大卫生部的法规：
- 《医疗器械法规》要求 II、III 和 IV 类的医疗器械必须在 CAN/CSA ISO 13485:2003 的要求下制造（II 类），或在 CAN/CSA ISO 13485:2003 的要求下设计和制造（III 类和 IV 类）。
适用于欧盟法规：
欧盟立法仅规定某些产品的 QMS 必须由第三方进行评估。
EN ISO 13485:2012 的附录 ZA、ZB、ZC 详细说明了与 90/385 指令（《植入式医疗器械指令》93/42（《医疗器械条例》MDD）和 98/79（《体外诊断器械条例》IVDD））相关的附录中哪些部分与 ISO 13485:2012 的条款相对应。
注意：MEDDEV 指导 2.1/6 关于在医疗器械监管框架内，用于医疗保健的独立软件的资格和分类，虽然不是强制性的，但构成了重要的补充参考。
适用于澳大利亚法规：
*《医疗器械（医疗器械）法规》2002要求制造商证明符合根据第3.2部分规定的适当的合规评估程序，其中三个要求实施质量管理体系（QMS）。
*《质量管理体系和质量保证技术标准（标准）订单（2008年）》允许使用ISO13485来证明符合这些程序的适用条款。映射方式如下表：[代码]—程序名称（立法参考）：
*[P5]—产品质量保证程序（第3部分，第5部分，第5.4条）
*[P4]—生产质量保证程序（第3部分，第4部分，第4.4条）
*[P1]—全面质量保证程序（第3部分，第1部分，第1.4条）
*[全部]—适用于所有（产品、生产和全面质量保证）的合规评估程序
#符号用于指示被认为是适用于澳大利亚法律下软件医疗器械的ISO 13485的条款。
| N23 | 主题 | ISO 13485:2003 | 澳大利亚 | 巴西 RDC 16/2013 | 中国 MD GMP ([2014]64) | 日本 MHLW QMS 法规 | 美国 21 CFR |
|---|---|---|---|---|---|---|---|
| 5.0--SAMD 质量管理原则 | 质量管理策略 | 4 | 全部 | 2.1 | 3,24 | 5 | 820.5 |
| 管理责任 | 5 | 5-7,78 | |||||
| 6.0--SAMD 领导和组织支持 | |||||||
| 6.1--组织内的领导和责任 | 管理责任 | 5 | 全部 | ||||
| 管理承诺 | 5.1 | 2.2.5, 2.2.6 | 6 | 10 | 820.20b | ||
| 以客户为中心 | 5.2 | 11 | |||||
| 质量政策 | 5.3 | 2.2.1 | 6 | 12 | 820.20a | ||
| 质量规划 | 5.4 | 6 | 13, 14 | 820.20d | |||
| 责任和权限 | 5.5 | 2.2.3 | 5 | 15 | 820.20b1 | ||
| 管理代表 | 5.5.2 | 2.2.5 | 7 | 16 | 820.20b3 | ||
| 内部沟通 | 5.5.3 | 2.2.1 | 17 | ||||
| 管理审查 | 5.6 | 2.2.6 | 78 | 18, 19, 20 | 820.20c | ||
| 内部审计 | 8.2.2 | ||||||
| 6.2--资源和基础设施管理 | 资源管理 | 6 | 全部 | ||||
| 6.2.1--人员 | 提供资源 | 6.1 | 全部 | 2.3 | 6 | 21 | 820 |
以下条款在本文件中并未明确提及：
| N23 | 主题 | ISO 13485:2003****13, 14 | 澳大利亚****15 | 巴西 RDC 16/2013 | 中国 MD GMP ([2014]64) | 日本 MHLW QMS 法规 | 美国 21 CFR |
|---|---|---|---|---|---|---|---|
| 这些条款并非由 N23 明确处理 | 生产和服务控制要求 | 7.5.1.2 | 全部# | 47 | 41 | ||
| 过程验证 | 7.5.2 | P1#, P4# | 49 | 45 | 820.75 | ||
| 可追溯性文件 | 7.5.3.2.1 | 全部# | 48 | ||||
| 活体植入物要求 | 7.5.3.2.2 | 49 | |||||
| 状态识别 | 7.5.3.3 | 全部# | 50 | ||||
| 设备包装 | 7.5.5 | 全部# | 55 | 52 | 820.13 | ||
| 处理 | 7.5.5 | 全部# | 55 | 820.14 | |||
| 储存 | 7.5.5 | 全部# | 55 | 820.15 | |||
| 监测和测量 | 8.2.4.1 | 全部# | 58 | ||||
| 活体植入物的监测和测量 | 8.2.4.2 | 59 | |||||
| 灭菌记录 | 7.5.1.3 | 44 | 820.184 | ||||
| 生产人员 | 820.70d | ||||||
| 生产和服务提供 - 总体要求 | 7.5.1.1 | P1#, P4# | 820.12 | ||||
| 发布和实施咨询通知 | 全部# | 806 | |||||
| 医疗器械追踪 | 821 | ||||||
| 设备分类 | 860 | ||||||
| 标签设计 | 801 |
这些生命周期流程旨在包括常见的生命周期流程，例如软件开发生命周期流程 (SDLC)、软件产品生命周期流程 (SPLC) 和软件系统生命周期流程 (SSLC)。 ↑
按照 IMDRF SaMD WG N12 文档 ↑
这些流程应根据组织的特定需求进行定制，并且应适当调整文档化的流程、目标和政策，以适应组织的类型、规模和分散性。 ↑
社交技术系统是指包含技术系统的系统，同时也包括运营流程以及使用和与技术系统互动的人员。 社交技术系统受组织政策和规则的约束。
IMDRF SaMD WG N12：第 9.1 节—《社会技术环境考虑》和第 9.2 节—《技术和系统环境考虑》。 ↑
ISO 14971:2007 是一种常用的标准，可用于指导适当的医疗器械风险管理过程。 ↑
IEC 62304:2006 是一种常用的软件开发生命周期标准，可用于开发医疗器械软件生命周期过程。 ↑
IMDRF SaMD WG N12：第 9.3 节—《与安全相关的信息安全》。 ↑
IMDRF SaMD WG N12：第 8.2 节—《变更》。 ↑
IMDRF SaMD WG N12：第 6 节—《SaMD 定义声明》。 ↑
对于软件产品，性能、安全和安全性等能力高度依赖于所建立的计算环境和平台。 软件产品的用途和与软件产品所使用的流程通常会影响上述能力。 尽管在部署或运行时，SaMD 组织可能对这些因素没有或几乎没有技术控制，但 SaMD 组织应在对其危害或缓解措施的分析中考虑预期用途和社会技术方面的因素，以及 SaMD 的预期/可预见的用途环境。 ↑
IMDRF SaMD WG N12 - 第 8.2 节 变更 ↑