2. 从临床需求到产品需求
数字疗法产品的失败，很少败在算法或工程实现上，更多败在起点：把"医生随口提的一个想法"直接当成产品需求，跳过临床需求的识别与转化。本节要解决的核心问题是——如何把模糊的临床痛点，变成一份可评审、可开发、可验证的需求规格说明书（SRS）。
一、识别未满足的临床需求
未满足临床需求（Unmet Clinical Need）不是"医生觉得不方便"，而是现有诊疗路径中，患者结局、医疗资源效率或依从性存在可量化缺口，且现有手段无法有效填补。识别它需要三个证据来源交叉验证：
- 结局缺口：某疾病的达标率、复发率、再入院率等指标长期低于指南目标。例如某类慢病指南要求血压达标率≥70%，而实际基层随访达标率仅约40%。
- 过程缺口：诊疗路径中存在依赖人工、易遗漏、无法连续监测的环节，如出院后30天内的用药依从性无人跟踪。
- 可及性缺口：有效干预存在，但受限于地域、专业人员数量或费用，患者无法获得。
判断一个需求是否"值得做"，可用四问过滤：是否影响明确人群的硬结局？现有方案是否确实无效或不可及？数字手段是否具备机制上的优势（如实时、连续、可交互、可规模化）？是否有可测量的终点？四问中任一为否，都应暂缓立项。
二、利益相关者分析
数字疗法的利益相关者比传统器械更复杂，因为"使用者、付费者、受益者"常常不是同一方。典型角色包括：患者/照护者、临床医生、护士或健康管理师、医院信息科、医保或商保、药企/渠道、监管机构。分析时对每个角色记录三项：核心诉求、关键顾虑、影响力。
例如患者诉求是"少跑医院、看得懂自己的数据"，顾虑是"操作复杂、隐私泄露"；医生诉求是"不增加文书负担、能快速看到异常"，顾虑是"数据不可信、责任边界不清"。若产品只满足患者而让医生多花10分钟录入，落地必然受阻。因此需求优先级必须建立在"关键角色的否决权"之上——任何一方强烈反对，都可能导致产品无法进入真实场景。
三、临床路径拆解
把目标疾病的标准诊疗路径按时间轴拆成阶段，再逐段标注"谁在做什么、产生什么数据、哪里会断"。以某术后康复场景为例，路径可拆为：术前评估→手术→住院康复→出院过渡→居家康复→随访复诊。拆解后常能发现断点集中在"出院过渡"和"居家阶段"：患者离院后缺乏专业指导，依从性骤降，异常无法及时上报。
拆解的输出应是一张"路径—角色—数据—断点"对照表，它直接决定了产品的介入位置。数字疗法不应试图覆盖全路径，而应聚焦断点最严重、数字手段最能发挥连续监测与即时反馈优势的那一段。
四、需求转化方法
从临床需求到产品需求，需要经过"临床问题→用户需求→产品需求→系统需求"的逐层翻译，每一层都要可追溯。常用方法有三种：
- 场景化转化：把临床问题写成具体使用场景（谁、在什么时间地点、遇到什么、期望什么），再从场景中提取功能点。
- 指标反推：先确定临床终点（如6分钟步行距离提升、再入院率下降），反推需要采集哪些数据、以什么频率、触发什么干预。
- 约束前置：把法规、隐私、可用性约束提前写入需求，避免后期返工。
转化过程中最容易出错的是"把手段当需求"。例如"要有一个打卡功能"是手段，真实需求是"提升用药依从性"。需求应描述可验证的结果，而非预设的实现方式。
五、需求规格说明书撰写与评审
SRS 的核心是让每条需求都具备唯一编号、来源、描述、验收标准和优先级。推荐使用"用户故事 + 验收条件"的写法，并保持双向可追溯：每条产品需求能回溯到临床需求，每条临床需求都有产品需求承接。
评审时重点检查五类问题：完整性（是否覆盖所有关键角色与断点）、一致性（需求之间是否冲突）、可验证性（能否设计出客观测试）、可行性（技术与法规是否允许）、优先级合理性（是否与临床价值匹配）。评审应邀请临床、工程、法规、可用性多方参与，并留下评审记录与决议。
上图展示了从临床需求到 SRS 的完整转化链路：左侧四个输入要素（临床需求、利益相关者、路径断点、可测量终点）汇聚到转化方法层，再分解为具体产品需求，最终收敛为可评审的 SRS，并通过虚线回环实现双向追溯。实际项目中，这条链路不是单向走完就结束，而是随临床反馈持续迭代——当真实世界数据表明某条产品需求未能改善终点指标时，应回到临床需求层重新审视假设。
一份可用的 SRS 至少应包含：需求编号、需求来源（对应哪条临床需求）、需求描述（用户故事形式）、验收标准（可测试）、优先级（MoSCoW 或类似分级）、约束条件（法规/隐私/技术）。评审通过后，SRS 即成为后续设计、开发、测试与临床验证的共同基线，任何变更都需走变更控制流程并更新追溯矩阵。