2. SaMD监管框架与产品分类

SaMD（Software as a Medical Device）的监管难点，不在于“软件”本身，而在于同一段代码在不同预期用途、不同风险等级、不同法域下，可能落入完全不同的监管路径。理解FDA、NMPA与EU MDR三套框架的差异，是产品立项阶段就必须完成的工作，而不是等到注册申报前才补课。

三套框架的底层逻辑差异

FDA对SaMD的监管建立在“器械”定义之上，通过510(k)、De Novo、PMA三条主要通道实现上市前审查，并借助IMDRF的SaMD风险分类框架（基于“软件对患者/公众健康的影响程度”与“软件提供信息的医疗决策重要性”两个维度）进行分级。NMPA则依据《医疗器械分类目录》与《医疗器械软件注册审查指导原则》，将独立软件按第二类、第三类管理，核心判断依据是预期用途、处理对象（影像、生理参数、基因数据等）以及是否给出诊断/治疗建议。EU MDR不单独定义SaMD，而是将软件视为医疗器械或附件，按MDR附录VIII的规则（尤其是规则11）进行分类，规则11明确：用于提供诊断或治疗决策信息的软件通常归入IIa及以上，若决策可能导致死亡或不可逆损伤则升至III类。

三者的关键差异在于：FDA更强调基于风险的功能分级与上市路径选择；NMPA更强调按目录和预期用途归类；EU MDR则通过规则11把“决策影响”直接写入分类规则。这意味着同一款辅助诊断软件，在美国可能是Class II De Novo，在中国可能是三类，在欧盟可能是IIb或III类。

风险分类规则的实际判断方法

FDA的SaMD风险分类框架由IMDRF提出，两个维度分别是“软件对患者或公众健康的影响状态”（危急、严重、非严重）和“软件提供信息的医疗决策重要性”（驱动临床管理、辅助临床管理、提供临床信息）。例如，一款仅用于显示DICOM影像、不进行任何分析的软件，属于“提供临床信息+非严重”，通常为Class I；而一款直接输出“建议立即手术”的AI软件，属于“驱动临床管理+危急”，通常为Class III。

NMPA的判断更依赖《医疗器械分类目录》中的具体条目。以“人工智能辅助诊断软件”为例，若处理对象为CT影像、预期用途为“辅助医生检测肺结节”，通常归入第三类；若仅用于影像后处理（如三维重建、窗宽窗位调节），不给出诊断结论，则可能归入第二类。实操中，若分类不明确，可向省级药监局提交分类界定申请，获得书面意见后再启动注册。

EU MDR规则11的表述值得逐句拆解：“用于提供诊断或治疗决策信息的软件，包括体外诊断软件，应归入IIa类；除非该决策可能导致死亡或不可逆损伤，则归入III类；若仅用于支持已由其他医疗器械作出的决策，则归入IIa类。”这意味着，如果软件只是“辅助”而非“替代”医生判断，且医生可独立复核，通常不会直接跳到III类，但需要公告机构审查。

预期用途声明与产品定位实战

预期用途声明是监管路径的起点，也是产品定位的核心。一份合格的预期用途声明应包含：目标疾病或状态、目标人群、输入数据、输出信息、使用场景、使用者资质。例如，不要写“AI辅助诊断肺癌”，而应写“本软件用于对成人胸部CT影像进行肺结节检测，输出结节位置、大小及恶性概率评分，供放射科医师参考，不替代医师诊断”。

产品定位实战中，常见的策略是“先窄后宽”：先以低风险、窄适应症获得首个注册证，再通过变更注册逐步扩展。例如，先注册“肺结节检测”二类，再扩展至“肺癌辅助诊断”三类。但需注意，NMPA对算法更新有明确要求：若算法核心逻辑、训练数据、预期用途发生重大变更，可能触发重新注册而非变更注册。

三地分类与路径对照示例

最后需要强调：三套框架并非互斥，而是可以并行准备。对于计划全球上市的SaMD产品，建议在需求阶段就建立“监管需求矩阵”，将三地的分类规则、文件要求、临床证据要求映射到产品需求与验证活动中。这样，同一套软件文档可以同时支撑三地申报，避免后期返工。