臨床データはすでにデジタル化されているのに、
なぜ手作業で抽出されるのか

臨床文書化の二つの並行世界

臨床文書は、互いにほとんど連携しない二つの情報エコシステムの中に存在します。一つ目は構造化データです。チェックボックス、ドロップダウンメニュー、ラジオボタン。診断を分類するICD-10コード。処置を記述するCPTコード。データベースのフィールドに収まる検査値（ヘモグロビン12.3 g/dL、クレアチニン0.9 mg/dL）。これはEHRが管理するために構築された世界です。検索可能で、クエリ可能で、レポート作成も可能です。しかし、量と臨床的な豊かさの点では、これは浅い部分にすぎません。

二つ目の世界は非構造化データです。臨床医が実際に診たもの、考えたこと、行ったことを記述する際に生成する叙述的な散文です。「右上葉に1.2 cmの棘状結節があり、胸膜陥入を伴う — CTガイド下生検を推奨」と記された放射線科レポート。発症時の症状から合併症、退院後の指示まで、12日間の入院を詳述する退院サマリー。どの血管に、どのグラフトを用いて、どのような条件下でバイパスを行ったかを800語の外科的詳細で記述する手術記録。3回のシフトにわたる臨床医の評価の変化を捉えた経過記録。

この二つ目の世界、すなわち叙述の世界には、医療記録内の臨床的に意味のあるデータの約80%が含まれていると推定されています。そこには意思決定の背後にある推論、診断コードが平坦化してしまうニュアンス、検査値を単なる数字ではなく実践可能なものにする文脈が含まれています。そして、この世界はデフォルトでは、病院内のあらゆるレポートツール、分析プラットフォーム、自動化ワークフローから見えない状態にあります。

構造化された世界は「何が起こったか」を簡潔に答え、非構造化の世界は「なぜ起こったのか、それが何を意味するのか、次に何をすべきか」に答えます。問題は、機械が前者しか読めないことです。

EHRがこの問題を解決しなかった理由

2009年のHITECH Actが米国病院のEHR導入率を9%から90%以上に押し上げて以来、合理的な前提が持続しています。電子健康記録はデータアクセシビリティの問題を解決するはずだというものです。臨床情報がデジタルなら、機械可読であるべきです。機械可読なら、クエリ可能であるべきです。クエリ可能なら、手動抽出は時代遅れになるはずです。

その前提は最初の段階で崩れます。EHRは臨床知識システムではありません。EHRは請求処理に最適化されたトランザクショナルデータベースであり、患者診療のデジタル化の主なユースケースが保険請求の生成だった時代に構築されました。主要なEHRプラットフォーム（Epic、Cerner、Meditech、Allscripts）に組み込まれた中核的なエンジニアリング上の決定は、臨床叙述を構造化フィールドではなく非構造化添付ファイルとして保存するというものです。病院内のPACSで生成された放射線科レポートは患者記録に添付されます。フリーテキストボックスに入力された退院サマリーはテキストブロブとして保存されます。手術記録はPDFとしてアップロードされます。

EHRはこれらの文書を保存します。しかし、解析はしません。内容のインデックス化もしません。「右上葉の1.2 cmの棘状結節」というフレーズを、クエリで取得できる構造化データ要素にマッピングすることもありません。データベースの観点から見ると、放射線科レポートも退院サマリーも手術記録も、1998年の紙カルテのスキャンコピーと同じカテゴリに分類されます。デジタル化されているが構造化されておらず、保存されているが検索できない。

2025年にJournal of Medical Internet Researchに掲載された研究では、180万人の患者を対象に、構造化コードと自由記述テキストの間の情報の重複を調査しました。その結果、構造化データだけ（ICDコード、処置コード、検査値）では、臨床像のごく一部しか捉えられないことが判明しました。自由記述テキストには「患者ケアのニュアンスを捉えた詳細な記述」が含まれていました。EHRの構造化フィールドは、患者がCABGを受けたことを示していました。手術記録は、CABGがどのように行われたかを示していました。これは、品質測定、リスク調整、臨床研究にとって極めて重要です。

これは、特定のEHRベンダーの失敗ではありません。EHRが設計された目的の結果です。EHRは、請求や規制報告のために構造化データを取得するように構築されました。物語から意味を抽出するようには構築されていませんでした。臨床データの80%が自由記述テキストにあるという事実は、バグではありません。臨床医が複雑な情報を伝達する人間の方法、つまりドロップダウンではなく文章でケアを記録することの自然な結果です。

誰も語らない抽象化労働力

EHRは臨床記録を検索不可能な塊として保存するため、病院は、それらの記録を読み、特定のデータポイントを他のシステムに手動で入力することをフルタイムの仕事とする専門職階級を丸ごと雇用しています。彼らは臨床データアブストラクターと呼ばれ、米国医療における最大の隠れた人件費の一つを代表しています。

臨床データアブストラクターは、通常、正看護師（RN）、登録医療情報技術者（RHIT）、または認定腫瘍登録士（CTR）です。つまり、資格を持つ臨床医または認定医療情報専門家であり、患者のカルテをレビューし、品質報告、臨床レジストリ、研究、規制遵守のために主要なデータ要素を抽出します。この作業には臨床知識が必要です。手術レジストリを抽象化するには手術解剖学の理解がなければならず、心臓レジストリを抽象化するには血行動態データの解釈ができなければなりません。最大級の臨床抽象化アウトソーシング企業の一つであるAmerican Data Networkは、アブストラクターの中心的なタスクを、「臨床記録、検査結果、画像レポート、投薬」をレビューし、「それらの詳細を構造化フィールドに変換する」ことと説明しています。

この労働力の規模を正確に測定することは困難です。なぜなら、抽象化は標準化された職種名ではなく、品質部門、レジストリチーム、臨床研究ユニットに組み込まれているからです。しかし、経済性は病院レベルで見えます。Massachusetts General Hospitalのレジストリ運営チームによる2018年のプレゼンテーションでは、単一の学術医療センターにおける11の外科専門学会レジストリの人員コストを詳細に分析しました。

これは1つの病院における5つのレジストリであり、年間人員コストは約$1.2百万～$1.7百万に上ります。しかもこれらは、MGHがFTEデータを公表したレジストリにすぎません。ほとんどの学術医療センターは8～15のレジストリに参加しています。Society of Thoracic Surgeons National Databaseだけでも、米国内の成人心臓手術の95%をカバーしており、各CABG症例では、術前リスク因子、術中詳細、退院後30日間の転帰にわたる200以上のデータ要素の抽出が必要です。American College of Cardiologyが運営するNCDRネットワークには、心臓カテーテル検査、ICD植込み、弁膜症手術などをカバーする6つのレジストリに2,400以上の病院が参加しています。

Carta Healthcareが2024年夏に米国の病院の臨床データ抽出担当者を対象に実施した調査では、回答者の50%が作業時間の半分以上を手動データ入力と抽出に費やしていることが判明しました。この調査では、「臨床医はレジストリを品質・プロセス改善に不可欠とみなす一方で、手動データ抽出という負担の大きい作業がこれらの専門家を限界に追い込んでいるという厄介なパラドックス」が指摘されています。自動化について尋ねたところ、45%が自動化ツールにより組織の抽出作業が高速化すると考え、30%がデータ品質の向上に役立つと回答し、20%がコスト削減につながると回答しました。自動化への需要は、理論上は自動化に脅かされる立場にある抽出担当者自身から生まれています。実際には、抽出すべきデータ量は労働力が追いつくよりも速く増加しています。

Redditでは、より率直な意見が見られます。ある臨床研究専門家は次のように投稿しました。「患者データをレジストリに入力するのに何時間も費やしたのに、このレジストリには約100人の患者がいることが判明した（すべて遅延している）。」r/clinicalresearchの別のスレッドでは、単純にこう問いかけています。「データ入力や患者記録からの情報確認に一般的にどのくらいの時間を費やしていますか？」——これは、日常業務に深く組み込まれすぎて誰も基準となる答えを持っていないワークフロー問題を示す質問です。その答えは「1日の大半」だからです。

経済規模は外挿すれば明らかになります。年収75,000ドルの臨床データアブストラクターが、レポートを読み、特定の値を探し、別のシステムに入力するという作業に時間の50%を費やしている場合、事実上の転記に費やされる年間人件費はおよそ37,500ドルに相当します。単一の多レジストリ大学病院のアブストラクション業務従事者（10〜20人のFTE）全体に掛け合わせると、病院あたり年間375,000ドルから750,000ドルになります。NCDR参加病院2,400施設だけを対象にしても、手動によるレジストリアブストラクションの総コストは、訓練を受けた臨床専門家が患者対応業務の代わりにデータ転記を行っている機会費用を考慮する前の段階で、控えめに見積もっても年間数十億ドル規模に上ります。

1人の患者、1つのカルテ、5つのレジストリ — そして5回の別々のデータ入力作業

アブストラクションの経済性は、他の業界には類を見ない臨床レジストリの構造的特徴によって増幅されます。複数のレジストリが同じソース文書からデータを取得しますが、それらは互いにデータを共有しません。

冠動脈バイパス移植術を受ける患者を考えてみましょう。Society of Thoracic Surgeons（STS）成人心臓外科データベースでは、この患者について200以上のデータ要素が必要です：術前リスク因子（糖尿病の状態、駆出率、既往のPCI）、術中詳細（グラフト数、大動脈遮断時間、内胸動脈の使用）、および30日転帰（死亡率、脳卒中、深部胸骨創感染、腎不全、長期人工呼吸）。

同じ患者のカルテには同じ手術記録が含まれています。しかし、この患者は術前カテーテル検査を受けたため、NCDR CathPCIレジストリにもアブストラクトされる可能性があります。そして、そのレジストリには独自のデータ辞書と独自のフィールド定義があります。手術に経カテーテル弁処置が含まれる場合、STS/ACC TVTレジストリが別の変数セットを追加します。患者に手術室への再入室を必要とする合併症があった場合、ACS NSQIP外科品質レジストリが適用される可能性があります。病院が患者の心血管状態についてGet With The Guidelines（GWTG）プログラムに参加している場合、それは独自のアブストラクション要件を持つ5番目のレジストリになります。

5つすべてのレジストリが同じソース文書を読みます。 同じ放射線科レポート。同じ手術記録。同じ退院サマリー。同じ検査値。そして米国のほぼすべての病院で、5つの異なるデータアブストラクションワークフロー（多くの場合、異なるアブストラクターに分割され、時には同じ人物が同じ作業を5回行う）が、重複するデータポイントを手動で抽出して5つの別々のレジストリ提出プラットフォームに入力しています。

MGHのデータはこれを明確に示しています。単一の病院で11の外科レジストリを管理しており、人員要件は0.5 FTE（年間500件以下の小規模レジストリ）から10 FTE（年間750件の移植レジストリ）まで幅広く設定されています。変数の定義は、同じ臨床概念であってもレジストリ間で異なることがよくあります。あるレジストリでは「術後腎不全」をあるクレアチニン閾値で定義し、別のレジストリでは異なる閾値や時間枠で定義しています。症例あたりの抽象化時間は、レジストリの複雑さと患者の臨床経過に応じて、15分から4時間の範囲です。

これはHL7 FHIRで解決できる技術的な相互運用性の問題ではありません。FHIRはシステム間のデータの転送を標準化できます。つまり、システムAがラボ値をシステムBに送信する際に、両システムが送信形式に同意することを保証します。しかしFHIRができないのは、物語的な段落を構造化されたフィールドに変換することです。「1.2 cmの尖った小結節」と記載された放射線科レポートを読み取り、「最大径の腫瘍サイズ」というレジストリフィールドに入力することはできません。散文から構造化データへのこの変換は、依然として人間の読者、または意味的抽出が可能なAIシステムを必要とします。相互運用性の標準は伝送問題を解決しました。構造化問題は解決していません。

皮肉な現実：すでにデジタル化されているのに、構造化されていない

医療ITには、「デジタル化」—紙の記録をコンピュータに入れること—が課題であるという根強い物語があります。この物語は2005年には理にかなっていました。当時、ほとんどの病院は紙のカルテで運営されており、HITECH Actもまだ始まっていませんでした。今日では意味をなしません。米国の病院の90%以上がEHRを使用しています。放射線科部門は10年以上前からフィルムレス化されており、ほとんどの放射線科レポートは完全にデジタルのPACSからEHRへのワークフロー内で生成、署名、配布されています。退院サマリーはタイプ入力され、カセットテープへの口述ではありません。手術記録はテンプレート化されたEHRモジュールに入力されます。最も重要な臨床文書—最も豊かな臨床情報を含む物語—はすでにデジタル化されています。

ボトルネックはデジタル化ではありません。ボトルネックは構造化です。

そして構造化のボトルネックには、具体的で測定可能な形状があります。それは、「この患者はCABGを受けた」—EHRが報告できる構造化された事実—と、STSレジストリがそのCABGがどのように行われたかについて要求する200の個別データポイントとの間のギャップです。その200のデータポイントのすべてが、臨床文書のどこかに存在します。術前の駆出率は心エコーレポートに、グラフト数は手術記録に、術後の人工呼吸期間はICUフローシートに、30日死亡率のステータスは退院後のフォローアップ電話から自由文書のメモとして文書化されています。情報はカルテにあります。ただ、機械が読める形式になっていないだけです。

これは自動化に関する会話全体を再構成します。問題は「臨床文書をデジタル化できるか？」ではありません—その船はすでに出航しました。問題は「すでにデジタル化された臨床物語から、より多くの人を雇って読んでタイプ入力させることなく、構造化データを抽出できるか？」です。

この違いが重要なのは、実際に問題を解決する技術の種類が変わるからです。テンプレートベースのOCR — ページ上のフィールドが「どこにあるか」を読み取るタイプ — は、固定レイアウトの文書、つまり定型フォーム、印刷された表、構造化された請求書のために設計されました。臨床手術記録には固定レイアウトがありません。外科医が書いた、毎回異なる経過をたどる可能性のある処置を記述した、ナラティブ形式の文章です。ナラティブにテンプレートを適用することはできません。理解することしかできないのです。

ここで、テンプレートOCRではなくビジョン言語モデル（VLM）を基盤とする、現在の世代のAI抽出ツールが登場します。VLMは駆出率がページのどこに書かれているかを知る必要はありません。駆出率が何であるか — パーセント値であり、通常「EF 45%」や「LVEF 40〜45%と推定」のように表現されること — を知り、ナラティブ内のどこに現れてもそれを見つけ出す必要があります。これは意味的抽出であり、座標ベースの抽出ではありません。臨床概念が、表現の異なるナラティブ全体にわたって一貫した意味的シグネチャを持つこと、そして言語を理解するよう訓練されたモデルが、循環器科医が「EF 40%」と書こうが「左室収縮機能は中等度低下、推定EF 40〜45%」と書こうが、「駆出率」を見つけ出せるという原理に基づいて機能します。

臨床データの構造化が実際に意味すること

ボトルネックが構造化 — デジタル化ではない — なのであれば、解決策はより優れたスキャナーでも、より速いタイピストでもありません。人間の抽象化担当者が読むのと同じように臨床ナラティブを読むことができるシステム、つまり各文の意味を理解し、どの概念がどのレジストリフィールドに対応するかを特定し、人間が検証できる構造化出力を生成するシステムが必要です。

これは、ほとんどの文書自動化ツールが構築された目的とは根本的に異なるタスクです。請求書や発注書を処理する従来の文書抽出ツールは、フォームのレイアウトを学習することで機能します。「請求書番号」が右上に表示され、「合計」が最終ページの下部に表示されることを記憶します。同じベンダーから新しい請求書が届くと、ツールは同じ座標を読み取り、同じフィールドを抽出します。別のベンダーが異なる形式の請求書を送ってきた場合、ツールは新しいテンプレートを必要とします。

臨床ナラティブは、2つの点でこのアプローチを無効にします。第一に、固定レイアウトがありません — A病院の退院サマリーとB病院の退院サマリーはどちらもナラティブですが、情報の整理方法が異なり、見出しも異なり、臨床概念を表現する語彙も異なります。第二に、そしてより根本的には、データ自体が位置的ではないことです。「クロスクランプ時間47分」を手術記録の特定のボックスで見つけることはありません。外科医が好む散文スタイルで書かれた、他の手術詳細に囲まれた段落に埋め込まれているのを見つけるのです。

意味的抽出は、位置ではなく意味に基づいて機能することでこれを解決します。VLMは文書全体を読み取り、どの臨床概念が存在するかを理解し、各概念に対応する値を抽出します — 概念がページのどこに現れるか、著者がどのような表現を使用したか、文書がタイプされたPDF、スキャンされたレポート、EHRインターフェースのスクリーンショットのいずれであるかに関係なく。抽出ツールは、新しい病院の文書形式ごとに再トレーニングする必要はありません。形式を学習しているのではなく、概念を認識しているからです。

実際のワークフローは「AIがアブストラクターに取って代わる」のではありません。「AIが読み取り工程を担当し、アブストラクターが検証工程を担当する」のです。AIは手術記録、退院サマリー、心エコー報告書、経過観察記録から、STS心臓レジストリ入力の200以上のフィールドを自動入力します。アブストラクター（心臓外科経験のあるRN）は、入力されたフィールドをレビューし、抽出エラーを修正し、曖昧な症例には臨床的判断を適用し、検証済みエントリを提出します。アブストラクターの時間は、データの発見（Carta調査によると勤務日の50%以上を占める、EHR文書80ページのスクロール作業）から、データの検証（臨床的専門知識を要し自動化できない部分）へとシフトします。

現在、CABG患者のアブストラクションに45〜90分かかっており、複数のEHRモジュールにわたる術前・術中・術後の文書を網羅する必要がある場合、初期データ取得を処理するセマンティック抽出ツールにより、アブストラクターの症例あたりの時間を半分以上削減できます。計算は単純です。時給40ドルのRNアブストラクターが年間1,300件のCABG症例を処理し（MGHがSTS-Cardiacレジストリで報告した件数）、AI支援抽出で1症例あたり30分節約できれば、年間650時間のRN労働が回収されます。これは約26,000ドルの人件費削減に相当し、転記作業から検証・品質改善業務へと振り向けられます。5つのレジストリ、2,400の病院にわたって見れば、その合計は誤差の範囲ではありません。

よくある質問

EHRはなぜデフォルトで臨床文書を構造化しないのですか？

構造化データ入力（ドロップダウン、チェックボックス、制約付き語彙）は、臨床医の思考・コミュニケーション方法と根本的に相容れないからです。チェックボックスは「胸痛：あり」を捕捉できますが、「患者は約2週間前から増悪傾向にある、労作で悪化し安静で軽減する、左肩に放散する断続的な胸骨下圧迫感を訴える」という表現は捕捉できません。チェックボックスは請求コードを捕捉します。ナラティブは臨床的推論を捕捉します。臨床医に構造化フィールドのみでの記録を強制すれば、機械は読めるが他の臨床医には使えないデータが生まれます。このトレードオフは現実のものであり、医療界は—正しく—機械に優しい文書よりも臨床的に有用な文書を選択してきました。

一般的な病院は臨床レジストリにいくつ参加していますか？

地域病院では3〜5件のレジストリに参加する場合があります。通常、脳卒中（GWTG）、心臓カテーテル治療（NCDR CathPCI）、外科治療の質（ACS NSQIP）を対象としています。大規模な学術医療センターでは通常10〜15件のレジストリに参加しており、心臓外科（STS）、外傷（TQIP）、移植（SRTR）、腫瘍（NCDB）、および複数の専門分野のレジストリにわたります。MGHの公開データでは11件のレジストリをカバーしており、多くの学術センターではこれを上回る数となっています。各レジストリは抽象化FTEを追加し、レジストリ間でデータを共有しないため、FTEはさらに増加します。

どのような種類の臨床文書が手動での抽象化を必要としますか？

最も抽象化作業を生み出す文書は、放射線科レポート、退院サマリー、手術記録、経過記録、病理レポートです。これらは、臨床的に最も豊富な情報が含まれる、記述中心の文書です。検査値、投薬指示、バイタルサインは構造化データであり、EHRから直接エクスポートできます。手作業は、構造化フィールドが捉えるように設計されていない臨床的推論とニュアンスを含む自由記述文書に圧倒的に集中しています。

AIはレジストリ利用に十分な精度で放射線科レポートを実際に読むことができますか？

視覚言語モデルは、放射線科の記述から腫瘍の寸法、左右性、画像診断モダリティ、フォローアップ推奨などの個別のデータポイントを抽出でき、抽象化担当者が検証するための一次ツールとして活用できる精度を備えています。ただし、放射線科レポートには曖昧さ（断定を避けた所見、「約」と限定された測定値など）が含まれており、人間の解釈が必要なため、臨床レビューの代替にはなりません。適切なアーキテクチャはAI支援による抽象化です。モデルがフィールドに入力し、抽象化担当者が検証します。これは、Carta調査で抽象化担当者が求めたモデルと同じものです。臨床的判断を置き換えることなく、手動での検索時間を削減するツールです。

臨床文書におけるデジタル化と構造化の違いとは？

デジタル化とは、文書を物理的な形態から電子形態に変換することです。紙のカルテをスキャンする、EHRからPDFを生成する、PACSに画像を保存するなどが該当します。文書はファイルになります。構造化とは、その文書の内容を、叙述的な散文から個別の検索可能なデータフィールドに変換することです。手術記録の段落から「クロスクランプ時間：47分」を抽出し、「cross_clamp_time_minutes」というデータベースフィールドに値「47」を入力することです。デジタル化は人間が読めるファイルを作り出します。構造化は機械が使用できるデータを作り出します。臨床文書における問題は、デジタル化は進んだものの、構造化がそれに続かなかったことです。そのため、病院は今でも人手による作業を雇用しているのです。