図1●異なるシステム間で情報を共有するためにグリッド技術を採用<BR>電子カルテを中心とする診療情報を,県内の有力病院と地域の診療所間で共有するシステムを目指した。既に稼働中のシステムをいかに接続するかが課題になったが,データ・グリッドによりデータベースを仮想的に統合することで,この壁を乗り越えた
図1●異なるシステム間で情報を共有するためにグリッド技術を採用<BR>電子カルテを中心とする診療情報を,県内の有力病院と地域の診療所間で共有するシステムを目指した。既に稼働中のシステムをいかに接続するかが課題になったが,データ・グリッドによりデータベースを仮想的に統合することで,この壁を乗り越えた
[画像のクリックで拡大表示]
図2●県立3病院間で診療データを複製&lt;BR&gt;各病院でカルテに記された診療データを相互に配信し,データを複製することで情報を共有する。地域の診療所は,SSL-VPNでこの情報にアクセス可能
図2●県立3病院間で診療データを複製<BR>各病院でカルテに記された診療データを相互に配信し,データを複製することで情報を共有する。地域の診療所は,SSL-VPNでこの情報にアクセス可能
[画像のクリックで拡大表示]
図3●グリッド・ミドルウエアがデータベースの違いを吸収&lt;BR&gt;中央病院は新たにシステムを構築したが,海部病院と三好病院は既に電子カルテ・システムを構築していた。既存システムには手を加えず,データ・グリッドのミドルウエア(WebSphere Information Integrator)を導入してデータを複製。データ・グリッドのミドルウエアが,各データベースのスキーマに合わせたSQL文と配信用のスキーマに基づくSQL文を相互に変換し,データベースの違いを吸収する
図3●グリッド・ミドルウエアがデータベースの違いを吸収<BR>中央病院は新たにシステムを構築したが,海部病院と三好病院は既に電子カルテ・システムを構築していた。既存システムには手を加えず,データ・グリッドのミドルウエア(WebSphere Information Integrator)を導入してデータを複製。データ・グリッドのミドルウエアが,各データベースのスキーマに合わせたSQL文と配信用のスキーマに基づくSQL文を相互に変換し,データベースの違いを吸収する
[画像のクリックで拡大表示]

Point
1. 3つの病院間で診療情報を共有,将来はほかの病院にも接続する計画
2. グリッド・ミドルウエアを採用し,異種分散データベースを複製
3. 既存DBとの接続は,トランザクション・ログを定期的に参照して実装

 徳島県内の3つの県立病院が,診療情報の共有システムを構築した。このプロジェクトに参加したのは,徳島県立中央病院と同海部病院,同三好病院。将来的にはさらに多くの病院と情報共有する構想があり,災害時のデータ保護を兼ねたかったことから,「データ・グリッド」技術を採用した(図1[拡大表示])。米IBMのグリッド・ミドルウエア「WebSphere Information Integrator」を利用し,病院間でデータベースを複製させている。2005年7月にシステムをカットオーバーした。

DBのスキーマも種類もばらばら

 構築したシステムは「地域診療情報連携システム」と呼ぶ。中央病院の電子カルテ・システムの刷新と同時期に,3病院間の診療情報共有プロジェクトが立ち上がった。

 中央病院の電子カルテ・システムは,地域診療情報連携システムと同時期に構築するので情報共有を前提に設計できる。だが,ほかの2つの病院のデータベースや,中央病院のほかのシステムのデータベースは,情報共有を前提に構築していない。データベースのスキーマは異なるし,RDBMSの種類もばらばら。実際,海部病院はOracle Database,三好病院は富士通のSymfowareを利用していた。

 病院間で情報共有するためには,各病院のデータベース・スキーマを統一したり,データセンターを新設したりといった方法も考えられる。だが,「事業として独立している病院間でデータベースの仕様を統一するのは過去の経験からも難しく,1カ所にDBサーバーを集約するのは負担が重く現実的ではない」(プロジェクトの中心となった徳島県立中央病院 企画情報化 システム係長の佐光広格(さこうひろのり)氏)。

 当面は3病院だけが対象になったが,将来的には県内の別の病院とも連携する構想が最初からあった。さらに,「大きな災害が発生し,いずれかの病院が被害に遭ったとしても,県立病院で持っている情報を失わずに保護するシステムを作りたかった」(佐光氏)。こうした状況で佐光氏は,「異なる複数のデータベースを仮想的に一つのデータベースに見せる『データ・グリッド』が現実的な解だ」と考えた。

 具体的には,それぞれの病院で更新した情報を相互に交換し,どこの病院でもほかの病院の診療情報を取り出せるよう設計した。データベースを複製し,いずれかの病院でシステムがダウンしても,ほかの病院ではそれを意識せずにデータベースを利用できる。大規模な災害が発生しても,全病院のデータベースが壊れない限り,データは保護される。各病院のデータベースの位置付けが等しく,特定のサーバーやデータベースに依存しないシステムである。この考えを基に,地域診療情報連携システムを構築した(図2[拡大表示])。

DBの違いはミドルが吸収

 データベースの複製に利用したのは,米IBMのグリッド・ミドルウエア「WebSphere Information Integrator」(以下,WII)である。SQL文をメッセージ・キューイング技術で送信するソフトだ。メッセージ技術を用いているので,送信先のシステムがダウンしてもメッセージを送信しないだけで,ほかのシステムには影響しない。

 地域診療情報連携システムでは,このWIIを複製対象のデータベースの数だけ,データベースとペアになるように配置した。配置場所は,WIIの導入を前提に設計した中央病院の電子カルテ・システムと,海部/三好病院の既存システムでは異なる。

 中央病院のシステムでは,アプリケーション・サーバーとデータベースの間にWIIを配置した。アプリケーション・サーバーからはWIIがデータベースに見える。一方の海部病院や三好病院では,既存システムを修正したくないためアプリケーション・サーバーとデータベースの間ではなく,アプリケーション・サーバーからするとデータベースの後ろに配置した。こうすれば既存のアプリケーションの修正は不要で,WIIはデータベースにだけアクセスするようになる。

 SQLデータベースのスキーマの違いや,RDBMSの種類の違いは,WIIが吸収する。WIIの動きを,中央病院のデータベースが更新された場合で説明しよう。WIIはアプリケーション・サーバーからSQL文を受け取り(図3[拡大表示](1)),ローカル・データベースにそのSQL文を引き渡す(同(2))。WIIは受け取ったSQL文を,あらかじめ設計しておいたデータ交換用のスキーマに合わせて変換する(同(3))。変換したSQL文をメッセージ・キューイング技術を用いてほかのすべてのWIIに送信(同(4))。メッセージを受け取ったWIIは,メッセージからSQL文を取り出して変換し(同(5)),SQL文をデータベースに発行する(同(6))。

 メッセージ・キューイングを利用しているので情報の転送は非同期だが,「実際に計測したところ,メッセージの送信から他の病院のデータベースが更新されるまで,ほぼ1秒以内に完了している」(佐光氏)という。