医療支援システム
【課題】医療機器からサーバに至るデータ送受信経路における通信障害の発生を，サーバ側でより正確に把握することができる医療支援システムを提供する。
【解決手段】医療支援システムは，患者宅内に設置され運転情報を作成する医療機器と，医療機器に接続され運転情報を取得する通信端末子機と，通信端末子機と第１の通信媒体(13)を介して情報を送受信する通信端末親機と，患者宅から遠隔の地に設置され，医療機器とその運転情報が格納されたデータベース(DB)を有し，通信端末親機から第２の通信媒体(150)を介して運転情報を含む情報をアップロードされるサーバ(20)とを有し，通信端末子機と通信端末親機は，第１の通信媒体(13)に通信障害が発生したときに第１の通信障害情報を記録し，通信端末親機は，医療機器に異常が発生したときに医療機器が作成する緊急情報をリアルタイムでサーバにアップロードし，第１の通信障害情報を所定期間間隔であらかじめ設定されたアップロードタイミングでサーバにアップロードする。
【解決手段】医療支援システムは，患者宅内に設置され運転情報を作成する医療機器と，医療機器に接続され運転情報を取得する通信端末子機と，通信端末子機と第１の通信媒体(13)を介して情報を送受信する通信端末親機と，患者宅から遠隔の地に設置され，医療機器とその運転情報が格納されたデータベース(DB)を有し，通信端末親機から第２の通信媒体(150)を介して運転情報を含む情報をアップロードされるサーバ(20)とを有し，通信端末子機と通信端末親機は，第１の通信媒体(13)に通信障害が発生したときに第１の通信障害情報を記録し，通信端末親機は，医療機器に異常が発生したときに医療機器が作成する緊急情報をリアルタイムでサーバにアップロードし，第１の通信障害情報を所定期間間隔であらかじめ設定されたアップロードタイミングでサーバにアップロードする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，医療支援システムに関し，特に，患者宅内または医療機関内に設置され運転情報を作成する医療機器と，医療機器に接続され運転情報を取得する通信端末子機と，通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，前記患者宅または医療機関から遠隔の地に設置され通信端末親機から第２の通信媒体を介して運転情報を含む情報をアップロードされるサーバとを有する医療支援システムに関する。
【背景技術】
【０００２】
近年，喘息，肺気腫症，慢性気管支炎などの呼吸器系器官の疾患に苦しむ患者が増加する傾向にあるが，その治療法として効果的なもののひとつに酸素吸入療法がある。酸素吸入療法とは，酸素ガスあるいは酸素富化空気を患者に吸入させるものである。その酸素供給源として，酸素濃縮装置，液体酸素，酸素ガスボンベなどが知られているが，使用時の便利さや保守管理の容易さから，在宅酸素療法には医療用酸素濃縮装置が最もよく利用されている。
【０００３】
この医療用酸素濃縮装置は，病院などの医療機関のみならず在宅療法のために患者宅においても使用されている。在宅酸素療法では，病院内とは異なり医師や看護師の監視下で使用されないので，装置の状態を把握することができず，患者が医師から処方されたとおりに正しい設定で使用しているか否か，取扱説明書の記載とおりに正しい使用方法を遵守しているか否かを確認することは困難である。
【０００４】
そこで，酸素濃縮装置による在宅療法を適切に行うために，酸素濃縮装置に通信端末装置を接続し，遠隔にあるサーバに酸素濃縮器の通常の運転情報や異常時の緊急情報を送信することが提案されている。サーバには，酸素濃縮装置などの医療機器とその運転情報とを有するデータベースが備えられ，サーバは，通信端末装置からアップロードされる運転情報をデータベースに格納し，それを分析して適切に使用されているか否かのチェックを行い，緊急情報により医療機器の異常を早期に発見する。このような医療支援システムが，特許文献１，２，３に記載されている。
【特許文献１】特開平３−１４３４５１号公報
【特許文献２】特開平６−５４９１０号公報
【特許文献３】特開２００５−２４５７３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
この医療支援システムでは，患者宅内の医療機器から遠隔にあるサーバまで，いくつかの通信装置を経由してデータ通信を行っている。とくに，患者宅内での医療機器から通信端末装置までの間を無線通信回線や有線通信回線を経由して情報の送受信を可能にし，さらに通信端末装置からサーバまでの間を公衆通信網などを経由して情報のアップロードを可能にしている。
【０００６】
しかしながら，患者宅では，接続ケーブルを外してしまったり，通信端末装置の電源をオフにしたり，無線通信に不都合な場所に通信端末装置を移動させたりなど，予測できない偶発的な要因により通信障害が発生し，サーバへの通常の運転情報や異常発生時の緊急情報のアップロードができなくなることが予想される。
【０００７】
そのような場合，サーバ側のシステム管理者が患者宅内の通信障害の発生を正確に把握することができず，発生する通信障害に対して復旧のための適切な指示を電話等を介して患者などに与えることができない場合がある。そのため，システム管理者は患者宅を訪問して通信障害の把握と復旧を行わなければならない。
【０００８】
そこで，本発明の目的は，医療機器からサーバに至るデータ送受信経路における通信障害の発生を，サーバ側でより正確に把握することができる医療支援システムを提供することにある。
【課題を解決するための手段】
【０００９】
一つの実施態様によれば，医療支援システムは，患者宅内または医療機関内に設置され運転情報を作成する医療機器と，前記医療機器に接続され前記運転情報を取得する通信端末子機と，前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，前記通信端末子機と通信端末親機は，前記第１の通信媒体に通信障害が発生したときに第１の通信障害情報を記録し，前記通信端末親機は，前記第１の通信障害情報を所定期間間隔のアップロードタイミングで前記サーバにアップロードする。
【００１０】
上記の実施態様によれば，患者宅内の通信端末子機と親機とが第１の通信媒体に発生する通信障害の発生を記録し，その通信障害情報がリアルタイムではなくアップロードタイミングでサーバにアップロードされるので，第２の通信媒体への負担をかけることなくサーバ側での通信障害の検出を可能にする。
【００１１】
上記の実施形態において好ましくは，通信端末親機は，前記医療機器に異常が発生したときに前記医療機器が作成する緊急情報をリアルタイムで前記サーバにアップロードする。
【００１２】
上記の実施態様において好ましくは，前記通信端末親機は，前記第２の通信媒体に通信障害が発生したときに第２の通信障害情報を記録し，前記第１の通信障害情報に加えて前記第２の通信障害情報も前記アップロードタイミングで前記サーバにアップロードする。
【００１３】
同様に，前記医療機器と通信端末子機は，当該医療機器と通信端末子機間で通信障害が発生したときに第３の通信障害情報を記録し，前記通信端末親機は，前記第１の通信障害情報に加えて前記第３の通信障害情報も前記アップロードタイミングで前記サーバにアップロードする。
【００１４】
上記の実施態様において好ましくは，前記第１の通信障害情報と，前記第２または第３の通信障害情報とは，通信障害の発生回数を含む。
【００１５】
上記の実施態様において好ましくは，前記通信端末親機と通信端末子機は，所定時間間隔で送受信を行い，当該送受信では，前記通信端末親機が前記通信端末子機に第１のステータス要求を送信し，前記通信端末子機が前記第１のステータス要求に応答して第１のステータス応答を前記通信端末親機に返信し，前記第１のステータス要求と第１のステータス応答には前記通信端末親機と通信端末子機が記録した第１の通信障害情報が含まれ，前記通信端末親機と通信端末子機とが前記第１の通信障害情報を共有し，さらに，前記通信端末子機と医療機器も，所定時間間隔で送受信を行い，当該送受信では，前記通信端末子機が前記医療機器に第２のステータス要求を送信し，前記医療機器が前記第２のステータス要求に応答して第２のステータス応答を前記通信端末子機に返信し，前記第２のステータス要求と第２のステータス応答には前記通信端末子機と医療機器が記録した第３の通信障害情報が含まれ，前記通信端末子機と医療機器とが前記第３の通信障害情報を共有する。
【００１６】
別の実施態様によれば，患者宅内または医療機関内に設置され運転情報を作成する医療機器と，前記医療機器に接続され前記運転情報を取得する通信端末子機と，前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，前記患者宅または医療機関から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，前記通信端末子機と通信端末親機は，前記第１の通信媒体に，第２の通信媒体に，及び前記通信端末子機と医療機器間に通信障害を検出したときそれぞれ第１，第２，及び第３の通信障害情報を記録し，前記通信端末親機は，前記第１，第２，及び第３の通信障害情報を前記サーバにアップロードする。
【００１７】
上記の別の実施態様によれば，サーバ側で患者宅内のどの通信媒体で通信障害が発生しているかをサーバ側で検出することができる。
【発明の効果】
【００１８】
本発明の医療支援システムによれば，医療機器からサーバに至るデータ送受信経路における通信障害の発生を，サーバ側でより正確に把握することができる。
【発明を実施するための最良の形態】
【００１９】
以下，図面にしたがって本発明の実施の形態について説明する。但し，本発明の技術的範囲はこれらの実施の形態に限定されず，特許請求の範囲に記載された事項とその均等物まで及ぶものである。
【００２０】
図１は，本実施の形態における医療支援システムの一例を示す図である。患者宅や，老人ホームや児童福祉施設などを含む医療機関１００，１１０には，医療用酸素濃縮装置などの在宅療法に使用される医療機器１０と，医療機器１０に通信ケーブル１１などを介して接続される通信端末子機１２と，通信端末子機１２と無線通信媒体もしくは有線通信媒体１３を介して情報通信可能な通信端末親機１４とが設置されている。そして，通信端末親機１４は，公衆電話回線１５０などの公衆通信網を介して，医療機器１０から遠隔の地にあるデータセンタ２００内のサーバ２０に，情報のアップロードを行う。データセンタ内のサーバ２０には，医療機器と患者の情報と，その医療機器の運転情報などを格納するデータベースＤＢが接続されている。このサーバ２０は，例えば，患者宅から遠隔の地に設置されたり，医療機関内の医療機器から離れた場所に設置されたりする。
【００２１】
通信端末子機１２は，医療機器１０の筐体に収納されて通信接続部材を介して接続される場合もある。そして，通信端末親機１４は，患者宅内に設置されている電話のモジュラージャックに電話回線ケーブル１５を接続することで公衆通信網１５０に接続される。よって，通信端末親機１４は，患者宅内の固定電話などの通信機器と公衆通信網１５０を共有しあっている。
【００２２】
通常状態では，医療機器１０である酸素濃縮装置は，空気中の酸素を濃縮して例えば９０％の高い酸素濃度ガスを生成し，患者は医師の処方にしたがって酸素吸入を行う。医療機器１０は，この運転情報，例えば酸素供給を何時，どのくらいの期間，どのくらいの量，行ったかなどの情報を作成し，通信端末子機１２に出力する。そして，通信端末親機１４はこの運転情報を取得し，あらかじめ設定されたアップロードタイミングでサーバ２０にアップロードする。このアップロードタイミングは，例えば２４時間に１回の周期で複数の医療機器それぞれに対して固有に定められたタイミングである。このように複数の医療機器に対してそれぞれのアップロードタイミングを定めることで，サーバへのアップロードが集中することを回避する。また，通信端末親機１４は，患者宅内の通信機器と公衆通信網１５０を共有しているので，アップロードタイミングは，夜間の時間帯に設定されている。
【００２３】
医療機器１０は，異常が発生すると緊急情報を作成する。例えば，酸素濃度または酸素流量などが異常値になった，あるいは，医療機器の各構成部品が定常状態から逸脱した状態となった場合などである。この緊急情報は，通信端末子機１２を経由して通信端末親機１４に供給される。そして，通信端末親機１４は，その緊急情報を，アップロードタイミングを待つことなく，リアルタイムでサーバ２０にアップロードする。
【００２４】
医療機器１０と子機１２とは，それらを接続する通信ケーブル１１での通信障害を検出したら，その通信障害情報をそれぞれが記録する。同様に，子機１２と親機１４も，それらの間の通信媒体１３において通信障害を検出したら，その通信障害情報をそれぞれが記録する。そして，親機１４は，サーバ２０との間で通信障害を検出したらその通信障害情報も記録する。
【００２５】
医療機器１０と子機１２間で，及び子機１２と親機１４間で，所定時間間隔で送受信が繰り返される。これは，患者宅内の医療機器と通信端末との間の正常運転を常時確認するためのものである。医療機器１０と子機１２との間の送受信では，子機１２が所定のインターバル，例えば３０秒などの数十秒のインターバルで医療機器１０にステータス要求を送信し，それに応答して，医療機器１０がステータス応答を返信する。このステータス要求とステータス応答には互いが記録している通信障害情報が相互に含まれ，さらに，ステータス応答には医療機器１０が作成した動作情報と緊急情報とが含まれる。
【００２６】
子機１２と親機１４との間の送受信では，親機１４が所定のインターバル，例えば２秒などの数秒のインターバルで子機１２にステータス要求を送信し，それに応答して子機１２がステータス応答を返信する。この場合も，このステータス要求とステータス応答には互いが記録している通信障害情報が相互に含まれ，さらに，ステータス応答には医療機器１０が作成した動作情報と緊急情報とが含まれる。
【００２７】
これらの送受信により，医療機器が作成した運転情報と緊急情報と，医療機器１０，子機１２が記録した通信障害情報とが，親機１４に供給される。そして，親機１４は，前述のアップロードタイミングで運転情報と通信障害情報とをサーバ２０にアップロードする。また，緊急情報は，リアルタイムでアップロードされる。
【００２８】
親機１４は，サーバ２０へのアップロードを公衆電話回線などの公衆通信網１５０を介して行っている。したがって，アップロードタイミングは２４時間に１回の夜間に設定されている。それにより，患者宅の固定電話などの通信機器の通常動作に支障を与えないようにしている。したがって，医療機器１０の緊急情報を除いて，通常の運転情報と通信障害情報とは，アップロードタイミングでサーバ２０にアップロードされる。一度アップロードされると，親機１４が記憶している通信障害情報はクリアされる。また，子機１２，医療機器１０が記憶している通信障害情報もクリアされる。
【００２９】
図２は，送受信で交換されるメッセージ情報ＭＳＧのフォーマット例を示す図である。このメッセージＭＳＧは，サーバと親機間，医療機器と子機間の通信プロトコルのセッション層のパケットに対応する。このメッセージＭＳＧを構成するパケットは，下位層（トランスポート層，ネットワーク層，データリンク層）のパケットのデータに格納される。そして，データリンク層のパケットには，通信中のデータ誤りを検出するためのＣＲＣコードが含まれている。ＣＲＣとは，Cyclic Redundancy Check（巡回冗長検査）であり，一種の誤り検出符号である。このメッセージＭＳＧが含まれたデータが医療機器から，子機，親機，サーバと伝送される。
【００３０】
メッセージＭＳＧのフォーマットは，ヘッダ部ＨＤとデータ部Ｄａｔａとを有する。ヘッダ部ＨＤは，データ部Ｄａｔａが定常の運転情報か緊急情報かの区別を示すメッセージタイプMtypeと，メッセージMSGが送信される時刻を示すメッセージ送信時刻Time1と，医療機器が運転情報や緊急情報などデータを作成した時刻を示すデータ作成時刻Time2と，医療機器１０のIDを示すMeIDと，通信端末親機のIDを示すMasterIDと，通信端末子機のIDを示すSlaveIDと，通信障害情報を含む通信障害データStatusと，データの長さを示すLengthとが含まれている。そして，データ部Dataには送信対象のデータDataが格納される。
【００３１】
メッセージＭＳＧを受信した機器は，このデータ長Lengthと実際のデータ部Dataのデータ長とを比較して，受信時の通信障害の有無を検知することができる。また，前述のCRCコードを解析することによっても，受信時の通信障害の有無を検知できる。
【００３２】
図３は，メッセージＭＳＧ内のヘッダ部ＨＤの通信障害データStatusのビット構成を示す図である。通信障害データStatusは，通信ケーブル１１，無線回線１３，電話回線１５，１５０のいずれに通信障害が発生したかを区別できるフォーマットにされている。さらに，好ましくは，通信障害の発生回数も含まれる。また，通信障害を検出した機器別に，さらにその機器が検出した通信障害がその機器の送信時か受信時かの区別もできるようになっている。
【００３３】
図３の表には，通信障害が発生した通信媒体と，通信障害を記録する機器別に，通信障害データのビットｂ１〜ｂ１２が示されている。例えば，親機と子機の間の無線回線について説明すると，子機が親機からの受信時に通信障害を検出した場合は，ビットｂ５にそれを記録する。また，子機が親機への送信時に通信障害を検出した場合は，ビットｂ６にそれを記録する。一方，親機が子機からの受信時に通信障害を検出した場合は，ビットｂ７にそれを記録する。また，親機が子機への送信時に通信障害を検出した場合は，ビットｂ８にそれを記録する。つまり，ビットｂ５〜ｂ８には，通信障害を検出した機器別に，また通信障害が発生したと判断される受信，送信の別に，通信障害の発生が記録される。
【００３４】
医療機器１０と子機１２との間の通信ケーブル１１の通信障害は，上記と同様にビットｂ１〜ｂ４に記録される。また，親機１４とサーバ２０との間の電話回線における通信障害については，サーバからの受信時の通信障害とサーバへの送信時の通信障害を検出したときに，親機は，ビットｂ９，ｂ１０にそれぞれ記録する。
【００３５】
上記のビットｂ１〜ｂ１２は，それぞれが１ビットの場合は，通信障害の発生の有無を記録するにとどまる。ただし，好ましくは，このビットｂ１〜ｂ１２は，それぞれが２ビット以上であり，その場合は，ビット数に応じて２のビット数乗−１を最大回数とする通信障害発生回数をビットｂ１〜ｂ１２それぞれに持たせることができる。
【００３６】
医療機器，子機，親機は，それぞれが通信障害を検出したときに対応するビットｂ１〜ｂ１２にその情報を記録する。そして，前述の送受信で，メッセージＭＳＧを交換しあうことで，それぞれが記録した通信障害情報を共有し，親機は全ての機器が記録した通信障害情報を取得する。
【００３７】
図４は，本実施の形態における通信障害の発生とその記録について説明する図である。一例として，通信端末親機１４と子機１２との間のビーコン通信について説明する。
【００３８】
図４（１）は，正常通信であり，親機１４はステータス要求Ｓ１０を子機１２に送信し，それに応答して子機１２はステータス応答Ｓ１１を親機１４に返信する。これらのステータス要求とステータス応答には，それぞれのメッセージＭＳＧが含まれる。よって，親機１４は子機１２が検出した通信障害の情報をビットｂ３〜ｂ６から取得することができる。また，子機１２のメッセージＭＳＧには，医療機器が検出した通信障害情報もビットｂ１，ｂ２に含まれているので，親機１４はそれも取得することができる。親機１４と子機１２は，互いに取得したメッセージＭＳＧ内の通信障害データStatusのうち，他の機器が記録した情報を自らの通信障害データStatusにコピーする。
【００３９】
図４（２）は，親機１４からのステータス要求Ｓ１０が数秒のインターバル期間内に子機１２に受信されない場合であり，子機１２はタイムエラーにより親機からの受信に送信障害３０が発生したことを検出し，ビットｂ５にそれを記録する。一方，親機１４は子機からのステータス応答を受信できずタイムエラーにより子機への送信時または子機からの受信時に通信障害が発生したことを検出し，ビットｂ７，ｂ８にそれを記録する。各ビットが複数ビットからなり通信障害の回数を記録している場合は，各機器は上記の通信障害の発生を検出した時に対応するビットをインクリメントする。
【００４０】
図４（３）は，親機からのステータス要求Ｓ１０が子機により受信されたが，その受信データに誤りが存在することが検出された場合であり，さらに子機からの再送要求Ｓ１２が通信障害３２により親機に受信されない場合である。子機１２は，受信データのＣＲＣチェックなどで受信時の通信障害３１を検出し，ビットｂ５にそれを記録する。親機１４は，タイムエラーにより子機への送信時または子機からの受信時に通信障害が発生したことを検出し，ビットｂ７，ｂ８にそれを記録する。
【００４１】
図４（４）は，図４（３）において，子機１２から親機１４への再送要求Ｓ１２が親機により受信した場合である。子機１２は，受信データのＣＲＣチェックなどで受信時の通信障害を検出し，ビットｂ５にそれを記録し，親機１４は，再送を求められていることから子機への送信時に通信障害が発生したことを検出し，ビットｂ８にそれを記録する。
【００４２】
図４（５）は，子機からのステータス応答Ｓ１１が親機により受信され，それにデータエラーが検出された場合であり，子機は通信障害を検出せず，親機は子機からの受信時の通信障害を検出し，ビットｂ７にそれを記録する。
【００４３】
上記は，通信障害の一例を示して，それらを検出した機器がどのビットにその通信障害を記録または回数のインクリメントを行うかについて説明した。上記以外にも通信障害の例が考えられるが，それぞれに対応して，通信障害を検出した機器が対応するビットにそれを記録する。
【００４４】
医療機器と子機との間も同様である。また，親機とサーバとの間は，親機がサーバにアップロードを試みるもサーバから応答がない場合に，親機は，親機からサーバへの送信にエラーが発生したかまたはサーバからの受信にエラーが発生したかを検出し，ビットｂ９，ｂ１０にそれを記録する。
【００４５】
図５は，本実施の形態においてサーバが通信障害発生箇所別に通信障害を検出することを説明する図である。Ｎｏ．１は，医療機器に異常が発生した場合であり，動作異常に対応して医療機器が緊急情報を作成する。この緊急情報は，メッセージＭＳＧのデータ部Dataに格納され，送受信により，子機１２，親機１４に転送され，親機からのリアルタイムのアップロードによりサーバ２０はその緊急情報を受信する。そして，サーバ２０は，メッセージＭＳＧ内のデータ部Dataを解析することで，医療機器の異常を検出する。Ｎｏ．１では，サーバ２０はメッセージＭＳＧのヘッダ内の通信障害データStatusから発生した通信障害を検出することもできる。
【００４６】
Ｎｏ．２では，医療機器と子機とを接続する通信ケーブル１１に通信障害が発生した場合であり，エラー要因は，例えばケーブルの未接続または伝送データのビットエラーなどが考えられる。この場合，少なくとも子機が記録するメッセージＭＳＧの通信障害データStatusにその通信障害の事実と回数が含まれている。ただし，データ部Dataには何もデータは入っていない（空データ）。そして，送受信によりメッセージＭＳＧを互いに供給しあい，親機１４がサーバ２０にそのメッセージＭＳＧをアップロードするので，メッセージＭＳＧのヘッダ部ＨＤの通信障害データStatusから，サーバ２０は通信媒体１１に通信障害が発生したこと，その発生回数を検出する。なお，ある時刻に通信ケーブル１１にたまたま通信障害が発生したとしても，リトライ時には発生しない場合がある。その場合は，医療機器が記録した通信障害発生の事実と共に発生回数もサーバ２０に供給されるので，サーバ２０は通信媒体の信頼性を判断することができる。
【００４７】
Ｎｏ．３では，子機と親機とを接続する無線通信媒体１３に通信障害が発生した場合であり，エラー要因は，例えば伝送データのビットエラーの発生や，無線通信の異常などが考えられる。この場合，少なくとも親機が記録するメッセージＭＳＧの通信障害データStatusにその通信障害の事実と回数が含まれている。そして，親機がこのメッセージＭＳＧをサーバ２０にアップロードするので，サーバ２０は通信媒体１３に通信障害が発生したことと，その発生回数を検出する。この場合も，ある時刻に無線通信媒体１３に通信障害が発生したとしても，リトライ時には発生しない場合がある。その場合は，医療機器や子機が記録した通信障害発生の事実と共に発生回数もサーバ２０に供給される。
【００４８】
Ｎｏ．４では，親機とサーバ間の電話回線に通信障害が発生した場合であり，エラー要因は，電話回線の異常または伝送データのエラービット発生などである。この場合，電話回線による通信が成功しないかぎり，サーバはデータを受信することはない。しかし，サーバへのアップロードタイミングになってもアップロードがなされないことから，何らかの障害が発生したことは検出できるが，どこに障害が発生しているかを特定することはできない。ただし，リトライ時にアップロードに成功すれば，サーバ２０は，その通信障害の事実と回数を検出することができる。
【００４９】
以上の通り，本実施の形態では，所定時間間隔で行う送受信で互いに交換しあうメッセージのヘッダ部に通信障害データを格納し，通常の動作情報と異常発生時の緊急情報を格納するデータ部の伝達と共に通信障害データも親機に転送し，サーバ２０にアップロードする。これにより，サーバ２０は，患者宅内のどの通信媒体で通信障害が発生しているか，さらにどの程度の頻度で発生しているかを知ることができる。よって，サーバ側のサービス担当者がその通信障害データを解析して，患者宅に連絡し適切な復旧指示を患者に与えることができる。
【００５０】
また，アップロードにより通常の動作情報を受信した場合でも，サーバは，そのメッセージ内の通信障害データStatusを参照することで，その動作情報の伝送に際して発生した通信障害の回数を通信媒体別に知ることができる。
【００５１】
図６は，本実施の形態において医療機器に異常が発生したときの動作シーケンスを示す図である。子機１２と医療機器１０とは，数十秒間隔で行う送受信で，子機１２がステータス要求Ｓ１０−１を医療機器に送信し，それに応答して医療機器がステータス応答Ｓ１１−１を子機に返信している。これらのステータス要求とステータス応答で前述のメッセージＭＳＧが供給される。
【００５２】
ある時点で，医療機器１０に異常４０が発生すると，医療機器１０はその異常発生を知らせる緊急情報を作成しメッセージＭＳＧのデータ部Ｄａｔａに格納する。そして，次の送受信タイミングで，ステータス要求Ｓ１０−２に応答して，ステータス応答Ｓ１１−２でそのメッセージＭＳＧを子機に返信する。
【００５３】
親機１４と子機１２との間では，数秒間隔で行う送受信で，親機１４がステータス要求Ｓ１０−３を子機１２に送信し，それに応答して子機１２が親機１４にステータス応答Ｓ１１−３をメッセージＭＳＧと共に返信する。これにより，親機１４は，メッセージＭＳＧのデータ部の緊急情報を取得する。
【００５４】
そして，親機１４は，メッセージＭＳＧのヘッダ部ＨＤのメッセージタイプが緊急情報であることに応答して，アップロードタイミングを待つことなくリアルタイムで，サーバ２０に発呼Ｓ１３−１を行い，メッセージＭＳＧをデータ送信Ｓ１４−１を行う。データ送信が完了しサーバ２０からの応答確認Ｓ１５−１を受信すると，親機１４は，回線を切断Ｓ１６−１する。これにより，サーバ２０には，リアルタイムで医療機器の緊急情報が伝えられる。この時，サーバ２０は，メッセージＭＳＧの通信障害データStatusも受信する。
【００５５】
なお，親機１４は，アップロードタイミングになると，サーバ２０に対して発呼Ｓ１３−２を行い，それまで蓄積した動作情報を含むメッセージＭＳＧをデータ送信Ｓ１４−２を行い，サーバの応答確認Ｓ１５−２に応答して，回線切断Ｓ１６−２を行う。この時も，サーバ２０は，メッセージＭＳＧ内の通信障害データStatusも受信する。
【００５６】
医療機器に異常が発生した場合は，それを看過すると在宅診療に支障を来すことになるので，リアルタイムで緊急情報をサーバ２０にアップロードし，サーバ側でサービス担当者が緊急措置を講じることができるようにする。
【００５７】
図７は，本実施の形態における子機の医療機器との送受信のフローチャート図である。子機は，酸素濃縮装置などの医療機器にステータス要求を送信する（Ｓ２０）。そして，酸素濃縮装置からタイムアウト時間内にアクノリッジＡＣＫを受信できない場合は（Ｓ２１のＮＯ），再送信要求回数（例えば３回）に達するまで（Ｓ２２のＹＥＳ），ステータス要求の送信を繰り返す（Ｓ２０）。アクノリッジＡＣＫは，前述のステータス応答である。そして，再送信要求回数に達したら（Ｓ２２のＮＯ），子機は，子機と医療機器間の通信媒体（ケーブル）に送信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ２３）。通信障害フラグとは，前述の通信障害データStatusのビットｂ３，ｂ４である。
【００５８】
さらに，子機は，タイムアウト内にアクノリッジＡＣＫを受信したら（Ｓ２１のＹＥＳ），受信データが正常か否かをＣＲＣコードなどを利用してチェックする（Ｓ２４）。データエラーが検出されたら，受信時に通信障害が発生したことが検出され，対応する通信障害フラグｂ３にフラグを立てる（Ｓ２５）。また，データエラーが検出されなければ通信障害フラグは記録されない（Ｓ２６）。
【００５９】
図８は，本実施の形態における子機の親機との送受信のフローチャート図である。子機は，親機からステータス要求を受信し（Ｓ３０），受信データが正常か否かをＣＲＣコードなどによりチェックする（Ｓ３１）。もしデータエラーが検出されたら，子機は，親機からの受信時に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ３２）。つまり，通信障害データのビットｂ５にフラグを立てる。
【００６０】
さらに，子機は，親機にステータス応答を送信する（Ｓ３３）。これに対する親機からのアクノリッジＡＣＫをタイムアウト時間内に受信できなければ（Ｓ３４のＮＯ），再送信要求回数に達するまで（Ｓ３５のＹＥＳ），ステータス応答の送信Ｓ３３を繰り返す。再送信要求回数に達するまで親機からのアクノリッジＡＣＫを受信できなければ，子機は，親機への送信または親機からの受信に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ３６）。例えば，通信障害データのビットｂ５，ｂ６にフラグを立てる。アクノリッジＡＣＫを受信できれば，通信障害フラグは立てない（Ｓ３７）。
【００６１】
図９は，本実施の形態において子機と医療機器との間で通信障害が発生したときの動作シーケンスを示す図である。子機１２は，医療機器１０にステータス要求Ｓ１０−１を送信する。これに応答して，医療機器１０はステータス応答Ｓ１１−１を返信する。ある時点で，子機からのステータス要求Ｓ１０−２に対して医療機器からのステータス応答を受信できない場合は，子機は，医療機器との間の通信媒体に通信障害４１が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ２３）。この通信障害フラグは，図７の工程Ｓ２３でのフラグと同じであり，ビットｂ３，ｂ４である。
【００６２】
その後，親機１４が，たとえば数秒間隔の送受信で，ステータス要求Ｓ１０−３を子機１２に送信し，子機１２は，それに応答して，ステータス応答Ｓ１１−３を親機１４に返信する。このステータス応答にはメッセージＭＳＧが含まれ，親機１４は，メッセージ内の通信障害データStatus内のビットｂ３，ｂ４から子機と医療機器間の通信障害の情報を取得する。
【００６３】
そして，親機は，アップロードタイミングでサーバ２０に発呼Ｓ１３−２を行い，データ送信Ｓ１４−２を行う。この送信データには，メッセージＭＳＧが含まれ，そのヘッダには通信障害データStatusが含まれ，データ部Dataには通常の運転情報が含まれる。そして，親機は，サーバからの応答Ｓ１５−２に応答して，回線を切断する（Ｓ１６−２）。親機は，サーバへのアップロードに成功すると，それまでの通信障害データをクリアする。同様に，子機，医療機器もそれまでの通信障害データをクリアする。
【００６４】
以上のとおり，子機と親機とは，子機と医療機器との間の通信障害データを共有しあう。これは，子機と親機のいずれかが電源オフにより記憶データを失った場合でも，電源オン後に送受信によりメッセージを供給しあってデータの復帰を行うことができるようにするためである。
【００６５】
また，親機は，通信障害データが存在していても，異常情報のようにリアルタイムでサーバにアップロードすることはしない。通信障害は比較的小さくない頻度で発生しがちであり，偶発的に発生することもあり，通信障害が発生するたびにサーバにアップロードすると，公衆通信網の回線を頻繁に使用することになり，患者宅または医療機関の公衆通信網の回線に負担を強いることになるからである。また，偶発的に通信障害が発生してもリトライにより成功する場合があり，医療機器の異常発生よりも緊急性が低いからである。
【００６６】
図１０は，本実施の形態における親機の子機との送受信のフローチャート図である。図１０は，図７と類似している。つまり，親機は，数秒間隔で行う送受信により，子機にステータス要求を送信する（Ｓ４０）。そして，親機は，子機からタイムアウト時間内にアクノリッジＡＣＫを受信できない場合は（Ｓ４１のＮＯ），再送信要求回数（例えば３回）に達するまで（Ｓ４２のＹＥＳ），ステータス要求の送信Ｓ４０を繰り返す。再送要求回数までにアクノリッジＡＣＫを受信できない場合は（Ｓ４２のＮＯ），親機は，通信媒体１３に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ４３）。このフラグは，前述のビットｂ７，ｂ８に対応する。
【００６７】
また，親機は，アクノリッジＡＣＫに対応するステータス応答の受信データが正常か否かをＣＲＣコードなどによりチェックする（Ｓ４４）。データエラーが検出されると（Ｓ４４のＮＯ），親機は，子機からの受信時に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ４５）。このフラグは，ビットｂ７に対応する。また，データエラーが検出されなければ，通信障害フラグは立てない（Ｓ４６）。
【００６８】
図１１は，本実施の形態における親機のサーバへのアップロードのフローチャート図である。親機は，あらかじめ決められたアップロードタイミングでサーバに発呼を行う（Ｓ５０）。そして，サーバにメッセージＭＳＧを含むデータを送信する（Ｓ５１）。このデータ送信に対してサーバからタイムアウト時間内にアクノリッジ信号ＡＣＫを受信できないときは（Ｓ５２のＮＯ），再送要求回数に達するまで（Ｓ５３のＹＥＳ），データ送信Ｓ５１を繰り返す。採用要求回数に達してもアクノリッジ信号ＡＣＫを受信できないときは（Ｓ５３のＮＯ），親機は公衆通信網の通信障害を検出し，対応する通信障害フラグを立てる（Ｓ５４）。このフラグは，ビットｂ９，ｂ１０に対応する。
【００６９】
また，親機は，サーバからのアクノリッジ信号ＡＣＫの受信データが正常か否かをＣＲＣコードなどにより行い（Ｓ５５），エラーが検出されると対応する通信障害フラグを立てる（Ｓ５６）。例えばこのフラグは，ビットｂ９に対応する。エラーが検出されなければフラグは立てない（Ｓ５７）。
【００７０】
図１２は，本実施の形態において親機と子機との間で通信障害が発生したときの動作シーケンスを示す図である。親機は，送受信により，子機に対してステータス要求Ｓ１０−３を送信する。しかし，タイムアウト時間内に子機からのステータス応答を規定回数トライしても受信できない場合は，親機は子機との通信媒体１３に通信障害４２が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ４３）。この場合は，子機への送信または子機からの受信で通信障害が発生した可能性があり，ビットｂ７，ｂ８に記録される。
【００７１】
親機１４は，アップロードタイミングになると，サーバ２０に発呼Ｓ１３−２を行い，データ送信Ｓ１４−２を行う。この送信データにはメッセージＭＳＧが含まれ，そのヘッダＨＤには通信障害データStatusが含まれ，データ部Dataには通常の運転情報が含まれる。そして，親機は，サーバからの応答Ｓ１５−２に応答して回線を切断する（Ｓ１６−２）。親機は，サーバへのアップロードに成功すると，それまでの通信障害データをクリアする。同様に，子機，医療機器もそれまでの通信障害データをクリアする。
【００７２】
親機１４と子機１２とは，互いの通信障害データを共有しあい，いずれかが電源オフになってそのデータが消失しても，その後の電源オンの後にデータの復帰ができるようにしている。そして，親機１４は，通信障害データを通常の運転データとともに，２４時間に１回のアップロードタイミングでサーバ２０にアップロードする。
【００７３】
サーバ２０は，アップロードされたメッセージＭＳＧ内の通信障害データStatusを解析することで，患者宅内の通信媒体１１，１３及び公衆通信網１５０のどれかに通信障害が発生していること，さらに，好ましくはアップロードタイミング間の発生回数を検出することができる。それにより，サーバ側のサービス担当者は患者宅に電話連絡をして通信障害への対応策を適切に指示することができる。
【００７４】
例えば，発生回数が多い通信媒体１１，１３，１５０の疑われる障害に基づいて医療機器１０，ケーブル１１，子機１２，親機１４，それらの間の無線環境，親機１４から公衆通信網１５０への接続配線１５などについて，必要な措置を指示する。
【００７５】
上記の実施の形態では，医療機器として医療用酸素濃縮装置を例にして説明したが，それ以外にも，在宅療法に使用される医療機器としては，超音波治療器，成人用人工呼吸器などがある。また，医療機器は，患者宅内に設置される場合以外に，医療機関内に設置される場合もあるが，そのような場合でも，本実施の形態を適用することができる。
【００７６】
また，上記の公衆通信網は，酸素濃縮機と通信端末機とが設置される患者宅や医療機関に設置される電話機その他の通信機器（ファクシミリ、インターネットに接続されるパーソナルコンピュータなど）と共有される公衆通信網（たとえば有線通信手段あるいは無線通信手段を用いて実現されるインターネット、携帯電話通信網、またはＰＨＳ通信網などを含む公衆通信網）であれば，本実施の形態に適用できる。
【図面の簡単な説明】
【００７７】
【図１】本実施の形態における医療支援システムの一例を示す図である。
【図２】送受信で交換されるメッセージ情報ＭＳＧのフォーマット例を示す図である。
【図３】メッセージＭＳＧ内のヘッダ部ＨＤの通信障害データStatusのビット構成を示す図である。
【図４】本実施の形態における通信障害の発生とその記録について説明する図である。
【図５】本実施の形態においてサーバが通信障害発生箇所別に通信障害を検出することを説明する図である。
【図６】本実施の形態において医療機器に異常が発生したときの動作シーケンスを示す図である。
【図７】本実施の形態における子機の医療機器との送受信のフローチャート図である。
【図８】本実施の形態における子機の親機との送受信のフローチャート図である。
【図９】本実施の形態において子機と医療機器との間で通信障害が発生したときの動作シーケンスを示す図である。
【図１０】本実施の形態における親機の子機との送受信のフローチャート図である。
【図１１】本実施の形態における親機のサーバへのアップロードのフローチャート図である。
【図１２】本実施の形態において親機と子機との間で通信障害が発生したときの動作シーケンスを示す図である。
【符号の説明】
【００７８】
１００．１１０：患者宅または医療機関
１０：医療機器，酸素濃縮装置
１２：通信端末子機
１４：通信端末親機
１５０：公衆通信網
２０：サーバ
ＤＢ：データベース
【技術分野】
【０００１】
本発明は，医療支援システムに関し，特に，患者宅内または医療機関内に設置され運転情報を作成する医療機器と，医療機器に接続され運転情報を取得する通信端末子機と，通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，前記患者宅または医療機関から遠隔の地に設置され通信端末親機から第２の通信媒体を介して運転情報を含む情報をアップロードされるサーバとを有する医療支援システムに関する。
【背景技術】
【０００２】
近年，喘息，肺気腫症，慢性気管支炎などの呼吸器系器官の疾患に苦しむ患者が増加する傾向にあるが，その治療法として効果的なもののひとつに酸素吸入療法がある。酸素吸入療法とは，酸素ガスあるいは酸素富化空気を患者に吸入させるものである。その酸素供給源として，酸素濃縮装置，液体酸素，酸素ガスボンベなどが知られているが，使用時の便利さや保守管理の容易さから，在宅酸素療法には医療用酸素濃縮装置が最もよく利用されている。
【０００３】
この医療用酸素濃縮装置は，病院などの医療機関のみならず在宅療法のために患者宅においても使用されている。在宅酸素療法では，病院内とは異なり医師や看護師の監視下で使用されないので，装置の状態を把握することができず，患者が医師から処方されたとおりに正しい設定で使用しているか否か，取扱説明書の記載とおりに正しい使用方法を遵守しているか否かを確認することは困難である。
【０００４】
そこで，酸素濃縮装置による在宅療法を適切に行うために，酸素濃縮装置に通信端末装置を接続し，遠隔にあるサーバに酸素濃縮器の通常の運転情報や異常時の緊急情報を送信することが提案されている。サーバには，酸素濃縮装置などの医療機器とその運転情報とを有するデータベースが備えられ，サーバは，通信端末装置からアップロードされる運転情報をデータベースに格納し，それを分析して適切に使用されているか否かのチェックを行い，緊急情報により医療機器の異常を早期に発見する。このような医療支援システムが，特許文献１，２，３に記載されている。
【特許文献１】特開平３−１４３４５１号公報
【特許文献２】特開平６−５４９１０号公報
【特許文献３】特開２００５−２４５７３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
この医療支援システムでは，患者宅内の医療機器から遠隔にあるサーバまで，いくつかの通信装置を経由してデータ通信を行っている。とくに，患者宅内での医療機器から通信端末装置までの間を無線通信回線や有線通信回線を経由して情報の送受信を可能にし，さらに通信端末装置からサーバまでの間を公衆通信網などを経由して情報のアップロードを可能にしている。
【０００６】
しかしながら，患者宅では，接続ケーブルを外してしまったり，通信端末装置の電源をオフにしたり，無線通信に不都合な場所に通信端末装置を移動させたりなど，予測できない偶発的な要因により通信障害が発生し，サーバへの通常の運転情報や異常発生時の緊急情報のアップロードができなくなることが予想される。
【０００７】
そのような場合，サーバ側のシステム管理者が患者宅内の通信障害の発生を正確に把握することができず，発生する通信障害に対して復旧のための適切な指示を電話等を介して患者などに与えることができない場合がある。そのため，システム管理者は患者宅を訪問して通信障害の把握と復旧を行わなければならない。
【０００８】
そこで，本発明の目的は，医療機器からサーバに至るデータ送受信経路における通信障害の発生を，サーバ側でより正確に把握することができる医療支援システムを提供することにある。
【課題を解決するための手段】
【０００９】
一つの実施態様によれば，医療支援システムは，患者宅内または医療機関内に設置され運転情報を作成する医療機器と，前記医療機器に接続され前記運転情報を取得する通信端末子機と，前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，前記通信端末子機と通信端末親機は，前記第１の通信媒体に通信障害が発生したときに第１の通信障害情報を記録し，前記通信端末親機は，前記第１の通信障害情報を所定期間間隔のアップロードタイミングで前記サーバにアップロードする。
【００１０】
上記の実施態様によれば，患者宅内の通信端末子機と親機とが第１の通信媒体に発生する通信障害の発生を記録し，その通信障害情報がリアルタイムではなくアップロードタイミングでサーバにアップロードされるので，第２の通信媒体への負担をかけることなくサーバ側での通信障害の検出を可能にする。
【００１１】
上記の実施形態において好ましくは，通信端末親機は，前記医療機器に異常が発生したときに前記医療機器が作成する緊急情報をリアルタイムで前記サーバにアップロードする。
【００１２】
上記の実施態様において好ましくは，前記通信端末親機は，前記第２の通信媒体に通信障害が発生したときに第２の通信障害情報を記録し，前記第１の通信障害情報に加えて前記第２の通信障害情報も前記アップロードタイミングで前記サーバにアップロードする。
【００１３】
同様に，前記医療機器と通信端末子機は，当該医療機器と通信端末子機間で通信障害が発生したときに第３の通信障害情報を記録し，前記通信端末親機は，前記第１の通信障害情報に加えて前記第３の通信障害情報も前記アップロードタイミングで前記サーバにアップロードする。
【００１４】
上記の実施態様において好ましくは，前記第１の通信障害情報と，前記第２または第３の通信障害情報とは，通信障害の発生回数を含む。
【００１５】
上記の実施態様において好ましくは，前記通信端末親機と通信端末子機は，所定時間間隔で送受信を行い，当該送受信では，前記通信端末親機が前記通信端末子機に第１のステータス要求を送信し，前記通信端末子機が前記第１のステータス要求に応答して第１のステータス応答を前記通信端末親機に返信し，前記第１のステータス要求と第１のステータス応答には前記通信端末親機と通信端末子機が記録した第１の通信障害情報が含まれ，前記通信端末親機と通信端末子機とが前記第１の通信障害情報を共有し，さらに，前記通信端末子機と医療機器も，所定時間間隔で送受信を行い，当該送受信では，前記通信端末子機が前記医療機器に第２のステータス要求を送信し，前記医療機器が前記第２のステータス要求に応答して第２のステータス応答を前記通信端末子機に返信し，前記第２のステータス要求と第２のステータス応答には前記通信端末子機と医療機器が記録した第３の通信障害情報が含まれ，前記通信端末子機と医療機器とが前記第３の通信障害情報を共有する。
【００１６】
別の実施態様によれば，患者宅内または医療機関内に設置され運転情報を作成する医療機器と，前記医療機器に接続され前記運転情報を取得する通信端末子機と，前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，前記患者宅または医療機関から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，前記通信端末子機と通信端末親機は，前記第１の通信媒体に，第２の通信媒体に，及び前記通信端末子機と医療機器間に通信障害を検出したときそれぞれ第１，第２，及び第３の通信障害情報を記録し，前記通信端末親機は，前記第１，第２，及び第３の通信障害情報を前記サーバにアップロードする。
【００１７】
上記の別の実施態様によれば，サーバ側で患者宅内のどの通信媒体で通信障害が発生しているかをサーバ側で検出することができる。
【発明の効果】
【００１８】
本発明の医療支援システムによれば，医療機器からサーバに至るデータ送受信経路における通信障害の発生を，サーバ側でより正確に把握することができる。
【発明を実施するための最良の形態】
【００１９】
以下，図面にしたがって本発明の実施の形態について説明する。但し，本発明の技術的範囲はこれらの実施の形態に限定されず，特許請求の範囲に記載された事項とその均等物まで及ぶものである。
【００２０】
図１は，本実施の形態における医療支援システムの一例を示す図である。患者宅や，老人ホームや児童福祉施設などを含む医療機関１００，１１０には，医療用酸素濃縮装置などの在宅療法に使用される医療機器１０と，医療機器１０に通信ケーブル１１などを介して接続される通信端末子機１２と，通信端末子機１２と無線通信媒体もしくは有線通信媒体１３を介して情報通信可能な通信端末親機１４とが設置されている。そして，通信端末親機１４は，公衆電話回線１５０などの公衆通信網を介して，医療機器１０から遠隔の地にあるデータセンタ２００内のサーバ２０に，情報のアップロードを行う。データセンタ内のサーバ２０には，医療機器と患者の情報と，その医療機器の運転情報などを格納するデータベースＤＢが接続されている。このサーバ２０は，例えば，患者宅から遠隔の地に設置されたり，医療機関内の医療機器から離れた場所に設置されたりする。
【００２１】
通信端末子機１２は，医療機器１０の筐体に収納されて通信接続部材を介して接続される場合もある。そして，通信端末親機１４は，患者宅内に設置されている電話のモジュラージャックに電話回線ケーブル１５を接続することで公衆通信網１５０に接続される。よって，通信端末親機１４は，患者宅内の固定電話などの通信機器と公衆通信網１５０を共有しあっている。
【００２２】
通常状態では，医療機器１０である酸素濃縮装置は，空気中の酸素を濃縮して例えば９０％の高い酸素濃度ガスを生成し，患者は医師の処方にしたがって酸素吸入を行う。医療機器１０は，この運転情報，例えば酸素供給を何時，どのくらいの期間，どのくらいの量，行ったかなどの情報を作成し，通信端末子機１２に出力する。そして，通信端末親機１４はこの運転情報を取得し，あらかじめ設定されたアップロードタイミングでサーバ２０にアップロードする。このアップロードタイミングは，例えば２４時間に１回の周期で複数の医療機器それぞれに対して固有に定められたタイミングである。このように複数の医療機器に対してそれぞれのアップロードタイミングを定めることで，サーバへのアップロードが集中することを回避する。また，通信端末親機１４は，患者宅内の通信機器と公衆通信網１５０を共有しているので，アップロードタイミングは，夜間の時間帯に設定されている。
【００２３】
医療機器１０は，異常が発生すると緊急情報を作成する。例えば，酸素濃度または酸素流量などが異常値になった，あるいは，医療機器の各構成部品が定常状態から逸脱した状態となった場合などである。この緊急情報は，通信端末子機１２を経由して通信端末親機１４に供給される。そして，通信端末親機１４は，その緊急情報を，アップロードタイミングを待つことなく，リアルタイムでサーバ２０にアップロードする。
【００２４】
医療機器１０と子機１２とは，それらを接続する通信ケーブル１１での通信障害を検出したら，その通信障害情報をそれぞれが記録する。同様に，子機１２と親機１４も，それらの間の通信媒体１３において通信障害を検出したら，その通信障害情報をそれぞれが記録する。そして，親機１４は，サーバ２０との間で通信障害を検出したらその通信障害情報も記録する。
【００２５】
医療機器１０と子機１２間で，及び子機１２と親機１４間で，所定時間間隔で送受信が繰り返される。これは，患者宅内の医療機器と通信端末との間の正常運転を常時確認するためのものである。医療機器１０と子機１２との間の送受信では，子機１２が所定のインターバル，例えば３０秒などの数十秒のインターバルで医療機器１０にステータス要求を送信し，それに応答して，医療機器１０がステータス応答を返信する。このステータス要求とステータス応答には互いが記録している通信障害情報が相互に含まれ，さらに，ステータス応答には医療機器１０が作成した動作情報と緊急情報とが含まれる。
【００２６】
子機１２と親機１４との間の送受信では，親機１４が所定のインターバル，例えば２秒などの数秒のインターバルで子機１２にステータス要求を送信し，それに応答して子機１２がステータス応答を返信する。この場合も，このステータス要求とステータス応答には互いが記録している通信障害情報が相互に含まれ，さらに，ステータス応答には医療機器１０が作成した動作情報と緊急情報とが含まれる。
【００２７】
これらの送受信により，医療機器が作成した運転情報と緊急情報と，医療機器１０，子機１２が記録した通信障害情報とが，親機１４に供給される。そして，親機１４は，前述のアップロードタイミングで運転情報と通信障害情報とをサーバ２０にアップロードする。また，緊急情報は，リアルタイムでアップロードされる。
【００２８】
親機１４は，サーバ２０へのアップロードを公衆電話回線などの公衆通信網１５０を介して行っている。したがって，アップロードタイミングは２４時間に１回の夜間に設定されている。それにより，患者宅の固定電話などの通信機器の通常動作に支障を与えないようにしている。したがって，医療機器１０の緊急情報を除いて，通常の運転情報と通信障害情報とは，アップロードタイミングでサーバ２０にアップロードされる。一度アップロードされると，親機１４が記憶している通信障害情報はクリアされる。また，子機１２，医療機器１０が記憶している通信障害情報もクリアされる。
【００２９】
図２は，送受信で交換されるメッセージ情報ＭＳＧのフォーマット例を示す図である。このメッセージＭＳＧは，サーバと親機間，医療機器と子機間の通信プロトコルのセッション層のパケットに対応する。このメッセージＭＳＧを構成するパケットは，下位層（トランスポート層，ネットワーク層，データリンク層）のパケットのデータに格納される。そして，データリンク層のパケットには，通信中のデータ誤りを検出するためのＣＲＣコードが含まれている。ＣＲＣとは，Cyclic Redundancy Check（巡回冗長検査）であり，一種の誤り検出符号である。このメッセージＭＳＧが含まれたデータが医療機器から，子機，親機，サーバと伝送される。
【００３０】
メッセージＭＳＧのフォーマットは，ヘッダ部ＨＤとデータ部Ｄａｔａとを有する。ヘッダ部ＨＤは，データ部Ｄａｔａが定常の運転情報か緊急情報かの区別を示すメッセージタイプMtypeと，メッセージMSGが送信される時刻を示すメッセージ送信時刻Time1と，医療機器が運転情報や緊急情報などデータを作成した時刻を示すデータ作成時刻Time2と，医療機器１０のIDを示すMeIDと，通信端末親機のIDを示すMasterIDと，通信端末子機のIDを示すSlaveIDと，通信障害情報を含む通信障害データStatusと，データの長さを示すLengthとが含まれている。そして，データ部Dataには送信対象のデータDataが格納される。
【００３１】
メッセージＭＳＧを受信した機器は，このデータ長Lengthと実際のデータ部Dataのデータ長とを比較して，受信時の通信障害の有無を検知することができる。また，前述のCRCコードを解析することによっても，受信時の通信障害の有無を検知できる。
【００３２】
図３は，メッセージＭＳＧ内のヘッダ部ＨＤの通信障害データStatusのビット構成を示す図である。通信障害データStatusは，通信ケーブル１１，無線回線１３，電話回線１５，１５０のいずれに通信障害が発生したかを区別できるフォーマットにされている。さらに，好ましくは，通信障害の発生回数も含まれる。また，通信障害を検出した機器別に，さらにその機器が検出した通信障害がその機器の送信時か受信時かの区別もできるようになっている。
【００３３】
図３の表には，通信障害が発生した通信媒体と，通信障害を記録する機器別に，通信障害データのビットｂ１〜ｂ１２が示されている。例えば，親機と子機の間の無線回線について説明すると，子機が親機からの受信時に通信障害を検出した場合は，ビットｂ５にそれを記録する。また，子機が親機への送信時に通信障害を検出した場合は，ビットｂ６にそれを記録する。一方，親機が子機からの受信時に通信障害を検出した場合は，ビットｂ７にそれを記録する。また，親機が子機への送信時に通信障害を検出した場合は，ビットｂ８にそれを記録する。つまり，ビットｂ５〜ｂ８には，通信障害を検出した機器別に，また通信障害が発生したと判断される受信，送信の別に，通信障害の発生が記録される。
【００３４】
医療機器１０と子機１２との間の通信ケーブル１１の通信障害は，上記と同様にビットｂ１〜ｂ４に記録される。また，親機１４とサーバ２０との間の電話回線における通信障害については，サーバからの受信時の通信障害とサーバへの送信時の通信障害を検出したときに，親機は，ビットｂ９，ｂ１０にそれぞれ記録する。
【００３５】
上記のビットｂ１〜ｂ１２は，それぞれが１ビットの場合は，通信障害の発生の有無を記録するにとどまる。ただし，好ましくは，このビットｂ１〜ｂ１２は，それぞれが２ビット以上であり，その場合は，ビット数に応じて２のビット数乗−１を最大回数とする通信障害発生回数をビットｂ１〜ｂ１２それぞれに持たせることができる。
【００３６】
医療機器，子機，親機は，それぞれが通信障害を検出したときに対応するビットｂ１〜ｂ１２にその情報を記録する。そして，前述の送受信で，メッセージＭＳＧを交換しあうことで，それぞれが記録した通信障害情報を共有し，親機は全ての機器が記録した通信障害情報を取得する。
【００３７】
図４は，本実施の形態における通信障害の発生とその記録について説明する図である。一例として，通信端末親機１４と子機１２との間のビーコン通信について説明する。
【００３８】
図４（１）は，正常通信であり，親機１４はステータス要求Ｓ１０を子機１２に送信し，それに応答して子機１２はステータス応答Ｓ１１を親機１４に返信する。これらのステータス要求とステータス応答には，それぞれのメッセージＭＳＧが含まれる。よって，親機１４は子機１２が検出した通信障害の情報をビットｂ３〜ｂ６から取得することができる。また，子機１２のメッセージＭＳＧには，医療機器が検出した通信障害情報もビットｂ１，ｂ２に含まれているので，親機１４はそれも取得することができる。親機１４と子機１２は，互いに取得したメッセージＭＳＧ内の通信障害データStatusのうち，他の機器が記録した情報を自らの通信障害データStatusにコピーする。
【００３９】
図４（２）は，親機１４からのステータス要求Ｓ１０が数秒のインターバル期間内に子機１２に受信されない場合であり，子機１２はタイムエラーにより親機からの受信に送信障害３０が発生したことを検出し，ビットｂ５にそれを記録する。一方，親機１４は子機からのステータス応答を受信できずタイムエラーにより子機への送信時または子機からの受信時に通信障害が発生したことを検出し，ビットｂ７，ｂ８にそれを記録する。各ビットが複数ビットからなり通信障害の回数を記録している場合は，各機器は上記の通信障害の発生を検出した時に対応するビットをインクリメントする。
【００４０】
図４（３）は，親機からのステータス要求Ｓ１０が子機により受信されたが，その受信データに誤りが存在することが検出された場合であり，さらに子機からの再送要求Ｓ１２が通信障害３２により親機に受信されない場合である。子機１２は，受信データのＣＲＣチェックなどで受信時の通信障害３１を検出し，ビットｂ５にそれを記録する。親機１４は，タイムエラーにより子機への送信時または子機からの受信時に通信障害が発生したことを検出し，ビットｂ７，ｂ８にそれを記録する。
【００４１】
図４（４）は，図４（３）において，子機１２から親機１４への再送要求Ｓ１２が親機により受信した場合である。子機１２は，受信データのＣＲＣチェックなどで受信時の通信障害を検出し，ビットｂ５にそれを記録し，親機１４は，再送を求められていることから子機への送信時に通信障害が発生したことを検出し，ビットｂ８にそれを記録する。
【００４２】
図４（５）は，子機からのステータス応答Ｓ１１が親機により受信され，それにデータエラーが検出された場合であり，子機は通信障害を検出せず，親機は子機からの受信時の通信障害を検出し，ビットｂ７にそれを記録する。
【００４３】
上記は，通信障害の一例を示して，それらを検出した機器がどのビットにその通信障害を記録または回数のインクリメントを行うかについて説明した。上記以外にも通信障害の例が考えられるが，それぞれに対応して，通信障害を検出した機器が対応するビットにそれを記録する。
【００４４】
医療機器と子機との間も同様である。また，親機とサーバとの間は，親機がサーバにアップロードを試みるもサーバから応答がない場合に，親機は，親機からサーバへの送信にエラーが発生したかまたはサーバからの受信にエラーが発生したかを検出し，ビットｂ９，ｂ１０にそれを記録する。
【００４５】
図５は，本実施の形態においてサーバが通信障害発生箇所別に通信障害を検出することを説明する図である。Ｎｏ．１は，医療機器に異常が発生した場合であり，動作異常に対応して医療機器が緊急情報を作成する。この緊急情報は，メッセージＭＳＧのデータ部Dataに格納され，送受信により，子機１２，親機１４に転送され，親機からのリアルタイムのアップロードによりサーバ２０はその緊急情報を受信する。そして，サーバ２０は，メッセージＭＳＧ内のデータ部Dataを解析することで，医療機器の異常を検出する。Ｎｏ．１では，サーバ２０はメッセージＭＳＧのヘッダ内の通信障害データStatusから発生した通信障害を検出することもできる。
【００４６】
Ｎｏ．２では，医療機器と子機とを接続する通信ケーブル１１に通信障害が発生した場合であり，エラー要因は，例えばケーブルの未接続または伝送データのビットエラーなどが考えられる。この場合，少なくとも子機が記録するメッセージＭＳＧの通信障害データStatusにその通信障害の事実と回数が含まれている。ただし，データ部Dataには何もデータは入っていない（空データ）。そして，送受信によりメッセージＭＳＧを互いに供給しあい，親機１４がサーバ２０にそのメッセージＭＳＧをアップロードするので，メッセージＭＳＧのヘッダ部ＨＤの通信障害データStatusから，サーバ２０は通信媒体１１に通信障害が発生したこと，その発生回数を検出する。なお，ある時刻に通信ケーブル１１にたまたま通信障害が発生したとしても，リトライ時には発生しない場合がある。その場合は，医療機器が記録した通信障害発生の事実と共に発生回数もサーバ２０に供給されるので，サーバ２０は通信媒体の信頼性を判断することができる。
【００４７】
Ｎｏ．３では，子機と親機とを接続する無線通信媒体１３に通信障害が発生した場合であり，エラー要因は，例えば伝送データのビットエラーの発生や，無線通信の異常などが考えられる。この場合，少なくとも親機が記録するメッセージＭＳＧの通信障害データStatusにその通信障害の事実と回数が含まれている。そして，親機がこのメッセージＭＳＧをサーバ２０にアップロードするので，サーバ２０は通信媒体１３に通信障害が発生したことと，その発生回数を検出する。この場合も，ある時刻に無線通信媒体１３に通信障害が発生したとしても，リトライ時には発生しない場合がある。その場合は，医療機器や子機が記録した通信障害発生の事実と共に発生回数もサーバ２０に供給される。
【００４８】
Ｎｏ．４では，親機とサーバ間の電話回線に通信障害が発生した場合であり，エラー要因は，電話回線の異常または伝送データのエラービット発生などである。この場合，電話回線による通信が成功しないかぎり，サーバはデータを受信することはない。しかし，サーバへのアップロードタイミングになってもアップロードがなされないことから，何らかの障害が発生したことは検出できるが，どこに障害が発生しているかを特定することはできない。ただし，リトライ時にアップロードに成功すれば，サーバ２０は，その通信障害の事実と回数を検出することができる。
【００４９】
以上の通り，本実施の形態では，所定時間間隔で行う送受信で互いに交換しあうメッセージのヘッダ部に通信障害データを格納し，通常の動作情報と異常発生時の緊急情報を格納するデータ部の伝達と共に通信障害データも親機に転送し，サーバ２０にアップロードする。これにより，サーバ２０は，患者宅内のどの通信媒体で通信障害が発生しているか，さらにどの程度の頻度で発生しているかを知ることができる。よって，サーバ側のサービス担当者がその通信障害データを解析して，患者宅に連絡し適切な復旧指示を患者に与えることができる。
【００５０】
また，アップロードにより通常の動作情報を受信した場合でも，サーバは，そのメッセージ内の通信障害データStatusを参照することで，その動作情報の伝送に際して発生した通信障害の回数を通信媒体別に知ることができる。
【００５１】
図６は，本実施の形態において医療機器に異常が発生したときの動作シーケンスを示す図である。子機１２と医療機器１０とは，数十秒間隔で行う送受信で，子機１２がステータス要求Ｓ１０−１を医療機器に送信し，それに応答して医療機器がステータス応答Ｓ１１−１を子機に返信している。これらのステータス要求とステータス応答で前述のメッセージＭＳＧが供給される。
【００５２】
ある時点で，医療機器１０に異常４０が発生すると，医療機器１０はその異常発生を知らせる緊急情報を作成しメッセージＭＳＧのデータ部Ｄａｔａに格納する。そして，次の送受信タイミングで，ステータス要求Ｓ１０−２に応答して，ステータス応答Ｓ１１−２でそのメッセージＭＳＧを子機に返信する。
【００５３】
親機１４と子機１２との間では，数秒間隔で行う送受信で，親機１４がステータス要求Ｓ１０−３を子機１２に送信し，それに応答して子機１２が親機１４にステータス応答Ｓ１１−３をメッセージＭＳＧと共に返信する。これにより，親機１４は，メッセージＭＳＧのデータ部の緊急情報を取得する。
【００５４】
そして，親機１４は，メッセージＭＳＧのヘッダ部ＨＤのメッセージタイプが緊急情報であることに応答して，アップロードタイミングを待つことなくリアルタイムで，サーバ２０に発呼Ｓ１３−１を行い，メッセージＭＳＧをデータ送信Ｓ１４−１を行う。データ送信が完了しサーバ２０からの応答確認Ｓ１５−１を受信すると，親機１４は，回線を切断Ｓ１６−１する。これにより，サーバ２０には，リアルタイムで医療機器の緊急情報が伝えられる。この時，サーバ２０は，メッセージＭＳＧの通信障害データStatusも受信する。
【００５５】
なお，親機１４は，アップロードタイミングになると，サーバ２０に対して発呼Ｓ１３−２を行い，それまで蓄積した動作情報を含むメッセージＭＳＧをデータ送信Ｓ１４−２を行い，サーバの応答確認Ｓ１５−２に応答して，回線切断Ｓ１６−２を行う。この時も，サーバ２０は，メッセージＭＳＧ内の通信障害データStatusも受信する。
【００５６】
医療機器に異常が発生した場合は，それを看過すると在宅診療に支障を来すことになるので，リアルタイムで緊急情報をサーバ２０にアップロードし，サーバ側でサービス担当者が緊急措置を講じることができるようにする。
【００５７】
図７は，本実施の形態における子機の医療機器との送受信のフローチャート図である。子機は，酸素濃縮装置などの医療機器にステータス要求を送信する（Ｓ２０）。そして，酸素濃縮装置からタイムアウト時間内にアクノリッジＡＣＫを受信できない場合は（Ｓ２１のＮＯ），再送信要求回数（例えば３回）に達するまで（Ｓ２２のＹＥＳ），ステータス要求の送信を繰り返す（Ｓ２０）。アクノリッジＡＣＫは，前述のステータス応答である。そして，再送信要求回数に達したら（Ｓ２２のＮＯ），子機は，子機と医療機器間の通信媒体（ケーブル）に送信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ２３）。通信障害フラグとは，前述の通信障害データStatusのビットｂ３，ｂ４である。
【００５８】
さらに，子機は，タイムアウト内にアクノリッジＡＣＫを受信したら（Ｓ２１のＹＥＳ），受信データが正常か否かをＣＲＣコードなどを利用してチェックする（Ｓ２４）。データエラーが検出されたら，受信時に通信障害が発生したことが検出され，対応する通信障害フラグｂ３にフラグを立てる（Ｓ２５）。また，データエラーが検出されなければ通信障害フラグは記録されない（Ｓ２６）。
【００５９】
図８は，本実施の形態における子機の親機との送受信のフローチャート図である。子機は，親機からステータス要求を受信し（Ｓ３０），受信データが正常か否かをＣＲＣコードなどによりチェックする（Ｓ３１）。もしデータエラーが検出されたら，子機は，親機からの受信時に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ３２）。つまり，通信障害データのビットｂ５にフラグを立てる。
【００６０】
さらに，子機は，親機にステータス応答を送信する（Ｓ３３）。これに対する親機からのアクノリッジＡＣＫをタイムアウト時間内に受信できなければ（Ｓ３４のＮＯ），再送信要求回数に達するまで（Ｓ３５のＹＥＳ），ステータス応答の送信Ｓ３３を繰り返す。再送信要求回数に達するまで親機からのアクノリッジＡＣＫを受信できなければ，子機は，親機への送信または親機からの受信に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ３６）。例えば，通信障害データのビットｂ５，ｂ６にフラグを立てる。アクノリッジＡＣＫを受信できれば，通信障害フラグは立てない（Ｓ３７）。
【００６１】
図９は，本実施の形態において子機と医療機器との間で通信障害が発生したときの動作シーケンスを示す図である。子機１２は，医療機器１０にステータス要求Ｓ１０−１を送信する。これに応答して，医療機器１０はステータス応答Ｓ１１−１を返信する。ある時点で，子機からのステータス要求Ｓ１０−２に対して医療機器からのステータス応答を受信できない場合は，子機は，医療機器との間の通信媒体に通信障害４１が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ２３）。この通信障害フラグは，図７の工程Ｓ２３でのフラグと同じであり，ビットｂ３，ｂ４である。
【００６２】
その後，親機１４が，たとえば数秒間隔の送受信で，ステータス要求Ｓ１０−３を子機１２に送信し，子機１２は，それに応答して，ステータス応答Ｓ１１−３を親機１４に返信する。このステータス応答にはメッセージＭＳＧが含まれ，親機１４は，メッセージ内の通信障害データStatus内のビットｂ３，ｂ４から子機と医療機器間の通信障害の情報を取得する。
【００６３】
そして，親機は，アップロードタイミングでサーバ２０に発呼Ｓ１３−２を行い，データ送信Ｓ１４−２を行う。この送信データには，メッセージＭＳＧが含まれ，そのヘッダには通信障害データStatusが含まれ，データ部Dataには通常の運転情報が含まれる。そして，親機は，サーバからの応答Ｓ１５−２に応答して，回線を切断する（Ｓ１６−２）。親機は，サーバへのアップロードに成功すると，それまでの通信障害データをクリアする。同様に，子機，医療機器もそれまでの通信障害データをクリアする。
【００６４】
以上のとおり，子機と親機とは，子機と医療機器との間の通信障害データを共有しあう。これは，子機と親機のいずれかが電源オフにより記憶データを失った場合でも，電源オン後に送受信によりメッセージを供給しあってデータの復帰を行うことができるようにするためである。
【００６５】
また，親機は，通信障害データが存在していても，異常情報のようにリアルタイムでサーバにアップロードすることはしない。通信障害は比較的小さくない頻度で発生しがちであり，偶発的に発生することもあり，通信障害が発生するたびにサーバにアップロードすると，公衆通信網の回線を頻繁に使用することになり，患者宅または医療機関の公衆通信網の回線に負担を強いることになるからである。また，偶発的に通信障害が発生してもリトライにより成功する場合があり，医療機器の異常発生よりも緊急性が低いからである。
【００６６】
図１０は，本実施の形態における親機の子機との送受信のフローチャート図である。図１０は，図７と類似している。つまり，親機は，数秒間隔で行う送受信により，子機にステータス要求を送信する（Ｓ４０）。そして，親機は，子機からタイムアウト時間内にアクノリッジＡＣＫを受信できない場合は（Ｓ４１のＮＯ），再送信要求回数（例えば３回）に達するまで（Ｓ４２のＹＥＳ），ステータス要求の送信Ｓ４０を繰り返す。再送要求回数までにアクノリッジＡＣＫを受信できない場合は（Ｓ４２のＮＯ），親機は，通信媒体１３に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ４３）。このフラグは，前述のビットｂ７，ｂ８に対応する。
【００６７】
また，親機は，アクノリッジＡＣＫに対応するステータス応答の受信データが正常か否かをＣＲＣコードなどによりチェックする（Ｓ４４）。データエラーが検出されると（Ｓ４４のＮＯ），親機は，子機からの受信時に通信障害が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ４５）。このフラグは，ビットｂ７に対応する。また，データエラーが検出されなければ，通信障害フラグは立てない（Ｓ４６）。
【００６８】
図１１は，本実施の形態における親機のサーバへのアップロードのフローチャート図である。親機は，あらかじめ決められたアップロードタイミングでサーバに発呼を行う（Ｓ５０）。そして，サーバにメッセージＭＳＧを含むデータを送信する（Ｓ５１）。このデータ送信に対してサーバからタイムアウト時間内にアクノリッジ信号ＡＣＫを受信できないときは（Ｓ５２のＮＯ），再送要求回数に達するまで（Ｓ５３のＹＥＳ），データ送信Ｓ５１を繰り返す。採用要求回数に達してもアクノリッジ信号ＡＣＫを受信できないときは（Ｓ５３のＮＯ），親機は公衆通信網の通信障害を検出し，対応する通信障害フラグを立てる（Ｓ５４）。このフラグは，ビットｂ９，ｂ１０に対応する。
【００６９】
また，親機は，サーバからのアクノリッジ信号ＡＣＫの受信データが正常か否かをＣＲＣコードなどにより行い（Ｓ５５），エラーが検出されると対応する通信障害フラグを立てる（Ｓ５６）。例えばこのフラグは，ビットｂ９に対応する。エラーが検出されなければフラグは立てない（Ｓ５７）。
【００７０】
図１２は，本実施の形態において親機と子機との間で通信障害が発生したときの動作シーケンスを示す図である。親機は，送受信により，子機に対してステータス要求Ｓ１０−３を送信する。しかし，タイムアウト時間内に子機からのステータス応答を規定回数トライしても受信できない場合は，親機は子機との通信媒体１３に通信障害４２が発生したことを検出し，対応する通信障害フラグを立てる（Ｓ４３）。この場合は，子機への送信または子機からの受信で通信障害が発生した可能性があり，ビットｂ７，ｂ８に記録される。
【００７１】
親機１４は，アップロードタイミングになると，サーバ２０に発呼Ｓ１３−２を行い，データ送信Ｓ１４−２を行う。この送信データにはメッセージＭＳＧが含まれ，そのヘッダＨＤには通信障害データStatusが含まれ，データ部Dataには通常の運転情報が含まれる。そして，親機は，サーバからの応答Ｓ１５−２に応答して回線を切断する（Ｓ１６−２）。親機は，サーバへのアップロードに成功すると，それまでの通信障害データをクリアする。同様に，子機，医療機器もそれまでの通信障害データをクリアする。
【００７２】
親機１４と子機１２とは，互いの通信障害データを共有しあい，いずれかが電源オフになってそのデータが消失しても，その後の電源オンの後にデータの復帰ができるようにしている。そして，親機１４は，通信障害データを通常の運転データとともに，２４時間に１回のアップロードタイミングでサーバ２０にアップロードする。
【００７３】
サーバ２０は，アップロードされたメッセージＭＳＧ内の通信障害データStatusを解析することで，患者宅内の通信媒体１１，１３及び公衆通信網１５０のどれかに通信障害が発生していること，さらに，好ましくはアップロードタイミング間の発生回数を検出することができる。それにより，サーバ側のサービス担当者は患者宅に電話連絡をして通信障害への対応策を適切に指示することができる。
【００７４】
例えば，発生回数が多い通信媒体１１，１３，１５０の疑われる障害に基づいて医療機器１０，ケーブル１１，子機１２，親機１４，それらの間の無線環境，親機１４から公衆通信網１５０への接続配線１５などについて，必要な措置を指示する。
【００７５】
上記の実施の形態では，医療機器として医療用酸素濃縮装置を例にして説明したが，それ以外にも，在宅療法に使用される医療機器としては，超音波治療器，成人用人工呼吸器などがある。また，医療機器は，患者宅内に設置される場合以外に，医療機関内に設置される場合もあるが，そのような場合でも，本実施の形態を適用することができる。
【００７６】
また，上記の公衆通信網は，酸素濃縮機と通信端末機とが設置される患者宅や医療機関に設置される電話機その他の通信機器（ファクシミリ、インターネットに接続されるパーソナルコンピュータなど）と共有される公衆通信網（たとえば有線通信手段あるいは無線通信手段を用いて実現されるインターネット、携帯電話通信網、またはＰＨＳ通信網などを含む公衆通信網）であれば，本実施の形態に適用できる。
【図面の簡単な説明】
【００７７】
【図１】本実施の形態における医療支援システムの一例を示す図である。
【図２】送受信で交換されるメッセージ情報ＭＳＧのフォーマット例を示す図である。
【図３】メッセージＭＳＧ内のヘッダ部ＨＤの通信障害データStatusのビット構成を示す図である。
【図４】本実施の形態における通信障害の発生とその記録について説明する図である。
【図５】本実施の形態においてサーバが通信障害発生箇所別に通信障害を検出することを説明する図である。
【図６】本実施の形態において医療機器に異常が発生したときの動作シーケンスを示す図である。
【図７】本実施の形態における子機の医療機器との送受信のフローチャート図である。
【図８】本実施の形態における子機の親機との送受信のフローチャート図である。
【図９】本実施の形態において子機と医療機器との間で通信障害が発生したときの動作シーケンスを示す図である。
【図１０】本実施の形態における親機の子機との送受信のフローチャート図である。
【図１１】本実施の形態における親機のサーバへのアップロードのフローチャート図である。
【図１２】本実施の形態において親機と子機との間で通信障害が発生したときの動作シーケンスを示す図である。
【符号の説明】
【００７８】
１００．１１０：患者宅または医療機関
１０：医療機器，酸素濃縮装置
１２：通信端末子機
１４：通信端末親機
１５０：公衆通信網
２０：サーバ
ＤＢ：データベース
【特許請求の範囲】
【請求項１】
患者宅内または医療機関内に設置され運転情報を作成する医療機器と，
前記医療機器に接続され前記運転情報を取得する通信端末子機と，
前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，
前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，
前記通信端末子機と通信端末親機は，前記第１の通信媒体に通信障害が発生したときに第１の通信障害情報を記録し，
前記通信端末親機は，前記第１の通信障害情報を所定期間間隔のアップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項２】
患者宅内または医療機関内に設置され運転情報を作成する医療機器と，
前記医療機器に接続され前記運転情報を取得する通信端末子機と，
前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，
前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，
前記通信端末子機と通信端末親機は，前記第１の通信媒体に通信障害が発生したときに第１の通信障害情報を記録し，
前記通信端末親機は，前記医療機器に異常が発生したときに前記医療機器が作成する緊急情報をリアルタイムで前記サーバにアップロードし，前記第１の通信障害情報を所定期間間隔のアップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項３】
請求項１または２において，
前記通信端末親機は，前記第２の通信媒体に通信障害が発生したときに第２の通信障害情報を記録し，前記第１の通信障害情報に加えて前記第２の通信障害情報も前記アップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項４】
請求項１，２または３において，
前記医療機器と通信端末子機は，当該医療機器と通信端末子機間で通信障害が発生したときに第３の通信障害情報を記録し，
前記通信端末親機は，前記第１の通信障害情報に加えて前記第３の通信障害情報も前記アップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項５】
請求項４において，
前記第１の通信障害情報と，前記第２または第３の通信障害情報とは，通信障害の発生回数を含むことを特徴とする医療支援システム。
【請求項６】
請求項１または２において，
前記通信端末親機と通信端末子機は，所定時間間隔で送受信を行い，
当該送受信では，前記通信端末親機が前記通信端末子機にステータス要求を送信し，前記通信端末子機が前記ステータス要求に応答してステータス応答を前記通信端末親機に返信し，
前記ステータス要求とステータス応答には前記通信端末親機と通信端末子機が記録した第１の通信障害情報が含まれ，前記通信端末親機と通信端末子機とが前記第１の通信障害情報を共有することを特徴とする医療支援システム。
【請求項７】
請求項４において，
前記通信端末親機と通信端末子機は，所定時間間隔で送受信を行い，
当該送受信では，前記通信端末親機が前記通信端末子機に第１のステータス要求を送信し，前記通信端末子機が前記第１のステータス要求に応答して第１のステータス応答を前記通信端末親機に返信し，前記第１のステータス要求と第１のステータス応答には前記通信端末親機と通信端末子機が記録した第１の通信障害情報が含まれ，前記通信端末親機と通信端末子機とが前記第１の通信障害情報を共有し，
前記通信端末子機と医療機器も，所定時間間隔で送受信を行い，
当該送受信では，前記通信端末子機が前記医療機器に第２のステータス要求を送信し，前記医療機器が前記第２のステータス要求に応答して第２のステータス応答を前記通信端末子機に返信し，前記第２のステータス要求と第２のステータス応答には前記通信端末子機と医療機器が記録した第３の通信障害情報が含まれ，前記通信端末子機と医療機器とが前記第３の通信障害情報を共有することを特徴とする医療支援システム。
【請求項８】
患者宅内または医療機関内に設置され運転情報を作成する医療機器と，
前記医療機器に接続され前記運転情報を取得する通信端末子機と，
前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，
前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，
前記通信端末子機と通信端末親機は，前記第１の通信媒体に，第２の通信媒体に，及び前記通信端末子機と医療機器間に通信障害を検出したときそれぞれ第１，第２，及び第３の通信障害情報を記録し，
前記通信端末親機は，前記第１，第２，及び第３の通信障害情報を前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項１】
患者宅内または医療機関内に設置され運転情報を作成する医療機器と，
前記医療機器に接続され前記運転情報を取得する通信端末子機と，
前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，
前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，
前記通信端末子機と通信端末親機は，前記第１の通信媒体に通信障害が発生したときに第１の通信障害情報を記録し，
前記通信端末親機は，前記第１の通信障害情報を所定期間間隔のアップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項２】
患者宅内または医療機関内に設置され運転情報を作成する医療機器と，
前記医療機器に接続され前記運転情報を取得する通信端末子機と，
前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，
前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，
前記通信端末子機と通信端末親機は，前記第１の通信媒体に通信障害が発生したときに第１の通信障害情報を記録し，
前記通信端末親機は，前記医療機器に異常が発生したときに前記医療機器が作成する緊急情報をリアルタイムで前記サーバにアップロードし，前記第１の通信障害情報を所定期間間隔のアップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項３】
請求項１または２において，
前記通信端末親機は，前記第２の通信媒体に通信障害が発生したときに第２の通信障害情報を記録し，前記第１の通信障害情報に加えて前記第２の通信障害情報も前記アップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項４】
請求項１，２または３において，
前記医療機器と通信端末子機は，当該医療機器と通信端末子機間で通信障害が発生したときに第３の通信障害情報を記録し，
前記通信端末親機は，前記第１の通信障害情報に加えて前記第３の通信障害情報も前記アップロードタイミングで前記サーバにアップロードすることを特徴とする医療支援システム。
【請求項５】
請求項４において，
前記第１の通信障害情報と，前記第２または第３の通信障害情報とは，通信障害の発生回数を含むことを特徴とする医療支援システム。
【請求項６】
請求項１または２において，
前記通信端末親機と通信端末子機は，所定時間間隔で送受信を行い，
当該送受信では，前記通信端末親機が前記通信端末子機にステータス要求を送信し，前記通信端末子機が前記ステータス要求に応答してステータス応答を前記通信端末親機に返信し，
前記ステータス要求とステータス応答には前記通信端末親機と通信端末子機が記録した第１の通信障害情報が含まれ，前記通信端末親機と通信端末子機とが前記第１の通信障害情報を共有することを特徴とする医療支援システム。
【請求項７】
請求項４において，
前記通信端末親機と通信端末子機は，所定時間間隔で送受信を行い，
当該送受信では，前記通信端末親機が前記通信端末子機に第１のステータス要求を送信し，前記通信端末子機が前記第１のステータス要求に応答して第１のステータス応答を前記通信端末親機に返信し，前記第１のステータス要求と第１のステータス応答には前記通信端末親機と通信端末子機が記録した第１の通信障害情報が含まれ，前記通信端末親機と通信端末子機とが前記第１の通信障害情報を共有し，
前記通信端末子機と医療機器も，所定時間間隔で送受信を行い，
当該送受信では，前記通信端末子機が前記医療機器に第２のステータス要求を送信し，前記医療機器が前記第２のステータス要求に応答して第２のステータス応答を前記通信端末子機に返信し，前記第２のステータス要求と第２のステータス応答には前記通信端末子機と医療機器が記録した第３の通信障害情報が含まれ，前記通信端末子機と医療機器とが前記第３の通信障害情報を共有することを特徴とする医療支援システム。
【請求項８】
患者宅内または医療機関内に設置され運転情報を作成する医療機器と，
前記医療機器に接続され前記運転情報を取得する通信端末子機と，
前記通信端末子機と第１の通信媒体を介して情報を送受信する通信端末親機と，
前記医療機器から遠隔の地に設置され，前記医療機器とその運転情報が格納されたデータベースを有し，前記通信端末親機から第２の通信媒体を介して前記運転情報を含む情報をアップロードされるサーバとを有し，
前記通信端末子機と通信端末親機は，前記第１の通信媒体に，第２の通信媒体に，及び前記通信端末子機と医療機器間に通信障害を検出したときそれぞれ第１，第２，及び第３の通信障害情報を記録し，
前記通信端末親機は，前記第１，第２，及び第３の通信障害情報を前記サーバにアップロードすることを特徴とする医療支援システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１０−８１９９３（Ｐ２０１０−８１９９３Ａ）
【公開日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願番号】特願２００８−２５１４６５（Ｐ２００８−２５１４６５）
【出願日】平成２０年９月２９日（２００８．９．２９）
【出願人】（５０３３６９４９５）帝人ファーマ株式会社 (159)
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
【公開日】平成２２年４月１５日（２０１０．４．１５）
【国際特許分類】
【出願日】平成２０年９月２９日（２００８．９．２９）
【出願人】（５０３３６９４９５）帝人ファーマ株式会社 (159)
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
[ Back to top ]