電子カルテ共有:相互運用性ガイド

電子カルテ（EHR）をシステム間で共有するには、少なくとも4つの規格を調整しなければならない。APIベースの交換にはHL7 FHIR R4、文書ベースの転送にはC-CDA R2.1、レガシーメッセージングにはHL7 v2.x、画像にはDICOMだ。個人情報保護委員会（PPC）は2024年の改正APPI対応ガイドラインで、医療情報を扱う事業者に対して転送時の暗号化とアクセスログの保存を明示的に求めている。

実際に使っている標準の積み重ね

医療記録の相互運用性が複雑に見えるのは、実際に複雑だからだ。各レイヤーの役割を以下に示す。

HL7 v2.x：1990年代のパイプ区切りメッセージ。病院内の検査オーダー・ADT（入院/退院/転棟）フィード・オーダー管理の主力。組織間の共有には不向き。
C-CDA R2.1：患者サマリー・退院サマリー・紹介状を表現する構造化XML文書。DirectメッセージングとほとんどのHIE交換の基盤。
HL7 FHIR R4：JSON/XMLでHTTPS上で交換されるRESTfulリソース（Patient、Observation、Condition、MedicationRequest）。ONCカーズ法規制が要求する現代の層。
DICOM：画像専用の規格。独自のパイプ（DIMSE、DICOMweb）を持つ。
USCDI v3：認証済みEHRが公開しなければならないデータクラスと要素。臨床メモ・社会的決定要因・性的指向/性自認を含む。

「EHRを共有する」とは、各レイヤーから断片を取り出し、受信者に適したフォーマットに組み合わせることだ。

FHIR APIと情報遮断禁止規則

ONCの21世紀医療法最終規則（45 CFR Part 171）は、2020年5月より情報遮断を禁止行為とし、2023年のHHSの最終規則の下では特定の主体に対して1件あたり最大100万ドルの民事制裁金を設けている。技術要件として、認証済みEHRはUSCDIデータセットをサポートするFHIR R4 APIを公開しなければならない。

Epic、Cerner、athenahealth、eClinicalWorksとの統合開発者の場合のステップを示す。

ベンダーの開発者ポータルにアプリを登録する
OAuth 2.0とPKCEを含むSMART on FHIRの起動シーケンスを使用する
patient/*.readなどのスコープをリクエストする
HTTPS上でJSONバンドルを受信する

実際の落とし穴として、APIスコープ・レート制限・本番アクセスがベンダーごとに大きく異なることが挙げられる。EpicはPayer-ProviderまたはSpecialty Appの合意が必要、CernerはSandboxへのアクセスが速いが認証フローが異なる。

C-CDA：組織間サマリーのデフォルト

FHIRの台頭にもかかわらず、ほとんどの組織間記録交換はC-CDA文書として送られる。C-CDA R2.1のContinuity of Care Document（CCD）は通常200KB〜2MBのXMLで人間が読めるHTMLを埋め込んでいる。主なテンプレートを示す。

CCD（ケアの継続性文書）
退院サマリー
紹介状
診察記録
経過記録

これらはDirectメッセージング（S/MIMEover SMTP）またはクエリベースのHIE交換を通じて流れる。受信EHRはXMLをパースし、構造化要素をローカル記録に取り込む。パースの品質にはばらつきがあり、問題リストは取り込めても社会歴が欠落するEHRもある。

TEFCA、QHINと国家レベルのネットワーク戦略

Trusted Exchange Framework and Common Agreement（TEFCA）は2022年1月にONCが最終化し、2023年から運用開始した。Qualified Health Information Networks（QHIN）がCommon Agreementを通じて相互接続する。

送信側臨床医の観点から言えば、TEFCAは「一度クエリを発行し、QHIN参加者全体にリーチする」ことを意味する。IT担当者の観点からは、既存のIHEプロファイルに上乗せされたガバナンスレイヤーであり、新しいプロトコルを実装するものではない。

APIが失敗したときのファイル転送へのフォールバック

あらゆる標準があっても、どのAPIにも収まらないファイルを移動させる必要に迫られる場面がある。例を以下に示す。

電子化以前の紙の記録をスキャンした300MBのPDFバンドル
後ろ向き研究レビュー用のSASまたはStata形式の研究データセット
画像サーバーに格納する必要のない在宅医療の創傷写真セット
係属中の医療過誤訴訟に関連する法的保持記録

このようなケースでは、暗号化ファイル転送へのフォールバックが必要だ。要件はBAAの締結・保存時AES-256-GCM・転送時TLS 1.3・監査ログ・リンク有効期限だ。

HexaTransfer はアップロード前にクライアントサイド暗号化を行うアドホック手段として機能する。https://hexatransfer.com で無料・アカウント不要・最大10GBで利用できる。転送を標準の監査記録に記録しておくこと。

患者照合と識別子問題

記録を共有するには、それが正しい患者のものであることを確認する必要がある。日本では「医療等ID」の整備が進みつつあるが、完全な実装はまだ先だ。現状では氏名・生年月日・性別・住所・電話番号による確率的マッチングに依存する。

本番ネットワークでの照合率はデータ品質によって70〜95%と幅がある。照合漏れは診療時点での記録欠如と、下流カルテの重複記録を招く。

ファイルレベルの転送では、ファイル名または表紙に患者識別子を必ず含める。患者番号・生年月日・少なくとも1つの追加識別子が必要だ。臨床医が「Yamada-MRI.dcm」がどの患者のものかを推測することに頼ってはならない。

同意・セグメンテーションと特別な記録

すべての記録が同等に共有できるわけではない。精神科の診療記録・HIV検査結果・遺伝情報・生殖に関する健康情報は多くの国で特別な共有規則を持つ。日本でも次世代医療基盤法やゲノム指針が適用される。

転送ツールがセグメンテーションを尊重できない場合、つまりどの部分に追加同意が必要かを識別できない場合は、精神科記録に使用しないことだ。整形外科のフォローアップパケットに使えばよい。

小規模診療所とリソースギャップ

医師3名の診療所にはCIOがいない。医療事務が請求業務と並行してITを担当する。それでも、要求に応じてUSCDI準拠の記録を提供し、すべてのベンダーとBAAを締結し、情報遮断の苦情に対応しなければならない。

実務的なアプローチを示す。

Direct・FHIR・患者APIを標準で備えるEHRを選択する
EHRが送信できないすべてに対応するBAAつきのアドホック暗号化転送ツールを1つ選ぶ
ワークフローを1枚のSOPに文書化する
毎週使う2つのツールについてスタッフ全員をトレーニングする

電子カルテの共有は単一ベンダーが解決する問題ではない。維持すべき多層ワークフローだ。標準が対応できる部分は標準を使い、標準がカバーしない事例には安全な暗号化フォールバックを持つ。NISCの「重要インフラのサイバーセキュリティに係る行動計画」でも医療分野の安全な情報連携が強調されている。