JP2007140607A - 医療マネジメント支援装置、医療マネジメント支援方法、及び医療マネジメント支援プログラム、並びに医療マネジメント支援システム - Google Patents

Abstract

【課題】 患者の診察、看護、治療業務をはじめとする医療機関における各種業務の遂行は勿論のこと、医療の質向上と医療機関の経営改善も図り、医療機関のマネジメント全体を支援することができる医療マネジメント支援システムを提供する。
【解決手段】 医療マネジメント支援システムにおけるサーバは、情報処理端末機からのアクセスに応じて、クリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図を作成し、当該情報処理端末機の表示部に表示させる。
【選択図】 図３２

Description

本発明は、患者の診察、看護、治療業務をはじめとする医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援装置、医療マネジメント支援方法、及び医療マネジメント支援プログラム、並びに医療マネジメント支援システムに関し、特に、医療の質向上と医療機関の経営改善とを目的とする医療マネジメント支援装置、医療マネジメント支援方法、及び医療マネジメント支援プログラム、並びに医療マネジメント支援システムに関する。

従来から、プロジェクトマネジメントの分野においては、クリティカルパスという概念を用いてタスクの管理を行っている。クリティカルパスとは、プロジェクトの開始から完了に至るタスクを結んだ経路のうち、要する時間が最長となる経路と定義される。換言すれば、クリティカルパスとは、プロジェクトの完遂を遅らせないために絶対に遅らせてはならないタスクの組み合わせである。かかるクリティカルパス上のタスクは、クリティカルタスクと称される。したがって、プロジェクトにおいては、クリティカルタスクの完遂が１日遅れる度に、当該プロジェクト全体の完遂が１日遅れることになる。逆に、プロジェクトにおいては、クリティカルタスクが１日早く終わった場合には、当該プロジェクトも１日早く終わることになる。このように、クリティカルパスの長さは、プロジェクト全体の長さを意味し、プロジェクト全体の長さは、クリティカルタスク以外のタスクの短縮を図っても短縮されないことになる。したがって、プロジェクトマネジメントにおいては、クリティカルパスを予定通り遂行することが重要とされている。

近年、医療分野においても、患者の入院期間の短縮化と医療の質向上とを目指した標準化を実現するために、クリティカルパスの考え方を導入しつつあり、その利用が増加している状況である。医療におけるクリティカルパスは、臨床（クリニカル）に応用するクリティカルパスという意味から、クリニカルパスと称されることが多い。日本クリニカルパス学会において、クリニカルパスとは、主に入院時に患者に対して手渡される診療スケジュール表であって、例えば図５０に示すように、疾患を治療する上で必要な治療、検査、ケア等を縦軸に、時間（日付）を横軸にとって作成される診療スケジュール表であると定義されている。

このようなクリニカルパスは、一般に、個々の病院や診療所等の医療機関が独自に作成して活用しているのが現状であるが、近年では、利用実績があり、且つ、効果も確認されている優れたクリニカルパスについては、複数の医療機関が相互に閲覧して活用する場を提供するための試みを行われている（例えば、非特許文献１等参照。）。また、近年では、クリニカルパスの作成及び活用を行うための技術も提案されている（例えば、特許文献１乃至特許文献６等参照。）。

財団法人医療情報システム開発センター、"全国医療機関からのクリティカルパスの登録と公開のご案内"、［online］、［平成１７年９月１日検索］、インターネット＜URL:http://epath.medis.jp/e-cp_frame02.html＞ 特開２００３−１０８６６１号公報 特開２００４−１３２１９号公報 特開２００４−１９２４８５号公報 特開２００４−１９２４８６号公報 特開２００５−１４９０８４号公報 特開２００５−１６５５１３号公報

しかしながら、既存のクリニカルパスは、代表的な疾患については対応することができるものの、例えば救急疾患等のように、バリエーションや合併症の多い疾患に対応することができず、汎用的でないという問題があった。

また、既存のクリニカルパスは、上述したように、疾患を治療する上で必要な治療等の項目と、時間との関係のみを規定するにとどまり、医師や看護師をはじめとするリソースの活用を何ら考慮していない。そのため、現実の医療機関においては、作成したクリニカルパスに基づく診療スケジュールが、医師や看護師等の都合によってしばしば変化してしまい、クリニカルパスを有効に活用することができていないという問題があった。

さらに、近年の医療分野においては、実際に行われている医療の経過や結果の意義ある項目を臨床評価指標（Quality Indicator；クオリティインディケータ、又はClinical Indicator；クリニカルインディケータ）として設定し、その臨床評価指標に基づいて、医療機関にて行われる医療の質の評価が行われている。そのため、医療機関においては、かかる医療の質を向上させることが従来よりも大きく要求されている。しかしながら、既存のクリニカルパスは、医療の質の評価と何ら連動するものではなく、現実の医療機関においては、クリニカルパスを有効に活用することができていないという問題があった。

さらにまた、既存のクリニカルパスは、上述したように、リソースの活用を何ら考慮していないことから、病棟、さらには医療機関全体におけるリソース配分の最適化に活用できないという問題があった。

また、既存のクリニカルパスは、あくまでも診療スケジュール表にとどまることから、医療経営との統合が困難であるという問題があった。

そして、上述した特許文献１乃至特許文献６をはじめとするクリニカルパスに関する従来の技術は、かかる問題を含むクリニカルパスを前提としていることから、これらの問題を解決することができていないのが現状である。

本発明は、このような実情に鑑みてなされたものであり、既存のクリニカルパスの問題を解決し、患者の診察、看護、治療業務をはじめとする医療機関における各種業務の遂行は勿論のこと、医療の質向上と医療機関の経営改善も図り、医療機関のマネジメント全体を支援することができる医療マネジメント支援装置、医療マネジメント支援方法、及び医療マネジメント支援プログラム、並びに医療マネジメント支援システムを提供することを目的とする。

本願出願人は、医療機関におけるプロジェクトマネジメントについて鋭意研究を重ねた結果、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論を医療機関におけるプロジェクトマネジメントに応用することを考えた。そして、本願出願人は、臨床医学とプロジェクトマネジメント理論、医療の質、及び医療経営的な要因を統合した画期的なアルゴリズムを考案し、本発明を実現するに至った。

すなわち、上述した目的を達成する本発明にかかる医療マネジメント支援装置は、医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援装置であって、上記医療機関における医療従事者の操作に応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成手段と、上記ネットワーク図作成手段によって作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶する記憶手段と、少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、上記医療機関における医療従事者が閲覧する所定の表示手段に表示させる制御手段とを備えることを特徴としている。

また、上述した目的を達成する本発明にかかる医療マネジメント支援方法は、医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援方法であって、上記医療機関における医療従事者の操作に応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成工程と、上記ネットワーク図作成工程にて作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶手段に記憶させる記憶工程と、少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、上記医療機関における医療従事者が閲覧する所定の表示手段に表示させる表示工程とを備えることを特徴としている。

さらに、上述した目的を達成する本発明にかかる医療マネジメント支援プログラムは、医療機関における各種業務の遂行と医療の質向上とを支援するコンピュータ実行可能な医療マネジメント支援プログラムであって、上記医療機関における医療従事者の操作に応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成処理と、上記ネットワーク図作成処理にて作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶手段に記憶させる記憶処理と、少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、上記医療機関における医療従事者が閲覧する所定の表示手段に表示させる表示処理とを備えることを特徴としている。

さらにまた、上述した目的を達成する本発明にかかる医療マネジメント支援システムは、医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援システムであって、上記医療機関における医療従事者が操作する情報処理端末機と、上記情報処理端末機のアクセス対象としてのサーバとを備え、上記サーバは、上記情報処理端末機からのアクセスに応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成手段と、上記ネットワーク図作成手段によって作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶する記憶手段と、上記情報処理端末機からのアクセスに応じて、少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、当該情報処理端末機の表示手段に表示させる制御手段とを有することを特徴としている。

このような本発明にかかる医療マネジメント支援装置、医療マネジメント支援方法、及び医療マネジメント支援プログラム、並びに医療マネジメント支援システムは、クリティカルチェーン理論にしたがってプロジェクトネットワーク図を作成する際に、各タスクの完了基準として臨床評価指標及び／又は臨床的アウトカムを設定する。そして、本発明にかかる医療マネジメント支援装置、医療マネジメント支援方法、及び医療マネジメント支援プログラム、並びに医療マネジメント支援システムは、作成されたプロジェクトネットワーク図を、医療従事者に閲覧可能に表示させる。これにより、本発明にかかる医療マネジメント支援装置、医療マネジメント支援方法、及び医療マネジメント支援プログラム、並びに医療マネジメント支援システムにおいては、医療の質の評価を考慮したプロジェクトマネジメントを行うことが可能となる。

本発明は、クリティカルチェーン理論に、医療の質の評価を考慮した画期的なアルゴリズムを実装することにより、既存のクリニカルパスの問題を解決し、患者の診察、看護、治療業務をはじめとする医療機関における各種業務の遂行は勿論のこと、医療の質向上と医療機関の経営改善も図ることができ、医療機関のマネジメント全体を支援することができる。

以下、本発明を適用した具体的な実施の形態について図面を参照しながら詳細に説明する。

この実施の形態は、患者の診察、看護、治療業務をはじめとする医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援システムである。特に、この医療マネジメント支援システムは、既存のクリニカルパスの問題を解決し、医療機関における各種業務の遂行は勿論のこと、医療の質向上と医療機関の経営改善も図り、医療機関のマネジメント全体を支援することができるものである。

まず、本発明の明確化を図るために、医療マネジメント支援システムの具体的な説明に先だって、本発明の基礎となったプロジェクトマネジメント理論と、このプロジェクトマネジメント理論を医療マネジメント支援システムに応用するにあたって課題となる医療特有の事項について、１．〜３．の見出しを付して説明する。

本願出願人は、本発明を想定するにあたり、クリニカルパスの原型となっているクリティカルパス理論そのものにも問題が存在すると考えた。そこで、本願出願人は、制約条件の理論（Theory of Constraint；ＴＯＣ）の発案者であるエリヤフ・ゴールドラット博士によって提唱されたプロジェクトマネジメント理論であり、既存のクリティカルパスの欠点を補ったプロジェクトマネジメント理論である「クリティカルチェーン」に着目した。医療マネジメント支援システムは、このクリティカルチェーンのスケジュール管理理論を医療機関における入院患者のスケジュールの最適化に応用するために、本願出願人が新たに考案した、臨床医学とプロジェクトマネジメント理論、医療の質、及び医療経営的な要因を統合した画期的なアルゴリズムによって実現されるものである。

以下、かかるクリティカルチェーンと既存のクリティカルパス（クリニカルパス）との差異とともに、クリティカルチェーンの基礎理論について説明する。

１． クリティカルチェーンとクリティカルパスとの差異
１．１ 不確実性に対する考え方
クリティカルチェーン理論は、その根幹となる考え方が「不確実性こそがプロジェクトマネジメントの本質である」という点で、標準化されたスケジュールを当てはめようとする既存のクリニカルパスと根本的に異なったアプローチである。プロジェクトの所要時間は、例えば図１に示すように、右方向に歪んだ（歪度＞０）の分布曲線に沿うものとなることが多い。クリティカルチェーン理論は、プロジェクトに要する時間を、かかる確率分布として捉え、その不確実性をマネジメントするための手法といえる。

１．２ セーフティの組み込み
通常、クリティカルパス理論に基づいてプロジェクトのスケジュールを決めるにあたっては、当該プロジェクトを構成するタスクについての所要時間として、「確実に終えることができる時間」を見積もる。すなわち、プロジェクトのスケジュールを決めるにあたっては、図１に示した確率分布において、平均値ではなく、それよりも右方向にずれた値を、予測所要時間として見積もる。このように平均値よりも多く見積もられた所要時間としての安全余裕（セーフティ）が全てのタスクについて組み込まれることに起因して、プロジェクト全体が完了する期間は必要以上に長くなってしまうことになる。これに対して、クリティカルチェーン理論においては、個々のタスクからセーフティを切り取り、切り取ったセーフティを１カ所に集めてプロジェクトの進捗を管理する。この点で、クリティカルチェーン理論は、既存のクリティカルパス理論と異なる。

１．３ 学生症候群の考慮
クリティカルパス理論においては、上述したように、個々のタスクにセーフティを組み込む。ここで、タスクの期限内完了を目的とすることについて考える。この場合、期限内にタスクが完了するように、十分なセーフティを設ければよいと考えがちである。しかしながら、プロジェクトにおいては、十分なセーフティを設け、確実に期限内にタスクが完了するようにスケジュールを決めたとしても、期限間際になってからタスクが開始されることが多い。これは、恰も学生が宿題を期限間際になってから開始するという様子と同様である。したがって、十分なセーフティを設けることは、必ずしもよいこととはいえない行動である。クリティカルチェーン理論においては、上述したように、セーフティを１カ所に集めてプロジェクトの進捗を管理する点で、既存のクリティカルパス理論と異なる。

１．４ 遅延は伝播するが早期完了は伝播しないという特性の考慮
自己のタスクが期限よりも早く完了したとしても、その事実を次のタスクの実行者に伝えることは少ないのが一般的である。なぜなら、タスクを早く完了した事実を伝えることは、その事実に対するインセンティブがないどころか、次回のセーフティの見積もりに対してネガティブに影響する、すなわち、長いセーフティを得ることができない状況を作り出すおそれがあるためである。一方、タスクの完了が期限よりも遅れた場合には、その遅延は、確実に次のタスクの遅延となって伝播する。クリティカルチェーン理論においては、このような遅延は伝播するが早期完了は伝播しないという特性に着目し、納期（デッドライン）を設定せずに、各プロジェクトメンバがタスクを受け取った瞬間に実行を開始し、タスクの完了時に次のタスクを実行するメンバに引き渡すことを要求する。この点で、クリティカルチェーン理論は、既存のクリティカルパス理論と異なる。

１．５ リソースの競合
クリティカルパス理論においては、リソースの競合が考慮されていないことから、同じリソースが同時に複数のタスクを掛け持つという現象が生じる。かかるタスクの掛け持ちは、個々のタスクの完了の遅延を招来し、プロジェクト全体の期間を長くしてしまう要因となる。クリティカルパス理論の最大の欠点は、このようなリソースの競合を考慮しない点にある。クリティカルチェーン理論においては、あるプロジェクト内のみならず、他のプロジェクトをも考慮して、リソースの競合を排除することに細心の注意を払っている点で、クリティカルパス理論と異なる。

２． クリティカルチェーン理論に基づくプロジェクトマネジメントの手順
このように、クリティカルパス理論とは異なるクリティカルチェーン理論に基づくプロジェクトマネジメントは、以下のような手順にしたがって行われる。

２．１ プロジェクトネットワーク図の作成
まず、クリティカルチェーン理論においては、プロジェクトネットワーク図の作成を行う。クリティカルチェーン理論においては、プロジェクトを構成する各タスクの実行順序に沿ってプロジェクトネットワーク図を作成するのではなく、最初に、プロジェクト完了の成果物の定義を行う。具体的には、クリティカルチェーン理論においては、図２に示すように、例えば「製品を１００個、○○へ向けて発送する」といったように、「この状況になったら、プロジェクト完了であるといえる」という完了基準を客観的に記述する。

続いて、クリティカルチェーン理論においては、定義したプロジェクトの完了基準を満たすための必要条件を記述する。なお、この必要条件を満たすための作業がタスクとなる。具体的には、クリティカルチェーン理論においては、図３に示すように、完了基準を満たすための必要条件として２つの条件Ｃ１，Ｃ２がある場合には、これら２つの条件Ｃ１，Ｃ２を記述する。なお、同図においては、条件Ｃ１，Ｃ２のそれぞれを満たすタスクとして、タスクＡ，Ｂを挙げている。

続いて、クリティカルチェーン理論においては、設定したタスクを実行するための必要条件を記述する。なお、この必要条件を満たすための作業が、設定したタスクの前に完了していなければならないタスクとなる。具体的には、クリティカルチェーン理論においては、図４に示すように、タスクＡを開始するためには３つのタスクＣ，Ｄ，Ｅを完了していることが必要であり、タスクＢを開始するためには２つのタスクＦ，Ｇを完了していることが必要である場合には、これらタスクＣ，Ｄ，Ｅ，Ｆ，Ｇを必要条件として記述する。

クリティカルチェーン理論においては、このような作業を、現在の状態から直接行うことができるタスクＸ，Ｙに至るまで逆時系列順に行い、プロジェクトネットワーク図を作成する。

２．２ 所要時間の見積もり
クリティカルチェーン理論においては、このようにしてプロジェクトネットワーク図を作成すると、各タスクの実行に必要な所要時間を見積もる。ここで、クリティカルチェーン理論においては、各タスクの所要時間を見積もる際に、不確実性を考慮して、例えば図５に示すように、約５０％程度の確率でタスクを完了することができると思われる第１の完了期間（Aggressive, But Possible；ＡＢＰ）と、約９０％以上の確率でタスクを完了することができると思われる第２の完了期間（Highly Possible；ＨＰ）という２種類の時間を見積もる。クリティカルチェーン理論においては、例えば図６に示すように、見積もった期間をプロジェクトネットワーク図における各タスクに記述する。なお、同図は、１０個のタスクＴ１，Ｔ２，・・・，Ｔ１０によって構成される仮想のプロジェクトにおけるプロジェクトネットワーク図を示しており、最右側の縦線がプロジェクトの完了を示すものである。また、同図に示す見積もり日数は、第１の完了期間ＡＢＰである。

２．３ 各タスクへのリソース割り当て
続いて、クリティカルチェーン理論においては、プロジェクトネットワーク図に各タスクの所要時間を記述すると、各タスクの実行に必要な人材、機材、資材といったリソースを割り当て、例えば図７に示すように、割り当てたリソースをプロジェクトネットワーク図における各タスクに記述する。このリソースは、各タスクの特性によって決定される。

２．４ リソース競合の解除
続いて、クリティカルチェーン理論においては、プロジェクトネットワーク図の中で、同一期間に同一リソースが複数のタスクに関与している部分、すなわち、リソースが競合している部分を探索する。図７に示したプロジェクトネットワーク図においては、図８中斜線部で示すように、２つのリソースＣ，Ｄが競合している。ここで、プロジェクトにおいては、リソースの競合が発生すると、そのリソースが複数のタスクに同時に関与することを要求され、いわゆるBad Multi-taskingと称される状況に陥る。

ここで、なぜBad Multi-taskingがプロジェクトに悪影響を及ぼすかについて説明する。

図９に、複数のタスクを同時に実行するMulti-taskingと、複数のタスクを順次実行するFocused-taskingとの２つの方法で、所要時間が２．０である３つのタスクＡ，Ｂ，Ｃを実行した場合の比較を示す。多くの場合、早くタスクの実行を開始すればするほど、そのタスクは早く完了すると考えることから、全てのタスクを同時にこなそうという心理が働く傾向にある。しかしながら、現実には、複数の作業を同時に実行することはできないため、Multi-taskingにおいては、各タスクを細切れにし、少しずつ実行することになる。すなわち、Multi-taskingにおいては、図９中Ａ−１に示すように、３つのタスクＡ，Ｂ，Ｃを、それぞれ、所要時間が１．０となるように２分割し、この分割したタスクを実行することになる。これに対して、Focused-taskingにおいては、図９中Ｂ−１に示すように、３つのタスクＡ，Ｂ，Ｃを、それぞれ、前のタスクが完了してから実行することになる。また、前のタスクが完了した後、新たな作業にとりかかるのは、物理的にも心理的にも準備が必要となり、また、思考の整理等のため時間を要する。すなわち、複数の作業を同時に行う場合には、セットアップタイムを要することになり、タスクの切り替えが多いほど、セットアップタイムが多くなることになる。

これらから、セットアップタイムをαとすると、タスクＡ，Ｂ，Ｃのそれぞれの完了に要する期間は、Multi-taskingの場合には、図９中Ａ−２に示すように、４．０＋３αとなる一方で、Focused-taskingの場合には、図９中Ｂ−２に示すように、２．０＋αとなり、全体の完了に要する期間も、Multi-taskingよりもFocused-taskingの方が短くなる。このように、プロジェクトは、早く開始すれば早く完了するわけではなく、Multi-taskingよりもFocused-taskingの方が望ましい方法である。

したがって、プロジェクトにおいては、リソースを競合させないマネジメントを行うことが重要となる。そこで、クリティカルチェーン理論においては、プロジェクトネットワーク図の中で、リソースが競合するタスクを時間的に前にずらすことにより、リソースの競合を解除する。このとき、クリティカルチェーン理論においては、リソースの競合を解除する方法が複数ある場合には、トータルのプロジェクト期間が最短となるように工夫する。具体的には、クリティカルチェーン理論においては、図８に示した競合状態の場合には、例えば図１０に示すように、リソースＣ，Ｄが関与するタスクを前倒しして、プロジェクトネットワーク図を書き替える。

２．５ クリティカルチェーンの決定
そして、クリティカルチェーン理論においては、このようにして作業とリソースとの依存関係の双方を解消すると、その中で最も長い期間を要する経路をクリティカルチェーンとして求める。具体的には、図１０に示したように、リソースの競合を解除した場合には、クリティカルチェーンは、例えば図１１に示すように、リソースＡ，Ｅ，Ｃ，Ｃ，Ｄ，Ｂが順次関与する所要見積もり日数７．３日のタスクの集合となる。

２．６ バッファの設定
このようにして完成したプロジェクトのスケジュールは、上述した第１の完了期間ＡＢＰに基づくものであるため、「約５０％程度の確率で当該プロジェクトを完了する」ものである。しかしながら、現実には、様々な不確実性により、全てのタスクが見積もられた第１の完了期間ＡＢＰの時間内で完了するとは限らない。そこで、クリティカルチェーン理論においては、バッファと称される猶予時間を挿入することにより、不確実性に対応する。クリティカルチェーン理論において中心となるバッファは、プロジェクトバッファ（Project Buffer；ＰＢ）と、フィーディングバッファ（Feeding Buffer；ＦＢ）である。

プロジェクトバッファＰＢとは、プロジェクトのクリティカルチェーン上のタスクの遅延からプロジェクトを保護するためのバッファであり、フィーディングバッファＦＢとは、クリティカルチェーンに合流する作業又は作業群の遅延からプロジェクトを保護するためのバッファである。なお、クリティカルチェーン理論においては、これら２つのバッファの他に、期限が決まっているタスクのためのバッファ（Contractual Milestone Buffer）やリソースのためのバッファであるリソースバッファ（Resource Buffer）等、プロジェクトを不確実性から保護するバッファが存在する。後述する医療マネジメント支援システムにおいても、実際にはこれらのバッファを利用するが、以下では、説明の簡便化のため、プロジェクトバッファＰＢ及びフィーディングバッファＦＢのみを設定するものとして説明する。

２．７ ＰＢ，ＦＢの計算
プロジェクトバッファＰＢ及びフィーディングバッファＦＢとして必要な時間は、単純に計算できるものではないが、大まかに決定するための方法として、Rule of Thumb（ＲＯＴ）法と、Square Root of Sum of Squares（ＳＲＳＳ）法とが提唱されている。なお、これら２つの方法は、そのときの状況に応じて、いずれを利用するかを考慮すべきであり、医療マネジメント支援システムにおいては、臨床状況や病棟の状況等を十分に考慮した上で、バッファの時間的な長さを設定するが、以下では、説明の簡便化のため、ＲＯＴ法を用いてバッファの長さを計算するものとする。

まず、ＲＯＴ法においては、全てのタスクの第１の完了期間ＡＢＰと第２の完了期間ＨＰとを推定し、それらの差分値｜ＨＰ−ＡＢＰ｜を算出する。次表１に、図１１に示したプロジェクトネットワーク図における各タスクＴ１，Ｔ２，・・・，Ｔ１０の第１の完了期間ＡＢＰ及び第２の完了期間ＨＰの推定値と、これらの差分値｜ＨＰ−ＡＢＰ｜とを示す。その上で、ＲＯＴ法においては、クリティカルチェーンに属するタスクと従属するタスクとに分けて、それぞれの差分値｜ＨＰ−ＡＢＰ｜を加算する。プロジェクトバッファＰＢの長さは、クリティカルチェーンに属するタスクの差分値｜ＨＰ−ＡＢＰ｜の総和の１／２であり、フィーディングバッファＦＢも、同様に求めることができる。この結果を、次表２に示す。

クリティカルチェーン理論においては、求めたバッファの長さを図１１に示したプロジェクトネットワーク図に記述することにより、例えば図１２に示すように、プロジェクトプランを示すクリティカルチェーンモデルを作成する。この結果、プロジェクトが完了するまでの予定日数は、クリティカルチェーンの７．３日とプロジェクトバッファＰＢの２．９日との和である１０．２日となる。

クリティカルチェーン理論においては、このような一連の手順にしたがって、単一のプロジェクトについてのプランを作成し、そのプロジェクトのマネジメントを行うことができる。

２．８ 複数のプロジェクトの同期
ところで、一般には、複数のプロジェクトが同時に進行することが多い。そのため、複数のプロジェクトのスケジュールを同時に管理する方法が必要となる。また、複数のプロジェクトがある場合には、リソースが同時に複数のタスクを掛け持つことが多くなり、上述したBad Multi-taskingと称される状況が生じやすくなる。クリティカルチェーン理論に基づくプロジェクトマネジメントにおいては、複数のプロジェクトを管理する方法を「プロジェクトの同期」と称する。以下、複数のプロジェクトの同期の手順について説明する。なお、ここでは、説明の簡略化のため、図１３に示すように、２つのクリティカルチェーンモデルからなるプロジェクトＸ，Ｙの同期の手順について説明するものとする。

まず、クリティカルチェーン理論においては、リソースが競合する複数のプロジェクトがある場合には、その優先順位の明確化を図る。ここで、プロジェクトＸ，Ｙのうち、プロジェクトＸの完了が優先されると仮定する。クリティカルチェーン理論においては、リソースＡが１人の人間である場合には、プロジェクトＸ，Ｙの開始時点で当該リソースＡの競合が発生するため、優先順位が低いプロジェクトＹの開始を遅らせることになる。

続いて、クリティカルチェーン理論においては、複数のプロジェクト間で競合するリソースの中で最も利用度の高いものをシンクロナイザ（同期基準）とし、優先順位が低いプロジェクトのうち、そのシンクロナイザを必要とするタスクを含めて当該タスクよりも時間的に遅く実行されるタスクを、そのプロジェクトネットワーク上で右側へ、すなわち、時間的に遅い方へずらす。具体的には、クリティカルチェーン理論においては、図１３に示した例の場合には、図１４に示すように、リソースＡをシンクロナイザとし、プロジェクトＹ全体を右側にずらす。

しかしながら、このままでは、プロジェクトＸのタスクＴ１の完了が遅延した場合には、プロジェクトＹの開始に直接影響が生じる。そのため、クリティカルチェーン理論においては、同期する競合リソースの前に同期バッファ（Synchronization Buffer；ＳＢ）を設定する。具体的には、クリティカルチェーン理論においては、図１４に示した例の場合には、図１５に示すように、プロジェクトＹでリソースＡが必要となるタスクＴ１の前に同期バッファＳＢを設定する。なお、同期バッファＳＢの長さは、状況や患者の状態等に応じて変化するが、一般には、１００％として設定する。

クリティカルチェーン理論においては、他のリソースの競合がある場合には、競合する全てのリソースについて、このような同期を行うことにより、競合の解消を図る。具体的には、クリティカルチェーン理論においては、図１５に示した例の場合には、リソースＥにも競合が生じていることから、その部分に同様の同期を行うことにより、図１６に示すように、最終的に同期された２つのプロジェクトＸ，Ｙについてのクリティカルチェーンモデルを作成する。

クリティカルチェーン理論においては、このような一連の手順にしたがって、同期された複数のプロジェクについてのプランを作成し、そのプロジェクトのマネジメントを行うことができる。クリティカルチェーン理論においては、３つ以上のプロジェクトがある場合にも、基本的には同様の同期を行うことになる。

２．９ バッファマネジメント
クリティカルチェーン理論に基づくプロジェクトマネジメントにおいては、このようにしてプランが作成された個々のプロジェクトの管理を行うために、バッファのモニタリングを行う。クリティカルチェーン理論においては、例えば図１７に示すように、プロジェクトバッファＰＢを３等分し、実際のプロジェクトの進捗状況と照合したときに、その残存量が１００％〜６７％である場合には「安全区域」とし、６６％〜３４％である場合には「注意区域」とし、３３％以下である場合には「危険区域」として区別する。

クリティカルチェーン理論に基づくプロジェクトマネジメントにおいては、このようにバッファのモニタリングを行うことにより、プロジェクトの進捗管理等を行うことができる。

３． 医療マネジメントに対するクリティカルチェーン理論の応用
さて、本発明の実施の形態として示す医療マネジメント支援システムは、このようなクリティカルチェーン理論を応用して実現される。以下では、このような医療マネジメント支援システムについて説明する。

３．１ 医療におけるクリティカルチェーン理論の課題
クリティカルチェーン理論は、既存のクリティカルパス理論の欠点を補うことができる非常にまとまった理論であるが、そのまま医療におけるマネジメントに用いるには、以下のような課題がある。

まず、クリティカルチェーン理論は、プロジェクトを期限内に完了するための方法として有効であるが、医療においては、それだけではなく、適正な業務、すなわち、質が担保された業務を行うことが必要であり、これを実現する対策が必要である。

また、医療においては、例えば合併症等の予期せぬ事態が発生した場合には、プロジェクトネットワークの変更を余儀なくされる。したがって、医療におけるマネジメントにおいては、クリティカルチェーン理論に加え、かかる予期せぬ事態に対する対策が必要である。

さらに、医療においては、各タスクに医師や看護師等の複数のリソースが関与することが多いが、同時にタスクを実行するだけではなく、時間をずらして実行される各リソースの行為の結果、アウトカムが達成されるという非同期型の共同作業も多い。したがって、医療におけるマネジメントにおいては、クリティカルチェーン理論に加え、複数のリソースによる非同期型の共同作業をも考慮する必要がある。

さらにまた、医療においては、あるタスクにリソースが終日占拠されることは少なく、数分程度の細かい単位のタスクが断続的に行われ、１つの大きなタスクとなることが多い。したがって、医療におけるマネジメントにおいては、クリティカルチェーン理論に加え、かかる断続的なタスクに対する対策が必要である。

また、医療においては、１人のリソースが１日に複数の患者に関与し、さらに、１人の患者が複数のリソースの診療や処置等を受ける、というタスクとプロジェクトとがＮ対Ｍの関係となることが多い。したがって、医療におけるマネジメントにおいては、クリティカルチェーン理論に基づくプロジェクトの進捗状況に加え、リソースのマネジメントが重要となる。

さらに、クリティカルチェーン理論においては、プロジェクトの完了基準が明確に定められるが、医療においては、患者の疾患が全て治癒した上で退院できるわけではなく、完了基準が明確になりにくいという側面がある。したがって、医療におけるマネジメントにおいては、かかる完了基準の不明確さに対する対策が必要である。

以上の理由から、医療におけるマネジメントにおいては、クリティカルチェーン理論をそのまま利用することは困難である。そこで、本願出願人は、クリティカルチェーン理論に対して、医療における質の考え方、臨床医学、費用効果性、医療情報学に基づく理論を組み合わせ、日本における保険医療制度の中で、医療の質を担保しつつ最小のコストで最大の効果を発揮することができるアルゴリズムを開発し、医療マネジメント支援システムを実現した。

また、本願出願人は、これらのアルゴリズムを実際の臨床でリアルタイムに利用するために、電子カルテシステムやオーダリングシステム等の医療機関情報システムとの連携を実現する方法を考案した。これらのアルゴリズムは、プロジェクトマネジメント理論のみでは解決することができない医療の特殊性や公共性をも勘案し、クリティカルチェーン理論を医療分野に特化した形で拡大したものである。

３．２ 医療におけるプロジェクトマネジメントの必要性
ここで、医療におけるプロジェクトマネジメントの必要性について説明する。

プロジェクトとは、１）ある目的の達成のために、２）一定期間の中で、３）限られたリソースをマネジメントする作業である。この定義に基づくと、患者を入院させ、退院させるという作業もプロジェクトに他ならない。換言すれば、医療機関においては、日々、病棟においてプロジェクトマネジメントを行っているといっても過言ではない。しかしながら、医療機関においては、プロジェクトマネジメントの視点が存在していないのが現状である。これに対して、医療においては、以下の理由から、質と効率との両立が強く望まれており、プロジェクトマネジメントの重要性は増しているのが現状である。

３．２．１ 医療の質評価への動き
米国のInstitute of Medicine（ＩＯＭ）が１９９９年に報告した「To Err is Human（邦訳：ヒトは誰でも間違える）」によれば、全米において医療事故による死亡者数は、年間４９０００人から９８０００人であるといわれる。この報告がきっかけとなり、米国のみならず、全世界において、「医療の質」に対する意識が高まっている。昨今の医療訴訟の増加や、医師免許の更新性への要望等の観点から、日本においても、「医療の質」に対する人々の要求も高まりつつある。

また、近年では、米国における高齢者向けの医療保険であるメディケアにおいて、提供した医療の質やその結果に基づいて、償還に傾斜をつける「Pay for Performance」という動きも出てきている。一方、日本においても、入院患者の医療に対して効率を求める仕組みである入院診療費用の包括支払いの動きが進んでいる。

３．２．２ 入院診療費用の包括支払いの導入
日本の医療分野においては、２００３年４月より、全国の特定機能病院等において、日本独自の診断分類であるＤＰＣ（Diagnosis Procedure Combination）が導入され、その診断分類に基づいた保険診療費の包括支払い方式が導入されつつある。そして、今後、入院保険診療費の償還は、このＤＰＣによる診断群別定額支払い方式になることが予想されている。

ＤＰＣによる定額支払い方式においては、入院期間を３つに分類し、ある疾患群における全国の医療機関の平均入院期間の２５パーセンタイル値までの入院期間をＩ期とし、全国平均値までの入院期間をＩＩ期とし、平均入院期間＋２×標準偏差（約９７．５パーセンタイル値）までの入院期間をＩＩＩ期とし、それぞれの包括支払い額に傾斜をつけている。例えば、合併症をともなわない２型糖尿病、すなわち、インスリン非依存型糖尿病の患者（国際疾病分類第１０版コード（The International Statistical Classification of Diseases and Related Health Problems, tenth revision；以下、ＩＣＤ−１０コードという。）：Ｅ１１９）におけるインスリン導入を目的とした教育入院におけるＩ期，ＩＩ期，ＩＩＩ期の入院期間、及び償還診療報酬は、次表３に示すようになる。したがって、医療機関にとっては、できるだけ多くの患者をＩ期である７日以内、若しくは、ＩＩ期である１５日以内に退院させることが、収益を最大化するために必要な目標となる。

定額支払い方式のよい点は、疾患毎の医療費が決まっているため、医療費の高騰を防ぎ、医療従事者・医療機関に標準的な医療を促進させることであるが、その一方で、医療の質によらず、支払い額が決まっていることによるモラルハザードが懸念される。例えば、上表３に示した例においては、１５日目までに十分な教育効果があがっていない場合であっても、収益を考え、患者を退院させてしまう、という行為を生じさせる可能性がある。これは、医療の質を低下させてしまう可能性があるといっても過言ではない。

３．２．３ 医療の質と効率（経営）を同時に制御するシステムの必要性
したがって、医療においては、医療の質を担保しながら、最短期間で患者を退院させることを可能とするスケジューリングが必要である。また、質を担保するためには、そのスケジューリングをモニタリングするための指標が必要となる。そして、運用を考えると、スケジューリングの機能は、電子カルテシステム等の医療機関情報システムと連携できることが望まれる。

３．２．４ 医療機関の活動内容に合致したマネジメントシステム
医療機関において、個々の患者は、上述したように、複数のリソースによってマネジメントされる複数のタスクを有する。すなわち、複数の医療従事者が１人の患者に関与するとともに、１人の医療従事者が複数の患者に関与することから、患者のタスクと医療従事者のタスクとの関係がＮ対Ｍとなる。

したがって、医療におけるスケジュール管理は、例えば図１８に示すように、患者、病棟、検査室や手術室等の部門、医師等の診療科といったように多次元にわたることになり、かかる問題を解決することができるマネジメントシステムが必要となる。

４． 医療マネジメント支援システムの概要
４．１ プロジェクトネットワーク図の役割
既存のクリニカルパスが入院日数を軸とした診療スケジュール表に過ぎないのに対して、医療マネジメント支援システムは、臨床におけるスケジューリングを「最短期間で、医療の質評価指標を満たす」ことを目的としたものであり、質と効率との２次元の要素を考慮した最適化を図るものである。

また、既存のクリニカルパスが不確実性による変動やスケジュールの遅延を「バリアンス」としてネガティブに捉え、このバリアンスをクリティカルパスからの脱落例として取り扱うのに対して、医療マネジメント支援システムにおいては、バリアンスを「プロジェクトの管理上、回避できない変動と不確実性」として捉え、それら変動や不確実性に対する対処を臨床マネジメントとして位置付けている。すなわち、医療マネジメント支援システムにおいては、一連の臨床を、「医療の質評価指標を満たすためのタスクのリレー」とし、クリティカルチェーン理論に基づくプロジェクトマネジメントに基づいて、プロジェクトネットワーク図を作成し、このプロジェクトネットワーク図に基づいて、ダイナミックなタスク管理を行い、不確実性に対処することを重視している。

医療マネジメント支援システムにおいて、プロジェクトネットワーク図は、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べたものであり、各タスクの完了基準は、臨床行為の質の評価指標（Quality Indicator；クオリティインディケータ、又はClinical Indicator；クリニカルインディケータ。以下、臨床評価指標という。）や臨床的アウトカム（Clinical Outcomes）として数値で表される。医療マネジメント支援システムにおいては、概略的には、例えば図１９に示すような画面を後述する情報処理端末機の表示部に表示させる。すなわち、医療マネジメント支援システムにおいては、患者毎のプロジェクトネットワーク図を作成するための画面を情報処理端末機の表示部に表示させ、同図に示すように、各タスクを並べていくことにより、プロジェクトネットワーク図を作成し、また、作成されたプロジェクトネットワーク図を閲覧することを可能とする。医療マネジメント支援システムにおいては、作成されたプロジェクトネットワーク図を構成する各タスクを選択することにより、そのタスクの状況や臨床評価指標等の情報を閲覧することができる。また、医療マネジメント支援システムにおいては、作成したプロジェクトネットワーク図を、患者の状態急変といった不測の事態に応じてダイナミックに変化させることも可能である。なお、医療マネジメント支援システムにおいては、後述するように、電子カルテシステム等の医療機関情報システムとの連携を図ることにより、各タスクに設定する臨床評価指標をリアルタイムでインポートすることが可能に構成される。

このように、医療マネジメント支援システムにおいては、各タスクの完了基準の設定をともなうプロジェクトネットワーク図の作成、及びその閲覧機能が設けられる。

４．２ 医療機関情報システムとの連携
医療マネジメント支援システムは、例えば図２０に示すように、電子カルテシステムやオーダリングシステム等の医療機関情報システムから独立したシステムとして構成することもでき、これら医療機関情報システムを構成する１つのモジュールとして構成することもできる。いずれの場合であっても、医療マネジメント支援システムは、プロジェクトの管理に必要な各種情報を医療機関情報システムから入力するとともに、プロジェクトの全体最適化を図るために必要な各種情報を医療機関情報システムに対して出力することが可能に構成される。このとき、医療マネジメント支援システムにおいては、医療機関情報システムとの間で授受されるデータの形式を、医療情報交換のための標準規約であるＨＬ−７（Health Level-7）に準拠したものとすることにより、このＨＬ−７に準拠した患者管理、オーダリング、照会、財務、検査報告、マスタファイル、情報管理、予約、患者紹介、患者ケア、ラボラトリオートメーション、アプリケーション管理、人事管理等の各種システムとの間でデータの交換を行うことができる。

また、医療マネジメント支援システムにおいては、医療チームがプロジェクトネットワーク図を作成し、そのタスクの完了基準を設定する際に、その完了基準が例えば検査値といった医療機関情報システムから参照可能な情報である場合には、当該医療機関情報システムからこれらの情報の提供をリアルタイムに受けるようにする。これにより、医療マネジメント支援システムにおいては、タスクの完了を自動的に確認することが可能となり、その結果を医療チームが迅速に把握することが可能となる。

このように、医療マネジメント支援システムにおいては、医療機関情報システムとの連携機能が設けられる。

４．３ 優先順位決定のためのバッファマネジメント
医療マネジメント支援システムにおいては、緊急状態にある患者を除き、バッファの残存量を求め、その残存量に基づいて、全てのケアにおいて臨床行為における優先順位を決定することができる。また、医療マネジメント支援システムにおいては、患者のケアの進捗度合いとしてバッファを記録することができる。したがって、医療マネジメント支援システムにおいては、プロジェクトネットワーク図の進捗状況とバッファの状況とに基づいて、複数の診療科で患者を診療している場合には、ある診療科の医療チームが他の診療科の進捗状況を参照することが可能となる。概略的には、医療マネジメント支援システムにおいては、例えば図２１に示すような画面を病棟に設けられた情報処理端末機の表示部に表示させる。すなわち、医療マネジメント支援システムにおいては、患者毎に、氏名やＩＤ、予定入院期間、上述したＤＰＣによる定額支払い方式におけるＩ期及びＩＩ期の日数とともに、上述した「安全区域」、「注意区域」、「危険区域」として区別されるバッファの状況を視覚的に表した情報が掲載された画面を情報処理端末機の表示部に表示させる。医療マネジメント支援システムにおいては、かかる画面に表示された患者の氏名やＩＤを選択することにより、その患者のプロジェクトネットワーク図を情報処理端末機の表示部に表示させることができる。また、医療マネジメント支援システムにおいては、かかる画面を介してバッファの状況を閲覧することにより、その日にどの患者にリソースを集中すべきかといった優先順位を決定することができる。さらに、医療マネジメント支援システムにおいては、Ｉ期やＩＩ期の根拠となるＤＰＣ分類コードや、タスクの完了基準となる臨床評価指標や臨床的アウトカム等の情報を一覧形式で情報処理端末機の表示部に表示させることもできる。

このように、医療マネジメント支援システムにおいては、患者毎のバッファの状況を視覚的に表した情報を閲覧する機能を設けることにより、優先順位を決定することができる。

４．４ 医療機関全体の最適化のためのバッファマネジメント
医療機関は、様々な部門に分かれているが、プロジェクトの進行が複数の部門にわたる場合には、各部門におけるリソース配分の最適化を図るのではなく、当該医療機関全体におけるリソース配分の最適化を行う必要がある。医療マネジメント支援システムにおいては、バッファの残存量を電子カルテシステム等と連携させることにより、リソースに制限のある検査等の効率的な利用を図ることが可能となる。例えば、医療マネジメント支援システムにおいては、ＣＴスキャンやＭＲＩ検査等、１日に一定人数しかこなすことができない検査の場合には、臨床的に緊急度が高い重症患者を優先して検査を行うものの、その重症患者の後は、バッファの残存量に基づいて、検査のスケジューリングを行うことが可能となる。すなわち、医療マネジメント支援システムにおいては、検査時間を予約せずに、検査枠の中で可能な限り、バッファの残存量が少ない患者から検査を行えばよい。なお、検査のスケジュールは、前日の夕方時点でのバッファの残存量に基づいて決定するのが望ましく、例えば夜間における患者の状態急変によるバッファの状況の変化等、夜間の状況に応じて当日の朝に微調整を行えばよい。概略的には、医療マネジメント支援システムにおいては、当日のＣＴスキャンの管理のために、例えば図２２に示すような画面を情報処理端末機の表示部に表示させる。すなわち、医療マネジメント支援システムにおいては、患者毎に、氏名やＩＤ、予定入院期間、前回ＣＴスキャンを行ってからの期間とともに、バッファの状況を視覚的に表した情報や、臨床的に緊急度が高い患者を識別するための緊急マークが掲載された画面を情報処理端末機の表示部に表示させる。医療マネジメント支援システムにおいては、かかる画面を介してバッファの状況を閲覧することにより、その日にＣＴスキャンの申し込みがある患者のうち、優先すべき患者を決定することができる。このとき、医療マネジメント支援システムにおいては、かかる画面に表示された前回ＣＴスキャンを行ってからの期間をバッファの状況とあわせて参照することにより、双方のバランスに基づいて、最適な優先順位を決定することができる。なお、医療マネジメント支援システムにおいては、緊急マークを不用意に乱立させないように所定の基準を設けるのが望ましい。

このように、医療マネジメント支援システムにおいては、リソースに制限のある検査等について、患者毎のバッファの状況を視覚的に表した情報を閲覧する機能を設けることにより、医療機関全体におけるリソース配分の最適化を図ることができる。

４．５ テンプレート
医療マネジメント支援システムにおいては、例えば糖尿病の教育入院といった代表的な疾患についてはプロジェクトネットワーク図をテンプレート化することが可能である。すなわち、医療マネジメント支援システムにおいては、テンプレートを呼び出し、必要に応じて、個々の患者によるバリエーションを加味するのみで、患者毎のプロジェクトネットワーク図を作成することができる。

ここで、医療マネジメント支援システムにおいては、一度作成したプロジェクトネットワーク図を、個々の患者のＩＤ、ＩＣＤ−１０コード、ＤＰＣ分類コード、病棟等の属性を付与してデータベースに記憶させる。そして、医療マネジメント支援システムにおいては、データベースに記憶された全てのプロジェクトネットワーク図を、他の患者に対するテンプレートとして再利用することができる。また、医療マネジメント支援システムにおいては、プロジェクトネットワーク図のみならず、プロジェクトネットワーク図を構成する各タスクについても分類してデータベースに記憶させることにより、タスク達成のためのプロセスやその達成指標としての臨床評価指標を、他の患者に対するテンプレートとして再利用することもできる。さらに、医療マネジメント支援システムにおいては、代表的なテンプレートを、ウェブ上に公開されたデータベース等を用いて管理することにより、他の医療機関で作成されたプロジェクトネットワーク図等をダウンロードして活用したり、自己が作成したプロジェクトネットワーク図と比較したりすることも可能となる。

なお、１つのＤＰＣ分類コードに対するプロジェクトネットワーク図は、医学的根拠に基づいて作成されると予想されることから、多くの場合、どの医療機関でも同様の内容のものが作成されると考えられる。しかしながら、各タスクを達成するためのケアの方法は、個々の患者の状況や嗜好、医療機関の状況、病棟の状況、医師の専門性、地域性、文化等、様々な要素に影響を受ける可能性がある。医療マネジメント支援システムにおいては、既存のクリニカルパスが医療機関独自に作成されるのに対して、プロジェクトネットワーク図をテンプレートとして共有することができる一方で、それを構成する各タスクをカスタマイズすることができるため、各医療機関の独自性を発揮させることが可能となる。

このように、医療マネジメント支援システムにおいては、プロジェクトネットワーク図やタスク等をテンプレート化する機能が設けられる。

４．６ 医療の質の評価
医療マネジメント支援システムにおいては、プロジェクトネットワーク図の共有を図ることにより、その評価基準である臨床評価指標や臨床的アウトカムの共有も図ることが可能となる。通常のクリティカルチェーン理論においては、バッファの管理がマネジメントの中心となるが、医療マネジメント支援システムにおいては、これに加え、臨床評価指標や臨床的アウトカムのマネジメントを行うことにより、プロジェクトの効率性（経営効率）と医療の質とをともにマネジメントすることが可能となる。また、医療マネジメント支援システムにおいては、プロジェクトネットワーク図と各タスクの臨床評価指標や臨床的アウトカム、さらには、そのタスクの達成率を公開することにより、各医療機関がプロセスの透明性の確保と説明責任を遂行することが可能となる。さらに、医療マネジメント支援システムにおいては、同じタスクと臨床評価指標や臨床的アウトカムとを設定している医療機関の間で、臨床評価指標や臨床的アウトカムの達成率、各タスクの完了に要した時間、全体の入院期間等の比較を行うことができ、改善点の明確化を図ることも可能となる。すなわち、医療マネジメント支援システムにおいては、他のタスクと比べてタスクの完了までの期間のばらつきが大きいタスクや、他の医療機関と比較して完了までの期間が長いタスクの原因を探ることにより、改善点を見つけ出すことが可能となる。そして、医療マネジメント支援システムにおいては、これらの分析の結果、必要に応じて、タスクを分割してさらに微細にタスクの進捗管理を行うこともできるし、逆に、複数のタスクを１つにまとめていくような柔軟な対応を行うことも可能となる。

このように、医療マネジメント支援システムにおいては、臨床評価指標や臨床的アウトカムに基づいて医療の質の評価を行い、プロジェクトの効率性（経営効率）とともにマネジメントすることが可能となる。

４．７ 診断がつかない疾病の場合
医療マネジメント支援システムにおいては、上述したように、目標とするスケジュールからなるプロジェクトネットワーク図がＤＰＣに基づいて決定されることから、診断がつかない病態については、診断をつけることを目標としたスケジュールからなるプロジェクトネットワーク図を作成することになる。そして、医療マネジメント支援システムにおいては、診断がついてから、作成されたプロジェクトネットワーク図を改訂する。例えば、不明熱（ＩＣＤ−１０コード：Ｒ５０９）におけるＩ期，ＩＩ期，ＩＩＩ期の入院期間、及び償還診療報酬は、次表４に示すように設定されている。したがって、医療マネジメント支援システムにおいては、Ｉ期である３日以内、若しくは、ＩＩ期である１０日以内に診断をつけることを目標としたスケジュールからなるプロジェクトネットワーク図を作成し、診断がついた時点で、当該疾患のプロジェクトネットワーク図に改訂すればよい。

このように、医療マネジメント支援システムにおいては、診断がつかない疾病の場合であっても、適切なマネジメントを行うことが可能となる。

４．８ 合併症等の不測の事態への対処
医療マネジメント支援システムにおいては、合併症等が生じた場合には、その患者のプロジェクトネットワーク図に新たなタスクが追加されることになり、これに応じて入院予定日数も変化する。ここで、医療マネジメント支援システムにおいては、プロジェクトバッファの能力を超えるような合併症等が生じた場合には、通常、ＤＰＣ分類コードも変化する。したがって、医療マネジメント支援システムにおいては、ＤＰＣ分類コードの変化に応じて、プロジェクトバッファの大きさ等も自動的に変化することができるようなデータベースを構築する。

５． 医療マネジメント支援システムの具体的構成
以下では、このような概要からなる医療マネジメント支援システムについて、より具体的に説明する。

なお、医療マネジメント支援システムは、先に図２０に示したように、電子カルテシステムやオーダリングシステム等の医療機関情報システムから独立したシステムとして構成することもでき、これら医療機関情報システムを構成する１つのモジュールとして構成することもできる。また、本発明は、医療マネジメント支援システムを実現するための医療マネジメント支援プログラムの頒布形態に拘泥するものではない。以下では、説明の便宜上、例えば図２３に示すように、医師や看護師等が操作する各種情報処理端末機ＣＬが、インターネット等のネットワークＮＴを介して所定のサーバＳＶに対してアクセスし、サーバＳＶが医療マネジメント支援プログラムに関する処理を実行した結果を示す情報を情報処理端末機ＣＬが受信して表示部に表示させることにより、医師や看護師等がマネジメントを行う環境を享受できるＡＳＰ（Application Service Provider）サービス型／オンライン型の医療マネジメント支援システムについて説明する。

情報処理端末機ＣＬは、例えば、パーソナルコンピュータの他、携帯電話機や携帯情報端末機（Personal Digital Assistant；ＰＤＡ）等から構成され、医師や看護師等によって操作されるものである。具体的には、情報処理端末機ＣＬは、図２４に示すように、各部を統括的に制御するＣＰＵ（Central Processing Unit）１１と、各種プログラムを含む各種情報を格納する読み取り専用のＲＯＭ（Read Only Memory）１２と、ワークエリアとして機能するＲＡＭ（Random Access Memory）１３と、各種情報を読み出し及び／又は書き込み可能に記憶する記憶部１４と、外部のネットワークに接続して通信を行う通信部１５と、ユーザインターフェースとしての図示しない所定の操作デバイスを介した入力操作の処理及び制御を行う入力操作制御部１６と、各種情報を表示する表示部１７とを備える。

ＣＰＵ１１は、記憶部１４等に格納されている各種アプリケーションプログラムをはじめとする各種プログラムを実行し、各部を統括的に制御する。例えば、ＣＰＵ１１は、サーバＳＶに対してアクセスするためのアプリケーションプログラムを実行し、その画面を表示部１７に表示させる。

ＲＯＭ１２は、各種プログラムをはじめとする各種情報を格納している。このＲＯＭ１２に格納されている情報は、ＣＰＵ１１の制御のもとに読み出される。

ＲＡＭ１３は、ＣＰＵ１１が各種プログラムを実行する際のワークエリアとして機能し、ＣＰＵ１１の制御のもとに、各種情報を一時記憶するとともに、記憶している各種情報を読み出す。

記憶部１４は、ＣＰＵ１１の制御のもとに、サーバＳＶに対してアクセスするためのアプリケーションプログラムの他、各種画像データや音声データをはじめとする各種情報を記憶するとともに、記憶している各種情報を読み出す。この記憶部１４としては、例えば、ハードディスクや不揮発性メモリ等を用いることができる。また、記憶部１４には、本体に対して着脱可能とされるフレキシブルディスクやメモリカード等の記憶媒体に対して、各種情報の読み出し及び／又は書き込みを行うドライブ装置も含まれる。

通信部１５は、例えば、アナログ回線、いわゆるイーサネット（登録商標）等から構成されるＬＡＮ（Local Area Network）、ＩＳＤＮ（Integrated Services Digital Network）、ＡＤＳＬ（Asymmetric Digital Subscriber Line）、若しくはＦＴＴＨ（Fiber To The Home）等の各種ネットワーク回線、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．１１に準拠した無線ＬＡＮ若しくはいわゆるブルートゥース（Bluetooth（登録商標））等の各種無線通信方式、又はいわゆるＦＯＭＡ（登録商標）等のＷ−ＣＤＭＡ（Wideband-Code Division Multiple Access）方式若しくはＨＤＲ（High Data Rate）等のＣＤＭＡ−２０００方式といった、各種方式に基づくネットワークに接続するためのインターフェースであり、ＣＰＵ１１の制御のもとに、外部との通信を行う。

入力操作制御部１６は、例えば、キーボード、マウス、キーパッド、赤外線リモートコントローラ、スティックキー、又はプッシュボタンといった、ユーザインターフェースとしての図示しない所定の操作デバイスを介した入力操作を受け付け、操作内容を示す制御信号をＣＰＵ１１に対して供給する。

表示部１７は、例えば、液晶ディスプレイ（Liquid Crystal Display；ＬＣＤ）、プラズマ・ディスプレイ・パネル（Plasma Display Panel；ＰＤＰ）、有機エレクトロルミネッセンス（Organic ElectroLuminescent）ディスプレイ、又はＣＲＴ（Cathode Ray Tube）といった、各種表示デバイスであり、ＣＰＵ１１の制御のもとに、各種画像データや、その他の各種情報を表示する。例えば、表示部１７は、サーバＳＶから送信された画像情報を表示する。

このような各部を備える情報処理端末機ＣＬは、ＣＰＵ１１の制御のもとに、サーバＳＶに対してアクセスし、当該サーバＳＶによって提供されるプロジェクトネットワーク図の作成や閲覧等をはじめとする上述した各種画面を表示部１７に表示する。

サーバＳＶは、情報処理端末機ＣＬと同様に、物理的には図２４に示したような各部を備えるものとして構成される。このようなサーバＳＶは、記憶部１４等に所定の医療マネジメント支援プログラムを実装しており、この医療マネジメント支援プログラムをＣＰＵ１１によって実行することにより、情報処理端末機ＣＬを操作する医師や看護師等に対する支援を行う。具体的には、サーバＳＶは、アクセスしてきた情報処理端末機ＣＬからの要求に応じて、ＣＰＵ１１の制御のもとに、記憶部１４等に記憶されているプロジェクトネットワーク図やタスク等のテンプレートをはじめとする各種データベースから読み出した情報に基づいて、後述するような画面を作成し、作成した画面を情報処理端末機ＣＬの表示部１７に表示させる。また、サーバＳＶは、ＣＰＵ１１の制御のもとに、情報処理端末機ＣＬによって入力された内容に基づいて、データベースに対して各種情報を格納し、その結果からなる画面を情報処理端末機ＣＬの表示部１７に表示させる。

より具体的には、サーバＳＶは、ＣＰＵ１１の制御のもとに、医療マネジメント支援プログラムを実行することにより、医療従事者の操作に応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成手段としての機能を実現する。また、サーバＳＶは、ＣＰＵ１１の制御のもとに、医療マネジメント支援プログラムを実行することにより、作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶部１４等に記憶させ、少なくとも記憶部１４等に記憶されているプロジェクトネットワーク図を、医療従事者が閲覧する情報処理端末機ＣＬの表示部１７に表示させる制御手段としての機能を実現する。さらに、サーバＳＶは、既存の医療機関情報システムとの間で情報の授受を行う通信手段としての機能を実現する。

ここで、サーバＳＶの記憶部１４等に形成されるデータベースは、例えば図２５に示すような各種テーブルから構成される。なお、同図においては、各テーブルに属する細かい属性は省略し、主なテーブルの関連性を明記するに留めている。具体的には、データベースには、リソースに関する情報を記述したリソーステーブル、医療従事者に関する情報を記述した従事者テーブル、タスクに関する情報を記述したタスクテーブル、臨床評価指標や臨床的アウトカム（クオリティインディケータ；ＱＩ）に関する情報を記述したクオリティインディケータテーブル、患者に関する情報を記述した患者テーブル、ＩＣＤ−１０コードに関する情報を記述したＩＣＤ−１０テーブル、ＤＰＣ分類コードに関する情報を記述したＤＰＣテーブル、プロジェクトネットワーク図に関する情報を記述したネットワークテーブル、リソースと医療従事者との関係を記述したリソース＿従事者テーブル、タスクとクオリティインディケータとの関係を記述したタスク＿ＱＩテーブル、患者とタスクとプロジェクトネットワーク図との関係を記述した患者＿タスク＿ネットワークテーブル、タスクとプロジェクトネットワーク図との関係を記述したタスク＿ネットワークテーブル、各タスクの内容を記述したタスクプロパティテーブル、各タスクの詳細を記述したタスク詳細テーブル等が格納される。

リソーステーブルは、属性データとして、リソースに固有のＩＤを主キー（ＰＫ）とし、リソース名称等の情報を記述する。また、従事者テーブルは、属性データとして、医療従業者に固有のＩＤを主キー（ＰＫ）とし、従業者名称等の情報を記述する。さらに、タスクテーブルは、属性データとして、タスクに固有のＩＤを主キー（ＰＫ）とし、タスク名称等の情報を記述する。さらにまた、クオリティインディケータテーブルは、属性データとして、ＱＩに固有のＩＤを主キー（ＰＫ）とし、その具体的な完了基準等の情報を記述する。また、患者テーブルは、属性データとして、患者に固有のＩＤを主キー（ＰＫ）として記述する。さらに、ＩＣＤ−１０テーブルは、属性データとして、ＩＣＤ−１０コードを主キー（ＰＫ）とし、ＩＣＤ−１０の名称等の情報を記述する。さらにまた、ＤＰＣテーブルは、属性データとして、ＤＰＣ分類コードを主キー（ＰＫ）とし、ＩＣＤ−１０コードを外部キー（ＦＫ）として記述する。また、ネットワークテーブルは、属性データとして、プロジェクトネットワーク図に固有のＩＤを主キー（ＰＫ）とし、ＤＰＣ分類コードを外部キー（ＦＫ）として記述する。

リソース＿従事者テーブルは、そのＩＤを主キー（ＰＫ）とし、リソースに固有のＩＤと医療従業者に固有のＩＤとを外部キー（ＦＫ）として記述することにより、リソースと医療従事者との関係を定義する。また、タスク＿ＱＩテーブルは、そのＩＤを主キー（ＰＫ）とし、ＱＩに固有のＩＤとタスクに固有のＩＤとを外部キー（ＦＫ）として記述することにより、タスクとクオリティインディケータとの関係を定義する。さらに、患者＿タスク＿ネットワークテーブルは、そのＩＤを主キー（ＰＫ）とし、患者に固有のＩＤを外部キー（ＦＫ）として記述することにより、患者とタスクとプロジェクトネットワーク図との関係を定義する。さらにまた、タスク＿ネットワークテーブルは、そのＩＤを主キー（ＰＫ）とし、タスク＿ＱＩテーブルのＩＤと患者＿タスク＿ネットワークテーブルのＩＤとネットワークＩＤ等を外部キー（ＦＫ）として記述することにより、タスクとプロジェクトネットワーク図との関係を定義する。また、タスクプロパティテーブルは、そのＩＤを主キー（ＰＫ）とし、リソース＿従事者テーブルのＩＤと患者＿タスク＿ネットワークテーブルのＩＤとを外部キー（ＦＫ）として記述することにより、各タスクの内容を定義する。さらに、タスク詳細テーブルは、そのＩＤを主キー（ＰＫ）とし、タスクプロパティテーブルのＩＤを外部キー（ＦＫ）として記述することにより、各タスクの詳細を定義する。

なお、医療マネジメント支援システムにおいては、例えば患者に関する詳細情報やクオリティインディケータの計算に用いる検査値といったように、当該医療マネジメント支援システムに特有ではない情報は、電子カルテやそのリポジトリの属性を正確に指定することにより、参照又はインポートすることができる。

このような情報処理端末機ＣＬ及びサーバＳＶから構成される医療マネジメント支援システムにおいては、サーバＳＶが、ＣＰＵ１１の制御のもとに、医療マネジメント支援プログラムを実行し、医師や看護師等によって入力指定されて情報処理端末機ＣＬから送信されてきた各種情報やデータベースに記憶された情報に基づいて、プロジェクトネットワーク図等を作成し、情報処理端末機ＣＬに対して送信することにより、当該医師や看護師等に各種情報を閲覧させる。

具体的には、医療マネジメント支援システムを糖尿病の教育入院に適用すると、以下のようになる。

成人になってから発症する２型糖尿病は、重症になると血糖をコントロールするためにインスリンと称されるホルモンを補充する治療が必要となる。インスリンの注射量は、糖尿病の程度や個人の状態等に応じて変化する。インスリンの過剰摂取は、低血糖を招来する一方で、過小摂取は、高血糖が持続し、心疾患や脳血管障害の合併頻度を高める。したがって、糖尿病患者は、初めてインスリンによる治療を開始する場合には、適正なインスリン量を調整するための自己血糖測定方法を学習するとともに、自宅や外出先等で適切に自己注射を行うためのトレーニングを受けるために、一定期間入院する。これを教育入院という。

図２６に、糖尿病教育入院のプロジェクトネットワーク図を示す。すなわち、このプロジェクトネットワーク図は、退院までに、タスクＴ１としての足のケア、タスクＴ２としての血糖コントロール、タスクＴ３としての患者への自己血糖測定指導、及びタスクＴ４としての患者への自己注射指導を行うように構成される。医療マネジメント支援システムにおいては、患者の入院が決定すると、情報処理端末機ＣＬからサーバＳＶに対してアクセスし、このようなプロジェクトネットワーク図を作成することから処理を開始する。

まず、医療マネジメント支援システムにおいては、タスクの設定を行う。ここでは、退院時の基準として、「食後２時間後の血糖が４００ｍｇ／ｄｌ以下である状態を３日以上継続した場合であり、且つ、決められた足のケアを終了していること」を設定する。また、各タスクＴ１，Ｔ２，Ｔ３，Ｔ４の完了基準としては、それぞれ、図２７に示すように設定する。すなわち、タスクＴ１は、「足のケアを行うこと」と「足のケアに関する指導を行うこと」を完了基準とする。また、このタスクＴ１の評価対象は、プロセスであるため、実行したか否かを示す１，０等の数値で表されることになる。タスクＴ２は、「全ての食後２時間後の血糖が４００ｍｇ／ｄｌ以下である状態が３日連続したこと」を完了基準として設定する。また、このタスクＴ２の評価対象は、臨床的アウトカムである。タスクＴ３は、「標準化された自己血糖測定指導の実施」と、「血糖測定とその記録の手順試験に合格すること」と、「自己効力感のスコアが所定点数以上であること」を完了基準として設定する。また、このタスクＴ３の評価対象は、「標準化された自己血糖測定指導の実施」がプロセスであり、「血糖測定とその記録の手順試験に合格すること」及び「自己効力感のスコアが所定点数以上であること」が臨床的アウトカムである。タスクＴ４は、「標準化された自己注射指導の実施」と、「自己注射の手順試験に合格すること」と、「自己効力感のスコアが所定点数以上であること」を完了基準として設定する。また、このタスクＴ４の評価対象は、「標準化された自己注射指導の実施」がプロセスであり、「自己注射の手順試験に合格すること」及び「自己効力感のスコアが所定点数以上であること」が臨床的アウトカムである。

また、医療マネジメント支援システムにおいては、各タスクに必要なリソースの設定を行う。なお、糖尿病教育入院の場合には、全てのタスクに患者本人がリソースとして関与することになる。具体的には、各タスクＴ１，Ｔ２，Ｔ３，Ｔ４に必要なリソースとしては、それぞれ、図２８に示すように設定する。すなわち、タスクＴ１，Ｔ３，Ｔ４に必要なリソースは、患者本人及び看護師であり、タスクＴ２に必要なリソースは、患者本人、担当医師、及び看護師である。

ここで、タスクＴ２としての血糖コントロールは、一度だけ行えばよい一塊のタスクではなく、図２９に示すように、完了条件を満たすまで、毎日繰り返し行われるものである。したがって、医療マネジメント支援システムにおいては、かかる繰り返しタスクを設定し、これを考慮した上で、各タスクＴ１，Ｔ２，Ｔ３，Ｔ４の第１の完了期間ＡＢＰと第２の完了期間ＨＰとを設定する。ここでは、各タスクＴ１，Ｔ２，Ｔ３，Ｔ４の第１の完了期間ＡＢＰ及び第２の完了期間ＨＰとして、図３０に示すように設定する。

そして、医療マネジメント支援システムにおいては、上述したプロジェクトバッファＰＢやフィーディングバッファＦＢを設定し、最も長い期間を要する経路をクリティカルチェーンとして求める。具体的には、医療マネジメント支援システムにおいては、図３１に示すようなクリティカルチェーンモデルを作成する。このクリティカルチェーンモデルにおいては、２つのタスクＴ２，Ｔ３がクリティカルチェーンを構成するタスクである。したがって、この患者が退院するまでの予定日数は、タスクＴ２，Ｔ３のそれぞれの第１の完了期間ＡＢＰを加算した５日間と、タスクＴ２の直後に設けられたプロジェクトバッファＰＢの６日間とを加算した１１日間となり、上表３に示したＩＩ期の略中央となる。

医療マネジメント支援システムにおいては、このようなプロジェクトネットワーク図を作成するために、サーバＳＶが医療マネジメント支援プログラムを実行することにより、当該プロジェクトネットワーク図を作成する医療従事者が操作する情報処理端末機ＣＬの表示部１７に例えば図３２に示すようなネットワーク図作成画面を表示させる。このネットワーク図作成画面には、作成されたプロジェクトネットワーク図を表示するネットワーク図表示領域５１と、タスクの設定を行うためのタスクプロパティ設定領域５２と、タスクが後述するサブタスクを含んでいる場合にそのサブタスクを表示するサブタスク表示領域５３と、サブタスクの設定を行うためのサブタスクプロパティ設定領域５４とが設けられる。なお、同図においては、作成されたプロジェクトネットワーク図がネットワーク図表示領域５１に表示されている様子を示しているが、処理の開始時には、何も表示されていないことは勿論である。

医療マネジメント支援システムにおいては、かかるネットワーク図作成画面を情報処理端末機ＣＬの表示部１７に表示した状態で、プロジェクトネットワーク図の作成を行う。すなわち、サーバＳＶは、情報処理端末機ＣＬの操作に応じて、ネットワーク図表示領域５１にタスクやバッファ等を示すオブジェクトを配置することにより、新規のプロジェクトネットワーク図を作成する。また、サーバＳＶは、情報処理端末機ＣＬの操作に応じて、記憶部１４等に形成されたデータベースから、テンプレート化されているプロジェクトネットワーク図を検索し、そのプロジェクトネットワーク図をネットワーク図表示領域５１に表示させることもできる。このとき、サーバＳＶは、情報処理端末機ＣＬを介して入力されたＩＣＤ−１０コード、患者を識別するための患者ＩＤ、医師や病棟、医療機関といったユーザの定義等を条件として検索を行うことができる。また、サーバＳＶは、上述したように、テンプレート化されたプロジェクトネットワーク図がウェブ上に公開されている場合には、条件に合致するプロジェクトネットワーク図をダウンロードし、ネットワーク図表示領域５１に表示させることもできる。

記憶部１４等のデータベースから読み出したり、ウェブ上からダウンロードしたりしたプロジェクトネットワーク図は、患者の状態等に応じて任意に変更可能とされる。例えば、サーバＳＶは、症状の把握等に時間がかかりそうな患者の場合には、情報処理端末機ＣＬの操作に応じて、各タスクの第１の完了期間ＡＢＰや第２の完了期間ＨＰを長めに設定したり、新たなタスクを追加したりし、修正されたプロジェクトネットワーク図をネットワーク図表示領域５１に表示させる。

また、ネットワーク図表示領域５１に表示されたプロジェクトネットワーク図を構成する個々のタスクは、情報処理端末機ＣＬのマウス操作等に応じて選択され、タスクプロパティ設定領域５２を介して、その詳細情報の設定を行うことができる。サーバＳＶは、情報処理端末機ＣＬの操作に応じて、このタスクプロパティ設定領域５２を介して、そのタスクの完了基準、そのタスクに必要なリソース、第１の完了期間ＡＢＰや第２の完了期間ＨＰ、及び、例えばそのタスクを実行しなければならない開始日及び終了日や、その他のタスクとのリードタイムといった時間的な制約等を設定する。なお、図３２には、タスクＴ１としての足のケアについて、詳細情報を設定する様子を示している。

より具体的には、タスクプロパティ設定領域５２には、そのタスクのＤＰＣ分類コードやＩＣＤ−１０コードが表示領域５５に表示される。ＤＰＣ分類コードやＩＣＤ−１０コードは、当該医療マネジメント支援システムが電子カルテシステムと連携している場合には、その電子カルテシステムから参照することができる。ここで、医療マネジメント支援システムにおいては、ＩＣＤ−１０コードを軸にＤＰＣ分類コードに応じてタスクのＩＤを設定することにより、他の医療機関との情報共有を容易に行うことが可能となる。また、タスクプロパティ設定領域５２には、ＤＰＣ分類コードがある場合には、例えばＩ期やＩＩ期といったそのＤＰＣ分類コードの情報が表示され、その他の場合には、ＩＣＤ−１０コードに応じた平均入院日数といったように、そのタスクの第１の完了期間ＡＢＰや第２の完了期間ＨＰを決定するための参考となる情報が表示される。

また、タスクプロパティ設定領域５２には、そのタスクの完了基準が表示領域５６に表示される。これら完了基準は、プロセスの場合には実行したか否かを示す数値で設定され、臨床的アウトカムの場合には具体的な数値で設定される。また、完了基準としては、評価の目的等も同時に設定可能である。これら数値や評価の目的等は、情報処理端末機ＣＬの操作に応じて任意に設定可能であるが、データベースから抽出することも可能である。さらに、完了基準のうち学会等で認められた臨床評価指標には、その旨を示すマーク５７が付与され、このマーク５７が情報処理端末機ＣＬを介して選択されるのに応じて、その臨床評価指標についての詳細な解説情報が表示される。さらにまた、タスクプロパティ設定領域５２には、そのタスクに必要なリソースが表示領域５８に表示される。これらリソースは、情報処理端末機ＣＬの操作に応じて、デフォルトで設定されているもの以外にも追加したり、不要なものを削除したりすることができる。また、タスクプロパティ設定領域５２には、第１の完了期間ＡＢＰや第２の完了期間ＨＰを入力する入力ボックス５９が表示される。なお、完了基準やリソースは、その情報量が多くなる場合には、それらの表示領域５６，５８を折り畳み表示することも可能である。

ここで、タスクプロパティ設定領域５２を介して設定されるタスクは、その完了までの日数が見積もられているが、現実の医療においては、これらのタスクが終日行われることは、手術等の特殊な場合を除いてさほど多くない。例えば、レントゲン検査というタスクが行われるのは、１日のうち３０分程度であり、その他の時間は、患者リソースの立場からは、リソースの競合が起こらない限り、他のタスクに費やしてもよい。

また、複数のリソースが関与するタスクの場合には、リソースの関与が時間的に並列の場合と直列の場合とがある。例えば、足のケアというタスクには、足ケア士による診察を行い、その診察結果に基づいて看護師が指導を行う、といったように、異なるリソースが関与する２つのタスクが時間的に直列に存在することになる。すなわち、足のケアというタスクには、足ケア士と患者をリソースとする「診察」というサブタスクと、看護師と患者をリソースとする「指導」というサブタスクとが存在することになる。

かかるタスクを患者からみた場合には、当該タスクは単一であるが、各リソースのスケジューリングを考慮する観点からは、サブタスクを個々に設定する必要がある。そこで、医療マネジメント支援システムにおいては、サブタスク表示領域５３とサブタスクプロパティ設定領域５４とを情報処理端末機ＣＬの表示部１７に表示させる。サーバＳＶは、情報処理端末機ＣＬの操作に応じて、ネットワーク図表示領域５１を介したプロジェクトネットワーク図の作成と同様の手順にしたがって、サブタスク表示領域５３を介してサブタスクのネットワーク図を作成することができる。また、サーバＳＶは、情報処理端末機ＣＬの操作に応じて、タスクプロパティ設定領域５２を介したタスクの設定と同様の手順にしたがって、サブタスクプロパティ設定領域５４を介してサブタスクの設定を行うことができる。なお、サブタスクは、主にリソースのスケジューリングを目的とすることから、リソースの関与を細かく設定することになる。

医療マネジメント支援システムにおいては、このようなネットワーク図作成画面を介してプロジェクトネットワーク図を作成すると、記憶部１４等に形成されたデータベースに記憶させる。そして、医療マネジメント支援システムにおいては、サーバＳＶが医療マネジメント支援プログラムを実行することにより、作成されたプロジェクトネットワーク図に基づいて、様々な管理画面を情報処理端末機ＣＬの表示部１７に表示させる。

まず、医療マネジメント支援システムにおいては、病棟、診療部門、及び診療科等のスケジュール管理者が操作する情報処理端末機ＣＬの表示部１７に、例えば図３３に示すように、複数の患者のスケジュールを管理するための管理画面を表示させる。この管理画面には、患者の氏名やＩＤを表示する患者表示領域６１と、臨床的（clinical）な緊急度を表示する臨床的緊急度表示領域６２と、クリティカルチェーン理論におけるバッファの状況を表示するバッファ状況表示領域６３と、患者に対する施術の進捗状況、すなわち、プロジェクトの進捗状況を表示する進捗状況表示領域６４とが設けられる。なお、同図においては、５人の患者Ａ，Ｂ，Ｃ，Ｄ，Ｅに関する情報のみが表示されている様子を示しているが、実際には、管理対象の患者全員分の情報を表示することができるのは勿論である。

患者表示領域６１は、各患者を識別するための領域である。サーバＳＶは、この患者表示領域６１に表示された任意の患者が情報処理端末機ＣＬを介して選択されるのに応じて、当該患者のプロジェクトネットワーク図を当該情報処理端末機ＣＬの表示部１７に表示させることができる。なお、この患者表示領域６１に表示される患者の順序は、その氏名順であってもよい。また、患者表示領域６１に表示される患者の順序は、例えば図３４に示すように、臨床的な緊急度やバッファの状況に応じて並べ替えることもできる。これにより、医療マネジメント支援システムにおいては、病棟や医療チーム等における会議を行う際に、臨床的な緊急度が高い患者やバッファの残存量が少ない患者への対処を優性して行うという目安として利用することが可能となる。また、混合病棟等においては、科名やその他の条件による検索を行い、条件に合致した患者に関する情報のみを情報処理端末機ＣＬの表示部１７に表示させることにより、患者数を絞り込むことも可能である。

臨床的緊急度表示領域６２は、臨床的な緊急度を色分け等によって識別可能に表示する領域である。サーバＳＶは、ＩＣＤ−１０コード、病棟、医師、及び患者等の状況に応じて、予め定められた規則に該当した場合に、臨床的緊急度表示領域６２に表示する色を変化させる。また、臨床的緊急度表示領域６２に表示される色は、各科管理者や病棟管理者、担当医師チーム等の判断で任意に変更することも可能である。例えば、合併症等を含む臨床的な突発事態が生じた症例の場合には、臨床的緊急度表示領域６２には「赤色」を表示する。これにより、管理者は、現在作成されているスケジュールとは無関係にリソースの割り付けを考えたり、必要に応じて、当該患者のプロジェクトネットワーク図の変更も考慮したりすることが可能となる。医療マネジメント支援システムにおいては、全ての患者が臨床的に緊急状態とならないように運用することになる。

バッファ状況表示領域６３は、プロジェクトマネジメント、すなわち、クリティカルチェーン理論におけるバッファの状況を色分け等によって識別可能に表示する領域である。サーバＳＶは、残存する第１の完了期間ＡＢＰと、残存するバッファの期間とに基づいて、バッファ状況表示領域６３に表示する色を変化させる。例えば、バッファ状況表示領域６３には、実際のプロジェクトの進捗状況と照合したときに、残存するタスクを行う上で必要なバッファの残存量が予定の２／３以上である場合には上述した「安全区域」を示す「青色」を表示する。また、バッファ状況表示領域６３には、実際のプロジェクトの進捗状況と照合したときに、残存するタスクを行う上で必要なバッファの残存量が予定の１／３以上２／３未満である場合には上述した「注意区域」を示す「黄色」を表示する。医療マネジメント支援システムにおいては、バッファ状況表示領域６３が「黄色」を表示した場合には、関連部署や医療チームでプロジェクトが遅延している原因を考察し、当該バッファ状況表示領域６３が「赤色」になった場合の対処方法について検討する。このとき、医療マネジメント支援システムにおいては、必要に応じて、当該患者のプロジェクトネットワーク図の変更も考慮する必要もあるが、クリティカルチェーン理論にしたがって、この時点では臨床的に必要がある場合を除いて行動を起こさないように運用する。さらに、バッファ状況表示領域６３には、実際のプロジェクトの進捗状況と照合したときに、残存するタスクを行う上で必要なバッファの残存量が予定の１／３以下となった場合には上述した「危険区域」を示す「赤色」を表示する。医療マネジメント支援システムにおいては、バッファ状況表示領域６３が「赤色」を表示した場合には、当該バッファ状況表示領域６３が「黄色」を表示した場合に検討した対処方法を実施することになる。このとき、医療マネジメント支援システムにおいては、合併症等が生じている場合には、ＤＰＣ分類コードの変更とともに、プロジェクトネットワーク図の変更を考慮する。

進捗状況表示領域６４は、プロジェクトの進捗状況を日付とともにバー状に表示する領域である。サーバＳＶは、作成されたプロジェクトネットワーク図と、実際の進捗状況とに基づいて、進捗状況表示領域６４に表示するバーの長さや色等を変化させる。

医療マネジメント支援システムにおいては、このような管理画面を介して、病棟、診療部門、及び診療科等の管理者が各患者の管理を行うことができる。

また、医療マネジメント支援システムにおいては、患者を担当する医師が操作する情報処理端末機ＣＬの表示部１７に、例えば図３５に示すように、患者に対する診療内容を記録するとともに当該患者を管理するための管理画面を表示させる。この管理画面には、医師が受け持っている患者についてのタスクやＴｏＤｏ等の一覧を表示する受け持ち患者一覧表示領域７１と、この受け持ち患者一覧表示領域７１に表示された患者のうち選択された患者についてのタスクやＴｏＤｏ等の一覧を表示する受け持ち患者表示領域７２と、選択された患者に対するプロジェクトの進捗状況を表示する進捗状況表示領域７３と、受け持ち患者表示領域７２に表示されたタスクのうち選択されたタスクの完了基準を表示する完了基準表示領域７４と、この完了基準表示領域７４に表示された完了基準の達成率と直接関与する情報が表示される達成率情報表示領域７５と、受け持ち患者表示領域７２に表示された各タスクに対する診療内容を記録及び表示する診療内容記録・表示領域７６と、受け持ち患者表示領域７２に表示された各タスクに対する全ての記録を検索するタスク記録検索領域７７と、このタスク記録検索領域７７を介して検索されたタスクの記録を表示するタスク記録表示領域７８とが設けられる。

受け持ち患者一覧表示領域７１は、現時点で各医師が受け持っている患者についてのタスクやＴｏＤｏ等の一覧を表示する領域である。サーバＳＶは、ＩＣＤ−１０コード、病棟、医師、及び患者等の状況、残存する第１の完了期間ＡＢＰ、バッファ残存量、作成されたプロジェクトネットワーク図、実際の進捗状況等に基づいて、受け持ち患者一覧表示領域７１に各種情報を表示させる。具体的には、受け持ち患者一覧表示領域７１には、例えば図３６に示すように、患者が在床している病棟名、患者の氏名、上述した臨床的な緊急度、バッファ残存量、プロジェクトの進捗状況、実行すべきタスク、他職種のリソースや患者からリクエストがあったＴｏＤｏとしてのタスクであるか否かを示すＴｏＤｏマーク等の情報が一覧形式で表示される。ここで、医療マネジメント支援システムにおいては、ある患者を複数の医師がチームを組んで診療している場合には、その時点での病棟担当医や検査担当者となっている医師のみが、この受け持ち患者一覧表示領域７１に表示される情報を閲覧可能であり、たとえ病棟担当医であっても、外来といった他の仕事をしている間は、病棟医リソースとして認識されていないため、受け持ち患者一覧表示領域７１に表示される情報を閲覧することができない仕組みを設けている。これは、以下の理由による。

リソースとは、プロジェクト用語で、タスクを完了するために必要な人材、機材、資材を意味する。例えば、ＣＴ検査というタスクにおいては、ＣＴという機材と、放射線科医師、担当医師、看護師、放射線技師、患者というリソースが必要となる。ここで、医師は、個人で複数のリソースとなることが多く、また、同時期に異なる場所から異なる形のリソースとして要求されることも多い。すなわち、医師は、上述したBad Multi-taskingの原因となりやすいリソースである。したがって、医療マネジメント支援システムにおいては、Bad Multi-taskingを防止するために、１人の医師が「外来医」というリソースとして働いている場合には、その医師を「病棟担当医」や「検査担当医」というリソースのタスクから解放し、完全に「外来医」リソースとして外来医がなすべきタスクに集中できるように、医師の役割シフトをカレンダとしてデータベースに記憶させる。なお、医療マネジメント支援システムにおいては、医師のシフトを設定することにより、Bad Multi-taskingを防止することができるものの、これは同時に複数の医師が互いの役割を補完しあうためのチームを組む必要性を増大させることになる。例えば、終日、外来医リソースとなる医師は病棟に行くことができないため、他の医師が「病棟医」リソースとして病棟業務をカバーすることになる。

受け持ち患者表示領域７２は、受け持ち患者一覧表示領域７１に表示された患者のうち、情報処理端末機ＣＬを介して選択された患者についてのタスクやＴｏＤｏ等の一覧を表示する領域である。具体的には、受け持ち患者表示領域７２には、例えば図３７に示すように、各タスクについて、主観的所見（Ｓ）、客観的所見（Ｏ）、アセスメント（Ａ）、プラン（Ｐ）のいずれかに新たな記載があった場合には、その旨を把握できるようなマークが表示される。また、受け持ち患者表示領域７２には、他職種のリソースや患者から何らかのリクエストがあった場合には、その旨を把握できるように、ＴｏＤｏマークが表示される。医療マネジメント支援システムにおいては、このＴｏＤｏマークとして識別されるタスクが緊急を要するものである場合には、サーバＳＶの制御のもとに、医療機関内のＰＨＳ（Personal Handyphone System）等、医師等を呼び出すためのコールシステムを動作させたり、医師等が操作する情報処理端末機ＣＬの表示部１７に緊急を報知する割り込み情報を表示させたりする。

進捗状況表示領域７３は、上述した進捗状況表示領域６４と同様に、受け持ち患者一覧表示領域７１に表示された患者のうち、情報処理端末機ＣＬを介して選択された患者に対するプロジェクトの進捗状況をバー状に表示する領域である。サーバＳＶは、作成されたプロジェクトネットワーク図と、実際の進捗状況とに基づいて、進捗状況表示領域７３に表示するバーの長さや色等を変化させる。また、進捗状況表示領域７３は、プロジェクトの進捗状況とともに、臨床的な緊急度やバッファの状況等を表示するようにしてもよい。

完了基準表示領域７４は、受け持ち患者表示領域７２に表示されたタスクのうち、情報処理端末機ＣＬを介して選択されたタスクの完了基準を表示する領域である。また、完了基準表示領域７４には、表示した完了基準が臨床評価指標である場合には、その旨を示すマークが表示され、このマークが情報処理端末機ＣＬを介して選択されるのに応じて、その臨床評価指標の意義や使い方、過去における当該医師個人、病棟、診療科、医療機関全体といった単位別の達成率等の詳細情報が表示される。このとき、完了基準表示領域７４には、臨床評価指標の達成率が、現時点のもののみならず、過去からの傾向として表示される。さらに、医療マネジメント支援システムにおいては、地域や全国における臨床評価指標の達成率とリンクさせることにより、ベンチマークを行うことも可能となる。

達成率情報表示領域７５は、完了基準表示領域７４に表示された完了基準の達成率と直接関与する情報を表示する領域である。医療マネジメント支援システムにおいては、この達成率情報表示領域７５を介して、完了基準に関する具体的な数値情報を閲覧することができる。また、医療マネジメント支援システムにおいては、その完了基準が設定されたタスクの進捗状況をバー状に表示するとともに、臨床的な緊急度やバッファの状況等を表示する。

診療内容記録・表示領域７６は、受け持ち患者表示領域７２に表示された各タスクに対する診療内容を記録するための領域であり、また、記録された診療内容を表示する領域である。サーバＳＶは、この診療内容記録・表示領域７６を用いて情報処理端末機ＣＬを介して入力された情報をデータベースに記憶するとともに、当該診療内容記録・表示領域７６に表示させる。この診療内容記録・表示領域７６は、ある意味では診療録としての役割を果たすものであるが、診療内容の検索を重視するため、可能な限り多くの項目を数値や選択項目の形式で入力するように構成されるのが望ましい。また、診療内容記録・表示領域７６は、メモとして、上述した主観的所見（Ｓ）、客観的所見（Ｏ）、アセスメント（Ａ）、プラン（Ｐ）を画像やテキスト等を用いて記録可能とし、これらメモとして記録した所見等を時系列で表示することもできる。なお、この診療内容記録・表示領域７６を介して記録される情報は、あくまでも「医療の質」と「プロジェクトの管理」とに必要な情報を取り出すために必要な情報であり、いわゆる「カルテ」」的な診療録ではないことは勿論である。

タスク記録検索領域７７及びタスク記録表示領域７８は、診療内容記録・表示領域７６が医師個人の記録を閲覧するためのものであるのに対して、自己のみならず他の医師等が記録した内容を含め、各タスクに対する全ての記録を閲覧するためのものである。タスク記録検索領域７７は、受け持ち患者表示領域７２に表示された各タスクに対する全ての記録を検索するための領域である。サーバＳＶは、このタスク記録検索領域７７を介して選択された、リソース、上述した主観的所見（Ｓ）、客観的所見（Ｏ）、アセスメント（Ａ）、プラン（Ｐ）の種類、年月日等の条件に基づいて、合致するタスクに対する全ての記録を検索し、検索結果を時系列順にタスク記録表示領域７８に表示する。

医療マネジメント支援システムにおいては、このような管理画面を介して、各医師が各患者の管理を行うことができる。

さらに、医療マネジメント支援システムにおいては、医療機関全体の最適化を図るために、情報処理端末機ＣＬの表示部１７に、例えば図３８に示すように、ＣＴスキャンやＭＲＩ検査等の管理を行うための管理画面を表示させる。この管理画面には、患者の氏名やＩＤを表示する患者表示領域８１と、臨床的な緊急度を表示する臨床的緊急度表示領域８２と、クリティカルチェーン理論におけるバッファの状況を表示するバッファ状況表示領域８３と、患者に対するプロジェクトの進捗状況を表示する進捗状況表示領域８４と、各検査に対する所見等を記録及び表示する所見記録・表示領域８５と、検査に使用する資材や物品等の利用記録を記録及び表示する利用記録・表示領域８６と、各検査に対する全ての記録を検索する検査記録検索領域８７と、この検査記録検索領域８７を介して検索された検査の記録を表示する検査記録表示領域８８とが設けられる。

患者表示領域８１は、各患者を識別するための領域である。サーバＳＶは、この患者表示領域６１に表示された任意の患者が情報処理端末機ＣＬを介して選択されるのに応じて、当該患者のプロジェクトネットワーク図や診療記録等を当該情報処理端末機ＣＬの表示部１７に表示させることができる。

臨床的緊急度表示領域８２は、上述した臨床的緊急度表示領域６２と同様に、臨床的な緊急度を色分け等によって識別可能に表示する領域である。また、バッファ状況表示領域８３は、上述したバッファ状況表示領域６３と同様に、クリティカルチェーン理論におけるバッファの状況を色分け等によって識別可能に表示する領域である。さらに、進捗状況表示領域８４は、上述した進捗状況表示領域６４と同様に、プロジェクトの進捗状況を日付とともにバー状に表示する領域である。サーバＳＶは、臨床的な緊急度やバッファの状況に応じて、予約された患者の検査順序を決定し、その順序で、これら患者表示領域８１、臨床的緊急度表示領域８２、バッファ状況表示領域８３、及び進捗状況表示領域８４の表示を行う。なお、サーバＳＶは、全ての患者に対する検査を当日中に行うことができない場合には、検査を行うことができない患者を翌日以降に振り分けるが、翌日の検査スケジュールを、前日の夕方時点での臨床的な緊急度とバッファの残存量とに基づいて決定し、おおよその検査予定を組み上げる。また、サーバＳＶは、当日に至急に行う必要が生じた検査についても、臨床的な緊急度とバッファの残存量とに基づいて決定する。特に、臨床的な緊急度は、「医師の判断」という主観的尺度ではなく、可能な限り、予め定められた客観的な尺度に基づいて決定する。

所見記録・表示領域８５は、検査時に記録すべき所見等を記録及び表示する領域である。この所見記録・表示領域８５を介して記録される情報は、上述した診療内容記録・表示領域７６と同様に、あくまでも「医療の質」と「プロジェクトの管理」とに必要な情報を取り出すために必要な情報が中心となる。ここで、所見記録・表示領域８５に記録すべき情報としては、検査毎にタスクに関連した項目からなるテンプレートを用いるのが望ましい。このとき、医療マネジメント支援システムにおいては、ベンチマークを行うことを考慮して、所見記録・表示領域８５に、少なくとも院内や地域毎に共通のフォーマットで情報を記録するのが望ましい。

利用記録・表示領域８６は、検査に使用する資材や物品等の利用記録を記録及び表示する領域であり、患者あたりの変動費用（variable cost）の参考に活用するための情報収集を目的として設けられる。サーバＳＶは、この利用記録・表示領域８６を用いて情報処理端末機ＣＬを介して入力された情報をデータベースに記憶するとともに、当該利用記録・表示領域８６に表示させる。医療マネジメント支援システムにおいては、この利用記録・表示領域８６の機能を、既存のオーダリングシステムや会計システム等と連携させてもよいが、請求金額の算出等を目的とするものはないため、当該利用記録・表示領域８６を介して記録する情報を、あくまでもリソースの配分という視点と変動費用の記録という視点とから策定する必要がある。

検査記録検索領域８７及び検査記録表示領域８８は、上述したタスク記録検索領域７７及びタスク記録表示領域７８と同様に、各検査に対する全ての記録を閲覧するためのものである。サーバＳＶは、検査記録検索領域８７を介して選択された、リソース、上述した主観的所見（Ｓ）、客観的所見（Ｏ）、アセスメント（Ａ）、プラン（Ｐ）の種類、年月日等の条件に基づいて、合致する検査に対する全ての記録を検索し、検索結果を時系列順に検査記録表示領域８８に表示する。

医療マネジメント支援システムにおいては、このような管理画面を介して、検査の予約状況等を把握し、医療機関全体の最適化を図ることができる。

さて、医療マネジメント支援システムにおいては、各リソース、ひいては各医療従事者が常に１つのタスクに集中するようなスケジューリングを行う。換言すれば、医療マネジメント支援システムにおいては、サーバＳＶにより、各医療従事者のスケジュール表を作成することができる。ここでは、看護師についての簡略的な看護スケジュールの例について説明する。

先に図２６に示した血糖コントロールというタスクＴ２は、上述したように、繰り返しタスクであるが、その第１の完了期間ＡＢＰとして少なくとも３日必要であり、所定の完了条件を満たすまで継続される。ここで、このタスクは、完了条件がある一定期間以上満たされない場合には、その患者を一旦退院させ、外来でのコントロールを行うことになる。そのため、このタスクの完了条件は、正確には、図２７に示した「全ての食後２時間後の血糖が４００ｍｇ／ｄｌ以下である状態が３日連続したこと」の他に、「この条件が満たされずに、○日間（図３０においては１０日間とした）入院が継続すること」となり、これらのいずれかが満たされた場合に、その患者が退院することになる。

ここで、血糖コントロールタスクＴ２は、終日行われる作業ではなく、例えば図３９に示すように、１日の中で小時間ずつ分散的に行われるものである。したがって、このタスクを担当するリソースが１人であったとしても、すなわち、血糖測定・指導の担当看護師が１人であったとしても、複数の患者に対してこのタスクを行うことが可能である。そのため、このタスクに必要な看護師リソースは、例えば、１人の看護師によって５人の患者を担当できるのであれば、１タスクあたり０．２人となる。

医療マネジメント支援システムにおいては、このようなタスクに対する必要リソース量をサーバＳＶによって求め、スケジュール表を作成する。図４０に、血糖コントロールタスクＴ２におけるある患者の１日のスケジュールのうち、午前６時３０分から午前９時過ぎまでのものを抜粋したものを示す。すなわち、医療マネジメント支援システムにおいては、タスクに対する必要リソース量に基づいて、時刻毎にサブタスクを並べてスケジュール表を作成する。なお、医療マネジメント支援システムにおいては、これらの情報を、先に図３２に示したサブタスクプロパティ設定領域５４を用いて設定することになる。

具体的には、このスケジュール表によれば、患者は、血糖コントロールタスクＴ２を構成する「採血」サブタスクＳＴ１と「インスリン注射」サブタスクＳＴ２とを行うことになる。ここで、このスケジュール表において、先に図３０に示したその他のタスク（タスクＴ３としての患者への自己血糖測定指導、及びタスクＴ４としての患者への自己注射指導）が同時に行われる場合には、これらの指導の時間を含むため、血糖コントロールタスクＴ２を構成する「採血」サブタスクＳＴ１と「インスリン注射」サブタスクＳＴ２とを長く設定する必要がある。また、同時に患者が使用するインスリンによってインスリン注射のタイミングが異なることになる。

さらに、この患者は、レギュラーインスリンを使用しており、タスクＴ３としての患者への自己血糖測定指導が同時に進行している。したがって、このスケジュール表においては、「採血」サブタスクＳＴ１の第１の完了期間ＡＢＰを「６分」に設定してあるが、タスクＴ３としての患者への自己血糖測定指導がない場合には、この第１の完了期間ＡＢＰを「２分」とすることができる。また、この「採血」サブタスクＳＴ１に対するプロジェクトバッファＰＢは、約４分に設定される。医療マネジメント支援システムにおいては、この「採血」サブタスクＳＴ１を行うと、看護師によって後述するＰＤＡ等の携帯可能な情報処理端末機ＣＬを介して血糖値を記録し、タスク完了の判定を行う。

さらにまた、この患者は、タスクＴ４としての患者への自己注射指導も同時に進行している。したがって、このスケジュール表においては、「インスリン注射」サブタスクＳＴ２の第１の完了期間ＡＢＰを「６分」に設定してあるが、タスクＴ４としての患者への自己血糖測定指導がない場合には、この第１の完了期間ＡＢＰを「２分」とすることができる。また、この「インスリン注射」サブタスクＳＴ２に対するプロジェクトバッファＰＢも、約４分に設定される。医療マネジメント支援システムにおいては、この「インスリン注射」サブタスクＳＴ２を行うと、看護師によって携帯可能な情報処理端末機ＣＬを介してタスク完了の記録が行われる。医療マネジメント支援システムにおいては、サーバＳＶの制御のもとに、この記録をデータベースに記憶させることにより、上述した各種画面に表示されるプロジェクトの進捗状況等に反映される。

そして、このスケジュール表によれば、患者は、レギュラーインスリンを使用していることから、原則的には、食前３０分前にインスリンの注射が完了している必要がある。換言すれば、この患者は、インスリン注射後３０分経過してから食事を摂取することになる。ここで、このスケジュール表においては、食事もサブタスクとなる。この「食事」サブタスクＳＴ３のリソースは、患者の食事介助が不要な場合には、患者のみとなる。なお、食事時間は、リソースのスケジュールには関係ないものの、患者に何らかの検査や処置を行う予定がある場合には重要である。

さらに、患者は、食後２時間後の血糖測定を行うために、「採血」サブタスクＳＴ４を行う。ここで、食後２時間後の血糖値とは、食事を開始してから２時間後の値である。そのため、看護師は、「インスリン注射」サブタスクＳＴ２の完了時に、患者に食事の開始時刻を指定するようにする。また、医療マネジメント支援システムにおいては、例えばバーコードやＩＣタグ等の記録媒体等を用い、患者が「食事」サブタスクＳＴ３を開始した時刻を情報処理端末機ＣＬを介してデータベースに入力して記憶させることにより、より正確なスケジューリングを行うことが可能となる。

このように、医療マネジメント支援システムにおいては、先に図３２に示したサブタスクプロパティ設定領域５４を用いてサブタスクの設定を行うことにより、スケジュール表を作成することができる。

なお、実際には、このようなサブタスクを有する患者が例えば糖尿病病棟等の１つの病棟に複数入院していることが考えられる。したがって、医療マネジメント支援システムにおいては、複数の患者、すなわち、複数のプロジェクトが存在することから、上述したプロジェクトの同期を行う必要がある。以下、１つの病棟に様々な条件を有する８人の糖尿病教育入院患者が在床している状態を例に挙げ、患者のスケジュール管理及び看護師のスケジュール管理について説明する。

図４１に、ここで用いる患者の状態を示す。すなわち、患者０１は、使用するインスリンの種類がレギュラーインスリンであり、上述したタスクＴ３としての患者への自己血糖測定指導、及びタスクＴ４としての患者への自己注射指導をともに行う必要がある状態である。また、患者０２は、使用するインスリンの種類が超即効インスリンであり、タスクＴ４としての患者への自己注射指導のみを行う必要がある状態である。さらに、患者０３は、使用するインスリンの種類がレギュラーインスリンであり、タスクＴ３，Ｔ４とも行う必要がない状態である。さらにまた、患者０４は、使用するインスリンの種類がレギュラーインスリンであり、タスクＴ４としての患者への自己注射指導のみを行う必要がある状態である。また、患者０５は、使用するインスリンの種類が超即効インスリンであり、タスクＴ３としての患者への自己血糖測定指導、及びタスクＴ４としての患者への自己注射指導をともに行う必要がある状態である。さらに、患者０６は、使用するインスリンの種類がレギュラーインスリンであり、タスクＴ３としての患者への自己血糖測定指導のみを行う必要がある状態である。さらにまた、患者０７は、使用するインスリンの種類が超即効インスリンであり、タスクＴ３としての患者への自己血糖測定指導のみを行う必要がある状態である。また、患者０８は、使用するインスリンの種類が超即効インスリンであり、タスクＴ３，Ｔ４とも行う必要がない状態である。

図４２に、同期されていない８人の患者０１，０２，・・・，０８のそれぞれの血糖コントロールタスクＴ２を構成するサブタスクのスケジュール表を示す。なお、同図においては、説明の便宜上、全ての患者０１，０２，・・・，０８のそれぞれのサブタスクに対する第１の完了期間ＡＢＰ及びプロジェクトバッファＰＢの長さを、タスクＴ３，Ｔ４の有無に応じて同一としているが、医療マネジメント支援システムにおいては、患者の特性等に応じて異なる値としてもよい。同図における「採血」サブタスク及び「インスリン注射」サブタスクに対する第１の完了期間ＡＢＰ及びプロジェクトバッファＰＢの長さは、図４０を用いた説明にて定義したものと同一である。

医療マネジメント支援システムにおいては、このような同期されていないプロジェクトに対してサーバＳＶによって上述した同期バッファＳＢを設定することにより、同期されたスケジュール表を作成する。図４３に、２人の看護師０１，０２が「採血」、「インスリン注射」、「確認」を担当するとしたときの同期されたスケジュール表を示す。なお、ここでは、看護師の視点からスケジュール表を作成するため、「採血」と「インスリン注射」は連続したサブタスクとし、患者間における移動を含めた同期バッファＳＢを設定している。なお、医療マネジメント支援システムにおいては、これらの情報を、先に図３２に示したサブタスクプロパティ設定領域５４を用いて設定することになる。

具体的には、このスケジュール表によれば、図４３右端に示すように、一方の看護師０１が、４人の患者０１，０２，０３，０４をこの順序で担当し、他方の看護師０２が、患者０５，０６，０７，０８をこの順序で担当することになる。これにともない、各患者０１，０２，・・・，０８が行う作業時刻がずれ、食事の開始時刻もずれることになる。ここで、医療マネジメント支援システムにおいては、同期バッファＳＢの期間は、基本的にバッファとして取り扱い、手が空いた場合であっても他のタスクを行わず、また、他のリソースのタスクが遅延していても個人の判断ではそのタスクのリソースとして手出ししないように運用する。さらに、医療マネジメント支援システムにおいては、同期バッファＳＢの期間を、血糖値やタスク完了の記録に用いてもよいが、次のサブタスクの開始を遅らせないように運用する。

このように、医療マネジメント支援システムにおいては、先に図３２に示したサブタスクプロパティ設定領域５４を用いてサブタスクの設定を行うことにより、同期された最適なスケジュール表を作成することができ、患者及び看護師双方のスケジュール管理を行うことができる。

また、医療マネジメント支援システムにおいては、かかる看護師のスケジュール管理をＰＤＡのような携帯可能な情報処理端末機ＣＬを用いて個人がフォローできるシステムを構築することにより、病棟全体、ひいては医療機関全体の最適なプロジェクトマネジメントを行うための情報をリアルタイムに収集し、必要に応じて同期を調整しながら、プロジェクトマネジメントを行うことが可能となる。

具体的には、医療マネジメント支援システムにおいては、例えば図４４乃至図４７に示すような画面を表示するＰＤＡのような携帯可能な情報処理端末機ＣＬを、看護師等の病棟スタッフに所持させることにより、血糖値やタスク完了等の記録を簡便に行い、スケジュール管理のための情報収集と情報管理とを行う。

すなわち、医療マネジメント支援システムにおいては、看護師が所持する情報処理端末機ＣＬの場合には、サーバＳＶの制御のもとに、当該情報処理端末機ＣＬの表示部１７に例えば図４４に示すような当該看護師のスケジュール表１０１をスクロール可能に表示させる。このスケジュール表１０１は、先に図４３右端に示したような内容を移植したものであり、時間毎にタスクとバッファとが区切られて表示され、終了したタスクと、次に実行すべきタスクと、その後実行すべきタスクとが色分け等によって識別可能に表示されたものである。また、この画面には、当該看護師のスケジュールの進捗状況をバッファの状況の形式で表示するバッファ状況表示領域１０２が設けられる。医療マネジメント支援システムにおいては、このバッファ状況表示領域１０２に色分け等によって識別可能に表示されたバッファの状況を看護師が閲覧することにより、スケジュールの進捗状況を把握することができる。ただし、医療マネジメント支援システムにおいては、看護師自身が勝手にスケジュール変更を行うことは禁止する。すなわち、医療マネジメント支援システムにおいては、病棟管理者のみがスケジュール変更を行う権限を有するように運用することにより、病棟全体のスケジュールの最適化を保持することが可能となる。一方、看護師のスケジュールは完全に個別化されており、他の看護師は、全く異なるスケジュール表及びバッファの状況を閲覧することになる。

また、医療マネジメント支援システムにおいては、スケジュール表１０１を構成するタスクのうち、次に実行すべきタスクの部分を看護師がタッチペン等を用いて選択することにより、サーバＳＶの制御のもとに、タスクを開始した旨が記録される。医療マネジメント支援システムにおいては、サーバＳＶの制御のもとに、この記録をデータベースに記憶させることにより、上述した各種画面に表示されるプロジェクトの進捗状況等に反映される。そして、医療マネジメント支援システムにおいては、サーバＳＶの制御のもとに、例えば図４５に示すように、選択されたタスクに関する情報を記録及び表示する画面を情報処理端末機ＣＬの表示部１７に表示させる。この画面には、患者の氏名とともに当該患者に固有のバーコード１０３が設けられる。医療マネジメント支援システムにおいては、看護師が図示しないバーコードリーダを用いてバーコード１０３をスキャンすることにより、タスク上の患者の氏名と実際の患者の氏名とが合致していることを確認することができる。医療マネジメント支援システムにおいては、特に投薬や検査業務等を行う際に、医療事故を防ぐために必ずこのステップを実行させるのが望ましい。また、医療マネジメント支援システムにおいては、患者の氏名を確認できる手段であれば、バーコードの代わりにＩＣタグ等の記録媒体等を用いてもよい。

そして、医療マネジメント支援システムにおいては、患者の氏名の確認後、看護師が実際のタスクを実行する。医療マネジメント支援システムにおいては、タスクを実行すると、看護師が、血糖値等の測定値やタスクの完了を示す情報等を入力ボックス１０４に記録するとともに、確定ボタン１０５を選択する。これに応じて、医療マネジメント支援システムにおいては、サーバＳＶの制御のもとに、そのタスクの完了基準との照合を行い、完了基準を満たしている場合には、その旨を情報処理端末機ＣＬを介して看護師に通知して当該タスクを完了する。また、医療マネジメント支援システムにおいては、確定ボタン１０５の選択に応じて、自動的に上述した客観的所見（Ｏ）の記録が行われ、さらにプラン（Ｐ）の実行が確認される。医療マネジメント支援システムにおいては、サーバＳＶの制御のもとに、これら記録をデータベースに記憶させることにより、上述した各種画面に表示されるプロジェクトの進捗状況等に反映される。なお、医療マネジメント支援システムにおいては、食後２時間後の血糖測定に対する食事の開始時刻等、前のタスクの時刻に応じて次のタスクの時刻が決まるようなタスクについては、確認ボタン１０５が選択されるのに応じて、その時刻が自動的に設定されるようにしてもよい。

さらに、医療マネジメント支援システムにおいては、確認ボタン１０５が選択されるのに応じて、サーバＳＶの制御のもとに、例えば図４６に示すように、その患者についてのプロジェクト全体の進捗状況、タスクの進捗状況、及びバッファの消費率等の情報を表示する画面を情報処理端末機ＣＬの表示部１７に表示させる。また、この画面には、その患者について留意すべき特記事項等が存在する場合に、その事項を閲覧するためのリンク１０６が設けられる。さらに、この画面には、今回のタスクの実行により、上述した主観的所見（Ｓ）、客観的所見（Ｏ）、アセスメント（Ａ）等、他の職種等と共有すべき特記事項が生じた場合には、その旨をチェックするチェックボックス１０７が設けられる。なお、医療マネジメント支援システムにおいては、このチェックボックス１０７に入力を行う時点ではバッファ残存量が十分にない場合も想定されることから、原則的には、その特記事項についての詳細な記録を行わないようにし、所定の記録時間に記録を行うようにする。ただし、医療マネジメント支援システムにおいては、十分なバッファ残存量がある場合には、特記事項の記録を行うようにしてもよい。

さらにまた、医療マネジメント支援システムにおいては、先に図３８に示した利用記録・表示領域８６と同様に、サーバＳＶの制御のもとに、例えば図４７に示すように、患者あたりの変動費用の参考に活用するための情報として、検査に使用した資材や物品等の利用記録を記録する利用記録領域１０８が設けられた画面を情報処理端末機ＣＬの表示部１７に表示させる。また、この画面にも、予定外の物品や薬剤等を利用した場合にその旨をチェックするチェックボックス１０９が設けられる。医療マネジメント支援システムにおいては、このチェックボックス１０９を用いることにより、防備録の機能を実現することができるが、このチェックボックス１０９に入力を行う時点ではバッファ残存量が十分にない場合も想定されることから、原則的には、その利用記録についての詳細な記録を行わないようにし、所定の記録時間に記録を行うようにする。

医療マネジメント支援システムにおいては、これら図４６及び図４７を介して入力された情報についても、サーバＳＶの制御のもとに、データベースに記憶させることにより、上述した各種画面に表示されるプロジェクトの進捗状況等に反映されることになる。

このように、医療マネジメント支援システムにおいては、携帯可能な情報処理端末機ＣＬを看護師等の病棟スタッフに所持させることにより、各種情報の記録を簡便に行うことができ、スケジュール管理のための情報収集と情報管理とを確実且つ効率よく行うことができる。

以上のように、医療マネジメント支援システムにおいては、医療におけるリアルタイムでのプロジェクトマネジメントに利用することができるが、これとともに、全体の質のコントロールにも利用することができる。すなわち、医療マネジメント支援システムにおいては、全ての行為に「タスク」と「リソース」という属性が付随することから、これらの情報を利用した分析を行うことが可能となる。

具体的には、医療マネジメント支援システムにおいては、タスク毎に要した日数の評価を行うことができる。図４８に、糖尿病教育入院における各タスクに要した時間のばらつきを、いわゆる箱ひげ図として表したものである。医療マネジメント支援システムにおいては、タスクの開始日及び終了日が入力されてデータベースに記憶されていることから、診療の過程において、これら質管理に必要な情報が入力されることになる。したがって、医療マネジメント支援システムにおいては、サーバＳＶの制御のもとに、これらの情報に基づいてかかる箱ひげ図を作成し、情報処理端末機ＣＬの表示部１７に表示させることができる。なお、医療マネジメント支援システムにおいては、例えば、箱ひげ図におけるひげを超える症例が全体の１０％を超えるとか、第２の完了期間ＨＰを超える症例が全体の２０％を超える等、「ばらつきの大きさ」を定義することにより、サーバＳＶの制御のもとに、ばらつきの大きいタスクから並べ替えて情報処理端末機ＣＬの表示部１７に表示させることも可能である。医療マネジメント支援システムにおいては、個人の医療者、科長・部長、事務管理者、エグゼクティブ等が、それぞれの目的に基づいて、かかる分析のためのテンプレートを予め定義することにより、プロジェクトを遂行するにあたっての迅速な意思決定を実現することができる。

さらに、医療マネジメント支援システムにおいては、ばらつきのあるタスクについて、そのばらつきの原因を探るために、例えば、患者の年齢、性別、他の合併症、糖尿の重症度、家族の有無といった当該患者の属性や、医師、科、病棟、看護師といったリソースによる層別化した評価を行うことも可能である。また、医療マネジメント支援システムにおいては、同じタスクであっても、ＩＣＤコードやＤＰＣ分類コード等、疾患分類での比較を行うことも可能である。さらに、医療マネジメント支援システムにおいては、リソース毎に変動費用の入力を行うことから、その変動費用の情報を加味した分析にも応用することができる。

さらにまた、医療マネジメント支援システムにおいては、サーバＳＶの制御のもとに、例えば図４９に示すように、個々の患者の状況をプロットしたコントロールチャート等のグラフを作成し、情報処理端末機ＣＬの表示部１７に表示させることもできる。また、医療マネジメント支援システムにおいては、かかるグラフの他に、パレート図、ヒストグラム、管理図、散布図、特性要因図、チェックシートといった、いわゆるＱＣ（Quality Control；品質管理）７つ道具を利用した分析を行うことも可能である。さらに、医療マネジメント支援システムにおいては、目標を設定することにより、経営改善方法論の１つであるシックスシグマによる質管理のモニタリングツールとしても活用することができる。

以上説明したように、本発明の実施の形態として示した医療マネジメント支援システムは、クリティカルチェーン理論に、医療の質の評価を考慮した画期的なアルゴリズムを実装することにより、既存のクリニカルパスの問題を解決し、患者の診察、看護、治療業務をはじめとする医療機関における各種業務の遂行は勿論のこと、医療の質向上と医療機関の経営改善も図ることができ、医療機関のマネジメント全体を支援することができる。

なお、本発明は、上述した実施の形態に限定されるものではない。例えば、上述した実施の形態では、ＡＳＰサービス型／オンライン型の医療マネジメント支援システムを採用し、情報処理端末ＣＬからのアクセスに応じてサーバＳＶが医療マネジメント支援プログラムを実行し、その結果を情報処理端末ＣＬに対して提示することにより、医療従事者がマネジメントを行う環境を享受できるものとして説明したが、本発明は、例えば、情報処理端末がサーバに対してアクセスして上述した各種データベースをはじめとする各種情報とともに医療マネジメント支援プログラムをダウンロードして実行するダウンロード型であっても適用することができ、また、医療マネジメント支援プログラムをＣＤ（Compact Disc）等の記憶媒体を介して頒布し、情報処理端末がこの記憶媒体に記憶されている医療マネジメント支援プログラムを実行するような形態であっても適用することができる。さらに、本発明は、全てのデータベースや医療マネジメント支援プログラムを情報処理端末機に実装するのではなく、機能毎にサーバと情報処理端末機とに適切に分散させてもよい。すなわち、本発明にかかる医療マネジメント支援装置とは、サーバＳＶ及び／又は情報処理端末機ＣＬのいずれかによって実現されるものである。

また、上述した実施の形態では、糖尿病教育入院を例に挙げて説明したが、本発明は、任意の疾病に基づく入院であっても容易に適用することができる。なお、現状のＤＰＣ分類コードでは、１０００以上の疾患が定義されていることから、プロジェクトネットワーク図のテンプレートを作成する場合には、数万個ものテンプレートを作成することになる。

さらに、医療マネジメント支援システムにおいては、上述したように、物品の利用記録を記録することにより、物品の消耗を追跡することができる。したがって、医療マネジメント支援システムにおいては、患者の入院から退院までのプロジェクトマネジメントを行うのみならず、物品の在庫管理にも応用することができる。

さらにまた、上述した実施の形態では、単一の医療機関において患者を入院させて退院させるという作業をプロジェクトと捉え、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べてプロジェクトネットワーク図を作成するものとして説明したが、本発明は、患者の退院後の開業医等における外来までをフォローするように、プロジェクトネットワーク図を拡張してもよい。すなわち、医療マネジメント支援システムにおいては、プロジェクトネットワーク図を、入院から退院までの部分と残りの外来の部分とを連続的に作成し、前者の部分を医療機関におけるプロジェクトとするとともに、後者の部分を開業医におけるプロジェクトとし、医療機関と開業医との間で情報を共有する、といったように、あるプロジェクトに関わる複数のプレイヤのつながりを考慮した経営手法であるいわゆるサプライチェーンマネジメントのような一元管理を行うことも可能となる。

このように、本発明は、その趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。

クリティカルチェーン理論について説明するための図であり、プロジェクトの所要時間を確率分布として表した図である。 クリティカルチェーン理論について説明するための図であり、プロジェクト完了の成果物の定義を行う様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、定義したプロジェクトの完了基準を満たすための必要条件としてのタスクを設定する様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、設定したタスクを実行するための必要条件としての他のタスクを設定する様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、プロジェクトの所要時間を確率分布として表した図に、各タスクの実行に必要な所要時間としての第１の完了期間及び第２の完了期間を記述した様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、作成されたプロジェクトネットワーク図における各タスクに、見積もった第１の完了期間を記述した様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、作成されたプロジェクトネットワーク図における各タスクに、割り当てたリソースを記述した様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、図７に示したプロジェクトネットワーク図のうち、リソースが競合している部分を説明する図である。 クリティカルチェーン理論について説明するための図であり、複数のタスクを同時に実行するMulti-taskingと、複数のタスクを順次実行するFocused-taskingとの２つの方法で、同じタスクを実行した場合の比較を説明する図である。 クリティカルチェーン理論について説明するための図であり、図８に示したリソース競合状態を解除した様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、クリティカルチェーンを求めた様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、図１１に示したプロジェクトネットワーク図にバッファを記述してクリティカルチェーンモデルを作成した様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、競合している２つのクリティカルチェーンモデルからなるプロジェクトを説明する図である。 クリティカルチェーン理論について説明するための図であり、図１３に示す２つのプロジェクトのうち、一方のプロジェクトの開始時間をずらした様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、図１４に示す２つのプロジェクトのうち、一方のプロジェクトに同期バッファを設定した様子を説明する図である。 クリティカルチェーン理論について説明するための図であり、最終的に同期された２つのプロジェクトを説明する図である。 クリティカルチェーン理論について説明するための図であり、プロジェクトバッファのモニタリングについて説明するための図である。 医療機関におけるタスクの多次元について説明するための図である。 本発明の実施の形態として示す医療マネジメント支援システムにおいて、情報処理端末機の表示部に表示させる概略的な画面例を説明する図であり、プロジェクトネットワーク図の作成及び閲覧を行うための画面例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムと既存の医療機関情報システムとの関係を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおいて、情報処理端末機の表示部に表示させる概略的な画面例を説明する図であり、病棟での管理に用いる画面例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおいて、情報処理端末機の表示部に表示させる概略的な画面例を説明する図であり、検査の管理に用いる画面例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムの構成を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおけるサーバ及び情報処理端末の回路構成を説明するブロック図である。 本発明の実施の形態として示す医療マネジメント支援システムにおけるデータベースの概略構成を説明する図である。 糖尿病教育入院のプロジェクトネットワーク図の例を説明する図である。 図２６に示すプロジェクトネットワーク図における各タスクの完了基準を説明する図である。 図２６に示すプロジェクトネットワーク図における各タスクに必要なリソースを説明する図である。 繰り返しタスクについて説明するための図である。 図２６に示すプロジェクトネットワーク図における各タスクの完了期間を説明する図である。 図２６に示すプロジェクトネットワーク図から作成されるクリティカルチェーンモデルを説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける情報処理端末機の表示部に表示される画面の具体例を説明する図であり、ネットワーク図作成画面の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける情報処理端末機の表示部に表示される画面の具体例を説明する図であり、複数の患者のスケジュールを管理するための管理画面の具体例を説明する図である。 図３３に示す管理画面における患者表示領域に表示される患者の順序を並べ替えた様子を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける情報処理端末機の表示部に表示される画面の具体例を説明する図であり、患者に対する診療内容を記録するとともに当該患者を管理するための管理画面の具体例を説明する図である。 図３５に示す管理画面における受け持ち患者一覧表示領域に表示される情報の具体例を説明する図である。 図３５に示す管理画面における受け持ち患者表示領域に表示される情報の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける情報処理端末機の表示部に表示される画面の具体例を説明する図であり、検査の管理を行うための管理画面の具体例を説明する図である。 血糖コントロールタスクが行われる様子を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける情報処理端末機の表示部に表示される画面の具体例を説明する図であり、血糖コントロールタスクにおけるある患者の１日のスケジュール表の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおけるプロジェクトの同期について説明するために用いる患者の状態を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける情報処理端末機の表示部に表示される画面の具体例を説明する図であり、複数のプロジェクトが同期されていないスケジュール表の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける情報処理端末機の表示部に表示される画面の具体例を説明する図であり、複数のプロジェクトが同期されたスケジュール表の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける携帯可能な情報処理端末機の表示部に表示される画面の具体例を説明する図であり、看護師のスケジュール表の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける携帯可能な情報処理端末機の表示部に表示される画面の具体例を説明する図であり、図４４に示す画面から遷移した画面の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける携帯可能な情報処理端末機の表示部に表示される画面の具体例を説明する図であり、図４５に示す画面から遷移した画面の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける携帯可能な情報処理端末機の表示部に表示される画面の具体例を説明する図であり、図４６に示す画面から遷移した画面の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける携帯可能な情報処理端末機の表示部に表示される画面の具体例を説明する図であり、糖尿病教育入院における各タスクに要した時間のばらつきを表す箱ひげ図の具体例を説明する図である。 本発明の実施の形態として示す医療マネジメント支援システムにおける携帯可能な情報処理端末機の表示部に表示される画面の具体例を説明する図であり、個々の患者の状況をプロットしたコントロールチャートの具体例を説明する図である。 クリニカルパスの具体例を説明する図である。

符号の説明

１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 記憶部
１５ 通信部
１６ 入力操作制御部
１７ 表示部
５１ ネットワーク図表示領域
５２ タスクプロパティ設定領域
５３ サブタスク表示領域
５４ サブタスクプロパティ設定領域
５５，５６，５８ 表示領域
５７ マーク
５９，１０４ 入力ボックス
６１，８１ 患者表示領域
６２，８２ 臨床的緊急度表示領域
６３，８３，１０２ バッファ状況表示領域
６４，８４ 進捗状況表示領域
７１ 受け持ち患者一覧表示領域
７２ 受け持ち患者表示領域
７３ 進捗状況表示領域
７４ 完了基準表示領域
７５ 達成率情報表示領域
７６ 診療内容記録・表示領域
７７ タスク記録検索領域
７８ タスク記録表示領域
８５ 所見記録・表示領域
８６ 利用記録・表示領域
８７ 検査記録検索領域
８８ 検査記録表示領域
１０１ スケジュール表
１０３ バーコード
１０５ 確認ボタン
１０６ リンク
１０７，１０９ チェックボックス
１０８ 利用記録領域
ＣＬ 情報処理端末
ＮＴ ネットワーク
ＳＶ サーバ

Claims (20)

1. 医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援装置であって、
   上記医療機関における医療従事者の操作に応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成手段と、
   上記ネットワーク図作成手段によって作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶する記憶手段と、
   少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、上記医療機関における医療従事者が閲覧する所定の表示手段に表示させる制御手段とを備えること
   を特徴とする医療マネジメント支援装置。
2. 上記ネットワーク図作成手段は、作成したプロジェクトネットワーク図の中で、同一期間に同一リソースが複数のタスクに関与している競合部分を探索し、リソースが競合するタスクを時間的に前にずらすことによってリソースの競合を解除してプロジェクトネットワーク図を書き替えること
   を特徴とする請求項１記載の医療マネジメント支援装置。
3. 上記ネットワーク図作成手段は、複数の患者に対するプロジェクトが同時に進行する場合には、当該複数のプロジェクトの同期を図り、プロジェクトネットワーク図を作成すること
   を特徴とする請求項１記載の医療マネジメント支援装置。
4. 上記所要時間は、約５０％の確率でタスクを完了することができる第１の完了期間であること
   を特徴とする請求項１記載の医療マネジメント支援装置。
5. 上記ネットワーク図作成手段は、上記完了基準、上記所要時間、及び上記リソースを設定するための画面を、プロジェクトネットワーク図を作成する医療従事者が閲覧する所定の表示手段に表示させ、上記画面を介して入力される情報に基づいて、当該プロジェクトネットワーク図を作成すること
   を特徴とする請求項１記載の医療マネジメント支援装置。
6. 上記ネットワーク図作成手段は、タスクがサブタスクを含んでいる場合には、当該サブタスクを設定するための領域を上記画面に設けて表示させること
   を特徴とする請求項５記載の医療マネジメント支援装置。
7. 上記ネットワーク図作成手段は、テンプレートとして上記記憶手段又は外部の記憶手段に記憶されている代表的な疾患についてのプロジェクトネットワーク図を呼び出すこと
   を特徴とする請求項１記載の医療マネジメント支援装置。
8. 上記ネットワーク図作成手段によって作成されたプロジェクトネットワーク図は、所定の属性が付与されて上記記憶手段に記憶されること
   を特徴とする請求項１又は請求項７記載の医療マネジメント支援装置。
9. 上記属性は、国際疾病分類及び／又は日本独自の診断分類であるＤＰＣ分類を含むこと
   を特徴とする請求項８記載の医療マネジメント支援装置。
10. 上記記憶手段には、上記ネットワーク図作成手段によって作成されたプロジェクトネットワーク図を構成する各タスク、並びに、各タスクの完了基準としての臨床評価指標及び／又は臨床的アウトカムが記憶されること
    を特徴とする請求項８記載の医療マネジメント支援装置。
11. 上記制御手段は、患者に対する診療内容又は検査内容を記録するための画面を、当該患者の担当医師及び担当看護師を含む医療従事者が閲覧する所定の表示手段に表示させ、その記録を上記記憶手段に記憶させること
    を特徴とする請求項１記載の医療マネジメント支援装置。
12. 上記制御手段は、上記記憶手段に記憶されている実際のプロジェクトの進捗状況に関する情報に基づいて、上記バッファの残存量を求め、求めた残存量を識別可能とした当該バッファの状況を表示する画面を、管理を行う医療従事者が閲覧する所定の表示手段に表示させること
    を特徴とする請求項１１記載の医療マネジメント支援装置。
13. 上記制御手段は、上記記憶手段に記憶されている情報に基づいて、臨床的な緊急度を識別可能に表示する画面を、上記管理を行う医療従事者が閲覧する所定の表示手段に表示させること
    を特徴とする請求項１２記載の医療マネジメント支援装置。
14. 上記制御手段は、上記記憶手段に記憶されている情報に基づいて、実際のプロジェクトの進捗状況を表示する画面を、上記管理を行う医療従事者が閲覧する所定の表示手段に表示させること
    を特徴とする請求項１３記載の医療マネジメント支援装置。
15. 上記制御手段は、上記記憶手段に記憶されている情報に基づいて、医療従事者のスケジュール表を、当該医療従事者が閲覧する所定の表示手段に表示させること
    を特徴とする請求項１４記載の医療マネジメント支援装置。
16. 上記制御手段は、上記記憶手段に記憶されている情報に基づいて、医療の質を分析し、その分析結果を、分析を行う医療従事者が閲覧する所定の表示手段に表示させること
    を特徴とする請求項１５記載の医療マネジメント支援装置。
17. 既存の医療機関情報システムとの間で情報の授受を行う通信手段を備えること
    を特徴とする請求項１記載の医療マネジメント支援装置。
18. 医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援方法であって、
    上記医療機関における医療従事者の操作に応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成工程と、
    上記ネットワーク図作成工程にて作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶手段に記憶させる記憶工程と、
    少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、上記医療機関における医療従事者が閲覧する所定の表示手段に表示させる表示工程とを備えること
    を特徴とする医療マネジメント支援方法。
19. 医療機関における各種業務の遂行と医療の質向上とを支援するコンピュータ実行可能な医療マネジメント支援プログラムであって、
    上記医療機関における医療従事者の操作に応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成処理と、
    上記ネットワーク図作成処理にて作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶手段に記憶させる記憶処理と、
    少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、上記医療機関における医療従事者が閲覧する所定の表示手段に表示させる表示処理とを備えること
    を特徴とする医療マネジメント支援プログラム。
20. 医療機関における各種業務の遂行と医療の質向上とを支援する医療マネジメント支援システムであって、
    上記医療機関における医療従事者が操作する情報処理端末機と、
    上記情報処理端末機のアクセス対象としてのサーバとを備え、
    上記サーバは、
    上記情報処理端末機からのアクセスに応じて、患者を入院させて退院させるという作業をプロジェクトと捉え、プロジェクトマネジメント理論の１つであるクリティカルチェーン理論にしたがって、現在の状態から退院基準を満たす状態へと患者の状態を改善するために完了すべき一連の臨床行為をタスクとして並べ、臨床評価指標及び／又は臨床的アウトカムとして表される各タスクの完了基準、各タスクの実行に必要な所要時間、及び各タスクの実行に必要なリソースを設定するとともに、上記所要時間内でタスクが完了しない場合の猶予時間としてのバッファを挿入し、患者毎のプロジェクトネットワーク図の作成を行うネットワーク図作成手段と、
    上記ネットワーク図作成手段によって作成されたプロジェクトネットワーク図、及び患者に対する診療内容又は検査内容の記録を含む各種情報を記憶する記憶手段と、
    上記情報処理端末機からのアクセスに応じて、少なくとも上記記憶手段に記憶されているプロジェクトネットワーク図を、当該情報処理端末機の表示手段に表示させる制御手段とを有すること
    を特徴とする医療マネジメント支援システム。