臨床オペレーションインテリジェンスはレイクハウス上に構築する

臨床データの問題はストレージの問題ではありません。ほとんどの組織にはすでにデータウェアハウス、CTMS、EDCがあり、その下流のどこかにBIレイヤーがあります。問題は、これらのシステムのどれも、臨床チームが実際に行う必要がある意思決定をサポートする方法で互いに通信していないことです。そのため、意思決定は代わりにスプレッドシートで行われています。

本日、私たちはSite Feasibility Workbenchを完全にオープンソースのDatabricks Appとしてリリースします。これは、アプリケーション、モデル、データが同じプラットフォーム上に存在する場合、臨床運用インテリジェンスがどのように見えるかを示すためです。Tufts Center for the Study of Drug Developmentによると、アクティブ化された調査サイトの37%が目標よりも少ない患者を登録し、さらに11%は全く患者を登録しませんでした。その結果、53%の試験が計画された登録期間を超過し、6件に1件は計画の2倍以上の時間がかかりました（Lamberti et al.; その後のCSDDの影響レポートでも同様のレベルの低パフォーマンスが追跡され続けています）。1日あたり最大50万ドルの未実現の医薬品売上と1日あたり4万ドルの直接的な試験費用がかかる慢性的なサイトの低パフォーマンスは、医薬品開発における最も重大なコストドライバーの1つです。その複合的な低パフォーマンス率は、少なくとも20年間、実質的に横ばいです。ツールは問題ではありません。アーキテクチャが問題なのです。

臨床運用チームは、既存のシステムに接続されたダッシュボードをさらに必要としているわけではありません。彼らは、予測とそれを検証する運用結果との間のフィードバックループが実際に閉じられるように、意思決定支援アプリケーションがデータとモデルが存在する場所に存在することを必要としています。

アーキテクチャに関する議論

臨床意思決定支援の従来の考え方は次のようになります。分析データはデータウェアハウスまたはレイクハウスに存在します。別のアプリケーションデータベースが運用状態を保持します。パイプラインがそれらを緩やかに同期させます。Webアプリケーションが両方の前面に配置され、Silverレイヤーで意味的な調和を追加します。各レイヤーは、統合オーバーヘッド、認証サーフェスエリア、およびアプリケーションが表示するデータの信頼性を低下させる同期ラグを導入します。

Databricks Apps、Lakebase、およびAI/BI Genieは、それらを抽象化するのではなく、不要にすることで、これらのレイヤーをすべて排除します。

Databricks Appsは、ワークスペース内でWebアプリケーションを実行します。アプリは、ファーストクラスのワークスペースサービスプリンシパルとして認証され、SQL Statement APIを介してUnity Catalogをクエリし、ワークスペースREST API経由でAI/BI Genieを呼び出します。これらはすべて内部接続上で行われます。臨床運用データはワークスペースの境界を越えることはありません。アプリは、追加の設定なしにUnity Catalogのアクセス制御を継承します。

Lakebaseは運用データベースレイヤーです。アイドル時にはゼロにスケールし、ワークスペースのIDシステム内で完全にプロビジョニングおよび認証されるマネージドPostgreSQLです。従来のアプリケーションが独自のスキーマドリフト、同期ジョブ、および認証ローテーションを持つ個別に管理されたRDSインスタンスを必要とするのに対し、Lakebaseはデータとモデルが存在するのと同じプラットフォーム上にあります。

AI/BI Genieは、最後のギャップを埋めます。ガバナンスされたデータへの自然言語アクセスをアプリケーションワークフローに直接組み込みます。スタディマネージャーは、MLモデルがトレーニングされたのと同じUnity Catalogテーブルに対して、同じアクセス制御が適用された状態で、プレーンな英語で質問します。

その結果、外部API呼び出しを行わず、個別の運用データベースインフラストラクチャを維持せず、分析レイヤーと運用レイヤー間の同期パイプラインを必要としない臨床運用アプリケーションが実現します。

監査可能性に関する議論

サイトの実現可能性に関する標準的な業界アプローチは、ベンダーの商用スコアリング製品またはCRO提供の分析プラットフォームに依存しています。これらのツールは集計された業界データに基づいて構築されており、ベースラインとしては有用ですが、ポートフォリオの具体性には対応できません。10年間のCTMS、EDC、およびIRTの履歴を持つスポンサーは、自社のプロトコルにおけるサイトのパフォーマンスに関する重要なシグナルを持っています。

MLスタックがDatabricks上に存在する場合、その組織の知識がトレーニングデータになります。このワークベンチのモデルは、業界平均ではなく、貴社の過去の登録率、サイト適格性履歴、スクリーニング失敗パターン、およびプロトコル実行記録に基づいてトレーニングされます。CMS Open Paymentsは、適切に使用された場合、研究への関与とインフラストラクチャと相関する公開シグナルレイヤーを追加し、無料で利用できます。トライアルポートフォリオが成長するにつれて、モデルは同じインフラストラクチャ上で改善されます。これは、単一プラットフォームアーキテクチャが可能にする、ライセンスされたスコアリング製品にはできない複利効果です。新しい研究ごとに予測が改善され、新しいサイト関係ごとに次のトレーニング実行に反映されます。MLflowは、すべてのモデルトレーニング実行、パラメータ、メトリック、およびアーティファクトを追跡し、モデルバージョン間の比較、オンデマンドでの再現性、および生のCTMSおよびEDCレコードからデプロイされた予測までの完全な監査証跡を可能にします。

規制の側面も重要です。21 CFR Part 11、ICH E6(R3)、およびFDAのGood Machine Learning Practice（GMLP）ガイダンス、そしてアルゴリズム意思決定支援における透明性に対するFDAの関心の高まりにより、モデルの解釈可能性とデータガバナンスはオプション機能ではなく、重要な考慮事項となっています。各予測は、ガバナンスされたUnity Catalog Deltaテーブルとして保存されたSHAP属性を保持しているため（MLflowでバージョン管理され、Unity Catalogで系統が追跡され、クエリ可能）、サイト選択の根拠はスコア自体と同じくらい監査可能です。臨床アフェアーズチームは、ブラックボックスのベンダーレポートではなく、SQLクエリでデータモニタリング委員会の質問に答えることができます。

構築したもの

Site Feasibility Workbenchは、臨床試験サイト選択のための6段階のガイド付きワークフローです。プロトコル選択、スコア制約、地理的概要、サイトランキング、SHAP駆動のサイト詳細調査、および最終ショートリスト。多様性に関する考慮事項は、FDORA 2022の下でのFDAの多様性行動計画の期待に沿った、ファーストクラスのスコアリング次元です。

複合的な実現可能性スコアは、リアルワールドエビデンス、患者アクセスデータ、過去のサイトパフォーマンス、サイト適格性履歴、Open Payments KOLシグナル、およびプロトコル実行要因を組み合わせます。これらはすべて、組織自身のCTMS、EDC、およびIRTの履歴でトレーニングされたTAセグメント化されたLightGBMモデルによって駆動されます。

強調する価値があるのは、ワークフローのステップやモデルの機能ではありません。患者レベルのデータはUnity Catalogのアクセス制御を継承し、PHI処理はカタログまたはスキーマレベルで構成されたスポンサーのHIPAAセーフハーバー/エキスパート決定姿勢に従います。

アーキテクチャが可能にすることです。各予測は、予測自体とともにガバナンスされたDeltaテーブルとして保存されたSHAP説明を保持しており、モデルの根拠は説明するスコアと同じくらい監査可能でバージョン管理されています。各予測はガバナンスされたSHAP属性に分解されるため、スポンサーはコミュニティサイト、マイノリティを支援する機関、または初めての調査員の体系的な過小評価に関する推奨事項を監査でき、解釈可能性を公平性の制御に転換できます。

保存されたショートリストは、チーム共有のためにLakebaseに永続化されます。AI/BI Genieアシスタントは、同じUnity Catalogテーブルに対して自然言語でクロスドメインの質問に答えます。これらはすべて、ワークスペース外のインフラストラクチャを必要としません。

これは意思決定支援レイヤーであり、記録システムのソースではありません。CTMS/EDC/IRTは権威あるままです。ワークベンチは、その系統がUnity CatalogとMLflowでガバナンスされた予測を生成します。

完全なアプリケーション（FastAPIバックエンド、Reactフロントエンド、シードノートブック、およびデプロイメントスクリプト）は、オープンソースリポジトリとして公開されています。Unity Catalogを備えた既存のDatabricksワークスペースにデプロイするには、スポンサー固有のセキュリティレビューと検証の前に、約30分の技術的なデプロイメント時間が必要です。

より大きなプラットフォームの1つのモジュール

Site Feasibility Workbench は、トライアルライフサイクル全体をカバーする、より広範なアーキテクチャである Databricks Clinical Operations Intelligence Hub の最初の公開リリースです。

• サイトの実現可能性と選択 — このリポジトリがカバーする内容
• 患者コホートと募集 — EHR とリアルワールドエビデンスを Lakehouse スケールで利用したプロトコルに沿ったコホート構築
• 登録速度オプティマイザー — 1〜3 か月の将来予測ホライズンを持つ、サイトごとの月次 ML 停止予測
• リスクベースモニタリングとコンプライアンス — 登録異常、データ遅延、プロトコル逸脱の継続的なモニタリング

4 つすべてが Databricks Apps としてデプロイされます。4 つすべてが Unity Catalog を直接クエリします。外部 API 呼び出しは行いません。臨床アプリケーションがデータとモデルが存在する場所で稼働すると、フィードバックループが閉じます。サイト選択モデルは、登録結果から学習します。リスクスコアは、改訂履歴が増えるにつれて更新されます。AI によるすべての推奨事項には、それを生成した CTMS、EDC、および IRT レコードへの系統トレイルが付属しています。

はじめに

公開リポジトリをクローンします。デプロイします。変更点を教えてください。

GitHub リポジトリ

Clinical Operations Intelligence Hub 全体については、BrickTalk レコーディング: Scaling BioPharma Intelligence + Databricks Agentic Clinical Ops. をご覧ください。

Lakebase および Databricks Apps の本番環境での利用については、プラットフォームの基本要素について詳しく説明しています。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事