(57)【特許請求の範囲】
【請求項１】
ユーザインターフェース装置における表示のための、少なくとも一つのデータ処理装置により実行されるグラフィカルユーザーインターフェスを有する点滴管理プラットフォームにより、複数の容器のうちそれぞれの容器について、複数の患者のうち１人についての識別情報、点滴モジュールの識別情報、および対応する前記患者への点滴のための前記容器内の流体の属性を指定することと、
前記点滴管理プラットフォームにより、複数の患者のうちそれぞれの患者への流体投与に関連付けられたデータを複数の点滴モジュールから受信することであって、前記データは、対応する前記点滴モジュールの前記識別情報を含み、前記複数の点滴モジュールは、前記点滴管理プラットフォームから遠隔位置にあり、
前記点滴管理プラットフォームにより、受信された前記データを用いて、各容器について累積点滴量を決定することであって、累積点滴量は、少なくとも１つの区分それぞれについての点滴量の総和に等しく、各区分は、対応する前記点滴モジュールによってプログラムされた対応する前記容器における特定量の流体を流す期間を表すものであり、
前記点滴管理プラットフォームが、前記容器の最大容器容量は名目量プラス過充填許可量に等しいという規則を各容器に対して適用することにより、各容器の前記最大容器容量と、前記累積点滴量とに基づいて、対応する前記患者へ点滴される前記流体の量と、前記容器中に残っている流体の量とを決定することと、
前記点滴された流体の決定された量と、各容器の前記残っている流体の決定された量とを示すデータを提供することと、
各区分の開始時間に基づいて、対応する前記容器の最大容器容量を既に超えているかを決定することと、
前記最大容器容量を超えている場合、対応する前記容器の使用が完了したものとして決定することと、
前記点滴管理プラットフォームによって、使用が完了した前記容器と関連付けられた前記患者の前記識別情報と、使用が完了した前記容器において前記流体を点滴した前記点滴モジュールに関する前記識別情報と、使用が完了した前記容器内の前記流体の属性とを指定する新規の容器を設定することと、
を含む、コンピュータによって実行される方法。
【請求項２】
前記データを提供することは、前記データをグラフィカルユーザインターフェースにおいて表示すること、前記データをロードすること、前記データを保存すること、および、前記データをリモート計算システムへ送信すること、のうち少なくとも１つ含む、請求項１に記載の方法。
【請求項３】
前記指定すること、前記受信すること、前記決定すること、および、前記提供することのうち少なくとも１つは、少なくとも１つの計算システムの一部を形成する少なくとも１つのデータプロセッサによって実行される、請求項１または２に記載の方法。
【請求項４】
各区分は、対応する前記患者への送達のために処方された前記流体の量を指定する異なる順序識別情報を有する、請求項１〜３のいずれか１つに記載の方法。
【請求項５】
前記受信されたデータは、各区分について前記開始時間を示すメッセージを含む、請求項４に記載の方法。
【請求項６】
提供される前記データは、前記容器が空になるであろう推定時間を含む、請求項１〜５のいずれかに記載の方法。
【請求項７】
命令が少なくとも１つの計算システムの少なくとも１つのデータプロセッサによって実行されると、請求項１〜６のいずれかに記載される方法が行われる前記命令を保存する、非一時的コンピュータ読出し可能記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願への相互参照）
本出願は、２０１３年３月１３日に出願された「薬剤容器容量の追跡のための点滴管理プラットフォーム」という発明の名称の米国出願番号第１３／８０２，２７７号に対する優先権を主張する。その内容は、これにより参照によって全部が取り入まれる。
【０００２】
本明細書中に記載される本発明は、点滴容器内の流体／薬剤の量を追跡するための点滴管理プラットフォームに関する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
臨床環境において、患者への投与のための点滴は、静脈（ＩＶ）、皮下、動脈、硬膜外、腸内または潅注の流体空間を経由して行われる。これらの点滴は、大量ポンプ、注射器を介してまたは患者制御によって鎮痛によって送られる。点滴は、病院薬局によって制御され、薬局または処方者は一般的には、各点滴に含まれる希釈剤の量を指定する。しかし、このような点滴を収容している容器中の実際の量は、処方量に必ずしも対応していないため、処方量の投与後に薬剤／流体が残留する場合がある。加えて、いくつかの場合においてこのような容器（例えば、ＩＶバッグなど）内に最初に与えられた流体の量が過充填または充填不足である場合もある。
【０００４】
さらに、介護者は、同一の薬剤／流体の治療を繰り返すことを要求することが多い。余剰な薬剤がある場合、薬剤容器内の残りの量全てを用いることが好ましいであろう。薬剤が不足する場合、新規の薬剤容器が必要になる。
【０００５】
看護師が患者のベッドサイドにおいて点滴をプログラムする際、点滴すべき量（ＶＴＢＩ）を容器全体の量未満となるようにプログラムすることが多い。看護師は、容器全体の量が投与されるまで複数のＶＴＢＩをプログラムすることにより、点滴を区分分けしてプログラムしてもよい。
【課題を解決するための手段】
【０００６】
一態様において、点滴管理プラットフォームは、複数の容器それぞれについて、複数の患者のうち１人についての識別情報、点滴モジュールの識別情報、および対応する患者への点滴のための容器内の流体を特徴付ける属性を指定する。その後、点滴管理プラットフォームは、複数の患者それぞれへの流体投与を特徴付けるデータを複数の点滴モジュールから受信する。このデータは、対応する点滴モジュールの識別情報を含み、複数の点滴モジュールは、点滴管理プラットフォームから遠隔位置にある。その後、点滴管理プラットフォームは、各容器について規則セットを用いて、対応する患者へ点滴される流体の量と、容器中に残っている流体の量とを決定し得る。その後、点滴された流体の決定された量と、各容器の残りの流体の決定された量とを特徴付けるデータが提供され得る。
【０００７】
提供されるデータは、表示目的のためのグラフィカルユーザインターフェースへ送信されるデータ、永続記憶装置へ送信されるデータ、リモート計算システムへ送信されるデータのうち１つ以上を含み得る。データプロバイダのうち少なくとも１つは、少なくとも１つの計算システムの一部を形成する少なくとも１つのデータプロセッサによって実装される。指定すること、受信すること、決定すること、および提供することの少なくとも１つは、少なくとも１つの計算システムの一部を形成する少なくとも１つのデータプロセッサによって実装される。
【０００８】
このデータは、各容器の最大容量、累積点滴量、点滴区分の開始時間のうち１つ以上を決定するために用いられ得る。
【０００９】
容器の最大容量は、名目量プラス過充填許可量に等しくあり得る。加えて、提供されるデータは、容器が空になる推定時間を含み得る。
【００１０】
対応する容器内に残留している流体の決定された量が対応する決定された累積点滴量に基づくように、受信されたデータを用いて累積点滴量決定することができる。累積点滴量は、少なくとも１つの区分それぞれの点滴量の総和に等しくすることができる。各区分は、対応する点滴モジュールによってプログラムされた対応する容器の部分を含み得る。各区分は、対応する患者へ送達するために処方された流体の量を指定する異なる順序識別情報を持ち得る。受信されたデータは、各区分の開始時間を示すメッセージを含み得る。
【００１１】
各区分の開始時間に基づいて、対応する容器の最大容器容量が既に超えているかを決定することができる。この容器は、最大容量を超えた場合に完了していると特徴付けられ得る。加えて、点滴管理プラットフォームは、完了した容器と関連付けられた患者の識別情報、完了した容器の流体を点滴した点滴モジュールの識別情報、および完了した容器内の流体を特徴付ける属性を指定する新規の容器を生成することができる。
【００１２】
命令を保存する非一時的なコンピュータで読み出し可能な媒体を含むコンピュータプログラム製品についても記載される。これらの命令は、１つ以上の計算システムの１つ以上のデータプロセッサによって実行されると、少なくとも１つのデータプロセッサがこの中で動作を行う。同様に、１つ以上のデータプロセッサおよび１つ以上のデータプロセッサへ接続されたメモリを含み得るコンピュータシステムについても記載される。メモリは、少なくとも１つプロセッサに本明細書中に記載される動作のうち１つ以上を行わせる命令を一時的にまたは永久的に保存し得る。加えて、単一の計算システム内に設けられたかまたは２つ以上の計算システム間に分散された１つ以上のデータプロセッサにより、方法が実装され得る。このような計算システムは、１つ以上の接続を経由して接続され、データおよび／またはコマンドや他の命令等を交換する。１つ以上の接続は、これに限られないが、例えば、インターネット、無線広域ネットワーク、ローカルエリアネットワーク、広域ネットワーク、有線ネットワークなどのネットワーク上の接続を含む。また、１つ以上の複雑な計算システムの間の直接の接続などを経由してもよい。
【発明の効果】
【００１３】
本明細書中に記載される本発明は、多数の利点を提供する。例えば、本発明は、特定の介護施設の過充填／充填不足事例を考慮に入れて患者へ投与されている全ての点滴についてのビューを提供する点滴管理プラットフォームを提供する点において、有利である。
【００１４】
本明細書中に記載される本発明の１つ以上の変形例の詳細について、添付図面および以下の記載において説明する。本明細書中に記載される本発明の他の特徴および利点が、記載および図面ならびに特許請求の範囲から明らかになる。
【図面の簡単な説明】
【００１５】
【図１】医療環境内の計算機環境を示すシステム図である。
【００１６】
【図２】点滴管理プラットフォームを示す第１の図である。
【００１７】
【図３】点滴管理プラットフォームを示す第２の図である。
【００１８】
【図４】点滴管理プラットフォームを示す第３の図である。
【００１９】
【図５】点滴管理プラットフォームを示す第４の図である。
【００２０】
【図６】点滴管理プラットフォームによって実行される方法を示すプロセスフロー図である。
【発明を実施するための形態】
【００２１】
図１は、病院などの医療環境内の計算機環境１００を示すシステム図である。多様なデバイスおよびシステムが、医療環境内にあるものおよび医療環境から遠隔にあるもののどちらも、少なくとも１つの計算機ネットワーク１０５を介して相互作用することができる。この計算機ネットワーク１０５は、多様なデバイスおよびシステム間におけるデジタル通信接続（すなわち、有線または無線）の任意の形態または媒体を提供することができる。通信ネットワークの例を挙げると、ローカルエリアネットワーク（「ＬＡＮ」）、広域ネットワーク（「ＷＡＮ」）およびインターネットがある。いくつかの場合において、多様なデバイスおよびシステムのうち１つ以上は、ピアツーピア接続を介して（配線接続を介してまたは例えば、ＢｌｕｅｔｏｏｔｈまたはＷｉＦｉのような無線プロトコルを介して）直接的に相互作用することができる。加えて、いくつかの変形例において、デバイスおよびシステムのうち１つ以上は、携帯電話データネットワークを介して通信する。
【００２２】
特に、計算機環境１００の形態は、バックエンドコンポーネントを（例えばデータサーバ１１０として）含むか、またはミドルウェアコンポーネントを（例えば、アプリケーションサーバ１１５として）含むか、またはフロンドエンドコンポーネントを（例えば、ユーザが本明細書中に記載される本発明の実現と相互作用をするグラフィカルユーザインターフェースまたはウェブブラウザを有するクライアントコンピュータ１２０として）含むか、またはこのようなバックエンド、ミドルウェア、またはフロンドエンドコンポーネントの任意の組み合わせを含む計算システムにおいて、実現される。クライアント１２０およびサーバ１１０、１１５は、概して相互に遠隔に配置され、典型的には通信ネットワーク１０５を通じて相互作用する。クライアント１２０とサーバ１１０、１１５との関係は、それぞれのコンピュータ上において実行しかつおよび相互にクライアント−サーバ関係を有するコンピュータプログラムに生じる。クライアント１２０は、医療環境内において多様な機能を提供するローカルアプリケーションを含む多様な計算機プラットフォームのいずれかであり得る。例えば、クライアント１２０には、デスクトップコンピュータ、ラップトップコンピュータ、タブレット、およびタッチスクリーンインターフェースを備えた他のコンピュータが含まれるがこれらに限られるものではない。ローカルアプリケーションは、ネットワーク接続性が不要な点および／またはサーバ１１０、１１５（例えば、ウェブブラウザ）のうち１つ以上と相互作用し得る点において、自立型であり得る。
【００２３】
多様なアプリケーションが、例えば、電子健康記録アプリケーション、医療デバイス監視、操作およびメンテナンスアプリケーション、スケジューリングアプリケーション、課金アプリケーションなどの計算機環境内の多様なデバイスおよびシステム上において実行され得る。
【００２４】
ネットワーク１０５は、１つ以上のデータ保存システム１２５へ接続され得る。データ保存システム１２５は、医療環境内または専門施設内の物理的なデータ保存を提供するデータベースを含み得る。追加的にまたは代替的に、データ保存システム１２５は、例えばマルチテナント計算機環境中へのデータのリモート保存を提供するクラウドベースのシステムを含み得る。データ保存システム１２５は、非一時的なコンピュータで読み出し可能な媒体も含み得る。
【００２５】
モバイル通信デバイス（ＭＣＤ）１３０は、計算機環境１００の一部も形成し得る。ＭＣＤ１３０は、ネットワーク１０５を介して直接的に通信し、かつ／または、例えば携帯電話データネットワークのような中間ネットワークを介してネットワーク１０５と通信することができる。例えば、ＳＭＳおよびＭＭＳのようなメッセージプロトコルを含む多様な種類の通信プロトコルが、ＭＣＤ１３０によって用いられ得る。
【００２６】
多様な種類の医療デバイス１４０が、計算機環境１００の一部として用いられ得る。例えば、計算機環境は、薬剤を含む流体を患者へ送達するための多様なシステム／ユニットを含み得る。特定の種類の医療デバイス１４０の１つは、点滴モジュール１４０Ａである。点滴モジュール１４０Ａは、多様な種類の点滴ポンプ（例えば、蠕動点滴ポンプ、大量点滴ポンプおよび注射器ポンプ）を含み得る。点滴モジュール１４０Ａは、ネットワーク１０５へ直接に接続されかつ／または医療デバイス１４０へ接続され、医療デバイス１４０はネットワーク１４０へ接続される。
【００２７】
医療デバイス１４０は、他に明記無き限り、患者の１つ以上の生理学的測定を特徴付けかつ／または患者の治療を特徴付ける通信インターフェースを備える任意の種類のデバイスまたはシステムを含み得る。いくつかの場合において、医療デバイス１４０は、（ネットワーク１０５との通信と対照的に）ピアツーピア有線または無線通信を介して別の医療デバイス１４０と通信する。例えば、医療デバイス１４０は、他の医療デバイス１４０すなわち無線パルスオキシメータや、有線血圧モニターへ接続されたベッドサイドバイタルサインモニターを含み得る。医療デバイス１４０の１つ以上の動作パラメータは、臨床医によりローカルに制御されてもよいし、ネットワーク１０５を介して臨床医により制御されてもよいし、かつ／あるいはサーバ１１５、クライアント１２０、データ保存システム１２５、ＭＣＤ１３０および／または別の医療デバイス１４０のうち１つ以上によって制御されてもよい。
【００２８】
計算機環境１００は、病院などの医療環境内に必要となり得るような多様な種類の機能を提供し得る。医療デバイス１４０は、患者の１つ以上の生理学的測定および／または患者の治療を特徴付けるデータを提供し得る（例えば、医療デバイス１４０は、点滴管理システムなどであり得る）。医療デバイス１４０によって生成されたデータは、他の医療デバイス１４０、サーバ１１０、１１５、クライアント１２０、ＭＣＤ１３０へ伝達されかつ／またはデータ保存システム１２５中へ保存され得る。
【００２９】
計算機環境１００は、少なくとも１つの薬剤順序付けシステム１４５も含み得る。薬剤順序付けシステム１４５は、ネットワークへ接続され、生成および監視すべき順序（例えば、処方など）を可能にする。薬剤順序システム１４５は、例えば、アプリケーションサーバ１１５を介して、クライアント１２０およびＭＣＤ１３０のうち１つによってアクセスされ得る。薬剤順序付けシステム１４５は、少なくとも１つの点滴モジュール１４０Ａを介して、事前規定された期間にわたって事前規定された順序に従って、患者内に点滴すべき複数の薬剤および／または他の流体を指定し得る。これらの順序は、データ保存システム１２５中に保存されかつ／または他のクライアント１２０、ＭＣＤ１３０および／または医療デバイス１４０の１つ以上へ押し出され得る。いくつかの場合において、介護者は、（多様な生理学的センサーなどによって測定されるような）患者からの反応に基づいて、このような薬剤送達のタイミングおよび順序を変更する。
【００３０】
医療デバイス１４０（例えば、点滴モジュール１４０Ａ）のうち１つ以上は、患者へ送達される流体（例えば、薬剤）の量を監視し得る。患者へ送達される流体をここでは点滴と呼ぶ。他に明記無き限り、本明細書において薬剤に言及する場合、点滴モジュール１４０Ａを介して患者へ送達される非薬剤流体（例えば、血液、生理食塩水など）を含むものとして解釈されるべきである。
【００３１】
上記したように、薬剤などの流体を収容する容器は、薬剤師／処方者によって順序付けられた量によって異なる場合が多い。1人以上の患者への点滴の追跡および監視のためのグラフィカルユーザインターフェースを含むソフトウェアにより実装される点滴管理プラットフォーム１５０が設けられ得る。点滴管理プラットフォーム１５０は、ネットワーク１０５を介して点滴モジュール１４０Ａと通信する。点滴モジュール１４０Ａは、特定の点滴に関連する多様な属性を含む／特徴づけるデータを、直接的にまたは間接的に点滴管理プラットフォーム１５０へ提供し得る（データは、例えば、患者識別子、薬剤容器識別子、薬剤種類、薬剤投与速度、点滴モジュール識別子などである）。このような属性は、例えば点滴モジュール１４０Ａから送られたメッセージを介して提供され得る。いくつかの場合において、点滴管理プラットフォーム１５０は、薬剤順序を薬剤順序付けシステム１４５から受信した後、このような順序を特定の点滴モジュール１４０Ａおよび／または（点滴モジュール１４０Ａと後に関連付けられる）特定の患者と関連付ける。
【００３２】
図２は、ソフトウェア点滴管理プラットフォームのサンプルグラフィカルユーザインターフェースを示す図２００である。グラフィカルユーザインターフェースは、多様なグラフィカルユーザインターフェース要素を提供し、1人以上の患者のための複数の同時の点滴のビューを可能にするデータを表示する。本例において、少なくとも１人の患者へ提供される（それぞれは別個の行に示される）一連の点滴にに関するデータが表示される。このようなデータは、点滴モジュール１４０Ａから受信されたデータに基づいて定期的にまたは動的に更新され得る。第１の列２０５は、（患者名と異なる）患者識別子を羅列し得る。第２の列２１０は、特定の種類の点滴（例えば、連続的な、間欠的な、流動性の、など）を特定し得る。第３の列２１５は、患者名を羅列し得る。第４の列２２０は、点滴されている流体および／または点滴治療を特定し得る。第５の列２２５は、点滴の投薬量レベルを特定し得る。第６の列２３０は、点滴の流量を特定し得る。第７の列２３５は、点滴された流体を収容している容器が空になる推定時間を羅列し得る。第８の列２４０は、点滴された流体を収容している容器中の推定残留量を提供する。第９の列２４５は、点滴の現在の状態を羅列する。第１０の列２５０は、（データが連続更新されない場合に）特定の点滴についてのデータの最終更新時期を羅列する。第１１の列２５５は、点滴と関連付けられた優先度を羅列する。図２００の特定のビューは、ひとえに例示のためのものであり、進行中の点滴を特徴付ける追加のおよび／またはより少ない情報が所望の実装に応じて表示してもよいことが理解されるであろう。加えて、ユーザが表示されているデータの異なるビューを持つこと、および／または、そうではない場合には表示されたデータを操作することまたは使うことを可能にするために、多様なグラフィカルユーザインターフェース要素が提供され得る。
【００３３】
点滴管理プラットフォーム１５０は、（例えば１つ以上の事前規定された規則を用いて）薬剤の濃度およびこのような薬剤を収容する容器の容量を多様な方法で計算することができる（その後、これを用いて、第８の列２４０に示すように推定残留量を計算する）。一例において、薬剤濃度は、希釈剤量に対する薬剤単位の比率（例えば、ＣＥＦＴＡＺｉｄｉｍｅ  １０００ｍｇ／５０ｍｌ）として定義され得る。ほとんどの薬剤容器の場合、希釈剤量は、容器の名目量である。この規則は、単位量あたりで定義される濃度を有する間欠的なまたは連続的な薬剤には適用されない（１ｍＬあたりの薬剤量、例えば、Ｃｅｆａｚｏｌｉｎ  ５ｍｇ／１ｍｌ）。希釈剤量を追跡することにより、容器容量を計算することが可能になる。
容器名目量＝希釈剤量。
【００３４】
点滴管理プラットフォーム１５０は、様々な容量の容器を考慮に入れることができる。ほとんどの場合、容器の実際の容量は、容器の名目容量よりも大きい（容器に過充填をするという病院の習慣に基づく）。個々の病院の習慣により、薬局のための過充填（容量）パーセンテージの標準化が可能になる。最大容量は、以下のように計算することができる：
最大容器容量＝容器名目容量＊（１＋過充填％）。
【００３５】
いくつかの場合において、点滴は、希釈剤量１ｍＬでプログラムされる。これらのシナリオにおいて、初期点滴のための点滴すべき量（ＶＴＢＩ）は、容器最大容量として用いられ得、この場合に以下のようになる：最大容器容量＝ＶＴＢＩ。
【００３６】
点滴容器の追跡のため、点滴管理プラットフォーム１５０は、最大容器容量を維持し、各容器の累積点滴量と比較することができる。点滴モジュール１４０Ａは、点滴量を点滴メッセージ（すなわち、対応する点滴モジュール１４０Ａから送信されたデータ）の一部として提供することができる。累積点滴量は、容器に対して特定可能な全区分の点滴量の総和に等しくすることができる。区分とは、本明細書中用いられるように、所与の時期に投与されるようにプログラムされた容器の一部として定義され得、新規の順序識別情報と共に特定される。このような順序は、例えば、薬剤順序付けシステム１４５（例えば、薬局および／またはＥＭＲシステムなど）において開始し得る。
累積点滴量＝全区分の点滴量の総和。
【００３７】
点滴管理プラットフォーム１５０は、容器に対して点滴量の累積総和を維持することができる。点滴管理プラットフォーム１５０は、点滴モジュール１４０Ａと関連付けられた新規の順序ＩＤをもつ容器を生成し特定することができる。その後、容器情報を点滴管理プラットフォーム１５０によって維持されることができる。
【００３８】
点滴管理プラットフォーム１５０が区分開始（点滴のプログラミングにおいて割り当てられる順序ＩＤを含むＳＴＡＲＴまたはＲＥＳＴＡＲＴメッセージ）を示すメッセージを受信すると、当該点滴が点滴管理プラットフォーム１５０が既に保存した容器に関連するか否かを特定するためのアルゴリズムが起動され得る。アルゴリズムが最大容器容量が点滴されているかまたは超えていることを決定した場合、既存の容器およびその関連付けられた点滴は完了したものとしてみなされ、新規のものが生成される。
【００３９】
特定された各新規の容器について、点滴管理プラットフォーム１５０は、点滴についての関連付けられた点滴値を保存することができる。関連付けられた点滴値は、例えば、患者ＩＤ、点滴モジュールＩＤ、薬剤名、濃度（薬剤量／希釈剤量）および国内薬剤コード（ＮＤＣ）（適用可能な場合）、および点滴種類：一次または二次、のうち１つ以上である。これらの値は、一意的な容器を規定する。点滴管理プラットフォーム１５０によって維持されている容器のリストが（上記）点滴詳細と整合しない場合、アルゴリズムは、新規の点滴容器を生成し得る（現在の容器は完了したものとみなされる）。いくつかの実装において、累積点滴量を考慮する場合、アルゴリズムは、一次または二次の点滴／容器を考慮し得る。
【００４０】
点滴管理プラットフォーム１５０は、容器の累積点滴量と、点滴モジュール１４０Ａから受信された点滴メッセージ中の点滴すべき量（ＶＴＢＩ）とを用いて、これが同一の容器であるかあるいは新規のものであるかを特定することができる。累積点滴量およびＶＴＢＩの総和がこの容器の最大容器容量を超える場合、アルゴリズムは、前回の容器を完了しているものとしてマークし、新規の容器が生成され得る。そうではない場合、アルゴリズムは、点滴メッセージが既存の容器の新規区分であると決定することができる。
【００４１】
そのため、点滴管理プラットフォーム１５０によって受信された新規の区分に対して、累積点滴量＋ＶＴＢＩ＜＝最大容器容量である場合、この区分は、既存／現在の容器の一部として特定され得る。そうではない場合、新規の容器が使用されているものとみなされ得る（すなわち、累積点滴量＋ＶＴＢＩ＞最大容器容量）。
【００４２】
図３〜５は、薬剤量／希釈剤量３０５、累積点滴量３１０および点滴すべき量３１５に関するデータを示す点滴管理プラットフォームの異なるビューを示している図３００、４００、５００である。図３の図３００を参照して、ＣＥＦＴＡＺｉｄｉｍｅの５０ｍｌの薬剤バッグを患者に接続し、介護者（例えば、看護師など）は、（ＶＴＢＩ列３１５によって示されるように）３０ｍｌの薬剤が患者へ点滴されるようにプログラムする。図４の図４００を参照して、薬剤の３０ｍｌが患者中へ点滴された後、介護者は、（ＶＴＢＩ列３１５によって示されるように）さらに２０．５ｍｌの薬剤をプログラムする。５０．５ｍｌはバッグ量である５０ｍｌを超えているものの、変形例は、事前規定された許容範囲内に収まる。図５の図５００を参照して、第２の点滴である２０．５ｍｌの終了後、介護者は、（ＶＴＢＩ列３１５によって示されるように）さらに５ｍｌの点滴をプログラムする。このさらなる量は許容範囲から逸脱するため、点滴管理プラットフォームは、このさらなる点滴を新規の容器であるとして関連付ける。
【００４３】
図６は、方法を示すプロセスフロー図６００である。この方法では、６１０において、点滴管理プラットフォームは、複数の容器それぞれについて、複数の患者のうち１人についての識別情報、点滴モジュールの識別情報、および対応する患者へ送達されるべき容器内の流体を特徴付ける属性を指定する。その後、６２０において、点滴管理プラットフォームは、複数の患者それぞれへの流体投与を特徴付けかつ対応する点滴モジュールの識別情報を含むデータを複数のリモート点滴モジュールから受信する。その後、６３０において、点滴管理プラットフォームは、各容器について、対応する患者へ点滴される流体の量と、容器中に残っている流体の量とを決定する。このような決定は、例えば、このような計算がどのように生成され得るかを定義する規則セットを用いて行うことができる。この決定が行われた後、６４０において、点滴された流体の決定された量および各容器の残りの流体の決定された量を特徴付けるデータが提供される（例えば、表示、保存、ロード、送信などされる）。
【００４４】
本明細書中に記載される本発明の１つ以上の態様または特徴が、デジタル電子回路、集積回路、特殊設計ＡＳＩＣ（特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェアおよび／またはこれらの組み合わせとして実現され得る。これらの多様な実装は、保存システム、少なくとも１つの入力デバイス（例えば、マウス、タッチスクリーンなど）および少なくとも１つの出力デバイスとデータおよび命令の送受信を行うように接続された、特殊または汎用目的であり得るプログラマブルシステム（例えば、少なくとも１つプログラマブルプロセッサ）上において実行可能でありかつ／または解釈可能である１つ以上のコンピュータプログラムにおける実装を含み得る。
【００４５】
これらのコンピュータプログラムは、プログラム、ソフトウェア、ソフトウェアアプリケーション、アプリケーション、コンポーネントまたはコードとも呼ばれるが、プログラマブルプロセッサのための機械命令を含み、高レベル手続き型言語、オブジェクト指向プログラミング言語、関数型プログラミング言語、論理プログラミング言語、および／または、アセンブリ／機械語で実装され得る。本明細書中に用いられるように、「機械可読媒体」という用語は、任意のコンピュータプログラム製品、装置および／またはデバイスを指し、例えば、磁気ディスク、光学ディスク、メモリ、およびプログラマブル論理デバイス（ＰＬＤ）であり、それらは、機械命令および／またはデータをプログラマブルプロセッサへ提供するために用いられる。また、機械可読媒体には、機械命令を機械可読信号として受信するものも含む。「機械可読信号」という用語は、機械命令および／またはデータをプログラマブルプロセッサへ提供するために用いられる任意の信号を指す。機械可読媒体は、このような機械命令を非一時的に保存し得る。例えば、非一時的な固体メモリまたは磁気ハードドライブまたは任意の等価な保存媒体と同様にである。代替的にまたは追加的に、機械可読媒体は、例えば１つ以上の物理的なプロセッサコアと関連付けられたプロセッサキャッシュまたは他のランダムアクセスメモリと同様に、このような機械命令を一時的に保存し得る。
【００４６】
ユーザとの相互作用を提供するため、本明細書中に記載される本発明は、表示デバイス並びにキーボードおよびポインティングデバイスを有するコンピュータにおいて実装され得る。表示デバイスとして、例えば、ユーザへ情報を表示するための陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）モニターがある。キーボードおよびポインティングデバイスとして、マウスまたはトラックボールがあり、それらによって、ユーザはコンピュータへ入力を与えることができる。ユーザとの相互作用を提供するために、他の種類のデバイスも利用可能である。例えば、ユーザへ提供されるフィードバックは、任意の形態の知覚フィードバックであり得、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックである。ユーザからの入力は、任意の形態で受信され、例を非限定的に挙げると、聴覚、会話、または触覚入力である。他の可能な入力デバイスを非限定的に挙げると、タッチスクリーンまたは他のタッチセンサー式デバイスがあり、例えば、単一点のまたは多点型の抵抗または容量性トラックパッド、音声認識ハードウェアおよびソフトウェア、光学スキャナ、光学ポインタ、デジタル画像キャプチャデバイスおよび関連付けられた解釈ソフトウェアなどである。
【００４７】
本明細書中に記載される本発明は、所望の構成に応じてシステム、装置、方法および／または物品として具現化され得る。上記記載において明らかにされた実装は、本明細書中に記載される本発明と矛盾しない全ての実装を示すわけではない。すなわち、それらは、記載された本発明に関連する形態と矛盾しないいくつかの例に過ぎない。上記においてはいくつかの変形例を詳述しているが、他の変形例または追加例も可能である。特に、さらなる特徴および／または変形例を本明細書中に記載のものに加えて提供することができる。例えば、上記した実装は、開示された特徴の多様な組み合わせおよび部分的組み合わせ、および／または、上記に開示されたいくつかのさらなる特徴の組み合わせおよび部分的組み合わせに向けることができる。加えて、添付図面に示されかつ／または本明細書中に記載された論理フローは、所望の結果を達成するために、図示された特定の順序または逐次的順序を必ずしも必要としない。他の実装は、次に述べるクレームの範囲内であろう。
【図１】
0006538646.tif 000002
【図２】
0006538646.tif 000003
【図３】
0006538646.tif 000004
【図４】
0006538646.tif 000005
【図５】
0006538646.tif 000006
【図６】
0006538646.tif 000007