软件医疗器械合规背景：是什么/为什么

SaMD是什么？ 根据国际通用定义，软件类医疗器械(Software as a Medical Device, SaMD)是指不作为硬件组成部分、独立执行一项或多项医疗用途的软体。换言之，纯软件产品（例如诊断图像处理软件、心电数据分析APP）如果用于人体疾病的预测、诊断、监护、治疗或缓解，满足医疗器械定义，就属于SaMD范畴。MDR没有单独定义SaMD这个术语，但将其归入**医疗器械软件(MDSW)**的大类进行监管。强调一点：无论软件是否与硬件绑定，只要具有医疗目的，就视为医疗器械，受到同等法规约束。

法规分类之痛：软件由于无形、用途多样，按传统规则分类比较棘手。MDR新增了分类规则11专门针对软件。《MDR附录VIII》第II章规则11规定：

• 如果软件驱动决策可能导致死亡或不可逆损伤风险，则归III类最高风险等级；
• 如果驱动决策可能导致严重健康恶化或手术干预，归IIb类；
• 其他提供诊断或治疗信息以指导临床决策的软件，一般归IIa类；
• 仅用于档案、通讯、简单辅助的则I类。

因此，许多SaMD默认是IIa级起步，比旧指令时代要求提高。例如：一款辅助影像诊断的软件会归类IIa；若其误判可能耽误重大疾病治疗，则会上调IIb或III类。对于制造商而言，这意味着需要更严格的合规投入（如需公告机构审核技术文档、临床评价需要更充分数据等）。

硬件 vs 软件差异：软件医疗器械和传统有源设备在技术文件要求上有共通之处，也有特殊挑战：

• 软件没有物理磨损，但面临网络安全漏洞、程序Bug等非实体风险。其危害很多来自数据错误或功能异常，在风险评估上偏重逻辑风险而非机械/电气风险。
• 软件可快速迭代，版本更新频繁。传统器械几个月/年才出一个改型，软件却可能每几周小升级一次，如何界定哪些变更需要重新CE合规是新课题。AI/机器学习(ML)软件更复杂，其算法模型能自我演进，如果不控制好，模型更新后的性能可能偏离原先验证范围，监管上就视为超出批准范围的改变。
• 软件器械的临床评价依赖算法有效性的验证，需要大量测试和用户试用数据，且要考虑多种使用环境（例如移动端的光照、噪声影响）。有时对比金标准测量在统计学上证明不劣即可支撑有效性，但算法黑箱可能让公告机构要求更多解释（例如AI模型特征、训练数据质量）。

正因如此，法规对软件提出特定要求。MDR附录I 17.1-17.4条款明确了软件设计必须保证可重复性、可靠性和性能，即软件在预期用途下稳定实现制造商声称的功能【17.1】。特别是单一故障(single fault)不应导致安全风险【17.1】——例如加校验机制防止一个数据错误引发诊断全盘失准。

网络安全为何受关注？现代医疗软件大多运行于通用平台（PC、手机）并连网传输敏感数据，这使其易遭网络攻击或未授权篡改。一旦医疗软件被黑客控制或数据被伪造，中断服务事小，误诊、窃取患者隐私甚至直接危及生命，事态就严重了。2017年席卷全球的WannaCry勒索病毒甚至导致部分医院医疗设备停摆，就是惨痛案例。因此，欧盟立法时在附录I多个地方嵌入了信息安全要求。比如附录I 17.2强调软件生命周期中的风险管理须包括信息安全(information security)因素；附录I 17.4要求制造商规定软件运行的IT安全措施，包括防止未授权访问【17.4】。附录I 18.8同样要求有源设备避免被恶意干扰【18.8】。这些都是在防范网络安全风险。MDCG 2019-16指南进一步提出软件产品应保证CIA三要素：机密性(Confidentiality)、完整性(Integrity)、可用性(Availability)。如果不重视网络安全设计和维护，就无法满足这些强制要求，也为产品埋下合规与安全双重隐患。

AI/ML动态更新挑战：人工智能（AI）和机器学习(ML)算法正广泛应用于医疗软件，如影像诊断AI、个性化治疗规划软件等。AI算法通常通过海量数据训练得到模型，其性能取决于训练集，模型更新有可能提升性能，也可能引入新风险。监管难点在于：传统医疗器械认证是一锤定音——固定设计、固定性能拿证。但AI模型若“自我学习”不断更新（Adaptive AI），那认证时评估的性能可能随时间变化，监管如何确保持续符合要求？目前MDR对于AI没有特别法规，但任何软件更新都要遵循变更管控。对于声明有持续学习能力的AI，公告机构倾向让制造商限定算法变更范围，例如将AI训练冻结在验证过的数据范围内，或设定触发阈值——模型一旦超出特定性能边界即需要重新提交评估。这就要求开发团队对算法变更的影响有充分验证手段，并把更新流程文档化，包括何种更新属“显著变化”必须事先经公告机构批准。总之，在适用法规完善前，企业要采取谨慎策略：大多数取得CE的AI医疗软件目前采用“封闭模型”方式，即出厂后除Bug修复外不自动改变算法，或者在PMCF框架下收集新数据，由厂家定期线下重新训练、验证后通过正常变更流程发布新版模型，而不真正做到实时自学习。管理者需要认清，AI模型每一次显著更新本质上相当于一次新产品改型，必须严控和记录，让公告机构确信模型始终处于有效受控状态。

综上，软件医疗器械的合规焦点可以概括为：严谨的软件工程过程 + 全面的安全防护 + 受控的算法更新。接下来我们将结合实践谈谈“怎么做”。

软件合规实践要点：怎么做/清单/模板

1. 软件生命周期：建立有据可查的开发流程\ 软件开发需遵循计划 -> 需求 -> 设计 -> 实现 -> 测试 -> 发布 -> 维护的生命周期模型，并确保每一步都有相应的文档输出和评审记录。这正是IEC 62304《医疗器械软件—软件生命周期过程》标准的要求。具体实践中：

• 定义明确的需求和架构：编制软件需求规格说明(SRS)，包括功能需求（“软件要做什么”）和安全性能要求（“软件不能出什么错”）。这些需求应追溯到医疗用途和一般安全与性能要求(GSPR)，如对精度、响应时间、安全机制的要求。然后制定软件架构设计，划分模块并指明各模块的安全级别（IEC 62304按照可能危害将软件分A/B/C级，C级最高需最严格过程）。例如，一款放射治疗计划软件，剂量计算模块属于最高风险C级，需要冗余校验；而UI界面错误则不直接致命也许B级。

• 贯穿风险管理：根据ISO 14971做软件风险分析，识别潜在故障情景（如算法边界条件处理错误导致误诊断）及其导致的危害，拟定风险控制措施（如增加输入有效性检查、极端值告警）。每个风险控制应在设计或需求文档中反映，并在测试中验证有效。例如，若识别出网络中断风险，控制措施是在网络恢复后对数据完整性进行检查确认，那么测试用例需模拟断网场景验证软件正确报警并恢复。

• 严格验证和确认：制定软件验证和确认计划。验证是内部技术指标满足性测试，包括单元测试、集成测试、系统测试等。确认是确保最终软件实现满足临床应用需求。对于医疗器械软件，两者缺一不可，且要有独立证据。实践中应保留：代码单元测试报告、集成测试报告、模拟环境系统测试报告、用户验收测试等。一些常见疏漏是：缺少对异常路径的测试（只测正常输入），缺少负载性能测试。务必覆盖各种异常场景（断电、数据异常、非法操作），以符合附录I 17.1要求的单一故障安全。

• 建立双向可追溯矩阵：将需求-设计-风险-测试关联起来形成矩阵。在技术文档中可以一一列出：需求ID 1由设计模块A实现，相关风险R1、R2，验证通过测试用例TC-05; 需求ID 2…等等。这种矩阵清晰展示每个需求均有实现并被测试，每个风险均有控制并被验证。公告机构审核软件文件时，对这种矩阵非常看重，因为它能快速评估是否存在“漏项”。现实中有企业提供了IEC 62304过程文档却被挑刺，就是因为缺乏这种证据链：审阅者找不到某高风险需求对应的测试用例，就会质疑软件安全证明不充分。因此推荐采用矩阵加超链接（或目录索引）的形式组织文档，方便审核。

• 变更管理：软件频繁更新，一定要建立配置和变更管理制度。所有源代码、需求文档、测试用例都纳入版本控制库。修改流程应包括评估变更影响范围、更新相应文档、执行受影响模块的回归测试，并由质量部门批准发布。若变更涉及新增功能或新的风险，需要考虑是否触发向公告机构报告实质性更改(Significant Change)。特别地，对于持续交付模式，应通过内部SOP定义清楚哪类改动属重大，需要预先与公告机构沟通；哪类为次要更新，可在下次审计提供文档跟踪。务必避免无记录的私下补丁或开发团队擅自更改算法。所有发布版本均需冻结归档，保留可追溯性至少上市后10年，以满足法规可追踪要求。

2. 网络安全：构建软件的安全护城河\ 网络安全需要贯穿软件生命周期的各个环节，目标是防止患者信息泄露、软件功能被攻击破坏，以及确保软件在真实网络环境中可靠运行。以下是网络安全合规实施要点：

• 开发阶段安全设计：从架构设计时就考虑安全威胁模型(Threat Modeling)。列出潜在攻击渠道（如通信接口、数据存储、用户认证等）、可能的威胁（数据被窃听篡改、身份伪造、恶意代码注入…），并为每个威胁设计缓解措施。例如：针对数据传输窃听，采用传输层加密(TLS)；针对未授权访问，采用分级身份认证和日志监控；针对恶意软件干扰，在关键运算模块加入校验机制防代码或内存被修改。将这些安全需求和实现手段写入设计文档，并在风险分析中将网络安全风险纳入（ISO 14971下可以当作延伸的“信息安全风险”，或采用IEC 80001-5-1的框架）。MDR附录I 17.2强调考虑信息安全原则【17.2】就是指要把这些环节融入。

• 实现阶段安全编码：遵循安全编码规范（如输入校验防SQL注入/缓冲区溢出、敏感信息不写死在代码等），并利用静态代码分析工具检查常见漏洞。很多网络安全漏洞源于低级编程错误，因此要在软件实现阶段杜绝。对外部依赖库，要选用有良好安全记录的版本，尽量避免使用已知高危漏洞的开源组件。

• 测试阶段安全验证：除了功能测试，还应进行**渗透测试(penetration test)和模糊测试(fuzz testing)**等专门的安全测试。渗透测试让网络安全专家模拟黑客攻击软件，检验防护有效性；模糊测试则向软件输入随机畸形数据，观察是否会崩溃或异常。对于存储敏感患者数据的软件，还应验证数据加密和访问控制是否符合预期（比如尝试越权访问受保护数据，确保系统正确拒绝）。这些测试可自行进行，也可委托第三方安全机构出具报告，充实技术文件中的安全验证章节。

• 发布阶段文档与部署：按照附录I 17.4【17.4】，在随附文件(IFU或安装指南)中列明运行软件的最低系统配置和安全要求。例如要求用户网络具备防火墙隔离、计算机安装杀毒软件、不使用默认密码等。如果软件需要开放接口(API)与其他系统连接，说明如何安全配置接口、适用的加密协议版本。对云端AI服务类产品，则提示医院IT人员关注与云通信的安全配置。发布前，要建立应急响应机制：一旦公开爆出基础组件的漏洞（如Windows系统漏洞），马上评估对产品影响，在适当期限内提供安全更新。欧盟监管希望厂家有产品安全网络漏洞处理流程，类似IT行业的CVE响应机制。

• 维护阶段监控与补丁：发布后持续监测网络安全威胁信息源（如CERT公告、厂商安全通报）。对用户上报的安全事件即时记录分析。对于发现的新漏洞，应依据严重程度决定是否触发FSCA：例如发现软件存在可被黑客控制治疗剂量的漏洞，这是严重公共健康风险，应按警戒要求2日内上报并尽快发布补丁给所有客户安装。即使风险不那么紧急，也建议通过PMS渠道将已识别漏洞、补丁情况纳入PSUR报告中，向公告机构证明已积极管理网络安全风险。要注意，打补丁属于软件变更行为，应按照变更流程验证补丁对功能无副作用。如果补丁本身改变了软件性能（例如加强安全导致运行变慢），需要重新评估风险收益是否仍平衡。一般而言安全补丁不会改变诊断/治疗逻辑，视为不影响性能的更改，可以走快速发布流程。但这一判断过程依然要有文档可供审核。

3. AI/ML动态更新：确保算法“可控进化” 对于采用机器学习算法的产品，核心是保证模型的每一次更动都在掌控中。监管的原则是算法模型版本固定地通过审查，后续如模型变化可能影响安全性能，就属于重大更改需重新评估。以下措施可考虑：

• 锁定训练边界：在技术文档中界定模型适用的数据范围和训练参数。锁定算法指出厂后的模型不自我学习，只做推断。这其实是目前大多数AI医疗器械采用的方式——模型训练在工厂完成，经验证合格才发布，运行中不变。这种情况下，避开了动态更新的问题，但失去持续改进的好处。若产品希望具备学习能力（例如不断积累临床数据优化模型），建议采用**“周期性离线更新”**：即定期收集使用数据，在研发环境再训练新模型，新模型经过验证后当作软件新版本发布。这样每次模型改变都走标准变更路径，由公告机构视情审查。

• 预定义更新规则：如果宣称软件具有一定自适应能力（例如根据患者个体特征调整算法），必须在上市前向公告机构说明算法的更新机制和范围。可以通过附录II技术文档描述一种Predetermined Change Control Plan（美国FDA提出的概念，在欧盟也有参考），列明模型会按照哪些触发条件更新、更新幅度如何受限、如何确保更新后仍满足性能指标。例如：“算法每接受100例新病例数据，会重新校准阈值，但灵敏度变化不超过±2%，且自有校验模块确保特异度不低于原规要求”。然后需要提供模拟或试验数据证明这样限制内的模型迭代不会降低安全性和有效性。尽管欧盟尚无明确规范，但提前规划这些**“控参自学习”方案将有助于公告机构理解并放心批准你的产品，并将它们写入风险管理和临床评价作为使用规范**的一部分。

• 版本控制与验证：AI模型要有版本号，与软件版本关联，一起纳入配置管理。每次模型参数变化，都按变更流程进行验证（用独立测试集评估新模型性能是否达到先前/更优且不出现新偏差），出具模型验证报告。如果发现模型更新带来某类输入下性能下降，则不可贸然发布，需改进或降级更新幅度。所有版本的模型文件应归档保存，以便追溯。如果产品在市运行采用远程更新模式，厂家应建立监控日志，记录每台设备在何时升级到哪个模型版本。这样万一出了差错，可以迅速定位问题模型版本范围并执行召回或补丁。

• 与公告机构沟通：目前针对AI模型更新，业界和监管机构处在摸索中。制造商在设计带学习能力的软件时，宜提前与公告机构沟通预期的更新方式，取得共识。有的NB可能要求在CE技术审核时就把未来计划的模型改进策略写明。一旦出现超出原定方案的更新需求，务必主动向NB提出批准新的更新。切忌擅自大幅调整算法却不通知，这等同于将未获批的“新产品”投入市场，风险极高。

例子：某AI心电诊断软件通过CE认证，限定适用于成年人。后续厂家获取了儿童心电数据，训练出对儿童也高精度的模型。这个模型改变了使用人群范围（新增儿科），属于适用目的变更，必须申报公告机构审批。厂家准备了儿童临床验证数据并更新临床评价，NB审查后才批准发布儿童版。这体现了AI模型扩展应用需要走严谨的变更审评流程，不可绕过。

4. 常见误区与对策：

• 误区：光有流程文档，没有研发输出。有些企业提供IEC 62304程序文件，却拿不出需求文档、测试报告等“实货”。这属于典型的重过程、轻结果。监管更关注的是技术文件中具体的设计和验证证据。对策：务必要保存并提交关键输出文件：需求规格、架构设计图、源代码版本列表、测试用例及结果、缺陷跟踪表等等。让审核员看到纸面证据，而不仅是说“我们遵循了62304”。

• 误区：软件验证浮于表面。例如只提供了功能测试结果，未考虑性能边界和异常情况；或验证团队与开发团队缺少独立性，倾向于“验证过关”。对策：引入多层次测试，尤其要有独立第三方或独立质量部门参与确认测试，提供确认报告说明软件可满足临床预期用途。对于关键性能指标，采用临床真实数据测评，并在CER中给出统计显著的验证结论，比如敏感度90% (95%CI…)，与对照方法无显著差异等，增加说服力。

• 误区：忽视网络安全文档。有的技术档案中完全没有网络安全专章，或只有简单一两句“软件很安全”，这在当前审核环境下是不合格的。对策：单独准备网络安全报告，内容包括：威胁清单和风险评估表、设计中采取的各项安全措施列表（加密、认证、日志、容错等）、穿透测试或代码审计结果摘要、用户安全指南。并在风险管理报告专门附加信息安全风险小节，列明符合附录I 17.2和18.8条款的具体措施。这样让审核人员明确感知产品安全可靠，不易受到网络攻击影响其性能。

• 误区：AI模型更新无管控。存在厂商一味追求模型精度，不经充分验证就强制推送更新包给用户，结果新模型在某些罕见病例表现不佳引发误诊。这反映出更新管控流程的缺失。对策：建立AI模型变更委员会，由算法工程师、临床专家、法规人员组成，对每次模型改动进行风险评估和验证审核，必要时邀请公告机构实时沟通。不到万全不轻易发布更新，即使发布也提供回退机制。对临床敏感场景，宁可迭代慢一些，确保安全有效性不倒退。

综上，软件类医疗器械的法规符合需要软硬结合：一方面靠硬性的体系流程和文档来证明可信度，一方面靠软实力——研发团队扎实的工程实践和安全文化将技术要求落实到位。只有两者结合，才能既通过审查，又在临床使用中获得医生和患者的信任。软件无形，但其安全性能必须让人“看得见、信得过”。愿我们在数字医疗征途中，始终将质量与安全编码进每一行代码，织密网络安全防护网，掌控AI创新节奏，让软件医疗器械成为精准医疗的重要基石。

互动提问：您在开发或申报医疗器械软件时遇到过哪些挑战？例如文档整理量大、难以判定软件的法规分类、网络安全测试成本高、人工智能算法验证复杂等。欢迎留言分享您的经历和心得！

💡 问题：您认为软件医疗器械合规过程中，哪个环节最容易被忽视？是需求和风险管理、验证测试，还是网络安全防护？说说您的看法，我们将在留言中展开讨论。

法规及指南参考

    欧盟MDR附录I和附录VIII

    MDCG 2019-16、MDCG 2020-1、MDCG 2023-4等