(57)【要約】【課題】複数の医療機器を統合的に運用する。【解決手段】本発明は、サーバが医療機器の保守をスケジューリングする方法であって、  サーバは、医療機器から隔離されたコンピューティングシステムに、医療機器についての保守を実行するリマインダを含む医療機器保守スケジュールを格納し、コンピューティングシステムから前記医療機器に前記リマインダを送信すること、を特徴とする。【選択図】図１
2014006915.tif 000002
【特許請求の範囲】
【請求項１】
サーバが医療機器の保守をスケジューリングする方法であって、
前記サーバは、
前記医療機器から隔離されたコンピューティングシステムに、前記医療機器についての保守を実行するリマインダを含む医療機器保守スケジュールを格納し、
前記コンピューティングシステムから前記医療機器に前記リマインダを送信すること、
を特徴とする方法。
【請求項２】
前記サーバは、
前記リマインダを表示すること、
を特徴とする請求項１に記載の方法。
【請求項３】
前記リマインダを送信することは、
前記医療機器から前記コンピューティングシステムへの通信に応じて実行されること、
を特徴とする請求項１に記載の方法。
【請求項４】
前記コンピューティングシステムは、
前記医療機器と通信可能に接続された医療機器サーバであること、
を特徴とする請求項１に記載の方法。
【請求項５】
前記リマインダを送信することは、
前記リマインダの送信を可能にするトリガ信号を送信することを含むこと、
を特徴とする請求項１に記載の方法。
【請求項６】
前記リマインダは、
前記医療機器に格納されること、
を特徴とする請求項５に記載の方法。
【請求項７】
前記医療機器保守スケジュールは、
前記コンピューティングシステムの医療機器保守スケジュールのデータベースに格納されること、
を特徴とする請求項１に記載の方法。
【請求項８】
医療機器が前記医療機器の保守をスケジューリングする方法であって、
前記医療機器は、
前記医療機器において医療機器サーバから前記医療機器の保守イベントに関するリマインダを受け取り、
前記医療機器のディスプレイに前記リマインダを表示すること、
を特徴とする方法。
【請求項９】
前記医療機器は、
前記医療機器サーバから保守データを受け取ること、
を特徴とする請求項８に記載の方法。
【請求項１０】
前記医療機器は、
前記リマインダを受け取った後に操作を継続すること、
を特徴とする請求項１ないし請求項９のいずれか１項に記載の方法。
【請求項１１】
前記医療機器は、
医療点滴ポンプであること、
を特徴とする請求項１ないし請求項９のいずれか１項に記載の方法。
【請求項１２】
前記リマインダは、
前記医療機器の使用を不可能にすること、
を特徴とする請求項１ないし請求項９のいずれか１項に記載の方法。
【請求項１３】
前記保守データは、
更新された操作ソフトウエアを含むこと、
を特徴とする請求項１ないし請求項９のいずれか１項に記載の方法。
【請求項１４】
医療機器保守スケジュールを管理するシステムであって、
前記システムは、
医療機器と、
前記医療機器と通信可能に接続されたコンピューティングシステムと、を有し、
前記コンピューティングシステムは、
少なくとも１つのリマインダを含む医療機器保守スケジュールを格納するメモリと、
前記メモリと操作可能に接続されたプログラマブル回路と、を有し、
前記プログラマブル回路は、
前記医療機器保守スケジュールを格納し、
前記コンピューティングシステムから前記医療機器に前記リマインダを送信するプログラム命令を実行すること、
を特徴とするシステム。
【請求項１５】
前記医療機器は、
医療点滴ポンプであること、
を特徴とする請求項１４に記載のシステム。
【請求項１６】
前記コンピューティングシステムは、
前記医療機器と通信可能に接続された医療機器サーバであること、
を特徴とする請求項１４に記載のシステム。
【請求項１７】
前記プログラマブル回路は、
前記医療機器から前記コンピューティングシステムへの通信に応じて前記リマインダを送信するようにプログラミングされていること、
を特徴とする請求項１４に記載のシステム。
【請求項１８】
前記医療機器は、
前記リマインダを表示すること、
を特徴とする請求項１４に記載のシステム。
【請求項１９】
前記プログラマブル回路は、
前記医療機器に格納されたリマインダの送信を可能にするトリガ信号を送信することによって前記リマインダを送信するようにプログラミングされていること、
を特徴とする請求項１４に記載のシステム。
【請求項２０】
前記システムは、
複数の前記医療機器と、
前記医療機器のそれぞれに対応する医療機器保守スケジュールを格納する前記コンピューティングシステムの前記メモリと、
を含み、
前記医療機器保守スケジュールは、
少なくとも１つのリマインダを含み、
前記プログラマブル回路は、
前記医療機器保守スケジュールを格納し、
複数の前記医療機器の１又は複数の時刻値を格納し、
医療機器を選択し、前記医療機器に対応する医療機器保守スケジュールから前記リマインダを送信するプログラム命令を実行すること、
を特徴とする請求項１４に記載のシステム。
【請求項２１】
前記医療機器は、
前記リマインダを受け取った後に操作を継続すること、
を特徴とする請求項１４ないし請求項２０のいずれか１項に記載のシステム。
【請求項２２】
前記リマインダは、
前記医療機器の使用を不可能にすること、
を特徴とする請求項１４ないし請求項２０のいずれか１項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願の原出願は、米国を除くすべての指定国については、スミス メディカル エムディ インク.を出願人として、米国のみについては、米国市民ニック ロバーツ及び米国市民リー エー. ニューマンを出願人として、更に、２００７年８月１０日に出願された米国特許仮出願第６０／９６４，４４４号を基礎とする優先権を主張して、２００８年８月１１日付ＰＣＴ国際特許出願として出願されたものの国内移行である。
【０００２】
一般的には、本発明の開示は、医療機器の使用及び制御のためのシステムを介した患者の治療に関する。具体的には、本発明の開示は、医療機器を使用する患者の治療のためのソフトウエアに関する。
【背景技術】
【０００３】
病院及び他の医療センタにおいて、患者は、制御された治療管理及びモニタリングを要望する。病院及び治療センタは、モニタリング及び治療管理を支援する様々なタイプ及びブランドの医療機器を使用している。例えば、治療管理を支援するために使用される医療機器は、医療点滴ポンプ、パルス酸素濃度計、心肺機能モニタ、他の治療提供設備及び他の患者モニタリング設備を含み得る。一般的には、様々なタイプ及びブランドの医療機器は、使用する通信標準がそれぞれ異なっている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
様々な機器によって適用される基準が異なるため、機器間の相互運用が制限され、治療管理は困難になる。１つ又は複数の医療機器を使用している間、介護人は、その医療機器に関する多数の動作を実行したくなるかもしれない。例えば、介護人は、観察された患者の容態に基づいて、医療機器にパラメータを入力したくなるかもしれない。また、介護人は、モニタが収集したデータを見たくなるかもしれない。様々な医療機器ごとに標準が異なることに起因して、介護人は、多くのタイプのソフトウエア及びハードウエアを使用して、患者を治療するために必要な医療機器が収集した情報にアクセスすることになるかもしれない。
【０００５】
複数の医療機器を統合的に運用することもまた困難であり得る。医療機器が１つしかないのであれば、管理すべき治療が変わる都度プログラミングすることができるし、病院内での使用場所が変わる都度プログラミングすることもできる。別々の病院に所在する様々なタイプの医療機器についての使用履歴を比較することが必要になるかもしれない。同様に、介護人がいる場所とは別の場所に医療機器がある場合も多いので、医療機器の状態をモニタリングすることが困難になり得る。
【課題を解決するための手段】
【０００６】
（要約）
患者に対する治療の方法及びシステムが開示される。当該方法及びシステムは、医療機器情報学を使用し治療及びその治療で使用される薬品を修正し有効にすることを含む。本発明の開示の様々な実施形態で、医療点滴ポンプのような医療機器が、サーバとインタフェースを取り、患者に対する治療を管理する。
【０００７】
いくつかの実施形態においては、医療機器メタデータは、医療機器ネットワーク内で医療機器を定義するために使用される。他の実施形態においては、メッセージが、医療機器とサーバとの間で送信されて、治療及び医療機器に対する他の操作を定義する。他の実施形態においては、操作データ及び履歴データが医療機器から医療機器サーバに送信されて、患者に対する治療の管理を遠隔モニタリングすることを可能にする。他の実施形態においては、タイミングパラメータが、医療機器と医療機器サーバとの間での送信及びイベント追跡を指示する。
【０００８】
特定の実施形態においては、医療機器とサーバとの間の通信方法が開示される。当該方法は、メタデータを１つ又は複数の医療機器に関連付ける。当該メタデータは、医療機器の属性に対応している。当該方法は、メタデータをサーバに格納することを含む。サーバは、メタデータを使用することによって、各医療機器と通信する。
【０００９】
第２の実施形態においては、複数の医療機器と通信するシステムが開示される。当該システムは、複数の医療機器及び当該複数の医療機器と通信可能に接続されたサーバを含む。サーバは、医療機器を記述するメタデータを格納するメモリ及びメモリと操作可能に接続されたプログラマブル回路を含む。プログラマブル回路は、プログラム命令を実行し、メタデータを１つ又は複数の医療機器に関連付ける。メタデータは、医療機器の少なくとも１つの属性に対応している。プログラマブル回路は、プログラム命令を実行し、メタデータをサーバに格納し、少なくとも１つの医療機器との間で、メタデータを含む情報を送信する。
【００１０】
第３の実施形態においては、医療機器とサーバとの間の通信方法が開示される。当該方法は、メタデータを複数の医療機器のそれぞれに関連付けることを含む。メタデータは、医療機器に共通な少なくとも１つの属性に対応している。当該方法は、第２のメタデータを複数の医療機器のうちの少なくとも１つの医療機器に関連付けることも含む。第２のメタデータは、医療機器の少なくとも１つのカスタム属性に対応している。当該方法は、メタデータをサーバに格納することも含む。サーバは、メタデータを使用することによって、医療機器のそれぞれと通信する。当該方法は、１つの医療機器を選択し、メタデータを含む情報を、当該医療機器との間で通信することも含む。
【００１１】
第４の実施形態においては、複数の医療機器とサーバとの間の通信方法が開示される。当該方法は、医療機器において医療機器サーバへのメッセージを生成することを含む。メッセージは、当該医療機器を特定するために使用されるメタデータを含む。当該方法は、医療機器において医療機器サーバからのメッセージを受け取ることも含む。メッセージは、医療機器を特定するメタデータを含む。
【００１２】
追加的な実施形態においては、別々のカスタマサイトでの複数の医療機器についての識別情報を格納するメモリ、及び、メモリと操作可能に接続されたプログラマブル回路を含むサーバが開示される。プログラマブル回路は、プログラム命令を実行し、１つ又は複数の別々のカスタマサイトにおいて医療機器からのデータを受け取り、当該データを１つ又は複数の別々のカスタマサイトに関連付けてメモリ内に格納し、当該データの一部を、データのその部分を送信した医療機器に関連付ける。
【００１３】
さらに他の実施形態においては、サーバネットワークが開示される。当該ネットワークは、別々のカスタマサイトにおいて、複数の医療機器、及び、複数の医療機器と操作可能に接続されたサーバを含む。サーバは、別々のカスタマサイトでの複数の医療機器についての識別情報を格納するメモリ、及び、メモリと操作可能に接続されたプログラマブル回路を含む。プログラマブル回路は、プログラム命令を実行し、１つ又は複数の別々のカスタマサイトにおいて医療機器からのデータを受け取り、当該データを１つ又は複数の別々のカスタマサイトに関連付けてメモリ内に格納し、当該データの一部を、データのその部分を送信した医療機器に関連付ける。サーバネットワークは、カスタマサイトの１つにおいて、ワークステーションも含む。ワークステーションは、サーバと通信可能に接続され、カスタマサイトに関するデータを要求する。
【００１４】
他の実施形態においては、医療機器に対して情報を配備する方法が開示される。当該方法は、サーバ上のデータパッケージ内に情報を格納することを含む。当該情報は、医療機器に提供されることを目的とする。当該方法は、医療機器からのメッセージを受け取り、当該メッセージを受け取ることに応答して、医療機器に対して、医療機器向けの情報がサーバ上に存在することを示す。当該方法は、当該情報を求める要求を受け取り、当該要求を受け取ると、医療機器にデータパッケージを提供することも含む。
【００１５】
追加的な実施形態においては、医療機器の動作に影響を与えるためにサーバから医療機器に提供されたデータパッケージが開示される。当該データパッケージは、医療機器の動作を変更するためのデータを含む情報を含む。当該情報は、データ構造を有する。データパッケージは、データパッケージの内容に関するサイズ情報及び不足情報を含む、サーバ読取可能なヘッダも含む。データパッケージは、当該情報に関するデータ構造情報を含む、ベンダ定義されたヘッダも含む。
【００１６】
さらに追加的な実施形態においては、医療機器に対して情報を配備するシステムが開示される。当該システムは、データパッケージと、メモリとインタフェースが取られたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行し、データパッケージに情報を格納する。当該情報は、医療機器に提供されることを目的とする。プログラマブル回路は、プログラム命令を実行し、医療機器からメッセージを受け取り、医療機器に対して、医療機器向けの情報がメモリ内に存在することを示す。プログラマブル回路はさらに、プログラム命令を実行し、当該情報を求める要求を受け取り、医療機器にデータパッケージを提供する。
【００１７】
他の実施形態においては、医療機器によって情報を受け取る方法が開示される。当該方法は、医療機器サーバとの通信セッションを開始する。当該方法は、医療機器サーバが医療機器に提供されるべきデータパッケージを格納しているという表示を受け取ることも含む。当該方法は、データパッケージを要求し、当該データパッケージを受け取ることも含む。
【００１８】
追加的な実施形態においては、２以上の時間帯に亘って分散される複数の医療機器と、医療機器と操作可能に接続されたサーバとを含む医療機器ネットワークが開示される。当該サーバは、イベントログデータを保持するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行して複数の医療機器からイベントログデータを受け取り、イベントログデータ内の時間帯情報を修正する。プログラマブル回路は、プログラム命令を実行してイベントログデータをメモリに格納する。
【００１９】
追加的な実施形態においては、２以上の時間帯に位置する複数の医療機器間でイベントログ時間帯情報を統合する方法が開示される。当該方法は、複数の医療機器からイベントログデータを受け取り、イベントログデータ内の時間帯情報を修正することを含む。当該方法は、イベントログデータをメモリに格納することも含む。
【００２０】
追加的な実施形態においては、２以上の時間帯に位置する複数の医療機器間でイベントログ時間帯情報を統合する方法が開示される。当該方法は、複数の医療機器からイベントログデータを受け取り、ユニバーサルタイムプロトコルを反映するようにイベントログデータ内のタイムスタンプを修正することを含む。当該方法は、イベントログデータをメモリに格納し、ユニバーサルタイムプロトコルを使用してグローバルイベントを追跡することも含む。当該方法は、医療機器に関するイベントログデータを求めるクエリを受け取り、ユニバーサルタイムプロトコルを、医療機器の位置に関するローカル時間帯情報に変換する。
【００２１】
追加的な実施形態においては、医療イベントログ結果を検索する方法が開示される。当該方法は、医療機器によって生成されたイベントログデータをサーバにおいて受け取り、当該イベントログデータをサーバのメモリに格納することを含む。当該方法は、イベントログデータのサブセットの要求を受け取ることも含む。当該イベントログデータのサブセットは、少なくとも１つの特徴によって定義される。当該方法は、特徴に基づいてイベントログデータをフィルタリングすることも含む。
【００２２】
追加的な実施形態においては、医療イベントログ結果の検索システムが開示される。当該システムは、複数の特徴を有するイベントログデータを格納するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行し、医療機器が生成したイベントログデータをサーバにおいて受け取り、イベントログデータをサーバのメモリに格納する。プログラマブル回路は、少なくとも１つの特徴によって定義されるイベントログデータのサブセットの要求を受け取り、特徴に基づいてイベントログデータをフィルタリングする。
【００２３】
追加的な実施形態においては、医療イベントログ結果を検索する方法が開示される。当該方法は、医療点滴ポンプによって生成されたイベントログデータをサーバにおいて受け取り、イベントログデータをサーバのメモリに格納する。当該方法は、イベントログデータのサブセットの要求を、サーバから隔離されておりサーバと通信可能に接続されたワークステーションから受け取ることも含む。当該イベントログデータのサブセットは、少なくとも１つの特徴によって定義される。当該方法は、特徴に基づいてイベントログデータをフィルタリングし、フィルタリングされたイベントログデータをワークステーションに対して出力することを含む。当該特徴は、医療機器をプログラミングした又は操作した介護人を表す介護人識別子である。
【００２４】
追加的な実施形態においては、医療機器の保守をスケジューリングする方法が開示される。当該方法は、医療機器保守スケジュールを、医療機器から隔離されたコンピューティングシステム上に格納することを含む。医療機器保守スケジュールは、リマインダを含み、医療機器についての保守を実行する。当該方法は、リマインダをコンピューティングシステムから医療機器に送信することも含む。
【００２５】
追加的な実施形態においては、医療機器保守スケジュールを管理するシステムが開示される。当該システムは、医療機器と、医療機器と通信可能に接続されたコンピューティングシステムとを含む。コンピューティングシステムは、医療機器保守スケジュールを格納するメモリを含む。医療機器保守スケジュールは、少なくとも１つのリマインダを含む。コンピューティングシステムは、メモリと操作可能に接続されたプログラマブル回路も含む。プログラマブル回路は、プログラム命令を実行し、医療機器保守スケジュールを格納し、リマインダをコンピューティングシステムから医療機器に送信する。
【００２６】
追加的な実施形態においては、医療機器保守スケジュールを管理するシステムが開示される。当該システムは、複数の医療機器と、複数の医療機器と通信可能に接続されたコンピューティングシステムとを含む。コンピューティングシステムは、それぞれの医療機器に対応する医療機器保守スケジュールを格納するメモリを含む。医療機器保守スケジュールはそれぞれ、少なくとも１つのリマインダを含む。コンピューティングシステムは、メモリと操作可能に接続されたプログラマブル回路も含む。プログラマブル回路は、プログラム命令を実行し、医療機器保守スケジュールを格納し、複数の医療機器の１つ又は複数の時刻値を格納し、１つの医療機器を選択し、当該医療機器に対応する医療機器保守スケジュールからリマインダを送信する。プログラマブル回路は、プログラム命令を実行し、リマインダをコンピューティングシステムから医療機器に送信する。
【００２７】
追加的な実施形態においては、医療機器の保守をスケジューリングする方法が開示される。当該方法は、医療機器において、医療機器サーバからのリマインダを受け取る。リマインダは、医療機器の保守イベントに関連している。当該方法は、リマインダを医療機器のディスプレイ上に表示することも含む。
【００２８】
追加的な実施形態においては、医療点滴ポンプ内の変更後パラメータの追跡方法が開示される。当該方法は、医療点滴ポンプと医療機器サーバとの間で通信セッションを確立し、医療機器点滴ポンプから医療機器サーバに、初期パラメータ値、更新されたパラメータ値、及び最終パラメータ値を送信する。当該方法は、医療機器サーバ上に、初期パラメータ値、更新されたパラメータ値、及び最終パラメータを格納することも含む。１つ又は複数のパラメータ値に関連付けられたメタデータは、医療機器サーバ及び医療点滴ポンプへのパラメータ値を特定する。
【００２９】
追加的な実施形態においては、医療点滴ポンプ内の変更後パラメータを追跡するシステムが開示される。当該システムは、１つ又は複数のプログラマブルパラメータを有する医療点滴ポンプと、医療点滴ポンプと通信可能に接続された医療機器サーバとを含む。医療機器サーバは、パラメータ値を格納するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行し、医療点滴ポンプと医療機器サーバとの間で通信セッションを確立し、医療機器点滴ポンプから、初期パラメータ値、更新されたパラメータ値、及び最終パラメータ値を受け取る。プログラマブル回路は、プログラム命令を実行し、初期パラメータ値、更新されたパラメータ値、及び最終パラメータ値をメモリに格納する。１つ又は複数のパラメータ値に関連付けられたメタデータは、医療機器サーバ及び医療点滴ポンプへのパラメータ値を特定する。
【００３０】
追加的な実施形態においては、医療点滴ポンプ内の変更後パラメータを追跡するシステムが開示される。当該システムは、複数の医療点滴ポンプを含む。医療点滴ポンプのそれぞれは、１つ又は複数のプログラマブルパラメータを有する。当該システムは、複数の医療点滴ポンプと通信可能に接続された医療機器サーバも含む。医療機器サーバは、パラメータ値を格納するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行し、１つ又は複数の医療点滴ポンプと医療機器サーバとの間で通信セッションを確立し、医療機器点滴ポンプから、初期パラメータ値、更新されたパラメータ値、及び最終パラメータ値を受け取る。プログラマブル回路は、プログラム命令を実行し、初期パラメータ値、更新されたパラメータ値、及び最終パラメータ値をメモリに格納する。１つ又は複数のパラメータ値に関連付けられたメタデータは、医療機器サーバ及び医療点滴ポンプへのパラメータ値を特定する。
【００３１】
追加的な実施形態においては、医療機器サーバが開示される。医療機器サーバは、患者容態情報及びコマンド情報を格納するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行し、第１の医療機器から患者容態情報を受け取る。患者容態情報は、患者に関連し、患者に対する治療の必要性を決定する。プログラマブル回路は、プログラム命令を実行し、当該治療を提供する第２の医療機器にコマンドを送信する。
【００３２】
追加的な実施形態においては、医療機器をプログラミングする方法が開示される。当該方法は、第１の医療機器から患者容態情報を受け取ることを含む。患者容態情報は患者に関連する。当該方法は、患者に対する治療の必要性を、医療機器サーバによって決定することも含む。当該方法は、患者に対する治療を行うことができる第２の医療機器をプログラミングすることも含む。
【００３３】
追加的な実施形態においては、医療機器ネットワークが開示される。当該医療機器ネットワークは、複数の医療機器と、複数の医療機器と操作可能に接続された医療機器サーバとを含む。医療機器サーバは、患者容態情報及びコマンド情報を格納するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行し、複数の医療機器のうちの第１の医療機器から患者容態情報を受け取り、患者に対する治療の必要性を決定する。プログラマブル回路は、プログラム命令を実行し、治療が必要であると認めると、複数の医療機器のうちの第２の医療機器にコマンドを送信する。第２の医療機器は、治療を提供する。
【００３４】
追加的な実施形態においては、医療機器のオンラインステータスを決定する方法を開示する。当該方法は、所定の期間内に医療機器からの通信を待ち受け、所定の期間内に医療機器からメッセージが受け取られたか否かを決定する。当該方法は、決定ステップに基づいて医療機器ごとにオンラインステータスを確立することも含む。
【００３５】
追加的な実施形態においては、医療機器に関するオンラインステータスを格納するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む医療機器サーバが開示される。プログラマブル回路は、プログラム命令を実行し、予め決定された期間内に医療機器からの通信を待ち受け、予め決定された期間内に医療機器からメッセージが受け取られたか否かを決定する。プログラマブル回路は、決定ステップに基づいて医療機器ごとにオンラインステータスを確立する。
【００３６】
追加的な実施形態においては、医療機器のオンラインステータスを通信する方法が開示される。当該方法は、第１の時点において、医療機器サーバとの通信を開始し、第２の時点において、医療機器サーバとの通信を開始することによって、オンラインステータスを確立することを含む。第２の時点は、第１の時点後の予め決定された期間内の時点である。
【００３７】
追加的な実施形態においては、医療機器と医療機器サーバとの間でクロックを同期させる方法が開示される。当該方法は、医療機器と通信可能に接続された医療機器サーバ上でサーバ時刻値を維持し、サーバ時刻値を医療機器サーバから医療機器に送信することを含む。医療機器は、サーバ時刻値を維持する。当該方法は、機器時刻値をサーバ時刻値に置換することも含む。
【００３８】
追加的な実施形態においては、医療機器同期システムが開示される。当該システムは、機器時刻値を維持する医療機器と、医療機器と通信可能に接続された医療機器サーバとを含む。医療機器サーバは、サーバ時刻値を格納するメモリと、メモリと操作可能に接続されたプログラマブル回路とを含む。プログラマブル回路は、プログラム命令を実行し、サーバ時刻値を維持し、サーバ時刻値を医療機器に送信する。医療機器は、サーバ時刻値を受け取り、機器時刻値をサーバ時刻値に置換する。
【００３９】
追加的な実施形態においては、複数の医療機器と医療機器サーバとの間でクロックを同期させる方法が開示される。当該方法は、複数の医療機器と通信可能に接続された医療機器サーバ上でサーバ時刻値を維持することを含む。当該方法は、サーバ時刻値を医療機器サーバから医療機器に送信することを含む。それぞれの医療機器は、サーバ時刻値を維持する。当該方法は、それぞれの医療機器の機器時刻値をサーバ時刻値に置換し、医療機器から医療機器サーバへの確認信号を受け取ることも含む。
【００４０】
追加的な実施形態においては、ソフトウエア開発キットが開示される。当該キットは、医療機器インストールソフトウエアを含む。医療機器インストールソフトウエアは、ユーザが医療機器の１つ又は複数の特徴に関連するメタデータを定義することを可能にするコンピュータ読取可能な命令を含む。当該キットは、データパッケージ提供ソフトウエアも含む。データパッケージ提供ソフトウエアは、サーバから医療機器にデータパッケージを提供するコンピュータ読取可能な命令を含む。当該キットは、サーバソフトウエアも含む。サーバソフトウエアは、医療機器サーバ上で実行されるコンピュータ読取可能な命令を含む。サーバソフトウエアは、サーバから医療機器への通信を制御する。
【００４１】
追加的な実施形態においては、医療機器と医療機器サーバとの間の通信を可能にするキットが開示される。当該キットは、ユーザが医療機器の１つ又は複数の特徴に関連するメタデータを定義することを可能にするコンピュータ読取可能な命令を含む医療機器インストールソフトウエアを含む。医療機器インストールソフトウエアは、メタデータを、医療機器及び医療機器サーバについての１つ又は複数の特徴に関連付ける。当該キットは、データパッケージ提供ソフトウエアも含む。データパッケージ提供ソフトウエアは、サーバから医療機器にデータパッケージを提供するコンピュータ読取可能な命令を含む。データパッケージは、医療機器の動作を制御するコンピュータ読取可能な命令を含む。当該キットは、サーバソフトウエアも含む。サーバソフトウエアは、医療機器サーバ上で実行されるコンピュータ読取可能な命令を含む。サーバソフトウエアは、サーバから医療機器への通信を制御する。
【図面の簡単な説明】
【００４２】
【図１】本発明の実施形態に係る医療機器ネットワークの一例を示す図である。
【図２】本発明の実施形態に係る医療機器のブロック図である。
【図３】医療機器ネットワークのソフトウエア構成図である。
【図４】医療機器ネットワークの第２のソフトウエア構成図である。
【図５】複数のエントリによって制御される医療機器の遠隔管理のための方法及びシステムのフローチャートである。
【図６】医療機器の制御をサーバを使用して行う方法及びシステムのフローチャートである。
【図７】医療機器の遠隔制御の状態図である。
【図８】医療機器ネットワークにおいて使用されるメッセージシステムの機能図である。
【図９】医療機器と医療機器サーバの間の通信を行う方法及びシステムのフローチャートである。
【図１０】医療機器と医療機器サーバの間の通信を行う他の方法及びシステムのフローチャートである。
【図１１】医療機器及び医療機器サーバ向けの拡張可能通信システムを容易にするために使用可能なメタデータを含むデータモデルである。
【図１２】医療機器及び医療機器サーバ向けの拡張可能通信システムを容易にするために使用可能なメタデータを含むデータモデルである。
【図１３】医療機器及び医療機器サーバ向けの拡張可能通信システムを容易にするために使用可能なメタデータを含むデータモデルである。
【図１４】医療機器及び医療機器サーバ向けの拡張可能通信システムを容易にするために使用可能なメタデータを含むデータモデルである。
【図１５】医療機器及び医療機器サーバ向けの拡張可能通信システムを容易にするために使用可能なメタデータを含むデータモデルである。
【図１６】医療機器及び医療機器サーバ向けの拡張可能通信システムを容易にするために使用可能なメタデータを含むデータモデルである。
【図１７】医療機器イベントをフィルタリングする方法及びシステムのフローチャートである。
【図１８】医療機器の保守を管理する方法及びシステムのフローチャートである。
【図１９】医療機器で発生しているイベントを追跡するために使用可能なイベントメタデータを含むデータモデルである。
【図２０】医療機器で発生しているイベントを追跡するために使用可能なイベントメタデータを含むデータモデルである。
【図２１】医療機器で発生しているイベントを追跡するために使用可能なイベントメタデータを含むデータモデルである。
【図２２】医療機器で発生しているイベントを追跡するために使用可能なイベントメタデータを含むデータモデルである。
【図２３】医療機器で発生しているイベントを追跡するために使用可能なイベントメタデータを含むデータモデルである。
【図２４】医療機器で発生しているイベントを追跡するために使用可能なイベントメタデータを含むデータモデルである。
【図２５】医療機器サーバから１つ又は複数の医療機器への送信用にフォーマットされたデータパケットの図である。
【図２６】図２５のデータパケットを提供するための方法及びシステムのフローチャートである。
【図２７】医療機器サーバから医療機器にデータパケットを提供することを容易にするために使用可能なメタデータを含むデータモデルである。
【図２８】医療機器サーバから医療機器にデータパケットを提供することを容易にするために使用可能なメタデータを含むデータモデルである。
【図２９】医療機器サーバから医療機器にデータパケットを提供することを容易にするために使用可能なメタデータを含むデータモデルである。
【図３０】医療機器サーバから医療機器にデータパケットを提供することを容易にするために使用可能なメタデータを含むデータモデルである。
【図３１】医療機器サーバから医療機器にデータパケットを提供することを容易にするために使用可能なメタデータを含むデータモデルである。
【図３２】医療機器サーバから医療機器にデータパケットを提供することを容易にするために使用可能なメタデータを含むデータモデルである。
【図３３】医療機器ネットワーク内で時間を同期させるために使用可能なメタデータを含む図である。
【図３４】医療機器ネットワーク内で医療機器を同期させる方法及びシステムのフローチャートである。
【図３５】イベントログデータの時間調整のための方法及びシステムのフローチャートである。
【図３６】本発明の実施形態に係る医療機器サーバの機能ユニットのブロック図である。
【図３７】医療機器サーバ管理システムのブロック図である。
【図３８】医療機器サーバからアクセス可能な医療機器管理イベント追跡レポートの一例である。
【図３９】医療機器サーバからアクセス可能なセキュリティイベント追跡レポートの一例である。
【図４０】医療機器サーバからアクセス可能なセキュリティイベント傾向レポートの一例である。
【図４１】医療機器サーバからアクセス可能なユーザ履歴レポートの一例である。
【図４２】医療機器メタデータの管理のためのユーザインタフェースである。
【図４３】医療機器メタデータの管理のための他のユーザインタフェースである。
【図４４】医療機器ネットワーク内でのデータパケット分配を管理するためのユーザインタフェースである。
【図４５】医療機器ネットワーク内で医療機器にデータパケットを配備するためのユーザインタフェースである。
【図４６】医療機器へのデータパケットの配備を確認するためのユーザインタフェースである。
【図４７】医療機器サーバから医療機器へのエラーデータ送信を含む隔離レポートの一例である。
【図４８】図４７の隔離レポートに対応する詳細隔離レポートの一例である。
【図４９】医療機器サーバから医療機器へのデータパッケージの配備を表示するパッケージ配備レポートの一例である。
【図５０】医療機器サーバから医療機器へのデータパッケージのエラー配備を表示するパッケージ配備エラーレポートの一例である。
【図５１】医療機器保守イベントを表示する保守レポートの一例である。
【図５２】医療機器サーバに送信された医療機器故障を表示する医療機器故障レポートの一例である。
【図５３】医療機器サーバに送信された医療機器故障の傾向を表示する医療機器故障傾向レポートの一例である。
【図５４】医療機器サーバから医療機器にパラメータ変化を送信するための方法及びシステムのフローチャートである。
【図５５】医療機器サーバから、医療機器を治療に基づいてプログラミングすることを容易にするために使用可能なメタデータを含む図である。
【図５６】医療機器を治療に基づいてプログラミングするためのメッセージシーケンスの一例である。
【図５７】医療機器サーバに送信された変更された医療機器パラメータを追跡するための方法及びシステムのフローチャートである。
【図５８】医療機器から医療機器サーバに送信されたイベントログデータを表示する医療機器履歴レポートの一例である。
【図５９】医療機器から医療機器サーバに送信された治療イベントログデータを表示する治療履歴レポートの一例である。
【図６０】医療機器から医療機器サーバに送信された治療イベントログデータから導出された治療傾向を表示する治療傾向レポートの一例である。
【図６１】医療機器から医療機器サーバに送信された治療イベントログデータ治療の変更を表示する治療変更履歴レポートの一例である。
【図６２】医療機器から医療機器サーバに送信された治療イベントログデータから導出された治療変更傾向を表示する治療変更傾向レポートの一例である。
【図６３】医療機器のオンラインステータスを決定するための方法及びシステムのフローチャートである。
【図６４】医療機器から遠隔測定データを収集するための方法及びシステムのフローチャートである。
【図６５】医療機器から遠隔測定データを受け取るためのメッセージシーケンスの一例である。
【図６６】医療機器から医療機器サーバへの遠隔測定データの送信を容易にするために使用可能なメタデータを含む図である。
【図６７】１つ又は複数の医療機器に関連する遠隔測定データを表示するために使用可能なダッシュボードの一例である。
【発明を実施するための形態】
【００４３】
（詳細説明）
ここでは、本発明の様々な実施形態を、図面を参照しつつ詳細に説明する。複数の図面に亘って、同一要素には同一番号を振っている。これらの実施形態を参照することは、本発明の範囲を限定することを意味しない。本発明の範囲を限定するのは、添付の請求の範囲のみである。さらに、当該明細書で説明される実施例は、本発明を限定することを目的としておらず、請求項の発明に対応する想定可能な多くの実施形態のうちのいくつかを説明するに過ぎない。
【００４４】
ここに記述される本発明の様々な実施形態の論理演算は、以下の（１）、（２）及び／又は（３）として実現される。
（１）コンピュータ内のプログラマブル回路上で実行される、ステップ、操作又は手順のシーケンス
（２）医療機器内のプログラマブル回路上で実行される、ステップ、操作又は手順のシーケンス
（３）プログラマブル回路内の相互接続された機器モジュール又はプログラムエンジン
【００４５】
当該明細書がここで説明する対象は、医療機器ネットワーク内の様々な医療機器及び医療機器サーバの使用及びプログラミングである。当業者であれば、医療点滴ポンプ、パルス酸素濃度計、心肺機能モニタ、他の治療提供設備及び他の患者モニタリング設備のような様々な医療機器が、ユーザに対する治療を管理する際に使用されることに気がつくであろう。これらのそしてその他の医療機器が、ここに開示される医療機器ネットワーク内で使用され得る。ここに開示される様々な実施形態において、医療機器サーバという語は、コンピューティングシステム、メッセージ制御、及び当該システムの様々な他の構成要素を統合的に運用するために使用されるストレージ機器を意味する。さらに、医療機器の文脈中の“ユーザ”という語は、一般的に、治療を受ける人間を意味する。医療機器サーバの使用についての文脈のように、他の多くの文脈中では、ユーザという語は、医療機器についての情報にアクセスしている医療機器又はコンピュータを操作している介護人のような、他の人間をも意味し得る。
【００４６】
さらに、ここに開示される医療機器及び相互接続されたコンピューティングシステムは、情報及びフィールドを、ディスプレイとも称するユーザインタフェース及びレポートとして生成し提供する。ユーザインタフェース及びレポートは、フィールド、数字／文字列、時刻及び日付を含み得る。フィールドは、セルとも称し、ユーザに対し、情報の入力及び／又は選択を促す。様々なコンピューティングシステム及び医療機器上で、様々なタイプの入出力装置が利用可能である。
【００４７】
本明細書中に出てくる様々なタイプの医療機器は、操作パラメータを実行又は使用する。操作パラメータは、コンピュータが実行するステップ、機器モジュール、及び個々の医療機器ユーザの要求を満たすプログラムを、カスタマイズ、又は個人化する。操作パラメータは、数値、文字列、フラグ、引数名、もしくは、ユーザ又は介護人が医療機器の動作を制御するために設定し得る医療機器プログラミングの他の実施形態であり得る。いくつかの実施形態においては、メタデータは、医療機器内の様々な操作パラメータ、並びに、サーバ及び医療機器とインタフェースを取った他のコンピュータシステムへの様々な操作パラメータの能力を文字で定義したものである。
【００４８】
I．ハードウエア環境
図１及び図２には、一般化されたハードウエア環境が記述されている。図１は、本発明の実施形態に係る医療機器ネットワーク１００の一例を示す。医療機器ネットワーク１００は、様々な医療機器及び通信システムが相互通信を行う方法を提供する。医療機器ネットワーク１００は、様々なタイプの医療機器と相互接続されている医療機器サーバ１０２を含む。医療機器は、能動的医療機器１０４、受動的医療機器１０６、及び、医療点滴ポンプ１０８として示されている複数の典型的医療機器を含み得る。
【００４９】
能動的医療機器１０４とは、患者に対する治療を管理するのに資する多くの医療機器のうちの任意のものを言う。能動的医療機器１０４は、流体治療薬を提供するための医療点滴ポンプ又は他の治療提供機器を含む。ある実施形態においては、能動的医療機器１０４は、図示されている医療点滴ポンプ１０８のような、医療点滴機器である。
【００５０】
受動的医療機器１０６とは、患者に対する治療を管理するのに積極的に資するというよりは、患者の容態をモニタリングする多くの監視機器のうちの任意のものを言う。受動的医療機器の例として、パルス酸素濃度計、心肺機能モニタ、又は、呼吸数、心拍数及び周期、血中酸素濃度及び他の健康指標のような患者の生体信号を計測する他の患者監視システムがある。
【００５１】
医療機器サーバ１０２は、医療機器との間で通信を行う、１つ又は複数の汎用又は専用コンピューティングシステムである。医療機器サーバ１０２は、様々な医療機器１０４、１０６、１０８から受け取られたデータを格納し検索する。医療機器サーバ１０２によって受け取られたデータは、医療機器１０４、１０６、１０８からサーバ１０２に送信された、イベントログデータ、プログラミングデータ及び様々な他のデータを含み得る。
【００５２】
オプションとして、医療機器ネットワーク１００は、ワークステーション１１０及び携帯コンピューティングシステム１１２のような、医療機器サーバ１０２との通信接続を可能にする追加的コンピューティング機器を含む。ワークステーション１１０及び携帯コンピューティングシステム１１２は、医療機器サーバにアクセス可能な通信インタフェースを有する、汎用コンピューティングシステム又はシンクライアントコンピューティングシステムである。ワークステーション１１０及び携帯コンピューティングシステム１１２は、一般的に、入力装置及びディスプレイを含むので、ユーザ（すなわち介護人）は、ユーザが患者のいる場所にいないときでも、患者についての情報にアクセスできる。ユーザは、ワークステーション１１０及び携帯コンピューティングシステム１１２を介して医療機器サーバ１０２にアクセスし、医療機器から収集されたデータを検索し、医療機器サーバ１０２に対して、１つ又は複数の医療機器に様々なメッセージ又はソフトウエアパッケージを送信するように指示し得る。
【００５３】
医療機器ネットワーク１００は、スイッチ１１４及び無線アクセスポイント１１６のようなネットワークインフラ構成要素を、オプションとして含む。ネットワークインフラ構成要素は、様々な医療機器１０４、１０６、１０８、医療機器サーバ１０２と追加的コンピューティングシステム１１０、１１２との間の通信インフラを提供する。医療機器ネットワーク１００は、ネットワークに含まれる様々な構成要素間の通信ルートを要求するが、所与の医療機器ネットワークに含まれる具体的構成要素は、医療機器ネットワークの具体的なインフラ及びユーザのニーズに基づいて変化する。したがって、スイッチ１１４及び無線アクセスポイント１１６は、ネットワークの様々な構成要素間の通信相互接続を実現するための典型的構成要素となることを予定されている。追加的タイプの、医療機器、コンピューティングシステム又はネットワーキング構成要素がネットワーク１００内で使用されてもよい。
【００５４】
図２は、医療機器２００の典型的なブロック図である。医療機器２００は、患者の治療管理又はモニタリングのための、多くの能動的医療機器又は受動的医療機器のうちの任意のものである。ある可能な実施形態においては、医療機器２００は、薬品や、他の流体治療薬を患者に点滴する医療点滴ポンプである。他のタイプの医療機器も可能である。
【００５５】
医療機器２００は、例えば、ランダムアクセスメモリ（ＲＡＭ）２０４、フラッシュメモリ２０６及び電気的消去可能プログラム可能型読取専用メモリ（ＥＥＰＲＯＭ）２０８を含むメモリサブシステムにインタフェースされるプログラマブル回路２０２を含む。ＲＡＭ２０４は、医療機器の操作パラメータを格納し、操作データ又は命令に比較して重要でない任意のストレージも格納する。フラッシュメモリ２０６は、ポンププログラム、当該ポンププログラムを使用するためのポンプパラメータ又は他のシステムファームウエアのような、ポンプ操作を定義する命令及び／又はデータメモリを格納する。ＥＥＰＲＯＭ２０８は、医療機器２００によって使用され、停電、バッテリ切れ又は他の予想外イベントのような、機器故障が発生した場合にも保存する必要がある、初期命令のセットを格納する。ＥＥＰＲＯＭ２０８は、必要に応じてＲＡＭ２０４又はフラッシュメモリ２０６に読み込まれ又はコピーされたうえで実行され得る、ファームウエア又は命令を、オプションとして含む。
【００５６】
医療機器２００の様々な実施形態において、メモリサブシステムの構成要素は、医療機器の必要に応じて決まる。ある機器においては、ここに記述された１つ又は複数のメモリシステム構成要素は存在しない。このような機器においては、当該機器内に格納されるデータ及び指示のいくつか又はすべては、当該機器内に存在するメモリサブシステムの他の構成要素内に格納されてもよい。ＲＡＭは、重要な操作データ又は命令を一時的に格納してもよい。また代替的な実施形態として、前記したフラッシュメモリの内容及びＥＥＰＲＯＭメモリの内容が相互に入れ替わってもよいし、それらの内容のすべてが、１つのタイプの不揮発性メモリ内に格納されてもよい。最後に、強誘電体（ferro-electric）メモリのような、他のタイプの不揮発性メモリが代替的に使用されてもよい。
【００５７】
医療機器２００は、機器が壁面コンセント又は他の交流電源に接続できないときに、医療機器に直流電源を供給するバッテリシステムも含む。ある実施形態においては、バッテリシステム２１０は、充電式リチウムイオンスマートバッテリシステムを含む。当該システムは、電源管理と、交流電源の存在に応じて直流電源と交流電源との間で切り替えを行うインテリジェントスイッチングとを提供する。他の実施形態においては、バッテリシステム２１０は、ニッケルカドミウムバッテリを含む充電式バッテリシステムのような、別タイプのバッテリシステムを含む。
【００５８】
医療機器２００は、プログラマブル回路２０２とインタフェースが取られている入力装置２１２及び出力装置２１４を含む。入力装置２１２を介して、ユーザは、医療機器の設置場所において、当該機器の動作を調節できる。入力装置２１２は、例えば、マウス、キーボード、キーパッド、トラックボール、タッチスクリーン、コントロールボタン又は他のユーザ制御可能機器であり得る。出力装置２１４は、医療機器に関する情報をユーザ及び当該機器の外部にある機器に対して提供する、あらゆるタイプのオーディオ、ビデオ又はデータインタフェースであり得る。様々な実施形態において、出力装置２１４は、第２の医療機器に対するデータインタフェースであってもよいし、医療機器２００の状態に関する情報をユーザに表示する外部モニタに接続されていてもよい。
【００５９】
医療機器２００は、ディスプレイ２１６及びアラーム２１８も含む。ディスプレイは、当該機器のユーザに情報を表示することができる視覚機器である。医療機器２００の様々な実施形態に応じて、ディスプレイ２１６は、例えば、ＬＣＤ、ＣＲＴ又は他のスクリーンのようなディスプレイであり得る。他のタイプの表示装置を追加することも可能である。さらに、医療機器はディスプレイ２１６を含むものとして図示されているが、代替的な実施形態においては、表示装置は要求されない。アラーム２１８は、ユーザ内又は機器内で検出された様々な条件を様々なタイプの聴覚指示を用いてユーザに提供し得る。これらの条件は、異常に低い又は高い心拍数又は呼吸数のような、検出された健康条件、あるいは、薬の供給量が少なくなっている、又は、当該機器の保守が要求されているということを示すような、当該機器に関する警告を含む。オプションとして、アラームは、ここに列挙されていない追加的な警告条件に基づいても発報する。選択されたアラームは、一般的に、実装された医療機器のタイプ及び当該機器が検出する条件に関連する。
【００６０】
有線通信インタフェース２２０は、医療機器サーバ又は他の汎用コンピューティングシステムとインタフェースを取る医療機器２００からのデータ通信接続を提供する。有線通信インタフェース２２０は、プログラマブル回路２０２とインタフェースを取り、医療機器２００からのデータを送受信する。様々な実施形態において、有線通信インタフェース２２０は、イーサネット（登録商標）、又は、デジタルデータを通信可能な他のデータ接続であり得る。
【００６１】
無線通信インタフェース２２２は、有線通信インタフェース２２０を代替するものである。したがって、医療機器の設置場所に起因して有線通信インタフェースが使用できないときでも、医療機器２００は、医療機器サーバ又は他のコンピューティングシステムとの通信を維持できる。無線通信インタフェース２２２は、プログラマブル回路２０２とインタフェースを取り、医療機器からのデータを無線で送受信する。無線通信インタフェース及び有線通信インタフェースのうちの一方を使用するか又は両方を使用するかは、医療機器の設置場所又は医療機器サーバと通信する必要性によって決まる。ある実施形態において、医療機器は、一方又は両方のインタフェースに対して一定のデータストリームを提供するので、医療機器サーバにアクセスしている者は、医療機器の状態を連続的に追跡することができる。他の実施形態においては、医療機器は、定期的又は間欠的に一方又は両方のインタフェースを起動及び／又は通信し、医療機器及び医療機器サーバのうちのいずれかによって保持された操作データ又は他の情報を更新する。
【００６２】
医療機器２００は、患者インタフェース２２４も含む。患者インタフェース２２４は、ユーザに対する治療をモニタリングし、又は提供する、医療機器２００の機械的構成要素を制御する。患者インタフェース２２４は、機器の機能に基づく医療機器のタイプによって異なる。医療機器２００がモニタである場合、患者インタフェース２２４は、センサ又は他の身体検出設備を含み得る。医療機器２００が医療点滴ポンプである場合、患者インタフェース２２４は、駆動機構、オクルージョンセンサ、流量センサもしくは他の薬品制御又は供給インタフェースを含み得る。他の医療機器及び対応する患者インタフェースもまた可能である。図示しない追加的構成要素も、当該機器の具体的用途に応じて、医療機器２００の様々な実施形態に含まれ得る。
【００６３】
II.総合的ソフトウエア環境
図３〜図６は、本発明の開示の様々な実施形態に係る、医療機器ネットワーク１００及びその構成要素のための総合的ソフトウエア環境を示す。ここで開示されるソフトウエア環境は、２つのセクションに分かれる。
（１）IIIにおいて説明する、医療機器と医療機器サーバとの間の通信に関する本発明の特徴。
（２）IVにおいて説明する、医療機器動作に関するデータの閲覧、医療機器ネットワークに対する変更又は追加の管理のような、医療機器ネットワークとユーザとの相互作用を含む本発明の特徴。
両者の特徴は、一般的に、図１及び図２においてその主たる物理的特徴を記述した医療機器ネットワーク内の医療機器の統合的運用に関する。
【００６４】
ここで開示される様々なソフトウエアは、II〜IVに記述される、メタデータインストールソフトウエア、パッケージ配備ソフトウエア及びサーバソフトウエアを含み、様々な方法でパッケージ化され、様々な別の医療機器ネットワーク用に組織化される。ある可能な実施形態においては、様々なソフトウエア実施形態が、ソフトウエア配備キット（ＳＤＫ）に含まれる。当該キットは、ここで記述される様々なソフトウエア構成要素のうちのいくつか又はすべてを含む。このような実施形態においては、医療機器は、モニタ及び医療点滴ポンプを含み得る。ソフトウエアは、医療機器及び医療機器サーバの両者上で使用可能な予めパッケージ化されたメタデータファイルを含み得る。当該ソフトウエアに関するユーザ読取可能な書類も含まれ得る。
【００６５】
さらに、ここで開示され請求の範囲に記載された様々なソフトウエアは、図１及び図２のハードウエア環境内で動作可能な多くのタイプのコンピューティングシステムのうちの任意のものとして具現化され得る。例えば、コンピューティング機器は、少なくともいくつかの形状のコンピュータ読取可能な媒体を典型的に含む。コンピュータ読取可能な媒体は、コンピューティングシステムによってアクセスされ得る利用可能な媒体であれば何でもよい。コンピュータ読取可能な媒体は、限定ではない例としてはコンピュータストレージ媒体及び通信媒体を含む。
【００６６】
コンピュータストレージ媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール又は他のデータのような情報を格納する任意の方法又は技術において実装される、揮発性、不揮発性、着脱可能及び着脱不可能な媒体を含む。コンピュータストレージ媒体は、ＲＡＭ、ＲＯＭ，ＥＥＰＲＯＭ、フラッシュメモリ、他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、他の磁気ストレージ機器、又は、所望の情報を格納するために使用され、かつ、コンピューティングシステムによってアクセスされ得るあらゆる他の媒体を含むが、それらに限定されない。
【００６７】
通信媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール若しくは、搬送波又は他の搬送機構のような変調されたデータ信号内の他のデータを典型的に具現化し、あらゆる情報配信媒体を含む。変調されたデータ信号という語は、信号中の情報をコード化するような方法で設定又は変更された１つ又は複数の特徴を有する信号を意味する。限定的でない例としては、通信媒体は、有線ネットワーク又は有線直接接続のような有線媒体、並びに、音声、ＲＦ、赤外線、及び他の無線媒体のような無線媒体を含む。前記した媒体の任意の組合せもまた、コンピュータ読取可能な媒体の範囲に含まれるべきである。コンピュータ読取可能な媒体は、コンピュータプログラム製品と呼ばれてもよい。
【００６８】
図３は、本発明の開示が実施されるソフトウエア構造３００を示す。ソフトウエア構造３００は、医療機器データが格納され、医療機器の遠方から管理され得る動作環境を提供する。ソフトウエア構造３００は、様々なタイプの医療機器が動作可能な拡張可能構造も提供する。ソフトウエア構造３００は、様々な医療機器と通信接続されている１つ又は複数のコンピューティングシステムを使用し、複数の場所及び異なる企業体に亘って動作可能である。ソフトウエア構造３００は、１つ又は複数の医療機器及び医療機器サーバを含む医療機器ネットワーク内で作動する。ソフトウエア構造が作動する医療機器ネットワークの構成の候補が図１に記述されている。
【００６９】
ある実施形態においては、マイクロソフト社のマイクロソフトＳＱＬサーバ２００５というリレーショナルビジネスインテリジェントコンポーネントを使用して、ソフトウエア構造３００の特徴が実現される。このような実施形態においては、ウエブインタフェースのような様々なモジュールが、マイクロソフトインターネットインフォメーションサービス（ＩＩＳ）のようなウエブサービスを使用して提供され得る。他の可能な実施形態においては、アパッチベースの又は他のサーバのような様々なウエブサービスを併用しつつ、マイクロソフトＳＱＬサーバ２０００、オラクル、又は他のデータベース管理及びビジネスインテリジェンス製品を用いて、当該システムが実施される。
【００７０】
ソフトウエア構造３００は、１つ又は複数の医療機器３０２、バックオフィスコンポーネント３０４及びクライアントアプリケーション３０６を含む。医療機器３０２は、介護人を介して患者に対する治療をモニタリングし、提供する。医療機器３０２は、図１及び図２において説明したような様々なプログラマブル医療機器のうち任意のものであり得る。
【００７１】
バックオフィスコンポーネント３０４は、１つ又は複数の医療機器サーバ３０８、管理モジュール３１０、イベント追跡モジュール３１２、及び操作モジュール３１４を含む。医療機器サーバ３０８は、様々なモジュール３１０、３１２、３１４と医療機器３０２との間でメッセージを中継すること等により、バックオフィスコンポーネント３０４に関連付けられた様々な医療機器３０２との通信を管理する。医療機器サーバ３０８は、医療機器３０２及び様々なモジュール３１０、３１２、３１４が理解可能なメッセージを創出するので、様々なタイプの医療機器が当該モジュールを使用して管理され得る。医療機器３０２に送信されるメッセージを使用して、医療機器サーバ３０８は、医療機器から履歴情報を収集し、様々な保守操作を自動化し、ユーザのベットサイドで治療を支援し、医療機器をモニタリングする。ある可能な実施形態においては、医療機器サーバ３０８は、ＳＯＡＰ又は他のメッセージングプロトコルを介しＸＬＭ又は他のタイプのマークアップ言語を使用すること等によって、様々なタイプの医療機器と通信するためのメタデータベースのメッセージングシステムを管理する。
【００７２】
ある可能な実施形態においては、医療機器サーバ３０８は、追加的なバックオフィスコンポーネント３０４のホストであるコンピューティングシステム上に存在する。他の実施形態においては、医療機器サーバは、他のバックオフィスコンポーネントから分離したコンピューティングハードウエア上に存在する。このようなシステムにおいては、医療機器サーバ３０８は、他のバックオフィスコンポーネントとは別の場所に設置されてもよいし、以降図４及び図５において記述するように、他のバックオフィスコンポーネントとは別の事業体によって管理されてもよい。単純に言えば、ソフトウエア実施形態の記述全体を通じて、医療機器サーバという語は、選択された具体的な実施形態に応じて、医療機器サーバ３０８又はバックオフィスコンポーネント３０４の何れかを全体として含むことを意図している。いくつかの実施形態においては、医療機器サーバ３０８は、１つ又は複数の物理的コンピューティングプラットフォーム上に設置され得る。結果として、医療機器サーバは複数存在することになる。
【００７３】
管理モジュール３１０は、イベント又は操作データへのアクセスを可能にするためのような、後記する様々な理由により、医療機器サーバ３０８及びクライアントアプリケーション３０６が要求することができる管理データ３１６とのインタフェースを提供する。管理データ３１６は、ユーザ名、パスワード、ＩＰ認証又は他のユーザ認証のようなユーザ認証情報を含み、ユーザに関連付けられたアクセス権を定義する権利情報も含む。例えば、管理データ３１６は、ユーザ名をパスワードに関連付け、正しいユーザ名及びパスワードを入力し認証権を受け取ることをユーザに要求する。次に、ユーザ名とパスワードがアクセス権情報に関連付けられる。アクセス権情報は、データの具体的カテゴリ、医療機器のサブセット、又はユーザに許可されたコマンドのタイプを定義する。追加的なアクセス権が管理データ３１６において定義され、管理モジュール３１０によって管理されてもよい。
【００７４】
管理データ３１６は、医療機器サーバ３０８が医療機器３０２と交信するのに用いる操作パラメータを定義することによって、環境３００内で管理される様々な医療機器３０２の能力も定義する。例えば、患者をモニタリングする医療機器は、モニタリング機能に関する様々な定義されたパラメータを含んでもよいが、治療提供に関するパラメータを含むことにはならない。管理データ内で操作パラメータを設定することによって様々な医療機器候補の能力をユーザ定義できるようになると、環境３００は、ユーザ拡張可能なバックオフィスコンポーネントのセットを提供する。当該バックオフィスコンポーネントのセットは、異なるメーカによって製造され異なる場所に配置されている、様々な能力を有する様々な医療機器を構成に加えることが可能である。
【００７５】
特定の実施形態においては、管理モジュール３１０は、様々なクライアントアプリケーションにアクセス可能なウエブインタフェースを生成し、１つ又は複数のバックオフィスコンポーネント３０４内に保持されたデータにアクセスしようとするユーザ又は介護人を遠隔認証する。他の実施形態においては、管理モジュールは、遠隔アプリケーションがバックオフィスコンポーネント３０４によって管理されるデータにアクセスすることを可能にするインタフェースを提供する。
【００７６】
イベント追跡モジュール３１２は、医療機器サーバ３０８へのインタフェースを提供し、イベントデータ３１８を整理し、管理する。イベントデータ３１８は、医療機器３０２内で発生する様々なイベントに関する履歴データに対応する。履歴データは、医療機器サーバ３０８によって収集され送信される。イベントデータ３１８は、医療機器識別子をイベント識別子及び医療機器内で発生するイベントについての追加説明情報に関連付ける。イベント追跡モジュール３１２を使用して追跡されるイベントの例としては、電源イベント、アラームイベント、保守イベント、遠隔測定イベント、治療イベント、又は、様々な医療機器の治療変更イベントがある。様々なイベント及びこのようなイベントを追跡するために使用されるスキーマの例は、図１９〜図２４に沿って後記する。特定の実施形態においては、イベント追跡モジュール３１２は、医療機器サーバ３０８によってアクセス可能なウエブインタフェースを生成し、イベントデータ３１８の格納位置にデータを移転する。
【００７７】
操作モジュール３１４は、システム操作情報、治療命令、保守作業、及び、環境３００に関連付けられた様々な医療機器３０２の動作を行うために使用される他の情報のような、システムの様々な動作特性を管理する。操作モジュール３１４は、様々なタイプの操作データ３２０を管理するための医療機器サーバ３０８及び様々な外部コンピューティングシステムへのウエブインタフェースを提供し、これらのシステムが操作データ３２０を閲覧することを可能にし、様々な医療機器３０２に対してするように、ソフトウエア構造３００内でコマンドを伝達する。
【００７８】
オプションであるデータウエアハウス３２２は、様々なクライアントアプリケーションによる使用のために、管理データ、イベントデータ及び操作データを含む、様々な予め定義され収集されたデータを集約し統合する。図示された実施形態においては、レポーティングアプリケーションは、データウエアハウス３２２からデータを受け取る。データウエアハウス３２２は、管理データ３１６、イベントデータ３１８及び操作データ３２０からの様々なデータを集約する。データウエアハウス３２２は、これらのタイプのデータのうちの１又は複数に基づきレポートを生成するために使用可能な、便利な静的保存場所を提供する。レポート例は、IVにおいて記述されるユーザとサーバ間の通信システムとともに後記される。データウエアハウス３２２は、ＳＱＬサーバ分析サービス、Ｈｙｐｅｒｉｏｎ  Ｅｓｓｂａｓｅ、オラクルＯＬＡＰ又はデータの様々な組み合わせに対して問い合わせる又はアクセスすることを可能にする他のデータストアのような、多くのリレーショナル又はオンライン分析処理製品のうちの任意のものを使用して作成される。オプションであるデータウエアハウス３２２がない実施形態については、ここに記述されたその機能は、管理、イベント追跡、操作データベース及びそれらに対応するモジュールによって、ここに記述されたように提供され得る。
【００７９】
クライアントアプリケーション３０６は、一般的に、１つ又は複数のデータソース３１６、３１８、３２０、３２２にアクセスし、ユーザ出力フォームを生成する。ユーザ出力フォームは、介護人又は他のユーザに、当該介護人又はユーザがアクセスした医療機器についての、現在の情報又は履歴情報を示すものである。バックエンドコンポーネント３０４にアクセスするクライアントアプリケーション３０６は、管理アプリケーション３２４、レポーティングアプリケーション３２６、ダッシュボード３２８、保守フォーム３３０及び様々な追加的外部アプリケーション３３２を含む。
【００８０】
管理アプリケーション３２４によって、様々な管理ウエブフォームを含む管理データ３１６へのユーザアクセスを提供し、バックオフィスコンポーネント３０４にアクセスすることを試みる他のユーザのための使用権限を定義し、医療機器３０２の操作パラメータも定義する。管理データ３１６には、追加的な管理ウエブフォームも含まれる。
【００８１】
レポーティングアプリケーション３２６は、管理データ３１６、イベントデータ３１８及び操作データ３２０に基づいて、多くの標準化されたレポートを提供する。バックオフィスコンポーネント３０４がデータウエアハウス３２２を含む実施形態においては、レポートは、データウエアハウス内の情報に基づき得る。バックオフィスコンポーネント３０４内で追跡された様々なタイプのデータを使用して作成されたレポートの例としては、セキュリティレポート、ユーザ履歴、ソフトウエア配備レポート、医療機器プログラミングレポート、保守レポート、機器履歴レポート、治療レポート及び他のレポートがある。
【００８２】
ダッシュボード３２８は、介護人又はユーザが医療機器３０２のステータスを閲覧することを可能にする。ダッシュボード３２８は、操作データに基づき、操作モジュール３１０とインタフェースを取る。環境３００内で利用可能なダッシュボード３２８は、データを頻繁にバックオフィスコンポーネント３０４に送信することができる様々な医療機器３０２に対応する。ダッシュボード３２８は、機器によって提供された最新の治療のような、医療機器に関する操作データを受け取る。この情報は、ダッシュボードユーザインタフェース上に反映され、介護人又はユーザにアクセス可能なコンピューティングシステムの表示機器上に提示される。ある可能な実施形態においては、ダッシュボード３２８は、対応する医療機器の視覚インタフェースを、ウエブポータルフォーマットで再現する。
【００８３】
保守フォーム３３０は、介護人又は医療機器３０２の他のユーザに、保守情報を表示する。保守フォーム３３０は、実行された保守、スケジューリングされた保守、提案された保守及び保守傾向のような、操作データ３２０に含まれる追跡された保守情報を表示する。保守フォーム３３０は、ユーザが、ファームウエア更新及び他のソフトウエア配備のような、医療機器３０２に対する様々な更新を行うことを可能にする。ある可能な実施形態においては、操作データ３２０は、ユーザが保守フォームを介してアクセスできる保守スケジュール情報を含む。このような実施形態においては、保守フォーム３３０は、様々な医療機器３０２ごとに要求される追加的保守と、操作データ３２０内で追跡された保守イベント履歴とを含む、保守スケジュールをユーザに表示する。
【００８４】
様々な外部アプリケーション３３２は、操作モジュール３１４と通信することによって、ソフトウエア環境３００の機能を拡張する。外部アプリケーション３３２は、ソフトウエア環境３００の機能を拡張するために使用可能な任意のアプリケーションを含む。
【００８５】
図４は、図３に代替するソフトウエア構造４００を示し、医療機器からのデータのストレージが、医療機器が作動する施設以外の事業体によって管理される場合に使用され得る。例えば、医療機器３０２及び医療機器サーバ３０８は、郡（counties）又は民間団体のような、１つ又は複数の健康管理事業体によって経営される１つ又は複数の病院又は医療施設４０４に存在してもよい。しかしながら、これらの機器からのデータのストレージは、離れた場所にある様々な施設のデータを管理することを契約している健康管理組織又は他の組織４０５によって管理されてもよい。当該事業体は、当該施設にある医療機器サーバ３０８からデータを収集し、当該サーバ３０８は適宜次々にウエブサイトモジュール３１０、３１２、３１４のうちの１つと通信する。このような手順をとることによって、病院は、医療機器サーバ内に病院の医療機器からのデータを集約することができ、第三者は、コンピューティング構造を管理し、データの長期ストレージ、管理、アクセス及び／又はレポーティングに関する保守タスクを実行することができる。
【００８６】
図５は、図４で示されたようなソフトウエア構造の管理のためのシステム及び方法を示す。第三者は、様々な場所又はカスタマサイトに存在する様々な健康管理組織内に設置され、当該組織によって制御される医療機器から収集されたデータに関するデータ管理タスクを取扱う。図５のシステム５００の操作フローは、開始操作から始まる（ステップ５０２）。当該操作は、医療機器サーバに接続された様々な医療機器の操作によるような、システム５００の起動に対応する。
【００８７】
データ受信モジュールは、病院、クリニック又は他の管理組織のような１つ又は複数の事業体が管理する医療機器によって生成されたデータを受け取る（ステップ５０４）。ある実施形態においては、データ受信モジュールは、図４のバックオフィスコンポーネント３０４に示されるような医療機器サーバ又はクライアントアプリケーションから様々な管理データ、イベントデータ又は操作データを受け取ることに対応する（ステップ５０４）。
【００８８】
関連付けモジュールは、データ受信モジュールが受け取った（ステップ５０４）データを、受け取られたデータの起点である医療機器に関連付ける（ステップ５０６）。ある可能な実施形態においては、関連付けモジュールは、管理データ３１６において定義されたように、データを、医療機器が存在する様々な場所又は当該機器を制御する様々な事業体に関連付ける（ステップ５０６）。データの関連付けは、ファイル、テーブル又はデータベース内で発見されるような、データ間の論理的又は物理的関係であり得る。
【００８９】
ユーザが特定の病院又は場所から医療機器についての情報を検索するとき、バックオフィスコンポーネントが、関連付けモジュールの具体的な態様に応じて、当該ユーザと同じ場所にある又は同じ事業体内にある当該医療機器に関する情報のみを当該ユーザに提供することができるように、関連付けモジュールはデータを準備する（ステップ５０６）。例えば、単一の病院又は病棟は、そのデータが第三者によって収集され管理される様々な医療機器を有してもよい。当該病院又は病棟で働く医師、看護師又は他の介護人は、当該病棟内の特定の医療機器に関する情報であって、当該病棟又は病院によって制御されていない情報に対し遠隔サーバからアクセスしてもよい。
【００９０】
オプションであるプログラムモジュールは、事業体又は場所に関する特定の命令に基づいて、データ又は情報をバックオフィスコンポーネントから医療機器に分配する（ステップ５０８）。例えば、病院又は病棟は、当該病院又は病棟の医療機器に対してソフトウエアアップグレードを要求することができる。バックオフィスコンポーネントは、バックオフィスコンポーネントに関連付けられた又はバックオフィスコンポーネントにモニタリングされた他の機器を除く、当該事業体の特定のタイプの機器に対してのみ、当該病院によって要求された特定のソフトウエアアップグレードを指示する。
【００９１】
他の実施形態においては、病院又は健康管理場所にあるワークステーションは、データ受信モジュール及び関連付けモジュールを実行すること等によって当該場所にある医療機器についてのステータス情報を閲覧し得る（ステップ５０４、５０６）。当該例においては、ワークステーションのユーザは、オプションとして、医療機器の再プログラミングを選択してもよいし、当該ユーザに関連付けられた場所にある特定のタイプの医療機器すべてに対してグローバルコマンドを発信することによって再プログラミングを行うこともできる。バックオフィスコンポーネントは、適当な医療機器サーバに対し、当該場所にある医療機器に分配する必要のある特定の命令を送信するが、バックオフィスコンポーネントによって管理される、他の場所にある同じ医療機器に対して当該情報を送信することはない。
【００９２】
操作フローは、終了操作で終了する（ステップ５１０）。当該終了操作は、１つ又は複数の医療機器との通信セッションを終了することに対応する。
【００９３】
図６は、医療機器動作が相互接続されている図１の医療機器ネットワーク内で実行可能なシステム及び方法を示す。システム６００は、１人の患者に関連付けられた医療機器のグループのように、特定の場所において異なるタイプの医療機器を相互接続することに関する。システム６００は、医療機器サーバ又はバックオフィスコンポーネントによって受け取られるような、第１の医療機器によって観察された患者の行動に基づいて、医療機器サーバ又は他のバックオフィスコンポーネント上で追加的な望ましい治療を行うこと、又は、第２の医療機器を使用したモニタリング活動を行うことを決定する多くの規則を含む。
【００９４】
システム６００の操作フローは、開始操作から始まる（ステップ６０２）。当該操作は、医療機器サーバに接続された複数の医療機器を使用して患者のモニタリングを開始することに対応する。開始操作は、患者に関連付けられた第１の医療機器によってログされるような、医療機器サーバにおける少なくとも１つのイベントを受け取ることに対応する（ステップ６０２）。
【００９５】
容態受信モジュールは、当該患者に対する治療をモニタリング又は管理するために使用される第１の医療機器から、当該患者の容態を受け取る（ステップ６０４）。一例では、容態受信モジュールは、患者に関連付けられた医療機器から患者の容態を受け取り得る（ステップ６０４）。患者の容態は、心拍又は呼吸の数又は規則性、痛みがあるという患者自身による指摘、患者の血糖値さらに患者に対する管理された治療の進展を含んでもよい。患者の容態は、患者に対する治療をモニタリングする又は提供する医療機器によって生成されたアラームもオプションとして含む。
【００９６】
決定モジュールは、第１の医療機器から受け取られた患者の容態に基づき１つ又は複数の規則を実行する（ステップ６０６）。１つ又は複数の規則は、当該患者に対する治療又はモニタリングの追加又は変更のような、当該患者に関する何らかの追加的動作が必要とされているか否かを定義する。決定モジュールは、様々な規則を、変更後の治療を実行し得る特定の医療機器に関連付ける（ステップ６０６）。当該患者に対する治療を現在モニタリングしている又は現在提供している能動的医療機器に対応する規則のみが実行される。決定モジュールの実行例として、モニタが、患者が痛みを感じているということを感知し、又はその旨の報告を受けるという場合がある（ステップ６０６）。このような場合、１つ又は複数の規則は、疼痛治療が当該患者に対して利用可能であるか否かを決定し、利用可能であれば、患者に対して施すべき適当な治療を決定する。例えば、医療点滴ポンプが当該患者に関連付けられている場合、決定モジュールは、当該ポンプは疼痛治療を行い得るという結論を出し、当該患者に対する治療を提供するためのポンプパラメータを計算する（ステップ６０６）。
【００９７】
プログラムモジュールは、決定モジュールで決定された（ステップ６０６）変更後の若しくは追加的な治療又はモニタリングを提供し得るターゲット医療機器向けのプログラムを生成する（ステップ６０８）。プログラムモジュールは、治療に対する変更又は追加を、当該患者の介護人にアクセス可能なワークステーション又は当該治療を施し得る医療機器の何れかに送信する（ステップ６０８）。ある実施形態においては、プログラムモジュールは、介護人が決定モジュールで決定された（ステップ６０６）提案治療を承認することを要求する（ステップ６０８）。他の実施形態においては、プログラムモジュールは、治療を行うことができる医療機器を直接プログラミングするので、追加的な介護人の承認又は関与がなくても当該治療が行われ得る（ステップ６０８）。
【００９８】
操作フローは、終了操作で終了する（ステップ６１０）。終了操作は、医療機器サーバがワークステーション又は医療機器へ決定された治療を送信することを終了することに対応する。
【００９９】
III.医療機器とサーバ通信
図７〜図３５は、図１及び図２に示された医療機器と医療機器サーバ又は他のバックオフィスコンポーネントとの間の通信のための様々なシステム及び方法を一般的に記述する。当該セクションで記述されるシステム及び方法は、医療機器ネットワーク内の医療機器の統合的運用に関する。当該統合的運用は、１つ又は複数の施設、組織、時間帯又は他の論理要素に亘る。これらのシステムは、ユーザが、IVで後記する医療機器ネットワークと相互作用している間に使用され得る。ユーザとの関与は、医療機器の統合的運用、及び医療機器ネットワーク内の医療機器からのデータの収集及び通信に関する。
【０１００】
図７及び図８には、医療機器サーバと様々なタイプの医療機器との間の通信が記述されている。医療機器サーバ及び医療機器によって使用される通信方法は、拡張可能なシステムを提供する。当該システムは、医療機器サーバが、様々な医療機器メーカによって製造され、異なる通信プロトコル、能力及び他の特性を有する、様々な異なるタイプの医療機器と通信することを可能にする。
【０１０１】
図７は、医療機器サーバが遠隔的に位置している医療機器と結合している典型的な拡張可能システム７００を示す。システム７００は、医療機器サーバに関連付けられている医療機器のステータスを追跡し、新規の及び既存の医療機器を医療機器サーバに関連付け、拡張可能な医療機器ネットワークを提供する。当該医療機器ネットワークは、様々な異なる病院又は病院内の異なる場所に設置される様々なタイプ及びブランドの医療機器が相互通信することを可能にする。システム７００においては、医療機器サーバによって識別される医療機器のそれぞれは、当該サーバ上のテーブルに保持される関連付けられた状態を有することになる。したがって、システム７００は、当該サーバに関連付けられた医療機器ごとに、当該サーバ上で独立して作動する。システム７００は、開始ノード７０２から始まる。当該ノードは、図１に示されたように、医療機器サーバを含む医療機器ネットワークに医療機器を接続することに対応する。
【０１０２】
医療機器に接続されると、医療機器サーバは、当該医療機器が既知のタイプであるか否かを決定しなければならない。医療機器が未知のタイプである場合は、操作フローは、既知の状態７０４に移行する。既知の状態は、医療機器の能力についての情報を受け取ることに対応する結果、医療機器は、医療機器ネットワークに追加され得る。既知の状態７０４は、医療機器の操作能力を記述するユーザ入力を受け付けることに起因してもよいし、医療機器と医療機器サーバとの間の通信又はテストを含んでもよい。医療機器サーバが、ある機器は既知状態７０４に対応する既知の状態にあると判断した場合、医療機器サーバは、当該医療機器を認識された機器として扱う。しかし、当該機器はシステムによって電源が投入されていないか、システムによって認識されていない。医療機器が既知のタイプである場合は、操作フローは、決定ノード７０６に移行する。この決定ノード７０６は、医療機器の状態を決定することに対応する。
【０１０３】
４つの操作状態が、医療機器サーバの観点から医療機器の操作を定義する。４つの操作状態とは、電源投入状態７０８、治療状態７１０、故障状態７１２及びアラーム状態７１４である。電源投入状態７０８は、電源が投入されており、通常の操作を行っているが、患者に対する治療のモニタリングを行う又は治療を提供するために使用されていない医療機器に対応する。医療機器が医療機器サーバに対して、医療機器に電源が投入されたという指示を送信すると、既知状態７０４又は決定ノードから電源投入状態７０８に移行する。医療機器サーバは、操作継続状態、すなわち治療状態７１０、故障状態７１２及びアラーム状態７１４からも、電源投入状態に移行する。当該パスで電源投入状態に移行するのは、医療機器サーバが医療機器をこれらの状態のうちの１つに関連付けている条件を当該医療機器が除去したという指示を医療機器サーバが受け取ったときである。
【０１０４】
治療状態７１０は、医療機器が現在動作中である、治療を提供している、又は患者をモニタリングしているということを、医療機器サーバに対し送信している医療機器に対応する。医療機器が取る特定の動作は、当該特定の医療機器の特性によって決定される。しかしながら、医療機器サーバは、医療機器が現在操作中であることを認識することのみを必要とする。システム７００は、他の操作状態７０８、７１２、７１４のうちの何れからも、又は決定ノード７０６からも、治療状態に移行し得る。医療機器が成功裏に治療を終了すると、当該医療機器はその旨のイベントを医療機器サーバに送信する。医療機器サーバは、当該機器に関連付けられているテーブルエントリを電源投入状態７０８に戻す。医療機器が、故障又はアラームイベントに起因して治療を終了できない場合は、当該医療機器はその旨のイベントを医療機器サーバに送信する。医療機器サーバは、当該機器に関連付けられているテーブルエントリを適当な操作状態に変更する。
【０１０５】
故障状態７１２は、モニタリング中又は治療提供中の当該医療機器の故障のように、医療機器内で発生したエラーに対応する。故障状態７１２へは、電源投入状態７０８又は治療状態７１０の何れかから移行し得る。決定ノード７０６からも移行し得る。ある可能な実施形態においては、故障状態７１２は、故障が発生した医療機器を制御している介護人が通知を行うトリガとなり得る。他の実施形態においては、医療機器サーバが、テーブル内に故障状態エントリを生成する指示を受け取ったとき、当該サーバは、当該医療機器で発生している故障を決定し、エラーを訂正し得る。故障状態が解消されると、医療機器は、当該医療機器は前の操作状態に戻った、又は決定ノード７０６から戻った場合は電源投入状態７０８に移行した旨の指示を医療機器サーバに送信する。医療機器の状態を追跡する医療機器サーバに保持されているテーブルは、適宜更新されて、当該医療機器の状態を反映する。
【０１０６】
アラーム状態７１４は、医師、看護師又は他の介護人の注意を要求するイベントが医療機器内で発生しているという指示を当該医療機器から医療機器サーバが受け取ることに対応する。例えば、医療機器は、治療用の薬品が切れた医療点滴ポンプであり得る。他の例では、医療機器は心拍数モニタであり、イベントとは異常に低い又は高い心拍数をモニタリングし検出することである。アラーム状態７１４へは、電源投入状態７０８又は治療状態７１０の何れかから移行し得る。決定ノード７０６からも移行し得る。アラーム状態が解消されると、医療機器は、当該医療機器は前の操作状態に戻った旨の指示を医療機器サーバに送信し、テーブルが適当に更新される。
【０１０７】
非稼動状態７１６へは、電源投入状態７０８、治療状態７１０、故障状態７１２又はアラーム状態７１４を含む動作状態の何れかからも移行し得る。非稼動状態７１６は、医療機器サーバが、医療機器が作動中であるか否かを決定することができない又は医療機器がどの状態にあるかを決定することができないことに対応する。非稼動状態７１６は、医療機器サーバのユーザに、医療機器を医療機器サーバに正しく関連付けるために医療機器に対する注意が必要であることを示す。
【０１０８】
システム７００の操作例では、医療機器が医療機器ネットワークに導入されたとき、医療機器サーバは、どのように医療機器と通信するかを知っている場合もあり、知らない場合もある。医療機器が既知のものであり、現在電源を投入されていないとすると、いずれ医療機器サーバは既知状態７０４に移行することになる。医療機器の電源が投入されたとき、当該医療機器は、電源投入メッセージをサーバに送信する。当該メッセージは、テーブルを更新し、当該医療機器が電源投入状態７０８にあることを示す。医療機器が治療を行うとき、医療機器はサーバにメッセージを送信し、医療機器サーバは、当該医療機器を治療状態７１０に関連付ける。医療機器が成功裏に治療の提供を終了したとき、医療機器は、サーバにメッセージを送信する。当該メッセージは、当該機器のテーブルエントリを治療状態７１０から電源投入状態７０８に変更する。何らかの理由で医療機器が故障した場合、医療機器は故障メッセージをサーバに送信する。当該メッセージは、当該医療機器が故障状態７１２にあるとみなす。
【０１０９】
医療機器が薬品切れを起こし又は患者の危険条件を検出した場合は、当該機器は、サーバにアラームメッセージを送信する。当該メッセージは、医療機器をアラーム状態７１４に関連付ける。機器が治療の提供を終了したとき、当該機器は、治療の提供が終了したというメッセージをサーバに送信し、サーバは、当該医療機器を電源投入状態７０８に関連付ける。介護人は医療機器の電源を切ってもよい。機器の電源を切る前に、介護人はサーバにメッセージを送信する。当該メッセージは、当該医療機器を既知状態７０４に関連付ける。
【０１１０】
図８は、医療機器サーバ及び医療機器を統合する通信システム８００の例の図である。通信システム８００は、医療機器のような外部装置から入力メッセージを受け取り、処理し、格納する。ある実施形態においては、通信システム８００は、ＳＯＡＰプロトコルのような、メタデータベースの通信プロトコルを使用する。このようなシステムにおいては、医療機器サーバは、メッセージスキーマファイルを使用して医療機器から受け取ったメッセージを有効化する。
【０１１１】
通信システム８００では、医療機器８０２から送信されたメッセージが医療機器サーバ８０４によって受け取られる。当該医療機器サーバ８０４は、機器サーバオブジェクト８０６、メッセージハンドラ８０８及びデータ階層８１０を含む。医療機器８０２は、医療機器サーバと通信可能な多くの医療機器のうちの任意のものであり得る。医療機器の様々な実施形態が図２とともに前記されている。
【０１１２】
医療機器サーバ８０４は、医療機器から情報を収集し医療機器の設定とモニタリングを支援する多くの汎用コンピュータのうちの任意のものであり得る。医療機器サーバ８０４は、機器サーバオブジェクト８０６を含む。機器サーバオブジェクト８０６は、医療機器サーバから送信され受け取られたメッセージを取扱い、当該メッセージを構文解析し、当該メッセージが、医療機器サーバが当該メッセージに基づいて動作するために必要な情報を含んでいることを決定する。例えば、機器サーバオブジェクトは、メッセージに含まれる様々なメタデータタグ及びメタデータに関連付けられているデータを構文解析し、メッセージタイプ、発信元又は宛先機器識別子又はネットワーク識別子、及び、メッセージデータを確認する。
【０１１３】
典型的なメッセージ内容は、機器サーバオブジェクト８０６の様々な特徴を記載する。システム内に具体化される様々な機器ハンドラについても同様である。機器サーバオブジェクト定義の一例は以下の通りである。
<Feature>
<Id>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</Id>
<LicenseId> XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</LicenseId>
<Name>Medical Device Secured Server</Name>
<Provider>MedicalDeviceServer.MedicalDeviceSoapTcpServer,MedicalDeviceServer.
MedicalDeviceSoapTcpServer.MedicalDeviceSoapSecureTcpServer</Provider>
<Description>Receives inbound connection over SSL secured TCP/IP 
networks.</Description>
<Type>Server</Type>
</Feature>
【０１１４】
この例では、Featureタグは、オブジェクトを機器サーバオブジェクトの特徴として定義する。Idタグは、GUID、すなわち特徴を識別するために使用される統計的に一意な番号を定義する。LicenseIdタグは、定義された特徴を含むライセンスを識別する。Nameタグは、特徴の名称を提供する。Providerタグ、Descriptionタグ及びTypeタグは、オブジェクトの様々な実施詳細を定義する。追加的な実施詳細があってもよい。
【０１１５】
１つ又は複数のメッセージハンドラ８０８は、機器サーバオブジェクト８０６から、もとのフォーマットのメッセージを受け取り、当該メッセージを処理し、医療機器サーバ８０４のデータ階層８１０によって理解可能かつ格納可能なフォーマットに当該メッセージを変換する。受け取られたメッセージのタイプにより、様々なハンドラに受け取られたメッセージが割り当てられる。各ハンドラは、所与の方法で、特定のタイプのメッセージを処理する。ある実施形態においては、メッセージハンドラは、アラームハンドラ、故障ハンドラ、保守ハンドラ、電源ハンドラ、要求ハンドラ、様々な遠隔測定ハンドラ及び様々な治療ハンドラを含む。医療機器サーバ８０４によって管理されるメッセージの様々なタイプによっては、ハンドラを追加することも減らすこともが可能である。
【０１１６】
第２の典型的なサーバオブジェクト定義は、メッセージハンドラ８０８の様々な特徴を記述する。
<Feature>
<Id>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</Id>
<LicenseId> XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX </LicenseId>
<Name>Medical Device Event Handler</Name>
<Provider>Informatics.BackOffice.MedicalDeviceServer</Provider>
<Description>Validate received events and stores them in the Operations 
database</Description>
<Type>Handler</Type>
</Feature>
【０１１７】
メッセージハンドラ８０８の当該例は、機器サーバオブジェクト８０６の記述と類似しているが、メタデータが特徴を定義するハンドラを定義することを示すProviderタグを使用して定義される。メッセージハンドラ８０８は、以下のコードを使用して機器サーバオブジェクト８０６と結合している。
<Handler>
…
<FeatureId>XXXXXXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX</FeatureId>
<HandlerId>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</HandlerId>
…
</Handler>
【０１１８】
特徴８０６をハンドラ８０８に結合させることによって、医療機器サーバ８０４は、特定のタイプのデータを適切なハンドラに送信できる。
【０１１９】
データ階層８１０は、メッセージハンドラ８０８からストレージ用のメッセージを受け取り、ＳＯＡＰベースのメッセージに変換し又は機器サーバオブジェクト８０６を介して医療機器に送信するためのデータを、リクエスティングメッセージハンドラ８０８に提供することによって、データ要求に応える。
【０１２０】
Ａ．メタデータプログラミング及び通信
図９〜図１６では、様々な医療機器の操作特性を定義するために使用されるメタデータをリストにするプログラミングスキーマが開示される。メタデータは、医療機器サーバが、医療点滴ポンプ又は他の治療提供又はモニタリング設備のような、様々な医療機器と通信することを可能にする。医療機器を、特有のインタフェースというより医療機器の動作特性の観点から医療機器サーバ内に定義することによって、医療機器サーバは、医療機器のタイプごとの内部動作を理解する必要がなくなる。むしろ、予想される医療機器の動作に基づいて、サーバは、いかに当該医療機器と通信するかを理解することになる。一般的に、開示されたメタデータスキーマは、図８に前記されたようなＸＭＬプロトコル及びＳＯＡＰベースメッセージングシステムを使用して作動する。しかしながら、他の標準化された通信方法論も使用され得る。
【０１２１】
図９は、医療機器と医療機器サーバとの間を通信するシステム及び方法を示す。図２において前記したように、図示されたシステム９００は、様々なタイプ及びブランドの医療機器に拡張性を提供する。医療機器サーバは、医療機器ごとに関連付けられたパラメータと、予め決定されたメタデータのセットを定義することによって医療機器と通信することが可能である。システム９００は、開始操作でインスタンスを作成する（ステップ９０２）。開始操作は、医療機器を医療機器サーバと通信可能に接続することに対応する。ある実施形態においては、通信可能な接続は、図１に示されたネットワークのように、医療機器サーバを含む医療機器ネットワークに医療機器を導入することに対応する。他の実施形態においては、通信可能な接続は、ソフトウエア開発キット内で供給される、さもなければ、本発明の開示に合致するように供給される、メタデータ通信レイヤをインストールするためのソフトウエアを使用して医療機器にメタデータパッケージをインストールすることに対応する。
【０１２２】
関連付けモジュールは、医療機器サーバのデータベース中で様々な医療機器にメタデータを関連付ける（ステップ９０４）。医療機器は対応するメタデータを格納するので、関連付けられたメタデータは、当該医療機器上のメタデータセットに対応する。メタデータは、すべての医療機器に共通する少なくとも１つの属性又は動作特性に対応し、医療機器ネットワーク内の様々な医療機器を区別し、識別し、それらの医療機器と通信を行う。様々な可能な実施形態においては、メタデータによって定義された動作特性は、患者情報、ユーザ又は介護者情報、制御情報、薬品情報又は場所情報を含む。図１１〜図１６の１つ又は複数のスキーマに記述されているように、追加的な動作特性が含まれてもよい。メタデータは、電源イベント、アラームイベント、保守イベント、遠隔測定イベント、治療イベント、治療変更イベント又は他のイベントのような、医療機器内で発生する様々なイベントにも対応する。追加的なイベントが図１７〜図３３に記述されている。
【０１２３】
格納モジュールは、メタデータを、医療機器サーバ又はバックオフィスコンポーネント上に格納する（ステップ９０６）。医療機器は、メタデータ及び図８ともに前記したメタデータベースのメッセージングシステムを使用することによって、各医療機器と通信する。操作フローは終了操作に進む（ステップ９０８）。終了操作は、医療機器と医療機器サーバとの間の通信スキーマの確立を終了することに対応する。
【０１２４】
図１０は、医療機器と医療機器サーバとの間で通信するための他のシステム及び方法を示す。図１０のシステム１０００は、医療機器ネットワーク内のすべての医療機器に共通なメタデータを格納し、医療機器のサブセットに特有な情報も格納する。このようにすれば、これらの医療機器と医療機器サーバとの間の通信をカスタマイズすることができる。システム１０００の操作フローは、開始操作から始まる（ステップ１００２）。当該操作は、医療機器ネットワーク内の医療機器サーバに医療機器を通信可能に接続することに対応する。
【０１２５】
開始操作の後、操作フローは、一般的関連付けモジュールに進む（ステップ１００４）。一般的関連付けモジュールは、図９の関連付けモジュールに対応する（ステップ９０４）。ここでは、一般的関連付けモジュールは、予め決定されたメタデータのセット及び医療機器ごとに関連付けらたパラメータを定義することによって、医療機器ネットワーク内の各医療機器の特性を定義するメタデータを関連付ける（ステップ１００４）。カスタムメタデータモジュールは、メタデータを１つ又は複数の医療機器に関連付ける（ステップ１００６）。当該メタデータは当該機器に特有のものである。カスタムメタデータの例としては、特定タイプの医療機器内で発生する特定の電源イベント、これらの機器によってサポートされた特殊化された通信タイプ、又は、医療機器ネットワーク内のすべての医療機器の一部について定義された他の操作パラメータがある。格納モジュールは、図９の格納モジュールに一般的に対応し（ステップ９０６）、一般的なメタデータ及びカスタムメタデータをサーバ上に格納する（ステップ１００８）。
【０１２６】
機器選択モジュールは、医療機器サーバに格納されている当該機器を定義するメタデータに基づき、医療機器ネットワーク内の、通信すべき１つ又は複数の医療機器を選択する（ステップ１０１０）。ある実施形態において、機器選択モジュールは、医療機器からメッセージを受け取ると実行する。他の実施形態においては、医療機器サーバは、１つの医療機器から事前の信号通信を受け取らずに、１つ又は複数の医療機器を選択し、当該医療機器と通信する。
【０１２７】
通信モジュールは、機器選択モジュールにおいて決定された（ステップ１０１０）、選択された医療機器にメッセージを送信する（ステップ１０１２）。通信モジュールは、医療機器に送信するためのＳＯＡＰベースのメッセージを作成する。当該メッセージは、医療機器及び当該医療機器に送信されるべきデータを識別する宛先情報を含む。当該メッセージは、図１１〜図１６、図１９〜図２４で後記されるような、システム１０００によって理解されるスキーマ内で定義されるメタデータタグによって識別される様々な情報を含む。操作フローは終了操作で終了する（ステップ１０１４）。当該終了操作は、医療機器へのメッセージの送信を終了することに対応する。
【０１２８】
図１１〜図１６は、医療機器及び医療機器サーバのための拡張可能な通信システムを容易にするために使用可能なメタデータを含む様々なスキーマを示す。スキーマは、図１の医療機器ネットワーク内で使用され、様々な医療機器及び医療機器サーバを識別し、医療機器が当該機器と通信することを可能にする。スキーマは、ネットワーク内のすべての医療機器に共通な、又は、１つ又は複数の医療機器に特有の、様々な操作パラメータ又は属性を含む。開示された様々なスキーマを使用することによって、医療機器サーバは、医療機器を識別し、当該機器の特性を識別することができ、（１）当該機器の能力及び制限を知ることによって、また、（２）他の医療機器と拡張可能な通信プロトコルを共有することによって、どのように当該機器と相互動作するかを知ることができる。
【０１２９】
図１１は、医療機器サーバと通信可能に接続された各医療機器の様々な操作特性を識別するために使用される識別スキーマ１１００を示す。識別スキーマ１１００は、様々なグローバルパラメータを含むメインテーブル１１０２、ネットワークテーブル１１０４、アクセステーブル１１０６及び１つ又は複数のパッケージテーブル１１０８を含む。メインテーブル１１０２は、機器タイプ、機器識別子、セッション識別子、ネットワーク識別子、アクセス識別子及びパッケージアクセプタンスを含む、様々な汎用機器識別特性に関連付けられたメタデータを含む。機器タイプは、当該機器の製造者及び型式のような、医療機器のタイプの識別情報に関するものもあり、一方、機器識別子は、各機器に特有なものもある。セッション識別子、ネットワーク識別子及びアクセス識別子は、メッセージが医療機器に正しく送信されることを可能にする接続文字列を定義する。パッケージ識別子は、医療機器が医療機器サーバからパッケージを受け取り、各機器上で使用可能な現在のパッケージを示すテーブルにリンクすることができるか否かを示す。
【０１３０】
ネットワークテーブル１１０４、アクセステーブル１１０６及びパッケージテーブル１１０８を含む残りの操作継続テーブルは、医療機器の接続及び能力に関する追加情報を提供し、メインテーブル１１０２のネットワーク識別子、アクセス識別子及びパッケージ識別子によって、メインテーブルにリンクされている。ネットワークテーブル１１０４は、インターネット上での医療機器への接続を定義するために必要な、ホスト、ドメイン、ＩＰアドレス及びポート情報を含む。アクセステーブル１１０６は、当該物理機器を当該ＩＰアドレスへ対応させる特定のネットワーク接続に対応する、ＩＰアドレス及び物理Ｉｄを含む。パッケージテーブル１１０８は、ソフトウエアパッケージの名称及びバージョンのような、医療機器によって使用されるソフトウエア又はファームウエアパッケージの追加詳細情報を記述する。医療機器へのパッケージ配備に関する追加詳細情報は、図２５〜図３３とともに後記される。
【０１３１】
図１２は、医療機器と医療機器サーバとの間でメッセージを送信し、メッセージの要素を追跡するロジスティクスを記述する要素を含む制御テーブル１２００を示す。図示された制御テーブル１２００は、メッセージ識別子、タイムスタンプ及び応答メタデータを含む。メッセージ識別子は、メッセージを追跡するために使用される識別文字列を提供し、識別子により医療機器が識別される。タイムスタンプは、メッセージが医療機器サーバ又は医療機器から送信された時刻を示す。応答は、メッセージが医療機器から来ているかそれともサーバからの応答であるかを示すブーリン型の値を提供する。メッセージ追跡に関する追加的なメタデータも、制御テーブルに含んでもよい。
【０１３２】
図１３は、医療機器と関連付ける患者情報を追跡するために使用される患者テーブル１３００を示す。患者テーブル１３００は、識別子及び氏名要素を含む。氏名要素は、患者の氏名に関するメタデータを有し、識別子は、患者を統計的に一意に識別する。他の患者に関するメタデータも含まれ得る。
【０１３３】
図１４は、患者の場所を示すために使用される場所テーブル１４００を示す。場所テーブル１４００は、エイリアス要素及び記述要素を定義するメタデータを含む。記述要素とは、“病院Ｘ，新生児科，部屋１”のような患者の場所の言語的記述である。エイリアス要素は、場所を医療機器に関連付けるために使用される省略コードを提供する。患者又は医療機器の場所を記述する追加的なメタデータも場所テーブル１４００に含まれ得る。
【０１３４】
図１５は、薬品と医療機器との関連付けがなされている場合に、医療機器に関連付けられている薬品を示すために使用される薬品テーブル１５００を示す。いくつかの医療機器のみが患者に対する薬品ベースの治療を提供することができるという事実があれば、薬品テーブルは、医療機器ごとに追加作成されてもよいし、されなくてもよい。薬品テーブルは、薬品識別子、薬品名称及び薬品濃度に関するメタデータを含む。医療機器によって使用される薬品をさらに識別又は記述するために、追加的なメタデータが使用され得る。
【０１３５】
図１６は、医師、看護師又は医療機器を現在制御している他の介護人に対応するユーザテーブル１６００を示す。ユーザテーブル１６００は、ユーザ識別子、ユーザ氏名及びシステムの操作に必要なユーザの追加識別特性に関するメタデータを含む。
【０１３６】
Ｂ.イベントログ及び保守
図１７〜図２４においては、図１の医療機器ネットワークにおいて使用され、医療機器サーバに関連付けられた様々な医療機器のイベント及び保守実施形態を追跡するシステム、方法及びスキーマが開示される。これらのイベントベースのスキーマは、医療機器ネットワーク内の医療機器の現在の及び過去の実績を追跡するため及び医療機器を保守するために使用され得る。後記するスキーマは、メッセージシステムを定義し、医療機器ネットワーク内の医療機器又は他のバックオフィスコンポーネントによって格納されるイベントの順序付けも定義する。医療機器サーバの比較的一定な操作特性に関する、II.Ａで記述されたスキーマとの比較では、イベントロギング及び保守追跡スキーマは、医療機器ネットワーク内で発生する特定のイベント又はタスクを定義する。
【０１３７】
図１７は、図１９〜図２４に記述された様々なイベントベースのメッセージスキーマを使用する医療機器サーバ又はバックオフィスコンポーネントから生じるイベントログを受け取るための方法及びシステムを示す。システム１７００は、医療機器ネットワークの医療機器サーバ又はバックオフィスコンポーネント上で実行され、これらのコンポーネントによって管理される１つ又は複数のデータベースに格納されるイベントログデータを提供する。
【０１３８】
システム１７００の操作フローは、医療機器ネットワークの初期操作に対応する開始操作から始まる（ステップ１７０２）。操作フローは、イベント受信モジュールに進む（ステップ１７０４）。イベント受信モジュールは、医療機器サーバに関連付けられた様々な医療機器からイベントログデータを受け取る（ステップ１７０４）。イベントログデータは、医療機器内で発生するイベントを表し、電源イベント、遠隔測定イベント、アラームイベント、治療イベント、保守イベント又は図１９〜図２４のスキーマにおいて定義されるような他のイベントのような多くのタイプのイベントのうちの任意のものであり得る。
【０１３９】
メッセージ本文例は、医療機器から医療機器サーバへのイベントの通信を例示する。当該例においては、医療機器は、当該ポンプに電源が投入されたことを示す電源イベントを、医療機器サーバに送信する医療点滴ポンプである。
<env:Body><mds:PowerEvent xmlns:mds:=’mds:xml-schema:soap11’>
<Trigger>on</Trigger>
<Message>Normal Power Up Complete</Message>
<Timestamp>1900-01-01T00:00:08</Timestamp>
<Medfusion4000_Power>
<Source>AC</Source>
<Capacity>90.0％</Capacity>
</Medfusion4000_Power>
</mds:PowerEvent></env:Body>
【０１４０】
当該メッセージ部分は、これがメッセージ本文であり、ＳＯＡＰ1.1メッセージングプロトコルを使用していることを識別している。ポンプから送信されたメッセージは、電源投入処理が終了していることを示し、当該ポンプによって割り当てられたタイムスタンプを含む。様々な電源パラメータは、図１９の電源イベントテーブルに含まれるパラメータに対応し、医療点滴ポンプによって特定の値に関連付けられている。メッセージが医療機器サーバによって医療点滴ポンプから受け取られ、当該値は、電源イベントスキーマに対応する適切なイベントテーブルに格納される。
【０１４１】
同様なメッセージが医療機器から医療機器サーバに送信され、ここで記述されたように、医療機器ネットワーク内で追跡される他のタイプのイベントに関連付けられた応答が当該サーバから当該医療機器に返信される。
【０１４２】
ストレージモジュールは、医療機器からサーバへのメッセージにおいて定義されたように、正しいメタデータに関連付けられたイベントログデータをデータベースに格納する（ステップ１７０６）。ある実施形態においては、ストレージモジュールは、図３及び図４のイベントデータにイベントログデータを格納する（ステップ１７０６）。
【０１４３】
要求受信モジュールは、医療機器サーバ又は他のバックオフィスコンポーネントに格納されているイベントログデータに対する要求を受け付ける（ステップ１７０８）。受け取られた要求は、ワークステーション、携帯コンピューティング機器又は他のタイプのコンピューティングシステムから来てもよい。当該要求は、日付範囲、介護人の氏名又は識別子、患者の氏名又は識別子、薬品の名称又は識別子、特定の機器、又は、イベントログデータに関連付けられた他のタイプの情報のような、１つ又は複数のナローイングパラメータを含む。ある例においては、要求受信モジュールは、医療点滴ポンプによる特定の薬品の提供に関連するイベントログデータに対する要求を受け取る（ステップ１７０８）。
【０１４４】
結果生成モジュールは、当該要求のナローイングパラメータに基づいて、医療機器サーバ又はバックオフィスコンポーネントによって保持されるイベントログデータをフィルタリングすること等によって、要求受信モジュールによって受け取られた（ステップ１７０８）特定の要求に基づいて、結果を生成する（ステップ１７１０）。結果生成モジュールは、オプションとして、要求があったコンピューティングシステムに結果を送信する（ステップ１７１０）。要求受信モジュールに記述されている（ステップ１７０８）例を使用して、医療機器サーバは、識別されたポンプによって識別された薬品の提供に関するイベントログデータを返信するクエリを生成する。このクエリは、ＳＱＬ又は他のデータベースクエリ言語で作成されるので、医療機器サーバに結合しているデータベース管理システムは、クエリ結果を返信し得る。
【０１４５】
操作フローは、終了操作で終了する（ステップ１７１２）。終了操作は、結果を生成し、当該結果を要求のあったコンピューティングシステムに送信することを終了することに対応する。
【０１４６】
図１８は、医療機器に予防保守データを通信するシステム及び方法を示す。システム１８００は、図１１〜図１６のメタデータと図１９〜図２４の追加的イベントメタデータを使用し、医療機器ネットワーク内の１つ又は複数の医療機器上で実行されるべき保守タスクを追跡し通信する。図１７とともに記述された様々なメッセージ送信原則が、通信の発生を可能にする。
【０１４７】
システム１８００は、医療機器ネットワークの初期操作に対応する開始操作から始まる（ステップ１８０２）。操作フローは、ストレージモジュールに進む（ステップ１８０４）。ストレージモジュールは、１つ又は複数の医療機器に結合している医療機器サーバ上に保守スケジュールを格納する。保守スケジュールは、医療機器サーバ又はバックオフィスコンポーネントのデータベースに格納され、スケジュールに含まれる保守リマインダイベント用の時刻値と、医療機器用の時刻値を含む。保守スケジュールは、オプションとして、要求された操作ソフトウエア更新又は他の設定パラメータのような保守データを参照する。
【０１４８】
ある例では、ストレージモジュールは、一連の医療点滴ポンプについて定期的に行うことを提案された、又は、特定の医療点滴ポンプについて行うことを提案された再較正（recalibration）の指示を含む保守スケジュールを格納する（ステップ１８０４）。このような例では、ストレージモジュールは、医療点滴ポンプのユーザ又は製造者によって提供された保守スケジュールを格納することができ、指示された保守が予定されているときは、当該ポンプのユーザにリマインダを提供する（ステップ１８０４）。
【０１４９】
送信モジュールは、保守イベントが発生したとき、保守スケジュールに関連付けられた１つ又は複数の医療機器にリマインダを送信する（ステップ１８０６）。リマインダは、医療点滴ポンプに関連付けられたディスプレイ上に表示されるユーザ読取可能なメッセージであってもよい。当該メッセージは、再較正が提案されていることを介護人に示す。又は、リマインダは、医療機器上にユーザ読取可能なメッセージが格納されるトリガとなってもよい。
【０１５０】
送信モジュールは、オプションとして、保守リマインダに関連付けられた保守データを送信する（ステップ１８０６）。システム１８００のある実施形態においては、送信モジュールによって送信されたリマインダは、医療機器を無効にする（ステップ１８０６）。他の実施形態においては、リマインダは、医療機器が操作を継続することを可能にする。他の実施形態においては、リマインダは、要求されている医療機器の保守を実行する所定時間前に送信される。
【０１５１】
保守イベントは、ストレージモジュール（ステップ１８０４）からの医療点滴ポンプの操作例を継続している医療点滴ポンプに送信される。保守イベントは、医療機器に対し、当該機器の保守が必要であることを示し、医療点滴ポンプの表示装置上に表示される、“保守が要求されています。製造者に連絡して下さい”又は保守を要求する他の指示のような、リマインダメッセージを含む。ある設定では、保守イベントは、当該医療機器の保守及びケアに関する特定の指示を有する製造者に介護人が連絡するまで、医療機器が操作を継続することを可能にする。
【０１５２】
操作フローは、終了操作で終了する（ステップ１８０８）。終了操作は、保守リマインダ及び対応する任意の保守データを医療機器に送信することを終了することに対応する。
【０１５３】
図１９〜図２４は、医療機器と医療機器サーバとの間で通信し、応答するためのイベントベースのスキーマを示す。開示されるスキーマは、図１の医療機器ネットワークで使用可能であり、医療機器サーバ及びバックオフィスコンポーネントがイベントログを収集し、医療機器にメッセージを送信することを可能にする。ネットワークの医療機器及び医療機器サーバは、後記のメタデータを使用して、メッセージ及びイベントデータを送信し、
メッセージ内容を識別する。医療機器サーバ又はバックオフィスコンポーネントは、メタデータに対応付けてイベントデータを格納する。
【０１５４】
図１９は、電源イベントテーブル１９００及び電源イベント応答テーブル１９１０を示す。テーブル１９００、１９１０は、機器電源投入、機器電源切断、バッテリ警告及び他の電源関連イベントのような、医療機器内の様々な電源イベントを追跡するために使用されるメタデータを定義する。電源イベントテーブル１９００は、トリガ、メッセージ及びタイムスタンプに関するメタデータを含む。トリガは、機器電源投入、機器電源切断又は機器の電源ステータスの更新のような、医療機器の変更イベントに対応する。メッセージは、バッテリ残量低下警告、電源投入イベント発生、電源切断イベント発生又は他の電源関連イベントのような、医療機器に発生した特定のイベントを記述する。タイムスタンプは、医療機器に当該電源イベントが起きた時刻を示す。
【０１５５】
電源イベント応答テーブル１９１０は、医療機器サーバによって受け取られた電源イベントに対する様々な応答候補を定義するメタデータを含む。例えば、医療機器サーバが電源投入イベントを受け取ったとき、当該サーバは、特定の保守タスクが要求されていること、ダウンロードすべきソフトウエア又はファームウエアが利用可能であることを返信してもよい。電源イベント応答テーブルは、結果、メッセージメタデータ、セッションメタデータ、間隔メタデータ及びパッケージメタデータを含む。結果メタデータは、医療機器の状態変化、又は受け取られたイベントのサーバ認識可能な様々な他の結果のような、電源イベントの結果に関する。メッセージメタデータは、医療機器に関連付けられた表示装置に応答メッセージの内容を記述するような、医療機器に送信されるべきメッセージを含む。セッションメタデータは、医療機器サーバ間の通信セッションに関する情報を含む。間隔メタデータは、医療機器からサーバへの通信の期待される間隔に関する情報を含む。当該情報は、IVで後記するように、医療機器のオンラインステータスのサーバ検出に関する。パッケージメタデータは、医療機器が新たなパッケージ情報を利用可能であるか否か、図２５〜図３３のパッケージ配備方法及びシステムを介して何が提供され得るか、のような機器に対する指示を提供する。追加的なメタデータが、応答テーブル１９１０及び対応する応答メッセージに含まれてもよい。
【０１５６】
図２０は、アラームイベントテーブル２０００及びアラームイベント応答テーブル２０１０を示す。アラームイベントは、医療機器内でトリガを受けたアラームとの起動及び消去と、医療機器によって生成され医療機器サーバに送信される対応するメッセージに関する。医療機器内でのアラームの起動及び消去は、医療機器によって検出される患者条件に関連していてもよいし、トリガ、メッセージ及びタイムスタンプメタデータを含む電源イベントテーブル１９００に対応するアラームイベントテーブル２０００に関連していてもよい。アラームイベントテーブル２０００の場合は、トリガメタデータは、起動、消去又はアラームメッセージ更新に関する。メッセージメタデータ及びタイムスタンプメタデータは、電源イベントテーブル１９００の対応するフィールドと同様に使用される。
【０１５７】
アラームイベント応答テーブル２０１０は、電源イベント応答テーブル１９１０に対応する。アラームイベント応答テーブルのメタデータを使用して生成されたメッセージは、アラームイベントメッセージの受信があると、医療機器に送信される。したがって、アラームイベント応答テーブル２０１０は、一般的に、電源イベント応答テーブル１９１０とは異なる応答を含み、アラームイベントに関するメッセージ、パッケージ又は他の命令を送信する。
【０１５８】
図２１は、保守イベントテーブル２１００及び保守イベント応答テーブル２１１０を示す。保守イベントは、操作ソフトウエア、較正ソフトウエア、又は、要求されている保守を示す通知メッセージの更新の要求のような、保守が要求されているという指示に対する医療機器の特定の反応に対応する。保守イベントテーブル２１００は、保守をするにはソフトウエアアップグレード又は遠隔制御可能な他の保守イベントが必要である状況に備えて、医療機器サーバと協働して保守を実行する準備をしている医療機器から受け取られたメッセージ内のデータに対応する。保守イベントテーブル２１００は、トリガ、メッセージメタデータ及びタイムスタンプメタデータを含むという点では電源イベントテーブル１９００と同じである。保守イベントテーブル２１００の場合は、トリガメタデータは、適用済の更新又はパッケージに関する。メッセージメタデータ及びタイムスタンプメタデータは、電源イベントテーブル１９００の対応するフィールドと同様に使用される。
【０１５９】
保守イベント応答テーブル２１１０は、電源イベント応答テーブル１９１０にも対応し、医療機器サーバ又は他のバックオフィスコンポーネントによって生成される。保守イベント応答テーブルのメタデータを使用して生成されたメッセージは、保守イベントメッセージの受信があると、医療機器に送信される。そして当該生成されたメッセージは、要求されている保守、保守スケジュール情報、医療機器によって表示されるべき要求されている保守についての情報に関する追加詳細情報のような、保守イベントに応じて発生する、メッセージ、パッケージ又は他の命令に関する。
【０１６０】
図２２は、遠隔測定イベントテーブル２２００及び遠隔測定イベント応答テーブル２２１０を示す。遠隔測定とは、医療機器サーバにアクセスしているユーザが、殆どリアルタイムで、医療機器の操作を遠隔的にモニタリングできる程度に、医療機器から医療機器サーバにイベントデータを殆ど連続的にストリーミングすることを言う。遠隔測定イベントテーブル２２００は、トリガメタデータ、メッセージメタデータ及びタイムスタンプメタデータを含む電源イベントテーブル１９００に対応する。遠隔測定イベントテーブル２２００の場合は、トリガメタデータは、医療機器から受け取られた遠隔測定に関する更新イベントに関する。メッセージ及びタイムスタンプメタデータは、電源イベントテーブル１９００の対応するフィールドと同様に使用される。
【０１６１】
遠隔測定イベント応答テーブル２２１０は、電源イベント応答テーブル１９１０にも対応するが、サーバによって生成される。遠隔測定イベント応答テーブルのメタデータを使用して生成されたメッセージは、遠隔測定イベントメッセージの受信があると、医療機器に送信される。そして当該生成されたメッセージは、遠隔測定イベントに応じて、メッセージ、パッケージ又は他の命令を送信する。
【０１６２】
図２３は、治療イベントテーブル２３００及び治療イベント応答テーブル２３１０を示す。治療イベントは、一般的に、医療機器における治療又はモニタリング処理の開始及び停止に関する。開始又は停止された特定の治療は、使用される医療機器のタイプに左右され、モニタリング、薬品提供又は他の治療を含み得る。治療イベントテーブル２３００は、トリガメタデータ、メッセージメタデータ及びタイムスタンプメタデータを含む電源イベントテーブル１９００に対応する。治療イベントテーブル２３００の場合は、トリガメタデータは、医療機器による治療の初期化又は終了に関するような、治療の設定、開始、終了又は更新に関する。メッセージ及びタイムスタンプメタデータは、電源イベントテーブル１９００の対応するフィールドと同様に使用される。
【０１６３】
治療イベント応答テーブル２３１０は、電源イベント応答テーブル１９１０にも対応するが、サーバによって生成される。治療イベント応答テーブルのメタデータを使用して生成されたメッセージは、治療イベントメッセージの受信があると、医療機器に送信される。そして当該生成されたメッセージは、治療イベントに応じて、メッセージ、パッケージ又は他の命令を送信する。
【０１６４】
図２４は、治療変更イベントテーブル２４００及び治療変更イベント応答テーブル２４１０を示す。治療変更イベントは、一般的には、医療機器上の操作の変更に関し、前記の治療イベントに関連している。治療変更イベントは、例えば薬品提供率のような、治療のモニタリング及び提供に関するパラメータ変更を含む。治療変更イベントテーブル２４００は、トリガメタデータ、メッセージメタデータ及びタイムスタンプメタデータを含む電源イベントテーブル１９００に対応する。治療変更イベントテーブル２４００の場合は、トリガメタデータは、治療変更に関するような、イベントの無効化、警告、放棄又は更新に関する。メッセージ及びタイムスタンプメタデータは、電源イベントテーブル１９００の対応するフィールドと同様に使用される。
【０１６５】
治療変更イベント応答テーブル２４１０は、電源イベント応答テーブル１９１０にも対応するが、サーバによって生成される。治療変更イベント応答テーブルのメタデータを使用して生成されたメッセージは、治療イベントメッセージの受信があると、医療機器に送信される。そして当該生成されたメッセージは、治療変更イベントに応じて、メッセージ、パッケージ又は他の命令を送信する。
【０１６６】
Ｃ．パッケージ配備
図１１に戻り、医療機器サーバから医療機器にパッケージを配備する様々なシステム及び方法が存在する。配備されたパッケージは、保守情報、治療のための新たな又は変更後のパラメータ、又は、医療機器ネットワーク内の医療機器に対する他のソフトウエアアップグレード又は変更を含んでもよい。ある可能な実施形態においては、パッケージは、パッケージが任意の可能なタイプのパッケージデータとともに送信される医療機器をプログラミングするために使用され得る。パッケージデータを受け取ることが可能な医療機器は、メインテーブル１１０２及びパッケージテーブル１１０８にこの能力を示す。メインテーブル１１０２は、機器がパッケージを受け取る能力を示し、パッケージテーブル１１０８は、医療機器の操作に使用するために医療機器に格納された現在のパッケージ情報に関する情報を含む。パッケージ提供は、以降により詳細に記述されるように、メッセージに応答して発生し、パッケージの提供が可能であることを医療機器に示すイベント応答テーブル１９１０〜２４１０のパッケージデータ識別子を使用して開始される。
【０１６７】
図２５には、医療機器に情報を配備するときに使用されるパッケージ２５００の構造の一例が示される。パッケージ２５００は、サーバヘッダ２５０２、ベンダヘッダ２５０４及び医療機器に提供されるべき情報２５０６を含む。サーバヘッダ２５０２は、すべてのパッケージに共通の形状をしており、パッケージを受け取る機器のタイプ及びパッケージの発信元に関する。パッケージサイズ、暗号化フォーマット、又は暗号化鍵位置情報のような追加情報が、サーバヘッダ２５０２に含まれていてもよい。ある実施形態においては、サーバヘッダ２５０２は、パッケージに組み込まれた２５６バイトのブロックである。
【０１６８】
ベンダヘッダ２５０４は、パッケージを受け取る医療機器内でのパッケージの使用に関するベンダ特有の情報を含む。医療機器サーバにパッケージを供給するベンダは、一般的に、パッケージを受け取ることを目的とする医療機器に関連付けられた製造者又は保守会社であるので、ベンダは、ベンダヘッダ２５０４を、ベンダが製造する医療機器に理解可能な方法で作成する。ベンダヘッダは、一般的に、情報２５０６のサイズに関する情報と、当該情報の中にある暗号化情報２５０８の場所とを含む。暗号化情報２５０８は、情報を復号するために医療機器に使用され、一般的には、暗号化された形で医療機器に格納される。
【０１６９】
情報２５０６は、一般的に、ファームウエアアップグレード、治療パラメータを含むファイル又は他の２進数データのような、医療機器サーバから医療機器に移転されるべき任意のソフトウエアを含む。パッケージ提供システム２５００は、ベンダヘッダ２５０４又は情報２５０６の特定のフォーマットに従属することはない。情報２５０６は、一般的に、医療機器サーバ上に暗号化された形で格納されている。医療機器に移転されると、医療機器は、ベンダヘッダ２５０４の情報に基づいて暗号化情報２５０８を検索することによって情報２５０６を復号する。
【０１７０】
図２６は、医療機器サーバから医療機器にパッケージデータを配備するシステム及び方法を示す。システム２６００は、医療機器から受け取ったメッセージに応答して、図５のパッケージ２５００のようなパッケージを医療機器に分配する。
【０１７１】
システム２６００内の操作フローは、開始モジュールから始まる（ステップ２６０２）。開始モジュールは、医療機器のベンダ、医療機器の管理者又は医療機器の操作を熟知する他の事業体からパッケージ情報を受け取ることに対応する。ストレージモジュールは、受け取ったパッケージを医療機器サーバに格納する（ステップ２６０４）。次回に医療機器がサーバと通信するとき、医療機器への応答に、パッケージが存在するという指示が含まれるように、ストレージモジュールは、医療機器に対する警報又は他の変数を設定することもできる（ステップ２６０４）。ある実施形態においては、ストレージモジュールは、医療機器サーバ又はバックオフィスコンポーネント上に格納されている一方、パッケージを暗号化し、パッケージが使用される又は送信されるべきときに、医療機器サーバ又は医療機器自身の何れかがメッセージを復号する（ステップ２６０４）。他の実施形態においては、ストレージモジュールは、パッケージが医療機器サーバ又はバックオフィスコンポーネント上に格納するとき、パッケージを暗号化しないでおく（ステップ２６０４）。
【０１７２】
メッセージ受信モジュールは、医療機器サーバにおいて、医療機器からメッセージを受け取る（ステップ２６０６）。メッセージは、図１９〜図２４で前記した、電源、保守、アラーム、遠隔測定、治療、治療変更イベントメッセージのような、多くのタイプのメッセージのうち任意のものであってよい。追加的なメッセージタイプも可能である。
【０１７３】
指示モジュールは、医療機器に対して、パッケージが当該機器に提供されることが予定されていることを示す（ステップ２６０８）。ある実施形態においては、指示モジュールは、パッケージが存在することを示す、メッセージ応答のパラメータを設定する（ステップ２６０８）。例えば、指示モジュールは、図１９〜図２４のイベント応答メッセージ１９１０〜２４１０に含まれるパッケージメタデータのパラメータを設定し得る。パッケージ配備に関する特定のメッセージの送信、医療機器によるパッケージ要求又は他の方法のような、パッケージの存在を示す追加的な方法も可能である。
【０１７４】
要求モジュールは、パッケージを受け取りたい旨の医療機器からの要求を受け取る（ステップ２６１０）。要求モジュールは、パッケージについての情報を要求する１つ又は複数のステップを含み、当該パッケージが受け入れられるべきであることを、医療機器において確認してもよい（ステップ２６１０）。ある可能な実施形態においては、要求モジュールは、図２７に示されるようなメタデータを使用してパッケージ情報要求メッセージを送信する（ステップ２６１０）。このような実施形態においては、要求モジュールは、オプションとして、パッケージ情報要求メッセージとは別のパッケージデータ要求メッセージを送信する（ステップ２６１０）。当該パッケージデータ要求メッセージは、医療機器サーバからのパッケージ内容を記述するパッケージ情報の受信した後に送信される。他の実施形態においては、要求モジュールは、図２９又は図３１に示されるような要求を受け取る（ステップ２６１０）。
【０１７５】
提供モジュールは、要求されたパッケージを医療機器に提供する（ステップ２６１２）。パッケージ提供メッセージのフォーマットは、図３０又は図３２に示されるようであり得る。操作フローは、医療機器に対するパッケージ送信が終了することに対応する終了操作２６１４で終了する。
【０１７６】
図２７〜図３２は、医療機器サーバから医療機器にパッケージを配備する、図１に示されたような、医療機器ネットワーク内のメッセージ及びテーブルで使用されるメタデータを含むスキーマを示す。スキーマは、様々な要求と、医療機器がパッケージ情報の提供を要求しその応答として要求した情報を受け取るという、応答シナリオを表示する。医療機器と医療機器サーバとの間で、パッケージ及び同封されるデータを提供する前に、１つ又は複数のメッセージが送信されてもよい。
【０１７７】
図２７は、医療機器に配備されるために利用可能なパッケージについての情報を要求するために使用されるメタデータを含むパッケージ情報要求テーブル２７００を示す。医療機器は、医療機器サーバ内の、当該機器に関するメインテーブル１１０２又はパッケージテーブル１１０８の情報を反映しているような、先立つ応答に基づく利用可能なパッケージを医療機器サーバから通知される。当該テーブル２７００のメタデータは、パッケージ及びパッケージの内容についての要求情報を識別するために医療機器によって使用される
パッケージ識別子を含む。パッケージに関するメタデータがテーブル２７００及び医療機器からのメッセージにさらに含まれてもよい。
【０１７８】
図２８は、医療機器に配備されるために利用可能なパッケージを記述するのに使用されるメタデータを含むパッケージ情報要求応答テーブル２８００を示す。テーブル２８００のメタデータは、パッケージ情報要求テーブル２７００のパッケージ識別子に対応するパッケージ識別子を含み、パッケージ情報メタデータも含む。パッケージ情報メタデータは、名称メタデータ及びバージョンメタデータを含むパッケージ情報テーブル２８０２にリンクする。名称メタデータ及びバージョンメタデータに関連付けられた値は、医療機器がパッケージの配備を要求するか否かを決定することができるように、パッケージを記述する。
【０１７９】
図２９は、医療機器サーバからパッケージデータを要求するのに使用されるメタデータを含むパッケージデータ要求テーブル２９００を示す。パッケージデータ要求テーブル２９００は、パッケージ識別子と要求タイプメタデータを含む。パッケージ識別子は、医療機器への配備のために利用可能なパッケージを一意に識別する。要求タイプは、パッケージデータの所望の提供フォーマットを示す識別子を表す。ある実施形態においては、パッケージデータは、標準文字フォーマット又はＸＯＰフォーマットの何れかで医療機器に提供され得る。
【０１８０】
図３０は、医療機器にパッケージを配備するのに使用されるメタデータを含むパッケージデータ要求応答テーブル３０００を示す。パッケージデータ要求応答テーブル３０００に含まれるメタデータは、パッケージ識別子とパッケージ２進数データフィールドを含む。パッケージ識別子は、図２９で言及されたパッケージを識別し、パッケージ２進数データフィールドは、医療機器に提供されつつあるパッケージを表す２進数データを示す。パッケージ２進数データフィールドは、オプションとして、医療機器への提供のためのパッケージ２進数データを含む、セパレートパッケージ２進数データテーブルへリンクすることもできる。ある実施形態においては、医療機器に提供されるパッケージは、図２５のパッケージ２５００である。
【０１８１】
図３１は、パッケージ要求テーブル３１００を示す。パッケージ要求テーブル３１００は、図２７のパッケージ情報要求テーブル２７００と組み合わされた、図２９のパッケージデータ要求テーブル２９００に対応する。パッケージ要求テーブル３１００は、パッケージをダウンロードする前に、医療機器がパッケージ情報を有効にする必要がない場合、医療機器によって使用され得る。パッケージ要求テーブル３１００は、パッケージデータ要求テーブル２９００と同様に、パッケージ識別子と応答タイプを含むが、完全なパッケージを要求することによって、パッケージ情報及びパッケージデータが分けられる必要がないことを指示する。
【０１８２】
図３２は、図３１のパッケージ要求テーブル３１００によって反映されたフォームのメッセージに応答して送信された医療機器サーバからのメッセージのスキーマを示すパッケージ要求応答テーブル３２００を示す。パッケージ要求応答テーブルは、パッケージ識別子、パッケージ情報及びパッケージ２進数データを含む。パッケージ情報メタデータは、パッケージデータに関連付けられた名称メタデータ及びバージョンメタデータを含むパッケージ情報テーブル３２０２にリンクする。パッケージ２進数メタデータは、医療機器に配備されるべきパッケージに対応するメタデータを含むパッケージ２進数テーブル３２０４にリンクする。
【０１８３】
Ｄ．時間管理
図３３〜図３５には、医療機器ネットワーク内の時間管理のためのシステム及び方法が示される。医療機器ネットワークはサイズ又は形状が変わり得るので、記述される時間管理システムは、様々な事業体、様々な場所及び様々な時間帯に亘って拡張する。記述されるシステム及び方法は、１つ又は複数の場所又は時間帯にある医療機器及び医療機器サーバの同期を取る一様な方法を提供する。
【０１８４】
図３３は、医療機器サーバでの医療機器時刻を追跡し、医療機器と医療機器サーバとの間の時刻同期メッセージを送信するために使用可能である時刻メッセージングスキーマ３３００を示す。時刻スキーマ３３００は、時刻要求テーブル３３０２、時刻要求応答テーブル３３０４及びシステム時刻テーブル３３０６を含む。時刻要求テーブル３３０２は、オプションとして、メタデータを含まない代わりに、医療機器時刻をサーバ又はバックオフィスコンポーネントに格納された時刻に同期させるための、医療機器から医療機器サーバに送信される時刻要求応答を表す。時刻要求応答テーブル３３０４は、医療機器サーバ上に格納されたシステム時刻値に関連付けられたシステム時刻メタデータを含む。システム時刻メタデータは、オプションとして、医療機器の時刻を医療機器サーバから受け取った時刻に同期させるために使用可能な時刻値を含むシステム時刻テーブル３３０６にリンクする。時刻同期を支援するために使用可能な追加的メタデータ又は他の情報も使用され得る。
【０１８５】
図３４は、医療機器ネットワーク内で医療機器と医療機器サーバを同期させる方法及びシステムを示す。システム３４００の操作フローは、医療機器ネットワークの初期操作に対応する開始操作から始まる（ステップ３４０２）。サーバ時刻保守モジュールは、通信可能に接続されている医療機器の時刻値を同期させるために使用されるべきサーバ内のグローバル時刻値を維持する（ステップ３４０４）。
【０１８６】
サーバ時刻送信モジュールは、医療機器ネットワーク内の１つ又は複数の医療機器に、サーバ時刻を送信する（ステップ３４０６）。ある実施形態において、サーバ時刻送信モジュールは、医療機器からの要求メッセージに応答して医療機器にサーバ時刻値を送信する（ステップ３４０６）。このような実施形態では、要求メッセージは、図３３の時刻要求テーブル３３０２に示されるフォームであってもよい。
【０１８７】
他の実施形態において、送信モジュールは、医療機器の場所の時間帯に基づいて、サーバ時刻値をローカル化されたサーバ時刻値に変換する（ステップ３４０６）。当該変換は、サーバが医療機器とは別の時間帯にある場合に行われる。このようにして、サーバと医療機器は、適切な時間帯に変換された同期された時刻値を有することになる。この実施形態を実施するには、サーバからの送信時に、すべての時刻をユニバーサルタイムプロトコルに変換し、送信先の医療機器は、時刻値を当該送信先の医療機器の場所のローカル時刻に再変換する。医療機器サーバのローカル時刻から医療機器のローカル時刻への変換のような、他の時間帯変換も可能である。
【０１８８】
置換モジュールは、機器時刻を、医療機器サーバから受け取られたサーバ時刻値に置換する（ステップ３４０８）。置換モジュールは、医療機器の場所で使用されるべき、時刻調整されたサーバ時刻値を使用する（ステップ３４０８）。オプションとしての置換モジュールは、医療機器が成功裏にサーバと同期されたことを示す確認メッセージを医療機器サーバに送信し、サーバが、どの医療機器が成功裏にサーバと同期されているかを追跡することを可能にする（ステップ３４１０）。操作フローは、時刻同期処理の終了に対応する終了操作で終了する（ステップ３４１２）。
【０１８９】
図３５には、イベントログデータを同期させる方法及びシステムが示される。システム３５００は、複数の時間帯の異なる場所に位置する医療機器から受け取られたイベントログデータを収容する。イベントログデータのローカルタイムスタンプは当該機器が存在する時間帯を表すので、同じタイムスタンプを有する異なる時間帯からのイベントログは、実際には異なる時刻に発生したものであるように、イベントログデータは作成される。システム３５００は、イベントログデータを格納するとき、及び、イベントログデータをユーザの閲覧に供するときに、当該相違を補償する。システム３５００の操作フローは、医療機器から医療機器サーバへのイベントデータの初期通信に対応する開始操作から始まる（ステップ３５０２）。
【０１９０】
受信モジュールは、医療機器サーバが１つ又は複数の医療機器からイベントログデータを受け取ることに対応する（ステップ３５０４）。前記したように、イベントログデータは、治療イベント、アラームイベント、保守イベント、遠隔測定イベント、又は、他のタイプのイベントのような様々なタイプのイベントに関する様々な詳細情報を含む。これらのイベントのそれぞれは、医療機器の現在時刻値とローカル時間帯を反映するタイムスタンプに関連付けられている。時間帯修正モジュールは、タイムスタンプ情報を、医療機器のローカル時間帯から一定の時間帯に変換する（ステップ３５０６）。ある実施形態においては、時間帯修正モジュールは、タイムスタンプをユニバーサルタイムプロトコル（ＵＴＰ）に変換する（ステップ３５０６）。ストレージモジュールは、変換されたタイムスタンプ及び関連付けられたイベントログデータを、医療機器サーバ又はバックオフィスコンポーネントに格納する（ステップ３５０８）。
【０１９１】
オプションとしてのグローバル追跡モジュールは、一様な時間帯情報を使用してグローバルイベントを追跡する（ステップ３５１０）。例えば、すべての時間帯に亘る１つの瞬間に発生するイベントを追跡しようとするユーザは、ユニバーサルタイムプロトコルを使用してグローバルイベントを追跡し、すべての時間帯に亘る標準時刻を維持することができる。ユーザは、サーバ上に格納されたグローバルイベントに関するイベントログデータに対する要求を送信し、一定の時間帯情報を有するタイムスタンプとともにイベントログ情報を受け取る。
【０１９２】
ローカルイベント要求モジュールは、イベントが発生する時間帯に関連付けられるイベントデータのタイプを含むローカルイベントデータに対する要求を受け取る（ステップ３５１２）。時間帯特定イベントの例は、病院でのシフトの開始時又は終了時に発生することを決められているイベント又は他のローカルイベントを含み得る。ローカルイベント要求モジュールは、イベントデータを要求するクエリを生成し、イベントログデータを含む結果を返信する（ステップ３５１２）。変換モジュールは、記録されたイベントログデータの元となった医療機器の場所に基づいて、一様な時間帯情報をローカル時間帯情報に変換する（ステップ３５１４）。変換モジュールは、オプションとして、要求するユーザに分配するための、補償されたローカル時刻イベントログを含むレポートをイベントログデータから生成する（ステップ３５１４）。システム３５００の操作フローは、変換モジュールの終了（ステップ３５１４）に対応する終了操作で終了する（ステップ３５１６）。
【０１９３】
IV.サーバ通信への遠隔ユーザ
図３６〜図６６には、図１で示されたような、医療機器ネットワークの医療機器サーバへのユーザアクセスを管理する、一般化されたウエブサービス構造が開示される。当該ウエブサービス構造は、サーバ通信への遠隔ユーザが、図１の医療機器ネットワークの医療機器に関するデータアクセス及びプログラミング能力を備えることを可能にする。例えば、ユーザは、医療機器から離れていても、管理タスクを実行し、医療機器、アクセスイベント及び操作記録に対するソフトウエア更新を管理し、保守を実行し、治療を変更し、殆どリアルタイムで医療機器操作を閲覧することができる。これらの機能は後記される。
【０１９４】
図３６は、図３及び図４の医療機器ネットワークのソフトウエア構造候補のサブシステムとして示された、全体ウエブサービス構造３６００を示す。当該ウエブサービス構造は、ユーザを認証し、医療機器サーバ上に格納されたデータへのアクセスを提供する、様々なウエブモジュール又はサーバを含む。ある可能な実施形態において、ウエブサービス構造は、マイクロソフト社のインターネット情報サーバを使用するドットネット（.ＮＥＴ）構造として実現される。
【０１９５】
ウエブサービス構造３６００は、管理ウエブサービス３６０２、操作ウエブサービス３６０４及びイベント追跡ウエブサービス３６０６を含む。管理ウエブサービス３６０２は、医療機器サーバのユーザを認証し、ログイン、ログアウト及びユーザパスワード変更のための機能インタフェースを含む。管理ウエブサービス３６０２は、製品、カスタマ、カスタマに関連付けられたコンタクト情報、カスタマに関連付けられたユーザアカウント、及び他の変数に関する情報を追跡する。管理ウエブサービス３６０２は、当該追跡された情報を使用して特定のユーザを認証する。各ユーザは、特定の治療施設に関連付けられており、管理ウエブサービスにおいてはカスタマと呼ばれる。管理ウエブサービス３６０２の具体的な実施クラスは、IV.Ａで後記される。
【０１９６】
操作ウエブサービス３６０４は、治療提供データ又はモニタリングデータに関する操作データのような、医療機器の操作データに対するアクセスを提供する。操作ウエブサービス３６０４は、医療機器で発生している様々な治療状態を追跡し、発生し得るメッセージシーケンスが医療機器の治療イベントのトリガとなる又は治療イベントを追跡することを可能にする。操作ウエブサービス３６０４の具体的な実施形態は、IV.Ｂで後記される。
【０１９７】
イベント追跡ウエブサービス３６０６は、医療機器サーバにより受け取られた遠隔測定データのような、医療機器で発生する様々なイベントデータを追跡する。イベント追跡ウエブサービス３６０６は、ユーザが医療機器から離れているときでも、ユーザが、殆どリアルタイムの医療機器動作を閲覧し、医療機器のオンラインステータスを決定することを可能にする。イベント追跡ウエブサービス３６０６の具体的な実施形態は、IV．Ｃで記述される。
【０１９８】
図３７〜図４１には、管理ウエブサービスを定義し使用するためのシステム及びレポートが示される。図３７は、管理ウエブサービス３７００を定義する典型的なクラス構造を示す。管理ウエブサービス３７００は、図３６の管理ウエブサービス３６０２の可能な実施形態を提供し、図３の管理ウエブフォーム３２４のような、多くの任意のユーザインタフェースを介してアクセス可能である。管理ウエブサービス３７００は、認証クラス３７０２、承認クラス３７０４、ユーザクラス３７０６、役割クラス３７０８、ライセンスクラス３７１０、リソースクラス３７１２、メタデータクラス３７１４及び事業体設定クラス３７１６を含む。各クラスは、インターネット及びウエブベースのユーザインタフェースを介して遠隔的にアクセス可能な、管理タスクを実行するための多くの機能を含む。様々なクラスの機能性は、後記される。
【０１９９】
認証クラス３７０２は、管理ウエブサービス３７００に対する初期アクセス提供し、ログイン及びログアウト機能を含む。承認クラス３７０４は、様々なリソース制御機能を含み、２人のユーザが同じデータに読み書きしてデータ競合を起こさないようにする。承認クラス３７０４に具現化されたリソース制御機能は、読み、書き、生成、消去及びアクセス許可を含む。他の機能が承認クラス３７０４に具現化されてもよい。
【０２００】
他のクラスのそれぞれは、承認クラス３７０４にリンクし、承認クラス３７０４によって保護されるデータへの読み書きを要求する。ユーザクラス３７０６は、システムが、新規ユーザの生成、ユーザ情報の編集、パスワード変更、ユーザの消去、ユーザ役割の定義、ユーザ履歴の検索のような様々なユーザ管理タスクを実行することを可能にする。他の機能も可能である。役割クラス３７０８は、ユーザに割り当て可能な役割を定義し、管理データで定義される様々な役割を、生成、更新、消去、及び検索する能力を含む。役割は、医師、看護師又は他の健康管理者のような、医療機器サーバ又はバックオフィスコンポーネントによって管理されるデータにアクセス可能な個人の様々なクラスに対応してもよい。役割は、個人が関連付けられる様々な事業体に対応してもよい。
【０２０１】
ライセンスクラス３７１０は、システムにインストールされるライセンスを定義し、即時ログイン可能なユーザの数を制御し、様々なアカウント用の使用モデルを定義する。例えば、特定のアカウントは、限定数の個人に対してのみ、即時に遠隔測定データを閲覧し又は治療記録にアクセスすることを許可してもよいし、医療機器サーバ又はバックオフィスコンポーネントを追跡使用するカスタマに課金する方法を定義してもよい。
【０２０２】
リソースクラス３７１２は、管理者が医療機器サーバの特定の機能領域に対応するリソースを加除することを可能にする。メタデータクラス３７１４は、新たに導入された医療機器に対応するカスタムメタデータのような管理システム、又は、新たに導入された医療機器自身の何れかにメタデータをインストールする下層機能を提供する。メタデータをインストールするインタフェース例が、図４２及び図４３で後記される。事業体設定クラス３７１６は、事業体設定の書き込み及び検索を可能にする。追加的なクラスを含む追加的な管理機能が管理ウエブサービス３７００に統合されてもよい。
【０２０３】
図３８〜図４１は、ユーザにアクセス可能な管理レポート例を示す。図３８〜図４１の管理レポートは、図３及び図４に示されたレポート３２６に対応し、医療機器サーバによってログされる管理イベントに関するデータウエアハウス３２２に格納される情報から導出される。本発明の開示のある可能な実施形態では、様々なレポートが、マイクロソフト社のＳＱＬサーバレポーティングサービスを使用して生成される。他のレポーティング及びビジネスインテリジェンスソフトウエアが使用されてもよい。
【０２０４】
図３８は、管理追跡イベントレポート３８００を表示する。管理追跡イベントレポートは、医療機器サーバに対するユーザアクセス及び接続のような管理イベントに関する詳細情報を表示する。当該レポートのエントリの数及び内容は、管理ウエブサービスに提示されたクエリに一致する、図３の管理データ３１６からのデータに対応する。管理追跡イベントレポートは、時刻及び日付情報３８０２、アプリケーション情報３８０４及びメッセージ情報３８０６を含む。コード情報、時間帯指標及び他の情報のような、追加情報が、オプションとして、レポート３８００に含まれ得る。
【０２０５】
時刻及び日付情報３８０２は、管理モジュールによって追跡されるイベントに関するタイムスタンプ情報を表示する。時刻及び日付情報３８０２は、ユーザがローカル時間帯オプション又はＧＴＭ標準時オプションの何れを選択するかに応じて、様々にフォーマットを変えて、レポート上に表示される。図示されたレポート３８００では、ローカル時間帯オプションが選択されている。
【０２０６】
アプリケーション情報３８０４は、アクセスされたサービス又はハンドラを示し、メッセージ３８０６は、当該サービス又はハンドラについて取られた動作を示す。図示された例では、“ＭＤＳ：Ｍｄｓ０１”及び“ＭＤＳ：Ｍｄｓ０２”とラベルされた２つの医療機器サーバについての接続イベントが示されている。
【０２０７】
図３９は、セキュリティイベントレポート３９００を示す。セキュリティイベントレポート３９００は、一般的には、管理追跡イベントレポート３８００に対応するが、医療機器サーバへのアクセスというよりは、医療機器サーバのセキュリティに関するイベントを含む。セキュリティイベントレポート３９００は、時刻及び日付情報３９０２、アプリケーション情報３９０４及びメッセージ情報３９０６を含む。各情報は、管理追跡イベントレポート３８００と同じ機能を有する。
【０２０８】
図４０は、セキュリティイベント傾向レポート４０００を示す。セキュリティイベント傾向レポート４０００は、セキュリティ関連イベントの時系列のグラフを表示する。図示された実施形態において、セキュリティイベント傾向レポート４０００は、月ごとのセキュリティイベントの頻度を示す棒グラフを表示する。セキュリティイベントの傾向を表示する他の形状も可能である。
【０２０９】
図４１は、ユーザ履歴レポート４１００を示す。ユーザ履歴レポートは、１つ又は複数のユーザに関してログされたイベントを時系列に並べたリストを表示する。当該リストの各エントリは、時刻及び日付情報４１０２、格納コード４１０４、能動的ユーザに対応するユーザ名称４１０６及びユーザによって取られる動作に関するメッセージ４１０８を含む。オプションとしての詳細情報エントリ４１１０は、セッションキー、場所、名称、又はユーザ履歴で発生する他の活動のような履歴情報に関連付けられた追加情報を未加工の形で表示する。
【０２１０】
１.メタデータ及びパッケージ配備インタフェース
図４２〜図５０には、メタデータ、ファームウエア又は他の２進数データを用いて、医療機器サーバ及び医療機器をプログラミングする様々な方法が示されている。図４２〜図４６は、医療機器サーバにおいて、それぞれ医療機器サーバ又は医療機器に対する設定用であるメタデータ又はパッケージの提供又は消去のような、様々な管理タスクを実行するために使用可能な管理フォームを表示する。管理フォームは、図３及び図４の管理アプリケーション３２４によって生成されるフォームに対応する。図４７〜図５０は、メタデータ及びパッケージのインストールの結果を表示するレポートを表示し、図３及び図４のデータウエアハウスから利用可能なレポート３２６のサブセットである。
【０２１１】
図４２及び図４３は、III.Ａ及びIIIＢで前記したように、管理ユーザが、医療機器サーバにインストールされたメタデータを管理することを可能にするユーザインタフェースを表示する。図４２は、医療機器サーバに対して現在インストールされているか、又はインストールされるべく利用可能であるかの何れかであるメタデータパッケージを示す初期ユーザインタフェース４２００を示す。リスト領域４２０２は、当該例では“仮想点滴ポンプ”、“仮想患者モニタ”及び“Medfusion4000”のように表示されている、パッケージを列挙する。リスト領域のチェックボックス４２０４は、ユーザが１つ又は複数のインストールされるパッケージを選択することを可能にし、インストールボタン４２０６は、医療機器サーバにパッケージをインストールし、アンインストールボタン４２０８は、医療機器サーバからメタデータパッケージを消去する。
【０２１２】
図４３は、ユーザがメタデータファイルを閲覧し、当該ファイルを医療機器サーバ上にインストールすることを可能にするメタデータインストールインタフェース４３００を表示する。メタデータインストールインタフェース４３００は、ユーザインタフェース４２００において、システム内に存在する医療機器のタイプの内の１つを選択した後に現れ、ユーザが、初期ユーザインタフェース４２００を使用して先立って行ったメタデータの選択に関連付けられたメタデータを選択し、インストールすることを可能にする。
【０２１３】
図４４は、III．Ｃで前記したように、１つ又は複数の医療機器に対する分配用のパッケージの配備を行うパッケージ配備インタフェース４４００を表示する。パッケージ配備インタフェース４４００は、一般的には、図４２のメタデータインストールインタフェース４２００に対応するが、医療機器サーバに対してというよりはむしろ医療機器上にインストールされるべきソフトウエアに関する。リスト領域４４０２は、当該例では“簡略点滴ポンプ”及び“テストパッケージ”のように表示されている、パッケージを列挙する。リスト領域のチェックボックス４４０４は、ユーザが１つ又は複数のインストールされるパッケージを選択することを可能にし、配備ボタン４４０６は、医療機器サーバにパッケージを配備し、アンインストールボタン４４０８は、医療機器サーバからメタデータパッケージを消去する。
【０２１４】
配備ボタン４４０６が選択されると、図４５に示されるユーザインタフェース４５００が表示される。ユーザインタフェース４５００は、システム管理者が名称フィールド４５０２にパッケージ配備名称を入力することを可能にし、当該管理者が開始フィールド４５０４及び終了フィールド４５０６に、それぞれ開始時刻及び終了時刻を入力することを可能にする。ユーザインタフェースは、システム管理者が、パッケージ配備ファイル選択フィールド４５０８において、使用すべきパッケージ配備ファイルを選択することを可能にする。システム管理は、配備ボタン４５１０を押下してパッケージを配備し、キャンセルボタン４５１２を押下して配備をキャンセルする。
【０２１５】
配備ボタン４５１０が選択されると、図４６に示されたユーザインタフェース４６００が表示され、ユーザは、正しいパッケージが医療機器にダウンロードするために選択されたことを確認できる。ユーザインタフェース４６００は、パッケージ情報フィールド４５０２に、先立つユーザインタフェース４４００、４５００で入力された開始時刻及び終了時刻を含む、パッケージ配備詳細情報を表示する。ユーザインタフェース４６００は、ベンダフィールド４５０４に、ベンダ識別子、名称、ベンダパッケージのバージョンのような、ベンダ属性をさらに表示する。
【０２１６】
図４７〜図５０は、メタデータ定義されたイベントメッセージ又はパッケージ配備に関するものとして、図３及び図４のデータウエアハウス３２２から生成された様々なレポートを表示する。図４７及び図４８は、医療機器から受け取った故障のあるメッセージのメッセージハンドリング及びデバッギングに関する。図４９及び図５０は、ソフトウエア配備の成功及び失敗記録又は医療機器に対する他の２進数データを具現化するパッケージ配備レポートを表示する。
【０２１７】
図４７は、医療機器サーバによって受け取られた隔離メッセージの時系列リストを表示する隔離レポート４７００を表示する。隔離レポート４７００は、時刻及び日付情報４７０２、状態情報４７０４及びメッセージ情報４７０６を含む。時刻及び日付情報４７０２は、医療機器サーバによって追跡された隔離イベントに関するタイムスタンプ情報を表示する。時刻及び日付情報４７０２は、ユーザがローカル時間帯オプション又はＧＭＴ標準時間帯オプションの何れを選択するかに応じて表示フォーマットが変化する。
【０２１８】
状態情報４７０４は、それが新たなメッセージ、解除されたメッセージ又は再挿入されたメッセージの何れであるかのような、隔離されたメッセージの状態に関する。新たなメッセージとは、新たに発見された問題のあるメッセージを意味する。一方、解除されたメッセージは、問題解決が不可能であり、削除（drop）されなければならないメッセージに対応する。再挿入されたメッセージは、医療機器がサーバからの応答を待ち受けている場合に、メッセージサーバに再導入されたメッセージを意味する。
【０２１９】
メッセージ情報４７０６は、メッセージ移転において発生したエラーを記述する。一般に、医療機器サーバが医療機器から受け取ったメッセージを理解する能力に関する様々なエラーメッセージが可能である。
【０２２０】
図４８は、医療機器サーバから受け取った特定の隔離メッセージの詳細情報を表示する隔離詳細情報レポート４８００を表示する。隔離詳細情報レポートは、隔離レポート４７００上に表示されたエラー情報を含むエラーフィールド４８０２と、医療機器サーバのメッセージ動作をユーザデバッギング又は修正するための、メッセージに含まれるメタデータ及び値を表示するソースフィールド４８０４とを含む。
【０２２１】
図４９は、様々なタイプの医療機器の関連付けリスト及び各医療機器へのパッケージ配備のステータスとともに医療機器サーバに知らされるパッケージ配備を示すパッケージ配備レポート４９００を表示する。パッケージ配備レポートは、１つ又は複数のパッケージ配備エントリ４９０２を含む。各エントリは、当該タイプの機器に配備されつつある特定のパッケージに関する。各パッケージエントリは、サブエントリ４９０４を有する。各サブエントリは、一般化されたパッケージ配備の資格を有する特定の機器に関する。各サブエントリは、ホスト名称情報４９０６、物理識別子４９０８、通知情報４９１０、送信情報４９１２及び終了情報４９１４を含む。ホスト名称情報４９０６は、機器にパッケージを提供する医療機器サーバに対応する。物理識別子４９０８は、医療機器に関連付けられた一意な識別子を表示する。通知情報４９１０は、パッケージが利用可能であることが医療機器に通知された時刻及び日付を表示する。送信情報４９１２は、パッケージが成功裏に医療機器に送信された時刻及び日付を表示する。終了情報４９１４は、パッケージが成功裏に医療機器に配備された省略のない時刻及び日付を表示する。
【０２２２】
パッケージ配備ごとに、追加的な情報が追跡され得る。例えば、パッケージの配備に失敗した場合、エラー表示４９１６が、エラー及びエラーの結果を表示する。
【０２２３】
図５０は、パッケージ配備エラーレポート５０００を表示する。パッケージ配備エラーレポート５０００は、特定のパッケージと、パッケージ配備が失敗した原因となった対応する機器についての詳細イベント履歴を提供する。パッケージ配備エラーレポート５０００は、ターゲット医療機器タイプとパッケージ識別子を含むタイトル５００２を表示する。タイトルは、オプションとして、パッケージ配備に関連付けられた名称を表示する。
【０２２４】
パッケージ配備エラーレポート５０００は、時刻及び日付情報５００４、オプションであるホスト情報５００６、物理識別子情報５００８及びメッセージ情報５０１０を表示する。時刻及び日付情報５００４は、パッケージ配備のエラーがいつ発生したかを示している。オプションであるホスト名称情報５００６は、医療機器が設置されるネットワーク名称を表示する。物理識別子情報５００８は、医療機器に関連付けられた識別子を含む。メッセージ情報５０１０は、パッケージ配備エラーに関連付けられたメッセージを表示する。配備エラーに関する追加情報がレポート５０００に含まれてもよい。
【０２２５】
２．保守／故障
図５１〜図５３には、医療機器の保守及び故障に関するレポートが開示される。当該レポートは、医療機器上で実行された保守の記録に対するユーザアクセス、及び医療機器エラーと当該エラーの傾向に関する情報に対するユーザアクセスを提供する。III．Ｂで前記されたように、保守又は故障に関する追加的なレポートが同様に統合化され、医療機器サーバによって収集された保守イベントデータに対応してもよい。ある可能な実施形態において、図５１〜図５３の１つ又は複数のレポートは、図３及び図４の保守フォーム３３０に対応する。
【０２２６】
図５１は、様々な医療機器の保守記録を列挙する医療機器保守レポート５１００を示す。医療機器保守レポート５１００は、様々なタイプの医療機器に対応するタイプエントリ５１０２と、特定の医療機器に対応する機器サブエントリ５１０４とを含む。図示された実施形態においては、タイプエントリ５１０２は、“MedFusion4000”及び“Titan”のエントリであり、機器サブエントリ５１０４は、各タイプ内の個別の行である。
【０２２７】
各サブエントリ内には、ホスト名称情報５１０６、物理識別子情報５１０８、バージョン情報５１１０、パッケージ情報５１１２及び予防保守日付情報５１１４が存在する。ホスト名称情報５１０６は、医療機器に関連付けられたネットワークを表示する。物理識別子５１０８は、医療機器に関連付けられた一意な識別子を表示する。バージョン情報５１１０は、医療機器に関連付けられた１つ又は複数のバージョン番号を表示する。パッケージ情報５１１２は、医療機器によって使用されているパッケージを表示する。予防保守日付情報５１１４は、医療機器が予防保守を受ける期限の日付を表示する。追加的な情報が各サブエントリ内に同様に表示され得る。
【０２２８】
図５２は、医療機器故障レポート５２００を示す。医療機器故障レポート５２００は、バッテリ、モータ又は他の機械的機構の故障に起因するような、医療機器サーバに送信された医療機器故障に関するイベントを表示する。医療機器故障レポート５２００は、時刻及び日付情報５２０２、ホスト情報５２０４、物理識別子情報５２０６及びメッセージ情報５２０８を含む。情報５２０２〜５２０８の使用方法は、図５０のパッケージ配備エラーレポート５０００の対応する構成要素と同様であるが、医療機器故障イベントに関する。例えば、医療機器故障レポート５２００では、メッセージ情報は、医療機器のモータ、バッテリ又は他の機械的故障のような機器故障イベント情報を含む。
【０２２９】
図５３は、医療機器故障傾向レポート５３００を示す。医療機器故障傾向レポート５３００は、医療機器故障関連イベントの時系列のグラフを表示する。医療機器故障傾向レポート５３００は、医療機器内で繰り返されたエラー又は医療機器故障の他の検出可能な傾向をユーザに示す。図示された実施形態において、医療機器故障傾向レポート５３００は、月ごとの機器故障イベントの頻度を示す棒グラフを表示する。機器故障イベントの傾向を表示する他の形状も可能である。
【０２３０】
Ｂ.操作ウエブサービス：治療状態の操作及び制御
図５４〜図６２は、図３６の操作ウエブサービスの様々な特徴を開示する。具体的には、図は、医療機器ネットワークの医療機器の遠隔操作のための、システム、方法及びレポートを示す。ある可能な実施形態において、システム及び方法は、医療機器の当初パラメータ、更新されたパラメータ及び最終パラメータを追跡することによって、医療機器の変化した治療パラメータの追跡を記述する。
【０２３１】
図５４は、医療機器サーバの治療命令状態を追跡する方法及びシステムのフローチャートである。治療命令とは、患者に治療を提供することを指示する医療機器へのコマンドである。システム５４００は、治療命令を実行する間に医療機器で起きる様々な状態候補に対応する状態を含む。
【０２３２】
システム５４００の操作フローは、開始ノード５４０２から始まる。開始ノードは、医療機器又は医療機器サーバに新たな治療命令を導入することに対応する。一旦治療命令が導入されると、システム５４００は、治療命令が新たに導入されたが、医療機器によって未だ実行されていないことを示す新たな状態５４０４に入る。システム５４００が、新たな状態５４００にあるとき、ユーザは、治療命令をキャンセルするオプションを有する。ユーザが治療命令のキャンセルを選択した場合、システム５４００の操作フローは、キャンセル状態５４０６に進む。操作フローは、キャンセル状態から、治療モジュールの終了に対応する終了ノード５４０８に進む。終了ノード５４０８において、操作フローは終了し、医療機器サーバを使用して追跡された治療提供イベントは、ユーザによりレビューされるために引続き格納される。
【０２３３】
システム５４００が新たな状態にあるとき、ユーザが治療命令をキャンセルしないことを選択した場合、操作フローは設定支援状態５４１０に進む。設定支援状態５４１０は、治療パラメータの設定を支援することを試みる。設定支援が不成功である場合、操作フローは、失敗状態５４１２へ分岐する。失敗状態５４１２は、設定支援処理が失敗したことを示すエラーメッセージを格納する。操作フローは、失敗状態５４１２から、終了ノード５４０８に進む。
【０２３４】
設定支援状態５４１０が成功裏に治療パラメータを設定した場合は、操作フローは、設定状態５４１４に分岐する。設定状態５４１４は、医療機器において治療が成功裏に設定され、患者に提供される準備ができていることを示す。
【０２３５】
医療機器サーバから送信される又は医療機器によって生成される治療開始イベントは、医療機器における治療開始に対応するシステムが開始状態５４１６に進むトリガとなる。医療機器又は医療機器サーバから受け取られた治療終了イベントは、システム５４００の操作フローを治療の提供が終了したことを示す終了状態５４１８に進ませる。
【０２３６】
図５５は、治療サービス５５００を定義する典型的なクラス構造を示す。治療サービス５５００は、操作ウエブサービスモジュール３６０４の機能の一部を図示する。治療サービス５５００は、図３７の管理ウエブサービス３７００からの様々な機能にリンクし、それらの機能を使用する。
【０２３７】
治療サービス５５００は、治療命令クラス５５０２、治療命令規則ユーティリティ５５０４及び治療命令動作目録５５０６を含む。治療命令クラス５５０２は、治療サービス５５００が作動する医療機器ネットワークの医療機器によって提供されるべき様々な治療を開始し、停止し及び定義するための様々な治療命令操作を含む。治療命令操作は、治療生成、治療更新、治療キャンセル、治療実行及び治療検索操作を含む。追加的な治療命令操作も治療命令クラス５５０２に含まれ得る。
【０２３８】
治療命令規則ユーティリティ５５０４は、治療の実行のために要求される様々なパラメータ及びコマンドを含む、治療命令の実行に関する表現及び動作を提供する。治療命令動作目録５５０６は、治療命令の選択及び／又は実行中に使用される助言メッセージを提供する。
【０２３９】
図５６は、治療命令管理アプリケーション５６０２、図３６に示されるような操作ウエブサービス５６０４、図３及び図４で開示された医療機器サーバ５６０６及び図２に示されたような医療機器５６０８の間で実行される典型的なメッセージ交換処理５６００、５６２０、５６４０及び５６６０を表示する。治療命令管理アプリケーション５６０２は、管理ウエブサービスとインタフェースを取り操作サービス５６０４及び医療機器サーバ５６０８に治療命令及び他のメッセージを送信する任意のアプリケーションであり得る。
【０２４０】
第１のメッセージ交換処理５６００は、治療命令生成メッセージ５６１０を操作ウエブサーバ５６０４に送信する治療命令管理アプリケーション５６０２を図示する。操作ウエブサーバ５６０４は、治療情報を確認し操作データ内に治療命令を格納する。操作ウエブサーバ５６０４は、メッセージの受信の成功又は失敗を返信する（５６１２）。
【０２４１】
第２のメッセージ交換処理５６２０は、治療命令更新メッセージ又は治療命令キャンセルメッセージ５６２２を後ほど送信する治療命令管理アプリケーション５６０２を図示する。操作ウエブサーバ５６０４は、治療情報を確認しメッセージに応じて治療命令を更新又はキャンセルする。操作ウエブサーバ５６０４は、メッセージの受信の成功又は失敗を返信する（５６２４）。
【０２４２】
第１のメッセージ交換処理５６００の後に発生する第３のメッセージ交換処理５６４０は、治療命令が実行されるべきであることを示すメッセージ５６４２を送信する治療命令管理アプリケーション５６０２を図示する。治療命令管理アプリケーション５６０２は、治療命令実行メッセージ５６４２を操作ウエブサービス５６０４に送信し、操作ウエブサービス５６０４は、治療命令を確認し、治療命令メッセージ５６４２を医療機器サーバ５６０６に転送する。医療機器サーバ５６０６は、治療命令メッセージ５６４２を医療機器５６０８に転送する。
【０２４３】
医療機器５６０８は、治療命令メッセージ５６４２の受け取りの成功又は失敗を示すメッセージ５６４４を送信する。医療機器サーバ５６０６及び操作ウエブサービス５６０４は、メッセージ５６４４を、命令のトリガとなったアプリケーション５６０２に返送する。
【０２４４】
医療機器がメッセージ５６４４を送信した後のある時点で、医療機器５６０８は、第４のメッセージ処理５６６０を開始する。当該処理では、医療機器は、医療機器が患者に対して治療の提供を開始したことを示す治療開始メッセージ５６６２を医療機器サーバ５６０８に送信する。医療機器サーバ５６０８は、メッセージ５６６２を操作ウエブサービス５６０４に送信する。操作ウエブサービスは治療命令状態を更新する。医療機器サーバは、メッセージ５６６２を、図３６のようなイベント追跡ウエブサービス５６０５に転送し、イベント履歴ログに治療提供イベントを格納する。イベント追跡ウエブサービス５６０５及び操作ウエブサービス５６０４の両者は、治療開始メッセージ５６６２の受け取りの成功又は失敗を示す応答メッセージ５６６４を送信する。
【０２４５】
治療終了イベント又はアラームのような、医療機器が引き起こす追加的イベントが、メッセージ処理５６６０と同様に、構成要素５６０２〜５６０８の間で遣り取りされる。さらに、追加的なメッセージングスキーマも含まれ得る。
【０２４６】
図５７は、医療点滴ポンプのような医療機器の変更されたパラメータを追跡する方法及びシステムを示す。システム５７００は、ここで記述されたように様々なパラメータの変化を識別するためにメタデータを使用して、医療機器の操作に使用される初期パラメータ、更新されたパラメータ及び最終パラメータ値を送信する。システム５７００は、開始操作５７０２から始まる。開始操作は、医療機器における治療の開始に対応する。医療機器において開始される治療は、治療の様々な特徴を定義するパラメータ値を必要とするパラメータを含む。例えば、医療点滴ポンプによって提供される治療においては、様々なパラメータは、基礎比率、ボーラス（bolus）比率、閾値及び様々な他のパラメータを含む。
【０２４７】
初期パラメータ受信モジュールは、医療機器から初期パラメータ値を受け取る（ステップ５７０４）。初期パラメータは、医療機器によって異なるパラメータが受信される前に、医療機器に設定されるパラメータであり、医療機器による治療の提供又はモニタリングに関する任意のタイプの操作パラメータでよい。更新パラメータ受信モジュールは、医療機器から、初期パラメータからの変化に対応する更新されたパラメータ値を受け取る（ステップ５７０６）。更新されたパラメータ値は、医療機器の動作を変更する新たなパラメータ値である。更新されたパラメータ値は、初期パラメータと同じパラメータに関する。最終パラメータ受信モジュールは、医療機器から最終パラメータ値を受け取る（ステップ５７０８）。最終パラメータ値は、更新されたパラメータ値によって機器が再プログラミングされた後、治療及びモニタリングをするために医療機器が使用することになるパラメータ値である。最終パラメータ値は、更新されたパラメータ値と同じであってもよいし、例えば、医療機器のパラメータに対して設定された様々なハード及びソフト制限に基づいて異なる値としてもよい。様々な実施形態において、受信モジュールの処理（ステップ５７０４〜５７０８）は、並列的又は直列的に実行されてもよいし、医療機器から医療機器サーバへの１つ又は複数のメッセージ内に含まれてもよい。
【０２４８】
パラメータ格納モジュールは、医療機器サーバ又は他のバックオフィスコンポーネントのメモリに、初期パラメータ値、更新されたパラメータ値及び最終パラメータ値を格納する（ステップ５７１０）。最終パラメータ受信モジュールが受信した（ステップ５７０８）最終パラメータ値を、医療機器サーバに格納されているハード制限又はソフト制限と比較する追加的ステップをオプションとしてシステム５７００が有し得る。最終パラメータ値が制限を超えた場合、システム５７００は、医療機器サーバでアラームを発してもよいし、オプションとして、パッケージ配備又は他のメッセージを介して医療点滴ポンプにアラームを返信してもよい。他の実施形態においては、アラームは、医療機器に関連付けられた介護人に送信される。
【０２４９】
操作フローは、終了操作で終了する（ステップ５７１２）。終了操作は、ポンプパラメータ値の変更を終了し、更新されたポンプパラメータ値を医療機器サーバ又は他のバックオフィスコンポーネントに格納することに対応する。
【０２５０】
図５８は、図５７の方法及びシステムに応じた、医療機器の初期パラメータ値、更新されたパラメータ値及び最終パラメータ値を列挙する医療機器履歴レポート５８００を示す。医療機器履歴レポート５８００は、医療機器ラベル５８０２、日付及び時刻情報５８０４、クラス情報５８０６、トリガ情報５８０８、メッセージ情報５８１０、場所情報５８１２及び薬品情報５８１４を含む。医療機器ラベル５８０２は、履歴がレポート５８００に表示される機器の医療機器名称に対応する。日付及び時刻情報５８０４は、医療機器履歴レポートに含まれる様々なイベントの発生時刻に対応する。クラス情報５８０６は、イベントのタイプと重症度を記述する。治療変更イベントの場合は、クラス情報５８０６は、変更されたパラメータの初期値と、ユーザによって入力された値を表す当該パラメータの変更された値と、医療機器によって使用される最終設定値を示す当該パラメータの最終値を含む。
【０２５１】
トリガ情報５８０８は、医療機器イベントに関連付けられたトリガを表示する。図示された例では、クラスがアラームであるイベントは高い関心水準を有し、トリガ情報５８０８において警告を含む。しかしながら、治療変更を記述するイベントは、トリガ情報５８０８をアクティブにしない。
【０２５２】
メッセージ情報５８１０は、バッテリ寿命、治療提供進捗度、治療パラメータ制限又は医療機器の物理的特性のような医療機器のステータスについての実施形態を含む。場所情報５８１２は、医療機器を制御する部署、施設及び事業体のような、医療機器の場所に関する情報を含む。薬品情報５８１４は、医療機器によって提供されつつある薬品又は治療についての情報を含み、オプションとして、治療変更のための情報についてのみ含まれるようにしてもよい。医療機器サーバ及び操作ウエブサーバによって追跡された情報に基づいて、医療機器についての追加的な情報が医療機器履歴レポート５８００に表示され得る。
【０２５３】
図５９は、治療履歴レポート５９００を示す。治療履歴レポート５９００は、図５８の医療機器イベント履歴レポート５８００に表示されたものと同じ情報を表示するが、治療イベント情報のみを表示する。治療履歴レポート５９００は、医療機器ラベル５９０２、日付及び時刻情報５９０４、クラス情報５９０６、トリガ情報５９０８、メッセージ情報５９１０、場所情報５９１２及び薬品情報５９１４を含む。各情報は、医療機器イベント履歴レポート５８００の対応するエントリと同様な役割を果たす。
【０２５４】
図６０は、治療傾向レポート６０００を示す。治療傾向レポート６０００は、治療関連イベントの時系列のグラフを表示する。図示された実施形態において、治療傾向レポート６０００は、月ごとの治療イベントの頻度を示す棒グラフを表示する。治療イベントの傾向を表示する他の形状も可能である。
【０２５５】
図６１は、治療変更履歴レポート６１００を示す。治療変更履歴レポート６１００は、図５８の医療機器イベント履歴レポート５８００に表示されたものと同じ情報を表示するが、治療変更イベント情報のみを表示する。治療変更イベントは、医療機器を使用する治療の提供の変更されたパラメータに対応する。治療変更履歴レポート６１００は、医療機器ラベル６１０２、日付及び時刻情報６１０４、クラス情報６１０６、トリガ情報６１０８、メッセージ情報６１１０、場所情報６１１２及び薬品情報６１１４を含む。各情報は、医療機器イベント履歴レポート５８００及び治療履歴レポート５９００の対応するエントリと同様な役割を果たす。
【０２５６】
図６２は、治療変更傾向レポート６２００を示す。治療変更傾向レポート６２００は、治療変更イベントの時系列のグラフを表示する。図示された実施形態において、治療変更傾向レポート６２００は、月ごとの治療変更イベントの頻度を示す棒グラフを表示する。治療変更イベントの傾向を表示する他の形状も可能である。
【０２５７】
Ｃ．イベントウエブサービス：オンラインステータス及び機器動作の閲覧
図６３〜図６６には、図３６のイベントウエブサービスの様々な特徴が記述される。イベントウエブサービスは、外部アプリケーションが医療機器サーバ及びバックオフィスコンポーネントからイベントデータを収集する方法を提供する。具体的には、イベントウエブサービスは、医療機器のオンラインステータスを表示し、図１、図３及び図４で記述されたような医療機器ネットワークの文脈内の医療機器の操作に関する、殆どリアルタイムの遠隔測定情報を可能にする遠隔測定ストリームへのアクセスを提供する。
【０２５８】
図６３は、医療機器のオンラインステータスを決定する方法及びシステムのフローチャートである。システム６３００は、医療機器サーバ又は他のバックオフィスコンポーネント上で作動し、機器とサーバとの間の正確な通信を確保するために予め決定された期間内に医療機器からの通信を待ち受ける。
【０２５９】
システム６３００の操作フローは、開始操作から始まる（ステップ６３０２）。開始操作は、医療機器と医療機器サーバとの間の初期通信に対応する。操作フローは、開始操作（ステップ６３０２）から、待ち受けモジュール（ステップ６３０４）に進む。待ち受けモジュールは、医療機器サーバ及び／又はバックオフィスコンポーネントに、医療機器サーバが通信を待ち受ける予め決定された予想期間を設定する。
【０２６０】
データ受信操作は、メッセージが医療機器サーバによって受け取られたか否かを決定する（ステップ６３０６）。データが医療機器サーバによって受け取られた場合（ステップ６３０６“ＹＥＳ”）、操作フローは、更新モジュールに進み、医療機器のステータスを更新し、機器がオンラインであることを示す（ステップ６３０８）。
【０２６１】
オプションである出力更新モジュールは、メッセージ内の受け取られた情報に基づいて、医療機器サーバからの出力を更新する（ステップ６３１０）。メッセージ内の受け取られた情報は、医療機器ステータス情報、イベントログデータ、遠隔測定データ又は様々な他のタイプのデータを含み得る。ある実施形態において、メッセージは、遠隔測定ストリームの開始点を示し、医療機器からのメッセージに応答して、医療機器サーバ及びバックオフィスコンポーネントは、ダッシュボードスクリーンの外観を更新し、受け取られた遠隔測定データを反映する。他の実施形態において、出力更新モジュールは、１つ又は複数のバックオフィスコンポーネント内の医療機器ステータス情報を更新する。
【０２６２】
医療機器が継続作動し、医療機器サーバは予め決定された期間内に医療機器にメッセージを送信し続けているとデータ受信操作が決定する間（ステップ６３０６）は、操作フローは、データ受信操作（ステップ６３０６）、更新モジュール（ステップ６３０８）及び出力更新モジュール（ステップ６３１０）のループを繰り返す。
【０２６３】
データ受信操作が、予め決定された期間内にデータを受け取ることに失敗した場合（ステップ６３０６“ＮＯ”）は、操作フローはオフラインモジュールに進む。オフラインモジュールは、医療機器サーバ及び／又はバックオフィスコンポーネント内の医療機器の状態をオフラインに変更する（ステップ６３１２）。操作フローは、オプションである出力更新モジュールに進む。出力更新モジュールが出力を更新し、追加的なメッセージが受け取られるまでは、現在表示されているデータは、医療機器サーバによって現在のものとはもはや認識されていないことを示す（ステップ６３１０）。操作フローは、終了モジュールで終了する（ステップ６３１４）。終了モジュールは、医療機器ネットワークの操作を一時停止することに対応する。
【０２６４】
図６４〜図６６は、医療機器から受け取られた遠隔測定ストリームを操作する方法及びシステムを提供する。ここに記述される遠隔測定ストリームは、医療機器から医療機器サーバへの殆ど連続した通信を提供し、ダッシュボード又は他のウエブポータル上で閲覧可能である。
【０２６５】
図６４は、医療機器からの遠隔測定情報を殆どリアルタイムで表示するシステム及び方法のフローチャートを示す。システム６４００の操作フローは、開始ノード６４０２から始まる。開始ノードは、医療機器ネットワーク内で遠隔測定ストリームを送信することが可能な医療機器の開始操作に対応する。新たな状態６４０４は、遠隔測定ストリームがそれ以前に実行されていないことを示す。新たな状態の後、ストリーム開始処理は、図６５で後記するように、遠隔測定ストリームを開始することを試みる。ストリーム開始処理が失敗すると、操作フローは、遠隔測定ストリームの開始の失敗に対応する失敗状態６４０６に進む。操作フローは、次に終了ノード６４０８に進む。
【０２６６】
ストリーム開始処理が成功裏に開始した場合、操作フローは、収集状態６４１０に進む。収集状態は、医療機器から遠隔測定データを収集する医療機器サーバに対応する。収集状態では、遠隔測定データは、医療機器サーバ又は他のバックオフィスコンポーネントに格納され、ダッシュボード又は他のモニタリングユーザインタフェースに出力され得る。
【０２６７】
収集状態６４１０からシステム６４００の操作フローが進み得るオプションは多い。医療機器サーバ又はバックオフィスコンポーネント内に予め決定された予想時間内に、遠隔測定ストリームメッセージを含むメッセージが医療機器から医療機器サーバに送信されない場合、操作フローはオフライン状態６４１２に進む。オフライン状態６４１２は、遠隔測定データを定期的に受け取ることがもはやないシステムに対応する。暫定的レポートが後ほど受け取られた場合は、システム６４００は、収集状態６４１０に戻る。
【０２６８】
遠隔測定ストリームがユーザによって一時停止された場合、操作フローは、一時停止状態６４１４に進む。一時停止状態は、遠隔測定データを受け取ることを一時的に止めるシステムに対応する。ユーザは、遠隔測定ストリームを再開し、システム６４００を収集状態に戻し得る。
【０２６９】
終了状態６４１６へは、ユーザがストリームを終了することによって、又は、システムが医療機器電源切断イベントを受け取ることによって、収集状態６４１０、オフライン状態６４１２、一時停止状態６４１４から進み得る。終了状態６４１６は、遠隔測定ストリームの終了に対応する。終了状態６４１６では、システムは、もはや医療機器から情報を受け取らず、ダッシュボードは更新されない。ある可能な実施形態において、システム６４００が終了状態にあるとき、ダッシュボード又は他のモニタリングインタフェースは、ユーザに、データは現在収集されていないことを示す。終了状態から、操作フローは終了ノード６４０８に進む。
【０２７０】
図６５は、典型的な遠隔測定ストリームメッセージシーケンス６５００、６５２０、６５４０及び６５６０を表示する。遠隔測定ストリームメッセージシーケンスは、図６７に示されるようなダッシュボード６５０２、図３６に示されるようなイベント追跡ウエブサービス６５０４、図３及び図４に開示されるような医療機器サーバ６５０６及び図２に示されるような医療機器６５０８の間で実行される。第１の遠隔測定ストリームメッセージシーケンス６５００は、医療機器からダッシュボードへの遠隔測定ストリームを要求する開始要求を図示する。メッセージシーケンス６５００は、ダッシュボード６５０２が遠隔測定ストリーム開始メッセージ６５１０をイベント追跡ウエブサービス６５０４に送信することから始まる。イベント追跡ウエブサービスは、メッセージ６５１０を医療機器サーバ６５０６に送信する。医療機器サーバは、メッセージ６５１０を医療機器６５０８に送信する。医療機器は、メッセージの成功又は失敗を示す応答メッセージ６５１２を生成する。応答メッセージは、医療機器サーバ６５０６及びイベント追跡ウエブサービス６５０４によって、ダッシュボード６５０２に転送される。
【０２７１】
第２の遠隔測定ストリームメッセージシーケンス６５２０は、医療機器６５０８による遠隔測定ストリームの開始を図示する。医療機器６５０８は、遠隔測定イベント６５２２を生成する。遠隔測定イベントは、医療機器６５０８から医療機器サーバ６５０６への遠隔測定データの殆ど連続的な通信を含む。医療機器サーバは、遠隔測定データを、イベント追跡ウエブサービス６５０４を介してダッシュボード６５０２へ送信する。ダッシュボード６５０２は、遠隔測定データを、殆どリアルタイムでユーザに表示する。ある実施形態において、ダッシュボードは、医療機器の外観を再作成する。ダッシュボードは、遠隔測定ストリームの受け取りに成功したことを示す応答メッセージ６５２４をイベント追跡ウエブサービス６５０４に送信する。
【０２７２】
ダッシュボード６５０２は、遠隔測定ウインドウ取得メッセージ６５２６を生成し、当該メッセージをイベント追跡ウエブサービスに送信する。イベント追跡ウエブサービスは、コマンドの成功又は失敗を示すメッセージ６５２８で応答する。この時点で遠隔測定ウインドウが開始され、ダッシュボード又はウエブポータルは遠隔測定データを表示する。
【０２７３】
この時点で、医療機器の電源が切断された場合、イベント追跡ウエブサービス６５０４は、エラーメッセージで応答し、遠隔測定ストリームを終了する。
【０２７４】
第３の遠隔測定ストリームメッセージシーケンス６５４０は、医療機器が遠隔測定ストリームを生成するのを遮断することによって遠隔測定ストリームを終了することを図示する。医療機器６５０８は、電源切断イベントメッセージ６５４２を生成し、当該メッセージを医療機器サーバ６５０６に送信する。医療機器サーバは、遠隔測定ストリーム終了メッセージをイベント追跡ウエブサービス６５０４に送信する。イベント追跡ウエブサービス６５０４は、メッセージ６５４２の受け取りの成功又は失敗を示す応答メッセージ６５４４を生成する。医療機器サーバ６５０６は、応答メッセージ６５４４を医療機器６５０８に転送する。
【０２７５】
第４の遠隔測定ストリームメッセージシーケンス６５６０は、シーケンス６５４０に関し、ダッシュボード６５０２で遠隔測定ストリームを切断することによって遠隔測定ストリームを終了することを図示する。ダッシュボード６５０２は、遠隔測定ストリーム終了メッセージ６５６２を生成する。遠隔測定ストリーム終了メッセージは、ダッシュボードからイベント追跡ウエブサービス６５０４に送信され、その後、医療機器サーバ６５０６を介して医療機器６５０８へ送信される。医療機器６５０８は、その遠隔測定ストリームを終了し、メッセージ６５６２の受け取りの成功又は失敗を示す応答メッセージ６５６４を生成する。医療機器サーバは、メッセージ６５６４を、イベント追跡ウエブサービス６５０４を介してダッシュボード６５０２に転送する。本発明の開示の医療機器及びダッシュボードを使用して遠隔測定ストリームを開始及び終了するために、追加的なメッセージング処理が可能である。
【０２７６】
図６６は、遠隔測定ストリームクラス６６００を定義する典型的なクラス構造を示す。遠隔測定ストリーム構造６６００は、イベントウエブサービスモジュール３６０６の機能の一部を図示する。遠隔測定ストリームは、図３７の管理ウエブサービス３７００からの様々な機能に関連し、それらの機能を使用する。
【０２７７】
遠隔測定ストリーム構造６６００は、遠隔測定ストリームクラス６６０２及び最新イベントクラス６６０４を含む。遠隔測定ストリームクラス６６０２は、利用可能な遠隔測定ストリームの開始、終了、一時停止及び検索を含む様々な遠隔測定関連操作を含む。追加的な遠隔測定ストリーム操作が遠隔測定ストリームクラス６６０２に含まれ得る。最新イベントクラス６６０４は、最新のイベントを検索する機能を含み、いつ最新のイベントが医療機器から受け取られたかを決定し、このことによって、医療機器のオンラインステータスを決定し、遠隔測定ストリームデータの利用可能性を決定する。追加的な機能が最新イベントクラス６６０４に含まれ得る。追加的なクラスが遠隔測定ストリーム構造６６００に追加され得る。
【０２７８】
他のコンピューティング機器のワークステーションで遠隔測定データを閲覧するために様々な例のダッシュボードが使用されてもよい。ダッシュボードの一例が図６７に示される。ダッシュボード６７００は、当該ダッシュボードが関連付けられているポンプに関する遠隔測定データ（例えば、現在の又は殆ど現在の操作状態）を表示する。ダッシュボード６７００は、遠隔測定データを受け取り、当該データを殆どリアルタイムでユーザに表示する多くのダッシュボードアプリケーションのうちの任意のものであり得る。ダッシュボード６７００は、例えば、図３及び図４のダッシュボード３２８として論理的に図示されたダッシュボードに対応し得る。ダッシュボード６７００は、図６４〜図６６に記述されるように遠隔測定ストリームによって更新され得る。
【０２７９】
図示された実施形態において、ダッシュボード６７００は、ダッシュボードに関連付けられた各医療機器に関する、名称６７０２、識別子６７０４、ドメイン６７０６、アドレス６７０８、ポート６７１０、動作履歴６７１２を追跡する。名称６７０２は、ユーザに認識可能であり、機器自身又はサーバの何れかにに割り当てられた機器の名称に対応する。識別子６７０４は、医療機器の同一性を確認するためにサーバによって使用可能な一意な識別子を提供する。様々な実施形態において、当該識別子は、グローバルユニーク識別子（ＧＵＩＤ）、ハードウエアアドレス又は医療機器の他の識別子に対応し得る。ドメイン６７０６は、医療機器が存在するネットワークの名称を示す。アドレス６７０８は、サーバから医療機器に送信する方法についての接続情報を提供する。図示された実施形態において、アドレス６７０８は、医療機器のＩＰアドレスとして示されている。ポート６７１０は、医療機器の帰還通信ポートを列挙する。動作履歴フィールド６７１２は、サーバと通信した医療機器上に発生した最新イベントの日付及び時刻を列挙する。
【０２８０】
ダッシュボード６７００は、ダッシュボードが関連付けられたポンプの操作ステータスを図示する。図示された実施形態において、“MD0333”、“MD0444” “MD0524”、“MD0324”及び“MD0988”という名称の５つの医療機器がダッシュボード６７００で追跡されている。第１、第４及び第５の機器（MD0333、MD0324及びMD0988）は電源が投入されており、患者に治療を提供しているものとして図示されている。第２の機器（MD0444）は、機器の異常動作の可能性又は機器に関連付けられた患者に関する緊急条件を示すアラーム状態にあるものとして示されている。第３の機器（MD0524）は、医療機器に発生している機能不全又はエラーを示す故障状態にあるものとして示されている。操作ステータスを示す他の状態がダッシュボード６７００上に図示されてもよい。
【０２８１】
オプションとして、ユーザが異なるタイプの情報をフィルタリングする又は表示することを可能にする追加的な特徴がダッシュボード６７００に含まれ得る。図示されている実施形態において、一時停止チェックボックス６７１４及びオフライン機器チェックボックス６７１６は、ユーザがダッシュボードを選択可能に修正することを可能にする。一時停止チェックボックス６７１４は、選択されると、ダッシュボードの情報の更新を中止してダッシュボードを一時的に固定し、ユーザがダッシュボードの状態を一度に閲覧することを可能にする。一時停止チェックボックス６７１４が選択されていないときは、ダッシュボード上のステータス情報は、関連付けられた医療機器から受け取られたデータを継続的に更新し得る。オフライン機器チェックボックス６７１６は、ダッシュボードが、ダッシュボードに関連付けられた機器に関する情報を表示することを可能にするが、当該機器はオンラインではなく、ダッシュボードは、当該機器から最新のステータス情報を受け取っていない。ユーザがモニタリングすべき機器の所望のセットを選択すること、及び、これらのユーザから受け取られた遠隔測定データの特定部分を閲覧することを可能にする他の表示特徴及びフィルタがダッシュボードに具現化されることも可能である。
【０２８２】
前記の様々な実施形態は例示のためにのみ提供されており、本発明を限定するものと解釈されてはならない。当業者であれば、ここに記述された実施形態及び適用例に従うことなく、かつ請求の範囲に記載される本発明の主旨を逸脱することなく、本発明に対してなされ得る様々な修正及び変更を認識できるであろう。
【符号の説明】
【０２８３】
１００  医療機器ネットワーク
１０２  医療機器サーバ
１０４  医療機器
１０６  受動的医療機器
１０８  医療ポンプ
１１０  ワークステーション
１１２  携帯コンピューティングシステム
１１４  スイッチ
１１６  無線アクセスポイント
２００  医療機器
２０２  プログラマブル回路
２０４  ＲＡＭ
２０６  フラッシュ
２０８  ＥＥＰＲＯＭ
２１０  バッテリシステム
２１２  入力装置
２１４  出力装置
２１６  ディスプレイ
２１８  アラーム
２２０  有線ネットワークインタフェース
２２２  無線ネットワークインタフェース
２２４  患者インタフェース
３００  ソフトウエア構造
３０２  医療機器
３０４  バックオフィスコンポーネント
３０６  クライアントアプリケーション
３０８  医療機器サーバ
３１０  管理ウエブサービス
３１２  イベント追跡ウエブサービス
３１４  動作ウエブサービス
３１６  管理
３１８  イベント追跡
３２０  動作
３２２  データウエアハウス
３２４  管理ウエブフォーム
３２６  レポート
３２８  ダッシュボードウエブフォーム
３３０  保守ウエブフォーム
３３２  外部アプリケーション
４００  ソフトウエア構造
４０４  施設コンポーネント
【図１】
2014006915.tif 000003
【図２】
2014006915.tif 000004
【図３】
2014006915.tif 000005
【図４】
2014006915.tif 000006
【図５】
2014006915.tif 000007
【図６】
2014006915.tif 000008
【図７】
2014006915.tif 000009
【図８】
2014006915.tif 000010
【図９】
2014006915.tif 000011
【図１０】
2014006915.tif 000012
【図１１】
2014006915.tif 000013
【図１２】
2014006915.tif 000014
【図１３】
2014006915.tif 000015
【図１４】
2014006915.tif 000016
【図１５】
2014006915.tif 000017
【図１６】
2014006915.tif 000018
【図１７】
2014006915.tif 000019
【図１８】
2014006915.tif 000020
【図１９】
2014006915.tif 000021
【図２０】
2014006915.tif 000022
【図２１】
2014006915.tif 000023
【図２２】
2014006915.tif 000024
【図２３】
2014006915.tif 000025
【図２４】
2014006915.tif 000026
【図２５】
2014006915.tif 000027
【図２６】
2014006915.tif 000028
【図２７】
2014006915.tif 000029
【図２８】
2014006915.tif 000030
【図２９】
2014006915.tif 000031
【図３０】
2014006915.tif 000032
【図３１】
2014006915.tif 000033
【図３２】
2014006915.tif 000034
【図３３】
2014006915.tif 000035
【図３４】
2014006915.tif 000036
【図３５】
2014006915.tif 000037
【図３６】
2014006915.tif 000038
【図３７】
2014006915.tif 000039
【図３８】
2014006915.tif 000040
【図３９】
2014006915.tif 000041
【図４０】
2014006915.tif 000042
【図４１】
2014006915.tif 000043
【図４２】
2014006915.tif 000044
【図４３】
2014006915.tif 000045
【図４４】
2014006915.tif 000046
【図４５】
2014006915.tif 000047
【図４６】
2014006915.tif 000048
【図４７】
2014006915.tif 000049
【図４８】
2014006915.tif 000050
【図４９】
2014006915.tif 000051
【図５０】
2014006915.tif 000052
【図５１】
2014006915.tif 000053
【図５２】
2014006915.tif 000054
【図５３】
2014006915.tif 000055
【図５４】
2014006915.tif 000056
【図５５】
2014006915.tif 000057
【図５６】
2014006915.tif 000058
【図５７】
2014006915.tif 000059
【図５８】
2014006915.tif 000060
【図５９】
2014006915.tif 000061
【図６０】
2014006915.tif 000062
【図６１】
2014006915.tif 000063
【図６２】
2014006915.tif 000064
【図６３】
2014006915.tif 000065
【図６４】
2014006915.tif 000066
【図６５】
2014006915.tif 000067
【図６６】
2014006915.tif 000068
【図６７】
2014006915.tif 000069