「設計当初の段階では、新病棟が全床稼働した際にどの程度のデータ量が発生するのか判断できませんでした。また、新たな医療サービス充実のために検査機器などが導入された場合、どの程度データが増加するのかは予測しにくいのが実状です。さらに最近では他院から紹介された患者さんは、検査結果データをCD-Rに入れて持参するのが一般化しつつあるため、動画などを含むデータもクリニカルデータリポジトリに格納していかなければなりません。それゆえ、データベースサーバーは、必要に応じて容易に拡張できる必要があります。しかも、サービスを止めることなく、データベースサーバーを追加できる仕組みが求められたのです」（澤氏）。RACはデータベースサーバーを必要に応じて追加していくことで、データ容量の増大とともに性能の向上に対応でき、しかも膨大な医療情報をストレスなく検索・参照できる性能を持つ点が選定理由となったという。
ただし、データ量の増加によってストレージの増設が不可欠とは言っても、そのコストを可能な限り抑えることも重要だった。ストレージは、ディスク装置のグレードによって価格が大きく異なる。「当初、30テラバイトの容量を想定しましたが、これをすべて処理スピードの高いディスク装置でそろえる前提で試算したら、とんでもない金額になりました。そこで、グレードの高い高性能の装置と安価でそれなりの性能の装置を、両方利用することにしました」（澤氏）。
具体的には、生体情報のデータとアラームが上がったときに生成される心電図系のデータは、リアルタイム性が求められるので、高速なグレードの高いディスク装置に保存。記録や参照に俊敏性がそれほど求められないデータは、安価なディスク装置に保存することにした。通常は困難な併用体制を運営するために、データの重要度や利用頻度に応じて、ストレージを最適配置する管理ツール（Oracle Database 11g のAutomatic Storage Management）を導入した。澤氏は「現在は、1.5テラバイトを高速なストレージで、28.5テラバイトを安価なストレージで構成。ストレージ管理ツールによって、グレードの高いディスク装置だけで構成するのと比べて、約10分の1のコストでストレージ環境を構築できました」と語る。
もう1つの斬新な技術の導入は、サーバー仮想化による部門システムの構築である。ほぼすべての部門システム（約30）を、VMwareの仮想化技術で構築した。これにより、システム障害時に仮想サーバー移行で迅速な復旧が可能になると同時に、部門システムのデータバックアップを一元管理できるようになり、運用負担を大幅に減らすことができたという。
システム連携はエンジニアの世界からオペレーターの世界に
もう1つ重要な点は、医療情報連携基盤であるi-EHRのシステム連携手法として、SOA（サービス指向アーキテクチャー）技術を採用したことだ。SOA環境によって、部門システムとの柔軟なシステム連携と、ワークフローに基づいたプロセス連携が容易になり、早期のサービス立ち上げとコストの大幅な抑制につながった。
一般に、部門システムと電子カルテシステムを連携する際には、それぞれ異なるベンダーの部門システムとのインタフェース開発に膨大な時間とコストがかかる。例えば、生体情報モニターの場合、ベンダーが異なるとそれぞれの検査機器ごとにサブシステムを構築するケースがほとんどで、そのサブシステムごとにインタフェースを開発する必要がある。帝京大学病院では、製品の特性によって急性期病棟および手術室、一般病床、後方病床のそれぞれで異なるベンダー3社の生体情報システムを導入しているが、サブシステムの構築費用として3社が提出した見積の合計額は約9億円だったという。
澤氏は「各社の生体情報モニターはHL7などの標準形式に対応しているので、SOA環境であれば直接データを吸い上げることができます。そのため、ゲートウエイサーバーだけを各社に準備してもらうことにしました。9億円というサブシステムの構築費用は、支払わずに済みました」と、SOA環境によるシステム連携のコスト削減の大きさを指摘する。別のケースでは、昨年12月に心臓リハビリテーションサービスの新規立ち上が計画された際にも、サービス内容を設計し必要な医療機器を調達した。システム接続に関して従来のように電子カルテベンダーとの調整やエンジニアリングは不要になり、オペレーターレベルで接続を完了できたという。費用はほぼ医療機器の購入費用のみで、計画からサービス開始までわずか1カ月しかかからなかった。
従来のシステム環境では、新しい医療サービスのためのシステム導入時はもちろん、部門システムが更新されるたびにデータ連携のためのエンジニアリングが必要となり、そのたびに多くの工数と数百万から数千万円というコストが発生してきた。そのすべての作業と技術を、各ベンダーに依存せざるを得ないからだ。SOA環境実現によって、その状況は一変した。澤氏は、「データ連携は、エンジニアの世界からオペレーターの世界になった」と劇的な変化を表現する。
情報の有効活用に向けてスタッフごとのダッシュボード提供
i-EHRの運用が始まって、ちょうど1年。診療現場での意識は大きく変わった。「例えば、医療スタッフが診療端末でクリニカルデータリポジトリを検索してみて、そこに情報がなかった場合、データそのものが存在しないと判断するようになりました。システムやデータベースに対する信頼度が上がった結果です。そのため、従来のように研修医や医療情報管理スタッフが、病院内の各部門を走り回って資料を探すというような、ムダな労働がなくなりました」（澤氏）。
また、情報の有効活用という点では、現在取り組んでいるのがアクティビティーベースの原価管理だ。帝京大学病院では2004年に原価管理システムを導入していたが、そのコストドライバーが固定化したものであり、ドライバーの見直しも手間がかかるために、導入当初に設計したコストドライバーをそのまま使い続けていたという。各診療科の占有面積にしても、新病棟のオープンなどにより環境は大きく変わったにもかかわらず、従前の値を利用せざるをえない状況だった。「診療科の面積などはもちろん、医療スタッフの行動、特に看護師は指示に基づいて行動していますから、そのステータス情報はすべてi-EHRに記録されており、細かいレベルでのアクティビティーの把握が可能になりました。その分析によって、業務の割り振りの最適化もやりやすくなります」（澤氏）。
各診療科の医師ごとの診療患者数、平均在院日数など一般的な病院統計情報、各診療科のホームページなどで公表している症例別などの各種統計情報なども、クリニカルデータリポジトリからの整理・分析が非常に容易にできるようになっている。澤氏は「経営上、あるいは診療上の意思決定のためBI（ビジネスインテリジェンス）を推し進めていくことが今後の展開です。現在はオペレーターによるデータの抽出・分析が行われていますが、最終的な目標は院長、各診療科医師、看護師、事務スタッフなどそれぞれのスタッフが、必要な情報をオペレータに頼らず自分で分析・参照できるような環境にすることです。それをダッシュボード化して、情報提供できる仕組みを構築する計画です」と説明する。
生産性の高いシステム連携の仕組みと情報の統合・一元化により医療データのガバナンスを実現した帝京大学附属病院は、今後も医療現場での情報の有効活用に向けた環境整備を一層進めていく。
■病院概要
名称：帝京大学医学部附属病院
住所：東京都板橋区加賀2-11-1
病床数：1154床（一般：1107床/精神：47床）
主な承認指定：特定機能病院／救命救急センター／総合周産期母子医療センター／がん診療連携拠点病院／救急医療機関指定／災害拠点病院／臨床研修指定病院
Webサイト：http://www.teikyo-u.ac.jp/hospital/
導入システム：オラクル（データベース他、病院情報連携基盤プラットフォーム）など
