特開2015-170229(P2015-170229A)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社医用工学研究所の特許一覧

特開2015-170229診療データ管理プログラム及び診療データ管理システム
<>
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000003
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000004
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000005
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000006
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000007
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000008
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000009
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000010
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000011
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000012
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000013
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000014
  • 特開2015170229-診療データ管理プログラム及び診療データ管理システム 図000015
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2015-170229(P2015-170229A)
(43)【公開日】2015年9月28日
(54)【発明の名称】診療データ管理プログラム及び診療データ管理システム
(51)【国際特許分類】
   G06Q 50/24 20120101AFI20150901BHJP
【FI】
   G06Q50/24 110
【審査請求】未請求
【請求項の数】4
【出願形態】OL
【全頁数】18
(21)【出願番号】特願2014-45774(P2014-45774)
(22)【出願日】2014年3月7日
(71)【出願人】
【識別番号】306032981
【氏名又は名称】株式会社医用工学研究所
(74)【代理人】
【識別番号】100177921
【弁理士】
【氏名又は名称】坂岡 範穗
(72)【発明者】
【氏名】北岡 義国
【テーマコード(参考)】
5L099
【Fターム(参考)】
5L099AA23
(57)【要約】
【課題】異なる形式のデータベースが存在してもこれらの統合データベースを作成する必要がなく、また、データの検索、統計処理等が速やかに行えるようにする。
【解決手段】コンピュータを、同じ目的のためにデータベース毎に設けられた異なるテーブルを同種ターゲットとして管理する同種ターゲット用のテーブルと、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を1つの同種列として管理する同種列用のテーブルと、同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、検索条件が入力されると、同種ターゲット用のテーブル、同種列用のテーブル、及びデータ変換ルール用のテーブルに基づき複数のデータベースから実データを検索する検索制御部と、検索した実データを同種データに変換するともに、一時的に記憶するビュー記憶部として機能させる。
【選択図】図1
【特許請求の範囲】
【請求項1】
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理プログラムにおいて、
コンピュータを、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な1つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な1つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
して機能させることを特徴とする診療データ管理プログラム。
【請求項2】
複数の前記データベースが、異なる世代の医療情報システムによる、異なるデータベースであることを特徴とする請求項1に記載の診療データ管理プログラム。
【請求項3】
複数の前記データベースが、並列して存在する異なる医療情報システムによる、異なるデータベースであることを特徴とする請求項1に記載の診療データ管理プログラム。
【請求項4】
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理システムにおいて、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な1つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な1つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
を備えることを特徴とする診療データ管理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、異なる形式で記憶された複数のデータベースのデータを統合して管理する診療データ管理プログラム及び診療データ管理システムに関する。
【背景技術】
【0002】
従来、複数の病院等によって別個に設けられている電子カルテを統合して管理するものとして、特開2009−266077号公報に、診察対象となった患者を、一意に識別可能なシステムIDが提示された当該患者の診察内容を含む電子カルテを介して取得し、取得された電子カルテにおける電子カルテ情報の項目を調整した電子カルテ情報にシステムIDを対応付けた電子カルテ統合情報を生成して電子カルテ統合DBに格納し、キーワードを提示した電子カルテの閲覧要求を通信ネットワークを介して受け付け、電子カルテ統合DBを参照し、受け付けたキーワードに合致する電子カルテ統合情報を検索し、検索された電子カルテ統合情報に含まれる電子カルテ情報を所定のカテゴリ別に振り分け、振り分けされた電子カルテ情報を閲覧要求元の端末装置に送信する電子カルテ管理サーバが開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2009−266077号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、特許文献1に開示されている技術では、異なるシステムにおける電子カルテのデータを統合するに際し、それぞれのデータを検証して、一定のルールを作成し、該ルールに基づきデータの変換作業を行い、1つの統合データベースに保管し直す必要があった。係る場合、診療データは膨大な量となるため、全ての項目のデータを対象とすることは労力面と金銭面とから現実的ではなく、実際は膨大なデータの一部についてのみ変換作業が行われることが多かった。また、このデータの一部の変換作業においても多大な労力と金銭が必要となっていた。
【0005】
さらに、統合されたデータを使用するにあたり、当初想定していた項目の範囲を超えてデータが必要となった場合、元のデータを取得し直す必要が生じ、多大な労力と金銭とを要するデータの変換作業を再度行う必要があった。またさらに、電子カルテのデータは年々増大しており、長年のデータを1つの統合データベースへ格納して、そこから検索をしたり統計情報を引き出したりすると、データベースの応答時間が長くなってしまうという課題もあった。
【0006】
本発明は、上記の点に鑑みなされたもので、電子カルテや各種部門システムのメーカーやシステム自体が変更される等して、異なる形式のデータベースが存在しても、これらの統合データベースを作成する必要がなく、また、データの検索、統計処理、問い合わせが速やかに行える診療データ管理プログラム及び診療データ管理システムを提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明の診療データ管理プログラムは、
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理プログラムにおいて、
コンピュータを、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な1つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な1つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
して機能させることを特徴とする。
【0008】
本発明の診療データ管理プログラムによれば、同種ターゲット用のテーブルによって、同じ目的のためにデータベース毎に設けられた異なるテーブルを論理的な1つの同種ターゲットとしてまとめて管理することができる。この同じ目的とは、例えば病名に関するもの、処方に関するもの、注射に関するもの等があり、これらの同じ目的のテーブルは、データベース毎に異なるテーブル名となっている。同種ターゲット用のテーブルはこれらの異なるテーブルを、同じ目的という上位概念でまとめて管理するのである。
【0009】
また、同種列用のテーブルによって、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を論理的な1つの同種列として管理することができる。この同じ意味を持つ列とは、例えば、病名に関するテーブルであれば、病名を示す列、診療科を示す列、担当医師を示す列等であり、処方に関するテーブルであれば、薬品名を示す列、用量を示す列、用法を示す列等であり、注射に関するテーブルでは、薬品名を示す列、投与量を示す列、投与方法を示す列等である。これらの同じ意味を持つ列は、異なるデータベースのテーブル毎に異なる列名となっている。同種列用のテーブルは、これらの列名の異なる複数の列を、同じ意味という上位概念でまとめて管理するのである。
【0010】
また、データ変換ルール用のテーブルによって、同種列とされた複数の列に記憶されたそれぞれ異なる形式の実データを、統合のための同種データに変換する変換ルールを管理することができる。これは、同種列用のテーブルによって管理される同じ意味を持つ同種列は、その列名を含むデータ形式、データ内容がデータベース毎のテーブルによって異なる。例えば、患者の性別を示す列であれば、あるデータベースのテーブルは列名「seibetu」、データ形式「数字」、データ「0」又は「1」であり、他のデータベースのテーブルは列名「sex」、データ形式「文字」、データ「M」又は「F」等である。データ変換ルール用のテーブルは、これらの列の実データのデータ形式とデータを、統合のための同種データのデータ形式とデータに変換するルールを管理するのである。
【0011】
また、検索制御部によって、所望の検索条件が入力されると、同種ターゲット用のテーブル、同種列用のテーブル、及びデータ変換ルール用のテーブルに基づき複数のデータベースのテーブルの列から、当該データベースに記憶された実データを検索することができる。これは、所望の検索条件が入力されると、同種ターゲット用のテーブル、同種列用のテーブル、及びデータ変換ルール用のテーブルから、検索対象となるデータベース、テーブル、列、データを特定し、必要なデータを検索するのである。なお、このとき検索されたデータは、複数のデータベースから検索されたままの状態である実データである。
【0012】
また、変換制御部は、実データを、前記同種列用のテーブル、及びデータ変換ルール用のテーブルに基づき、同種データに変換する。例えば、上述の実データである列名「seibetu」、データ形式「数字」、データ「0」又は「1」、及び列名「sex」、データ形式「文字」、データ「M」又は「F」を、同種データの一例である列名「性別」、データ形式「文字」、データ「男」又は「女」に変換する等である。なお、同種データとは、実データを統合のために所定の列名、データ形式、データに変換処理したデータ、又は変換処理を行ったが実データと同種データが同じであって変換が不要であったデータを意図する。また、変換制御部は、上記変換した同種データをそのまま又は所定の形式の、表示用のデータであるビューデータとすることができる。
【0013】
また、ビュー記憶部は、変換制御部によって作成されたビューデータを、一時的に記憶する。このビュー記憶部は、複数のデータベースから検索され変換されたデータ全てを長い期間記憶する必要がなく、ビューデータのみを一時的に記憶できればよい。したがって、その都度必要なビューデータを記憶できる容量があればよく、システムの簡素化とコストダウンを図ることができる。また、表示部は、ビュー記憶部に記憶されたビューデータを、視覚的な情報として、所定の形式で表示させる。
【0014】
本発明の診療データ管理プログラムの好ましい例は、
複数の前記データベースが、異なる世代の医療情報システムによる、異なるデータベースであることを特徴とする。
【0015】
本発明の診療データ管理プログラムの好ましい例は、
複数の前記データベースが、並列して存在する異なる医療情報システムによる、異なるデータベースであることを特徴とする。
【0016】
これら本発明の診療データ管理プログラムの好ましい例によれば、異なる世代の医療情報システムによる、又は並列して存在する異なる医療情報システムによる、異なるデータベースを統合して管理することができ、ある医療機関で医療情報システムのメーカーが変わっても、又は離れた場所にある医療機関同士でも、複数のデータベースのデータを統合してデータの検索等を行うことができる。
【0017】
本発明の診療データ管理システムは、
異なる形式で記憶された複数のデータベースを統合して管理する診療データ管理システムにおいて、
同じ目的のために前記データベース毎に設けられた異なるテーブルを、論理的な1つの同種ターゲットとしてまとめて管理する同種ターゲット用のテーブルと、
前記同種ターゲットとされた複数の前記テーブルの中の同じ意味を持つ列を、論理的な1つの同種列としてまとめて管理する同種列用のテーブルと、
前記同種列とされた複数の列に記憶された異なる形式の実データを、統合のための同種データに変換する変換ルールを管理するデータ変換ルール用のテーブルと、
所望の検索条件が入力されると、前記同種ターゲット用のテーブル、前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき、検索対象となる前記データベース毎に設けられた前記テーブルと前記列とを特定し、複数の前記データベースから前記実データを検索する検索制御部と、
検索した前記実データを前記同種列用のテーブル、及び前記データ変換ルール用のテーブルに基づき前記同種データに変換するとともに、表示用のデータとしてのビューデータにする変換制御部と、
前記ビューデータを一時的に記憶するビュー記憶部と、
前記ビュー記憶部に記憶された前記ビューデータを視覚的な情報として表示させる表示部と、
を備えることを特徴とする。
【0018】
本発明の診療データ管理システムによれば、上述した理由により、診療データ管理プログラムと同様の作用効果を奏することができる。
【発明の効果】
【0019】
以上説明したように、本発明によれば、電子カルテや各種部門システムのメーカーや種類が変更される等して、異なる形式のデータベースが存在しても、これらの統合データベースを作成する必要がなく、また、データの検索、統計処理、問い合わせが速やかに行える診療データ管理プログラム及び診療データ管理システムを提供することができる。
【図面の簡単な説明】
【0020】
図1】本発明の一実施形態に係る診療データシステムの構成を示す機能ブロック図である。
図2】異なる医療情報システムにおいて、同じ目的のために設けられた異なるテーブルを説明する図である。
図3】同種ターゲットと同種列の概念を説明する図である。
図4】同種ターゲット用のテーブルを説明する図である。
図5】同種列用のテーブルを説明する図である。
図6】データ変換ルール用のテーブルを説明する図である。
図7】薬名マスタテーブル、ターゲットマスタテーブルを説明する図である。
図8】データの検索と変換によってビューデータが作成される過程を説明する図である。
図9】複数のデータベースからデータの検索と変換をする全体の処理を説明するフロー図である。
図10】検索条件の入力と、実データを検索するために必要となる情報の取得の処理を説明するフロー図である。
図11】実データの検索の処理を説明するフロー図である。
図12】実データを同種データに変換する処理を説明するフロー図である。
図13】ビューデータの作成の処理を説明するフロー図である。
【発明を実施するための形態】
【0021】
以下、本発明の診療データ管理システムの実施の形態について、添付図面を参照して詳細に説明する。なお、本発明に係る診療データ管理プログラムは、コンピュータに本発明に係る診療データ管理システムを実行させるためのものである。
【0022】
図1は本発明の一実施形態に係る診療データシステムの構成を示す機能ブロック図、図2は異なる医療情報システムにおいて、同じ目的のために設けられた異なるテーブルを説明する図、図3は同種ターゲットと同種列の概念を説明する図、図4は同種ターゲット用のテーブルを説明する図、図5は同種列用のテーブルを説明する図、図6はデータ変換ルール用のテーブルを説明する図、図7は薬名マスタテーブル、ターゲットマスタテーブルを説明する図である。
【0023】
先ず、本実施形態の診療データ管理システム1の概要を説明する。図1に示すように、本実施形態の診療データ管理システム1には、異なる世代の医療情報システムによる、又は並列して存在する異なる医療情報システムによる、異なるデータベース100,200が接続されている。この異なるデータベース100,200に設けられたテーブルとして、例えば、図2(A)に示すように、医療情報システムAのデータベースには、病名を管理する目的のための病名オーダーテーブルと、処方を管理する目的のための処方オーダーテーブルが設けられている。また、図2(B)に示すように、医療情報システムBのデータベースにも、病名を管理する目的のための検索用診療記録病名テーブルと、処方を管理する目的のための検索用処方テーブルが設けられている。これらのテーブルでは、同じ目的のテーブルであっても、医療情報システムが異なるため、テーブル名が異なっている。
【0024】
また、上記テーブルのうち同じ意味を持つ列であっても、その列名、データ形式、データの内容が異なっている。例えば、患者の性別を示す列であれば、図2(A)に示す医療情報システムAの、病名オーダーテーブルと処方オーダーテーブルは、列名「seibetu」、データ形式「数字」、データ「0」又は「1」であり、図2(B)に示す医療情報システムBの、検索用診療記録病名テーブルと検索用処方テーブルは、列名「sex」、データ形式「文字」、データ「M」又は「F」等である。このように、医療情報システムが異なれば、同じ目的のテーブル、同じ意味を持つ列であっても、そのデータ形式やデータの内容が異なり、そのままではまとめて検索等することができない。
【0025】
本実施形態の診療データ管理システム1は、これらの目的は同じだが異なるテーブルを、論理的な1つの同種ターゲットとして、また、同じ意味を持つ列を同種列として、まとめて管理するのである。ここでは、例として病名を目的とする同種ターゲットと該同種ターゲットに係る同種列、及び処方を目的とする同種ターゲットと該同種ターゲットに係る同種列を説明する。図3(A)に示す、病名を目的とする同種ターゲットでは、医療情報システムAの病名オーダーテーブルと医療情報システムBの検索用診療記録病名テーブルがまとめられている。また、図3(B)に示す、処方を目的とする同種ターゲットでは、医療情報システムAの処方オーダーテーブルと医療情報システムBの検索用処方テーブルがまとめられている。
【0026】
また、図3(A)(B)において、これらのテーブルの上側に、説明のための同種列を記載している。この同種列とは、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を、論理的な1つの列としてまとめて管理するもので、図中の矢印線で示すように、同種列「患者ID」は、「kanjyaID」と「患者番号」の列を同じ意味を持つ列としてまとめて管理し、同種列「性別」は「seibetu」と「sex」の列を同じ意味を持つ列としてまとめて管理するのである。なお、同種ターゲットが異なれば、同種列の内容も異なる。
【0027】
また、同種列としてまとめられた列も、テーブルが異なればそのデータ形式とデータが異なる。これらの異なるデータ形式とデータは、データ変換ルールを用いて、統合のためのデータへ変換されるのである。
【0028】
図1に戻り、本実施形態の診療データ管理システム1の構成を説明する。図1に示すように、本実施形態の診療データ管理システム1は、入力部10と、記憶部20と、制御部11と、表示部14とを備える。
【0029】
なお、接続されている複数のデータベース100,200に記憶されている元データ、又は複数のデータベース100,200から検索し抽出されているが変換処理されず元データの状態のままの形式である列名とデータとを、便宜上、実データと呼ぶ。また、実データを統合のためにその列名、データ形式、データの内容を変換処理したデータ、又は変換処理したが変換する必要がなかったデータを同種データという。
【0030】
入力部10は、公知のキーボード、マウス、タッチパネル、トラックボール等の入力機器を備え、これらの機器から所望の検索条件を入力することができる。
【0031】
記憶部20は、公知のハードディスクドライブ、半導体記憶装置等から構成され、その内部に、同種ターゲット用のテーブル21、同種列用のテーブル22、データ変換ルール用のテーブル23、各種マスタテーブル24、ビュー記憶部25を備える。また、記憶部20には、本実施形態の診療データ管理システム1を実現するために実行される診療データ管理プログラムやオペレーティングシステムが記憶され、その他コンピュータの動作に必要な記憶領域が設けられる。
【0032】
同種ターゲット用のテーブル21は、異なる医療情報システムの異なる形式で記憶されたデータベース100,200において、同じ目的のために前記データベース毎に設けられた異なるテーブルを論理的な1つの同種ターゲットとしてまとめて管理するためのもので、図4(A)に示す同種ターゲットテーブルと、図4(B)に示す同種ターゲット管理テーブルを備える。同種ターゲットテーブルは「同種ターゲットID」と「表示名」の項目(列)を、同種ターゲット管理テーブルは「同種ターゲットID」と「ターゲットID」の項目を有する。なお、同種ターゲット用のテーブルを、同種ターゲットテーブルと同種ターゲット管理テーブルの2つに分けているのは、管理をし易くするためであり、1つのテーブルにまとめてもよいし、他の項目を追加して3つ以上のテーブルとしてもよい。
【0033】
同種ターゲットテーブルの項目に設けられている同種ターゲットIDは、同じ目的のテーブル毎に設定されるIDであり、表示名は、その目的を表わす名前を上位概念として設定するものである。ここでは同種ターゲットID「1」が表示名「病名」に、同じく「2」が「処方」に設定されている。
【0034】
また、同種ターゲット管理テーブルの項目に設けられているターゲットIDは、複数のデータベースにそれぞれ設けられたテーブルを特定するためのIDである。つまり、同種ターゲットテーブルと同種ターゲット管理テーブルにより、同種ターゲットID「1」に設定された同種ターゲットは、「病名」を示す目的のテーブルであり、この病名を目的とするテーブルはターゲットID「A−1」と「B−5」で示されるテーブルであるということがわかる。同様に、同種ターゲットID「2」は、「処方」を目的とし、そのテーブルはターゲットID「A−8」と「B−3」で示されるテーブルであることがわかる。
【0035】
同種列用のテーブル22は、同種ターゲットとされた複数のテーブルの中の同じ意味を持つ列を論理的な1つの同種列としてまとめて管理するもので、図5(A)に示す同種列テーブルと、図5(B)に示す同種列管理テーブルを備える。同種列テーブルは「同種列ID」と「同種ターゲットID」と「表示名」と「データ形式」の項目を、同種列管理テーブルは「同種列ID」と「ターゲットID」と「列名」と「データ変換」と「データ変換ルールID」の項目を有する。なお、同種列用のテーブルを、同種列テーブルと同種列管理テーブルの2つに分けているのは、管理をし易くするためであり、1つのテーブルにまとめても、あるいは3つ以上のテーブルに分けてもよい。
【0036】
同種列テーブルの項目に設けられている同種列IDは、同じ意味を持つ列をまとめた同種列毎に設定されるIDである。また、同種ターゲットIDは、既に説明したように、同じ目的のためのテーブル毎に設定されるIDである。表示名は、同種列ID毎に設定され、同種列とされた列のデータを表示するときに表示される列名である。また、データ形式は、同じく同種列ID毎に設定され、同種列とされた列のデータを表示するときに使用されるデータ形式である。ここでは、病名を目的とするテーブルである同種ターゲットID「1」は、その項目として同種列IDを「1」から「6」まで備え、それぞれの同種列IDに表示名とデータ形式が設定されている。つまり、同種列ID「1」は、同種ターゲットID「1」のテーブルの列のうち、「患者ID」の意味を持つ列をまとめるためのもので、そのデータ形式は「数字形」であり、同種列ID「2」は、同種ターゲットID「1」のテーブルの列のうち、「性別」の意味を持つ列をまとめるためのもので、そのデータ形式は「文字型」であることがわかる。同様に、処方を示すテーブルである同種ターゲットID「2」は、その項目に同種列IDを「7」から「12」まで備え、それぞれの同種列IDに表示名とデータ形式が設定されていることがわかる。
【0037】
同種列管理テーブルの項目に設けられている同種列ID、ターゲットIDは、既に述べたとおりである。列名の項目は、ターゲットIDによって特定されたテーブルの中の、同じ意味を持つ列を特定するためのものであり、その列に実際に使用されている実データの列名が記憶される。また、データ変換の項目は、特定した列に記憶されている実データを変換する必要があるか否かを記憶しており、そのデータが「Y」ならばデータ変換が必要、「N」ならばデータ変換が不要である。また、データ変換ルールIDの項目は、データ変換する必要がある実データをどのように同種データに変換するかのルールを特定するためのIDが記憶されている。ここでは、同種列IDが「2」「8」「11」に係るデータの変換が必要であることがわかる。例えば、同種列ID「2」でまとめられた列は、ターゲットID「A−1」と「B−5」で示されるテーブルの、列名「seibetu」と「sex」で表された列であり、これらの列に記憶されたデータはデータ変換が必要で、そのデータ変換ルールIDは「1」と「2」であることがわかる。
【0038】
データ変換ルール用のテーブル23は、同種列とされた複数の列の実データを、統合のための同種データに変換する変換ルールを管理するもので、ここでは図6(A)に示すデータ変換ルールテーブルと、図6(B)に示すデータ変換ルール詳細テーブルを備える。データ変換ルールテーブルは「データ変換ルールID」と「名称」の項目を、データ変換ルール詳細テーブルは「データ変換ルールID」と「同種データ」と「実データ」の項目を有する。なお、データ変換ルール用のテーブルを、データ変換ルールテーブルとデータ変換ルール詳細テーブルの2つに分けているのは、管理をし易くするためであり、1つのテーブルにまとめても、あるいは3つ以上のテーブルに分けてもよい。
【0039】
データ変換ルールテーブルの項目に設けられているデータ変換ルールIDは、既に述べたように、データ変換する必要がある実データをどのように同種データに変換するかのルールを特定するためのものである。また、名称の項目は、変換する実データがどの医療情報システムのどのような意味のデータであるかを示すものである。
【0040】
データ変換ルール詳細テーブルの項目に設けられているデータ変換ルールIDは上述の通りである。また、同種データの項目は、実データをどのように変換するかが記憶されており、実データの項目は、変換する前のデータが記憶されている。ここでは、データ変換ルールID「1」と「3」は、実データが「0」又は「1」であるとき、それを同種データの「男」又は「女」に変換し、データ変換ルールID「2」と「4」は、実データが「M」又は「F」であるとき、それを同種データの「男」又は「女」に変換することがわかる。同様に、データ変換ルールID「5」は、実データが「K100」「K101」・・・というコードであるとき、それを同種データである「アシニン」「イシニン」・・・という薬名に変換し、データ変換ルールID「6」は、実データが「M1000」「M1001」・・・というコードであるとき、それを同種データである「アシニン」「イシニン」・・・という薬名に変換することがわかる。
【0041】
各種マスタテーブル24は、固定的で基本的なデータを記憶させるもので、例として図7(A)に示す薬名マスタテーブル、図7(B)に示すターゲットマスタテーブルがある。薬名マスタテーブルは、同種データにおける薬名を記憶しておくもので、ここでは「アシニン」「イシニン」・・・という薬名が記憶されている。
【0042】
ターゲットマスタテーブルは、上述のターゲットIDが実際にどの医療情報システムのどのデーブルを示すものかを記憶するテーブルで、「ターゲットID」と「システム名称」と「テーブル名称」の項目を有する。ターゲットIDは既に説明したとおりである。システム名称の項目は、ターゲットIDが示すテーブルが、医療情報システムAと医療情報システムBのどちらのシステムであるかを記憶している。また、テーブル名称の項目は、医療情報システムのデータベースに設けられた実際のテーブルの名称を記憶している。ここでは、ターゲットID「A−1」で示されるテーブルは、「医療情報システムA」の「病名オーダー」というテーブルであり、また、ターゲットID「A−2」で示されるテーブルは、「医療情報システムA」の「放射線オーダー」というテーブルであることがわかる。なお、ターゲットマスタテーブルは、ここでは各種マスタテーブルの一例として説明したが、同種ターゲット用のテーブルに含めてもよい。
【0043】
図1に戻り、ビュー記憶部25は、後述するビューデータを一時的に記憶するための領域である。この一時的とは、ビューデータを本実施形態の診療データ管理システム1が運用され続けられる限り記憶するものではないという意味であり、表示部14によるビューデータの表示が終われば、ビュー記憶部25からビューデータを直ちに削除してもよいし、ビュー記憶部25の容量に余裕があれば、過去の検索履歴のビューデータを所定の期間保存しておいてもよい。
【0044】
制御部11は、CPU、半導体による補助メモリ等で実現されるもので、検索制御部12と、変換制御部13とを備える。
【0045】
検索制御部12は、所望の検索条件が入力部10より入力されると、同種ターゲット用のテーブル21、同種列用のテーブル22、及びデータ変換ルール用のテーブル23に基づき、検索対象となるデータベース100,200毎に設けられたテーブルと列とを特定し、それぞれのデータベースから実データを検索する。具体的な手順としては、検索したい同種ターゲット、当該同種ターゲットの同種列、及び当該同種列の同種データ等が入力部10により入力されると、同種ターゲットとしてまとめられた複数のテーブルの、同種列としてまとめられた複数の列から、同種データに対応する実データを検索し、必要とされる範囲のデータ、例えば当該実データを含むレコードを選択し、実データによる新たなテーブル(以下、「実データテーブル」という。)を、同種ターゲットとしてまとめられた複数のテーブル毎に作成するのである。
【0046】
変換制御部13は、検索した実データテーブルを、データ変換ルール用のテーブルに基づき同種データによるテーブル(以下、「同種データテーブル」という。)に変換する。具体的な手順は、同種列管理テーブルにより、実データテーブルの列名を含む実データを変換する必要があるか否か、変換する必要があるならばどのデータ変換ルールIDによって変換するかを判断する。次に、データ変換ルール用のテーブル23に基づき変換する必要のある実データは変換し、変換する必要の無い実データはそのままとする変換処理を行う。そして、変換処理したデータにより同種データテーブルを作成するのである。
【0047】
また、複数のデータベース100,200から検索され作成された実データテーブルから変換された同種データテーブルは、原則として異なる医療情報システムのデータベースの数ほど存在する。これらの複数の同種データテーブルは、変換制御部13により表示用のデータとして1つのテーブルである、ビューデータにまとめられる。また、このビューデータは、まとめられたテーブルのうち、所望の項目のみ表示させることもできる。
【0048】
表示部14は、公知のディスプレイ装置等を備え、入力部10により入力された検索条件、ビュー記憶部25に記憶されたビューデータ等を視覚的な情報として表示させる。
【0049】
次に、以上説明した各構成要素の機能を踏まえて、本実施形態の診療データ管理システム1の動作について図2図13を参照して説明する。図2図7は既に説明したとおりである。図8はデータの検索と変換によってビューデータが作成される過程を説明する図である。また、図9は複数のデータベースからデータの検索と変換をする全体の処理を説明するフロー図、図10は検索条件の入力と、実データを検索するために必要となる情報の取得の処理を説明するフロー図、図11は実データの検索の処理を説明するフロー図、図12は実データを同種データに変換する処理を説明するフロー図、図13はビューデータの作成の処理を説明するフロー図である。
【0050】
先ず、図9を参照して、本実施形態の診療データ管理システム1による、複数のデータベース100,200から実データを検索し、検索した実データを同種データに変換し、さらにビューデータとして表示する全体の処理を説明する。
【0051】
本実施形態の診療データ管理システム1による処理が開始されると、表示部14により検索条件の入力を受け付ける画面が表示され、操作者が入力部10を操作することにより検索条件が入力される。また、検索条件の入力とともに、実データの検索に必要となる同種ターゲットID、ターゲットID、同種列IDが取得される(S1000)。次に、取得された同種ターゲットID、ターゲットID、同種列IDを基に、複数の医療情報システムのデータベースから実データを検索する(S2000)。次に、検索した実データを同種データに変換する(S3000)。次に、変換された1つ以上の同種データから、ビューデータを作成する(S4000)。そして、表示部14によりビューデータを視覚的な情報として表示する(S5000)。
【0052】
次に、図9図13に示すフロー図を参照して本実施形態の診療データ管理システム1による処理の各ステップを詳細に説明しながら、図2〜8に示すテーブルを参照してデータの検索と変換の具体例を説明する。
【0053】
図10に示す、ステップS1000の検索条件の入力と、同種ターゲットID、ターゲットID、同種列IDの取得では、先ず、検索制御部12により、同種ターゲットテーブル(図4(A))の表示名の項目が参照され、検索対象とする同種ターゲットを決定するための同種ターゲットの表示名の入力画面が表示される(S1010)。次に、入力部10により、検索する同種ターゲットの表示名、例えば「処方」が入力される(S1020)。すると、検索制御部12により、同種ターゲットテーブルから表示名「処方」の同種ターゲットID「2」が取得され(S1030)、さらに、同種ターゲット管理テーブル(図4(B))から、同種ターゲットID「2」を基に、データベース毎に設けられた異なるテーブルを示すターゲットID「A−8」「B−3」が取得される(S1040)。
【0054】
次に、検索対象とする同種列を決定するために、同種列テーブル(図5(A))の表示名の項目のうち、上記で取得した同種ターゲットID「2」に係るレコード(図中「a」で示すレコード)の表示名である「患者ID」「性別」「依頼科」・・・を入力する同種列の表示名入力画面が表示される(S1050)。次に、入力部10により、検索する同種列の表示名、例えば「薬名」が入力される(S1060)。すると、検索制御部12により、同種列テーブルから表示名「薬名」の同種列ID「11」が取得される(図中「b」で示すレコード)(S1070)。
【0055】
次に、取得した同種列ID「11」の同種データの名称を記憶した、図7(A)に示す薬名マスタの同種データの項目が参照され、検索対象とする同種データを決定するために、同種データを入力する同種データ入力画面が表示される(S1080)。次に、入力部10により検索する同種データ、例えば「イシニン」が入力される(S1090)。これらの処理により、「処方」「薬名」「イシニン」という検索条件の入力と、同種ターゲットID「2」、ターゲットID「A−8」「B−3」、同種列ID「11」の取得がなされる。なお、ステップS1070で取得した同種列IDに係るデータの変換が必要ない場合(取得した同種列IDに対応する、同種列管理テーブルのデータ変換の項目が「N」の場合。)は、ステップS1080では実データのマスタを参照して表示してもよい。また、ここでは薬名マスタを参照して「イシニン」という薬名を検索条件として選択したが、例えば、検索対象が検査値である場合、数字で所望の値の範囲等を指定することや、検査結果が陽性か陰性かといった検索条件を設定することもできる。
【0056】
次に、図11に示す、ステップS2000の実データの検索では、検索制御部12により、検索対象とするテーブルの列が特定される(S2010)。具体的には、ステップS1070で取得した同種列ID「11」を基に、同種列管理テーブル(図5(B))の同種列ID「11」に係るレコード(図中「c」で示すレコード)を参照する。そして、列名の項目からステップS1040で取得したターゲットID「A−8」「B−3」に対応する「yakuzaimeisyou」「薬品番号」を取得する。これにより、ターゲットID「A−8」のテーブルの「yakuzaimeisyou」の列、及びターゲットID「B−3」のテーブルの「薬品番号」の列を検索対象として特定することができる。
【0057】
次に、検索制御部12により、ステップS1090で入力された同種データが実データと同じか否かが判断される(S2020)。ここでは、同種列管理テーブルのデータ変換の項目のうち、既に取得した同種列ID「11」、及びターゲットID「A−8」「B−3」のレコードが参照される(図中「c」で示すレコード)。ここでデータが「Y」ならば入力された同種データと実データは異なり、「N」ならば入力された同種データと実データとは同じである。入力された同種データと実データが異なる場合、同種データを検索キーとしても実データは検索できないため、検索キーとなる実データを取得する必要がある。この手順としては、先ず、同種列管理テーブルのデータ変換ルールIDの項目から、データ変換ルールIDが取得される(S2030)。ここでは、同種列ID「11」のレコードのデータ変換の項目は「Y」となっており、同種データと実データが異なりデータ変換が必要であることがわかるとともに、データ変換ルールIDの項目からデータ変換ルールID「5」「6」が取得される。
【0058】
次に、検索制御部12により、同種データを基に検索キーとなる実データを取得する処理がなされる(S2040)。これは、ステップS2030で取得したデータ変換ルールID「5」「6」を基に、データ変換ルール詳細テーブル(図6(B))の、データ変換ルールID「5」と「6」に係るレコード(図中「d」で示すレコード)の同種データの項目の中から検索条件となっている「イシニン」を検索する。そして、実データの項目のうち「イシニン」を含むレコードから検索キーとなる実データとして、データ変換ルールID「5」については「K101」を、データ変換ルールID「6」については「M1001」を取得するのである。つまり、ステップS2010からステップS2040の処理により、ターゲットID「A−8」については列名「yakuzaimeisyou」及び検索キーとなる実データ「K101」が、ターゲットID「B−3」については列名「薬品番号」及び検索キーとなる実データ「M1001」が取得される。なお、上記ステップS2020で、データ変換の項目が「N」であった場合、同種データは実データと同じであり、同種データそのものを検索キーとすることができるため、ステップS2030とステップS2040の処理はスキップされる。
【0059】
次に、検索制御部12により、既に取得したターゲットID、列名、検索キーとなる実データ又は同種データを基に、複数のデータベースから実データに係るレコードを検索する処理を行う(S2050)。これは、先ず、ターゲットマスタテーブル(図7(B))を参照し、ターゲットID「A−8」に対応する医療情報システムとテーブルを特定する。ここでは、ターゲットID「A−8」に対応する医療情報システムとテーブルは、「システムA」の「処方オーダー」であることがわかる(図中「e」で示すレコード)。そして、図2(A)に示す医療情報システムAの「処方オーダー」テーブルの項目「yakuzaimeisyou」から、検索キーとなる実データ「K101」を検索し、該当するレコードを抽出する。そして、図8(B)に示す実データテーブルを作成する(S2060)。
【0060】
同じく、ターゲットID「B−3」についても、ターゲットマスタテーブルからターゲットID「B−3」に対応する医療情報システムとテーブルは、「システムB」の「検索用処方」であることがわかる(図中「f」で示すレコード)。そして、図2(B)に示す医療情報システムBの「検索用処方」テーブルの項目「薬品番号」から、検索キーとなる実データ「M1001」を検索し、該当するレコードを抽出し、図8(D)に示す実データテーブルを作成する。このようにして、実データの検索の処理と、実データテーブルの作成がなされる。
【0061】
次に、図12に示す、ステップS3000の実データを同種データに変換では、変換制御部13により、上記で作成された実データテーブルを同種データテーブルに変換する。先ず、同種データテーブルに変換されていない実データテーブルを選択する(S3010)。ここでは、図8(B)に示すターゲットID「A−8」から検索された実データテーブル(以下「A−8実データテーブル」という)を選択する。次に、実データテーブルの変換処理されていない列を選択し、その同種列ID、データ変換の有無、データ変換ルールIDを取得する(S3020)。ここでは、A−8実データテーブルの処理されていない列のうち最初の列「kaishibi」を選択し、ターゲットID「A−8」及び列名「kaishibi」を基に同種列管理テーブル(図5(B))を参照し(図中「g」で示すレコード)、同種列ID「10」、データ変換「N」、データ変換ルールID「無し」を取得する。次に、同種列の表示名を取得し、元の列名を表示名に変換する(S3030)。ここでは、既に取得した同種列ID「10」を基に、同種列テーブル(図5(A))を参照し(図中「h」で示すレコード)、表示名「処方開始日」とデータ形式「日付型」を取得し、A−8実データテーブルの最初の列名「kaishibi」を、取得した表示名「処方開始日」に変換する。
【0062】
次に、ステップS3020で取得した、データ変換「N」、データ変換ルールID「無し」を基に「処方開始日」の列のデータ変換が必要か否かが判断される(S3040)。ここでは、データ変換が必要ないため、A−8実データテーブルの列名「処方開始日」の列のデータはそのまま何もされず、後述するステップS3050とステップS3060はスキップされる。
【0063】
次に、A−8実データテーブルの変換処理していない残りの列があるか否かが判断される(S3070)。ここでは、列「kanjyaID」があるため、この列も上記ステップS3020からステップS3040の処理が行われ、列名が「患者ID」に変更されるとともに、当該列のデータはそのまま変更されない。
【0064】
次に、同じく繰り返し処理がなされ、ステップS3020で、A−8実データテーブルの列「seibetu」が選択され、同種列管理テーブル(図5(B))から同種列ID「8」、データ変換「Y」、データ変換ルールID「3」が取得される(図中「i」で示すレコード)。次に、ステップS3030で、同種列テーブル(図5(A))から同種列ID「8」のレコード(図中「j」で示すレコード)が選択され、表示名「性別」とデータ形式「文字型」が取得され、A−8実データテーブルの列名「seibetu」が、取得した表示名「性別」に変換される。
【0065】
次に、ステップS3040で、データ変換が必要か否かが判断される。ここでは上記ステップS3020で取得されたデータ変換の項目データが「Y」のため、データ変換が必要と判断される。次に、既に取得したデータ変換ルールID「3」を基に、データ変換ルール詳細テーブル(図6(B))を参照し、該当するレコード(図中「k」で示すレコード)を選択し、同種データの項目と実データの項目からデータの変換ルールを取得する(S3050)。そして、取得した変換ルールとデータ形式に従い、実データを同種データに変換する(S3060)。ここでは、A−8実データテーブルの「性別」の列の実データ「0」を同種データ「男」データ形式「文字型」に、実データ「1」を同種データ「女」データ形式「文字型」に変換する。これらのステップS3020からステップS3070を繰り返すことにより、A−8実データテーブルの全ての列名と実データが処理され、図8(C)に示す、A−8同種データテーブルへと変換される。
【0066】
次に、他に変換されていない実データテーブルがあるか否かが判断される(S3080)。ここでは、図8(D)に示すターゲットID「B−3」から作成された実データテーブル(以下、「B−3実データテーブル」という。)があり、ステップS3010に戻り、B−3実データテーブルが選択され、上述したステップS3020からステップS3070の処理が繰り返されることで、図8(E)に示す、B−3同種データテーブルへと変換される。なお、列名が同種列の表示名(図5(A)の表示名の項目)に変換されるのをわかりやすくするため、図8(A)に同種列の表示名を示している。
【0067】
次に、図13に示す、ステップS4000のビューデータの作成では、変換制御部13により、上記ステップS3000からステップS3080までの処理によって作成された同種データテーブルが複数あるか否かが判断される(S4010)。同種データテーブルが複数ある場合、変換制御部13は、複数の同種データテーブルを一つのテーブルに統合しビューデータを作成する(S4020)。ここでは、A−8同種データテーブルとB−3同種データテーブルがあり、これらを統合するとともに、項目の順番を図8(A)に示す同種列と同じように並び替えて、図8(F)に示すビューデータテーブルを作成する。そして、作成したビューデータテーブルをビューデータとしてビュー記憶部25に記憶させる(S4030)。一方、同種データテーブルが一つの場合、その同種データテーブル自体がビューデータとなるため、同種データテーブルの統合はなされず、項目の順番の並び替えのみが行われる。なお、ビューデータとしては、統合したテーブルのうち、所望の項目のみ抽出することもできる。
【0068】
次に、図9のステップS5000に示すように、表示部14によりビューデータが視覚的な情報として表示される。そして、操作者による閲覧等が終了し、表示されなくなったビューデータは、直ちにビュー記憶部25から削除してもよいし、ビュー記憶部25の容量に余裕がれば所定の期間、過去の検索データとして残してもよい。
【0069】
以上、述べたように、本発明の診療データ管理プログラム及び診療データ管理システムによれば、電子カルテや各種部門システムのメーカーやシステム自体が変更される等して、異なる形式のデータベースが存在しても、これらの統合データベースを作成する必要がなく、統合データベースを作成するための多大な労力と金銭が不要となるとともに、コンピュータ資源を節約することができる。また、複数のデータベースから全てのデータを網羅して統合データベースを作成することは一般的に困難であり、一部のデータは統合データベースに組み込まれず、バックアップ用のストレージ等のみに残されることが多々あったが、本発明の診療データ管理プログラム及び診療データ管理システムによれば、統合データベースを作成する必要がないため、元のデータベースをそのまま残して運用することが可能であり、データの保全にも有利である。
【0070】
また、データの検索等のおいて、その都度必要な範囲のみの処理を行うため、データの検索、統計処理、問い合わせが速やかに行えるとともに、システム自体の負荷を低減させることができる。
【0071】
また、本発明の診療データ管理プログラム及び診療データ管理システムを運用中に、再度電子カルテや各種部門システムのメーカーやシステム自体が変更されたり、他の病院等と合併等したりしてデータベースの数が増えても、同種ターゲット用のテーブル、同種列用のテーブル、データ変換ルール用のテーブル等のメンテナンスで対応することができ、新たな統合データベースを作成する必要がなく、将来にわたってコストを抑えた柔軟な対応をすることができる。
【0072】
なお、上述した診療データ管理プログラム及び診療データ管理システムは、本発明の例示であり、発明の趣旨を逸脱しない範囲でその構成を適宜変更することができる。例えば、処理の結果が同じであれば、上述の処理のフローの順番を一部入れ替えることもできる。また、データの変換処理において、実データテーブルをそのまま残して、別途同種データテーブルを作成することもできる。また、検索条件の入力では、所望の検索条件をキーボード等から直接テキストデータで入力してもよいし、プルダウンメニュー等を用いて複数の候補から選択するようにする等、様々な入力方法を採用することができる。
【符号の説明】
【0073】
1・・診療データ管理システム、
10・・入力部、11・・制御部、12・・検索制御部、13・・変換制御部、14・・表示部
20・・記憶部、21・・同種ターゲット用のテーブル、22・・同種列用のテーブル、23・・データ変換ルール用のテーブル、24・・各種マスタテーブル、25・・ビュー記憶部、
100,200・・データベース、
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13