カルテ番号を連携の手がかりにする｜患者情報を正しく結び付ける設計

前回は、AXの最初の対象をバックオフィスの一業務に絞る考え方を紹介しました。そこから予約画面、見積書、紹介状などをつなぐとき、先に決めておきたいのが「どの患者さんの情報か」を確かめる方法です。転記を減らせても、別の患者さんの情報と結び付けば、確認の負担と危険が増えてしまいます。

第4回は、カルテ番号を連携の手がかりにする設計を考えます。以下はすべて架空データによる設計例です。金川歯科医院の全システムで一元管理や自動照合を実現したという報告ではありません。

「番号が同じ」だけで、同じ患者と決めない

カルテ側の「00123」と予約アプリ側の「00123」が、同じ人を指すとは限りません。別のシステムや拠点で、それぞれ番号を発行している場合があるからです。番号の値だけでなく、どこが、どの仕組みで発行した番号かを一緒に扱います。

医療情報の交換規格HL7 FHIRのIdentifierにも、番号の適用範囲を表すsystemと、その範囲内の値を表すvalueという考え方があります。ここではその区別を設計の参考にします。利用中のアプリがFHIRに対応している、あるいはこの構成で連携できると確認したものではありません。

一元管理は、既存番号の付け直しから始めない

すべてのアプリを同じ番号に変える前に、院内で基準にする識別子と、各システムの番号との対応を整理する方法があります。例えば、本人との対応を確認できた架空の1人について、次のように記録する設計です。

院内の基準ID：P-DEMO-01
拠点A・カルテシステムの番号：00123
拠点A・予約アプリの番号：R-00456
照合状態：確認済み／確認した担当者と日時を記録

これは画面に表示する一覧の例ではなく、管理する関係の例です。対応が分からない記録は空欄や「確認待ち」にし、番号を推測して埋めません。氏名が同じという理由だけで自動統合することも避けます。本人確認や照合に使う項目、確認する担当者は、医院の手順と各システムの仕様に合わせて決める必要があります。

00123は、計算する数ではなく文字列として扱う

カルテ番号の「00123」は、数値に変換すると先頭のゼロが失われることがあります。入力欄だけでなく、受け渡し、保存、再表示まで、識別子を文字列として保つ設計にします。MDNも、数字だけで構成されていても計算用ではない識別子に、数値入力欄を使うことを勧めていません。

ただし「00123」と「123」を必ず別人とするという意味でもありません。同じ番号を表すかどうかは、番号を発行する側の仕様に依存します。桁数や文字の意味を確かめずにゼロを削ったり、逆に補ったりせず、元の値を残します。自動変換が必要なら、その規則と確認方法を先に決めます。

カルテ番号への置き換えは、匿名化ではない

氏名をカルテ番号に置き換えても、対応表などから本人を識別できるなら、匿名になったとは扱えません。個人情報保護委員会のFAQでは、匿名加工情報について、特定の個人を識別できず、元の個人情報を復元できないようにした情報と説明しています。法令上の「仮名加工情報」「匿名加工情報」の要件を、番号への置き換えだけで満たすとは考えないことが大切です。

対応表を見る人を必要な担当者に限り、連携先に渡す項目も業務に必要な範囲に絞る、という管理まで含めて設計します。AIや外部サービスに渡すときも「名前がないから大丈夫」と判断せず、利用目的や契約、設定を確認します。開発の最初は、実際の患者情報を使わず架空データで試せます。

つながる例と、止まる例を両方試す

最初の検証は、確認済みの組み合わせで正しい書類に進めることに加え、番号が空、別拠点に同じ番号がある、対応候補が複数ある、といった例も用意します。不明なときに別人へ結び付けず、理由を表示して確認待ちに戻せるかを確かめます。

対応の修正には、変更前後、理由、担当者、日時を残す設計が役立ちます。また、患者が一致しても、予約日や検査日まで一致するとは限りません。患者の照合と、今回扱う予約・文書の選択は分けて確かめます。まずは二つのアプリ、一つの業務で、小さく検証するところから始めてみましょう。

次回は「Codexで何を形にできたか」。金川歯科医院の開発記録を、実装・試験・実運用・構想に分けて整理します。

出典・確認範囲

公式資料の確認日：2026年10月14日。番号の扱いと個人情報の考え方を確認するための資料です。本記事の対応表や確認待ちの流れは、これらを参考にした一般的な設計案で、医院の実装仕様ではありません。

この記事はAIによる調査・文章作成支援を用いています。公開後に運営者が確認し、必要に応じて追記・修正します。