临床研究系统最怕“功能齐全、事实说不清”。一个受试者为什么错过访视、某条数据由谁修改、研究者何时签署、质疑为什么关闭，这些都必须能够被还原。界面设计的第一任务不是让页面看起来专业，而是让研究流程、数据责任和时间关系不再含糊。
临床研究系统最怕“功能齐全、事实说不清”。一个受试者为什么错过访视、某条数据由谁修改、研究者何时签署、质疑为什么关闭，这些都必须能够被还原。界面设计的第一任务不是让页面看起来专业，而是让研究流程、数据责任和时间关系不再含糊。
01 先别画仪表盘，先画研究对象之间的关系
临床项目通常同时存在研究、中心、受试者、访视、表单、数据点、质疑、偏差、文件和人员。它们不是平行菜单，而是一条可以追溯的关系链。若产品一开始只按“首页、列表、详情、设置”规划，后期几乎一定会被业务规则推翻。
更可靠的做法是先建立对象模型：一个研究包含多个中心；中心纳入受试者；受试者按照方案进入计划访视；访视产生表单和数据；数据可能触发质疑、偏差或安全事件；关键动作进入审计记录。对象关系确定以后，导航、权限和页面层级才有依据。
| 核心对象 | 它回答的问题 | 界面不能遗漏的内容 |
|---|---|---|
| 研究 Study | 这是哪个方案与版本？ | 方案版本、阶段、国家/中心、关键里程碑 |
| 中心 Site | 哪个机构负责执行？ | 启动状态、入组、数据质量、人员授权 |
| 受试者 Subject | 谁在接受哪些研究活动？ | 筛选、随机、访视、停药、退出与隐私标识 |
| 访视 Visit | 计划何时发生，实际发生了什么？ | 窗口期、实际日期、缺失、改期、超窗原因 |
| 数据与表单 | 哪条记录支持研究结论？ | 来源、状态、修改、签署、冻结与锁定 |
| 质疑/偏差 | 哪里不一致，谁来处理？ | 提出人、责任人、证据、往返记录与关闭理由 |
02 访视不是日历事件，而是“计划时间”和“实际事实”的对照
很多系统把访视做成日历卡片，只显示日期和完成状态。这会掩盖真正重要的差异：计划访视窗口、实际发生日期、缺失项目、补录时间、受试者原因和研究者判断。
界面应同时展示计划与实际，不能用一个“已完成”覆盖全部细节。对于超窗、漏访和提前终止，系统需要把异常放在用户当前任务旁边，而不是藏进报表。
| 场景 | 常见错误设计 | 更可执行的设计 |
|---|---|---|
| 访视未开始 | 只显示“待完成” | 显示窗口开放时间、准备项、未满足前置条件 |
| 访视已发生但数据未齐 | 仍标记“进行中” | 拆分为访视发生、表单录入、核查与签署状态 |
| 超出窗口 | 红色标签但无动作 | 显示偏离天数、原因记录入口和后续责任人 |
| 访视取消/改期 | 直接覆盖原日期 | 保留原计划、变更原因、操作者和新日期 |
| 提前终止 | 从后续计划中消失 | 明确终止原因、需补做项目和研究状态影响 |
03 不要只设计页面状态，要设计数据生命周期
临床数据的“完成”通常不是终点。数据可能经历草稿、已保存、待核查、被质疑、已更正、已签署、冻结、锁定，以及在授权条件下重新开启。每一个状态都意味着不同的人能做不同的事。
如果状态只靠颜色表达，用户会在“能不能改、改了会发生什么、谁需要重新确认”上反复试错。状态旁应出现具体动作、责任人和影响说明。
临床系统的好用，不是让操作更随意，而是让每一步的责任、证据和后果更清楚。
04 质疑管理要像协作闭环，不能像评论区
数据质疑（Query）不是一句“请核实”。它需要关联具体数据点、触发原因、提出角色、责任人、回复证据、修改动作和关闭判断。系统应让用户在同一上下文中看见原值、修改值和往返记录，而不是在多个页面之间跳转。
批量质疑也要谨慎。重复问题可以批量生成，但关闭前仍需确认每条记录是否真正解决，避免用“全部关闭”制造表面整洁。
- 质疑入口靠近数据点，避免用户失去上下文。
- 自动规则触发与人工质疑要有清晰区分。
- 回复不能只填文本，应允许关联文件、数据修改或无需修改的理由。
- 关闭人应能看到完整历史，而不是只看到最后一条回复。
- 重新打开必须记录原因，并通知原处理人。
05 角色权限要落到“对象、动作和数据范围”
“CRA能看、CRC能改、PI能签”只是粗略口号。真正的权限至少包含三个维度：能访问哪些研究或中心、能对哪些对象执行什么动作、在什么状态下可以执行。
受监管场景还要求关键电子记录和签署具备可靠性、完整性与可追溯性。设计上不能只把按钮隐藏掉，还要考虑后端鉴权、签署语义、审计轨迹和导出检查。
| 角色 | 主要任务 | 容易设计错的地方 |
|---|---|---|
| CRC/研究协调员 | 受试者与访视执行、数据录入 | 被迫在多个系统重复录入；看不到未完成准备项 |
| PI/研究者 | 医学判断、确认与签署 | 签署页面只给“同意”，看不到变更和异常摘要 |
| CRA/监查员 | 中心监查、源数据核查、问题跟踪 | 仪表盘只看完成率，不呈现风险与待行动项 |
| 数据管理 | 规则检查、质疑、冻结与锁库 | 质疑与数据修改分离，难以验证闭环 |
| 申办方项目团队 | 跨中心进度、质量与风险 | 指标很多，但无法定位到中心、受试者和责任人 |
| 审计/稽查 | 追溯记录与流程合规 | 导出内容缺上下文，审计轨迹难读或不可筛选 |
06 多中心仪表盘应该先回答“今天该处理什么”
多中心研究最容易做成一面彩色大屏：入组曲线、完成率、中心排名都很完整，却不能告诉项目经理下一步去哪一个中心、找哪一个人、解决哪一类问题。
首页应按风险和行动组织：受试者安全相关事项优先，其次是访视超窗、关键数据缺失、长期未解决质疑、签署积压和中心启动阻塞。趋势图负责解释变化，行动列表负责推动工作。
| 优先级 | 典型问题 | 默认动作 |
|---|---|---|
| P0 受试者安全 | 严重不良事件未确认、紧急随访缺失 | 立即通知责任人并持续升级 |
| P1 数据完整性 | 关键终点缺失、签署后未经授权修改 | 阻止后续锁定并要求说明 |
| P2 方案执行 | 访视超窗、偏差未记录 | 分配任务，记录原因与纠正措施 |
| P3 运营效率 | 一般质疑积压、文件即将到期 | 进入周期性工作队列 |
07 设计评审时，用真实研究场景走一遍
不要只让业务负责人看静态页面。至少选择一个完整受试者，演练筛选、入组、访视、数据录入、自动质疑、人工回复、研究者签署、监查和锁定。再故意制造超窗、错误修改、人员离职和中心暂停，观察系统能否保持事实一致。
临床系统的可用性测试也不能只测“能否完成任务”。还要记录错误是否可恢复、用户能否解释当前状态、关键操作是否留下足够证据，以及不同角色看到的信息是否一致。
常见问题
临床研究系统一定要一次包含EDC、CTMS、eTMF和受试者端吗？
不一定。先根据研究类型和现有系统边界确定主系统职责。强行把所有模块放进一个产品，往往会增加权限、数据同步和验证成本。即使采用多个系统，也应明确主数据来源、同步频率和冲突处理。
审计追踪是不是把所有操作日志保存下来就够了？
不够。审计记录要能回答谁在何时对什么记录做了什么修改、修改前后是什么、为什么修改，并且关键人员不能自行篡改审计记录。界面还要支持筛选、关联上下文和可读导出。
临床系统可以为了易用减少确认步骤吗？
可以减少无意义重复，但不能删除必要的责任确认。更好的方式是合并上下文、提供差异摘要、明确签署含义，而不是把高风险操作变成无提示的一键完成。
科研系统UI设计最先需要客户提供什么？
至少需要研究流程、角色清单、关键表单、状态规则、例外场景、合规要求和现有数据来源。只有页面清单而没有业务规则，无法准确估算设计范围。
链接复制成功
