JP4414874B2 - 障害通知システム - Google Patents

Description

本発明は、業務施設に設置された装置に障害が発生した場合に、障害通知を行う障害通知システムに関する。

従来から、医療機関などの施設に設置されている装置の障害を検知して、その障害内容を電子メール等の配信手段を使用して効率よく伝達する障害通知システムが提案されている。例えば、特許文献１には、業務処理に障害が生じた場合に、電子メールで障害が発生したことを示す障害情報を通知する技術が開示されている。
特開２００１−１６００２９号公報

ところで、従来の障害通知システムでは、医療機関などの施設に設置されている装置に障害が発生したとき、発生した障害の障害内容が保守担当者に電子メールで通知されることがある。しかしながら、障害を通知する障害通知機能に障害が発生した場合、保守担当者に障害内容を含む電子メールが届かないことがある。この場合、電子メールの受信側において障害の発生原因の切り分けが困難になる。電子メールの受信側における障害の発生原因の切り分けが困難であれば、直接現地に出向いて障害の発生原因の解析作業を行うことになるが、障害通知システムに生じた障害が、例えば、保守担当者の責任範囲外の障害である場合、その保守作業が結果として無駄になり障害の発生原因を特定できない可能性がある。

本発明はこうした課題に鑑みてなされたものであり、その目的は、障害通知の受信側において障害の発生原因の切り分けの精度を高めることができる障害通知システムの提供にある。

本発明のある態様は、障害通知システムに関する。このシステムは、業務施設に設けられた端末装置と、業務支援装置と、当該支援装置を監視する監視装置とを備え、業務支援装置は、端末装置に発生した障害を検知する障害検知部と、検知した障害に関する障害情報を所定の時間間隔で送信する第１送信部と、を備え、監視装置は、業務支援装置が正常に稼働しているか否かを監視する稼働監視部と、稼働監視部による監視情報を所定の時間間隔で送信する第２送信部と、を備える。

業務施設としては、例えば、医療機関、研究所などが挙げられる。特に、業務施設が医療機関の場合には、端末装置としては、内視鏡装置などの医療機器、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）などが挙げられる。また、業務支援装置としては、ＰＣなどの端末装置とＬＡＮ（Local Area Network）などのネットワークで接続された管理用サーバなどが挙げられる。

この態様によれば、例えば、第１送信部に障害が発生し障害情報取得側に障害情報が通知されない場合でも、第２送信部により所定の時間間隔で送信される監視情報に基づいて障害の発生原因の切り分けが容易となる。その結果、障害情報が通知されない場合における、障害情報取得側においての障害の発生原因の切り分けの精度を高めることができる。障害情報が通知されない場合において、保守担当者は障害の発生原因に応じて保守作業を実施するか否かの判断を事前に行うことができ、障害回復に係る保守作業全体を効率化できる。

端末装置に発生する障害の原因解析に有用な環境情報を取得する環境情報取得部をさらに備え、第１送信部は、業務支援装置が正常に稼働している場合に、環境情報を所定の時間間隔で送信してもよい。第１送信部は、端末装置に障害が発生した場合に、環境情報に障害情報を関連づけて送信してもよい。

環境情報および監視情報を受信する受信部と、受信部により環境情報および監視情報が受信できない場合に、業務支援装置を送信先として、当該業務支援装置を含む監視対象のシステムに障害が発生しているか否かを確認するための確認情報を送信する第３送信部と、を備える装置をさらに含んでもよい。

第１送信部、第２送信部および第３送信部のうち少なくとも一つの送信部による送信手段が電子メールであってもよい。この構成によれば、既存の電子メールシステムを活用して、障害通知システムを低コストで実現することができる。

本発明によれば、障害回復に係る保守作業全体を効率化できるシステムを提供できる。

本発明を具体的に説明する前に、概要を述べる。本実施の形態は、医療機関などの業務施設に設置された装置に障害が発生した場合に、障害情報を含む電子メールを保守担当者に通知する障害通知システムに関する。この障害通知システムは、内視鏡装置などの医療機器と、医師または看護師が使用するＰＣやＰＤＡなどの端末機器と、医療業務支援サーバと、障害の発生を監視する障害監視装置と、電子メールの送受信を制御するメールサーバと、を含み、それらはＬＡＮによって接続されている。本実施の形態に係る障害通知システムは、主として、以下に示すような特徴を有する。

一つめは、医療業務支援サーバに障害情報を含む電子メールを送信させるだけでなく、医療業務支援サーバとは異なる装置である障害監視装置に医療業務支援サーバが正常に稼働しているか否かを監視させ、その監視情報を定期的に電子メールで通知するよう障害通知システムを構成していることである。これにより、医療業務支援サーバに障害が発生し障害情報が通知されない場合でも、障害監視装置により送信される監視情報に基づいて障害の発生原因の切り分けが容易となる。

二つめは、医療業務支援サーバおよび障害監視装置から送信される電子メールを受信できない場合に、医療業務支援サーバ宛てに、当該サーバを含む監視対象の医療業務支援システムにて障害が発生しているか否かを確認するための確認情報を送信するよう障害通知システムを構成していることである。これにより、医療業務支援サーバおよび障害監視装置から電子メールが送信されなくても、医療業務支援システムにて障害が発生しているか否かを確認することができる。

図１は、本実施の形態に係る障害通知システムの全体構成を示す。この障害通知システム１０は、医療機関に設けられた医療業務支援システム２０と、医療業務支援システム２０の保守管理を行う保守管理システム７０と、医療業務支援システム２０と保守管理システム７０とを相互に通信可能に接続するＷＡＮ（Wide Area Network）１２と、を含む。

医療業務支援システム２０は、内視鏡装置などの医療機器２４と、医師または看護師が使用するＰＣ２６やＰＤＡ２８と、医療機器２４で得られた医療データや、患者のカルテ情報、看護情報などを格納する医療業務支援サーバ３０と、障害の発生を監視する障害監視装置１００と、受信した電子メールを転送する医療業務メールサーバ３８と、それら機器、端末やサーバを相互に通信可能に接続するＬＡＮ２２と、当該ＬＡＮ２２と外部のＷＡＮ１２とを接続する医療業務側ネットワークルータ１６とを含む。なお、以下では、医療機器２４、ＰＣ２６やＰＤＡ２８を端末装置２９と適宜総称する。

医療機器２４は、得られたデータを、ＬＡＮ２２を介して医療業務支援サーバ３０に送信して、サーバ内部の不図示のデータ格納部に記録する。医療機器２４で得られるデータとしては、例えば、内視鏡装置によって撮像された胃内部の画像が挙げられる。

ＰＣ２６またはＰＤＡ２８は、ＬＡＮ２２を介して医療業務支援サーバ３０にアクセス可能である。医師は、患者の診察に関連して、ＰＣ２６を用いて医療業務支援サーバ３０内部の不図示のデータ格納部に格納されたカルテに関するデータや医療データを読み出し、必要に応じてこれらのデータを記録することが可能である。また、看護師は、患者の看護に関連して、ＰＤＡ２８を用いて医療業務支援サーバ３０内部の不図示のデータ格納部に看護情報として記録することができる。

医療業務支援サーバ３０は、医療データ、患者のカルテ情報、看護情報等の医療に関する情報を格納し、医療機器２４、ＰＣ２６およびＰＤＡ２８からの要求に従ってデータの送受信を行う。データの送受信の際、医療業務支援サーバ３０は、医療機器２４、ＰＣ２６およびＰＤＡ２８との通信履歴を通信ログとして記録する。通信ログには、装置名やＩＰ（Internet Protocol）アドレスなどの通信相手を特定する情報、通信時間、通信内容、およびエラーメッセージが対応して記載される。なお、エラーメッセージは、障害の内容ごとに振り分けられた障害番号を含んでもよい。

医療業務支援サーバ３０は、障害検知部３２と、環境情報取得部３４と、支援サーバ側送信部３６とを含む。障害検知部３２は、医療業務支援サーバ３０に記録された通信ログを監視し、端末装置２９に発生した障害を検知する。具体的には、障害検知部３２は、例えば、医療業務支援サーバ３０内部の不図示の障害リストに登録されている障害番号やエラーメッセージが通信ログ内に含まれるか否かに応じて障害の発生の有無を検知する。なお、この障害リストは医療業務支援システム２０内に生じうる障害に関する障害番号やエラーメッセージなどが記録されたファイルであり、事前に行われる運用試験の結果に基づいて保守担当者により予め作成されてもよい。障害検知部３２は、障害の発生を検知した場合、検知された障害に関する障害番号および障害発生時刻などを含む障害情報を通信ログから抽出する。なお、この抽出処理は障害検知部３２内部の図示しない抽出部が行ってもよい。

環境情報取得部３４は、医療業務支援サーバ３０の起動処理時および停止処理時に環境情報を取得する。環境情報とは、端末装置２９に発生する障害の原因解析に有用な情報、例えば、端末装置２９や医療業務支援サーバ３０に搭載されるハードウエアやソフトウエアに関する情報である。なお、環境情報の具体例については後述する。取得された環境情報は後述の支援サーバ側送信部３６により電子メールで保守担当者宛てに送信される。また、起動処理時や停止処理時を示す情報を環境情報に含めることで、環境情報を受け取った保守担当者は医療業務支援サーバ３０の起動から停止までの間を知ることができる。

さらに、環境情報取得部３４は、医療業務支援サーバ３０が正常に稼働している間、所定の時間間隔、例えば、１分間に１回の割合で環境情報を取得する。医療業務支援サーバ３０の正常な稼働状態とは、医療業務支援サーバ３０が提供する各種サービスが正常に機能している状態を指し、例えば、相手の装置から送信されるｐｉｎｇコマンドによる問いかけに対して応答できる状態などが挙げられる。この構成によれば、医療業務支援サーバ３０の稼働中に定期的に送信される環境情報を、停止処理時を示す情報を含む環境情報を取得する前に取得できなくなった場合、保守担当者は障害通知システム１０に何らかの障害が生じたと判断できる。そのタイミングにおいて、保守担当者は障害の発生原因の解析動作を開始できる。

なお、環境情報は時間の経過とともにその内容が変化するか否か、すなわち動的なものであるか静的なものであるかは問わない。以下、ハードウエアおよびソフトウエアに関する環境情報を、それぞれ動的なもの、静的なものに分けて具体的に説明する。

動的なハードウエアの環境情報とは、例えば、ＣＰＵ（Central Processing Unit）使用率やメモリ使用量などを指し、一方、静的なハードウエアの環境情報とは、メモリの物理的容量やデバイス機器の種類などを指す。例えば、ＣＰＵ使用率やメモリ使用量を取得するのであれば、環境情報取得部３４はｖｍｓｔａｔコマンドを実行してもよい。他の例として、メモリの物理的容量を取得するのであれば、環境情報取得部３４はｍｅｍコマンドを実行してもよい。

また、動的なソフトウエアの環境情報とは、例えば、ソフトウエアを実行させるためのプロセスの状態を指し、一方、静的なソフトウエアの環境情報とは、例えば、ＯＳ（Operating System）やアプリケーションなどのソフトウエアの名称やバージョンを指す。例えば、プロセスの状態を取得するのであれば、環境情報取得部３４はｐｓコマンドを実行してもよい。他の例として、ＯＳのバージョンを取得するのであれば、環境情報取得部３４はオプション「−ｖ」を伴うｕｎａｍｅコマンドを実行してもよい。

支援サーバ側送信部３６は、医療業務支援サーバ３０が正常に稼働している場合に、環境情報を所定の時間間隔、例えば、１分間に１回の割合で送信する。具体的には、支援サーバ側送信部３６は環境情報取得部３４により取得されたハードウエアやソフトウエアの環境情報が記載された電子メール（以下、「支援サーバ側メール」という）を作成し、当該電子メールを医療業務メールサーバ３８を介して後述の保守管理メールサーバ４０に所定の時間間隔で送信する。

障害検知部３２により障害が検知された場合、支援サーバ側送信部３６は、障害検知部３２により抽出された障害情報を上述の支援サーバ側メールに追加し、当該支援サーバ側メールを医療業務メールサーバ３８を介して保守管理メールサーバ４０に送信する。この場合、支援サーバ側送信部３６は、環境情報と障害情報とを関連づけた支援サーバ側メールを生成する。一つの支援サーバ側メール内に環境情報と障害情報とが関連付けられているため、障害の発生原因を解析するのに好都合である。

障害監視装置１００は、稼働監視部１０２および監視サーバ側送信部１０４を備える。稼働監視部１０２は、医療業務支援サーバ３０が正常に稼働しているか否かを監視する。具体的には、稼働監視部１０２は、例えば、ｐｉｎｇコマンドを実行し、医療業務支援サーバ３０からの応答結果を医療業務支援サーバ３０からの監視情報として取得する。なお、医療業務支援サーバ３０が正常に稼働しているか否かを監視するためのコマンドであればｐｉｎｇコマンドに限られない。

監視サーバ側送信部１０４は、稼働監視部１０２による監視情報を所定の時間間隔、例えば、１分間に１回の割合で送信する。具体的には、監視サーバ側送信部１０４は、稼働監視部１０２により取得された監視情報が記載された電子メール（以下、「監視サーバ側メール」という）を作成し、当該監視サーバ側メールを医療業務メールサーバ３８を介して後述の保守管理メールサーバ４０に送信する。この構成によれば、監視サーバ側メールは監視サーバ側送信部１０４により所定の時間間隔で送信されるため、保守担当者は定期的に取得するはずの監視サーバ側メールを取得できない場合に障害通知システム１０に何らかの障害が生じたと判断できる。不図示であるが、この判断は後述の保守管理端末５０内部の判断部が行っても良い。

不図示の判断部は、監視サーバ側送信部１０４により所定の時間間隔で送信される監視情報を取得できない場合、所定の時間後、例えば１時間の経過後に再度監視情報を取得した場合であれば、障害は未発生であると判断してもよい。障害監視装置１００が単なる一時の電源オフの状態でも、その間は監視サーバ側送信部１０４からの監視サーバ側メールの送信は行われない。この場合、保守担当者は障害監視装置１００に障害が発生したとの誤判断を行うことがある。その結果、保守担当者が現地に駆けつけるといった無駄な作業が発生することがある。そのため、所定の時間の間、例えば１時間の間、監視情報を含む監視サーバ側メールを取得できなくても障害が未発生であると判断することは有意義である。

保守管理システム７０は、受信した電子メールを転送する保守管理メールサーバ４０と、保守担当者が使用する保守管理端末５０と、保守管理メールサーバ４０と保守管理端末５０とを相互に通信可能に接続するＬＡＮ１４と、当該ＬＡＮ１４と外部のＷＡＮ１２とを接続する保守管理側ネットワークルータ１８とを含む。

保守管理メールサーバ４０は、支援サーバ側送信部３６により送信された支援サーバ側メールと監視サーバ側送信部１０４により送信された監視サーバ側メールとを保守管理端末５０に転送する。

保守管理端末５０は、受信部５２と保守端末側送信部５４とを含む。受信部５２は、保守管理メールサーバ４０により転送された支援サーバ側メールと監視サーバ側メールを受信する。保守担当者は支援サーバ側メールに含まれる障害情報を参照することで、障害の発生原因を特定し、障害回復などの作業を行う。さらに、本実施の形態では、支援サーバ側メールの受信が不可能になった場合、保守担当者は監視サーバ側メールの受信状況に基づいて障害の発生原因を特定する。

例えば、保守管理端末５０内部に支援サーバ側メールおよび監視サーバ側メールの受信状況と障害発生原因とが関連づけられた障害原因特定表データを保持する図示しない保持部を備え、保守担当者は当該障害原因特定表データを参照することで、医療業務支援システム２０において生じた障害の発生原因を特定してもよい。なお、障害の発生原因の特定動作は保守担当者のかわりに保守管理端末５０内部の不図示の障害原因特定部が行ってもよい。障害原因特定表データは、事前に行われる障害通知システム１０の運用試験の結果に基づいて保守担当者により予め作成されてもよい。

保守端末側送信部５４は、受信部５２により環境情報が含まれた支援サーバ側メールおよび監視情報が含まれた監視サーバ側メールを受信できない場合に、医療業務支援サーバ３０宛てに、当該サーバを含む監視対象の医療業務支援システム２０にて障害が発生しているか否かを確認するための確認情報を送信する。具体的には、保守端末側送信部５４は、例えば確認情報として本文が空白である電子メールを作成し、医療業務メールサーバ３８を介して医療業務支援サーバ３０宛てに送信する。

受信部５２により支援サーバ側メールおよび監視サーバ側メールを受信できない場合、以下の二つのケースが考えられる。
（ア）医療業務メールサーバ３８や医療業務側ネットワークルータ１６などにおいて発生したインフラ障害
（イ）医療業務支援サーバ３０および障害監視装置１００の単なる電源のオフ状態
（ア）の場合、保守端末側送信部５４から送信された電子メールが医療業務メールサーバ３８に転送できない旨のエラーメッセージが保守管理メールサーバ４０から保守管理端末５０宛てに返信される。一方、（イ）の場合、保守端末側送信部５４から送信された電子メールは医療業務メールサーバ３８に転送できるため、保守管理メールサーバ４０からエラーメッセージが返信されることはない。

すなわち、受信部５２により環境情報が含まれた支援サーバ側メールおよび監視情報が含まれた監視サーバ側メールを受信できない場合、保守端末側送信部５４が医療業務支援サーバ３０宛てに確認情報を含む電子メールを送信することで、保守担当者は、受信不可の原因が（ア）であるか、あるいは（イ）であるかの判断を行うことができる。これにより、メール受信側である保守管理端末５０において、医療業務支援システム２０にて障害が発生したか否かを特定できる。その結果、先の例で言えば、（ア）の場合に障害回復作業を実施するといった作業の切り分けを作業実施前に行うことができ、不要な作業に生ずるコストや労力を削減できる。これにより、障害回復を行うための保守作業全体を効率化できる。

以下、障害が発生した場合と障害が発生しなかった場合のそれぞれにおける、支援サーバ側メールおよび監視サーバ側メールの一例を図２および図３に示す。図２（ａ）は、障害の発生が検知されない場合の支援サーバ側メール、一方、図２（ｂ）は、障害の発生が検知された場合の支援サーバ側メールを示す。なお、図の煩雑さを避けるため、送信先欄やＣｃ欄は本図では省略するものとする。

障害検知部３２により障害の発生が検知されない場合、図２（ａ）に示す環境情報１１２を含む支援サーバ側メール１１０が支援サーバ側送信部３６により送信される。図２（ａ）に示す環境情報１１２は、「ｈｏｓｔＡ」という名称の医療業務支援サーバ３０に関する環境情報１１２の取得日時が「２００４年１２月１日の１２時」である。なお、図２（ａ）には医療業務支援サーバ３０の環境情報１１２が示されているが、他の例として、医療機器２４や端末装置２９に関する環境情報が支援サーバ側メール１１０に含まれていてもよい。

障害検知部３２により障害の発生が検知された場合、図２（ａ）に示す環境情報１１２に、さらに障害情報１１４が含まれる支援サーバ側メール１１０が支援サーバ側送信部３６により送信される。図２（ｂ）に示すごとく、環境情報１１２と障害情報１１４とが関連づけられている。図２（ｂ）に示す障害情報１１４は、障害番号が「１００１」で、「カルテ書き込みエラー」である障害が、「２００４年１２月１日の１２時」に発生している。

図３（ａ）は、医療業務支援サーバが正常に稼働していることを示す監視サーバ側メール、一方、図３（ｂ）は、医療業務支援サーバが正常に稼働していないことを示す監視サーバ側メールの一例を示す。なお、図３（ａ）および図３（ｂ）は、ｐｉｎｇコマンドの実行結果を示したものである。

図３（ａ）に示す監視サーバ側メール１２０は、医療業務支援サーバ３０との通信が正常に行われている、すなわちサーバが正常に稼働していることを示すものであり、監視情報としての第１実行結果１２２〜第３実行結果１２６を含む。具体的には、第１実行結果１２２は、稼働監視部１０２から「ｈｏｓｔＡ」という名称の医療業務支援サーバ３０宛てに３２バイトのデータのかたまりが送信されていることを示す。また、第２実行結果１２４および第３実行結果１２６は、医療業務支援サーバ３０上のサービスが３２バイトのデータのかたまりを受け取り正常に応答していることを示す。

図３（ｂ）に示す監視サーバ側メール１２０は、医療業務支援サーバ３０との通信が正常に行われていない、すなわちサーバが正常に稼働していないことを示すものであり、監視情報としての第１実行結果１２２および第４実行結果１２８を含む。具体的には、第４実行結果１２８は、稼働監視部１０２からの問いかけに対し医療業務支援サーバ３０からの応答がない状態を示す。

図４は、本実施の形態に係る障害原因特定表データの一例を示す。保守担当者は、この障害原因特定表データ１３０を参照し、保守管理メールサーバ４０から転送される支援サーバ側メールおよび監視サーバ側メールの受信状況から、医療業務支援システム２０において生じた障害の発生原因を特定する。

障害原因特定表データ１３０は支援サーバ側メール欄１３２と、監視サーバ側メール欄１３４と、障害発生原因欄１３６とを備える。支援サーバ側メール欄１３２は、受信部５２により支援サーバ側メールの受信が行われた否かの受信状況を保持する。監視サーバ側メール欄１３４は、受信部５２により監視サーバ側メールの受信が行われた否かの受信状況を保持する。障害発生原因欄１３６は、支援サーバ側メールの受信状況および監視サーバ側メールの受信状況に対応づけられた障害発生原因を保持する。

データ１３８は、受信部５２により支援サーバ側メールの受信は行われたが監視サーバ側メールの受信は行われなかった場合、医療業務支援サーバ３０側に障害が発生していることを示す。一方、データ１４０は、受信部５２により支援サーバ側メールおよび監視サーバ側メールの受信が行われなかった場合、ＬＡＮ２２のケーブル障害や医療業務メールサーバ３８の障害などのインフラ障害が発生していることを示す。

従来では、保守担当者は医療業務支援サーバ３０から送信される障害通知メールを参照することで、障害の発生原因を特定していた。しかしながら、例えば、以下のケースでは、医療業務支援サーバ３０からの障害通知メールの送信は行われない。下記に示す障害が医療業務支援システム２０内に発生した場合、保守担当者は障害通知メールを取得できないため、障害の発生原因の特定が困難になる。
（１）医療業務支援サーバ３０に搭載されたＯＳの動作異常による支援サーバ側送信部３６の送信機能停止
（２）ＬＡＮ２２のケーブル障害、医療業務メールサーバ３８の障害や医療業務側ネットワークルータ１６の機器障害など、医療業務支援サーバ３０以外で生じたインフラ障害

本実施の形態では、医療業務支援サーバ３０に支援サーバ側メールを送信させるだけでなく、医療業務支援サーバ３０とは異なる装置である障害監視装置１００に医療業務支援サーバ３０が正常に稼働しているか否かを監視させ、その監視情報を定期的に監視サーバ側メールで通知するよう障害通知システム１０を構成している。

この構成によれば、例えば、受信部５２が支援サーバ側メールを受信できないが監視サーバ側メールを受信できる場合、保守担当者は図４に示すデータ１３８を参照することで医療業務支援サーバ３０側に障害があると特定できる。先の例で言えば、障害の発生原因が（１）であると特定できる。さらに、受信部５２が支援サーバ側メールおよび監視サーバ側メールを受信できない場合、図４に示すデータ１４０を参照することで医療業務支援サーバ３０以外のネットワークなどのインフラに障害があると特定できる。先の例で言えば、障害の発生原因が（２）であると特定できる。

これにより、メール受信側である保守管理端末５０においての障害の発生原因の切り分けの精度を高めることができる。その結果、医療業務支援サーバ３０側に障害が発生した場合、先の例で言えば（１）の場合に障害回復作業を実施するといった作業の切り分けを作業実施前に行うことができ、不要な作業に生ずるコストや労力を削減できる。これにより、障害回復を行うための保守作業全体を効率化できる。

図５は、支援サーバ側メールの送信処理の流れを示す。医療業務支援サーバ３０の電源がユーザによりオンされ、医療業務支援システム２０の起動が開始される（Ｓ１０）。医師または看護師の業務により、医療機器２４、ＰＣ２６やＰＤＡ２８が操作され、医療業務支援サーバ３０に通信ログが順次記録され、蓄積される（Ｓ１２）。障害検知部３２は、医療業務支援サーバ３０に記録された通信ログを参照し、障害が発生したか否かを判断する（Ｓ１４）。障害が発生したと判断した場合（Ｓ１４のＹ）、障害検知部３２は通信ログから障害情報を抽出する（Ｓ１６）。障害が発生していないと判断した場合（Ｓ１４のＮ）、障害検知部３２は障害情報の抽出をスキップする。環境情報取得部３４は環境情報を取得する（Ｓ１８）。支援サーバ側送信部３６は、障害検知部３２により障害が発生しないと判断された場合、環境情報を含む支援サーバ側メールを、一方、障害検知部３２により障害が発生したと判断された場合、障害情報および環境情報を含む支援サーバ側メールを、保守管理メールサーバ４０宛てに送信する（Ｓ２０）。

保守管理メールサーバ４０は支援サーバ側送信部３６により送信された支援サーバ側メールを保守管理端末５０に転送する（Ｓ２２）。保守管理端末５０は保守管理メールサーバ４０により配信された支援サーバ側メールを受信する（Ｓ２４）。医療業務支援サーバ３０が停止処理されない間（Ｓ２６のＮ）、上述したステップ１２〜ステップ２４の処理が所定の時間間隔、例えば、１分間に１回の割合で繰り返し行われる。医療業務支援サーバ３０が停止処理されたとき（Ｓ２６のＹ）、停止処理の間に上述したステップ１２〜ステップ２４の処理が一度行われ、支援サーバ側メールの送信処理を終了する。

図６は、監視サーバ側メールの送信処理の流れを示す。障害監視装置１００の電源がユーザによりオンされ起動される（Ｓ４０）。稼働監視部１０２は医療業務支援サーバ３０が正常に稼働しているかを監視し、監視情報を取得する（Ｓ４２）。監視サーバ側送信部１０４は保守管理メールサーバ４０に監視サーバ側メールを送信する（Ｓ４４）。保守管理メールサーバ４０は監視サーバ側送信部１０４により送信された監視サーバ側メールを保守管理端末５０に転送する（Ｓ４６）。保守管理端末５０は保守管理メールサーバ４０により転送された監視サーバ側メールを受信する（Ｓ４８）。障害監視装置１００が停止処理されない間（Ｓ５０のＮ）、上述したステップ４２〜ステップ４８の処理が所定の時間間隔、例えば、１分間に１回の割合で繰り返し行われる。障害監視装置１００が停止処理されたとき（Ｓ５２のＹ）、監視サーバ側メールの送信処理を終了する。

本発明と本実施の形態に係る構成の対応を例示する。第１送信部は「支援サーバ側送信部３６」に対応し、第２送信部は「監視サーバ側送信部１０４」に対応し、第３送信部は「保守端末側送信部５４」に対応する。

以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。そうした変形例を以下に挙げる。

実施の形態に係る障害通知システム１０では、障害監視装置１００と医療機器２４、ＰＣ２６やＰＤＡ２８などの端末装置２９とを別の構成としたが、変形例として障害監視装置１００を医療機器２４、ＰＣ２６やＰＤＡ２８のうち少なくとも一つの装置の内部に一構成として組み込んでもよい。

本実施の形態に係る障害通知システムの全体構成を示す図である。 図２（ａ）は、障害の発生が検知されない場合の支援サーバ側メールの一例を示す図であり、一方、図２（ｂ）は、障害の発生が検知された場合の支援サーバ側メールの一例を示す図である。 図３（ａ）は、医療業務支援サーバが正常に稼働していることを示す監視サーバ側メールの一例を示す図であり、一方、図３（ｂ）は、医療業務支援サーバが正常に稼働していないことを示す監視サーバ側メールの一例を示す図である。 本実施の形態に係る障害原因特定表データの一例を示す図である。 支援サーバ側メールの送信処理の流れを示す図である。 監視サーバ側メールの送信処理の流れを示す図である。

符号の説明

１０ 障害通知システム、 ３２ 障害検知部、 ３４ 環境情報取得部、 ３６ 支援サーバ側送信部、 ５２ 受信部、 ５４ 保守端末側送信部、 １０２ 稼働監視部、 １０４ 監視サーバ側送信部、 １１２ 環境情報、 １１４ 障害情報。

Claims (3)

1. 業務施設に設けられた端末装置と、業務支援装置と、当該業務支援装置を監視する監視装置と、管理装置と、を備えた障害通知システムにおいて、
   前記業務支援装置は、
   前記端末装置に発生した障害を検知する障害検知部と、
   前記端末装置に発生した障害の原因解析に有用な環境情報を取得する環境情報取得部と、
   前記業務支援装置が正常に稼働している場合に、前記環境情報を所定の時間間隔で送信し、前記障害検知部により障害が検知された場合に、前記障害に関する障害情報を送信する第１送信部と、を備え、
   前記監視装置は、
   前記業務支援装置が正常に稼働しているか否かを監視する稼働監視部と、
   前記稼働監視部による監視情報を所定の時間間隔で送信する第２送信部と、を備え、
   前記管理装置は、
   前記環境情報、前記障害情報および前記監視情報を受信する受信部と、
   前記受信部により前記環境情報および前記監視情報が受信できない場合に、前記業務支援装置を送信先として、当該業務支援装置を含む監視対象のシステムに障害が発生しているか否かを確認するための確認情報を送信する第３送信部と、を備えることを特徴とする障害通知システム。
2. 前記第１送信部は、前記端末装置に障害が発生した場合に、前記環境情報に前記障害情報を関連づけて送信することを特徴とする請求項１に記載の障害通知システム。
3. 前記第１送信部、前記第２送信部および前記第３送信部のうち少なくとも一つの送信部による送信手段が電子メールであることを特徴とする請求項１または２に記載の障害通知システム。

Images