医療DWHの星型設計徹底解説：患者・受診・診療行為・検査データモデルで実現する医療DX
医療DWHの星型設計で患者・受診・診療行為・検査データをどうモデル化するか。具体的なデータモデル例から、医療DXを加速するデータ活用戦略と実践的課題解決策を解説します。
目次 クリックで開く
医療DWHの星型設計徹底解説：患者・受診・診療行為・検査データモデルで実現する医療DX
100件超のBI研修と50件超のCRM/データ基盤導入から導き出した、医療データの「サイロ化」を打破する究極のアーキテクチャ。現場の落とし穴を回避し、経営と臨床の質を直結させる設計指針を公開します。
はじめに：なぜ医療機関のデータ活用は「星型設計」でなければならないのか
医療現場において「データはあるが、活用できていない」という声は、私がコンサルティングに入らせていただくほぼ全ての病院で共通する悩みです。電子カルテ、レセコン、画像診断、検査システム……。各部門で最適化されたSaaSやパッケージが導入された結果、データはバラバラに分断（サイロ化）され、経営層が「疾患別の利益率」を見ようとしたり、臨床医が「特定薬剤の投与量と検査値の相関」を分析しようとしても、SQLの地獄のような結合（JOIN）作業に阻まれるのが実態です。
この問題を解決する唯一の処方箋が、「星型設計（スタースキーマ）」による医療DWH（データウェアハウス）の再構築です。正規化された業務データベースとは異なり、分析の高速化と直感性を追求したこの設計手法こそが、医療DXの心臓部となります。本稿では、実務で数々の失敗と成功を見てきた立場から、教科書通りではない「勝てるデータモデル」を解説します。
1. 医療DWHの基礎と星型設計の構造
ファクトとディメンションの明確な分離
星型設計は、中央に「事実」を記録するファクトテーブルを置き、その周囲に「属性」を示すディメンションテーブルを配置します。医療データにおいては、以下の定義が標準となります。
- ファクトテーブル： 受診、診療行為（点数/費用）、検査結果値、処方量、入院日数など。時系列で蓄積され、計算（SUMやAVG）の対象となるデータ。
- ディメンションテーブル： 患者属性、医師名、診療科、ICD-10（疾患コード）、日付、時間、施設など。分析の「切り口（軸）」となるデータ。
| 設計要素 | 役割 | 医療現場での具体例 |
|---|---|---|
| ファクト | 事象の数値的記録 | 診療行為点数、検査値、待ち時間、利益額 |
| ディメンション | 文脈・属性の定義 | 患者の年齢層、主治医の専門、地域、年度 |
| メリット | 分析の高速化 | 数千万件の検査データから特定疾患のみを数秒で抽出可能 |
この構造を採用することで、現場のスタッフがTableauやPower BIなどのBIツールを使って自らデータを探索する際、「どのテーブルと結合すればいいか分からない」という迷いを一掃できます。関連リンクとして、【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』も参照してください。データ連携の思想は、ヘルスケアでもバックオフィスでも共通です。
2. 【実践】患者ディメンションの設計と「名寄せ」の罠
主要項目とデータモデリング
患者ディメンション（Dim_Patient）は、分析の基点となる最重要テーブルです。単に電子カルテの患者マスタをコピーするのではなく、分析に必要な「導出属性」を持たせることが肝要です。
- 患者ID（サロゲートキー）： システム間のID重複を避けるためのDWH専用キー。
- 属性情報： 生年月日、性別、住所（市区町村レベル）、死亡フラグ。
- 【＋α】分析用属性： 初診日からの経過日数、最終受診日、重症度カテゴリなど。
匿名化・仮名化の実装指針
医療データは「要配慮個人情報」の塊です。分析用DWHには、直接識別子（氏名、詳細な住所、電話番号）は入れず、ハッシュ化した仮名IDを使用するのが鉄則です。
【出典URL：厚生労働省：医療情報システムの安全管理に関するガイドライン】
3. 受診・診療行為・検査のデータモデル設計
受診ファクト（Fact_Encounter）
「1受診（来院から帰宅まで）」を1レコードとする粒度です。ここでは、「待ち時間」「滞在時間」「初再診区分」をメジャーとして持ちます。これは病院経営における「稼働率」や「効率性」を測るKPIの源泉となります。
診療行為ファクト（Fact_Procedures）
粒度は「オーダー明細単位」です。DPC（診断群分類別包括評価）対象病院の場合、ここに含まれるDPCコードと点数が、収益分析の鍵を握ります。
| 項目カテゴリ | 物理名例 | 型 | 解説 |
|---|---|---|---|
| 外部キー | patient_key | INT | Dim_Patientへの結合用 |
| 外部キー | date_key | INT | Dim_Dateへの結合用 |
| メジャー | procedure_points | DECIMAL | 診療行為の点数 |
| メジャー | drug_dosage | DECIMAL | 薬剤の投与量 |
検査ファクト（Fact_LabResults）
検査データは、数値データとテキストデータ（所見）が混在する難所です。
数値データについては、必ず「基準値上限・下限」を同一レコード内に持たせる設計にしてください。
【出典URL：一般社団法人 日本医療情報学会：J-MIX（標準的検体検査データ名称）】
4. 推奨ツールとコスト感
医療DWHを構築する際、オンプレミスのレガシーなDBを選択するのはもはや時代遅れです。拡張性とセキュリティ、そして何より計算能力を考慮すると、クラウドネイティブな構成一択となります。
1. Google BigQuery
医療DXにおいて最も採用されているデータウェアハウスです。
- 特徴： サーバーレスで運用負荷が極めて低い。数ペタバイトのクエリも数秒で完結。
- コスト： ストレージ：$0.02/GB、クエリ：$5/TB（無料枠あり）。
- 公式サイトURL： https://cloud.google.com/bigquery
当社のアーキテクチャ事例でも、高額MAツールは不要。BigQueryとリバースETLで構築するアーキテクチャとして紹介しています。
2. Snowflake
マルチクラウド対応のデータクラウド。
- 特徴： データの共有機能（Data Sharing）が強力で、共同研究やグループ病院間での連携に最適。
- コスト： コンピューティング費用：$2.00/クレジット〜。
- 公式サイトURL： https://www.snowflake.com/ja/
3. trocco（ETLツール）
医療機関内の閉域網データをクラウドへ転送するための国内SaaS。
- 特徴： GUIベースで設定可能。日本の商習慣やデータ構造に強く、サポートが手厚い。
- コスト： 月額10万円〜。
- 公式サイトURL： https://trocco.io/lp/index.html
5. 導入事例・成功シナリオ：特定機能病院Bの変革
課題：経営分析の遅延と臨床研究の限界
特定機能病院Bでは、月次の経営会議資料を作成するのに、医事課のスタッフが毎月30時間をかけてExcel集計を行っていました。また、医師が研究のためにデータを必要とする際も、情報システム部門に依頼してからデータが届くまで1ヶ月を要していました。
解決策：BigQueryによる星型DWHの構築
電子カルテおよび医事会計システムのデータをtrocco経由でBigQueryへ統合。本稿で解説した「星型設計」に基づき、患者・受診・診療行為・検査の4大データモデルを構築しました。
成果：
- 経営可視化： 会議資料の自動更新により、医事課の残業代を年間200万円削減。
- 臨床への貢献： 医師がLookerを利用し、自ら「特定術式後の合併症発生率」をリアルタイムに分析可能になった。
- コスト最適化： 不要な検査や過剰投薬のパターンを可視化し、薬剤費の3%削減に成功。
【出典URL：Google Cloud Blog: How hospitals use BigQuery】
まとめ：データモデルが医療の質を決定する
医療DXとは、単に電子カルテを入れることではありません。蓄積された膨大なデータを「知恵」に変える仕組みを、組織に埋め込むことです。そのためには、技術的に正しいデータモデル、すなわち**「星型設計」**という強固な土台が不可欠です。
もし貴院が、高額なパッケージを導入したにもかかわらず、「見たいデータが見られない」状況にあるなら、それはツールのせいではなく、データアーキテクチャの不在が原因かもしれません。私たちは、単なるシステムの導入ではなく、現場が使いこなせるデータ基盤の設計から、BI研修による文化の定着までを伴走支援します。
