群里说 Sponsor 是 Responsible Party，供应商交接却没人负责
申办方群在 CRO 离场后寻找注册支持；加入候选名单前，先分开 Responsible Party、PRS 访问人与供应商执行负责人。
重点监测信号
- 群成员说公开 NCT 记录把申办方列为 Responsible Party，而离场 CRO 可能仍掌握操作访问或提交历史
- 工作说明写新供应商负责管理提交，却没有申办方批准人和具体记录范围
- 供应商候选名单有日期，但 PRS 访问、内容批准和报告期限依据仍未解决
临床试验技术供应商接下注册支持工作前，要把三项责任分别写清：谁是提交研究信息的 Responsible Party、哪些人拥有获授权的 Protocol Registration and Results System（PRS，注册与结果系统）访问权、谁代表供应商完成合同内工作。同一个人可以兼任多项，但 NCT 记录、登录权限和工作说明不能互相替代证明。
这篇写给查看获授权申办方、合同研究组织（CRO）和研究启动 Telegram 群的临床试验技术合作负责人。披露或系统集成候选名单可能在大家还互相假定“另一个人负责”时关闭。晚一天看到，供应商进不了名单；没写清三项责任就加入，交出的方案也可能根本没有获授权的人能执行。
典型行业案例——本复合场景用于说明采购信号和决策模式，不代表真实客户、真实群聊或商业结果。
周一：群里的公开记录说法与交接对不上
09:10，一个已获授权的研究启动群出现短消息：
2 个 study 要 CTgov support，之前 CRO 的人离职了。sponsor 周五 review，明天定 shortlist
09:28，有人回复：
公开记录里 sponsor 是 RP。PRS 的东西好像在 US ops 那边
10:04，又有人粘贴一段文档：
新供应商负责维护注册与结果提交
这些消息暴露了一个真实的范围问题，却没有解决它。群里没有两个 NCT 编号、研究类型、申办方身份、精确 Responsible Party 数据、控制相关 PRS 记录的组织、获授权用户、提交状态、报告依据、内容批准人、工作说明边界、联系许可，也没说明发帖人有何权限。
“之前 CRO 的人离职”也可能有多种意思。他可能负责准备内容、录入数据、协调批准、管理账户，也可能只是熟悉历史。群里没有说。没拆开这些功能就让新供应商“接手”，只会把旧交接的含糊复制进新合同。
定义：Responsible Party 是报告责任，不是账户用户的同义词
ClinicalTrials.gov 的注册数据元素定义把 Responsible Party 定义为负责提交临床研究信息的主体，可以是 Sponsor、Sponsor-Investigator，或在所列条件下由 Sponsor 指定的 Principal Investigator。官方Responsible Party FAQ说明，在符合条件的 Principal Investigator 按所述流程被指定前，Sponsor 仍承担该责任。临床试验报告要求页面也说明，适用路径仍需逐项核对。
PRS 是向 ClinicalTrials.gov 提交和维护研究信息所用的系统。官方PRS 常见问题说明，一个组织的 PRS 账户可以有多个用户；公开页面并不会因此显示究竟是哪位用户录入或批准了每次修改。
这就产生了三个不同问题：
- 谁承担适用的提交责任？ 从精确研究记录、Responsible Party 字段和报告路径开始，由申办方或法规专业人员确认适用性与指定关系。
- 谁能在 PRS 操作？ 确认相关组织、获授权用户、记录访问权和当前账户流程。群里的名字或旧截图都不是访问证据。
- 谁执行供应商任务？ 在工作说明中写明交付负责人、记录、字段或结果模块、源数据输入、复核步骤和验收点。
把三个人都叫作“注册负责人”，会删掉真正决定交接能否执行的信息。
周二：每个碎片只翻译成一个核实问题
合作负责人不需要在群里索取一份完整采购 Brief。真实群聊很少一次给全。更可行的做法，是把每个碎片变成一条足以改变商务判断的问题。
“2 个 study。”
问：“具体是哪两个 NCT 记录？”相似标题或一个申办方名称，不足以支持访问和工作量复核。
“公开记录里 sponsor 是 RP。”
问：“每条记录当前的 Responsible Party 字段写了什么，申办方内部由谁确认适用责任？”不能把群发言者直接变成 Responsible Party。
“PRS 在 US ops。”
问：“哪个组织和哪些获授权人员目前能进入每条记录，谁负责相应访问流程？”不要让任何人在群里发送凭据。“US ops”这个地点标签没有说明具名用户、记录范围或批准权。
“维护提交。”
问：“供应商负责准备修改、录入已批准数据、回复复核意见、协调批准，还是执行提交？谁提供源数据，谁签字确认？”一个宽泛动词藏着几项不同工作。
“周五 sponsor review。”
问：“周五要决定什么？如果有人声称存在注册或结果截止日，使用的是哪个官方来源？”内部复核日期可以很紧急，却不自动等于法规期限。
申办方身份、系统访问和法律适用性应保持未知，直到正确的人提供证据。
三项责任交接备注
到周二下午，负责人应该能写出一条分成三段的短备注。
1. 提交责任
记录精确 NCT 编号、当前公开 Responsible Party 信息、研究类型，以及由谁确认适用报告路径。如果指定关系或适用性存在争议，就写“未核实”，不能从复制字段中代替申办方选答案。
2. PRS 访问与操作
记录工作访问所属组织、能进入各条记录的获授权人员、账户管理人或支持路径，以及尚未确认的访问步骤。访问权与批准权必须分开。共享凭据、转发截图或前承包人的姓名都不能证明交接有效。
3. 供应商执行
记录新供应商的具名负责人、范围内的注册字段或结果模块、将收到哪些源文件、谁批准内容、什么算验收，以及哪些任务继续由申办方承担。“管理 ClinicalTrials.gov”不够具体。
针对这个复合场景，一条诚实备注可以这样写：
据称涉及两条记录，尚未提供 NCT 编号。群消息称公开记录把申办方列为 Responsible Party，待逐条核对并由申办方确认。“US ops”据称掌握 PRS 历史，但组织、获授权用户、记录访问权和账户流程均未核实。拟议范围写着维护注册与结果提交，却没有区分内容准备、录入、复核意见回复、批准和提交。周五是申办方内部复核；报告依据未知。记录、访问和批准负责人确认前，不估算集成或披露工作。
它没有把需求叫成已确认项目，却能让下一位复核者开始工作。
为什么这会改变供应商判断
注册支持供应商需要的不只是一个可见 Responsible Party 名称。申办方能批准内容、却没人能访问记录时，眼前任务是获授权访问与记录控制；访问存在、源数据和批准负责人缺失时，供应商面对的是内容治理缺口；两者都有，但工作说明只写“管理提交”时，商务任务是拆开准备、录入、回复意见、批准和提交。
这些路径需要的人和工作量不同。公开记录有助于识别研究和报告出的责任，但它不能认证群发言者的权限，也不会自动把工作流转给供应商。
临床研究与 PMCF 服务分流区分研究标签与交付物；Part 11 审计追踪整改区分系统访问与整改范围；Telegram 销售记录交接清单保留来源、未知项和人工决定。三项责任写清后再查看服务价格。
Top Prospect 可以整理并排序用户主动连接、有权访问且已启用的群消息片段，保留原文、来源、时间、AI 摘要和判断理由。当前生产版匹配目标界面只保存配置，不会自动生成新候选。它不能验证 Responsible Party、授予 PRS 访问权、批准注册内容、联系群成员或执行提交；这些决定由申办方、法规与供应商人员作出。
关键事实
- Responsible Party 是提交临床研究信息的已定义责任。
- PRS 访问权是一项操作能力，不能单独建立提交责任或批准权限。
- 供应商工作说明应写明具体记录、任务、源数据、批准人与验收点。
- 申办方内部复核日期不自动等于法规报告截止日。
- 公开记录、账户证据和合同回答不同问题，必须分开保存。
- 群发言者身份、联系许可、账户流程与签约权仍由人核实。
本文由 Top商业线索研究团队撰写，并于 2026 年 8 月 24 日依据 Sources 中列出的四个 ClinicalTrials.gov 官方页面完成复核。本复合案例只用于商务信息研究，不构成法律或法规建议。
常见问题
ClinicalTrials.gov 的 Responsible Party 就是登录 PRS 的人吗？
不一定。Responsible Party 是提交研究信息的已定义责任，PRS 访问权是操作能力。两者可以落在同一人身上，但公开记录、申办方指定和当前获授权访问必须分别核实。
拥有 PRS 访问权，是否证明某人能批准记录修改？
不能。访问权只说明用户能在适用设置下进入账户或记录，不能单独证明法律责任、申办方批准权或签约权。
可以把注册支持供应商直接当作 Responsible Party 吗？
不能从工作说明推断。适用的 ClinicalTrials.gov 定义与报告要求、申办方指定和合格法规复核共同决定责任；供应商可以执行明确任务，而不因此成为 Responsible Party。
加入注册支持候选名单前，应确认什么？
确认精确 NCT 记录、记录中或适用的 Responsible Party、拥有获授权 PRS 访问的组织与人员、内容批准人、供应商交付物，以及任何截止日的官方来源。账户交接步骤和签约权在核实前继续留空。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
