医療デバイスからのデータを表示する方法および装置
本発明は、一側面では、複数の非同種の環境医療デバイスからのデータの表示を提供するためのシステムに関する。一実施形態では、システムは、データを第２のプロトコルに変換するためのローカル認証局と、ローカル認証局と通信する中央認証局と、中央認証局と通信するユーザインターフェースとを含む。中央認証局は、ユーザインターフェースによる表示のために、第２のプロトコルに変換されたデータをルーティングする。別の実施形態では、第１のプロトコルは、ネイティブデバイスプロトコルであり、第２のプロトコルは、同種のシステムプロトコルである。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本願は、米国仮特許出願第６１／２５０，９４７号（２００９年１０月１３日出願）の優先権を主張し、この出願の開示は、その全体が本明細書に参照によって援用される。
【背景技術】
【０００２】
（発明の分野）
本発明は、概して、医療デバイスの分野に関し、より具体的には、中央の場所における医療デバイスからの患者データを変換および表示する分野に関する。
【発明の概要】
【課題を解決するための手段】
【０００３】
本発明は、一側面では、複数の非同種の環境医療デバイスからのデータの表示を提供するためのシステムに関する。一実施形態ではシステムは、データを第２のプロトコルに変換するためのローカル認証局と、ローカル認証局と通信する中央認証局と、中央認証局と通信するユーザインターフェースとを含む。中央認証局は、ユーザインターフェースによる表示のために、第２のプロトコルに変換されたデータをルーティングする。
【０００４】
別の実施形態では、第１のプロトコルは、ネイティブデバイスプロトコルであり、第２のプロトコルは、同種のシステムプロトコルである。一実施形態では、同種のシステムプロトコルは、ＸＭＬである。さらに別の実施形態では、第１のプロトコルは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）であって、第２のプロトコルは、本明細書では、ＸＭＬ、ＣＰＣ ＸＭＬ、またはＴＣＰ／ＣＰＣ ＸＭＬと称される、別のプロトコルとＴＣＰの組み合わせである。
【０００５】
別の実施形態では、システムはさらに、ローカル認証局と中央認証局との間で通信するスマートアラームモジュールを含む。スマートアラームモジュールは、医療デバイスからのデータが、アラームをトリガするための所定の基準を満たすか否かを決定する。さらに別の実施形態では、システムはさらに、スマートアラームモジュールと通信するデータベースを含む。なおもさらなる別の実施形態では、システムはさらに、中央認証局およびデータベースと通信するデータベースインターフェースを含む。
【０００６】
一実施形態では、システムはさらに、データベースとウェブインターフェースとの間で通信するインターネット情報サーバを含む。別の実施形態では、システムはさらに、データベース、スマートアラームモジュール、およびユーザインターフェースと通信する構成サービスを含む。さらに別の実施形態ではシステムはさらに、ローカル認証局と医療デバイスとの間で通信するデマルチプレクサを含む。なおもさらなる別の実施形態では、ローカル認証局は、中央認証局の近傍に物理的に位置する一方、別の実施形態では、ローカル認証局は、医療デバイスの近傍に物理的に位置する。
【０００７】
本発明の別の側面は、複数の非同種の環境医療デバイスからのデータの表示を提供するための方法である。一実施形態では、方法は、ローカル認証局によって、医療デバイスから、第１のプロトコルを使用して、データを受信するステップと、ローカル認証局によって、データを第２のプロトコルに変換するステップと、ローカル認証局によって、第２のプロトコルにおいて、データを中央認証局に伝送するステップと、中央認証局によって、第２のプロトコルにおいて、データをユーザインターフェースに伝送するステップと、ユーザインターフェースによって、データを表示するステップとを含む。
【０００８】
別の実施形態では、方法はさらに、スマートアラームモジュールによって、医療デバイスからのデータが、アラームをトリガするための所定の基準を満たすか否かを決定するステップを含む。さらに別の実施形態では、方法はさらに、ローカル認証局による第２のプロトコルへのデータの変換に先立って、医療デバイスからのデータを逆多重化するステップを含む。
【０００９】
本願は、２００４年１１月８日出願の米国特許出願第１０／９８４，１８６号および２００１年２月２３日出願の米国特許第６，８３９，７５３号の開示をその全体として組み込む。
【００１０】
本発明は、添付の請求項における特殊性によって注目される。前述の本発明の利点は、さらなる利点とともに、以下の説明と関連して検討される付随の図面を参照することによって、より理解される。図面中、同一参照文字は、概して、異なる図を通して、同一部品を指す。図面は、必ずしも、正確な縮尺ではなく、代わりに、概して、本発明の原理を例示するために強調される。
【図面の簡単な説明】
【００１１】
【図１】図１は、本発明のシステムの実施形態のブロック図である。
【図２】図２は、着目補足情報とともに、種々の患者アイコンの図の実施形態を示す。
【図３】図３は、スマートアラームを設定するためにアクセスされる、別のユーザインターフェース画面の実施形態を示す。
【図４】図４は、各患者のために設定されるスマートアラームを列挙する、概要画面の実施形態を示す。
【図５】図５は、本発明の医療デバイス監視システムに対する種々の管理機能を行うために好適なグラフィックユーザインターフェースの実施形態のスクリーンショットである。
【図６】図６は、複数のベッドを同時に監視するための画面のスクリーンショットである。
【図７】図７は、別の監視画面のスクリーンショットである。
【図８】図８は、ログ画面の実施形態を図示する。
【図９】図９は、経時的な種々の患者傾向を示すためのユーザインターフェースの実施形態を図示する。
【図１０】図１０Ａは、本発明のある実施形態による、ローカル認証局サーバに関する付加的な詳細によってシステムを図示する。図１０Ｂは、本発明のある実施形態による、ローカル認証局サーバに関する付加的な詳細によってシステムを図示する。
【図１１】図１１は、本発明の別のシステム実施形態のブロック図を図示する。
【発明を実施するための形態】
【００１２】
図および本願中におけるＣＰＣ ＸＭＬまたはＴＣＰ／ＣＰＣ ＸＭＬの参照は、ＸＭＬならびに医療デバイスおよび医療デバイスデータに関連する情報を含有するＸＭＬの広範囲の使用を包含する。したがって、一実施形態では、ＣＰＣ ＸＭＬは、ＸＭＬ、または医療デバイスまたは患者情報を伝送する、あるいは含む、もしくは別様に患者監視システムと協働するように修正されるＸＭＬを指す。同様に、一実施形態では、ＴＣＰ／ＣＰＣ ＸＭＬは、ＴＣＰまたはＸＭＬ、ならびに医療デバイスまたは患者情報を伝送する、あるいは含む、もしくは別様に患者監視システムと協働するように修正されるＴＣＰおよびＸＭＬを指す。
【００１３】
概要として、図１を参照すると、一実施形態では、異種の医療デバイス１０、１０’、１０’’、１０’’’（概して、１０）は、複数の方法において、本発明のシステムに接続される。医療デバイス１０は、典型的には、それぞれ、患者データ等のデバイス特有のデータのためのシリアル出力２２、２２’を有する。一般に、医療デバイスおよびシステムは、患者を監視し、患者データを収集し、改良された医療治療および患者の安全性をもたらすように変換および処理される。一実施形態では、その独自のネイティブデバイスプロトコルを伴う、種々の種類の医療デバイスを使用することができる。さらに、一実施形態では、本明細書で使用されるように、用語「医療デバイス」は、患者データを収集し、患者安全性を補助するために使用される、または別様に、１人以上の患者の医療治療あるいは診断を促進するために使用される任意のデバイスを含むことができるが、それらに限定されない。一実施形態では、医療デバイスのネイティブプロトコルは、種々の異種の医療デバイス１０と通信するか、または別様に、データを交換するために、システムによって使用される同種のプロトコルに翻訳、変換、あるいは再マッピングされる。
【００１４】
別の実施形態では、医療デバイス１０’’’は、中央認証局３０（後述される）を介して、システムに接続する。代替として、医療デバイス１０’はまた、ゲートウェイ１８を使用して、ローカル認証局に接続することができる。なおも別の実施形態では、医療デバイス１０’’は、スマートアラームモジュール３４（後述される）を介して、システムに接続する。
【００１５】
示される一実施形態では、医療デバイス１０のシリアル出力ポート２２は、医療デバイス１０のシリアル出力をインターネット伝送制御プロトコル（ＴＣＰ／ＩＰ）等のネットワークを介して使用するために好適なプロトコルに変更する、ネットワークデバイス１４に接続される。別の実施形態では、医療デバイス１０’のシリアル出力ポート２２’は、ゲートウェイ１８に接続される。ゲートウェイ１８は、いくつかの医療デバイス１０’をゲートウェイ１８に接続させ、デバイス１０’のそれぞれからのデータをＴＣＰ／ＩＰまたはユーザデータグラムプロトコル（ＵＤＰ）を使用するネットワークを介した伝送に好適な単一データストリームに多重化することによって、データ接続を形成する。
【００１６】
第３の実施形態では、医療デバイスは、スマートアラーム３４を介してシステムに接続される１０’’である。別の実施形態では、医療デバイス１０’’’は、中央認証局３０を介して、システムに接続される。
【００１７】
医療デバイス１０が、ネットワークデバイス１４に接続される実施形態では、データが、ネットワークデバイスから到着すると、ＴＣＰ／ＩＰパケットは、ローカル認証局２６によって、直接受信される。第２の実施形態では、データが、ゲートウェイ１８から到着する場合、データは、ローカル認証局２６への送信に先立って、デマルチプレクサ３０を通してパスされる。デマルチプレクサ３１またはｄｅｍｕｘは、各デバイス１０’のために、ＴＣＰ／ＩＰあるいはＵＤＰパケットを別個のＴＣＰ／ＩＰパケットに分離する。一実施形態では、代替通信チャネル１９は、ゲートウェイ１８およびローカル認証局２６が、デマルチプレクサ３１無しで、データを交換するように存在する。
【００１８】
次いで、実施形態に応じて、ローカル認証局２６は、データを中央認証局３０またはスマートアラームモジュール３４のいずれかに送信する。データが、ローカル認証局２６から中央認証局３０に直接送信される場合、通信は、一実施形態では、ＴＣＰ／ＩＰプロトコルを利用する。データが、ローカル認証局２６によって、スマートアラームモジュール３４に送信される場合、メッセージが、ＴＣＰ／ＩＰ、ＸＭＬ、ＴＣＰ／ＣＰＣ ＸＭＬプロトコル等の同種のシステムプロトコル、または別の好適なプロトコルを使用して、送信される。一実施形態では、ＣＰＣ ＸＭＬプロトコルが、種々の利点を提供するために、使用される。
【００１９】
従来のＴＣＰプロトコルと組み合わせて、ＸＭＬベースのプロトコルを使用する有利な理由の１つは、一実施形態では、医療デバイス監視システムが、ＴＣＰ／ＩＰソケットを使用して、ある医療デバイスデータを伝送することである。本医療デバイスデータは、監視システムに接続された医療デバイスの状態を記述する。対照的に、一例示的実装では、ＸＭＬ文書は、クライアントブリッジ（イーサネット（登録商標）コンバータに直列である）、システム全体のサーバによって、または医療デバイス自体から直接、生成される。データを生成し、伝送する、任意の構成要素またはデバイス（医療デバイス、サーバ、ブリッジ等）は、システムによって、発行元であると決定される。ＴＣＰ／ＩＰソケットは、ＸＭＬ文書と組み合わせて使用されるため、２つのプロトコルシステムは、全体的監視システムにルーティングされるデータを管理するために使用される。発行元に関する付加的詳細および説明は、図１０Ｂの議論で後述される。
【００２０】
構成要素またはデバイスが、１つ以上の医療デバイスからデータを収集する関連責任を伴う発行元として扱われる時、そのような発行元は、ローカル認証局２６として知られる。ローカル認証局は、図１０Ｂに示されるように、デバイスデータを関係のあるデータ利用者に情報を配信する責任を負うシステムに提供する。
【００２１】
一実施形態では、ローカル認証局２６は、中央認証局３０と同一場所に物理的に位置する。他の実施形態では、ローカル認証局２６および任意のデマルチプレクサ３０は、医療デバイス１０’の近傍に物理的に位置する、またはゲートウェイ１８自体の一部であってもよい。一般に、図に示されるトポロジ、および種々のモジュール、インターフェース、サブシステム、システム等は、所与の患者監視シナリオのために、必要に応じて、機能または場所毎に、結合または分離することができる。一実施形態では、システムの異なる要素は、異なる場所に位置することができる。例えば、図１に示されるように、いくつかの実施形態では、システムの異なる要素は、分離され、異なる物理的場所に位置することができる。一実施形態では、システムは、示されるように、異なる物理的場所ＡおよびＢにおいて、構成要素に分離される。
【００２２】
スマートアラームモジュール３４は、医療デバイスからのデータ１０、１０’が、臨床医によって設定された値から逸脱すると、付加的アラームを発生するために使用される。このように、臨床医は、例えば、医療デバイス１０、１０’自体から直接利用不可能である、パラメータの変更率に基づいて、アラームを設定してもよい。例えば、スマートアラームモジュール３４によって発生されるアラームは、同種のシステムプロトコルを使用して、中央認証局３０に送信される。スマートアラーム設定値を定義する値は、ＴＣＰ／ＩＰプロトコル、別のプロトコル、または同種のシステムプロトコルを使用して、構成サービス３８によって、スマートアラームモジュール３４に書き込まれる。
【００２３】
中央認証局３０によって、ローカル認証局２６またはスマートアラーム３４のいずれかから受信したデータは、同種のシステムプロトコルを使用して、ユーザインターフェース４２に伝送される。中央認証局３０はまた、ＴＣＰ／ＣＰＣ ＸＭＬメッセージ等の同種のシステムプロトコルに基づいて、メッセージをデータベースインターフェース４６に伝送する。データベースインターフェース４６は、データベース５０内に記憶するために、同種のデータをアクティブＸデータオブジェクト（ＡＤＯ）に変換する。このように、システムによって受信されたイベントは、スマートアラームを含め、ログをとることができる。
【００２４】
ユーザインターフェース４２は、ＴＣＰ／ＣＰＣ ＸＭＬプロトコル等の同種のシステムプロトコルを使用して、構成サーバ３８にデータを書き込む。次に、データは、ＡＤＯを使用して、構成サーバによって、データベース５０に書き込まれる。データベース５０はまた、管理ツールＨＬ７ＡＤＴによって書き込まれ、これは次に、ＴＣＰを使用して、構成サーバ３８によって書き込まれる。管理ツールは、患者情報を更新するために使用される。管理ツールＨＬ７ＡＤＴはまた、例えば、病院または他の医療供給者（または、その下位単位）における、患者電子医療記録（ＥＭＲ）ならびに患者入院、退院、および転院記録（ＡＤＴ）から情報を受信し、そこにデータを伝送する。
【００２５】
最後に、ウェブインターフェース５８は、システムへのブラウザアクセスを可能にする。一実施形態では、アクセスは、ＨＴＴＰセキュアプロトコルを使用して付与される。ウェブインターフェース５８は、ＡＤＯを使用して、データを読み、データベース５０にデータを書き込むために、インターネット情報サービス６２を使用する。
【００２６】
モジュールのそれぞれを個々に検討すると、スマートアラームモジュール３４は、ローカル認証局２６から受信することによってデータをレビューする。患者と関連付けられたデータは、データベース内に記憶されるように、種々のパラメータのためのアラーム設定と比較される。アラームがトリガされると、アラームは、ユーザインターフェース４２を介して、複数のユーザ画面上に表示される。
【００２７】
いくつかの実施形態では、データベースをバイパスすることは、種々の速度およびデータ処理利点を提供する。データストリームを分割し、それを復元することによって、システムが拡大縮小する。その結果、システムは、他のデバイス（サーバ、プロセッサ、ルータ、ハブ等）に作業を分担することができる。例えば、ＸＭＬパケットが到着すると、システムは、それを複製し、リダイレクトし、２つの異なるストリームまたはチャネルを介して送信することができる。これは、それらの２つの分割されたストリームと関連付けされる任意の処理または送達負荷を分割する。本明細書に説明される、ルーティングおよびデータ送達の一部として、各データストリームは、さらに処理を分配し、負荷を移動させるために、継続的に複製し、反復的に分割することができる。一実施形態では、これを行う関連コストは、データストリームを分割するために使用される時間である。本時間周期は、典型的には、患者安全性の維持と関連付けられた計器感度およびタイミングニーズに対して、十分に短時間に制御される。
【００２８】
同種のシステムプロトコルの一実施例は、ＸＭＬである。ＸＭＬは、十分に開発された標準的デベロッパツールを有する。加えて、ＸＭＬは、利点を有する。例えば、フレキシブルデータパケットは、システムの処理／受信側における不必要な複雑性を伴うことなく、種々の異なるデバイスからの入力を取り扱うことができるように生成することができる。一実施形態では、波形全体をＸＭＬパケット内にエンコードすることができる。ＸＭＬシーケンスは、拡大し、ＴＣＰ／ＩＰパケットの最大ペイロードサイズに到達すると、複数のＴＣＰ／ＩＰパケットにわたって分割することができる。
【００２９】
ＴＣＰ／ＩＰおよびＸＭＬは、２つの異なるネットワーク層で使用される。ＸＭＬは、パケット搬送データである。ＴＣＰ／ＩＰ層は、パケットが進む回線としての役割を果たす。ＴＣＰ／ＩＰは、肯定応答およびシーケンス番号の両方を提供し、保証された送達を提供するように機能する。
【００３０】
図２は、着目する補足情報を伴う種々の患者データの表示の画面ビューを示している。さらに、このスクリーンショットでは、アラーム８０がトリガされて示されている。実施例では、この患者の酸素レベルは、設定限界値を下回っている。その結果、臨床医が、アラームと関連付けられた患者または医療デバイスを確認することができるように電話がかけられる。
【００３１】
図３では、本明細書に説明されるシステムおよび方法によって監視される種々の患者のそれぞれに対して、スマートアラームを設定するための具体的詳細および種々のパラメータが示される。
【００３２】
このディスプレイにおいて、種々の患者パラメータのための上限および下限値は、臨床医によって設定することができる。加えて、所与の時間周期内に生じ得る連続アラームの数を付加的安全性特徴として設定することができる。最後に、画面はまた、所与のパラメータのための正常範囲も示す。図４では、システムのユーザは、患者毎に設定されるすべてのスマートアラームを視認することができる。この表示では、各スマートアラームは、設定時間、その値、その限界値、および任意のコンテキストメッセージとともに、別個に列挙される。ナースコールインジケータは、スマートアラームが生じたことを示し、患者および部屋番号を列挙する。
【００３３】
ユーザインターフェース４２は、システムにデータを入力し、そこから情報を読み出すために、臨床医または他のユーザによって使用される。図５は、本明細書に説明される医療デバイス監視システムに対して、種々の管理機能を行うために好適なグラフィックユーザインターフェースのスクリーンショットである。一実施形態では、図５のスクリーンショットは、図１に示されるウェブインターフェース５８またはユーザインターフェース４２と関連付けられる。示されるように、インターフェースは、ユーザにあるタスクを行わせる、種々のマウスクリック可能な要素を含む。これらのタスクは、新しい患者の入院、全体的監視システムへの新しい医療デバイスの追加、医療デバイス（Ｄ／Ｃ）の廃棄、患者間の医療デバイスの交換、患者データの編集、患者の転院、患者監視スタッフへのポケベルの割当、スマートアラームの更新および設定、ならびに種々のインターフェース画面の全体的ビューの調節を含むが、それらに限定されない。概して、インターフェース実施形態のうちのいくつかにおいて使用されるように、ベッドまたは部屋識別子は、患者およびデバイスにリンクされて示される。加えて、アラートのうちの１つ以上もまた、示される。一実施形態では、用語「アラート」および「アラーム」は、互換可能に使用され、いずれかの用語の最も広範な合理的意味を包含する。別の実施形態では、アラームは、所与の患者または他の着目医療パラメータのための特定の閾値の個別の監視である。例えば、アラーム監視は、高心拍数であってもよい。一実施形態では、アラートは、多くの場合、状況的である。アラームは、多くの場合、収集されたデータによって駆動される。一実施形態では、アラートは、受信患者データの処理に基づいて検出された根本問題に基づく、アラームのトリガに応答して表示される結果である。例えば、アラートは、心室頻拍の発症等、システムユーザに表示されるものであってもよい。電極の患者からの離脱は、アラートの原因の別の実施例である。
【００３４】
図６は、複数のベッドを監視する責任を負うユーザが、それらのすべてまたはそれらの下位集合を同時に見ることを可能にする概要画面を示す。図６に示されるように、個々のベッドアイコンは、クリック可能であって、拡張表示ビューを生成するか、または画面アラーム等のあるパラメータを設定するために選択することができる。
【００３５】
図７は、幾人かの患者を同時に監視する際に有用な別のモニタ画面である。スクリーンショット８５の右下部分の患者表示は、停止中の医療デバイスを示す。停止中の医療デバイスは、オフであって、データを送信していないデバイス、または故障状態にあるデバイスである。デバイススタンバイモードは、ネットワークリンクにわたって識別可能な「心拍インジケータ」を有するため、スタンバイモードは、典型的には、停止中モードと同一ではないが、いくつかのデバイス実施形態では、その可能性がある。加えて、他の６つのアクティブ患者監視ウィンドウは、リアルタイムまたは実質的にリアルタイムで、脈拍数または血中酸素濃度等の患者データを表示している。これらの６つのウィンドウはそれぞれ、マウスを使用して、臨床医または他の患者監視ユーザによって選択可能である。ウィンドウ８６のうちの１つをクリックすると、図７に示されるように、付加的詳細８７を伴う、ドロップダウンビューが表示される。
【００３６】
図８は、異なるネットワーク、患者、および医療デバイスイベントが、経時的に生じることに伴って、種々の着目情報を含むログ画面を図示する。これらのイベントを経時的に記録することによって、データは、システム故障の場合、または監視されている患者のうちの１人に対して、医療上の緊急事態が生じる場合、保存される。
【００３７】
図９は、経時的種々の患者傾向を示すためのユーザインターフェースである。種々の患者および着目パラメータを選択することによって、ネットワーク中継医療デバイスデータに基づいて、傾向またはパターンを示すように、プロットを生成することができる。一実施形態では、パラメータ、アラート等の優先順位が付けられたリストを示す、またはデータを監視システムに提供するデバイスの種類に基づいて、画面の設計を更新することが可能である。一実施形態では、経時的にパラメータのリストの優先順位を付けることによって、最も重要な測定が、監視画面のトップに来るが、経時的に変化してもよい。例えば、一ユーザインターフェース実施形態では、第１の重要測定と関連付けられた事象が存在しない場合、次の測定が、画面上のトップ位置にスライドアップする。これは、画面の専有面積を管理し、患者監視に責任を負うユーザに、優先情報に焦点を当てさせることに有用である。
【００３８】
一実施形態では、ワークフローおよび患者状態または患者に取り付けられたデバイスの種類を表示することができる。例えば、ワークフローは、施設の種類に基づいて、変更することができる。人工呼吸器施設は、循環器病棟とは対照的に、異なるアラームまたはアラームの異なる組み合わせを要求してもよい。すべての呼吸パラメータは、最初に、呼吸器科病棟において、表示される。反対に、心臓パラメータは、最初に、循環器病棟において、表示される。
【００３９】
一実施形態では、データを表示するための階層が使用される。患者の状態、健康、診断、病棟の種類、場所等に基づいて、情報はすべて、患者または医療デバイスパラメータの画面表示上で調節するために使用することができる。一実施形態では、システムは、履歴情報、またはある患者パラメータが最大変化率を受ける程度に基づいて、情報がどのように表示されるかに関して、自動プログラムすることができる。したがって、医療デバイスを使用して、所与の患者から収集された血圧が、降下し続ける場合、システムは、ユーザインターフェースの一部として、血圧がどのように表示されるかを変更することができる。例えば、画面システム上のアイテムのリスト内に、リスト上でより高い血圧を掲げ、したがって、患者に発症している問題の指標としの最も重要な画面要素として、強調することができる。患者に絶えず問題がある、またはパラメータ値が絶えず閾値を超過する場合、スマートシステムを使用して、より頻繁に生じる閾値超過に注意を向けることは、いくつかの利点をもたらす。一実施形態では、本明細書に説明されるシステムは、病院の情報システムおよびデータベースにデータを取り込み、ならびにそのようなシステムからの情報を使用して、システム自体によって使用されるデータベースにデータを取り込むことができる。
【００４０】
図１０Ａは、医療デバイスＡ、１１０は、ネイティブデバイス言語を使用して、ブリッジ１１２とデータを交換する、医療デバイスデータ交換システム１００を示す。次に、ブリッジ１１２は、第１のプロトコルであるプロトコルＸを使用して、ローカル認証局サーバ１１６とデータを交換する。別の実施形態では、デバイスネットワークＢ、１１８もまた、第２のプロトコルであるプロトコルＹを使用して、ローカル認証局サーバ１１６と通信する。本デバイスネットワークＢは、そのようなベッドのそれぞれにおける各患者と関連付けられた医療デバイスを伴う、複数のベッド等の複数の医療デバイスを有するネットワークを含んでもよい。ローカル認証局サーバ１１６は、本実施形態では、示されるように、それぞれ、プロトコルＸおよびプロトコルＹ等の異なるプロトコルを受信するように構成される、パーサＸ、１２０およびパーサＹ、１２２等の複数のパーサを含む。
【００４１】
一実施形態では、各それぞれのパーサは、関連ネイティブデバイスまたはネットワークプロトコルを共通の同種のシステムプロトコル１２３に変換する。医療デバイス１１０またはネットワーク１１８から受信した下層データは、同種のプロトコルを使用して、抽象デバイス１２５に通信される。抽象デバイス１２５の役割は、メモリ内に受信されることに伴ってデータパケットを表すことである。パケットデータは、抽象デバイス１２５から同種のプロトコル出力１３０に送信される（本実施例では、ＣＰＣ／ＸＭＬ出力として示される）。医療デバイスデータが変換されると、例えば、Ｂｅｒｎｏｕｌｌｉエンタープライズサーバ等のデータ監視または処理サーバ１３２に送信される。一実施形態では、医療デバイスデータは、ＣＰＣ／ＸＭＬ等のＸＭＬ形式で中継される。
【００４２】
図１０Ｂは、患者が監視されることに伴って、医療デバイスデータが生成される、全体的システムまたはプラットフォーム１５０を示す。一実施形態では、患者データを捕捉し、それをシステムの残りに中継するエンティティは、データ発行元と称される。下層患者データは、医療デバイス１１０Ａ、１１０Ｂ、および１１０Ｃ（概して、１１０）によって捕捉される。３つの医療デバイスが、例示として、図１０Ｂでは示されるが、システムは、任意の数の医療デバイスを含むことができることを理解されるであろう。前述のように、ＸＭＬを生成し、伝送する、任意の構成要素またはデバイス（医療デバイス、サーバ、ブリッジ等）は、システムによって、発行元として取り扱われる。ＴＣＰ／ＩＰソケットの両方が、ＸＭＬページと組み合わせて使用されるため、２つのプロトコルシステムは、全体的監視システムにルーティングされるデータを管理するために使用される。一実施形態では、医療デバイス１１０ａ−１１０ｃは、１つ以上の認証局に情報を伝送すると、発行元１５５として動作することができる。一実施形態では、医療デバイス１１０は、前述のように、ローカル認証局１６０および／または中央認証局１６３にデータを中継する。
【００４３】
図１０Ｂを継続して参照すると、いくつかの実施形態では、認証局（例えば、ローカル認証局１６０および中央認証局１６３）は、医療デバイスからのデータを受信することによって、利用者として、データを他のシステム構成要素に伝送することによって、発行元として、機能することができる。１つのローカル認証局および１つの中央認証局が、例示のために、図１０Ｂでは示されるが、システムは、任意の数のそのような認証局を含むことができることを理解されるであろう。一実施形態では、ローカル認証局１６０は、中央認証局１６３に情報を中継すると、発行元として機能する。一実施形態では、発行元は、関係のあるデータ利用者１７０に情報を配信する。一実施形態では、処理された医療デバイスデータを利用者１７０に送信する、この配信ハブは、中央認証局１６３である。利用者１７０として機能することができる、デバイスおよびインターフェースの非限定的実施例は、ポケベルサービス１６６、ＧＵＩアプリケーション１６１、およびデータベースインターフェース１６８を含む。
【００４４】
図１１は、スマートアラームシステムに関連する付加的詳細ならびに例示的接続およびデータフィードとともに、患者が監視されるときに、医療デバイスデータが生成される、全体的システムまたはプラットフォーム２００を示す。示されるように、スマートアラームシステムまたはサービス３４は、メッセージあるいは他のデータ要素の形式において、医療デバイスデータを受信（または、送信）する。スマートアラームシステムは、ＸＭＬ等の第１のプロトコルにエンコードされる受信医療デバイスデータを分析し、いくつかのスマートアラームの種類（逸脱、限界値、組み合わせ、または連続）のうちの１つか否か決定する。具体的には、逸脱アラームは、設定値からの患者値の逸脱によってトリガされるものである。限界値アラームは、指定範囲外に移動する患者値によってトリガされるものである。組み合わせアラームは、２つ以上の他のアラームの発生がアラームを生じさせるものである。例えば、血圧が、正常範囲外に降下し、心拍率が、正常範囲を超える場合、アラームがトリガされるであろう。連続アラームは、所与のアラームが設定回数を超えてトリガされる場合、トリガされるものである。例えば、３０秒の持続時間の少なくとも２回の酸素飽和度の低下が、２分以内に生じる場合である。認められるアラームの種類に基づいて、あるアラームデータが、中央認証局３０にパスされる。加えて、他のデータも、スマートアラームシステム３４から構成サービス３８またはデータベースサーバにパスすることができる。次に、データのフローが双方向であるように、クエリ２３０またはデータフィードが、データベース５０またはスマートアラームシステム３４から発生することができる。アラーム限界値がユーザによって変更される時を示す、構成サービス３８と、スマートアラームシステム３４との間のデータフローもまた、双方向である。
【００４５】
一実施形態では、システムは１つ以上のデバイスを含有する、ルートノードを含む。典型的には、ＸＭＬ文書は、反転ツリー構造を有する。ＸＭＬに関して、ルートノードは、他の子ノードが依存する、所与の文書のトップレベル（または、ツリーディレクトリのトップ）を示す。故に、一実施形態では、ルートノード情報は、システム上で生成された各メッセージの開始および終了をマークする。ルートノード情報の非限定的実施例は、以下のようである。
【００４６】
【数１】
ルートノード後、特定の医療デバイスまたは要素ｃｐｃに関連する具体的情報が、以下のように提供される。
【００４７】
【数２】
ＸＭＬ文書を下に続けると、特定の医療デバイスの属性に関連する具体的情報が、以下のように提供される。
【００４８】
【数３】
上記のように、属性情報（ＡＴＴＬＩＳＴｃｐｃ）は、メッセージ、システムにメッセージ発行元を識別する識別子（ｂｉｄ）、接続の種類（例えば、発行元）、およびメッセージの日時を生成したデバイス要素（例えば、医療デバイス）の記述（種類）を含むことができる。メッセージは、メッセージを生成したデバイス要素に関するさらなる情報を含有する。
【００４９】
デバイス要素情報の非限定的実施例は、以下のようである。
【００５０】
【数４】
システムにメッセージ発行元を識別する識別子（ｂｉｄ）、メッセージを生成したデバイス要素の種類（ｔｙｐｅ）、ならびにデバイス要素のメーカ、モデル、およびバージョン等の情報を含むことができる。デバイス要素の状態、場所、アラーム、イベント、測定等に関する種々の情報もまた、メッセージ内に含むことができる。
【００５１】
故に、一実施形態では、例示的メッセージは、以下を表示する。
ルートノード：
【００５２】
【数５】
場所ノード：
【００５３】
【数６】
設定ノード：
【００５４】
【数７】
測定ノード：
【００５５】
【数８】
波形ノード：
【００５６】
【数９−１】
【００５７】
【数９−２】
アラームノード：
【００５８】
【数１０】
本明細書に説明されるものの変形例、修正、および他の実装は、請求される発明の精神および範囲から逸脱することなく、当業者に想起されるであろう。故に、本発明は、前述の例示的説明によってではなく、代わりに、以下の請求項の精神および範囲によって定義される。
【技術分野】
【０００１】
（関連出願の相互参照）
本願は、米国仮特許出願第６１／２５０，９４７号（２００９年１０月１３日出願）の優先権を主張し、この出願の開示は、その全体が本明細書に参照によって援用される。
【背景技術】
【０００２】
（発明の分野）
本発明は、概して、医療デバイスの分野に関し、より具体的には、中央の場所における医療デバイスからの患者データを変換および表示する分野に関する。
【発明の概要】
【課題を解決するための手段】
【０００３】
本発明は、一側面では、複数の非同種の環境医療デバイスからのデータの表示を提供するためのシステムに関する。一実施形態ではシステムは、データを第２のプロトコルに変換するためのローカル認証局と、ローカル認証局と通信する中央認証局と、中央認証局と通信するユーザインターフェースとを含む。中央認証局は、ユーザインターフェースによる表示のために、第２のプロトコルに変換されたデータをルーティングする。
【０００４】
別の実施形態では、第１のプロトコルは、ネイティブデバイスプロトコルであり、第２のプロトコルは、同種のシステムプロトコルである。一実施形態では、同種のシステムプロトコルは、ＸＭＬである。さらに別の実施形態では、第１のプロトコルは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）であって、第２のプロトコルは、本明細書では、ＸＭＬ、ＣＰＣ ＸＭＬ、またはＴＣＰ／ＣＰＣ ＸＭＬと称される、別のプロトコルとＴＣＰの組み合わせである。
【０００５】
別の実施形態では、システムはさらに、ローカル認証局と中央認証局との間で通信するスマートアラームモジュールを含む。スマートアラームモジュールは、医療デバイスからのデータが、アラームをトリガするための所定の基準を満たすか否かを決定する。さらに別の実施形態では、システムはさらに、スマートアラームモジュールと通信するデータベースを含む。なおもさらなる別の実施形態では、システムはさらに、中央認証局およびデータベースと通信するデータベースインターフェースを含む。
【０００６】
一実施形態では、システムはさらに、データベースとウェブインターフェースとの間で通信するインターネット情報サーバを含む。別の実施形態では、システムはさらに、データベース、スマートアラームモジュール、およびユーザインターフェースと通信する構成サービスを含む。さらに別の実施形態ではシステムはさらに、ローカル認証局と医療デバイスとの間で通信するデマルチプレクサを含む。なおもさらなる別の実施形態では、ローカル認証局は、中央認証局の近傍に物理的に位置する一方、別の実施形態では、ローカル認証局は、医療デバイスの近傍に物理的に位置する。
【０００７】
本発明の別の側面は、複数の非同種の環境医療デバイスからのデータの表示を提供するための方法である。一実施形態では、方法は、ローカル認証局によって、医療デバイスから、第１のプロトコルを使用して、データを受信するステップと、ローカル認証局によって、データを第２のプロトコルに変換するステップと、ローカル認証局によって、第２のプロトコルにおいて、データを中央認証局に伝送するステップと、中央認証局によって、第２のプロトコルにおいて、データをユーザインターフェースに伝送するステップと、ユーザインターフェースによって、データを表示するステップとを含む。
【０００８】
別の実施形態では、方法はさらに、スマートアラームモジュールによって、医療デバイスからのデータが、アラームをトリガするための所定の基準を満たすか否かを決定するステップを含む。さらに別の実施形態では、方法はさらに、ローカル認証局による第２のプロトコルへのデータの変換に先立って、医療デバイスからのデータを逆多重化するステップを含む。
【０００９】
本願は、２００４年１１月８日出願の米国特許出願第１０／９８４，１８６号および２００１年２月２３日出願の米国特許第６，８３９，７５３号の開示をその全体として組み込む。
【００１０】
本発明は、添付の請求項における特殊性によって注目される。前述の本発明の利点は、さらなる利点とともに、以下の説明と関連して検討される付随の図面を参照することによって、より理解される。図面中、同一参照文字は、概して、異なる図を通して、同一部品を指す。図面は、必ずしも、正確な縮尺ではなく、代わりに、概して、本発明の原理を例示するために強調される。
【図面の簡単な説明】
【００１１】
【図１】図１は、本発明のシステムの実施形態のブロック図である。
【図２】図２は、着目補足情報とともに、種々の患者アイコンの図の実施形態を示す。
【図３】図３は、スマートアラームを設定するためにアクセスされる、別のユーザインターフェース画面の実施形態を示す。
【図４】図４は、各患者のために設定されるスマートアラームを列挙する、概要画面の実施形態を示す。
【図５】図５は、本発明の医療デバイス監視システムに対する種々の管理機能を行うために好適なグラフィックユーザインターフェースの実施形態のスクリーンショットである。
【図６】図６は、複数のベッドを同時に監視するための画面のスクリーンショットである。
【図７】図７は、別の監視画面のスクリーンショットである。
【図８】図８は、ログ画面の実施形態を図示する。
【図９】図９は、経時的な種々の患者傾向を示すためのユーザインターフェースの実施形態を図示する。
【図１０】図１０Ａは、本発明のある実施形態による、ローカル認証局サーバに関する付加的な詳細によってシステムを図示する。図１０Ｂは、本発明のある実施形態による、ローカル認証局サーバに関する付加的な詳細によってシステムを図示する。
【図１１】図１１は、本発明の別のシステム実施形態のブロック図を図示する。
【発明を実施するための形態】
【００１２】
図および本願中におけるＣＰＣ ＸＭＬまたはＴＣＰ／ＣＰＣ ＸＭＬの参照は、ＸＭＬならびに医療デバイスおよび医療デバイスデータに関連する情報を含有するＸＭＬの広範囲の使用を包含する。したがって、一実施形態では、ＣＰＣ ＸＭＬは、ＸＭＬ、または医療デバイスまたは患者情報を伝送する、あるいは含む、もしくは別様に患者監視システムと協働するように修正されるＸＭＬを指す。同様に、一実施形態では、ＴＣＰ／ＣＰＣ ＸＭＬは、ＴＣＰまたはＸＭＬ、ならびに医療デバイスまたは患者情報を伝送する、あるいは含む、もしくは別様に患者監視システムと協働するように修正されるＴＣＰおよびＸＭＬを指す。
【００１３】
概要として、図１を参照すると、一実施形態では、異種の医療デバイス１０、１０’、１０’’、１０’’’（概して、１０）は、複数の方法において、本発明のシステムに接続される。医療デバイス１０は、典型的には、それぞれ、患者データ等のデバイス特有のデータのためのシリアル出力２２、２２’を有する。一般に、医療デバイスおよびシステムは、患者を監視し、患者データを収集し、改良された医療治療および患者の安全性をもたらすように変換および処理される。一実施形態では、その独自のネイティブデバイスプロトコルを伴う、種々の種類の医療デバイスを使用することができる。さらに、一実施形態では、本明細書で使用されるように、用語「医療デバイス」は、患者データを収集し、患者安全性を補助するために使用される、または別様に、１人以上の患者の医療治療あるいは診断を促進するために使用される任意のデバイスを含むことができるが、それらに限定されない。一実施形態では、医療デバイスのネイティブプロトコルは、種々の異種の医療デバイス１０と通信するか、または別様に、データを交換するために、システムによって使用される同種のプロトコルに翻訳、変換、あるいは再マッピングされる。
【００１４】
別の実施形態では、医療デバイス１０’’’は、中央認証局３０（後述される）を介して、システムに接続する。代替として、医療デバイス１０’はまた、ゲートウェイ１８を使用して、ローカル認証局に接続することができる。なおも別の実施形態では、医療デバイス１０’’は、スマートアラームモジュール３４（後述される）を介して、システムに接続する。
【００１５】
示される一実施形態では、医療デバイス１０のシリアル出力ポート２２は、医療デバイス１０のシリアル出力をインターネット伝送制御プロトコル（ＴＣＰ／ＩＰ）等のネットワークを介して使用するために好適なプロトコルに変更する、ネットワークデバイス１４に接続される。別の実施形態では、医療デバイス１０’のシリアル出力ポート２２’は、ゲートウェイ１８に接続される。ゲートウェイ１８は、いくつかの医療デバイス１０’をゲートウェイ１８に接続させ、デバイス１０’のそれぞれからのデータをＴＣＰ／ＩＰまたはユーザデータグラムプロトコル（ＵＤＰ）を使用するネットワークを介した伝送に好適な単一データストリームに多重化することによって、データ接続を形成する。
【００１６】
第３の実施形態では、医療デバイスは、スマートアラーム３４を介してシステムに接続される１０’’である。別の実施形態では、医療デバイス１０’’’は、中央認証局３０を介して、システムに接続される。
【００１７】
医療デバイス１０が、ネットワークデバイス１４に接続される実施形態では、データが、ネットワークデバイスから到着すると、ＴＣＰ／ＩＰパケットは、ローカル認証局２６によって、直接受信される。第２の実施形態では、データが、ゲートウェイ１８から到着する場合、データは、ローカル認証局２６への送信に先立って、デマルチプレクサ３０を通してパスされる。デマルチプレクサ３１またはｄｅｍｕｘは、各デバイス１０’のために、ＴＣＰ／ＩＰあるいはＵＤＰパケットを別個のＴＣＰ／ＩＰパケットに分離する。一実施形態では、代替通信チャネル１９は、ゲートウェイ１８およびローカル認証局２６が、デマルチプレクサ３１無しで、データを交換するように存在する。
【００１８】
次いで、実施形態に応じて、ローカル認証局２６は、データを中央認証局３０またはスマートアラームモジュール３４のいずれかに送信する。データが、ローカル認証局２６から中央認証局３０に直接送信される場合、通信は、一実施形態では、ＴＣＰ／ＩＰプロトコルを利用する。データが、ローカル認証局２６によって、スマートアラームモジュール３４に送信される場合、メッセージが、ＴＣＰ／ＩＰ、ＸＭＬ、ＴＣＰ／ＣＰＣ ＸＭＬプロトコル等の同種のシステムプロトコル、または別の好適なプロトコルを使用して、送信される。一実施形態では、ＣＰＣ ＸＭＬプロトコルが、種々の利点を提供するために、使用される。
【００１９】
従来のＴＣＰプロトコルと組み合わせて、ＸＭＬベースのプロトコルを使用する有利な理由の１つは、一実施形態では、医療デバイス監視システムが、ＴＣＰ／ＩＰソケットを使用して、ある医療デバイスデータを伝送することである。本医療デバイスデータは、監視システムに接続された医療デバイスの状態を記述する。対照的に、一例示的実装では、ＸＭＬ文書は、クライアントブリッジ（イーサネット（登録商標）コンバータに直列である）、システム全体のサーバによって、または医療デバイス自体から直接、生成される。データを生成し、伝送する、任意の構成要素またはデバイス（医療デバイス、サーバ、ブリッジ等）は、システムによって、発行元であると決定される。ＴＣＰ／ＩＰソケットは、ＸＭＬ文書と組み合わせて使用されるため、２つのプロトコルシステムは、全体的監視システムにルーティングされるデータを管理するために使用される。発行元に関する付加的詳細および説明は、図１０Ｂの議論で後述される。
【００２０】
構成要素またはデバイスが、１つ以上の医療デバイスからデータを収集する関連責任を伴う発行元として扱われる時、そのような発行元は、ローカル認証局２６として知られる。ローカル認証局は、図１０Ｂに示されるように、デバイスデータを関係のあるデータ利用者に情報を配信する責任を負うシステムに提供する。
【００２１】
一実施形態では、ローカル認証局２６は、中央認証局３０と同一場所に物理的に位置する。他の実施形態では、ローカル認証局２６および任意のデマルチプレクサ３０は、医療デバイス１０’の近傍に物理的に位置する、またはゲートウェイ１８自体の一部であってもよい。一般に、図に示されるトポロジ、および種々のモジュール、インターフェース、サブシステム、システム等は、所与の患者監視シナリオのために、必要に応じて、機能または場所毎に、結合または分離することができる。一実施形態では、システムの異なる要素は、異なる場所に位置することができる。例えば、図１に示されるように、いくつかの実施形態では、システムの異なる要素は、分離され、異なる物理的場所に位置することができる。一実施形態では、システムは、示されるように、異なる物理的場所ＡおよびＢにおいて、構成要素に分離される。
【００２２】
スマートアラームモジュール３４は、医療デバイスからのデータ１０、１０’が、臨床医によって設定された値から逸脱すると、付加的アラームを発生するために使用される。このように、臨床医は、例えば、医療デバイス１０、１０’自体から直接利用不可能である、パラメータの変更率に基づいて、アラームを設定してもよい。例えば、スマートアラームモジュール３４によって発生されるアラームは、同種のシステムプロトコルを使用して、中央認証局３０に送信される。スマートアラーム設定値を定義する値は、ＴＣＰ／ＩＰプロトコル、別のプロトコル、または同種のシステムプロトコルを使用して、構成サービス３８によって、スマートアラームモジュール３４に書き込まれる。
【００２３】
中央認証局３０によって、ローカル認証局２６またはスマートアラーム３４のいずれかから受信したデータは、同種のシステムプロトコルを使用して、ユーザインターフェース４２に伝送される。中央認証局３０はまた、ＴＣＰ／ＣＰＣ ＸＭＬメッセージ等の同種のシステムプロトコルに基づいて、メッセージをデータベースインターフェース４６に伝送する。データベースインターフェース４６は、データベース５０内に記憶するために、同種のデータをアクティブＸデータオブジェクト（ＡＤＯ）に変換する。このように、システムによって受信されたイベントは、スマートアラームを含め、ログをとることができる。
【００２４】
ユーザインターフェース４２は、ＴＣＰ／ＣＰＣ ＸＭＬプロトコル等の同種のシステムプロトコルを使用して、構成サーバ３８にデータを書き込む。次に、データは、ＡＤＯを使用して、構成サーバによって、データベース５０に書き込まれる。データベース５０はまた、管理ツールＨＬ７ＡＤＴによって書き込まれ、これは次に、ＴＣＰを使用して、構成サーバ３８によって書き込まれる。管理ツールは、患者情報を更新するために使用される。管理ツールＨＬ７ＡＤＴはまた、例えば、病院または他の医療供給者（または、その下位単位）における、患者電子医療記録（ＥＭＲ）ならびに患者入院、退院、および転院記録（ＡＤＴ）から情報を受信し、そこにデータを伝送する。
【００２５】
最後に、ウェブインターフェース５８は、システムへのブラウザアクセスを可能にする。一実施形態では、アクセスは、ＨＴＴＰセキュアプロトコルを使用して付与される。ウェブインターフェース５８は、ＡＤＯを使用して、データを読み、データベース５０にデータを書き込むために、インターネット情報サービス６２を使用する。
【００２６】
モジュールのそれぞれを個々に検討すると、スマートアラームモジュール３４は、ローカル認証局２６から受信することによってデータをレビューする。患者と関連付けられたデータは、データベース内に記憶されるように、種々のパラメータのためのアラーム設定と比較される。アラームがトリガされると、アラームは、ユーザインターフェース４２を介して、複数のユーザ画面上に表示される。
【００２７】
いくつかの実施形態では、データベースをバイパスすることは、種々の速度およびデータ処理利点を提供する。データストリームを分割し、それを復元することによって、システムが拡大縮小する。その結果、システムは、他のデバイス（サーバ、プロセッサ、ルータ、ハブ等）に作業を分担することができる。例えば、ＸＭＬパケットが到着すると、システムは、それを複製し、リダイレクトし、２つの異なるストリームまたはチャネルを介して送信することができる。これは、それらの２つの分割されたストリームと関連付けされる任意の処理または送達負荷を分割する。本明細書に説明される、ルーティングおよびデータ送達の一部として、各データストリームは、さらに処理を分配し、負荷を移動させるために、継続的に複製し、反復的に分割することができる。一実施形態では、これを行う関連コストは、データストリームを分割するために使用される時間である。本時間周期は、典型的には、患者安全性の維持と関連付けられた計器感度およびタイミングニーズに対して、十分に短時間に制御される。
【００２８】
同種のシステムプロトコルの一実施例は、ＸＭＬである。ＸＭＬは、十分に開発された標準的デベロッパツールを有する。加えて、ＸＭＬは、利点を有する。例えば、フレキシブルデータパケットは、システムの処理／受信側における不必要な複雑性を伴うことなく、種々の異なるデバイスからの入力を取り扱うことができるように生成することができる。一実施形態では、波形全体をＸＭＬパケット内にエンコードすることができる。ＸＭＬシーケンスは、拡大し、ＴＣＰ／ＩＰパケットの最大ペイロードサイズに到達すると、複数のＴＣＰ／ＩＰパケットにわたって分割することができる。
【００２９】
ＴＣＰ／ＩＰおよびＸＭＬは、２つの異なるネットワーク層で使用される。ＸＭＬは、パケット搬送データである。ＴＣＰ／ＩＰ層は、パケットが進む回線としての役割を果たす。ＴＣＰ／ＩＰは、肯定応答およびシーケンス番号の両方を提供し、保証された送達を提供するように機能する。
【００３０】
図２は、着目する補足情報を伴う種々の患者データの表示の画面ビューを示している。さらに、このスクリーンショットでは、アラーム８０がトリガされて示されている。実施例では、この患者の酸素レベルは、設定限界値を下回っている。その結果、臨床医が、アラームと関連付けられた患者または医療デバイスを確認することができるように電話がかけられる。
【００３１】
図３では、本明細書に説明されるシステムおよび方法によって監視される種々の患者のそれぞれに対して、スマートアラームを設定するための具体的詳細および種々のパラメータが示される。
【００３２】
このディスプレイにおいて、種々の患者パラメータのための上限および下限値は、臨床医によって設定することができる。加えて、所与の時間周期内に生じ得る連続アラームの数を付加的安全性特徴として設定することができる。最後に、画面はまた、所与のパラメータのための正常範囲も示す。図４では、システムのユーザは、患者毎に設定されるすべてのスマートアラームを視認することができる。この表示では、各スマートアラームは、設定時間、その値、その限界値、および任意のコンテキストメッセージとともに、別個に列挙される。ナースコールインジケータは、スマートアラームが生じたことを示し、患者および部屋番号を列挙する。
【００３３】
ユーザインターフェース４２は、システムにデータを入力し、そこから情報を読み出すために、臨床医または他のユーザによって使用される。図５は、本明細書に説明される医療デバイス監視システムに対して、種々の管理機能を行うために好適なグラフィックユーザインターフェースのスクリーンショットである。一実施形態では、図５のスクリーンショットは、図１に示されるウェブインターフェース５８またはユーザインターフェース４２と関連付けられる。示されるように、インターフェースは、ユーザにあるタスクを行わせる、種々のマウスクリック可能な要素を含む。これらのタスクは、新しい患者の入院、全体的監視システムへの新しい医療デバイスの追加、医療デバイス（Ｄ／Ｃ）の廃棄、患者間の医療デバイスの交換、患者データの編集、患者の転院、患者監視スタッフへのポケベルの割当、スマートアラームの更新および設定、ならびに種々のインターフェース画面の全体的ビューの調節を含むが、それらに限定されない。概して、インターフェース実施形態のうちのいくつかにおいて使用されるように、ベッドまたは部屋識別子は、患者およびデバイスにリンクされて示される。加えて、アラートのうちの１つ以上もまた、示される。一実施形態では、用語「アラート」および「アラーム」は、互換可能に使用され、いずれかの用語の最も広範な合理的意味を包含する。別の実施形態では、アラームは、所与の患者または他の着目医療パラメータのための特定の閾値の個別の監視である。例えば、アラーム監視は、高心拍数であってもよい。一実施形態では、アラートは、多くの場合、状況的である。アラームは、多くの場合、収集されたデータによって駆動される。一実施形態では、アラートは、受信患者データの処理に基づいて検出された根本問題に基づく、アラームのトリガに応答して表示される結果である。例えば、アラートは、心室頻拍の発症等、システムユーザに表示されるものであってもよい。電極の患者からの離脱は、アラートの原因の別の実施例である。
【００３４】
図６は、複数のベッドを監視する責任を負うユーザが、それらのすべてまたはそれらの下位集合を同時に見ることを可能にする概要画面を示す。図６に示されるように、個々のベッドアイコンは、クリック可能であって、拡張表示ビューを生成するか、または画面アラーム等のあるパラメータを設定するために選択することができる。
【００３５】
図７は、幾人かの患者を同時に監視する際に有用な別のモニタ画面である。スクリーンショット８５の右下部分の患者表示は、停止中の医療デバイスを示す。停止中の医療デバイスは、オフであって、データを送信していないデバイス、または故障状態にあるデバイスである。デバイススタンバイモードは、ネットワークリンクにわたって識別可能な「心拍インジケータ」を有するため、スタンバイモードは、典型的には、停止中モードと同一ではないが、いくつかのデバイス実施形態では、その可能性がある。加えて、他の６つのアクティブ患者監視ウィンドウは、リアルタイムまたは実質的にリアルタイムで、脈拍数または血中酸素濃度等の患者データを表示している。これらの６つのウィンドウはそれぞれ、マウスを使用して、臨床医または他の患者監視ユーザによって選択可能である。ウィンドウ８６のうちの１つをクリックすると、図７に示されるように、付加的詳細８７を伴う、ドロップダウンビューが表示される。
【００３６】
図８は、異なるネットワーク、患者、および医療デバイスイベントが、経時的に生じることに伴って、種々の着目情報を含むログ画面を図示する。これらのイベントを経時的に記録することによって、データは、システム故障の場合、または監視されている患者のうちの１人に対して、医療上の緊急事態が生じる場合、保存される。
【００３７】
図９は、経時的種々の患者傾向を示すためのユーザインターフェースである。種々の患者および着目パラメータを選択することによって、ネットワーク中継医療デバイスデータに基づいて、傾向またはパターンを示すように、プロットを生成することができる。一実施形態では、パラメータ、アラート等の優先順位が付けられたリストを示す、またはデータを監視システムに提供するデバイスの種類に基づいて、画面の設計を更新することが可能である。一実施形態では、経時的にパラメータのリストの優先順位を付けることによって、最も重要な測定が、監視画面のトップに来るが、経時的に変化してもよい。例えば、一ユーザインターフェース実施形態では、第１の重要測定と関連付けられた事象が存在しない場合、次の測定が、画面上のトップ位置にスライドアップする。これは、画面の専有面積を管理し、患者監視に責任を負うユーザに、優先情報に焦点を当てさせることに有用である。
【００３８】
一実施形態では、ワークフローおよび患者状態または患者に取り付けられたデバイスの種類を表示することができる。例えば、ワークフローは、施設の種類に基づいて、変更することができる。人工呼吸器施設は、循環器病棟とは対照的に、異なるアラームまたはアラームの異なる組み合わせを要求してもよい。すべての呼吸パラメータは、最初に、呼吸器科病棟において、表示される。反対に、心臓パラメータは、最初に、循環器病棟において、表示される。
【００３９】
一実施形態では、データを表示するための階層が使用される。患者の状態、健康、診断、病棟の種類、場所等に基づいて、情報はすべて、患者または医療デバイスパラメータの画面表示上で調節するために使用することができる。一実施形態では、システムは、履歴情報、またはある患者パラメータが最大変化率を受ける程度に基づいて、情報がどのように表示されるかに関して、自動プログラムすることができる。したがって、医療デバイスを使用して、所与の患者から収集された血圧が、降下し続ける場合、システムは、ユーザインターフェースの一部として、血圧がどのように表示されるかを変更することができる。例えば、画面システム上のアイテムのリスト内に、リスト上でより高い血圧を掲げ、したがって、患者に発症している問題の指標としの最も重要な画面要素として、強調することができる。患者に絶えず問題がある、またはパラメータ値が絶えず閾値を超過する場合、スマートシステムを使用して、より頻繁に生じる閾値超過に注意を向けることは、いくつかの利点をもたらす。一実施形態では、本明細書に説明されるシステムは、病院の情報システムおよびデータベースにデータを取り込み、ならびにそのようなシステムからの情報を使用して、システム自体によって使用されるデータベースにデータを取り込むことができる。
【００４０】
図１０Ａは、医療デバイスＡ、１１０は、ネイティブデバイス言語を使用して、ブリッジ１１２とデータを交換する、医療デバイスデータ交換システム１００を示す。次に、ブリッジ１１２は、第１のプロトコルであるプロトコルＸを使用して、ローカル認証局サーバ１１６とデータを交換する。別の実施形態では、デバイスネットワークＢ、１１８もまた、第２のプロトコルであるプロトコルＹを使用して、ローカル認証局サーバ１１６と通信する。本デバイスネットワークＢは、そのようなベッドのそれぞれにおける各患者と関連付けられた医療デバイスを伴う、複数のベッド等の複数の医療デバイスを有するネットワークを含んでもよい。ローカル認証局サーバ１１６は、本実施形態では、示されるように、それぞれ、プロトコルＸおよびプロトコルＹ等の異なるプロトコルを受信するように構成される、パーサＸ、１２０およびパーサＹ、１２２等の複数のパーサを含む。
【００４１】
一実施形態では、各それぞれのパーサは、関連ネイティブデバイスまたはネットワークプロトコルを共通の同種のシステムプロトコル１２３に変換する。医療デバイス１１０またはネットワーク１１８から受信した下層データは、同種のプロトコルを使用して、抽象デバイス１２５に通信される。抽象デバイス１２５の役割は、メモリ内に受信されることに伴ってデータパケットを表すことである。パケットデータは、抽象デバイス１２５から同種のプロトコル出力１３０に送信される（本実施例では、ＣＰＣ／ＸＭＬ出力として示される）。医療デバイスデータが変換されると、例えば、Ｂｅｒｎｏｕｌｌｉエンタープライズサーバ等のデータ監視または処理サーバ１３２に送信される。一実施形態では、医療デバイスデータは、ＣＰＣ／ＸＭＬ等のＸＭＬ形式で中継される。
【００４２】
図１０Ｂは、患者が監視されることに伴って、医療デバイスデータが生成される、全体的システムまたはプラットフォーム１５０を示す。一実施形態では、患者データを捕捉し、それをシステムの残りに中継するエンティティは、データ発行元と称される。下層患者データは、医療デバイス１１０Ａ、１１０Ｂ、および１１０Ｃ（概して、１１０）によって捕捉される。３つの医療デバイスが、例示として、図１０Ｂでは示されるが、システムは、任意の数の医療デバイスを含むことができることを理解されるであろう。前述のように、ＸＭＬを生成し、伝送する、任意の構成要素またはデバイス（医療デバイス、サーバ、ブリッジ等）は、システムによって、発行元として取り扱われる。ＴＣＰ／ＩＰソケットの両方が、ＸＭＬページと組み合わせて使用されるため、２つのプロトコルシステムは、全体的監視システムにルーティングされるデータを管理するために使用される。一実施形態では、医療デバイス１１０ａ−１１０ｃは、１つ以上の認証局に情報を伝送すると、発行元１５５として動作することができる。一実施形態では、医療デバイス１１０は、前述のように、ローカル認証局１６０および／または中央認証局１６３にデータを中継する。
【００４３】
図１０Ｂを継続して参照すると、いくつかの実施形態では、認証局（例えば、ローカル認証局１６０および中央認証局１６３）は、医療デバイスからのデータを受信することによって、利用者として、データを他のシステム構成要素に伝送することによって、発行元として、機能することができる。１つのローカル認証局および１つの中央認証局が、例示のために、図１０Ｂでは示されるが、システムは、任意の数のそのような認証局を含むことができることを理解されるであろう。一実施形態では、ローカル認証局１６０は、中央認証局１６３に情報を中継すると、発行元として機能する。一実施形態では、発行元は、関係のあるデータ利用者１７０に情報を配信する。一実施形態では、処理された医療デバイスデータを利用者１７０に送信する、この配信ハブは、中央認証局１６３である。利用者１７０として機能することができる、デバイスおよびインターフェースの非限定的実施例は、ポケベルサービス１６６、ＧＵＩアプリケーション１６１、およびデータベースインターフェース１６８を含む。
【００４４】
図１１は、スマートアラームシステムに関連する付加的詳細ならびに例示的接続およびデータフィードとともに、患者が監視されるときに、医療デバイスデータが生成される、全体的システムまたはプラットフォーム２００を示す。示されるように、スマートアラームシステムまたはサービス３４は、メッセージあるいは他のデータ要素の形式において、医療デバイスデータを受信（または、送信）する。スマートアラームシステムは、ＸＭＬ等の第１のプロトコルにエンコードされる受信医療デバイスデータを分析し、いくつかのスマートアラームの種類（逸脱、限界値、組み合わせ、または連続）のうちの１つか否か決定する。具体的には、逸脱アラームは、設定値からの患者値の逸脱によってトリガされるものである。限界値アラームは、指定範囲外に移動する患者値によってトリガされるものである。組み合わせアラームは、２つ以上の他のアラームの発生がアラームを生じさせるものである。例えば、血圧が、正常範囲外に降下し、心拍率が、正常範囲を超える場合、アラームがトリガされるであろう。連続アラームは、所与のアラームが設定回数を超えてトリガされる場合、トリガされるものである。例えば、３０秒の持続時間の少なくとも２回の酸素飽和度の低下が、２分以内に生じる場合である。認められるアラームの種類に基づいて、あるアラームデータが、中央認証局３０にパスされる。加えて、他のデータも、スマートアラームシステム３４から構成サービス３８またはデータベースサーバにパスすることができる。次に、データのフローが双方向であるように、クエリ２３０またはデータフィードが、データベース５０またはスマートアラームシステム３４から発生することができる。アラーム限界値がユーザによって変更される時を示す、構成サービス３８と、スマートアラームシステム３４との間のデータフローもまた、双方向である。
【００４５】
一実施形態では、システムは１つ以上のデバイスを含有する、ルートノードを含む。典型的には、ＸＭＬ文書は、反転ツリー構造を有する。ＸＭＬに関して、ルートノードは、他の子ノードが依存する、所与の文書のトップレベル（または、ツリーディレクトリのトップ）を示す。故に、一実施形態では、ルートノード情報は、システム上で生成された各メッセージの開始および終了をマークする。ルートノード情報の非限定的実施例は、以下のようである。
【００４６】
【数１】
ルートノード後、特定の医療デバイスまたは要素ｃｐｃに関連する具体的情報が、以下のように提供される。
【００４７】
【数２】
ＸＭＬ文書を下に続けると、特定の医療デバイスの属性に関連する具体的情報が、以下のように提供される。
【００４８】
【数３】
上記のように、属性情報（ＡＴＴＬＩＳＴｃｐｃ）は、メッセージ、システムにメッセージ発行元を識別する識別子（ｂｉｄ）、接続の種類（例えば、発行元）、およびメッセージの日時を生成したデバイス要素（例えば、医療デバイス）の記述（種類）を含むことができる。メッセージは、メッセージを生成したデバイス要素に関するさらなる情報を含有する。
【００４９】
デバイス要素情報の非限定的実施例は、以下のようである。
【００５０】
【数４】
システムにメッセージ発行元を識別する識別子（ｂｉｄ）、メッセージを生成したデバイス要素の種類（ｔｙｐｅ）、ならびにデバイス要素のメーカ、モデル、およびバージョン等の情報を含むことができる。デバイス要素の状態、場所、アラーム、イベント、測定等に関する種々の情報もまた、メッセージ内に含むことができる。
【００５１】
故に、一実施形態では、例示的メッセージは、以下を表示する。
ルートノード：
【００５２】
【数５】
場所ノード：
【００５３】
【数６】
設定ノード：
【００５４】
【数７】
測定ノード：
【００５５】
【数８】
波形ノード：
【００５６】
【数９−１】
【００５７】
【数９−２】
アラームノード：
【００５８】
【数１０】
本明細書に説明されるものの変形例、修正、および他の実装は、請求される発明の精神および範囲から逸脱することなく、当業者に想起されるであろう。故に、本発明は、前述の例示的説明によってではなく、代わりに、以下の請求項の精神および範囲によって定義される。
【特許請求の範囲】
【請求項１】
複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステムであって、該システムは、
該複数の異種の医療デバイスと通信する中央認証局サブシステムと、
該中央認証局サブシステムと通信するユーザインターフェースと、
該中央認証局サブシステムと通信するデータベースサブシステムと、
を備え、該中央認証局サブシステムは、実質的に同時に、該ユーザインターフェースによって表示し、および該データベースサブシステムによって記憶するために、該複数の異種の医療デバイスからの該データを伝送する、システム。
【請求項２】
前記複数の医療デバイスと前記中央認証局との間で通信するローカル認証局サブシステムをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項３】
前記ローカル認証局は、前記複数の異種の医療デバイスからの前記データを第１のプロトコルから第２のプロトコルに変換する、請求項２に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項４】
前記第１のプロトコルは、ネイティブデバイスプロトコルであり、前記第２のプロトコルは、同種のシステムプロトコルである、請求項３に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項５】
同種のシステムプロトコルは、ＸＭＬである、請求項３に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項６】
前記中央認証局は、コンピュータ上に常駐し、前記データを前記データベースと前記ユーザインターフェースとに並行して伝送するように設計される、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項７】
前記中央認証局と電気的に通信するスマートアラームモジュールをさらに備え、該スマートアラームモジュールは、前記複数の異種の医療デバイスのうちの１つの医療デバイスからの前記データが、アラームをトリガするための所定の基準を満たすか否かを決定する、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項８】
前記スマートアラームモジュールはまた、前記データベースおよび構成サービスモジュールと電気的に通信する、請求項７に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項９】
前記中央認証局サブシステムおよび前記データベースと電気的に通信するデータベースインターフェースをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１０】
前記データベースおよびウェブインターフェースの両方と電気的に通信するネットワークサーバをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１１】
前記構成サービスモジュールは、前記ユーザインターフェースと電気的に通信する、請求項７に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１２】
前記ローカル認証局サブシステムおよび前記複数の異種の医療デバイスの両方と電気的に通信するデマルチプレクサをさらに備える、請求項２に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１３】
前記ローカル認証局サブシステムは、前記中央認証局サブシステムの近傍に物理的に位置する、請求項２に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１４】
前記中央認証局サブシステムと前記複数の異種の医療デバイスとの間で電気的に通信するスマートアラームモジュールをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１５】
複数の異種の医療デバイスからのデータの表示を提供する方法であって、該方法は、
中央認証局サブシステムによって、該医療デバイスからのデータを受信するステップと、
該中央認証局サブシステムによって、実質的に同時に、ユーザインターフェースとデータベースとの両方に該データを伝送するステップと、
該ユーザインターフェースによって、該データを表示するステップと
を含む、方法。
【請求項１６】
請求項１５に記載の複数の異種の医療デバイスからのデータの表示を提供する方法であって、該方法は、
スマートアラームモジュールによって、該複数の医療デバイスのうちの１つの医療デバイスからの該データが、アラームをトリガするための所定の基準を満たすか否かを決定するステップをさらに備える、方法。
【請求項１７】
請求項１５に記載の複数の異種の医療デバイスからのデータの表示を提供する方法であって、該方法は、
該複数の医療デバイスからのデータを逆多重化するステップと、
前記中央認証局サブシステムによる該データの受信に先立って、ローカル認証局サブシステムによって第１のプロトコルから第２のプロトコルに該データを変換するステップと、
をさらに含む、方法。
【請求項１８】
請求項１５に記載の複数の異種の医療デバイスからのデータの表示を提供する方法であって、前記中央認証局は、コンピュータ上に常駐し、および該データを該データベースと前記ユーザインターフェースとに並行して伝送するように設計されることにより、データベースアクセスが遅延または回避されて、ユーザへのデータ送達の速度を改善する、方法。
【請求項１】
複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステムであって、該システムは、
該複数の異種の医療デバイスと通信する中央認証局サブシステムと、
該中央認証局サブシステムと通信するユーザインターフェースと、
該中央認証局サブシステムと通信するデータベースサブシステムと、
を備え、該中央認証局サブシステムは、実質的に同時に、該ユーザインターフェースによって表示し、および該データベースサブシステムによって記憶するために、該複数の異種の医療デバイスからの該データを伝送する、システム。
【請求項２】
前記複数の医療デバイスと前記中央認証局との間で通信するローカル認証局サブシステムをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項３】
前記ローカル認証局は、前記複数の異種の医療デバイスからの前記データを第１のプロトコルから第２のプロトコルに変換する、請求項２に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項４】
前記第１のプロトコルは、ネイティブデバイスプロトコルであり、前記第２のプロトコルは、同種のシステムプロトコルである、請求項３に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項５】
同種のシステムプロトコルは、ＸＭＬである、請求項３に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項６】
前記中央認証局は、コンピュータ上に常駐し、前記データを前記データベースと前記ユーザインターフェースとに並行して伝送するように設計される、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項７】
前記中央認証局と電気的に通信するスマートアラームモジュールをさらに備え、該スマートアラームモジュールは、前記複数の異種の医療デバイスのうちの１つの医療デバイスからの前記データが、アラームをトリガするための所定の基準を満たすか否かを決定する、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項８】
前記スマートアラームモジュールはまた、前記データベースおよび構成サービスモジュールと電気的に通信する、請求項７に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項９】
前記中央認証局サブシステムおよび前記データベースと電気的に通信するデータベースインターフェースをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１０】
前記データベースおよびウェブインターフェースの両方と電気的に通信するネットワークサーバをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１１】
前記構成サービスモジュールは、前記ユーザインターフェースと電気的に通信する、請求項７に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１２】
前記ローカル認証局サブシステムおよび前記複数の異種の医療デバイスの両方と電気的に通信するデマルチプレクサをさらに備える、請求項２に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１３】
前記ローカル認証局サブシステムは、前記中央認証局サブシステムの近傍に物理的に位置する、請求項２に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１４】
前記中央認証局サブシステムと前記複数の異種の医療デバイスとの間で電気的に通信するスマートアラームモジュールをさらに備える、請求項１に記載の複数の異種の医療デバイスからのデータの表示を提供するプロセッサベースのシステム。
【請求項１５】
複数の異種の医療デバイスからのデータの表示を提供する方法であって、該方法は、
中央認証局サブシステムによって、該医療デバイスからのデータを受信するステップと、
該中央認証局サブシステムによって、実質的に同時に、ユーザインターフェースとデータベースとの両方に該データを伝送するステップと、
該ユーザインターフェースによって、該データを表示するステップと
を含む、方法。
【請求項１６】
請求項１５に記載の複数の異種の医療デバイスからのデータの表示を提供する方法であって、該方法は、
スマートアラームモジュールによって、該複数の医療デバイスのうちの１つの医療デバイスからの該データが、アラームをトリガするための所定の基準を満たすか否かを決定するステップをさらに備える、方法。
【請求項１７】
請求項１５に記載の複数の異種の医療デバイスからのデータの表示を提供する方法であって、該方法は、
該複数の医療デバイスからのデータを逆多重化するステップと、
前記中央認証局サブシステムによる該データの受信に先立って、ローカル認証局サブシステムによって第１のプロトコルから第２のプロトコルに該データを変換するステップと、
をさらに含む、方法。
【請求項１８】
請求項１５に記載の複数の異種の医療デバイスからのデータの表示を提供する方法であって、前記中央認証局は、コンピュータ上に常駐し、および該データを該データベースと前記ユーザインターフェースとに並行して伝送するように設計されることにより、データベースアクセスが遅延または回避されて、ユーザへのデータ送達の速度を改善する、方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１３−５０７２２８（Ｐ２０１３−５０７２２８Ａ）
【公表日】平成２５年３月４日（２０１３．３．４）
【国際特許分類】
【出願番号】特願２０１２−５３４２７９（Ｐ２０１２−５３４２７９）
【出願日】平成２２年１０月１２日（２０１０．１０．１２）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０５２２７１
【国際公開番号】ＷＯ２０１１／０４６９０８
【国際公開日】平成２３年４月２１日（２０１１．４．２１）
【出願人】（５０３２６１９９３）カーディオパルモナリー コーポレイション (2)
【Ｆターム（参考）】
【公表日】平成２５年３月４日（２０１３．３．４）
【国際特許分類】
【出願日】平成２２年１０月１２日（２０１０．１０．１２）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０５２２７１
【国際公開番号】ＷＯ２０１１／０４６９０８
【国際公開日】平成２３年４月２１日（２０１１．４．２１）
【出願人】（５０３２６１９９３）カーディオパルモナリー コーポレイション (2)
【Ｆターム（参考）】
[ Back to top ]