管理システム
【課題】管理の対象となる人や物の位置を把握して、人や物の流れの効率化を図ることが出来る様な管理システムの提供。
【解決手段】管理対象物（例えば病院内の患者１、当該患者が保有するカードやバッジ、その他物流施設内を流通する物品等）に付加されたＩＣタグ（２）と、管理対象施設（例えば、病院３、市場、等）内に設けられて前記ＩＣタグ（２）から発信されるコード信号を受信し且つ受信した旨を出力する読取手段（例えば、カードリーダー４）と、制御手段（ネットワークコンピュータ）とを有し、該制御手段（５）は、読取手段（４）から発信された信号に基づいてＩＣタグ（２）を付加された前記管理対象物（例えば患者１）の流れを解析する様に構成されていることを特徴としている。
【解決手段】管理対象物（例えば病院内の患者１、当該患者が保有するカードやバッジ、その他物流施設内を流通する物品等）に付加されたＩＣタグ（２）と、管理対象施設（例えば、病院３、市場、等）内に設けられて前記ＩＣタグ（２）から発信されるコード信号を受信し且つ受信した旨を出力する読取手段（例えば、カードリーダー４）と、制御手段（ネットワークコンピュータ）とを有し、該制御手段（５）は、読取手段（４）から発信された信号に基づいてＩＣタグ（２）を付加された前記管理対象物（例えば患者１）の流れを解析する様に構成されていることを特徴としている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、施設（例えば病院等）内における人の流れや物の流れを解析するためのシステムに関する。より詳細には、本発明は、病院その他の種々の施設内における人や物の流れを解析して、当該人や物の流れが滞留する（ボトルネックが生じる）ことを未然に防止して、当該人や物の流れを効率化するためのシステムに関する。
【背景技術】
【０００２】
従来、病院内における患者の行動把握は行われておらず、個々の患者の「５Ｗ１Ｈ」、即ち、「誰が、何時、何処（受付、待合室、診察室、検査室？）で、何（例えば、受付を済ませて待っているのであれば診察待ち、診察を済ませて検査を待っているのであれば検査待ち）を、何故、どれ程（経過時間として、受付を済ませてから１時間待っている云々）行っているか」を把握する術はなかった。
尚、近年、痴呆患者の放浪癖に対応するため、居場所確認のためのモニタリング・システムは開発されてはいる。しかし、このシステムは一般患者全体をモニタリングし、病院全体の状況を把握したり、過去のデータを蓄積して今後を予測したりすることに利用するものではない。
【０００３】
また、病院側及び／又は患者側の要請として、一般患者の動向のモニタリングによる待ち時間の把握及びその短縮がある。
【０００４】
これまでは、病院内の混雑の度合いや待ち時間などを管理するツールは無く、看護師の目視観察によって概要のみ把握されていた。
【０００５】
待ち時間短縮のため、診察時間の予約制度を敷いている病院もあるが、これは統計的な個々の患者の診察データに基づくものではなく、単に一定時間内に一定の患者数を診察できるものとして予約を取っており、個々の患者の診察時間までを考慮したものではない。したがって、そのような予約制度があっても長時間に亘って待たされることが多く、患者側には大きな不満が存在するのが現状である。
【０００６】
上述のように、個々の患者の５Ｗ１Ｈが把握出来ないために、例えば、待合室の患者で順番が来ても、その時トイレ等で中座していて、順番が来たことを確認できず、例えば、急患を先にし、不急の患者（トイレに行った患者）を後回しにするといった様な診察順番の入替が円滑に行われない。
現状では、受付順で各医療行為が行われ、例えば、処置に急を要する人を優先し、処置に急を要さない人は後回にするという様に、診察順序を入れ替えることは出来ない。
【０００７】
或いは、個々の患者の５Ｗ１Ｈが把握出来ないために、患者が今何をどれくらい待っているか、そして待ちの原因は何によるものかが判断出来ない。即ち、病院側は、患者の混雑の原因が診察、検査、処置、会計、或いはその他の何れであるかが分からない。したがって、病院としては改善の余地がない。
患者側としても、待ち時間が正確に把握できれば、待ち時間を有効に利用出来るが、それが分からないため、あとどれ位待てば診察や検査が出来るか、知る術が無い。
【０００８】
さらに、個々の患者の５Ｗ１Ｈが把握出来ないために、患者一人一人の診察時間、検査時間、処置時間等が把握できず、予約制を採用しても、個々の診療時間等のばらつきで、予約制による１日の時間短縮等、効率向上の精度が上がらず、依然として順番待ちや、診察や各種処理の「空き」が発生してしまう。
特に規模が大きい病院では、「待ち時間」が長いという不満が非常に強いことは、広く知られている。
【０００９】
その他の従来技術としては、ＩＤコードリーダーを発信するＩＣタグを用いて被管理者の居場所を常時把握するように構成したシステムが存在する（特許文献１）。
【００１０】
しかし、その様な従来技術では、被管理者の位置を把握することしか行っておらず、被管理者の位置データに基づいて、より効率的な或いは好感度の高い管理を行うという発想は無く、上述した様な種々の問題点を解消するものではなかった。
【特許文献１】特開２００３−３２３４９０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は上述した従来技術の問題点に鑑みて提案されたものであり、管理の対象となる人や物の位置を把握して、人や物の流れの効率化を図ることが出来る様な管理システムの提供を目的としている。
【課題を解決するための手段】
【００１２】
本発明の管理システムは、管理対象物（例えば病院内の患者１、当該患者が保有するカードやバッジ、その他物流施設内を流通する物品等）に付加されたＩＣタグ（２）と、管理対象施設（例えば、病院３、市場、等）内に設けられて前記ＩＣタグ（２）から発信されるコード信号を受信し且つ受信した旨を出力する読取手段（例えば、カードリーダー４）と、制御手段（ネットワークコンピュータ５）とを有し、該制御手段（５）は、読取手段（４）から発信された信号に基づいてＩＣタグ（２）を付加された前記管理対象物（例えば患者１）の流れを解析する様に構成されていることを特徴としている（請求項１：図１）。
【００１３】
本発明において、前記管理対象施設は病院（３）であり、前記制御手段（ネットワークコンピュータ５）は、読取手段（カードリーダー４から発信された信号に基づいて、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う部署（診療室３２、検査室３３等）における待ち時間を演算するように構成されているのが好ましい（請求項２：図１０、図１１）。
【００１４】
ここで、前記制御手段（ネットワークコンピュータ５）は、読取手段（４）から発信された信号に基づいて、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）に必要な時間（診療時間の予測値）を求めるように構成されているのが好ましい（請求項３：図３、図４）。
【００１５】
そして本発明において、前記制御手段（ネットワークコンピュータ５）は、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う待ち時間（或いは、その演算結果）が最も少なくなる様に、次回の処理に必要な時間（予約時間）を決定するように構成されているのが好ましい（請求項４：図３、図５）。
【００１６】
また本発明において、前記制御手段（ネットワークコンピュータ５）は、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う部署における待ち時間の演算結果（待ち時間として演算された結果の数値）が所定時間（所定値）以上であれば、当該個人（１）に対して実施される処理における待ち時間の演算結果の合計が少なくなる様に当該処理の順序を変更する制御を実行する様に構成されているのが好ましい（請求項５：図８、図９）。
【００１７】
或いは本発明において、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う部門（診察室３２、検査室３３等）における待ち時間が所定時間（許容待ち時間）を超えた場合には、他の部門（検査室３３、処置室３４等）で作業を行うスタッフ（医者、看護師、検査技師等）を、当該部門（診察室３２、検査室３３等）のスタッフとして配置する制御を行う様に構成されているのが好ましい（請求項６：図１２、図１３）。
【００１８】
本明細書において、「コンピュータ」なる文言は、情報処理能力を有する全ての機器を意味する包括的な文言として使用されている。
【発明の効果】
【００１９】
上述する構成を具備する本発明によれば、前記ＩＣタグ（２）から発信されるコード信号を受信して管理対象物（例えば病院内の患者１、物流施設内を流通する物品）の位置を把握するのみならず、当該受信された信号に基づいて、前記管理対象物（患者１）の流れを解析する様に構成されているので、解析された結果に基いて、前記管理対象物（患者１）の流れ（人の流れや物流）が最も効率的になるように、種々の手法を実行することが出来る。
すなわち、管理対象物（患者１）を特定するのみならず、最適な処理を行うための解析用ツールとして使用することが出来る。
【００２０】
そして、本発明を例えば病院（３）に適用した場合、前記管理対象物は診療や各種処置を受ける患者（１）であり、係る患者（１）の流れを解析することにより、各部門における待ち時間を把握することが出来るので（請求項２）、いわゆるボトルネックとなっているのがどの部門であるかを決定出来る。係るボトルネックを決定出来れば、当該ボトルネックを解消する様に業務内容の改善を図ることにより、病院全体における患者（１）の待ち時間を減少して、待ち時間に対する患者（１）の不満に対処することが出来る。
換言すれば、本発明を病院に適用すれば、現在、病院に通院する人々や患者における最大の不満である「待ち時間が長い」という問題を、解消することが出来る。
【００２１】
同様に、本発明によれば、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）に必要な時間、すなわち診療時間の予測値を求めることが出来るので（請求項３）、係る予測値を用いて、予約して来院する患者（１）の待ち時間が最も少なくなるように構成することが出来る。
その結果、従来における問題点である「予約をしても待たされる」という患者（１）の不満に対処出来る。
【００２２】
それと共に、当該予測値を活用して、診療や検査等のスケジュールを好適に決定して、来院した患者（１）の待ち時間を最も少なくすることが可能となる（請求項４）。
【００２３】
これに加えて、本発明によれば、待ち時間が所定時間（許容待ち時間）を超えた場合には、他の部門（検査室３３、処置室３４等）で作業を行うスタッフ（医者、看護師、検査技師等）を、当該部門（診察室３２、検査室３３等）のスタッフとして配置する（いわゆる「リカバリー」を行う）様に構成されているので（請求項５）、係る部門（診察室３２、検査室３３等）が待ち時間の長いボトルネックとなってしまうことを解消し或いは予防することが出来る。
【発明を実施するための最良の形態】
【００２４】
以下、添付図面を参照して、本発明の実施形態について説明する。
【００２５】
図１及び図２を参照して本発明の第１実施形態を説明する。
図１において、管理対象施設である病院３は、待合室３０と、受付３１と、診察室３２と、検査室３３と、処置室３４とに区画されている。受付３１及び各部屋３２〜３４の入口には、夫々ゲート４０が設けられ、その各ゲート４０には後述するＩＣタグの情報を読み取るカードリーダー４が備えてある。
【００２６】
前記全てのカードリーダー４は、当該システムＡの制御手段であるネットワークコンピュータ５に入力信号ラインＬｉで接続されている。また、受付３１及び各部屋３２〜３４には、モニタを備えた端末Ｐ１（受付用）、Ｐ２〜Ｐ４（各部屋用）が設置され、情報ネットワークＬｏで前記ネットワークコンピュータ５に接続されている。
尚、情報ネットワークＬｏとしては、セキュリティが万全であれば、インターネットでも可能である。又、カードリーダー４は、レジのリーダーのようなものでもよく、その他、種々の方式が有り、特に限定する趣旨ではない。
【００２７】
管理対象である当該病院３の患者には、受付を済ませた患者１全員に対してＩＣタグ２を持たせる。
このＩＣタグ２は、特定個人、即ち患者１の情報（ネットワークコンピュータ５のサーバー側に入っている）をサーバー側から引き出すための暗証番号のような特定の識別コードが記録されているＩＣチップと、アンテナとによって構成されている。
尚、図１において、符号３ｉは病院の出入り口を示す。又、ＩＣタグ２をバーコードで代替させることも可能である。
【００２８】
各部屋の端末Ｐ２〜Ｐ４では、ネットワークコンピュータ５からの情報を受け取るとともに、個々の患者の処置結果が入力される。患者一人一人の情報は、当該患者１がＩＣタグ２とともにゲート４０を通過する度に、カードリーダー４及び入力信号ラインＬｉを介してネットワークコンピュータ５に伝送される。
【００２９】
ネットワークコンピュータ５はこれらの情報を基に、個々の患者の状態をリアルタイムにモニタリングする。
ネットワークコンピュータ５は、患者毎の診察時間や処置時間、会計処理時間等のデータを蓄積する。
【００３０】
上述した構成の管理システムＡによれば、測定したデータに基づき、以下のような利用が可能となる。
（１） 端末Ｐ１〜Ｐ４に待ち患者数とともに待ち時間を表示する。端末Ｐ１〜Ｐ４に表示された結果から、病院の医師、看護師、事務会計係は、患者の待ち時間とともに待ちの理由を把握することが出来る。
患者や来訪者は、待ち時間を正確に把握して、何時呼ばれるかを正確に予測することが出来る。従って、待ち時間を有効に利用出来る。例えば、待ち時間を他の作業に振り当てることが出来る。待ち時間を正確に把握できるので、診療の順番が来た人が、中座していることが防げる。
勿論、診療の順番が来るのを事前に見計らって、予めトイレに行ける。
又、事務会計係や受付は「本日は混んでいるか？」等の電話の問い合わせに応答する必要があって、そのような場合には「患者の待ち時間及びその理由」も把握しておけば、問い合わせに対して、利便を与えられる。
（２） 時間的に余裕の無い患者を優先するなど、個々の患者のニーズに合わせて診察順を入れ替えることが出来る。
（３） 患者毎の診察、検査、処置等のフローをデータベース化することにより、通常のルート、例えば、（「診察」→「検査」→「診察」→「処置」）の順番を入れ替えることにより、待ち時間を短縮することが出来る。
【００３１】
ここで、ＩＣタグ２の携行の態様としては、一般的には患者の診察券に取付けられるものが考えられるが、診察券にＩＣタグ２を取り付けることに代えて、患者の所有する、或いは身に着けるバッジ、ブレスレッド、カードその他に取り付けても良い。
ＩＣタグ２をどの様に取り付けるかは、病院の規模により変わる。例えば、大規模病院では、診察券を流用する場合が多く、中小規模病院では、見た目の良い態様を選択する傾向である。
【００３２】
カードリーダー４の他の利用例としては、例えば、痴呆症の徘徊であれば、病院中の至るところにカードリーダー４を設置して、徘徊する患者の現在位置をリアルタイムで把握する。或いは、カードリーダー４を病院３の出入り口３ｉだけに設置して、徘徊する患者が病院を出た場合に、直ちに対処出来るようにすることも可能である。
【００３３】
第１実施形態の作用効果を以下に記す。
（１） 患者がどの時間帯に何処でどんな理由によって待たされているか、データが自動採取出来る。また、そのデータを分析することにより、ネック工程や空時間（アイドル時間）等、経営工学的手法による問題解決のためのデータとして利用出来る。
（２） 患者が何処でどんな理由で待っているか把握出来るので、待ちの原因や夫々の工程の空き状況によって、検査の順番を入れ替える等の工程変更を行えば、空時間の有効活用が出来る。
（３） 従来の方法では診察可能な患者の総数を増すことは不可能であったが、本実施形態の管理システムＡを活用すれば、空時間の有効活用により、正味の診察時間を削ることなく診察可能な患者数を増やすことが出来る。
（４） 患者の居場所が把握出来るので、スピーカーによるアナウンス等、患者呼び出し時間が短縮出来る。
（５） 予約制を強いている場合、個々の患者における過去の情報（平均診察時間や検査の要否、時間的余裕の有無等）から、予約時間の精度を高めることが出来る他、急ぎの患者を優先させる等、個人個人の事情に合った対応が可能となる。
（６） 本発明の第１実施形態によれば、病院３側は、患者１の混雑の原因が、診察か、検査か、会計か、その他かが把握出来る。そして、混雑要因を特定すれば、病院として、混雑の改善が可能となる。
従来は、例えば、診察に時間が掛かっているのに、会計処理を改善するようなことが行われているような例があったが、本発明によれば、その様な「意味のない；場違いな」改善を行うことが無くなる。
すなわち、本発明の第１実施形態によれば、待ち時間に関するデータを取得することにより、「混雑」解消のための適切な改善策が立案出来る。
【００３４】
図２に基づいて、第１実施形態におけるネットワークコンピュータ５の構成と、ＩＣタグ２を用いて情報を収集する態様をより詳細に説明する。
【００３５】
図２において、ネットワークコンピュータ５は、病院内の管理ポイント毎に配置された全てのカードリーダー４と接続され、カードリーダー４を経由して、患者１の所持するＩＣタグ２からデータ収受を行うインターフェース５１と、そのインターフェース５１で収受したデータを記憶するデータベース５２と、データベースに記憶されたデータに基づいて、各種演算、例えば、患者１が病院３内で消費した待ち時間の合計の計算や、統計データ分析、例えば、待ちの原因分析処理を行う処理ユニット５３とによって構成されている。
前記処理ユニット５３は、病院３内の管理ポイント毎に設置された端末Ｐ１〜Ｐ４と接続され、その端末のモニタＭによって、処理の内容、例えば現在受付を済ませた患者の待ち時間等を表示する。
尚、図２では患者１、ＩＣタグ２、病院３、端末Ｐ１〜Ｐ４は省略している。
【００３６】
即ち、当該ネットワークコンピュータ５では、対象とする患者１にＩＣタグ２を所持させ、病院３内の管理ポイント毎に設置したカードリーダー４から、各患者１の所持するＩＣタグ２の各管理ポイント経過時間を時系列的に測定し、作業分析のデータとして活用している。
【００３７】
個々の患者１について、ストップウォッチやビデオ撮影などの手段により計測するのが、従来のタイムスタディ（改善の前段階の計測）であった。
それに対して、図２で示す様なシステム（ネットワークコンピュータ５）であれば、その様なタイムスタディを自動化できる。換言すれば、図２のシステムによれば、作業改善のためのデータ取り（タイムスタディ）を自動的に集計できる。そして、図２で示す様なシステム（ネットワークコンピュータ５）を採用すれば、患者１のみならず、看護師、医師、事務方の一人、検査技師、一人の動きをＩＣタグ２でチェックして、データが取れる。
また、過去の診療データ等と組み合わせることにより、ジャストインタイムで、且つ、精度の高い（待ち時間が短い）予約を行うことが可能となる。
【００３８】
図３〜図７で示す第２実施形態は、図１及び図２を参照して説明した第１実施形態を応用した予約に関する技術に係るものである。
【００３９】
図３は、第１実施形態を予約システムに適用した場合の、図１のネットワークコンピュータ５の機能ブロック図として示したものである。
ネットワークコンピュータ５Ａ（図３では、図２と符合を違えている）以外の第２実施形態に係る予約システムは、図１のシステムをそのまま利用している。
換言すれば、図１のネットワークコンピュータ５の構成例の一つ及びその制御例（４種類の処理）が、図３〜図７で示す第２実施形態である。
【００４０】
先ず、図３において、第２実施形態のネットワークコンピュータ５Ａは、各カードリーダー４と接続されたインターフェース５１と、データベース５２と、処理ユニット５３と、予約スケジューリング５４を備えた予約システム５５とを有している。
【００４１】
前記予約システム５５は、受付３１（図１参照）の端末Ｐ１と接続しており、予約情報や予約の問い合わせ、スケジュールの問い合わせ、急患等の緊急割り込みに対応している。
又、予約システム５５の予約スケジューリング５４は受付３１の端末Ｐ１と接続して、ネットワークコンピュータ５で設定した予約スケジュールを、受付３１のモニタＭ及び待合室３０のモニタＭに表示する。
【００４２】
次に、図４及び図５に基づいて、個々の患者の診療時間を予測する処理方法について説明する。
【００４３】
先ずデータベース５２側の処理として、ステップＳ１では、カードリーダー４により、ネットワークコンピュータ５Ａのインターフェース５１を経由して、ＩＣタグ２による患者１（図１参照）全体のデータの受信を行う。
【００４４】
次のステップＳ２では、患者個人毎にデータを分析して、ステップＳ３に進み患者各個人の診察時間（診察予測時間）を予測する。
【００４５】
次に、予約システム５５側の処理として、図５において、先ずステップＳ４で、ネットワークコンピュータ５Ａは、予約の申し込みがあるまで待機しており（ステップＳ４のループ）、申し込みがあれば（ステップＳ４のＹＥＳ）、ステップＳ５に進む。
【００４６】
ステップＳ５では、予約者及び予約希望時間を入力した後、ステップＳ６に進み、予想診療時間を決定し、ステップＳ７に進む。
【００４７】
ステップＳ７では、ネットワークコンピュータ５Ａは予約希望時刻から予想診療時間に他の予約と重複するか否かを判断しており、重複していれば（ステップＳ７のＹＥＳ）、ステップＳ８に進み、当該予約希望時刻が不可であることを最寄りの表示手段に出力しステップＳ５まで戻り、再びステップＳ５以降を繰り返す。
【００４８】
一方、重複していなければ（ステップＳ７のＮＯ）、ステップＳ９に進み、当該予約希望時刻がＯＫであることを出力して制御を終える。
【００４９】
上述のように、個々の患者における診療時間の予測値を求め、係る予測値を参照することにより、予約時間丁度に来院した患者の待ち時間を出来る限り短くすることが可能となる。
具体的には、図４のステップＳ１において、ＩＣタグ２がカードリーダー４を通過する毎にデータを発信することにより、個々の患者がどの様な診察或いは処置を受け、当該診察或いは処置にどの位の時間を要したかが、データとしてデータベース５２に蓄積される。
【００５０】
係るデータを、個人毎にまとめることにより、次回の来院或いは次回の処置は、どの部門から始め、どのような順序で進めたほうがよいかが予想できる。この予想は、診療或いは処置を行った医師や技師の側から入力することも可能である。それと共に、次回に受診或いは対象となる診療や処置に要する時間を、過去のデータから推定することも可能となる。
【００５１】
予約の際には、予約した本人について、予想される診療或いは処置に要する時間の予測値（図５のステップＳ６の処理で求まる：図３の矢印ａ）と、前後の患者の診療或いは処置に要する時間の予測値（これも、図５のステップＳ６の処理で求まる：図３の矢印ａの処理）とを参照して、出来る限り待ち時間が短くなるような組み合わせを演算している。
係る演算は、統計処理上の公知手法を用いることで、処理ユニット（図３の５３）で実行可能である。
これにより、次回の予約を決定することが出来る。
【００５２】
図３〜図５の実施形態は、次回の診療や処置の予約のためのシステムであるが、受付の段階における処理にも適用できる。
すなわち、図５で予約時間を決定するに際して、診療や処置のために来院した患者或いは入院している患者のその日における診療や処置を、出来る限り待ち時間が少なくなる様に、効率的に行う様に設定しているので、受付の段階で、当該効率的に設定された診療や処置についてのスケジュールを、当該患者に知らせれば良い。
【００５３】
具体的には、受付の段階において、図３で示す様に、受付３１の端末Ｐ１（図１参照）からネットワークコンピュータ５Ａの予約システム５５にスケジュールの問い合わせを行い、予約システム５５から受付３１の端末Ｐ１に予約スケジュール情報を出力する。
受付３１の端末Ｐ１では、出力された予約スケジュール、すなわち効率的に設定された診療や処置についてのスケジュールを表示する。
係る処理を示すのが、図６である。
【００５４】
図６に基づいて、係る処理方法を説明する。
先ず、ステップＳ１１では、ネットワークコンピュータ５Ａは、受付３１の端末Ｐ１からスケジュールの問い合わせがあったか否かを判断しており、問い合わせがあれば（ステップＳ１１のＹＥＳ）、ステップＳ１２に進み、一方、問い合わせが無ければ（ステップＳ１１のＮＯ）、ステップＳ１１のループを繰り返す。
【００５５】
ステップＳ１２では、当該患者１のスケジュールを予約システム５５より出力して制御を終える。
【００５６】
ここで、スケジュールの表示は、図３では図示しない端末（或いはディスプレイ）等で、病院内の随所で行う様に構成することが出来る。
【００５７】
ここで、事故、急病等、救急患者すなわち診療や処理に緊急性のある患者が発生する場合がある。かかる場合には、診療や処理を速やかに行わないと、命に関わる事態が想定される。
即ち、そのような場合には、図４〜図６にかかわらず、直ちに診療や処理が必要となる。
【００５８】
その様な救急患者の場合は、緊急のタグを与えて処理する。具体的には、救急患者等、処置に急を要する人を優先し、処置に急を要さない人は順番を後に回しても良い。
上述の処理を、図７に基づいて説明する。
【００５９】
先ず、緊急患者の容態を診て、緊急タグ（図示しない）を付与するか否かを判断して、付与するのであれば（ステップＳ２１のＹＥＳ）、ステップＳ２２に進み、付与しないのであれば（ステップＳ２１のＮＯ）、前述の図４〜図６の処理へ移る。
【００６０】
ステップＳ２２では、緊急タグを付与した患者の処置を最優先とし、次のステップＳ２３では、緊急タグを付与した旨を予約システム５５に送信し、ステップＳ２４で予約スケジュールを変更して処理を終える。
【００６１】
上述したように、救急患者が存在することにより、既に予定されたスケジュールは変動する。その様な場合には、処理ユニット５３及び予約システム５５で、緊急タグが付与された状態において、改めて待ち時間が最小となる予約スケジュールを計算し、必要に応じて予約スケジュールを変更することが出来る。予約スケジュールの変更では、患者の待ち順番の入れ換えが行われる。
【００６２】
ここで、或る患者の診療における処置の順序を入れ換える（例えば、第１及び第２の検査が必要な患者がいた場合、第１の検査が混雑していて、第２の検査が空いている場合、第２の検査から受診させる様に案内する）ことも可能である。
その詳細については、以下の第３実施形態で述べる。
【００６３】
図７で述べたとおり、本発明の実施形態では、待ち時間が少なくなる様に効率的に設定された診療や処置についてのスケジュールである予約スケジュールが、受付時に表示可能である様に構成されている。
しかし、種々の診療や処理が、予測されたのとは異なってしまう場合もある。その様な場合、予約スケジュールを出力されていたとしても、待ち時間が長時間となってしまう場合がある。勿論、係る予約スケジュールが出力されていない場合には、更に待ち時間の長期化を招き問題を大きくしてしまう。
【００６４】
その様な場合において、待ち時間が長い診察や処理を後回しにすることにより、診療や処理全体に費やされる時間を短縮出来る場合がある。
図８及び図９の第３実施形態はその様な状態に対処するための手法である。
【００６５】
図８及び図９に基づいて、第３実施形態を説明する。
【００６６】
先ず、図８において、第３実施形態のネットワークコンピュータ５Ｂは、各カードリーダー４と接続されたインターフェース５１と、データベース５２と、処理ユニット５３と、判定ユニット５６とを有している。
【００６７】
前記判定ユニット５６は、表示・連絡ユニット５７と接続している。
ここで、表示連絡ユニット５７は、受付３１（図１参照）或いは各部屋３１〜３４の端末Ｐ１〜Ｐ４のモニタＭとしても良い。
【００６８】
前記処理ユニット５３では、或る患者の診療における処置の順序を入れ換えた場合の科目別、経路別の待ち時間を計算し直し、その情報を判定ユニット５６に送信して（図８のａの経路）、判定ユニット５６は入替が「ＯＫ」の場合の結果を表示・連絡ユニット５７で表示する。
尚、判定ユニットで「ＮＧ」と判断された場合は、「ＮＧ」であったことを処理ユニット５３にフィードバックして（ｂの経路）、処理ユニット５３は再び別の計算を行う。
【００６９】
次に、図９に基づいて、係る処理の流れを説明する。
【００７０】
先ず、ステップＳ３１では、ＩＣタグ２によるデータを受信し、次のステップＳ３２では、診察順序及び予約待ち時間を決定して、ステップＳ３３に進む。
【００７１】
ステップＳ３３では、処理ユニット５３で、入れ替えた場合の予約待ち時間を演算し、その値が所定値以下か否かを判断する。所定値以下であれば（ステップＳ３３のＹＥＳ）、ステップＳ３７まで進み、所定値を超えていれば（ステップＳ３３のＮＯ）、ステップＳ３４に進む。
【００７２】
ステップＳ３４では、判定ユニット５６で、他の部門と順番を変更することが可能か否かを判断しており、可能であれば（ステップＳ３４のＹＥＳ）、ステップＳ３５に進み、変更出来なければ（ステップＳ３４のＮＯ）、ステップＳ３７まで進む。
【００７３】
ステップＳ３５では、判定ユニット５６は、変換した部門の予想待ち時間が所定値以下であるか否かを判断しており、所定値以下であれば（ステップＳ３５のＹＥＳ）、次のステップＳ３６に進む。一方、所定値を超えていれば（ステップＳ３５のＮＯ）、ステップＳ３４に戻り、再びステップＳ３４以降を繰り返す。
【００７４】
ステップＳ３６では、変換した部門を次の診察部門に決定し、ステップＳ３７に進み、診察順番を最寄りの表示・連絡手段５７に表示・連絡して処理を終える。
【００７５】
上述したように、第３実施形態の処理では、待ち時間が長い診察や処理を後回しにすることにより、診療や処理全体に費やされる時間を短縮出来る。
【００７６】
図８及び図９の第３実施形態は、第１実施形態及び／又は第２実施形態と組み合わせて実施することが可能である。
【００７７】
次に、図１０及び図１１を参照して、第４実施形態を説明する。図１０及び図１１の第４実施形態は、待ち時間の管理に関する実施形態である。
【００７８】
先ず、図１０において、第４実施形態のネットワークコンピュータ５Ｃは、各カードリーダー４と接続されたインターフェース５１と、データベース５２と、処理ユニット５３と、待機時間出力手段５８とを有している。
【００７９】
前記待機時間出力手段５８は、各端末Ｐ１〜Ｐ４のモニタＭと接続している。
【００８０】
次に、図１１に基づいて、第４実施形態の処理の流れを説明する。
【００８１】
ステップＳ４１では、第１実施形態〜第３実施形態と同様に、カードリーダー４によりＩＣタグ２によるデータを自動的に受信して、当該データを、インターフェース５１を介してネットワークコンピュータ５Ｃのデータベース５２に一旦記憶する。
【００８２】
処理装置５３では、ステップＳ４２で、前記記憶されたデータを引き出し、そのデータを各科目毎にデータ分析する。そして、次のステップＳ４３では、当該データに基づいて、各管理ポイント毎の待ち時間を処理装置５３で算出し、ボトルネックとなっている行程の割り出し、待ち時間の決定、待ち時間の時系列的推移状況の決定等を行う。
待ち時間の時系列的推移状況とは、時間が経過すれば、待ち時間が増加（減少）する等の傾向を指す。
【００８３】
ここで、ボトルネックとなっている行程の割り出し、待ち時間の決定、待ち時間の時系列的推移状況の決定（ステップＳ４３）は、ＩＣタグ２によるデータを各科目（病院であれば、各医局、各診療室、各検査室）毎に整理して、公知の統計処理上の各種手法を用いることにより行われる。当該統計処理上の手法については、説明を省略する。
【００８４】
ボトルネックとなっている行程の割り出しが出来れば、当該行程に医師や看護師を多数配置したり、当該行程における診療や処置を後回しにする様に患者を誘導したり、当該行程における担当の医師や看護師等に対してボトルネックとなっている旨を通知する等、各種の手法により、ボトルネックを積極的に解消することが可能である。
【００８５】
次のステップＳ４４に進み、ネットワークコンピュータ５Ｃは、以上の結果の表示要求があるか否かを判断して、表示要求があれば（ステップＳ４４のＹＥＳ）、ステップＳ４５でモニタＭによって表示した後処理を終える。一方、表示要求が無ければ、（ステップＳ４４のＮＯ）、そのまま処理を終える。
【００８６】
図１０及び図１１の第４実施形態では、待ち時間が決定されれば、各部門における待ち時間を比較することにより、ボトルネックが特定できる。
また、待ち時間が長い部門に対して、医師や看護師を多数配置したり、当該部門の診療や処置を後回しにする様に患者を誘導したり、当該部門の担当者（医師や看護師や技師）に対して待ち時間が長くなっている旨を通知する等により、ボトルネックの発生を未然に防止する措置を取ることが可能となる。
そして、待ち時間の時系列的推移状況が決定出来る場合も、ボトルネックの発生を事前に予見出来る。
さらに、ボトルネック解消のために患者等を誘導するに際して、図１０で示すモニタＭでスケジュールを表示することが出来る。
【００８７】
第４実施形態は、第１実施形態〜第３実施形態と組み合わせて実施することが可能である。
【００８８】
ボトルネックの発生を未然に防止するため、或いは、発生してしまったボトルネックを解消するために、担当の医師や看護師や技師を増員する制御について、以下、図１２及び図１３の第５実施形態で詳細に説明する。
【００８９】
同一の処理或いは診療を行う部門（医師や看護師や技師等の個人を含む）が複数存在する場合に、一方の部門の待ち時間が長く、他方の待ち時間が短い場合に、待ち時間が短い方の担当者（スタッフ）に、待ち時間が長い方の応援をさせ、以って、待ち時間の均等化を図るのが、図１２及び図１３のリカバリーシステムである。
【００９０】
図１２において、第５実施形態のネットワークコンピュータ５Ｄは、第３実施形態のネットワークコンピュータ５Ｂとベースが同様であるが、処理ユニット５３及び判定ユニット５６が各端末Ｐ１〜Ｐ４と接続されていることが異なる。
【００９１】
図１３に基づいて、第５実施形態の処理の流れを説明する。
【００９２】
先ず、ステップＳ５１において、ネットワークコンピュータ５Ｄは、待ち時間が許容値以上の部門がある、及び／又はリカバリーの要請があるかを判断しており、待ち時間が許容値以上の部門がある、及び／又はリカバリーの要請がある場合は（ステップＳ５１のＹＥＳ）、ステップＳ５２に進む。一方、待ち時間が許容値以上の部門がない、及び／又はリカバリーの要請が無い場合は（ステップＳ５１のＮＯ）、あるまで、ステップＳ５１のループを繰り返す。
【００９３】
ステップＳ５２では、当該部門に他のスタッフが存在するか否かを判断しており、存在すれば（ステップＳ５２のＹＥＳ）、ステップＳ５３に進み、存在しなければ（ステップＳ５２のＮＯ）、ステップＳ５６に進む。
【００９４】
ここで、リカバリーするべき他のスタッフが存在しないような部門については、リカバリー自体が不可能である。従ってステップＳ５６では、リカバリーが不可能であることを、待ち時間が所定以上の部門及び／又はリカバリーの要請をした部門へ連絡した後、処理を終える。
【００９５】
また、或る部門のスタッフが他の部門のリカバリーに行った結果、今度は、その部門がボトルネックとなってしまうことは防止する必要がある。そのため、ステップＳ５３では、他のスタッフが存在する部署の待ち時間を入力して、その部署のリカバリー後の待ち時間を演算する。
【００９６】
次のステップＳ５４では、演算した待ち時間が所定値未満であれば（ステップＳ５４のＹＥＳ）、当該スタッフにリカバリー要請を連絡した後、処理を終える。
【００９７】
スタッフを他の部門に回した結果、その部門の待ち時間が一定時間よりも長くなってしまうような演算結果が得られた場合には、当該部門からスタッフを他の部門の応援に出すことはしない。そこで、待ち時間が所定値を超えてしまったなら（ステップＳ５４のＮＯ）、ステップＳ５２まで戻り、再びステップＳ５２以降を繰り返す。
【００９８】
すなわち、第５実施形態では、病院全体として、待ち時間が短くなるように、設定されている。
【００９９】
また、第５実施形態は、第１実施形態〜第４実施形態と組み合わせて実施することが可能である。
【産業上の利用可能性】
【０１００】
図示の実施形態では、病院を例示しているが、本発明の適用は、病院のみに限定されるものではなく、遊園地や役所等、多数の人が訪れて、順番待ちの時間の存在が問題になる様な施設の全てについて、本発明が適用可能である。
或いは、人にＩＣタグを付加する場合のみならず、対象とする物にＩＣタグを装着させ、ＩＣタグリーダー（カードリーダー）を施設内の管理ポイント毎に設置し、各管理ポイント経過時間を時系列的に測定し、物流分析のデータとして活用することも可能である。
【０１０１】
すなわち、図示の実施形態はあくまでも例示であり、本発明の技術的範囲を限定する趣旨ではない。
【図面の簡単な説明】
【０１０２】
【図１】本発明の第１実施形態の管理システム全体の構成を示したブロック図。
【図２】第１実施形態のネットコンピュータの構成を示したブロック図。
【図３】本発明の第２実施形態に関するネットコンピュータの構成を示したブロック図。
【図４】本発明の第２実施形態のネットコンピュータのデータベース側における予約処理の流れを説明するフローチャート。
【図５】本発明の第２実施形態のネットコンピュータの予約システム側における予約処理の流れを説明するフローチャート。
【図６】本発明の第２実施形態に係り、スケジュールの問合せが有った場合の処理方法を示したフローチャート。
【図７】本発明の第２実施形態に係り、緊急性のある患者が発生した場合の処理方法を示したフローチャート。
【図８】本発明の第３実施形態に関するネットコンピュータの構成を示したブロック図。
【図９】本発明の第３実施形態に係り、ある患者の医療処置の順番を入れ替える場合の処理方法を示したフローチャート。
【図１０】本発明の第４実施形態に関するネットコンピュータの構成を示したブロック図。
【図１１】本発明の第４実施形態に係り、待ち時間の管理方法を示したフローチャート。
【図１２】本発明の第５実施形態に関するネットコンピュータの構成を示したブロック図。
【図１３】本発明の第５実施形態に係り、発生してしまったボトルネックを解消するため、医師や看護師や技師を増員する制御方法を示したフローチャート。
【符号の説明】
【０１０３】
１・・・管理対象物／患者
２・・・ＩＣタグ
３・・・管理対象施設／病院
４・・・カードリーダー
５、５Ａ、５Ｂ、５Ｃ、５Ｄ・・・ネットワークコンピュータ
３０・・・待合室
３１・・・受付
３２・・・診察室
３３・・・検察室
３４・・・処置室
４０・・・ゲート
５１・・・インターフェース
５２・・・データベース
５３・・・処理ユニット
５５・・・予約システム
５６・・・判定ユニット
５７・・・表示・連絡ユニット
Ｍ・・・表示手段／モニタ
【技術分野】
【０００１】
本発明は、施設（例えば病院等）内における人の流れや物の流れを解析するためのシステムに関する。より詳細には、本発明は、病院その他の種々の施設内における人や物の流れを解析して、当該人や物の流れが滞留する（ボトルネックが生じる）ことを未然に防止して、当該人や物の流れを効率化するためのシステムに関する。
【背景技術】
【０００２】
従来、病院内における患者の行動把握は行われておらず、個々の患者の「５Ｗ１Ｈ」、即ち、「誰が、何時、何処（受付、待合室、診察室、検査室？）で、何（例えば、受付を済ませて待っているのであれば診察待ち、診察を済ませて検査を待っているのであれば検査待ち）を、何故、どれ程（経過時間として、受付を済ませてから１時間待っている云々）行っているか」を把握する術はなかった。
尚、近年、痴呆患者の放浪癖に対応するため、居場所確認のためのモニタリング・システムは開発されてはいる。しかし、このシステムは一般患者全体をモニタリングし、病院全体の状況を把握したり、過去のデータを蓄積して今後を予測したりすることに利用するものではない。
【０００３】
また、病院側及び／又は患者側の要請として、一般患者の動向のモニタリングによる待ち時間の把握及びその短縮がある。
【０００４】
これまでは、病院内の混雑の度合いや待ち時間などを管理するツールは無く、看護師の目視観察によって概要のみ把握されていた。
【０００５】
待ち時間短縮のため、診察時間の予約制度を敷いている病院もあるが、これは統計的な個々の患者の診察データに基づくものではなく、単に一定時間内に一定の患者数を診察できるものとして予約を取っており、個々の患者の診察時間までを考慮したものではない。したがって、そのような予約制度があっても長時間に亘って待たされることが多く、患者側には大きな不満が存在するのが現状である。
【０００６】
上述のように、個々の患者の５Ｗ１Ｈが把握出来ないために、例えば、待合室の患者で順番が来ても、その時トイレ等で中座していて、順番が来たことを確認できず、例えば、急患を先にし、不急の患者（トイレに行った患者）を後回しにするといった様な診察順番の入替が円滑に行われない。
現状では、受付順で各医療行為が行われ、例えば、処置に急を要する人を優先し、処置に急を要さない人は後回にするという様に、診察順序を入れ替えることは出来ない。
【０００７】
或いは、個々の患者の５Ｗ１Ｈが把握出来ないために、患者が今何をどれくらい待っているか、そして待ちの原因は何によるものかが判断出来ない。即ち、病院側は、患者の混雑の原因が診察、検査、処置、会計、或いはその他の何れであるかが分からない。したがって、病院としては改善の余地がない。
患者側としても、待ち時間が正確に把握できれば、待ち時間を有効に利用出来るが、それが分からないため、あとどれ位待てば診察や検査が出来るか、知る術が無い。
【０００８】
さらに、個々の患者の５Ｗ１Ｈが把握出来ないために、患者一人一人の診察時間、検査時間、処置時間等が把握できず、予約制を採用しても、個々の診療時間等のばらつきで、予約制による１日の時間短縮等、効率向上の精度が上がらず、依然として順番待ちや、診察や各種処理の「空き」が発生してしまう。
特に規模が大きい病院では、「待ち時間」が長いという不満が非常に強いことは、広く知られている。
【０００９】
その他の従来技術としては、ＩＤコードリーダーを発信するＩＣタグを用いて被管理者の居場所を常時把握するように構成したシステムが存在する（特許文献１）。
【００１０】
しかし、その様な従来技術では、被管理者の位置を把握することしか行っておらず、被管理者の位置データに基づいて、より効率的な或いは好感度の高い管理を行うという発想は無く、上述した様な種々の問題点を解消するものではなかった。
【特許文献１】特開２００３−３２３４９０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は上述した従来技術の問題点に鑑みて提案されたものであり、管理の対象となる人や物の位置を把握して、人や物の流れの効率化を図ることが出来る様な管理システムの提供を目的としている。
【課題を解決するための手段】
【００１２】
本発明の管理システムは、管理対象物（例えば病院内の患者１、当該患者が保有するカードやバッジ、その他物流施設内を流通する物品等）に付加されたＩＣタグ（２）と、管理対象施設（例えば、病院３、市場、等）内に設けられて前記ＩＣタグ（２）から発信されるコード信号を受信し且つ受信した旨を出力する読取手段（例えば、カードリーダー４）と、制御手段（ネットワークコンピュータ５）とを有し、該制御手段（５）は、読取手段（４）から発信された信号に基づいてＩＣタグ（２）を付加された前記管理対象物（例えば患者１）の流れを解析する様に構成されていることを特徴としている（請求項１：図１）。
【００１３】
本発明において、前記管理対象施設は病院（３）であり、前記制御手段（ネットワークコンピュータ５）は、読取手段（カードリーダー４から発信された信号に基づいて、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う部署（診療室３２、検査室３３等）における待ち時間を演算するように構成されているのが好ましい（請求項２：図１０、図１１）。
【００１４】
ここで、前記制御手段（ネットワークコンピュータ５）は、読取手段（４）から発信された信号に基づいて、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）に必要な時間（診療時間の予測値）を求めるように構成されているのが好ましい（請求項３：図３、図４）。
【００１５】
そして本発明において、前記制御手段（ネットワークコンピュータ５）は、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う待ち時間（或いは、その演算結果）が最も少なくなる様に、次回の処理に必要な時間（予約時間）を決定するように構成されているのが好ましい（請求項４：図３、図５）。
【００１６】
また本発明において、前記制御手段（ネットワークコンピュータ５）は、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う部署における待ち時間の演算結果（待ち時間として演算された結果の数値）が所定時間（所定値）以上であれば、当該個人（１）に対して実施される処理における待ち時間の演算結果の合計が少なくなる様に当該処理の順序を変更する制御を実行する様に構成されているのが好ましい（請求項５：図８、図９）。
【００１７】
或いは本発明において、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）を行う部門（診察室３２、検査室３３等）における待ち時間が所定時間（許容待ち時間）を超えた場合には、他の部門（検査室３３、処置室３４等）で作業を行うスタッフ（医者、看護師、検査技師等）を、当該部門（診察室３２、検査室３３等）のスタッフとして配置する制御を行う様に構成されているのが好ましい（請求項６：図１２、図１３）。
【００１８】
本明細書において、「コンピュータ」なる文言は、情報処理能力を有する全ての機器を意味する包括的な文言として使用されている。
【発明の効果】
【００１９】
上述する構成を具備する本発明によれば、前記ＩＣタグ（２）から発信されるコード信号を受信して管理対象物（例えば病院内の患者１、物流施設内を流通する物品）の位置を把握するのみならず、当該受信された信号に基づいて、前記管理対象物（患者１）の流れを解析する様に構成されているので、解析された結果に基いて、前記管理対象物（患者１）の流れ（人の流れや物流）が最も効率的になるように、種々の手法を実行することが出来る。
すなわち、管理対象物（患者１）を特定するのみならず、最適な処理を行うための解析用ツールとして使用することが出来る。
【００２０】
そして、本発明を例えば病院（３）に適用した場合、前記管理対象物は診療や各種処置を受ける患者（１）であり、係る患者（１）の流れを解析することにより、各部門における待ち時間を把握することが出来るので（請求項２）、いわゆるボトルネックとなっているのがどの部門であるかを決定出来る。係るボトルネックを決定出来れば、当該ボトルネックを解消する様に業務内容の改善を図ることにより、病院全体における患者（１）の待ち時間を減少して、待ち時間に対する患者（１）の不満に対処することが出来る。
換言すれば、本発明を病院に適用すれば、現在、病院に通院する人々や患者における最大の不満である「待ち時間が長い」という問題を、解消することが出来る。
【００２１】
同様に、本発明によれば、個人（入院患者、来院者等患者１）に対して実施される処理（診察、検査、その他の各種処置）に必要な時間、すなわち診療時間の予測値を求めることが出来るので（請求項３）、係る予測値を用いて、予約して来院する患者（１）の待ち時間が最も少なくなるように構成することが出来る。
その結果、従来における問題点である「予約をしても待たされる」という患者（１）の不満に対処出来る。
【００２２】
それと共に、当該予測値を活用して、診療や検査等のスケジュールを好適に決定して、来院した患者（１）の待ち時間を最も少なくすることが可能となる（請求項４）。
【００２３】
これに加えて、本発明によれば、待ち時間が所定時間（許容待ち時間）を超えた場合には、他の部門（検査室３３、処置室３４等）で作業を行うスタッフ（医者、看護師、検査技師等）を、当該部門（診察室３２、検査室３３等）のスタッフとして配置する（いわゆる「リカバリー」を行う）様に構成されているので（請求項５）、係る部門（診察室３２、検査室３３等）が待ち時間の長いボトルネックとなってしまうことを解消し或いは予防することが出来る。
【発明を実施するための最良の形態】
【００２４】
以下、添付図面を参照して、本発明の実施形態について説明する。
【００２５】
図１及び図２を参照して本発明の第１実施形態を説明する。
図１において、管理対象施設である病院３は、待合室３０と、受付３１と、診察室３２と、検査室３３と、処置室３４とに区画されている。受付３１及び各部屋３２〜３４の入口には、夫々ゲート４０が設けられ、その各ゲート４０には後述するＩＣタグの情報を読み取るカードリーダー４が備えてある。
【００２６】
前記全てのカードリーダー４は、当該システムＡの制御手段であるネットワークコンピュータ５に入力信号ラインＬｉで接続されている。また、受付３１及び各部屋３２〜３４には、モニタを備えた端末Ｐ１（受付用）、Ｐ２〜Ｐ４（各部屋用）が設置され、情報ネットワークＬｏで前記ネットワークコンピュータ５に接続されている。
尚、情報ネットワークＬｏとしては、セキュリティが万全であれば、インターネットでも可能である。又、カードリーダー４は、レジのリーダーのようなものでもよく、その他、種々の方式が有り、特に限定する趣旨ではない。
【００２７】
管理対象である当該病院３の患者には、受付を済ませた患者１全員に対してＩＣタグ２を持たせる。
このＩＣタグ２は、特定個人、即ち患者１の情報（ネットワークコンピュータ５のサーバー側に入っている）をサーバー側から引き出すための暗証番号のような特定の識別コードが記録されているＩＣチップと、アンテナとによって構成されている。
尚、図１において、符号３ｉは病院の出入り口を示す。又、ＩＣタグ２をバーコードで代替させることも可能である。
【００２８】
各部屋の端末Ｐ２〜Ｐ４では、ネットワークコンピュータ５からの情報を受け取るとともに、個々の患者の処置結果が入力される。患者一人一人の情報は、当該患者１がＩＣタグ２とともにゲート４０を通過する度に、カードリーダー４及び入力信号ラインＬｉを介してネットワークコンピュータ５に伝送される。
【００２９】
ネットワークコンピュータ５はこれらの情報を基に、個々の患者の状態をリアルタイムにモニタリングする。
ネットワークコンピュータ５は、患者毎の診察時間や処置時間、会計処理時間等のデータを蓄積する。
【００３０】
上述した構成の管理システムＡによれば、測定したデータに基づき、以下のような利用が可能となる。
（１） 端末Ｐ１〜Ｐ４に待ち患者数とともに待ち時間を表示する。端末Ｐ１〜Ｐ４に表示された結果から、病院の医師、看護師、事務会計係は、患者の待ち時間とともに待ちの理由を把握することが出来る。
患者や来訪者は、待ち時間を正確に把握して、何時呼ばれるかを正確に予測することが出来る。従って、待ち時間を有効に利用出来る。例えば、待ち時間を他の作業に振り当てることが出来る。待ち時間を正確に把握できるので、診療の順番が来た人が、中座していることが防げる。
勿論、診療の順番が来るのを事前に見計らって、予めトイレに行ける。
又、事務会計係や受付は「本日は混んでいるか？」等の電話の問い合わせに応答する必要があって、そのような場合には「患者の待ち時間及びその理由」も把握しておけば、問い合わせに対して、利便を与えられる。
（２） 時間的に余裕の無い患者を優先するなど、個々の患者のニーズに合わせて診察順を入れ替えることが出来る。
（３） 患者毎の診察、検査、処置等のフローをデータベース化することにより、通常のルート、例えば、（「診察」→「検査」→「診察」→「処置」）の順番を入れ替えることにより、待ち時間を短縮することが出来る。
【００３１】
ここで、ＩＣタグ２の携行の態様としては、一般的には患者の診察券に取付けられるものが考えられるが、診察券にＩＣタグ２を取り付けることに代えて、患者の所有する、或いは身に着けるバッジ、ブレスレッド、カードその他に取り付けても良い。
ＩＣタグ２をどの様に取り付けるかは、病院の規模により変わる。例えば、大規模病院では、診察券を流用する場合が多く、中小規模病院では、見た目の良い態様を選択する傾向である。
【００３２】
カードリーダー４の他の利用例としては、例えば、痴呆症の徘徊であれば、病院中の至るところにカードリーダー４を設置して、徘徊する患者の現在位置をリアルタイムで把握する。或いは、カードリーダー４を病院３の出入り口３ｉだけに設置して、徘徊する患者が病院を出た場合に、直ちに対処出来るようにすることも可能である。
【００３３】
第１実施形態の作用効果を以下に記す。
（１） 患者がどの時間帯に何処でどんな理由によって待たされているか、データが自動採取出来る。また、そのデータを分析することにより、ネック工程や空時間（アイドル時間）等、経営工学的手法による問題解決のためのデータとして利用出来る。
（２） 患者が何処でどんな理由で待っているか把握出来るので、待ちの原因や夫々の工程の空き状況によって、検査の順番を入れ替える等の工程変更を行えば、空時間の有効活用が出来る。
（３） 従来の方法では診察可能な患者の総数を増すことは不可能であったが、本実施形態の管理システムＡを活用すれば、空時間の有効活用により、正味の診察時間を削ることなく診察可能な患者数を増やすことが出来る。
（４） 患者の居場所が把握出来るので、スピーカーによるアナウンス等、患者呼び出し時間が短縮出来る。
（５） 予約制を強いている場合、個々の患者における過去の情報（平均診察時間や検査の要否、時間的余裕の有無等）から、予約時間の精度を高めることが出来る他、急ぎの患者を優先させる等、個人個人の事情に合った対応が可能となる。
（６） 本発明の第１実施形態によれば、病院３側は、患者１の混雑の原因が、診察か、検査か、会計か、その他かが把握出来る。そして、混雑要因を特定すれば、病院として、混雑の改善が可能となる。
従来は、例えば、診察に時間が掛かっているのに、会計処理を改善するようなことが行われているような例があったが、本発明によれば、その様な「意味のない；場違いな」改善を行うことが無くなる。
すなわち、本発明の第１実施形態によれば、待ち時間に関するデータを取得することにより、「混雑」解消のための適切な改善策が立案出来る。
【００３４】
図２に基づいて、第１実施形態におけるネットワークコンピュータ５の構成と、ＩＣタグ２を用いて情報を収集する態様をより詳細に説明する。
【００３５】
図２において、ネットワークコンピュータ５は、病院内の管理ポイント毎に配置された全てのカードリーダー４と接続され、カードリーダー４を経由して、患者１の所持するＩＣタグ２からデータ収受を行うインターフェース５１と、そのインターフェース５１で収受したデータを記憶するデータベース５２と、データベースに記憶されたデータに基づいて、各種演算、例えば、患者１が病院３内で消費した待ち時間の合計の計算や、統計データ分析、例えば、待ちの原因分析処理を行う処理ユニット５３とによって構成されている。
前記処理ユニット５３は、病院３内の管理ポイント毎に設置された端末Ｐ１〜Ｐ４と接続され、その端末のモニタＭによって、処理の内容、例えば現在受付を済ませた患者の待ち時間等を表示する。
尚、図２では患者１、ＩＣタグ２、病院３、端末Ｐ１〜Ｐ４は省略している。
【００３６】
即ち、当該ネットワークコンピュータ５では、対象とする患者１にＩＣタグ２を所持させ、病院３内の管理ポイント毎に設置したカードリーダー４から、各患者１の所持するＩＣタグ２の各管理ポイント経過時間を時系列的に測定し、作業分析のデータとして活用している。
【００３７】
個々の患者１について、ストップウォッチやビデオ撮影などの手段により計測するのが、従来のタイムスタディ（改善の前段階の計測）であった。
それに対して、図２で示す様なシステム（ネットワークコンピュータ５）であれば、その様なタイムスタディを自動化できる。換言すれば、図２のシステムによれば、作業改善のためのデータ取り（タイムスタディ）を自動的に集計できる。そして、図２で示す様なシステム（ネットワークコンピュータ５）を採用すれば、患者１のみならず、看護師、医師、事務方の一人、検査技師、一人の動きをＩＣタグ２でチェックして、データが取れる。
また、過去の診療データ等と組み合わせることにより、ジャストインタイムで、且つ、精度の高い（待ち時間が短い）予約を行うことが可能となる。
【００３８】
図３〜図７で示す第２実施形態は、図１及び図２を参照して説明した第１実施形態を応用した予約に関する技術に係るものである。
【００３９】
図３は、第１実施形態を予約システムに適用した場合の、図１のネットワークコンピュータ５の機能ブロック図として示したものである。
ネットワークコンピュータ５Ａ（図３では、図２と符合を違えている）以外の第２実施形態に係る予約システムは、図１のシステムをそのまま利用している。
換言すれば、図１のネットワークコンピュータ５の構成例の一つ及びその制御例（４種類の処理）が、図３〜図７で示す第２実施形態である。
【００４０】
先ず、図３において、第２実施形態のネットワークコンピュータ５Ａは、各カードリーダー４と接続されたインターフェース５１と、データベース５２と、処理ユニット５３と、予約スケジューリング５４を備えた予約システム５５とを有している。
【００４１】
前記予約システム５５は、受付３１（図１参照）の端末Ｐ１と接続しており、予約情報や予約の問い合わせ、スケジュールの問い合わせ、急患等の緊急割り込みに対応している。
又、予約システム５５の予約スケジューリング５４は受付３１の端末Ｐ１と接続して、ネットワークコンピュータ５で設定した予約スケジュールを、受付３１のモニタＭ及び待合室３０のモニタＭに表示する。
【００４２】
次に、図４及び図５に基づいて、個々の患者の診療時間を予測する処理方法について説明する。
【００４３】
先ずデータベース５２側の処理として、ステップＳ１では、カードリーダー４により、ネットワークコンピュータ５Ａのインターフェース５１を経由して、ＩＣタグ２による患者１（図１参照）全体のデータの受信を行う。
【００４４】
次のステップＳ２では、患者個人毎にデータを分析して、ステップＳ３に進み患者各個人の診察時間（診察予測時間）を予測する。
【００４５】
次に、予約システム５５側の処理として、図５において、先ずステップＳ４で、ネットワークコンピュータ５Ａは、予約の申し込みがあるまで待機しており（ステップＳ４のループ）、申し込みがあれば（ステップＳ４のＹＥＳ）、ステップＳ５に進む。
【００４６】
ステップＳ５では、予約者及び予約希望時間を入力した後、ステップＳ６に進み、予想診療時間を決定し、ステップＳ７に進む。
【００４７】
ステップＳ７では、ネットワークコンピュータ５Ａは予約希望時刻から予想診療時間に他の予約と重複するか否かを判断しており、重複していれば（ステップＳ７のＹＥＳ）、ステップＳ８に進み、当該予約希望時刻が不可であることを最寄りの表示手段に出力しステップＳ５まで戻り、再びステップＳ５以降を繰り返す。
【００４８】
一方、重複していなければ（ステップＳ７のＮＯ）、ステップＳ９に進み、当該予約希望時刻がＯＫであることを出力して制御を終える。
【００４９】
上述のように、個々の患者における診療時間の予測値を求め、係る予測値を参照することにより、予約時間丁度に来院した患者の待ち時間を出来る限り短くすることが可能となる。
具体的には、図４のステップＳ１において、ＩＣタグ２がカードリーダー４を通過する毎にデータを発信することにより、個々の患者がどの様な診察或いは処置を受け、当該診察或いは処置にどの位の時間を要したかが、データとしてデータベース５２に蓄積される。
【００５０】
係るデータを、個人毎にまとめることにより、次回の来院或いは次回の処置は、どの部門から始め、どのような順序で進めたほうがよいかが予想できる。この予想は、診療或いは処置を行った医師や技師の側から入力することも可能である。それと共に、次回に受診或いは対象となる診療や処置に要する時間を、過去のデータから推定することも可能となる。
【００５１】
予約の際には、予約した本人について、予想される診療或いは処置に要する時間の予測値（図５のステップＳ６の処理で求まる：図３の矢印ａ）と、前後の患者の診療或いは処置に要する時間の予測値（これも、図５のステップＳ６の処理で求まる：図３の矢印ａの処理）とを参照して、出来る限り待ち時間が短くなるような組み合わせを演算している。
係る演算は、統計処理上の公知手法を用いることで、処理ユニット（図３の５３）で実行可能である。
これにより、次回の予約を決定することが出来る。
【００５２】
図３〜図５の実施形態は、次回の診療や処置の予約のためのシステムであるが、受付の段階における処理にも適用できる。
すなわち、図５で予約時間を決定するに際して、診療や処置のために来院した患者或いは入院している患者のその日における診療や処置を、出来る限り待ち時間が少なくなる様に、効率的に行う様に設定しているので、受付の段階で、当該効率的に設定された診療や処置についてのスケジュールを、当該患者に知らせれば良い。
【００５３】
具体的には、受付の段階において、図３で示す様に、受付３１の端末Ｐ１（図１参照）からネットワークコンピュータ５Ａの予約システム５５にスケジュールの問い合わせを行い、予約システム５５から受付３１の端末Ｐ１に予約スケジュール情報を出力する。
受付３１の端末Ｐ１では、出力された予約スケジュール、すなわち効率的に設定された診療や処置についてのスケジュールを表示する。
係る処理を示すのが、図６である。
【００５４】
図６に基づいて、係る処理方法を説明する。
先ず、ステップＳ１１では、ネットワークコンピュータ５Ａは、受付３１の端末Ｐ１からスケジュールの問い合わせがあったか否かを判断しており、問い合わせがあれば（ステップＳ１１のＹＥＳ）、ステップＳ１２に進み、一方、問い合わせが無ければ（ステップＳ１１のＮＯ）、ステップＳ１１のループを繰り返す。
【００５５】
ステップＳ１２では、当該患者１のスケジュールを予約システム５５より出力して制御を終える。
【００５６】
ここで、スケジュールの表示は、図３では図示しない端末（或いはディスプレイ）等で、病院内の随所で行う様に構成することが出来る。
【００５７】
ここで、事故、急病等、救急患者すなわち診療や処理に緊急性のある患者が発生する場合がある。かかる場合には、診療や処理を速やかに行わないと、命に関わる事態が想定される。
即ち、そのような場合には、図４〜図６にかかわらず、直ちに診療や処理が必要となる。
【００５８】
その様な救急患者の場合は、緊急のタグを与えて処理する。具体的には、救急患者等、処置に急を要する人を優先し、処置に急を要さない人は順番を後に回しても良い。
上述の処理を、図７に基づいて説明する。
【００５９】
先ず、緊急患者の容態を診て、緊急タグ（図示しない）を付与するか否かを判断して、付与するのであれば（ステップＳ２１のＹＥＳ）、ステップＳ２２に進み、付与しないのであれば（ステップＳ２１のＮＯ）、前述の図４〜図６の処理へ移る。
【００６０】
ステップＳ２２では、緊急タグを付与した患者の処置を最優先とし、次のステップＳ２３では、緊急タグを付与した旨を予約システム５５に送信し、ステップＳ２４で予約スケジュールを変更して処理を終える。
【００６１】
上述したように、救急患者が存在することにより、既に予定されたスケジュールは変動する。その様な場合には、処理ユニット５３及び予約システム５５で、緊急タグが付与された状態において、改めて待ち時間が最小となる予約スケジュールを計算し、必要に応じて予約スケジュールを変更することが出来る。予約スケジュールの変更では、患者の待ち順番の入れ換えが行われる。
【００６２】
ここで、或る患者の診療における処置の順序を入れ換える（例えば、第１及び第２の検査が必要な患者がいた場合、第１の検査が混雑していて、第２の検査が空いている場合、第２の検査から受診させる様に案内する）ことも可能である。
その詳細については、以下の第３実施形態で述べる。
【００６３】
図７で述べたとおり、本発明の実施形態では、待ち時間が少なくなる様に効率的に設定された診療や処置についてのスケジュールである予約スケジュールが、受付時に表示可能である様に構成されている。
しかし、種々の診療や処理が、予測されたのとは異なってしまう場合もある。その様な場合、予約スケジュールを出力されていたとしても、待ち時間が長時間となってしまう場合がある。勿論、係る予約スケジュールが出力されていない場合には、更に待ち時間の長期化を招き問題を大きくしてしまう。
【００６４】
その様な場合において、待ち時間が長い診察や処理を後回しにすることにより、診療や処理全体に費やされる時間を短縮出来る場合がある。
図８及び図９の第３実施形態はその様な状態に対処するための手法である。
【００６５】
図８及び図９に基づいて、第３実施形態を説明する。
【００６６】
先ず、図８において、第３実施形態のネットワークコンピュータ５Ｂは、各カードリーダー４と接続されたインターフェース５１と、データベース５２と、処理ユニット５３と、判定ユニット５６とを有している。
【００６７】
前記判定ユニット５６は、表示・連絡ユニット５７と接続している。
ここで、表示連絡ユニット５７は、受付３１（図１参照）或いは各部屋３１〜３４の端末Ｐ１〜Ｐ４のモニタＭとしても良い。
【００６８】
前記処理ユニット５３では、或る患者の診療における処置の順序を入れ換えた場合の科目別、経路別の待ち時間を計算し直し、その情報を判定ユニット５６に送信して（図８のａの経路）、判定ユニット５６は入替が「ＯＫ」の場合の結果を表示・連絡ユニット５７で表示する。
尚、判定ユニットで「ＮＧ」と判断された場合は、「ＮＧ」であったことを処理ユニット５３にフィードバックして（ｂの経路）、処理ユニット５３は再び別の計算を行う。
【００６９】
次に、図９に基づいて、係る処理の流れを説明する。
【００７０】
先ず、ステップＳ３１では、ＩＣタグ２によるデータを受信し、次のステップＳ３２では、診察順序及び予約待ち時間を決定して、ステップＳ３３に進む。
【００７１】
ステップＳ３３では、処理ユニット５３で、入れ替えた場合の予約待ち時間を演算し、その値が所定値以下か否かを判断する。所定値以下であれば（ステップＳ３３のＹＥＳ）、ステップＳ３７まで進み、所定値を超えていれば（ステップＳ３３のＮＯ）、ステップＳ３４に進む。
【００７２】
ステップＳ３４では、判定ユニット５６で、他の部門と順番を変更することが可能か否かを判断しており、可能であれば（ステップＳ３４のＹＥＳ）、ステップＳ３５に進み、変更出来なければ（ステップＳ３４のＮＯ）、ステップＳ３７まで進む。
【００７３】
ステップＳ３５では、判定ユニット５６は、変換した部門の予想待ち時間が所定値以下であるか否かを判断しており、所定値以下であれば（ステップＳ３５のＹＥＳ）、次のステップＳ３６に進む。一方、所定値を超えていれば（ステップＳ３５のＮＯ）、ステップＳ３４に戻り、再びステップＳ３４以降を繰り返す。
【００７４】
ステップＳ３６では、変換した部門を次の診察部門に決定し、ステップＳ３７に進み、診察順番を最寄りの表示・連絡手段５７に表示・連絡して処理を終える。
【００７５】
上述したように、第３実施形態の処理では、待ち時間が長い診察や処理を後回しにすることにより、診療や処理全体に費やされる時間を短縮出来る。
【００７６】
図８及び図９の第３実施形態は、第１実施形態及び／又は第２実施形態と組み合わせて実施することが可能である。
【００７７】
次に、図１０及び図１１を参照して、第４実施形態を説明する。図１０及び図１１の第４実施形態は、待ち時間の管理に関する実施形態である。
【００７８】
先ず、図１０において、第４実施形態のネットワークコンピュータ５Ｃは、各カードリーダー４と接続されたインターフェース５１と、データベース５２と、処理ユニット５３と、待機時間出力手段５８とを有している。
【００７９】
前記待機時間出力手段５８は、各端末Ｐ１〜Ｐ４のモニタＭと接続している。
【００８０】
次に、図１１に基づいて、第４実施形態の処理の流れを説明する。
【００８１】
ステップＳ４１では、第１実施形態〜第３実施形態と同様に、カードリーダー４によりＩＣタグ２によるデータを自動的に受信して、当該データを、インターフェース５１を介してネットワークコンピュータ５Ｃのデータベース５２に一旦記憶する。
【００８２】
処理装置５３では、ステップＳ４２で、前記記憶されたデータを引き出し、そのデータを各科目毎にデータ分析する。そして、次のステップＳ４３では、当該データに基づいて、各管理ポイント毎の待ち時間を処理装置５３で算出し、ボトルネックとなっている行程の割り出し、待ち時間の決定、待ち時間の時系列的推移状況の決定等を行う。
待ち時間の時系列的推移状況とは、時間が経過すれば、待ち時間が増加（減少）する等の傾向を指す。
【００８３】
ここで、ボトルネックとなっている行程の割り出し、待ち時間の決定、待ち時間の時系列的推移状況の決定（ステップＳ４３）は、ＩＣタグ２によるデータを各科目（病院であれば、各医局、各診療室、各検査室）毎に整理して、公知の統計処理上の各種手法を用いることにより行われる。当該統計処理上の手法については、説明を省略する。
【００８４】
ボトルネックとなっている行程の割り出しが出来れば、当該行程に医師や看護師を多数配置したり、当該行程における診療や処置を後回しにする様に患者を誘導したり、当該行程における担当の医師や看護師等に対してボトルネックとなっている旨を通知する等、各種の手法により、ボトルネックを積極的に解消することが可能である。
【００８５】
次のステップＳ４４に進み、ネットワークコンピュータ５Ｃは、以上の結果の表示要求があるか否かを判断して、表示要求があれば（ステップＳ４４のＹＥＳ）、ステップＳ４５でモニタＭによって表示した後処理を終える。一方、表示要求が無ければ、（ステップＳ４４のＮＯ）、そのまま処理を終える。
【００８６】
図１０及び図１１の第４実施形態では、待ち時間が決定されれば、各部門における待ち時間を比較することにより、ボトルネックが特定できる。
また、待ち時間が長い部門に対して、医師や看護師を多数配置したり、当該部門の診療や処置を後回しにする様に患者を誘導したり、当該部門の担当者（医師や看護師や技師）に対して待ち時間が長くなっている旨を通知する等により、ボトルネックの発生を未然に防止する措置を取ることが可能となる。
そして、待ち時間の時系列的推移状況が決定出来る場合も、ボトルネックの発生を事前に予見出来る。
さらに、ボトルネック解消のために患者等を誘導するに際して、図１０で示すモニタＭでスケジュールを表示することが出来る。
【００８７】
第４実施形態は、第１実施形態〜第３実施形態と組み合わせて実施することが可能である。
【００８８】
ボトルネックの発生を未然に防止するため、或いは、発生してしまったボトルネックを解消するために、担当の医師や看護師や技師を増員する制御について、以下、図１２及び図１３の第５実施形態で詳細に説明する。
【００８９】
同一の処理或いは診療を行う部門（医師や看護師や技師等の個人を含む）が複数存在する場合に、一方の部門の待ち時間が長く、他方の待ち時間が短い場合に、待ち時間が短い方の担当者（スタッフ）に、待ち時間が長い方の応援をさせ、以って、待ち時間の均等化を図るのが、図１２及び図１３のリカバリーシステムである。
【００９０】
図１２において、第５実施形態のネットワークコンピュータ５Ｄは、第３実施形態のネットワークコンピュータ５Ｂとベースが同様であるが、処理ユニット５３及び判定ユニット５６が各端末Ｐ１〜Ｐ４と接続されていることが異なる。
【００９１】
図１３に基づいて、第５実施形態の処理の流れを説明する。
【００９２】
先ず、ステップＳ５１において、ネットワークコンピュータ５Ｄは、待ち時間が許容値以上の部門がある、及び／又はリカバリーの要請があるかを判断しており、待ち時間が許容値以上の部門がある、及び／又はリカバリーの要請がある場合は（ステップＳ５１のＹＥＳ）、ステップＳ５２に進む。一方、待ち時間が許容値以上の部門がない、及び／又はリカバリーの要請が無い場合は（ステップＳ５１のＮＯ）、あるまで、ステップＳ５１のループを繰り返す。
【００９３】
ステップＳ５２では、当該部門に他のスタッフが存在するか否かを判断しており、存在すれば（ステップＳ５２のＹＥＳ）、ステップＳ５３に進み、存在しなければ（ステップＳ５２のＮＯ）、ステップＳ５６に進む。
【００９４】
ここで、リカバリーするべき他のスタッフが存在しないような部門については、リカバリー自体が不可能である。従ってステップＳ５６では、リカバリーが不可能であることを、待ち時間が所定以上の部門及び／又はリカバリーの要請をした部門へ連絡した後、処理を終える。
【００９５】
また、或る部門のスタッフが他の部門のリカバリーに行った結果、今度は、その部門がボトルネックとなってしまうことは防止する必要がある。そのため、ステップＳ５３では、他のスタッフが存在する部署の待ち時間を入力して、その部署のリカバリー後の待ち時間を演算する。
【００９６】
次のステップＳ５４では、演算した待ち時間が所定値未満であれば（ステップＳ５４のＹＥＳ）、当該スタッフにリカバリー要請を連絡した後、処理を終える。
【００９７】
スタッフを他の部門に回した結果、その部門の待ち時間が一定時間よりも長くなってしまうような演算結果が得られた場合には、当該部門からスタッフを他の部門の応援に出すことはしない。そこで、待ち時間が所定値を超えてしまったなら（ステップＳ５４のＮＯ）、ステップＳ５２まで戻り、再びステップＳ５２以降を繰り返す。
【００９８】
すなわち、第５実施形態では、病院全体として、待ち時間が短くなるように、設定されている。
【００９９】
また、第５実施形態は、第１実施形態〜第４実施形態と組み合わせて実施することが可能である。
【産業上の利用可能性】
【０１００】
図示の実施形態では、病院を例示しているが、本発明の適用は、病院のみに限定されるものではなく、遊園地や役所等、多数の人が訪れて、順番待ちの時間の存在が問題になる様な施設の全てについて、本発明が適用可能である。
或いは、人にＩＣタグを付加する場合のみならず、対象とする物にＩＣタグを装着させ、ＩＣタグリーダー（カードリーダー）を施設内の管理ポイント毎に設置し、各管理ポイント経過時間を時系列的に測定し、物流分析のデータとして活用することも可能である。
【０１０１】
すなわち、図示の実施形態はあくまでも例示であり、本発明の技術的範囲を限定する趣旨ではない。
【図面の簡単な説明】
【０１０２】
【図１】本発明の第１実施形態の管理システム全体の構成を示したブロック図。
【図２】第１実施形態のネットコンピュータの構成を示したブロック図。
【図３】本発明の第２実施形態に関するネットコンピュータの構成を示したブロック図。
【図４】本発明の第２実施形態のネットコンピュータのデータベース側における予約処理の流れを説明するフローチャート。
【図５】本発明の第２実施形態のネットコンピュータの予約システム側における予約処理の流れを説明するフローチャート。
【図６】本発明の第２実施形態に係り、スケジュールの問合せが有った場合の処理方法を示したフローチャート。
【図７】本発明の第２実施形態に係り、緊急性のある患者が発生した場合の処理方法を示したフローチャート。
【図８】本発明の第３実施形態に関するネットコンピュータの構成を示したブロック図。
【図９】本発明の第３実施形態に係り、ある患者の医療処置の順番を入れ替える場合の処理方法を示したフローチャート。
【図１０】本発明の第４実施形態に関するネットコンピュータの構成を示したブロック図。
【図１１】本発明の第４実施形態に係り、待ち時間の管理方法を示したフローチャート。
【図１２】本発明の第５実施形態に関するネットコンピュータの構成を示したブロック図。
【図１３】本発明の第５実施形態に係り、発生してしまったボトルネックを解消するため、医師や看護師や技師を増員する制御方法を示したフローチャート。
【符号の説明】
【０１０３】
１・・・管理対象物／患者
２・・・ＩＣタグ
３・・・管理対象施設／病院
４・・・カードリーダー
５、５Ａ、５Ｂ、５Ｃ、５Ｄ・・・ネットワークコンピュータ
３０・・・待合室
３１・・・受付
３２・・・診察室
３３・・・検察室
３４・・・処置室
４０・・・ゲート
５１・・・インターフェース
５２・・・データベース
５３・・・処理ユニット
５５・・・予約システム
５６・・・判定ユニット
５７・・・表示・連絡ユニット
Ｍ・・・表示手段／モニタ
【特許請求の範囲】
【請求項１】
管理対象物に付加されたＩＣタグと、管理対象施設内に設けられて前記ＩＣタグから発信されるコード信号を受信し且つ受信した旨を出力する読取手段と、制御手段とを有し、該制御手段は、読取手段から発信された信号に基いてＩＣタグを付加された前記管理対象物の流れを解析する様に構成されていることを特徴とする管理システム。
【請求項２】
前記管理対象施設は病院であり、前記制御手段は、読取手段から発信された信号に基づいて、個人に対して実施される処理を行う部署における待ち時間を演算するように構成されている請求項１の管理システム。
【請求項３】
前記制御手段は、読取手段から発信された信号に基づいて、個人に対して実施される処理に必要な時間を求めるように構成されている請求項２の管理システム。
【請求項４】
前記制御手段は、個人に対して実施される処理を行う待ち時間が最も少なくなる様に、次回の処理に必要な時間を決定するように構成されている請求項２、３の何れかの管理システム。
【請求項５】
前記制御手段は、個人に対して実施される処理を行う部署における待ち時間の演算結果が所定時間以上であれば、当該個人に対して実施される処理における待ち時間の演算結果の合計が少なくなる様に当該処理の順序を変更する制御を実行する様に構成されている請求項２〜４の何れか１項の管理システム。
【請求項６】
個人に対して実施される処理を行う部門における待ち時間が所定時間を超えた場合には、他の部門で作業を行うスタッフを、当該部門のスタッフとして配置する制御を行う様に構成されている請求項２〜５の何れか１項の管理システム。
【請求項１】
管理対象物に付加されたＩＣタグと、管理対象施設内に設けられて前記ＩＣタグから発信されるコード信号を受信し且つ受信した旨を出力する読取手段と、制御手段とを有し、該制御手段は、読取手段から発信された信号に基いてＩＣタグを付加された前記管理対象物の流れを解析する様に構成されていることを特徴とする管理システム。
【請求項２】
前記管理対象施設は病院であり、前記制御手段は、読取手段から発信された信号に基づいて、個人に対して実施される処理を行う部署における待ち時間を演算するように構成されている請求項１の管理システム。
【請求項３】
前記制御手段は、読取手段から発信された信号に基づいて、個人に対して実施される処理に必要な時間を求めるように構成されている請求項２の管理システム。
【請求項４】
前記制御手段は、個人に対して実施される処理を行う待ち時間が最も少なくなる様に、次回の処理に必要な時間を決定するように構成されている請求項２、３の何れかの管理システム。
【請求項５】
前記制御手段は、個人に対して実施される処理を行う部署における待ち時間の演算結果が所定時間以上であれば、当該個人に対して実施される処理における待ち時間の演算結果の合計が少なくなる様に当該処理の順序を変更する制御を実行する様に構成されている請求項２〜４の何れか１項の管理システム。
【請求項６】
個人に対して実施される処理を行う部門における待ち時間が所定時間を超えた場合には、他の部門で作業を行うスタッフを、当該部門のスタッフとして配置する制御を行う様に構成されている請求項２〜５の何れか１項の管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００６−２６８４０４（Ｐ２００６−２６８４０４Ａ）
【公開日】平成１８年１０月５日（２００６．１０．５）
【国際特許分類】
【出願番号】特願２００５−８５２９４（Ｐ２００５−８５２９４）
【出願日】平成１７年３月２４日（２００５．３．２４）
【出願人】（０００１１０２５１）トピー工業株式会社 (255)
【Ｆターム（参考）】
【公開日】平成１８年１０月５日（２００６．１０．５）
【国際特許分類】
【出願日】平成１７年３月２４日（２００５．３．２４）
【出願人】（０００１１０２５１）トピー工業株式会社 (255)
【Ｆターム（参考）】
[ Back to top ]