JP2020502631A - 患者モニタリングのための待ち行列 - Google Patents

Abstract

個人の状態の変化をモニタリングするために個人を患者モニタリング待ち行列に編成することに関する技法が本願で開示される。さまざまな実施形態において、複数の患者のそれぞれから取得される初期バイタルサインに基づいて患者緊急度インジケーターが受領されてもよい（５０２）。患者がモニタリングされるべき次のスケジュールされた時間に基づいて優先順位付けされた患者を含む患者モニタリング待ち行列が確立されてもよい（５０４、９０２）。次のスケジュールされた時間は、少なくとも部分的には、患者緊急度インジケーターに基づいて決定されてもよい（１１０６）。患者モニタリング待ち行列の先頭の選択された患者が、モニタリングのために送付されてもよく（５０６、１０７６）、バイタルサイン取得カメラ（２７６、３７６、４７６、７７６、８７６）を使って前記選択された患者から更新されたバイタルサインが邪魔にならないように取得されてもよい（５１０）。邪魔にならない取得の結果に応答して、患者モニタリング待ち行列が変更されてもよい（１０３４、１０３８、１０４２、１０４６）。

Description

本開示は、概括的には医療に向けられている。より詳細には、本稿に開示されるさまざまな方法および装置は、待合室などのエリアにおける患者のような複数の個人を、患者の状態の変化をモニタリングするための患者モニタリング待ち行列に編成することに関するが、それだけではない。

患者が病院を訪れるとき、患者は典型的には、患者の名前、年齢、身長、体重、バイタルサイン、訪問理由および他の同様の情報など、患者に関するさまざまな情報を決定するためにトリアージされる。いったんトリアージされると、患者は待合室などのエリアに送られて、患者を診察および／または治療するために医師などの病院資源が利用可能になるのを待つ。患者の待ち時間は、病院資源の利用可能性によってはかなりの長さになることがある。患者が待っている間に悪化することはめずらしくなく、医療人員が常に適時に悪化に気づくとは限らない。

本開示は、待合室などのエリアにおける患者のような複数の個人を、患者の状態の変化をモニタリングするための待ち行列に編成するための方法、システムおよび装置に向けられる。たとえば、複数のトリアージされた患者は、救急治療室（「ER」）の医師によって診察されることができるまで待合室で待つことがある。患者は、患者モニタリング待ち行列（単に「患者待ち行列」とも称される）に含められてもよく、この待ち行列は、たとえば、トリアージ看護師によって患者から取得／収集された情報に基づいて決定される各患者に関連付けられた緊急度の指標（本稿では「患者緊急度インジケーター（patient acuity indicator）」と称される）ならびに患者待ち時間、患者の在室などの他のデータ・ポイントに基づいて順序付けまたはランク付けされる。いくつかの実施形態では、たとえば患者待ち行列の順序で、各患者から一つまたは複数の更新されたバイタルサインを手動で取得するために医療人員が派遣されてもよい。他の実施形態では、待合室に取り付けられた一つまたは複数の「バイタルサイン取得カメラ」が、各患者からの一つまたは複数のバイタルサインの非接触および／または邪魔にならない収集を周期的に実施するように構成されてもよい。医療人員によって手動で取得されるものであれ、あるいはバイタルサイン取得カメラまたはウェアラブル・センサーのような他の手段を使って自動的に取得されるものであれ、これらの更新されたバイタルサインは、血圧、温度、脈拍、酸素飽和度(「SO₂」)、呼吸数、皮膚の色、姿勢、発汗レベルなどを含みうるが、これらに限定されない。

患者をモニタリングするために使用される資源――たとえばバイタルサイン取得カメラ――は限られていることがある。よって、患者待ち行列は、モニタリングされる患者を適切にスケジュールするために、さまざまな方法でランク付けまたは「優先順位付け」されうる。いくつかの実施形態では、患者待ち行列が、先入れ先出し（「FIFO」）技法、ラウンドロビン技法などを用いて優先順位付けされてもよい。しかしながら、他の実施形態では、患者待ち行列は、より緊急性の高い患者がより緊急性の低い患者よりも頻繁にモニタリングされるように、優先順位付けされてもよい。たとえば、より緊急性の高い患者は、待っている間に悪化する可能性がより高いことがありうるからである。たとえば、いくつかの実施形態において、患者待ち行列は、少なくとも部分的には、患者に関連付けられた患者緊急度インジケーターに基づいて優先順位付けされてもよい。たとえば、患者緊急度インジケーターを使って、患者へのモニタリングのための次のスケジュールされた時間が決定され、割り当てられてもよく、患者待ち行列は、モニタリングのための次のスケジュールされた時間によって優先順位付けされてもよい。

一般に、ある側面では、方法が、一つまたは複数のプロセッサによって、一つまたは複数のバイタルサイン取得カメラによって捕捉されることができるエリア内の複数の患者の各患者に関連付けられた患者緊急度インジケーターを受領する段階であって、各患者に関連付けられた患者緊急度インジケーターは、患者から収集された一つまたは複数の初期バイタルサインに基づく、段階と；前記プロセッサの一つまたは複数によって、少なくとも部分的には患者緊急度インジケーターに基づいて優先順位付けされた前記複数の患者を含む患者モニタリング待ち行列を確立する段階と；前記プロセッサの一つまたは複数によって、前記患者待ち行列から、前記患者モニタリング待ち行列の先頭の患者を選択する段階と；前記バイタルサイン取得カメラの一つまたは複数によって、選択された患者からの一つまたは複数の更新されたバイタルサインを邪魔にならないように収集する段階と；前記プロセッサの一つまたは複数によって、前記邪魔にならない収集の結果に応答して、前記患者モニタリング待ち行列を変更する段階とを含みうる。

さまざまな実施形態において、患者待ち行列は、モニタリングされる患者のための次のスケジュールされた時間にさらに基づいて、優先順位付けされてもよい。さまざまな実施形態において、モニタリングされる各患者のための次のスケジュールされた時間は、少なくとも部分的には、その患者に関連付けられた患者緊急度インジケーターに基づいて決定されてもよい。さまざまな実施形態において、邪魔にならない収集の結果は、前記プロセッサの一つまたは複数によって、選択された患者の悪化を医療人員にアラートする出力を提供することを含んでいてもよく、前記変更することは、選択された患者を患者待ち行列から除去することを含んでいてもよい。

さまざまな実施形態において、邪魔にならない収集の結果は、一つまたは複数の更新されたバイタルサインを邪魔にならないように収集し損なったことを含んでいてもよく、前記変更することは、選択された患者を待ち行列に入れ直すことを含む。さまざまな実施形態において、邪魔にならない収集の結果は、一つまたは複数の更新されたバイタルサインの成功した収集を含んでいてもよく、前記変更することは、少なくとも部分的には選択された患者に関連付けられた患者緊急度インジケーターに基づいて、選択された患者を待ち行列に入れ直すことを含んでいてもよい。さまざまな実施形態において、選択された患者を待ち行列に入れ直すことは、少なくとも部分的には選択された患者に関連付けられた患者緊急度インジケーターに基づいて、モニタリングされる選択された患者のための次のスケジュールされた時間を計算することを含んでいてもよい。さまざまな実施形態では、選択された患者を待ち行列に入れ直すことは、選択された患者を患者待ち行列の選択された位置に挿入することを含んでいてもよい。選択された位置は、選択された患者がモニタリングされるべき次のスケジュールされた時間よりも遅い、またはより大きい、モニタリングされるべき次のスケジュールされた時間をもつ、患者待ち行列内の別の患者より前であってもよい。

さまざまな実施形態では、本方法は、選択された患者を表わす参照画像に基づいて、前記プロセッサの一つまたは複数によって、エリア内の複数の患者のうちの選択された患者を識別することをさらに含んでいてもよい。さまざまな実施形態では、参照画像は、トリアージ・ステーションに付随する一つまたは複数のカメラまたは医療待合室に付随する登録デスクによって捕捉される。さまざまな実施形態では、本方法はさらに、前記プロセッサの一つまたは複数によって、ウォッチドッグ・タイマーを所定の時間間隔に設定する段階と；更新されたバイタルサインが患者待ち行列内の任意の患者から最後に邪魔にならないように収集されてから前記所定の時間間隔が経過したとの判定に応答して、患者待ち行列から選択された患者を再選択する段階と；一つまたは複数のバイタルサイン取得カメラによって更新されたバイタルサインを邪魔にならないよう取得しようとする試みの検出に応答して、ウォッチドッグ・タイマーをリセットする段階とを含んでいてもよい。

上述の概念および下記でより詳細に論じられる追加的な概念のあらゆる組み合わせ（かかる概念が相互に矛盾しないことを条件とする）が、本稿で開示される主題の一部であると考えられることを理解しておくべきである。特に、本開示の末尾に現われる特許請求される主題のあらゆる組み合わせは、本稿に開示された主題の一部であると考えられる。また、本稿で明示的に用いられ、参照によって組み込まれる何らかの開示にも現われることがありうる用語は、本稿に開示される特定の概念と最も整合する意味を与えられるべきであることも理解しておくべきである。

図面において、同様の参照符号は一般に異なる図面を通じて同じ部分を指す。また、図面は、必ずしも同縮尺ではなく、一般に、開示の原理を例解することに重点が置かれている。

さまざまな実施形態に基づく、開示された技法を用いてモニタリングされる患者についての一般的なプロセス・フローを概略的に示す。

さまざまな実装に基づく、開示されるさまざまなコンポーネントが本開示の選択された諸側面を実装しうる例示的な環境を示す。

さまざまな実施形態に基づく、開示された技法が実施されうる例示的シナリオを示す。 さまざまな実施形態に基づく、開示された技法が実施されうる例示的シナリオを示す。

さまざまな実施形態に基づく、エリア内の個人をモニタリングする例示的方法を示す。

例示的なコンピュータ・システムのコンポーネントを示す。

さまざまな実施形態に基づく、バイタルサイン取得カメラの例示的コンポーネントを概略的に示す。 さまざまな実施形態に基づく、バイタルサイン取得カメラの例示的コンポーネントを概略的に示す。

さまざまな実施形態に基づく、本稿に記載される技法を用いてモニタリングされる患者待ち行列を確立するための例示的な方法を示す。

さまざまな実施形態に基づく、さまざまなイベントとディスパッチ患者のサブルーチンとの間の例示的な相互作用を示す。

さまざまな実施形態に基づく、前記患者待ち行列において患者を待ち行列に入れ直すための例示的な方法を示す。

さまざまな実施形態に基づく、新規および／または待ち行列に入れ直された患者をモニタリングするための、例示的な患者待ち行列と、次のスケジュールされた時間を計算するためのルックアップテーブルとを示す。

患者が病院を訪れる時、患者は典型的には、患者の名前、年齢、身長、体重、バイタルサイン、訪問理由および他の同様の情報など、患者についてのさまざまな情報を決定するために、登録され、トリアージされる。いったんトリアージされると、患者は待合室などのエリアに送られて、患者を診察および／または治療するために医師などの病院資源が利用可能になるのを待つ。患者の待ち時間は、病院資源の利用可能性によってはかなりの長さになることがある。時折、患者は待っている間に悪化し、医療人員が常に適時に悪化に気づくとは限らない。よって、本稿に記載される技法は、重篤さにかかわりなくすべての患者が定期的にモニタリングされることを保証しつつ、より重篤な患者を優先する順序での、待合室のようなエリアにおける患者の状態のモニタリングを容易にする。

下記は、本発明のさまざまな実施形態で使用される用語の定義である。本稿で使用される「データベース」という用語は、データおよび情報が記憶、検索、取り出し、更新および操作されることを許容するとともに、それらがテーブル形式などの一つまたは複数のフォーマットに提示される、またはテキスト、数値、画像およびオーディオ・データにグループ化されることを許容するように編成されたデータおよび情報の集合を指す。本稿で使用される「データベース」という用語は、より大きなデータベースの一部を指すこともあり、この場合、データベース内のある型のデータベースを形成する。本稿で使用される「データベース」は、ローカルに存在するか、またはリモート位置、たとえばリモート・ネットワーク・サーバーからアクセスされうる従来のデータベースをも指す。データベースは、典型的には、さまざまな型の揮発性および不揮発性のコンピュータ記憶装置を含むコンピュータ・メモリ内に存在する。データベースが存在するメモリは、高速ランダムアクセスメモリ、または磁気ディスク記憶装置、光記憶装置、およびフラッシュメモリのような不揮発性メモリを含みうる。データベースが存在するメモリは、データベースによって受領され、データベースに格納されるデータを処理し、整理するための一つまたは複数のソフトウェアをも含んでもよい。

図１は、開示される技法を用いて患者が概括的にどのようにモニタリングされうるかを概略的に示している。具体的には、待合室より前のエリアにおいて生起しうる動作およびアクションが描かれている。待合室より前のエリアは、待合室より前のエリア（単数または複数）１０２などであり、受付および／または登録および／またはトリアージ・ステーションもしくはブースを含みうる。さらに、待合室１０４において生起しうる動作およびアクションが描かれている。ブロック１０６において、新規患者が、たとえば、受付デスク（図示せず）でチェックインした後、待合室前エリア１０２にはいるおよび／または接近することができる。

ブロック１０８では、新規患者が登録されてもよい。登録はたとえば、患者の氏名、年齢、性別、保険情報および訪問理由などの患者についての情報を収集することを含んでいてもよい。典型的には、この情報は、トリアージ看護師のような医療人員によって手動でコンピュータに入力されてもよいが、それだけではない。いくつかの実施形態では、患者の一つまたは複数の参照画像が、たとえば、トリアージ看護師によって操作されるコンピューティング装置と一体のカメラ、スタンドアローンのカメラおよび／またはバイタルサイン取得カメラによって取得されてもよい（その場合、少なくともいくつかのバイタルサインは、登録時に任意的に取得されてもよい）。多くの事例において、トリアージ看護師は、さまざまな医療器具を用いてブロック１１０でさまざまな初期バイタルサインを取得しうる。これらの初期のバイタルサインは、血圧、脈拍、グルコースレベル、SO₂、フォトプレチスモグラム（「PPG」）、呼吸数（たとえば呼吸のレート）、温度、皮膚の色などを含みうるが、これらに限定されない。図１には描かれていないが、いくつかの実施形態では、患者の病歴の取得／更新、患者のアレルギーの判別、患者の医薬使用の判別など、トリアージにおいて他の情報も収集されてもよい。

いくつかの実施形態では、トリアージの間、患者は、患者の疾患の重症度をランク付けするために使用されうる指標となりうる、いわゆる「患者緊急度インジケーター」を割り当てられてもよく、場合によっては、救急治療室資源の予期される必要性を示してもよい。患者緊急度インジケーターを決定および／または割り当てするためには、いくつもある一般に使われているインジケーターおよび／または臨床決定支援（「CDS」）アルゴリズムが使用されうる。それには、緊急重症度指数（「ESI」）、台湾トリアージシステム（「TTS」）、カナダ・トリアージ・アンド・アキュイティ・スケール（「CTAS」）などを含まれるが、これらに限定されない。たとえば、いくつかの実施形態では、患者のバイタルサインは、システム・データベースに記憶されている、あらかじめ定義されたバイタルサイン閾値、または所与の患者年齢、性別、体重などに典型的な公表されているかまたは既知のバイタルサイン値と比較されて、患者の初期患者緊急度インジケーターおよび／または患者待ち行列における患者の初期位置を決定してもよい。ひとたび患者が登録され、その初期バイタルサインが取得されると、ブロック１１２において、患者は待合室１０４に送られてもよい。いくつかの実施形態では、患者についてのさまざまな生理的および他の情報が、トレーニングされたモデル（たとえば、回帰モデル、ニューラルネットワーク、深層学習ネットワークなど）、症例に基づく推論アルゴリズム、または一つまたは複数の緊急度インジケーターを導出するための他の臨床推論アルゴリズムに供給されてもよい。いくつかの実施形態では、患者の緊急度インジケーターを導出するために使用される情報は、バイタルまたはバイタルサイン取得カメラによって捕捉されうる他の情報を含んでいてもよく、または完全にそれらに限定されていてもよい。いくつかの実施形態では、緊急度インジケーターを導出するために使用される情報は、代替的または追加的に、患者の以前の電子医療記録（「EMR」）からの情報、トリアージ時に患者から取得された情報、患者によって携行されるウェアラブル装置もしくは他のセンサーからの情報、待合室の他の患者または人についての情報（たとえば、室内の他の人のバイタル）、家族メンバーまたは患者に関連するその他についての情報（たとえば、家族メンバーのEMR）などの情報を含んでいてもよい。

ブロック１１４において、たとえば、一つまたは複数のカメラ、センサーまたは医療人員からの入力を用いて、患者が待合室を離れたことが判別されてもよい。ブロック１１４は、現在待合室内にいる各人物をスキャンし（たとえば、後述するブロック１２０の実行のように、ひとたび患者がバイタルが捕捉されるべき患者の待ち行列の先頭になったら該患者を位置特定しようとするシーク機能の一部として、または後述するブロック１１８および１２０を含むループの多重実行のように、バイタルを捕捉するために室内の各人物を通じて巡回する）、患者が位置特定されなかったことを判別することを含んでいてもよい。いくつかの実施形態では、システムは、一時的な不在を考慮に入れるために（たとえばトイレに行くまたはトリアージ室で臨床スタッフと話す）、患者が待合室を離れたとみなされる前に、その患者がみつからない事例の所定回数に達するまたはその患者がみつからない所定の長さの時間が経過するまで待ってもよい。たとえば、患者は、医師の診察を受ける番なので、ER本体に連れて行かれたことがありうる。あるいは待っている間に患者の状態が改善したため患者が病院を去ったことがありうる。あるいは、患者がしびれをきらして、他所でケアを求めるために去ったことがありうる。場合によっては、患者が離れて、たとえばトイレの使用後に戻ってくることがある。理由がどうあれ、ひとたび患者が少なくとも閾値時間にわたって待合室を離れたことが判別されると、ブロック１１６において、患者は、たとえば、登録された患者が入力される待ち行列から除去することによって、システムから解放されてもよい。場合によっては、看護師または他の医療人員が、患者の不在と再来した場合の戻りとを記録してもよい。

ブロック１１８において、待合室１０４内の患者が、本稿に記載される技法を使うモニタリングのために識別されてもよい。たとえば、いくつかの実施形態では、待合室内の複数の患者に関連する情報（たとえば、トリアージで得られた情報）は、たとえば、待ち時間、待合室における患者の存在（たとえば、みつからない患者は、診察を受けることなく去ったのか、単にトイレもしくは自動販売機まで行ったのかをさらに判別するために探されてもよい）などといった他の指標に加えてまたはかかる他の指標の代わりに、それぞれの患者緊急度インジケーターによって、患者モニタリング待ち行列においてランク付けされてもよい。さらに他の実施形態では、患者緊急度インジケーターは、患者モニタリング待ち行列をランク付けするときには考慮されなくてもよく、代わりに、患者の待ち時間、患者の存在等の事情のみが考慮されてもよい。

しかしながら、そのような患者モニタリング待ち行列はランク付けされ、いくつかの実施形態では、待ち行列における最初の患者が、次にモニタリングされるべき患者として識別される。患者モニタリング待ち行列が、患者緊急度インジケーターによってランク付けされた物理的メモリ位置のシーケンスにおいて格納されることは要求されない（可能ではあるが）。むしろ、いくつかの実施形態では、ランク付けされた患者モニタリング待ち行列が、単に、各患者に関連付けられたランクまたは優先度レベル値を含むのでもよい。換言すれば、本稿に記載される「患者モニタリング待ち行列」は、必ずしもメモリ／データベース位置の連続する／順序付けられたシーケンスではなく、患者緊急度インジケーター、待ち時間などに基づいて論理的にランク付けされる「論理的」待ち行列のことであってもよい。ブロック１１８において、患者は、患者モニタリング待ち行列におけるそれぞれのランク付けの順で、モニタリングのために同定されてもよい。

ブロック１２０において、ブロック１１８で識別された患者は待合室１０４において位置特定されてもよい。いくつかの実施形態では、待合室１０４の中または近くに配備された一つまたは複数のバイタルサイン取得カメラ（図１には描かれていない；図２、図７および図８参照）は、待合室１０４内の患者のさまざまな視覚的特徴をスキャンして、それらの特徴をブロック１０８における登録の間に捕捉された参照患者画像と照合するよう動作させられてもよい。患者画像の対応する特徴と照合されうる患者の視覚的特徴は、顔、毛髪、衣服、胴体などを含むが、これらに限定されない。医療人員が手動で、更新されたバイタルサインを取得する実施形態では、医療人員は、待合室でモニタリングするために次の患者を探してもよい。

他の実施形態では、患者モニタリング待ち行列が確立されなくてもよい。代わりに、バイタルサイン取得カメラは単に、それぞれの視野が待合室３０４の所定の軌道を通じて動くように、パン、チルトおよび／またはズームするように構成されてもよい。たとえば、バイタルサイン取得カメラは、椅子の列を通じて順次スキャンするように、および／または普通患者がいることが知られている待合室１０４の諸エリアを通じて順次スキャンするように構成されてもよい。さらに他の実施形態では、広い視野をもつ一つまたは複数のカメラを使用して、多数のまたはすべての患者を同時に検出、識別およびモニタリングしてもよい。そのような実施形態では、それぞれの顔が捕捉されるにつれて、諸患者記録と突き合わせて照合されて、その顔が対応する患者を識別する。それにより、バイタルが捕捉され、正しい患者または人物に相関付けられることができる。

さまざまな実施形態において、システムは、（たとえば段階１０８〜１１２に従って）システムに登録されている患者のみをモニタリングすることに限定されなくてもよい。たとえば、待合室にいる患者の同伴者が、同伴者自身は患者として登録されていなかったとしても、注意を要する状態を発達させることがありうる。もう一つの例として、患者が、待合室／登録ステーションが混んでいる、登録することを知らない、登録しないことを選ぶなどの理由で、登録１０８〜１１２を通過せず、単に待合室で座っていることがありうる。そのような実施形態では、システムは、その顔の画像／ビデオを捕捉する（または他の識別特徴を捕捉する）ことによって、登録されていない人を検出することがあり、登録された患者の間で一致する患者記録をみつけ損なうことがありうる。そのような場合、システムは、その未知の患者を表わすための新しいレコードを作成し、初期バイタル測定として該レコードに記憶するためのバイタルを捕捉し、そして参照画像として画像／ビデオを記録してもよい（あるいは、参照画像としてのその後の使用のために、可能性としてはよりよいアングルから、一つまたは複数の追加の画像／ビデオを捕捉してもよい）。その未知の患者についてのアラートまたはその他の情報が（たとえば後述するように）待合室スタッフに対して表示される場合、その情報は、該アラートまたは他の情報が対応している待合室にいる人物を識別する際にスタッフを助けるために、これらの参照画像／ビデオの一つまたは複数と一緒に表示されてもよい。人物が段階１０８〜１１２に従って後に登録される場合、新しい情報は、「未知の人物」レコードにマージされてもよい。これは手動で（たとえば、登録情報で補足される既存のレコードをスタッフが手動で選択することによって）または自動的に（たとえば、後で二つのレコードの参照画像を比較し、それらが同じ人物に対応することを判別することによって、またはバイタル捕捉シーケンスの間にその人物を両方のレコードと照合することによって後で困難／曖昧さに遭遇することによって）のいずれでもよい。

ブロック１２２では、待合室１０４の中または近くに取り付けられるか、または他の仕方で配備された一つまたは複数のバイタルサイン取得カメラが、ブロック１１８において識別され、ブロック１２０において位置特定された患者からの一つまたは複数の更新されたバイタルサインの邪魔にならない（unobtrusive）（たとえば非接触の）取得を実行するように動作させられてもよい。バイタルサイン取得カメラは、血圧、脈拍（または心拍数）、皮膚の色、呼吸数、PPG、SO₂、温度、姿勢、発汗レベルなどを含むが、これらに限定されない、患者からの多様な異なるバイタルサインを（患者に物理的に接触することなく）取得するように構成されてもよい。さらに他の実施形態では、更新されたバイタルサインは、バイタルサイン取得カメラを使って自動的にではなく、たとえば医療人員によって手動で取得されてもよい。さらに他の実施形態では、更新されたバイタルサインは、ウェアラブル・センサーなどの他の装置を用いて自動的に取得されてもよい。

いくつかの実施形態では、バイタルサインを取得するためおよび／または患者から生理情報を抽出するために、いわゆる「非接触方法」を実行するように装備されたバイタルサイン取得カメラが、医療画像装置として使用されてもよい。そのようなカメラの限定しない例は、米国特許出願公開第20140192177A1、20140139656A1、20140148663A1、20140253709A1、20140235976A1および20140275880A1に記載されている。これらはあらゆる目的について参照によってここに組み込まれる。図７および図８は、本開示のさまざまな実施形態で使用されうるバイタルサイン取得カメラの二つの限定しない構成を概略的に描いている。

いくつかの実施形態では、患者の心拍数または脈拍を決定するための一つの技法は、患者の顔の皮膚色をモニタリングすることでありうる。血流に起因する皮膚の色の微小変化が、バイタルサイン取得カメラによって検出されうる。これらの検出された微小変化を用いて、患者の脈拍数を決定しうる。変動する心拍数の変化による顔の皮膚色の変化は、肉眼では見えないかもしれないが、本稿に記載されるバイタルサイン取得カメラの使用は、皮膚の色の微小変化の検出を許容しうる。

本稿に記載されるバイタルサイン取得カメラによって測定可能なもう一つのバイタルサインは、患者の呼吸数である。いくつかの実施形態において、バイタルサイン取得カメラは、患者の胸部および／または腹部エリアにズームインして、患者の胸部または腹部の動きを追跡してもよい。次いで、医療画像装置が、患者の胸部または横隔膜エリアの動きをモニタリングすることによって決定されうる患者の呼吸数を決定してもよい。追加的または代替的に、患者の体温が、サーモグラフィーまたは赤外線画像／ビデオを捕捉するように構成された、本稿に記載されるバイタルサイン取得カメラによって決定されてもよい。

ブロック１２０では、たとえば図２（後述）に描かれた一つまたは複数のコンポーネントによって、患者の状態が変化したかどうかが、ブロック１２２で取得された更新されたバイタルサイン（単数または複数）と、以前に取得されたバイタルサイン（たとえば、ブロック１１０で取得された初期バイタルサイン、またはバイタルサイン取得カメラによって取得された更新されたバイタルサイン／生理パラメータの前の反復）との比較に基づいて判定されてもよい。たとえば、患者の脈拍、呼吸数、血圧、SO2、PPG、体温などが、患者が待っている間に増加または減少したかどうかが判定されてもよい。答えがノーである場合、制御はブロック１１８に戻ってもよく、新たな患者（たとえば、次に高い患者緊急度インジケーターをもつ患者）が識別されてもよく、制御はブロック１２０に戻ってもよい。しかしながら、ブロック１２４における答えがイエスである（すなわち、患者の状態が変化した）場合、制御はブロック１２６に渡されてもよい。いくつかの実施形態において、患者の状態は、（少なくとも部分的には）モニタリング順序を決定するために使用される同じ緊急度インジケーターによって表わされてもよい。

ブロック１２６では、ブロック１２４で検出された変化に基づいて医療アラートが正当化されるかどうかが（やはり図２の一つまたは複数のコンポーネントによって）判定されてもよい。たとえば、一つまたは複数のバイタルサインおよび／または患者緊急度インジケーターの変化が一つまたは複数の閾値を満たすかどうか（たとえば、血圧がこの特定の患者にとって安全と考えられるレベルを超えて上昇したか？）を決定することができる。答えがイエスである場合、制御はブロック１２８に渡されてもよい。ブロック１２８では、たとえば、当直看護師または他の医療人員に対して、患者が悪化しつつあるというアラートが出力されてもよい。次いで、医療人員は患者をチェックして、患者をただちに入院させたり、または患者を医師に送ったりするなどの是正アクションが正当化されるかどうかを判定してもよい。いくつかの実施形態では、制御はブロック１１８に直接戻ってもよい。しかしながら、ブロック１２６における答えがノーである場合、いくつかの実施形態では、制御はブロック１１８に戻ってもよい。

図２は、さまざまな実施形態に従って、開示された技法を実施するために使用されうる例示的コンポーネントを描いている。病院情報システム２４０は、病院、医師の診察室などに一般的に見られるタイプのものであってもよい。病院情報システム２４０は、一つまたは複数のコンピュータ・ネットワーク（図示せず）を介して接続されていてもいなくてもよい一つまたは複数のコンピューティング・システムを用いて実装されてもよい。病院情報システム２４０は、なかでも、登録モジュール２４２、トリアージ・モジュール２４４、解放モジュール２４６およびアラーム・モジュール２４８を含んでいてもよい。モジュール２４２〜２４８または本稿に記載される他の任意のモジュールまたはエンジンのうちの一つまたは複数は、メモリに記憶された命令を実行する一つまたは複数のマイクロプロセッサを含む、ハードウェアおよびソフトウェアの任意の組み合わせを使用して実装されてもよい。たとえば、登録モジュール２４２は、プロセッサ上で実行される登録に関連して本稿に記載される機能を実装する登録命令を含んでいてもよく、一方、トリアージ・モジュール２４４は、同じプロセッサ上で実行されるトリアージに関連して本明細書に記載の機能を実装するトリアージ命令を含んでいてもよい。同様の基礎となるハードウェアおよびソフトウェアが、本稿に記載される他の「モジュール」を実施するために使われてもよい。

登録モジュール２４２は、たとえば、当直看護師からの手動入力として、新規患者の登録（registration）情報を受領するように構成されてもよい。これは、たとえば、患者の氏名、年齢、保険情報などを含みうる。トリアージ・モジュール２４４は、たとえば、当直看護師から手動入力として、またはネットワーク接続された医療設備から直接、上述のようなバイタルサインおよび／または体重、身長、患者の来院理由などといった他の生理データを受領するよう構成されてもよい。さまざまな実施形態において、トリアージ・モジュール２４４によって受信されるバイタルサインおよび／または患者緊急度インジケーター（たとえば図２におけるESI）は、登録モジュール２４２によって受信される対応する患者情報と、たとえば病院情報システム２４０に関連する一つまたは複数のデータベース（図示せず）において、関連付けられてもよい。

アラーム・モジュール２４８は、患者の悪化などのさまざまなイベントを示す情報を受信し、応答してさまざまなアラーム（alarm）および／またはアラート（alert）を発するように構成されてもよい。これらのアラームおよび／またはアラートは、視覚的出力（たとえば、病院人員に見えるディスプレイ・スクリーン）、インターホン・アナウンス、テキスト・メッセージ、電子メール、オーディオ・アラート、触覚アラート、ページ、ポップアップ・ウインドー、フラッシュライトなどを含むが、これらに限定されない多様なモダリティーを使って出力されうる。病院情報システム２４０のモジュール２４２〜２４８は、たとえば、一つまたはコンピュータ・ネットワーク（図示せず）を介して、病院情報システム・インターフェース２５０（図2の「H.I.S.インターフェース」）に動作可能に結合されてもよい。

病院情報システム・インターフェース２５０は、伝統的な病院情報システム２４０と、本開示の選択された諸側面をもって構成された患者モニタリング・システム２５２との間のインターフェースとして機能しうる。さまざまな実施形態において、病院情報システム・インターフェース２５０は、たとえば、患者モニタリング・システム２５２の他のモジュールに対して、患者についてのさまざまな情報を公開してもよい。該情報は、登録情報、患者緊急度インジケーター（たとえばESI）、処方および／または投与された医薬、患者が解放されたかどうか、さまざまなアラーム／アラートなどである。後述するように、いくつかの実施形態では、これらの公開は、イベント公開・申し込み（event publish and subscribe）（「EPS」）モジュール２７０に提供されてもよく、次いでこのモジュールが、それらを選択的にデータベース２７２に格納し、および／またはそれらを患者モニタリング・システム２５２の他のモジュールに選択的に公開してもよい。いくつかの実施形態では、病院情報システム・インターフェース２５０は、追加的にまたは代替的に、他のモジュールによって提供される一つまたは複数のアラートまたは公開に申し込んでもよい。たとえば、病院情報システム・インターフェース２５０は、悪化検出モジュール２６８からのアラートに申し込んでもよい。それによりたとえば、病院情報システム・インターフェース２５０が、アラーム・モジュール２４８のような病院情報システム２４０の適切なコンポーネントに、患者が悪化しつつあることを通知してもよい。

患者モニタリング・システム２５２は、患者が実際の医学的状態に適した仕方でサービスを受けることを確実にするために、待合室１０４のようなエリアにいる患者のモニタリングを容易にする多様なコンポーネントを含んでもよい。患者モニタリング・システム２５２は、たとえば、一つまたは複数のカメラ２５６とインターフェースをもつ患者捕捉モジュール２５４、患者待ち行列モジュール２５８、患者位置特定器モジュール２６０、動的較正モジュール２６２、顔／胴体取得モジュール２６４、バイタルサイン測定モジュール２６６、悪化検出モジュール２６８、前述のEPSモジュール２７０および一つまたは複数のデータベース２７２、２７４を含みうる。上述のように、モジュール２５０、２５４および２５８〜２７４のそれぞれは、ハードウェアおよびソフトウェアの任意の組み合わせを使って実装されてもよい。また、これらのモジュールは別々に描かれているが、これは限定したり、各モジュールが別々のハードウェアまたはソフトウェアに実装されることを示唆したりすることを意図するものではない。たとえば、一つまたは複数のモジュールが組み合わされたり、および／または省略されたりしてもよく、一つまたは複数のモジュールが、一つまたは複数のコンピュータ・ネットワーク（図示せず）を介して動作可能に接続された一つまたは複数のコンピューティング・システム上に実装されてもよい。図２のさまざまなコンポーネントを接続する線は、これらのコンポーネントにアクセス可能な通信チャネルを表わしていてもよい。これらの通信チャネルは、一つまたは複数のバス、イーサネット（登録商標）、Wi-Fi、Bluetooth（登録商標）、Z-Wave、ZigBee、セルラー通信などのような、いくつもあるネットワーキングまたは他のコンピュータ通信技術を用いて実装されうる。

患者モニタリング・システム２５２は、たとえば、患者からある距離のところから、患者の一つまたは複数のバイタルサインを取得するように構成された一つまたは複数のバイタルサイン取得カメラ２７６をも含んでもよい。そのようなバイタルサイン取得カメラの例を上述した。さまざまな実施形態において、バイタルサイン取得カメラ２７６は、待合室１０４のようなエリアの種々の部分がその視野内に含まれるようにパン、チルトおよびズームするように動作可能なパン‐チルト‐ズーム（「PTZ」）カメラであってもよい。このようにして、モニタリングされるエリアをスキャンして、種々の患者を位置特定することが可能であり、それにより、更新されたバイタルサインが、邪魔にならないように取得されうる。

患者捕捉モジュール２５４は、一つまたは複数のカメラ２５６から、患者の捕捉された画像データを担持する一つまたは複数の信号を受領してもよい。たとえば、いくつかの実施形態では、患者捕捉モジュール２５４は、カメラ２５６からビデオ・ストリームを受領してもよい。患者捕捉モジュール２５４は、患者が存在するときを検出するために、ビデオ・ストリームに対して画像処理（たとえば、顔検出、セグメンテーション、人間の形態を検出するための形状検出など）を実行してもよく、該検出に応答して患者の参照画像を捕捉してもよい。いくつかの実施形態では、参照画像は、ビデオ・ストリームの個々のフレームよりも高い解像度で捕捉されてもよいが、これは必須ではない。いくつかの実施形態では、カメラ２５６は、ウェブカメラ、PTZカメラ（たとえば２７６）などといった、待合室前のエリア１０２の中または近くで配備されるスタンドアローンのカメラであってもよい。カメラ２５６によって捕捉された一つまたは複数の画像は、その後、患者に関連付けられた参照患者画像として使われ、後に、モニタリングされるエリア内の患者を識別するために使用されてもよい。

患者待ち行列モジュール２５８は、たとえば、データベース内の、モニタリングされるエリア内の患者の患者モニタリング待ち行列を確立および／または維持するように構成されてもよい。さまざまな実施形態において、患者モニタリング待ち行列は、さまざまなパラメータによって順序付けられてもよい。いくつかの実施形態において、患者モニタリング待ち行列における患者は、少なくとも部分的には患者緊急度インジケーターに基づいて（すなわち、健康状態に基づく優先順位によって）および／または待ち時間、到着時間などの他のパラメータに基づいてランク付けされてもよい。いくつかの実施形態において、更新されたバイタルサインは、待合室１０４のようなモニタリングされるエリアで待っている患者から、待ち行列の順序で取得されてもよい。他の実施形態では、更新されたバイタルサインは、FIFOまたはラウンドロビン順に患者から取得されてもよい。他の実施形態では、更新されたバイタルサインは、バイタルサイン取得カメラ２７６にプログラムされた所定のスキャン軌跡に対応する順序で、諸患者から取得されてもよい（たとえば、椅子の各列を順にスキャンする）。

患者位置特定器モジュール２６０は、患者捕捉モジュール２５４によって捕捉された一つまたは複数の参照患者画像との関連で、バイタルサイン取得カメラ２７６から受領された一つまたは複数の信号を使用して、モニタリングされているエリア（たとえば待合室１０４）における一または複数の患者を位置特定するように構成されてもよい。患者位置特定器モジュール２６０は、患者のさまざまな視覚的特徴を用いて患者を識別するために、さまざまな画像処理技法を使用してもよい。患者を認識するために使用されうるこれらの視覚的特徴は、顔の特徴、胴体の特徴、衣服、毛髪、姿勢などを含みうるが、これらに限定されない。

いくつかの実施形態において、患者位置特定器モジュール２６０は、更新されたバイタルサインを得るもとになる特定の患者を求めて、モニタリングされるエリアを探索してもよい。たとえば、患者位置特定モジュール２６０は、患者待ち行列モジュール２５８によって同定された患者を求めて、モニタリングされるエリアを探索してもよい。患者待ち行列モジュール２５８によって同定された患者は、たとえば、患者モニタリング待ち行列の先頭の患者であってもよい。いくつかの実施形態において、患者位置特定モジュール２６０は、同定された患者が識別されるまで、バイタルサイン取得カメラ２７６に、モニタリングされているエリア（たとえば待合室１０４）をスキャンさせてもよい。

動的較正モジュール２６２は、バイタルサイン取得カメラ２７６の使用を追跡し、必要に応じてそれらを較正するよう構成されてもよい。たとえば、動的較正モジュール２６２は、バイタルサイン取得カメラ２７６が特定のPTZ位置を指すように命令されるときはいつでも、それが常に同じ位置を指すことを確実にすることができる。PTZカメラは、絶えず、または少なくとも頻繁に動いていてもよい。よって、その機械的コンポーネントは、摩耗を受けることがある。小さな機械的誤差／バイアスが累積し、その結果、バイタルサイン取得カメラ２７６が時間の経過とともに、所与のPTZコマンドに対して異なる仕方で応答をすることがありうる。動的較正モジュール２６２は、たとえば、ランドマーク（たとえば、壁上の小さなステッカーのような印）を用いて、バイタルサイン取得カメラ２７６を適切に応答させる補正機構をトレーニングすることができる較正ルーチンを時折実行することによって、これを是正することができる。

ひとたび患者待ち行列２５８から同定された患者が、患者位置特定モジュール２６０によって認識されると、顔／胴体取得モジュール２６４は、その視野が患者の所望される部分を捕捉するように、一つまたは複数のバイタルサイン取得カメラ２７６をパン、チルトおよび／またはズームするように構成されてもよい。たとえば、いくつかの実施形態では、顔／胴体取得モジュール２６４は、患者の顔および／または胴体に焦点が合わされるように、バイタルサイン取得カメラ２７６をパン、チルトまたはズームしてもよい。追加的または代替的に、顔／胴体取得モジュール２６４は、患者の顔を捕捉するために一つのバイタルサイン取得カメラ２７６をパン、チルト、またはズームし、患者の胴体を捕捉するために別のバイタルサイン取得カメラ２７６をパン、チルト、またはズームしてもよい。次いで、さまざまなバイタルサインが取得されうる。たとえば、患者の脈拍、SpO₂、呼吸数および血圧などのバイタルサインが、たとえば、バイタルサイン測定モジュール２６６によって、バイタルサイン取得カメラ２７６によって捕捉された患者の顔の画像／ビデオに対して画像処理を実行することによって取得されてもよい。患者の呼吸数、全身姿勢（これは疼痛および／または負傷を示すことがある）などといったバイタルサインが、バイタルサイン取得カメラ２７６によって捕捉された患者の胴体の画像／ビデオに対して画像処理を実行することによって、たとえばバイタルサイン測定モジュール２６６によって、取得されてもよい。もちろん、顔および胴体は、バイタルサインを得るために検査されうる身体部分の二つの例にすぎず、限定することは意図されていない。

悪化検出モジュール２６８は、一つまたは複数の信号を分析して、登録された患者の状態が悪化、改善および／または安定のままであるかどうかを判定するように構成されてもよい。いくつかの実施形態において、患者の状態は、少なくとも部分的には、モニタリングのための患者の順序を決定するための上述した同じ患者緊急度インジケーターによって表わされてもよい。よって、悪化検出モジュール２６８は、本稿に記載される一つまたは複数のCDS、症例ベース推論もしくは他の臨床推論アルゴリズム、または、本稿に記載される緊急度インジケーター以外の患者状態指標を評価するための他の臨床推論アルゴリズム（たとえばトレーニングされたロジスティック回帰モデルまたは他の機械学習モデル）を含んでいてもよい。いくつかの実施形態において、悪化検出モジュール２６８によって使用される患者緊急度または患者状態の他の指標を評価するためのアルゴリズムは、たとえば、選択された機械学習モジュールのための新しいトレーニングされた重み（たとえばシータ値）を書くことによって、またはプロセッサによる実行のための新しい命令を（たとえばJava（登録商標）アーカイブ、JAR、ファイルまたはコンパイルされたライブラリの形で）提供することによって、随時更新されてもよい。これらの信号は、たとえば、患者の初期バイタルサインおよび他の生理情報（たとえば、図１のブロック１０８〜１１０で得られたもの）、バイタルサイン測定モジュール２６６によって得られた更新されたバイタルサイン、患者の初期患者緊急度インジケーター（たとえば、トリアージの際に割り当てられる）、および／または患者の更新された患者緊急度インジケーターを含んでいてもよい。これらの信号を使用してなされた判定に基づいて、悪化検出モジュール２６８は、さまざまなアクションを行なうために、さまざまなアラートをさまざまな他のモジュールに送ってもよい。たとえば、悪化検出モジュール２６８は、たとえば、EPSモジュール２７０にアラートを送ることにより、アラートを公開してもよく、それにより、EPSモジュールは、病院情報システム２４０のアラーム・モジュール２４８のような申し込んでいるモジュールに対して該アラートを公開することができる。いくつかの実施形態では、そのようなアラートは、たとえば、患者名（またはより一般的には患者識別子）、画像、待合室における患者の最後に検出された位置、ベースラインのバイタルサイン、一つまたは複数の更新されたバイタルサイン、および／または患者緊急度インジケーターの指示を含んでいてもよい。アラートを受信すると、アラーム・モジュール２４８は、患者の悪化、特に待合室で患者の最後に検出された位置について医療人員に対してアラートまたはアラームを発してもよい。

EPSモジュール２７０は、図２のさまざまな他のコンポーネントによって発された（released）イベントを分配するように構成された一般的な通信ハブであってもよい。いくつかの実施形態では、図２に描かれる他のモジュールの全部または少なくともいくつかは、そのモジュールからの結果／決定／計算／判定の何らかの形を示すイベントを生成しうる。これらのイベントは、EPSモジュール２７０に送られるか、または「公開される」（published）ことができる。図２に描かれる他のモジュールの全部または一部は、他の任意のモジュールから任意のイベントを受信することを選択する、またはかかるイベントに「申し込む」ことができる。EPSモジュール２７０は、イベントを受信すると、イベントを示すデータを、そのイベントに申し込んでいるすべてのモジュールに送ってもよい（たとえばそのイベントを転送する）。

いくつかの実施形態では、EPSモジュール２７０は、データベース２７２および／またはアーカイブ２７４（これは任意的であってもよい）のような一つまたは複数のデータベースと通信してもよい。いくつかの実施形態では、EPSモジュール２７０は、一つまたは複数のデータベース２７２および／または２７４に記憶された情報へのアクセスを提供する、および／または他のモジュールから受領された情報（たとえばアラート）をデータベース２７２および／または２７４に追加するために、任意のモジュールからリモート手続き呼出し（remote procedure call）（「RPC」）を受け入れてもよい。データベース２７２は、図２の一つまたは複数の他のモジュールによって送られる／ブロードキャストされる／送信されるアラート、公開または他の通信に含まれる情報を記憶してもよい。いくつかの実施形態では、データベース２７２は、たとえば、患者に関連する参照画像および／または患者の初期バイタルサイン、更新されたバイタルサイン（バイタルサイン取得カメラ２７６によって取得される）および／または患者緊急度インジケーターを記憶してもよい。任意的なアーカイブ２７４は、いくつかの実施形態では、同じまたは類似の情報をより長い期間にわたって記憶してもよい。

さまざまなハードウェア構成が、患者モニタリング・システム２５２を実装するために利用されうることは明白であろう。たとえば、いくつかの実施形態では、単一の装置が、システム２５２全体を実装してもよい（たとえば、単一のサーバーがカメラ２７６を動作させてバイタル取得機能２６０〜２６６を実行し、悪化検出２６８および待ち行列管理２５８を含むバイタル解析およびアラート機能を実行する）。他の実施形態では、複数の独立した装置がシステム２５２を形成してもよい。たとえば、第一の装置がカメラ２７６を駆動し、機能２６０〜２６６を実装してもよく、一方、別のサーバーが残りの機能を実行してもよい。いくつかのそのような実施形態では、ある装置は待合室にローカルであってもよく、別の装置は遠隔であってもよい（たとえば、地理的に遠隔なクラウド・コンピューティング・アーキテクチャーにおける仮想マシンとして実装される）。いくつかの実施形態では、装置（たとえばプロセッサおよびメモリを含む）がカメラ２７６自体の内部に配置されてもよく、よって、カメラ２７６は、単に単能周辺機器ではなくてもよく、バイタルサイン機能２６０〜２６６を実行してもよい。いくつかのそのような実施形態では、別のサーバーは、さらなる処理のためにバイタルが返されることを要求するために、カメラ２７６に指示（たとえば、識別子、フル・レコード、または登録された顔画像）を提供してもよい。いくつかのそのような実施形態では、追加的な機能がカメラ２７６に搭載されてもよく、たとえば、悪化検出２６８（またはそのための前処理）および／または患者待ち行列２５８の管理がカメラ２７６上で実行されてもよい。いくつかの実施形態では、カメラ２７６が、HISインターフェース２５０またはEPS ２７０までも実装してもよい。さまざまな追加的な構成が明白であろう。

図３は、開示される技法が待合室３０４内の複数の患者３７８Ａ〜３７８Ｃをモニタリングするために実装されうる例示的シナリオを示す。この例では、三人の患者３７８Ａ〜３７８Ｃは、医療人員３８０の診療を受けるために病院待合室３０４で待っている。二つのビデオ・カメラ３７６Ａ、３７６Ｂが、待合室３０４の表面（たとえば、天井、壁）に取り付けられる。二つのビデオ・カメラ３７６Ａ、３７６Ｂは、待合室３０４内の患者３７８をモニタリングするために使用されてもよい。患者３７８Ａ〜３７８Ｃはそれぞれ、予備的な患者状態分析に基づいてトリアージ医療人員（図示せず）により、患者緊急度インジケーターを割り当てられていてもよい。患者３７８が診療する医師を待つ間、二つのビデオ・カメラ３７６Ａ、３７６Ｂが、患者の悪化を検出するために、上述のように患者３７８をモニタリングしてもよい。いくつかの実施形態では、患者に関連付けられた患者緊急度インジケーターが、患者が悪化したことが患者モニタリング・システム（より具体的には、悪化検出モジュール２６８）によって検出されたことに応答して、医療人員によって更新されてもよい。

いくつかの実施形態では、患者３７８の一つまたは複数の更新されたバイタルサインは、ビデオ・カメラ３７６Ａ、３７６Ｂを使って取得されてもよい。追加的または代替的に、バイタルサイン取得カメラ３７６は、患者３７８を、荒いまたは不規則な呼吸などの異常な呼吸パターンについて解析してもよい。呼吸困難を経験している患者をも描く非常に蒼白な皮膚色をもつ患者の画像またはビデオが、たとえば病院情報システム２４０によって記憶された患者の参照画像と比較されて、患者が心臓発作を経験していることを判定してもよい。そのようなシナリオでは、たとえばテキスト・メッセージ、インターホン・アナウンス、ディスプレイ画面上の出力などによって、アラートがすぐに医療人員に送られてもよい。

図３において、第一の患者３７８Ａは血液および尿検査の結果を待つ学生であり、第二の患者３７８Ｂはスポーツ負傷の治療を受けるのを待っており、第三の患者３７８Ｃはいくつかの胃痛に関して医師の診察を受ける必要があるとする。四人目の患者３７８Ｄが、何らかの軽度の呼吸困難のために前から医師の診察を待っていたが、ビデオ・カメラ３７６Ａ、３７６Ｂによって、緊急ケアを正当化するいくつかの症状を示すことが検出されたとする。四人目の患者３７８Ｄの悪化を医療人員に通知するために、音声または視覚的警告のようなアラートが発されてもよい。アラートを受信すると、ケア提供者は患者３７８Ｄの状態を確認しに行く。結果として、救急人員３８０が第四の患者３７８Ｄを救急室３８４に連れて行ってもよく、患者はそこで必要な処置を受ける。ひとたび第四の患者３７８Ｄが救急室３８４に搬送されると、いまだ待合室３０４で順番を待っている患者３７８Ａ〜３７８Ｃのみをモニタリングするよう、患者モニタリング待ち行列が更新されてもよい。

本稿に記載される技法は、病院の待合室に限定されない。本稿に記載される技法が実装されて多様な技術的利点を達成しうる他の多くのシナリオがある。たとえば、開示された技法は、空港、アリーナおよび他の公共の場所における群衆のセキュリティー・モニタリングのためにも使用されうる。そのようなシナリオでは、患者緊急度悪化を判別するために患者をモニタリングするのではなく、リスク測定のような他の型の測定のために個人がモニタリングされてもよい。

もう一つの例として、図４は、開示される技法がジムにおいてどのように実装されうるかを描いている。二つのバイタルサイン取得カメラ４７６Ａ、４７６Ｂは、たとえば運動家４７８Ａ〜４７８Ｂをモニタリングするために使用されることができるように、ジム内の各運動家をモニタリングするために要求されるあらゆる角度をカバーするように戦略的に位置される。トレーニング・インストラクター４８６（たとえば、コーチ、フィットネス・インストラクターまたは理学療法士）は、まず、たとえば、運動家の以前の身体負傷に起因するストレッチ中にその特定の運動家が痛みを感じるかどうかを判定することによって、運動家４７８の身体状態を評価してもよい。第一の運動家４７８Ａが評価に合格すると、トレーニング・インストラクター４８６は、第一の運動家４７８Ａに標準的なトレーニング・レジメンを開始するよう指示してもよい。この例では、第一の運動家４７８Ａが、割り当てられたトレーニング・レジメン――たとえばトレッドミルを使用するもの――を実行するとき、心拍数、呼吸数および体温などのそのバイタルサインが、バイタルサイン取得カメラ４７６Ａ、４７６Ｂによって連続的／定期的にモニタリングされてもよく、それによりたとえば、第一の運動家４７８Ａが運動しすぎているかどうかを判定しうる。

いくつかの実施形態において、モニタリング・プロセスの開始時に、たとえば、第一の運動家４７８Ａが運動のためにジムにはいるとき、二つのバイタルサイン取得カメラ４７６のうちの一つが、たとえば、以前に（たとえば、第一の運動家４７８がジムに入会し、写真IDを受け取ったときに）捕捉された参照画像に基づいて、第一の運動家４７８Ａを識別することができる。バイタルサイン取得カメラ４７６Ａは、心拍数を取得するために、第一の運動家４７８Ａの顔エリアにズームインしてもよい。取得されたバイタルサインは、バイタルサイン取得カメラ４７６Ａによって、さらなる解析のためにコンピューティング装置（図示せず；患者モニタリング・システム２５２の一つまたは複数のコンポーネント）に送信されてもよく、データベース（たとえば２７２、２７４）に記憶されてもよい。取得されたバイタルサインが一定の閾値レベルを超える場合、超えられた閾値についてトレーニング・インストラクター４８６にアラートするための通知が（たとえば、可聴信号または視覚的アラートの形で）生成されてもよい。いくつかの実施形態では、コンピューティング装置は、ストレッチングおよびトレーニング・セッション間の十分な休息のような、第一の運動家４７８Ａによって実行されるべき特定の段階を勧告してもよい。他の運動家、たとえば第二の運動家４７８Ｂに対しても、それぞれの健康状態に応じて同様の技法が適用されてもよい。いくつかの実施形態では、負傷の徴候をモニタリングするよりもむしろ、本稿に記載される技法は、ジムまたは同様の場面において、燃焼カロリーまたは他の生理メトリックを追跡するために使われてもよい。これは、バイタルサイン取得カメラ４７６によって経時的に追跡される、たとえば運動家の動き、体重、温度、脈拍、呼吸数などに基づく。図２のシステムをこの設定に適合させるために、悪化検出モジュール２６８は単に、利用可能なパラメータからカロリー燃焼（または他のメトリック）を導出するためのアルゴリズムを設けられてもよい。いくつかの実施形態では、システムは、たとえば、室内の各人の燃焼カロリーまたは他のメトリックを示す室内の人々に見えるディスプレイのような競争的コンポーネントを含んでいてもよく、表示は可能性としては、燃焼カロリーの高い順または観察された他のメトリックのよい順にランク付けされてもよい。

図５は、待合室、ジムなどのエリアにおける患者などの複数の個人をモニタリングするための例示的な方法５００を示す。便宜上、方法５００の動作のいくつかは、動作を実行するシステムを参照して記述される。このシステムは、さまざまなコンピュータ・システムのさまざまなコンポーネントを含んでいてもよい。たとえば、いくつかの動作は、患者モニタリング・システム２５２の一つまたは複数のコンポーネントによって実行されてもよい。さらに、方法５００の動作は特定の順序で示されるが、これは限定することは意図されていない。一つまたは複数の動作が並べ替え、省略または追加されてもよい。

ブロック５０２では、上述のバイタルサイン取得カメラ（これは上述のように、パン、チルトおよび／またはズームによって調節可能な視野を有していてもよい）の視野において捕捉されることができる待合室などのエリアに位置する複数の個人（たとえば、患者、運動家、ナーシングホームの居住者など）について、（たとえばトリアージ時に）たとえば医療人員から、個々の健康指数（たとえば、患者緊急度インジケーター、運動強度指標、ESIなど）が受領されてもよい。たとえば、さまざまな実施形態において、モニタリングされる領域にはいる前に、一つまたは複数の初期バイタルサインが、たとえばトリアージ看護師またはトレーナーによって、各個人から取得されてもよい。これらの初期のバイタルサインに基づいて、ブロック５０２において、エリア内の各個人について、たとえば医療人員によって、個々の健康指数が決定されてもよい。

ブロック５０４では、システムは、エリア内の個人の待ち行列（たとえば患者待ち行列）を確立（またはすでに存在する場合は更新）してもよい。さまざまな実施形態において、待ち行列は、少なくとも部分的にはブロック５０２で決定された個々の健康指数に基づいて、順序付けおよび／またはランク付けされてもよい。追加的または代替的に、いくつかの実施形態では、待ち行列は、各患者が到着した時刻、各患者がどのくらい長く待っているか、などを含むがこれらに限定されない他のデータ・ポイントに基づいて順序付けられてもよい。

ブロック５０６では、システムは、更新されたバイタルサインが取得されるべき所与の個人を選択してもよい。たとえば、システムは、患者緊急度インジケーターが最も高い患者を選択してもよく、これは、多くの場合、待ち行列における最初の患者でありうる。他の実施形態では、システムは、FIFOおよび／またはラウンドロビンを使用するなど、異なる順序で個人を選択してもよい。

ブロック５０８では、ブロック５０６で選択された個人は、たとえば、その個人の一つまたは複数の参照画像に基づいて、一つまたは複数のバイタルサイン取得カメラ２７６によって、モニタリングされるエリア内で位置特定されてもよい（たとえば、図１のブロック１２０）。上述のように、顔の特徴、姿勢、衣服、サイズなどを含むがこれらに限定されない、個人のさまざまな視覚的特徴が、患者の位置特定のために使用されうる。ブロック５１０では、一つまたは複数のバイタルサイン取得カメラ２７６は、ブロック５０６で選択され、ブロック５０８で位置特定された個人から、一つまたは複数の更新されたバイタルサインを邪魔にならないように取得してもよい。さまざまな実施形態において、個人は、たとえば、トリアージ看護師または他の人員に通知することにより、邪魔にならない取得からオプトアウトしてもよい。

いくつかの実施形態では、ブロック５１２において、ブロック５０６で選択され、ブロック５０８で位置特定された個人における悪化が、ブロック５１０で取得された更新されたバイタルサインと、所与の患者に関連付けられた個々の健康指数（たとえばブロック５０２で決定された）または所与の患者から取得された初期バイタルサイン（または患者モニタリング・システム２５２の以前の反復の際に取得された更新されたバイタルサイン）のうちの少なくとも一方とに基づいて検出されてもよい。たとえば初期バイタルサインと更新バイタルサインとの間の差が閾値を満たすことに起因して悪化が検出される場合、方法５００は、ブロック５１４に進んでもよい。ブロック５１４では、テキスト・メッセージ、インターホン・アナウンス、視覚的出力、オーディオ出力、触覚フィードバックなどを含むがこれらに限定されないさまざまなモダリティーの出力が、前記の差について関係する人員にアラートするために、たとえば患者の悪化について当直看護師に通知するために、提供されてもよい。いくつかの実施形態では、たとえば、医療人員は、（たとえば、医療人員が待合室で誰を探すかを知るように）悪化している患者の最も最近に捕捉された画像または待合室における悪化している患者のライブ・ストリーミング・ビデオを表示することによって、患者の悪化についてアラートされてもよい。方法５００がブロック５１２の後にブロック５１４に進むか否かにかかわりなく、方法５００は、ブロック５０４に戻って、待ち行列を更新し、たとえば、次に高い患者緊急度インジケーターをもつ患者がモニタリングされうるように待ち行列を再順序付けしてもよい。

本稿に記載される例は、バイタルサインの非接触収集を実行するように構成されたカメラのようなバイタルサイン取得カメラに主として関わるものであったが、これは限定することは意図されていない。さまざまな実施形態において、他の型のセンサーがバイタルサイン取得カメラに組み込まれ、および／または患者のバイタルサインを検出するために別個に配備されてもよい。たとえば、モーション・センサーが、たとえば、患者が発作を起こしていることに起因する動きのような待合室における患者の異常な動きを検出するために使われてもよい。赤外線、光学、マイクロ波、超音波、音響、または断層撮影に基づくセンサー、ならびに在室センサーのカテゴリーに該当するセンサーを含むがこれらに限定されない、さまざまな型のモーション・センサーを使用することができる。モーション・センサーは、受動的および／または動的でありうる。受動的赤外線センサーは、たとえば、動く物体によって放射される赤外線放射を検出するよう設計された焦電センサーによって熱移動を検出する。これに対して、超音波センサーは、ドップラー・シフトの原理を利用してもよい。超音波センサーは、モニタリングされる領域において高周波音波を送信し、反射波パターンを検出してもよい。マイクロ波センサーは、音波ではなく高周波のマイクロ波を送信しうる点を除いて、同様の仕方で機能しうる。

図６は、例示的なコンピュータ・システム６１０のブロック図である。コンピュータ・システム６１０は、典型的には、バス・サブシステム６１２を介して多数の周辺装置と通信する少なくとも一つのプロセッサ６１４を含む。本稿で使用されるところでは、用語「プロセッサ」は、たとえばマイクロプロセッサ、FPGA、ASIC、他の同様のデバイスおよびそれらの組み合わせなどの、本稿に記載されるCDSシステムに帰せられるさまざまな機能を実行することができるさまざまなデバイスを包含するものと理解されるであろう。これらの周辺装置は、たとえばメモリ・サブシステム６２５およびファイル記憶サブシステム６２６を含むデータ保持サブシステム６２４と、ユーザー・インターフェース出力装置６２０と、ユーザー・インターフェース入力装置６２２と、ネットワーク・インターフェース・サブシステム６１６とを含んでいてもよい。入出力装置は、コンピュータ・システム６１０とのユーザー対話を許容する。ネットワーク・インターフェース・サブシステム６１６は、外部ネットワークへのインターフェースを提供し、他のコンピュータ・システム内の対応するインターフェース・デバイスに結合される。

ユーザー・インターフェース入力装置６２２は、キーボード、マウス、トラックボール、タッチパッドまたはグラフィックス・タブレットのようなポインティングデバイス、スキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンおよび／または他の型の入力装置などのオーディオ入力装置を含んでいてもよい。一般に、用語「入力装置」の使用は、コンピュータ・システム６１０または通信ネットワーク上に情報を入力するための可能なあらゆる型の装置および方法を含むことが意図されている。

ユーザー・インターフェース出力装置６２０は、ディスプレイ・サブシステム、プリンター、ファクシミリ機またはオーディオ出力装置のような非視覚的ディスプレイを含むことができる。表示サブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）のようなフラットパネル装置、投影装置または可視画像を生成するための他の何らかの機構を含みうる。前記ディスプレイ・サブシステムはまた、オーディオ出力装置を介してなど、非視覚的ディスプレイをも設けてもよい。一般に、「出力装置」という用語の使用は、コンピュータ・システム６１０からユーザーまたは別の機械もしくはコンピュータ・システムに情報を出力するためのあらゆる可能な型の装置および方法を含むことが意図されている。

データ保持システム６２４は、本稿に記載されるモジュールの一部または全部のモジュールの機能を提供するプログラミングおよびデータ構造体を記憶する。たとえば、データ保持システム６２４は、方法５００の選択された諸側面を実行する、および／または患者モニタリング・システム２５２の一つまたは複数のコンポーネントを実装する論理を含んでいてもよい。

これらのソフトウェア・モジュールは、一般に、プロセッサ６１４単独によって、または他のプロセッサとの組み合わせで、実行される。記憶サブシステムにおいて使用されるメモリ６２５は、プログラム実行中に命令およびデータを記憶するためのメイン・ランダムアクセスメモリ（RAM）６３０、固定した命令が記憶されるリードオンリーメモリ（ROM）６３２および命令／データ・キャッシュ（追加的または代替的に少なくとも一つのプロセッサ６１４と一体であってもよい）のような他の型のメモリを含むいくつかのメモリを含むことができる。ファイル記憶サブシステム６２６は、プログラムおよびデータ・ファイルのための持続的記憶装置を提供することができ、ハードディスクドライブ、関連のリムーバブル媒体と一緒のフロッピーディスクドライブ、CD-ROMドライブ、光学式ドライブまたはリムーバブル媒体カートリッジを含んでいてもよい。ある種の実装の機能を実装するモジュールは、ファイル記憶サブシステム６２６によってデータ保持システム６２４に、またはプロセッサ６１４によってアクセス可能な他のマシンに記憶されてもよい。本稿で使用されるところの用語「非一時的なコンピュータ読取り可能媒体」は、揮発性メモリ（たとえばDRAMおよびSRAM）および不揮発性メモリ（たとえばフラッシュメモリ、磁気記憶装置および光学式記憶装置）の両方を包含するが、一時的な信号を除外することが理解されるであろう。

バス・サブシステム６１２は、コンピュータ・システム６１０のさまざまなコンポーネントおよびサブシステムが意図したように互いと通信するようにする機構を提供する。バス・サブシステム６１２は、単一のバスとして概略的に示されているが、バス・サブシステムの代替的な実装は複数のバスを使用してもよい。

コンピュータ・システム６１０は、ワークステーション、サーバー、計算クラスター、ブレードサーバー、サーバーファームまたは他の任意のデータ処理システムもしくはコンピューティング装置を含むさまざまな型であることができる。いくつかの実施形態では、コンピュータ・システム６１０は、クラウド・コンピューティング環境内に実装されてもよい。コンピュータおよびネットワークの絶えず変化する性質のため、図６に描かれるコンピュータ・システム６１０の記述は、いくつかの実装を例解するための特定の例としてのみ意図される。図６に描かれるコンピュータ・システムよりも多数または少数のコンポーネントを有する、コンピュータ・システム６１０の他の多くの構成が可能である。

図７は、本稿に記載されるさまざまな実施形態で使用されうるバイタルサイン取得カメラ７７６の第一の実施形態の概略図を示す。電磁放射７８２、特に可視波長および赤外波長範囲の光が、患者などの生体７８４から反射され、前記カメラ７７６によって受信され、評価されて、生体７８４の生体計測信号７９８を生成する。カメラ７７６は、実質的に550nmまで、および／または約600nmまで、および／または650nmまでの波長範囲で、入射電磁放射７８２内の入射可視光をブロックするためのフィルタ７８６を含んでいてもよい。次いで、フィルタリングされた入射光７８８は、少なくとも二つの異なる色信号７９２_A、７９２_Bを生成する色センサー７９０によって、たとえば二つの別個の色検出器７９３、７９４（またはそのような色検出器のアレイ）の使用によって、検知される。結合ユニット７９５は、たとえば線形結合によって、前記色信号７９２_A、７９２_Bを組み合わせることによって、少なくとも一つの結合色信号７９６を生成する。最後に、処理ユニット７９７が、前記結合色信号７９６を処理し、生体７８４の少なくとも一つの生体計測信号７９８を抽出するために設けられる。結合ユニット７９５および処理ユニット７９７は、いくつかの実施形態では、共通のプロセッサ７９９によって、たとえばプロセッサの処理要素として実現されてもよく、あるいは従来のプロセッサ上のソフトウェアにおいて実装されてもよい。しかしながら、それらは異なる仕方で、たとえば専用のハードウェア要素として実現されてもよい。

図８は、本稿に記載されるさまざまな実施形態で使用され得るカメラ８７６’の第二の実施形態を概略的に示す。図８は、任意的に、（このおよび／または他の実施形態において）追加的なフィルタ８８６’が設けられてもよいことを示している。フィルタ８８６’は、色センサー８９０に到達する前に、少なくとも1100nmより上、特に少なくとも1000nmより上の波長範囲内の入射光をブロックするように構成される。一般に、これらの色センサー、たとえばイメージング・シリコン・センサーは、より長い波長に向かって自然に減少する感度を示すが、そのような追加的なフィルタ８８６’は、上述の上限閾値波長よりも上のフィルタリングされる入射光８８８内の信号寄与がブロックされる、すなわち、水吸収が支配的になる信号寄与が、二回フィルタリングされた入射光８８８’内ではブロックされることを保証し得る。

さらに、この実施形態では、色センサー８９０は、たとえば、光検出器８９５（より一般にはイメージセンサー）の前に設けられた三つの異なる色フィルタ領域を有する色フィルタ・アレイ８９３の使用によって、三つの異なる色信号８９２_A、８９２_B、８９２_Cを生成する。そのような色センサー（たとえば、二つの色フィルタ領域のみを有する色フィルタ・アレイを含む）は、図７に示される実施形態においても使用されることができる。いくつかの実施形態では、色センサー８９０は、RGB色センサーによって従来から提供されるような、赤色信号８９２_A、緑色信号８９２_Bおよび青色信号８９２_Cを生成する色フィルタ・アレイを含んでもよい。これら三つの色信号８９２_A、８９２_B、８９２_Cから、結合ユニット８９５は、前記三つの色信号８９２_A、８９２_B、８９２_Cのうちの少なくとも二つの色信号の二つの異なる組み合わせ、特に線形結合を作ることによって、二つの組み合わされた色信号８９６_A、８９６_Bを生成する。これら二つの組み合わされた色信号８９６_A、８９６_Bから、処理ユニットは、次いで、最終的に、生体８８４からの所望の生体計測信号８９８を抽出する。

図９は、さまざまな実施形態に基づく、バイタルサイン取得カメラ（たとえば２７６、３７６、４７６、７７６、８７６）を用いてモニタリングされる患者の優先順位付けされた患者待ち行列を確立し、維持するための例示的方法９００を示す。方法９００の動作は特定の順序で描かれるが、これは、限定することを意図したものではない。さまざまな実施形態において、一つまたは複数の動作が追加、省略および／または順序変更されてもよい。いくつかの実施形態では、方法９００の一つまたは複数の動作（および／または図１０および図１１に描かれる動作）は、たとえば、図１のブロック１１８（および／または図５のブロック５０６）でモニタリングされる患者を同定することの一部として、患者待ち行列モジュール２５８によって実行されてもよい。

ブロック９０２において、現在の患者待ち行列が確立されてもよい。いくつかの実施形態では、現在の患者待ち行列は、群衆モニタリング・データベース（図２における「CMD」）２７８から得ることができる。たとえば、群衆モニタリング・データベース２７８は、患者が登録するおよび／またはトリアージされる際に患者データを入れられてもよい。優先順位待ち行列からのデータが失われる場合、それは、群衆モニタリング・データベース２７８からのデータを使って、再びデータを入れられてもよい。いくつかの実施形態では、群衆モニタリング・データベース２７８は、単にデータベース２７２の一部であってもよい。

追加的または代替的に、患者待ち行列は、新規患者が登録されるおよび／またはトリアージされる際に、オンザフライで生成されてもよい。患者待ち行列は、さまざまなデータ・ポイントに基づいて優先順位付け（または「ランク付け」）されてもよい。たとえば、いくつかの実施形態では、患者待ち行列は、少なくとも部分的には、複数の患者に関連付けられた患者緊急度インジケーターに（直接的または間接的に）基づいて優先順位付けされてもよい。ESIが患者緊急度インジケーターとして用いられるとする。より緊急の患者、すなわち、より低いESIをもつ患者は、一般的にそれほど緊急でない患者よりも頻繁にモニタリングされてもよい。しかしながら、もし患者がESIのみに基づいて患者待ち行列において優先順位付けされるならば、最も緊急でない患者は、恒常的に患者待ち行列の後ろに移され（たとえば、新しい、より緊急の患者が次々にはいってくる場合）、決してモニタリングされない（あるいは少なくとも、許容できないほど低頻度でモニタリングされる）おそれがあるかもしれない。

よって、すべての患者が許容可能な頻度でモニタリングされることを確実にするために、いくつかの実施形態では、患者待ち行列は、患者がモニタリングされるべき、いわゆる「次のスケジュールされた時間」に少なくとも部分的には基づいて、直接的に優先順位付けされてもよい。これらの「次のスケジュールされた時間」は、一つまたは複数のバイタルサイン取得カメラ２７６によってモニタリングするために、患者待ち行列から患者が「送付される」〔ディスパッチされる〕べき（または送付されると予測される）将来の時刻でありうる。患者が次のスケジュールされた時間にモニタリングされることは必須ではない。モニタリング資源――たとえば一つまたは複数のバイタルサイン取得カメラ――が、患者の次のスケジュールされた時間よりも早く患者をモニタリングするために利用可能である場合（すなわち、患者待ち行列内でその患者より前のすべての患者がモニタリングされ終わっている場合）、その患者は、スケジュールされた時刻よりも先にモニタリングされてもよい。同様に、前記一つまたは複数のバイタルサイン・カメラがスケジュールより遅れる場合、たとえ実際のモニタリング時間が次のスケジュールされた時間よりも遅くても、患者たちは待ち行列内の順序でモニタリングされてもよい。もちろん、「モニタリングのための次のスケジュールされた時間」以外の他のメトリックが代わりに使用されてもよい。たとえば、数値（またはアルファベット）の優先度スコアまたはランクなどである。

図９に戻って参照すると、さまざまな実施形態において、ブロック９０２で確立された患者待ち行列は、たとえば、患者モニタリング・システム２５２の他のモジュールとは独立して患者待ち行列モジュール２５８によって実行されるおかげで、比較的独立に維持され、操作されてもよい。患者モニタリング・システム２５２の一つまたは複数の他のコンポーネント、たとえば、バイタルサイン取得カメラ（単数または複数）２７６がフリーズするまたは他の仕方で不具合を起こす場合、患者待ち行列モジュール２５８が、モニタリングするために次の患者を送付する〔ディスパッチする〕（dispatch）（たとえばその識別子を公開する）できることが有益でありうる。よって、ブロック９０４において、ウォッチドッグ・タイマーが、所定の時間間隔に設定されてもよい。この所定の時間間隔は任意の時間の長さであってよい。いくつかの実施形態では、所定の時間間隔は、二人の異なる患者からの更新されたバイタルサインを取得することの間に通例必要とされる典型的な時間の長さ（たとえば、平均、中央値など）よりも長い時間の長さ、または二人の異なる患者のモニタリングの間で許容される最大の時間の長さよりもわずかに長い時間の長さとして選択されてもよい。いくつかの実施形態では、ウォッチドッグ・タイマーに関連する所定の時間間隔は、モニタリングされる患者の数、利用可能なバイタルサイン取得カメラの数などに基づいて選択および／または変更されてもよい。

ブロック９０６において、患者待ち行列の先頭（これは待ち行列の「論理的な」先頭であり、必ずしもメモリ位置のシーケンスにおける最初である必要はない）にある患者が、モニタリングのために送付されてもよい。本明細書で使用される「送付」（dispatch）とは、必ずしも患者または医療人員による何らかの意図的な行動を指すわけではない。むしろ、本明細書で使用される「ディスパッチ」とは、患者の識別情報が他のコンポーネントに提供されることをいい、それにより、該他のコンポーネントは、更新されたバイタルサインが患者から獲得されるようにすることができる。たとえば、患者待ち行列モジュール２５８は、患者待ち行列の先頭の患者に関連付けられた識別子をEPSモジュール２７０に公開することによって、患者を送付してもよい。次いで、EPSモジュール２７０は、そのような通知に申し込んでいる図２の他の任意のモジュール（たとえば、患者位置特定器モジュール２６０）に識別子を公開してもよい。いくつかの実施形態では、患者待ち行列モジュール２５８は、待合室におけるその患者の最後の知られている位置（たとえば、患者位置特定器モジュール２６０が患者を位置特定するための補助として）、参照画像（たとえば、画像自体または画像へのリンク／ポインタ）などといった他の情報も提供してもよい。

ブロック９０８では、患者待ち行列モジュール２５８は、イベントを待ち、たとえばEPSモジュール２７０からイベントが到着するにつれて該イベントを処理してもよい。患者待ち行列モジュール２５８に提供されうるイベントの一例は、患者待ち行列内のいずれかの患者から更新されたバイタルサインが最後に邪魔にならないように取得されて以来、ブロック９０４において設定されたウォッチドッグ・タイマーに関連する前記所定の時間間隔が経過したことの判別である。このことは、たとえば、バイタルサイン取得カメラ（単数または複数）および／または別のモジュール（たとえば２６０、２６２、２６４、２６６）がフリーズした、または他の仕方で不具合を起こしたことを示唆しうる。そのようなシナリオでは、待ち行列の先頭にいる患者が患者待ち行列から再選択され、モニタリングのために他のコンポーネント（たとえば、患者位置特定器モジュール２６０）に提供されてもよい。いくつかの実施形態では、患者がモニタリングされることができる前にウォッチドッグが複数回期限切れになる場合、たとえば、EPSモジュール２７０からの通知に応答してアラーム・モジュール２４８によって、患者モニタリング・システム２５２の一つまたは複数のコンポーネントに問題があるというアラートが発されてもよい。他方、患者が正常にモニタリングされる（または少なくとも患者をモニタリングする試みがなされる）場合には、ウォッチドッグ・タイマーはリセットされてもよい。

図１０は、ブロック９０８で処理されうる多様な他のイベントを描いている。たとえば、患者追加イベント１０２０は、新規患者が登録されるおよび／またはトリアージされたときに生じてもよい。そのような場合、ブロック１０２２において、新規患者が、たとえば該新規患者に関連付けられた患者緊急度インジケーターに少なくとも部分的には（たとえば直接的または間接的に）基づいて選択された位置で、患者待ち行列に追加されてもよい。患者を患者待ち行列に追加するまたは待ち行列に入れ直す例示的な方法が図１１に描かれている。

患者解放イベント１０２４は、たとえば、患者が救急治療室または他のところに治療されるために連れて行かれたため、または患者が、たとえば具合がよくなったことを医療人員に通知した後に、自身の意志で待合室を離れるため、患者が解放されるときに生じてもよい。そのような場合、その患者はブロック１０２６において待ち行列から除去されてもよい。いくつかの実施形態では、待ち行列から患者を除去することは、解放された患者が他の患者待ち行列変更が実行されるときに考慮されないよう、解放された患者に関連するエントリー（たとえばメモリ位置）を削除することを含んでいてもよい。

患者緊急度インジケーターへの変化イベント１０２８は、患者に関連する患者緊急度インジケーターが変化したときに生じうる。たとえば、医療人員は、たとえば（バイタルサイン取得カメラ２７６によって得られた更新されたバイタルサインに基づく）患者が悪化していることの判別に応答して、再検査するおよび／またはその患者と会話をもつことができる。患者の悪化は、必ずしも救急治療室での即座の治療を正当化するのではないことがあるが、患者の患者緊急度インジケーターが変化した可能性があり、より頻繁な（または場合によってはより低頻度の）モニタリングが正当化される。そのような場合、ブロック１０３０において、患者は、新しい患者緊急度インジケーターに基づいて、待ち行列に入れ直され（re-queued）てもよい。そのような患者を待ち行列に入れ直すことは、図１１に描かれる方法１１００と同様の仕方で実行されてもよい。

患者イベント発見不能イベント１０３２は、患者位置特定モジュール２６０が、バイタルサイン取得カメラ２７６を使用して、送付された患者を位置特定することができないときに生じうる。たとえば、患者がスタッフに知らせずに去ったことがありえ、あるいは患者がトイレに行ったか、他の事情で出て行ったことがありうる。そのような場合、いくつかの実施形態では、たとえば、図１１に描かれるのと同様の動作を実行することによって、位置特定されなかった患者がブロック１０３４において待ち行列に入れ直されてもよい。

いくつかの実施形態では、位置特定されなかった患者をブロック１０３４において待ち行列に入れ直すことは、送付サブルーチン１０７０をトリガーしうる。送付サブルーチン１０７０のブロック１０７２において、これがその患者を位置特定しようとする第二の（またはより多い回数目の）試みであるかどうかが判定されてもよい。答えが「イエス」であれば、１０７４においてアラートが発されてもよい。たとえば、当直看護師または他の医療人員が、たとえばディスプレイ画面、可聴アラート、ページ、テキスト・メッセージなどにより、患者が見つからないことを通知されてもよい。ブロック１０７４においてアラートが生じるかどうかにかかわらず、送付サブルーチン１０７０のブロック１０７６において、待ち行列の先頭の患者（前記のみつからない患者は、ブロック１０３４で待ち行列に入れ直され、よって、もはや患者待ち行列の先頭ではない）が、モニタリングのために送付されてもよい。いくつかの実施形態では、上述のウォッチドッグ・タイマーは、次いで送付サブルーチンのブロック１０７８においてリセットされてもよい。

モニタリング完了イベント１０３６は、患者モニタリング・システム２５２のバイタルサイン測定モジュール２６６が、一つまたは複数のバイタルサイン取得カメラ２７６を動作させて、成功裏に、更新されたバイタルサインを得ることができるときに生じうる。患者が悪化していないとすると、患者は、図１１に描かれるのと同様の仕方で、待ち行列に入れ直されてもよい（１０３８）。患者の患者緊急度インジケーターが変化していない場合、いくつかの実施形態では、患者の、モニタリングのための次のスケジュールされた時間は、以前と同様の時間間隔として将来に向かって投影されてもよい。図１０に示されるように、次いで、ブロック１０７６から始まる送付サブルーチン１０７０がトリガーされてもよい。

モニタリング失敗イベント１０４０は、患者モニタリング・システム２５２のバイタルサイン測定モジュール２６６が、一つまたは複数のバイタルサイン取得カメラ２７６を動作させて、送付された患者から更新されたバイタルサインを得ることができないときに生じうる。そのような場合、患者はブロック１０４２で待ち行列に入れ直されてもよい。同様に、モニタリング部分的失敗イベント１０４４は、患者モニタリング・システム２５２のバイタルサイン測定モジュール２６６が、一つまたは複数のバイタルサイン取得カメラ２７６を動作させて、送付された患者から更新されたバイタルサインを得ることが部分的にしか成功できないときに生じうる。たとえば、バイタルサイン取得カメラ２７６が、三つの異なるバイタルサインを取得するように構成されているが、一つまたは二つのバイタルサインだけをなんとか取得する場合、モニタリングは、部分的な失敗とみなされてもよい。そのような場合、患者はブロック１０４６で待ち行列に入れ直されてもよい。図１０に示されるように、患者がブロック１０４２または１０４６で待ち行列に入れ直されるかどうかにかかわらず、次いで、ブロック１０７６から始まる送付サブルーチン１０７０がトリガーされてもよい。

いくつかの実施形態では、特定の患者を待ち行列に入れ直されるとき、該特定の患者をモニタリングするための次のスケジュールされた時間は、少なくとも部分的には、最も最近のモニタリング試行が失敗したかどうかに基づいて計算されてもよい。たとえば、特定の患者がうまくモニタリングされた（すなわち、更新されたバイタルサインが、ブロック１０３６においてバイタルサイン取得カメラ２７６によってうまく取得された）とする。いくつかの実施形態では、その特定の患者の、モニタリングのための次のスケジュールされた時間は、たとえば、特定の患者の患者緊急度インジケーターに関連する値（たとえば分単位）に現在の時間を加えることによって計算されてもよい。しかしながら、モニタリングが部分的（１０４４）または完全に失敗した（１０４０）場合は、その特定の患者の、モニタリングのための次のスケジュールされた時間を早めることが有益でありうる。たとえば、いくつかの実施形態では、モニタリングの試みが完全に失敗した後の患者のモニタリングのための次のスケジュールされた時間は、最小の時間間隔（たとえば5分）に設定されてもよく、または成功裏のモニタリング後にあったであろう患者の次のスケジュールされたモニタリング時間の比較的小さな割合として設定されてもよい。同様に、モニタリングの試みが部分的に失敗した後の患者の、モニタリングのための次のスケジュールされた時間は、成功裏のモニタリング後にあったであろう患者の次のスケジュールされたモニタリング時間よりは短い時間間隔（たとえばその時間の半分）に設定されてもよいが、可能性としては、完全なモニタリング失敗後にあったであろう患者の次のスケジュールされたモニタリング時間よりは長い。

ウォッチドッグ・タイマー満了イベント１０４８は、前記ウォッチドッグ・タイマーが期限切れになったとき、バイタルサイン取得カメラ２７６を用いて患者から、更新されたバイタルサインを取得する何らかの新たな試みがなされる前に、生じうる。上記のように、そのような場合、最後に送付された患者（すなわち「現在の患者」）は、ブロック１０５０において再送付されてもよく、たとえば、送付サブルーチン１０７０のブロック１０７６に動作を送り戻す。

図１１は、たとえば、図１０のブロック１０３８において、成功裏にモニタリングされた患者（図１１の文脈では、「モニタリングされた患者」と称される）を待ち行列に入れ直すための例示的方法１１００を示している。上記のように、新規患者を追加するため、ならびに他の患者、たとえば、モニタリングが不成功だったおよび／または部分的にモニタリングされた患者を待ち行列に入れ直すために同様の技法が実行されてもよい。ただし、次のスケジュールされた時間は、上述のように異なって計算されてもよい。方法１１００の動作は特定の順序で描かれているが、これは限定することは意図されていない。さまざまな実施形態において、一つまたは複数の動作は、順序変更、追加および／または省略されてもよい。

ブロック１１０２では、たとえば、モニタリングされる患者の情報（たとえば患者識別子、患者緊急度インジケーター、次のモニタリングするためのスケジュールされた時間、待合室における最後の既知の位置など）を入れられる一つまたは複数のメモリ位置を割り当てる（たとえば新たなデータベース・レコードをインスタンス生成する）ことによって、新しい待ち行列エントリーが生成されてもよい。さらに、モニタリングされた患者の情報（完了したばかりの成功裏のモニタリングをトリガーしたもの）を以前に含んでいた待ち行列エントリーは、待ち行列から除去されてもよい。ブロック１１０４において、ブロック１１０２において待ち行列から除去された古い待ち行列エントリーの内容が、新しく生成された待ち行列エントリーにコピーされてもよい。他の実施形態では、患者待ち行列に新しいエントリーを追加して古いエントリーを除去する代わりに、待ち行列の同じエントリー（たとえば同じメモリ位置および／またはデータベース・エントリー）が再利用されてもよい。

ブロック１１０６において、前記モニタリングされた患者をモニタリングするための次のスケジュールされた時間は、少なくとも部分的には、モニタリングされた患者の患者緊急度インジケーターに基づいて計算および／または更新されてもよい。患者がモニタリングされるべき次のスケジュールされた時間がどのように計算されうるかの限定しない例が図１２に描かれている。図１２は、例示的な患者待ち行列と、現在の時間（14:21）と、患者緊急度インジケーター（この例ではESIスコア）とモニタリングされるべき次のスケジュールされた時間として使用されるべき対応する時間間隔（たとえば分単位）との間の関連付けを描く表とを描いている。たとえば、ESIスコアが5の患者は「緊急でない」と見なされてもよく、よって、頻繁にモニタリングされる必要がないかもしれない。よって、そのような患者には、現在の時刻から30分であるモニタリングのための次のスケジュールされた時刻を割り当てることができる。対照的に、ESIスコアが2の患者は「緊急」と見なされてもよく、よって、より頻繁にモニタリングする必要があるかもしれない。よって、そのような患者には、現在の時刻から5分であるモニタリングのための次のスケジュールされた時刻を割り当てることができる。上述のように、いくつかの実施形態では、患者をモニタリングする前回の試みが不成功であったかまたは部分的成功であったたかに依存して、患者をモニタリングするための次のスケジュールされた時間は異なる仕方で計算されることができる。たとえば、図１２の表に描かれている時間は、部分的にモニタリングされた患者については半分にされてもよく（または他の仕方で短縮されてもよく）、モニタリングが不成功であった患者についてはさらに短縮されてもよい。もちろん、これらの短縮は、遡及的な解析、状況、選好および／または他の因子に基づいて調整可能であってもよい。

図１１に戻って参照するに、ブロック１１０８において、モニタリングのための次のスケジュールされた時間が、前記モニタリングされた患者をモニタリングするための次のスケジュールされた時間以上である患者待ち行列における最初のエントリーが識別されてもよい。ブロック１１１０では、それらの次のスケジュールされた時間が等しいかどうかが判定されてもよい。答えがノーである場合（すなわち、前記モニタリングされた患者についての次のスケジュールされた時間が、ブロック１１０８で識別されたエントリーについての、次のスケジュールされた時間よりも早い場合）、方法１１００はブロック１１１２に進んでもよい。ブロック１１１２では、モニタリングされた患者に関連する新しいエントリーは、ブロック１１０８において識別されたエントリーの前で、患者待ち行列に挿入されてもよい。次いで、方法１１００は終了してもよい。しかしながら、ブロック１１１０における答えが「イエス」である場合には、方法はブロック１１１４に進んでもよい。

ブロック１１１４では、モニタリングのための同じ次のスケジュールされた時間を有するが、前記モニタリングされた患者よりも患者緊急度インジケーターが小さい、患者待ち行列内の次のエントリーが識別されてもよい。この文脈における「より小さい」は、激しさ／緊急性がより低いことを意味するので、ESIが患者緊急度インジケーターとして使用される実施形態では、「より低い緊急度」は実際には「より高いESIスコア」を意味する。次いで、方法１１００はブロック１１１２に進み、モニタリングされた患者の新しい待ち行列エントリーが、ブロック１１１４で識別されたエントリーの前で、患者待ち行列に挿入される。

図１２の左側の患者待ち行列は、複数の患者が、モニタリングされるべき次のスケジュールされた時間によって、どのように優先順位付けされうるかの例を描いている。上記のように、これらの次のスケジュールされた時間は、少なくとも部分的には、患者緊急度インジケーターまたは図１２ではESIスコアに基づいて計算されていてもよい。よって、より大きな緊急度（すなわち、図１２ではより低いESIスコア）をもつ患者は、患者待ち行列の前方（先頭）のほうに分布する傾向がある一方、より緊急性の低い患者は後ろ（末尾）のほうに分布する傾向があることが観察できる。しかしながら、図１１の方法１１００のような方法を用いることによって、低リスク患者であっても、高リスク患者ほど頻繁ではないにしても、少なくとも定期的にモニタリングされることを確実にすることが可能である。たとえば、患者1452は、ESIスコアが4であるが、それにもかかわらず、モニタリングに関して二番目である。

上記のように、いくつかの実施形態では、図１２に描かれる次のスケジュールされた時間は、必ずしも束縛するものではないことがある。待ち行列の先頭の患者をモニタリングするための次のスケジュールされた時間より前に、一つまたは複数のバイタルサイン取得カメラ２７６が利用可能になる場合、患者待ち行列モジュール２５８は、先に進んで、待ち行列の先頭の患者を、たとえば患者位置特定器モジュール２６０に送付することができる。複数のバイタルサイン取得カメラが利用可能ないくつかの実施形態では、複数の患者が患者待ち行列から同時におよび／または並行して送付されてもよい。たとえば、待ち行列の先頭の患者は、以前に送付された患者のモニタリングが完了する前に、患者待ち行列から送付されてもよい。もう一つの例として、二人の患者が同時に送付され、一方は第一のバイタルサイン取得カメラ２７６によってモニタリングされ、他方は第二のバイタルサイン取得カメラ２７６によってモニタリングされてもよい。あるいはまた、このシステムは、カメラの視野内のN人の患者を同時に処理（識別、測定）することができてもよい。その場合、待ち行列の先頭からの患者が処理されていて、N−1人までの患者が視野にいるとき、待ち行列は、この同時処理を反映するように更新されてもよい。

いくつかの実施形態が本願に記載され図示されているが、当業者は、機能を実行するおよび／または本明細書に記載される結果および／または利点の一つもしくは複数を得るための、多様な他の手段および／または構造を容易に構想するであろう。そのような変形および／または修正の各々は、本明細書に記載される実施形態の範囲内にあると見なされる。より一般的には、当業者は、本明細書に記載されるすべてのパラメータ、寸法、材料および構成が例示的であることが意味されており、実際のパラメータ、寸法、材料および／または構成は、教示が使用される特定の用途（単数または複数）に依存することを容易に理解するであろう。当業者は、本明細書に記載する個別的な実施形態への多くの等価物を認識するか、または高々日常的なを用いて確かめることができるであろう。よって、上述の実施形態は単に例として呈示されており、添付の請求項およびその等価物の範囲内で、実施形態が、具体的に記載され、特許請求される以外の仕方で実施されうることは理解される。本開示の発明的実施形態は、本明細書中で記載されたそれぞれの個別の特徴、システム、物品、材料、キットおよび／または方法に向けられる。さらに、二つ以上のそのような特徴、システム、物品、材料、キットおよび／または方法の組み合わせは、もしそのような特徴、システム、物品、材料、キットおよび／または方法が相互に矛盾するものでなければ、本開示の範囲内に含まれる。

本明細書中で定義され、用いられるあらゆる定義は、辞書の定義、参照により組み込まれた文書における定義および／または定義された用語の通常の意味よりも優先することが理解されるべきである。

本願の明細書および特許請求の範囲において使われる不定冠詞「a」および「an」は、そうでないことが明瞭に示されるのでない限り、「少なくとも一つ」を意味することが理解されるべきである。

本願の明細書および特許請求の範囲において使われる句「および／または」は、そのように連結された要素、すなわち、いくつかの場合には同時に存在し、他の場合には一方のみが存在する要素の「いずれかまたは双方」を意味すると理解されるべきである。「および／または」を用いて挙げられる複数の要素は同じように、すなわち、そのように連結された要素の「一つまたは複数」と解釈されるべきである。任意的に、「および／または」節によって具体的に特定された要素に以外の要素が任意的に存在していてもよく、具体的に特定された要素に関係していてもいなくてもよい。このように、限定しない例として、「Aおよび／またはB」への言及は、「含む」のようなオープンエンドの言辞との関連で使われるときは、ある実施形態ではAのみ（任意的に、B以外の要素を含む)を；もう一つの実施形態ではBのみ（任意的に、A以外の要素を含む）を；さらにもう一つの実施形態ではAおよびBの両方（任意的に、他の要素を含む）；などをいうことができる。

本願で明細書および特許請求の範囲において使われるところでは、「または」は上記で定義した「および／または」と同じ意味を有すると理解されるべきである。たとえば、リスト中で項目を分離するときに、「または」または「および／または」は、包含的である、すなわち、いくつかのもしくはリストの要素の、二つ以上をも含め少なくとも一つを含み、任意的にはリストにない追加的な項目をも含むと解釈されるべきである。「…の一つのみ」または「…のちょうど一つ」、あるいは請求項で使われるときの「…からなる」など、そうでないことが明瞭に示された用語のみが、いくつかの要素またはリストの要素のちょうど一つの要素を含むことをいう。一般に、本明細書において使用される「または」という用語は、排他的選択肢（すなわち、一方または他方であるが両方ではない）を示すものと解釈されるのは、「いずれか一つ」、「…の一つ」、「…の一方のみ」または「…のちょうど一つ」のような排他性の用語を伴うときのみである。請求項において使用されるときの「本質的には…からなる」は、特許法の分野において使用される通常の意味を有する。

本願で明細書および特許請求の範囲において用いられるところでは、一つまたは複数の要素のリストに言及しての句「少なくとも一つ」は、要素のリスト中のいずれか一つまたは複数の要素から選択される少なくとも一つの要素を意味すると理解されるべきであるが、必ずしも要素のリスト内に具体的に挙げられている一つ一つの要素の少なくとも一つを含むとは限らず、要素のリスト中の要素のどんな組合せも排除しない。この定義は、具体的に特定された要素に関連するかまたは関連しないかを問わず、句「少なくとも一つ」が言及する要素のリスト内で具体的に特定された要素以外の要素が任意的に存在していてもよいことをも許容する。このように、限定しない例として、「AおよびBのうちの少なくとも一つ」（または、等価だが、「AまたはBの少なくとも一つ」、または等価だが、「Aおよび／またはBの少なくとも一つ」）は、ある実施形態では、任意的には二つ以上を含む少なくとも一つAであって、Bは存在しない（任意的に、B以外の要素を含む）こと；もう一つの実施形態では、任意的には二つ以上を含む少なくとも一つBであって、Aは存在しない（任意的に、A以外の要素を含む）こと；さらにもう一つの実施形態では、任意的には二つ以上を含む少なくとも一つAおよび任意的には二つ以上を含む少なくとも一つB（任意的に、他の要素を含む）；などをいう。

また、そうでないことが明瞭に示されているのでない限り、二つ以上の段階または工程を含む本願で特許請求されるいずれの方法においても、該方法の段階または工程の順序は、必ずしも該方法の段階または工程が記載される順序に限定されないことも理解されるべきである。

特許請求の範囲ならびに上記の明細書において、「有する」、「含む」、「担持する」、「もつ」、「含有する」、「関わる」、「保持する」、「から構成された」などのようなすべての移行句は、オープンエンドである、すなわち、それを含むがそれに限定されるものではないことを意味すると理解されるべきである。「…からなる」および「本質的には…からなる」という移行句のみが、それぞれ、米国特許庁特許審査手続マニュアル、第2111.03節に記載されるクローズドまたは半クローズドな移行句である。

Claims (15)

1. 一つまたは複数のプロセッサによって、一つまたは複数のバイタルサイン取得カメラによって捕捉されることができるエリア内の複数の患者の各患者に関連付けられた患者緊急度インジケーターを受領する段階であって、各患者に関連付けられた患者緊急度インジケーターは、その患者から取得された一つまたは複数の初期バイタルサインに基づく、段階と；
   前記プロセッサの一つまたは複数によって、少なくとも部分的には前記患者緊急度インジケーターに基づいて優先順位付けされた前記複数の患者を含む患者モニタリング待ち行列を確立する段階と；
   前記プロセッサの一つまたは複数によって、前記患者モニタリング待ち行列から、前記患者モニタリング待ち行列の先頭の患者を選択する段階と；
   前記バイタルサイン取得カメラの一つまたは複数によって、選択された患者から一つまたは複数の更新されたバイタルサインを邪魔にならないように取得する段階と；
   前記プロセッサの一つまたは複数によって、前記邪魔にならない取得の結果に応答して、前記患者モニタリング待ち行列を変更する段階とを含む、
   コンピュータ実装される方法。
2. 前記患者モニタリング待ち行列は、患者がモニタリングされるべき次のスケジュールされた時間にさらに基づいて優先順位付けされる、請求項１記載のコンピュータ実装される方法。
3. モニタリングされる各患者についての次のスケジュールされた時間は、少なくとも部分的には、その患者に関連付けられた患者緊急度インジケーターに基づいて決定される、請求項１記載のコンピュータ実装される方法。
4. 前記邪魔にならない取得の結果は、前記プロセッサの一つまたは複数によって、前記選択された患者の悪化を医療人員にアラートする出力を提供することを含み、前記変更することは、前記選択された患者を前記患者モニタリング待ち行列から除去することを含む、請求項１記載のコンピュータ実装される方法。
5. 前記邪魔にならない取得の結果は、前記一つまたは複数の更新されたバイタルサインを邪魔にならないように取得し損なったことを含み、前記変更することは、前記選択された患者を待ち行列に入れ直すことを含む、請求項１記載のコンピュータ実装される方法。
6. 前記邪魔にならない取得の結果は、前記一つまたは複数の更新されたバイタルサインの成功した取得を含み、前記変更することは、少なくとも部分的には前記選択された患者に関連付けられた患者緊急度インジケーターに基づいて、前記選択された患者を待ち行列に入れ直すことを含む、請求項１記載のコンピュータ実装される方法。
7. 前記選択された患者を待ち行列に入れ直すことは、少なくとも部分的には前記選択された患者に関連付けられた患者緊急度インジケーターに基づいて、前記選択された患者がモニタリングされる次のスケジュールされた時間を計算することを含む、請求項６記載のコンピュータ実装される方法。
8. 前記選択された患者を待ち行列に入れ直すことは、前記選択された患者を前記患者モニタリング待ち行列の選択された位置に挿入することを含み、前記選択された位置は、前記選択された患者がモニタリングされる前記次のスケジュールされた時間より遅いまたは大きい、モニタリングされるべき次のスケジュールされた時間をもつ、前記患者モニタリング待ち行列の中の別の患者より前である、請求項７記載のコンピュータ実装される方法。
9. 前記プロセッサの一つまたは複数によって、前記選択された患者を表わす参照画像に基づいて、前記エリアにいる前記複数の患者のうちで前記選択された患者を位置特定する段階をさらに含む、請求項１記載のコンピュータ実装される方法。
10. 前記参照画像は、トリアージ・ステーションに付随する一つまたは複数のカメラまたは医療待合室に付随する登録デスクによって捕捉される、請求項９記載のコンピュータ実装される方法。
11. 前記プロセッサの一つまたは複数によって、ウォッチドッグ・タイマーを所定の時間間隔に設定する段階と；
    更新されたバイタルサインが前記患者モニタリング待ち行列内のいずれかの患者から最後に邪魔にならないように取得されてから前記所定の時間間隔が経過したとの判定に応答して、患者モニタリング待ち行列から前記選択された患者を再選択する段階と；
    前記一つまたは複数のバイタルサイン取得カメラによって、更新されたバイタルサインを邪魔にならないよう取得しようとする試みの検出に応答して、前記ウォッチドッグ・タイマーをリセットする段階とを含む、
    請求項９記載のコンピュータ実装される方法。
12. 一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに動作可能に結合されたメモリとを有するシステムであって、前記メモリは命令を記憶しており、前記命令は、一つまたは複数のプロセッサによる該命令の実行に応答して、前記一つまたは複数のプロセッサに：
    一つまたは複数のバイタルサイン取得カメラによって捕捉されることができるエリア内の複数の患者の各患者に関連付けられた患者緊急度インジケーターを受領する段階であって、各患者に関連付けられた患者緊急度インジケーターは、その患者から取得された一つまたは複数の初期バイタルサインに基づく、段階と；
    少なくとも部分的には、患者がモニタリングされるべき次のスケジュールされた時間に基づいて優先順位付けされた前記複数の患者を含む患者モニタリング待ち行列を確立する段階と；
    前記一つまたは複数のバイタルサイン取得カメラによるモニタリングのために、前記患者モニタリング待ち行列からの選択された患者を送付する段階と；
    前記バイタルサイン取得カメラの一つまたは複数によって、前記複数の患者のうちの前記選択された患者から一つまたは複数の更新されたバイタルサインを邪魔にならないように取得する段階と；
    前記邪魔にならない取得の結果に応答して、前記患者モニタリング待ち行列を変更する段階とを実行させるものである、
    システム。
13. 前記患者がモニタリングされるべき次のスケジュールされた時間が、少なくとも部分的には前記患者緊急度インジケーターに基づいて計算される、請求項１２記載のシステム。
14. 命令を有する少なくとも一つの非一時的なコンピュータ可読媒体であって、前記命令は、一つまたは複数のプロセッサによる該命令の実行に応答して、前記一つまたは複数のプロセッサに：
    一つまたは複数のバイタルサイン取得カメラによって捕捉されることができるエリア内の複数の患者の各患者に関連付けられた患者緊急度インジケーターを受領する段階であって、各患者に関連付けられた患者緊急度インジケーターは、その患者から取得された一つまたは複数の初期バイタルサインに基づく、段階と；
    患者がモニタリングされるべき次のスケジュールされた時間に基づいて優先順位付けされた前記複数の患者を含む患者モニタリング待ち行列を確立する段階であって、前記患者がモニタリングされるべき次のスケジュールされた時間は、少なくとも部分的には前記患者緊急度インジケーターに基づいて決定される、段階と；
    モニタリングのために、前記患者モニタリング待ち行列の先頭の選択された患者を送付する段階と；
    前記バイタルサイン取得カメラの一つまたは複数によって、前記複数の患者のうちの前記選択された患者から一つまたは複数の更新されたバイタルサインを邪魔にならないように取得する段階と；
    前記邪魔にならない取得の結果に応答して、前記患者モニタリング待ち行列を変更する段階とを実行させるものである、
    少なくとも一つの非一時的なコンピュータ可読媒体。
15. 前記邪魔にならない取得の結果が、前記選択された患者の悪化を医療人員にアラートする出力を提供することを含み、前記変更することは、前記選択された患者を前記患者モニタリング待ち行列から除去することを含む、請求項１４記載の少なくとも一つの非一時的なコンピュータ可読媒体。

Images