特許 7444832 医療監視システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-27

(45)【発行日】2024-03-06

(54)【発明の名称】医療監視システム

(51)【国際特許分類】

   G16H 40/60 20180101AFI20240228BHJP

【ＦＩ】

G16H40/60

【請求項の数】 20

(21)【出願番号】P 2021179963

(22)【出願日】2021-11-04

(62)【分割の表示】P 2019142228の分割

【原出願日】2010-03-03

(65)【公開番号】P2022020743

(43)【公開日】2022-02-01

【審査請求日】2021-12-06

(31)【優先権主張番号】61/209,147

(32)【優先日】2009-03-04

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】61/296,439

(32)【優先日】2010-01-19

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】500000212

【氏名又は名称】マシモ・コーポレイション

(74)【代理人】

【識別番号】110000729

【氏名又は名称】弁理士法人ユニアス国際特許事務所

(72)【発明者】

【氏名】カイアニ、マッシ、ジョー、イー．

(72)【発明者】

【氏名】ムーシン、バイラル

(72)【発明者】

【氏名】サンパス、アナンド

(72)【発明者】

【氏名】ホウセル、ピーター、スコット

(72)【発明者】

【氏名】ワフィーク、ジハッド、アデル

(72)【発明者】

【氏名】オルセン、グレゴリー、エー．

(72)【発明者】

【氏名】アル‐アリ、アマー

【審査官】玉木 宏治

(56)【参考文献】

【文献】特開２００５－２５２５３４（ＪＰ，Ａ）

【文献】特開２００３－０２３４４０（ＪＰ，Ａ）

【文献】特開２００７－１８９６１０（ＪＰ，Ａ）

【文献】特開２００６－１９８２４１（ＪＰ，Ａ）

【文献】特開２００７－２４４５１６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１６Ｈ １０／００－８０／００

Ｇ０６Ｑ ５０／２２

(57)【特許請求の範囲】

【請求項1】

医療情報ネットワーク内での第１および第２の医療装置の間の通信を促進する、コンピュータシステムによって実行される方法であって、
第１の医療装置から第１の入力メッセージを受信するステップであって、前記第１の医療装置は、第１の通信プロトコルに従って前記入力メッセージを生成しており、前記入力メッセージは、第２の医療装置を、前記入力メッセージの意図された受信側として識別する、前記受信するステップと、
前記第２の医療装置に、アクションを実現するための命令を含む第１のテストメッセージを送信するステップと、
前記第２の医療装置に、前記第１のテストメッセージによって命令されたアクションの結果を問合せる第２のテストメッセージを送信するステップと、
前記第２の医療装置による前記第２のテストメッセージに対する応答の少なくとも部分的に基づいて、１つ以上の変換ルールを決定するステップと、
前記１つ以上の変換ルールを適用して、前記入力メッセージを出力メッセージに変換するステップであって、前記第２の医療装置は、前記出力メッセージを受信して処理するように構成された、前記変換するステップと、
前記出力メッセージを前記第２の医療装置に与えるステップと、を含む方法。

【請求項2】

前記第１の通信プロトコルは、ＨＬ７プロトコルを含む、請求項１に記載の方法。

【請求項3】

前記入力メッセージに基づいて前記変換ルールを生成するステップをさらに含む、請求項１に記載の方法。

【請求項4】

前記変換するステップは、前記入力メッセージの少なくとも一部分を再配列することを含む、請求項１に記載の方法。

【請求項5】

前記与えるステップは、前記出力メッセージをネットワーク経由で前記第２の医療装置に与えることを含む、請求項１に記載の方法。

【請求項6】

前記第２の医療装置から第２の入力メッセージを受信するステップであって、前記第２の医療装置は、第２の通信プロトコルに従って前記第２の入力メッセージを生成している、前記受信するステップと、
異なる複数の変換ルールを適用して、前記第２の入力メッセージを第２の出力メッセージに変換するステップであって、前記第１の医療装置は、前記第２の出力メッセージを受信して処理するように構成された、前記変換するステップと、
前記第２の出力メッセージを前記第１の医療装置に与えるステップと、をさらに含む、
請求項１に記載の方法。

【請求項7】

医療情報ネットワーク内での第１および第２の医療装置の間の通信を促進するように構成された、コンピュータシステムを備える医療装置メッセージ変換器であって、
第１の医療装置から第１の入力メッセージを受信し、前記第２の医療装置に第１のテストメッセージを送信し、第２の医療装置にアクションを実行させ、アクションの結果を問合わせるために第２のテストメッセージを第２の医療装置に送信しするように構成された通信インタフェースモジュールであって、前記第１の医療装置は、第１の通信プロトコルに従って前記入力メッセージを生成しており、前記入力メッセージは、第２の医療装置を、前記入力メッセージの意図された受信側として識別する、前記通信インタフェースモジュールと、
前記第２の医療装置による前記第２のテストメッセージに対する応答の少なくとも部分的に基づいて、１つ以上の変換ルールを決定し、前記１つ以上の変換ルールを適用して、前記入力メッセージを出力メッセージに変換するように構成された変換モジュールであって、前記第２の医療装置は、前記出力メッセージを受信して処理するように構成された、前記変換モジュールと、を備える医療装置メッセージ変換器。

【請求項8】

複数の医療装置と病院情報システムまたは臨床情報システムとの間で伝達されるメッセージを変換する、コンピュータシステムによって実行される方法であって、
電子患者医療記録を備える病院情報システムから入力メッセージを受信するステップであって、前記入力メッセージの内容は、医療電子通信プロトコルで許可されている第１のフォーマッティングルールセットに従ってフォーマットされている、前記受信するステップと、
医療装置に、アクションを実現するための命令を含む第１のテストメッセージを送信するステップと、
前記医療装置に、前記第１のテストメッセージによって命令されたアクションの結果を問合せる第２のテストメッセージを送信するステップと、
前記医療装置による前記第２のテストメッセージに対する応答の少なくとも部分的に基づいて、１つ以上の変換ルールを決定するステップと、
出力メッセージを生成するステップであって、前記出力メッセージの内容は、前記医療電子通信プロトコルで許可されている第２のフォーマッティングルールセットに従って再フォーマットされており、前記変換ルールは、前記出力メッセージの内容の再フォーマッティングを、前記第２のフォーマッティングルールセットに準拠するように制御する、前記生成するステップと、
前記出力メッセージを前記医療装置に出力するステップと、を含む方法。

【請求項9】

前記変換ルールは自動的に生成される、請求項８に記載の方法。

【請求項10】

前記テストメッセージは応答メッセージに対する要求を含み、前記１つ以上の変換ルールを決定することは、前記応答メッセージに基づいて、実装すべきフォーマッティングのタイプを自動的に決定することを含む、請求項８に記載の方法。

【請求項11】

前記第１のフォーマッティングルールセットは、ＨＬ７を用いて実装される、請求項８に記載の方法。

【請求項12】

前記入力メッセージを前記１つ以上の変換ルールと比較するステップを更に含む、請求項８に記載の方法。

【請求項13】

前記比較するステップは、前記入力メッセージのフォーマッティングと内容とを分離することを含む、請求項１２に記載の方法。

【請求項14】

前記入力メッセージおよび出力メッセージは、同じプロトコルを使用するが、フォーマットが異なる、請求項８に記載の方法。

【請求項15】

前記入力メッセージおよび出力メッセージは、異なるプロトコルを使用する、請求項８に記載の方法。

【請求項16】

前記入力メッセージはＨＬ７規格に準拠しているかどうかを判定するステップをさらに含む、請求項８に記載の方法。

【請求項17】

前記生成するステップは、フィールド区切り文字を置き換えること、および／または、フィールド位置を変更することを含む、請求項８に記載の方法。

【請求項18】

前記メッセージは、入院退院転院（ＡＤＴ）メッセージを含む、請求項８に記載の方法。

【請求項19】

前記変換ルールが、フィールドの繰り返し性、カージナル数、位置、使用状態、データ型、および／または長さをさらに含む、請求項８に記載の方法。

【請求項20】

更新可能またはユーザ構成可能なファイルからルールを読み出すステップをさらに含む、請求項８に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、参照によりそれぞれの全内容が本明細書に組み込まれている、２００９年３月４日に出願された米国特許仮出願第６１／２０９１４７号（件名「ＰＲＯＸＩＭＩＴＹ ＤＩＳＰＬＡＹ ＭＯＮＩＴＯＲ」）、ならびに２０１０年１月１９日に出願された米国特許仮出願第６１／２９６４３９号（件名「ＭＥＤＩＣＡＬ ＭＯＮＩＴＯＲＩＮＧ ＳＹＳＴＥＭ」）の優先権の利益を主張するものである。

【0002】

本開示は、たとえば、病院および他の患者治療施設における用途を有するシステム、装置、および方法に関する。たとえば、本明細書に記載のシステム、装置、および方法は、患者からの生理学的情報の取得、その生理学的情報の分析、およびその生理学的情報の、臨床担当者および他のシステムまたは装置への伝達に使用可能である。

【背景技術】

【0003】

病院、介護施設、および他の患者治療施設は、典型的には、施設内の１つ以上のベッドサイドに患者監視装置を備えている。患者監視装置は、一般に、医療患者の生理学的パラメータを取得および分析するためのセンサ、処理装置、およびディスプレイを備えている。生理学的パラメータにはいろいろなものがあるが、たとえば、呼吸数、ＳｐＯ_２レベル、脈拍、血圧などが挙げられる。医師、看護師、および他の特定の医療従事者を含む臨床担当者は、医療患者から取得された生理学的パラメータを用いて、病気の診断および治療の処方を行う。また、臨床担当者は、生理学的パラメータを用いて、様々な臨床的状況にある患者を監視して、患者に対する治療のレベルを上げるかどうかを決定する。

【0004】

ＨｂＣＯ、ＨｂＭｅｔ、総ヘモグロビン（Ｈｂｔ）などのような詳細なパラメータに加えてＳｐＯ_２や脈拍数のようなパルスオキシメトリパラメータを測定できる患者監視器、ならびに対応する複数の波長光学センサについての説明が、少なくとも、２００６年３月１日に出願された米国特許出願第１１／３６７０１３号明細書（件名「Ｍｕｌｔｉｐｌｅ Ｗａｖｅｌｅｎｇｔｈ Ｓｅｎｓｏｒ Ｅｍｉｔｔｅｒｓ」）、ならびに２００６年３月１日に出願された米国特許出願第１１／３６６２０８号明細書（件名「Ｎｏｎｉｎｖａｓｉｖｅ Ｍｕｌｔｉ－Ｐａｒａｍｅｔｅｒ Ｐａｔｉｅｎｔ Ｍｏｎｉｔｏｒ」）においてなされており、これらは両方ともＭａｓｉｍｏ Ｌａｂｏｒａｔｏｒｉｅｓ，Ｉｒｖｉｎｅ，ＣＡ（Ｍａｓｉｍｏ Ｌａｂｓ）に譲渡されており、両方とも、参照により本明細書に組み込まれている。さらに、いろいろなパラメータの中でも特にＳｐＯ_２、脈拍数、灌流指数、信号品質、ＨｂＣＯ、およびＨｂＭｅｔを測定するための非侵襲的血液パラメータ監視器および対応する複数の波長光学センサ（Ｒａｉｎｂｏｗ（商標）粘着式再利用可能センサやＲＡＤ－５７（商標）およびＲａｄｉｃａｌ－７（商標）監視器など）が、Ｍａｓｉｍｏ Ｃｏｒｐｏｒａｔｉｏｎ，Ｉｒｖｉｎｅ，ＣＡ（Ｍａｓｉｍｏ）から入手可能である。

【0005】

高度な生理学的監視システムは、たとえば、ほんの数例であるが、一酸化炭素ヘモグロビン（ＨｂＣＯ）、メトヘモグロビン（ＨｂＭｅｔ）、および総ヘモグロビン（Ｈｂｔ）などのような他の血液パラメータの計算および表示のための詳細機能に加えて、パルスオキシメトリを組み込むことが可能である。ＳｐＯ_２に加えて、ＨｂＣＯ、ＨｂＭｅｔ、Ｈｂｔなどのパラメータを測定できる、高度な生理学的監視器および対応する複数の波長光学センサについての説明が、少なくとも、２００６年３月１日に出願された米国特許出願第１１／３６７０１３号明細書（件名「Ｍｕｌｔｉｐｌｅ Ｗａｖｅｌｅｎｇｔｈ Ｓｅｎｓｏｒ Ｅｍｉｔｔｅｒｓ」）、ならびに２００６年３月１日に出願された米国特許出願第１１／３６６２０８号明細書（件名「Ｎｏｎｉｎｖａｓｉｖｅ Ｍｕｌｔｉ－Ｐａｒａｍｅｔｅｒ Ｐａｔｉｅｎｔ Ｍｏｎｉｔｏｒ」）においてなされており、これらはＭａｓｉｍｏ Ｌａｂｓに譲渡されており、参照により本明細書に組み込まれている。さらに、いろいろなパラメータの中でも特にＳｐＯ_２、脈拍数、灌流指数（ＰＩ）、信号品質（ＳｉＱ）、拍動変動指数（ＰＶＩ）、ＨｂＣＯ、およびＨｂＭｅｔを測定するための非侵襲的血液パラメータ監視器および対応する複数の波長光学センサ（Ｒａｉｎｂｏｗ（商標）粘着式再利用可能センサやＲＡＤ－５７（商標）およびＲａｄｉｃａｌ－７（商標）監視器など）が、Ｍａｓｉｍｏから入手可能である。

【先行技術文献】

【特許文献】

【0006】

【文献】米国特許出願第１１／３６７０１３号明細書

【文献】米国特許出願第１１／３６６２０８号明細書

【発明の概要】

【発明が解決しようとする課題】

【0007】

本明細書には、様々な医療監視装置、システム、および方法を記載している。

【課題を解決するための手段】

【0008】

実施形態によっては、医療監視装置またはシステムが、臨床担当者の存在を検知すること、ならびに、たとえば、臨床担当者の存在が検知されたことに対する応答として何らかのアクションを実行することが可能である。実施形態によっては、医療監視システムは、病院または他の患者治療施設において、いくつかの医療装置、何人かの臨床担当者、および／または何人かの患者の位置を検出することが可能である。そして、検出された位置を用いて、位置に基づく何らかのアクション、たとえば、医療装置の構成変更などを行うことが可能である。

【0009】

本明細書では、医療通信プロトコル変換器を用いて医療監視装置（またはシステム）間の通信を促進する様々な装置、システム、および方法を記載する。異なるプロトコルフォーマットで通信するようにプログラムされている医療装置間の通信を促進するために、医療通信プロトコル変換器を構成することが可能である。医療通信プロトコル変換器は、第１のプロトコルフォーマットに従ってフォーマットされた入力メッセージを第１の医療装置から受信すること、ならびに、変換ルールセットを用いて、第２の医療装置によってサポートされている第２のプロトコルフォーマットに従ってフォーマットされた出力メッセージを出力することが可能である。たとえば、医療通信プロトコル変換器は、第１のＨＬ７プロトコルフォーマットに従ってフォーマットされた入力メッセージを病院情報システムから受信すること、ならびに、変換ルールセットとの比較に基づいて、第２のＨＬ７プロトコルフォーマットに従ってフォーマットされた出力メッセージを出力することが可能である。

【0010】

実施形態によっては、医療監視装置またはシステムが、何人かの患者から生理学的パラメータデータを収集すること、ならびに、このデータを用いて様々なアラーム状態検出条件および／またはアラーム通知遅延時間をシミュレートすることが可能である。これらのシミュレートされたアラーム状態検出条件および／またはアラーム通知遅延時間を解析および使用することにより、（たとえば、ベッドサイド患者監視装置で使用される）実際のアラーム状態検出条件および／またはアラーム通知遅延時間を変更することが可能である。

【0011】

特定実施形態では、生理学的情報を監視する医療患者監視装置が、少なくとも１人の患者から生理学的情報を受信するように構成されたインタフェースを備える。本装置はさらに、生理学的情報に基づく臨床的に有用なタスクを実行するように構成されたプロセッサを備えることが可能である。本装置はまた、医療患者監視装置の近傍の検出範囲内において、臨床担当者が誰であるかを表す臨床担当者トークンの物理的存在を検出する検出器を備えることが可能である。さらに、本プロセッサは、臨床担当者トークンが検出されたことに対する応答として、第１の所定のアクションを実行するように構成可能であり、第１の所定のアクションは、臨床担当者が誰かという情報に関連付けられている。

【0012】

特定実施形態では、複数の医療装置の物理的位置を特定する臨床システムが、複数の患者から生理学的情報を収集することが可能な複数の医療患者監視装置を備える。本臨床システムはさらに、医療患者監視装置からの無線信号を検出することが可能な検出器の分散ネットワークを備えることが可能である。本臨床システムはまた、検出器から検出された無線信号に基づいて、医療患者監視装置の物理的位置を推定することが可能な、検出器と通信可能に結合された位置監視サーバを備えることが可能である。

【0013】

様々な実施形態において、医療情報ネットワーク内での第１および第２の医療装置の間の通信を促進する方法が、第１の通信プロトコルに従って生成された第１の入力メッセージを第１の医療装置から受信するステップを含む。入力メッセージは、第２の医療装置を、入力メッセージの意図された受信側として識別することが可能である。本方法はさらに、１つ以上の変換ルールを適用して入力メッセージを出力メッセージに変換するステップを含むことが可能である。本方法はまた、出力メッセージを第２の医療装置に与えるステップを含むことが可能であり、第２の医療装置は、出力メッセージを受信して処理するように構成されている。

【0014】

特定実施形態では、医療情報ネットワーク内での第１および第２の医療装置の間の通信を促進するように構成された医療装置メッセージ変換器が、第１の通信プロトコルに従って第１の入力メッセージを生成した第１の医療装置から第１の入力メッセージを受信するように構成された通信インタフェースモジュールを備える。入力メッセージは、第２の医療装置を、入力メッセージの意図された受信側として識別することが可能である。変換器はさらに、１つ以上の所定の変換ルールを格納するように構成されたルールモジュールと、ルールモジュールから取り出した１つ以上の変換ルールを適用して入力メッセージを出力メッセージに変換するように構成された変換モジュールとを備えることが可能である。第２の医療装置は、出力メッセージを受信して処理するように構成可能である。

【0015】

様々な実施形態において、複数の医療装置と病院情報システムまたは臨床情報システムとの間で伝達されるメッセージを変換する方法が、電子患者医療記録を備える病院情報システムから入力メッセージを受信するステップを含み、入力メッセージの内容は、医療電子通信プロトコルで許可されている第１のフォーマッティングルールセットに従ってフォーマットされている。本方法はさらに、入力メッセージを変換ルールセットと比較するステップと、出力メッセージを生成するステップとを含むことが可能であり、出力メッセージの内容は、医療電子通信プロトコルで許可されている第２のフォーマッティングルールセットに従って再フォーマットされている。変換ルールは、出力メッセージの内容の再フォーマッティングを、第２のフォーマッティングルールセットに準拠するように制御することが可能である。本方法はまた、出力メッセージを医療装置に出力するステップを含むことが可能である。

【0016】

様々な実施形態において、共通の医療電子通信プロトコルに属するがフォーマットが異なる入力医療メッセージおよび出力医療メッセージに対して、現場でのカスタマイズが可能な変換を行う方法が、第１の医療装置から入力メッセージを受信するステップを含み、入力メッセージの内容は、第１のフォーマッティングルールセットに従ってフォーマットされている。本方法はさらに、入力メッセージから、意図された受信側医療装置を特定するステップを含むことが可能である。本方法はまた、入力メッセージを変換ルールセットと比較するステップと、入力メッセージと変換ルールセットとの比較に基づいて、意図された受信側医療装置によって予期される第２のフォーマッティングルールセットを反映するように入力メッセージのフォーマッティングを変更するステップと、を含むことが可能である。さらに、本方法はまた、内容が第２のフォーマッティングルールセットに従ってフォーマットされている出力メッセージを生成するステップと、出力メッセージを、意図された受信側医療装置に出力するステップと、を含むことが可能である。

【0017】

特定実施形態では、病院情報システムと患者監視器との間の医療メッセージの伝達を促進するシステムが、複数の患者の電子医療記録を格納するように構成された電子医療記録データベースを有する病院情報システムを備える。本システムはさらに、患者の少なくとも１つの生理学的状態を監視するように構成された患者監視器を備えることが可能である。本システムはまた、病院情報システムと患者監視器との間に通信可能に結合されるように構成された変換モジュールを備えることも可能である。変換モジュールは、内容が第１のフォーマッティングルールセットに従ってフォーマットされている入力メッセージを病院情報システムまたは患者監視器のうちの一方から受信するステップと、入力メッセージを変換ルールセットと比較するステップと、出力メッセージを生成するステップであって、出力メッセージの内容は、第２のフォーマッティングルールセットに従って再フォーマットされており、変換ルールは、出力メッセージの内容の再フォーマッティングを、第２のフォーマッティングルールセットに準拠するように制御する、出力メッセージを生成するステップと、を行うように構成可能である。

【0018】

特定実施形態では、ネットワーク経由での医療装置間の医療メッセージの伝達を促進するシステムが、医療メッセージの送受信を行うように構成された第１の医療装置であって、ネットワークと通信可能に結合されるように構成された第１の医療装置を備える。本システムはさらに、医療メッセージの送受信を行うように構成された第２の医療装置であって、ネットワークと通信可能に結合されるように構成された第２の医療装置を備えることが可能である。本システムはまた、第１の医療装置と第２の医療装置との間に通信可能に結合されるように構成された変換モジュールを備えることも可能である。変換モジュールは、内容が第１のフォーマッティングルールセットに従ってフォーマットされている入力メッセージを第１の医療装置から受信するステップと、入力メッセージを変換ルールセットと比較するステップと、行うように構成可能である。変換モジュールはまた、内容が第２のフォーマッティングルールセットに従って再フォーマットされている出力メッセージを生成するように構成可能であり、変換ルールは、出力メッセージの内容の再フォーマッティングを、第２のフォーマッティングルールセットに準拠するように制御する。さらに、変換モジュールは、出力メッセージを第２の医療装置に出力するように構成可能である。

【0019】

様々な実施形態において、医療電子通信プロトコルに従って医療通信のフォーマッティングを定義する方法が、フォーマット変換ソフトウェアをコンパイルするステップと、フォーマット変換ソフトウェアをインストールするステップと、フォーマット変換ソフトウェアを再コンパイルすることなく、ユーザ構成可能ファイル内で変換ルールセットを更新するステップと、を含む。

【0020】

特定実施形態では、生理学的パラメータ監視データを解析する方法が、複数の患者から生理学的パラメータデータを受信するステップを含む。本方法はさらに、第１のアラーム条件に基づいて検出されている、複数の患者に発生したアラーム状態を表す第１の生理学的パラメータアラームデータをその複数の患者から受信するステップを含むことが可能である。本方法はまた、第２のアラーム条件に基づいて検出されるシミュレートされたアラーム状態を表している第２の生理学的パラメータアラームデータを、プロセッサを用いて生成するステップを含むことが可能である。さらに、本方法は、プロセッサを用いて第１および第２の生理学的パラメータアラームデータを比較するステップを含むことが可能である。特定実施形態では、コンピュータ可読媒体が、コンピュータによって読み出された場合に、この、生理学的パラメータ監視データを解析する方法を前記コンピュータに実行させる命令を含む。

【0021】

様々な実施形態において、生理学的パラメータ監視データを解析する方法が、複数の患者から生理学的パラメータデータを受信するステップを含む。本方法はさらに、第１のアラーム通知遅延時間に基づいて生成された生理学的パラメータアラーム通知を表す第１の生理学的パラメータアラーム通知データを受信するステップを含むことが可能である。本方法はまた、第２のアラーム通知遅延時間に基づいて生成されるシミュレートされた生理学的パラメータアラーム通知を表している、第２の生理学的パラメータアラーム通知データを、プロセッサを用いて生成するステップを含むことが可能である。さらに、本方法は、第１および第２の生理学的パラメータアラーム通知データを比較するステップを含むことが可能である。

【0022】

以下では、添付図面を参照しながら、様々な実施形態を説明する。これらの実施形態は、例としてのみ図示および説明するものであって、本開示の範囲を限定するものではない。

【図面の簡単な説明】

【0023】

【図1】本発明の一実施形態による生理学的監視システムを示す例示的ブロック図である。

【図2】生理学的監視システムの別の実施形態を示す例示的ブロック図である。

【図3】本発明の一実施形態によるネットワーク・インタフェース・モジュールを示す例示的ブロック図である。

【図4】本発明の一実施形態による、状況に基づいて生理学的情報を伝達する方法を示す例示的フローチャート図である。

【図5】本発明の一実施形態によるアラーム通知システムを示す例示的ブロック図である。

【図6】臨床ネットワーク環境の一実施形態を示すブロック図である。

【図7】図６の臨床ネットワーク環境のより詳細な実施形態を示すブロック図である。

【図8A】医療イベントをジャーナルデータベースにジャーナリングする方法の一実施形態を示すフローチャートである。

【図8B】ジャーナルデータベースおよびラウンドロビンデータベースからのデータを相互に関連付ける方法の一実施形態を示すフローチャートである。

【図9】図６の臨床ネットワーク環境において患者を監視するためのユーザインタフェースの一例の画面ショットである。

【図10】高度な患者監視システムの斜視図である。

【図11】マルチユーザ環境における近傍表示を示す図である。

【図12】近傍表示監視器の全体ブロック図である。

【図13】ユーザ表示環境設定画面を示す図である。

【図14】臨床担当者トークンの存在を自動的に検出できる患者監視装置の概略図である。

【図15】患者監視装置の検出範囲内で臨床担当者トークンの存在を検出する検出方法を示すフローチャートである。

【図16】看護師詰所または中央患者監視装置のグラフィカル・ユーザ・インタフェースの一例を示す図である。

【図17】臨床担当者の存在が検出されたことに基づいて患者監視装置によって既に有効にされている、臨床担当者に固有のアクションをいつ無効にするかを決定する方法を示すフローチャートである。

【図18】患者監視装置を有効にして臨床担当者トークンの存在を自動的に検出するシステムの概略図である。

【図19】臨床担当者近傍認識機能を有する患者監視装置ネットワークの概略図である。

【図20】ＷｉＦｉアクセスポイントが分散している病院フロアの概略図であり、ＷｉＦｉアクセスポイントを用いることにより、医療装置、患者、および臨床担当者の物理的位置を推定することが可能である。

【図21】ユーザが近傍にいることを有利にフィードバックする近傍表示実施形態を示す図である。

【図22】ユーザが近傍にいることを有利にフィードバックする近傍表示実施形態を示す図である。

【図23】ユーザが近傍にいることを有利にフィードバックする近傍表示実施形態を示す図である。

【図21A】仮想回転三角形固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図21B】仮想回転三角形固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図21C】仮想回転三角形固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図21D】仮想回転三角形固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図21E】仮想回転三角形固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図21F】仮想回転三角形固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図22A】仮想回転立方体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図22B】仮想回転立方体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図22C】仮想回転立方体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図22D】仮想回転立方体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図22E】仮想回転立方体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図23A】仮想回転平面固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図23B】仮想回転平面固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図23C】仮想回転平面固体を利用して近傍にいることをフィードバックする近傍表示実施形態を示す図である。

【図24A】第１の医療装置と第２の医療装置とが変換モジュールを介して相互通信する様子を示す図である。

【図24B】第１の医療装置と第２の医療装置とが変換モジュールおよび通信バスを介して相互通信する様子を示す図である。

【図25A】変換モジュールが受信する入力メッセージの一例を示す図である。

【図25B】図１９Ａの入力メッセージの、フィールドとして解析されたメッセージ・ヘッダ・セグメントを示す図である。

【図25C】図２５Ｂの解析されたメッセージ・ヘッダ・セグメントをエンコードしたものを示す図である。

【図25D】図２５Ａの入力メッセージに基づく、変換モジュールの出力メッセージの一例を示す図である。

【図26】入力メッセージと、変換モジュールに関連付けられた変換ルールとの比較と、に基づいて、出力メッセージを生成する変換プロセスを示す図である。

【図27A】変換モジュールが、第１のＨＬ７フォーマットを有する病院情報システム（「ＨＩＳ」）から、第２のＨＬ７フォーマットを有する意図された受信側医療装置へのＨＬ７メッセージの伝達を促進する変換プロセスを示す図である。

【図27B】変換モジュールが、第１のＨＬ７フォーマットを有する医療装置から、第２のＨＬ７フォーマットを有するＨＩＳへのＨＬ７メッセージの伝達を促進する変換プロセスを示す図である。

【図28】変換モジュールで使用する変換ルールを手動で構成するメッセージング実装ソフトウェアツールからの画面ショットの例を示す図である。

【図29A】変換モジュールによって実行される自動ルール構成プロセスを示す図である。

【図29B】変換モジュールによって実行される自動ルール構成プロセスを示す図である。

【図29C】ＨＬ７プロトコルを利用するメッセージに対して、変換モジュールによって実行される自動ルール構成プロセスを示す図である。

【図29D】ＨＬ７プロトコルを利用するメッセージに対して、変換モジュールによって実行される自動ルール構成プロセスを示す図である。

【図30】アラーム限界値の関数としての所与の生理学的パラメータに対するアラームイベントの分布のグラフ例である。

【図31】アラーム条件の変化の結果である、識別されるアラーム状態の変化を調べる方法を示すフローチャートである。

【図32】シミュレートされたアラーム条件がアラーム検出イベントに及ぼす影響を示す表による報告例を示す図である。

【図33】アラーム条件の変化の結果として起こる、識別されるアラーム状態の変化を調べる別の方法を示すフローチャートである。

【図34】シミュレートされたアラーム条件がアラーム検出イベントの数に及ぼす影響、ならびに、このシミュレートされたアラーム条件が、たとえば、偽陰性および偽陽性に及ぼす影響を示す表による報告例を示す図である。

【図35】アラーム通知遅延時間の変化の結果として起こる、アラーム通知イベントの変化を調べる方法を示すフローチャートである。

【図36A-36B】マルチユーザ患者監視環境において有利な機能を提供する近傍表示を示す図である。複数のレイアウトゾーンを有する表示を示す図である。

【図37A-37F】マルチユーザ患者監視環境において有利な機能を提供する近傍表示を示す図である。インストールされたパラメータの数に応じてレイアウトおよびフォントサイズを変える表示を示す図である。

【図38A-38B】マルチユーザ患者監視環境において有利な機能を提供する近傍表示を示す図である。パラメータウェルを有する表示を示す図である。

【図39A-39B】マルチユーザ患者監視環境において有利な機能を提供する近傍表示を示す図である。アラームを発しているパラメータを拡大する表示を示す図である。

【図40A-40B】マルチユーザ患者監視環境において有利な機能を提供する近傍表示を示す図である。着色アラームゾーンを有する動向グラフの表示を示す図である。

【図41】矢印キーとカーソルの白黒反転を合わせた表示を示す図である。

【図42】ユーザが選択可能なジャンプ画面を有する表示を示す図である。

【図43A】動向グラフの表示を示す図である。

【図43B】動向グラフの表示を示す図である。

【発明を実施するための形態】

【0024】

様々な実施形態において、生理学的監視システムは、医療患者から発生した生理学的信号を監視し、その信号を処理して、患者の様々な生理学的パラメータのいずれかを求めるシステムである。たとえば、場合によっては、生理学的監視システムは、患者の様々な生理学的パラメータのいずれかを求めることが可能であり、それらは、たとえば、呼吸数、吸気時間、呼気時間、Ｉ：Ｅ比（たとえば、吸気時間呼気時間比）、吸気流、呼気流、一回換気量、分時拍出量、無呼吸継続時間、呼吸音、ラ音、水泡音、喘鳴、呼吸音の変化（空気流量の減少または空気流の変化など）などである。さらに、場合によっては、生理学的監視システムは、他の生理学的音を監視し、それらは、プローブオフ検出に役立つ心拍数、心音（たとえば、Ｓ１、Ｓ２、Ｓ３、Ｓ４、および心雑音）、心音の変化（たとえば、正常音から心雑音への変化や、体液過剰を表す分裂心音）などである。さらに、生理学的監視システムは、心音をよりよく検出するために胸の上で第２のプローブを用いることが可能であり、ユーザ入力を最小限（たとえば、入力高さのみ）に抑えることが可能であり、Ｈｅａｌｔｈ Ｌｅｖｅｌ ７（ＨＬ７）インタフェースを用いてデモグラフィを自動的に入力することが可能である。

【0025】

特定の実施形態の生理学的監視システムは、オープンアーキテクチャ通信規格を用いた共用ネットワークに接続された１つ以上の患者監視装置を含んでいる。これらの、特定の実施形態の患者監視装置は、ネットワーク・インタフェース・モジュールと結合された生理学的監視器を含んでいる。生理学的監視器は、１つ以上のセンサと、センサからの信号を処理するセンサ処理モジュールとを含んでいる。ネットワーク・インタフェース・モジュールは、センサ処理モジュールからの生理学的情報を受け取り、この情報を共用ネットワークに送信する。ネットワーク・インタフェース・モジュールは、様々な生理学的監視器に接続可能である。さらに、様々な実装のネットワーク・インタフェース・モジュールは、１人の医療患者に独占的に割り当てられる可搬型ベッドサイド装置である。

【0026】

特定実施形態では、ネットワーク・インタフェース・モジュールは、共用ネットワーク経由でのエンドユーザとの直接的なネットワーク接続の確立を促進する。これらのエンドユーザは、医師、看護師、および他の病院スタッフを含んでおり、電子装置（たとえば、ページャ、ＰＤＡ、ラップトップ、コンピュータ、可動式コンピュータ（ＣＯＷ）など）上のネットワーク・インタフェース・モジュールから生理学的情報、アラーム、およびアラートを受け取ることが可能である。

【0027】

図１は、特定実施形態の生理学的監視システム１００（たとえば、アラーム通知システム）を示しており、これは、「既製の」ハードウェアおよび通信プロトコルを用いたオープンネットワークアーキテクチャを含んでいる。様々な実装におけるこのアーキテクチャは、共用（オープン）ネットワークであり、複数の患者監視装置１１０、ネットワークバス１２０（たとえば、イーサネット(登録商標）バックボーン）、および病院ＷＬＡＮ １２６を含んでいる。さらに、この共用ネットワークは、インターネット１５０との接続１２２、インターネット１５０経由でのエンドユーザ装置１５２との接続１２２、および病院ＷＬＡＮ １２６経由でのエンドユーザ装置１２８との接続１２２をさらに含むことが可能である。したがって、特定実施形態の生理学的監視システム１００は、現在利用可能な患者監視システムをコスト効率よく置き換えるエンタープライズシステムである。

【0028】

生理学的監視システム１００は、複数のベッドサイド装置、たとえば、患者監視装置１１０を含んでいる。様々な実施形態の患者監視装置１１０は、複数のセンサ１０２、１つ以上のセンサ処理モジュール１０４、および通信モジュール、たとえば、ネットワーク・インタフェース・モジュール１０６を含んでいる。図示した実施形態では、２つの患者監視装置１１０を示している。一方の患者監視装置は、１セットのセンサ１０２と、１つのセンサ処理モジュール１０４と、１つのネットワーク・インタフェース・モジュール１０６とを含んでいる。他方の患者監視装置１１０は、２セットのセンサ１０２と、２つのセンサ処理モジュール１０４と、１つのネットワーク・インタフェース・モジュール１０６とを含んでいる。

【0029】

特定の実施形態では、各患者監視装置１１０は、１人の医療患者が使用する。これらの患者監視装置１１０は、患者監視装置１１０のネットワークを形成しており、各患者監視装置１１０は、病院ネットワーク１２６と、インターネット１５０へのネットワークインタフェースとを含む共用ネットワークを経由して、臨床担当者および他のエンドユーザと通信することが可能である。

【0030】

患者監視装置１１０の１つ以上のセンサ１０２が、医療患者に装着されている。これらのセンサ１０２は、ＥＣＧセンサ、音響センサ、パルスオキシメータ、または他のタイプのセンサであってよい。センサ１０２は、医療患者から生理学的情報を取得し、この情報を、ケーブル１０３または無線接続（図示せず）を介してセンサ処理モジュール１０４に送信する。特定実施形態では、生理学的情報は、１つ以上の生理学的パラメータまたは値と、それらの生理学的パラメータに対応する波形とを含む。

【0031】

センサ処理モジュール１０４は、センサ１０２から生理学的情報を受信する。特定実施形態のセンサ処理モジュール１０４は、プロセッサを有する回路と、生理学的情報を受信する入力ポートと、プロセッサ内で生理学的情報を処理するソフトウェアと、オプションでディスプレイと、オプションで入力装置（たとえば、キーボード）とを含んでいる。さらに、センサ処理モジュール１０４は、１つ以上の出力ポート（シリアルポートなど）を含んでいる。たとえば、センサ処理モジュール１０４に、ＲＳ２３２、ＲＳ４２３、またはオートボーＲＳ２３２（シリアルインタフェース規格）のポート、またはユニバーサルシリアルバス（ＵＳＢ）ポートを備えることが可能である。

【0032】

特定実施形態では、センサ処理モジュール１０４は、センサ１０２から受信した信号から波形を生成する。センサ処理モジュール１０４はまた、単一または複数のパラメータの動向を分析して、アラームイベントより先に早期警戒アラートを臨床担当者に与えることも可能である。さらに、特定実施形態におけるセンサ処理モジュール１０４は、生理学的パラメータが特定の安全閾値を超えたことに対する応答としてアラームを発生させる。

【0033】

アラートの例として、パルスオキシメータと通信できないこと、パルスオキシメータ側でアラームが鳴らないこと、計器（パルスオキシメータ）のバッテリ残量不足、送信機のバッテリ残量不足などが挙げられる。アラームの例として、ＳｐＯ_２のレベルおよびアラーム、高および低ＳｐＯ_２、高および低ＰＲ、ＨｂＣＯのレベルおよびアラーム、ＨｂＭＥＴのレベルおよびアラーム、脈拍数およびアラーム、センサなし、センサがオフの患者、センサエラー、低灌流指数、低信号品質、ＨｂＣＯ、ＨｂＭＥＴ、ＰＩの動向のアラーム、飽和度低下指数のアラームなどがある。

【0034】

図示した実施形態におけるネットワーク・インタフェース・モジュール１０６は、１つ以上のコネクタ１０８を介して１つ以上のセンサ処理モジュール１０４に接続されており、コネクタ１０８は、センサ処理モジュール１０４のシリアルポートに対応するシリアルコネクタであってよい。コネクタ１０８の破線は、特定実施形態のネットワーク・インタフェース・モジュール１０６とセンサ処理モジュール１０４との接続が永続的なものではないことを表している。しかしながら、（図示していない）代替実施形態では、ネットワーク・インタフェース・モジュール１０６は、センサ処理モジュール１０４内に収容される。

【0035】

様々な実装におけるネットワーク・インタフェース・モジュール１０６は、プロセッサと、入力ポート（標準ＲＳ２３２シリアルポートなど）と、ネットワーク出力ポート（イーサネット（登録商標）ポートなど）と、ネットワーク・インタフェース・モジュール１０６がネットワーク通信対応装置として動作することを可能にするソフトウェアとを含んでいる。さらに、ネットワーク・インタフェース・モジュール１０６は、記憶装置１１４を含んでおり、記憶装置１１４は、ネットワーク・インタフェース・モジュール１０６内に含めてよく、ネットワーク・インタフェース・モジュール１０６とは独立に接続してもよい。

【0036】

ネットワーク・インタフェース・モジュール１０６は、共用ネットワーク経由でのエンドユーザ装置との接続を開始および維持するために接続オーバヘッドを管理する。特定実施形態では、ネットワーク・インタフェース・モジュール１０６は、マイクロサーバまたはＷｅｂサーバとして動作することにより、接続を管理する。このような場合、ネットワーク・インタフェース・モジュール１０６は、ネットワーク接続対応装置である。ネットワーク・インタフェース・モジュール１０６は、Ｗｅｂサーバとして、ネットワーク・インタフェース・モジュール１０６の記憶装置１１４に格納されたＷｅｂページにエンドユーザがアクセスできるように、インターネット１５０との直接接続を確立する。したがって、一実施形態では、ネットワーク・インタフェース・モジュール１０６は、インターネット１５０に接続するための独立したサーバを必要としない。一実施形態では、ネットワーク・インタフェース・モジュール１０６は、接続１２２がモデムを含むことにより、モデムを介してインターネット１５０に直接接続する。ネットワーク・インタフェース・モジュール１０６は、共用ネットワーク経由での接続を管理する場合には、ユーザ認証のようなセキュリティ管理機能を実行してもよい。

【0037】

特定実施形態では、ネットワーク・インタフェース・モジュール１０６は、アクセスポイント１２４、または他の無線または有線送信機を介して、共用ネットワーク経由でデータを送信する。代替として、ネットワーク・インタフェース・モジュール１０６は、インターネット１５０経由で、生理学的情報を直接エンドユーザに伝達することが可能である。通知装置（たとえば、病院ＷＬＡＮ １２６に接続されたエンドユーザ装置１２８、１５２）を携帯する臨床担当者などのエンドユーザは、オンデマンドで、またはアラームまたはアラートのイベント時に、生理学的患者パラメータおよび波形の実時間表示を受信することが可能である。特定実施形態において、生理学的情報を実時間で、またはわずかな遅れで送信することは、効果的なアラーム対応のためのＪｏｉｎｔ Ｃｏｍｍｉｓｓｉｏｎ ｏｎ Ａｃｃｒｅｄｉｔａｔｉｏｎ ｏｆ Ｈｅａｌｔｈｃａｒｅ Ｏｒｇａｎｉｚａｔｉｏｎｓ（ＪＣＡＨＯ）規格を順守したアラーム待ち時間の規格に適合している。したがって、特定実施形態のネットワーク・インタフェース・モジュール１０６は、中央看護師詰所と同等の機能性を付加するものである。

【0038】

特定実施形態では、ネットワーク・インタフェース・モジュール１０６は、状況管理を実行する。一実施形態では、状況管理は、生理学的情報に状況情報を関連付けて状況データパッケージを形成することを含む。状況情報にはいくつかのカテゴリの情報を含めることが可能であり、たとえば、ネットワーク・インタフェース・モジュール１０６に関連する状況情報、医療患者に関連する状況情報、ネットワーク・インタフェース・モジュール１０６の使用に関連する状況情報、およびネットワーク接続に関連する状況情報という各カテゴリの情報を含めることが可能である。これらの状況カテゴリのうちの１つ以上において、状況情報に含めることが可能なものとして、患者名、患者の一意の院内識別番号、患者の場所、ネットワーク・インタフェース・モジュール１０６の識別番号、生理学的監視システム１００内で発生したイベントのタイムスタンプ、環境条件（ネットワーク状態の変化や、ネットワーク・インタフェース・モジュール１０６の使用状況統計など）、ネットワークリンクに対応する識別情報（たとえば、ネットワーク接続がＷｉＦｉかイーサネット（登録商標）か）などがある。一実施形態では、状況データパッケージ内の状況情報に、上記情報カテゴリのうちの１つ以上からすべての状況情報または一部のサブセットの状況情報を含めることが可能である。

【0039】

ネットワーク・インタフェース・モジュール１０６が受け取る状況情報は、たとえば、看護師がネットワーク・インタフェース・モジュール１０６に入力する情報や、サーバ１３６からの情報である。一実施形態では、ネットワーク・インタフェース・モジュール１０６は、この情報（たとえば、患者の識別番号および場所を含む）を受け取ることにより、当該医療患者に独占的に割り当てられることとなる。ネットワーク・インタフェース・モジュール１０６は、アラームまたはアラートの発生中に、または臨床担当者の要求に応じて、またはスケジュールに従って、状況データパッケージを臨床担当者に送信または伝達する。さらに、ネットワーク・インタフェース・モジュール１０６は、生理学的情報の連続的なストリームを臨床担当者に送信することが可能である。

【0040】

特定実施形態において、ネットワーク・インタフェース・モジュール１０６は、オプションで複数のセンサ処理モジュール１０４に接続することにより、患者状況情報および他の状況情報を複数のセンサ処理モジュール１０４に関連付けることが可能である。これにより、ネットワーク・インタフェース・モジュール１０６向けに状況を作成することに加えて、１つ以上のセンサ処理モジュール１０４向けに状況を作成することが可能である。

【0041】

一実施形態におけるネットワーク・インタフェース・モジュール１０６は、状況データパッケージを送信することに加えて、状況データパッケージを記憶装置１１４に格納する。記憶装置１１４は、フラッシュメモリ、ハードディスクドライブ、または他の形態の不揮発性または揮発性メモリであってよい。特定実施形態では、記憶装置１１４は、フロー制御バッファとして動作する。ネットワーク・インタフェース・モジュール１０６は、フロー制御バッファとして動作する記憶装置１１４を用いて、通信中のフロー制御を実行する。これについては、後で図３に関して詳細に説明する。

【0042】

実装によっては、オプションで、サーバ１３６を生理学的監視システム１００に含めることが可能である。そのような実装におけるサーバ１３６は、一般に、ブレードサーバなどのようなコンピューティング装置である。特定実施形態では、サーバ１３６は、データクローゼットに収容されたアプライアンスサーバである。他の実施形態では、サーバ１３６は、中央看護師詰所に設置された、ワークステーションサーバのようなサーバである。

【0043】

サーバ１３６は、複数のネットワーク・インタフェース・モジュール１０６から状況データパッケージを受信し、その状況データパッケージを記憶装置１３８に格納する。したがって、特定実施形態では、この記憶装置１３８は、長期的患者データをアーカイブする。この患者データは、患者の退院後も維持可能である。サーバ１３６は、患者データの格納時には、共用ネットワークと外部の電子医療記録（ＥＭＲ）システムとの間のインタフェースとして動作可能である。

【0044】

サーバ１３６はまた、ユーザとシステムとの対話、およびシステムの性能指標に関するデータを格納することも可能である。特定実施形態のサーバ１３６には、ジャーナルデータベースが組み込まれている。ジャーナルデータベースは、すべてのアラートおよびアラームまたはアラートおよびアラームのサブセット、ならびに人間の対話を、航空機の「ブラックボックス」が操縦室の活動を記録するのとほぼ同じように記憶する。ジャーナルは、普段、臨床担当のエンドユーザがアクセスすることはできず、技術的な承認がない限り、不正変更されることはない。さらに、サーバ１３６は、システム全体の稼働時間のようなシステム性能指標の内部ジャーナリングを実行することが可能である。

【0045】

一実施形態では、サーバ１３６のジャーナリング機能は、トランザクションベースのアーキテクチャを構成する。生理学的監視システム１００の特定のトランザクションをジャーナリングすることにより、記録済みイベントの時系列を後で再構築して、行われた治療の質を評価することが可能である。これらのトランザクションには、患者監視装置１００からの生理学的情報、患者監視装置１１０、病院ＷＬＡＮ １２６の接続、ユーザ操作、およびシステム挙動に関連する状態変化が含まれる。一実施形態において生理学的監視器から受信した生理学的情報に関連するジャーナリングは、生理学的情報そのものを記録すること、生理学的情報の変化を記録すること、またはその両方を含む。

【0046】

特定実施形態におけるサーバ１３６は、ネットワーク・インタフェース・モジュール１０６と、臨床担当者用通知装置（ＰＤＡやページャなど）と、外部システム（ＥＭＲなど）との間の接続を維持する論理ツールおよび管理ツールを提供している。特定実施形態のサーバ１３６がさらに提供するものとして、生理学的監視システム１００に関連するソフトウェアのインストール（プロビジョニング）を行って、システムに新しい装置を追加したり、シフトの開始時および終了時のアラーム通知用として通知装置（たとえば、ＰＤＡやページャなど）を各臨床担当者に割り当てたりすることを可能にするＷｅｂベースのインタフェース、主治療担当者がアラームに対応しない場合のエスカレーションアルゴリズム、アラーム発生および応答時間に関する管理報告を提供するインタフェース、場所管理、システム性能指標（システム全体の稼働時間など）の内部ジャーナリングなどがある（たとえば、図５および関連の記載を参照）。

【0047】

特定実施形態におけるサーバ１３６はまた、臨床アラームを予期して早期アラートを与える、高度なルールエンジンおよび信号処理アルゴリズムのためのプラットフォームを提供する。一実施形態におけるサーバ１３６のオペレーティングシステムは、コスト上の理由からＬｉｎｕｘ（登録商標）ベースであるが、Ｍｉｃｒｏｓｏｆｔベースまたは他のオペレーティングシステムも使用可能である。さらに、サーバ１３６は、データ記憶装置およびシステム冗長性機能（ＲＡＩＤ（独立ディスクのランダム配列）オプションや高可用性オプションなど）を含むように拡張可能である。

【0048】

別の実施形態（図示せず）では、エンドユーザ装置１２８、１５２は、２行表示の単方向ＰＯＣＳＡＧページャを含んでおり、これは、可聴および振動モードを有し、病院の一般的なフロア配置によくある過酷な機械的環境に適したサイズおよび耐久性を有する。さらに別の実施形態では、エンドユーザ装置１２８、１５２は、Ｍｏｔｏｒｏｌａ ＦｌｅｘページャおよびＷＬＡＮページャのような双方向ページングシステムを含んでいる。双方向ページングの一利点は、メッセージ受信を確認できること、ならびにアラームをリモートで静音化できることである。エンドユーザは、エンドユーザによって決定される堅牢性および許容できるフォームファクタに基づいて、無線ＰＤＡを用いることも可能である。そのような装置の一例として、Ｓｙｍｂｏｌ Ｔｅｃｈｎｏｌｏｇｙ ＭＣ５０ ＰＤＡ／Ｂａｒｃｏｄｅ Ｓｃａｎｎｅｒがある。

【0049】

図２は、本発明の別の実施形態の生理学的監視システム２００を示す。生理学的監視システム２００は、ネットワーク通信対応装置２１０を含んでいる。ネットワーク通信対応装置２１０は、無線接続を介して病院ネットワーク２２０に直接接続されている。特定実施形態では、ネットワーク通信対応装置２１０は、図１のセンサ１０２およびセンサ処理モジュール１０４と同様のセンサおよびセンサ処理モジュールを含んでいる。これらのネットワーク通信対応装置２１０のいくつかはベッドサイド装置であり、他は、歩行できる（移動可能な）患者に使用可能な、手持ち型もしくは他の患者装着型の装置である。

【0050】

病院ネットワーク２２０は、生理学的情報および状況情報を、ページャ２４０、ＰＤＡ ２３０などを含む臨床担当者用通知装置に送信する。特定実施形態では、病院ネットワーク２２０は、サーバ２５０を利用して、状況データパッケージをページ送信機２４２に送信し、ページ送信機２４２はさらにそのデータを単方向無線ページャ２４０に送信する。サーバ２５０には、外部インタフェース２８０を結合することが可能である。外部インタフェース２８０は、エンタープライズページング、看護師呼出システム、ワイドエリアページングシステム、エンタープライズ臨床／患者情報システム、サードパーティの監視監督システムのうちの１つ以上を含むことが可能である。

【0051】

他のいくつかの装置２６０（何らかの患者監視機器など）は、ネットワーク通信対応装置ではない。すなわち、これらの他の装置２６０は、支援がないとネットワークに接続できない。図示した生理学的監視システム２００では、ネットワーク通信対応ではない装置例２６０が、ネットワーク・インタフェース・モジュール２７０に接続されている。ネットワーク・インタフェース・モジュール２７０は、ネットワーク通信に対応していない他の装置２６０に、ＲＳ２３２ケーブル２６４で接続されている。このような接続は、多くの装置に見られる、標準化されたシリアル接続である。ネットワーク・インタフェース・モジュール２７０は、ＲＳ２３２ポートを有しているので、ネットワーク通信に対応していない患者監視装置を病院ネットワーク２２０に、さらにはインターネットに直接接続できるようにすることが可能である。

【0052】

さらに、実施形態によっては、ネットワーク・インタフェース・モジュール２７０は、１つ以上の他の装置２６０に接続することにより、患者状況情報および他の状況情報を１つ以上の他の装置２６０に関連付けることが可能である。したがって、ネットワーク・インタフェース・モジュール２７０向けに状況を作成することに加えて、１つ以上の他の装置２６０向けに状況を作成することが可能である。

【0053】

図３は、本発明の特定実施形態によるネットワーク・インタフェース・モジュール３００を示す。図示した実施形態におけるネットワーク・インタフェース・モジュール３００は、入力ポート３０２を含んでおり、特定実施形態における入力ポート３０２は、センサ処理モジュールとの接続を促進するシリアルポートである。ネットワーク・インタフェース・モジュール３００はまた、ネットワークインタフェース３０４を含んでおり、これは、有線インタフェース（たとえば、イーサネット（登録商標））または無線インタフェース（ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）など）であってよい。代替として、ネットワーク・インタフェース・モジュール１０４は、ケーブルＴＶインタフェースまたは他のタイプのインタフェースで通信することが可能である。このようなＣＴＶインタフェースは、ビデオフォーマットと同時共存する副搬送波双方向通信機能を提供する。

【0054】

ネットワーク・インタフェース・モジュール３００はまた、記憶装置３５０と通信する。図示した実施形態では、記憶装置３５０を、ネットワーク・インタフェース・モジュール３００とは別であるように示したが、実装によっては、記憶装置３５０は、ネットワーク・インタフェース・モジュール３００に含まれる。さらに、図示していないが、ネットワーク・インタフェース・モジュール３００は、通信プログラムコードを実装するプロセッサを含むことが可能である。同様に、図示していないが、ネットワーク・インタフェース・モジュール３００は、看護師が状況情報を入力するための入力装置と、ネットワーク・インタフェース・モジュール３００からの出力を受けるディスプレイとを含むことが可能である。

【0055】

ネットワーク・インタフェース・モジュール３００は、手持ち型、可搬型、または据置型の患者監視プラットフォームまたは計器に組み込むことが可能であり、また、そのような装置に対する汎用インタフェースとしてのＲＳ２３２入力を有するアクセサリパッケージに収容することが可能である。別の実施形態では、（図示していない）アクティブＲＦＩＤタグ機能を、ネットワーク・インタフェース・モジュール１０６、または臨床担当者用装置（たとえば、通知装置）、またはこの両方に含めることにより、イベントの発生時、または要求に応じて、患者または臨床担当者の位置を特定することが可能になる。また、共用ネットワークでの動作時には、ネットワーク・インタフェース・モジュール１０６は、オープンアーキテクチャ通信規格であるＩＥＥＥ ８０２．ＩＸ（セキュリティおよび認可）、ＩＥＥＥ ８０２．３（イーサネット（登録商標））、およびＷｉＦｉ（ＩＥＥＥ ８０２．１１ａ、ｂ、ｇ、ｅ、ｉ無線プロトコル）に準拠している。

【0056】

ネットワーク・インタフェース・モジュール３００内の状況管理モジュール３１０が、状況データを管理する。一実施形態では、状況管理モジュール３１０は、図１に関して既述した状況情報などの状況情報を受信する。一実施形態では、患者が入院したとき、または病院内の特定のベッドを割り当てられたときに、看護師または他の臨床担当者が、状況情報（患者名、識別番号、場所など）をキーボードまたは他の入力装置（図示せず）からネットワーク・インタフェース・モジュール３００に入力する。他の実施形態では、状況管理モジュール３１０が、図１のサーバ１３６のようなサーバから状況情報を受信する。

【0057】

状況管理モジュール３１０は、センサ処理モジュールから受信した生理学的情報に状況情報を関連付ける。特定実施形態では、状況管理モジュール３１０は、この関連付けを、アラーム状態の発生時に実行する。そのような場合、状況管理モジュール３１０は、履歴生理学的情報のスナップショットと状況情報とをまとめた状況データパッケージを作成することが可能である。他の実施形態では、状況管理モジュール３１０は、関連付けを連続的に実行し、ネットワーク・インタフェース・モジュール３００は、連続的な、またはスケジュールされた状況データパッケージをエンドユーザに送信する。さらに、ネットワーク・インタフェース・モジュール３００内の状況管理モジュール３１０または他のモジュールは、状況データパッケージを記憶装置３５０に格納する。

【0058】

通信モジュール３２０は、ネットワークインタフェース３０４を用いてネットワークと通信する。特定実施形態では、通信モジュール３２０は、Ｗｅｂサーバの機能性を保有する。通信モジュール３２０は、Ｗｅｂサーバとして、ネットワーク・インタフェース・モジュール３００が、サーバを用いずに、病院ネットワークおよびインターネットと直接通信することを可能にする。したがって、ネットワーク接続に対応していない生理学的監視装置のような他の装置を、ネットワーク・インタフェース・モジュールと接続してネットワーク対応にすることが可能である。ネットワーク・インタフェース・モジュール３００は、接続を開始および維持するために接続オーバヘッドを管理し、状況情報（たとえば、図１に関して既述した状況情報のいずれか）を管理し、Ｗｅｂ対応装置上に患者情報を表示するためのＷｅｂサーバを提供する。一実施形態では、ＸＭＬ技術をベースとする通信プロトコルにより、ベッドサイド装置が多数のターゲットエンドユーザプラットフォーム（ＰＤＡ、可動式コンピュータ（ＣＯＷ）、タブレットＰＣ、ＩＰ携帯電話（スマートフォン）、固定ＰＣなど）とインタフェースすることが可能になる。

【0059】

特定実施形態では、通信モジュール３２０は、標準通信プロトコルを用いてネットワークと通信する。標準通信プロトコルの例として、イーサネット（登録商標）、ＷｉＦｉ（ＷＬＡＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）などがある。通信モジュール３２０は、標準通信プロトコルを用いることにより、共用ネットワークまたはオープンネットワークアーキテクチャを経由してデータの送受信を行うことが可能である。しかしながら、通信モジュール３２０は、独自プロトコルを用いる独自ネットワークにも使用可能である。

【0060】

ネットワーク・インタフェース・モジュール３００が独自ネットワークではなく共用ネットワーク経由で通信を行う実施形態では、ネットワーク・インタフェース・モジュール３００は、ネットワークリソースを、ネットワーク上の他の装置と共用する。ネットワークトラフィックが大規模になると、ネットワーク通信の信頼性に影響が及ぶ場合がある。そこで、特定の実装のネットワーク・インタフェース・モジュール３００は、フロー制御モジュール３３０を含んでいる。フロー制御モジュール３３０は、送信されたデータがエンドユーザによって受信されたことを確認する。エンドユーザがデータを受信しなかった場合、フロー制御モジュール３３０は、記憶装置３５０に格納されているデータを再送信する。したがって、特定実施形態では、記憶装置３５０は、フロー制御バッファとして動作する。

【0061】

セキュリティモジュール３４０が、ネットワークインタフェース装置３００へのユーザアクセス、ならびに記憶装置３５０に格納されているデータへのユーザアクセスを管理する。特定実施形態では、セキュリティモジュール３４０は、ネットワーク・インタフェース・モジュール３００に接続しようとしているユーザが、そうすることを許可されているかどうかを判定する。一実装では、セキュリティモジュール３４０は、標準ＩＥＥＥ．８０２．ＩＸネットワークアクセス制御プロトコルを用いて認証を管理する。特定実施形態におけるネットワーク・インタフェース・モジュール１０６は、Ｈｅａｌｔｈ Ｉｎｓｕｒａｎｃｅ Ｐｏｒｔａｂｉｌｉｔｙ ａｎｄ Ａｃｃｏｕｎｔａｂｉｌｉｔｙ Ａｃｔ（ＨＩＰＡＡ）（医療保険の相互運用性と説明責任に関する法律）の要件を満たすセキュリティおよび暗号化を提供する。

【0062】

特定実施形態では、ネットワーク・インタフェース・モジュール３００は、ＩＥＥＥ １０７３規格と、ＩＥＥＥ １０７３規格に対する最新の更新、すなわち、ＩＥＥＥ １１７０３規格とで指定される機能性のすべてまたは一部を組み込んでいる（ＩＥＥＥ １０７３および１１７０３規格はいずれも参照によって本明細書に組み込まれている）。特定実施形態では、状況管理モジュール３１０、通信モジュール３２０、フロー制御モジュール３３０、およびセキュリティモジュール３４０は、ＩＥＥＥ １０７３および１１７０３規格で指定される機能性も組み込んでいる。標準プロトコルを用いることにより、ネットワーク・インタフェース・モジュール３００を用いて、非常に様々な生理学的監視装置をネットワーク通信に対応させることが可能である。

【0063】

図４は、本発明の一実施形態による、状況に基づいて生理学的情報を伝達する方法４００を示す。特定実施形態では、方法４００は、図１～３に関して既述したネットワーク・インタフェース・モジュールのいずれかによって実行される。さらに、特定実施形態における方法４００は、図１、２、および５に関して記載されるいずれかの生理学的監視システムによって実行可能である。

【0064】

方法４００では、まず、４０２で、状況情報を受信する。一実施形態では、ネットワーク・インタフェース・モジュールのような装置が、状況情報を一度（初期化ステップなどにおいて）受信する。次に方法４００は、４０４で、生理学的情報を受信する。特定実施形態では、方法４００は、方法４００の残りのステップの全体にわたって生理学的情報の受信を続ける。代替として、方法４００は、方法４００の一部において生理学的情報４００を受信してもよい。

【0065】

４０５で、方法４００は、アラーム状態またはアラートが発生しているかどうかを判定する。アラーム状態またはアラートが発生している場合、方法４００は４０６に進む。一方、アラーム状態またはアラートが発生していない場合、方法４００は４０４に戻る。一実施形態では、方法４００が４０４に戻ることは、アラーム状態またはアラートが発生するまでネットワーク・インタフェース・モジュールが生理学的情報を連続して受信することを表す。特定実施形態（図示せず）では、方法４００は、アラーム状態またはアラートが発生した場合でも生理学的情報の受信を続けてよい。

【0066】

４０６で、方法４００は、状況データパッケージを用意する。状況データパッケージは、状況情報と、生理学的情報のスナップショットとを含むことが可能である。一実施形態では、生理学的情報のスナップショットは、アラームまたはアラートを引き起こした生理学的情報を含む。一実施形態では、生理学的情報のスナップショットは、アラームまたはアラートの発生前後の情報を含む。状況データパッケージは、４０８で、フロー制御バッファに格納される。

【0067】

４１０で、方法４００は、ネットワーク接続を確立する。一実施形態では、４１０でネットワーク接続を確立することは、ネットワーク・インタフェース・モジュールをエンドユーザ装置（たとえば、勤務シフト中の看護師に割り当てられた通知装置）に接続することを含む。次に方法４００は、４１２で、エンドユーザ装置のユーザ（たとえば、看護師）が認証済みかどうかを判定する。ユーザが認証済みでない場合、方法４００は４２０に進む。一方、ユーザが認証済みである場合、方法４００は４１４に進む。

【0068】

方法４００は、４１４で、状況データパッケージをユーザに伝達する。４１６で、方法４００は、状況データパッケージが受信されたかどうかを判定する。状況データパッケージが受信された場合、方法４００は４２０に進む。受信されていない場合、方法４００は４１８に進み、４１８で、フロー制御バッファに格納されているデータにアクセスする。一実施形態では、この、方法４００でアクセスされるデータは、４１４でユーザに伝達された状況データパッケージと同等またはほぼ同等である。

【0069】

次に方法４００は、４１４に戻り、４１４で、状況データパッケージをユーザに伝達（たとえば、再送信）し、次に、４１６で、パッケージが受信されたかどうかを再確認する。方法４００は、実装によっては、状況データパッケージが受信されるまで、ステップ４１４、４１６、および４１８の間のループを続ける。したがって、特定実施形態におけるステップ４１４、４１６、および４１８は、方法４００で実行されるフロー制御を構成している。これらのフロー制御ステップにより、方法４００は、共用ネットワークにおいて発生しうるネットワーク送信エラーを克服することが可能になる。

【0070】

状況データパッケージが受信された場合、方法４００は、４２０で、生理学的情報の監視を続けるかどうかの評価を行う。監視を続けることを決定した場合、方法４００は４０４に戻り、４０４で、生理学的情報の受信を続ける。一方、監視を続けないことを決定した場合、方法４００は終了する。

【0071】

方法４００の様々な実施形態では、アラーム状態がない場合でも、状況データパッケージまたは生理学的情報のみがユーザに送信される。さらに別の実施形態では、上記ステップのすべてより少ないステップが実行されたり、上記ステップが別の順序で実行されたりする。たとえば、方法４００は、４０４で生理学的情報を受信するステップを実行し、４０６で状況データパッケージを用意するステップを実行し、４１０でネットワーク接続を確立するステップを実行し、４１４で状況データパッケージをユーザに伝達するステップを実行するだけでもよい。

【0072】

図５は、本発明の特定実施形態によるアラーム通知システム５００を示す。臨床サブシステム５１０が、アラーム通知システム５００の主要ソフトウェアコンポーネントを定義しており、これには、臨床割り当てモジュール５１２、ベッドサイド装置初期化モジュール５１４、通知および表示モジュール５１６、エスカレーション・ルール・モジュール５１８、臨床報告モジュール５２０、および臨床データ格納モジュール５２２が含まれる。ＨＩＰＡＡおよび病院ＩＴ方針に準拠したモバイルコンピューティング装置には、認証機能が組み込まれている。

【0073】

臨床割り当てモジュール５１２は、割り当て機能を有する。看護監督者は、各シフトの開始時および新しい患者の入院時に、個々の看護師を特定の患者に割り当てる。シフト割り当てが行われるのは、「報告」移行活動時のシフト変更においてであり、ここで、前のシフトからの個々の看護師および看護監督者が患者を次のシフトに「引き継ぐ」。この報告は、病院の看護サービス方針および手続きに応じて、全看護師が出席する公式なものであっても、非公式なものであってもよい。臨床割り当てモジュール５１２は、割り当て可能な看護師のリストに個々の患者を割り当てることを可能にする、直観的なインタフェースを提供する。このモジュールの主なユーザは、看護監督者から任命された病棟事務員である。看護師には、１人以上の患者、または全患者を割り当てることが可能である。代替の作業フローとして、自己割り当てがある。これは、個々の看護師が自身に患者を割り当てるものであり、この場合は、看護師が病棟事務員の役割を果たす。自己割り当てモデルでは、割り当てのない患者がいれば、その患者は全看護師または看護監督者に割り当てられるのがデフォルトの実施態様である。

【0074】

ベッドサイド装置初期化モジュール５１４は、上述のネットワーク・インタフェース・モジュールのようなベッドサイド装置であって、看護助手によってセットアップされることがある。看護師がこの作業を行う場合には、看護師が看護助手の役割を果たすことになる。作業フローに含まれるのは、装置をベッドサイドに設置すること、センサを装着すること、装置を初期化すること、名前、ＩＤ、場所などの患者状況を設定することなどである。

【0075】

通知および表示モジュール５１６は、無線通知装置（単方向ページャ、ＰＤＡ、ＩＰ電話、ＣＯＷ、またはタブレット）を個々の看護師に割り当てる。この装置は、各看護師に関連付けられる。臨床割り当てモジュール５１２に基づいて、アラームが通知装置に向けて経路設定される。病院が保有するページングシステムが看護師に支給される場合のような非専用通知装置ソリューションは、待ち時間特性が不明である。サーバでは、ベッドサイド装置からの受信後の待ち時間が１秒未満である汎用インタフェースが利用可能であり、この汎用インタフェースは、サーバ外部インタフェースへの提示時にタイムスタンプがなされ、タイムスタンプはサーバ内のジャーナリングシステムに格納される。ＰＤＡ、ＣＯＷＳ、タブレットなどのモバイルコンピューティングプラットフォーム用のインタフェースを追加することにより、個々の患者の現在のデータおよび動向データの表示が可能になる。

【0076】

エスカレーション・ルール・モジュール５１８は、病院によって定義されたエスカレーションポリシーを発動させるルールエンジンを有する。エスカレーション・ルール・モジュール５１８は、アラームへの対応がない場合、またはアラームが（たとえば、ポリシーによって）事前定義された時間にわたって持続している場合に、代替および追加の臨床ユーザに向けてアラームの代替経路設定を行う。特定実施形態におけるエスカレーション・ルール・モジュール５１８は、緊急対応チームに向けてアラームの経路設定を行う。

【0077】

臨床報告モジュール５２０は、生理学的状態および／または進行を判断する材料となる臨床データに関して、事前定義されたフォーマットで報告を行う。エンドユーザの必要に応じて、２つ以上の報告が可能である。報告は、個々の患者に関するタイムクリティカルな表示ではなく、アラーム通知システム５００の特権を有し、アラーム通知システム５００によって認証済みの臨床担当者が離れた場所から見ることが可能である。これらの報告は、Ｗｅｂブラウザ表示であって、臨床担当者は、時間およびパラメータの尺度やアラームの再表示などの表示パラメータを設定することが可能である。

【0078】

臨床データ格納モジュール５２２は、当業者であれば既知であるように、情報を格納するためのデータ記憶装置およびデータベースリソースを提供する。

【0079】

図５はさらに、技術的サポートサブシステム５３０を示しており、これは、ＨＩＰＡＡに準拠した臨床サブシステム５１０と隔離されており、したがって、リスク報告モジュール５３８を除いて、どの患者情報も閲覧できず、アクセスできない。技術的サポートサブシステム５３０は、プロビジョニングモジュール５３２、管理モジュール、サービスモジュール５３６、リスク報告モジュール５３８、および技術的データ格納モジュール５４０を含んでいる。

【0080】

プロビジョニングモジュール５３２は、プロビジョニング、すなわち、システムおよび顧客の初めての使用の初期インストールを提供する。プロビジョニングモジュール５３２の主なユーザは、フィールドインストール担当者である。プロビジョニングモジュール５３２は、システムを出荷用梱包から出してアラーム通知システム５００の機能性を完全なものにするためのスタートアップスクリプトおよびシステム構成をすべて収容している。プロビジョニングは、顧客現場の個々の装置、ページャのような通知装置、ＰＤＡ、ＣＯＷ、テーブル、およびＩＰ電話を、好ましくは無線手段（たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標））によって構成するステップを含んでいる。

【0081】

管理モジュール５３４は、ユーザのセットアップ、各種の役割別特権に関するポリシー（看護助手はアラームの設定または変更ができる、など）の設定、許可される装置接続の識別ならびに他の、ＩＴシステムによくある一般システム管理業務のセットアップを、アプリケーション管理者が行うためのシステムインタフェースを提供する。

【0082】

サービスモジュール５３６は、リモートサービス、ＩＴサービス、生物医学的サービスなどの様々な技術的サポート担当者のためのインタフェースを提供する。これらの各担当者は、互いの役割を実行してよい。サービス担当者は、インタフェースを用いて、システム性能データにアクセスすることにより、性能、たとえば、データトラフィック、接続されている装置資産、ソフトウェアバージョン管理、ＣＰＵローディング、ネットワークローディングなどにアクセスすることが可能になり、また、リモート技術的サービス手続き、たとえば、プリンタキューのリセット、ディスクの再パーティション、ソフトウェアパッチのアップロードなどを実行することが可能になる。サービスモジュール５３６は、システムによってキャプチャ可能なすべてのユーザ対話または一部のユーザアクション（特に、デフォルト値やアラーム設定の変更）を格納する、完全なジャーナリング機能を含んでいる。

【0083】

リスク報告モジュール５３８は、ＪＣＡＨＯ、他の規制団体、および内部品質保証委員会の要求に照らしてアラームに対する臨床的対応の全体的な効果を判定するための、アラーム発生、アラーム継続時間、アラームから臨床的対応までの時間、および他の統計データに関する要約報告を提供する。

【0084】

技術的データ格納モジュール５４０は、技術的データに関して用いられる点以外は、臨床データ格納モジュール５２２と同等の特性を有する。技術的データ格納モジュール５４０は、臨床データ格納モジュール５２２と同じ物理的かつ論理的エンティティを共用してもしなくてもよい。

【0085】

図５はさらに、外部インタフェースサブシステム５５０を示しており、これは、ベッドサイド装置および外部システムとのインタフェースを提供するものであり、たとえば、電子医療記録、入院退院転院システム、ＰＯＣＳＡＧページャシステム、ミドルウェアエンジン（Ｅｍｅｒｇｉｎなど）、Ｗｅｂ／ＸＭＬ対応装置（無線ＰＤＡ、ＣＯＷ、タブレットＰＣなど）などとのインタフェースを提供する。外部インタフェースサブシステム５５０は、ＨＬ７インタフェース５５２、ページャインタフェース５５４、ＸＭＬ／Ｗｅｂインタフェース５５６、および装置インタフェース５５８を有する。

【0086】

ＨＬ７インタフェース５５２は、電子医療記録（ＥＭＲ）に対する双方向インタフェースを提供し、プッシュモデルおよびプルモデルの両方をサポートしている。プッシュモデルは、ベッドサイドの看護師がデータ転送を起動する場合である。プルモデルは、ＥＭＲシステムがアラーム通知システム５００サーバをポーリングする場合である。ページャインタフェース５５４は、外部ページングシステムへの出力を提供する。メッセージ待ち時間は、どのようなユーザ保有のページングソリューションの場合も、エンドユーザに特定される。この同じ出力を、Ｅｍｅｒｇｉｎのようなミドルウェアアラーム通知システムに用いることが可能である。ＸＭＬ／Ｗｅｂインタフェース５５６は、モバイルコンピューティングプラットフォーム（無線ＰＤＡ、ＣＯＷ、テーブル、Ｗｅｂ対応ＩＰフォンなど）との双方向インタフェースを提供する。モバイルコンピューティングプラットフォームは、ＷｅｂブラウザのＸＭＬアプリケーションをサポートしている。装置インタフェース５５８は、ベッドサイド装置ならびに他の、通信モジュールまたはアクセサリに対応する装置に対する双方向インタフェースを提供する。他のベッドサイド装置にインタフェースするためのオプションとして、アプリケーションプログラマインタフェース（ＡＰＩ）機能がある。

【0087】

アラーム通知システム５００システムの（簡潔さのために図示または記載していない）主なエンドユーザは、病院電子医療記録、入院退院転院、調剤、臨床情報、患者フロー追跡などを含む。各担当者（たとえば、アラーム通知システム５００のユーザ）は、臨床担当者および技術的サポート担当者を含んでいる。臨床担当者は、看護監督者、病棟事務員、看護助手、看護師、即応チーム、呼吸療法士などである。

【0088】

看護監督者は、各シフトの開始時に個々の看護師を特定の患者に割り当てる。シフトは、病院の要員配置方針に応じて変わる可能性がある。病棟事務員は、看護監督者から指示を受け、典型的には、割り当てをシステムに入力し、システム全体を監視する。病棟事務員は、すべてのシフトにわたって待機していなくてもよい。看護助手は、看護師または看護監督者から割り当てを受け、典型的には、ベッドサイド装置センサを装着し、ベッドサイド装置を初期化し、アラームをデフォルト値に設定する。看護師は、個々の患者の看護と、アラームへの最初の対応とに主たる責任を有する。看護監督者は、看護師のスキルと患者のニーズとに応じて２人以上の患者を看護師に割り当てる。看護師には、いつも同じ患者が割り当てられるわけではない。看護助手は、どの病院にもいるわけではない。

【0089】

即応チームは、ベッドサイドの看護師または看護監督者から発動された臨床緊急事態に対応する。即応チームは、２つ以上の治療室をサポートし、シフトに応じて１人以上のメンバーを有する。即応チームは、すべての病院に配備されなくてもよい。呼吸療法士は、２人以上の患者、ならびに通常は２つ以上の治療室の呼吸治療を管理する責任を有する。一部の国際環境では、呼吸療法士を置かない。

【0090】

臨床担当者の作業置換により、能力の高い担当者が他の担当者の役割を担うことが可能である。アラーム通知システム５００は、そのようなことを実行するためのメカニズムを可能にする。たとえば、看護監督者は、病棟事務員、看護助手、看護師、および即応チームの役割を果たすことが可能である。看護師は、病棟事務員、看護助手、および即応チームの役割を果たすことが可能である。一部の国際市場では、看護師が呼吸療法士の役割を果たすことが可能である。

【0091】

技術的サポート担当者は、フィールドインストール担当者、アプリケーション管理者、リモートサービス、ＩＴ技術者、生物医学技術者、リスク管理者などである。フィールドインストール担当者は、初期インストールのためのシステムのプロビジョニングを行い、各コンポーネントをインストールし、インストールおよび構成が購買契約を満たすかどうかを検証する。アプリケーション管理者は、ユーザアカウントおよびシステムをデフォルトにセットアップし、維持する。リモートサービスは、ダイヤルアップやＶＰＮのようなリモートリンクを経由するリモート診断およびシステムメンテナンスを提供する。ＩＴ技術者は、システムが病院ＩＴネットワークと一体化されている場合に、ネットワークサポートサービスを提供する。生物医学技術者は、ベッドサイドおよびシステムの一次サービスを提供する。リスク管理者は、品質およびリスク軽減のために報告を精査する。技術的サポート担当者は、他の担当者の代わりを務めることもある。たとえば、ＩＴ技術者、生物医学技術者、またはリモートサービスは、アプリケーション管理者の役割を果たすことも可能である。ＩＴ技術者または生物医学技術者は、互いの役割を果たすことも可能である。

【0092】

特定実施形態では、生理学的動向データを迅速に格納および取得するシステムおよび方法を提供する。たとえば、医療患者から取得された生理学的情報を、ラウンドロビンデータベースに格納することが可能である。ラウンドロビンデータベースは、生理学的情報を、時間的に等間隔である一連のレコードの形で格納することが可能である。パラメータ記述子を用いると、レコード内のパラメータ値を識別することが可能である。パラメータ記述子を変更することによって、パラメータ値を動的に更新することが可能であり、これによってデータベースがフレキシブルになる。さらに、データベースに用いるファイルのサイズは、患者の状態に応じて、動的に調節することが可能である。

【0093】

さらに、特定実施形態では、臨床ネットワークの生理学的監視器から取得された医療データを、ジャーナルデータベースに格納またはジャーナリングすることが可能である。この医療データは、臨床担当者と１つ以上の医療装置との対話に対する応答として発生した装置イベントを含むことが可能である。医療イベントデータは、装置から発動されたイベント（アラームなど）を含むことも可能である。ジャーナルデータベースに格納された医療データを分析して統計または指標を導出することが可能であり、これらを用いて、臨床担当者および／または病院の作業成果を向上させることが可能である。

【0094】

本明細書で用いる用語「ラウンドロビンデータベース」および「ＲＲＤＢ」は、その本来の意味に加えて、本明細書で開示される独特の特性および特徴を有する、改良されたデータベース構造を示す場合もある。本明細書では、これらの構造を動的ＲＲＤＢまたは適応ＲＲＤＢと称することもある。

【0095】

図６は、臨床ネットワーク環境６００の一実施形態を示す。臨床ネットワーク環境６００は、１つ以上の患者監視器６４０、看護師詰所システム６３０、および臨床担当者装置６５０とネットワーク６１０経由で通信する多患者監視システム（ＭＭＳ）６２０を含んでいる。特定実施形態では、ＭＭＳ ６２０は、患者監視器６４０から取得された生理学的データを、看護師詰所システム６３０および／または臨床担当者装置６５０に提供する。さらに、特定実施形態では、ＭＭＳ ６２０は、生理学的情報および医療イベント情報を、後刻の分析のために格納する。

【0096】

臨床ネットワーク環境６００のネットワーク６１０は、ＬＡＮまたはＷＡＮ、無線ＬＡＮ（「ＷＬＡＮ」）、または他のタイプの、任意の病院、介護施設、患者治療拠点、または他の臨床施設で使用されるネットワークであってよい。説明を容易にするために、本明細書の残りの部分では、病院という状況における臨床環境を説明するが、本明細書に記載の特徴は、他の臨床施設または設定でも用いることが可能であることを理解されたい。実装によっては、ネットワーク６１０は、複数の病院または臨床施設にある装置と相互接続可能であり、これらの装置は、インターネット、リース回線などを介して、互いに離れていてよい。同様に、臨床ネットワーク環境１００の各種装置６２０、６３０、６４０、および６５０は、地理的に（たとえば、複数の病院に）分散していてよく、あるいは、同じ場所（たとえば、単一病院内）にあってもよい。

【0097】

患者監視器６４０は、医療患者に結合されたセンサによって検出される生理学的信号を監視するポイントオブケア（ＰＯＣ）計器などであってよい。患者監視器６４０は、信号を処理して、様々な生理学的パラメータのいずれかを求めることが可能である。生理学的パラメータの一例として、血液酸素飽和度（ＳｐＯ_２）がある。生理学的パラメータの他の例については、後で図７に関して説明する。

【0098】

患者監視器６４０は、生理学的情報をＭＭＳ ６２０に提供することが可能である。患者監視器６４０はまた、アラームなど、医療イベントに関する情報をＭＭＳ ６２０に提供することも可能である。アラームは、たとえば、生理学的パラメータが正常範囲から逸脱することに対する応答としてトリガ可能である。アラームはまた、センサが患者から脱落したプローブオフ状態のような、機器の障害に関するアラートを含むことも可能である。後で、医療イベントの他の例を図７に関して説明する。

【0099】

様々な実施形態において、患者監視器６４０は、生理学的情報および医療イベントをＭＭＳ ６２０に提供する。ＭＭＳ ６２０については、後で詳述する。実装によっては、患者監視器６４０は、この情報の少なくとも一部を看護師詰所システム６３０および臨床担当者装置６５０に直接提供することが可能である。

【0100】

看護師詰所システム６３０は、看護師詰所に配置されるデスクトップコンピュータ、ラップトップ、ワークステーションなどであってよい。看護師詰所には、１つ以上の看護師詰所コンピュータ６３０を配置することが可能である。看護師詰所コンピュータ６３０は、ＭＭＳ ６２０（または監視器６４０）から生理学的情報およびアラームデータを受信して表示することが可能である。特定実施形態では、看護師詰所コンピュータ６３０は、生理学的情報および医療情報を、合理化された、一目でわかるビューで提供するグラフィカル・ユーザ・インタフェース（ＧＵＩ）を使用している。このＧＵＩの一例を、後で図９に関して説明する。

【0101】

臨床担当者装置６５０は、臨床担当者が使用する様々な装置のいずれかであってよく、たとえば、ページャ、携帯電話、スマートフォン、個人用携帯端末（ＰＤＡ）、ラップトップ、タブレットＰＣ、パーソナルコンピュータなどであってよい。実施形態によっては、臨床担当者装置６５０は、生理学的情報およびアラームをＭＭＳ ６２０（または監視器６４０）から受信することが可能である。生理学的データおよびアラームデータは、特定の臨床担当者装置６５０に、たとえば、アラームに対する応答として、提供可能である。場合により、臨床担当者装置６５０は、生理学的パラメータの値および波形を受信することが可能である。

【0102】

特定実施形態におけるＭＭＳ ６２０は、ネットワーク６１０内のネットワークトラフィックを管理するためのハードウェアおよび／またはソフトウェアを有する１つ以上の物理コンピューティング装置（サーバなど）を含んでいる。このハードウェアおよび／またはソフトウェアは、機能別に、複数の異なるサーバ６２０に、論理的かつ／または物理的に分割可能であり、それらは、たとえば、通信サーバ、Ｗｅｂサーバ、データベースサーバ、アプリケーションサーバ、ファイルサーバ、プロキシサーバなどである。

【0103】

ＭＭＳ ６２０は、標準化されたプロトコル（ＴＣＰ／ＩＰなど）または独自プロトコルを用いて、患者監視器６４０、看護師詰所コンピュータ６３０、および臨床担当者装置６５０と通信可能である。一実施形態では、患者監視器６４０がＭＭＳ ６２０との接続を求めた場合、ＭＭＳ ６２０は、その患者監視器６４０を認証し、患者監視器６４０に結合された患者の状況情報を患者監視器６４０に提供することが可能である。状況情報は、いろいろなものを含んでよいが、特に、患者のデモグラフィ、患者のアラーム設定、および患者に対する臨床担当者の割り当てを含んでよい。状況情報の例を本明細書に記載している。ＭＭＳ ６２０は、この状況情報を、患者の入院情報が与えられている看護師詰所システム６３０または他の病院コンピュータシステムから取得可能である。

【0104】

ＭＭＳ ６２０は、患者監視器６４０に接続するとただちに、生理学的情報および医療イベントを患者監視器６４０から受信することが可能である。ＭＭＳ ６２０は、それらの生理学的情報および医療イベントの少なくとも一部を看護師詰所システム６３０および／または臨床担当者装置６５０に提供することが可能である。たとえば、ＭＭＳ ６２０は、複数の患者監視器６４０に関する生理学的データおよびアラームを看護師詰所システム６３０に提供することが可能であり、看護師詰所システム６３０では看護師がそのデータおよび／またはアラームを評価して患者の治療方法を決定することが可能である。同様に、ＭＭＳ ６２０は、無線ページ、電子メール、インスタントメッセージなどを臨床担当者装置６５０に送信することにより、生理学的データおよびアラームを臨床担当者に提供することが可能である。

【0105】

有利なことに、特定実施形態では、ＭＭＳ ６２０は、患者監視器６４０から取得した生理学的情報をラウンドロビンデータベース（ＲＲＤＢ）６２４に格納することが可能である。様々な実施形態のＲＲＤＢ ６２２は、患者データの迅速な格納および取り出しを容易にする、合理化されたデータベース構造を有する。したがって、ＲＲＤＢ ６２２は、特定実施形態では、生理学的動向データを迅速に看護師詰所６３０および臨床担当者装置 ６５０に提供することに用いることが可能である。したがって、たとえば、臨床担当者が特定時間帯（たとえば、過去１時間）にわたる患者の生理学的動向を見たい場合、臨床担当者は、看護師詰所コンピュータ６３０または臨床担当者装置 ６５０を用いてＭＭＳ ６２０に問い合わせることが可能である。そして、ＭＭＳ ６２０は、所望の時間帯に対応する生理学的情報をＲＲＤＢ ６２２から取得することが可能である。有利なことに、ＲＲＤＢ ６２２は、動向データをより迅速に取得できるようにすることが可能であるため、病院監視システムで現在使用されているリレーショナルデータベースを用いることが可能である。ＲＲＤＢ ６２２のさらなる用法および最適化については後述する。

【0106】

特定実施形態では、ＭＭＳ ６２０はまた、医療イベントに関する情報をジャーナルデータベース６２４にアーカイブまたは格納する。医療イベントは、患者監視器６４０、看護師詰所システム６３０、および臨床担当者装置６５０のような装置によって記録されたイベントを含むことが可能である。具体的には、医療イベントは、臨床担当者と装置との対話に対する応答として発生する装置イベント（たとえば、臨床担当者の指示によるアラームの機能停止）を含むことが可能である。医療イベントはまた、臨床担当者と装置との対話がなくても発生する装置イベント（たとえば、アラームそのもの）も含むことが可能である。医療イベントのさらなる例については、後で図７に関して説明する。

【0107】

ＭＭＳ ６２０は、ジャーナルデータベース６２４に格納された医療イベント情報を分析して、医療イベントに関する統計を導出することが可能である。たとえば、ＭＭＳ ６２０は、アラームイベントおよびアラーム機能停止イベントを分析して、アラームから臨床的対応までの時間を求めることが可能である。ＭＭＳ ６２０は、これらの統計を用いて、臨床担当者および／または病院の作業成果に関する報告を生成することが可能である。有利なことに、特定実施形態では、これらの統計および報告を用いて、臨床担当者および病院の作業成果を向上させることが可能である。

【0108】

たとえば、特定状況では、これらの報告は、病院が問題の原因を患者監視器６４０で見つけることに役立ちうる。以下のシナリオ例は、そのような報告の潜在的利点を示すことができる。ＳｐＯ_２アラームレベルは、成人と新生児とで異なる傾向がある。しかしながら、臨床担当者によってはこのことが知られていない場合があり、新生児用ＳｐＯ_２監視器に成人のアラームレベルを含める変更が行われる可能性がある。このような変更は、誤アラームの多発を引き起こす可能性があり、これによって、臨床担当者は、苛立ったり、患者監視器６４０の使用を避けたりする可能性がある。臨床担当者によるアラーム変更のような医療イベントをジャーナリングし、ジャーナリングされたデータを分析することにより、臨床担当者が新生児用監視器のアラーム設定を不適切に調節していたことが判明する可能性がある。その場合、病院は、この情報を用いて是正措置を行うことが可能である（たとえば、アラーム限界を固定し、臨床担当者のトレーニングを行うなど）。

【0109】

図示していないが、臨床ネットワーク環境６００内に管理装置を設けることが可能である。管理装置は、病院管理者、ＩＴ担当者などが操作するコンピューティング装置を含むことが可能である。たとえば、ＩＴ担当者は、管理装置を用いて、複数の患者監視器６４０、看護師詰所システム６３０、およびＭＭＳ ６２０に変更を周知させることが可能である。また、管理装置によって、ＩＴ担当者は、サードパーティシステム（たとえば、電子医療記録（ＥＭＲ）システム）をＭＭＳ ６２０とインタフェースさせることが可能になる。たとえば、サードパーティシステムを用いることにより、複数の監視器のアラーム設定の変更を管理装置から行うことが可能になる。一般に、管理者、ＩＴ担当者、および管理装置によって行われるアクションも、ジャーナルデータベース６２４にジャーナリングすることが可能である。

【0110】

図７は、臨床ネットワーク環境７００のより詳細な実施形態を示す。臨床ネットワーク環境７００は、ネットワーク７１０と、患者監視器７４０と、看護師詰所システム７３０と、ＭＭＳ ７２０と、ＲＲＤＢ ７２２と、ジャーナルデータベース７２４とを含んでいる。これらのコンポーネントは、図６に関して上述した機能性をすべて含んでよい。説明を簡単にするために、監視器７４０および看護師詰所システム７３０は１つずつ図示した。さらに、図示していないが、上述した臨床担当者装置７５０も、臨床ネットワーク環境７００に含めることが可能である。

【0111】

患者監視器７４０の図示した実施形態は、監視モジュール７４２、ＲＲＤＢモジュール７４４、およびジャーナルモジュール７４６を含んでいる。これらのモジュールのそれぞれは、ハードウェアおよび／またはソフトウェアを含んでよい。他のコンポーネント（通信モジュールなど）は図示していないが、様々な実装において患者監視器７４０に含めてよい。

【0112】

監視モジュール７４２は、患者に結合された１つ以上のセンサから発生した生理学的信号を監視することが可能である。監視モジュール７４２は、信号を処理して、様々な生理学的パラメータのいずれかを求めることが可能である。たとえば、監視モジュール７４２は、脈拍数、プレチスモグラフ波形データ、灌流指数、体内組織中の血液成分の各値などの生理学的パラメータを求めることが可能であり、血液成分の各値としては、たとえば、動脈血一酸化炭素飽和度（「ＨｂＣＯ」）、メトヘモグロビン飽和度（「ＨｂＭｅｔ」）、総ヘモグロビン（「ＨｂＴ」または「ＳｐＨｂ」）、動脈血酸素飽和度（「ＳｐＯ_２」）、動脈血酸素飽和分率（「ＳｐａＯ_２」）、酸素含有量（「ＣａＯ_２」）などがある。

【0113】

さらに、監視モジュール７４２は、音響センサから生理学的情報を取得することが可能であり、これは、呼吸数、吸気時間、呼気時間、吸気時間呼気時間比、吸気流、呼気流、一回換気量、分時拍出量、無呼吸継続時間、呼吸音、ラ音、水泡音、喘鳴、呼吸音の変化（空気流量の減少または空気流の変化など）などを求めるために行う。さらに、場合によっては、監視モジュール７４２は、他の生理学的音を監視し、それらは、（たとえば、プローブオフ検出に役立つ）心拍数、心音（たとえば、Ｓ１、Ｓ２、Ｓ３、Ｓ４、および心雑音）、心音の変化（たとえば、正常音から心雑音への変化や、体液過剰を表す分裂心音）などである。さらに、監視モジュール７４２は、心電図検査（ＥＣＧ）による、患者の心臓の電気的活動の監視や、他の様々な生理学的パラメータの監視を行うことが可能である。

【0114】

実装によっては、患者監視器７４０は、様々なデータ信頼性指標を求めることも可能であり、たとえば、参照によって開示の全体が本明細書に組み込まれている米国特許第７０２４２３３号明細書（件名「Ｐｕｌｓｅ ｏｘｉｍｅｔｒｙ ｄａｔａ ｃｏｎｆｉｄｅｎｃｅ ｉｎｄｉｃａｔｏｒ」）に記載されているデータ信頼性指標を求めることも可能である。また、患者監視器７４０は、灌流指数を求めることも可能であり、たとえば、参照によって開示の全体が本明細書に組み込まれている米国特許第７２９２８８３号明細書（件名「Ｐｈｙｓｉｏｌｏｇｉｃａｌ ａｓｓｅｓｓｍｅｎｔ ｓｙｓｔｅｍ」）に記載されている灌流指数を求めることも可能である。さらに、患者監視器７４０は、プレチスモグラフ変動指数（ＰＶＩ）を求めることも可能であり、たとえば、参照によって開示の全体が本明細書に組み込まれている米国特許出願公開第２００８／０１８８７６０号明細書（件名「Ｐｌｅｔｈｙｓｍｏｇｒａｐｈ ｖａｒｉａｂｉｌｉｔｙ ｐｒｏｃｅｓｓｏｒ」）に記載されているＰＶＩを求めることも可能である。本明細書に記載の各パラメータは、例に過ぎず、特定実施形態では他にも様々なパラメータを使用することが可能である。

【0115】

特定実施形態では、ＲＲＤＢモジュール７４４は、監視モジュール７４２から生理学的情報を受信し、この生理学的情報をネットワーク７１０経由でＭＭＳ ７２０に送信する。応答として、ＭＭＳ ２２０は、生理学的情報をＲＲＤＢ ７２２に格納することが可能である。有利なことに、特定実施形態では、ＲＲＤＢモジュール７４４は、生理学的情報をＭＭＳ ７２０に送信する前にパラメータ記述子に関連付ける。パラメータ記述子は、ＲＲＤＢモジュール７４４が生理学的パラメータの各測定値に関連付ける識別子であってよい。ＭＭＳ ７２０は、これらのパラメータ記述子を用いて、ＲＲＤＢモジュール７４４から受信した測定パラメータのタイプを識別することが可能である。

【0116】

パラメータ記述子は、マークアップ言語仕様、たとえば、拡張可能マークアップ言語（ＸＭＬ）仕様に従って生成された記述子であってよい。したがって、パラメータ記述子は、測定された生理学的値を囲むタグを含むことが可能である。これらのタグは、機械可読であっても人間可読であってもよい。たとえば、タグは、数値的識別子（たとえば、「００１７」）や記述的識別子（「ＳＰＯ_２」や「ＳＰＨＢ」など）を含んでよい。パラメータ記述子に関連付けられたＳｐＯ_２センサおよびＳｐＨｂセンサからの生理学的情報の簡略化されたストリーム例は、たとえば、＜ＳＰＯ２＞９６＜／ＳＰＯ２＞ ＜ＳＰＨＢ＞１４．１＜／ＳＰＨＢ＞ ＜ＳＰＯ２＞９７＜／ＳＰＯ２＞ ＜ＳＰＨＢ＞１４．０＜／ＳＰＨＢ＞（以降も続く）のようになる。

【0117】

一実施形態では、ＲＲＤＢモジュール７４４は、患者監視器７４０で利用可能な事前定義済みパラメータ記述子のセットを（たとえば、データファイルとして）格納しておくことが可能である。これらのパラメータ記述子は、患者監視器７４０で測定可能な、予想されるパラメータに対応することが可能である。ＲＲＤＢモジュール７４４から送信されるパラメータ記述子は、患者監視器７４０で測定されるパラメータの特定のサブセットに依存してよい。

【0118】

患者監視器７４０によって、追加（または別）のパラメータが連続して測定される場合、ＲＲＤＢモジュール７４０は、ＭＭＳ ７２０に送信されたパラメータ記述子を動的に更新してよい。同様に、患者監視器７４０がいずれかのパラメータの測定を中止する場合、ＲＲＤＢモジュール７４４は、対応するパラメータ記述子をＭＭＳ ７２０に送信することを中止してよい。

【0119】

図示した実施形態では、患者監視器７４０はまた、ジャーナルモジュール７４６を含んでいる。ジャーナルモジュール７４０は、患者監視器７４０に関連する医療イベントを記録することが可能である。これらの医療イベントは、臨床担当者が発動させたイベントを含むことが可能であり、たとえば、アラーム設定（たとえば、最大および最小許容パラメータ値）、監視対象パラメータのタイプ、患者監視器７４０に接続されるセンサのタイプなどを変更することを含むことが可能である。ジャーナルモジュール７４６は、これらのイベントを記録することが可能であり、これは、たとえば、臨床担当者のボタン押しを記録するキーロガーなどとして動作することにより可能である。ジャーナルモジュール７４６はまた、センサまたはケーブルが患者監視器７４０に接続されたことを検出する電流検知回路などを含むことも可能である。医療イベントはまた、非臨床担当者が発動させたイベント（アラームやアラートなど）を含んでよい。医療イベントはまた、ネットワーク７１０の全体にわたるアラーム設定のＥＭＲ更新のような、管理装置（図示せず）からのイベントも含んでよい。

【0120】

ジャーナルモジュール７４６は、これらのイベントを、患者監視器７４０でローカルにログ記録することが可能である。ジャーナルモジュール７４６は、イベントをローカルにログ記録することに加えて、またはその代わりに、これらのイベントに関する情報をＭＭＳ ７２０に送信することが可能である。そして、ＭＭＳ ７２０は、このイベント情報をジャーナルデータベース７２４に格納することが可能である。

【0121】

看護師詰所システム７３０は、図示した実施形態では、患者監視クライアント７３２を有しているように示した。患者監視クライアント７３２は、看護師詰所システム７３０が生理学的情報およびアラーム情報を受信および表示できるようにすることが可能である。患者監視クライアント７３２は、ユーザ・インタフェース・モジュール７３４を含んでいる。ユーザ・インタフェース・モジュール７３４は、たとえば、複数の患者監視器７４０についての生理学的情報、患者情報、および医療イベント情報を表示するソフトウェアを含むことが可能である。ユーザ・インタフェース・モジュール７３４はまた、患者の入退院や装置アラーム限界のリモート変更などを臨床担当者が行えるようにすることも可能である。ユーザ・インタフェース・モジュール７３４で生成可能なユーザインタフェースの一例について、後で図９に関して説明する。

【0122】

患者監視クライアント７３２はさらに、ジャーナルモジュール７３６を含んでいる。ジャーナルモジュール７３６は、患者監視クライアント７３２に関連する医療イベントを記録するソフトウェアを含むことが可能である。たとえば、ジャーナルモジュール７３６は、どの臨床担当者が患者監視クライアント７３２にログインし、ログオフしたか、ならびにこれらのイベントがいつ発生したかを記録することが可能であり、入退院イベントを記録することが可能であり、他の、臨床担当者のキーストローク、マウスクリック、および患者監視クライアント７３２との対話を記録することが可能である。ジャーナルモジュール７３６は、このイベント情報を、看護師詰所システム７３０にローカルにログ記録したり、かつ／または、ＭＭＳ ７２０に送信したりすることが可能である。

【0123】

図示したように、ＭＭＳ ７２０は、ネットワーク管理モジュール７２１、ＲＲＤＢ管理モジュール７２３、およびジャーナル管理モジュール７２５を含むことが可能であり、これらのそれぞれが１つ以上のソフトウェアコンポーネントを含むことが可能である。一実施形態では、ネットワーク管理モジュール７２１は、生理学的情報および医療イベントデータを収容したメッセージを患者監視器７４０から受信する。ネットワーク管理モジュール７２１は、このデータの少なくとも一部を看護師詰所システム７３０および図６の臨床担当者装置６５０に提供することが可能である。ネットワーク管理モジュール７２１はまた、生理学的情報をＲＲＤＢ管理モジュール７２３に提供し、医療イベントデータをジャーナル管理モジュール７２５に提供することが可能である。

【0124】

特定実施形態では、ＲＲＤＢ管理モジュール７２３は、患者監視器７４０から受信した生理学的情報をＲＲＤＢ ７２２に格納する。患者監視器７４０が最初にＭＭＳ ７２０に接続したとき、または別のときに、ＲＲＤＢ管理モジュール７２３は、その患者監視器７４０に対応する１つ以上のＲＲＤＢファイルをＲＲＤＢ ７２２内に作成することが可能である。この１つ以上のファイルの内容は、患者監視器７４０のタイプに依存してよく、患者監視器７４０のシリアル番号、モデル番号、ベンダ識別子、これらの組み合わせなどによって定義可能である。ＲＲＤＢファイルの構造および内容の具体例が、参照により全内容が本明細書に組み込まれている米国特許出願公開第２００９／０１１９３３０号明細書に記載されている。

【0125】

ＲＲＤＢ管理モジュール７２３はまた、ＲＲＤＢに格納されている生理学的動向データを、監視器７４０、看護師詰所システム７３０、および／または臨床担当者装置への送信に備えて、ネットワーク管理モジュール７２１に与えることも可能である。ＲＲＤＢ管理モジュール７２３はまた、図８Ｂに関して後述する目的のために、ＲＲＤＢ ７２２にある生理学的データをジャーナル管理モジュール７２５に提供することも可能である。

【0126】

ジャーナル管理モジュール７２５は、特定の実装では、監視器７４０および看護師詰所システム７３０から医療イベントデータを受信し、このデータをジャーナルデータベース７２４に格納することが可能である。一実施形態では、ジャーナルデータベース７２４は、リレーショナルデータベースであるが、他の構造も使用可能である。イベントデータの各エントリは、イベントがいつ発生したかを示す、対応するタイムスタンプを有することが可能である。このタイムスタンプは、ジャーナルモジュール７４６または７３６、あるいはジャーナル管理モジュール７２５によって与えることが可能である。ジャーナル管理モジュール７２５はまた、医療イベントの発生回数を反映するイベントカウンタをジャーナルデータベース７２４に格納することが可能である。たとえば、ある時間帯に発生したアラームの数や、臨床担当者がネットワーク装置にログオンまたはログオフした回数をカウントするカウンタを格納することが可能である。

【0127】

有利なことに、ジャーナル管理モジュール７２５は、特定実施形態では、ジャーナルデータベース７２４内の医療データを分析して、臨床担当者および／または病院の作業成果の統計または指標を求めることが可能である。ジャーナル管理モジュール７２５は、これらの統計にアクセスするためのインタフェースを、看護師詰所システム７３０または別のコンピューティング装置のユーザに提供することが可能である。一例示的実施形態では、ジャーナル管理モジュール７２５は、アラームイベントおよびアラーム機能停止イベントを分析して、臨床担当者がアラームに対応するまでの時間を求めることが可能である。ジャーナル管理モジュール７２５はさらに、看護師の日中および夜間のシフトにおける臨床担当者の対応までの時間を求めることが可能である。ジャーナル管理モジュール７２５は、病院管理者が、たとえば、どのシフトの作業成果が他より良好かを判定できるように、これらの統計の報告を生成することが可能である。

【0128】

より一般的には、ジャーナル管理モジュール７２５は、ジャーナルデータベース７２４にあるデータから導出される様々な統計を分析して、臨床担当者および／または病院の作業成果に関する報告を生成することが可能である。報告の一例として、監視報告カードがあり、これは、導出された統計に少なくとも部分的に基づいて、所与の病院を他の病院と比べて（または、所与の看護師詰所を他の看護師詰所と比べて、など）格付けするものである。有利なことに、病院管理者、臨床担当者などは、これらの統計および報告を用いて、臨床担当者および病院の作業成果を向上させることが可能である。

【0129】

臨床ネットワーク環境７００の機能の一部またはすべては、特定実施形態に適応可能である。たとえば、ジャーナルモジュール７４６または７３６のいずれかまたは両方が、ジャーナル管理モジュール７２５の機能の一部またはすべてを実行することが可能である。同様に、１つ以上のジャーナルデータベース７２４を、患者監視器７４０および／または看護師ワークステーション７３０に格納することが可能である。同様に、ＲＲＤＢモジュール７２４は、ＲＲＤＢ管理モジュール７２３の機能の一部またはすべてを実行することが可能であり、ＲＲＤＢ ７２２は、患者監視器７４０に格納可能である。さらに、実装によっては、図６の臨床担当者装置６５０も同様にＲＲＤＢモジュールおよび／またはジャーナルモジュールを有することが可能である。他の実施形態では、他にも様々な適応、構成、および組み合わせが可能である。ＲＲＤＭの実施形態に関する追加情報が、米国特許出願公開第２００９／０１１９３３０号明細書に記載されている。

【0130】

図８Ａは、医療イベントをジャーナルデータベースにジャーナリングする方法８００Ａの一実施形態を示す。一実施形態では、方法８００Ａは、上述のＭＭＳのいずれか（たとえば、ＭＭＳ ６２０または７２０）によって実装可能である。具体的には、方法８００Ａは、ジャーナル管理モジュール７２５によって実装可能である。代替として、少なくともいくつかのブロックは、ジャーナルモジュール７３６、７４６によって実装可能である。有利なことに、特定実施形態では、方法８００Ａは、ジャーナリングされたデータに基づく報告の生成を容易にする。

【0131】

ブロック８０２では、医療イベントをジャーナルデータベースにジャーナリングする。ユーザ（たとえば、臨床担当者）からの報告要求に対する応答として、ブロック８０４で、医療イベントに関する統計をジャーナルデータベースから取得する。この統計は、医療イベントのタイプ、頻度、および継続時間、このイベントに関連付けられた臨床担当者または患者が誰かという情報、アラームに対応するまでの時間、これらの組み合わせなどを含むことが可能である。

【0132】

ブロック８０６で、この医療イベント統計に関する報告を生成する。ブロック８０８で、この報告を用いて、病院の作業を改善できる可能性のある領域を識別する。たとえば、この報告は、作業成果に基づいて病院または病院の臨床担当者にスコアを割り当てる「監視報告カード」であってよい。

【0133】

図８Ｂは、ジャーナルデータベースおよびＲＲＤＢにあるデータを相互に関連付ける方法８００Ｂの一実施形態を示す。一実施形態では、方法８００Ｂは、上述のＭＭＳのいずれか（たとえば、ＭＭＳ ６２０または７２０）によって実装可能である。具体的には、方法８００Ｂは、ＲＲＤＢモジュール７２３およびジャーナル管理モジュール７２５によって実装可能である。代替として、少なくともいくつかのブロックは、ＲＲＤＢモジュール７４４およびジャーナルモジュール７３６、７４６によって実装可能である。有利なことに、特定実施形態では、方法８００Ｂは、ＲＲＤＢにある生理学的情報と、医療イベントとを、時間に関して相互に関連付けることを可能にする。このような、イベントおよび生理学的データの再構築は、航空機の「ブラックボックス」技術と同種のものにすることが可能であり、これによって、ユーザは、医療インシデントに至るまでの臨床処置を再現することが可能になる。

【0134】

ブロック８１２では、ある時間帯に対応するジャーナリングされたデータおよび生理学的データをレビューする要求を、ユーザから受信する。ユーザは、患者の治療における問題の原因を特定したい臨床担当者、病院管理者などであってよい。たとえば、ユーザは、患者のＳｐＯ_２が安全レベルを下回ったときに臨床担当者が対応できなかった原因を特定したい場合がある。

【0135】

ブロック８１４では、指定時間帯のジャーナリングされたデータをジャーナルデータベースから取り出す。このブロックは、ジャーナル管理モジュール７２５により実行可能である。ブロック８１６では、指定時間帯の生理学的データをＲＲＤＢから取り出す。このブロックは、ＲＲＤＢ管理モジュール７２３により実行可能である。ブロック８１８では、ジャーナルデータと生理学的データとを、時間に関して相互に関連付ける。この相互関連付けは、時系列上に正しい時間的順序で与えられた生理学的パラメータの値（オプションで波形を含む）に対して、医療イベントの時系列を再構築することを含むことが可能である。実施形態によっては、この、ＲＲＤＢ管理モジュール７２３とジャーナル管理モジュール７２５との間の連係を容易にするために、各データベース７２２、７２４のタイムスタンプを、データの格納時に同期させることが可能である。

【0136】

ブロック８２０では、相互に関連付けられたデータを、ユーザに提示するために出力する。この出力は、たとえば、生理学的情報（たとえば、波形）に医療イベントを重ね合わせたグラフィカル表示などを含むことが可能である。この相互に関連付けられたデータについては、様々な表示フォーマットが使用可能である。

【0137】

図９は、患者監視用グラフィカル・ユーザ・インタフェース（ＧＵＩ）９００の一例を示す。ＧＵＩ ９００は、看護師詰所システムなどに設けることが可能である。また、ＧＵＩ ９００は、臨床担当者装置上に表示することも可能である。

【0138】

ＧＵＩ ９００には、いくつかの表示領域がある。図示した実施形態では、ＧＵＩ ９００は、患者状態表示領域９１０を含んでいる。患者状態表示領域９１０は、病院または他の臨床施設にいる複数の患者の状態を示す。一実施形態では、患者状態表示領域９１０は、病院の一診療科における複数の患者の患者状態を示す。有利なことに、特定実施形態では、患者状態表示領域９１０は、複数の患者の健康状態の「一目でわかる」ビューを提供する。

【0139】

患者状態表示領域９１０は、複数の患者状態モジュール９１２を含んでいる。各患者状態モジュール９１２は、医療患者に結合可能な患者監視器に対応することが可能である。各患者状態モジュール９１２は、グラフィカル状態インジケータ９１４を表示することが可能である。画面９００に、グラフィカル状態インジケータ９１４の一例を、縮小画像による患者監視器アイコンで示す。グラフィカル状態インジケータ９１４は、患者監視器のいくつかの状態のうちの１つを選択的に表示することが可能である。一実施形態では、患者監視器が示しうる４つの状態を、グラフィカル状態インジケータ９１４で表示することが可能である。この４つの状態は、アラーム状態、アラーム状態なし、患者状況情報状態、および接続状態である。

【0140】

様々な実装において、グラフィカル状態インジケータ９１４は、色、形状などを変えることにより、異なる患者監視器状態のうちの１つを示す。たとえば、アラーム状態が存在する場合は、グラフィカル状態インジケータ９１４を赤色にしてアラームを示すことが可能である。当該患者に関して使用可能な状況情報がない場合（図１を参照）は、グラフィカル状態インジケータ９１４を黄色にすることが可能である。装置が患者またはネットワークに接続されていない場合は、グラフィカル状態インジケータ９１４を灰色にすることが可能である。アラーム状態がなく、状況情報があり、患者監視器が患者およびネットワークに接続されている場合は、グラフィカル状態インジケータ９１４を緑色にすることが可能である。上述の実施形態の代わりに、または上述の実施形態との組み合わせで、他にも様々な色、記号、および／または状態を用いることが可能である。

【0141】

有利なことに、グラフィカル状態インジケータ９１４は、患者監視器の状態を、一目でわかるように示す。したがって、患者状態表示領域９１０では、何人かの患者に対応するいくつかのグラフィカル状態インジケータ９１４が、これらの患者に対応する患者監視器についての一目でわかるビューを表示する。したがって、臨床担当者は、アラーム、接続状態、および状況情報に関する患者側のニーズを容易に理解することが可能である。

【0142】

現在利用可能な看護師詰所コンピュータ用グラフィカル・ユーザ・インタフェースは、各患者について複数の波形または変化中の生理学的パラメータの数値を表示するものが多い。この患者情報表示方法は、雑然とし、込み入っていてわかりにくく、眠気を誘うこともあるものになる可能性がある。たとえば、夜間シフトで勤務中の看護師は、ディスプレイ上の他の複数の患者のインジケータの数値や波形などが変化しているときに、あるアラームに集中することは困難であろう。これに対し、本明細書に記載のグラフィカルインタフェースでは、グラフィカル状態インジケータ９１４がアラーム状態を示す際に、このアラーム状態を目立たせることが可能であり、臨床担当者にただちに認識させることが可能である。

【0143】

さらに、グラフィカル状態インジケータ９１４は、看護師が行うと予想される最初のレベルの分析を簡略化する。現在利用可能な装置では、看護師は、多くの場合、患者の健康状態を判定するために、看護師詰所で波形を分析しなければならない。これに対し、画面９００を用いた場合、看護師は、患者の波形または変化中のパラメータを解釈することがまったく不要になり、代わりに、アラームの存在を示すグラフィカル状態インジケータ９１４に頼ることが可能である。

【0144】

特定実施形態では、患者状態モジュール９１２は、マウスのシングルクリックなどにより選択可能である。一実施形態では、患者状態モジュール９１２の選択で、患者監視器ビュー領域９２０が表示されるようにすることが可能である。患者監視器ビュー領域９２０は、選択された患者状態モジュール９１２に対応する患者監視器のビューを表示する。特定の実装では、患者監視器ビュー領域９２０は、患者のベッドサイドにある実際の患者監視器の画面のビューを表示することが可能である。したがって、臨床担当者は、患者の生理学的パラメータを、おおむねなじみのあるフォーマットで、容易に認識することが可能である。患者監視器ビュー領域９２０は、現在も患者から生理学的情報を受信中である。

【0145】

特定の実装では、履歴ビュー領域９３０が、選択された患者監視器状態モジュール９１２に対応する医療イベントデータを表示することが可能である。この医療イベントデータは、ＧＵＩ ９００に含めるために、ジャーナルデータベースから取得可能である。履歴ビュー９３０は、たとえば、いつセンサを患者に接続したか、またはいつ患者から切り離したか、アラームがいつアクティブだったか、ならびに、患者が病院または診療科にいつ入院したか、を表示することが可能である。図示していないが、履歴ビュー領域９３０はまた、ジャーナリングされたデータの代わりに、またはそれに追加して、ＲＲＤＢから取得された動向データを表示するようにも構成可能である。リモート装置への患者情報の送信

【0146】

実施形態によっては、本明細書に記載の患者監視装置は、患者情報を、臨床担当者による精査のために、１つ以上のリモート装置に送信することが可能である。そのようなリモート装置として、たとえば、リモートコンピュータ、スマートフォン、ＰＤＡなどがある。患者情報をリモート装置に送信することが有用であるのは、それによって臨床担当者が患者の状態をリモートから監視する能力が高められるためである。たとえば、臨床担当者は、患者のベッドサイドにいなくても、さらには病院などの患者治療施設にいなくても、患者の状態を効果的に監視することができる。

【0147】

実施形態によっては、患者監視装置（たとえば、本明細書に記載の患者監視装置）で収集された情報のうちのいずれかを、リモート装置に送信することが可能である。そのような情報は、たとえば、医療パラメータ（たとえば、血液酸素飽和度、脈拍数、呼吸数など）の値、動向データなどを含むことが可能である。また、患者の映像、および／または、患者および／または病室の音声を含むことも可能である。たとえば、病室にビデオカメラおよび／またはマイクロホンを設けることが可能である。実施形態によっては、ビデオカメラおよび／またはマイクロホンは、たとえば、本明細書に記載のような医療監視装置に組み込むことが可能である。ビデオカメラは、病室の周囲光の明るさが十分であれば、可視光で患者を撮像することが可能である。ビデオカメラはまた、病室が暗すぎて、許容できる画質の映像が可視光では得られない場合には、たとえば、赤外光を検出することが可能である。ビデオカメラはまた、患者および／または患者の周辺を照らすための赤外光源を含むことも可能である。実施形態によっては、ビデオカメラは、周辺光の明るさが何らかの閾値を下回ると自動的にビデオカメラを赤外モードに切り替えることに使用可能な周囲光センサを含む。この光センサはまた、赤外光源が含まれている場合には赤外光源をオンにすることにも使用可能である。

【0148】

患者情報（たとえば、医療パラメータデータ、患者の映像／音声、その他）の送信は、たとえば、１つ以上の通信ネットワーク（たとえば、ＬＡＮ、ＷＬＡＮ、インターネットなどのようなコンピュータネットワークや、電話網、その他）を用いて行うことが可能である。実施形態によっては、病院または他の患者治療拠点に全体または一部が物理的に位置する１つ以上の通信ネットワークが使用可能である。実施形態によっては、外部通信ネットワークを用いて、世界中のリモート装置と通信することが可能である。したがって、臨床担当者は、どこにいても、担当患者の状態に関する膨大な量の情報をリモートで取得することが可能である。実施形態によっては、臨床担当者は、患者と直接通信することも可能である。たとえば、患者監視装置は、臨床担当者のリモート装置からの音声を患者に伝えるスピーカを備えることが可能である。同様に、患者監視装置は、臨床担当者のリモート装置からの映像を表示する（たとえば、テレビ会議用の）ディスプレイを備えることが可能である。このようにして、情報交換を双方向で行うことにより、臨床担当者は、患者と直接対話することが可能になる。装置および臨床担当者の位置を把握している病院システム

【0149】

高度な監視システムは、多くの異なる生理学的パラメータを多くの異なるフォーマットで表示することが可能である。この充実した実行機能および表示の柔軟性に弱点があるとすれば、１つは、これらのシステムを使用する治療担当者に提示される情報が過剰である可能性があることである。これらの治療担当者は、たとえば、医師、呼吸療法士、登録看護師、および他の臨床担当者であり、それぞれの監視システムの使い方は、通常バイタルサインの取得から、複雑な生理学的状態の診断および処置、臨床研究およびデータ収集まで様々である。

【0150】

本明細書に記載のような患者監視装置は、臨床担当者と装置との対話を可能にする、キーボード、タッチスクリーン、その他の入力装置を備えることが可能である。このようなユーザインタフェース装置を用いることにより、臨床担当者は、たとえば、ユーザ名やパスワードのようなログイン情報を入力することが可能である。場合によっては、患者監視装置は、装置へのログインを臨床担当者に求める場合があり、それは、たとえば、装置が提供する機能のうちの１つ以上の機能へのアクセスを許可する前、かつ／または、装置において利用可能な特定情報へのアクセスを許可する前である。本明細書に記載の看護師詰所システム（中央監視装置）は、臨床担当者が使用する際にログインを求められることがある監視装置の一例である。ベッドサイドの患者監視器の場合は、臨床担当者は、新しい患者の監視を初期化する前にログインを求められることがある。患者監視装置の使用前にログインを求められない場合でも、臨床担当者は、患者監視装置によって提供される一連の利用可能なアクションの中から特定のアクションを行わせる際に、入力装置との何らかのタイプの対話を求められる場合がある。

【0151】

たとえば、患者監視装置を所望の様式に構成する場合に、ユーザ入力を求められることがある。実施形態によっては、臨床担当者は、入力装置を用いて、患者監視装置のディスプレイに提示される内容、あるいはその内容のフォーマッティングを、臨床担当者の環境設定に合わせて変更することが可能である。場合によっては、看護師は、入力装置を用いて、中央監視装置を、（たとえば、フロア全体のすべての患者を表示するのではなく）その特定の看護師に割り当てられた患者の監視情報だけを表示するように、手動で構成することが可能である。臨床担当者はまた、入力装置を用いて、患者監視設定を変更することも可能であり、たとえば、生理学的パラメータ値を、ローデータ、アラームタイプ、生理学的パラメータアラーム限界（たとえば、アラーム閾値）などから計算するオプションなどを変更することが可能である。

【0152】

繁忙な病院では臨床担当者らが時間的制約にさらされているため、この、（たとえば、入力装置を物理的に操作することにより）患者監視装置と手動で対話するプロセスは、特に一日を通して何度も繰り返すことが必要な場合には、大変な負担になる可能性がある。場合によっては、特定機能にアクセスしたり、装置を構成したりするために患者監視装置と手動で対話することに必要な時間は、特に差し迫った事態においては患者の健康を脅かす可能性すらある。少なくとも上述の理由により、病院の機器、たとえば、ベッドサイド患者監視器、中央監視装置などの装置は、臨床担当者の存在を自動的に検出する機能、そして、たとえば、存在が検出された臨床担当者が誰かという情報に基づいて何らかの所定のアクションを行う機能を有することが有利であろう。

【0153】

実施形態によっては、近傍表示監視器が、（たとえば、環境設定、優先度、またはユーザ了解に従って）表示を現在の観測者に適応させることにより、高度な監視システムを、ユーザの様々なニーズや好みに有利に適応させる。したがって、表示されるパラメータおよびフォーマットは、デフォルトで、事前定義されたユーザクラスに従って選択したり、特定の個人または個別グループ向けにカスタマイズしたりすることが可能である。近傍表示監視器の近傍にいる人を識別する１つの方法は、ＩＤタグまたは他のトークンによる方法である。ＩＤタグは、たとえば、無線周波数識別（ＲＦＩＤ）や無線送信などにより、ユーザの存在を近傍表示監視器に伝達することが可能である。近傍表示監視器の近傍範囲内に複数のユーザが存在する場合は、優先度方式またはユーザの了解により、どのユーザに対応するかを決定することが可能である。

【0154】

実施形態によっては、近傍表示監視器は、監視器および相互接続されたセンサを有し、このセンサは、光放射を組織部位に送信し、その組織部位内の拍動血流による減衰を経た光放射に応答するセンサ信号を生成する。この監視器は、センサ信号に応答する生理学的パラメータを計算し、近傍表示を利用して、その生理学的パラメータを、監視器の近傍にいるユーザに関連付けられた表示環境設定に従って画面上に表示することが可能である。生理学的パラメータを治療担当者の閲覧用として提示するために、監視器にディスプレイを組み込むことが可能である。監視器に送受信機を組み込むことが可能であり、送受信機は、識別信号に応答することが可能である。この識別信号は、治療担当者に対応させることが可能である。治療担当者が携帯する送信機が、たとえば、ディスプレイがまずまず見える程度の、監視器からの距離に相当する範囲内で識別信号を送信することが可能である。その識別信号で示される治療担当者に関連付けられた表示環境設定に従う、好ましい設定の画面で、生理学的パラメータをディスプレイに提示することが可能である。

【0155】

実施形態によっては、近傍表示監視器が、ディスプレイおよび無線送受信機を有する監視器を備える。無線送受信機は、各自が固有の表示環境設定を有する任意のユーザが監視器の近傍にいることを示す識別信号に応答することが可能である。その表示環境設定に従う、好ましい設定の画面で、生理学的パラメータをディスプレイに提示することが可能である。

【0156】

実施形態によっては、近傍表示監視器が、肉組織部位に装着された光センサを有する。このセンサから送信される光放射にセンサ信号が応答することが可能であり、このセンサ信号を、組織部位内の拍動血流による吸収後に、センサで検出することが可能である。このセンサ信号は、監視器に伝達可能であり、監視器は、このセンサ信号を処理して、拍動血流の各成分に応答する生理学的パラメータを導出する。監視器の近傍にいるユーザが誰かという情報は、無線信号で監視器に伝達可能である。画面環境設定は、たとえば、ユーザが誰かという情報から決定可能であり、これを用いて、生理学的パラメータを監視器のディスプレイに表示することが可能である。

【0157】

実施形態によっては、近傍表示監視器は、プロセッサおよびディスプレイを含んでいる。プロセッサは、肉組織部位内に送信された光放射から生成され、肉組織部位内での拍動血流による減衰を経て検出されたセンサ信号に応答可能である。プロセッサは、拍動血流の各成分を表す複数の生理学的パラメータを計算するように構成可能である。ディスプレイは、近傍ユーザの閲覧用として、生理学的パラメータ値の視覚的表現を提供することが可能である。近傍ユーザが誰かという情報は、無線通信手段によって取得可能である。生理学的パラメータは、画面環境設定手段によってディスプレイに提示可能である。ユーザが誰かという情報は、ルックアップテーブル手段によって、画面環境設定に関連付けることが可能である。

【0158】

図１０は、生理学的測定システムを示しており、これは、組織部位１０００に装着される非侵襲的センサ１０１０と、患者監視器１０２０と、監視器１０２０およびセンサ１０１０を相互接続するインタフェースケーブル１０３０とを含んでいる。この生理学的監視システムは、複数波長センサなどの高度な機能や、（パルスオキシメトリの生理学的パラメータ以外の、またはこれに加えて）いくつか例を挙げれば一酸化炭素ヘモグロビン、メトヘモグロビン、総ヘモグロビンなどの生理学的パラメータを求める高度なプロセスに加えて、パルスオキシメトリを組み込むことが可能である。患者監視器１０２０は、近傍表示１０２１を有しており、これは、選択された生理学的パラメータの測定値を提示するとともに、これらのパラメータが所定の限界を超えた場合に治療担当者にアラートする可視可聴アラーム機構を提供する。患者監視器１０２０はまた、いくつかアイテムがある中で特に、表示機能およびアラーム機能を制御するキー１０２２を備えている。近傍表示１０２１およびキー１０２２は、治療担当者が（たとえば、可搬型の手持ち式装置を用いて）患者状態を容易に把握できるように、多くのパラメータを整理して表示するユーザインタフェースを与える。

【0159】

図１１は、特定のユーザ１１３０の存在ならびにそのユーザの表示環境設定に対応するように有利に構成された近傍表示１０２１（図１０）の様々な画面１１５０を示す。各ユーザは、処置をする医師や付き添う看護師など、様々な治療担当者のいずれかであってよい。一実施形態では、近傍表示１０２１（図１０）はまた、特定グループのユーザのどのユーザにも対応可能である。

【0160】

後で図１３に関して説明するように、監視器１０２０（図１０）に対して特定のユーザまたはユーザグループが存在または近接しているかどうかは、ユーザが装着するＲＦＩＤ（無線周波数識別）タグまたは他の無線通信によって突き止めることが可能である。そして、そのユーザに関連付けられた所定の表示環境設定に従って、１つ以上の特定の画面をディスプレイに表示することが可能である。このようにして、近傍表示１０２１（図１０）は、監視器ユーザの環境設定に合わせられる。「ＲＦＩＤタグ」（または簡単に「タグ」）には、監視器の近傍のユーザをリモートで識別できる任意の無線通信装置が含まれる。タグに含まれるのは、バッジ、タグ、クリップ、ブレスレット、ペンなどの形状で、ＲＦＩＤチップまたは他の無線通信コンポーネントを収容する装置であり、これらに限定されない。タグはまた、スマートフォン、ＰＤＡ、ポケットＰＣなどの、無線通信機能を有するモバイルコンピューティング装置も包含する。

【0161】

図１１に示すように、たとえば、監視器の近傍にいる麻酔専門医１１３１が識別されると、ディスプレイが、脈拍数の動向を示す画面１１１０に変わる。看護師１１３２が監視器の近傍に入ると、表示が、パルスオキシメトリパラメータ、プレチスモグラフ、およびアラーム限界を示す画面１１２０に変わる。呼吸療法士１１３３が監視器の近傍に入ると、表示が、パルスオキシメトリ、異常ヘモグロビン、および灌流指数を示す画面１１４０に変わる。

【0162】

実施形態によっては、近傍表示監視器は、すべての近傍ユーザが近傍から出ると、応答として、表示を自動的に薄暗くして減光設定にする。この機能は、有利なことに、睡眠中または入眠時の患者の邪魔にならないようにするためのものである。実施形態によっては、近傍表示監視器は、近傍ユーザがいなくなった場合に、同様に応答として、パルスの「ビープ音」および他の重要ではない音を自動的に抑える。

【0163】

図１２は、近傍ユーザ１２８０に対して、ユーザの表示環境設定に従って計算済みパラメータを表示するように応答する近傍表示監視器１２００を示す。図１２に示すように、近傍表示監視器１２００は、実施形態によっては、光センサ（図示せず）とインタフェースするフロントエンド１２１０を有している。光センサは、患者の組織部位の拍動血流に応答するセンサ信号を発生させる。光センサについては、上述の米国特許出願第１１／３６７０１３号明細書（件名「Ｍｕｌｔｉｐｌｅ Ｗａｖｅｌｅｎｇｔｈ Ｓｅｎｓｏｒ Ｅｍｉｔｔｅｒｓ」）に記載がある。フロントエンド１２１０は、センサ信号１２１２を調整およびデジタル化して、デジタル信号プロセッサ（ＤＳＰ）１２２０に入力する。ＤＳＰ １２２０は、センサ信号１２１２に従って生理学的パラメータ１２２２を導出する。計算されたパラメータ値は、ディスプレイドライバ１２３０に伝達され、ディスプレイドライバ１２３０は、所定のフォーマットに従って、それらのパラメータをディスプレイ１２７０上に提示する。フロントエンドおよびＤＳＰを有する監視器については、上述の米国特許出願第１１／３６６２０８号明細書（件名「Ｎｏｎｉｎｖａｓｉｖｅ Ｍｕｌｔｉ－Ｐａｒａｍｅｔｅｒ Ｐａｔｉｅｎｔ Ｍｏｎｉｔｏｒ」）に記載がある。

【0164】

図１２にさらに示すように、近傍表示監視器１２００は、送受信機または受信機１２４０、ルックアップテーブル１２５０、および表示環境設定１２５８を有している。ユーザ１２８０は、ユーザ１２８０を送受信機１２４０に対して識別させるＩＤタグ１２６０を有している。ユーザ１２８０が近傍表示監視器１２００の近傍にいる場合、ＩＤタグ１２６０は、ユーザ１２８０を識別させるために、送受信機１２４０と通信することが可能である。一実施形態では、送受信機１２４０はＲＦＩＤリーダであり、ＩＤタグ１２６０は、ユーザコード１２５２を収容したＲＦＩＤチップが埋め込まれている。別の実施形態では、送受信機１２４０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの１つ以上の短距離無線通信規格に準拠している。ユーザ１２８０は、（たとえば、ＩＤタグ１２６０上のボタンまたは同様の起動手段を操作することにより）近傍表示監視器１２００との通信を起動することが可能であり、ユーザコード１２５２が送受信機１２４０に送信される。送受信機１２４０は、ユーザコード１２５２をＤＳＰ １２２０に伝達する。ＤＳＰ １２２０は、受信したユーザコード１２５２から表示環境設定１２５８を導出するために、ルックアップテーブル１２５０にアクセスすることが可能である。表示環境設定１２５８は、表示パラメータ１２２２および画面フォーマット１２２４を示しており、これらがディスプレイドライバ１２３０に伝達される。

【0165】

図１２にさらに示すように、実施形態によっては、ルックアップテーブル１２５０は、ユーザコード１２５２を、治療担当者ＩＤ １２５６および優先度１２５４に関連付ける。近傍表示監視器１２００の近傍に複数のユーザが来た場合、どの表示環境設定１２５８を用いてディスプレイ１２７０を構成するかは、優先度１２５４によって決定される。

【0166】

図１３は、表示環境設定画面１３００を示しており、この画面は、ルックアップテーブル１２５０（図１２）の特定の行に情報を与える。セットアップまたは登録手続きにより、ユーザは、１つ以上のプロファイルを指定することが可能であり、プロファイルは、たとえば、表示環境設定と、パラメータを計算すること、ならびにアラームをトリガすることに関する様々なオプションとを含む。

【0167】

図１４は、臨床担当者トークン１４１０の存在を自動的に検出できる患者監視装置１４００の概略図である。実施形態によっては、臨床担当者トークン１４１０は、たとえば、臨床担当者が一日中装着または携帯することを意図された可搬型アイテムである。患者監視装置１４００は、臨床担当者トークンの存在に基づいて、その臨床担当者の存在を認識することが可能である。

【0168】

患者監視装置１４００は、（たとえば、通信モジュール１４０２のような）検出器を含んでいる。患者監視装置１４００はまた、ディスプレイ１４０４およびプロセッサ１４０６を含んでいる。プロセッサ１４０６を用いて、たとえば、１人以上の患者から収集された生理学的情報に基づく臨床的に有用なタスク（たとえば、生理学的パラメータ値の計算、アラーム状態の特定、臨床担当者ユーザインタフェースからの生理学的情報の出力、臨床担当者へのアラーム状態の通知など）を実行することが可能である。患者監視装置１４００はまた、本明細書に記載のように、患者の監視を支援する他のモジュール（たとえば、医療センサまたはコンピュータネットワークから生理学的情報を受信するインタフェース、臨床担当者との対話を容易にするユーザインタフェースなど）を含むことも可能である。実施形態によっては、通信モジュール１４０２は、送信機、受信器、または送受信機である。他のタイプの通信モジュールも使用可能である。実施形態によっては、通信モジュール１４０２は、短距離送受信機である。短距離送受信機は、たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）対応送受信機であってよい。Ｂｌｕｅｔｏｏｔｈ（登録商標）は、比較的短距離での装置間データ交換のための無線プロトコルである。通信モジュール１４０２はまた、赤外線送受信機、ＲＦＩＤタグ、または他の任意の通信手段（たとえば、短距離通信）であってよい。

【0169】

通信モジュール１４０２は、実施形態によっては、検出範囲１４２０内においてリモート装置からの信号を検出することが可能である。検出範囲１４２０の大きさは、たとえば、通信モジュール１４０２からの通信信号の強度によって決定可能である。検出範囲１４２０の大きさはまた、患者監視装置１４００の周囲の影響を受ける可能性もある。実施形態によっては、検出範囲１４２０は、半径が３０フィート以下であるように構成される。実施形態によっては、検出範囲１４２０の半径は、２０フィート以下である。実施形態によっては、半径は１０フィート以下であり、実施形態によっては、半径は５フィート以下、あるいは３フィート以下である。

【0170】

臨床担当者トークン１４１０も同様に通信モジュール１４１２を含んでおり、通信モジュール１４１２は、たとえば、送信機、受信機、または送受信機であってよいが、他のタイプの通信モジュールも使用可能である。患者監視装置１４００の場合と同様に、臨床担当者トークン１４１０に含まれる通信モジュール１４１２は、短距離送受信機であってよく、たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）送受信機などであってよい。患者監視装置１４００は、臨床担当者の存在を検出することが可能であり、この検出は、たとえば、臨床担当者トークン１４１０からの１つ以上の通信信号の認識に基づいて可能である。臨床担当者トークン１４１０からの通信信号は、たとえば、患者監視装置１４００によって起動される通信に対する応答として来ることが可能であり、あるいは、臨床担当者トークン１４１０からの通信信号は、臨床担当者トークン自体によって起動されることが可能である。たとえば、リモート装置間の無線通信を起動するために、多くの様々な方法を用いることが可能である。

【0171】

臨床担当者トークン１４１０はまた、情報を、たとえば、メモリに入れて運ぶことが可能である。このメモリは、たとえば、揮発性メモリであっても不揮発性メモリであってもよい。情報は、臨床担当者トークン１４１０にハード配線されてもよく、プログラム可能であってもよい。実施形態によっては、臨床担当者トークン１４１０は、臨床担当者トークン１４１０が割り当てられた臨床担当者に固有の臨床担当者ＩＤ １４１４を含む。臨床担当者トークン１４１０はまた、他の情報も含むことが可能であり、これはたとえば、臨床担当者のログイン情報（たとえば、ユーザ名およびパスワード）や、臨床担当者の存在が認識されたときに患者監視装置１４００によって実行されるべき所定のアクション（臨床担当者をログインさせること、患者監視装置１４００の構成環境設定を設定すること、機能を有効にすることなど）を起動するコードまたは他のインジケータなどである。

【0172】

臨床担当者トークン１４１０はまた、入力モジュール１４１６を含むことが可能であり、臨床担当者は、これを用いて、通信モジュール１４１２にリモート通信を行わせることが可能であり、このリモート通信の相手は、たとえば、患者監視装置１４００、または他の何らかの、病院の患者監視ネットワークの一部をなす装置である。たとえば、入力モジュール１４１６は、１つ以上のボタン、または他の入力装置を含むことが可能であり、臨床担当者は、これを用いて、患者監視装置１４００に臨床担当者の存在を認識させるべく、その患者監視装置１４００との通信を起動することが可能である。さらに、臨床担当者は、入力モジュール１４１６を用いることにより、たとえば、特定の患者が緊急対応を必要としていることを発見した場合に緊急対応チームを呼ぶことや、監視アラームを静音化することが可能である。また、用途に応じて、入力モジュール１４１６を他の目的に用いることも可能である。

【0173】

実施形態によっては、臨床担当者トークン１４１０は、携帯電話、ノートブックコンピュータ、ＰＤＡ装置、ヘッドセットなどであり、これらのいずれかは、たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）対応であってよい。実施形態によっては、臨床担当者トークン１４１０は、本明細書に記載のように生理学的パラメータアラーム状態を臨床担当者に通知するページャまたは他の通知装置である。実施形態によっては、臨床担当者トークン１４１０は、アクティブまたはパッシブＲＦＩＤタグである。アクティブＲＦＩＤは、たとえば、ＷｉＦｉ対応であってよい。実施形態によっては、臨床担当者トークン１４１０は、（たとえば、二次元または三次元の）バーコードである。実施形態によっては、臨床担当者トークン１４１０は、臨床担当者の身体の一部である。たとえば、臨床担当者トークン１４１０は、指紋、網膜、臨床担当者の顔などであってよい。そのような実施形態では、臨床担当者ＩＤ １４１４は、実際には、臨床担当者の固有の生物測定学的署名である。通信モジュール１４０２は、通信相手となる臨床担当者トークン１４１０のタイプに基づいて選択可能である。たとえば、患者監視装置１４００内の通信モジュール１４０２は、ＲＦＩＤ質問機、バーコードスキャナ、指紋スキャナ、網膜スキャナ、顔認識装置などであってよい。

【0174】

実施形態によっては、臨床担当者トークン１４１０は、有利なことに、患者監視装置１４００への登録が可能でありながら、たとえば、患者監視装置１４００、患者監視システム、病院などとの間に以前からの接続または関係がない民生用装置である。たとえば、臨床担当者トークン１４１０は、患者監視装置１４００、または他の任意の、臨床担当者トークンの存在を検出できるように構成された装置と通信する用途に特化されていない民生用装置であってよい。たとえば、多くの臨床担当者は、個人用の携帯電話を既に保有していて、一日中身に付けている。実施形態によっては、臨床担当者の個人用電子装置は、（たとえば、本明細書で後述する登録処理の後に）臨床担当者トークン１４１４として機能することが可能である。このことは、病院などの治療施設の側に投資を求めることなく、各臨床担当者に専用臨床担当者トークン１４１０が与えられる点で有利となりうる。その一方で、実施形態によっては、臨床担当者トークン１４１０は、たとえば、存在検出機能を有する患者監視装置（たとえば、１４００）に対して動作することを主目的として臨床担当者に与えられる専用装置である。

【0175】

実施形態によっては、臨床担当者トークン１４１０は、たとえば、患者監視装置からの質問に、定型の応答信号（たとえば、臨床担当者ＩＤ １４１４）でのみ応答することが可能である。しかしながら、実施形態によっては、臨床担当者トークン１４１０は、複数の（かつ／または可変の）信号および情報を患者監視装置１４００に送信することが可能である。臨床担当者トークン１４１０は、プロセッサを含むことが可能であり、たとえば、患者監視装置１４００との様々なインテリジェント通信の機能を臨床担当者トークン１４１０に与えるソフトウェアアプリケーションを実行するプロセッサを含むことが可能である。

【0176】

実施形態によっては、登録処理を完了してから臨床担当者トークン１４１０を患者監視装置１４００とともに使用することにより、存在検出機能が実装される。たとえば、登録処理時に、特定の臨床担当者に割り当てられた固有の臨床担当者ＩＤ １４１４を、臨床担当者トークン１４１０に与えることが可能である。この臨床担当者ＩＤは、たとえば、患者監視装置１４００からアクセスできるデータベースに格納することが可能であり、これによって、患者監視装置１４００は、臨床担当者トークン１４１０に格納されている臨床担当者ＩＤ １４１４に基づいて、臨床担当者を識別することが可能である。臨床担当者ＩＤ １４１４はまた、データベース内で、たとえば、その臨床担当者に割り当てられた、患者監視装置１４００にアクセスするためのログイン情報に関連付けることが可能である。

【0177】

データベースはまた、特定の患者監視装置が臨床担当者の存在を検出したときに行われる、その臨床担当者の所望の１つ以上のアクションの指示を格納することも可能である。データベースは、患者監視装置に対する、臨床担当者の構成環境設定を格納することが可能である。たとえば、患者監視装置１４００のディスプレイ１４０４に表示される特定の生理学的パラメータおよび他の監視情報は、構成可能であってよい。たとえば、ベッドサイド患者監視器の場合、ディスプレイ１４０４は、特定の生理学的パラメータの数値インジケータ、その生理学的パラメータのグラフィカルインジケータ、視覚的アラーム、同時に複数の生理学的パラメータ、患者センサからの生理学的パラメータ信号の信号品質などを表示することが可能であってよい。臨床担当者の構成環境設定は、どのタイプの情報を表示するか、ならびに、表示情報をどのようにフォーマットするかを、患者監視装置１４００に指示することが可能である。患者監視装置１４００に対する臨床担当者の構成環境設定はまた、患者監視設定（たとえば、生理学的パラメータアラーム限界など）を含むことが可能である。

【0178】

たとえば、本明細書に記載のタイプのような中央監視装置の場合、臨床担当者の構成環境設定は、同様に、監視中の患者ごとに、中央監視装置において表示される生理学的パラメータ（または他の監視情報）のタイプおよび表示フォーマットを含むことが可能である。さらに、臨床担当者の構成環境設定は、患者監視装置において表示される病室（または患者名）の固定された、または動的なリストを含むことが可能である。これらの病室（または患者）は、たとえば、その特定の臨床担当者に現在割り当てられている病室（または患者）であってよい。しかしながら、一般に、臨床担当者ＩＤ １４１４に関連付けられている、臨床担当者の構成環境設定は、患者監視装置１４００の任意の構成可能な特徴、態様、または機能を含むことが可能である。

【0179】

データベースは、臨床担当者が患者監視装置１４００の検出範囲１４２０に入ったときに起動させたいと考える患者監視装置１４００の特定のアクションを、臨床担当者ＩＤ １４１４に関連付けることが可能である。臨床担当者の存在が検出されたときに自動的に起動させることが可能な、そのようなアクションの例を、本明細書では記載している。さらに、実施形態によっては、データベースは、優先度レベルを臨床担当者ＩＤ １４１４に関連付けることも可能である。優先度レベルは、（たとえば、検出範囲１４２０内で複数の臨床担当者が同時に検出された場合に）どの臨床担当者に医療監視装置１４００への優先アクセスを与えるかを指示することが可能である。

【0180】

実施形態によっては、臨床担当者に割り当てられたログイン情報、監視装置の構成環境設定、臨床担当者の存在の認識時に自動的に起動するアクションのリスト、優先度レベル、および／または他の情報を、臨床担当者トークン１４１０自体に格納することが可能である。そのような実施形態では、この情報は、臨床担当者トークン１４１０から患者監視装置１４００に直接送信することが可能であり、この点は、患者監視装置１４００が、トークン１４１０に格納された臨床担当者ＩＤ １４１４を用いてデータベースから情報を取得する場合と対照的である。他の方法を用いても、たとえば、臨床担当者が患者監視装置１４００の検出範囲１４２０に入ったときに患者監視装置１４００に行わせたいと考える所定のアクション（たとえば、ログイン、構成変更、その他）に臨床担当者ＩＤ １４１４を関連付けることが可能である。

【0181】

実施形態によっては、患者監視装置１４００は、登録処理が完了してから、特定の臨床担当者の存在を、その臨床担当者のトークン１４１０に基づいて検出することが可能になり、また、たとえば、臨床担当者の存在の認識に基づいて、その臨床担当者に固有のアクションを行うことが可能になる。実施形態によっては、患者監視装置１４００の検出範囲１４２０に臨床担当者トークン１４１０がいつ存在し、いつ存在しないかを判定する検出ロジック１４０８を実行するように、患者監視装置１４００のプロセッサ１４０６を構成する。実施形態によっては、検出ロジック１４０８は、検出範囲１４２０に臨床担当者トークン１４１０が存在すると判定するために、あるいは、何らかの臨床担当者固有のアクションを実行するために、満たされなければならないルールまたは他の条件のセットである。

【0182】

図１５は、患者監視装置の検出範囲内で臨床担当者トークン（たとえば、１４１０）の存在を検出する検出方法１５００を示すフローチャートである。検出方法１５００は、たとえば、待機状態１５０２から始まり、その時点では、患者監視装置１４００は、臨床担当者の存在を検出していない。待機状態１５０２では、たとえば、患者監視装置１４００によって提供可能な機能および情報に手動でアクセスすることが可能である。待機状態１５０２では、臨床担当者がキーボード、マウス、またはタッチスクリーンなどの入力装置を用いて、患者監視装置を手動で構成すること、または患者監視装置と対話することも可能である。したがって、待機状態１５０２では、有利なことに、臨床担当者トークン１４１０を割り当てられていない臨床担当者でも、患者監視装置１４００を使用したり、これと対話したりすることが可能である。

【0183】

判断ブロック１５０４では、プロセッサ１４０６は、検出ロジック１４０８を実行して、臨床担当者トークン１４１０からの信号が検出されたかどうかを判定する。たとえば、実施形態によっては、患者監視装置１４００の通信モジュール１４０２は、臨床担当者トークン発見信号を、たとえば、連続的に、または定期的に、送信することが可能である。判断ブロック１５０４では、プロセッサ１４０６は、患者監視装置の発見信号に対する、臨床担当者トークン１４１０からの応答が受信されたかどうかを判定することが可能である。代替として、または追加で、臨床担当者トークン１４１０は、患者監視装置１４００が検出可能な発見信号を、たとえば、連続的に、または定期的に、送信するように構成可能である。臨床担当者トークン１４１０からの応答信号は、たとえば、臨床担当者ＩＤ １４１４または他の情報を含むことが可能である。臨床担当者トークン１４１０からの信号が検出されない場合、検出方法１５００は、待機状態１５０２に戻る。一方、臨床担当者トークン１４１０からの信号が検出された場合、検出方法１５００は、次の判断ブロック１５０６に進むことが可能である。

【0184】

判断ブロック１５０６では、プロセッサ１４０６は、検出ロジック１４０８を実行して、検出された、臨床担当者トークン１４１０からの信号が信号強度閾値を超えたかどうかを判定する。この検査は、たとえば、臨床担当者トークン１４１０と患者監視装置１４００との間の物理的な距離の推定として役立つことが可能である。たとえば、患者監視装置１４００は、検出イベントが発生したかどうか、および／または臨床担当者の検出時に特定の所定アクションを行うかどうか、が、臨床担当者と患者監視装置１４００との間の物理的な距離の推定値に依存するように構成可能である。このことは、たとえば、多くの臨床担当者がしばしば通り過ぎる、人通りの多い場所の近くに中央監視装置がある場合に有用である可能性がある。そのような状況では、臨床担当者検出イベントを、臨床担当者が中央監視装置から比較的短距離の場所にいる状況に限定するために、判断ブロック１５０６に使用する信号強度閾値を比較的高いレベルに設定することが有利である。したがって、信号強度閾値は、たとえば、臨床担当者存在検出イベントが認識されないような、所望の、臨床担当者トークン１４１０からの物理的距離に基づいて構成可能であってよい。検出された、臨床担当者トークン１４１０からの信号の振幅強度が、判断ブロック１５０６で使用される信号強度閾値を下回った場合、検出方法１５００は、待機状態１５０２に戻る。一方、信号強度が閾値を超えた場合、検出方法１５００は、次の判断ブロック１５０８に進むことが可能である。

【0185】

検出ブロック１５０８では、プロセッサ１４０６は、検出ロジック１４０８を実行して、臨床担当者トークン１４１０からの信号の信号強度が、ある時間閾値より長い近傍時間にわたって信号強度閾値を超えたかどうかを判定する。この検査は、臨床担当者が患者監視装置１４００の近くを通りかかったものの、それが過渡的なものに過ぎず、臨床担当者存在検出イベントに値するほど長い時間にわたって検出範囲１４２０にとどまったのではない場合に、臨床担当者存在検出イベントを認識しないようにするために役立つことが可能である。この検査は、同様に、多くの様々な臨床担当者が日常的にしばしば通り過ぎる、患者監視装置１４００の周囲の人通りの多い場所での、臨床担当者存在検出イベントの誤発生を防ぐのに役立つ可能性がある。判断ブロック１５０８で用いる近傍時間閾値は、構成可能であってよい。実施形態によっては、近傍時間閾値は、たとえば、１秒、２秒、または５秒に設定可能である。しかしながら、他の近傍時間も使用可能である。検出された臨床担当者トークン１４１０の近傍時間が、判断ブロック１５０８で用いられる近傍時間閾値を超えない場合、検出方法１５００は、たとえば、待機状態１５０２に戻る。一方、臨床担当者トークン１４１０の近傍時間が近傍時間閾値を超えた場合、検出方法１５００は、ブロック１５１０に進むことが可能である。

【0186】

ブロック１５１０では、臨床担当者存在検出イベントが認識される。この場合、患者監視装置１４００は、たとえば、認識された臨床担当者トークン１４１０に関連付けられた臨床担当者の識別情報に基づく何らかの所定アクションを有効にするか起動することが可能である。たとえば、患者監視装置１４００は、臨床担当者をログインさせること、構成設定を変更すること、通常、臨床担当者が不在の場合には制限されている何らかのアクションまたは機能を許可することなどを行うことが可能である。図１５に示した検出方法１５００では、臨床担当者存在検出イベントが発生したかどうかは、臨床担当者トークン１４１０からの信号の信号強度、ならびに臨床担当者トークン１４１０からの信号が信号強度閾値を超えている時間の長さに依存する。しかしながら、実施形態によっては、臨床担当者存在検出イベントが、臨床担当者トークン１４１０からの信号の信号強度だけに基づいて認識されてもよく、あるいは、臨床担当者トークン１４１０からの信号が検出されている時間長だけに基づいて認識されてもよい。

【0187】

実施形態によっては、臨床担当者トークン１４１０からの信号の信号強度と近傍時間との、それぞれ単独に基づくか、それらの組み合わせに基づくかにかかわらず、検出ロジック１４０８には他の要因を含めることも可能である。たとえば、臨床担当者存在検出イベントの認識は、臨床担当者が誰かという情報に、少なくとも部分的に基づくことが可能である（患者監視装置１４００によっては、特定の臨床担当者しかアクセスできない場合があるからである）。さらに、臨床担当者存在検出イベントの認識は、臨床担当者に割り当てられた優先度に基づくことも可能である。たとえば、看護監督者に、他の、シフトの看護師より高い優先度を割り当てて、看護監督者ではない看護師の存在が既に患者監視装置１４００によって認識されている場合でも、看護監督者の存在が患者監視装置１４００によって認識されるようにすることが可能である。これに対し、逆の状況では、新しい臨床担当者存在検出イベントにならないようにすることが可能である。すなわち、優先度の高い臨床担当者の存在が既に患者監視装置１４００によって認識されている場合に、優先度の低い臨床担当者の検出が検出イベントにならないようにすることが可能である。優先度レベルは、複数の臨床担当者トークンが、臨床担当者検出イベントを起動するための他の要件を同時に満たしている場合に、検出ロジック１４０８において使用可能な、均衡を破る条件の一例である。この均衡を破る条件としては、他の条件も使用可能である。

【0188】

検出ロジック１４０８には、病院、関係する医療機器のタイプ（たとえば、患者監視機器、または他の何らかのタイプの医療装置）に応じて、広く様々な要因を含めることが可能であることを理解されたい。さらに、そのような要因は、検出ロジック１４０８において、様々なかたちで考慮することが可能である。たとえば、検出ロジック１４０８は、いつ閾値を超えたか、いつブール式が真または偽になったか、いつファジー論理式が真または偽になったか、いつ数学的方程式が満たされたか、または満たされなかったか、いつ複合語規則が満たされたか、または満たされなかったか、などを特定することが可能である。

【0189】

臨床担当者検出イベントが、たとえば、検出方法１５００に従って認識された場合、患者監視装置１４００は、様々な方法で応答可能である。たとえば、患者監視装置１４００は、患者監視装置１４００の近傍において検出されたトークンを有する臨床担当者が誰かという情報に基づいて、所定のアクションを起動することが可能である。実施形態によっては、所定のアクションは、患者監視装置１４００が臨床担当者を自動的にログインさせることであり、この場合、臨床担当者に対し、たとえば、入力装置と物理的に対話することを求めない。この処理によって、臨床担当者は時間を節約でき、場合によっては、患者の命を救うことも可能である。本明細書に記載のように、臨床担当者のログイン情報は、臨床担当者トークン１４１０から患者監視装置１４００に送信可能であり、また、トークン１４１０からの臨床担当者ＩＤ １４１４を用いてデータベースから取り出すことも可能である。

【0190】

実施形態によっては、患者監視装置は、臨床担当者トークン１４１０の検出内容に基づいて、特定の機能を有効または無効にする。たとえば、患者監視装置は、検出された臨床担当者の認証情報に基づいて、メニューおよびボタン（たとえば、アラーム限界メニュー、アラーム静音化、すべてミュートなど）を有効／無効にすることが可能である。実施形態によっては、患者監視装置１４００は、臨床担当者の存在を検出するとただちに、リモート装置に対し、患者監視情報の送信を開始する。たとえば、患者の呼吸音を取り込むことができるベッドサイド患者監視器が、臨床担当者のＢｌｕｅｔｏｏｔｈ（登録商標）ヘッドセットに対し、その呼吸音の送信を自動的に開始することが可能である（このＢｌｕｅｔｏｏｔｈ（登録商標）ヘッドセットは、臨床担当者トークン１４１０としても動作可能である）。他の実施形態では、患者監視装置１４００は、特定の臨床担当者の存在を検出するとただちに、リモート装置に対し、任意のタイプの監視情報の送信を（たとえば、インターネット経由で）開始することが可能である。たとえば、患者監視装置１４００は、患者の酸素飽和度動向データを、後刻の分析および診断のために、臨床担当者のコンピュータに送信することが可能である。患者監視装置１４００はまた、患者監視装置１４００の近傍で特定の臨床担当者の存在が検出されたことに対する応答として、他の任意のタイプの患者情報（たとえば、医療パラメータ値および／または動向データ、病室からの映像および／または音声など）を、たとえば、その臨床担当者のコンピュータ、または他の何らかの装置に送信することが可能である。

【0191】

実施形態によっては、患者監視装置は、その構成を、検出された臨床担当者の構成環境設定に基づいて自動的に更新することが可能である。たとえば、患者監視装置１４００は、表示する情報の内容または表示する情報のフォーマットを変更することが可能である。このような構成変更は、臨床担当者が臨床担当者トークン１４１０の登録処理時に指示した設定に基づいて行うことが可能である。そのような実施形態の一例を、図１６に示す。実施形態によっては、患者監視装置が、表示画面のレイアウト（たとえば、表示するパラメータの数、表示する波形、動向、および他の画面コントロール）を変更する。表示のレイアウトは、事前定義されたレイアウトの中から選択可能であり、あるいは、臨床担当者がカスタムレイアウトを作成することも可能である。同じことが、他の構成設定にも当てはまる。構成設定は、個別のユーザまたはグループのレベルで臨床担当者に関連付けることが可能である。レイアウトの衝突に備えて、レイアウトモードの階層を確立することが可能である。

【0192】

患者監視装置１４００はまた、臨床担当者の登録済み環境設定に基づいて、他の構成設定を更新することも可能である。これらは、たとえば、生理学的パラメータアラーム限界、アラーム静音化、すべてミュート、平均化時間、アルゴリズムモードなどを含むことが可能である。さらに、患者監視装置１４００は、何らかのタイプの報告（たとえば、所定時間帯にわたる、その監視器によって登録されているすべてアラーム状態の報告）を自動的に作成することが可能である。

【0193】

さらに、臨床担当者近傍検出イベントに対する応答として、アラームの告知および挙動を変更することが可能である。たとえば、アラーム状態を現在登録中のベッドサイド患者監視装置１４００に臨床担当者が近づきつつある場合、臨床担当者が患者監視装置１４００の特定半径内に入ったことが認識されると、アラームが自動的に静音化されることが可能である。実施形態によっては、患者監視装置１４００がアラーム状態を通知する方法は、臨床担当者の物理的位置に依存してよい。たとえば、臨床担当者が既に患者監視装置１４００の近傍にいる間に患者監視装置１４００がアラーム状態を検出した場合、患者監視装置１４００は、可聴アラームを発しないか、小音量の可聴アラームを発することが可能である。アラームの音量は、臨床担当者の存在が検出されたことに基づいて、他の方法でも調節可能である。同様に、そのようなシナリオでは、患者監視装置１４００は、中央監視装置にアラームを送信しないように構成可能である。実施形態によっては、医療監視装置は、アラーム時に既に臨床担当者が存在すれば、他の臨床担当者に対して通知やページングを行わない。医療監視装置のアラーム通知動作は、臨床担当者の存在が検出されたことに基づいて、様々に変更可能である。臨床担当者近傍認識機能を有する医療監視装置は、検出されている臨床担当者が自分の存在を確認できるようにすることが可能である。臨床担当者の存在が検出されている限り、アラームの終了までの長さを変更することが可能である（たとえば、延長することが可能である）。

【0194】

実施形態によっては、患者監視装置１４００は、臨床担当者の存在の検出に対する応答として、その臨床担当者の言語環境設定に従って、監視装置によって表示される文字情報の言語を切り替える。実施形態によっては、患者監視装置は、監視装置の近傍において１人以上の臨床担当者が検出されたことに基づいて、リスク管理のために要求される場合があるオンデバイス確認を識別して実行する。実施形態によっては、患者監視装置は、患者のベッドサイドへの臨床担当者の訪問の数、各訪問の存在時刻、各臨床担当者訪問の長さ、臨床担当者がアラームに対応するまでの時間、その他をログ記録する。臨床担当者は、監視装置で測定されたパラメータをチャート化することを許可されることが可能であり、たとえば、臨床担当者が誰であるかを検出した結果に基づいて、認証情報付き電子医療記録にチャート化することを許可されることが可能である。本明細書に記載の、他の様々なタイプのアクションおよび／または構成変更、またはこれらの組み合わせも、患者監視装置１４００の近傍において臨床担当者が検出されたという事実に基づいて自動的に起動されるように仕向けられることが可能である。

【0195】

図１６は、看護師詰所または中央患者監視装置のグラフィカル・ユーザ・インタフェース１６００の一例を示す。グラフィカル・ユーザ・インタフェース１６００は、図９に関して説明したグラフィカル・ユーザ・インタフェースと同様の機能を有している。たとえば、グラフィカル・ユーザ・インタフェース１６００は、患者状態表示領域１６１０を含んでいる。患者状態表示領域１６１０は、複数の患者状態モジュール１６１２を含んでおり、それぞれがグラフィカル状態インジケータ１６１４を有している。グラフィカル・ユーザ・インタフェース１６００はまた、患者監視器ビュー領域１６２０および履歴ビュー領域１６３０を含んでいる。

【0196】

図９に示すように、中央患者監視装置は、いくつかの患者状態表示領域を含んでおり、それぞれが、別々の患者からの監視情報を表示している。しかしながら、１人の看護師が個別に対応することが可能な数より多くの患者の状態を表示している図９と異なり、図１６は、特定の臨床担当者に割り当てられた患者だけを表示している。中央患者監視装置の表示は、臨床担当者の存在が認識されると、図９の表示から、たとえば、図１６の表示に、自動的に更新されることが可能である。このようにして、臨床担当者は、中央患者監視装置と実際に物理的な対話を行うことなく、中央患者監視装置に近づくだけで、自分に割り当てられた各患者の状態を一目で素早く、かつ便利にチェックすることが可能である。さらに、本明細書に記載の近傍検出機能を用いて、看護師詰所での、患者への臨床担当者の割り当てを容易にすることが可能である。たとえば、ある所定の時間帯において、患者のベッドサイド監視器の近傍で臨床担当者が検出された場合に、図１６のビューに患者が自動的に追加されるようにすることが可能である。

【0197】

図１７は、臨床担当者の存在が検出されたことに基づいて患者監視装置１４００によって既に有効にされている、臨床担当者に固有のアクションをいつ無効にするかを決定する方法１７００を示すフローチャートである。方法１７００では、まず、ブロック１７０２で、本明細書に記載のように、臨床担当者に固有の何らかのアクションが、既に有効にされている。方法１７００は次に、判断ブロック１７０４および判断ブロック１７０８に進む。たとえば、方法１７００は、既に検出されている臨床担当者が患者監視装置の近傍にとどまっているかどうかを検出することと、同時に、より高い優先度の臨床担当者が患者監視装置の近傍に到着したかどうかを検出することと、を含むことが可能である。たとえば、判断ブロック１７０８で示した処理により、より高い優先度の臨床担当者の存在が検出された場合に割り込み信号を生成することが可能である。

【0198】

判断ブロック１７０４では、プロセッサ１４０６は、検出ロジック１４０８を実行して、臨床担当者トークン１４１０からの信号の強度が、ある信号閾値を下回ったかどうかを判定する。この閾値は、図１５の判断ブロック１５０６で使用される閾値と同じであってよい。代替として、これら２つの閾値は、ある程度のヒステリシスを検出システムに与えるために、異なってもよい。このヒステリシスは、臨床担当者トークン１４１０からの信号の強度が、たまたま、選択されている閾値にほぼ等しい場合に、臨床担当者トークン１４１０が、存在状態と不在状態とが短い間隔で繰り返し切り替わるように認識される可能性がある状況に対する保護のために与えられる。臨床担当者トークン１４１０からの信号の強度が信号閾値を下回らない場合、方法１７００は、ブロック１７０２に戻って、臨床担当者に固有のアクションを有効に保ち続ける。一方、臨床担当者トークン１４１０からの信号の強度が、判断ブロック１７０４で使用されている閾値を下回った場合、方法１７００は、判断ブロック１７０６に進む。

【0199】

検出ブロック１７０６では、プロセッサ１４０６は、検出ロジック１４０８を実行して、臨床担当者トークン１４１０からの信号の強度が、ある時間閾値より長い不在時間に対応する信号閾値を下回ったかどうかを判定する。したがって、判断ブロック１７０４および１７０６の組み合わせでは、臨床担当者トークンが、特定時間長にわたって、特定範囲の外側にあったかどうかが判定されることになる。実施形態によっては、この時間閾値は、たとえば、医療監視装置１４００によって表示される情報の内容に応じて可変であってよい。たとえば、患者監視装置１４００がデリケートな個人情報を表示している場合には、患者のプライバシを保護するために、時間閾値を比較的短くすることが可能である。

【0200】

不在時間が、判断ブロック１７０６で使用されている時間閾値を超えない場合、方法１７００は、ブロック１７０２に戻って、臨床担当者に固有のアクションを有効に保ち続ける。一方、不在時間が時間閾値を超えた場合、方法１７００は、ブロック１７１０に進む。ブロック１７１０では、臨床担当者は、患者監視装置１４００の近傍にはもういないものとして認識される。したがって、先に有効にされていた、臨床担当者に固有のアクションが無効にされる。そのような場合、患者監視装置１４００は、図１５に関して説明した待機状態１５０２と同様の状態に戻ることが可能である。実施形態によっては、ブロック１７１０で患者監視装置１４００によって実行されるアクションは、図１５のブロック１５１０で監視装置によって実行されるアクションに対して実質的に逆であってよい。たとえば、臨床担当者の存在が最初に検出されて、その臨床担当者が患者監視装置１４００に自動的にログインした場合は、ブロック１７１０で、この臨床担当者をログアウトすることが可能である。同様に、検出された臨床担当者の環境設定に基づいて患者監視装置１４００の構成が変更された場合、ブロック１７１０では、それらの構成変更を、たとえば、デフォルトの状態に復元することが可能である。

【0201】

ここで判断ブロック１７０８を参照すると、プロセッサ１４０６は、検出ロジック１４０８を実行して、より高い優先度の臨床担当者の存在が検出されたかどうかを判定する。そのような臨床担当者の検出は、たとえば、図１５に関して説明した検出方法１５００に従って進めることが可能である。本明細書に記載のように、２人以上の臨床担当者が検出された場合にどの臨床担当者の存在を認識すべきかを決定するための、均衡を破る条件として動作可能な優先度値を、各臨床担当者に割り当てることが可能である。判断ブロック１７０８において、より高い優先度の臨床担当者が検出されない場合、方法１７００は、ブロック１７０２に戻る。一方、判断ブロック１７０８において、より高い優先度の臨床担当者が検出された場合、方法１７００は、ブロック１７１０に進むことが可能である。ブロック１７１０では、既に検出されていた臨床担当者の存在の認識が無効にされ、新しく検出された、より高い優先度の臨床担当者の存在が認識される。

【0202】

図１８は、患者監視装置１８００を有効にして臨床担当者トークン１８１０の存在を自動的に検出するシステムの概略図である。患者監視装置１８００および臨床担当者トークン１８１０は、異なる点として示すものを除いては、たとえば、本明細書で図１４に関して説明した患者監視装置１４００および臨床担当者トークン１４１０と同様であると考えてよい。図１８に示した実施形態では、患者監視装置１８００は、たとえば、１つ以上のＷｉＦｉアクセスポイント１８３０～１８３２の支援を受けて、臨床担当者トークン１８１０の存在を検出する。ＷｉＦｉアクセスポイント１８３０～１８３２は、患者監視が行われている患者治療環境全体に有利に分散させることが可能である。ＷｉＦｉアクセスポイント１８３０～１８３２は、たとえば、ＩＥＥＥ ８０２．１１規格に基づいて動作可能である。

【0203】

患者監視装置１８００の通信モジュール１８０２は、たとえば、ＷｉＦｉアクセスポイント１８３０～１８３２と通信するためのＷｉＦｉ対応無線機であってよい。実施形態によっては、臨床担当者トークン１８１０は、ＷｉＦｉ対応ＲＦＩＤタグである。患者監視装置１８００は、ＷｉＦｉアクセスポイント１８３０～１８３２と通信することにより、それらのＷｉＦｉアクセスポイントを基準にして自身の位置を三角測量することが可能である。同様に、臨床担当者トークン１８１０の位置も、三角測量することが可能である。したがって、たとえば、患者監視装置１８００が、分散したＷｉＦｉアクセスポイント１８３０～１８３２を用いることにより、患者監視装置１８００に対する臨床担当者トークン１８１０の近似位置を求めることが可能である。実施形態によっては、患者監視装置１８００は、臨床担当者トークン１８１０と直接通信することにより、たとえば、分散したＷｉＦｉアクセスポイント１８３０～１８３２を用いて行われる位置近似を強化することも可能である。

【0204】

図１９は、臨床担当者近傍認識機能を有する患者監視装置ネットワーク１９００の概略図である。患者監視装置ネットワーク１９００は、たとえば、図１、２、６、および７に示したものと同様であってよい。患者監視装置ネットワーク１９００は、複数の患者１９０６、１９１６、１９２６を監視する複数のベッドサイド患者監視器１９０２、１９１２、１９２２を含んでいる。実施形態によっては、ベッドサイド患者監視器１９０２、１９１２、１９２２のそれぞれは、たとえば、図１４（１４００）および図１８（１８００）に示したものと同様である。ベッドサイド患者監視器１９０２、１９１２、１９２２は、臨床担当者トークン１９０４、１９１４、１９２４に基づいて臨床担当者の存在を検出することが可能である。臨床担当者トークン１９０４、１９１４、１９２４は、たとえば、図１４（１４１０）および図１８（１８１０）に示したものと同様であってよい。

【0205】

患者監視装置ネットワーク１９００はまた、患者１９０６、１９１６、１９２６のそれぞれをリモートで監視する看護師詰所システム１９３２を含んでいる。看護師詰所システム（または中央監視装置）１９３２は、本明細書に記載のものと同様であってよい。患者監視装置ネットワーク１９００はまた、登録データベース１９４２を含むことも可能である。本明細書に記載のように、登録データベース１９４２は、臨床担当者トークン１９０４、１９１４、１９２４、１９３４によって保持される固有の臨床担当者ＩＤ（たとえば、１４１４、１８１４）を、それらのトークンが患者監視装置１９０２、１９１２、１９２２、１９３２の存在下にある場合にそれらの患者監視装置を制御する情報に関連付けることが可能である。たとえば、登録データベース１９４２は、各固有臨床担当者ＩＤを、ログイン情報、構成環境設定、および、監視装置が臨床担当者の存在を認識した後に実行する所定のアクションに関連付けることが可能である。

【0206】

図示した患者監視装置ネットワーク１９００では、患者監視装置１９０２、１９１２、１９２２、１９３２のそれぞれが、ネットワーク１９５０を介して互いに通信可能である。実施形態によっては、ネットワーク１９５０は、各種医療装置間の通信を容易にするために、オープンソース通信規格を用いる。図示していないが、患者監視装置ネットワーク１９００はまた、ＷｉＦｉアクセスポイント、ページング送信機、ページャ、および他の、本明細書に記載の装置を含むことも可能である。

【0207】

図２０は、ＷｉＦｉアクセスポイント２０３０～２０３４が分散している病院フロア２０００の概略図である。ＷｉＦｉアクセスポイント２０３０～２０３４を用いることにより、医療装置２００２、２００４、患者２０１０、２０１２、および臨床担当者２０１４、２０１６の物理的位置を推定することが可能である。患者治療領域全体にＷｉＦｉカバレッジを与えるために、ＷｉＦｉアクセスポイント２０３０～２０３４、または他の検出器を、病院フロア、または他の物理的領域の全体に分散させることが可能である。実施形態によっては、ＷｉＦｉアクセスポイント２０３０～２０３４のそれぞれのカバレッジエリア２０４０～２０４４が互いに重なり合う。実施形態によっては、ＷｉＦｉアクセスポイント２０３０～２０３４は、医療装置２００２、２００４、患者２０１０、２０１２、および臨床担当者２０１４、２０１６の各位置を追跡することが必要な、病院フロアのほぼすべての部分で、ＷｉＦｉアクセスポイント２０３０～２０３４のうちの少なくとも３つのカバレッジエリア２０４０～２０４４が重なり合うのに十分な程度に密集している。アクセスポイント２０３０～２０３４は、たとえば、壁の表面または内部、天井の表面または内部、その他にマウント可能である。

【0208】

医療装置２００２、２００４は、本明細書に記載の他のものと同様であってよい。たとえば、実施形態によっては、医療装置２００２、２００４は、患者監視装置である。実施形態によっては、医療装置２００２、２００４に、追跡タグまたはトークン２００６、２００８が装着されている。追跡タグ２００６、２００８は、本明細書に記載の臨床担当者トークンと同様であってよい。実施形態によっては、追跡タグ２００６、２００８は、ＷｉＦｉ対応ＲＦＩＤタグであるが、他のタイプの追跡タグも好適である場合がある。各追跡タグ２００６、２００８は、機器ＩＤを含んでよい。

【0209】

本明細書で既に述べたように、臨床担当者２０１４、２０１６は、臨床担当者トークン２０２２、２０２４を携帯することが可能である。臨床担当者トークン２０２２、２０２４は、本明細書に記載のものと同様であってよい。たとえば、実施形態によっては、臨床担当者トークン２０１４、２０１６は、ＷｉＦｉ対応ＲＦＩＤタグである。実施形態によっては、各患者２０１０、２０１２にも患者トークン２０１８、２０２０を装着することが可能である。患者トークン２０１８、２０２０は、本明細書に記載の臨床担当者トークンと同様であってよい。実施形態によっては、患者トークン２０１８、２０２０は、ＷｉＦｉ対応ＲＦＩＤタグである。これらは、ブレスレット、または他の適切な方法で患者に装着することが可能である。各患者トークン２０１８、２０２０は、患者ＩＤを含んでよい。

【0210】

ＷｉＦｉアクセスポイント２０３０～２０３４の分散ネットワークを用いて、医療装置追跡タグ２００６、２００８、臨床担当者トークン２０２２、２０２４、および患者トークン２０１８、２０２０と通信することにより、病院２０００内のこれらのタグおよびトークンのそれぞれの物理的位置を推定することが可能である。たとえば、ＷｉＦｉアクセスポイント２０３０～２０３４を用いて、各タグまたはトークンの位置を三角測量することが可能である。

【0211】

図２０は、追跡タグ２００６、２００８、臨床担当者トークン２０２２、２０２４、および患者トークン２０１８、２０２０の位置を検出するために使用可能なＷｉＦｉアクセスポイント２０３０～２０３４の分散ネットワークを示しているが、他の装置も同様の目的に使用可能である。たとえば、実施形態によっては、ＷｉＦｉアクセスポイント２０３０～２０３４が無効にされ、短距離送受信機を有する医療装置２００２、２００４、または他の検出器が、それらの場所でアドホックネットワークを形成するために用いられる。各医療装置２００２、２００４は、アドホックネットワーク内でノードとして動作可能であり、各ノードは、たとえば、各ノードを取り巻く患者２０１０、２０１２、および臨床担当者２０１４、２０１６に関する情報を共有することが可能である。実施形態によっては、医療装置２００２、２００４はＢｌｕｅｔｏｏｔｈ（登録商標）対応であるが、他の短距離無線通信規格も使用可能である。

【0212】

病院フロア２０００に、十分に密集して配列された、いくつかの医療装置が含まれる場合、分散した医療装置２００２、２００４は、たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）対応の医療装置追跡タグ２００６、２００８、患者トークン２０１８、２０２０、および臨床担当者トークン２０２２、２０２４の位置を追跡するためのネットワークとして動作可能である。そのような実施形態では、各追跡タグまたはトークンの物理的位置は、それがＢｌｕｅｔｏｏｔｈ（登録商標）対応医療装置のレンジ内にある場合のみ識別可能であってよい。さらに、実施形態によっては、各追跡タグまたはトークンの物理的位置は、正確には識別できない場合がある。これは、各Ｂｌｕｅｔｏｏｔｈ（登録商標）対応医療装置が、追跡タグまたはトークンは、その医療装置の検出範囲内のどこかにあることしか突き止められない可能性があるからである。それにもかかわらず、このレベルの追跡分解能は、多くの場合には十分である。

【0213】

図２０に示した実施形態では、ＷｉＦｉアクセスポイント２０３０、２０３４に位置監視サーバを通信可能に結合することが可能である。位置監視サーバは、各医療装置２００２、２００４、各患者２０１０、２０１２、および各臨床担当者２０１４、２０１６の推定位置を追跡するように構成可能である。位置監視サーバは、この位置情報を表示するディスプレイを含んでよい。さらに、位置監視サーバ、または他の何らかの装置は、本明細書に記載の患者監視システムの提供機能を強化する上で役立つことが可能なロジックを実行することが可能である。位置監視サーバはまた、医療装置２００２、２００４と通信可能に結合可能である。

【0214】

図２０に示したシステムを用いて、たとえば、本明細書に記載の患者監視システムを強化することが可能である。既述のように、本明細書に記載の患者監視システムは、たとえば、監視対象患者の生理学的パラメータ（たとえば、ＳｐＯ_２、呼吸数、その他）によってアラームがトリガされた場合に、臨床担当者に通知することが可能である。実施形態によっては、その患者の監視を割り当てられた臨床担当者に、最初に通知が、たとえば、ページング、電子メール、文字メッセージなどによって行われる。最初に通知された臨床担当者が所定時間以内に対応しない場合、患者監視システムは、その患者のアラーム状態を別の１人以上の臨床担当者に通知するエスカレーションアルゴリズムを実行するように構成可能である。実施形態によっては、アラーム状態が存在する場合に送出される臨床担当者通知は、少なくとも部分的には、位置ベースのルールを用いて制御可能である。たとえば、どの臨床担当者に最初にアラーム状態を通知するか、ならびに、エスカレーションが必要になった場合は、どの１人またはそれ以上の臨床担当者に通知するかを、位置ベースルールで決定することが可能である。位置ベースルールは、（たとえば、患者２０１０、２０１２、および／または臨床担当者２０１４、２０１６の）物理的位置に関する、図２０に示したシステムからの情報を入力として受信することが可能である。

【0215】

位置ベースルールは、たとえば、患者２０１０、２０１２、および／または臨床担当者２０１４、２０１６の絶対位置または相対位置に依存してよい。たとえば、患者２０１０がアラーム状態になった場合、その患者が既に割り当てられている臨床担当者が病院の同じフロア（または何らかの他の領域）にいれば、その臨床担当者に最初に通知することが可能である。実施形態によっては、アラーム状態にある患者の最も近くにいる臨床担当者に通知することが可能であり、これは、その臨床担当者がその患者に既に割り当てられていたかどうかにかかわらず行われる。実施形態によっては、アラーム状態にある患者に正規に割り当てられていた臨床担当者が所定時間以内に対応できなかった場合に限り、その患者の最も近くにいる臨床担当者に通知することが可能である。実施形態によっては、アラーム状態が特に緊急であって即時対応を要する場合に、近くの看護師にアラーム状態を通知する。他にも様々な位置ベースルールが実装可能である。

【0216】

また、アラームを停止させることを臨床担当者に許可するかどうかを、位置ベースルールで制御することも可能である。本明細書に開示のように、臨床担当者トークン２０２２、２０２４は、入力モジュール（たとえば、１４１６）を含むことが可能である。この入力モジュールの１つの用途は、臨床担当者がアラームの通知を受け、その患者に向かった時点でアラームをリモートで無効にすることである。しかしながら、実施形態によっては、臨床担当者が、たとえば、患者から、ある閾値距離より離れている場合に、臨床担当者がアラームをリモートで無効にすることを禁ずることが可能な位置ベースルールが実行可能である。

【0217】

また、図２０に示したシステムによって与えられる位置情報を用いて、患者２０１０、２０１２が、その患者に割り当てられた監視装置から、ある閾値距離より離れた場合に、臨床担当者にアラートを与えることが可能である。患者監視システムの文脈で位置ベースルールのいくつかの例を説明したが、図２０に示したシステムによって与えられる情報を用いて、多くの様々な医療装置に関して様々な位置ベースルールを実装することが可能である。たとえば、選択されたアクションが、装置、臨床担当者、および／または患者の推定された物理的距離に全面的に（または部分的に）依存する場合にそのアクションを実行するかどうかを決定するためのルールも、そのような位置ベースルールの１つである。

【0218】

実施形態によっては、医療装置２００２、２００４を構成する場合（たとえば、患者監視設定を構成する場合）にも、位置ベースルールを設けることが可能である。たとえば、本明細書に記載のタイプの患者監視装置を、その患者監視装置が配置される病棟ごとに異なる生理学的パラメータアラーム限界で構成する場合がある。たとえば、新生児の脈拍数に関するアラーム限界は、一般に、成人の脈拍数の場合と異なる設定にしなければならない。したがって、新生児用のアラーム限界が設定された監視装置を使用して、新生児室の外にいる患者を監視しようとした場合には臨床担当者に通知することが望ましいであろう。これが可能なのは、図２０に示したシステムが医療装置の位置を検出できるためである。監視装置の物理的位置に基づいて、他の監視装置構成設定を、臨床担当者に推奨することも、自動的に設定することも可能である。実施形態によっては、参照によってその内容全体が本明細書に組み込まれている米国特許出願公開第２００９／０２７５８４４号明細書に開示されている構成設定および手法を、本明細書に記載の位置ベースルールを用いて制御することが可能である。

【0219】

図２１～２３は、ユーザが近傍にいることに対する応答として、第１の画面から好ましい画面に回転するように表示される多面アニメーション機能を有する近傍表示２１００、２２００、２３００を示す。有利なことに、この機能は、監視器が、上述の識別信号をユーザから受信し、そのユーザの存在を認識したことを、ユーザにフィードバックする。たとえば、この多面提示は、複数のファセットを有し、それらのファセットのうちの２つ以上に異なる画面環境設定を有する三角形状固体、立方体形状固体、または平面固体のいずれであってもよい。当業者であれば理解されるように、球や円筒のような非ファセット形状を含む、他の様々な、回転する幾何形状が、同様のユーザフィードバックを与えることが可能である。以下では、これらの多面提示について詳細に説明する。

【0220】

図２１Ａ～Ｆは、近傍表示２１００の実施形態を示しており、これは、回転する三角形固体２１０５を利用して、監視器の近傍を出入りする複数の監視器ユーザの様々な表示環境設定に対応する複数の画面の切り替わりを表す。具体的には、三角形固体２１０５は、第１の面２１０１、第２の面２１０２、および第３の面２１０３を有しており、これらの各面は、ユーザがディスプレイの近傍にいることに対する応答として、様々なユーザ環境設定で患者監視情報を表示するように構成されている。さらに、三角形固体２１０５は、近傍ユーザにフィードバックを与えるために面２１０１、２１０２、２１０３の間で切り替わる際に回転するように表示される。

【0221】

図２１Ａに示すように、第１のユーザに関連する第１の面２１０１は、ディスプレイ２１１０に表示される。図２１Ｂに示すように、第２のユーザがディスプレイの近傍に入ると、監視器は、後で図７に関して説明するように、第２のユーザを識別し、三角形固体２１０５を第１の面２１０１から第２の面２１０２に仮想的に回転させる。そして、図２１Ｃに示すように、ディスプレイ２１１０は、第２のユーザの表示環境設定に対応する第２の面２１０２を表示する。図２１Ｄに示すように、第３のユーザが監視器の近傍に入ると、監視器は、第３のユーザを識別し、三角形固体２１０５を第２の面２１０２から第３の面２１０３に仮想的に回転させる。そして、図２１Ｅに示すように、ディスプレイ２１１０は、第３のユーザの表示環境設定に対応する第３の面２１０３を表示する。図２１Ｆに示すように、第１のユーザが再度識別されると、ディスプレイ２１１０は、三角形固体を仮想的に回転させて、第１の面２１０１に戻す。このようにして、三角形固体２１０５の面２１０１、２１０２、２１０２は、様々なユーザ環境設定に従って、かつ、ユーザが監視器の近傍にいるかどうかに基づいて、ディスプレイ２１１０に選択的に表示される。図１３に関して説明したように、複数のユーザが監視器の近傍に同時に存在する場合は、優先度方式または了解方式を用いて、どの画面を表示するかを決定する。

【0222】

図２２Ａ～Ｅは、近傍表示２２００の実施形態を示しており、これは、回転する立方体２２０５を利用して、監視器の近傍を出入りする複数の監視器ユーザの様々な表示環境設定に対応する複数の画面の切り替わりを表す。具体的には、立方体２２０５は、第１の面２２０１、第２の面２２０２、および第３の面２２０３を有しており、これらの各面は、ユーザがディスプレイの近傍にいることに対する応答として、様々なユーザ環境設定で患者監視情報を表示するように構成されている。さらに、立方体２２０５は、近傍ユーザにフィードバックを与えるために面２２０１、２２０２、２２０３の間で切り替わる際に回転するように表示される。これは、図２１Ａ～Ｆに関して既に詳述したものと同様に行われる。

【0223】

図２３Ａ～Ｃは、近傍表示２３００の実施形態を示しており、これは、回転する平面固体２３０５を利用して、監視器の近傍を出入りする複数の監視器ユーザの様々な表示環境設定に対応する複数の画面の切り替わりを表す。具体的には、平面固体２３０５は、第１の面２３０１、および第２の面２３０２を有しており、これらの各面は、ユーザがディスプレイの近傍にいることに対する応答として、様々なユーザ環境設定で患者監視情報を表示するように構成されている。さらに、平面固体２３０５は、近傍ユーザにフィードバックを与えるために面２３０１、２３０２の間で切り替わる際に回転するように表示される。これは、図２１Ａ～Ｆおよび図２２Ａ～Ｅに関して既に詳述したものと同様に行われる。

【0224】

本明細書では、ベッドサイド監視器に関していくつかの特徴を記載しているが、近傍表示は、ベッドサイドであれ、中央監視場所（看護師詰所など）であれ、任意の場所にある、医療用であれ、非医療用であれ、任意の監視装置に適用可能である。さらに、近傍表示は、生理学的データ収集または他の監視器用途（たとえば、履歴データの精査、アラーム限界の設定および確認、医療担当者または機器保守担当者によるソフトウェア更新のインストールなど）において適用可能である。装置間およびシステム間の通信を促進するための医療通信プロトコルの変換

【0225】

医療コストは上昇を続けており、価格が妥当で高品質な患者治療に対する要求も高まっている。医療コストは、病院情報システムの有効性を高めることにより、削減が可能である。医療機関の有効性に影響を及ぼしうる要因の１つは、医療機関で使用されている様々な臨床コンピュータシステム同士が、どの程度、互いに対話して情報を交換することが可能か、である。

【0226】

病院、患者治療施設、および医療供給者機関は、典型的には、非常に様々な臨床コンピュータシステムを、電子医療情報の管理のために備えている。ＩＴまたは管理インフラストラクチャ全体の中で各臨床コンピュータシステムは、患者治療プロセスの特定のカテゴリまたは側面を満たすことを支援することが可能である。たとえば、病院が備えている可能性があるのは、患者監視システム、医療用文書化および／または撮像システム、患者管理システム、電子医療記録システム、電子業務管理システム、営業財務システム（調剤および課金など）、および／または通信システム、その他である。

【0227】

病院または他の患者治療施設における治療の品質を向上させるためには、ＩＴインフラストラクチャ全体において異なる臨床コンピュータシステムのそれぞれが効果的に相互通信できることが必要であろう。そうすれば、ある臨床コンピュータシステムで収集した患者データを、そのような患者データから恩恵を受けうる別の臨床コンピュータシステムと交換することが可能になるであろう。たとえば、これにより、行うべき患者治療や実行すべきアクションに関する決定を、利用可能なすべての情報の完全な分析に基づいて行うことが可能になるであろう。

【0228】

現行の運用では、個々の臨床コンピュータシステムは、別々のベンダから供給可能であり、多くの場合はそのようになっている。結果として、個々の臨床コンピュータシステムは、独自のネットワークまたは通信インフラストラクチャ、独自の通信プロトコルなどを用いて実装可能であるため、病院で使用されている様々な臨床コンピュータシステムは、必ずしも効果的には相互に通信できていない。

【0229】

医療装置および医療システムのベンダは、自社の市場シェアを増やし、追加の製品、システム、および／またはアップグレードを医療供給者に高く売りつけるために、他のベンダの医療装置および医療システムとの効果的な通信ができない独自システムを開発することがある。したがって、医療供給者は、運用する個々の臨床コンピュータシステムのタイプごとに、利用可能な最良の技術を選択するのではなく、事業全体またはシステム全体での購買決定を強いられる。

【0230】

こうしたことが起こる一例が、患者監視に利用可能な救命技術の分野にある。たとえば、様々な生理学的パラメータを監視するベッドサイド装置は、多くの様々なものが、様々なベンダや供給業者から入手可能である。そのような供給業者の１つが、ある特定の生理学的パラメータの監視に関してクラス最高の装置を提案する一方、別のそのような供給業者が、別の生理学的パラメータに関して、クラス最高の装置を提案する場合がある。したがって、病院は、状況によっては、複数の製造元からの監視装置を使用する自由があることが望ましい場合もあるが、異なる製造元からの装置同士がインタフェースも患者情報の交換もできない場合には、そのような自由を持つことはできないであろう。したがって、価格が妥当で高品質な患者治療を提供することができなくなる可能性がある。さらに、各病院または患者治療施設も、それぞれの臨床コンピュータネットワーク環境に独自の通信プロトコルを実装する可能性があるため、情報交換をさらに妨げる可能性がある。

【0231】

医療コンピュータシステム間および装置間の臨床メッセージ伝達のためのメッセージングの枠組を与えるために、Ｈｅａｌｔｈ Ｌｅｖｅｌ Ｓｅｖｅｎ（「ＨＬ７」）プロトコルを開発した。ＨＬ７通信プロトコルは、様々なＨＬ７準拠の臨床コンピュータシステム同士が相互通信を行うために使用できる、いくつかの規格、指針、および方法論を指定する。

【0232】

ＨＬ７通信プロトコルは、多くの医療装置メーカーによって採用されている。しかしながら、ＨＬ７規格は、きわめてフレキシブルであって、指針の枠組（たとえば、メッセージのハイレベル論理構造）を与えるに過ぎない。したがって、各医療装置または医療システムのメーカーまたはベンダは、ＨＬ７準拠を維持しながら多少異なるようにＨＬ７プロトコルを実装することが可能である。たとえば、ＨＬ７メッセージのフォーマットは、実装ごとに異なってよい。これについては、本明細書で詳細に説明する。場合によっては、ある実装のＨＬ７メッセージが、別のＨＬ７の実装に従うメッセージに含まれない情報内容を含むことも可能である。したがって、医療装置または臨床コンピュータシステムがすべてＨＬ７準拠であっても、相互通信ができない可能性が依然としてある。

【0233】

したがって、必要とされているのは、確立された通信プロトコル（たとえば、ＨＬ７）の、許容される別々の実装を用いた医療装置間またはシステム間の医療メッセージの伝達を改善することが可能であり、それによって、複数の臨床コンピュータシステムを統合して患者治療の品質を高めることが可能なモジュールである。

【0234】

図２４Ａは、第１の医療装置２４０５と第２の医療装置２４１０とが変換モジュール２４１５を介して相互通信する様子を示す。第１の医療装置２４０５は、ある認められた電子医療通信プロトコルの、第１の許容されるフォーマットまたは実装に従ってメッセージの送受信を行うように構成されており、第２の医療装置２４１０は、その電子医療通信プロトコルの、第２の許容されるフォーマットまたは実装に従ってメッセージの送受信を行うように構成されている。実施形態によっては、第１および第２のプロトコルフォーマットは、ＨＬ７通信プロトコルの別々の実装である。ＨＬ７以外の電子医療通信プロトコルも使用可能である。

【0235】

変換モジュール２４１５は、第１のプロトコルフォーマットを有する入力メッセージを第１の医療装置２４０５から受信し、第２のプロトコルフォーマットを有する出力メッセージを生成して第２の医療装置２４１０に送信する。変換モジュール２４１５はまた、第２のプロトコルフォーマットを有する入力メッセージを第２の医療装置２４１０から受信し、第１のプロトコルフォーマットを有する出力メッセージを生成して第１の医療装置２４０５に送信する。したがって、変換モジュール２４１５は、第１および第２の医療装置２４０５、２４１０が効果的かつシームレスに相互通信することを可能にするものであり、この場合、各装置によって実装された通信機器またはプロトコルを修正することは必ずしも必要ではない。

【0236】

特定実施形態では、変換モジュール２４１５は、入力メッセージの意図された受信側が予期するプロトコルフォーマットを、たとえば、入力メッセージ内の情報に基づいて、または様々な装置で使用されるプロトコルフォーマットを格納したデータベースを参照して特定し、意図された受信側の装置またはシステムで使用されるプロトコルフォーマットに基づいて出力メッセージを生成する。出力メッセージは、変換モジュール２４１５からのアクセスが可能な変換ルールセット２４２０との比較に基づいて（かつ、変換ルールセット２４２０の適用に基づいて）生成可能である。

【0237】

変換ルール２４２０は、共通プロトコルの範囲内でありうる、フォーマッティング実装が一様でないことに対処する方法を制御するルールを含むことが可能である。電子医療通信プロトコルのフォーマッティング実装が一様でないことの例としては、データフィールドを区切るために使用される区切り文字または分離文字、特定のフィールドが必須なのかオプションなのか、メッセージの各部分の繰返し性（たとえば、セグメント、フィールド、コンポーネント、サブコンポーネント）、メッセージの各部分のシーケンス（たとえば、フィールドまたはコンポーネントの順序）、メッセージの特定の部分が含まれているかどうか、メッセージまたはメッセージの各部分の長さ、メッセージの様々な部分に使用されるデータ型などがある。

【0238】

特定実施形態では、変換ルール２４２０は、第１のＨＬ７実装に準拠している入力メッセージを、第２のＨＬ７実装に準拠している出力メッセージに「変換」するために実行する必要がある追加、削除、交換、および／または修正を定義している。出力メッセージは、たとえば、入力メッセージの実体または内容のすべて（または一部）を維持したまま、入力メッセージと異なるフォーマッティングを有することが可能である。

【0239】

変換モジュール２４１５は、共通電子医療通信プロトコルの別々の実装（たとえば、ＨＬ７メッセージの別々のフォーマッティング）の間の変換を行うことに加えて、別々の通信プロトコルに準拠した入力メッセージと出力メッセージとの間の変換を行うようにも構成可能である。実施形態によっては、変換モジュール２４１５は、たとえば、ある医療通信プロトコルのメッセージに応答して、これを別の医療通信プロトコルのメッセージに変換することが可能である。たとえば、変換モジュール２４１５は、ＨＬ７プロトコル、ＩＳＯ １１０７３プロトコル、他のオープンプロトコル、および／または独自プロトコルに従って送信されるメッセージ間の通信を促進することが可能である。したがって、ＨＬ７プロトコルに従って送信された入力メッセージを、別のプロトコルに従う出力メッセージに変換することが可能であり、この逆も可能である。

【0240】

以下では、変換モジュール２４１５および変換ルール２４２０の動作について、詳細に説明する。ここでは、変換モジュール２４１５を含むシステムアーキテクチャの様々な実施形態について説明する。

【0241】

特定実施形態では、第１の医療装置２４０５、第２の医療装置２４１０、および変換モジュール２４１５は、共通通信ネットワークへの接続を介して、通信可能に結合されている。実施形態によっては、第１の医療装置２４０５と第２の医療装置２４１０との間のすべてのメッセージが、変換モジュール２４１５を通って送信されるように、変換モジュール２４１５を、（通信ネットワークの有無にかかわらず）第１の医療装置２４０５と第２の医療装置２４１０との間に通信可能に結合することが可能である。他のアーキテクチャも可能である。

【0242】

第１および第２の医療装置２４０５、２４１０および変換モジュール２４１５は、たとえば、上述の、図２の生理学的監視システム２００または図６の臨床ネットワーク環境６００の一部分に含めることが可能である。特定実施形態では、生理学的監視システム２００のその一部分は、生理学的監視システム２００のメッセージングサブシステムの、病院で使用される各種臨床コンピュータシステムの間のデータ交換をサポートする部分を含んでいる。

【0243】

特定実施形態では、変換モジュール２４１５は、病院環境内の複数のネットワークにまたがる通信を促進することが可能である。他の実施形態では、変換モジュール２４１５は、病院（または臨床）ネットワーク環境の外に延びる１つ以上のネットワークにまたがるメッセージ通信を促進することが可能である。たとえば、変換モジュール２４１５は、金融機関、保険会社、政府機関、院外薬局、他の病院、介護施設、または患者治療施設、診療室などとの通信インタフェースを提供することが可能である。

【0244】

実施形態によっては、図２４の変換モジュール２４１５は、たとえば、本明細書に記載の患者監視システム２００のコンポーネントであってよい。たとえば、変換モジュール２４１５は、図２に示した病院ネットワーク２２０と通信可能に結合可能である。そのような実施形態では、変換モジュール２４１５は、たとえば、生理学的パラメータ測定値、生理学的パラメータ動向情報、生理学的パラメータアラーム状態などの患者監視情報を、ベッドサイド医療監視装置、看護師詰所監視システム、病院用または臨床用情報システム（電子医療記録が格納可能）、および／または他の多くの医療装置およびシステムの間で交換することを促進することが可能である。変換モジュール２４１５は、異なる医療装置およびシステムの間のシームレスな通信を可能にすることができ、これらの装置およびシステムのそれぞれは、臨床（または病院）ネットワーク環境内で、たとえば、ＨＬ７通信プロトコルのような電子医療通信プロトコルの別々の実装を使用してよい。

【0245】

特定実施形態では、変換モジュール２４１５は、患者監視サブシステムの一部である第１の医療装置と、患者監視システム２００の一部ではない（または外部にある）第２の医療装置との間の通信を促進することも可能である。したがって、変換モジュール２４１５は、外部で生成された医療メッセージ（たとえば、ＨＩＳまたはＣＩＳからの患者情報更新メッセージ、状態問合せメッセージなど）に応答すること、ならびに外部報告メッセージ（たとえば、患者監視器または看護師詰所監視システムからのイベント報告メッセージ、アラーム通知メッセージなど）を生成することが可能であってよい。

【0246】

別の実施形態では、第１および第２の医療装置２４０５、２４１０は、通信バス２４２１を経由して相互通信する。通信バス２４２１は、インターネット、病院ＷＬＡＮ、ＬＡＮ、パーソナルエリアネットワークなどを含む、上述の通信ネットワーク、システム、および方法のうちの任意の１つ以上を含んでよい。たとえば、図１、２、６、７、１９などに関して上述したネットワークのいずれかを用いて、上述の第１および第２の医療装置２４０５、２４１０を含む複数の医療装置の間の通信を促進することが可能である。そのような実施形態の１つを、図２４Ｂに示す。

【0247】

図２４Ｂでは、第１の医療装置２４０５が通信バス２４２１にメッセージを供給する。このメッセージは、第２の医療装置２４１０が受信することを意図しているが、第１および第２の医療装置２４０５、２４１０が別々の通信プロトコルフォーマットに従って通信しているために、第２の医療装置２４１０は、そのメッセージを処理することができない。

【0248】

変換モジュール２４１５は、そのようなメッセージに関して、通信バス２４２１を監視している。変換モジュールは、そのメッセージを受信し、第１の医療装置２４０５が第２の医療装置２４１０と通信しようとしていることを知る。変換モジュール２４１５は、メッセージ変換によって、第１の医療装置２４０５と第２の医療装置２４１０との間の通信が促進されると判断する。そこで、変換モジュール２４１５は、変換モジュール２４２０に格納されている適切な変換ルールを利用する。変換モジュール２４２０は、メモリ、すなわち、ＥＰＲＯＭ、ＲＡＭ、ＲＯＭ、その他を含むことが可能である。

【0249】

変換モジュール２４１５は、本明細書に記載のいずれかの方法に従って、第１の医療装置２４０５からのメッセージを変換する。変換後、変換モジュール２４１５は、変換したメッセージを通信バス２４２１に引き渡す。第２の医療装置２４１０は、変換されたメッセージを受信し、しかるべき応答を行う。たとえば、第２の医療装置２４１０は、ある機能を実行するか、かつ／または、第１の医療装置２４０５と通信しようとするであろう。変換モジュール２４１５は、同様に、第２の医療装置２４１０から第１の医療装置２４０５への通信を促進する。

【0250】

第１の医療装置２４０５および第２の医療装置２４１０は、たとえば、図２に示した病院ネットワーク２２２に通信可能に結合された、いずれかの医療装置またはシステムであってよい。これらの医療装置またはシステムは、たとえば、ポイントオブケア装置（ベッドサイド患者監視器など）、データ記憶装置または患者記録データベース、病院（または臨床）情報システム、中央監視装置（看護師詰所監視システムなど）、および／または臨床装置（ページャ、携帯電話、スマートフォン、個人用携帯情報端末（ＰＤＡ）、ラップトップ、タブレットＰＣ、パーソナルコンピュータ、ポッドなど）などであってよい。

【0251】

実施形態によっては、第１の医療装置２４０５は、生理学的パラメータ（たとえば、酸素飽和度、脈拍数、血圧、その他）を追跡するために患者に通信可能に結合された患者監視器であり、第２の医療装置２４１０は、病院情報システム（「ＨＩＳ」）または臨床情報システム（「ＣＩＳ」）である。実施形態によっては、患者監視器は、生理学的パラメータ測定値、生理学的パラメータアラーム、または他の、患者の監視中に生成された生理学的パラメータ測定情報を、ＨＩＳまたはＣＩＳによって維持されている、患者の電子医療記録に含めるために、ＨＩＳまたはＣＩＳに伝達する。

【0252】

実施形態によっては、第１の医療装置２４０５は、ＨＩＳまたはＣＩＳであり、第２の医療装置２４１０は、本明細書に記載の看護師詰所監視システムである。しかしながら、変換モジュール２４１５は、病院または他の患者治療施設で使用されている広く様々な医療装置およびシステムの間の通信を促進することが可能である。たとえば、変換モジュール２４１５は、患者生理学的パラメータ監視装置同士の通信、監視装置と看護師詰所監視システムとの間の通信などを促進することが可能である。

【0253】

本明細書に記載の患者監視サブシステム（たとえば、生理学的監視システム２００）のような患者監視サブシステムは、変換モジュール２４１５を用いて、ＨＩＳが、ＨＬ７プロトコルの別の実装、または他の何らかの電子医療通信プロトコルを使用している場合でも、そのＨＩＳにデータをプッシュしたり、そのＨＩＳからデータをプルしたりすることが可能である。

【0254】

特定実施形態では、患者監視サブシステムは、所定の間隔でデータをプッシュ／プルするように構成可能である。たとえば、患者監視器または臨床担当者詰所監視システムは、患者が患者監視器に接続された時点で患者データが既に利用可能であるように、周期的な間隔でＨＩＳから患者データを自動的にダウンロードすることが可能である。ＨＩＳから送信された患者データは、患者の登録時に受信された入院／退院／転院（［ＡＤＴ」）情報を含むことが可能である。ＡＤＴメッセージの起動は、病院情報システムによって可能であり、これは、たとえば、患者が入院、退院、転院したこと、または登録されたこと、あるいは、患者情報が更新またはマージされたこと、あるいは転院または退院が取り消されたことを、補助システムに通知するために行われる。

【0255】

他の実施形態では、患者監視サブシステムは、ＨＩＳに対して問合せによる要請があった場合に限り、データをＨＩＳにプッシュしたり、ＨＩＳからプルしたりするように構成可能である。たとえば、臨床担当者が、ＨＩＳ上の、患者の電子医療記録に格納されている情報を要求することが可能である。

【0256】

さらに別の実施形態では、患者監視サブシステムは、要請されていないイベントに対する応答として、データをＨＩＳにプッシュしたり、ＨＩＳからプルしたりするように構成可能である。たとえば、監視中の患者の生理学的パラメータによってアラーム状態が入力されることが可能であり、これは、患者の電子医療記録に格納されるように自動的にＨＩＳに送信されることが可能である。さらに別の実施形態では、いつ、ＨＩＳとの間でメッセージをやりとりするかを決定するために、上述の方法または代替の方法の任意の組み合わせを用いることが可能である。

【0257】

変換モジュール２４１５を用いるメッセージ伝達のためのシステムアーキテクチャ例およびトリガ例を説明してきた。次に、変換モジュールの動作について説明する。図２５Ａ～２５Ｄは、変換プロセスの様々なフェーズまたはステップにおける医療メッセージの例を示す。この変換プロセスの詳細については、後で図２６、２７Ａ、および２７Ｂに関して詳述する。

【0258】

図２５Ａは、変換モジュール２４１５がＨＩＳから受信したＡＤＴ入力メッセージ例２５０５を示す。ＡＤＴ入力メッセージ２５０５は、ＨＬ７通信プロトコルに従って実装されており、患者の入院に関連する情報を含んでいる。ＡＤＴ入力メッセージ２５０５は、複数のセグメントを含んでおり、それらは、メッセージ・ヘッダ・セグメント２５０６、イベントセグメント、患者識別セグメント、患者診察セグメント、役割セグメント、診断セグメント、および複数のカスタムセグメントを含んでいる。

【0259】

実施形態によっては、メッセージヘッダ（「ＭＳＨ」）セグメント２５０６は、メッセージの送信され方、フィールド区切り記号およびエンコード文字、メッセージタイプ、送信側および受信側、その他を定義している。ＭＳＨ文字列の後の最初の記号または文字は、フィールド区切り記号または分離記号を定義することが可能である（このメッセージでは「カレット」記号）。次の４つの記号または文字は、エンコード文字を定義することが可能である。１番目の記号は、コンポーネント区切り記号（「～」）を定義する。２番目の記号は、繰り返し区切り記号（「｜」）を定義する。３番目の記号は、エスケープ区切り記号（「＼」）を定義する。４番目の記号は、サブコンポーネント 区切り記号（「＆」）を定義する。これらの区切り記号はすべて、複数のＨＬ７実装の間で一様でない可能性がある。

【0260】

実施形態によっては、ヘッダセグメント例２５０６はさらに、送信側アプリケーション（「ＶＡＦＣ ＰＩＭＳ」）、受信側アプリケーション（「ＮＰＴＦ－５０８」）、メッセージの日付／時刻（「２００９１１２０１０４６０９－０６００」）、メッセージタイプ（「ＡＤＴ－Ａ０１」）、メッセージ制御ＩＤ（「５８１０３」）、処理ＩＤ（「Ｐ」）、および国コード（「ＵＳＡ」）を含む。連続するカレット記号で表されるように、ヘッダセグメントは、複数の空白フィールドも含んでいる。

【0261】

図２５Ｂは、識別されたフィールド区切り記号（カレット記号）に基づいてフィールドまたはエレメントとして解析されたメッセージ・ヘッダ・セグメント２５０６を示す。特定実施形態では、解析済み入力メッセージは、拡張可能スタイルシート言語変換（ＸＳＬＴ）ルールに従って変換されるように構成されたＸＭＬメッセージを含む。

【0262】

特定実施形態では、解析済み入力メッセージはエンコード可能である。図２５Ｃは、（たとえば、ユニコード変換フォーマット８（「ＵＴＦ－８」）エンコード方式を用いて）エンコードされた後の入力メッセージの解析済みメッセージ・ヘッダ・セグメントを示す。

【0263】

エンコード済みメッセージ・ヘッダ・セグメントは、メッセージにおいて使用可能な様々なデータ型のうちのいくつかを示す。たとえば、３番目の解析済みフィールドの送信側アプリケーション（「ＶＡＦＣ ＰＩＭＳ」）および５番目の解析済みフィールドの受信側アプリケーション（「ＮＰＴＦ－５０８」）は、階層的デジグネータ（「ＨＤ」）名データ型を用いて表される。日付／時刻フィールド（７番目の解析済みフィールド）は、タイムスタンプ（「ＴＳ」）データ型を用いて表される。処理ＩＤフィールド（１１番目の解析済みフィールド）は、処理タイプ（「ＰＴ」）データ型を用いて表される。データ型識別子を含まないフィールドは、文字列（「ＳＴ」）データ型を用いて表される。他の可能なデータ型として、たとえば、符号化エレメント、構造化数値、タイミング数量、テキストデータ、日付、エントリ識別子、符号化値、数値、シーケンス識別などがある。これらのセグメントの様々なフィールドおよび属性に使用するデータ型は、複数のフォーマッティング実装間で一様でない可能性がある。

【0264】

図２５Ｄは、図２５Ａの入力メッセージ例２５０５に基づく、変換モジュール２４１５からの出力メッセージ例２５１０を示す。出力メッセージ２５１０は、メッセージ受信確認セグメント２５１２を含む。

【0265】

変換モジュールの動作についてであるが、変換モジュール２４１５は、たとえば、変換ルールセット２４２０の適用に基づいて、入力メッセージを反映する出力メッセージを作成、発生、または生成することが可能である。実施形態によっては、変換モジュール２４１５は、たとえば、変換ルールセット２４２０との比較（および変換ルールセット２４２０の適用）に基づいて、入力メッセージを翻訳、変形、変換、再フォーマット、構成、変更、再配列、修正、適応、改変、または調節して、出力メッセージを形成することが可能である。実施形態によっては、変換モジュール２４１５は、たとえば、入力メッセージを、入力メッセージの内容を保持しながら、変換ルールセット２４２０との比較（および変換ルールセット２４２０の適用）に基づく新しいフォーマッティング実装を有する出力メッセージに交換または置換することが可能である。

【0266】

図２６は、入力メッセージと、変換モジュール２４１５に関連付けられた変換ルールセット２４２０との比較と、に基づいて、出力メッセージを生成する変換プロセス２６００を示す。変換プロセス２６００では、まず、ブロック２６０２で、変換モジュール２４１５が、第１の医療装置から入力メッセージを受信する。

【0267】

ブロック２６０４では、変換モジュール２４１５は、入力メッセージのフォーマッティング実装、および出力メッセージに用いるフォーマッティング実装を決定する。特定実施形態では、入力メッセージは、フォーマッティング実装を表す１つ以上の識別子を含むことが可能である。実施形態によっては、フォーマッティング実装の決定は、たとえば、メッセージ自体を解析することによって可能であり、この解析は、使用されている区切り記号またはエンコード文字、フィールドの順序、セグメント、フィールド、またはコンポーネントの繰り返し性、フィールドのデータ型、または他の実装変形形態を識別することよって行う。特定実施形態では、変換モジュール２４１５は、フォーマッティング実装の決定を支援するために、（図２５Ｂに示したように）メッセージの内容からフォーマッティングを分離または解析することが可能である。実施形態によっては、変換モジュール２４１５は、入力メッセージのフォーマッティング実装を決定するために、変換モジュール２４１５がインタフェースするように構成されている各装置で使用されている実装を格納したデータベースを参照する。

【0268】

特定実施形態では、出力メッセージに必要なフォーマッティング実装の決定は、入力メッセージから決定することも可能である。たとえば、入力メッセージは、意図された受信側のアプリケーション、設備、システム、装置、および／または宛先を識別するフィールドを含むことが可能である。あるいは、入力メッセージは、送信されたメッセージのタイプ（たとえば、ＡＤＴメッセージ）を識別するフィールドを含むことが可能であり、変換モジュール２４１５は、送信されたメッセージのタイプおよび／または送信側のアプリケーション、装置、またはシステムから、しかるべき受信側を決定することが可能である。そして、変換モジュール２４１５は、入力メッセージの意図された受信側にとって必要なフォーマッティング実装を決定することが可能である。

【0269】

判断ブロック２６０５では、変換モジュール２４１５は、ルールセットが、入力メッセージの識別されたフォーマッティング実装から、出力メッセージに使用する識別されたフォーマッティング実装への変換用として構成されているかどうかを判定する。このルールセットは、変換モジュールソフトウェアのインストール前に手動で構成されていてもよく、入力メッセージの受信前に自動的に構成されていてもよい。ルールセットが既に構成されている場合、変換プロセス２６００は、ブロック２６０６に進む。ルールセットが構成されていない場合は、ブロック２６０７でルールセットを構成する。ルールセットは、図２８および図２９Ａ～２９Ｄに関して後述するように構成可能である。次に変換プロセス２６００は、ブロック２６０８に進む。

【0270】

ブロック２６０６では、変換モジュール２４１５は、変換ルールセット２４２０から、入力メッセージの決定済みフォーマッティング実装と出力メッセージのフォーマッティング実装との間の変換を制御する事前構成済みルールを識別する。実施形態によっては、事前構成済みルールの識別は、手動で行うことが可能である。

【0271】

ブロック２６０８では、変換モジュール２４１５は、変換ルール２４２０の１つ以上の構成済みルールセットに基づいて出力メッセージを生成する。特定実施形態では、出力メッセージは、入力メッセージの内容のすべて（または少なくとも一部分）を保持しているが、そのフォーマットは、入力メッセージの意図された受信側によって予期およびサポートされるフォーマットである。

【0272】

変換ルール２４２０は、たとえば、単方向ルールおよび／または双方向ルールを含むことが可能である。単方向ルールは、たとえば、第１の医療装置（たとえば、２４０５）から第２の医療装置（たとえば、２４１０）へのメッセージの場合には適用可能であるが、第２の医療装置から第１の医療装置へのメッセージの場合には適用されないルールである。たとえば、単方向ルールは、（たとえば、ＨＬ７通信プロトコルの）異なる２つのフォーマッティング実装の、フィールド間に使用されている区切り記号の差異に対処することが可能である。変換モジュール２４１５は、フィールド区切り記号が入力メッセージの意図された受信側によってサポートされているかどうかを判定するために、フィールド区切り記号ルールを適用することが可能である。入力メッセージのフィールド区切り記号が、意図された受信側によってサポートされていない場合、フィールド区切り記号ルールは、入力メッセージのフィールド区切り記号を、意図された受信側によってサポートされているフィールド区切り記号に置き換えることが可能である。

【0273】

たとえば、入力側医療装置からの入力メッセージに、フィールド区切り記号または分離記号として「カレット」記号（「＾」）を使用するフォーマッティング実装が含まれる場合がある。これに対し、意図された受信側医療装置によって認識されるフォーマッティング実装では、フィールド区切り記号として「パイプ」記号（「｜」）を使用している場合がある。変換モジュール２４１５は、意図された受信側医療装置によって認識されるフォーマッティング実装に使用されるフィールド区切り記号を変換ルールセット２４２０から識別し、入力メッセージに基づく出力メッセージであって、入力メッセージで使用されている「カレット」フィールド区切り記号の代わりに「パイプ」フィールド区切り記号を使用する出力メッセージを生成することが可能である。この場合、カレット記号をパイプ記号に置き換えるルールは、パイプ記号をフィールド区切り記号として認識する受信側装置に送信されるメッセージにのみ適用される。このルールは、カレット記号をフィールド区切り記号として認識することがわかっている受信側装置に宛てられたメッセージの場合にはパイプ記号をカレット記号に置き換えることを指示する補足ルールを伴うことが可能である。

【0274】

別の単方向ルールは、異なるフォーマッティング実装の間での特定フィールドの有無に対処することが可能である。たとえば、入力側医療装置からの入力メッセージが、意図された受信側医療装置によって認識されないフィールドを含む場合がある。変換モジュール２４１５は、この認識されない（またはサポートされない）フィールドを含まない出力メッセージを生成することが可能である。意図された受信側医療装置が予期するフィールドを入力メッセージが含まない場合には、変換ルールセット２４２０は、意図された受信側医療装置が予期するフィールドにヌルエントリまたは空白「」文字列を挿入するルール、および／または、予期されたフィールドの欠落を受信側装置にアラートするルールを含むことが可能である。また、変換モジュール２４１５は、受信側装置がメッセージの特定部分をサポートしていないことを送信側装置に通知することも可能である。

【0275】

他の単方向ルールは、たとえば、あるデータ型を別のデータ型に（たとえば、文字列（「ＳＴ」）をテキストデータ（「ＴＸ」）に、あるいは構造化数値（「ＳＮ」）を数値（「ＮＭ」）に）変換すること、ならびに、メッセージの様々な部分の長さを増減することを容易にすることが可能である。また、単方向ルールは、メッセージの各部分の繰り返しが一様でないことに対処することが可能である。たとえば、変換モジュール２４１５は、メッセージのセグメント、フィールド、コンポーネント、またはサブコンポーネントの繰り返しインスタンスにフィールド繰り返しルールを適用して、そのような繰り返しインスタンスが受信側装置によっていくつサポートされているかを確定し、サポートされていれば、必要に応じていくつかの繰り返しインスタンスを削除したり追加したりすることが可能である。たとえば、患者識別セグメントの電話番号フィールドは、自宅、勤務先、および携帯電話の番号を入力できるように、繰り返し可能フィールドであってよい。

【0276】

双方向ルールも使用可能である。双方向ルールは、どの装置が送信側で、どの装置が受信側かに関係なく、第１および第２の医療装置（たとえば、２４０５、２４１０）の間のメッセージに一様に適用可能である。双方向ルールは、たとえば、シーケンスの変化に対処することが可能である。特定の実装では、入力側医療装置からの入力メッセージは、患者名フィールドを１つ以上含むことが可能であるが、この場合、ファーストネームコンポーネントがラストネームコンポーネントの前に表示される。これに対し、意図された受信側医療装置は、ラストネームコンポーネントがファーストネームコンポーネントの前に表示される実装を予期している可能性がある。したがって、変換ルールセット２４２０は、２つの医療装置の間、または２つのフォーマッティング実装の間での通信時に、ファーストネームコンポーネントとラストネームコンポーネントの順序を入れ替える双方向ルールを含むことが可能である。一般に、フィールド、コンポーネント、またはサブコンポーネントの順序が、意図された受信側にとって正しいかどうかを判定し、必要に応じてそれらを再配列するフィールド順序ルールを適用することが可能である。また、たとえば、フォーマッティング実装間の他の順序のばらつきや他のタイプのばらつきがある場合に、これらに対処するために、別の双方向ルールを含めることも可能である。

【0277】

変換ルール２４２０は、複合ルールを含んでもよい。たとえば、複合ルールは、複数のルールのｉｆ－ｔｈｅｎシーケンスを含むことが可能であり、あるルールは別のルールの結果に依存することが可能である。変換ルール２４２０によっては、計算および論理（たとえば、ブール論理またはファジー論理）、その他を使用することも可能である。

【0278】

上述のように、病院ベースの通信ネットワークを経由して伝達されるメッセージは、ＨＬ７プロトコルを使用することが可能である。図２７Ａおよび２７Ｂは、病院ベースの通信ネットワークまたは臨床ネットワークを経由してＨＩＳと医療装置との間でＨＬ７メッセージを伝達する変換プロセス２７００Ａ、２７００Ｂを示す。変換プロセス２７００Ａ、２７００Ｂについては、第１および第２のＨＬ７フォーマット間の「変換」を制御するルールが既に構成済みであるという前提で説明する。

【0279】

図２７Ａに示した変換プロセス２７００Ａでは、変換モジュール２４１５は、第１のＨＬ７フォーマットを有するＨＩＳから、第２のＨＬ７フォーマットを有する、意図された受信側医療装置（たとえば、患者監視器または臨床担当者詰所監視システム）へのＨＬ７メッセージ（たとえば、図２５ＡのＡＤＴメッセージ）の伝達を促進する。

【0280】

変換プロセス２７００Ａでは、まず、ブロック２７０１で、変換モジュール２４１５が、第１のＨＬ７フォーマットを有する入力メッセージをＨＩＳから受信する。特定実施形態では、入力メッセージは、たとえば、患者の入院および／または患者の識別に関する情報や、電子医療記録データベースにある、患者の医療履歴情報を含んでいる。

【0281】

ブロック２７０３では、変換モジュール２４１５は、入力メッセージのフォーマッティング実装と、出力メッセージに用いるフォーマッティング実装とを決定する。これらの決定は、図２６のブロック２６０４に関して上述した決定と同様に行うことが可能である。

【0282】

ブロック２７０５では、変換モジュール２４１５は、入力メッセージの決定済みＨＬ７フォーマットと出力メッセージのＨＬ７フォーマットとの間の変換を制御するルールを識別し、識別したルールに基づいて、第２のＨＬ７フォーマットを有する出力メッセージを生成する。特定実施形態では、出力メッセージは、ＨＩＳから送信された入力メッセージの内容は保持するものの、そのフォーマットは、入力メッセージの意図された受信側によって予期およびサポートされているフォーマットである。

【0283】

ブロック２７０７では、変換モジュール２４１５は、病院ベースの通信ネットワークを経由して、出力メッセージを、意図された受信側に出力することが可能である。特定実施形態では、意図された受信側は、病院情報システムに確認応答メッセージを返送することにより、正常受信の確認応答を行うか、エラーが発生したことを報告することが可能である。

【0284】

図２７Ｂに示した変換プロセス２７００Ｂでは、変換モジュール２４１５は、第１のＨＬ７フォーマットを有する医療装置（たとえば、患者監視器）から、第２のＨＬ７フォーマットを有するＨＩＳへのＨＬ７メッセージの伝達を促進する。たとえば、患者監視器は、報告イベントデータｍ（たとえば、患者アラームデータ）をＨＩＳに送信して、患者の電子医療記録に格納することが可能である。

【0285】

変換プロセス２７００Ｂでは、まず、ブロック２７０２で、変換モジュール２４１５が、第１のＨＬ７フォーマットを有する入力メッセージを医療装置から受信する。特定実施形態では、入力メッセージは、ＨＩＳに関連付けられた電子医療記録データベースに記録するための、監視対象患者の１つ以上の生理学的パラメータに関する患者監視データまたはアラームデータを含む。

【0286】

ブロック２７０４では、変換モジュール２４１５は、入力メッセージのフォーマッティング実装と、出力メッセージに用いるフォーマッティング実装とを決定する。これらの決定は、図２６のブロック２６０４に関して上述した決定と同様に行うことが可能である。

【0287】

ブロック２７０６では、変換モジュール２４１５は、入力メッセージの決定済みＨＬ７フォーマットと出力メッセージのＨＬ７フォーマットとの間の変換を制御するルールを識別し、識別したルールに基づいて、第２のＨＬ７フォーマットを有する出力メッセージを生成する。特定実施形態では、出力メッセージは、医療装置から送信された入力メッセージの内容は保持するものの、そのフォーマットは、ＨＩＳによって予期およびサポートされているフォーマットである。

【0288】

ブロック２７０８では、変換モジュール２４１５は、病院ベースの通信ネットワークを経由して、出力メッセージを、病院情報システムに出力することが可能である。特定実施形態では、ＨＩＳは、医療装置に確認応答メッセージを返送することにより、正常受信の確認応答を行うか、エラーが発生したことを報告することが可能である。

【0289】

図２６、図２７Ａ、および図２７Ｂでは、変換モジュール２４１５の動作について説明した。図２８および図２９Ａ～２９Ｄでは、変換ルール２４２０の構成の記述について説明する。

【0290】

変換ルール２４２０は、１つ以上のスタイルシート、履歴関係データ構造体、表、リスト、他のデータ構造体、これらの組み合わせなどとして実装可能である。特定実施形態では、変換ルール２４２０は、変換モジュール２４１５内のローカルメモリに格納可能である。他の実施形態では、変換ルール２４２０は、変換モジュール２４１５と通信可能に結合された外部メモリまたはデータ記憶装置に格納可能である。

【0291】

変換モジュール２４１５は、単一のルールセット、または複数のルールセットを含むことが可能である。たとえば、変換モジュール２４１５は、医療装置／システムごとに、かつ／または、ネットワークと結合された（またはネットワークと結合可能な）、通信し合う可能性がある医療装置／システムのペアごとに、別々のルールセットを含むことが可能である。実施形態によっては、変換モジュール２４１５は、（たとえば、ＨＬ７プロトコルのような）医療通信プロトコルの下で許可されるフォーマッティング実装の、可能なペアごとに、別々のルールセットを含むことが可能である。

【0292】

特定実施形態では、変換ルール２４２０は、たとえば、図２８に示すメッセージング実装ソフトウェアツール２８００を用いて手動で入力することが可能である。たとえば、特定の病院ネットワークに関わるソフトウェア開発者は、病院ネットワークと結合されている（または、結合される可能性がある）装置および／またはシステムで使用されるプロトコルメッセージフォーマットを調査し、それらの装置および／またはシステムでサポートまたは認識される様々なプロトコルメッセージフォーマットの間の「変換」を促進するルールを手動で入力することが可能である。

【0293】

図２８は、変換モジュール２４１５で使用する変換ルール２４２０を手動で構成するメッセージング実装ソフトウェアツール２８００からの画面ショットの例を示す。この、メッセージング実装ソフトウェアツール２８００からの画面ショットは、電子医療通信プロトコル（たとえば、ＨＬ７）のフォーマッティング実装間で異なる可能性がある様々なパラメータを示している。この画面ショットはまた、異なるＨＬ７実装間での変換に関する変換ルールを定義する（または、定義するために用いられる）情報をユーザが入力できる領域を含んでいる。実施形態によっては、メッセージング実装ソフトウェアツール２８００は、たとえば、様々な医療装置の既知の通信プロトコル実装に基づいて事前構成された様々なルールセットを格納する。そのような実施形態では、ユーザは、装置の製造元、型番などのような識別情報を入力することにより、そのような装置を使用する通信に用いる１つ以上の変換ルール２４２０を構成することが可能である。メッセージング実装ツール２８００は、この識別情報に基づいて、当該装置との通信に用いる、事前構成された変換ルールセットを識別することが可能である。

【0294】

他の実施形態では、変換ルール２４２０は、自動生成が可能である。たとえば、新しいルールセット（または複数のルールセット）の自動生成は、ネットワーク上で新たに認識された「通信する」医療装置またはシステムの検出によってトリガされることが可能である。特定実施形態では、新しいルールセットまたは複数のルールセットの自動生成は、ネットワークと結合された新しい「通信する」医療装置またはシステムから第１のメッセージを受信した時点（またはその医療装置またはシステムに第１のメッセージを送信した時点）で行うことが可能である。さらに別の実施形態では、ルールセットの自動生成は、既存のルールセットを更新または動的に修正することを含む。

【0295】

変換ルールセットの自動生成は、様々な方法で実行可能である。たとえば、実施形態によっては、変換モジュール２４１５は、変換ルール２４２０の事前構成されたセットの使用を、たとえば、ネットワーク上で認識された新しい装置の製造元および型式に基づいて自動的に開始することが可能である。特定実施形態では、図２９Ａの自動ルール構成プロセス２９００Ａで示すように、変換モジュール２４１５は、新しい装置またはシステムに１つ以上のメッセージを要求し、それらのメッセージを解析して、実装するフォーマッティングのタイプを決定することが可能である。自動ルール構成プロセス２９００Ａでは、まず、ブロック２９０１で、変換モジュール２４１５が、ネットワーク上で検出された医療装置またはシステムから１つ以上のメッセージを受信する。これらのメッセージは、意図された受信側医療装置またはシステムに向けての送信時に、または、変換モジュール２４１５またはネットワークに結合された別の医療装置またはシステムから送信された問合せに対する応答として、受信可能である。

【0296】

ブロック２９０３では、変換モジュール２４１５は、１つ以上の受信メッセージのプロトコルを決定する。これは、たとえば、これらのメッセージを解析すること、またはネットワーク上の各医療装置またはシステムによってどのような通信プロトコル／フォーマットが実装されているかを示すデータベースに照会することにより行う。特定実施形態では、変換モジュール２４１５は、単一の共通プロトコル（たとえば、ＨＬ７）を用いて実装されている医療メッセージを処理するように構成されている。したがって、受信メッセージが、サポートされていない（または、認識されていない）プロトコルを用いて実装されていると判定した場合、変換モジュールは、検出された医療装置またはシステムから受信したメッセージを無視するか、アラートまたは警告を出力するか、メッセージを変換せずに送信することを許可することが可能である。

【0297】

ブロック２９０５では、変換モジュール２４１５は、１つ以上の受信メッセージのフォーマッティング実装を決定する。特定実施形態では、受信メッセージは、フォーマッティング実装を表す１つ以上の識別子を含むことが可能である。他の実施形態では、フォーマッティング実装の決定は、たとえば、フィールド順序、使用されている区切り文字またはエンコード文字、または他の実装のばらつきをチェックすることにより、メッセージ自体を解析して行うことが可能である。特定実施形態では、変換モジュール２４１５は、フォーマッティング実装の決定を支援するために、メッセージの内容からフォーマッティングを分離または解析することが可能である。

【0298】

ブロック２９０７では、変換モジュール２４１５は、検出された医療装置またはシステムから受信したメッセージおよび／またはこれらの医療装置またはシステムに送信したメッセージを処理する１つ以上のルールまたはルールセットを構成する。特定実施形態では、ルールを構成することは、新しいルールを作成または生成することを伴う。他の実施形態では、ルールを構成することは、既存のルールを変更または更新することを伴う。構成されたルールまたはルールセットは、変換ルール２４２０に含めることが可能である。新しい装置またはシステムで使用されているフォーマッティング実装に対するルールセットが既に存在する場合、新しい変換ルールを構成することは必須でなくてよい。その代わりに、既存の変換ルールをその新しい装置またはシステムに関連付けて、その装置またはシステムを関与させる通信に用いることが可能である。他の実施形態では、変換モジュール２４１５は、新しい装置またはシステムに特化された新しいルールセットを作成することが可能であり、あるいは、識別されたフォーマッティングの微小な差異に基づいて既存のルールセットを修正することが可能である。

【0299】

他の実施形態では、変換モジュール２４１５は、装置またはシステムで使用されている通信プロトコルおよび実装の識別に有用である可能性がある１つ以上のテストメッセージを生成することが可能である。たとえば、変換モジュールは、新しく検出された装置またはシステムに特定のアクション（たとえば、情報を格納すること）を行わせるテストメッセージを生成し、その、新しく検出された装置によって行われたアクションに関する情報を問い合わせて、そのテストメッセージが理解されたかどうか、あるいはどのように理解されたかを調べることが可能である。これを、図２９Ｂの自動ルール構成プロセス２９００Ｂで説明する。

【0300】

自動ルール構成プロセス２９００Ｂでは、まず、ブロック２９０２で、変換モジュール２４１５が、１つ以上のテスト（または初期化）メッセージを、ネットワーク上で検出されたリモート装置またはシステムに送信する。テストメッセージは、たとえば、リモート装置またはシステムに対し、特定のアクション（たとえば、患者情報を格納すること）を行うことを指示するように構成可能である。特定実施形態では、テストメッセージは、リモート装置またはシステムによって認識またはサポートされているフォーマッティングのタイプを表す応答を生成するように構成可能である。他の実施形態では、テストメッセージは、特定のフォーマッティング実装をサポートしている装置またはシステムだけがテストメッセージを理解して、テストメッセージに正しく従うように構成可能である。

【0301】

ブロック２９０４では、変換モジュール２４１５は、リモート装置またはシステムに照会して、リモート装置またはシステムに送信されたテストメッセージに基づいて行われたアクションに関する情報を受信し、テストメッセージが理解されたかどうかを判定する。たとえば、テストメッセージが、リモート装置またはシステムに対し、患者情報を特定の場所に格納することを指示した場合、変換モジュール２４１５は、その場所からの情報を問い合わせることにより、テストメッセージが理解されたかどうかを判定することが可能である。テストメッセージが理解されなかった場合、変換モジュール２４１５は、たとえば、テストメッセージが理解されたと判定されるまで、既知のフォーマッティング実装のテストメッセージの送信を続けることが可能である。

【0302】

ブロック２９０６では、変換モジュール２４１５は、受信した情報に基づいて、プロトコルおよびフォーマッティング実装を決定する。一例として、特定実施形態では、テストメッセージは、患者名情報を格納する指示を含むことが可能である。テストメッセージは、ファーストネームコンポーネントの後にラストネームコンポーネントがある患者名フィールドを含むことが可能である。そして、変換モジュール２４１５は、患者のラストネームを返すようにリモート装置またはシステムに問い合わせることが可能である。この問合せは、患者のラストネームが返されるか、ファーストネームが返されるかに応じて、リモート装置またはシステムで使用されているフォーマッティング実装におけるフィールドの順序に関する情報を決定することに役立つことが可能である。別の例として、テストメッセージは、検出された装置またはシステムに対し、コンポーネントの繰り返しインスタンスを格納することを指示することが可能である。そして、変換モジュール２４１５は、繰り返しインスタンスを返すように装置またはシステムに問い合わせて、もしあれば、どのインスタンスが格納されていたかを知ることが可能である。この繰り返し性情報によれば、リモート装置またはシステムで使用されているフォーマッティング実装において特定のフィールドの繰り返しが許可されているかどうか、ならびに、許可されていれば、いくつの繰り返しインスタンスが許可されているか、を知ることも可能である。

【0303】

ブロック２９０８では、変換モジュール２４１５は、検出された医療装置またはシステムから受信したメッセージおよび／またはこれらの医療装置またはシステムに送信したメッセージを処理する１つ以上のルールを構成する。たとえば、このルールは、本明細書に記載のように、第１の医療装置で使用されているメッセージフォーマットから、第２の医療装置で使用されているメッセージフォーマットに、メッセージを変換することが可能である。特定実施形態では、ルールを構成することは、新しいルールを作成または生成することを伴う。他の実施形態では、ルールを構成することは、既存のルールを変更または更新することを伴う。新しい装置またはシステムで使用されているフォーマッティング実装に対するルールセットが既に存在する場合、新しい変換ルールを構成することは必須でなくてよい。その代わりに、既存の変換ルールをその新しい装置またはシステムに関連付けて、その装置またはシステムを関与させる通信に用いることが可能である。

【0304】

図２９Ｃおよび図２９Ｄは、ＨＬ７プロトコルを利用するメッセージに対して、変換モジュール２４１５によって実行される自動ルール構成プロセスを示す。ＨＬ７プロトコルは、たとえば、管理、物流、財務、および臨床の各プロセスをサポートするために電子メッセージを伝達することに使用可能である。たとえば、ＨＬ７メッセージは、患者のデモグラフィ情報および診察情報を様々な医療システムの間で交換するために使用される患者管理メッセージ（たとえば、ＡＤＴメッセージ）を含むことが可能である。

【0305】

図２９Ｃに示した自動ルール構成プロセス２９００Ｃは、図２９Ａに示したプロセス２９００Ａと同様である。ブロック２９１１では、変換モジュール２４１５は、ＨＬ７医療装置から１つ以上のメッセージを受信する。ブロック２９１５では、変換モジュール２４１５は、受信した１つ以上のメッセージから、そのＨＬ７医療装置のフォーマッティング実装を決定する。上述のように、フォーマッティング実装の決定は、たとえば、フィールドの順序またはシーケンス、フィールド区切り文字、繰り返し性、カージナル数、および他のＨＬ７実装のばらつきをチェックすることにより、行うことが可能である。

【0306】

ブロック２９１７では、変換モジュール２４１５は、ＨＬ７医療装置から受信したメッセージおよび／またはＨＬ７医療装置に送信したメッセージを処理する１つ以上のルールを構成する。特定実施形態では、ルールを構成することは、検出されたフォーマッティング実装に関する新しいルールを作成または生成することを伴う。他の実施形態では、ルールを構成することは、既存のルールを動的に変更または更新することを伴う。新しいＨＬ７医療装置で使用されているフォーマッティング実装に対するルールセットが既に存在する場合、新しい変換ルールを構成することは必須でなくてよい。その代わりに、既存の変換ルールをその新しいＨＬ７医療装置に関連付けて、その装置を関与させる通信に用いることが可能である。

【0307】

図２９Ｄに示した自動ルール構成プロセス２９００Ｄは、図２９Ｂに示したプロセス２９００Ｂと同様である。ブロック２９１２では、変換モジュール２４１５は、１つ以上のテスト（またはダミー、または初期化）メッセージをＨＬ７医療装置に送信する。他の実施形態では、変換モジュール２４１５は、１つ以上のテストメッセージを別のＨＬ７医療装置から新しいＨＬ７医療装置に送信させることが可能である。上述のように、テストメッセージは、既知のＨＬ７フォーマットを含んで、ＨＬ装置がテストメッセージを理解するかどうかを調べるように構成されたメッセージを含むことが可能である。テストメッセージは、たとえば、テストＡＤＴメッセージを含むことが可能である。

【0308】

ブロック２９１４では、変換モジュール２４１５は、ＨＬ医療装置に問い合わせて、テストメッセージに対する応答として行われたアクションに関する情報または格納された情報を受信する。ブロック２９１６では、変換モジュール２４１５は、受信した情報に基づいて、そのＨＬ７装置のフォーマッティング実装を決定する。特定実施形態では、変換モジュール２４１５は、受信した情報を解析して、１つ以上のテストメッセージが正しく理解されたかどうかを判定することが可能である。正しく理解されたテストメッセージがなかった場合、変換モジュール２４１５は、他の既知のＨＬ７フォーマットを有する追加テストメッセージを送信し、ブロック２９１４および２９１６を繰り返すことが可能である。

【0309】

ブロック２９１８では、変換モジュール２４１５は、検出されたＨＬ７医療装置から受信したメッセージおよび／または検出されたＨＬ７医療装置に送信したメッセージを処理する１つ以上の変換ルールを構成する。特定実施形態では、変換ルールを構成することは、新しい変換ルールを作成または生成することを伴う。他の実施形態では、ルールを構成することは、既存のルールを変更または更新することを伴う。新しいＨＬ７医療装置で使用されているフォーマッティング実装に対する変換ルールセットが既に存在する場合、新しい変換ルールを構成することは必須でなくてよい。その代わりに、既存の変換ルールをその新しいＨＬ７医療装置に関連付けて、そのＨＬ７医療装置を関与させる通信に用いることが可能である。

【0310】

上述の自動ルール構成プロセスは、変換モジュール２４１５によるネットワーク装置またはシステムの検出によってトリガすることが可能である。図２９Ａ～２９Ｄで参照した医療装置は、図２に示し、かつ上述した装置またはシステムのいずれを含んでもよい。

【0311】

実施形態によっては、変換ルールの自動生成は、変換モジュール２４１５を含むメッセージングサブシステムソフトウェアのインストール後およびコンパイル後に有利に行うことが可能である。特定実施形態では、変換ルール２４２０の自動生成または動的修正は、変換モジュールソフトウェアを再コンパイルまたは再ビルドすることを必要とせずに行うことが可能である。この特徴は、医療環境で使用されるソフトウェアの妥当性検査に関するＵ．Ｓ．Ｆｏｏｄ ａｎｄ Ｄｒｕｇ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ（「ＦＤＡ」）の要件に効率よく準拠することに関して、有利となることが可能である。

【0312】

たとえば、ある医療装置メーカーが、変換モジュール２４１５を用いて、病院または他の患者治療施設に設置しようとする特定の医療装置またはシステム（たとえば、本明細書に記載の患者監視システム）と、病院に既に設置されている他の装置またはシステム（たとえば、ＨＩＳまたはＣＩＳ）との間の通信を促進することを計画している状況を考える。設置する新しい医療装置の動作に必要な任意のソフトウェアについて、（たとえば、病院にある他の既存の装置またはシステムのＨＬ７実装が不明のままであるとしても）病院でインストールする前に、ＦＤＡ準拠に関する妥当性検査を少なくとも部分的に行うことが可能である。たとえば、新しい医療装置のためのソフトウェアの、病院にある他の装置からメッセージを受信することに依存する任意の側面について、インストール前の妥当性検査で、予定されたメッセージフォーマットが受信されれば、完全かつ正常に動作可能であることを確認することが可能である。そして、新しい医療装置を病院に設置した時点で、変換モジュール２４１５が、予定されたフォーマットのメッセージを、新しく設置された装置に送信することが可能であることを示すことにより、ソフトウェアの妥当性検査を完了することが可能である。このようにして、ＦＤＡ妥当性検査作業は、かなりの部分をインストール前の時間枠で行うことが可能である。インストール前であれば、作業は、現場で行うよりも制御されたかたちで、より容易に行うことが可能である。

【0313】

さらに、たとえば、医療装置またはシステムを別々の病院に設置することを予定していて、それぞれの病院の既存の装置が、たとえば、ＨＬ７プロトコルの別々の実装を使用している場合には、変換モジュール２４１５は、ＦＤＡ妥当性検査を合理化することに一層役立つことが可能である。通常は、こうした状況であれば、それぞれの病院において、新しい医療装置のためのソフトウェアの全機能性について、妥当性を完全に確認しなければならないところである。これに対し、変換モジュール２４１５が新しい医療装置と病院の既存の装置との間をインタフェースする場合には、先ほど説明したように、ソフトウェアの機能性のかなりの部分は、インストール前の１回の検査で妥当性を確認することが可能である。そして、各病院に設置した時点で、正しいメッセージフォーマットが変換モジュールから受信されることを確認することにより、医療装置のソフトウェア妥当性検査を完了することが可能である（変換モジュールの変換ルールは、現場でのカスタマイズが可能である）。この結果、現場での妥当性検査手順の効率を大幅に向上させることが可能になり、これによって、より効率的なＦＤＡ準拠作業が有利に可能になり、現場でのカスタマイズが可能な変換ルールの使用によって、救命医療技術をより迅速に患者に導入することが可能になる。患者監視報告

【0314】

本明細書では、血液酸素飽和度、脈拍数、血圧、および他の多くの生理学的パラメータを監視する装置および方法について説明している。そのような医療監視装置は、多くの場合、アラーム限界を設けてプログラムされている。アラーム限界は、ある特定の生理学的パラメータの値が、たとえば、安全または健康と見なされる値の範囲から逸脱した場合に、これを自動的に検出するためのものである。実施形態によっては、そのようなアラーム状態が検出された場合に、様々なアクションを行わせることが可能である。たとえば、ベッドサイド医療監視器が、可聴または可視のアラームを発することが可能である。さらに、場合によっては、ある設定された長さの時間（たとえば、５秒）にわたってアラーム状態が持続した後に、アラーム状態を、たとえば、本明細書に記載したように、中央患者監視装置に表示することが可能である。さらに、アラーム状態が、ある設定された長さの時間（たとえば、１０秒）にわたってさらに持続すると、アラーム状態になっている患者の治療を割り当てられている臨床担当者に、たとえば、ページャまたは他の通知装置で通知することが可能である。

【0315】

検出されるアラーム状態の数は、もちろん、アラーム状態を示すアラーム条件の設定によって変わる。実施形態によっては、そのようなアラーム条件は、閾値を含むことが可能であり、閾値は、安全または正常と見なされる生理学的パラメータの値と、臨床担当者が対応すべき医療状態を示していると見なされる生理学的パラメータの値との境界を示すことが可能である。そのようなアラーム閾値の設定が、通常の状況での健康な人々における当該生理学的パラメータの一般的な値に近いほど、検出されるアラームイベントの数が多くなることが予想される。一般的には、アラーム条件を満たす値が、所与の生理学的パラメータの正常とされる範囲の値に近いほど、患者が何らかのタイプの医療介入（たとえば、薬の投与、ＣＰＲ、人工呼吸など）を必要としていることを示す、通常範囲の値からの逸脱を検出する可能性は高くなる。このことは、患者に医療的苦痛があってもアラームがトリガされないこと（これは偽陰性ということになる）の可能性が低くなることから、望ましいことであると言えよう。

【0316】

しかしながら、偽陰性の低減にはコストがかかる。すなわち、偽陰性の低減に成功する、生理学的パラメータのアラーム条件は、偽陽性の割合を増やす可能性もある。偽陽性は、患者に何ら臨床的に顕著な医療的苦痛がない場合でもアラーム状態が検出される状態を指す。偽陽性があまりに頻発すると、臨床担当者にとっては耐え難い負担になる可能性がある。臨床担当者は、アラーム状態を精査すること、監視装置をアラーム状態からリセットすることなどを行わなければならないからである。さらに、偽陽性が頻発すると、臨床担当者にとってのアラームイベントの重要性が、意識的であれ、無意識的であれ、薄れることによって、患者がリスクにさらされることになる可能性もある。したがって、医療監視アプリケーションのアラーム条件は、偽陽性のアラームイベントを過度に増やすことなく、偽陰性をまずまずの割合に抑える、申し分ないバランスを達成するように決定することが望ましい。場合によっては、偽陰性よりは偽陽性のほうがまだ好ましいことがある。特に、偽陰性の結果が患者にとって深刻なものになる状況においてはそうである。そのように、偽陰性の発生を比較的低い割合に保つことが好ましいことを、アラーム限界条件の選択に反映させることが可能である。しかしながら、偽陽性が常に偽陰性より好ましいわけでは必ずしもない。さらに、あるタイプの患者にとって申し分ないアラーム条件が、別のタイプの患者にとっては不十分である場合もある。偽陽性と偽陰性との間の適切なバランスは、医療監視アプリケーションごとに異なる可能性がある。

【0317】

たとえば、血液酸素飽和度の監視の場合、健康な人の典型的なＳｐＯ_２値は、９５～１００％の範囲に収まるであろう。したがって、患者監視装置を、ＳｐＯ_２アラーム閾値を９４％として構成した場合、偽陽性アラームイベントの数は、比較的多くなる可能性がある。これに対し、ＳｐＯ_２アラーム閾値を９２％に設定すると、偽陽性の数は減る可能性が高いが、偽陰性の数が、医療監視アプリケーションによっては、申し分ないレベルを超えて増える可能性がある。したがって、偽陰性を申し分ないレベル以下に保ちながら偽陽性を減らすようなアラーム閾値の選択を支援するデータを与える装置および方法が、非常に有用であろう。そのような装置および方法を用いることにより、広く様々な生理学的パラメータについてアラーム条件を確立することが可能である。

【0318】

図３０は、所与の生理学的パラメータの場合の、アラーム限界値に対するアラームイベントの分布のグラフ例３０００である。グラフ３０００は、様々なアラーム限界値に対して、検出されたアラーム状態の数をプロットしたものである。グラフ３０００は、たとえば、広く様々なアラーム限界値を用いて、統計的に有意な長さの時間にわたって、統計的に有意な数の特定タイプの患者（たとえば、心臓病の患者）から生理学的パラメータアラームデータを収集したという仮定的状況を反映している。もちろん、アラーム限界値の関数としてのアラームイベントの分布は、一般には、生理学的パラメータごとに異なる。

【0319】

グラフ３０００は、ｘ軸に、直線的に増加する一連のアラーム限界値を示している。ｙ軸には、各アラーム限界値に対応する、検出されたアラーム状態の数をプロットしている。図示したように、この特定の生理学的パラメータの場合、検出されたアラーム状態の数は、おおむね、アラーム限界値が増加するに従って減少している。グラフ３０００の各棒は、たとえば、偽陽性アラームイベントと正しく検出されたアラームイベント（たとえば、患者が本当に医療的支援を求めていた場合のアラームイベントの検出）とを合わせたものを表している。

【0320】

縦の破線３００２は、１つの可能なアラーム限界閾値を表している。たとえば、生理学的パラメータ値が、縦の破線３００２で示された閾値を上回ると、アラーム状態が検出され、生理学的パラメータ値がこの閾値を下回ると、アラーム状態が検出されない。縦の破線３００４は、別の可能なアラーム限界値を表している。

【0321】

グラフ３０００に示すように、図示されたアラーム限界値３００２、３００４の間には、ｘ軸上に値が２つしかない。しかしながら、図示された２つのアラーム閾値３００２、３００４のそれぞれを用いて検出されたアラームの数は、第１のアラーム閾値３００２から第２のアラーム閾値３００４にかけて、ほぼ半減している。したがって、この場合、アラーム閾値の数は、アラーム限界値の変化に対して非直線的に関連している。このことは、場合によっては、病院または他の患者治療施設が、生理学的パラメータの監視に用いるアラーム条件を比較的小さく変化させるだけで、検出されるアラームおよび偽陽性の数に、まったく異なる影響を与える可能性があることを示している。場合によっては、たとえば、臨床的に有意な偽陰性のリスクを必ずしも増やすことなく偽陽性の数を減らすことによって、検出されるアラームの数を大幅に減らすことができるであろう。しかしながら、アラーム条件（たとえば、アラーム閾値）に対する比較的小さな調節で偽陽性の数を大きく変化させることができなかったとしても、本明細書に記載の方法は、状況によっては、偽陽性の数を安全に徐々に減らすことに有用であることが可能である。もちろん、患者の監視に用いるアラーム条件の変更は、軽々に行われるべきではない。一般的には、アラーム条件のいかなる変更も、病院管理者または他の責任者による承認が必要である。

【0322】

実施形態によっては、患者治療ドメインにいる患者から医療監視情報を収集する装置および／またはシステムを設ける。たとえば、この医療監視情報は、臨床的に有意な長さの時間にわたって、臨床的に有意な数の患者から収集することが可能である。実施形態によっては、患者治療ドメインは、類似タイプの患者のグループ、すなわち、医療的特性、状態、不具合点などが類似するために、アラーム状態を監視する理由も類似することが予想できる患者のグループである。たとえば、患者治療ドメインは、ある病院フロアにいる心臓病患者のグループなどからなるものであってよい。

【0323】

実施形態によっては、いくつかのベッドサイド患者監視器を用いて、患者から生理学的信号を収集する。ロー生理学的信号は、ベッドサイド患者監視器で処理することが可能である。たとえば、ベッドサイド患者監視器は、ロー信号の平均、フィルタリング、その他を実行することが可能である。ベッドサイド患者監視器はまた、生理学的パラメータの値を計算する演算を実行することが可能である。そして、ベッドサイド患者監視器は、生理学的パラメータ値（たとえば、ＳｐＯ_２、脈拍数、血圧、その他）およびその時間的動向の表示を出力することが可能である。そして、各患者についての生理学的情報（たとえば、ロー生理学的信号、処理済み生理学的信号、および／または生理学的パラメータの計算値など）を、たとえば、中央リポジトリに送信して格納することが可能である。実施形態によっては、この情報は、ネットワーク接続されたデータベース（たとえば、本明細書に記載のラウンドロビンデータベース７２２など）に格納される。実施形態によっては、中央リポジトリは、患者の医療監視情報を、ある長さの時間（たとえば、１週間、あるいは１か月など）にわたって特定のドメイン（たとえば、病棟）に格納することが可能である。

【0324】

第１のアラーム条件セットが満たされているかどうかを検出するために、監視の初期に、１つ以上のアルゴリズムをロー生理学的信号、処理済み生理学的信号、および／または生理学的パラメータの計算値に適用することが可能である。これは、たとえば、当該患者治療ドメインの各患者に対する各ベッドサイド患者監視器によって行うことが可能である。第１のアラーム条件セットは、たとえば、実時間監視機能を実行してアラーム状態を検出する患者監視装置に実装された条件である。このアラーム条件が満たされると、本明細書に記載のようにアラームを発生させることが可能である。また、中央リポジトリを用いて、アラーム状態の発生を患者ごとに記録することも可能である。

【0325】

実施形態によっては、統計的に有意な量の患者監視データが中央リポジトリに収集された時点で、報告モジュールが、中央リポジトリにアクセスし、これらのデータを用いて、患者治療ドメイン内の患者監視装置が、監視時に実際に使用したアラーム条件セットと異なるアラーム条件セットを使用したとしたら検出されたであろうアラームイベントをシミュレートすることが可能である。

【0326】

実施形態によっては、報告モジュールは、本明細書に記載の患者監視システム（たとえば、図１、２、６、７、１９などに示した患者監視システム）と併せて使用される。実施形態によっては、報告モジュールは、ベッドサイド患者監視装置、中央監視装置、データベース、および他の、患者監視システムを形成しうる装置のネットワークと通信可能に結合されたサーバまたは他のコンピューティング装置である。報告モジュールは、患者監視データを解析するプロセッサを含むことが可能である。報告モジュールは、たとえば、患者監視データを格納する電子メモリを含むことも可能である。

【0327】

実施形態によっては、中央リポジトリが、たとえば、患者ごとの生理学的パラメータ動向データを含む場合、報告モジュールは、この動向データにアクセスすることが可能であり、これを、たとえば、アラーム条件が満たされているかどうかを検出するためにベッドサイド患者監視装置で使用されていたものと同じ１つ以上のアルゴリズムを用いて再解析することが可能である。しかしながら、この場合は、アラーム状態を検出するために（たとえば、患者監視データが実際に収集されたときに、実時間で）使用されていた第１のアラーム条件とは異なる、第２のアラーム条件を使用することが可能である。実施形態によっては、報告モジュールは、格納された患者監視データを、複数の異なる新しいアラーム条件を用いて再解析する。したがって、報告モジュールは、アラーム条件の変化の関数として、検出されるアラームの数がどのように変化するかを示す情報を生成することが可能である。

【0328】

図３１は、アラーム条件の変化の結果である、識別されるアラーム状態の変化を調べる方法３１００を示すフローチャートである。方法３１００では、まず、ブロック３１０２で、患者治療ドメインにいる患者のグループから生理学的パラメータデータを収集する。たとえば、生理学的パラメータデータは、患者治療施設全体に分散配置されたいくつかの異なるベッドサイド患者監視装置によって収集可能である。収集された生理学的パラメータデータは、たとえば、監視されている生理学的パラメータと、生理学的パラメータデータを収集されている患者とに関連する任意のタイプの情報を含むことが可能である。繰り返しになるが、収集可能な生理学的パラメータデータの例として、ロー生理学的信号、処理済み生理学的信号、生理学的パラメータの計算値などがある。

【0329】

ブロック３１０４では、生理学的パラメータデータを解析して、第１のアラーム条件セットに基づいてアラーム状態を識別する。アラーム条件は、アラームをトリガする生理学的状態を修正するように構成可能であってよい。実施形態によっては、生理学的パラメータデータの解析は、（たとえば、アラーム状態をその発生時に検出するために、ベッドサイド患者監視装置によって）ほぼ実時間で実行される。アラーム条件は、一般に、監視される個々の生理学的パラメータごとに異なる。実施形態によっては、アラーム条件は、単一の閾値である。実施形態によっては、アラーム条件は、（たとえば、生理学的パラメータの安全値または正常値の閉塞範囲を規定する）複数の閾値を含む。他のタイプのアラーム条件も使用可能である。

【0330】

ブロック３１０６では、生理学的パラメータデータを、たとえば、中央リポジトリ（たとえば、ラウンドロビンデータベース７２２）に格納する。実施形態によっては、中央リポジトリは、ブロック３１０２で収集された生理学的パラメータデータのすべて（または、ほぼすべて）を格納する。たとえば、中央リポジトリは、生理学的情報を格納することが可能であり、これは、たとえば、各患者からのロー生理学的信号、あるいは、（たとえば、ベッドサイド患者監視装置によって）既にある程度まで処理または変更されている生理学的信号である。さらに、中央リポジトリは、ブロック３１０４で患者ごとに検出されたすべてのアラーム状態に関する情報を格納することが可能である。たとえば、中央リポジトリは、患者ごとの各アラーム状態のタイミングおよびタイプを格納することが可能である。

【0331】

ブロック３１０８では、既に格納されている生理学的パラメータデータを解析して、ブロック３１０４で使用した第１の条件とは異なる第２のアラーム条件に基づいてアラーム状態を識別することが可能である。この解析は、たとえば、本明細書に記載の報告モジュールによって実行可能である。たとえば、血液酸素飽和度の監視の場合、検出されたパルスオキシメトリ信号が、実際の監視時に、９４％酸素飽和度のアラーム閾値を用いて解析されたとすると、その後、ブロック３１０８で、このパルスオキシメトリ信号を、９３％酸素飽和度、または９２％酸素飽和度、その他のアラーム閾値で再解析することが可能である。このように、既に収集された生理学的パラメータデータを解析することにより、別のアラーム閾値の効果を、リスクのない方法でシミュレートすることが可能である。これは、患者が、たとえば、ブロック３１０２、３１０４で、引き続き、既に容認され、妥当性が確認されているアラーム条件で監視可能であるためである。このように、生理学的データから識別されているアラーム状態に対する、アラーム条件を変更することの効果をシミュレートできることは、病院または他の患者治療施設にとっては、アラーム条件を当該の病院または患者治療施設に個別に適応させるように調節する手段として有利である。アラーム条件を個別に適応させることは有利である。それは、ある病院において（または、あるタイプの患者に対して）良好に働くアラーム条件が、別の病院においても（または別のタイプの患者に対しても）良好に働くことが必ずしも保証されないためである。その原因として考えられるのは、使用されている監視機器のタイプが異なること、患者数が異なること、提供されている治療のタイプが異なること、臨床担当者によって実施されている医療手順が異なることなどである。

【0332】

実施形態によっては、ブロック３１０８で、収集された生理学的パラメータデータに対して報告モジュールが適用している１つ以上のアルゴリズムが、実時間でアラーム状態を検出するために監視時に適用された１つ以上のアルゴリズムと同じ（またはほぼ同等）である。ただし、このことは、すべての実施形態において必須でなくてもよい。さらに、実施形態によっては、中央リポジトリに格納されている生理学的パラメータデータは、（たとえば、データの収集時にベッドサイド患者監視器によって）アラーム検出アルゴリズムが適用された生理学的パラメータデータと同じ（またはほぼ同等）である。このようにして、様々なアラーム条件を、それらがあたかも、実時間アラーム状態を検出するための生理学的パラメータデータの収集時に実際に使用されたかのように、シミュレートすることが可能である。

【0333】

ブロック３１１０では、報告モジュールは、検出されるアラーム状態に対する、シミュレートされたアラーム条件の効果を解析することが可能である。たとえば、報告モジュールは、新しいシミュレートされたアラーム条件を用いて検出されるアラーム状態の数に変化があれば、その変化を解析することが可能である。この情報は、たとえば、患者別に、および／または患者の集合体について与えることが可能である。さらに、報告モジュールは、アラーム状態が検出されるタイミングの差を解析することが可能である。一般的には、報告モジュールは、第２のアラーム条件を使用して検出されるアラーム状態の数、タイプ、タイミング、継続時間、その他を、監視時に適用された第１のアラーム条件を使用して検出されるアラーム状態と比較して、変化があればその変化を解析することが可能である。

【0334】

ブロック３１１２では、報告モジュールは、シミュレートされたアラーム条件の効果を識別、説明、要約、または他の形式で記載した報告を出力することが可能である。この報告は、たとえば、病院管理者が、（たとえば、ベッドサイド患者監視器で使用されている）アラーム条件に対する何らかの変更が許されるかどうかを判断する上で有用であることが可能である。たとえば、本明細書に記載のように、状況によっては、アラーム条件は、検出される偽陽性の数を減らすように変更可能である。報告モジュールは、そのような変更が既に実施されていたとすればもたらされたであろう効果についての情報を提供することができるため、病院管理者が上記の判断を下す能力を高める。一般的には、病院管理者は、（たとえば、偽陰性を容認し難いほど増やすことなく偽陽性を減らすために）アラーム条件の変更を安全に行うことが可能かどうかを判断する最終責任を負う。

【0335】

図３２は、シミュレートされたアラーム条件がアラーム検出イベントに及ぼす影響を示す表３２００による報告例を示す。表３２００は、５つの異なるシミュレートされたアラーム条件についての行エントリを含んでいるが、新しいアラーム条件はいくつでもシミュレート可能である。表３２００は、シミュレートされたアラーム条件のそれぞれを用いて検出されるアラームの数についての列エントリを含んでいる。アラームの数は、たとえば、患者ごとに分類したり、生理学的パラメータデータを収集したすべての患者において検出されるアラームの総計としてリストにしたりできる。

【0336】

表３２００はまた、シミュレートされたアラーム条件のそれぞれを用いて検出されるアラームの数を、生理学的パラメータデータの収集時に適用された実際のアラーム条件を用いて検出されるアラームの数と比較した変化についての列エントリを含んでいる。この変化は、アラームの数の差、パーセント差などのように示すことが可能である。

【0337】

シミュレートされたアラーム条件の効果を報告することについては、他にも様々なタイプの情報および情報フォーマットが存在する。図３２は、シミュレートされたアラーム条件に基づいて報告モジュールが生成可能な報告の一例を示しているに過ぎない。このような報告は、病院管理者が、アラーム条件を変更すべきかどうかについての判断を下すことを支援するために、シミュレートされたアラーム条件の効果に関する広く様々な情報を含むことが可能であることを理解されたい。さらに、そのような報告は、表、チャート、グラフ、リスト、スプレッドシートなどをはじめとする広く様々なフォーマットで提示可能である。

【0338】

図３３は、アラーム条件の変化の結果として起こる、識別されるアラーム状態の変化を調べる別の方法３３００を示すフローチャートである。方法３３００は、図３１に示した方法３１００と類似しているが、方法３３００はさらに、たとえば、偽陽性アラームおよび偽陰性アラームに対する、シミュレートされたアラーム限界の予想される効果を調べることを含む。

【0339】

方法３３００は、ブロック３３０２および３３０４については、図３１に示した方法３１００およびブロック３１０２、３１０４に関して上述したように進めることが可能である。これに対し、ブロック３３０６では、方法３３００は、医療介入データを収集することをさらに含む。医療介入データは、たとえば、生理学的パラメータの監視中のいずれかの時点で患者が何らかのタイプの医療介入を必要としたかどうかの記録を含むことが可能である。そのような医療介入としては、たとえば、薬の管理、医師または看護師による対応（たとえば、臨時の対応）、即応チームによる対応、治療または処置の管理、その他がある。医療介入データはまた、たとえば、医療介入のタイプ、時刻、および継続時間、医療介入を必要とした医療的原因、アラーム検出イベントとの関係などの、医療介入に関するあらゆる関連情報を含むことも可能である。

【0340】

実施形態によっては、ブロック３３０６で収集された医療介入データを用いて、ブロック３３０４で検出されたアラーム状態の中に偽陽性アラームがあったとすれば、それはどれか、および／または、医療的苦痛の正しい徴候を表したアラームはどれだったか、などを調べる。その後、この情報を用いて、たとえば、様々なシミュレートされたアラーム条件であったなら、識別されたいずれかの偽陽性アラームが識別されなかったかどうか、あるいは、それらのシミュレートされたアラーム条件であったなら、結果として、医療介入が必要であることを実際に示していたアラームのいずれかが検出されないことがあったかどうか（たとえば、結果として偽陰性になったかどうか）、を調べることが可能である。さらに、医療介入データを用いて、偽陰性を識別すること、ならびに、シミュレートされたアラーム条件であったなら、結果として、そのような偽陰性が検出されたかどうかを判定することが可能である。この情報を解析して報告内で提示することにより、病院管理者が、患者監視装置で使用されているアラーム条件を、本明細書に記載のように、シミュレートされたアラーム条件に基づいて変更すべきかどうかの判断を下すことをさらに支援することが可能である。

【0341】

医療介入データは、様々な方法で取得可能である。たとえば、医療介入データは、医療介入が必要になったときに臨床担当者が記録できる。そして、これらの記録を手動で中央リポジトリにインポートすることが可能である。中央リポジトリは、収集された生理学的パラメータデータも格納する。医療介入データは、（たとえば、病院情報システムまたは臨床情報システムに格納されている）患者の電子医療記録から中央リポジトリに自動的にインポートすることも可能である。実施形態によっては、ベッドサイド患者監視装置は、（たとえば、アラームが無効にされた後に）医療介入データを入力することを臨床担当者を促すように構成可能である。他の、医療介入の記録を取得する方法も使用可能である。

【0342】

患者に対して行われた医療介入の記録が、たとえば、検出されたアラーム状態のタイミングと時間的に関連していれば（たとえば、医療介入の記録と検出されたアラーム状態との間隔が所定閾値未満のいくらかの時間長であれば）、この記録は、正しく検出されたアラーム状態を表していると見なすことが可能である。たとえば、検出されたアラーム状態の後、比較的短時間のうちに医療介入が行われた場合、そのアラーム状態は医療的対応を必要としていたと考えられる。一方、行われた医療介入の記録が、当該患者に関して検出されたどのアラーム状態のタイミングとも時間的に関連していない場合は、医療介入を必要とした医療状態によってアラームがトリガされなかったことから、この記録は、偽陰性を表していると考えられる。方法３３００の後半では、様々な新しいアラーム条件がシミュレートされた後、そのようなシミュレートされた条件であったなら偽陰性が検出されたかどうか、あるいは、監視時に適切に設けられていたアラーム条件によって正しく検出されたアラーム状態が、新しいシミュレートされた条件であっても検出されたかどうか、を判定することが可能である。

【0343】

実施形態によっては、医療介入データは、所与の患者に対する医療介入が行われたかどうかの自動推定を含むことが可能である。アラーム検出イベントの後に医療介入が必要とされたかどうかの推定を、（たとえば、臨床担当者がアラームイベントに対応した後に患者のところにいた時間の長さ、あるいは、検出されたアラームイベントからいくらかの制限時間以内に医師が来て患者を診察したかどうか、に基づいて）自動的に行うことが可能である。この情報は、本明細書に記載の臨床担当者近傍検出装置およびシステムを用いて収集可能である。たとえば、実施形態によっては、患者監視装置が、アラーム検出イベントの発生後にタイマを起動することが可能である。いくらかの所定時間以内に（たとえば、本明細書に記載のように、臨床担当者トークンによって識別される）医師の存在が検出された場合、その医師の来訪がアラームイベントへの対応として行われたと推定することが可能である。したがって、その医師の来訪は、医療介入であると識別することが可能である。同様に、患者監視装置が、臨床担当者（たとえば、看護師）がアラームを静音化した後に患者の近傍にいる時間の長さを追跡することが可能である。患者のところにいる時間の長さが特定閾値を超えた場合は、アラームイベントへの対応として、何らかのタイプの医療介入が必要であったと推測することが可能である。

【0344】

さらに、（たとえば、アラームイベントの後に）医療介入が必要とされたかどうかの推定は、その患者について収集された生理学的データを解析することにより、確定可能である。たとえば、報告モジュールは、生理学的パラメータの動向値を解析して、アラームイベントの検出後も生理学的パラメータが悪化し続けたかどうかを判定することが可能である。実施形態によっては、報告モジュールは、動向データを解析して、生理学的パラメータの動向値で示される患者の状態が、アラーム検出イベントの１分後に悪化したかどうか、かつ／または、５分後に悪化したかどうか、かつ／または、１０分後に悪化したかどうか、を判定することが可能である。もちろん、その他の制限時間も使用可能である。そのような解析によって、患者の状態がアラームイベントの検出後に悪化したことが示された場合、これは、患者に医療的苦痛があったこと、ならびに、アラームが偽陽性ではなかったことをアラームが実際に表していたことの表れと見なすことが可能である。

【0345】

今説明したとおり、方法３３００で使用する医療介入データは、行われた医療介入の実際の記録から取得可能である。代替として、または追加で、方法３３００で使用する医療介入データは、たとえば、アラームイベントが検出された結果として臨床担当者が患者のところにいた時間の長さ、またはアラームイベントが検出された後のいくらかの妥当な時間内の生理学的パラメータの挙動などの要因に基づいて推定可能である。他の、医療介入の実施を推定する要因および方法も使用可能である。実際の臨床担当者記録から得られた医療介入データのほうがより正確で信頼性が高いが、そのような医療介入の実施が報告されない場合もある。推定された医療介入データは、正確な記録の維持を臨床担当者に頼ることが少ないために、役立つことが可能であるが、推定は、実際の臨床担当者記録よりは信頼性が多少低い場合がある。

【0346】

ブロック３３０８では、収集された生理学的パラメータデータおよび医療介入データを、報告モジュールによる後刻の解析に備えて、たとえば、中央リポジトリ（たとえば、ラウンドロビンデータベース７２２）に格納することが可能である。報告モジュールは、収集された医療介入データと検出されたアラームイベントとを相互に関連付けるロジックを含むことが可能である。たとえば、このロジックは、ある患者に対する所与の医療介入が、その患者に発生したアラーム状態と関連していたかどうかを判定するルールまたは条件を含むことが可能である。たとえば、医療介入データを実際に臨床担当者記録から取得する場合には、ある患者に対する特定の医療介入の実施と、その患者について検出されたアラームイベントの発生との間隔が、特定の時間長の範囲内であれば、その医療介入と発生したアラームイベントとを相互に関連付けることが可能である。他の方法でも、医療介入データと、その医療介入と関連する可能性があった、対応する検出されたアラームイベントとを照合することが可能である。たとえば、そのような相互関連は、実施された医療介入のタイプおよび監視データが取得された生理学的パラメータのタイプに基づくことが可能である。特定の生理学的パラメータに関連する可能性が特に高いものとして、いくつかの医療介入を表示することが可能である。そのような場合、報告モジュールのロジックは、そのような医療介入が、その生理学的パラメータによってトリガされたアラームイベントと相互に関連するものとしてマーキングされる可能性がより高くなるように構成可能である。

【0347】

ブロック３３１０では、報告モジュールは、（たとえば、図３１（たとえば、ブロック３１０８）に関して説明した）第２のアラーム条件を用いて生理学的パラメータデータを解析する。ブロック３３１２では、報告モジュールは、第１のアラーム条件を用いて識別されたアラーム状態と、シミュレートされた第２のアラーム条件を用いて識別されたアラーム状態との間の差を解析することが可能である。報告モジュールは、たとえば、第２のアラーム条件であったなら検出されたであろうアラーム状態を特定した後、第１のアラーム条件を用いて実際の監視時に正しく識別された本当のアラーム状態のうちのどれだけが、シミュレートされたアラーム条件が代わりに実装されていたとしても検出されたかを求めることが可能である。偽陰性の数が増えないようにするために、そのような本当のアラーム状態が同様に検出されることが望ましい。したがって、提案された、アラーム条件の変更を採用すべきかどうかの判断を支援するために、所与のシミュレートされたアラーム条件であったなら検出されないであろう本当のアラーム状態の数に関する情報を、病院管理者に提供することが可能である。

【0348】

さらに、報告モジュールは、識別されていたすべての偽陰性に対する、シミュレートされたアラーム条件の効果を、医療介入データに基づいて解析することが可能である。実施形態によっては、報告モジュールは、患者監視装置で実際に使用された第１のアラーム条件では識別されなかったいずれかの偽陰性が、シミュレートされたアラーム条件であったなら検出されたかどうか、を判定することが可能である。この判定は、たとえば、シミュレートされたアラーム条件を用いて検出されるいずれかのアラーム状態が、既に識別されている偽陰性イベントと時間的に相互に関連しているかどうかを判定するように設計されたロジックを実行することによって可能である。たとえば、シミュレートされたアラーム条件であれば識別されるアラーム状態が、所与の閾値より短いいくらかの時間だけ、識別された偽陰性のタイミングより先行する場合、これは、そのアラーム状態が偽陰性の表れであったであろうことを表していると見なすことが可能である。シミュレートされたアラーム条件であれば検出されるアラーム状態と、識別されていた偽陰性とを、医療介入データに基づいて相互に関連付けることには、他の論理テストを適用することも可能である。

【0349】

ブロック３３１４では、報告モジュールは、シミュレートされたアラーム条件の効果を識別、説明、要約、または他の形式で記載した報告を出力する。実施形態によっては、この報告は、シミュレートされたアラーム条件が、検出されるアラームイベントの数に対してだけでなく、たとえば、シミュレートされたアラーム条件であったなら検出されていた可能性のある、以前には検出されなかった偽陰性の数、パーセンテージ、比率などに対しても及ぼすことが期待される効果を示すことが可能である。この報告はまた、たとえば、第１のアラーム条件で正しく識別されていて、第２のアラーム条件であったなら識別されなかった可能性のある実際のアラーム状態の数、パーセンテージ、割合などを示すことも可能である。この報告は、他の情報も同様に含むことが可能である。

【0350】

図３４は、シミュレートされたアラーム条件がアラーム検出イベントの総数に及ぼす影響、ならびに、このシミュレートされたアラーム条件が、たとえば、偽陰性および偽陽性に及ぼす影響を示す表３４００による報告例を示す。表３４００は、図３２に示した表３２００に類似しており、５つの異なるシミュレートされたアラーム条件についての行エントリを含んでいる。表３４００は、シミュレートされたアラーム条件のそれぞれを用いて検出されるアラームの数についての列エントリを含んでいる。表３２００はまた、シミュレートされたアラーム条件のそれぞれを用いて検出されるアラームの数を、生理学的パラメータデータの収集時に適用された実際のアラーム条件を用いて検出されるアラームの数と比較した変化についての列エントリを含んでいる。

【0351】

さらに表３４００は、以前には検出されなかったが、特定のシミュレートされたアラーム条件であったなら検出されたであろう偽陰性の推定される数またはパーセンテージについての列エントリを含んでいる。表３４００はまた、第１のアラーム条件で正しく識別されたが、特定のシミュレートされたアラーム条件であったなら識別されなかったであろう本当のアラーム状態（すなわち、シミュレートされたアラーム条件によって新たにもたらされる偽陰性）の推定される数またはパーセンテージについての列エントリを含んでいる。これらの値は、本明細書に記載のように、報告モジュールによって算定または推定可能である。表３４００は、偽陽性の数の変化に関する情報を含むことも可能であり、たとえば、第１のアラーム条件では検出されたが、シミュレートされたアラーム条件であったなら検出されなかったであろう偽陽性の数、または、第１のアラーム条件では検出されなかったが、シミュレートされたアラーム条件であったなら検出されたであろう偽陽性の数に関する情報を含むことも可能である。

【0352】

図３４も、シミュレートされたアラーム条件に基づいて報告モジュールが生成可能な報告の一例を示しているに過ぎない。このような報告は、病院管理者が、アラーム条件を変更すべきかどうかについての判断を下すことを支援するための広く様々な情報を含むことが可能であることを理解されたい。さらに、そのような報告は、表、チャート、グラフ、リスト、スプレッドシートなどをはじめとする広く様々なフォーマットで提示可能である。

【0353】

報告モジュールは、本明細書に記載のようにアラーム条件をシミュレートすることに加えて、ベッドサイド患者監視装置および／または中央患者監視装置の他の構成変更の効果をシミュレートすることも可能である。たとえば、報告モジュールは、様々なアラーム通知遅延時間の効果をシミュレートすることが可能である。本明細書に記載のように、実施形態によっては、ベッドサイド患者監視器は、アラーム状態が検出された場合に、所定のアラーム通知遅延時間が経過するまで待機して、それから、アラームイベントの通知を臨床担当者または中央監視装置に送信するように構成可能である。さらに、中央監視装置も同様に、所定のアラーム通知遅延時間が経過するまで待機して、それから、検出されたアラームの通知を臨床担当者に（たとえば、ページングまたは他の通知方法で）実際に送信するように構成可能である。

【0354】

これらの通知遅延時間は、アラーム状態が一時的にしか続かない場合に、偽陽性のアラーム通知イベントの頻度を減らすことに役立つことが可能である。このような一時的なアラーム状態は、たとえば、突発的な動きや感情によって引き起こされる場合がある。報告モジュールは、アラーム通知イベントに対して通知遅延時間を変える効果をシミュレートすることに役立つことが可能である。このことが役立つことが可能なのは、たとえば、通知遅延時間の比較的わずかな変更が、臨床担当者が対応しなければならない偽陽性の数の重要な削減につながる可能性があるためである。

【0355】

図３５は、アラーム通知遅延時間の変化の結果として起こる、アラーム通知イベントの変化を調べる方法３５００を示すフローチャートである。方法３５００では、まず、ブロック３５０２で、本明細書に記載のように、生理学的パラメータアラームイベントに関して患者を監視する。

【0356】

方法３５００はブロック３５０４に進み、そこでは、第１のアラーム通知遅延時間に基づいてアラーム通知イベントを識別する。たとえば、アラーム通知イベントは、ベッドサイド患者監視器から中央監視装置への、アラーム状態の通知であってよい。この場合、第１のアラーム通知遅延時間は、ベッドサイド監視器でアラーム状態が検出された時点と、このアラームの通知が中央監視装置に送信された時点との間の経過時間として測定可能である。さらに、アラーム通知イベントは、患者監視装置から臨床担当者への、アラーム状態の通知であってよい。この場合、第１のアラーム通知遅延時間は、アラーム状態が検出された時点と、臨床担当者が通知された時点との間の経過時間として測定可能である。

【0357】

第１のアラーム通知遅延時間の継続時間にわたってアラーム状態が持続したかどうかを検出するために、監視の初期に、１つ以上のアルゴリズムをロー生理学的信号、処理済み生理学的信号、および／または生理学的パラメータの計算値に適用することが可能である。これは、たとえば、当該患者治療ドメインの各患者に対する各ベッドサイド患者監視器によって行うことが可能である。第１のアラーム通知遅延時間の継続時間にわたってアラーム状態が持続した場合は、アラーム通知イベントを認識することが可能である。

【0358】

ブロック３５０６では、生理学的パラメータデータを収集して、たとえば、本明細書に記載の中央リポジトリ（たとえば、ラウンドロビンデータベース７２２）に格納する。ブロック３５０８では、生理学的パラメータデータを再解析する。これは、たとえば、第１のアラーム通知遅延時間と異なる第２のアラーム通知遅延時間を用いる報告モジュールで行う。たとえば、ブロック３５０４で患者監視装置で使用された第１のアラーム通知遅延時間が５秒であった場合は、アラーム通知遅延時間を、たとえば、６秒または７秒などにして生理学的パラメータデータを再解析することが可能である。より短い遅延時間でもシミュレート可能である。

【0359】

場合によっては、アラーム状態が性質として一時的でしかない場合に、アラーム通知遅延時間を若干長めにすると、結果として、アラーム通知イベントが生成される前にアラーム状態が終わる可能性がある。このようにして、アラーム通知遅延時間を調節することにより、臨床担当者が対応しなければならないアラーム通知イベントの数を、潜在的に、安全に減らすことが可能である。これによって、臨床担当者は、一時的でないアラームイベントへの対応に時間をかけることが可能になって、患者治療の有効性が高まる。もちろん、一般的には、アラーム通知遅延時間のいかなる変更も、病院管理者または他の責任者の承認が必要である。これは、たとえば、アラーム通知遅延時間を長くすることによって、アラーム検出と臨床担当者の到着との間の経過時間が長くなって、患者を受け容れがたいリスクにさらすことがないようにするためである。

【0360】

既に収集された生理学的パラメータデータを報告モジュールで解析することにより、別のアラーム通知遅延時間の効果を、リスクのない方法でシミュレートすることが可能である。これは、患者が、たとえば、ブロック３５０２、３５０４で、引き続き、既に容認され、妥当性が確認されている遅延時間で監視可能であるためである。このように、別のアラーム通知遅延時間を必ずしも実際に実装することなく、それらのアラーム通知遅延時間が持つであろう効果をシミュレートできることは、病院または他の患者治療施設にとっては、アラーム通知遅延時間を当該の病院または患者治療施設に個別に適応させるように調節する手段として有利である。アラーム条件に関して本明細書に記載したように、アラーム通知遅延時間を変化させると、結果として、必ずしも患者のリスクを増やすことなく、アラーム通知イベントの数が大幅に減少する可能性がある。

【0361】

ブロック３５１０では、報告モジュールは、第１のアラーム通知遅延時間を用いて検出される臨床担当者通知イベントの数と、第２のアラーム通知遅延時間を用いて検出される臨床担当者通知イベントの数との差を解析することが可能である。たとえば、報告モジュールは、アラーム通知遅延時間の変更に対する応答として、アラーム通知イベントの総数が減るか、または増えるかを判定し、どれだけ減るか、または増えるかを算出することが可能である。この情報を、表、チャート、スプレッドシートなどの形式で病院管理者に提示することにより、患者監視装置によって実施されるアラーム通知遅延時間の変更が有利かどうかを、病院管理者が判断することを支援することが可能である。

【0362】

臨床担当者の対応までの時間のデータを、報告モジュールによる解析に備えて収集して格納することも可能である。臨床担当者の対応までの時間は、たとえば、臨床担当者がアラーム状態の通知を受けた時点と、臨床担当者がアラームをオフにして患者の状態をチェックするために病室に到着した時点との間の経過時間として測定可能である。この経過時間は、たとえば、ベッドサイド患者監視装置で測定して中央データリポジトリに送信することが可能である。臨床担当者の対応までの時間は、臨床担当者ごとに、かつ／または、臨床担当者のグループ全体について、格納可能である。結果として、報告モジュールは、たとえば、各臨床担当者、および／または、臨床担当者のグループ全体について、対応までの時間の最大値、最小値、および平均値に関する情報を出力することが可能である。このデータは、個々の臨床担当者、または臨床担当者のグループが監視アラームにいかに即時対応できるかの指標として、病院管理者の役に立つことが可能である。表示機能

【0363】

図３６Ａ～Ｂは、複数のレイアウトゾーンを有する表示を示しており、これには、パラメータ３６１０、プレチスモグラフ３６２０、プロンプトウィンドウ３６３０、患者情報３６４０、監視器設定３６５０、監視器状態３６６０、ユーザプロファイル３６７０、パラメータウェル３６８０、パルスツーパルス信号品質バー３６９０、およびソフトキーメニュー３６９５のための各ゾーンが含まれる。有利なことに、各ゾーンは、近傍ユーザにとって最も重要なパラメータが読みやすいように、情報が動的に拡大縮小される。また、プロンプトウィンドウ３６３０は、表示の中のあまり重要でない部分を一時的に重ね書きする重ね合わせメッセージ表示を利用する。さらに、パラメータウェル３６８０は、パラメータがアラームを発するまで最小化されるように近傍ユーザが選択したパラメータを収容する。以下では、これらおよび他の表示効率化機能について説明する。

【0364】

図３７Ａ～Ｆは、インストールされたパラメータの数に応じてレイアウトおよびフォントサイズを変える表示を示す。図は、８個のパラメータ（図３７Ａ）、７個のパラメータ（図３７Ｂ）、６個のパラメータ（図３７Ｃ）、５個のパラメータ（図３７Ｄ）、４個のパラメータ（図３７Ｅ）、および３個のパラメータ（図３７Ｆ）を表示する場合の水平方向および垂直方向の表示フォーマットを示している。有利なことに、フォントサイズは、インストールされたパラメータが少ないほど大きくなる。さらに、パラメータレイアウトは、インストールされたパラメータの数に応じた行数および間隔に従って変わる。また、プレチスモグラフ表示も、インストールされたパラメータが少ない場合にはサイズが大きくなる。さらに、テキスト情報のフォントサイズは、表示される情報の量に応じて拡大縮小される。たとえば、患者名の表示のフォントは、日時の情報が追加されると小さくなる。

【0365】

図３８Ａ～Ｂは、パラメータウェル３８１０を有する表示３８００を示す。具体的には、パラメータ値は、主表示部分またはパラメータウェルのいずれかに表示される。メニュー選択を通して、またはユーザが近傍にいることで起動されるユーザプロファイルによって、パラメータがパラメータウェルに最小化される。有利なことに、パラメータウェル内では１つ以上のパラメータが、比較的小さいフォントで表示されている。一方、最小化されていたパラメータがアラームを発すると、そのパラメータがパラメータウェルから除去され、比較的大きなフォントで主表示に戻る。

【0366】

図３９Ａ～Ｂは、アラームを発しているパラメータのフォントサイズを大きくした拡大パラメータ表示３９００、３９０１を示す。通常状態では、すべてのパラメータが同じサイズのフォントで表示される。アラームが発生すると、パラメータが限界を超えたことに注目させるために、限界を超えたパラメータの実際の値と限界値とが大きなフォントで表示され、さらに点滅する。別の実施形態では、すべてのパラメータが最大またはほぼ最大のサイズのフォントで表示されている場合に、アラームを発しているパラメータのサイズが少しだけ大きくなり、他のすべてのパラメータのサイズが小さくなる。結果として、アラームを発しているパラメータが拡大されている表示になる。一実施形態では、単一のパラメータがアラームを発している場合（図３９Ａ）、またはすべてのパラメータがアラームを発している場合（図３９Ｂ）に、背景色も（たとえば、赤の背景色とやわらかい赤の背景色との間で）同じ頻度で点滅して、点滅しているフォントとのコントラストを付ける。

【0367】

図４０～４３は、様々な有利な特徴を有する、他の表示の実施形態を示す。図４０Ａ～Ｂは、アラームをトリガした患者状態の深刻度の履歴をユーザが容易に識別できるように着色された着色アラームゾーン４０１０を有する動向表示４０００を示す。図４１は、矢印キーとカーソルの白黒反転を合わせた表示を示す。図４３Ａ～Ｂは、動向表示および対応するセットアップ画面を示す。

【0368】

図４２は、ユーザが選択可能なジャンプ画面を有する表示を示す。具体的には、ユーザは、メニューオプションの選択肢を通して、ホームページからアクセス可能な複数のジャンプ画面（たとえば、図示した７つの選択肢）のいずれかを選択することが可能である。一実施形態では、このボタンのデフォルトの動作は、「動向トグル」ボタン４２３１である。他のボタンは、「アラーム限界」４２３２、「圧縮波形表示またはＰＩおよびＰＶＩ動向オーバレイ」４２３３、「モード感度」４２３４、「患者アセス」４２３５、「パラメータ詳細トグル」４２３６、および「ユーザプロファイルログイン」４２３７である。

【0369】

本明細書に記載の情報および信号は、様々な技術および手法のいずれかを用いて表現可能である。たとえば、上記記載を通して参照可能なデータ、命令、コマンド、情報、信号、ビット、記号、およびチップは、電圧、電流、電磁波、磁場または磁性粒子、光場または光学粒子、またはこれらの任意の組み合わせにより表現可能である。

【0370】

本明細書で開示した実施形態に関して記載した各種の例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両者の組み合わせとして実装可能である。この、ハードウェアおよびソフトウェアの互換性を明示するために、ここまでは、各種の例示的なコンポーネント、ブロック、モジュール、回路、およびステップを、それぞれの機能性の観点から一般的に記載してきた。そのような機能性をハードウェアとして実装するか、ソフトウェアとして実装するかは、具体的な用途、およびシステム全体に課せられた設計上の制約に依存する。当業者であれば、記載の機能性を、具体的な用途に応じて様々なかたちで実装することが可能であるが、そのような実装の決定は、本発明の範囲からの逸脱を引き起こすと解釈されてはならない。

【0371】

実施形態によれば、本明細書に記載の方法のいずれかの特定の動作、イベント、または機能は、様々なシーケンスで実行可能であり、追加することも、結合することも、すべて省略することも可能である（たとえば、説明したすべての動作またはイベントが、本方法の実施に必須であるとは限らない）。さらに、特定実施形態では、複数の動作またはイベントを、順次的にではなく、（たとえば、マルチスレッド処理、割り込み処理、または複数のプロセッサにより）並行して実行することが可能である。

【0372】

本明細書で開示した実施形態に関して記載した各種の例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理素子、ディスクリートゲート論理またはトランジスタ論理、ディスクリートハードウェアコンポーネント、または、本明細書に記載の機能を実行するように設計された、これらの任意の組み合わせにより実装または実行が可能である。汎用プロセッサは、マイクロプロセッサ、従来型プロセッサ、コントローラ、マイクロコントローラ、状態機械などであってよい。プロセッサはまた、コンピューティング装置の組み合わせとして実装可能であり、たとえば、ＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、１つ以上のマイクロプロセッサとＤＳＰコアとの併用、または他の任意のそのような構成として実装可能である。さらに、「処理」という用語は、複数の意味を包含することを意図した広義語であり、複数の意味には、たとえば、プログラムコードを実装すること、命令を実行すること、信号を操作すること、フィルタリング、算術演算を実行すること、などが含まれる。

【0373】

本明細書で開示した実施形態に関して記載した方法またはアルゴリズムの各ステップは、ハードウェアで、またはプロセッサで実行されるソフトウェアモジュールで、または両者の組み合わせで直接実施することが可能である。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、または他の任意の形式の、当該技術分野で既知の記憶媒体内に存在してよい。記憶媒体は、プロセッサと結合され、これにより、プロセッサは、記憶媒体から情報を読み出したり、記憶媒体に情報を書き込んだりすることが可能である。代替として、記憶媒体は、プロセッサと一体であってもよい。プロセッサおよび記憶媒体は、ＡＳＩＣ内に存在してもよい。ＡＳＩＣは、ユーザ端末内に存在してよい。代替として、プロセッサおよび記憶媒体は、ユーザ端末内にディスクリート部品として存在してよい。

【0374】

モジュールは、ソフトウェアオブジェクト指向ソフトウェアコンポーネント、クラスコンポーネントおよびタスクコンポーネント、プロセス、メソッド、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造体、表、配列、または変数などのソフトウェアコンポーネントまたはハードウェアコンポーネントのいずれかを含んでよく、これらに限定されない。

【0375】

さらに、本発明を、特定の好ましい実施形態の文脈で開示したが、本発明のシステム、装置、および方法の特定の利点、特徴、および態様は、他の様々な実施形態において実現可能であることを理解されたい。さらに、本明細書に記載の様々な態様および特徴は、個別に、または組み合わせて、または相互に置換して実施可能であること、ならびに、それらの特徴および態様の様々な組み合わせおよび副組み合わせが可能であり、それらも本発明の範囲に収まることを理解されたい。さらに、上述のシステムおよび装置は、好ましい実施形態において記載されたモジュールおよび機能をすべて含む必要はない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21A-21F】

【図22A-22E】

【図23A】

【図23B】

【図23C】

【図24A】

【図24B】

【図25A】

【図25B】

【図25C】

【図25D】

【図26】

【図27A】

【図27B】

【図28】

【図29A】

【図29B】

【図29C】

【図29D】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36A】

【図36B】

【図37A】

【図37B】

【図37C】

【図37D】

【図37E】

【図37F】

【図38A】

【図38B】

【図39A】

【図39B】

【図40A】

【図40B】

【図41】

【図42】

【図43A】

【図43B】