1. SaMD产品开发工程导论

医疗器械软件（Medical Device Software, MDSW）是医疗器械领域中增长最快、监管最复杂的品类之一。在正式进入开发工程之前，必须先厘清一个基础问题：我们做的软件，究竟属于哪一类？监管身份不同，适用的标准、证据链、上市路径和工程实践都会发生根本性变化。本章围绕三个核心概念展开：SaMD（Software as a Medical Device，作为医疗器械的软件）、SiMD（Software in a Medical Device，医疗器械中的软件）以及通用软件（General Purpose Software），并给出典型产品形态、产业地图与课程项目任务书。

一、SaMD的定义与判定边界

根据IMDRF（国际医疗器械监管机构论坛）的定义，SaMD是预期用于一个或多个医疗目的、且不依赖于硬件医疗器械即可实现这些目的的软件。关键词有两个：一是“医疗目的”，二是“不依赖硬件医疗器械”。前者决定它是否进入医疗器械监管范围，后者决定它属于SaMD还是SiMD。

“医疗目的”通常包括：疾病的诊断、预防、监测、治疗或缓解；损伤或残疾的诊断、治疗、缓解或补偿；解剖或生理过程的研究、替代、调节；以及妊娠控制等。若软件仅用于医院行政管理、账单结算、纯教学演示或一般健康生活方式记录（如不涉及疾病判断的步数统计），通常不构成医疗器械软件。

判定SaMD时，监管机构普遍采用“预期用途（Intended Use）”而非“实际功能”作为首要依据。同一段算法代码，若厂商声称用于“辅助医生判断肺结节恶性风险”，它就是SaMD；若声称仅用于“影像显示与测量”，则可能只是医疗器械附件或通用软件。因此，预期用途声明是SaMD工程的第一份设计输入，它直接决定后续的风险等级、临床评价深度与质量体系要求。

二、SaMD与SiMD、通用软件的区别

SiMD是嵌入在硬件医疗器械中、用于驱动或控制该硬件的软件，例如输液泵的流量控制固件、CT机的重建算法、心脏起搏器的参数管理程序。SiMD的医疗目的由硬件器械承载，软件是器械的组成部分，通常随硬件一同注册。SaMD则独立于硬件存在，可以运行在通用计算平台（手机、云端、PC）上，其医疗目的由软件自身实现。

通用软件（如Excel、微信、通用图像处理工具）没有医疗预期用途，不受医疗器械法规约束。但需注意：通用软件若被厂商“赋权”用于医疗场景并对外宣称医疗用途，就可能被重新定性为SaMD。例如，某通用AI绘图工具被用于生成病理切片增强图并宣称辅助诊断，即触发监管。

三者的核心差异可归纳为：医疗目的归属、硬件依赖程度、监管路径、风险来源、证据类型。SaMD的风险主要来自算法输出错误、数据偏差、人机交互误导；SiMD的风险还叠加硬件失效、实时性、电气安全；通用软件的风险则主要是信息安全与可用性，不涉及患者伤害。

三、典型产品形态与产业地图

SaMD的典型产品形态可归为四类。第一类是诊断辅助类，如基于CT/MRI的AI肺结节检测、眼底糖网筛查、病理切片分类，通常输出风险评分或标注，供医生参考。第二类是治疗支持类，如放疗计划系统、胰岛素剂量计算器、数字疗法（DTx）中的认知行为干预程序。第三类是监测与预警类，如可穿戴心电分析、ICU脓毒症早期预警、居家血氧趋势判断。第四类是患者管理类，如用药提醒、术后随访、慢病管理，但需注意此类若仅做记录提醒，可能不构成SaMD。

产业地图上，SaMD生态由五类角色构成：算法与软件厂商（如AI影像公司、DTx企业）、硬件与平台厂商（提供算力、云服务、可穿戴设备）、医疗机构与临床专家（提供数据、标注、临床验证场景）、监管与标准机构（NMPA、FDA、CE、IMDRF、IEC/ISO）、第三方服务商（CRO、质量体系咨询、网络安全测试、云计算合规）。理解这张地图，有助于在项目中定位自身角色、识别关键干系人与合规依赖。

四、课程项目任务书发布

本课程采用“项目驱动”方式。每位学员需选择一个SaMD产品方向，完成从预期用途声明、风险分析、软件需求、架构设计、算法验证、网络安全、临床评价到注册申报文档的全流程工程实践。项目任务书如下：