「医療DX」に関連する編集部お薦め記事

政府主導の「医療DX」は成功するのか　医療現場が感じるギャップ

医療従事者150万人に「Microsoft 365」　医療DXに懸けるNHSの決意

　前述した『Nature』の1本目の論文は、病院の救急部門での活用を想定した自律型AIシステム「MIRA」を紹介している。患者の病歴聴取、検査結果の照会、検査の指示、処方、そしてエンドツーエンドの管理計画の作成までを行うものだ。500件の実症例でテストした結果、MIRAの診断精度は87.8％に達し、専門医の78.1％を上回る数字を示した。虫垂切除術などの外科処置を正しく指示した割合は、医師の38.3％に対しMIRAは53.5％だった。また、処方された468の薬剤のうち、適応や安全性、アレルギー相互作用、腎機能に応じた用量などが適切だった割合は99.8％に達した。

　2本目の論文のシステム「AMIE」は、継続的な外来診療のために構築されたものだ。100人の患者を対象に、複数の専門領域にわたる3回の診察を行った。独立した評価者による判定では、AMIEの管理計画は21人の専門医よりも優れていると評価された。3回目の診察までにAMIEの計画が適切とされた割合は98％で、医師の81％を凌いだ。治療の正確性も医師の67％に対し95％と圧倒した。

　世界で最も引用される医学研究者の1人であるエリック・トポル氏は、これらの結果を「医療AIが単なる診断支援を超え、自律的臨床管理へと進化した」と評した。どちらのシステムも、精査されたデータとテキストベースの対話による制御された研究環境でのテストではあるが、臨床AIがどこへ向かっており、どれほどの速さで到達しようとしているかを如実に示している。

なぜ単なる「レポート」の問題ではないのか

　経験豊富なNHSのデジタルリーダーたちは「既存のシステムを適切に接続すれば同じことができる」と反応するかもしれない。電子カルテ（EPR）や検査室、モニターからデータを引き出し、スコア化してチームに通知する。それは「統合」であって新しいプラットフォームではないという主張だ。

　この反応は理解できる。しかし、それは自律型システムが果たす役割の半分しか捉えていない。

　MIRAは11種類の異なるツールを使い分け、8万5000以上の行動選択肢から判断を下す。血液検査や画像診断を指示し、入院の優先順位を決め、腎機能やアレルギー歴に合わせて特定の抗生物質を処方する。これら1つ1つは、画面に表示されるレポートではない。臨床システムに書き込まれる「アクション」だ。

　NHSのトラストでこれらのアクションを実行するには、電子カルテ、薬剤システム、病理検査、患者管理システムに同時に書き込む必要がある。そのためには、患者、薬剤、検査結果、病棟の場所、ケア計画が連動したオブジェクトとして存在する、統合された運用データプラットフォームが必要だ。AIがそれらを読み取りかつ書き戻せる環境だ。

　データウェアハウスは設計上、読み取り専用だ。共有ケア記録は患者の全体像は見られるものの、書き戻し機能や開発環境は欠如している。電子カルテは自社システム内では機能するが、所有していないシステムのデータを横断して推論することはできない。

　以下で紹介するフロリダ州のタンパ総合病院の事例は、この違いを実務で理解した際に何が起きるかを証明している。

タンパ総合病院の事例：なぜ電子カルテでは解決できなかったのか

　2022年8月以降、タンパ総合病院の「敗血症ハブ」は約1000人の患者をリアルタイムで監視している。これはPalantirのFoundryプラットフォーム（FDPと同じ技術）上に構築された。電子カルテ、検査結果、臨床ノート、ベッドサイドモニターのデータを1つの患者オブジェクトモデルに集約する。システムが敗血症の初期兆候を検知すると、通知を出すだけではなく、構造化された迅速対応ワークフローを起動し、1時間以内に抗生物質が投与される。推計では、これにより886人の命が救われ、48時間以内の敗血症死亡率が68％減少した。

　タンパ総合病院は、電子カルテの1つである「Epic」をすでに導入していた。Epicには独自の敗血症予測モデルが組み込まれている。しかし外部の研究者による検証では、その精度は公称値を大幅に下回っていた。同病院がEpic標準の機能ではなくFoundryベースのハブを採用したのは、電子カルテ単体では外部データソースを統合できなかったからだ。モデルの精度が低い場合でも迅速に改善でき、早期発見を1時間以内の臨床アクションにつなげるワークフローを支えきれなかったのである。

　タンパの運用ループは「検知と報告」ではない。検知し、文脈に応じたアラートを出し、行動し、その結果をシステムに記録してスコアを再調整するループだ。このループには、プラットフォームが共通のデータモデルを通じて臨床システムから読み取り、書き戻す必要がある。「記録」だけでなく「次は何が起きるべきか」という「アクション」を定義するオントロジーが求められる。同病院は現在、同じプラットフォーム上で60以上の運用製品を動かしている。全てが同じ統合データレイヤーの上に構築されているからだ。

　同病院の最高デジタルイノベーション責任者は、これを「医療システムの運用バックボーン、あるいはOS」と表現した。これこそが、臨床現場がリアルタイムでデータを基に行動する「フロントラインファースト」の議論だ。

ポータビリティ（移植性）という課題

　経験豊富なCIOであれば、自前の統合エンジンやデータフィードを使い、タンパのようなシステムをローカルで構築できるかもしれない。実際、多大なコストと労力をかけて実現した例もある。

　だが、構築されたシステムは、そのトラスト内でしか機能しない。ローカルでの構築は、現地のデータ形式やコーディング手法に依存するからだ。別のトラストに広めようとすれば、データモデルが異なるため統合を一からやり直すことになる。

　FDPはこの問題を解決する。「標準データモデル（カノニカルデータモデル）」により、患者や検査結果、処置の表現方法をプラットフォーム上の全トラストで標準化する。オントロジーがそれらを結び付け、アクションがどう流れるかを定義するセマンティックレイヤーとなる。

　この開発環境があれば、あるトラストで作られた製品を、作り直すことなく別のトラストで動かせる。全拠点が同じアーキテクチャを共有しているため、AIはどこでも一貫してデータを扱える。1つのトラストで開発された敗血症対策製品を、原理的には他の136のトラストに即座に展開できる。

　移植性が確保されても、現場への導入や運用変更の管理は必要だが、最もコストと時間がかかる「一からの統合作業」を繰り返す必要はなくなる。137の組織ごとに個別対応するのは非現実的だ。統制された共通プラットフォームこそが臨床AIをNHS全体に迅速に普及させる唯一の道と言えよう。

プラットフォームではなく「データ基盤」が本質

　MIRAもAMIEも、Foundry上で構築されたわけではない。いずれもFHIRやICD-10、SNOMED-CTといった標準的な臨床データ形式を使用している。AIレイヤーは特定のプラットフォームに依存しない。依存しているのは、複数のソースから得られる構造化・標準化されたリアルタイムの臨床データだ。それも、AIが推論し、アクションを起こせる形式でなければならない。

　臨床AIが検証された研究環境では、こうした前提条件はすでにクリアされていた。データは整理され、アクセス可能な状態だった。研究者は統合の問題を解決する必要がなく、AIそのものに集中できたのである。

　NHSにとっての問いは「どのプラットフォームを使うか」ではない。統合の問題を全国規模で解決できるプラットフォームがあるかどうかだ。リアルタイムの接続性、書き戻し機能、そしてデータセット全体を推論できるAIレイヤーを備えたものがあるかという問いだ。

　PalantirのFoundryに備わるAIP機能は、これを提供している。後付けではなく、オントロジー上で直接動作するAIレイヤーだ。FDPの核心であるカノニカルデータモデルはNHSが所有する知的財産であり、公開もされている。原理的には別のプラットフォームでの再実装も可能だが、代替案を構築した者はまだいない。現在137のトラストで運用されているのは、議会で廃止の是非が議論されているそのシステムだけだ。

NHSのデータギャップ

　どのNHSトラストに足を踏み入れても、臨床情報は30以上のITシステムに分散している。電子カルテ、病理、画像、薬剤、産科、手術室、地域システムがそれぞれ断片的なデータを保持している。これらの大半はリアルタイムで対話できない。データモデルもコーディング手法も異なり、患者や病棟をシステム間でつなぐ共通のマスターデータすら存在しない。

　その傍らには、誰も監査していない非公式なレイヤーもある。患者リストを追跡するスプレッドシート。今日の退院予定を記したホワイトボード。会議のたびに印刷される患者リスト。アクセス制御も監査証跡もない共有ドライブの臨床データなどだ。

　現場では、データ統合の問題は解決されていない。過去25年間、共有ケア記録やローカル統合エンジンを通じて進歩はあった。しかし、共通のマスターデータに基づき、組織を越えて臨床オブジェクトを一貫して表現できる運用モデルは誕生しなかった。FDPのオントロジーとカノニカルデータモデルは、NHSが初めて手にした統制され移植可能な運用モデルなのだ。

　この基盤がなければ、自律型AIを導入するには137のトラストごとに個別に問題を解決しなければならない。デジタル化プロジェクトの歴史が示す通り、個別解決は失敗への道である。

チェンジマネジメントは「反対理由」ではなく「必要理由」

　最も熟慮された反対意見は、問題はテクノロジーではなく「現場の変革」にあるという主張だ。臨床チームが既存のツールを使いこなせるよう支援すれば、新しいプラットフォームがなくてもスプレッドシートやホワイトボードは消えるという。

　これには一理ある。あるトラストグループでは、同じ手術室スケジュール管理製品を導入しても病院間で成果に差が出た。その要因は、リーダーシップの質やチーム体制、プロセスを再設計する意欲といった組織面のものだった。チェンジマネジメントを伴わないテクノロジーの導入は失敗する。これはAIの時代になっても変わらない。

　ただ、既存のシステムがこれからやってくる変革を支えきれるという前提に立っている点で、その議論は不完全だ。データが分散し、システム同士が会話できない状態で、AI駆動の臨床製品のために現場を変えることはできない。NHSにはプラットフォームを作れば普及すると過信した苦い歴史がある。FDPでその過ちを繰り返してはならない。

　同時に、NHSには待っている余裕はない。医療従事者は減り続けている。この臨床能力の不足を補う政府の答えがAIであり、大半のトラストがまだ構築していないデータ基盤にかかっている。導入を1年遅らせることは、より少ないスタッフで、その負担を軽減できるツールなしに現場を回し続けることを意味する。インフラ整備と変革への投資は同時に行われるべきだろう。

遅延の代償

　NHSはテクノロジーの曲線から大きく遅れており、いまだにインフラの欠陥が支配している。保健大臣は2026年、3つのトラストで依然としてFAXが使われていることを認めた。タンパ総合病院がAIで命を救っている一方で、NHSの一部はインターネット以前のツールで患者の流れを管理している。

　このギャップの代償は、命で測られる。英国では敗血症で年間約4万8000人が亡くなっている。その約25％は、適切なタイミングでの診断と治療があれば防げた可能性がある。初期検知と迅速な対応、それこそがタンパのシステムが実現したものだ。

　デジタルのリーダーにとっての問いは、これが「来るかどうか」ではない。その時、自組織のインフラが整っているか。それとも、バラバラの30のシステムとホワイトボードに自律型AIをつなごうと現場が苦闘することになるのか。もし答えが分からないのなら、次の3点を自問してほしい。

• 自組織には現在、どのような運用データインフラがあり、どこにギャップがあるか？
• 職員が正式なITシステムの外で管理している臨床情報は何か？　そのリスクを誰が負っているのか？
• AI駆動の臨床製品が、論文の世界から現場の運用へと移る時、自組織はどう対応する計画か？