JP2009282701A - 実施計画管理システム及び実施計画管理プログラム - Google Patents

Abstract

【課題】実施計画の実施結果を様々な視点から活用可能とすることで、実施計画の客観的な評価を行うこと等を可能とする、実施計画管理システム及び実施計画管理プログラムを提供することを目的とする。
【解決手段】複数の実施行為の内容と実施順序とを含んで構成される実施計画を管理するための実施計画管理システムであって、複数の実施行為の内容及び実施順序を特定するための実施計画情報を格納する実施計画情報ＤＢ２１ｂと、実施計画の実施履歴に関する実施履歴情報を、実施対象に関する実施対象情報あるいは実施者に関する実施者情報と共に、当該実施計画に対応する実施計画情報に関連付けて格納する実施履歴情報ＤＢ２１ｃと、実施対象情報、実施者情報、あるいは実施計画情報が特定された場合に、当該特定された情報に対応する他の情報を実施履歴情報ＤＢ２１ｃから取得する実施計画情報生成部２２ａとを備える。
【選択図】図１

Description

本発明は、実施対象に対して複数の標準化された実施行為を実施するための実施計画の実行管理等を行う実施計画管理システム及び実施計画管理プログラムに関する。

従来、医療関連行為を二次元構造で示したクリティカルパスが知られている。このクリティカルパスは、それまで医師の個人的な暗黙知として蓄積された膨大な医療知識を、標準化及び可視化を通じて形式知として提示することで、医療の質と効率を系統的に保証及び向上させることができる点で有用である。しかしながら、患者の状態によっては、クリティカルパスを適用できなかったり、予め想定された標準的な経過から乖離してしまいクリティカルパスを逸脱する可能性があるという問題が指摘されていた。

この点に鑑みて本願発明者は、医療プロセス質管理システム及び医療プロセス質管理方法を提案した（特許文献１参照）。このシステムは、患者に対して実施する複数の医療プロセス及び各医療プロセスの実施順序等を記憶する記憶部と、次に実施する医療プロセスを読み出すプロセス管理部等を備えて構成されている。このシステムにおいては、「プロセスチャート（臨床プロセスチャート）」と「ユニットシート」を用いて、医療行為の内容を臨床経路に従って医師等に順次提示する。「ユニットシート」とは、患者の目標状態毎に形成された医療行為単位である「ユニット（プロセス）」を視覚化したものである。「プロセスチャート」は、複数のユニットを連結して構成される臨床経路の俯瞰図である。

このようにプロセスチャートとユニットシートという２種類のツールによって、医療行為の内容や実施順序を標準化された内容で各医師に提示することで、各医師が個別的に独自判断で医療行為の内容や実施順序を決定する場合に比べて、医療行為の構造化や標準化を図ることができ、臨床知識の抽出や俯瞰的可視化を行うことができて、延いては医療プロセスの質を維持及び向上させることができる。また、このシステムによれば、患者の個別性に柔軟に対応できるので、従来のクリティカルパスの問題点を解消することが可能になる。

国際公開第２００６／０５７３３６号パンフレット

しかしながら、従来のシステムでは、医療計画に対する客観的な評価や、該客観的な評価に基づいた医療計画の修正・選定が困難であった。すなわち、上記システムでは、医療計画に対する評価は医師が自らの知見によって行うことを前提としているため、当該医師以外の視点による客観的な評価が困難であったり、当該医師以外の関係者（行政、患者）が医療計画を評価することが困難であった。すなわち、医療計画を実行したり、その実行結果を漫然と蓄積しても、この実行結果を有効に再利用するための仕組みが存在していなかった。

例えば、医師にとっては、医療計画の立案時に、当該医療計画に適した患者又は不適な患者を客観的に判断することが困難であった。また、患者にとっては、自分の病気の治療に適した医療機関、治療に要する期間や費用、あるいは治癒率といった情報については、上記システムから得ることができなかった。このため、上記システムが、最終目的である患者の生活の質（ＱＯＬ)の向上にどの程度寄与効し得るのかが不透明であった。

本発明は、上記に鑑みてなされたものであって、実施計画の実行を管理する場合において、実施計画の実施履歴を蓄積し、この実施履歴を様々な視点から活用可能とすることで、実施計画の客観的な評価を行うこと等を可能とする、実施計画管理システム及び実施計画管理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１に記載の本発明は、実施対象に対して実施者によって実施され得る複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画を管理するための実施計画管理システムであって、前記複数の実施行為の内容及び前記実施順序を特定するための実施計画情報を格納する実施計画情報格納手段と、前記実施計画の実施履歴に関する実施履歴情報を、前記実施対象に関する実施対象情報あるいは前記実施者に関する実施者情報と共に、当該実施計画に対応する前記実施計画情報に関連付けて格納する実施履歴情報格納手段と、前記実施対象情報、前記実施者情報、あるいは前記実施計画情報が特定された場合に、当該特定された情報に対応する他の情報を前記実施履歴情報格納手段から取得する情報取得手段とを備えたことを特徴とする。

また、請求項２に記載の本発明は、請求項１に記載の本発明において、前記実施履歴情報格納手段には、前記実施計画における前記実施対象の属性を特定するための属性情報と、前記実施計画における実施結果の良否を特定する良否情報とが、当該実施計画に対応する前記実施計画情報に関連付けて格納され、前記情報取得手段は、前記実施計画情報が特定された場合に、当該特定された実施計画情報に対応する前記属性情報及び前記良否情報を前記実施履歴情報格納手段から取得し、当該取得した情報に基づいて、前記実施計画の実施結果が良好であった実施対象の属性又は前記実施計画の実施結果が良好でなかった実施対象の属性に関する情報を取得することを特徴とする。

また、請求項３に記載の本発明は、請求項２に記載の本発明において、前記情報取得手段は、前記実施計画情報が特定された場合に、当該実施計画情報にて特定される実施計画とは異なる推奨実施計画を所定方法にて設定し、当該設定された推奨実施計画の実施計画情報に対応する前記属性情報及び前記良否情報を前記実施履歴情報格納手段から取得し、当該取得した情報に基づいて、前記推奨実施計画の実施結果が良好であった実施対象の属性に関する情報を取得することを特徴とする。

また、請求項４に記載の本発明は、請求項１から３のいずれか一項に記載の本発明において、前記実施履歴情報格納手段には、前記実施計画の実施目的を特定するための実施目的情報と、前記実施計画の実施に要する期間又は料金を特定するための所要情報とが、当該実施計画に対応する前記実施計画情報に関連付けて格納され、前記情報取得手段は、前記実施目的情報が特定された場合に、当該特定された実施目的情報に対応する所要情報を前記実施履歴情報格納手段から取得することを特徴とする。

また、請求項５に記載の本発明は、請求項４に記載の本発明において、前記実施履歴情報格納手段には、前記実施目的情報及び前記所要情報が、前記実施者を特定する実施者情報に関連付けて格納され、前記情報取得手段は、前記実施目的情報が特定された場合に、当該特定された実施目的情報に対応する所要情報を、当該特定された実施目的情報に対応する実施者情報にて特定される実施者毎に取得することを特徴とする。

また、請求項６に記載の本発明は、請求項４又は５に記載の本発明において、前記実施履歴情報格納手段には、前記実施目的情報及び前記所要情報が、前記実施対象の属性を特定するための属性情報に関連付けて格納され、前記情報取得手段は、前記実施目的情報が特定された場合に、当該特定された実施目的情報に対応する所要情報を、当該特定された実施目的情報に対応する属性情報にて特定される属性毎に取得することを特徴とする。

また、請求項７に記載の本発明は、実施対象に対して実施者によって実施され得る複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画を管理するための実施計画方法をコンピュータに実行させるためのプログラムであって、前記コンピュータには、前記複数の実施行為の内容及び前記実施順序を特定するための実施計画情報を格納する実施計画情報格納手段と、前記実施計画の実施履歴に関する実施履歴情報を、前記実施対象に関する実施対象情報あるいは前記実施者に関する実施者情報と共に、当該実施計画に対応する前記実施計画情報に関連付けて格納する実施履歴情報格納手段とが設けられており、前記コンピュータに、前記実施対象情報、前記実施者情報、あるいは前記実施計画情報が特定された場合に、当該特定された情報に対応する他の情報を前記実施履歴情報格納手段から取得する情報取得ステップを実行させることを特徴とする。

請求項１、７に記載の本発明によれば、実施対象情報、実施者情報、あるいは実施計画情報が特定された場合に、当該特定された情報に対応する他の情報を取得できるので、例えば、所望の実施結果を得るために適した実施対象を特定するための実施対象情報を取得したり、所望の実施結果を得るために適した実施者を特定するための実施者情報を取得したり、あるいは、所望の実施結果を得るために適した実施計画を特定するための実施計画情報を取得することができ、これらの情報を用いて、実施計画の立案や評価を容易かつ客観的に行うことが可能となる。

請求項２に記載の本発明によれば、実施計画の実施結果が良好であった実施対象の属性や、実施計画の実施結果が良好でなかった実施対象の属性に関する情報を取得できるので、自己が立案した実施計画を適用しようとしている実施対象の属性が、これら取得した属性に合致しているか否かを判定することが可能となる。従って、当該実施計画を適用しようとしている実施対象に対して、当該実施計画が適しているか否かを判定することが可能となる。

請求項３に記載の本発明によれば、実施計画情報にて特定される実施計画とは異なる推奨実施計画に対して、実施結果が良好であった実施対象の属性に関する情報を取得できるので、自己が立案した実施計画以外の実施計画に適した実施対象の属性を把握することが可能となる。従って、当該実施計画を適用しようとしている実施対象の属性が、当該取得した実施対象の属性に合致する場合には、自己が立案した実施計画に代えて、当該推奨実施計画を採用する等、実施計画を修正することが容易となる。

請求項４に記載の本発明によれば、実施目的情報に対応する所要情報を取得できるので、実施計画の実施に要する期間又は料金を容易に把握でき、実施計画の採用基準として考慮することができる。

請求項５に記載の本発明によれば、実施計画の実施に要する期間又は料金を実施者毎に把握できるので、実施計画に適した実施者の選定基準とすることができる。

請求項６に記載の本発明によれば、実施計画の実施に要する期間又は料金を実施対象の属性毎に把握できるので、実施計画に適した実施対象の選定基準とすることができる。

以下に添付図面を参照して、この発明に係る実施計画管理システム及び実施計画管理プログラムを実施するための最良の形態について詳細に説明する。まず、〔I〕本実施の形態の基本概念を説明した後、〔II〕本実施の形態の具体的内容について説明し、〔III〕最後に本実施の形態に対する変形例について説明する。ただし、本実施の形態によって本発明が限定されるものではない。

〔I〕本実施の形態の基本概念
まず、本実施の形態の基本概念について説明する。本実施の形態に係る実施計画管理システム（以下「本システム」）及び実施計画管理プログラム（以下「本プログラム」）は、実施対象に対する実施行為を実施する実施者に対して、当該実施行為を標準化された内容及び実施順序で実施するための実施計画の実行管理を支援するためのシステム及びプログラムである。

本システム及び本プログラムは、広範な分野に適用可能であり、概念的には、当該分野における形式知（具体的には、実施対象に対して実施者が実施する複数の実施行為の内容と、これら複数の実施行為の相互間の実施順序）を構造化することで可視化が可能な全ての分野に適用可能である。この適用分野の例としては、「医療分野」、「防災分野」、「教育分野」を挙げることができ、この適用分野に応じて、「実施対象」、「実施目的」、「実施者」、「実施行為」、「実施計画」の具体的内容は異なり得る。例えば、医療分野では、実施対象＝患者、実施目的＝治療すべき疾患、実施者＝医師（又は病院の如き医療機関）、実施行為＝医療行為、実施計画＝医療計画である。同様に、防災分野では、実施対象＝被災者や被災物、実施目的＝防止すべき災害やテロ行為、実施者＝救援者、実施行為＝救援行為、実施計画＝救援計画が該当し、教育分野では、実施対象＝生徒、実施目的＝教育対象とする能力や科目、実施者＝教師、実施行為＝教育行為、実施計画＝教育計画が該当する。以下では、本システム及び本プログラムを医療分野に適用した場合について説明する。

図１は、本実施の形態に係る実施計画管理システムの全体構成を概念的に示す説明図である。この図１に示すように、統合支援センター１に設置された作成サーバ１０及び管理サーバ２０と、複数の病院の各々に設置された端末３０と、患者の自宅等の任意の場所に設置された端末４０とが、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）やインターネットの如きネットワーク３を介して相互に通信可能に接続されている。また、統合支援センター１の内部では、作成サーバ１０と管理サーバ２０とが、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）の如きネットワーク４を介して相互に通信可能に接続されている。

本実施形態では、上述の特許文献１に全部又は一部が開示された「患者状態適応型パスシステム（ＰＣＡＰＳ：Ｐａｔｉｅｎｔ Ｃｏｎｄｉｔｉｏｎ Ａｄａｐｔｉｖｅ Ｐａｔｈ Ｓｙｓｔｅｍ）（登録商標）」を利用する。この患者状態適応型パスシステムは、患者の初期状態から最終目標状態に至る臨床経路を示す俯瞰的なモデルであり、この臨床経路を、「患者状態」を基軸とする複数の「目標状態」を相互にリンクして視覚化したものであって、具体的には「プロセスチャート（臨床プロセスチャート）」と「ユニットシート」の２つのツールを用いて構成される。

図２には、これらプロセスチャート及びユニットシートの基本構成モデルを示す。プロセスチャートとは、患者の目標状態毎に形成された実施行為単位（医療の質を管理するために適切な大きさに設定された単位）である「ユニット（プロセス）」を連結することで構成される臨床経路の俯瞰図であり、疾患毎に構成され、当該疾患を有する患者の初期状態から最終目標状態に至る間に想定されるすべての臨床状態を包含する。各ユニットは「実行エレメント」と「判断エレメント」とから構成されている。実行エレメントは、患者状態を当該ユニットの目標状態に達するように組み込まれた実施業務を実行していく行為を示し、判断エレメントは、患者状態が当該ユニットの目標状態に達したか否かを判断する行為を示す。そして、各実行エレメントと、当該各実行エレメントの直後の判断エレメントとを、視覚的に表示する手段として「ユニットシート」が構成される。

このユニットシートの表示画面例を図３に示す。具体的にはユニットシートは、「患者ＩＤ」、「ユニットＩＤ」、「医療行為(実施行為）」、「患者状態」、「目標状態」、「ユニット移行ロジック」、「条件付き指示」、「離脱条件」を含む。患者ＩＤは、当該ユニットシートが適用されている患者を一意に特定するための識別情報である。ユニットＩＤは、当該ユニットシートに対応するユニットを一意に特定するための識別情報である。医療行為は、当該ユニットシートに対応する実行エレメントにおいて実行すべき医療行為の項目や内容を記述した情報であり、例えば、医行為、ケア行為、及び調整行為を含む。患者状態は、当該ユニットシートに対応するユニットにおいて注目すべき患者状態の内容を記述した情報である。ユニット移行ロジックは、当該ユニットシートに対応するユニットから次順のユニットに移行するときの条件及び移行先のユニットシートに対応するユニットＩＤを記述した情報である。条件付き指示は、当該ユニットにおける医療行為中に発生した患者状態に早急に対応するための指示内容を含んで構成されている。離脱条件は、目標状態からの危険な乖離の判断基準を示す遷移状態になった場合には、当該ユニットシートを離脱すべき場合があるため、この離脱を行うための条件を含んで構成されている。

このように構成される「プロセスチャート」及び「ユニットシート」は、作成サーバ１０によるＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）サービスを用いて、各病院の医師等が作成することができる。すなわち、作成サーバ１０及び管理サーバ２０には、このように構成される「プロセスチャート」及び「ユニットシート」を特定するための情報と、これら「プロセスチャート」及び「ユニットシート」の作成を支援するための機能とが設けられており、各病院の医師等は、これら情報及び機能に対して端末３０、４０を介してネットワーク３、４を通じてアクセスし、プロセスチャート及びユニットシートの作成及び利用を行うことができる。

このように作成された「プロセスチャート」及び「ユニットシート」の実施は、管理サーバ２０によって制御される。すなわち、作成された「プロセスチャート」及び「ユニットシート」に関する情報は、管理サーバ２０に格納される。この管理サーバ２０は、プロセスチャートにおける最初のユニットに対応するユニットシートの内容を端末３０を介して医師に対して表示出力等にて提示する。そして、医師が、当該提示されたユニットシートに含まれる医療行為を行い、その後の患者状態を端末３０に入力すると、この患者状態が端末３０を介して管理サーバ２０にて受け付けられる。次いで、管理サーバ２０は、患者状態が当該ユニットの目標状態に達したか否かを判断する。目標状態に達したと判断した場合には、当該最初のユニットの次順のユニットをプロセスチャートに基づいて特定し、当該次順のユニットに対応するユニットシートの内容を端末３０を介して医師に対して提示する。以降同様に、プロセスチャートにて定義された順序に従ったユニットに対応するユニットシートの内容の提示処理と、医師による患者状態の入力を受け付ける処理と、目標状態に達したか否かを判断する判断処理とが繰り返し行われ、プロセスチャートにおける最後のユニットの医療行為が終了することで、一連の処理が終了する。

図４は、プロセスチャートの具体例である。このプロセスチャートは、前立腺全摘除を行う場合の例である。このプロセスチャートは、複数のユニットの各々を構成する実行エレメント及び判断エレメントと、これら各エレメントを相互に接続する線分とを含んでおり、当該線分によって各エレメントの相互間の実施順序が視覚的に示されている。例えば、実行エレメント「Ａ−１ 前立腺全摘除術」の医療行為を実行した後、判断エレメント「ＳＡ−１」において患者状態と目標状態とに基づく判断を行い、この判断結果に応じて、実行エレメント「Ａ−２ 術後急性期」又は実行エレメント「Ｂ−２ 術後急性期」」のいずれかに移行する。図４における各実行エレメントの枠内には、各実行エレメントに対応するユニットの名称及びユニットＩＤを示す。例えば、最初の実行エレメントに対応するユニットの名称は「入院 術前」であり、ユニットＩＤは「Ａ−０」である。

ここで、本実施の形態の特徴の一つは、実施計画の実行結果を履歴情報として蓄積し、この履歴情報を用いて、医師や医師以外の第三者にとって有用な情報を取得する点にある。医師に有用な情報としては、各実施計画に適した患者（以下「適合患者」）又は適していない患者（以下「不適合患者」）の属性を挙げることができ、このような属性を医師に提示することで、医師が実施計画の適否を判断することができる。医師以外の第三者にとって有用な情報としては、各疾患に適した実施計画、医療機関、治療機関、治癒率、治療費を挙げることができ、このような情報を第三者に提示することで、第三者が治療に適した実施計画等を判断することができる。第三者としては、例えば、医療行為を管理する行政機関や、医療行為を受ける患者を挙げることができ、以下では患者に情報を提供する場合を例にとって説明する。

〔II〕本実施の形態の具体的内容
次に、本実施の形態の具体的内容について説明する。以下では、図１に示した実施計画管理システムの各部の構成について説明し、次いで、実施計画管理システムを用いて実行される実施計画管理プログラムの処理内容について説明する。

（構成−作成サーバ）
最初に、図１の作成サーバ１０の構成を説明する。この作成サーバ１０は、患者に対して実施され得る実施行為の内容及び実施順序を含んだ実施計画を作成する実施計画作成支援装置である。機能概念的には、作成サーバ１０は、記憶部１１、制御部１２、及びネットワークインターフェース（以下「ネットワークＩＦ」）１３を、バスにて相互に通信可能に接続して構成されている。

記憶部１１は、各種処理に必要な情報やパラメータを不揮発的に格納する格納手段であり、例えば、ＨＤ（Ｈａｒｄ Ｄｉｓｋ）にて構成される（後述する記憶部２１において同じ）。具体的には、この記憶部１１は、機能概念的に、標準実施計画情報ＤＢ１１ａ、病院情報ＤＢ１１ｂ、及び疾患情報ＤＢ１１ｃを備える。これら各ＤＢに格納される情報の具体的内容については後述する。

制御部１２は、作成サーバ１０の各部を制御する制御手段であり、機能概念的に、実施計画情報生成部１２ａを備える。この実施計画情報生成部１２ａは、プロセスチャート及びユニットシートを特定する実施計画情報を生成する実施計画情報生成手段である。この制御部１２は、具体的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や、このＣＰＵ上で解釈実行される各種のプログラム（ＯＳなどの制御プログラムや、各種の処理手順などを規定したプログラム）、及び、所要プログラムや所要データを格納するためのキャッシュメモリを備えて構成される（後述する制御部２２において同じ）。このＣＰＵ上で解釈実行される各種のプログラムには本プログラムが含まれ、本プログラムは、例えば、ＣＤ−ＲＯＭやＤＶＤを含む任意の記憶媒体に記憶された後、インストールされて記憶部１１に不揮発的に記憶され、ＣＰＵにて解釈実行されることで制御部１２の実質的機能を構成する。

ネットワークＩＦ１３は、ネットワーク３、４を介した通信を行うための通信手段であり、例えばネットワークボードとして構成される（後述するネットワークＩＦ２３において同じ）。このネットワークＩＦ１３を介して端末３０、４０からの情報入力の受け付けが行われることから、当該ネットワークＩＦ１３は実施計画入力手段として機能する。また、このネットワークＩＦ１３を介して各種の情報の出力が行われることから、当該ネットワークＩＦ１３は出力手段として機能する。

（構成−管理サーバ）
次に、管理サーバ２０の構成を説明する。この管理サーバ２０は、作成サーバ１０にて作成された実施計画の実施を管理する実施計画制御装置である。機能概念的には、管理サーバ２０は、記憶部２１、制御部２２、及びネットワークＩＦ２３を、バスにて相互に通信可能に接続して構成されている。

記憶部２１には、機能概念的に、患者情報ＤＢ２１ａ、実施計画情報ＤＢ２１ｂ、及び実施履歴情報ＤＢ２１ｃを備える。これら各ＤＢに格納される情報の具体的内容については後述する。

制御部２２は、管理サーバ２０の各部を制御する制御手段であり、機能概念的に、実施計画情報生成部２２ａ及び実施計画管理部２２ｂを備える。実施計画情報生成部２２ａは、作成サーバ１０と共に実施計画の生成を支援する実施計画生成支援手段であると共に、実施計画の実行履歴に基づいて所要の情報を取得するもので、特許請求の範囲における情報取得手段に対応する。実施計画管理部２２ｂは、実施計画の実行を管理する実施計画管理手段であると共に、実施計画の実行履歴を蓄積する実施履歴蓄積手段である。

（構成−端末）
各端末３０、４０は、医師や患者が管理サーバ２０に対して入出力を行うための端末装置である。この端末３０、４０は、管理サーバ２０との通信機能や各種情報の入出力機能を有する限りにおいて、公知のパーソナルコンピュータと同様に構成できるために、その詳細な説明は省略する。

（構成−データベースの具体的内容−作成サーバ）
次に、作成サーバ１０及び管理サーバ２０の各ＤＢの具体的内容について説明する。ただし、以下の構成例では本実施の形態に係る情報のみを格納する例を示し、実際には以下に説明する情報以外の任意の情報を各ＤＢに格納することができ、あるいは一部の情報については適宜省略することもる。また、各ＤＢに格納される情報のうち、同一名称の情報については、特記する場合を除いて相互に同一の内容であるものとし、重複説明は行わないものとする。

まず、作成サーバ１０の各ＤＢの具体的内容について説明する。図１の標準実施計画情報ＤＢ１１ａは、患者に対して実施すべき標準的な実施行為及び実施順序を特定するための情報（標準実施計画情報）を格納する手段である。この標準実施計画情報は、図５に例示するように、項目「疾患ＩＤ」、項目「ユニットＩＤ」、項目「医療行為(実施行為）」、項目「患者状態」、項目「目標状態」、項目「ユニット移行ロジック」、項目「条件付き指示」、項目「離脱条件」、及び項目「標準滞在日数」に対応する情報を相互に関連付けて構成されている。項目「疾患ＩＤ」に対応する情報は、各実施計画に対応する各疾患を一意に識別するための識別情報である。項目「標準滞在日数」に対応する情報は、各ユニットの標準的な滞在日数（当該ユニットに移行してから次順のユニットへ移行するまでの日数）である。その他の各項目に対応する情報は、図３の表示画面の説明において述べた通りである。

この標準実施計画情報を格納する方法及びタイミングは任意であるが、例えば、当該標準実施計画情報を、医師のヒアリング等に基づいて標準化することで決定し、作成サーバ１０に接続した図示しない管理用端末を介して標準実施計画情報ＤＢ１１ａに予め格納しておくことができる。この標準実施計画情報の標準化は、必ずしも硬直的なものではなく、各医療機関や各患者の実情に合致するように、各医療機関や各医師が端末３０を用いて任意の内容にカスタマイズできるようにしてもよい。なお、これら各情報の具体的な記述構造としては、図５に示した構成例以外の任意の構造を採用することができ、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式により、タグを用いて各情報の意味を構造化することができる。

図１の病院情報ＤＢ１１ｂは、各病院に関する情報（病院情報）を格納する病院情報格納手段である。この病院情報は、特許請求の範囲における実施者情報に対応するもので、図６に例示するように、項目「病院ＩＤ」、項目「病院名」、項目「住所」、項目「分類」、及び項目「ベッド数」を相互に関連付けて構成されている。項目「病院ＩＤ」に対応する情報は、各病院を一意に識別するための識別情報である。項目「病院名」に対応する情報は、各病院の名称である。項目「住所」に対応する情報は、各病院の住所である。項目「分類」に対応する情報は、各病院の分類（ここでは急性期と慢性期のいずれか）を示す情報である。項目「ベッド数」に対応する情報は、各病院のベッドの総数である。これら項目「住所」、項目「分類」、及び項目「ベッド数」に対応する情報は、病院の属性情報である。なお、実施者情報としては、医師や医療機関の設備等の情報を用いてもよい。

図１の疾患情報ＤＢ１１ｃは、各実施計画による治療の対象になる疾患に関する情報（疾患情報）を格納する疾患情報格納手段である。この疾患情報は、特許請求の範囲における実施目的情報に対応するもので、図７に例示するように、項目「疾患ＩＤ」、項目「疾患名」、及び項目「症状」を相互に関連付けて構成されている。項目「疾患ＩＤ」に対応する情報は、各疾患を一意に識別するための識別情報である。項目「疾患名」に対応する情報は、各疾患の名称（病名）である。項目「症状」に対応する情報は、各疾患において患者に現われる代表的な病状である。

（構成−データベースの具体的内容−管理サーバ）
次に、図１の管理サーバ２０の各ＤＢの具体的内容について説明する。患者情報ＤＢ２１ａは、実施行為の対象である患者に関する情報（患者情報）を格納する手段である。この患者情報は、特許請求の範囲における実施対象情報に対応するもので、図８に例示するように、項目「患者ＩＤ」、項目「年齢」、項目「性別」、項目「住所」、及び項目「疾患ＩＤ」に対応する情報を相互に関連付けて構成されている。項目「患者ＩＤ」に対応する情報は、各実施計画の対象となる患者を一意に識別するための識別情報である。項目「年齢」、項目「性別」、項目「住所」に対応する情報は、それぞれ各患者の年齢、性別、住所であり、特許請求の範囲における属性情報に対応する。項目「疾患ＩＤ」に対応する情報は、各患者の各疾患を一意に識別するための情報であり、その内容は図７の項目「疾患ＩＤ」に対応する情報と共通である。

図１の実施計画情報ＤＢ２１ｂは、患者に対して実施すべき実施行為及び実施順序を特定するための情報（実施計画情報）を格納する実施計画情報格納手段であり、特許請求の範囲の実施計画情報格納手段に対応する。この実施計画情報は、図９に例示するように、項目「患者ＩＤ」、項目「医師ＩＤ」、項目「疾患ＩＤ」、項目「ユニットＩＤ」、項目「医療行為（実施行為）」、項目「患者状態」、項目「目標状態」、項目「ユニット移行ロジック」、項目「条件付き指示」、項目「離脱条件」、及び項目「標準滞在日数」に対応する情報を相互に関連付けて構成されている。これら各項目に対応する情報は、図５から図８の同一項目に対応する情報と共通である。ここでは、一つの患者ＩＤ及び疾患ＩＤに対して複数のユニットＩＤを関連付けることで、当該患者ＩＤにて特定される患者に対して、当該疾患ＩＤにて特定される疾患を治療するための複数の実施行為が特定される。この実施行為の実施順序は図示しない任意の情報にて特定される。例えば、後述する実施計画作成処理においてフローチャートにて指定された各ユニットの配置をＸＭＬ形式のデータとして構造化することで特定され、あるいはフローチャートにおける描画データとして特定されて、当該実施計画情報ＤＢ２１ｂに格納される。

図１の実施履歴情報ＤＢ２１ｃは、実施計画の実施履歴に関する情報（実施履歴情報）を格納するもので、特許請求の範囲における実施履歴情報格納手段に対応する。この実施履歴情報は、図１０に例示するように、項目「患者ＩＤ」、項目「病院ＩＤ」、項目「疾患ＩＤ」、項目「移行経路及び滞在日数」、項目「実施結果」、及び項目「治療費」に対応する情報を相互に関連付けて構成されている。項目「患者ＩＤ」に対応する情報は、各実施計画の対象となる患者を一意に識別するための識別情報であり、その内容は図８の項目「患者ＩＤ」に対応する情報（実施対象情報の一部）と共通であり、この情報に基づいて患者情報ＤＢ２１ａを参照することによって、患者の属性情報を取得できる。項目「病院ＩＤ」に対応する情報は、各実施計画が実施された各病院を一意に識別するための識別情報であり、その内容は図６の項目「病院ＩＤ」に対応する情報（実施者情報の一部）と共通であって、この情報に基づいて病院情報ＤＢ１１ｂを参照することによって、病院の属性情報を取得できる。項目「疾患ＩＤ」に対応する情報は、各実施計画における治療の対象となった各疾患を一意に識別するための識別情報であり、その内容は図７の項目「疾患ＩＤ」に対応する情報（実施目的情報の一部）と共通である。

項目「移行経路及び滞在日数」に対応する情報は、各実施計画が各病院において実際に実施された場合における、プロセスチャート内での各ユニットの移行経路を特定するための情報及び各ユニットの実際の滞在日数を特定するための情報である。図１０の例では、実施された各ユニットのユニットＩＤが実施順に記載されることで移行経路が特定されており、例えば「Ａ−０（１），Ａ−１（１），Ａ−２（２）」との情報によって、最初に実施されたユニットは「ユニットＩＤ＝Ａ−０のユニット」、次に実施されたユニットは「ユニットＩＤ＝Ａ−１のユニット」、３番目に実施されたユニットは「ユニットＩＤ＝Ａ−２のユニット」であることが判る。また図１０の例では、各ユニットＩＤの直後に付された括弧内の数値が、当該ユニットの実際の滞在日数（当該ユニットの実施行為を完了するまでに要した日数）となっており、例えば「Ａ−０（１）」との情報によって、「ユニットＩＤ＝Ａ−０のユニット」の滞在日数は１日であったことが判る。ただし、これら移行経路や滞在日数を特定するための情報の具体的な構成は任意に変更することができる。このように滞在日数を特定するための情報は、特許請求の範囲における所要情報の一部に対応する。

項目「実施結果」に対応する情報は、各実施計画の実施結果として、実施対象が所望の状態になったか否か（医療計画の場合には患者の疾患が治癒したか否か）を示す情報であり、特許請求の範囲における良否情報に対応するものであって、この例では、「良」又は「否」のいずれかの情報が格納されている。ただし、この良否の判定は他の情報に基づいて行なうこともでき、例えば、項目「移行経路及び滞在日数」に対応する情報として格納された滞在日数を積算し、この滞在日数が所定値より小さい場合には実施結果＝良（短期間でスムーズに治癒した）、滞在日数が所定値より大きい場合には実施結果＝否（治癒に長期間を要した）と判定してもよく、この場合には、項目「結果良否」及びこれに対応する情報を省略してもよい。項目「治療費」に対応する情報は、各実施計画の実施に要した治療費の合計を示す情報であり、特許請求の範囲における所要情報の一部に対応する。

（処理）
次に、本装置において本プログラムを実行すること等によって行われる処理（以下、本処理）について説明する。なお、以下の本処理の説明において、制御主体を特記しない処理については、作成サーバ１０の制御部１２又は管理サーバ２０の制御部２２にて実行されるものとし、情報の取得元や取得経路を特記しない場合については、公知のタイミング及び公知の方法にて、作成サーバ１０の記憶部１１又は管理サーバ２０の記憶部２１に予め格納されており、あるいは、端末３０、４０を介して医師や患者によって手入力されたものとする。

本処理は、実施計画情報生成処理、実施計画管理処理、及び実施履歴活用処理に大別される。実施計画情報生成処理は実施計画を特定する実施計画情報を生成する処理で、実施計画管理処理は実施計画を実行してその結果を蓄積する処理、実施履歴活用処理は実施計画の実行結果に基づいて所要の情報を取得する処理である。以下、各処理について順次説明する。

（処理−実施計画情報生成処理）
まず実施計画情報生成処理について説明する。図１１は、実施計画情報生成処理のフローチャートである。最初に、各病院の医師は、端末３０を介して所定方法にて管理サーバ２０にアクセスして実施計画の作成要求を送信する。この際、医師は、自己が属する病院に予め割り当てられた病院ＩＤ、実施計画の対象になる患者の患者ＩＤ、及び実施計画の対象になる患者の疾患に予め割り当てられた疾患ＩＤを端末３０に入力する。

一方、管理サーバ２０の実施計画情報生成部２２ａは、作成要求の受信の有無を監視しており（ステップＳＡ−１）、作成要求を受信すると共に（ステップＳＡ−１，Ｙｅｓ）、病院ＩＤ、患者ＩＤ、及び疾患ＩＤを受信した場合には（ステップＳＡ−２）、作成サーバ１０の実施計画情報生成部１２ａを介して、当該疾患ＩＤに対応する標準実施計画情報を標準実施計画情報ＤＢ１１ａから取得し、この標準実施計画情報の画面データを端末３０に送信する（ステップＳＡ−３）。

この画面データは、端末３０に予めインストールされた汎用又は専用のブラウザソフトウェアによって解釈され、当該標準実施計画情報が端末３０のモニタに表示される（端末３０、４０の以下の画面表示において同じ）。例えば、予め構造化されて標準実施計画情報ＤＢ１１ａに格納された標準実施計画情報が、その構造に応じたツリー構造にて階層化してプロセスチャートとして表示される。あるいは、このプロセスチャートのユニットを医師が端末３０を介して選択すると、当該選択されたユニットに対応するユニットシートが表示される。そして、医師は、例えばプロセスチャートの表示画面において、当該プロセスチャートに含まれるユニットを実施したい順序に沿って端末３０を介して選択することで、ユニットの移行経路を指定することができる。

ここで、管理サーバ２０の実施計画情報生成部２２ａは、患者適否情報取得処理を行う（ステップＳＡ−４）。この患者適否情報取得処理は、実施計画に好適な患者又は不適な患者に関する情報を取得するための処理である。この患者適否情報取得処理のフロチャートを図１２に示す。実施計画情報生成部２２ａは、その時点で選択されている実施計画（ここでは標準実施計画情報にて特定される実施計画）と同一の実施計画に対応する実施履歴情報を実施履歴情報ＤＢ２１ｃから取得する（ステップＳＢ−１）。ここで、同一の実施計画に対応する実施履歴情報とは、例えば、先に端末３０から管理サーバ２０に送信された疾患ＩＤと同一の疾患ＩＤを有する実施履歴情報であって、当該時点で指定されている実施計画の移行経路と同一の移行経路を有する実施履歴情報である。すなわち、同一の疾患ＩＤを有する実施履歴情報であっても、医師の修正等によって異なる移行経路を取り得るが、ここでは移行経路が同一の実施履歴情報のみを取得する。

次いで、実施計画情報生成部２２ａは、取得した実施履歴情報の中で、実施結果として「良」が含まれている実施履歴情報と、実施結果として「否」が含まれている実施履歴情報とをそれぞれ特定し（ステップＳＢ−２）、これら特定した実施履歴情報のそれぞれに対してステップＳＢ−３〜ＳＢ−５の処理を行う。すなわち、実施結果として「良」が含まれている実施履歴情報に含まれる患者ＩＤを取得し（ステップＳＢ−３）、当該取得した患者ＩＤに対応する患者情報を患者情報ＤＢ２１ａから取得し（ステップＳＢ−４）、当該取得した患者情報に含まれる属性情報（ここでは、年齢、性別、住所）の共通項を抽出する（ステップＳＢ−５）。例えば、属性情報として「年齢＝６７、性別＝男性、住所＝東京都文京区」を含む患者情報と、属性情報として「年齢＝５５、性別＝男性、住所＝東京都台東区」を含む患者情報があった場合、共通項として、「年齢＝５５〜６７」、「性別＝男性」、「住所＝東京都」を抽出する。この抽出ロジックとしては、例えば公知の自然言語解析ロジックや言語辞書を適用して情報の包含関係を判定することができる。このような処理を経ることで、当該時点で指定されている実施計画に対する適合患者の属性を取得することができる。また同様に、実施結果として「否」が含まれている実施履歴情報に含まれる患者ＩＤを取得し（ステップＳＢ−３）、当該取得した患者ＩＤに対応する患者情報を患者情報ＤＢ２１ａから取得し（ステップＳＢ−４）、当該取得した患者情報に含まれる属性情報（ここでは、年齢、性別、住所）の共通項を抽出する（ステップＳＢ−５）。このような処理を経ることで、当該時点で指定されている実施計画に対する不適合患者の属性を取得することができる。

さらに、実施計画情報生成部２２ａは、当該時点で指定されている実施計画の移行経路とは異なる移行経路（以下「推奨移行経路」）を自動的に設定し（ステップＳＢ−６）、当該推奨移行経路に対してステップＳＢ−１〜ＳＢ−５と同様の処理を行うことで、当該患者ＩＤを含む患者情報に含まれる属性情報の共通項を抽出する（ステップＳＢ−７〜ＳＢ−１１）。ここで、推奨移行経路としては、例えば、先に端末３０から管理サーバ２０に送信された疾患ＩＤと同一の疾患ＩＤを有する実施履歴情報の中で、これまでに最も適応されている移行経路を設定することができる。また、ステップＳＢ−８では、実施結果として「良」が含まれている実施履歴情報に含まれる患者ＩＤのみの特定を行う。このような処理を経ることで、推奨移行経路に対する適合患者の属性を取得することができる。

そして、実施計画情報生成部２２ａは、ステップＳＢ−５及びＳＢ−１１で取得した情報を出力する画面データを生成し、当該画面データを端末３０に送信する（ステップＳＢ−１２）。この結果、情報出力画面が端末３０のモニタに表示される。この情報出力画面の表示例を図１３に示す。このような情報出力画面を見ることで、医師は、当該時点で指定されている実施計画の移行経路に対する適合患者の属性と不適合患者の属性を把握することができるので、自己の患者の属性が適合患者と不適合患者のいずれに該当するのかを判定し、その結果に応じて、当該時点で指定されている実施計画の移行経路をそのまま自己の患者に採用すべきか否かを客観的に判断できる。また同時に、医師は、推奨移行経路に対する適合患者の属性を把握することができるので、自己の患者の属性が当該適合患者の属性に合致する場合には、当該時点で指定されている実施計画の移行経路を推奨移行経路に変更すべきであることを把握できる。

そして、図１１の処理に戻り、医師は、これらの情報を参考にした上で、当該時点で指定されている実施計画を修正するか否かを判断し、修正する場合には、端末３０の入力装置を介して所定方法で修正を行う。このように修正が行われると(ステップＳＡ−５，Ｙｅｓ）、当該修正後の実施計画に対してステップＳＡ−３及びＳＡ−４が再び行われるので、医師は新たな情報を参考にした上で、実施計画が自己の患者に適しているか否かを判断できる。以降、自己の患者に適した実施計画となるまで同様の処理を繰り返し、医師が実施計画の修正不要と判断した場合には、端末３０の入力装置を介して修正不要の旨を指示する。修正不要の旨を受信した場合(ステップＳＡ−５，Ｎｏ）、実施計画情報生成部２２ａは、当該時点で指定されている実施計画を特定するための実施計画情報を、ステップＳＡ−２で取得された病院ＩＤ、患者ＩＤ、及び疾患ＩＤと共に、実施計画情報ＤＢ２１ｂに格納して（ステップＳＡ−６）、実施計画情報生成処理を終了する。

（処理−実施計画管理処理）
次に、実施計画管理処理について説明する。図１４は、実施計画管理処理のフローチャートである。先の関係性情報生成処理の終了後、任意のタイミングで、医師が端末３０を介して診療を行いたい患者の患者ＩＤを入力することにより医療プロセスの開始を指示すると（ステップＳＣ−１，Ｙｅｓ）、管理サーバ２０の実施計画管理部２２ｂは、当該患者ＩＤに対応する実施計画情報を実施計画情報ＤＢ２１ｂから取得し、当該実施計画情報をプロセスチャート又はユニットシートとして当該端末３０のモニタに出力する（ステップＳＣ−２）。従って、医師は、患者の疾患に対応する実施行為やその実施手順を確認し、標準化された内容及び手順にて医療行為を行うことができる。

医師は、各ユニットシートに表示されている医療行為を実施する毎に、当該医療行為が行われた患者の状態を、端末３０を介して管理サーバ２０に入力する（ステップＳＣ−３）。管理サーバ２０の実施計画管理部２２ｂは、入力された患者状態と、実施計画情報における当該ユニットシートの目標状態とを比較して、患者状態が目標状態に達したか否かを判定する（ステップＳＣ−４）。そして、患者の状態が目標状態に達したと判定された場合（ステップＳＣ−４，Ｙｅｓ）、実施計画管理部２２ｂは、実施計画情報によって規定される次順のユニットのユニットシートの内容を端末３０に送信してモニタに表示させる（ステップＳＣ−８）。このユニットシートの内容を端末３０を介して閲覧することで、医師は、患者状態に合致したユニットシートの内容を閲覧でき、医療行為の実施内容を確認できる。

一方、ステップＳＣ−４において患者状態が目標状態に達していないと判定された場合（ステップＳＣ−４，Ｎｏ）、実施計画管理部２２ｂは、次のユニットシートに移行することなく、次の患者状態の入力が受け付けられるまで待機する。ここで、患者状態が目標状態から大きく乖離して離脱条件に合致した場合には、当該ユニットを離脱する（ステップＳＣ−５，Ｙｅｓ）。この離脱後の行為の特定方法としては種々の方法を取り得るが、ここでは、実施計画情報に含まれる各ユニットシートの内容を端末３０に順次提示し（ステップＳＣ−６）、この中から離脱先として最適だと思われるユニットシートを医師に選択させ、選択があった場合には（ステップＳＣ−７，Ｙｅｓ）、このユニットシートを表示し（ステップＳＣ−８）、それ以降は、当該ユニットシートを開始点として、当該ユニットシートに規定されるユニット移行ロジックに基づいて移行する。

このように患者状態の入力が行われた場合や、ユニットの移行や離脱が行われた場合、実施履歴管理部２２ｂは、その都度、実施履歴情報を実施履歴情報ＤＢ２１ｃに格納する（ステップＳＣ−９）。例えば、ユニットの移行が行われた場合には、当該移行元のユニットＩＤ及び当該移行先のユニットのユニットＩＤを移行経路として実施履歴情報ＤＢ２１ｃに格納すると共に、当該移行元のユニットから当該移行先のユニットに移行するまでの経過日数を滞在日数として実施履歴情報ＤＢ２１ｃに格納する。なお、各実施計画における全てのユニットが修了した場合には、当該実施計画の実施結果の良否及びそれまでに要した治療費の総額が、医師やその他の病院職員によって端末３０を介して実施履歴情報ＤＢ２１ｃに格納される。あるいは、各実施計画における全てのユニットが修了しなかった場合（治療途中で患者が死亡した場合等）には、治癒しなかった旨の情報が、医師等によって実施結果として実施履歴情報ＤＢ２１ｃに格納される。これにて実施計画管理処理が終了する。この実施計画管理処理によって蓄積された実施履歴情報は、その後の実施計画管理処理や実施履歴活用処理において利用される。

（処理−実施履歴活用処理）
最後に、実施履歴活用処理について説明する。図１５は、実施履歴活用処理のフローチャートである。最初に、各患者は、端末４０を介して所定方法にて管理サーバ２０にアクセスして実施履歴の送信要求を送信する。この際、患者は、自己の病気の疾患名又は症状を端末４０に入力する。

一方、管理サーバ２０の実施計画情報生成部２２ａは、送信要求の受信の有無を監視しており（ステップＳＤ−１）、送信要求と共に疾患名又は病状を受信した場合には（ステップＳＤ−１，Ｙｅｓ）、当該疾患名又は病状に対応する疾患ＩＤを作成サーバ１０の疾患情報ＤＢ１１ｃから取得し（ステップＳＤ−２）、この疾患ＩＤに対応する実施履歴情報を実施履歴情報ＤＢ２１ｃから取得する（ステップＳＤ−３）。

次いで、実施計画情報生成部２２ａは、ステップＳＤ−３において取得した実施履歴情報の中から、病院毎の「治癒率」、「平均の治療期間」、及び「平均の治療費」を算出する（ステップＳＤ−４）。具体的には、取得した実施履歴情報に含まれる病院ＩＤに着目し、病院ＩＤ毎に実施履歴情報を分けた後、実施結果＝良を含む実施履歴情報の総数と、実施結果＝否又は治癒しなかった旨の情報を含む実施履歴情報の総数をそれぞれ算出し、これら総数の比率を算出し、当該算出結果を「治癒率」とする。また、病院ＩＤ毎に実施履歴情報を分けた後、各実施履歴情報毎に滞在日数を積算し、この滞在日数の平均値を算出し、当該算出結果を「平均の治療期間」とする。さらには、病院ＩＤ毎に実施履歴情報を分けた後、各実施履歴情報に含まれる治療費の平均値を算出し、当該算出結果を「平均の治療費」とする。

また、実施計画情報生成部２２ａは、ステップＳＤ−３において取得した実施履歴情報の中から、患者の属性毎の「治癒率」、「平均の治療期間」、及び「平均の治療費」を算出する（ステップＳＤ−５）。具体的には、取得した実施履歴情報に含まれる患者ＩＤを取得し、当該取得した患者ＩＤに対応する属性を患者情報ＤＢ２１ａから取得し、当該取得した属性を所定基準でグルーピングする。例えば、「年齢」を複数階層にグルーピングする。そして、このグルーピングした属性に基づいて、ステップＳＤ−３において取得した実施履歴情報を区分し、各区分毎にステップＳＤ−４と同様の処理を行うことで、患者の属性毎の「治癒率」、「平均の治療期間」、及び「平均の治療費」を算出する。

そして、実施計画情報生成部２２ａは、ステップＳＤ−４及びＳＤ−５で取得した情報を出力する画面データを生成し、当該画面データを端末４０に送信する（ステップＳＤ−６）。この結果、情報出力画面が端末４０のモニタに表示される。この情報出力画面の表示例を図１６に示す。このような情報出力画面を見ることで、患者は、自己の病気を治療するために適した病院を把握したり、自己の属性に合致する治癒率等を把握することができる。

（実施の形態の効果）
このように本実施の形態によれば、患者情報、病院情報、あるいは実施計画情報が特定された場合に、当該特定された情報に対応する他の情報を取得できるので、例えば、所望の実施結果を得るために適した患者を特定するための患者情報を取得したり、所望の実施結果を得るために適した病院を特定するための病院情報を取得したり、あるいは、所望の実施結果を得るために適した実施計画を特定するための実施計画情報を取得することができ、これらの情報を用いて、医師による実施計画の立案や、患者による実施計画の評価を、容易かつ客観的に行うことが可能となる。

また本実施の形態によれば、実施計画の実施結果が良好であった患者の属性や、実施計画の実施結果が良好でなかった患者の属性に関する情報を取得できるので、医師にとっては、自己が立案した実施計画を適用しようとしている患者の属性が、これら取得した属性に合致しているか否かを判定することが可能となる。従って、医師にとって、当該実施計画を適用しようとしている実施対象に対して、当該実施計画が適しているか否かを判定することが可能となる。

また本実施の形態によれば、実施計画情報にて特定される実施計画とは異なる推奨実施計画に対して、実施結果が良好であった患者の属性に関する情報を取得できるので、自己が立案した実施計画以外の実施計画に適した患者の属性を把握することが可能となる。従って、当該実施計画を適用しようとしている患者の属性が、当該取得した患者の属性に合致する場合には、自己が立案した実施計画に代えて、当該推奨実施計画を採用する等、医師にとって、実施計画を修正することが容易となる。

また本実施の形態によれば、疾患に対応する治療期間や治療費を取得できるので、実施計画の実施に要する治療期間や治療費を容易に把握でき、実施計画の採用基準として考慮することができる。

また本実施の形態によれば、実施計画の実施に要する治療期間や治療費を病院毎に把握できるので、病院の選定基準とすることができる。

また本実施の形態によれば、実施計画の実施に要する治療期間や治療費を患者の属性毎に把握できるので、実施計画の選定基準とすることができる。

〔III〕本実施の形態に対する変形例
以上、本発明に係る実施の形態について説明したが、本発明の具体的な構成及び手段は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良できる。以下、このような変形例について説明する。

（解決しようとする課題や発明の効果について）
まず、発明が解決しようとする課題や発明の効果は、前記した内容に限定されるものではなく、本発明によって、前記に記載されていない課題を解決したり、前記に記載されていない効果を奏することもでき、また、記載されている課題の一部のみを解決したり、記載されている効果の一部のみを奏することがある。

（構成及び制御について）
また、上記実施の形態で自動的に行われるものとして説明した制御の全部または任意の一部を手動で行っても良く、逆に、手動で行われるものとして説明した制御の全部または任意の一部を公知技術または上述した思想に基づいて自動化しても良い。また、上記実施の形態において示した各構成要素の各機能ブロックの一部又は全部を、ハードワイヤードロジックにて構成しても良い。

（分散や統合について）
また、上述した各電気的構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成できる。例えば、作成サーバ１０と管理サーバ２０とを相互に統合したり、作成サーバ１０や管理サーバ２０の一部の機能を他のサーバに分散配置してもよい。

本発明の実施の形態に係る実施計画管理システムの全体構成を概念的に示す説明図である。 プロセスチャート及びユニットシートの基本構成モデルを示す図である。 ユニットシートの表示画面例を示す図である。 プロセスチャートの具体例を示す図である。 標準実施計画情報の構成例を示す図である。 病院情報の構成例を示す図である。 疾患情報の構成例を示す図である。 患者情報の構成例を示す図である。 実施計画情報の構成例を示す図である。 実施履歴情報の構成例を示す図である。 実施計画情報生成処理のフローチャートである。 患者適否情報取得処理のフローチャートである。 患者適否情報取得処理にて取得された情報の出力画面の表示例を示す図である。 実施計画管理処理のフローチャートである。 実施履歴活用処理のフローチャートである。 実施履歴活用処理にて取得された情報の出力画面の表示例を示す図である。

符号の説明

１ 統合支援センター
３、４ ネットワーク
１０ 作成サーバ
１１、２１ 記憶部
１１ａ 標準実施計画情報ＤＢ
１１ｂ 病院情報ＤＢ
１１ｃ 疾患情報ＤＢ
１２、２２ 制御部
１２ａ、２２ａ 実施計画情報生成部
１３、２３ ネットワークＩＦ
２０ 管理サーバ
２１ａ 患者情報ＤＢ
２１ｂ 実施計画情報ＤＢ
２１ｃ 実施履歴情報ＤＢ
２２ｂ 実施計画管理部
３０、４０ 端末

Claims (7)

1. 実施対象に対して実施者によって実施され得る複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画を管理するための実施計画管理システムであって、
   前記複数の実施行為の内容及び前記実施順序を特定するための実施計画情報を格納する実施計画情報格納手段と、
   前記実施計画の実施履歴に関する実施履歴情報を、前記実施対象に関する実施対象情報あるいは前記実施者に関する実施者情報と共に、当該実施計画に対応する前記実施計画情報に関連付けて格納する実施履歴情報格納手段と、
   前記実施対象情報、前記実施者情報、あるいは前記実施計画情報が特定された場合に、当該特定された情報に対応する他の情報を前記実施履歴情報格納手段から取得する情報取得手段と、
   を備えたことを特徴とする実施計画管理システム。
2. 前記実施履歴情報格納手段には、前記実施計画における前記実施対象の属性を特定するための属性情報と、前記実施計画における実施結果の良否を特定する良否情報とが、当該実施計画に対応する前記実施計画情報に関連付けて格納され、
   前記情報取得手段は、前記実施計画情報が特定された場合に、当該特定された実施計画情報に対応する前記属性情報及び前記良否情報を前記実施履歴情報格納手段を参照して取得し、当該取得した情報に基づいて、前記実施計画の実施結果が良好であった実施対象の属性又は前記実施計画の実施結果が良好でなかった実施対象の属性に関する情報を取得すること、
   を特徴とする請求項１に記載の実施計画管理システム。
3. 前記情報取得手段は、前記実施計画情報が特定された場合に、当該実施計画情報にて特定される実施計画とは異なる推奨実施計画を所定方法にて設定し、当該設定された推奨実施計画の実施計画情報に対応する前記属性情報及び前記良否情報を前記実施履歴情報格納手段から取得し、当該取得した情報に基づいて、前記推奨実施計画の実施結果が良好であった実施対象の属性に関する情報を取得すること、
   を特徴とする請求項２に記載の実施計画管理システム。
4. 前記実施履歴情報格納手段には、前記実施計画の実施目的を特定するための実施目的情報と、前記実施計画の実施に要する期間又は料金を特定するための所要情報とが、当該実施計画に対応する前記実施計画情報に関連付けて格納され、
   前記情報取得手段は、前記実施目的情報が特定された場合に、当該特定された実施目的情報に対応する所要情報を前記実施履歴情報格納手段から取得すること、
   を特徴とする請求項１から３のいずれか一項に記載の実施計画管理システム。
5. 前記実施履歴情報格納手段には、前記実施目的情報及び前記所要情報が、前記実施者を特定する実施者情報に関連付けて格納され、
   前記情報取得手段は、前記実施目的情報が特定された場合に、当該特定された実施目的情報に対応する所要情報を、当該特定された実施目的情報に対応する実施者情報にて特定される実施者毎に取得すること、
   を特徴とする請求項４に記載の実施計画管理システム。
6. 前記実施履歴情報格納手段には、前記実施目的情報及び前記所要情報が、前記実施対象の属性を特定するための属性情報に関連付けて格納され、
   前記情報取得手段は、前記実施目的情報が特定された場合に、当該特定された実施目的情報に対応する所要情報を、当該特定された実施目的情報に対応する属性情報にて特定される属性毎に取得すること、
   を特徴とする請求項４又は５に記載の実施計画管理システム。
7. 実施対象に対して実施者によって実施され得る複数の実施行為の内容と当該複数の実施行為の実施順序とを含んで構成される実施計画を管理するための実施計画方法をコンピュータに実行させるためのプログラムであって、
   前記コンピュータには、
   前記複数の実施行為の内容及び前記実施順序を特定するための実施計画情報を格納する実施計画情報格納手段と、
   前記実施計画の実施履歴に関する実施履歴情報を、前記実施対象に関する実施対象情報あるいは前記実施者に関する実施者情報と共に、当該実施計画に対応する前記実施計画情報に関連付けて格納する実施履歴情報格納手段とが設けられており、
   前記コンピュータに、
   前記実施対象情報、前記実施者情報、あるいは前記実施計画情報が特定された場合に、当該特定された情報に対応する他の情報を前記実施履歴情報格納手段から取得する情報取得ステップを実行させること、
   を特徴とする実施計画管理プログラム。

Images