(57)【要約】【課題】  医療機関においてコンピュータシステムを用いてプロセス管理を行うことにより、医療行為を含む業務の実施状況を視覚的に表示、共有し、医療従事者が確実に診療業務を遂行できるようにする。【解決手段】  医療機関において医療従事者が使用する複数の端末６及び携帯端末７と、クリニカルフローサーバ２とがネットワーク５を介して接続されたクリニカルフローシステム１である。クリニカルフローサーバ２は、複数の医療業務モジュールを所定の実行順序に従って実行し、医療業務モジュールの実行状況に応じて、各医療従事者が使用する端末６又は携帯端末７へメッセージを送信するとともに、このメッセージに応答して送信される指示に従って医療業務モジュールを実行する。【選択図】  図１ 
2005063253.tif 000002
【特許請求の範囲】
【請求項１】
医療機関において医療行為を含む業務の遂行を支援するクリニカルフローの実行方法であって、
クリニカルフローを構成する医療業務モジュール及び各医療業務モジュールの実行順序を定義するオーダトレイ情報を複数記憶しておき、
前記複数のオーダトレイ情報のうちいずれか一のオーダトレイ情報が指定され、さらに前記オーダトレイ情報に基づいて処理すべき処理対象データが指定された場合に、指定された前記オーダトレイ情報と前記処理対象データとクリニカルフローの実行状態を示す情報とを組み合わせてオーダトレイインスタンスを生成し、
生成したオーダトレイインスタンスに基づいて医療業務モジュールを呼び出すことによってオーダトレイインスタンスを実行するとともに、前記医療業務モジュールの実行に応じて前記オーダトレイインスタンスの実行状態を示す情報を更新することを特徴とするクリニカルフロー実行方法。
【請求項２】
実行中の前記オーダトレイインスタンスがユーザからの入力指示又は他の機器からの情報入力を待機する状態となった場合に、当該オーダトレイインスタンスをサスペンド状態に移行させ、
サスペンド状態にある前記オーダトレイインスタンスに対する再開要求があった場合に前記オーダトレイインスタンスの実行を再開し、サスペンド状態にある前記オーダトレイインスタンスに対する中止要求があった場合に前記オーダトレイインスタンスの実行を中止することを特徴とする請求項１記載のクリニカルフロー実行方法。
【請求項３】
前記オーダトレイ情報は、ＸＭＬ（eXtensible Markup Language）によって記述されたものであることを特徴とする請求項１または２記載のクリニカルフロー実行方法。
【請求項４】
前記オーダトレイインスタンスの実行中にユーザに対する通知を行う際に、指定された宛先にプロセスキューを発信するプロセスキュー発信モジュールを実行することを特徴とする請求項１から３のいずれかに記載のクリニカルフロー実行方法。
【請求項５】
前記プロセスキュー発信モジュールによってプロセスキューを発信する際にプロセスキューの宛先が指定されると、指定された宛先に対応づけて、前記医療機関における組織上の権限、職責、役割、グループ構成のうちいずれか一以上に基づき予め定められた宛先に対してプロセスキューを発信することを特徴とする請求項４記載のクリニカルフロー実行方法。
【請求項６】
医療機関において医療行為を含む業務の遂行を支援するクリニカルフロー実行システムであって、
クリニカルフローを構成する医療業務モジュール及び各医療業務モジュールの実行順序を定義するオーダトレイ情報を複数記憶するオーダトレイ情報記憶手段と、
前記オーダトレイ情報記憶手段に記憶された複数のオーダトレイ情報のうちいずれか一のオーダトレイ情報が指定され、さらに前記オーダトレイ情報に基づいて処理すべき処理対象データが指定された場合に、指定された前記オーダトレイ情報と前記処理対象データとクリニカルフローの実行状態を示す情報とを組み合わせてオーダトレイインスタンスを生成するクリニカルフロー実行要求受付手段と、
前記クリニカルフロー実行要求受付手段により生成されたオーダトレイインスタンスを取得し、取得したオーダトレイインスタンスに基づいて医療業務モジュールを呼び出すことによってオーダトレイインスタンスを実行するとともに、前記医療業務モジュールの実行に応じて前記オーダトレイインスタンスの実行状態を示す情報を更新するフロー実行制御手段と、
前記フロー実行制御手段による呼び出しに応じて前記医療業務モジュールを実行するモジュール実行手段と、
を備えることを特徴とするクリニカルフロー実行システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療機関における医療行為を含む業務の遂行を支援するクリニカルフローの実行方法、及び、クリニカルフロー実行システムに関する。
【背景技術】
【０００２】
近年、医療機関において行われる業務、すなわち医療行為を含む業務は著しく複雑化している。これは、新たな診断方法等の開発による業務の増加、多様な治療方法の存在、医療従事者自身の経験を基本とした運用、施設ごとの組織や人員配置等の特性によるものである。このような状況に対し、殆どの医療機関は、主に医師・看護師らの医療スタッフの個人的な努力によって対応していた。このため、医療スタッフは、年々複雑に変化する業務を安全かつ効率的に行わなければならないという大きな負担を強いられていた。
【０００３】
ところで、複雑な業務の遂行を支援する方法としては、従来、ワークフローシステムが知られている（例えば、特許文献１参照。）。
【０００４】
【特許文献１】特開２０００−２０７４７４号公報
【０００５】
ワークフローシステムは、今まで人が行っていた業務について、業務の進捗状況管理等をコンピュータシステムによって行う処理である。これにより、業務の分担の明確化、業務プロセスの明確化、関連者による業務進捗度合いの共有、実行状況の管理・放置状態の警告等により、プロセスの効率化、ミスの防止、プロセス効率の評価が可能とされている。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところが、医療機関においてワークフローシステムを導入した例の多くは、医療費の会計処理等を対象としたものであって、医療行為を含む業務について、ワークフローシステムを適用しようとした例は無かった。
【０００７】
医療機関におけるワークフローシステムの導入を妨げてきた要因としては、次の問題が挙げられる。
第１に、医療機関毎に医療機器等の設備や検査の細かい手順が異なるため、ワークフローシステムの導入にあたっては、医療機関毎の業務手順に合わせてカスタマイズする必要がある。しかしながら、従来のワークフローシステムは業務手順の変更に要する労力が非常に大きく、カスタマイズに要するコストの負担が大きくなってしまうという問題があった。さらに、一つの医療機関においても、業務手順の変更は日常的に発生するが、上述のように、ワークフローの手順を変更する作業は手軽に行えるものではなかった。
【０００８】
第２に、一つの医療機関においても、診療科、病棟、診療補助部門等で独立した業務手順を有する場合があり、曜日や時間帯等によって手順が異なることをも考慮すると、非常に多くのワークフローを定義・保守する必要がある。さらに、ワークフローを導入する以前に予め標準化しておくアプローチも試されたが、上記のような複雑な要素を標準化するために、さらに多くの時間を費やして調整しなければならなかった。
【０００９】
これら上記第１および第２の問題により、医療機関において、医療行為を含む業務にワークフローシステムを導入したとしても、業務を効果的に支援することはできず、十分な効果を得ることは不可能であった。
【００１０】
本発明は、医療機関において、医療行為を含む業務について、コンピュータシステムを用いてプロセス管理を行うことにより、医療従事者間で誰が何をいつ行うのか、また実行状況を視覚的に表示、共有し、医療従事者が確実に診療業務を遂行できるようにすることを目的とする。
また、本発明は、業務手順の変更に容易に対応することが可能であり、かつ、多様な業務手順に対応することが可能なワークフローシステムを提供することをさらなる目的とする。
【課題を解決するための手段】
【００１１】
上記の課題を解決するため、第１の発明は、医療機関において医療行為を含む業務の遂行を支援するクリニカルフローを実行するため、クリニカルフローを構成する医療業務モジュール及び各医療業務モジュールの実行順序を定義するオーダトレイ情報を複数記憶しておき、複数のオーダトレイ情報のうちいずれか一のオーダトレイ情報が指定され、さらにオーダトレイ情報に基づいて処理すべき処理対象データが指定された場合に、指定されたオーダトレイ情報と処理対象データとクリニカルフローの実行状態を示す情報とを組み合わせてオーダトレイインスタンスを生成し、生成したオーダトレイインスタンスに基づいて医療業務モジュールを呼び出すことによってオーダトレイインスタンスを実行するとともに、医療業務モジュールの実行に応じてオーダトレイインスタンスの実行状態を示す情報を更新することを特徴とする。
【００１２】
また、第２の発明は、実行中のオーダトレイインスタンスがユーザからの入力指示又は他の機器からの情報入力を待機する状態となった場合に、当該オーダトレイインスタンスをサスペンド状態に移行させ、サスペンド状態にあるオーダトレイインスタンスに対する再開要求があった場合にオーダトレイインスタンスの実行を再開し、サスペンド状態にあるオーダトレイインスタンスに対する中止要求があった場合にオーダトレイインスタンスの実行を中止することを特徴とする。
【００１３】
第３の発明は、オーダトレイ情報がＸＭＬ（eXtensible Markup Language）によって記述されたものであることを特徴とする。
【００１４】
第４の発明は、オーダトレイインスタンスの実行中にユーザに対する通知を行う際に、指定された宛先にプロセスキューを発信するプロセスキュー発信モジュールを実行することを特徴とする。
【００１５】
第５の発明は、プロセスキュー発信モジュールによってプロセスキューを発信する際にプロセスキューの宛先が指定されると、指定された宛先に対応づけて、医療機関における組織上の権限、職責、役割、グループ構成のうちいずれか一以上に基づき予め定められた宛先に対してプロセスキューを発信することを特徴とする。
【発明の効果】
【００１６】
第１の発明によれば、クリニカルフローを実行するために、医療行為に係る業務処理を行うための医療業務モジュールと、クリニカルフローを構成する医療業務モジュール及び各医療業務モジュールの実行順序を定義するオーダトレイ情報とを用いるので、医療業務の手順すなわちクリニカルフローの内容を変更する場合、オーダトレイ情報を書き換えることによって速やかに対応でき、実際の処理プログラムである医療業務モジュールの変更等を行う必要がない。このため、医療機関毎の状況に合わせてクリニカルフローをカスタマイズすることも容易であり、クリニカルフローの変更に対しても迅速に対応可能であるという効果が得られる。さらに、多様な医療業務を支援するために多数のクリニカルフローを利用する場合、医療業務モジュールは各クリニカルフローの実行時に必要に応じて呼び出せば良いので、医療業務モジュールは共通のものを用意しておけば良く、オーダトレイ情報のみを多数用意すれば良い。これにより、少ない労力で多数のクリニカルフローを用意することができるので、多様な医療業務に対応できるという効果が得られる。また、クリニカルフローを実行する際には、オーダトレイ情報と処理対象データとを結合させてオーダトレイインスタンスを生成し、生成したオーダトレイインスタンスを実行するので、クリニカルフローの実行中にオーダトレイ情報自体が占有されることがない。さらに、オーダトレイインスタンスには、処理対象データが含まれているため、オーダトレイインスタンスのみに基づいてクリニカルフローを実行できる。これにより、複数のオーダトレイインスタンスを並行して実行することができるので、医療機関において多数のクリニカルフローを並行して実行できる。従って、医療機関において、複数の患者に関するクリニカルフローを同時に実行することも可能であり、その他、医療機関における様々なニーズに対応できるという効果が得られる。
さらに、本発明によれば、クリニカルフローを実行する際に、医療業務モジュールの実行に応じてオーダトレイインスタンスの実行状態を更新するので、クリニカルフローの実行状況を容易に確認できるという効果が得られる。
【００１７】
第２の発明によれば、待機状態となったオーダトレイインスタンスをサスペンド状態にすることで、そのオーダトレイインスタンスの処理に用いたハードウェア資源を解放することが可能となる。このため、複数のオーダトレイインスタンスを並行して実行する際の処理効率を高めることができるという効果が得られる。
【００１８】
第３の発明によれば、オーダトレイ情報の内容を容易に変更することができるので、クリニカルフローの変更等に容易に対応できるという効果が得られる。また、コンピュータプログラムの専門的な知識を有する者でなくてもオーダトレイ情報を作成・編集することが可能なため、医療機関毎の実情に合わせてクリニカルフローをカスタマイズすることができ、より効率よく医療業務の遂行を支援することができるという効果が得られる。
【００１９】
第４の発明によれば、ユーザに対するメッセージを、メッセージの重要度又は緊急性を示す情報とともに迅速に通知できるという効果が得られる。
【００２０】
第５の発明によれば、プロセスキューの宛先として、指定された宛先だけでなく医療機関における組織上の権限、職責、役割、グループ構成等に応じた適切な宛先が設定されるので、クリニカルフローに関する情報の共有を実現できるという効果が得られる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の最良の実施形態について、図面に基づき説明する。
図１は、本実施形態におけるクリニカルフローシステムの概略構成を示す図である。図１に示すクリニカルフローシステム１は、クリニカルフローサーバ２、ネットワーク５、端末６及び携帯端末７を中心として構成される。クリニカルフローサーバ２にはデータベースサーバ３が接続され、さらに、ネットワーク５を介して外部サブシステム４１が接続される。また、クリニカルフローサーバ２には、後述するアダプタ２８により、構内／公衆回線４０を介して携帯型電話機４２及びＦＡＸ４３が接続されるとともに、ラベルプリンタ４４及びプリンタ４５が接続される。
【００２２】
クリニカルフローとは、医療機関における医療業務（医療行為を含む）を支援するため、複数の医療業務モジュールを組み合わせて所定の順序で実行する処理である。医療業務モジュールとは、医療機関における業務処理を行うための処理プログラムである。
【００２３】
クリニカルフローサーバ２はクリニカルフローを実行するアプリケーションサーバである。クリニカルフローサーバ２は、ネットワーク５を介して接続された端末６からの指示に従って、データベースサーバ３に格納された各種情報を読み出し、クリニカルフローを実行する。クリニカルフローの実行中、クリニカルフローサーバ２は、必要に応じてネットワーク５を介して外部サブシステム４１にアクセスして、外部サブシステム４１に対する処理依頼や処理結果の報告を含む各種情報を送受信する。
また、クリニカルフローの実行中、クリニカルフローサーバ２は、アダプタ２８によって、構内／公衆電話回線４０を介して携帯型電話機４２に音声信号を出力したり、構内／公衆電話回線４０を介してＦＡＸ４３に情報を送信して印刷させたり、或いは、ラベルプリンタ４４及びプリンタ４５を制御してラベルや帳票を印刷させる。
【００２４】
データベースサーバ３は、クリニカルフローシステム１において処理される各種情報を格納し、クリニカルフローサーバ２からの要求に応じて情報を検索・抽出してクリニカルフローサーバ２に提供する。データベースサーバ３は、例えば、クリニカルフローシステム１が設置された医療機関における患者の個人情報や電子カルテに係る情報等を格納する。
【００２５】
外部サブシステム４１は、医療業務に係る情報を処理する各種装置（例えば、検査機器等の医療用機器やレセプトコンピュータ、部門システム等）であって、ネットワーク５を介してクリニカルフローサーバ２に接続され、所定のプロトコルを実行することによって、クリニカルフローサーバ２との間で情報を送受信する。
【００２６】
ネットワーク５は、クリニカルフローサーバ２と、外部サブシステム４１と、端末６や携帯端末７とを接続するネットワークである。ネットワーク５の具体的な実装形態は任意であり、医療機関内に敷設された構内ＬＡＮ（Local Area Network）やＰＢＸ（Private Branch eXchange）を含む構内電話回線網のみで構成されても良いし、公衆回線網、パケット通信網、フレームリレー網、ＡＴＭ（Asynchronous Transfer Mode）網や各種専用線、或いは、インターネット等の外部ネットワークを利用して構築されたＶＰＮ（Virtual Private Network）等の外部通信回線を含むものであっても良く、有線通信回線か無線通信回線かを問わない。
【００２７】
端末６及び携帯端末７は、クリニカルフローシステム１が設置された医療機関のスタッフ（医師、看護師、検査技師等の医療従事者、医療管理業務等の運営部門従事者等を含む）が使用する端末装置であって、ネットワーク５上に複数設置することが可能である。端末６及び携帯端末７は、医療機関内の各所（受付、検査室、診察室、処置室、ナースステーション、病室等）やスタッフの自宅等に設置され、或いは、スタッフが携帯する。図１に示す例では、端末６はパーソナルコンピュータであり、携帯端末７はＰＤＡ（Personal Digital Assistants）であるが、携帯電話機（ＰＤＣ（Personal Digital Cellular）方式、ＧＳＭ（Global System for Mobile communications）方式、ＣＤＭＡ（Code Division Multiple Access）方式等の各方式による携帯電話、及びＰＨＳ（Personal Handyphone System）を含む）を用いることも勿論可能である。なお、端末６及び携帯端末７の数は図１に示した数に限定されず、任意に変更可能である。
【００２８】
端末６及び携帯端末７は、ネットワーク５を利用した専用アプリケーションプログラムによる各種機能、電子メール機能、ブラウザ機能、メッセージング機能等の機能によって、クリニカルフローサーバ２との間で各種情報を送受信し、スタッフによって入力された指示をクリニカルフローサーバ２に送信する処理、及び、クリニカルフローサーバ２から受信した情報を画面上に表示する処理を行う。
【００２９】
なお、端末６及び携帯端末７の各端末は、誰が使用しているのかが一義的に定まっており、クリニカルフローサーバ２において、端末６及び携帯端末７の各端末を、それぞれ誰が使用しているかを判別することができる。この構成は、例えば、予め端末毎にユーザが指定されている構成としても良いし、或いは、クリニカルフローサーバ２を管理サーバとするドメインネットワークに、各使用者が自分に割り当てられたユーザ名に基づいて端末６及び携帯端末７からログインする構成としても良い。
【００３０】
図２は、図１に示すクリニカルフローサーバ２の機能的構成を示すブロック図である。
なお、説明の便宜のため、図２には、クリニカルフローサーバ２に外部接続される外部サブシステム４１、携帯型電話機４２、ＦＡＸ４３、ラベルプリンタ４４、プリンタ４５及び電子メール作成部４６の各部を図示する。
【００３１】
図２に示すように、クリニカルフローサーバ２は、クリニカルフローエンジン２１と、クリニカルフローエンジン２１の外部コンポーネントであるルール制御部２７、アダプタ２８及びメディアエクスチェンジャ２９とによって構成される。
また、クリニカルフローエンジン２１は、クリニカルフロー実行要求Ｉ／Ｆ（インタフェース）２２、クリニカルフロー制御部２３、データエンティティ格納部２４、医療業務モジュール実行部２５及び管理ツール２６の各機能部により構成される。
【００３２】
なお、図２はあくまでクリニカルフローサーバ２の機能的な構成を図示したもので、クリニカルフローサーバ２のハードウェア構成を限定するものではない。従って、図２に示す各機能部を、特定のハードウェアにより実現しても良いし、或いは、図示しないＣＰＵ（Central Processing Unit）、主記憶装置、補助記憶装置、通信インタフェース装置等の各種ハードウェアにより実現しても良い。
【００３３】
ここで、クリニカルフローシステム１において用いられるオーダトレイについて説明する。オーダトレイとは、クリニカルフローにおいて実行すべき業務手続や各業務手続の実行順序を定めた静的な情報である。
図３は、ＸＭＬによって記述されたオーダトレイの一例を示す図である。
【００３４】
図３に示すオーダトレイ１００は、プロパティセクション１０１、制御情報セクション１０２、及びフロー定義セクション１０３から構成される。
プロパティセクション１０１は、オーダトレイ１００の作成者、最終更新者、作成日時、最終更新日時、リビジョン等の各種情報を含む。プロパティセクション１０１は「clinical_flow_XML_property」タグで定義され、「author（作者）」、「last_author（最終更新者）」、「created_date（作成日時）」、「last_saved（最終更新日時）」、「revision（リビジョン）」等のタグを用いて記述される。
【００３５】
制御情報セクション１０２は、クリニカルフローの開始手続となる業務手続のＩＤ、例外処理の開始手続となる業務手続のＩＤ、クリニカルフローの処理モード等に関する情報を含む。制御情報セクション１０２は「flow_control」タグにより定義され、「start_process（開始手続）」、「exception_process（例外処理の開始手続）」、「process_mode（処理モード）」等のタグを用いて記述される。
【００３６】
フロー定義セクション１０３は、オーダトレイ１００に従ってクリニカルフローを実行する際に処理すべき業務手続に関する情報を含む。フロー定義セクション１０３は「clinical_flow」タグにより定義され、「process（業務手続の定義）」、「procedure（業務手続を処理するために呼び出す機能の識別文字列）」、「param（業務手続を処理するために呼び出す機能に渡す静的パラメータ）」、「result（業務手続の処理結果に応じた分岐をするための定義）」等のタグを用いて記述される。
【００３７】
図３に示すフロー定義セクション１０３には、業務手続定義１０４及び業務手続定義１０５が記述されている。業務手続定義１０４は、「検査材料を確認」とのＩＤが付された業務手続を、医療業務モジュール「Getmaterial」を呼び出して実行する旨を定義する。医療業務モジュール「Getmaterial」は、検査材料の種類を判別する処理を行うための医療業務モジュールであって、検査材料が骨髄液であれば処理結果として「骨髄液」を返し、検査材料が血液であればデフォルト値を返す。また、業務手続定義１０４には、医療業務モジュール「Getmaterial」が処理結果「骨髄液」を返した場合、「案内票を出力」という業務手続に移行する旨が定義され、医療業務モジュール「Getmaterial」がデフォルト値を返した場合はクリニカルフローを終了する旨が定義されている。
業務手続定義１０５は、「案内票を出力」とのＩＤが付された業務手続を、医療業務モジュール「OutputGuidance」を呼び出して実行する旨を定義する。医療業務モジュール「OutputGuidance」は、ネットワーク５上に設置されたプリンタ（ＩＰアドレス127.0.0.1）により、所定の案内票を印刷出力する処理である。業務手続定義１０５は、医療業務モジュール「OutputGuidance」がデフォルトの処理結果を返した場合にクリニカルフローを終了する旨を定義する。
【００３８】
このように、本願発明を適用したクリニカルフローシステム１においては、ＸＭＬで記述されたオーダトレイによって複数の医療業務モジュールの実行順序が定義されるので、クリニカルフローの変更や業務手続の追加等にも容易に対応できる。
【００３９】
なお、図３はあくまでオーダトレイの一例を示すものであって、クリニカルフローシステム１において利用するＸＭＬタグやパラメータ等は図３中に示すものに限られず、クリニカルフローシステム１を利用する医療機関における業務手順やクリニカルフローシステム１の実装形態等に合わせて任意に変更可能である。
【００４０】
クリニカルフロー実行要求Ｉ／Ｆ２２は、端末６又は携帯端末７の操作によりユーザから入力される各種要求を受け付けるインタフェースであり、入力された要求に応じてクリニカルフローの実行開始等の制御を行う。クリニカルフロー実行要求Ｉ／Ｆ２２は、端末６又は携帯端末７の操作による要求に応じて、データエンティティ格納部２４に格納されたオーダトレイを取得し、取得したオーダトレイにランタイム情報を結合させることでオーダトレイインスタンスを生成し、データエンティティ格納部２４に格納させる。さらに、クリニカルフロー実行要求Ｉ／Ｆ２２は、オーダトレイインスタンスを処理するためのクリニカルフロー制御部２３のインスタンスを生成させる。クリニカルフロー制御部２３においては、複数のインスタンスが各々独立してオーダトレイインスタンスを処理することが可能である。すなわち、クリニカルフロー制御部２３は、複数のオーダトレイインスタンスを並行して実行できる。
【００４１】
クリニカルフロー制御部２３は、クリニカルフロー実行要求Ｉ／Ｆ２２からの要求に応じて、データエンティティ格納部２４に格納されたオーダトレイインスタンスを読み込んで、クリニカルフローを実行する。クリニカルフローの実行に際して、クリニカルフロー制御部２３は、オーダトレイに定義された医療業務モジュールを医療業務モジュール実行部２５から呼び出して実行させる。また、クリニカルフロー制御部２３は、オーダトレイインスタンスの実行中、医療業務モジュールの実行に応じて、オーダトレイインスタンスの実行状態を更新してデータエンティティ格納部２４に格納させる。
【００４２】
ここで、図４を用いてクリニカルフロー実行要求Ｉ／Ｆ２２及びクリニカルフロー制御部２３の動作について、詳細に説明する。
図４は、クリニカルフロー実行要求Ｉ／Ｆ２２及びクリニカルフロー制御部２３の動作を詳細に示す図であり、（ａ）はクリニカルフローを開始する際の動作を示し、（ｂ）はクリニカルフローを再開する際の動作を示し、（ｃ）はクリニカルフローを中止する際の動作を示す。
【００４３】
まず、図４（ａ）において、端末６又は携帯端末７の操作によってクリニカルフロー開始要求が入力され、対象の患者及び実行すべきオーダトレイ（ここではオーダトレイ２０１）が指定されると（図中Ｐ１）、クリニカルフロー実行要求Ｉ／Ｆ２２は、指定された対象の患者に関する情報を取得し、指定されたオーダトレイ２０１をデータエンティティ格納部２４から取得する（図中Ｐ２）。続いて、クリニカルフロー実行要求Ｉ／Ｆ２２は、対象の患者に関する情報及びクリニカルフローの実行状態を示す情報等を含むランタイム情報をオーダトレイに結合させることにより、オーダトレイインスタンス２０２を生成して、データエンティティ格納部２４に格納する（図中Ｐ３）。
【００４４】
そして、クリニカルフロー実行要求Ｉ／Ｆ２２は、クリニカルフロー制御部２３のインスタンスを生成し、生成したインスタンスによって実行すべきオーダトレイインスタンス２０２を指定する（図中Ｐ４）。
クリニカルフロー制御部２３は、クリニカルフロー実行要求Ｉ／Ｆ２２により指定されたオーダトレイインスタンス２０２をデータエンティティ格納部２４から読み込んで実行する（図中Ｐ５）ことにより、クリニカルフローを実行する。
【００４５】
クリニカルフローシステム１により実行されるクリニカルフローには、例えば、医師による承認操作や処置室における処置等、人が介在する業務に係る処理が含まれるが、人が介在する業務の進行を待っている間はクリニカルフローの進行が一時停止し、いわゆる「待機状態」となる。また、クリニカルフローサーバ２において、外部サブシステム４１に処理を依頼して処理結果を待つ間は、同様に「待機状態」となる。
クリニカルフロー制御部２３は、実行中のオーダトレイインスタンス２０２が待機状態となった場合、オーダトレイインスタンス２０２の実行状態をサスペンド状態に設定してデータエンティティ格納部２４に格納する。この時点でクリニカルフロー制御部２３のインスタンスは消滅する。
サスペンド状態のオーダトレイインスタンス２０２は、端末６又は携帯端末７からクリニカルフロー実行要求Ｉ／Ｆ２２に対する要求に応じて、以下に述べるように再開または中止される。
【００４６】
図４（ｂ）に示すように、端末６又は携帯端末７の操作によって、サスペンド状態のオーダトレイインスタンス（ここでは、オーダトレイインスタンス２０２）に対するクリニカルフロー再開要求が入力されると（図中Ｐ１１）、クリニカルフロー実行要求Ｉ／Ｆ２２は、クリニカルフロー制御部２３のインスタンスを生成し、再開要求されたオーダトレイインスタンス２０２を指定する（図中Ｐ１２）。クリニカルフロー制御部２３は、クリニカルフロー実行要求Ｉ／Ｆ２２により指定されたオーダトレイインスタンス２０２を、データエンティティ格納部２４から読み込んで、オーダトレイインスタンスを再開する（図中Ｐ１３）。
【００４７】
また、図４（ｃ）に示すように、端末６又は携帯端末７の操作によってサスペンド状態のオーダトレイインスタンスに対するクリニカルフロー中止要求が入力されると（図中Ｐ２１）、クリニカルフロー実行要求Ｉ／Ｆ２２は、クリニカルフロー制御部２３のインスタンスを生成し、中止要求されたオーダトレイインスタンス２０２を指定する（図中Ｐ２２）。クリニカルフロー制御部２３は、クリニカルフロー実行要求Ｉ／Ｆ２２により指定されたオーダトレイインスタンス２０２を、データエンティティ格納部２４から読み込んで、オーダトレイインスタンス２０２の実行状態を「中止」に設定して更新を行う（図中Ｐ２３）。
【００４８】
図２に戻り、データエンティティ格納部２４は、オーダトレイやオーダトレイインスタンス等、クリニカルフローエンジン２１により処理される各種のデータエンティティを格納する。
【００４９】
医療業務モジュール実行部２５は、医療業務に係る各種の業務処理を行うための医療業務モジュールを格納し、クリニカルフロー制御部２３からの呼び出しに応じて、上記医療業務モジュールを提供する。
医療業務モジュール実行部２５が提供する医療業務モジュールは、医療業務全般において汎用的に使用可能な共通機能モジュールと、特定の医療業務に関する業務機能モジュールとがある。共通機能モジュールには、例えば、プロセスキューを発信する機能、ルール制御部２７にアクセスする機能、メディアエクスチェンジャ２９に対してデータを送信する機能、アダプタ２８を介して外部サブシステム４１へデータを転送する機能等が含まれる。医療業務モジュール実行部２５が提供する医療業務モジュールはプラグインの形態をとり、容易に追加することが可能である。追加された医療業務モジュールは、以前から存在する医療業務モジュールと同様に、必要に応じて呼び出され、その機能が提供される。
【００５０】
ここで、医療業務モジュール実行部２５が発信するプロセスキューについて説明する。
プロセスキューは特定の宛先が設定されたメッセージであり、例えば、処置室に対して骨髄液の採取を行うよう依頼したり、医師に対して検査結果の異常を通知したりする等の目的で用いられる。プロセスキューの宛先となったユーザは、端末６又は携帯端末７によって、プロセスキューの閲覧、承認等の処理を行うことが可能である。
クリニカルフローがサスペンド状態になっている場合、端末６又は携帯端末７においてプロセスキューに対する閲覧や承認等の処理が行われることで、クリニカルフロー実行要求Ｉ／Ｆ２２に対するクリニカルフローの再開要求が行われる。
【００５１】
医療業務モジュール実行部２５がプロセスキューを発信するための医療業務モジュールを実行すると、プロセスキュー情報が生成され、データエンティティ格納部２４に格納される。図５は、プロセスキュー情報の構成を模式的に示す図である。
図５に示すように、プロセスキュー情報は、プロセスキュー制御情報と、メッセージ情報と、アプリケーション制御情報とによって構成される。
【００５２】
プロセスキュー制御情報は、各プロセスキューに固有の識別情報としての「プロセスキューＩＤ」、プロセスキューの宛先を示す「宛先」、プロセスキューを発信したクリニカルフローについて、発信者等を示す「発信元」、プロセスキューの発信日時を示す「発信日時」、プロセスキューの有効期限を示す「有効期限」、プロセスキューの緊急度を示す「緊急度」、プロセスキューの重要度を示す「重要度」、プロセスキューの処理状態を示す「ステータス」等の各種情報を含む。
メッセージ情報は、プロセスキューの題名である「サブジェクト」、及び、メッセージの内容である「メッセージ内容」の各情報を含む。
アプリケーション制御情報は、プロセスキューを処理する際に使用するアプリケーションを示す「関連アプリケーション」、使用するアプリケーションに渡される情報である「アプリケーション情報」、プロセスキューを発信したオーダトレイインスタンスに関する情報である「オーダトレイインスタンス」、プロセスキューの処理により発生するイベントを定める「関連イベント」等の各種情報を含む。
なお、プロセスキューに含まれる情報は、クリニカルフローシステム１を利用する医療機関における業務手順や組織形態、或いは、クリニカルフローシステム１の実装形態等に合わせて任意に変更可能である。
【００５３】
プロセスキューが発信される際に生成されるプロセスキュー情報は、データエンティティ格納部２４において宛先毎に設けられた記憶エリア（図示略）に格納される。宛先として設定されたユーザが使用する端末６又は携帯端末７は、該ユーザに対応する記憶エリアに格納されたプロセスキュー情報を参照することにより、該ユーザを宛先とするプロセスキューを随時取得し、閲覧できる。
【００５４】
なお、医療業務モジュール実行部２５においてプロセスキューを発信する処理は、プロセスキューが単なるメッセージとしての機能のみを有し、プロセスキューの発信後に処理が進行する場合と、発信したプロセスキューに応答するユーザからの指示入力が必要なため、プロセスキュー発信後に指示入力に対する待機状態に移行する場合とがある。プロセスキュー発信後に待機状態に移行した場合、クリニカルフロー制御部２３によって、実行中のオーダトレイインスタンスがサスペンド状態となり、発信されたプロセスキューに応答して指示入力があった場合に、当該指示入力が、クリニカルフロー実行要求Ｉ／Ｆ２２によってクリニカルフロー再開要求として受け付けられ、オーダトレイインスタンスの実行が再開される。
【００５５】
図６は、端末６又は携帯端末７においてプロセスキュー情報を閲覧する際の画面の一例として、端末６に表示されるプロセスキュー閲覧画面６１を示す図である。なお、図６のプロセスキュー閲覧画面６１は、あくまでプロセスキューを閲覧するための画面の一構成例を示すものであって、プロセスキュー閲覧画面６１中の表示カラムの種類・順番といった細部構成については、プロセスキューに含まれる情報の種類や数、或いはクリニカルフローシステム１の実装形態等に応じて任意に変更可能である。
【００５６】
図６に示すプロセスキュー閲覧画面６１には、プロセスキューを閲覧する機能の名称「Process
Queue Browser」が表示されるとともに、閲覧中のユーザ名「医師Ａ」が表示されている。つまり、図６に示すプロセスキュー閲覧画面６１は、「医師Ａ」を宛先とするプロセスキューを閲覧中の画面である。
【００５７】
プロセスキュー閲覧画面６１には、医師Ａを宛先とした３件のプロセスキューについて、プロセスキューの題名が、プロセスキューの状態を示す「未確認」や重要度を示す「！重要」といった情報とともに表示されている。そして、これらのプロセスキューの題名を選択指定する操作により、プロセスキューの内容を閲覧できるようになっている。
また、プロセスキュー閲覧画面６１の下部には、プロセスキューの内容確認を指示する確認ボタンが配置されている。端末６の操作により、プロセスキュー閲覧画面６１に表示中のプロセスキューの題名を選択指定して確認ボタンを操作すると、当該プロセスキューに対する確認（承認）の処理が行える。プロセスキューの確認の処理が行われると、プロセスキュー閲覧画面６１におけるプロセスキューの状態が「未確認」から「確認」へ変更され、さらに、当該プロセスキューに対応するデータエンティティ格納部２４内のプロセスキュー情報において「ステータス」を更新する処理が行われる。
【００５８】
また、端末６において、確認されたプロセスキューをプロセスキュー閲覧画面６１上から消去するようにしても良い。この場合、プロセスキュー閲覧画面６１は、一種のＴｏＤｏリストとして利用できる。
【００５９】
さらに、端末６において、プロセスキュー閲覧画面６１に配された確認ボタンが操作された際に、プロセスキューの状態が「未確認」から「確認」へ変更されるとともに、プロセスキューに応答する指示がクリニカルフロー実行要求Ｉ／Ｆ２２へ送信されるようにしても良い。
【００６０】
なお、プロセスキューの宛先は、予め設定された情報に基づいて様々な方法によって設定することが可能である。
図７は、プロセスキューの宛先を指定する条件の例を示す図である。同図中、（ａ）はダイレクト指定を行う場合の条件を示し、（ｂ）はエイリアス指定を行う場合の条件を示し、（ｃ）は複数の宛先を含むエイリアス指定を行う場合の条件を示し、（ｄ）は役割指定を行う場合の条件を示す。
【００６１】
プロセスキューの宛先を、一人一人の人物を単位として設定する方法としては、図７（ａ）に示すような条件を用いれば良い。図７（ａ）に示す条件は、宛先を直接指定するダイレクト指定を行う場合の条件であり、医師Ａが宛先として指定されると、医師Ａを宛先とするプロセスキューが発信され、薬剤師Ｂが宛先として指定されると薬剤師Ｂを宛先とするプロセスキューが発信される。
また、例えば図７（ｂ）及び（ｃ）に示すように、医療機関内における役割等を示すエイリアスを用いて宛先を指定することも可能である。図７（ｂ）の条件に従えば、宛先として「Ａ先生」が指定されると、実際のプロセスキューの宛先に医師Ａが設定される。また、宛先として「Ａ先生の代診医」が指定されると、医師Ｂを宛先とするプロセスキューが発信される。なお、医師Ａの代診医がいる場合は、医師Ａと代診医とがプロセスキューを共有するようにしておけば、医師Ａ宛てのプロセスキューを、医師Ａと代診医の二人が閲覧できる。
【００６２】
さらに、図７（ｃ）に示す条件は、複数の宛先を含むエイリアス指定を行うための条件である。図７（ｃ）の条件に従えば、宛先として「内科医師」が指定されると、内科の医師である医師Ａを宛先とするプロセスキュー及び医師Ｂを宛先とするプロセスキューが発信される。また、宛先として「検査室」が指定されると、検査室に所属する技師Ｃを宛先とするプロセスキュー及び技師Ｄを宛先とするプロセスキューが発信され、「外科受付」が宛先として指定されると、外科受付に所属する職員である職員Ｅを宛先とするプロセスキュー、職員Ｆを宛先とするプロセスキュー、及び職員Ｇを宛先とするプロセスキューが発信される。
【００６３】
また、図７（ｄ）に示すように、医療機関における役割に基づいて宛先を設定することも可能である。図７（ｄ）の条件に従えば、宛先として「予約割り当て担当」を指定すると、予約割り当て担当宛てのプロセスキューが発信される。予約割り当ての担当となっている技師Ｃ及び技師Ｄはプロセスキューを共有できるようになっており、技師Ｃ及び技師Ｄは、いずれも、予約割り当て担当を宛先とするプロセスキューを受信できる。同様に、宛先として「服薬指導担当」を指定すると、服薬指導担当宛てのプロセスキューが発信される。服薬指導の担当となっている薬剤師Ｈ、薬剤師Ｊ及び薬剤師Ｋはプロセスキューを共有できるようになっており、３人とも、予約割り当て担当を宛先とするプロセスキューを受信できる。
【００６４】
このように、図７（ａ）〜（ｄ）に示すような条件を予め設定し、例えばデータエンティティ格納部２４に格納しておくことにより、プロセスキューの宛先を、医療機関における組織上の権限、職責、役割、グループ構成等に基づいて、ダイレクト指定、エイリアス指定、役割指定といった方法によって指定できるので、医療業務の円滑な進行を促進し、かつ、医療機関の状況に合わせて医療業務を支援することができる。
【００６５】
なお、プロセスキューの宛先として複数のユーザが設定される場合、設定された各宛先に対するプロセスキューが、それぞれ発信される構成としても良いし、複数の宛先を有する一つのプロセスキューが複数の宛先へ発信される構成としても良い。また、プロセスキューの宛先として複数のユーザが設定される場合、及び、プロセスキューを共有する場合には、当該プロセスキューの確認（承認）といった処理を行うことが可能なユーザと、閲覧のみ可能なユーザとを分けて設定することも勿論可能である。
【００６６】
また、データエンティティ格納部２４に格納されたプロセスキューを受信し、閲覧、処理する方法としては、端末６及び携帯端末７からクリニカルフローエンジン２１にアクセスする方法だけでなく、クリニカルフローエンジン２１からメディアエクスチェンジャ２９を介して、プロセスキュー情報を電子メール作成部４６に送信し、電子メール作成部４６から電子メールとして各種機器に送信する方法を採用しても良く、メディアエクスチェンジャ２９から携帯型電話機４２又はＦＡＸ４３に対してプロセスキュー情報を送信する方法を用いても良い。
【００６７】
図２に戻り、管理ツール２６は、データエンティティ格納部２４に格納されたデータエンティティを管理するための処理を行う。具体的には、管理ツール２６は、クリニカルフローエンジンのインストール、プロセスキューの宛先の登録・変更・削除、利用業務モジュールのプラグイン情報の管理、オーダトレイの定義、オーダトレイインスタンスの状態監視、プロセスキューの状態監視、各種処理に係るログの参照、完了したオーダトレイインスタンスの削除、完了したプロセスキューのクリーンアップ、不正な状態に陥ったオーダトレイインスタンスの検出と復旧等の処理を行う。
【００６８】
ルール制御部２７は、予め定義された、医療業務に係る種々の医療業務ルールと、医療業務ルールに従って評価処理を行う評価エンジンとを保持している。ルール制御部２７は、クリニカルフローエンジン２１によって呼び出された際に、クリニカルフローエンジン２１から渡されるデータを評価エンジンによって評価し、評価結果をクリニカルフローエンジン２１に返す。
【００６９】
アダプタ２８は、ネットワーク５を介して外部サブシステム４１との間で各種データを送受信するためのインタフェースである。
【００７０】
メディアエクスチェンジャ２９は、携帯型電話機４２、ＦＡＸ４３、ラベルプリンタ４４、プリンタ４５等の各種外部デバイス、及び、電子メール作成部４６に接続されており、クリニカルフローエンジン２１から入力される共通データを、上記各種外部デバイス又は電子メール作成部４６向けに加工し、出力する。例えば、メディアエクスチェンジャ２９は、クリニカルフローエンジン２１から入力されるデータに基づいて、携帯型電話機４２に宛てて電話を発信し、携帯型電話機４２に音声を送信する。また、例えば、メディアエクスチェンジャ２９は、ＦＡＸ４３に対して電話を発信するとともに所定のプロトコルを実行し、ＦＡＸを送信する。さらに、メディアエクスチェンジャ２９は、クリニカルフローエンジン２１から入力されるデータに基づいて印刷用データを生成し、ラベルプリンタ４４又はプリンタ４５に対して送信し、ラベルや帳票等を印刷出力させる。
さらに、メディアエクスチェンジャ２９は、クリニカルフローエンジン２１から入力されたデータに基づいて電子メール作成部４６を制御し、電子メール作成部４６によって電子メールを作成・送信させる。
【００７１】
電子メール作成部４６は、メディアエクスチェンジャ２９の制御に従って電子メールを作成し、ネットワーク５（図１）又は構内／公衆電話回線４０（図１）を介して電子メールを送信する。
【００７２】
以上のように構成されるクリニカルフローシステム１によってクリニカルフローを実行する場合の例として、検査業務のクリニカルフローを実行する場合を、実施例として説明する。
【実施例】
【００７３】
図８は、図１のクリニカルフローシステムにより実行されるクリニカルフローの一例として、検査業務のクリニカルフローを示すフローチャートである。
図８に示す検査業務は、医師が検査オーダを発行することにより開始される（ステップＳ１１）。検査オーダの発行時には、検査を受ける患者名や検査の種類等が指定される。
医師により検査オーダが発行されると、検査材料の確認が行われ、骨髄液の検査なのか血液検査なのかが判別される（ステップＳ１２）。
骨髄液の検査を行う場合、骨髄液の採取は処置室で行われるので、患者に対して処置室への案内票が渡され（ステップＳ１３）、処置室で骨髄液が採取される（ステップＳ１４）。血液検査の場合、すぐに採血が行われるので、ラベルプリンタによって血液検査ラベルが印刷出力される（ステップＳ１５）。
その後、検査システムに検査の依頼が出され（ステップＳ１６）、検査結果が返されると、検査結果の評価が行われる（ステップＳ１７）。
検査結果が正常値であった場合、医師に検査が終了した旨が通知され（ステップＳ１８）、本クリニカルフローは終了する。また、検査結果が異常値であった場合、医師に対して検査結果が異常であった旨が通知され（ステップＳ１９）、本クリニカルフローは終了する。
【００７４】
図９は、本実施例におけるクリニカルフローサーバ２の詳細構成を示す機能ブロック図である。図９に示すクリニカルフローサーバ２は、基本的に、図２に示した構成と同様である。
本実施例においては、クリニカルフローサーバ２に、外部サブシステム４１として検査システム４７が接続されている。検査システム４７には、ＩＰアドレス「192.168.1.200」が割り当てられ、ポート番号「5678」のポートに対するアクセスに応じて検査依頼を受け付ける。
また、クリニカルフローサーバ２において、ルール制御部２７は、検査結果に係る医療業務ルールを保持しており、この医療業務ルールに従って検査システム４７による検査結果を評価する評価エンジン「Evaluate Test Result」を有する。「Evaluate Test Result」は、検査結果が正常値の場合は処理結果「normal」を返し、検査結果が異常値の場合は処理結果「abnormal」を返す仕様となっている。
さらに、クリニカルフローサーバ２において、メディアエクスチェンジャ２９にはＩＰアドレス「192.168.1.100」が割り当てられている。また、メディアエクスチェンジャ２９は、クリニカルフローエンジン２１から識別子「Guidance」を含むデータが入力された場合には、プリンタ４５によって、予め作成された案内票フォーマットに基づく帳票を印刷出力させ、識別子「BloodTestLabel」を含むデータが入力された場合には、ラベルプリンタ４４によって、予め作成された血液検査ラベルフォーマットに基づくラベルを印刷出力させる。
【００７５】
図１０は、本実施例におけるクリニカルフローを実行するためのオーダトレイを示す図である。図１０に示すオーダトレイはＸＭＬで記述されている。
【００７６】
図１０に示すオーダトレイには、「検査材料の確認」、「患者に処置室への案内票を渡す」、「処置室で骨髄液を採取」、「検査システムに検査を依頼」、「検査結果の評価」、「医師に検査終了を通知」、「医師に検査結果が異常であることを通知」、「血液検査ラベルを出力」の各プロセスが定義されている。
【００７７】
「検査材料の確認」プロセスでは、医療業務モジュール実行部２５の医療業務モジュール「CheckTestMaterial」が呼び出される。医療業務モジュール「CheckTestMaterial」が処理結果「骨髄液」を返した場合は「患者に処置室への案内票を渡す」プロセスへ移行し、「CheckTestMaterial」が処理結果「血液」を返した場合は、「血液検査ラベルを出力」プロセスへ移行する。
【００７８】
「患者に処置室への案内票を渡す」プロセスでは、医療業務モジュール実行部２５の医療業務モジュール「MediaExchanger」が呼び出され、パラメータとして「192.168.1.100｜Guidance」が渡される。医療業務モジュール「MediaExchanger」は、メディアエクスチェンジャ２９（図９）を制御して各種処理を行わせるためのプログラムである。医療業務モジュール「MediaExchanger」が実行されることで、ＩＰアドレス「192.168.1.100」に基づいて、メディアエクスチェンジャ２９にデータが出力される。メディアエクスチェンジャ２９は、識別子「Guidance」に従って、プリンタ４５によって案内票を印刷させる。「MediaExchanger」の実行後、「処置室で骨髄液を採取」プロセスへ移行する。
【００７９】
「処置室で骨髄液を採取」プロセスでは、医療業務モジュール実行部２５の医療業務モジュール「ProcessQueue」が呼び出され、パラメータ「処置室｜骨髄液の採取をお願いします｜通常」が渡される。従って、医療業務モジュール「ProcessQueue」の実行により、「処置室室」宛てに、内容が「骨髄液の採取をお願いします」、緊急度が「通常」のプロセスキューが発信される。「ProcessQueue」の実行後、「検査システムに検査を依頼」プロセスへ移行する。
【００８０】
「検査システムに検査を依頼」プロセスでは、医療業務モジュール「TestSystemAdapter」が呼び出され、パラメータ「192.168.1.200」が渡される。医療業務モジュール「TestSystemAdapter」の実行により、ＩＰアドレス「192.168.1.200」に基づいてアダプタ２８を介して検査システム４７へデータが送信され、「検査結果の評価」プロセスに移行する。
【００８１】
「検査結果の評価」プロセスでは、医療業務モジュール「RuleEngine」が呼び出され、パラメータ「EvaluateTestResult」が渡される。医療業務モジュール「RuleEngine」が実行されることで、ルール制御部２７の評価エンジン「EvaluateTestResult」が呼び出され、検査システム４７による検査結果の評価が行われる。ルール制御部２７の評価エンジン「EvaluateTestResult」が返した処理結果が「normal」であった場合は「医師に検査終了を通知」プロセスへ移行し、「EvaluateTestResult」が返した処理結果が「abnormal」であった場合は「医師に検査結果が異常であることを通知」プロセスへ移行する。
【００８２】
「医師に検査終了を通知」プロセスでは、医療業務モジュール実行部２５の医療業務モジュール「ProcessQueue」が呼び出され、パラメータ「医師｜検査結果が出ました｜通常」が渡される。従って、医療業務モジュール「ProcessQueue」の実行により、「医師」宛てに、内容が「検査結果が出ました」、緊急度が「通常」のプロセスキューが発信される。「ProcessQueue」の実行後、クリニカルフローは終了する。
【００８３】
「医師に検査結果が異常であることを通知」プロセスでは、医療業務モジュール実行部２５の医療業務モジュール「ProcessQueue」が呼び出され、パラメータ「医師｜検査結果が異常でした｜至急」が渡される。従って、医療業務モジュール「ProcessQueue」の実行により、「医師」宛てに、内容が「検査結果が異常でした」、緊急度が「至急」のプロセスキューが発信される。「ProcessQueue」の実行後、クリニカルフローは終了する。
【００８４】
「血液検査ラベルを出力」プロセスでは、医療業務モジュール実行部２５の医療業務モジュール「MediaExchanger」が呼び出され、パラメータとして「192.168.1.100｜BloodTestLabel」が渡される。医療業務モジュール「MediaExchanger」が実行されることで、ＩＰアドレス「192.168.1.100」に基づいて、メディアエクスチェンジャ２９にデータが出力される。メディアエクスチェンジャ２９は、識別子「BloodTestLabel」に従ってラベルプリンタ４４によって血液検査ラベルを印刷させる。「MediaExchanger」の実行後、「検査システムに検査を依頼」プロセスへ移行する。
【００８５】
図１１は、図１０に示すオーダトレイに従ってクリニカルフローを実行する際のクリニカルフローシステム１の動作を示すフローチャートである。
【００８６】
ステップＳ２１では、検査材料の確認を行うため、医療業務モジュール「CheckTestMaterial」が実行される（ステップＳ２１）。
ここで、医療業務モジュール「CheckTestMaterial」が処理結果「骨髄液」を返した場合、クリニカルフローはステップＳ２２に移行し、患者に処置室への案内票を渡すために医療業務モジュール「MediaExchanger」が実行され、プリンタ４５によって案内票が出力され、クリニカルフローはステップＳ２３へ移行する。
ステップＳ２３では、処置室において骨髄液を採取するため、医療業務モジュール「ProcessQueue」が実行され、宛先を「処置室」とするプロセスキューが発信される。ここで、クリニカルフローはサスペンド状態に移行し、クリニカルフロー再開要求によって再開され、ステップＳ２５に移行する。
【００８７】
一方、ステップＳ２１において、「CheckTestMaterial」が処理結果「血液」を返した場合、クリニカルフローはステップＳ２４に移行し、血液検査ラベルを印刷するために医療業務モジュール「MediaExchanger」が実行され、ラベルプリンタ４４によって案内票が出力され、クリニカルフローはステップＳ２５へ移行する。
【００８８】
ステップＳ２５では、検査システム４７に対して検査を依頼するため、医療業務モジュール「TestSystemAdapter」が実行される。ここでクリニカルフローはサスペンド状態に移行し、検査システムにおける検査が終了した後、例えば検査室に設置された端末６からの入力等によってクリニカルフロー再開要求が発生すると、クリニカルフローが再開されてステップＳ２６に移行する。
【００８９】
ステップＳ２６では、検査結果の評価を行うため、医療業務モジュール「RuleEngine」が実行される。医療業務モジュール「RuleEngine」が処理結果「normal」を返した場合、クリニカルフローはステップＳ２７に移行して、医師に検査終了を通知するため、医療業務モジュール「ProcessQueue」が実行され、宛先を「医師」とするプロセスキューが発信される。ここで、クリニカルフローはサスペンド状態に移行し、クリニカルフロー再開要求によって再開され、クリニカルフローが終了する。
一方、ステップＳ２６において医療業務モジュール「RuleEngine」が処理結果「abnormal」を返した場合、クリニカルフローはステップＳ２８に移行して、医師に検査結果が異常であったことを通知するため、医療業務モジュール「ProcessQueue」が実行され、宛先を「医師」とするプロセスキューが発信される。ここで、クリニカルフローはサスペンド状態に移行し、クリニカルフロー再開要求によって再開され、クリニカルフローが終了する。
【００９０】
なお、以上の実施形態及び実施例においては、オーダトレイを記述するために用いたＸＭＬタグはあくまで一例であり、本発明を適用する環境や条件に応じて任意に変更可能である。また、医療機関における端末６の設置場所等の細部構成についても適宜変更可能である。また、上記実施例においては検査業務のクリニカルフローについて説明したが、本発明はこれに限定されるものではなく、必要なオーダトレイを用意しておくことにより、医療機関における殆ど全ての業務のクリニカルフローを実行することが可能である。
【図面の簡単な説明】
【００９１】
【図１】本発明の最良の実施形態におけるクリニカルフローシステムの概略構成を示す図である。
【図２】図１に示すクリニカルフローサーバの機能的構成を示すブロック図である。
【図３】図２に示すクリニカルフローエンジンによって処理されるオーダトレイの一例を示す図である。
【図４】図２に示すクリニカルフローエンジンの動作を模式的に示す図である。
【図５】図２に示すクリニカルフローエンジンにより発信されるプロセスキュー情報の構成を模式的に示す図である。
【図６】図１に示す端末に表示されるプロセスキュー閲覧画面の例を示す図である。
【図７】図２に示すクリニカルフローエンジンによりプロセスキューの宛先を指定する条件を示す図であり、（ａ）はダイレクト指定を行う場合の条件を示し、（ｂ）はエイリアス指定を行う場合の条件を示し、（ｃ）は複数の宛先を含むエイリアス指定を行う場合の条件を示し、（ｄ）は役割指定を行う場合の条件を示す。
【図８】図１のクリニカルフローシステムにより実行されるクリニカルフローの一例として、検査業務のクリニカルフローを示すフローチャートである。
【図９】本発明の実施例におけるクリニカルフローサーバの機能的構成を示すブロック図である。
【図１０】本発明の実施例において用いるオーダトレイの例を示す図である。
【図１１】本発明の実施例において実行されるクリニカルフローを示すフローチャートである。
【符号の説明】
【００９２】
１  クリニカルフローシステム
２  クリニカルフローサーバ
２１  クリニカルフローエンジン
２２  クリニカルフロー実行要求Ｉ／Ｆ
２３  クリニカルフロー制御部
２４  データエンティティ格納部
２５  医療業務モジュール実行部
２６  管理ツール
２７  ルール制御部
２８  アダプタ
２９  メディアエクスチェンジャ
３  データベースサーバ
５  ネットワーク
６  端末
７  携帯端末
【図１】
2005063253.tif 000003
【図２】
2005063253.tif 000004
【図３】
2005063253.tif 000005
【図４】
2005063253.tif 000006
【図５】
2005063253.tif 000007
【図６】
2005063253.tif 000008
【図７】
2005063253.tif 000009
【図８】
2005063253.tif 000010
【図９】
2005063253.tif 000011
【図１０】
2005063253.tif 000012
【図１１】
2005063253.tif 000013