re:Invent 2024: HuronがAIで臨床試験開始プロセスを改善
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Improve clinical trial coverage analysis with generative AI (HLS212)
この動画では、Huronのコンサルティングチームが臨床試験開始プロセスをデジタルトランスフォーメーションによって改善した事例を紹介しています。通常220日かかる臨床試験開始のプロセスにおいて、Coverage Analysisという複雑な意思決定プロセスに着目し、Amazon BedrockとSmartsheetを組み合わせたAIソリューションを構築しました。Schedule of Activitiesという臨床試験の手順を示す複雑な表の65%が異なるフォーマットを持つという課題に対し、独自のパーサーを開発。さらにAIエージェントフレームワークを実装することで、2000にも及ぶ意思決定を効率化し、分析の精度と一貫性を向上させることに成功しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Huronのイノベーションチャレンジ：臨床試験開始の迅速化
みなさん、こんにちは。本日はご参加いただき、ありがとうございます。まず、Huronについて簡単にご紹介させていただきます。Huronはグローバルなコンサルティング企業です。 6つの業界にわたって、クライアントの大きな課題解決をサポートしています。本日は、全社的なイノベーションチャレンジを通じて、私たちのManaged Servicesをデジタルトランスフォーメーションによってどのように変革し、クライアントの臨床試験開始をどのように支援しているかについてお話しします。
ソリューションの説明に入る前に、臨床試験とは何かについてお話ししたいと思います。2020年6月、COVID-19パンデミックの最中で、1日平均1,000人のアメリカ人が亡くなっていた時期を思い出してください。私たちは切実にワクチンを必要としていました。通常、臨床試験の開始までには平均220日かかります。ワクチンを開発するためには、臨床試験を開始する必要があります。この生命に関わる危機的状況において、業界標準の90日でさえも長すぎる期間でした。このイノベーションチャレンジの機会が訪れたとき、臨床試験をより迅速に開始できる領域に焦点を当てることは理にかなっていました。
私は全米の医療機関の臨床試験開始を支援するチームを率いています。緑色でハイライトされた部分が私たちが注力している領域で、Coverage Analysisがデジタルトランスフォーメーションを始めるのに最適な場所だと判断しました。なぜCoverage Analysisが良いスタート地点なのでしょうか？それは端的に言って、難しいからです。 Coverage Analysisは、私が「2つの世界の融合」と考えているものです。一方には、科学的な世界があり、そこでは科学、プロトコル方法論、専門用語が言語として使われています。もう一方には、患者の臨床ケアと医療費請求の世界があります。Coverage Analysisを行うには、この両方の言語を理解し、さらに臨床応用とガイドラインも理解している必要があります。
Coverage Analysisの詳細な手順については説明しませんが、これがデジタルトランスフォーメーションプロジェクトの対象として適している理由は、反復的で困難であり、非常に複雑な意思決定プロセスを含み、臨床試験開始の全体プロセスにおいて極めて重要だからです。それでは、私のイノベーションチャレンジのアイデアを実現に導いてくれたデジタルパートナーに話を譲りたいと思います。
AIを活用したCoverage Analysis：課題と解決策
ありがとうございます、Heather。 ここでの取り組みと目指すことを要約すると、まず、様々な形式で保存された構造化情報と非構造化テキストを含む複雑な文書を照会する必要がありました。それらの文書に対して、質問を投げかけ解釈するのに実際の専門知識が必要な、難しい質問のセットを行う必要がありました。そして、共有可能で、全体的な集計形式や個別のケースごとに検証できる形式で結果を報告する必要がありました。Heatherは長年にわたり、手作業のツール、マクロ、意思決定ツリー、ホワイトペーパーを使用してこのアウトプットの最適化と改善に取り組んできました。しかし、Generative AIやAIイノベーションが登場する以前は、「とにかく作業をこなす」という表現に集約されていました。なぜなら、結局のところ、それは専門家による手作業のプロセスだったからです。規制が変更されチームが入れ替わる中で、継続的なトレーニングが必要で、非常に慎重で熟練した実行が求められる困難な作業でした。
このプロセスには、単純な管理業務と非常に複雑な判断や解釈が不均衡な比率で混在しており、今週のカンファレンスで学んでいるAI技術の明確な候補となりました。このイノベーションチャレンジは社内向けの取り組みでした。構築予定の製品の対象ユーザーは限定的であり、そのため予算と投資できる労力にも制限がありました。これは外部向けにリリースするものではなかったため、そうした制約の中で慎重にソリューションを設計する必要がありました。
当時、私たちにはAIの専門家チームが十分にいなかったため、会場でも見かけるような特定のテクノロジーを活用して実現する必要がありました。ゼロからの構築は避け、時代の変化に対応して進化していくことが確実なプラットフォームを選択して開発を進めました。マネジメントチームが自身で引き継ぎ、維持できるソリューションを構築しました。これは重要なポイントでした。というのも、私たちはこれまでの社内業務で、システムが構築・納品されても維持されず、オーナーが機能拡張を望んでもそれを実現するチームがいないという問題を経験してきたからです。
では、私たちが構築したものを見ていきましょう。最上層にあるのはバックエンドの取り込みプロセスで、RAGオプションを使用した経験のある方にはお馴染みのものです。Amazon Bedrockナレッジを採用しました。当時は機能セットが比較的シンプルでしたが、私たちの要件の進化に合わせてここ2年で急速に進化し、カスタマイズされたチャンキング戦略などが導入されました。特に重要なのは、取り込み時のフィルターとカスタムコードフックの導入です。これにより、Amazon Bedrockの単一インスタンスを使用しながら、質問が行われた際にナレッジベース内の1つか2つの文書からのみ情報を取得することが可能になりました。特定の臨床試験に関係のない文書から回答が返ってくることは避けなければならず、Amazon Bedrockソリューション内のフィルターがそれを可能にしました。
下層の興味深い部分は、情報の取り出し方と提示方法でした。最初はチャットUIから始めました。今では文書との対話は馴染み深い体験となっていますが、Heatherのチームが必要な情報を得るために、長く複雑な質問やプロンプトを暗記して入力する必要があったでしょう。そのため、何らかのプロンプトライブラリが明らかに必要でした。Bedrockフレームワーク内には現在プロンプトライブラリがありますが、当時はありませんでした。たとえそれが利用可能だったとしても、マネジメントチームがセルフサービスで使用できるようにするためには、UIとUXを再構築する必要があったでしょう。
そこで、フロントエンドにはSmartsheetを選択しました。Smartsheetは、Google SheetsやOffice 365 Excelのようなスプレッドシートのオンライン版です。私たちにとって非常に具体的なメリットがありました。Heatherが臨床試験レビューのテンプレートを定義し、それをインスタンス化できます。フォーマットと質問が組み込まれたこれらのテンプレートから、特定のレビューに向けて調整したい専門家が、慣れ親しんだスプレッドシートUIを使用してカスタマイズできます。そのスプレッドシートにファイルを添付すると、それらのファイルが検索対象となります。保存ボタンを押すと、webhookがAPIを呼び出してリクエストを行い、情報を取得し、Smartsheet内の質問の横の列に回答が入力されます。これは汎用的なツールで、Heatherはすでにより広範な用途での活用を検討しています。
それでは、私たちがどのように問題に取り組んだかについてお話ししましたので、このプロセスで学んだことと、その最適化について、Claraに引き継ぎたいと思います。ソリューションのテストを開始するにあたり、対応が必要な様々なタイプのリサーチプロトコルがあることに気づき、大きな課題に直面しました。重要なデータの1つが、Schedule of Activitiesと呼ばれるものに格納されています。Schedule of Activitiesは、臨床試験の各ステップを詳細に示す複雑な表です。スクリーニング活動や治療などの情報が含まれることがあります。各Schedule of Activitiesは、その臨床試験に固有のものです。
テストの過程で、これらの表の65%がフォーマットや構造が異なっていることがわかりました。建物の設計図のように、建設手順を示すものですが、もしステップの解釈を誤ると、臨床試験の患者さんにとって構造全体が損なわれてしまいます。
このSchedule of Activitiesの例を見てみましょう。ご覧の通り、手順が列挙され、期間が示されています。サイクルや各サイクルの特定の日に分けることができ、Xは手順が必要な時期を示しています。医療の専門家はこの表を視覚的に理解し、どの手順が必要かを把握できます。私たちの課題は、Large Language Modelが理解できるような方法でこの表を理解する必要があることです。
次の課題は意思決定に関するものです。Coverage Analysisでは、各時点での各手順について、多くの意思決定を行う必要があります。請求先を正確に判断しなければなりません。規模感をお伝えすると、特定の手順には50の異なるステップと10の時点があり、54の異なる質問に答える必要があるかもしれません。これは、1つのリサーチプロトコルに対してアナリストが行う必要のある2000の意思決定に相当します。
では、複雑な表をどのように解釈し、何千もの意思決定をどのようにナビゲートするのでしょうか？更新されたアーキテクチャをご覧いただくと、これらの課題に対処するための改良を加えていることがわかります。Schedule of Activitiesの複雑さに対処するため、より高度で洗練されたパーサー、つまり表全体を理解し、表とそれに関連するデータの整合性を保持できるドキュメントパーサーが必要だと認識しました。Large Language Modelが理解できるように、表には2次元に圧縮する必要のある多くの情報が含まれています。
市場にある多くのパーサー、サービス、テクノロジーを評価することができましたが、最終的には独自のものを構築することを決定しました。なぜなら、スケジュールの解釈は非常に特殊で、それぞれが極めて独自性の高いものだからです。次に、意思決定における課題についてお話ししましょう。臨床試験では、各ステップにおいて複雑な決定と依存関係を考慮する必要があり、それぞれの決定が他に影響を与えます。そのため、プロセス全体を通じてコンテキストを考慮した推論を行うことが極めて重要です。
AIエージェントは、推論をシミュレートし、データに基づいた意思決定を行うことができます。私たちはAIエージェントフレームワークの実装を開始しました。このフレームワークにより、問題をより小さな管理可能なコンポーネントに分解することができます。これらのコンポーネントは基本的に、分析内の特定のタスクを協調して処理する専門エージェントです。さらに、エージェントは特定のドメイン、例えば患者の医療履歴や基礎疾患の理解などの分野に特化することができます。これらのドメインはそれぞれ非常に特殊であるため、それに応じた具体的な質問を投げかける必要があります。これら全ての目的は、分析の精度と一貫性を向上させることにあります。
私たちはこれらのソリューションと改善を積極的に実装している最中ですが、すでにチームとユーザーは改善を実感しています。
これらの改善には、Research Officeチーム、つまりHeatherのチームにもたらされたソリューションからの大きな恩恵が含まれています。このソリューションがもたらす依存性と効率性の向上が顕著に表れています。例えば、反復的なタスクに費やす時間が減少したことで、文書化ワークフローが効率化されました。
また、代替手順を事前に特定できるようになったことで、分析のやり直しの必要性を最小限に抑えることができ、精度が向上したことも強調されています。これらの結果は、チームのためだけでなく、私たちが継続的に進化し革新を続けるソリューションに依存している臨床試験の患者さんをサポートするために、ソリューションの改善を続けることを後押ししています。
私たちは、世の中にある様々なテクノロジーやベストプラクティスについて、さらに学んでいくことを楽しみにしています。これで本日のプレゼンテーションを終わらせていただきます。お時間をいただき、誠にありがとうございました。Q&Aセッションでお会いできることを楽しみにしております。また、LinkedInを通じて私たちHuron Consultingとつながっていただければ幸いです。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion