Mercy の AI リーダー: 戦略第一、常にガバナンス

マーシーのエンタープライズ AI および意思決定インテリジェンス担当副社長、ケリー ボマリート博士は、医療システムの AI の課題は、輝かしいツールではなく、エンタープライズ プランから始まると述べています。経営陣が会計年度ごとに組織全体の 5 つの OKR を設定した後、責任あるリーダーに作業の流れが段階的に流れます。ボンマリート氏は、自動化と AI による収益サイクルの改善を目的とした重要な成果の管理委員を務めています。初期の優先事項には、拒否、事前承認、検査の承認から請求までの患者の引き継ぎが含まれます。これらの分野では、テクノロジーによってスタッフの負担が軽減され、患者エクスペリエンスが向上します。

このインタビューは、最近出版された記事の一部として行われました。 AI特別レポート

彼女は、スコーピングはプラットフォームではなく問題から始まることを強調します。つまり、運用目標を定義し、その後、分析、ワークフローの標準化、EMR 構築、または AI が適切な手段であるかどうかを評価します。ボマリート氏は、この規律により、適合性の低いパイロットにリソースが分散することを回避し、貴重なエンジニアリング時間を物質的価値に向けることができると主張しています。 「AI がすべてを解決できるわけではありません。もちろん、AI にできることはたくさんあります。しかし、できないこともたくさんあります。」と彼女は述べ、解決可能な問題であっても、価値実現までの時間と保守性によっては、社内ビルドよりもベンダーとのパートナーシップを通じてより適切に対処できる可能性があると指摘しました。

ポッドキャスト: 新しいウィンドウで再生する | ダウンロード (長さ: 33:30 — 23.0MB)

購読する： アップルのポッドキャスト | スポティファイ | アンドロイド | パンドラ | アイハートラジオ | ポッドチェイサー | ポッドキャストインデックス | 電子メール | チューンイン

データ品質とベンダーの現実

Bommarito は、ソリューションの選択をデータの準備状況に結び付けます。彼女は、下流のテクノロジーがどの程度うまく機能するかを決定する要因として、EMR への一貫した入力、標準化されたフレーズ、ワークフローの均一性といった基本を挙げています。彼女の見解では、想定されるデータ仕様がサイト固有の現実と衝突すると、ベンダーの実装が行き詰まるという。彼女は、医療システムはこれらの仮定を事前にプレッシャーテストし、独自のデータ収集とガバナンスの基準を管理する必要があると指摘しています。そのために、彼女は、チームがドキュメントのパターンと例外パスがモデルの入力と出力をどのように形成するかを確認できるように、調査全体を通じて情報学者と運用リーダーをエンジニアとペアにすることを推奨しています。

別個のトラックとしてのガバナンス

彼女は、Mercy の構造は意図的なものであると説明しています。エンタープライズ データおよび AI オフィスは、AI ガバナンスとともに、中核となる IT 組織の外側にあります。専任のレビュー担当者がベンダー モデル カードを調査し、責任ある AI 慣行へのコンプライアンスを追跡します。 Mercy はまた、AI 通知要件を契約に組み込んでおり、サプライヤーが評価期間なしで新機能を「オン」にすることはできません。 「AI ガバナンスは、組織の設立方法にもよりますが、独立したプロセスであるべきだと思います」とボマリート氏は言います。彼女の目的は、アップグレードを阻止することではなく、AI チェックをセキュリティおよび IT 変更管理と同期させ、臨床医に対する透明性と、意図された用途と意図しない用途の明確性を確保することであると付け加えました。

規制、リスク、そして関与する人間

彼女は臨床安全に関して明確な線を引いています。医療機器として機能する可能性のある機能はすべて、FDA への影響について審査する必要があり、臨床場面で大規模な言語モデルを使用する場合は、人間を常に関与させておく必要があります。教育は不可欠です。臨床医は、ツールが何を行うように設計されているのか、またそうではないのか、そのツールがどのようにして推奨に至ったのか、そしてどこに限界があるのかを知る必要があります。その責任をマーケティングレーベルに委託することはできない、と彼女は指摘する。 「ツールを使用するのはあなたであるため、それは依然としてあなたの責任です」と付け加え、ベンダーが自社の製品が規制対象のデバイスではないと主張する場合でも、医療システムはガバナンスの姿勢を検証する必要があると付け加えた。

スケールに合わせて構築されたパイロット

ボンマリート氏は、「パイロット」という言葉を、一回限りのライセンスではなく、エンジニアリングの慎重さを示すものだと考えています。社内で開発された取り組みは、プラットフォーム (再利用可能なマイクロサービスとエージェント) として設計されているため、あるサービス ラインで概念実証が成功すると、他のサービス ラインにもすぐに拡張できます。考え方によって「使い捨て」コードが防止され、価値が証明されればスケールが加速されます。ベンダーのパイロットについて、彼女はリーダーたちに現実的な予算を立てるよう警告しています。特に単一 EMR 環境では、限定的なトライアルを可能にするための IT の強化は、完全な実装に匹敵することがよくあります。早めにリソースを組み立てることで、無制限の実験を回避し、意思決定のマイルストーンを明確に保つことができます。

何が重要かを測定する

彼女はチームに対し、財務、運営、経験などの価値指標を最初に宣言し、現実が計画から乖離した場合でも柔軟性を保つようアドバイスしています。文書作成の負担の軽減など、一部のメリットは定性的なものになります。その他、拒否防止や事前認証サイクル時間の短縮など、前後のビューを明確にするのに役立ちます。ボマリート氏は、根本的な問題を中心に解決策の要求を再構成することも推奨しています。場合によっては、ダウンストリームの修正を最適化するよりも、アップストリームで問題を防ぐことがより良い解決策となる場合があります。ここで、情報学、運用、エンジニアリング間の緊密な連携が、迅速な反復と継続的なフィードバックを通じて成果をあげることができると彼女は指摘します。

テイク・イット・アウェイ

• AI 投資を企業の OKR に固定します。ツールではなく目的を重視してスコープを推進する
• ベンダーのデータ仕様を実際のワークフローと文書化パターンに照らしてプレッシャーテストする
• AI ガバナンスを IT 変更管理から分離し、プロセスを並行して実行する
• ベンダーがすでに使用されている製品に AI を追加する場合は、契約上の通知が必要です
• 社内の「パイロット」を再利用可能なサービスとエージェントを備えたプラットフォーム構築として扱う
• 完全な導入であるかのように、ベンダーのパイロットに予算を設定します。それに応じてスタッフ
• 価値の指標を事前に宣言しますが、必要に応じて定性的なメリットも考慮します
• 下流での改善よりも上流での運用上の問題の予防を優先します
• 臨床での LLM の使用については常に人間に知らせてください。エンドユーザーに機能と制限について教育する
• 情報学者とオペレーターを継続的に関与させて、エッジケースと例外を明らかにする

彼女は、進化するフロンティアの動作原則として謙虚に立ち返り、「AI で実際に何ができるのか、何ができないのかについて謙虚になる必要があります。」と述べています。