薬剤情報を保持するため、および薬物送達デバイスと通信するためのシステム
【課題】１つまたは複数の薬物投与デバイスまたは薬物送達デバイスと通信するためのシステムを提供する。
【解決手段】薬剤情報を保持するため、ならびに病院環境、薬局環境、または生物医学サービス環境において使用されるために設計されたソフトウェアを含む薬物送達デバイスと通信するためのシステム。ソフトウェアは、コンピュータ可読媒体上で提供されることが可能である。ソフトウェアは、施設が、筐体内部のスロットに取り外し可能な形で挿入されたプラグアンドプレイモジュールを有するインフューザ１２で使用するため、または筐体内部に密閉された接続エンジンを有するインフューザで使用するための、ハード薬剤限度とソフト薬剤限度の両方、ならびにその他のパラメータで、薬剤ライブラリをカスタマイズすることを可能にする。システムは、１つまたは複数のコンピュータ１０に接続された１つまたは複数のインフューザへのデータ転送をサポートする。
【解決手段】薬剤情報を保持するため、ならびに病院環境、薬局環境、または生物医学サービス環境において使用されるために設計されたソフトウェアを含む薬物送達デバイスと通信するためのシステム。ソフトウェアは、コンピュータ可読媒体上で提供されることが可能である。ソフトウェアは、施設が、筐体内部のスロットに取り外し可能な形で挿入されたプラグアンドプレイモジュールを有するインフューザ１２で使用するため、または筐体内部に密閉された接続エンジンを有するインフューザで使用するための、ハード薬剤限度とソフト薬剤限度の両方、ならびにその他のパラメータで、薬剤ライブラリをカスタマイズすることを可能にする。システムは、１つまたは複数のコンピュータ１０に接続された１つまたは複数のインフューザへのデータ転送をサポートする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概ね、薬物投与デバイスまたは薬物送達デバイスに関する。より詳細には、本発明は、薬剤情報または薬物情報を保持するため、コンピュータと１つまたは複数の輸液ポンプの間で通信を提供するため、ならびにそのような情報および通信の整合性を保証するための新規なシステムに関する。
【背景技術】
【０００２】
患者の循環系に直接に薬物、およびその他の液体を投与することが望ましい場合、静脈内輸液療法が処方される。臨床行為が意図していたよりも高い、または低い投与量がプログラミングされていることを臨床家に警告する警報がなかったなら、患者に送達される結果の量が、疾病率（ｍｏｒｂｉｄｉｔｙ）の増加をもたらす、または致命的となる可能性がある。薬用液体を患者の身体に輸液するのに医療スタッフ（ｍｅｄｉｃａｌ ｐｅｒｓｏｎｎｅｌ）によって使用される、様々なタイプの輸液ポンプが存在する。薬剤用量プログラミング警報の機能を有するポンプは、ほとんど存在しない。一部のポンプは、電子的にダウンロード可能な薬剤ポンプのためのカスタマイズされた薬剤ライブラリを使用する。例えば、参照により全体が本明細書に組み込まれている米国特許第６２６９３４０号が、カスタマイズされた薬剤ライブラリを策定して、パーソナルコンピュータ（ＰＣ）から、注射ポンプの筐体内部の消去可能な、電子的に読み込み可能なメモリの中にダウンロードするためのシステムおよびコンピュータ可読媒体を説明している。しかし、先行技術のシステムおよび輸液ポンプは、いくつかの欠点を有する。以下は、先行技術において見られる様々な問題を解決する斬新な輸液ポンプシステムの説明である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許第６２６９３４０号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、１つまたは複数の薬物投与デバイスまたは薬物送達デバイスと通信するためのシステムに関する。より詳細には、本発明は、リモートコンピュータ、ならびにコンピュータ可読媒体上のソフトウェアプログラムを利用して、スタンドアロンベースで、または統合された薬物管理システムの一部として、１つまたは複数の輸液ポンプに情報をダウンロードし、および／または１つまたは複数の輸液ポンプから情報をアップロードするシステムに関する。
【課題を解決するための手段】
【０００５】
一例では、ソフトウェアは、生物工学技師、薬剤師、医師、その他を含むが、以上には限定されないユーザによって使用されることが可能である、強力な薬剤ライブラリ作成能力、薬剤ライブラリ編集能力、および薬剤ライブラリアーカイブ能力をリモートコンピュータに提供する。各薬剤エントリが、関連するＣＣＡ指定を有する単一の薬剤処方集ワークシートまたは薬剤処方集データベースが、医療施設全体のために作成されることが可能である。同一の薬剤に、異なる臨床看護領域において異なる限度が確立されていることが可能であり、特定の臨床看護領域に関して医療施設の推奨される最良の慣行に依存して、異なるデバイスパラメータ、および異なるデバイス設定値が適用される可能性がある。単一の薬剤処方集ワークシートは、各臨床看護領域に関して別個のデータベースまたはサブデータベースより、管理し、更新し、保持するのがより容易である。ソフトウェアの一例では、ソフトウェアは、ユーザがデータをキー入力するにつれ、各キー入力とともに、薬剤処方集ワークシートへの入力を動的に検証するリアルタイムの規則セットバリデータ（ｖａｌｉｄａｔｏｒ）を提供する。ユーザは、値が、許容される範囲を超えた場合、またはデータが、所定の予期される特徴を満たさない場合、即時に通知を受ける。一例では、ソフトウェアは、薬物送達デバイスと通信するために、拡張マークアップ言語も使用する。コンピュータとデバイスの間の通信は、巡回冗長検査などの、任意の所望の技術を使用して検証されることが可能である。別の例では、データベースを使用して、複数の輸液ポンプの履歴が格納される。これにより、１つのデータベースの中で１つの機関におけるすべてのポンプからイベントログデータを取り出す能力が可能になり、使用の場所、時刻、誤りのタイプ、その他に基づき、データを取り出すことができる。他のタイプのリポートも可能である。
【０００６】
ソフトウェアは、一例では、コンピュータを利用して、１つまたは複数の薬剤送達デバイス（輸液ポンプなどの）に情報をダウンロードし、および１つまたは複数の薬物送達デバイス（輸液ポンプなどの）から情報をアップロードするシステムの一部分として役立つ。一実施形態では、システムは、ソフトウェアを格納するためのメモリ、ユーザインタフェース、およびディスプレイを有するリモートパーソナルコンピュータ（ＰＣ）を含む。また、システムは、１つまたは複数の輸液ポンプ、ならびに、ＰＣをポンプに接続して、ＰＣとポンプの間における情報の通信を円滑にするための１つまたは複数の技術も含む。輸液ポンプは、薬物（すなわち、液体、薬物、またはそれらの混合物）を患者に送達するための単一のチャネルを有することも、複数のチャネルを有することも可能である。一例では、ポンプにダウンロードされる情報には、限定としてではなく、１つまたは複数の薬剤エントリが、通常、臨床看護領域別にグループ化されている薬剤ライブラリ、薬剤送達パラメータ（ハード限度およびソフト限度）、デバイス設定値、デバイスパラメータ、またはデバイス限度、患者識別データなどの患者固有の情報、看護者ＩＤ（ｃａｒｅｇｉｖｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などの看護者固有の情報が含まれることが可能である。
【０００７】
一例では、ソフトウェアおよび通信プロトコルは、異なるバージョン、異なるモデル、および異なるタイプの薬物送達デバイスに適用可能なオープンアーキテクチャを利用する。本発明の一実施形態では、ソフトウェアは、情報をダウンロードするため、およびアップロードするために、複数の汎用輸液ポンプと有線通信を確立するシステムにおいて利用される。他の諸実施形態では、ソフトウェアは、情報をダウンロードするため、およびアップロードするために、ポンプ筐体内部に設置されたプラグアンドプレイ（ｐｌｕｇ ａｎｄ ｐｌａｙ）通信モジュールを有する１つまたは複数の汎用輸液ポンプと無線通信を確立するシステムにおいて利用される。他の諸実施形態では、プラグアンドプレイ通信モジュールは、ポンプ筐体内部に密閉されたオプションの回路基板上に一体化して組み込まれる。薬物送達デバイスの例には、単一チャネルまたは複数チャネルの汎用輸液ポンプ、患者自己管理鎮痛（ｐａｔｉｅｎｔ ｃｏｎｔｒｏｌｌｅｄ ａｎａｌｇｅｓｉａ）（ＰＣＡ）ポンプ、歩行（ａｍｂｕｌａｔｏｒｙ）ポンプ、経腸ポンプ、ＩＶ輸液ポンプ、その他が含まれていたが、以上には限定されない。
【０００８】
また、ソフトウェアは、薬物管理ユニットまたは薬物管理サーバとインタフェースをとる、あるいはそのようなユニットまたはサーバとして動作するコンピュータ上でも役立つ。その例では、ソフトウェアは、患者エリアネットワーク（ＰＡＮ）内で、ＰＣと１つまたは複数の薬剤送達デバイスの間における通信を円滑にする。ＰＣとデバイスの間の通信がどのような目的で使用されることが可能であるかの例には、薬物送達デバイスを動作させるため、および制御するための患者固有の薬剤送達命令をダウンロードすること、ならびにデバイス特性、条件、使用履歴、および警報履歴などの情報をアップロードすることが含まれるが、以上には限定されない。
【０００９】
本発明が、例として、限定としてではなく、同様の符号が同様の要素を示す、添付の図面の図に示されている。
【図面の簡単な説明】
【００１０】
【図１Ａ】本発明による輸液ポンプの正面図である。
【図１Ｂ】図１の輸液ポンプの背面図である。
【図１Ｃ】図１の輸液ポンプの背面透視図であり、ポンプとコンピュータの間の通信を円滑にするプラグアンドプレイモジュールを示す。
【図１Ｄ】ＣＤ−ＲＯＭディスク、または本発明によるコンピュータ可読媒体の可能な一実施形態を示す正面透視図である。
【図１Ｅ】接続箱への接続を介して、複数のポンプをコンピュータと通信するようにさせるのに使用されることが可能なデータケーブルの透視図である。
【図１Ｆ】プラグアンドプレイモジュールをコンピュータに接続し、他のポンプと互いに接続するためのデュアルジャック付き（ｄｕａｌ ｊａｃｋｅｄ）接続箱ケーブルの透視図である。
【図１Ｇ】接続箱上のデュアルジャックの１つにコンピュータを接続するためのデータケーブルの透視図である。
【図２】本発明がどのように使用されることが可能かを示す図である。
【図３】ライブラリをカスタマイズするためのプロセスの一例を示す図である。
【図４Ａ】ＰＣと輸液ポンプの間の通信を示す図である。
【図４Ｂ】薬剤ライブラリを編集し、ダウンロードするプロセスを示す流れ図である。
【図５】複数のポンプのコンピュータへの接続を示す背面図である。
【図６】薬剤師が、本発明を備えたコンピュータ上で見るワークシートの例を示す図である。
【図７Ａ】ソフト限度オーバライドレポートの例を示す図である。
【図７Ｂ】図７のレポートを説明するテーブルである。
【図７Ｃ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｄ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｅ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｆ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ａ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｂ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｃ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｄ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図９】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１０】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１１】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１２Ａ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｂ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｃ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｄ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１３】本発明で使用するための電子システムの一例を示すブロック図である。
【図１４】本発明で使用するための電子システムの一例を示すブロック図である。
【図１５Ａ】薬剤に関する規則セットを編集する際に使用されるダイアログボックスの例を示す図である。
【図１５Ｂ】本発明のＲｕｌｅ Ｓｅｔ Ｅｄｉｔｏｒにおける様々なフィールドまたは値に関する有効な入力範囲を示すテーブルである。
【図１６】規則セットバリデータ判定ツリーの一例を示す図である。
【図１７Ａ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１７Ｂ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１７Ｃ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１８】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１９】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図２０Ａ】ＸＭＬ交換スキーマの一例を示す図である。
【図２０Ｂ】本発明の一例において利用されるＸＭＬオブジェクトタグ名を示すテーブルである。
【図２１】規則セットの追加、編集、削除、または閲覧を行う際に規則セットエディタで使用されるダイアログボックスの例である。
【図２２】ＤａｔａＭｏｄｅｌとＤａｔａＩｔｅｍの間の関係を示すブロック図である。
【図２３】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２４Ａ】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２４Ｂ】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２５】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２６】ソフト限度警報イベントまたはオーバライド臨床イベントをサポートするデータモデルを示す図である。
【発明を実施するための形態】
【００１１】
一般に、本発明は、コンピュータと、１つまたは複数の薬物投与デバイスの間で通信を提供するためのシステムおよび方法を提供する。本発明は、ハードウェアとソフトウェアを使用して、コンピュータと輸液ポンプの間のリンクを提供する。一例では、本発明は、薬局環境または生物医学技術サービス環境、あるいは、全体が本明細書に明示的に組み込まれている、２００３年１２月５日に出願した、「ＭＥＤＩＣＡＴＩＯＮ ＭＡＮＡＧＥＭＥＮＴ ＳＹＳＴＥＭ」という名称の本出願人の同時係属仮出願第６０／５２７５８３号、および２００４年２月２０日に出願した、同一の名称による通常の特許出願で説明されている、薬物管理ユニット（ＭＭＵ）において使用されるように設計される。
【００１２】
本発明は、施設が、イリノイ州、アボットパーク所在のアボットラボラトリーズ（Ａｂｂｏｔｔ Ｌａｂｏｒａｔｏｒｉｅｓ）から入手可能な、ＰＬＵＭ Ａ＋（登録商標）インフューザ（ｉｎｆｕｓｅｒ）またはポンプのような輸液ポンプで使用するための薬剤ライブラリをカスタマイズすることを可能にする。また、他のタイプのポンプも、本発明で使用されることが可能である。例えば、本発明は、患者自己管理鎮痛（ＰＣＡ）ポンプ、歩行ポンプ、経腸ポンプ、ならびにＩＶ輸液ポンプで使用されることが可能である。また、本発明は、複数のポンプからのデータの格納も可能にし、様々な安全性レポート、イベント、および警報レポートを生成する。
【００１３】
図１Ａは、Ａｂｂｏｔｔ ＰＬＵＭ Ａ＋（登録商標）インフューザまたはポンプ１２の正面図である。図１Ｂは、筐体２が、筐体２内部に、コンピュータと輸液ポンプの間の通信を円滑にするプラグアンドプレイモジュール４を受けるために内部に形成された、縦に細長いスロット３を含むように変更されている、図１ＡのＰＬＵＭ Ａ＋（登録商標）ポンプの背面図である。プラグアンドプレイモジュール４は、筐体２内部に動作可能なように配置され、筐体によって実質的に包囲され、保護され、隔離される。プラグアンドプレイモジュール４は、ポンプ筐体２のスロット３にはまり込む、薄い、細長いカード形状のケースを有する。このため、本発明のプラグアンドプレイモジュール４は、ポンプによって占有される空間をほとんど増大させることがない。図１Ａおよび図１Ｂに示されるプラグアンドプレイモジュール４は、ハードワイヤド通信向けに構成される。しかし、以下に説明するとおり、プラグアンドプレイモジュール４は、無線通信向けに構成されることも可能である。
【００１４】
一例では、本発明のソフトウェアは、１２までの臨床看護領域（ＣＣＡ）を格納することができ、１００までの薬剤エントリ（９９の薬剤エントリ、およびＮｏ Ｄｒｕｇ Ｓｅｌｅｃｔｅｄ）が各ＣＣＡの中に格納されて、合計で１２００のエントリが、マスタ薬剤処方集の中に格納される。その例では、本発明のソフトウェアは、単一のコンピュータに接続された１５までのＡｂｂｏｔｔ ＰＬＵＭ Ａ＋（登録商標）単一チャネルインフューザのデータ転送をサポートする。もちろん、本発明は、異なる格納能力および通信能力で設計されることが可能であり、異なるポンプ向けに構成されることが可能である。
【００１５】
図２は、本発明がどのように使用されることが可能であるかを示す図である。図２に示されるとおり、ソフトウェアが、ホストコンピュータ（この例では、パーソナルコンピュータ、つまり、ＰＣ１０）上にインストールされると、ユーザは、任意の所望される規則セットを含む、薬剤ライブラリを作成する（または、ソフトウェア媒体を備えたライブラリを使用する）ことができる。薬剤ライブラリは、薬剤名、薬剤量、薬剤単位、希釈液量、希釈液単位、投与単位、薬剤クラス、ハード限度、およびハード限度範囲内のソフト限度を含むエントリを含むことが可能である。薬剤濃度は、入力する必要がない。というのは、その値は、薬剤量、薬剤単位、希釈液量、および希釈液単位から導出可能だからである。また、ユーザは、ライブラリ内で複数のＣＣＡを作成することもできる。次に、ユーザは、ＰＣを複数のインフューザ１２に接続し、ＰＣとインフューザの間でデータ転送を開始することができる。例えば、アクティブ薬剤ライブラリが、ＰＣから、接続されたインフューザにダウンロードされることが可能である。さらに、データは、インフューザからＰＣに転送されることも可能である。例えば、イベントログおよびアラームログが、接続されたインフューザからＰＣにアップロードされることが可能である。また、所望の他のあらゆるタイプのデータまたは通信も、ＰＣとインフューザの間で転送されることが可能である。
【００１６】
図３は、ライブラリをカスタマイズするためのプロセスの一例を示す図である。図３のプロセスは、薬剤師などのユーザが、ＰＣ１０上でワークシートを作成することから始まる。この例では、ワークシートは、依然、編集されることが可能であり、まだ完成されていないライブラリと考えることができる。このワークシートの１つの目立った特徴は、ワークシートが、２つの同時のビュー、すなわち、目標の「実用（ｗｏｒｋｉｎｇ）」処方集ビュー、およびソース「基準」処方集ビューを提供することである。一例では、薬剤のマスタ処方集ビューが、同時に、そのＣＣＡに関する目標薬剤のビューが示されながら、基準ビューの中にあることが可能である。同様に、別の例では、目標ビューは、「Ｍｅｄｉｃａｌ（内科）」などの１つのＣＣＡであるのに対し、ソースは、「Ｓｕｒｇｅｒｙ（外科）」などの別のＣＣＡであることも可能である。薬剤師は、全く同一の薬剤エントリを、関連する規則セットとともに、ソースから目標にコピーすることができる。この提示により、すべての必要なＣＣＡを策定するのにかかる時間が短縮され、薬剤師のための容易な品質検査、ならびに策定されているすべての薬剤規則セットにわたるビューが促進される。さらに、同一の薬剤名、濃度、および規則セットを多くの異なるＣＣＡの中に再入力することを余儀なくされた場合に、タイプ入力の誤りが減少する。薬剤ライブラリを策定する際の誤りは、看護士のためのセーフティネットの低下、患者の疾病率の増加をもたらす可能性がある。図６は、薬剤師（または他のユーザ）が、本発明を備えたコンピュータ上で見ることができるワークシートの一例を示す。図６は、マスタ薬剤処方集テーブルが、スクリーンの下部１４にあり、選択されたＣＣＡにおける薬剤が、スクリーンの上部１６にある分割スクリーンビューを示す。プルダウンメニュー１８を使用して、いずれのＣＣＡが、上部１６で表示されるかが選択される。
【００１７】
図３および図２０Ａを参照すると、ユーザは、次に、許可されたユーザによって定義された、病院の区域または患者集団（ｐａｔｉｅｎｔ ｐｏｐｕｌａｔｉｏｎ）（例えば、集中治療部（ＩＣＵ））において使用するための薬剤ライブラリのサブセットである、ＣＣＡを作成する（そのようなＣＣＡが、既に作成済みでない場合）。各ＣＣＡは、事前定義された数の特定の薬剤を有することが可能である。また、病院は、薬剤ライブラリの中に複数のＣＣＡを有することが可能である。次に、ユーザは、任意の所望の薬剤クラス（例えば、抗生物質、麻酔薬、β遮断剤、その他）を作成し、その後、薬剤エントリを規則セットとともにＣＣＡに追加する。次に、ＣＣＡインフューザ設定値が、設定される。ＣＣＡインフューザ設定値の例には、最大速度、既定の閉塞圧、最大患者体重および／または最小患者体重が含まれる。次に、マスタインフューザ設定値が、セットアップされる。マスタインフューザ設定値の例には、Ｃｏｎｔｉｎｕｅ Ｒａｔｅ（療法が完了した後に、インフューザが切り替わる既定の速度）、Ｅｎａｂｌｅ Ｄｅｌａｙ／Ｓｔａｎｄｂｙ（既定のスタンバイ設定）、Ｃａｌｌｂａｃｋ Ｎｏｔｉｆｉｃａｔｉｏｎ（イネーブルにされた場合、多段輸液中の段階の合間に、または薬用量を装填した後に、インフューザ１２が、可聴の看護士コールバックアラームを発し、通知を表示するようにさせる）、およびＤｅｌｉｖｅｒ Ｔｏｇｅｔｈｅｒ（既定として、２チャネル送達方法を選択することを可能にする）が含まれる。ワークシートを完成させる前に、ワークシートレポートが印刷され、点検されることが可能である。最後に、ワークシートが、アクティブライブラリとして完成される。
【００１８】
アクティブライブラリが準備できた後、技師は、１つまたは複数のインフューザ１２をデータ転送のためにＰＣ１０に接続することができる。図４Ａおよび図５は、ＰＣ１０とインフューザ１２の間の通信を示す図である。第１に、アクティブライブラリが、インポートされる。次に、技師は、インフューザ１２をＰＣ１０に接続する。インフューザ１２は、任意の所望の形でＰＣ１０に接続されることが可能である。例えば、ケーブル（図１Ｆ）が、ＰＣ１０上のシリアルポートと、接続箱（図１Ｅ）の間で接続されることが可能であり、接続箱は、プラグアンドプレイモジュール４（図１Ａ）を介して、各インフューザ１２のデータポートにも接続される。インフューザ１２とＰＣ１０は、シリアルインタフェース（ＲＳ２３２、ＵＳＢ、その他）、パラレルインタフェース、その他を含め、任意の所望のタイプのインタフェースを使用することができる。別の例では、インフューザ１２は、必要に応じてＰＣ１０への接続を提供する無線能力を有することが可能である。接続されると、プログラミングイベント、設定値、およびアラーム、その他を含むが、以上には限定されない情報が、履歴情報（ログ）またはリアルタイム情報として、ＰＣにアップロードされることが可能であり、アクティブライブラリが、インフューザ１２のすべてにダウンロードされることが可能である。図５は、複数のシリアルコネクタ、および複数の接続箱を有するシリアルケーブルを使用した、複数のポンプのコンピュータへの接続を示す図である。
【００１９】
図４Ｂは、前述したプロセスを示す別の流れ図である。図示されるとおり、病院処方集が、１つまたは複数のワークシートにインポートされることが可能である。ユーザが、薬剤ライブラリを完成させた後、アクティブ薬剤ライブラリが、１つまたは複数のインフューザにダウンロードされることが可能である。また、図４Ｂは、薬剤ライブラリが、アーカイブされ、ワークシートを策定する、または編集する際に、再び使用されることが可能であることも示す。
【００２０】
本発明は、先行技術における様々な問題を解決するいくつかの特徴を含む。以下は、それらの特徴の説明である。
【００２１】
本発明は、リモートプロシージャコール（ＲＰＣ）のために拡張マークアップ言語（ＸＭＬ）表現を利用する。ＸＭＬを使用する１つの利点は、ＸＭＬ構文ドキュメントの使用により、プロトコルが、異なるタイプの製品をサポートすることが可能になることである。例えば、第１のインフューザが、別のインフューザによって要求されるフォーマットとは異なる、ある通信フォーマットだけしか許さない可能性がある。ＸＭＬを使用することにより、システムは、異なるタイプのインフューザと通信することができる。異なるタイプのデバイスの例には、異なるコンピュータアーキテクチャを有するデバイス、異なるタイプのコンピュータプロセッサを実行しているデバイス、異なるソフトウェアプログラム（または同一のプログラムの異なるバージョン）を実行しているデバイスが含まれる。さらに、一部のデバイスは、他のデバイス上で使用されているバイナリフォーマットと互換性がない可能性があるバイナリデータフォーマットを使用して動作する。このように、ホストコンピュータは、様々な異なるタイプのデバイスに関して同一のメッセージフォーマットを使用することができる。また、本発明は、輸液ポンプなどの患者に接続された医療デバイスと通信する際に、ＸＭＬパーサの使用も提供する。
【００２２】
本発明の一部の応用例では、ホストとポンプが、互換性のないバイナリデータフォーマットを有する可能性がある。その理由で、ホスト上と、ポンプ上で同一である語彙形式（ｌｅｘｉｃａｌ ｆｏｒｍ）を定義する必要がある。その共通の語彙表現が、正規形式と呼ばれる。プロセス固有のバイナリ形式を正規形式に変換するプロセスは、正規化と呼ばれる。
【００２３】
誤り検査は、一般に、チェックサム関数またはハッシュ関数を使用する。しかし、これらの関数は、常に信頼できるわけではない。本発明は、医療上クリティカルなデータを使用するので、より信頼できる誤り検査関数を使用することが重要である。さらに、ライブラリ全体の内容を検証することが依然として可能でありながら、部分ライブラリ更新（薬剤ライブラリの中の個別の項目などの）を可能にすることが望ましい。本発明は、標準のチェックサム関数またはハッシュ関数を、交換データ構造全体の状態を保護するグローバル正規巡回冗長検査（Ｇｌｏｂａｌ Ｃａｎｏｎｉｃａｌ Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）（ｇＣＣＲＣ）で補う。ｇＣＣＲＣの目的は、ホストとポンプが、試みられたデータ伝送の後に、それぞれのデータが同一であることを検証することができるようにすることである。ｇＣＣＲＣは、より低いレベルのチェックサム、およびその他の方法によって捕えられない誤りを検出することができる。例えば、ｇＣＣＲＣは、ドロップされたパケットの数が、シーケンス番号の範囲そのものである場合を検出する。また、ｇＣＣＲＣは、ポンプ切断、停電、およびソフトウェア欠陥のような例外を含む、あらゆる種類のプロトコル障害に対する、最終の「バックストップ（ｂａｃｋｓｔｏｐ）」検証も提供する。
【００２４】
一例では、２つのバイナリイメージ（ホストコンピュータにおけるイメージと、インフューザにおけるイメージ）を比較して、それらが同一であるかどうかを確かめて、インフューザの中に格納されたデータの内容を検証する従来の技法ではなく、２つの場合により全く異なる物理的（ビット単位の）表現が、意味的に同一であるかどうかを判定する比較が行われる。これは、正規表現（いずれの側も、格納のために実際に使用しない）を使用し、次に、２つの抽象表現の間で比較を行うことによって達せられる。例えば、輸液ポンプにおけるデータの内容を検証するのに、ポンプにおけるデータに基づき、ＣＲＣが計算される。次に、ホストが、ポンプにおけるデータであると考えるものに基づき、ＣＲＣが計算される。次に、それらの数値が比較される。数値が同一であった場合、データは、ホストとインフューザにおいて同一である可能性が極めて高い。このアプローチの１つの利点は、少量のデータしか、比較の目的で転送されることが要求されないことである。ライブラリ全体のバイナリイメージは、比較のために再伝送されなくてもよい。また、このアプローチは、データ伝送中の誤り検査の要件も無くす。
【００２５】
本発明の別の態様は、ＣＲＣがどのように計算されるかに関する。使用されるＣＲＣの形態は、Ｃｏｍｉｔｅ Ｃｏｎｓｕｌｔａｔｉｆ Ｉｎｔｅｒｎａｔｉｏｎａｌｅ ｄｅ Ｔｅｌｅｇｒａｐｈｉｑｕｅ ｅｔ Ｔｅｌｅｐｈｏｎｉｑｕｅ（ＣＣＩＴ）によって指定されている。しかし、本発明では、ＣＣＩＴ ＣＲＣは、逆のビット順序（ＣＣＩＴによって指定される左から右にではなく、右から左に）で行われて、計算をより効率的にするようにする。Ｉｎｔｅｌプロセッサは、ＣＣＩＴによって規定される、いわゆる「ネットワークバイト順」とは逆の「エンディアン性（ｅｎｄｉａｎｎｅｓｓ）」を有するので、ビット逆転により、一部のプロセッサ上でインプリメンテーション問題が回避されることになる。
【００２６】
ＣＲＣを使用して前述した語（異なるエンディアン性を有することが可能な）を構築する際、ＣＲＣを使用する前に、ドキュメントまたはデータの構文を正確に定義することが重要である。本発明は、その目的でＸＭＬスキーマを使用する。加えて、ＸＭＬスキーマは、検証のために使用されるセマンティクスを定義するのに使用される。）検証されるべきデータ（例えば、薬剤ライブラリ）は、正規形式（前述した）に変換され、ＸＭＬスキーマを使用して検証され、確認されて、データが有効であるとともに、正しい形式である（ｗｅｌｌ ｆｏｒｍｅｄ）かどうかが判定される。ライブラリの例では、この検証検査は、ライブラリをポンプに伝送する前に行われる。
【００２７】
本発明のＸＭＬスキーマの一例は、２つの主要な部分、エクスチェンジスキーマ、およびインプライドスキーマを含む。一般に、エクスチェンジスキーマは、ホストコンピュータと輸液ポンプの間で通信されるべきデータの構造を定義する。インプライドスキーマは、交換されているデータの型を定義する（さらに、検証する）。
【００２８】
図２０Ａは、Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ（ＵＭＬ）表記法を使用する、ＸＭＬエクスチェンジスキーマの一例を示す図である。図２０Ａの例で示されるとおり、薬剤ライブラリは、インフューザ設定値、少なくとも１つの薬剤エントリ、およびアクティブライブラリオブジェクトを含む。この例では、１つのインフューザ設定値オブジェクト、および１つのアクティブライブラリオブジェクトだけが存在するが、１２００までの薬剤エントリオブジェクトが存在する。図２０Ａに示された各オブジェクトは、それぞれのボックス内に記載される属性を含む。アクティブライブラリオブジェクトは、１２までのＣＣＡオブジェクトを含む。各ＣＣＡオブジェクトは、１００までの規則セットオブジェクトを含む。この例では、１つの薬剤につき１つだけの規則セットが存在するが、複数の薬剤が、単一の規則セットを共有することが可能である。図２０Ａに示されたデータ構造、およびそれらのデータ構造のメンバは、各エントリに関するタグ名（オプションとして、略記される／短縮される）を有するＸＭＬオブジェクトとして定義される。図２０Ｂは、一例において使用される名前を明らかにする。図２０Ｂは、コマンドとともに、クエリおよび応答、ならびにそれらの対応する省略形を示す。図示されるとおり、データ構造に加えて、コマンドおよびクエリも、ＸＭＬで符号化され、ホストコンピュータ（つまり、サーバ）側およびポンプ（つまり、クライアント）側によって、データと同様に処理される。当業者には明白なとおり、コマンドおよびクエリを本発明とともに使用して、ホストコンピュータとクライアント輸液ポンプの間で通信を効率的に提供することができる。例えば、以下のコマンドにより、サーバの計算されたグローバル正規チェックサムをクライアントに通信している間に、薬剤ライブラリ更新が終了される（＜ｘＥＵ ｇｃｃｒｃ＝”９Ｂ８Ｄ”／＞）。図２０Ｂに示されるとおり、「ｘＥＵ」は、コマンド「ＥｎｄＬｉｂｒａｒｙＵｐｄａｔｅ」の省略形であり、他方、値「９Ｂ８Ｄ」は、サーバのチェックサムの１６進値の例である。その他のコマンドおよびクエリも、同様の形で使用される。
【００２９】
インプライドデータは、ホストコンピュータ１０と輸液ポンプ１２の間の契約である。インプライドデータは、ホストによって管理され、ホストおよびクライアントのためのソフトウェアを開発する際に使用される。一例では、インプライドデータは、通信リンクを介して伝送されず、インフューザソフトウェアがそのデータを処理することも決してない。インプライドスキーマの１つの目的は、クライアントに送られることが許されるデータの値および型を検証することである。１つの形態の検証は、範囲外の値が伝送されるのを制限する範囲検査である。別の形態の検証は、表示精度であることが可能である。例えば、変数の表示範囲は、０．１位（ｔｅｎｔｈｓ ｏｆ ｄｉｇｉｔ）であることが可能である。そのようなケースでは、１２．００という値を送信することは、その値が、変数の範囲を超えた精度を記述しているので、無効である。別のタイプの検証は、固有型検査であることが可能である。暗黙のスキーマは、ＸＭＬスキーマドキュメントの形態をとる。ＸＭＬスキーマドキュメントは、エクスチェンジスキーマの中のすべてのクライアント／ホスト固有の型定義のための型定義を提供する。以下は、様々なインプライドスキーマの型の例である。第１の例は、機関名文字列が、３０文字以下であることを定義する単純文字列型スキーマである。
【数１】
【００３０】
ＸＭＬスキーマは、ほとんどの数値データ型上でｆｒａｃｔｉｏｎＤｉｇｉｔｓファセットを直接に介して固定小数点表示をサポートする。以下の例は、最小および最大の１０進数値および小数部数値を定義する。
【数２】
【００３１】
一例では、本発明は、ＥｎｃｏｄｅｄＳｔｒｉｎｇに対するｘｓ：ｅｎｕｍｅｒａｔｉｏｎ制限を定義することにより、インプライドエニュメレーションを構築する。
【数３】
【００３２】
単一の値に関する複数の範囲が、＜ｘｓ：ｃｈｏｉｃｅ＞を介して値に関して指定されることが可能である。以下の例は、上限範囲および下限範囲を含む、患者体重フィールドに関する。
【数４】
【００３３】
ＸＭＬを使用することの１つの問題は、ＸＭＬが、非常に詳細（ｖｅｒｂｏｓｅ）であることであり、これにより、帯域幅要件が増大する。通信オーバーヘッドを低減するため、本発明は、依然として標準に準拠するが、ＸＭＬ識別子をいくつかの文字ニーモニック（ｍｎｅｍｏｎｉｃ）に短縮することによって大幅に低減された帯域幅で動作する、よりコンパクトな形態のＸＭＬを使用する。符号化は、簡潔な要素、および属性名を使用する正しい形式のＸＭＬである。一例では、各ＸＭＬ Ｓｈｏｒｔ Ｎａｍｅは、英字だけから成り、最初の文字によって一意に識別されることが可能である。コマンドは、引数をＸＭＬ属性として送る。応答は、値を、属性値として、かつ／または応答要素の中に入れ子にされた要素として戻す。例えば、長いＸＭＬ名「ＩｎｆｕｓｅｒＳｅｔｔｉｎｇ」は、「ＩＳ」に短縮される。したがって、例示的なコマンドラインは、
例：コンパクトなＰｕｍｐＣｏｎｆｉｇｕｒａｔｉｏｎインスタンス
【数５】
のようなものであり、
例：ＰｕｍｐＣｏｎｆｉｇｕｒａｔｉｏｎインスタンス
【数６】
のような、コンパクトでないバージョンではない。
この例では、符号化は、約２００文字を約６０文字に削減しており、およそ３．３対１の比をもたらしている。
【００３４】
本発明は、データポートプロトコルの上に、信頼できるバイナリトランスポートプロトコルを含む、拡張されたデータポートプロトコルを使用する。つまり、プロトコルが、データポートプロトコルの上で実行される。このアプローチの１つの利点は、異なるマシン間の互換性の向上である。別の利点は、大きいメッセージがセグメント化され、再組み立てされることが可能なことである。これにより、ホストまたはポンプが大きいメッセージを扱うことができない場合でも、非常に大きいメッセージが、プロトコルスタックを介して送信されることが可能になる。大きいメッセージは、小さいパケットにセグメント化され、後に再組み立てされる。
【００３５】
本発明は、ポンプにダウンロードされることが可能であり、アクティブライブラリと呼ばれる１つのライブラリだけが、コンピュータの中に保持されることを可能にすることにより、データベースの安全性を確実にする。これにより、時間が経つにつれ誤ったライブラリがダウンロードされないことが確実になる。編集されることが可能なライブラリは、ワークシートと呼ばれ、多くの異なるワークシートが存在することが可能である。かつてアクティブであり、もはやアクティブではないライブラリは、アーカイブされ、そのようなものとして自動的に指定される。アクティブライブラリを別のコンピュータに転送することができるように、一意の特別なファイル拡張子および認識が開発された。これにより、複数の所在地を有する、より大型の医療施設の薬局間における全く同一のライブラリの転送が可能になる。
【００３６】
本発明の別の利点は、システムが、複数の輸液ポンプに同時にデータをダウンロードすることができることである。ライブラリは、マルチキャストの形で複数のポンプに伝送される。システムは、ポイントツーポイント通信を使用して、各ポンプのステータスを定期的に検証する。ポンプの１つが問題を有する場合、ダウンロードは、再スタートされることが可能であり、各ポンプが、新たなダウンロードの通知を受ける。一例では、あるポンプが、ブロードキャストダウンロード中にダウンロードエラーを検出すると、そのポンプは、ホストコンピュータにメッセージを送信し、すると、ホストは、ダウンロードを停止する。次に、ホストは、ポンプのすべてにポーリングを行って、ポンプのすべてが、有効なデータを有するメッセージを受信していた時点を特定する。ダウンロードは、複数の個々のタグ付きメッセージにわたって行われるので、タグ番号により、いずれのポンプもダウンロードエラーを報告していなかった時点をホストコンピュータが識別することが可能になる。ダウンロードが続けられる際、ダウンロードは、その時点で始まり、したがって、データのすべてが、再びダウンロードされなくてもよい。マルチキャスト通信戦略は、ダウンロードスループットを最適化する。例えば、ライブラリが、ダウンロードするのに１０分かかる場合、１５のポンプが、各ポンプに個々にダウンロードするのにかかる１５０分に対して、１０分でダウンロードを受信することができる。マルチキャストとポイントツーポイント通信のこの混合により、個々のポンプへの堅牢なダウンロードおよび再試行／回復機構が円滑になる。本発明の別の利点は、ワークシートが、薬剤エントリのＣＣＡビューを同時に提供しながら、マスタ処方集ビューを薬剤師に提供することである。薬剤エントリを編集すること、およびコピーすることは、いずれのビューにおいても行われることが可能である。この提示により、薬剤限度警報または薬用量限度警報が策定されるにつれ、薬剤師のための容易な品質検査、安全性機能が促進される。薬剤ライブラリを策定する際の誤りは、看護士のためのセーフティネットの低下、患者の疾病率の増加をもたらす可能性がある。
【００３７】
本発明の別の利点は、単一のデータベースを使用して、複数の輸液ポンプの履歴を格納することができることである。これにより、１つのデータベースの中で１つの機関におけるすべてのポンプからイベントログデータを取り出す能力が可能になり、使用の場所、時刻、誤りのタイプ、その他に基づき、データを取り出すことができる。また、他のタイプのレポートも可能である。また、集中データベースを使用しても、システムは、それぞれが、任意の所望のポンプにダウンロードすることができる複数のＰＣを含むことが可能である。
【００３８】
同様に、本発明は、ポンプ使用データを収集し、関連するレポートを生成することもできる。例えば、ソフト限度オーバライドデータが、ソフト限度オーバライドに関連するレポートの生成のために収集されることが可能である。そのタイプのレポートは、スタッフを評価すること、将来の限度を設定すること、その他などの任意の所望の目的で使用されることが可能である。
【００３９】
本発明は、薬剤データをリアルタイムで検証することができるアクティブ薬剤ライブラリエディタを含む。本発明は、無制限の数の薬剤ライブラリを管理することができる。薬剤ライブラリは、マスタ薬剤処方集（ＣＣＡが作成される元になる薬剤テーブル）、および複数のＣＣＡで構成される。ライブラリは、アクティブ（完成されていないワークシート）であること、アーカイブされていること（データベースに保存されている、以前にアクティブであったライブラリ）、またはワークシート（インフューザへのダウンロードがまだ承認されておらず、依然として編集されることが可能なドラフトライブラリ）であることが可能である。アクティブライブラリだけが、ポンプにダウンロードされることを許される。ポンプの動作上の振舞いを記述する構成パラメータなどの項目が、ポンプ全体にわたって、またはＣＣＡに固有で設定されることが可能である。それらのパラメータは、各ライブラリに独特である。ＴａｌｌＭａｎレタリングが、薬剤名に関してサポートされる。ＴａｌｌＭａｎレタリングに対する変更は、ライブラリ全体でレプリケートされる。ライブラリの中の各薬剤が、薬剤分類に関連付けられる。薬剤分類は、各ライブラリに独特である。薬剤は、複数の濃度、および複数の規則セットを有することが可能である。規則セットは、完全であること、限られていること、またはなしであることが可能である。
【００４０】
本発明の別の特徴は、アクティブ薬剤ライブラリが利用することができる様々なレベルの規則に関連する。本発明は、デバイス規則（例えば、特定の医療デバイス、または特定のタイプのデバイスの動作または限度に関連する規則）、ＣＣＡ規則（例えば、特定のＣＣＡに関連する規則）、薬剤規則（特定の薬剤に関連する規則）、および患者規則（例えば、年齢、体重、健康、病歴、アレルギー、その他などの、特定の患者に関連する規則）を含め、複数の規則レベルの使用を可能にする。
【００４１】
Ｒｕｌｅ Ｓｅｔ Ｅｄｉｔｏｒ（ＲＳＥ）が、薬剤データベースの中の規則セットを作成し、編集するのに使用される。ＲＳＥは、規則セットを正確に表示し、適宜、「追加」ボタン、「保存」ボタン、または「削除」ボタンをイネーブルにすることを担う。図２１は、規則セットの追加、編集、削除、または閲覧を行う際に規則セットエディタで使用されるダイアログボックスの例を示す。図２１に示されるとおり、薬剤名、薬剤クラス、薬剤量、薬剤希釈液、およびソフト限度／ハード限度のためのフィールドが存在する。ＲＳＥは、入力基準を調整すること、ならびにユーザが入力選択を行っている間に規則セットを検証することを担う。ＲＳＥは、ＲｕｌｅＳｅｔＤａｔａＩｔｅｍ（ＲＳＤＩ）（以下に説明する）をデータモデルとして使用し、ＲｕｌｅＳｅｔＶａｌｉｄａｔｏｒ（ＲＳＶ）（以下に説明する）をコントローラとして使用する。ＲＳＥは、モデルが検証されるべき場合、ＲＳＤＩにメッセージを送信する。ＲＳＤＩは、ＲＳＤＩを検証するＲＳＶにメッセージを送信する。この責任分離は、規則セットエディタユーザインタフェースとライブラリインポートプロセスの両方に関する標準の検証インプリメンテーションをカプセル化するように確立される。
【００４２】
本発明の別の利点は、薬剤構成に関する。本発明は、特定の薬剤に関する薬剤名および濃度の定義を可能にする特別な規則セットを含む。しかし、ポンプにおいて、ユーザは、薬剤量および薬剤単位を無効にすることができる。したがって、限度が設定されるが、ユーザは、濃度を定義することを許される。したがって、本発明は、ユーザが、薬剤ごとに送達の単位を選択することを選択的に制限する、または許す能力、ならびに薬剤単位の濃度を有する薬剤にラベルを付けるが、他の単位（ｍｌ／時）で送達する能力を有する。
【００４３】
本発明の別の利点は、制約定義に関する。本発明は、一意制約オブジェクトのセットを含む。制約オブジェクトは、キーボード入力、マウス入力、およびインポート入力を検証するための標準のインプリメンテーションを定義する。例えば、特定のフィールドが、ある数値範囲に制約されることが可能である。制約は、物事が誤って行われるのを防止する。しかし、ときとして、１つのオブジェクト入力は、別のオブジェクトの内容に基づき、本発明では、制約定義は、入力定義が変化するにつれ、動的に変化する。例えば、オブジェクト「薬剤量」に関して、制約は、測定単位（例えば、グラム数、その他）に依存して変化することが可能である。
【００４４】
Ｄｏｓｅ Ｒａｔｅ Ｄｏｃｕｍｅｎｔ（ＤＲＤ）が、複数の制約を集約して、入力確認が、無制限の数の制約オブジェクト全体でカスケードされることが可能であるようにする。ＤＲＤのインプリメンテーションの一例では、オブジェクト、ＤｏｓｅＲａｔｅＤｏｃｕｍｅｎｔは、ｊａｖａｘ．ｓｗｉｎｇ．ｔｅｘｔ．ＰｌａｉｎＤｏｃｕｍｅｎｔを拡張して、要求されるメソッド、ｉｎｓｅｒｔＳｔｒｉｎｇ（ｉｎｔオフセット、Ｓｔｉｎｇ文字列、ＡｔｔｒｉｂｕｔｅＳｅｔ属性）をインプリメントする。このメソッドは、適宜、ＳｔｒｉｎｇＣｏｎｓｔｒａｉｎｔ．ｃｈｅｃｋＩｎｐｕｔ（Ｓｔｒｉｎｇ ｐｒｏｐｏｓｅｄＶａｌｕｅ）を内部で呼び出す。
【００４５】
Ｒｕｌｅ Ｓｅｔ Ｃｏｎｓｔｒａｉｎｔ（ＲＳＣ）が、薬剤量、希釈液量、ならびにハード限度およびソフト限度に関する特定のＤＲＤを提供する。ＲＳＣは、薬剤単位および投与量単位に基づき、それらの設定値を動的に変更して入力を検証するのに使用される。ＲＳＣは、いくつかの制約オブジェクトを集約して、エントリが、有効範囲内にあることを確認する。一例では、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度は、独自のＤＲＤおよびＣｏｎｓｔｒａｉｎｔオブジェクトを有するが、それぞれは、目標のニーズを満たすように独特である。ＲＳＣは、構築されると、規定の値で初期設定される。ｓｅｔＤｒｕｇＡｍｏｕｎｔＣｏｎｓｔｒａｉｎｔｓ（ｄｒｕｇＬａｂｅｌＰＫ）に対する連続的なコールにより、ｄｒｕｇＡｍｏｕｎｔＤＲＤが調整される。同様に、ｓｅｔＤｉｌｕｅｎｔＡｍｏｕｎｔＣｏｎｓｔｒａｉｎｔ（）に対するコールにより、ｄｉｌｕｅｎｔＡｍｏｕｎｔＤＲＤが調整される。本発明の一例では、唯一の制約は、ｄｉｌｕｅｎｔＡｍｏｕｎｔである。同様に、ｓｅｔＬｉｍｉｔＣｏｎｓｔｒａｉｎｔｓ（ｄｏｓｉｎｇＵｎｉｔＰＫ）に対する連続的なコールにより、限度量が調整される。
【００４６】
Ｒｕｌｅ Ｓｅｔ Ｄａｔａ Ｉｔｅｍ（ＲＳＤＩ）は、特殊化されたＤａｔａＩｔｅｍであり、データモデルとして作用する。Ｇｅｔｔｅｒ／Ｓｅｔｔｅｒが提供されて、ＲＶＤＣ（以下に説明する）、ＲＳＥ、およびＲＳＶ（以下に説明する）によって必要とされる様々な形態の属性を取得し、設定する。ＤａｔａＩｔｅｍは、自らをどのようにＳＱＬ Ｓｅｒｖｅｒデータベースの中に追加するかを知っている。本発明の一例では、ＲＳＶは、ＲＳＤＩのプライベートインプリメンテーションとしてではなく、静的オブジェクトとしてインプリメントされる。この責任分離により、ＲＳＶのインプリメンテーションおよび保持がより簡単になる。
【００４７】
Ｒｕｌｅ Ｓｅｔ Ｄａｔａ Ｍｏｄｅｌ（ＲＳＤＭ）は、インポートされているすべてのＲＳＤＩアイテムのための仮想データストアを提供する特殊化されたＡｂｓｔｒａｃｔＤａｔａＭｏｄｅｌである。
【００４８】
Ｒａｔｅ Ｖｅｒｓｕｓ Ｄｏｓｅ Ｃａｌｃｕｌａｔｉｏｎ（ＲＶＤＣ）が、患者の体重、薬剤濃度、その他などの変数の文脈において、所与の薬用量に対応する送達速度を計算する。一例では、ＲＶＤＣは、特定の輸液ポンプインプリメンテーションに結び付けられていない。また、一例では、ＲＶＤＣアルゴリズムは、純粋に代数的である。ＲＳＤＩは、ＲＳＶによって抽出され、ＲＶＤＣに送られて、ＤｏｓｅＦｒｏｍＲａｔｅまたはｃａｌｃｕｌａｔｅＲａｔｅＦｒｏｍＤｏｓｅが計算されるデータを所有する。
【００４９】
Ｒｕｌｅ Ｓｅｔ Ｖａｌｉｄａｔｏｒ（ＲＳＶ）は、すべての規則セットデータフィールドに関する検証プロセスを調整する。ＲＳＶは、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度によって必要とされる制約をリセットすることから始める。ＲＳＶは、各フィールドを準拠について、以下のとおり組織的に検証する。すなわち、
・長さは、０または空白であってはならず、最大長を超えてはならない。
・ピクセル長は、ポンプ上の表示可能な領域を超えてはならない。
・名前が、無効な文字に関して検査される。
【００５０】
ＲＳＶは、ユーザ入力、インポートされたライブラリ、１つの場所から別の場所にコピーされた薬剤を含め、異なるソースからの規則セットを検証するのに使用され、ＣＣＡ最大速度設定値に対する調整を行う。ＲＳＶは、システム全体で、規則セットが、形式が正しく、有効であり、ライブラリ全体に関する送達準拠に違反しないことを検証するのに、一貫して、常に使用される。ユーザが、規則に違反するデータを入力しようと試みた場合、ダイアログボックスの中の「保存」ボタンが、低輝度表示されて、ディセーブルにされ、ユーザが、規則に違反するデータを変更することを余儀なくされる。図１５Ａは、薬剤に関する規則セットを編集する際に使用されるダイアログボックスの例を示す図である。この例では、ユーザは、所望されるものを何であれ編集し、次に、「保存」ボタンをクリックする。エントリが有効ではなかった場合、「保存」ボタンは、低輝度表示され、ユーザは、変更を保存することを許されない。
【００５１】
図１６は、規則セットバリデータ判定ツリーの一例を示す。図１６に示された判定ツリーは、規則セット限度の有効性を評価するのに使用される基本的な論理を表す。一般に、判定ツリーは、規則セットが、「ＮＯＮＥ」、「ＦＵＬＬ」、または「ＬＩＭＩＴＥＤ」であるかどうかを尋ね、次に、判定ツリーの中で概要が述べられた他の質問を尋ねて、規則セットが有効であるかどうかを判定する。図１６は、ユーザが、規則セットを作成している間、または編集している間に、キーボード入力またはマウス入力を行うたびに行われる動的検査を示す。また、図１６は、ＲＳＶがどのように検査を行って、そのような送達速度／薬用量が、薬用量限度に基づいて許容できるかどうかを確かめるかも示す。また、最大速度ＣＣＡインフューザ設定値などの、他の設定値も同様の形で考慮に入れられる、または分析されることが可能である。
【００５２】
本発明の別の特徴は、Ｄａｔａ Ｍｏｄｅｌに関する。Ｄａｔａ Ｍｏｄｅｌは、データを薬剤ライブラリの中にインポートすること、ソースから宛先ＣＣＡライブラリにコピーすること、およびＣＣＡライブラリ内のＣＣＡ設定値を編集することに使用される。以下の図は、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間の関係、および高レベルの対話を示す。図２２は、ＤａｔａＭｏｄｅｌとＤａｔａＩｔｅｍの間の関係を示す。簡明にするため、ＣＣＡＳｅｔｔｉｎｇおよびＣＣＡＬｉｂｒａｒｙ ＤａｔａＭｏｄｅｌおよびＤａｔａＩｔｅｍは、図２２に示していない。図２３は、インポートプロセスとＲｕｌｅＳｅｔＤａｔａＩｔｅｍの間における高レベルの対話を示す図である。前述したとおり、インポートとＲＳＥの間で、いくつかの類似点が存在する。例えば、ＲＳＤＩが、ＲＳＶによって検証される。インポートプロセスは、タブ区切り値（ＴＳＶ）ファイルまたはカンマ区切り値（ＣＳＶ）ファイルを消費して、ＲＳＤＭオブジェクトを作成する。ＲＳＤＭは、Ｄｒｕｇ Ｌｉｂｒａｒｙエントリ、ＣＣＡエントリ、ＣＣＡ Ｌｉｂｒａｒｙ Ｖｉｅｗエントリ、およびＭａｓｔｅｒ Ｄｒｕｇ Ｆｏｒｍｕｌａｒｙ（ＭＤＦ）エントリを作成するのに使用される。図２４Ａおよび図２４Ｂは、規則セットが、目標からソースＣＣＡ Ｌｉｂｒａｒｙにコピーされる際の、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間における高レベルの対話を示す、２つの好ましいＵＭＬ図を示す。同様に、図２５は、ＣＣＡ Ｓｅｔｔｉｎｇが、目標ＣＣＡ Ｌｉｂｒａｒｙの中で編集される際の、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間における高レベルの対話を示す。
【００５３】
また、本発明は、Ｄｏｓｅ Ｒａｔｅ Ｅｄｉｔｏｒ（ＤＲＥ）と呼ばれる特殊化されたコンボボックスエディタも有する。ＤＲＥは、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度についてのＤＲＤを確立するのに使用される。ＤＲＥは、薬用量入力と予約語「Ｎｏｎｅ」の両方を特に考慮に入れているため、独特である。ＤＲＥは、０のすべての絶対値（例えば、「０」、「０．０」、「０．００」、「なし」、その他）を「Ｎｏｎｅ」に変換し、０ではない値に関するすべての後続の０または小数点を除去する。
【００５４】
前述したとおり、本発明は、ハード限度とソフト限度の両方を同時に使用することができる。さらに、様々な関連するレポートが、１つまたは複数の輸液ポンプから生成されることが可能である。１つのタイプのレポートは、ソフト限度オーバライドレポート（以下に説明する）である。以下は、ソフト限度オーバライドレポートがどのように生成されることが可能かの例である。ＳｏｆｔＬｉｍｉｔ Ａｌｅｒｔ／Ｏｖｅｒｒｉｄｅレポートのための永続ストレージ設計が、アップロードされたログの「保存」のための特定の要件と、生のログデータを解析して、臨床行為、部分的イベント、および重複ログエントリを明らかにする間接的な要件の両方によって推進される。一例では、すべてのログデータが、そのデータがアップロードされた源の輸液ポンプとの関連付けを保持する。
【００５５】
生のログデータは、アーカイブの目的とともに、ログ内容の直接報告（リスト表示（ｌｉｓｔｉｎｇ））をサポートするために保持される。保持に先立ち、生のログデータは、第１回の解析を受けて、ＰＣに既にアップロード済みであるが、輸液ポンプの中に格納されたままであった（アップロード後、ログがクリアされていないために）古いデータを表すログの部分が削除される。以下のデータベーステーブルが、解析されたログデータを保持するように定義される。
【表１】
リストアップされた最初の３つのテーブル、ＵｐｌｏａｄＨｉｓｔｏｒｙ、ＵｐｌｏａｄＥｖｅｎｔ、およびＥｖｅｎｔＴｙｐｅは、生のアップロードされたイベントデータを保持する既存の機能をサポートする。リストアップされた第４のテーブル、ＣｌｉｎｉｃａｌＡｃｔｉｏｎは、個別のイベント（Ｓｏｆｔ Ｌｉｍｉｔ Ａｌｅｒｔ／Ｏｖｅｒｒｉｄｅ）に関する必要なコンテキストを提供して、有意な役立つレポートを生成することを目的とする。
【００５６】
前述したテーブルのそれぞれの個々のフィールドを以下に示す。最初に、ＵｐｌｏａｄＨｉｓｔｏｒｙからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表２】
【００５７】
次に、ＵｐｌｏａｄＥｖｅｎｔからのフィールドを、それらのフィールドの目的とともにリストアップする。
【表３】
【００５８】
次に、ＥｖｅｎｔＴｙｐｅからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表４】
【００５９】
最後に、ＣｌｉｎｉｃａｌＡｃｔｉｏｎからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表５】
一例では、リストアップされたフィールドのすべてが必須であり、「空白でない」ように制約される。この例では、すべてのデータフィールドが、「利用不可」という値をサポートして、特定のフィールドが、イベントログから取り出されることが可能でなかったために（例えば、ログが３２１行を超えた場合の上書きに起因して）、全く値を有さないことを示す。以下の図は、Ｓｏｆｔ Ｌｉｍｉｔ Ａｌｅｒｔイベントまたはオーバライド臨床イベントをサポートするデータモデルを示す。図２６は、ソフト限度警報イベントまたはオーバライド臨床イベントをサポートするデータモデルを示す図である。
【００６０】
図７Ａは、１つのソフト限度オーバライドレポートの例を示す。図７Ｂは、図７Ａに示された見出しおよびデータの説明を含む。図７Ｃ〜図７Ｆおよび図８Ａ〜図８Ｄは、この例では、ドーパミン、ヘパリン、インスリン、およびバンコマイシンである、いくつかの異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す。図７Ｃ〜図７Ｆに示されたレポートは、出される警報のタイプ（ハード下限、ソフト下限、ソフト上限、ハード上限）、ならびに各警報が出された回数をリストアップする。出される各タイプの警報に関して、レポートは、ユーザが、警報にどのように応答したかに関連する統計も示す。この例では、レポートは、警報がオーバライドされたまたはオーバライドされなかった回数を示す。さらに、情報のエントリを確認するように求められた際に、ユーザによって「いいえ」が入力された回数も示す。図８Ａ〜図８Ｄは、警報レポートおよびオーバライドレポートの別の例を示す。図８Ａ〜図８Ｄに示されたレポートは、各警報が、ＣＣＡ（この例では、ＩＣＵおよびＭｅｄＳｕｒｇ）によって隔てられていることを除いて、図７Ｃ〜図７Ｆに示されるレポートと同様である。以上の例から、任意の所望の情報が、本発明によって収集され、報告されることが可能であることが明白である。
【００６１】
本発明の１つの利点は、ハード限度とソフト限度の両方が、各薬剤に関して与えられることが可能であり、いずれの薬剤／ＣＣＡの組み合わせにも、１つ、２つ、３つ、または４つの限度が割り当てられることが可能なことである。ハード限度とソフト限度の両方を与える能力が存在する場合、使用されることが可能な限度の１６の組み合わせが存在する。４つの限度のそれぞれが、ある限度を指定する値を含むこと、または「限度」が、無制限（適切なフィールド内の「なし」によって示される）であることが可能である。それらの２つの可能性は、各限度に関して、すなわち、ハード下限、ソフト下限、ソフト上限、およびハード上限）に関して）存在する。この特徴は、ユーザが、ハード上限だけ、ハードとソフトの上限と下限、ハード上限およびソフト上限（下限なし）、ハード下限およびソフト下限（上限なし）、その他などの、様々な組み合わせでデバイスを構成することを可能にする。２つのセットの上限と下限の例では、構成の１６の可能な組み合わせが存在する。さらなる限度セットが使用される場合、より多くの組み合わせが可能である。一実施形態では、ハード限度は、ユーザによって無効にされることが可能でない、選択された薬剤、および選択されたＣＣＡに関する薬用量上限／薬用量下限である。別の実施形態におけるハード限度は、管理上の（ｓｕｐｅｒｖｉｓｏｒｙ）オーバライドを要求するか、または許すことが可能である。ハード限度、権限レベル、およびオーバライド可能性は、薬剤ライブラリ内の各薬剤に関して、病院によって定義される。特定の薬剤に関するハード限度は、割り当てられている場合、異なるＣＣＡにわたって異なる可能性がある。
【００６２】
一実施形態では、ソフト限度は、ユーザによって無効にされることが可能な、選択された薬剤、および選択されたＣＣＡに関する薬用量上限および／または薬用量下限である。特定の薬剤に関するソフト限度は、割り当てられている場合、ＣＣＡにわたって異なる可能性がある。ソフト限度に達した場合、警報または警告をトリガする規則セットが、薬剤ライブラリに関して提供される。警告は、操作者の側で、明確なオーバライドステップを要する。同様に、ユーザが、プログラミングすることを許される送達速度の範囲に対するハード限度を与える規則セットが、薬剤ライブラリに関して提供される。例えば、ソフト下限が、毎時１０ｍＬに設定され、臨床家が、毎時９ｍｌを入力した場合、インフューザは、ソフト限度オーバライド警報を表示する。インフューザの履歴ログの中に記録されるこの警報は、そのエントリが、その薬剤エントリに関して設定されたソフト限度の範囲外であることを臨床家に通知する。臨床家は、オーバライドを使用して、プログラミングを続けることを選択すること、またはオーバライドを取り消して、別の値を再入力することができる。臨床家が、ソフト限度を無効にすることを選択した場合、そのイベントが、インフューザの履歴ログの中に別個に記録される。ハード限度およびソフト限度は、他の様々な薬剤パラメータに関して設定されることが可能である。例には、投薬速度、薬剤送達時間、薬剤濃度、患者の体重、輸液されるべき量（ＶＴＢＩ）、その他が含まれる。
【００６３】
ハード限度および／またはソフト限度の別の用法は、正しいデータ入力に関する。例えば、時間エントリに対してハード限度を設定して、ユーザが、０から５９までの間の値だけを入力することができるようにすることが可能である。この例では、システムは、データ入力エラーに気付き、有効な範囲内の値を入力するようにユーザに強制する。別の例では、様々な薬剤フィールドに関して、一部の値または範囲だけが、入力されることを許される。１５Ｂは、薬剤単位フィールド、薬剤量フィールド、希釈液量フィールド、送達薬用量／速度単位フィールド、ならびにハード限度フィールドおよびソフト限度フィールドに関して入力されることが可能な値の例を示す。ユーザが他の値を入力することを試みる場合、システムはユーザに有効なフィールドを入力させ、または警報またはアラームを発する。
【００６４】
また、本発明は、１つのコンピュータから別のコンピュータへの薬剤ライブラリのインポートおよびエクスポートも可能にする。ライブラリがインポートされることが可能になるには、まず、ライブラリが、エクスポートされなければならない。一般に、薬剤ライブラリは、事前定義されたフォーマットを有する完成した薬剤ライブラリ（ＦＤＬ）にエクスポートされることが可能であり、そのフォーマットは、ライブラリを、ライブラリが、アクティブライブラリとしてインポートされ、設定されることが可能な他のコンピュータに、安全で、セキュリティで保護された形で移植可能にする。例えば、アクティブライブラリを有する第１のＰＣに関して、ライブラリは、バイナリフォーマットにエクスポートされ、ライブラリがインポートされる第２のＰＣに移されることが可能であり（ネットワーク、コンピュータ可読媒体、その他を介して）、したがって、第１のＰＣと第２のＰＣにおけるライブラリが同期される。特別ファイル拡張子（ＦＤＬ）、ならびにコンピュータ間におけるソフトウェアによる認識が、要求される。
【００６５】
ＦＤＬがエクスポートされると、薬剤ライブラリ全体がまず、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャ（以下を参照）を使用して、データベースから「選択される」。そのプロシージャは、実際、いくつかの選択ステートメントを含み、１つのテーブル当たり１つのステートメントを含む。テーブルは、コピー用のテーブルと同一である。各テーブルに関して、エクスポートメソッドが、テーブル名、行と列の数をシリアル化し、次に、各行が、列ごとにシリアル化される。元のデータベースインデックス値がシリアル化されることに留意されたい。ライブラリが、ファイルから読み取られると、インデックス値は、もはや有効ではないが、あたかもライブラリがコピーされたかのように同一に、マップされなければならない。一例では、ＦＤＬファイルは、「読み取り専用」ファイルである。ＦＤＬファイルは、Ｊａｖａ（登録商標）シリアル化フォーマットであるので、ＦＤＬファイルは、通常のソフトウェアアプリケーションを使用して、ユーザによって容易に変更されない。この特徴は、シリアル化を使用することの理由の一部であり、つまり、ユーザが、完成した薬剤ライブラリを改ざんするのをやめさせるためである。
【００６６】
ＦＤＬがインポートされると、最初に、すべてのシリアル化された情報が、３次元アレイの形態でメモリに読み込まれる。テーブルに関する１つの次元、行に関する１つの次元、および列に関する１つの次元の、３つのアレイ次元が存在する。行の次元のサイズ、および列の次元のサイズは、各テーブルに関して異なることが可能である。この「生の」データが、テーブルごと、行ごとにデータベースに挿入される。また、インデックスマッピングも、途中で実行されることが可能である。次に、行が挿入されると、新たなインデックス値が生成されて、コピー操作中に行われるのと同様に、マップの中に格納される。一部のテーブルは、他の、以前に挿入されたテーブルに対するインデックスを含むことが可能である。それらのインデックスは、生成されたマップを使用して、元の値から新たな値に変換される。それらの変換されたインデックス値は、新たな行に挿入される値である。ＦＤＬは、データベースの中に格納された後、Ｆｉｎａｌｉｚｅｄ Ｄｒｕｇ Ｌｉｂｒａｒｙとなり、別のＦｉｎａｌｉｚｅｄ Ｄｒｕｇ ＬｉｂｒａｒｙをＡｒｃｈｉｖｅｄライブラリにする。
【００６７】
以下は、いずれの順序でテーブルがアレイの中に格納されているか、インデックス依存関係は、どのようなものか、いずれの列をマップの中に格納するか、いずれの列値が、挿入されることが可能になるには、まず、新たな値にマップされる必要があるか、その他をＦＤＬインポートに知らせる、ＦＤＬＤａｔａ．ｊａｖａの説明である。
【００６８】
薬剤ライブラリをコピーする場合と同様に、ＦＤＬインポート中にテーブルが処理される順序が重要であることを認識することが重要である。その順序は、列挙された定数としてＦＤＬＤａｔａ．ｊａｖａファイルの中に符号化される。以下は、そのような列挙された定数の例である。すなわち、
【数７】
【００６９】
以上の定数は、前述した生のデータの３次元アレイへのインデックスとして使用されることが可能である。また、このコードセクションは、データベーススキーマに変更が行われた場合、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌによって生成されることも可能である。
【００７０】
エクスポート／インポートされる各テーブルに関して、テーブル名、列の数、他のテーブルが依存する可能性がある列が存在するとすれば、列のいずれか（ｉｄＣｏｌｕｍｎ）、および最後に、そのテーブルが依存するテーブルに対するインデックスセットを常に把握しているＴａｂｌｅＩｎｆｏのインスタンスが存在する。「ｉｄＣｏｌｕｍｎ」は、指定されている場合、行が挿入されるにつれ、そのテーブルの各行に関するデータベースによって生成される。古い値（シリアル化されたファイルからの）と新たな値（データベース行挿入からの）が、インデックスマップの中に格納される。次に、古いインデックスを参照する他のすべてのメモリ内テーブルが、新たなインデックスを含むように更新されてから、行が挿入される。例えば、以下に示されるＲｕｌｅＳｅｔテーブルの「ｉｄＣｏｌｕｍｎ」は、そのテーブルのＲｕｌｅＳｅｔＩＤ列であり、ＲｕｌｅＳｅｔＩＤ列は、偶然、ＴａｂｌｅＩｎｆｏテーブルの中の第２の列である。このため、ＲｕｌｅＳｅｔに関するＴａｂｌｅＩｎｆｏインスタンスにおける「ｉｄＣｏｌｕｍｎ」は、１（第１の列は、０、第２の列は、１，．．．）である。次に、ＦＤＬがエクスポートされた際、ＲｕｌｅＳｅｔＩＤが５０４７であったＲｕｌｅＳｅｔテーブルの中の行が存在していたものと想定されたい。すなわち、
【表６】
ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙテーブル（以下に示す）はそれぞれ、ＲｕｌｅＳｅｔ依存関係、つまり、それぞれのＲｕｌｅＳｅｔＩＤ列を有する。
【表７】
次に、ＦＤＬがインポートされる際、ＲｕｌｅＳｅｔテーブル（以下に示す）のその特定の行に、５１２２という新たなインデックス値が与えられるものと想定されたい。
【表８】
後に、ＣｃａＬｉｂｒａｒｙテーブルまたはＤｒｕｇＦｏｒｍｕｌａｒｙテーブルが挿入される前に、５０４７のあらゆるＲｕｌｅＳｅｔＩＤ値がまず、５１２２に変更される。１という「ｉｄＣｏｌｕｍｎ」設定値が、５０４７−５１２２マッピングを格納するようにＦＤＬインポートコードに告げる。
【表９】
ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙテーブルの中の５０４７値が、依然としてメモリの中に、つまり、生のデータの３次元テーブルの中にある間に、５１２２に変更される。それらのテーブルが処理された後、ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙＩＤテーブルが、以下に示される。
【表１０】
【００７１】
ＦＤＬＤａｔａ．ｊａｖａファイルを再び参照すると、ファイルの様々なセクションが、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルによって自動的に生成される。それらのセクションは、そのファイルの出力からｊａｖａコードにカットアンドペーストが行われることが可能である。具体的には、テーブル順序定数（以上に示す）、ならびにＴａｂｌｅＩｎｆｏアレイおよびそのアレイの内容が、データベーススキーマ変更のイベントにおいて生成されることが可能である。
【００７２】
また、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルは、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャ（以下に説明する）の大部分も同時に生成する。この場合も、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルが生成するＳＱＬコードは、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ．ｓｑｌファイル内の適切な場所にカットアンドペーストが行われることが可能である。
【００７３】
ＦＤＬがエクスポートされる際、ライブラリを構成するデータが、データベースから獲得される（そのデータが、ファイルにシリアル化されることが可能であるように）。ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャが、それを行う。プロシージャは、いくつかの選択ステートメントを利用し、テーブルを特定の順序で選択し、任意の所与のテーブルの列を特定の順序で選択する。
【００７４】
テーブルの順序、およびそれらのテーブル内の列の順序は、薬剤ライブラリを再構築するＦＤＬインポートコードに重要であるので、ＦＤＬエクスポート、ＦＤＬインポート、およびＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙコードが、互いに同期して保たれることが不可欠である。データベーススキーマのほんのわずかな変更も、ＦＤＬＤａｔａ．ｊａｖａおよびＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ、ならびにＣｏｐｙＤｒｕｇＬｉｂｒａｒｙ格納プロシージャの変更を余儀なくさせる。ほんのわずかな誤り（不一致）によっても、適切に機能しなくなる。
【００７５】
ＣｏｐｙＤｒｕｇＬｉｂｒａｒｙコードを除いて、ｊａｖａ変更およびＳＱＬ変更のほとんどは、新たなスキーマが配備された後、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルを実行することによってもたらされることが可能である。それらのファイルの中の一致する／類似のコードの上に、生成されたコードを単にカットアンドペーストする。また、ＣｏｐｙＤｒｕｇＬｉｂｒａｒｙコード変更も、自動化されることが可能である。
【００７６】
本発明の１つの特徴は、データが、システムにインポートされること、およびシステムからエクスポートされることが可能なことである。カンマ区切り値（ＣＳＶ）またはタブ区切り値（ＴＳＶ）を使用するライブラリテキストファイルが、システムによってインポートされることが可能である。１つの独特な特徴は、ファイル全体が、前述したＲＳＶ検査に合格しなければならず、さもなければ、インポート全体が、無効と見なされることである。
【００７７】
本発明は、様々なポンプまたは医療デバイスに適用可能であり、本明細書で本発明を説明するのに使用されているポンプに限定されないことが当業者には認識されよう。さらに、本発明を逸脱することなく、ポンプとコンピュータの間における接続は、無線であることも、有線であることも可能であることが当業者には認識されよう。無線通信エンジンが、ポンプおよびコンピュータに接続され、ＢＬＵＥＴＯＯＴＨ（商標）（ＩＥＥＥ８０２．１５）、あるいはＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｂ、およびＩＥＥＥ８０２．１１ｇに記載されるような他のプロトコルなどの、通信プロトコルを利用する無線ネットワークを使用することが可能である。無線ネットワーク内の通信は、無線周波数電磁放射、赤外線放射、またはネットワーク要素間で無線通信を達するための他の手段を利用することができる。
【００７８】
一例では、プラグアンドプレイモジュール４が、無線通信エンジンまたは無線接続エンジンを収容する、または入れることができる。医療ポンプのための従来の無線通信モジュールは、最適な送受信のために、外部プラグイン、ボルト留めタイプであった。それらの従来の通信モジュールは、ポンプのために要求される空間を大幅に大きくし、ポンプの外形を変える。それらのモジュールは、ポンプが落とされた場合、損傷を受ける、または外れる可能性がある。さらに、他の医療機器に対する干渉の可能性を防止するように、医療機器からの最大電気放射に関する厳格な標準が存在する。本発明の無線プラグアンドプレイモジュール４は、ポンプによって占有されるスペースを大幅に大きくしない。以下に説明する、改良されたアンテナ設計で、ポンプ筐体２内部にプラグアンドプレイモジュール４を配置することにより、依然として、良好な位置／向きの許容度の大きい（ｐｏｓｉｔｉｏｎ／ｏｒｉｅｎｔａｔｉｏｎ ｔｏｌｅｒａｎｔ）送受信特性がもたらされ、デバイスからの電子放射が低下して、よりよく制限されるという意外な結果がもたらされる。
【００７９】
前述したとおり、本発明の輸液ポンプは、他の様々なデバイスに接続されることが可能である。一例では、本発明は、接続エンジンを使用して、ポンプが、様々な他のデバイスに接続することを可能にすることに加えて、システム機能を提供する。以下は、本発明で使用されることが可能な接続エンジンの一例である。前述した例では、様々な特徴および能力が、所望に応じてカスタマイズされることが可能である。
【００８０】
接続エンジンは、重要なシステム機能を提供すること、ならびに有線通信リンクと無線通信リンクの両方を介して、薬物管理ユニット（ＭＭＵ）、病院情報システム（ＨＩＳ）、薬局情報システム（ＰｈＩＳ）、およびその他の医療情報システムを含む様々な外部システムに、インフューザが接続することができるようにすることを目的とする、インフューザの筐体内部のアセンブリである。接続エンジンは、エンジンの印刷配線アセンブリ上のデータバスおよびアドレスバスを介して、基板−基板コネクタを介して、ＣＰＵ印刷配線アセンブリとインタフェースをとることができる。一例では、接続エンジンは、インフューザＣＰＵ印刷配線アセンブリのために、約１〜２メガバイトの読み取り専用プログラムと、１メガバイト以上の読み取り／書き込みデータメモリとをサポートする。接続エンジンは、インフューザユニットの後部上で外部に位置するシリアルデータポートを介して、ホストコンピュータと通信することができる。一例では、データポートは、電気的に絶縁される。
【００８１】
この例では、接続エンジンは、ユニットの後部上で外部からアクセス可能な、フロントパネルロックアウトスイッチを含む。また、接続エンジンは、ユニットの後部上で外部に位置する看護士呼び出しインタフェースも含むことが可能である。看護士呼び出しインタフェースは、患者が、アラームメッセージを看護士に送ることを可能にする、患者によって保持されるスイッチなどの、看護士呼び出しデバイスとともに使用されることを許す。また、接続エンジンは、器具の背後からアクセス可能なアラーム音量コントロールも含むことが可能である。このコントロールは、エラー、警告、その他をユーザに知らせる可聴アラームに関する音量レベルを調整する。
【００８２】
接続エンジンは、インフューザと外部システムの間で双方向通信を確立する目的で、様々な外部システムに対するインフューザの相互接続をサポートすることができるモジュール型のインテリジェントな印刷配線アセンブリである。外部システムの例には、薬物管理ユニット（ＭＭＵ）、医療情報システム、ＨＩＳ、および外部無線アクセスポイントが含まれることが可能である。外部システムのその他の例には、薬剤ライブラリおよびソフトをインフューザにダウンロードするため、およびインフューザからログをアップロードするための、１つまたは複数のＰＣが含まれる。
【００８３】
前述したとおり、本発明は、有線通信と無線通信の両方が可能である。サポートされることが可能な有線インタフェースの例には、イーサネット（登録商標）の１０ＢａｓｅＴおよび１００ＢａｓｅＴの標準、ならびにメガビットインタフェースおよび光ファイバインタフェースが含まれる。サポートされることが可能な無線インタフェースの例には、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ、ならびに他のあらゆる所望されるインタフェースが含まれる。接続エンジンは、ＸＭＬサービス、ＨＴＭＬサービス、ｆｔｐサービス、およびＴｅｌｎｅｔサービスを含め、様々なネットワークプロトコルをサポートすることができる。
【００８４】
一例では、本発明は、通常、有線インタフェースか、または無線インタフェースを使用して動作する。別の実施形態では、本発明は、有線インタフェースと無線インタフェースの両方を同時に使用することができる。その例では、いずれかのモードで障害が検出された場合、すべての通信が、機能しているモードに自動的に切り替わることが可能である。
【００８５】
接続エンジンハードウェアは、所望される機能および能力に依存して、多くの形態をとることができる。一例では、接続エンジンは、以下のサブ回路を含む。すなわち、ＣＰＵメモリ、つまり、ＲＡＭおよびフラッシュ、外部シリアルインタフェース、看護士呼び出しインタフェース、オーディオ音量コントロール、ロックアウトスイッチ、接続エンジンコントローラ、イーサネット（登録商標）インタフェース、無線インタフェース、およびアンテナアセンブリである。また、以下の外部コネクタも、含まれることが可能である。すなわち、イーサネット（登録商標）ＲＪ−４５コネクタ、Ｗｉ−Ｆｉトランシーバをアンテナ印刷配線アセンブリに接続するためのＲＦコネクタ、ＲＳ２３２シリアルポートＤＢ９コネクタ、および看護士呼び出しインタフェースコネクタである。
【００８６】
図９〜図１１は、本発明で使用されることが可能な、取り外し可能なプラグアンドプレイモジュールではなく、ポンプ筐体内部に完全に密閉された例示的な接続エンジンのブロック図である。図９は、ユニバーサルシリアルバス（ＵＳＢ）を介して接続エンジン２２に接続されたユーザインタフェースコントローラ（ＵＩＣ）２０を示す。もちろん、他のインタフェースも使用されることが可能である（例えば、ＲＳ２３２シリアルインタフェース、パラレルインタフェース、その他）。接続エンジン２２は、イーサネット（登録商標）接続およびＷｉＦｉ接続を有する、図９に示された入出力基板である。図１０は、プロセッサ２４を含む接続エンジンのブロック図である。プロセッサ２４は、イーサネット（登録商標）トランシーバ２６およびトランス２８に接続されて、１つまたは複数のＰＣ１０と通信するイーサネット（登録商標）インタフェースをもたらす。また、このインタフェースは、無線で提供されることも可能である。プロセッサは、ＵＳＢコントローラ３０にも接続される。ＵＳＢコントローラ３０は、ＵＳＢインタフェースを介して、ＵＩＣ ＵＳＢクライアント３２およびＲＦトランシーバ３４に接続される。
【００８７】
２つのアンテナ３６および３８を有するＲＦトランシーバ３４が示されている。本発明は、１つだけのアンテナを含んでもよいが、２つのアンテナが、本発明の性能を向上させることができる。本発明と他のデバイスの間の通信は、クリティカルである可能性があるので、可能な最も信頼できる無線通信を提供することが望ましい。２つのダイバース（ｄｉｖｅｒｓｅ）アンテナが、本発明の無線通信カバレッジを最適化する。本発明は、２つの異なるダイバーシチスキーム、空間ダイバーシチ、およびパターンダイバーシチの組み合わせを使用する。従来、空間ダイバーシチでは、２つの同一のアンテナが、２つの別個の場所に配置されて、共通の受信機にダイバーシチ受信をもたらす。そのケースでは、スキームは、アンテナを物理的に分離するだけでなく、２つのアンテナを直角に配置することにより、パターンダイバーシチも実現する。このようにして、１つのアンテナにおけるピークが、他方のアンテナのゼロ（ｎｕｌｌ）を埋めて、複合アンテナ指向性図（ｃｏｍｂｉｎｅｄ ｒａｄｉａｔｉｏｎ ｐａｔｔｅｒｎ）が、単一のアンテナだけよりも、より全方向性に見えるようにする。このアンテナダイバーシチスキームは、いくつかの目的を達する。第１に、外部からそれほど明らかでないアンテナを有することが望ましく、内部に組み込まれたアンテナを使用することが望ましくなる。第２に、ほとんどのアプリケーションにおいて、本発明は、デバイスが放射することができる放射の量を制限する、ＩＥＣ６０６０１−１−２、２ｎｄ Ｅｄｉｔｉｏｎ標準で指定されるＥＭＣ要件を満たさなければならない。２つのダイバースアンテナの使用は、以上の目的を達するのに役立つ。一例では、本発明で使用されるアンテナは、輸液ポンプの筐体内部に密閉される。これは、ほこり、有害な溶媒、およびごみをアンテナに近づけないようにするのに役立ち、放射の制限を強化するとともに、アンテナの損傷の可能性を低くする。
【００８８】
別の例では、接続エンジンは、情報を一時的に格納するためのキャッシュとして使用されるメモリを含む。キャッシュは、システムをより効率的に、より信頼できる形で機能させることができる。
【００８９】
図１１は、図１０に示される無線インタフェースのブロック図であり、ホストコンピュータと通信するためのＵＳＢインタフェースを含むベースバンドプロセッサ−媒体アクセスコントローラ４０を示す。プロセッサ４０は、変調器／復調器４２、ＲＦ／ＩＦ変換器４４、および電力増幅器４６に接続される。アンテナ３６および３８が、電力増幅器４６およびＲＦ／ＩＦ変換器４４によって駆動される。
【００９０】
図１２Ａ〜図１５Ａは、Ａｂｂｏｔｔ ＰＬＵＭ Ａ＋（登録商標）インフューザに適用された、本発明の一例の電子システム図である。図１２Ａ〜図１２Ｄは、ＣＰＵ、および通信エンジンまたは接続エンジンを示す。通信エンジンは有線または無線のインタフェースを介した他のデバイスとの通信を容易にする。通信エンジンは、図９〜図１１に関連して前述したのと同一の直角に配置されたアンテナを利用することができる。また、図１２は、スイッチおよびユーザコントロール、看護士呼び出しジャック、キーパッド、アラームスピーカ、ＬＥＤ、その他などの、様々なコンポーネントとインタフェースをとるためのデジタルＩ／Ｏチップも示す。図１３は、電源回路および絶縁バリアを含む、電源サブシステムを示す。図１４は、圧力センサ、空気センサ、モータ位置センサ、およびモータドライブを含む、機構サブシステムを示す。
【００９１】
図１７は、患者自己管理鎮痛（ＰＣＡ）ポンプの電子システムブロック図である。図１８および図１９は、図１７に示されるＰＣＡポンプで使用されることが可能な接続エンジンの電子システムインタフェースブロック図である。図１７は、システムに電力を供給する電源を含む。マイクロコントローラが、キーパッド、患者ペンダント、シリアルポート、バーコード読み取り装置、様々なセンサ、様々なスイッチ、モータドライブ、ディスプレイおよびＬＥＤインジケータ、ならびにスピーカを含め、システムの様々なコンポーネントとインタフェースをとる。
【００９２】
図１８は、図１７に示されるＰＣＡシステムで使用されることが可能な接続エンジンのブロック図である。図１８は、接続エンジンと、イーサネット（登録商標）、ＷｉＦｉ、外部ＲＳ２３２シリアルインタフェース、ならびにホストデバイスに対するＲＳ２３２シリアルインタフェースを含む、いくつかのインタフェースとを示す。また、図１８は、接続エンジンが、ＰＣＡポンプ（図１７）から電源をとることができる（電源コネクタを介して）接続エンジンも示す。ＰＣＡポンプは、様々なモータに電力を供給するためのモータ電圧ＶＭＯＴを生成する。同一の電圧ＶＭＯＴを使用して、接続エンジンに電力が供給されることが可能である。
【００９３】
図１９は、図１８の接続エンジンのより詳細なブロック図である。接続エンジンは、イーサネット（登録商標）プロセッサと８０２．１１ｂ無線トランシーバをともに組み込んだ有線／無線接続モジュールである、接続エンジンコントローラ（ＣＥＣ）を含む。イーサネット（登録商標）トランシーバ、およびすべての必要な回路は、ＲＪ−４５ジャックを介して１０／１００Ｂａｓｅ Ｔインタフェースを提供する。ＵＳＢコントローラ、およびすべての必要な回路が、ＷｉＦｉに対するＵＳＢ（ホスト）インタフェースを制御する。２つのＲＳ２３２ポートが、システムバスに接続される。また、接続エンジンは、ＦＬＡＳＨメモリおよびＳＤＲＡＭメモリも含む。
【００９４】
以上の詳細な説明では、本発明を、本発明の特定の例示的な諸実施形態に関連して説明した。特許請求の範囲に記載される本発明のより広い範囲を逸脱することなく、それらの実施形態に様々な改変および変更が行われることが可能である。したがって、本明細書および図面は、制限的ではなく、例示的であると見なされるべきである。
【技術分野】
【０００１】
本発明は、概ね、薬物投与デバイスまたは薬物送達デバイスに関する。より詳細には、本発明は、薬剤情報または薬物情報を保持するため、コンピュータと１つまたは複数の輸液ポンプの間で通信を提供するため、ならびにそのような情報および通信の整合性を保証するための新規なシステムに関する。
【背景技術】
【０００２】
患者の循環系に直接に薬物、およびその他の液体を投与することが望ましい場合、静脈内輸液療法が処方される。臨床行為が意図していたよりも高い、または低い投与量がプログラミングされていることを臨床家に警告する警報がなかったなら、患者に送達される結果の量が、疾病率（ｍｏｒｂｉｄｉｔｙ）の増加をもたらす、または致命的となる可能性がある。薬用液体を患者の身体に輸液するのに医療スタッフ（ｍｅｄｉｃａｌ ｐｅｒｓｏｎｎｅｌ）によって使用される、様々なタイプの輸液ポンプが存在する。薬剤用量プログラミング警報の機能を有するポンプは、ほとんど存在しない。一部のポンプは、電子的にダウンロード可能な薬剤ポンプのためのカスタマイズされた薬剤ライブラリを使用する。例えば、参照により全体が本明細書に組み込まれている米国特許第６２６９３４０号が、カスタマイズされた薬剤ライブラリを策定して、パーソナルコンピュータ（ＰＣ）から、注射ポンプの筐体内部の消去可能な、電子的に読み込み可能なメモリの中にダウンロードするためのシステムおよびコンピュータ可読媒体を説明している。しかし、先行技術のシステムおよび輸液ポンプは、いくつかの欠点を有する。以下は、先行技術において見られる様々な問題を解決する斬新な輸液ポンプシステムの説明である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許第６２６９３４０号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、１つまたは複数の薬物投与デバイスまたは薬物送達デバイスと通信するためのシステムに関する。より詳細には、本発明は、リモートコンピュータ、ならびにコンピュータ可読媒体上のソフトウェアプログラムを利用して、スタンドアロンベースで、または統合された薬物管理システムの一部として、１つまたは複数の輸液ポンプに情報をダウンロードし、および／または１つまたは複数の輸液ポンプから情報をアップロードするシステムに関する。
【課題を解決するための手段】
【０００５】
一例では、ソフトウェアは、生物工学技師、薬剤師、医師、その他を含むが、以上には限定されないユーザによって使用されることが可能である、強力な薬剤ライブラリ作成能力、薬剤ライブラリ編集能力、および薬剤ライブラリアーカイブ能力をリモートコンピュータに提供する。各薬剤エントリが、関連するＣＣＡ指定を有する単一の薬剤処方集ワークシートまたは薬剤処方集データベースが、医療施設全体のために作成されることが可能である。同一の薬剤に、異なる臨床看護領域において異なる限度が確立されていることが可能であり、特定の臨床看護領域に関して医療施設の推奨される最良の慣行に依存して、異なるデバイスパラメータ、および異なるデバイス設定値が適用される可能性がある。単一の薬剤処方集ワークシートは、各臨床看護領域に関して別個のデータベースまたはサブデータベースより、管理し、更新し、保持するのがより容易である。ソフトウェアの一例では、ソフトウェアは、ユーザがデータをキー入力するにつれ、各キー入力とともに、薬剤処方集ワークシートへの入力を動的に検証するリアルタイムの規則セットバリデータ（ｖａｌｉｄａｔｏｒ）を提供する。ユーザは、値が、許容される範囲を超えた場合、またはデータが、所定の予期される特徴を満たさない場合、即時に通知を受ける。一例では、ソフトウェアは、薬物送達デバイスと通信するために、拡張マークアップ言語も使用する。コンピュータとデバイスの間の通信は、巡回冗長検査などの、任意の所望の技術を使用して検証されることが可能である。別の例では、データベースを使用して、複数の輸液ポンプの履歴が格納される。これにより、１つのデータベースの中で１つの機関におけるすべてのポンプからイベントログデータを取り出す能力が可能になり、使用の場所、時刻、誤りのタイプ、その他に基づき、データを取り出すことができる。他のタイプのリポートも可能である。
【０００６】
ソフトウェアは、一例では、コンピュータを利用して、１つまたは複数の薬剤送達デバイス（輸液ポンプなどの）に情報をダウンロードし、および１つまたは複数の薬物送達デバイス（輸液ポンプなどの）から情報をアップロードするシステムの一部分として役立つ。一実施形態では、システムは、ソフトウェアを格納するためのメモリ、ユーザインタフェース、およびディスプレイを有するリモートパーソナルコンピュータ（ＰＣ）を含む。また、システムは、１つまたは複数の輸液ポンプ、ならびに、ＰＣをポンプに接続して、ＰＣとポンプの間における情報の通信を円滑にするための１つまたは複数の技術も含む。輸液ポンプは、薬物（すなわち、液体、薬物、またはそれらの混合物）を患者に送達するための単一のチャネルを有することも、複数のチャネルを有することも可能である。一例では、ポンプにダウンロードされる情報には、限定としてではなく、１つまたは複数の薬剤エントリが、通常、臨床看護領域別にグループ化されている薬剤ライブラリ、薬剤送達パラメータ（ハード限度およびソフト限度）、デバイス設定値、デバイスパラメータ、またはデバイス限度、患者識別データなどの患者固有の情報、看護者ＩＤ（ｃａｒｅｇｉｖｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などの看護者固有の情報が含まれることが可能である。
【０００７】
一例では、ソフトウェアおよび通信プロトコルは、異なるバージョン、異なるモデル、および異なるタイプの薬物送達デバイスに適用可能なオープンアーキテクチャを利用する。本発明の一実施形態では、ソフトウェアは、情報をダウンロードするため、およびアップロードするために、複数の汎用輸液ポンプと有線通信を確立するシステムにおいて利用される。他の諸実施形態では、ソフトウェアは、情報をダウンロードするため、およびアップロードするために、ポンプ筐体内部に設置されたプラグアンドプレイ（ｐｌｕｇ ａｎｄ ｐｌａｙ）通信モジュールを有する１つまたは複数の汎用輸液ポンプと無線通信を確立するシステムにおいて利用される。他の諸実施形態では、プラグアンドプレイ通信モジュールは、ポンプ筐体内部に密閉されたオプションの回路基板上に一体化して組み込まれる。薬物送達デバイスの例には、単一チャネルまたは複数チャネルの汎用輸液ポンプ、患者自己管理鎮痛（ｐａｔｉｅｎｔ ｃｏｎｔｒｏｌｌｅｄ ａｎａｌｇｅｓｉａ）（ＰＣＡ）ポンプ、歩行（ａｍｂｕｌａｔｏｒｙ）ポンプ、経腸ポンプ、ＩＶ輸液ポンプ、その他が含まれていたが、以上には限定されない。
【０００８】
また、ソフトウェアは、薬物管理ユニットまたは薬物管理サーバとインタフェースをとる、あるいはそのようなユニットまたはサーバとして動作するコンピュータ上でも役立つ。その例では、ソフトウェアは、患者エリアネットワーク（ＰＡＮ）内で、ＰＣと１つまたは複数の薬剤送達デバイスの間における通信を円滑にする。ＰＣとデバイスの間の通信がどのような目的で使用されることが可能であるかの例には、薬物送達デバイスを動作させるため、および制御するための患者固有の薬剤送達命令をダウンロードすること、ならびにデバイス特性、条件、使用履歴、および警報履歴などの情報をアップロードすることが含まれるが、以上には限定されない。
【０００９】
本発明が、例として、限定としてではなく、同様の符号が同様の要素を示す、添付の図面の図に示されている。
【図面の簡単な説明】
【００１０】
【図１Ａ】本発明による輸液ポンプの正面図である。
【図１Ｂ】図１の輸液ポンプの背面図である。
【図１Ｃ】図１の輸液ポンプの背面透視図であり、ポンプとコンピュータの間の通信を円滑にするプラグアンドプレイモジュールを示す。
【図１Ｄ】ＣＤ−ＲＯＭディスク、または本発明によるコンピュータ可読媒体の可能な一実施形態を示す正面透視図である。
【図１Ｅ】接続箱への接続を介して、複数のポンプをコンピュータと通信するようにさせるのに使用されることが可能なデータケーブルの透視図である。
【図１Ｆ】プラグアンドプレイモジュールをコンピュータに接続し、他のポンプと互いに接続するためのデュアルジャック付き（ｄｕａｌ ｊａｃｋｅｄ）接続箱ケーブルの透視図である。
【図１Ｇ】接続箱上のデュアルジャックの１つにコンピュータを接続するためのデータケーブルの透視図である。
【図２】本発明がどのように使用されることが可能かを示す図である。
【図３】ライブラリをカスタマイズするためのプロセスの一例を示す図である。
【図４Ａ】ＰＣと輸液ポンプの間の通信を示す図である。
【図４Ｂ】薬剤ライブラリを編集し、ダウンロードするプロセスを示す流れ図である。
【図５】複数のポンプのコンピュータへの接続を示す背面図である。
【図６】薬剤師が、本発明を備えたコンピュータ上で見るワークシートの例を示す図である。
【図７Ａ】ソフト限度オーバライドレポートの例を示す図である。
【図７Ｂ】図７のレポートを説明するテーブルである。
【図７Ｃ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｄ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｅ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｆ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ａ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｂ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｃ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｄ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図９】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１０】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１１】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１２Ａ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｂ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｃ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｄ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１３】本発明で使用するための電子システムの一例を示すブロック図である。
【図１４】本発明で使用するための電子システムの一例を示すブロック図である。
【図１５Ａ】薬剤に関する規則セットを編集する際に使用されるダイアログボックスの例を示す図である。
【図１５Ｂ】本発明のＲｕｌｅ Ｓｅｔ Ｅｄｉｔｏｒにおける様々なフィールドまたは値に関する有効な入力範囲を示すテーブルである。
【図１６】規則セットバリデータ判定ツリーの一例を示す図である。
【図１７Ａ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１７Ｂ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１７Ｃ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１８】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１９】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図２０Ａ】ＸＭＬ交換スキーマの一例を示す図である。
【図２０Ｂ】本発明の一例において利用されるＸＭＬオブジェクトタグ名を示すテーブルである。
【図２１】規則セットの追加、編集、削除、または閲覧を行う際に規則セットエディタで使用されるダイアログボックスの例である。
【図２２】ＤａｔａＭｏｄｅｌとＤａｔａＩｔｅｍの間の関係を示すブロック図である。
【図２３】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２４Ａ】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２４Ｂ】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２５】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２６】ソフト限度警報イベントまたはオーバライド臨床イベントをサポートするデータモデルを示す図である。
【発明を実施するための形態】
【００１１】
一般に、本発明は、コンピュータと、１つまたは複数の薬物投与デバイスの間で通信を提供するためのシステムおよび方法を提供する。本発明は、ハードウェアとソフトウェアを使用して、コンピュータと輸液ポンプの間のリンクを提供する。一例では、本発明は、薬局環境または生物医学技術サービス環境、あるいは、全体が本明細書に明示的に組み込まれている、２００３年１２月５日に出願した、「ＭＥＤＩＣＡＴＩＯＮ ＭＡＮＡＧＥＭＥＮＴ ＳＹＳＴＥＭ」という名称の本出願人の同時係属仮出願第６０／５２７５８３号、および２００４年２月２０日に出願した、同一の名称による通常の特許出願で説明されている、薬物管理ユニット（ＭＭＵ）において使用されるように設計される。
【００１２】
本発明は、施設が、イリノイ州、アボットパーク所在のアボットラボラトリーズ（Ａｂｂｏｔｔ Ｌａｂｏｒａｔｏｒｉｅｓ）から入手可能な、ＰＬＵＭ Ａ＋（登録商標）インフューザ（ｉｎｆｕｓｅｒ）またはポンプのような輸液ポンプで使用するための薬剤ライブラリをカスタマイズすることを可能にする。また、他のタイプのポンプも、本発明で使用されることが可能である。例えば、本発明は、患者自己管理鎮痛（ＰＣＡ）ポンプ、歩行ポンプ、経腸ポンプ、ならびにＩＶ輸液ポンプで使用されることが可能である。また、本発明は、複数のポンプからのデータの格納も可能にし、様々な安全性レポート、イベント、および警報レポートを生成する。
【００１３】
図１Ａは、Ａｂｂｏｔｔ ＰＬＵＭ Ａ＋（登録商標）インフューザまたはポンプ１２の正面図である。図１Ｂは、筐体２が、筐体２内部に、コンピュータと輸液ポンプの間の通信を円滑にするプラグアンドプレイモジュール４を受けるために内部に形成された、縦に細長いスロット３を含むように変更されている、図１ＡのＰＬＵＭ Ａ＋（登録商標）ポンプの背面図である。プラグアンドプレイモジュール４は、筐体２内部に動作可能なように配置され、筐体によって実質的に包囲され、保護され、隔離される。プラグアンドプレイモジュール４は、ポンプ筐体２のスロット３にはまり込む、薄い、細長いカード形状のケースを有する。このため、本発明のプラグアンドプレイモジュール４は、ポンプによって占有される空間をほとんど増大させることがない。図１Ａおよび図１Ｂに示されるプラグアンドプレイモジュール４は、ハードワイヤド通信向けに構成される。しかし、以下に説明するとおり、プラグアンドプレイモジュール４は、無線通信向けに構成されることも可能である。
【００１４】
一例では、本発明のソフトウェアは、１２までの臨床看護領域（ＣＣＡ）を格納することができ、１００までの薬剤エントリ（９９の薬剤エントリ、およびＮｏ Ｄｒｕｇ Ｓｅｌｅｃｔｅｄ）が各ＣＣＡの中に格納されて、合計で１２００のエントリが、マスタ薬剤処方集の中に格納される。その例では、本発明のソフトウェアは、単一のコンピュータに接続された１５までのＡｂｂｏｔｔ ＰＬＵＭ Ａ＋（登録商標）単一チャネルインフューザのデータ転送をサポートする。もちろん、本発明は、異なる格納能力および通信能力で設計されることが可能であり、異なるポンプ向けに構成されることが可能である。
【００１５】
図２は、本発明がどのように使用されることが可能であるかを示す図である。図２に示されるとおり、ソフトウェアが、ホストコンピュータ（この例では、パーソナルコンピュータ、つまり、ＰＣ１０）上にインストールされると、ユーザは、任意の所望される規則セットを含む、薬剤ライブラリを作成する（または、ソフトウェア媒体を備えたライブラリを使用する）ことができる。薬剤ライブラリは、薬剤名、薬剤量、薬剤単位、希釈液量、希釈液単位、投与単位、薬剤クラス、ハード限度、およびハード限度範囲内のソフト限度を含むエントリを含むことが可能である。薬剤濃度は、入力する必要がない。というのは、その値は、薬剤量、薬剤単位、希釈液量、および希釈液単位から導出可能だからである。また、ユーザは、ライブラリ内で複数のＣＣＡを作成することもできる。次に、ユーザは、ＰＣを複数のインフューザ１２に接続し、ＰＣとインフューザの間でデータ転送を開始することができる。例えば、アクティブ薬剤ライブラリが、ＰＣから、接続されたインフューザにダウンロードされることが可能である。さらに、データは、インフューザからＰＣに転送されることも可能である。例えば、イベントログおよびアラームログが、接続されたインフューザからＰＣにアップロードされることが可能である。また、所望の他のあらゆるタイプのデータまたは通信も、ＰＣとインフューザの間で転送されることが可能である。
【００１６】
図３は、ライブラリをカスタマイズするためのプロセスの一例を示す図である。図３のプロセスは、薬剤師などのユーザが、ＰＣ１０上でワークシートを作成することから始まる。この例では、ワークシートは、依然、編集されることが可能であり、まだ完成されていないライブラリと考えることができる。このワークシートの１つの目立った特徴は、ワークシートが、２つの同時のビュー、すなわち、目標の「実用（ｗｏｒｋｉｎｇ）」処方集ビュー、およびソース「基準」処方集ビューを提供することである。一例では、薬剤のマスタ処方集ビューが、同時に、そのＣＣＡに関する目標薬剤のビューが示されながら、基準ビューの中にあることが可能である。同様に、別の例では、目標ビューは、「Ｍｅｄｉｃａｌ（内科）」などの１つのＣＣＡであるのに対し、ソースは、「Ｓｕｒｇｅｒｙ（外科）」などの別のＣＣＡであることも可能である。薬剤師は、全く同一の薬剤エントリを、関連する規則セットとともに、ソースから目標にコピーすることができる。この提示により、すべての必要なＣＣＡを策定するのにかかる時間が短縮され、薬剤師のための容易な品質検査、ならびに策定されているすべての薬剤規則セットにわたるビューが促進される。さらに、同一の薬剤名、濃度、および規則セットを多くの異なるＣＣＡの中に再入力することを余儀なくされた場合に、タイプ入力の誤りが減少する。薬剤ライブラリを策定する際の誤りは、看護士のためのセーフティネットの低下、患者の疾病率の増加をもたらす可能性がある。図６は、薬剤師（または他のユーザ）が、本発明を備えたコンピュータ上で見ることができるワークシートの一例を示す。図６は、マスタ薬剤処方集テーブルが、スクリーンの下部１４にあり、選択されたＣＣＡにおける薬剤が、スクリーンの上部１６にある分割スクリーンビューを示す。プルダウンメニュー１８を使用して、いずれのＣＣＡが、上部１６で表示されるかが選択される。
【００１７】
図３および図２０Ａを参照すると、ユーザは、次に、許可されたユーザによって定義された、病院の区域または患者集団（ｐａｔｉｅｎｔ ｐｏｐｕｌａｔｉｏｎ）（例えば、集中治療部（ＩＣＵ））において使用するための薬剤ライブラリのサブセットである、ＣＣＡを作成する（そのようなＣＣＡが、既に作成済みでない場合）。各ＣＣＡは、事前定義された数の特定の薬剤を有することが可能である。また、病院は、薬剤ライブラリの中に複数のＣＣＡを有することが可能である。次に、ユーザは、任意の所望の薬剤クラス（例えば、抗生物質、麻酔薬、β遮断剤、その他）を作成し、その後、薬剤エントリを規則セットとともにＣＣＡに追加する。次に、ＣＣＡインフューザ設定値が、設定される。ＣＣＡインフューザ設定値の例には、最大速度、既定の閉塞圧、最大患者体重および／または最小患者体重が含まれる。次に、マスタインフューザ設定値が、セットアップされる。マスタインフューザ設定値の例には、Ｃｏｎｔｉｎｕｅ Ｒａｔｅ（療法が完了した後に、インフューザが切り替わる既定の速度）、Ｅｎａｂｌｅ Ｄｅｌａｙ／Ｓｔａｎｄｂｙ（既定のスタンバイ設定）、Ｃａｌｌｂａｃｋ Ｎｏｔｉｆｉｃａｔｉｏｎ（イネーブルにされた場合、多段輸液中の段階の合間に、または薬用量を装填した後に、インフューザ１２が、可聴の看護士コールバックアラームを発し、通知を表示するようにさせる）、およびＤｅｌｉｖｅｒ Ｔｏｇｅｔｈｅｒ（既定として、２チャネル送達方法を選択することを可能にする）が含まれる。ワークシートを完成させる前に、ワークシートレポートが印刷され、点検されることが可能である。最後に、ワークシートが、アクティブライブラリとして完成される。
【００１８】
アクティブライブラリが準備できた後、技師は、１つまたは複数のインフューザ１２をデータ転送のためにＰＣ１０に接続することができる。図４Ａおよび図５は、ＰＣ１０とインフューザ１２の間の通信を示す図である。第１に、アクティブライブラリが、インポートされる。次に、技師は、インフューザ１２をＰＣ１０に接続する。インフューザ１２は、任意の所望の形でＰＣ１０に接続されることが可能である。例えば、ケーブル（図１Ｆ）が、ＰＣ１０上のシリアルポートと、接続箱（図１Ｅ）の間で接続されることが可能であり、接続箱は、プラグアンドプレイモジュール４（図１Ａ）を介して、各インフューザ１２のデータポートにも接続される。インフューザ１２とＰＣ１０は、シリアルインタフェース（ＲＳ２３２、ＵＳＢ、その他）、パラレルインタフェース、その他を含め、任意の所望のタイプのインタフェースを使用することができる。別の例では、インフューザ１２は、必要に応じてＰＣ１０への接続を提供する無線能力を有することが可能である。接続されると、プログラミングイベント、設定値、およびアラーム、その他を含むが、以上には限定されない情報が、履歴情報（ログ）またはリアルタイム情報として、ＰＣにアップロードされることが可能であり、アクティブライブラリが、インフューザ１２のすべてにダウンロードされることが可能である。図５は、複数のシリアルコネクタ、および複数の接続箱を有するシリアルケーブルを使用した、複数のポンプのコンピュータへの接続を示す図である。
【００１９】
図４Ｂは、前述したプロセスを示す別の流れ図である。図示されるとおり、病院処方集が、１つまたは複数のワークシートにインポートされることが可能である。ユーザが、薬剤ライブラリを完成させた後、アクティブ薬剤ライブラリが、１つまたは複数のインフューザにダウンロードされることが可能である。また、図４Ｂは、薬剤ライブラリが、アーカイブされ、ワークシートを策定する、または編集する際に、再び使用されることが可能であることも示す。
【００２０】
本発明は、先行技術における様々な問題を解決するいくつかの特徴を含む。以下は、それらの特徴の説明である。
【００２１】
本発明は、リモートプロシージャコール（ＲＰＣ）のために拡張マークアップ言語（ＸＭＬ）表現を利用する。ＸＭＬを使用する１つの利点は、ＸＭＬ構文ドキュメントの使用により、プロトコルが、異なるタイプの製品をサポートすることが可能になることである。例えば、第１のインフューザが、別のインフューザによって要求されるフォーマットとは異なる、ある通信フォーマットだけしか許さない可能性がある。ＸＭＬを使用することにより、システムは、異なるタイプのインフューザと通信することができる。異なるタイプのデバイスの例には、異なるコンピュータアーキテクチャを有するデバイス、異なるタイプのコンピュータプロセッサを実行しているデバイス、異なるソフトウェアプログラム（または同一のプログラムの異なるバージョン）を実行しているデバイスが含まれる。さらに、一部のデバイスは、他のデバイス上で使用されているバイナリフォーマットと互換性がない可能性があるバイナリデータフォーマットを使用して動作する。このように、ホストコンピュータは、様々な異なるタイプのデバイスに関して同一のメッセージフォーマットを使用することができる。また、本発明は、輸液ポンプなどの患者に接続された医療デバイスと通信する際に、ＸＭＬパーサの使用も提供する。
【００２２】
本発明の一部の応用例では、ホストとポンプが、互換性のないバイナリデータフォーマットを有する可能性がある。その理由で、ホスト上と、ポンプ上で同一である語彙形式（ｌｅｘｉｃａｌ ｆｏｒｍ）を定義する必要がある。その共通の語彙表現が、正規形式と呼ばれる。プロセス固有のバイナリ形式を正規形式に変換するプロセスは、正規化と呼ばれる。
【００２３】
誤り検査は、一般に、チェックサム関数またはハッシュ関数を使用する。しかし、これらの関数は、常に信頼できるわけではない。本発明は、医療上クリティカルなデータを使用するので、より信頼できる誤り検査関数を使用することが重要である。さらに、ライブラリ全体の内容を検証することが依然として可能でありながら、部分ライブラリ更新（薬剤ライブラリの中の個別の項目などの）を可能にすることが望ましい。本発明は、標準のチェックサム関数またはハッシュ関数を、交換データ構造全体の状態を保護するグローバル正規巡回冗長検査（Ｇｌｏｂａｌ Ｃａｎｏｎｉｃａｌ Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）（ｇＣＣＲＣ）で補う。ｇＣＣＲＣの目的は、ホストとポンプが、試みられたデータ伝送の後に、それぞれのデータが同一であることを検証することができるようにすることである。ｇＣＣＲＣは、より低いレベルのチェックサム、およびその他の方法によって捕えられない誤りを検出することができる。例えば、ｇＣＣＲＣは、ドロップされたパケットの数が、シーケンス番号の範囲そのものである場合を検出する。また、ｇＣＣＲＣは、ポンプ切断、停電、およびソフトウェア欠陥のような例外を含む、あらゆる種類のプロトコル障害に対する、最終の「バックストップ（ｂａｃｋｓｔｏｐ）」検証も提供する。
【００２４】
一例では、２つのバイナリイメージ（ホストコンピュータにおけるイメージと、インフューザにおけるイメージ）を比較して、それらが同一であるかどうかを確かめて、インフューザの中に格納されたデータの内容を検証する従来の技法ではなく、２つの場合により全く異なる物理的（ビット単位の）表現が、意味的に同一であるかどうかを判定する比較が行われる。これは、正規表現（いずれの側も、格納のために実際に使用しない）を使用し、次に、２つの抽象表現の間で比較を行うことによって達せられる。例えば、輸液ポンプにおけるデータの内容を検証するのに、ポンプにおけるデータに基づき、ＣＲＣが計算される。次に、ホストが、ポンプにおけるデータであると考えるものに基づき、ＣＲＣが計算される。次に、それらの数値が比較される。数値が同一であった場合、データは、ホストとインフューザにおいて同一である可能性が極めて高い。このアプローチの１つの利点は、少量のデータしか、比較の目的で転送されることが要求されないことである。ライブラリ全体のバイナリイメージは、比較のために再伝送されなくてもよい。また、このアプローチは、データ伝送中の誤り検査の要件も無くす。
【００２５】
本発明の別の態様は、ＣＲＣがどのように計算されるかに関する。使用されるＣＲＣの形態は、Ｃｏｍｉｔｅ Ｃｏｎｓｕｌｔａｔｉｆ Ｉｎｔｅｒｎａｔｉｏｎａｌｅ ｄｅ Ｔｅｌｅｇｒａｐｈｉｑｕｅ ｅｔ Ｔｅｌｅｐｈｏｎｉｑｕｅ（ＣＣＩＴ）によって指定されている。しかし、本発明では、ＣＣＩＴ ＣＲＣは、逆のビット順序（ＣＣＩＴによって指定される左から右にではなく、右から左に）で行われて、計算をより効率的にするようにする。Ｉｎｔｅｌプロセッサは、ＣＣＩＴによって規定される、いわゆる「ネットワークバイト順」とは逆の「エンディアン性（ｅｎｄｉａｎｎｅｓｓ）」を有するので、ビット逆転により、一部のプロセッサ上でインプリメンテーション問題が回避されることになる。
【００２６】
ＣＲＣを使用して前述した語（異なるエンディアン性を有することが可能な）を構築する際、ＣＲＣを使用する前に、ドキュメントまたはデータの構文を正確に定義することが重要である。本発明は、その目的でＸＭＬスキーマを使用する。加えて、ＸＭＬスキーマは、検証のために使用されるセマンティクスを定義するのに使用される。）検証されるべきデータ（例えば、薬剤ライブラリ）は、正規形式（前述した）に変換され、ＸＭＬスキーマを使用して検証され、確認されて、データが有効であるとともに、正しい形式である（ｗｅｌｌ ｆｏｒｍｅｄ）かどうかが判定される。ライブラリの例では、この検証検査は、ライブラリをポンプに伝送する前に行われる。
【００２７】
本発明のＸＭＬスキーマの一例は、２つの主要な部分、エクスチェンジスキーマ、およびインプライドスキーマを含む。一般に、エクスチェンジスキーマは、ホストコンピュータと輸液ポンプの間で通信されるべきデータの構造を定義する。インプライドスキーマは、交換されているデータの型を定義する（さらに、検証する）。
【００２８】
図２０Ａは、Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ（ＵＭＬ）表記法を使用する、ＸＭＬエクスチェンジスキーマの一例を示す図である。図２０Ａの例で示されるとおり、薬剤ライブラリは、インフューザ設定値、少なくとも１つの薬剤エントリ、およびアクティブライブラリオブジェクトを含む。この例では、１つのインフューザ設定値オブジェクト、および１つのアクティブライブラリオブジェクトだけが存在するが、１２００までの薬剤エントリオブジェクトが存在する。図２０Ａに示された各オブジェクトは、それぞれのボックス内に記載される属性を含む。アクティブライブラリオブジェクトは、１２までのＣＣＡオブジェクトを含む。各ＣＣＡオブジェクトは、１００までの規則セットオブジェクトを含む。この例では、１つの薬剤につき１つだけの規則セットが存在するが、複数の薬剤が、単一の規則セットを共有することが可能である。図２０Ａに示されたデータ構造、およびそれらのデータ構造のメンバは、各エントリに関するタグ名（オプションとして、略記される／短縮される）を有するＸＭＬオブジェクトとして定義される。図２０Ｂは、一例において使用される名前を明らかにする。図２０Ｂは、コマンドとともに、クエリおよび応答、ならびにそれらの対応する省略形を示す。図示されるとおり、データ構造に加えて、コマンドおよびクエリも、ＸＭＬで符号化され、ホストコンピュータ（つまり、サーバ）側およびポンプ（つまり、クライアント）側によって、データと同様に処理される。当業者には明白なとおり、コマンドおよびクエリを本発明とともに使用して、ホストコンピュータとクライアント輸液ポンプの間で通信を効率的に提供することができる。例えば、以下のコマンドにより、サーバの計算されたグローバル正規チェックサムをクライアントに通信している間に、薬剤ライブラリ更新が終了される（＜ｘＥＵ ｇｃｃｒｃ＝”９Ｂ８Ｄ”／＞）。図２０Ｂに示されるとおり、「ｘＥＵ」は、コマンド「ＥｎｄＬｉｂｒａｒｙＵｐｄａｔｅ」の省略形であり、他方、値「９Ｂ８Ｄ」は、サーバのチェックサムの１６進値の例である。その他のコマンドおよびクエリも、同様の形で使用される。
【００２９】
インプライドデータは、ホストコンピュータ１０と輸液ポンプ１２の間の契約である。インプライドデータは、ホストによって管理され、ホストおよびクライアントのためのソフトウェアを開発する際に使用される。一例では、インプライドデータは、通信リンクを介して伝送されず、インフューザソフトウェアがそのデータを処理することも決してない。インプライドスキーマの１つの目的は、クライアントに送られることが許されるデータの値および型を検証することである。１つの形態の検証は、範囲外の値が伝送されるのを制限する範囲検査である。別の形態の検証は、表示精度であることが可能である。例えば、変数の表示範囲は、０．１位（ｔｅｎｔｈｓ ｏｆ ｄｉｇｉｔ）であることが可能である。そのようなケースでは、１２．００という値を送信することは、その値が、変数の範囲を超えた精度を記述しているので、無効である。別のタイプの検証は、固有型検査であることが可能である。暗黙のスキーマは、ＸＭＬスキーマドキュメントの形態をとる。ＸＭＬスキーマドキュメントは、エクスチェンジスキーマの中のすべてのクライアント／ホスト固有の型定義のための型定義を提供する。以下は、様々なインプライドスキーマの型の例である。第１の例は、機関名文字列が、３０文字以下であることを定義する単純文字列型スキーマである。
【数１】
【００３０】
ＸＭＬスキーマは、ほとんどの数値データ型上でｆｒａｃｔｉｏｎＤｉｇｉｔｓファセットを直接に介して固定小数点表示をサポートする。以下の例は、最小および最大の１０進数値および小数部数値を定義する。
【数２】
【００３１】
一例では、本発明は、ＥｎｃｏｄｅｄＳｔｒｉｎｇに対するｘｓ：ｅｎｕｍｅｒａｔｉｏｎ制限を定義することにより、インプライドエニュメレーションを構築する。
【数３】
【００３２】
単一の値に関する複数の範囲が、＜ｘｓ：ｃｈｏｉｃｅ＞を介して値に関して指定されることが可能である。以下の例は、上限範囲および下限範囲を含む、患者体重フィールドに関する。
【数４】
【００３３】
ＸＭＬを使用することの１つの問題は、ＸＭＬが、非常に詳細（ｖｅｒｂｏｓｅ）であることであり、これにより、帯域幅要件が増大する。通信オーバーヘッドを低減するため、本発明は、依然として標準に準拠するが、ＸＭＬ識別子をいくつかの文字ニーモニック（ｍｎｅｍｏｎｉｃ）に短縮することによって大幅に低減された帯域幅で動作する、よりコンパクトな形態のＸＭＬを使用する。符号化は、簡潔な要素、および属性名を使用する正しい形式のＸＭＬである。一例では、各ＸＭＬ Ｓｈｏｒｔ Ｎａｍｅは、英字だけから成り、最初の文字によって一意に識別されることが可能である。コマンドは、引数をＸＭＬ属性として送る。応答は、値を、属性値として、かつ／または応答要素の中に入れ子にされた要素として戻す。例えば、長いＸＭＬ名「ＩｎｆｕｓｅｒＳｅｔｔｉｎｇ」は、「ＩＳ」に短縮される。したがって、例示的なコマンドラインは、
例：コンパクトなＰｕｍｐＣｏｎｆｉｇｕｒａｔｉｏｎインスタンス
【数５】
のようなものであり、
例：ＰｕｍｐＣｏｎｆｉｇｕｒａｔｉｏｎインスタンス
【数６】
のような、コンパクトでないバージョンではない。
この例では、符号化は、約２００文字を約６０文字に削減しており、およそ３．３対１の比をもたらしている。
【００３４】
本発明は、データポートプロトコルの上に、信頼できるバイナリトランスポートプロトコルを含む、拡張されたデータポートプロトコルを使用する。つまり、プロトコルが、データポートプロトコルの上で実行される。このアプローチの１つの利点は、異なるマシン間の互換性の向上である。別の利点は、大きいメッセージがセグメント化され、再組み立てされることが可能なことである。これにより、ホストまたはポンプが大きいメッセージを扱うことができない場合でも、非常に大きいメッセージが、プロトコルスタックを介して送信されることが可能になる。大きいメッセージは、小さいパケットにセグメント化され、後に再組み立てされる。
【００３５】
本発明は、ポンプにダウンロードされることが可能であり、アクティブライブラリと呼ばれる１つのライブラリだけが、コンピュータの中に保持されることを可能にすることにより、データベースの安全性を確実にする。これにより、時間が経つにつれ誤ったライブラリがダウンロードされないことが確実になる。編集されることが可能なライブラリは、ワークシートと呼ばれ、多くの異なるワークシートが存在することが可能である。かつてアクティブであり、もはやアクティブではないライブラリは、アーカイブされ、そのようなものとして自動的に指定される。アクティブライブラリを別のコンピュータに転送することができるように、一意の特別なファイル拡張子および認識が開発された。これにより、複数の所在地を有する、より大型の医療施設の薬局間における全く同一のライブラリの転送が可能になる。
【００３６】
本発明の別の利点は、システムが、複数の輸液ポンプに同時にデータをダウンロードすることができることである。ライブラリは、マルチキャストの形で複数のポンプに伝送される。システムは、ポイントツーポイント通信を使用して、各ポンプのステータスを定期的に検証する。ポンプの１つが問題を有する場合、ダウンロードは、再スタートされることが可能であり、各ポンプが、新たなダウンロードの通知を受ける。一例では、あるポンプが、ブロードキャストダウンロード中にダウンロードエラーを検出すると、そのポンプは、ホストコンピュータにメッセージを送信し、すると、ホストは、ダウンロードを停止する。次に、ホストは、ポンプのすべてにポーリングを行って、ポンプのすべてが、有効なデータを有するメッセージを受信していた時点を特定する。ダウンロードは、複数の個々のタグ付きメッセージにわたって行われるので、タグ番号により、いずれのポンプもダウンロードエラーを報告していなかった時点をホストコンピュータが識別することが可能になる。ダウンロードが続けられる際、ダウンロードは、その時点で始まり、したがって、データのすべてが、再びダウンロードされなくてもよい。マルチキャスト通信戦略は、ダウンロードスループットを最適化する。例えば、ライブラリが、ダウンロードするのに１０分かかる場合、１５のポンプが、各ポンプに個々にダウンロードするのにかかる１５０分に対して、１０分でダウンロードを受信することができる。マルチキャストとポイントツーポイント通信のこの混合により、個々のポンプへの堅牢なダウンロードおよび再試行／回復機構が円滑になる。本発明の別の利点は、ワークシートが、薬剤エントリのＣＣＡビューを同時に提供しながら、マスタ処方集ビューを薬剤師に提供することである。薬剤エントリを編集すること、およびコピーすることは、いずれのビューにおいても行われることが可能である。この提示により、薬剤限度警報または薬用量限度警報が策定されるにつれ、薬剤師のための容易な品質検査、安全性機能が促進される。薬剤ライブラリを策定する際の誤りは、看護士のためのセーフティネットの低下、患者の疾病率の増加をもたらす可能性がある。
【００３７】
本発明の別の利点は、単一のデータベースを使用して、複数の輸液ポンプの履歴を格納することができることである。これにより、１つのデータベースの中で１つの機関におけるすべてのポンプからイベントログデータを取り出す能力が可能になり、使用の場所、時刻、誤りのタイプ、その他に基づき、データを取り出すことができる。また、他のタイプのレポートも可能である。また、集中データベースを使用しても、システムは、それぞれが、任意の所望のポンプにダウンロードすることができる複数のＰＣを含むことが可能である。
【００３８】
同様に、本発明は、ポンプ使用データを収集し、関連するレポートを生成することもできる。例えば、ソフト限度オーバライドデータが、ソフト限度オーバライドに関連するレポートの生成のために収集されることが可能である。そのタイプのレポートは、スタッフを評価すること、将来の限度を設定すること、その他などの任意の所望の目的で使用されることが可能である。
【００３９】
本発明は、薬剤データをリアルタイムで検証することができるアクティブ薬剤ライブラリエディタを含む。本発明は、無制限の数の薬剤ライブラリを管理することができる。薬剤ライブラリは、マスタ薬剤処方集（ＣＣＡが作成される元になる薬剤テーブル）、および複数のＣＣＡで構成される。ライブラリは、アクティブ（完成されていないワークシート）であること、アーカイブされていること（データベースに保存されている、以前にアクティブであったライブラリ）、またはワークシート（インフューザへのダウンロードがまだ承認されておらず、依然として編集されることが可能なドラフトライブラリ）であることが可能である。アクティブライブラリだけが、ポンプにダウンロードされることを許される。ポンプの動作上の振舞いを記述する構成パラメータなどの項目が、ポンプ全体にわたって、またはＣＣＡに固有で設定されることが可能である。それらのパラメータは、各ライブラリに独特である。ＴａｌｌＭａｎレタリングが、薬剤名に関してサポートされる。ＴａｌｌＭａｎレタリングに対する変更は、ライブラリ全体でレプリケートされる。ライブラリの中の各薬剤が、薬剤分類に関連付けられる。薬剤分類は、各ライブラリに独特である。薬剤は、複数の濃度、および複数の規則セットを有することが可能である。規則セットは、完全であること、限られていること、またはなしであることが可能である。
【００４０】
本発明の別の特徴は、アクティブ薬剤ライブラリが利用することができる様々なレベルの規則に関連する。本発明は、デバイス規則（例えば、特定の医療デバイス、または特定のタイプのデバイスの動作または限度に関連する規則）、ＣＣＡ規則（例えば、特定のＣＣＡに関連する規則）、薬剤規則（特定の薬剤に関連する規則）、および患者規則（例えば、年齢、体重、健康、病歴、アレルギー、その他などの、特定の患者に関連する規則）を含め、複数の規則レベルの使用を可能にする。
【００４１】
Ｒｕｌｅ Ｓｅｔ Ｅｄｉｔｏｒ（ＲＳＥ）が、薬剤データベースの中の規則セットを作成し、編集するのに使用される。ＲＳＥは、規則セットを正確に表示し、適宜、「追加」ボタン、「保存」ボタン、または「削除」ボタンをイネーブルにすることを担う。図２１は、規則セットの追加、編集、削除、または閲覧を行う際に規則セットエディタで使用されるダイアログボックスの例を示す。図２１に示されるとおり、薬剤名、薬剤クラス、薬剤量、薬剤希釈液、およびソフト限度／ハード限度のためのフィールドが存在する。ＲＳＥは、入力基準を調整すること、ならびにユーザが入力選択を行っている間に規則セットを検証することを担う。ＲＳＥは、ＲｕｌｅＳｅｔＤａｔａＩｔｅｍ（ＲＳＤＩ）（以下に説明する）をデータモデルとして使用し、ＲｕｌｅＳｅｔＶａｌｉｄａｔｏｒ（ＲＳＶ）（以下に説明する）をコントローラとして使用する。ＲＳＥは、モデルが検証されるべき場合、ＲＳＤＩにメッセージを送信する。ＲＳＤＩは、ＲＳＤＩを検証するＲＳＶにメッセージを送信する。この責任分離は、規則セットエディタユーザインタフェースとライブラリインポートプロセスの両方に関する標準の検証インプリメンテーションをカプセル化するように確立される。
【００４２】
本発明の別の利点は、薬剤構成に関する。本発明は、特定の薬剤に関する薬剤名および濃度の定義を可能にする特別な規則セットを含む。しかし、ポンプにおいて、ユーザは、薬剤量および薬剤単位を無効にすることができる。したがって、限度が設定されるが、ユーザは、濃度を定義することを許される。したがって、本発明は、ユーザが、薬剤ごとに送達の単位を選択することを選択的に制限する、または許す能力、ならびに薬剤単位の濃度を有する薬剤にラベルを付けるが、他の単位（ｍｌ／時）で送達する能力を有する。
【００４３】
本発明の別の利点は、制約定義に関する。本発明は、一意制約オブジェクトのセットを含む。制約オブジェクトは、キーボード入力、マウス入力、およびインポート入力を検証するための標準のインプリメンテーションを定義する。例えば、特定のフィールドが、ある数値範囲に制約されることが可能である。制約は、物事が誤って行われるのを防止する。しかし、ときとして、１つのオブジェクト入力は、別のオブジェクトの内容に基づき、本発明では、制約定義は、入力定義が変化するにつれ、動的に変化する。例えば、オブジェクト「薬剤量」に関して、制約は、測定単位（例えば、グラム数、その他）に依存して変化することが可能である。
【００４４】
Ｄｏｓｅ Ｒａｔｅ Ｄｏｃｕｍｅｎｔ（ＤＲＤ）が、複数の制約を集約して、入力確認が、無制限の数の制約オブジェクト全体でカスケードされることが可能であるようにする。ＤＲＤのインプリメンテーションの一例では、オブジェクト、ＤｏｓｅＲａｔｅＤｏｃｕｍｅｎｔは、ｊａｖａｘ．ｓｗｉｎｇ．ｔｅｘｔ．ＰｌａｉｎＤｏｃｕｍｅｎｔを拡張して、要求されるメソッド、ｉｎｓｅｒｔＳｔｒｉｎｇ（ｉｎｔオフセット、Ｓｔｉｎｇ文字列、ＡｔｔｒｉｂｕｔｅＳｅｔ属性）をインプリメントする。このメソッドは、適宜、ＳｔｒｉｎｇＣｏｎｓｔｒａｉｎｔ．ｃｈｅｃｋＩｎｐｕｔ（Ｓｔｒｉｎｇ ｐｒｏｐｏｓｅｄＶａｌｕｅ）を内部で呼び出す。
【００４５】
Ｒｕｌｅ Ｓｅｔ Ｃｏｎｓｔｒａｉｎｔ（ＲＳＣ）が、薬剤量、希釈液量、ならびにハード限度およびソフト限度に関する特定のＤＲＤを提供する。ＲＳＣは、薬剤単位および投与量単位に基づき、それらの設定値を動的に変更して入力を検証するのに使用される。ＲＳＣは、いくつかの制約オブジェクトを集約して、エントリが、有効範囲内にあることを確認する。一例では、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度は、独自のＤＲＤおよびＣｏｎｓｔｒａｉｎｔオブジェクトを有するが、それぞれは、目標のニーズを満たすように独特である。ＲＳＣは、構築されると、規定の値で初期設定される。ｓｅｔＤｒｕｇＡｍｏｕｎｔＣｏｎｓｔｒａｉｎｔｓ（ｄｒｕｇＬａｂｅｌＰＫ）に対する連続的なコールにより、ｄｒｕｇＡｍｏｕｎｔＤＲＤが調整される。同様に、ｓｅｔＤｉｌｕｅｎｔＡｍｏｕｎｔＣｏｎｓｔｒａｉｎｔ（）に対するコールにより、ｄｉｌｕｅｎｔＡｍｏｕｎｔＤＲＤが調整される。本発明の一例では、唯一の制約は、ｄｉｌｕｅｎｔＡｍｏｕｎｔである。同様に、ｓｅｔＬｉｍｉｔＣｏｎｓｔｒａｉｎｔｓ（ｄｏｓｉｎｇＵｎｉｔＰＫ）に対する連続的なコールにより、限度量が調整される。
【００４６】
Ｒｕｌｅ Ｓｅｔ Ｄａｔａ Ｉｔｅｍ（ＲＳＤＩ）は、特殊化されたＤａｔａＩｔｅｍであり、データモデルとして作用する。Ｇｅｔｔｅｒ／Ｓｅｔｔｅｒが提供されて、ＲＶＤＣ（以下に説明する）、ＲＳＥ、およびＲＳＶ（以下に説明する）によって必要とされる様々な形態の属性を取得し、設定する。ＤａｔａＩｔｅｍは、自らをどのようにＳＱＬ Ｓｅｒｖｅｒデータベースの中に追加するかを知っている。本発明の一例では、ＲＳＶは、ＲＳＤＩのプライベートインプリメンテーションとしてではなく、静的オブジェクトとしてインプリメントされる。この責任分離により、ＲＳＶのインプリメンテーションおよび保持がより簡単になる。
【００４７】
Ｒｕｌｅ Ｓｅｔ Ｄａｔａ Ｍｏｄｅｌ（ＲＳＤＭ）は、インポートされているすべてのＲＳＤＩアイテムのための仮想データストアを提供する特殊化されたＡｂｓｔｒａｃｔＤａｔａＭｏｄｅｌである。
【００４８】
Ｒａｔｅ Ｖｅｒｓｕｓ Ｄｏｓｅ Ｃａｌｃｕｌａｔｉｏｎ（ＲＶＤＣ）が、患者の体重、薬剤濃度、その他などの変数の文脈において、所与の薬用量に対応する送達速度を計算する。一例では、ＲＶＤＣは、特定の輸液ポンプインプリメンテーションに結び付けられていない。また、一例では、ＲＶＤＣアルゴリズムは、純粋に代数的である。ＲＳＤＩは、ＲＳＶによって抽出され、ＲＶＤＣに送られて、ＤｏｓｅＦｒｏｍＲａｔｅまたはｃａｌｃｕｌａｔｅＲａｔｅＦｒｏｍＤｏｓｅが計算されるデータを所有する。
【００４９】
Ｒｕｌｅ Ｓｅｔ Ｖａｌｉｄａｔｏｒ（ＲＳＶ）は、すべての規則セットデータフィールドに関する検証プロセスを調整する。ＲＳＶは、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度によって必要とされる制約をリセットすることから始める。ＲＳＶは、各フィールドを準拠について、以下のとおり組織的に検証する。すなわち、
・長さは、０または空白であってはならず、最大長を超えてはならない。
・ピクセル長は、ポンプ上の表示可能な領域を超えてはならない。
・名前が、無効な文字に関して検査される。
【００５０】
ＲＳＶは、ユーザ入力、インポートされたライブラリ、１つの場所から別の場所にコピーされた薬剤を含め、異なるソースからの規則セットを検証するのに使用され、ＣＣＡ最大速度設定値に対する調整を行う。ＲＳＶは、システム全体で、規則セットが、形式が正しく、有効であり、ライブラリ全体に関する送達準拠に違反しないことを検証するのに、一貫して、常に使用される。ユーザが、規則に違反するデータを入力しようと試みた場合、ダイアログボックスの中の「保存」ボタンが、低輝度表示されて、ディセーブルにされ、ユーザが、規則に違反するデータを変更することを余儀なくされる。図１５Ａは、薬剤に関する規則セットを編集する際に使用されるダイアログボックスの例を示す図である。この例では、ユーザは、所望されるものを何であれ編集し、次に、「保存」ボタンをクリックする。エントリが有効ではなかった場合、「保存」ボタンは、低輝度表示され、ユーザは、変更を保存することを許されない。
【００５１】
図１６は、規則セットバリデータ判定ツリーの一例を示す。図１６に示された判定ツリーは、規則セット限度の有効性を評価するのに使用される基本的な論理を表す。一般に、判定ツリーは、規則セットが、「ＮＯＮＥ」、「ＦＵＬＬ」、または「ＬＩＭＩＴＥＤ」であるかどうかを尋ね、次に、判定ツリーの中で概要が述べられた他の質問を尋ねて、規則セットが有効であるかどうかを判定する。図１６は、ユーザが、規則セットを作成している間、または編集している間に、キーボード入力またはマウス入力を行うたびに行われる動的検査を示す。また、図１６は、ＲＳＶがどのように検査を行って、そのような送達速度／薬用量が、薬用量限度に基づいて許容できるかどうかを確かめるかも示す。また、最大速度ＣＣＡインフューザ設定値などの、他の設定値も同様の形で考慮に入れられる、または分析されることが可能である。
【００５２】
本発明の別の特徴は、Ｄａｔａ Ｍｏｄｅｌに関する。Ｄａｔａ Ｍｏｄｅｌは、データを薬剤ライブラリの中にインポートすること、ソースから宛先ＣＣＡライブラリにコピーすること、およびＣＣＡライブラリ内のＣＣＡ設定値を編集することに使用される。以下の図は、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間の関係、および高レベルの対話を示す。図２２は、ＤａｔａＭｏｄｅｌとＤａｔａＩｔｅｍの間の関係を示す。簡明にするため、ＣＣＡＳｅｔｔｉｎｇおよびＣＣＡＬｉｂｒａｒｙ ＤａｔａＭｏｄｅｌおよびＤａｔａＩｔｅｍは、図２２に示していない。図２３は、インポートプロセスとＲｕｌｅＳｅｔＤａｔａＩｔｅｍの間における高レベルの対話を示す図である。前述したとおり、インポートとＲＳＥの間で、いくつかの類似点が存在する。例えば、ＲＳＤＩが、ＲＳＶによって検証される。インポートプロセスは、タブ区切り値（ＴＳＶ）ファイルまたはカンマ区切り値（ＣＳＶ）ファイルを消費して、ＲＳＤＭオブジェクトを作成する。ＲＳＤＭは、Ｄｒｕｇ Ｌｉｂｒａｒｙエントリ、ＣＣＡエントリ、ＣＣＡ Ｌｉｂｒａｒｙ Ｖｉｅｗエントリ、およびＭａｓｔｅｒ Ｄｒｕｇ Ｆｏｒｍｕｌａｒｙ（ＭＤＦ）エントリを作成するのに使用される。図２４Ａおよび図２４Ｂは、規則セットが、目標からソースＣＣＡ Ｌｉｂｒａｒｙにコピーされる際の、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間における高レベルの対話を示す、２つの好ましいＵＭＬ図を示す。同様に、図２５は、ＣＣＡ Ｓｅｔｔｉｎｇが、目標ＣＣＡ Ｌｉｂｒａｒｙの中で編集される際の、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間における高レベルの対話を示す。
【００５３】
また、本発明は、Ｄｏｓｅ Ｒａｔｅ Ｅｄｉｔｏｒ（ＤＲＥ）と呼ばれる特殊化されたコンボボックスエディタも有する。ＤＲＥは、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度についてのＤＲＤを確立するのに使用される。ＤＲＥは、薬用量入力と予約語「Ｎｏｎｅ」の両方を特に考慮に入れているため、独特である。ＤＲＥは、０のすべての絶対値（例えば、「０」、「０．０」、「０．００」、「なし」、その他）を「Ｎｏｎｅ」に変換し、０ではない値に関するすべての後続の０または小数点を除去する。
【００５４】
前述したとおり、本発明は、ハード限度とソフト限度の両方を同時に使用することができる。さらに、様々な関連するレポートが、１つまたは複数の輸液ポンプから生成されることが可能である。１つのタイプのレポートは、ソフト限度オーバライドレポート（以下に説明する）である。以下は、ソフト限度オーバライドレポートがどのように生成されることが可能かの例である。ＳｏｆｔＬｉｍｉｔ Ａｌｅｒｔ／Ｏｖｅｒｒｉｄｅレポートのための永続ストレージ設計が、アップロードされたログの「保存」のための特定の要件と、生のログデータを解析して、臨床行為、部分的イベント、および重複ログエントリを明らかにする間接的な要件の両方によって推進される。一例では、すべてのログデータが、そのデータがアップロードされた源の輸液ポンプとの関連付けを保持する。
【００５５】
生のログデータは、アーカイブの目的とともに、ログ内容の直接報告（リスト表示（ｌｉｓｔｉｎｇ））をサポートするために保持される。保持に先立ち、生のログデータは、第１回の解析を受けて、ＰＣに既にアップロード済みであるが、輸液ポンプの中に格納されたままであった（アップロード後、ログがクリアされていないために）古いデータを表すログの部分が削除される。以下のデータベーステーブルが、解析されたログデータを保持するように定義される。
【表１】
リストアップされた最初の３つのテーブル、ＵｐｌｏａｄＨｉｓｔｏｒｙ、ＵｐｌｏａｄＥｖｅｎｔ、およびＥｖｅｎｔＴｙｐｅは、生のアップロードされたイベントデータを保持する既存の機能をサポートする。リストアップされた第４のテーブル、ＣｌｉｎｉｃａｌＡｃｔｉｏｎは、個別のイベント（Ｓｏｆｔ Ｌｉｍｉｔ Ａｌｅｒｔ／Ｏｖｅｒｒｉｄｅ）に関する必要なコンテキストを提供して、有意な役立つレポートを生成することを目的とする。
【００５６】
前述したテーブルのそれぞれの個々のフィールドを以下に示す。最初に、ＵｐｌｏａｄＨｉｓｔｏｒｙからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表２】
【００５７】
次に、ＵｐｌｏａｄＥｖｅｎｔからのフィールドを、それらのフィールドの目的とともにリストアップする。
【表３】
【００５８】
次に、ＥｖｅｎｔＴｙｐｅからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表４】
【００５９】
最後に、ＣｌｉｎｉｃａｌＡｃｔｉｏｎからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表５】
一例では、リストアップされたフィールドのすべてが必須であり、「空白でない」ように制約される。この例では、すべてのデータフィールドが、「利用不可」という値をサポートして、特定のフィールドが、イベントログから取り出されることが可能でなかったために（例えば、ログが３２１行を超えた場合の上書きに起因して）、全く値を有さないことを示す。以下の図は、Ｓｏｆｔ Ｌｉｍｉｔ Ａｌｅｒｔイベントまたはオーバライド臨床イベントをサポートするデータモデルを示す。図２６は、ソフト限度警報イベントまたはオーバライド臨床イベントをサポートするデータモデルを示す図である。
【００６０】
図７Ａは、１つのソフト限度オーバライドレポートの例を示す。図７Ｂは、図７Ａに示された見出しおよびデータの説明を含む。図７Ｃ〜図７Ｆおよび図８Ａ〜図８Ｄは、この例では、ドーパミン、ヘパリン、インスリン、およびバンコマイシンである、いくつかの異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す。図７Ｃ〜図７Ｆに示されたレポートは、出される警報のタイプ（ハード下限、ソフト下限、ソフト上限、ハード上限）、ならびに各警報が出された回数をリストアップする。出される各タイプの警報に関して、レポートは、ユーザが、警報にどのように応答したかに関連する統計も示す。この例では、レポートは、警報がオーバライドされたまたはオーバライドされなかった回数を示す。さらに、情報のエントリを確認するように求められた際に、ユーザによって「いいえ」が入力された回数も示す。図８Ａ〜図８Ｄは、警報レポートおよびオーバライドレポートの別の例を示す。図８Ａ〜図８Ｄに示されたレポートは、各警報が、ＣＣＡ（この例では、ＩＣＵおよびＭｅｄＳｕｒｇ）によって隔てられていることを除いて、図７Ｃ〜図７Ｆに示されるレポートと同様である。以上の例から、任意の所望の情報が、本発明によって収集され、報告されることが可能であることが明白である。
【００６１】
本発明の１つの利点は、ハード限度とソフト限度の両方が、各薬剤に関して与えられることが可能であり、いずれの薬剤／ＣＣＡの組み合わせにも、１つ、２つ、３つ、または４つの限度が割り当てられることが可能なことである。ハード限度とソフト限度の両方を与える能力が存在する場合、使用されることが可能な限度の１６の組み合わせが存在する。４つの限度のそれぞれが、ある限度を指定する値を含むこと、または「限度」が、無制限（適切なフィールド内の「なし」によって示される）であることが可能である。それらの２つの可能性は、各限度に関して、すなわち、ハード下限、ソフト下限、ソフト上限、およびハード上限）に関して）存在する。この特徴は、ユーザが、ハード上限だけ、ハードとソフトの上限と下限、ハード上限およびソフト上限（下限なし）、ハード下限およびソフト下限（上限なし）、その他などの、様々な組み合わせでデバイスを構成することを可能にする。２つのセットの上限と下限の例では、構成の１６の可能な組み合わせが存在する。さらなる限度セットが使用される場合、より多くの組み合わせが可能である。一実施形態では、ハード限度は、ユーザによって無効にされることが可能でない、選択された薬剤、および選択されたＣＣＡに関する薬用量上限／薬用量下限である。別の実施形態におけるハード限度は、管理上の（ｓｕｐｅｒｖｉｓｏｒｙ）オーバライドを要求するか、または許すことが可能である。ハード限度、権限レベル、およびオーバライド可能性は、薬剤ライブラリ内の各薬剤に関して、病院によって定義される。特定の薬剤に関するハード限度は、割り当てられている場合、異なるＣＣＡにわたって異なる可能性がある。
【００６２】
一実施形態では、ソフト限度は、ユーザによって無効にされることが可能な、選択された薬剤、および選択されたＣＣＡに関する薬用量上限および／または薬用量下限である。特定の薬剤に関するソフト限度は、割り当てられている場合、ＣＣＡにわたって異なる可能性がある。ソフト限度に達した場合、警報または警告をトリガする規則セットが、薬剤ライブラリに関して提供される。警告は、操作者の側で、明確なオーバライドステップを要する。同様に、ユーザが、プログラミングすることを許される送達速度の範囲に対するハード限度を与える規則セットが、薬剤ライブラリに関して提供される。例えば、ソフト下限が、毎時１０ｍＬに設定され、臨床家が、毎時９ｍｌを入力した場合、インフューザは、ソフト限度オーバライド警報を表示する。インフューザの履歴ログの中に記録されるこの警報は、そのエントリが、その薬剤エントリに関して設定されたソフト限度の範囲外であることを臨床家に通知する。臨床家は、オーバライドを使用して、プログラミングを続けることを選択すること、またはオーバライドを取り消して、別の値を再入力することができる。臨床家が、ソフト限度を無効にすることを選択した場合、そのイベントが、インフューザの履歴ログの中に別個に記録される。ハード限度およびソフト限度は、他の様々な薬剤パラメータに関して設定されることが可能である。例には、投薬速度、薬剤送達時間、薬剤濃度、患者の体重、輸液されるべき量（ＶＴＢＩ）、その他が含まれる。
【００６３】
ハード限度および／またはソフト限度の別の用法は、正しいデータ入力に関する。例えば、時間エントリに対してハード限度を設定して、ユーザが、０から５９までの間の値だけを入力することができるようにすることが可能である。この例では、システムは、データ入力エラーに気付き、有効な範囲内の値を入力するようにユーザに強制する。別の例では、様々な薬剤フィールドに関して、一部の値または範囲だけが、入力されることを許される。１５Ｂは、薬剤単位フィールド、薬剤量フィールド、希釈液量フィールド、送達薬用量／速度単位フィールド、ならびにハード限度フィールドおよびソフト限度フィールドに関して入力されることが可能な値の例を示す。ユーザが他の値を入力することを試みる場合、システムはユーザに有効なフィールドを入力させ、または警報またはアラームを発する。
【００６４】
また、本発明は、１つのコンピュータから別のコンピュータへの薬剤ライブラリのインポートおよびエクスポートも可能にする。ライブラリがインポートされることが可能になるには、まず、ライブラリが、エクスポートされなければならない。一般に、薬剤ライブラリは、事前定義されたフォーマットを有する完成した薬剤ライブラリ（ＦＤＬ）にエクスポートされることが可能であり、そのフォーマットは、ライブラリを、ライブラリが、アクティブライブラリとしてインポートされ、設定されることが可能な他のコンピュータに、安全で、セキュリティで保護された形で移植可能にする。例えば、アクティブライブラリを有する第１のＰＣに関して、ライブラリは、バイナリフォーマットにエクスポートされ、ライブラリがインポートされる第２のＰＣに移されることが可能であり（ネットワーク、コンピュータ可読媒体、その他を介して）、したがって、第１のＰＣと第２のＰＣにおけるライブラリが同期される。特別ファイル拡張子（ＦＤＬ）、ならびにコンピュータ間におけるソフトウェアによる認識が、要求される。
【００６５】
ＦＤＬがエクスポートされると、薬剤ライブラリ全体がまず、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャ（以下を参照）を使用して、データベースから「選択される」。そのプロシージャは、実際、いくつかの選択ステートメントを含み、１つのテーブル当たり１つのステートメントを含む。テーブルは、コピー用のテーブルと同一である。各テーブルに関して、エクスポートメソッドが、テーブル名、行と列の数をシリアル化し、次に、各行が、列ごとにシリアル化される。元のデータベースインデックス値がシリアル化されることに留意されたい。ライブラリが、ファイルから読み取られると、インデックス値は、もはや有効ではないが、あたかもライブラリがコピーされたかのように同一に、マップされなければならない。一例では、ＦＤＬファイルは、「読み取り専用」ファイルである。ＦＤＬファイルは、Ｊａｖａ（登録商標）シリアル化フォーマットであるので、ＦＤＬファイルは、通常のソフトウェアアプリケーションを使用して、ユーザによって容易に変更されない。この特徴は、シリアル化を使用することの理由の一部であり、つまり、ユーザが、完成した薬剤ライブラリを改ざんするのをやめさせるためである。
【００６６】
ＦＤＬがインポートされると、最初に、すべてのシリアル化された情報が、３次元アレイの形態でメモリに読み込まれる。テーブルに関する１つの次元、行に関する１つの次元、および列に関する１つの次元の、３つのアレイ次元が存在する。行の次元のサイズ、および列の次元のサイズは、各テーブルに関して異なることが可能である。この「生の」データが、テーブルごと、行ごとにデータベースに挿入される。また、インデックスマッピングも、途中で実行されることが可能である。次に、行が挿入されると、新たなインデックス値が生成されて、コピー操作中に行われるのと同様に、マップの中に格納される。一部のテーブルは、他の、以前に挿入されたテーブルに対するインデックスを含むことが可能である。それらのインデックスは、生成されたマップを使用して、元の値から新たな値に変換される。それらの変換されたインデックス値は、新たな行に挿入される値である。ＦＤＬは、データベースの中に格納された後、Ｆｉｎａｌｉｚｅｄ Ｄｒｕｇ Ｌｉｂｒａｒｙとなり、別のＦｉｎａｌｉｚｅｄ Ｄｒｕｇ ＬｉｂｒａｒｙをＡｒｃｈｉｖｅｄライブラリにする。
【００６７】
以下は、いずれの順序でテーブルがアレイの中に格納されているか、インデックス依存関係は、どのようなものか、いずれの列をマップの中に格納するか、いずれの列値が、挿入されることが可能になるには、まず、新たな値にマップされる必要があるか、その他をＦＤＬインポートに知らせる、ＦＤＬＤａｔａ．ｊａｖａの説明である。
【００６８】
薬剤ライブラリをコピーする場合と同様に、ＦＤＬインポート中にテーブルが処理される順序が重要であることを認識することが重要である。その順序は、列挙された定数としてＦＤＬＤａｔａ．ｊａｖａファイルの中に符号化される。以下は、そのような列挙された定数の例である。すなわち、
【数７】
【００６９】
以上の定数は、前述した生のデータの３次元アレイへのインデックスとして使用されることが可能である。また、このコードセクションは、データベーススキーマに変更が行われた場合、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌによって生成されることも可能である。
【００７０】
エクスポート／インポートされる各テーブルに関して、テーブル名、列の数、他のテーブルが依存する可能性がある列が存在するとすれば、列のいずれか（ｉｄＣｏｌｕｍｎ）、および最後に、そのテーブルが依存するテーブルに対するインデックスセットを常に把握しているＴａｂｌｅＩｎｆｏのインスタンスが存在する。「ｉｄＣｏｌｕｍｎ」は、指定されている場合、行が挿入されるにつれ、そのテーブルの各行に関するデータベースによって生成される。古い値（シリアル化されたファイルからの）と新たな値（データベース行挿入からの）が、インデックスマップの中に格納される。次に、古いインデックスを参照する他のすべてのメモリ内テーブルが、新たなインデックスを含むように更新されてから、行が挿入される。例えば、以下に示されるＲｕｌｅＳｅｔテーブルの「ｉｄＣｏｌｕｍｎ」は、そのテーブルのＲｕｌｅＳｅｔＩＤ列であり、ＲｕｌｅＳｅｔＩＤ列は、偶然、ＴａｂｌｅＩｎｆｏテーブルの中の第２の列である。このため、ＲｕｌｅＳｅｔに関するＴａｂｌｅＩｎｆｏインスタンスにおける「ｉｄＣｏｌｕｍｎ」は、１（第１の列は、０、第２の列は、１，．．．）である。次に、ＦＤＬがエクスポートされた際、ＲｕｌｅＳｅｔＩＤが５０４７であったＲｕｌｅＳｅｔテーブルの中の行が存在していたものと想定されたい。すなわち、
【表６】
ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙテーブル（以下に示す）はそれぞれ、ＲｕｌｅＳｅｔ依存関係、つまり、それぞれのＲｕｌｅＳｅｔＩＤ列を有する。
【表７】
次に、ＦＤＬがインポートされる際、ＲｕｌｅＳｅｔテーブル（以下に示す）のその特定の行に、５１２２という新たなインデックス値が与えられるものと想定されたい。
【表８】
後に、ＣｃａＬｉｂｒａｒｙテーブルまたはＤｒｕｇＦｏｒｍｕｌａｒｙテーブルが挿入される前に、５０４７のあらゆるＲｕｌｅＳｅｔＩＤ値がまず、５１２２に変更される。１という「ｉｄＣｏｌｕｍｎ」設定値が、５０４７−５１２２マッピングを格納するようにＦＤＬインポートコードに告げる。
【表９】
ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙテーブルの中の５０４７値が、依然としてメモリの中に、つまり、生のデータの３次元テーブルの中にある間に、５１２２に変更される。それらのテーブルが処理された後、ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙＩＤテーブルが、以下に示される。
【表１０】
【００７１】
ＦＤＬＤａｔａ．ｊａｖａファイルを再び参照すると、ファイルの様々なセクションが、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルによって自動的に生成される。それらのセクションは、そのファイルの出力からｊａｖａコードにカットアンドペーストが行われることが可能である。具体的には、テーブル順序定数（以上に示す）、ならびにＴａｂｌｅＩｎｆｏアレイおよびそのアレイの内容が、データベーススキーマ変更のイベントにおいて生成されることが可能である。
【００７２】
また、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルは、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャ（以下に説明する）の大部分も同時に生成する。この場合も、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルが生成するＳＱＬコードは、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ．ｓｑｌファイル内の適切な場所にカットアンドペーストが行われることが可能である。
【００７３】
ＦＤＬがエクスポートされる際、ライブラリを構成するデータが、データベースから獲得される（そのデータが、ファイルにシリアル化されることが可能であるように）。ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャが、それを行う。プロシージャは、いくつかの選択ステートメントを利用し、テーブルを特定の順序で選択し、任意の所与のテーブルの列を特定の順序で選択する。
【００７４】
テーブルの順序、およびそれらのテーブル内の列の順序は、薬剤ライブラリを再構築するＦＤＬインポートコードに重要であるので、ＦＤＬエクスポート、ＦＤＬインポート、およびＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙコードが、互いに同期して保たれることが不可欠である。データベーススキーマのほんのわずかな変更も、ＦＤＬＤａｔａ．ｊａｖａおよびＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ、ならびにＣｏｐｙＤｒｕｇＬｉｂｒａｒｙ格納プロシージャの変更を余儀なくさせる。ほんのわずかな誤り（不一致）によっても、適切に機能しなくなる。
【００７５】
ＣｏｐｙＤｒｕｇＬｉｂｒａｒｙコードを除いて、ｊａｖａ変更およびＳＱＬ変更のほとんどは、新たなスキーマが配備された後、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルを実行することによってもたらされることが可能である。それらのファイルの中の一致する／類似のコードの上に、生成されたコードを単にカットアンドペーストする。また、ＣｏｐｙＤｒｕｇＬｉｂｒａｒｙコード変更も、自動化されることが可能である。
【００７６】
本発明の１つの特徴は、データが、システムにインポートされること、およびシステムからエクスポートされることが可能なことである。カンマ区切り値（ＣＳＶ）またはタブ区切り値（ＴＳＶ）を使用するライブラリテキストファイルが、システムによってインポートされることが可能である。１つの独特な特徴は、ファイル全体が、前述したＲＳＶ検査に合格しなければならず、さもなければ、インポート全体が、無効と見なされることである。
【００７７】
本発明は、様々なポンプまたは医療デバイスに適用可能であり、本明細書で本発明を説明するのに使用されているポンプに限定されないことが当業者には認識されよう。さらに、本発明を逸脱することなく、ポンプとコンピュータの間における接続は、無線であることも、有線であることも可能であることが当業者には認識されよう。無線通信エンジンが、ポンプおよびコンピュータに接続され、ＢＬＵＥＴＯＯＴＨ（商標）（ＩＥＥＥ８０２．１５）、あるいはＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｂ、およびＩＥＥＥ８０２．１１ｇに記載されるような他のプロトコルなどの、通信プロトコルを利用する無線ネットワークを使用することが可能である。無線ネットワーク内の通信は、無線周波数電磁放射、赤外線放射、またはネットワーク要素間で無線通信を達するための他の手段を利用することができる。
【００７８】
一例では、プラグアンドプレイモジュール４が、無線通信エンジンまたは無線接続エンジンを収容する、または入れることができる。医療ポンプのための従来の無線通信モジュールは、最適な送受信のために、外部プラグイン、ボルト留めタイプであった。それらの従来の通信モジュールは、ポンプのために要求される空間を大幅に大きくし、ポンプの外形を変える。それらのモジュールは、ポンプが落とされた場合、損傷を受ける、または外れる可能性がある。さらに、他の医療機器に対する干渉の可能性を防止するように、医療機器からの最大電気放射に関する厳格な標準が存在する。本発明の無線プラグアンドプレイモジュール４は、ポンプによって占有されるスペースを大幅に大きくしない。以下に説明する、改良されたアンテナ設計で、ポンプ筐体２内部にプラグアンドプレイモジュール４を配置することにより、依然として、良好な位置／向きの許容度の大きい（ｐｏｓｉｔｉｏｎ／ｏｒｉｅｎｔａｔｉｏｎ ｔｏｌｅｒａｎｔ）送受信特性がもたらされ、デバイスからの電子放射が低下して、よりよく制限されるという意外な結果がもたらされる。
【００７９】
前述したとおり、本発明の輸液ポンプは、他の様々なデバイスに接続されることが可能である。一例では、本発明は、接続エンジンを使用して、ポンプが、様々な他のデバイスに接続することを可能にすることに加えて、システム機能を提供する。以下は、本発明で使用されることが可能な接続エンジンの一例である。前述した例では、様々な特徴および能力が、所望に応じてカスタマイズされることが可能である。
【００８０】
接続エンジンは、重要なシステム機能を提供すること、ならびに有線通信リンクと無線通信リンクの両方を介して、薬物管理ユニット（ＭＭＵ）、病院情報システム（ＨＩＳ）、薬局情報システム（ＰｈＩＳ）、およびその他の医療情報システムを含む様々な外部システムに、インフューザが接続することができるようにすることを目的とする、インフューザの筐体内部のアセンブリである。接続エンジンは、エンジンの印刷配線アセンブリ上のデータバスおよびアドレスバスを介して、基板−基板コネクタを介して、ＣＰＵ印刷配線アセンブリとインタフェースをとることができる。一例では、接続エンジンは、インフューザＣＰＵ印刷配線アセンブリのために、約１〜２メガバイトの読み取り専用プログラムと、１メガバイト以上の読み取り／書き込みデータメモリとをサポートする。接続エンジンは、インフューザユニットの後部上で外部に位置するシリアルデータポートを介して、ホストコンピュータと通信することができる。一例では、データポートは、電気的に絶縁される。
【００８１】
この例では、接続エンジンは、ユニットの後部上で外部からアクセス可能な、フロントパネルロックアウトスイッチを含む。また、接続エンジンは、ユニットの後部上で外部に位置する看護士呼び出しインタフェースも含むことが可能である。看護士呼び出しインタフェースは、患者が、アラームメッセージを看護士に送ることを可能にする、患者によって保持されるスイッチなどの、看護士呼び出しデバイスとともに使用されることを許す。また、接続エンジンは、器具の背後からアクセス可能なアラーム音量コントロールも含むことが可能である。このコントロールは、エラー、警告、その他をユーザに知らせる可聴アラームに関する音量レベルを調整する。
【００８２】
接続エンジンは、インフューザと外部システムの間で双方向通信を確立する目的で、様々な外部システムに対するインフューザの相互接続をサポートすることができるモジュール型のインテリジェントな印刷配線アセンブリである。外部システムの例には、薬物管理ユニット（ＭＭＵ）、医療情報システム、ＨＩＳ、および外部無線アクセスポイントが含まれることが可能である。外部システムのその他の例には、薬剤ライブラリおよびソフトをインフューザにダウンロードするため、およびインフューザからログをアップロードするための、１つまたは複数のＰＣが含まれる。
【００８３】
前述したとおり、本発明は、有線通信と無線通信の両方が可能である。サポートされることが可能な有線インタフェースの例には、イーサネット（登録商標）の１０ＢａｓｅＴおよび１００ＢａｓｅＴの標準、ならびにメガビットインタフェースおよび光ファイバインタフェースが含まれる。サポートされることが可能な無線インタフェースの例には、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ、ならびに他のあらゆる所望されるインタフェースが含まれる。接続エンジンは、ＸＭＬサービス、ＨＴＭＬサービス、ｆｔｐサービス、およびＴｅｌｎｅｔサービスを含め、様々なネットワークプロトコルをサポートすることができる。
【００８４】
一例では、本発明は、通常、有線インタフェースか、または無線インタフェースを使用して動作する。別の実施形態では、本発明は、有線インタフェースと無線インタフェースの両方を同時に使用することができる。その例では、いずれかのモードで障害が検出された場合、すべての通信が、機能しているモードに自動的に切り替わることが可能である。
【００８５】
接続エンジンハードウェアは、所望される機能および能力に依存して、多くの形態をとることができる。一例では、接続エンジンは、以下のサブ回路を含む。すなわち、ＣＰＵメモリ、つまり、ＲＡＭおよびフラッシュ、外部シリアルインタフェース、看護士呼び出しインタフェース、オーディオ音量コントロール、ロックアウトスイッチ、接続エンジンコントローラ、イーサネット（登録商標）インタフェース、無線インタフェース、およびアンテナアセンブリである。また、以下の外部コネクタも、含まれることが可能である。すなわち、イーサネット（登録商標）ＲＪ−４５コネクタ、Ｗｉ−Ｆｉトランシーバをアンテナ印刷配線アセンブリに接続するためのＲＦコネクタ、ＲＳ２３２シリアルポートＤＢ９コネクタ、および看護士呼び出しインタフェースコネクタである。
【００８６】
図９〜図１１は、本発明で使用されることが可能な、取り外し可能なプラグアンドプレイモジュールではなく、ポンプ筐体内部に完全に密閉された例示的な接続エンジンのブロック図である。図９は、ユニバーサルシリアルバス（ＵＳＢ）を介して接続エンジン２２に接続されたユーザインタフェースコントローラ（ＵＩＣ）２０を示す。もちろん、他のインタフェースも使用されることが可能である（例えば、ＲＳ２３２シリアルインタフェース、パラレルインタフェース、その他）。接続エンジン２２は、イーサネット（登録商標）接続およびＷｉＦｉ接続を有する、図９に示された入出力基板である。図１０は、プロセッサ２４を含む接続エンジンのブロック図である。プロセッサ２４は、イーサネット（登録商標）トランシーバ２６およびトランス２８に接続されて、１つまたは複数のＰＣ１０と通信するイーサネット（登録商標）インタフェースをもたらす。また、このインタフェースは、無線で提供されることも可能である。プロセッサは、ＵＳＢコントローラ３０にも接続される。ＵＳＢコントローラ３０は、ＵＳＢインタフェースを介して、ＵＩＣ ＵＳＢクライアント３２およびＲＦトランシーバ３４に接続される。
【００８７】
２つのアンテナ３６および３８を有するＲＦトランシーバ３４が示されている。本発明は、１つだけのアンテナを含んでもよいが、２つのアンテナが、本発明の性能を向上させることができる。本発明と他のデバイスの間の通信は、クリティカルである可能性があるので、可能な最も信頼できる無線通信を提供することが望ましい。２つのダイバース（ｄｉｖｅｒｓｅ）アンテナが、本発明の無線通信カバレッジを最適化する。本発明は、２つの異なるダイバーシチスキーム、空間ダイバーシチ、およびパターンダイバーシチの組み合わせを使用する。従来、空間ダイバーシチでは、２つの同一のアンテナが、２つの別個の場所に配置されて、共通の受信機にダイバーシチ受信をもたらす。そのケースでは、スキームは、アンテナを物理的に分離するだけでなく、２つのアンテナを直角に配置することにより、パターンダイバーシチも実現する。このようにして、１つのアンテナにおけるピークが、他方のアンテナのゼロ（ｎｕｌｌ）を埋めて、複合アンテナ指向性図（ｃｏｍｂｉｎｅｄ ｒａｄｉａｔｉｏｎ ｐａｔｔｅｒｎ）が、単一のアンテナだけよりも、より全方向性に見えるようにする。このアンテナダイバーシチスキームは、いくつかの目的を達する。第１に、外部からそれほど明らかでないアンテナを有することが望ましく、内部に組み込まれたアンテナを使用することが望ましくなる。第２に、ほとんどのアプリケーションにおいて、本発明は、デバイスが放射することができる放射の量を制限する、ＩＥＣ６０６０１−１−２、２ｎｄ Ｅｄｉｔｉｏｎ標準で指定されるＥＭＣ要件を満たさなければならない。２つのダイバースアンテナの使用は、以上の目的を達するのに役立つ。一例では、本発明で使用されるアンテナは、輸液ポンプの筐体内部に密閉される。これは、ほこり、有害な溶媒、およびごみをアンテナに近づけないようにするのに役立ち、放射の制限を強化するとともに、アンテナの損傷の可能性を低くする。
【００８８】
別の例では、接続エンジンは、情報を一時的に格納するためのキャッシュとして使用されるメモリを含む。キャッシュは、システムをより効率的に、より信頼できる形で機能させることができる。
【００８９】
図１１は、図１０に示される無線インタフェースのブロック図であり、ホストコンピュータと通信するためのＵＳＢインタフェースを含むベースバンドプロセッサ−媒体アクセスコントローラ４０を示す。プロセッサ４０は、変調器／復調器４２、ＲＦ／ＩＦ変換器４４、および電力増幅器４６に接続される。アンテナ３６および３８が、電力増幅器４６およびＲＦ／ＩＦ変換器４４によって駆動される。
【００９０】
図１２Ａ〜図１５Ａは、Ａｂｂｏｔｔ ＰＬＵＭ Ａ＋（登録商標）インフューザに適用された、本発明の一例の電子システム図である。図１２Ａ〜図１２Ｄは、ＣＰＵ、および通信エンジンまたは接続エンジンを示す。通信エンジンは有線または無線のインタフェースを介した他のデバイスとの通信を容易にする。通信エンジンは、図９〜図１１に関連して前述したのと同一の直角に配置されたアンテナを利用することができる。また、図１２は、スイッチおよびユーザコントロール、看護士呼び出しジャック、キーパッド、アラームスピーカ、ＬＥＤ、その他などの、様々なコンポーネントとインタフェースをとるためのデジタルＩ／Ｏチップも示す。図１３は、電源回路および絶縁バリアを含む、電源サブシステムを示す。図１４は、圧力センサ、空気センサ、モータ位置センサ、およびモータドライブを含む、機構サブシステムを示す。
【００９１】
図１７は、患者自己管理鎮痛（ＰＣＡ）ポンプの電子システムブロック図である。図１８および図１９は、図１７に示されるＰＣＡポンプで使用されることが可能な接続エンジンの電子システムインタフェースブロック図である。図１７は、システムに電力を供給する電源を含む。マイクロコントローラが、キーパッド、患者ペンダント、シリアルポート、バーコード読み取り装置、様々なセンサ、様々なスイッチ、モータドライブ、ディスプレイおよびＬＥＤインジケータ、ならびにスピーカを含め、システムの様々なコンポーネントとインタフェースをとる。
【００９２】
図１８は、図１７に示されるＰＣＡシステムで使用されることが可能な接続エンジンのブロック図である。図１８は、接続エンジンと、イーサネット（登録商標）、ＷｉＦｉ、外部ＲＳ２３２シリアルインタフェース、ならびにホストデバイスに対するＲＳ２３２シリアルインタフェースを含む、いくつかのインタフェースとを示す。また、図１８は、接続エンジンが、ＰＣＡポンプ（図１７）から電源をとることができる（電源コネクタを介して）接続エンジンも示す。ＰＣＡポンプは、様々なモータに電力を供給するためのモータ電圧ＶＭＯＴを生成する。同一の電圧ＶＭＯＴを使用して、接続エンジンに電力が供給されることが可能である。
【００９３】
図１９は、図１８の接続エンジンのより詳細なブロック図である。接続エンジンは、イーサネット（登録商標）プロセッサと８０２．１１ｂ無線トランシーバをともに組み込んだ有線／無線接続モジュールである、接続エンジンコントローラ（ＣＥＣ）を含む。イーサネット（登録商標）トランシーバ、およびすべての必要な回路は、ＲＪ−４５ジャックを介して１０／１００Ｂａｓｅ Ｔインタフェースを提供する。ＵＳＢコントローラ、およびすべての必要な回路が、ＷｉＦｉに対するＵＳＢ（ホスト）インタフェースを制御する。２つのＲＳ２３２ポートが、システムバスに接続される。また、接続エンジンは、ＦＬＡＳＨメモリおよびＳＤＲＡＭメモリも含む。
【００９４】
以上の詳細な説明では、本発明を、本発明の特定の例示的な諸実施形態に関連して説明した。特許請求の範囲に記載される本発明のより広い範囲を逸脱することなく、それらの実施形態に様々な改変および変更が行われることが可能である。したがって、本明細書および図面は、制限的ではなく、例示的であると見なされるべきである。
【特許請求の範囲】
【請求項１】
少なくとも１つの薬物投与デバイスと通信する方法であって、
マシン可読フォーマットでデータを格納するために少なくとも１つの薬物投与デバイスに格納ロケーションを提供すること、
リモートデバイスと無線で通信するための無線インタフェースを提供すること、および
リモートデバイスから少なくとも１つの薬物投与デバイスに情報を無線で送信することを含み、情報は、拡張マークアップ言語を使用して送信される、方法。
【請求項２】
情報は、薬剤ライブラリに関するエントリを含む、請求項１に記載の方法。
【請求項３】
情報は、薬物投与デバイスパラメータを含む、請求項１に記載の方法。
【請求項４】
少なくとも１つの薬物投与デバイスを構成する複数の薬物投与デバイスを提供することをさらに含む、請求項１に記載の方法。
【請求項５】
無線インタフェースを提供することは、少なくとも１つのアンテナを提供することを含む、請求項１に記載の方法。
【請求項６】
少なくとも１つのアンテナを無線インタフェースケース内に収容することをさらに含む、請求項５に記載の方法。
【請求項７】
少なくとも１つのアンテナおよび格納ロケーションを薬物投与デバイスの筐体内に収容することをさらに含む、請求項５に記載の方法。
【請求項８】
無線インタフェースを提供することは、２つのアンテナを提供することを含む、請求項１に記載の方法。
【請求項９】
２つのアンテナは、空間的に異なる、請求項８に記載の方法。
【請求項１０】
２つのアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項８に記載の方法。
【請求項１１】
２つのアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項８に記載の方法。
【請求項１２】
薬物投与デバイスから情報を受信することをさらに含む、請求項１に記載の方法。
【請求項１３】
薬物投与デバイスから受信される情報は、イベントログを含む、請求項１２に記載の方法。
【請求項１４】
薬物投与デバイスは、輸液ポンプである、請求項１に記載の方法。
【請求項１５】
薬物投与デバイスは、患者自己管理鎮痛ポンプである、請求項１に記載の方法。
【請求項１６】
薬物投与デバイスは、歩行ポンプである、請求項１に記載の方法。
【請求項１７】
１つまたは複数の処方された薬物を患者に投与するための装置であって、
装置の動作を制御するためのコントローラと、
装置に関するデバイスパラメータをマシン可読フォーマットで格納するための、コントローラに電気的に結合された１つまたは複数の格納ロケーションと、
外部デバイスと無線で通信するための、コントローラに電気的に結合された無線インタフェースとを含む、装置。
【請求項１８】
装置は、輸液ポンプである、請求項１７に記載の装置。
【請求項１９】
１つまたは複数の格納ロケーションは、薬剤ライブラリを格納する、請求項１７に記載の装置。
【請求項２０】
無線インタフェースと外部デバイスの間の通信は、拡張マークアップ言語を使用する、請求項１７に記載の装置。
【請求項２１】
装置は、無線インタフェースに結合されたアンテナをさらに含む、請求項１７に記載の装置。
【請求項２２】
装置は、コントローラと、１つまたは複数の格納ロケーションと、無線インタフェースと、アンテナとを収容する筐体をさらに含む、請求項２１に記載の装置。
【請求項２３】
装置は、無線インタフェースに結合された第１のアンテナと第２のアンテナとをさらに含む、請求項２１に記載の装置。
【請求項２４】
第１のアンテナと第２のアンテナは、空間的に異なる、請求項２３に記載の装置。
【請求項２５】
第１のアンテナと第２のアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項２３に記載の装置。
【請求項２６】
第１のアンテナと第２のアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項２３に記載の装置。
【請求項２７】
装置は、コントローラと、１つまたは複数の格納ロケーションと、無線インタフェースと、第１のアンテナと、第２のアンテナとを収容する筐体をさらに含む、請求項２６に記載の装置。
【請求項２８】
１名または複数名の患者に薬物を投与するための方法であって、
薬物投与デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションと、無線インタフェースとをそれぞれが有する複数の薬物投与デバイスを提供すること、
ホストコンピュータを提供すること、
ホストコンピュータ上で薬剤ライブラリを構成すること、および
ホストコンピュータ上の薬剤ライブラリから、無線インタフェースを介して、薬物投与デバイスの少なくともいくつかに情報を送信することを含む、方法。
【請求項２９】
情報は、薬物投与デバイスの１つだけにポイントツーポイントの形で送信される、請求項２８に記載の方法。
【請求項３０】
情報は、薬物投与デバイスのすべてに同時にブロードキャストされる、請求項２８に記載の方法。
【請求項３１】
ホストコンピュータから受信された情報に少なくとも部分的に基づき、患者に薬剤を投与することをさらに含む、請求項２８に記載の方法。
【請求項３２】
情報は、拡張マークアップ言語を使用して薬物投与デバイスに送信される、請求項２８に記載の方法。
【請求項３３】
筐体内に少なくとも１つのアンテナを収容することをさらに含む、請求項２８に記載の方法。
【請求項３４】
筐体は、コントローラ、および薬物投与デバイスの１つまたは複数の格納ロケーションも収容する、請求項３３に記載の方法。
【請求項３５】
薬物投与デバイスの無線インタフェースのための２つのアンテナを提供することをさらに含む、請求項２８に記載の方法。
【請求項３６】
２つのアンテナは、空間的に異なる、請求項３５に記載の方法。
【請求項３７】
２つのアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項３５に記載の方法。
【請求項３８】
２つのアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項３５に記載の方法。
【請求項３９】
薬物投与デバイスは、輸液ポンプである、請求項２８に記載の方法。
【請求項４０】
薬物投与デバイスは、患者自己管理鎮痛ポンプである、請求項２８に記載の方法。
【請求項４１】
薬物投与デバイスは、歩行ポンプである、請求項２８に記載の方法。
【請求項４２】
薬物投与デバイスからホストコンピュータに情報を送信することをさらに含む、請求項２８に記載の方法。
【請求項４３】
情報は、拡張マークアップ言語を使用して薬物投与デバイスからホストコンピュータに送信される、請求項４２に記載の方法。
【請求項４４】
ホストコンピュータによって受信される情報は、イベントログを含む、請求項４３に記載の方法。
【請求項４５】
薬物投与デバイスによって送信された情報から１つまたは複数のレポートを生成することをさらに含む、請求項４３に記載の方法。
【請求項４６】
１つまたは複数のレポートは、イベントログからの情報を含む、請求項４５に記載の方法。
【請求項４７】
１つまたは複数のレポートは、薬物投与デバイスの動作に関連する情報を含む、請求項４５に記載の方法。
【請求項４８】
薬剤ライブラリから情報を送信するステップは、薬物に関するハード限度を提供することを含む、請求項２８に記載の方法。
【請求項４９】
薬剤ライブラリから情報を送信するステップは、薬物に関するソフト限度を提供することを含む、請求項２８に記載の方法。
【請求項５０】
薬剤ライブラリから情報を送信するステップは、薬物に関するハード限度とソフト限度の両方を提供することを含む、請求項２８に記載の方法。
【請求項５１】
１つまたは複数の薬物投与デバイスと通信する方法であって、
ホストコンピュータを提供すること、
１つまたは複数の薬物投与デバイスを提供すること、
拡張マークアップ言語（ＸＭＬ）を使用してメッセージをフォーマットすること、および
ＸＭＬフォーマットされたメッセージを、ホストコンピュータから１つまたは複数の薬物投与デバイスの少なくとも１つに送信することを含む、方法。
【請求項５２】
ＸＭＬフォーマットされたメッセージを１つまたは複数の薬物投与デバイスの１つからホストコンピュータに送信することをさらに含む、請求項５１に記載の方法。
【請求項５３】
受信されたＸＭＬフォーマットされたメッセージを解析して、ホストコンピュータによって送信された情報を獲得することをさらに含む、請求項５１に記載の方法。
【請求項５４】
ＸＭＬフォーマットされたメッセージは、無線で送信される、請求項５１に記載の方法。
【請求項５５】
メッセージをフォーマットすることは、
１つまたは複数のＸＭＬ識別子を使用してメッセージをフォーマットすること、および
１つまたは複数のＸＭＬ識別子を短縮して、ＸＭＬフォーマットされたメッセージを送信するのに要求される帯域幅を低減することをさらに含む、請求項５１に記載の方法。
【請求項５６】
ホストコンピュータ上に薬剤ライブラリを格納することをさらに含む、請求項５１に記載の方法。
【請求項５７】
ＸＭＬフォーマットされたメッセージは、格納された薬剤ライブラリからの情報を含む、請求項５６に記載の方法。
【請求項５８】
１つまたは複数の薬物投与デバイスは、輸液ポンプである、請求項５１に記載の方法。
【請求項５９】
メッセージは、正規形式になっている、請求項５１に記載の方法。
【請求項６０】
メッセージの中に含まれる情報を検証することをさらに含む、請求項５１に記載の方法。
【請求項６１】
情報は、ＸＭＬスキーマを使用して検証される、請求項６０に記載の方法。
【請求項６２】
情報を検証するステップは、ホストコンピュータからの情報の正規表現を、メッセージを受信した１つまたは複数の薬物投与デバイスの少なくとも１つからの情報の正規表現と比較するステップをさらに含む、請求項６０に記載の方法。
【請求項６３】
検証された情報は、複数のビットを含み、正規表現は、右から左へのビット順序を使用して生成される、請求項６２に記載の方法。
【請求項６４】
ホストコンピュータおよび薬物投与デバイスによって格納されたデータを検証することをさらに含む、請求項５１に記載の方法。
【請求項６５】
データを検証するステップは、ホストコンピュータによって格納されたデータの正規表現を、薬物投与デバイスによって格納されたデータの正規表現と比較するステップをさらに含む、請求項６４に記載の方法。
【請求項６６】
１名または複数名の患者に薬物を投与する方法であって、
ホストコンピュータを提供すること、
薬剤ライブラリを構成する薬剤送達情報を格納するように、ホストコンピュータを使用すること、
格納された薬剤送達情報に関連するデータ含むメッセージを生成するように、拡張マークアップ言語（ＸＭＬ）を使用すること、
生成されたメッセージを薬物投与デバイスに送信すること、
格納された薬剤送達情報からデータを抽出するように、送信されたメッセージを薬物投与デバイスにおいて解析すること、および
抽出されたデータに少なくとも部分的に基づき、薬物投与デバイスを使用して薬物を患者に投与することを含む、方法。
【請求項６７】
薬物投与デバイスは、輸液ポンプである、請求項６６に記載の方法。
【請求項６８】
メッセージは、無線で薬物投与デバイスに送信される、請求項６６に記載の方法。
【請求項６９】
薬物投与デバイスにおいてメッセージを生成するように、拡張マークアップ言語（ＸＭＬ）を使用することをさらに含む、請求項６６に記載の方法。
【請求項７０】
メッセージを薬物投与デバイスからホストコンピュータに送信することをさらに含む、請求項６９に記載の方法。
【請求項７１】
薬物投与デバイスは、患者に薬物を投与するための１つまたは複数のポンプを含み、方法が、
抽出されたデータに少なくとも部分的に基づき、１つまたは複数のポンプの動作を制御することをさらに含む、請求項６６に記載の方法。
【請求項７２】
薬剤送達情報は、１つまたは複数の薬剤ライブラリを含む、請求項６６に記載の方法。
【請求項７３】
複数の薬物投与デバイスに薬剤ライブラリをダウンロードする方法であって、
複数の薬物投与デバイスを提供すること、
ホストコンピュータを提供すること、
薬剤ライブラリをホストコンピュータに格納すること、
ホストコンピュータと複数の薬物投与デバイスの間の通信を提供するように、拡張マークアップ言語（ＸＭＬ）を使用すること、および
ホストコンピュータから、格納された薬剤ライブラリに関連する情報を複数の薬物投与デバイスに送信することを含む、方法。
【請求項７４】
複数の薬物投与デバイスに送信される情報は、タグ付きである、請求項７３に記載の方法。
【請求項７５】
各薬物投与デバイスは、情報の諸部分を選択的に利用するように、タグを使用する、請求項７４に記載の方法。
【請求項７６】
各薬物投与デバイスは、情報の諸部分を選択的に利用するべく、情報を解析するのにタグを使用する、請求項７４に記載の方法。
【請求項７７】
送信された情報は、薬剤ライブラリ全体を含む、請求項７４に記載の方法。
【請求項７８】
送信された情報は、薬剤ライブラリのサブセットだけを含む、請求項７４に記載の方法。
【請求項７９】
薬剤ライブラリは、複数の薬物投与デバイスに同時にダウンロードされる、請求項７３に記載の方法。
【請求項８０】
薬剤ライブラリがダウンロードされる間に、複数の薬物投与デバイスに送信されるメッセージは、タグ付きである、請求項７９に記載の方法。
【請求項８１】
薬物投与デバイスの１つが、ダウンロードエラーを報告した場合、薬剤ライブラリダウンロードを停止し、後に、薬剤ライブラリダウンロードを続けることをさらに含む、請求項８０に記載の方法。
【請求項８２】
薬剤ライブラリダウンロードは、２回目、タグ付きメッセージの少なくとも一部をダウンロードすることなしに、続けられる、請求項８１に記載の方法。
【請求項８３】
薬剤ライブラリダウンロードは、いずれの薬物投与デバイスも、ダウンロードエラーを報告していなかった時点から続けられる、請求項８２に記載の方法。
【請求項８４】
薬物投与デバイスは、輸液ポンプである、請求項８３に記載の方法。
【請求項８５】
複数の異なるタイプの薬物投与デバイスと通信する方法であって、
ホストコンピュータを提供すること、
第１のタイプの薬物投与デバイスを提供すること、
第２のタイプの薬物投与デバイスを提供すること、
複数の薬物投与デバイスの動作に関連するデータをホストコンピュータ上に格納すること、および
薬物投与デバイスと通信することを含み、ホストコンピュータと薬物投与デバイスの間の通信は、拡張マークアップ言語（ＸＭＬ）を使用してフォーマットされたメッセージを使用する、方法。
【請求項８６】
第１のタイプの薬物投与デバイスは、第２のタイプの薬物投与デバイスによって使用されるコンピュータアーキテクチャとは異なるコンピュータアーキテクチャを使用する、請求項８５に記載の方法。
【請求項８７】
第１のタイプの薬物投与デバイスは、第１のタイプのコンピュータプロセッサを使用し、第２のタイプの薬物投与デバイスは、第２のタイプのコンピュータプロセッサを使用する、請求項８５に記載の方法。
【請求項８８】
第１のタイプの薬物投与デバイスは、第２のタイプの薬物投与デバイス上で実行されるソフトウェアとは異なるソフトウェアを実行する、請求項８５に記載の方法。
【請求項８９】
第１のタイプの薬物投与デバイスは、第２のタイプの薬物投与デバイスによって使用されるバイナリフォーマットと互換性のないバイナリデータフォーマットを使用する、請求項８５に記載の方法。
【請求項９０】
前記メッセージは、ホストコンピュータと薬物投与デバイスの間の通信が正規形式に変換される際に使用される、請求項８５に記載の方法。
【請求項９１】
ホストコンピュータと薬物投与デバイスの間の通信は、無線である、請求項８５に記載の方法。
【請求項９２】
ホストコンピュータ上にデータを格納することは、ホストコンピュータ上に薬剤ライブラリを格納することをさらに含む、請求項８５に記載の方法。
【請求項９３】
同一の格納された薬剤ライブラリが、複数の薬物投与デバイスにダウンロードされる、請求項９２に記載の方法。
【請求項９４】
同一の格納された薬剤ライブラリが、少なくともいくつかは、異なるタイプの薬物投与デバイスである複数の薬物投与デバイスにダウンロードされる、請求項９２に記載の方法。
【請求項９５】
格納された薬剤ライブラリの少なくとも一部分が、複数の薬物投与デバイスにダウンロードされる、請求項９２に記載の方法。
【請求項９６】
薬物投与デバイスを制御する方法であって、
デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションとを有する薬物投与デバイスを提供すること、
第１の薬剤のパラメータの第１の上限値および第１の下限値を定義する第１の限度セットを格納すること、および
第１の薬剤のパラメータの第２の上限値および第２の下限値を定義する第２の限度セットを格納することを含む、方法。
【請求項９７】
薬物投与デバイスが、薬剤を投与するのに使用される際、パラメータの第１の限度セットおよび第２の限度セットをパラメータの実際の値と比較する請求項９６に記載の方法。
【請求項９８】
パラメータの値が、第１の限度、または第２の限度の範囲内にない場合、警告を表示することをさらに含む、請求項９７に記載の方法。
【請求項９９】
第１の限度セットは、第２の限度セットの範囲内に入る、請求項９７に記載の方法。
【請求項１００】
パラメータの値が、第２の限度の範囲外にある場合、薬物投与デバイスは、所与の薬剤を投与することを許されない、請求項９８に記載の方法。
【請求項１０１】
第２の限度セットは、権限が付与された個人によってオーバライドされることが可能である、請求項１００に記載の方法。
【請求項１０２】
第２の限度セットがオーバライドされた回数の記録をとることをさらに含む、請求項１０１に記載の方法。
【請求項１０３】
第２の限度セットに関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項１０２に記載の方法。
【請求項１０４】
パラメータの値が、第１の限度の範囲外であり、かつ、パラメータの値が、第２の限度の範囲内であった場合、薬物投与デバイスは、所与の薬剤を投与することを許されない、請求項９７に記載の方法。
【請求項１０５】
第１の第２の限度セットは、権限が付与された個人によってオーバライドされることが可能である請求項１０４に記載の方法。
【請求項１０６】
第２の限度セットがオーバライドされた回数の記録をとることをさらに含む、請求項１０５に記載の方法。
【請求項１０７】
第２の限度セットに関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項１０５に記載の方法。
【請求項１０８】
第１の限度セットは、ソフト限度であり、第２の限度セットは、ハード限度である、請求項９６に記載の方法。
【請求項１０９】
各薬剤は、病院における異なる臨床看護領域に関して、異なるハード限度、および異なるソフト限度を有することが可能である、請求項１０８に記載の方法。
【請求項１１０】
薬剤のパラメータは、投与速度（ｄｏｓａｇｅ ｒａｔｅ）に関連する、請求項９６に記載の方法。
【請求項１１１】
薬剤のパラメータは、薬用量（ｄｏｓｅ）に関連する、請求項９６に記載の方法。
【請求項１１２】
薬剤のパラメータは、投与（ｄｏｓａｇｅ）量に関連する、請求項９６に記載の方法。
【請求項１１３】
薬剤のパラメータは、薬剤量に関連する、請求項９６に記載の方法。
【請求項１１４】
薬剤のパラメータは、希釈液量に関連する、請求項９６に記載の方法。
【請求項１１５】
薬剤のパラメータは、投薬速度に関連する、請求項９６に記載の方法。
【請求項１１６】
薬剤のパラメータは、薬剤送達時間に関連する、請求項９６に記載の方法。
【請求項１１７】
薬剤のパラメータは、薬剤濃度に関連する、請求項９６に記載の方法。
【請求項１１８】
薬剤のパラメータは、患者の体重に関連する、請求項９６に記載の方法。
【請求項１１９】
薬剤のパラメータは、患者の体表面積に関連する、請求項９６に記載の方法。
【請求項１２０】
薬物投与デバイスは、輸液ポンプである、請求項９６に記載の方法。
【請求項１２１】
薬剤のパラメータは、輸液されるべき量（ＶＴＢＩ）に関連する、請求項９６に記載の方法。
【請求項１２２】
患者に１つまたは複数の薬物を投与するための装置であって、
コントローラと、
コントローラに電気的に結合された１つまたは複数の格納ロケーションと、
装置の動作を制御するための、１つまたは複数の格納ロケーションに格納された制御情報とを含み、制御情報は、動作パラメータの値の第１の範囲を定義するソフト限度セットと、動作パラメータの値の第２の範囲を定義するハード限度セットとを含む、装置。
【請求項１２３】
ソフト限度セットは、ハード限度の範囲内に入る、請求項１２２に記載の装置。
【請求項１２４】
コントローラは、動作パラメータの値をハード限度およびソフト限度と比較する、請求項１２２に記載の装置。
【請求項１２５】
コントローラは、動作パラメータの値が、ハード限度およびソフト限度の範囲内にない場合、メッセージを表示する、請求項１２２に記載の装置。
【請求項１２６】
コントローラは、動作パラメータが、ハード限度の範囲を外れた場合、ユーザが、患者に薬物を投与するのを防止する、請求項１２２に記載の装置。
【請求項１２７】
ハード限度は、権限が付与された個人によってオーバライドされることが可能である、請求項１２６に記載の装置。
【請求項１２８】
ハード限度がオーバライドされた回数は、コントローラによって記録をとられる、請求項１２７に記載の装置。
【請求項１２９】
ハード限度に関連する情報、および記録をとられた情報を含むレポートが生成される、請求項１２８に記載の装置。
【請求項１３０】
コントローラは、動作パラメータの値が、ハード限度の範囲内にあるが、ソフト限度の範囲外にある場合、メッセージを表示する、請求項１２５に記載の装置。
【請求項１３１】
コントローラは、動作パラメータの値が、ハード限度の範囲内にあるが、ソフト限度の範囲外にある場合、ソフト限度をオーバライドすることを確認するよう、ユーザに要求する、請求項１２５に記載の装置。
【請求項１３２】
コントローラは、ソフト限度がオーバライドされた回数の記録をとる、請求項１３１に記載の装置。
【請求項１３３】
ソフト限度に関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項１３２に記載の装置。
【請求項１３４】
動作パラメータは、薬剤投与速度に関連する、請求項１２２に記載の装置。
【請求項１３５】
動作パラメータは、薬剤送達時間に関連する、請求項１２２に記載の装置。
【請求項１３６】
動作パラメータは、薬剤濃度に関連する、請求項１２２に記載の装置。
【請求項１３７】
動作パラメータは、患者の体重に関連する、請求項１２２に記載の装置。
【請求項１３８】
動作パラメータは、輸液されるべき薬剤量に関連する、請求項１２２に記載の装置。
【請求項１３９】
装置は、輸液ポンプである、請求項１２２に記載の装置。
【請求項１４０】
薬物投与デバイスを制御する方法であって、
デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションとを有する薬物投与デバイスを提供すること、
第１の薬剤のパラメータの第１の上限値および第１の下限値を定義する第１の限度セットを格納する能力を提供すること、および
第１の薬剤のパラメータの第２の上限値および第２の下限値を定義する第２の限度セットを格納する能力を提供することを含む、方法。
【請求項１４１】
第１の限度セットおよび第２の限度セットの１つまたは複数の中の値を選択的に格納することをさらに含む、請求項１４０に記載の方法。
【請求項１４２】
上限および下限の第１のセットおよび第２のセットを格納することにより、ハード上限およびソフト上限、およびハード下限およびソフト下限を作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４３】
第１の上限セットおよび第２の上限セットを格納することにより、ハード上限およびソフト上限だけを作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４４】
第１の下限セットおよび第２の下限セットを格納することにより、ハード下限およびソフト下限だけを作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４５】
ハード上限、ハード下限、ソフト上限、および／またはソフト下限の組み合わせを選択的に作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４６】
ハード上限、ハード下限、ソフト上限、ソフト下限の１つまたは複数の限度の組み合わせを使用して、限度セットを作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４７】
薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、
ホストコンピュータを提供すること、
ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、
ワークシートを構成すること、および
ワークシートを１つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
【請求項１４８】
カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項１４７に記載の方法。
【請求項１４９】
医療デバイスパラメータは、薬剤ライブラリを含む、請求項１４７に記載の方法。
【請求項１５０】
ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項１４７に記載の方法。
【請求項１５１】
ワークシートを構成することは、ハード限度およびソフト限度をセットアップすることを含む、請求項１４７に記載の方法。
【請求項１５２】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項１４７に記載の方法。
【請求項１５３】
データをワークシートに入力することをさらに含む、請求項１４７に記載の方法。
【請求項１５４】
ユーザによって入力されるデータは、リアルタイムで検証される、請求項１５３に記載の方法。
【請求項１５５】
データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項１５４に記載の方法。
【請求項１５６】
薬剤ライブラリが、ホストコンピュータから第２のコンピュータにエクスポートされる、請求項１４７に記載の方法。
【請求項１５７】
薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項１５６に記載の方法。
【請求項１５８】
薬剤ライブラリが、第２のコンピュータからホストコンピュータにインポートされる、請求項１４７に記載の方法。
【請求項１５９】
ワークシートの構成中にワークシートの少なくとも一部分を表示することをさらに含む、請求項１４７に記載の方法。
【請求項１６０】
基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示することをさらに含む、請求項１４７に記載の方法。
【請求項１６１】
ワークシートを構成することは、薬剤処方集を編集することを含む、請求項１４７に記載の方法。
【請求項１６２】
基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項１６１に記載の方法。
【請求項１６３】
ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項１４７に記載の方法。
【請求項１６４】
規則セットは、薬剤濃度および投与量に関連する規則を含む、請求項１６３に記載の方法。
【請求項１６５】
規則セットは、薬剤送達限度を定義する規則を含む、請求項１６３に記載の方法。
【請求項１６６】
規則セットは、薬物投与デバイスレベル規則を含む、請求項１６３に記載の方法。
【請求項１６７】
デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項１６６に記載の方法。
【請求項１６８】
規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項１６３に記載の方法。
【請求項１６９】
規則セットは、一部の患者に固有の患者レベル規則を含む、請求項１６３に記載の方法。
【請求項１７０】
薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、
ホストコンピュータを提供すること、
医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、
ワークシートにデータを入力することによってワークシートを構成すること、
入力されるデータをリアルタイムで検証すること、および
ワークシートを１つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
【請求項１７１】
カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項１７０に記載の方法。
【請求項１７２】
医療デバイスパラメータは、薬剤ライブラリを含む、請求項１７０に記載の方法。
【請求項１７３】
ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項１７０に記載の方法。
【請求項１７４】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項１７０に記載の方法。
【請求項１７５】
データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項１７０に記載の方法。
【請求項１７６】
薬剤ライブラリが、ホストコンピュータから第２のコンピュータにエクスポートされる、請求項１７０に記載の方法。
【請求項１７７】
薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項１７６に記載の方法。
【請求項１７８】
薬剤ライブラリが、第２のコンピュータからホストコンピュータにインポートされる、請求項１７０に記載の方法。
【請求項１７９】
ワークシートの構成中にワークシートの少なくとも一部分を表示することをさらに含む、請求項１７０に記載の方法。
【請求項１８０】
基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示することをさらに含む、請求項１７９に記載の方法。
【請求項１８１】
ワークシートを構成することは、薬剤処方集を編集することを含む、請求項１７０に記載の方法。
【請求項１８２】
基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項１８１に記載の方法。
【請求項１８３】
ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項１７０に記載の方法。
【請求項１８４】
規則セットは、薬剤濃度および投与量に関連する、請求項１８３に記載の方法。
【請求項１８５】
規則セットは、薬剤送達限度を定義する規則を含む、請求項１８３に記載の方法。
【請求項１８６】
規則セットは、薬物投与デバイスレベル規則を含む、請求項１８３に記載の方法。
【請求項１８７】
デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項１８６に記載の方法。
【請求項１８８】
規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項１８３に記載の方法。
【請求項１８９】
規則セットは、一部の患者に固有の患者レベル規則を含む、請求項１８３に記載の方法。
【請求項１９０】
薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、
ホストコンピュータを提供すること、
医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、
ワークシートを構成すること、
ワークシートの構成中にワークシートの少なくとも一部分を表示すること、
基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示すること、および
ワークシートを１つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
【請求項１９１】
カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項１９０に記載の方法。
【請求項１９２】
医療デバイスパラメータは、薬剤ライブラリを含む、請求項１９０に記載の方法。
【請求項１９３】
ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項１９０に記載の方法。
【請求項１９４】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項１９０に記載の方法。
【請求項１９５】
データをワークシートに入力することをさらに含む、請求項１９０に記載の方法。
【請求項１９６】
ユーザによって入力されるデータは、リアルタイムで検証される、請求項１９５に記載の方法。
【請求項１９７】
データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項１９６に記載の方法。
【請求項１９８】
薬剤ライブラリが、ホストコンピュータから第２のコンピュータにエクスポートされる、請求項１９０に記載の方法。
【請求項１９９】
薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項１９８に記載の方法。
【請求項２００】
薬剤ライブラリが、第２のコンピュータからホストコンピュータにインポートされる、請求項１９０に記載の方法。
【請求項２０１】
ワークシートを構成することは、薬剤処方集を編集することを含む、請求項１９０に記載の方法。
【請求項２０２】
基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項２０１に記載の方法。
【請求項２０３】
ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項１９０に記載の方法。
【請求項２０４】
規則セットは、薬剤濃度および投与量に関連する規則を含む、請求項２０３に記載の方法。
【請求項２０５】
規則セットは、薬剤送達限度を定義する規則を含む、請求項２０３に記載の方法。
【請求項２０６】
規則セットは、薬物投与デバイスレベル規則を含む、請求項２０３に記載の方法。
【請求項２０７】
デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項２０６に記載の方法。
【請求項２０８】
規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項２０３に記載の方法。
【請求項２０９】
規則セットは、一部の患者に固有の患者レベル規則を含む、請求項２０３に記載の方法。
【請求項２１０】
１名または複数名の患者に薬物を投与する方法であって、
ホストコンピュータを提供すること、
薬物投与デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションとをそれぞれが有する複数の薬物投与デバイスを提供すること、
ホストコンピュータと複数の薬物投与デバイスの間で通信リンクを提供すること、
ホストコンピュータと薬物投与デバイスの間で情報を交換すること、および
複数の薬物投与デバイスの動作に関連する１つまたは複数のレポートを生成することを含む、方法。
【請求項２１１】
複数の薬物投与デバイスは、イベントログをホストコンピュータに送信し、１つまたは複数の生成されたレポートは、薬物投与デバイスの少なくとも１つからのイベントログ情報を含む、請求項２１０に記載の方法。
【請求項２１２】
生成されたレポートは、複数の薬物投与デバイスからのイベントログに関連する統計データを含む、請求項２１１に記載の方法。
【請求項２１３】
複数の薬物投与デバイスは、デバイスパラメータ限度のユーザオーバライドに関連するオーバライドデータをログ記録する、請求項２１１に記載の方法。
【請求項２１４】
複数の薬物投与デバイスは、オーバライドデータログをホストコンピュータに送信し、レポートは、オーバライドデータログに基づいて生成される、請求項２１３に記載の方法。
【請求項２１５】
生成されたレポートは、ユーザが、デバイスパラメータ限度をオーバライドした回数を示す、請求項２１４に記載の方法。
【請求項２１６】
生成されたレポートは、ユーザが、デバイスパラメータ限度をオーバライドすることを断った回数を示す、請求項２１４に記載の方法。
【請求項２１７】
１つまたは複数のレポートは、薬物投与デバイス群の１つまたは複数のデバイスの動作に関連する情報を含む、請求項２１０に記載の方法。
【請求項２１８】
複数の薬物投与デバイスからの交換された情報を格納して、デバイス情報のデータベースを構築することをさらに含む、請求項２１０に記載の方法。
【請求項２１９】
所与の薬物投与デバイスセットによって投与された薬剤に関連する統計を含むレポートを生成することをさらに含む、請求項２１８に記載の方法。
【請求項２２０】
通信リンクは、有線ネットワークである、請求項２１０に記載の方法。
【請求項２２１】
通信リンクは、無線ネットワークである、請求項２１０に記載の方法。
【請求項２２２】
ホストコンピュータ、および複数の薬物投与デバイスは、拡張マークアップ言語（ＸＭＬ）を使用してメッセージをフォーマットする、請求項２１０に記載の方法。
【請求項２２３】
薬物投与デバイスは、輸液ポンプである、請求項２１０に記載の方法。
【請求項２２４】
医療デバイスパラメータを格納するためのメモリを有するホストコンピュータと、
ホストコンピュータと医療デバイスの間でデータを転送するためにホストコンピュータと医療デバイスとの間で形成された電気接続と、
ホストコンピュータのメモリにインポートするため、および医療デバイスにダウンロードするための、コンピュータ可読媒体上の医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートとを含む、医療デバイスシステム。
【請求項２２５】
医療デバイスを収容するための筐体をさらに含み、ホストコンピュータと医療デバイスの間の電気接続は、筐体内部のスロットの中に配置されたプラグアンドプレイモジュールを含む、請求項２２４に記載の医療デバイスシステム。
【請求項２２６】
医療デバイスは、プラグアンドプレイモジュールを受けるための筐体内部に形成されたスロットと、プラグアンドプレイモジュールを受けるための筐体内部のプラグとを備えた筐体を有する、請求項２２４に記載の医療デバイスシステム。
【請求項２２７】
医療デバイスを収容するための筐体をさらに含み、ホストコンピュータと医療デバイスの間の電気接続は、筐体内部に完全に密閉された接続エンジンを含み、ホストコンピュータと医療デバイスの間の電気接続が、無線であるようにしている、請求項２２４に記載の医療デバイスシステム。
【請求項２２８】
ホストコンピュータ間の電気接続は、データケーブルを含む、請求項２２４に記載の医療デバイスシステム。
【請求項２２９】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度を確立することを可能にする、請求項２２４に記載の医療デバイスシステム。
【請求項２３０】
ホストコンピュータと医療デバイスの間の電気接続は、無線である、請求項２２４に記載の医療デバイスシステム。
【請求項２３１】
ホストコンピュータと通信するための２つのアンテナをさらに含む、請求項２３０に記載の医療デバイスシステム。
【請求項２３２】
医療デバイス情報を格納するための記憶媒体を含むコンピュータ上で実行されるプログラムを格納するコンピュータ可読媒体であって、
医療デバイス情報は、デバイスパラメータを含む、前記デバイスパラメータでプログラマブル医療デバイスを、選択された臨床看護領域に基づいて構成するためのワークシートを含み、前記プログラムは、コンピュータに、
前記コンピュータのユーザが、ワークシートを選択することができるようにする機能と、
ユーザが、ハード限度とソフト限度の両方でワークシートをカスタマイズして、選択された臨床領域に基づく、ユーザによって策定されたデバイスパラメータを満たすようにすることができるようにする機能と、
ユーザが、ワークシートの一部分を医療デバイスに電子的にダウンロードすることができるようにする機能とを実行させる、媒体。
【請求項１】
少なくとも１つの薬物投与デバイスと通信する方法であって、
マシン可読フォーマットでデータを格納するために少なくとも１つの薬物投与デバイスに格納ロケーションを提供すること、
リモートデバイスと無線で通信するための無線インタフェースを提供すること、および
リモートデバイスから少なくとも１つの薬物投与デバイスに情報を無線で送信することを含み、情報は、拡張マークアップ言語を使用して送信される、方法。
【請求項２】
情報は、薬剤ライブラリに関するエントリを含む、請求項１に記載の方法。
【請求項３】
情報は、薬物投与デバイスパラメータを含む、請求項１に記載の方法。
【請求項４】
少なくとも１つの薬物投与デバイスを構成する複数の薬物投与デバイスを提供することをさらに含む、請求項１に記載の方法。
【請求項５】
無線インタフェースを提供することは、少なくとも１つのアンテナを提供することを含む、請求項１に記載の方法。
【請求項６】
少なくとも１つのアンテナを無線インタフェースケース内に収容することをさらに含む、請求項５に記載の方法。
【請求項７】
少なくとも１つのアンテナおよび格納ロケーションを薬物投与デバイスの筐体内に収容することをさらに含む、請求項５に記載の方法。
【請求項８】
無線インタフェースを提供することは、２つのアンテナを提供することを含む、請求項１に記載の方法。
【請求項９】
２つのアンテナは、空間的に異なる、請求項８に記載の方法。
【請求項１０】
２つのアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項８に記載の方法。
【請求項１１】
２つのアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項８に記載の方法。
【請求項１２】
薬物投与デバイスから情報を受信することをさらに含む、請求項１に記載の方法。
【請求項１３】
薬物投与デバイスから受信される情報は、イベントログを含む、請求項１２に記載の方法。
【請求項１４】
薬物投与デバイスは、輸液ポンプである、請求項１に記載の方法。
【請求項１５】
薬物投与デバイスは、患者自己管理鎮痛ポンプである、請求項１に記載の方法。
【請求項１６】
薬物投与デバイスは、歩行ポンプである、請求項１に記載の方法。
【請求項１７】
１つまたは複数の処方された薬物を患者に投与するための装置であって、
装置の動作を制御するためのコントローラと、
装置に関するデバイスパラメータをマシン可読フォーマットで格納するための、コントローラに電気的に結合された１つまたは複数の格納ロケーションと、
外部デバイスと無線で通信するための、コントローラに電気的に結合された無線インタフェースとを含む、装置。
【請求項１８】
装置は、輸液ポンプである、請求項１７に記載の装置。
【請求項１９】
１つまたは複数の格納ロケーションは、薬剤ライブラリを格納する、請求項１７に記載の装置。
【請求項２０】
無線インタフェースと外部デバイスの間の通信は、拡張マークアップ言語を使用する、請求項１７に記載の装置。
【請求項２１】
装置は、無線インタフェースに結合されたアンテナをさらに含む、請求項１７に記載の装置。
【請求項２２】
装置は、コントローラと、１つまたは複数の格納ロケーションと、無線インタフェースと、アンテナとを収容する筐体をさらに含む、請求項２１に記載の装置。
【請求項２３】
装置は、無線インタフェースに結合された第１のアンテナと第２のアンテナとをさらに含む、請求項２１に記載の装置。
【請求項２４】
第１のアンテナと第２のアンテナは、空間的に異なる、請求項２３に記載の装置。
【請求項２５】
第１のアンテナと第２のアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項２３に記載の装置。
【請求項２６】
第１のアンテナと第２のアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項２３に記載の装置。
【請求項２７】
装置は、コントローラと、１つまたは複数の格納ロケーションと、無線インタフェースと、第１のアンテナと、第２のアンテナとを収容する筐体をさらに含む、請求項２６に記載の装置。
【請求項２８】
１名または複数名の患者に薬物を投与するための方法であって、
薬物投与デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションと、無線インタフェースとをそれぞれが有する複数の薬物投与デバイスを提供すること、
ホストコンピュータを提供すること、
ホストコンピュータ上で薬剤ライブラリを構成すること、および
ホストコンピュータ上の薬剤ライブラリから、無線インタフェースを介して、薬物投与デバイスの少なくともいくつかに情報を送信することを含む、方法。
【請求項２９】
情報は、薬物投与デバイスの１つだけにポイントツーポイントの形で送信される、請求項２８に記載の方法。
【請求項３０】
情報は、薬物投与デバイスのすべてに同時にブロードキャストされる、請求項２８に記載の方法。
【請求項３１】
ホストコンピュータから受信された情報に少なくとも部分的に基づき、患者に薬剤を投与することをさらに含む、請求項２８に記載の方法。
【請求項３２】
情報は、拡張マークアップ言語を使用して薬物投与デバイスに送信される、請求項２８に記載の方法。
【請求項３３】
筐体内に少なくとも１つのアンテナを収容することをさらに含む、請求項２８に記載の方法。
【請求項３４】
筐体は、コントローラ、および薬物投与デバイスの１つまたは複数の格納ロケーションも収容する、請求項３３に記載の方法。
【請求項３５】
薬物投与デバイスの無線インタフェースのための２つのアンテナを提供することをさらに含む、請求項２８に記載の方法。
【請求項３６】
２つのアンテナは、空間的に異なる、請求項３５に記載の方法。
【請求項３７】
２つのアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項３５に記載の方法。
【請求項３８】
２つのアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項３５に記載の方法。
【請求項３９】
薬物投与デバイスは、輸液ポンプである、請求項２８に記載の方法。
【請求項４０】
薬物投与デバイスは、患者自己管理鎮痛ポンプである、請求項２８に記載の方法。
【請求項４１】
薬物投与デバイスは、歩行ポンプである、請求項２８に記載の方法。
【請求項４２】
薬物投与デバイスからホストコンピュータに情報を送信することをさらに含む、請求項２８に記載の方法。
【請求項４３】
情報は、拡張マークアップ言語を使用して薬物投与デバイスからホストコンピュータに送信される、請求項４２に記載の方法。
【請求項４４】
ホストコンピュータによって受信される情報は、イベントログを含む、請求項４３に記載の方法。
【請求項４５】
薬物投与デバイスによって送信された情報から１つまたは複数のレポートを生成することをさらに含む、請求項４３に記載の方法。
【請求項４６】
１つまたは複数のレポートは、イベントログからの情報を含む、請求項４５に記載の方法。
【請求項４７】
１つまたは複数のレポートは、薬物投与デバイスの動作に関連する情報を含む、請求項４５に記載の方法。
【請求項４８】
薬剤ライブラリから情報を送信するステップは、薬物に関するハード限度を提供することを含む、請求項２８に記載の方法。
【請求項４９】
薬剤ライブラリから情報を送信するステップは、薬物に関するソフト限度を提供することを含む、請求項２８に記載の方法。
【請求項５０】
薬剤ライブラリから情報を送信するステップは、薬物に関するハード限度とソフト限度の両方を提供することを含む、請求項２８に記載の方法。
【請求項５１】
１つまたは複数の薬物投与デバイスと通信する方法であって、
ホストコンピュータを提供すること、
１つまたは複数の薬物投与デバイスを提供すること、
拡張マークアップ言語（ＸＭＬ）を使用してメッセージをフォーマットすること、および
ＸＭＬフォーマットされたメッセージを、ホストコンピュータから１つまたは複数の薬物投与デバイスの少なくとも１つに送信することを含む、方法。
【請求項５２】
ＸＭＬフォーマットされたメッセージを１つまたは複数の薬物投与デバイスの１つからホストコンピュータに送信することをさらに含む、請求項５１に記載の方法。
【請求項５３】
受信されたＸＭＬフォーマットされたメッセージを解析して、ホストコンピュータによって送信された情報を獲得することをさらに含む、請求項５１に記載の方法。
【請求項５４】
ＸＭＬフォーマットされたメッセージは、無線で送信される、請求項５１に記載の方法。
【請求項５５】
メッセージをフォーマットすることは、
１つまたは複数のＸＭＬ識別子を使用してメッセージをフォーマットすること、および
１つまたは複数のＸＭＬ識別子を短縮して、ＸＭＬフォーマットされたメッセージを送信するのに要求される帯域幅を低減することをさらに含む、請求項５１に記載の方法。
【請求項５６】
ホストコンピュータ上に薬剤ライブラリを格納することをさらに含む、請求項５１に記載の方法。
【請求項５７】
ＸＭＬフォーマットされたメッセージは、格納された薬剤ライブラリからの情報を含む、請求項５６に記載の方法。
【請求項５８】
１つまたは複数の薬物投与デバイスは、輸液ポンプである、請求項５１に記載の方法。
【請求項５９】
メッセージは、正規形式になっている、請求項５１に記載の方法。
【請求項６０】
メッセージの中に含まれる情報を検証することをさらに含む、請求項５１に記載の方法。
【請求項６１】
情報は、ＸＭＬスキーマを使用して検証される、請求項６０に記載の方法。
【請求項６２】
情報を検証するステップは、ホストコンピュータからの情報の正規表現を、メッセージを受信した１つまたは複数の薬物投与デバイスの少なくとも１つからの情報の正規表現と比較するステップをさらに含む、請求項６０に記載の方法。
【請求項６３】
検証された情報は、複数のビットを含み、正規表現は、右から左へのビット順序を使用して生成される、請求項６２に記載の方法。
【請求項６４】
ホストコンピュータおよび薬物投与デバイスによって格納されたデータを検証することをさらに含む、請求項５１に記載の方法。
【請求項６５】
データを検証するステップは、ホストコンピュータによって格納されたデータの正規表現を、薬物投与デバイスによって格納されたデータの正規表現と比較するステップをさらに含む、請求項６４に記載の方法。
【請求項６６】
１名または複数名の患者に薬物を投与する方法であって、
ホストコンピュータを提供すること、
薬剤ライブラリを構成する薬剤送達情報を格納するように、ホストコンピュータを使用すること、
格納された薬剤送達情報に関連するデータ含むメッセージを生成するように、拡張マークアップ言語（ＸＭＬ）を使用すること、
生成されたメッセージを薬物投与デバイスに送信すること、
格納された薬剤送達情報からデータを抽出するように、送信されたメッセージを薬物投与デバイスにおいて解析すること、および
抽出されたデータに少なくとも部分的に基づき、薬物投与デバイスを使用して薬物を患者に投与することを含む、方法。
【請求項６７】
薬物投与デバイスは、輸液ポンプである、請求項６６に記載の方法。
【請求項６８】
メッセージは、無線で薬物投与デバイスに送信される、請求項６６に記載の方法。
【請求項６９】
薬物投与デバイスにおいてメッセージを生成するように、拡張マークアップ言語（ＸＭＬ）を使用することをさらに含む、請求項６６に記載の方法。
【請求項７０】
メッセージを薬物投与デバイスからホストコンピュータに送信することをさらに含む、請求項６９に記載の方法。
【請求項７１】
薬物投与デバイスは、患者に薬物を投与するための１つまたは複数のポンプを含み、方法が、
抽出されたデータに少なくとも部分的に基づき、１つまたは複数のポンプの動作を制御することをさらに含む、請求項６６に記載の方法。
【請求項７２】
薬剤送達情報は、１つまたは複数の薬剤ライブラリを含む、請求項６６に記載の方法。
【請求項７３】
複数の薬物投与デバイスに薬剤ライブラリをダウンロードする方法であって、
複数の薬物投与デバイスを提供すること、
ホストコンピュータを提供すること、
薬剤ライブラリをホストコンピュータに格納すること、
ホストコンピュータと複数の薬物投与デバイスの間の通信を提供するように、拡張マークアップ言語（ＸＭＬ）を使用すること、および
ホストコンピュータから、格納された薬剤ライブラリに関連する情報を複数の薬物投与デバイスに送信することを含む、方法。
【請求項７４】
複数の薬物投与デバイスに送信される情報は、タグ付きである、請求項７３に記載の方法。
【請求項７５】
各薬物投与デバイスは、情報の諸部分を選択的に利用するように、タグを使用する、請求項７４に記載の方法。
【請求項７６】
各薬物投与デバイスは、情報の諸部分を選択的に利用するべく、情報を解析するのにタグを使用する、請求項７４に記載の方法。
【請求項７７】
送信された情報は、薬剤ライブラリ全体を含む、請求項７４に記載の方法。
【請求項７８】
送信された情報は、薬剤ライブラリのサブセットだけを含む、請求項７４に記載の方法。
【請求項７９】
薬剤ライブラリは、複数の薬物投与デバイスに同時にダウンロードされる、請求項７３に記載の方法。
【請求項８０】
薬剤ライブラリがダウンロードされる間に、複数の薬物投与デバイスに送信されるメッセージは、タグ付きである、請求項７９に記載の方法。
【請求項８１】
薬物投与デバイスの１つが、ダウンロードエラーを報告した場合、薬剤ライブラリダウンロードを停止し、後に、薬剤ライブラリダウンロードを続けることをさらに含む、請求項８０に記載の方法。
【請求項８２】
薬剤ライブラリダウンロードは、２回目、タグ付きメッセージの少なくとも一部をダウンロードすることなしに、続けられる、請求項８１に記載の方法。
【請求項８３】
薬剤ライブラリダウンロードは、いずれの薬物投与デバイスも、ダウンロードエラーを報告していなかった時点から続けられる、請求項８２に記載の方法。
【請求項８４】
薬物投与デバイスは、輸液ポンプである、請求項８３に記載の方法。
【請求項８５】
複数の異なるタイプの薬物投与デバイスと通信する方法であって、
ホストコンピュータを提供すること、
第１のタイプの薬物投与デバイスを提供すること、
第２のタイプの薬物投与デバイスを提供すること、
複数の薬物投与デバイスの動作に関連するデータをホストコンピュータ上に格納すること、および
薬物投与デバイスと通信することを含み、ホストコンピュータと薬物投与デバイスの間の通信は、拡張マークアップ言語（ＸＭＬ）を使用してフォーマットされたメッセージを使用する、方法。
【請求項８６】
第１のタイプの薬物投与デバイスは、第２のタイプの薬物投与デバイスによって使用されるコンピュータアーキテクチャとは異なるコンピュータアーキテクチャを使用する、請求項８５に記載の方法。
【請求項８７】
第１のタイプの薬物投与デバイスは、第１のタイプのコンピュータプロセッサを使用し、第２のタイプの薬物投与デバイスは、第２のタイプのコンピュータプロセッサを使用する、請求項８５に記載の方法。
【請求項８８】
第１のタイプの薬物投与デバイスは、第２のタイプの薬物投与デバイス上で実行されるソフトウェアとは異なるソフトウェアを実行する、請求項８５に記載の方法。
【請求項８９】
第１のタイプの薬物投与デバイスは、第２のタイプの薬物投与デバイスによって使用されるバイナリフォーマットと互換性のないバイナリデータフォーマットを使用する、請求項８５に記載の方法。
【請求項９０】
前記メッセージは、ホストコンピュータと薬物投与デバイスの間の通信が正規形式に変換される際に使用される、請求項８５に記載の方法。
【請求項９１】
ホストコンピュータと薬物投与デバイスの間の通信は、無線である、請求項８５に記載の方法。
【請求項９２】
ホストコンピュータ上にデータを格納することは、ホストコンピュータ上に薬剤ライブラリを格納することをさらに含む、請求項８５に記載の方法。
【請求項９３】
同一の格納された薬剤ライブラリが、複数の薬物投与デバイスにダウンロードされる、請求項９２に記載の方法。
【請求項９４】
同一の格納された薬剤ライブラリが、少なくともいくつかは、異なるタイプの薬物投与デバイスである複数の薬物投与デバイスにダウンロードされる、請求項９２に記載の方法。
【請求項９５】
格納された薬剤ライブラリの少なくとも一部分が、複数の薬物投与デバイスにダウンロードされる、請求項９２に記載の方法。
【請求項９６】
薬物投与デバイスを制御する方法であって、
デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションとを有する薬物投与デバイスを提供すること、
第１の薬剤のパラメータの第１の上限値および第１の下限値を定義する第１の限度セットを格納すること、および
第１の薬剤のパラメータの第２の上限値および第２の下限値を定義する第２の限度セットを格納することを含む、方法。
【請求項９７】
薬物投与デバイスが、薬剤を投与するのに使用される際、パラメータの第１の限度セットおよび第２の限度セットをパラメータの実際の値と比較する請求項９６に記載の方法。
【請求項９８】
パラメータの値が、第１の限度、または第２の限度の範囲内にない場合、警告を表示することをさらに含む、請求項９７に記載の方法。
【請求項９９】
第１の限度セットは、第２の限度セットの範囲内に入る、請求項９７に記載の方法。
【請求項１００】
パラメータの値が、第２の限度の範囲外にある場合、薬物投与デバイスは、所与の薬剤を投与することを許されない、請求項９８に記載の方法。
【請求項１０１】
第２の限度セットは、権限が付与された個人によってオーバライドされることが可能である、請求項１００に記載の方法。
【請求項１０２】
第２の限度セットがオーバライドされた回数の記録をとることをさらに含む、請求項１０１に記載の方法。
【請求項１０３】
第２の限度セットに関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項１０２に記載の方法。
【請求項１０４】
パラメータの値が、第１の限度の範囲外であり、かつ、パラメータの値が、第２の限度の範囲内であった場合、薬物投与デバイスは、所与の薬剤を投与することを許されない、請求項９７に記載の方法。
【請求項１０５】
第１の第２の限度セットは、権限が付与された個人によってオーバライドされることが可能である請求項１０４に記載の方法。
【請求項１０６】
第２の限度セットがオーバライドされた回数の記録をとることをさらに含む、請求項１０５に記載の方法。
【請求項１０７】
第２の限度セットに関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項１０５に記載の方法。
【請求項１０８】
第１の限度セットは、ソフト限度であり、第２の限度セットは、ハード限度である、請求項９６に記載の方法。
【請求項１０９】
各薬剤は、病院における異なる臨床看護領域に関して、異なるハード限度、および異なるソフト限度を有することが可能である、請求項１０８に記載の方法。
【請求項１１０】
薬剤のパラメータは、投与速度（ｄｏｓａｇｅ ｒａｔｅ）に関連する、請求項９６に記載の方法。
【請求項１１１】
薬剤のパラメータは、薬用量（ｄｏｓｅ）に関連する、請求項９６に記載の方法。
【請求項１１２】
薬剤のパラメータは、投与（ｄｏｓａｇｅ）量に関連する、請求項９６に記載の方法。
【請求項１１３】
薬剤のパラメータは、薬剤量に関連する、請求項９６に記載の方法。
【請求項１１４】
薬剤のパラメータは、希釈液量に関連する、請求項９６に記載の方法。
【請求項１１５】
薬剤のパラメータは、投薬速度に関連する、請求項９６に記載の方法。
【請求項１１６】
薬剤のパラメータは、薬剤送達時間に関連する、請求項９６に記載の方法。
【請求項１１７】
薬剤のパラメータは、薬剤濃度に関連する、請求項９６に記載の方法。
【請求項１１８】
薬剤のパラメータは、患者の体重に関連する、請求項９６に記載の方法。
【請求項１１９】
薬剤のパラメータは、患者の体表面積に関連する、請求項９６に記載の方法。
【請求項１２０】
薬物投与デバイスは、輸液ポンプである、請求項９６に記載の方法。
【請求項１２１】
薬剤のパラメータは、輸液されるべき量（ＶＴＢＩ）に関連する、請求項９６に記載の方法。
【請求項１２２】
患者に１つまたは複数の薬物を投与するための装置であって、
コントローラと、
コントローラに電気的に結合された１つまたは複数の格納ロケーションと、
装置の動作を制御するための、１つまたは複数の格納ロケーションに格納された制御情報とを含み、制御情報は、動作パラメータの値の第１の範囲を定義するソフト限度セットと、動作パラメータの値の第２の範囲を定義するハード限度セットとを含む、装置。
【請求項１２３】
ソフト限度セットは、ハード限度の範囲内に入る、請求項１２２に記載の装置。
【請求項１２４】
コントローラは、動作パラメータの値をハード限度およびソフト限度と比較する、請求項１２２に記載の装置。
【請求項１２５】
コントローラは、動作パラメータの値が、ハード限度およびソフト限度の範囲内にない場合、メッセージを表示する、請求項１２２に記載の装置。
【請求項１２６】
コントローラは、動作パラメータが、ハード限度の範囲を外れた場合、ユーザが、患者に薬物を投与するのを防止する、請求項１２２に記載の装置。
【請求項１２７】
ハード限度は、権限が付与された個人によってオーバライドされることが可能である、請求項１２６に記載の装置。
【請求項１２８】
ハード限度がオーバライドされた回数は、コントローラによって記録をとられる、請求項１２７に記載の装置。
【請求項１２９】
ハード限度に関連する情報、および記録をとられた情報を含むレポートが生成される、請求項１２８に記載の装置。
【請求項１３０】
コントローラは、動作パラメータの値が、ハード限度の範囲内にあるが、ソフト限度の範囲外にある場合、メッセージを表示する、請求項１２５に記載の装置。
【請求項１３１】
コントローラは、動作パラメータの値が、ハード限度の範囲内にあるが、ソフト限度の範囲外にある場合、ソフト限度をオーバライドすることを確認するよう、ユーザに要求する、請求項１２５に記載の装置。
【請求項１３２】
コントローラは、ソフト限度がオーバライドされた回数の記録をとる、請求項１３１に記載の装置。
【請求項１３３】
ソフト限度に関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項１３２に記載の装置。
【請求項１３４】
動作パラメータは、薬剤投与速度に関連する、請求項１２２に記載の装置。
【請求項１３５】
動作パラメータは、薬剤送達時間に関連する、請求項１２２に記載の装置。
【請求項１３６】
動作パラメータは、薬剤濃度に関連する、請求項１２２に記載の装置。
【請求項１３７】
動作パラメータは、患者の体重に関連する、請求項１２２に記載の装置。
【請求項１３８】
動作パラメータは、輸液されるべき薬剤量に関連する、請求項１２２に記載の装置。
【請求項１３９】
装置は、輸液ポンプである、請求項１２２に記載の装置。
【請求項１４０】
薬物投与デバイスを制御する方法であって、
デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションとを有する薬物投与デバイスを提供すること、
第１の薬剤のパラメータの第１の上限値および第１の下限値を定義する第１の限度セットを格納する能力を提供すること、および
第１の薬剤のパラメータの第２の上限値および第２の下限値を定義する第２の限度セットを格納する能力を提供することを含む、方法。
【請求項１４１】
第１の限度セットおよび第２の限度セットの１つまたは複数の中の値を選択的に格納することをさらに含む、請求項１４０に記載の方法。
【請求項１４２】
上限および下限の第１のセットおよび第２のセットを格納することにより、ハード上限およびソフト上限、およびハード下限およびソフト下限を作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４３】
第１の上限セットおよび第２の上限セットを格納することにより、ハード上限およびソフト上限だけを作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４４】
第１の下限セットおよび第２の下限セットを格納することにより、ハード下限およびソフト下限だけを作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４５】
ハード上限、ハード下限、ソフト上限、および／またはソフト下限の組み合わせを選択的に作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４６】
ハード上限、ハード下限、ソフト上限、ソフト下限の１つまたは複数の限度の組み合わせを使用して、限度セットを作成することをさらに含む、請求項１４０に記載の方法。
【請求項１４７】
薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、
ホストコンピュータを提供すること、
ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、
ワークシートを構成すること、および
ワークシートを１つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
【請求項１４８】
カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項１４７に記載の方法。
【請求項１４９】
医療デバイスパラメータは、薬剤ライブラリを含む、請求項１４７に記載の方法。
【請求項１５０】
ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項１４７に記載の方法。
【請求項１５１】
ワークシートを構成することは、ハード限度およびソフト限度をセットアップすることを含む、請求項１４７に記載の方法。
【請求項１５２】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項１４７に記載の方法。
【請求項１５３】
データをワークシートに入力することをさらに含む、請求項１４７に記載の方法。
【請求項１５４】
ユーザによって入力されるデータは、リアルタイムで検証される、請求項１５３に記載の方法。
【請求項１５５】
データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項１５４に記載の方法。
【請求項１５６】
薬剤ライブラリが、ホストコンピュータから第２のコンピュータにエクスポートされる、請求項１４７に記載の方法。
【請求項１５７】
薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項１５６に記載の方法。
【請求項１５８】
薬剤ライブラリが、第２のコンピュータからホストコンピュータにインポートされる、請求項１４７に記載の方法。
【請求項１５９】
ワークシートの構成中にワークシートの少なくとも一部分を表示することをさらに含む、請求項１４７に記載の方法。
【請求項１６０】
基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示することをさらに含む、請求項１４７に記載の方法。
【請求項１６１】
ワークシートを構成することは、薬剤処方集を編集することを含む、請求項１４７に記載の方法。
【請求項１６２】
基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項１６１に記載の方法。
【請求項１６３】
ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項１４７に記載の方法。
【請求項１６４】
規則セットは、薬剤濃度および投与量に関連する規則を含む、請求項１６３に記載の方法。
【請求項１６５】
規則セットは、薬剤送達限度を定義する規則を含む、請求項１６３に記載の方法。
【請求項１６６】
規則セットは、薬物投与デバイスレベル規則を含む、請求項１６３に記載の方法。
【請求項１６７】
デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項１６６に記載の方法。
【請求項１６８】
規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項１６３に記載の方法。
【請求項１６９】
規則セットは、一部の患者に固有の患者レベル規則を含む、請求項１６３に記載の方法。
【請求項１７０】
薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、
ホストコンピュータを提供すること、
医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、
ワークシートにデータを入力することによってワークシートを構成すること、
入力されるデータをリアルタイムで検証すること、および
ワークシートを１つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
【請求項１７１】
カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項１７０に記載の方法。
【請求項１７２】
医療デバイスパラメータは、薬剤ライブラリを含む、請求項１７０に記載の方法。
【請求項１７３】
ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項１７０に記載の方法。
【請求項１７４】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項１７０に記載の方法。
【請求項１７５】
データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項１７０に記載の方法。
【請求項１７６】
薬剤ライブラリが、ホストコンピュータから第２のコンピュータにエクスポートされる、請求項１７０に記載の方法。
【請求項１７７】
薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項１７６に記載の方法。
【請求項１７８】
薬剤ライブラリが、第２のコンピュータからホストコンピュータにインポートされる、請求項１７０に記載の方法。
【請求項１７９】
ワークシートの構成中にワークシートの少なくとも一部分を表示することをさらに含む、請求項１７０に記載の方法。
【請求項１８０】
基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示することをさらに含む、請求項１７９に記載の方法。
【請求項１８１】
ワークシートを構成することは、薬剤処方集を編集することを含む、請求項１７０に記載の方法。
【請求項１８２】
基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項１８１に記載の方法。
【請求項１８３】
ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項１７０に記載の方法。
【請求項１８４】
規則セットは、薬剤濃度および投与量に関連する、請求項１８３に記載の方法。
【請求項１８５】
規則セットは、薬剤送達限度を定義する規則を含む、請求項１８３に記載の方法。
【請求項１８６】
規則セットは、薬物投与デバイスレベル規則を含む、請求項１８３に記載の方法。
【請求項１８７】
デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項１８６に記載の方法。
【請求項１８８】
規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項１８３に記載の方法。
【請求項１８９】
規則セットは、一部の患者に固有の患者レベル規則を含む、請求項１８３に記載の方法。
【請求項１９０】
薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、
ホストコンピュータを提供すること、
医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、
ワークシートを構成すること、
ワークシートの構成中にワークシートの少なくとも一部分を表示すること、
基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示すること、および
ワークシートを１つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
【請求項１９１】
カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項１９０に記載の方法。
【請求項１９２】
医療デバイスパラメータは、薬剤ライブラリを含む、請求項１９０に記載の方法。
【請求項１９３】
ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項１９０に記載の方法。
【請求項１９４】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項１９０に記載の方法。
【請求項１９５】
データをワークシートに入力することをさらに含む、請求項１９０に記載の方法。
【請求項１９６】
ユーザによって入力されるデータは、リアルタイムで検証される、請求項１９５に記載の方法。
【請求項１９７】
データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項１９６に記載の方法。
【請求項１９８】
薬剤ライブラリが、ホストコンピュータから第２のコンピュータにエクスポートされる、請求項１９０に記載の方法。
【請求項１９９】
薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項１９８に記載の方法。
【請求項２００】
薬剤ライブラリが、第２のコンピュータからホストコンピュータにインポートされる、請求項１９０に記載の方法。
【請求項２０１】
ワークシートを構成することは、薬剤処方集を編集することを含む、請求項１９０に記載の方法。
【請求項２０２】
基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項２０１に記載の方法。
【請求項２０３】
ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項１９０に記載の方法。
【請求項２０４】
規則セットは、薬剤濃度および投与量に関連する規則を含む、請求項２０３に記載の方法。
【請求項２０５】
規則セットは、薬剤送達限度を定義する規則を含む、請求項２０３に記載の方法。
【請求項２０６】
規則セットは、薬物投与デバイスレベル規則を含む、請求項２０３に記載の方法。
【請求項２０７】
デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項２０６に記載の方法。
【請求項２０８】
規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項２０３に記載の方法。
【請求項２０９】
規則セットは、一部の患者に固有の患者レベル規則を含む、請求項２０３に記載の方法。
【請求項２１０】
１名または複数名の患者に薬物を投与する方法であって、
ホストコンピュータを提供すること、
薬物投与デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための１つまたは複数の格納ロケーションとをそれぞれが有する複数の薬物投与デバイスを提供すること、
ホストコンピュータと複数の薬物投与デバイスの間で通信リンクを提供すること、
ホストコンピュータと薬物投与デバイスの間で情報を交換すること、および
複数の薬物投与デバイスの動作に関連する１つまたは複数のレポートを生成することを含む、方法。
【請求項２１１】
複数の薬物投与デバイスは、イベントログをホストコンピュータに送信し、１つまたは複数の生成されたレポートは、薬物投与デバイスの少なくとも１つからのイベントログ情報を含む、請求項２１０に記載の方法。
【請求項２１２】
生成されたレポートは、複数の薬物投与デバイスからのイベントログに関連する統計データを含む、請求項２１１に記載の方法。
【請求項２１３】
複数の薬物投与デバイスは、デバイスパラメータ限度のユーザオーバライドに関連するオーバライドデータをログ記録する、請求項２１１に記載の方法。
【請求項２１４】
複数の薬物投与デバイスは、オーバライドデータログをホストコンピュータに送信し、レポートは、オーバライドデータログに基づいて生成される、請求項２１３に記載の方法。
【請求項２１５】
生成されたレポートは、ユーザが、デバイスパラメータ限度をオーバライドした回数を示す、請求項２１４に記載の方法。
【請求項２１６】
生成されたレポートは、ユーザが、デバイスパラメータ限度をオーバライドすることを断った回数を示す、請求項２１４に記載の方法。
【請求項２１７】
１つまたは複数のレポートは、薬物投与デバイス群の１つまたは複数のデバイスの動作に関連する情報を含む、請求項２１０に記載の方法。
【請求項２１８】
複数の薬物投与デバイスからの交換された情報を格納して、デバイス情報のデータベースを構築することをさらに含む、請求項２１０に記載の方法。
【請求項２１９】
所与の薬物投与デバイスセットによって投与された薬剤に関連する統計を含むレポートを生成することをさらに含む、請求項２１８に記載の方法。
【請求項２２０】
通信リンクは、有線ネットワークである、請求項２１０に記載の方法。
【請求項２２１】
通信リンクは、無線ネットワークである、請求項２１０に記載の方法。
【請求項２２２】
ホストコンピュータ、および複数の薬物投与デバイスは、拡張マークアップ言語（ＸＭＬ）を使用してメッセージをフォーマットする、請求項２１０に記載の方法。
【請求項２２３】
薬物投与デバイスは、輸液ポンプである、請求項２１０に記載の方法。
【請求項２２４】
医療デバイスパラメータを格納するためのメモリを有するホストコンピュータと、
ホストコンピュータと医療デバイスの間でデータを転送するためにホストコンピュータと医療デバイスとの間で形成された電気接続と、
ホストコンピュータのメモリにインポートするため、および医療デバイスにダウンロードするための、コンピュータ可読媒体上の医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートとを含む、医療デバイスシステム。
【請求項２２５】
医療デバイスを収容するための筐体をさらに含み、ホストコンピュータと医療デバイスの間の電気接続は、筐体内部のスロットの中に配置されたプラグアンドプレイモジュールを含む、請求項２２４に記載の医療デバイスシステム。
【請求項２２６】
医療デバイスは、プラグアンドプレイモジュールを受けるための筐体内部に形成されたスロットと、プラグアンドプレイモジュールを受けるための筐体内部のプラグとを備えた筐体を有する、請求項２２４に記載の医療デバイスシステム。
【請求項２２７】
医療デバイスを収容するための筐体をさらに含み、ホストコンピュータと医療デバイスの間の電気接続は、筐体内部に完全に密閉された接続エンジンを含み、ホストコンピュータと医療デバイスの間の電気接続が、無線であるようにしている、請求項２２４に記載の医療デバイスシステム。
【請求項２２８】
ホストコンピュータ間の電気接続は、データケーブルを含む、請求項２２４に記載の医療デバイスシステム。
【請求項２２９】
ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度を確立することを可能にする、請求項２２４に記載の医療デバイスシステム。
【請求項２３０】
ホストコンピュータと医療デバイスの間の電気接続は、無線である、請求項２２４に記載の医療デバイスシステム。
【請求項２３１】
ホストコンピュータと通信するための２つのアンテナをさらに含む、請求項２３０に記載の医療デバイスシステム。
【請求項２３２】
医療デバイス情報を格納するための記憶媒体を含むコンピュータ上で実行されるプログラムを格納するコンピュータ可読媒体であって、
医療デバイス情報は、デバイスパラメータを含む、前記デバイスパラメータでプログラマブル医療デバイスを、選択された臨床看護領域に基づいて構成するためのワークシートを含み、前記プログラムは、コンピュータに、
前記コンピュータのユーザが、ワークシートを選択することができるようにする機能と、
ユーザが、ハード限度とソフト限度の両方でワークシートをカスタマイズして、選択された臨床領域に基づく、ユーザによって策定されたデバイスパラメータを満たすようにすることができるようにする機能と、
ユーザが、ワークシートの一部分を医療デバイスに電子的にダウンロードすることができるようにする機能とを実行させる、媒体。
【図１Ａ】
【図１Ｂ】
【図１Ｃ】
【図１Ｄ】
【図１Ｅ】
【図１Ｆ】
【図１Ｇ】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図７Ｅ】
【図７Ｆ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１２Ｄ】
【図１３】
【図１４】
【図１５Ａ】
【図１５Ｂ】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１７Ｃ】
【図１８】
【図１９】
【図２０Ａ】
【図２０Ｂ】
【図２１】
【図２２】
【図２３】
【図２４Ａ】
【図２４Ｂ】
【図２５】
【図２６】
【図１Ｂ】
【図１Ｃ】
【図１Ｄ】
【図１Ｅ】
【図１Ｆ】
【図１Ｇ】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図７Ｄ】
【図７Ｅ】
【図７Ｆ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１２Ｄ】
【図１３】
【図１４】
【図１５Ａ】
【図１５Ｂ】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１７Ｃ】
【図１８】
【図１９】
【図２０Ａ】
【図２０Ｂ】
【図２１】
【図２２】
【図２３】
【図２４Ａ】
【図２４Ｂ】
【図２５】
【図２６】
【公開番号】特開２０１２−１９６４６２（Ｐ２０１２−１９６４６２Ａ）
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−１０７２５４（Ｐ２０１２−１０７２５４）
【出願日】平成２４年５月９日（２０１２．５．９）
【分割の表示】特願２００６−５３９９２４（Ｐ２００６−５３９９２４）の分割
【原出願日】平成１６年１１月１２日（２００４．１１．１２）
【出願人】（５０４３０８４４２）ホスピラ・インコーポレイテツド (50)
【Ｆターム（参考）】
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【出願番号】特願２０１２−１０７２５４（Ｐ２０１２−１０７２５４）
【出願日】平成２４年５月９日（２０１２．５．９）
【分割の表示】特願２００６−５３９９２４（Ｐ２００６−５３９９２４）の分割
【原出願日】平成１６年１１月１２日（２００４．１１．１２）
【出願人】（５０４３０８４４２）ホスピラ・インコーポレイテツド (50)
【Ｆターム（参考）】
[ Back to top ]