2. 远程监测与干预的临床需求与场景建模

数字疗法系统的工程起点不是技术选型，而是把临床意图翻译成可验证的工程需求。慢病管理、精神健康、康复训练三类场景的临床目标差异极大，若用同一套需求模板套用，往往在后期出现"数据采了但没人看""提醒发了但患者不依从""量表做了但无法支撑干预决策"等问题。本节的任务是建立一套从场景到需求规格说明书的可操作路径。

一、三类场景的临床目标差异

慢病管理（以2型糖尿病、高血压为例）的核心临床目标是代谢指标长期达标并减少急性事件。其需求重心在周期性生理参数采集、用药依从性、生活方式行为改变与异常值预警。典型参数包括空腹血糖、餐后2h血糖、血压、体重、步数，采样频率通常为每日1～4次，预警阈值如收缩压≥180 mmHg或空腹血糖≥13.9 mmol/L需触发即时干预。

精神健康（以抑郁、焦虑障碍为例）的核心目标是症状严重度下降与复发早期识别。其需求重心在标准化量表（PHQ-9、GAD-7）、情绪与睡眠日志、会话依从性，以及风险信号（自伤意念）的快速响应。数据以主观报告为主，采样频率为每周或每日，需求必须包含危机升级路径。

康复训练（以卒中后上肢运动康复为例）的核心目标是运动功能评分提升与训练剂量达标。其需求重心在动作完成质量、训练次数与强度、关节活动度，数据来源为可穿戴传感器或摄像头姿态估计，采样频率可达每秒数十帧，需求必须包含动作识别准确率与训练安全边界。

二、功能需求与非功能需求的提取方法

功能需求回答"系统必须做什么"，非功能需求回答"系统必须在什么约束下做"。提取时建议以临床工作流为线索逐环节追问：谁在什么时间、基于什么数据、做出什么判断、触发什么动作。

以糖尿病远程监测为例，功能需求可提取为：患者端每日录入血糖并自动上传；系统按阈值规则判定异常等级；异常达到2级时向责任护士推送待办；护士在15分钟内完成电话随访并记录处置结果；医生端可查看近14天趋势曲线。非功能需求则包括：数据上传成功率≥99%、异常告警端到端延迟≤60秒、患者端操作步骤≤3步、隐私数据加密存储并符合个人信息保护要求、系统可用性≥99.5%。

三、场景建模：从场景到需求规格说明书

场景建模的作用是把零散的临床诉求组织成结构化、可追溯的需求集合。推荐采用"角色—触发—数据—判断—动作—验收"六要素描述每个场景，再汇总为需求规格说明书。下图展示了三类场景在数据来源、采样频率、判断逻辑与干预动作上的差异关系，可作为需求提取时的对照参照。

四、需求规格说明书的组织与验收标准

需求规格说明书不是需求清单的堆砌，每条需求都应可追溯到具体场景，并具备可验证的验收标准。建议每条需求包含编号、来源场景、需求描述、优先级、验收方式五个字段。以下为可直接参考的示例片段：

需求编号：REQ-DM-007
来源场景：糖尿病远程监测—异常血糖预警
需求描述：当患者上传空腹血糖值 ≥ 13.9 mmol/L 时，
          系统应在 60 秒内向责任护士推送 2 级告警待办。
优先级：高
验收方式：构造血糖值 14.2 mmol/L 的测试数据，
          记录从数据入库到护士端收到待办的时间戳差值，
          连续 20 次测试均 ≤ 60 秒为通过。

非功能需求的验收同样需要量化。例如"患者端操作≤3步"可验收为：从打开应用到完成一次血糖录入，点击次数不超过3次，且不出现二级菜单跳转。"动作识别准确率≥90%"可验收为：选取10名受试者各完成20次标准动作，人工标注为金标准，系统识别结果与金标准一致的比例≥90%。

五、从需求到后续设计的衔接

需求规格说明书完成后，应能直接支撑三类后续工作：一是系统架构设计，功能需求决定模块划分，非功能需求决定性能与安全设计；二是测试用例设计，每条验收标准对应至少一个测试用例；三是临床验证方案设计，需求中的临床目标（如糖化血红蛋白下降幅度）应转化为临床试验的终点指标。若某条需求无法映射到这三类工作中的任何一类，通常说明它要么表述不清，要么与临床目标无关，应重新审视或删除。

场景建模的价值在于把临床语言与工程语言对齐。护士说"血糖太高要赶紧处理"，工程侧需要把它翻译为"空腹血糖≥13.9 mmol/L 触发2级告警，60秒内推送待办，15分钟内完成随访记录"。这个翻译过程的质量，直接决定数字疗法系统能否在真实临床环境中被使用、被信任、被持续运行。