行业洞察

2026年11月10日

为什么选择 cubePAY？

完成一项临床试验活动并不一定意味着可以立即发起付款。约定的费用、必要的数据核查以及审批流程都需要保持一致。建立这一关联正是 cubePAY 的核心目的。

cubePAY 利用预设的付款规则与 EDC 数据生成付款条目，将其纳入对账单，并支持审核与审批流程。对于申办方（Sponsor）和 CRO 而言，它提供了一种结构化的方式，助力实现从临床试验活动到付款对账单的推进，同时完整记录每个条目的生成与审批过程。

将付款条件与临床数据相连接

付款的前提条件可能不仅限于受试者完成访视。一项临床试验可能要求必须先完成原始数据核查（SDV），相关活动才具备付款资格。

cubePAY 将这些条件与 EDC 数据紧密关联。一旦相关的费用清单（Fee Schedule）完成审批流程，且满足预设的触发条件，系统便会依据既定费率自动生成付款条目。这有助于减少人工识别符合条件的活动以及手动重建对应付款条目的需求。

例如，单次访视可能包含多项需付费的评估项目。在“全部满足（All Satisfied）”规则下，cubePAY 会等到所有必备条件均达成后才生成付款条目；而在逐项结算规则下，则可以在满足预设访视要求的前提下，按符合资格的具体评估项目分别生成付款。此外，患者状态同样可用于判定付款资格，从而使规则能够灵活体现研究方案对诸如筛选失败等情况的处理方式。

准确体现各项研究约定的费用

付款安排在不同国家和研究中心之间可能存在差异。cubePAY 支持配置包含本币币种、付款条目和税务设置的国家级模板，并可在此基础上通过中心级费用清单（Site Fee Schedule）开展更深维度的配置。

可复用的主数据条目（Master Items）为费率定义提供了统一的起点。在此基准上，针对各项具体试验配置国家模板和中心费用清单，既能帮助项目团队保持统一的架构规范，又能灵活满足本地化需求。

并非所有费用都源自 EDC 数据。团队亦可手动添加付款条目，例如中心启动费（Site Initiation Fee）。适用的间接费用和税率均可在付款工作流中统一配置并完成计算。

将符合条件的条目纳入受控的审批流程

生成条目只是发起付款的其中一步。团队仍需复核金额，并确认对账单已获得所需的各项审批。

cubePAY 可按照预设周期自动生成付款对账单草稿。当需要在常规周期之外处理业务时，用户也可以手动创建对账单。对账单遵循该试验所配置的签署工作流，为团队提供明确规范的流程，以便对所列条目进行审核与批准。

系统会完整记录付款状态以及录入的付款日期，并支持利用对账单信息发送付款通知。向研究中心或受试者进行的实际资金转账在 cubePAY 系统外部完成。cubePAY 的核心职能在于支持付款的触发与相关记录管理，而非执行银行转账业务。

随着试验推进保持变更全程可追溯

在付款条目生成之后，临床数据仍可能发生变更。例如，修正后的评估数据可能会改变与该项活动相关的具体金额。

cubePAY 会根据对账单工作流所处的阶段来处理这些变更。与草稿对账单关联的条目可以直接更新；而一旦对账单已保存或进入签署流程，调整机制会将原始条目标记为作废（void），并创建关联条目以冲销原始金额并记录替换后的新金额。

国家模板与中心费用清单的版本控制机制，同样支持在试验开展期间对付款配置进行变更。审计追踪（Audit Trails）与审批历史则完整记录了付款工作流背后的所有变更与决策历程。

赋予团队对付款记录的全局可视性

申办方与 CRO 需要清楚掌握已生成了哪些条目，以及这些条目当前处于工作流的哪个阶段。cubePAY 提供与患者及对账单相互关联的付款条目记录，并配备按试验、研究中心和患者维度的报表筛选功能。

这些记录有助于团队复核付款条目的依据及其所记录的状态。数据导出功能可支持系统外部的后续工作，而审计历史则确保了付款准备与审批步骤的全程可追溯。