cubePAYを選ぶ理由

試験上の活動が完了しても、すぐに支払いを開始できるとは限りません。合意済みの費用、必要なデータ確認、承認プロセスの3つがそろって初めて、支払いに進めます。この3つをつなぐのがcubePAYの役割です。

cubePAYは、設定した支払ルールとEDCのデータをもとに支払項目を生成します。生成した項目は支払明細書にまとめられ、レビューと承認に回ります。治験依頼者とCROは、臨床上の活動から支払明細書までを一定の手順で進められます。各項目がどのように作成・承認されたかの記録も残ります。

支払条件を臨床データと連携

支払条件は「来院が行われたかどうか」だけではありません。たとえば、原資料との照合（SDV：Source Data Verification）が終わるまでは、その活動を支払対象としない試験もあります。

cubePAYは、こうした条件をEDCのデータと連携させます。該当する費用表が承認ワークフローを完了し、設定されたトリガー要件を満たすと、定義済みの費用に基づいて支払項目が自動で生成されます。支払対象の活動を手作業で洗い出し、支払エントリを一から作り直す手間を減らせます。

例を挙げます。1回の来院に、支払対象となる評価項目が複数含まれているとします。「All Satisfied（すべて充足）」ルールでは、必要な条件がすべて満たされてから支払項目が生成されます。一方、項目別ルールでは、来院ごとの要件を満たす範囲で、条件を満たした評価項目ごとに支払いを反映できます。患者ステータスを支払対象の判定条件に加えることもできるため、スクリーニング脱落などへの試験ごとの対応方針をルールに組み込めます。

試験ごとの合意費用を反映

支払条件は国や実施医療機関によって異なります。cubePAYでは、通貨・支払項目・税設定を国ごとに持つ国別テンプレートを利用できます。さらに施設別の費用表で、実施医療機関ごとに細かく設定できます。

費用の定義は、再利用できるマスター項目から始めます。そのうえで、国別テンプレートと施設別費用表を試験ごとに設定します。共通の構成を保ちながら、各地域の要件も反映できます。

すべての費用がEDCのデータから発生するわけではありません。施設立ち上げ費用のような支払項目は、手動で追加できます。該当する間接経費や税率も設定でき、支払ワークフローの中で計算されます。

支払対象の項目を管理された承認プロセスへ

支払項目を生成しても、それで支払いを開始できるわけではありません。金額をレビューし、支払明細書が必要な承認を得たことを確認する必要があります。

cubePAYは、設定したスケジュールに沿って支払明細書のドラフトを自動作成します。このサイクル以外のタイミングで必要になれば、手動でも作成できます。支払明細書は試験ごとに設定した署名ワークフローに沿って進むため、含まれる項目のレビューと承認を決まった手順で行えます。

システムには支払ステータスと入力された支払日が記録されます。支払明細書の情報を使って支払通知を送ることもできます。なお、実施医療機関や被験者への実際の送金はcubePAYの外で行います。cubePAYが担うのは支払いの起点となる処理とその記録で、銀行振込そのものは行いません。

試験の進行中も変更を追跡

支払項目の作成後に、臨床データが変わることがあります。たとえば評価値が修正されると、その活動に紐づく金額も変わる場合があります。

cubePAYでは、こうした変更を支払明細書のワークフロー上の段階に応じて処理します。ドラフト段階の支払明細書に含まれる項目は、そのまま更新できます。支払明細書が保存された後や署名段階に進んだ後は、調整プロセスで処理します。元の項目は無効（void）として残し、元の金額を相殺するエントリと、修正後の金額を記録するエントリを、元の項目に紐づけて作成します。

国別テンプレートと施設別費用表にはバージョン管理機能があるため、試験の途中で支払設定を変更しても対応できます。監査証跡と承認履歴によって、支払ワークフローにおける変更内容と意思決定の経緯が記録されます。