リモート制御による医療装置
患者（６１８）に医療処置を配信する医療処置管理システム（６１０）である。システム（６１０）は、第１の位置に配置される医療デバイス（６１２）と、医療デバイス（６１２）に接続される電子機器プロセッサ（６２８）と、プロセッサ（６２８）に接続されるセンサ（６１６）と、第１の位置から離れた第２の位置に配置されるリモートコントローラ（６４６）とを備える。リモートコントローラ（６４６）は、電子機器プロセッサ（６２８）の動作を制御する入力デバイスを有する。センサ（６１６）は、プロセッサ（６２８）に送信する１つ以上の信号を受信する。信号は、患者の生理学的条件および／または患者の環境から導出され得る。プロセッサ（６２８）は、信号を受信して、信号の計算（６３０」）を実行する。計算の結果に基づいて、プロセッサ（６２８）は、所定の期間に患者（６１８）への医療処置の配当を調整する。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連参照）
本願は、１９９９年３月１９日に出願された米国特許第０９／２７２，５０２号の一部継続出願であり、米国特許第０９／２７２，５０２号は、米国特許第５，８８５，２４５号の継続出願であり、米国特許第５，８８５，２４５号は、（現在破棄された）１９９６年８月２日に出願された米国特許第０８／６９１，６８７号の一部継続出願であり、これらの出願は、本明細書中で参照として援用され、本明細書の一部をなす。
【０００２】
（技術分野）
本発明は、リモート位置から輸液ポンプ等の医療デバイスをモニタおよび／または制御する装置に関する。
【背景技術】
【０００３】
（発明の背景）
輸液ポンプは、患者に液体薬を自動的に管理するために利用される。液体薬は、薬のソースから供給され、カテーテルまたは他の注入デバイスを介して患者にポンピングされる。液体が注入される方法は、輸液ポンプによって制御される。輸液ポンプは、液体薬が連続的に一定の速度で注入される連続モード、または、注入速度が徐々に増加し、一定になり、その後徐々に減少する傾斜（ｒａｍｐ）モードのような、様々な輸液のモードを有し得る。
【０００４】
通常、輸液ポンプのモニタは、輸液ポンプに組み込まれた視覚表示手段をよく見ることによって行われ、輸液ポンプの制御は、キーパッドのような輸液ポンプと統合された入力デバイスを起動することによって行われる。結果的に、輸液ポンプのモニタおよび／または制御は、輸液ポンプが配置されている同じ位置で行われる。
【０００５】
さらに、多くのタイプの医療処置では、処置の影響および最終的な有用性は、治療に対する患者の耐容性および感受性に依存する。このような測定は、正確かつ効果的に患者を治療する際に、医者を支援する。しかしながら、現在のところ、特定の被験者の実際の計測または被験者の環境ではなく客観的な計測に基づいて、多くの医療処置が患者に提供されている。
【０００６】
例えば、多くの薬物療法の典型的な医療処置パラメータは、一般的な２４時間周期のシステムに基づいて提供される。２４時間周期のシステムの下では、植物および動物の典型的な生理学的機能は、およそ２４時間間隔で再発することが、医療産業界では知られている。人間の場合、身体の時計は、視交差上核（ＳＣＮ）に配置され、別個の細胞群は、視床下部内に検出される。ＳＣＮは、人間の身体の２４時間周期のリズムを制御または調整する。通常、人間の２４時間周期のリズムは、松果体によるメラトニン分泌を介して、眼を通る光と暗闇との交代によってキャリブレーションされる。
【０００７】
さらに、通常の人間の組織の細胞の代謝および増殖は、同様のリズムを表し、これにより、振幅ならびにピークおよびトラフの時間が予測可能となる。このようなリズムは、薬理学的特性、耐容性、および最終的な有用性に影響する。例えば、２４時間周期のリズムは、癌治療における、耐容性および抗腫瘍性の効能を含む、抗癌性医薬品の利用および効果に影響する。したがって、時間薬理学の処置（ｉｎｔｅｒｖｅｎｔｉｏｎ）では、抗癌剤薬物は、特に化学療法とともに、標準的な２４時間周期のリズムにしたがって配信される。例えば、Ｆｌｏｘｕｒｉｄｉｎｅ配信は、通常４回に分けて服用され、各服用量は、一日の時間に依存する。
【０００８】
午前９時〜午後３時の間に服用量の１４％
午後３時〜午後９時の間に服用量の６８％
午後９時〜午前３時の間に服用量の１４％
午前３時〜午前９時の間に服用量の４％
通常、薬剤が配信される時間は、医者によって選択され、患者の代謝の変化と客観的に一致する。しかし、２４時間周期のリズムは、単に、患者の代謝の変化の推定値であり、実際の患者の代謝には基づいていない。したがって、薬剤配信が実際に患者の実際の代謝と一致するかどうかは、評価も判定もされない。
【０００９】
さらに、異なる医療処置は、異なる最適服用時間プロファイルを有する。例えば、異なる抗腫瘍性の薬物は、通常、異なる時間に服用される。ＥｐｉｒｕｂｉｃｉｎおよびＤａｕｎｏｒｕｂｉｃｉｎは、通常、ライトオンセットの後の２時間で服用される。Ｃｙｃｏｐｈａｓｐｈａｍｉｄｅは、通常、ライトオンセットの後の１２時間で服用される。Ｃｉｓｐｌａｔｉｎは、通常、ライトオンセットの後の１５時間で服用される。Ｖｉｎｂｌａｓｔｉｎｅは、通常、ライトオンセットの後の１８時間で服用される。理解され得るように、異なる薬物は、異なる作用のメカニズムを有する。
【００１０】
しかし、他のファクタがまた、適切な医療処置に影響を与える。例えば、通常の組織の最小の感受性は、薬物の代謝（例えば、グルタチオン）に影響を与える酵素レベルに関連すると考えられる。これらの可変量の全体のドライバは、患者の休息活動周期であると考えられる。この効果のために、研究室のラット研究が、１２時間の光および１２時間の暗闇のサイクルの支配下にある動物により導かれるべきであることが知られている。
【００１１】
それにもかかわらず、異なる患者は（癌治療については、および異なる腫瘍でさえ）、全く同一の２４時間周期ではないことが知られている。したがって、２４時間周期の治療の間で最適化するべき少なくとも２つの局面が存在する。（１）腫瘍（単数または複数）のピーク感受性、（２）通常の組織の最小の感受性である。
【００１２】
標準的な時間薬理学の処置は、時間および服用を制御することによって、薬物耐容性の２４時間周期のリズムの利点を利用する。したがって、このことは、毒性の効果を低減し、患者の生活の質を改良することができる。さらに、化学療法の薬物を含む多くの薬物では、少なくとも毒性の２４時間周期の時間でより大きい最大耐用性を示した服用を管理することによって、生存の改良が導かれ得る。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、上述のように、標準的な２４時間周期のシステムに従う医療処置を提供することには、多くの欠点が存在する。
【課題を解決するための手段】
【００１４】
本発明のある局面によると、医療装置は、患者への医療処置を管理するプログラム可能医療デバイスであって、第１の位置に配置される、プログラム可能医療デバイスと、プログラム可能医療デバイスを制御するリモートコントローラであって、プログラム可能医療デバイスが配置される第１の位置から離れた第２の位置に配置される、リモートコントローラとを有する。プログラム可能医療デバイスは、患者への医療処置を管理する手段と、該管理手段を制御する制御コマンドをユーザが入力することを可能にする入力デバイスとを備える。リモートコントローラは、ディスプレイデバイスと、該プログラム医療デバイスの入力デバイスに実質的に対応する仮想入力デバイスの可視表示を生成するディスプレイデバイスに動作可能なように接続される手段と、第２の位置にいるユーザが可視入力デバイスを起動して、ユーザが第２の位置からプログラム可能医療デバイスの動作を制御することを可能にする手段とを備える。
【００１５】
入力デバイスは、例えば、キーパッドであってもよく、仮想入力デバイスは、キーパッドと実質的に同じ構成を有する複数のキーの視覚表示であってもよい。
【００１６】
プログラム可能医療デバイスは、患者への液体薬を管理する輸液ポンプであってもよく、これは、患者に接続されることに適合する液体注入デバイスと、液体注入デバイスに接続されるコンジットと、液体注入デバイスによりコンジットを介して患者に液体薬をポンピングするポンピングメカニズムとを備える。
【００１７】
本発明の別の局面によると、医療処置デバイスは、制御アルゴリズムおよびセンシングデバイスを利用して、薬剤の供給および患者に薬剤を配信する手段を有する。制御アルゴリズムは、医療デバイスに接続される。センシングデバイスは、制御アルゴリズムに接続され、センシングデバイスは、制御アルゴリズムに信号を送信する。制御アルゴリズムは、センシングデバイスから取り出される信号を処理し、薬剤が医療処置デバイスから患者へ配信されるべきかどうかを判定するために、信号の処理の結果に基づいてフィードバック制御を展開する。フィードバック制御は、医療処置デバイスに提供されて、患者への医療処置あの配信を制御する。デバイスのリモートコントローラは、第１の位置から離れた第２の位置に配置される。リモートコントローラは、制御アルゴリズムの動作を制御する入力デバイスを有する。
【００１８】
本発明のさらに別の実施形態によると、本発明の医療配信システムは、プログラム可能医療デバイスと、ローカルコントローラと、リモートコントローラとを備える。プログラム可能医療デバイスは、患者への医療処置を管理する第１の位置に配置され、プログラム可能医療デバイスは、患者への医療処置を管理する手段を有する。さらに、プログラム可能医療デバイスは、プログラム可能医療デバイスの制御コマンドを入力する第１の入力デバイスを有する。ローカルコントローラは、プログラム可能医療デバイスに動作可能に接続される。ローカルコントローラは、第１の位置に配置され、ローカルコントローラの制御コマンドを入力する第２の入力デバイスを有する。さらに、ローカルコントローラは、患者からの信号を受信するように、患者に動作可能に接続され、ローカルコントローラは、プログラム可能医療デバイスの動作を操作する。リモートコントローラは、プログラム可能医療デバイスが配置される第１の位置から離れた第２の位置に配置され、第２の位置のユーザがローカルコントローラを制御することを可能にする手段を有する。
【００１９】
本発明のこれらおよび他の特徴および利点は、好ましい実施形態の詳細な説明から当業者に理解可能であり、好ましい実施形態は、簡単な説明が以下に示される図面を参照して説明される。
【発明を実施するための最良の形態】
【００２０】
（好ましい実施形態の詳細な説明）
図１は、患者への医療処置を管理する装置１０の１つの実施形態を示す。図１を参照すると、装置１０は、輸液ポンプ１２の形式のプログラム可能医療処置手段を含み、輸液ポンプ１２は、１６で概略的に示される液体コンジットを介して、カテーテル１４の形式の液体薬注入デバイスに接続される。
【００２１】
装置１０は、輸液ポンプ１２が配置される部屋の位置から離れた部屋の位置に配置されるリモートモニタ／コントローラ２０を備える。リモートモニタ／コントローラ２０は、ポンプ１２が配置される同じ建物の異なる部屋に配置されてもよいし、あるいは、ポンプ１２が配置される建物と異なる建物に配置されてもよい。リモートモニタ／コントローラ２０は、データリンク２４を介して従来の音声／データモデム２２に接続され、さらに、モデム２２は、音声リンク２８を介して電話２６に接続される。輸液ポンプ１２は、データリンク３２を介して従来の音声／データモデム３０に接続され、モデム３０は、音声リンク３６を介して電話３４に接続される。２つのモデム２２、３０は、例えば電話線となり得る、通信リンク３８を介して、双方向音声およびデータ通信に相互接続される。
【００２２】
図２は、図１に概略的に示されるリモートモニタ／コントローラ２０の電子機器のブロック図である。図２を参照すると、リモートモニタ／コントローラ２０は、マイクロプロセッサ（ＭＰ）６０、リードオンリーメモリ（ＲＯＭ）６２、ランダムアクセスメモリ（ＲＡＭ）６４、および入力／出力（Ｉ／Ｏ）回路６６を備え、これらの全てが、アドレス／データバス６８によって相互接続される。マイクロプロセッサ６０は、データバイトを送信する送信バッファ（ＸＭＩＴ）７０、および、データバイトを受信する受信バッファ（ＲＥＣ）７２を有する。リモートモニタ／コントローラ２０データリンク７６を介してＩ／Ｏ回路６６に接続されるキーボード７４、ライン８０を介してＩ／Ｏ回路６６に接続されるＣＲＴ等のディスプレイデバイス７８、および、ライン８４を介してＩ／Ｏ回路６６に接続される電子マウス８２等の入力デバイスを有する。リモートモニタ／コントローラ２０はまた、ハードディスクドライブまたはフロッピー（登録商標）ディスクドライブ等の１つ以上のディスクドライブを備え得る。
【００２３】
図３は、図１に概略的に示される輸液ポンプ１２の１つの実施形態の前面図である。図３を参照すると、ポンプ１２は、ユーザがデータおよびコマンドを入力し得るキーパッド９０の形式の入力デバイス、ならびに、ユーザにテキストメッセージを表示するディスプレイ９２を有する。
【００２４】
輸液ポンプ１２の電子機器のブロック図が、図４に示される。図４を参照すると、ポンプ１２は、コントローラ１００、組み込みＩ／Ｏインターフェース１０２ａを有する電気的にプログラム可能リードオンリーメモリ（ＥＰＲＯＭ）１０２、不揮発性ＲＡＭ１０４、リアルタイムクロック１０６、ならびにディスプレイ９２を備え、これら全てが、通信バス１０８によって相互接続される。ディスプレイ９２は、バックライト１１を備え、このバックライトは、コントローラ１００およびバックライト１１０を相互接続するライン１１２で発生したイネーブル信号によって選択的に起動される。ＲＡＭ１０４およびリアルタイムクロック１０６の両方が、バッテリー１１４に接続される。このバッテリー１１４は、システム電力が欠乏しているときのみに、ＲＡＭ１０４およびリアルタイムクロック１０６に電力を供給する。コントローラ１００は、通信バス１０８に接続される送信バッファ１１６および受信バッファ１１８を有する。
【００２５】
コントローラ１００は、ライン１２２を介して制御信号を増幅回路１２０に周期的に送信することによって薬輸液速度を制御して、液体コンジット１６（図１）の一部分と接触するように適合されるロータリポンプホイール（図示されない）のような、ポンピングメカニズム１２６を駆動するポンプモニタ１２４を駆動する。
【００２６】
コントローラ１００は、シャフトエンコーダ（ＳＥ）センサ１３０からの周期的入力を受信し、このセンサ１３０は、モータ１２４のシャフトに配置される。ＳＥセンサ１３０は、２つの信号出力をコントローラ１００に提供する二相モーションセンシングエンコーダであり得る。モータ１２４の回転スピードおよびその回転の方向は、２つの信号出力の間の速度および位相の関係に基づいて、コントローラ１０によって決定される。
【００２７】
ＳＥエンコーダ１３０は、周期的に信号をコントローラ１００へライン１３２を介して送信する。信号が送信されるたびに、インタラプトが発生し、コントローラ１００は、モーションシャフトの実際の位置とその所望の位置とを比較し、パルス幅の変調された信号等の新しい制御信号を増幅器１２０にライン１２２を介して送信して、モータ１２４の実際のスピードが、所望の薬輸液速度に必要となるモータスピードに対応することを保証する。ＳＥセンサ１３０によって生じるインタラプトは、最高の優先度を割り当てられることにより、そのインタラプトは、直ちにコントローラ１００によって他のアクションが取られる前に応答を受ける。
【００２８】
ポンプ１２は、本明細書中に記載されない他の多くの他の特徴を有し、これらは、以下の特許出願に記載される。それぞれの出願は、本明細書中で参照として援用される。「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｈａｖｉｎｇ Ｐｏｗｅｒ Ｓａｖｉｎｇ Ｍｏｄｅｓ」と称する１９９５年３月６日に出願された米国特許第０８／３９９，１８４号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｗｉｔｈ Ｓｅｌｅｃｔｉｖｅ Ｂａｃｋｌｉｇｈｔ」と称する１９９５年３月６日に出願された米国特許第０８／３９８，９７７７号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｈａｖｉｎｇ Ｗｉｔｈ Ｄｉｆｆｅｒｅｎｔ Ｏｐｅｒａｔｉｎｇ Ｍｏｄｅｓ」と称する１９９５年３月６日に出願された米国特許第０８／３９８，９８０号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｈａｖｉｎｇ Ｗｉｔｈ Ｄｕａｌ−Ｌａｔｃｈｉｎｇ Ｍｅｃｈａｎｉｓｍ」と称する１９９５年３月６日に出願された米国特許第０８／３９９，１８３号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｗｉｔｈ Ｈｉｓｔｏｒｉｃａｌ Ｄａｔａ Ｒｅｃｏｒｄｉｎｇ」と称する１９９５年３月６日に出願された米国特許第０８／３９８，８８７号である。
【００２９】
輸液ポンプ１２の動作は、ＥＰＲＯＭ１０４に格納されるコンピュータプログラムによって制御され、コントローラ１００によって実行される。動作全体のフローチャート２００は、図５に示される。図５を参照すると、ポンプ１２がオンにされると、ステップ２０２において、ポンプが開始され、ポンプ動作のテストが実行される。ポンプ１２は、輸液の間一時的にオフにされてもよく、この場合、以下に示されるように、ポンプ１２は、オンに戻された場合に輸液を継続し得る。ステップ２０４において、ポンプによって注入される液体の容積がいくらか残っているか、輸液のためのさらなる時間がいくらか残っている場合（ポンプが輸液の間に一時的にオフにされる場合）、プログラムは分岐してステップ２０６に進み、ステップ２０６では、ユーザは、ディスプレイ９２に表示されるメッセージを介して、以前の輸液が再開されるべきかどうかを尋ねられる。ユーザが（キーパッド９０を介して）「はい」と答える場合、プログラムは分岐して、「ｒｅａｄｙ−ｔｏ−ｒｕｎ（実行準備完了）」ステップ２１０に進む。前回の輸液が再開されない場合、プログラムは分岐して、ステップ２１２に進む。
【００３０】
輸液ポンプ１２は、ロックアウトモードを有する。ロックアウトモードでは、ユーザは、注入される容積または輸液の速度等の、輸液パラメータをプログラムすることを妨げられ得る。例えば、ポンプ１２は、注入される特定のフロープロファイル、フロー速度、および容積を有する輸液を配信するように、医療助手によってプログラムされ得る。その輸液をプログラミングした後、医療助手は、ポンプをロックアウトモードにし得る。ロックアウトモードでは、患者は、輸液パラメータのいかなる変更をも防がれる。ステップ２１２では、ポンプ１２が既にロックアウトモードに置かれていた場合、プログラムは分岐して、直接「ｒｅａｄｙ−ｔｏ−ｒｕｎ」ステップ２１０へ進み、全てのプログラムステップを迂回する。
【００３１】
ステップ２１２では、ポンプがロックアウトモードにない場合、プログラムは分岐して、ステップ２１４に進む。ステップ２１４では、プログラムは、ユーザに、ディスプレイ９２を介して、続く輸液の間に患者がポンプをプログラムすることが許可されるべきであるかどうかを入力するように促す。ポンプがプログラム可能でない場合、プログラムは分岐して、ステップ２１６に進む。ステップ２１６では、ロックアウトシーケンスは、どの輸液モードがロックアウトされるべきであるかを入力することをユーザに要求することによって、実行される。ポンプが患者によってプログラム可能である場合、プログラムは、ステップ２１６を迂回する。
【００３２】
輸液ポンプ１２は、５つの輸液の基本モードを有する。１）ポンプが単一の速度で単一の容積を配信する連続モード、２）閾値の速度まで徐々に増加し、閾値速度で一定にとどまり、その後徐々に減少する速度で、ポンプが液体を配信する、自動傾斜モード、３）３時間おきに１つの液体容積等、比較的長い期間の間隔があけられた別個の液体容積をポンプが配信する、断続モード、４）ポンプが、２５の異なる期間のそれぞれの間に固有の輸液速度を配信するようにプログラム可能である、カスタムモード、５）ポンプが、患者の周期的な要求に応答して、鎮痛のボーラスを周期的に注入する、痛みが制御された鎮痛（ＰＣＡ）モードである。
【００３３】
ステップ２１８では、ポンプ１２は、ユーザにプロンプト「継続するか？」をディスプレイ９２に生成する。ユーザがポンプを連続モードで利用することを望む場合、ユーザは、キーパッド９０を介して「はい」と答え、プログラムは分岐して、ステップ２２０に進む。ステップ２２０では、所望の輸液速度、注入される容積等の多くの輸液パラメータを入力することによって、連続モードがユーザによってプログラムされる。ステップ２１８では、ユーザが連続モードを利用したくない場合、ユーザは「いいえ」と答え、プログラムは分岐してステップ２２２に進む。ステップ２２２〜２３６は、５つの可能な輸液モードのうちのどれが選択されるかに依存して、ユーザが異なる輸液パラメータに対して促されることを除き、ステップ２１８および２２０と概ね同じである。
【００３４】
ステップ２２０、２２４、２２８、２３２、または２３６のうちの１つが完了した後、プログラムは分岐して「ｒｅａｄｙ−ｔｏ−ｒｕｎ」ステップ２１０に進む。ユーザが「Ｒｕｎ（実行）」キーを押すと、ポンプ１２は、実行モード２６０を入力し、ステップ２１８、２２２、２２６、２３０、２３４のいずれかで選択された輸液モードならびにステップ２２０、２２４、２２８、２３２、２３６のいずれかで入力された輸液パラメータに応じて、患者に液体薬を注入する。ポンプ１２は、「ホールド」キーが押されるまで実行モード２６０を続ける。警告条件の発生時に、ステップ２６４にて、警告が報告される。ステップ２６２において、ホールドキーが押されると、ステップ２６６にて、輸液が停止し、ポンプ１２は、ステップ２６８にて実行キーが押されるのを待つか、ステップ２７０にてオン／オフスイッチがオフにされるのを待つ。
【００３５】
上述の動作をまとめると、ポンプがロックアウトモードで利用される場合、医療助手は、ポンプをオンにし、所望の輸液モードをステップ２２０、２２４、２２８、２３２、２３６のいずれかでプログラムし、その後、ポンプをオフにする。プログラムされた輸液パラメータは、メモリ１０４に保持される。医療助手は、ポンプをオンに戻し、ステップ２１４にて「プログラム可能？」プロンプトに応じて「いいえ」キーを押し、ステップ２１６にてロックアウト情報を入力し、その後、ポンプを再度オフにする。患者が連続してポンプをオンにして輸液を行う場合、プログラムは、ステップ２１２から直接「ｒｅａｄｙ−ｔｏ−ｒｕｎ」ステップ２１０に進み、ステップ２１０では、患者が輸液パラメータを変更することを防ぐ。
【００３６】
ロックアウトモードが利用されない場合、医療助手または患者は、ポンプをオンにし、所望の輸液モードをプログラムし、その後、「実行」キーを押して輸液をスタートさせる。このとき、決して、ポンプをオフにしない。
【００３７】
プログラミングおよび動作中に、輸液ポンプ１２は、自動的に不揮発性メモリ１０４に全ての重要な輸液データを記録して、完全な履歴データレコードを生成する。この履歴データレコードは、メモリ１０４から後に取り出され、特定の輸液療法がどの程度効果的であったかを決定する際に役立つ診療目的、ならびに、処方された輸液が実際に配信されたことを確認する治療目的を含む様々な目的で利用され得る。
【００３８】
図６は、図５におおよそが示されたポンプ動作全体の間に実行される、輸液データが記録される様々なステップを示す。データの格納をトリガーする多くのイベントが、表１の左側の列にリスト化され、各イベントの発生時に記録される輸液データが、表１の右側の列にリスト化される。リアルタイムクロック１０６によって判定される、輸液データが記録される時間がまた、輸液データとともに格納される。
【００３９】
【表１】
表１および図６を参照すると、輸液ポンプへの電力がオンにされるとき、電力オンのデータおよび時間が記録される。ステップ３０２で判定される際に、ポンプが、ステップ２２０、２２４、２２８、２３２、２３６（図５）のいずれかに準拠して完全にプログラムされる場合、プログラムされた輸液パラメータは、その格納の時間とともに、ステップ３０４で格納される。格納される特定のパラメータは、どの輸液モードがプログラムされたかに依存する。複数の輸液モードのそれぞれについて格納される輸液パラメータのいくつかの例が、以下に設定される表２に示される。
【００４０】
【表２】
ステップ３０６で判定される際にポンプが実行モード２６０（図５）を入力する場合、どの輸液が実行されるのかに準拠したパラメータとともに、実行モードが開始した時間は、ステップ３０８にて格納される。
【００４１】
ステップ３１０では、ホールドキーが押されると、ホールドキーが押された時間に注入される全容積とともに、ホールドキーが押された時間が、ステップ３１２にて格納される。ポンプはまた、連続速度からｋｅｅｐ−ｖｅｉｎ−ｏｐｅｎ（ＫＶＯ；血管を開いたままにする）速度までスイッチングすることによってか、あるいは、断続モードでは、ＫＶＯ速度からより高い輸液速度まで変化させることによって生じる変化のような任意の輸液速度変化を格納する。この変化の存在は、ステップ３１４にて検出される。新しい速度および新しい速度がスタートした時間が、ステップ３１６にて格納される。
【００４２】
ステップ３１８では、警告が生成されると、警告のタイプ、警告が生じた時間、および、警告の時間に注入される全容積が、ステップ３２０にて記録される。
【００４３】
ステップ３３０では、輸液が再開すると（輸液の間にオフにされた後、ポンプがオンに戻るとき）、輸液が再開された時間は、輸液パラメータとともに、ステップ３３１にて格納される。ステップ３３４において判定される際に、ロックアウトシーケンスのプログラミングが完了すると（すなわち、図５のステップ２１６の後）、ロックアウトのプログラミングが完了した時間が、ロックアウトされた輸液モードとともに格納される。ステップ３３８にて、ボーラス要求の検出時に、ボーラスが要求された時間が、ボーラスが実際に与えられたかどうかのインジケーションならびにボーラスの量とともに、ステップ３４０にて格納される。
【００４４】
図７は、ＲＡＭ１０４の一部分のデータ構造を示す。ＲＡＭ１０４では、輸液データ（図６のステップ中に格納されたデータ）が格納される。図７を参照すると、輸液データは、複数のメモリ位置３７２に格納される。データは、ポインタ３７６を利用してメモリ位置３７２に書き込まれ、ポインタ３７６は、データが次に格納されるべきメモリ位置を特定する。
【００４５】
図８は、メモリ位置３７２にデータを格納するルーティン３８０のフローチャートである。図８を参照すると、ステップ３８２では、ポインタ３７６は、データが格納される次のメモリ位置３７２のアドレスにセットされる。ステップ３８４にて、ポインタ３７６が、データが格納され得る最後のメモリ位置にある場合、ルーティンは分岐して、ステップ３８６に進む。ステップ３８６では、ポインタは、データが格納され得る第１のメモリ位置のアドレスにセットされる。ステップ３８４、３８６の結果として、メモリ位置３７２の中身は、周期的に新しいデータで上書きされる。しかしながら、メモリ位置３７２の数は、例えば、数ヶ月間のデータが上書きされる前に格納されるだけ十分に大きい。ステップ３８８および３９０では、データは、ポインタ３７６によって特定されるメモリ位置３７２に格納される（データは、リアルタイムクロック１０６から生成されたタイムスタンプ、ならびに、特定の輸液イベントを特定するイベントデータを含む）。
【００４６】
図９、１０、および１２は、リモートモニタ／コントローラ２０によって実行される様々なルーティンのフローチャートである。以下により詳細に説明されるように、リモートモニタ／コントローラ２０は、輸液ポンプ１２の動作をモニタするために利用され得、輸液ポンプ１２の動作を制御し、および／または、輸液ポンプ１２から輸液データおよび患者データを送信して、その結果、このようなデータは、患者から離れた位置にいるヘルスケアの専門家によって調べられ得る。
【００４７】
リモートモニタ／コントローラ２０は、異なるタイプの輸液ポンプとインターフェースをとるように設計される。どのタイプの輸液ポンプにリモートモニタ／コントローラ２０が動作可能なように接続されるのかを決定するために、ポンプ識別ルーティン１００は、リモートモニタ／コントローラ２０と輸液ポンプ１２との間の通信リンクが確立された後に実行される。図９を参照すると、捨てプＰ４０２にて、リモートモニタ／コントローラ２０は、ポンプ識別（ＩＤ）要求を通信リンク３８を介して輸液ポンプ１２に送信する。ポンプＩＤ要求に応答して、ポンプ１２は、マルチキャラクターＩＤコードをリモートモニタ／コントローラ２０に送信して戻す。ＩＤコードは、例えば、ポンプモデルを識別する１つ以上のキャラクタおよび／またはポンプのソフトウェア１つ以上のキャラクタを含み得る。ステップ４０４では、リモートモニタ／コントローラ２０は、全てのキャラクタが、例えば、改行キャラクタ＜ＬＦ＞に続くキャリッジリターンキャラクタ＜ＣＬ＞のような、１つ以上のターミネーションキャラクタを識別することによって受信されたことを決定し得る。
【００４８】
ステップ４０８は、正しいレスポンスがポンプ１２から受信されたかどうかを判定し、これは、可能性のあるＩＤコードのリストについて、ポンプ１２から受信されたキャラクタをチェックすることで判定され得る。正しいレスポンスが受信された場合、ルーティンは分岐して、ステップ４１０に進む。ステップ４１０では、例えば、受信されたポンプＩＤコードを少なくとも１つの可能性のあるＩＤコード（輸液ポンプの特定のタイプを識別する）と比較することによってか、あるいは、受信されたＩＤコードを可能性のある多くのＩＤコード（各コードは、輸液ポンプの特定のタイプを識別する）と比較することによって、ポンプのタイプが判定される。本明細書中で利用される場合、輸液ポンプの「タイプ」は、ポンプのモデルまたはポンプのソフトウェアバージョンに関連し得る。
【００４９】
ステップ４０８によって判定された場合に正しいレスポンスが受信されなかった場合、ステップ４１２では、タイマーによって計測されたルーティンが所定の期間が、ターミネーションキャラクタを受信する前に満了したかどうかを判定する。もし満了していた場合、ルーティンは分岐して、ステップ４１４に進み、ステップ４１４では、エラーメッセージが、ポンプの障害により生成され、ポンプＩＤ要求に応答する。
【００５０】
ステップ４１２では、いくつかのタイプのレスポンス（正しいレスポンスではない）が、タイマーが満了する前に受信された場合、ルーティンは分岐して、ステップ４１６に進む。ステップ４１６〜４２６は、リモートモニタ／コントローラ２０に接続される輸液ポンプ１２のタイプを判定する第２の方法を含み、これは、ポンプ１２のディスプレイ９２のキャラクタの数に基づく。例えば、輸液ポンプの第１のタイプは、１２個のキャラクタを表示することができるディスプレイを有し得るのに対し、輸液ポンプの第２のタイプは、３２個のキャラクタを表示することができるディスプレイを有し得る。ステップ４１６〜４２６は、ディスプレイのキャラクタの数に基づいて、輸液ポンプのタイプを判定する。
【００５１】
ステップ４１６では、リモートモニタ／コントローラ２０は、ポンプ表示要求を輸液ポンプ１２に送信して、ポンプ１２にそのディスプレイ９２のコンテンツを送信するように要求する。ステップ４１８では、リモートモニタ／コントローラ２０は、ポンプ１２から送信されたディスプレイキャラクタを読む。ステップ４２０では、所定の期間が満了したか、あるいは、終了キャラクタが受信された場合、ルーティンは分岐して、ステップ４２２に進む。ステップ４２２では、タイマーによって計測された所定の期間が、終了キャラクタの受信の前に経過した場合、ルーティンは分岐して、ステップ４２４に進む。ステップ４２４では、適切なエラーメッセージが生成される。ステップ４２６では、ポンプのタイプが、受信されたディスプレイキャラクタの数に基づいて決定される。
【００５２】
ルーティンはまた、所定の数のキャラクタが受信された場合、ステップ４２０を出ることができる。リモートモニタ／コントローラ２０が２つの異なるタイプの輸液ポンプとインターフェースをとるように設計されており、１つのポンプは１２個のキャラクタの表示性能を有し、もう一方のポンプは、３２個のキャラクタを表示性能を有する場合、ステップ４２０にてリモートモニタ／コントローラ２０が１２個より多い表示キャラクタを受信していると、そのポンプタイプが３２個の表示性能を有するポンプに対応していることを直ちに判定することができる。
【００５３】
リモートモニタ／コントローラ２０は、輸液ポンプ１２を制御すること、ポンプ１２の動作をモニタリングすること、ポンプ１２からリモートモニタ／コントローラ２０まで輸液データを送信すること、および、データを表示することを含む、４つの基本機能が実行されることを可能にする。ユーザは、リモートモニタ／コントローラ２０のディスプレイデバイス７８（図２）上に表示された動作モードを、マウス８２を介して選択することによって、これらの機能の１つを実行し得る。これらのモードは、リモートモニタ／コントローラ２０のヘルスケアの専門家がコマンド信号を輸液ポンプ１２に送信して、その動作を制御し得るコマンドモード、輸液ポンプ１２が継続的に可視ディスプレイ９２のコンテンツをリモートモニタ／コントローラ２０に送信するモニタリングモード、輸液データがポンプ１２からリモートモニタ／コントローラ２０まで送信されるダウンロードデータモード、および、輸液データがリモートモニタ／コントローラ２０のディスプレイ７８に表示され得る表示データモードを含む。
【００５４】
図１０は、リモートモニタ／コントローラ２０の基本動作のフローチャート４５０を示す。図１０を参照すると、ステップ４５２にて、ユーザが上述のコマンドモードを選択した場合、ルーティンは分岐して、ステップ４５４に進む。ステップ４５４では、輸液ポンプ１２のキーパッド９０のディスプレイが、ディスプレイデバイス７８に示される。ステップ４５４で示されるディスプレイは、リモートモニタ／コントローラ２０に接続された特定の輸液ポンプのタイプのキーパッド９０の入力キーと実質的に同一の、空間的構成を有する複数の可視入力キーを含む。このような可視ディスプレイの例は、図１１Ａに示される。
【００５５】
尚、図１１Ａに示される可視キーパッドは、図３に示される（ポンプ１２のオン／オフキーが可視キーディスプレイのリセットキーに置き換えられることを除き）ポンプ１２の実際のキーパッド９０と同一である。異なるキーパッドを有する異なるタイプのポンプがリモートモニタ／コントローラ２０に付加される場合、その特定のキーパッドは、ディスプレイデバイス７８に表示される。異なる可視キーパッドの例が、図１１Ｂに示される。様々な可視キーパッド構成が、リモートモニタ／コントローラ２０のメモリに格納され得、各可視キーパッド構成は、その構成に関連するポンプタイプコードを有する。リモートモニタ／コントローラ２０は、（図９のルーティンを介して）最初にリモートモニタ／コントローラ２０が付加されるポンプのタイプを決定するので、メモリおよびディスプレイからポンプのタイプの対応する可視キーパッドを取り出し得る。
【００５６】
可視キーパッドが表示された後、ヘルスケアの専門家は、いくつかの可視キーをマウス８２により選択することによって、輸液ポンプ１２の動作を制御し得る。タッチ感知スクリーンまたは放射線センサによって駆動される画面のような、キーを選択するほかの方法が利用され得る。輸液ポンプ１２は、キーパッド９０を介して入力されるコマンド、リモートモニタ／コントローラ２０から生成されるコマンドに応答する。ステップ４５６および４５８では、ヘルスケアの専門家によって入力された任意のコマンドが、輸液ポンプ１２に送信され、ステップ４６０および４６２において、ポンプ１２のディスプレイは、リモートモニタ／コントローラ２０に送信され、リモートモニタ／コントローラ２０のディスプレイデバイス７８上に表示される。ステップ４６４では、ユーザがコマンドモードを終了した場合、ルーティンは分岐して、ステップ４５２に戻る。
【００５７】
ステップ４６５では、ヘルスケアの専門家がモニタモードを選択した場合、ルーティンは分岐して、ステップ４６６に進み、ステップ４６６では、ポンプ表示９２の可視表示がディスプレイデバイス７８に示される。ステップ４６７では、ポンプ表示９２のコンテンツが、リモートモニタ／コントローラ２０に送信され、ステップ４６８では、これらのコンテンツは、ステップ４６６で生成された可視表示で表示される。ステップ４６９では、ユーザがモニタモードを終了した場合、ルーティンは分岐して、ステップ４５２に進む。そうでなければ、ルーティンは分岐して、ステップ４６７に戻り、ポンプ表示９２のコンテンツは、ステップ４６８にてディスプレイデバイス７８に連続的に示される（輸液ポンプ１２のディスプレイ９２は、ポンプ動作がディスプレイ９２を閲覧することによってモニタリングされ得るように、ポンプ動作にしたがって変化する）。ステップ４６７は、たとえば、ポンプ１２にポンプ表示要求を送信することによって（上述のステップ４１６〜４２０と同様のステップを介して）達成され得る。
【００５８】
ステップ４７０で判定される際に、ヘルスケアの専門家がポンプ１２からリモートモニタ／コントローラ２０までデータをダウンロードする要求を入力する場合、ルーティンは分岐して、ステップ４７２に進み、ステップ４７２では、図１３〜１４と関連させて以下に示されるように、データ送信が達成される。ユーザがステップ４７４にて判定される際に、閲覧データログ要求を入力する場合。ルーティンは分岐して、ステップ４７６に進み、ステップ４７６では、ステップ４７２で既にダウンロードされたデータが、リモートモニタ／コントローラ２０のディスプレイデバイス７８に表示され得る。ユーザは、ステップ４７８を介してモード選択ルーティン４５０を終了し得る。
【００５９】
図１２は、図１０に概略的に示される送信コマンドステップ４５８を実装するために利用され得る１つのルーティンを示す。図１２を参照すると、ポンプコマンドは、ステップ４８０にてリモートモニタ／コントローラ２０から送信され、その後、輸液ポンプ１２が、リモートモニタ／コントローラ２０にコマンドのエコーを送信し、それにより、リモートモニタ／コントローラ２０は、コマンドがポンプ２１によって適切に受信されたことを知る。エコーを作るキャラクタは、ステップ４８２、４８４によって受信され、エコーが正しくない場合、エラーメッセージが、ヘルスケアの専門家に対して表示される。ステップ４９０にて、リモートモニタ／コントローラ２０は、ポンプ１２にエコーの確認を送信する。
【００６０】
図１０のステップ４６８にて概略的に示される輸液ポンプ１２からリモートモニタ／コントローラ２０までのデータの送信は、輸液ポンプ１２によって実行される受信インタラプトサービスルーティン５００および送信インタラプトサービスルーティン５５０を介して達成される。ルーティン５００、５５０のフローチャートは、図１３および図１４に示される。
【００６１】
図１３に示される受信ルーティン５００は、ポンプコントローラ１００による受信インタラプトの発生時に呼び出される。受信インタラプトは、コントローラ１００の受信バッファ１１８で、リモートモニタ／コントローラ２０からのメッセージが受信されたことを示す。ダウンロードデータコマンドが輸液ポンプ１２に送信された場合（図１０のステップ４６６にて判定される場合に）、データダンプフラグが論理「１」に設定され、ポンプ１２からリモートモニタ／コントローラ２０へのデータ送信またはダンプが進行中であることを示す。データ送信は、セグメント化される様式で実行される。ＲＡＭ１０４から格納される全ての輸液データおよび患者データを、１つの連続ストリームでリモートモニタ／コントローラ２０に送信するのではなく、データは、セグメント化された複数の部分として送信され、各部分は、例えば１００マイクロ秒の期間で、隣接する部分から時間で分離される。
【００６２】
図１３を参照すると、ルーティンがステップ５０２で開始するとき、キャラクタまたはメッセージは、受信バッファ１１８でちょうど受信されている。ステップ５０２では、データダンプフラグがアクティブであり、データ送信が既に進行中であることを意味する場合、ルーティンは分岐して、ステップ５０４に進み、ステップ５０４では、データダンプフラグは、ロジック「０」に設定され、データダンプ動作を効果的に送信し、ステップ５０６にて、リモートモニタ／コントローラ２０にエラーメッセージが送信される。これは、データダンプ動作がリモートモニタ／コントローラ２０から輸液ポンプ１２まで送信される任意のコマンドと干渉することを防ぐためになされる。
【００６３】
データダンプフラグがステップ５０２にて判定される場合にアクティブでない場合、ルーティンは分岐して、ステップ５０８に進む。ステップ５０８では、受信バッファ１１８でちょうど受信されたメッセージは、このメッセージがデータダンプコマンドであるかどうかを判定するためにチェックされる。もし、データダンプコマンドでなければ、ルーティンは分岐して、ステップ５１０に進み、ステップ５１０にて、ポンプ１２は、コマンドに応答する。
【００６４】
メッセージがデータコマンドであれば、ルーティンは分岐して、ステップ５１２に進み、ステップ５１２では、送信ポインタ５１３（図７を参照）は、リモートモニタ／コントローラ２０にまだ送信されていないＲＡＭ１０４の最も古いデータに設定される。ステップ５１４にて、新しいデータ送信動作が開始した後、データダンプフラグが論理「１」に設定される。ステップ５１６にて、送信ポインタ５１３によって指定されるデータバイトが、ＲＡＭ１０４から取り出され、ステップ５１８にて、送信ポインタ５１３の位置が送信された次のデータバイトのアドレスにポイントされるように更新される（例えば、インクリメントされる）。ステップ５２０にて、ステップ５１６で取り出されたデータバイトは、ＡＳＣＩＩでフォーマットされ、ステップ５２２にて、送信インタラプトがイネーブルされ、ステップ５２４にて、再フォーマットされたデータバイトが、輸液ポンプ送信バッファ１１６からリモートモニタ／コントローラ２０までデータリンク３８を介して送信される。
【００６５】
第１のデータバイトが送信バッファ１１６から送信されつくした場合、送信インタラプトがコントローラ１００によって生成され、送信バッファ１１６がエンプティであり、別のデータバイトが送信され得ることを示す。送信インタラプトが生成すると、送信ルーティン５５０が実行される。図１４を参照すると、ステップ５５２にて、データダンプフラグのステータスがチェックされる。フラグがアクティブでなく、データダンプ動作が進行中でないことを意味する場合、ルーティンは分岐して、ステップ５５４に進み、ステップ５５４では、ルーティンは他のインタラプトに応答する。データダンプフラグがアクティブである場合、ルーティンは分岐して、ステップ５５６に進み、ステップ５５６にて、このルーティンは、全てのセグメント化された輸液データの部分が送信されたかどうかを判定する。これは、例えば、送信ポインタ５１３およびポインタ３７６（図７）が同一のメモリ位置をポイントしているかどうかを判定することによって達成され得る。全ての要求されたデータが送信された場合、ルーティンは分岐して、ステップ５５８に進み、送信インタラプトがディゼーブルされ、その後、ステップ５６０に進み、ステップ５６０にて、データダンプフラグが論理「０」にリセットされ、データ送信動作が効果的に終了する。
【００６６】
ステップ５５６で判定される場合に、全てのデータが送信されていなかった場合、ルーティンは分岐してステップ５６２に進み、ステップ５６２にて、送信ポインタ５１３によって指定されるデータバイトが、ＲＡＭ１０４から取り出される。ステップ５６４にて、送信ポインタの位置が、送信される次のデータバイトのアドレスをポイントするように更新される。ステップ５６６にて、ステップ５６２で取り出されたデータバイトは、ＡＳＣＩＩでフォーマットされ、ステップ５６８にて、再フォーマットされたデータバイトは、輸液ポンプ送信バッファ１１６からリモートモニタ／コントローラ２０にデータリンク３８を介して送信される。
【００６７】
セグメント化されたデータ部分をリモートモニタ／コントローラ２０に送信さするようにコントローラ１００によって生成された送信インタラプトは、シャフトエンコーダセンサ１３０の入力に応答して生成されるインタラプトよりも低いプライオリティを割り当てられる。シャフトエンコーダセンサ１３０は、所望の輸液速度を提供するために必要となる。結果的に、輸液データおよび患者データの送信は、ポンプ１２の所望の輸液速度を提供する能力とインターフェースを取らず、データ送信は、ポンプが患者に薬を注入している間に生じ得る。
【００６８】
図１５は、リモートモニタ／コントローラ２０のディスプレイデバイス７８に示され得るグラフィカルユーザメニューの図である。ヘルスケアの専門家は、開始日時、終了日時、データのタイプ等の多くの様々なパラメータを介して、送信または閲覧する特定のデータを選択し得る。送信または閲覧するために特定のデータが選択され得る特定の耐容は、本発明にとって重要であるとは考えられない。
【００６９】
さらに、図１６〜２４は、特定の患者の状態および／または特定の患者の環境の変化に基づいて医療処置を配当するために医療処置配信制御を利用する医療処置管理システム６１０を示す。図１６に示されるように、医療処置管理システム６１０の１つの実施形態は、輸液ポンプ１２で有り得る医療デバイス６１２、医療デバイス６１２に接続された制御アルゴリズム６２６、および患者６１８に接続されたセンサ６１６を備える。医療デバイス６１２は、輸液ポンプ、人工呼吸器、インシュリン配信デバイス、および麻酔配信デバイスを備えるがこれらに制限されない様々なデバイスの１つであってもよいが、当業者であれば、他の医療デバイスが本発明の範囲から逸脱することなく利用され得ることを理解し得る。さらに、医療デバイス６１２は、上述のようにプログラム可能であり得、さらに当業者によって理解される。
【００７０】
１つの実施形態では、図３に示される輸液ポンプ１２は、患者６１８への液体薬（ｌｉｑｕｉｄ ｍｅｄｉｃａｎｔ）を管理する医療デバイス６１２として利用される。通常、医療デバイス６１２は、薬剤の供給（示されない）および患者６１８への薬剤を配信する手段（示されない）を有する。輸液ポンプ１２により、薬剤の供給は、通常、注射器またはＩＶタイプバックに含まれる液体薬である。さらに、輸液ポンプ１２により、薬剤を配信する手段は、液体輸液デバイスを備え、多くの場合、患者に接続されることに適合する中空針またはカテーテル、液体輸液デバイスに接続されるコンジットまたはチューブ、液体輸液デバイスによりコンジットを介して患者に液体薬をポンピングするポンピングメカニズム、ならびに、ポンピングメカニズムを制御するコントローラを備える。しかし、他のタイプの医療デバイスが利用される場合、医療処置および処置を配信する手段は、特定の医療デバイスに一致するように変化する。例えば、それぞれ適切な配信手段により、人工呼吸器は、患者に酸素を供給し、インシュリン配信メカニズムは、患者にインシュリンを配信し、麻酔デバイスは、麻酔ガスまたは麻酔薬を患者に提供する。
【００７１】
図１６に示される実施形態では、センサ６１６は、患者６１８に接続され、患者６１８の生理学的状態に関する情報を患者６１８から受信する。当業者には理解されるように、このような生理学的状態は、患者の心拍、患者の体温、患者の血圧、患者の活動レベル、患者の細胞の代謝、患者の細胞の増殖、患者の代謝要求、患者の食物摂取量、および患者のＳｐＯ２レベル等を含むが、これらに制限されない。これらのファクタおよび当業者に知られた他のファクタは、医療処置、および、特に薬物療法を病状の治療中の個人に配当するためのトリガーとなる出来事であると理解される。さらに、センシングデバイスは、手動の入力を受信する入力デバイスを備え得る。手動の入力は、ヘルスケア提供者または患者によって提供され得る。センシングデバイスに入力を提供する患者の例は、医療デバイス１２がインシュリン配信メカニズムである場合である。このように、患者は、患者によって消費される食べ物のタイプを示す入力をセンサに提供し得る。
【００７２】
１つの実施形態では、複数のセンサ６１６は、患者の特定の物理パラメータを継続的にモニタする携帯用多パラメータの生理学的モニタ（図示されず）に含まれる。モニタは、ＥＫＧ電極、胸部拡張センサ、加速度計、胸部マイクロフォン、バイオメトリック圧力センサ、体温センサ、および周囲温度センサを含む、センサ６１６を有する。各センサは、アナログデジタル変換器（ＡＤＣ）に出力信号を提供する。
【００７３】
このような実施形態では、センサ６１６は、身体ストラップ（図示されない）に設けられ得、身体ストラップは、上部に様々なセンサおよびサポーティング電子機器が配当される胸部ストラップを含み得る。（さらに、多パラメータモニタリングデバイスが、胸部以外の身体の一部分のまわりにストラップによってマウントされ得ることが当業者に理解される。）胸部ストラップは、患者６１８の胴のまわりに適合するように適合される。
【００７４】
様々なパラメータセンサ６１６は、センサが検出するパラメータ（単数または複数）に最も適したストラップに配置される。各センサ６１６は、信号処理の分野では公知であるように、センサ信号をフィルタリングおよび増幅するアナログ回路に電気的入力を提供し、コントローラハードウェアの一部分であり得るアナログデジタル変換器にそれらのセンサ信号を出力する。ストラップのセンサは、以下のようであり得る。患者の胸部の表面の温度を感知する胸の温度センサ、患者の環境の周囲のバイオメトリック圧を感知するバイオメトリック圧力センサ、患者の胸部の拡張および収縮を示す胸部ストラップの伸張を検出する胸部拡張（人工呼吸）センサ、患者の身体の運動および傾きを検出する加速度計、患者の環境の周囲温度を感知する周囲温度センサ、患者の胴内からの音を検出するマイクロフォン、腕の下の患者の胴の側面の温度を感知する脇の下温度センサ、ならびに心筋のアクションによって生じる電気信号を検出するＥＫＧ電極である。ＥＫＧ電極は、グランドまたは基準電極と組み合わせて利用され、患者の胸部の肌に接触して配置され、患者の心筋のポンピングアクションによって発生する電気信号を検出する。ＥＫＧ（電極心電図）が、医学分野で周知である、患者の心臓の動きを示す。
【００７５】
さらに図１６に示されるように、センサ６１７は、センサ６１６に加えて、または、センサ６１６の代わりに提供され得る。センサ６１７は、患者６１８の環境に関する情報を取得する。通常、センサ６１６、６１７は、患者６１８のからの介入なく、自動的に患者の生理学的状態および／または環境条件のそれぞれに関する信号を取得する。制御アルゴリズム６２６によって必要とされる情報に基づいて、複数のセンサ６１６、６１７は、直列または並列に利用され得る（図１６、１９、２２、および２３）。
【００７６】
センサ６１６、６１７は、個人の心拍、体温、血圧、活動レベル、細胞の代謝、細胞の増殖、代謝要求、ＳｐＯ２レベル等に関するか、あるいは、周囲温度、周囲の光条件等の環境条件６１７に基づく信号のような信号を受信することができる任意のデバイスであり得る。図４および５に示されるように、このようなセンサ６１６、６１７は、バイタルサインモニタ、血圧モニタ、光センサ、環境センサ、および活動センサを含み得るがこれらに限定されない。さらに、図６に示されるように、別個のコンポーネントではなく、センサ１６、１７は、コントローラ２８と統合されてもよい。
【００７７】
センサ６１６、６１７から受信した信号は、制御アルゴリズム６２６に電気的に送信される６２４。図１７、１８、および２１に示されるように、制御アルゴリズム６２６は、コントローラ６２８（プロセッサとも呼ばれる）の一部であってもよい。さらに、図１８に示されるように、コントローラ６２８は、医療デバイス６１２のコンポーネントであってもよい。患者６１８に対して管理される特定の医療処置に応じて、制御アルゴリズム６２６は、１つ以上のセンサ６１６、６１７から信号を要求し得る。患者の休息活動または代謝サイクルが、コルチゾール、肝酵素、およびクレアチンの血液細胞数、血漿、または血清濃度を含む様々な要素を計測することによって、観血的に判定され得ることが理解される一方で、他の方法もまた利用可能である。例えば、患者の休息活動または代謝サイクルは、患者のバイタルサインまたは活動によって非観血的に計測され得る。さらに、患者の体温が夜間に低下し、患者の心拍は、患者が休息しているときに低下することが発見された。したがって、このような信号は、センサ６１６、６１７によって取得され、このような情報は、処理のための制御アルゴリズム６２６に送信される６２４。
【００７８】
制御アルゴリズム６２６が異なる医療処置ごとにおそらく異なることが理解され、さらに、同一の医療処置に対しても、制御アルゴリズム６２６が異なる患者では異なり得ることも理解される。制御アルゴリズム６２６の１つの例が、図２４に示される。図２４に示されるように、制御アルゴリズム６２６は、患者６１８の心拍の関数として、患者への薬剤の配信を制御するために利用され得る。この実施形態では、制御アルゴリズム６２６は、患者の心拍の信号をセンサ６１６の１つから受信する。制御アルゴリズム６２６は、最大心拍と信号を比較することによって、信号６３０を処理する。心拍信号が最大心拍信号よりも小さい場合に、制御アルゴリズムは、フィードバック制御６３２を展開（ｄｅｖｅｌｏｐ）して、輸液ポンプ１２の輸液の速度を２％まで低下させる。心拍信号が最大心拍信号よりも小さくない場合に、制御アルゴリズムは、さらに、輸液療法が完了したかどうかを判定する。輸液療法が完了していない場合、輸液を続けるための、フィードバック制御６３２が提供される。心拍信号のさらなる処理６３０がその後も継続される。輸液療法が完了していた場合、輸液ポンプ１２を停止するための、フィードバック制御６３２が提供される。
【００７９】
制御アルゴリズム６２６が送信された信号６２４を受信した後、この制御アルゴリズム２６は、制御アルゴリズム６２６を介して信号を処理し６３０、結果として生じるフィードバック制御６３２が展開される。複数の信号が複数のセンサ６１６、６１７から要求され、かつ、受信された場合に、各必要とされる信号は、プログラムされる制御アルゴリズム６２６によって処理され、結果として生じるフィードバック制御６３２が展開される。フィードバック制御６３２は、医療デバイス６１０の制御信号として動作して、患者６１８への医療処置の配信を制御または調整する。
【００８０】
これは、医療デバイス６１０に、制御アルゴリズム６２６によって展開されたフィードバック制御６３２を送信する６３４ことによって達成される。フィードバック制御６３２は、医療デバイス６１０の動作にコマンドを提供する。フィードバック制御６３２は、通常、医療デバイス６１０の信号またはコマンドの２つのうちの１つを提供する。すなわち、患者６１８に医療処置を配信する６３６か、または、患者に医療処置を配信しない６３８かのどちらかである。フィードバック制御６３２は、医療処置を配信する６３６ために信号を提供する場合、患者６１８に提供する処置の量および速度を指示する医療デバイス６１２に信号を提供し得る。このような信号は、薬剤配信の速度を増加または減少させることを含み得る。
【００８１】
図２２に示されるように、複数の医療デバイス６１２ａ、６１２ｂは、患者６１８に医療処置を配信する６３６ために利用され得る。特定の医療治療は同じであってもよく、異なるように単に服用されてもよく、あるいは、各医療デバイス６１２ａ、６１２ｂは、患者６１８に異なる医療処置を配信６３６してもよい。さらに、図２２に示されるように、それぞれ医療デバイス６１２ａ、６１２ｂごとに、別個の制御アルゴリズム６２６ａ、６２６ｂが利用され得る。図７の実施形態は、２つの別個の制御アルゴリズム６２６ａ、６２６ｂ、および多くのセンサ６１６ａ、６１６ｂ、および６１７を利用する。センサ６１６ａ、６１７は、制御アルゴリズム６２６ａに信号を送信６２４し、制御アルゴリズム６２６ａは、患者６１８に配信される６３６処置に応じて、センサ６１６ａ、６１７の一方または両方からの信号を処理し６３０、結果として生じるフィードバック制御６３２ａを展開し得る。センサ６１６ｂは、信号を制御アルゴリズム６２６ｂに送信し、制御アルゴリズム６２６ｂは、同様に信号を処理して６３０、結果として生じるフィードバック制御６３２ｂを展開する。フィードバック制御６３２ａが第１の医療デバイス６１２ａに送信され、患者６１８への医療処置の配信６３６ａを制御しつつ、フィードバック制御６３２ｂが第２の医療デバイス６１２ｂに送信され、同じ患者６１８に医療処置の配信６３６ｂを制御する。
【００８２】
逆に、図２３に示されるように、１つの制御アルゴリズム６２６は、複数の医療デバイス６１２ａ、６１２ｂを制御し得る。この実施形態では、１つの制御アルゴリズム６２６は、複数のセンサ６１６ａ、６１６ｂ、および６１７により利用され得る。センサ６１６ａ、６１６ｂ、および６１７は、制御アルゴリズム６２６に信号を送信６２４し、制御アルゴリズム６２６は、患者６１８に配信される６３６処置に応じて、１つ以上のセンサ６１６ａ、６１６ｂ、および６１７からの信号を処理し６３０、結果として生じる１つ以上のフィードバック制御６３２ａ、６３２ｂを展開し得る。フィードバック制御６３２ａが第１の医療デバイス６１２ａに送信され、患者６１８への医療処置の配信６３６ａを制御しつつ、フィードバック制御３２ｂが第２の医療デバイス１２ｂに送信され、同じ患者６１８への医療処置の配信６３６ｂを制御する。したがって、この実施形態では、第１の医療デバイス６１２ａの制御アルゴリズムは、第２の医療デバイス６１２ｂと同じ制御アルゴリズム６２６である。
【００８３】
医療処置装置６１０は、異なる処置療法により利用され得るので、制御アルゴリズム６２６は、通常、異なる処置療法ごとに改変または変更される。したがって、図１６および図１７に示されるように、通常、入力デバイス６４２が提供され、制御アルゴリズム６２６の制御パラメータ６４４を調節および設定し得る。入力デバイス６４２は、コントローラ６２８に接続されてもよいし、直接的に制御アルゴリズム６２６に接続されてもよい。制御アルゴリズム６２６は、手動で入力されてもよく、一方で、さらに、データベースまたはネットワークから動的にダウンロードされてもよい。
【００８４】
さらに、図１６に示されるように、医療デバイス６１２はまた、医療デバイス６１２用の入力デバイス６４８を有し得る。医療デバイス１２用の入力デバイス６４８は、ユーザ（通常は認可された臨床医）が制御コマンド６５０を入力して、医療デバイス６１２のパラメータを調節または制御することを可能にする。別の実施形態では、医療デバイス６１２用の入力デバイスは、コントローラ／制御アルゴリズム用の入力デバイスと同じである。
【００８５】
図１７に示されるように、制御アルゴリズム６２６および／またはコントローラ６２８の制御パラメータをリモートで調節または設定するために、リモートコントローラ６４６（すなわち、リモート入力デバイス）が提供され得る。本発明の譲受人に譲渡された米国特許第５，８８５，２４５号は、リモートコントローラを開示し、特に本明細書中で参照として援用され、本発明の一部をなす。リモートコントローラ６４６は、医療デバイス６１２が配置される（すなわち第１の位置）部屋の位置から離れた部屋の位置（すなわち、第２の位置）に配置される。リモートコントローラ６４６は、医療デバイス６１２が配置される建物と同じ建物の異なる部屋に配置されて得、または、医療デバイス６１２が配置される建物とは異なる建物に配置され得る。リモートコントローラ６４６は、データリンク６５４を介して従来の音声／データモデム６５２に接続され、モデム６５２はまた、音声リンク６５８を介して電話６５６に接続される。医療デバイス６１２は、データリンク６６２を介して従来の音声／データモデム６６０に接続され、モデム６６０は、音声リンク６６６を介して電話６６４に接続される。２つのモデム６５２、６６０は、通信リンク６６８を介して双方向性音声およびデータ通信に相互接続され、通信リンク６６８は、例えば、電話線であり得る。さらに、リモートコントローラ６４６は、インターネット、イントラネット、およびワイヤレスネットワークを介して、制御アルゴリズム６２６と通信し得る。さらに、リモートコントローラ６２６は、サーバであってもよい。
【００８６】
特定の実施形態が説明され、かつ記載されたが、多くの改変が本発明の意図から著しく逸脱することなく想定され、保護の範囲は、添付の請求項の範囲によってのみ制限される。
【図面の簡単な説明】
【００８７】
【図１】図１は、患者に対する医療処置を管理し、患者の状態をモニタする装置のブロック図である。
【図２】図２は、図１に概略的に示されるリモートモニタ／コントローラの電子機器コンポーネントのブロック図である。
【図３】図３は、図１に概略的に示される輸液ポンプの１つの実施形態の前面図である。
【図４】図４は、図３の輸液ポンプの電子機器コンポーネントのブロック図である。
【図５】図５は、輸液ポンプの動作全体のフローチャートである。
【図６】図６は、輸液ポンプの動作中に実行される多数のデータ記録ステップを示す。
【図７】図７は、輸液ポンプのメモリの一部を示す。
【図８】図８は、輸液ポンプの動作に関するデータおよび患者の状態に関するデータを格納するために利用され得る格納データルーティンのフローチャートである。
【図９】図９は、リモートモニタ／コントローラが接続される輸液ポンプの型を識別するために利用され得るルーティンのフローチャートである。
【図１０】図１０は、リモートモニタ／コントローラのモード選択ルーティンのフローチャートである。
【図１１Ａ】図１１Ａは、リモートモニタ／コントローラによって生成される可視表示の一部を示す。
【図１１Ｂ】図１１Ｂは、リモートモニタ／コントローラによって生成される可視表示の一部を示す。
【図１２】図１２は、リモートモニタ／コントローラによって実行されるコマンドポンプルーティンのフローチャートである。
【図１３】図１３は、輸液ポンプによって実行される受信ルーティンのフローチャートである。
【図１４】図１４は、輸液ポンプによって実行される送信ルーティンのフローチャートである。
【図１５】図１５は、リモートモニタ／コントローラによって表示され得るグラフィカルユーザメニューの図である。
【図１６】図１６は、本発明の医療処置管理システムのブロック図である。
【図１７】図１７は、リモート制御を含む、図１６の医療処置管理システムの変形のブロック図である。
【図１８】図１８は、コントローラが医療デバイスのコンポーネントである、図１６の医療処置管理システムの別の変形のブロック図である。
【図１９】図１９は、さまざまなセンシングデバイスを含む、図１６の医療処置管理システムの別の変形のブロック図である。
【図２０】図２０は、さまざまなセンシングデバイスを含む、図１６の医療処置管理システムの別の変形のブロック図である。
【図２１】図２１は、コントローラおよびセンシングデバイスが統合コンポーネントである、図１６の医療処置管理システムの別の変形のブロック図である。
【図２２】図２２は、複数の医療処置デバイスを含む、図１６の医療処置管理システムの別の変形のブロック図である。
【図２３】図２３は、複数の医療処置デバイス用のプロセッサを含む、図２２の医療処置管理システムの別の変形のブロック図である。
【図２４】図２４は、１つのタイプの本発明の制御アルゴリズムのブロック図である。
【技術分野】
【０００１】
（関連参照）
本願は、１９９９年３月１９日に出願された米国特許第０９／２７２，５０２号の一部継続出願であり、米国特許第０９／２７２，５０２号は、米国特許第５，８８５，２４５号の継続出願であり、米国特許第５，８８５，２４５号は、（現在破棄された）１９９６年８月２日に出願された米国特許第０８／６９１，６８７号の一部継続出願であり、これらの出願は、本明細書中で参照として援用され、本明細書の一部をなす。
【０００２】
（技術分野）
本発明は、リモート位置から輸液ポンプ等の医療デバイスをモニタおよび／または制御する装置に関する。
【背景技術】
【０００３】
（発明の背景）
輸液ポンプは、患者に液体薬を自動的に管理するために利用される。液体薬は、薬のソースから供給され、カテーテルまたは他の注入デバイスを介して患者にポンピングされる。液体が注入される方法は、輸液ポンプによって制御される。輸液ポンプは、液体薬が連続的に一定の速度で注入される連続モード、または、注入速度が徐々に増加し、一定になり、その後徐々に減少する傾斜（ｒａｍｐ）モードのような、様々な輸液のモードを有し得る。
【０００４】
通常、輸液ポンプのモニタは、輸液ポンプに組み込まれた視覚表示手段をよく見ることによって行われ、輸液ポンプの制御は、キーパッドのような輸液ポンプと統合された入力デバイスを起動することによって行われる。結果的に、輸液ポンプのモニタおよび／または制御は、輸液ポンプが配置されている同じ位置で行われる。
【０００５】
さらに、多くのタイプの医療処置では、処置の影響および最終的な有用性は、治療に対する患者の耐容性および感受性に依存する。このような測定は、正確かつ効果的に患者を治療する際に、医者を支援する。しかしながら、現在のところ、特定の被験者の実際の計測または被験者の環境ではなく客観的な計測に基づいて、多くの医療処置が患者に提供されている。
【０００６】
例えば、多くの薬物療法の典型的な医療処置パラメータは、一般的な２４時間周期のシステムに基づいて提供される。２４時間周期のシステムの下では、植物および動物の典型的な生理学的機能は、およそ２４時間間隔で再発することが、医療産業界では知られている。人間の場合、身体の時計は、視交差上核（ＳＣＮ）に配置され、別個の細胞群は、視床下部内に検出される。ＳＣＮは、人間の身体の２４時間周期のリズムを制御または調整する。通常、人間の２４時間周期のリズムは、松果体によるメラトニン分泌を介して、眼を通る光と暗闇との交代によってキャリブレーションされる。
【０００７】
さらに、通常の人間の組織の細胞の代謝および増殖は、同様のリズムを表し、これにより、振幅ならびにピークおよびトラフの時間が予測可能となる。このようなリズムは、薬理学的特性、耐容性、および最終的な有用性に影響する。例えば、２４時間周期のリズムは、癌治療における、耐容性および抗腫瘍性の効能を含む、抗癌性医薬品の利用および効果に影響する。したがって、時間薬理学の処置（ｉｎｔｅｒｖｅｎｔｉｏｎ）では、抗癌剤薬物は、特に化学療法とともに、標準的な２４時間周期のリズムにしたがって配信される。例えば、Ｆｌｏｘｕｒｉｄｉｎｅ配信は、通常４回に分けて服用され、各服用量は、一日の時間に依存する。
【０００８】
午前９時〜午後３時の間に服用量の１４％
午後３時〜午後９時の間に服用量の６８％
午後９時〜午前３時の間に服用量の１４％
午前３時〜午前９時の間に服用量の４％
通常、薬剤が配信される時間は、医者によって選択され、患者の代謝の変化と客観的に一致する。しかし、２４時間周期のリズムは、単に、患者の代謝の変化の推定値であり、実際の患者の代謝には基づいていない。したがって、薬剤配信が実際に患者の実際の代謝と一致するかどうかは、評価も判定もされない。
【０００９】
さらに、異なる医療処置は、異なる最適服用時間プロファイルを有する。例えば、異なる抗腫瘍性の薬物は、通常、異なる時間に服用される。ＥｐｉｒｕｂｉｃｉｎおよびＤａｕｎｏｒｕｂｉｃｉｎは、通常、ライトオンセットの後の２時間で服用される。Ｃｙｃｏｐｈａｓｐｈａｍｉｄｅは、通常、ライトオンセットの後の１２時間で服用される。Ｃｉｓｐｌａｔｉｎは、通常、ライトオンセットの後の１５時間で服用される。Ｖｉｎｂｌａｓｔｉｎｅは、通常、ライトオンセットの後の１８時間で服用される。理解され得るように、異なる薬物は、異なる作用のメカニズムを有する。
【００１０】
しかし、他のファクタがまた、適切な医療処置に影響を与える。例えば、通常の組織の最小の感受性は、薬物の代謝（例えば、グルタチオン）に影響を与える酵素レベルに関連すると考えられる。これらの可変量の全体のドライバは、患者の休息活動周期であると考えられる。この効果のために、研究室のラット研究が、１２時間の光および１２時間の暗闇のサイクルの支配下にある動物により導かれるべきであることが知られている。
【００１１】
それにもかかわらず、異なる患者は（癌治療については、および異なる腫瘍でさえ）、全く同一の２４時間周期ではないことが知られている。したがって、２４時間周期の治療の間で最適化するべき少なくとも２つの局面が存在する。（１）腫瘍（単数または複数）のピーク感受性、（２）通常の組織の最小の感受性である。
【００１２】
標準的な時間薬理学の処置は、時間および服用を制御することによって、薬物耐容性の２４時間周期のリズムの利点を利用する。したがって、このことは、毒性の効果を低減し、患者の生活の質を改良することができる。さらに、化学療法の薬物を含む多くの薬物では、少なくとも毒性の２４時間周期の時間でより大きい最大耐用性を示した服用を管理することによって、生存の改良が導かれ得る。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、上述のように、標準的な２４時間周期のシステムに従う医療処置を提供することには、多くの欠点が存在する。
【課題を解決するための手段】
【００１４】
本発明のある局面によると、医療装置は、患者への医療処置を管理するプログラム可能医療デバイスであって、第１の位置に配置される、プログラム可能医療デバイスと、プログラム可能医療デバイスを制御するリモートコントローラであって、プログラム可能医療デバイスが配置される第１の位置から離れた第２の位置に配置される、リモートコントローラとを有する。プログラム可能医療デバイスは、患者への医療処置を管理する手段と、該管理手段を制御する制御コマンドをユーザが入力することを可能にする入力デバイスとを備える。リモートコントローラは、ディスプレイデバイスと、該プログラム医療デバイスの入力デバイスに実質的に対応する仮想入力デバイスの可視表示を生成するディスプレイデバイスに動作可能なように接続される手段と、第２の位置にいるユーザが可視入力デバイスを起動して、ユーザが第２の位置からプログラム可能医療デバイスの動作を制御することを可能にする手段とを備える。
【００１５】
入力デバイスは、例えば、キーパッドであってもよく、仮想入力デバイスは、キーパッドと実質的に同じ構成を有する複数のキーの視覚表示であってもよい。
【００１６】
プログラム可能医療デバイスは、患者への液体薬を管理する輸液ポンプであってもよく、これは、患者に接続されることに適合する液体注入デバイスと、液体注入デバイスに接続されるコンジットと、液体注入デバイスによりコンジットを介して患者に液体薬をポンピングするポンピングメカニズムとを備える。
【００１７】
本発明の別の局面によると、医療処置デバイスは、制御アルゴリズムおよびセンシングデバイスを利用して、薬剤の供給および患者に薬剤を配信する手段を有する。制御アルゴリズムは、医療デバイスに接続される。センシングデバイスは、制御アルゴリズムに接続され、センシングデバイスは、制御アルゴリズムに信号を送信する。制御アルゴリズムは、センシングデバイスから取り出される信号を処理し、薬剤が医療処置デバイスから患者へ配信されるべきかどうかを判定するために、信号の処理の結果に基づいてフィードバック制御を展開する。フィードバック制御は、医療処置デバイスに提供されて、患者への医療処置あの配信を制御する。デバイスのリモートコントローラは、第１の位置から離れた第２の位置に配置される。リモートコントローラは、制御アルゴリズムの動作を制御する入力デバイスを有する。
【００１８】
本発明のさらに別の実施形態によると、本発明の医療配信システムは、プログラム可能医療デバイスと、ローカルコントローラと、リモートコントローラとを備える。プログラム可能医療デバイスは、患者への医療処置を管理する第１の位置に配置され、プログラム可能医療デバイスは、患者への医療処置を管理する手段を有する。さらに、プログラム可能医療デバイスは、プログラム可能医療デバイスの制御コマンドを入力する第１の入力デバイスを有する。ローカルコントローラは、プログラム可能医療デバイスに動作可能に接続される。ローカルコントローラは、第１の位置に配置され、ローカルコントローラの制御コマンドを入力する第２の入力デバイスを有する。さらに、ローカルコントローラは、患者からの信号を受信するように、患者に動作可能に接続され、ローカルコントローラは、プログラム可能医療デバイスの動作を操作する。リモートコントローラは、プログラム可能医療デバイスが配置される第１の位置から離れた第２の位置に配置され、第２の位置のユーザがローカルコントローラを制御することを可能にする手段を有する。
【００１９】
本発明のこれらおよび他の特徴および利点は、好ましい実施形態の詳細な説明から当業者に理解可能であり、好ましい実施形態は、簡単な説明が以下に示される図面を参照して説明される。
【発明を実施するための最良の形態】
【００２０】
（好ましい実施形態の詳細な説明）
図１は、患者への医療処置を管理する装置１０の１つの実施形態を示す。図１を参照すると、装置１０は、輸液ポンプ１２の形式のプログラム可能医療処置手段を含み、輸液ポンプ１２は、１６で概略的に示される液体コンジットを介して、カテーテル１４の形式の液体薬注入デバイスに接続される。
【００２１】
装置１０は、輸液ポンプ１２が配置される部屋の位置から離れた部屋の位置に配置されるリモートモニタ／コントローラ２０を備える。リモートモニタ／コントローラ２０は、ポンプ１２が配置される同じ建物の異なる部屋に配置されてもよいし、あるいは、ポンプ１２が配置される建物と異なる建物に配置されてもよい。リモートモニタ／コントローラ２０は、データリンク２４を介して従来の音声／データモデム２２に接続され、さらに、モデム２２は、音声リンク２８を介して電話２６に接続される。輸液ポンプ１２は、データリンク３２を介して従来の音声／データモデム３０に接続され、モデム３０は、音声リンク３６を介して電話３４に接続される。２つのモデム２２、３０は、例えば電話線となり得る、通信リンク３８を介して、双方向音声およびデータ通信に相互接続される。
【００２２】
図２は、図１に概略的に示されるリモートモニタ／コントローラ２０の電子機器のブロック図である。図２を参照すると、リモートモニタ／コントローラ２０は、マイクロプロセッサ（ＭＰ）６０、リードオンリーメモリ（ＲＯＭ）６２、ランダムアクセスメモリ（ＲＡＭ）６４、および入力／出力（Ｉ／Ｏ）回路６６を備え、これらの全てが、アドレス／データバス６８によって相互接続される。マイクロプロセッサ６０は、データバイトを送信する送信バッファ（ＸＭＩＴ）７０、および、データバイトを受信する受信バッファ（ＲＥＣ）７２を有する。リモートモニタ／コントローラ２０データリンク７６を介してＩ／Ｏ回路６６に接続されるキーボード７４、ライン８０を介してＩ／Ｏ回路６６に接続されるＣＲＴ等のディスプレイデバイス７８、および、ライン８４を介してＩ／Ｏ回路６６に接続される電子マウス８２等の入力デバイスを有する。リモートモニタ／コントローラ２０はまた、ハードディスクドライブまたはフロッピー（登録商標）ディスクドライブ等の１つ以上のディスクドライブを備え得る。
【００２３】
図３は、図１に概略的に示される輸液ポンプ１２の１つの実施形態の前面図である。図３を参照すると、ポンプ１２は、ユーザがデータおよびコマンドを入力し得るキーパッド９０の形式の入力デバイス、ならびに、ユーザにテキストメッセージを表示するディスプレイ９２を有する。
【００２４】
輸液ポンプ１２の電子機器のブロック図が、図４に示される。図４を参照すると、ポンプ１２は、コントローラ１００、組み込みＩ／Ｏインターフェース１０２ａを有する電気的にプログラム可能リードオンリーメモリ（ＥＰＲＯＭ）１０２、不揮発性ＲＡＭ１０４、リアルタイムクロック１０６、ならびにディスプレイ９２を備え、これら全てが、通信バス１０８によって相互接続される。ディスプレイ９２は、バックライト１１を備え、このバックライトは、コントローラ１００およびバックライト１１０を相互接続するライン１１２で発生したイネーブル信号によって選択的に起動される。ＲＡＭ１０４およびリアルタイムクロック１０６の両方が、バッテリー１１４に接続される。このバッテリー１１４は、システム電力が欠乏しているときのみに、ＲＡＭ１０４およびリアルタイムクロック１０６に電力を供給する。コントローラ１００は、通信バス１０８に接続される送信バッファ１１６および受信バッファ１１８を有する。
【００２５】
コントローラ１００は、ライン１２２を介して制御信号を増幅回路１２０に周期的に送信することによって薬輸液速度を制御して、液体コンジット１６（図１）の一部分と接触するように適合されるロータリポンプホイール（図示されない）のような、ポンピングメカニズム１２６を駆動するポンプモニタ１２４を駆動する。
【００２６】
コントローラ１００は、シャフトエンコーダ（ＳＥ）センサ１３０からの周期的入力を受信し、このセンサ１３０は、モータ１２４のシャフトに配置される。ＳＥセンサ１３０は、２つの信号出力をコントローラ１００に提供する二相モーションセンシングエンコーダであり得る。モータ１２４の回転スピードおよびその回転の方向は、２つの信号出力の間の速度および位相の関係に基づいて、コントローラ１０によって決定される。
【００２７】
ＳＥエンコーダ１３０は、周期的に信号をコントローラ１００へライン１３２を介して送信する。信号が送信されるたびに、インタラプトが発生し、コントローラ１００は、モーションシャフトの実際の位置とその所望の位置とを比較し、パルス幅の変調された信号等の新しい制御信号を増幅器１２０にライン１２２を介して送信して、モータ１２４の実際のスピードが、所望の薬輸液速度に必要となるモータスピードに対応することを保証する。ＳＥセンサ１３０によって生じるインタラプトは、最高の優先度を割り当てられることにより、そのインタラプトは、直ちにコントローラ１００によって他のアクションが取られる前に応答を受ける。
【００２８】
ポンプ１２は、本明細書中に記載されない他の多くの他の特徴を有し、これらは、以下の特許出願に記載される。それぞれの出願は、本明細書中で参照として援用される。「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｈａｖｉｎｇ Ｐｏｗｅｒ Ｓａｖｉｎｇ Ｍｏｄｅｓ」と称する１９９５年３月６日に出願された米国特許第０８／３９９，１８４号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｗｉｔｈ Ｓｅｌｅｃｔｉｖｅ Ｂａｃｋｌｉｇｈｔ」と称する１９９５年３月６日に出願された米国特許第０８／３９８，９７７７号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｈａｖｉｎｇ Ｗｉｔｈ Ｄｉｆｆｅｒｅｎｔ Ｏｐｅｒａｔｉｎｇ Ｍｏｄｅｓ」と称する１９９５年３月６日に出願された米国特許第０８／３９８，９８０号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｈａｖｉｎｇ Ｗｉｔｈ Ｄｕａｌ−Ｌａｔｃｈｉｎｇ Ｍｅｃｈａｎｉｓｍ」と称する１９９５年３月６日に出願された米国特許第０８／３９９，１８３号、「Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ Ｗｉｔｈ Ｈｉｓｔｏｒｉｃａｌ Ｄａｔａ Ｒｅｃｏｒｄｉｎｇ」と称する１９９５年３月６日に出願された米国特許第０８／３９８，８８７号である。
【００２９】
輸液ポンプ１２の動作は、ＥＰＲＯＭ１０４に格納されるコンピュータプログラムによって制御され、コントローラ１００によって実行される。動作全体のフローチャート２００は、図５に示される。図５を参照すると、ポンプ１２がオンにされると、ステップ２０２において、ポンプが開始され、ポンプ動作のテストが実行される。ポンプ１２は、輸液の間一時的にオフにされてもよく、この場合、以下に示されるように、ポンプ１２は、オンに戻された場合に輸液を継続し得る。ステップ２０４において、ポンプによって注入される液体の容積がいくらか残っているか、輸液のためのさらなる時間がいくらか残っている場合（ポンプが輸液の間に一時的にオフにされる場合）、プログラムは分岐してステップ２０６に進み、ステップ２０６では、ユーザは、ディスプレイ９２に表示されるメッセージを介して、以前の輸液が再開されるべきかどうかを尋ねられる。ユーザが（キーパッド９０を介して）「はい」と答える場合、プログラムは分岐して、「ｒｅａｄｙ−ｔｏ−ｒｕｎ（実行準備完了）」ステップ２１０に進む。前回の輸液が再開されない場合、プログラムは分岐して、ステップ２１２に進む。
【００３０】
輸液ポンプ１２は、ロックアウトモードを有する。ロックアウトモードでは、ユーザは、注入される容積または輸液の速度等の、輸液パラメータをプログラムすることを妨げられ得る。例えば、ポンプ１２は、注入される特定のフロープロファイル、フロー速度、および容積を有する輸液を配信するように、医療助手によってプログラムされ得る。その輸液をプログラミングした後、医療助手は、ポンプをロックアウトモードにし得る。ロックアウトモードでは、患者は、輸液パラメータのいかなる変更をも防がれる。ステップ２１２では、ポンプ１２が既にロックアウトモードに置かれていた場合、プログラムは分岐して、直接「ｒｅａｄｙ−ｔｏ−ｒｕｎ」ステップ２１０へ進み、全てのプログラムステップを迂回する。
【００３１】
ステップ２１２では、ポンプがロックアウトモードにない場合、プログラムは分岐して、ステップ２１４に進む。ステップ２１４では、プログラムは、ユーザに、ディスプレイ９２を介して、続く輸液の間に患者がポンプをプログラムすることが許可されるべきであるかどうかを入力するように促す。ポンプがプログラム可能でない場合、プログラムは分岐して、ステップ２１６に進む。ステップ２１６では、ロックアウトシーケンスは、どの輸液モードがロックアウトされるべきであるかを入力することをユーザに要求することによって、実行される。ポンプが患者によってプログラム可能である場合、プログラムは、ステップ２１６を迂回する。
【００３２】
輸液ポンプ１２は、５つの輸液の基本モードを有する。１）ポンプが単一の速度で単一の容積を配信する連続モード、２）閾値の速度まで徐々に増加し、閾値速度で一定にとどまり、その後徐々に減少する速度で、ポンプが液体を配信する、自動傾斜モード、３）３時間おきに１つの液体容積等、比較的長い期間の間隔があけられた別個の液体容積をポンプが配信する、断続モード、４）ポンプが、２５の異なる期間のそれぞれの間に固有の輸液速度を配信するようにプログラム可能である、カスタムモード、５）ポンプが、患者の周期的な要求に応答して、鎮痛のボーラスを周期的に注入する、痛みが制御された鎮痛（ＰＣＡ）モードである。
【００３３】
ステップ２１８では、ポンプ１２は、ユーザにプロンプト「継続するか？」をディスプレイ９２に生成する。ユーザがポンプを連続モードで利用することを望む場合、ユーザは、キーパッド９０を介して「はい」と答え、プログラムは分岐して、ステップ２２０に進む。ステップ２２０では、所望の輸液速度、注入される容積等の多くの輸液パラメータを入力することによって、連続モードがユーザによってプログラムされる。ステップ２１８では、ユーザが連続モードを利用したくない場合、ユーザは「いいえ」と答え、プログラムは分岐してステップ２２２に進む。ステップ２２２〜２３６は、５つの可能な輸液モードのうちのどれが選択されるかに依存して、ユーザが異なる輸液パラメータに対して促されることを除き、ステップ２１８および２２０と概ね同じである。
【００３４】
ステップ２２０、２２４、２２８、２３２、または２３６のうちの１つが完了した後、プログラムは分岐して「ｒｅａｄｙ−ｔｏ−ｒｕｎ」ステップ２１０に進む。ユーザが「Ｒｕｎ（実行）」キーを押すと、ポンプ１２は、実行モード２６０を入力し、ステップ２１８、２２２、２２６、２３０、２３４のいずれかで選択された輸液モードならびにステップ２２０、２２４、２２８、２３２、２３６のいずれかで入力された輸液パラメータに応じて、患者に液体薬を注入する。ポンプ１２は、「ホールド」キーが押されるまで実行モード２６０を続ける。警告条件の発生時に、ステップ２６４にて、警告が報告される。ステップ２６２において、ホールドキーが押されると、ステップ２６６にて、輸液が停止し、ポンプ１２は、ステップ２６８にて実行キーが押されるのを待つか、ステップ２７０にてオン／オフスイッチがオフにされるのを待つ。
【００３５】
上述の動作をまとめると、ポンプがロックアウトモードで利用される場合、医療助手は、ポンプをオンにし、所望の輸液モードをステップ２２０、２２４、２２８、２３２、２３６のいずれかでプログラムし、その後、ポンプをオフにする。プログラムされた輸液パラメータは、メモリ１０４に保持される。医療助手は、ポンプをオンに戻し、ステップ２１４にて「プログラム可能？」プロンプトに応じて「いいえ」キーを押し、ステップ２１６にてロックアウト情報を入力し、その後、ポンプを再度オフにする。患者が連続してポンプをオンにして輸液を行う場合、プログラムは、ステップ２１２から直接「ｒｅａｄｙ−ｔｏ−ｒｕｎ」ステップ２１０に進み、ステップ２１０では、患者が輸液パラメータを変更することを防ぐ。
【００３６】
ロックアウトモードが利用されない場合、医療助手または患者は、ポンプをオンにし、所望の輸液モードをプログラムし、その後、「実行」キーを押して輸液をスタートさせる。このとき、決して、ポンプをオフにしない。
【００３７】
プログラミングおよび動作中に、輸液ポンプ１２は、自動的に不揮発性メモリ１０４に全ての重要な輸液データを記録して、完全な履歴データレコードを生成する。この履歴データレコードは、メモリ１０４から後に取り出され、特定の輸液療法がどの程度効果的であったかを決定する際に役立つ診療目的、ならびに、処方された輸液が実際に配信されたことを確認する治療目的を含む様々な目的で利用され得る。
【００３８】
図６は、図５におおよそが示されたポンプ動作全体の間に実行される、輸液データが記録される様々なステップを示す。データの格納をトリガーする多くのイベントが、表１の左側の列にリスト化され、各イベントの発生時に記録される輸液データが、表１の右側の列にリスト化される。リアルタイムクロック１０６によって判定される、輸液データが記録される時間がまた、輸液データとともに格納される。
【００３９】
【表１】
表１および図６を参照すると、輸液ポンプへの電力がオンにされるとき、電力オンのデータおよび時間が記録される。ステップ３０２で判定される際に、ポンプが、ステップ２２０、２２４、２２８、２３２、２３６（図５）のいずれかに準拠して完全にプログラムされる場合、プログラムされた輸液パラメータは、その格納の時間とともに、ステップ３０４で格納される。格納される特定のパラメータは、どの輸液モードがプログラムされたかに依存する。複数の輸液モードのそれぞれについて格納される輸液パラメータのいくつかの例が、以下に設定される表２に示される。
【００４０】
【表２】
ステップ３０６で判定される際にポンプが実行モード２６０（図５）を入力する場合、どの輸液が実行されるのかに準拠したパラメータとともに、実行モードが開始した時間は、ステップ３０８にて格納される。
【００４１】
ステップ３１０では、ホールドキーが押されると、ホールドキーが押された時間に注入される全容積とともに、ホールドキーが押された時間が、ステップ３１２にて格納される。ポンプはまた、連続速度からｋｅｅｐ−ｖｅｉｎ−ｏｐｅｎ（ＫＶＯ；血管を開いたままにする）速度までスイッチングすることによってか、あるいは、断続モードでは、ＫＶＯ速度からより高い輸液速度まで変化させることによって生じる変化のような任意の輸液速度変化を格納する。この変化の存在は、ステップ３１４にて検出される。新しい速度および新しい速度がスタートした時間が、ステップ３１６にて格納される。
【００４２】
ステップ３１８では、警告が生成されると、警告のタイプ、警告が生じた時間、および、警告の時間に注入される全容積が、ステップ３２０にて記録される。
【００４３】
ステップ３３０では、輸液が再開すると（輸液の間にオフにされた後、ポンプがオンに戻るとき）、輸液が再開された時間は、輸液パラメータとともに、ステップ３３１にて格納される。ステップ３３４において判定される際に、ロックアウトシーケンスのプログラミングが完了すると（すなわち、図５のステップ２１６の後）、ロックアウトのプログラミングが完了した時間が、ロックアウトされた輸液モードとともに格納される。ステップ３３８にて、ボーラス要求の検出時に、ボーラスが要求された時間が、ボーラスが実際に与えられたかどうかのインジケーションならびにボーラスの量とともに、ステップ３４０にて格納される。
【００４４】
図７は、ＲＡＭ１０４の一部分のデータ構造を示す。ＲＡＭ１０４では、輸液データ（図６のステップ中に格納されたデータ）が格納される。図７を参照すると、輸液データは、複数のメモリ位置３７２に格納される。データは、ポインタ３７６を利用してメモリ位置３７２に書き込まれ、ポインタ３７６は、データが次に格納されるべきメモリ位置を特定する。
【００４５】
図８は、メモリ位置３７２にデータを格納するルーティン３８０のフローチャートである。図８を参照すると、ステップ３８２では、ポインタ３７６は、データが格納される次のメモリ位置３７２のアドレスにセットされる。ステップ３８４にて、ポインタ３７６が、データが格納され得る最後のメモリ位置にある場合、ルーティンは分岐して、ステップ３８６に進む。ステップ３８６では、ポインタは、データが格納され得る第１のメモリ位置のアドレスにセットされる。ステップ３８４、３８６の結果として、メモリ位置３７２の中身は、周期的に新しいデータで上書きされる。しかしながら、メモリ位置３７２の数は、例えば、数ヶ月間のデータが上書きされる前に格納されるだけ十分に大きい。ステップ３８８および３９０では、データは、ポインタ３７６によって特定されるメモリ位置３７２に格納される（データは、リアルタイムクロック１０６から生成されたタイムスタンプ、ならびに、特定の輸液イベントを特定するイベントデータを含む）。
【００４６】
図９、１０、および１２は、リモートモニタ／コントローラ２０によって実行される様々なルーティンのフローチャートである。以下により詳細に説明されるように、リモートモニタ／コントローラ２０は、輸液ポンプ１２の動作をモニタするために利用され得、輸液ポンプ１２の動作を制御し、および／または、輸液ポンプ１２から輸液データおよび患者データを送信して、その結果、このようなデータは、患者から離れた位置にいるヘルスケアの専門家によって調べられ得る。
【００４７】
リモートモニタ／コントローラ２０は、異なるタイプの輸液ポンプとインターフェースをとるように設計される。どのタイプの輸液ポンプにリモートモニタ／コントローラ２０が動作可能なように接続されるのかを決定するために、ポンプ識別ルーティン１００は、リモートモニタ／コントローラ２０と輸液ポンプ１２との間の通信リンクが確立された後に実行される。図９を参照すると、捨てプＰ４０２にて、リモートモニタ／コントローラ２０は、ポンプ識別（ＩＤ）要求を通信リンク３８を介して輸液ポンプ１２に送信する。ポンプＩＤ要求に応答して、ポンプ１２は、マルチキャラクターＩＤコードをリモートモニタ／コントローラ２０に送信して戻す。ＩＤコードは、例えば、ポンプモデルを識別する１つ以上のキャラクタおよび／またはポンプのソフトウェア１つ以上のキャラクタを含み得る。ステップ４０４では、リモートモニタ／コントローラ２０は、全てのキャラクタが、例えば、改行キャラクタ＜ＬＦ＞に続くキャリッジリターンキャラクタ＜ＣＬ＞のような、１つ以上のターミネーションキャラクタを識別することによって受信されたことを決定し得る。
【００４８】
ステップ４０８は、正しいレスポンスがポンプ１２から受信されたかどうかを判定し、これは、可能性のあるＩＤコードのリストについて、ポンプ１２から受信されたキャラクタをチェックすることで判定され得る。正しいレスポンスが受信された場合、ルーティンは分岐して、ステップ４１０に進む。ステップ４１０では、例えば、受信されたポンプＩＤコードを少なくとも１つの可能性のあるＩＤコード（輸液ポンプの特定のタイプを識別する）と比較することによってか、あるいは、受信されたＩＤコードを可能性のある多くのＩＤコード（各コードは、輸液ポンプの特定のタイプを識別する）と比較することによって、ポンプのタイプが判定される。本明細書中で利用される場合、輸液ポンプの「タイプ」は、ポンプのモデルまたはポンプのソフトウェアバージョンに関連し得る。
【００４９】
ステップ４０８によって判定された場合に正しいレスポンスが受信されなかった場合、ステップ４１２では、タイマーによって計測されたルーティンが所定の期間が、ターミネーションキャラクタを受信する前に満了したかどうかを判定する。もし満了していた場合、ルーティンは分岐して、ステップ４１４に進み、ステップ４１４では、エラーメッセージが、ポンプの障害により生成され、ポンプＩＤ要求に応答する。
【００５０】
ステップ４１２では、いくつかのタイプのレスポンス（正しいレスポンスではない）が、タイマーが満了する前に受信された場合、ルーティンは分岐して、ステップ４１６に進む。ステップ４１６〜４２６は、リモートモニタ／コントローラ２０に接続される輸液ポンプ１２のタイプを判定する第２の方法を含み、これは、ポンプ１２のディスプレイ９２のキャラクタの数に基づく。例えば、輸液ポンプの第１のタイプは、１２個のキャラクタを表示することができるディスプレイを有し得るのに対し、輸液ポンプの第２のタイプは、３２個のキャラクタを表示することができるディスプレイを有し得る。ステップ４１６〜４２６は、ディスプレイのキャラクタの数に基づいて、輸液ポンプのタイプを判定する。
【００５１】
ステップ４１６では、リモートモニタ／コントローラ２０は、ポンプ表示要求を輸液ポンプ１２に送信して、ポンプ１２にそのディスプレイ９２のコンテンツを送信するように要求する。ステップ４１８では、リモートモニタ／コントローラ２０は、ポンプ１２から送信されたディスプレイキャラクタを読む。ステップ４２０では、所定の期間が満了したか、あるいは、終了キャラクタが受信された場合、ルーティンは分岐して、ステップ４２２に進む。ステップ４２２では、タイマーによって計測された所定の期間が、終了キャラクタの受信の前に経過した場合、ルーティンは分岐して、ステップ４２４に進む。ステップ４２４では、適切なエラーメッセージが生成される。ステップ４２６では、ポンプのタイプが、受信されたディスプレイキャラクタの数に基づいて決定される。
【００５２】
ルーティンはまた、所定の数のキャラクタが受信された場合、ステップ４２０を出ることができる。リモートモニタ／コントローラ２０が２つの異なるタイプの輸液ポンプとインターフェースをとるように設計されており、１つのポンプは１２個のキャラクタの表示性能を有し、もう一方のポンプは、３２個のキャラクタを表示性能を有する場合、ステップ４２０にてリモートモニタ／コントローラ２０が１２個より多い表示キャラクタを受信していると、そのポンプタイプが３２個の表示性能を有するポンプに対応していることを直ちに判定することができる。
【００５３】
リモートモニタ／コントローラ２０は、輸液ポンプ１２を制御すること、ポンプ１２の動作をモニタリングすること、ポンプ１２からリモートモニタ／コントローラ２０まで輸液データを送信すること、および、データを表示することを含む、４つの基本機能が実行されることを可能にする。ユーザは、リモートモニタ／コントローラ２０のディスプレイデバイス７８（図２）上に表示された動作モードを、マウス８２を介して選択することによって、これらの機能の１つを実行し得る。これらのモードは、リモートモニタ／コントローラ２０のヘルスケアの専門家がコマンド信号を輸液ポンプ１２に送信して、その動作を制御し得るコマンドモード、輸液ポンプ１２が継続的に可視ディスプレイ９２のコンテンツをリモートモニタ／コントローラ２０に送信するモニタリングモード、輸液データがポンプ１２からリモートモニタ／コントローラ２０まで送信されるダウンロードデータモード、および、輸液データがリモートモニタ／コントローラ２０のディスプレイ７８に表示され得る表示データモードを含む。
【００５４】
図１０は、リモートモニタ／コントローラ２０の基本動作のフローチャート４５０を示す。図１０を参照すると、ステップ４５２にて、ユーザが上述のコマンドモードを選択した場合、ルーティンは分岐して、ステップ４５４に進む。ステップ４５４では、輸液ポンプ１２のキーパッド９０のディスプレイが、ディスプレイデバイス７８に示される。ステップ４５４で示されるディスプレイは、リモートモニタ／コントローラ２０に接続された特定の輸液ポンプのタイプのキーパッド９０の入力キーと実質的に同一の、空間的構成を有する複数の可視入力キーを含む。このような可視ディスプレイの例は、図１１Ａに示される。
【００５５】
尚、図１１Ａに示される可視キーパッドは、図３に示される（ポンプ１２のオン／オフキーが可視キーディスプレイのリセットキーに置き換えられることを除き）ポンプ１２の実際のキーパッド９０と同一である。異なるキーパッドを有する異なるタイプのポンプがリモートモニタ／コントローラ２０に付加される場合、その特定のキーパッドは、ディスプレイデバイス７８に表示される。異なる可視キーパッドの例が、図１１Ｂに示される。様々な可視キーパッド構成が、リモートモニタ／コントローラ２０のメモリに格納され得、各可視キーパッド構成は、その構成に関連するポンプタイプコードを有する。リモートモニタ／コントローラ２０は、（図９のルーティンを介して）最初にリモートモニタ／コントローラ２０が付加されるポンプのタイプを決定するので、メモリおよびディスプレイからポンプのタイプの対応する可視キーパッドを取り出し得る。
【００５６】
可視キーパッドが表示された後、ヘルスケアの専門家は、いくつかの可視キーをマウス８２により選択することによって、輸液ポンプ１２の動作を制御し得る。タッチ感知スクリーンまたは放射線センサによって駆動される画面のような、キーを選択するほかの方法が利用され得る。輸液ポンプ１２は、キーパッド９０を介して入力されるコマンド、リモートモニタ／コントローラ２０から生成されるコマンドに応答する。ステップ４５６および４５８では、ヘルスケアの専門家によって入力された任意のコマンドが、輸液ポンプ１２に送信され、ステップ４６０および４６２において、ポンプ１２のディスプレイは、リモートモニタ／コントローラ２０に送信され、リモートモニタ／コントローラ２０のディスプレイデバイス７８上に表示される。ステップ４６４では、ユーザがコマンドモードを終了した場合、ルーティンは分岐して、ステップ４５２に戻る。
【００５７】
ステップ４６５では、ヘルスケアの専門家がモニタモードを選択した場合、ルーティンは分岐して、ステップ４６６に進み、ステップ４６６では、ポンプ表示９２の可視表示がディスプレイデバイス７８に示される。ステップ４６７では、ポンプ表示９２のコンテンツが、リモートモニタ／コントローラ２０に送信され、ステップ４６８では、これらのコンテンツは、ステップ４６６で生成された可視表示で表示される。ステップ４６９では、ユーザがモニタモードを終了した場合、ルーティンは分岐して、ステップ４５２に進む。そうでなければ、ルーティンは分岐して、ステップ４６７に戻り、ポンプ表示９２のコンテンツは、ステップ４６８にてディスプレイデバイス７８に連続的に示される（輸液ポンプ１２のディスプレイ９２は、ポンプ動作がディスプレイ９２を閲覧することによってモニタリングされ得るように、ポンプ動作にしたがって変化する）。ステップ４６７は、たとえば、ポンプ１２にポンプ表示要求を送信することによって（上述のステップ４１６〜４２０と同様のステップを介して）達成され得る。
【００５８】
ステップ４７０で判定される際に、ヘルスケアの専門家がポンプ１２からリモートモニタ／コントローラ２０までデータをダウンロードする要求を入力する場合、ルーティンは分岐して、ステップ４７２に進み、ステップ４７２では、図１３〜１４と関連させて以下に示されるように、データ送信が達成される。ユーザがステップ４７４にて判定される際に、閲覧データログ要求を入力する場合。ルーティンは分岐して、ステップ４７６に進み、ステップ４７６では、ステップ４７２で既にダウンロードされたデータが、リモートモニタ／コントローラ２０のディスプレイデバイス７８に表示され得る。ユーザは、ステップ４７８を介してモード選択ルーティン４５０を終了し得る。
【００５９】
図１２は、図１０に概略的に示される送信コマンドステップ４５８を実装するために利用され得る１つのルーティンを示す。図１２を参照すると、ポンプコマンドは、ステップ４８０にてリモートモニタ／コントローラ２０から送信され、その後、輸液ポンプ１２が、リモートモニタ／コントローラ２０にコマンドのエコーを送信し、それにより、リモートモニタ／コントローラ２０は、コマンドがポンプ２１によって適切に受信されたことを知る。エコーを作るキャラクタは、ステップ４８２、４８４によって受信され、エコーが正しくない場合、エラーメッセージが、ヘルスケアの専門家に対して表示される。ステップ４９０にて、リモートモニタ／コントローラ２０は、ポンプ１２にエコーの確認を送信する。
【００６０】
図１０のステップ４６８にて概略的に示される輸液ポンプ１２からリモートモニタ／コントローラ２０までのデータの送信は、輸液ポンプ１２によって実行される受信インタラプトサービスルーティン５００および送信インタラプトサービスルーティン５５０を介して達成される。ルーティン５００、５５０のフローチャートは、図１３および図１４に示される。
【００６１】
図１３に示される受信ルーティン５００は、ポンプコントローラ１００による受信インタラプトの発生時に呼び出される。受信インタラプトは、コントローラ１００の受信バッファ１１８で、リモートモニタ／コントローラ２０からのメッセージが受信されたことを示す。ダウンロードデータコマンドが輸液ポンプ１２に送信された場合（図１０のステップ４６６にて判定される場合に）、データダンプフラグが論理「１」に設定され、ポンプ１２からリモートモニタ／コントローラ２０へのデータ送信またはダンプが進行中であることを示す。データ送信は、セグメント化される様式で実行される。ＲＡＭ１０４から格納される全ての輸液データおよび患者データを、１つの連続ストリームでリモートモニタ／コントローラ２０に送信するのではなく、データは、セグメント化された複数の部分として送信され、各部分は、例えば１００マイクロ秒の期間で、隣接する部分から時間で分離される。
【００６２】
図１３を参照すると、ルーティンがステップ５０２で開始するとき、キャラクタまたはメッセージは、受信バッファ１１８でちょうど受信されている。ステップ５０２では、データダンプフラグがアクティブであり、データ送信が既に進行中であることを意味する場合、ルーティンは分岐して、ステップ５０４に進み、ステップ５０４では、データダンプフラグは、ロジック「０」に設定され、データダンプ動作を効果的に送信し、ステップ５０６にて、リモートモニタ／コントローラ２０にエラーメッセージが送信される。これは、データダンプ動作がリモートモニタ／コントローラ２０から輸液ポンプ１２まで送信される任意のコマンドと干渉することを防ぐためになされる。
【００６３】
データダンプフラグがステップ５０２にて判定される場合にアクティブでない場合、ルーティンは分岐して、ステップ５０８に進む。ステップ５０８では、受信バッファ１１８でちょうど受信されたメッセージは、このメッセージがデータダンプコマンドであるかどうかを判定するためにチェックされる。もし、データダンプコマンドでなければ、ルーティンは分岐して、ステップ５１０に進み、ステップ５１０にて、ポンプ１２は、コマンドに応答する。
【００６４】
メッセージがデータコマンドであれば、ルーティンは分岐して、ステップ５１２に進み、ステップ５１２では、送信ポインタ５１３（図７を参照）は、リモートモニタ／コントローラ２０にまだ送信されていないＲＡＭ１０４の最も古いデータに設定される。ステップ５１４にて、新しいデータ送信動作が開始した後、データダンプフラグが論理「１」に設定される。ステップ５１６にて、送信ポインタ５１３によって指定されるデータバイトが、ＲＡＭ１０４から取り出され、ステップ５１８にて、送信ポインタ５１３の位置が送信された次のデータバイトのアドレスにポイントされるように更新される（例えば、インクリメントされる）。ステップ５２０にて、ステップ５１６で取り出されたデータバイトは、ＡＳＣＩＩでフォーマットされ、ステップ５２２にて、送信インタラプトがイネーブルされ、ステップ５２４にて、再フォーマットされたデータバイトが、輸液ポンプ送信バッファ１１６からリモートモニタ／コントローラ２０までデータリンク３８を介して送信される。
【００６５】
第１のデータバイトが送信バッファ１１６から送信されつくした場合、送信インタラプトがコントローラ１００によって生成され、送信バッファ１１６がエンプティであり、別のデータバイトが送信され得ることを示す。送信インタラプトが生成すると、送信ルーティン５５０が実行される。図１４を参照すると、ステップ５５２にて、データダンプフラグのステータスがチェックされる。フラグがアクティブでなく、データダンプ動作が進行中でないことを意味する場合、ルーティンは分岐して、ステップ５５４に進み、ステップ５５４では、ルーティンは他のインタラプトに応答する。データダンプフラグがアクティブである場合、ルーティンは分岐して、ステップ５５６に進み、ステップ５５６にて、このルーティンは、全てのセグメント化された輸液データの部分が送信されたかどうかを判定する。これは、例えば、送信ポインタ５１３およびポインタ３７６（図７）が同一のメモリ位置をポイントしているかどうかを判定することによって達成され得る。全ての要求されたデータが送信された場合、ルーティンは分岐して、ステップ５５８に進み、送信インタラプトがディゼーブルされ、その後、ステップ５６０に進み、ステップ５６０にて、データダンプフラグが論理「０」にリセットされ、データ送信動作が効果的に終了する。
【００６６】
ステップ５５６で判定される場合に、全てのデータが送信されていなかった場合、ルーティンは分岐してステップ５６２に進み、ステップ５６２にて、送信ポインタ５１３によって指定されるデータバイトが、ＲＡＭ１０４から取り出される。ステップ５６４にて、送信ポインタの位置が、送信される次のデータバイトのアドレスをポイントするように更新される。ステップ５６６にて、ステップ５６２で取り出されたデータバイトは、ＡＳＣＩＩでフォーマットされ、ステップ５６８にて、再フォーマットされたデータバイトは、輸液ポンプ送信バッファ１１６からリモートモニタ／コントローラ２０にデータリンク３８を介して送信される。
【００６７】
セグメント化されたデータ部分をリモートモニタ／コントローラ２０に送信さするようにコントローラ１００によって生成された送信インタラプトは、シャフトエンコーダセンサ１３０の入力に応答して生成されるインタラプトよりも低いプライオリティを割り当てられる。シャフトエンコーダセンサ１３０は、所望の輸液速度を提供するために必要となる。結果的に、輸液データおよび患者データの送信は、ポンプ１２の所望の輸液速度を提供する能力とインターフェースを取らず、データ送信は、ポンプが患者に薬を注入している間に生じ得る。
【００６８】
図１５は、リモートモニタ／コントローラ２０のディスプレイデバイス７８に示され得るグラフィカルユーザメニューの図である。ヘルスケアの専門家は、開始日時、終了日時、データのタイプ等の多くの様々なパラメータを介して、送信または閲覧する特定のデータを選択し得る。送信または閲覧するために特定のデータが選択され得る特定の耐容は、本発明にとって重要であるとは考えられない。
【００６９】
さらに、図１６〜２４は、特定の患者の状態および／または特定の患者の環境の変化に基づいて医療処置を配当するために医療処置配信制御を利用する医療処置管理システム６１０を示す。図１６に示されるように、医療処置管理システム６１０の１つの実施形態は、輸液ポンプ１２で有り得る医療デバイス６１２、医療デバイス６１２に接続された制御アルゴリズム６２６、および患者６１８に接続されたセンサ６１６を備える。医療デバイス６１２は、輸液ポンプ、人工呼吸器、インシュリン配信デバイス、および麻酔配信デバイスを備えるがこれらに制限されない様々なデバイスの１つであってもよいが、当業者であれば、他の医療デバイスが本発明の範囲から逸脱することなく利用され得ることを理解し得る。さらに、医療デバイス６１２は、上述のようにプログラム可能であり得、さらに当業者によって理解される。
【００７０】
１つの実施形態では、図３に示される輸液ポンプ１２は、患者６１８への液体薬（ｌｉｑｕｉｄ ｍｅｄｉｃａｎｔ）を管理する医療デバイス６１２として利用される。通常、医療デバイス６１２は、薬剤の供給（示されない）および患者６１８への薬剤を配信する手段（示されない）を有する。輸液ポンプ１２により、薬剤の供給は、通常、注射器またはＩＶタイプバックに含まれる液体薬である。さらに、輸液ポンプ１２により、薬剤を配信する手段は、液体輸液デバイスを備え、多くの場合、患者に接続されることに適合する中空針またはカテーテル、液体輸液デバイスに接続されるコンジットまたはチューブ、液体輸液デバイスによりコンジットを介して患者に液体薬をポンピングするポンピングメカニズム、ならびに、ポンピングメカニズムを制御するコントローラを備える。しかし、他のタイプの医療デバイスが利用される場合、医療処置および処置を配信する手段は、特定の医療デバイスに一致するように変化する。例えば、それぞれ適切な配信手段により、人工呼吸器は、患者に酸素を供給し、インシュリン配信メカニズムは、患者にインシュリンを配信し、麻酔デバイスは、麻酔ガスまたは麻酔薬を患者に提供する。
【００７１】
図１６に示される実施形態では、センサ６１６は、患者６１８に接続され、患者６１８の生理学的状態に関する情報を患者６１８から受信する。当業者には理解されるように、このような生理学的状態は、患者の心拍、患者の体温、患者の血圧、患者の活動レベル、患者の細胞の代謝、患者の細胞の増殖、患者の代謝要求、患者の食物摂取量、および患者のＳｐＯ２レベル等を含むが、これらに制限されない。これらのファクタおよび当業者に知られた他のファクタは、医療処置、および、特に薬物療法を病状の治療中の個人に配当するためのトリガーとなる出来事であると理解される。さらに、センシングデバイスは、手動の入力を受信する入力デバイスを備え得る。手動の入力は、ヘルスケア提供者または患者によって提供され得る。センシングデバイスに入力を提供する患者の例は、医療デバイス１２がインシュリン配信メカニズムである場合である。このように、患者は、患者によって消費される食べ物のタイプを示す入力をセンサに提供し得る。
【００７２】
１つの実施形態では、複数のセンサ６１６は、患者の特定の物理パラメータを継続的にモニタする携帯用多パラメータの生理学的モニタ（図示されず）に含まれる。モニタは、ＥＫＧ電極、胸部拡張センサ、加速度計、胸部マイクロフォン、バイオメトリック圧力センサ、体温センサ、および周囲温度センサを含む、センサ６１６を有する。各センサは、アナログデジタル変換器（ＡＤＣ）に出力信号を提供する。
【００７３】
このような実施形態では、センサ６１６は、身体ストラップ（図示されない）に設けられ得、身体ストラップは、上部に様々なセンサおよびサポーティング電子機器が配当される胸部ストラップを含み得る。（さらに、多パラメータモニタリングデバイスが、胸部以外の身体の一部分のまわりにストラップによってマウントされ得ることが当業者に理解される。）胸部ストラップは、患者６１８の胴のまわりに適合するように適合される。
【００７４】
様々なパラメータセンサ６１６は、センサが検出するパラメータ（単数または複数）に最も適したストラップに配置される。各センサ６１６は、信号処理の分野では公知であるように、センサ信号をフィルタリングおよび増幅するアナログ回路に電気的入力を提供し、コントローラハードウェアの一部分であり得るアナログデジタル変換器にそれらのセンサ信号を出力する。ストラップのセンサは、以下のようであり得る。患者の胸部の表面の温度を感知する胸の温度センサ、患者の環境の周囲のバイオメトリック圧を感知するバイオメトリック圧力センサ、患者の胸部の拡張および収縮を示す胸部ストラップの伸張を検出する胸部拡張（人工呼吸）センサ、患者の身体の運動および傾きを検出する加速度計、患者の環境の周囲温度を感知する周囲温度センサ、患者の胴内からの音を検出するマイクロフォン、腕の下の患者の胴の側面の温度を感知する脇の下温度センサ、ならびに心筋のアクションによって生じる電気信号を検出するＥＫＧ電極である。ＥＫＧ電極は、グランドまたは基準電極と組み合わせて利用され、患者の胸部の肌に接触して配置され、患者の心筋のポンピングアクションによって発生する電気信号を検出する。ＥＫＧ（電極心電図）が、医学分野で周知である、患者の心臓の動きを示す。
【００７５】
さらに図１６に示されるように、センサ６１７は、センサ６１６に加えて、または、センサ６１６の代わりに提供され得る。センサ６１７は、患者６１８の環境に関する情報を取得する。通常、センサ６１６、６１７は、患者６１８のからの介入なく、自動的に患者の生理学的状態および／または環境条件のそれぞれに関する信号を取得する。制御アルゴリズム６２６によって必要とされる情報に基づいて、複数のセンサ６１６、６１７は、直列または並列に利用され得る（図１６、１９、２２、および２３）。
【００７６】
センサ６１６、６１７は、個人の心拍、体温、血圧、活動レベル、細胞の代謝、細胞の増殖、代謝要求、ＳｐＯ２レベル等に関するか、あるいは、周囲温度、周囲の光条件等の環境条件６１７に基づく信号のような信号を受信することができる任意のデバイスであり得る。図４および５に示されるように、このようなセンサ６１６、６１７は、バイタルサインモニタ、血圧モニタ、光センサ、環境センサ、および活動センサを含み得るがこれらに限定されない。さらに、図６に示されるように、別個のコンポーネントではなく、センサ１６、１７は、コントローラ２８と統合されてもよい。
【００７７】
センサ６１６、６１７から受信した信号は、制御アルゴリズム６２６に電気的に送信される６２４。図１７、１８、および２１に示されるように、制御アルゴリズム６２６は、コントローラ６２８（プロセッサとも呼ばれる）の一部であってもよい。さらに、図１８に示されるように、コントローラ６２８は、医療デバイス６１２のコンポーネントであってもよい。患者６１８に対して管理される特定の医療処置に応じて、制御アルゴリズム６２６は、１つ以上のセンサ６１６、６１７から信号を要求し得る。患者の休息活動または代謝サイクルが、コルチゾール、肝酵素、およびクレアチンの血液細胞数、血漿、または血清濃度を含む様々な要素を計測することによって、観血的に判定され得ることが理解される一方で、他の方法もまた利用可能である。例えば、患者の休息活動または代謝サイクルは、患者のバイタルサインまたは活動によって非観血的に計測され得る。さらに、患者の体温が夜間に低下し、患者の心拍は、患者が休息しているときに低下することが発見された。したがって、このような信号は、センサ６１６、６１７によって取得され、このような情報は、処理のための制御アルゴリズム６２６に送信される６２４。
【００７８】
制御アルゴリズム６２６が異なる医療処置ごとにおそらく異なることが理解され、さらに、同一の医療処置に対しても、制御アルゴリズム６２６が異なる患者では異なり得ることも理解される。制御アルゴリズム６２６の１つの例が、図２４に示される。図２４に示されるように、制御アルゴリズム６２６は、患者６１８の心拍の関数として、患者への薬剤の配信を制御するために利用され得る。この実施形態では、制御アルゴリズム６２６は、患者の心拍の信号をセンサ６１６の１つから受信する。制御アルゴリズム６２６は、最大心拍と信号を比較することによって、信号６３０を処理する。心拍信号が最大心拍信号よりも小さい場合に、制御アルゴリズムは、フィードバック制御６３２を展開（ｄｅｖｅｌｏｐ）して、輸液ポンプ１２の輸液の速度を２％まで低下させる。心拍信号が最大心拍信号よりも小さくない場合に、制御アルゴリズムは、さらに、輸液療法が完了したかどうかを判定する。輸液療法が完了していない場合、輸液を続けるための、フィードバック制御６３２が提供される。心拍信号のさらなる処理６３０がその後も継続される。輸液療法が完了していた場合、輸液ポンプ１２を停止するための、フィードバック制御６３２が提供される。
【００７９】
制御アルゴリズム６２６が送信された信号６２４を受信した後、この制御アルゴリズム２６は、制御アルゴリズム６２６を介して信号を処理し６３０、結果として生じるフィードバック制御６３２が展開される。複数の信号が複数のセンサ６１６、６１７から要求され、かつ、受信された場合に、各必要とされる信号は、プログラムされる制御アルゴリズム６２６によって処理され、結果として生じるフィードバック制御６３２が展開される。フィードバック制御６３２は、医療デバイス６１０の制御信号として動作して、患者６１８への医療処置の配信を制御または調整する。
【００８０】
これは、医療デバイス６１０に、制御アルゴリズム６２６によって展開されたフィードバック制御６３２を送信する６３４ことによって達成される。フィードバック制御６３２は、医療デバイス６１０の動作にコマンドを提供する。フィードバック制御６３２は、通常、医療デバイス６１０の信号またはコマンドの２つのうちの１つを提供する。すなわち、患者６１８に医療処置を配信する６３６か、または、患者に医療処置を配信しない６３８かのどちらかである。フィードバック制御６３２は、医療処置を配信する６３６ために信号を提供する場合、患者６１８に提供する処置の量および速度を指示する医療デバイス６１２に信号を提供し得る。このような信号は、薬剤配信の速度を増加または減少させることを含み得る。
【００８１】
図２２に示されるように、複数の医療デバイス６１２ａ、６１２ｂは、患者６１８に医療処置を配信する６３６ために利用され得る。特定の医療治療は同じであってもよく、異なるように単に服用されてもよく、あるいは、各医療デバイス６１２ａ、６１２ｂは、患者６１８に異なる医療処置を配信６３６してもよい。さらに、図２２に示されるように、それぞれ医療デバイス６１２ａ、６１２ｂごとに、別個の制御アルゴリズム６２６ａ、６２６ｂが利用され得る。図７の実施形態は、２つの別個の制御アルゴリズム６２６ａ、６２６ｂ、および多くのセンサ６１６ａ、６１６ｂ、および６１７を利用する。センサ６１６ａ、６１７は、制御アルゴリズム６２６ａに信号を送信６２４し、制御アルゴリズム６２６ａは、患者６１８に配信される６３６処置に応じて、センサ６１６ａ、６１７の一方または両方からの信号を処理し６３０、結果として生じるフィードバック制御６３２ａを展開し得る。センサ６１６ｂは、信号を制御アルゴリズム６２６ｂに送信し、制御アルゴリズム６２６ｂは、同様に信号を処理して６３０、結果として生じるフィードバック制御６３２ｂを展開する。フィードバック制御６３２ａが第１の医療デバイス６１２ａに送信され、患者６１８への医療処置の配信６３６ａを制御しつつ、フィードバック制御６３２ｂが第２の医療デバイス６１２ｂに送信され、同じ患者６１８に医療処置の配信６３６ｂを制御する。
【００８２】
逆に、図２３に示されるように、１つの制御アルゴリズム６２６は、複数の医療デバイス６１２ａ、６１２ｂを制御し得る。この実施形態では、１つの制御アルゴリズム６２６は、複数のセンサ６１６ａ、６１６ｂ、および６１７により利用され得る。センサ６１６ａ、６１６ｂ、および６１７は、制御アルゴリズム６２６に信号を送信６２４し、制御アルゴリズム６２６は、患者６１８に配信される６３６処置に応じて、１つ以上のセンサ６１６ａ、６１６ｂ、および６１７からの信号を処理し６３０、結果として生じる１つ以上のフィードバック制御６３２ａ、６３２ｂを展開し得る。フィードバック制御６３２ａが第１の医療デバイス６１２ａに送信され、患者６１８への医療処置の配信６３６ａを制御しつつ、フィードバック制御３２ｂが第２の医療デバイス１２ｂに送信され、同じ患者６１８への医療処置の配信６３６ｂを制御する。したがって、この実施形態では、第１の医療デバイス６１２ａの制御アルゴリズムは、第２の医療デバイス６１２ｂと同じ制御アルゴリズム６２６である。
【００８３】
医療処置装置６１０は、異なる処置療法により利用され得るので、制御アルゴリズム６２６は、通常、異なる処置療法ごとに改変または変更される。したがって、図１６および図１７に示されるように、通常、入力デバイス６４２が提供され、制御アルゴリズム６２６の制御パラメータ６４４を調節および設定し得る。入力デバイス６４２は、コントローラ６２８に接続されてもよいし、直接的に制御アルゴリズム６２６に接続されてもよい。制御アルゴリズム６２６は、手動で入力されてもよく、一方で、さらに、データベースまたはネットワークから動的にダウンロードされてもよい。
【００８４】
さらに、図１６に示されるように、医療デバイス６１２はまた、医療デバイス６１２用の入力デバイス６４８を有し得る。医療デバイス１２用の入力デバイス６４８は、ユーザ（通常は認可された臨床医）が制御コマンド６５０を入力して、医療デバイス６１２のパラメータを調節または制御することを可能にする。別の実施形態では、医療デバイス６１２用の入力デバイスは、コントローラ／制御アルゴリズム用の入力デバイスと同じである。
【００８５】
図１７に示されるように、制御アルゴリズム６２６および／またはコントローラ６２８の制御パラメータをリモートで調節または設定するために、リモートコントローラ６４６（すなわち、リモート入力デバイス）が提供され得る。本発明の譲受人に譲渡された米国特許第５，８８５，２４５号は、リモートコントローラを開示し、特に本明細書中で参照として援用され、本発明の一部をなす。リモートコントローラ６４６は、医療デバイス６１２が配置される（すなわち第１の位置）部屋の位置から離れた部屋の位置（すなわち、第２の位置）に配置される。リモートコントローラ６４６は、医療デバイス６１２が配置される建物と同じ建物の異なる部屋に配置されて得、または、医療デバイス６１２が配置される建物とは異なる建物に配置され得る。リモートコントローラ６４６は、データリンク６５４を介して従来の音声／データモデム６５２に接続され、モデム６５２はまた、音声リンク６５８を介して電話６５６に接続される。医療デバイス６１２は、データリンク６６２を介して従来の音声／データモデム６６０に接続され、モデム６６０は、音声リンク６６６を介して電話６６４に接続される。２つのモデム６５２、６６０は、通信リンク６６８を介して双方向性音声およびデータ通信に相互接続され、通信リンク６６８は、例えば、電話線であり得る。さらに、リモートコントローラ６４６は、インターネット、イントラネット、およびワイヤレスネットワークを介して、制御アルゴリズム６２６と通信し得る。さらに、リモートコントローラ６２６は、サーバであってもよい。
【００８６】
特定の実施形態が説明され、かつ記載されたが、多くの改変が本発明の意図から著しく逸脱することなく想定され、保護の範囲は、添付の請求項の範囲によってのみ制限される。
【図面の簡単な説明】
【００８７】
【図１】図１は、患者に対する医療処置を管理し、患者の状態をモニタする装置のブロック図である。
【図２】図２は、図１に概略的に示されるリモートモニタ／コントローラの電子機器コンポーネントのブロック図である。
【図３】図３は、図１に概略的に示される輸液ポンプの１つの実施形態の前面図である。
【図４】図４は、図３の輸液ポンプの電子機器コンポーネントのブロック図である。
【図５】図５は、輸液ポンプの動作全体のフローチャートである。
【図６】図６は、輸液ポンプの動作中に実行される多数のデータ記録ステップを示す。
【図７】図７は、輸液ポンプのメモリの一部を示す。
【図８】図８は、輸液ポンプの動作に関するデータおよび患者の状態に関するデータを格納するために利用され得る格納データルーティンのフローチャートである。
【図９】図９は、リモートモニタ／コントローラが接続される輸液ポンプの型を識別するために利用され得るルーティンのフローチャートである。
【図１０】図１０は、リモートモニタ／コントローラのモード選択ルーティンのフローチャートである。
【図１１Ａ】図１１Ａは、リモートモニタ／コントローラによって生成される可視表示の一部を示す。
【図１１Ｂ】図１１Ｂは、リモートモニタ／コントローラによって生成される可視表示の一部を示す。
【図１２】図１２は、リモートモニタ／コントローラによって実行されるコマンドポンプルーティンのフローチャートである。
【図１３】図１３は、輸液ポンプによって実行される受信ルーティンのフローチャートである。
【図１４】図１４は、輸液ポンプによって実行される送信ルーティンのフローチャートである。
【図１５】図１５は、リモートモニタ／コントローラによって表示され得るグラフィカルユーザメニューの図である。
【図１６】図１６は、本発明の医療処置管理システムのブロック図である。
【図１７】図１７は、リモート制御を含む、図１６の医療処置管理システムの変形のブロック図である。
【図１８】図１８は、コントローラが医療デバイスのコンポーネントである、図１６の医療処置管理システムの別の変形のブロック図である。
【図１９】図１９は、さまざまなセンシングデバイスを含む、図１６の医療処置管理システムの別の変形のブロック図である。
【図２０】図２０は、さまざまなセンシングデバイスを含む、図１６の医療処置管理システムの別の変形のブロック図である。
【図２１】図２１は、コントローラおよびセンシングデバイスが統合コンポーネントである、図１６の医療処置管理システムの別の変形のブロック図である。
【図２２】図２２は、複数の医療処置デバイスを含む、図１６の医療処置管理システムの別の変形のブロック図である。
【図２３】図２３は、複数の医療処置デバイス用のプロセッサを含む、図２２の医療処置管理システムの別の変形のブロック図である。
【図２４】図２４は、１つのタイプの本発明の制御アルゴリズムのブロック図である。
【特許請求の範囲】
【請求項１】
リモート制御された医療配信システムであって、
医療の供給および患者に薬剤を配信する手段を有する医療処置デバイスであって、第１の位置に配置される、医療処置デバイスと、
該医療デバイスに接続される制御アルゴリズムと、
該制御アルゴリズムに接続されるセンシングデバイスであって、該センシングデバイスは、該制御アルゴリズムに信号を送信し、該制御アルゴリズムは、該センシングデバイスから取り出された信号を処理し、該信号の処理の結果に基づいてフィードバック制御を展開して、該薬剤が該医療処置デバイスから該患者に配信されるべきかどうかを判定し、該センシングデバイスは、該医療処置デバイスに該フィードバック制御を提供して、該患者への該医療処置の配信を制御する、センシングデバイスと
を備える、システム。
【請求項２】
リモートコントローラが、インターネットを介して前記制御アルゴリズムと通信する、請求項１に記載のリモート制御された医療配信システム。
【請求項３】
リモートコントローラが、イントラネットを介して前記制御アルゴリズムと通信する、請求項１に記載のリモート制御された医療配信システム。
【請求項４】
リモートコントローラが、ワイヤレスネットワークを介して前記制御アルゴリズムと通信する、請求項１に記載のリモート制御された医療配信システム。
【請求項５】
リモートコントローラが、サーバである、請求項１に記載のリモート制御された医療配信システム。
【請求項６】
前記医療処置デバイスは、前記患者への液体薬を管理する輸液ポンプであって、該患者に接続されることに適合した液体注入デバイスを有する輸液ポンプと、該液体注入デバイスに接続されたコンジットと、該コンジットを介して患者へと該液体注入デバイスにより該液体薬をポンピングするポンピングメカニズムと、該ポンピングメカニズムを制御するポンプコントローラであって、該患者への該医療処置の配信を制御するために、該医療処置デバイスへの前記フィードバック制御を受信する、ポンプコントローラとを備える、請求項１に記載のリモート制御された医療配信システム。
【請求項７】
前記センシングデバイスは、前記患者の生理学的状態に関する該患者からの情報を受信するように該患者に接続されるセンサを備え、該情報は、信号に変換される、請求項１に記載のリモート制御された医療配信システム。
【請求項８】
前記センサは、バイタルサインモニタである、請求項７に記載のリモート制御された医療配信システム。
【請求項９】
前記センシングデバイスは、前記患者の環境に関する情報を受信するセンサを備える、請求項１に記載のリモート制御された医療配信システム。
【請求項１０】
前記センサは、光センサである、請求項９に記載のリモート制御された医療配信システム。
【請求項１１】
前記制御アルゴリズムに接続されるローカル入力デバイスであって、前記第１の位置に配置される、ローカル入力デバイス
をさらに備える、請求項１に記載のリモート制御された医療配信システム。
【請求項１２】
前記ローカル入力デバイスは、複数の空間的構成で配置されるエントリキーを有し、リモートコントローラは、ディスプレイを有し、前記医療配信システムは、前記ローカル入力デバイスのエントリキーと実質的に同一の空間的構成を有する複数の仮想エントリキーの可視表示を生成する、該ディスプレイに動作するように接続される手段をさらに備える、請求項１１に記載のリモート制御された医療配信システム。
【請求項１３】
医療処置を配信することができる医療デバイスから患者へと医療処置を配信するリモート制御された医療配信システムであって、
信号を受信するセンサと、該センサに動作可能なように接続される制御アルゴリズムと、該センサから離れた位置に配置されるリモート入力デバイスとを備え、該センサは、該信号を取得し、該制御アルゴリズムは、該センサによって取得される該信号を処理し、該医療デバイスから該患者への該医療処置の配信を制御することに適合するフィードバック制御を展開し、該リモート入力デバイスは、該制御アルゴリズムの動作を操作する手段を有する、システム。
【請求項１４】
医療処置の供給および該医療処置を該患者に配信する手段を有する医療デバイスをさらに備え、該医療デバイスは、該制御アルゴリズムに動作可能なように接続され、該制御アルゴリズムは、該医療デバイスから該患者への該医療処置の配信を制御する、請求項１３に記載の医療配信システム。
【請求項１５】
前記制御アルゴリズムに動作可能なように接続されるローカル入力でバスをさらに備え、該ローカル入力デバイスは、該制御アルゴリズムのプロセスパラメータを制御する、請求項１３に記載の医療配信システム。
【請求項１６】
前記リモート入力デバイスに接続されるディスプレイをさらに備え、該ディスプレイは、該制御アルゴリズムの可視的読み出しを提供する、請求項１３に記載の医療配信システム。
【請求項１７】
前記センサは、前記患者に動作可能なように接続され、該患者の生理学的状態に関する情報を受信する、請求項１３に記載の医療配信システム。
【請求項１８】
医療配信システムであって、
患者への医療処置を管理する第１の位置に配置されるプログラム可能医療デバイスであって、該プログラム可能医療デバイスは、該患者への該医療処置を管理する手段を有し、該プログラム可能医療デバイスは、該プログラム可能医療デイバスの制御コマンドを入力する第１の入力デバイスを有する、プログラム可能医療デバイスと、
該プログラム可能医療デバイスに動作可能なように接続されるローカルコントローラであって、該ローカルコントローラは、該第１の位置に配置され、該ローカルコントローラの制御コマンドを入力する第２の入力デバイスを有し、該ローカルコントローラは、該患者から信号を受信するように該患者に動作可能なようにさらに接続され、該ローカルコントローラは、該プログラム可能医療デバイスの動作を操作する、ローカルコントローラと、
該ローカルコントローラを制御するリモートコントローラであって、該リモートコントローラは、該プログラム可能デバイスが配置される第１の位置から離れた第の位置に配置され、該リモートコントローラは、該第２の位置のユーザが該ローカルコントローラを制御することを可能にする手段を有する、リモートコントローラと
を備える、システム。
【請求項１９】
前記第２の入力デバイスは、バーコードリーダである、請求項１８に記載の医療配信システム。
【請求項２０】
患者の情報および医療データは、前記第２の入力デイバスを介して入力される、請求項１８に記載の医療配信システム。
【請求項２１】
ディスプレイデバイスと、前記プログラム可能医療デバイスの前記入力デバイスに実質的に対応する仮想入力デバイスの可視表示を生成する表示手段であって、該ディスプレイデバイスに動作可能な用に接続される、表示手段と、前記第２の位置のユーザが該可視入力デバイスを起動して、該ユーザが該第２の位置から前記プログラム可能医療デバイスの動作を制御することを可能にする手段と
をさらに備える、請求項１８に記載の医療装置。
【請求項２２】
患者に薬剤を提供する方法であって、該薬剤配信は、該患者の１つ以上の生理学的状態によってトリガーされ、該方法は、
薬剤配信デバイスを提供するステップと、
制御アルゴリズムを有するローカルコントローラを提供するステップと、
センサを提供するステップと、
リモートコントローラを提供するステップであって、該リモートコントローラは、入力デバイスを有する、ステップと、
該患者の該生理学的状態に関する信号を取得するセンサを利用し、該信号を該コントローラに送信し、該信号に含まれる情報を該制御アルゴリズムに入力し、該制御アルゴリズムからの結果のデータに基づいて結果を展開し、該制御アルゴリズムからの結果に基づいてフィードバック制御を展開し、かつ、該患者に該薬剤を配信するために、該フィードバック制御に基づいて適切な薬剤配信デバイスを操作するステップと
を包含する、方法。
【請求項２３】
患者に薬剤を提供する方法であって、該薬剤配信は、１つ以上の環境条件によってトリガーされ、該方法は、
薬剤配信デバイスを提供するステップと、
制御アルゴリズムを有するローカルコントローラを提供するステップと、
センサを提供するステップと、
リモートコントローラを提供するステップであって、該リモートコントローラは、入力デバイスを有する、ステップと、
該患者の環境の該環境条件に関する信号を取得するセンサを利用し、該信号を該コントローラに送信し、該信号に含まれる情報を該制御アルゴリズムに入力し、該制御アルゴリズムからの結果のデータに基づいて結果を展開し、該制御アルゴリズムからの結果に基づいてフィードバック制御を展開し、かつ、該患者に該薬剤を配信するために、該フィードバック制御に基づいて適切な薬剤配信デバイスを操作するステップと
を包含する、方法。
【請求項１】
リモート制御された医療配信システムであって、
医療の供給および患者に薬剤を配信する手段を有する医療処置デバイスであって、第１の位置に配置される、医療処置デバイスと、
該医療デバイスに接続される制御アルゴリズムと、
該制御アルゴリズムに接続されるセンシングデバイスであって、該センシングデバイスは、該制御アルゴリズムに信号を送信し、該制御アルゴリズムは、該センシングデバイスから取り出された信号を処理し、該信号の処理の結果に基づいてフィードバック制御を展開して、該薬剤が該医療処置デバイスから該患者に配信されるべきかどうかを判定し、該センシングデバイスは、該医療処置デバイスに該フィードバック制御を提供して、該患者への該医療処置の配信を制御する、センシングデバイスと
を備える、システム。
【請求項２】
リモートコントローラが、インターネットを介して前記制御アルゴリズムと通信する、請求項１に記載のリモート制御された医療配信システム。
【請求項３】
リモートコントローラが、イントラネットを介して前記制御アルゴリズムと通信する、請求項１に記載のリモート制御された医療配信システム。
【請求項４】
リモートコントローラが、ワイヤレスネットワークを介して前記制御アルゴリズムと通信する、請求項１に記載のリモート制御された医療配信システム。
【請求項５】
リモートコントローラが、サーバである、請求項１に記載のリモート制御された医療配信システム。
【請求項６】
前記医療処置デバイスは、前記患者への液体薬を管理する輸液ポンプであって、該患者に接続されることに適合した液体注入デバイスを有する輸液ポンプと、該液体注入デバイスに接続されたコンジットと、該コンジットを介して患者へと該液体注入デバイスにより該液体薬をポンピングするポンピングメカニズムと、該ポンピングメカニズムを制御するポンプコントローラであって、該患者への該医療処置の配信を制御するために、該医療処置デバイスへの前記フィードバック制御を受信する、ポンプコントローラとを備える、請求項１に記載のリモート制御された医療配信システム。
【請求項７】
前記センシングデバイスは、前記患者の生理学的状態に関する該患者からの情報を受信するように該患者に接続されるセンサを備え、該情報は、信号に変換される、請求項１に記載のリモート制御された医療配信システム。
【請求項８】
前記センサは、バイタルサインモニタである、請求項７に記載のリモート制御された医療配信システム。
【請求項９】
前記センシングデバイスは、前記患者の環境に関する情報を受信するセンサを備える、請求項１に記載のリモート制御された医療配信システム。
【請求項１０】
前記センサは、光センサである、請求項９に記載のリモート制御された医療配信システム。
【請求項１１】
前記制御アルゴリズムに接続されるローカル入力デバイスであって、前記第１の位置に配置される、ローカル入力デバイス
をさらに備える、請求項１に記載のリモート制御された医療配信システム。
【請求項１２】
前記ローカル入力デバイスは、複数の空間的構成で配置されるエントリキーを有し、リモートコントローラは、ディスプレイを有し、前記医療配信システムは、前記ローカル入力デバイスのエントリキーと実質的に同一の空間的構成を有する複数の仮想エントリキーの可視表示を生成する、該ディスプレイに動作するように接続される手段をさらに備える、請求項１１に記載のリモート制御された医療配信システム。
【請求項１３】
医療処置を配信することができる医療デバイスから患者へと医療処置を配信するリモート制御された医療配信システムであって、
信号を受信するセンサと、該センサに動作可能なように接続される制御アルゴリズムと、該センサから離れた位置に配置されるリモート入力デバイスとを備え、該センサは、該信号を取得し、該制御アルゴリズムは、該センサによって取得される該信号を処理し、該医療デバイスから該患者への該医療処置の配信を制御することに適合するフィードバック制御を展開し、該リモート入力デバイスは、該制御アルゴリズムの動作を操作する手段を有する、システム。
【請求項１４】
医療処置の供給および該医療処置を該患者に配信する手段を有する医療デバイスをさらに備え、該医療デバイスは、該制御アルゴリズムに動作可能なように接続され、該制御アルゴリズムは、該医療デバイスから該患者への該医療処置の配信を制御する、請求項１３に記載の医療配信システム。
【請求項１５】
前記制御アルゴリズムに動作可能なように接続されるローカル入力でバスをさらに備え、該ローカル入力デバイスは、該制御アルゴリズムのプロセスパラメータを制御する、請求項１３に記載の医療配信システム。
【請求項１６】
前記リモート入力デバイスに接続されるディスプレイをさらに備え、該ディスプレイは、該制御アルゴリズムの可視的読み出しを提供する、請求項１３に記載の医療配信システム。
【請求項１７】
前記センサは、前記患者に動作可能なように接続され、該患者の生理学的状態に関する情報を受信する、請求項１３に記載の医療配信システム。
【請求項１８】
医療配信システムであって、
患者への医療処置を管理する第１の位置に配置されるプログラム可能医療デバイスであって、該プログラム可能医療デバイスは、該患者への該医療処置を管理する手段を有し、該プログラム可能医療デバイスは、該プログラム可能医療デイバスの制御コマンドを入力する第１の入力デバイスを有する、プログラム可能医療デバイスと、
該プログラム可能医療デバイスに動作可能なように接続されるローカルコントローラであって、該ローカルコントローラは、該第１の位置に配置され、該ローカルコントローラの制御コマンドを入力する第２の入力デバイスを有し、該ローカルコントローラは、該患者から信号を受信するように該患者に動作可能なようにさらに接続され、該ローカルコントローラは、該プログラム可能医療デバイスの動作を操作する、ローカルコントローラと、
該ローカルコントローラを制御するリモートコントローラであって、該リモートコントローラは、該プログラム可能デバイスが配置される第１の位置から離れた第の位置に配置され、該リモートコントローラは、該第２の位置のユーザが該ローカルコントローラを制御することを可能にする手段を有する、リモートコントローラと
を備える、システム。
【請求項１９】
前記第２の入力デバイスは、バーコードリーダである、請求項１８に記載の医療配信システム。
【請求項２０】
患者の情報および医療データは、前記第２の入力デイバスを介して入力される、請求項１８に記載の医療配信システム。
【請求項２１】
ディスプレイデバイスと、前記プログラム可能医療デバイスの前記入力デバイスに実質的に対応する仮想入力デバイスの可視表示を生成する表示手段であって、該ディスプレイデバイスに動作可能な用に接続される、表示手段と、前記第２の位置のユーザが該可視入力デバイスを起動して、該ユーザが該第２の位置から前記プログラム可能医療デバイスの動作を制御することを可能にする手段と
をさらに備える、請求項１８に記載の医療装置。
【請求項２２】
患者に薬剤を提供する方法であって、該薬剤配信は、該患者の１つ以上の生理学的状態によってトリガーされ、該方法は、
薬剤配信デバイスを提供するステップと、
制御アルゴリズムを有するローカルコントローラを提供するステップと、
センサを提供するステップと、
リモートコントローラを提供するステップであって、該リモートコントローラは、入力デバイスを有する、ステップと、
該患者の該生理学的状態に関する信号を取得するセンサを利用し、該信号を該コントローラに送信し、該信号に含まれる情報を該制御アルゴリズムに入力し、該制御アルゴリズムからの結果のデータに基づいて結果を展開し、該制御アルゴリズムからの結果に基づいてフィードバック制御を展開し、かつ、該患者に該薬剤を配信するために、該フィードバック制御に基づいて適切な薬剤配信デバイスを操作するステップと
を包含する、方法。
【請求項２３】
患者に薬剤を提供する方法であって、該薬剤配信は、１つ以上の環境条件によってトリガーされ、該方法は、
薬剤配信デバイスを提供するステップと、
制御アルゴリズムを有するローカルコントローラを提供するステップと、
センサを提供するステップと、
リモートコントローラを提供するステップであって、該リモートコントローラは、入力デバイスを有する、ステップと、
該患者の環境の該環境条件に関する信号を取得するセンサを利用し、該信号を該コントローラに送信し、該信号に含まれる情報を該制御アルゴリズムに入力し、該制御アルゴリズムからの結果のデータに基づいて結果を展開し、該制御アルゴリズムからの結果に基づいてフィードバック制御を展開し、かつ、該患者に該薬剤を配信するために、該フィードバック制御に基づいて適切な薬剤配信デバイスを操作するステップと
を包含する、方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公表番号】特表２００６−５０３５９７（Ｐ２００６−５０３５９７Ａ）
【公表日】平成１８年２月２日（２００６．２．２）
【国際特許分類】
【出願番号】特願２００３−５５９５８２（Ｐ２００３−５５９５８２）
【出願日】平成１４年１２月５日（２００２．１２．５）
【国際出願番号】ＰＣＴ／ＵＳ２００２／０３８９０１
【国際公開番号】ＷＯ２００３／０５９４２２
【国際公開日】平成１５年７月２４日（２００３．７．２４）
【出願人】（５９１０１３２２９）バクスター・インターナショナル・インコーポレイテッド (448)
【氏名又は名称原語表記】ＢＡＸＴＥＲ ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＩＮＣＯＲＰ０ＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成１８年２月２日（２００６．２．２）
【国際特許分類】
【出願日】平成１４年１２月５日（２００２．１２．５）
【国際出願番号】ＰＣＴ／ＵＳ２００２／０３８９０１
【国際公開番号】ＷＯ２００３／０５９４２２
【国際公開日】平成１５年７月２４日（２００３．７．２４）
【出願人】（５９１０１３２２９）バクスター・インターナショナル・インコーポレイテッド (448)
【氏名又は名称原語表記】ＢＡＸＴＥＲ ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＩＮＣＯＲＰ０ＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]