連携実施計画支援システム及び連携実施計画支援プログラム
【課題】実施対象に対して複数の実施行為を実施するための実施計画を、さらに複数連携させて実施される連携実施計画の管理や実行を支援することができる、連携実施計画支援システム及び連携実施計画支援プログラムを提供する。
【解決手段】連携実施計画支援システム１の連携実施計画支援サーバ１０は、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報を格納する実施計画情報ＤＢ２１ｄと、複数の実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報を格納する連携実施計画情報ＤＢ２１ｅと、連携実施計画情報の少なくとも一部を取得すると共に、当該連携実施計画に対応する複数の実施計画に関する実施計画情報の少なくとも一部を取得し、当該取得した情報を併せて支援端末３０を介して出力する制御部１２とを備える。
【解決手段】連携実施計画支援システム１の連携実施計画支援サーバ１０は、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報を格納する実施計画情報ＤＢ２１ｄと、複数の実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報を格納する連携実施計画情報ＤＢ２１ｅと、連携実施計画情報の少なくとも一部を取得すると共に、当該連携実施計画に対応する複数の実施計画に関する実施計画情報の少なくとも一部を取得し、当該取得した情報を併せて支援端末３０を介して出力する制御部１２とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、実施対象に対して複数の実施行為を実施するための実施計画を、さらに複数連携させて実施される連携実施計画の管理や実行を支援する、連携実施計画支援システム及び連携実施計画支援プログラムに関する。
【背景技術】
【０００２】
従来、医療関連行為を二次元構造で示したクリティカルパスが知られている。このクリティカルパスは、それまで医師の個人的な暗黙知として蓄積された膨大な医療知識を、標準化及び可視化を通じて形式知として提示することで、医療の質と効率を系統的に保証及び向上させることができる点で有用である。しかしながら、患者の状態によっては、クリティカルパスを適用できなかったり、予め想定された標準的な経過から乖離してしまいクリティカルパスを逸脱する可能性があるという問題が指摘されていた。
【０００３】
この点に鑑みて本願発明者等は、医療プロセス質管理システム及び医療プロセス質管理方法を提案した（特許文献１参照）。このシステムは、患者に対して実施する複数の医療プロセス及び各医療プロセスの実施順序等を記憶する記憶部と、次に実施する医療プロセスを読み出すプロセス管理部等を備えて構成されている。このシステムにおいては、「プロセスチャート（臨床プロセスチャート）」と「ユニットシート」を用いて、医療行為の内容を臨床経路に従って医師等に順次提示する。「ユニットシート」とは、患者の目標状態毎に形成された医療行為単位である「ユニット（プロセス）」を視覚化したものである。「プロセスチャート」は、複数のユニットを連結して構成される臨床経路の俯瞰図である。
【０００４】
このようにプロセスチャートとユニットシートという２種類のツールによって、医療行為の内容や実施順序を標準化された内容で各医師に提示することで、各医師が個別的に独自判断で医療行為の内容や実施順序を決定する場合に比べて、医療行為の標準化を図ることができ、延いては医療プロセスの質を維持及び向上させることができる。また、このシステムによれば、患者の個別性に柔軟に対応できるので、従来のクリティカルパスの問題点を解消することが可能になる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２００６／０５７３３６号パンフレット
【特許文献２】特開２００７−１２８３５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、このような従来の医療プロセス質管理システムや医療プロセス質管理方法は、主として一人の患者に対する医療計画を対象としたものであるため、複数の患者のそれぞれに対する医療計画が相互に連携しつつ進行するような場合に、この進行の状態や連携の可否等を統合的に管理することには必ずしも適しているとは言えなかった。
【０００７】
例えば、生体肝移植を行う場合においては、肝臓を提供する者（以下、ドナー）と、肝臓の提供を受ける者（以下、レシーピエント）とが存在する。この場合、従来の医療プロセス質管理システムや医療プロセス質管理方法では、ドナーに対する医療計画と、レシーピエントに対する医療計画とを、相互に独立して管理等することは可能であるが、ドナーの状態に応じてレシーピエントに対する医療行為の内容や順序を決定する必要がある場合等、ドナー対する医療計画とレシーピエントに対する医療計画を相互に連携しつつ進行させたい場合には、この進行の状態や連携の可否等を管理することが困難であった。
【０００８】
本発明は、上記に鑑みてなされたものであって、実施対象に対して複数の実施行為を実施するための実施計画を、さらに複数連携させて実施される連携実施計画の管理や実行を支援することができる、連携実施計画支援システム及び連携実施計画支援プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、請求項１に係る連携実施計画支援システムは、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段とを備える。
【００１０】
請求項２に係る連携実施計画支援システムは、請求項１に係る連携実施計画支援システムにおいて、前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、前記制御手段は、前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う。
【００１１】
請求項３に係る連携実施計画支援システムは、請求項２に係る連携実施計画支援システムにおいて、前記連携実施計画情報格納手段に格納される前記連携実施計画情報は、前記連携実施計画の種類を特定する連携実施計画種類情報を含み、前記特定状態情報格納手段は、前記特定状態情報を前記連携実施計画種類情報に関連付けて格納し、前記制御手段は、前記連携実施計画に対応する前記連携実施計画種類情報を前記連携実施計画情報格納手段から取得し、当該取得した連携実施計画種類情報に対応する前記特定状態情報を前記特定状態情報格納手段から取得し、前記実施計画情報格納手段から取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定する。
【００１２】
請求項４に係る連携実施計画支援システムは、請求項１から３のいずれか一項に係る連携実施計画支援システムにおいて、前記実施計画情報格納手段に格納される前記実施行為内容情報は、複数の前記実施計画の連携性を判定するために使用する連携性判定情報を含み、前記連携実施計画において連携させる複数の前記実施計画の連携性を判定するための連携性判定条件を特定する連携性判定条件情報を格納する連携性判定条件情報格納手段を備え、前記制御手段は、前記特定された連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記連携性判定情報を前記実施計画情報格納手段から取得すると共に、前記特定された連携実施計画に対応する前記連携性判定条件情報を前記連携性判定条件情報納手段から取得し、当該取得した連携性判定情報に基づいて、当該取得した連携性判定条件情報にて特定される連携性判定条件が満たされるか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う。
【００１３】
請求項５に係る連携実施計画支援システムは、請求項１から４のいずれか一項に係る連携実施計画支援システムにおいて、前記実施対象は患者であり、前記実施行為は医療行為であり、前記実施計画は医療計画であり、前記連携実施計画は連携医療計画である。
【００１４】
請求項６に係る連携実施計画支援プログラムは、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、を備えるコンピュータに実行させるプログラムであって、前記コンピュータを、前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段として機能させる。
【００１５】
請求項７に係る連携実施計画支援プログラムは、請求項６に係る連携実施計画支援プログラムは、前記コンピュータの前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、前記コンピュータは、前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、前記コンピュータを、前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う前記制御手段として機能させる。
【００１６】
請求項８に係る連携実施計画支援プログラムは、請求項６又は７に係る連携実施計画支援プログラムは、前記実施対象は患者であり、前記実施行為は医療行為であり、前記実施計画は医療計画であり、前記連携実施計画は連携医療計画である。
【発明の効果】
【００１７】
請求項１に係る連携実施計画支援システム又は請求項６に係る連携実施計画支援プログラムによれば、連携実施計画情報と複数の実施計画情報を併せて出力するので、この出力を参照することで、連携実施計画において連携される可能性がある複数の実施計画の内容や状況を把握することが可能となり、これら複数の実施計画を一つのプロジェクト（エピソード）として管理することが可能になるので、連携実施計画の管理や実行を容易かつ的確に行うことが可能となる。従って、実施行為の質を高めることが可能となる。
【００１８】
請求項２に係る連携実施計画支援システム又は請求項７に係る連携実施計画支援プログラムによれば、実施対象の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、複数の実施計画が特定の状態になった場合に連携実施計画が進行する場合等において、連携実施計画の進行の可否や適否を判断することが容易になり、連携実施計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００１９】
請求項３に係る連携実施計画支援システムによれば、連携実施計画の種類に応じて特定された特定状態情報に基づいて、実施対象の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、連携実施計画の種類に応じた適切な特定状態情報に基づいて連携実施計画の進行の可否や適否を判断することが容易になり、連携実施計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００２０】
請求項４に係る連携実施計画支援システムによれば、連携性判定条件が満たされるか否かが出力手段を介して報知されるので、複数の実施計画が所定条件下でのみ連携可能である場合等において、複数の実施計画を連携させることの可否や適否を判断することが容易になり、連携実施計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００２１】
請求項５に係る連携実施計画支援システム又は請求項８に係る連携実施計画支援プログラムによれば、連携医療計画において連携される可能性がある複数の医療計画の内容や状況を把握することが可能となり、これら複数の医療計画を一つのプロジェクト（エピソード）として管理することが可能になるので、連携医療計画の管理や実行を容易かつ的確に行うことが可能となる。従って、医療行為の質を高めることが可能となる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施の形態に係る連携医療計画支援システムの全体構成を概念的に示す説明図である。
【図２】プロセスチャート及びユニットシートの基本構成モデルを示す図である。
【図３】ユニットシートの表示画面例を示す図である。
【図４】生体肝移植のレシーピエントのプロセスチャート（一部）の例を示す図である。
【図５】生体肝移植のドナーのプロセスチャートの例を示す図である。
【図６】患者情報の構成例を示す図である。
【図７】医師情報の構成例を示す図である。
【図８】疾患情報の構成例を示す図である。
【図９】医療計画情報の構成例を示す図である。
【図１０】連携医療計画情報の構成例を示す図である。
【図１１】連携医療計画種類情報の構成例を示す図である。
【図１２】特定状態情報の構成例を示す図である。
【図１３】連携性判定条件情報の構成例を示す図である。
【図１４】連携医療計画情報登録処理のフローチャートである。
【図１５】連携医療計画情報登録用画面の表示例を示す図である。
【図１６】連携医療計画情報出力処理のフローチャートである。
【図１７】連携医療計画情報出力用画面の表示例を示す図である。
【発明を実施するための形態】
【００２３】
以下に添付図面を参照して、この発明に係る連携実施計画支援システム及び連携実施計画支援プログラムを実施するための一形態について詳細に説明する。まず、〔I〕本実施の形態の基本概念を説明した後、〔II〕本実施の形態の具体的内容について説明し、〔III〕最後に本実施の形態に対する変形例について説明する。ただし、本実施の形態によって本発明が限定されるものではない。
【００２４】
〔I〕本実施の形態の基本概念
まず、本実施の形態の基本概念について説明する。本実施の形態に係る連携実施計画支援システム及び連携実施計画支援プログラムは、複数の実施計画を連携させて実施される可能性がある連携実施計画の管理や実行を支援するものである。ここで、実施計画とは、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される。
【００２５】
連携実施計画支援システム及び連携実施計画支援プログラムは、広範な分野に適用可能であり、概念的には、当該分野における形式知（具体的には、実施対象に対して実施者が実施する複数の実施行為の内容と、これら複数の実施行為の相互間の実施順序）を構造化することで可視化が可能な全ての分野に適用可能である。この適用分野の例としては、「医療分野」、「防災分野」、「教育分野」を挙げることができ、この適用分野に応じて、「実施対象」、「実施者」、「実施行為」、「実施計画」、「連携実施計画」の具体的内容は異なり得る。例えば、医療分野では、実施対象＝患者、実施者＝医師（又は病院の如き医療機関）、実施行為＝医療行為、実施計画＝医療計画、連携実施計画＝複数の患者や疾患に対する医療計画を連携して行われ得る連携医療計画である。同様に、防災分野では、実施対象＝災害やテロ行為の被災者や被災物、実施者＝救援者、実施行為＝救援行為、実施計画＝救援計画、連携実施計画＝複数の地域や被災者に対する救援計画を連携して行われ得る連携救援計画が該当し、教育分野では、実施対象＝生徒、実施者＝教師、実施行為＝教育行為、実施計画＝教育計画、連携実施計画＝複数の地域や生徒に対する教育計画を連携して行われ得る連携教育計画が該当する。
【００２６】
以下では、連携実施計画支援システム及び連携実施計画支援プログラムを医療分野に適用した場合について説明するものとし、実施対象＝患者、実施者＝医師や看護師等の医療従事者、実施行為＝医療行為、実施計画＝医療計画、連携実施計画＝連携医療計画と読み替えて説明する。また、連携実施計画支援システムは連携医療計画支援システム（以下「本システム」）、連携実施計画支援プログラムは連携医療計画支援プログラム（以下「本プログラム」）と読み替えて説明する。なお、本システム及び本プログラムを他の分野に適用する場合には、上述のように「実施対象」、「実施者」、「実施行為」、「実施計画」、「連携実施計画」の内容を当該他の分野に応じた内容に読み替えればよい。
【００２７】
なお、連携医療計画は、複数の医療計画を連携して行われ得る計画であるが、「連携して行われ得る」とは、一つの連携実施計画において、複数の実施計画が連携する候補となるが、これら候補となる実施計画が必ず連携する場合の他、候補となる実施計画が条件によっては連携しない場合があることを意味している。例えば、生体肝移植において、一つのレシーピエントと複数のドナーが存在する場合、複数のドナーの中のいずれか一人のみが、最終的なドナーとなって肝臓を提供することになるが、このように、レシーピエントの医療計画に対して、複数のドナーの医療計画の一部しか最終的に連携しない場合であっても、レシーピエントの医療計画と、複数のドナーの医療計画が、相互に連携し得るものとして説明される。
【００２８】
図１は、連携医療計画支援システムの全体構成を概念的に示す説明図である。この図１に示すように、複数の病院の各々には、連携医療計画支援システム１が設置されている。この連携医療計画支援システム１は、連携医療計画支援サーバ１０、電子カルテサーバ２０、支援端末３０を、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）の如きネットワーク４０を介して相互に通信可能に接続して構成されている。また、連携医療計画支援システム１には、医療計画作成支援サーバ５０がインターネットの如きネットワーク６０を介して通信可能に接続されている。
【００２９】
本実施形態では、上述の特許文献１又は特許文献２に全部又は一部が開示された「患者状態適応型パスシステム（ＰＣＡＰＳ：Ｐａｔｉｅｎｔ Ｃｏｎｄｉｔｉｏｎ Ａｄａｐｔｉｖｅ Ｐａｔｈ Ｓｙｓｔｅｍ）」を利用する。この患者状態適応型パスシステムは、患者の初期状態から最終目標状態に至る臨床経路を示す俯瞰的なモデルであり、この臨床経路を、「患者状態」を基軸とする複数の「目標状態」を相互にリンクして視覚化したものであって、具体的には「プロセスチャート（臨床プロセスチャート）」と「ユニットシート」の２つのツールを用いて構成される。
【００３０】
図２には、これらプロセスチャート及びユニットシートの基本構成モデルを示す。プロセスチャートとは、患者の目標状態毎に形成された医療行為単位（医療の質を管理するために適切な大きさに設定された単位）である「ユニット（プロセス）」を連結することで構成される臨床経路の俯瞰図であり、疾患毎に構成され、当該疾患を有する患者の初期状態から最終目標状態に至る間に想定されるすべての臨床状態を包含する。各ユニットは「実行エレメント」と「判断エレメント」とから構成されている。実行エレメントは、患者状態を当該ユニットの目標状態に達するように組み込まれた医療業務を実行していく行為を示し、判断エレメントは、患者状態が当該ユニットの目標状態に達したか否かを判断する行為を示す。そして、各実行エレメントと、当該各実行エレメントの直後の判断エレメントとを、視覚的に表示する手段として「ユニットシート」が構成される。
【００３１】
このユニットシートの表示画面例を図３に示す。具体的にはユニットシートは、「患者ＩＤ」、「ユニットＩＤ」、「医療行為」、「患者状態」、「目標状態」、「ユニット移行ロジック」、「条件付き指示」、「離脱条件」を含む。患者ＩＤは、当該ユニットシートが適用されている患者を一意に特定するための識別情報である。ユニットＩＤは、当該ユニットシートに対応するユニットを一意に特定するための識別情報である。医療行為は、当該ユニットシートに対応する実行エレメントにおいて実行すべき医療行為の項目や内容を記述した情報であり、例えば、医行為、ケア行為、及び調整行為を含む。患者状態は、当該ユニットシートに対応するユニットにおいて注目すべき患者状態の内容を記述した情報である。ユニット移行ロジックは、当該ユニットシートに対応するユニットから次順のユニットに移行するときの条件及び移行先のユニットシートに対応するユニットＩＤを記述した情報である。条件付き指示は、当該ユニットにおける医療行為中に発生した患者状態に早急に対応するための指示内容を含んで構成されている。離脱条件は、目標状態からの危険な乖離の判断基準を示す遷移状態になった場合には、当該ユニットシートを離脱すべき場合があるため、この離脱を行うための条件を含んで構成されている。
【００３２】
このように構成される「プロセスチャート」及び「ユニットシート」は、図１の医療計画作成支援サーバ５０によるＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）サービスを用いて、各病院の医師等が作成することができる。すなわち、医療計画作成支援サーバ５０には、各病院に共通の標準的な「プロセスチャート」及び「ユニットシート」を特定するための情報が格納されている。そして、各病院の医師等は、医療計画作成支援サーバ５０に支援端末３０を介してアクセスし、標準的な「プロセスチャート」及び「ユニットシート」を呼び出し、この標準的な「プロセスチャート」及び「ユニットシート」を自己の病院に合致した個別的な「プロセスチャート」及び「ユニットシート」に所定方法でカスタマイズして連携医療計画支援サーバ１０に格納することで、プロセスチャート及びユニットシートの作成を行うことができる。
【００３３】
このように作成された「プロセスチャート」及び「ユニットシート」の実施は、連携医療計画支援サーバ１０の後述する医療計画管理部１２ａによって制御される。すなわち、この医療計画管理部１２ａは、プロセスチャートにおける最初のユニットに対応するユニットシートの内容を支援端末３０を介して医師に対して表示出力等にて提示する。そして、医師が、当該提示されたユニットシートに含まれる医療行為を行い、その後の患者状態を支援端末３０に入力すると、この患者状態が支援端末３０を介して連携医療計画支援サーバ１０にて受け付けられる。次いで、連携医療計画支援サーバ１０は、患者状態が当該ユニットの目標状態に達したか否かを判断する。目標状態に達したと判断した場合には、当該最初のユニットの次順のユニットをプロセスチャートに基づいて特定し、当該次順のユニットに対応するユニットシートの内容を支援端末３０を介して医師に対して提示する。以降同様に、プロセスチャートにて定義された順序に従ったユニットに対応するユニットシートの内容の提示処理と、医師による患者状態の入力を受け付ける処理と、目標状態に達したか否かを判断する判断処理とが繰り返し行われ、プロセスチャートにおける最後のユニットの医療行為が終了することで、一連の処理が終了する。
【００３４】
図４は、生体肝移植のレシーピエントのプロセスチャート（一部）の例、図５は、生体肝移植のドナーのプロセスチャートの例である。これらのプロセスチャートは、複数のユニットの各々を構成する実行エレメント及び判断エレメントと、これら各エレメントを相互に接続する線分とを含んでおり、当該線分によって各エレメントの相互間の実施順序が視覚的に示されている。例えば、図４のプロセスチャートでは、実行エレメント「Ａ−７」の医療行為を実行した後、判断エレメントにおいて患者状態と目標状態とに基づく判断を行い（ただし、判断エレメントの図示は省略する）、この判断結果に応じて、実行エレメント「Ａ−８」又は「Ａ−９」のいずれかに移行する。図４、５における各実行エレメントの枠内には、各実行エレメントに対応するユニットの名称及びユニットＩＤを示す。例えば、図４のプロセスチャートでは、最初の実行エレメントに対応するユニットの名称は「術前評価（絶対的ｃｏｎｔｒａ症例の例外）」であり、ユニットＩＤは「Ａ−１」である。
【００３５】
〔II〕本実施の形態の具体的内容
次に、本実施の形態の具体的内容について説明する。以下では、図１に示した各部の構成について説明し、次いで、連携医療計画支援プログラムの処理内容について説明する。
【００３６】
（構成−連携医療計画支援サーバ）
最初に、図１の連携医療計画支援サーバ１０の構成を説明する。この連携医療計画支援サーバ１０は、連携医療計画を支援する連携医療計画支援装置であり、機能概念的に、記憶部１１、制御部１２、及びネットワークインターフェース（以下、インターフェースは「ＩＦ」）１３を、バス１４にて相互に通信可能に接続して構成されている。
【００３７】
記憶部１１は、各種処理に必要な情報やパラメータを不揮発的に格納する格納手段であり、例えば、ＨＤ（Ｈａｒｄ Ｄｉｓｋ）にて構成される。具体的には、この記憶部１１は、機能概念的に、患者情報データベース（以下、データベースは「ＤＢ」）１１ａ、医師情報ＤＢ１１ｂ、疾患情報ＤＢ１１ｃ、医療計画情報ＤＢ１１ｄ、連携医療計画情報ＤＢ１１ｅ、連携医療計画種類情報ＤＢ１１ｆ、特定状態情報ＤＢ１１ｇ、及び連携性判定条件情報ＤＢ１１ｈを備える。これら各ＤＢ１１ａ〜１１ｈに格納される情報の具体的内容については後述する。
【００３８】
制御部１２は、連携医療計画支援サーバ１０の各部を制御する制御手段であり、機能概念的に、医療計画管理部１２ａ及び連携医療計画管理部１２ｂを備える。医療計画管理部１２ａは、医療計画の実行を管理する医療計画管理手段である。連携医療計画管理部１２ｂは、連携医療計画の実行を管理する連携医療計画管理手段である。さらに、連携医療計画管理部１２ｂは、連携医療計画情報登録部１２ｂ１及び連携医療計画情報出力部１２ｂ２を備える。連携医療計画情報登録部１２ｂ１は、連携医療計画情報を登録するための連携医療計画情報登録処理を行う連携医療計画情報登録手段である。連携医療計画情報出力部１２ｂ２は、連携医療計画情報登録処理で登録された連携医療計画情報を出力するための連携医療計画情報出力処理を行う連携医療計画情報出力手段である。この制御部１２は、具体的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や、このＣＰＵ上で解釈実行される各種のプログラム（ＯＳなどの制御プログラムや、各種の処理手順などを規定したプログラム）、及び、所要プログラムや所要データを格納するためのキャッシュメモリを備えて構成される。このＣＰＵ上で解釈実行される各種のプログラムには本プログラムが含まれ、本プログラムは、例えば、ＣＤ−ＲＯＭやＤＶＤを含む任意の記憶媒体に記憶された後、インストールされて記憶部１１に不揮発的に記憶され、ＣＰＵにて解釈実行されることで制御部１２の実質的機能を構成する。
【００３９】
ネットワークＩＦ１３は、ネットワーク４０、６０を介した通信を行うための通信手段であり、例えばネットワークボードとして構成される。このネットワークＩＦ１３を介して支援端末３０等からの情報入力の受け付けが行われることから、当該ネットワークＩＦ１３は入力手段を構成する。また、このネットワークＩＦ１３を介して各種の情報の出力が行われることから、当該ネットワークＩＦ１３は出力手段を構成する。
【００４０】
（構成−電子カルテサーバ）
次に、電子カルテサーバ２０の構成を説明する。この電子カルテサーバ２０は、患者のカルテに関する電子情報を管理するカルテ情報管理装置である。この電子カルテサーバ２０の具体的構成は任意であり、連携医療計画支援サーバ１０との通信機能を有する限りにおいて、公知の電子カルテサーバと同様に構成できるために、その詳細な説明は省略する。なお、病院に配置されるサーバとしては、この電子カルテサーバ２０以外にも、医事会計サーバの如き公知の任意の情報処理装置を含めることができる。
【００４１】
（構成−支援端末）
各支援端末３０は、医師を含む医療従事者が連携医療計画支援サーバ１０に対して入出力を行うための端末装置であり、特に、連携医療計画支援サーバ１０や医療計画作成支援サーバ５０との通信機能と、患者状態の入力を受け付ける入力機能と、プロセスチャート及びユニットシートの出力を行う出力機能と、後述する連携医療計画管理画面の出力を行う出力手段として機能とを有する。この支援端末３０は、連携医療計画支援サーバ１０との通信機能や各種情報の入出力機能を有する限りにおいて、公知のパーソナルコンピュータと同様に構成できるために、その詳細な説明は省略する。
【００４２】
（構成−医療計画作成支援サーバ）
次に、医療計画作成支援サーバ５０の構成を説明する。この医療計画作成支援サーバ５０は、医療計画の作成を支援する医療計画作成支援装置であり、特に、連携医療計画支援サーバ１０や支援端末３０との通信機能と、標準的なプロセスチャート及びユニットシートを格納する機能と、支援端末３０を通じた要求に応じてプロセスチャート及びユニットシートを提供する機能と、これら「プロセスチャート」及び「ユニットシート」を個別的な「プロセスチャート」及び「ユニットシート」にカスタマイズすることを支援するための機能とが設けられている。ただし、この医療計画作成支援サーバ５０としては、例えば、本願発明者等による特開２００９−２０５６５４に開示されている作成サーバを使用することができる。
【００４３】
（構成−連携医療計画支援サーバのＤＢ）
次に、連携医療計画支援サーバ１０の各ＤＢ１１ａ〜１１ｈに格納される情報の具体的内容について説明する。ただし、以下の構成例では本実施の形態に係る情報のみを格納する例を示し、実際には以下に説明する情報以外の任意の情報を各ＤＢ１１ａ〜１１ｈに格納することができ、あるいは一部の情報については適宜省略することもある。また、各ＤＢ１１ａ〜１１ｈに格納される情報のうち、同一名称の情報については、特記する場合を除いて相互に同一の内容であるものとし、重複説明は行わないものとする。
【００４４】
図１の患者情報ＤＢ１１ａは、医療行為の対象である患者に関する情報（患者情報）を格納する手段である。この患者情報は、図６に例示するように、項目「患者ＩＤ」、項目「患者氏名」、項目「年齢」、項目「性別」、項目「住所」、及び項目「疾患ＩＤ」に対応する情報を相互に関連付けて構成されている。項目「患者ＩＤ」に対応する情報は、各医療計画の対象となる患者を一意に識別するための患者識別情報である。項目「患者氏名」、項目「年齢」、項目「性別」、項目「住所」に対応する情報は、それぞれ、各患者の氏名、年齢、性別、住所である。項目「疾患ＩＤ」に対応する情報は、各患者の各疾患を一意に識別するための疾患識別情報である。
【００４５】
図１の医師情報ＤＢ１１ｂは、各医師に関する情報（医師情報）を格納する医師情報格納手段である。この医師情報は、図７に例示するように、項目「医師ＩＤ」、項目「専門」、及び項目「経験年数」を相互に関連付けて構成されている。項目「医師ＩＤ」に対応する情報は、各医師を一意に識別するための医師識別情報である。項目「専門」に対応する情報は、各医師の専門分野である。項目「経験年数」に対応する情報は、各医師の医師としての経験年数である。
【００４６】
図１の疾患情報ＤＢ１１ｃは、各医療計画による治療の対象になる疾患に関する情報（疾患情報）を格納する疾患情報格納手段である。この疾患情報は、図８に例示するように、項目「疾患ＩＤ」、及び項目「疾患名」を相互に関連付けて構成されている。項目「疾患ＩＤ」に対応する情報は、図６の同一項目に対応する情報と共通である。項目「疾患名」に対応する情報は、各疾患の名称（病名）である。ただし、本実施の形態では、いわゆる病気に該当しない場合であっても、医療計画や連携医療計画の医療行為の対象になる場合があることを想定しており、このような場合における当該対象となる原因（あるいは、理由、位置付け、役割、立場）を示す情報も、疾患として疾患情報ＤＢ１１ｃに登録している。例えば、連携医療計画が生体肝移植である場合において、ドナーが健康であり疾患を持っていない場合であっても、当該生体肝移植のドナーである旨を疾患と同列に疾患情報に登録している。図８の例では、疾患ＩＤ＝ＳＩＤ０００３が、生体肝移植のドナーであることを示している。
【００４７】
図１の医療計画情報ＤＢ１１ｄは、患者に対して実施する複数の医療行為の内容と当該複数の医療行為の実施順序とを含んで構成される医療計画に関する医療計画情報（実施計画情報）であって、医療計画を一意に識別する医療計画識別情報（実施計画識別情報）と、複数の医療行為の内容を特定する医療行為内容情報（実施行為内容情報）と、複数の医療行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された医療計画情報（実施計画情報）、を格納する医療計画情報格納手段（実施計画情報格納手段）である。この医療計画情報は、図９に例示するように、項目「患者ＩＤ」、項目「医師ＩＤ」、項目「疾患ＩＤ」、項目「ユニットＩＤ」、項目「医療行為」、項目「患者状態」、項目「目標状態」、項目「ユニット移行ロジック」、項目「条件付き指示」、項目「離脱条件」、及び項目「標準滞在日数」に対応する情報を相互に関連付けて構成されている。項目「患者ＩＤ」、項目「医師ＩＤ」、及び項目「疾患ＩＤ」に対応する情報は、図６から８の同一項目に対応する情報とそれぞれ共通である。項目「ユニットＩＤ」に対応する情報は、ユニットを一意に識別するためのユニット識別情報である。項目「医療行為」、項目「患者状態」、項目「目標状態」、項目「ユニット移行ロジック」、項目「条件付き指示」、及び項目「離脱条件」の対応する各情報は、図３の説明において述べた通りであり、医療行為内容情報と実施順序情報の一部を構成する。項目「標準滞在日数」に対応する情報は、各ユニットの標準的な滞在日数（当該ユニットに移行してから次順のユニットへ移行するまでの日数）である。ここでは、項目「患者状態」に対応する情報（状態情報）には、各ユニットにおいて注目すべき患者状態の内容を記述した情報に加えて、この状態が測定された場合にはその測定結果を示す測定結果情報が併せて格納されているものとし、この測定結果情報が、実施計画の連携性を判定するために使用する連携性判定情報として機能する。図９の例では、ユニットＩＤ＝Ａ−２のユニットにおいて、測定された血圧が１２８であり、血液型がＡ型であり、組織適合抗原がＨＬＡ−Ａであることを示している。この医療計画情報は、例えば、患者の数に応じた数だけ（患者ＩＤ毎に）作成され、医療計画情報ＤＢ１１ｄに格納される。なお、医療計画情報の具体的な記述構造としては、図５に示した構成例以外の任意の構造を採用することができ、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式により、タグを用いて各情報の意味を構造化することができる。
【００４８】
図１の連携医療計画情報ＤＢ１１ｅは、複数の医療計画を連携させて実施される可能性がある連携医療計画に関する連携医療計画情報であって、連携させる可能性がある複数の医療計画に対応する医療計画識別情報（実施計画識別情報）を、相互に関連付けて構成された連携医療計画情報（連携実施計画情報）、を格納する連携医療計画情報格納手段（連携実施計画情報格納手段）である。この連携医療計画情報は、図１０に例示するように、項目「連携医療計画ＩＤ」、項目「連携医療計画種類ＩＤ」、項目「第１患者ＩＤ」、及び項目「第２患者ＩＤ」に対応する情報を相互に関連付けて構成されている。項目「連携医療計画ＩＤ」に対応する情報は、連携医療計画を一意に識別するための連携医療計画識別情報である。項目「連携医療計画種類ＩＤ」は、連携医療計画の種類を一意に識別するための連携医療計画種類情報（連携実施計画種類情報）である。項目「第１患者ＩＤ」に対応する情報は、連携医療計画ＩＤにて識別される連携医療計画に対応する複数の医療計画の対象となる患者の患者ＩＤであって、第１グループに属する患者（以下、第１患者）のＩＤであり、医療計画識別情報（実施計画識別情報）として機能する。項目「第２患者ＩＤ」に対応する情報は、連携医療計画ＩＤにて識別される連携医療計画に対応する複数の医療計画の対象となる患者の患者ＩＤであって、第２グループに属する患者（以下、第２患者）のＩＤであり、医療計画識別情報（実施計画識別情報）として機能する。第１グループに属する患者とは、連携医療計画ＩＤにて識別される連携医療計画において、共通の条件に合致するために相互に入れ替わることが可能な患者を意味しており、例えば、連携医療計画が生体肝移植である場合には、ドナーとなる患者が該当する。第２グループに属する患者とは、連携医療計画ＩＤにて識別される連携医療計画において、第１グループとは異なる共通の条件に合致するために相互に入れ替わることが可能な患者を意味しており、例えば、連携医療計画が生体肝移植である場合には、レシーピエントとなる患者が該当する。また、第１グループに属する患者と第２グループに属する患者とは、それぞれ単数又は複数である可能性があり、特定の連携医療計画ＩＤの第１グループに属する患者が他の連携医療計画ＩＤの第１グループにも属する可能性がある。例えば、図１０の例では、患者ＩＤ＝ＰＩＤ０００１の患者は、連携医療計画ＩＤ＝ＲＩＤ０００１の連携医療計画における第１グループと、連携医療計画ＩＤ＝ＲＩＤ０００２の連携医療計画における第１グループに属しており、例えば、後述する図１１の内容を参照すると、一人のドナーが、生体肝移植のドナーとしてレシーピエントに対して肝臓を提供する可能性があると共に、死体肝移植のドナーとしてレシーピエントに対して肝臓を提供する可能性がある場合を示している。
【００４９】
図１の連携医療計画種類情報ＤＢ１１ｆは、連携医療計画の種類を特定するための連携医療計画種類情報を格納する連携医療計画種類情報格納手段である。この連携医療計画種類情報は、図１１に例示するように、項目「連携医療計画種類ＩＤ」、項目「連携医療計画種類名」、項目「第１患者の種類」、及び項目「第２患者の種類」に対応する情報を相互に関連付けて構成されている。項目「連携医療計画種類ＩＤ」に対応する情報は、図１０の同一項目に対応する情報と共通である。項目「連携医療計画種類名」に対応する情報は、連携医療計画の種類の名称である。項目「第１患者の種類」に対応する情報は、連携医療計画における第１患者の種類（あるいは、原因、理由、位置付け、役割、立場）である。項目「第２患者の種類」に対応する情報は、連携医療計画における第２患者の種類（あるいは、原因、理由、位置付け、役割、立場）である。
【００５０】
図１の特定状態情報ＤＢ１１ｇは、医療計画における実施対象が取り得る状態の中で、連携医療計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段である。この特定状態情報は、図１２に例示するように、項目「連携医療計画種類ＩＤ」及び項目「患者状態」を相互に関連付けて構成されている。これらの各項目に対応する情報は、図９、１０の同一項目に対応する情報と共通である。例えば、図１２の例では、連携医療計画種類ＩＤ＝ＲＫＩＤ０００２の連携医療計画における特定の状態とは、この連携医療計画に連携された医療計画の対象になる第１患者が心臓死した状態であることを示している。
【００５１】
図１の連携性判定条件情報ＤＢ１１ｈは、連携医療計画において連携させる複数の医療計画の連携性を判定するための連携性判定条件を特定する連携性判定条件情報を格納する連携性判定条件情報格納手段である。この連携性判定条件情報は、図１３に例示するように、項目「連携医療計画種類ＩＤ」及び項目「連携性判定条件」を相互に関連付けて構成されている。項目「連携医療計画種類ＩＤ」に対応する情報は、図１０の同一項目に対応する情報と共通である。項目「連携性判定条件」に対応する情報は、連携性判定条件を示す情報である。例えば、図１３の例では、連携医療計画種類ＩＤ＝ＲＫＩＤ０００１の連携医療計画における連携性判定条件とは、第１患者と第２患者の相互間で、血液型が適合し、かつ、組織適合抗原が適合することであることを示す。
【００５２】
（処理）
次に、本システムにおいて本プログラムを実行すること等によって行われる連携医療計画支援処理（以下、本処理）について説明する。この処理は、連携医療計画情報を登録するための連携医療計画情報登録処理と、この連携医療計画情報登録処理で登録された連携医療計画情報を出力するための連携医療計画情報出力処理に大別される。以下、これら各処理を順次説明する。なお、ステップは「Ｓ」と略記する。
【００５３】
以下の本処理の説明において、制御主体を特記しない処理については、連携医療計画支援サーバ１０の制御部１２にて実行されるものとし、情報の取得元や取得経路を特記しない場合については、公知のタイミング及び公知の方法にて、連携医療計画支援サーバ１０の記憶部１１に予め格納されており、あるいは、支援端末３０を介して医療従事者によって入力されるものとする。特に、図６の患者情報、図７の医師情報、図８の疾患情報、及び図９の医療計画情報については、本願発明者等による特開２００９−２０５６５４に開示されている処理と同様の処理により、あるいはその他の任意の処理により、支援端末３０を介して医療従事者によって予め入力することができる。また、図１１の連携医療計画種類情報、図１２の特定状態情報、及び図１３の連携性判定条件情報については、医療従事者が医学的見地に基づいて決定し、支援端末３０を介して医療従事者によって予め入力することができる。
【００５４】
（処理−連携医療計画情報登録処理）
最初に、連携医療計画情報登録処理について説明する。図１４は、連携医療計画情報登録処理のフローチャートである。医療従事者は、連携医療計画を作成したい場合には、支援端末３０を介して連携医療計画支援サーバ１０にアクセスして所定の方法で連携医療計画情報登録を要求する。この要求を受けた連携医療計画支援サーバ１０の連携医療計画情報登録部１２ｂ１は（ＳＡ１、Ｙｅｓ）、記憶部１１に予め記憶された連携医療計画情報登録用画面を支援端末３０に送信し（ＳＡ２）、この連携医療計画情報登録用画面が支援端末３０の図示しないモニタに表示される。
【００５５】
図１５は、連携医療計画情報登録用画面の表示例である。この連携医療計画情報登録用画面は、登録したい連携医療計画の連携医療計画種類を選択する選択欄７０と、登録したい連携医療計画において連携させる医療計画を選択する選択欄７１、７２と、登録を指示する登録ボタン７３が設けられている。選択欄７０は、例えば、連携医療計画種類情報ＤＢ１１ｆに格納されている連携医療計画種類情報に含まれる連携医療計画種類ＩＤと連携医療計画種類名とをドロップダウンリスト形式で表示させることができるように構成されており、このように表示させた連携医療計画種類ＩＤと連携医療計画種類名の中から、登録したい連携医療計画の連携医療計画種類に合致するものを医療従事者がクリック等にて選択する。また、選択欄７１、７２は、例えば、患者情報ＤＢ１１ａに格納されている患者情報に含まれている患者ＩＤと患者氏名とをドロップダウンリスト形式で表示させることができるように構成されており、このように表示させた患者ＩＤと患者氏名の中から、登録したい連携医療計画の連携医療計画種類に合致するものを医療従事者がクリック等にて選択する。ここでは、連携医療計画において連携させる医療計画の選択を、これら医療計画の対象となっている患者を選択することで行うこととしており、選択欄７１で第１患者を選択し、選択欄７２で第２患者を選択する。
【００５６】
これら各選択欄７０〜７２における選択を行った後、医療従事者がクリック等にて登録ボタン７３を押下すると、連携医療計画情報登録部１２ｂ１は、選択欄７０〜７２で選択された情報に基づいて連携医療計画情報の新規なレコードを生成し、当該生成したレコードを連携医療計画情報ＤＢ１１ｅに登録する（ＳＡ３）。例えば、連携医療計画情報登録部１２ｂ１は、連携医療計画ＩＤを所定方法（例えば連番）で生成し、当該生成した連携医療計画ＩＤと、図１５の選択欄７０で選択された連携医療計画種類ＩＤと、図１５の選択欄７１で選択された第１患者の患者ＩＤと、図１５の選択欄７２で選択された第２患者の患者ＩＤとを、相互に関連付けて登録する。これにて連携医療計画情報登録処理が終了する。
【００５７】
（処理−連携医療計画情報出力処理）
次に、連携医療計画情報出力処理について説明する。図１６は、連携医療計画情報出力処理のフローチャートである。医療従事者は、連携医療計画情報を出力したい場合には、支援端末３０を介して連携医療計画支援サーバ１０にアクセスして所定の方法で連携医療計画情報出力を要求する。この要求を受けた連携医療計画支援サーバ１０の連携医療計画情報出力部１２ｂ２は（ＳＢ１、Ｙｅｓ）、その時点で連携医療計画情報ＤＢ１１ｅに格納されている連携医療計画情報を対象に、連携性判定条件判定処理と、特定状態判定処理を行い、これら各処理の結果等を含んだ情報を表示するための連携医療計画情報出力用画面を支援端末３０に送信し（ＳＢ８）、この連携医療計画情報出力用画面が支援端末３０の図示しないモニタに表示される。
【００５８】
（処理−連携医療計画情報出力処理−連携性判定条件判定処理）
まず、連携性判定条件判定処理について説明する。連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから連携医療計画情報を取得し、当該取得した連携医療計画情報に含まれる連携医療計画種類ＩＤに対応する連携性判定条件を連携性判定条件情報ＤＢ１１ｈから取得する（ＳＢ２）。また、連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる第１患者ＩＤと第２患者ＩＤに基づき、医療計画情報ＤＢ１１ｄの医療計画情報を参照し、第１患者ＩＤ又は第２患者ＩＤと同一の患者ＩＤに関連付けられた各患者の医療計画における各患者状態（測定結果情報を含む）を取得する（ＳＢ３）。そして、連携性判定条件情報ＤＢ１１ｈから取得した連携性判定条に、医療計画情報ＤＢ１１ｄから取得した各患者状態（測定結果情報を含む）が合致するか否かを判定することにより、連携医療計画情報ＤＢ１１ｅの連携医療計画情報にて特定される連携医療計画を行う上で、医療計画情報ＤＢ１１ｄの医療計画情報にて特定される医療計画を連携させることの可否（または適否）を判定する（ＳＢ４）。
【００５９】
なお、医療計画における各患者状態は、各患者について最新のものを取得する。例えば、各患者の医療計画において、測定結果情報を含んでいる患者状態に関連付けられたユニットＩＤを持つユニットを特定し、当該特定したユニットの中で、最も実施順序が遅くユニットの患者状態を最新のものと特定することができる。実施順序は、ユニットＩＤとユニット移行ロジックを参照することで特定することができる。あるいは、最新の測定結果情報を含む患者状態を、各患者ＩＤに関連付けて格納しておくＤＢを設け、このＤＢを参照して最新の測定結果情報を取得してもよい。あるいは、ユニットの実施履歴を格納するＤＢを設け、このＤＢを参照することで、現在のユニットを特定するようにしてもよい。このように最新の患者状態を取得する点は、後述する特定状態判定処理において同じである。
【００６０】
例えば、連携医療計画情報出力部１２ｂ２は、図１０の連携医療計画情報における連携医療計画ＩＤ＝ＲＩＤ０００１で識別される連携医療計画に関し、図１３の連携性判定条件情報から、連携医療計画種類ＩＤ＝ＲＫＩＤ０００１に対応する連携性判定条件として「第１患者と第２患者の相互間：血液型が適合、かつ、組織適合抗原が適合」を取得し、図９の医療計画情報から、患者ＩＤ＝ＰＩＤ０００１である第１患者（ドナーとなる患者）の最新の患者状態として、血液型＝Ａ型、組織適合抗原＝ＨＬＡ−Ａを取得すると共に、患者ＩＤ＝ＰＩＤ００７８である第２患者（レシーピエントとなる患者）の最新の患者状態として、血液型＝Ｂ型、組織適合抗原＝ＨＬＡ−Ａを取得する（患者ＩＤ＝ＰＩＤ００７８に対応する医療計画情報の例は図９において図示せず）。この場合、連携医療計画情報出力部１２ｂ２は、第１患者の患者状態と第２患者の患者状態は、連携性判定条件情報の患者状態に合致しないため（この例では血液型が適合しないため）、連携不可（又は連携不適）と判定する。これにて連携性判定条件判定処理が終了する。
【００６１】
（処理−連携医療計画情報出力処理−特定状態判定処理）
次に、特定状態判定処理について説明する。連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから連携医療計画情報を取得し、当該取得した連携医療計画情報に含まれる連携医療計画種類ＩＤに対応する患者状態を特定状態情報ＤＢ１１ｇから取得する（ＳＢ５）。また、連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる第１患者ＩＤと第２患者ＩＤに基づき、医療計画情報ＤＢ１１ｄの医療計画情報を参照し、第１患者ＩＤ又は第２患者ＩＤと同一の患者ＩＤに関連付けられた各患者の医療計画における各患者状態（測定結果情報を含む）を取得する（ＳＢ６）。そして、特定状態情報ＤＢ１１ｇから取得した患者状態に、医療計画情報ＤＢ１１ｄから取得した各患者状態（測定結果情報を含む）が合致するか否かを判定することにより、連携医療計画情報ＤＢ１１ｅの連携医療計画情報にて特定される連携医療計画を行う上での特定の状態が到来したか否かを判定する（ＳＢ７）。
【００６２】
例えば、連携医療計画情報出力部１２ｂ２は、図１０の連携医療計画情報における連携医療計画ＩＤ＝ＲＩＤ０００１で識別される連携医療計画に関し、図１２の特定状態情報から、連携医療計画種類ＩＤ＝ＲＫＩＤ０００１に対応する患者状態として「第１患者と第２患者：血圧１４０未満」を取得し、図９の医療計画情報から、患者ＩＤ＝ＰＩＤ０００１である第１患者（ドナーとなる患者）の最新の患者状態として、血圧＝１２８を取得すると共に、患者ＩＤ＝ＰＩＤ００７８である第２患者（レシーピエントとなる患者）の患者状態として、血圧＝１３０を取得する（患者ＩＤ＝ＰＩＤ００７８に対応する医療計画情報の例は図９において図示せず）。この場合、連携医療計画情報出力部１２ｂ２は、第１患者の患者状態と第２患者の患者状態は、特定状態情報の患者状態に合致するため、特定状態が到来したものと判定する。これにて特定状態判定処理が終了する。
【００６３】
（処理−連携医療計画情報出力処理）
その後、連携医療計画情報出力部１２ｂ２は、上述のように、その時点で連携医療計画情報ＤＢ１１ｅに格納されている連携医療計画情報の少なくとも一部と、当該連携医療計画に対応する複数の医療計画に関する医療計画情報の少なくとも一部と、連携性判定条件判定処理の処理結果と、特定状態判定処理の処理結果と、を含んだ情報を併せて表示するための連携医療計画情報出力用画面を支援端末３０に送信し（ＳＢ８）、この連携医療計画情報出力用画面が支援端末３０の図示しないモニタに表示される。
【００６４】
図１７は、連携医療計画情報出力用画面の表示例である。この連携医療計画情報出力用画面は、連携医療計画を表示するための表示領域８０と、連携医療計画において連携される医療計画を表示するための領域であって、第１患者（例えばドナー）の医療計画を表示する表示領域８１と、第２患者（例えばレシーピエント）の医療計画を表示する表示領域８２とを含んで構成されている。
【００６５】
表示領域８０には、各連携医療計画に対応する１又は複数のレコードが表示されており、各レコードは、連携医療計画ＩＤと連携医療計画種類名を含んで構成されている。連携医療計画種類名は、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる連携医療計画種類ＩＤに基づいて連携医療計画種類情報ＤＢ１１ｆを参照することで取得される。
【００６６】
表示領域８１、８２には、各医療計画に対応する１又は複数のレコードが表示されており、各レコードは、患者ＩＤと、患者氏名と、連携性判定条件判定結果（図１７では条件判定）と、特定状態判定結果（図１７では状態判定）を含んで構成されている。患者ＩＤは、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる第１患者ＩＤ又は第２患者ＩＤである。患者氏名は、連携医療計画情報に含まれる第１患者ＩＤ又は第２患者ＩＤに基づいて患者情報ＤＢ１１ａを参照することで取得される。連携性判定条件判定結果は、上述の連携性判定条件判定処理の処理結果であり、例えば、「連携可」又は「連携不可」のいずれかが表示される。特定状態判定結果は、上述の特定状態判定処理の処理結果であり、例えば、「到来」又は「未到来」のいずれかが表示される。
【００６７】
ここで、表示領域８１、８２に表示される情報は、表示領域８０に表示された情報やその選択結果に基づいて切り替えられる。すなわち、表示領域８０に複数のレコードが表示されている場合（連携医療計画情報ＤＢ１１ｅに複数のレコードの連携医療計画情報が格納されている場合）には、当該表示されている複数のレコードの中から、特定の一つのレコードを、医療従事者が支援端末３０を介してクリック等にて選択することで、出力対象とする連携実施計画が特定され、当該特定された連携医療計画に連携する第１患者と第２患者の情報が表示領域８１、８２に表示される。したがって、表示領域８０に表示されている複数のレコードの選択を切り替える度に、表示領域８１、８２の表示内容が切り替わる。あるいは、表示領域８０に一つのレコードのみが表示されている場合（連携医療計画情報ＤＢ１１ｅに一つのレコードの連携医療計画情報のみが格納されている場合）には、当該一つのレコードに対応する連携医療計画に連携する第１患者と第２患者の情報が表示領域８１、８２に表示される。
【００６８】
例えば、図１７の例では、表示領域８０に表示されている２つのレコードのうち、上側のレコードが選択されている例を示している。そして、表示領域８１には、２人の第１患者（ドナー）の医療計画に対応するレコードが表示されており、表示領域８２には、１人の第２患者（レシーピエント）の医療計画に対応するレコードが表示されている。２人の第１患者のレコードの中で、上側のレコードには連携性判定条件判定処理の処理結果として「連携不可」が表示されているので、第２患者（レシーピエント）の医療計画と連携できない（レシーピエントへの臓器の提供が出来ない）ことが判り、下側のレコードには連携性判定条件判定処理の処理結果として「連携可」が表示されているので、第２患者（レシーピエント）の医療計画と連携できる（レシーピエントへの臓器の提供が出来る）ことが判る。なお、ここでは、２人の第１患者（ドナー）に対して一人の第２患者（レシーピエント）が関連付けられている例を示しており、この場合、第２患者（レシーピエント）のレコードにおける連携性判定条件判定処理の処理結果の表示においては、いずれの第１患者（ドナー）に対する処理結果であるのかが特定できるように、第１患者の患者ＩＤが併せて表示されている。例えば、図１７の例では、患者ＩＤ＝ＰＩＤ００１５の第２患者に対して、患者ＩＤ＝ＰＩＤ０００１の第１患者は連携できないが、患者ＩＤ＝ＰＩＤ０２３５の第１患者は連携できることを示している。
【００６９】
また、２人の第１患者のレコードの中で、上側のレコードには特定状態判定結果の処理結果として「未到来」が表示されているので、第１患者の患者状態は未だ特定状態になっておらず、仮に連携性判定条件判定処理の処理結果が「連携可」であった場合でも、現時点では第２患者（レシーピエント）の医療計画と連携できない（レシーピエントへの臓器の提供が出来ない）ことが判る。一方、２人の第１患者のレコードの中で、下側のレコードには特定状態判定結果の処理結果として「到来」が表示されているので、連携性判定条件判定処理の処理結果が「連携可」である場合には、現時点で第２患者（レシーピエント）の医療計画と連携できる（レシーピエントへの臓器の提供が出来る）ことが判る。
【００７０】
これらのことから、図１７の例では、現時点において、患者ＩＤ＝ＰＩＤ００１５の第２患者であるレシーピエントに対して、患者ＩＤ＝ＰＩＤ０２３５の第１患者であるドナーから臓器の提供ができる状態であることが把握できる。
【００７１】
（実施の形態の効果）
このように本実施の形態によれば、連携医療計画情報と複数の医療計画情報を併せて出力するので、この出力を参照することで、連携医療計画において連携される可能性がある複数の医療計画の内容や状況を把握することが可能となり、これら複数の医療計画を一つのプロジェクト（エピソード）として管理することが可能になるので、連携医療計画の管理や実行を容易かつ的確に行うことが可能となる。従って、医療行為の質を高めることが可能となる。
【００７２】
また、患者の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、複数の医療計画が特定の状態になった場合に連携医療計画が進行する場合等において、連携医療計画の進行の可否や適否を判断することが容易になり、連携医療計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００７３】
また、連携医療計画の種類に応じて特定された特定状態情報に基づいて、実施対象の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、連携医療計画の種類に応じた適切な特定状態情報に基づいて連携医療計画の進行の可否や適否を判断することが容易になり、連携医療計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００７４】
また、連携性判定条件が満たされるか否かが出力手段を介して報知されるので、複数の医療計画が所定条件下でのみ連携可能である場合等において、複数の医療計画を連携させることの可否や適否を判断することが容易になり、連携医療計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００７５】
〔III〕各実施の形態に対する変形例
以上、本発明に係る各実施の形態について説明したが、本発明の具体的な構成及び手段は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良できる。以下、このような変形例について説明する。
【００７６】
（解決しようとする課題や発明の効果について）
まず、発明が解決しようとする課題や発明の効果は、前記した内容に限定されるものではなく、本発明によって、前記に記載されていない課題を解決したり、前記に記載されていない効果を奏することもでき、また、記載されている課題の一部のみを解決したり、記載されている効果の一部のみを奏することがある。
【００７７】
（構成及び制御について）
また、上記実施の形態で自動的に行われるものとして説明した制御の全部または任意の一部を手動で行っても良く、逆に、手動で行われるものとして説明した制御の全部または任意の一部を公知技術または上述した思想に基づいて自動化しても良い。また、上記実施の形態において示した各構成要素の各機能ブロックの一部又は全部を、ハードワイヤードロジックにて構成しても良い。
【００７８】
（分散や統合について）
また、上述した各電気的構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成できる。例えば、連携医療計画支援サーバ１０と医療計画作成支援サーバ５０を相互に統合したり、連携医療計画支援サーバ１０の機能を複数のサーバやＤＢに分散したり、連携医療計画支援サーバ１０や医療計画作成支援サーバ５０の一部の機能を支援端末３０に持たせてもよい。
【００７９】
（情報の格納や取得について）
また、連携医療計画支援サーバ１０の各ＤＢの具体的構成も任意に変更可能であり、上述の各ＤＢを相互に統合したり、各ＤＢをさらに分割して構成してもよい。さらに、連携医療計画支援に必要な情報の全部又は一部を、電子カルテサーバ２０から取得してもよい。すなわち、連携医療計画支援サーバ１０で使用する第１患者ＩＤや第２患者ＩＤと、既存の電子カルテサーバ２０で患者を識別するための使用している患者ＩＤとを、相互に対応させた同一のＩＤとし、あるいは相互に変換可能な変換テーブルを介在させ、連携医療計画情報に含まれる第１患者ＩＤや第２患者ＩＤに基づいて、これら第１患者ＩＤや第２患者ＩＤに対応する患者の電子カルテ情報を電子カルテサーバ２０から取得して連携医療計画情報出力用画面に出力するようにしてもよい。
【００８０】
（連携医療計画と医療計画の関係について）
上記実施の形態では、連携医療計画が生体肝移植である場合を主に例示しているので、連携医療計画に連携し得る医療計画として、第１患者（ドナー）の医療計画と、第２患者（レシーピエント）の医療計画との、合計２つのカテゴリの医療計画を連携させるものとしている。ただし、連携医療計画に連携し得る医療計画のカテゴリ数は、１つ以上の任意の数であればよい。例えば、別々のドナーから提供された心臓と肝臓を一つのレシーピエントに移植する場合には、第１患者（心臓のドナー）の医療計画と、第２患者（肝臓のドナー）の医療計画と、第３患者（レシーピエント）の医療計画との、合計３つのカテゴリの医療計画を連携させることになる。また、各カテゴリにおける医療計画の数も任意であり、例えば、第２患者（レシーピエント）の医療計画として、複数の第２患者の医療計画を第１患者（ドナー）の医療計画に連携させてもよい。これらの各場合においても、上記説明した実施の形態を、当業者に自明な知識で拡張することで、実現可能である。
【００８１】
（実施計画識別情報について）
上記実施の形態では、連携医療計画情報に第１患者ＩＤと第２患者ＩＤを含めており、これら第１患者ＩＤと第２患者ＩＤを用いて連携医療計画に連携される複数の医療計画を識別しているため、これら第１患者ＩＤと第２患者ＩＤが特許請求の範囲における実施計画識別情報として機能している。この他にも、医療計画を一意に識別する医療計画ＩＤを医療計画情報の各レコードに関連付けて格納しておくと共に、連携医療計画情報の第１患者ＩＤと第２患者ＩＤに代えて医療計画ＩＤを含める等、任意の識別情報を、実施計画識別情報とすることが可能である。
【００８２】
（特定状態情報について）
上記実施の形態では、特定状態情報として特定の患者状態を使用しており、具体的には、患者状態に含まれる血圧の数値が所定の血圧の数値範囲に合致する場合に、特定の状態が到来したものと判定しているが、数値に基づく判定以外にも、言葉による判定を行ってもよい。例えば、特定状態情報として、特定の患者状態になったことを示す特定の用語（予約語）（例えば死亡、心臓停止、脳死等）を登録しておき、患者状態に当該用語が含まれることとなった場合には、特定の患者状態になったものと判定してもよい。
【００８３】
（情報の出力形態について）
上記実施の形態では、連携医療計画情報等を連携医療計画情報出力用画面にて表示しているが、この他の任意の形態で当該情報等を出力することが可能であり、例えば、支援端末３０に接続された公知の印刷装置に印刷したり、支援端末３０が備える公知のスピーカから特定状態が到来した場合に所定の報知音を出力してもよい。また、連携医療計画情報出力用画面にて表示する場合であっても、この画面構成や各表示領域に表示する情報の内容や配置は変更可能であり、例えば、表示領域には第１患者の血液型や組織適合抗原を表示したり、表示領域には第２患者の最新の患者状態を併せて表示したり、特定の状態になった患者に対応するレコードを点滅表示させたり、特定の状態になった患者に対応するレコードを色や文字サイズを変えることで強調表示させてもよい。
【００８４】
（処理タイミングについて）
上記実施の形態では、医療従事者が連携医療計画情報出力を要求した場合に、連携性判定条件判定処理及び特定状態判定処理が実行されるものとして説明したが、これら各処理の実行タイミングは任意に変更することができる。例えば、特定状態判定処理については、所定間隔が到来する毎（例えば１時間毎）に繰り返し実行したり、医療計画情報ＤＢ１１ｄにおける患者状態が更新される毎に繰り返し実行し、特定状態が到来した場合には、連携医療計画情報出力用画面が支援端末３０に自動的に表示されるようにしてもよい。
【符号の説明】
【００８５】
１ 連携医療計画支援システム
１０ 連携医療計画支援サーバ
１１ 記憶部
１１ａ 患者情報ＤＢ
１１ｂ 医師情報ＤＢ
１１ｃ 疾患情報ＤＢ
１１ｄ 医療計画情報ＤＢ
１１ｅ 連携医療計画情報ＤＢ
１１ｆ 連携医療計画種類情報ＤＢ
１１ｇ 特定状態情報ＤＢ
１１ｈ 連携性判定条件情報ＤＢ
１２ 制御部
１２ａ 医療計画管理部
１２ｂ 連携医療計画管理部
１２ｂ１ 連携医療計画情報登録部
１２ｂ２ 連携医療計画情報出力部
１３ ネットワークＩＦ
１４ バス
２０ 電子カルテサーバ
３０ 支援端末
４０、６０ ネットワーク
５０ 医療計画作成支援サーバ
７０〜７２ 選択欄
７３ 登録ボタン
８０〜８２ 表示領域
【技術分野】
【０００１】
本発明は、実施対象に対して複数の実施行為を実施するための実施計画を、さらに複数連携させて実施される連携実施計画の管理や実行を支援する、連携実施計画支援システム及び連携実施計画支援プログラムに関する。
【背景技術】
【０００２】
従来、医療関連行為を二次元構造で示したクリティカルパスが知られている。このクリティカルパスは、それまで医師の個人的な暗黙知として蓄積された膨大な医療知識を、標準化及び可視化を通じて形式知として提示することで、医療の質と効率を系統的に保証及び向上させることができる点で有用である。しかしながら、患者の状態によっては、クリティカルパスを適用できなかったり、予め想定された標準的な経過から乖離してしまいクリティカルパスを逸脱する可能性があるという問題が指摘されていた。
【０００３】
この点に鑑みて本願発明者等は、医療プロセス質管理システム及び医療プロセス質管理方法を提案した（特許文献１参照）。このシステムは、患者に対して実施する複数の医療プロセス及び各医療プロセスの実施順序等を記憶する記憶部と、次に実施する医療プロセスを読み出すプロセス管理部等を備えて構成されている。このシステムにおいては、「プロセスチャート（臨床プロセスチャート）」と「ユニットシート」を用いて、医療行為の内容を臨床経路に従って医師等に順次提示する。「ユニットシート」とは、患者の目標状態毎に形成された医療行為単位である「ユニット（プロセス）」を視覚化したものである。「プロセスチャート」は、複数のユニットを連結して構成される臨床経路の俯瞰図である。
【０００４】
このようにプロセスチャートとユニットシートという２種類のツールによって、医療行為の内容や実施順序を標準化された内容で各医師に提示することで、各医師が個別的に独自判断で医療行為の内容や実施順序を決定する場合に比べて、医療行為の標準化を図ることができ、延いては医療プロセスの質を維持及び向上させることができる。また、このシステムによれば、患者の個別性に柔軟に対応できるので、従来のクリティカルパスの問題点を解消することが可能になる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２００６／０５７３３６号パンフレット
【特許文献２】特開２００７−１２８３５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、このような従来の医療プロセス質管理システムや医療プロセス質管理方法は、主として一人の患者に対する医療計画を対象としたものであるため、複数の患者のそれぞれに対する医療計画が相互に連携しつつ進行するような場合に、この進行の状態や連携の可否等を統合的に管理することには必ずしも適しているとは言えなかった。
【０００７】
例えば、生体肝移植を行う場合においては、肝臓を提供する者（以下、ドナー）と、肝臓の提供を受ける者（以下、レシーピエント）とが存在する。この場合、従来の医療プロセス質管理システムや医療プロセス質管理方法では、ドナーに対する医療計画と、レシーピエントに対する医療計画とを、相互に独立して管理等することは可能であるが、ドナーの状態に応じてレシーピエントに対する医療行為の内容や順序を決定する必要がある場合等、ドナー対する医療計画とレシーピエントに対する医療計画を相互に連携しつつ進行させたい場合には、この進行の状態や連携の可否等を管理することが困難であった。
【０００８】
本発明は、上記に鑑みてなされたものであって、実施対象に対して複数の実施行為を実施するための実施計画を、さらに複数連携させて実施される連携実施計画の管理や実行を支援することができる、連携実施計画支援システム及び連携実施計画支援プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するために、請求項１に係る連携実施計画支援システムは、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段とを備える。
【００１０】
請求項２に係る連携実施計画支援システムは、請求項１に係る連携実施計画支援システムにおいて、前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、前記制御手段は、前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う。
【００１１】
請求項３に係る連携実施計画支援システムは、請求項２に係る連携実施計画支援システムにおいて、前記連携実施計画情報格納手段に格納される前記連携実施計画情報は、前記連携実施計画の種類を特定する連携実施計画種類情報を含み、前記特定状態情報格納手段は、前記特定状態情報を前記連携実施計画種類情報に関連付けて格納し、前記制御手段は、前記連携実施計画に対応する前記連携実施計画種類情報を前記連携実施計画情報格納手段から取得し、当該取得した連携実施計画種類情報に対応する前記特定状態情報を前記特定状態情報格納手段から取得し、前記実施計画情報格納手段から取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定する。
【００１２】
請求項４に係る連携実施計画支援システムは、請求項１から３のいずれか一項に係る連携実施計画支援システムにおいて、前記実施計画情報格納手段に格納される前記実施行為内容情報は、複数の前記実施計画の連携性を判定するために使用する連携性判定情報を含み、前記連携実施計画において連携させる複数の前記実施計画の連携性を判定するための連携性判定条件を特定する連携性判定条件情報を格納する連携性判定条件情報格納手段を備え、前記制御手段は、前記特定された連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記連携性判定情報を前記実施計画情報格納手段から取得すると共に、前記特定された連携実施計画に対応する前記連携性判定条件情報を前記連携性判定条件情報納手段から取得し、当該取得した連携性判定情報に基づいて、当該取得した連携性判定条件情報にて特定される連携性判定条件が満たされるか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う。
【００１３】
請求項５に係る連携実施計画支援システムは、請求項１から４のいずれか一項に係る連携実施計画支援システムにおいて、前記実施対象は患者であり、前記実施行為は医療行為であり、前記実施計画は医療計画であり、前記連携実施計画は連携医療計画である。
【００１４】
請求項６に係る連携実施計画支援プログラムは、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、を備えるコンピュータに実行させるプログラムであって、前記コンピュータを、前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段として機能させる。
【００１５】
請求項７に係る連携実施計画支援プログラムは、請求項６に係る連携実施計画支援プログラムは、前記コンピュータの前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、前記コンピュータは、前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、前記コンピュータを、前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う前記制御手段として機能させる。
【００１６】
請求項８に係る連携実施計画支援プログラムは、請求項６又は７に係る連携実施計画支援プログラムは、前記実施対象は患者であり、前記実施行為は医療行為であり、前記実施計画は医療計画であり、前記連携実施計画は連携医療計画である。
【発明の効果】
【００１７】
請求項１に係る連携実施計画支援システム又は請求項６に係る連携実施計画支援プログラムによれば、連携実施計画情報と複数の実施計画情報を併せて出力するので、この出力を参照することで、連携実施計画において連携される可能性がある複数の実施計画の内容や状況を把握することが可能となり、これら複数の実施計画を一つのプロジェクト（エピソード）として管理することが可能になるので、連携実施計画の管理や実行を容易かつ的確に行うことが可能となる。従って、実施行為の質を高めることが可能となる。
【００１８】
請求項２に係る連携実施計画支援システム又は請求項７に係る連携実施計画支援プログラムによれば、実施対象の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、複数の実施計画が特定の状態になった場合に連携実施計画が進行する場合等において、連携実施計画の進行の可否や適否を判断することが容易になり、連携実施計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００１９】
請求項３に係る連携実施計画支援システムによれば、連携実施計画の種類に応じて特定された特定状態情報に基づいて、実施対象の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、連携実施計画の種類に応じた適切な特定状態情報に基づいて連携実施計画の進行の可否や適否を判断することが容易になり、連携実施計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００２０】
請求項４に係る連携実施計画支援システムによれば、連携性判定条件が満たされるか否かが出力手段を介して報知されるので、複数の実施計画が所定条件下でのみ連携可能である場合等において、複数の実施計画を連携させることの可否や適否を判断することが容易になり、連携実施計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００２１】
請求項５に係る連携実施計画支援システム又は請求項８に係る連携実施計画支援プログラムによれば、連携医療計画において連携される可能性がある複数の医療計画の内容や状況を把握することが可能となり、これら複数の医療計画を一つのプロジェクト（エピソード）として管理することが可能になるので、連携医療計画の管理や実行を容易かつ的確に行うことが可能となる。従って、医療行為の質を高めることが可能となる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施の形態に係る連携医療計画支援システムの全体構成を概念的に示す説明図である。
【図２】プロセスチャート及びユニットシートの基本構成モデルを示す図である。
【図３】ユニットシートの表示画面例を示す図である。
【図４】生体肝移植のレシーピエントのプロセスチャート（一部）の例を示す図である。
【図５】生体肝移植のドナーのプロセスチャートの例を示す図である。
【図６】患者情報の構成例を示す図である。
【図７】医師情報の構成例を示す図である。
【図８】疾患情報の構成例を示す図である。
【図９】医療計画情報の構成例を示す図である。
【図１０】連携医療計画情報の構成例を示す図である。
【図１１】連携医療計画種類情報の構成例を示す図である。
【図１２】特定状態情報の構成例を示す図である。
【図１３】連携性判定条件情報の構成例を示す図である。
【図１４】連携医療計画情報登録処理のフローチャートである。
【図１５】連携医療計画情報登録用画面の表示例を示す図である。
【図１６】連携医療計画情報出力処理のフローチャートである。
【図１７】連携医療計画情報出力用画面の表示例を示す図である。
【発明を実施するための形態】
【００２３】
以下に添付図面を参照して、この発明に係る連携実施計画支援システム及び連携実施計画支援プログラムを実施するための一形態について詳細に説明する。まず、〔I〕本実施の形態の基本概念を説明した後、〔II〕本実施の形態の具体的内容について説明し、〔III〕最後に本実施の形態に対する変形例について説明する。ただし、本実施の形態によって本発明が限定されるものではない。
【００２４】
〔I〕本実施の形態の基本概念
まず、本実施の形態の基本概念について説明する。本実施の形態に係る連携実施計画支援システム及び連携実施計画支援プログラムは、複数の実施計画を連携させて実施される可能性がある連携実施計画の管理や実行を支援するものである。ここで、実施計画とは、実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される。
【００２５】
連携実施計画支援システム及び連携実施計画支援プログラムは、広範な分野に適用可能であり、概念的には、当該分野における形式知（具体的には、実施対象に対して実施者が実施する複数の実施行為の内容と、これら複数の実施行為の相互間の実施順序）を構造化することで可視化が可能な全ての分野に適用可能である。この適用分野の例としては、「医療分野」、「防災分野」、「教育分野」を挙げることができ、この適用分野に応じて、「実施対象」、「実施者」、「実施行為」、「実施計画」、「連携実施計画」の具体的内容は異なり得る。例えば、医療分野では、実施対象＝患者、実施者＝医師（又は病院の如き医療機関）、実施行為＝医療行為、実施計画＝医療計画、連携実施計画＝複数の患者や疾患に対する医療計画を連携して行われ得る連携医療計画である。同様に、防災分野では、実施対象＝災害やテロ行為の被災者や被災物、実施者＝救援者、実施行為＝救援行為、実施計画＝救援計画、連携実施計画＝複数の地域や被災者に対する救援計画を連携して行われ得る連携救援計画が該当し、教育分野では、実施対象＝生徒、実施者＝教師、実施行為＝教育行為、実施計画＝教育計画、連携実施計画＝複数の地域や生徒に対する教育計画を連携して行われ得る連携教育計画が該当する。
【００２６】
以下では、連携実施計画支援システム及び連携実施計画支援プログラムを医療分野に適用した場合について説明するものとし、実施対象＝患者、実施者＝医師や看護師等の医療従事者、実施行為＝医療行為、実施計画＝医療計画、連携実施計画＝連携医療計画と読み替えて説明する。また、連携実施計画支援システムは連携医療計画支援システム（以下「本システム」）、連携実施計画支援プログラムは連携医療計画支援プログラム（以下「本プログラム」）と読み替えて説明する。なお、本システム及び本プログラムを他の分野に適用する場合には、上述のように「実施対象」、「実施者」、「実施行為」、「実施計画」、「連携実施計画」の内容を当該他の分野に応じた内容に読み替えればよい。
【００２７】
なお、連携医療計画は、複数の医療計画を連携して行われ得る計画であるが、「連携して行われ得る」とは、一つの連携実施計画において、複数の実施計画が連携する候補となるが、これら候補となる実施計画が必ず連携する場合の他、候補となる実施計画が条件によっては連携しない場合があることを意味している。例えば、生体肝移植において、一つのレシーピエントと複数のドナーが存在する場合、複数のドナーの中のいずれか一人のみが、最終的なドナーとなって肝臓を提供することになるが、このように、レシーピエントの医療計画に対して、複数のドナーの医療計画の一部しか最終的に連携しない場合であっても、レシーピエントの医療計画と、複数のドナーの医療計画が、相互に連携し得るものとして説明される。
【００２８】
図１は、連携医療計画支援システムの全体構成を概念的に示す説明図である。この図１に示すように、複数の病院の各々には、連携医療計画支援システム１が設置されている。この連携医療計画支援システム１は、連携医療計画支援サーバ１０、電子カルテサーバ２０、支援端末３０を、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）の如きネットワーク４０を介して相互に通信可能に接続して構成されている。また、連携医療計画支援システム１には、医療計画作成支援サーバ５０がインターネットの如きネットワーク６０を介して通信可能に接続されている。
【００２９】
本実施形態では、上述の特許文献１又は特許文献２に全部又は一部が開示された「患者状態適応型パスシステム（ＰＣＡＰＳ：Ｐａｔｉｅｎｔ Ｃｏｎｄｉｔｉｏｎ Ａｄａｐｔｉｖｅ Ｐａｔｈ Ｓｙｓｔｅｍ）」を利用する。この患者状態適応型パスシステムは、患者の初期状態から最終目標状態に至る臨床経路を示す俯瞰的なモデルであり、この臨床経路を、「患者状態」を基軸とする複数の「目標状態」を相互にリンクして視覚化したものであって、具体的には「プロセスチャート（臨床プロセスチャート）」と「ユニットシート」の２つのツールを用いて構成される。
【００３０】
図２には、これらプロセスチャート及びユニットシートの基本構成モデルを示す。プロセスチャートとは、患者の目標状態毎に形成された医療行為単位（医療の質を管理するために適切な大きさに設定された単位）である「ユニット（プロセス）」を連結することで構成される臨床経路の俯瞰図であり、疾患毎に構成され、当該疾患を有する患者の初期状態から最終目標状態に至る間に想定されるすべての臨床状態を包含する。各ユニットは「実行エレメント」と「判断エレメント」とから構成されている。実行エレメントは、患者状態を当該ユニットの目標状態に達するように組み込まれた医療業務を実行していく行為を示し、判断エレメントは、患者状態が当該ユニットの目標状態に達したか否かを判断する行為を示す。そして、各実行エレメントと、当該各実行エレメントの直後の判断エレメントとを、視覚的に表示する手段として「ユニットシート」が構成される。
【００３１】
このユニットシートの表示画面例を図３に示す。具体的にはユニットシートは、「患者ＩＤ」、「ユニットＩＤ」、「医療行為」、「患者状態」、「目標状態」、「ユニット移行ロジック」、「条件付き指示」、「離脱条件」を含む。患者ＩＤは、当該ユニットシートが適用されている患者を一意に特定するための識別情報である。ユニットＩＤは、当該ユニットシートに対応するユニットを一意に特定するための識別情報である。医療行為は、当該ユニットシートに対応する実行エレメントにおいて実行すべき医療行為の項目や内容を記述した情報であり、例えば、医行為、ケア行為、及び調整行為を含む。患者状態は、当該ユニットシートに対応するユニットにおいて注目すべき患者状態の内容を記述した情報である。ユニット移行ロジックは、当該ユニットシートに対応するユニットから次順のユニットに移行するときの条件及び移行先のユニットシートに対応するユニットＩＤを記述した情報である。条件付き指示は、当該ユニットにおける医療行為中に発生した患者状態に早急に対応するための指示内容を含んで構成されている。離脱条件は、目標状態からの危険な乖離の判断基準を示す遷移状態になった場合には、当該ユニットシートを離脱すべき場合があるため、この離脱を行うための条件を含んで構成されている。
【００３２】
このように構成される「プロセスチャート」及び「ユニットシート」は、図１の医療計画作成支援サーバ５０によるＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）サービスを用いて、各病院の医師等が作成することができる。すなわち、医療計画作成支援サーバ５０には、各病院に共通の標準的な「プロセスチャート」及び「ユニットシート」を特定するための情報が格納されている。そして、各病院の医師等は、医療計画作成支援サーバ５０に支援端末３０を介してアクセスし、標準的な「プロセスチャート」及び「ユニットシート」を呼び出し、この標準的な「プロセスチャート」及び「ユニットシート」を自己の病院に合致した個別的な「プロセスチャート」及び「ユニットシート」に所定方法でカスタマイズして連携医療計画支援サーバ１０に格納することで、プロセスチャート及びユニットシートの作成を行うことができる。
【００３３】
このように作成された「プロセスチャート」及び「ユニットシート」の実施は、連携医療計画支援サーバ１０の後述する医療計画管理部１２ａによって制御される。すなわち、この医療計画管理部１２ａは、プロセスチャートにおける最初のユニットに対応するユニットシートの内容を支援端末３０を介して医師に対して表示出力等にて提示する。そして、医師が、当該提示されたユニットシートに含まれる医療行為を行い、その後の患者状態を支援端末３０に入力すると、この患者状態が支援端末３０を介して連携医療計画支援サーバ１０にて受け付けられる。次いで、連携医療計画支援サーバ１０は、患者状態が当該ユニットの目標状態に達したか否かを判断する。目標状態に達したと判断した場合には、当該最初のユニットの次順のユニットをプロセスチャートに基づいて特定し、当該次順のユニットに対応するユニットシートの内容を支援端末３０を介して医師に対して提示する。以降同様に、プロセスチャートにて定義された順序に従ったユニットに対応するユニットシートの内容の提示処理と、医師による患者状態の入力を受け付ける処理と、目標状態に達したか否かを判断する判断処理とが繰り返し行われ、プロセスチャートにおける最後のユニットの医療行為が終了することで、一連の処理が終了する。
【００３４】
図４は、生体肝移植のレシーピエントのプロセスチャート（一部）の例、図５は、生体肝移植のドナーのプロセスチャートの例である。これらのプロセスチャートは、複数のユニットの各々を構成する実行エレメント及び判断エレメントと、これら各エレメントを相互に接続する線分とを含んでおり、当該線分によって各エレメントの相互間の実施順序が視覚的に示されている。例えば、図４のプロセスチャートでは、実行エレメント「Ａ−７」の医療行為を実行した後、判断エレメントにおいて患者状態と目標状態とに基づく判断を行い（ただし、判断エレメントの図示は省略する）、この判断結果に応じて、実行エレメント「Ａ−８」又は「Ａ−９」のいずれかに移行する。図４、５における各実行エレメントの枠内には、各実行エレメントに対応するユニットの名称及びユニットＩＤを示す。例えば、図４のプロセスチャートでは、最初の実行エレメントに対応するユニットの名称は「術前評価（絶対的ｃｏｎｔｒａ症例の例外）」であり、ユニットＩＤは「Ａ−１」である。
【００３５】
〔II〕本実施の形態の具体的内容
次に、本実施の形態の具体的内容について説明する。以下では、図１に示した各部の構成について説明し、次いで、連携医療計画支援プログラムの処理内容について説明する。
【００３６】
（構成−連携医療計画支援サーバ）
最初に、図１の連携医療計画支援サーバ１０の構成を説明する。この連携医療計画支援サーバ１０は、連携医療計画を支援する連携医療計画支援装置であり、機能概念的に、記憶部１１、制御部１２、及びネットワークインターフェース（以下、インターフェースは「ＩＦ」）１３を、バス１４にて相互に通信可能に接続して構成されている。
【００３７】
記憶部１１は、各種処理に必要な情報やパラメータを不揮発的に格納する格納手段であり、例えば、ＨＤ（Ｈａｒｄ Ｄｉｓｋ）にて構成される。具体的には、この記憶部１１は、機能概念的に、患者情報データベース（以下、データベースは「ＤＢ」）１１ａ、医師情報ＤＢ１１ｂ、疾患情報ＤＢ１１ｃ、医療計画情報ＤＢ１１ｄ、連携医療計画情報ＤＢ１１ｅ、連携医療計画種類情報ＤＢ１１ｆ、特定状態情報ＤＢ１１ｇ、及び連携性判定条件情報ＤＢ１１ｈを備える。これら各ＤＢ１１ａ〜１１ｈに格納される情報の具体的内容については後述する。
【００３８】
制御部１２は、連携医療計画支援サーバ１０の各部を制御する制御手段であり、機能概念的に、医療計画管理部１２ａ及び連携医療計画管理部１２ｂを備える。医療計画管理部１２ａは、医療計画の実行を管理する医療計画管理手段である。連携医療計画管理部１２ｂは、連携医療計画の実行を管理する連携医療計画管理手段である。さらに、連携医療計画管理部１２ｂは、連携医療計画情報登録部１２ｂ１及び連携医療計画情報出力部１２ｂ２を備える。連携医療計画情報登録部１２ｂ１は、連携医療計画情報を登録するための連携医療計画情報登録処理を行う連携医療計画情報登録手段である。連携医療計画情報出力部１２ｂ２は、連携医療計画情報登録処理で登録された連携医療計画情報を出力するための連携医療計画情報出力処理を行う連携医療計画情報出力手段である。この制御部１２は、具体的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や、このＣＰＵ上で解釈実行される各種のプログラム（ＯＳなどの制御プログラムや、各種の処理手順などを規定したプログラム）、及び、所要プログラムや所要データを格納するためのキャッシュメモリを備えて構成される。このＣＰＵ上で解釈実行される各種のプログラムには本プログラムが含まれ、本プログラムは、例えば、ＣＤ−ＲＯＭやＤＶＤを含む任意の記憶媒体に記憶された後、インストールされて記憶部１１に不揮発的に記憶され、ＣＰＵにて解釈実行されることで制御部１２の実質的機能を構成する。
【００３９】
ネットワークＩＦ１３は、ネットワーク４０、６０を介した通信を行うための通信手段であり、例えばネットワークボードとして構成される。このネットワークＩＦ１３を介して支援端末３０等からの情報入力の受け付けが行われることから、当該ネットワークＩＦ１３は入力手段を構成する。また、このネットワークＩＦ１３を介して各種の情報の出力が行われることから、当該ネットワークＩＦ１３は出力手段を構成する。
【００４０】
（構成−電子カルテサーバ）
次に、電子カルテサーバ２０の構成を説明する。この電子カルテサーバ２０は、患者のカルテに関する電子情報を管理するカルテ情報管理装置である。この電子カルテサーバ２０の具体的構成は任意であり、連携医療計画支援サーバ１０との通信機能を有する限りにおいて、公知の電子カルテサーバと同様に構成できるために、その詳細な説明は省略する。なお、病院に配置されるサーバとしては、この電子カルテサーバ２０以外にも、医事会計サーバの如き公知の任意の情報処理装置を含めることができる。
【００４１】
（構成−支援端末）
各支援端末３０は、医師を含む医療従事者が連携医療計画支援サーバ１０に対して入出力を行うための端末装置であり、特に、連携医療計画支援サーバ１０や医療計画作成支援サーバ５０との通信機能と、患者状態の入力を受け付ける入力機能と、プロセスチャート及びユニットシートの出力を行う出力機能と、後述する連携医療計画管理画面の出力を行う出力手段として機能とを有する。この支援端末３０は、連携医療計画支援サーバ１０との通信機能や各種情報の入出力機能を有する限りにおいて、公知のパーソナルコンピュータと同様に構成できるために、その詳細な説明は省略する。
【００４２】
（構成−医療計画作成支援サーバ）
次に、医療計画作成支援サーバ５０の構成を説明する。この医療計画作成支援サーバ５０は、医療計画の作成を支援する医療計画作成支援装置であり、特に、連携医療計画支援サーバ１０や支援端末３０との通信機能と、標準的なプロセスチャート及びユニットシートを格納する機能と、支援端末３０を通じた要求に応じてプロセスチャート及びユニットシートを提供する機能と、これら「プロセスチャート」及び「ユニットシート」を個別的な「プロセスチャート」及び「ユニットシート」にカスタマイズすることを支援するための機能とが設けられている。ただし、この医療計画作成支援サーバ５０としては、例えば、本願発明者等による特開２００９−２０５６５４に開示されている作成サーバを使用することができる。
【００４３】
（構成−連携医療計画支援サーバのＤＢ）
次に、連携医療計画支援サーバ１０の各ＤＢ１１ａ〜１１ｈに格納される情報の具体的内容について説明する。ただし、以下の構成例では本実施の形態に係る情報のみを格納する例を示し、実際には以下に説明する情報以外の任意の情報を各ＤＢ１１ａ〜１１ｈに格納することができ、あるいは一部の情報については適宜省略することもある。また、各ＤＢ１１ａ〜１１ｈに格納される情報のうち、同一名称の情報については、特記する場合を除いて相互に同一の内容であるものとし、重複説明は行わないものとする。
【００４４】
図１の患者情報ＤＢ１１ａは、医療行為の対象である患者に関する情報（患者情報）を格納する手段である。この患者情報は、図６に例示するように、項目「患者ＩＤ」、項目「患者氏名」、項目「年齢」、項目「性別」、項目「住所」、及び項目「疾患ＩＤ」に対応する情報を相互に関連付けて構成されている。項目「患者ＩＤ」に対応する情報は、各医療計画の対象となる患者を一意に識別するための患者識別情報である。項目「患者氏名」、項目「年齢」、項目「性別」、項目「住所」に対応する情報は、それぞれ、各患者の氏名、年齢、性別、住所である。項目「疾患ＩＤ」に対応する情報は、各患者の各疾患を一意に識別するための疾患識別情報である。
【００４５】
図１の医師情報ＤＢ１１ｂは、各医師に関する情報（医師情報）を格納する医師情報格納手段である。この医師情報は、図７に例示するように、項目「医師ＩＤ」、項目「専門」、及び項目「経験年数」を相互に関連付けて構成されている。項目「医師ＩＤ」に対応する情報は、各医師を一意に識別するための医師識別情報である。項目「専門」に対応する情報は、各医師の専門分野である。項目「経験年数」に対応する情報は、各医師の医師としての経験年数である。
【００４６】
図１の疾患情報ＤＢ１１ｃは、各医療計画による治療の対象になる疾患に関する情報（疾患情報）を格納する疾患情報格納手段である。この疾患情報は、図８に例示するように、項目「疾患ＩＤ」、及び項目「疾患名」を相互に関連付けて構成されている。項目「疾患ＩＤ」に対応する情報は、図６の同一項目に対応する情報と共通である。項目「疾患名」に対応する情報は、各疾患の名称（病名）である。ただし、本実施の形態では、いわゆる病気に該当しない場合であっても、医療計画や連携医療計画の医療行為の対象になる場合があることを想定しており、このような場合における当該対象となる原因（あるいは、理由、位置付け、役割、立場）を示す情報も、疾患として疾患情報ＤＢ１１ｃに登録している。例えば、連携医療計画が生体肝移植である場合において、ドナーが健康であり疾患を持っていない場合であっても、当該生体肝移植のドナーである旨を疾患と同列に疾患情報に登録している。図８の例では、疾患ＩＤ＝ＳＩＤ０００３が、生体肝移植のドナーであることを示している。
【００４７】
図１の医療計画情報ＤＢ１１ｄは、患者に対して実施する複数の医療行為の内容と当該複数の医療行為の実施順序とを含んで構成される医療計画に関する医療計画情報（実施計画情報）であって、医療計画を一意に識別する医療計画識別情報（実施計画識別情報）と、複数の医療行為の内容を特定する医療行為内容情報（実施行為内容情報）と、複数の医療行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された医療計画情報（実施計画情報）、を格納する医療計画情報格納手段（実施計画情報格納手段）である。この医療計画情報は、図９に例示するように、項目「患者ＩＤ」、項目「医師ＩＤ」、項目「疾患ＩＤ」、項目「ユニットＩＤ」、項目「医療行為」、項目「患者状態」、項目「目標状態」、項目「ユニット移行ロジック」、項目「条件付き指示」、項目「離脱条件」、及び項目「標準滞在日数」に対応する情報を相互に関連付けて構成されている。項目「患者ＩＤ」、項目「医師ＩＤ」、及び項目「疾患ＩＤ」に対応する情報は、図６から８の同一項目に対応する情報とそれぞれ共通である。項目「ユニットＩＤ」に対応する情報は、ユニットを一意に識別するためのユニット識別情報である。項目「医療行為」、項目「患者状態」、項目「目標状態」、項目「ユニット移行ロジック」、項目「条件付き指示」、及び項目「離脱条件」の対応する各情報は、図３の説明において述べた通りであり、医療行為内容情報と実施順序情報の一部を構成する。項目「標準滞在日数」に対応する情報は、各ユニットの標準的な滞在日数（当該ユニットに移行してから次順のユニットへ移行するまでの日数）である。ここでは、項目「患者状態」に対応する情報（状態情報）には、各ユニットにおいて注目すべき患者状態の内容を記述した情報に加えて、この状態が測定された場合にはその測定結果を示す測定結果情報が併せて格納されているものとし、この測定結果情報が、実施計画の連携性を判定するために使用する連携性判定情報として機能する。図９の例では、ユニットＩＤ＝Ａ−２のユニットにおいて、測定された血圧が１２８であり、血液型がＡ型であり、組織適合抗原がＨＬＡ−Ａであることを示している。この医療計画情報は、例えば、患者の数に応じた数だけ（患者ＩＤ毎に）作成され、医療計画情報ＤＢ１１ｄに格納される。なお、医療計画情報の具体的な記述構造としては、図５に示した構成例以外の任意の構造を採用することができ、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式により、タグを用いて各情報の意味を構造化することができる。
【００４８】
図１の連携医療計画情報ＤＢ１１ｅは、複数の医療計画を連携させて実施される可能性がある連携医療計画に関する連携医療計画情報であって、連携させる可能性がある複数の医療計画に対応する医療計画識別情報（実施計画識別情報）を、相互に関連付けて構成された連携医療計画情報（連携実施計画情報）、を格納する連携医療計画情報格納手段（連携実施計画情報格納手段）である。この連携医療計画情報は、図１０に例示するように、項目「連携医療計画ＩＤ」、項目「連携医療計画種類ＩＤ」、項目「第１患者ＩＤ」、及び項目「第２患者ＩＤ」に対応する情報を相互に関連付けて構成されている。項目「連携医療計画ＩＤ」に対応する情報は、連携医療計画を一意に識別するための連携医療計画識別情報である。項目「連携医療計画種類ＩＤ」は、連携医療計画の種類を一意に識別するための連携医療計画種類情報（連携実施計画種類情報）である。項目「第１患者ＩＤ」に対応する情報は、連携医療計画ＩＤにて識別される連携医療計画に対応する複数の医療計画の対象となる患者の患者ＩＤであって、第１グループに属する患者（以下、第１患者）のＩＤであり、医療計画識別情報（実施計画識別情報）として機能する。項目「第２患者ＩＤ」に対応する情報は、連携医療計画ＩＤにて識別される連携医療計画に対応する複数の医療計画の対象となる患者の患者ＩＤであって、第２グループに属する患者（以下、第２患者）のＩＤであり、医療計画識別情報（実施計画識別情報）として機能する。第１グループに属する患者とは、連携医療計画ＩＤにて識別される連携医療計画において、共通の条件に合致するために相互に入れ替わることが可能な患者を意味しており、例えば、連携医療計画が生体肝移植である場合には、ドナーとなる患者が該当する。第２グループに属する患者とは、連携医療計画ＩＤにて識別される連携医療計画において、第１グループとは異なる共通の条件に合致するために相互に入れ替わることが可能な患者を意味しており、例えば、連携医療計画が生体肝移植である場合には、レシーピエントとなる患者が該当する。また、第１グループに属する患者と第２グループに属する患者とは、それぞれ単数又は複数である可能性があり、特定の連携医療計画ＩＤの第１グループに属する患者が他の連携医療計画ＩＤの第１グループにも属する可能性がある。例えば、図１０の例では、患者ＩＤ＝ＰＩＤ０００１の患者は、連携医療計画ＩＤ＝ＲＩＤ０００１の連携医療計画における第１グループと、連携医療計画ＩＤ＝ＲＩＤ０００２の連携医療計画における第１グループに属しており、例えば、後述する図１１の内容を参照すると、一人のドナーが、生体肝移植のドナーとしてレシーピエントに対して肝臓を提供する可能性があると共に、死体肝移植のドナーとしてレシーピエントに対して肝臓を提供する可能性がある場合を示している。
【００４９】
図１の連携医療計画種類情報ＤＢ１１ｆは、連携医療計画の種類を特定するための連携医療計画種類情報を格納する連携医療計画種類情報格納手段である。この連携医療計画種類情報は、図１１に例示するように、項目「連携医療計画種類ＩＤ」、項目「連携医療計画種類名」、項目「第１患者の種類」、及び項目「第２患者の種類」に対応する情報を相互に関連付けて構成されている。項目「連携医療計画種類ＩＤ」に対応する情報は、図１０の同一項目に対応する情報と共通である。項目「連携医療計画種類名」に対応する情報は、連携医療計画の種類の名称である。項目「第１患者の種類」に対応する情報は、連携医療計画における第１患者の種類（あるいは、原因、理由、位置付け、役割、立場）である。項目「第２患者の種類」に対応する情報は、連携医療計画における第２患者の種類（あるいは、原因、理由、位置付け、役割、立場）である。
【００５０】
図１の特定状態情報ＤＢ１１ｇは、医療計画における実施対象が取り得る状態の中で、連携医療計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段である。この特定状態情報は、図１２に例示するように、項目「連携医療計画種類ＩＤ」及び項目「患者状態」を相互に関連付けて構成されている。これらの各項目に対応する情報は、図９、１０の同一項目に対応する情報と共通である。例えば、図１２の例では、連携医療計画種類ＩＤ＝ＲＫＩＤ０００２の連携医療計画における特定の状態とは、この連携医療計画に連携された医療計画の対象になる第１患者が心臓死した状態であることを示している。
【００５１】
図１の連携性判定条件情報ＤＢ１１ｈは、連携医療計画において連携させる複数の医療計画の連携性を判定するための連携性判定条件を特定する連携性判定条件情報を格納する連携性判定条件情報格納手段である。この連携性判定条件情報は、図１３に例示するように、項目「連携医療計画種類ＩＤ」及び項目「連携性判定条件」を相互に関連付けて構成されている。項目「連携医療計画種類ＩＤ」に対応する情報は、図１０の同一項目に対応する情報と共通である。項目「連携性判定条件」に対応する情報は、連携性判定条件を示す情報である。例えば、図１３の例では、連携医療計画種類ＩＤ＝ＲＫＩＤ０００１の連携医療計画における連携性判定条件とは、第１患者と第２患者の相互間で、血液型が適合し、かつ、組織適合抗原が適合することであることを示す。
【００５２】
（処理）
次に、本システムにおいて本プログラムを実行すること等によって行われる連携医療計画支援処理（以下、本処理）について説明する。この処理は、連携医療計画情報を登録するための連携医療計画情報登録処理と、この連携医療計画情報登録処理で登録された連携医療計画情報を出力するための連携医療計画情報出力処理に大別される。以下、これら各処理を順次説明する。なお、ステップは「Ｓ」と略記する。
【００５３】
以下の本処理の説明において、制御主体を特記しない処理については、連携医療計画支援サーバ１０の制御部１２にて実行されるものとし、情報の取得元や取得経路を特記しない場合については、公知のタイミング及び公知の方法にて、連携医療計画支援サーバ１０の記憶部１１に予め格納されており、あるいは、支援端末３０を介して医療従事者によって入力されるものとする。特に、図６の患者情報、図７の医師情報、図８の疾患情報、及び図９の医療計画情報については、本願発明者等による特開２００９−２０５６５４に開示されている処理と同様の処理により、あるいはその他の任意の処理により、支援端末３０を介して医療従事者によって予め入力することができる。また、図１１の連携医療計画種類情報、図１２の特定状態情報、及び図１３の連携性判定条件情報については、医療従事者が医学的見地に基づいて決定し、支援端末３０を介して医療従事者によって予め入力することができる。
【００５４】
（処理−連携医療計画情報登録処理）
最初に、連携医療計画情報登録処理について説明する。図１４は、連携医療計画情報登録処理のフローチャートである。医療従事者は、連携医療計画を作成したい場合には、支援端末３０を介して連携医療計画支援サーバ１０にアクセスして所定の方法で連携医療計画情報登録を要求する。この要求を受けた連携医療計画支援サーバ１０の連携医療計画情報登録部１２ｂ１は（ＳＡ１、Ｙｅｓ）、記憶部１１に予め記憶された連携医療計画情報登録用画面を支援端末３０に送信し（ＳＡ２）、この連携医療計画情報登録用画面が支援端末３０の図示しないモニタに表示される。
【００５５】
図１５は、連携医療計画情報登録用画面の表示例である。この連携医療計画情報登録用画面は、登録したい連携医療計画の連携医療計画種類を選択する選択欄７０と、登録したい連携医療計画において連携させる医療計画を選択する選択欄７１、７２と、登録を指示する登録ボタン７３が設けられている。選択欄７０は、例えば、連携医療計画種類情報ＤＢ１１ｆに格納されている連携医療計画種類情報に含まれる連携医療計画種類ＩＤと連携医療計画種類名とをドロップダウンリスト形式で表示させることができるように構成されており、このように表示させた連携医療計画種類ＩＤと連携医療計画種類名の中から、登録したい連携医療計画の連携医療計画種類に合致するものを医療従事者がクリック等にて選択する。また、選択欄７１、７２は、例えば、患者情報ＤＢ１１ａに格納されている患者情報に含まれている患者ＩＤと患者氏名とをドロップダウンリスト形式で表示させることができるように構成されており、このように表示させた患者ＩＤと患者氏名の中から、登録したい連携医療計画の連携医療計画種類に合致するものを医療従事者がクリック等にて選択する。ここでは、連携医療計画において連携させる医療計画の選択を、これら医療計画の対象となっている患者を選択することで行うこととしており、選択欄７１で第１患者を選択し、選択欄７２で第２患者を選択する。
【００５６】
これら各選択欄７０〜７２における選択を行った後、医療従事者がクリック等にて登録ボタン７３を押下すると、連携医療計画情報登録部１２ｂ１は、選択欄７０〜７２で選択された情報に基づいて連携医療計画情報の新規なレコードを生成し、当該生成したレコードを連携医療計画情報ＤＢ１１ｅに登録する（ＳＡ３）。例えば、連携医療計画情報登録部１２ｂ１は、連携医療計画ＩＤを所定方法（例えば連番）で生成し、当該生成した連携医療計画ＩＤと、図１５の選択欄７０で選択された連携医療計画種類ＩＤと、図１５の選択欄７１で選択された第１患者の患者ＩＤと、図１５の選択欄７２で選択された第２患者の患者ＩＤとを、相互に関連付けて登録する。これにて連携医療計画情報登録処理が終了する。
【００５７】
（処理−連携医療計画情報出力処理）
次に、連携医療計画情報出力処理について説明する。図１６は、連携医療計画情報出力処理のフローチャートである。医療従事者は、連携医療計画情報を出力したい場合には、支援端末３０を介して連携医療計画支援サーバ１０にアクセスして所定の方法で連携医療計画情報出力を要求する。この要求を受けた連携医療計画支援サーバ１０の連携医療計画情報出力部１２ｂ２は（ＳＢ１、Ｙｅｓ）、その時点で連携医療計画情報ＤＢ１１ｅに格納されている連携医療計画情報を対象に、連携性判定条件判定処理と、特定状態判定処理を行い、これら各処理の結果等を含んだ情報を表示するための連携医療計画情報出力用画面を支援端末３０に送信し（ＳＢ８）、この連携医療計画情報出力用画面が支援端末３０の図示しないモニタに表示される。
【００５８】
（処理−連携医療計画情報出力処理−連携性判定条件判定処理）
まず、連携性判定条件判定処理について説明する。連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから連携医療計画情報を取得し、当該取得した連携医療計画情報に含まれる連携医療計画種類ＩＤに対応する連携性判定条件を連携性判定条件情報ＤＢ１１ｈから取得する（ＳＢ２）。また、連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる第１患者ＩＤと第２患者ＩＤに基づき、医療計画情報ＤＢ１１ｄの医療計画情報を参照し、第１患者ＩＤ又は第２患者ＩＤと同一の患者ＩＤに関連付けられた各患者の医療計画における各患者状態（測定結果情報を含む）を取得する（ＳＢ３）。そして、連携性判定条件情報ＤＢ１１ｈから取得した連携性判定条に、医療計画情報ＤＢ１１ｄから取得した各患者状態（測定結果情報を含む）が合致するか否かを判定することにより、連携医療計画情報ＤＢ１１ｅの連携医療計画情報にて特定される連携医療計画を行う上で、医療計画情報ＤＢ１１ｄの医療計画情報にて特定される医療計画を連携させることの可否（または適否）を判定する（ＳＢ４）。
【００５９】
なお、医療計画における各患者状態は、各患者について最新のものを取得する。例えば、各患者の医療計画において、測定結果情報を含んでいる患者状態に関連付けられたユニットＩＤを持つユニットを特定し、当該特定したユニットの中で、最も実施順序が遅くユニットの患者状態を最新のものと特定することができる。実施順序は、ユニットＩＤとユニット移行ロジックを参照することで特定することができる。あるいは、最新の測定結果情報を含む患者状態を、各患者ＩＤに関連付けて格納しておくＤＢを設け、このＤＢを参照して最新の測定結果情報を取得してもよい。あるいは、ユニットの実施履歴を格納するＤＢを設け、このＤＢを参照することで、現在のユニットを特定するようにしてもよい。このように最新の患者状態を取得する点は、後述する特定状態判定処理において同じである。
【００６０】
例えば、連携医療計画情報出力部１２ｂ２は、図１０の連携医療計画情報における連携医療計画ＩＤ＝ＲＩＤ０００１で識別される連携医療計画に関し、図１３の連携性判定条件情報から、連携医療計画種類ＩＤ＝ＲＫＩＤ０００１に対応する連携性判定条件として「第１患者と第２患者の相互間：血液型が適合、かつ、組織適合抗原が適合」を取得し、図９の医療計画情報から、患者ＩＤ＝ＰＩＤ０００１である第１患者（ドナーとなる患者）の最新の患者状態として、血液型＝Ａ型、組織適合抗原＝ＨＬＡ−Ａを取得すると共に、患者ＩＤ＝ＰＩＤ００７８である第２患者（レシーピエントとなる患者）の最新の患者状態として、血液型＝Ｂ型、組織適合抗原＝ＨＬＡ−Ａを取得する（患者ＩＤ＝ＰＩＤ００７８に対応する医療計画情報の例は図９において図示せず）。この場合、連携医療計画情報出力部１２ｂ２は、第１患者の患者状態と第２患者の患者状態は、連携性判定条件情報の患者状態に合致しないため（この例では血液型が適合しないため）、連携不可（又は連携不適）と判定する。これにて連携性判定条件判定処理が終了する。
【００６１】
（処理−連携医療計画情報出力処理−特定状態判定処理）
次に、特定状態判定処理について説明する。連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから連携医療計画情報を取得し、当該取得した連携医療計画情報に含まれる連携医療計画種類ＩＤに対応する患者状態を特定状態情報ＤＢ１１ｇから取得する（ＳＢ５）。また、連携医療計画情報出力部１２ｂ２は、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる第１患者ＩＤと第２患者ＩＤに基づき、医療計画情報ＤＢ１１ｄの医療計画情報を参照し、第１患者ＩＤ又は第２患者ＩＤと同一の患者ＩＤに関連付けられた各患者の医療計画における各患者状態（測定結果情報を含む）を取得する（ＳＢ６）。そして、特定状態情報ＤＢ１１ｇから取得した患者状態に、医療計画情報ＤＢ１１ｄから取得した各患者状態（測定結果情報を含む）が合致するか否かを判定することにより、連携医療計画情報ＤＢ１１ｅの連携医療計画情報にて特定される連携医療計画を行う上での特定の状態が到来したか否かを判定する（ＳＢ７）。
【００６２】
例えば、連携医療計画情報出力部１２ｂ２は、図１０の連携医療計画情報における連携医療計画ＩＤ＝ＲＩＤ０００１で識別される連携医療計画に関し、図１２の特定状態情報から、連携医療計画種類ＩＤ＝ＲＫＩＤ０００１に対応する患者状態として「第１患者と第２患者：血圧１４０未満」を取得し、図９の医療計画情報から、患者ＩＤ＝ＰＩＤ０００１である第１患者（ドナーとなる患者）の最新の患者状態として、血圧＝１２８を取得すると共に、患者ＩＤ＝ＰＩＤ００７８である第２患者（レシーピエントとなる患者）の患者状態として、血圧＝１３０を取得する（患者ＩＤ＝ＰＩＤ００７８に対応する医療計画情報の例は図９において図示せず）。この場合、連携医療計画情報出力部１２ｂ２は、第１患者の患者状態と第２患者の患者状態は、特定状態情報の患者状態に合致するため、特定状態が到来したものと判定する。これにて特定状態判定処理が終了する。
【００６３】
（処理−連携医療計画情報出力処理）
その後、連携医療計画情報出力部１２ｂ２は、上述のように、その時点で連携医療計画情報ＤＢ１１ｅに格納されている連携医療計画情報の少なくとも一部と、当該連携医療計画に対応する複数の医療計画に関する医療計画情報の少なくとも一部と、連携性判定条件判定処理の処理結果と、特定状態判定処理の処理結果と、を含んだ情報を併せて表示するための連携医療計画情報出力用画面を支援端末３０に送信し（ＳＢ８）、この連携医療計画情報出力用画面が支援端末３０の図示しないモニタに表示される。
【００６４】
図１７は、連携医療計画情報出力用画面の表示例である。この連携医療計画情報出力用画面は、連携医療計画を表示するための表示領域８０と、連携医療計画において連携される医療計画を表示するための領域であって、第１患者（例えばドナー）の医療計画を表示する表示領域８１と、第２患者（例えばレシーピエント）の医療計画を表示する表示領域８２とを含んで構成されている。
【００６５】
表示領域８０には、各連携医療計画に対応する１又は複数のレコードが表示されており、各レコードは、連携医療計画ＩＤと連携医療計画種類名を含んで構成されている。連携医療計画種類名は、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる連携医療計画種類ＩＤに基づいて連携医療計画種類情報ＤＢ１１ｆを参照することで取得される。
【００６６】
表示領域８１、８２には、各医療計画に対応する１又は複数のレコードが表示されており、各レコードは、患者ＩＤと、患者氏名と、連携性判定条件判定結果（図１７では条件判定）と、特定状態判定結果（図１７では状態判定）を含んで構成されている。患者ＩＤは、連携医療計画情報ＤＢ１１ｅから取得した連携医療計画情報に含まれる第１患者ＩＤ又は第２患者ＩＤである。患者氏名は、連携医療計画情報に含まれる第１患者ＩＤ又は第２患者ＩＤに基づいて患者情報ＤＢ１１ａを参照することで取得される。連携性判定条件判定結果は、上述の連携性判定条件判定処理の処理結果であり、例えば、「連携可」又は「連携不可」のいずれかが表示される。特定状態判定結果は、上述の特定状態判定処理の処理結果であり、例えば、「到来」又は「未到来」のいずれかが表示される。
【００６７】
ここで、表示領域８１、８２に表示される情報は、表示領域８０に表示された情報やその選択結果に基づいて切り替えられる。すなわち、表示領域８０に複数のレコードが表示されている場合（連携医療計画情報ＤＢ１１ｅに複数のレコードの連携医療計画情報が格納されている場合）には、当該表示されている複数のレコードの中から、特定の一つのレコードを、医療従事者が支援端末３０を介してクリック等にて選択することで、出力対象とする連携実施計画が特定され、当該特定された連携医療計画に連携する第１患者と第２患者の情報が表示領域８１、８２に表示される。したがって、表示領域８０に表示されている複数のレコードの選択を切り替える度に、表示領域８１、８２の表示内容が切り替わる。あるいは、表示領域８０に一つのレコードのみが表示されている場合（連携医療計画情報ＤＢ１１ｅに一つのレコードの連携医療計画情報のみが格納されている場合）には、当該一つのレコードに対応する連携医療計画に連携する第１患者と第２患者の情報が表示領域８１、８２に表示される。
【００６８】
例えば、図１７の例では、表示領域８０に表示されている２つのレコードのうち、上側のレコードが選択されている例を示している。そして、表示領域８１には、２人の第１患者（ドナー）の医療計画に対応するレコードが表示されており、表示領域８２には、１人の第２患者（レシーピエント）の医療計画に対応するレコードが表示されている。２人の第１患者のレコードの中で、上側のレコードには連携性判定条件判定処理の処理結果として「連携不可」が表示されているので、第２患者（レシーピエント）の医療計画と連携できない（レシーピエントへの臓器の提供が出来ない）ことが判り、下側のレコードには連携性判定条件判定処理の処理結果として「連携可」が表示されているので、第２患者（レシーピエント）の医療計画と連携できる（レシーピエントへの臓器の提供が出来る）ことが判る。なお、ここでは、２人の第１患者（ドナー）に対して一人の第２患者（レシーピエント）が関連付けられている例を示しており、この場合、第２患者（レシーピエント）のレコードにおける連携性判定条件判定処理の処理結果の表示においては、いずれの第１患者（ドナー）に対する処理結果であるのかが特定できるように、第１患者の患者ＩＤが併せて表示されている。例えば、図１７の例では、患者ＩＤ＝ＰＩＤ００１５の第２患者に対して、患者ＩＤ＝ＰＩＤ０００１の第１患者は連携できないが、患者ＩＤ＝ＰＩＤ０２３５の第１患者は連携できることを示している。
【００６９】
また、２人の第１患者のレコードの中で、上側のレコードには特定状態判定結果の処理結果として「未到来」が表示されているので、第１患者の患者状態は未だ特定状態になっておらず、仮に連携性判定条件判定処理の処理結果が「連携可」であった場合でも、現時点では第２患者（レシーピエント）の医療計画と連携できない（レシーピエントへの臓器の提供が出来ない）ことが判る。一方、２人の第１患者のレコードの中で、下側のレコードには特定状態判定結果の処理結果として「到来」が表示されているので、連携性判定条件判定処理の処理結果が「連携可」である場合には、現時点で第２患者（レシーピエント）の医療計画と連携できる（レシーピエントへの臓器の提供が出来る）ことが判る。
【００７０】
これらのことから、図１７の例では、現時点において、患者ＩＤ＝ＰＩＤ００１５の第２患者であるレシーピエントに対して、患者ＩＤ＝ＰＩＤ０２３５の第１患者であるドナーから臓器の提供ができる状態であることが把握できる。
【００７１】
（実施の形態の効果）
このように本実施の形態によれば、連携医療計画情報と複数の医療計画情報を併せて出力するので、この出力を参照することで、連携医療計画において連携される可能性がある複数の医療計画の内容や状況を把握することが可能となり、これら複数の医療計画を一つのプロジェクト（エピソード）として管理することが可能になるので、連携医療計画の管理や実行を容易かつ的確に行うことが可能となる。従って、医療行為の質を高めることが可能となる。
【００７２】
また、患者の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、複数の医療計画が特定の状態になった場合に連携医療計画が進行する場合等において、連携医療計画の進行の可否や適否を判断することが容易になり、連携医療計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００７３】
また、連携医療計画の種類に応じて特定された特定状態情報に基づいて、実施対象の状態が特定の状態に合致するか否かが出力手段を介して報知されるので、連携医療計画の種類に応じた適切な特定状態情報に基づいて連携医療計画の進行の可否や適否を判断することが容易になり、連携医療計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００７４】
また、連携性判定条件が満たされるか否かが出力手段を介して報知されるので、複数の医療計画が所定条件下でのみ連携可能である場合等において、複数の医療計画を連携させることの可否や適否を判断することが容易になり、連携医療計画の管理や実行を一層容易かつ一層的確に行うことが可能となる。
【００７５】
〔III〕各実施の形態に対する変形例
以上、本発明に係る各実施の形態について説明したが、本発明の具体的な構成及び手段は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良できる。以下、このような変形例について説明する。
【００７６】
（解決しようとする課題や発明の効果について）
まず、発明が解決しようとする課題や発明の効果は、前記した内容に限定されるものではなく、本発明によって、前記に記載されていない課題を解決したり、前記に記載されていない効果を奏することもでき、また、記載されている課題の一部のみを解決したり、記載されている効果の一部のみを奏することがある。
【００７７】
（構成及び制御について）
また、上記実施の形態で自動的に行われるものとして説明した制御の全部または任意の一部を手動で行っても良く、逆に、手動で行われるものとして説明した制御の全部または任意の一部を公知技術または上述した思想に基づいて自動化しても良い。また、上記実施の形態において示した各構成要素の各機能ブロックの一部又は全部を、ハードワイヤードロジックにて構成しても良い。
【００７８】
（分散や統合について）
また、上述した各電気的構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成できる。例えば、連携医療計画支援サーバ１０と医療計画作成支援サーバ５０を相互に統合したり、連携医療計画支援サーバ１０の機能を複数のサーバやＤＢに分散したり、連携医療計画支援サーバ１０や医療計画作成支援サーバ５０の一部の機能を支援端末３０に持たせてもよい。
【００７９】
（情報の格納や取得について）
また、連携医療計画支援サーバ１０の各ＤＢの具体的構成も任意に変更可能であり、上述の各ＤＢを相互に統合したり、各ＤＢをさらに分割して構成してもよい。さらに、連携医療計画支援に必要な情報の全部又は一部を、電子カルテサーバ２０から取得してもよい。すなわち、連携医療計画支援サーバ１０で使用する第１患者ＩＤや第２患者ＩＤと、既存の電子カルテサーバ２０で患者を識別するための使用している患者ＩＤとを、相互に対応させた同一のＩＤとし、あるいは相互に変換可能な変換テーブルを介在させ、連携医療計画情報に含まれる第１患者ＩＤや第２患者ＩＤに基づいて、これら第１患者ＩＤや第２患者ＩＤに対応する患者の電子カルテ情報を電子カルテサーバ２０から取得して連携医療計画情報出力用画面に出力するようにしてもよい。
【００８０】
（連携医療計画と医療計画の関係について）
上記実施の形態では、連携医療計画が生体肝移植である場合を主に例示しているので、連携医療計画に連携し得る医療計画として、第１患者（ドナー）の医療計画と、第２患者（レシーピエント）の医療計画との、合計２つのカテゴリの医療計画を連携させるものとしている。ただし、連携医療計画に連携し得る医療計画のカテゴリ数は、１つ以上の任意の数であればよい。例えば、別々のドナーから提供された心臓と肝臓を一つのレシーピエントに移植する場合には、第１患者（心臓のドナー）の医療計画と、第２患者（肝臓のドナー）の医療計画と、第３患者（レシーピエント）の医療計画との、合計３つのカテゴリの医療計画を連携させることになる。また、各カテゴリにおける医療計画の数も任意であり、例えば、第２患者（レシーピエント）の医療計画として、複数の第２患者の医療計画を第１患者（ドナー）の医療計画に連携させてもよい。これらの各場合においても、上記説明した実施の形態を、当業者に自明な知識で拡張することで、実現可能である。
【００８１】
（実施計画識別情報について）
上記実施の形態では、連携医療計画情報に第１患者ＩＤと第２患者ＩＤを含めており、これら第１患者ＩＤと第２患者ＩＤを用いて連携医療計画に連携される複数の医療計画を識別しているため、これら第１患者ＩＤと第２患者ＩＤが特許請求の範囲における実施計画識別情報として機能している。この他にも、医療計画を一意に識別する医療計画ＩＤを医療計画情報の各レコードに関連付けて格納しておくと共に、連携医療計画情報の第１患者ＩＤと第２患者ＩＤに代えて医療計画ＩＤを含める等、任意の識別情報を、実施計画識別情報とすることが可能である。
【００８２】
（特定状態情報について）
上記実施の形態では、特定状態情報として特定の患者状態を使用しており、具体的には、患者状態に含まれる血圧の数値が所定の血圧の数値範囲に合致する場合に、特定の状態が到来したものと判定しているが、数値に基づく判定以外にも、言葉による判定を行ってもよい。例えば、特定状態情報として、特定の患者状態になったことを示す特定の用語（予約語）（例えば死亡、心臓停止、脳死等）を登録しておき、患者状態に当該用語が含まれることとなった場合には、特定の患者状態になったものと判定してもよい。
【００８３】
（情報の出力形態について）
上記実施の形態では、連携医療計画情報等を連携医療計画情報出力用画面にて表示しているが、この他の任意の形態で当該情報等を出力することが可能であり、例えば、支援端末３０に接続された公知の印刷装置に印刷したり、支援端末３０が備える公知のスピーカから特定状態が到来した場合に所定の報知音を出力してもよい。また、連携医療計画情報出力用画面にて表示する場合であっても、この画面構成や各表示領域に表示する情報の内容や配置は変更可能であり、例えば、表示領域には第１患者の血液型や組織適合抗原を表示したり、表示領域には第２患者の最新の患者状態を併せて表示したり、特定の状態になった患者に対応するレコードを点滅表示させたり、特定の状態になった患者に対応するレコードを色や文字サイズを変えることで強調表示させてもよい。
【００８４】
（処理タイミングについて）
上記実施の形態では、医療従事者が連携医療計画情報出力を要求した場合に、連携性判定条件判定処理及び特定状態判定処理が実行されるものとして説明したが、これら各処理の実行タイミングは任意に変更することができる。例えば、特定状態判定処理については、所定間隔が到来する毎（例えば１時間毎）に繰り返し実行したり、医療計画情報ＤＢ１１ｄにおける患者状態が更新される毎に繰り返し実行し、特定状態が到来した場合には、連携医療計画情報出力用画面が支援端末３０に自動的に表示されるようにしてもよい。
【符号の説明】
【００８５】
１ 連携医療計画支援システム
１０ 連携医療計画支援サーバ
１１ 記憶部
１１ａ 患者情報ＤＢ
１１ｂ 医師情報ＤＢ
１１ｃ 疾患情報ＤＢ
１１ｄ 医療計画情報ＤＢ
１１ｅ 連携医療計画情報ＤＢ
１１ｆ 連携医療計画種類情報ＤＢ
１１ｇ 特定状態情報ＤＢ
１１ｈ 連携性判定条件情報ＤＢ
１２ 制御部
１２ａ 医療計画管理部
１２ｂ 連携医療計画管理部
１２ｂ１ 連携医療計画情報登録部
１２ｂ２ 連携医療計画情報出力部
１３ ネットワークＩＦ
１４ バス
２０ 電子カルテサーバ
３０ 支援端末
４０、６０ ネットワーク
５０ 医療計画作成支援サーバ
７０〜７２ 選択欄
７３ 登録ボタン
８０〜８２ 表示領域
【特許請求の範囲】
【請求項１】
実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、
複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、
前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段と、
を備える連携実施計画支援システム。
【請求項２】
前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、
前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、
前記制御手段は、前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う、
請求項１に記載の連携実施計画支援システム。
【請求項３】
前記連携実施計画情報格納手段に格納される前記連携実施計画情報は、前記連携実施計画の種類を特定する連携実施計画種類情報を含み、
前記特定状態情報格納手段は、前記特定状態情報を前記連携実施計画種類情報に関連付けて格納し、
前記制御手段は、前記連携実施計画に対応する前記連携実施計画種類情報を前記連携実施計画情報格納手段から取得し、当該取得した連携実施計画種類情報に対応する前記特定状態情報を前記特定状態情報格納手段から取得し、前記実施計画情報格納手段から取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定する、
請求項２に記載の連携実施計画支援システム。
【請求項４】
前記実施計画情報格納手段に格納される前記実施行為内容情報は、複数の前記実施計画の連携性を判定するために使用する連携性判定情報を含み、
前記連携実施計画において連携させる複数の前記実施計画の連携性を判定するための連携性判定条件を特定する連携性判定条件情報を格納する連携性判定条件情報格納手段を備え、
前記制御手段は、前記特定された連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記連携性判定情報を前記実施計画情報格納手段から取得すると共に、前記特定された連携実施計画に対応する前記連携性判定条件情報を前記連携性判定条件情報納手段から取得し、当該取得した連携性判定情報に基づいて、当該取得した連携性判定条件情報にて特定される連携性判定条件が満たされるか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う、
請求項１から３のいずれか一項に記載の連携実施計画支援システム。
【請求項５】
前記実施対象は患者であり、
前記実施行為は医療行為であり、
前記実施計画は医療計画であり、
前記連携実施計画は連携医療計画である、
請求項１から４のいずれか一項に記載の連携実施計画支援システム。
【請求項６】
実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、
複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、
を備えるコンピュータに実行させるプログラムであって、
前記コンピュータを、
前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段、
として機能させる連携実施計画支援プログラム。
【請求項７】
前記コンピュータの前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、
前記コンピュータは、前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、
前記コンピュータを、
前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う前記制御手段、
として機能させる請求項６に記載の連携実施計画支援プログラム。
【請求項８】
前記実施対象は患者であり、
前記実施行為は医療行為であり、
前記実施計画は医療計画であり、
前記連携実施計画は連携医療計画である、
請求項６又は７に記載の連携実施計画支援プログラム。
【請求項１】
実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、
複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、
前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段と、
を備える連携実施計画支援システム。
【請求項２】
前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、
前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、
前記制御手段は、前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う、
請求項１に記載の連携実施計画支援システム。
【請求項３】
前記連携実施計画情報格納手段に格納される前記連携実施計画情報は、前記連携実施計画の種類を特定する連携実施計画種類情報を含み、
前記特定状態情報格納手段は、前記特定状態情報を前記連携実施計画種類情報に関連付けて格納し、
前記制御手段は、前記連携実施計画に対応する前記連携実施計画種類情報を前記連携実施計画情報格納手段から取得し、当該取得した連携実施計画種類情報に対応する前記特定状態情報を前記特定状態情報格納手段から取得し、前記実施計画情報格納手段から取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定する、
請求項２に記載の連携実施計画支援システム。
【請求項４】
前記実施計画情報格納手段に格納される前記実施行為内容情報は、複数の前記実施計画の連携性を判定するために使用する連携性判定情報を含み、
前記連携実施計画において連携させる複数の前記実施計画の連携性を判定するための連携性判定条件を特定する連携性判定条件情報を格納する連携性判定条件情報格納手段を備え、
前記制御手段は、前記特定された連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記連携性判定情報を前記実施計画情報格納手段から取得すると共に、前記特定された連携実施計画に対応する前記連携性判定条件情報を前記連携性判定条件情報納手段から取得し、当該取得した連携性判定情報に基づいて、当該取得した連携性判定条件情報にて特定される連携性判定条件が満たされるか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う、
請求項１から３のいずれか一項に記載の連携実施計画支援システム。
【請求項５】
前記実施対象は患者であり、
前記実施行為は医療行為であり、
前記実施計画は医療計画であり、
前記連携実施計画は連携医療計画である、
請求項１から４のいずれか一項に記載の連携実施計画支援システム。
【請求項６】
実施対象に対して実施する複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画に関する実施計画情報であって、前記実施計画を一意に識別する実施計画識別情報と、前記複数の実施行為の内容を特定する実施行為内容情報と、前記複数の実施行為の実施順序を特定する実施順序情報とを、相互に関連付けて構成された実施計画情報、を格納する実施計画情報格納手段と、
複数の前記実施計画を連携させて実施される可能性がある連携実施計画に関する連携実施計画情報であって、連携させる可能性がある複数の前記実施計画に対応する前記実施計画識別情報を、相互に関連付けて構成された連携実施計画情報、を格納する連携実施計画情報格納手段と、
を備えるコンピュータに実行させるプログラムであって、
前記コンピュータを、
前記連携実施計画に関する前記連携実施計画情報の少なくとも一部を前記連携実施計画情報格納手段から取得すると共に、当該連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報の少なくとも一部を前記実施計画情報格納手段から取得し、当該取得した連携実施計画情報の少なくとも一部と当該取得した実施計画情報の少なくとも一部とを併せて出力手段に出力する制御手段、
として機能させる連携実施計画支援プログラム。
【請求項７】
前記コンピュータの前記実施計画情報格納手段に格納される前記実施行為内容情報は、前記実施対象の状態を特定する状態情報を含み、
前記コンピュータは、前記実施計画における前記実施対象が取り得る状態の中で、前記連携実施計画に関連する特定の状態を特定する特定状態情報を格納する特定状態情報格納手段を備え、
前記コンピュータを、
前記連携実施計画に対応する複数の前記実施計画に関する前記実施計画情報に含まれる前記状態情報を前記実施計画情報格納手段から取得すると共に、前記特定状態情報を前記特定状態情報格納手段から取得し、当該取得した状態情報にて特定される前記実施対象の状態が、当該取得した特定状態情報にて特定される前記特定の状態に合致するか否かを判定し、当該判定結果を報知するための出力を前記出力手段を介して行う前記制御手段、
として機能させる請求項６に記載の連携実施計画支援プログラム。
【請求項８】
前記実施対象は患者であり、
前記実施行為は医療行為であり、
前記実施計画は医療計画であり、
前記連携実施計画は連携医療計画である、
請求項６又は７に記載の連携実施計画支援プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１１−１６４８０５（Ｐ２０１１−１６４８０５Ａ）
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願番号】特願２０１０−２４９２１（Ｐ２０１０−２４９２１）
【出願日】平成２２年２月７日（２０１０．２．７）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２１年度、文部科学省、「関西広域バイオメディカルクラスター構想（神戸地域）に伴う研究委託業務」に係る再委託契約、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（３０００６１８３５）財団法人先端医療振興財団 (28)
【出願人】（３０１０１８６０３）株式会社サイバー・ラボ (11)
【出願人】（５０２０９９２０１）
【出願人】（５０４４２６０８９）
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願日】平成２２年２月７日（２０１０．２．７）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２１年度、文部科学省、「関西広域バイオメディカルクラスター構想（神戸地域）に伴う研究委託業務」に係る再委託契約、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（３０００６１８３５）財団法人先端医療振興財団 (28)
【出願人】（３０１０１８６０３）株式会社サイバー・ラボ (11)
【出願人】（５０２０９９２０１）
【出願人】（５０４４２６０８９）
[ Back to top ]