JP2016502693A - 患者ケアを提供するためのシステム及び方法 - Google Patents

Abstract

患者ケアを提供するためのシステムは、携帯電話プラットフォームと、独自仕様ではないハードウェア及びソフトウェア・モジュールとを用いた、医療データの取得、集約、配布、記憶及び表示を含む。本システムは、検出機器と、取得機器と、ネットワーク・アプライアンスと、クラウド・コンピューティング及びストレージと、提示機器とを含む。検出機器は、有線又は無線接続により取得機器に接続される。検出取得機器は、ケア提供者設備及び外来診療環境で使用可能であり、携帯電話（３Ｇ／４Ｇ）ネットワークを介してクラウドに接続可能である。臨床データは、例えばＬｕａ等の標準スクリプト言語を用いてヘッダのみを符号化した暗号化メッセージにおいて、送信される。提示機器は、コンピュータ、タブレット、携帯電話及び壁掛け式ディスプレイを含み、何れの場所にも設置可能であり、ケア提供者が患者データに非常にアクセスしやすくなる。【選択図】図１Ａ

Description

本明細書は、医療システムに関する。特に、本明細書は、既存の携帯電話ネットワーク、クラウド・ベース・サービス、家庭用電子機器及び標準ネットワークへの接続による医療データの取得、集約、分析、配布、記憶及び表示を可能とする患者ケアを提供するための分散型患者モニタリング・システム及び方法に関する。

病院環境で通常用いられる患者ケアを提供するための標準的なシステムは、患者の医療データを取得、集約、配布、記憶及び表示するためのモジュールを含む。このようなモジュールは、多数のソフトウェア・プログラムを実行する種々のハードウェア部品からなり、通常、情報ネットワークにより接続される。現在利用できる患者ケアを提供するためのシステムは、独自仕様のハードウェアを使用することにより、選択肢の拡大を制限し、システムの使用を抑える。たいていの場合、システムは、システム実行要求に従って設計された特定のアプリケーション・ソフトウェアのみを許可する。更に、定期的なアップグレードやアップデートのため、病院環境は、多くの場合、システムで作動するハードウェア及びソフトウェアの双方について、複数のバージョンを有している。それゆえ、これらのシステムは、限られた範囲内でのみカスタマイズされる閉じられた箱のようになりがちである。技術が進歩するにつれ、病院は、既存のシステムに新しい機能を統合するといった高まる困難に直面する。一般的には、現場の情報技術（ＩＴ）スタッフが、手動によりアップグレード及びトラブルシューティングを実行することが要求される。

患者ケアを提供するための現在のシステムは、フォーマットとスキーマとプロトコルからなるメッセージの符号化とを厳密に定義しなければならない従来の通信プロトコルを利用するネットワークを含む。これらの定義は、システム内の情報の送信機と情報の受信機との間での規約を形成し、一般的に、厳密な「ビット・レベル」符号化、或いは、例えば拡張マークアップ言語（ＸＭＬ）等のより高レベルの符号化の何れかの形式をとる。「ビット・レベル」符号化は、メッセージ毎に全てのビット及びバイトのバイナリ・レベルでの正確なレイアウトを伴い、それゆえ、プロトコルにおいて全てのメッセージの正確なフォーマット及び内容を厳密に定義する。インターネットで使用されるＴＣＰ／ＩＰプロトコルは、「ビット・レベル」符号化の一例である。ＸＭＬ符号化は、プロトコル固有のスキーマを使用して、標準化フォーマット（ＸＭＬ）の上に必要なルールを重ね、メッセージのレイアウトを定義する。ハイパー・テキスト・マークアップ言語（ＨＴＭＬ）ウェブ・ページ標準は、ＸＭＬ符号化の一例である。

両方のタイプの符号化が、送信機と受信機とが同じプロトコルに合意することを要求する。ＸＭＬデータを待つ受信機は、送信機からのバイナリ・データを処理することができず、逆もまた同じである。したがって、プロトコルの変更及び強化が、送信機及び受信機が同時にアップデートされるロックステップ方式でなされなければならない。現在のシステムは、通常、広範囲に配置されているため、このような同時アップグレードは実現困難であり、プロトコルがごくわずかしか進化しない「膠着状態」をもたらすこととなる。

更に、標準プロトコルを介する情報の送信は、いくつかの変換ステップを伴う。送信機は、送信前にデータを符号化しなければならず、受信機は、データを復号化して復元しなければならない。頻繁にデータを符号化及び復号化すると、作業が複雑化し、作業コストを大幅に増大させることとなる。下層プロトコルに変更を加える場合、一般的に、符号化及び復号化の両方の段階の改訂が必要とされ、やはりコストの増大を招くこととなる。

代表的なネットワークにおける通信プロトコルには、接続型及び非接続型の２つの基本的な型式がある。接続型プロトコルは、接続する両者の間で、データ交換が行われる前に、応答確認の手続を必要とする。一方、非接続型プロトコルは、事前の設定や応答確認無しで、データ交換が可能である。

安全な通信は、一般的に、暗号化を用いて実施され、全ての現存する暗号化様式は、接続する両者に共有秘密鍵を、一般的に、メッセージの暗号化及び復号化を可能とする鍵の形式で持つことを要求する。鍵の共有には多くの技術が存在するが、接続の設定中に鍵を交換できるように、全て、接続型プロトコルの使用を伴う。更に、個々の接続は、それぞれ、独自の秘密鍵の組を特定しなければならない。このように、第１のエージェントが他の１００のエージェントと接続する場合、個々のやり取りは、それぞれ、個々の暗号化接続を伴い、第１のエージェントは、１００の同時接続及び関連する鍵の管理を要求される。そのように、多くのエージェントが他の多くのエージェントと通信をするシステムでは、接続の総数が急激に増加する。これにより、コストが増大し、システムが遅くなることとなる。

これを克服するために、多くのシステムが、エージェント間での接続の経路を決める（ルーティングする）単一のセントラル・「エクスチェンジ（交換機）」（central exchange）を利用している。この場合、各エージェントが共通のセントラル・エクスチェンジに接続しさえすれば良いので、接続の総数はエージェントの数に一致する。しかし、エクスチェンジが信頼できなければ、エージェントは、接続するエージェントの各組み合わせに対し、個々の暗号化鍵組を保持し続けなければならない。このように、エージェントは、交換鍵に「接続」し続けなければならない。

送信機と受信機との間で送信されたメッセージは、重要度及び優先度（プライオリティ）が異なり、些末なものから重大なものまで存在する。所定のメッセージの配信を保証することは、一般的に極めて困難或いは不可能であるため、多くの場合、メッセージの受信機がデータの送信者に受信した旨を知らせることが有益である。この受領証の生成には、ネットワークの帯域幅を消費する（受信されたメッセージ毎に少なくとも一つの新しいメッセージが受信機により生成される）ため、多くの場合、最も重要度の高いメッセージのために確保しておかれる。

メッセージの符号化と同様に、従来の通信プロトコルは、送信機と受信機との間で規約を形成するとともに、受信機が配信受領証を生成して送信する仕様を、厳格に定義されたルールに頼らなければならない。一般的に、プロトコルは、復号化されるべきフィールド又はシーケンスを特定し、受領メッセージが生成されるかどうかを決定する。追加のフィールドは、受領メッセージのフォーマットと送信者のネットワークアドレスとを定義する。従来のネットワークシステムが受領証の生成を効果的に保証するためには、メッセージ受信要求、フォーマット記述子及びアドレス指定が、全て互換性の有るフォーマットとなるように、ネットワーク上の全てのエージェントが、互換性の有るバージョンのプロトコルを実行しなければならない。

更に、従来のメッセージ受領証生成は、受領証明のフォーマットが受信機のソフトウェア・スタックにおいて符号化される機能性によって決定されるという点において、非常に制約が有る。特定の種類のメッセージを受信次第、一連の複雑な動作が求められる場合、各ネットワーク・エージェントのソフトウェア・スタックにおいて符号化されなければならない。

例えば、一種の重大なメッセージは、標準的な受領証（送信者に返信されるメッセージ）が生成されることのみならず、二次的なメッセージ受信通知が（全ての高優先度メッセージの受信を記録する）データ・ロギング・サーバへ送信されることをも要求する。従来のシステムでは、この動作は、追加のオプション・データ・フィールド（二次的な受信通知が、二次通知サーバのアドレスや、二次サーバが利用不可な場合の特別な動作等を有効化する）が実装のために使用されるように、メッセージ・プロトコルに組み込まれなければならない。これは、従来のプロトコルでの符号化が困難なメッセージ受信に対する複雑な応答である。この効果は、全てのメッセージのサイズが増え、プロトコルが漸進的に複雑化し、遅くなり、使用及び保持が困難になることである。

このようにプロトコルで符号化される新規の動作毎に、全てのネットワーク・エージェントにおけるネットワーク・ソフトウェア・スタックが、複雑度及びメモリ消費を増し、効率が悪くなる。更に、このような機能は、全てのネットワーク・エージェントが当該機能をサポートする互換性の有るバージョンのプロトコルを実行するまで、使用できない。

メッセージを送信する際、代表的なネットワークもまた、様々なプロトコルに頼って、データ・パケットに対する最適なルート（経路）を決定する。これらのプロトコルは、静的なコスト距離を用いて、エンドポイント間の最適なパス（経路）を決定する。大部分は、非負エッジ・パス・コスト・グラフの単一始点最短経路問題を解くグラフ検索アルゴリズムであるダイクストラ・アルゴリズムに基づいて、２つの頂点間の最短距離を決定する。各リンクには、特定の属性に基づきコストが割り当てられるが、これは、通常、利用可能な帯域幅である。

ルーティング・プロトコルであるオープン・ショーテスト・パス・ファースト（ＯＳＰＦ）は、ルート選択プロトコルの一般的な例である。他の属性が有効である一方、ＯＳＰＦは、通常、利用可能なネットワーク・リンク毎に１０^８／帯域幅のコストを割り当てるように構成される。１００Ｍｂｉｔ／ｓの帯域幅のリンクは、１のコストを有し、１０Ｍｂｉｔ／ｓのリンクは、１０のコストを有する。２つのネットワーク間のパスの選択に際し、ＯＳＰＦは、最も低コストのパスを選択する。

リンク層プロトコルであるスパニング・ツリー・プロトコル（ＳＴＰ）もまた、既定のコスト表を用いて、利用可能なインタフェース帯域幅に基づき、ネットワークに対する最適なパスを選択する。ＳＴＰでは、１０Ｍｂｉｔ／ｓには１００のコストが与えられる一方、１００Ｍｂｉｔ／ｓには１９のコストが与えられる。各パスにおける全てのリンクの和は、パス・コストの決定に用いられ、ネットワークでの通信において最も低コストのパスの選択に用いられる。

これらのプロトコルでは、パス・コストは、各インタフェースに対する交渉リンク速度に応じて決定される。しかし、実際の通信速度は、ネットワークの混雑、パケット損失及び待ち行列遅延により、リアル・タイムで影響を受け得る。これらのプロパティは動的に変化し、最適なパスが静的なコスト距離を用いて算出された場合、これらのプロパティは考慮されない。

代表的なネットワークは、様々なプロトコルを用いて、一又は複数の送信機から複数の他の受信機へ、データを送信する。一又は複数の送信者から同時に複数の受信者にデータを転送することは、マルチキャストと呼ばれる。プロトコル独立マルチキャスト（ＰＩＭ）は、自身のトポロジー（接続形態）発見機構を含まないものの他のプロトコルにより提供されるルーティング情報を用いる一群のプロトコルである。インターネット・グループ管理プロトコル（ＩＧＭＰ）は、マルチキャスト・グループのメンバーシップを確立するために、ネットワーク上でホスト及びルータにより使用される。ＩＧＭＰを用いて代表的なネットワーク上で動作する場合、機器は、ローミングしている時はいつでも、ホスト又はルータとの状態の再同期或いは接続の再確立を行わなければならない。ローミング中にルータ間における状態を維持するためには、複数の要求の間、システムがセッション情報或いは機器の状態を保持することが必要とされる。これにより、システムの速度が落ち、追加の記憶装置の必要性が増すこととなる。

代表的なネットワークにおいてメッセージを転送する送信機及び受信機の多くは、モバイル機器である。これらの機器は、多くの場合、データの転送に対し、電力量に制限が課される。これらは、通常、電池を電源としており、無線伝送（ブルートゥース、８０２．１１無線、３Ｇ、４Ｇ、ＬＴＥ等）が、利用可能な電力や電池の総エネルギーの大部分を用いることは、珍しくない。この問題は、医療モニタリング・システムの一部として用いられるモバイル機器でみられるように、機器が絶え間なくデータを送信する場合に、とりわけ深刻である。

送信機から重複したメッセージが送信される場合、モバイル・ネットワークにおいてマルチキャスト時に直面する別の問題が発生する。上記したように、無線（ＲＦ）通信を用いてメッセージを送信する場合、システムは、利用可能な帯域幅の量及びモバイル機器の電池残量により、転送可能なデータ量に制限を受ける。ＲＦ相互接続により多くの帯域幅が必要とされることは、システムの全コストが増大することと関係が有る。重複したメッセージの送信は、帯域幅をより多く消費するのみならず、モバイル機器において不必要な電池の消耗をもたらすこととなる。

危急を知らせる場合、従来の患者ケアを提供するためのシステムは、一般的に、患者につなげられた機器に真っ先にアラームをアナウンスする。患者につなげられた機器によって生成されるアラームは、多くの場合、例えばセントラル・ワークステーション等のリモートの（遠く離れた）物理的機器において、複製され、表示される。セントラル・ワークステーションは、一般的に、複数の患者の状態を見守る一人のケア提供者によって使用される大型ディスプレイである。更に、モバイル・アラーム機器は、ケア提供者が治療室を動き回る間、ケア提供者によって装着される。これらの機器は、アラームするような事象が患者の一人に発生した場合に、担当のケア提供者に通知することができる。

これらのアラームの手法は、全て、アラーム状態に対し、一般的に以下の１）〜４）のパスをたどるプログラムされた応答を提供する：１）患者につなげられた機器でアラームする；２）セントラル・ディスプレイ或いはリモート・ディスプレイでアラームする；３）ケア提供者にアラームを通知する；４）通知したケア提供者が応答しない場合、所定の段階的拡大に基づき、ケア提供者の応答が有るまで、別のケア提供者への通知を行う。従来のアラームの計画は、効率的である一方、患者又は最も近くにいるケア提供者の物理的位置を考慮しないため、アラームへの応答の遅れにつながり得る。

従来の患者ケア・システムを使用するケア提供者が直面する別の問題として、アラーム疲れがある。患者モニタがアラームを生成すべき状態を検出すると、例えば大音量で反復する可聴音や、機器又はディスプレイにおける点滅発光表示、アラームを表すテキスト・メッセージ等、ケア提供者に対する通知が生成されることとなる。ケア提供者は、勤務シフト中に多数の異なる患者に対する非常に多くのアラームに応答した後では、アラーム音に対して鈍感になるかもしれない。これにより、重要なアラームが無視される或いはケア提供者によって不適切に無効化されると、患者に悪影響をもたらすこととなり得る。既存の患者モニタリング・システムは、特定の状況において、ケア提供者がアラームを「黙らせる（silence）」ことを可能とすることによって、アラーム疲れを最小限に抑えようと試みる。アラームを黙らせることは、アラームを切ることではなく、代わりに、一般的に、ケア提供者が患者の世話をしている間、気が散らないように、アラーム音を一時的に切ることである。

「アラーム消音（alarm silence）」は、選択された期間、アラーム音を切って黙らせる形態である。（現在進行中のアラームに対する）「アラーム受信確認（alarm acknowledge）」は、アラーム状況の期間中、アラームの通知の強度を低減する。アラーム状態が解消すればいつでも、「アラーム受信確認」状態も解消し、同じタイプの新たなアラームが、全アラーム動作を再び引き起こすこととなる。例えば、心房細動（一般的には、生死にかかわるものではないが、長時間続くこともある）のようなアラーム状態に対し、アラーム受信確認動作を行うことにより、点滅の停止及びアラーム音の停止が可能となるが、パラメータ・ゾーンでは、ケア提供者がアラーム状態を確認したことを示すアイコンと共に、アラームが発生していることを示し続ける。この状態は、アラームがリセットされるまで、或いは、アラーム状態が解消されるまで、持続することとなる。患者が、心房細動から最低限の期間脱した後、再びその状態に戻った場合、心房細動に適した最大限のアラームが、再び開始することとなる。

（ラッチ・アラームに対する）「アラーム受信確認」は、もし発生したらケア提供者に通知しなければならないほど重要なアラーム状況に対するものである。ラッチ・アラームが発生すると、アラーム状態が存在しなくなった後も、アラームが観測されたことをケア提供者が「受信確認」するまで、患者モニタはアラームを継続する。ひとたび受信確認されると、アラーム状態が存在しなくなれば、アラームは切られることとなる。これらのアラーム消音計画は、効率的である一方、更に良く分散され、ケア提供者チーム・アプローチ向きとなるよう、改良の余地がある。

また、現在のシステムは、たいてい固定されており、ひとたび患者が病院環境から外に出ると、患者ケアの提供には使用できなくなってしまう。そのようなシステムでは、ひとたび患者が退院すると、まだ医学的配慮を必要とする場合でも、患者やそのケア提供者が医師や医療関係者につながる方法を提供できない。

したがって、必要とされるのは、独自仕様の技術の利用に限定されない患者ケアを提供するための柔軟性が有り且つ堅固なシステムである。新しいシステムは、ベース・モジュールの交換の必要が無く、数年間サポートを提供するに足る柔軟性を持つべきである。また、システムは、現場での技術的な専門知識をほとんど必要としないものであるべきである。このようなシステムは、サービス型ソフトウェア（ＳａａＳ）原理を用いて動作し、ケア提供者、患者及び家族は、クラウドに記憶されたプログラム及びデータにアクセスする。クラウドは、システムに必要なコンピューティング（演算）及びストレージ（記憶場所）を提供し、プログラムやデータをローカルに記憶するシック・クライアントから利用を遠ざける。クラウド・コンピューティングは、コストを低減し、システムの柔軟性を増大することとなる。

また、メッセージの符号化を、より効率的且つ費用効率性が高い方法で処理するシステムが、必要とされる。具体的には、必要とされるのは、符号化及び復号化の手順を簡略化するとともに、システムの構成要素を同時にアップグレードする必要が無くシステムの強化が可能な、柔軟性の有る符号化プロトコルである。そのような符号化プロトコルは、また、例えば配信受領プログラム等、メッセージ送信において実行可能なプログラムの包含をも簡略化することとなる。

更に、メッセージの交換に先立ち鍵或いは他の秘密鍵の取り決めの必要が無く、暗号化されたメッセージを二者間で送信する非接続型エクスチェンジの必要性が有る。必要とされるのは、ネットワークを介するメッセージの非接続型送信に対し、信頼できるセントラル・エクスチェンジである。

また、必要とされるのは、最速ルートの決定時に、例えば、混雑、パケット損失及び待ち行列遅延等のリアル・タイムのネットワーク使用を考慮するメッセージ・ルーティング・プロトコルである。

また、機器が、ルータとの再同期の必要が無く、ルータの動作状態を把握しないままローミングに入ることが可能であり、効率的なマルチキャストが可能なシステムが、必要とされている。そのようなシステムは、機器における電池の消耗を低減し、ネットワーク上の要求を少なくすることとなる。更に、メッセージの重複送信の発生を減らすことにより、帯域幅及びモバイル機器の電池消耗を最小限にするシステムが、必要とされる。

また、必要とされるのは、送信機での消費電力を最小限にするために、ネットワークにおけるメッセージのフロー（流れ）を制御する方法である。無線機器では、一般的に、一定バイト数のデータが単一ブロックのデータとして送信される方が、複数のより小さなブロックのデータとして送信されるよりも、より効率的である。したがって、必要とされるのは、複数のメッセージを、複数のより小さなメッセージとしてよりも、単一ブロックで共に送信する方法である。

患者及びケア提供者双方の位置及び存在情報に基づくアラーム・プライオリティ・ルーティングが、必要とされる。また、ケア提供者の分散型チームを考慮するアラーム消音の方法が、必要とされる。

また、個々のハードウェアが充分に小さく可動性であるため、医療部門（デパートメント）を超えての移動や、退院後の一定期間、患者の自宅に送られることが可能なシステムが、必要とされる。

病院環境から外来診療の場まで、患者に対し適切なケアを提供するために、個々のハードウェア・モジュールが、異なるタイプの患者センサとインタフェースをとるべく設定可能なシステムが、必要とされる。

また、必要とされるのは、患者、その家族及びケア提供者に対し、安全且つ確実な方法で接続可能とすることにより、いつどこでも患者の状態を警戒（ubiquitous patient vigilance）するシステムである。また、サード・パーティの機器からの患者の生理学的データ及びデータ解析から生じた他の情報を受信可能とすべく、システムを適合させることにより、サード・パーティが開発したソリューションの利用をサポートし、これにより革新を促進する患者ケアを提供するためのシステムが、必要とされる。

本明細書は、患者ケアを提供するためのシステムであって、揮発性又は不揮発性であり、コンピュータに読み込み可能な第１の媒体を有し、波動を伝送するための伝送媒体を含まない第１のコンピュータ・デバイスと、揮発性又は不揮発性であり、コンピュータに読み込み可能な第２の媒体を有し、波動を伝送するための伝送媒体を含まない第２のコンピュータ・デバイスと、揮発性又は不揮発性であり、コンピュータに読み込み可能な第３の媒体を有し、波動を伝送するための伝送媒体を含まない少なくとも一つのターゲット・コンピュータ・デバイスと、を備え、前記第１の媒体は、前記第１のコンピュータ・デバイスによって実行されると、標準スクリプト言語を用いて実行可能なプログラムを暗号化し、暗号化された前記プログラムをメッセージのヘッダに添付し、前記メッセージを、無線接続を介して、前記第１のコンピュータ・デバイスから前記第２のコンピュータ・デバイスへ送信する、複数の第１のプログラム指令を備え、前記第２の媒体は、前記第２のコンピュータ・デバイスによって実行されると、前記第１のコンピュータ・デバイスから前記メッセージを受信し、前記メッセージから、前記メッセージの受信用である少なくとも一つのターゲット・コンピュータ・デバイスを決定し、前記メッセージを、無線接続を介して、前記第２のコンピュータ・デバイスから前記少なくとも一つのターゲット・コンピュータ・デバイスへ送信する、複数の第２のプログラム指令を備え、前記第３の媒体は、第３のコンピュータ・デバイスによって実行されると、前記第２のコンピュータ・デバイスから前記メッセージを受信し、前記実行可能なプログラムを復号化し、前記実行可能なプログラムを実行することにより、前記メッセージを受信する、複数の第３のプログラム指令を備え、前記第２のコンピュータ・デバイスは、クラウド・ベース・コンピュータ・デバイスであることを特徴とする患者ケアを提供するためのシステムを提供することを目的とする。

本明細書は、また、患者ケアを提供するためのシステムであって、患者の少なくとも一つのパラメータを検出し、報告する少なくとも一つの検出機器と、前記少なくとも一つの検出機器と結合し、前記少なくとも一つの検出機器から電子患者データを受信するとともに、前記患者データを記憶可能なメモリを含む少なくとも一つの取得機器と、前記少なくとも一つの取得機器と結合し、前記取得機器から前記患者データを受信するための少なくとも一つのネットワーク・アプライアンスと、クラウド・コンピューティングを提供するためのネットワークであり、前記少なくとも一つのネットワーク・アプライアンスが結合し、前記患者データが全てのネットワーク機器にわたってアクセス可能となるように、前記患者データを記憶するためのデータベースを含むネットワークと、前記ネットワークと結合し、前記患者データにアクセスし、グラフィカル・ユーザ・インタフェース上で前記患者データを表示するための少なくとも一つの提示機器と、を備え、前記電子患者データの前記ネットワークを介する送信は、標準スクリプト言語を用いて実行可能なプログラムを符号化することによる前記患者データの暗号化と、前記患者データを含むメッセージへの前記プログラムの添付と、を含むことを特徴とする患者ケアを提供するためのシステムを提供することを目的とする。

一の実施の形態において、ネットワーク・アプライアンスは、患者の近傍に配置される。別の実施の形態において、ネットワーク・アプライアンスは、患者から離れて配置される。

一の実施の形態において、検出機器は、前記少なくとも一つの取得機器に有線接続を介して結合される。別の実施の形態において、検出機器は、前記少なくとも一つの取得機器に無線接続を介して結合される。

一の実施の形態において、前記少なくとも一つの検出機器及び前記少なくとも一つの取得機器は、３Ｇ／４Ｇ接続を介してネットワークに接続可能である。

一の実施の形態において、標準スクリプト言語は、Ｌｕａである。

一の実施の形態において、提示機器は、従来のＰＣ、タブレット、スマートフォン及び壁掛け式ディスプレイの何れか一つを備える。

一の実施の形態において、取得機器は、更に、提示機器として機能する。

一の実施の形態において、取得機器は、前記患者に対する全ての臨床データを複製して、前記メモリに記憶し、システム障害の場合、独立型のモニタとして機能する。

一の実施の形態において、取得機器は、ケア提供者設備における固定機器である。別の実施の形態において、取得機器は、退院した前記患者とともに及び外来診療のために残るモバイル機器である。

一の実施の形態において、患者ケアを提供するためのシステムは、実際の使用中におけるネットワーク性能を直接測定することにより最も効率的なメッセージ経路を算出するコスト・ベース・ルーティング・アルゴリズムを更に含む。

一の実施の形態において、患者ケアを提供するためのシステムは、前記患者及びケア提供者双方の位置及び存在情報に基づき、アラーム優先度をルーティングするアラーム・ルーティング・プロトコルを更に含む。一の実施の形態において、ケア提供者が、前記患者に割り当てられたすべての機器に対し、可聴アラームの消音又は音量を下げることができる。

一の実施の形態において、患者ケアを提供するためのシステムは、エクスチェンジと各メッセージ送信機及び受信機との間で、機器毎に一度暗号化されたリンクを確立する信頼されたセントラル・メッセージ・エクスチェンジを更に含む。一の実施の形態において、セントラル・メッセージ・エクスチェンジは、定期的に送信される急を要さないメッセージをひとまとめにする。一の実施の形態において、メッセージ送信機は、各メッセージを一度のみ送信し、前記セントラル・メッセージ・エクスチェンジは、各メッセージを複製して、前記メッセージのヘッダに含まれるサブスクリプション・リストに基づき、複数の受領者へ送信する。

本明細書は、また、患者ケアを提供するための方法であって、患者ケア・システムを提供するステップであって、少なくとも一つの患者の生理学的パラメータを検出し、報告する少なくとも一つの検出機器と、前記少なくとも一つの検出機器に結合する少なくとも一つの取得機器であって、前記少なくとも一つの検出機器から電子患者データを受信するとともに、前記患者データを記憶可能なメモリを含む取得機器と、前記少なくとも一つの取得機器に結合する少なくとも一つのネットワーク・アプライアンスであって、前記取得機器から前記患者データを受信するネットワーク・アプライアンスと、クラウド・コンピューティングを提供するためのネットワークであって、前記少なくとも一つのネットワーク・アプライアンスが結合されるとともに、前記患者データが全てのネットワーク機器にわたってアクセス可能となるように、該患者データを記憶するためのデータベースを含むネットワークと、前記ネットワークに結合する少なくとも一つの提示機器であって、前記患者データにアクセスし、該患者データをグラフィカル・ユーザ・インタフェース上に表示する提示機器と、を含む患者ケア・システムを提供するステップと、前記少なくとも一つの検出機器を用いて前記少なくとも一つの患者の生理学的パラメータを検出及び報告するステップと、前記少なくとも一つの患者の生理学的パラメータを示す電子データを前記取得機器へ送信するステップと、標準スクリプト言語を用いて実行可能なプログラムを符号化することにより前記患者データを暗号化し、前記患者データを含むメッセージに前記患者データを添付するステップと、前記暗号化されたデータを前記ネットワーク・アプライアンスへ送信するステップと、クラウド・コンピューティングを用いて前記ネットワーク上で前記データを記憶するステップと、前記提示機器を用いて前記データにアクセスし、該データを復号化し、表示するステップと、を含むことを特徴とする方法を提供することを目的とする。

本願の前述の及び他の実施の形態は、図面と、以下に記載する詳細な説明とにおいて、より詳細に記載される。

本明細書に係る医療データ情報システムのワークフローの一の実施の形態を説明する図である。 病院の集中治療室（ＩＣＵ）における本発明の例示的な使用状況を説明する図である。 病院の一般病棟における本明細書に係るシステムの例示的な使用状況を説明する図である。 自宅状況における本明細書に係るシステムの例示的な使用状況を説明する図である。 本明細書に係る医療データ情報システムの一の実施の形態の例示的な物理的配置を説明するブロック図である。 一の実施の形態に係るシステム・ポータル・アプリケーションのソフトウェア・アーキテクチャを説明するブロック図である。 本明細書に係る医療データ情報システムにおける取得機器の初期化動作を説明するフローチャートである。 一の実施の形態における２つのアプリケーション間での例示的なメッセージ交換動作を説明するフロー図である。 本明細書の医療データ情報システムにおける一組のアプリケーションからのメッセージのフローの一の実施の形態を説明するフロー図である。

本明細書は、携帯電話プラットフォームと、独自仕様ではないハードウェア及びソフトウェア・モジュールとを用いた、医療データの取得、集約、配布、記憶及び表示により、患者ケアを提供するためのシステムに向けられている。一の実施の形態において、本明細書のシステムは、以下を用いて実装される：少なくとも一組の複数のプログラム命令を実行する二以上のコンピュータ又はコンピュータ・デバイス；前記コンピュータ・デバイス間におけるデータの転送手段；及び、前記コンピュータ・デバイス間のデータの転送を促進するための少なくとも一つのプロトコル。

また、本願で記載される機能は、ラップトップ又はタブレット・コンピュータ；パーソナル・コンピュータ；携帯情報端末（パーソナル・データ・アシスタント）；携帯電話；サーバ；組み込みプロセッサ；デジタル・プロセッサ（ＤＳＰ）・チップ或いはプログラム命令又はコードを実行可能な専用画像機器；を含むがこれらに限定されないいかなるコンピュータ・プラットフォームにおいても動作可能であることは、当業者であれば理解するであろう。

更に、プラットフォームは、一又は複数の不揮発性メモリに記憶される複数のプログラム命令を、一又は複数のプロセッサを用いて実行することにより、本願に記載される機能を提供し、一又は複数の有線或いは無線ネットワークによるデータ通信で、送受信機を介してデータを提示及び／或いは受信することは、理解されるであろう。

また、各機器が、データの送信及び伝送が可能な無線及び／或いは有線の受信機及び送信機と、プログラム命令の処理が可能な少なくとも一つのプロセッサと、プログラム命令を記憶可能なメモリと、ここで記載される処理を実行するための複数のプログラム命令からなるソフトウェアと、を有することは、理解されるであろう。更に、プログラム・コードは、単一のコンピュータ上で動作する単一のアプリケーションにコンパイル（予めコンパイル或いは「ジャスト・イン・タイム」でコンパイル）可能であり、或いは、ローカルに又は互いにリモートで動作する数台の異なるコンピュータに配布可能である。

本明細書のシステムは、患者から生理学的データを収集し、検出されたデータを取得機器へ送信する一又は複数の検出機器と、受信したデータをクラウドへ送信する取得機器とを提供し、システムの構成要素は、相互に接続される。クラウドは、データを集約し、一又は複数のディスプレイ或いは提示機器にデータを配布する。

システムは、サード・パーティがアプリケーションを導入及び開発できるようにすることにより、新しい技術を迅速に活用する。更に、本システムは、インストール、トラブルシューティング及びサービス（修理）が容易であり、特別なハードウェア、ネットワークの構築又はＩＴスタッフを必要としない。また、システムは、堅固でないネットワーク・インフラにおいても動作可能であり、万一のときに機能する「セーフ」モードにおいても動作する能力を有する。更に、患者ケアを提供するためのシステムは、患者に取り付けられることが可能な患者モニタリング・モジュールを備え、病院から退院した患者とともに、また、外来診療のために、持ち運びが可能となる。

一の実施の形態では、システムは通信プロトコルを使用し、メッセージの送信時には、送信機は業界標準のスクリプト言語で書かれた小規模なコンピュータ・プログラムを含む。受信機は、メッセージを受信すると、プログラムを実行し、使用可能な形式のメッセージデータを生成する。これにより、メッセージ自体を厳格に符号化する必要性が排除され、メッセージの符号化における柔軟性の大幅な拡張が提供される。一の実施の形態では、スクリプト言語はＬｕａである。一の実施の形態では、送信機は、更に、実行可能な配信受領コードを上記したプログラムに挿入することにより、自身の受領証明の生成が可能となっている。受信機は、当該コードを実行し、オリジナルのメッセージを受信すると、配信受領を送信する。

一の実施の形態では、システムは、現在のネットワーク性能を実際の使用中に直接測定することを含む複数の因子を用いて、最も効率的なメッセージ・ルート（経路）を算出するコスト・ベース・ルーティング・アルゴリズムを使用するメッセージ・エクスチェンジ（メッセージ交換機；message exchange）を含む。

一の実施の形態では、システムは、メッセージの転送に先立ち送信機及び受信機が鍵或いは他の秘密鍵を交換する必要性を排除することにより、暗号化されたメッセージの非接続型エクスチェンジを提供する。これは、エクスチェンジと各送信機及び受信機との間で機器毎に１回の暗号化リンクを確立する信頼できるセントラル・メッセージ・エクスチェンジ（central trusted message exchange）を提供することにより、達成される。

一の実施の形態では、システムは、急を要さないメッセージをまとめて、連続的によりはむしろ周期的に送信するメカニズムを提供することにより、モバイル機器の電池残量及び帯域幅使用量を節約する。更に、システムは、複数の受領者を対象としたメッセージが、送信機によって１回のみ送信されることを指示する。各メッセージは、ヘッダ内に全ての受領者の完全なサブスクリプション・リストを含む。そして、システム・ルータは、メッセージを複製し、各受領者へ送信する。これはまた、電池の消耗及び全般的な帯域幅の使用を低減することに役立つ。

一の実施の形態において、システムは、患者及びケア提供者双方の位置及び存在情報に基づき、アラーム優先度（プライオリティ）をルーティングする。応答可能なケア提供者の位置と、患者に最も近い少なくとも一人のケア提供者の位置又は特定のタイプのアラームに基づき最良のケアを提供するべく指定されたケア提供者の位置との双方で、アラームが鳴らされる。

一の実施の形態では、システムは、特定の患者に対して割り当てられたすべての機器に対し、ケア提供者がアラームを「クエンチする（quench）」ことにより、アラーム音を消音する或いは音量を下げることを許可する。

本発明は、複数の実施の形態に向けられる。以下の開示は、当業者が本発明を実施することを可能とするために提供される。本明細書で使用する言語は、何れかの実施の形態を否定するものとして解釈すべきではなく、特許請求の範囲に記載した表現の意味を超えて特許請求の範囲を制限するように用いられるべきではない。ここに定義される一般的な原理は、発明の精神及び範囲を逸脱しない範囲で、他の実施の形態や応用例に適用可能である。また、使用される専門用語や表現は、例となる実施の形態を記載するためのものであり、限定的に考慮すべきではない。したがって、本発明は、多くの代替例や、変形例、開示された原理や特徴に整合する同等のものを包含する最も広い範囲に対応する。明瞭性を考慮して、また、本発明を不必要に曖昧としないために、本発明に関連する技術分野において周知の技術内容に関する詳細については、記載しないこととする。

システムの概略

図１Ａは、本明細書に係る医療データ情報システムのワークフロー１００の一の実施の形態を説明する図である。ステップ１０２は、検出機器１１３を介する医療データの取得を示す。検出機器１１３は、様々な実施の形態において、民生品（ＣＯＴＳ）のセンサ、時代遅れの機器（入力のみ）及びサード・パーティの機器を含む。様々な実施の形態において、システムは、一又は複数のアプリケーション・プロバイダにより利用可能とされた複数のプラグ・アンド・プレイ・アプリケーションを備える。システムは、少なくとも一つの検出機器１１３と、少なくとも一つの取得機器１１２と、ネットワーク・アプライアンス・ＧＨＣ／クラウド１１４と、提示／表示機器１１６とを含む。一の実施の形態では、この少なくとも一つの検出機器１１３は、有線接続或いは無線接続により、少なくとも一つの取得機器１１２と接続可能である。検出機器１１３は、外来診療の環境において取得機器１１２とともに使用可能であり、一の実施の形態では、携帯電話（３Ｇ／４Ｇ）ネットワークを介してクラウドに接続可能である。一の実施の形態において、取得機器１１２は、医療分野におけるいかなるアプリケーション、機器又はサービスの発展をも可能にするためのエコシステムや、アプリケーション・プログラミング・インタフェース（ＡＰＩ）、テンプレート等を備える医療情報プラットフォームを提供する。一の実施の形態では、取得機器１１２は、オープン・ソース及び有標製品の双方をサポートする。取得機器１１２は、米国の医療保険の携行性と責任に関する法律（ＨＩＰＡＡ）に従って作られるため、医療関連アプリケーションに関して、プラットフォーム独立性が備えられる。一の実施の形態では、医療ソフトウェアの発展はもちろん、医療機器の同期をも可能にすべく、複数のＡＰＩが取得機器１１２に設けられる。様々な実施の形態において、取得機器１１２は、複数のサード・パーティ生理学的パラメータ入力ソースと、例えば人工呼吸器や、ＩＶポンプ、患者パラメータ検出機器等の医療機器とから、データを受信する。取得機器は、クラウドに接続するネットワーク・アプライアンス・ＧＨＣに接続する。一の実施の形態では、取得機器１１２は、提示機器として動作することも可能である。したがって、取得機器１１２は、システムが患者モニタリング・システムとして機能することを可能とすると同時に、サード・パーティ・アプリケーションを活用することをも可能とする。

一の実施の形態では、取得機器は、ケア提供者にアラーム・メッセージングを提供する第二の通信技術（すなわち、例えば３Ｇ／４Ｇ等の携帯電話技術）を提供可能である。別の実施の形態では、取得機器は、例えば患者ＩＤ番号或いは病床番号（ベッド番号）及びアラーム・タイプ（心拍、呼吸等）等の重大なアラーム情報のみを提供する可視的表示器（例えば光表示器等）又は音声表示器を有する。

取得されたデータは、ステップ１０４において、クラウド１１４により集約及び配布される。他の実施の形態では、クラウドは共同設置され、一又は複数のドメインを含む。クラウド１１４は、取得機器１１２上で動作するアルゴリズムに対し、処理能力を提供することにより、ローカル・ハブとして作動する。既存の携帯電話ベース・プラットフォームが使用されることにより、消費者向け技術の活用が可能となり、独立したパラメータ集約プラットフォームの製造／開発コストが削減される。様々な実施の形態において、クラウド１１４は、モバイル機器が患者につなげられ、病院環境内で患者モニタとして動作することを可能とする。一の実施の形態では、クラウド１１４は、また、モバイル機器が、病院以外の環境において、看護師及び医師によって、患者のモニタリング及びケアのために使用されることを可能とする。別の実施の形態では、クラウド１１４は、モバイル機器が、複数の医療アプリケーション及び機器、具体的には検出機器を介して、自宅にいる患者とケア提供者とをつなぐことを可能とする。更に別の実施の形態では、クラウド１１３は、モバイル機器が老人ホームにいる家族とケア提供者とをつなぐことを可能とする。

様々な実施の形態において、クラウド１１４は、下層ネットワークが適切に機能しない時でさえ、システムが効率的に動作することを可能とする。更に、クラウド１１４は、いかなる既存のネットワーク・インフラにおいても動作し、動作のために特定の或いは独自仕様のハードウェア／ソフトウェアをインストールする必要が無い。システムは、セーフ・モードで動作するように設計されており、ネットワーク障害の場合には、少なくとも一つの患者モニタリング装置が動作可能となっている。たとえセントラル・モニタリングが利用できない場合も、セーフ・モードの動作で、少なくとも患者にローカル接続されるアラームが作動する。ＧＨＣ又はネットワークとの接続が使用不可である場合も、取得機器及び任意でＧＨＣが、患者の生理学的データを分析及び記憶可能であり、患者の位置において、アラーム・メッセージングを提供可能である。機器はデータを記憶し、ネットワーク動作が回復すると、データはＧＨＣクラウドへ送信される。記憶された情報は、アラームの生成や他の情報のために生成される連続的な患者生理学的信号或いはメッセージ・パケットになり得る。取得機器は、完全な患者生理学的データの受信及び提示にも適用可能である。

様々な実施の形態において、クラウド１１４は、一又は複数の病院又は医療センタから取得され、各病院又は医療センタから離れて（リモートで）記憶されるデータを含む。クラウド１１４に患者データを記憶することにより、組織に導入された正規のデータベース管理システムに関連する処理の遅れが取り除かれる。したがって、クラウド１１４は、離れた場所にいるケア提供者はもちろん、サード・パーティのコンサルタントにも、クラウド内に記憶されたデータを分析可能とする。クラウドは、また、複数のソースからの生理学的及び他の患者データの処理を考慮に入れて、サード・パーティ・アプリケーションにもクラウド１１４に記憶されたデータを分析可能とする。更に、クラウド１１４は、患者のリモート・トリアージを可能にする。これにより、新興成長領域や発展途上領域の市場ではもちろん、軍事衝突領域や被災地においても、多大なる用途をもたらすことであろう。

配布後、データは、ステップ１０６で、様々な実施の形態において、従来のＰＣ、タブレット、スマートフォン及び壁掛け式ディスプレイを含む表示機器１１６上に提示される。様々な実施の形態において、医療データは、システム１００のインフラで利用可能ないかなる表示機器においても表示可能である。システムは、データの表示を、独自仕様の表示機器に限定しない。システムは、また、複数の位置に位置する複数の表示機器に患者データを同時に提示することをも可能にする。

一の実施の形態において、本明細書のシステムは、例えば、Ｐａｔｉｅｎｔ Ｒｅｓｏｌｖｅｒ、Ｄｅｖｉｃｅ Ｒｅｓｏｌｖｅｒ、Ｐｏｌｉｃｙ Ｅｎｇｉｎｅ、Ｏｒｃｈｅｓｔｒａｔｉｏｎ、Ｍａｎａｇｅｍｅｎｔ等、複数のクラウド・ベース・サービスを提供する。例えば、Ｐａｔｉｅｎｔ Ｒｅｓｏｌｖｅｒ又はＤｅｖｉｃｅ Ｒｅｓｏｌｖｅｒサービスは、医学的な配慮が必要な患者に最も近い位置にいるケア提供者及び／或いは医療専門家を決定する。様々な実施の形態において、Ｐａｔｉｅｎｔ Ｒｅｓｏｌｖｅｒサービスは、例えば「患者カタログ」、「患者ＩＤマップ」、「ＰＨＩ管理」、「セッション・マップ」等の機能を備える。Ｄｅｖｉｃｅ Ｒｅｓｏｌｖｅｒサービスは、例えば「機器管理」、「セッション・カタログ」等の機能を備える。Ｐｏｌｉｃｙ Ｅｎｇｉｎｅサービスは、例えば「配布」、「セキュリティ・ポリシー」、「アクセス・コントロール」、「アラーム・エスカレート」等の機能を備える。Ｏｒｃｈｅｓｔｒａｔｉｏｎサービスは、例えば「ワークフロー」、「データフロー」等の機能を備える。Ｍａｎａｇｅｍｅｎｔサービスは、例えば「ドメイン管理」、「機器構成」、「アップグレード管理」等の機能を備える。セントラル・ダッシュボードは、医療サービス提供組織が、組織の全設備にわたって、組織の具体的なポリシー（方針）に基づき、Ｐａｔｉｅｎｔ Ｒｅｓｏｌｖｅｒ、Ｄｅｖｉｃｅ Ｒｅｓｏｌｖｅｒ及びＰｏｌｉｃｙ Ｅｎｇｉｎｅを設定可能とする。セントラル・ダッシュボードは、全ての機器がポリシーに準拠し、患者に対するケアの一律基準を確立することを保証する。クラウド・ベース・サービスは、位置、優先度、可用性及び機能の組合せに基づく適切なケア提供者への患者のアラーム情報のインテリジェント・マッピングを提供する。

一の実施の形態では、本明細書のシステムは、例えばヘルス・システム・セブン（ＨＬ７）・ゲートウェイ（双方向）や、患者及び家族アプリケーション、ケア提供者アプリケーション、アーカイビング・アンド・プリンティング・アプリケーション及びアドミニストレーション・アンド・ダッシュボード・アプリケーション等の複数のウェブ・アプリケーションを提供する。

ステップ１０２で、取得機器１１２は、患者から臨床データを動的に取得する。また、取得機器１１２は、全体的なシステム障害の発生時に、アラーム及びデータ表示の双方について、代替として機能する。取得機器１１２を内蔵バックアップとして包含することにより、システム・コストの低減及びシステムの複雑度の最小限化に役立つ。ステップ１０４におけるクラウド１１４の機能は、機器及びサービス発見、データ配布及び記憶、セキュリティ及びポリシー制御、患者ケア報告の生成、システム測定及びワークフローを含むが、これらに限定されない。クラウド・システムは、機器、アプリケーション及び機能のクラウド（商業界）からのライセンス供与と、それに続く機器及びアプリケーションの使用のそのままの測定及び記録を可能とする。実施例は、特定の患者に付随するパラメータの数及びタイプ、期間の長さ、ネットワーク上でアクティブな機器の数、及び、特定の機能が使用された回数を含む。機器、アプリケーション及び機能の実際の使用を知ることにより、新規で唯一の課金モデル（billing model）が可能になる。実施例は、特定の分析に対して使用毎に課金する方法や、システムによりモニタリングされる患者の数に基づく課金、患者の度合い（例えば、モニタリングされるパラメータの数）に基づく課金を含む。従来の患者モニタリング・システムは、資本設備の品目として売られている。クラウド・システムの能力は、従来の資本設備購買を、サービス・モデルへと変化させる。ステップ１０６で含まれる表示機器１１６は、臨床データ、アラーム表現及び全体の患者管理の表示を提供する。更に、一の実施の形態では、各表示機器１１６は、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を含み、ケア提供者は、事務的職務を果たすことが可能となる。

一の実施の形態では、取得機器１１２は、ケア提供者設備と患者の自宅との双方に配置され、独立系ハードウェア開発会社（ＩＨＶ）の機器及び海外からのシステム輸入品を収容する拡張性を有する。一の実施の形態では、ネットワーク・アプライアンス・ＧＨＣは、ケア提供者設備に配置され、独立系ソフトウェア開発会社（ＩＳＶ）のアプリケーション及び海外からのシステム・インタフェースを収容する拡張性を有する。一の実施の形態では、表示機器１１６は、何れの場所にも配置可能であり、ＩＳＶアプリケーションを収容する拡張性を有する。

図１Ｂは、病院の集中治療室（ＩＣＵ）１０１における本発明の例示的な使用状況を説明する図である。検出機器１１３を介して複数のパラメータを検出可能な取得機器１１２が、患者データの測定及び収集に使用される。ベッドサイド・モニタ・ディスプレイ１２２は、イーサネット（登録商標）接続により取得機器１１２につなげられ、患者の生命に関する統計値を表示する。取得機器１１２は、また、例えば看護師モニタ１２４や、病室外の専用モニタ・ディスプレイ１２６、緊急指令システム（ＩＣＳ）モニタ１２８、セントラル・ステーション・モニタ１２９等の複数の患者モニタにつなげられる。取得機器１１２と複数のディスプレイとは、本明細書で提供されるクラウド１１４につなげられる。クラウド１１４は、同様に、患者関連データを記憶するためのデータ・ストレージ・プラットフォーム１４４につなげられる。クラウド１１４により、ケア提供者１５２は、モバイル表示機器１１５を介して患者の記録にアクセス可能となるとともに、患者の家族１５４は、病院環境から離れた場所において、モバイル表示機器１１６を介して患者の状況をモニタリング可能となる。クラウド１１４は、また、時間をかけて収集された複数の生理学的パラメータからの組合せ解析を可能とする。これは、システムの一部として開発されたセンサ機器と、サード・パーティ・センサ機器とを含む。

図１Ｃは、病院の一般病棟１０３における本明細書に係るシステムの例示的な使用状況を説明する図である。取得機器１１２は、例えば心拍数（ＨＲ）や、呼吸数等の患者の医療データを受信するパラメータ集約プラットフォームとして使用される。図示される実施の形態では、取得機器１１２は、また、患者のベッドサイド・モニタとして動作する。取得機器１１２は、本明細書のシステムによって提供されるクラウド１１４と、無線でつなげられる。クラウド１１４は、同様に、患者関連データを記憶するためのデータ・ストレージ・プラットフォーム１４４とつなげられる。更に、クラウド１１４は、一般病棟への入室を許可されている患者全員の生命に関する統計値を表示するための監視ユニット１３６とつなげられる。クラウド１１４により、ケア提供者１５２は、モバイル表示機器１１６を介して患者の記録にアクセス可能となるとともに、患者の家族１５４は、病院環境から離れた場所において、モバイル表示機器１１６を介して患者の状況をモニタリング可能となる。クラウド・システムは、家族に、患者ケア情報へのアクセス、患者のケアの履歴及びワーク・フローの調査、退院指導のアップデートの確認及び受信、及び、課金の調査の能力を提供することにより、患者ケアの過誤を将来的に減らす可能性を秘めている。

図１Ｄは、「自宅」１０５状況における本明細書に係るシステムの例示的な使用状況を説明する図である。モバイル取得機器１１２は、例えば携帯電話や他の独立した機器等であり、例えば心拍数（ＨＲ）や、呼吸数、血糖値等の患者の医療データを受信するパラメータ集約プラットフォームとして使用するために、患者の自宅に導入される。取得機器１１２は、また、患者のホーム（自宅）・モニタリング・ドックとしても動作する。取得機器１１２は、本明細書のシステムによって提供されるクラウド１１４とつなげられる。クラウド１１４は、同様に、患者関連データを記憶するためのデータ・ストレージ・プラットフォーム１４４とつなげられる。クラウド１１４は、また、例えば看護師モニタ１２４や、ＩＣＳモニタ１２８、リアル・タイム・ベースで患者の生命に関する統計値を表示するためのセントラル・ステーション・モニタ１２９等の複数のモニタとつなげられる。クラウド１１４により、ケア提供者１５２は、モバイル表示機器１１６を介して、患者の記録にアクセス可能及び患者の健康をモニタリング可能となるとともに、患者の家族１５４は、病院環境から離れた場所において、モバイル表示機器１１６を介して、患者の状況をモニタリング可能となる。

システム・トポグラフィー

図２は、本明細書に係る医療データ情報システム２００の一の実施の形態の例示的な物理的トポグラフィー（配置）を説明するブロック図である。一の実施の形態において、システム２００は、患者データの取得のための検出／取得機器２１２（図１Ａの検出機器１１２及び／或いは取得機器１１３に対応）と、患者データの提示のための表示機器２１６（図１Ａの表示機器１１６に対応）とを含む。別の実施の形態では、システム２００は、データの取得及びデータの提示の両方を可能な機器を含む。従来の患者モニタは、取得機器及び提示機器の両方として機能可能である。システム２００は、また、患者データの集約及び配布に対応可能な複数のグローバル・ヘルス・コネクタ（ＧＨＣ）２１３、２１５を有するクラウド２１４を含む。ＧＨＣは、ネットワークに結合する統合ソフトウェアを有するネットワーク・ハードウェア・アプライアンスである。一の実施の形態では、システム２００は、ケア提供者設備、例えば病院２２０に共同配置される複数のＧＨＣ２１５と、クラウド２１４内に配置される複数のＧＨＣ２１３との双方を含む。ＧＨＣ２１３、２１５は、システム２００の取得機器２１２及び表示機器２１６に接続するために動作する。一の実施の形態では、取得機器２１２及び表示機器２１６は、新しい媒体又はメッセージ・エクスチェンジ・スイッチ構成を介して接続される。クラウド２１４は、ルーティング可能な冗長基幹（redundant routable backbone）において、全てのＧＨＣ２１３、２１５にピアとして接続し、全ての検出機器２１２及び表示機器２１６を束ねて、グローバルな患者の状態への警戒（global patient vigilance）を確立する。言い換えれば、システム内の何れの表示機器においても、常にかつ任意の適切なアクセスにおいて、何れの患者の患者データも提示可能となるように、全ての患者データがクラウドによって集められ、配布される。

図２に示されるように、検出機器２１２は、病院２２０、診療所２２２及び患者の自宅２２４に配置可能である。表示機器は、病院２２０、診療所２２２及びケア提供者２２６と共に配置可能である。病院２２０及び診療所２２２における検出機器２１２及び表示機器２１６は、それぞれ、病院ネットワーク２３０及び診療所ネットワーク２３２を介して接続され、全ての機器が、インターネット２３４を介して、クラウド２１４を通じて相互に接続する。

一の実施の形態において、検出機器は、システム取得機器と称され、システム・セッション・フォーマットで、データの取得及びパブリッシュ（発行）を行う何れの機器も含む。このような機器は、従来の固定されたベッドサイド・モニタ、小型のフォーム・ファクタ装着型機器、例えばデジタル・データ・レコーダや海外からのシステム輸入品等の仮想機器等を含むが、これらに限定されない。情報のフロー（流れ）は、システム取得機器に未加工のフォーマット・データを提供するセンサから始まる。取得機器におけるドライバ・アプリケーションは、未加工のフォーマット・データをパラメータ・データに加工する。パラメータ・データは、次に、取得機器により、システム・セッション・フォーマットでパブリッシュされ、ネットワークにアップロードされる。システム・セッション・フォーマットは、クラウドによって認識され、表示機器に配布されるパラメータ・データの形態である。

一の実施の形態では、一人の患者には一台のシステム取得機器が割り当てられ、患者による取得機器の共同使用はない。複数のセンサ及びパラメータは、一台の取得機器によりグループ分けされ、一人の患者に対する固有のセッションとされる。一の実施の形態において、取得機器は、最近５日間の患者データを記憶するローカル・メモリを有する。ローカルに記憶されるデータは、クラウドにアップロードされたデータの正確な複製であり、複製モデルを介してパブリッシュされる。一の実施の形態では、システムは、ピア・ツー・ピア（peer-to-peer）のデータの推移複製を含む。ネットワーク内における有意なデータベースの大部分が、ピア・ツー・ピア・モデルを用いて、複数の場所で複製される。ピア・ツー・ピア・モデルは、費用対効果発見的問題解決法（cost/benefit heuristic）に基づき、推移複製及び選択複製を自動的に処理する。ローカル・メモリは、データ履歴及びシステム全体の障害時におけるバックアップを提供する。

一の実施の形態において、表示機器は、システム提示機器と称され、データを表示する任意の機器を含むとともに、任意でアラームを含む。このような機器は、従来のＰＣ、タブレット、スマートフォン及び壁掛け式モニタを含むが、これらに限定されない。提示機器は、ブラウザ・ベースであり、何れの場所でも働く環境をサポートする。一の実施の形態では、システム提示機器は、ＧＵＩを含み、ケア提供者ワークステーションの機能を提供する。例えば、様々な実施の形態において、提示機器のＧＵＩは、アラーム管理及びクエンチ（quench）、患者管理（入院／退院）、患者／セッション接続及び過去に遡ってのデータ分析機能（レトロスペクティブ・データ分析機能）を提供する。一の実施の形態では、全ての提示機器が、インタフェース・ファンデーション（基盤）として、ハイパー・テキスト・マークアップ言語５（ＨＴＭＬ５）を使用する共通ユーザ・インタフェースを含む。

図２を再度参照して、システム・クラウド２１４は、共同配置されるグローバル・ヘルス・コネクタ（ＧＨＣ）２１５と、クラウドＧＨＣ２１３との双方を含み、全てが接続して、システム・クラウド・バックボーン（システム・クラウド基幹；system cloud backbone）を形成する。共同配置されるＧＨＣ２１５は、それぞれ、プラグで接続され、電源がオンされ、そしてケア提供者設定に使用される小型のネットワーク・アプライアンスである。一の実施の形態では、およそ２００から５００の病床（ベッド）が、各共同配置されたＧＨＣに割り当てられる。クラウドＧＨＣ２１３は、バックボーン（基幹）のグローバルな広がりを確保し、一の実施の形態では、およそ５００，０００の病床が、各クラウドＧＨＣクラスタ（８のクラウドＧＨＣを含む）に割り当てられる。システム・クラウド２１４は、メッセージ・エクスチェンジ・ディレクトリをホスティングする。一の実施の形態では、全てのＧＨＣ２１３、２１５はピアであり、全ての取得機器２１２及び提示機器２１６は、何れのＧＨＣ２１３、２１５とも接続可能である。各ＧＨＣ２１３、２１５は、取得機器２１２からセッション・データを集約し、当該データを提示機器２１６へ配布する。システム・クラウドは、アカウント、患者及びアセット（資産；asset）別に整理されたドメイン・カタログを含む。更に、一の実施の形態では、ＧＨＣは、真のフェイル・オーバー冗長性（fail-over redundancy）のために、完全に複製される。

一の実施の形態において、システム・クラウドは、少なくとも一つのシステム・クラウド・ドメインと、複数のシステム・クラウド・デパートメント（部門）とを含む。ドメインは、システム・クラウドの論理的に分離された上層であり、ドメイン間のアクセスを提供しない。ドメインは、一般的に、病院に相当し、１０の病床から１，０００以上の病床まで、病床数に対応する費用で拡張可能（scalable）である。情報システムの日常の動作は、全てドメインで発生する。ドメインの各ユーザの景色は、システムの全「世界」の景色である。言い換えれば、各ユーザは固有であり、また、分離されており、任意の適切なアクセスの場合、同じドメイン内の他の全てのユーザを見ることができる。全てのＧＨＣ、取得機器及び提示機器は、ドメインに属する。一の実施の形態において、外部機器はドメインで使用可能であるが、最初に、当該ドメインで動作する権限を与えられなければならない。システム・クラウド・ドメインは、全ての病院データを包含する。全ての病院データは、全てのケア提供者に対するアカウント、患者の保護医療情報（ＰＨＩ）、患者セッション・データ、アセット・レコード（資産記録）、システム・クラウド・デパートメント情報及び予め設定された病院が必要とするパラメータ設定を含むが、これらに限定されない。

各システム・クラウド・デパートメントは、ドメイン内での区分を表し、ワークフローを助ける機能を有する。各デパートメントは、一般的に、病院組織に相当し、複数のデパートメントにまたがるアクセスに関し、ほとんど制限の無い「ソフトな」区分とみなされる。ケア提供者が彼らのデパートメントで患者に素早く集中可能となるように、ケア提供者、患者及び機器は、全て、「ホーム」・デパートメントを有する。多くのデパートメントは、制限が無く、システム内での強制が無いため、ケア提供者は、要望通りにデパートメントを移ることができる。全ての機器は、電源オン時に、ログオンするケア提供者のデパートメントによって決定されるデパートメントを引き継ぐ。一の実施の形態では、あるデパートメントは制限されており、最初にケア提供者によってアクセスされる前に、事前承諾を必要とする。例えば、ケア提供者は、最初に承諾が得られなければ、精神科医療デパートメントにアクセスできない。各デパートメントは、更に、予算編成のために課金イベント（billing events）の監視を行う。

一の実施の形態では、システム・クラウドは、更に、複数のドメインに対する課金を集約するために使用されるシステム・クラウド組織を含む。

システム・セキュリティ

本明細書の医療データ情報システムの各ドメインは、「ウォールド・ガーデン（壁に囲まれた庭）」として設計される。各ドメインは、厳しく制限されたアクセスを含むが、ひとたび中に入ると、ユーザは、自由に動き回ることができる。システムのセキュリティは、会計監査が行き渡り、全ての活動が記録されるパーミッシブ・モデル（permissive model）として組み立てられる。システムにおける変わった要求は、「ブレイク・ザ・グラス（break the glass）」シナリオで対処される。例えば、一の実施の形態では、変わったアクセスを要求するユーザには、次に進む前に、「本当に？」といったタイプの質問が提示されるとともに、警告音が続く。システムは、ユーザへの広範囲のアクセスを提供するが、必要に応じて、まだいくらかの制限は存在する。例えば、看護師は、全てのアカウントを消去することはできない。本明細書の医療データ情報システムのセキュリティは、ケア提供者が患者ケアを提供することを妨げることがないように設計される。そのようなものとして、システムは、ＩＴセキュリティ、暗号化、仮想プライベート・ネットワーク（ＶＰＮ）又はオペレーティング・システム（ＯＳ）・プラットフォームを信頼しないこととなる。

ケア提供者及び管理者は、取得機器を介してシステムにアクセスするために、ユーザ名とパスワード認証情報とを有するアカウントを持つ必要が有る。一の実施の形態では、患者及び親戚は、インターネットを介して特別な制限付きのアクセスが可能であり、アカウントは必要とされない。一の実施の形態では、アカウントを有するユーザには、更に、短文式認証情報として、ＰＩＮが提供される。ＰＩＮは、例えば数字キーパッド等での認証情報の完全な入力が手ごわい場合に使用するためのものである。ＰＩＮは、割り当てられたロール（役割；role）に固有のものであり、複数のユーザが取得或いは提示機器にログオンした際に、アカウントを切り替えるために使用される。更に、ＰＩＮは、ネットワークがダウンした際の緊急アクセスのために、全ての装置において、キャッシュに格納されている。

各アカウントには、一組の許可されたロールが割り当てられる。各ロールは、管理側によりセット・アップされたパーミッション（許可；permission）の指定された組を定義する。ユーザは、ログオン中にロールを選択し、続いてパーミッションを選択する。一の実施の形態では、ロールは、また、許可されたアプリケーションのリストを特定する。ロールは、ログオフした後再度ログオンすることによってのみ、変更が可能である。一つのシステム機器への複数のログオンは、全て、同じロールを共有しなければならない。各ロールに割り当てられたパーミッションは、ＰＨＩへのアクセス、患者の入院許可、データの閲覧を含むが、これらに限定されない。各アカウントは、ロールの割り当てによってのみ、パーミッションを受ける。言い換えれば、アカウント・レベルでの権利は無い。アクティブ・ディレクトリ・フェデレーション（active directory federation）は、ディレクトリのグループにロールを位置づけ、大部分のアカウント管理がアクティブ・ディレクトリ内で実行されることを許可する。

メッセージ及びネットワーク・トラフィックを含む全てのデータが、高度暗号化規格２５６（ＡＥＳ−２５６）を用いて暗号化される。更に、全てのシステム機器が、システム・クラウドに接続される前に、認証される。一の実施の形態では、装置ＯＳはシステムによって信頼されていないとみなされるので、復号化ポイントは、装置におけるメッセージ・エクスチェンジ接続ポイントである。機密情報への意図せぬアクセスを防ぐために、ＰＨＩデータは、独立した暗号化データベースにおける臨床データ又はセッションから隔離される。一つのデータベースへの不正アクセスは、ＨＩＰＡＡによって保護されるＰＨＩを危険にさらさない。システムは、堅固な秘密鍵管理及び秘密鍵エスクロー（escrow）を含み、主となる秘密鍵が、認証情報により鍵をかけられた金庫（vault）に閉じ込められる。キャッシュに格納された金庫は、ネットワークがダウンした場合にも、ログオンを許可する。クラウド及びローカル・ネットワークは、同じ暗号化を利用し、クラウド・バックアップもまた、暗号化される。

ネットワーク障害や、ソフトウェア・ウイルスによる攻撃、或いは他の原因による非常時には、システムは、ＧＨＣへの接続をシャット・ダウンし、独立した機器として動作することにより、ローカルなアラーム・メッセージングとともに生理学的データを取得及び提示することが可能である。

システムは、図３に示されるように、Ｌｕａ符号化と仮想マシン（ＶＭ）とを利用し、信頼できるセキュリティのためのクローズド・システムを実現するとともに、サード・パーティによって拡張可能なポータブル・システムを実現する。ＶＭは、極めて有害な入力ソフトウェアが取得機器を介してシステムに接続された場合、ソフトウェアが、システム・ハードウェア及びソフトウェアから切り離された仮想マシンに包含されるように、切り離されたアプリケーションを生成する。攻撃時には、システムはＶＭをシャット・ダウンする一方、他の患者モニタリング・アプリケーションのために、システムは動作を継続可能である。

システム・アプリケーション

本明細書の医療データ情報システムの全ての機器は、システムのベース・ソフトウェア・スタックであるシステム・ポータル・アプリケーションを動作させる。各ＯＳプラットフォーム（ＰＣ、Ｍａｃ、ｉＯＳ、アンドロイド）は、そのＯＳのために作られた特別なポータル・アプリケーションであり、ＯＳに特有の手段（例えば、ｉ−Ｔｕｎｅｓ）によって、機器に配信される。システム・ポータル・アプリケーションは、対象のＯＳプラットフォームそれぞれに対して、モノリシック・バイナリ（monolithic binary）としてパッケージされる。システム・ポータル・アプリケーションを単純に動作させることにより、機器は、システム取得機器、システム提示機器、或いはその両方となる。システム・ポータル・アプリケーションは、また、ＧＨＣ及びウェブ・サーバにおいて使用される。

システム・ポータル・アプリケーションが使用される前に、機器の登録が必要となる。登録は、機器とシステム・ポータル・アプリケーションとの組合せに対して、システム・ドメインにおけるアセット・レコードを作成する。登録は、また、メッセージ・アドレッシングに対して、ドメイン・メッセージ・エクスチェンジ接続ＩＤを割り当て、暗号化されたローカル・ストレージに対して、秘密鍵及びエスクロー金庫を割り当てる。登録は、オフラインで、或いは許可されれば機器に対して直接、実行可能である。外部機器は許可されるが、機器が汚染されていないことを確かめるべく登録が必要とされる。

図３は、一の実施の形態に係るシステム・ポータル・アプリケーションのソフトウェア・アーキテクチャ３００を説明するブロック図である。ポータル・アプリケーションは、ＯＳプロセスとして読み込まれる（ロードされる）モノリシック・アプリケーションである。ポータル・アプリケーションは、必要に応じて、ホスト・システム・アプリケーションに複数の統合臨床エンジン・ブロック（integrated clinical engine block）３２０のインスタンスを作成するポータル・アプリケーション・ベース３１０を含む。

ベース３１０は、ポータル・アプリケーションをオペレーティング・システム３０５の特異性から分離し、起動、記憶及び他のＯＳインタフェースを取り扱うＯＳ抽象化レイヤ（ＯＳＡＬ）３１１を包含する。ＯＳＡＬ３１１は、ＯＳ特有であるポータル・アプリケーションの一部でしかなく、コードの再使用を最大化する。ベース３１０は、また、一の実施の形態では、Ｌｕａプログラミング言語で記述された実行可能なアプリケーションに対して、機能的サポートを提供する複数のライブラリ３１２を含む。ライブラリ３１２は、セキュリティ／暗号化、標準クエリ言語ライト（ＳＱＬｉｔｅ）、ｚｌｉｂ、ユーザ・インタフェース／ユーザ・エクスペリエンス（ＵＩ／ＵＸ）及び他の多岐にわたるライブラリを含む。当業者は、Ｌｕａが、拡張可能意味論（extensive semantics）を考慮して、比較的単純なスクリプト言語として設計された軽量のＯＳに関係なく使えるクロスプラットフォーム・プログラミング言語であることを認識するであろう。ベース３１０には、また、統合臨床エンジン・ブロック３２０においてＬｕａアプリケーション・コードを実行するためのＬｕａエンジン３１３が含まれる。Ｌｕａエンジン３１３は、また、共有コード・ブロックのためのＬｕａチャンク・プール（chunk pool）３１４を取り扱う。ベース３１０は、また、統合臨床エンジン・ブロック・マネジャーを包含し、メッセージ・エクスチェンジ・プロトコル・スタック３１５を完成する。ポータル・アプリケーション・ベース３１０は、基本的に、高機能Ｌｕａホストとして機能し、アクティブ・コードを含まない。

各統合臨床エンジン・ブロック３２０は、システム・アプリケーションを実行するために使用されるサイトとして機能する。システム取得機器及びシステム提示機器は、それぞれ、単一の統合臨床エンジン・ブロック３２０のインスタンスを作成する。ウェブ・サーバは、サーバ毎に様々なＩＤを介する接続ポイントＩＤの特別な処理との動的なウェブ接続毎に、１ブロックのインスタンスを作成する。各ブロック３２０は、各ブロックがクラウドによってシステム機器として「見られる」ように、自身のメッセージ交換接続ポイント３２１を包含する。更に、各ブロックは、自身のＴＣＰ／ＩＰ接続、ログオン及びパーミッションを有する。各ブロック３２０は、更に、独自のＬｕａアプリケーション３２２を複数含む。Ｌｕａアプリケーション３２２は、ブート及びシステム・アプリケーションを含み、ポータル・アプリケーション・ベース３１０のＬｕａエンジン３１３によって実行される。ベース３１０は、ブロック３２０において、Ｌｕａアプリケーション３２２を実行するスレッド・プール（thread pool）を維持する。スレッドは、必要に応じて、Ｌｕａインスタンスにディスパッチ（dispatch）される。Ｌｕａアプリケーション３２２は、イベント駆動型である。全てのＬｕａでないコードは、全てのシステム・ポータル・アプリケーションにわたって同一である。

Ｌｕａブート・アプリケーションは、システム・ポータル・アプリケーションに結び付けられ、機器のタイプ（取得機器或いは提示機器）を定義する。ブート・アプリケーションは、ポータル・アプリケーション・バイナリの内部に送られる唯一のアプリケーションであり、クラウドにログオンし、システム・アプリケーションを読み込むことが唯一の機能である。システム・アプリケーションは、ポータル・アプリケーションの実際の機能を包含し、要望通りにＬｕａアプリケーションを読み込む働きを行う。

Ｌｕａアプリケーションは、オンライン市場で売られ、アセットとして保管される。全てのアプリケーションが、機器のポータル・アプリケーションに配布され、ジャスト・イン・タイム（ＪＩＴ）で読み込まれ、メッセージ・エクスチェンジを介して実行される。Ｌｕａアプリケーションのアップグレードは、アセット・カタログに入れられ、より煩雑なポータル・アプリケーションのアップグレードから切り離される。

図４は、本明細書に係る医療データ情報システムにおける取得機器の初期化動作を示すフローチャートである。ステップ４０２において、予め組み込まれているブート・アプリケーションが、適切な取得機器システム・アプリケーションを読み込む。そして、ステップ４０４において、取得機器システム・アプリケーションが、センサ検出イベントを登録し、適切な初期設定を読み込むことにより、機器を初期化する。ステップ４０６において、新たなセンサが接続され、システム・アプリケーションがセンサ接続イベントを受信すると、システム・アプリケーションは、センサの種類及び型を決定すべく識別のための問合せを行う。システム・アプリケーションは、また、ドメイン内のアセット・カタログに、マッチング・アプリケーション・ドライバの問合せを行い、カタログからドライバを読み込む、或いは、キャッシュされたコピーを使用する。ステップ４０８において、新たなドライバがセンサに接続し、予め設定されたセッティングを初期化し、ディレクトリ内のパラメータを登録する。ステップ４１０において、パラメータ・データがローカルに記録され、サブスクリプションに利用可能となる。これにより、システムがセンサ機器の型を自動的に検出し、その機器に、取得機器、システム・アラーム及び生理学的データ提示とのインタフェースをとらせるべく構成するプラグ・アンド・プレイ機能が備えられる。

メッセージ・エクスチェンジ・プロトコル

本明細書の患者ケアを提供するためのシステムは、ネットワークを介して送信される情報の符号化に、固有のプロトコルを使用する。メッセージがシステム・メッセージ交換プロトコルを介して送信されると、送信機は、業界標準スクリプト言語を用いる小規模なコンピュータ・プログラムとともに、メッセージを送信する。一の実施の形態では、スクリプト言語はＬｕａである。受信機は、メッセージを受信すると、包含されるプログラムを実行し、実行の結果として、所望のデータを受信する。メッセージの実行により、完全に復号化済であり、更なる処理の必要なく、受信機によりすぐに使用可能なデータが、自然に生み出される。メッセージ・エクスチェンジ・プロトコルは、メッセージの実際の内容を標準化するよりも、むしろ、受信機でのメッセージの実行を標準化する。このように動作することにより、メッセージ・エクスチェンジ・プロトコルは、送信機と受信機との間の規約を、メッセージの内容の定義から、メッセージの実行の結果の定義に変更する。

メッセージ・エクスチェンジ・プロトコルは、プログラムの最終実行により予期したデータが生み出される限りは、メッセージの送信時にどのようなプログラムを望んだにせよ、送信機が生成することを可能とすることにより、メッセージの符号化において、より高度な柔軟性を提供する。更に、新たなメッセージの封入は、メッセージの封入に気づいている必要のある受信機がなくても展開可能であり、これにより、送信機及び受信機が同時にアップデートされなければならないという問題を回避する。メッセージ・エクスチェンジは、また、包含されるプログラムがひとたび実行されると、使用可能な形式の最終データを提供することにより、符号化のオーバーヘッド（付帯的コスト；overhead）を取り除く。

一の実施の形態では、メッセージ・エクスチェンジは、自身と各送信機及び受信機との間に暗号化されたリンクを確立する信頼されたセントラル・エクスチェンジである。メッセージ・エクスチェンジと個々の送信機及び受信機との間のリンクは、送信機又は受信機毎に一度のみ確立される必要がある。送信機は、ワン・タイム・キー（ＯＴＫ）で、送信するメッセージをローカルに暗号化する。そして、送信機は、ＯＴＫで暗号化されたメッセージを、メッセージ・エクスチェンジで交換された鍵を用いて送信する。メッセージ・エクスチェンジは、信頼されたエクスチェンジであるため、双方の鍵を知っており、ＯＴＫを復号化した後、受信機のためにＯＴＫを再暗号化することとなる。メッセージ・エクスチェンジは、その後、メッセージと共に、再暗号化されたＯＴＫを受信機へ送信する。一の実施の形態において、記載されたプロトコルは、異なる位置で、複数のエクスチェンジにわたって使用されることが可能である。メッセージ・エクスチェンジは、ただＯＴＫの復号化及び暗号化をしなければならないに過ぎず、メッセージに関しては、そのまま通過させることが可能であるので、結果として、エクスチェンジにおけるオーバーヘッドが低減される。エクスチェンジは、送信機と受信機とが互いに鍵を交換する必要が無い非接続型である。鍵の交換は、信頼されたメッセージ・エクスチェンジにおいてそれによりなされ、送信機或いは受信機毎に一度確立されることが必要とされるのみである。メッセージ鍵は、エンドポイント接続を確立する必要無く、信頼された（二地点間）メッセージ・エクスチェンジ構成を介してなされ、結果として、より効率的なメッセージの転送が可能となる。

一の実施の形態において、送信機は、受領者リストをメッセージのヘッダに埋め込んで、エクスチェンジへ送信する。メッセージ・エクスチェンジは、受領者リストを複製し、全ての意図された受信機へ、メッセージを転送する。メッセージ・エクスチェンジは、全てのメッセージの配布を処理し、送信機には、受領者の数にかかわらずメッセージを一度送信することのみを要求する。これにより、送信機は、消費電力を低減可能となる。更に、受領者リストは各メッセージのヘッダに含まれるので、ルータ動作が処理状態を把握せずとも可能となる。したがって、機器がローミング中に新たなＧＨＣに移動した場合、機器は再同期の必要が無く、新たなＧＨＣへのデータの送信を単純に継続する。サブスクリプション・リストは、各メッセージに付加済である。

送信機からのコードは、受信機で実行されるので、包含されていたプログラムが、受信機の実行領域でいかなる法的行為を実行することも可能である。一の実施の形態では、受領証明の生成は、メッセージに包含されるコードの一部として、データのオリジナルの送信者への受領証明の形成及び生成を含む交換メッセージを送信する送信機によって、達成される。受信機がスクリプトを実行すると、別の交換メッセージが受信機によって形成され、オリジナルのデータ送信者へ送信される。別の実施の形態では、受領証明の収集は、また、データ収集サーバへ送信される。この実施の形態では、送信機によって送信されたスクリプト・プログラムは、送信機に向けた受領証明生成プログラムと、データ収集サーバに向けた別の受領証明生成プログラムとを含む。

したがって、例えばＬｕａ等のスクリプト言語を用いることにより、メッセージ・エクスチェンジ・システムにおけるいかなるメッセージも、自身の配信受領を生成することが可能である。これにより、より高レベルのプロトコルが、メッセージ・エクスチェンジ構成からの追加のサポートの必要なく、自身の配信認証動作を記述可能となる。受領証明は、厳格に維持されるプロトコルを要求しない受信機において複雑な動作を符号化するために送信機と受信機との間で交換メッセージを使用可能な方法の一例である。

システム・メッセージ・エクスチェンジ・プロトコルは、システムにおいて、個々の機器間及び機器とＧＨＣとの間における全ての通信を取り扱う。エクスチェンジは、必要とされる他のネットワーク・プロビジョニング無しで、ＴＣＰ／ＩＰｖ４又はＴＰ／ＩＰｖ６と、ＤＨＣＰとを使用する。メッセージ・エクスチェンジは、単純な単一の接続トポロジー（接続形態）を常にモニタリングし、備える。各機器は、ＧＨＣへの単一のＴＣＰ／ＩＰ接続を維持する。ＧＨＣは、互いに接続し、機器から機器へのメッセージングが非接続型であり、処理状態を把握しないものであるように、スイッチ構成を形成する。全てのファイアウォール接続は、外向きであり、オープン・ポートを必要としない。単純なトポロジーは、低遅延で即座のスイッチングを行う高性能なシステムをもたらす。

各システム・ポータル・アプリケーションの統合臨床エンジン・ブロックは、それぞれ、ＧＨＣに実際のＴＣＰ／ＩＰ接続を提供する接続ポイントとして機能する。切断／再接続及びサブネットへの移行は、他のアプリケーションに対して透過的である。接続ポイントの識別は、機器及びポータル・アプリケーションがシステムに登録された時に、確立される。一般的に、単一の機器は、システムと単一の接続となるように、一つの統合臨床エンジン・ブロックを有する一つのポータル・アプリケーションを含む。接続ポイントは、各統合臨床エンジン・ブロックにおいて、全てのアプリケーションに対する全てのメッセージを取り扱う。

メッセージのエンドポイントは、常にアプリケーションである。固有のエンドポイントは、ドメインＩＤ、接続ポイントＩＤ及びアプリケーションＩＤを含む。したがって、各統合臨床エンジン・ブロックは、動作中のアプリケーションの一つにインスタンスを有することのみが可能である。一の実施の形態において、ローカルＧＨＣ上に常に存在するドメイン・カタログについては、特例が有る。周知のサービスが、専用の多形の（polymorphic）接続ポイントＩＤに対してマッピングされる。一の実施の形態では、アプリケーションは、ＧＨＣにサービスを登録可能である。ここで、サービスは、メッセージの内容及び順序を示すグローバルＩＤである。

図５は、一の実施の形態における二つのアプリケーション間での例示的なメッセージ交換動作を説明するフロー図である。統合臨床エンジン・ブロック１ ５３０内において、アプリケーションＡＰＰ１ ５３５は、アプリケーションＡＰＰ４ ５６５に対するメッセージを作成し、ステップ５０５において、当該メッセージを、メッセージ・エクスチェンジ接続ポイントＣＰ１ ５３２へ送信する。アプリケーションＡＰＰ１ ５３５は、メッセージ・エクスチェンジの第１エンドポイントＥＰ１であり、アプリケーションＡＰＰ４ ５６５は、メッセージ・エクスチェンジの第２エンドポイントＥＰ２である。ターゲット・アプリケーションＡＰＰ４ ５６５は、統合臨床エンジン・ブロック２ ５６０内において、メッセージ・エクスチェンジ接続ポイントＣＰ２ ５６２の第２エンドポイントＥＰ２にアドレスを指定される。ＣＰ１ ５３２におけるメッセージ・エクスチェンジ・スタックは、メッセージをセグメントに分割し、ステップ５１０において、メッセージ・セグメントをＧＨＣ１ ５４０へ送信する。ＧＨＣ１ ５４０は、ディレクトリをチェックし、ＣＰ２ ５６２をＧＨＣ２ ５５０上に配置する。ステップ５１５において、ＧＨＣ１ ５４０は、メッセージ・セグメントをＧＨＣ２ ５５０へ送信する。ＧＨＣ２ ５５０は、メッセージ・セグメントを受信し、ステップ５２０において、それらをＣＰ２ ５６２へ直接送信する。ＣＰ２ ５８２におけるメッセージ・エクスチェンジ・スタックは、セグメントを受信し、メッセージを再構築する。ステップ５２５において、ＣＰ２ ５６２は、メッセージをターゲット・アプリケーションＡＰＰ４ ５６５へ送信する。また、図５に示されるように、集積回路エンジン・ブロック１ ５３０内のアプリケーションＡＰＰ２ ５３７及び集積回路ブロック２ ５６０内のアプリケーションＡＰＰ３ ５６７は、ＣＰ１ ５３２及びＣＰ２ ５６２を介して接続される追加のメッセージ・エクスチェンジ・エンドポイントを表す。

全てのメッセージは、送信のために、セグメントに分割され、圧縮され、暗号化される。全てのメッセージの取り扱いは、各エンドにおいて、接続ポイントによって実行される。ＧＨＣは、不明瞭なデータを単純に切り替える。より小さなメッセージ・セグメントを送信することにより、ＧＨＣ内でのより効率的な切り替えが可能となり、優先度の低い大きなメッセージにより、より優先度の高いメッセージがブロックされることを防止する。セグメントは、第１エンドポイントから送信され、少なくとも一つのＧＨＣを通過して、第２エンドポイントへ送信される。セグメントが一つのＧＨＣから別のＧＨＣへ渡り歩くうちに、セグメント・ヘッダのみが暗号化され、復号化される。セグメントは、最適なネットワーク構成に組み立てられ、より速いルーティングを行うべく、ターゲットＧＨＣで特徴づけられる。

一の実施の形態では、交換メッセージ・セグメントをルーティングするＧＨＣは、加重メトリックを用いて、最良の或いは最速のルートを算出及び選択するコスト・ベース・ルーティング・アルゴリズムを用いる。メトリックは、実際の使用中に、リンク性能を直接測定することにより、自動的に算出される。初期設定やチューニングの必要は無い。ルーティング・プロトコルは、不必要なクラウド・コストを避けるために、潜在するネットワークの混雑、機能停止及び変更に対し、動的に対処する一方、ネットワーク障害の際には、クラウド全体の代替システムの維持も行う。動作中は、ＧＨＣは、ルーティング・コスト・メトリックを交換し、データ転送量を自動的に平衡化する。実際のリンク性能の直接測定に対処することにより、システムは、セグメントを効率的にルーティングするとともに、帯域幅の使用量を最小限にする。

一の実施の形態において、本明細書の患者ケアを提供するためのシステムは、データを妥当なサイズのメッセージに「束ね」て、一定量のデータの送信に使用される電力を最小限にする。データをより大きなメッセージに「束ね」ることにより、メッセージの生成時とその受信機への送信時との間の遅れの増大を生み出すが、送信機からの電力を低減する。病院における多数の送信機は、モバイル機器たり得るため、メッセージを「束ね」ることは、バッテリーの寿命を延ばすことに役立つ。送信機器によって継続的に取得されるデータの例は、ＥＣＧ（心電図）、血圧及びパルス・オキシメトリ（血中酸素濃度）波形を含む。急を要さない状況では、このデータは、電力の保存のため、互いに「束ね」て送信することが可能である。例えば命にかかわる臨床アラームや重大なシステム・メッセージ等の緊急のメッセージは、個々に且つ即時に送信されることとなる。

メッセージは、システム・アプリケーションによって生成されるので、これらはコントロール・ポイント（ＮＣＰ）で列をつくる。待ち行列処理の一部は、メッセージの優先度の決定を含む。例えば、一の実施の形態では、メッセージは、システム、緊急、高優先度、中優先度及び低優先度と分類され、最高優先度のメッセージが最初に送信される。帯域幅の留保は、低優先度のメッセージの窮乏を防ぐ。特定のアプリケーションからの急を要さないメッセージは、早期のＩＰバッファ掃き出しの原因となる緊急且つ高優先度のメッセージとともに、常に順に送信される。一の実施の形態では、「バックグラウンド・オプション」は、システムが次のグループの「束ね」られたメッセージを送信するまで、低優先度のメッセージを引き延ばす。システムが「束ねられたメッセージ」のグループを送信する各インスタンスは、システムの「心臓の鼓動」と呼ばれる。一の実施の形態では、「心臓の鼓動」は、低周波（０．５から１０Ｈｚ）で生じる。

一の実施の形態では、システムは、複数のサブスクライバ（加入者）又は受信機によって使用されることを意図したデータが、ソース機器又は送信機によって一度のみ生成されることを保証するパブリケーション及びサブスクリプション（Ｐｕｂ／Ｓｕｂ）機構を実装する。例えば、システムで使用されるモバイル・モニタリング機器では、機器が取得したデータを複数の消費者が有することは珍しくない。代表的なモバイル・モニタは、同一の患者を異なる機器（そのうちいくつかは持ち運び可能である）でモニタリングする複数のケア提供者（看護師、管理する看護師、医師）によって使用されるアラーム及び生命に関するデータを、生成しても良い。更に、生命に関するデータ、リアル・タイムの波形及び動向は、ネットワークに接続されたベッドサイド・モニタ及びセントラル・モニタで、継続的に表示されても良い。

この実施例では、各ケア提供者の機器（及び接続されたユニット）は、モバイル・モニタによって生成されるデータへのアクティブ・サブスクリプションを有するであろう。この場合、モバイル・モニタは、機器から、最も近いＧＨＣへ、モニタリングするデータを一度に送信する。送信されるメッセージは、機器のデータの全ての受領者のアドレスを含む。ＧＨＣは、アドレスのリストを読み取り、重複したデータが全ての受領者へ送信されることを保証することとなる。

ソース機器におけるＣＰは、データに対してアクティブな全てのサブスクリプションをモニタリングし、各サブスクライバに対するルーティング情報が、ＧＨＣへ送信される単一のメッセージ・パケットに含まれることを保証することとなる。データは、ＧＨＣによって受信されると、サブスクライブする機器それぞれに向けての新しいメッセージを生成することとなる。なお、ＧＨＣは、高速ネットワーク接続に壁面コンセントで配線接続されるので、この時点でのデータの複製は、もはや「高価」ではない。

メッセージ・エクスチェンジ・プロトコルは、低出力機器に対して最適化される。一の実施の形態において、出力フローの制御は、電力の制限のない機器では不必要であるため、任意に選択される。バックグラウンド・オプションは、転送量を減少させ、メッセージを一気に送信することにより、ＷｉＦｉ無線の使用を最適化する。更に、パブリッシュ／サブスクライブ（Ｐｕｂ／Ｓｕｂ）データは、機器から一度のみ送信される。ＷｉＦｉ転送量の総量を減らすことにより、機器のバッテリー寿命を改善し、ネットワークの負荷を低減する。「心臓の鼓動」は、接続がダウンした際に警報を処理し、また、状況、メトリック、ストール・リスト及び位置／存在のアップデートを送信する。

図６は、本明細書の医療データ情報システムにおける一組のアプリケーションからのメッセージのフローの一の実施の形態を説明するフロー図である。ステップ６０５では、アプリケーションＡＰＰ１ ６３０及びアプリケーションＡＰＰ２ ６４０は、それぞれ、別のアプリケーション（不図示）に配信するために、メッセージ・エクスチェンジ・スタック／接続ポイント６５０へメッセージを送信する。メッセージ・エクスチェンジ６５２は、生成された鍵を用いて、各メッセージを個別に圧縮及び暗号化する。そして、メッセージ・エクスチェンジ６５２は、各メッセージをセグメントに分割し、セグメントを封入する。その後、ステップ６１０において、メッセージ・エクスチェンジ６５２は、封入されたセグメントを、接続ポイント待ち行列６５３へ送信する。メッセージのセグメントは、そして、優先度が決められ、バックグラウンド・メッセージが次の「心臓の鼓動」まで保留される。セグメントのヘッダは暗号化され、セグメントは互いに連結される。ステップ６１５では、連結されたセグメントが、ＯＳ ＴＣＰ／ＩＰスタック６６０へ送信される。ここから、セグメントは、ステップ６２０において、ネットワーク６７０へ送信され、ルーティングのために接続されたＧＨＣへ送信される。

パブリッシュ／サブスクライブ（Ｐｕｂ／Ｓｕｂ）は、統合臨床エンジン・ブロックの接続ポイントで取り扱われるサービス規約であり、したがって、全てのアプリケーションによって共有される。接続ポイントは、サブスクライバ・リストの記録を取り扱い、サブスクライバのエンドポイントのリストによってパブリッシュ・メッセージを拡張する。接続ポイントは、メッセージのセグメントを、サブスクライバ・リストとともに、ＧＨＣへ一度のみ送信する。そして、ＧＨＣは、全てのサブスクライバに届くように、必要に応じてセグメントを分岐させる。このメッセージ・セグメントのルーティングは、ネットワーク・トラフィックと、パブリッシャにおける電池の消耗とを、最小限にする。必要な時には、サブスクライバは、パブリッシャがサブスクリプションを維持しないので、サブスクリプションを再度確立しなければならない。サブスクライバは、パブリッシャがサブスクリプションの孤立を回避するために消えた場合、再度サブスクライブしなければならない。

メッセージ・エクスチェンジのディレクトリは、各ＧＨＣによって保持されるイン・メモリ・データベースであり、ＳＱＬｉｔｅによって、何百万というエントリーと同じ規模で支持される。一の実施の形態では、ディレクトリは、ドメインにおいて、２〜５秒以内に、全てのＧＨＣにわたり複製する。複製のトリガ（ダーティ・フラグ）は、「心臓の鼓動」にピギーバック（便乗）する。一の実施の形態では、ディレクトリは、全ての機器、エンドポイント及びサービスのレジストリを含み、また、機器の位置を維持する。機器の位置の決定は、ケア提供者が患者を探す際の助けとなり得る。一の実施の形態では、最後に知られた位置は、また、機器がフラッシュされる際に、アセット・カタログに維持される。ディレクトリは、また、サード・パーティ機器の発見に拡張される。

一の実施の形態において、エクスチェンジを介して送信されたメッセージの大部分が、Ｌｕａソース・コードとして送信される。Ｌｕａの使用は、ネットワーク及びポータル・アプリケーションにわたって制御が維持されるので、安全である。Ｌｕａソース・コード化は、単純なメッセージの復号化を提供する。例えば、一の実施の形態では、ユーザは、メッセージの内容に「loadstring()」をコールして、値を得ることができる。更に、Ｌｕａの構文解析ツールがデータセットに対して最適化されるので（タブレットで、３００＞ｓｅｃ）、Ｌｕａソース・コード化は、より速いシステムを提供する。Ｌｕａソース・コードの使用は、厳格に固定されたフォーマットのメッセージを取り除き、受領及び実行されたメッセージの効果に規約を基づかせることにより、メッセージ・サービス規約の枠組みを変更する。メッセージの受領証明は、メッセージにコードを付加することにより生成される。

患者セッション及び臨床データ

本明細書の医療データ情報システムでは、患者セッションは、患者から収集された全ての臨床データの入れ物である。各セッションは、患者データを収集する際に、システム取得機器によって作成される。更に、各セッションは、グローバル一意識別子（ＧＵＩＤ）によって、機器毎に識別される。セッションは、かつて付加されたのみであるように、累積的に不変である。一の実施の形態では、各セッションは、宙ぶらりんのセッションを避けるべく、一時間の「ストリップ（帯）」に分割される。セッションは、それ自体、アノニマス（匿名）であり、保険医療情報（ＰＨＩ）を含まない。各セッション内のデータは、決定的であり、全てのデータを含み、デジタル・ビデオ・レコーダのように再生が可能である。更に、一の実施の形態では、各セッションは、全ての臨床データ及びアラームと、設定変更と、誰が変更したかの記録とを含む。

一の実施の形態では、セッションはシステム取得機器に由来し、ＧＨＣで記憶され、配布される。ＧＨＣは、複製プロトコルを用いて、全てのセッション・ストリップを収集する。複製の遅れは、レトロスペクティブ・データが迅速に分析に利用可能となるように、一般的に数秒のみとなっている。一の実施の形態では、クラウドＧＨＣは、要求に応じてセッション・ストリップの収集のみを行う。

患者のセッションとの関連付けは、セッションのライフタイム（存続期間）から切り離される。新しいセッションは、入力しなくても、患者に対して作成可能であり、関連付けは、セッション開始時、セッション中及びセッション後になされることが可能である。例えばボイス・ノートなどの「ブレッドクラム」は、セッション関連付けの助けとなる。一の実施の形態では、期間に対する注釈は、患者記録に残される。一の実施の形態では、注釈は、手動或いは合成（例えば、アラームから生成される）が可能である。セッションのアーカイビング及び記憶の観点から、一の実施の形態では、基本的な保有期間後に、セッションはトリミングが可能である。一の実施の形態では、セッションのトリミングは、アラームが無く、注釈の無い波形データの廃棄を伴う。トリミングされたセッションは、クラウドへ移行され、ＧＨＣから取り除かれる。トリミングされたセッションのクラウドへの移動により、顧客がストレージに対して、どのくらいの期間、支払を行うかの決定次第で、原則的に無限のストレージを提供する。

アラーム・ルーティング及びアラーム・クエンチング

一の実施の形態において、本明細書の患者ケアを提供するためのシステムは、患者及びケア提供者双方の位置及び存在情報に基づくアラーム・プライオリティ・ルーティングの方法を提供する。一の実施の形態において、アラーム・プライオリティ・ルーティングの方法は、２０１１年１１月１８日に出願され、本発明の出願人に譲渡された「患者モニタリング・システムにおける最初のアラーム通知を伝達するシステム及び方法」と題された米国特許出願第１３/３００，４３４号に開示されたものと同様であり、全て、参照として、本明細書に取り込まれている。

一の実施の形態において、本明細書のシステムは、最も近接した対応可能な応答者に最初のアラームをルーティングすることにより、アラームとケア提供者からの応答との間に要する時間を最小限にする。一の例示的な実施の形態では、第１のケア提供者が、患者に対応可能なオペレータとして指定される（前記患者に対して直接対応可能である）。第１のケア提供者は、彼又は彼女のモバイル・アラーム表示機器に、患者に対するアラームを受信させる。患者に対する重大なアラームは、モバイル機器でアナウンスする。第１のケア提供者は、モバイル機器のディスプレイを見て、患者がまだ病床（ベッド）にいること及び第２のケア提供者（オペレータ）が既に患者のベッドサイドにいることを決定する。第１のケア提供者は、モバイル機器のディスプレイ上の第２のケア提供者の名前を押圧し、状況を評価するために、第２のケア提供者との間での双方向音声通信を即座に行う。

別の例示的な実施の形態では、遠く離れた患者が、病棟を離れて散歩に出掛ける。病棟の外に出た際に、患者が心停止となり倒れる。患者が装着する遠隔モニタは、高優先度アラーム（ハイ・プライオリティ・アラーム）を発する。本明細書のシステムは、患者の物理的位置の知識に基づき、遠く離れた病棟にいる患者に対応可能なオペレータに警告するとともに、患者の現在位置により近い位置にいる更に２人のオペレータに支援を警告する。システムは、更に、状況が解決されるまで、３人のケア提供者全てを、彼らのモバイル機器を介して通信可能とする。

別の実施の形態において、システムは機器警報を含み、特定のアラームが、予め選択されたケア提供者によって持ち運ばれる手持ちの機器に配信される。例えば、システムは、ＩＣＵ／ＣＣＵ内の医師又は看護師のＰＤＡに警報を送信可能である。所定の組合せの分散したケア提供者が、優先度アラーム（プライオリティ・アラーム）を受信することとなる。この選択的な通知は、ネットワーク上の全ての人が警告を受けるわけではないことを意味する。例えば、ケア提供者が病室５にいる場合、システムは、そのケア提供者を対象にアラームを送ることができる。ケア提供者の位置通知は、個別のスキルの組合せを特定することも可能である。一の実施の形態では、応答を確保するために、全ての警告を通知されるマスタ・ディスパッチャ（発送者）が存在する。選択されたケア提供者を警告の対象とすること及び当該ケア提供者に警告を割り当てることは、最も適切なケア提供者がまず警告を受信することを確保することにより、システムの応答効率を高める。

一の実施の形態では、本明細書の患者ケアを提供するためのシステムは、また、分散型の且つケア提供者チーム向けのアラームを管理する方法を提供する。提供された方法は、アラームを黙らせる或いは「クエンチする（quench）」。患者につなげられた機器により、アラーム状態が検出されると、システムは、患者に適切なケア提供者に、アラーム状態が発生していることを通知することとなる。アラーム・メッセージを受信し、そのようにするための適切な権利を有するオペレータの何れかが、アラームを「クエンチする」ことができる。オペレータによりアラームをクエンチすること（クエンチング）が、現在アラーム情報を表示している全ての機器を、機器を黙らせる、或いは、従来のアラーム応答動作と同じ振る舞いをする「クエンチ状態」に変更する。クエンチ動作は、アラーム状態が観測されたこと及び権限を有するオペレータが適切な行動をとったことを、他のオペレータに示唆する。

一の実施の形態において、「アラームがクエンチされた」状態は、患者に関連づけられる全ての取得機器に適用され、タイムアウト時間が経過するまで、或いは、クエンチされたアラームよりもより優先度の高い新たなアラーム状態が検出されるまで、維持されることとなる。これらの状態の何れかが発生した場合、アラームがクエンチされた状態は消去され、アラーム表示機器は、全て、現在のアラーム状態の組合せに対し、必要に応じて、全てのアラーム信号を表示する。

一の実施の形態では、既にアラームがクエンチされた状態にある時に、クエンチを起動することは、タイムアウトをリセットするとともに、現在存在するアラーム状態の組合せに基づきアラームをクエンチする優先度をリセットすることとなる。一の実施の形態では、何れのオペレータも、アラームがクエンチされた状態をキャンセルする能力及び全てのアラーム表示機器に全アラーム機能を回復させる能力を有する。

オプション機能

様々な実施の形態において、本明細書の患者ケアを提供するためのシステムは、更に、以下のオプション機能の何れか一つ或いは組合せを含む。

一の実施の形態において、システムの表示機器は、波形の対数表示を提供可能である。波形表示の左右の遠端で時間スケールを対数圧縮することにより、システムは、ユーザに、追加のデータを利用可能とする。ケア提供者は、これらのエリアを普通に「スワイプ」して、波形の中央部が中心となるようデータを移動させることができる。ケア提供者は、また、更に詳細に見直したい波形の一部を配置した後、データの線形表示に切り替えることも可能である。

一の実施の形態において、システム機器は、従来の「ゴーン」となるアラーム音に加えて、音声アラームを含む。例えば、ケア提供者が装着したヘッドセットに追加された音声合成が、アラームの要因、患者の位置（例えば、病室、手術室等）及び患者の名前を含む更なるアラームの詳細を提供する。

一の実施の形態において、システム機器は、退院患者のため又は外来診療のための外来患者ケア・レジメンを提供する。患者が外来患者ケアのためのモニタリング機器を自宅に持ち帰ると、機器は、従来は退院時に口頭でなされていた読みやすい外来説明書、内蔵のカレンダー・リマインダー、処方薬のクイック・レスポンス（ＱＲ）コードをスキャンして投薬計画を点検する能力を含む投薬計画及び他の同様の役割を含むケアに対する更なる支援を提供可能となる。

一の実施の形態では、ＱＲコード（登録商標）は、位置サービスを助けるために使用される。例えばＷｉ−Ｆｉ三角測量や近距離無線通信（ＮＦＣ）等の先進技術に加えて、ＱＲコード（登録商標）の簡単な印刷及びドアの隣へのそれらの貼付により、新興成長市場に特に適用可能な安価な位置把握の方法が提供される。ケア提供者機器におけるカメラは、コードを素早くスナップ写真に撮影し、位置把握を提供するために使用される。

一の実施の形態において、システムは、患者情報と患者及び家族のためのエンターテインメントとの双方を提供するための高性能壁掛け式ディスプレイを含む。患者の病室の表示機器は、ケア提供者がいない時には、エンターテインメント・ハブとして動作するが、ケア提供者が病室に入るとすぐに、患者ケア情報を提供すべく自動的に切り替わる。一の実施の形態では、システムは、デュアル・ディスプレイ構成を提供する。このデュアル・ディスプレイ構成は、２０１１年３月２１日に出願され、本発明の出願人に譲渡された、「マルチ−ディスプレイ・ベッドサイド・モニタリング・システム」と題される米国特許出願第１３／０５２，８８３号に記載され、全て、参照として本明細書に取り込まれている。

システムは、患者のベッドサイドに設置され、患者のリアル・タイムの生命に関する統計値と共に患者に関する集約された医療情報を提供可能なデュアル・ディスプレイ・モニタを提供する。二つのディスプレイのうち一方のディスプレイは、リアル・タイムの患者のモニタリング情報を継続的に表示し、他方のディスプレイは、例えば薬が届けられた時等の情報の表示や、生命兆候（バイタル・サイン）に関連した検査結果の表示、及び、一般的に独立したデータ端末を介するアクセスのみが可能な他のリモートの病院アプリケーションへのアクセスの提供のために使用される。デュアル・ディスプレイ・モニタは、病院情報システムに接続され、ローカル・ソフトウェア・アプリケーション及びリモート・ソフトウェア・アプリケーションを、例えばＣｉｔｒｉｘ（登録商標）によって利用可能とされるソフトウェア等のリモート・ディスプレイ・ソフトウェアを介して表示することが可能である。更に、デュアル・ディスプレイ・モニタは、追加ディスプレイを四つまで増設可能なセントラル・モニタ構成に接続可能である。これらの追加ディスプレイは、より多くの患者をモニタリングすることや、追加データを表示すること及び／又は他のアプリケーションをホスティングすることのために使用可能である。

また、更なる実施の形態では、デュアル・ディスプレイ・モニタでアクセスされるローカル及びリモートのソフトウェア・アプリケーションは、また、患者をモニタリングする機能の提供にのみ関連するアプリケーションの他にも、アプリケーションを含む。例えば、エンターテインメント・アプリケーション；インターネット或いは他のネットワーク接続アプリケーション；又は患者教育アプリケーション、電子メール或いはビデオ会議アプリケーション、当業者には明白な付加価値の有る他のアプリケーション等が、このようなソフトウェアに相当する。

一の実施の形態において、デュアル・ディスプレイ・モニタは、患者モード或いはケア提供者モードの何れかで、使用可能である。患者モードでは、臨床設定は変更不可であるが、例えばエンターテインメント又は患者教育等、承認されたソフトウェア・アプリケーションの管理リストを実行することは可能である。モニタは、ケア提供者が病室内にいる場合以外は、患者モードである。このように、例えば、患者が付き添う人のいない病室にいる場合、モニタは一般的に患者モードとなる。このモードは、ケア提供者によってリモートで変更可能である。ケア提供者モードに変更するためには、モニタは、認証情報、パスワード又はＲＦＩＤバッジを要求することが可能である。一の実施の形態では、患者モードを、操作状況に合わせて無効化或いは最小限化することが可能である。このように、臨床状況が変化する場合（例えば、一定のアラーム・クラス（高優先度））、患者のアプリケーションは、ケア提供者によってクリアされるまで、無効化或いは最小限化される。これは、ケア提供者によって、アラーム・タイプ又はアラーム・クラスに応じて、設定変更可能であることが望ましい。

一の実施の形態では、システムは、機器間でのデータの収集を向上及び効率化するプラグ・アンド・ユーズ・アルゴリズム・カスケードを提供する。センサが機器に接続されると、適切なドライバ・アプリケーションの読み込みが開始される。このドライバは、続いて、機器から臨床データをパブリッシュする。このデータは、別のドライバ・アプリケーションに更なるデータの処理を実施させる仮想センサとして具現化され、これにより、必要に応じてドライバ読み込みの「カスケード」が引き起こされる。これにより、高性能のアラーム・ドライバが読み込まれ、複数の装置からデータを収集することが可能となる。

一の実施の形態では、システムは、明確な入力及び出力で、機能ブロックとして医療データ・アルゴリズムを記述することにより、自己集合性カスケーディング医療データ・フローを提供する。特定の出力が望まれる場合、メタデータを用いて入力と出力とを逆の（消費者が提供する）カスケードで接続することにより、その組み合わせのブロックが自己集合可能である。これは、リアル・タイム・データ及びレトロスペクティブ分析の双方に適用可能である。更に、利用可能な出力の組は、利用可能な未加工の入力及びアルゴリズム置換から、容易に算出される。

一の実施の形態において、システム機器は、アラーム表示機器として動作可能であるか否かを自己診断可能である。様々な実施の形態において、全ての機器がアラーム表示機器として動作可能なわけではない。機器がユーザビリティ要求を満たすために、充分大きな可聴音を生成する能力又は充分大きなメッセージを視覚的に表示する能力には、制約が有り得る。自己診断は、機器にインストールされたアプリケーションによって実施され、結果は、機器がアラーム表示機器として動作可能であるかを判定するために、システムによって使用される。

一の実施の形態では、患者が病院に滞在中はいつでも、何れのケア提供者によってもアクセス可能となるように、システムは、単一のファイルに患者のデータを集約及び記憶する手段を提供する。一の実施の形態では、この手段は、６４人までの患者のデータをリアル・タイム・リモート画面で表示可能な単一のＰＣをベースとする機器を含む。機器は、また、表示を改善するために、四つの追加ディスプレイを結合可能である。

機器は、患者データをレトロスペクティブ・ベースで（過去に遡って）提示するための堅固なユーザ・インタフェースを含む。機器は、あたかもデータが機器に埋め込まれたかのように、患者のデータを全て表示するための集中管理リモート・ステーションとして機能する。ケア提供者は、いつでも何れの位置からも臨床データを閲覧できる。

更に、一の実施の形態において、機器は、患者記録管理及びセッション記録の形式で、患者の関連付け及び識別を提供する。従来の患者モニタリング・システムでは、データの保管（ストレージ）は、患者主体というよりも、機器が主体であった。それ自体は、患者の退院後においても、患者データが病室内の機器にまだ存在する可能性を示す。更に、従来のシステムでは、診療記録番号（ＭＲＮ）及び識別番号が混同され得る。患者記録管理とセッション記録とを合併することにより、データ・フローが停止しようとも、新しいセッションが開始され、関連付けが再度行われる。各患者は、電子シリアル番号に関連付けられる。したがって、患者が一のモニタリング機器から切り離され、他のモニタリング機器に再接続された場合、当該患者は、新たな機器に再度関連付けられる。一の実施の形態では、様々な機器からの全ての患者データが全体として表示可能となるべく、セッションは統合可能である。

患者は、多数の関連付け方法を介して、異なるモニタリング機器に関連付け可能である。様々な実施の形態では、これらは、自動網膜走査、患者の生体認証及びセンサ・ベース認証を含む。例えば、関連付けは、ＤＮＡサンプルの収集及び解析、指紋分析、或いは他のいくつかの非侵襲的手段によって達成される。それぞれの関連付けの方法は、患者を識別し、機器及び機器からのデータ記録と患者とを調整する。特定の機器と一人の患者との関連付けは、ひとたび確立されると常に存在し、重複した関連付けが確立される問題は決して起こらない。これは、また、ＲＦＩＤブレスレットが壊れた際に生じる機器−患者関連付けの喪失の問題を回避する。

別の実施の形態では、各患者は、ケア提供者間で行き来し、患者のケアの間いつでも通知される必要があるタグ或いはランヤードによって、機器と関連付けられる。

一の実施の形態では、システムは、また、ケア提供者機器及び患者データ間の関連付けを提供する。各ケア提供者は、その人物が何を望むかに基づき、手持ちの機器上のディスプレイをカスタマイズ可能である。上記した実施の形態は、本発明のシステムの多くの用途の例示に過ぎない。ここでは、本発明の実施の形態のいくつかを記載したに過ぎず、本発明は、発明の精神及び範囲を逸脱しない範囲で、様々な他の特別な形態で具体化され得ることを理解すべきである。したがって、本実施の形態及び実施例は、例示に過ぎず、これらに限定されるものではない。本発明は、添付の請求項の範囲内で変更が可能である。

Claims (20)

1. 患者ケアを提供するためのシステムであって、
   ａ． 揮発性又は不揮発性であり、コンピュータに読み込み可能な第１の媒体を有し、波動を伝送するための伝送媒体を含まない第１のコンピュータ・デバイスと、
   ｂ． 揮発性又は不揮発性であり、コンピュータに読み込み可能な第２の媒体を有し、波動を伝送するための伝送媒体を含まない第２のコンピュータ・デバイスと、
   ｃ． 揮発性又は不揮発性であり、コンピュータに読み込み可能な第３の媒体を有し、波動を伝送するための伝送媒体を含まない少なくとも一つのターゲット・コンピュータ・デバイスと、を備え、
   前記第１の媒体は、前記第１のコンピュータ・デバイスによって実行されると、
   ａ１． 標準スクリプト言語を用いて実行可能なプログラムを暗号化し、暗号化された前記プログラムをメッセージのヘッダに添付し、
   ａ２． 前記メッセージを、無線接続を介して、前記第１のコンピュータ・デバイスから前記第２のコンピュータ・デバイスへ送信する、複数の第１のプログラム指令を備え、
   前記第２の媒体は、前記第２のコンピュータ・デバイスによって実行されると、
   ｂ１． 前記第１のコンピュータ・デバイスから前記メッセージを受信し、
   ｂ２． 前記メッセージから、前記メッセージの受信用である少なくとも一つのターゲット・コンピュータ・デバイスを決定し、
   ｂ３． 前記メッセージを、無線接続を介して、前記第２のコンピュータ・デバイスから前記少なくとも一つのターゲット・コンピュータ・デバイスへ送信する、複数の第２のプログラム指令を備え、
   前記第３の媒体は、第３のコンピュータ・デバイスによって実行されると、
   ｃ１． 前記第２のコンピュータ・デバイスから前記メッセージを受信し、
   ｃ２． 前記実行可能なプログラムを復号化し、
   ｃ３． 前記実行可能なプログラムを実行することにより、前記メッセージを受信する、複数の第３のプログラム指令を備え、
   前記第２のコンピュータ・デバイスは、クラウド・ベース・コンピュータ・デバイスであることを特徴とする患者ケアを提供するためのシステム。
2. 患者ケアを提供するためのシステムであって、
   ａ． 患者の少なくとも一つのパラメータを検出し、報告する少なくとも一つの検出機器と、
   ｂ． 前記少なくとも一つの検出機器と結合し、前記少なくとも一つの検出機器から電子患者データを受信するとともに、前記患者データを記憶可能なメモリを含む少なくとも一つの取得機器と、
   ｃ． 前記少なくとも一つの取得機器と結合し、前記取得機器から前記患者データを受信するための少なくとも一つのネットワーク・アプライアンスと、
   ｄ． クラウド・コンピューティングを提供するためのネットワークであり、前記少なくとも一つのネットワーク・アプライアンスが結合し、前記患者データが全てのネットワーク機器にわたってアクセス可能となるように、前記患者データを記憶するためのデータベースを含むネットワークと、
   ｅ． 前記ネットワークと結合し、前記患者データにアクセスし、グラフィカル・ユーザ・インタフェース上で前記患者データを表示するための少なくとも一つの提示機器と、
   を備え、
   前記電子患者データの前記ネットワークを介する送信は、標準スクリプト言語を用いて実行可能なプログラムを符号化することによる前記患者データの暗号化と、前記患者データを含むメッセージへの前記プログラムの添付と、を含むことを特徴とする患者ケアを提供するためのシステム。
3. 前記ネットワーク・アプライアンスは、患者の近傍に配置されることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
4. 前記ネットワーク・アプライアンスは、患者から離れて配置されることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
5. 前記少なくとも一つの検出機器は、前記少なくとも一つの取得機器に有線接続を介して結合されることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
6. 前記少なくとも一つの検出機器は、前記少なくとも一つの取得機器に無線接続を介して結合されることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
7. 前記少なくとも一つの検出機器及び前記少なくとも一つの取得機器は、３Ｇ／４Ｇ接続を介してネットワークに接続可能であることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
8. 前記標準スクリプト言語は、Ｌｕａであることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
9. 前記提示機器は、従来のＰＣ、タブレット、スマートフォン及び壁掛け式ディスプレイの何れか一つを備えることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
10. 前記取得機器は、更に、提示機器として機能することを特徴とする請求項２記載の患者ケアを提供するためのシステム。
11. 前記取得機器は、前記患者に対する全ての臨床データを複製して、前記メモリに記憶し、システム障害の場合、独立型のモニタとして機能することを特徴とする請求項２記載の患者ケアを提供するためのシステム。
12. 前記取得機器は、ケア提供者設備における固定機器であることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
13. 前記取得機器は、退院した前記患者とともに及び外来診療のために残るモバイル機器であることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
14. 実際の使用中におけるネットワーク性能を直接測定することにより最も効率的なメッセージ経路を算出するコスト・ベース・ルーティング・アルゴリズムを更に含むことを特徴とする請求項２記載の患者ケアを提供するためのシステム。
15. 前記患者及びケア提供者双方の位置及び存在情報に基づき、アラーム優先度をルーティングするアラーム・ルーティング・プロトコルを更に含むことを特徴とする請求項２記載の患者ケアを提供するためのシステム。
16. ケア提供者が、前記患者に割り当てられたすべての機器に対し、可聴アラームの消音又は音量を下げることができることを特徴とする請求項２記載の患者ケアを提供するためのシステム。
17. エクスチェンジと各メッセージ送信機及び受信機との間で、機器毎に一度暗号化されたリンクを確立する信頼されたセントラル・メッセージ・エクスチェンジを更に含むことを特徴とする請求項２記載の患者ケアを提供するためのシステム。
18. 前記セントラル・メッセージ・エクスチェンジは、定期的に送信される急を要さないメッセージをひとまとめにすることを特徴とする請求項１７記載の患者ケアを提供するためのシステム。
19. 前記メッセージ送信機は、各メッセージを一度のみ送信し、前記セントラル・メッセージ・エクスチェンジは、各メッセージを複製して、前記メッセージのヘッダに含まれるサブスクリプション・リストに基づき、複数の受領者へ送信することを特徴とする請求項１７記載の患者ケアを提供するためのシステム。
20. 患者ケアを提供するための方法であって、
    ａ． 患者ケア・システムを提供するステップであって、
    ｉ． 少なくとも一つの患者の生理学的パラメータを検出し、報告する少なくとも一つの検出機器と、
    ｉｉ． 前記少なくとも一つの検出機器に結合する少なくとも一つの取得機器であって、前記少なくとも一つの検出機器から電子患者データを受信するとともに、前記患者データを記憶可能なメモリを含む取得機器と、
    ｉｉｉ． 前記少なくとも一つの取得機器に結合する少なくとも一つのネットワーク・アプライアンスであって、前記取得機器から前記患者データを受信するネットワーク・アプライアンスと、
    ｉｖ． クラウド・コンピューティングを提供するためのネットワークであって、前記少なくとも一つのネットワーク・アプライアンスが結合されるとともに、前記患者データが全てのネットワーク機器にわたってアクセス可能となるように、該患者データを記憶するためのデータベースを含むネットワークと、
    ｖ． 前記ネットワークに結合する少なくとも一つの提示機器であって、前記患者データにアクセスし、該患者データをグラフィカル・ユーザ・インタフェース上に表示する提示機器と、
    を含む患者ケア・システムを提供するステップと、
    ｂ． 前記少なくとも一つの検出機器を用いて前記少なくとも一つの患者の生理学的パラメータを検出及び報告するステップと、
    ｃ． 前記少なくとも一つの患者の生理学的パラメータを示す電子データを前記取得機器へ送信するステップと、
    ｄ． 標準スクリプト言語を用いて実行可能なプログラムを符号化することにより前記患者データを暗号化し、前記患者データを含むメッセージに前記患者データを添付するステップと、
    ｅ． 前記暗号化されたデータを前記ネットワーク・アプライアンスへ送信するステップと、
    ｆ． クラウド・コンピューティングを用いて前記ネットワーク上で前記データを記憶するステップと、
    ｇ． 前記提示機器を用いて前記データにアクセスし、該データを復号化し、表示するステップと、
    を含むことを特徴とする方法。
    

Images