[LLM PoC]LLMによる疑義照会の半自動化PoC
こんにちは!PharmaXエンジニアリング責任者の上野(@ueeeeniki)です!
今回は、PharmaXで行っているLLMのPoCの中から、疑義照会の半自動化について簡単に説明します。
そして、LLMのアプリケーションへの応用上の課題やLLMがアプリケーション開発にもたらした革命的なポイントについて説明したいと思います。
疑義照会は、医療機関&薬局にしかない概念ですが、LLMのPoCを語る上では非常に面白い題材だと思っています。
事前に断っておくと、私たちがLLMのPoCとして発表する内容はあくまで「技術的に可能であること」を示すものであり、参考にされた方や企業の個人情報保護の問題などについては一切の責任を負いません。
自社のデータは、各企業や個人がきちんと責任を持って扱っていただければと思います。
特に、OpenAI社のAPIを使う場合には、個人情報の第三者提供にあたるため、細心の注意を払って取り扱ってください。
弊社では、LLMのPoC段階では、サンプルデータを作成してPoCを行っています。
また、あくまで「疑義照会の半自動化」という言葉を使っているように、最終的には薬剤師のチェックを経ることが望ましいでしょう。
今回の記事は、LLMで実際に何かを作ってみたいという方の参考になれば嬉しいです。
コードはほとんど出てこないため、エンジニア以外の方も読んでいただける内容かと思います。
疑義照会とはなにか?
そもそも疑義照会とは何か?という話から始めます。
疑義照会とは、薬剤師が処方せんの内容についての疑問点やおかしな点を発行した医師に問い合わせることです。
処方せんと聞いてピンとくる方ばかりではないと思いますが、処方せんとは下の添付画像のようなもので、病院やクリニックで医師に診断されるともらうことのできる紙(電子処方せんもあるがまだ)です。
薬局に行って、この紙を薬剤師さんに渡すと、引き換えに医療用医薬品を購入することができます。
大事なのは、画像内の赤枠の欄で、ここにその人に処方される医薬品名や1日の服用数、服用タイミング、合計の処方量などが記載されており、その内容に従って薬剤師が調剤※を行います。
欄の中には処方せんを発行するシステムごとに、さまざまなフォーマットで処方情報が記載されています。
※調剤とは「処方箋に基づいて医薬品をそろえ、患者に交付する業務」のことをいいます
問題は、この処方内容が間違っていることが多々あることです。
疑義照会の7、8割ぐらいが、法律に定められている処方量とのズレ(1日の最大容量を超えた量が処方されているなど)や、単純な記載ミスであることが多いでしょう。
薬の添付文書を読めば分かることではあるのですが、医師は薬の効能は理解していますが、すべての薬の情報が頭に入っているわけではありませんし、いちいち添付文書を見る時間もありません。
なぜ、そのようなチェック機構が医師のカルテに搭載されてないのかは不思議ではありますが、きちんとチェックをして医療事故を防ぐのが薬剤師の大事な仕事です。
今回のPoCでは、以下の4つについて可能か試しました。
①処方せん情報をテキストデータ化する
②処方せんのテキストデータから医薬品の処方情報を抜き出して構造化する
③処方情報とその医薬品の添付文書の内容を照らし合わせる
④疑義照会の文章を自動作成する
ここでは話を単純にするため、処方情報と下記のような添付文書の用法用量のみと照らし合わせることとしましょう。
GPT-4 APIによる半自動疑義照会システムのPoC
LLMの使いどころ
今回は特に、
・② 処方せんから医薬品の処方情報を抜き出して構造化する
・④ 疑義照会の文章を自動作成する
でGPT-4 APIを用いています。
より具体的には、
・②では、処方せんのフォーマットがクリニックごとに異なるため、処方情報を構造化して抽出する
・④では、薬ごとに異なる用法用量を解釈し、②で抽出した処方情報とのズレを指摘する
のにGPT-4を用いています。
それでは、早速解説していきましょう。
① 処方せん情報をテキスト化する
まず前提として、(電子処方せんが解禁されましたが、基本的には)処方せんは紙で発行されます。
紙の情報からOCRなどで処方せん情報をテキスト化する必要があります。
(紙どころかFAXの場合もありますが、ここでツッコまないこととします。)
ここはOCRの領域ですが、OCRを深堀るとそれはそれで一大テーマであり、今回の趣旨から離れすぎてしまうので、今回は省略することにします。
最近は、クリニックでのオンライン診療→薬局でのオンライン服薬指導などの場合、処方せんが最初からPDFなどの電子データで送られることも事例としては聞くようになってきました。
つまり、処方せんから
・処方せん画像などからOCRでテキストデータ化
・PDFなどの電子データからPythonライブラリのPDFMinerなどでテキスト情報を抽出
などの手順でテキストデータ化できたとしましょう。
② 処方せんから医薬品の処方情報を抜き出して構造化する
処方せんデータがテキスト化できたとしたら、次に下記画像の赤枠から処方情報を抜き出して、構造化します。
出力形式は、下記のようなJSONの配列形式にしたいとします。
ここで構造化したい理由としては、手順③で、DBに保存されているその薬の添付文書を取り出すときにLIKE検索をしたいからです。
技術的に困難なポイントは、処方せん内の処方情報欄の形式は処方せんを出力するクリニック側のシステムによってバラバラであることです。
それだけではなく、同じシステムでも処方せん2枚にまたがっていたり、下記のような省略が行われていたりします。
同じ処方せん内でも、半角・全角が混ざっていることがあることもあります。
このあたりが非常に闇深いポイントになります。
これまでの開発では、正規表現などでいろんなパターンをマッチさせて引っ掛けて来たのだと思いますが、複数あるテキストパターンから特定の情報を抜き出すのは、正規表現などでは難しくなります。
人間は長文のテキストの中から、テキストの意味を理解して特定の情報を抜き出す(例:議事録の中からTODOを見つける)ことが可能ですが、LLMでも同じことが可能です。
もちろん、わざわざLLMを使う以外の手法も存在しますが、ここではGPT-4のAPIを使って、処方せんのテキストから処方情報をJSON配列の形式で抽出することとします。
下記のように、いわゆる「Few-Shotプロンプティング」という手法で、さまざまな処方せん形式とそこから抽出するJSON配列の例をプロンプトに与えてあげましょう。
例を参考にして、入力されたテキストデータからJSON配列形式に構造化された結果を出力してください。
JSON配列形式=[{
"薬名": {薬名},
"1日摂取量": {1日摂取量},
"摂取タイミング": {摂取タイミング},
"処方量": {処方量},
"注意点": {注意点}
}]
------
入力例1="
セルトラリン錠25mg 1錠
無効の時2錠まで内服可
アトルバスタチン口腔内崩壊錠 1錠
【1日1回夕食後に】 (14 日分)
"
出力例1="
[{
"薬名": "セルトラリン錠25mg",
"1日摂取量": "1錠",
"摂取タイミング": "1日1回夕食後に",
"処方量": "14 日分",
"注意点": 無効の時2錠まで内服可
},
{
"薬名": "アトルバスタチン口腔内崩壊錠",
"1日摂取量": "1錠",
"摂取タイミング": "1日1回夕食後に",
"処方量": "14 日分",
"注意点": ""
}]
"
------
入力="
1) (先)プロプレス錠8 (8mg) 1錠
・・・1×朝食後 30日分
2) (先)リビディル錠80mg (80mg) 1錠
・・・1×朝食後 30日分
3) (先)フェブリク錠10mg (10mg) 1錠
・・・1×朝食後 30日分
"
出力=
どのような例を与えれば上手く行くのかは、ぜひ試行錯誤してみてください。(おそらく上述のような例だけでは上手くいかないと思います)
少なくとも私の手元では、GPT-4のAPIでFew-Shotプロンプティングを行ったところ、自作した数百枚の処方せんサンプルすべてに対して、処方情報を上手く構造化して抽出することができました。
このように処方情報を構造化して抽出することができれば、添付文書の内容と照らし合わせることが可能になります。
③ 処方情報とその医薬品の添付文書を照らし合わせる
処方情報とその医薬品の添付文書を照らし合わせることは、そう難しいことではなくLLMも登場しません。
医薬品の添付文書情報は、PMDAの検索ページで検索することができます。
スクレイピングなどの手法を用いて、医薬品ごとの用法用量を事前にDBにでも保存しておきます。
(医薬品の添付文書は、適宜改定されるので注意が必要です)
②で抽出した薬名でDBを検索すれば、薬ごとの用法用量を取得することが可能です。
④ 疑義照会の文章を自動作成する
ここまでくれば、後は②で処方せんから抽出した処方情報と、③の用法用量を照らし合わせて、気になるポイントを指摘するようにGPT-4のAPIに問い合わせるだけです。
当然、プロンプトの工夫が非常に重要になります。
ここでは、1日の用量にだけ着目して下記のようなプロンプトを与えることとしましょう。
1. 処方内容=
薬名: メトホルミン塩酸塩錠250mg
1日摂取量:3錠
摂取タイミング:1日3回毎食後に
処方量:14 日分
-
用法用量=通常、成人には1回1錠(アナグリプチン/メトホルミン塩酸塩として100mg/250mg又は100mg/500mg)を1日2回朝夕に経口投与する。
---
2. 処方内容=
薬名:抑肝散エキス顆粒
1日摂取量:7.5g
摂取タイミング:1日3回毎食前に
処方量:14日分
-
用法用量=通常、成人1日7.5gを2〜3回に分割し、食前又は食間に経口投与する。なお、年齢、体重、症状により適宜増減する。
---
3. 処方内容=
薬名:レンボレキサント錠2.5mg
摂取量:1錠
摂取タイミング:1日1回就寝前に
処方量:14日分
-
用法用量=通常、成人にはレンボレキサントとして1日1回5mgを就寝直前に経口投与する。なお、症状により適宜増減するが、1日1回10mgを超えないこととする。
------
それぞれの医薬品で処方内容と用法用量を照らし合わせて、気になるポイントがあれば処方内容と用法用量の内容を比較して教えてください。
特に、一日用量={薬名に含まれる用量×1日服用量}が所定の用法用量に記載されてる1日用量の上限を超えている場合には気になるポイントとして指摘してください。
問題がない場合は、気になるポイント:なし 、解説: なしとだけ答えてください。
出力フォーマットは以下の形式に従ってください。
薬名:{薬名}
1日摂取量:{1日服用量}
気になるポイント:{気になるポイント}
解説:{解説}
------
出力=
お分かりいただけるかと思いますが、②と③で取り出した情報を処方内容と用法用量に埋める必要があります。
処方内容=
薬名: {薬名}
1日摂取量: {1日摂取量}
摂取タイミング: {摂取タイミング}
処方量: {処方量}
-
用法用量={用法用量}
上記のようなプロンプトをGPT-4のAPIに投げた結果は以下の通りになります。
メトホルミン塩酸塩錠とレンボレキサント錠については、1日の摂取用量と添付文書に記載の用法用量のズレを指摘してくれています。
現場の薬剤師さんからすれば指摘が少し細かすぎるでしょうが、漏れなく指摘してくれている事は分かります。
プロンプトの工夫によっては、摂取タイミングがおかしいことや処方量が多すぎることなども指摘することが可能です。
こちらも私の手元で自作した数百枚の処方せんサンプルすべてに対して、GPT-4のAPIに問い合わせた所、数件を除いてほぼすべての処方せんで指摘漏れはありませんでした。
指摘の仕方などについても、②のとき同様にFew-Shotプロンプティングを行えば、より精度の高い指摘が可能になるでしょう。
今後の挑戦ポイント
今回は詳しくは解説しませんでしたが、処方せんの疑義照会には他にもいくつか困難なポイントがあります。
例えば、処方せんには医師の権限で処方内容が変更不可である旨を記載することが可能です。
このような場合には、疑義照会しなくてもよい場合があるため指摘をする必要がありません。
また、用法用量にも今回出した例の他にもさまざまな記載方法があり、一筋縄ではいきません。
このロキソニンのように効能・効果によって、用法用量が異なる場合があります。
実は、処方せんからのみでは医師がどの効能・効果を狙って薬を処方したのかは分からないのです。
このようなことまで勘案してLLMに指摘させるとすると、また少し工夫が必要になるでしょう。
まとめ〜LLMの凄さについて
今回は、疑義照会の半自動化の試みについて簡単に説明しました。
今回解説していない困難なポイントもありますが、少なくとも私自身は改善を行えば、かなりの精度で疑義照会が半自動化できるという手応えを得ることができました。
冒頭でも申し上げた通り、自社で同じようなことをする場合には、個人情報の扱いなどには十分お気をつけてください。
LLMの凄さについて
今回のPoCでも分かるようにLLMが開発にもたらす革命的なポイントはいくつかあると思っています。
① 非構造化データを扱えるようになったこと
LLMの凄さは、(『生成AI/LLMが切り拓く新たな医療の可能性とPharmaXの挑戦』という記事でも書きましたが)非構造化なインプットデータから有用なアウトプットが出すということが人間と同等もしくそれ以上に上手くできるようになったことです。
今回の例と照らし合わせると、以下のようになります。
・処方せんデータから処方情報を取り出すのは、非構造化データから構造化データを取り出す例です
・処方情報と用法用量から疑義照会の文章を作り出すのは、構造化データから非構造化データを作成する例です
このように構造・非構造のデータを精度高く変換できるようになれば、かなりアプリケーション開発の自由度が高まります。
② Few-shotプロンプティングで独自のデータを例として与えることが出来る
これまでのAI開発では、自社のやりたいタスクが特徴的であれば、ある程度自社のデータを与えて、独自のモデルを作る必要がありました
事前学習を自社で行うか、既存のモデルをFine-Tuningすることになります。
しかし、今回の例のように、Few-shotプロンプティングで例を与える工夫をすれば、十分に独自のタスクをこなすことは可能です。
他にも例えば、弊社PharmaXのプロダクトでいうと、薬剤師チームが患者さんとやり取りするメッセージをサジェッションすることなどは、薬剤師チームの対応例などを与えて上げれば十分可能です。
もちろん、どのような例を与えるか?などは重要ですが、プロンプトエンジニアリングの世界で完結するのであれば、PDCAを回す速度は劇的に速まります。
Fine-Tuningする必要があるならば、データを準備するなど時間的にもかなりのコストがかかってしまいます。
このように今回のPoCでは、十分にLLMの可能性を感じることができました。
いつでもご連絡ください
もっと詳しい話を聞きたいなど、ご興味がある方は、YOUTRUSTまたはTwitter DMからご連絡をお待ちしています!
GW明けにLLM周りの取り組みを紹介するイベントもやるので、ぜひご参加いただければ嬉しいです!
また、生成AI/LLMの専任チームも立ち上げておりますので、ご興味ある方はご連絡ください!
この記事が気に入ったらサポートをしてみませんか?