JP6097232B2 - クリニカルパス管理装置 - Google Patents

Description

本発明は、クリニカルパスを管理するクリニカルパス管理装置に関するものである。

近年、医療機関ではクリニカルパスの導入が進んでいる。クリニカルパスは、目標とする状態に到達するまでの段階的な処置（治療や検査など）計画を示すものであり、クリニカルパスに従って処置を行うことで処置内容が標準化され、医療スタッフや患者の理解度を高めることができる。これにより、医療機関においては、安定した質の高い処置が可能となる。また、患者においては、納得のうえで安心して処置を受けることができる。

一方、クリニカルパスは、あくまで標準的な治療計画を示すものであるため、例えば、患者の病状がクリニカルパスの作成時の予想よりも軽いまたは重いなど、クリニカルパス作成時の状況と現状とが異なる場合もある。このような場合には、クリニカルパスを現状に合わせて適宜変更する必要がある。

クリニカルパスの変更を考慮した技術としては、例えば、下記特許文献１が知られている。下記特許文献１では、クリニカルパスを変更するにあたり、変更の内容を病院資源（病室、手術室、機材、担当者（医師や看護師、検査技師など））のスケジュールと照合して変更が可能か否かを判定し、変更が可能な場合にクリニカルパスを変更している。また、下記特許文献１では、クリニカルパスを変更した場合、その旨を関係機関（影響を受ける医師や看護師など）に通知している。

特開２００５−１５７５６０号公報

上述のように、クリニカルパスは現状に合わせて変更が必要となる場合がある反面、安易な変更が行われてしまうと、患者を不安にさせてしまうだけでなく、医療機関側の混乱を招き、医療ミスの原因ともなりかねない。しかしながら、上記特許文献１では、このような問題については考慮されていない。つまり、上記特許文献１では、クリニカルパスの変更を行う際に、スケジュールの確認しか行っておらず、スケジュールが空いていればクリニカルパスが変更されてしまう。このため、例えば、現場の看護士などの判断でクリニカルパスが変更さてしまい、担当医は変更後に知らされるなどの場合があり問題であった。

本発明は、上記背景を鑑みてなされたものであり、安易なクリニカルパスの変更を防止できるクリニカルパス管理装置を提供することを目的としている。

上記目的を達成するために、本発明のクリニカルパス管理装置は、目標とする状態に到達するまでの段階的な処置計画を示すクリニカルパスが複数格納されたデータベースと、クリニカルパスのそれぞれに含まれる処置及び各処置の担当者に関する情報に基づいて、担当者毎のスケジュールデータを生成するスケジュールデータ生成部と、クリニカルパスを変更する変更要求を受け付ける変更要求受付部と、変更要求の受け付けに伴って作動され、変更の内容をスケジュールデータに照合し、変更が可能か否かを判定する変更可否判定部と、変更が可能と判定された場合に、変更を承認可能な変更承認権限を有するユーザーの端末に対して変更の承認を求める変更承認要求を送信する変更承認要求送信部と、変更承認要求に応答して変更承認権限を有するユーザーの端末から変更を承認する旨の承認通知が送信された際に、変更を行うクリニカルパス変更部と、を備えたことを特徴としている。

変更承認要求を送信するユーザーの端末を変更することによって、変更承認権限を委譲する変更承認権限委譲部を設けてもよい。

スケジュールデータに基づいて、承認が可能であるか否かを判定する承認可否判定部を備え、変更承認権限委譲部は、変更承認権限を有するユーザーが承認を不可能であると判定された場合に、承認が可能なユーザーに変更承認権限を委譲するものでもよい。

承認可否判定部は、処置の担当者として設定されたユーザーが処置を実行している間は、承認が不可能であると判定するものでもよい。

変更承認権限委譲部は、委譲の期間を設定して委譲を行い、期間の経過後、委譲前に変更承認権限を有していたユーザーに変更承認権限を戻すものでもよい。

クリニカルパス変更部は、承認を受けずに処置を行うことを許容する状態として設定された許容状態中は、承認の有無に関わらず変更を行うものでもよい。

クリニカルパス変更部は、変更の内容が、緊急時の搬送先として設定された搬送先へ患者を搬送して実行する処置の追加である場合に、許容状態中であるとして、承認の有無に関わらず変更を行うものでもよい。

患者の生体情報を監視し、生体情報に基づいて許容状態であるか否かを判定する許容状態判定部を設けてもよい。

変更承認権限を有するユーザーの端末として、変更対象のクリニカルパスで処置が行われる患者の担当医の端末が設定されているものでもよい。

クリニカルパスのそれぞれに含まれる処置及び処置に用いる処置資源を抽出し、処置資源毎の使用状況データを作成する使用状況データ生成部を備え、変更可否判定部は、スケジュールデータと使用状況データとに基づいて、変更が可能か否かを判定するものでもよい。

データベースに格納された各クリニカルパルに含まれる処置のそれぞれに対し、処置の優先度が対応付けされた優先度対応情報を記憶する優先度対応情報記憶部を備え、変更可否判定部は、変更対象のクリニカルパスと他のクリニカルパスとの間で処置が重複するか否かを判定し、重複する場合に、変更対象のクリニカルパスと他のクリニカルパスとの少なくとも一方を変更することによって重複を回避するための変更プランを生成し、変更プランで変更される処置の優先度に基づいて変更対象のクリニカルパスの変更が可能か否かを判定するものでもよい。

変更可否判定部は、変更プランで変更される各処置の優先度の合計値に基づいて変更対象のクリニカルパスの変更が可能か否かを判定するものでもよい。

変更可否判定部は、変更プランとして複数の変更プランを生成するとともに、生成された変更プラン毎に合計値を算出し、合計値が最も低い変更プランへの変更が可能であると判定するものでもよい。

変更可否判定部は、合計値を予め設定された閾値と比較し、合計値が閾値未満の変更プランについてはこの変更プランへの変更が可能であると判定し、合計値が閾値以上の変更プランについてはこの変更プランへの変更が不可能と判定するものでもよい。

優先度は、事前準備の必要な処置の方が事前準備の不必要な処置よりも高く設定されていてもよい。

優先度は、事前準備の期間が長い処置ほど高く設定されていてもよい。

事前準備が必要な処置として、処置前の所定期間に食事制限が科せられる処置が設定されていてもよい。

本発明は、変更承認権限を有するユーザーからの承認を受けたうえでクリニカルパスを変更するようにしたので、安易なクリニカルパスの変更を防止できる。

医療支援システムの構成を示す概略図である。 クリニカルパスのデータ体系を示す説明図である。 クリニカルパスが表示された状態を示す説明図である。 ユーザー情報を示す説明図である。 スケジュールデータを示す説明図である。 アプリケーションサーバの構成を示すブロック図である。 アプリケーションサーバの機能構成図である。 クリニカルパスが変更される流れを示すフローチャートである。 優先度対応情報を示す説明図である。 優先度に基づいて採用する変更プランが決定される流れを示すフローチャートである。

図１において、医療支援システム１０は、目標とする状態に到達するまでの段階的な処置（治療や検査など）計画を示すクリニカルパス２６（図２、図３参照）を用いた医療を支援するものであり、クリニカルパス２６の管理（作成、保管、配信、変更など）を行うクリニカルパス管理装置１２を備えている。

クリニカルパス管理装置１２には、インターネットなどのネットワーク１４を介して医療支援システム１０のユーザーの端末１６が複数接続されている。クリニカルパス管理装置１２は、ネットワーク１４を介して端末１６にＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｒｅｆａｃｅ）などの操作画面を配信し、操作画面を通じて端末１６から入力される操作指示に従ってクリニカルパス２６の管理を行う。

端末１６は、ネットワーク１４への接続機能、キーボードやマウスなどの入力手段や液晶ディスプレイなどの表示手段（または、入力手段と表示手段とを兼ねたタッチパネル型のディスプレイ）を備えた、デスクトップ型のパソコンやノート型のパソコン、タブレット端末、携帯電話やスマートフォンなど周知の電子機器である。これら端末１６は、医療支援システム１０のユーザーによって使用される。医療支援システム１０のユーザーは、患者の治療を担当する担当医や担当医の補佐をする看護士や検査技師などの医療スタッフである。

クリニカルパス管理装置１２は、例えば、医療支援システム１０を運営する運営会社に設置される。クリニカルパス管理装置１２は、後述するアプリケーションプログラム（ＡＰ）３０（図６参照）に従って、操作画面の配信やクリニカルパス２６の管理など各種機能を実行するアプリケーションサーバ１７と、クリニカルパスＤＢ（データベース）１８と、ユーザー情報ＤＢ２０と、スケジュールデータＤＢ２１とから構成され、これらがＬＡＮなどのネットワーク２２を介して接続されている。

図２、図３に示すように、クリニカルパスＤＢ１８には、クリニカルパス２６を新規作成する際のベースとなるテンプレート２４、及び、テンプレート２４に基づいて作成された作成済みのクリニカルパス２６が格納される。なお、図２は、クリニカルパス２６を構成するデータの体系を示し、図３は、クリニカルパス２６を閲覧するためにディスプレイに表示した状態を示している。

クリニカルパス２６は、目標とする状態へ到達するまでの段階的な処置計画を示すものであり、処置対象の患者を識別するための患者識別情報（患者名や患者ＩＤなど）や、クリニカルパス２６全体としての処置内容（タイトル）や、クリニカルパス２６の各段階での処置（イベント）の内容（日程、時刻、場所、使用機材、担当者、到達目標）を示すイベント情報などの各種情報が関連付けされたものである。

また、クリニカルパス２６には、権限情報として、閲覧権限を有するユーザーの識別情報（ユーザーＩＤなど）、及び、変更承認権限を有するユーザーの識別情報が対応付けされている。閲覧権限は、クリニカルパス２６の閲覧が許容される権限である。また、変更承認権限は、クリニカルパス２６の変更（イベントの追加や削除、日程や時刻、場所、使用機材、担当者の変更など）を承認し、変更内容を確定できる権限である。

なお、クリニカルパス２６の生成時に、各ユーザーに付与される初期状態の権限については予め設定されており、クリニカルパス２６の生成時には、予め設定されたユーザーに対して予め設定された権限が自動的に付与される。具体的には、閲覧権限が、クリニカルパスのイベントに関与する医療スタッフ（担当医、看護士、検査技師など）に付与され、変更承認権限が、担当医に付与される。なお、各ユーザーに付与される初期状態の権限については前述した例に限定されず、適宜変更できる。

図４に示すように、ユーザー情報ＤＢ２０には、ユーザーに関するユーザー情報２８が記憶されている。ユーザー情報２８は、ユーザー名、ユーザーＩＤなどユーザーを識別するための識別情報や、ユーザーが所有する端末１６を識別するための端末ＩＤ、ユーザーの連絡先情報（電話番号や電子メールアドレス）、ユーザーのステータス情報（ユーザーの所属する診療科や役職など）が対応付けされたものである。

ユーザー情報２８は、ユーザー毎に区別され、１人分のユーザー情報は、医療支援システム１０の初回利用時に行われるユーザー登録処理において生成され、ユーザー情報ＤＢ２０に記憶（新規登録）される。ユーザー登録処理では、ユーザーに対してユーザー名や連絡先情報、ステータス情報の入力が要求され、ユーザーが自身の端末１６からユーザー名及びステータス情報を入力すると、ユーザーＩＤが割り当てられるとともに、情報の入力元の端末１６の端末ＩＤが取得され、ユーザー名や連絡先情報、ステータス情報とともにユーザーＩＤに対応付けされることによってユーザー情報が生成される。

図５に示すように、スケジュールデータＤＢ２１には、病院資源毎のイベントスケジュールを示すスケジュールデータ２９が記憶されている。病院資源は、医師、看護士、検査技師などの医療スタッフや、病室、手術室などの場所（空間）や、検査装置や手術用の機材などの使用機材である。後述するように、スケジュールデータ２９は、クリニカルパスＤＢ１８に格納された複数のクリニカルパル２６から、共通の病院資源についてのイベントスケジュールを抽出し、病院資源毎に時間軸上に並べることによって生成される。

図６に示すように、アプリケーションサーバ１７は、パーソナルコンピュータやワークステーションといったコンピュータをベースに、オペレーティングシステムなどの制御プログラムや、コンピュータをアプリケーションサーバ１７として機能させるためのＡＰ３０をインストールして構成される。

アプリケーションサーバ１７は、ストレージデバイス３２、メモリ３４、ＣＰＵ３６、通信Ｉ／Ｆ３８を備え、こられがデータバス４０を介して接続されている。ストレージデバイス３２は、例えば、ハードディスクドライブであり、アプリケーションサーバ１７の本体に内蔵された内部ストレージである。ストレージデバイス３２は、制御プログラムや、アプリケーションサーバ用ソフトウエアなどのＡＰ３０、並びに、ＡＰ３０の実行時に表示される画像やメッセージ、並びに、各種操作画面を表示するための表示用データ４２などが格納される。

メモリ３４は、ＣＰＵ３６が処理を実行するためのワークメモリである。ＣＰＵ３６は、ストレージデバイス３２に格納された制御プログラムをメモリ３４へロードして、プログラムに従った処理を実行することにより、コンピュータの各部を統括的に制御する。通信Ｉ／Ｆ３８は、ネットワーク１４、２２と通信するためのインタフェースを備えており、アプリケーションサーバ１７は、通信Ｉ／Ｆ３８を介し、ネットワーク１４、２２を経由してクリニカルパスＤＢ１８、ユーザー情報ＤＢ２０、並びに端末１６と通信する。

ＡＰ３０は、各種機能をコンピュータに実行させるためのプログラムである。ＣＰＵ３６は、ストレージデバイス３２に格納されたＡＰ３０をメモリ３４へロードして、プログラムに従った処理を実行することにより、コンピュータの各部を統括的に制御する。

図７に示すように、ＡＰ３０が起動すると、ＣＰＵ３６は、メモリ３４と協働して、スケジュールデータ生成部５０、クリニカルパス生成部５２、クリニカルパス配信部５４、クリニカルパス変更部（変更要求受付部、変更可否判定部、変更承認要求送信部）５６、変更承認権限委譲部５８として機能する。

スケジュールデータ生成部５０は、クリニカルパスＤＢ１８に記憶されているクリニカルパス２６から、スケジュールデータ２９を生成する。前述のように、スケジュールデータ２９は、病院資源毎のイベントスケジュールを示すものである。クリニカルパス２６には、それぞれのクリニカルパス２６で利用する病院資源のイベントスケジュールが含まれている。スケジュールデータ生成部５０は、クリニカルパスＤＢ１８に格納された複数のクリニカルパス２６から、共通の病院資源についてのイベントスケジュールを抽出し、病院資源毎に時間軸上に並べることによって、スケジュールデータ２９を生成する。また、スケジュールデータ生成部５０は、クリニカルパス２６の生成や変更が行われる毎に、同様の手順でスケジュールデータ２９の更新を行う。

クリニカルパス生成部５２は、クリニカルパスを生成するための操作画面であるクリニカルパス生成画面をユーザーの端末１６に配信し、クリニカルパス生成画面を通じてなされたユーザーからの指示に従って、新たなクリニカルパスを生成する。ユーザーは、クリニカルパス生成画面に従って、クリニカルパスＤＢ１８に格納されているクリニカルパス２６のテンプレート２４の中からいずれか選択した後、選択したテンプレート２４にイベント情報を入力する。

ユーザーが選択したテンプレート２４及び入力したイベント情報は、クリニカルパス作成要求として、クリニカルパス生成部５２に入力される。クリニカルパス生成部５２は、このクリニカルパス作成要求を受け付け、クリニカルパス作成要求に基づくクリニカルパス（以下、作成予定のクリニカルパス）が作成可能か否かを判定する。

この判定は、作成予定のクリニカルパスをスケジュールデータ２９に照合し、作成予定のクリニカルパスと既に作成済みの他のクリニカルパス２６とで利用する病院資源が重複しているか否かを調べることによって行われる。そして、クリニカルパス生成部５２は、病院資源が重複している場合、作成予定のクリニカルパスの作成が不可能と判定し、病院資源が重複していない場合は、作成予定のクリニカルパスの作成が可能と判定する。

クリニカルパス生成部５２は、クリニカルパスの作成が不可能と判定された場合は、クリニカルパス生成画面を通じてユーザーにその旨を伝える。他方、クリニカルパスの作成が可能と判定された場合、クリニカルパス生成部５２は、作成予定のクリニカルパスを新たなクリニカルパスとしてクリニカルパスＤＢ１８に記憶する。これにより、新たなクリニカルパス２６の作成が完了する。

クリニカルパス配信部５４は、閲覧を希望するクリニカルパス２６を選択させるための操作画面であるクリニカルパス選択画面をユーザーの端末１６に配信する。ユーザーは、クリニカルパス選択画面に従って、クリニカルパスＤＢ１８に格納されているクリニカルパス２６の中から閲覧を希望するクリニカルパス２６を選択する。ユーザーがクリニカルパス２６を選択すると、選択されたクリニカルパス２６の閲覧要求がクリニカルパス配信部５４に入力される。クリニカルパス配信部５４は、閲覧要求を受け付けると、閲覧要求されたクリニカルパス２６の権限情報を参照し、ユーザーが閲覧権限を有しているかを判定し、ユーザーが閲覧権限を有している場合に、閲覧要求されたクリニカルパス２６をユーザーの端末１６に配信する。

クリニカルパス変更部５６は、クリニカルパスの変更を行うための操作画面であるクリニカルパス変更画面をユーザーの端末１６に配信し、クリニカルパス変更画面を通じてなされたユーザーからの指示に従って、既存のクリニカルパスの変更を行う。ユーザーは、クリニカルパス変更画面に従って、クリニカルパスＤＢ１８に格納されているクリニカルパス２６の中からいずれか選択した後、選択したクリニカルパス２６に新たなイベント情報の入力や既存のイベント情報の削除や変更を指示する旨の情報を入力する。

入力された情報は、クリニカルパス変更要求として、クリニカルパス変更部５６に入力される。クリニカルパス変更部５６は、このクリニカルパス変更要求を受け付け、クリニカルパス変更要求に基づく変更が可能か否かを判定する。

この判定は、変更要求の内容をスケジュールデータ２９に照合し、変更を行った際に他のクリニカルパス２６とで利用する病院資源が重複するか否かを調べることによって行われる。そして、クリニカルパス変更部５６は、病院資源が重複している場合、変更が不可能と判定し、病院資源が重複していない場合は、変更が可能と判定する。

クリニカルパス変更部５６は、変更が不可能と判定された場合は、クリニカルパス変更画面を通じてユーザーにその旨を伝える。他方、変更が可能と判定された場合、クリニカルパス生成部５２は、変更対象のクリニカルパス２６及びユーザー情報２８を参照し、変更対象のクリニカルパス２６の変更承認権限を有するユーザーの端末１６に対して、変更の承認を求める変更承認要求を、例えば、電子メールなどで送信する。

そして、クリニカルパス変更部５６は、変更承認要求に応答して変更を承認する旨の変更承認通知が変更承認権限を有するユーザーの端末１６から送信されると、クリニカルパス変更要求に従って変更予定のクリニカルパスの内容を変更することによってクリニカルパスＤＢ１８を更新する。これにより、クリニカルパス２６の変更が完了する。

なお、変更承認権限を有するユーザーの端末１６に、クリニカルパスの変更を求める変更承認要求とともに変更前後のクリニカルパスを比較した比較データを送信してもよい。さらに変更承認要求を電子メールで送信する例で説明をしたが、承認の可否を選択するための操作画面を配信し操作画面を通じて承認の可否を入力させてもよい。

変更承認権限委譲部５８は、変更承認権限の委譲を行うために設けられており、クリニカルパス２６の権限情報の書き換えを行うことによって、変更承認権限の委譲を行う。具体的には、変更承認権限を有するユーザーの識別情報としてクリニカルパス２６に対応付けされた識別情報を、変更承認権限を委譲する移譲先のユーザーの識別情報へと書き換える（この書き換えにより、結果として変更承認要求の送信先も変更される）。

変更承認権限委譲部５８は、前述した変更承認要求の送信に先立って作動され、変更承認権限を有するユーザーが、変更の承認を可能か否かを判定する。この判定において、変更承認権限委譲部５８は、スケジュールデータ２９から変更承認権限を有するユーザーのスケジュールを参照し、変更承認権限を有するユーザーが、いずれの処理も実行していない場合、変更の承認が可能と判定し、いずれかの処置を実行中である場合、変更の承認が不可能と判定する。そして、変更承認権限委譲部５８は、変更承認権限を有するユーザーが、変更の承認が可能と判定された場合、変更承認権限の委譲を行わず、変更の承認が不可能と判定された場合、変更承認権限の委譲を行うと決定する。

変更承認権限の委譲を行うことが決定されると、変更承認権限委譲部５８は、変更承認権限をいずれのユーザーに委譲するかを決定する。この決定において、変更承認権限委譲部５８は、ユーザー情報２８及びスケジュールデータ２９を参照し、変更承認権限の委譲元のユーザーと同じ診療科に所属する医師の中から、変更の承認が可能な（すなわち、いずれの処理も実行していない）医師を、変更承認権限の移譲先のユーザーとして決定する。そして、変更承認権限委譲部５８は、クリニカルパス２６に対応付けされた識別情報（変更承認権限を有するユーザーの識別情報）を、移譲先のユーザーの識別情報に書き換える。これにより、変更承認権限の委譲が完了する。なお、変更承認要求は、変更承認権限の委譲が完了した後に送信される。すなわち、変更承認権限の委譲が行われた場合は委譲先のユーザーに対して変更承認要求が送信される。

以下上記構成による本発明の作用について図８に示すフローチャートをもとに説明を行う。図８に示すように、クリニカルパス管理装置１２では、クリニカルパス２６の内容を変更する変更要求を受け付けると、スケジュールデータ２９に基づき、この変更要求に基づく変更が可能か否かを判定する。

変更が不可能な場合は、クリニカルパスは変更されず、処理が終了する。他方、変更が可能な場合は、スケジュールデータ２９に基づき、変更承認権限を有するユーザーが変更の承認を可能な状態にあるか否かを判定する。

承認が可能な場合は、変更承認権限を有するユーザーの端末１６に対して変更の承認を要求する変更承認要求を送信する。他方、承認が不可能な場合は、承認が可能なユーザーに変更承認権限を委譲した後、このユーザーの端末１６に対して変更承認要求を送信する。そして、クリニカルパス管理装置１２は、変更承認権限を有するユーザーにより変更が承認されると、クリニカルパス２６の内容を変更する。

このように、クリニカルパス管理装置１２では、変更承認権限を有するユーザーの承認が得られないとクリニカルパスの変更ができないようにしたので、クリニカルパルが安易に変更されてしまうといった問題を防止できる。

さらに、クリニカルパス管理装置１２では、変更承認権限を有するユーザーが変更の承認が不可能な場合に、変更の承認が可能なユーザーに変更承認権限を委譲し、変更承認権限の移譲先のユーザーに対して変更承認要求を送信する。このため、変更の承認が行われずに、クリニカルパスの変更ができないなどの問題を防止できる。

なお、本発明の細部の構成については上記実施形態に限定されず、適宜変更できる。例えば、上記実施形態では、クリニカルパス管理装置を医療支援システムの運営会社に設置する例で説明をしたが、クリニカルパス管理装置を医療支援システムのユーザーが所属する医療機関に設置してもよい。

また、上記実施形態では、変更承認権限を有するユーザーが変更の承認を行えないと判定された場合、同じ診療科の医師に変更承認権限が委譲される例で説明をしたが、変更承認権限の移譲先や、移譲先を決定する手法については適宜変更できる。例えば、変更承認権限を他の診療科の医師に委譲してもよい。また、変更承認権限を有するユーザーと、移譲先のユーザーとの対応関係を規定したルックアップテーブルを設け、このルックアップテーブルに従って移譲先を決定してもよい。さらに、変更承認権限の移譲先として決定されたユーザーが必ずしも承認可能な状態にあるとは限らない（変更承認権限を有するユーザーと移譲先のユーザーとの両方とも承認不可能な状態にある場合もある）ので、複数のユーザーに対して委譲の優先度を設定し、優先度の高いユーザーから順に優先的に委譲を行うようにしてもよい。

さらに、変更承認権限の委譲先をユーザーが決定してもよい。この場合、変更承認権限を有するユーザーが、自身の端末からクリニカルパス管理装置にアクセスし、変更承認権限を委譲するユーザーを指定し、このユーザーに自身の所有する変更承認権限を委譲するといったことが考えられる。また、変更承認要求を送信するきっかけとなったユーザー、すなわち、クリニカルパスを変更しようとしたユーザーが、自身の端末で変更承認権限を委譲するユーザーを指定し、指定したユーザーに変更承認権限を委譲してもよい。ただし、変更承認権限を有していないユーザーに、変更承認権限の移譲先を決定できる権限を与えてしまうと、混乱の原因となってしまう。このため、変更承認権限を有していないユーザーに変更承認権限の移譲先を指定させる場合、例えば、変更承認権限を有するユーザーと同じ診療科内の医師の中から変更承認権限の委譲先を指定させるなど、変更承認権限の委譲先として指定可能なユーザーの範囲を予め制限しておき、このように制限された範囲の中で変更承認権限を委譲するユーザーを指定させることが好ましい。

さらに、変更承認権限を期限付きで委譲するといったことも考えられる。この場合、変更承認権限を有するユーザーが変更の承認を行えない期間についてのみ他のユーザーに対して変更承認権限を委譲し、前記期間が経過した後に元のユーザーに対して変更承認権限を戻すといったことが考えられる。もちろん、変更承認権限を委譲する期間については、前述した例に限定されず、例えば、１日または１週間といったように予め設定された期間としてもよいし、ユーザーが任意の期間を設定できるようにしてもよい。

また、上述のように、期限付きで変更承認権限を委譲する場合と、無期限で変更承認権限を委譲する場合とを設け、これらが自動的に切り替わるようにしてもよい。この場合、変更承認権限の移譲先に応じて、期限付きで変更承認権限を委譲する場合と無期限で変更承認権限を委譲する場合とを切り替えるといったことが考えられる。具体的には、変更承認権限の委譲先が同じ診療科内の医療スタッフである場合は、期限付きで変更承認権限を委譲し、変更承認権限の移譲先が異なる診療科の医療スタッフである場合は、無期限で変更承認権限を委譲するといったことが考えられる。もちろん、変更承認権限の移譲先とは異なる条件を満たしているか否かに応じて、期限付きで変更承認権限を委譲する場合と無期限で変更承認権限を委譲する場合とを切り替えてもよい。

さらに、患者の容態が急変したなど緊急の場合についても、変更承認権限を有するユーザーからの承認がないとクリニカルパスを変更できない構成であると、緊急時の処置が遅れてしまうといった問題がある。このため、緊急の場合については、承認無しでクリニカルパスの変更を可能とすることが好ましい。緊急の場合か否かの判断は、例えば、生体モニターにより血圧や脈拍数、呼吸などを監視し、異常が検知された場合に承認無しでクリニカルパスの変更を許容する状態へと移行するといったことが考えられる。また、クリニカルパスの変更内容が、集中治療室や救命救急室、手術室などでの処置など緊急性の高い処置として予め設定された処置の追加である場合に承認無しでクリニカルパスの変更を許容する状態へと移行させてもよい。もちろん、緊急時以外の場合に承認なしでクリニカルパスの変更を許容する状態へと移行させてもよい、また、ユーザーからの指示（自身の端末の操作）で、承認なしでクリニカルパスの変更を許容する状態へと移行させてもよい。

なお、上述のように承認無しでクリニカルパスの変更を許容する状態は、所定期間が経過した後に解除されることが好ましい。また、承認無しでクリニカルパスの変更を許容する状態中に行われた変更については、変更後に変更承認権限を有するユーザーに承認を求めることが好ましい。

また、上記実施形態では、変更承認権限を有するユーザーが１つのクリニカルパスに対して１人である例で説明をしたが、１つのクリニカルパスについて複数のユーザーが変更承認権限を有するユーザーとして設定され、これら全員の承認が得られた場合に、クリニカルパスが変更されるようにしてもよい。また、１つのクリニカルパスについて複数のユーザーが変更承認権限を有するユーザーとして設定され、これらのうち１人または予め設定された人数の承認が得られた場合に、クリニカルパスが変更されるようにしてもよい。もちろん、１人のユーザーが複数のクリニカルパスの変更承認権を有していてもよい。

さらに、上記実施形態では、変更要求通りに変更対象のクリニカルパスを変更すると他のクリニカルパスとの間で病院資源が重複してしまう場合、変更が不可と判定されていずれのクリニカルパスの変更も行われない例で説明をしたが、本発明はこれに限定されるものではない。変更対象のクリニカルパスを変更する際に、この変更に伴って他のクリニカルパスを変更することで病院資源の重複が無くなり、変更対象のクリニカルパスを変更要求通りに変更できる場合もある。このため、他のクリニカルパスを変更する変更プランも考慮して、変更が可能か否かを判定してもよい。

また、上述したように、他のクリニカルパスの変更を行うだけでなく、変更対象のクリニカルパスについても、変更要求された内容に対して変更を加えること、例えば、変更要求された内容が処置を２０時間早めるものである場合に処置を１８時間早める内容に変更することによって病院資源の重複が無くなり、変更要求通りではないものの変更を行わないよりは変更要求に近い内容に変更できる場合もある。このため、変更要求された内容に対して変更を加える変更プランも考慮して、変更が可能か否かを判定してもよい。もちろん、このように変更要求された内容を変更する変更プランと、前述したように他のクリニカルパスを変更する変更プランとの両方を考慮して、変更が可能か否かを判定してもよい。

以下、変更要求された内容に変更を加える変更プランと、他のクリニカルパスを変更する変更プランとの両方を考慮して、変更が可能か否かを判定する具体的な実施例について図９、図１０を用いて説明を行う。なお、以下の説明では、上述した実施形態と同様の部材については説明を省略している。

本実施例の医療支援システムでは、クリニカルパス管理装置に、優先度対応情報が記憶されている。図９に示すように優先度対応情報１００は、クリニカルパスＤＢに記憶された各クリニカルパスに含まれる各処置のそれぞれについて、各処置の優先度を示す数値が対応付けされたものであり、図９の例では、処置Ａには優先度５、処置Ｂには優先度４、処置Ｃには優先度３、処置Ｄには優先度２、処置Ｅには優先度１が対応付けされている。

なお、各処置に対応付けする優先度は自由に設定できるが、後述するように、優先度が高い処置ほどスケジュールに組み込まれた後に変更され難くなるので、変更の手間や影響が大きい処置ほど優先度を高く設定することが好ましい。具体的には、医師の中でも特別な資格や経験を有する者しか担当できない処置や、多くのスタッフが関与する処置や、設置数の少ない特殊な装置を用いて行う処置の優先度を高く設定することが好ましい。また、処置の中には、処置に用いる装置の起動や準備が必要であったり、処置前の所定期間に食事制限を科す必要があるなど、事前準備が必要なものもある。このように、事前準備の必要が処置については、事前準備に要する手間や期間が長い処置ほど優先度を高く設定することが好ましい。

また、優先度対応情報１００は、アプリケーションサーバ、クリニカルパスＤＢ、ユーザー情報ＤＢ、スケジュールデータＤＢなど、クリニカルパス管理装置の既存の構成部のいずれかに記憶させてもよい、すなわち、クリニカルパス管理装置の既存の構成部のいずれかを優先度対応情報記憶部として機能させてもよい。また、クリニカルパス管理装置に、優先度対応情報１００を記憶するための専用のデータベースを設け、このデータベースを優先度対応情報記憶部として機能させてもよい。

そして、本実施例では、クリニカルパス変更部が、前述した優先度対応情報１００を用いて、変更要求に基づく変更が可能な変更プランを判定する。具体的には、図１０に示すように、クリニカルパス変更部は、変更要求を受け付けると、この変更要求に従って変更を行った際に他のクリニカルパスとの間でイベント（用いる病院資源）が重複するか否かを調べ、イベントが重複しない場合、変更要求通りの変更プラン、すなわち、変更要求通りに変更対象のクリニカルパスのみを変更する変更プランを、変更可能な変更プランと判定（採用する変更プランとして決定）する。

一方、クリニカルパス変更部は、イベントが重複する場合、重複が発生しないように変更対象のクリニカルパスと他のクリニカルパスとの少なくとも一方を変更する複数種類の変更プランを生成する。変更プランの生成では、例えば、下記１〜４のような方法で変更プランが生成される。

［方法１］
重複しているイベントで用いる病院資源の種類は変更せずに重複しているイベントの開始時間を変更することによって変更プランを生成する方法。
［方法２］
重複しているイベントの開始時間は変更せずに重複しているイベントで用いる病院資源の種類を変更（検査機器や検査担当者などを変更）することによって変更プランを生成する方法。
［方法３］
重複しているイベントで用いる病院資源及び開始時間の両方を変更することによって変更プランを生成する方法。
［方法４］
重複しているイベント自体の内容を変更（重要ではないイベントの廃止や、検査項目数を減らすなどのイベントの簡略化、同様の機能を有する別イベントへの置き換えなど）することによって変更プランを生成する方法。

なお、上述した各方法のそれぞれで生成する変更プランは１つに限定されるものでない。例えば、上述した方法１において、重複するイベントの開始時間を１時間ずらした変更プランと、２時間ずらした変更プランの２種類の変更プランを生成してもよい。また、上述した方法を組み合わせて用いることによって変更プランを生成してもよい。さらに、変更プランの生成方法によって本発明は限定されるものではないので、上述した方法以外の方法を用いて変更プランを生成してもよい。もちろん、生成する変更プランの数も自由に設定できる。

また、変更対象のクリニカルパスと他のクリニカルパスとのイベントの重複を回避するために、２つのクリニカルパスの一方または両方を変更すると、さらに他のクリニカルパスとイベントが重複する場合もある。クリニカルパス変更部が生成する変更プランの中には、このように１つのクリニカルパスの変更に伴って連鎖的に発生するイベントの重複の全てを回避するように３つ以上のクリニカルパスを変更するものも含まれる。

上述のように複数の変更プランを生成した後、クリニカルパス変更部は、優先度対応情報１００を参照し、それぞれの変更プラン毎に、各変更プランで変更される処置の優先度を合計した変更プラン毎の優先度の合計値を算出する。そして、クリニカルパス変更部は、変更プラン毎の優先度の合計値が最も低い変更プランを、変更可能な変更プランと判定（採用する変更プランとして決定）する。

そして、採用する変更プランが決定されると、上記実施形態と同様に、この変更プランへ変更することの承認を経た後、この変更プランへと変更される。

このように、本実施例によれば、変更対象のクリニカルパスを変更する際に、他のクリニカルパスを変更する変更プランも考慮するようにしたので、他のクリニカルパスを変更する変更プランを考慮せずに変更要求通りに変更できないときは変更を行わない場合と比較して、変更対象のクリニカルパスを変更要求通りに変更できる可能性を高くできる。また、本実施例によれば、変更要求通りに変更対象のクリニカルパスを変更できない場合であっても、変更要求の内容を変更する変更プランを考慮するようにしたので、変更要求通りに変更対象のクリニカルパスを変更できないときは変更を行わない場合と比較して、変更要求に近い変更プランへ変更できる可能性を高くできる。

また、本実施例のように、変更要求通りまたは変更要求に近づけるために他のクリニカルパスを変更する場合、変更要求通りまたは変更要求に近づけることができるといったメリットを得られる反面、他のクリニカルパスを変更することによるデメリットも発生するが、本実施例では、変更する処置の優先度を考慮し、優先度の高い処置は変更され難く、優先度の低い処置が優先的に変更されるようにしている。このため、本実施例によれば、上述したメリットを生かし、デメリットを抑えることができる。

なお、本実施例では、各変更プランで変更される処置の優先度を合計した変更プラン毎の優先度の合計値を算出し、合計値が最も低い変更プランを採用する例で説明をしたが、この合計値が所定の閾値を越えた場合には、いずれの変更プランも採用しない、すなわち変更が不可能と判定してもよい。こうすることで、変更要求に近づけるために、強引な変更が行われてしまうといった問題を防止できる。すなわち、変更要求に近づけるために、変更対象のクリニカルパスだけでなく、他のクリニカルパスの変更や、さらに、他のクリニカルパスの変更に伴って連鎖的に発生する重複の全てを回避するように複数のクリニカルパスが変更される場合、変更されるクリニカルパスの数などによっては、変更要求に近づくメリットよりも、複数のクリニカルパスが変更されることによるデメリットの方が大きくなってしまうといった問題があるが、合計値が所定の閾値を越えた場合には、いずれの変更プランも採用しない（すなわち、変更を行わない）ようにすることで、このような問題を防止できる。

また、本実施例では、複数種類の変更プランを生成する例で説明をしたが、１つの変更プランのみを生成し、この変更プランにより変更される処置の優先度の合計値を算出し、合計値が所定の閾値未満である場合に、この変更プランへの変更が可能と判定してもよい。

１０ 医療支援システム
１２ クリニカルパス管理装置
１７ アプリケーションサーバ
１８ クリニカルパスＤＢ
２０ ユーザー情報ＤＢ
２１ スケジュールデータＤＢ
２６ クリニカルパス
２８ ユーザー情報
２９ スケジュールデータ
３０ ＡＰ
３２ ストレージデバイス
３４ メモリ
３６ ＣＰＵ
５０ スケジュールデータ生成部
５２ クリニカルパス生成部
５４ クリニカルパス配信部
５６ クリニカルパス変更部（変更要求受付部、変更可否判定部、変更承認要求送信部）
５８ 変更承認権限委譲部

Claims (16)

1. 目標とする状態に到達するまでの段階的な処置計画を示すクリニカルパスが複数格納されたデータベースと、
   前記クリニカルパスのそれぞれに含まれる処置及び各処置の担当者に関する情報に基づいて、担当者毎のスケジュールデータを生成するスケジュールデータ生成部と、
   前記クリニカルパスを変更する変更要求を受け付ける変更要求受付部と、
   前記変更要求の受け付けに伴って作動され、前記変更の内容を前記スケジュールデータに照合し、前記変更が可能か否かを判定する変更可否判定部と、
   前記変更が可能と判定された場合に、前記変更を承認可能な変更承認権限を有するユーザーの端末に対して前記変更の承認を求める変更承認要求を送信する変更承認要求送信部と、
   前記変更承認要求に応答して前記変更承認権限を有するユーザーの端末から前記変更を承認する旨の承認通知が送信された際に、前記変更を行うクリニカルパス変更部と、
   前記データベースに格納された各クリニカルパルに含まれる処置のそれぞれに対し、処置の優先度が対応付けされた優先度対応情報を記憶する優先度対応情報記憶部と、
   を備え、
   前記変更可否判定部は、
   変更対象のクリニカルパスと他のクリニカルパスとの間で処置が重複するか否かを判定し、重複する場合に、前記変更対象のクリニカルパスと前記他のクリニカルパスとの少なくとも一方を変更することによって前記重複を回避するための変更プランを生成し、
   前記変更プランで変更される処置の優先度に基づいて前記変更対象のクリニカルパスの変更が可能か否かを判定することを特徴とするクリニカルパス管理装置。
2. 前記変更承認要求を送信するユーザーの端末を変更することによって、前記変更承認権限を委譲する変更承認権限委譲部を備えたことを特徴とする請求項１記載のクリニカルパス管理装置。
3. 前記スケジュールデータに基づいて、前記承認が可能であるか否かを判定する承認可否判定部を備え、
   前記変更承認権限委譲部は、前記変更承認権限を有するユーザーが前記承認を不可能であると判定された場合に、前記承認が可能なユーザーに前記変更承認権限を委譲することを特徴とする請求項２記載のクリニカルパス管理装置。
4. 前記承認可否判定部は、前記処置の担当者として設定されたユーザーが前記処置を実行している間は、前記承認が不可能であると判定することを特徴とする請求項３記載のクリニカルパス管理装置。
5. 前記変更承認権限委譲部は、前記委譲の期間を設定して前記委譲を行い、前記期間の経過後、前記委譲前に前記変更承認権限を有していたユーザーに前記変更承認権限を戻すことを特徴とする請求項２〜４いずれか１項記載のクリニカルパス管理装置。
6. 前記クリニカルパス変更部は、前記承認を受けずに前記処置を行うことを許容する状態として設定された許容状態中は、前記承認の有無に関わらず前記変更を行うことを特徴とする請求項１〜５いずれか１項記載のクリニカルパス管理装置。
7. 前記クリニカルパス変更部は、前記変更の内容が、緊急時の搬送先として設定された搬送先へ患者を搬送して実行する処置の追加である場合に、前記許容状態中であるとして、前記承認の有無に関わらず前記変更を行うことを特徴とする請求項６記載のクリニカルパス管理装置。
8. 患者の生体情報を監視し、前記生体情報に基づいて前記許容状態であるか否かを判定する許容状態判定部を備えたことを特徴とする請求項６または７記載のクリニカルパス管理装置。
9. 前記変更承認権限を有するユーザーの端末として、前記変更対象のクリニカルパスで処置が行われる患者の担当医の端末が設定されていることを特徴とする請求項１〜８いずれか１項記載のクリニカルパス管理装置。
10. 前記クリニカルパスのそれぞれに含まれる処置及び前記処置に用いる処置資源を抽出し、前記処置資源毎の使用状況データを作成する使用状況データ生成部を備え、
    前記変更可否判定部は、前記スケジュールデータと前記使用状況データとに基づいて、前記変更が可能か否かを判定することを特徴とする請求項１〜９いずれか１項記載のクリニカルパス管理装置。
11. 前記変更可否判定部は、前記変更プランで変更される各処置の優先度の合計値に基づいて前記変更対象のクリニカルパスの変更が可能か否かを判定することを特徴とする請求項１〜１０いずれか１項記載のクリニカルパス管理装置。
12. 前記変更可否判定部は、前記変更プランとして複数の変更プランを生成するとともに、生成された変更プラン毎に前記合計値を算出し、前記合計値が最も低い変更プランへの変更が可能であると判定することを特徴とする請求項１１記載のクリニカルパス管理装置。
13. 前記変更可否判定部は、前記合計値を予め設定された閾値と比較し、前記合計値が前記閾値未満の変更プランについてはこの変更プランへの変更が可能であると判定し、前記合計値が前記閾値以上の変更プランについてはこの変更プランへの変更が不可能と判定することを特徴とする請求項１１または１２記載のクリニカルパス管理装置。
14. 前記優先度は、事前準備の必要な処置の方が事前準備の不必要な処置よりも高く設定されていることを特徴とする請求項１〜１３いずれか１項記載のクリニカルパス管理装置。
15. 前記優先度は、前記事前準備の期間が長い処置ほど高く設定されていることを特徴とする請求項１４記載のクリニカルパス管理装置。
16. 前記事前準備が必要な処置として、処置前の所定期間に食事制限が科せられる処置が設定されていることを特徴とする請求項１４または１５記載のクリニカルパス管理装置。
    

Images