[2-G-3-OP13-2] 異なるベンダーの医療系データベースを統合し セルフBI・災害時利用目的とした三次的利用サーバーの構築
診療現場において,日々大量の医療に関るデータを入力しているにもかかわらず、ユーザーがデータを円滑に取り出すことが困難な状況にある。実際、基幹DB(電子カルテ系)と部門DB(手術・重症系(ICU)、病歴系等)にまたがり抽出する場合、各々のDWHからCSVに落とし込みエクセル等で結合させていく知識が必要とされ、ユーザー自身が行うことが困難な背景があった。
以上を克服する方法として、毎日深夜帯に異なるベンダーのサーバーにアタッチし、SQLマルチインスタンスを利用した1つのSQLサーバーに統合・保存させ、そのデータを三次的利用できる統合サーバーを構築した。
三次サーバーは、将来性、汎用性からMSSQLを採用した。しかし、コピー元となる各DBは、オラクルやベンダー独自のものを利用しており、リレーションシップは使えなかった。そこで、ODBCを利用しコピー元の構造をそのままの形でSQLに変換する機能を付属のツールで独自開発し、深夜のタスク処理にて抽出、朝7時には前日までのデータが三次サーバーで利用できる構成が有用であった。
三次サーバーは独立しているため、日中の繁忙時の利用でも基幹業務のレスポンスに影響することはない。その特徴を利用し、1.統計管理者向けに、エクセルでSQLを直接集計できるMSSQLBI。2.一般ユーザー向けに、経営帳票や病歴の抽出ができるインメモリー型のセルフBI機能。3.100V端末にデータを落とし込み、災害時にスタンドアロンでデータ参照が可能な機能の実装を行った。
日々蓄積される医療情報は病院の貴重な資産であり、利用をベンダーの意向に左右されることは問題が大きい。1つのSQLサーバーに異なるベンダーの医療系データベースを蓄積させる、それがベンダーにデータを人質にされない為に私たちが導いた結論である。三次サーバーはベンダーを超えて自分たちの手でデータを利用できる仕組みであり、その汎用性から今後も発展の可能性が高いものと考える。
以上を克服する方法として、毎日深夜帯に異なるベンダーのサーバーにアタッチし、SQLマルチインスタンスを利用した1つのSQLサーバーに統合・保存させ、そのデータを三次的利用できる統合サーバーを構築した。
三次サーバーは、将来性、汎用性からMSSQLを採用した。しかし、コピー元となる各DBは、オラクルやベンダー独自のものを利用しており、リレーションシップは使えなかった。そこで、ODBCを利用しコピー元の構造をそのままの形でSQLに変換する機能を付属のツールで独自開発し、深夜のタスク処理にて抽出、朝7時には前日までのデータが三次サーバーで利用できる構成が有用であった。
三次サーバーは独立しているため、日中の繁忙時の利用でも基幹業務のレスポンスに影響することはない。その特徴を利用し、1.統計管理者向けに、エクセルでSQLを直接集計できるMSSQLBI。2.一般ユーザー向けに、経営帳票や病歴の抽出ができるインメモリー型のセルフBI機能。3.100V端末にデータを落とし込み、災害時にスタンドアロンでデータ参照が可能な機能の実装を行った。
日々蓄積される医療情報は病院の貴重な資産であり、利用をベンダーの意向に左右されることは問題が大きい。1つのSQLサーバーに異なるベンダーの医療系データベースを蓄積させる、それがベンダーにデータを人質にされない為に私たちが導いた結論である。三次サーバーはベンダーを超えて自分たちの手でデータを利用できる仕組みであり、その汎用性から今後も発展の可能性が高いものと考える。