帝京大学医学部附属病院（以下、帝京大学病院）は、2009年5月から統合型病院情報システムを運用している。医療情報連携基盤にSOA（サービス指向アーキテクチャ）を採用し、クリニカルデータリポジトリによる医療情報の統合・一元化と、サーバー仮想化技術を使った部門システムのサーバー統合を実現した、画期的な病院情報システムだ。そのコンセプトは、的確な意思決定を支援するために医療スタッフに必要な情報を適切に提供するという目的を、データガバナンスを実現することで達成しようというものである。
医療現場の利用者に必要な診療情報を確実に提供するために
多くの医療機関で病院情報システムの構築・運用が行われるようになったが、そのほとんどは電子カルテシステムを中心に置き、各部門システムを連携させて電子カルテシステム上からデータを参照する構造になっている。この構造の最大の利点は、患者情報を起点として、診療録の記載内容や部門をまたがったオーダーエントリー・実施、検査データの参照などが可能なことだ。
しかし、診療情報の有効な活用という視点から見ると、必ずしも良い仕組みとはいえない。例えば、病院経営の視点での情報分析やEBM実践のための情報活用、教育・研究のための情報活用を考えた場合、アプリケーションの機能の範囲内でしか情報を利用できないのは足かせとなる。帝京大学病院の統合型病院情報システムが目指したものは、そうした電子カルテシステム中心のシステムではない。診療現場で医療情報を有効活用できるようにするための、病院情報システムの実現である。
「われわれが構築した統合型病院情報システムは、必要な医療情報のすべてをクリニカルデータリポジトリに統合・一元管理し、医師や看護師など院内の利用者へ必要な情報をタイムリーに提供し、的確に意思決定の支援ができるシステムです。従来の電子カルテ製品は、部門システム同様、病院情報システムを構成している部品の1つに過ぎないという考えで構築しました」。帝京大学本部情報システム部部長の澤 智博氏は、新病院情報システムのコンセプトをこう述べる。
現在の日本の電子カルテ製品は、オーダリングシステムから進化しているため、医事会計に結びつくオーダーエントリー・実施情報をベースにデータが記録されるようになっている。したがって、患者が再来受付機で受け付けした時間、診察ブースに到達した時間、検査を受けている状態など、患者のステータス情報はシステム上に存在するものの、そのデータは数カ月で消去されてしまうことがある。
澤氏は、こうしたデータ管理の仕組みは、情報活用という点で問題があると指摘する。患者の院内滞留時間は経営的な視点での重要指標であるため、病院側が意図した患者導線に沿っているかどうかを計るデータとしては、患者ステータス情報が活用できなくなるからだ。
オーダリングシステムは、もともと関連する複数の処理を1つの処理単位としてまとめたトランザクションをベースとしており、各データを直接活用するのは難しい。特にオーダリングシステムをベースにした電子カルテ製品のデータベースは、ベンダー独自の製品で仕様が明らかにされないため、ユーザーが触れることはできない。
また、電子カルテ製品が部門システムと連携していても、情報そのものは部門システムのデータベースやファイルシステムに分散している。電子カルテの画面表示上は統合されているように見えるものの、部門システム上の情報のありかを示しているだけである。その情報を個別に抽出して活用するのは困難であるのに加えて、マルチベンダーで構成される部門システムのデータの保全性は一貫性に乏しく、長期保存する場合は各部門で独自にシステムを構築する必要も出てくる。
こうした部門システムの情報やオーダリング情報を含む電子カルテ製品のデータなど、すべての医療情報をクリニカルデータリポジトリに格納し、活用できる仕組みが統合型病院情報システムである。「欧米でいわれている病院情報システムは、CPOE（医師向けオーダーエントリー）、EHR（電子診療録）、CDR（クリニカルデータリポジトリ）、DSS（意思決定支援システム）の4つが要素になっています。電子カルテ製品はオーダリングと診療録の機能部品として利用し、その情報および部門システムの全情報をオープンなデータベースに統合し、自分たちで統制できる環境を構築することが最大の目的でした」（澤氏）。
耐障害性・拡張性・柔軟性を実現するテクノロジーの選択
帝京大学病院が構築した「i-EHR」は、富士通の電子カルテシステムのデータベースと相互に連携している。同時に、各部門システムと連携し、PACSで扱われる医用画像データであるDICOMデータ以外のあらゆる医療情報を、クリニカルデータリポジトリに格納する。利用者は電子カルテ端末でオーダーエントリーや、テンプレートを利用した診療録の入力・参照作業をすると同時に、別のi-EHR画面で部門システムの各種検査結果やPDF化した文書情報を参照できる。つまりi-EHRは、病院情報連携基盤としての役割と部門システムの情報の結果参照機能を持っていることになる。
i-EHRの核となるクリニカルデータリポジトリのシステム要件は、まず1つのリポジトリの中でテキストデータと、静止画や動画などのバイナリデータ（非構造化データ）を統合管理できるオープンな仕様のデータベースであることだった。「PACSは、製品として完結しており、当院の規模で100テラバイトを超える容量が必要であることから、クリニカルデータリポジトリとは別に構築するのが妥当と考えました。そのためPACSは、DICOM用ストレージという位置付けで、放射線部門の医用画像とDICOM化したエコーデータを格納しています。それ以外の写真データや動画データ、スキャンした文書データなども合わせて一元的に管理できることが最大の要件でした。また、情報の有効な二次利用がしやすいよう、オープンな標準仕様のデータベースであることも要件の1つでした」（澤氏）という。
クリニカルデータリポジトリには、あらゆる医療情報が集中するため、システム障害が起こると、即時に診療業務の停止を招くことになる。それを避けるためには、耐障害性に優れ、冗長構成をとれることが重要だ。こうした要件を考慮した結果、澤氏が選択したクリニカルデータリポジトリのプラットフォームソリューションは、オラクルのOracle Database 11gおよびOracle Real Application Cluster（RAC）だった。その大きな理由は、複数のサーバーを連結するクラスター構成にして、データベースの可用性を高められるからだ。加えて、新しい医療サービスの追加提供や動画像など非構造化データの急増が確実視されたため、クリニカルデータリポジトリの大容量化は避けられないと判断し、スケーラビリティーも重視した。
