(57)【特許請求の範囲】
【請求項１】
少なくとも１つの薬物送達デバイスと、
メモリおよびユーザインタフェースを含むホストコンピュータと、
ホストコンピュータを少なくとも１つの薬物送達デバイスにそれらの間でのデータ転送のために接続する通信ネットワークとを備え、
ユーザインタフェースは、少なくとも１つの薬物送達デバイスを構成するために少なくとも１つの薬物送達デバイスへのダウンロードのための、ユーザから複数の薬剤エントリを受け取ってユーザカスタマイズ可能な薬剤ライブラリを形成するように適合され、
ユーザカスタマイズ可能な薬剤ライブラリは、それぞれ少なくともいくつかの特定の薬剤エントリと関連付けられた薬物送達デバイス構成パラメータを有する複数の薬剤エントリを含み、各特定の薬剤エントリは、特定の薬剤に関連し、
ユーザカスタマイズ可能な薬剤ライブラリは、特定されていない薬剤エントリと関連付けられた薬物送達デバイス構成パラメータを有する特定されていない薬剤エントリも含み、特定されていない薬剤エントリは、特定の薬剤には関連しない、薬物送達デバイスシステム。
【請求項２】
ユーザインタフェースが、複数の臨床看護領域のプルダウンメニューリストを表示し、ユーザが、複数の臨床看護領域の１つを選択し、かつユーザカスタマイズ可能な薬剤ライブラリに追加／保存されることになる薬剤エントリの一部として規則セットおよびインフューザ設定値のそれぞれ１つを入力できるようにする、請求項１に記載のシステム。
【請求項３】
ユーザインタフェースが、複数の薬剤分類のプルダウンメニューリストを表示し、ユーザが、複数の薬剤分類の１つを選択し、かつユーザカスタマイズ可能な薬剤ライブラリに追加／保存されることになる薬剤エントリの一部として規則セットおよびインフューザ設定値のそれぞれ１つを入力できるようにする、請求項１に記載のシステム。
【請求項４】
ユーザインタフェースが、複数の薬剤単位のプルダウンメニューリストを表示し、ユーザが、複数の薬剤単位の１つを選択し、かつユーザカスタマイズ可能な薬剤ライブラリに追加／保存されることになる薬剤エントリの一部として規則セットおよびインフューザ設定値のそれぞれ１つを入力できるようにする、請求項１に記載のシステム。
【請求項５】
ユーザインタフェースが、複数の投与単位のプルダウンメニューリストを表示し、ユーザが、複数の投与単位の１つを選択し、かつユーザカスタマイズ可能な薬剤ライブラリに追加／保存されることになる薬剤エントリの一部として規則セットおよびインフューザ設定値のそれぞれ１つを入力できるようにする、請求項１に記載のシステム。
【請求項６】
ユーザインタフェースが、複数の規則セットタイプのプルダウンメニューリストを表示し、前記規則セットが、完全であること（Ｆｕｌｌ）、限られていること（Ｌｉｍｉｔｅｄ）、およびないこと（Ｎｏｎｅ）の１つを含み、ユーザが、複数の規則セットタイプの１つを選択し、かつユーザカスタマイズ可能な薬剤ライブラリに追加／保存されることになる薬剤エントリの一部として規則セット値およびインフューザ設定値のそれぞれ１つを入力できるようにする、請求項１に記載のシステム。
【請求項７】
ユーザインタフェースが、複数の希釈液単位のプルダウンメニューリストを表示し、ユーザが、複数の希釈液単位の１つを選択し、かつユーザカスタマイズ可能な薬剤ライブラリに追加／保存されることになる薬剤エントリの一部として規則セットおよびインフューザ設定値のそれぞれ１つを入力できるようにする、請求項１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概ね、薬物投与デバイスまたは薬物送達デバイスに関する。より詳細には、本発明は、薬剤情報または薬物情報を保持するため、コンピュータと１つまたは複数の輸液ポンプの間で通信を提供するため、ならびにそのような情報および通信の整合性を保証するための新規なシステムに関する。
【背景技術】
【０００２】
患者の循環系に直接に薬物、およびその他の液体を投与することが望ましい場合、静脈内輸液療法が処方される。臨床行為が意図していたよりも高い、または低い投与量がプログラミングされていることを臨床家に警告する警報がなかったなら、患者に送達される結果の量が、疾病率（ｍｏｒｂｉｄｉｔｙ）の増加をもたらす、または致命的となる可能性がある。薬用液体を患者の身体に輸液するのに医療スタッフ（ｍｅｄｉｃａｌ  ｐｅｒｓｏｎｎｅｌ）によって使用される、様々なタイプの輸液ポンプが存在する。薬剤用量プログラミング警報の機能を有するポンプは、ほとんど存在しない。一部のポンプは、電子的にダウンロード可能な薬剤ポンプのためのカスタマイズされた薬剤ライブラリを使用する。例えば、参照により全体が本明細書に組み込まれている米国特許第６２６９３４０号が、カスタマイズされた薬剤ライブラリを策定して、パーソナルコンピュータ（ＰＣ）から、注射ポンプの筐体内部の消去可能な、電子的に読み込み可能なメモリの中にダウンロードするためのシステムおよびコンピュータ可読媒体を説明している。しかし、先行技術のシステムおよび輸液ポンプは、いくつかの欠点を有する。以下は、先行技術において見られる様々な問題を解決する斬新な輸液ポンプシステムの説明である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許第６２６９３４０号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、１つまたは複数の薬物投与デバイスまたは薬物送達デバイスと通信するためのシステムに関する。より詳細には、本発明は、リモートコンピュータ、ならびにコンピュータ可読媒体上のソフトウェアプログラムを利用して、スタンドアロンベースで、または統合された薬物管理システムの一部として、１つまたは複数の輸液ポンプに情報をダウンロードし、および／または１つまたは複数の輸液ポンプから情報をアップロードするシステムに関する。
【課題を解決するための手段】
【０００５】
一例では、ソフトウェアは、生物工学技師、薬剤師、医師、その他を含むが、以上には限定されないユーザによって使用されることが可能である、強力な薬剤ライブラリ作成能力、薬剤ライブラリ編集能力、および薬剤ライブラリアーカイブ能力をリモートコンピュータに提供する。各薬剤エントリが、関連するＣＣＡ指定を有する単一の薬剤処方集ワークシートまたは薬剤処方集データベースが、医療施設全体のために作成されることが可能である。同一の薬剤に、異なる臨床看護領域において異なる限度が確立されていることが可能であり、特定の臨床看護領域に関して医療施設の推奨される最良の慣行に依存して、異なるデバイスパラメータ、および異なるデバイス設定値が適用される可能性がある。単一の薬剤処方集ワークシートは、各臨床看護領域に関して別個のデータベースまたはサブデータベースより、管理し、更新し、保持するのがより容易である。ソフトウェアの一例では、ソフトウェアは、ユーザがデータをキー入力するにつれ、各キー入力とともに、薬剤処方集ワークシートへの入力を動的に検証するリアルタイムの規則セットバリデータ（ｖａｌｉｄａｔｏｒ）を提供する。ユーザは、値が、許容される範囲を超えた場合、またはデータが、所定の予期される特徴を満たさない場合、即時に通知を受ける。一例では、ソフトウェアは、薬物送達デバイスと通信するために、拡張マークアップ言語も使用する。コンピュータとデバイスの間の通信は、巡回冗長検査などの、任意の所望の技術を使用して検証されることが可能である。別の例では、データベースを使用して、複数の輸液ポンプの履歴が格納される。これにより、１つのデータベースの中で１つの機関におけるすべてのポンプからイベントログデータを取り出す能力が可能になり、使用の場所、時刻、誤りのタイプ、その他に基づき、データを取り出すことができる。他のタイプのリポートも可能である。
【０００６】
ソフトウェアは、一例では、コンピュータを利用して、１つまたは複数の薬剤送達デバイス（輸液ポンプなどの）に情報をダウンロードし、および１つまたは複数の薬物送達デバイス（輸液ポンプなどの）から情報をアップロードするシステムの一部分として役立つ。一実施形態では、システムは、ソフトウェアを格納するためのメモリ、ユーザインタフェース、およびディスプレイを有するリモートパーソナルコンピュータ（ＰＣ）を含む。また、システムは、１つまたは複数の輸液ポンプ、ならびに、ＰＣをポンプに接続して、ＰＣとポンプの間における情報の通信を円滑にするための１つまたは複数の技術も含む。輸液ポンプは、薬物（すなわち、液体、薬物、またはそれらの混合物）を患者に送達するための単一のチャネルを有することも、複数のチャネルを有することも可能である。一例では、ポンプにダウンロードされる情報には、限定としてではなく、１つまたは複数の薬剤エントリが、通常、臨床看護領域別にグループ化されている薬剤ライブラリ、薬剤送達パラメータ（ハード限度およびソフト限度）、デバイス設定値、デバイスパラメータ、またはデバイス限度、患者識別データなどの患者固有の情報、看護者ＩＤ（ｃａｒｅｇｉｖｅｒ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などの看護者固有の情報が含まれることが可能である。
【０００７】
一例では、ソフトウェアおよび通信プロトコルは、異なるバージョン、異なるモデル、および異なるタイプの薬物送達デバイスに適用可能なオープンアーキテクチャを利用する。本発明の一実施形態では、ソフトウェアは、情報をダウンロードするため、およびアップロードするために、複数の汎用輸液ポンプと有線通信を確立するシステムにおいて利用される。他の諸実施形態では、ソフトウェアは、情報をダウンロードするため、およびアップロードするために、ポンプ筐体内部に設置されたプラグアンドプレイ（ｐｌｕｇ  ａｎｄ  ｐｌａｙ）通信モジュールを有する１つまたは複数の汎用輸液ポンプと無線通信を確立するシステムにおいて利用される。他の諸実施形態では、プラグアンドプレイ通信モジュールは、ポンプ筐体内部に密閉されたオプションの回路基板上に一体化して組み込まれる。薬物送達デバイスの例には、単一チャネルまたは複数チャネルの汎用輸液ポンプ、患者自己管理鎮痛（ｐａｔｉｅｎｔ  ｃｏｎｔｒｏｌｌｅｄ  ａｎａｌｇｅｓｉａ）（ＰＣＡ）ポンプ、歩行（ａｍｂｕｌａｔｏｒｙ）ポンプ、経腸ポンプ、ＩＶ輸液ポンプ、その他が含まれていたが、以上には限定されない。
【０００８】
また、ソフトウェアは、薬物管理ユニットまたは薬物管理サーバとインタフェースをとる、あるいはそのようなユニットまたはサーバとして動作するコンピュータ上でも役立つ。その例では、ソフトウェアは、患者エリアネットワーク（ＰＡＮ）内で、ＰＣと１つまたは複数の薬剤送達デバイスの間における通信を円滑にする。ＰＣとデバイスの間の通信がどのような目的で使用されることが可能であるかの例には、薬物送達デバイスを動作させるため、および制御するための患者固有の薬剤送達命令をダウンロードすること、ならびにデバイス特性、条件、使用履歴、および警報履歴などの情報をアップロードすることが含まれるが、以上には限定されない。
【０００９】
本発明が、例として、限定としてではなく、同様の符号が同様の要素を示す、添付の図面の図に示されている。
【図面の簡単な説明】
【００１０】
【図１Ａ】本発明による輸液ポンプの正面図である。
【図１Ｂ】図１の輸液ポンプの背面図である。
【図１Ｃ】図１の輸液ポンプの背面透視図であり、ポンプとコンピュータの間の通信を円滑にするプラグアンドプレイモジュールを示す。
【図１Ｄ】ＣＤ−ＲＯＭディスク、または本発明によるコンピュータ可読媒体の可能な一実施形態を示す正面透視図である。
【図１Ｅ】接続箱への接続を介して、複数のポンプをコンピュータと通信するようにさせるのに使用されることが可能なデータケーブルの透視図である。
【図１Ｆ】プラグアンドプレイモジュールをコンピュータに接続し、他のポンプと互いに接続するためのデュアルジャック付き（ｄｕａｌ  ｊａｃｋｅｄ）接続箱ケーブルの透視図である。
【図１Ｇ】接続箱上のデュアルジャックの１つにコンピュータを接続するためのデータケーブルの透視図である。
【図２】本発明がどのように使用されることが可能かを示す図である。
【図３】ライブラリをカスタマイズするためのプロセスの一例を示す図である。
【図４Ａ】ＰＣと輸液ポンプの間の通信を示す図である。
【図４Ｂ】薬剤ライブラリを編集し、ダウンロードするプロセスを示す流れ図である。
【図５】複数のポンプのコンピュータへの接続を示す背面図である。
【図６】薬剤師が、本発明を備えたコンピュータ上で見るワークシートの例を示す図である。
【図７Ａ】ソフト限度オーバライドレポートの例を示す図である。
【図７Ｂ】図７のレポートを説明するテーブルである。
【図７Ｃ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｄ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｅ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図７Ｆ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ａ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｂ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｃ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図８Ｄ】異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す図である。
【図９】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１０】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１１】本発明で使用されることが可能な例示的な接続のブロック図である。
【図１２Ａ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｂ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｃ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１２Ｄ】本発明で使用するための電子システムの一例を示すブロック図である。
【図１３】本発明で使用するための電子システムの一例を示すブロック図である。
【図１４】本発明で使用するための電子システムの一例を示すブロック図である。
【図１５Ａ】薬剤に関する規則セットを編集する際に使用されるダイアログボックスの例を示す図である。
【図１５Ｂ】本発明のＲｕｌｅ  Ｓｅｔ  Ｅｄｉｔｏｒにおける様々なフィールドまたは値に関する有効な入力範囲を示すテーブルである。
【図１６】規則セットバリデータ判定ツリーの一例を示す図である。
【図１７Ａ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１７Ｂ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１７Ｃ】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１８】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図１９】本発明による無線接続エンジンまたは無線通信エンジンを有する患者自己管理鎮痛ポンプを示すブロック図である。
【図２０Ａ】ＸＭＬ交換スキーマの一例を示す図である。
【図２０Ｂ】本発明の一例において利用されるＸＭＬオブジェクトタグ名を示すテーブルである。
【図２１】規則セットの追加、編集、削除、または閲覧を行う際に規則セットエディタで使用されるダイアログボックスの例である。
【図２２】ＤａｔａＭｏｄｅｌとＤａｔａＩｔｅｍの間の関係を示すブロック図である。
【図２３】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２４Ａ】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２４Ｂ】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２５】本発明の様々なプロセス間における高レベルの対話を示す図である。
【図２６】ソフト限度警報イベントまたはオーバライド臨床イベントをサポートするデータモデルを示す図である。
【発明を実施するための形態】
【００１１】
一般に、本発明は、コンピュータと、１つまたは複数の薬物投与デバイスの間で通信を提供するためのシステムおよび方法を提供する。本発明は、ハードウェアとソフトウェアを使用して、コンピュータと輸液ポンプの間のリンクを提供する。一例では、本発明は、薬局環境または生物医学技術サービス環境、あるいは、全体が本明細書に明示的に組み込まれている、２００３年１２月５日に出願した、「ＭＥＤＩＣＡＴＩＯＮ  ＭＡＮＡＧＥＭＥＮＴ  ＳＹＳＴＥＭ」という名称の本出願人の同時係属仮出願第６０／５２７５８３号、および２００４年２月２０日に出願した、同一の名称による通常の特許出願で説明されている、薬物管理ユニット（ＭＭＵ）において使用されるように設計される。
【００１２】
本発明は、施設が、イリノイ州、アボットパーク所在のアボットラボラトリーズ（Ａｂｂｏｔｔ  Ｌａｂｏｒａｔｏｒｉｅｓ）から入手可能な、ＰＬＵＭ  Ａ＋（登録商標）インフューザ（ｉｎｆｕｓｅｒ）またはポンプのような輸液ポンプで使用するための薬剤ライブラリをカスタマイズすることを可能にする。また、他のタイプのポンプも、本発明で使用されることが可能である。例えば、本発明は、患者自己管理鎮痛（ＰＣＡ）ポンプ、歩行ポンプ、経腸ポンプ、ならびにＩＶ輸液ポンプで使用されることが可能である。また、本発明は、複数のポンプからのデータの格納も可能にし、様々な安全性レポート、イベント、および警報レポートを生成する。
【００１３】
図１Ａは、Ａｂｂｏｔｔ  ＰＬＵＭ  Ａ＋（登録商標）インフューザまたはポンプ１２の正面図である。図１Ｂは、筐体２が、筐体２内部に、コンピュータと輸液ポンプの間の通信を円滑にするプラグアンドプレイモジュール４を受けるために内部に形成された、縦に細長いスロット３を含むように変更されている、図１ＡのＰＬＵＭ  Ａ＋（登録商標）ポンプの背面図である。プラグアンドプレイモジュール４は、筐体２内部に動作可能なように配置され、筐体によって実質的に包囲され、保護され、隔離される。プラグアンドプレイモジュール４は、ポンプ筐体２のスロット３にはまり込む、薄い、細長いカード形状のケースを有する。このため、本発明のプラグアンドプレイモジュール４は、ポンプによって占有される空間をほとんど増大させることがない。図１Ａおよび図１Ｂに示されるプラグアンドプレイモジュール４は、ハードワイヤド通信向けに構成される。しかし、以下に説明するとおり、プラグアンドプレイモジュール４は、無線通信向けに構成されることも可能である。
【００１４】
一例では、本発明のソフトウェアは、１２までの臨床看護領域（ＣＣＡ）を格納することができ、１００までの薬剤エントリ（９９の薬剤エントリ、およびＮｏ  Ｄｒｕｇ  Ｓｅｌｅｃｔｅｄ）が各ＣＣＡの中に格納されて、合計で１２００のエントリが、マスタ薬剤処方集の中に格納される。その例では、本発明のソフトウェアは、単一のコンピュータに接続された１５までのＡｂｂｏｔｔ  ＰＬＵＭ  Ａ＋（登録商標）単一チャネルインフューザのデータ転送をサポートする。もちろん、本発明は、異なる格納能力および通信能力で設計されることが可能であり、異なるポンプ向けに構成されることが可能である。
【００１５】
図２は、本発明がどのように使用されることが可能であるかを示す図である。図２に示されるとおり、ソフトウェアが、ホストコンピュータ（この例では、パーソナルコンピュータ、つまり、ＰＣ１０）上にインストールされると、ユーザは、任意の所望される規則セットを含む、薬剤ライブラリを作成する（または、ソフトウェア媒体を備えたライブラリを使用する）ことができる。薬剤ライブラリは、薬剤名、薬剤量、薬剤単位、希釈液量、希釈液単位、投与単位、薬剤クラス、ハード限度、およびハード限度範囲内のソフト限度を含むエントリを含むことが可能である。薬剤濃度は、入力する必要がない。というのは、その値は、薬剤量、薬剤単位、希釈液量、および希釈液単位から導出可能だからである。また、ユーザは、ライブラリ内で複数のＣＣＡを作成することもできる。次に、ユーザは、ＰＣを複数のインフューザ１２に接続し、ＰＣとインフューザの間でデータ転送を開始することができる。例えば、アクティブ薬剤ライブラリが、ＰＣから、接続されたインフューザにダウンロードされることが可能である。さらに、データは、インフューザからＰＣに転送されることも可能である。例えば、イベントログおよびアラームログが、接続されたインフューザからＰＣにアップロードされることが可能である。また、所望の他のあらゆるタイプのデータまたは通信も、ＰＣとインフューザの間で転送されることが可能である。
【００１６】
図３は、ライブラリをカスタマイズするためのプロセスの一例を示す図である。図３のプロセスは、薬剤師などのユーザが、ＰＣ１０上でワークシートを作成することから始まる。この例では、ワークシートは、依然、編集されることが可能であり、まだ完成されていないライブラリと考えることができる。このワークシートの１つの目立った特徴は、ワークシートが、２つの同時のビュー、すなわち、目標の「実用（ｗｏｒｋｉｎｇ）」処方集ビュー、およびソース「基準」処方集ビューを提供することである。一例では、薬剤のマスタ処方集ビューが、同時に、そのＣＣＡに関する目標薬剤のビューが示されながら、基準ビューの中にあることが可能である。同様に、別の例では、目標ビューは、「Ｍｅｄｉｃａｌ（内科）」などの１つのＣＣＡであるのに対し、ソースは、「Ｓｕｒｇｅｒｙ（外科）」などの別のＣＣＡであることも可能である。薬剤師は、全く同一の薬剤エントリを、関連する規則セットとともに、ソースから目標にコピーすることができる。この提示により、すべての必要なＣＣＡを策定するのにかかる時間が短縮され、薬剤師のための容易な品質検査、ならびに策定されているすべての薬剤規則セットにわたるビューが促進される。さらに、同一の薬剤名、濃度、および規則セットを多くの異なるＣＣＡの中に再入力することを余儀なくされた場合に、タイプ入力の誤りが減少する。薬剤ライブラリを策定する際の誤りは、看護士のためのセーフティネットの低下、患者の疾病率の増加をもたらす可能性がある。図６は、薬剤師（または他のユーザ）が、本発明を備えたコンピュータ上で見ることができるワークシートの一例を示す。図６は、マスタ薬剤処方集テーブルが、スクリーンの下部１４にあり、選択されたＣＣＡにおける薬剤が、スクリーンの上部１６にある分割スクリーンビューを示す。プルダウンメニュー１８を使用して、いずれのＣＣＡが、上部１６で表示されるかが選択される。
【００１７】
図３および図２０Ａを参照すると、ユーザは、次に、許可されたユーザによって定義された、病院の区域または患者集団（ｐａｔｉｅｎｔ  ｐｏｐｕｌａｔｉｏｎ）（例えば、集中治療部（ＩＣＵ））において使用するための薬剤ライブラリのサブセットである、ＣＣＡを作成する（そのようなＣＣＡが、既に作成済みでない場合）。各ＣＣＡは、事前定義された数の特定の薬剤を有することが可能である。また、病院は、薬剤ライブラリの中に複数のＣＣＡを有することが可能である。次に、ユーザは、任意の所望の薬剤クラス（例えば、抗生物質、麻酔薬、β遮断剤、その他）を作成し、その後、薬剤エントリを規則セットとともにＣＣＡに追加する。次に、ＣＣＡインフューザ設定値が、設定される。ＣＣＡインフューザ設定値の例には、最大速度、既定の閉塞圧、最大患者体重および／または最小患者体重が含まれる。次に、マスタインフューザ設定値が、セットアップされる。マスタインフューザ設定値の例には、Ｃｏｎｔｉｎｕｅ  Ｒａｔｅ（療法が完了した後に、インフューザが切り替わる既定の速度）、Ｅｎａｂｌｅ  Ｄｅｌａｙ／Ｓｔａｎｄｂｙ（既定のスタンバイ設定）、Ｃａｌｌｂａｃｋ  Ｎｏｔｉｆｉｃａｔｉｏｎ（イネーブルにされた場合、多段輸液中の段階の合間に、または薬用量を装填した後に、インフューザ１２が、可聴の看護士コールバックアラームを発し、通知を表示するようにさせる）、およびＤｅｌｉｖｅｒ  Ｔｏｇｅｔｈｅｒ（既定として、２チャネル送達方法を選択することを可能にする）が含まれる。ワークシートを完成させる前に、ワークシートレポートが印刷され、点検されることが可能である。最後に、ワークシートが、アクティブライブラリとして完成される。
【００１８】
アクティブライブラリが準備できた後、技師は、１つまたは複数のインフューザ１２をデータ転送のためにＰＣ１０に接続することができる。図４Ａおよび図５は、ＰＣ１０とインフューザ１２の間の通信を示す図である。第１に、アクティブライブラリが、インポートされる。次に、技師は、インフューザ１２をＰＣ１０に接続する。インフューザ１２は、任意の所望の形でＰＣ１０に接続されることが可能である。例えば、ケーブル（図１Ｆ）が、ＰＣ１０上のシリアルポートと、接続箱（図１Ｅ）の間で接続されることが可能であり、接続箱は、プラグアンドプレイモジュール４（図１Ａ）を介して、各インフューザ１２のデータポートにも接続される。インフューザ１２とＰＣ１０は、シリアルインタフェース（ＲＳ２３２、ＵＳＢ、その他）、パラレルインタフェース、その他を含め、任意の所望のタイプのインタフェースを使用することができる。別の例では、インフューザ１２は、必要に応じてＰＣ１０への接続を提供する無線能力を有することが可能である。接続されると、プログラミングイベント、設定値、およびアラーム、その他を含むが、以上には限定されない情報が、履歴情報（ログ）またはリアルタイム情報として、ＰＣにアップロードされることが可能であり、アクティブライブラリが、インフューザ１２のすべてにダウンロードされることが可能である。図５は、複数のシリアルコネクタ、および複数の接続箱を有するシリアルケーブルを使用した、複数のポンプのコンピュータへの接続を示す図である。
【００１９】
図４Ｂは、前述したプロセスを示す別の流れ図である。図示されるとおり、病院処方集が、１つまたは複数のワークシートにインポートされることが可能である。ユーザが、薬剤ライブラリを完成させた後、アクティブ薬剤ライブラリが、１つまたは複数のインフューザにダウンロードされることが可能である。また、図４Ｂは、薬剤ライブラリが、アーカイブされ、ワークシートを策定する、または編集する際に、再び使用されることが可能であることも示す。
【００２０】
本発明は、先行技術における様々な問題を解決するいくつかの特徴を含む。以下は、それらの特徴の説明である。
【００２１】
本発明は、リモートプロシージャコール（ＲＰＣ）のために拡張マークアップ言語（ＸＭＬ）表現を利用する。ＸＭＬを使用する１つの利点は、ＸＭＬ構文ドキュメントの使用により、プロトコルが、異なるタイプの製品をサポートすることが可能になることである。例えば、第１のインフューザが、別のインフューザによって要求されるフォーマットとは異なる、ある通信フォーマットだけしか許さない可能性がある。ＸＭＬを使用することにより、システムは、異なるタイプのインフューザと通信することができる。異なるタイプのデバイスの例には、異なるコンピュータアーキテクチャを有するデバイス、異なるタイプのコンピュータプロセッサを実行しているデバイス、異なるソフトウェアプログラム（または同一のプログラムの異なるバージョン）を実行しているデバイスが含まれる。さらに、一部のデバイスは、他のデバイス上で使用されているバイナリフォーマットと互換性がない可能性があるバイナリデータフォーマットを使用して動作する。このように、ホストコンピュータは、様々な異なるタイプのデバイスに関して同一のメッセージフォーマットを使用することができる。また、本発明は、輸液ポンプなどの患者に接続された医療デバイスと通信する際に、ＸＭＬパーサの使用も提供する。
【００２２】
本発明の一部の応用例では、ホストとポンプが、互換性のないバイナリデータフォーマットを有する可能性がある。その理由で、ホスト上と、ポンプ上で同一である語彙形式（ｌｅｘｉｃａｌ  ｆｏｒｍ）を定義する必要がある。その共通の語彙表現が、正規形式と呼ばれる。プロセス固有のバイナリ形式を正規形式に変換するプロセスは、正規化と呼ばれる。
【００２３】
誤り検査は、一般に、チェックサム関数またはハッシュ関数を使用する。しかし、これらの関数は、常に信頼できるわけではない。本発明は、医療上クリティカルなデータを使用するので、より信頼できる誤り検査関数を使用することが重要である。さらに、ライブラリ全体の内容を検証することが依然として可能でありながら、部分ライブラリ更新（薬剤ライブラリの中の個別の項目などの）を可能にすることが望ましい。本発明は、標準のチェックサム関数またはハッシュ関数を、交換データ構造全体の状態を保護するグローバル正規巡回冗長検査（Ｇｌｏｂａｌ  Ｃａｎｏｎｉｃａｌ  Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）（ｇＣＣＲＣ）で補う。ｇＣＣＲＣの目的は、ホストとポンプが、試みられたデータ伝送の後に、それぞれのデータが同一であることを検証することができるようにすることである。ｇＣＣＲＣは、より低いレベルのチェックサム、およびその他の方法によって捕えられない誤りを検出することができる。例えば、ｇＣＣＲＣは、ドロップされたパケットの数が、シーケンス番号の範囲そのものである場合を検出する。また、ｇＣＣＲＣは、ポンプ切断、停電、およびソフトウェア欠陥のような例外を含む、あらゆる種類のプロトコル障害に対する、最終の「バックストップ（ｂａｃｋｓｔｏｐ）」検証も提供する。
【００２４】
一例では、２つのバイナリイメージ（ホストコンピュータにおけるイメージと、インフューザにおけるイメージ）を比較して、それらが同一であるかどうかを確かめて、インフューザの中に格納されたデータの内容を検証する従来の技法ではなく、２つの場合により全く異なる物理的（ビット単位の）表現が、意味的に同一であるかどうかを判定する比較が行われる。これは、正規表現（いずれの側も、格納のために実際に使用しない）を使用し、次に、２つの抽象表現の間で比較を行うことによって達せられる。例えば、輸液ポンプにおけるデータの内容を検証するのに、ポンプにおけるデータに基づき、ＣＲＣが計算される。次に、ホストが、ポンプにおけるデータであると考えるものに基づき、ＣＲＣが計算される。次に、それらの数値が比較される。数値が同一であった場合、データは、ホストとインフューザにおいて同一である可能性が極めて高い。このアプローチの１つの利点は、少量のデータしか、比較の目的で転送されることが要求されないことである。ライブラリ全体のバイナリイメージは、比較のために再伝送されなくてもよい。また、このアプローチは、データ伝送中の誤り検査の要件も無くす。
【００２５】
本発明の別の態様は、ＣＲＣがどのように計算されるかに関する。使用されるＣＲＣの形態は、Ｃｏｍｉｔｅ  Ｃｏｎｓｕｌｔａｔｉｆ  Ｉｎｔｅｒｎａｔｉｏｎａｌｅ  ｄｅ  Ｔｅｌｅｇｒａｐｈｉｑｕｅ  ｅｔ  Ｔｅｌｅｐｈｏｎｉｑｕｅ（ＣＣＩＴ）によって指定されている。しかし、本発明では、ＣＣＩＴ  ＣＲＣは、逆のビット順序（ＣＣＩＴによって指定される左から右にではなく、右から左に）で行われて、計算をより効率的にするようにする。Ｉｎｔｅｌプロセッサは、ＣＣＩＴによって規定される、いわゆる「ネットワークバイト順」とは逆の「エンディアン性（ｅｎｄｉａｎｎｅｓｓ）」を有するので、ビット逆転により、一部のプロセッサ上でインプリメンテーション問題が回避されることになる。
【００２６】
ＣＲＣを使用して前述した語（異なるエンディアン性を有することが可能な）を構築する際、ＣＲＣを使用する前に、ドキュメントまたはデータの構文を正確に定義することが重要である。本発明は、その目的でＸＭＬスキーマを使用する。加えて、ＸＭＬスキーマは、検証のために使用されるセマンティクスを定義するのに使用される。）検証されるべきデータ（例えば、薬剤ライブラリ）は、正規形式（前述した）に変換され、ＸＭＬスキーマを使用して検証され、確認されて、データが有効であるとともに、正しい形式である（ｗｅｌｌ  ｆｏｒｍｅｄ）かどうかが判定される。ライブラリの例では、この検証検査は、ライブラリをポンプに伝送する前に行われる。
【００２７】
本発明のＸＭＬスキーマの一例は、２つの主要な部分、エクスチェンジスキーマ、およびインプライドスキーマを含む。一般に、エクスチェンジスキーマは、ホストコンピュータと輸液ポンプの間で通信されるべきデータの構造を定義する。インプライドスキーマは、交換されているデータの型を定義する（さらに、検証する）。
【００２８】
図２０Ａは、Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ（ＵＭＬ）表記法を使用する、ＸＭＬエクスチェンジスキーマの一例を示す図である。図２０Ａの例で示されるとおり、薬剤ライブラリは、インフューザ設定値、少なくとも１つの薬剤エントリ、およびアクティブライブラリオブジェクトを含む。この例では、１つのインフューザ設定値オブジェクト、および１つのアクティブライブラリオブジェクトだけが存在するが、１２００までの薬剤エントリオブジェクトが存在する。図２０Ａに示された各オブジェクトは、それぞれのボックス内に記載される属性を含む。アクティブライブラリオブジェクトは、１２までのＣＣＡオブジェクトを含む。各ＣＣＡオブジェクトは、１００までの規則セットオブジェクトを含む。この例では、１つの薬剤につき１つだけの規則セットが存在するが、複数の薬剤が、単一の規則セットを共有することが可能である。図２０Ａに示されたデータ構造、およびそれらのデータ構造のメンバは、各エントリに関するタグ名（オプションとして、略記される／短縮される）を有するＸＭＬオブジェクトとして定義される。図２０Ｂは、一例において使用される名前を明らかにする。図２０Ｂは、コマンドとともに、クエリおよび応答、ならびにそれらの対応する省略形を示す。図示されるとおり、データ構造に加えて、コマンドおよびクエリも、ＸＭＬで符号化され、ホストコンピュータ（つまり、サーバ）側およびポンプ（つまり、クライアント）側によって、データと同様に処理される。当業者には明白なとおり、コマンドおよびクエリを本発明とともに使用して、ホストコンピュータとクライアント輸液ポンプの間で通信を効率的に提供することができる。例えば、以下のコマンドにより、サーバの計算されたグローバル正規チェックサムをクライアントに通信している間に、薬剤ライブラリ更新が終了される（＜ｘＥＵ  ｇｃｃｒｃ＝”９Ｂ８Ｄ”／＞）。図２０Ｂに示されるとおり、「ｘＥＵ」は、コマンド「ＥｎｄＬｉｂｒａｒｙＵｐｄａｔｅ」の省略形であり、他方、値「９Ｂ８Ｄ」は、サーバのチェックサムの１６進値の例である。その他のコマンドおよびクエリも、同様の形で使用される。
【００２９】
インプライドデータは、ホストコンピュータ１０と輸液ポンプ１２の間の契約である。インプライドデータは、ホストによって管理され、ホストおよびクライアントのためのソフトウェアを開発する際に使用される。一例では、インプライドデータは、通信リンクを介して伝送されず、インフューザソフトウェアがそのデータを処理することも決してない。インプライドスキーマの１つの目的は、クライアントに送られることが許されるデータの値および型を検証することである。１つの形態の検証は、範囲外の値が伝送されるのを制限する範囲検査である。別の形態の検証は、表示精度であることが可能である。例えば、変数の表示範囲は、０．１位（ｔｅｎｔｈｓ  ｏｆ  ｄｉｇｉｔ）であることが可能である。そのようなケースでは、１２．００という値を送信することは、その値が、変数の範囲を超えた精度を記述しているので、無効である。別のタイプの検証は、固有型検査であることが可能である。暗黙のスキーマは、ＸＭＬスキーマドキュメントの形態をとる。ＸＭＬスキーマドキュメントは、エクスチェンジスキーマの中のすべてのクライアント／ホスト固有の型定義のための型定義を提供する。以下は、様々なインプライドスキーマの型の例である。第１の例は、機関名文字列が、３０文字以下であることを定義する単純文字列型スキーマである。
【数１】
0005647644.tif 000002
【００３０】
ＸＭＬスキーマは、ほとんどの数値データ型上でｆｒａｃｔｉｏｎＤｉｇｉｔｓファセットを直接に介して固定小数点表示をサポートする。以下の例は、最小および最大の１０進数値および小数部数値を定義する。
【数２】
0005647644.tif 000003
【００３１】
一例では、本発明は、ＥｎｃｏｄｅｄＳｔｒｉｎｇに対するｘｓ：ｅｎｕｍｅｒａｔｉｏｎ制限を定義することにより、インプライドエニュメレーションを構築する。
【数３】
0005647644.tif 000004
【００３２】
単一の値に関する複数の範囲が、＜ｘｓ：ｃｈｏｉｃｅ＞を介して値に関して指定されることが可能である。以下の例は、上限範囲および下限範囲を含む、患者体重フィールドに関する。
【数４】
0005647644.tif 000005
【００３３】
ＸＭＬを使用することの１つの問題は、ＸＭＬが、非常に詳細（ｖｅｒｂｏｓｅ）であることであり、これにより、帯域幅要件が増大する。通信オーバーヘッドを低減するため、本発明は、依然として標準に準拠するが、ＸＭＬ識別子をいくつかの文字ニーモニック（ｍｎｅｍｏｎｉｃ）に短縮することによって大幅に低減された帯域幅で動作する、よりコンパクトな形態のＸＭＬを使用する。符号化は、簡潔な要素、および属性名を使用する正しい形式のＸＭＬである。一例では、各ＸＭＬ  Ｓｈｏｒｔ  Ｎａｍｅは、英字だけから成り、最初の文字によって一意に識別されることが可能である。コマンドは、引数をＸＭＬ属性として送る。応答は、値を、属性値として、かつ／または応答要素の中に入れ子にされた要素として戻す。例えば、長いＸＭＬ名「ＩｎｆｕｓｅｒＳｅｔｔｉｎｇ」は、「ＩＳ」に短縮される。したがって、例示的なコマンドラインは、
例：コンパクトなＰｕｍｐＣｏｎｆｉｇｕｒａｔｉｏｎインスタンス
【数５】
0005647644.tif 000006
0005647644.tif 000007
のようなものであり、
例：ＰｕｍｐＣｏｎｆｉｇｕｒａｔｉｏｎインスタンス
【数６】
0005647644.tif 000008
のような、コンパクトでないバージョンではない。
この例では、符号化は、約２００文字を約６０文字に削減しており、およそ３．３対１の比をもたらしている。
【００３４】
本発明は、データポートプロトコルの上に、信頼できるバイナリトランスポートプロトコルを含む、拡張されたデータポートプロトコルを使用する。つまり、プロトコルが、データポートプロトコルの上で実行される。このアプローチの１つの利点は、異なるマシン間の互換性の向上である。別の利点は、大きいメッセージがセグメント化され、再組み立てされることが可能なことである。これにより、ホストまたはポンプが大きいメッセージを扱うことができない場合でも、非常に大きいメッセージが、プロトコルスタックを介して送信されることが可能になる。大きいメッセージは、小さいパケットにセグメント化され、後に再組み立てされる。
【００３５】
本発明は、ポンプにダウンロードされることが可能であり、アクティブライブラリと呼ばれる１つのライブラリだけが、コンピュータの中に保持されることを可能にすることにより、データベースの安全性を確実にする。これにより、時間が経つにつれ誤ったライブラリがダウンロードされないことが確実になる。編集されることが可能なライブラリは、ワークシートと呼ばれ、多くの異なるワークシートが存在することが可能である。かつてアクティブであり、もはやアクティブではないライブラリは、アーカイブされ、そのようなものとして自動的に指定される。アクティブライブラリを別のコンピュータに転送することができるように、一意の特別なファイル拡張子および認識が開発された。これにより、複数の所在地を有する、より大型の医療施設の薬局間における全く同一のライブラリの転送が可能になる。
【００３６】
本発明の別の利点は、システムが、複数の輸液ポンプに同時にデータをダウンロードすることができることである。ライブラリは、マルチキャストの形で複数のポンプに伝送される。システムは、ポイントツーポイント通信を使用して、各ポンプのステータスを定期的に検証する。ポンプの１つが問題を有する場合、ダウンロードは、再スタートされることが可能であり、各ポンプが、新たなダウンロードの通知を受ける。一例では、あるポンプが、ブロードキャストダウンロード中にダウンロードエラーを検出すると、そのポンプは、ホストコンピュータにメッセージを送信し、すると、ホストは、ダウンロードを停止する。次に、ホストは、ポンプのすべてにポーリングを行って、ポンプのすべてが、有効なデータを有するメッセージを受信していた時点を特定する。ダウンロードは、複数の個々のタグ付きメッセージにわたって行われるので、タグ番号により、いずれのポンプもダウンロードエラーを報告していなかった時点をホストコンピュータが識別することが可能になる。ダウンロードが続けられる際、ダウンロードは、その時点で始まり、したがって、データのすべてが、再びダウンロードされなくてもよい。マルチキャスト通信戦略は、ダウンロードスループットを最適化する。例えば、ライブラリが、ダウンロードするのに１０分かかる場合、１５のポンプが、各ポンプに個々にダウンロードするのにかかる１５０分に対して、１０分でダウンロードを受信することができる。マルチキャストとポイントツーポイント通信のこの混合により、個々のポンプへの堅牢なダウンロードおよび再試行／回復機構が円滑になる。本発明の別の利点は、ワークシートが、薬剤エントリのＣＣＡビューを同時に提供しながら、マスタ処方集ビューを薬剤師に提供することである。薬剤エントリを編集すること、およびコピーすることは、いずれのビューにおいても行われることが可能である。この提示により、薬剤限度警報または薬用量限度警報が策定されるにつれ、薬剤師のための容易な品質検査、安全性機能が促進される。薬剤ライブラリを策定する際の誤りは、看護士のためのセーフティネットの低下、患者の疾病率の増加をもたらす可能性がある。
【００３７】
本発明の別の利点は、単一のデータベースを使用して、複数の輸液ポンプの履歴を格納することができることである。これにより、１つのデータベースの中で１つの機関におけるすべてのポンプからイベントログデータを取り出す能力が可能になり、使用の場所、時刻、誤りのタイプ、その他に基づき、データを取り出すことができる。また、他のタイプのレポートも可能である。また、集中データベースを使用しても、システムは、それぞれが、任意の所望のポンプにダウンロードすることができる複数のＰＣを含むことが可能である。
【００３８】
同様に、本発明は、ポンプ使用データを収集し、関連するレポートを生成することもできる。例えば、ソフト限度オーバライドデータが、ソフト限度オーバライドに関連するレポートの生成のために収集されることが可能である。そのタイプのレポートは、スタッフを評価すること、将来の限度を設定すること、その他などの任意の所望の目的で使用されることが可能である。
【００３９】
本発明は、薬剤データをリアルタイムで検証することができるアクティブ薬剤ライブラリエディタを含む。本発明は、無制限の数の薬剤ライブラリを管理することができる。薬剤ライブラリは、マスタ薬剤処方集（ＣＣＡが作成される元になる薬剤テーブル）、および複数のＣＣＡで構成される。ライブラリは、アクティブ（完成されていないワークシート）であること、アーカイブされていること（データベースに保存されている、以前にアクティブであったライブラリ）、またはワークシート（インフューザへのダウンロードがまだ承認されておらず、依然として編集されることが可能なドラフトライブラリ）であることが可能である。アクティブライブラリだけが、ポンプにダウンロードされることを許される。ポンプの動作上の振舞いを記述する構成パラメータなどの項目が、ポンプ全体にわたって、またはＣＣＡに固有で設定されることが可能である。それらのパラメータは、各ライブラリに独特である。ＴａｌｌＭａｎレタリングが、薬剤名に関してサポートされる。ＴａｌｌＭａｎレタリングに対する変更は、ライブラリ全体でレプリケートされる。ライブラリの中の各薬剤が、薬剤分類に関連付けられる。薬剤分類は、各ライブラリに独特である。薬剤は、複数の濃度、および複数の規則セットを有することが可能である。規則セットは、完全であること、限られていること、またはなしであることが可能である。
【００４０】
本発明の別の特徴は、アクティブ薬剤ライブラリが利用することができる様々なレベルの規則に関連する。本発明は、デバイス規則（例えば、特定の医療デバイス、または特定のタイプのデバイスの動作または限度に関連する規則）、ＣＣＡ規則（例えば、特定のＣＣＡに関連する規則）、薬剤規則（特定の薬剤に関連する規則）、および患者規則（例えば、年齢、体重、健康、病歴、アレルギー、その他などの、特定の患者に関連する規則）を含め、複数の規則レベルの使用を可能にする。
【００４１】
Ｒｕｌｅ  Ｓｅｔ  Ｅｄｉｔｏｒ（ＲＳＥ）が、薬剤データベースの中の規則セットを作成し、編集するのに使用される。ＲＳＥは、規則セットを正確に表示し、適宜、「追加」ボタン、「保存」ボタン、または「削除」ボタンをイネーブルにすることを担う。図２１は、規則セットの追加、編集、削除、または閲覧を行う際に規則セットエディタで使用されるダイアログボックスの例を示す。図２１に示されるとおり、薬剤名、薬剤クラス、薬剤量、薬剤希釈液、およびソフト限度／ハード限度のためのフィールドが存在する。ＲＳＥは、入力基準を調整すること、ならびにユーザが入力選択を行っている間に規則セットを検証することを担う。ＲＳＥは、ＲｕｌｅＳｅｔＤａｔａＩｔｅｍ（ＲＳＤＩ）（以下に説明する）をデータモデルとして使用し、ＲｕｌｅＳｅｔＶａｌｉｄａｔｏｒ（ＲＳＶ）（以下に説明する）をコントローラとして使用する。ＲＳＥは、モデルが検証されるべき場合、ＲＳＤＩにメッセージを送信する。ＲＳＤＩは、ＲＳＤＩを検証するＲＳＶにメッセージを送信する。この責任分離は、規則セットエディタユーザインタフェースとライブラリインポートプロセスの両方に関する標準の検証インプリメンテーションをカプセル化するように確立される。
【００４２】
本発明の別の利点は、薬剤構成に関する。本発明は、特定の薬剤に関する薬剤名および濃度の定義を可能にする特別な規則セットを含む。しかし、ポンプにおいて、ユーザは、薬剤量および薬剤単位を無効にすることができる。したがって、限度が設定されるが、ユーザは、濃度を定義することを許される。したがって、本発明は、ユーザが、薬剤ごとに送達の単位を選択することを選択的に制限する、または許す能力、ならびに薬剤単位の濃度を有する薬剤にラベルを付けるが、他の単位（ｍｌ／時）で送達する能力を有する。
【００４３】
本発明の別の利点は、制約定義に関する。本発明は、一意制約オブジェクトのセットを含む。制約オブジェクトは、キーボード入力、マウス入力、およびインポート入力を検証するための標準のインプリメンテーションを定義する。例えば、特定のフィールドが、ある数値範囲に制約されることが可能である。制約は、物事が誤って行われるのを防止する。しかし、ときとして、１つのオブジェクト入力は、別のオブジェクトの内容に基づき、本発明では、制約定義は、入力定義が変化するにつれ、動的に変化する。例えば、オブジェクト「薬剤量」に関して、制約は、測定単位（例えば、グラム数、その他）に依存して変化することが可能である。
【００４４】
Ｄｏｓｅ  Ｒａｔｅ  Ｄｏｃｕｍｅｎｔ（ＤＲＤ）が、複数の制約を集約して、入力確認が、無制限の数の制約オブジェクト全体でカスケードされることが可能であるようにする。ＤＲＤのインプリメンテーションの一例では、オブジェクト、ＤｏｓｅＲａｔｅＤｏｃｕｍｅｎｔは、ｊａｖａｘ．ｓｗｉｎｇ．ｔｅｘｔ．ＰｌａｉｎＤｏｃｕｍｅｎｔを拡張して、要求されるメソッド、ｉｎｓｅｒｔＳｔｒｉｎｇ（ｉｎｔオフセット、Ｓｔｉｎｇ文字列、ＡｔｔｒｉｂｕｔｅＳｅｔ属性）をインプリメントする。このメソッドは、適宜、ＳｔｒｉｎｇＣｏｎｓｔｒａｉｎｔ．ｃｈｅｃｋＩｎｐｕｔ（Ｓｔｒｉｎｇ  ｐｒｏｐｏｓｅｄＶａｌｕｅ）を内部で呼び出す。
【００４５】
Ｒｕｌｅ  Ｓｅｔ  Ｃｏｎｓｔｒａｉｎｔ（ＲＳＣ）が、薬剤量、希釈液量、ならびにハード限度およびソフト限度に関する特定のＤＲＤを提供する。ＲＳＣは、薬剤単位および投与量単位に基づき、それらの設定値を動的に変更して入力を検証するのに使用される。ＲＳＣは、いくつかの制約オブジェクトを集約して、エントリが、有効範囲内にあることを確認する。一例では、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度は、独自のＤＲＤおよびＣｏｎｓｔｒａｉｎｔオブジェクトを有するが、それぞれは、目標のニーズを満たすように独特である。ＲＳＣは、構築されると、規定の値で初期設定される。ｓｅｔＤｒｕｇＡｍｏｕｎｔＣｏｎｓｔｒａｉｎｔｓ（ｄｒｕｇＬａｂｅｌＰＫ）に対する連続的なコールにより、ｄｒｕｇＡｍｏｕｎｔＤＲＤが調整される。同様に、ｓｅｔＤｉｌｕｅｎｔＡｍｏｕｎｔＣｏｎｓｔｒａｉｎｔ（）に対するコールにより、ｄｉｌｕｅｎｔＡｍｏｕｎｔＤＲＤが調整される。本発明の一例では、唯一の制約は、ｄｉｌｕｅｎｔＡｍｏｕｎｔである。同様に、ｓｅｔＬｉｍｉｔＣｏｎｓｔｒａｉｎｔｓ（ｄｏｓｉｎｇＵｎｉｔＰＫ）に対する連続的なコールにより、限度量が調整される。
【００４６】
Ｒｕｌｅ  Ｓｅｔ  Ｄａｔａ  Ｉｔｅｍ（ＲＳＤＩ）は、特殊化されたＤａｔａＩｔｅｍであり、データモデルとして作用する。Ｇｅｔｔｅｒ／Ｓｅｔｔｅｒが提供されて、ＲＶＤＣ（以下に説明する）、ＲＳＥ、およびＲＳＶ（以下に説明する）によって必要とされる様々な形態の属性を取得し、設定する。ＤａｔａＩｔｅｍは、自らをどのようにＳＱＬ  Ｓｅｒｖｅｒデータベースの中に追加するかを知っている。本発明の一例では、ＲＳＶは、ＲＳＤＩのプライベートインプリメンテーションとしてではなく、静的オブジェクトとしてインプリメントされる。この責任分離により、ＲＳＶのインプリメンテーションおよび保持がより簡単になる。
【００４７】
Ｒｕｌｅ  Ｓｅｔ  Ｄａｔａ  Ｍｏｄｅｌ（ＲＳＤＭ）は、インポートされているすべてのＲＳＤＩアイテムのための仮想データストアを提供する特殊化されたＡｂｓｔｒａｃｔＤａｔａＭｏｄｅｌである。
【００４８】
Ｒａｔｅ  Ｖｅｒｓｕｓ  Ｄｏｓｅ  Ｃａｌｃｕｌａｔｉｏｎ（ＲＶＤＣ）が、患者の体重、薬剤濃度、その他などの変数の文脈において、所与の薬用量に対応する送達速度を計算する。一例では、ＲＶＤＣは、特定の輸液ポンプインプリメンテーションに結び付けられていない。また、一例では、ＲＶＤＣアルゴリズムは、純粋に代数的である。ＲＳＤＩは、ＲＳＶによって抽出され、ＲＶＤＣに送られて、ＤｏｓｅＦｒｏｍＲａｔｅまたはｃａｌｃｕｌａｔｅＲａｔｅＦｒｏｍＤｏｓｅが計算されるデータを所有する。
【００４９】
Ｒｕｌｅ  Ｓｅｔ  Ｖａｌｉｄａｔｏｒ（ＲＳＶ）は、すべての規則セットデータフィールドに関する検証プロセスを調整する。ＲＳＶは、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度によって必要とされる制約をリセットすることから始める。ＲＳＶは、各フィールドを準拠について、以下のとおり組織的に検証する。すなわち、
・長さは、０または空白であってはならず、最大長を超えてはならない。
・ピクセル長は、ポンプ上の表示可能な領域を超えてはならない。
・名前が、無効な文字に関して検査される。
【００５０】
ＲＳＶは、ユーザ入力、インポートされたライブラリ、１つの場所から別の場所にコピーされた薬剤を含め、異なるソースからの規則セットを検証するのに使用され、ＣＣＡ最大速度設定値に対する調整を行う。ＲＳＶは、システム全体で、規則セットが、形式が正しく、有効であり、ライブラリ全体に関する送達準拠に違反しないことを検証するのに、一貫して、常に使用される。ユーザが、規則に違反するデータを入力しようと試みた場合、ダイアログボックスの中の「保存」ボタンが、低輝度表示されて、ディセーブルにされ、ユーザが、規則に違反するデータを変更することを余儀なくされる。図１５Ａは、薬剤に関する規則セットを編集する際に使用されるダイアログボックスの例を示す図である。この例では、ユーザは、所望されるものを何であれ編集し、次に、「保存」ボタンをクリックする。エントリが有効ではなかった場合、「保存」ボタンは、低輝度表示され、ユーザは、変更を保存することを許されない。
【００５１】
図１６は、規則セットバリデータ判定ツリーの一例を示す。図１６に示された判定ツリーは、規則セット限度の有効性を評価するのに使用される基本的な論理を表す。一般に、判定ツリーは、規則セットが、「ＮＯＮＥ」、「ＦＵＬＬ」、または「ＬＩＭＩＴＥＤ」であるかどうかを尋ね、次に、判定ツリーの中で概要が述べられた他の質問を尋ねて、規則セットが有効であるかどうかを判定する。図１６は、ユーザが、規則セットを作成している間、または編集している間に、キーボード入力またはマウス入力を行うたびに行われる動的検査を示す。また、図１６は、ＲＳＶがどのように検査を行って、そのような送達速度／薬用量が、薬用量限度に基づいて許容できるかどうかを確かめるかも示す。また、最大速度ＣＣＡインフューザ設定値などの、他の設定値も同様の形で考慮に入れられる、または分析されることが可能である。
【００５２】
本発明の別の特徴は、Ｄａｔａ  Ｍｏｄｅｌに関する。Ｄａｔａ  Ｍｏｄｅｌは、データを薬剤ライブラリの中にインポートすること、ソースから宛先ＣＣＡライブラリにコピーすること、およびＣＣＡライブラリ内のＣＣＡ設定値を編集することに使用される。以下の図は、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間の関係、および高レベルの対話を示す。図２２は、ＤａｔａＭｏｄｅｌとＤａｔａＩｔｅｍの間の関係を示す。簡明にするため、ＣＣＡＳｅｔｔｉｎｇおよびＣＣＡＬｉｂｒａｒｙ  ＤａｔａＭｏｄｅｌおよびＤａｔａＩｔｅｍは、図２２に示していない。図２３は、インポートプロセスとＲｕｌｅＳｅｔＤａｔａＩｔｅｍの間における高レベルの対話を示す図である。前述したとおり、インポートとＲＳＥの間で、いくつかの類似点が存在する。例えば、ＲＳＤＩが、ＲＳＶによって検証される。インポートプロセスは、タブ区切り値（ＴＳＶ）ファイルまたはカンマ区切り値（ＣＳＶ）ファイルを消費して、ＲＳＤＭオブジェクトを作成する。ＲＳＤＭは、Ｄｒｕｇ  Ｌｉｂｒａｒｙエントリ、ＣＣＡエントリ、ＣＣＡ  Ｌｉｂｒａｒｙ  Ｖｉｅｗエントリ、およびＭａｓｔｅｒ  Ｄｒｕｇ  Ｆｏｒｍｕｌａｒｙ（ＭＤＦ）エントリを作成するのに使用される。図２４Ａおよび図２４Ｂは、規則セットが、目標からソースＣＣＡ  Ｌｉｂｒａｒｙにコピーされる際の、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間における高レベルの対話を示す、２つの好ましいＵＭＬ図を示す。同様に、図２５は、ＣＣＡ  Ｓｅｔｔｉｎｇが、目標ＣＣＡ  Ｌｉｂｒａｒｙの中で編集される際の、ＤｒｕｇＬｉｂｒａｒｙＭａｎａｇｅｒ（ＤＬＭ）とＲＳＤＩの間における高レベルの対話を示す。
【００５３】
また、本発明は、Ｄｏｓｅ  Ｒａｔｅ  Ｅｄｉｔｏｒ（ＤＲＥ）と呼ばれる特殊化されたコンボボックスエディタも有する。ＤＲＥは、ｄｒｕｇＡｍｏｕｎｔ、ｄｉｌｕｅｎｔＡｍｏｕｎｔ、および限度についてのＤＲＤを確立するのに使用される。ＤＲＥは、薬用量入力と予約語「Ｎｏｎｅ」の両方を特に考慮に入れているため、独特である。ＤＲＥは、０のすべての絶対値（例えば、「０」、「０．０」、「０．００」、「なし」、その他）を「Ｎｏｎｅ」に変換し、０ではない値に関するすべての後続の０または小数点を除去する。
【００５４】
前述したとおり、本発明は、ハード限度とソフト限度の両方を同時に使用することができる。さらに、様々な関連するレポートが、１つまたは複数の輸液ポンプから生成されることが可能である。１つのタイプのレポートは、ソフト限度オーバライドレポート（以下に説明する）である。以下は、ソフト限度オーバライドレポートがどのように生成されることが可能かの例である。ＳｏｆｔＬｉｍｉｔ  Ａｌｅｒｔ／Ｏｖｅｒｒｉｄｅレポートのための永続ストレージ設計が、アップロードされたログの「保存」のための特定の要件と、生のログデータを解析して、臨床行為、部分的イベント、および重複ログエントリを明らかにする間接的な要件の両方によって推進される。一例では、すべてのログデータが、そのデータがアップロードされた源の輸液ポンプとの関連付けを保持する。
【００５５】
生のログデータは、アーカイブの目的とともに、ログ内容の直接報告（リスト表示（ｌｉｓｔｉｎｇ））をサポートするために保持される。保持に先立ち、生のログデータは、第１回の解析を受けて、ＰＣに既にアップロード済みであるが、輸液ポンプの中に格納されたままであった（アップロード後、ログがクリアされていないために）古いデータを表すログの部分が削除される。以下のデータベーステーブルが、解析されたログデータを保持するように定義される。
【表１】
0005647644.tif 000009
リストアップされた最初の３つのテーブル、ＵｐｌｏａｄＨｉｓｔｏｒｙ、ＵｐｌｏａｄＥｖｅｎｔ、およびＥｖｅｎｔＴｙｐｅは、生のアップロードされたイベントデータを保持する既存の機能をサポートする。リストアップされた第４のテーブル、ＣｌｉｎｉｃａｌＡｃｔｉｏｎは、個別のイベント（Ｓｏｆｔ  Ｌｉｍｉｔ  Ａｌｅｒｔ／Ｏｖｅｒｒｉｄｅ）に関する必要なコンテキストを提供して、有意な役立つレポートを生成することを目的とする。
【００５６】
前述したテーブルのそれぞれの個々のフィールドを以下に示す。最初に、ＵｐｌｏａｄＨｉｓｔｏｒｙからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表２】
0005647644.tif 000010
【００５７】
次に、ＵｐｌｏａｄＥｖｅｎｔからのフィールドを、それらのフィールドの目的とともにリストアップする。
【表３】
0005647644.tif 000011
【００５８】
次に、ＥｖｅｎｔＴｙｐｅからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表４】
0005647644.tif 000012
【００５９】
最後に、ＣｌｉｎｉｃａｌＡｃｔｉｏｎからのフィールドを、それらのフィールドの目的の説明とともにリストアップする。
【表５】
0005647644.tif 000013
一例では、リストアップされたフィールドのすべてが必須であり、「空白でない」ように制約される。この例では、すべてのデータフィールドが、「利用不可」という値をサポートして、特定のフィールドが、イベントログから取り出されることが可能でなかったために（例えば、ログが３２１行を超えた場合の上書きに起因して）、全く値を有さないことを示す。以下の図は、Ｓｏｆｔ  Ｌｉｍｉｔ  Ａｌｅｒｔイベントまたはオーバライド臨床イベントをサポートするデータモデルを示す。図２６は、ソフト限度警報イベントまたはオーバライド臨床イベントをサポートするデータモデルを示す図である。
【００６０】
図７Ａは、１つのソフト限度オーバライドレポートの例を示す。図７Ｂは、図７Ａに示された見出しおよびデータの説明を含む。図７Ｃ〜図７Ｆおよび図８Ａ〜図８Ｄは、この例では、ドーパミン、ヘパリン、インスリン、およびバンコマイシンである、いくつかの異なる薬剤に関するソフト限度オーバライドレポートおよびハード限度オーバライドレポートの例を示す。図７Ｃ〜図７Ｆに示されたレポートは、出される警報のタイプ（ハード下限、ソフト下限、ソフト上限、ハード上限）、ならびに各警報が出された回数をリストアップする。出される各タイプの警報に関して、レポートは、ユーザが、警報にどのように応答したかに関連する統計も示す。この例では、レポートは、警報がオーバライドされたまたはオーバライドされなかった回数を示す。さらに、情報のエントリを確認するように求められた際に、ユーザによって「いいえ」が入力された回数も示す。図８Ａ〜図８Ｄは、警報レポートおよびオーバライドレポートの別の例を示す。図８Ａ〜図８Ｄに示されたレポートは、各警報が、ＣＣＡ（この例では、ＩＣＵおよびＭｅｄＳｕｒｇ）によって隔てられていることを除いて、図７Ｃ〜図７Ｆに示されるレポートと同様である。以上の例から、任意の所望の情報が、本発明によって収集され、報告されることが可能であることが明白である。
【００６１】
本発明の１つの利点は、ハード限度とソフト限度の両方が、各薬剤に関して与えられることが可能であり、いずれの薬剤／ＣＣＡの組み合わせにも、１つ、２つ、３つ、または４つの限度が割り当てられることが可能なことである。ハード限度とソフト限度の両方を与える能力が存在する場合、使用されることが可能な限度の１６の組み合わせが存在する。４つの限度のそれぞれが、ある限度を指定する値を含むこと、または「限度」が、無制限（適切なフィールド内の「なし」によって示される）であることが可能である。それらの２つの可能性は、各限度に関して、すなわち、ハード下限、ソフト下限、ソフト上限、およびハード上限）に関して）存在する。この特徴は、ユーザが、ハード上限だけ、ハードとソフトの上限と下限、ハード上限およびソフト上限（下限なし）、ハード下限およびソフト下限（上限なし）、その他などの、様々な組み合わせでデバイスを構成することを可能にする。２つのセットの上限と下限の例では、構成の１６の可能な組み合わせが存在する。さらなる限度セットが使用される場合、より多くの組み合わせが可能である。一実施形態では、ハード限度は、ユーザによって無効にされることが可能でない、選択された薬剤、および選択されたＣＣＡに関する薬用量上限／薬用量下限である。別の実施形態におけるハード限度は、管理上の（ｓｕｐｅｒｖｉｓｏｒｙ）オーバライドを要求するか、または許すことが可能である。ハード限度、権限レベル、およびオーバライド可能性は、薬剤ライブラリ内の各薬剤に関して、病院によって定義される。特定の薬剤に関するハード限度は、割り当てられている場合、異なるＣＣＡにわたって異なる可能性がある。
【００６２】
一実施形態では、ソフト限度は、ユーザによって無効にされることが可能な、選択された薬剤、および選択されたＣＣＡに関する薬用量上限および／または薬用量下限である。特定の薬剤に関するソフト限度は、割り当てられている場合、ＣＣＡにわたって異なる可能性がある。ソフト限度に達した場合、警報または警告をトリガする規則セットが、薬剤ライブラリに関して提供される。警告は、操作者の側で、明確なオーバライドステップを要する。同様に、ユーザが、プログラミングすることを許される送達速度の範囲に対するハード限度を与える規則セットが、薬剤ライブラリに関して提供される。例えば、ソフト下限が、毎時１０ｍＬに設定され、臨床家が、毎時９ｍｌを入力した場合、インフューザは、ソフト限度オーバライド警報を表示する。インフューザの履歴ログの中に記録されるこの警報は、そのエントリが、その薬剤エントリに関して設定されたソフト限度の範囲外であることを臨床家に通知する。臨床家は、オーバライドを使用して、プログラミングを続けることを選択すること、またはオーバライドを取り消して、別の値を再入力することができる。臨床家が、ソフト限度を無効にすることを選択した場合、そのイベントが、インフューザの履歴ログの中に別個に記録される。ハード限度およびソフト限度は、他の様々な薬剤パラメータに関して設定されることが可能である。例には、投薬速度、薬剤送達時間、薬剤濃度、患者の体重、輸液されるべき量（ＶＴＢＩ）、その他が含まれる。
【００６３】
ハード限度および／またはソフト限度の別の用法は、正しいデータ入力に関する。例えば、時間エントリに対してハード限度を設定して、ユーザが、０から５９までの間の値だけを入力することができるようにすることが可能である。この例では、システムは、データ入力エラーに気付き、有効な範囲内の値を入力するようにユーザに強制する。別の例では、様々な薬剤フィールドに関して、一部の値または範囲だけが、入力されることを許される。１５Ｂは、薬剤単位フィールド、薬剤量フィールド、希釈液量フィールド、送達薬用量／速度単位フィールド、ならびにハード限度フィールドおよびソフト限度フィールドに関して入力されることが可能な値の例を示す。ユーザが他の値を入力することを試みる場合、システムはユーザに有効なフィールドを入力させ、または警報またはアラームを発する。
【００６４】
また、本発明は、１つのコンピュータから別のコンピュータへの薬剤ライブラリのインポートおよびエクスポートも可能にする。ライブラリがインポートされることが可能になるには、まず、ライブラリが、エクスポートされなければならない。一般に、薬剤ライブラリは、事前定義されたフォーマットを有する完成した薬剤ライブラリ（ＦＤＬ）にエクスポートされることが可能であり、そのフォーマットは、ライブラリを、ライブラリが、アクティブライブラリとしてインポートされ、設定されることが可能な他のコンピュータに、安全で、セキュリティで保護された形で移植可能にする。例えば、アクティブライブラリを有する第１のＰＣに関して、ライブラリは、バイナリフォーマットにエクスポートされ、ライブラリがインポートされる第２のＰＣに移されることが可能であり（ネットワーク、コンピュータ可読媒体、その他を介して）、したがって、第１のＰＣと第２のＰＣにおけるライブラリが同期される。特別ファイル拡張子（ＦＤＬ）、ならびにコンピュータ間におけるソフトウェアによる認識が、要求される。
【００６５】
ＦＤＬがエクスポートされると、薬剤ライブラリ全体がまず、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャ（以下を参照）を使用して、データベースから「選択される」。そのプロシージャは、実際、いくつかの選択ステートメントを含み、１つのテーブル当たり１つのステートメントを含む。テーブルは、コピー用のテーブルと同一である。各テーブルに関して、エクスポートメソッドが、テーブル名、行と列の数をシリアル化し、次に、各行が、列ごとにシリアル化される。元のデータベースインデックス値がシリアル化されることに留意されたい。ライブラリが、ファイルから読み取られると、インデックス値は、もはや有効ではないが、あたかもライブラリがコピーされたかのように同一に、マップされなければならない。一例では、ＦＤＬファイルは、「読み取り専用」ファイルである。ＦＤＬファイルは、Ｊａｖａ（登録商標）シリアル化フォーマットであるので、ＦＤＬファイルは、通常のソフトウェアアプリケーションを使用して、ユーザによって容易に変更されない。この特徴は、シリアル化を使用することの理由の一部であり、つまり、ユーザが、完成した薬剤ライブラリを改ざんするのをやめさせるためである。
【００６６】
ＦＤＬがインポートされると、最初に、すべてのシリアル化された情報が、３次元アレイの形態でメモリに読み込まれる。テーブルに関する１つの次元、行に関する１つの次元、および列に関する１つの次元の、３つのアレイ次元が存在する。行の次元のサイズ、および列の次元のサイズは、各テーブルに関して異なることが可能である。この「生の」データが、テーブルごと、行ごとにデータベースに挿入される。また、インデックスマッピングも、途中で実行されることが可能である。次に、行が挿入されると、新たなインデックス値が生成されて、コピー操作中に行われるのと同様に、マップの中に格納される。一部のテーブルは、他の、以前に挿入されたテーブルに対するインデックスを含むことが可能である。それらのインデックスは、生成されたマップを使用して、元の値から新たな値に変換される。それらの変換されたインデックス値は、新たな行に挿入される値である。ＦＤＬは、データベースの中に格納された後、Ｆｉｎａｌｉｚｅｄ  Ｄｒｕｇ  Ｌｉｂｒａｒｙとなり、別のＦｉｎａｌｉｚｅｄ  Ｄｒｕｇ  ＬｉｂｒａｒｙをＡｒｃｈｉｖｅｄライブラリにする。
【００６７】
以下は、いずれの順序でテーブルがアレイの中に格納されているか、インデックス依存関係は、どのようなものか、いずれの列をマップの中に格納するか、いずれの列値が、挿入されることが可能になるには、まず、新たな値にマップされる必要があるか、その他をＦＤＬインポートに知らせる、ＦＤＬＤａｔａ．ｊａｖａの説明である。
【００６８】
薬剤ライブラリをコピーする場合と同様に、ＦＤＬインポート中にテーブルが処理される順序が重要であることを認識することが重要である。その順序は、列挙された定数としてＦＤＬＤａｔａ．ｊａｖａファイルの中に符号化される。以下は、そのような列挙された定数の例である。すなわち、
【数７】
0005647644.tif 000014
【００６９】
以上の定数は、前述した生のデータの３次元アレイへのインデックスとして使用されることが可能である。また、このコードセクションは、データベーススキーマに変更が行われた場合、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌによって生成されることも可能である。
【００７０】
エクスポート／インポートされる各テーブルに関して、テーブル名、列の数、他のテーブルが依存する可能性がある列が存在するとすれば、列のいずれか（ｉｄＣｏｌｕｍｎ）、および最後に、そのテーブルが依存するテーブルに対するインデックスセットを常に把握しているＴａｂｌｅＩｎｆｏのインスタンスが存在する。「ｉｄＣｏｌｕｍｎ」は、指定されている場合、行が挿入されるにつれ、そのテーブルの各行に関するデータベースによって生成される。古い値（シリアル化されたファイルからの）と新たな値（データベース行挿入からの）が、インデックスマップの中に格納される。次に、古いインデックスを参照する他のすべてのメモリ内テーブルが、新たなインデックスを含むように更新されてから、行が挿入される。例えば、以下に示されるＲｕｌｅＳｅｔテーブルの「ｉｄＣｏｌｕｍｎ」は、そのテーブルのＲｕｌｅＳｅｔＩＤ列であり、ＲｕｌｅＳｅｔＩＤ列は、偶然、ＴａｂｌｅＩｎｆｏテーブルの中の第２の列である。このため、ＲｕｌｅＳｅｔに関するＴａｂｌｅＩｎｆｏインスタンスにおける「ｉｄＣｏｌｕｍｎ」は、１（第１の列は、０、第２の列は、１，．．．）である。次に、ＦＤＬがエクスポートされた際、ＲｕｌｅＳｅｔＩＤが５０４７であったＲｕｌｅＳｅｔテーブルの中の行が存在していたものと想定されたい。すなわち、
【表６】
0005647644.tif 000015
ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙテーブル（以下に示す）はそれぞれ、ＲｕｌｅＳｅｔ依存関係、つまり、それぞれのＲｕｌｅＳｅｔＩＤ列を有する。
【表７】
0005647644.tif 000016
次に、ＦＤＬがインポートされる際、ＲｕｌｅＳｅｔテーブル（以下に示す）のその特定の行に、５１２２という新たなインデックス値が与えられるものと想定されたい。
【表８】
0005647644.tif 000017
後に、ＣｃａＬｉｂｒａｒｙテーブルまたはＤｒｕｇＦｏｒｍｕｌａｒｙテーブルが挿入される前に、５０４７のあらゆるＲｕｌｅＳｅｔＩＤ値がまず、５１２２に変更される。１という「ｉｄＣｏｌｕｍｎ」設定値が、５０４７−５１２２マッピングを格納するようにＦＤＬインポートコードに告げる。
【表９】
0005647644.tif 000018
ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙテーブルの中の５０４７値が、依然としてメモリの中に、つまり、生のデータの３次元テーブルの中にある間に、５１２２に変更される。それらのテーブルが処理された後、ＣｃａＬｉｂｒａｒｙテーブルおよびＤｒｕｇＦｏｒｍｕｌａｒｙＩＤテーブルが、以下に示される。
【表１０】
0005647644.tif 000019
【００７１】
ＦＤＬＤａｔａ．ｊａｖａファイルを再び参照すると、ファイルの様々なセクションが、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルによって自動的に生成される。それらのセクションは、そのファイルの出力からｊａｖａコードにカットアンドペーストが行われることが可能である。具体的には、テーブル順序定数（以上に示す）、ならびにＴａｂｌｅＩｎｆｏアレイおよびそのアレイの内容が、データベーススキーマ変更のイベントにおいて生成されることが可能である。
【００７２】
また、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルは、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャ（以下に説明する）の大部分も同時に生成する。この場合も、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルが生成するＳＱＬコードは、ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ．ｓｑｌファイル内の適切な場所にカットアンドペーストが行われることが可能である。
【００７３】
ＦＤＬがエクスポートされる際、ライブラリを構成するデータが、データベースから獲得される（そのデータが、ファイルにシリアル化されることが可能であるように）。ＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ格納プロシージャが、それを行う。プロシージャは、いくつかの選択ステートメントを利用し、テーブルを特定の順序で選択し、任意の所与のテーブルの列を特定の順序で選択する。
【００７４】
テーブルの順序、およびそれらのテーブル内の列の順序は、薬剤ライブラリを再構築するＦＤＬインポートコードに重要であるので、ＦＤＬエクスポート、ＦＤＬインポート、およびＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙコードが、互いに同期して保たれることが不可欠である。データベーススキーマのほんのわずかな変更も、ＦＤＬＤａｔａ．ｊａｖａおよびＳｅｌｅｃｔＥｎｔｉｒｅＤｒｕｇＬｉｂｒａｒｙ、ならびにＣｏｐｙＤｒｕｇＬｉｂｒａｒｙ格納プロシージャの変更を余儀なくさせる。ほんのわずかな誤り（不一致）によっても、適切に機能しなくなる。
【００７５】
ＣｏｐｙＤｒｕｇＬｉｂｒａｒｙコードを除いて、ｊａｖａ変更およびＳＱＬ変更のほとんどは、新たなスキーマが配備された後、ＰｏｓｔＳｃｈｅｍａＣｈａｎｇｅ．ｓｑｌファイルを実行することによってもたらされることが可能である。それらのファイルの中の一致する／類似のコードの上に、生成されたコードを単にカットアンドペーストする。また、ＣｏｐｙＤｒｕｇＬｉｂｒａｒｙコード変更も、自動化されることが可能である。
【００７６】
本発明の１つの特徴は、データが、システムにインポートされること、およびシステムからエクスポートされることが可能なことである。カンマ区切り値（ＣＳＶ）またはタブ区切り値（ＴＳＶ）を使用するライブラリテキストファイルが、システムによってインポートされることが可能である。１つの独特な特徴は、ファイル全体が、前述したＲＳＶ検査に合格しなければならず、さもなければ、インポート全体が、無効と見なされることである。
【００７７】
本発明は、様々なポンプまたは医療デバイスに適用可能であり、本明細書で本発明を説明するのに使用されているポンプに限定されないことが当業者には認識されよう。さらに、本発明を逸脱することなく、ポンプとコンピュータの間における接続は、無線であることも、有線であることも可能であることが当業者には認識されよう。無線通信エンジンが、ポンプおよびコンピュータに接続され、ＢＬＵＥＴＯＯＴＨ（商標）（ＩＥＥＥ８０２．１５）、あるいはＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｂ、およびＩＥＥＥ８０２．１１ｇに記載されるような他のプロトコルなどの、通信プロトコルを利用する無線ネットワークを使用することが可能である。無線ネットワーク内の通信は、無線周波数電磁放射、赤外線放射、またはネットワーク要素間で無線通信を達するための他の手段を利用することができる。
【００７８】
一例では、プラグアンドプレイモジュール４が、無線通信エンジンまたは無線接続エンジンを収容する、または入れることができる。医療ポンプのための従来の無線通信モジュールは、最適な送受信のために、外部プラグイン、ボルト留めタイプであった。それらの従来の通信モジュールは、ポンプのために要求される空間を大幅に大きくし、ポンプの外形を変える。それらのモジュールは、ポンプが落とされた場合、損傷を受ける、または外れる可能性がある。さらに、他の医療機器に対する干渉の可能性を防止するように、医療機器からの最大電気放射に関する厳格な標準が存在する。本発明の無線プラグアンドプレイモジュール４は、ポンプによって占有されるスペースを大幅に大きくしない。以下に説明する、改良されたアンテナ設計で、ポンプ筐体２内部にプラグアンドプレイモジュール４を配置することにより、依然として、良好な位置／向きの許容度の大きい（ｐｏｓｉｔｉｏｎ／ｏｒｉｅｎｔａｔｉｏｎ  ｔｏｌｅｒａｎｔ）送受信特性がもたらされ、デバイスからの電子放射が低下して、よりよく制限されるという意外な結果がもたらされる。
【００７９】
前述したとおり、本発明の輸液ポンプは、他の様々なデバイスに接続されることが可能である。一例では、本発明は、接続エンジンを使用して、ポンプが、様々な他のデバイスに接続することを可能にすることに加えて、システム機能を提供する。以下は、本発明で使用されることが可能な接続エンジンの一例である。前述した例では、様々な特徴および能力が、所望に応じてカスタマイズされることが可能である。
【００８０】
接続エンジンは、重要なシステム機能を提供すること、ならびに有線通信リンクと無線通信リンクの両方を介して、薬物管理ユニット（ＭＭＵ）、病院情報システム（ＨＩＳ）、薬局情報システム（ＰｈＩＳ）、およびその他の医療情報システムを含む様々な外部システムに、インフューザが接続することができるようにすることを目的とする、インフューザの筐体内部のアセンブリである。接続エンジンは、エンジンの印刷配線アセンブリ上のデータバスおよびアドレスバスを介して、基板−基板コネクタを介して、ＣＰＵ印刷配線アセンブリとインタフェースをとることができる。一例では、接続エンジンは、インフューザＣＰＵ印刷配線アセンブリのために、約１〜２メガバイトの読み取り専用プログラムと、１メガバイト以上の読み取り／書き込みデータメモリとをサポートする。接続エンジンは、インフューザユニットの後部上で外部に位置するシリアルデータポートを介して、ホストコンピュータと通信することができる。一例では、データポートは、電気的に絶縁される。
【００８１】
この例では、接続エンジンは、ユニットの後部上で外部からアクセス可能な、フロントパネルロックアウトスイッチを含む。また、接続エンジンは、ユニットの後部上で外部に位置する看護士呼び出しインタフェースも含むことが可能である。看護士呼び出しインタフェースは、患者が、アラームメッセージを看護士に送ることを可能にする、患者によって保持されるスイッチなどの、看護士呼び出しデバイスとともに使用されることを許す。また、接続エンジンは、器具の背後からアクセス可能なアラーム音量コントロールも含むことが可能である。このコントロールは、エラー、警告、その他をユーザに知らせる可聴アラームに関する音量レベルを調整する。
【００８２】
接続エンジンは、インフューザと外部システムの間で双方向通信を確立する目的で、様々な外部システムに対するインフューザの相互接続をサポートすることができるモジュール型のインテリジェントな印刷配線アセンブリである。外部システムの例には、薬物管理ユニット（ＭＭＵ）、医療情報システム、ＨＩＳ、および外部無線アクセスポイントが含まれることが可能である。外部システムのその他の例には、薬剤ライブラリおよびソフトをインフューザにダウンロードするため、およびインフューザからログをアップロードするための、１つまたは複数のＰＣが含まれる。
【００８３】
前述したとおり、本発明は、有線通信と無線通信の両方が可能である。サポートされることが可能な有線インタフェースの例には、イーサネット（登録商標）の１０ＢａｓｅＴおよび１００ＢａｓｅＴの標準、ならびにメガビットインタフェースおよび光ファイバインタフェースが含まれる。サポートされることが可能な無線インタフェースの例には、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ、ならびに他のあらゆる所望されるインタフェースが含まれる。接続エンジンは、ＸＭＬサービス、ＨＴＭＬサービス、ｆｔｐサービス、およびＴｅｌｎｅｔサービスを含め、様々なネットワークプロトコルをサポートすることができる。
【００８４】
一例では、本発明は、通常、有線インタフェースか、または無線インタフェースを使用して動作する。別の実施形態では、本発明は、有線インタフェースと無線インタフェースの両方を同時に使用することができる。その例では、いずれかのモードで障害が検出された場合、すべての通信が、機能しているモードに自動的に切り替わることが可能である。
【００８５】
接続エンジンハードウェアは、所望される機能および能力に依存して、多くの形態をとることができる。一例では、接続エンジンは、以下のサブ回路を含む。すなわち、ＣＰＵメモリ、つまり、ＲＡＭおよびフラッシュ、外部シリアルインタフェース、看護士呼び出しインタフェース、オーディオ音量コントロール、ロックアウトスイッチ、接続エンジンコントローラ、イーサネット（登録商標）インタフェース、無線インタフェース、およびアンテナアセンブリである。また、以下の外部コネクタも、含まれることが可能である。すなわち、イーサネット（登録商標）ＲＪ−４５コネクタ、Ｗｉ−Ｆｉトランシーバをアンテナ印刷配線アセンブリに接続するためのＲＦコネクタ、ＲＳ２３２シリアルポートＤＢ９コネクタ、および看護士呼び出しインタフェースコネクタである。
【００８６】
図９〜図１１は、本発明で使用されることが可能な、取り外し可能なプラグアンドプレイモジュールではなく、ポンプ筐体内部に完全に密閉された例示的な接続エンジンのブロック図である。図９は、ユニバーサルシリアルバス（ＵＳＢ）を介して接続エンジン２２に接続されたユーザインタフェースコントローラ（ＵＩＣ）２０を示す。もちろん、他のインタフェースも使用されることが可能である（例えば、ＲＳ２３２シリアルインタフェース、パラレルインタフェース、その他）。接続エンジン２２は、イーサネット（登録商標）接続およびＷｉＦｉ接続を有する、図９に示された入出力基板である。図１０は、プロセッサ２４を含む接続エンジンのブロック図である。プロセッサ２４は、イーサネット（登録商標）トランシーバ２６およびトランス２８に接続されて、１つまたは複数のＰＣ１０と通信するイーサネット（登録商標）インタフェースをもたらす。また、このインタフェースは、無線で提供されることも可能である。プロセッサは、ＵＳＢコントローラ３０にも接続される。ＵＳＢコントローラ３０は、ＵＳＢインタフェースを介して、ＵＩＣ  ＵＳＢクライアント３２およびＲＦトランシーバ３４に接続される。
【００８７】
２つのアンテナ３６および３８を有するＲＦトランシーバ３４が示されている。本発明は、１つだけのアンテナを含んでもよいが、２つのアンテナが、本発明の性能を向上させることができる。本発明と他のデバイスの間の通信は、クリティカルである可能性があるので、可能な最も信頼できる無線通信を提供することが望ましい。２つのダイバース（ｄｉｖｅｒｓｅ）アンテナが、本発明の無線通信カバレッジを最適化する。本発明は、２つの異なるダイバーシチスキーム、空間ダイバーシチ、およびパターンダイバーシチの組み合わせを使用する。従来、空間ダイバーシチでは、２つの同一のアンテナが、２つの別個の場所に配置されて、共通の受信機にダイバーシチ受信をもたらす。そのケースでは、スキームは、アンテナを物理的に分離するだけでなく、２つのアンテナを直角に配置することにより、パターンダイバーシチも実現する。このようにして、１つのアンテナにおけるピークが、他方のアンテナのゼロ（ｎｕｌｌ）を埋めて、複合アンテナ指向性図（ｃｏｍｂｉｎｅｄ  ｒａｄｉａｔｉｏｎ  ｐａｔｔｅｒｎ）が、単一のアンテナだけよりも、より全方向性に見えるようにする。このアンテナダイバーシチスキームは、いくつかの目的を達する。第１に、外部からそれほど明らかでないアンテナを有することが望ましく、内部に組み込まれたアンテナを使用することが望ましくなる。第２に、ほとんどのアプリケーションにおいて、本発明は、デバイスが放射することができる放射の量を制限する、ＩＥＣ６０６０１−１−２、２ｎｄ  Ｅｄｉｔｉｏｎ標準で指定されるＥＭＣ要件を満たさなければならない。２つのダイバースアンテナの使用は、以上の目的を達するのに役立つ。一例では、本発明で使用されるアンテナは、輸液ポンプの筐体内部に密閉される。これは、ほこり、有害な溶媒、およびごみをアンテナに近づけないようにするのに役立ち、放射の制限を強化するとともに、アンテナの損傷の可能性を低くする。
【００８８】
別の例では、接続エンジンは、情報を一時的に格納するためのキャッシュとして使用されるメモリを含む。キャッシュは、システムをより効率的に、より信頼できる形で機能させることができる。
【００８９】
図１１は、図１０に示される無線インタフェースのブロック図であり、ホストコンピュータと通信するためのＵＳＢインタフェースを含むベースバンドプロセッサ−媒体アクセスコントローラ４０を示す。プロセッサ４０は、変調器／復調器４２、ＲＦ／ＩＦ変換器４４、および電力増幅器４６に接続される。アンテナ３６および３８が、電力増幅器４６およびＲＦ／ＩＦ変換器４４によって駆動される。
【００９０】
図１２Ａ〜図１５Ａは、Ａｂｂｏｔｔ  ＰＬＵＭ  Ａ＋（登録商標）インフューザに適用された、本発明の一例の電子システム図である。図１２Ａ〜図１２Ｄは、ＣＰＵ、および通信エンジンまたは接続エンジンを示す。通信エンジンは有線または無線のインタフェースを介した他のデバイスとの通信を容易にする。通信エンジンは、図９〜図１１に関連して前述したのと同一の直角に配置されたアンテナを利用することができる。また、図１２は、スイッチおよびユーザコントロール、看護士呼び出しジャック、キーパッド、アラームスピーカ、ＬＥＤ、その他などの、様々なコンポーネントとインタフェースをとるためのデジタルＩ／Ｏチップも示す。図１３は、電源回路および絶縁バリアを含む、電源サブシステムを示す。図１４は、圧力センサ、空気センサ、モータ位置センサ、およびモータドライブを含む、機構サブシステムを示す。
【００９１】
図１７は、患者自己管理鎮痛（ＰＣＡ）ポンプの電子システムブロック図である。図１８および図１９は、図１７に示されるＰＣＡポンプで使用されることが可能な接続エンジンの電子システムインタフェースブロック図である。図１７は、システムに電力を供給する電源を含む。マイクロコントローラが、キーパッド、患者ペンダント、シリアルポート、バーコード読み取り装置、様々なセンサ、様々なスイッチ、モータドライブ、ディスプレイおよびＬＥＤインジケータ、ならびにスピーカを含め、システムの様々なコンポーネントとインタフェースをとる。
【００９２】
図１８は、図１７に示されるＰＣＡシステムで使用されることが可能な接続エンジンのブロック図である。図１８は、接続エンジンと、イーサネット（登録商標）、ＷｉＦｉ、外部ＲＳ２３２シリアルインタフェース、ならびにホストデバイスに対するＲＳ２３２シリアルインタフェースを含む、いくつかのインタフェースとを示す。また、図１８は、接続エンジンが、ＰＣＡポンプ（図１７）から電源をとることができる（電源コネクタを介して）接続エンジンも示す。ＰＣＡポンプは、様々なモータに電力を供給するためのモータ電圧ＶＭＯＴを生成する。同一の電圧ＶＭＯＴを使用して、接続エンジンに電力が供給されることが可能である。
【００９３】
図１９は、図１８の接続エンジンのより詳細なブロック図である。接続エンジンは、イーサネット（登録商標）プロセッサと８０２．１１ｂ無線トランシーバをともに組み込んだ有線／無線接続モジュールである、接続エンジンコントローラ（ＣＥＣ）を含む。イーサネット（登録商標）トランシーバ、およびすべての必要な回路は、ＲＪ−４５ジャックを介して１０／１００Ｂａｓｅ  Ｔインタフェースを提供する。ＵＳＢコントローラ、およびすべての必要な回路が、ＷｉＦｉに対するＵＳＢ（ホスト）インタフェースを制御する。２つのＲＳ２３２ポートが、システムバスに接続される。また、接続エンジンは、ＦＬＡＳＨメモリおよびＳＤＲＡＭメモリも含む。
【００９４】
以上の詳細な説明では、本発明を、本発明の特定の例示的な諸実施形態に関連して説明した。特許請求の範囲に記載される本発明のより広い範囲を逸脱することなく、それらの実施形態に様々な改変および変更が行われることが可能である。したがって、本明細書および図面は、制限的ではなく、例示的であると見なされるべきである。
【図１Ａ】
0005647644.tif 000020
【図１Ｂ】
0005647644.tif 000021
【図１Ｃ】
0005647644.tif 000022
【図１Ｄ】
0005647644.tif 000023
【図１Ｅ】
0005647644.tif 000024
【図１Ｆ】
0005647644.tif 000025
【図１Ｇ】
0005647644.tif 000026
【図２】
0005647644.tif 000027
【図３】
0005647644.tif 000028
【図４Ａ】
0005647644.tif 000029
【図４Ｂ】
0005647644.tif 000030
【図５】
0005647644.tif 000031
【図６】
0005647644.tif 000032
【図７Ａ】
0005647644.tif 000033
【図７Ｂ】
0005647644.tif 000034
【図７Ｃ】
0005647644.tif 000035
【図７Ｄ】
0005647644.tif 000036
【図７Ｅ】
0005647644.tif 000037
【図７Ｆ】
0005647644.tif 000038
【図８Ａ】
0005647644.tif 000039
【図８Ｂ】
0005647644.tif 000040
【図８Ｃ】
0005647644.tif 000041
【図８Ｄ】
0005647644.tif 000042
【図９】
0005647644.tif 000043
【図１０】
0005647644.tif 000044
【図１１】
0005647644.tif 000045
【図１２Ａ】
0005647644.tif 000046
【図１２Ｂ】
0005647644.tif 000047
【図１２Ｃ】
0005647644.tif 000048
【図１２Ｄ】
0005647644.tif 000049
【図１３】
0005647644.tif 000050
【図１４】
0005647644.tif 000051
【図１５Ａ】
0005647644.tif 000052
【図１５Ｂ】
0005647644.tif 000053
【図１６】
0005647644.tif 000054
【図１７Ａ】
0005647644.tif 000055
【図１７Ｂ】
0005647644.tif 000056
【図１７Ｃ】
0005647644.tif 000057
【図１８】
0005647644.tif 000058
【図１９】
0005647644.tif 000059
【図２０Ａ】
0005647644.tif 000060
【図２０Ｂ】
0005647644.tif 000061
【図２１】
0005647644.tif 000062
【図２２】
0005647644.tif 000063
【図２３】
0005647644.tif 000064
【図２４Ａ】
0005647644.tif 000065
【図２４Ｂ】
0005647644.tif 000066
【図２５】
0005647644.tif 000067
【図２６】
0005647644.tif 000068