想定事例. これは説明用の想定事例であり、顧客の実績ではありません。クリニックグループも、ここに出てくる数字もすべて仮定です。事前承認のためのAIを示します。患者カルテを読み、保険者が求める事実を拾い、パケットを組み立てるソフトウェアです。医学的必要性は判断せず、自分では何も提出しません。承認するのはコーディネーターです。
複数のクリニックを持つグループで、事前承認パケットの準備が遅いと想像してください。説明のために、コーディネーターがカルテ、保険者のポータル、チェックリストの間で事実を写す作業に時間を取られていると仮定します。この記事では設計と、何を測るかを順に見ていきます。結果は報告しません。
グループは架空なので、名前を挙げる顧客はいません。名前より大事な点が一つあります。パイプラインは抽出して組み立てますが、自動提出は決してしません。コーディネーターがすべてのパケットを承認し、実行のたびに、モデルが何を読み何を生成したかの監査ログが残ります。
事前承認の案件で時間はどこに消えますか?
作る前にまず測ります。コーディネーターが案件のサンプルを準備する様子を観察し、各ステップの時間を計ります。書くのは速い。探す、読む、打ち直すのが遅いのです。
- カルテを読み、診断、効果のなかった投薬、指示した医師のメモを見つける。
- それらの事実を、プランごとに異なる個別の保険者の要件に突き合わせる。
- すべてをパケットとポータルに打ち直し、二重に確認する。作業は中断のたびに分断される。
- 待つ。作りかけのパケットは、コーディネーターが戻るまで止まったままになる。
だから目標は「もっと速く書く」ことでは一度もなかった。「カルテにすでにある事実を人に探させるのをやめる」ことだった。
#事前承認のAIは準備の手間をどう減らしますか?
AIは事前承認の準備時間をどう減らしますか?
カルテを読み、保険者が求める臨床上の事実を抽出し、パケットを下書きします。コーディネーターは打ち直す代わりに確認します。クリニックグループは、準備時間とコーディネーターの工数を導入の前後で測ります。保険者に届く前に、すべての提出を承認するのは引き続きコーディネーターです。
パイプラインは4つのステップで動く。カルテから関連する事実を抽出し、保険会社のパケット形式に組み立て、必須項目が揃っていて内容に矛盾がないかを検証し、コーディネーターの承認キューへルーティングする。人間が承認をクリックしない限り、そのキューから何も出ていかない。
この設計は、物流クレームやオンボーディングの想定事例と同じ書類処理のパターンを使い、規制の厳しい医療分野向けに調整したものです。形はAI導入のページで説明しています。抽出、検証、振り分け、人による承認キューです。ここでの違いは監査ログです。医療なので、モデルが読んだ項目と書いた項目をすべて記録し、レビュー担当者がパケットのどの行もカルテ上の出典まで遡れるようにします。
#AIが事実を間違えたらどうなるのか
人が読むので、見つかります。承認キューの存在意義はそこにあります。下書きされたパケットの一部は、コーディネーターによる項目の修正や追加が必要になると見込み、その割合を追跡してください。それはパイプラインの失敗ではありません。パイプラインが役目を果たしている状態です。下書きを素早く出し、人が探す代わりに確認に時間を使えるようにします。
We are
Stennirは、コーディネーターが承認するためのprior authorizationパケットを下書きし、完全な監査証跡を備えた書類処理パイプラインを構築する。
We aren't
Stennirは、医療上の必要性を判断したり、自ら保険会社にクレームを提出したりする自動提出ボットではない。
ここに顧客の発言はありません。顧客が存在しないからです。この設計の試金石は、モデルが何も判断しないまま、コーディネーターがカルテの打ち直しをやめられるかどうかです。
クリニックグループは何を測りますか?
パケットの準備時間とコーディネーターの工数を、導入の前後で、同じクリニック、同じコーディネーター、同じ保険者構成で測ります。基準値は何かを変える前に取ります。そうして初めて、本物の改善とデモを区別できます。ここでは結果を主張しません。
クリニックグループの運営を担い、チームがカルテを保険者ポータルに打ち直しているなら、この種の仕事が当てはまります。この例と同じく、何かを作る前にまず測るところから始めます。その考え方はAIコンサルティングのページに、私たちの発想はジャーナルの残りの記事にあります。自分の一週間のようだと感じたら、何を作っているか教えてください。
