System for maintaining drug information and communicating with medication delivery device
Abstract
Problem to be solved.To provide one or more medication delivery devices or a system for communicating with the medication delivery devices.
Solution.The system is used for maintaining drug information and communicating with the medication delivery devices including a software designed for use in a hospital, pharmacy or biomedical technical service environments. The software may be provided on a computer readable medium. The software allows a facility to customize a drug library with both hard and soft drug limits and other parameters for use with an infuser having a plug and play module removably inserted into a slot within a housing, or for use with an infuser having a connectivity engine enclosed within the housing. The system supports data transfer to one or more infusers connected to one or more computers 10.

Term
Projected expiry 9 May 2032.
- Priority
- Filed
- Published
- Today
- Projected expiry
232 claims: 18 independent, 214 dependent
- 1少なくとも1つの薬物投与デバイスと通信する方法であって、 マシン可読フォーマットでデータを格納するために少なくとも1つの薬物投与デバイスに格納ロケーションを提供すること、 リモートデバイスと無線で通信するための無線インタフェースを提供すること、および リモートデバイスから少なくとも1つの薬物投与デバイスに情報を無線で送信することを含み、情報は、拡張マークアップ言語を使用して送信される、方法。
- 2情報は、薬剤ライブラリに関するエントリを含む、請求項1に記載の方法。
- 3情報は、薬物投与デバイスパラメータを含む、請求項1に記載の方法。
- 4少なくとも1つの薬物投与デバイスを構成する複数の薬物投与デバイスを提供することをさらに含む、請求項1に記載の方法。
- 5無線インタフェースを提供することは、少なくとも1つのアンテナを提供することを含む、請求項1に記載の方法。
- 6少なくとも1つのアンテナを無線インタフェースケース内に収容することをさらに含む、請求項5に記載の方法。
- 7少なくとも1つのアンテナおよび格納ロケーションを薬物投与デバイスの筐体内に収容することをさらに含む、請求項5に記載の方法。
- 8無線インタフェースを提供することは、2つのアンテナを提供することを含む、請求項1に記載の方法。
- 92つのアンテナは、空間的に異なる、請求項8に記載の方法。
- 102つのアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項8に記載の方法。
- 112つのアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項8に記載の方法。
- 12薬物投与デバイスから情報を受信することをさらに含む、請求項1に記載の方法。
- 13薬物投与デバイスから受信される情報は、イベントログを含む、請求項12に記載の方法。
- 14薬物投与デバイスは、輸液ポンプである、請求項1に記載の方法。
- 15薬物投与デバイスは、患者自己管理鎮痛ポンプである、請求項1に記載の方法。
- 16薬物投与デバイスは、歩行ポンプである、請求項1に記載の方法。
- 171つまたは複数の処方された薬物を患者に投与するための装置であって、 装置の動作を制御するためのコントローラと、 装置に関するデバイスパラメータをマシン可読フォーマットで格納するための、コントローラに電気的に結合された1つまたは複数の格納ロケーションと、 外部デバイスと無線で通信するための、コントローラに電気的に結合された無線インタフェースとを含む、装置。
- 18装置は、輸液ポンプである、請求項17に記載の装置。
- 191つまたは複数の格納ロケーションは、薬剤ライブラリを格納する、請求項17に記載の装置。
- 20無線インタフェースと外部デバイスの間の通信は、拡張マークアップ言語を使用する、請求項17に記載の装置。
- 21装置は、無線インタフェースに結合されたアンテナをさらに含む、請求項17に記載の装置。
- 22装置は、コントローラと、1つまたは複数の格納ロケーションと、無線インタフェースと、アンテナとを収容する筐体をさらに含む、請求項21に記載の装置。
- 23装置は、無線インタフェースに結合された第1のアンテナと第2のアンテナとをさらに含む、請求項21に記載の装置。
- 24第1のアンテナと第2のアンテナは、空間的に異なる、請求項23に記載の装置。
- 25第1のアンテナと第2のアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項23に記載の装置。
- 26第1のアンテナと第2のアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項23に記載の装置。
- 27装置は、コントローラと、1つまたは複数の格納ロケーションと、無線インタフェースと、第1のアンテナと、第2のアンテナとを収容する筐体をさらに含む、請求項26に記載の装置。
- 281名または複数名の患者に薬物を投与するための方法であって、 薬物投与デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための1つまたは複数の格納ロケーションと、無線インタフェースとをそれぞれが有する複数の薬物投与デバイスを提供すること、 ホストコンピュータを提供すること、 ホストコンピュータ上で薬剤ライブラリを構成すること、および ホストコンピュータ上の薬剤ライブラリから、無線インタフェースを介して、薬物投与デバイスの少なくともいくつかに情報を送信することを含む、方法。
- 29情報は、薬物投与デバイスの1つだけにポイントツーポイントの形で送信される、請求項28に記載の方法。
- 30情報は、薬物投与デバイスのすべてに同時にブロードキャストされる、請求項28に記載の方法。
- 31ホストコンピュータから受信された情報に少なくとも部分的に基づき、患者に薬剤を投与することをさらに含む、請求項28に記載の方法。
- 32情報は、拡張マークアップ言語を使用して薬物投与デバイスに送信される、請求項28に記載の方法。
- 33筐体内に少なくとも1つのアンテナを収容することをさらに含む、請求項28に記載の方法。
- 34筐体は、コントローラ、および薬物投与デバイスの1つまたは複数の格納ロケーションも収容する、請求項33に記載の方法。
- 35薬物投与デバイスの無線インタフェースのための2つのアンテナを提供することをさらに含む、請求項28に記載の方法。
- 362つのアンテナは、空間的に異なる、請求項35に記載の方法。
- 372つのアンテナは、直角に配置されて、パターンダイバーシチを実現する、請求項35に記載の方法。
- 382つのアンテナは、直角に配置され、空間的に異なって、パターンダイバーシチと空間ダイバーシチをともに実現する、請求項35に記載の方法。
- 39薬物投与デバイスは、輸液ポンプである、請求項28に記載の方法。
- 40薬物投与デバイスは、患者自己管理鎮痛ポンプである、請求項28に記載の方法。
- 41薬物投与デバイスは、歩行ポンプである、請求項28に記載の方法。
- 42薬物投与デバイスからホストコンピュータに情報を送信することをさらに含む、請求項28に記載の方法。
- 43情報は、拡張マークアップ言語を使用して薬物投与デバイスからホストコンピュータに送信される、請求項42に記載の方法。
- 44ホストコンピュータによって受信される情報は、イベントログを含む、請求項43に記載の方法。
- 45薬物投与デバイスによって送信された情報から1つまたは複数のレポートを生成することをさらに含む、請求項43に記載の方法。
- 461つまたは複数のレポートは、イベントログからの情報を含む、請求項45に記載の方法。
- 471つまたは複数のレポートは、薬物投与デバイスの動作に関連する情報を含む、請求項45に記載の方法。
- 48薬剤ライブラリから情報を送信するステップは、薬物に関するハード限度を提供することを含む、請求項28に記載の方法。
- 49薬剤ライブラリから情報を送信するステップは、薬物に関するソフト限度を提供することを含む、請求項28に記載の方法。
- 50薬剤ライブラリから情報を送信するステップは、薬物に関するハード限度とソフト限度の両方を提供することを含む、請求項28に記載の方法。
- 511つまたは複数の薬物投与デバイスと通信する方法であって、 ホストコンピュータを提供すること、 1つまたは複数の薬物投与デバイスを提供すること、 拡張マークアップ言語(XML)を使用してメッセージをフォーマットすること、および XMLフォーマットされたメッセージを、ホストコンピュータから1つまたは複数の薬物投与デバイスの少なくとも1つに送信することを含む、方法。
- 52XMLフォーマットされたメッセージを1つまたは複数の薬物投与デバイスの1つからホストコンピュータに送信することをさらに含む、請求項51に記載の方法。
- 53受信されたXMLフォーマットされたメッセージを解析して、ホストコンピュータによって送信された情報を獲得することをさらに含む、請求項51に記載の方法。
- 54XMLフォーマットされたメッセージは、無線で送信される、請求項51に記載の方法。
- 55メッセージをフォーマットすることは、 1つまたは複数のXML識別子を使用してメッセージをフォーマットすること、および 1つまたは複数のXML識別子を短縮して、XMLフォーマットされたメッセージを送信するのに要求される帯域幅を低減することをさらに含む、請求項51に記載の方法。
- 56ホストコンピュータ上に薬剤ライブラリを格納することをさらに含む、請求項51に記載の方法。
- 57XMLフォーマットされたメッセージは、格納された薬剤ライブラリからの情報を含む、請求項56に記載の方法。
- 581つまたは複数の薬物投与デバイスは、輸液ポンプである、請求項51に記載の方法。
- 59メッセージは、正規形式になっている、請求項51に記載の方法。
- 60メッセージの中に含まれる情報を検証することをさらに含む、請求項51に記載の方法。
- 61情報は、XMLスキーマを使用して検証される、請求項60に記載の方法。
- 62情報を検証するステップは、ホストコンピュータからの情報の正規表現を、メッセージを受信した1つまたは複数の薬物投与デバイスの少なくとも1つからの情報の正規表現と比較するステップをさらに含む、請求項60に記載の方法。
- 63検証された情報は、複数のビットを含み、正規表現は、右から左へのビット順序を使用して生成される、請求項62に記載の方法。
- 64ホストコンピュータおよび薬物投与デバイスによって格納されたデータを検証することをさらに含む、請求項51に記載の方法。
- 65データを検証するステップは、ホストコンピュータによって格納されたデータの正規表現を、薬物投与デバイスによって格納されたデータの正規表現と比較するステップをさらに含む、請求項64に記載の方法。
- 661名または複数名の患者に薬物を投与する方法であって、 ホストコンピュータを提供すること、 薬剤ライブラリを構成する薬剤送達情報を格納するように、ホストコンピュータを使用すること、 格納された薬剤送達情報に関連するデータ含むメッセージを生成するように、拡張マークアップ言語(XML)を使用すること、 生成されたメッセージを薬物投与デバイスに送信すること、 格納された薬剤送達情報からデータを抽出するように、送信されたメッセージを薬物投与デバイスにおいて解析すること、および 抽出されたデータに少なくとも部分的に基づき、薬物投与デバイスを使用して薬物を患者に投与することを含む、方法。
- 67薬物投与デバイスは、輸液ポンプである、請求項66に記載の方法。
- 68メッセージは、無線で薬物投与デバイスに送信される、請求項66に記載の方法。
- 69薬物投与デバイスにおいてメッセージを生成するように、拡張マークアップ言語(XML)を使用することをさらに含む、請求項66に記載の方法。
- 70メッセージを薬物投与デバイスからホストコンピュータに送信することをさらに含む、請求項69に記載の方法。
- 71薬物投与デバイスは、患者に薬物を投与するための1つまたは複数のポンプを含み、方法が、 抽出されたデータに少なくとも部分的に基づき、1つまたは複数のポンプの動作を制御することをさらに含む、請求項66に記載の方法。
- 72薬剤送達情報は、1つまたは複数の薬剤ライブラリを含む、請求項66に記載の方法。
- 73複数の薬物投与デバイスに薬剤ライブラリをダウンロードする方法であって、 複数の薬物投与デバイスを提供すること、 ホストコンピュータを提供すること、 薬剤ライブラリをホストコンピュータに格納すること、 ホストコンピュータと複数の薬物投与デバイスの間の通信を提供するように、拡張マークアップ言語(XML)を使用すること、および ホストコンピュータから、格納された薬剤ライブラリに関連する情報を複数の薬物投与デバイスに送信することを含む、方法。
- 74複数の薬物投与デバイスに送信される情報は、タグ付きである、請求項73に記載の方法。
- 75各薬物投与デバイスは、情報の諸部分を選択的に利用するように、タグを使用する、請求項74に記載の方法。
- 76各薬物投与デバイスは、情報の諸部分を選択的に利用するべく、情報を解析するのにタグを使用する、請求項74に記載の方法。
- 77送信された情報は、薬剤ライブラリ全体を含む、請求項74に記載の方法。
- 78送信された情報は、薬剤ライブラリのサブセットだけを含む、請求項74に記載の方法。
- 79薬剤ライブラリは、複数の薬物投与デバイスに同時にダウンロードされる、請求項73に記載の方法。
- 80薬剤ライブラリがダウンロードされる間に、複数の薬物投与デバイスに送信されるメッセージは、タグ付きである、請求項79に記載の方法。
- 81薬物投与デバイスの1つが、ダウンロードエラーを報告した場合、薬剤ライブラリダウンロードを停止し、後に、薬剤ライブラリダウンロードを続けることをさらに含む、請求項80に記載の方法。
- 82薬剤ライブラリダウンロードは、2回目、タグ付きメッセージの少なくとも一部をダウンロードすることなしに、続けられる、請求項81に記載の方法。
- 83薬剤ライブラリダウンロードは、いずれの薬物投与デバイスも、ダウンロードエラーを報告していなかった時点から続けられる、請求項82に記載の方法。
- 84薬物投与デバイスは、輸液ポンプである、請求項83に記載の方法。
- 85複数の異なるタイプの薬物投与デバイスと通信する方法であって、 ホストコンピュータを提供すること、 第1のタイプの薬物投与デバイスを提供すること、 第2のタイプの薬物投与デバイスを提供すること、 複数の薬物投与デバイスの動作に関連するデータをホストコンピュータ上に格納すること、および 薬物投与デバイスと通信することを含み、ホストコンピュータと薬物投与デバイスの間の通信は、拡張マークアップ言語(XML)を使用してフォーマットされたメッセージを使用する、方法。
- 86第1のタイプの薬物投与デバイスは、第2のタイプの薬物投与デバイスによって使用されるコンピュータアーキテクチャとは異なるコンピュータアーキテクチャを使用する、請求項85に記載の方法。
- 87第1のタイプの薬物投与デバイスは、第1のタイプのコンピュータプロセッサを使用し、第2のタイプの薬物投与デバイスは、第2のタイプのコンピュータプロセッサを使用する、請求項85に記載の方法。
- 88第1のタイプの薬物投与デバイスは、第2のタイプの薬物投与デバイス上で実行されるソフトウェアとは異なるソフトウェアを実行する、請求項85に記載の方法。
- 89第1のタイプの薬物投与デバイスは、第2のタイプの薬物投与デバイスによって使用されるバイナリフォーマットと互換性のないバイナリデータフォーマットを使用する、請求項85に記載の方法。
- 90前記メッセージは、ホストコンピュータと薬物投与デバイスの間の通信が正規形式に変換される際に使用される、請求項85に記載の方法。
- 91ホストコンピュータと薬物投与デバイスの間の通信は、無線である、請求項85に記載の方法。
- 92ホストコンピュータ上にデータを格納することは、ホストコンピュータ上に薬剤ライブラリを格納することをさらに含む、請求項85に記載の方法。
- 93同一の格納された薬剤ライブラリが、複数の薬物投与デバイスにダウンロードされる、請求項92に記載の方法。
- 94同一の格納された薬剤ライブラリが、少なくともいくつかは、異なるタイプの薬物投与デバイスである複数の薬物投与デバイスにダウンロードされる、請求項92に記載の方法。
- 95格納された薬剤ライブラリの少なくとも一部分が、複数の薬物投与デバイスにダウンロードされる、請求項92に記載の方法。
- 96薬物投与デバイスを制御する方法であって、 デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための1つまたは複数の格納ロケーションとを有する薬物投与デバイスを提供すること、 第1の薬剤のパラメータの第1の上限値および第1の下限値を定義する第1の限度セットを格納すること、および 第1の薬剤のパラメータの第2の上限値および第2の下限値を定義する第2の限度セットを格納することを含む、方法。
- 97薬物投与デバイスが、薬剤を投与するのに使用される際、パラメータの第1の限度セットおよび第2の限度セットをパラメータの実際の値と比較する請求項96に記載の方法。
- 98パラメータの値が、第1の限度、または第2の限度の範囲内にない場合、警告を表示することをさらに含む、請求項97に記載の方法。
- 99第1の限度セットは、第2の限度セットの範囲内に入る、請求項97に記載の方法。
- 100パラメータの値が、第2の限度の範囲外にある場合、薬物投与デバイスは、所与の薬剤を投与することを許されない、請求項98に記載の方法。
- 101第2の限度セットは、権限が付与された個人によってオーバライドされることが可能である、請求項100に記載の方法。
- 102第2の限度セットがオーバライドされた回数の記録をとることをさらに含む、請求項101に記載の方法。
- 103第2の限度セットに関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項102に記載の方法。
- 104パラメータの値が、第1の限度の範囲外であり、かつ、パラメータの値が、第2の限度の範囲内であった場合、薬物投与デバイスは、所与の薬剤を投与することを許されない、請求項97に記載の方法。
- 105第1の第2の限度セットは、権限が付与された個人によってオーバライドされることが可能である請求項104に記載の方法。
- 106第2の限度セットがオーバライドされた回数の記録をとることをさらに含む、請求項105に記載の方法。
- 107第2の限度セットに関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項105に記載の方法。
- 108第1の限度セットは、ソフト限度であり、第2の限度セットは、ハード限度である、請求項96に記載の方法。
- 109各薬剤は、病院における異なる臨床看護領域に関して、異なるハード限度、および異なるソフト限度を有することが可能である、請求項108に記載の方法。
- 110薬剤のパラメータは、投与速度(dosage rate)に関連する、請求項96に記載の方法。
- 111薬剤のパラメータは、薬用量(dose)に関連する、請求項96に記載の方法。
- 112薬剤のパラメータは、投与(dosage)量に関連する、請求項96に記載の方法。
- 113薬剤のパラメータは、薬剤量に関連する、請求項96に記載の方法。
- 114薬剤のパラメータは、希釈液量に関連する、請求項96に記載の方法。
- 115薬剤のパラメータは、投薬速度に関連する、請求項96に記載の方法。
- 116薬剤のパラメータは、薬剤送達時間に関連する、請求項96に記載の方法。
- 117薬剤のパラメータは、薬剤濃度に関連する、請求項96に記載の方法。
- 118薬剤のパラメータは、患者の体重に関連する、請求項96に記載の方法。
- 119薬剤のパラメータは、患者の体表面積に関連する、請求項96に記載の方法。
- 120薬物投与デバイスは、輸液ポンプである、請求項96に記載の方法。
- 121薬剤のパラメータは、輸液されるべき量(VTBI)に関連する、請求項96に記載の方法。
- 122患者に1つまたは複数の薬物を投与するための装置であって、 コントローラと、 コントローラに電気的に結合された1つまたは複数の格納ロケーションと、 装置の動作を制御するための、1つまたは複数の格納ロケーションに格納された制御情報とを含み、制御情報は、動作パラメータの値の第1の範囲を定義するソフト限度セットと、動作パラメータの値の第2の範囲を定義するハード限度セットとを含む、装置。
- 123ソフト限度セットは、ハード限度の範囲内に入る、請求項122に記載の装置。
- 124コントローラは、動作パラメータの値をハード限度およびソフト限度と比較する、請求項122に記載の装置。
- 125コントローラは、動作パラメータの値が、ハード限度およびソフト限度の範囲内にない場合、メッセージを表示する、請求項122に記載の装置。
- 126コントローラは、動作パラメータが、ハード限度の範囲を外れた場合、ユーザが、患者に薬物を投与するのを防止する、請求項122に記載の装置。
- 127ハード限度は、権限が付与された個人によってオーバライドされることが可能である、請求項126に記載の装置。
- 128ハード限度がオーバライドされた回数は、コントローラによって記録をとられる、請求項127に記載の装置。
- 129ハード限度に関連する情報、および記録をとられた情報を含むレポートが生成される、請求項128に記載の装置。
- 130コントローラは、動作パラメータの値が、ハード限度の範囲内にあるが、ソフト限度の範囲外にある場合、メッセージを表示する、請求項125に記載の装置。
- 131コントローラは、動作パラメータの値が、ハード限度の範囲内にあるが、ソフト限度の範囲外にある場合、ソフト限度をオーバライドすることを確認するよう、ユーザに要求する、請求項125に記載の装置。
- 132コントローラは、ソフト限度がオーバライドされた回数の記録をとる、請求項131に記載の装置。
- 133ソフト限度に関連する情報、および記録をとられた情報を含むレポートを生成することをさらに含む、請求項132に記載の装置。
- 134動作パラメータは、薬剤投与速度に関連する、請求項122に記載の装置。
- 135動作パラメータは、薬剤送達時間に関連する、請求項122に記載の装置。
- 136動作パラメータは、薬剤濃度に関連する、請求項122に記載の装置。
- 137動作パラメータは、患者の体重に関連する、請求項122に記載の装置。
- 138動作パラメータは、輸液されるべき薬剤量に関連する、請求項122に記載の装置。
- 139装置は、輸液ポンプである、請求項122に記載の装置。
- 140薬物投与デバイスを制御する方法であって、 デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための1つまたは複数の格納ロケーションとを有する薬物投与デバイスを提供すること、 第1の薬剤のパラメータの第1の上限値および第1の下限値を定義する第1の限度セットを格納する能力を提供すること、および 第1の薬剤のパラメータの第2の上限値および第2の下限値を定義する第2の限度セットを格納する能力を提供することを含む、方法。
- 141第1の限度セットおよび第2の限度セットの1つまたは複数の中の値を選択的に格納することをさらに含む、請求項140に記載の方法。
- 142上限および下限の第1のセットおよび第2のセットを格納することにより、ハード上限およびソフト上限、およびハード下限およびソフト下限を作成することをさらに含む、請求項140に記載の方法。
- 143第1の上限セットおよび第2の上限セットを格納することにより、ハード上限およびソフト上限だけを作成することをさらに含む、請求項140に記載の方法。
- 144第1の下限セットおよび第2の下限セットを格納することにより、ハード下限およびソフト下限だけを作成することをさらに含む、請求項140に記載の方法。
- 145ハード上限、ハード下限、ソフト上限、および/またはソフト下限の組み合わせを選択的に作成することをさらに含む、請求項140に記載の方法。
- 146ハード上限、ハード下限、ソフト上限、ソフト下限の1つまたは複数の限度の組み合わせを使用して、限度セットを作成することをさらに含む、請求項140に記載の方法。
- 147薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、 ホストコンピュータを提供すること、 ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、 ワークシートを構成すること、および ワークシートを1つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
- 148カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項147に記載の方法。
- 149医療デバイスパラメータは、薬剤ライブラリを含む、請求項147に記載の方法。
- 150ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項147に記載の方法。
- 151ワークシートを構成することは、ハード限度およびソフト限度をセットアップすることを含む、請求項147に記載の方法。
- 152ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項147に記載の方法。
- 153データをワークシートに入力することをさらに含む、請求項147に記載の方法。
- 154ユーザによって入力されるデータは、リアルタイムで検証される、請求項153に記載の方法。
- 155データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項154に記載の方法。
- 156薬剤ライブラリが、ホストコンピュータから第2のコンピュータにエクスポートされる、請求項147に記載の方法。
- 157薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項156に記載の方法。
- 158薬剤ライブラリが、第2のコンピュータからホストコンピュータにインポートされる、請求項147に記載の方法。
- 159ワークシートの構成中にワークシートの少なくとも一部分を表示することをさらに含む、請求項147に記載の方法。
- 160基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示することをさらに含む、請求項147に記載の方法。
- 161ワークシートを構成することは、薬剤処方集を編集することを含む、請求項147に記載の方法。
- 162基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項161に記載の方法。
- 163ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項147に記載の方法。
- 164規則セットは、薬剤濃度および投与量に関連する規則を含む、請求項163に記載の方法。
- 165規則セットは、薬剤送達限度を定義する規則を含む、請求項163に記載の方法。
- 166規則セットは、薬物投与デバイスレベル規則を含む、請求項163に記載の方法。
- 167デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項166に記載の方法。
- 168規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項163に記載の方法。
- 169規則セットは、一部の患者に固有の患者レベル規則を含む、請求項163に記載の方法。
- 170薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、 ホストコンピュータを提供すること、 医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、 ワークシートにデータを入力することによってワークシートを構成すること、 入力されるデータをリアルタイムで検証すること、および ワークシートを1つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
- 171カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項170に記載の方法。
- 172医療デバイスパラメータは、薬剤ライブラリを含む、請求項170に記載の方法。
- 173ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項170に記載の方法。
- 174ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項170に記載の方法。
- 175データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項170に記載の方法。
- 176薬剤ライブラリが、ホストコンピュータから第2のコンピュータにエクスポートされる、請求項170に記載の方法。
- 177薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項176に記載の方法。
- 178薬剤ライブラリが、第2のコンピュータからホストコンピュータにインポートされる、請求項170に記載の方法。
- 179ワークシートの構成中にワークシートの少なくとも一部分を表示することをさらに含む、請求項170に記載の方法。
- 180基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示することをさらに含む、請求項179に記載の方法。
- 181ワークシートを構成することは、薬剤処方集を編集することを含む、請求項170に記載の方法。
- 182基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項181に記載の方法。
- 183ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項170に記載の方法。
- 184規則セットは、薬剤濃度および投与量に関連する、請求項183に記載の方法。
- 185規則セットは、薬剤送達限度を定義する規則を含む、請求項183に記載の方法。
- 186規則セットは、薬物投与デバイスレベル規則を含む、請求項183に記載の方法。
- 187デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項186に記載の方法。
- 188規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項183に記載の方法。
- 189規則セットは、一部の患者に固有の患者レベル規則を含む、請求項183に記載の方法。
- 190薬物投与デバイスによって使用されるための薬剤ライブラリを構成する方法であって、 ホストコンピュータを提供すること、 医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートを提供すること、 ワークシートを構成すること、 ワークシートの構成中にワークシートの少なくとも一部分を表示すること、 基準ワークシートを、構成中のワークシートと同一のスクリーン上で表示すること、および ワークシートを1つまたは複数の薬物投与デバイスにダウンロードすることを含む、方法。
- 191カスタマイズ可能なワークシートは、複数のワークシートから選択される、請求項190に記載の方法。
- 192医療デバイスパラメータは、薬剤ライブラリを含む、請求項190に記載の方法。
- 193ワークシートは、選択された臨床看護領域に基づいて構成されることが可能である、請求項190に記載の方法。
- 194ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度をセットアップすることを可能にする、請求項190に記載の方法。
- 195データをワークシートに入力することをさらに含む、請求項190に記載の方法。
- 196ユーザによって入力されるデータは、リアルタイムで検証される、請求項195に記載の方法。
- 197データは、データ入力を検証するためのインプリメンテーションを定義する制約オブジェクトを使用して検証される、請求項196に記載の方法。
- 198薬剤ライブラリが、ホストコンピュータから第2のコンピュータにエクスポートされる、請求項190に記載の方法。
- 199薬剤ライブラリは、バイナリフォーマットを使用してエクスポートされる、請求項198に記載の方法。
- 200薬剤ライブラリが、第2のコンピュータからホストコンピュータにインポートされる、請求項190に記載の方法。
- 201ワークシートを構成することは、薬剤処方集を編集することを含む、請求項190に記載の方法。
- 202基準処方集も表示しながら、編集されている薬剤処方集を示す分割スクリーン表示を提供することをさらに含む、請求項201に記載の方法。
- 203ワークシートを構成することは、薬剤ライブラリの中の個々の薬剤を支配する規則セットを定義することを含む、請求項190に記載の方法。
- 204規則セットは、薬剤濃度および投与量に関連する規則を含む、請求項203に記載の方法。
- 205規則セットは、薬剤送達限度を定義する規則を含む、請求項203に記載の方法。
- 206規則セットは、薬物投与デバイスレベル規則を含む、請求項203に記載の方法。
- 207デバイスレベル規則は、一部の薬物投与デバイスの能力または限度に関連する、請求項206に記載の方法。
- 208規則セットは、一部の臨床看護領域に固有の臨床看護領域レベル規則を含む、請求項203に記載の方法。
- 209規則セットは、一部の患者に固有の患者レベル規則を含む、請求項203に記載の方法。
- 2101名または複数名の患者に薬物を投与する方法であって、 ホストコンピュータを提供すること、 薬物投与デバイスの動作を制御するためのコントローラと、デバイスの動作に関連する情報を格納するための1つまたは複数の格納ロケーションとをそれぞれが有する複数の薬物投与デバイスを提供すること、 ホストコンピュータと複数の薬物投与デバイスの間で通信リンクを提供すること、 ホストコンピュータと薬物投与デバイスの間で情報を交換すること、および 複数の薬物投与デバイスの動作に関連する1つまたは複数のレポートを生成することを含む、方法。
- 211複数の薬物投与デバイスは、イベントログをホストコンピュータに送信し、1つまたは複数の生成されたレポートは、薬物投与デバイスの少なくとも1つからのイベントログ情報を含む、請求項210に記載の方法。
- 212生成されたレポートは、複数の薬物投与デバイスからのイベントログに関連する統計データを含む、請求項211に記載の方法。
- 213複数の薬物投与デバイスは、デバイスパラメータ限度のユーザオーバライドに関連するオーバライドデータをログ記録する、請求項211に記載の方法。
- 214複数の薬物投与デバイスは、オーバライドデータログをホストコンピュータに送信し、レポートは、オーバライドデータログに基づいて生成される、請求項213に記載の方法。
- 215生成されたレポートは、ユーザが、デバイスパラメータ限度をオーバライドした回数を示す、請求項214に記載の方法。
- 216生成されたレポートは、ユーザが、デバイスパラメータ限度をオーバライドすることを断った回数を示す、請求項214に記載の方法。
- 2171つまたは複数のレポートは、薬物投与デバイス群の1つまたは複数のデバイスの動作に関連する情報を含む、請求項210に記載の方法。
- 218複数の薬物投与デバイスからの交換された情報を格納して、デバイス情報のデータベースを構築することをさらに含む、請求項210に記載の方法。
- 219所与の薬物投与デバイスセットによって投与された薬剤に関連する統計を含むレポートを生成することをさらに含む、請求項218に記載の方法。
- 220通信リンクは、有線ネットワークである、請求項210に記載の方法。
- 221通信リンクは、無線ネットワークである、請求項210に記載の方法。
- 222ホストコンピュータ、および複数の薬物投与デバイスは、拡張マークアップ言語(XML)を使用してメッセージをフォーマットする、請求項210に記載の方法。
- 223薬物投与デバイスは、輸液ポンプである、請求項210に記載の方法。
- 224医療デバイスパラメータを格納するためのメモリを有するホストコンピュータと、 ホストコンピュータと医療デバイスの間でデータを転送するためにホストコンピュータと医療デバイスとの間で形成された電気接続と、 ホストコンピュータのメモリにインポートするため、および医療デバイスにダウンロードするための、コンピュータ可読媒体上の医療デバイスパラメータのユーザによるカスタマイズが可能なワークシートとを含む、医療デバイスシステム。
- 225医療デバイスを収容するための筐体をさらに含み、ホストコンピュータと医療デバイスの間の電気接続は、筐体内部のスロットの中に配置されたプラグアンドプレイモジュールを含む、請求項224に記載の医療デバイスシステム。
- 226医療デバイスは、プラグアンドプレイモジュールを受けるための筐体内部に形成されたスロットと、プラグアンドプレイモジュールを受けるための筐体内部のプラグとを備えた筐体を有する、請求項224に記載の医療デバイスシステム。
- 227医療デバイスを収容するための筐体をさらに含み、ホストコンピュータと医療デバイスの間の電気接続は、筐体内部に完全に密閉された接続エンジンを含み、ホストコンピュータと医療デバイスの間の電気接続が、無線であるようにしている、請求項224に記載の医療デバイスシステム。
- 228ホストコンピュータ間の電気接続は、データケーブルを含む、請求項224に記載の医療デバイスシステム。
- 229ユーザによるカスタマイズが可能なワークシートは、ユーザが、ハード限度およびソフト限度を確立することを可能にする、請求項224に記載の医療デバイスシステム。
- 230ホストコンピュータと医療デバイスの間の電気接続は、無線である、請求項224に記載の医療デバイスシステム。
- 231ホストコンピュータと通信するための2つのアンテナをさらに含む、請求項230に記載の医療デバイスシステム。
- 232医療デバイス情報を格納するための記憶媒体を含むコンピュータ上で実行されるプログラムを格納するコンピュータ可読媒体であって、 医療デバイス情報は、デバイスパラメータを含む、前記デバイスパラメータでプログラマブル医療デバイスを、選択された臨床看護領域に基づいて構成するためのワークシートを含み、前記プログラムは、コンピュータに、 前記コンピュータのユーザが、ワークシートを選択することができるようにする機能と、 ユーザが、ハード限度とソフト限度の両方でワークシートをカスタマイズして、選択された臨床領域に基づく、ユーザによって策定されたデバイスパラメータを満たすようにすることができるようにする機能と、 ユーザが、ワークシートの一部分を医療デバイスに電子的にダウンロードすることができるようにする機能とを実行させる、媒体。
Independent claims232
90 paragraphs, as filed
The present invention generally relates to a drug administration device or a drug delivery device. More specifically, the present invention provides drug information or communication between a computer and one or more infusion pumps to retain drug information, and guarantees the integrity of such information and communication. Regarding a new system for.
Intravenous infusion therapy is prescribed when it is desirable to administer the drug and other fluids directly into the patient's circulatory system. If there was no warning to the clinician that the clinical practice was programmed with a higher or lower dose than intended, the amount of result delivered to the patient would increase the morbidity. Can bring or be fatal. Medical staff to infuse medicated fluids into the patient's body There are various types of infusion pumps used by personnel). Few pumps have the function of drug dose programming alerts. Some pumps use a customized drug library for electronically downloadable drug pumps. For example, US Pat. No. 6,269,340, which is incorporated herein by reference in its entirety, develops a customized drug library from a personal computer (PC), an erasable, electronic inside the enclosure of an injection pump. Describes system and computer readable media for downloading into readable memory. However, prior art systems and infusion pumps have some drawbacks. The following is a description of a novel infusion pump system that solves various problems found in the prior art.
<p><patcit num="1"><text>U.S. Pat. No. 6,269,340</text></patcit></p>
<p num="0004"> The present invention relates to a system for communicating with one or more drug administration devices or drug delivery devices. More specifically, the present invention utilizes remote computers, as well as software programs on computer-readable media, to inform one or more infusion pumps on a stand-alone basis or as part of an integrated drug management system. And / or uploading information from one or more infusion pumps.</p>
<p num="0005"> In one example, the software can be used by users, including, but not limited to, biotechnologists, pharmacists, doctors, and others, with powerful drug library creation, drug library editing, and drug libraries. Provides archiving capabilities to remote computers. A single drug prescription collection worksheet or drug prescription collection database, where each drug entry has an associated CCA designation, can be created for the entire medical facility. It is possible that the same drug has different limits established in different clinical nursing areas, with different device parameters, and different devices, depending on the best recommended practices of the medical facility for a particular clinical nursing area. The setting value may be applied. A single drug prescription collection worksheet is easier to manage, update, and maintain than a separate database or sub-database for each clinical nursing area. In one example of the software, the software provides a real-time rule set validator that dynamically validates the input to the drug prescription collection worksheet with each key input as the user keys the data. The user will be notified immediately if the value exceeds an acceptable range or if the data does not meet certain expected characteristics. In one example, the software also uses an extended markup language to communicate with the drug delivery device. Communication between the computer and the device can be verified using any desired technique, such as cyclic redundancy check. In another example, a database is used to store the history of multiple infusion pumps. This allows the ability to retrieve event log data from all pumps in one institution within a database, and retrieve data based on location of use, time of day, type of error, etc. Other types of reports are also possible.</p><p num="0006"> The software, in one example, utilizes a computer to download information to one or more drug delivery devices (such as an infusion pump) and from one or more drug delivery devices (such as an infusion pump). Useful as part of the uploading system. In one embodiment, the system includes a remote personal computer (PC) having a memory for storing software, a user interface, and a display. The system also includes one or more infusion pumps, as well as one or more techniques for connecting a PC to the pump to facilitate communication of information between the PC and the pump. The infusion pump can have a single channel for delivering the drug (ie, liquid, drug, or mixture thereof) to the patient, or it can have multiple channels. In one example, the information downloaded to the pump is not limited, but one or more drug entries are usually grouped by clinical nursing area drug library, drug delivery parameters (hard and soft limits). , Device settings, device parameters, or device limits, patient-specific information such as patient identification data, and nurse-specific information such as caregiver identification.</p><p num="0007"> In one example, software and communication protocols utilize open architectures that are applicable to different versions, different models, and different types of drug delivery devices. In one embodiment of the invention, the software is used in a system that establishes wired communication with multiple general purpose infusion pumps to download and upload information. In other embodiments, the software is one or more general purpose infusion pumps with a plug and play communication module installed inside the pump housing for downloading and uploading information. Used in systems that establish wireless communication with. In other embodiments, the Plug and Play communication module is integrated and integrated onto an optional circuit board sealed inside the pump housing. Examples of drug delivery devices include single-channel or multi-channel general purpose infusion pumps, patient controlled analgesia. Included, but not limited to, analgesia (PCA) pumps, ambulatory pumps, enteral pumps, IV infusion pumps, and more.</p><p num="0008"> The software is also useful on computers that interface with or act as such units or servers. In that example, the software facilitates communication between the PC and one or more drug delivery devices within the patient area network (PAN). An example of the purpose for which communication between a PC and a device can be used is to download patient-specific drug delivery instructions to operate and control the drug delivery device. , As well as uploading information such as device characteristics, conditions, usage history, and alert history, but not limited to.</p><p num="0009"> The present invention is shown, by way of example, in the figure of the accompanying drawings, where similar reference numerals indicate similar elements, but not as a limitation.</p>
<figref num="1A">It is a front view of the infusion pump by this invention.</figref><figref num="1B">It is a rear view of the infusion pump of FIG.</figref><figref num="1C">FIG. 1 is a rear perspective view of the infusion pump of FIG. 1 showing a plug-and-play module that facilitates communication between the pump and a computer.</figref><figref num="1D">FIG. 5 is a front perspective view showing a possible embodiment of a CD-ROM disc or a computer-readable medium according to the present invention.</figref><figref num="1E">A perspective view of a data cable that can be used to allow multiple pumps to communicate with a computer via a connection to a junction box.</figref><figref num="1F">FIG. 3 is a perspective view of a dual jacked junction box cable for connecting a Plug and Play module to a computer and connecting it to other pumps.</figref><figref num="1G">It is a perspective view of a data cable for connecting a computer to one of the dual jacks on the junction box.</figref><figref num="2">It is a figure which shows how this invention can be used.</figref><figref num="3">It is a figure which shows an example of the process for customizing a library.</figref><figref num="4A">It is a figure which shows the communication between a PC and an infusion pump.</figref><figref num="4B">It is a flow chart which shows the process of editing and downloading a drug library.</figref><figref num="5">It is a rear view which shows the connection of a plurality of pumps to a computer.</figref><figref num="6">It is a figure which shows the example of the worksheet which the pharmacist sees on the computer equipped with this invention.</figref><figref num="7A">It is a figure which shows the example of a soft limit override report.</figref><figref num="7B">It is a table explaining the report of FIG.</figref><figref num="7C">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="7D">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="7E">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="7F">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="8A">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="8B">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="8C">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="8D">It is a figure which shows the example of the soft limit override report and the hard limit override report about a different drug.</figref><figref num="9">It is a block diagram of an exemplary connection that can be used in the present invention.</figref><figref num="10">It is a block diagram of an exemplary connection that can be used in the present invention.</figref><figref num="11">It is a block diagram of an exemplary connection that can be used in the present invention.</figref><figref num="12A">It is a block diagram which shows an example of the electronic system for use in this invention.</figref><figref num="12B">It is a block diagram which shows an example of the electronic system for use in this invention.</figref><figref num="12C">It is a block diagram which shows an example of the electronic system for use in this invention.</figref><figref num="12D">It is a block diagram which shows an example of the electronic system for use in this invention.</figref><figref num="13">It is a block diagram which shows an example of the electronic system for use in this invention.</figref><figref num="14">It is a block diagram which shows an example of the electronic system for use in this invention.</figref><figref num="15A">FIG. 5 is an example of a dialog box used when editing a rule set for a drug.</figref><figref num="15B">A table showing valid input ranges for various fields or values in the Rule Set Editor of the present invention.</figref><figref num="16">It is a figure which shows an example of the rule set validator judgment tree.</figref><figref num="17A">FIG. 5 is a block diagram showing a patient self-managed analgesic pump having a wireless connection engine or wireless communication engine according to the present invention.</figref><figref num="17B">FIG. 5 is a block diagram showing a patient self-managed analgesic pump having a wireless connection engine or wireless communication engine according to the present invention.</figref><figref num="17C">FIG. 5 is a block diagram showing a patient self-managed analgesic pump having a wireless connection engine or wireless communication engine according to the present invention.</figref><figref num="18">FIG. 5 is a block diagram showing a patient self-managed analgesic pump having a wireless connection engine or wireless communication engine according to the present invention.</figref><figref num="19">FIG. 5 is a block diagram showing a patient self-managed analgesic pump having a wireless connection engine or wireless communication engine according to the present invention.</figref><figref num="20A">It is a figure which shows an example of the XML exchange schema.</figref><figref num="20B">It is a table which shows the XML object tag name used in the example of this invention.</figref><figref num="21">An example of a dialog box used in the Rule Set Editor when adding, editing, deleting, or browsing rule sets.</figref><figref num="22">It is a block diagram which shows the relationship between DataModel and DataItem.</figref><figref num="23">It is a figure which shows the high level dialogue between various processes of this invention.</figref><figref num="24A">It is a figure which shows the high level dialogue between various processes of this invention.</figref><figref num="24B">It is a figure which shows the high level dialogue between various processes of this invention.</figref><figref num="25">It is a figure which shows the high level dialogue between various processes of this invention.</figref><figref num="26">It is a figure which shows the data model which supports a soft limit alarm event or an override clinical event.</figref>
In general, the present invention provides systems and methods for providing communication between a computer and one or more drug administration devices. The present invention uses hardware and software to provide a link between a computer and an infusion pump. In one example, the invention is in a pharmacy environment or a biomedical technology service environment, or in its entirety is expressly incorporated herein, filed on December 5, 2003, under the name "MEDICATION MANAGEMENT SYSTEM". As used in the Drug Management Unit (MMU) as described in Applicant's Simultaneous Pending Provisional Application No. 60/527583 and the conventional patent application of the same name filed on February 20, 2004. Designed to.
The present invention provides a drug library for use by a facility in an infusion pump such as a PLUM A +® infuser or pump, available from Abbott Laboratories, located in Abbott Park, Illinois. Allows customization. Other types of pumps can also be used in the present invention. For example, the invention can be used in patient-controlled analgesia (PCA) pumps, gait pumps, enteral pumps, and IV infusion pumps. The invention also allows the storage of data from multiple pumps and produces various safety reports, event and alert reports.
FIG. 1A is a front view of the Abbott PLUM A +® infuser or pump 12. FIG. 1B comprises a vertically elongated slot 3 formed inside the housing 2 to receive a plug-and-play module 4 that facilitates communication between the computer and the infusion pump. It is a rear view of the PLUM A + (registered trademark) pump of FIG. 1A which has been changed to. The Plug and Play module 4 is arranged so as to be operable inside the housing 2, and is substantially surrounded, protected, and isolated by the housing. The Plug and Play module 4 has a thin, elongated card-shaped case that fits into slot 3 of the pump housing 2. Therefore, the plug-and-play module 4 of the present invention hardly increases the space occupied by the pump. The plug-and-play module 4 shown in FIGS. 1A and 1B is configured for hardwired communication. However, as described below, the Plug and Play module 4 can also be configured for wireless communication.
In one example, the software of the invention can store up to 12 clinical nursing areas (CCAs), with up to 100 drug entries (99 drug entries, and No Drug Selected) stored within each CCA. , A total of 1200 entries are stored in the master drug prescription collection. In that example, the software of the invention supports data transfer of up to 15 Abbott PLUM A +® single channel infusers connected to a single computer. Of course, the invention can be designed with different storage and communication capabilities and can be configured for different pumps.
FIG. 2 is a diagram showing how the present invention can be used. As shown in FIG. 2, when the software is installed on the host computer (personal computer in this example, PC10), the user creates a drug library containing any desired set of rules (in this example, PC10). Alternatively, a library with software media can be used). The drug library can include entries containing drug name, drug amount, drug unit, diluent volume, diluent unit, dosing unit, drug class, hard limit, and soft limit within the hard limit range. The drug concentration does not need to be entered. This is because the value can be derived from the drug amount, drug unit, diluent volume, and diluent unit. The user can also create multiple CCA in the library. Next, the user can connect the PC to the plurality of infusers 12 and start data transfer between the PC and the infuser. For example, the active drug library can be downloaded from a PC to a connected infuser. In addition, the data can also be transferred from the infuser to the PC. For example, event logs and alarm logs can be uploaded to a PC from a connected infuser. Also, any other type of data or communication desired can also be transferred between the PC and the infuser.
FIG. 3 is a diagram showing an example of a process for customizing a library. The process of FIG. 3 begins with a user, such as a pharmacist, creating a worksheet on the PC10. In this example, the worksheet can still be edited and can be thought of as an unfinished library. One striking feature of this worksheet is that the worksheet provides two simultaneous views: a target "working" prescription collection view and a source "reference" prescription collection view. In one example, a master prescription collection view of a drug can be in the reference view while at the same time showing a view of the target drug for that CCA. Similarly, in another example, the target view could be one CCA such as "Medicinal", while the source could be another CCA such as "Surgery". .. The pharmacist can copy the exact same drug entry from the source to the target, along with the relevant set of rules. This presentation reduces the time it takes to develop all the required CCA, facilitates easy quality inspection for pharmacists, and facilitates a view across all drug rule sets that have been developed. In addition, typing errors are reduced when the same drug name, concentration, and rule set are forced to be re-entered into many different CCA's. Mistakes in developing a drug library can lead to lower safety nets for nurses and increased patient morbidity. FIG. 6 shows an example of a worksheet that a pharmacist (or other user) can view on a computer equipped with the present invention. FIG. 6 shows a split screen view in which the master drug prescription collection table is at the bottom 14 of the screen and the drug in the selected CCA is at the top 16 of the screen. The pull-down menu 18 is used to select which CCA is displayed at the top 16.
With reference to FIGS. 3 and 20A, the user is then a drug for use in a hospital area or patient population (eg, Intensive Care Unit (ICU)) as defined by an authorized user. Create a CCA that is a subset of the library (if no such CCA has already been created). Each CCA can have a predefined number of specific agents. Hospitals can also have multiple CCA in their drug library. The user then creates any desired drug class (eg, antibiotics, anesthetics, beta blockers, etc.) and then adds the drug entry to the CCA along with the rule set. Next, the CCA infuser set value is set. Examples of CCA infuser settings include maximum velocity, default occlusion pressure, maximum patient weight and / or minimum patient weight. Next, the master infuser setting is set up. Examples of master infuser settings include Continue Rate (the default rate at which the infuser switches after therapy is complete), Enable. Delay / Standby (default standby setting), Callback Notification (when enabled, between stages during multistage infusion, or after loading the dose, the infuser 12 issues an audible nurse callback alarm. Notifications will be displayed), and Delay Together (which allows you to choose a two-channel delivery method by default). The worksheet report can be printed and inspected before the worksheet is completed. Finally, the worksheet is completed as an active library.
After the active library is ready, the technician can connect one or more infusers 12 to the PC 10 for data transfer. 4A and 5 are diagrams showing communication between the PC 10 and the infuser 12. First, the active library is imported. Next, the engineer connects the infuser 12 to the PC 10. The infuser 12 can be connected to the PC 10 in any desired form. For example, a cable (FIG. 1F) can be connected between the serial port on the PC 10 and the junction box (FIG. 1E), the junction box via the plug and play module 4 (FIG. 1A). , Also connected to the data port of each infuser 12. The infuser 12 and PC 10 can use any desired type of interface, including serial interfaces (RS232, USB, etc.), parallel interfaces, etc. In another example, the infuser 12 can have the radio capability to provide a connection to the PC 10 as needed. Once connected, information including, but not limited to, programming events, settings, alarms, etc. can be uploaded to the PC as historical information (logs) or real-time information, and is an active library. Can be downloaded to all of the infuser 12. FIG. 5 is a diagram showing the connection of a plurality of pumps to a computer using a serial cable having a plurality of serial connectors and a plurality of junction boxes.
FIG. 4B is another flow diagram showing the process described above. As illustrated, hospital prescription collections can be imported into one or more worksheets. After the user completes the drug library, the active drug library can be downloaded to one or more infusers. FIG. 4B also shows that the drug library can be archived and used again in formulating or editing worksheets.
The present invention includes several features that solve various problems in the prior art. The following is a description of their features.
The present invention utilizes extended markup language (XML) representation for remote procedure call (RPC). One advantage of using XML is that the use of XML syntax documentation allows the protocol to support different types of products. For example, the first infuser may only allow one communication format, which is different from the format required by another infuser. By using XML, the system can communicate with different types of infusers. Examples of different types of devices include devices with different computer architectures, devices running different types of computer processors, and devices running different software programs (or different versions of the same program). In addition, some devices operate with binary data formats that may not be compatible with the binary formats used on other devices. In this way, the host computer can use the same message format for a variety of different types of devices. The present invention also provides the use of an XML parser when communicating with a medical device connected to a patient, such as an infusion pump.
In some application examples of the present invention, the host and pump may have incompatible binary data formats. For that reason, it is necessary to define the same lexical form on the host and on the pump. The common vocabulary expression is called the canonical form. The process of converting a process-specific binary format to a canonical format is called normalization.
Error checking generally uses a checksum function or a hash function. However, these functions are not always reliable. Since the present invention uses medically critical data, it is important to use more reliable error checking functions. Furthermore, it is desirable to allow partial library updates (such as individual items in the drug library) while it is still possible to verify the contents of the entire library. The present invention uses a standard checksum or hash function to protect the state of the entire exchanged data structure, Global Cyclic Redundancy Check (Global Canonical C). Cyclic Redundancy. Check) (gCCRC) to supplement. The purpose of the gCCRC is to allow the host and pump to verify that their data are identical after the attempted data transmission. The gCCRC can detect lower levels of checksums and errors that are not otherwise caught. For example, gCCRC detects when the number of dropped packets is in the sequence number range itself. The gCCRC also provides final "backstop" verification for all types of protocol failures, including exceptions such as pump disconnects, power outages, and software defects.
In one example, a traditional technique that compares two binary images (an image on the host computer and an image on the infuser) to see if they are the same and to verify the content of the data stored in the infuser. Rather, a comparison is made to determine if the two completely different physical (bitwise) representations are semantically identical. This is achieved by using a regular expression (neither side is actually used for storage) and then making a comparison between the two abstract expressions. For example, to verify the content of the data in the infusion pump, the CRC is calculated based on the data in the pump. The CRC is then calculated based on what the host considers to be the data in the pump. Then those numbers are compared. If the numbers are the same, the data is very likely to be the same on the host and infuser. One advantage of this approach is that only small amounts of data are required to be transferred for comparison purposes. The binary image of the entire library does not have to be retransmitted for comparison. This approach also eliminates the requirement for error checking during data transmission.
Another aspect of the invention relates to how CRC is calculated. The form of CRC used is specified by the Commite Consultative Internationale de Telegraphique et Telephonique (CCIT). However, in the present invention, the CCIT CRC is performed in the reverse bit order (from right to left instead of left to right specified by CCIT) to make the calculation more efficient. Since Intel processors have "endianness" which is the opposite of the so-called "network byte order" defined by CCIT, bit inversion avoids implementation problems on some processors. become.
When constructing the aforementioned words (which can have different endianness) using a CRC, it is important to accurately define the syntax of the document or data before using the CRC. The present invention uses XML Schema for that purpose. In addition, XML Schema is used to define the semantics used for validation. The data to be validated (eg, drug library) is converted to canonical format (as described above), validated and verified using XML Schema, and the data is valid and in the correct format (well). It is determined whether or not it is formatted). In the library example, this validation check is done before the library is pumped.
An example of an XML schema of the present invention includes two main parts, an exchange schema, and an implied schema. In general, the exchange schema defines the structure of the data to be communicated between the host computer and the infusion pump. The implied schema defines (and validates) the types of data being exchanged.
FIG. 20A shows Unified Modeling. It is a figure which shows an example of the XML exchange schema using the Language (UML) notation. As shown in the example of FIG. 20A, the drug library includes an infuser setting, at least one drug entry, and an active library object. In this example, there is only one infuser set value object and one active library object, but there are up to 1200 drug entry objects. Each object shown in FIG. 20A contains the attributes described within its respective box. Active library objects include up to 12 CCA objects. Each CCA object contains up to 100 rule set objects. In this example, there is only one rule set per drug, but multiple drugs can share a single rule set. The data structures shown in FIG. 20A, and the members of those data structures, are defined as XML objects with tag names (optionally abbreviated / abbreviated) for each entry. FIG. 20B reveals the names used in the example. FIG. 20B shows the queries and responses, along with the commands, and their corresponding abbreviations. As shown, in addition to the data structure, commands and queries are also XML encoded and processed by the host computer (ie, server) side and pump (ie, client) side in the same way as the data. As will be apparent to those skilled in the art, commands and queries can be used with the present invention to efficiently provide communication between the host computer and the client infusion pump. For example, the following command terminates the drug library update while communicating the server's calculated global canonical checksum to the client (<xEU). gccrc = "9B8D" />). As shown in FIG. 20B, "xEU" is an abbreviation for the command "EndLibryUpdate", while the value "9B8D" is an example of a hexadecimal value for the server checksum. Other commands and queries are used in a similar fashion.
Implied data is a contract between the host computer 10 and the infusion pump 12. Implied data is managed by the host and used in developing software for the host and client. In one example, implied data is not transmitted over the communication link and the infuser software never processes the data. One purpose of the implied schema is to validate the values and types of data that can be sent to clients. One form of verification is a range check that limits the transmission of out-of-range values. Another form of verification can be display accuracy. For example, the display range of variables is 0.1 (tenths of). It is possible to be a digit). In such cases, sending a value of 12.00 is invalid because the value describes accuracy beyond the range of the variable. Another type of verification can be a unique test. The implicit schema takes the form of an XML Schema document. The XML Schema document provides type definitions for all client / host-specific type definitions in the exchange schema. The following are examples of various implied schema types. The first example is a simple string type schema that defines that the institution name string is 30 characters or less.<maths num="1"></maths>
XML Schema supports fixed-point representation directly through the fractionDigits facet on most numeric data types. The following example defines minimum and maximum decimal and decimal numbers.<maths num="2"></maths>
In one example, the present invention constructs implied enumeration by defining xs: enumeration restrictions on Encoded String.<maths num="3"></maths>
Multiple ranges for a single value can be specified for the value via <xs: choice>. The following examples relate to patient weight fields, including upper and lower limits.<maths num="4"></maths>
One problem with using XML is that it is very verbose, which increases bandwidth requirements. To reduce communication overhead, the invention is still standard compliant, but in a more compact form operating with significantly reduced bandwidth by shortening the XML identifier to some character mnemonic. Use XML. Coding is a well-formed XML that uses concise elements and attribute names. In one example, each XML Short Name consists only of letters and can be uniquely identified by the first letter. The command sends the argument as an XML attribute. The response returns the value as an attribute value and / or as an element nested within the response element. For example, the long XML name "InuserSetting" is abbreviated to "IS". Therefore, the exemplary command line is Example: Compact Pump Configuration instance<maths num="5"></maths>Is like Example: PumpConfiguration instance<maths num="6"></maths>Not a non-compact version like. In this example, the coding reduces about 200 characters to about 60 characters, resulting in a ratio of about 3.3: 1.
The present invention uses an extended data port protocol that includes a trusted binary transport protocol on top of the data port protocol. That is, the protocol runs on top of the data port protocol. One advantage of this approach is improved compatibility between different machines. Another advantage is that large messages can be segmented and reassembled. This allows very large messages to be sent through the protocol stack, even if the host or pump is unable to handle the large messages. Larger messages are segmented into smaller packets and later reassembled.
The present invention ensures the security of the database by allowing only one library, called the active library, to be downloaded to the pump and kept in the computer. This ensures that the wrong library is not downloaded over time. A library that can be edited is called a worksheet, and many different worksheets can exist. Libraries that were once active and are no longer active are archived and automatically designated as such. Unique special file extensions and recognitions have been developed to allow the active library to be transferred to another computer. This allows the transfer of the exact same library between pharmacies in larger medical facilities with multiple locations.
Another advantage of the present invention is that the system can download data to multiple infusion pumps at the same time. The library is transmitted to multiple pumps in the form of multicast. The system uses point-to-point communication to periodically verify the status of each pump. If one of the pumps has a problem, the download can be restarted and each pump will be notified of the new download. In one example, if a pump detects a download error during a broadcast download, the pump will send a message to the host computer, and the host will stop the download. The host then polls all of the pumps to determine when all of the pumps were receiving messages with valid data. Since the download spans multiple individual tagged messages, the tag number allows the host computer to identify when none of the pumps reported a download error. As the download continues, the download begins at that point and therefore all of the data does not have to be downloaded again. Multicast communication strategies optimize download throughput. For example, if the library takes 10 minutes to download, 15 pumps can receive the download in 10 minutes, compared to 150 minutes it takes to download individually to each pump. This mix of multicast and point-to-point communication facilitates robust downloads to individual pumps and retry / recovery mechanisms. Another advantage of the present invention is that the worksheet provides the pharmacist with a master prescription collection view while simultaneously providing a CCA view of the drug entry. Editing and copying drug entries can be done in any view. This presentation provides an easy quality test for pharmacists, safe as drug limit alerts or dose limit alerts are developed. All-sexual function is promoted. Mistakes in developing a drug library can lead to lower safety nets for nurses and increased patient morbidity.
Another advantage of the present invention is that a single database can be used to store the history of multiple infusion pumps. This allows the ability to retrieve event log data from all pumps in one institution within a database, and retrieve data based on location of use, time of day, type of error, etc. Other types of reports are also possible. Also, using a centralized database, the system can include multiple PCs, each of which can be downloaded to any desired pump.
Similarly, the invention can also collect pump usage data and generate relevant reports. For example, soft limit override data can be collected for the generation of reports related to soft limit override. That type of report can be used for any desired purpose, such as evaluating staff, setting future limits, and so on.
The present invention includes an active drug library editor capable of verifying drug data in real time. The present invention can manage an unlimited number of drug libraries. The drug library consists of a master drug prescription collection (the drug table from which the CCA is created) and a plurality of CCA. The library must be active (incomplete worksheet), archived (previously active library stored in the database), or worksheet (download to the infuser still approved). It is possible that it is a draft library that has not yet been edited). Only active libraries are allowed to be downloaded to the pump. Items such as configuration parameters that describe the operational behavior of the pump can be set throughout the pump or unique to the CCA. Those parameters are unique to each library. TallMan lettering is supported with respect to drug names. Changes to TallMan lettering are replicated throughout the library. Each drug in the library is associated with a drug classification. The drug classification is unique to each library. The drug can have multiple concentrations and multiple rule sets. The rule set can be complete, limited, or none.
Another feature of the invention relates to the various levels of rules available to active drug libraries. The present invention relates to device rules (eg, rules related to the behavior or limits of a particular medical device, or a particular type of device), CCA rules (eg, rules related to a particular CCA), drug rules (eg, a particular drug). Allows the use of multiple rule levels, including rules related to) and patient rules (eg, rules related to a particular patient, such as age, weight, health, medical history, allergies, etc.).
Rule Set The Editor (RSE) is used to create and edit the rule set in the drug database. The RSE is responsible for accurately displaying the rule set and enabling the "Add", "Save", or "Delete" buttons as appropriate. FIG. 21 shows an example of a dialog box used in the rule set editor when adding, editing, deleting, or browsing rule sets. As shown in FIG. 21, there are fields for drug name, drug class, drug amount, drug diluent, and soft / hard limit. The RSE is responsible for adjusting the input criteria and validating the rule set while the user makes input selections. The RSE uses the RuleSetDataItem (RSDI) (described below) as the data model and the RuleSetValidator (RSV) (described below) as the controller. The RSE sends a message to RSDI when the model should be validated. The RSDI sends a message to the RSV that validates the RSDI. This separation of responsibilities is established to encapsulate the standard validation implementation for both the ruleset editor user interface and the library import process.
Another advantage of the present invention relates to drug composition. The present invention includes a special set of rules that allows the definition of drug names and concentrations for a particular drug. However, in the pump, the user can disable the drug amount and drug unit. Therefore, limits are set, but the user is allowed to define the concentration. Accordingly, the present invention labels drugs having the ability of the user to selectively limit or allow the choice of delivery units per drug, as well as the concentration of drug units, but other units (ml /). Has the ability to deliver at time).
Another advantage of the present invention relates to constraint definitions. The present invention includes a set of unique constraint objects. Constraint objects define a standard implementation for validating keyboard, mouse, and import inputs. For example, a particular field can be constrained to a certain numeric range. Constraints prevent things from being done by mistake. However, sometimes one object input is based on the contents of another object, and in the present invention, the constraint definition changes dynamically as the input definition changes. For example, with respect to the object "drug amount", the constraints can vary depending on the unit of measurement (eg, grams, etc.).
The Dose Rate Document (DRD) aggregates multiple constraints so that input validation can be cascaded across an unlimited number of constraint objects. In an example of a DRD implementation, the object, DoseRateDocment, is described by javax. swing. text. Extends PlanDocment to implement the required method, insertSting (int offset, Sting string, AttributeSet attribute). This method can be used as appropriate in the StringConstraint. CheckImport (String promotedValue) is called internally.
Rule Set Constraint (RSC) provides specific DRDs for drug and diluent volumes, as well as hard and soft limits. RSCs are used to dynamically change their settings to validate inputs based on drug and dose units. The RSC aggregates some constraint objects to ensure that the entry is within scope. In one example, the drugAmount, diffuseAmount, and limits have their own DRD and Constraint objects, each of which is unique to meet the needs of the goal. When the RSC is constructed, it is initialized with a specified value. A continuous call to setDrugAmountConstraints (drugLabelPK) adjusts the dragAmountDRD. Similarly, a call to setDilentAmountConstraint () adjusts the diffuseAmountDRD. In one example of the invention, the only constraint is the diffuseAmount. Similarly, a continuous call to setLimitConstraints (dosingUnitPK) adjusts the limit.
The Rule Set Data Item (RSDI) is a specialized Data Item that acts as a data model. Getter / Setter is provided to acquire and set various forms of attributes required by RVDC (described below), RSE, and RSV (described below). DataItem knows how to add itself to the SQL Server database. In one example of the invention, RSV is implemented as a static object rather than as a private implementation of RSDI. This separation of responsibilities makes it easier to implement and maintain RSV.
The Rule Set Data Model (RSDM) is a specialized Abstrac Data Model that provides a virtual data store for all imported RSDI items.
Rate Versus Dose Certification (RVDC) calculates the delivery rate for a given dosage in the context of variables such as patient weight, drug concentration, and so on. In one example, RVDC is not tied to a particular infusion pump implementation. Also, in one example, the RVDC algorithm is purely algebraic. The RSDI possesses the data extracted by RSV and sent to the RVDC for which the DoseFromRate or calculateRateFromDose is calculated.
The Rule Set Validator (RSV) coordinates the validation process for all rule set data fields. RSV begins by resetting the constraints required by the drugAmount, diffuseAmount, and limits. RSV systematically verifies each field for compliance as follows: That is, The length must not be 0 or blank and must not exceed the maximum length. -The pixel length must not exceed the visible area on the pump. -Names are checked for invalid characters.
RSV is used to validate rule sets from different sources, including user-entered, imported libraries, drugs copied from one location to another, and adjusts to CCA maximum velocity settings. RSV is consistently and always used throughout the system to verify that the rule set is well-formed, valid, and does not violate service compliance for the entire library. If the user attempts to enter data that violates the rule, the Save button in the dialog box will be dimmed and disabled, allowing the user to modify the data that violates the rule. Is forced to. FIG. 15A is a diagram showing an example of a dialog box used when editing a rule set for a drug. In this example, the user edits whatever he wants and then clicks the "Save" button. If the entry is not valid, the Save button will be dimmed and the user will not be allowed to save the changes.
FIG. 16 shows an example of a rule set validator determination tree. The decision tree shown in FIG. 16 represents the basic logic used to evaluate the validity of rule set limits. In general, the decision tree asks if the rule set is "NONE", "FULL", or "LIMITED", then asks the other questions outlined in the decision tree to make the rule. Determine if the set is valid. FIG. 16 shows a dynamic check performed each time the user makes keyboard or mouse input while creating or editing a rule set. FIG. 16 also shows how RSV tests to see if such delivery rates / doses are acceptable based on dose limits. Other settings, such as the maximum velocity CCA infuser setting, can also be taken into account or analyzed in a similar manner.
Another feature of the present invention relates to the Data Model. The Data Model is used to import data into the drug library, copy from the source to the destination CCA library, and edit the CCA settings in the CCA library. The figure below shows the relationship between DragLibryManager (DLM) and RSDI, as well as a high level of dialogue. FIG. 22 shows the relationship between the Data Model and the Data Item. For brevity, CCASettings and CCALibry DataModels and DataItems are not shown in FIG. FIG. 23 is a diagram showing a high level of dialogue between the import process and the RuleSetDataItem. As mentioned above, there are some similarities between imports and RSEs. For example, RSDI is verified by RSV. The import process consumes tab-separated values (TSV) or comma-separated values (CSV) files to create RSDM objects. RSDM is a Drug Library entry, CCA entry, CCA Library Used to create View entries and Master Drug Formulary (MDF) entries. 24A and 24B show two preferred UML diagrams showing a high level of dialogue between the DragLibraryManager (DLM) and RSDI as the rule set is copied from the target to the source CCA Library. Similarly, FIG. 25 shows a high level of dialogue between the DragLibraryManager (DLM) and RSDI as the CCA Setting is edited within the target CCA Library.
The present invention also has a specialized combo box editor called Dose Rate Editor (DRE). DRE is used to establish DRDs for drugAmount, diffuseAmount, and limits. DRE is unique because it specifically takes into account both dose entry and the reserved word "None". DRE converts all absolute values of 0 (eg, "0", "0.0", "0.00", "none", etc.) to "None" and all subsequent values for non-zero values. Remove zeros or decimal points.
As mentioned above, the present invention can use both hard and soft limits at the same time. In addition, various related reports can be generated from one or more infusion pumps. One type of report is the Soft Limit Override Report (discussed below). The following is an example of how a soft limit override report can be generated. Persistent storage design for SoftLimit Alert / Override reports analyzes raw log data with specific requirements for "storing" uploaded logs to identify clinical practices, partial events, and duplicate log entries. Driven by both indirect requirements to clarify. In one example, all log data retains an association with the infusion pump from which the data was uploaded.
Raw log data is retained for archival purposes as well as to support direct reporting of log content (listing). Prior to retention, the raw log data had already been uploaded to the PC after the first analysis, but was still stored in the infusion pump (because the log was not cleared after uploading). The part of the log that represents the old data is deleted. The following database tables are defined to hold the parsed log data.<tables num="1"></tables>The first three tables listed, UploadHistory, UploadEvent, and EventType, support the existing ability to retain raw uploaded event data. The fourth table listed, ClinicalAction, aims to provide the necessary context for individual events (Soft Limit Allert / Override) and generate significant and useful reports.
Each individual field in the table above is shown below. First, the fields from UploadHistory are listed with a description of the purpose of those fields.<tables num="2"></tables>
Next, the fields from UploadEvent are listed along with the purpose of those fields.<tables num="3"></tables>
Next, the fields from EventType are listed with a description of the purpose of those fields.<tables num="4"></tables>
Finally, the fields from the Clinical Action are listed with a description of the purpose of those fields.<tables num="5"></tables>In one example, all of the listed fields are required and constrained to be "non-blank". In this example, all data fields support the value "not available" and certain fields could not be retrieved from the event log (for example, if the log exceeds 321 lines). Indicates that it has no value (due to overwriting). The figure below shows a data model that supports Soft Limit Allert events or Override clinical events. FIG. 26 shows a data model that supports a soft limit alert event or an override clinical event.
FIG. 7A shows an example of one soft limit override report. FIG. 7B includes headings and data descriptions shown in FIG. 7A. 7C-7F and 8A-8D show examples of soft and hard limit override reports for several different agents, in this example dopamine, heparin, insulin, and vancomycin. The reports shown in FIGS. 7C-7F list the types of alarms issued (hard lower limit, soft lower limit, soft upper limit, hard upper limit) and the number of times each alarm is issued. For each type of alert issued, the report also shows statistics related to how the user responded to the alert. In this example, the report shows the number of times the alert was overridden or not overridden. It also indicates the number of times the user has entered "no" when asked to confirm an entry for information. 8A-8D show another example of an alarm report and an override report. The reports shown in FIGS. 8A-8D are similar to the reports shown in FIGS. 7C-7F, except that each alert is separated by a CCA (ICU and MedSurg in this example). From the above examples, it is clear that any desired information can be collected and reported by the present invention.
One advantage of the present invention is that both hard and soft limits can be given for each drug, and for any drug / CCA combination, one, two, three, or four. It is possible that limits can be assigned. If there is the ability to give both hard and soft limits, then there are 16 combinations of limits that can be used. Each of the four limits can contain a value that specifies a limit, or the "limit" can be unlimited (indicated by "none" in the appropriate field). These two possibilities exist for each limit: hard lower limit, soft lower limit, soft upper limit, and hard upper limit). This feature allows the user to configure the device in various combinations such as hard upper limit only, hard and soft upper and lower limits, hard upper limit and soft upper limit (no lower limit), hard lower limit and soft lower limit (no upper limit), etc. Allows you to. In the examples of the upper and lower limits of the two sets, there are 16 possible combinations of configurations. More combinations are possible if additional limit sets are used. In one embodiment, the hard limit is a dose upper limit / dose lower limit for the selected drug and the selected CCA that cannot be overridden by the user. Hard limits in another embodiment can require or allow supervisory overrides. Hard limits, authority levels, and overrideability are defined by the hospital for each drug in the drug library. Hard limits for a particular drug, if assigned, can vary across different CCA.
In one embodiment, the soft limit is a dose upper and / or dose lower limit for the selected drug and selected CCA that can be overridden by the user. Soft limits for a particular drug, if assigned, can vary across CCA. A set of rules is provided for the drug library that triggers an alert or alert when the soft limit is reached. The warning requires a clear override step on the part of the operator. Similarly, a set of rules is provided for a drug library that gives a hard limit on the range of delivery rates that a user is allowed to program. For example, if the soft lower limit is set to 10 mL / h and the clinician inputs 9 ml / h, the infuser will display a soft limit override alarm. This alert, recorded in the infuser history log, notifies the clinician that the entry is outside the soft limits set for the drug entry. The clinician can use the override to choose to continue programming, or cancel the override and re-enter another value. If the clinician chooses to disable the soft limit, the event is recorded separately in the infuser history log. Hard and soft limits can be set for various other drug parameters. Examples include dosing rate, drug delivery time, drug concentration, patient weight, amount to be infused (VTBI), etc.
Another use of hard and / or soft limits relates to correct data entry. For example, it is possible to set a hard limit on the time entry so that the user can only enter a value between 0 and 59. In this example, the system notices a data entry error and forces the user to enter a value within the valid range. In another example, only some values or ranges are allowed to be entered for various drug fields. Reference numeral 15B shows examples of values that can be entered for the drug unit field, the drug amount field, the diluent field, the delivery drug dose / rate unit field, and the hard and soft limit fields. If the user attempts to enter another value, the system prompts the user to fill in a valid field or raises an alarm or alarm.
The invention also allows the import and export of drug libraries from one computer to another. The library must first be exported before it can be imported. In general, a drug library can be exported to a complete drug library (FDL) with a predefined format, the format of which is that the library is imported and configured as the active library. Make it portable in a secure and secure manner to other computers that are capable of. For example, for a first PC with an active library, the library can be exported to a binary format and transferred to a second PC where the library will be imported (via network, computer readable media, etc.). Therefore, the libraries on the first PC and the second PC are synchronized. A special file extension (FDL), as well as software recognition between computers, is required.
When the FDL is exported, the entire drug library is first "selected" from the database using the SelectEnterDrugLibry storage procedure (see below). The procedure actually contains several selection statements, one statement per table. The table is the same as the table for copying. For each table, the export method serializes the table name, the number of rows and columns, and then each row is serialized column by column. Note that the original database index values are serialized. When the library is read from the file, the index values are no longer valid, but must be mapped the same as if the library was copied. In one example, the FDL file is a "read-only" file. Since the FDL file is in Java® serialization format, the FDL file is not easily modified by the user using a normal software application. This feature is part of the reason for using serialization, that is, to prevent users from tampering with the completed drug library.
When the FDL is imported, all serialized information is first loaded into memory in the form of a 3D array. There are three array dimensions: one for the table, one for the rows, and one for the columns. The size of the row dimensions and the size of the column dimensions can be different for each table. This "raw" data is inserted into the database table by table and row by row. Index mapping can also be executed on the way. Then, when a row is inserted, a new index value is generated and stored in the map, just as it does during a copy operation. Some tables can contain indexes on other, previously inserted tables. Those indexes are converted from the original value to the new value using the generated map. Those converted index values are the values that will be inserted into the new row. After being stored in the database, the FDL becomes a Finalized Drug Library and makes another Finalized Drug Library an Archived library.
The following is the order in which the tables are stored in the array, what the index dependencies are, which columns are stored in the map, and which column values are inserted. To be able to do this, first let the FDL import know if it needs to be mapped to a new value, FDLData. It is an explanation of Java.
As with copying drug libraries, it is important to recognize that the order in which the tables are processed during the FDL import is important. The order is as listed constants in FDLData. It is encoded in the java file. The following is an example of such an enumerated constant. That is,<maths num="7"></maths>
The above constants can be used as indexes into the 3D array of raw data described above. This code section also includes PostSchemaChange. It can also be generated by sql.
For each table being exported / imported, the table name, the number of columns, any of the columns (idCallumn) that other tables may depend on, and finally that table depends on it. There is an instance of TableInfo that keeps track of the index set for the table. The "idColumn", if specified, is generated by the database for each row in the table as the row is inserted. The old value (from the serialized file) and the new value (from the database row insert) are stored in the index map. Then all other in-memory tables that reference the old index are updated to contain the new index before the row is inserted. For example, the "idColumn" of the RuleSet table shown below is the RuleSetID column of that table, and the RuleSetID column happens to be the second column in the TableInfo table. Therefore, the "idColumn" in the TableInfo instance for RuleSet is 1 (0 in the first column, 1, ... in the second column). Next, assume that there was a row in the RuleSet table that had a RuleSetID of 5047 when the FDL was exported. That is,<tables num="6"></tables>The CcaLibry table and the DragFormulary table (shown below) each have a RuleSet dependency, i.e., their respective RuleSetID column.<tables num="7"></tables>Next, assume that when the FDL is imported, that particular row in the RuleSet table (shown below) will be given a new index value of 5122.<tables num="8"></tables>Later, any RuleSetID value of 5047 is first changed to 5122 before the CcaLibry or DragonFormulary table is inserted. An "idColum" setting of 1 tells the FDL import code to store the 5047-5122 mapping.<tables num="9"></tables>The 5047 values in the CcaLibry and DragonFormulary tables are changed to 5122 while still in memory, i.e. in the 3D table of raw data. After processing those tables, the CaLibry table and the DragFormularyID table are shown below.<tables num="10"></tables>
FDLData. If you look back at the Java file, you will see that the various sections of the file are in the PostSchemaChange. It is automatically generated by the skl file. Those sections can be cut and pasted into the Java code from the output of that file. Specifically, the table ordering constants (shown above), as well as the TableInfo array and the contents of that array, can be generated in the event of a database schema change.
In addition, PostSchemaChange. The SQL file also generates most of the SelectEnterDrugLibry storage procedure (described below) at the same time. In this case as well, PostSchemaChange. The SQL code generated by the skl file can be found in SelectEnterDrugLibry. It is possible to cut and paste in the appropriate place in the SQL file.
When the FDL is exported, the data that makes up the library is retrieved from the database (so that the data can be serialized into files). The SelectEnterDrugLibry storage procedure does that. The procedure utilizes several selection statements to select tables in a particular order and columns in any given table in a particular order.
The order of the tables, and the order of the columns in those tables, is important for the FDL import code that reconstructs the drug library, so that the FDL export, FDL import, and SelectEnterDrugLibry codes can be kept in sync with each other. It is essential. Even the slightest change in the database schema can be found in FDLData. It forces you to change the Java and SelectEnterDrugLibry, as well as the CopyDrugLibry storage procedure. Even the slightest error (mismatch) will not work properly.
With the exception of the CopyDrugLibry code, most of the Java and SQL changes are made by PostSchemaChange. After the new schema is deployed. It can be brought about by running the skl file. Simply cut and paste the generated code over the matching / similar code in those files. Also, the CopyDrugLibry code change can be automated.
One feature of the present invention is that the data can be imported into and exported from the system. Library text files that use comma-separated values (CSV) or tab-separated values (TSV) can be imported by the system. One unique feature is that the entire file must pass the RSV test described above, otherwise the entire import is considered invalid.
It will be appreciated by those skilled in the art that the invention is applicable to a variety of pumps or medical devices and is not limited to the pumps used herein to describe the invention. Moreover, one of ordinary skill in the art will recognize that the connection between the pump and the computer can be wireless or wired without departing from the present invention. A wireless communication engine is connected to the pump and computer, such as BLUETOOTH (IEEE802.15), or other protocols such as those described in IEEE802.11, IEEE802.11a, IEEE802.11b, and IEEE802.11g. , It is possible to use a wireless network that utilizes a communication protocol. Communication within the wireless network can utilize radio frequency electromagnetic radiation, infrared radiation, or other means for reaching wireless communication between network elements.
In one example, the Plug and Play module 4 can accommodate or contain a wireless communication engine or a wireless connection engine. Conventional wireless communication modules for medical pumps have been external plug-ins and bolted types for optimal transmission and reception. These conventional communication modules significantly increase the space required for the pump and change the shape of the pump. Those modules can be damaged or dislodged if the pump is dropped. In addition, there are strict standards for maximum electrical radiation from medical devices to prevent possible interference with other medical devices. The wireless plug and play module 4 of the present invention does not significantly increase the space occupied by the pump. By arranging the plug-and-play module 4 inside the pump housing 2 with the improved antenna design described below, good position / orientation tolerant transmission / reception characteristics are still provided. The result is the surprising result that the electron emission from the device is reduced and better restricted.
As mentioned above, the infusion pump of the present invention can be connected to various other devices. In one example, the present invention uses a connection engine to provide system functionality in addition to allowing the pump to connect to a variety of other devices. The following is an example of a connection engine that can be used in the present invention. In the examples described above, various features and capabilities can be customized as desired.
The connectivity engine provides important system functions, as well as via both wired and wireless communication links, drug management unit (MMU), hospital information system (HIS), pharmacy information system (PhIS), and others. An assembly inside an infuser housing that is intended to allow the infuser to connect to a variety of external systems, including medical information systems. The connection engine can interface with the CPU print wiring assembly via the board-to-board connector via the data bus and address bus on the engine print wiring assembly. In one example, the connectivity engine supports approximately 1-2 megabytes of read-only programs and 1 megabytes or more of read / write data memory for the infuser CPU print wiring assembly. The connection engine can communicate with the host computer via a serial data port located externally on the rear of the infuser unit. In one example, the data port is electrically isolated.
In this example, the connected engine includes a front panel lockout switch that is externally accessible on the rear of the unit. The connection engine can also include a nurse calling interface located externally on the rear of the unit. The nurse call interface allows the patient to be used with a nurse call device, such as a switch held by the patient, which allows the patient to send an alarm message to the nurse. The connection engine can also include an alarm volume control accessible from behind the appliance. This control adjusts the volume level for audible alarms that notify the user of errors, warnings, and more.
A connectivity engine is a modular, intelligent printed wiring assembly that can support infuser interconnection to various external systems for the purpose of establishing bidirectional communication between the infuser and the external system. Examples of external systems can include drug management units (MMUs), medical information systems, HIS, and external wireless access points. Other examples of external systems include one or more PCs for downloading drug libraries and software to the infuser and for uploading logs from the infuser.
As described above, the present invention enables both wired communication and wireless communication. Examples of wired interfaces that can be supported include Ethernet® 10BaseT and 100BaseT standards, as well as megabit and fiber optic interfaces. Examples of radio interfaces that can be supported include IEEE802.11a / b / g, as well as any other desired interface. The connection engine can support a variety of network protocols, including XML services, HTML services, ftp services, and Telnet services.
In one example, the invention typically operates using either a wired interface or a wireless interface. In another embodiment, the present invention can use both a wired interface and a wireless interface at the same time. In that example, if a failure is detected in any of the modes, all communications can be automatically switched to the functioning mode.
Connected engine hardware can take many forms, depending on the desired functionality and capabilities. In one example, the connected engine includes the following subcircuits: That is, CPU memory, that is, RAM and flash, an external serial interface, a nurse call interface, audio volume control, a lockout switch, a connected engine controller, an Ethernet® interface, a wireless interface, and an antenna assembly. The following external connectors can also be included. That is, an Ethernet® RJ-45 connector, an RF connector for connecting a Wi-Fi transceiver to an antenna printed wiring assembly, an RS232 serial port DB9 connector, and a nurse call interface connector.
9 to 11 are block diagrams of an exemplary connected engine that is completely sealed inside a pump housing rather than a removable plug-and-play module that can be used in the present invention. FIG. 9 shows a user interface controller (UIC) 20 connected to the connection engine 22 via a universal serial bus (USB). Of course, other interfaces can also be used (eg RS232 serial interface, parallel interface, etc.). The connection engine 22 is an input / output board shown in FIG. 9 having an Ethernet® connection and a WiFi connection. FIG. 10 is a block diagram of a connection engine including a processor 24. The processor 24 is connected to an Ethernet® transceiver 26 and a transformer 28 to provide an Ethernet® interface that communicates with one or more PCs 10. The interface can also be provided wirelessly. The processor is also connected to the USB controller 30. The USB controller 30 is UIC via the USB interface. It is connected to the USB client 32 and the RF transceiver 34.
An RF transceiver 34 with two antennas 36 and 38 is shown. The present invention may include only one antenna, but two antennas can improve the performance of the present invention. Communication between the present invention and other devices can be critical, so it is desirable to provide the most reliable wireless communication possible. Two diversity antennas optimize the wireless communication coverage of the present invention. The present invention uses a combination of two different diversity schemes, spatial diversities, and pattern diversities. Traditionally, in spatial diversity, two identical antennas are placed in two separate locations to bring diversity reception to a common receiver. In that case, the scheme not only physically separates the antennas, but also realizes pattern diversity by arranging the two antennas at right angles. In this way, the peaks in one antenna fill the nulls in the other antenna and are combined radiation. Pattern) makes it look more omnidirectional than just a single antenna. This antenna diversity scheme serves several purposes. First, it is desirable to have an antenna that is less obvious from the outside, and it is desirable to use an antenna that is built inside. Second, in most applications, the invention must meet the EMC requirements specified in the IEC60601-1-2, 2nd Edition standard, which limits the amount of radiation a device can emit. The use of two divers antennas helps to achieve these goals. In one example, the antenna used in the present invention is sealed inside the housing of the infusion pump. This helps keep dust, harmful solvents, and debris away from the antenna, increasing radiation limits and reducing the likelihood of antenna damage.
In another example, the connection engine includes memory that is used as a cache to temporarily store information. Caches can make your system work more efficiently and more reliably.
FIG. 11 is a block diagram of the wireless interface shown in FIG. 10 showing a baseband processor-media access controller 40 including a USB interface for communicating with a host computer. The processor 40 is connected to a modulator / demodulator 42, an RF / IF converter 44, and a power amplifier 46. Antennas 36 and 38 are driven by a power amplifier 46 and an RF / IF converter 44.
12A-15A are electronic system diagrams of an example of the present invention applied to an Abbott PLUM A +® infuser. 12A-12D show the CPU and the communication engine or connection engine. The communication engine facilitates communication with other devices via a wired or wireless interface. The communication engine can utilize the same right-angled antennas as described above in connection with FIGS. 9-11. FIG. 12 also shows a digital I / O chip for interfacing with various components such as switches and user controls, nurse call jacks, keypads, alarm speakers, LEDs, and more. FIG. 13 shows a power supply subsystem that includes a power supply circuit and an insulating barrier. FIG. 14 shows a mechanical subsystem including a pressure sensor, an air sensor, a motor position sensor, and a motor drive.
FIG. 17 is an electronic system block diagram of a patient-controlled analgesia (PCA) pump. 18 and 19 are electronic system interface block diagrams of the connected engine that can be used in the PCA pump shown in FIG. FIG. 17 includes a power source that powers the system. The microcontroller interfaces with various components of the system, including keypads, patient pendants, serial ports, bar code readers, various sensors, various switches, motor drives, displays and LED indicators, and speakers.
FIG. 18 is a block diagram of a connection engine that can be used in the PCA system shown in FIG. FIG. 18 shows a connectivity engine and several interfaces, including Ethernet®, WiFi, an external RS232 serial interface, and an RS232 serial interface to a host device. FIG. 18 also shows a connected engine (via a power connector) in which the connected engine can be powered from a PCA pump (FIG. 17). The PCA pump produces a motor voltage VMOT to power various motors. It is possible to power the connected engine using the same voltage VMOT.
FIG. 19 is a more detailed block diagram of the connected engine of FIG. The connection engine includes a connection engine controller (CEC), which is a wired / wireless connection module incorporating both an Ethernet® processor and an 802.11b wireless transceiver. Ethernet® transceivers, and all required circuitry, provide a 10/100 Base T interface via an RJ-45 jack. The USB controller, and all necessary circuitry, controls the USB (host) interface to WiFi. Two RS232 ports are connected to the system bus. The connection engine also includes FLASH memory and SDRAM memory.
In the above detailed description, the present invention has been described in the context of specific exemplary embodiments of the present invention. Various modifications and modifications can be made to those embodiments without departing from the broader scope of the invention described in the claims. Therefore, the specification and drawings should be considered exemplary rather than restrictive.
68 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43 Sheet 44 Sheet 45 Sheet 46 Sheet 47 Sheet 48 Sheet 49 Sheet 50 Sheet 51 Sheet 52 Sheet 53 Sheet 54 Sheet 55 Sheet 56 Sheet 57 Sheet 58 Sheet 59 Sheet 60 Sheet 61 Sheet 62 Sheet 63 Sheet 64 Sheet 65 Sheet 66 Sheet 67 Sheet 68
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| WO02069099A2 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| WO0211049A2 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| JPH07502678A | Cites | Japan | Examiner |
55 members in 6 offices
Priority claims12
| Document | Office | Kind | Date |
|---|---|---|---|
| 51964603 | United States of America | P | |
| 51964603 | United States of America | P | |
| 52755003 | United States of America | P | |
| 52755003 | United States of America | P | |
| 78387704 | United States of America | A | |
| 78387704 | United States of America | A | |
| 2003519646 | – | – | – |
| 2003527550 | – | – | – |
| 2004783877 | – | – | – |
| US20030519646P | – | – | – |
| US20030527550P | – | – | – |
| US20040783877 | – | – | – |
Members55
| Document | Office | Kind | |
|---|---|---|---|
| CA2554903A1 | Canada | A1 | |
| WO2005036447A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2004292207A1 | Australia | A1 | |
| CA2545792A1 | Canada | A1 | |
| WO2005050526A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2005144043A1 | United States of America | A1 | |
| WO2005050526A8 | World Intellectual Property Organization (WIPO) | A8 | |
| WO2005036447A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US2005278194A1 | United States of America | A1 | |
| US2006089854A1 | United States of America | A1 | |
| US2006089855A1 | United States of America | A1 | |
| US2006100907A1 | United States of America | A1 | |
| EP1685516A2 | European Patent Office (EPO) | A2 | |
| EP1704501A2 | European Patent Office (EPO) | A2 | |
| US2006265186A1 | United States of America | A1 | |
| EP1744262A2 | European Patent Office (EPO) | A2 | |
| US2007055479A1 | United States of America | A1 | |
| EP1744262A3 | European Patent Office (EPO) | A3 | |
| US2007083344A1 | United States of America | A1 | |
| JP2007511287A | Japan | A | |
| US2007213598A1 | United States of America | A1 | |
| US2007214003A1 | United States of America | A1 | |
| EP1855221A2 | European Patent Office (EPO) | A2 | |
| EP1855221A3 | European Patent Office (EPO) | A3 | |
| US2008133265A1 | United States of America | A1 | |
| US7398183B2 | United States of America | B2 | |
| US7454314B2 | United States of America | B2 | |
| US7490021B2 | United States of America | B2 | |
| US2009135196A1 | United States of America | A1 | |
| US2010130933A1 | United States of America | A1 | |
| EP2273401A1 | European Patent Office (EPO) | A1 | |
| EP2273402A1 | European Patent Office (EPO) | A1 | |
| EP2273403A1 | European Patent Office (EPO) | A1 | |
| US7895053B2 | United States of America | B2 | |
| EP2336924A1 | European Patent Office (EPO) | A1 | |
| AU2004292207B2 | Australia | B2 | |
| US8065161B2 | United States of America | B2 | |
| US2012065990A1 | United States of America | A1 | |
| US2012066609A1 | United States of America | A1 | |
| JP2012187411A | Japan | A | |
| JP2012196462AThis record | Japan | A | |
| JP5069004B2 | Japan | B2 | |
| US8380536B2 | United States of America | B2 | |
| CA2545792C | Canada | C | |
| JP5584726B2 | Japan | B2 | |
| CA2554903C | Canada | C | |
| JP5647644B2 | Japan | B2 | |
| US9123077B2 | United States of America | B2 | |
| US2016051751A1 | United States of America | A1 | |
| US9572923B2 | United States of America | B2 | |
| US2017274140A1 | United States of America | A1 | |
| US10434246B2 | United States of America | B2 | |
| US2020206413A1 | United States of America | A1 | |
| US11235100B2 | United States of America | B2 | |
| US2022331513A1 | United States of America | A1 |
21 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of completion of termEXPY | EXPY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Written request for registration of change of domicileJAPANESE INTERMEDIATE CODE: R313531S531 | S531 | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Notification of resignation of power of attorneyJAPANESE INTERMEDIATE CODE: A7424RD04 | RD04 |
Numbers
- Publication
- 2012196462
- Publication, DOCDB
- 2012196462
- Publication, EPODOC
- JP2012196462
- Application
- 107254
- Application, DOCDB
- 2012107254
- Application, EPODOC
- JP20120107254
Titles2
- Japanese
- 薬剤情報を保持するため、および薬物送達デバイスと通信するためのシステム
- English
- The system for communicating with a medicine delivery device, in order to hold drug information
Classification
- CPC, 10
- A61M5/142
- A61M5/14212
- A61M5/145
- A61M2205/3561
- A61M2205/3584
- A61M2205/52
- G16H40/67
- G16H70/40
- G16H20/17
- G16H15/00
- IPC, 10
- A61M5 142
- A61G12 00
- A61M5 00
- A61M5 145
- A61M5 172
- G16H10 60
- G16H20 17
- G16H40 67
- G16H70 40
- G06Q50 24