JP5116423B2 - 実施行為支援装置及び実施行為支援プログラム - Google Patents
実施行為支援装置及び実施行為支援プログラム Download PDFInfo
- Publication number
- JP5116423B2 JP5116423B2 JP2007260625A JP2007260625A JP5116423B2 JP 5116423 B2 JP5116423 B2 JP 5116423B2 JP 2007260625 A JP2007260625 A JP 2007260625A JP 2007260625 A JP2007260625 A JP 2007260625A JP 5116423 B2 JP5116423 B2 JP 5116423B2
- Authority
- JP
- Japan
- Prior art keywords
- implementation
- information
- action
- unit
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
Description
本発明は、所定対象に対する複数の実施行為を標準化された内容及び実施順序で行う実施者に対して、各実施行為の実施に有用な支援情報を提供するための実施行為支援装置及び実施行為支援プログラムに関する。
従来、医療関連行為を二次元構造で示したクリティカルパスが知られている。このクリティカルパスは、医療計画や実施の標準化及び可視化を通じて、医療の質と効率を系統的に保証及び向上させることができる点で有用である。しかしながら、患者の状態によっては、クリティカルパスを適用できなかったり、予め想定された標準的な経過から乖離してしまいクリティカルパスを逸脱する可能性があるという問題が指摘されていた。
この点に鑑みて本願発明者は、医療プロセス質管理システム及び医療プロセス質管理方法を提案した（特許文献１参照）。このシステムは、患者に対して実施する複数の医療プロセス及び各医療プロセスの実施順序等を記憶する記憶部と、次に実施する医療プロセスを読み出すプロセス管理部等を備えて構成されている。このシステムによれば、医療プロセスが所定基準に従って記憶部から順次読み出されて出力されるので、この出力された医療プロセスを参照しつつ医師が医療行為を行うことで、各医師が個別的に独自判断で医療行為の内容や実施順序を決定する場合に比べて、医療行為の標準化を図ることができ、延いては医療プロセスの質を維持及び向上させることができる。また、このシステムによれば、患者の個別性に柔軟に対応できるので、クリティカルパスの問題点を解消することが可能になる。
特に、このようなシステムによれば、各医療プロセスの内容及び実施順序を特定した時点で、患者の特定の状態に対応するための指示内容や当該指示内容を適用するための条件も同時に特定でき、さらには、各医療プロセスの実施スケジュールや、各医療プロセスを実施するために使用するリソース（医療資源）の予約等の見通しを立てることが可能になる。
しかしながら、従来のシステムでは、これら指示内容を適用するための条件、実施スケジュール、あるいはリソースの予約等が、各医療プロセスの内容及び実施順序が最初に作成された時点で固定化されてしまう。一方、実際の医療現場においては、患者への医療行為の実施状態が変化することで、固定化された条件や実施スケジュール等が維持できなくなる場合がある。例えば、患者の特定の状態に対応するための指示内容の適用条件を予め設定していた場合であっても、患者状態の遷移によっては当該適用条件による指示では間に合わない場合があった。あるいは、特定の医療プロセスの完了に要した期間が予め想定されていた標準的な期間から大きく乖離してしまった場合、当該完了した医療プロセスより以降の医療プロセスについては、実施スケジュールやリソースの使用予定が変動してしまう可能性があった。このような変動は従来の固定的なシステムでは吸収できなかったので、医療プロセスの工程管理の質や精度の一層の向上を図ることが困難であった。
本発明は、上記に鑑みてなされたものであって、各種の実施行為の内容及び実施行為の実施順序を対象の状態に適応させて変化させることに加えて、当該実施行為に関する様々な情報についても対象の状態に適応させて動的に変化させることで、各種の実施行為の標準化に加えて実施計画の最適化等を図ることができる、実施行為支援装置及び実施行為支援プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、請求項１に記載の本発明は、所定対象に対して実施すべき実施行為の内容を実施行為単位で特定するための実施行為情報と、複数の前記実施行為情報にて内容が特定される複数の実施行為の相互間における実施順序を特定するための実施順序情報と、を格納する実施行為情報格納手段と、前記所定対象の状態又は前記実施行為の実施状態に応じて変化し得る関連情報を格納する関連情報格納手段と、所定対象に対して過去に実施された実施行為の内容を特定するための前記実施行為情報と、所定対象に対して過去に実施された実施行為の実施日数を特定するための実施日数情報と、を格納する実施履歴情報格納手段と、前記所定対象の状態又は前記実施行為の実施状態を特定するための状態情報の入力を受け付ける入力手段と、前記状態情報の入力が前記入力手段を介して受け付けられた場合に、当該状態情報に基づいて前記実施行為情報格納手段を参照することにより将来的に実施され得る前記実施行為及び当該実施行為の実施順序を特定し、当該特定された実施行為を当該特定された実施順序に従って実施する場合における関連情報を所定方法にて決定し、当該決定した関連情報に基づいて前記関連情報格納手段に格納された関連情報を更新する情報更新手段と、前記情報更新手段にて更新された関連情報を所定の出力先に出力する出力手段とを備え、前記情報更新手段は、前記実施履歴情報格納手段に格納された前記実施行為情報及び前記実施日数情報に基づいて前記関連情報を決定することを特徴とする。
請求項２に記載の本発明は、請求項１に記載の本発明において、前記実施行為情報は、患者に対して実施すべき医療行為の内容を医療行為単位で特定するための情報であり、前記実施順序情報は、複数の前記実施行為情報にて内容が特定される複数の医療行為の相互間における実施順序を特定するための情報であり、前記状態情報は、前記患者の状態を特定するための情報又は前記医療行為の実施状態を特定するための情報であり、前記関連情報は、前記医療行為の実施条件、前記医療行為の実施スケジュール、又は、前記医療行為を実施する際に使用する医療資源を特定するための情報であることを特徴とする。
請求項３に記載の本発明は、請求項１又は２に記載の本発明において、前記実施行為を実施するための標準的な日数を含む標準スケジュール情報を格納する標準スケジュール情報格納手段を備え、前記情報更新手段は、前記所定対象に対して過去に実施された実施行為を実施するための標準的な日数を前記標準スケジュール情報格納手段から取得すると共に、前記所定対象に対して過去に実施された当該実施行為の実施日数を前記実施履歴情報格納手段から取得し、当該取得された標準的な日数と当該取得された実施日数との差分を算定し、前記特定された実施行為を実施するための標準的な日数を前記標準スケジュール情報格納手段から取得し、当該取得した標準的な日数を前記算定した差分に基づいて更新することを特徴とする。
請求項４に記載の本発明は、請求項１から３のいずれか一項に記載の本発明において、前記関連情報の更新に関する状態を報知するための更新状態報知情報を、前記関連情報に関連付けて格納する更新状態報知情報格納手段を備え、前記情報更新手段は、前記所定方法にて決定した前記関連情報に伴う前記更新状態報知情報を前記更新状態報知情報格納手段から取得し、前記出力手段は、前記取得された前記更新状態報知情報を所定の出力先に出力することを特徴とする。
請求項５に記載の本発明は、請求項１から４のいずれか一項に記載の本発明において、前記出力手段は、前記情報更新手段にて更新された関連情報を、前記実施行為を実施するために使用する資源の予約を管理するための所定の資源管理装置に出力することを特徴とする。
請求項６に記載の本発明は、所定対象に対して実施すべき実施行為の内容を実施行為単位で特定するための実施行為情報と、複数の前記実施行為情報にて内容が特定される複数の実施行為の相互間における実施順序を特定するための実施順序情報と、を格納する実施行為情報格納手段と、前記所定対象の状態又は前記実施行為の実施状態に応じて変化し得る関連情報を格納する関連情報格納手段と、所定対象に対して過去に実施された実施行為の内容を特定するための前記実施行為情報と、所定対象に対して過去に実施された実施行為の実施日数を特定するための実施日数情報と、を格納する実施履歴情報格納手段と、前記所定対象の状態又は前記実施行為の実施状態を特定するための状態情報の入力を受け付ける入力手段と、前記関連情報を所定の出力先に出力する出力手段と、を備えたコンピュータに実行させるプログラムであって、前記状態情報の入力が前記入力手段を介して受け付けられた場合に、当該状態情報に基づいて前記実施行為情報格納手段を参照することにより将来的に実施され得る前記実施行為及び当該実施行為の実施順序を特定するステップと、前記特定された実施行為を当該特定された実施順序に従って実施する場合における関連情報を所定方法にて決定するステップと、前記決定した関連情報に基づいて前記関連情報格納手段に格納された関連情報を更新するステップと、前記更新された関連情報を前記出力手段を介して前記所定の出力先に出力するステップと、前記実施履歴情報格納手段に格納された前記実施行為情報及び前記実施日数情報に基づいて前記関連情報を決定するステップとを前記コンピュータに実行させる。
請求項１、６に記載の本発明によれば、所定対象の状態又は実施行為の実施状態に適合させて関連情報を動的に更新でき、実施行為の内容や実施順序の標準化を行ってその質を維持及び管理することに加えて、実施行為の内容や実施行為の実施計画に関する情報等の最適化等を図ることができる。
また、過去の実施行為情報や実施順序情報に基づいて関連情報を更新でき、実施行為の実施実績を反映した更新処理を行うことができる。
特に、過去の臨床履歴に基づいて調整された実施スケジュールを把握できるので、患者の個別的な臨床傾向に合致した実施スケジュールを把握でき、患者の個別的な実情に応じた臨床工程管理を行うことができる。
また、過去の実施行為情報や実施順序情報に基づいて関連情報を更新でき、実施行為の実施実績を反映した更新処理を行うことができる。
特に、過去の臨床履歴に基づいて調整された実施スケジュールを把握できるので、患者の個別的な臨床傾向に合致した実施スケジュールを把握でき、患者の個別的な実情に応じた臨床工程管理を行うことができる。
請求項２に記載の本発明によれば、患者の状態又は医療行為の実施状態に適合させて、医療行為の実施条件、医療行為のスケジュール、又は、医療行為を実施する際に使用する医療資源を特定するための情報を動的に更新でき、医療行為の内容や実施順序の標準化を行ってその質を維持及び管理することに加えて、医療行為の内容や医療行為の実施計画に関する情報等の最適化等を図ることができる。
請求項３に記載の本発明によれば、標準情報に基づいて関連情報を更新でき、標準化された基準に基づいて更新処理を実行することができるので、更新処理自体についても標準化を図ることができ、更新処理自体の質を維持及び管理することができる。
請求項４に記載の本発明によれば、関連情報が更新された場合には、当該関連情報の更新状態を報知するための更新状態報知情報が自動的に出力されるので、実施者は関連情報の更新状態を容易かつ確実に把握することができ、実施者に対する注意喚起等を図ることができる。
請求項５に記載の本発明によれば、関連情報を資源管理装置に出力することで、資源管理装置における資源管理を自動的に更新することができる。
以下に添付図面を参照して、この発明に係る実施行為支援装置及び実施行為支援プログラムを実施するための最良の形態について詳細に説明する。まず、〔I〕本実施の形態の基本概念を説明した後、〔II〕本実施の形態の具体的内容について説明し、〔III〕最後に本実施の形態に対する変形例について説明する。ただし、本実施の形態によって本発明が限定されるものではない。
〔I〕本実施の形態の基本概念
まず、本実施の形態の基本概念について説明する。本実施の形態に係る実施行為支援装置（以下「本装置」）及び実施行為支援プログラム（以下「本プログラム」）は、所定対象に対する実施行為を実施する実施者に対して、当該実施を支援するための各種の情報を提示することにより、当該実施行為の実施を支援するための装置及びプログラムである。
まず、本実施の形態の基本概念について説明する。本実施の形態に係る実施行為支援装置（以下「本装置」）及び実施行為支援プログラム（以下「本プログラム」）は、所定対象に対する実施行為を実施する実施者に対して、当該実施を支援するための各種の情報を提示することにより、当該実施行為の実施を支援するための装置及びプログラムである。
本装置及び本プログラムは、広範な分野に適用可能であり、概念的には、当該分野における形式知（具体的には、所定対象に対する複数の実施行為の内容と、これら複数の実施行為の相互間の実施順序）を構造化することで可視化が可能な全ての分野に適用可能である。この適用分野の例としては、「医療分野」、「防災分野」、「教育分野」を挙げることができる。この適用分野に応じて、上述した「所定対象」、「実施者」、「実施行為」の具体的内容は異なり得る。例えば、医療分野では、所定対象＝患者、実施者＝医師、実施行為＝医療行為である。同様に、防災分野では、所定対象＝災害やテロ行為の被災者や被災物、実施者＝救援者、実施行為＝救援行為、教育分野では、所定対象＝生徒、実施者＝教師、実施行為＝教育行為が該当する。以下では、本装置及び本プログラムを医療分野に適用した場合について説明する（必要に応じて、本装置を「医療行為支援サーバ」、本プログラムを「医療行為支援プログラム」と称する）が、本装置及び本プログラムを他の分野に適用する場合には、上述のように「所定対象」、「実施者」、「実施行為」の内容を当該他の分野に応じた内容に読み替えばよい。
図１は、医療情報システムの全体構成を概念的に示す説明図である。この図１に示すように、医療情報システムは、医療行為支援サーバ１、関連サーバ群１０、及び複数の支援端末２０を、構内ＬＡＮやインターネットの如きネットワーク３０を介して相互に通信可能として構成されている。これら各部の具体的構成については後述する。なお、本実施の形態では、医療情報システムによって特定の一つの医療機関の内部で実施される各種の医療行為を支援する例を示すが、医療情報システムによって複数の医療機関の医療行為を統合的に支援したり、医療情報システムの各構成要素を複数の医療機関に分散配置したりしてもよい。
本装置及び本プログラムでは、上述の特許文献１に全部又は一部が開示された「患者状態適応型パスシステム（PCAPS: Patient Condition Adaptive Path System)」を利用する。この患者状態適応型パスシステムは、患者の初期状態から最終目標状態に至る臨床経路を示す俯瞰的なモデルであり、この臨床経路を、「患者状態」を基軸とする複数の「目標状態」を相互にリンクして視覚化したものであって、具体的には「臨床プロセスチャート」と「ユニットシート」の２つのツールを用いて構成される。
図２には、これら臨床プロセスチャート及びユニットシートの基本構成モデルを示す。臨床プロセスチャートとは、患者の目標状態毎に形成された医療行為単位（医療の質を管理するために適切な大きさに設定された単位）である「ユニット（プロセス）」を連結することで構成される臨床経路の俯瞰図であり、疾患毎に構成され、当該疾患を有する患者の初期状態から最終目標状態に至る間に想定されるすべての臨床状態を包含する。各ユニットは「実行エレメント」と「判断エレメント」とから構成されている。実行エレメントは、患者状態を当該ユニットの目標状態に達するように組み込まれた医療業務を実行していく行為を示し、判断エレメントは、患者状態が当該ユニットの目標状態に達したか否かを判断する行為を示す。そして、各実行エレメントと、当該各実行エレメントの直後の判断エレメントとを、視覚的に表示する手段として「ユニットシート」が構成される。
このユニットシートの表示画面例を図３に示す。具体的にはユニットシートは、「患者ＩＤ」、「ユニットＩＤ」、「医療行為」、「患者状態」、「目標状態」、「ユニット移行ロジック」、「条件付き指示」を含む。患者ＩＤは、当該ユニットシートが適用されている患者を一意に特定するための識別情報である。ユニットＩＤは、当該ユニットシートに対応するユニットを一意に特定するための識別情報である。医療行為は、当該ユニットシートに対応する実行エレメントにおいて実行すべき医療行為の項目や内容を記述した情報であり、医行為、ケア行為、及び調整行為を含む。患者状態は、当該ユニットシートに対応するユニットにおいて注目すべき患者状態の内容を記述した情報である。ユニット移行ロジックは、当該ユニットシートに対応するユニットから次順のユニットに移行するときの条件及び移行先のユニットシートに対応するユニットＩＤを記述した情報である。条件付き指示は、当該ユニットにおける医療行為中に発生した患者状態に早急に対応するための指示内容及び当該指示内容を実行するための条件を特定する条件パラメータ（図３では「１３５以上」）を含んで構成されている。
このように構成される「臨床プロセスチャート」及び「ユニットシート」を特定するための情報が本装置に予め格納されており、本装置及び本プログラムは、臨床プロセスチャートにおける最初のユニットに対応するユニットシートの内容を支援端末２０を介して医師に対して表示出力等にて提示する。そして、医師が、当該提示されたユニットシートに含まれる医療行為を行い、その後の患者状態を支援端末２０に入力すると、この患者状態が支援端末２０を介して本装置にて受け付けられる。次いで、本装置及び本プログラムは、患者状態が当該ユニットの目標状態に達したか否かを判断する。目標状態に達したと判断した場合には、当該最初のユニットの次順のユニットを臨床プロセスチャートに基づいて特定し、当該次順のユニットに対応するユニットシートの内容を支援端末２０を介して医師に対して提示する。以降同様に、臨床プロセスチャートにて定義された順序に従ったユニットに対応するユニットシートの内容の提示処理と、医師による患者状態の入力を受け付ける処理と、目標状態に達したか否かを判断する判断処理とが繰り返し行われ、臨床プロセスチャートにおける最後のユニットの医療行為が終了することで、一連の処理が終了する。このように構成され実行される患者状態適応型パスによれば、臨床プロセスチャート及びユニットシートを標準化された内容及び順序で各医師に提示することで、医療を安全と質保証の視点から支援できる。
本実施の形態の特徴の一部は、上述のように構成された臨床プロセスチャート及びユニットシートに含まれる情報自体や、当該情報に基づいて導出される情報を、その時点における患者状態や患者に対して行われた医療行為の内容に応じて、動的に更新することにある（以下、本装置及び本プログラムによって動的に更新され得る情報を「関連情報」と称する）。この関連情報としては様々な情報を含むことができるが、以下の例では、条件付き指示における条件を特定するための「条件パラメータ」、各ユニットの医療行為の「実施スケジュール」、及び、各ユニットで使用されるリソースの予約情報である「リソース予約」を更新する場合について説明する。
〔II〕本実施の形態の具体的内容
次に、本実施の形態の具体的内容について説明する。以下では、図１に示した医療情報システムの各部の構成について説明し、次いで、医療行為支援サーバ１を用いて実行される医療行為支援プログラムの処理内容について説明する。
次に、本実施の形態の具体的内容について説明する。以下では、図１に示した医療情報システムの各部の構成について説明し、次いで、医療行為支援サーバ１を用いて実行される医療行為支援プログラムの処理内容について説明する。
（構成−医療情報システム−医療行為支援サーバ）
図１の医療行為支援サーバ１は、特許請求の範囲における実施行為支援装置及びコンピュータに対応するもので、機能概念的に、記憶部２、制御部３、及びネットワークインターフェース（以下「ネットワークＩＦ」）４を、バス５にて相互に通信可能に接続して構成されている。
図１の医療行為支援サーバ１は、特許請求の範囲における実施行為支援装置及びコンピュータに対応するもので、機能概念的に、記憶部２、制御部３、及びネットワークインターフェース（以下「ネットワークＩＦ」）４を、バス５にて相互に通信可能に接続して構成されている。
記憶部２は、医療行為支援サーバ１における各種処理に必要な情報やパラメータを不揮発的に格納する格納手段であり、例えば、ＨＤ（Hard Disk）にて構成される。具体的には、この記憶部２は、機能概念的に、実施行為情報記憶部２ａ、標準情報記憶部２ｂ、履歴情報記憶部２ｃ、及び関連情報記憶部２ｄに大別される。実施行為情報記憶部２ａは、患者に対して実施すべき医療行為の内容を医療行為単位で特定するためのユニットシート（実施行為情報）と、複数の医療行為の相互間における実施順序を特定するためのプロセスチャート（実施順序情報）とを格納する手段であり、具体的には、プロセスＤＢ（Database）２ａ１を備える。標準情報記憶部２ｂは、関連情報の標準的な内容を特定するための情報を記憶する手段であり、具体的には、標準条件パラメータＤＢ２ｂ１、標準実施スケジュールＤＢ２ｂ２、標準リソース予約ＤＢ２ｂ３を備える。履歴情報記憶部２ｃは、患者に対して実施されたユニットシート及びプロセスチャートの履歴情報を格納する手段であり、具体的には、プロセス履歴ＤＢ２ｃ１を備える。関連情報記憶部２ｄは、患者の状態又は医療行為の実施状態に応じて更新される関連情報を記憶する手段であり、具体的には、条件パラメータＤＢ２ｄ１、実施スケジュールＤＢ２ｄ２、及びリソース予約ＤＢ２ｄ３を備える。これら実施行為情報記憶部２ａ、標準情報記憶部２ｂ、履歴情報記憶部２ｃ、関連情報記憶部２ｄは、それぞれ、特許請求の範囲における実施行為情報格納手段、標準情報格納手段、履歴情報格納手段、関連情報格納手段に対応する。また、関連情報記憶部２ｄは、特許請求の範囲における更新状態報知情報格納手段にも対応する。以下、これら各ＤＢの構成例についてより詳細に説明する。ただし、以下の構成例では本実施の形態に係る最低限の情報を格納する例を示し、実際には以下に説明する情報以外の任意の情報を各ＤＢに格納することができる。
プロセスＤＢ２ａ１は、標準化された臨床プロセスチャート及びユニットシートを特定するための情報（以下「プロセス情報」）を格納するためのプロセス情報格納手段である。図４は、臨床プロセスチャートの具体例である。この臨床プロセスチャートは、前立腺全摘徐を行う場合の例であるが、この他の各種の疾患に対応する臨床プロセスチャートも疾患名に関連付けてプロセスＤＢ２ａ１に格納されている。この臨床プロセスチャートは、複数のユニットの各々を構成する実行エレメント及び判断エレメントと、これら各エレメントを相互に接続する線分とを含んでおり、当該線分によって各エレメントの相互間の実行順序が視覚的に示されている。例えば、実行エレメント「Ａ−１ 前立腺全摘除術」の医療行為を実行した後、判断エレメント「ＳＡ−１」において患者状態と目標状態とに基づく判断を行い、この判断結果に応じて、実行エレメント「Ａ−２ 術後急性期」又は実行エレメント「Ｂ−２ 術後急性期」」のいずれかに移行する。図４における各実行エレメントの枠内には、各実行エレメントに対応するユニットの名称及びユニットＩＤを示す。例えば、最初の実行エレメントに対応するユニットの名称は「入院 術前」であり、ユニットＩＤは「Ａ−０」である。
図５は、プロセスＤＢ２ａ１に格納されるプロセス情報の一部の構成例であり、図４の臨床プロセスチャートを特定するための情報、及び、この臨床プロセスチャートの各ユニットに対応するユニットシートの内容を特定するための情報の具体例である。この情報は、図３に示した情報と同様であり、「ユニットＩＤ」、「医療行為」、「患者状態」、「目標状態」、「ユニット移行ロジック」、及び「条件付き指示」を相互に関連付けて構成されている。特に、医療行為は、当該医療行為において使用され得るリソースを特定するための情報（ここでは、「手術室」等の「リソース名」と、各リソースを一意に特定するための「ＯＰ０００１」等の「リソースＩＤ」）を含む。
図１の標準条件パラメータＤＢ２ｂ１は、標準化された条件付き指示及びその条件パラメータを特定するための情報（以下「標準条件パラメータ情報」）を格納するための標準条件パラメータ情報格納手段である。図６は、標準条件パラメータ情報の構成例を示す図である。この標準条件パラメータ情報は、各条件付き指示が適用されるユニットの「ユニットＩＤ」、各条件付き指示の条件パラメータを選択する際の基準である「条件パラメータ選択基準」、各条件付き指示の条件パラメータが適用される「患者状態」、各条件項目の具体的判断基準となる数値である「条件パラメータ」、各条件付き指示の内容を記述した「条件付き指示」、及び「ガイド情報」を相互に関連付けて構成されている。ここでは、一つの「条件付き指示」に対して条件パラメータを複数格納することができ、これら複数の条件パラメータの条件パラメータ選択基準についても複数格納することができる。図６の例では、ユニットＩＤ「Ａ−０」の判断ロジックとして、患者の体温が「３７℃未満」の場合には、患者の血圧が「１３５以上」になった時点で、条件付き指示「血圧降下剤投与」を行い、患者の体温が「３７℃以上」の場合には、患者の血圧が「１３０以上」になった時点で、条件付き指示「血圧降下剤投与」を行う旨を示す。このように条件パラメータを選択するのは、患者状態や医療行為によって、所定の条件付き指示を行う条件が異なり得るためであり、例えば、患者の体温が比較的低い場合には、患者の体温が比較的高くなるまで血圧降下剤が不要であるが、患者の体温が比較的高い場合には、患者の体温が比較的低い場合であっても血圧降下剤が必要になる、といった状況を医療プロセスに反映させるためである。
また、ガイド情報は、関連情報の更新に関する状態を報知するための情報であり、特許請求の範囲における更新状態報知情報に対応する。図６の例では、条件パラメータ「１３５以上」に設定する場合は、患者状態が比較的安定している状態（体温３７℃未満）であり、医師に注意喚起すべき事項が特にないためにガイド情報が空欄になっているが、条件パラメータ「１３０以上」に設定する場合は、患者状態が比較的不安定な状態（体温３７℃以上）であるため、医師に対して、注意喚起を行うためのガイド情報が設定されている。ガイド情報の具体的内容は任意であるが、例えば、条件パラメータが更新された旨、不安定な状態に対応する条件パラメータに設定された旨、予想される疾患の内容、あるいは、条件付き指示を実施する上での特別な留意点等を報知する内容とすることができる。この例では、条件パラメータに対してガイド情報を固定的に関連付けているが、同一の条件パラメータに対して、当該条件パラメータを設定するに至った履歴等に基づいて、異なるガイド情報の中から一つのガイド情報を動的に選択するようにしてもよい。例えば、複数のガイド情報と、各ガイド情報を選択するための選択基準情報とを予め標準条件パラメータＤＢ２ｂ１に格納しておき、プロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴に基づいて選択基準情報を判定することでガイド情報を選択するようにしてもよい。この場合には、条件パラメータの更新頻度が所定の基準頻度を越えている場合にのみ、条件付き指示の変更に留意する旨のガイド情報を表示してもよい。また、標準値に対する条件パラメータの乖離度に応じてガイド情報の内容を変えてもよく、標準値に対して所定範囲内の条件パラメータに更新した場合には、条件パラメータが更新された旨のみを報知するガイド情報を選択し、標準値に対して所定範囲を逸脱する条件パラメータに更新した場合には、患者状態に特に留意すべき旨を報知するガイド情報を選択することができる。
図１の標準実施スケジュールＤＢ２ｂ２は、標準化された実施スケジュールを特定するための情報（以下「標準実施スケジュール情報」）を格納するための標準実施スケジュール情報格納手段である。図７は、標準実施スケジュール情報の構成例を示す図である。この標準実施スケジュール情報は、各ユニットシートの「ユニットＩＤ」、及び当該各ユニットシートに移行してから次順のユニットシートに移行するまでの標準的な日数である「標準日数」を相互に関連付けて構成されている。図７の例では、ユニットＩＤ「Ａ−０」に対応するユニットシートに移行してから、次順のユニットシートに移行するまでに標準的に「３」日を要することを示す。
図１の標準リソース予約ＤＢ２ｂ３は、標準化されたリソース予約を特定するための情報（以下「標準リソース予約情報」）を格納するための標準リソース予約情報格納手段である。図８は、標準標準リソース予約情報の構成例を示す図である。この標準リソース予約情報は、各ユニットシートの「ユニットＩＤ」、各ユニットシートにおいて使用され得るリソースの「リソースＩＤ」、及び各ユニットシートへの移行日を基準として各リソースの使用を開始する「使用日」を相互に関連付けて構成されている。図８の例では、ユニットＩＤ「Ａ−１」に対応するユニットシートに移行してから、リソースＩＤ「ＯＰ０００１」にて特定されるリソースを「１」日目に使用することを示す。
これらプロセス情報、標準条件パラメータ情報、標準実施スケジュール情報、及び標準リソース予約情報を生成する方法及びタイミングは任意であるが、例えば、これら各情報を、医師のヒアリング等に基づいて標準化することで決定して各ＤＢに予め格納しておくことができる。これら各情報やプロセス情報の標準化は、必ずしも硬直的なものではなく、各医療機関や各患者の実情に合致するように、各医療機関や各医師が支援端末２０を用いて任意の内容にカスタマイズできるようにしてもよい。なお、これらプロセス情報等の具体的な記述構造も任意であるが、例えばＸＭＬ（Extensible Markup Language）により、タグを用いて各情報の意味及び構造を記述することができる。
図１のプロセス履歴ＤＢ２ｃ１は、プロセス情報を各患者に実際に適用した際の履歴を特定するための情報（以下「プロセス履歴情報」）を格納するためのプロセス履歴情報格納手段である。図９には、プロセス履歴情報の構成例を示す。このプロセス履歴情報は、概略的には図５に示すプロセス情報に対して、各ユニットシートが実際に適用された患者の「患者ＩＤ」、及び各ユニットシートに対応するユニットに実際に移行した年月日（以下「移行年月日」）を付加して構成されている。このプロセス履歴情報は、各患者の診療の初期の時点においてプロセスＤＢ２ａ１から取得されてプロセス履歴ＤＢ２ｃ１に初期値として記憶された後、各患者の臨床が経過するに伴って更新される。
図１の条件パラメータＤＢ２ｄ１は、各患者毎の各ユニットの条件付き指示の条件パラメータを特定するための情報であって動的に更新された情報（以下「条件パラメータ情報」）を格納するための条件パラメータ情報格納手段である。この条件パラメータ情報の構成例を図１０に示す。この条件パラメータ情報は、各患者毎に設けられるもので、「患者ＩＤ」、「ユニットＩＤ」、及び「条件パラメータ」を相互に関連付けて構成されている。
図１の実施スケジュールＤＢ２ｄ２は、各患者毎の各ユニットの実施スケジュールを特定するための情報（以下「実施スケジュール情報」）を格納するための実施スケジュール情報格納手段である。この実施スケジュール情報の構成例を図１１に示す。この実施スケジュール情報は、各患者毎に設けられるもので、「患者ＩＤ」、「ユニットＩＤ」、及び当該各ユニットシートに移行する予定の年月日を示す「移行年月日」を相互に関連付けて構成されている。
図１のリソース予約ＤＢ２ｄ３は、各患者毎の各ユニットにおいて使用されるリソースの予約内容を特定するための情報（以下「リソース予約情報」）を格納するためのリソース予約情報格納手段である。このリソース予約情報の構成例を図１２に示す。このリソース予約情報は、各患者毎に設けられるもので、「患者ＩＤ」、「ユニットＩＤ」、「リソースＩＤ」、及び当該各リソースの予約の年月日を示す「予約年月日」を相互に関連付けて構成されている。
これら条件パラメータ情報、実施スケジュール情報、及びリソース予約情報は、各患者の診療の初期の時点においてプロセスＤＢ２ａ１から取得されて、標準条件パラメータＤＢ２ｂ１、標準実施スケジュールＤＢ２ｂ２、標準リソース予約ＤＢ２ｂ３にそれぞれ初期値として記憶された後、各患者の臨床が経過するに伴って動的に更新される。
図１において、制御部３は、医療行為支援サーバ１の各部を制御する制御手段であり、機能概念的に、プロセス管理部３ａ及び情報更新部３ｂを備える。プロセス管理部３ａは、臨床プロセスチャート及びユニットシートを用いた臨床プロセスを管理する手段である。情報更新部３ｂは、患者状態に適応して関連情報を更新するもので、特許請求の範囲における情報更新手段に対応する。この情報更新部３ｂは、機能概念的に、条件パラメータ更新部３ｂ１、実施スケジュール更新部３ｂ２、及びリソース予約更新部３ｂ３を備える。条件パラメータ更新部３ｂ１は、条件パラメータを患者状態に応じて動的に更新する条件パラメータ更新手段である。実施スケジュール更新部３ｂ２は、実施スケジュール情報を患者状態に応じて動的に更新する実施スケジュール更新手段である。リソース予約更新部３ｂ３は、リソース予約を患者状態に応じて動的に更新するリソース予約更新手段である。
この制御部３は、具体的には、ＣＰＵ（Central Processing Unit）や、このＣＰＵ上で解釈実行される各種のプログラム（ＯＳなどの制御プログラムや、各種の処理手順などを規定したプログラム）、及び、所要プログラムや所要データを格納するためのキャッシュメモリを備えて構成される。特に、制御部３は、本プログラムとしての医療行為支援プログラムを備えて構成されている。この医療行為支援プログラムは、例えば、ＣＤ−ＲＯＭやＤＶＤを含む任意の記憶媒体に記憶された後、医療行為支援サーバ１にインストールされて記憶部２に不揮発的に記憶され、ＣＰＵにて解釈実行されることで制御部３の実質的機能を構成する。
ネットワークＩＦ４は、医療行為支援サーバ１がネットワーク３０を介した通信を行うための通信手段であり、例えばネットワークボードとして構成される。このネットワークＩＦ４を介して、医療行為支援サーバ１に対する各種の情報の入出力が行われることから、当該ネットワークＩＦ４は特許請求の範囲における入力手段及び出力手段に対応する。ただし、この医療行為支援サーバ１には、ネットワークＩＦ４とは別に、各種情報の入力を受け付けるためのキーボードやポインティングデバイス、あるいは、各種情報を出力するためのモニタやスピーカを設けてもよく、この場合には、これらキーボードやポインティングデバイスが特許請求の範囲における入力手段に対応すると共に、モニタやスピーカが特許請求の範囲における出力手段に対応する。
（構成−医療情報システム−関連サーバ群）
関連サーバ群１０は、医療機関における各種の情報を処理するための複数のサーバを含んで構成されるもので、例えば、医事会計サーバ１１とオーダサーバ１２とを含んで構成されている。医事会計サーバ１１は、医事会計に関する情報を入力又は出力するための情報処理を行なう装置である。オーダサーバ１２は、各種のリソースの発注、在庫管理、あるいは予約管理を行う装置であり、特許請求の範囲における資源管理装置に対応する。これら関連サーバ群１０に含まれる各サーバの具体的構成は任意であり、医療行為支援サーバ１との間における通信機能を有する限りにおいて、公知のサーバ装置と同様に構成できるために、その説明を省略する。なお、関連サーバ群１０に含まれる各サーバの種類は例示であり、この他の任意のサーバを含めることができる。
関連サーバ群１０は、医療機関における各種の情報を処理するための複数のサーバを含んで構成されるもので、例えば、医事会計サーバ１１とオーダサーバ１２とを含んで構成されている。医事会計サーバ１１は、医事会計に関する情報を入力又は出力するための情報処理を行なう装置である。オーダサーバ１２は、各種のリソースの発注、在庫管理、あるいは予約管理を行う装置であり、特許請求の範囲における資源管理装置に対応する。これら関連サーバ群１０に含まれる各サーバの具体的構成は任意であり、医療行為支援サーバ１との間における通信機能を有する限りにおいて、公知のサーバ装置と同様に構成できるために、その説明を省略する。なお、関連サーバ群１０に含まれる各サーバの種類は例示であり、この他の任意のサーバを含めることができる。
（構成−医療情報システム−支援端末）
各支援端末２０は、医師を含む医療従事者が医療行為支援サーバ１や関連サーバ群１０の各サーバに対して入出力を行うための端末装置であり、特に、患者状態の入力を受け付ける入力機能と、臨床プロセスチャート及びユニットシートの出力を行う出力機能を有する。この支援端末２０は、各種情報の入出力機能及び医療行為支援サーバ１との間における通信機能を有する限りにおいて、公知のパーソナルコンピュータと同様に構成できるために、その詳細な説明は省略する。
各支援端末２０は、医師を含む医療従事者が医療行為支援サーバ１や関連サーバ群１０の各サーバに対して入出力を行うための端末装置であり、特に、患者状態の入力を受け付ける入力機能と、臨床プロセスチャート及びユニットシートの出力を行う出力機能を有する。この支援端末２０は、各種情報の入出力機能及び医療行為支援サーバ１との間における通信機能を有する限りにおいて、公知のパーソナルコンピュータと同様に構成できるために、その詳細な説明は省略する。
（処理）
次に、医療行為支援サーバ１にて医療行為支援プログラムを実行すること等によって行われる医療行為支援処理（以下、本処理）について説明する。なお、以下の本処理の説明において、制御主体を特記しない処理については、制御部３にて実行されるものとし、情報の取得元や取得経路を特記しない場合については、公知のタイミング及び公知の方法にて、関連サーバ群１０の各サーバから情報が取得され、あるいは、支援端末２０を介して医療従事者が情報を手入力するものとする。
次に、医療行為支援サーバ１にて医療行為支援プログラムを実行すること等によって行われる医療行為支援処理（以下、本処理）について説明する。なお、以下の本処理の説明において、制御主体を特記しない処理については、制御部３にて実行されるものとし、情報の取得元や取得経路を特記しない場合については、公知のタイミング及び公知の方法にて、関連サーバ群１０の各サーバから情報が取得され、あるいは、支援端末２０を介して医療従事者が情報を手入力するものとする。
（処理−全体処理）
まず、医療行為支援処理の全体について説明する。図１３は、医療行為支援処理のフローチャートである。最初に、医師が支援端末２０を介して患者の患者ＩＤ及び疾患名を入力すると共に、医療プロセスの開始を指示すると、これらの情報が支援端末２０から医療行為支援サーバ１に送信される。この医療行為支援サーバ１のプロセス管理部３ａは、支援端末２０からの情報の入力を受け付けると（ステップＳＢ−１，Ｙｅｓ）、当該患者の疾患名に対応するプロセス情報をプロセスＤＢ２ａ１から取得し、当該取得したプロセス情報に患者ＩＤを付加することでプロセス履歴情報を生成し、このプロセス履歴情報をプロセス履歴ＤＢ２ｃ１に格納する（ステップＳＢ−２）。このようにプロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報のプロセスチャートやユニットシートは、医師が支援端末２０を介して任意のタイミングで呼び出し、当該支援端末２０のモニタを介して閲覧できる。この際に必要な情報の一部は、プロセス履歴情報の患者ＩＤ、ユニットＩＤ、あるいはリソースＩＤに基づいて、標準条件パラメータＤＢ２ｂ１、標準実施スケジュールＤＢ２ｂ２、あるいは標準リソース予約ＤＢ２ｂ３から取得される。従って、医師は、患者の疾患に対応する医療行為やその実施手順を確認し、標準化された内容及び手順にて医療行為を行うことができる。また、処理対象になっている患者ＩＤ（以下「当該患者ＩＤ」）やユニットＩＤ（以下「当該ユニットＩＤ」）は、医師がプロセスチャートやユニットシートを介して患者状態を入力することで、あるいは、医師が患者ＩＤやユニットＩＤを支援端末２０に入力することで、医療行為支援サーバ１において特定されるものとし、この特定に関する処理の説明を省略する。
まず、医療行為支援処理の全体について説明する。図１３は、医療行為支援処理のフローチャートである。最初に、医師が支援端末２０を介して患者の患者ＩＤ及び疾患名を入力すると共に、医療プロセスの開始を指示すると、これらの情報が支援端末２０から医療行為支援サーバ１に送信される。この医療行為支援サーバ１のプロセス管理部３ａは、支援端末２０からの情報の入力を受け付けると（ステップＳＢ−１，Ｙｅｓ）、当該患者の疾患名に対応するプロセス情報をプロセスＤＢ２ａ１から取得し、当該取得したプロセス情報に患者ＩＤを付加することでプロセス履歴情報を生成し、このプロセス履歴情報をプロセス履歴ＤＢ２ｃ１に格納する（ステップＳＢ−２）。このようにプロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報のプロセスチャートやユニットシートは、医師が支援端末２０を介して任意のタイミングで呼び出し、当該支援端末２０のモニタを介して閲覧できる。この際に必要な情報の一部は、プロセス履歴情報の患者ＩＤ、ユニットＩＤ、あるいはリソースＩＤに基づいて、標準条件パラメータＤＢ２ｂ１、標準実施スケジュールＤＢ２ｂ２、あるいは標準リソース予約ＤＢ２ｂ３から取得される。従って、医師は、患者の疾患に対応する医療行為やその実施手順を確認し、標準化された内容及び手順にて医療行為を行うことができる。また、処理対象になっている患者ＩＤ（以下「当該患者ＩＤ」）やユニットＩＤ（以下「当該ユニットＩＤ」）は、医師がプロセスチャートやユニットシートを介して患者状態を入力することで、あるいは、医師が患者ＩＤやユニットＩＤを支援端末２０に入力することで、医療行為支援サーバ１において特定されるものとし、この特定に関する処理の説明を省略する。
（処理−全体処理−関連情報の初期値−条件パラメータ）
次いで、情報更新部３ｂは、関連情報の初期値を設定する（ステップＳＢ−３）。具体的には、条件パラメータの初期値の設定は条件パラメータ更新部３ｂ１によって以下のように行われる。すなわち、条件パラメータ更新部３ｂ１は、プロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報から当該患者ＩＤに対応する各ユニットＩＤを取得し、これら各ユニットＩＤに対応する「条件パラメータ」を標準条件パラメータＤＢ２ｂ１から取得し、この「条件パラメータ」を患者ＩＤ及びユニットＩＤに関連付けることで条件パラメータ情報を生成して、この条件パラメータ情報を条件パラメータＤＢ２ｄ１に格納する。この際、一つの指示内容に対して複数の条件パラメータが設定されている場合、条件パラメータ更新部３ｂ１は、いずれか一つの条件パラメータを所定方法で選択し（例えば、先頭に格納されている条件パラメータをデフォルトとして選択し）、当該選択した条件パラメータを条件パラメータＤＢ２ｄ１に格納する。このように設定された条件パラメータ情報の初期値は、例えば医師がプロセス履歴情報のユニットシートを支援端末２０で閲覧する毎に、条件パラメータＤＢ２ｄ１から呼び出されて図３に示すようにユニットシートに出力される。従って、医師は、条件付き指示の判断を行う基準になる条件パラメータを容易に把握できる。
次いで、情報更新部３ｂは、関連情報の初期値を設定する（ステップＳＢ−３）。具体的には、条件パラメータの初期値の設定は条件パラメータ更新部３ｂ１によって以下のように行われる。すなわち、条件パラメータ更新部３ｂ１は、プロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報から当該患者ＩＤに対応する各ユニットＩＤを取得し、これら各ユニットＩＤに対応する「条件パラメータ」を標準条件パラメータＤＢ２ｂ１から取得し、この「条件パラメータ」を患者ＩＤ及びユニットＩＤに関連付けることで条件パラメータ情報を生成して、この条件パラメータ情報を条件パラメータＤＢ２ｄ１に格納する。この際、一つの指示内容に対して複数の条件パラメータが設定されている場合、条件パラメータ更新部３ｂ１は、いずれか一つの条件パラメータを所定方法で選択し（例えば、先頭に格納されている条件パラメータをデフォルトとして選択し）、当該選択した条件パラメータを条件パラメータＤＢ２ｄ１に格納する。このように設定された条件パラメータ情報の初期値は、例えば医師がプロセス履歴情報のユニットシートを支援端末２０で閲覧する毎に、条件パラメータＤＢ２ｄ１から呼び出されて図３に示すようにユニットシートに出力される。従って、医師は、条件付き指示の判断を行う基準になる条件パラメータを容易に把握できる。
（処理−全体処理−関連情報の初期値−実施スケジュール）
また、実施スケジュールの初期値の設定は実施スケジュール更新部３ｂ２によって以下のように行われる。すなわち、実施スケジュール更新部３ｂ２は、プロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報から当該患者ＩＤに対応する各ユニットＩＤを取得し、これら各ユニットＩＤに対応する「標準日数」を標準実施スケジュールＤＢ２ｂ２から取得する。また、実施スケジュール更新部３ｂ２は、現在の年月日（以下「現在年月日」）を公知の方法で取得する（例えば医療行為支援サーバ１の内部クロックから取得する）。そして、実施スケジュール更新部３ｂ２は、当該取得した現在年月日を、プロセスチャートの最初のユニットシートの移行年月日とする。また、実施スケジュール更新部３ｂ２は、それ以降の各ユニットシートの移行年月日を、当該取得した現在年月日に対して当該各ユニットシートの以前に実施される全てのユニットシートの標準日数を付加することで算定する。
また、実施スケジュールの初期値の設定は実施スケジュール更新部３ｂ２によって以下のように行われる。すなわち、実施スケジュール更新部３ｂ２は、プロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報から当該患者ＩＤに対応する各ユニットＩＤを取得し、これら各ユニットＩＤに対応する「標準日数」を標準実施スケジュールＤＢ２ｂ２から取得する。また、実施スケジュール更新部３ｂ２は、現在の年月日（以下「現在年月日」）を公知の方法で取得する（例えば医療行為支援サーバ１の内部クロックから取得する）。そして、実施スケジュール更新部３ｂ２は、当該取得した現在年月日を、プロセスチャートの最初のユニットシートの移行年月日とする。また、実施スケジュール更新部３ｂ２は、それ以降の各ユニットシートの移行年月日を、当該取得した現在年月日に対して当該各ユニットシートの以前に実施される全てのユニットシートの標準日数を付加することで算定する。
例えば、現在年月日が「２００７年９月１日」、プロセスチャートの最初のユニットシートの標準日数が「３日」、プロセスチャートの２番目のユニットシートの標準日数が「４日」である場合、最初のユニットシートの移行年月日は「２００７年９月１日」に設定され、２番目のユニットシートの移行年月日は「２００７年９月４日」と算定され、３番目のユニットシートの移行年月日は「２００７年９月８日」と算定される。プロセスチャートに分岐がある場合には、各分岐先のユニットシートについてそれぞれ移行年月日を算定する。次いで、実施スケジュール更新部３ｂ２は、このように算定した移行年月日を当該患者ＩＤ及び各ユニットＩＤに関連付けることで実施スケジュール情報を生成し、当該生成した実施スケジュール情報を実施スケジュールＤＢ２ｄ２に格納する。このように設定された実施スケジュール情報の初期値は、例えば医師がプロセス履歴情報のプロセスチャートを支援端末２０で閲覧する毎に、実施スケジュールＤＢ２ｄ２から呼び出されてプロセスチャートに同時に出力される。従って、医師は、プロセスにおける各医療行為の実施スケジュールを容易に把握でき、臨床工程を時間的観点から俯瞰してその管理を容易に行うことができる。
（処理−全体処理−関連情報の初期値−リソース予約）
また、リソース予約の初期値の設定はリソース予約更新部３ｂ３によって以下のように行われる。すなわち、リソース予約更新部３ｂ３は、プロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報から当該患者ＩＤに対応する各ユニットＩＤを取得する。また、リソース予約更新部３ｂ３は、これら各ユニットＩＤに対応する「リソースＩＤ」及び「使用日」を標準リソース予約ＤＢ２ｂ３から取得すると共に、先に実施スケジュールＤＢ２ｄ２に実施スケジュールの初期値として記憶させた各ユニットシートの「移行年月日」を取得する。そして、リソース予約更新部３ｂ３は、当該取得した各ユニットシートの移行年月日に対して、各リソースの使用日を付加することで、各ユニットシートにおける各リソースの予約年月日を算定する。例えば、あるユニットシートの移行年月日が「２００７年９月４日」であり、当該ユニットシートに含まれるリソースの使用日が「２」であった場合、当該リソースの予約年月日は「２００７年９月６日」と算定される。
また、リソース予約の初期値の設定はリソース予約更新部３ｂ３によって以下のように行われる。すなわち、リソース予約更新部３ｂ３は、プロセス履歴ＤＢ２ｃ１に格納されたプロセス履歴情報から当該患者ＩＤに対応する各ユニットＩＤを取得する。また、リソース予約更新部３ｂ３は、これら各ユニットＩＤに対応する「リソースＩＤ」及び「使用日」を標準リソース予約ＤＢ２ｂ３から取得すると共に、先に実施スケジュールＤＢ２ｄ２に実施スケジュールの初期値として記憶させた各ユニットシートの「移行年月日」を取得する。そして、リソース予約更新部３ｂ３は、当該取得した各ユニットシートの移行年月日に対して、各リソースの使用日を付加することで、各ユニットシートにおける各リソースの予約年月日を算定する。例えば、あるユニットシートの移行年月日が「２００７年９月４日」であり、当該ユニットシートに含まれるリソースの使用日が「２」であった場合、当該リソースの予約年月日は「２００７年９月６日」と算定される。
次いで、リソース予約更新部３ｂ３は、このように算定した予約年月日を、当該患者ＩＤ及び当該ユニットＩＤと、先に取得したリソースＩＤとに関連付けてリソース予約情報を生成し、当該生成したリソース予約情報をリソース予約ＤＢ２ｄ３に格納する。このように設定されたリソース予約情報の初期値は、医療行為支援サーバ１から関連サーバ群１０のオーダサーバ１２に送信され、オーダサーバ１２によってリソースの発注処理や予約処理が行われる。従って、将来的に必要になる各種のリソースを、標準化された予定に基づいて発注や予約でき、リソース管理を容易に行うことができる。
（処理−全体処理）
次いで、図１３において、医師は、患者状態が変化する毎に、最新の患者状態（例えば、体温、血圧、呼吸数、各種の検査結果を示す数値等）を支援端末２０を介して入力する。この患者状態は、支援端末２０から医療行為支援サーバ１に送信される。患者状態の入力が医療行為支援サーバ１において受け付けられた場合には（ステップＳＢ−４，Ｙｅｓ）、情報更新部３ｂが関連情報を更新するための情報更新処理を行なうことで関連情報が更新される（ステップＳＢ−５）。この更新処理の具体的内容は後述する。
次いで、図１３において、医師は、患者状態が変化する毎に、最新の患者状態（例えば、体温、血圧、呼吸数、各種の検査結果を示す数値等）を支援端末２０を介して入力する。この患者状態は、支援端末２０から医療行為支援サーバ１に送信される。患者状態の入力が医療行為支援サーバ１において受け付けられた場合には（ステップＳＢ−４，Ｙｅｓ）、情報更新部３ｂが関連情報を更新するための情報更新処理を行なうことで関連情報が更新される（ステップＳＢ−５）。この更新処理の具体的内容は後述する。
次いで、プロセス管理部３ａは、入力された患者状態と、プロセス履歴ＤＢ２ｃ１に記憶されたユニットシートの目標状態とを比較して、患者状態が目標状態に達したか否かを判定する（ステップＳＢ−６）。そして、患者の状態が目標状態に達したと判定された場合（ステップＳＢ−６，Ｙｅｓ）、プロセス管理部３ａは、プロセスチャートによって規定される次順のユニットのユニットシートの内容をプロセス履歴ＤＢ２ｃ１から取得して支援端末２０に送信する（ステップＳＢ−７）。このユニットシートの内容を支援端末２０を介して閲覧することで、医師は、患者状態に合致したユニットシートの内容を閲覧でき、医療行為の実施内容を確認できる。またこのようにユニットを移行した場合、プロセス管理部３ａは、現在年月日を公知の方法で取得し、この現在年月日を、移行先のユニットのユニットシートの移行年月日としてプロセス履歴ＤＢ２ｃ１に記憶する（ステップＳＢ−８）。
一方、ステップＳＢ−６において患者状態が目標状態に達していないと判定された場合（ステップＳＢ−６，Ｎｏ）、プロセス管理部３ａは、次のユニットシートに移行することなく、次の患者状態の入力が受け付けられるまで待機する。以降、同様にステップＳＢ−４〜ＳＢ−８を繰り返すことで、医療行為が実施される。なお、患者状態が目標状態から大きく乖離した場合には、警告や必要な処置内容を支援端末２０に出力するようにしてもよい。すなわち、ユニットシートに、目標状態とは別に、目標状態からの危険な乖離の判断基準を示す遷移状態や、当該遷移状態になった場合に出力すべき警告や処置内容を予めプロセス情報として格納しておき、ステップＳＢ−６において患者状態が当該遷移状態になったと判断された場合には、これら警告や処置内容を行うようにしてもよい。
（処理−情報更新処理）
次に、ステップＳＢ−５の情報更新処理の具体的内容について説明する。図１４は情報更新処理のフローチャートである。この処理では、条件パラメータを更新するための条件パラメータ更新処理（ステップＳＣ−１）、実施スケジュールを更新するための実施スケジュール更新処理（ステップＳＣ−２）、及び、リソース予約を更新するためのリソース予約更新処理（ステップＳＣ−３）を順次行う。以下、これら各更新処理について順次説明する。
次に、ステップＳＢ−５の情報更新処理の具体的内容について説明する。図１４は情報更新処理のフローチャートである。この処理では、条件パラメータを更新するための条件パラメータ更新処理（ステップＳＣ−１）、実施スケジュールを更新するための実施スケジュール更新処理（ステップＳＣ−２）、及び、リソース予約を更新するためのリソース予約更新処理（ステップＳＣ−３）を順次行う。以下、これら各更新処理について順次説明する。
（処理−情報更新処理−条件パラメータ更新処理）
まず、条件パラメータ更新処理について説明する。図１５は条件パラメータ更新処理のフローチャートである。条件パラメータ更新部３ｂ１は、標準条件パラメータＤＢ２ｂ１における当該患者ＩＤに対応する標準条件パラメータ情報の中から、図１３のステップＳＢ−４において受け付けられた患者状態に合致する条件パラメータ選択基準を特定し、当該特定した条件パラメータ選択基準に対応する条件パラメータと、当該条件パラメータに対応するガイド情報とを取得する（ステップＳＤ−１）。そして、条件パラメータ更新部３ｂ１は、当該取得した条件パラメータを、当該患者ＩＤ及び当該ユニットＩＤに関連付けて条件パラメータＤＢ２ｄ１に格納することで、条件パラメータ情報を更新する（ステップＳＤ−２）。次いで、条件パラメータ更新部３ｂ１は、ステップＳＤ−１で取得した条件パラメータ及びガイド情報を支援端末２０に送信する（ステップＳＤ−３）。この結果、支援端末２０で閲覧されているユニットシートの条件付き指示の条件パラメータが更新されるので、医師は、患者状態に応じた新たな条件パラメータを基準として、患者状態が条件付き指示に合致するか否かを判断できる。例えば、図３のユニットシートでは、条件パラメータの初期値である血圧＝「１３５以上」で指示内容「血圧降下剤投与」を行う旨が表示されているが、医師によって入力された患者状態が体温３７℃以上の場合、図６の例では条件パラメータ「１３０以上」が取得されるので、図１８の表示画面例に示すように、条件パラメータが血圧＝「１３０以上」で指示内容「血圧降下剤投与」を行う旨の表示に自動的に切り替わる。また、更新された条件パラメータの近傍にガイド情報が表示されるので、医師に対して、条件パラメータの更新に伴う各種の注意喚起を行うことができる。なお、図１８の例では、ユニットシートの内部にガイド情報を表示しているが、当該ユニットシートとは別画面のナビゲーション用の画面に表示してもよい。
まず、条件パラメータ更新処理について説明する。図１５は条件パラメータ更新処理のフローチャートである。条件パラメータ更新部３ｂ１は、標準条件パラメータＤＢ２ｂ１における当該患者ＩＤに対応する標準条件パラメータ情報の中から、図１３のステップＳＢ−４において受け付けられた患者状態に合致する条件パラメータ選択基準を特定し、当該特定した条件パラメータ選択基準に対応する条件パラメータと、当該条件パラメータに対応するガイド情報とを取得する（ステップＳＤ−１）。そして、条件パラメータ更新部３ｂ１は、当該取得した条件パラメータを、当該患者ＩＤ及び当該ユニットＩＤに関連付けて条件パラメータＤＢ２ｄ１に格納することで、条件パラメータ情報を更新する（ステップＳＤ−２）。次いで、条件パラメータ更新部３ｂ１は、ステップＳＤ−１で取得した条件パラメータ及びガイド情報を支援端末２０に送信する（ステップＳＤ−３）。この結果、支援端末２０で閲覧されているユニットシートの条件付き指示の条件パラメータが更新されるので、医師は、患者状態に応じた新たな条件パラメータを基準として、患者状態が条件付き指示に合致するか否かを判断できる。例えば、図３のユニットシートでは、条件パラメータの初期値である血圧＝「１３５以上」で指示内容「血圧降下剤投与」を行う旨が表示されているが、医師によって入力された患者状態が体温３７℃以上の場合、図６の例では条件パラメータ「１３０以上」が取得されるので、図１８の表示画面例に示すように、条件パラメータが血圧＝「１３０以上」で指示内容「血圧降下剤投与」を行う旨の表示に自動的に切り替わる。また、更新された条件パラメータの近傍にガイド情報が表示されるので、医師に対して、条件パラメータの更新に伴う各種の注意喚起を行うことができる。なお、図１８の例では、ユニットシートの内部にガイド情報を表示しているが、当該ユニットシートとは別画面のナビゲーション用の画面に表示してもよい。
なお、ガイド情報の表示に加えて、支援端末２０で閲覧されているユニットシートの条件付き指示の表示欄に、条件パラメータが更新された旨の注意喚起を行うための所定の表示（例えば、条件付き指示の表示欄を明滅させたり、注意喚起用の所定マークを点滅表示する等）を行ってもよい。具体的には、プロセス情報がＸＭＬにて記述されている場合には所定の表示制御用のタグを当該プロセス情報に付加したり、所定の制御コードを支援端末２０に出力することで実行する。これにて条件パラメータ更新処理が終了する。この処理によれば、医師は、条件パラメータが更新されたことを確実に認識でき、患者状態が条件付き指示に合致するか否かを新規な条件パラメータに基づいて正確に判断できる。
（処理−情報更新処理−実施スケジュール更新処理）
次に、実施スケジュール更新処理について説明する。図１６は実施スケジュール更新処理のフローチャートである。まず実施スケジュール更新部３ｂ２は、当該患者ＩＤ及び当該ユニットＩＤに対応する標準日数であって、現在のユニットシート以降の各ユニットシートの標準日数を標準実施スケジュールＤＢ２ｂ２から取得すると共に（ステップＳＥ−１）、現在年月日を公知の方法で取得する（ステップＳＥ−２）。次いで、実施スケジュール更新部３ｂ２は、現在のユニットシート以降の各ユニットシートの実施スケジュールの移行年月日を、当該取得した現在年月日に対して当該各ユニットシートの以前に実施される全てのユニットシートの標準日数を付加することで算定する（ステップＳＥ−３）。このことにより、例えば、現在のユニットシートを実行している日（すなわち現在年月日）が、先に初期値として設定した移行年月日と異なる場合には、その差分を修正した実施スケジュールが算定されることになる。
次に、実施スケジュール更新処理について説明する。図１６は実施スケジュール更新処理のフローチャートである。まず実施スケジュール更新部３ｂ２は、当該患者ＩＤ及び当該ユニットＩＤに対応する標準日数であって、現在のユニットシート以降の各ユニットシートの標準日数を標準実施スケジュールＤＢ２ｂ２から取得すると共に（ステップＳＥ−１）、現在年月日を公知の方法で取得する（ステップＳＥ−２）。次いで、実施スケジュール更新部３ｂ２は、現在のユニットシート以降の各ユニットシートの実施スケジュールの移行年月日を、当該取得した現在年月日に対して当該各ユニットシートの以前に実施される全てのユニットシートの標準日数を付加することで算定する（ステップＳＥ−３）。このことにより、例えば、現在のユニットシートを実行している日（すなわち現在年月日）が、先に初期値として設定した移行年月日と異なる場合には、その差分を修正した実施スケジュールが算定されることになる。
さらに実施スケジュール更新部３ｂ２は、このように算定した移行年月日を、当該患者のこれまでの臨床経過に基づいて調整する。具体的には、実施スケジュール更新部３ｂ２は、プロセス履歴ＤＢ２ｃ１を参照し、当該患者がこれまでに各ユニットシートを終了するまでに実際に要した日数（以下「所要日数」）を算定する（ステップＳＥ−４）。この算定は、当該患者に対してこれまでに実施が完了した各ユニットシートへの移行年月日と、当該各ユニットシートの次順の移行年月日との差分として求めることができる。そして、実施スケジュール更新部３ｂ２は、当該算定した所要日数とステップＳＥ−１において取得した各ユニットシートの標準日数との差分をユニットシート毎に求め、これら全ての差分の平均値を算定する（ステップＳＥ−５）。例えば、プロセスチャートの最初のユニットシートの所要日数が「５日」、当該ユニットシートの標準日数が「３日」であった場合、所要日数と標準日数との差分は「＋２日」となる。また、次順のユニットシートの所要日数が「８日」、当該ユニットシートの標準日数が「４日」であった場合、所要日数と標準日数との差分は「＋４日」となる。そして、全ての差分の平均値は、３日（＝（２日＋４日）／２）と算定される。
次いで、実施スケジュール更新部３ｂ２は、当該算定した平均値を、先のステップＳＥ−３において算定した移行年月日に対して加算することで、調整された移行年月日を求める（ステップＳＥ−６）。その後、実施スケジュール更新部３ｂ２は、このように調整した移行年月日を、実施スケジュールＤＢ２ｄ２に当該患者ＩＤに関連付けて記憶させることで、実施スケジュール情報を更新する（ステップＳＥ−７）。このように更新された移行年月日は、例えば医師がプロセス履歴情報のプロセスチャートを支援端末２０で閲覧する毎に、実施スケジュールＤＢ２ｄ２から呼び出されて支援端末２０に送信され、プロセスチャートに同時に出力される。これにて実施スケジュール更新処理が終了する。この処理によれば、医師は、患者状態に適合した各医療行為の最新の実施スケジュールを容易に把握でき、臨床工程管理を一層正確に行うことができる。特に、過去の臨床履歴に基づいて調整された実施スケジュールを把握できるので、患者の個別的な臨床傾向に合致した実施スケジュールを把握でき、患者の個別的な実情に応じた臨床工程管理を行うことができる。
（処理−情報更新処理−リソース予約更新処理）
最後に、リソース予約更新処理について説明する。図１７はリソース予約更新処理のフローチャートである。まずリソース予約更新部３ｂ３は、当該患者ＩＤ及び当該ユニットＩＤに対応する使用日であって、現在のユニットシート以降の各ユニットシートにおける各リソースのリソースＩＤ及び使用日を標準リソース予約ＤＢ２ｂ３から取得する（ステップＳＦ−１）。また、リソース予約更新部３ｂ３は、上述した実施スケジュール更新処理において更新された実施スケジュールＤＢ２ｄ２から、現在のユニットシート以降の各ユニットシートの移行年月日を取得する（ステップＳＦ−２）。そして、当該取得した各ユニットシートの移行年月日に対して、各リソースの使用開始日を付加することで、現在のユニットシート以降の各ユニットシートにおける各リソースの予約年月日を算定する（ステップＳＦ−３）。次いでリソース予約更新部３ｂ３は、このように算定した予約年月日を、リソース予約ＤＢ２ｄ３に患者ＩＤ、ユニットＩＤ，及びリソースＩＤに関連付けて記憶させることで、リソース予約情報を更新する（ステップＳＦ−４）。
最後に、リソース予約更新処理について説明する。図１７はリソース予約更新処理のフローチャートである。まずリソース予約更新部３ｂ３は、当該患者ＩＤ及び当該ユニットＩＤに対応する使用日であって、現在のユニットシート以降の各ユニットシートにおける各リソースのリソースＩＤ及び使用日を標準リソース予約ＤＢ２ｂ３から取得する（ステップＳＦ−１）。また、リソース予約更新部３ｂ３は、上述した実施スケジュール更新処理において更新された実施スケジュールＤＢ２ｄ２から、現在のユニットシート以降の各ユニットシートの移行年月日を取得する（ステップＳＦ−２）。そして、当該取得した各ユニットシートの移行年月日に対して、各リソースの使用開始日を付加することで、現在のユニットシート以降の各ユニットシートにおける各リソースの予約年月日を算定する（ステップＳＦ−３）。次いでリソース予約更新部３ｂ３は、このように算定した予約年月日を、リソース予約ＤＢ２ｄ３に患者ＩＤ、ユニットＩＤ，及びリソースＩＤに関連付けて記憶させることで、リソース予約情報を更新する（ステップＳＦ−４）。
このように更新されたリソース予約情報は、医療行為支援サーバ１から関連サーバ群１０のオーダサーバ１２に送信される。このオーダーシステムは、当該送信された新規なリソース予約情報に基づいて、リソース予約情報の初期値に基づいて行ったリソースの予約を必要に応じて修正し、オーダサーバ１２によってリソースの発注修正処理や予約更新処理を行う。これにてリソース予約更新処理が終了する。この処理によれば、将来的に必要になる各種のリソースの予約を、患者状態に合致した内容に更新でき、患者状態に適合したリソース管理を容易に行うことができる。特に、新規なリソース予約情報は、実施スケジュール更新処理において過去の臨床履歴に基づいて調整された実施スケジュールを基準として更新されているので、患者の個別的な臨床傾向に合致したリソースの使用タイミングを把握でき、患者の個別的な実情に応じたリソース管理を行うことができる。
（実施の形態の効果）
このように本実施の形態によれば、プロセスチャートやユニットシートを医師が支援端末２０を介して任意のタイミングで呼び出し、当該支援端末２０のモニタを介して閲覧できるので、医師は、患者の病名に対応する医療行為やその実施手順を確認し、標準化された内容及び手順にて医療行為を行うことができる。
また、支援端末２０で閲覧されているユニットシートの条件付き指示の条件パラメータが更新されるので、医師は、患者状態に応じた新たな条件パラメータを基準として、患者状態が条件付き指示に合致するか否かを判断できる。特に、医師は、条件パラメータが更新されたことを確実に認識でき、患者状態が条件付き指示に合致するか否かを新規な条件パラメータに基づいて正確に判断できる。
さらに、医師は、プロセスにおける各医療行為の実施スケジュールを容易に把握でき、臨床工程を時間的観点から俯瞰してその管理を容易に行うことができる。特に、過去の臨床履歴に基づいて調整された実施スケジュールを把握できるので、患者の個別的な臨床傾向に合致した実施スケジュールを把握でき、患者の個別的な実情に応じた臨床工程管理を行うことができる。
さらにまた、将来的に必要になる各種のリソースの予約を、患者状態に合致した内容に更新でき、患者状態に適合したリソース管理を容易に行うことができる。特に、新規なリソース予約情報は、実施スケジュール更新処理において過去の臨床履歴に基づいて調整された実施スケジュールを基準として更新されているので、患者の個別的な臨床傾向に合致したリソースの使用タイミングを把握でき、患者の個別的な実情に応じたリソース管理を行うことができる。
このように本実施の形態によれば、プロセスチャートやユニットシートを医師が支援端末２０を介して任意のタイミングで呼び出し、当該支援端末２０のモニタを介して閲覧できるので、医師は、患者の病名に対応する医療行為やその実施手順を確認し、標準化された内容及び手順にて医療行為を行うことができる。
また、支援端末２０で閲覧されているユニットシートの条件付き指示の条件パラメータが更新されるので、医師は、患者状態に応じた新たな条件パラメータを基準として、患者状態が条件付き指示に合致するか否かを判断できる。特に、医師は、条件パラメータが更新されたことを確実に認識でき、患者状態が条件付き指示に合致するか否かを新規な条件パラメータに基づいて正確に判断できる。
さらに、医師は、プロセスにおける各医療行為の実施スケジュールを容易に把握でき、臨床工程を時間的観点から俯瞰してその管理を容易に行うことができる。特に、過去の臨床履歴に基づいて調整された実施スケジュールを把握できるので、患者の個別的な臨床傾向に合致した実施スケジュールを把握でき、患者の個別的な実情に応じた臨床工程管理を行うことができる。
さらにまた、将来的に必要になる各種のリソースの予約を、患者状態に合致した内容に更新でき、患者状態に適合したリソース管理を容易に行うことができる。特に、新規なリソース予約情報は、実施スケジュール更新処理において過去の臨床履歴に基づいて調整された実施スケジュールを基準として更新されているので、患者の個別的な臨床傾向に合致したリソースの使用タイミングを把握でき、患者の個別的な実情に応じたリソース管理を行うことができる。
〔III〕各実施の形態に対する変形例
以上、本発明に係る各実施の形態について説明したが、本発明の具体的な構成及び手段は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良できる。以下、このような変形例について説明する。
以上、本発明に係る各実施の形態について説明したが、本発明の具体的な構成及び手段は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良できる。以下、このような変形例について説明する。
（解決しようとする課題や発明の効果について）
まず、発明が解決しようとする課題や発明の効果は、前記した内容に限定されるものではなく、本発明によって、前記に記載されていない課題を解決したり、前記に記載されていない効果を奏することもでき、また、記載されている課題の一部のみを解決したり、記載されている効果の一部のみを奏することがある。
まず、発明が解決しようとする課題や発明の効果は、前記した内容に限定されるものではなく、本発明によって、前記に記載されていない課題を解決したり、前記に記載されていない効果を奏することもでき、また、記載されている課題の一部のみを解決したり、記載されている効果の一部のみを奏することがある。
（構成及び制御について）
また、上記各実施の形態で自動的に行われるものとして説明した制御の全部または任意の一部を手動で行っても良く、逆に、手動で行われるものとして説明した制御の全部または任意の一部を公知技術または上述した思想に基づいて自動化しても良い。また、上記実施の形態において示した各構成要素の各機能ブロックの一部又は全部を、ハードワイヤードロジックにて構成しても良い。
また、上記各実施の形態で自動的に行われるものとして説明した制御の全部または任意の一部を手動で行っても良く、逆に、手動で行われるものとして説明した制御の全部または任意の一部を公知技術または上述した思想に基づいて自動化しても良い。また、上記実施の形態において示した各構成要素の各機能ブロックの一部又は全部を、ハードワイヤードロジックにて構成しても良い。
（分散や統合について）
また、上述した各電気的構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成できる。例えば、医療行為支援サーバ１の全部又は一部の機能を支援端末２０に持たせることで、ネットワーク構成を用いることなく、支援端末２０単独で患者状態適応型パスシステムを実行したり、関連情報の動的更新を行うようにしてもよい。
また、上述した各電気的構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成できる。例えば、医療行為支援サーバ１の全部又は一部の機能を支援端末２０に持たせることで、ネットワーク構成を用いることなく、支援端末２０単独で患者状態適応型パスシステムを実行したり、関連情報の動的更新を行うようにしてもよい。
あるいは、医療行為支援サーバ１の一部の機能を他のサーバに分散配置してもよい。また、医療行為支援サーバ１の各ＤＢを分離又は統合することもでき、標準条件パラメータＤＢ２ｂ１、標準実施スケジュールＤＢ２ｂ２、標準リソース予約ＤＢ２ｂ３の内容を、プロセスＤＢ２ａ１の各ユニットシートの内容として記憶させてたり、条件パラメータＤＢ２ｄ１、実施スケジュールＤＢ２ｄ２、及びリソース予約ＤＢ２ｄ３の内容を、プロセス履歴ＤＢ２ｃ１の各ユニットシートの内容として記憶させてもよい。
（関連情報の更新タイミングについて）
上記実施の形態では、患者状態の入力が受け付けられる毎に関連情報を更新しているが、関連情報の全部又は一部については他の任意のタイミングで更新してもよく、例えば、実施スケジュールやリソース予約は、ユニットシートが次順のユニットシートに移行した時点でのみ更新するようにしてもよい。
上記実施の形態では、患者状態の入力が受け付けられる毎に関連情報を更新しているが、関連情報の全部又は一部については他の任意のタイミングで更新してもよく、例えば、実施スケジュールやリソース予約は、ユニットシートが次順のユニットシートに移行した時点でのみ更新するようにしてもよい。
（関連情報の更新基準について）
上記実施の形態では、条件パラメータを、各ユニットの患者状態に基づいて更新しているが、過去の患者状態の履歴に基づいて更新するようにしてもよい。例えば、患者に対して過去に実施されたユニットにおける、所定の基準状態変化や標準日数に対する患者の状態変化や所要日数の差分を求め、この差分を基準として、条件パラメータを選択してもよい。
上記実施の形態では、条件パラメータを、各ユニットの患者状態に基づいて更新しているが、過去の患者状態の履歴に基づいて更新するようにしてもよい。例えば、患者に対して過去に実施されたユニットにおける、所定の基準状態変化や標準日数に対する患者の状態変化や所要日数の差分を求め、この差分を基準として、条件パラメータを選択してもよい。
この発明は、医療分野を含む様々な分野における実施行為の標準化システムに適用できるもので、実施行為に関連する情報を対象の状態に応じて動的に変化させることで、実施行為の計画管理等を最適化することに有用である。
１ 医療行為支援サーバ
２ 記憶部
２ａ 実施行為情報記憶部
２ａ１ プロセスＤＢ
２ｂ 標準情報記憶部
２ｂ１ 標準条件パラメータＤＢ
２ｂ２ 標準実施スケジュールＤＢ
２ｂ３ 標準リソース予約ＤＢ
２ｃ 履歴情報記憶部
２ｃ１ プロセス履歴ＤＢ
２ｄ 関連情報記憶部
２ｄ１ 条件パラメータＤＢ
２ｄ２ 実施スケジュールＤＢ
２ｄ３ リソース予約ＤＢ
３ 制御部
３ａ プロセス管理部
３ｂ 情報更新部
３ｂ１ 条件パラメータ更新部
３ｂ２ 実施スケジュール更新部
３ｂ３ リソース予約更新部
４ ネットワークＩＦ
５ バス
１０ 関連サーバ群
１１ 医事会計サーバ
１２ オーダサーバ
２０ 支援端末
３０ ネットワーク
２ 記憶部
２ａ 実施行為情報記憶部
２ａ１ プロセスＤＢ
２ｂ 標準情報記憶部
２ｂ１ 標準条件パラメータＤＢ
２ｂ２ 標準実施スケジュールＤＢ
２ｂ３ 標準リソース予約ＤＢ
２ｃ 履歴情報記憶部
２ｃ１ プロセス履歴ＤＢ
２ｄ 関連情報記憶部
２ｄ１ 条件パラメータＤＢ
２ｄ２ 実施スケジュールＤＢ
２ｄ３ リソース予約ＤＢ
３ 制御部
３ａ プロセス管理部
３ｂ 情報更新部
３ｂ１ 条件パラメータ更新部
３ｂ２ 実施スケジュール更新部
３ｂ３ リソース予約更新部
４ ネットワークＩＦ
５ バス
１０ 関連サーバ群
１１ 医事会計サーバ
１２ オーダサーバ
２０ 支援端末
３０ ネットワーク
Claims (6)
- 所定対象に対して実施すべき実施行為の内容を実施行為単位で特定するための実施行為情報と、複数の前記実施行為情報にて内容が特定される複数の実施行為の相互間における実施順序を特定するための実施順序情報と、を格納する実施行為情報格納手段と、
前記所定対象の状態又は前記実施行為の実施状態に応じて変化し得る関連情報を格納する関連情報格納手段と、
所定対象に対して過去に実施された実施行為の内容を特定するための前記実施行為情報と、所定対象に対して過去に実施された実施行為の実施日数を特定するための実施日数情報と、を格納する実施履歴情報格納手段と、
前記所定対象の状態又は前記実施行為の実施状態を特定するための状態情報の入力を受け付ける入力手段と、
前記状態情報の入力が前記入力手段を介して受け付けられた場合に、当該状態情報に基づいて前記実施行為情報格納手段を参照することにより将来的に実施され得る前記実施行為及び当該実施行為の実施順序を特定し、当該特定された実施行為を当該特定された実施順序に従って実施する場合における関連情報を所定方法にて決定し、当該決定した関連情報に基づいて前記関連情報格納手段に格納された関連情報を更新する情報更新手段と、
前記情報更新手段にて更新された関連情報を所定の出力先に出力する出力手段とを備え、
前記情報更新手段は、前記実施履歴情報格納手段に格納された前記実施行為情報及び前記実施日数情報に基づいて前記関連情報を決定すること、
を特徴とする実施行為支援装置。 - 前記実施行為情報は、患者に対して実施すべき医療行為の内容を医療行為単位で特定するための情報であり、
前記実施順序情報は、複数の前記実施行為情報にて内容が特定される複数の医療行為の相互間における実施順序を特定するための情報であり、
前記状態情報は、前記患者の状態を特定するための情報又は前記医療行為の実施状態を特定するための情報であり、
前記関連情報は、前記医療行為の実施条件、前記医療行為の実施スケジュール、又は、前記医療行為を実施する際に使用する医療資源、を特定するための情報であること、
を特徴とする請求項１に記載の実施行為支援装置。 - 前記実施行為を実施するための標準的な日数を含む標準スケジュール情報を格納する標準スケジュール情報格納手段を備え、
前記情報更新手段は、前記所定対象に対して過去に実施された実施行為を実施するための標準的な日数を前記標準スケジュール情報格納手段から取得すると共に、前記所定対象に対して過去に実施された当該実施行為の実施日数を前記実施履歴情報格納手段から取得し、当該取得された標準的な日数と当該取得された実施日数との差分を算定し、前記特定された実施行為を実施するための標準的な日数を前記標準スケジュール情報格納手段から取得し、当該取得した標準的な日数を前記算定した差分に基づいて更新すること、
を特徴とする請求項１又は２に記載の実施行為支援装置。 - 前記関連情報の更新に関する状態を報知するための更新状態報知情報を、前記関連情報に関連付けて格納する更新状態報知情報格納手段を備え、
前記情報更新手段は、前記所定方法にて決定した前記関連情報に伴う前記更新状態報知情報を前記更新状態報知情報格納手段から取得し、
前記出力手段は、前記取得された前記更新状態報知情報を所定の出力先に出力すること、
を特徴とする請求項１から３のいずれか一項に記載の実施行為支援装置。 - 前記出力手段は、前記情報更新手段にて更新された関連情報を、前記実施行為を実施するために使用する資源の予約を管理するための所定の資源管理装置に出力すること、
を特徴とする請求項１から４のいずれか一項に記載の実施行為支援装置。 - 所定対象に対して実施すべき実施行為の内容を実施行為単位で特定するための実施行為情報と、複数の前記実施行為情報にて内容が特定される複数の実施行為の相互間における実施順序を特定するための実施順序情報と、を格納する実施行為情報格納手段と、
前記所定対象の状態又は前記実施行為の実施状態に応じて変化し得る関連情報を格納する関連情報格納手段と、
所定対象に対して過去に実施された実施行為の内容を特定するための前記実施行為情報と、所定対象に対して過去に実施された実施行為の実施日数を特定するための実施日数情報と、を格納する実施履歴情報格納手段と、
前記所定対象の状態又は前記実施行為の実施状態を特定するための状態情報の入力を受け付ける入力手段と、
前記関連情報を所定の出力先に出力する出力手段と、
を備えたコンピュータに実行させるプログラムであって、
前記状態情報の入力が前記入力手段を介して受け付けられた場合に、当該状態情報に基づいて前記実施行為情報格納手段を参照することにより将来的に実施され得る前記実施行為及び当該実施行為の実施順序を特定するステップと、
前記特定された実施行為を当該特定された実施順序に従って実施する場合における関連情報を所定方法にて決定するステップと、
前記決定した関連情報に基づいて前記関連情報格納手段に格納された関連情報を更新するステップと、
前記更新された関連情報を前記出力手段を介して前記所定の出力先に出力するステップと、
前記実施履歴情報格納手段に格納された前記実施行為情報及び前記実施日数情報に基づいて前記関連情報を決定するステップと、
を前記コンピュータに実行させるための実施行為支援プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007260625A JP5116423B2 (ja) | 2007-10-04 | 2007-10-04 | 実施行為支援装置及び実施行為支援プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007260625A JP5116423B2 (ja) | 2007-10-04 | 2007-10-04 | 実施行為支援装置及び実施行為支援プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009093252A JP2009093252A (ja) | 2009-04-30 |
| JP5116423B2 true JP5116423B2 (ja) | 2013-01-09 |
Family
ID=40665222
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007260625A Active JP5116423B2 (ja) | 2007-10-04 | 2007-10-04 | 実施行為支援装置及び実施行為支援プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5116423B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012008636A (ja) * | 2010-06-22 | 2012-01-12 | Shinkichi Himeno | 電子カルテの指示文書作成装置 |
| JP5618915B2 (ja) * | 2011-06-13 | 2014-11-05 | 株式会社日立製作所 | 診療支援システム、診療ワークフロー分析システム及び診療支援方法 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003331055A (ja) * | 2002-05-14 | 2003-11-21 | Hitachi Ltd | クリニカルパス運用支援情報システム |
| JP2004118664A (ja) * | 2002-09-27 | 2004-04-15 | Fujitsu Ltd | 診療計画策定装置 |
| JP2004192486A (ja) * | 2002-12-13 | 2004-07-08 | Toshikazu Tanaka | クリティカルパス作成装置および作成方法 |
| JP2005157560A (ja) * | 2003-11-21 | 2005-06-16 | Olympus Corp | 病院情報システム |
| JP5188067B2 (ja) * | 2004-11-25 | 2013-04-24 | 悦功 飯塚 | 医療プロセス質管理システム、医療プロセス質管理方法 |
| JP2007072925A (ja) * | 2005-09-09 | 2007-03-22 | Hitachi Medical Corp | 予約システム |
-
2007
- 2007-10-04 JP JP2007260625A patent/JP5116423B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2009093252A (ja) | 2009-04-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220246287A1 (en) | System and method for dynamically managing surgical preferences | |
| JP7456581B2 (ja) | 継続的改善システムおよび継続的改善システムの作動方法 | |
| US20120296671A1 (en) | Guideline-based patient discharge planning | |
| US20100169771A1 (en) | User Interface for Managing Patient Care Plans | |
| CN102693351B (zh) | 用于临床决策支持的系统和方法 | |
| US20140297331A1 (en) | Systems and methods for organizing, storing, communicating, and verifying information throughout the process of providing healthcare services | |
| WO2016165005A1 (en) | Context-aware careflow engine, platform, device, system, method, and computer-readable medium | |
| JP2021509617A5 (ja) | ||
| US20100169109A1 (en) | Managing Patient Care Plans | |
| JP5116423B2 (ja) | 実施行為支援装置及び実施行為支援プログラム | |
| US20160188841A1 (en) | Medical support apparatus, system and method for medical service | |
| JP2017010165A (ja) | 透析管理システム、透析管理方法、および透析管理プログラム | |
| US20140019159A1 (en) | Method, apparatus, and computer program product for patient charting | |
| US20220310241A1 (en) | Clinical decision support scheduling and alerts | |
| US20160210438A1 (en) | Medical assistance device, control method for medical assistance device, and medical assistance system | |
| JP5053812B2 (ja) | 実施計画統合支援システム及び実施計画統合支援プログラム | |
| JP2005182362A (ja) | 看護医療支援装置、方法、及びプログラム | |
| JP5219557B2 (ja) | 実施行為支援装置及び実施行為支援プログラム | |
| JP2006209288A (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| KR102382541B1 (ko) | 고객 정보를 처리하는 방법 및 디바이스 | |
| JP6558678B2 (ja) | 処方薬管理装置、処方薬管理方法、および、処方薬管理プログラム | |
| JP4984784B2 (ja) | 複数の患者に対する治療計画を情報処理装置に行わせるプログラム、情報処理装置、及び治療計画方法 | |
| JP5604177B2 (ja) | 連携実施計画支援システム及び連携実施計画支援プログラム | |
| JP5300380B2 (ja) | 検診支援装置およびその制御プログラム | |
| JP5219556B2 (ja) | 実施計画作成支援装置及び実施計画作成支援プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100604 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120322 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120328 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120528 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120919 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121016 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 5116423 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20151026 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313117 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |