病院・診療所に紙で届く他院・検査会社の検査結果票を読み取り、項目名・値・単位・基準値を電子カルテへ取り込む形にそろえて、読み取りに自信のない値を人の確認に回す
紹介状に添付された他院の検査結果票や、検査会社から紙・FAXで届く結果票を読み取ります。項目名・値・単位・基準値を自院の検査項目にそろえて電子カルテへ取り込む形にし、読み取りに自信のない値だけを人の確認に回します。
- 生成AI
- ChatGPT/Claude/Gemini
- AIサービス
- Azure AI/Google Document AI
- 連携・自動化
- Python
- 対象業界
- 介護/医療
- 対象部門
- 総務
- 対象業務
- データ入力・転記/内容確認・チェック
- 主な課題
- 人手が足りない/入力作業が多い/確認ミスが多い
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/品質標準化/工数削減
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 紹介状と添付の結果票を受け取り、スキャンして文書管理システムに患者を指定して保存する
- 医師から依頼のあった結果票について、患者の氏名・生年月日と結果票の記載が一致するかを確かめる
- 結果票の項目名を読み、自院の検査項目のどれに当たるかを決める(「GOT」と「AST」、「Hb」と「血色素量」など)
- 値・単位・基準値を1項目ずつ電子カルテの外部検査の画面に入力する
- 単位が自院と違う項目は、換算するか、入力を見送る
- 検体の採取日を入力し、入力の誤りがないかを読み合わせる
- 人紹介状と添付の結果票をスキャンし、文書管理システムに患者を指定して保存する(今までどおり)
- 自動30分おきに新しく保存された結果票を取り、患者の番号と組にする
- 自動OCRが全ページの文字、文字ごとの信頼度、画像の品質、表を返す
- 自動生成AIが結果票の氏名・生年月日・採取日、項目ごとの項目名・値・単位・基準値・印を書かれたとおり取り出し、自院の項目の候補を選ぶ
- 自動スクリプトが患者の氏名・生年月日を電子カルテと照らし、単位を換算し、値の数字の信頼度を判定する
- 自動項目ごとに `ok` / `low_confidence` / `unit_unknown` / `unmapped` を付け、結果票ごとに `ready` / `needs_review` / `stop` を付ける
- 人担当者が `needs_review` の結果票で、印の付いた値だけを原本の画像と見比べて直す
- 人確認の済んだ結果を電子カルテに「外部検査」として取り込む
- 人医師が診療のときに、取り込まれた値と原本の画像を必要に応じて見る
各工程の詳しい説明を読む
- 紹介状と添付の結果票を受け取り、スキャンして文書管理システムに患者を指定して保存する
- 医師から依頼のあった結果票について、患者の氏名・生年月日と結果票の記載が一致するかを確かめる
- 結果票の項目名を読み、自院の検査項目のどれに当たるかを決める(「GOT」と「AST」、「Hb」と「血色素量」など)
- 値・単位・基準値を1項目ずつ電子カルテの外部検査の画面に入力する
- 単位が自院と違う項目は、換算するか、入力を見送る
- 検体の採取日を入力し、入力の誤りがないかを読み合わせる
(a)1項目ずつの手入力。 1枚に20項目前後あり、4番目の入力が時間の大半を占めます。 入力する人が限られ、依頼のあった患者の分しか追いつきません。
(b)小数点と桁の写し間違い。 「7.8」を「78」、「0.45」を「0.54」と写す誤りは、読み合わせをしても見落とすことがあります。 FAXで潰れた小数点は、目で読んでも判断がつきません。
(c)項目名と単位がそろわない。 同じ検査でも、結果票によって「γ-GTP」「GGT」「γ-GT」と書き方が違い、白血球数の単位が 10³/μL か /μL かも違います。 5番目で入力を見送った項目は、経過に穴が空きます。
(d)画像のまま残る。 入力しなかった結果票は画像で残り、次に同じ患者が来たときに、また画像を開いて読むことになります。
- 【人】 紹介状と添付の結果票をスキャンし、文書管理システムに患者を指定して保存する(今までどおり)
- 【自動】 30分おきに新しく保存された結果票を取り、患者の番号と組にする
- 【自動】 OCRが全ページの文字、文字ごとの信頼度、画像の品質、表を返す
- 【自動】 生成AIが結果票の氏名・生年月日・採取日、項目ごとの項目名・値・単位・基準値・印を書かれたとおり取り出し、自院の項目の候補を選ぶ
- 【自動】 スクリプトが患者の氏名・生年月日を電子カルテと照らし、単位を換算し、値の数字の信頼度を判定する
- 【自動】 項目ごとに
ok/low_confidence/unit_unknown/unmappedを付け、結果票ごとにready/needs_review/stopを付ける - 【人】 担当者が
needs_reviewの結果票で、印の付いた値だけを原本の画像と見比べて直す - 【人】 確認の済んだ結果を電子カルテに「外部検査」として取り込む
- 【人】 医師が診療のときに、取り込まれた値と原本の画像を必要に応じて見る
7番目で人が見るのは、印の付いた値と、その文字の部分の画像だけです。 1枚20項目をすべて読み直すのではありません。ok の値は、項目の対応付けを一覧で流し見て取り込みます。
5番目で患者が一致しなかった結果票は、stop として何もせずに止めます。 別の患者の結果を取り込む誤りは、どの写し間違いよりも重いからです。
02今回想定するシステム構成
検査結果票(紹介状の添付・FAX・検査会社の報告書) │ スキャンして文書管理システムに患者を指定して保存 ▼【トリガー】30分おきの定時実行 Python ── 新しい結果票を患者の番号と組にする ▼ Google Document AI(Enterprise Document OCR) │ 全ページの文字、文字ごとの信頼度、画像の品質スコア ▼ Google Document AI(Form Parser) │ 結果の表、氏名・生年月日・採取日の欄 ▼ Claude API ── 項目名・値・単位・基準値・印の取り出し、自院の項目の候補(構造化出力) ▼ Python ── 患者の照合、値の文字の信頼度の判定、単位の換算、基準値の照合 ▼ 判定(ready / needs_review / stop) ▼ 【人が印の付いた値だけを確認】 ▼ 電子カルテへ「外部検査」として取り込む
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| OCR | Google Document AI(Enterprise Document OCR、Form Parser) | Azure AI Document Intelligence |
| 生成AI | Claude API(項目名・値・単位・基準値の取り出し、自院の項目の候補の選択) | Gemini API、OpenAI API |
| 差異計算 | Python(値の文字ごとの信頼度の判定、単位の換算、患者の照合) | 電子カルテの取り込み時の確認の規則 |
| 連携 | Python(文書管理システムからの取得、取り込み用のファイルの書き出し) | 電子カルテの製品が用意する取り込みの仕組み |
| 保管 | 文書管理システム(結果票の原本のスキャン) | 電子カルテの画像の保管 |
電子カルテと文書管理システムは、今のものを使います。 電子カルテへの取り込みの形式は製品ごとに違うため、この部分は利用している電子カルテに合わせた個別の対応になります。 外部の検査結果を取り込む機能があるかを、最初に販売元に確かめてください。
OCRに Google Document AI を選ぶのは、日本語で使える2つのプロセッサがそろうからです。 Enterprise Document OCR と Form Parser は、どちらも一般提供(GA)で、対応言語に日本語が含まれます。
Enterprise Document OCR を使う理由は、文字ごとの信頼度です。 enableSymbol を有効にすると、1文字ずつの文字と信頼度が pages[].symbols[] に返ります。 値の欄の「7」「.」「8」のそれぞれに信頼度が付くので、潰れた小数点だけが低い、という状態を見分けられます。 画像の品質スコアも0から1で返り、0.5を下回るとぼけや薄さなど8種類の不具合が返ります。
Form Parser は、結果の表と、氏名・生年月日・採取日の欄を取り出します。 結果票の表は、項目名・結果・単位・基準値・印の列が並ぶ単純な表のことが多く、Form Parser の対象である、行や列をまたぐセルの無い表に当たります。2列に折り返した結果票や、健診の成績表のように区分の見出しが結合されたものは、OCRの全文を生成AIに渡します。
生成AIに Claude API を選ぶのは、構造化出力が一般提供になっているからです。 output_config.format に type: "json_schema" とスキーマを渡すと、スキーマどおりのJSONで返ります。
03どうやって実装するのか
処理の起点を決める
30分おきの定時実行にします。 紹介状は外来の受付と郵送でまとまって届き、スキャンは医事課の手の空いた時間に行われます。スキャンの直後に即時で動かす必要はなく、その日の外来に間に合えば足ります。
対象は、文書管理システムで文書の種類が「紹介状の添付」「外部検査結果」とされ、患者が指定されているものだけです。 患者が指定されていない文書は処理しません。患者の取り違えを、処理の入口で防ぐためです。
処理済みの印は、取り込み用のファイルまで作れたときだけ付けます。途中で止まったものは、次の回にやり直します。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 結果票のファイル | スキャンのPDF・FAXの画像、患者の番号、文書の種類、保存の日時 | 文書管理システム |
| 患者の情報 | 氏名(漢字・カナ)、生年月日、性別 | 電子カルテ |
| 読み取り結果 | 全ページの文字、文字ごとの信頼度、品質スコア、表、欄の名前と値 | Google Document AI |
| 自院の検査項目の表 | 自院の項目のコード、名前、別名の一覧(AST と GOT など)、自院の単位、換算の規則 | 自院の臨床検査の部門が作る表 |
| 信頼度の基準 | 値の数字の文字で、人に回す信頼度の境目 | 自院で決める値 |
質を決めるのは、自院の検査項目の表です。 結果票の項目名を自院のどの項目に対応付けるかは、別名の一覧で決まります。最初は、電子カルテ情報共有サービスで共有の対象とされる検査の43項目(総蛋白、アルブミン、AST、ALT、γ-GTP、クレアチニン、HbA1c、血算など)から作ると、外来でよく見る項目がほぼ入ります。
換算の規則には、換算してよい組み合わせだけを書きます。 10³/μL と /μL のように桁だけが違うものは換算の規則にできますが、検査の方法によって値の意味が変わるものは、換算せずに人に回します。 どれを換算してよいかは、臨床検査の部門が決めます。
データの取得方法を決める
Enterprise Document OCR には、次の3つを指定して送ります。
| 指定 | 設定 | 理由 |
|---|---|---|
enableSymbol | true | 1文字ずつの文字と信頼度を pages[].symbols[] に受け取る |
enableImageQualityScores | true | ページごとの品質スコアと不具合を受け取る |
hints.languageHints | ["ja"] | 推定させず、日本語として読ませる |
Form Parser からは、次の2つを取ります。
| 取るもの | 場所 | 使い方 |
|---|---|---|
| 表 | pages[].tables の headerRows と bodyRows、セルの layout | 項目名・結果・単位・基準値・印の行 |
| 欄の名前と値 | pages[].formFields の fieldName と fieldValue、confidence | 氏名、生年月日、採取日、検査の実施機関 |
値の文字の信頼度は、表のセルの位置と文字の位置を重ねて求めます。 セルの layout が指す本文の範囲(textAnchor の startIndex と endIndex)に入る文字を symbols から集め、その中で最も低い信頼度を、その値の信頼度にします。 平均にすると、潰れた小数点1つが他の数字に埋もれます。
FAXの結果票は、原本が後から届くかを先に確かめます。 患者の持参で原本が来るなら、FAXの画像で low_confidence が多いときは、原本のスキャンを待つほうが確認の手間が少なくなります。
AIへ渡す前に整形する
- 形式をそろえる … Document AI が受け付ける画像は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。スキャンは最低200dpi、300dpi以上が一般に最も良い結果になるとされています
- むやみに圧縮しない … 非可逆の形式で小さくすると、読み取りの精度が落ちるとされています。小数点が消えるので、スキャンの設定で圧縮を強くしません
- 紹介状の本文と結果票を分ける … 1つのPDFに紹介状の本文と結果票が入っています。表が返ったページを結果票として扱い、本文のページは後段に送りません
- 品質の足りないページを分ける …
qualityScoreが0.5を下回ったページは、needs_reviewの結果票にし、そのページの値はすべてlow_confidenceにします - 同じ結果票の重複を落とす … FAXで届いた結果票と、後から届いた原本のスキャンが重なります。採取日と実施機関が同じものは、原本のほうを残します
3番目で紹介状の本文を送らないのは、この構成が診療の内容を読まないためです。 本文には病歴や紹介の目的が書かれていますが、検査値の取り込みには要りません。 生成AIに渡す範囲を、結果票のページに限ります。
AIに処理させる
生成AIにさせるのは、結果票の項目の取り出しと、自院の項目の候補の選択だけです。
| 取り出すもの | 取り出し方 | 取り出せないとき |
|---|---|---|
| 患者の氏名と生年月日 | 書かれたとおり | missing |
| 採取日と実施機関 | 採取日・検体採取日の欄の日付と、検査の実施機関名 | 日付が複数あれば ambiguous |
| 項目名 | 書かれたとおり。略し方を直さない | 読めなければ unreadable |
| 値 | 書かれた文字列のとおり。数値も定性(−、±、+)も | 空欄は空 |
| 単位と基準値 | 書かれた文字列のとおり | 空欄は空 |
| 高値・低値の印 | H・L・*などの印を書かれたとおり | 印が無ければ空 |
| 自院の項目の候補 | 自院の項目の表の別名の一覧から1つ。無ければ unmapped | unmapped |
最後の行だけが、選ぶ作業です。 選べる値は自院の項目の表に限り、一覧に無い項目名は unmapped にさせます。 名前が似ているだけで近い項目に寄せると、別の検査の値が経過のグラフに混ざります。
| させないこと | 理由 |
|---|---|
| 値の書き換え・丸め | 書かれた文字列が記録。小数点の位置を直さない |
| 単位の換算 | 換算の規則はスクリプト。規則に無い単位は人へ |
| 基準値との比較・異常の判定 | 医師が判断する。印は書かれたものだけ |
| 読めない数字の推測 | 信頼度の低い文字を補わない |
| 前回の値との比較 | 診療の判断 |
| 紹介状の本文の要約 | この構成の対象ではない |
いちばん起きやすい失敗は、表の1行目です。 生成AIは、FAXで潰れて「7 8」に見える値を、基準値の範囲から考えて「7.8」と書きます。たまたま正しくても、それは結果票の値ではなく推測です。 値は書かれた文字列のまま返させ、小数点が確かかどうかは、スクリプトが文字の信頼度で決めます。
指示内容を固定する
あなたは病院の医事課で、他院や検査会社から届いた検査結果票を
電子カルテに取り込む準備をする担当です。
渡された読み取り結果だけを見て、項目を取り出してください。
判断や計算はしないでください。
【取り出す項目】
結果票 …… 患者の氏名、生年月日、採取日、検査の実施機関
項目 ……… 行ごとに、項目名、値、単位、基準値、高値・低値の印、
自院の項目の候補、そのページの番号
【自院の項目の候補の選び方】
次の一覧の別名と照らし、当たるものを1つ選んでください。
一覧に無い項目名は unmapped にしてください。
{local_test_master}
【厳守事項】
- 値は、書かれた文字列をそのまま写してください。
小数点を足したり動かしたり、桁を丸めたりしないでください。
- 数字が読みにくい場合も、基準値や他の項目から推測して
値を決めないでください。読み取り結果のとおりに写してください。
- 単位を換算しないでください。単位は書かれた文字列のままにしてください。
- 高値・低値の印は、結果票に書かれたものだけを写してください。
基準値と比べて印を付けないでください。
- 定性の結果(−、±、+、陰性、陽性)は、書かれたとおりに写してください。
- 異常かどうか、前回と比べてどうか、診療上の意味を書かないでください。
- 日付は西暦(YYYY-MM-DD)に直し、元の表記を evidence に残してください。
- evidence には、その行の根拠にした文字列をそのまま写してください。
【読み取り結果(結果票のページのみ、品質不足のページには印)】{pages}
「基準値や他の項目から推測しない」が、この指示の中心です。 生成AIは基準値の列を見て、ありえる値に寄せようとします。推測をはさむと、文字の信頼度で確認を絞るという設計そのものが成り立ちません。
「印を付けない」も外せません。 何も言わないと、基準値と比べて H や L を足してきます。結果票を出した検査機関の基準値と自院の基準値は違うことがあり、足した印は誰の判定でもない印になります。
出力形式を固定する
Claude API の構造化出力で、次の形のJSONを受け取ります。 要求の output_config.format に、type を json_schema として、スキーマを渡します。
{
"doc_id": "",
"patient": { "name": "", "birth_date": "", "status": "ok | missing | unreadable" },
"collected_on": "",
"facility": "",
"results": [
{ "page": 1, "name_written": "", "value_written": "", "unit_written": "",
"ref_range_written": "", "flag_written": "",
"local_code": "", "mapping": "mapped | unmapped",
"status": "ok | unreadable", "evidence": "" }
]
}
スキーマでは mapping と status を enum で固定し、local_code は自院の項目のコードの一覧を enum にします。 値は数値ではなく文字列で受け取ります。 数値の型にすると、「7.8」と「7.80」の違いや、定性の「(+)」が失われるためです。Claude の構造化出力は minimum のような数値の制約をサポートしないので、値の範囲の確かめはスクリプトで行います。
受け取ったあと、スクリプトが判定を足します。
{
"doc_id": "",
"patient_match": "matched | kana_only | mismatch",
"items": [
{ "local_code": "", "value": "", "value_min_symbol_conf": 0,
"unit_local": "", "converted": false,
"item_status": "ok | low_confidence | unit_unknown | unmapped" }
],
"verdict": "ready | needs_review | stop"
}
verdict | 条件 |
|---|---|
stop | patient_match が mismatch、採取日が無い |
needs_review | low_confidence、unit_unknown、unmapped の項目が1つでもある、品質不足のページがある |
ready | 上のどれにも当たらない |
item_status の low_confidence は、値の文字の最も低い信頼度が自院の基準を下回るものです。 基準の値は、最初の1か月の確認の結果を見て決めます。最初は高めに置き、人が直さなかった値の信頼度を見て下げていきます。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 文書管理システム | 新しい文書の取得 | 患者と文書の種類の指定された結果票を受け取る |
| Google Document AI | API呼び出し(同期の処理) | Enterprise Document OCR、Form Parser の順に送る |
| Claude API | API呼び出し | 項目の取り出しと、自院の項目の候補(構造化出力) |
| 電子カルテ | 患者の情報の読み取りと、取り込み用のファイルの受け渡し | 確認の済んだ結果を「外部検査」として取り込む |
電子カルテには、自院の検査とは別の「外部検査」として取り込みます。 実施機関と採取日を必ず付け、自院で測った値と混ざらないようにします。 取り込みの操作は担当者が行います。
取り込んだ値には、原本の画像への参照を付けます。 医師が値に疑問を持ったとき、1回の操作で結果票の該当のページを開けるようにします。
人が確認する
stopを先に見る … 患者が一致しないもの。スキャンのときの患者の指定を確かめ直しますlow_confidenceの値を見る … 値の文字の部分の画像を拡大して並べ、小数点と桁を確かめて直しますunit_unknownとunmappedを見る … 自院の項目に当てはめるか、取り込まずに画像のまま残すかを決めます。表に足すかは臨床検査の部門と週に1回まとめて決めます- 取り込む … 直した値は記録します
2番目で見るのは、値の文字の部分の画像だけです。 結果票の全体を開くのではなく、OCRが返した文字の位置で切り出した小さな画像を並べます。 1枚に20項目あっても、印の付く値は数個です。
ready の結果票は、項目の対応付けの一覧を流し見て取り込みます。 全項目を画像と読み合わせる運用にすると、第10章の3分には収まりません。
例外に対処する
| 起きること | 対応 |
|---|---|
| 患者が一致しない | stop。何も取り込まず、スキャンの指定を確かめる |
| 品質スコアが0.5を下回る | そのページの値をすべて low_confidence に。原本が届くなら待つ |
| 結果の表が取れない | 2列の折り返しや結合した見出し。OCRの全文を生成AIに渡す |
| 単位が換算の規則に無い | unit_unknown。換算せずに人へ |
| 項目名が自院の表に無い | unmapped。取り込むかは人が決める |
| 採取日が無い、または複数ある | 採取日が無ければ stop、複数あれば人へ |
| 同じ結果票がFAXと原本で届く | 原本のほうを残し、FAXの取り込みは取り消す |
| 結果が「中間」「未報告」のまま届く | 検査会社の途中の報告。取り込まずに人へ回し、確定の報告を待つ |
| 1枚に複数の採取日の結果が並ぶ | 前回値の列がある様式。採取日ごとに分けて取り出し、列の見出しを evidence に残す |
| Document AI や Claude API が応答しない | 処理済みの印を付けず、次の回にやり直す |
運用の最初に多いのは、5行目です。 結果票の項目名の書き方は紹介元ごとに癖があり、最初の1〜2か月は unmapped が多く出ます。 別名を表に足すほど減ります。
下から2行目の様式は、取り違えの原因になります。 前回値の列を今回の値として取り込むと、採取日の違う値が同じ日の結果として並びます。 列の見出しの日付を必ず値と組にしてください。
記録を残す
- 結果票の原本のスキャンと、患者の番号、文書の種類、保存の日時
- Document AI が返した結果の全文(文字ごとの信頼度を含む)と、Claude API に渡した全文と返ったJSON
- スクリプトが足した判定と、そのとき使った自院の検査項目の表、換算の規則、信頼度の基準の版
- 担当者が直した値と、直す前と後の値、その値の文字の信頼度
- 取り込んだ日時と、取り込んだ担当者
4つ目の記録で、信頼度の基準を見直します。 担当者が直さなかった値の信頼度が基準の近くに多く集まっていれば、基準を下げても誤りは増えません。 逆に、基準より高い信頼度の値を直していれば、基準を上げます。
04実装レベルの3段階
最小構成は、指示の書き方と、確認を絞れるかを確かめる段階です。 1枚ずつ貼り付けるので、月900枚には使えません。 半自動化で、1枚8分が5分程度になります。 読み取りと対応付けは自動になりますが、電子カルテへの入力が手作業で残ります。本格構成で3分になり、この段階が本記事の想定です。 取り込みの部分は電子カルテの製品に合わせた対応が要るため、ここが一番時間のかかる段階です。
05工数削減シミュレーション
導入後 900件 × 3分 ÷ 60 = 45 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 紹介状に添付された他院の検査結果票や、外部の検査会社から紙・FAXで届く結果票が毎月数百枚あり、医事課や医師事務作業補助者が電子カルテに手で入力するか、スキャンした画像を貼るだけで数値として残せていない病院・診療所。介護施設で、協力医療機関から届く検査結果を記録に写している場合にも当てはまる。
- 外部の検査結果の大半が検査会社とのデータ連携や電子的な診療情報提供書で届き、数値として取り込めている場合。月に届く結果票が数十枚の場合。異常値かどうか、どの検査を追加するかといった医学的な判断そのものを自動化したい場合、この構成では代替できません。
07最小構成で試す方法
- 先月スキャンした結果票から30枚を選ぶ(FAXのもの、2列に折り返したもの、単位が自院と違うものを数枚ずつ入れる)
- 氏名と生年月日の欄を紙で隠してからスキャンし直す
- 手元のAIサービスの画面に1枚ずつ貼り付け、「この検査結果票の項目名・値・単位・基準値・印を表にしてください。値は書かれたとおりに写し、推測や換算をしないでください。読みにくい数字には印を付けてください」と指示する
- 出てきた表を、原本と1項目ずつ読み合わせる
- 写し間違いがあった値が、AIが「読みにくい」と印を付けた値に含まれていたかを見る
5番目が、この構成の成り立つかどうかの分かれ目です。 写し間違いの多くが印の付いた値に入っていれば、文字の信頼度で確認を絞る設計が効きます。
| 出てきた内容 | 判断 |
|---|---|
| 写し間違いが印の付いた値に入っていた | OCRの文字の信頼度を使う構成に進む |
| 小数点を推測で補った | 指示の書き方で直る。構成は有効 |
| 基準値と比べて H・L を足した | 指示に「印を付けない」を足す |
| FAXの結果票で読めない値が多い | 原本を待つ運用が先。 AIの問題ではない |
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 生成AIが潰れた小数点を補う | 推測を禁じ、文字の信頼度で確かめる |
| 値の信頼度を平均で出す | 最も低い文字の信頼度を使う |
| 基準値と比べて H・L を足す | 書かれた印だけを写させる |
| 単位を勝手に換算する | 換算は規則に書いた組み合わせだけ。ほかは人へ |
| 名前の似た項目に寄せる | 自院の表の一覧から選ばせ、無ければ unmapped |
| 値を数値の型で受け取る | 文字列で受け取る。定性の結果と桁が失われる |
| 患者の指定の誤りに気づかない | 氏名と生年月日を照らし、合わなければ止める |
| 自院の値と混ざる | 「外部検査」として、実施機関と採取日を付けて取り込む |
| FAXと原本で二重に取り込む | 採取日と実施機関で重複を見つけ、原本を残す |
上の2行が、この構成の失敗のほとんどです。 どちらも、潰れた小数点という小さな誤りを、推測や平均で見えなくしてしまうことから起きます。 確認を絞る設計は、最も弱い1文字を見逃さないことで成り立ちます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 患者の氏名、生年月日、検査の結果と実施機関です。検査の結果は、患者の健康状態そのものを表す情報です。
- 生成AIに渡す範囲を結果票に限る … 紹介状の本文は後段に送りません。氏名と生年月日は照合のために取り出しますが、照合はスクリプトが電子カルテのデータと行います
- 処理する地域と契約を先に決める … Document AI は
us、eu、asia-southeast1などで処理できます。医療情報を外部のサービスで処理してよいか、どの地域で処理するかを、自院の医療情報の安全管理の規程と照らして決めます - この構成は医学的な判断をしない … 異常かどうか、前回と比べてどうかは医師が判断します。印は結果票に書かれたものだけです
- 患者が一致しないものは止める … 別の患者の結果を取り込む誤りは、写し間違いより重い誤りです
- 電子的な共有への移行を見ておく … 厚生労働省の電子カルテ情報共有サービスは、令和8年度冬頃からの運用開始を目標とされ、検査の43項目の結果を共有の対象にしています。紹介元が対応すれば、紙の結果票は減っていきます。 この構成は、それまでの間と、対応しない紹介元の分を埋めるものです
誤りが起きた場合のリスクは、写し間違いの値が数値として電子カルテに載ることと、別の患者に取り込むことの2つです。 前者は推測と平均で起き、後者は患者の照合を省くと起きます。数値として載る分、画像のままより誤りが目立ちにくくなります。 原本への参照を必ず付けてください。
10まず何から始めるか
1週目:電子カルテの取り込みの機能を確かめる
電子カルテの販売元に、外部の検査結果を取り込む機能があるか、どの形式で受け付けるかを確かめます。無ければ、本格構成の取り込みは見送り、半自動化の一覧で止める前提で進めます。
2週目:30枚で試す
先月の結果票から30枚を選び、氏名を隠してから手元のAIサービスで項目の表を作らせます。写し間違いが「読みにくい」と印の付いた値に含まれるかを最優先で見ます。
3週目:自院の検査項目の表を作る
臨床検査の部門と、電子カルテ情報共有サービスの43項目を土台に、自院の項目のコード、別名、単位、換算してよい組み合わせを表にします。換算しない項目も、表に「換算しない」と書きます。
4週目:文書管理システムから一覧までをつなぐ
OCR、取り出し、自院の項目への対応付け、文字の信頼度の印を一覧に書き出すところまで作ります。この時点では取り込まず、一覧を医師事務作業補助者が見ます。
2か月目: 患者の照合と単位の換算を足し、unmapped の項目名を毎週表に足します。担当者が直した値から信頼度の基準を見直します。3か月目以降: 電子カルテへの取り込みを足し、1枚8分が何分になったかを実測します。画像のまま残る結果票がほぼ無くなった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| Enterprise Document OCR と Form Parser が一般提供(GA)で、対応言語に日本語が含まれること。同期の処理のページの上限が15であること | Google Cloud: Processor list | 2026-10-06 |
enableSymbol で1文字ずつの文字が信頼度とともに pages[].symbols[] に返ること。画像の品質スコアが enableImageQualityScores で有効になり、0から1で返り、0.5を下回ると8種類の不具合が検出されること。languageHints を指定できること | Google Cloud: Enterprise Document OCR | 2026-10-06 |
| Form Parser がキーと値のペア、表、選択マークを取り出すこと。表は行や列をまたぐセルの無い単純な表が対象であること | Google Cloud: Form Parser | 2026-10-06 |
欄が formFields の fieldName と fieldValue で返り、confidence が付くこと。表が headerRows と bodyRows で返ること。各要素の layout の textAnchor が本文の startIndex と endIndex で位置を指すこと | Google Cloud: Handle the processing response | 2026-10-06 |
| 対応する画像の形式が PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などであること。非可逆の形式でファイルを小さくすると結果の精度が落ちうること。スキャンは最低200dpi、300dpi以上が一般に最も良い結果になるとされていること | Google Cloud: Supported files | 2026-10-06 |
構造化出力が一般提供で、output_config.format に type: "json_schema" とスキーマを指定して使うこと。enum をサポートし、minimum などの数値の制約をサポートしないこと | Claude Docs: Structured outputs | 2026-10-06 |
電子カルテ情報共有サービスで、救急と生活習慣病に関する43項目の検査結果を登録・閲覧でき、検体採取日時・基準値・評価(高値・低値)・進捗ステータスが補足情報として閲覧できること。画面の例で同じ項目が pg/mL と ng/L、10⁶/μL と 10⁴/μL で記録されていること。令和8年度冬頃からの運用開始を目標としていること | 厚生労働省: 電子カルテ情報共有サービス 概要案内 2.1.0版(令和8年7月) | 2026-10-06 |
検査の項目の対応付け、単位の換算、取り込んだ値の扱いは、自院の臨床検査の部門と医療情報の安全管理の規程、医師の判断に従ってください。 本記事は Google Cloud、Claude Docs、厚生労働省の資料で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0453)についてのご相談はこちらから。
