(57)【要約】【課題】  本発明は、各サブシステムに対するオーダを一元管理することができる病院情報システムを提供する。【解決手段】  患者への医療行為に関する予定を示す医療行為情報の複数から構成されるクリニカルパス情報を管理する病院情報システムにおいて、クリニカルパス情報を取得し、この取得したクリニカルパス情報をオーダ情報に変換し、この変換したオーダ情報を関連のある医療部門へ送信することにより、上記の課題の解決を図る。【選択図】      図１
2005157560.tif 000002
【特許請求の範囲】
【請求項１】
患者への医療行為に関する予定を示す医療行為情報の複数から構成されるクリニカルパス情報を管理する病院情報システムにおいて、
前記クリニカルパス情報を取得する取得手段と、
前記クリニカルパス情報を変換して、前記医療行為情報に係る前記医療行為に関連する医療部門へ該医療行為情報を通知するための情報である医療行為通知情報とする変換手段と、
前記医療行為通知情報を前記医療部門へ送信する送信手段と、
を備えることを特徴とする病院情報システム。
【請求項２】
前記変換手段は、前記取得手段により取得した前記クリニカルパス情報から前記医療行為情報を抽出し、該抽出した医療行為情報に、前記医療部門に関する情報を付加することを特徴とする請求項１に記載の病院情報システム。
【請求項３】
患者への医療行為に関する予定を示す医療行為情報の複数から構成されるクリニカルパス情報を管理する病院情報システムにおいて、
前記クリニカルパス情報を取得する手段と、
前記クリニカルパス情報を構成している前記医療行為情報に示されている前記医療行為の予定が実施可能であるか否かを判定する判定手段と、
前記判定手段による判定結果に基づいて、前記クリニカルパス情報を構成している前記医療行為情報の変更を促す通知をする判定結果変更通知手段と、
を備えることを特徴とする病院情報システム。
【請求項４】
前記判定手段は、前記取得手段により取得した前記クリニカルパス情報を構成している前記医療行為情報に含まれる医療行為の予定日時と、該医療行為に関連する医療部門の該医療行為の実施可能日時または実施不可能日時とを照合する
ことを特徴とする請求項３に記載の病院情報システム。
【請求項５】
患者への医療行為に関する予定を示す医療行為情報の複数から構成されるクリニカルパス情報を管理する病院情報システムにおいて、
前記クリニカルパス情報を取得する取得手段と、
前記医療行為情報間を関連付けた関連付け情報を記憶する記憶手段と、
前記取得手段により取得した前記クリニカルパス情報のうち所定の前記医療行為情報についての変更指示情報を受けた場合、該所定の医療行為情報と関連のある前記医療行為情報を前記関連付け情報から検索する検索手段と、
前記検索手段による検索結果に基づいて、前記クリニカルパス情報を構成している前記医療行為情報の変更を促す通知をする検索結果変更通知手段と、
を備えることを特徴とする病院情報システム。
【請求項６】
前記関連付け情報には、関連付けられた前記医療行為情報で示される前記予定日時の間隔時間を示す情報が含まれ、
検索結果変更通知手段は、前記検索手段により検索された医療行為情報に対応する前記間隔時間に基づいて生成される前記医療行為情報の変更例を含めた前記通知を行う
ことを特徴とする請求項５に記載の病院情報システム。
【請求項７】
前記病院情報システムは、さらに、
前記検索結果変更通知手段による通知後に変更された前記医療行為情報に係る前記クリニカルパス情報を取得し、該クリニカルパス情報を変換して、前記医療行為情報に係る前記医療行為に関連する医療部門へ該医療行為情報を通知するための情報である医療行為通知情報とする変換手段と、
前記医療行為通知情報を前記医療部門へ送信する送信手段と、
を備えることを特徴とする請求項６に記載の病院情報システム。
【請求項８】
前記変換手段は、前記取得手段により取得した前記クリニカルパス情報から前記医療行為情報を抽出し、該抽出した医療行為情報に、前記医療部門に関する情報を付加することを特徴とする請求項７に記載の病院情報システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療現場において患者情報を有効活用するためのシステムに関する。
【背景技術】
【０００２】
近年、病院において、例えば、内視鏡検査システムや放射線検査システム、看護システム等の様々な部門システム（以下、サブシステムともいう。このようなサブシステムから構成されるシステムを「病院情報システム」という）でＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）化が進んでおり、各サブシステムでは、検査結果や患者情報がデータ化されて管理されている。
【０００３】
従来、サブスシステム間での患者に対する個々の医療行為の指示情報（以下、オーダという）のやり取りは紙媒体等を用いて行われており、各部門の担当者が当該サブシステムに入力し、このような作業が各サブシステムで重複して行われていた。
また、近年のＩＴ化の推進により、所定の端末で入力した患者のオーダ情報をその医療行為を実施する部門サブシステムに対して送信することは可能であった。
【０００４】
さて、医療分野では現在医療の効率化を図るために、クリニカルパスが導入されている。クリニカルパスとは、各病気に応じた入院・治療スケジュールを標準化したものである。更に、具体的に述べると、ある種の疾患をもつ患者に対する治療・検査・ケア・処置・指導などの内容やタイミング、患者の状態などを時間軸に沿ってまとめたものである。
【０００５】
医療現場では、クリニカルパスを紙に印字し、これに基づいて、各サブシステムではオーダを入力することで、複数のサブシステム間での医療行為を、医療計画として管理していた。
また、クリニカルパスを導入して、医療行為を管理する発明も開示されている（たとえば、特許文献１、特許文献２。）。
【特許文献１】特開２００１−１１８０１４号公報
【特許文献２】特開２００３−１０８６６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところが、患者に対する医療行為は多岐にわたり、関連を持つ複数の医療行為について、それぞれにオーダを出す必要がある。しかしながら、従来の病院情報システムでは、個々の医療行為に対するオーダを個別に入力し、オーダ発行を繰り返す方法を取るため、オーダの入力作業に時間がかかる、また、入力ミスや入力漏れが発生しやすいという問題があった。また、各サブシステム間における患者の情報の整合性をとるに際し、人手によるところが大きく、負担となっていた。
【０００７】
また、従来、病院情報システムなどでオーダを発行する機能において、個々のオーダの変更を行うことは可能であった。しかし、１つのオーダが変更されることによって影響を受けるそれ以後の医療行為に対して、自動的にオーダ変更することはできなかった。例えば、手術の日程がずれることによって、術後に発生する様々な医療行為の日程がずれるといった変更を、各部門サブシステムに伝えることは出来なかった。
【０００８】
上記の課題に鑑み、本発明は、各サブシステムに対するオーダを一元管理することができる病院情報システムを提供する。また、クリニカルパスの医療行為を設定する場合に、予約が可能か否かの確認を行う病院情報システムを提供する。さらに、クリニカルパスに変更があると、その変更により影響を受ける医療行為等の担当部門のサブシステムへ変更情報を送信する病院情報システムを提供する。
【課題を解決するための手段】
【０００９】
上記課題は、特許請求の範囲の請求項１に記載の発明によれば、患者への医療行為に関する予定を示す医療行為情報の複数から構成されるクリニカルパス情報を管理する病院情報システムにおいて、前記クリニカルパス情報を取得する取得手段と、前記クリニカルパス情報を変換して、前記医療行為情報に係る前記医療行為に関連する医療部門へ該医療行為情報を通知するための情報である医療行為通知情報とする変換手段と、前記医療行為通知情報を前記医療部門へ送信する送信手段と、を備えることを特徴とする病院情報システムを提供することによって達成できる。
【００１０】
このように構成することによって、クリニカルパスの一度の入力で、複数の関連部門のサブシステムへオーダ情報を送信することができるので、クリニカルパスの一元管理ができる。
また上記課題は、特許請求の範囲の請求項２に記載の発明によれば、前記変換手段は、前記取得手段により取得した前記クリニカルパス情報から前記医療行為情報を抽出し、該抽出した医療行為情報に、前記医療部門に関する情報を付加することを特徴とする請求項１に記載の病院情報システムを提供することによって達成できる。
【００１１】
このように構成することによって、クリニカルパスに含まれる各医療行為情報を、当該医療行為に関連のある部門のサブシステムへ適切に送信することができる。
また上記課題は、特許請求の範囲の請求項３に記載の発明によれば、患者への医療行為に関する予定を示す医療行為情報の複数から構成されるクリニカルパス情報を管理する病院情報システムにおいて、前記クリニカルパス情報を取得する手段と、前記クリニカルパス情報を構成している前記医療行為情報に示されている前記医療行為の予定が実施可能であるか否かを判定する判定手段と、前記判定手段による判定結果に基づいて、前記クリニカルパス情報を構成している前記医療行為情報の変更を促す通知をする判定結果変更通知手段と、を備えることを特徴とする病院情報システムを提供することによって達成できる。
【００１２】
このように構成することによって、医療行為の設定段階で、予め当該医療行為の予約状況を確認し、予約枠に空きがあれば、予約することができる。
また上記課題は、特許請求の範囲の請求項４に記載の発明によれば、前記判定手段は、前記取得手段により取得した前記クリニカルパス情報を構成している前記医療行為情報に含まれる医療行為の予定日時と、該医療行為に関連する医療部門の該医療行為の実施可能日時または実施不可能日時とを照合することを特徴とする請求項３に記載の病院情報システムを提供することによって達成できる。
【００１３】
このように構成することによって、日時単位で予約枠の確認をすることができる。
また上記課題は、特許請求の範囲の請求項５に記載の発明によれば、患者への医療行為に関する予定を示す医療行為情報の複数から構成されるクリニカルパス情報を管理する病院情報システムにおいて、前記クリニカルパス情報を取得する取得手段と、前記医療行為情報間を関連付けた関連付け情報を記憶する記憶手段と、前記取得手段により取得した前記クリニカルパス情報のうち所定の前記医療行為情報についての変更指示情報を受けた場合、該所定の医療行為情報と関連のある前記医療行為情報を前記関連付け情報から検索する検索手段と、前記検索手段による検索結果に基づいて、前記クリニカルパス情報を構成している前記医療行為情報の変更を促す通知をする検索結果変更通知手段と、を備えることを特徴とする病院情報システムを提供することによって達成できる。
【００１４】
このように構成することによって、クリニカルパス変更に際し一度の入力作業で、複数の関連部門のサブシステムへオーダ情報を送信することができる。
また上記課題は、特許請求の範囲の請求項６に記載の発明によれば、前記関連付け情報には、関連付けられた前記医療行為情報で示される前記予定日時の間隔時間を示す情報が含まれ、検索結果変更通知手段は、前記検索手段により検索された医療行為情報に対応する前記間隔時間に基づいて生成される前記医療行為情報の変更例を含めた前記通知を行う
ことを特徴とする請求項５に記載の病院情報システムを提供することによって達成できる。
【００１５】
このように構成することによって、１つの医療行為情報の変更に伴うそれに関連する医療行為の変更について、どのぐらいの時間（または日数）変更すればよいかを示すことができる。
また上記課題は、特許請求の範囲の請求項７に記載の発明によれば、前記病院情報システムは、さらに、前記検索結果変更通知手段による通知後に変更された前記医療行為情報に係る前記クリニカルパス情報を取得し、該クリニカルパス情報を変換して、前記医療行為情報に係る前記医療行為に関連する医療部門へ該医療行為情報を通知するための情報である医療行為通知情報とする変換手段と、前記医療行為通知情報を前記医療部門へ送信する送信手段と、を備えることを特徴とする請求項６に記載の病院情報システムを提供することによって達成できる。
【００１６】
このように構成することによって、医療行為情報の変更に際し、この変更によって影響を受ける医療行為を検索し、影響を受ける場合には、その旨を通知することができる。
また上記課題は、特許請求の範囲の請求項８に記載の発明によれば、前記変換手段は、前記取得手段により取得した前記クリニカルパス情報から前記医療行為情報を抽出し、該抽出した医療行為情報に、前記医療部門に関する情報を付加することを特徴とする請求項７に記載の病院情報システムを提供することによって達成できる。
【００１７】
このように構成することによって、クリニカルパス変更に際し一度の入力作業で、複数の関連部門のサブシステムへオーダ情報を送信することができる。
【発明の効果】
【００１８】
本発明を用いることにより、患者に対する一連の医療行為を、クリニカルパスに基づいて一元管理することができるようになり、一回の入力によって、オーダの変更を各部門のシステムへ容易に反映させることができる。すなわち、この結果、オーダ入力作業の時間を削減することができる。また、重複した入力作業が発生しないので、オーダの入力ミス、入力漏れが削減される。
【発明を実施するための最良の形態】
【００１９】
図１は、病院情報システムの全体構成を示す。病院情報システム１は、病院情報システム用端末２（２ａ，２ｂ，２ｃ，２ｄ，２ｅ，・・・）、クリニカルパス・データベース・サーバ３、オーダ管理サーバ４、部門サブシステム５（５ａ，５ｂ，５ｃ，５ｄ，５ｅ，・・・）、及びこれらを接続するＬＡＮから構成される。クリニカルパス・データベース・サーバ３、オーダ管理サーバ４のサーバ群は、物理的に統合または分散させることが可能である。
【００２０】
病院情報システム端末２（２ａ，２ｂ，２ｃ，２ｄ，２ｅ，・・・）は、患者のクリニカルパスの計画、表示、オーダの入力、実施内容・結果の表示、患者情報の入力、表示を行うことができる。また、病院情報システム端末２に入力された情報は、クリニカルパス・データベース・サーバ３に送信される。
【００２１】
クリニカルパス・データベース・サーバ３には、病院情報システム端末２から送信された患者ごとのクリニカルパスの計画および実施内容・結果が保存される。また、病名・疾患ごとのクリニカルパスの雛型データが登録されており、患者ごとの入院・治療計画を立てるときの基準データとなる。
【００２２】
クリニカルパスの雛型データは、治療、検査、投薬などの医療行為を組み合わせた予定表として構成され、予定の開始から終了、例えば入院から退院までの間の医療行為が入力される。各医療行為の間には関連性があり、ある治療に対して、次にこの看護行為が必要である、といった繋がりを持っているので、このような関連付けを示すデータも登録されている。また、保存した患者ごとのクリニカルパスの計画および実施内容・結果をオーダ管理サーバ４へ送信する。
【００２３】
オーダ管理サーバ４は、オーダ変換手段４ａとオーダ送信手段４ｂを備えている。オーダ変換手段４ａでは、受信した患者ごとのクリニカルパスより各医療行為情報を抽出し、それをオーダ情報に変換する。オーダ送信手段４ｂでは、オーダ情報をこのオーダに対応する部門サブシステムに送信する。
【００２４】
部門サブシステム５には、例えば、看護システム、手術システム、給食システム、薬剤システム、各検査部門システム等がある。各サブシステム５（５ａ，５ｂ，５ｃ，５ｄ，５ｅ，・・・）は、ＰＣ端末、サーバ、携帯端末等から構成され、各々がＬＡＮにより接続されている。各部門サブシステムでは、オーダ管理サーバ４から送信されたオーダ情報に基づいて医療行為が実施され、その実施した医療行為の実施記録（実施内容、結果  等）が保存される。その後、クリニカルパス・データベース・サーバ３、またはオーダ管理サーバ４にその実施記録の一部（必要な情報）を送信する。
【００２５】
その後、クリニカルパス・データベース・サーバ３は、部門サブシステム５から送信された実施記録を受信し、その実施記録を保存する。
図２は、病院情報システム端末２、クリニカルパス・データベース・サーバ３、オーダ管理サーバ４、または部門サブシステム５の各装置内部の概念構成を示す。同図において、プログラムによる処理や演算を行う制御部（ＣＰＵ）１２と、必要なデータを記憶する記憶部１１と、マウス、キーボード、または携帯端末等の入力装置から命令またはデータ等を入力するためにこれらの装置を接続する入力インターフェース（以下、インターフェースをＩ／Ｆという）１３と、プリンタやディスプレイ等の装置にデータを出力するためにこれらの装置を接続する出力Ｉ／Ｆ１４と、ＬＡＮ等のネットワークとの接続のためのインターフェースである通信Ｉ／Ｆ（インターフェース）１０と、及びこれらを接続するバス１５と、から構成される。
【００２６】
図３は、病院情報システム端末２でのクリニカルパスの計画入力のフローを示す。患者のクリニカルパスは、オペレータにより病院情報システム端末２上で入力される。オペレータは、病院情報システム端末２にインストールされている本実施形態にかかる図３のプログラムをマウス等の入力装置を用いて起動させる。
【００２７】
上記より起動命令を受けた制御部１２は、記憶部１１に記憶されている上記のプログラムを読み込み、図３のフローで示すプログラムを起動させる。本プログラムを起動させると、ディスプレイにはクリニカルパス設定システムのメニュー画面が表示されている。このメニュー画面には各業務の処理に応じた処理画面へのボタンが複数存在し、その中から「クリニカルパスの選択」ボタンを選択すると、患者選択一覧が表示されるので、そこで所定の患者を選択すると、図４の画面に遷移する。それでは、以下では、図３のフローを参照しながら、各図の画面について説明する。
【００２８】
図４は、クリニカルパスの選択画面２０を示す。ここで、患者の病名・疾患が明確になっており、その病名・疾患に対するクリニカルパスが予め定義されているについて説明する。同図において、クリニカルパスの選択画面２０は、「クリニカルパス選択」一覧２１と、クリニカルパスの選択画面２０を中止して遷移元画面に戻る「キャンセル」ボタン２２と、「クリニカルパス選択」一覧２１で選択したクリニカルパスを決定する「ＯＫ」ボタン２３から構成される。
【００２９】
「クリニカルパス選択」一覧２１には、「○○病  クリニカルパス」、「□□病  クリニカルパス」、「○○手術  クリニカルパス」、「□□手術  クリニカルパス」等の所定の病名や疾患、手術に対応するクリニカルパスが表示されており、選択可能となっている。「クリニカルパス選択」一覧２１に表示される各クリニカルパス名は、クリニカルパスの選択画面２０への遷移時にクリニカルパス・データベース・サーバ３から取得した情報である。
【００３０】
まず、オペレータは、病院情報システム端末２で患者に対するクリニカルパスを選択する（ステップＳ１、以下ステップをＳと略する）。すなわち、クリニカルパス・データベース・サーバ３に登録されている病気・疾患ごとのクリニカルパスのリストが表示されるので、その中から患者の病気・疾患に合ったものを選択し、「ＯＫ」ボタン２３を押下する。
【００３１】
「ＯＫ」ボタン２３を押下後、不図示の画面に遷移し、その画面にてクリニカルパス設定の予定開始日、例えば、入院日を選択、または入力し（Ｓ２）、その画面内にある「ＯＫ」ボタンを押下すると、図５の画面に遷移する。そうすると、例えば、選択されたクリニカルパスが入院から退院まで１０日間で設定されているものである場合、入院日が９月１日であれば、図５に示すように、９月１日から１０日までの医療行為の予定が画面上に表示される。
【００３２】
図５は、クリニカルパス表示画面３０を示す。クリニカルパス表示画面３０は、患者の基本情報、選択したクリニカルパス名、開始日から終了日までの計画表が表示されるものである。具体的には、クリニカル表示画面３０は、「患者基本情報」表示欄３１、「クリニカルパス基本情報」表示欄３２、「クリニカルパス詳細情報」欄３３、本画面を終了して遷移元画面に戻る「キャンセル」ボタン３８、本画面で設定した情報をクリニカル・データベース・サーバ３に登録する「ＯＫ」ボタン３９から構成される。
【００３３】
「患者基本情報」表示欄３１には、クリニカルパス設定対象の患者の患者ＩＤ、氏名、性別、生年月日が表示される。また、「クリニカルパス基本情報」表示欄には、図４の「クリニカルパス選択」一覧２１で選択した病名・疾患等の名称や、そのクリニカルパスの適用開始日−適用終了日が表示される。
【００３４】
また、「クリニカルパス詳細情報」欄３３は、日にちを表す横軸３４、この日にちに対応する出来事を表示するイベント情報３５、治療・処置、検査、薬、栄養・食事、看護等の「医療行為」項目３６、各「医療行為」名表示領域３６に対応する日数を表すバー（図５中の網掛け部分）を表示させるバー表示領域３７から構成される。上述の通り、９月１日から１０日までの各医療行為に対応する日数がバーとして表示されている。なお、以下では、治療・処置、検査、薬、栄養・食事、看護等のクリニカルパスの構成要素を医療行為という。
【００３５】
上記のクリニカル表示画面３０に表示される項目は、クリニカル表示画面３０に遷移するときにクリニカルパス・データベース・サーバ３から各項目に対応する情報を取得している。このとき、クリニカルパス・データベース・サーバ３は、オーダ管理サーバ４に問い合わせをして、表示対象のクリニカルパスに含まれる医療行為のうち、予約枠のある医療行為に対し、予約枠が空いているかの検索処理を行っている（Ｓ３）。これについては、後述する。
【００３６】
図６は、クリニカル表示画面３０での予定の変更を促すメッセージ表示を示す。クリニカル表示画面３０がオープンされた時、デフォルトで自動設定された予定日時に対して既に予約枠がない場合がある。また、オペレータが、個々の医療行為について、クリニカルパスでデフォルトで自動設定された予定日時を変更したい場合には、手動で医療行為の予定日時を入力することができる。このとき、予約枠のある医療行為については、予約枠の空きを確認する必要がある。予約枠とは、医療行為の内容によっては、検査機器数、検査室等の制限のため１日に実施できる回数や時間帯が決まっているので、それらを予約枠として管理している。
【００３７】
クリニカル表示画面３０のオープン時（図５参照）に、予約枠が設定されている医療行為がクリニカルパスに含まれる場合、Ｓ３において、予約可能か否かの判定がされている。ここで、Ｓ３について詳述すると、具体的な予約枠の有無の検索は、クリニカル表示画面３０へ遷移するとき、クリニカル・データベース・サーバ３からクリニカル表示画面３０の表示に必要な情報を取得している。
【００３８】
このとき、クリニカル・データベース・サーバ３では、オーダ管理サーバ４で管理されている各サブシステムの予約情報を取得し、クリニカル表示画面３０に表示する対象のクリニカルパスに含まれる医療行為の日時と各サブシステムの予約情報（例えば、予約日時情報）とを照合して予約可能か否かを判定している。なお、予約情報は、直接各サブシステムのサーバから取得するようにしてもよい。
【００３９】
クリニカル・データベース・サーバ３での判定の結果、クリニカル表示画面３０に表示する対象のクリニカルパスに含まれるいずれかの医療行為のデフォルト設定の日時で予約枠に空きが無ければ、その旨の情報が病院情報システム端末２へ送信される。病院情報システム端末２の画面上でその検査の予定日時の変更が必要であることが表示される（図６参照）。例えば、入院６日目の午前の検査予定がクリニカルパスに設定されているのに、その日時に該当検査の予約枠に空きが無ければ、色や文字の強調によって、日時変更の必要が分かるよう表示される（Ｓ４）。
【００４０】
本実施形態では、図６に示すように、「予約枠が一杯です。日程を変更してください。」のメッセージ４０が表示される。そこで、メッセージ４０内にある「予約枠」ボタン４１をクリックすると、図７の画面が表示される。
図７は、検査予約画面５０を示す。同図において、検査予約画面５０は、横軸が日にち、縦軸が時間からなる予約枠設定領域５１と、本画面での処理を中止する「キャンセル」ボタン５２と、本画面での処理を確定する「ＯＫ」ボタン５３から構成される。検査予約画面５０では、検査の日程を変更することができる。
【００４１】
予約枠設定領域５１には予約枠が「予約不可」（網掛け表示）、「予約可能」（太枠表示）で表されている。本実施形態では、上述の通り、６日の午前の予約が既に埋っているので、「予約不可」表示５４となっている。また、７日の午後も「予約不可」表示５７となっているので予約することはできない。そこで、「予約可能」表示５５，５６，５８の中から選択する必要がある。本実施形態では、６日午後を選択している（選択された予約枠は、二重枠で表示される）。
【００４２】
上記より予約枠を選択後、「ＯＫ」ボタン５３を押下すると、検査予約画面５０が閉じてクリニカルパス表示画面３０がされ、「クリニカルパス詳細情報」欄３３にその変更した医療行為の予定日が更新される。
次に、クリニカルパスの雛型で決められた医療行為に対して、個別に詳細なオーダ情報を入力する必要のある場合やオーダの内容に変更のある場合は（Ｓ５で「Ｙｅｓ」へ進む）、図８のオーダ入力画面を開いて（Ｓ６）、詳細情報または変更情報を入力する。Ｓ５で変更が無ければ、「Ｎｏ」へ進み、後述するＳ８の処理を行う。
【００４３】
図８は、オーダ入力画面６１を示す。例えば、４日の医療行為「検査」の検査の内容を変更したいときには、「クリニカルパス詳細情報」欄３３の４日の検査のバーをマウスで右クリックすると、メニュー６０が表示され、その中から「変更」を選択すると、オーダ入力画面６１が表示される。オーダ入力画面６１は、医療行為「検査」の予定日を示す「予定日」と、「検査種別」と、「検査項目（検査１、検査２、検査３、検査４、検査５、検査６）」と、本画面での処理を中止する「キャンセル」ボタン６２と、本画面での処理を確定する「ＯＫ」ボタン６３から構成される。
【００４４】
「予定日」、「検査種別」、「検査項目」はそれぞれ、入力・変更が可能であるが、ここでは検査項目の変更について説明する。例えば、クリニカルパスのデフォルト設定では、検査３であったが、これを変更して検査１と検査４を実施する場合、オーダ入力画面６１にて検査１のチェックボックスのチェックを外して、検査１と検査４のチェックボックスをチェックして、「ＯＫ」ボタン６３を押下すると、オーダ入力画面６１は閉じる。このとき、クリニカルパス表示画面３０上では変更したクリニカルパスの情報が更新される。
【００４５】
このようにオーダ入力画面６１を用いて検査内容が変更される場合として考えられるのが、例えば、患者ごとの個別の要因、病状、アレルギー症状、感染症、などの理由が挙げられる。また、日程をずらす必要があるときは、予定表の上で、医療行為を実施する「予定日」を変更するが、これについては後述する。
【００４６】
さらに、クリニカルパスに医療行為を追加することもできる。例えば、「医療行為」名表示領域３６にマウスのポインタを移動させ、右クリックをすると、メニューが表示され、その中から「医療行為追加」を選択すると、医療行為情報一覧が表示されるので、任意にその中から医療行為を選択するようにしてもよい。このとき、選択後は、「クリニカルパス詳細情報」欄にその選択した医療行為が追加されている。
【００４７】
その後、オペレータは、他に変更をするか否かを判断し、変更があれば（Ｓ７で「Ｙｅｓ」に進む）、Ｓ６の処理を繰り返す。また、Ｓ７で変更が無ければ、「Ｎｏ」へ進み、後述するＳ８の処理を行う。
上記の処理の後、クリニカルパスの予定の開始日から終了日までの間の必要な医療行為の入力、設定が完了したら、クリニカルパス表示画面３０上で設定したクリニカルパスをクリニカルパス・データベース３に登録する（Ｓ８）。すなわち、「ＯＫ」ボタン３９を押下すると、例えば、Ｓ４やＳ６で変更した情報がクリニカルパス・データベース・サーバ３に送信され、クリニカルパス情報がクリニカルパス・データベース・サーバ３に登録される。
【００４８】
図９は、病院情報システム端末２からクリニカルパス・データベース・サーバ３に送信されるクリニカルパス情報６５の一例を示す。同図において、クリニカルパス情報６５はヘッダ情報部分と明細情報部分を有している。ヘッダ情報部分には、主にクリニカルパス表示画面での患者基本情報」表示欄３１や「クリニカルパス基本情報」表示欄３２の情報が含まれており、例えば、「患者ＩＤ」６５ａ、「クリニカルパスコード」６５ｂ、「クリニカルパス開始年月日」６５ｃ、「クリニカルパス終了年月日」６５ｄ、その他のフィールド群６５ｅ等から構成される。なお、「クリニカルパスコード」は、各クリニカルパスに設定されているコードのことである。
【００４９】
明細情報部分には主に「クリニカルパス詳細情報」欄３３の情報が含まれており、例えば、「医療行為コード」６５ｆ、「医療行為インデックス」６５ｇ。「開始予定日時」６５ｈ、「終了予定日時」６５ｉ、その他のフィールド群６５ｊ等から構成され、「クリニカルパス詳細情報」欄３３に表示されているバーの数だけレコードが格納されている。
【００５０】
「医療行為コード」は、各医療行為に設定されているコードであり、医療行為インデックスは、重複した医療行為コードを識別するためのコードである。例えば、図５の「クリニカルパス詳細情報」欄３３の医療行為「治療・処理」に対応するのが図９の医療行為コード＝５００１０１のレコードである。９月３日に医療行為「治療・処理」は１つしか存在しないから、当該レコードの「医療行為インデックス」には１が格納される。
【００５１】
また、図５の「クリニカルパス詳細情報」欄３３の医療行為「検査」に対応するのが図９の医療行為コード＝５１０２０１のレコードである。９月３日に医療行為「治療・処理」は５つ存在するから、当該レコードも５つ存在し、「医療行為インデックス」には順に１から５が格納される。
【００５２】
なお、予約枠の管理は、上記ではオーダ管理サーバにより管理されていたが、これに限定されず、各部門サブシステムでそれぞれの部門の予約枠を個別に管理する構成をとることも可能である。
次に、クリニカルパス・データベース・サーバ３に登録されたクリニカルパス情報６５が各サブシステムに発行される場合について説明する。
【００５３】
図１０は、クリニカルパス・データベース・サーバ３に登録されたクリニカルパス情報６５に基づいて、各サブシステムにオーダが発行されるフローを示す。上記のようにして、クリニカルパス・データベース・サーバ３にクリニカルパス情報６５が保存される（Ｓ１０）。これは、上記で説明したＳ８の処理のことである。その後、クリニカルパス・データベース・サーバ３に保存されたクリニカルパス情報がオーダ管理サーバ４に送信される。
【００５４】
次に、オーダ管理サーバ４は以下のオーダ処理を開始する（Ｓ１１）。オーダ管理サーバ４は、受信したクリニカルパス情報６５から個々の医療行為を抽出し（Ｓ１２）、それぞれの医療行為を担当する部門サブシステムへ送信するオーダ情報へ変換する（Ｓ１３）。オーダをどの部門サブシステムに送信するかの情報は、オーダ種別ごとに、オーダ管理サブシステムが管理している。
【００５５】
Ｓ１３について、図１１〜図１３のマスタテーブルを基に、さらに詳細を説明する。クリニカルパス・データベース・サーバ３のデータベース上には、医療行為マスタ７０（図１１）、サブシステムマスタ８０（図１２）、医療行為−サブシステム関連マスタ９０（図１３）が存在する。
【００５６】
図１１の医療行為マスタ７０は、対応測定や血圧測定等のクリニカルパスの構成要素として設定可能な医療行為を管理するテーブルである。１レコードは「医療行為コード」７１と、「医療行為名称」７２と、その他必要な情報を格納する複数のフィールド群７３より構成される。
【００５７】
図１２のサブシステムマスタ８０は、薬剤システムや内視鏡検査システム等の各部門で利用されているサブシステムに関する情報を管理するテーブルである。１レコードは、「サブシステムコード」８１、「サブシステム名称」８２、その他必要な情報を格納する複数のフィールド群８３より構成される。
【００５８】
図１３の医療行為−サブシステム関連マスタ９０は、医療行為に基づいて、その医療行為に関連のあるサブシステムにオーダを発行する場合、どの医療行為のオーダをどのサブシステムに発行すればよいかという関連付け情報を管理するテーブルである。１レコードは「医療行為コード」９１、「オーダ・インデックス」９２、「サブシステムコード」９３、その他必要な情報を格納するフィールド９４より構成される。また、１種類の医療行為に対して、複数のサブシステムを関連付けることができる。これは、１医療行為に対して、複数のサブシステムへオーダを送信する可能性を考慮したためである。
【００５９】
「オーダ・インデックス」９２は、１つの医療行為コードに対して複数のサブシステムコードが関連付けられている場合に用いる項目である。１つの医療行為コードに対して１つのサブシステムコードのみ関連付けられている場合には、「オーダ・インデックス」９２には「１」が格納される。
【００６０】
１つの医療行為コードに対して複数のサブシステムコードが関連付けられている場合には、オーダ・インデックスコードがそれぞれのサブシステムコードに対してカウントアップされて格納される。つまり、図１３に示すように、「医療行為コード：３００１０１」には、「サブシステムコード：１００１」と「サブシステムコード：７００１」が関連付けられているが、この場合、「オーダ・インデックス」９２には、「サブシステムコード：１００１」について「１」が、「サブシステムコード：７００１」について「２」が格納される。
【００６１】
クリニカルパス情報６５から抽出された各医療行為について、どのサブシステムに対してそのオーダ情報を送信すればよいかは、医療行為−サブシステム関連マスタ（図１３）を参照し、その医療行為コードに対応するサブシステムコードを参照する。
ここで、対象となる部門サブシステムが複数の場合もある。１個以上のサブシステムが関連付いている場合は、サブシステムマスタ（図１２）を参照し、そのサブシステムに対するオーダ送信に必要な情報を取得して、オーダ電文を生成し、そのサブシステムへオーダを送信する（Ｓ１４）。オーダ送信に必要な情報としては、例えばソケット通信を通信手段として使うならば、部門サブシステムのサーバのＩＰアドレス、ポート番号などの情報がある。そして、これらの情報を加えることでオーダ電文が生成される。
【００６２】
さて、再び図１０のフローの説明に戻る。オーダ管理サーバ４は、１個または複数の部門サブシステムへオーダを送信する（Ｓ１５）。１医療行為に対して、複数の部門システムにオーダを送信する必要がある例としては、例えば、注射オーダが挙げられる。注射オーダに対して以下の作業が必要であり、これらの作業を実施するために必要な各部門サブシステム（例えば、薬剤システム、看護携帯端末システム  等）にオーダが送信される。
【００６３】
１）  病棟における指示受作業
２）  薬剤部門における薬剤の払い出し作業
３）  病棟における薬剤の混注作業（ミキシング作業）
４）  病棟における患者への注射開始作業
５）  病棟における患者への注射終了作業
上述したように、その医療行為に対して、次の関連する部門がある場合（Ｓ１６で「Ｙｅｓ」へ進む）、Ｓ１４，Ｓ１５の処理を繰り返す。その医療行為に対して、関連する部門が無くなれば（Ｓ１６で「Ｎｏ」へ進む）、クリニカルパス情報６５に次の医療行為があるか否かを判定する（Ｓ１７）。
【００６４】
クリニカルパス情報６５に次の医療行為があれば（Ｓ１７で「Ｙｅｓ」へ進む）、Ｓ１２−Ｓ１７の処理を実行し、クリニカルパス情報６５に含まれる全ての医療行為についてＳ１２−Ｓ１７の処理を実行する。全ての医療行為についてＳ１２−Ｓ１７の処理が終了したら（Ｓ１７で「Ｎｏ」へ進む）、オーダ処理は終了する（Ｓ１８）。
【００６５】
以上では、クリニカルパスの計画入力−サーバへの登録−サブシステムへのオーダ発行というメインストリームについて述べた。次に、上記において少し触れたが、以下ではクリニカルパスで設定されている医療行為を実施する予定日を変更する場合について詳述する。
【００６６】
図１４は、クリニカルパスの変更フローを示す。患者に設定されたクリニカルパスは、その後治療経過などの状況変化に応じて、変更される事がある。この時、病院情報システム端末２上で既に設定されているクリニカルパスの変更をすることができる。また、このクリニカルパスの変更に応じて、各部門サブシステムに対してオーダ内容の変更情報を送信することが可能である。それでは、図１４を参照しながら、以下に詳述する。
【００６７】
まず、上述のクリニカルパス表示画面３０を開く（Ｓ２０）。次に、図１５に示すように、変更する必要のある医療行為を、クリニカルパスの画面上で選択する（Ｓ２１）。これは、図８で説明したのと同様である。そうすると、医療行為の詳細が表示されるので、変更入力を行う。例えば、医療行為「検査」を１日遅らせる場合について考える。このとき、「予定日」６４を９月４日から９月５日に変更する（Ｓ２２）。
【００６８】
次に、Ｓ２２の変更によって、その変更前の予定日以降の医療行為の計画で影響を受けるものがあるかか否かを判定する（Ｓ２３）。この中で医療行為のうち影響を受けるもの及び受けないものがあるが、医療行為同士の関連はクリニカルパス・データベースに登録されているので、どこが影響を受けるかが分かる。これについては後述する。また、変更することによって、それ以降の医療行為の計画で影響を受けるものがなければ（Ｓ２３で「Ｎｏ」へ進む）、Ｓ２４の処理を行う。
【００６９】
次に、Ｓ２３で変更の必要があると判定された場合（Ｓ２３で「Ｙｅｓ」へ進む）、影響を受ける医療行為は色や文字の強調によって表示される。この時、影響を受ける医療行為の日程を遅らせる、あるいは早めるといった内容は、変更された「予定日」６４に基づいて、自動で表示される（Ｓ２５）。これについては、図１６で説明する。
【００７０】
図１６は、図１５の「予定日」６４の変更によって影響を受けた医療行為の表示状態を示す。同図において、医療行為のうち「治療・処置」と「検査」が影響を受けている。「治療・処置」についてみてみると、「予定日」６４の変更前は、９月５日に予定日が設定されていたが（図１５参照）、変更後は１日ずれて９月６日の部分（１００）に予定日が表示され、さらに強調表示されている（Ｓ２６）。なお、ここでは、まだ、９月６日への変更は確定しておらず、ここでは、９月６日への変更が最小の変更であることをユーザに促している。「検査」についても同様であり、９月６日から９月７日（１０１）へ予定日を変更するように促している。
【００７１】
次に、これらの未確定の医療行為の予定日を確定させる処理を行わなければならない。そこで、例えば「検査」（１０１）をマウスで選択して右クリックをすると、図１７に示すメッセージが表示される。
図１７は、変更の影響を受けた医療行為の変更内容を決定するメッセージ画面１１０を示す。メッセージ画面には、変更前の予定日と変更後の予定日（未確定）を示す「予定日変更」と、「変更決定」ボタン１１２と、「詳細表示」ボタン１１１から構成される。自動的に変更された内容・日程でよければ（Ｓ２７で「Ｙｅｓ」へ進む）、「変更決定」ボタン１１２を押下してそのまま変更を決定する。変更の詳細を確認または変更する必要があれば（Ｓ２７で「Ｎｏ」へ進む）、「詳細表示」ボタン１１１を押下してオーダ入力画面６１を開いて、変更の詳細を確認または変更する（Ｓ２８）。
【００７２】
Ｓ２６、Ｓ２７，Ｓ２８の処理を繰り返して、すべての変更内容について確認後、Ｓ２４へ進む。
次に、オペレータは、その他に変更があるか否かを判断し（Ｓ２４）、変更があればＳ２１へ戻って、上記の処理を繰り返す。その他に変更が無ければ、オペレータは、「ＯＫ」ボタン３９を押下する。すると設定したクリニカルパス情報６５は、クリニカルパス・データベース・サーバ３に送信され、クリニカルパス情報６５がクリニカルパス・データベース・サーバ３に登録される。
【００７３】
その後、図１０のフローで説明したように、変更された医療行為すべてに対して、オーダ管理サーバ４が、変更オーダを関連する部門システムに対して送信する。
さて、図１４のＳ２３において、ひとつの医療行為の変更がそれ以降の医療行為に変更を与えるかどうかをチェックする方法については、図１８〜図２０を基に詳細を説明する。
【００７４】
図１８は、クリニカルパスのー部を抜粋し、医療行為の関連づけに関わる情報のみを図示したものである。ここで、医療行為「０００１」，「０００２」，「０００３」，「０００４」は、図１９に示すクリニカルパス・医療行為情報テーブル１３０に記録されている。
【００７５】
図１９は、クリニカルパス・医療行為情報テーブル１３０を示す。クリニカルパス・医療行為情報テーブル１３０は、クリニカルパス・データベース・サーバに格納されているテーブルであって、病院情報システム端末２から送信されたクリニカルパス情報６５に基づいて作成されるものである。クリニカルパス・医療行為情報テーブル１３０には当該クリニカルパスに含まれる医療行為に関する情報が格納されている。
【００７６】
クリニカルパス医療行為情報テーブル１３０の各レコードには、医療行為の「インデックス」１３１、「医療行為コード」１３２、「開始予定日時」１３３、「終了予定日時」１３４、およびその他の情報を記録するフィールド群１３５によって構成される。
一方、図１８のリンク情報０００１，０００２は、図２０に示すクリニカルパス・リンク情報テーブル１４０に記録されている。
【００７７】
図２０は、クリニカルパス・リンク情報テーブル１４０を示す。クリニカルパス・リンク情報テーブル１４０には、医療行為を関連付けている「リンク・インデックス」１４１と、「リンク・インデックス」１４１によって関連付けられた２つの医療行為を示す「医療行為インデックス１」１４２と「医療行為インデックス２」１４３と、２つの医療行為間に必要な「間隔日数（または間隔時間）」１４４が記録される。
【００７８】
この図１８では、９月１日９：００実施予定の医療行為０００１と、９月２日９：００に実施予定の医療行為０００３、同１２：００に実施予定の医療行為０００４がそれぞれリンク・インデックス「０００１」，「０００２」として関連付いている。しかしながら、医療行為０００２，０００５は他の医療行為との関連付けが無い。すなわち、他の医療行為に依存しておらず、独立しているので自由に変更することができる。
【００７９】
ここで、医療行為０００１の開始日時を１日遅らせようとした場合、以下のような処理が行われる。まず、オペレータにより医療行為０００１の開始日時が９月２日の９：００に変更される。すると、病院情報システム端末２の制御部はその変更についてクリニカル・データベース・サーバ３に問い合わせをする。この変更問い合わせ情報（例えば、変更されたインデックス、医療行為コード、変更後の開始予定日時等のデータが含まれる）を受信したクリニカル・データベース・サーバ３の制御部は、クリニカルパス・リンク情報テーブル１４０から「医療行為インデックス１」１４２に該当する医療行為、すなわち医療行為インデックス１＝「０００１」があるかどうかを検索処理を実行する。
【００８０】
この場合、医療行為インデックス１＝「０００１」の場合、リンク・インデックス０００１，０００２の２レコードが該当し、それぞれのレコードの「医療行為インデックス２」１４３の医療行為の内容を調べる。そうすると、医療行為インデックス２＝０００３，０００４である。ここで、クリニカルパス・医療行為情報テーブル１３０より医療行為０００３，０００４の内容を調べると、それぞれの「開始予定日時」１３３は「９月２日」であり、「間隔日数」１４４は「１日（翌日実施）」である。
【００８１】
医療行為０００１の開始予定日時が９月２日に変更されているため、クリニカルパス・リンク情報テーブル１４０に記録されている間隔日数と、実際の医療行為間（「医療行為０００１−医療行為０００３」間及び「医療行為０００１−医療行為０００４」間）の日数を計算すると、必要な間隔が空いていないという結果が得られる。
【００８２】
そこで、クリニカル・データベース・サーバ３の制御部は、それぞれの医療行為の開始予定日時及び終了予定日時をそれぞれの「間隔日数」１４４の分だけ後ろへずらす処理を実行する。
この場合、医療行為０００３，医療行為０００４の開始予定日時及び終了予定日時は、共に１日ずれ、医療行為０００３については「開始予定日時＝２００３／９／３  ９：００」，「終了予定日時＝２００３／９／３  １２：００」となり、医療行為０００４については「開始予定日時＝２００３／９／３  １２：００」，「終了予定日時＝２００３／９／３  １３：００」となり、それに伴って、それぞれの終了予定日時も同様に変更され、これらをクリニカル・データベース・サーバ３の記憶部に作業領域に一時的に保存する。それから、この一時的に保存した情報を変更問い合わせ結果情報として、病院情報システム端末２に返信する。
【００８３】
変更問い合わせ結果情報を受信した病院情報システム端末２の制御部は、その情報を反映させて、クリニカルパス表示画面３０の「クリニカルパス詳細情報」欄３３に表示させる（図１６参照）。
以上より、患者に対する一連の医療行為を、クリニカルパスを基に計画することができ、この計画を入力した段階で、個々の医療行為の担当部門にオーダを送ることができるので、各部門での再度のオーダの入力作業が極力少なくでき、オーダ入力作業の時間を削減することが可能である。
【００８４】
また、雛型となるクリニカルパスを基に計画を立て、ー連の医療行為の計画を時系列で参照できるために、オーダの入力ミス、入力漏れが削減される。また、クリニカルパスの変更を各部門システムに対して容易に反映させることができるので、変更事項の受け渡し漏れがなくなる。また、クリニカルパスに基づいて、１患者の医療行為に対して一元管理することが可能となる。
【図面の簡単な説明】
【００８５】
【図１】病院情報システムの全体構成を示す図である。
【図２】病院情報システムで用いられる各装置の内部構成を示す図である。
【図３】病院情報システム端末２でのクリニカルパスの計画入力のフローを示す図である。
【図４】クリニカルパスの選択画面を示す図である。
【図５】クリニカルパス表示画面を示す図である。
【図６】クリニカル表示画面での予定の変更を促すメッセージ表示を示す図である。
【図７】検査予約画面を示す図である。
【図８】オーダ入力画面を示す図である。
【図９】クリニカルパス情報の一例を示す図である。
【図１０】クリニカルパス・データベース・サーバ３に登録されたクリニカルパス情報６５に基づいて、各サブシステムにオーダが発行されるフローを示す図である。
【図１１】医療行為マスタテーブルを示す図である。
【図１２】サブシステムマスタテーブルを示す図である。
【図１３】医療行為−サブシステム関連マスタテーブルを示す図である。
【図１４】クリニカルパスの変更フローを示す図である。
【図１５】オーダ入力画面における予定日の変更を示す図である。
【図１６】図１５の「予定日」６４の変更によって影響を受けた医療行為の表示状態を示す図である。
【図１７】変更の影響を受けた医療行為の変更内容を決定するメッセージ画面を示す図である。
【図１８】クリニカルパスのー部を抜粋し、医療行為の関連づけに関わる情報を示す図である。
【図１９】クリニカルパス・医療行為情報テーブルを示す図である。
【図２０】クリニカルパス・リンク情報テーブルを示す図である。
【符号の説明】
【００８６】
１      病院情報システム１
２      病院情報システム用端末
３      クリニカルパス・データベース・サーバ
４      オーダ管理サーバ
５      部門サブシステム
１０    通信Ｉ／Ｆ
１１    記憶部
１２    制御部
１３    入力Ｉ／Ｆ
１４    出力Ｉ／Ｆ
１５    バス
【図１】
2005157560.tif 000003
【図２】
2005157560.tif 000004
【図３】
2005157560.tif 000005
【図４】
2005157560.tif 000006
【図５】
2005157560.tif 000007
【図６】
2005157560.tif 000008
【図７】
2005157560.tif 000009
【図８】
2005157560.tif 000010
【図９】
2005157560.tif 000011
【図１０】
2005157560.tif 000012
【図１１】
2005157560.tif 000013
【図１２】
2005157560.tif 000014
【図１３】
2005157560.tif 000015
【図１４】
2005157560.tif 000016
【図１５】
2005157560.tif 000017
【図１６】
2005157560.tif 000018
【図１７】
2005157560.tif 000019
【図１８】
2005157560.tif 000020
【図１９】
2005157560.tif 000021
【図２０】
2005157560.tif 000022