以下、図面を参照して、各実施形態について説明する。
(第1の実施形態)
図1は、第1の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。本実施形態に係る医療情報管理システムは、例えば複数の職種の参加者から構成される医療チームによって患者に対する治療を行うチーム医療(MDT:Multidisciplinary Team)における、患者に対する治療方針等について議論するための当該医療チームのミーティング(MDTミーティング)の際に用いられる。
図1に示すように、医療情報管理システムは、クライアント端末10及び当該クライアント端末10と通信可能に接続される医療情報管理サーバ20を備える。
また、医療情報管理サーバ20は、図示しないが、例えば画像保存通信システム(PACS:Picture Archiving and Communication Systems)、病院情報システム(HIS:Hospital Information System)、放射線科情報システム(RIS:Radiology Information System)及び看護記録システム等の種々の外部のシステムとネットワークを介して通信可能に接続されている。なお、これらの外部のシステムにおいては、それぞれ所定の規則に従って各種医療情報(画像データ、投薬記録、看護記録等)が保存されているものとする。
クライアント端末10は、情報送受信部11及び情報表示部12を含む。情報送受信部11は、医療情報管理サーバ20との間で各種情報を送受信するための機能部である。
具体的には、情報送受信部11は、ミーティングを行う医療チームの種別を示す種別情報(以下、MDT IDと表記)及び医療情報管理システムにログインするためのパスワードを医療情報管理サーバ20に対して送信する。なお、医療チームの種別とは、当該医療チームによるチーム医療が対象とする疾病や目的の種別であり、例えば癌を対象とするチーム、脳卒中を対象とするチーム及び栄養サポートを目的とするチーム等の種別がある。
また、情報送受信部11は、後述するようにミーティングにおいて議論されている患者に関する医療情報を医療情報管理サーバ20から受信する。情報送受信部11によって受信される医療情報には、上記した画像保存通信システム、病院情報システム、放射線科情報システム及び看護記録システム等の外部のシステムにおいて保存されている画像データやその他のデータ等が含まれる。
情報表示部12は、各種情報を表示するための機能部である。具体的には、情報表示部12は、情報送受信部11によって受信された医療情報を、医療チームを構成する参加者に対して表示する。
医療情報管理サーバ20は、格納部21、認証部22、情報参照履歴取得部23、情報参照履歴変換部24、関連情報取得部25及び関連情報送信部26を含む。
格納部21には、ログイン情報及び情報参照履歴情報が予め格納されている。ログイン情報は、上記したミーティングを行う医療チーム(当該ミーティングの主催者)が医療情報管理システムにログインする際に用いられる情報である。情報参照履歴情報は、医療チームが過去のミーティングにおいて参照した医療情報の履歴を示す情報である。具体的には、情報参照履歴情報は、過去のミーティングにおいて参照された患者に関する医療情報を参照するための方法(参照情報)を、当該ミーティングを行った医療チームの種別を示す種別情報(MDT ID)に対応づけて含む。なお、ログイン情報及び情報参照履歴情報の詳細については後述する。
認証部22は、クライアント端末10に含まれる情報送受信部11によって送信されたMDT ID及びパスワードを受信する。認証部22は、受信されたMDT ID及びパスワードと格納部21に格納されているログイン情報とに基づいて認証を行う。
情報参照履歴取得部23は、格納部21に格納されている情報参照履歴情報を参照して、認証部22によって受信されたMDT IDに対応づけて当該情報参照履歴情報に含まれる参照情報(医療情報を参照するための参照情報)を取得する。
情報参照履歴変換部24は、認証部22によって受信されたMDT IDによって示される種別の医療チームが行うミーティングにおいて議論されている患者を識別するための患者識別情報(以下、患者IDと表記)を取得する。情報参照履歴変換部24は、情報参照履歴取得部23によって取得された参照情報を、認証部22によって受信された患者IDに基づいて変換する処理を行う。
関連情報取得部25は、情報参照履歴変換部24によって変換された参照情報に基づいて、外部のシステムから医療情報を取得する。ここで関連情報取得部25によって取得される医療情報は、情報参照履歴取得部23によって取得された参照情報を用いて参照することができる医療情報に対応する医療情報(つまり、当該参照情報を用いて参照することができる医療情報と同じ種類の医療情報)であって、ミーティングにおいて議論される患者に関する医療情報である。
関連情報送信部26は、関連情報取得部25によって取得された医療情報をクライアント端末10に送信する。関連情報送信部26によって送信された医療情報は、クライアント端末10に含まれる情報送受信部11によって受信され、当該クライアント端末10に含まれる情報表示部12によって表示される。
図2は、図1に示す格納部21に格納されているログイン情報のデータ構造の一例を示す。
図2に示すように、ログイン情報には、MDT ID及びパスワードが対応づけて含まれる。MDT IDは、患者について議論するためのミーティングを行う医療チームの種別を示す。パスワードは、対応づけられているMDT IDによって示される種別の医療チームに対して予め定められているパスワードである。
図2に示す例では、ログイン情報には、MDT ID「Cancer」及びパスワード「○○○○」が対応づけて含まれている。これによれば、MDT ID「Cancer」によって示される種別の医療チームは、パスワード「○○○○」によってログイン可能であることが示されている。なお、MDT ID「Cancer」は、癌を対象とする医療チームの種別を示す。
ここでは詳しい説明を省略するが、ログイン情報においては、他のMDT IDについても同様にパスワードが規定されている。
図3は、図1に示す格納部21に格納されている情報参照履歴情報のデータ構造の一例を示す。
図3に示すように、情報参照履歴情報には、MDT IDに対応づけて使用アプリケーション情報及び参照情報(参照方法)が含まれている。MDT IDは、上記したように医療チームの種別を示す。使用アプリケーション情報は、対応づけられているMDT IDによって示される種別の医療チームが過去のミーティングにおいて医療情報を参照した際に使用したアプリケーションを示す。参照情報は、対応づけられているMDT IDによって示される種別の医療チームが過去のミーティングにおいて参照した医療情報を参照するための情報(つまり、当該医療情報にアクセスするための情報)であり、具体的には、当該医療情報を保存している外部のシステムにおける当該医療情報の保存位置(つまり、当該医療情報の取得先)を示すURI(Uniform Resource Identifier)を含む。
図3に示す例では、情報参照履歴情報には、MDT ID「Cancer」に対応づけて使用アプリケーション「DICOMビューワ」及び参照情報「http://PACS/patient01/001.dcm」が含まれている。これによれば、MDT ID「Cancer」によって示される種別の医療チーム(癌を対象とする医療チーム)が過去のミーティングにおいてDICOMビューワを使用して「http://PACS/patient01/001.dcm」に基づいてアクセス可能な医療情報を参照したことが示されている。
このように情報参照履歴情報によれば、過去のミーティングにおいて参照された医療情報の履歴が示される。
次に、図4のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。
まず、患者について議論するためのミーティングにおいて医療情報管理システムを利用する場合、例えば当該ミーティングの主催者(当該ミーティングを行う医療チームを構成する参加者)は、当該医療情報管理システムにログインする必要がある。
この場合、ミーティングの主催者は、例えば当該ミーティングの開始時に、クライアント端末10を操作することによって、当該ミーティングを行う医療チームの種別を示すMDT ID及びパスワードを入力する。
なお、医療チームのミーティングにおいて議論される患者を対象患者と称する。以下に説明する他の実施形態においても同様であるものとする。
このようにミーティングの主催者によってMDT ID及びパスワードが入力された場合、クライアント端末10に含まれる情報送受信部11は、当該入力されたMDT ID及びパスワードを医療情報管理サーバ20に送信する(ステップS1)。
医療情報管理サーバ20に含まれる認証部22は、クライアント端末10(に含まれる情報送受信部11)によって送信されたMDT ID及びパスワードを受信する。
認証部22は、受信されたMDT ID及びパスワードと格納部21に格納されているログイン情報とに基づいて認証処理を実行し、当該認証の成功または失敗を判定する(ステップS2)。認証部22は、受信されたMDT ID及びパスワードがログイン情報において対応づけられている場合には、認証が成功したと判定する。一方、認証部22は、受信されたMDT ID及びパスワードがログイン情報において対応づけられていない場合には、認証が失敗したと判定する。なお、認証部22による認証処理は、例えばActiveDirectoryやSSH等を用いて実行される。
認証部22によって認証が失敗したと判定された場合(ステップS2のNO)、医療情報管理システムへのログインが拒否されて、処理が終了される。
一方、認証部22によって認証が成功したと判定された場合(ステップS2のYES)、医療チーム(ミーティングの主催者)の医療情報管理システムへのログインが許可される。この場合、情報参照履歴取得部23は、格納部21に格納されている情報参照履歴情報を参照して、認証部22によって受信されたMDT ID(つまり、ログイン中のMDT ID)に対応づけて当該情報参照履歴情報に含まれる参照情報(URI)を取得する(ステップS3)。なお、参照情報は、例えば問い合わせ言語であるSQL等を用いることによって格納部21から取得することができる。
ここで、上記した図3に示す情報参照履歴情報が格納部21に格納されており、認証部22によってMDT IDとして「Cancer」が受信された場合には、図5に示すようにMDT ID「Cancer」に対応づけて当該情報参照履歴情報に含まれている参照情報が取得される。
次に、情報参照履歴変換部24は、情報参照履歴取得部23によって取得されたURI(文字列)を解析し、当該URIを対象患者(つまり、現在議論されている患者)に関する医療情報にアクセスするためのURIに変換する(ステップS4)。
ここで、情報参照履歴変換部24によるURIの変換処理について具体的に説明する。この場合、情報参照履歴変換部24は、対象患者を識別するための患者識別情報(以下、患者IDと表記)を、例えば病院外または病院内のシステム(MDTミーティングシステム等)から取得する。以下、対象患者を識別するための患者IDを対象患者IDと称する。
次に、情報参照履歴変換部24は、情報参照履歴取得部23によって取得されたURIに含まれる患者IDを特定する。情報参照履歴変換部24は、特定された患者ID(情報参照履歴取得部23によって取得されたURIに含まれる患者ID)を、対象患者IDに置き換える。これによって、情報参照履歴取得部23によって取得されたURIは、対象患者IDを含むURIに変換される。なお、URIに含まれる患者IDは、例えば外部のシステム(PACS、HIS、RIS及び看護記録システム等)に備えられるデータベース(DB)を参照することにより認識することができるものとする。
ここで、例えば図5に示す参照情報「¥¥HIS¥Patient01¥medicatin.html」を用いて具体的に説明すると、当該参照情報(つまり、URI)においては、患者ID「Patient01」が含まれている。対象患者IDが例えば「Patient99」である場合を想定すると、参照情報「¥¥HIS¥Patient01¥medicatin.html」は、参照情報「¥¥HIS¥Patient99¥medicatin.html」に変換される。なお、対象患者IDが「Patient99」である場合における図5に示す各参照情報の変換結果は、図6に示すようになる。以下、情報参照履歴変換部24によって変換される前の参照情報を変換前参照情報と称し、情報参照履歴変換部24によって変換された後の参照情報を変換後参照情報と称する。
上記したように医療情報管理サーバ20と通信可能な外部のシステム(PACS、HIS、RIS及び看護記録システム等)では、所定の規則に従って医療情報が保存されている。このため、図6に示す例えば変換前参照情報「http://PACS/Patient01/001.dcm」に基づいてアクセス可能な医療情報が患者ID「Patient01」によって識別される患者に関するDICOMデータ(画像データ)である場合、変換後参照情報「http://PACS/Patient99/001.dcm」に基づいてアクセス可能な医療情報は、当該変換前参照情報に基づいてアクセス可能なDICOMデータと同種のDICOMデータであって、患者ID「Patient99」によって識別される患者に関するDICOMデータとなる。
なお、ここで説明した参照情報の変換処理は一例であり、当該参照情報の変換処理は、外部のシステムにおける医療情報の保存方法等に応じて適宜変更されても構わない。つまり、情報参照履歴取得部23によって取得された参照情報は、当該参照情報によって参照される医療情報と同様な対象患者に関する医療情報を取得可能な情報に変換されればよい。
次に、関連情報取得部25は、情報参照履歴変換部24によって変換された参照情報(つまり、変換後参照情報)に基づいて、外部のシステムから医療情報(対象患者に関する医療情報)を取得する(ステップS5)。換言すれば、関連情報取得部25は、変換後参照情報に含まれるURIに基づいて外部のシステムにアクセスすることによって医療情報を取得する。この場合、関連情報取得部25は、例えばHTTPクライアントやFTPクライアント等の各変換後参照情報に応じた通信方法(図6に示す例では、http、Windows(登録商標)Explorer、FTP)により医療情報を取得する。
なお、関連情報取得部25は、変換後参照情報に基づいてアクセス可能な医療情報の全てを取得してもよいし、例えば予め定められている優先度に基づいて医療情報を取得するような構成とすることも可能である。具体的には、関連情報取得部25は、例えば参照された回数が多い医療情報を取得するように設定することも可能であるし、DICOMデータ(.dcmファイル)は常に取得するように設定することも可能である。
関連情報送信部26は、例えば通信API(Application Programming Interface)等を用いて、関連情報取得部25によって取得された医療情報をクライアント端末10に送信する(ステップS6)。この場合、関連情報送信部26は、関連情報取得部25によって取得された医療情報とともに、認証部22によって受信されたMDT IDに対応づけて情報参照履歴情報に含まれる使用アプリケーション情報をクライアント端末10に送信する。
クライアント端末10に含まれる情報送受信部11は、例えば通信API等を用いて、関連情報送信部26によって送信された医療情報及び使用アプリケーション情報を受信する。
次に、情報表示部12は、情報送受信部11によって受信された使用アプリケーション情報に基づいて、当該使用アプリケーション情報によって示されるアプリケーションを起動し、当該情報送受信部11によって受信された医療情報を当該起動されたアプリケーションに読み込ませる。これにより、情報表示部12は、情報送受信部11によって受信された医療情報を、起動されたアプリケーションで表示する(ステップS7)。なお、医療情報は、上記した医療チームのミーティングにおいて当該医療チームを構成する全ての参加者が確認可能な態様で表示される。
具体的には、情報送受信部11によって受信された使用アプリケーション情報がInternet Explorer(登録商標)やChrome等のブラウザを示し、医療情報がレセプト情報である場合には、当該ブラウザに当該レセプト情報を読み込ませて起動する。この場合、例えば図7に示す画面31が表示される。
更に、クライアント端末10においてブラウザが起動されている状態で、当該ブラウザを示す使用アプリケーション情報及び看護記録や治療計画に関する情報(医療情報)が情報送受信部11によって受信された場合には、図7に示す画面32のように、タブに当該看護記録や治療計画に関する情報を読み込ませておくことで、当該看護記録や治療計画に関する情報についても迅速に表示可能な状態にすることができる(つまり、迅速に表示を切り替えることができる)。
ここでは、ブラウザについて主に説明したが、画像ビューワ及びPDFリーダ等のミーティングで使用する他のアプリケーションであっても同様に医療情報を表示することができる。
上記したように本実施形態においては、クライアント端末10がミーティングを行う医療チームの種別を示す種別情報を医療情報管理サーバ20に送信し、医療情報管理サーバ20が当該送信された種別情報に対応づけて情報参照履歴情報に含まれる医療情報を参照するための参照情報を取得し、当該種別情報によって示される種別の医療チームが行うミーティングにおいて議論される患者を識別するための患者IDを取得し、当該参照情報に基づいて患者IDによって識別される患者に関する医療情報を取得し、当該取得された医療情報がクライアント端末10において表示される構成により、ミーティングにおいて患者に関する医療情報の検索等を行うことなく、当該医療情報をクライアント端末10において迅速に表示することが可能となる。
つまり、本実施形態においては、同種の医療チームによる過去のミーティングにおいて参照された医療情報(つまり、参照履歴)に基づいて取得されたミーティングにおける議論に必要な医療情報をクライアント端末10が事前に医療情報管理サーバ20から読み込んでおくことで、当該ミーティングの際にクライアント端末10において必要な情報を迅速に表示することが可能となる。
なお、本実施形態はチーム医療におけるミーティング(MDTミーティング)に適用されるものとして説明したが、例えば一般のカンファレンス等に適用されても構わない。
(第2の実施形態)
次に、第2の実施形態について説明する。本実施形態に係る医療情報管理システムの構成は、前述した第1の実施形態と同様であるため、適宜、図1を用いて説明する。
本実施形態に係る医療情報管理システムは、格納部21に格納されている情報参照履歴情報が医療情報の表示形式(画像の表示パラメータ等)を更に含む点が、前述した第1の実施形態とは異なる。
図8は、本実施形態における格納部21に格納されている情報参照履歴情報のデータ構造の一例を示す。
図8に示すように、情報参照履歴情報には、MDT IDに対応づけて使用アプリケーション情報、参照情報及び表示形式が含まれている。表示形式は、対応づけられている参照情報を用いて参照することができる医療情報(つまり、当該参照情報に含まれるURIに基づいてアクセス可能な医療情報)が過去のミーティングにおいて参照された際の表示形式を示す。なお、医療情報がDICOMデータ(画像データ)等である場合、表示形式には、例えばウィンドウ幅(WW)及びウィンドウレベル(WL)等が含まれる。なお、情報参照履歴情報に含まれるMDT ID、使用アプリケーション情報及び参照情報については、前述した第1の実施形態において説明した通りであるため、ここではその詳しい説明を省略する。
図8に示す例では、情報参照履歴情報には、MDT ID「Cancer」に対応づけて使用アプリケーション「DICOMビューワ」、参照情報「http://PACS/patient01/001.dcm」、表示形式「画像のWW/WL=(300,40)」及び「アプリウィンドウ最大化」が含まれている。これによれば、MDT ID「Cancer」によって示される種別の医療チームが過去のミーティングにおいてDICOMビューワを使用して「http://PACS/patient01/001.dcm」に基づいてアクセス可能な医療情報(画像データ)を、WW/WL=(300,40)に設定し、かつ、ウィンドウを最大化して参照(表示)したことが示されている。
次に、本実施形態に係る医療情報管理システムの処理手順について説明する。ここでは、便宜的に、前述した図4のフローチャートを用いて説明するが、前述した第1の実施形態と異なる部分について主に述べる。
まず、図4に示すステップS1〜S5の処理と同様の処理が実行される。次に、関連情報送信部26は、図4のステップS6の処理を実行する際に、認証部22によって受信されたMDT IDに対応づけて情報参照履歴情報に含まれる使用アプリケーション情報及び表示形式をクライアント端末10に送信する。
クライアント端末10に含まれる情報送受信部11は、例えば通信API等を用いて、関連情報送信部26によって送信された医療情報、使用アプリケーション情報及び表示形式を受信する。
次に、情報表示部12は、図4に示すステップS7の処理と同様に、情報受信部11によって受信された医療情報を、起動されたアプリケーションで表示する。この場合、情報受信部11によって受信された医療情報は、情報受信部11によって受信された表示形式で表示される。
具体的には、情報受信部11によって受信された医療情報がDICOMデータ(http://PACS/Patient01/001.dcmに基づいてアクセス可能な画像データ)であり、使用アプリケーション情報がDICOMビューワを示し、表示形式がWW/WL=(300,40)及びアプリウィンドウの最大化である場合には、情報表示部12は、図9に示すように、当該画像データのウィンドウ幅(WW)及びウィンドウレベル(WL)をそれぞれ300及び40に設定し、更にウィンドウを最大化して、DICOMビューワで表示する。
上記したように本実施形態においては、医療情報管理サーバ20において受信されたMDT IDに対応づけて情報参照履歴情報に含まれている表示形式で、関連情報取得部25によって取得された医療情報(ミーティングにおいて議論されている患者を識別するための患者IDに基づいて変換されたURIに基づいてアクセス可能な医療情報)をクライアント端末10に表示する構成により、過去のミーティングにおいて参照された医療情報と同様の表示形式で対象患者に関する医療情報を表示することが可能となる。
(第3の実施形態)
次に、第3の実施形態について説明する。図10は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図1と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図1と異なる部分について主に述べる。
本実施形態に係る医療情報管理システムは、クライアント端末において使用中のアプリケーションで表示可能な形式に医療情報を変換して、当該変換された医療情報をクライアント端末に送信する点が、前述した第1の実施形態とは異なる。
図10に示すように、医療情報管理システムは、クライアント端末100及び当該クライアント端末100と通信可能に接続される医療情報管理サーバ200を備える。
クライアント端末100は、使用状況認識部101及び使用状況送信部102を含む。使用状況認識部101は、クライアント端末100において使用しているアプリケーションを認識する。
使用状況送信部102は、使用状況認識部101によって認識されたアプリケーションを示す情報(以下、使用状況情報と表記)を医療情報管理サーバ200に送信する。
医療情報管理サーバ200は、関連情報変換部201を含む。関連情報変換部201は、関連情報取得部25によって取得された医療情報を、使用状況送信部102によって送信された使用状況情報によって示されるアプリケーション(つまり、クライアント端末100において使用されているアプリケーション)で表示可能な形式に変換する。
なお、このように関連情報変換部201によって変換された医療情報は、関連情報送信部26によってクライアント端末100に送信され、当該クライアント端末100において使用されているアプリケーションで表示される。
次に、図11のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。
まず、前述した図4に示すステップS1〜S5の処理に相当するステップS11〜S15の処理が実行される。
次に、クライアント端末100に含まれる使用状況認識部101は、例えばWindowsAPI等を用いて、当該クライアント端末100が現在使用しているアプリケーション(つまり、使用中のアプリケーション)を認識する(ステップS16)。なお、使用中のアプリケーションは、例えばクライアント端末100において当該アプリケーションに与えられているウィンドウがアクティブであるか否か等に基づいて判別される。
使用状況送信部102は、使用状況認識部101によって認識されたアプリケーションを示す使用状況情報を、通信API等を用いて医療情報管理サーバ200に送信する(ステップS17)。なお、使用状況送信部102によって送信される使用状況情報には、例えば使用状況認識部101によって認識されたアプリケーションのアプリケーション名及び当該アプリケーションのバージョン情報等が含まれる。
医療情報管理サーバ200に含まれる関連情報変換部201は、使用状況送信部102によって送信された使用状況情報を受信する。
関連情報変換部201は、受信された使用状況情報に含まれるアプリケーション名及びバージョン情報等に基づいて、ステップS15において関連情報取得部25によって取得された医療情報をクライアント端末100において使用中のアプリケーションで表示可能な形式に変換する(ステップS18)。
具体的には、ステップS15においてDICOMデータ(DICOM形式の画像データ)が取得されており、関連情報変換部201によって受信された使用状況情報がInternetExplorerのバージョン9を示す場合、関連情報変換部201は、例えばDICOMライブラリ等を用いて当該DICOMデータをJPGやPNG等のブラウザで表示できる形式に変換(画像変換)する。なお、この場合には、DICOMデータのヘッダ情報等もHTML形式に変換される。これにより、本来はブラウザで表示することができないDICOMデータをブラウザで表示することができるようになる。ここでは、DICOMデータがJPGやPNGに変換され、当該DICOMデータのヘッダ情報がHTML形式に変換されるものとして説明したが、これらはクライアント端末100において使用中のアプリケーションで表示可能な形式であれば他の任意の形式(例えば、PDFやXML等)に変換されても構わない。
関連情報送信部26は、関連情報変換部201によって形式が変換された医療情報をクライアント端末100に送信する(ステップS19)。
クライアント端末10に含まれる情報送受信部11は、例えばAPI等を用いて、関連情報送信部26によって送信された医療情報を受信する。
次に、情報表示部12は、情報送受信部11によって受信された医療情報を、当該医療情報を表示可能なクライアント端末100において使用されているアプリケーション(つまり、既に起動されているアプリケーション)に読み込ませる。これにより、情報表示部12は、情報送受信部11によって受信された医療情報を表示する。
ここで、図12は、情報表示部12によって医療情報が表示された際のクライアント端末100の表示画面の一例を示す。
図12に示す例では、医療情報管理サーバ200において例えばブラウザで表示可能な形式に変換された複数の医療情報(画像データ)をクライアント端末100において使用されているブラウザで表示した場合の表示画面が示されている。
なお、本実施形態において、医療情報管理サーバ200から送信される医療情報は単一のアプリケーション(例えば、ブラウザ等)で表示することができる形式に変換されているため、図12に示すように例えば対象患者を示す患者情報等を医療情報に付加して表示することにより、アプリケーションを切り替えることなく医療情報及び患者情報等を同時に確認ことが可能となる。なお、患者情報は、対象患者を識別するための患者ID等に基づいて医療情報管理システムの外部の例えば病院情報システム(HIS)等から取得されればよい。
上記したように本実施形態においては、対象患者に関する医療情報をクライアント端末100において使用されているアプリケーションで表示可能な形式に変換してクライアント端末100に送信する構成により、医療情報管理サーバ20から送信される全ての医療情報を単一のアプリケーションで表示(確認)することが可能になるため、医療情報を表示する際にアプリケーションを切り替えることが不要となり、当該アプリケーションの切り替えに要する時間を削減することが可能となる。
(第4の実施形態)
次に、第4の実施形態について説明する。図13は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図1と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図1と異なる部分について主に述べる。
本実施形態に係る医療情報管理システムは、患者について議論するミーティングの度に情報参照履歴情報を更新する点が、前述した第1の実施形態とは異なる。
図13に示すように、医療情報管理システムは、クライアント端末110及び当該クライアント端末110と通信可能に接続される医療情報管理サーバ210を備える。
クライアント端末110は、情報取得部111、情報取得状況検出部112及び情報取得状況通知部113を含む。
情報取得部111は、ミーティングにおいて議論されている患者に関する医療情報(第3の医療情報)を外部のシステムから取得する。なお、情報取得部111によって取得された医療情報は、例えば情報表示部12によって表示される。
情報取得状況検出部112は、情報取得部111によって取得された医療情報の取得先を示すURI及び当該医療情報を表示するために使用されるアプリケーションを検出する。
情報取得状況通知部113は、情報取得状況検出部112によって検出されたURIを及びアプリケーションを医療情報管理サーバ210に通知する。
医療情報管理サーバ210は、情報参照履歴更新部211を含む。情報参照履歴更新部211は、情報取得状況通知部113による通知に基づいて、格納部21に格納されている情報参照履歴情報を更新する。
以下、本実施形態に係る医療情報管理システムの動作について説明する。本実施形態に係る医療情報管理システムは、前述した第1の実施形態において説明した処理(図4に示す処理)に加えて、情報参照履歴更新処理を実行する。
図14に示すフローチャートを参照して、本実施形態に係る医療情報管理システムによって実行される情報参照履歴更新処理の処理手順について説明する。
まず、クライアント端末110に含まれる情報取得部111は、例えばミーティング中に、HTTPやFTP等のプロトコルを用いて、外部のシステムに対して医療情報(当該ミーティングにおいて議論されている患者に関する医療情報)のリクエストを送信することができる(ステップS21)。以下、情報取得部111によるリクエストの対象となる医療情報を対象医療情報と称する。
このリクエストが送信された外部のシステムは、対象医療情報をクライアント端末110に対して送信する。これにより、情報取得部111は、対象医療情報を外部のシステムから取得することができる。情報取得部111によって取得された対象医療情報は、例えば情報表示部12によって表示されて、ミーティングにおいて参照される。
上記したように情報取得部111からリクエストが送信された場合、情報取得状況検出部112は、対象医療情報の取得先を示すURI及び当該対象医療情報を表示するために使用されるアプリケーション(使用中のアプリケーション)を検出する(ステップS22)。
情報取得状況通知部113は、情報取得状況検出部112によって検出されたURI及びアプリケーションを、通信API等を用いて医療情報管理サーバ210に通知する(ステップS23)。
医療情報管理サーバ210に含まれる情報参照履歴更新部211は、ログイン中のMDT ID(つまり、認証部22によって受信されたMDT ID)に対応づけて情報取得状況通知部113によって通知されたURIを含む参照情報及びアプリケーションを示すアプリケーション情報を含む情報参照履歴情報を、格納部21に新たに格納する(ステップS24)。
ここで、情報参照履歴更新処理について具体的に説明すると、例えばクライアント端末110から外部のシステムであるPACSに対して対象医療情報(DICOMデータ)のリクエストが送信された場合には、対象医療情報の取得先であるURIとして例えば「http://PACS/Patient99/001.dcm」、当該対象医療情報を表示するために使用されるアプリケーションとして「DICOMビューワ」が医療情報管理サーバ210に通知される。この場合において、例えばログイン中のMDT IDが「Cancer」である場合には、当該MDT ID「Cancer」に対応づけて参照情報「http://PACS/Patient99/001.dcm」及び使用アプリケーション情報「DICOMビューワ」を含む情報参照履歴情報が格納部21に格納される。
上記したように本実施形態においては、ミーティングにおいて外部のシステムから医療情報が取得される度に格納部21に格納されている情報参照履歴情報が更新されるため、格納部21に格納されている情報参照履歴情報を更新しない場合と比較して、ミーティングにおいて必要な医療情報を漏れなく医療情報管理サーバ210からクライアント端末110に送信することが可能となる。
(第5の実施形態)
次に、第5の実施形態について説明する。図15は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図1と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図1と異なる部分について主に述べる。
本実施形態に係る医療情報管理システムは、ミーティングを行う医療チームを構成する参加者(つまり、ミーティングの参加者)の役割(職種)を考慮した医療情報がクライアント端末120において表示される点が、前述した第1の実施形態とは異なる。
図15に示すように、医療情報管理システムは、クライアント端末10及び当該クライアント端末10と通信可能に接続される医療情報管理サーバ220を備える。
医療情報管理サーバ220は、格納部221及び関連情報絞込み部222を含む。格納部221は、前述した第1の実施形態において説明したログイン情報及び情報参照履歴情報に加えて、役割関連情報を更に格納する。格納部221に格納されている役割関連情報は、ミーティングを行う医療チームを構成する参加者の役割毎に、当該役割に関連する医療情報(の取得先)を示す情報である。
関連情報絞込部222は、医療情報管理システムの外部のシステムから、ミーティングを行う医療チームを構成する参加者の役割を取得する。関連情報絞込部222は、取得された参加者の役割及び格納部221に格納されている役割関連情報に基づいて、情報参照履歴変換部24によって変換された参照情報(URI)に対して絞り込みを行う。
なお、本実施形態における関連情報取得部25は、関連情報絞込部222によって絞り込みが行われた後の参照情報に基づいて、外部のシステムから医療情報を取得する。
図16は、図15に示す格納部221に格納されている役割関連情報のデータ構造の一例を示す。
図16に示すように、役割関連情報には、役割に対応づけて関連情報が含まれている。役割は、ミーティングを行う医療チームを構成する参加者の例えば職種を示す。関連情報は、対応づけられている役割に関連する医療情報の取得先(つまり、当該役割に関連する医療情報を保存している外部のシステム等)を示す。
図16に示す例では、役割関連情報には、役割「病理医」に対応づけて関連情報「*/HIS/*」が含まれている。これによれば、ミーティングを行う医療チームを構成する参加者のうち、職種が「病理医」である参加者に関連する医療情報は、病院情報システム(HIS)に保存されていることが示されている。
なお、役割関連情報は、ミーティングを行う医療チームを構成する参加者の全ての役割(職種)について予め用意されているものとする。
また、図16に示す関連情報は一例であり、当該関連情報は、各システムに応じてその表現方法を変更することが可能である。
次に、図17のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。
まず、前述した図4に示すステップS1〜S4の処理に相当するステップS31〜S34の処理が実行される。
次に、医療情報管理サーバ220に含まれる関連情報絞込部222は、ミーティングを行う医療チームを構成する参加者の役割を取得する(ステップS35)。この場合、ミーティングを行う医療チームを構成する参加者の役割は、当該ミーティングに関する情報を管理するシステム(例えば、MDTミーティングシステム)、カンファレンスシステム及びスケジューリングシステム等の外部のシステムから取得される。
関連情報絞込部222は、取得された参加者の役割及び格納部221に格納されている役割関連情報に基づいて、ステップS34において情報参照履歴変換部24によって変換された参照情報の絞り込みが行われる(ステップS36)。
ここで、ステップS36の処理について具体的に説明する。この場合、関連情報絞込部222は、取得された参加者の役割の各々に対応づけて役割関連情報に含まれる関連情報を取得する。具体的には、図16に示す役割関連情報が格納部221に格納されており、関連情報絞込部222によって取得された参加者の役割(職種)が「放射線科医」及び「看護師」である場合には、関連情報絞込部222は、図18に示すように、関連情報「*/PACS/*」、「*/RIS/*」及び「看護記録システム」を取得する。
次に、関連情報絞込部222は、情報参照履歴変換部24によって変換された参照情報を、取得された関連情報によって示される外部のシステムから取得される医療情報の保存位置を示すURIを含む参照情報に絞り込む。
ここで、上記した関連情報に含まれる「*」は任意の文字列を表している。このため、関連情報絞込部222によって取得された関連情報が例えば「*/PACS/*」である場合には、情報参照履歴変換部24によって変換された参照情報は、「/PACS/」を含むURI(参照情報)に絞り込まれる。他の関連情報についても同様である。
具体的には、図19に示すように、情報参照履歴変換部24によって変換された参照情報が「http://PACS/Patient99/001.dcm」、「¥¥HIS¥Patient99¥medication.html」及び「ftp://PACS/Patient99/002.dcm」の3つであり、関連情報絞込部222によって取得された関連情報が「*/PACS/*」、「*/RIS/*」及び「看護記録システム」である場合には、当該3つの変換後参照情報が「http://PACS/Patient99/001.dcm」及び「ftp://PACS/Patient99/002.dcm」の2つに絞り込まれる。ここでは、「*/PACS/*」で表されるURI(つまり、PACSを取得先とするURI)に絞り込まれている。
なお、図19においては、情報参照履歴変換部24によって変換された参照情報を変換後参照情報、関連情報絞込部222によって絞り込まれた後の参照情報を絞込後参照情報と表記している。
再び図17に戻ると、関連情報取得部25は、関連情報絞込部222によって絞り込まれた後の参照情報(絞込後参照情報)に基づいて、外部のシステムから医療情報(対象患者に関する医療情報)を取得する(ステップS37)。これにより、関連情報取得部25は、ミーティングを行う医療チームを構成する参加者の役割に関連する医療情報を取得することができる。
以下、図4に示すステップS6及びS7の処理に相当するステップS38及びS39の処理が実行される。
上記したように本実施形態においては、ミーティングを行う医療チームを構成する参加者の役割に関連する医療情報に絞り込んでクライアント端末10に送信する構成により、当該参加者にとって有用な医療情報(つまり、ミーティングに参加している参加者に関連する医療情報)のみをクライアント端末10において表示することが可能となる。
なお、本実施形態においては、役割関連情報が予め格納部221に格納されているものとして説明したが、役割関連情報は例えば情報参照履歴情報等から統計的に算出(生成)されても構わない。具体的には、例えば役割が「病理医」である参加者等から構成される医療チームによるミーティングにおいて病院情報システム(HIS)に保存されている医療情報が多く参照されている場合には、当該役割「病理医」に対応づけて関連情報「*/HIS/*」を含む役割関連情報を生成し、当該生成された役割関連情報を格納部221に格納するようにしても構わない。
(第6の実施形態)
次に、第6の実施形態について説明する。図20は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図1及び図15と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図1及び図15と異なる部分について主に述べる。
本実施形態に係る医療情報管理システムは、ミーティングを行う医療チームを構成する参加者の各々が保持する参加者端末において当該参加者の役割に関連する医療情報を表示する点が、前述した第5の実施形態とは異なる。
図20に示すように、医療情報管理システムは、クライアント端末(主クライアント端末)10、参加者端末(副クライアント端末)130及び医療情報管理サーバ230を備える。医療情報管理サーバ230は、クライアント端末10及び参加者端末130と通信可能に接続される。なお、参加者端末130はミーティングを行う医療チームを構成する参加者の各々によって保持されるが、図20においては、便宜的に1つの参加者端末130のみが示されている。
参加者端末130は、情報送受信部131及び情報表示部132を含む。情報送受信部131は、医療情報管理サーバ230との間で各種情報を送受信するための機能部である。
具体的には、情報送受信部131は、参加者端末130を保持する参加者(つまり、ミーティングを行う医療チームを構成する参加者)を識別するための個人ID及び当該個人IDに対するパスワードを医療情報管理サーバ230に対して送信する。また、情報送受信部131は、ミーティングにおいて議論される患者に関する医療情報を医療情報管理サーバ230から受信する。
情報表示部132は、各種情報を表示するための機能部である。具体的には、情報表示部132は、情報送受信部131によって受信された医療情報を、参加者端末130を保持する参加者に対して表示する。
医療情報管理サーバ230は、格納部231、認証部232及び関連情報送信部231を含む。
格納部231は、前述したログイン情報、情報参照履歴情報に加えて、個人用ログイン情報を更に格納する。個人用ログイン情報は、参加者端末130を保持する参加者が当該参加者端末130から医療情報管理システムにログインする際に用いられる情報である。なお、個人用ログイン情報には、参加者端末130を保持する参加者毎に、当該参加者を識別するための個人ID及び当該個人IDに対して予め定められているパスワードが対応づけて含まれている。
認証部232は、参加者端末130に含まれる情報送受信部131によって送信された個人ID及びパスワードを受信する。認証部232は、受信された個人ID及びパスワードと格納部231に格納されている個人用ログイン情報とに基づいて認証を行う。
関連情報送信部231は、関連情報取得部25によって取得された医療情報をクライアント端末10に送信する。また、関連情報送信部231は、関連情報取得部25によって取得された医療情報のうち、ミーティングを行う医療チームを構成する参加者の役割に関連する医療情報を、当該参加者が保持する参加者端末130に送信する。
次に、本実施形態に係る医療情報管理システムの動作について説明する。本実施形態に係る医療情報管理システムは、クライアント端末用の処理及び参加者端末用の処理を実行する。なお、クライアント端末用の処理は、前述した図17に示す処理と同様であるため、その詳しい説明を省略する。
ここで、図21のフローチャートを参照して、本実施形態に係る医療情報管理システムによって実行される参加者端末用の処理の処理手順について説明する。なお、参加者端末用の処理は、ミーティングの主催者がクライアント端末10から医療情報管理システムにログインした後に行われる。
まず、参加者端末130を保持する参加者は、医療情報管理システムにログインする必要がある。
この場合、参加者端末130を保持する参加者は、当該参加者端末130を操作することによって、当該参加者を識別するための個人ID及びパスワードを入力する。
このように参加者端末130を保持する参加者によって個人ID及びパスワードが入力された場合、当該参加者端末130に含まれる情報送受信部131は、当該入力された個人ID及びパスワードを医療情報管理サーバ230に送信する(ステップS41)。
医療情報管理サーバ230に含まれる認証部232は、参加者端末130(に含まれる情報送受信部131)によって送信された個人ID及びパスワードを受信する。
認証部232は、受信された個人ID及びパスワードと格納部231に格納されている個人用ログイン情報とに基づいて認証処理を実行し、当該認証の成功または失敗を判定する(ステップS42)。認証部232は、受信された個人ID及びパスワードが個人用ログイン情報において対応づけられている場合には、認証が成功したと判定する。一方、認証部232は、受信された個人ID及びパスワードが個人用ログイン情報において対応づけられていない場合には、認証が失敗したと判定する。
認証部232によって認証が失敗したと判定された場合(ステップS42のNO)、医療情報システムへのログインが拒否されて、処理が終了される。
一方、認証部232によって認証が成功したと判定された場合(ステップS42のYES)、参加者端末130を保持する参加者の医療情報管理システムへのログインが許可される。この場合、例えばミーティングの主催者は、クライアント端末10を介して、医療情報管理システムにログインしている参加者が保持する参加者端末130に対して医療情報を送信する旨のリクエストを送信することができる(ステップS43)。
クライアント端末10からリクエストが送信された場合、医療情報管理サーバ230では、医療情報管理システムにログインしている参加者毎に関連する医療情報が取得される(ステップS44)。ここでは詳細な説明を省略するが、医療情報管理システムにログインしている参加者の各々に関連する医療情報は、前述した図17に示すステップS33〜S37の処理と同様の処理が実行されることによって取得される。
次に、関連情報送信部233は、取得された医療情報管理システムにログインしている参加者の各々に関連する医療情報を、当該参加者によって保持される参加者端末130に送信する(ステップS45)。つまり、参加者によって保持される参加者端末130には、当該参加者に関連する医療情報が送信される。例えば前述した図16に示す役割関連情報が格納部231に格納されている場合、関連情報「*/HIS/*」によって示される病院情報システムから取得された医療情報(つまり、「*/HIS/*」で表されるURIに基づいてアクセス可能な医療情報)は、役割(職種)が「病理医」である参加者が保持する参加者端末130に送信される。
なお、関連情報送信部26は、医療情報とともに、ミーティングの主催者がログインする際に認証部232によって受信されたMDT IDに対応づけて情報参照履歴情報に含まれる使用アプリケーション情報を送信する。
参加者端末130に含まれる情報送受信部131は、関連情報送受信部233によって送信された医療情報及び使用アプリケーション情報を受信する。
情報表示部132は、情報送受信部131によって受信された医療情報及び使用アプリケーション情報に基づいて、当該医療情報を表示する。なお、医療情報を表示する際の具体的な処理については、前述した第1の実施形態等で説明した通りであるので、その詳しい説明を省略する。
つまり、上記した参加者端末用の処理によれば、参加者の各々が保持する参加者端末130には当該参加者に関連する医療情報が表示される。一方、クライアント端末用の処理によれば、前述した第5の実施形態において説明したように、クライアント端末10にはミーティングを行う医療チームを構成する全ての参加者の役割に関連する医療情報が表示される。
上記したように本実施形態においては、参加者の役割に関連する医療情報が当該参加者によって保持される参加者端末130において表示される構成により、当該参加者は自身に関連する医療情報を、全ての参加者が確認するクライアント端末10の表示に関係なく容易に確認することができる。
なお、本実施形態においては、医療情報管理サーバ230がクライアント端末10からのリクエストに応じて参加者が保持する参加者端末130に当該参加者に関連する医療情報を送信するものとして説明したが、参加者端末130からのリクエストに応じて当該医療情報が送信される構成であってもよいし、クライアント端末10及び参加者端末130からのリクエストがなくても自動的に当該医療情報が送信されるような構成であっても構わない。
(第7の実施形態)
次に、第7の実施形態について説明する。本実施形態に係る医療情報管理システムの構成は、前述した第1の実施形態と同様であるため、適宜、図1を用いて説明する。
本実施形態に係る医療情報管理システムは、ミーティングにおいて議論されている患者(対象患者)の患者情報に基づいて医療情報を更に取得する点が、前述した第1の実施形態とは異なる。
本実施形態に係る医療情報管理システムにおいて、医療情報管理サーバ20に含まれる格納部21は、ログイン情報及び情報参照履歴情報に加えて、患者履歴情報を更に格納している。
ここで、図22は、本実施形態における格納部21に格納されている患者履歴情報のデータ構造の一例を示す。
図22に示すように、患者履歴情報には、患者情報及び参照情報が対応づけて含まれる。患者情報は、患者を示す情報であり、当該患者が患っている主病名、関連病名、当該患者の既往歴及び年齢等を含む。参照情報は、対応づけられている患者情報によって示される患者について議論するための過去のミーティングにおいて参照された医療情報を参照するための情報(つまり、当該医療情報にアクセスするための情報)であり、具体的には、当該医療情報を保存している外部のシステムにおける当該医療情報の保存位置(つまり、当該医療情報の取得先)を示すURIを含む。
図22に示す例では、患者履歴情報には、例えば主病名「脳梗塞」及び年齢「45」を含む患者情報と参照情報「http://HIS/Patient01/治療計画.html」とが対応づけて含まれている。これによれば、主病名が脳梗塞で、年齢が45である患者について議論するための過去のミーティングにおいて「http://HIS/Patient01/治療計画.html」に基づいてアクセス可能な医療情報が参照されたことが示されている。
次に、図23のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。
まず、図4に示すステップS1及びS2の処理に相当するステップS51及びS52の処理が実行される。
次に、情報参照履歴取得部23は、対象患者(ミーティングにおいて議論される対象となる患者)を示す患者情報を取得する(ステップS53)。この患者情報は、患者ID等に基づいて、医療情報管理システムの外部の例えば病院情報システム(HIS)から取得される。なお、情報参照履歴取得部23によって取得される患者情報には、主病名、関連病名、既往歴及び年齢等が含まれる。以下、情報参照履歴取得部23によって取得された患者情報を対象患者情報と称する。
情報参照履歴取得部23は、格納部21に格納されている患者履歴情報に含まれる患者情報のうち、対象患者情報と類似する患者情報を特定する(ステップS54)。
この場合、例えば対象患者情報と患者履歴情報に含まれる患者情報とを比較し、当該対象患者情報と当該患者情報との間で一致する項目の数をカウントすることによって、当該対象患者情報及び当該患者情報の相関値を算出する。これにより、例えば対象患者情報との相関値が予め定められた値以上の患者情報を、対象患者情報と類似する患者情報として特定することができる。なお、ここで説明した対象患者情報と類似する患者情報を特定するための処理は一例であり、他の処理によって対象患者情報と類似する患者情報が特定されても構わない。
次に、情報参照履歴取得部23は、格納部21に格納されている情報参照履歴情報及び患者履歴情報から参照情報を取得する(ステップS55)。具体的には、情報参照履歴取得部23は、認証部22によって受信されたMDT IDに対応づけて情報参照履歴情報に含まれる参照情報を取得する。また、情報参照履歴取得部23は、上記したように特定された患者情報に対応づけて患者履歴情報に含まれる参照情報を取得する。
以下、情報参照履歴取得部23によって取得された参照情報(情報参照履歴情報に含まれる参照情報及び患者履歴情報に含まれる参照情報)に対して前述した図4に示すステッS4の処理に相当するステップS56の処理が実行され、その後、当該図4に示すステップS5〜S7の処理に相当するステップS57〜S59の処理が実行される。
上記したように本実施形態においては、対象患者情報に類似する患者情報に対応づけて患者履歴情報に含まれる参照情報に基づいて取得された対象患者に関する医療情報がクライアント端末10において更に表示されるため、前述した第1の実施形態と比較して、ミーティングにおいて必要な医療情報を漏れなくクライアント端末10において表示することが可能となる。
(第8の実施形態)
次に、第8の実施形態について説明する。図24は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図1と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図1と異なる部分について主に述べる。
本実施形態に係る医療情報管理システムは、ミーティングにおいて議論されている患者(対象患者)に関する医療情報と過去の医療情報との差分をクライアント端末において表示する点が、前述した第1の実施形態とは異なる。
図24に示すように、医療情報管理システムは、クライアント端末10及び当該クライアント端末10と通信可能に接続される医療情報管理サーバ240を備える。
医療情報管理サーバ240は、格納部241及び情報比較部242を含む。
格納部241は、前述した第1の実施形態において説明したログイン情報に加えて、差分管理情報を更に格納する。格納部241に格納されている差分管理情報は、ミーティングにおいて参照された医療情報と当該医療情報より過去の医療情報(当該ミーティングより前にアクセスされた医療情報)との差分を示す差分情報を取得するための差分情報パスを含む。
ここで、クライアント端末10は、ミーティングにおいて議論されている患者に関する医療情報のリクエストを医療情報管理サーバ240に送信することができる。なお、クライアント端末10によって送信されるリクエストには、当該リクエストの対象となる医療情報の保存位置(取得先)を示すURIが含まれる。
情報比較部242は、クライアント端末10からリクエストが送信された場合、当該リクエストに含まれるURI、認証部22によって受信されたMDT ID及び格納部241に格納されている差分管理情報に基づいて、当該URIに基づいてアクセス可能な医療情報に関する差分情報を取得する。
情報比較部242は、クライアント端末10によって送信されたリクエストに含まれるURIに基づいて、外部のシステムから医療情報を取得する。
情報比較部242は、取得された差分情報と医療情報とを比較することによって当該差分情報と医療情報との差分を示す差分情報を生成する。
情報比較部242は、生成された差分情報に基づいて、外部のシステムから取得された医療情報に対して差分強調処理を実行する。
情報比較部242によって差分強調処理が実行された医療情報は、関連情報送信部26によってクライアント端末10に送信される。また、関連情報送信部26によって送信された医療情報は、クライアント端末10に含まれる情報送受信部11によって受信されて、情報表示部12によって表示される。
図25は、図24に示す格納部241に格納されている差分管理情報のデータ構造の一例を示す。
図25に示すように、差分管理情報には、MDT ID、作成日時及び差分情報パスが対応づけて含まれている。作成日は、差分情報が生成された日を示す。差分情報パスは、対応づけられているMDT IDによって示される種別の医療チームによるミーティングにおいて、対応づけられている作成日に参照された医療情報と当該ミーティングより前にアクセスされた医療情報との差分を示す差分情報(当該差分が記載されたファイル)を参照(取得)するための情報であり、例えば当該差分情報の保存位置(取得先)を示すURIを含む。なお、MDT IDは前述した第1の実施形態において説明した通りであるため、その詳しい説明を省略する。
図25に示す例では、差分管理情報には、例えばMDT ID「Cancer」、作成日「2012/03/01」及び差分情報パス「http://PACS/Patient01/001.dcm.Cancer_20120301_diff」が対応づけて含まれている。これによれば、MDT ID「Cancer」によって示される種別の医療チーム(癌を対象とする医療チーム)による2012年3月1日のミーティングにおいて参照された医療情報と当該2012年3月1日より前にアクセスされた医療情報との差分を示す差分情報が「http://PACS/Patient01/001.dcm.Cancer_20120301_diff」に示す保存位置に保存されていることが示されている。
なお、上記した差分管理情報は、ミーティングが行われる度(つまり、当該ミーティングにおいて医療情報が参照される度)に更新される。
次に、図26のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。
まず、前述した図4に示すステップS1及びS2の処理に相当するステップS61及びS62の処理が実行される。
ここで、例えばミーティングの主催者は、クライアント端末10を介して、当該ミーティングにおいて議論されている患者に関する医療情報のリクエストを送信することができる(ステップS63)。このリクエストには、当該リクエストの対象となる医療情報を取得するためのURIが含まれる。なお、医療情報のリクエストは、ブラウザやファイルシステム等を通して医療管理サーバ240に送信される。
情報比較部242は、クライアント端末10によって送信されたリクエストを受信する。情報比較部242は、受信されたリクエストに含まれるURI及び格納部241に格納されている差分管理情報を参照し、認証部22によって受信されたMDT IDに対応づけて当該差分管理情報に含まれている差分情報パスを検索する(ステップS64)。この場合、情報比較部242は、認証部22によって受信されたMDT IDに対応づけて差分管理情報に含まれている差分情報パスであって、受信されたリクエストに含まれるURIを含む差分情報パスを検索する。なお、検索された差分情報パスが複数存在する場合には、情報比較部242は、当該差分情報パスに対応づけて差分管理情報に含まれている作成日が最新の差分情報パスを取得する。
具体的には、認証部22によって受信されたMDT IDが「Cancer」であり、格納部241に上述した図25に示す差分管理情報が格納されており、情報比較部242によって受信されたリクエストに含まれるURIが「http://PACS/Patient01/002.dcm」である場合には、情報比較部242は、差分情報パス「http://PACS/Patient01/002.dcm.Cancer_20120301_diff」を取得する。
次に、情報比較部242は、取得された差分情報パスに基づいて、差分情報を取得する。また、情報比較部242は、受信されたリクエストに含まれるURIに基づいて、外部のシステムから医療情報を取得する。
情報比較部242は、取得された差分情報と医療情報とを比較し、例えば文字列処理によって文字列単位やバイナリ単位で当該差分情報と医療情報との差分をとる。これにより、情報比較部242は、差分情報を生成する(ステップS65)。
なお、情報比較部242によって生成された差分情報は、上記した情報比較部242によって受信されたリクエストに含まれるURIの末尾に認証部22によって受信されたMDT ID及び当該差分情報が生成された日(作成日)が付与されたものをファイル名とし、情報比較部242によって取得された差分情報と同一のフォルダに保存される。
次に、情報比較部242は、生成された差分情報に基づいて、取得された医療情報(つまり、クライアント端末10によってリクエストされた医療情報)に対する差分強調処理を実行する(ステップS66)。この場合、情報比較部242は、医療情報及び差分情報の双方に含まれる文字列や画像に対して強調表示処理を行う。具体的には、医療情報がHTMLファイルの場合はHTMLタグのBoldや色変更のためのタグ等を付与する処理を行う。また、医療情報が画像の場合は、画素値に差が生じる画素の画素値を変更する、またはアノテーションを付与することによって差分画像を生成し、原画像に付与する処理を行う。なお、画像に対して差分強調処理を行う場合、図27に示すように、濃度値の差を色で表現した差分画像(差分強調処理された画像)を必要に応じてレジストレーション(画像相互位置合わせ)する等により、現在及び過去の画像(医療情報)と比較しやすい画像を提供することが好ましい。
情報比較部242によって差分強調処理が実行された医療情報は、関連情報送信部26によってクライアント端末10に送信される(ステップS67)。
また、関連情報送信部26によって送信された医療情報は、クライアント端末10において使用されているブラウザ等のアプリケーションで表示される(ステップS68)。
上記したように本実施形態においては、ミーティング中にクライアント端末10によってリクエストされた医療情報(現在の医療情報)と当該医療情報より過去にアクセスされた医療情報(過去の医療情報)との差分を示す差分情報に基づいて差分強調処理が行われ、当該差分強調処理が行われた医療情報が当該クライアント端末10において表示される構成により、当該ミーティングにおいて当該現在の医療情報と過去の医療情報との差分を容易に把握することが可能となる。
なお、例えば医療情報が心拍数等を含む検査結果である場合には、現在の医療情報と過去の医療情報との差分情報には、現在の検査結果及び過去の検査結果の差を表す数値等が含まれていても構わない。このような差分情報に含まれる数値がクライアント端末10において強調表示されることによって、ミーティングにおいて対象患者の心拍数の数値の変化等を容易に認識することができる。
また、本実施形態においては、クライアント端末10によって送信されたリクエストに含まれるURIに対して図26に示すステップS64以降の処理が実行されるものとして説明したが、例えば前述した第1の実施形態における情報参照履歴変換部24によって変換された参照情報(変換ご参照情報)に含まれるURIに対して図26に示すステップS64以降の処理が実行されても構わない。
(第9の実施形態)
次に、第9の実施形態について説明する。図28は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図1と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図1と異なる部分について主に述べる。
本実施形態に係る医療情報管理システムは、ミーティング中の参加者の発言内容から議論の内容を判別し、当該議論の内容に関連した医療情報をクライアント端末において表示する点が、前述した第1の実施形態とは異なる。
図24に示すように、医療情報管理システムは、クライアント端末150及び当該クライアント端末150と通信可能に接続される医療情報管理サーバ250を備える。
クライアント端末150は、音声取得部151及び情報送受信部152を含む。音声取得部151は、患者について議論するためのミーティングにおける当該ミーティングの参加者の音声を取得する。
情報送受信部152は、音声取得部151によって取得された音声の情報(以下、音声情報と表記)を、医療情報管理サーバ250に送信する。また、情報送受信部11は、ミーティングにおいて議論されている患者に関する医療情報を医療情報管理サーバ20から受信する。
医療情報管理サーバ250は、格納部251、音声分類部252及び関連情報取得部253を含む。
格納部251には、ミーティングにおける議論の内容を表すカテゴリに関連する医療情報の取得先を示すカテゴリ別関連情報が予め格納されている。
音声分類部252は、クライアント端末150に含まれる情報送受信部152によって送信された音声情報を受信する。音声分類部252は、取得された音声情報に対して音声認識処理を実行する。音声分類部252は、音声認識処理結果に基づいて、ミーティングにおける議論の内容を表すカテゴリを決定する。
関連情報取得部253は、ミーティングにおいて議論されている患者を識別するための患者IDを取得する。関連情報取得部253は、格納部251に格納されているカテゴリ別関連情報、音声分類部252によって決定されたカテゴリ及び取得された患者IDに基づいて、当該カテゴリに関連する医療情報であって当該患者IDによって識別される患者に関する医療情報を、外部のシステムから取得する。
関連情報取得部253によって取得された医療情報は、関連情報送信部26によってクライアント端末150に送信される。また、関連情報送信部26によって送信された医療情報は、クライアント端末150に含まれる情報送受信部152によって受信されて、情報表示部12によって表示される。
図29は、図28に示す格納部251に格納されているカテゴリ別関連情報のデータ構造の一例を示す。
図29に示すように、カテゴリ別関連情報には、カテゴリに対応づけて参照情報が含まれている。カテゴリは、ミーティングにおける議論の内容を表す。参照情報は、対応づけられているカテゴリ(議論の内容)に関連する医療情報を参照するための情報(つまり、当該医療情報にアクセスするための情報)であり、例えば当該医療情報の取得先であるURIを表す。
図29に示す例では、カテゴリ別関連情報には、例えばカテゴリ「癌」に対応づけて参照情報「*/pathologicalImage/*」及び「*/PACS/Patient*/*.dcm」が含まれている。これによれば、癌に関連する医療情報が「*/pathologicalImage/*」及び「*/PACS/Patient*/*.dcm」によって表されるURIに基づいて取得可能であることが示されている。なお、カテゴリ別関連情報に含まれる参照情報に含まれる「*」は任意の文字列を表している。
次に、図30のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。
まず、クライアント端末150に含まれる音声取得部151は、例えばマイク等の集音機器を用いてミーティング中の参加者の発言(音声情報)を収集する(ステップS71)。音声取得部151によって収集(取得)された音声情報は、医療情報管理サーバ250に送信される。
医療情報管理サーバ250に含まれる音声分類部252は、クライアント端末150(に含まれる情報送受信部152)によって送信された音声情報を受信する。
音声分類部252は、受信された音声情報に対して音声認識処理を実行する(ステップS72)。具体的には、音声分類部252は、例えば言語モデルを用いた統計的音声認識手法や、隠れマルコフモデルやルールベースによる音声認識手法等を用いて、音声情報に対してカテゴリ分類を行う。
音声分類部252は、このような音声認識処理結果に基づいて、受信された音声情報のカテゴリ(ミーティングにおける議論の内容を表すカテゴリ)を決定する(ステップS73)。
次に、関連情報取得部253は、ミーティングにおいて議論されている患者(対象患者)に関する患者ID(対象患者ID)を取得する。なお、対象患者IDは、例えば病院外または病院内のシステム(MDTミーティングシステム等)から取得される。
関連情報取得部253は、格納部251に格納されているカテゴリ別関連情報、音声分類部252によって決定されたカテゴリ及び対象患者IDに基づいて医療情報を取得する(ステップS74)。
ここで、関連情報取得部253による医療情報の取得処理について具体的に説明する。この場合、関連情報取得部253は、格納部251に格納されているカテゴリ別関連情報を参照して、音声分類部252によって決定されたカテゴリに対応づけて当該カテゴリ別関連情報に含まれている参照情報を取得する。
次に、関連情報取得部253は、取得された参照情報によって表されるURIの患者IDに対応する部分を対象患者IDに基づいて変換する。具体的には、例えば関連情報取得部253によって取得された参照情報が図29に示す「*/PACS/Patient*/*.dcm」であり、対象患者IDが「Patient99」である場合には、関連情報取得部253は、当該「*/PACS/Patient*/*.dcm」を「*/PACS/Patient99/*.dcm」に変換する。
関連情報取得部253は、変換された参照情報に基づいて医療情報を外部のシステムから取得する。上記したように参照情報が「*/PACS/Patient99/*.dcm」に変換された場合には、当該「*/PACS/Patient99/*.dcm」の「*」の部分に任意の文字列を含むURIに基づいてアクセス可能な医療情報が取得される。
これにより、関連情報取得部253は、ミーティングにおける議論の内容に関連する医療情報であって、対象患者に関する医療情報を取得することができる。
関連情報取得部253によって取得された医療情報は、関連情報送信部26によってクライアント端末150に送信される(ステップS75)。
クライアント端末150に含まれる情報表示部12は、関連情報送信部26によって送信された医療情報を、当該クライアント端末150において使用されているアプリケーションまたは当該医療情報を表示する可能なアプリケーションで表示する(ステップS76)。
なお、図30に示す処理を定期的に実行することにより、例えばミーティング中に議題(議論の内容)が変わった場合であっても、当該議論の内容の変化に応じて適切な医療情報をクライアント端末150において表示することが可能である。
上記したように本実施形態においては、ミーティング中の参加者の音声に基づいて取得された医療情報がクライアント端末150において表示される構成により、ミーティングにおける議論の内容に応じた医療情報を迅速に表示することが可能となる。
以上説明した実施形態によれば、患者に関する情報を迅速に表示することが可能な医療情報管理システムを提供することが可能となる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。