病院情報システムの診療情報を口の難病プロジェクトに活用する仕組みとその課題

There have been many reports of active trial to use electronic medical data stored in the hospital information system. Subsets of the data warehouse are extracted as data-marts in advance to use them for research purposes. This technique has been used for general corporate management departments so far been applied to hospital managements and research. This technique also has been utilized to extract indicators for hospital management such as total cost of the hospital, averages for inhospital stay and others. We create infrastructure and environment that suites to use clinical data for research of intractable oral disease. The databases are intended for research use so that we must clear some issues such as access control, including anonymization of medical information. We are able to organize the functional requirements for them. In this talk, we will present the contents focued on database concepts and user interfaces.

1. はじめに

病院情報システムに蓄積された電子データを利用する試みが活発に行われ、それらをどのように活用するかは、国レベルでの検討課題となっている1)。ユーザが利用しやすいようデータウエアハウス（DWH）から、特定の部門で使われそうなデータをあらかじめ抽出してサブセットを作り、データマートとして提供するという考え方が出発点である2)。
しかしながら、これまで発表されてきたデータマートは構造化された入力の仕組みを使うと良い結果が得られるものの、その仕組みを構築することにノウハウが必要なため、データマート作成前に綿密な打合せを必要としていた3)。
大学病院で行われる臨床研究には、当該教室が長期にわたってノウハウを培いつつ行うものと、パイロットスタディとして短期で行うものとがある。すなわち、既存のデータマート構築は前者には向くが、後者では費用を含めた労力の点で取り組みにくい点があった。
そこで、今回はいわゆるビジネスインテリジェンスツール（以下BIツールと略）の匿名化機能、データ結合機能を活用し、後者のケースにも対応出来るデータベースを構築することにした。

2. DWH検索の現状

現有ＤＷＨでは、オーダを含めた診療行為に関連して発生する情報と医事会計システムの情報とを連結して蓄積しているため、検索対象となるテーブルの数が多いことや、そもそもどのテーブルにどのような情報が書かれているかがわかりにくい。一般ユーザがDWHを使うことは想定されていないのである。また、複数診療科にかかっている患者の情報をみだりに集計することは、診療科間で不要な軋轢を生むきっかけとなることもある。
したがって、昔の図書館と同様、検索を専門とする人材をおき、さまざまな調整も同時に行う必要があった。データマートは、これらの課題を克服できるため拡がりつつあるが、まだ一般ユーザにとって敷居が高いのが現実である。例えば、病名での検索を例にとると、現有DWHでは病名コードを確認し、それらをグループとして扱うステップを経るか、病名に含まれる文字列をキーとして集合演算を行う必要がある。

3. 開発の目的

上述のように既存のDWHとデータマートとの組み合わせを、パイロットスタディ的な研究に使うのは労力がかかりすぎてなじまない。また、匿名化処理を行ってしまうと、研究室でローカルに保有している情報を患者と紐づけて蓄積することができなってしまう。
そこで今回は、”現有のDWHに蓄積されたデータを、研究目的で用いる場合に必要とされるインフラストラクチャとユーザインタフェースを提供する。”ことを目的として”口の難病データベース”を設計した。

4. システム構成

図１にシステムの概要を示した。
DWHに蓄積されている医療情報を、必要に応じて研究室で保有している情報と連携させて蓄積できるサーバとそれを検索・集計するためのサーバを別に準備した。このサーバには、研究室から直接アクセスするのではなく、Firewallを通してＤＭＺにおいてあるＢＩツール用サーバを経由してアクセスする。ＢＩツールから、匿名化済みデータを検索でき、同時に検索のログを残すこととした。

5. ユーザインタフェース

図２にユーザインタフェースの一例を示した。
これは複数の病名コードをひとつの検索キーとして扱うためのインタフェースである。日常の診療現場で目にしている病名を選ぶことになるので、わかりやすいというユーザの評価を受けている。このインタフェースは、コード化されてＤＷＨに蓄積されている医療情報を検索する時に使うものである。
一方、診療録等にフリーテキストで入力されている内容も検索の対象として扱えるよう、いわゆる文字列検索も可能とし、そのためのインタフェースも準備した。短期間のパイロットスタディであれば、関係者間でキーワードを共有しておけば、それらを診療録にタグとして埋め込むことで、芋づる式検索が可能となった。

6. データの結合と匿名化

病院情報システムに既に蓄積されている診療情報に対して、各診療科あるいは各研究室で保有している各種情報を連結して追加保存するには、匿名化前の患者実IDがなければならない。リレーションを結ぶ先のデータが匿名化されていては、使用者側のデータを連携できないことは自明である。
一方、各診療科あるいは各研究室で保持している情報を、中央で準備したサーバに無条件でアップロードすることも、診療科側にとってはためらわれることであろう。かといって、患者実IDを保持したままの電子データを研究室へダウンロード可とし、研究室側でのデータ追加を許可するという運用には、研究室側の高いモラルと慎重な対応とが要求される。患者情報の入ったUSBメモリーを紛失した例は枚挙に遑がない。
そこで、BIツールを実装したサーバ上には、検索結果として患者実IDを含んだ検索結果を置き、それらに対して研究室等で保有しているデータを統合した統合化データと、それらのデータを匿名化した匿名化データとを分けて蓄積できる設計とした。
どこの端末からアクセスしてきたかあるいはユーザに割り振る権限によって、統合化データをみせるか、匿名化データを見せるかを切り分ける仕組みである。この形式をとることによって、病院業務遂行の面でもメリットが生まれると考えられる。
すなわち、日常業務で発生する様々な情報を診療録に入力しておくと、あとからその内容をキーワードとして検索可能となることから、様々な局面で患者情報の一次利用として活用されると期待できる。
しかしながら、現在のところBIツールのユーザライセンスを全職員に配布することのリスクについては未評価であることから、今後の課題と考えられる。

7. まとめ

今回のシステムは、当初匿名化済みデータのみを扱うことを前提に設計を進めたが、仕様検討を重ねるうちに、患者実名で検索が行えると診療現場の能率も向上するという意見が出始めた。そこで、ＢＩツールのサーバにどこの端末から検索に来たかで検索対象を実名とするか匿名とするかを切り換えられる仕組みを検討した。
具体的には、病院情報システムの端末からのアクセスに対しては上記の患者実IDを持った情報を見せ、病院の外にあると考えられる研究室の端末からのアクセスに対しては、匿名化済み情報しか見せないし、それしかダウンロードできないということである。
図書館の文献検索が専任サーチャーから一般人へ代わったように、近い将来、医療情報の検索を普通の医局員ができるようになるに違いない。それには、セキュリティの問題を含めてまだ明らかになっていない様々な課題があると予想される。
今後、システムに蓄積されたデータを組織横断的に使えることを目指して、ブラシュアップしていく予定である。