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