2. 数字疗法软件的特殊性与验证边界

在传统医疗器械软件（SaMD）中，软件通常扮演“测量、分析、辅助决策”的角色：它读取信号、计算指标、给出提示，最终由医生或患者做出判断。数字疗法（DTx）则把软件本身变成干预手段——患者按照软件给出的治疗内容、节奏和反馈执行，软件直接改变疾病进程或症状。这一根本差异，决定了它的验证对象、验证边界和版本控制策略都与传统医疗软件、消费健康 App 明显不同。

一、三类软件的定位差异

要理解 DTx 的验证边界，先要把它和另外两类软件区分开。传统医疗软件（如影像后处理、心电分析、剂量计算）的核心是“信息处理”，其输出是给临床人员的参考信息，风险主要来自错误信息导致的错误决策。消费健康 App（如步数记录、睡眠打分、冥想音频）的核心是“行为引导或娱乐”，通常不宣称治疗疾病，监管约束弱，验证重点是可用性和数据准确性。DTx 则介于两者之间但更严格：它既像消费 App 一样直接面向患者、依赖用户依从性，又像医疗器械一样宣称治疗适应症，因此必须证明“软件使用”与“临床获益”之间的因果链。

可以用一个简单的对比来把握：传统医疗软件验证的是“算法输出是否准确”，消费健康 App 验证的是“功能是否可用、数据是否大致可信”，而 DTx 验证的是“患者按软件执行后，症状或功能是否真的改善”。前两者的验证对象是软件功能，DTx 的验证对象是“软件作为干预”的整体效果。

二、软件作为干预手段：验证对象如何界定

DTx 的验证对象不是单一算法，而是“软件干预包”。这个包至少包含四个可独立变化的维度：治疗内容（如认知行为疗法的课程脚本、暴露练习的难度梯度）、交付逻辑（何时推送、如何根据患者输入调整下一步）、交互形式（语音、动画、游戏化任务）、依从性机制（提醒、奖励、进度可视化）。任何一个维度改变，都可能改变患者实际接受的“剂量”，从而影响疗效。

因此，验证边界必须回答三个问题：第一，软件中哪些部分属于“活性成分”，哪些只是包装？第二，活性成分的变更在什么范围内可以视为“未改变治疗实质”？第三，如何用可测量的指标证明患者确实按预期接受了干预？

以某假设的失眠 DTx 为例。其核心干预是每晚 20 分钟的认知行为治疗模块，包含睡眠限制、刺激控制、认知重构三个子模块。验证方案中，主要疗效终点可设为失眠严重程度指数（ISI）从基线到第 8 周的变化。但仅有终点不够，还需要过程指标：模块完成率、每晚实际使用时长、睡眠日记填写率。如果完成率低于 60%，即使 ISI 改善，也很难归因于软件本身，因为患者可能并未真正接受干预。这就是 DTx 验证与传统软件验证的关键区别：必须同时证明“软件被使用”和“使用带来获益”。

三、软件更新与版本控制对验证的影响

传统医疗软件的版本控制相对清晰：算法版本变化，重新做算法验证；界面变化，做可用性测试。DTx 的版本控制更复杂，因为一次看似微小的更新可能改变治疗剂量。例如，把每日推送时间从晚上 9 点改到早上 7 点，可能显著改变依从性；把认知重构模块的文本从 300 字精简到 150 字，可能降低治疗强度；把进度条从“连续打卡”改为“累计积分”，可能改变患者的行为模式。

因此，DTx 的版本控制不能只记录“版本号 + 变更日志”，而应建立变更影响矩阵：每一类变更对应需要重新收集的证据等级。下面给出一个可参考的示例矩阵，用于判断某次更新是否需要新的临床研究、桥接研究或仅需内部验证。

在实际操作中，版本控制还需要解决“累积效应”问题。假设某 DTx 在 12 个月内发布了 8 次更新，每次都属于“低影响”变更，但累积后治疗内容、交付节奏和交互形式都发生了明显变化。此时，最初的关键临床研究是否仍然代表当前版本？一个实用的做法是设定版本基线：以关键临床研究对应的版本为基线，任何更新都需评估“与基线的偏离度”。偏离度可用加权评分表示，例如治疗核心层变更权重 5，交付逻辑层权重 3，交互表现层权重 1，依从性机制权重 4。当累计偏离度超过预设阈值（如 10 分）时，触发桥接研究或重新验证。

四、验证边界的实践含义

综合来看，DTx 的验证边界可以概括为三条线：第一条是治疗实质线，界定哪些变更会改变活性成分；第二条是剂量线，界定患者实际接受的治疗量是否与验证时一致；第三条是证据线，界定现有临床证据能覆盖到哪个版本范围。三条线共同决定了“什么可以改、改了之后要做什么验证、什么时候必须重新做临床研究”。

对工程团队而言，这意味着版本管理不能只依赖代码仓库的 commit 记录，而应把临床证据、变更影响评估和过程指标纳入同一套配置管理。对临床团队而言，这意味着在解读疗效数据时，必须同时查看患者实际使用数据，否则无法区分“软件无效”和“软件未被使用”。对监管沟通而言，这意味着需要提前定义变更控制计划，而不是每次更新后被动解释。