簡単な回答: 医療データにおけるAIは7つの質問からなるパイプラインであり、ほとんどの失敗はどれか一つを飛ばすことから生じます。データはどこから来るのか（FHIRレコード、文書、デバイス、患者自身の言葉）？ モデルはどのようにデータにアクセスするのか（関連するものを集めるコンテキストAPI、モデルコンテキストプロトコルサーバー、レコードからの検索）？ 誰が許可したのか（患者の同意、目的と期間でスコープ化され、記録されている）？ データ内の人々を何が保護するのか（ケアコンテキストから離れるものはすべて匿名化、開発には合成データ、研究には仮名化）？ すべての出力は追跡可能か（入力と出力の出所）？ どうすれば機能することがわかるのか（臨床的なグラウンドトゥルースに対する評価、感覚ではなく）？ どのルールが適用されるのか（GDPR第9条および第22条、臨床的意思決定に情報を提供する場合はMDR、EU AI Act、HIPAA）？ このページは地図であり、各質問には独自のページがあります。
パイプライン
医療データにおけるAIのパイプラインは7つの段階からなり、それぞれに問いがあります。ソース（データがどこから来るか）、アクセス（モデルがどのようにデータに到達するか）、コントロール（誰が許可したか）、プライバシー（個人をどのように保護するか）、トレーサビリティ（出力が追跡可能か）、評価（成功をどのように測定するか）、そしてルール（どの法律が適用されるか）です。
| ステージ | 質問 | 良い状態とは | ページ |
|---|---|---|---|
| ソース | データはどこから来るのか？ | コード（LOINC、SNOMED CT、ATC）付きのFHIRレコード、構造が抽出された文書、出所が明記されたデバイスデータ。スクリーンショットやPDFだけではない | FHIR Observation, FHIR DiagnosticReport |
| アクセス | モデルはどのようにデータにアクセスするのか？ | レコードの境界が定められ、出所が明記されたスライスを返すコンテキストAPIまたはMCPサーバー。ダンプではなく、構造化されたフィルターによる検索 | RAG on medical records, Healthcare API for AI, MCP server |
| コントロール | 誰が許可したのか？ | 目的と期間ごとの患者の同意。サーバー側で強制されるスコープ。患者が閲覧できるアクセスログ。機能する取り消し | Patient consent platform, Who viewed my record? |
| プライバシー | 人々を何が保護するのか？ | 特定されたデータはケアコンテキスト内に留まる。開発、分析、モデルトレーニングには匿名化または合成データ。許可の下での研究には仮名化されたデータ | De-identification, Synthetic patient data |
| トレーサビリティ | 出力は追跡可能か？ | すべての入力（誰が、いつ、どこから記録したか）とすべてのAI出力（モデル、バージョン、使用された入力）の出所が、レコードと共に保存される | Medical data provenance |
| 評価 | どうすれば機能することがわかるのか？ | 臨床的なグラウンドトゥルースを持つテストセット、ソースへの忠実性、サブグループによるエラー分析、本番環境での監視、人間のレビューパス | Evaluating clinical LLMs |
| ルール | どの法律が適用されるのか？ | GDPR第9条および第22条、DPIA。出力が診断または治療に情報を提供する場合はMDR。AI Actの高リスクレジーム。米国ではHIPAA | The EU AI Act and health AI, SaMD classes, GDPR Article 9 |
3種類のAI、3つのリスクプロファイル
医療データにおけるAIには、3つの種類と3つのリスクプロファイルがあります。アシスタティブAIや管理AI（平易な言葉での要約や下書きメモなど）では、プライバシーと見逃されたエラーのリスクがあります。意思決定支援（相互作用のフラグ付けやトリアージなど）では、臨床的なリスクがあり、MDRが適用されます。そして、集団および研究AIでは、再識別とバイアスのリスクがあります。
支援および管理: 患者のためにレコードを平易な言葉で要約する、トランスクリプトから臨床医が編集するための診療記録を作成する、同意を得たレコードで「最後の血液検査はどこ？」と答える。リスクはプライバシーと、人間が見落とす可能性のあるエラーにあります。臨床的意思決定に情報を提供しない限りMDRは適用されませんが、AI Actの透明性義務とGDPRは適用されます。
意思決定支援: 相互作用をフラグ付けする、鑑別診断を提案する、トリアージする。リスクは臨床的です。MDR（通常はクラスIIa以上）が適用され、AI Actの高リスクレジームが続き、IEC 62304と臨床評価が必要です。このようなシステムがEHRにどのように接続されるかについては、CDS Hooks explainedを参照してください。
集団および研究: 多くのレコードにわたるパターンを見つける、医薬品安全性監視シグナル、コホート発見。リスクは再識別とバイアスです。データは許可の下で匿名化または仮名化され、最小セルサイズで集計され、方法は交絡について評価される必要があります。Secondary use of health dataを参照してください。
失敗モード
医療データにおけるAIの一般的な失敗モードは、レコード全体をプロンプトに詰め込むこと、ドキュメントを介したプロンプトインジェクション、臨床医が行ったかのようにモデルの推測をレコードに書き込むサイレント推論、法的根拠なしに識別されたデータでトレーニングすること、ベンダーのデモセットのみで評価すること、そして患者データでいっぱいのデバッグログです。
- コンテキストの詰め込み: プロンプトにレコード全体を貼り付ける。コストがかかり、データが漏洩し、モデルは間違った部分に注意を向けます。出所が明記された、境界が定められランク付けされたコンテキストの方がうまく機能し、監査可能です。
- 文書を介したプロンプトインジェクション: 「以前の指示を無視してください」と書かれたスキャンされた手紙。すべてのレコードコンテンツをデータとして扱い、ポリシーを設定させないでください。RAG on medical recordsを参照してください。
- サイレント推論: モデルが行動から診断を推論し、臨床医が行ったかのようにレコードに書き込む。出力はAI生成として出所と共にラベル付けされ、人間の主張なしにConditionになることはありません。FHIR Condition explainedを参照してください。
- 法的根拠なしに特定されたデータでのトレーニング: 患者レコードでのファインチューニングには、「データがあった」以上の法的根拠が必要です。通常、匿名化または合成データが役立ちます。
- ベンダーのデモセットでの評価: あなたの集団、あなたの言語、あなたの文書タイプで評価し、展開後も評価を続けてください。
- PHIでいっぱいのログ: デバッグのためにログに記録されたプロンプトと完了は、2番目の保護されていないレコードになります。コンテンツを仮名化するか、ログに記録しないでください。
標準とビルディングブロック
医療データにおけるAIの標準とビルディングブロックは、レコードと構造化されたAI出力のためのFHIR、ツールとデータへのガバナンスされたアクセスためのModel Context Protocol、認可のためのSMART on FHIR、トレーサビリティのためのHL7のAI/MLデータライフサイクル作業、AI管理のためのISO/IEC 42001、そしてAI法（AI Act）の調和された標準です。
レコードおよびAIの構造化された出力（derivedFrom付きのObservation、生成された要約のDocumentReference、モデルをエージェントとするProvenance）のためのFHIR。ツールとデータへの管理されたアクセスをAIアシスタントに提供するためのModel Context Protocol。承認のためのSMART on FHIR。トレーサビリティのためのHL7 AI/ML Data Lifecycleと出所の作業。AI管理システムのためのISO/IEC 42001。公開されるAI Actの調和規格。
Anpherosにて
医療データにおけるAIに関して、Anpherosはコードとプロビナンスを備えたFHIR R4レコード、トークン予算内でプロビナンスラベル付きのレコードのスライスを返すコンテキストAPI、個人の同意を得てアシスタントが個人のレコードを読むためのMCPサーバー、そして個人が管理する同意とアクセスログを提供します。Anpherosは診断AIを実行しません。
Anpherosは、レコード（FHIR R4、コード付き、出所付き）、トークン予算内で出所が明記されたスライスを返すコンテキストAPI、アシスタント（Claudeなど）が患者の同意を得て個人のレコードを読み取るためのMCPサーバー、および個人が制御する同意とアクセスログを提供します。診断AIを実行したり、AI推論を臨床的事実としてレコードに書き込んだりしません。開発者サイトに詳細があります：healthcare API for AI, MCP server, LLMs on healthcare data。
関連ページ
- RAG on medical records: how retrieval over a FHIR record works
- The EU AI Act and health AI
- Healthcare API for AI: provenance-labelled patient context
- De-identification of health data
- AI and your medical record (for patients)
- Secondary use of health data
- Anpheros MCP server (developer site)
- LLMs on healthcare data (developer site)
出典
- Model Context Protocol specification
- HL7 FHIR R4: Provenance
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex
- ISO/IEC 42001:2023, AI management system
- WHO: Ethics and governance of artificial intelligence for health, guidance on large multi-modal models (2024)
- HL7 SMART App Launch
よくある質問
患者レコードでモデルをファインチューニングできますか？
その目的のための法的根拠（同意、または保護措置を伴う第9条(2)(j)に基づく研究根拠）があり、DPIAを実施し、通常は匿名化が必要です。特定されたレコードは、利用可能だったという理由だけでトレーニングに使用することはできません。合成データと匿名化されたデータは、ほとんどの開発ニーズに対応します。
レコードのAI要約は医療機器ですか？
診断や治療のために解釈することなく、患者や臨床医のためにレコードの内容を言い換える場合はそうではありません。臨床的に所見の意味を提案した瞬間に、それはMDRの下での意思決定支援となります。
MCPとは何ですか、なぜここで重要なのでしょうか？
Model Context Protocolは、定義された機能を持つサーバーを介して、AIアシスタントをツールやデータソースに接続するためのオープンスタンダードです。医療データの場合、アシスタントがデータをチャットに貼り付けるのではなく、同意とログ記録を得て、管理されたサーバーを介して個人のレコードを読み取ることができます。
臨床LLM機能をどのように評価しますか？
あなたの集団からの実際のケースの保留セットを臨床医によってラベル付けし、正確性とソースへの忠実性のためのメトリック、サブグループと言語による分析、失敗ケースのレビュー、および展開後の監視を行います。ベンダーのベンチマークは出発点であり、証拠ではありません。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →