大規模言語モデルによる医療データの相互運用性の強化: FHIR 調査

リンク一覧

導入

方法

結果と考察

結論と参考文献

導入

多様なプラットフォームやシステム間での医療データの統合と交換は、標準化された形式や共通の意味理解がないため、依然として困難です。重要な医療情報が、整理された構造化形式ではなく非構造化データに埋め込まれている場合、この課題はさらに深刻になります。臨床記録などの非構造化医療データを FHIR リソースに標準化すると、さまざまな医療提供者間のあいまいさが軽減され、相互運用性が向上します。ただし、これは決して簡単な作業ではありません。以前の研究 1,2 では、臨床名エンティティの認識、用語コーディング、数学的計算、構造フォーマット、および人間による調整を含む複数のステップのプロセスを通じて、自然言語処理と機械学習ツールを組み合わせて、臨床記録を FHIR リソースに変換することを試みました。ただし、これらのアプローチでは、複数のツールからの結果を統合するために追加の人間の労力が必要であり、さまざまな要素の F1 スコアが 0.7 ～ 0.9 の範囲で、中程度のパフォーマンスしか達成されていません。この目的のために、大規模言語モデル (LLM) を利用して、フリーテキスト入力から FHIR 形式のリソースを直接生成する予定です。 LLM を活用することで、これまで複数ステップだったプロセスが簡素化され、自動 FHIR リソース生成の効率と精度が向上し、最終的には医療データの相互運用性が向上することが期待されます。

方法

データ注釈私たちの知る限り、コンテキストデータから生成された FHIR 標準のデータセットで、広く公開されているものはありません。そのため、私たちは、FHIR 形式のフリーテキスト入力と構造化出力の両方を含むデータセットに注釈を付けることにしました。フリーテキスト入力は、MIMICIII データセットの退院サマリーから取得されました。3 本質的には名前付きエンティティ認識タスクを含む 2018 n2c2 投薬抽出チャレンジ 4 のおかげで、投薬ステートメントの要素が特定されました。私たちの注釈はこれらの n2c2 注釈に基づいており、フリーテキストを NDC、RxNorm、SNOMED などの複数の臨床用語コーディングシステムに標準化しました。コンテキストとコードを FHIR 投薬ステートメントリソースに整理しました。変換された FHIR リソースは、構造、データ型、コードセット、表示名など、FHIR 標準への準拠を保証するために、公式の FHIR バリデーター (https://validator.fhir.org/) による検証を受けました。これらの検証済みの結果は、ゴールド スタンダード変換結果とみなされ、LLM に対するテストに使用できます。MIMIC データセットと n2c2 データセットは両方とも許可されたユーザーに公開されているため、データの使用に関して倫理的な懸念はありません。

大規模言語モデルFHIR 形式変換用の LLM として、OpenAI の GPT-4 モデルを使用しました。5 つの個別のプロンプトを使用して、入力されたフリーテキストをそれぞれ、投薬 (投薬コード、強度、および形態を含む)、経路、スケジュール、投薬量、および理由に変換するように LLM に指示しました。すべてのプロンプトは、タスクの指示、.JSON 形式の予想される出力 FHIR テンプレート、4～5 個の変換例、モデルが選択できるコードの包括的なリスト、および入力テキストという構造のテンプレートに準拠していました。実験では微調整やドメイン固有の適応は行われなかったため、最初は LLM に小さなサブセット (N = 100) を生成させました。次に、LLM が生成した FHIR 出力と人間の注釈との間の矛盾を手動で確認しました。よくある間違いが特定され、プロンプトの改善に使用されました。重要な点として、薬剤名の NDC、RxNorm、SNOMED 薬剤コードの全リスト、および SNOMED 所見コードには、理由によりアクセスできなかった点が挙げられます。また、たとえそのような包括的なリストがあったとしても、LLM のトークン制限を超えてしまうでしょう。そのため、LLM にこれらのエンティティのコーディングを任せず、代わりに、入力テキストに記載されているコンテキストを識別するように指示しました。薬剤の投与経路や剤形など、数百に及ぶその他の要素については、LLM が直接コーディングできるようにしました。LLM が生成した出力を評価する際の主な基準は、完全一致率でした。これには、コード、構造など、あらゆる面で人間の注釈と正確に一致させる必要があります。さらに、特定の要素の出現について、精度、再現率、F1 スコアを報告しました。MIMIC データの責任ある使用ガイドラインに沿って、Azure OpenAI サービスを通じて GPT-4 API にアクセスしました。私たちが使用した具体的なモデルは、「gpt-4-32k」の「2023-05-15」バージョンです。各テキスト入力は個別に MedicationStatement リソースに変換されました。効率を最適化するために、複数の非同期 API 呼び出しを行いました。

結果と考察

注釈と FHIR 生成の結果を表 1 に示します。要約すると、625 種類を超える異なる薬剤を網羅し、354 の理由に関連付けられた 3,671 件の薬剤リソースに注釈を付けました。大規模言語モデル (LLM) は、すべての要素にわたって 90% を超える優れた精度と 0.96 を超える F1 スコアを達成しました。以前の研究では、F1 スコアは、timing.repeat で 0.750、timing.route で 0.878、timing dosage で 0.899 に達しました。1 LLM はこれらの F1 スコアを少なくとも 8% 向上させました。以前の研究では、より小規模なプライベート データセットを使用し、完全一致率などの最も厳格な評価指標を採用せず、用語コーディングをスキップし、広範なトレーニングを必要としたことは注目に値します。さらに調査を進めると、用語コーディング (基本的には 100 を超えるクラスの分類タスクを含む)、数学的変換 (たとえば、入力に「TID、30 錠を分配」と記載されている場合に 10 日間の期間を推測する)、形式の適合性 (結果が .JSON 形式で解釈できない可能性は 0.3% 未満)、およびカーディナリティ (LLM は 1:N と 1:1 の両方の関係を処理できる) における高い精度にも感銘を受けました。

出力の精度は、使用する指示プロンプトに大きく依存します。私たちは、広範囲にわたる試行錯誤の結果、次のような推奨事項を策定しました。i) さまざまなエッジ ケースを網羅する多様な変換例を提供する。ii) 出力が期待される形式と結果に準拠するように、「MUST」などの強い言葉を使用する。iii) 小さなサブセットの結果を確認してプロンプトを継続的に更新および改良し、一般的な間違いを特定して全体的な精度を向上させる。iv) 語彙にないコーディングには注意する。LLM は、近い一致が見つからない場合に、存在しないコードを作成してユーザーの要求に応えようとする場合があります。

結論

この研究では、フリーテキスト入力を FHIR リソースに変換することで、LLM を活用して医療データの相互運用性を高めるための基盤を提供しました。今後の研究では、生成をさらに FHIR リソースに拡張し、さまざまな LLM モデルのパフォーマンスを比較することで、これらの成功をさらに発展させることを目指します。

参照

1. Hong N、Wen A、Shen F、Sohn S、Liu S、Liu H、Jiang G. FHIR ベースの型システムを使用した構造化および非構造化 EHR データの統合: 投薬データのケース スタディ。AMIA Summits on Translational Science Proceedings。2018;2018:74。

2. Hong N、Wen A、Shen F、Sohn S、Wang C、Liu H、Jiang G. 非構造化および構造化電子医療記録データを標準化および統合するためのスケーラブルな FHIR ベースの臨床データ正規化パイプラインの開発。JAMIA オープン。2019 年 12 月;2(4):570-9。

3. Johnson AE、Pollard TJ、Shen L、Lehman LW、Feng M、Ghassemi M、Moody B、Szolovits P、Anthony Celi L、Mark RG。MIMIC-III、無料でアクセスできる集中治療データベース。科学データ。2016年5月24日;3(1):1-9。

4. Henry S、Buchan K、Filannino M、Stubbs A、Uzuner O。2018 n2c2電子医療記録における薬物有害事象と薬剤抽出に関する共有タスク。米国医療情報学会誌。2020年1月;27(1):3-12。