质疑发起至关闭

质疑是针对具体数据点提出的核对事项，用于记录数据问题、相关成员的回复以及最终处理结果。质疑不会自动改写录入值；数据是否需要修改，应以原始记录和项目要求为依据。

功能说明

质疑管理将数据核对过程集中在同一条记录中。成员可以从问题产生开始，持续查看数据位置、问题说明、回复内容、相关数据变更和当前状态，直至问题关闭或取消。

质疑主要来自以下两种方式：

来源	产生方式	适用场景
自动质疑	表单提交后，系统运行适用的逻辑核查并在条件命中时创建	检查可由预设规则判断的数据问题
人工质疑	具备相应权限的成员针对字段主动创建	记录需要结合原始记录或专业判断进一步核对的问题

一条质疑对应具体的中心、研究参与者、事件、表单和字段。处理人员可以更正数据或保留原值并回复说明，发起方或具备相应权限的成员核对后，可以关闭、取消或重新打开质疑。完整处理过程会保留在质疑往来记录和项目操作日志中。

质疑功能通常包括以下工作：

• 在表单字段或质疑管理页面查看问题数据和待处理事项。
• 根据原始记录更正数据，或回复核对结论和依据。
• 核对回复与数据变更，并关闭、取消或重新打开质疑。
• 按中心、研究参与者、类型和状态筛选质疑，并根据项目要求导出记录。

成员只能查看和处理当前角色数据域内的质疑。项目角色通常覆盖整个项目，中心角色只覆盖已授权中心。质疑通知不会扩大成员原有的数据范围。

本页说明质疑从发起到关闭的处理方法；列表筛选、统计和导出见质疑统计与追踪。

状态流转与留痕

质疑通常从待处理进入已回复，核对完成后关闭。已关闭质疑仍存在问题时可以重新打开；误发、重复或不再适用的质疑可以取消。

状态	含义	后续处理
待处理	质疑已经创建，尚待相关成员核对	修正数据或提交回复
已回复（不同角色）	不同角色的成员已经回复，当前角色需要查看处理结果	核对回复，继续回复或关闭
已回复（同角色）	当前角色一方已经回复，等待其他角色查看或继续处理	跟踪后续回复或状态变化
已关闭	问题已经核对清楚，处理过程结束	出现未解决问题时重新打开
已取消	质疑误发、重复或不再适用	保留记录，不再作为待处理事项

“已回复（不同角色）”和“已回复（同角色）”用于区分回复与当前角色的关系。切换角色后，页面中的分类可能随当前角色变化，因此检查时应同时确认当前使用的角色。

质疑创建、回复、关闭、取消和重新打开分别形成处理记录。需要还原全过程时，应按时间顺序查看质疑往来，并结合项目操作日志和字段编辑历史核对以下内容：

• 质疑由自动规则还是人工操作创建。
• 每轮回复的内容、角色和时间。
• 相关字段是否修改，以及修改前后的值。
• 质疑为何关闭、取消或重新打开。
• 自动质疑是否因逻辑核查、逻辑控制或数据删除而解决。

具体处理方法见本页后续章节，日志查询方法见操作日志与审计追踪。

自动质疑

自动质疑由逻辑核查触发。表单仅“保存”时，数据仍处于暂存状态，不运行逻辑核查；表单“提交”后，系统运行当前方案版本中适用的规则。条件命中时，系统针对规则指定的核查字段创建质疑。

一条自动质疑通常包含以下信息：

信息	说明
数据位置	中心、研究参与者、事件、表单和字段，用于定位问题数据
质疑内容	逻辑核查中配置的问题说明，指出需要核对的内容
当前值与原有值	用于核对当前录入结果及相关变更
类型	用于区分自动质疑与人工质疑
状态	表示质疑当前处于待处理、已回复、已关闭或已取消等阶段
创建时间	记录质疑生成的时间

处理自动质疑时，应先核对原始记录、录入单位、事件和相关字段。录入值错误时，按真实记录更正；录入值无误时，在回复中说明核对结果和依据。相关数据或核查规则发生变化后，系统会重新运行适用规则，应在质疑详情中确认最新状态。

自动质疑不发送新质疑通知

系统自动产生的质疑不会触发“新质疑待处理”通知。相关成员应通过质疑管理页面和项目约定的检查频率查看待处理质疑。

人工质疑

人工质疑用于记录核查人员发现、但不能仅由预设逻辑核查表达的数据问题。临床监查员、数据管理员或其他具备质疑创建权限的成员可以在当前角色的数据范围内发起。

发起前需要确认以下条件：

• 目标研究参与者、事件、表单和字段正确。
• 当前角色可以查看目标数据，并具备质疑创建权限。
• 表单数据已经提交，能够进入质控流程。
• 当前字段的质疑记录中没有相同的待处理事项。

发起人工质疑时，在研究参与者详情中打开对应事件和表单，定位目标字段并查看已有质疑。确认需要新增后，选择发起质疑，填写问题说明和期望的核对结果，再按页面提示提交。提交成功后，可在字段的质疑记录和项目“质疑管理”页面查看新记录。

质疑内容应同时说明“发现的问题”和“需要核对的内容”。以下写法可用于统一项目内的描述口径：

情形	建议写法
数值超出预期	当前值为 150，请核对原始记录、录入单位及数值。
前后数据不一致	本次记录与基线记录不一致，请核对两次记录及变更依据。
日期顺序异常	结束日期早于开始日期，请核对原始记录及日期。
依据不足	当前值缺少可核对的原始记录，请确认数据来源并说明。

质疑内容应陈述事实，不应预先认定数据错误，也不应要求处理人为了关闭质疑而修改真实数据。内容中不得填写姓名、手机号、证件号码等可直接识别研究参与者身份的信息。

指派与通知

人工质疑创建后，系统根据角色权限和数据域确定通知接收人。具备目标表单数据编辑权限、且可以访问相关中心数据的成员，会收到“新质疑待处理”通知。通知不会扩大成员原有的数据范围。

通知事项	接收人	时间	默认渠道	打开位置
新人工质疑	具备目标表单数据编辑权限的成员	即时	站内通知；App 推送默认关闭；不支持短信	网页端打开研究参与者详情及对应质疑
质疑回复	被回复人	即时	站内通知；App 推送默认关闭；不支持短信	网页端打开研究参与者详情及对应质疑
自动质疑	不触发“新质疑待处理”通知	—	—	从质疑管理页面查看

质疑是否需要由指定角色或指定成员处理，应按照项目分工确定。系统通知用于提示待办，质疑的实际状态仍以字段质疑记录和“质疑管理”页面为准。通知渠道与订阅规则见消息通知。

避免重复质疑

重复质疑会分散同一问题的回复记录。人工发起前，应先在字段的质疑记录中检查未关闭事项；需要跨研究参与者查找时，可以在“质疑管理”中按中心、研究参与者、类型和状态筛选。

同一字段已有相同问题时，应在现有质疑中继续回复和处理，不应另建内容相同的质疑。已有质疑针对不同问题，或原质疑已经关闭但出现新的事实时，应分别记录，使每条质疑只处理一个明确问题。

系统是否允许在同一字段创建多条质疑，取决于当前页面和数据状态。提交前仍应由发起人核对已有记录，不能依赖系统自动识别描述相近的重复内容。

质疑处理与关闭

质疑处理用于把数据问题从“提出”推进到“核对、回复、确认和关闭”。处理过程围绕具体数据点展开，所有回复、关闭、取消和重新打开操作都会写入项目操作日志。

处理前检查

处理质疑前，应先确认以下条件：

• 当前角色具备目标数据的查看权限，并且可以访问对应中心或项目数据。
• 目标表单数据已经提交，已进入核查和质控流程。
• 已核对原始记录、录入单位、事件和相关字段，能够判断是需要改数还是需要说明。
• 当前字段、表单或研究参与者数据未处于锁定等禁止修改的状态。

质疑只能在当前角色的数据域内处理。项目角色通常覆盖整个项目，中心角色只覆盖授权中心。页面中看不到目标研究参与者、表单或质疑时，应先检查当前使用的角色及其数据范围。权限控制规则见权限控制与适用角色。

回复与数据修正

收到质疑后，常见处理路径有两类：更正数据，或保留数据并回复说明。两类处理都应以原始记录和项目要求为依据，不应为了消除质疑而改动真实数据。

更正数据

当前值与原始记录不一致时，应先修改数据，再确认相关质疑的最新状态。修改已提交数据时，系统会保留原值、新值、操作人、操作时间以及按表单配置要求填写的变更原因。

处理这类质疑时，应重点核对以下内容：

核对项	说明
原始记录	确认数据来源中的真实记录
当前值	确认系统中当前保存的值
原有值	确认此前修改或提交前后的差异
事件和表单	确认修改发生在正确的数据位置
变更原因	按表单配置和项目要求记录修改依据

数据修改后，系统会按当前适用规则重新处理相关核查结果。自动质疑可能因逻辑核查重新计算、逻辑控制变化或数据删除而解决，相应原因会记录在操作日志中。有关逻辑核查和自动质疑的来源，见逻辑核查和本页的自动质疑。

保留数据并回复说明

当前值与原始记录一致时，不应为了关闭质疑而修改真实数据。此时应在质疑中说明核对结果和依据，使发起方能够判断该问题是否已经解释清楚。

回复内容通常应包含以下信息：

内容	说明
核对结论	当前值是否与原始记录一致
核对依据	使用了哪份原始记录、报告或业务资料
补充说明	解释单位、时间点、记录方式或业务背景

回复应陈述事实，不应写入研究参与者可直接识别身份的信息，也不应使用“已改为正确值”这类不能说明依据的表述。字段数据变更的历史核对方法见操作日志与审计追踪。

关闭、再打开与取消

质疑关闭前，往往会经历多轮回复。项目工作区“质疑管理”页面当前显示的统计状态包括“待处理”“已回复（不同角色）”“已回复（同角色）”和“已关闭·取消”。检查一条质疑的完整过程时，应同时查看质疑详情中的往来记录和项目操作日志，而不能只看当前状态。

常见闭环操作及边界如下：

操作	常见执行人	前提	结果
回复质疑	具备目标数据编辑或处理权限的成员	已能访问目标质疑	形成新的往来记录，等待对方查看或继续处理
关闭质疑	发起方或具备确认权限的成员	已收到足够的回复或数据已核对清楚	质疑结束，状态进入已关闭
重新打开质疑	发起方或具备确认权限的成员	已关闭的质疑仍存在未解释清楚的问题	质疑重新进入处理流程
取消质疑	发起方或具备处理权限的成员	质疑误发、重复，或不再需要处理	质疑结束，状态进入已取消

系统支持单条和批量的回复、取消、关闭与重新打开操作，并分别记录处理结果。人工质疑和自动质疑都会保留处理留痕，但自动质疑的“创建”来源于逻辑核查，解决原因还可能记录为逻辑核查解决、逻辑控制解决或数据删除解决。

关闭、取消与重新打开都应有明确依据

关闭表示问题已经核对清楚；取消表示该条质疑本身不再成立，例如误发或重复；重新打开表示既往回复不足以支撑关闭结论。处理前应先核对已有往来记录，避免用“取消”代替继续沟通。

质疑处理的关键留痕包括：

• 质疑创建、回复、取消、关闭和重新打开记录。
• 与质疑相关的数据修改记录，包括原值、新值、操作人和时间。
• 自动质疑因规则变化、逻辑控制变化或数据删除而解决的记录。

需要还原完整处理过程时，可在项目工作区“操作日志”中按时间顺序核对质疑记录，并结合字段编辑历史查看数据是否发生过修改。日志编码与范围说明见操作日志类型。

处理时限与逾期

质疑处理相关的系统通知只覆盖人工质疑待处理和质疑回复两个场景：

触发场景	接收人	时间	默认渠道
新质疑待处理，仅限人工质疑	具备编辑表单数据权限的成员	即时	站内通知；App 推送默认关闭；不支持短信
质疑回复	被回复人	即时	站内通知；App 推送默认关闭；不支持短信

系统自动产生的质疑不会触发“新质疑待处理”通知，因此自动质疑需要通过“质疑管理”页面或项目约定的检查频率主动查看。通知设置不会扩大成员原有的权限或数据范围。完整场景见消息通知触发场景。

质疑多久回复、多久关闭，应以项目的数据管理计划、清理约定和角色分工为准。系统通知用于提示相关成员，不能代替项目自行设定的处理时限、逾期跟进和升级规则。

各角色职责

质疑处理通常需要发起方、答复方和复核方协同完成。以下分工基于内置角色的常见职责，用于帮助理解处理边界；具体权限仍以当前项目角色设置为准。

阶段	常见角色	主要工作
发起	临床监查员、数据管理员、医学经理、安全审核员等具备质疑创建权限的成员	发现问题、提出需要核对的事项、跟进回复
答复	临床协调员、研究者或其他具备目标表单数据编辑权限的成员	核对原始记录、修改数据或回复说明
确认	发起方或承担复核职责的成员	审阅回复和修改结果，决定关闭、继续追问或重新打开

同一用户即使同时拥有多个角色，进入项目后也只能以当前选定角色处理质疑。需要跨角色查看不同数据范围或执行不同动作时，应先切换到对应角色，再继续处理。

列表筛选、统计和导出见质疑统计与追踪。