(57)【要約】【課題】複数の処置実行者が院内に散在する場合であっても、生体に対する処置の要請及び処置の開始を短時間で報知し、院内業務を効率化することができる院内業務サポートシステム、及び、院内業務サポートサーバを提供する。【解決手段】院内業務サポートシステム１００は、生体４に対する処置に関する監視要素の状態を検知する検知器２と、生体４に対して処置を行う処置実行者５に携帯される複数の端末装置３と、検知器２及び端末装置３に対して通信可能に接続された院内業務サポートサーバ１と、を有している。院内業務サポートサーバ１は、検知器２からの検知信号に基づいて監視要素の状態が正常及び異常の何れであるかを判定し、判定結果が異常である場合、生体４に対する処置を要請する処置要請信号を端末装置３に送信し、端末装置３のうち何れかから応答信号を受信したときに、端末装置３に処置開始信号を送信する。【選択図】図１
2016154780.tif 000002
【特許請求の範囲】
【請求項１】
生体に対する処置に関する監視要素の状態を検知する検知器と、
前記生体に対して処置を行う処置実行者に携帯される複数の端末装置と、
前記検知器及び前記端末装置に対して通信可能に接続された院内業務サポートサーバと、を有しており、
前記院内業務サポートサーバは、
前記検知器からの検知信号に基づいて前記監視要素の状態が正常及び異常の何れであるかを判定する状態判定部と、
前記状態判定部における判定結果が異常である場合、前記生体に対する処置を要請する処置要請信号を前記端末装置に送信し、前記端末装置のうち何れかから応答信号を受信したときに、前記端末装置に処置開始信号を送信する通信制御部と、を有することを特徴とする院内業務サポートシステム。
【請求項２】
前記院内業務サポートサーバの前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常に基づいて選択した前記端末装置に対して前記処置要請信号を送信することを特徴とする請求項１に記載の院内業務サポートシステム。
【請求項３】
前記院内業務サポートサーバは、前記監視要素の種類と、各種類に対応付けられたサポート優先度とを記憶するサポート優先度記憶部をさらに有し、
前記院内業務サポートサーバの前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常の前記監視要素の種類に対応付けられた前記サポート優先度に基づいて選択した前記端末装置に対して前記処置要請信号を送信することを特徴とする請求項２に記載の院内業務サポートシステム。
【請求項４】
前記院内業務サポートサーバは、前記端末装置と前記端末装置を携帯する処置実行者の種別とを関連付けて記憶する処置実行者種別記憶部をさらに有し、
前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常を処置可能な前記処置実行者の種別の前記処置実行者が携帯する前記端末装置を選択して前記処置要請信号を送信することを特徴とする請求項２又は３に記載の院内業務サポートシステム。
【請求項５】
前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常に基づいて要請範囲を決定し、当該要請範囲に位置する前記端末装置に前記処置要請信号を送信することを特徴とする請求項２乃至４の何れか１項に記載の院内業務サポートシステム。
【請求項６】
前記院内業務サポートサーバにおける前記通信制御部は、
前記端末装置のうち何れかから処置完了信号を受信したときに、前記端末装置に処置完了信号を送信することを特徴とする請求項１に記載の院内業務サポートシステム。
【請求項７】
前記院内業務サポートサーバにおける前記通信制御部は、
前記状態判定部における判定結果が異常から正常に復帰した場合、前記端末装置に処置完了信号を送信することを特徴とする請求項１に記載の院内業務サポートシステム。
【請求項８】
前記院内業務サポートサーバにおける前記通信制御部は、
前記端末装置のうち何れかから処置完了信号を受信し、且つ、前記状態判定部における判定結果が異常から正常に復帰した場合、前記端末装置に処置完了信号を送信することを特徴とする請求項１に記載の院内業務サポートシステム。
【請求項９】
前記生体が複数存在しており、
前記通信制御部は、
前記状態判定部における異常の判定結果の生体が複数存在する場合、これら生体の中から前記サポート優先度の高い監視要素の処置を受けている生体を特定し、特定した生体に対する処置を要請する処置要請信号を前記端末装置に送信することを特徴とする請求項３乃至６の何れか１項に記載の院内業務サポートシステム。
【請求項１０】
前記院内業務サポートサーバにおける前記通信制御部は、さらに、
前記状態判定部における異常の判定結果の全ての生体について、前記監視要素の種類及び前記サポート優先度の少なくとも一方を示すサポート内容信号を前記端末装置に送信することを特徴とする請求項９に記載の院内業務サポートシステム。
【請求項１１】
生体に対する処置に関する監視要素の状態を検知する検知器と、前記生体に対して処置を行う処置実行者に携帯される複数の端末装置と、を有した院内業務サポートシステムの院内業務サポートサーバであって、
前記検知器及び前記端末装置に対して通信可能に接続された通信部と、
前記検知器からの検知信号に基づいて前記監視要素の状態が正常及び異常の何れであるかを判定する状態判定部と、
前記状態判定部における判定結果が異常である場合、前記生体に対する処置を要請する処置要請信号を前記端末装置に送信し、前記端末装置のうち何れかから応答信号を受信したときに、前記端末装置に処置開始信号を送信する通信制御部と、
を有することを特徴とする院内業務サポートサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、院内業務サポートシステム、及び、院内業務サポートサーバに関する。
【背景技術】
【０００２】
従来、病院等の院内における患者等の生体が、ベッド近傍などに設けられたナースコール子機を操作することや、生体に設置されて状態を監視する医療デバイスがアラートを発生させることにより、医療従事者の居るスタッフルームなどに設置されたナースコール親機や、医療従事者が携行するＰＨＳ等の携帯通信端末を動作させて呼び出しを報知するナースコールシステムがある。
【０００３】
例えば、特許文献１には、医療従事者の病室への入退室を検出し、病室に入っていない医療従事者の数が所定の数以上である場合には、病室に入っていない医療従事者が携行する携帯通信端末によって音や振動による報知を行わせ、病室に入っている医療従事者が携行する携帯通信端末によって音や振動による報知を行わせないようにし、病室に入っていない医療従事者の数が所定の数よりも少ない場合には、病室に入っていない医療従事者が携行する携帯通信端末だけでなく、病室に入っている医療従事者が携行する携帯通信端末によっても音や振動による報知を行わせるようにしたナースコールシステムが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５０９９９１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来では、呼び出された医療従事者は、ナースコール子機のある病室へ到着するまで、既に他の医療従事者が対応しているか否かがわからないため業務の効率を低下させるものであった。また、同時に複数の呼び出しが発生した場合、ある病室への医療従事者の到着が集中してしまい、他の呼び出し元の病室への到着が遅れてしまう虞があった。
【０００６】
本発明は、上記の問題を鑑みてなされたものであり、複数の処置実行者が院内に散在する場合であっても、生体に対する処置の要請及び処置の開始を短時間で報知し、院内業務を効率化することができる院内業務サポートシステム、及び、院内業務サポートサーバを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の院内業務サポートシステムは、生体に対する処置に関する監視要素の状態を検知する検知器と、前記生体に対して処置を行う処置実行者に携帯される複数の端末装置と、前記検知器及び前記端末装置に対して通信可能に接続された院内業務サポートサーバと、を有しており、前記院内業務サポートサーバは、前記検知器からの検知信号に基づいて前記監視要素の状態が正常及び異常の何れであるかを判定する状態判定部と、前記状態判定部における判定結果が異常である場合、前記生体に対する処置を要請する処置要請信号を前記端末装置に送信し、前記端末装置のうち何れかから応答信号を受信したときに、前記端末装置に処置開始信号を送信する通信制御部と、を有することを特徴とする。
【０００８】
上記の構成によれば、監視要素の状態が検知器の検知信号により院内業務サポートサーバに送信され、院内業務サポートサーバの状態判定部において、監視要素の良否が判定される。状態判定部における判定結果が異常である場合、処置要請信号が端末装置に送信されることによって、端末装置を携帯する処置実行者に対して生体に対する処置が要請される。そして、処置実行者が端末装置から応答信号を院内業務サポートサーバに送信すると、この信号を受信した院内業務サポートサーバが処置開始信号を前記端末装置に送信する。これにより、監視要素の状態が異常となって生体の処置が必要になった旨を端末装置を介して処置実行者に一斉に報知することができると共に、何れかの処置実行者が処置を行う旨を端末装置を介して処置実行者に一斉に報知することができる。この結果、複数の処置実行者が院内に散在する場合であっても、生体に対する処置の要請及び処置の開始を短時間で報知することができ、院内業務を効率化することができる。
【０００９】
また、本発明の院内業務サポートシステムにおいて、前記院内業務サポートサーバの前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常に基づいて選択した前記端末装置に対して前記処置要請信号を送信してもよい。
【００１０】
上記の構成によれば、通信制御部による処置要請信号の送信対象となる端末装置が検知器で発生した異常に基づいて選択される。これにより、送信が不要な端末装置に対しては送信をキャンセルできるため、院内の業務をより効率的にすることができる。
【００１１】
また、本発明の院内業務サポートシステムにおいて、前記院内業務サポートサーバは、前記監視要素の種類と、各種類に対応付けられたサポート優先度とを記憶するサポート優先度記憶部をさらに有し、前記院内業務サポートサーバの前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常の前記監視要素の種類に対応付けられた前記サポート優先度に基づいて選択した前記端末装置に対して前記処置要請信号を送信してもよい。
【００１２】
上記構成によれば、サポート優先度に応じて処置要請信号を送信する端末装置を選択できるため、院内の業務をより効率的にすることができる。
【００１３】
また、本発明の院内業務サポートシステムにおいて、前記院内業務サポートサーバは、前記端末装置と前記端末装置を携帯する処置実行者の種別とを関連付けて記憶する処置実行者種別記憶部をさらに有し、前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常を処置可能な前記処置実行者の種別の前記処置実行者が携帯する前記端末装置を選択して前記処置要請信号を送信してもよい。
【００１４】
上記の構成によれば、通信制御部による処置要請信号の送信対象となる端末装置は、検知器で発生した異常を処置可能な種別の処置実行者が携帯する端末装置であるか否かによって選択される。これにより、検知器の異常を処置可能な処置実行者のみに処置の要請が報知されるため、院内の業務をより効率的にすることができる。
【００１５】
また、本発明の院内業務サポートシステムにおいて、前記通信制御部は、前記状態判定部における判定結果が異常である場合、当該異常に基づいて要請範囲を決定し、当該要請範囲に位置する前記端末装置に前記処置要請信号を送信してもよい。
【００１６】
上記の構成によれば、通信制御部による処置要請信号の送信対象となる端末装置は、異常に基づいて決定される要請範囲に位置するか否かによって選択される。これにより、異常に基づいて必要な要請範囲に処置の要請が報知されるため、院内の業務をより効率的にすることができる。
【００１７】
また、本発明の院内業務サポートシステムにおいて、前記院内業務サポートサーバにおける前記通信制御部は、前記端末装置のうち何れかから処置完了信号を受信したときに、前記端末装置に処置完了信号を送信してもよい。
【００１８】
上記の構成によれば、複数の処置実行者が院内に散在する場合であっても、生体に対する処置の完了を短時間で報知することができる。
【００１９】
また、本発明の院内業務サポートシステムにおいて、前記院内業務サポートサーバにおける前記通信制御部は、前記状態判定部における判定結果が異常から正常に復帰した場合、前記端末装置に処置完了信号を送信してもよい。
【００２０】
上記の構成によれば、複数の処置実行者が院内に散在する場合であっても、生体に対する処置の完了を短時間で報知することができる。さらに、処置の完了と同時に検知器から送信される検知信号に基づいて処置の完了を処置実行者に報知することができるため、端末装置を操作する手間を省くことができる。
【００２１】
また、本発明の院内業務サポートシステムにおいて、前記院内業務サポートサーバにおける前記通信制御部は、前記端末装置のうち何れかから処置完了信号を受信し、且つ、前記状態判定部における判定結果が異常から正常に復帰した場合、前記端末装置に処置完了信号を送信してもよい。
【００２２】
上記の構成によれば、複数の処置実行者が院内に散在する場合であっても、生体に対する処置の完了を短時間で報知することができる。さらに、処置実行者による端末装置の操作による処置の完了と、検知器からの検知信号に基づく処置の完了との二重チェックが行われることによって、処置を行った処置実行者自身の勘違いを処置完了信号による端末装置の報知により防止することができる。即ち、端末装置を操作しても処置の完了報告が自身が携帯する端末装置において表示されなければ、処置が正常に行われていない可能性に気付くことができる。
【００２３】
また、本発明の院内業務サポートシステムにおいて、前記生体が複数存在しており、前記通信制御部は、前記状態判定部における異常の判定結果の生体が複数存在する場合、これら生体の中から前記サポート優先度の高い監視要素の処置を受けている生体を特定し、特定した生体に対する処置を要請する処置要請信号を前記端末装置に送信してもよい。
【００２４】
上記の構成によれば、複数の生体で監視要素が異常になった場合に、サポート優先度の高い生体から処置実行者が処置することができるため、異常による不具合の拡大を最小限に抑制することができる。
【００２５】
また、本発明の院内業務サポートシステムにおいて、前記院内業務サポートサーバにおける前記通信制御部は、さらに、前記状態判定部における異常の判定結果の全ての生体について、前記監視要素の種類及び前記サポート優先度の少なくとも一方を示すサポート内容信号を前記端末装置に送信してもよい。
【００２６】
上記の構成によれば、端末装置においてサポートを要する全ての生体を、サポート優先度や監視要素と共に処置実行者に報知することができるため、サポート優先度や監視要素に基づいて各処置実行者が複数の生体を手分けして処置することが可能になる。
【００２７】
また、本発明の院内業務サポートサーバは、生体に対する処置に関する監視要素の状態を検知する検知器と、前記生体に対して処置を行う処置実行者に携帯される複数の端末装置と、を有した院内業務サポートシステムの院内業務サポートサーバであって、前記検知器及び前記端末装置に対して通信可能に接続された通信部と、前記検知器からの検知信号に基づいて前記監視要素の状態が正常及び異常の何れであるかを判定する状態判定部と、前記状態判定部における判定結果が異常である場合、前記生体に対する処置を要請する処置要請信号を前記端末装置に送信し、前記端末装置のうち何れかから応答信号を受信したときに、前記端末装置に処置開始信号を送信する通信制御部と、を有することを特徴とする。
【００２８】
上記の構成によれば、複数の処置実行者が院内に散在する場合であっても、生体に対する処置の要請及び処置の開始を短時間で報知し、院内業務を効率化することが望まれる院内業務サポートシステムを院内業務サポートサーバにより容易に構築することができる。
【発明の効果】
【００２９】
複数の処置実行者が院内に散在する場合であっても、生体に対する処置の要請及び処置の開始を短時間で報知し、院内業務を効率化することができる。
【図面の簡単な説明】
【００３０】
【図１】院内業務サポートシステムの構成の概要を示す説明図である。
【図２】院内業務サポートサーバの処理フローを示す図である。
【図３】院内業務サポートシステムの全体構成を示す説明図である。
【図４】検知器の構成を示す説明図である。
【図５】端末装置の構成を示す説明図である。
【図６】検知器種別登録テーブルを示す図である。
【図７】端末装置への報知態様の例を示す説明図である。
【図８】端末装置への報知態様の例を示す説明図である。
【図９】端末装置への報知態様の例を示す説明図である。
【図１０】検知器登録テーブルを示す図である。
【図１１】検知器状態テーブルを示す図である。
【図１２】メッセージテーブルを示す図である。
【図１３】端末装置登録テーブルを示す図である。
【図１４】処置要請管理テーブルを示す図である。
【図１５】端末装置の表示画面の一例を示す説明図である。
【図１６】端末装置の表示画面の一例を示す説明図である。
【図１７】端末装置の表示画面の一例を示す説明図である。
【図１８】端末装置の表示画面の一例を示す説明図である。
【図１９】端末装置の表示画面の一例を示す説明図である。
【図２０】受付処理ルーチンのフローチャートである。
【図２１】処置要請処理ルーチンのフローチャートである。
【発明を実施するための形態】
【００３１】
以下、本発明の好適な実施の形態について、図面を参照しつつ説明する。
【００３２】
（院内業務サポートシステム１００の概要）
本発明の実施形態に係る院内業務サポートシステム１００は、検知器からの異常を処置実行者が携帯する端末装置へ報知すると共に、何れかの処置実行者が応答した場合には他の処置実行者の端末装置へ応答した旨を報知する機能を有する院内業務サポートサーバを有している。また、院内業務サポートシステム１００は、生体の状態を検知する検知器を、複数種組み込み可能にする機能を有している。
【００３３】
図１に示すように、院内業務サポートシステム１００は、検知器２と、端末装置３と、院内業務サポートサーバ１と、を有している。院内業務サポートシステム１００は、人や動物の病院内、介護施設内、動物実験等の実験室内等の院内に構築される。検知器２、及び、端末装置３は、夫々複数が、院内業務サポートサーバ１に通信可能に接続されている。院内業務サポートサーバ１と、検知器２、及び、端末装置３との通信は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）、インターネット網を用いて接続することが出来る。各機器間を接続するためには、電話回線、専用回線を介した有線通信や無線通信などが利用可能である。例えば、ＬＡＮにおける無線通信は、図示しない無線ＬＡＮアクセスポイントを介して行われる。
【００３４】
検知器２は、生体４に対する処置に関する監視要素の状態を検知する機能を有している。例えば、検知器２は、点滴速度カウンタ、留置針センサ、漏液センサ、脈監視装置等である。「生体」とは、人、動物等の処置対象を示す。また、「処置」とは、「生体」に対して行う医療行為、看護行為、実験行為等を示すものであり、例えば、点滴、透析、各種検査等である。また、「監視要素」とは、「検知器」によって監視された「生体」の状態、及び、「検知器」自体の状態を示すものである。例えば、「監視要素」は、点滴液の滴下速度、点滴液の残量、留置針の挿入部位からの液漏れ、留置針の抜け、生体の特定部位の濡れ、生体周辺部位の圧力変化等である。また、「監視要素」は、「検知器」の電源がオンであるか否か、「検知器」を駆動させるためのバッテリーの残量、「検知器」が監視中であるか否か、等の動作状態も含む。
【００３５】
検知器２は、院内業務サポートサーバ１に対して、「監視要素」を示す検知信号を送信するように構成される。尚、検知器２が警報機能を有していてもよい。即ち、検知器２は、検知した監視要素が異常であるか否かを判定する機能、及び、異常である場合に外部に異常である旨を報知する機能を有していてもよい。例えば、検知器２は、監視要素に応じて発光色が変更される発光部や、監視要素が異常である場合に警告音を発生するスピーカを有していてもよい。
【００３６】
端末装置３は、生体４に対して処置を行う処置実行者５に携帯される。「処置実行者」は、看護師、医師、介護士等の院内で従事する者を示す。端末装置３は、通信機能を備えたスマートフォン、携帯電話、携帯型パソコン、携帯型タブレット端末等が挙げられる。端末装置３は、例えば、アプリケーションがインストールされることで以下の機能が動作可能にされる。端末装置３は、院内業務サポートサーバ１から処置要請信号を受信した際に、生体４に対する処置を要請する旨を報知する機能を有する。端末装置３は、処置要請信号に含まれる生体４を特定することが可能な情報と共に、生体４に対する処置を要請する旨を報知する。これにより、処置実行者５は、特定の生体４に対する処置の要請が発生したことを理解することができる。報知される内容は、例えば、検知器２の識別情報、生体４の氏名、生体４が存在する場所（部屋番号等）が挙げられるが、生体４を特定することが可能である情報であれば特に限定されない。
【００３７】
また、端末装置３は、院内業務サポートサーバ１へ応答信号を送信する機能を有する。即ち、処置実行者５は、端末装置３を操作することにより、院内業務サポートサーバ１へ応答信号を送信することが可能である。応答信号には、処置要請信号を特定する情報が含まれる。即ち、院内業務サポートサーバ１へ応答信号が送信されることで、応答信号を送信した端末装置３を携帯する処置実行者５が、処置要請信号が示す生体４に対する処置の予約を行うことになる。
【００３８】
また、端末装置３は、院内業務サポートサーバ１から処置開始信号を受信した際に、当該処置開始信号が示す処置の要請をキャンセルする機能を有している。処置の要請のキャンセルとは、処置要請信号に基づく報知の終了、処置の要請が他の処置実行者５によって予約されたことを示す報知等である。
【００３９】
院内業務サポートサーバ１は、状態判定部１１と、通信制御部１２と、記憶部１３と、通信部１４と、を有している。状態判定部１１は、検知器２からの検知信号に基づいて監視要素の状態が正常及び異常の何れであるかを判定する機能を有している。以下、省略する場合があるが、院内業務サポートサーバ１は、検知器２及び端末装置３に対する通信を通信部１４を介して行う。
【００４０】
通信制御部１２は、状態判定部１１における判定結果が異常である場合、生体４に対する処置を要請する処置要請信号を端末装置３に送信する機能を有する。また、通信制御部１２は、端末装置３のうち何れかから応答信号を受信したときに、端末装置３に処置開始信号を送信する機能を有する。即ち、院内業務サポートサーバ１は、検知器２からの検知信号に基づいて異常であるか否かを判定し、異常である場合には生体４に対する処置の要請を発生（端末装置３への処置要請信号の送信）させる。
【００４１】
そして、院内業務サポートサーバ１は、発生した処置の要請に対してある処置実行者５による処置の予約（端末装置３のうち何れかから応答信号の受信）が行われた場合には、処置に対する予約完了の報知（端末装置３への処置開始信号の送信）を行う。これにより、予約を行った処置実行者５を除く処置実行者５は、処置の要請に対して処置を行う処置実行者５が決定されたこと、及び、自身は処置の要請に対応することが不要であること、を理解することができる。
【００４２】
（院内業務サポートサーバ１の処理フローの概要）
図２を参照して、院内業務サポートサーバ１の処理フローの概要を示す。図２に示すように、院内業務サポートサーバ１は、検知器２から検知信号を受信したか否かを判定する（Ｓ１）。院内業務サポートサーバ１は、検知器２から検知信号を受信しない場合（Ｓ１：ＮＯ）には、ステップＳ１が再実行される。即ち、院内業務サポートサーバ１は待機状態となる。
【００４３】
一方、院内業務サポートサーバ１は、検知器２から検知信号を受信した場合（Ｓ１：ＹＥＳ）、当該検知信号に基づき監視要素の状態が正常及び異常の何れであるかを判定する（Ｓ２）。院内業務サポートサーバ１は、当該監視要素の状態が正常である場合（Ｓ２：ＹＥＳ）には、ステップＳ１が再実行される。
【００４４】
一方、院内業務サポートサーバ１は、当該監視要素の状態が異常である場合（Ｓ２：ＹＥＳ）、ステップＳ１で受信した検知信号の送信元の検知器２を特定する（Ｓ３）。即ち、院内業務サポートサーバ１は、異常状態である検知器２を特定する。尚、検知器２の特定は、全ての検知信号に対して行われてもよい。
【００４５】
ステップＳ３の後、院内業務サポートサーバ１は、生体４を特定することが可能な情報として、特定した検知器２、又は、院内業務サポートサーバ１において、特定した検知器２に関連付けられた生体４の氏名・生体４が存在する場所（部屋番号等）等を含む処置要請信号を端末装置３に送信する（Ｓ４）。端末装置３においては、処置要請信号が受信された場合、上記のような生体４を特定することが可能な情報が報知される。そして、院内業務サポートサーバ１は、報知が行われた何れかの端末装置３から応答信号を受信したか否かを判定する（Ｓ５）。院内業務サポートサーバ１は、応答信号を受信しない場合（Ｓ５：ＮＯ）、ステップＳ５を再実行する。即ち、院内業務サポートサーバ１は待機状態となる。
【００４６】
一方、院内業務サポートサーバ１は、応答信号を受信した場合（Ｓ５：ＹＥＳ）、端末装置３に処置開始信号を送信する（Ｓ６）。応答信号には、処置要請信号を特定する情報が含まれる。端末装置３においては、処置要請信号が受信された場合、端末装置３で報知された処置の要請がキャンセルされる。尚、ステップＳ６において、ステップＳ５において受信した応答信号の送信元の端末装置３を、送信対象から除外するものであってもよい。
【００４７】
このように、監視要素の状態が検知器２の検知信号により院内業務サポートサーバ１に送信され、院内業務サポートサーバ１の状態判定部１１において、監視要素の良否が判定される。状態判定部１１における判定結果が異常である場合、処置要請信号が端末装置３に送信されることによって、端末装置３を携帯する処置実行者５に対して生体４に対する処置が要請される。そして、処置実行者５が端末装置３から応答信号を院内業務サポートサーバ１に送信すると、この信号を受信した院内業務サポートサーバ１が処置開始信号を端末装置３に送信する。これにより、監視要素の状態が異常となって生体４の処置が必要になった旨を端末装置３を介して処置実行者５に一斉に報知することができると共に、何れかの処置実行者５が処置を行う旨を端末装置３を介して処置実行者５に一斉に報知することができる。この結果、複数の処置実行者５が院内に散在する場合であっても、生体４に対する処置の要請及び処置の開始を短時間で報知することができる。
【００４８】
通信制御部１２による処置要請信号の送信対象は、全ての端末装置３であってもよいし、異常に基づいて選択される特定の端末装置３であってもよい。即ち、通信制御部１２は、状態判定部１１における判定結果が異常である場合、当該異常に基づいて選択した端末装置３に対して処置要請信号を送信する機能を有していてもよい。ここで、「異常に基づいて選択される」とは、異常を発生した検知器の種別に基づいて選択することを示すものであってもよいし、検知器が発生した異常の種別に基づいて選択することを示すものであってもよい。このように、通信制御部１２による処置要請信号の送信対象となる端末装置３が検知器２で発生した異常に基づいて選択される。これにより、送信が不要な端末装置３に対しては送信をキャンセルできるため、院内の業務をより効率的にすることができる。
【００４９】
また、記憶部１３には、各生体４の監視要素の種類に対応付けられたサポート優先度が記憶されている。監視要素は、サポート優先度によって優先順位が対応付けられている。通信制御部１２による処置要請信号の送信対象は、このサポート優先度に基づいて選択されるものであってもよい。即ち、通信制御部１２は、状態判定部１１における判定結果が異常である場合、当該異常の監視要素の種類に対応付けられたサポート優先度に基づいて選択した端末装置３に対して処置要請信号を送信するものであってもよい。
【００５０】
このように、発生した異常のサポート優先度に応じて処置要請信号を送信する端末装置を選択できるため、院内の業務をより効率的にすることができる。例えば、発生した異常が重大な状況である場合には全ての端末装置３へ報知を行い、軽微な状況である場合には特定した端末装置３のみに報知を行うことが可能となる。
【００５１】
より具体的には、通信制御部１２は、状態判定部における判定結果が異常である場合、当該異常を処置可能な種別の処置実行者が携帯する端末装置３を選択して処置要請信号を送信する機能を有していてもよい。ここで、記憶部１３は、端末装置３と端末装置３を携帯する処置実行者５の種別とを関連付けて記憶する処置実行者種別記憶部として機能する。即ち、通信制御部１２は、処置要請信号を送信する際に、記憶部１３を参照して、発生した異常を処置可能な種別の処置実行者５が携帯する端末装置３を選択する。ここで、「処置可能な種別の処置実行者」とは、処置可能なすべての種別の処置実行者であることに限定されない。また、異常に対して処置の要請を行う処置実行者の種別が記憶部１３等において予め対応付けられていることが好ましい。このように、通信制御部１２による処置要請信号の送信対象となる端末装置３は、検知器２で発生した異常を処置可能な種別の処置実行者５が携帯する端末装置３であるか否かによって選択される。これにより、検知器２の異常を処置可能な処置実行者５のみに処置の要請が報知されるため、院内の業務をより効率的にすることができる。例えば、発生した異常が重大な状況である場合には全ての処置実行者５の端末装置３へ同報通知を行い、軽微な状況である場合には当該異常に対応できる特定の処置実行者５のみにに報知を行うことで、院内の業務をより効率的にすることができる。尚、発生した異常が重大であるか否かは、上記のサポート優先度によって判断してもよい。
【００５２】
また、通信制御部１２は、状態判定部１１における判定結果が異常である場合、当該異常に基づいて要請範囲を決定し、当該要請範囲に位置する端末装置３に処置要請信号を送信する機能を有していてもよい。ここで、要請範囲とは、物理的な距離に基づく範囲に限定されず論理的な区分に基づくものであってもよい。例えば、院内が複数棟／複数階層を有する場合、異常に基づいて処置を要請する棟／階層を変更させてもよい。また、例えば、同フロアを部署ごとに区分し、異常に基づいて処置を要請する部署を変更させてもよい。このように、通信制御部１２による処置要請信号の送信対象となる端末装置３は、異常に基づいて決定される要請範囲に位置するか否かによって選択される。これにより、異常に基づく要請範囲基づいて必要な要請範囲に処置の要請が報知されるため、院内の業務をより効率的にすることができる。例えば、発生した異常が重大な状況である場合には全フロアの端末装置３へ同報通知を行い、軽微な状況である場合には検知器２の設置されている特定のフロアに存在する端末装置３のみに報知を行うことで、より多くの対応可能な処置実行者５への報知が可能となる。尚、発生した異常が重大であるか否かは、上記のサポート優先度によって判断してもよい。
【００５３】
尚、「選択した端末装置に対して処置要請信号を送信する」とは、実際に選択した端末装置３のみに対して処置要請信号を送信することに限定されない。例えば、全ての端末装置３に送信し、選択されなかった端末装置３において処置要請信号に基づく報知が行われなければ良い。即ち、「選択した端末装置に対して処置要請信号を送信する」とは、選択した端末装置３においてのみ報知されることも含む。
【００５４】
また、通信制御部１２は、端末装置３のうち何れかから処置完了信号を受信したときに、端末装置３に処置完了信号を送信する機能を有していてもよい。即ち、端末装置３は、処置完了信号を院内業務サポートサーバ１へ送信する機能を有する。従って、処置実行者５は、端末装置３を操作することにより、院内業務サポートサーバ１へ処置完了信号を送信することが可能である。処置完了信号には、要請信号を特定する情報が含まれる。即ち、院内業務サポートサーバ１へ処置完了信号が送信されることで、処置完了信号を送信した端末装置３を携帯する処置実行者５が、要請信号が示す生体４に対する処置が完了したことが端末装置３を介して各処置実行者５へ示されることになる。これにより、複数の処置実行者５が院内に散在する場合であっても、生体４に対する処置の完了を短時間で報知することができる。
【００５５】
また、通信制御部１２は、状態判定部１１における判定結果が異常から正常に復帰した場合、端末装置３に処置完了信号を送信する機能を有していてもよい。これにより、複数の処置実行者５が院内に散在する場合であっても、生体４に対する処置の完了を短時間で報知することができる。さらに、処置の完了と同時に検知器２から送信される検知信号に基づいて処置の完了を処置実行者５に報知することができるため、処置を行った処置実行者５が処置の完了を報告するために端末装置３を操作する手間を省くことができる。
【００５６】
また、通信制御部１２は、端末装置３のうち何れかから処置完了信号を受信し、且つ、状態判定部１１における判定結果が異常から正常に復帰した場合、端末装置３に処置完了信号を送信する機能を有していてもよい。これにより、複数の処置実行者５が院内に散在する場合であっても、生体４に対する処置の完了を短時間で報知することができる。さらに、処置実行者５による端末装置３の操作による処置の完了と、検知器２からの検知信号に基づく処置の完了との二重チェックが行われることによって、処置を行った処置実行者５自身の勘違いを処置完了信号による端末装置３の報知により防止することができる。即ち、端末装置３を操作しても処置の完了報告が自身が携帯する端末装置３において表示されなければ、処置が正常に行われていない可能性に気付くことができる。
【００５７】
また、通信制御部１２は、状態判定部１１における異常の判定結果の生体４が複数存在する場合、これら生体４の中からサポート優先度の高い監視要素の処置を受けている生体４を特定し、特定した生体４に対する処置を要請する処置要請信号を端末装置３に送信する機能を有していてもよい。「状態判定部における異常の判定結果の生体が複数存在する」とは、状態判定部１１が検知器２の監視要素の状態が異常であると判定してから当該検知器２が検知する生体４に対する応答信号を受信するまでの期間が重複する複数の検知器２が存在していることを示す。尚、当該期間は、状態判定部１１が検知器２の監視要素の状態が異常であると判定してから、当該検知器２が検知する生体４に対する処置完了信号を受信するまで、であってもよい。
【００５８】
また、通信制御部１２は、状態判定部１１における異常の判定結果の生体４が複数存在する場合、当該生体４を異常と判定された監視要素のサポート優先度に従い、優先順位の高い生体４を特定して処置要請信号を送信する。ここで送信される処置要請信号は、既に送信している優先順位の低い処置要請信号が示す処置を後回しにすることを端末装置３に報知させるものであってもよい。このように、複数の生体４で監視要素が異常になった場合に、サポート優先度の高い生体４から処置実行者５が処置することができるため、異常による不具合の拡大を最小限に抑制することができる。
【００５９】
また、通信制御部１２は、さらに、状態判定部１１における異常の判定結果の全ての生体４について、監視要素の種類及びサポート優先度の少なくとも一方を示すサポート内容信号を端末装置３に送信する機能を有していてもよい。これにより、端末装置３においてサポートを要する全ての生体４を、サポート優先度や監視要素と共に処置実行者５に報知することができるため、サポート優先度や監視要素に基づいて各処置実行者５が複数の生体４を手分けして処置することが可能になる。
【００６０】
尚、図示しないが、院内業務サポートサーバ１は、コンピュータであり、ＣＰＵ（Central Processing Unit）と、ＣＰＵが実行するプログラム及びこれらプログラムに使用されるデータを書き替え可能に記憶するＥＥＰＲＯＭ（Electrically Erasable and Programmable Read Only Memory）等と、プログラム実行時にデータを一時的に記憶するＲＡＭ（Random Access Memory）等とを含んでいる。院内業務サポートサーバ１が有する各構成は、これらハードウェアとＥＥＰＲＯＭ内のソフトウェアとの協働により構築されている。尚、院内業務サポートサーバ１は１台のコンピュータに限定されず、複数のコンピュータに上記機能を分散させて設けるものであってもよい。
【００６１】
（院内業務サポートシステムの構成）
以上の各機能を備えた院内業務サポートサーバ１、検知器２、及び、端末装置３を含む院内業務サポートシステム１００についてより具体的に説明する。以下、院内業務サポートシステム１００を病院内での業務に適用した場合について説明するが、これに限定されない。
【００６２】
（全体構成）
図３に示すように、院内業務サポートサーバ１、検知器２、及び、端末装置３が、ＬＡＮ１０１を介して通信可能に接続されている。検知器２は、病室等の処置室６において点滴等の処置が行われる入院患者や通院患者等の生体４に設置され、生体４に対する処置の状態を監視する。処置室６は、複数あってもよく、それぞれに複数の検知器２が設置されていてもよい。また、１の生体４に１種以上の複数の検知器２を設置してもよい。端末装置３は、看護師や医師等の処置実行者５のそれぞれに携帯され、表示部３４としてのディスプレイに報知画面が表示される。
【００６３】
（検知器２）
図４に示すように、検知器２は、設定部２１、通信部２２、電源部２３、及び、検知部２４を有している。設定部２１は、外部から検知器２の設定を行うため受付処理、及び／又は、受付構造を有する。設定部２１によって、院内業務サポートサーバ１との通信、及び、検知器２の動作等の設定が可能にされる。設定部２１は、直接コンピュータを接続するためのＵＳＢ（Universal Serial Bus）端子、及び、メモリ等を有し、外部からのコマンド等の入力を受け付け、設定内容を記憶するものであってもよい。また、設定部は、ディップスイッチ等の物理スイッチであってもよい。
【００６４】
具体的に、設定部２１によって設定される内容は、無線ＬＡＮに接続するためのＳＳＩＤ（Service Set Identifier）、セキュリティキー、院内業務サポートサーバ１のＩＰアドレス（Internet Protocol address）、及び、電源のオン／オフ等である。このように、設定部２１は、検知器２の設定を可能にするとともに設定内容を記憶する。
【００６５】
通信部２２は、院内業務サポートサーバ１に対する通信を行う機能を有する。通信部２２は、ＭＡＣ（Media Access Control）アドレスを有しており、これが検知器２の識別情報として用いられる。尚、これに限定されず、例えば、設定部２１に検知器２を一意に識別する情報を記憶するものであってもよい。電源部２３は、検知器２の動力源となる電池である。検知部２４は、生体４に対する処置、及び、電源部２３の電池残量等の監視要素の状態を検知し、これら監視要素を示す検知信号を送信する。
【００６６】
また、本実施形態では、検知器２は、自身の異常状態が正常状にに復帰したことを示す復帰信号を送信する機能を有している。具体的に、検知器２には、復帰信号を送信するためのボタン等の入力デバイスを有している。この入力デバイスが処置実行者５によって操作されることにより、院内業務サポートサーバ１へ復帰信号が送信されるように検知器２が構成されている。
【００６７】
（端末装置３）
本実施形態では、端末装置３は、スマートフォン又はタブレット端末である。図５に示すように、端末装置３は、制御部３１、記憶部３２、報知部３３、表示部３４、入力部３５、及び、通信部３６を有している。制御部３１は、各種プログラムを実行する。例えば、制御部３１は、院内業務サポートサーバ１から各種信号を受信した場合に表示部３４に各種信号に基づく表示画面を表示するプログラム、入力部３５への入力に基づき院内業務サポートサーバ１へ応答信号や処置開始信号を送信するプログラム等を実行する。記憶部３２は、上記のような各種プログラムを記憶すると共に、通信等の設定や院内業務サポートサーバ１からの各種信号に基づく情報を記憶する。例えば、設定内容は、無線ＬＡＮに接続するためのＳＳＩＤ、セキュリティキー、及び、院内業務サポートサーバ１のＩＰアドレス等である。
【００６８】
報知部３３は、院内業務サポートサーバ１から各種信号を受信したことを報知する。報知部３３は、例えば、音声により報知を行うスピーカや、振動により報知を行うためのモータである。表示部３４は、院内業務サポートサーバ１から受信した各種信号が示す詳細情報を表示するディスプレイである。入力部３５は、院内業務サポートサーバ１へ各種信号を送信するために処置実行者５が操作する入力装置である。入力部３５は、表示部３４の表面を覆うように図示しないタッチパネルを有している。これにより、処置実行者５の入力操作を受け付けることが可能にされている。また、入力部３５は、直接コンピュータを接続するためのＵＳＢ端子を有している。
【００６９】
通信部３６は、院内業務サポートサーバ１に対する通信を行う機能を有する。通信部３６は、ＭＡＣ（Media Access Control）アドレスを有しており、これが端末装置３の識別情報として用いられる。尚、これに限定されず、例えば、記憶部３２に端末装置３を一意に識別する情報を記憶するものであってもよい。通信部３６は、院内業務サポートサーバ１との間に確立された接続を維持する。これにより、院内業務サポートサーバ１から端末装置３への通知（信号の送信）を行うことが可能となる。
【００７０】
上記各種プログラムは、院内業務サポートサーバ１にアクセスしてＬＡＮ経由で端末装置３にインストールされてもよいし、入力部３５と直接接続した所定のコンピュータから端末装置３にインストールされてもよい。
【００７１】
端末装置３は、ＣＰＵ（Central Processing Unit）と、ＣＰＵが実行するプログラム及びこれらプログラムに使用されるデータを書き替え可能に記憶するＥＥＰＲＯＭ（Electrically Erasable and Programmable Read Only Memory）等と、プログラム実行時にデータを一時的に記憶するＲＡＭ（Random Access Memory）等とを含んでいる。端末装置３が有する各構成は、これらハードウェアとＥＥＰＲＯＭ内のソフトウェアとの協働により構築されている。
【００７２】
（院内業務サポートサーバ１）
院内業務サポートサーバ１は、検知器２、及び、端末装置３が通信可能であれば、院内の配置に限定されない。例えば、院内業務サポートサーバ１は、ＬＡＮ１０１を含むＷＡＮ内の異なるセグメントに配置されていてもよい。
【００７３】
（データテーブル）
ここで、院内業務サポートサーバ１において、記憶部１３（図１参照）が記憶するデータテーブルについて説明する。
【００７４】
（検知器種別登録テーブル）
検知器種別登録テーブルには、検知器２からの監視要素の種別と、監視要素の種別に応じた判定基準とが対応付けて記憶される。具体的に、本実施形態では、図６に示すように、検知器種別登録テーブルは、検知器種別欄、監視要素種別欄、判定基準欄、報知設定欄、サポート優先度欄、処置種別欄、及び、要請範囲欄を有している。検知器種別欄には、検知器の種類を識別するための名称が格納される。即ち、検知器種別が共通の検知器２は、同じ種類の機種となる。監視要素種別欄には、検知器２から送信され得る監視要素の種別が格納される。判定基準欄には、監視要素ごとに異常か正常かを判定するための基準が格納される。報知設定欄には、報知設定欄には、判定基準に基づき異常と判定された場合に端末装置３において報知されるメッセージを示す識別情報が格納される。サポート優先度欄には、メッセージごとに緊急度を示すサポート優先度が格納される。即ち、監視要素ごとに緊急度が設定されることになる。尚、サポート優先度は、検知器種別ごとに設定されるものであってもよい。
【００７５】
処置種別欄には、発生した異常を処置することが可能な処置実行者５の種別が格納される。これにより、例えば、看護師が処置可能な異常である場合には、看護師が携帯する端末装置３を選択して処置要請信号を送信することが可能であり、医師のみが処置可能な異常である場合には、看護師が携帯する端末装置３を選択して処置要請信号を送信することが可能である。また、より重大な異常については、看護師及び医師が携帯する端末装置３を選択して処置要請信号を送信することが可能である。このように、サポート優先度および検知器種別の組み合わせにより、重大な状況については全端末装置３への報知を行い、軽微な状況については看護師が携帯する端末装置３のみに報知を行うことにより、より効率的な運営が可能となる。尚、サポート優先度に基づいて処置種別を選択し、処置要請信号を送信する端末装置３を特定してもよい。例えば、サポート優先度が低い異常は看護師が携帯する端末装置３のみに報知し、サポート優先度が中程度の異常は医師が携帯する端末装置３のみに報知し、サポート優先度が高い異常は看護師及び医師が携帯する端末装置３に報知してもよい。この場合、記憶部１３には、サポート優先度の範囲に処置種別が対応付けられて記憶されることになる。
【００７６】
要請範囲欄には、発生した異常の処置要請信号を送信する要請範囲が格納される。本実施形態では、異常が発生した検知器２と同フロアの要請範囲をＡとし、異常が発生した検知器２の上下フロアをＢとし、異常が発生した検知器２の棟内全フロアをＣとし、隣接する病棟の全フロアをＤとしている。このように、異常（検知器２の監視要素種別）毎に要請範囲が対応づけられていると共に、要請範囲が任意に設定可能にされている。これにより、例えば、重大な状況の場合は、全フロアの端末装置３への同報通知を行い、軽微な状況については検知器２の設置されている特定のフロアの端末装置３への通知を行うことで、より多くの対応可能な処置実行者５への報知が可能となる。尚、上記のように複数の病棟をまたいで設定可能であり、複数の病棟は異なる地域に配置されるものであってもよい。このような場合であっても、ＷＡＮやインターネットを経由して処置の要請が可能となる。
【００７７】
尚、本実施形態では、図７に示すように、フロアごとにルータが設けられている。具体的に、１階フロアＦ１にはルータ１０２ａが設けられ、２階フロアＦ２にはルータ１０２ｂが設けられ、３階フロアＦ３にはルータ１０２ｃが設けられ、４階フロアＦ３にはルータ１０２ｄが設けられている。処置実行者５は、携帯する端末装置３を、自身の存在するフロアのルータに接続するようになっている。そして、検知器２、及び、端末装置３に割り当てられるＩＰアドレスは、ルータ１０２毎にセグメントが異なるようにされている。これにより、検知器２、及び、端末装置３の存在するフロアが、判別可能となっている。尚、検知器２、及び、端末装置３の位置判別方法はこれに限定されず、例えば、記憶部１３に、フロアの階数と、検知器２及び端末装置３とが対応付けられて記憶されるものであってもよい。
【００７８】
例えば、図７に示すように、２階フロアＦ２における検知器２において、サポート優先度が低い異常が発生した場合には、同じフロア（２階フロアＦ２）のルータ１０２ｂに接続される端末装置３に対して処置要請信号が送信される。また、図８に示すように、２階フロアＦ２における検知器２において、サポート優先度が中程度の異常が発生した場合には、同じフロア（２階フロアＦ２）と、上下階のフロア（１階フロアＦ１、及び、３階フロアＦ３）のルータ１０２ａ〜１０２ｃに接続される端末装置３に対して処置要請信号が送信される。また、図９に示すように、２階フロアＦ２における検知器２において、サポート優先度が高い異常が発生した場合には、全てのフロア（フロアＦ１〜Ｆ４）のルータ１０２ａ〜１０２ｄに接続される端末装置３に対して処置要請信号が送信される。
【００７９】
上記の検知器種別登録テーブルは、検知器２からの検知信号が異常であるか否かの判定に用いられる。例えば、検知器２が、正常状態において電気的に隔離状態の接点が、漏れた液により電気的に接続されることで漏液を検出する機能を有し、漏液を検出した場合に監視要素種別「漏液」について値「ＯＮ」を出力するものとする。この場合、予め検知器種別登録テーブルにおいて、監視要素種別「漏液」の判定基準を「ＯＮ」としておき、報知設定として「Ａ−００１」のメッセージを設定する。これにより、院内業務サポートサーバ１は、検知器２が異常であると判定し、生体４に対する処置を要請する処置要請信号を端末装置３に送信することが可能となる。
【００８０】
このように、院内業務サポートサーバ１は、検知器２からの検知器の状態を示す検知信号を受付可能な通信部１４と、検知器２からの検知信号の種別と検知信号の種別に応じた判定基準とを対応付けて記憶する記憶部１３と、通信部１４が受け付けた検知信号の値と、当該検知信号が示す種別に対応付けられた判定基準に基づき、検知器２の検知信号が異常を示すものであるか否かを判定する状態判定部１１と、状態判定部１１が、検知器２の検知信号が異常を示すものである、と判定した場合、複数の端末装置３において生体４に対する処置を要請する報知を行わせると共に、当該報知後のタイミングでの複数の端末装置３における入力に基づいて複数の端末装置３のうち何れか１を決定する通信制御部１２と、を有する。
【００８１】
これにより、検知器２が異常であるかを識別可能な信号を送信するものであれば、予め院内業務サポートサーバ１に検知信号の種別に応じた異常の判定基準を設定しておくことで、どのような検知器２であっても院内業務サポートサーバ１で異常を検出し、複数の端末装置３に対する処置の要請の報知を行うことができる。さらに、複数の端末装置３における入力に基づいて１の端末装置３を決定することで、処置の要請に対する処置実行者５を決定することが可能となる。
【００８２】
（検知器登録テーブル）
検知器登録テーブルには、院内業務サポートサーバ１に接続される全ての検知器２が記憶される。具体的に、図１０に示すように、検知器登録テーブルは、検知器種別欄、検知器名欄、ＩＰアドレス欄、ＭＡＣアドレス欄、及び、登録完了日時欄を有している。検知器種別欄には、検知器２の種類を識別するための名称が格納される。即ち、各検知器２に対する異常の判定基準は、検知器種別登録テーブルの検知器種別に関連付けられた設定内容に従うことになる。
【００８３】
尚、検知器登録テーブルにおいて、検知器２毎に、監視要素の判定基準を設定可能にされ、検知器２の異常判定を行う際に検知器登録テーブルの判定基準を優先されるものであってもよい。これにより、検知器２（生体４）毎に詳細な設定を行うことができる。例えば、検知器２が同じであっても、生体４の症状に応じて判定基準を細かく設定することができる。
【００８４】
検知器名欄には、検知器２を識別するための固有の名称が格納される。本実施形態では、処置実行者５は、検知器名に生体４の識別可能な名称を用いることより生体４、及び、生体４に設置された検知器２を特定可能にしているがこれに限定されない。ＩＰアドレス欄には、検知器２に設定されたＩＰアドレスが格納される。尚、ＩＰアドレスは、各検知器２が接続を確立する毎にＤＨＣＰ（Dynamic Host Configuration Protocol）によって動的に決定されてもよいし、各検知器２に予め静的に決定されるものであってもよい。ＭＡＣアドレス欄には、各検知器２毎に固有のＭＡＣアドレスが格納される。登録完了日時欄には、検知器２を院内業務サポートサーバ１に登録した日時が格納される。
【００８５】
（検知器状態テーブル）
検知器状態テーブルには、登録される全ての検知器２の状態が記憶される。具体的に、図１１に示すように、検知器状態テーブルは、ＭＡＣアドレス欄、監視要素種別欄、検知状態欄、電池残量欄、通信状態欄、報知設定欄、及び、ログ欄を有している。ＭＡＣアドレス欄には、検知器２を識別するためのＭＡＣアドレスが格納される。監視要素種別欄には検知器２から送信され得る監視要素の種別が格納され、検知状態欄には監視要素の種別ごとの検知状態が格納される。電池残量欄には、検知器２が有するバッテリの残量が格納される。通信状態欄には、検知器２がＬＡＮ１０１に接続されているか否かが格納される。ログ欄には、検知器２に対する通信ログファイルを識別する識別情報が格納される。
【００８６】
（メッセージテーブル）
メッセージテーブルには、検知器種別登録テーブルにおいて設定可能な報知設定毎に、メッセージが記憶される。具体的に、図１２に示すように、メッセージテーブルは、報知ＩＤ欄と、メッセージ欄と、を有している。報知ＩＤ欄には、メッセージを識別する報知ＩＤが格納される。報知ＩＤは、検知器種別登録テーブルにおいて、報知設定欄に設定可能である。メッセージ欄には、報知ＩＤごとに対応付けられたメッセージが格納される。このメッセージは端末装置３において表示部３４に表示される内容に含められる。
【００８７】
（端末装置登録テーブル）
端末装置登録テーブルには、院内業務サポートサーバ１に接続される全ての端末装置３が記憶される。具体的に、図１３に示すように、端末装置登録テーブルは、ユーザ名欄、ＩＰアドレス欄、ＭＡＣアドレス欄、登録完了日時欄、及び、種別欄を有している。ユーザ名欄には、端末装置３にインストールされたプログラムにログインするための一意のユーザ名が格納される。本実施形態では、処置実行者５は、ユーザ名により識別される。ＩＰアドレス欄には、端末装置３に設定されたＩＰアドレスが格納される。尚、ＩＰアドレスは、各端末装置３が接続を確立する毎にＤＨＣＰ（Dynamic Host Configuration Protocol）によって動的に決定されてもよいし、各端末装置３に予め静的に決定されるものであってもよい。ＭＡＣアドレス欄には、各端末装置３毎に固有のＭＡＣアドレスが格納される。登録完了日時欄には、端末装置３を院内業務サポートサーバ１に登録した日時が格納される。種別欄には、発生した異常を処置することが可能な処置実行者５の種別が格納される。処置実行者５の種別は、異常が発生した場合の端末装置３の選択の際に用いられる。
【００８８】
（処置要請管理テーブル）
処置要請管理テーブルは、異常が発生した際の処置の要請を管理するために用いられる。処置要請管理テーブルには、発生した処置要請信号と、処置要請信号毎の状態とが記憶される。具体的に、図１４に示すように、処置要請管理テーブルは、要請ＩＤ欄、検知器名欄、報知ＩＤ欄、サポート優先度欄、状態欄、対応者欄、発生日時欄、及び、完了日時欄を有している。要請ＩＤ欄には、処置要請信号を識別するための要請ＩＤが格納される。要請ＩＤは、処置要請信号を発生させる毎に採番される。検知器名欄には、異常と判定された検知器２の検知器名が格納される。報知ＩＤ欄には、メッセージを識別する報知ＩＤが格納される。即ち、端末装置３において出力するメッセージの報知ＩＤが格納される。サポート優先度欄には、検知器種別登録テーブル（図６参照）に設定されたサポート優先度が格納される。これにより、メッセージごとの緊急度を端末装置３へ通知することが可能となる。
【００８９】
状態欄には、要請した処置に対して処置実行者５の対応状況が格納される。具体的に、処置要請信号に対して、何れの端末装置３からも応答信号が送信されない場合には、状態欄に「未対応」が格納される。即ち、「未対応」は、何れの処置実行者５によっても処置に対応されていない状態を示す。また、処置要請信号に対して、端末装置３のうち何れかから応答信号が送信された場合には、状態欄に「応答」が格納される。即ち、「応答」は、応答信号を送信した端末装置３を携帯する処置実行者５が処置に対応している状態を示す。また、処置要請信号に対して、端末装置３のうち何れかから処置完了信号が送信された場合には、状態欄に「完了」が格納される。即ち、「完了」は、応答信号を送信した端末装置３を携帯する処置実行者５によって、処置が完了している状態を示す。
【００９０】
対応者欄には、応答信号を送信した端末装置３のユーザ名が格納される。従って、状態が「未対応」の処置要請信号にはユーザ名は格納されていない状態となる。発生日時欄には、処置要請信号を送信した日時が格納される。応答日時欄には、端末装置３から応答信号を受信した日時が格納される。完了日時欄には、端末装置３から処置完了信号を受信した日時が格納される。また、検知器の種類によって対応できる対応者が限られているような場合、対応可能な対応者のテーブルを登録しておくことにより、きめ細かな対応が可能となる。
【００９１】
本実施形態では、記憶部１３が記憶するデータテーブルが端末装置３の記憶部３２と同期され、同じデータテーブルが各端末装置３に記憶される。尚、同期されるデータテーブルや項目が限定されるものであってもよい。また、データテーブルは上記に限定されず、どのようなに正規化されたものであってもよい。
【００９２】
（表示画面）
次に、端末装置３において表示される報知画面について説明する。端末装置３は、院内業務サポートサーバ１から処置要請信号を受信すると、未対応状態の処置要請信号の一覧を示す一覧画面を表示する。
【００９３】
具体的に、一覧画面では、図１５に示すように、表示部３４の上部に未確認件数画像３４１が表示されると共に、未確認件数画像３４１の下方に要請画像３４２が表示される。未確認件数画像３４１は、端末装置３において受信した処置要請信号のうち、当該端末装置３を携帯する処置実行者５によって確認されていない数が表示される。要請画像３４２は、端末装置３において受信した処置要請信号の数だけ表示される。即ち、要請画像３４２が複数ある場合、異常の判定結果の生体４が複数存在することを示す。要請画像３４２には、異常が発生した検知器２の検知器名、院内業務サポートサーバ１が処置要請信号を出力した発生日時、及び、処置要請信号を識別する要請ＩＤが表示される。
【００９４】
尚、図示しないが、要請画像３４２が複数ある場合、そのサポート優先度に応じて表示がソートされてもよい。例えば、緊急度の高いものを上から順に表示することで、処置実行者５は要請された処置の優先度を理解することが可能となる。また、例えば、サポート優先度の上位（例えば、サポート優先度が１〜１０）の要請画像３４２については表示色を他と変えて、処置実行者５に緊急であることをより理解させるものであってもよい。
【００９５】
処置実行者５が要請画像３４２の領域をタッチ操作することにより、タッチされた処置要請信号が示す詳細情報が表示される。図１６に示すように、詳細画面には、要請画像３４２に表示されていた内容に加え、メッセージ画像３４３と、対応ボタン画像３４４とが表示される。メッセージ画像３４３は、異常の内容を示すメッセージを示す画像である。対応ボタン画像３４４には、「対応する」旨のテキストが示されたボタン状の画像である。処置実行者５が対応ボタン画像３４４の領域をタッチ操作することにより、端末装置３から院内業務サポートサーバ１へ応答信号が送信されることになる。このように、端末装置３は、院内業務サポートサーバ１からの処置の要請に対して、処置実行者５が対応するための入力画面が表示される。
【００９６】
端末装置３のうち何れかから応答信号が送信されると、一覧画面が更新される。図１７に示すように、一覧画面の端末装置３から応答信号が送信された要請画像３４２には、対応中の処置実行者５を示す対応者画像３４５が表示される。これにより、処置実行者５は、院内業務サポートサーバ１から要請された処置が対応中であることを認識できる。
【００９７】
要請に対し応答信号を送信した端末装置３において、当該要請に対応する要請画像３４２の領域をタッチ操作することにより、処置完了信号を送信可能な詳細画面が表示される。具体的に、図１８に示すように、対応完了ボタン画像３４６が表示される。対応完了ボタン画像３４６は、「対応完了」の旨のテキストが示されたボタン状の画像である。処置実行者５が対応完了ボタン画像３４６の領域をタッチ操作することにより、端末装置３から院内業務サポートサーバ１へ処置完了信号が送信されることになる。このように、処置の要請に対して応答した処置実行者５は、携帯する端末装置３において対応した処置が完了したことを院内業務サポートサーバ１へ通知することができる。
【００９８】
一覧画面において、処置完了信号が送信された要請に対応する要請画像３４２には、処置が完了した旨が示される。具体的に、図１９に示すように、対応者画像３４５が非表示にされると共に、院内業務サポートサーバ１が処置完了信号を受信した日時と、処置要請信号を識別する要請ＩＤとが要請画像３４２に追加表示される。各処置実行者５が携帯する端末装置３において、処置が完了した要請画像３４２の詳細画面を確認した場合、一覧画面から削除される。尚、上記各画面の表示態様や表示項目はこれに限定されない。
【００９９】
（動作）
次に、本実施形態の院内業務サポートサーバ１の動作について説明する。
【０１００】
（受付処理）
図２０は、院内業務サポートサーバ１のＣＰＵ（以下、単に「院内業務サポートサーバ１」と称す）が実行する受付処理ルーチンのフローチャートである。本ルーチンは、受信信号毎にスレッドが生成されて並行処理可能にされている。先ず、院内業務サポートサーバ１は、検知器２から検知信号を受信したか否かを判定する（Ｓ１０）。院内業務サポートサーバ１は、検知信号を受信した場合（Ｓ１０：ＹＥＳ）、処置要請処理を実行する（Ｓ１１）。処置要請処理については、後述する。処置要請処理が実行された後、ステップＳ１０に戻る。
【０１０１】
一方、検知信号を受信しない場合（Ｓ１０：ＮＯ）、院内業務サポートサーバ１は、端末装置３から応答信号を受信したか否かを判定する（Ｓ１２）。院内業務サポートサーバ１は、応答信号を受信した場合（Ｓ１２：ＹＥＳ）、データテーブルを更新する（Ｓ１３）。具体的に、院内業務サポートサーバ１は、応答信号に含まれる要請ＩＤによって、処置要請管理テーブル（図１４）のデータを確定し、応答信号に含まれるユーザ名を対応者欄に格納すると共に、状態欄を「応答」に更新する。
【０１０２】
その後、同期処理を実行する（Ｓ１４）。同期処理おいては、院内業務サポートサーバ１は、端末装置登録テーブル（図１３参照）に登録されている端末装置３に対して、処置開始信号として処置要請管理テーブルの内容を送信する。これにより、端末装置３における処置要請管理テーブルが更新されることになる。その結果、図１７に示すように、端末装置３において、処置実行者５は、要請された処置が対応中であることを確認できる。その後、ステップＳ１０に戻る。
【０１０３】
一方、応答信号を受信しない場合（Ｓ１２：ＮＯ）、院内業務サポートサーバ１は、端末装置３から処置完了信号を受信したか否かを判定する（Ｓ１５）。院内業務サポートサーバ１は、処置完了信号を受信した場合（Ｓ１５：ＹＥＳ）、データテーブルを更新する（Ｓ１６）。具体的に、院内業務サポートサーバ１は、処置完了信号に含まれる要請ＩＤによって、処置要請管理テーブル（図１４）のデータを確定し、状態欄を「完了」に更新すると共に、処置完了信号を受信した日時を完了日時欄に格納する。尚、ステップＳ１６において、処置完了信号に含まれるユーザ名が確定したデータの対応者欄に格納されたユーザ名と一致するか否かの確認を行ってもよい。
【０１０４】
その後、待機処理を実行する（Ｓ１７）。待機処理においては、検知器２からの検知信号を受信し、対応する監視要素が正常に更新されるまで次の処理を待機する。即ち、処置実行者５による端末装置３の操作による処置の完了と、検知器２からの検知信号に基づく処理の完了との二重チェックを行う。
【０１０５】
そして、同期処理を実行する（Ｓ１８）。同期処理おいては、院内業務サポートサーバ１は、端末装置登録テーブル（図１３参照）に登録されている端末装置３に対して、処置完了信号として処置要請管理テーブルの内容を送信する。これにより、端末装置３における処置要請管理テーブルが更新されることになる。その結果、図１９に示すように、端末装置３において、処置実行者５は、要請された処置が完了していることを確認できる。その後、ステップＳ１０に戻る。
【０１０６】
上述のように、本実施形態では、処置実行者５による端末装置３の操作による処置の完了と、検知器２からの検知信号に基づく処理の完了と、を院内業務サポートサーバ１から端末装置３への処置完了信号の送信条件としているがこれに限定されない。例えば、ステップＳ１７の待機処理を行わずに、処置実行者５による端末装置３の操作による処置の完了のみを院内業務サポートサーバ１から端末装置３への処置完了信号の送信条件としてもよい。
【０１０７】
（処置要請処理）
図２１は、院内業務サポートサーバ１が実行する処置要請処理ルーチンのフローチャートである。先ず、院内業務サポートサーバ１は、検知器から受信した検知信号の内容に基づいて、データテーブルを更新する（Ｓ１９）。具体的に、検知信号には、検知器２のＭＡＣアドレスが格納されており、検知器状態テーブル（図１１参照）の当該ＭＡＣアドレスに対応する検知器２の監視要素の検知状態を更新する。この検知信号に基づく処置の要請に対して、端末装置３から処置完了信号を受信していた場合、このステップＳ１９が実行されることによって、他のスレッドの受付処理ルーチンにおけるステップＳ１７の待機が完了することになる。
【０１０８】
そして、検知器２から受信した検知信号の内容が、異常を示すものであるか否かを判定する（Ｓ２０）。具体的に、検知信号が示す監視要素種別の値が、検知器種別登録テーブルの判定基準に合致するか否かを判定する。
【０１０９】
一方、検知信号の内容が異常を示すものである場合（Ｓ２０：ＹＥＳ）、院内業務サポートサーバ１は、既に異常に対する要請が行われているかを判定する（Ｓ２１）。具体的に、当該検知信号に基づいて、検知器登録テーブルから検知器名を取得する。そして、検知器種別登録テーブル（図６参照）から、異常とされた監視要素種別に対応する報知設定欄の報知ＩＤを取得する。そして、取得した検知器名および報知ＩＤに対応するデータが処置要請管理テーブル（図１４参照）にある場合、既に異常に対する要請が行われていると判定する。既に異常に対する要請が行われている場合（Ｓ２１：ＹＥＳ）、本ルーチンを終了する。
【０１１０】
異常に対する要請が行われていない場合（Ｓ２１：ＮＯ）、処置要請管理テーブル（図１４参照）にデータを追加する（Ｓ２２）。具体的に、ユニークな要請ＩＤを採番し、取得した検知器名および報知ＩＤに加え、状態を「未対応」とした新たなデータを処置要請管理テーブルに挿入する。
【０１１１】
その後、同期処理を実行する（Ｓ２３）。同期処理おいては、院内業務サポートサーバ１は、端末装置登録テーブル（図１３参照）に登録されている端末装置３に対して、処置要請信号及びサポート内容信号として処置要請管理テーブルの内容を送信する。これにより、端末装置３における処置要請管理テーブルが更新されることになる。その結果、図１５に示すように、端末装置３において、処置実行者５は、要請された未対応の処置を確認できる。この際に、端末装置３では、自身において当該要請された未対応の処置を報知するか否かを判定する。具体的に、端末装置３は、予め院内業務サポートサーバ１から自身に同期されている検知器種別登録テーブルを参照し、要請された処置の報知ＩＤに関連する処置種別や要請範囲から自身が処置の要請対象であるか否かを判定する。端末装置３は、自身が処置の要請対象である場合には、表示部３４等により処置要請の報知を行う。尚、これに限定されず、報知対象の端末装置３のみに処置要請信号を送信してもよい。これにより、端末装置３の処理が軽減される。院内業務サポートサーバ１はステップＳ２３の後、本ルーチンを終了する。
【０１１２】
ステップＳ２０において、検知信号が異常を示すものでない場合（Ｓ２１：ＮＯ）、対応するデータテーブルの値が異常であるか否かを判定する（Ｓ２５）。即ち、検知器２の検知信号が示す監視要素が、異常状態から正常状態へ移行したか否かを判定する。データテーブルの値が異常でない場合（Ｓ２５：ＮＯ）、本ルーチンを終了する。
【０１１３】
（その他の処理）
検知器２、端末装置３は、その使用前において、院内業務サポートサーバ１のデータテーブル（検知器登録テーブル（図１０参照）、端末装置登録テーブル（図１３参照））に、データが追加されて登録される。
【０１１４】
また、院内業務サポートサーバ１は、検知器２から復帰信号を受信した場合、当該検知器２に関連する処置の要請を完了状態にする。即ち、院内業務サポートサーバ１は、復帰信号に含まれるＭＡＣアドレスから検知器登録テーブル（図１０参照）を参照して検知器名を取得し、処置要請管理テーブル（図１４参照）において取得した検知器名に関連するデータの状態を「完了」に更新する。そして、受付処理のステップＳ１８と同様の処理を行うことで処置完了信号を端末装置３へ送信する。
【０１１５】
（変形例）
以上、本発明の実施形態について説明したが、本発明は上述の実施の形態に限られるものではなく、特許請求の範囲に記載した限りにおいて様々に変更して実施することができるものである。
【０１１６】
本実施形態では、検知器２に検知器名として、生体４を特定可能な情報を用いることで、検知器名で生体４を特定していたがこれに限定されない。例えば、患者等の処置対象となる生体４を登録するためのデータテーブルを設け、検知器２を用いる前に検知器２と生体４とを関連付けるものであってもよい。また、検知器２と生体４を処置する処置室６とを関連付けるものであってもよい。これにより、処置実行者５へ、端末装置３を介して、生体４や処置室６等の情報を処置の要請と共に報知することが可能となる。
【０１１７】
本明細書において用いた用語及び語法は、本発明を的確に説明するために用いたものであり、本発明の解釈を制限するために用いたものではない。また、当業者であれば、本明細書に記載された発明の概念から、本発明の概念に含まれる他の構成、システム、方法等を推考することは容易であると思われる。従って、請求の範囲の記載は、本発明の技術的思想を逸脱しない範囲で均等な構成を含むものであるとみなされるべきである。また、本発明の目的及び本発明の効果を充分に理解するために、すでに開示されている文献等を充分に参酌することが望まれる。
【符号の説明】
【０１１８】
１  院内業務サポートサーバ
２  検知器
３  端末装置
４  生体
５  処置実行者
６  処置室
１１  状態判定部
１２  通信制御部
１３  記憶部
１４  通信部
２１  設定部
２２  通信部
２３  電源部
２４  検知部
３１  制御部
３２  記憶部
３３  報知部
３４  表示部
３５  入力部
３６  通信部
１００  院内業務サポートシステム
３４１  未確認件数画像
３４２  要請画像
３４３  メッセージ画像
３４４  対応ボタン画像
３４５  対応者画像
３４６  対応完了ボタン画像
【図１】
2016154780.tif 000003
【図２】
2016154780.tif 000004
【図３】
2016154780.tif 000005
【図４】
2016154780.tif 000006
【図５】
2016154780.tif 000007
【図６】
2016154780.tif 000008
【図７】
2016154780.tif 000009
【図８】
2016154780.tif 000010
【図９】
2016154780.tif 000011
【図１０】
2016154780.tif 000012
【図１１】
2016154780.tif 000013
【図１２】
2016154780.tif 000014
【図１３】
2016154780.tif 000015
【図１４】
2016154780.tif 000016
【図１５】
2016154780.tif 000017
【図１６】
2016154780.tif 000018
【図１７】
2016154780.tif 000019
【図１８】
2016154780.tif 000020
【図１９】
2016154780.tif 000021
【図２０】
2016154780.tif 000022
【図２１】
2016154780.tif 000023