2. DCT平台需求分析与产品定义
去中心化临床试验（Decentralized Clinical Trial, DCT）平台的需求分析，本质上不是“把传统EDC搬到线上”，而是围绕试验参与各方在真实世界中的行为路径，重新定义数据采集、药物配送、随访执行与监查合规的产品边界。如果需求定义阶段只盯着“功能列表”，项目往往会在开发中期陷入反复返工：站点抱怨操作繁琐，患者因流程断裂脱落，申办方拿不到符合稽查要求的数据链。因此，本章从利益相关者地图出发，逐层推导到MVP范围界定，形成一条可追溯的需求工程链路。
一、利益相关者地图：先看清谁被系统改变
DCT平台的利益相关者远不止“患者”和“研究者”。建议用“影响力—受影响程度”二维矩阵来梳理，并标注每一方在试验中的核心诉求与关键接口。
- 患者/受试者：希望少跑医院、操作简单、隐私可控；接口是移动端App、可穿戴设备、快递签收。
- 研究站点（PI、CRC、药师）：关心入排审核、访视确认、AE判断、源数据可溯；接口是站点工作台、eSource、药物发放记录。
- 申办方：关注进度、数据质量、稽查轨迹、成本；接口是监查看板、数据导出、审计日志。
- CRO：承担项目管理与监查执行，需要跨站点协同、风险信号汇总；接口是任务分派、SDV工作流。
- 伦理委员会与监管机构：关注知情同意、隐私保护、数据完整性；接口是电子知情同意（eConsent）记录、审计追踪。
- 物流与居家护理服务商：负责药物温控配送、样本回收、上门采血；接口是订单状态、冷链温度记录。
这张地图的价值在于：任何一条需求都必须能回答“它改变了谁的行为、由谁承担操作成本、谁为数据质量负责”。例如“患者居家上传血压”这一功能，表面是患者操作，实际需要站点设定阈值、系统触发异常提醒、CRC跟进确认，缺一环就会形成数据黑洞。
二、患者旅程：把“访视”拆成可执行的任务链
传统试验中，患者旅程以“到院访视”为节点。DCT中必须把它拆解为“时间触发 + 任务触发”的混合模型。以一项高血压III期试验为例，第4周随访可拆为：
- 第4周前3天，App推送血压监测提醒，患者连续3天早晚各测2次；
- 系统自动判断平均值是否超过预设阈值（如收缩压≥160 mmHg）；
- 若超阈值，触发站点CRC电话随访任务，并生成AE待确认记录；
- 同时物流系统生成药物配送订单，冷链温度记录回传平台；
- 患者完成电子PRO问卷，数据直接进入eSource，无需人工转录。
这条旅程的关键设计点是“异常分支”而非“正常路径”。需求规格中必须明确：阈值由谁设定、超限后多久内响应、未响应如何升级、患者失联如何标记。这些才是DCT平台区别于普通健康App的地方。
三、申办方与CRO需求：从“看结果”到“看过程”
申办方的核心需求可归纳为四类：进度可视、质量可控、风险可预警、稽查可追溯。CRO则更关注跨站点协同效率与监查成本。两者在需求上高度重叠，但优先级不同。
| 需求维度 | 申办方关注点 | CRO关注点 | 平台功能映射 |
|---|---|---|---|
| 数据质量 | SDV覆盖率、质疑关闭率 | 监查任务分派效率 | 风险导向监查看板 |
| 患者保留 | 脱落率、依从性趋势 | 站点跟进提醒 | 依从性评分与预警 |
| 药物管理 | 温控合规、库存准确 | 配送异常处理 | 冷链记录与订单状态 |
| 合规审计 | 21 CFR Part 11 | 稽查准备时间 | 完整审计追踪与导出 |
在需求规格说明书中，建议为每条需求标注来源利益相关者与验收标准。例如“风险导向监查看板”的验收标准可写为：CRO可在5秒内筛选出某站点所有未关闭质疑，并导出含时间戳的CSV。
四、站点角色转变：从“执行者”到“远程协调者”
DCT不是削弱站点，而是重新分配站点工作。CRC的工作从“现场接待与录入”转向“远程确认与异常处理”。这带来三个具体需求：
- 任务工作台：按优先级展示待处理事项（超阈值、未上传、药物异常），而非按患者列表平铺。
- 远程知情确认：支持视频见证eConsent签署，并留存视频哈希与签署时间戳。
- 源数据核对：患者上传数据需与站点记录做一致性比对，差异项自动生成质疑。
如果平台只给站点一个“查看数据”的页面，而不提供任务优先级和异常聚合，站点会迅速退回手工Excel，DCT就名存实亡。
五、需求规格说明书编写与MVP范围界定
需求规格说明书（SRS）建议采用“用户故事 + 验收标准 + 优先级”的结构。优先级用MoSCoW法：Must have、Should have、Could have、Won't have。MVP只保留Must have，且必须满足“一条完整数据链可跑通”。
MVP范围示例（高血压DCT试验）：
- Must：eConsent签署、患者App血压上报、站点异常任务工作台、审计追踪、药物配送状态回传。
- Should：可穿戴设备自动同步、电子PRO、风险导向监查看板。
- Could：AI异常预测、患者社区、多语言支持。
- Won't（首期）：与医院HIS深度集成、区块链存证。
判断MVP是否合格的三个问题：① 患者能否独立完成一次完整随访？② 站点能否在不打电话给IT的情况下处理一次异常？③ 稽查员能否仅凭平台数据还原一次访视全过程？三个都“是”，MVP才具备上线条件。
常见陷阱：把“功能多”当成“范围大”。DCT平台的风险不在功能少，而在数据链断裂。宁可少做三个报表，也要保证eConsent、eSource、药物记录三者的时间戳与操作者身份可交叉追溯。
综上，DCT平台的需求分析应以利益相关者地图为起点，以患者旅程为线索，以站点任务重构为落地抓手，最终收敛为一份可验收、可排期、可追溯的SRS与MVP边界。产品定义阶段多花两周对齐“谁在什么条件下做什么”，远比开发阶段返工两个月更划算。