1. 医疗软件工程导论
医疗软件不是“运行在医院里的普通软件”这么简单。它直接或间接参与疾病预防、诊断、治疗、监护与康复，一旦失效，后果可能落在具体患者的生命安全上。因此，医疗软件工程的核心问题不是“功能能不能实现”，而是“在明确的临床场景与法规约束下，功能是否安全、有效、可追溯、可维护”。理解这一点，是后续需求分析与架构设计的出发点。
一、医疗软件的定义与边界
从工程视角看，医疗软件是以医学目的为核心、处理医疗数据或控制医疗行为、并需满足相应法规与质量标准的一类软件系统。它通常具备三个特征：其一，处理的对象是患者相关的生理、影像、检验、用药或诊疗数据；其二，输出会直接影响临床决策或治疗过程；其三，其全生命周期受监管约束，需要留存设计与验证证据。
需要区分“医疗软件”与“医疗场景中的通用软件”。医院财务系统、普通办公系统虽然运行在医疗机构内，但不以医学目的为核心，通常不属于医疗器械软件范畴。而像CT重建算法、输液泵嵌入式控制、AI辅助诊断模块，即使形态不同，只要其预期用途属于医疗，就应纳入医疗器械软件的管理思路。
二、医疗软件的分类
分类的目的不是贴标签，而是决定后续需求与架构的严格程度。常见分类维度如下：
- 按预期用途：诊断类（如影像辅助诊断）、治疗类（如放疗计划系统）、监护类（如中央监护）、康复类、医院信息管理类（如HIS、LIS、PACS）。
- 按风险等级：依据软件失效可能造成的伤害程度，划分为不同安全级别。级别越高，对需求追溯、验证覆盖、架构隔离的要求越严。
- 按部署形态：独立软件（SaMD）、软件作为医疗器械的组成部分（SiMD）、嵌入式固件、云端服务。
- 按实时性：硬实时（如除颤器控制）、软实时（如监护报警）、非实时（如病历归档）。
分类结果会直接改变架构决策。例如，硬实时治疗控制软件必须考虑确定性调度与故障安全状态；而影像归档系统更关注数据完整性与并发吞吐。
三、生命周期特征
医疗软件的生命周期与通用软件最大的差异在于：验证与确认贯穿始终，且变更受控。典型阶段包括：概念与预期用途定义、需求分析、架构设计、详细设计、实现、集成与验证、确认、上市后监督。与普通软件不同，需求阶段就要建立“用户需求—系统需求—软件需求”的追溯链，架构阶段要明确安全相关部件与风险控制措施。
上市后监督同样属于生命周期的一部分。真实世界中的不良事件、误报警、算法漂移，都可能触发再评价与设计变更。因此，医疗软件的生命周期不是“交付即结束”，而是“持续受控演进”。
四、需求与架构设计的核心地位
在医疗软件工程中，需求与架构处于承上启下的位置。需求回答“为谁、在什么临床场景下、达到什么医学目的、不能出现什么危害”；架构回答“如何把这些需求分配到可验证、可隔离、可替换的结构单元中”。
如果需求只写成“系统应能显示影像”，就无法判断清晰度、刷新时间、标注精度是否达标；如果架构没有把报警计算与界面显示隔离，一个界面卡顿就可能延误报警。可见，需求与架构不是文档形式，而是风险控制的第一道工程手段。
五、从需求到架构的追溯关系
下面用一张关系图说明医疗软件中“预期用途—风险—需求—架构—验证”的追溯链。图中每个环节都不是孤立文档，而是相互约束的证据链。
这张图强调一个工程事实：需求不是凭空写的，架构也不是凭经验画的。预期用途导出风险，风险转化为安全需求，需求分配到架构单元，架构再通过验证证据回过来证明需求被满足。任何一环断裂，都会在注册审评或临床使用中暴露问题。
六、一个简化的教学示例
假设要开发一套“输液泵嵌入式控制软件”，预期用途是“按医嘱速率向患者静脉输注药液”。风险分析识别出“输注速率过高”可能导致药物过量。由此导出安全需求：当实际速率偏离设定速率超过10%并持续5秒时，系统应在200毫秒内停止输注并发出报警。
架构上，就需要把“速率采集”“偏差判断”“泵电机停止”“报警输出”划分为可独立验证的部件，并设计故障安全状态——即使主控异常，也要有独立 watchdog 或硬件限流路径使泵停止。验证时，需要构造速率偏差场景，测量从偏差发生到泵停止的时间是否≤200毫秒，并保留测试记录作为追溯证据。
这个例子说明：医疗软件的需求必须可测量，架构必须可隔离风险，验证必须可复现。三者缺一不可。