1. 数字疗法产品全景与工程化边界

数字疗法（Digital Therapeutics，DTx）是以软件为主要活性成分、以循证医学证据为支撑、用于预防、管理或治疗特定疾病的干预产品。理解它的关键不在于“用了什么技术”，而在于它承担了什么样的临床责任：一款合格的数字疗法，必须能回答“干预什么适应症、通过什么机制起效、证据强度如何、在什么监管路径下上市”这四个问题。缺少任何一项，它更可能属于健康管理工具，而非数字疗法。

一、定义与监管分类

从监管视角看，数字疗法通常被归入医疗器械软件（SaMD）范畴。以中国NMPA、美国FDA、欧盟MDR的通行逻辑为例，分类主要取决于两个维度：预期用途的临床风险与是否提供治疗性决策或干预。若软件仅用于记录、展示、提醒，通常按低风险或非器械管理；若用于诊断辅助、治疗方案推荐、剂量调整或直接实施治疗干预，则风险等级显著上升，需要更严格的临床评价与质量体系。

下表给出一个便于课程项目使用的分类参照（示例性归纳，具体以目标市场法规为准）：

需要强调的是，分类不是一次性标签，而是贯穿产品生命周期的约束。一旦预期用途从“辅助记录”扩展到“治疗推荐”，软件等级、临床方案、上市后监测都会同步升级。

二、与传统数字健康产品的区别

传统数字健康产品（如挂号、问诊、健康科普、可穿戴数据展示）的核心价值是连接与信息效率；数字疗法的核心价值是临床结局改善。前者可以以用户增长和活跃度为主要指标，后者必须以症状评分、复发率、住院率、用药依从性等临床或功能终点来证明价值。这一差异直接决定了工程化边界：数字疗法不能只做“功能上线”，还要做“证据可追溯”。

三、典型产品形态与工程化挑战

常见形态包括：面向患者的治疗型App、面向医生的决策支持模块、软硬件结合的神经调控或监测系统、以及嵌入既有临床路径的模块化组件。它们的共同工程挑战是：临床逻辑与软件逻辑必须可分离、可验证、可追溯。例如，一个认知行为治疗模块，其“治疗剂量”由会话频率、时长、内容顺序共同决定，这些参数在软件中如何配置、如何记录、如何随版本变化，都会影响临床结论的可复现性。

下面这张图给出数字疗法产品从“临床假设”到“工程交付”再到“证据闭环”的整体关系，帮助建立全景认知：

四、课程项目任务书

本课程以一个贯穿式项目为主线：设计一款针对轻中度失眠的数字疗法产品原型，并完成从临床假设到工程实现再到证据规划的最小闭环。项目不要求真实开展临床试验，但要求所有参数、流程和判断依据都明确标注为“示例/假设”，并保持内部一致。

项目任务书包含以下交付物：

1. 产品定义卡：适应症、目标人群、干预机制、预期用途、监管分类初判。
2. 干预引擎配置表：以“睡眠限制+刺激控制”为核心，定义每周会话数、单次时长、内容顺序、解锁条件。示例参数：第1周每晚1次、每次8分钟；第2周起根据入睡潜伏期变化动态调整。
3. 数据与安全设计：采集哪些字段（入睡时间、觉醒次数、主观睡眠质量评分）、存储位置、访问权限、脱敏策略。
4. 证据规划表：主要终点（如失眠严重指数ISI下降≥7分）、次要终点、评价时间点（基线、第4周、第8周）、分析人群。
5. 变更控制记录：至少记录一次内容或算法变更，说明变更原因、影响评估与验证方式。

需要特别提醒的是，工程化边界不是限制创新，而是让创新可被验证。一个常见的误区是先把功能做得很丰富，再回头补临床证据，结果发现核心终点无法从现有数据中提取。正确的顺序是：先确定临床终点与测量方式，再反推需要采集哪些数据、干预引擎需要记录哪些参数，最后才进入界面与交互设计。这个顺序在本课程后续章节中会反复出现，也是项目任务书的第一条隐含要求。

从本章开始，你应当建立一种“双轨思维”：一条轨是临床与证据，另一条轨是软件与工程。两条轨必须在同一张路线图上对齐，任何一条脱轨，产品都无法完成从“数字健康工具”到“数字疗法”的跨越。