JP6062224B2 - 医療情報管理システム - Google Patents

Description

本発明の実施形態は、医療情報管理システムに関する。

近年では、患者中心の医療を実現するために、多くの病院においてチーム医療が導入されている。

チーム医療とは、患者自身もチームの一員と考えて医療に参加し、当該医療に関わる全ての職種がそれぞれの専門性を発揮することで、当該患者の満足度をより高めることを目指した医療をいう。

なお、チーム医療に関わる職種には、例えば医師、看護師、薬剤師、栄養士等の様々な職種が含まれる。また、チーム医療においては、直接医療を提供するチームのみならず、福祉職、心理職、スピリチュアルケア等の患者及び当該患者の家族をサポートするチームや、家族・友人、企業、マスコミ、政府等を含めた医療や患者を取り巻く社会資源からなるチームも含まれる。

医療は医師を頂点とした指示体制に基づいて行われることが主流であったが、チーム医療は、各職種が平等な関係にある。また、チーム医療においては、それぞれの職種が有する専門的な意見をもとに患者とともに議論し、そこで得られたチームのコンセンサスに基づいて協働しながら医療が行われる。従って、各職種の行動は、チームとしての責任を負う必要がある。更に、チーム医療では、状況に応じて、それぞれの職種がリーダーシップを発揮し、相互尊重することが求められる。

ところで、上記したチーム医療においては、ＭＤＴ（Multidisciplinary Team）ミーティングと呼ばれるものが行われる。なお、ＭＤＴとはチーム医療と同義であり、ＭＤＴミーティングは、ＭＤＴの目的である「患者中心の医療」を実現するための１つの手段である。

定期的に開催されるＭＤＴミーティングでは、当該ＭＤＴミーティングに参加する上記の各職種の担当者（以下、ＭＤＴメンバと表記）によって患者に対する治療方針等の議論が行われ、当該ＭＤＴメンバそれぞれの専門性を生かして結論が出される。なお、ＭＤＴミーティングは、例えば巨大スクリーンや遠隔地とのテレビ会議システム等の会議システムを利用して行われる。

特開２００８−０９０７１５号公報

ところで、ＭＤＴミーティングにおける議論のためには患者に関する情報が必要となるが、ＭＤＴメンバは専門性が異なるため、当該ＭＤＴミーティングにおいて必要となる情報も多岐にわたる。

また、ＭＤＴミーティングは時間に限りがあるため、議題に上がる患者１人あたり数分で結論が出される場合が多い。

このため、ＭＤＴミーティングにおいては、患者に関する情報を迅速に表示する（または切り替える）ことが重要となる。

そこで、本発明が解決しようとする課題は、議論に必要な患者情報を迅速に表示することが可能な医療情報管理システムを提供することにある。

実施形態によれば、クライアント端末及び当該クライアント端末と通信可能な状態で接続される医療情報管理サーバを具備する医療情報管理システムが提供される。

前記クライアント端末は、送信手段と、表示手段とを含む。

前記医療情報管理サーバは、格納手段と、第１の取得手段と、第２の取得手段と、第３の取得手段とを含む。

前記格納手段は、患者について議論するための過去のミーティングにおいて参照された当該患者に関する第１の医療情報を参照するための参照情報を、当該ミーティングを行った複数の参加者から構成される医療チームの種別を示す種別情報に対応づけて含む情報参照履歴情報を予め格納する。

前記送信手段は、患者について議論するためのミーティングを行う医療チームの種別を示す種別情報を前記医療情報管理サーバに送信する。

前記第１の取得手段は、前記送信された種別情報に対応づけて前記情報参照履歴情報に含まれる第１の医療情報を参照するための参照情報を取得する。

前記第２の取得手段は、前記送信された種別情報によって示される種別の医療チームが行うミーティングにおいて議論される患者を識別するための患者識別情報を取得する。

前記第３の取得手段は、前記第１の取得手段によって取得された第１の医療情報を参照するための参照情報に基づいて、前記第２の取得手段によって取得された患者識別情報によって識別される患者に関する第２の医療情報を取得する。

前記表示手段は、前記第３の取得手段によって取得された第２の医療情報を表示する。

第１の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図。 図１に示す格納部２１に格納されているログイン情報のデータ構造の一例を示す図。 図１に示す格納部２１に格納されている情報参照履歴情報のデータ構造の一例を示す図。 本実施形態に係る医療情報管理システムの処理手順を示すフローチャート。 情報参照履歴取得部２３によって取得される参照情報について説明するための図。 図５に示す参照情報が情報参照履歴変換部２４によって変換された場合について説明するための図。 クライアント端末２０において医療情報が表示された際の表示画面について説明するための図。 第２の実施形態における格納部２１に格納されている情報参照履歴情報のデータ構造の一例を示す図。 情報表示部１２によって医療情報が表示された際のクライアント端末１０の表示画面の一例を示す図。 第３の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図。 本実施形態に係る医療情報管理システムの処理手順を示すフローチャート。 情報表示部１２によって医療情報が表示された際のクライアント端末１００の表示画面の一例を示す図。 第４の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図。 本実施形態に係る医療情報管理システムによって実行される情報参照履歴更新処理の処理手順を示すフローチャート。 第５の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図。 図１５に示す格納部２２１に格納されている役割関連情報のデータ構造の一例を示す図。 本実施形態に係る医療情報管理システムの処理手順を示すフローチャート。 関連情報絞込部２２２によって取得される関連情報について説明するための図。 関連情報絞込部２２２によって変換後参照情報が絞り込まれた結果について説明するための図。 第６の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図。 本実施形態に係る医療情報管理システムによって実行される参加者端末用の処理の処理手順を示すフローチャート。 第７の実施形態における格納部２１に格納されている患者履歴情報のデータ構造の一例を示す図。 本実施形態に係る医療情報管理システムの処理手順を示すフローチャート。 第８の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図。 図２４に示す格納部２４１に格納されている差分管理情報のデータ構造の一例を示す図。 本実施形態に係る医療情報管理システムの処理手順を示すフローチャート。 差分強調処理が行われた画像について説明するための図。 第９の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図。 図２８に示す格納部２５１に格納されているカテゴリ別関連情報のデータ構造の一例を示す図。 本実施形態に係る医療情報管理システムの処理手順を示すフローチャート。

以下、図面を参照して、各実施形態について説明する。

（第１の実施形態）
図１は、第１の実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。本実施形態に係る医療情報管理システムは、例えば複数の職種の参加者から構成される医療チームによって患者に対する治療を行うチーム医療（ＭＤＴ：Multidisciplinary Team）における、患者に対する治療方針等について議論するための当該医療チームのミーティング（ＭＤＴミーティング）の際に用いられる。

図１に示すように、医療情報管理システムは、クライアント端末１０及び当該クライアント端末１０と通信可能に接続される医療情報管理サーバ２０を備える。

また、医療情報管理サーバ２０は、図示しないが、例えば画像保存通信システム（ＰＡＣＳ：Picture Archiving and Communication Systems）、病院情報システム（ＨＩＳ：Hospital Information System）、放射線科情報システム（ＲＩＳ：Radiology Information System）及び看護記録システム等の種々の外部のシステムとネットワークを介して通信可能に接続されている。なお、これらの外部のシステムにおいては、それぞれ所定の規則に従って各種医療情報（画像データ、投薬記録、看護記録等）が保存されているものとする。

クライアント端末１０は、情報送受信部１１及び情報表示部１２を含む。情報送受信部１１は、医療情報管理サーバ２０との間で各種情報を送受信するための機能部である。

具体的には、情報送受信部１１は、ミーティングを行う医療チームの種別を示す種別情報（以下、ＭＤＴ ＩＤと表記）及び医療情報管理システムにログインするためのパスワードを医療情報管理サーバ２０に対して送信する。なお、医療チームの種別とは、当該医療チームによるチーム医療が対象とする疾病や目的の種別であり、例えば癌を対象とするチーム、脳卒中を対象とするチーム及び栄養サポートを目的とするチーム等の種別がある。

また、情報送受信部１１は、後述するようにミーティングにおいて議論されている患者に関する医療情報を医療情報管理サーバ２０から受信する。情報送受信部１１によって受信される医療情報には、上記した画像保存通信システム、病院情報システム、放射線科情報システム及び看護記録システム等の外部のシステムにおいて保存されている画像データやその他のデータ等が含まれる。

情報表示部１２は、各種情報を表示するための機能部である。具体的には、情報表示部１２は、情報送受信部１１によって受信された医療情報を、医療チームを構成する参加者に対して表示する。

医療情報管理サーバ２０は、格納部２１、認証部２２、情報参照履歴取得部２３、情報参照履歴変換部２４、関連情報取得部２５及び関連情報送信部２６を含む。

格納部２１には、ログイン情報及び情報参照履歴情報が予め格納されている。ログイン情報は、上記したミーティングを行う医療チーム（当該ミーティングの主催者）が医療情報管理システムにログインする際に用いられる情報である。情報参照履歴情報は、医療チームが過去のミーティングにおいて参照した医療情報の履歴を示す情報である。具体的には、情報参照履歴情報は、過去のミーティングにおいて参照された患者に関する医療情報を参照するための方法（参照情報）を、当該ミーティングを行った医療チームの種別を示す種別情報（ＭＤＴ ＩＤ）に対応づけて含む。なお、ログイン情報及び情報参照履歴情報の詳細については後述する。

認証部２２は、クライアント端末１０に含まれる情報送受信部１１によって送信されたＭＤＴ ＩＤ及びパスワードを受信する。認証部２２は、受信されたＭＤＴ ＩＤ及びパスワードと格納部２１に格納されているログイン情報とに基づいて認証を行う。

情報参照履歴取得部２３は、格納部２１に格納されている情報参照履歴情報を参照して、認証部２２によって受信されたＭＤＴ ＩＤに対応づけて当該情報参照履歴情報に含まれる参照情報（医療情報を参照するための参照情報）を取得する。

情報参照履歴変換部２４は、認証部２２によって受信されたＭＤＴ ＩＤによって示される種別の医療チームが行うミーティングにおいて議論されている患者を識別するための患者識別情報（以下、患者ＩＤと表記）を取得する。情報参照履歴変換部２４は、情報参照履歴取得部２３によって取得された参照情報を、認証部２２によって受信された患者ＩＤに基づいて変換する処理を行う。

関連情報取得部２５は、情報参照履歴変換部２４によって変換された参照情報に基づいて、外部のシステムから医療情報を取得する。ここで関連情報取得部２５によって取得される医療情報は、情報参照履歴取得部２３によって取得された参照情報を用いて参照することができる医療情報に対応する医療情報（つまり、当該参照情報を用いて参照することができる医療情報と同じ種類の医療情報）であって、ミーティングにおいて議論される患者に関する医療情報である。

関連情報送信部２６は、関連情報取得部２５によって取得された医療情報をクライアント端末１０に送信する。関連情報送信部２６によって送信された医療情報は、クライアント端末１０に含まれる情報送受信部１１によって受信され、当該クライアント端末１０に含まれる情報表示部１２によって表示される。

図２は、図１に示す格納部２１に格納されているログイン情報のデータ構造の一例を示す。

図２に示すように、ログイン情報には、ＭＤＴ ＩＤ及びパスワードが対応づけて含まれる。ＭＤＴ ＩＤは、患者について議論するためのミーティングを行う医療チームの種別を示す。パスワードは、対応づけられているＭＤＴ ＩＤによって示される種別の医療チームに対して予め定められているパスワードである。

図２に示す例では、ログイン情報には、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」及びパスワード「○○○○」が対応づけて含まれている。これによれば、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」によって示される種別の医療チームは、パスワード「○○○○」によってログイン可能であることが示されている。なお、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」は、癌を対象とする医療チームの種別を示す。

ここでは詳しい説明を省略するが、ログイン情報においては、他のＭＤＴ ＩＤについても同様にパスワードが規定されている。

図３は、図１に示す格納部２１に格納されている情報参照履歴情報のデータ構造の一例を示す。

図３に示すように、情報参照履歴情報には、ＭＤＴ ＩＤに対応づけて使用アプリケーション情報及び参照情報（参照方法）が含まれている。ＭＤＴ ＩＤは、上記したように医療チームの種別を示す。使用アプリケーション情報は、対応づけられているＭＤＴ ＩＤによって示される種別の医療チームが過去のミーティングにおいて医療情報を参照した際に使用したアプリケーションを示す。参照情報は、対応づけられているＭＤＴ ＩＤによって示される種別の医療チームが過去のミーティングにおいて参照した医療情報を参照するための情報（つまり、当該医療情報にアクセスするための情報）であり、具体的には、当該医療情報を保存している外部のシステムにおける当該医療情報の保存位置（つまり、当該医療情報の取得先）を示すＵＲＩ（Uniform Resource Identifier）を含む。

図３に示す例では、情報参照履歴情報には、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」に対応づけて使用アプリケーション「ＤＩＣＯＭビューワ」及び参照情報「ｈｔｔｐ：／／ＰＡＣＳ／ｐａｔｉｅｎｔ０１／００１．ｄｃｍ」が含まれている。これによれば、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」によって示される種別の医療チーム（癌を対象とする医療チーム）が過去のミーティングにおいてＤＩＣＯＭビューワを使用して「ｈｔｔｐ：／／ＰＡＣＳ／ｐａｔｉｅｎｔ０１／００１．ｄｃｍ」に基づいてアクセス可能な医療情報を参照したことが示されている。

このように情報参照履歴情報によれば、過去のミーティングにおいて参照された医療情報の履歴が示される。

次に、図４のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。

まず、患者について議論するためのミーティングにおいて医療情報管理システムを利用する場合、例えば当該ミーティングの主催者（当該ミーティングを行う医療チームを構成する参加者）は、当該医療情報管理システムにログインする必要がある。

この場合、ミーティングの主催者は、例えば当該ミーティングの開始時に、クライアント端末１０を操作することによって、当該ミーティングを行う医療チームの種別を示すＭＤＴ ＩＤ及びパスワードを入力する。

なお、医療チームのミーティングにおいて議論される患者を対象患者と称する。以下に説明する他の実施形態においても同様であるものとする。

このようにミーティングの主催者によってＭＤＴ ＩＤ及びパスワードが入力された場合、クライアント端末１０に含まれる情報送受信部１１は、当該入力されたＭＤＴ ＩＤ及びパスワードを医療情報管理サーバ２０に送信する（ステップＳ１）。

医療情報管理サーバ２０に含まれる認証部２２は、クライアント端末１０（に含まれる情報送受信部１１）によって送信されたＭＤＴ ＩＤ及びパスワードを受信する。

認証部２２は、受信されたＭＤＴ ＩＤ及びパスワードと格納部２１に格納されているログイン情報とに基づいて認証処理を実行し、当該認証の成功または失敗を判定する（ステップＳ２）。認証部２２は、受信されたＭＤＴ ＩＤ及びパスワードがログイン情報において対応づけられている場合には、認証が成功したと判定する。一方、認証部２２は、受信されたＭＤＴ ＩＤ及びパスワードがログイン情報において対応づけられていない場合には、認証が失敗したと判定する。なお、認証部２２による認証処理は、例えばＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙやＳＳＨ等を用いて実行される。

認証部２２によって認証が失敗したと判定された場合（ステップＳ２のＮＯ）、医療情報管理システムへのログインが拒否されて、処理が終了される。

一方、認証部２２によって認証が成功したと判定された場合（ステップＳ２のＹＥＳ）、医療チーム（ミーティングの主催者）の医療情報管理システムへのログインが許可される。この場合、情報参照履歴取得部２３は、格納部２１に格納されている情報参照履歴情報を参照して、認証部２２によって受信されたＭＤＴ ＩＤ（つまり、ログイン中のＭＤＴ ＩＤ）に対応づけて当該情報参照履歴情報に含まれる参照情報（ＵＲＩ）を取得する（ステップＳ３）。なお、参照情報は、例えば問い合わせ言語であるＳＱＬ等を用いることによって格納部２１から取得することができる。

ここで、上記した図３に示す情報参照履歴情報が格納部２１に格納されており、認証部２２によってＭＤＴ ＩＤとして「Ｃａｎｃｅｒ」が受信された場合には、図５に示すようにＭＤＴ ＩＤ「Ｃａｎｃｅｒ」に対応づけて当該情報参照履歴情報に含まれている参照情報が取得される。

次に、情報参照履歴変換部２４は、情報参照履歴取得部２３によって取得されたＵＲＩ（文字列）を解析し、当該ＵＲＩを対象患者（つまり、現在議論されている患者）に関する医療情報にアクセスするためのＵＲＩに変換する（ステップＳ４）。

ここで、情報参照履歴変換部２４によるＵＲＩの変換処理について具体的に説明する。この場合、情報参照履歴変換部２４は、対象患者を識別するための患者識別情報（以下、患者ＩＤと表記）を、例えば病院外または病院内のシステム（ＭＤＴミーティングシステム等）から取得する。以下、対象患者を識別するための患者ＩＤを対象患者ＩＤと称する。

次に、情報参照履歴変換部２４は、情報参照履歴取得部２３によって取得されたＵＲＩに含まれる患者ＩＤを特定する。情報参照履歴変換部２４は、特定された患者ＩＤ（情報参照履歴取得部２３によって取得されたＵＲＩに含まれる患者ＩＤ）を、対象患者ＩＤに置き換える。これによって、情報参照履歴取得部２３によって取得されたＵＲＩは、対象患者ＩＤを含むＵＲＩに変換される。なお、ＵＲＩに含まれる患者ＩＤは、例えば外部のシステム（ＰＡＣＳ、ＨＩＳ、ＲＩＳ及び看護記録システム等）に備えられるデータベース（ＤＢ）を参照することにより認識することができるものとする。

ここで、例えば図５に示す参照情報「￥￥ＨＩＳ￥Ｐａｔｉｅｎｔ０１￥ｍｅｄｉｃａｔｉｎ．ｈｔｍｌ」を用いて具体的に説明すると、当該参照情報（つまり、ＵＲＩ）においては、患者ＩＤ「Ｐａｔｉｅｎｔ０１」が含まれている。対象患者ＩＤが例えば「Ｐａｔｉｅｎｔ９９」である場合を想定すると、参照情報「￥￥ＨＩＳ￥Ｐａｔｉｅｎｔ０１￥ｍｅｄｉｃａｔｉｎ．ｈｔｍｌ」は、参照情報「￥￥ＨＩＳ￥Ｐａｔｉｅｎｔ９９￥ｍｅｄｉｃａｔｉｎ．ｈｔｍｌ」に変換される。なお、対象患者ＩＤが「Ｐａｔｉｅｎｔ９９」である場合における図５に示す各参照情報の変換結果は、図６に示すようになる。以下、情報参照履歴変換部２４によって変換される前の参照情報を変換前参照情報と称し、情報参照履歴変換部２４によって変換された後の参照情報を変換後参照情報と称する。

上記したように医療情報管理サーバ２０と通信可能な外部のシステム（ＰＡＣＳ、ＨＩＳ、ＲＩＳ及び看護記録システム等）では、所定の規則に従って医療情報が保存されている。このため、図６に示す例えば変換前参照情報「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ０１／００１．ｄｃｍ」に基づいてアクセス可能な医療情報が患者ＩＤ「Ｐａｔｉｅｎｔ０１」によって識別される患者に関するＤＩＣＯＭデータ（画像データ）である場合、変換後参照情報「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／００１．ｄｃｍ」に基づいてアクセス可能な医療情報は、当該変換前参照情報に基づいてアクセス可能なＤＩＣＯＭデータと同種のＤＩＣＯＭデータであって、患者ＩＤ「Ｐａｔｉｅｎｔ９９」によって識別される患者に関するＤＩＣＯＭデータとなる。

なお、ここで説明した参照情報の変換処理は一例であり、当該参照情報の変換処理は、外部のシステムにおける医療情報の保存方法等に応じて適宜変更されても構わない。つまり、情報参照履歴取得部２３によって取得された参照情報は、当該参照情報によって参照される医療情報と同様な対象患者に関する医療情報を取得可能な情報に変換されればよい。

次に、関連情報取得部２５は、情報参照履歴変換部２４によって変換された参照情報（つまり、変換後参照情報）に基づいて、外部のシステムから医療情報（対象患者に関する医療情報）を取得する（ステップＳ５）。換言すれば、関連情報取得部２５は、変換後参照情報に含まれるＵＲＩに基づいて外部のシステムにアクセスすることによって医療情報を取得する。この場合、関連情報取得部２５は、例えばＨＴＴＰクライアントやＦＴＰクライアント等の各変換後参照情報に応じた通信方法（図６に示す例では、ｈｔｔｐ、Ｗｉｎｄｏｗｓ（登録商標）Ｅｘｐｌｏｒｅｒ、ＦＴＰ）により医療情報を取得する。

なお、関連情報取得部２５は、変換後参照情報に基づいてアクセス可能な医療情報の全てを取得してもよいし、例えば予め定められている優先度に基づいて医療情報を取得するような構成とすることも可能である。具体的には、関連情報取得部２５は、例えば参照された回数が多い医療情報を取得するように設定することも可能であるし、ＤＩＣＯＭデータ（．ｄｃｍファイル）は常に取得するように設定することも可能である。

関連情報送信部２６は、例えば通信ＡＰＩ（Application Programming Interface）等を用いて、関連情報取得部２５によって取得された医療情報をクライアント端末１０に送信する（ステップＳ６）。この場合、関連情報送信部２６は、関連情報取得部２５によって取得された医療情報とともに、認証部２２によって受信されたＭＤＴ ＩＤに対応づけて情報参照履歴情報に含まれる使用アプリケーション情報をクライアント端末１０に送信する。

クライアント端末１０に含まれる情報送受信部１１は、例えば通信ＡＰＩ等を用いて、関連情報送信部２６によって送信された医療情報及び使用アプリケーション情報を受信する。

次に、情報表示部１２は、情報送受信部１１によって受信された使用アプリケーション情報に基づいて、当該使用アプリケーション情報によって示されるアプリケーションを起動し、当該情報送受信部１１によって受信された医療情報を当該起動されたアプリケーションに読み込ませる。これにより、情報表示部１２は、情報送受信部１１によって受信された医療情報を、起動されたアプリケーションで表示する（ステップＳ７）。なお、医療情報は、上記した医療チームのミーティングにおいて当該医療チームを構成する全ての参加者が確認可能な態様で表示される。

具体的には、情報送受信部１１によって受信された使用アプリケーション情報がＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）やＣｈｒｏｍｅ等のブラウザを示し、医療情報がレセプト情報である場合には、当該ブラウザに当該レセプト情報を読み込ませて起動する。この場合、例えば図７に示す画面３１が表示される。

更に、クライアント端末１０においてブラウザが起動されている状態で、当該ブラウザを示す使用アプリケーション情報及び看護記録や治療計画に関する情報（医療情報）が情報送受信部１１によって受信された場合には、図７に示す画面３２のように、タブに当該看護記録や治療計画に関する情報を読み込ませておくことで、当該看護記録や治療計画に関する情報についても迅速に表示可能な状態にすることができる（つまり、迅速に表示を切り替えることができる）。

ここでは、ブラウザについて主に説明したが、画像ビューワ及びＰＤＦリーダ等のミーティングで使用する他のアプリケーションであっても同様に医療情報を表示することができる。

上記したように本実施形態においては、クライアント端末１０がミーティングを行う医療チームの種別を示す種別情報を医療情報管理サーバ２０に送信し、医療情報管理サーバ２０が当該送信された種別情報に対応づけて情報参照履歴情報に含まれる医療情報を参照するための参照情報を取得し、当該種別情報によって示される種別の医療チームが行うミーティングにおいて議論される患者を識別するための患者ＩＤを取得し、当該参照情報に基づいて患者ＩＤによって識別される患者に関する医療情報を取得し、当該取得された医療情報がクライアント端末１０において表示される構成により、ミーティングにおいて患者に関する医療情報の検索等を行うことなく、当該医療情報をクライアント端末１０において迅速に表示することが可能となる。

つまり、本実施形態においては、同種の医療チームによる過去のミーティングにおいて参照された医療情報（つまり、参照履歴）に基づいて取得されたミーティングにおける議論に必要な医療情報をクライアント端末１０が事前に医療情報管理サーバ２０から読み込んでおくことで、当該ミーティングの際にクライアント端末１０において必要な情報を迅速に表示することが可能となる。

なお、本実施形態はチーム医療におけるミーティング（ＭＤＴミーティング）に適用されるものとして説明したが、例えば一般のカンファレンス等に適用されても構わない。

（第２の実施形態）
次に、第２の実施形態について説明する。本実施形態に係る医療情報管理システムの構成は、前述した第１の実施形態と同様であるため、適宜、図１を用いて説明する。

本実施形態に係る医療情報管理システムは、格納部２１に格納されている情報参照履歴情報が医療情報の表示形式（画像の表示パラメータ等）を更に含む点が、前述した第１の実施形態とは異なる。

図８は、本実施形態における格納部２１に格納されている情報参照履歴情報のデータ構造の一例を示す。

図８に示すように、情報参照履歴情報には、ＭＤＴ ＩＤに対応づけて使用アプリケーション情報、参照情報及び表示形式が含まれている。表示形式は、対応づけられている参照情報を用いて参照することができる医療情報（つまり、当該参照情報に含まれるＵＲＩに基づいてアクセス可能な医療情報）が過去のミーティングにおいて参照された際の表示形式を示す。なお、医療情報がＤＩＣＯＭデータ（画像データ）等である場合、表示形式には、例えばウィンドウ幅（ＷＷ）及びウィンドウレベル（ＷＬ）等が含まれる。なお、情報参照履歴情報に含まれるＭＤＴ ＩＤ、使用アプリケーション情報及び参照情報については、前述した第１の実施形態において説明した通りであるため、ここではその詳しい説明を省略する。

図８に示す例では、情報参照履歴情報には、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」に対応づけて使用アプリケーション「ＤＩＣＯＭビューワ」、参照情報「ｈｔｔｐ：／／ＰＡＣＳ／ｐａｔｉｅｎｔ０１／００１．ｄｃｍ」、表示形式「画像のＷＷ／ＷＬ＝（３００，４０）」及び「アプリウィンドウ最大化」が含まれている。これによれば、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」によって示される種別の医療チームが過去のミーティングにおいてＤＩＣＯＭビューワを使用して「ｈｔｔｐ：／／ＰＡＣＳ／ｐａｔｉｅｎｔ０１／００１．ｄｃｍ」に基づいてアクセス可能な医療情報（画像データ）を、ＷＷ／ＷＬ＝（３００，４０）に設定し、かつ、ウィンドウを最大化して参照（表示）したことが示されている。

次に、本実施形態に係る医療情報管理システムの処理手順について説明する。ここでは、便宜的に、前述した図４のフローチャートを用いて説明するが、前述した第１の実施形態と異なる部分について主に述べる。

まず、図４に示すステップＳ１〜Ｓ５の処理と同様の処理が実行される。次に、関連情報送信部２６は、図４のステップＳ６の処理を実行する際に、認証部２２によって受信されたＭＤＴ ＩＤに対応づけて情報参照履歴情報に含まれる使用アプリケーション情報及び表示形式をクライアント端末１０に送信する。

クライアント端末１０に含まれる情報送受信部１１は、例えば通信ＡＰＩ等を用いて、関連情報送信部２６によって送信された医療情報、使用アプリケーション情報及び表示形式を受信する。

次に、情報表示部１２は、図４に示すステップＳ７の処理と同様に、情報受信部１１によって受信された医療情報を、起動されたアプリケーションで表示する。この場合、情報受信部１１によって受信された医療情報は、情報受信部１１によって受信された表示形式で表示される。

具体的には、情報受信部１１によって受信された医療情報がＤＩＣＯＭデータ（ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ０１／００１．ｄｃｍに基づいてアクセス可能な画像データ）であり、使用アプリケーション情報がＤＩＣＯＭビューワを示し、表示形式がＷＷ／ＷＬ＝（３００，４０）及びアプリウィンドウの最大化である場合には、情報表示部１２は、図９に示すように、当該画像データのウィンドウ幅（ＷＷ）及びウィンドウレベル（ＷＬ）をそれぞれ３００及び４０に設定し、更にウィンドウを最大化して、ＤＩＣＯＭビューワで表示する。

上記したように本実施形態においては、医療情報管理サーバ２０において受信されたＭＤＴ ＩＤに対応づけて情報参照履歴情報に含まれている表示形式で、関連情報取得部２５によって取得された医療情報（ミーティングにおいて議論されている患者を識別するための患者ＩＤに基づいて変換されたＵＲＩに基づいてアクセス可能な医療情報）をクライアント端末１０に表示する構成により、過去のミーティングにおいて参照された医療情報と同様の表示形式で対象患者に関する医療情報を表示することが可能となる。

（第３の実施形態）
次に、第３の実施形態について説明する。図１０は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図１と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１と異なる部分について主に述べる。

本実施形態に係る医療情報管理システムは、クライアント端末において使用中のアプリケーションで表示可能な形式に医療情報を変換して、当該変換された医療情報をクライアント端末に送信する点が、前述した第１の実施形態とは異なる。

図１０に示すように、医療情報管理システムは、クライアント端末１００及び当該クライアント端末１００と通信可能に接続される医療情報管理サーバ２００を備える。

クライアント端末１００は、使用状況認識部１０１及び使用状況送信部１０２を含む。使用状況認識部１０１は、クライアント端末１００において使用しているアプリケーションを認識する。

使用状況送信部１０２は、使用状況認識部１０１によって認識されたアプリケーションを示す情報（以下、使用状況情報と表記）を医療情報管理サーバ２００に送信する。

医療情報管理サーバ２００は、関連情報変換部２０１を含む。関連情報変換部２０１は、関連情報取得部２５によって取得された医療情報を、使用状況送信部１０２によって送信された使用状況情報によって示されるアプリケーション（つまり、クライアント端末１００において使用されているアプリケーション）で表示可能な形式に変換する。

なお、このように関連情報変換部２０１によって変換された医療情報は、関連情報送信部２６によってクライアント端末１００に送信され、当該クライアント端末１００において使用されているアプリケーションで表示される。

次に、図１１のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。

まず、前述した図４に示すステップＳ１〜Ｓ５の処理に相当するステップＳ１１〜Ｓ１５の処理が実行される。

次に、クライアント端末１００に含まれる使用状況認識部１０１は、例えばＷｉｎｄｏｗｓＡＰＩ等を用いて、当該クライアント端末１００が現在使用しているアプリケーション（つまり、使用中のアプリケーション）を認識する（ステップＳ１６）。なお、使用中のアプリケーションは、例えばクライアント端末１００において当該アプリケーションに与えられているウィンドウがアクティブであるか否か等に基づいて判別される。

使用状況送信部１０２は、使用状況認識部１０１によって認識されたアプリケーションを示す使用状況情報を、通信ＡＰＩ等を用いて医療情報管理サーバ２００に送信する（ステップＳ１７）。なお、使用状況送信部１０２によって送信される使用状況情報には、例えば使用状況認識部１０１によって認識されたアプリケーションのアプリケーション名及び当該アプリケーションのバージョン情報等が含まれる。

医療情報管理サーバ２００に含まれる関連情報変換部２０１は、使用状況送信部１０２によって送信された使用状況情報を受信する。

関連情報変換部２０１は、受信された使用状況情報に含まれるアプリケーション名及びバージョン情報等に基づいて、ステップＳ１５において関連情報取得部２５によって取得された医療情報をクライアント端末１００において使用中のアプリケーションで表示可能な形式に変換する（ステップＳ１８）。

具体的には、ステップＳ１５においてＤＩＣＯＭデータ（ＤＩＣＯＭ形式の画像データ）が取得されており、関連情報変換部２０１によって受信された使用状況情報がＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒのバージョン９を示す場合、関連情報変換部２０１は、例えばＤＩＣＯＭライブラリ等を用いて当該ＤＩＣＯＭデータをＪＰＧやＰＮＧ等のブラウザで表示できる形式に変換（画像変換）する。なお、この場合には、ＤＩＣＯＭデータのヘッダ情報等もＨＴＭＬ形式に変換される。これにより、本来はブラウザで表示することができないＤＩＣＯＭデータをブラウザで表示することができるようになる。ここでは、ＤＩＣＯＭデータがＪＰＧやＰＮＧに変換され、当該ＤＩＣＯＭデータのヘッダ情報がＨＴＭＬ形式に変換されるものとして説明したが、これらはクライアント端末１００において使用中のアプリケーションで表示可能な形式であれば他の任意の形式（例えば、ＰＤＦやＸＭＬ等）に変換されても構わない。

関連情報送信部２６は、関連情報変換部２０１によって形式が変換された医療情報をクライアント端末１００に送信する（ステップＳ１９）。

クライアント端末１０に含まれる情報送受信部１１は、例えばＡＰＩ等を用いて、関連情報送信部２６によって送信された医療情報を受信する。

次に、情報表示部１２は、情報送受信部１１によって受信された医療情報を、当該医療情報を表示可能なクライアント端末１００において使用されているアプリケーション（つまり、既に起動されているアプリケーション）に読み込ませる。これにより、情報表示部１２は、情報送受信部１１によって受信された医療情報を表示する。

ここで、図１２は、情報表示部１２によって医療情報が表示された際のクライアント端末１００の表示画面の一例を示す。

図１２に示す例では、医療情報管理サーバ２００において例えばブラウザで表示可能な形式に変換された複数の医療情報（画像データ）をクライアント端末１００において使用されているブラウザで表示した場合の表示画面が示されている。

なお、本実施形態において、医療情報管理サーバ２００から送信される医療情報は単一のアプリケーション（例えば、ブラウザ等）で表示することができる形式に変換されているため、図１２に示すように例えば対象患者を示す患者情報等を医療情報に付加して表示することにより、アプリケーションを切り替えることなく医療情報及び患者情報等を同時に確認ことが可能となる。なお、患者情報は、対象患者を識別するための患者ＩＤ等に基づいて医療情報管理システムの外部の例えば病院情報システム（ＨＩＳ）等から取得されればよい。

上記したように本実施形態においては、対象患者に関する医療情報をクライアント端末１００において使用されているアプリケーションで表示可能な形式に変換してクライアント端末１００に送信する構成により、医療情報管理サーバ２０から送信される全ての医療情報を単一のアプリケーションで表示（確認）することが可能になるため、医療情報を表示する際にアプリケーションを切り替えることが不要となり、当該アプリケーションの切り替えに要する時間を削減することが可能となる。

（第４の実施形態）
次に、第４の実施形態について説明する。図１３は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図１と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１と異なる部分について主に述べる。

本実施形態に係る医療情報管理システムは、患者について議論するミーティングの度に情報参照履歴情報を更新する点が、前述した第１の実施形態とは異なる。

図１３に示すように、医療情報管理システムは、クライアント端末１１０及び当該クライアント端末１１０と通信可能に接続される医療情報管理サーバ２１０を備える。

クライアント端末１１０は、情報取得部１１１、情報取得状況検出部１１２及び情報取得状況通知部１１３を含む。

情報取得部１１１は、ミーティングにおいて議論されている患者に関する医療情報（第３の医療情報）を外部のシステムから取得する。なお、情報取得部１１１によって取得された医療情報は、例えば情報表示部１２によって表示される。

情報取得状況検出部１１２は、情報取得部１１１によって取得された医療情報の取得先を示すＵＲＩ及び当該医療情報を表示するために使用されるアプリケーションを検出する。

情報取得状況通知部１１３は、情報取得状況検出部１１２によって検出されたＵＲＩを及びアプリケーションを医療情報管理サーバ２１０に通知する。

医療情報管理サーバ２１０は、情報参照履歴更新部２１１を含む。情報参照履歴更新部２１１は、情報取得状況通知部１１３による通知に基づいて、格納部２１に格納されている情報参照履歴情報を更新する。

以下、本実施形態に係る医療情報管理システムの動作について説明する。本実施形態に係る医療情報管理システムは、前述した第１の実施形態において説明した処理（図４に示す処理）に加えて、情報参照履歴更新処理を実行する。

図１４に示すフローチャートを参照して、本実施形態に係る医療情報管理システムによって実行される情報参照履歴更新処理の処理手順について説明する。

まず、クライアント端末１１０に含まれる情報取得部１１１は、例えばミーティング中に、ＨＴＴＰやＦＴＰ等のプロトコルを用いて、外部のシステムに対して医療情報（当該ミーティングにおいて議論されている患者に関する医療情報）のリクエストを送信することができる（ステップＳ２１）。以下、情報取得部１１１によるリクエストの対象となる医療情報を対象医療情報と称する。

このリクエストが送信された外部のシステムは、対象医療情報をクライアント端末１１０に対して送信する。これにより、情報取得部１１１は、対象医療情報を外部のシステムから取得することができる。情報取得部１１１によって取得された対象医療情報は、例えば情報表示部１２によって表示されて、ミーティングにおいて参照される。

上記したように情報取得部１１１からリクエストが送信された場合、情報取得状況検出部１１２は、対象医療情報の取得先を示すＵＲＩ及び当該対象医療情報を表示するために使用されるアプリケーション（使用中のアプリケーション）を検出する（ステップＳ２２）。

情報取得状況通知部１１３は、情報取得状況検出部１１２によって検出されたＵＲＩ及びアプリケーションを、通信ＡＰＩ等を用いて医療情報管理サーバ２１０に通知する（ステップＳ２３）。

医療情報管理サーバ２１０に含まれる情報参照履歴更新部２１１は、ログイン中のＭＤＴ ＩＤ（つまり、認証部２２によって受信されたＭＤＴ ＩＤ）に対応づけて情報取得状況通知部１１３によって通知されたＵＲＩを含む参照情報及びアプリケーションを示すアプリケーション情報を含む情報参照履歴情報を、格納部２１に新たに格納する（ステップＳ２４）。

ここで、情報参照履歴更新処理について具体的に説明すると、例えばクライアント端末１１０から外部のシステムであるＰＡＣＳに対して対象医療情報（ＤＩＣＯＭデータ）のリクエストが送信された場合には、対象医療情報の取得先であるＵＲＩとして例えば「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／００１．ｄｃｍ」、当該対象医療情報を表示するために使用されるアプリケーションとして「ＤＩＣＯＭビューワ」が医療情報管理サーバ２１０に通知される。この場合において、例えばログイン中のＭＤＴ ＩＤが「Ｃａｎｃｅｒ」である場合には、当該ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」に対応づけて参照情報「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／００１．ｄｃｍ」及び使用アプリケーション情報「ＤＩＣＯＭビューワ」を含む情報参照履歴情報が格納部２１に格納される。

上記したように本実施形態においては、ミーティングにおいて外部のシステムから医療情報が取得される度に格納部２１に格納されている情報参照履歴情報が更新されるため、格納部２１に格納されている情報参照履歴情報を更新しない場合と比較して、ミーティングにおいて必要な医療情報を漏れなく医療情報管理サーバ２１０からクライアント端末１１０に送信することが可能となる。

（第５の実施形態）
次に、第５の実施形態について説明する。図１５は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図１と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１と異なる部分について主に述べる。

本実施形態に係る医療情報管理システムは、ミーティングを行う医療チームを構成する参加者（つまり、ミーティングの参加者）の役割（職種）を考慮した医療情報がクライアント端末１２０において表示される点が、前述した第１の実施形態とは異なる。

図１５に示すように、医療情報管理システムは、クライアント端末１０及び当該クライアント端末１０と通信可能に接続される医療情報管理サーバ２２０を備える。

医療情報管理サーバ２２０は、格納部２２１及び関連情報絞込み部２２２を含む。格納部２２１は、前述した第１の実施形態において説明したログイン情報及び情報参照履歴情報に加えて、役割関連情報を更に格納する。格納部２２１に格納されている役割関連情報は、ミーティングを行う医療チームを構成する参加者の役割毎に、当該役割に関連する医療情報（の取得先）を示す情報である。

関連情報絞込部２２２は、医療情報管理システムの外部のシステムから、ミーティングを行う医療チームを構成する参加者の役割を取得する。関連情報絞込部２２２は、取得された参加者の役割及び格納部２２１に格納されている役割関連情報に基づいて、情報参照履歴変換部２４によって変換された参照情報（ＵＲＩ）に対して絞り込みを行う。

なお、本実施形態における関連情報取得部２５は、関連情報絞込部２２２によって絞り込みが行われた後の参照情報に基づいて、外部のシステムから医療情報を取得する。

図１６は、図１５に示す格納部２２１に格納されている役割関連情報のデータ構造の一例を示す。

図１６に示すように、役割関連情報には、役割に対応づけて関連情報が含まれている。役割は、ミーティングを行う医療チームを構成する参加者の例えば職種を示す。関連情報は、対応づけられている役割に関連する医療情報の取得先（つまり、当該役割に関連する医療情報を保存している外部のシステム等）を示す。

図１６に示す例では、役割関連情報には、役割「病理医」に対応づけて関連情報「＊／ＨＩＳ／＊」が含まれている。これによれば、ミーティングを行う医療チームを構成する参加者のうち、職種が「病理医」である参加者に関連する医療情報は、病院情報システム（ＨＩＳ）に保存されていることが示されている。

なお、役割関連情報は、ミーティングを行う医療チームを構成する参加者の全ての役割（職種）について予め用意されているものとする。

また、図１６に示す関連情報は一例であり、当該関連情報は、各システムに応じてその表現方法を変更することが可能である。

次に、図１７のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。

まず、前述した図４に示すステップＳ１〜Ｓ４の処理に相当するステップＳ３１〜Ｓ３４の処理が実行される。

次に、医療情報管理サーバ２２０に含まれる関連情報絞込部２２２は、ミーティングを行う医療チームを構成する参加者の役割を取得する（ステップＳ３５）。この場合、ミーティングを行う医療チームを構成する参加者の役割は、当該ミーティングに関する情報を管理するシステム（例えば、ＭＤＴミーティングシステム）、カンファレンスシステム及びスケジューリングシステム等の外部のシステムから取得される。

関連情報絞込部２２２は、取得された参加者の役割及び格納部２２１に格納されている役割関連情報に基づいて、ステップＳ３４において情報参照履歴変換部２４によって変換された参照情報の絞り込みが行われる（ステップＳ３６）。

ここで、ステップＳ３６の処理について具体的に説明する。この場合、関連情報絞込部２２２は、取得された参加者の役割の各々に対応づけて役割関連情報に含まれる関連情報を取得する。具体的には、図１６に示す役割関連情報が格納部２２１に格納されており、関連情報絞込部２２２によって取得された参加者の役割（職種）が「放射線科医」及び「看護師」である場合には、関連情報絞込部２２２は、図１８に示すように、関連情報「＊／ＰＡＣＳ／＊」、「＊／ＲＩＳ／＊」及び「看護記録システム」を取得する。

次に、関連情報絞込部２２２は、情報参照履歴変換部２４によって変換された参照情報を、取得された関連情報によって示される外部のシステムから取得される医療情報の保存位置を示すＵＲＩを含む参照情報に絞り込む。

ここで、上記した関連情報に含まれる「＊」は任意の文字列を表している。このため、関連情報絞込部２２２によって取得された関連情報が例えば「＊／ＰＡＣＳ／＊」である場合には、情報参照履歴変換部２４によって変換された参照情報は、「／ＰＡＣＳ／」を含むＵＲＩ（参照情報）に絞り込まれる。他の関連情報についても同様である。

具体的には、図１９に示すように、情報参照履歴変換部２４によって変換された参照情報が「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／００１．ｄｃｍ」、「￥￥ＨＩＳ￥Ｐａｔｉｅｎｔ９９￥ｍｅｄｉｃａｔｉｏｎ．ｈｔｍｌ」及び「ｆｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／００２．ｄｃｍ」の３つであり、関連情報絞込部２２２によって取得された関連情報が「＊／ＰＡＣＳ／＊」、「＊／ＲＩＳ／＊」及び「看護記録システム」である場合には、当該３つの変換後参照情報が「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／００１．ｄｃｍ」及び「ｆｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／００２．ｄｃｍ」の２つに絞り込まれる。ここでは、「＊／ＰＡＣＳ／＊」で表されるＵＲＩ（つまり、ＰＡＣＳを取得先とするＵＲＩ）に絞り込まれている。

なお、図１９においては、情報参照履歴変換部２４によって変換された参照情報を変換後参照情報、関連情報絞込部２２２によって絞り込まれた後の参照情報を絞込後参照情報と表記している。

再び図１７に戻ると、関連情報取得部２５は、関連情報絞込部２２２によって絞り込まれた後の参照情報（絞込後参照情報）に基づいて、外部のシステムから医療情報（対象患者に関する医療情報）を取得する（ステップＳ３７）。これにより、関連情報取得部２５は、ミーティングを行う医療チームを構成する参加者の役割に関連する医療情報を取得することができる。

以下、図４に示すステップＳ６及びＳ７の処理に相当するステップＳ３８及びＳ３９の処理が実行される。

上記したように本実施形態においては、ミーティングを行う医療チームを構成する参加者の役割に関連する医療情報に絞り込んでクライアント端末１０に送信する構成により、当該参加者にとって有用な医療情報（つまり、ミーティングに参加している参加者に関連する医療情報）のみをクライアント端末１０において表示することが可能となる。

なお、本実施形態においては、役割関連情報が予め格納部２２１に格納されているものとして説明したが、役割関連情報は例えば情報参照履歴情報等から統計的に算出（生成）されても構わない。具体的には、例えば役割が「病理医」である参加者等から構成される医療チームによるミーティングにおいて病院情報システム（ＨＩＳ）に保存されている医療情報が多く参照されている場合には、当該役割「病理医」に対応づけて関連情報「＊／ＨＩＳ／＊」を含む役割関連情報を生成し、当該生成された役割関連情報を格納部２２１に格納するようにしても構わない。

（第６の実施形態）
次に、第６の実施形態について説明する。図２０は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図１及び図１５と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１及び図１５と異なる部分について主に述べる。

本実施形態に係る医療情報管理システムは、ミーティングを行う医療チームを構成する参加者の各々が保持する参加者端末において当該参加者の役割に関連する医療情報を表示する点が、前述した第５の実施形態とは異なる。

図２０に示すように、医療情報管理システムは、クライアント端末（主クライアント端末）１０、参加者端末（副クライアント端末）１３０及び医療情報管理サーバ２３０を備える。医療情報管理サーバ２３０は、クライアント端末１０及び参加者端末１３０と通信可能に接続される。なお、参加者端末１３０はミーティングを行う医療チームを構成する参加者の各々によって保持されるが、図２０においては、便宜的に１つの参加者端末１３０のみが示されている。

参加者端末１３０は、情報送受信部１３１及び情報表示部１３２を含む。情報送受信部１３１は、医療情報管理サーバ２３０との間で各種情報を送受信するための機能部である。

具体的には、情報送受信部１３１は、参加者端末１３０を保持する参加者（つまり、ミーティングを行う医療チームを構成する参加者）を識別するための個人ＩＤ及び当該個人ＩＤに対するパスワードを医療情報管理サーバ２３０に対して送信する。また、情報送受信部１３１は、ミーティングにおいて議論される患者に関する医療情報を医療情報管理サーバ２３０から受信する。

情報表示部１３２は、各種情報を表示するための機能部である。具体的には、情報表示部１３２は、情報送受信部１３１によって受信された医療情報を、参加者端末１３０を保持する参加者に対して表示する。

医療情報管理サーバ２３０は、格納部２３１、認証部２３２及び関連情報送信部２３１を含む。

格納部２３１は、前述したログイン情報、情報参照履歴情報に加えて、個人用ログイン情報を更に格納する。個人用ログイン情報は、参加者端末１３０を保持する参加者が当該参加者端末１３０から医療情報管理システムにログインする際に用いられる情報である。なお、個人用ログイン情報には、参加者端末１３０を保持する参加者毎に、当該参加者を識別するための個人ＩＤ及び当該個人ＩＤに対して予め定められているパスワードが対応づけて含まれている。

認証部２３２は、参加者端末１３０に含まれる情報送受信部１３１によって送信された個人ＩＤ及びパスワードを受信する。認証部２３２は、受信された個人ＩＤ及びパスワードと格納部２３１に格納されている個人用ログイン情報とに基づいて認証を行う。

関連情報送信部２３１は、関連情報取得部２５によって取得された医療情報をクライアント端末１０に送信する。また、関連情報送信部２３１は、関連情報取得部２５によって取得された医療情報のうち、ミーティングを行う医療チームを構成する参加者の役割に関連する医療情報を、当該参加者が保持する参加者端末１３０に送信する。

次に、本実施形態に係る医療情報管理システムの動作について説明する。本実施形態に係る医療情報管理システムは、クライアント端末用の処理及び参加者端末用の処理を実行する。なお、クライアント端末用の処理は、前述した図１７に示す処理と同様であるため、その詳しい説明を省略する。

ここで、図２１のフローチャートを参照して、本実施形態に係る医療情報管理システムによって実行される参加者端末用の処理の処理手順について説明する。なお、参加者端末用の処理は、ミーティングの主催者がクライアント端末１０から医療情報管理システムにログインした後に行われる。

まず、参加者端末１３０を保持する参加者は、医療情報管理システムにログインする必要がある。

この場合、参加者端末１３０を保持する参加者は、当該参加者端末１３０を操作することによって、当該参加者を識別するための個人ＩＤ及びパスワードを入力する。

このように参加者端末１３０を保持する参加者によって個人ＩＤ及びパスワードが入力された場合、当該参加者端末１３０に含まれる情報送受信部１３１は、当該入力された個人ＩＤ及びパスワードを医療情報管理サーバ２３０に送信する（ステップＳ４１）。

医療情報管理サーバ２３０に含まれる認証部２３２は、参加者端末１３０（に含まれる情報送受信部１３１）によって送信された個人ＩＤ及びパスワードを受信する。

認証部２３２は、受信された個人ＩＤ及びパスワードと格納部２３１に格納されている個人用ログイン情報とに基づいて認証処理を実行し、当該認証の成功または失敗を判定する（ステップＳ４２）。認証部２３２は、受信された個人ＩＤ及びパスワードが個人用ログイン情報において対応づけられている場合には、認証が成功したと判定する。一方、認証部２３２は、受信された個人ＩＤ及びパスワードが個人用ログイン情報において対応づけられていない場合には、認証が失敗したと判定する。

認証部２３２によって認証が失敗したと判定された場合（ステップＳ４２のＮＯ）、医療情報システムへのログインが拒否されて、処理が終了される。

一方、認証部２３２によって認証が成功したと判定された場合（ステップＳ４２のＹＥＳ）、参加者端末１３０を保持する参加者の医療情報管理システムへのログインが許可される。この場合、例えばミーティングの主催者は、クライアント端末１０を介して、医療情報管理システムにログインしている参加者が保持する参加者端末１３０に対して医療情報を送信する旨のリクエストを送信することができる（ステップＳ４３）。

クライアント端末１０からリクエストが送信された場合、医療情報管理サーバ２３０では、医療情報管理システムにログインしている参加者毎に関連する医療情報が取得される（ステップＳ４４）。ここでは詳細な説明を省略するが、医療情報管理システムにログインしている参加者の各々に関連する医療情報は、前述した図１７に示すステップＳ３３〜Ｓ３７の処理と同様の処理が実行されることによって取得される。

次に、関連情報送信部２３３は、取得された医療情報管理システムにログインしている参加者の各々に関連する医療情報を、当該参加者によって保持される参加者端末１３０に送信する（ステップＳ４５）。つまり、参加者によって保持される参加者端末１３０には、当該参加者に関連する医療情報が送信される。例えば前述した図１６に示す役割関連情報が格納部２３１に格納されている場合、関連情報「＊／ＨＩＳ／＊」によって示される病院情報システムから取得された医療情報（つまり、「＊／ＨＩＳ／＊」で表されるＵＲＩに基づいてアクセス可能な医療情報）は、役割（職種）が「病理医」である参加者が保持する参加者端末１３０に送信される。

なお、関連情報送信部２６は、医療情報とともに、ミーティングの主催者がログインする際に認証部２３２によって受信されたＭＤＴ ＩＤに対応づけて情報参照履歴情報に含まれる使用アプリケーション情報を送信する。

参加者端末１３０に含まれる情報送受信部１３１は、関連情報送受信部２３３によって送信された医療情報及び使用アプリケーション情報を受信する。

情報表示部１３２は、情報送受信部１３１によって受信された医療情報及び使用アプリケーション情報に基づいて、当該医療情報を表示する。なお、医療情報を表示する際の具体的な処理については、前述した第１の実施形態等で説明した通りであるので、その詳しい説明を省略する。

つまり、上記した参加者端末用の処理によれば、参加者の各々が保持する参加者端末１３０には当該参加者に関連する医療情報が表示される。一方、クライアント端末用の処理によれば、前述した第５の実施形態において説明したように、クライアント端末１０にはミーティングを行う医療チームを構成する全ての参加者の役割に関連する医療情報が表示される。

上記したように本実施形態においては、参加者の役割に関連する医療情報が当該参加者によって保持される参加者端末１３０において表示される構成により、当該参加者は自身に関連する医療情報を、全ての参加者が確認するクライアント端末１０の表示に関係なく容易に確認することができる。

なお、本実施形態においては、医療情報管理サーバ２３０がクライアント端末１０からのリクエストに応じて参加者が保持する参加者端末１３０に当該参加者に関連する医療情報を送信するものとして説明したが、参加者端末１３０からのリクエストに応じて当該医療情報が送信される構成であってもよいし、クライアント端末１０及び参加者端末１３０からのリクエストがなくても自動的に当該医療情報が送信されるような構成であっても構わない。

（第７の実施形態）
次に、第７の実施形態について説明する。本実施形態に係る医療情報管理システムの構成は、前述した第１の実施形態と同様であるため、適宜、図１を用いて説明する。

本実施形態に係る医療情報管理システムは、ミーティングにおいて議論されている患者（対象患者）の患者情報に基づいて医療情報を更に取得する点が、前述した第１の実施形態とは異なる。

本実施形態に係る医療情報管理システムにおいて、医療情報管理サーバ２０に含まれる格納部２１は、ログイン情報及び情報参照履歴情報に加えて、患者履歴情報を更に格納している。

ここで、図２２は、本実施形態における格納部２１に格納されている患者履歴情報のデータ構造の一例を示す。

図２２に示すように、患者履歴情報には、患者情報及び参照情報が対応づけて含まれる。患者情報は、患者を示す情報であり、当該患者が患っている主病名、関連病名、当該患者の既往歴及び年齢等を含む。参照情報は、対応づけられている患者情報によって示される患者について議論するための過去のミーティングにおいて参照された医療情報を参照するための情報（つまり、当該医療情報にアクセスするための情報）であり、具体的には、当該医療情報を保存している外部のシステムにおける当該医療情報の保存位置（つまり、当該医療情報の取得先）を示すＵＲＩを含む。

図２２に示す例では、患者履歴情報には、例えば主病名「脳梗塞」及び年齢「４５」を含む患者情報と参照情報「ｈｔｔｐ：／／ＨＩＳ／Ｐａｔｉｅｎｔ０１／治療計画．ｈｔｍｌ」とが対応づけて含まれている。これによれば、主病名が脳梗塞で、年齢が４５である患者について議論するための過去のミーティングにおいて「ｈｔｔｐ：／／ＨＩＳ／Ｐａｔｉｅｎｔ０１／治療計画．ｈｔｍｌ」に基づいてアクセス可能な医療情報が参照されたことが示されている。

次に、図２３のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。

まず、図４に示すステップＳ１及びＳ２の処理に相当するステップＳ５１及びＳ５２の処理が実行される。

次に、情報参照履歴取得部２３は、対象患者（ミーティングにおいて議論される対象となる患者）を示す患者情報を取得する（ステップＳ５３）。この患者情報は、患者ＩＤ等に基づいて、医療情報管理システムの外部の例えば病院情報システム（ＨＩＳ）から取得される。なお、情報参照履歴取得部２３によって取得される患者情報には、主病名、関連病名、既往歴及び年齢等が含まれる。以下、情報参照履歴取得部２３によって取得された患者情報を対象患者情報と称する。

情報参照履歴取得部２３は、格納部２１に格納されている患者履歴情報に含まれる患者情報のうち、対象患者情報と類似する患者情報を特定する（ステップＳ５４）。

この場合、例えば対象患者情報と患者履歴情報に含まれる患者情報とを比較し、当該対象患者情報と当該患者情報との間で一致する項目の数をカウントすることによって、当該対象患者情報及び当該患者情報の相関値を算出する。これにより、例えば対象患者情報との相関値が予め定められた値以上の患者情報を、対象患者情報と類似する患者情報として特定することができる。なお、ここで説明した対象患者情報と類似する患者情報を特定するための処理は一例であり、他の処理によって対象患者情報と類似する患者情報が特定されても構わない。

次に、情報参照履歴取得部２３は、格納部２１に格納されている情報参照履歴情報及び患者履歴情報から参照情報を取得する（ステップＳ５５）。具体的には、情報参照履歴取得部２３は、認証部２２によって受信されたＭＤＴ ＩＤに対応づけて情報参照履歴情報に含まれる参照情報を取得する。また、情報参照履歴取得部２３は、上記したように特定された患者情報に対応づけて患者履歴情報に含まれる参照情報を取得する。

以下、情報参照履歴取得部２３によって取得された参照情報（情報参照履歴情報に含まれる参照情報及び患者履歴情報に含まれる参照情報）に対して前述した図４に示すステッＳ４の処理に相当するステップＳ５６の処理が実行され、その後、当該図４に示すステップＳ５〜Ｓ７の処理に相当するステップＳ５７〜Ｓ５９の処理が実行される。

上記したように本実施形態においては、対象患者情報に類似する患者情報に対応づけて患者履歴情報に含まれる参照情報に基づいて取得された対象患者に関する医療情報がクライアント端末１０において更に表示されるため、前述した第１の実施形態と比較して、ミーティングにおいて必要な医療情報を漏れなくクライアント端末１０において表示することが可能となる。

（第８の実施形態）
次に、第８の実施形態について説明する。図２４は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図１と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１と異なる部分について主に述べる。

本実施形態に係る医療情報管理システムは、ミーティングにおいて議論されている患者（対象患者）に関する医療情報と過去の医療情報との差分をクライアント端末において表示する点が、前述した第１の実施形態とは異なる。

図２４に示すように、医療情報管理システムは、クライアント端末１０及び当該クライアント端末１０と通信可能に接続される医療情報管理サーバ２４０を備える。

医療情報管理サーバ２４０は、格納部２４１及び情報比較部２４２を含む。

格納部２４１は、前述した第１の実施形態において説明したログイン情報に加えて、差分管理情報を更に格納する。格納部２４１に格納されている差分管理情報は、ミーティングにおいて参照された医療情報と当該医療情報より過去の医療情報（当該ミーティングより前にアクセスされた医療情報）との差分を示す差分情報を取得するための差分情報パスを含む。

ここで、クライアント端末１０は、ミーティングにおいて議論されている患者に関する医療情報のリクエストを医療情報管理サーバ２４０に送信することができる。なお、クライアント端末１０によって送信されるリクエストには、当該リクエストの対象となる医療情報の保存位置（取得先）を示すＵＲＩが含まれる。

情報比較部２４２は、クライアント端末１０からリクエストが送信された場合、当該リクエストに含まれるＵＲＩ、認証部２２によって受信されたＭＤＴ ＩＤ及び格納部２４１に格納されている差分管理情報に基づいて、当該ＵＲＩに基づいてアクセス可能な医療情報に関する差分情報を取得する。

情報比較部２４２は、クライアント端末１０によって送信されたリクエストに含まれるＵＲＩに基づいて、外部のシステムから医療情報を取得する。

情報比較部２４２は、取得された差分情報と医療情報とを比較することによって当該差分情報と医療情報との差分を示す差分情報を生成する。

情報比較部２４２は、生成された差分情報に基づいて、外部のシステムから取得された医療情報に対して差分強調処理を実行する。

情報比較部２４２によって差分強調処理が実行された医療情報は、関連情報送信部２６によってクライアント端末１０に送信される。また、関連情報送信部２６によって送信された医療情報は、クライアント端末１０に含まれる情報送受信部１１によって受信されて、情報表示部１２によって表示される。

図２５は、図２４に示す格納部２４１に格納されている差分管理情報のデータ構造の一例を示す。

図２５に示すように、差分管理情報には、ＭＤＴ ＩＤ、作成日時及び差分情報パスが対応づけて含まれている。作成日は、差分情報が生成された日を示す。差分情報パスは、対応づけられているＭＤＴ ＩＤによって示される種別の医療チームによるミーティングにおいて、対応づけられている作成日に参照された医療情報と当該ミーティングより前にアクセスされた医療情報との差分を示す差分情報（当該差分が記載されたファイル）を参照（取得）するための情報であり、例えば当該差分情報の保存位置（取得先）を示すＵＲＩを含む。なお、ＭＤＴ ＩＤは前述した第１の実施形態において説明した通りであるため、その詳しい説明を省略する。

図２５に示す例では、差分管理情報には、例えばＭＤＴ ＩＤ「Ｃａｎｃｅｒ」、作成日「２０１２／０３／０１」及び差分情報パス「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ０１／００１．ｄｃｍ．Ｃａｎｃｅｒ＿２０１２０３０１＿ｄｉｆｆ」が対応づけて含まれている。これによれば、ＭＤＴ ＩＤ「Ｃａｎｃｅｒ」によって示される種別の医療チーム（癌を対象とする医療チーム）による２０１２年３月１日のミーティングにおいて参照された医療情報と当該２０１２年３月１日より前にアクセスされた医療情報との差分を示す差分情報が「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ０１／００１．ｄｃｍ．Ｃａｎｃｅｒ＿２０１２０３０１＿ｄｉｆｆ」に示す保存位置に保存されていることが示されている。

なお、上記した差分管理情報は、ミーティングが行われる度（つまり、当該ミーティングにおいて医療情報が参照される度）に更新される。

次に、図２６のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。

まず、前述した図４に示すステップＳ１及びＳ２の処理に相当するステップＳ６１及びＳ６２の処理が実行される。

ここで、例えばミーティングの主催者は、クライアント端末１０を介して、当該ミーティングにおいて議論されている患者に関する医療情報のリクエストを送信することができる（ステップＳ６３）。このリクエストには、当該リクエストの対象となる医療情報を取得するためのＵＲＩが含まれる。なお、医療情報のリクエストは、ブラウザやファイルシステム等を通して医療管理サーバ２４０に送信される。

情報比較部２４２は、クライアント端末１０によって送信されたリクエストを受信する。情報比較部２４２は、受信されたリクエストに含まれるＵＲＩ及び格納部２４１に格納されている差分管理情報を参照し、認証部２２によって受信されたＭＤＴ ＩＤに対応づけて当該差分管理情報に含まれている差分情報パスを検索する（ステップＳ６４）。この場合、情報比較部２４２は、認証部２２によって受信されたＭＤＴ ＩＤに対応づけて差分管理情報に含まれている差分情報パスであって、受信されたリクエストに含まれるＵＲＩを含む差分情報パスを検索する。なお、検索された差分情報パスが複数存在する場合には、情報比較部２４２は、当該差分情報パスに対応づけて差分管理情報に含まれている作成日が最新の差分情報パスを取得する。

具体的には、認証部２２によって受信されたＭＤＴ ＩＤが「Ｃａｎｃｅｒ」であり、格納部２４１に上述した図２５に示す差分管理情報が格納されており、情報比較部２４２によって受信されたリクエストに含まれるＵＲＩが「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ０１／００２．ｄｃｍ」である場合には、情報比較部２４２は、差分情報パス「ｈｔｔｐ：／／ＰＡＣＳ／Ｐａｔｉｅｎｔ０１／００２．ｄｃｍ．Ｃａｎｃｅｒ＿２０１２０３０１＿ｄｉｆｆ」を取得する。

次に、情報比較部２４２は、取得された差分情報パスに基づいて、差分情報を取得する。また、情報比較部２４２は、受信されたリクエストに含まれるＵＲＩに基づいて、外部のシステムから医療情報を取得する。

情報比較部２４２は、取得された差分情報と医療情報とを比較し、例えば文字列処理によって文字列単位やバイナリ単位で当該差分情報と医療情報との差分をとる。これにより、情報比較部２４２は、差分情報を生成する（ステップＳ６５）。

なお、情報比較部２４２によって生成された差分情報は、上記した情報比較部２４２によって受信されたリクエストに含まれるＵＲＩの末尾に認証部２２によって受信されたＭＤＴ ＩＤ及び当該差分情報が生成された日（作成日）が付与されたものをファイル名とし、情報比較部２４２によって取得された差分情報と同一のフォルダに保存される。

次に、情報比較部２４２は、生成された差分情報に基づいて、取得された医療情報（つまり、クライアント端末１０によってリクエストされた医療情報）に対する差分強調処理を実行する（ステップＳ６６）。この場合、情報比較部２４２は、医療情報及び差分情報の双方に含まれる文字列や画像に対して強調表示処理を行う。具体的には、医療情報がＨＴＭＬファイルの場合はＨＴＭＬタグのＢｏｌｄや色変更のためのタグ等を付与する処理を行う。また、医療情報が画像の場合は、画素値に差が生じる画素の画素値を変更する、またはアノテーションを付与することによって差分画像を生成し、原画像に付与する処理を行う。なお、画像に対して差分強調処理を行う場合、図２７に示すように、濃度値の差を色で表現した差分画像（差分強調処理された画像）を必要に応じてレジストレーション（画像相互位置合わせ）する等により、現在及び過去の画像（医療情報）と比較しやすい画像を提供することが好ましい。

情報比較部２４２によって差分強調処理が実行された医療情報は、関連情報送信部２６によってクライアント端末１０に送信される（ステップＳ６７）。

また、関連情報送信部２６によって送信された医療情報は、クライアント端末１０において使用されているブラウザ等のアプリケーションで表示される（ステップＳ６８）。

上記したように本実施形態においては、ミーティング中にクライアント端末１０によってリクエストされた医療情報（現在の医療情報）と当該医療情報より過去にアクセスされた医療情報（過去の医療情報）との差分を示す差分情報に基づいて差分強調処理が行われ、当該差分強調処理が行われた医療情報が当該クライアント端末１０において表示される構成により、当該ミーティングにおいて当該現在の医療情報と過去の医療情報との差分を容易に把握することが可能となる。

なお、例えば医療情報が心拍数等を含む検査結果である場合には、現在の医療情報と過去の医療情報との差分情報には、現在の検査結果及び過去の検査結果の差を表す数値等が含まれていても構わない。このような差分情報に含まれる数値がクライアント端末１０において強調表示されることによって、ミーティングにおいて対象患者の心拍数の数値の変化等を容易に認識することができる。

また、本実施形態においては、クライアント端末１０によって送信されたリクエストに含まれるＵＲＩに対して図２６に示すステップＳ６４以降の処理が実行されるものとして説明したが、例えば前述した第１の実施形態における情報参照履歴変換部２４によって変換された参照情報（変換ご参照情報）に含まれるＵＲＩに対して図２６に示すステップＳ６４以降の処理が実行されても構わない。

（第９の実施形態）
次に、第９の実施形態について説明する。図２８は、本実施形態に係る医療情報管理システムの主として機能構成を示すブロック図である。なお、前述した図１と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１と異なる部分について主に述べる。

本実施形態に係る医療情報管理システムは、ミーティング中の参加者の発言内容から議論の内容を判別し、当該議論の内容に関連した医療情報をクライアント端末において表示する点が、前述した第１の実施形態とは異なる。

図２４に示すように、医療情報管理システムは、クライアント端末１５０及び当該クライアント端末１５０と通信可能に接続される医療情報管理サーバ２５０を備える。

クライアント端末１５０は、音声取得部１５１及び情報送受信部１５２を含む。音声取得部１５１は、患者について議論するためのミーティングにおける当該ミーティングの参加者の音声を取得する。

情報送受信部１５２は、音声取得部１５１によって取得された音声の情報（以下、音声情報と表記）を、医療情報管理サーバ２５０に送信する。また、情報送受信部１１は、ミーティングにおいて議論されている患者に関する医療情報を医療情報管理サーバ２０から受信する。

医療情報管理サーバ２５０は、格納部２５１、音声分類部２５２及び関連情報取得部２５３を含む。

格納部２５１には、ミーティングにおける議論の内容を表すカテゴリに関連する医療情報の取得先を示すカテゴリ別関連情報が予め格納されている。

音声分類部２５２は、クライアント端末１５０に含まれる情報送受信部１５２によって送信された音声情報を受信する。音声分類部２５２は、取得された音声情報に対して音声認識処理を実行する。音声分類部２５２は、音声認識処理結果に基づいて、ミーティングにおける議論の内容を表すカテゴリを決定する。

関連情報取得部２５３は、ミーティングにおいて議論されている患者を識別するための患者ＩＤを取得する。関連情報取得部２５３は、格納部２５１に格納されているカテゴリ別関連情報、音声分類部２５２によって決定されたカテゴリ及び取得された患者ＩＤに基づいて、当該カテゴリに関連する医療情報であって当該患者ＩＤによって識別される患者に関する医療情報を、外部のシステムから取得する。

関連情報取得部２５３によって取得された医療情報は、関連情報送信部２６によってクライアント端末１５０に送信される。また、関連情報送信部２６によって送信された医療情報は、クライアント端末１５０に含まれる情報送受信部１５２によって受信されて、情報表示部１２によって表示される。

図２９は、図２８に示す格納部２５１に格納されているカテゴリ別関連情報のデータ構造の一例を示す。

図２９に示すように、カテゴリ別関連情報には、カテゴリに対応づけて参照情報が含まれている。カテゴリは、ミーティングにおける議論の内容を表す。参照情報は、対応づけられているカテゴリ（議論の内容）に関連する医療情報を参照するための情報（つまり、当該医療情報にアクセスするための情報）であり、例えば当該医療情報の取得先であるＵＲＩを表す。

図２９に示す例では、カテゴリ別関連情報には、例えばカテゴリ「癌」に対応づけて参照情報「＊／ｐａｔｈｏｌｏｇｉｃａｌＩｍａｇｅ／＊」及び「＊／ＰＡＣＳ／Ｐａｔｉｅｎｔ＊／＊．ｄｃｍ」が含まれている。これによれば、癌に関連する医療情報が「＊／ｐａｔｈｏｌｏｇｉｃａｌＩｍａｇｅ／＊」及び「＊／ＰＡＣＳ／Ｐａｔｉｅｎｔ＊／＊．ｄｃｍ」によって表されるＵＲＩに基づいて取得可能であることが示されている。なお、カテゴリ別関連情報に含まれる参照情報に含まれる「＊」は任意の文字列を表している。

次に、図３０のフローチャートを参照して、本実施形態に係る医療情報管理システムの処理手順について説明する。

まず、クライアント端末１５０に含まれる音声取得部１５１は、例えばマイク等の集音機器を用いてミーティング中の参加者の発言（音声情報）を収集する（ステップＳ７１）。音声取得部１５１によって収集（取得）された音声情報は、医療情報管理サーバ２５０に送信される。

医療情報管理サーバ２５０に含まれる音声分類部２５２は、クライアント端末１５０（に含まれる情報送受信部１５２）によって送信された音声情報を受信する。

音声分類部２５２は、受信された音声情報に対して音声認識処理を実行する（ステップＳ７２）。具体的には、音声分類部２５２は、例えば言語モデルを用いた統計的音声認識手法や、隠れマルコフモデルやルールベースによる音声認識手法等を用いて、音声情報に対してカテゴリ分類を行う。

音声分類部２５２は、このような音声認識処理結果に基づいて、受信された音声情報のカテゴリ（ミーティングにおける議論の内容を表すカテゴリ）を決定する（ステップＳ７３）。

次に、関連情報取得部２５３は、ミーティングにおいて議論されている患者（対象患者）に関する患者ＩＤ（対象患者ＩＤ）を取得する。なお、対象患者ＩＤは、例えば病院外または病院内のシステム（ＭＤＴミーティングシステム等）から取得される。

関連情報取得部２５３は、格納部２５１に格納されているカテゴリ別関連情報、音声分類部２５２によって決定されたカテゴリ及び対象患者ＩＤに基づいて医療情報を取得する（ステップＳ７４）。

ここで、関連情報取得部２５３による医療情報の取得処理について具体的に説明する。この場合、関連情報取得部２５３は、格納部２５１に格納されているカテゴリ別関連情報を参照して、音声分類部２５２によって決定されたカテゴリに対応づけて当該カテゴリ別関連情報に含まれている参照情報を取得する。

次に、関連情報取得部２５３は、取得された参照情報によって表されるＵＲＩの患者ＩＤに対応する部分を対象患者ＩＤに基づいて変換する。具体的には、例えば関連情報取得部２５３によって取得された参照情報が図２９に示す「＊／ＰＡＣＳ／Ｐａｔｉｅｎｔ＊／＊．ｄｃｍ」であり、対象患者ＩＤが「Ｐａｔｉｅｎｔ９９」である場合には、関連情報取得部２５３は、当該「＊／ＰＡＣＳ／Ｐａｔｉｅｎｔ＊／＊．ｄｃｍ」を「＊／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／＊．ｄｃｍ」に変換する。

関連情報取得部２５３は、変換された参照情報に基づいて医療情報を外部のシステムから取得する。上記したように参照情報が「＊／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／＊．ｄｃｍ」に変換された場合には、当該「＊／ＰＡＣＳ／Ｐａｔｉｅｎｔ９９／＊．ｄｃｍ」の「＊」の部分に任意の文字列を含むＵＲＩに基づいてアクセス可能な医療情報が取得される。

これにより、関連情報取得部２５３は、ミーティングにおける議論の内容に関連する医療情報であって、対象患者に関する医療情報を取得することができる。

関連情報取得部２５３によって取得された医療情報は、関連情報送信部２６によってクライアント端末１５０に送信される（ステップＳ７５）。

クライアント端末１５０に含まれる情報表示部１２は、関連情報送信部２６によって送信された医療情報を、当該クライアント端末１５０において使用されているアプリケーションまたは当該医療情報を表示する可能なアプリケーションで表示する（ステップＳ７６）。

なお、図３０に示す処理を定期的に実行することにより、例えばミーティング中に議題（議論の内容）が変わった場合であっても、当該議論の内容の変化に応じて適切な医療情報をクライアント端末１５０において表示することが可能である。

上記したように本実施形態においては、ミーティング中の参加者の音声に基づいて取得された医療情報がクライアント端末１５０において表示される構成により、ミーティングにおける議論の内容に応じた医療情報を迅速に表示することが可能となる。

以上説明した実施形態によれば、患者に関する情報を迅速に表示することが可能な医療情報管理システムを提供することが可能となる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１０，１００，１１０，１５０…クライアント端末、１１，１５２…情報送受信部、１２…情報表示部、２０，２００，２１０，２２０，２３０，２４０，２５０…医療情報管理サーバ、２１，２２１，２３１，２４１，２５１…格納部、２２，２３２…認証部、２３…情報参照履歴取得部、２４…情報参照履歴変換部、２５，２５３…関連情報取得部、２６，２３３…関連情報送信部、１０１…使用状況認識部、１０２…使用状況送信部、１１１…情報取得部、１１２…情報取得状況検出部、１１３…情報取得状況通知部、１３０…参加者端末、１３１…情報送受信部、１３２…情報表示部、１５１…音声取得部、２０１…関連情報変換部、２１１…情報参照履歴更新部、２２２…関連情報絞込部、２４２…情報比較部、２５２…音声分類部。

Claims (10)

1. クライアント端末及び当該クライアント端末と通信可能に接続される医療情報管理サーバを具備する医療情報管理システムにおいて、
   前記クライアント端末は、送信手段と、表示手段とを含み、
   前記医療情報管理サーバは、格納手段と、第１の取得手段と、第２の取得手段と、第３の取得手段とを含み、
   前記格納手段は、患者について議論するための過去のミーティングにおいて参照された当該患者に関する第１の医療情報を参照するための参照情報を、当該ミーティングを行った複数の参加者から構成される医療チームの種別を示す種別情報に対応づけて含む情報参照履歴情報を予め格納し、
   前記送信手段は、患者について議論するためのミーティングを行う医療チームの種別を示す種別情報を前記医療情報管理サーバに送信し、
   前記第１の取得手段は、前記送信された種別情報に対応づけて前記情報参照履歴情報に含まれる第１の医療情報を参照するための参照情報を取得し、
   前記第２の取得手段は、前記送信された種別情報によって示される種別の医療チームが行うミーティングにおいて議論される患者を識別するための患者識別情報を取得し、
   前記第３の取得手段は、前記第１の取得手段によって取得された第１の医療情報を参照するための参照情報に基づいて、前記第２の取得手段によって取得された患者識別情報によって識別される患者に関する第２の医療情報を取得し、
   前記表示手段は、前記第３の取得手段によって取得された第２の医療情報を表示する
   ことを特徴とする医療情報管理システム。
2. 前記医療情報管理サーバは、参照情報変換手段を更に含み、
   前記格納手段に格納されている情報参照履歴情報に含まれる第１の医療情報を参照するための参照情報は、当該第１の医療情報を保存している外部のシステムにおける当該第１の医療情報の保存位置を示すＵＲＩを含み、
   前記参照情報変換手段は、前記第１の取得手段によって取得された第１の医療情報を参照するための参照情報に含まれるＵＲＩを前記第２の取得手段によって取得された患者識別情報に基づいて変換し、
   前記第３の取得手段は、前記変換されたＵＲＩに基づいて、前記第２の医療情報を前記外部のシステムから取得する
   ことを特徴とする請求項１記載の医療情報管理システム。
3. 前記格納手段に格納されている情報参照履歴情報は、前記種別情報に対応づけて前記第１の医療情報の表示形式を更に含み、
   前記第１の取得手段は、前記送信された種別情報に対応づけて前記情報参照履歴情報に含まれる第１の医療情報の表示形式を更に取得し、
   前記表示手段は、前記第２の取得手段によって取得された第２の医療情報を前記第１の取得手段によって取得された第１の医療情報の表示形式で表示する
   ことを特徴とする請求項１記載の医療情報管理システム。
4. 前記クライアント端末は、当該クライアント端末において使用されているアプリケーションを認識する認識手段を更に含み、
   前記医療情報管理サーバは、前記第３の取得手段によって取得された第２の医療情報を、前記認識されたアプリケーションで表示可能な形式に変換する医療情報変換手段を更に含み、
   前記表示手段は、前記変換された第２の医療情報を表示する
   ことを特徴とする請求項１記載の医療情報管理システム。
5. 前記クライアント端末は、当該クライアント端末が外部のシステムから第３の医療情報を取得したことを前記医療情報管理サーバに通知する通知手段を更に含み、
   前記医療情報管理サーバは、前記通知に基づいて、前記第３の医療情報を参照するための参照情報を前記送信された種別情報に対応づけて含む情報参照履歴情報を前記格納手段に格納する情報参照履歴更新手段を更に含む
   ことを特徴とする請求項１記載の医療情報管理システム。
6. 前記医療情報管理サーバは、前記送信された種別情報によって示される種別の医療チームを構成する参加者の役割を取得する第４の取得手段を更に含み、
   前記第３の取得手段は、前記第１の取得手段によって取得された第１の医療情報を参照するための参照情報に基づいて、前記第２の取得手段によって取得された患者識別情報によって識別される患者に関する第２の医療情報であって、前記第４の取得手段によって取得された参加者の役割に関連する第２の医療情報を取得する
   ことを特徴とする請求項１記載の医療情報管理システム。
7. 前記送信された種別情報によって示される種別の医療チームを構成する参加者が保持する参加者端末を更に具備し、
   前記医療情報管理サーバは、前記送信された種別情報によって示される種別の医療チームを構成する参加者の役割を取得する第４の取得手段を更に含み、
   前記第３の取得手段は、前記第１の取得手段によって取得された第１の医療情報を参照するための参照情報に基づいて、前記第２の取得手段によって取得された患者識別情報によって識別される患者に関する第２の医療情報であって、前記第４の取得手段によって取得された参加者の役割に関連する第２の医療情報を取得し、
   前記参加者端末は、前記第３の取得手段によって取得された第２の医療情報のうち当該参加者端末を保持する参加者の役割に関連する第２の医療情報を表示する表示手段を含む
   ことを特徴とする請求項１記載の医療情報管理システム。
8. 前記格納手段は、患者について議論するための過去のミーティングにおいて参照された当該患者に関する第３の医療情報を参照するための参照情報を、当該患者を示す第１の患者情報に対応づけて含む患者履歴情報を更に格納し、
   前記医療情報管理サーバは、前記第２の取得手段によって取得された患者識別情報によって識別される患者を示す第２の患者情報を取得する第４の取得手段を更に含み、
   前記第１の取得手段は、前記第４の取得手段によって取得された第２の患者情報と類似する前記第１の患者情報に対応づけて前記患者履歴情報に含まれる第３の医療情報を参照するための参照情報を更に取得し、
   前記第３の取得手段は、前記第１の取得手段によって取得された前記第３の医療情報を参照するための参照情報に基づいて、前記第２の取得手段によって取得された患者識別情報によって識別される患者に関する第４の医療情報を更に取得し、
   前記表示手段は、前記第３の取得手段によって取得された第４の医療情報を更に表示する
   ことを特徴とする請求項１記載の医療情報管理システム。
9. 前記医療情報管理サーバは、
   前記第３の取得手段によって取得された第２の医療情報より過去の前記第２の取得手段によって取得された患者識別情報によって識別される患者に関する第３の医療情報を取得する第４の取得手段と、
   前記第３の取得手段によって取得された第２の医療情報と前記第４の取得手段によって取得された第３の医療情報との差分を示す差分情報を生成する生成手段と、
   前記生成された差分情報に基づいて、前記第３の取得手段によって取得された第２の医療情報に対して差分強調処理を実行する差分強調処理手段と
   を更に含み、
   前記表示手段は、前記差分強調処理が実行された第２の医療情報を表示する
   ことを特徴とする請求項１記載の医療情報管理システム。
10. クライアント端末及び当該クライアント端末と通信可能に接続される医療情報管理サーバを具備する医療情報管理システムにおいて、
    前記クライアント端末は、音声取得手段と、表示手段とを含み、
    前記医療情報管理サーバは、音声分類手段と、識別情報取得手段と、関連情報取得手段とを含み、
    前記音声取得手段は、患者について議論するためのミーティングの参加者の音声を取得し、
    前記音声分類手段は、前記音声取得手段によって取得された音声に対して音声認識処理を実行し、当該音声認識処理結果に基づいて前記ミーティングの内容を表すカテゴリを決定し、
    前記関連情報取得手段は、前記決定されたカテゴリに関連する医療情報であって前記ミーティングにおいて議論されている患者に関する医療情報を取得し、
    前記表示手段は、前記関連情報取得手段によって取得された医療情報を表示する
    ことを特徴とする医療情報管理システム。

Images