JP6033874B2 - 医療装置更新システム - Google Patents

Description

本開示は、一般に医療装置に関する。より詳細には、本開示は、点滴ポンプなどの医療装置のソフトウェアおよび構成ファイルを更新するための新規なシステムおよび方法に関するものである。

薬剤や他の液体を直接患者の循環系に投与することが望ましい場合には、静脈内点滴治療が処方される。従来の一部の点滴ポンプは、病院がカスタマイズした薬剤ライブラリを備えており、病院で確立された臨床診療の推奨範囲外の投与量または他の構成パラメータを入力またはプログラムしようとする場合に、臨床医に警告する。患者身体に医薬の液体を注入するために、医療関係者により使用される点滴ポンプにはさまざまなタイプがある。上述のとおり、一部のポンプでは、電子的にダウンロード可能な薬剤ポンプのためにカスタマイズされた薬剤ライブラリを使用する。例えば、米国特許出願公開第２００７／０２１３５９８号明細書では、薬剤情報を維持し、薬剤送達装置と通信するシステムが記述されており、この特許の内容全体は参照によって本明細書に引用したものとする。カスタマイズされた薬剤ライブラリを更新することに加えて、通常、点滴ポンプなどの医療装置で実行しているソフトウェアを更新することも望ましい。しかし、従来の技術には、いくつかの欠点がある。以下は、従来技術に見られるさまざまな問題を解決する新規な医療装置更新システムの説明である。

米国特許出願公開第２００７／０２１３５９８号明細書

薬剤投与装置に更新を提供するための方法が記述されており、当該方法には、薬剤投与装置へのメッセージの送信、当該メッセージは薬剤投与装置で使用可能な１つ以上の更新ファイルに関係する情報を含み、薬剤投与装置でのメッセージの受信、メッセージによって識別される１つ以上の更新ファイルのダウンロードおよび保存、ならびに薬剤投与装置での１つ以上の更新ファイルのインストールが含まれる。

別の例では、サーバー、通信ネットワーク、および通信ネットワークを介してサーバーと通信する複数の医療装置を含む医療装置システムが提供されており、複数の医療装置はそれぞれ保存場所および医療装置の動作を制御するための制御ユニットを有し、制御ユニットはサーバーから受信される更新メッセージに応じて更新ファイルをプルするように構成され、制御ユニットはダウンロードされた更新ファイルのインストールを管理するように構成されている。

本開示の他の特徴および利点は、添付図面および以下の詳細な説明から明らかになるであろう。

本開示は、例示的な形で図示されており、添付図面の各図に限定するものではなく、同じ参照番号は同一の要素を示している。

病院環境での医療装置を図示するブロック図である。 医療装置を更新するプロセスの一例を図示する流れ図である。 「プッシュ」更新技術を使用する更新システムのブロック図である。 「プル」更新技術を使用する更新システムのブロック図である。 病院ネットワークの高レベルビューを示すブロック図である。 更新プロセスの一例を図示するシーケンス図である。 インストールの前に新しい２つの更新がダウンロードされるプロセスを示すタイミング図である。 試みられた更新の前後の医療装置の状態を図示する図および流れ図である。 リムーバブルＵＳＢフラッシュドライブを使用した、更新プロセスのための高レベルメッセージの処理およびアクションの一例を図示するシーケンス図である。 点滴ポンプシステムのブロック図である。 点滴装置の物理的／サブシステムのブロック図である。 点滴ポンプシステムアーキテクチャのブロック図である。 ライブラリのダウンロード、転送、およびインストールのための交換を示すシーケンス図である。 ライブラリおよびソフトウェアのダウンロード、転送、およびインストールのための交換を示すシーケンス図である。 試みられた更新の前後の注入器の状態を図示する図および流れ図である。 ユーザーの視点からの薬剤ライブラリおよびソフトウェアの更新のためのプロセスを図示する図である。 ユーザーの視点からの薬剤ライブラリおよびソフトウェアの更新のためのプロセスを図示する図である。 ユーザーの視点からの薬剤ライブラリおよびソフトウェアの更新のためのプロセスを図示する図である。 ユーザーの視点からの薬剤ライブラリおよびソフトウェアの更新のためのプロセスを図示する図である。 ソフトウェアおよび薬剤ライブラリの更新ならびに更新される装置を選択するためにユーザーにより使用される例示的な選択ウィザードのスクリーンショットである。

全般に、本開示では、医療点滴装置または点滴ポンプのような薬剤投与装置などの医療装置または医療装置システムに更新を提供するためのシステムおよび方法を記述している。性能の向上、問題への対処、機能の追加、あるいは医療装置の動作の変更を行うために、医療装置で実行しているソフトウェアを更新することが望ましい場合がある。カスタマイズされた薬剤ライブラリを使用する医療装置ではさらに、薬剤ライブラリも更新することが望ましい場合がある。一例では、ソフトウェアおよび構成の更新は、サーバーにより「プッシュ」されるのではなく、医療装置により「プル」される（以下で詳細に記述される）。

以下で記述されるシステムおよび方法は望ましい任意の医療装置に適用されることが可能であるが、システムおよび方法は点滴ポンプの例示的状況として記述される。例えば、開示される技術は、イリノイ州レークフォレストのＨｏｓｐｉｒａ，Ｉｎｃ．から市販されているＰＬＵＭ Ａ＋（ＴＭ）注入器またはポンプなどの点滴ポンプに使用されることができる。本開示は、他のタイプのポンプも使用されることができる。例えば、本技術は患者管理無痛法（ＰＣＡ）ポンプ、歩行型ポンプ、経腸ポンプのほか、ＩＶ点滴ポンプに使用されることができる。人口呼吸器、画像システム、患者の生理状態モニター、グルコースメーター、診断装置などの他の医療装置に対する本発明の適用も意図されている。

医療装置を更新するためにシステムを構成する場合、多数の要因が考慮される必要がある。例えば、臨床現場に配置される医療装置のソフトウェアおよび構成に対する更新が、タイムリーおよび調整された形で達成するのが困難な場合がある。時間および作業あたりのコストがかなりで、さらに、交互の更新プロセスが実装され、異なる構成およびソフトウェアが併行して動作している場合、別の２つの同一の医療装置が異なる形で動作または運転される可能性があるという混乱状況が発生する場合もある。

配置された医療装置で行われる更新プロセスには通常、２つのタイプがある。これら２つのタイプの更新プロセスには、医療装置の動作ソフトウェアの更新および装置構成の更新が含まれる。点滴ポンプの例の場合、装置構成に対する更新には、カスタマイズされた薬剤ライブラリの更新を含めることができ、これには限定されるわけではないが、投与量、速度、および数量などの許容可能なポンプの構成パラメータのデフォルト、範囲（ハードおよび／またはソフトの限度）、装置固有の設定、モニターされる値の許容可能な範囲などを含めることができる。

臨床現場に配置される医療装置のソフトウェアを更新する作業には従来、医療装置が臨床フロアから物理的に取り外され、生物医学センター（ポンプが洗浄され、補修される場所）などの特別に用意された場所に移動される必要がある。フロアから取り外されると、装置には特別な構成が必要な場合や装置が更新プロセスに備えてメーカー技術者により一部が分解される場合がある。次いで、生物医学センターの特別な更新ステーションを使用して、技術者によりソフトウェアの更新が適用される。次いで、分解が必要とされた更新された装置はメーカーの技術者により組み立てられる。必要に応じて、装置は、更新が正常であることの確認が可能なように特別に構成されることができる。更新が確認されると、装置は通常、病院の生物医学の技術者によって、臨床フロア用に再構成される。装置はさらに、洗浄され、更新プロセスが完了する。これで、装置が臨床フロアに戻される準備が完了する。

上述の更新プロセスには通常、装置ごとに１時間以上かかり、特別なプログラミングステーションで費やされる時間など、手作業によるステップの数と機械によるステップが限定されるために十分には拡大しない。例えば、そのようなプロセスを使用して、何千もの装置を備える病院で更新するには、かなりの時間と労力がかかる。例えば、２０００の装置を備える病院では更新するのに、およそ１人で一年かかる。

医療装置の構成の更新は通常、医療装置のソフトウェアの更新よりも頻繁に行われる。一例では、装置構成は病院で直接カスタマイズされ、メーカーの技術者との連携または支援なしで、病院により四半期ごと（またはより頻繁）に更新される。当然、構成の更新は、必要に応じて、頻度をより多くまたはより少なく実行されることができる。さらに、構成の更新は、病院職員、メーカーの技術者、または他のユーザーにより実行されることができる。

多くの場合、医療装置がネットワーク化されているならば、医療装置の構成は電子的に更新されることが可能である。一例では、これらの更新を電子的に配備するために使用されるメカニズムは、中央サーバーから更新中の医療装置へわずかなパケットの更新データを「プッシュ」することである。このアプローチの１つの欠点は、このプロセスがサーバーでリソースを非常に集約的に使用するので、通常、例えば、一度におよそ１５の装置などの医療装置の小さなグループに実行する場合にのみ効果的である。一部の例では、更新を装置に転送できるようにするため、生物医学の技術者によって医療装置が臨床フロアから取り外され、特別な状態に配置される。ソフトウェアの更新と同様に、これらの手作業によるステップでは、所定の時間に更新されることができる装置の数が限定される。

プッシュ型の構成更新の例では、病院のＩＴ技術者は、更新される医療装置を手作業で選択することによって、更新プロセスを開始する。次いで、技術者は装置への構成更新の転送の完了を待機してから、他の装置が選択される。一例では、装置への転送時間には約３０分かかる場合があるが、さらに、大規模な構成ファイルの場合には転送時間が１時間を超える可能性がある。さらに一部の例では、このタイプの転送は、何らかの理由で転送に失敗する場合には、装置が正常に受信した構成の数量に関係なく、最初から再び開始する必要がある。このことは、ＩＴ技術者がプロセスをモニターし、完了するのを待ってから、更新する他の医療装置をスケジュールする必要があるので、ＩＴ技術者にとって長くて退屈な配備時間となり、ＩＴ技術者の利用効率も悪くなる。医療装置では、構成の更新を受け入れるために装置を特定のモードにするなど、生物医学の技術者との連携や支援を必要とするので、生物医学の技術者のアクションは、ＩＴ技術者と同期する必要があり、病院資源の別の流出である。

上述のとおり、本開示ではさらに、サーバーからの更新をブッシュするのではなく、医療装置で更新をプルすることによって、点滴ポンプなどの医療装置に更新を提供するためのシステムおよび方法を記述している。このアプローチでは、ソフトウェアおよび構成の更新の間、医療装置が臨床フロアにとどまるようにすることができる。この形で実行される更新は医療装置自体によりインストールされるので、メーカーの技術者によっても、病院の生物医学の技術者によっても、分解、手作業によるプログラミング、または他の特別な取り扱いの必要がなくなる。この例では、更新は病院のネットワーキングインフラストラクチャを使用して医療装置に転送される。一部の例ではさらに、医療装置での更新のインストールは、看護師または他の病院職員などのユーザーによって起動される。

図１は、病院環境での医療装置を図示するブロック図である。図１に示されているように、医療装置１０（例えば、点滴装置）およびリモートサーバー１２は、コンピュータネットワークで結合され、サーバーおよび医療装置は互いに通信することができる。サーバー１２は必要に応じて、病院、病院から離れた場所、メーカーの施設、別の病院、または他のどこかに配置されることができる。医療装置１０にはユーザーインターフェース１４が含まれ、ユーザー（医師、看護師、技術者、患者など）は医療装置１０のモニターおよび／または操作を行うことができる。ユーザーインターフェースには、ディスプレイ、キーパッド、タッチスクリーン、ボタンおよびノブ、オーディオインジケータなどが含まれる場合がある。さらに、以下で詳細に記述されるとおり、サーバー１２からの更新は、ネットワークを使用するのではなく物理的記憶媒体（リムーバブルＵＳＢフラッシュドライブなど）を使用して医療装置に転送される場合もあることに留意していただきたい。さらに、さまざまな通信ネットワーキング方法が、利用可能なネットワーキングインフラストラクチャに応じて、転送を成し遂げるために使用されることが可能で、例えば、イーサーネット、Ｗｉ−Ｆｉ、および携帯電話ネットワークはすべて、この目的のために使用されることが可能である。

図１はさらに、医療装置１０のいくつかのサブシステムを示している。通信サブシステム１６は、医療装置１０とサーバー１２間のほか、医療装置１０と他の装置間の通信を円滑化する。アプリケーションサブシステム１８は、医療装置１０のほか、ユーザーインターフェース１４の動作も制御する。医療装置１０はさらに、複数の記憶場所も有している（以下に記述）。図１の例では、第１のフラッシュ記憶場所２０は、更新がインストールされるまで更新をキャッシュする。第２のフラッシュ記憶場所２２は、インストールされたソフトウェアおよび構成ファイルを保存する。第１および第２のフラッシュ記憶場所２０および２２の動作は、以下で詳細に記述されるが、一般的に、更新がダウンロードされるときに、キャッシュされ、後でインストールされる。同時に、現在のソフトウェアおよび構成ファイルがキャッシュされ、更新に失敗した場合に、システムで使用可能にする。このようにして、医療装置は、更新を試みた前の動作状態に戻ることができる。さらに、上述のような記憶場所は、単なる例に過ぎないことにも留意していただきたい。記憶場所は、より多くまたはより少なく使用されることができる。フラッシュメモリーに加えて、さらに任意の望ましいタイプの記憶媒体も使用されることが可能である。例えば、記憶場所には、ハードドライブ、ソリッドステートドライブ、または他の任意のタイプの不揮発性メモリーを使用することができる。

図２は、医療装置を更新するプロセスの動作の一例を図示する流れ図である。更新プロセスは一般的に、更新されるものが医療装置のソフトウェアでも、構成でも同じである。

図２で図示しているプロセスは、ステップ２−１０で、更新される医療装置を選択する病院のＩＴ技術者（または他のユーザー）から開始する。選択プロセスの例は、以下でより詳細に記述される。医療装置が選択された後、サーバーはネットワークを介して更新メッセージ（一例では、単一メッセージ）を選択されたセットの医療装置の中の選択された医療装置のそれぞれに送信する（ステップ２−１２）。一例では、各医療装置は固有のメッセージを受信する。他の例では、同じメッセージが各装置に送信されることができ、各装置は特定の装置に関連した情報を構文解釈することができる。ネットワークにアクティブに接続されていない装置は、サーバーが装置と通信を再確立したときに、更新メッセージを受信する。一例では、更新メッセージには、医療装置が更新をダウンロードしてインストールする必要のある更新についての情報が含まれている。例えば、更新メッセージにより、更新を構成するファイルのほか、ネットワーク上のファイルの場所も識別することができる。このことの１つの理由はスケーリング問題を除去するためであり、そうではない場合には、サーバーがアプリケーションレベルで装置への更新のセグメント化および転送を管理しなければならなくなる可能性がある。

ステップ２−１４で、プロセスにより更新メッセージが通信サブシステムで受信されたかどうかが判定される。更新メッセージが受信されていない場合、プロセスはメッセージを待機し続ける。更新メッセージが受信されている場合には、プロセスが続行される。この時点では、医療装置は各装置に対して直接、アプリケーションレベルのインターフェースではなく、ネットワーキングオペレーティングシステムレベルのインターフェースを使用して更新のファイルのダウンロードを担当するようになる。これによって、作業負荷が（サーバー上の負荷ではなく）装置に分配され、ネットワーク接続が失われた時点から再確立されるまで、更新ファイルの転送が再開できるようになるというさらなる利点がある。継続的なダウンロードがプロセスをもう一度やり直すことなく達成されることができる。

ステップ２−１６で、受信された更新メッセージで識別された更新が医療装置によってダウンロードまたはプルされる。ステップ２−１８で、プロセスにより、ダウンロードされた更新が確認されたかどうかが判定される。一例では、ダウンロードされた更新は、チェックサムを使用するか、他の任意の望ましい確認方法により確認されることができる。ダウンロードされた更新ファイルが確認されることが不可能な場合、プロセスは、更新が再度ダウンロードされる、ステップ２−１６に後退する。前述のとおり、ダウンロードプロセスは、中止した箇所で継続でき、ダウンロードプロセス全体が再開される必要はない。更新が正常に転送されていると確認されると、更新ファイルは、インストールプロセスにより必要になるまで、通信サブシステムによって記憶場所に保存される（ステップ２−２０）。一例では、この時点で、医療装置はインストールプロセスを開始するため、ユーザー（例えば、看護師、介護人、または患者など）からの合図を待機する。

更新ファイルがダウンロード、確認、および保存された後、通信サブシステムは更新が使用可能であるという信号をアプリケーションサブシステムに送る。この時点で、システムは、更新ファイルがインストールできるようになるまで待機する。一例では、更新は装置の電源オフのプロセスの間に実行されることができる。この例では、ユーザー（看護師、介護人、または患者）が医療装置の電源をオフにすると、ユーザーインターフェースは、更新（ソフトウェア、構成、または両方）が通信サブシステムにキャッシュされているという情報によってユーザーをプロンプトし（ステップ２−２２）、これでインストールされることができるようになる。次に、プロセスはステップ２−２４に進み、ここでは、プロセスによりユーザーが更新を受け入れるか、または更新を拒否するかどうかが判別される。ユーザーが更新を受け入れる場合、インストールプロセス（ステップ２−２６）が自動的に開始される。更新が完了すると、装置は通常どおりシャットダウンされる（ステップ２−２８）。ステップ２−２４で、ユーザーが更新を拒否する場合、医療装置は、更新をインストールすることなく、通常どおりシャットダウンされる。ユーザーインターフェースは、受け入れられるまで、使用可能な更新をユーザーに通知し続ける。上述の更新プロセス全体で、更新プロセスのステータス（例えば、更新メッセージが受信された、更新がダウンロードされた、更新がインストールされた、更新に失敗したなど）は、通信サブシステムによりサーバーに送信される。このようにして、サーバーは、システムの各医療装置の場合のステータスを追跡することができる。医療装置がサーバーと通信できない場合、装置は、将来の後刻に通信が確立されたとき、サーバーにステータスを通知する。同様のステータスメッセージは、医療装置のユーザーインターフェースにも表示されることができる。

さらに、一例では、ステップ２−１０から２−２０がバックグラウンドで実行されることができ、同時に、医療装置は通常の形で動作することに留意していただきたい。その結果、装置は、更新ファイルをダウンロードしてキャッシュするために、臨床フロアから取り外されたり、特別な更新モードに配置されたりする必要がなくなる。点滴ポンプの例では、更新は、点滴ポンプの通常の動作に影響することなく、点滴ポンプが患者への薬剤の投与に使用されると同時に、ダウンロードされ保存されることができる。さらに、図２で図示されているプロセスは、単一の医療装置の状況で記述されていることに留意していただきたい。しかし、更新システムは、更新を装置の多くに同時に実施するために同じプロセスを使用することができる。

次は、例示的な更新プロセスのより詳細な記述である。当然、更新は、本開示の範囲内で多数の方法により実行されることができる。

上述のとおり、更新プロセスの初期ステップは、更新する１つ以上の医療装置を選択することである。装置は、個別またはグループ、装置タイプに基づくセットまたはサブセット、装置モデル、装置の場所などで選択されることができる。この機能の一例示的実装形態では、ウィザードベースの選択メカニズム（以下に記述）が提供され、任意の数の装置が更新のために選択されることができる。ウィザードは、サーバー上で、またはサーバーと通信するネットワーククライアント上で実行可能である。更新プロセスが起動されると、進行するにつれ、更新のステータスがサーバーまたはネットワーククライアントのユーザーインターフェースを使用して表示され、表示または標準的なレポートでの使用のために利用することができる。

図２に図示されている更新プロセスの一利点は、スケーラビリティに関係する。上述のとおり、装置更新システムが拡大されると、サーバー上の負荷が処理しきれなくなり、装置がタイムリーで、コスト効率が良い形で更新されることができなくなる。図２の「プル」更新プロセスを活用することによって、更新プロセスはサーバーの処理能力を上回ることなく、簡単に拡大されることができる。上述の「プッシュ」技術と図２に図示している「プル」技術との相違を理解できるようにするため、各技術の短い説明が以下で提供される。

図３は、「プッシュ」更新技術を使用する更新システムのブロック図である。図３では、サーバー１２、およびネットワークを介してサーバー１２と通信することが可能な複数の医療装置１０を示している。装置１０が更新のために選択されると、サーバー１２はソフトウェアまたは構成ファイルを複数のチャンク３０にセグメント化し、第１のチャンク３０によりチェックサムを計算し、それは、破損やエラーなしにチャンク３０の転送が完了したことを確認するために、それぞれの装置１２によって後で使用される。サーバー１２は、ネットワークを通して装置１２への接続をオープンにして維持する。更新プロセスの間、チャンク３０のそれぞれは、個別にそれぞれの装置１０に送信される。サーバー１２は各チャンクの配信ステータスをモニターする。

装置１０は各チャンク３０を受信して検証し、配信の正常終了または配信の失敗メッセージをサーバー１２に送信する。次いで、サーバー１２はチェックサムを準備して、次のチェックサム３０を送信する。このプロセスは、更新ファイル全体が正常に転送されるか、失敗するまで繰り返される。この技術の障害回復は、第１のチャンクから初めてダウンロードをやり直すことである。

図３で示されている例を使用して、医療装置にプッシュされるファイルをセグメント化および追跡するためのサーバー１２上の負荷は極めて高く、直ぐにサーバー１２が飽和状態になる場合がある。その結果、おそらく、更新されていない装置にサービスを提供するために妥当なリソースを維持するため、同時に更新できるのは、ほんの数個の装置に過ぎなくなる。例えば、サーバーは装置からステータスおよびログ情報を受信し、装置に治療プログラミング情報を通信し、それらの活動で妨げられる。

図４は、図２に関して記述されているような、「プル」更新技術を使用する更新システムのブロック図である。図４では、サーバー１２、およびネットワークを介してサーバー１２と通信することが可能な複数の医療装置１０を示している。この方法を使用して、図３で図示されている方法と比較すると、サーバー１２は更新される各医療装置１０に、更新メッセージを送信し、それには、マニフェストと呼ばれる、更新を構成するファイルの場所が含まれている。この時点から、医療装置自体が更新ファイルのダウンロードを担当する。この結果、アプリケーション層でサーバー１２が担当する作業量が大幅に削減される。この直接の結果は、システムリソース、主に、ネットワークの帯域幅を限度とした、更新システムの線形スケーラビリティである。

更新ファイルの転送に失敗した場合、装置１０は自動的に、ダウンロードをもう一度やり直すのではなく、失敗した時点からの転送を再び始める。この例では、装置１０は転送のステータスをサーバー１２に通知する。このメッセージ交換は、サーバー１２上に軽微な負荷をもたらすのみで、更新されていない装置の上述の必要性にサービスを提供するためサーバー１２が空けられる。

この技術に関する追加の改善点は、マニフェストにチェックサムおよびバージョン情報が含まれる点である。したがって、装置１０に既に存在するファイルは再度転送されない。これによって、ネットワークの利用およびシステム性能が向上する。同じ技術がソフトウェアの更新のほか、構成の更新にも使用されることに留意していただきたい。

上述の更新メカニズムは、医療設備の有線および無線インフラストラクチャをサポートする。図５は、更新を受信する医療装置への有線と無線接続の両方を含む、病院ネットワークの高レベルビューを示すブロック図である。図５では、ネットワークとの無線インターフェースを有する複数の医療装置１０Ａと通信するための無線ルーター３２と結合しているサーバー１２を示している。サーバー１２はさらに、ネットワークとの有線インターフェースを有する複数の医療装置１０Ｂと通信するために有線ネットワークルーター３４と結合している。示されているネットワーク構成は単なる例であり、他のネットワーク構成も使用されることができることに留意していただきたい。また以下で記述するように、医療装置はさらに、リムーバブルディスクまたはＵＳＢフラッシュドライブなどの物理的記憶媒体を使用しても更新ファイルを受信することができる。

図６は、上述の更新プロセスのための高レベルメッセージの処理およびアクションの一例を図示するシーケンス図である。図６では、サーバー１２および図１に関して上述された医療装置１０（通信サブシステム１６およびアプリケーションサブシステム１８を含む）を示している。図６ではさらに、プロセスの第１のユーザー（病院のＩＴ職員として示されている）および第２のユーザー（看護師、介護人、または患者として示されている）のアクションも図示している。

示されているように、第１のユーザーは更新（ソフトウェアおよび／または構成の更新）される１つ以上の装置を選択する。それに応じて、サーバー１２は医療装置１０に対する更新メッセージを生成し送信する。更新メッセージには、更新ファイルのネットワークの場所が含まれている。通信サブシステム１６は更新メッセージを受信し、それに応じて、更新ファイルをダウンロードする（更新のマニフェストに照らして既に有しているすべてのファイルをチェックする）。ファイルがダウンロードされ、正常に転送されていることが検証されると、通信サブシステムは装置１０にファイルをキャッシュするためにファイルをローカルフラッシュ記憶装置に書き込み、ユーザーが更新プロセスを開始するときを待機する。更新ファイルのすべてがキャッシュされると、通信サブシステム１６は、メッセージをアプリケーションサブシステム１８に送信し、更新が使用可能であることを示す。

医療装置の通常のシャットダウンの間に、アプリケーションサブシステム１８はユーザー（この例では看護師）に更新がインストールされる必要があるかどうかを照会する。ユーザーが受け入れる場合、更新がインストールされ、医療装置１０はシャットダウンされる。更新プロセスの間、医療装置はサーバー１２に、更新プロセスのステータス（例えば、ファイルが正常にダウンロードされた、ダウンロードに失敗した、更新が完了、更新に失敗など）を示す、ステータスメッセージを提供する。

図１に関し上述のとおり、医療装置１０にはさらに、更新ならびにインストールされたファイルおよび構成ファイルをキャッシュするための第１および第２のフラッシュ記憶場所２０および２２がある。一例では、記憶場所は次のように利用されることができる。

更新がダウンロードされ、ファイルがキャッシュされた後、通信サブシステム１６は、アプリケーションサブシステム１８に更新の使用可能性を通知する。そのようなものとして、更新がアプリケーションサブシステム１８に転送されない間にはウィンドウがある。ウィンドウの間に、新しい更新（すなわち、新しい第２の更新）が通信サブシステム１６に転送される場合、さらに検証され、保存される必要がある。このプロセスが完了するまで、以前の更新がアクティブな更新と見なされ、更新がユーザーによって要求される場合、これがアプリケーションサブシステム１８に送信される。

しかし、新しい更新（新しい第２の更新）が正常にサーバーから転送され、代替のキャッシュ場所に書き込まれると、この新しい更新（新しい第２の更新）がアクティブな更新になり、更新がユーザーによって要求される場合に、これがアプリケーションサブシステムに送信される。

図７は、このプロセス（ここでは、２つの新しい更新がダウンロードされる）を示すタイミング図である。図７では、通信サブシステム１６および３つの異なる時間期間（Ｔ１、Ｔ２、およびＴ３）での記憶場所２０を示している。記憶場所２０には、２つのパーティション（キャッシュ場所２０Ａおよび２０Ｂ）が含まれる。Ｔ１の時点で、第１の更新がダウンロードされ、記憶場所２０Ａに保存される。Ｔ１の時点で、この更新がアクティブな更新と見なされ、つまり、Ｔ１の時点で更新要求がユーザーからもたらされる場合、それがインストールされる更新である。

Ｔ２の時点で、第１の更新はなおキャッシュされるが、更新をインストールするためのユーザーからの要求はまだない。同時に、より新しい更新（新しい第２の更新）がこの時に、記憶場所２０Ｂにダウンロードされている。Ｔ２の時点で、第１の更新（キャッシュ２０Ａに保存されているもの）がなおアクティブな更新と見なされ、つまり、Ｔ２の時点で更新要求がユーザーからもたらされる場合、それがインストールされる更新である。

Ｔ３の時点で、新しい第２の更新のダウンロードが終了し、検証され記憶場所２０Ｂに保存される。ここで、この更新が最新なので、この更新がアクティブな更新と見なされ、以前のアンインストールされた更新に取って代わる。時間Ｔ３の後に、更新要求がユーザーからもたらされる場合には、第２の更新（記憶場所２０Ｂに保存されている）がインストールされる更新となる。このような状態はまれではあるが、可能性のある状況である。

医療装置の継続的かつ適切な動作を確保するため、予防処置が講じられ、医療装置の適切な動作ソフトウェアおよび／または構成を維持する必要がある。例えば、一部の医療装置は適切な構成なしでは動作できない。この場合、構成の更新のインストールが失敗するときには、特別な配慮が行われ、以前の構成を保存することができる（引き続き、許容可能な場合）。一例では、更新が通信サブシステムから転送される場合、正常に受信され、フラッシュに記録されるまで、以前の構成が有効なままである。

新しく更新された構成がフラッシュに記録されたなら、前の構成が無効化され、以前の構成になり、この場所に新しい次の構成が書き込まれる。新しい構成の受信に失敗する場合、または新しい構成のフラッシュへの書き込みに失敗する場合には、アクティブなパーティションは変わりなくそのままである。受信および書き込みが正常に行われる場合には、新しい構成がアクティブな構成になる。

図８は、更新の前後の医療装置の状態を図示する図および流れ図である。図８の左の部分では、初期状態の医療装置を示している。初期状態（左側）では、２つの構成、アクティブな構成（記憶場所２２Ａに保存されている）および以前の構成（記憶場所２２Ｂに保存されている）がキャッシュされている。新しい構成のインストールが正常に行われた場合（図８の右側）、新しい構成がアクティブな構成になり、前の構成が無効化され、以前の構成になる（ここには新しい次の構成が書き込まれる）。新しい構成のインストールに失敗した場合には、アクティブなパーティションは変わりなくそのままである。

一例では、更新の処理は、更新メッセージに含まれるスクリプトに従う。通信サブシステムでは、スクリプトを使用して、追従されるプロセスおよびシーケンスを調整する。例えば、スクリプトでは最初に更新されるシステムの部分および更新される方法を命令する場合がある。さらにシステムでは、不測の問題に対処するために更新プロセスにある程度の柔軟性も提供する場合がある。

一例では、スクリプト処理は、ユーザーに更新を実行しないまたは保留するオプションを提供することなく、電源をオフにする間に更新の処理を行うために使用されることができる。言い換えれば、ユーザーの承認は不必要なのである。このことは、更新が非常に重要な状態、または更新が医療装置に関する知られている問題を修正する場合には有用なことがある。

別の例では、スクリプト処理は、更新が特定の時までに装置に展開されるようにし、それによって、すべての更新がその前ではなく、将来の特定の時の後に使用可能にするために使用されることができる。別の例では、スクリプト処理は、更新が特定の日付および／または時間までに、あるいは特定の日付および／または時間にインストールされることを確保するために使用されることができる。スクリプト処理はさらに、必要に応じて、他の多数の機能のために使用されることができる。

医療装置の適切な動作は非常に重要なので、更新が安全に実行されることを確保するためにいくつかの対策が講じられる必要がある。更新ファイルの安全性は、医療装置が転送後にファイルを復号化することができるような方法で、更新ファイルを暗号化することによって確実にされる。しかし、更新ファイルが転送中に妨害される場合、更新のデータを表示することは不可能になる。望ましい従来の任意の暗号化方法が使用されることができる。

暗号化メカニズムによりさらに、更新ファイルが妨害される場合、それが変更され、次いで有効な更新として医療装置に再実行されることができないことが確実になる。試みられる場合、装置は無効なファイルとして更新を拒否する。転送される更新に対する最も基本的なレベルの整合性チェックとして、適切に暗号化されたファイルのみが医療装置により受け入れられる。

上述のとおり、ソフトウェアおよび構成の更新のための基本的メカニズムの他の例では、病院のネットワークインフラストラクチャを活用するのではなく、更新の移植のための物理的装置に拡張される。望ましい任意の物理的装置が使用されることができるが、ＵＳＢフラッシュディスクを使用した例が記述される。この例では、サーバーは、更新ファイルおよび関連スクリプトを含むＵＳＢフラッシュディスク上で更新を作成し、保存する。ＵＳＢフラッシュドライブが更新される装置に挿入されると、通信サブシステムは、更新がちょうどネットワークインフラストラクチャを通して転送されるかのように、ＵＳＢインターフェースから更新ファイルをコピーする。

医療装置がネットワーク化されている場合、ネットワークで配信された更新のように動作し続け、発生するたびに更新のステータスをレポートする。図９は、更新を転送するためにＵＳＢフラッシュディスクを使用した、更新プロセスのための高レベルメッセージの処理およびアクションの一例を図示するシーケンス図である。図９では、サーバー１２および図１に関して上述された医療装置１０（通信サブシステム１６およびアプリケーションサブシステム１８を含む）を示している。図９ではさらに、プロセスの第１のユーザー（病院のＩＴ職員として示されている）および第２のユーザー（看護師として示されている）のアクションも図示している。

示されているように、第１のユーザーは更新（ソフトウェアおよび／または構成の更新）される装置または装置のタイプを選択する。それに応じて、サーバーは更新およびスクリプトを含むＵＳＢフラッシュディスクを生成する。医療装置１０で、ユーザーはＵＳＢディスクを装置１０のＵＳＢポートに挿入する。この時点で、スクリプトが引き継ぎ、更新は通信サブシステム１６によってコピーされる。ファイルがフラッシュディスクからコピーされ検証されると、更新ファイルはキャッシュに保存され、第２のユーザーが更新プロセスを開始するときを待機する。更新ファイルがキャッシュされると、通信サブシステム１６は、メッセージをアプリケーションサブシステム１８に送信し、更新が使用可能であることを示す。

医療装置１０の通常のシャットダウンの間に、アプリケーションサブシステム１８はユーザー（この例では看護師）に更新がインストールされる必要があるかどうかを照会する。看護師が受け入れる場合、更新がインストールされてから、医療装置１０はシャットダウンされる。更新プロセスの間、医療装置はサーバー１２（装置１０がネットワーク化されていると想定する）に、更新プロセスのステータス（例えば、ファイルが正常にダウンロードされた、ダウンロードに失敗した、更新が完了、更新に失敗など）を示す、ステータスメッセージを提供する。医療装置１０がネットワーク化されていない場合、ステータスメッセージは、次回、装置がネットワークに接続される際にサーバーに送信される。

医療装置更新システムの上記の説明は、一般用語で記述されており、一部のより特定の例も含まれている。次は、特定の医療装置システムでの例示的実装形態を例証する説明である。次の説明では、病院環境のネットワークシステムを通して協働するＰｌｕｍ Ａ＋（ＴＭ）点滴ポンプとＨｏｓｐｉｒａ ＭｅｄＮｅｔ（ＴＭ）に基づくシステムを記述している。Ｐｌｕｍ Ａ＋（ＴＭ）点滴ポンプとＨｏｓｐｉｒａ ＭｅｄＮｅｔ（ＴＭ）ソフトウェアは、イリノイ州レークフォレストのＨｏｓｐｉｒａ，Ｉｎｃ．から市販されており、本発明に従って適合または変更されることができる。

点滴ポンプシステムは、薬剤ライブラリおよび点滴ポンプのソフトウェアを電子的に配信して、インストールするために備えられている。ソフトウェアのインストールは、薬剤ライブラリのダウンロードおよびインストールプロセスと一体化されている。以下で記述されているものは、正常終了と失敗したインストールの両方を含む、ソフトウェアおよび薬剤ライブラリのインストール中に発生する表示画面およびアクションを表している。シーケンス図では、さまざまなシステムとの相互作用および連動を高レベルで示している。

図１０は、点滴ポンプシステムのブロック図である。図１０では、コンピュータネットワークにより結合された点滴ポンプ１１０（すなわち、注入器）およびＨｏｓｐｉｒａ ＭｅｄＮｅｔ（ＴＭ）サーバー１１２またはＨＭＳＳを示しており、サーバーと点滴ポンプは互いに通信することができる。点滴ポンプ１１０にはユーザーインターフェース１１４が含まれ、看護師または他のユーザーが点滴ポンプ１１０のモニターおよび／または操作を行うことができる。点滴ポンプ１１０には、示されているように、通信サブシステム１１６（すなわち、通信エンジン）およびアプリケーションサブシステム１１８（すなわち、ＭＣＵ（マスター制御ユニット））が含まれる。通信サブシステム１１６は、インストール時まで更新をキャッシュするためにフラッシュ記憶装置１２０にアクセスできる。アプリケーションサブシステム１１８は、インストールされたソフトウェアおよび構成ファイルを保存するためにフラッシュ記憶装置１２２にアクセスできる。

図１１は、点滴ポンプ通信サブシステム１１６およびアプリケーションサブシステム１１８の一部の機能の物理的配置を図示する点滴装置の物理的／サブシステムブロック図である。どちらのサブシステムもＲＡＭおよびフラッシュメモリーにアクセスできる。通信サブシステム１１６には、外部システム（有線および無線）へのインターフェースが含まれる。アプリケーションサブシステム１１８のＭＣＵは、ＣＰＵを含み、さらに、ポンプアクションの制御のほか、ユーザーインターフェース装置も備えている。

図１２は、点滴ポンプシステムのアーキテクチャブロック図である。図１２には、サーバー１１２との通信インターフェースを提供する通信サブシステム１１６を含む点滴ポンプ１１０、および病院のナースコールシステムが示されている。点滴ポンプ１１０にはさらに、メカニカルサブシステム、電源サブシステム、ならびにディスプレイおよび点滴サブシステム（ＭＣＵの一部）も含まれる。

上述の例に同様に、図１０〜図１２に図示されている点滴ポンプシステムは、点滴ポンプソフトウェアおよび薬剤ライブラリへの更新を処理することができる。通信サブシステム１１６がサーバー１１２からの更新要求を受信する場合、受信されたメッセージには更新を構成するファイルのマニフェストが含まれる。この例では、更新は薬剤ライブラリまたはソフトウェアおよび薬剤ライブラリ向けである。

ほとんどの場合、ソフトウェアの更新は新しいカスタムライブラリとともにもたらされる。この場合、新しいソフトウェアの更新が提供される場合、更新には、ソフトウェアの更新および薬剤ライブラリの更新を含む、照合済みセットが含まれる。その理由は、薬剤ライブラリはアプリケーションと密接に関係しており、ソフトウェアの変更は薬剤ライブラリに影響するからである。一部の例では、システムは、薬剤ライブラリエディタ（ＤＬＥ）アプリケーションとともに作成されるカスタム薬剤ライブラリなしの単なるソフトウェアのみの受信を許容しないように構成されている。これはサーバーによって制御される。

受信されたマニフェストにはさらに、更新のファイルのそれぞれへのネットワークの場所（パス）が含まれる。通信サブシステムは、更新ファイルのダウンロード、それらのファイルの検証、およびそれらのファイルの通信サブシステムフラッシュへのローカルでの保存を担当する。次いで、通信サブシステムはＭＣＵに対して、転送およびインストールするカスタム薬剤ライブラリまたはソフトウェアの更新および薬剤ライブラリがあることを通知する。

この例では、通信サブシステムが実行しており、注入器がＡＣ電源に接続されている場合にはサーバーに接続されている可能性があることに留意することは重要である。ＡＣ電源に接続されている間に注入器の電源をオフすることによってのみＭＣＵの電源はオフになる。通信サブシステムは動作を継続し、医療装置の電源がオフにされた場合でも、更新が医療装置に転送され、インストールされるようにすることができる。

保留にされている薬剤ライブラリの更新が通知されると、ユーザーが注入器の電源をオフにしようとするときに、ＭＣＵにより注入器の画面が表示される。この画面では、ユーザーに対して、その時に薬剤ライブラリをインストールする、またはインストールを後刻に延期するかの選択が提供される。ユーザーが薬剤ライブラリのインストールを選択すると、ＡＣ電源のステータスが最初に検証され（インストールの間の電源損失の可能性を低減化するため）、通信サブシステムはデータをＭＣＵに転送する。転送が完了すると、インストールプロセスがオペレータの入力なしに続けられる。

ユーザーが薬剤ライブラリのインストールを選択しない場合、ＭＣＵでは新しい薬剤ライブラリをインストールすることなく電源を切る。ユーザーには、薬剤ライブラリが最終的にインストールされるまで、注入器の電源が切られるたびに、使用可能な薬剤ライブラリの更新があることが継続的に通知される。

インストールに失敗する場合、次に電源がオンになるときに、ユーザーには失敗画面で注意が喚起される。次いで、オペレータは、注入器の電源をオフにしてインストールを再度試みるか、または以前のカスタム薬剤ライブラリで動作を継続することができる。

図１３は、薬剤ライブラリのダウンロード、転送、およびインストールのための交換を示すシーケンス図である。示されているように、Ｈｏｓｐｉｒａ ＭｅｄＮｅｔ（ＴＭ）ユーザーが１つ以上の点滴ポンプのための薬剤ライブラリをアクティブ化する。それに応じて、サーバー１１２は医療装置１０に対する更新メッセージを生成して送信する。通信サブシステム１１６は更新メッセージを受信し、それに応じて、薬剤ライブラリの更新ファイルをダウンロードする（更新のマニフェストに照らして既に有しているすべてのファイルをチェックする）。ファイルがダウンロードされて検証されると、通信サブシステム１１６は、メッセージをアプリケーションサブシステム１１８に送信し、更新が使用可能であることを示す。

注入器のシャットダウンの間、ＭＣＵはユーザーに更新がインストールされる必要があるかどうかを照会する。ユーザーが受け入れる場合、ＭＣＵによりソフトウェア更新イメージに再起動される。次いで、ＭＣＵにより生物医学モードで臨床イメージに再起動される。次いで要求後、薬剤ライブラリが通信サブシステムからＭＣＵに転送され、インストールされる。最終的に、注入器はシャットダウンする。このプロセスの間、注入器はサーバー１１２に、更新プロセスのステータス（例えば、ファイルが正常にダウンロードされた、ダウンロードに失敗した、更新が完了、更新に失敗など）を示す、ステータスメッセージを提供する。

ＭＣＵソフトウェアの更新のプロセスもカスタム薬剤ライブラリのインストールと同様で、オペレータが注入器の電源を切るときに発生するようなものである。その時点で、通信サブシステムは、ソフトウェアおよび／または薬剤ライブラリを受信し、サーバーから送信された情報（チェックサムを含むマニフェストファイル、およびインストールするパッケージのバージョン情報）に照らして検証する。通信サブシステムは、この新しいソフトウェアおよびカスタム薬剤ライブラリを、シリアルインターフェースを通してＭＣＵに通知する。ＭＣＵは、これをＳＥＥＰと呼ばれる特別なメモリーの場所にマークする−図１４のシリアルＥＥＰＲＯＭ）。

注入器の電源が切られると（ユーザーがオン／オフボタンを押すことに基づく）、ＭＣＵにより、ソフトウェアのインストールプロセスを開始することを提示する画面が表示される。

図１４は、ソフトウェアおよびライブラリのダウンロード、転送、およびインストールのための交換を示すシーケンス図である。示されているように、Ｈｏｓｐｉｒａ ＭｅｄＮｅｔ（ＴＭ）ソフトウェアのユーザーが１つ以上の点滴ポンプのための薬剤ライブラリをアクティブ化する。それに応じて、サーバー１１２は医療装置１０に対する更新メッセージを生成し送信する。通信サブシステム１１６は更新メッセージを受信し、それに応じて、ソフトウェアおよび薬剤ライブラリの更新ファイルをダウンロードする（更新のマニフェストに照らして既に有しているすべてのファイルをチェックする）。ファイルがダウンロードされて検証されると、通信サブシステム１１６は、メッセージをアプリケーションサブシステム１１８に送信し、ソフトウェアおよび薬剤ライブラリの更新が使用可能であることを示す。

注入器のシャットダウンの間、ＭＣＵはユーザーに更新がインストールされる必要があるかどうかを照会する。ユーザーが受け入れる場合、ＭＣＵによりソフトウェア更新イメージに再起動される。次いで要求後、ソフトウェアが通信サブシステムからＭＣＵに転送される。次いで、ＭＣＵにより生物医学モードで臨床イメージに再起動される。次いで要求後、薬剤ライブラリが通信サブシステムからＭＣＵに転送され、更新がインストールされる。最終的に、注入器はシャットダウンする。このプロセスの間、注入器はサーバー１１２に、更新プロセスのステータス（例えば、ファイルが正常にダウンロードされた、ダウンロードに失敗した、更新が完了、更新に失敗など）を示す、ステータスメッセージを提供する。

サーバーからのソフトウェア更新パッケージの一部として通信サブシステムのためのソフトウェアの更新がある場合、通信サブシステムの更新が最初にインストールされ、それらからＭＣＵにソフトウェアがインストールされることに留意していただきたい。いずれの場合でも、ソフトウェアの更新パッケージからインストールされる最後のものは、ＭＣＵのためのカスタム薬剤ライブラリである。

図８に関して上述のように、注入器の継続的かつ適切な動作を確保するため、予防処置が講じられ、適切な動作が維持される必要がある。例えば、注入器は適切な構成なしでは動作しない。したがって、構成の更新のインストールが失敗するときには、特別な配慮が行われ、以前の構成を保存することができる。一例では、更新が通信サブシステムから転送される場合、正常に受信され、フラッシュに記録されるまで、以前の構成が有効なままである。

図１５は、更新が試みられた前後の注入器の状態を図示する図および流れ図である。示されているように、ＭＣＵ１１８では、フラッシュメモリーに２つの薬剤ライブラリの場所１２２Ａおよび１２２Ｂを維持する。ＳＥＥＰが、どちらがアクティブなライブラリであるかを制御する。新しいライブラリがＭＣＵにロードされると、以前のアクティブなライブラリがフェイルオーバーオプションとして維持される。新しいソフトウェアがＭＣＵ上にインストールされると、以前のすべてのカスタム薬剤ライブラリはフォーマットが変更されたものとして消去される。新しいソフトウェアのインストールプロセスの一部として、新しいソフトウェアとともにもたられるデフォルトの薬剤ライブラリは、カスタム薬剤ライブラリ（ＣＤＬ）の場所の１つにコピーされ、ＳＥＥＰはアクティブなライブラリとしてのこの情報で更新される。通信サブシステムは、更新パッケージの一部である、カスタム薬剤ライブラリを送信し、ＭＣＵはカスタム薬剤ライブラリを未使用のカスタム薬剤ライブラリのフラッシュの場所に保存し、新しく保存したカスタム薬剤ライブラリをアクティブなＣＤＬとしてＳＥＥＰを更新する。

次いで、後続の更新によって、最も古いライブラリが新しいライブラリで置き換えられ、ＳＥＥＰへの更新により、次に電源を入れる際に、どちらがアクティブなライブラリかが制御される。

カスタム薬剤ライブラリのインストールに失敗する場合、ＳＥＥＰは更新されず、そのため、以前のアクティブな薬剤ライブラリが引き続き、アクティブな薬剤ライブラリになる。ユーザーが次にＭＣＵの電源をオフにすると、薬剤ライブラリのインストール画面が再び、これまたは新しく配信されたいずれかのカスタム薬剤ライブラリをインストールするために提供される。

図１６〜図１９は、装置のユーザーの視点からの薬剤ライブラリおよびソフトウェアの更新のためのプロセスを図示する図である。図１６〜図１９では、ユーザーのエクスペリエンスの重要な地点を提供する段階的な手順を図示し、カスタム薬剤ライブラリのインストールおよびソフトウェアのインストールのほか、更新動作が失敗した場合の障害処理のためにプロセスが実行される際のシーケンスおよび状態情報を示している。

図１６では、薬剤ライブラリのインストールのための注入器の画面の段階的な手順を図示しており、薬剤ライブラリの転送およびインストールプロセス間に発生するステップおよび画面を示している。プロセスは、ユーザーが電源オフのボタンを押すときに開始する。薬剤ライブラリがインストールされる準備が整った場合、画面２００が表示され、ユーザーに更新をインストールすることが照会される。ユーザーが「いいえ」を選択すると、ＭＣＵが電源オフになる。ユーザーが「はい」を選択すると、システムでは注入器がＡＣ電源に接続されているかどうかを検証する。接続されていない場合、ウィンドウ２０２が表示され、ユーザーにユニットをコンセントに差し込むように通知する。次いで、画面２０４が表示され、インストールが開始する。転送が正常に行われると、最も古い薬剤ライブラリが消去され、新しいライブラリがメモリーに書き込まれる。次いで、ＳＥＥＰが正常終了または失敗のいずれかとしてマークされ、ＭＣＵが電源オフにされる。

図１７では、失敗した薬剤ライブラリのインストールのための注入器の画面の段階的な手順を図示している。図１７のスクリーンショットでは、次に電源をオンの処理をした際の、失敗したライブラリのインストールの結果のステップおよび画面を示している。注入器の薬剤ライブラリは、新しい薬剤ライブラリが正常なインストールに失敗する場合、以前のライブラリが使用可能で、ユーザーがインストールを再試行することができるまで使用されるように保存される。しかし、使用可能な以前の薬剤ライブラリがデフォルトの薬剤ライブラリのみの場合には、注入器は使用することができない。このことは、新しいソフトウェアがインストールされ、ソフトウェアの更新の一部としてもたらされるカスタム薬剤ライブラリが正常なインストールに失敗する場合に当てはまる。

プロセスは、ユーザーが電源オンのボタンを押すときに開始し、スプラッシュ画面２１０が表示される。インストールが正常に行われるか、残りのライブラリがデフォルトライブラリのみではない場合に、ユーザーが障害発生画面の「Ｅｎｔｅｒ」ボタンを押すと、次いで、通常の流れの画面（画面２１２、２１４）が表示される。インストールに失敗した後、エラー画面２１６（ユーザーに、以前にインストールした薬剤ライブラリを使用するオプションがある場合）または画面２１８（注入器が動作不可能な場合）が表示される。

図１８では、ソフトウェアのインストールプロセスのための注入器の画面の段階的な手順を図示している。図１８のスクリーンショットでは、インストールプロセスのための処理の結果となるステップおよび画面を示している。失敗する場合、プロセスは正常にインストールされるまで、または試みが３回失敗するまで繰り返される。

ユーザーが電源オフのボタンを押し、インストールされる準備の整ったソフトウェアがある場合には、画面２２０が表示され、ユーザーにソフトウェアをインストールするかを照会する。ユーザーが「いいえ」を選択すると、ＭＣＵが電源オフになる。ユーザーが「はい」を選択すると、システムでは注入器がＡＣ電源に接続されているかどうかを検証する。接続されていない場合、ウィンドウ２２２が表示され、ユーザーにユニットをＡＣ電源に差し込むように通知する。あるいは、別の実施形態では、インストールはバッテリまたはＤＣ電源のみで進めることができる。次いで、画面２２４が表示され、ソフトウェアのインストールが開始され、カスタムライブラリの両方の場所が消去される。ソフトウェアのインストールに失敗すると、失敗がＳＥＥＰメモリーにマークされ、ＭＣＵの電源がオフになる。ソフトウェアのインストールが正常終了すると、画面２２６が表示され、薬剤ライブラリのインストールが開始される。ライブラリのインストールに失敗すると、失敗がＳＥＥＰメモリーにマークされ、ＭＣＵの電源がオフになる。ライブラリの転送が正常に行われると、カスタム薬剤ライブラリがメモリーに書き込まれる。次いで、ＳＥＥＰが正常終了または失敗のいずれかとしてマークされ、ＭＣＵが電源オフにされる。

図１９では、失敗したソフトウェアのインストールのための注入器の画面の段階的な手順を図示している。ユーザーが電源オンのボタンを押した後、スプラッシュ画面２３０が表示される。ソフトウェアのインストールが（この例では）３回失敗すると、画面２３２が表示され、ユーザーはサービスを受けるために、注入器を生物医学センサーに戻すように指示される。ソフトウェアが３回失敗していない場合、ソフトウェアの更新プロセスは繰り返されることができる。

上述のとおり、更新は、ユーザーが１つ以上の医療装置のために１つ以上の更新を選択する選択プロセスを通過した後に、医療装置で使用可能になる。一例では、ウィザードベースの選択メカニズムが、任意の数の装置が更新のために選択されるために備えられている。ウィザードは、サーバー上で、またはサーバーと通信するネットワーククライアント上で実行可能である。

図２０は、更新および更新のための装置を選択するためにユーザーにより使用される例示的な選択ウィザードのスクリーンショットである。ウィザードを使用して、ＩＴ技術者はサーバー上で更新を構成することができる。ウィザードには柔軟性があるので、異なる多くの実装形態で使用可能である。この例では、装置のタイプが選択され（プルダウンメニュー２４０）、使用可能なソフトウェアおよび構成ファイルが提示される（ボックス２４２）。次いで、ＩＴ技術者は更新する装置（テーブル２４４に表示される）および更新の一部となるファイルを選択できる。サーバーでは更新を特定の数のファイルにパッケージ化し、一例では、ＪＡＲ ｚｉｐ圧縮済みファイルとして実装される。さらに画面には、更新プロセスの間、更新のステータス２４６も表示される。

更新メッセージ（上述）が装置のために準備される。更新メッセージには、ファイルのマニフェストまたはリストおよびサーバー上の場所が含まれている。更新は１つのサーバー上の単一のファイルとすることも、複数のサーバーまたは１つのサーバー上の複数の場所からの複数のファイルから構成されることもできる。サーバーはこのメッセージを選択された装置のそれぞれに送信し、装置に更新の使用可能性と場所を通知する。

上述のとおり、次に装置はサーバーから更新ファイルをプルして、更新を装置にローカルに保存する。次いで、装置は電源オフの間に看護師に更新をインストールするようプロンプトする。更新がインストールされると、装置の電源は通常どおりに切れる。更新のスクリプト処理インターフェースは、更新を将来、使用可能にし、すべての装置に対する更新の段階的配信を可能にしてから、更新が使用可能にされる。

前述の詳細な説明では、開示が特定の例示的実施形態を参照して記述された。さまざまな修正形態および変更形態は、請求項で述べられる開示のより広い範囲を逸脱することなく作成されることが可能である。したがって、明細書や図面は限定的な意味ではなく、むしろ例示的なものであると認識していただきたい。

Claims (15)

1. 薬剤投与装置に更新を提供するための方法であって、当該方法は、
   薬剤投与装置に利用可能な１つ以上の更新ファイルに関する更新メッセージを薬剤投与装置に送信することであって、更新メッセージがマニフェストを含み、マニフェストが薬剤投与装置に利用可能な更新ファイルの場所、更新ファイルバージョン情報、更新ファイル整合性確認情報を含むこと、
   薬剤投与装置で更新メッセージを受信すること、
   薬剤投与装置が薬剤を投与するために使用されている間、更新メッセージによって識別される１つ以上の更新ファイルをダウンロードすること、
   更新ファイル整合性確認情報を使用して、１つ以上の更新ファイルが正常にダウンロードされたことを確認すること、
   将来の時点でのインストールのために薬剤投与装置上に１つ以上の更新ファイルを保存すること、
   薬剤投与装置のユーザーにプロンプトして薬剤投与装置を更新すること、および
   ユーザーが更新プロンプトを受け入れると、薬剤投与装置に１つ以上の更新ファイルをインストールすることを含む、方法。
2. 更新が複数の薬剤投与装置に提供され、当該方法にはさらに、
   更新される１つ以上の薬剤投与装置を選択すること、
   選択された薬剤投与装置でメッセージを受信することを含む、請求項１に記載の方法。
3. １つ以上の薬剤投与装置が、装置の物理的場所、装置のモデル、装置のタイプ、および装置が使用される方法の１つ以上に基づいて選択される、請求項２に記載の方法。
4. ダウンロードされた更新ファイルが薬剤投与装置の記憶場所に保存され、記憶場所にはさらに、更新される更新ファイルの１つ以上の以前のバージョンも保存される、請求項１に記載の方法。
5. 更新ファイルが、更新された薬剤ライブラリおよび更新された装置のソフトウェアの１つ以上を含む、または、
   更新ファイルが、更新プロセスの調整のために使用されるスクリプトを含む、請求項１に記載の方法。
6. メッセージが送信され、更新ファイルが通信ネットワークを使用して取得される、または、
   メッセージが送信され、更新ファイルが１つ以上の携帯型記憶装置を使用する薬剤投与装置によって取得される、請求項１に記載の方法。
7. 更新ファイル整合性確認情報が、チェックサムを含む、請求項１に記載の方法。
8. サーバーにステータスメッセージを提供し、ステータスメッセージが更新のダウンロードおよびインストールに関係するものであることをさらに含む、請求項１に記載の方法。
9. 薬剤投与装置で受信されたメッセージが更新ファイルの場所を含む、または、
   薬剤投与装置で受信されたメッセージが当該装置に固有のメッセージである、請求項１に記載の方法。
10. 薬剤投与装置が少なくとも１つの点滴ポンプを含む、請求項１に記載の方法。
11. 医療装置システムであって、
    サーバーと、
    通信ネットワークと、
    通信ネットワークを介してサーバーと通信する複数の医療装置で、複数の医療装置はそれぞれ保存場所および医療装置の動作を制御するための制御ユニットを有し、制御ユニットは、
    サーバーから更新メッセージを受信するように構成され、更新メッセージがマニフェストを含み、マニフェストが医療装置に利用可能な更新ファイルの場所、更新ファイルバージョン情報、および更新ファイル整合性確認情報を含み、
    医療装置が薬剤を投与するのに使用されている間、サーバーから受信される更新メッセージに応じて更新ファイルをプルするように構成され、
    更新ファイル整合性確認情報を使用して、更新ファイルが正常にダウンロードされたことを確認するように構成され、
    将来の時点でのインストールのために医療装置上に更新ファイルを保存するように構成され、
    それぞれの医療装置のユーザーにプロンプトしてそれぞれの医療装置を更新するように構成され、制御ユニットは、ユーザーによる更新プロンプトの受け入れ次第、ダウンロードされた更新ファイルのインストールを管理するように構成される医療装置とを備える、医療装置システム。
12. 医療装置システムが、ユーザーが更新される１つ以上の医療装置を選択できるように構成される、請求項１１に記載の医療装置システム。
13. 医療装置が、装置の物理的場所、装置のモデル、装置のタイプ、および装置が使用される方法の１つ以上に基づいて選択される請求項１２に記載の医療装置システム。
14. 各それぞれの記憶場所が、ダウンロードされた更新ファイルおよび更新されるファイルの１つ以上の以前のバージョンを保存する、または、
    更新ファイルが、更新された薬剤ライブラリおよび更新された装置のソフトウェアの１つ以上を含む、請求項１１に記載の医療装置システム。
15. 更新ファイルの各それぞれの更新ファイルが、更新プロセスの調整のために使用されるスクリプトを含む、または、
    制御ユニットが、サーバーにステータスメッセージを提供するよう構成され、ステータスメッセージが更新ファイルのダウンロードおよびインストールに関係している、または、
    複数の医療装置が少なくとも１つの点滴ポンプを含む、請求項１４に記載の医療装置システム。

Images