医療データ基盤設計――電子カルテ・レセプト・臨床データの統合と規制対応

医療データ基盤は、取り扱う情報の重要性と規制の厳しさから、他のどの業界よりも慎重な設計が求められます。電子カルテ、レセプト、検査結果、画像、ゲノム情報――これらを統合して臨床研究やAI活用に使おうとすると、必ず「誰が何のために使うのか」「匿名化は十分か」「アクセス制御は適切か」という問いに向き合うことになります。本記事では、医療データ基盤の設計を、データソースの全体像、標準規格(HL7 FHIR等)との連携、匿名化・仮名加工の実装、臨床研究・AI活用への応用という観点で体系的に整理します。

医療データ基盤の必要性と特殊性

医療データ基盤の目的は、第一義的には診療の質の向上です。電子カルテ・検査・画像が統合されることで、同一患者の経過観察や診断支援、再入院予測、薬剤相互作用のチェックといった臨床判断支援が可能になります。第二に、医療経営の可視化――症例別の原価、診療科別の収益、医師別の診療パターンなどを分析し、経営判断に活かせるようになります。第三に、臨床研究とAI応用――仮名化されたデータセットから、疾患予測モデルや治療効果分析が可能になります。

一方、医療データには他業界にない特殊性があります。個人情報保護法上の「要配慮個人情報」に該当し、取得・保管・利用の全段階で厳格なルールが課されます。また、医療特有の標準規格(HL7 FHIR、DICOM、SS-MIX2等)への対応、院内ネットワークの閉域性、医療機器との連携、電子カルテベンダーのロックインなど、技術的制約も大きいのが実情です。これらを理解した上で、段階的に基盤を構築していく必要があります。

医療データの全体像

医療データ基盤が扱う主要データソースを整理します。それぞれ規模・更新頻度・活用用途が大きく異なります。

データソース	主な内容	データ量	主な活用
電子カルテ	病名、処方、記録、経過	中	診療支援、経過分析
レセプト	診療報酬請求データ	中	経営分析、保険者提出
検査	血液、生化学、細菌検査	中	病態分析、再発予測
画像	CT/MRI/レントゲンのDICOM	大(数百GB〜TB)	画像診断AI、読影支援
バイタル	生体モニタ、ICUデータ	大	ICU分析、急変予測
ゲノム	遺伝子配列、バリアント	極大	がん治療、希少疾患
処方履歴	薬剤、投与量、期間	中	副作用分析、重複投薬チェック

これらを統合する医療データ基盤のアーキテクチャを図示します。

【医療データフロー図】

院内系（閉域）
 [電子カルテ]  [検査システム]  [画像(PACS)]  [レセコン]
      |             |              |              |
      v             v              v              v
   +------------------------------------------+
   |   SS-MIX2 / FHIR / DICOMゲートウェイ     |
   +--------------------+---------------------+
                        |
                        v
          === 仮名化ゲート（PII/PHI除去） ===
                        |
                        v
            +----------------------+
            |  セキュアDWH          |
            |  (研究用・匿名化済み) |
            +----+-----------+-----+
                 |           |
                 v           v
         [dbt Mart Layer]   [MLワークベンチ]
                 |           |
                 v           v
         [臨床研究分析] [予測モデル/画像AI]

※ 原本と仮名化版は物理的に分離して保管する。

ポイントは、仮名化ゲートを明確に置くことです。PII/PHI(個人識別情報・保護保健情報)を含むデータと、仮名化・匿名化済みのデータを物理的に分離して保管し、アクセス権限も別管理することで、万一の漏洩リスクを最小化します。設計の考え方はセキュリティ設計と権限管理の記事も併せてご覧ください。

医療データの標準規格とマッピング

医療データの統合で鍵となるのが、標準規格への準拠です。ベンダー間の相互運用性を確保するため、国内外で複数の規格が整備されています。

規格名	対象	特徴	用途
HL7 FHIR	医療情報全般	RESTful APIでJSON/XML交換	システム間連携、研究用
HL7 v2	メッセージング	区切り文字ベースの旧規格	既存システム連携
DICOM	医療画像	画像+メタデータの国際標準	PACS、画像AI
SS-MIX2	電子カルテ出力	厚労省推奨の標準ストレージ	国内研究、データ提供
ICD-10/11	病名コード	国際疾病分類	レセプト、統計
LOINC	検査項目	検査名の標準コード	検査データ統合

新規に基盤を作るならHL7 FHIRを前提にするのが国際標準です。既存の電子カルテから直接FHIRへ出力できない場合、SS-MIX2出力を経由してFHIR形式に変換する構成が一般的です。病名はICD-10、検査はLOINCで統一コード化することで、複数施設のデータを横断比較可能な形に整えます。標準規格対応は一度整備すれば長期的に使えるため、初期投資を惜しまず取り組む価値があります。コンプライアンス対応も併せて検討してください。

匿名化・仮名加工の実装

医療データを研究やAI学習に使うには、個人が特定できない形に加工することが必須です。仮名化と匿名化は別概念で、仮名化は「鍵があれば元に戻せる状態」、匿名化は「もう元に戻せない状態」を指します。次世代医療基盤法の枠組みでは、認定事業者が匿名加工医療情報を扱える仕組みが整備されています。

-- 患者ID仮名化 + 準識別子のk-匿名化
WITH pseudonymized AS (
  SELECT
    TO_HEX(SHA256(CONCAT(patient_id, 'salt_v1'))) AS patient_pseudo_id,
    FLOOR(age / 5) * 5                             AS age_bucket,
    SUBSTR(postal_code, 1, 3)                      AS postal_prefix,
    gender, diagnosis_code, visit_date
  FROM raw.clinical_records
)
SELECT *
FROM pseudonymized
WHERE (age_bucket, postal_prefix, gender, diagnosis_code) IN (
  SELECT age_bucket, postal_prefix, gender, diagnosis_code
  FROM pseudonymized
  GROUP BY 1, 2, 3, 4
  HAVING COUNT(DISTINCT patient_pseudo_id) >= 5   -- k=5 匿名化
);

このSQLでは、患者IDをSHA256でハッシュ化(ソルト付き)して仮名化し、年齢を5歳単位にバケット化、郵便番号を上3桁に粗い化した上で、同じ属性の組合せが5人未満のレコードを除外するk-匿名化(k=5)を実施しています。k値は対象データと研究目的に応じて決定し、医療機関の倫理審査委員会の承認を得てから運用します。実務ではさらにl-多様性やt-近似性といった高度な技法を組み合わせ、再識別リスクを多層で下げることが推奨されます。個人情報保護法の規定に準拠することが前提です。

臨床研究・AI活用のためのデータ設計

臨床研究やAI活用で使うデータは、研究ごとに要件が大きく異なります。がんの予後予測では数十年のフォローアップデータが必要ですし、急性期の急変予測では秒単位のバイタルデータが必要です。データ基盤は、こうした多様な研究要件に柔軟に応えられる設計にしておくことが重要です。

現実的な設計は、DWHに統合された縦長のイベントテーブル(患者ID・イベント種別・時刻・値)と、研究ごとに切り出す仮名化済みデータマートを分離する構成です。研究者はデータマートから必要な切り口で抽出し、倫理審査を通った範囲で分析します。画像やゲノムのような大容量データは、DWHではなくオブジェクトストレージ(S3やGCS)に保管し、メタデータだけをDWHで管理する構成が効率的です。MLワークベンチ(VertexAIやSageMaker)からは、SQLでメタデータを検索し、必要な画像やファイルをストレージから取得して学習・推論する流れになります。

セキュリティとアクセス制御

医療データ基盤のセキュリティは、原則として「最小権限の原則」で設計します。ロールごとに、閲覧できるテーブル・カラム・行を厳密に制限し、監査ログを全て記録します。特に重要なのは、研究者がアクセスできるのは仮名化・匿名化されたデータマートのみであり、原本のPII/PHIには一切触れられない状態を技術的に保証することです。

BigQueryやSnowflakeでは、行レベルセキュリティ(RLS)と列レベルセキュリティ(CLS)をポリシーとして定義でき、ロールごとにきめ細かい制御が可能です。暗号化は、保管時(at rest)と通信時(in transit)の両方で実施し、鍵管理は顧客管理型(CMEK)を基本とします。加えて、アクセスログ・クエリログは完全に保管し、定期的に監査することで、不審なアクセスを早期に検知します。これらのセキュリティ対策は、医療情報システムガイドライン（厚労省）および個人情報保護法ガイドラインに準拠した形で運用してください。コンプライアンス対応の記事も参考になります。

まとめ

医療データ基盤は、標準規格への準拠、仮名化ゲートの物理分離、最小権限のアクセス制御、という3本柱を土台に設計します。電子カルテ・レセプト・画像・ゲノムといった多様なソースを統合しつつ、要配慮個人情報としての取り扱いを徹底することで、臨床と研究の両方に価値を届ける基盤が構築できます。近接領域の設計は金融データ基盤や教育データ基盤も参考になります。

よくある質問

医療データ基盤で最も注意すべき点は?

個人情報保護法の「要配慮個人情報」に該当するため、取得時の同意管理と厳格なアクセス制御が必須です。加えて、医療情報システムガイドラインや次世代医療基盤法の枠組みを理解し、法務・倫理審査委員会と連携して運用設計を進めることが重要です。

HL7 FHIRとは何ですか?

医療情報の相互運用性のための国際標準規格です。RESTful APIでの医療データ交換を定義しており、医療データ基盤の標準インターフェースとして普及が進んでいます。新規構築の場合は、FHIR準拠を前提に設計することを強く推奨します。

医療データの二次利用は可能ですか?

次世代医療基盤法（仮名加工医療情報法）に基づき、認定事業者を通じた匿名加工データの利活用が可能です。適切な匿名化処理と倫理審査委員会の承認が前提となります。自院内の研究利用であっても、倫理審査と同意取得のプロセスを必ず通してください。