(57)【要約】【課題】異なる形式のデータベースが存在してもこれらの統合データベースを作成する必要がなく、また、データの検索、統計処理等が速やかに行えるようにする。【解決手段】コンピュータを、同じ目的のためにデータベース毎に設けられた異なるテーブルを同種ターゲットとして管理する同種ターゲット用のテーブルと、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を１つの同種列として管理する同種列用のテーブルと、同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、検索条件が入力されると、同種ターゲット用のテーブル、同種列用のテーブル、及びデータ変換ルール用のテーブルに基づき複数のデータベースから実データを検索する検索制御部と、検索した実データを同種データに変換するともに、一時的に記憶するビュー記憶部として機能させる。【選択図】図１
2015170229.tif 000002
【特許請求の範囲】
【請求項１】
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理プログラムにおいて、
コンピュータを、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な１つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な１つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
して機能させることを特徴とする診療データ管理プログラム。
【請求項２】
複数の前記データベースが、異なる世代の医療情報システムによる、異なるデータベースであることを特徴とする請求項１に記載の診療データ管理プログラム。
【請求項３】
複数の前記データベースが、並列して存在する異なる医療情報システムによる、異なるデータベースであることを特徴とする請求項１に記載の診療データ管理プログラム。
【請求項４】
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理システムにおいて、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な１つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な１つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
を備えることを特徴とする診療データ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なる形式で記憶された複数のデータベースのデータを統合して管理する診療データ管理プログラム及び診療データ管理システムに関する。
【背景技術】
【０００２】
従来、複数の病院等によって別個に設けられている電子カルテを統合して管理するものとして、特開２００９−２６６０７７号公報に、診察対象となった患者を、一意に識別可能なシステムＩＤが提示された当該患者の診察内容を含む電子カルテを介して取得し、取得された電子カルテにおける電子カルテ情報の項目を調整した電子カルテ情報にシステムＩＤを対応付けた電子カルテ統合情報を生成して電子カルテ統合ＤＢに格納し、キーワードを提示した電子カルテの閲覧要求を通信ネットワークを介して受け付け、電子カルテ統合ＤＢを参照し、受け付けたキーワードに合致する電子カルテ統合情報を検索し、検索された電子カルテ統合情報に含まれる電子カルテ情報を所定のカテゴリ別に振り分け、振り分けされた電子カルテ情報を閲覧要求元の端末装置に送信する電子カルテ管理サーバが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−２６６０７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１に開示されている技術では、異なるシステムにおける電子カルテのデータを統合するに際し、それぞれのデータを検証して、一定のルールを作成し、該ルールに基づきデータの変換作業を行い、１つの統合データベースに保管し直す必要があった。係る場合、診療データは膨大な量となるため、全ての項目のデータを対象とすることは労力面と金銭面とから現実的ではなく、実際は膨大なデータの一部についてのみ変換作業が行われることが多かった。また、このデータの一部の変換作業においても多大な労力と金銭が必要となっていた。
【０００５】
さらに、統合されたデータを使用するにあたり、当初想定していた項目の範囲を超えてデータが必要となった場合、元のデータを取得し直す必要が生じ、多大な労力と金銭とを要するデータの変換作業を再度行う必要があった。またさらに、電子カルテのデータは年々増大しており、長年のデータを１つの統合データベースへ格納して、そこから検索をしたり統計情報を引き出したりすると、データベースの応答時間が長くなってしまうという課題もあった。
【０００６】
本発明は、上記の点に鑑みなされたもので、電子カルテや各種部門システムのメーカーやシステム自体が変更される等して、異なる形式のデータベースが存在しても、これらの統合データベースを作成する必要がなく、また、データの検索、統計処理、問い合わせが速やかに行える診療データ管理プログラム及び診療データ管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の診療データ管理プログラムは、
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理プログラムにおいて、
コンピュータを、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な１つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な１つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
して機能させることを特徴とする。
【０００８】
本発明の診療データ管理プログラムによれば、同種ターゲット用のテーブルによって、同じ目的のためにデータベース毎に設けられた異なるテーブルを論理的な１つの同種ターゲットとしてまとめて管理することができる。この同じ目的とは、例えば病名に関するもの、処方に関するもの、注射に関するもの等があり、これらの同じ目的のテーブルは、データベース毎に異なるテーブル名となっている。同種ターゲット用のテーブルはこれらの異なるテーブルを、同じ目的という上位概念でまとめて管理するのである。
【０００９】
また、同種列用のテーブルによって、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を論理的な１つの同種列として管理することができる。この同じ意味を持つ列とは、例えば、病名に関するテーブルであれば、病名を示す列、診療科を示す列、担当医師を示す列等であり、処方に関するテーブルであれば、薬品名を示す列、用量を示す列、用法を示す列等であり、注射に関するテーブルでは、薬品名を示す列、投与量を示す列、投与方法を示す列等である。これらの同じ意味を持つ列は、異なるデータベースのテーブル毎に異なる列名となっている。同種列用のテーブルは、これらの列名の異なる複数の列を、同じ意味という上位概念でまとめて管理するのである。
【００１０】
また、データ変換ルール用のテーブルによって、同種列とされた複数の列に記憶されたそれぞれ異なる形式の実データを、統合のための同種データに変換する変換ルールを管理することができる。これは、同種列用のテーブルによって管理される同じ意味を持つ同種列は、その列名を含むデータ形式、データ内容がデータベース毎のテーブルによって異なる。例えば、患者の性別を示す列であれば、あるデータベースのテーブルは列名「ｓｅｉｂｅｔｕ」、データ形式「数字」、データ「０」又は「１」であり、他のデータベースのテーブルは列名「ｓｅｘ」、データ形式「文字」、データ「Ｍ」又は「Ｆ」等である。データ変換ルール用のテーブルは、これらの列の実データのデータ形式とデータを、統合のための同種データのデータ形式とデータに変換するルールを管理するのである。
【００１１】
また、検索制御部によって、所望の検索条件が入力されると、同種ターゲット用のテーブル、同種列用のテーブル、及びデータ変換ルール用のテーブルに基づき複数のデータベースのテーブルの列から、当該データベースに記憶された実データを検索することができる。これは、所望の検索条件が入力されると、同種ターゲット用のテーブル、同種列用のテーブル、及びデータ変換ルール用のテーブルから、検索対象となるデータベース、テーブル、列、データを特定し、必要なデータを検索するのである。なお、このとき検索されたデータは、複数のデータベースから検索されたままの状態である実データである。
【００１２】
また、変換制御部は、実データを、前記同種列用のテーブル、及びデータ変換ルール用のテーブルに基づき、同種データに変換する。例えば、上述の実データである列名「ｓｅｉｂｅｔｕ」、データ形式「数字」、データ「０」又は「１」、及び列名「ｓｅｘ」、データ形式「文字」、データ「Ｍ」又は「Ｆ」を、同種データの一例である列名「性別」、データ形式「文字」、データ「男」又は「女」に変換する等である。なお、同種データとは、実データを統合のために所定の列名、データ形式、データに変換処理したデータ、又は変換処理を行ったが実データと同種データが同じであって変換が不要であったデータを意図する。また、変換制御部は、上記変換した同種データをそのまま又は所定の形式の、表示用のデータであるビューデータとすることができる。
【００１３】
また、ビュー記憶部は、変換制御部によって作成されたビューデータを、一時的に記憶する。このビュー記憶部は、複数のデータベースから検索され変換されたデータ全てを長い期間記憶する必要がなく、ビューデータのみを一時的に記憶できればよい。したがって、その都度必要なビューデータを記憶できる容量があればよく、システムの簡素化とコストダウンを図ることができる。また、表示部は、ビュー記憶部に記憶されたビューデータを、視覚的な情報として、所定の形式で表示させる。
【００１４】
本発明の診療データ管理プログラムの好ましい例は、
複数の前記データベースが、異なる世代の医療情報システムによる、異なるデータベースであることを特徴とする。
【００１５】
本発明の診療データ管理プログラムの好ましい例は、
複数の前記データベースが、並列して存在する異なる医療情報システムによる、異なるデータベースであることを特徴とする。
【００１６】
これら本発明の診療データ管理プログラムの好ましい例によれば、異なる世代の医療情報システムによる、又は並列して存在する異なる医療情報システムによる、異なるデータベースを統合して管理することができ、ある医療機関で医療情報システムのメーカーが変わっても、又は離れた場所にある医療機関同士でも、複数のデータベースのデータを統合してデータの検索等を行うことができる。
【００１７】
本発明の診療データ管理システムは、
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理システムにおいて、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な１つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な１つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
を備えることを特徴とする。
【００１８】
本発明の診療データ管理システムによれば、上述した理由により、診療データ管理プログラムと同様の作用効果を奏することができる。
【発明の効果】
【００１９】
以上説明したように、本発明によれば、電子カルテや各種部門システムのメーカーや種類が変更される等して、異なる形式のデータベースが存在しても、これらの統合データベースを作成する必要がなく、また、データの検索、統計処理、問い合わせが速やかに行える診療データ管理プログラム及び診療データ管理システムを提供することができる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施形態に係る診療データシステムの構成を示す機能ブロック図である。
【図２】異なる医療情報システムにおいて、同じ目的のために設けられた異なるテーブルを説明する図である。
【図３】同種ターゲットと同種列の概念を説明する図である。
【図４】同種ターゲット用のテーブルを説明する図である。
【図５】同種列用のテーブルを説明する図である。
【図６】データ変換ルール用のテーブルを説明する図である。
【図７】薬名マスタテーブル、ターゲットマスタテーブルを説明する図である。
【図８】データの検索と変換によってビューデータが作成される過程を説明する図である。
【図９】複数のデータベースからデータの検索と変換をする全体の処理を説明するフロー図である。
【図１０】検索条件の入力と、実データを検索するために必要となる情報の取得の処理を説明するフロー図である。
【図１１】実データの検索の処理を説明するフロー図である。
【図１２】実データを同種データに変換する処理を説明するフロー図である。
【図１３】ビューデータの作成の処理を説明するフロー図である。
【発明を実施するための形態】
【００２１】
以下、本発明の診療データ管理システムの実施の形態について、添付図面を参照して詳細に説明する。なお、本発明に係る診療データ管理プログラムは、コンピュータに本発明に係る診療データ管理システムを実行させるためのものである。
【００２２】
図１は本発明の一実施形態に係る診療データシステムの構成を示す機能ブロック図、図２は異なる医療情報システムにおいて、同じ目的のために設けられた異なるテーブルを説明する図、図３は同種ターゲットと同種列の概念を説明する図、図４は同種ターゲット用のテーブルを説明する図、図５は同種列用のテーブルを説明する図、図６はデータ変換ルール用のテーブルを説明する図、図７は薬名マスタテーブル、ターゲットマスタテーブルを説明する図である。
【００２３】
先ず、本実施形態の診療データ管理システム１の概要を説明する。図１に示すように、本実施形態の診療データ管理システム１には、異なる世代の医療情報システムによる、又は並列して存在する異なる医療情報システムによる、異なるデータベース１００，２００が接続されている。この異なるデータベース１００，２００に設けられたテーブルとして、例えば、図２（Ａ）に示すように、医療情報システムＡのデータベースには、病名を管理する目的のための病名オーダーテーブルと、処方を管理する目的のための処方オーダーテーブルが設けられている。また、図２（Ｂ）に示すように、医療情報システムＢのデータベースにも、病名を管理する目的のための検索用診療記録病名テーブルと、処方を管理する目的のための検索用処方テーブルが設けられている。これらのテーブルでは、同じ目的のテーブルであっても、医療情報システムが異なるため、テーブル名が異なっている。
【００２４】
また、上記テーブルのうち同じ意味を持つ列であっても、その列名、データ形式、データの内容が異なっている。例えば、患者の性別を示す列であれば、図２（Ａ）に示す医療情報システムＡの、病名オーダーテーブルと処方オーダーテーブルは、列名「ｓｅｉｂｅｔｕ」、データ形式「数字」、データ「０」又は「１」であり、図２（Ｂ）に示す医療情報システムＢの、検索用診療記録病名テーブルと検索用処方テーブルは、列名「ｓｅｘ」、データ形式「文字」、データ「Ｍ」又は「Ｆ」等である。このように、医療情報システムが異なれば、同じ目的のテーブル、同じ意味を持つ列であっても、そのデータ形式やデータの内容が異なり、そのままではまとめて検索等することができない。
【００２５】
本実施形態の診療データ管理システム１は、これらの目的は同じだが異なるテーブルを、論理的な１つの同種ターゲットとして、また、同じ意味を持つ列を同種列として、まとめて管理するのである。ここでは、例として病名を目的とする同種ターゲットと該同種ターゲットに係る同種列、及び処方を目的とする同種ターゲットと該同種ターゲットに係る同種列を説明する。図３（Ａ）に示す、病名を目的とする同種ターゲットでは、医療情報システムＡの病名オーダーテーブルと医療情報システムＢの検索用診療記録病名テーブルがまとめられている。また、図３（Ｂ）に示す、処方を目的とする同種ターゲットでは、医療情報システムＡの処方オーダーテーブルと医療情報システムＢの検索用処方テーブルがまとめられている。
【００２６】
また、図３（Ａ）（Ｂ）において、これらのテーブルの上側に、説明のための同種列を記載している。この同種列とは、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を、論理的な１つの列としてまとめて管理するもので、図中の矢印線で示すように、同種列「患者ＩＤ」は、「ｋａｎｊｙａＩＤ」と「患者番号」の列を同じ意味を持つ列としてまとめて管理し、同種列「性別」は「ｓｅｉｂｅｔｕ」と「ｓｅｘ」の列を同じ意味を持つ列としてまとめて管理するのである。なお、同種ターゲットが異なれば、同種列の内容も異なる。
【００２７】
また、同種列としてまとめられた列も、テーブルが異なればそのデータ形式とデータが異なる。これらの異なるデータ形式とデータは、データ変換ルールを用いて、統合のためのデータへ変換されるのである。
【００２８】
図１に戻り、本実施形態の診療データ管理システム１の構成を説明する。図１に示すように、本実施形態の診療データ管理システム１は、入力部１０と、記憶部２０と、制御部１１と、表示部１４とを備える。
【００２９】
なお、接続されている複数のデータベース１００，２００に記憶されている元データ、又は複数のデータベース１００，２００から検索し抽出されているが変換処理されず元データの状態のままの形式である列名とデータとを、便宜上、実データと呼ぶ。また、実データを統合のためにその列名、データ形式、データの内容を変換処理したデータ、又は変換処理したが変換する必要がなかったデータを同種データという。
【００３０】
入力部１０は、公知のキーボード、マウス、タッチパネル、トラックボール等の入力機器を備え、これらの機器から所望の検索条件を入力することができる。
【００３１】
記憶部２０は、公知のハードディスクドライブ、半導体記憶装置等から構成され、その内部に、同種ターゲット用のテーブル２１、同種列用のテーブル２２、データ変換ルール用のテーブル２３、各種マスタテーブル２４、ビュー記憶部２５を備える。また、記憶部２０には、本実施形態の診療データ管理システム１を実現するために実行される診療データ管理プログラムやオペレーティングシステムが記憶され、その他コンピュータの動作に必要な記憶領域が設けられる。
【００３２】
同種ターゲット用のテーブル２１は、異なる医療情報システムの異なる形式で記憶されたデータベース１００，２００において、同じ目的のために前記データベース毎に設けられた異なるテーブルを論理的な１つの同種ターゲットとしてまとめて管理するためのもので、図４（Ａ）に示す同種ターゲットテーブルと、図４（Ｂ）に示す同種ターゲット管理テーブルを備える。同種ターゲットテーブルは「同種ターゲットＩＤ」と「表示名」の項目（列）を、同種ターゲット管理テーブルは「同種ターゲットＩＤ」と「ターゲットＩＤ」の項目を有する。なお、同種ターゲット用のテーブルを、同種ターゲットテーブルと同種ターゲット管理テーブルの２つに分けているのは、管理をし易くするためであり、１つのテーブルにまとめてもよいし、他の項目を追加して３つ以上のテーブルとしてもよい。
【００３３】
同種ターゲットテーブルの項目に設けられている同種ターゲットＩＤは、同じ目的のテーブル毎に設定されるＩＤであり、表示名は、その目的を表わす名前を上位概念として設定するものである。ここでは同種ターゲットＩＤ「１」が表示名「病名」に、同じく「２」が「処方」に設定されている。
【００３４】
また、同種ターゲット管理テーブルの項目に設けられているターゲットＩＤは、複数のデータベースにそれぞれ設けられたテーブルを特定するためのＩＤである。つまり、同種ターゲットテーブルと同種ターゲット管理テーブルにより、同種ターゲットＩＤ「１」に設定された同種ターゲットは、「病名」を示す目的のテーブルであり、この病名を目的とするテーブルはターゲットＩＤ「Ａ−１」と「Ｂ−５」で示されるテーブルであるということがわかる。同様に、同種ターゲットＩＤ「２」は、「処方」を目的とし、そのテーブルはターゲットＩＤ「Ａ−８」と「Ｂ−３」で示されるテーブルであることがわかる。
【００３５】
同種列用のテーブル２２は、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を論理的な１つの同種列としてまとめて管理するもので、図５（Ａ）に示す同種列テーブルと、図５（Ｂ）に示す同種列管理テーブルを備える。同種列テーブルは「同種列ＩＤ」と「同種ターゲットＩＤ」と「表示名」と「データ形式」の項目を、同種列管理テーブルは「同種列ＩＤ」と「ターゲットＩＤ」と「列名」と「データ変換」と「データ変換ルールＩＤ」の項目を有する。なお、同種列用のテーブルを、同種列テーブルと同種列管理テーブルの２つに分けているのは、管理をし易くするためであり、１つのテーブルにまとめても、あるいは３つ以上のテーブルに分けてもよい。
【００３６】
同種列テーブルの項目に設けられている同種列ＩＤは、同じ意味を持つ列をまとめた同種列毎に設定されるＩＤである。また、同種ターゲットＩＤは、既に説明したように、同じ目的のためのテーブル毎に設定されるＩＤである。表示名は、同種列ＩＤ毎に設定され、同種列とされた列のデータを表示するときに表示される列名である。また、データ形式は、同じく同種列ＩＤ毎に設定され、同種列とされた列のデータを表示するときに使用されるデータ形式である。ここでは、病名を目的とするテーブルである同種ターゲットＩＤ「１」は、その項目として同種列ＩＤを「１」から「６」まで備え、それぞれの同種列ＩＤに表示名とデータ形式が設定されている。つまり、同種列ＩＤ「１」は、同種ターゲットＩＤ「１」のテーブルの列のうち、「患者ＩＤ」の意味を持つ列をまとめるためのもので、そのデータ形式は「数字形」であり、同種列ＩＤ「２」は、同種ターゲットＩＤ「１」のテーブルの列のうち、「性別」の意味を持つ列をまとめるためのもので、そのデータ形式は「文字型」であることがわかる。同様に、処方を示すテーブルである同種ターゲットＩＤ「２」は、その項目に同種列ＩＤを「７」から「１２」まで備え、それぞれの同種列ＩＤに表示名とデータ形式が設定されていることがわかる。
【００３７】
同種列管理テーブルの項目に設けられている同種列ＩＤ、ターゲットＩＤは、既に述べたとおりである。列名の項目は、ターゲットＩＤによって特定されたテーブルの中の、同じ意味を持つ列を特定するためのものであり、その列に実際に使用されている実データの列名が記憶される。また、データ変換の項目は、特定した列に記憶されている実データを変換する必要があるか否かを記憶しており、そのデータが「Ｙ」ならばデータ変換が必要、「Ｎ」ならばデータ変換が不要である。また、データ変換ルールＩＤの項目は、データ変換する必要がある実データをどのように同種データに変換するかのルールを特定するためのＩＤが記憶されている。ここでは、同種列ＩＤが「２」「８」「１１」に係るデータの変換が必要であることがわかる。例えば、同種列ＩＤ「２」でまとめられた列は、ターゲットＩＤ「Ａ−１」と「Ｂ−５」で示されるテーブルの、列名「ｓｅｉｂｅｔｕ」と「ｓｅｘ」で表された列であり、これらの列に記憶されたデータはデータ変換が必要で、そのデータ変換ルールＩＤは「１」と「２」であることがわかる。
【００３８】
データ変換ルール用のテーブル２３は、同種列とされた複数の列の実データを、統合のための同種データに変換する変換ルールを管理するもので、ここでは図６（Ａ）に示すデータ変換ルールテーブルと、図６（Ｂ）に示すデータ変換ルール詳細テーブルを備える。データ変換ルールテーブルは「データ変換ルールＩＤ」と「名称」の項目を、データ変換ルール詳細テーブルは「データ変換ルールＩＤ」と「同種データ」と「実データ」の項目を有する。なお、データ変換ルール用のテーブルを、データ変換ルールテーブルとデータ変換ルール詳細テーブルの２つに分けているのは、管理をし易くするためであり、１つのテーブルにまとめても、あるいは３つ以上のテーブルに分けてもよい。
【００３９】
データ変換ルールテーブルの項目に設けられているデータ変換ルールＩＤは、既に述べたように、データ変換する必要がある実データをどのように同種データに変換するかのルールを特定するためのものである。また、名称の項目は、変換する実データがどの医療情報システムのどのような意味のデータであるかを示すものである。
【００４０】
データ変換ルール詳細テーブルの項目に設けられているデータ変換ルールＩＤは上述の通りである。また、同種データの項目は、実データをどのように変換するかが記憶されており、実データの項目は、変換する前のデータが記憶されている。ここでは、データ変換ルールＩＤ「１」と「３」は、実データが「０」又は「１」であるとき、それを同種データの「男」又は「女」に変換し、データ変換ルールＩＤ「２」と「４」は、実データが「Ｍ」又は「Ｆ」であるとき、それを同種データの「男」又は「女」に変換することがわかる。同様に、データ変換ルールＩＤ「５」は、実データが「Ｋ１００」「Ｋ１０１」・・・というコードであるとき、それを同種データである「アシニン」「イシニン」・・・という薬名に変換し、データ変換ルールＩＤ「６」は、実データが「Ｍ１０００」「Ｍ１００１」・・・というコードであるとき、それを同種データである「アシニン」「イシニン」・・・という薬名に変換することがわかる。
【００４１】
各種マスタテーブル２４は、固定的で基本的なデータを記憶させるもので、例として図７（Ａ）に示す薬名マスタテーブル、図７（Ｂ）に示すターゲットマスタテーブルがある。薬名マスタテーブルは、同種データにおける薬名を記憶しておくもので、ここでは「アシニン」「イシニン」・・・という薬名が記憶されている。
【００４２】
ターゲットマスタテーブルは、上述のターゲットＩＤが実際にどの医療情報システムのどのデーブルを示すものかを記憶するテーブルで、「ターゲットＩＤ」と「システム名称」と「テーブル名称」の項目を有する。ターゲットＩＤは既に説明したとおりである。システム名称の項目は、ターゲットＩＤが示すテーブルが、医療情報システムＡと医療情報システムＢのどちらのシステムであるかを記憶している。また、テーブル名称の項目は、医療情報システムのデータベースに設けられた実際のテーブルの名称を記憶している。ここでは、ターゲットＩＤ「Ａ−１」で示されるテーブルは、「医療情報システムＡ」の「病名オーダー」というテーブルであり、また、ターゲットＩＤ「Ａ−２」で示されるテーブルは、「医療情報システムＡ」の「放射線オーダー」というテーブルであることがわかる。なお、ターゲットマスタテーブルは、ここでは各種マスタテーブルの一例として説明したが、同種ターゲット用のテーブルに含めてもよい。
【００４３】
図１に戻り、ビュー記憶部２５は、後述するビューデータを一時的に記憶するための領域である。この一時的とは、ビューデータを本実施形態の診療データ管理システム１が運用され続けられる限り記憶するものではないという意味であり、表示部１４によるビューデータの表示が終われば、ビュー記憶部２５からビューデータを直ちに削除してもよいし、ビュー記憶部２５の容量に余裕があれば、過去の検索履歴のビューデータを所定の期間保存しておいてもよい。
【００４４】
制御部１１は、ＣＰＵ、半導体による補助メモリ等で実現されるもので、検索制御部１２と、変換制御部１３とを備える。
【００４５】
検索制御部１２は、所望の検索条件が入力部１０より入力されると、同種ターゲット用のテーブル２１、同種列用のテーブル２２、及びデータ変換ルール用のテーブル２３に基づき、検索対象となるデータベース１００，２００毎に設けられたテーブルと列とを特定し、それぞれのデータベースから実データを検索する。具体的な手順としては、検索したい同種ターゲット、当該同種ターゲットの同種列、及び当該同種列の同種データ等が入力部１０により入力されると、同種ターゲットとしてまとめられた複数のテーブルの、同種列としてまとめられた複数の列から、同種データに対応する実データを検索し、必要とされる範囲のデータ、例えば当該実データを含むレコードを選択し、実データによる新たなテーブル（以下、「実データテーブル」という。）を、同種ターゲットとしてまとめられた複数のテーブル毎に作成するのである。
【００４６】
変換制御部１３は、検索した実データテーブルを、データ変換ルール用のテーブルに基づき同種データによるテーブル（以下、「同種データテーブル」という。）に変換する。具体的な手順は、同種列管理テーブルにより、実データテーブルの列名を含む実データを変換する必要があるか否か、変換する必要があるならばどのデータ変換ルールＩＤによって変換するかを判断する。次に、データ変換ルール用のテーブル２３に基づき変換する必要のある実データは変換し、変換する必要の無い実データはそのままとする変換処理を行う。そして、変換処理したデータにより同種データテーブルを作成するのである。
【００４７】
また、複数のデータベース１００，２００から検索され作成された実データテーブルから変換された同種データテーブルは、原則として異なる医療情報システムのデータベースの数ほど存在する。これらの複数の同種データテーブルは、変換制御部１３により表示用のデータとして１つのテーブルである、ビューデータにまとめられる。また、このビューデータは、まとめられたテーブルのうち、所望の項目のみ表示させることもできる。
【００４８】
表示部１４は、公知のディスプレイ装置等を備え、入力部１０により入力された検索条件、ビュー記憶部２５に記憶されたビューデータ等を視覚的な情報として表示させる。
【００４９】
次に、以上説明した各構成要素の機能を踏まえて、本実施形態の診療データ管理システム１の動作について図２〜図１３を参照して説明する。図２〜図７は既に説明したとおりである。図８はデータの検索と変換によってビューデータが作成される過程を説明する図である。また、図９は複数のデータベースからデータの検索と変換をする全体の処理を説明するフロー図、図１０は検索条件の入力と、実データを検索するために必要となる情報の取得の処理を説明するフロー図、図１１は実データの検索の処理を説明するフロー図、図１２は実データを同種データに変換する処理を説明するフロー図、図１３はビューデータの作成の処理を説明するフロー図である。
【００５０】
先ず、図９を参照して、本実施形態の診療データ管理システム１による、複数のデータベース１００，２００から実データを検索し、検索した実データを同種データに変換し、さらにビューデータとして表示する全体の処理を説明する。
【００５１】
本実施形態の診療データ管理システム１による処理が開始されると、表示部１４により検索条件の入力を受け付ける画面が表示され、操作者が入力部１０を操作することにより検索条件が入力される。また、検索条件の入力とともに、実データの検索に必要となる同種ターゲットＩＤ、ターゲットＩＤ、同種列ＩＤが取得される（Ｓ１０００）。次に、取得された同種ターゲットＩＤ、ターゲットＩＤ、同種列ＩＤを基に、複数の医療情報システムのデータベースから実データを検索する（Ｓ２０００）。次に、検索した実データを同種データに変換する（Ｓ３０００）。次に、変換された１つ以上の同種データから、ビューデータを作成する（Ｓ４０００）。そして、表示部１４によりビューデータを視覚的な情報として表示する（Ｓ５０００）。
【００５２】
次に、図９〜図１３に示すフロー図を参照して本実施形態の診療データ管理システム１による処理の各ステップを詳細に説明しながら、図２〜８に示すテーブルを参照してデータの検索と変換の具体例を説明する。
【００５３】
図１０に示す、ステップＳ１０００の検索条件の入力と、同種ターゲットＩＤ、ターゲットＩＤ、同種列ＩＤの取得では、先ず、検索制御部１２により、同種ターゲットテーブル（図４（Ａ））の表示名の項目が参照され、検索対象とする同種ターゲットを決定するための同種ターゲットの表示名の入力画面が表示される（Ｓ１０１０）。次に、入力部１０により、検索する同種ターゲットの表示名、例えば「処方」が入力される（Ｓ１０２０）。すると、検索制御部１２により、同種ターゲットテーブルから表示名「処方」の同種ターゲットＩＤ「２」が取得され（Ｓ１０３０）、さらに、同種ターゲット管理テーブル（図４（Ｂ））から、同種ターゲットＩＤ「２」を基に、データベース毎に設けられた異なるテーブルを示すターゲットＩＤ「Ａ−８」「Ｂ−３」が取得される（Ｓ１０４０）。
【００５４】
次に、検索対象とする同種列を決定するために、同種列テーブル（図５（Ａ））の表示名の項目のうち、上記で取得した同種ターゲットＩＤ「２」に係るレコード（図中「ａ」で示すレコード）の表示名である「患者ＩＤ」「性別」「依頼科」・・・を入力する同種列の表示名入力画面が表示される（Ｓ１０５０）。次に、入力部１０により、検索する同種列の表示名、例えば「薬名」が入力される（Ｓ１０６０）。すると、検索制御部１２により、同種列テーブルから表示名「薬名」の同種列ＩＤ「１１」が取得される（図中「ｂ」で示すレコード）（Ｓ１０７０）。
【００５５】
次に、取得した同種列ＩＤ「１１」の同種データの名称を記憶した、図７（Ａ）に示す薬名マスタの同種データの項目が参照され、検索対象とする同種データを決定するために、同種データを入力する同種データ入力画面が表示される（Ｓ１０８０）。次に、入力部１０により検索する同種データ、例えば「イシニン」が入力される（Ｓ１０９０）。これらの処理により、「処方」「薬名」「イシニン」という検索条件の入力と、同種ターゲットＩＤ「２」、ターゲットＩＤ「Ａ−８」「Ｂ−３」、同種列ＩＤ「１１」の取得がなされる。なお、ステップＳ１０７０で取得した同種列ＩＤに係るデータの変換が必要ない場合（取得した同種列ＩＤに対応する、同種列管理テーブルのデータ変換の項目が「Ｎ」の場合。）は、ステップＳ１０８０では実データのマスタを参照して表示してもよい。また、ここでは薬名マスタを参照して「イシニン」という薬名を検索条件として選択したが、例えば、検索対象が検査値である場合、数字で所望の値の範囲等を指定することや、検査結果が陽性か陰性かといった検索条件を設定することもできる。
【００５６】
次に、図１１に示す、ステップＳ２０００の実データの検索では、検索制御部１２により、検索対象とするテーブルの列が特定される（Ｓ２０１０）。具体的には、ステップＳ１０７０で取得した同種列ＩＤ「１１」を基に、同種列管理テーブル（図５（Ｂ））の同種列ＩＤ「１１」に係るレコード（図中「ｃ」で示すレコード）を参照する。そして、列名の項目からステップＳ１０４０で取得したターゲットＩＤ「Ａ−８」「Ｂ−３」に対応する「ｙａｋｕｚａｉｍｅｉｓｙｏｕ」「薬品番号」を取得する。これにより、ターゲットＩＤ「Ａ−８」のテーブルの「ｙａｋｕｚａｉｍｅｉｓｙｏｕ」の列、及びターゲットＩＤ「Ｂ−３」のテーブルの「薬品番号」の列を検索対象として特定することができる。
【００５７】
次に、検索制御部１２により、ステップＳ１０９０で入力された同種データが実データと同じか否かが判断される（Ｓ２０２０）。ここでは、同種列管理テーブルのデータ変換の項目のうち、既に取得した同種列ＩＤ「１１」、及びターゲットＩＤ「Ａ−８」「Ｂ−３」のレコードが参照される（図中「ｃ」で示すレコード）。ここでデータが「Ｙ」ならば入力された同種データと実データは異なり、「Ｎ」ならば入力された同種データと実データとは同じである。入力された同種データと実データが異なる場合、同種データを検索キーとしても実データは検索できないため、検索キーとなる実データを取得する必要がある。この手順としては、先ず、同種列管理テーブルのデータ変換ルールＩＤの項目から、データ変換ルールＩＤが取得される（Ｓ２０３０）。ここでは、同種列ＩＤ「１１」のレコードのデータ変換の項目は「Ｙ」となっており、同種データと実データが異なりデータ変換が必要であることがわかるとともに、データ変換ルールＩＤの項目からデータ変換ルールＩＤ「５」「６」が取得される。
【００５８】
次に、検索制御部１２により、同種データを基に検索キーとなる実データを取得する処理がなされる（Ｓ２０４０）。これは、ステップＳ２０３０で取得したデータ変換ルールＩＤ「５」「６」を基に、データ変換ルール詳細テーブル（図６（Ｂ））の、データ変換ルールＩＤ「５」と「６」に係るレコード（図中「ｄ」で示すレコード）の同種データの項目の中から検索条件となっている「イシニン」を検索する。そして、実データの項目のうち「イシニン」を含むレコードから検索キーとなる実データとして、データ変換ルールＩＤ「５」については「Ｋ１０１」を、データ変換ルールＩＤ「６」については「Ｍ１００１」を取得するのである。つまり、ステップＳ２０１０からステップＳ２０４０の処理により、ターゲットＩＤ「Ａ−８」については列名「ｙａｋｕｚａｉｍｅｉｓｙｏｕ」及び検索キーとなる実データ「Ｋ１０１」が、ターゲットＩＤ「Ｂ−３」については列名「薬品番号」及び検索キーとなる実データ「Ｍ１００１」が取得される。なお、上記ステップＳ２０２０で、データ変換の項目が「Ｎ」であった場合、同種データは実データと同じであり、同種データそのものを検索キーとすることができるため、ステップＳ２０３０とステップＳ２０４０の処理はスキップされる。
【００５９】
次に、検索制御部１２により、既に取得したターゲットＩＤ、列名、検索キーとなる実データ又は同種データを基に、複数のデータベースから実データに係るレコードを検索する処理を行う（Ｓ２０５０）。これは、先ず、ターゲットマスタテーブル（図７（Ｂ））を参照し、ターゲットＩＤ「Ａ−８」に対応する医療情報システムとテーブルを特定する。ここでは、ターゲットＩＤ「Ａ−８」に対応する医療情報システムとテーブルは、「システムＡ」の「処方オーダー」であることがわかる（図中「ｅ」で示すレコード）。そして、図２（Ａ）に示す医療情報システムＡの「処方オーダー」テーブルの項目「ｙａｋｕｚａｉｍｅｉｓｙｏｕ」から、検索キーとなる実データ「Ｋ１０１」を検索し、該当するレコードを抽出する。そして、図８（Ｂ）に示す実データテーブルを作成する（Ｓ２０６０）。
【００６０】
同じく、ターゲットＩＤ「Ｂ−３」についても、ターゲットマスタテーブルからターゲットＩＤ「Ｂ−３」に対応する医療情報システムとテーブルは、「システムＢ」の「検索用処方」であることがわかる（図中「ｆ」で示すレコード）。そして、図２（Ｂ）に示す医療情報システムＢの「検索用処方」テーブルの項目「薬品番号」から、検索キーとなる実データ「Ｍ１００１」を検索し、該当するレコードを抽出し、図８（Ｄ）に示す実データテーブルを作成する。このようにして、実データの検索の処理と、実データテーブルの作成がなされる。
【００６１】
次に、図１２に示す、ステップＳ３０００の実データを同種データに変換では、変換制御部１３により、上記で作成された実データテーブルを同種データテーブルに変換する。先ず、同種データテーブルに変換されていない実データテーブルを選択する（Ｓ３０１０）。ここでは、図８（Ｂ）に示すターゲットＩＤ「Ａ−８」から検索された実データテーブル（以下「Ａ−８実データテーブル」という）を選択する。次に、実データテーブルの変換処理されていない列を選択し、その同種列ＩＤ、データ変換の有無、データ変換ルールＩＤを取得する（Ｓ３０２０）。ここでは、Ａ−８実データテーブルの処理されていない列のうち最初の列「ｋａｉｓｈｉｂｉ」を選択し、ターゲットＩＤ「Ａ−８」及び列名「ｋａｉｓｈｉｂｉ」を基に同種列管理テーブル（図５（Ｂ））を参照し（図中「ｇ」で示すレコード）、同種列ＩＤ「１０」、データ変換「Ｎ」、データ変換ルールＩＤ「無し」を取得する。次に、同種列の表示名を取得し、元の列名を表示名に変換する（Ｓ３０３０）。ここでは、既に取得した同種列ＩＤ「１０」を基に、同種列テーブル（図５（Ａ））を参照し（図中「ｈ」で示すレコード）、表示名「処方開始日」とデータ形式「日付型」を取得し、Ａ−８実データテーブルの最初の列名「ｋａｉｓｈｉｂｉ」を、取得した表示名「処方開始日」に変換する。
【００６２】
次に、ステップＳ３０２０で取得した、データ変換「Ｎ」、データ変換ルールＩＤ「無し」を基に「処方開始日」の列のデータ変換が必要か否かが判断される（Ｓ３０４０）。ここでは、データ変換が必要ないため、Ａ−８実データテーブルの列名「処方開始日」の列のデータはそのまま何もされず、後述するステップＳ３０５０とステップＳ３０６０はスキップされる。
【００６３】
次に、Ａ−８実データテーブルの変換処理していない残りの列があるか否かが判断される（Ｓ３０７０）。ここでは、列「ｋａｎｊｙａＩＤ」があるため、この列も上記ステップＳ３０２０からステップＳ３０４０の処理が行われ、列名が「患者ＩＤ」に変更されるとともに、当該列のデータはそのまま変更されない。
【００６４】
次に、同じく繰り返し処理がなされ、ステップＳ３０２０で、Ａ−８実データテーブルの列「ｓｅｉｂｅｔｕ」が選択され、同種列管理テーブル（図５（Ｂ））から同種列ＩＤ「８」、データ変換「Ｙ」、データ変換ルールＩＤ「３」が取得される（図中「ｉ」で示すレコード）。次に、ステップＳ３０３０で、同種列テーブル（図５（Ａ））から同種列ＩＤ「８」のレコード（図中「ｊ」で示すレコード）が選択され、表示名「性別」とデータ形式「文字型」が取得され、Ａ−８実データテーブルの列名「ｓｅｉｂｅｔｕ」が、取得した表示名「性別」に変換される。
【００６５】
次に、ステップＳ３０４０で、データ変換が必要か否かが判断される。ここでは上記ステップＳ３０２０で取得されたデータ変換の項目データが「Ｙ」のため、データ変換が必要と判断される。次に、既に取得したデータ変換ルールＩＤ「３」を基に、データ変換ルール詳細テーブル（図６（Ｂ））を参照し、該当するレコード（図中「ｋ」で示すレコード）を選択し、同種データの項目と実データの項目からデータの変換ルールを取得する（Ｓ３０５０）。そして、取得した変換ルールとデータ形式に従い、実データを同種データに変換する（Ｓ３０６０）。ここでは、Ａ−８実データテーブルの「性別」の列の実データ「０」を同種データ「男」データ形式「文字型」に、実データ「１」を同種データ「女」データ形式「文字型」に変換する。これらのステップＳ３０２０からステップＳ３０７０を繰り返すことにより、Ａ−８実データテーブルの全ての列名と実データが処理され、図８（Ｃ）に示す、Ａ−８同種データテーブルへと変換される。
【００６６】
次に、他に変換されていない実データテーブルがあるか否かが判断される（Ｓ３０８０）。ここでは、図８（Ｄ）に示すターゲットＩＤ「Ｂ−３」から作成された実データテーブル（以下、「Ｂ−３実データテーブル」という。）があり、ステップＳ３０１０に戻り、Ｂ−３実データテーブルが選択され、上述したステップＳ３０２０からステップＳ３０７０の処理が繰り返されることで、図８（Ｅ）に示す、Ｂ−３同種データテーブルへと変換される。なお、列名が同種列の表示名（図５（Ａ）の表示名の項目）に変換されるのをわかりやすくするため、図８（Ａ）に同種列の表示名を示している。
【００６７】
次に、図１３に示す、ステップＳ４０００のビューデータの作成では、変換制御部１３により、上記ステップＳ３０００からステップＳ３０８０までの処理によって作成された同種データテーブルが複数あるか否かが判断される（Ｓ４０１０）。同種データテーブルが複数ある場合、変換制御部１３は、複数の同種データテーブルを一つのテーブルに統合しビューデータを作成する（Ｓ４０２０）。ここでは、Ａ−８同種データテーブルとＢ−３同種データテーブルがあり、これらを統合するとともに、項目の順番を図８（Ａ）に示す同種列と同じように並び替えて、図８（Ｆ）に示すビューデータテーブルを作成する。そして、作成したビューデータテーブルをビューデータとしてビュー記憶部２５に記憶させる（Ｓ４０３０）。一方、同種データテーブルが一つの場合、その同種データテーブル自体がビューデータとなるため、同種データテーブルの統合はなされず、項目の順番の並び替えのみが行われる。なお、ビューデータとしては、統合したテーブルのうち、所望の項目のみ抽出することもできる。
【００６８】
次に、図９のステップＳ５０００に示すように、表示部１４によりビューデータが視覚的な情報として表示される。そして、操作者による閲覧等が終了し、表示されなくなったビューデータは、直ちにビュー記憶部２５から削除してもよいし、ビュー記憶部２５の容量に余裕がれば所定の期間、過去の検索データとして残してもよい。
【００６９】
以上、述べたように、本発明の診療データ管理プログラム及び診療データ管理システムによれば、電子カルテや各種部門システムのメーカーやシステム自体が変更される等して、異なる形式のデータベースが存在しても、これらの統合データベースを作成する必要がなく、統合データベースを作成するための多大な労力と金銭が不要となるとともに、コンピュータ資源を節約することができる。また、複数のデータベースから全てのデータを網羅して統合データベースを作成することは一般的に困難であり、一部のデータは統合データベースに組み込まれず、バックアップ用のストレージ等のみに残されることが多々あったが、本発明の診療データ管理プログラム及び診療データ管理システムによれば、統合データベースを作成する必要がないため、元のデータベースをそのまま残して運用することが可能であり、データの保全にも有利である。
【００７０】
また、データの検索等のおいて、その都度必要な範囲のみの処理を行うため、データの検索、統計処理、問い合わせが速やかに行えるとともに、システム自体の負荷を低減させることができる。
【００７１】
また、本発明の診療データ管理プログラム及び診療データ管理システムを運用中に、再度電子カルテや各種部門システムのメーカーやシステム自体が変更されたり、他の病院等と合併等したりしてデータベースの数が増えても、同種ターゲット用のテーブル、同種列用のテーブル、データ変換ルール用のテーブル等のメンテナンスで対応することができ、新たな統合データベースを作成する必要がなく、将来にわたってコストを抑えた柔軟な対応をすることができる。
【００７２】
なお、上述した診療データ管理プログラム及び診療データ管理システムは、本発明の例示であり、発明の趣旨を逸脱しない範囲でその構成を適宜変更することができる。例えば、処理の結果が同じであれば、上述の処理のフローの順番を一部入れ替えることもできる。また、データの変換処理において、実データテーブルをそのまま残して、別途同種データテーブルを作成することもできる。また、検索条件の入力では、所望の検索条件をキーボード等から直接テキストデータで入力してもよいし、プルダウンメニュー等を用いて複数の候補から選択するようにする等、様々な入力方法を採用することができる。
【符号の説明】
【００７３】
１・・診療データ管理システム、
１０・・入力部、１１・・制御部、１２・・検索制御部、１３・・変換制御部、１４・・表示部
２０・・記憶部、２１・・同種ターゲット用のテーブル、２２・・同種列用のテーブル、２３・・データ変換ルール用のテーブル、２４・・各種マスタテーブル、２５・・ビュー記憶部、
１００，２００・・データベース、
【図１】
2015170229.tif 000003
【図２】
2015170229.tif 000004
【図３】
2015170229.tif 000005
【図４】
2015170229.tif 000006
【図５】
2015170229.tif 000007
【図６】
2015170229.tif 000008
【図７】
2015170229.tif 000009
【図８】
2015170229.tif 000010
【図９】
2015170229.tif 000011
【図１０】
2015170229.tif 000012
【図１１】
2015170229.tif 000013
【図１２】
2015170229.tif 000014
【図１３】
2015170229.tif 000015