SaMD 与网络安全：软件生命周期文档与患者数据合规

一、结论先行

含软件的医疗器械在阿联酋要过两道门：一是第 6 条第 1 款 g 项下的说明书与标签信息完整，二是联邦法第 2/2019 号《健康领域信息通信技术应用》对患者数据处理的约束。我们的判断是，软件类产品的退回很少因为代码本身，而是因为文档无法回答三个问题——软件版本如何标识、安全更新如何交付、患者数据存在哪里。这三个问题的答案必须落在申报文件与标签两处。

二、法规依据

法规名称	文号／编号	公布日期	条款号	要点
阿联酋联邦法《健康领域信息通信技术应用》	联邦法第 2/2019 号	2019 年	涉患者数据处理条款	涉及患者数据处理的医疗器械受该法约束，与器械注册义务并行适用
阿联酋联邦法令《医疗产品、药师与药事机构管理法》	联邦法令第 38/2024 号	2024-10-14 刊登官方公报；2025-01-02 生效	第 6 条第 1 款 g 项	内外包装与纸质／电子说明书须提供产品全部信息并符合 EDE 标签指南，软件版本与安全信息须可呈现
阿联酋联邦法令《医疗产品、药师与药事机构管理法》	联邦法令第 38/2024 号	2024-10-14 刊登官方公报；2025-01-02 生效	第 6 条第 1 款 c、h 项	c 评估参考国上市许可合规性与上市后结果；h 其他条件由执行条例规定

三、专业解读看点

看点 1：软件生命周期文档的作用是“可追溯”，不是“堆材料”。 我们的判断是，EDE 审评需要看到需求—设计—验证—发布—维护的闭环，尤其是版本变更如何受控。文档组织上，把版本命名规则与安全更新流程单独成节，比把整份开发流程文档原样附上更有效。这在 45 个工作日 的审评时限内直接影响能否一次通过。

看点 2：网络安全证据应落到“更新如何交付”这一层。 软件类产品在 5 年 有效期内必然发生更新，若更新机制未在申报时说明，后续就可能触发第 15 条的变更问题。我们的取舍建议是：在申报文件中明确区分不影响安全有效性的缺陷修复与需要重新评估的功能变更，并写明各自的处理路径。

看点 3：联邦法第 2/2019 号带来的是并行义务，不能靠器械合规覆盖。 只要产品处理患者数据，就同时落在该法射程内。我们的做法是单独出具一份数据流向说明，写清数据存储位置、跨境传输情形与访问控制措施，与器械技术文件分卷提交，便于不同口径的审查者分别取用。执行条例尚未全部发布，跨境传输的具体条件应向主管机关书面确认。

四、实务建议

1. 软件生命周期文档按需求、设计、验证、发布、维护五段组织，并单列版本命名规则。
2. 在申报文件中说明安全更新的交付机制与用户告知方式。
3. 明确区分缺陷修复与功能变更，并分别写明对应的变更处理路径。
4. 单独出具患者数据流向说明，载明存储位置、跨境传输情形与访问控制措施。
5. 电子说明书或软件界面中的安全提示与阿语标签文本保持一致。
6. 对跨境数据传输等执行条例保留事项，向 EDE 及主管机关取得书面确认，不依据行业惯例推定。

五、核验清单

• □ 软件生命周期文档覆盖需求、设计、验证、发布、维护五段
• □ 软件版本命名规则成文，可在申报表、标签与软件界面中对应
• □ 网络安全更新交付机制与用户告知方式已写明
• □ 患者数据流向说明已单独成卷，含存储位置与跨境传输情形
• □ 联邦法第 2/2019 号下的义务已与第 6 条义务分开梳理，无遗漏
• □ 缺陷修复与功能变更的判定标准与处理路径已明确

延伸阅读：第 24 篇《风险管理文件（ISO 14971）与 IMDRF 基本原则清单的写法》、第 25 篇《技术文件摘要（STED）与器械主文档：如何组织才不返工》、第 03 篇《「医疗器械」在阿联酋法上的定义边界：第 1 条与第 2 条的读法》

法规信息核验至 2026 年 10 月 29 日。