電子カルテと経営データをつなぎ、病院経営を数字で回す
電子カルテ、部門システム、医事会計が分断し、施設ごとにデータ形式も揃っていない。抽出のたびにベンダーへ依頼が必要で、1回に数十万円かかる。施設横断の標準化から始める。
業界に共通する課題
院内システムがベンダー縦割り
電子カルテ・部門システム・医事会計が分断し、施設でデータ形式も不揃い。施設をまたいだ比較が実質的に不可能。
稼働×コストの実態が見えない
病床稼働・診療科別収支を突合できず、経営改善の打ち手が立てられない。「なんとなく黒字／赤字」の感覚で運営している。
データ抽出がベンダー依存
抽出のたびにベンダーへ依頼が必要で、時間も費用もかかり分析が進まない。1回の抽出依頼が数十万円になることも。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- A病院 電子カルテ（X社）
- B病院 電子カルテ（Y社）
- 医事会計（施設別）
- 部門システム・勤怠
- 病床稼働率（施設横断）
- 診療科別収支
- 職種別の人件費率
- 材料費・在庫
症状：診療収入は施設ごとの医事会計、人件費は勤怠システム、材料費は購買にあり、診療科コードが施設間で統一されていない。稼働率の定義も揃っておらず、分母が病床数の施設と稼働病床数の施設が混在している。抽出のたびにベンダーへの依頼が必要なため、施設横断の集計は経営会議前の手作業に依存している。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
各施設の医事会計・部門システム・勤怠から、本番に負荷をかけずデータを収集。ベンダーへの都度抽出依頼が不要になります。
揃える
施設ごとに異なる形式を標準化し、マルチテナントで施設別に分離しつつ横断分析可能に。指標の定義（稼働率の分母など）を全施設で統一します。
使う
病床稼働×診療科別収支のダッシュボード、匿名加工データの研究・改善活用、AI照会。経営会議の資料作成工数がほぼゼロになります。
施設が増えても、作り直しにはなりません。電子カルテの更改があってもコネクタ設定だけで追従できます。買収で病院が加わるようなグループ拡大では、施設が増えるほど基盤の価値が上がります。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
施設ごとに異なる診療科コードと稼働率の定義を統一し、診療収入と直接費を同一粒度で集計しました。
| 診療科 | 施設 | 診療収入 | 直接費 | 収支率 |
|---|---|---|---|---|
| 整形外科 | B病院 | ¥ 82,400千 | ¥ 91,200千 | ▲10.7% |
| 内科 | A病院 | ¥168,000千 | ¥161,400千 | +3.9% |
| 循環器科 | A病院 | ¥214,000千 | ¥178,600千 | +16.5% |
B病院 整形外科が10.7%の赤字です。要因分解では「病床稼働率68%（グループ平均84%）」と「手術室稼働の偏り（木曜のみ集中）」が主因。① 手術枠の平準化（想定 月+540万円）、② A病院整形との患者導線見直し、の2案を提示します。材料費では同一製品の施設間価格差（最大22%）を12品目で検出しました。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.department_pl- 施設コード
facility_id - 診療科
department - 収益
revenue - 直接費
direct_cost - 病床稼働率
bed_occupancy - 職員労働時間
staff_hours - 対象日
dt
施設・ベンダーごとに異なる項目定義を統一。個人が特定できる情報は匿名加工したうえでmart層に載せるため、研究・改善活用と個人情報保護を両立できます。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 8:00事務長
前日の病床稼働・手術件数・救急受入数の要約がAIから届く。異常値は理由の仮説付き。
- 昼 12:30診療部長
「自科の症例別収支と平均在院日数」を会話で照会。診療のあり方をデータで議論できる。
- 夕 16:00購買担当
材料費の施設間価格差アラートを確認。グループ一括交渉の候補品目が自動抽出される。
- 週次理事会
施設横断の収支が週次で確認できる（従来は月次以上）。会議資料の作成工数がほぼゼロ。
想定効果（仮定に基づく試算イメージ）
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。
3つの使い方のうち、どれを使うか
3つは排他ではありません。Cだけで始めて、あとからBへ広げることもできます。
W3 WMS × AI照会
弊社WMS（W3 sirius / W3 mimosa）のデータをデータレイクに取り込み、MCP経由でAIが直接参照します。SQLの記述もBIツールの操作教育も要りません。聞けば返ってきます。
データレイク蓄積（データ基盤 格納型）このモデルケースの主軸
他社システムのデータ連携サーバー、基幹DB、ECカートなどをCDC（変更差分取得）で接続し、毎日流れてくるデータをraw／mart 2層に溜め込みます。既存システムは無改修です。溜まったデータを、自然言語の指示で分析・加工できる状態にします。
ETL単体（システム直接連携）
データレイクを作らないまま、「抽出→変換→格納」だけのシステム間インターフェースとして使えます。個別IF開発をノーコードのGUI設定に置き換えることで、IF開発費が従来比 1/3〜1/2 になります。ここから始めて、あとからBへ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。