JP2022500731A - レスポンダネットワーク - Google Patents

Abstract

自動体外式除細動器などの医療デバイスおよび／またはボランティアレスポンダを潜在的な医療インシデントの現場に到達させるように設計されたレスポンダネットワークを改善するのに有用な様々な方法、医療デバイス、レスポンダネットワークサーバ、救急サービスインタフェース、およびコールセンター関連のプロセスが記載されている。

Description

本発明は、概して、公衆レスポンダネットワーク（ｐｕｂｌｉｃ ｒｅｓｐｏｎｄｅｒ ｎｅｔｗｏｒｋ）、例えば、近隣で起こり得る心停止インシデントに対応する意思のあるレスポンダのネットワークの作成および実施に関する。救急インシデントが発生した場合に、そのようなネットワークをサポートおよび利用するのに適した様々な方法、デバイス、およびソフトウェアアプリケーションについて記載する。

突然の心停止は、主要な死因の１つである。米国だけでも、毎年約３５万人が突然の心停止で死亡している。これは、４０歳以上の人の主な死因であり、学生アスリートの死因の第１位である。突然の心停止に対する最も効果的な治療法は、除細動と組み合わせたＣＰＲの使用である。自動体外式除細動器（ＡＥＤ）は、突然の心停止に関連する生命にかかわる心調律を自動的にチェックし、ショック可能な心調律が検出された場合に心臓に電気ショックを送出して正常な調律を回復するべく設計された携帯機器である。ＡＥＤによって治療される２つの最も一般的な状態は、無脈性心室頻拍（別名ＶＴまたはＶ−Ｔａｃｈ）および心室細動（ＶＦまたはＶ−Ｆｉｂ）である。ＡＥＤは、通常、専門の医療従事者がいない状況で、一般の人が使用できるように設計されている。

生命を救う可能性を考慮して、自動体外式除細動器は、比較的広範囲の公衆の場所および民間の場所に配備されており、近隣の人が心停止に陥った場合に利用できるようになっている。例として、ＡＥＤは、企業および官公庁、ショッピングセンター、空港、飛行機、レストラン、カジノ、ホテル、スポーツスタジアム、学校、フィットネスセンター、および人々が集まり得るその他の様々な場所において見られる。

ＡＥＤの利用可能性は年々増加しているが、その比較的高いコストは配置を制限する傾向があり、学校、スポーツ競技場、および人々が集まる他の場所を含む多くの場所において、ＡＥＤを利用することができない。従って、心停止インシデントが発生したときにＡＥＤが利用できない時間、場所、およびイベントが多数ある。突然の心停止インシデントが発生したときにＡＥＤが近隣にあっても、ＡＥＤの存在が知られていないか、救急時に不慣れな機器を使用しようとするのをためらうバイスタンダー（ｂｙｓｔａｎｄｅｒｓ）には機器に対して威圧感があるため、ＡＥＤは使用されないことが多い。

公衆アクセス除細動器の公衆の認識度を高めるために、多くの努力が続けられている。例として、登録済みであるか、またはそれ以外に既知の公衆アクセス除細動器の位置を示す多くのウェブサイトおよびダウンロード可能なアプリがある。いくつかの代表的なソリューションには、パルスポイント（Ｐｕｌｓｅｐｏｉｎｔ）（www.pulsepoint.org）、ＡＥＤＭＡＰ（www.aedmap.org）、およびＨｅａｒｔＳａｆｅ（www.heartsafe.org.uk）が含まれる。このような取り組みは非常に有用であるが、心臓異常（ｃａｒｄｉａｃ ｉｎｃｉｄｅｎｔ）時に使用するためには、バイスタンダーが近隣のＡＥＤの位置を探索し、標識された場所にあり、かつ正常に機能することが期待される最も近いＡＥＤを取得する必要がある。

もう１つの取り組みはパルスポイントレスポンド（Ｐｕｌｓｅ Ｐｏｉｎｔ Ｒｅｓｐｏｎｄ）（www.pulsepoint.org/pulsepoint-respond/）であり、これは、ＣＰＲおよびＡＥＤの使用について訓練を受けたボランティアの市民レスポンダが、公衆の場所で発生している近隣の心臓異常について通知を受けるコミュニティベースのプログラムである。市民レスポンダプロジェクトの背後にあるコンセプトは、市民レスポンダが従来の救急医療サービスよりも早く心臓異常に到達することができる可能性があるということである。これは、統計では１分毎に１０％程度の割合で生存率が減少することが示されている心停止インシデントにとって特に重要である。パルスポイントレスポンドシステムは、救急サービスと連携しているため、市民レスポンダの通報は救急サービスによってトリガされるようになっている。

これらのタイプのシステムは明らかに有益であるが、一般の人々の意識をさらに高め、心停止の応答時間を短縮し、かつ／または心停止の生存率を向上することができる追加の技術および改善された技術を開発するための努力が継続的に行われている。

前述およびその他の目的を達成するために、レスポンダネットワークを改善するのに有用な様々な方法、医療デバイス、サーバ、インタフェース、およびコールセンター関連のプロセスについて記載される。

一態様では、レスポンスネットワークサーバは、支援の要求を受信することに応答してクエリ対象の１組の医療デバイスを特定する。支援の要求は、潜在的な医療インシデントの場所を示す。状態クエリは、現在の位置および動作状態を確認するために特定された医療デバイスに送信される。少なくとも１つの状態クエリ応答を受信した後、インシデントアラートメッセージが、選択された応答する医療デバイスおよび／またはインシデントの現場において支援を要求する選択されたボランティアレスポンダに送信される。いくつかの実施形態では、医療デバイスは除細動器であり、支援の要求は除細動器支援の要求である。

インシデントアラートメッセージを送信するデバイスの選択は、インシデントからのデバイスの距離または移動時間、デバイスの報告された状態、過去のインシデント対応履歴、および／またはその他の様々な要因を含む様々な要因に基づくことができる。

いくつかの実施形態では、支援の要求は、救急コールセンターから直接的または間接的に受信される。状況によっては、支援の要求は、複数の異なる救急コールセンターと通信し、他のデバイスから複数の異なる救急コールセンターに救急インシデントデータを送信するように構成された救急サービスインタフェースを介して、救急コールセンターから間接的に受信される。他の実施形態では、支援の要求は、潜在的な医療インシデントの現場においてモバイルコンピューティングデバイス上のアプリから直接的または間接的に受信される。

特定の医療デバイス（例えば、除細動器）との通信は、その機器に関連付けられた通信ユニットに送信される。通信ユニットは、医療デバイスの一体部分であり得るか、または医療デバイスに物理的に取り付けられた独立したインタフェースユニットの一部であり得る。他の実施形態では、インタフェースユニットは、医療デバイスが格納されているベースステーションの一部であり得る。

除細動器の状況では、いくつかの実施形態では、状態クエリは比較的多数の除細動器に送信され、一方、近隣のインシデントアラートメッセージは、状態クエリを受信した選択された一部の除細動器に送信され得る。いくつかの実施形態では、選択された一部は、除細動器から状態クエリ応答が受信された除細動器のみを含む。様々な異なる選択および／またはフィルタリングルールを使用して、実際にインシデントが通知される一部の除細動器を特定することができる。様々な実施形態において、近隣のインシデントメッセージを受信するための除細動器の選択は、除細動器が状態クエリに応答したかどうか、除細動器によって報告された現在の位置および／または現在の状態、インシデントまでの推定距離または移動時間、除細動器に関連付けられた以前のインシデント対応履歴、および／または他の様々な要因等の要因に少なくとも部分的に基づくことができる。同様の要因を使用して、ボランティアインシデントアラートを送信するボランティアレスポンダを特定し得る。

いくつかの実施形態では、レスポンダネットワークサーバは、そのネットワーク内の除細動器の現在の位置および現在の機能状態を含むデータベースを維持する。
別の態様では、除細動器システムは、電子の状態クエリの受信に応答して現在の状態メッセージを送信するように構成されている。近隣のインシデントメッセージを受信すると、システムは、除細動器が有用であり得る心臓緊急事態が近隣にあることを示す近隣のインシデントアラートを生成する。

様々な実施形態では、近隣のインシデントアラートは、音声アラート、視覚アラートメッセージ、またはその両方の組み合わせを含む。視覚アラートメッセージは、除細動器自体の表示画面上に表示されるか、または除細動器に関連付けられたインタフェースデバイスに表示され得る。

いくつかの実施形態では、視覚アラートメッセージは、除細動器を使用できる緊急事態が近隣にあることの表示と、ユーザが救援する意思を示すためにユーザによって選択できるＧＵＩウィジェットとを含む。ＧＵＩウィジェットを選択すると、インシデント受け入れメッセージがレスポンダネットワークサーバに送信される。いくつかの実施形態では、インシデントの場所を示すためにマップが表示される。

いくつかの実施形態では、状態クエリを受信する除細動器は、状態クエリが受信されたチャネルとは異なるチャネルを介してレスポンダネットワークサーバとの接続を開くことによって応答する。続いて、状態レポートが新たな接続を介してネットワークサーバに送信される。いくつかの実施形態では、完全に異なる通信プロトコルが異なるチャネルで使用される。例えば、ＳＭＳメッセージなどのメッセージング技術を状態クエリに使用することができ、一方、ＩＰ通信プロトコルまたは他の適切なプロトコルを第２のチャネルに使用することができる。

いくつかの実施形態では、除細動器システムは、ベース除細動器ユニットと、ベース除細動器ユニット上に搭載され、かつベース除細動器ユニットに取り外し可能に取り付けられた取り外し可能なインタフェースユニットとを含む携帯型モジュラー除細動器システムである。いくつかの実施形態では、インタフェースユニットは、通信ユニットおよび表示画面を含む。

別の態様では、様々なコールセンターとレスポンダネットワークサーバとの間の通信を可能にするために救急サービスインタフェースが使用される。救急サービスインタフェースは、複数の異なる救急コールセンターと通信するように構成されている。救急サービスインタフェースは、また、接続されたデバイスからリアルタイムのインシデントデータを受信し、リアルタイムのインシデントデータを救急コールセンターのうちの適切な救急コールセンターに直接伝達するように構成されている。いくつかの実施形態では、救急コールセンターによって生成されたボランティア支援の要求は、救急サービスインタフェースに送信される。続いて、救急サービスインタフェースは、レスポンダネットワークサーバに支援の要求を送信する。支援の要求は、潜在的な医療インシデントの場所を含む。

別の態様では、除細動器のインシデントデータは、除細動器から、医療デバイスネットワークサーバ、救急サービスインタフェース、およびコールセンターを含む一連の仲介手段を介して、選択された医療従事者および／または医療施設に送信され得る。

様々な実施形態において、除細動器のインシデントデータは、患者に送達されたいくつかのショックの表示、各ショックの特性またはタイミングに関する情報、１つまたは複数のＥＣＧセグメント、除細動器の分類器によって行われる心調律の分類、および／または医療従事者に有用であり得るその他の利用可能な情報のうちの１つまたは複数を含み得る。

さらに別の態様では、コールセンターから受信したインシデント記録を自動的に分析して、自動体外式除細動器がインシデント記録によって参照されるインシデントに有用であるかどうかを判定する方法が記載される。ＡＥＤがインシデントに有用であり得ると判定された場合、インシデントアラートが１人以上の登録済みのボランティアレスポンダおよび／または１つ以上の自動体外式除細動器に自動的に電子的に送信されて、レスポンダがインシデントの現場に行くのを促すようにする。

別の態様では、コールセンターオペレータによる選択に適したグラフィカルユーザインタフェースウィジェットを有するコールセンターのコンピュータ支援の派遣ユニットが記載される。グラフィカルユーザインタフェースウィジェットを選択すると、コンピュータ支援の派遣ユニットが自動体外式除細動器支援の要求を送信する。自動体外式除細動器支援の要求は、支援が望まれる潜在的な心停止インシデントの場所の表示を含む。自動体外式除細動器支援の要求は、潜在的な心停止インシデントがあることを通知する特定のレスポンダまたは除細動器を特定しない一般的な要求である。自動体外式除細動器支援の要求は、潜在的な心停止インシデントを通知するために、（ａ）１組の除細動器、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定するレスポンダネットワークに送信される。

同様のアプローチは、除細動器以外の医療デバイスと組み合わせて使用することができる。

本発明およびその利点は、添付の図面と併せて以下の記載を参照することによって最もよく理解することができる。
潜在的なレスポンダに近隣の潜在的な心停止インシデントを通知するための公衆レスポンダネットワークの構成要素を示す概略図である。 救急サービスインタフェースを利用する潜在的なレスポンダに近隣の潜在的な心停止インシデントを通知するための代替的な公衆レスポンダネットワークの構成要素を示す概略図である。 公衆ＡＥＤ支援の要求に応答して、近隣のボランティアレスポンダおよびＡＥＤに対してインシデントアラートを生成するのに適したフローを示すフローチャートである。 一実施形態による、潜在的な心停止インシデントの現場から公衆支援の要求を開始するのに適したフローを示すフローチャートである。 別の実施形態による、潜在的な心停止インシデントについての救急オペレータへの通報から公衆支援の要求を開始するのに適したフローを示すフローチャートである。 公衆ＡＥＤ支援の要求に応答して、近隣のボランティアレスポンダおよびＡＥＤへのインシデントアラートを生成するのに適した別のフローを示すフローチャートである。 公衆レスポンダネットワークに接続することができるアプリを使用して、潜在的な心停止インシデントの現場から近隣の公衆レスポンダに救援を要求することを可能にする代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークに接続することができるアプリを使用して、潜在的な心停止インシデントの現場から近隣の公衆レスポンダに救援を要求することを可能にする代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークに接続することができるアプリを使用して、潜在的な心停止インシデントの現場から近隣の公衆レスポンダに救援を要求することを可能にする代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークに接続することができるアプリを使用して、潜在的な心停止インシデントの現場から近隣の公衆レスポンダに救援を要求することを可能にする代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 アプリを介して近隣救急アラートを受信して対応する登録済みレスポンダに関する代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 アプリを介して近隣救急アラートを受信して対応する登録済みレスポンダに関する代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 アプリを介して近隣救急アラートを受信して対応する登録済みレスポンダに関する代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 アプリを介して近隣救急アラートを受信して対応する登録済みレスポンダに関する代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 アプリを介して近隣救急アラートを受信して対応する登録済みレスポンダに関する代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークの一部である公衆アクセスＡＥＤにおける使用に適した代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークの一部である公衆アクセスＡＥＤにおける使用に適した代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークの一部である公衆アクセスＡＥＤにおける使用に適した代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークの一部である公衆アクセスＡＥＤにおける使用に適した代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 公衆レスポンダネットワークの一部である公衆アクセスＡＥＤにおける使用に適した代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。 別の救急コール派遣アーキテクチャの状況におけるＡＥＤレスポンスネットワーク起動ウィジェットの統合を示す概略的なブロック図である。 除細動器から、除細動器ネットワークサーバ、救急サービスインタフェース、および救急コールセンターを介して医療従事者および／または医療施設にインシデントデータを転送する方法を示すフローチャートである。

図面において、同様の参照番号が、同様の構造要素を示すために使用される場合がある。図面中の描写は図式的なものであり、縮尺どおりではないことも理解されたい。
本発明は、概して、公衆レスポンダネットワーク、例えば、潜在的な心停止インシデントの間に使用可能な除細動器（例えば、ＡＥＤ）およびそのようなインシデントに対応する意思のあるボランティアレスポンダのネットワークの作成および実施に関する。救急インシデントが発生した場合に、そのようなネットワークをサポートおよび利用するのに適した様々な方法、デバイス、およびソフトウェアアプリケーションについて説明する。本発明は、主に、除細動器と、心停止インシデントに対応する意思のあるボランティアとのネットワークのコンテキストにおいて説明される。しかしながら、同様のアプローチおよびシステムが、他のタイプの医療インシデント、治療および／または装置を含むレスポンダネットワークと組み合わせて使用することができることを理解されたい。

出願人は、多数の接続機能を含み、かつ／または携帯電話と組み合わせて使用するのに非常に適した自動体外式除細動器システムを開発している。例として、米国特許第１０，０２９，１０９号明細書および米国特許出願第１６／１４５，６５７号（各々が参照により本明細書に組み込まれる）には、いくつかのそのような装置が記載されている。

図１Ａおよび図１Ｂには、本明細書で企図されるタイプのレスポンダネットワークの構成要素が図式的に示されている。図１Ａに示される実施形態では、ネットワークは、図１ＡにおいてＡＥＤレスポンスネットワークサーバ（単数または複数）２０として参照される１つまたは複数のサーバとの通信を可能にする接続機能を有する多数のＡＥＤ１０を含む。組み込まれた特許および特許出願に記載されているＡＥＤのいくつかは、この目的で良好に動作するが、ネットワークはそのようなＡＥＤに限定されるものではない。いくつかの実施形態では、ＡＥＤ１０のいくつかは、完全に機能するベース除細動器と、ベース除細動器ユニット上に搭載され、かつベース除細動器ユニットに取り外し可能に取り付けられたインタフェースユニットとを含んで、一体型携帯モジュール式除細動器を提供するモジュール式除細動器システムであり得る。そのような実施形態では、インタフェースユニットは、適切な通信ネットワークを介してＡＥＤレスポンスネットワークサーバと通信するのに適した表示画面および通信ユニットなどの構成要素を含み得る。組み込まれた米国特許出願第１６／１４５，６５７号には、いくつかのそのようなシステムが記載されている。他の実施形態では、通信機能は、ベース除細動器ユニット自体に組み込まれ得る。

ＡＥＤレスポンスネットワークサーバ（単数または複数）２０は、例えば、救急コール／派遣センターによって通常使用されるコンピュータ支援派遣（ＣＡＤ：ｃｏｍｐｕｔｅｒ ａｉｄｅｄ ｄｉｓｐａｔｃｈ）システムを含む、既存の救急レスポンスネットワークおよびシステムと直接的または間接的に通信するように構成され得る。これらはまとめて救急サービスサーバ（２５）として参照されることもあり、図１Ａには、救急コールセンターサーバ（単数または複数）として参照される特定のクラスの救急サービスサーバが示されている。救急コールセンターは、公共安全応答ポイント（ＰＳＡＰ：Ｐｕｂｌｉｃ Ｓａｆｅｔｙ Ａｎｓｗｅｒｉｎｇ Ｐｏｉｎｔｓ）センター、米国およびカナダにおける９１１のコールセンター、ヨーロッパにおける１１２のコールセンター、一部の管轄区域内の９９９のコールセンター、およびその他の救急サービスのコールセンターなどのセンターである。

救急コール／派遣センター２５は、通常、救急医療技術者、救急サービス、消防署職員などを含み得る様々な救急医療サービスプロバイダ（ＥＭＳプロバイダ）２７と別々に通信することができる。

様々な実施形態において、ＡＥＤレスポンスネットワークサーバは、支援団体、または除細動器製造業者などの民間団体、または多数のＡＥＤを管理する団体によってホストされ得る。代替的に、ＡＥＤレスポンスネットワークサーバ（単数または複数）２０の機能を、救急サービスインタフェース（以下で説明する）内のサーバ（または複数のサーバ）に組み込むことができる。他の実施形態では、ＡＥＤレスポンスサーバ（単数または複数）２０の機能は、公共安全レスポンスネットワークおよび／または救急レスポンスネットワークの他の構成要素に組み込むことができる。

ネットワークはまた、ＡＥＤレスポンスネットワークサーバ２０と通信するように構成されたユーザアプリ３５または他の適切なソフトウェアがインストールされた多数のユーザデバイス３０を含む。ユーザデバイスは、携帯電話、タブレットコンピュータ、ならびに他のタイプのパーソナル通信および／またはコンピューティングデバイスを含む任意の多種多様な異なる形態をとり得る。ネットワークは、支援が有用であり得る近隣の救急インシデントの通知を受け取りたいという希望を示すように登録された多数の登録済みのボランティアレスポンダをも有する。突然の心停止に焦点を合わせたレスポンダネットワークのコンテキストでは、レスポンダは、おそらく、そして好ましくは、ＣＰＲおよびＡＥＤの使用について訓練されている。

ボランティアレスポンダは、ＡＥＤレスポンスネットワークサーバ２０からの通信を伝達および受信することができるレスポンダアプリ４５または他の適切なソフトウェアがインストールされた独自のユーザデバイス４０（例えば、スマートフォン、タブレット、または他のコンピューティングまたはモバイル／パーソナル通信デバイス）を有する。ユーザデバイス３０およびユーザアプリ３５と同様に、レスポンダユーザデバイス４０およびレスポンダアプリ４５は、多種多様な異なる形態（例えば、スマートフォン、タブレット、または他のコンピューティングまたはモバイル／パーソナル通信デバイス）をとることができ、それらは、図面において、デバイスおよびアプリが使用される様々なコンテキストを単に強調するためにラベル付けされている。いくつかの実施形態では、単一のアプリを、アプリ３５および４５の両方として使用することができ、主な違いは、ユーザがボランティアレスポンダとして登録したかどうか、およびそのような登録後にアクセスされ得るアプリの機能である。当然ながら、他の実施形態では、別個のアプリが提供されてもよい。全てのアプリが同じである必要はなく、１つのソースからのものである必要もない。むしろ、救急レスポンス機能は、様々な除細動器製造業者、様々な医療サービスプロバイダ、様々な支援団体、様々な救急サービスプロバイダ、様々なユーザデバイス製造業者などを含む様々な団体によって提供される多種多様なアプリケーションまたはソフトウェアコンポーネントに組み込むことができる。

いくつかの特定の実施形態では、ユーザアプリは、救急時に選択された除細動器と組み合わせて使用できるように設計されたＡＥＤアプリの形で具体化されて、ＡＥＤの使用を一般のレスポンダに全体的にわたって案内するのを支援し、かつ／または救急レスポンダおよびその他の関係する医療従事者へのインシデント情報の送信を可能にするのを支援する。従って、便宜上、以下の説明の多くでは、アプリはＡＥＤアプリとして参照される。しかしながら、ユーザアプリケーションソフトウェアは、非常に多様な形式をとることができ、かつＡＥＤサポート機能を備えたアプリに限定されることを意図していないことを理解されたい。

ＡＥＤレスポンスネットワークサーバ（単数または複数）２０はまた、多種多様な異なる形態をとることができ、かつサーバの必要な機能を実行するように構成された任意の中央システムまたはシステムの組み合わせを指すことを一般に意図している。例として、ＡＥＤレスポンスネットワークサーバは、１つまたは複数のコンピューティングデバイス、サーバクラスタ、ネットワーク上の分散コンピューティングノード、または複数の別個のシステムの組み合わせの形態をとることができる。このようなサーバは、救急サービス、非営利支援団体、医療機関、医療デバイス企業、政府機関、および／またはその他の適切な団体を含む、任意の種類の公衆団体または民間団体によって運営することができる。ＡＥＤレスポンスネットワークサーバは、ＡＥＤレスポンスネットワークの動作の処理専用にすることができ、ＡＥＤ管理サーバプラットフォームに統合することができ、既存の救急サービスサーバのコンポーネントに統合することができ、かつ／または様々な他の現在存在するシステム、または後に開発されるシステムの一部として装備することができる。

図１Ｂは、別の代表的なレスポンダネットワークのアーキテクチャを示す。この実施形態は、救急レスポンスネットワークインタフェースまたは救急サービスインタフェース２８が、ＡＥＤレスポンスネットワークサーバ２０と救急コールセンター２５との間のインタフェースとして機能することを除いて、図１Ｂに関して上記で説明した実施形態とかなり類似している。米国では、ラピッドＳＯＳ（ＲａｐｉｄＳＯＳ）は、現在最大の救急レスポンスネットワークインタフェースであり、かつこのような適用に最適である。ラピッドＳＯＳの特に望ましい機能の１つは、現在、米国の救急コールセンターの大部分と関係を持っており、他の接続デバイス２９から受信したインシデント関連データを様々なコールセンターに送信するように既に設定されていることであるが、現在のところ、コールセンターと任意の除細動器または除細動器ネットワークとの間の仲介手段としての役割を果たしていない。ラピッドＳＯＳについて具体的に言及しているが、必要に応じて、同じアプローチを任意の仲介手段、または複数の異なる仲介手段により使用することができることを理解されたい。

心停止インシデントが発生すると、ＡＥＤレスポンスネットワークサーバ２０は、公衆レスポンダからの支援の要求（ｒｅｑｕｅｓｔ ｆｏｒ ａｓｓｉｓｔａｎｃｅ）を受信し得る。支援の要求は、救急サービスサーバ２５（救急サービスインタフェースを介して直接的または間接的に）、ユーザアプリ３５、または警察システムまたは消防システムなどの他の救急要員派遣システムを含む任意の他の適切なシステムを含む様々な異なるソースから発信することができる。図２Ａは、一実施形態による、潜在的な心停止インシデントが発生した場合に、近隣の公衆ＡＥＤおよび公衆レスポンダへのアラートを生成するのに好適なフローを示すフローチャートである。

支援の要求が受信されると（ステップ２０１）、ＡＥＤレスポンスネットワークサーバ２０は、インシデントの近隣にいる１人または複数の登録済みのボランティアレスポンダを特定および選択することを試みる（ステップ２０４）。ＡＥＤレスポンスネットワークサーバはまた、インシデントの近隣にある１つまたは複数の既知の接続された公衆ＡＥＤを特定および選択することを試みる（ステップ２０９）。適切なボランティアおよびＡＥＤを特定するために使用されるプロトコル、プロセス、およびアルゴリズムは、幅広く存在し得、いくつかの適切なアプローチを以下に例として示す。ＡＥＤレスポンスネットワークサーバは、続いて、近隣救急インシデントアラートを、インシデントに近い選択された登録済みのボランティアレスポンダ（単数または複数）に送信する（ステップ２１１）。アラートは、アップル（Ａｐｐｌｅ（登録商標））ＩＯＳ（登録商標）およびアンドロイド（Ａｎｄｒｏｉｄ（登録商標））プッシュ通知サービス、ＳＭＳテキストメッセージ、その他のテキストまたは音声メッセージングプロトコル、マルチメディアメッセージングプロトコル（例えば、ＭＭＳ）、インスタントメッセージングまたはアイメッセージ（ｉＭｅｓｓａｇｅ）テクノロジ、電子メール等を含む様々な別個のメッセージングテクノロジのいずれかを介して送信することができる。（ａ）ＡＥＤを持っているか、または（ｂ）ＡＥＤに簡単にアクセスできるボランティアレスポンダが近隣にいる場合、ボランティアレスポンダは、ＡＥＤを取得して、ＡＥＤをインシデントの現場に早く持ち込むことができる。多くの場合、ＡＥＤを持っているか、または近隣のＡＥＤの位置を知っているそのようなボランティアレスポンダは、ＡＥＤを探して取得しようとするインシデントのバイスタンダーよりも早くＡＥＤを現場に持ち込み得る。

近隣のボランティアレスポンダへの通知と並行して、救急アラート通知を、インシデントに近い接続された任意のＡＥＤ１０に直接送信してもよい（ステップ２１３）。以下でより詳細に説明するように、通知を受けたＡＥＤは、インシデントのＡＥＤの近隣にいる人またはバイスタンダーの注意を引き付け、かつＡＥＤをインシデントの場所に持ち込むように要請することを目的とした近隣救急アラート信号を発行することができる。通常、このようなメッセージは、ＡＥＤレスポンダネットワークにオプトインした接続済みのＡＥＤにのみ送信される。

いくつかの実施形態では、ＡＥＤ１０の少なくともいくつかは、それらの現在の機能状態および現在の位置を報告するために照会することができる。そのような機能が存在する場合、インシデントの近隣に存在すると見られているＡＥＤの各々を照会（ピンギング（ｐｉｎｇ））して、ＡＥＤ特定ステップ２０９の一部としてその現在の状態／位置を提供することができる。次に、ピンギングされたＡＥＤの各々は、現在の状態および位置の情報を提供して応答し、その現在の情報は、ステップ２１３において救急インシデントアラートを送信するＡＥＤを決定するのに有用となるように使用することができる。

近隣救急アラートが近隣の登録済みのボランティアレスポンダおよび／または登録済みの接続されたＡＥＤに送信された後、ＡＥＤレスポンスネットワークサーバは、インシデントに適切に対応することに同意したレスポンダ（単数または複数）と通信して、レスポンダをインシデントの場所に案内し、インシデントへの対応に有用である得る他の情報を伝達するように支援する（ステップ２１５）。

ＡＥＤに近隣救急アラートを発行させることで、除細動器および訓練を受けたレスポンダでさえ、心停止インシデントの現場に他の方法よりも早く到着し得る多くのシナリオがあることを理解されたい。例えば、多くの場合、除細動器は、指定されたレスポンダの近隣に配置されてもよく、例えば、学校の環境では、除細動器は、訓練を受けたレスポンダであるコーチ、管理者、看護師、または教師のオフィスの近隣（またはオフィス内）に配置されてもよい。オフィスビルの環境では、除細動器は、訓練を受けたレスポンダである管理者または他の従業員の近隣に配置されてもよい。ＡＥＤがアラートを発行すると、訓練を受けたレスポンダがアラートを聞くことができる。このような状況では、除細動器をリアルタイムで必要とする救急インシデントを潜在的なレスポンダ（単数または複数）に通知して、現場に出向いて、必要に応じて支援を提供することができるようにすることには大きな価値がある。指定されたレスポンダ（または登録済みのボランティアレスポンダ）がすぐに対応できない場合でも、除細動器の場所の近くに他の責務者がいる可能性があり、ＡＥＤによって生成されたアラートは、そのような人に、対応するのを支援することが可能となり得るように近隣で心臓イベントが発生したことを通知し得る。再び学校を設定した環境を使用した場合に、インシデント時に除細動器の近隣に偶然居合わせた他の管理者、教師、コーチ、または他の責務者を、除細動器をインシデントの場所に迅速に移動させるように促すことができる。さらに、バイスタンダー（例えば、スポーツイベントのファン、学校の生徒または訪問者、公共空間でのバイスタンダー等）に、近隣の救急インシデントで除細動器が必要であることを通知することは、そのようなバイスタンダーがＡＥＤを救急の場所に持っていくように動機付けられる可能性があるため、価値がある。上記の例は学校の環境に多少焦点を当てているが、同じ動機が多種多様な異なるシナリオに適用されることを理解されたい。

前述したように、ＡＥＤレスポンスネットワークサーバ２０がボランティアレスポンダに対する要求を受信するか（例えば、図２Ａのステップ２０１）、またはそれ以外にボランティアレスポンダが特定の状況で有用であり得ると判定すると、サーバは、近隣のボランティアレスポンダおよび／またはボランティアレスポンダに有用であり得る近隣のＡＥＤを特定することを試みる（例えば、図２Ａのステップ２０４および２０９）。潜在的なレスポンダおよびＡＥＤを特定するために使用され得る様々な選択プロトコルがある。

上記で説明したように、いくつかの接続されたＡＥＤは、現在の状態および現在の位置を報告する機能を有している。場所は、ＡＥＤまたはＡＥＤに取り付けられたインタフェースユニットまたはＡＥＤに関連付けられたキャビネット内の全地球測位システム（ＧＰＳ）（または、より広義にはＧＮＳＳ）チップ、セルラーロケーティングテクノロジ、メトロポリタンビーコンシステム等を含む、ＡＥＤの場所をピンポイントで特定するために利用可能な様々な位置特定サービスのいずれかに基づいて、特定することができる。そのような実施形態では、ＡＥＤレスポンスネットワークサーバは、患者の指定された距離または応答時間内にあると見られている接続されたＡＥＤの各々にピンギングすることができる。上記で示唆したように、指定された距離は、インシデントから定義された半径内であってもよく、または予想される経路などのより高度な距離の測定に基づいていてもよい。代替的に、可能な場合は、推定応答時間を使用することができる。

照会されたＡＥＤは各々、機能の状態および場所をＡＥＤレスポンスネットワークサーバに伝達して、患者に使用するのに十分な動作状態にあるかどうか、それ以外に「作動可能なＡＥＤ（ｆｕｎｃｔｉｏｎａｌ ＡＥＤ）」として定義されるかどうかを通知する。ＡＥＤレスポンスネットワークサーバ２０が、患者の定義された距離内の作動可能なＡＥＤを特定すると、ＡＥＤレスポンスネットワークサーバ２０は、適切であると思われるそのようなＡＥＤに救急アラート（ステップ２１３）を送信し得る。留意すべき重要な点は、任意のＡＥＤが適切な動作状態にないか、またはそれ以外に「非作動可能なＡＥＤ」として定義されることをＡＥＤレスポンスネットワークサーバと通信する場合、サーバは、これらのＡＥＤを考慮から除外し、これらのＡＥＤに救急アラートを送信しないということである。「作動可能なＡＥＤ」が受信する救急アラートは、バイスタンダーの支援が有用である緊急事態があることを示す、特定されたＡＥＤ上の可聴信号および／または視覚信号を作動させる。バイスタンダーがアラートに気付いた場合、バイスタンダーは、ＡＥＤを現場に持ち込む意思があることを示して緊急事態を「受け入れる」ことができ、レスポンダが患者の位置に案内するために使用することができるマップがＡＥＤ上に表示される。

同様に、ボランティアレスポンダが緊急事態を受け入れた場合、適切なマップがボランティアレスポンダデバイス４０（例えば、スマートフォン）上に表示され、かつボランティアレスポンダを適切に案内し得る。必要に応じて、ＡＥＤレスポンスネットワークサーバ２０とボランティアレスポンダとの間で、いくつかの通信のやりとりがあり得ることを理解されたい。例えば、レスポンダは、ＡＥＤをすぐに使用できるかどうかを尋ねられる場合がある。その場合、ボランティアをインシデントに直接案内するためにレスポンダデバイス上にマップが表示され得る。そうでない場合、マップは、利用可能なＡＥＤの場所（単数または複数）を表示し、かつボランティアがＡＥＤを持ち込むことができるように、インシデントへの途中に最も近い作動可能なＡＥＤに案内し、次にインシデント自体にボランティアを案内し得る。

必要に応じて、ＡＥＤレスポンスネットワークサーバは、調整された方法でボランティアレスポンダにインテリジェントに指示すこともできる。例えば、ＡＥＤ上の近隣救急アラートを見たボランティアが、ＡＥＤを持ち込んでインシデントに対応していることを肯定的に示した場合、インシデントに近いがＡＥＤを持っていない登録済みのボランティアレスポンダは、利用可能な公衆ＡＥＤを見つけるために経路を迂回するのではなく、インシデントに直接進むように指示され得る。当然ながら、複数のボランティアレスポンダを誘導する際に使用される特定のプロトコルおよび優先順位は、レスポンダネットワーク管理の優先順位および設計目標に基づいて幅広く変化する。これには、インシデント通知を送信するボランティアおよび／またはＡＥＤの数、１人または複数の他のレスポンダがインシデントに対応していることを肯定的に示した場合に（たとえ示したとしても）、追加の潜在的なレスポンダ（単数または複数）を中止する時期、インシデントアラートのそれ以上のブロードキャストを終了するタイミング（例えば、専門の救急医療従事者が現場に到着したことに起因して、または他の人が対応したことに起因して）、インシデントに対して持ち込もうとするＡＥＤの数、ＡＥＤが手元にない場合でも、ボランティアのレスポンダがインシデントに直接移動するように指示されることがあるかどうか、および指示される状況等に関する決定が含まれる。

最初の支援の要求（２０１）をトリガする多くの方法がある。状況によっては、支援の要求は、電話上のユーザアプリ３５を介して明示的に支援を要求する現場の目撃者またはバイスタンダーによって生成され得る。図２Ｂは、そのような一実施形態による、そのような要求を生成するのに適した代表的なワークフローを示すフローチャートである。他の状況では、最初の支援の要求は、救急コールセンターから発信されるか、システムなどから受信した情報に基づいてトリガされ得る。図２Ｃは、第２の実施形態による、救急サービスに対してなされた通報（例えば、９１１の通報）に基づいて支援の要求を生成するのに適した代表的なワークフローを示すフローチャートである。さらに他の状況では、最初の支援の要求は、警察署または消防署などの他のソース、またはＡＥＤネットワークサーバ２０と直接または間接的に通信することができる任意の他のソースから発信することができる。

図２Ｂに示される実施形態では、潜在的な心臓インシデントの現場にいるユーザは、ボランティアレスポンダ支援の要求機能を含むアプリケーションを開く（ステップ２２３）。上記で示唆したように、そのような機能は、ＡＥＤアプリ３５または他の様々なアプリケーションプログラムのいずれかに組み込むことができる。このようなアプリは、携帯電話、タブレットコンピュータ、除細動器のインタフェースデバイスなど、様々なデバイス上で実行され得る。

ＡＥＤアプリを開くと、ユーザが様々な機能にアクセスするための機構が提供される。そのような機能の１つは、インシデントの近隣にある公衆アクセスＡＥＤの場所を示すＡＥＤマップである（ステップ２２５）。いくつかの実施形態では、ＡＥＤマップは、ＡＥＤアプリが開かれたときに表示される初期画面に含まれるが、他の実施形態では、ユーザがＡＥＤマップに容易にアクセスするための機構が提供される。ＡＥＤマップは、ユーザの場所の近くにある既知のまたは登録済みの公衆アクセスＡＥＤの場所を示しているため、イベントの目撃者がＡＥＤに直ちにアクセスできない緊急事態において特に有用である。さらなる救援が得られる場合、最も近いＡＥＤを取得するためにバイスタンダーを派遣することができる。

さらに、状況に応じて、ユーザは、支援および／またはＡＥＤが必要であることを示すことによって、近隣のボランティアレスポンダに支援を要求することができる（ステップ２２７）。繰り返しになるが、この救援要求は、インシデントの近隣に偶然居合わせたボランティアレスポンダが、イベントの目撃者によってＡＥＤが発見されて現場に戻るよりも早くインシデントの現場に持ち込むことができるＡＥＤを持っているか、またはアクセスできる可能性があるため、ユーザがＡＥＤに直ちにアクセスすることができない状況において特に有用である。このことは、ユーザがインシデントの現場に一人でいる場合にさらに重要である。この理由は、ＣＰＲは通常、患者に対して実行する必要があり、ユーザがＡＥＤを探している間、ＣＰＲを長期間実行しないと、患者の生存率が著しく低下する可能性があるからである。

支援の要求は、救援要求メッセージがＡＥＤレスポンスネットワークサーバに送信されるようにする適切なＧＵＩボタンまたは他の適切なＧＵＩ構造を選択することによって生成され得る。このメッセージは、救援が必要であることを示し、送信デバイスの場所を可能な限り詳細に提供する。必要とされる支援の要求を生成するためのインタフェースの特定の例を、図３Ａ等を参照して以下に説明する。

ユーザの支援の要求は、図２Ａを参照して上記したように、ＡＥＤレスポンスネットワークサーバ２０に送信され、ＡＥＤレスポンスネットワークサーバ２０は、公衆ボランティアレスポンダに関する要求を開始する。

ユーザがこれが緊急事態であることを示した場合、ユーザまたはバイスタンダーは、アプリによって救急サービス（例えば、米国における９１１）に通報するように、まだそれが行われていない場合に、望ましいくは促される。このステップは、救急医療従事者ができるだけ早くインシデントに派遣されるようにするために重要である。多くの状況では、ユーザまたはバイスタンダーが独立して救急サービスに通報することができるため、様々な実施形態では必要ではないが、救急サービスへのこのような通報は、任意選択的に、アプリによって円滑に進めるようにしてもよい。さらに他の実施形態では、ＡＥＤレスポンスネットワークサーバは、患者の位置を確認する救急コールセンターに通知を自動的に転送するように構成することができる。これが可能なのは、ユーザの支援の要求メッセージに、支援の要求を開始したユーザの場所を示す表示が含まれているからである。

ボランティアの市民レスポンダに対する要求は、救急医療支援に関する通報に応答して救急サービスのコールセンターによって開始することもできる。例として、図２Ｃは、一実施形態による、公衆安全応答ポイントセンター（ＰＳＡＰセンター、例えば、米国における９１１コールセンター）における救急オペレータに対してなされた通報に基づいて開始される、近隣の公衆レスポンダおよびＡＥＤへのアラートを生成するのに適したフローを示すフローチャートである。図示の実施形態では、プロセスは、ブロック２５１によって表されるように、救急オペレータ（例えば、９１１通信指令係）に対して通報がなされたときに開始する。潜在的な心停止インシデントに対する目撃者またはバイスタンダーによって通報がなされ、その通報によって救急対応プロセスが効果的に活性化される。通報者が心停止インシデントを目撃したか、他の当事者から救急サービスに通報するように言われたかに関係なく、救援を求めることで、専門の第一レスポンダが可能な限り迅速に緊急事態に派遣されることを保証する。

ほとんどの状況において、救急サービスへの通報は人によって開始されると予想されるが、場合によっては、通報はＡＥＤ自体によって自動的に開始され得る。例えば、いくつかのＡＥＤは、ＡＥＤが救急モードで作動したとき、またはユーザ入力、電極パッドカートリッジの開封の検出、電極パッドの配置の検出、ショック可能な心調律の検出などの他の何らかのトリガイベントに基づいて、救急サービスへの通報を自動的に開始するように設計され得る。

救急オペレータが電話に応答すると、オペレータは、ブロック２５３によって表されるように、報告した当事者が通報している救急のタイプを評価するプロセスを経る。必要に応じて、オペレータは救急サービスを現場に派遣する。いくつかの管轄区域では、オペレータは、必要となる可能性のある救援のタイプをよりよく理解するために、通報者が患者の状態を評価するのを支援する。例えば、患者が反応せず、適切に呼吸していない場合、オペレータは、患者が突然の心停止を経験した可能性があると推測し得る。このような状況では、オペレータは、ＣＰＲを実行するステップと、ＡＥＤが存在する場合、ＡＥＤを取得するステップを行うように通報者に案内し得る。並行して、オペレータは救急サービスを派遣する。さらに、通報中に、オペレータは、患者の位置など、他の重要な詳細を通報者に尋ねて学習する。状況によっては、患者の位置は、通報者に尋ねることによって決定される。さらに、携帯電話を含む多くの電話には、救急サービスに自身の位置を自動的に提供する機能がある。

通報者によって提供された情報、オペレータの評価、患者の位置、およびその他の関連情報を含むインシデントに関する詳細は、通常、コンピュータ支援派遣（ＣＡＤ）システム内のインシデント記録にオペレータによって登録される。ＣＡＤシステムは、インシデント記録を救急レスポンダと共有し、これは、派遣プロセスがスピードアップすることに有用である。また、専門の第一レスポンダが患者の状態を知って、患者の位置に到着する前に、状況をある程度理解することができるようにするのに有用である。

いくつかの実施形態では、図２Ｃの左側の分岐に示されているように、救急オペレータは、必要に応じて、公衆支援の要求を開始し得る。上記で参照した評価中に、救急オペレータは、決定ブロック２５５によって表されるように、ＡＥＤが現在の状況で有用である可能性が高いかどうかを決定することができる。突然の心停止のいくつかの重要な指標には、患者が反応せず、正常に呼吸していないという説明が含まれる。救急オペレータは、患者が突然の心停止に苦しんでいる可能性があり、現場にＡＥＤがないことに気付いた場合、救急オペレータは、ブロック２５９で表されるように、ＣＡＤシステムを介して公衆支援の要求を開始し得る。このような要求は、ＣＡＤシステムディスプレイ上の適切なＧＵＩボタンまたは他のＧＵＩ構造を選択することによって開始され得る。要求は、ＡＥＤレスポンスネットワークサーバ２０に転送され、ＡＥＤレスポンスネットワークサーバ２０は、図２Ａを参照して上記で説明したように、公衆ボランティアレスポンダに対する要求を開始する。

救急コールセンターへのほとんどの通報は、潜在的な心停止インシデントに関連していないため、ＡＥＤレスポンダネットワークを起動する理由がないことを理解されたい。例えば、緊急事態が住宅火災または火傷患者として説明されている場合、ＡＥＤは有用ではない。このような状況では、ブロック２５５の「否」分岐で表されるように、ＡＥＤレスポンダネットワークを起動することなく、通常の方法で通報が処理される。後続のオペレータの動作は本開示に特に関連しないので、ブロック２５７によって表されるように、ＡＥＤレスポンダネットワークの役割でのプロセスは効果的に終了する。

説明した救急オペレータが開始した公衆支援の要求は、管理当局が、ＡＥＤボランティアレスポンダネットワークから支援を要求するかどうかについてオペレータが明確な決定を行うことに満足している状況では、非常に良好に機能する。しかしながら、いくつかの管轄区域では、その決定をより自動的に行うことが好適である場合がある。そのような自動アプローチの１つを、図２Ｃの右側の分岐（ステップ２６２−２６８）を参照して説明する。

このアプローチでは、ブロック２６２で表されるように、ＣＡＤ記録を分析して、ＡＥＤが有用である可能性が高いかどうかを判定する。この分析は、様々な方法で実行することができる。例えば、多くのＣＡＤ記録には、インシデントの分類に有用なタグまたは、それ以外に状況の概要を含むタグが多数ある。突然の心停止に最も関連するいくつかの特徴は、（１）傷病者が無反応または意識不明であること、および（２）傷病者が呼吸していないか、または正しく呼吸していないことである。ＣＡＤ記録がこれらの状態に対する特定のタグを有する場合、記録タグを検索することができ、タグ検索に基づいて、インシデントを潜在的な突然の心停止としてまたはそうでないものとして分類することができる。インシデントが潜在的な突然の心停止として分類されない場合、ＡＥＤは有用でない可能性が高い。決定ブロック２６４からの「否」分岐によって表されるように、ＡＥＤが有用でない可能性が高いと判定された場合、ＣＡＤ記録のさらなる分析は必要ではなく、ＡＥＤレスポンダネットワークの役割でのプロセスは終了する。

あるいは、ＡＥＤが有用である可能性があると判定され（決定ブロック２６４からの「是」分岐）、記録がさらに有用な傷病者の位置データを含む場合、ブロック２６８によって表されるように、患者の位置を含んで、システムによって公衆支援の要求が自動的に開始され得る。要求は、ＡＥＤレスポンスネットワークサーバ２０に転送され、ＡＥＤレスポンスネットワークサーバ２０は、図２Ａを参照して上記で説明したように、公衆ボランティアレスポンダに対する要求を開始する。

上記の簡単な例では、ＡＥＤが有用であるかどうかを判定するために、いくつかの特定のＣＡＤ記録タグが検索された。他の状況では、その判定を行うためにかなり多くのロジックを使用することができる。例えば、いくつかの状況によっては、オペレータが、インシデントの場所でＡＥＤが現在利用可能であるかどうかを尋ねて指摘し得る。ＡＥＤがすでに現場にある場合は、ボランティアレスポンダにＡＥＤを現場に持ち込むように依頼する理由がない。しかしながら、このような状況では、ボランティアはＡＥＤを取得するのではなく、インシデントに直接進むように依頼されることとなり得るが、ボランティアの支援を要求することが望ましい場合がある。

全てのＣＡＤ記録が上記で参照された特定のタグを含むわけではなく、そのような状況では、記録をスキャンしてキーワードおよび／または他のタグを使用したり、かつ／またはその他の分析アプローチを適切に利用して、ＡＥＤ公衆レスポンダネットワークを介して公衆ボランティア支援を要求するかどうかの決定を可能にしたりすることができることを理解されたい。例えば、いくつかの実施形態では、分析エンジン（図示せず）は、心停止を示す検索されたキーワードのテーブルと、公衆レスポンダネットワークを介して支援の要求を開始するかどうかに関する決定を行う対応するロジックとを有することができる。当然ながら、他の様々な基準も使用することができる。

ＣＡＤ記録またはその他の利用可能なデータの分析は、様々な場所のいずれかで実行することができる。いくつかの実施形態では、ＡＥＤの有用性の判定と公衆支援の要求開始の責務とをＣＡＤソフトウェアに組み込んで、インシデント記録に基づいて救急コールセンターにおいて直接決定を下すことができるようにすることができる。地域の救急コールセンターからデータを取得し、そのデータを様々な公共安全および／または救急サービスに適切にリアルタイムで利用できるようにする救急データクリアリングハウスサービスもある。米国において、現在最も一般的なそのようなサービスはラピッドＳＯＳである。いくつかの実施形態では、ＡＥＤの有用性の判定および自動化された公衆支援の要求開始の責務を、そのようなクリアリングハウスにおけるサーバに組み込むことができる。さらに他の実施形態では、記録または選択された記録または記録の一部を、その場所での分析のためにＡＥＤレスポンダネットワークサーバ（単数または複数）に転送することができる。そのような実施形態では、記録、または記録の関連部分は、コールセンターから直接、またはラピッドＳＯＳなどの救急サービスインタフェースを介して転送することができる。

次に、図２Ｄを参照して、図２ＡのＡＥＤ通知プロセスの別の特定の実施形態について説明する。図２Ｄの実施形態は、ＡＥＤレスポンスネットワークサーバ２０がボランティアレスポンダに対する要求を受信したときに開始される（ブロック２０１）。説明された実施形態では、サーバ２０は、そのネットワーク内のＡＥＤの各々に関する記録を含むデバイスデータベースを維持している。ＡＥＤに関して保存される情報のいくつかは、（ａ）デバイスの地理的位置、（ｂ）ＡＥＤが私有ＡＥＤまたは公衆アクセスＡＥＤとして指定されているかどうか、（ｃ）ＡＥＤの管理者が、近隣の潜在的な心停止インシデントに関する通知を受信することをオプトインしたかどうか、（ｄ）ＡＥＤがモバイルＡＥＤとして指定されているか、または固定位置に保管されることになっているか、（ｅ）除細動器等の現在の状態等を含み得る。好ましくは、状態および位置情報は、例えば、ＡＥＤによってサーバ２０に報告される定期的な（例えば、毎日の）セルフテスト状態チェックの結果として、定期的に更新される。

ＡＥＤが公衆アクセスＡＥＤとして指定されている場合、デバイスの所有者／管理者は、公衆が利用できる時間／曜日等を指定することができる。例えば、ＡＥＤが指定された時間にのみ営業しているオフィスビルまたは小売店の内部にある場合、潜在的な第三者のレスポンダが施錠された建物内のＡＥＤを見つけようとしないように、指定された時間中にのみＡＥＤが公衆に利用可能であることを示すことが望ましい場合がある。

一般に、近隣のインシデントメッセージは、そのような通知をオプトインしたＡＥＤに送信され得る。これには、一般公衆が利用可能な公衆アクセスＡＥＤと、一般公衆が利用可能であるとは宣伝されていない私有ＡＥＤとの両方が含まれ得る。私有ＡＥＤが近隣のインシデントの通知を受け取ることを選択し得る多くの状況がある。そのような例は、ＡＥＤがボランティアレスポンダの個人的なＡＥＤである場合であり得る。別のそのような例は、ＡＥＤが公衆にアクセス可能でない建物または複合施設内に配置されている場合であり得る。別の例は、ＡＥＤが人の家屋内に配置されている場合である。

ＡＥＤは、固定位置ＡＥＤまたはモバイルＡＥＤとして指定され得る。固定位置ＡＥＤは、常に同じ場所に保存されることになっている。対照的に、モバイルＡＥＤはより頻繁に移動されることになっている。モバイルＡＥＤのいくつかの代表的な例には、車両に保管されるか、または安全キットの一部として（例えば、コーチ、ガイド、またはボランティアレスポンダによって）搬送されることになっているＡＥＤが含まれ得る。

ほとんどの公衆アクセスＡＥＤは、固定位置（例えば、オフィスビルのＡＥＤキャビネット、競技場、空港内の指定された場所等）に配置されることになっている固定位置ＡＥＤであると予想される。しかしながら、これは必要条件ではない。例えば、警察は、警察車両内に搬送されたＡＥＤをモバイルの公衆アクセスＡＥＤとして指定して、潜在的な心停止インシデントが発生したときに、警察官が近隣に偶然居合わせた場合に、ＡＥＤの位置をＡＥＤマップ上に表示することができるように選択し得る。当然ながら、他の状況では、そのようなデバイスを私有として指定することが望ましい場合がある。

図２Ｄに戻ると、ＡＥＤレスポンスサーバ２０がボランティアレスポンダに対する要求を受信する場合（ブロック２０１）、要求はインシデントの地理的位置を含む。次に、ＡＥＤレスポンスサーバは、インシデントに対応する際に使用するために潜在的に利用可能な１組のＡＥＤを特定する。潜在的に利用可能な１組のＡＥＤは、様々なフィルタリング技術を使用して様々な方法で決定され得る。いくつかの実施形態では、潜在的に利用可能な１組のＡＥＤは、デバイスデータベースに格納されたＡＥＤの最後の既知の場所に基づいて、インシデントの指定された範囲内にあると理解されるレスポンダネットワークデータベース内のＡＥＤを特定することによって少なくとも部分的に決定される（ブロック２７２）。いくつかの実施形態では、固定範囲のしきい値が全ての状況で使用されるが、他の実施形態では、指定された範囲のしきい値が様々な要因に基づいて変化し得る。例えば、いくつかの実施形態では、モバイルＡＥＤとして登録済みのデバイスに割り当てられる許容範囲が、常設のＡＥＤに割り当てられた範囲よりも大きくなり得る。車両内に配置されているモバイルＡＥＤは、その状態および位置をＡＥＤレスポンスサーバに最後に報告してからかなり遠くまで移動している可能性があるため、このことは望ましい。別の例では、インシデントの場所がＡＥＤの数が多くない地方の場合、範囲のしきい値は、インシデントの場所が登録済みのＡＥＤの数が多い大都市地域内の場合よりも大きくなり得る。潜在的に近隣にあるＡＥＤのこの最初の特定において使用される特定の範囲のしきい値は、幅広く変化し得る。いくつかの場合において、この最初のフィルタリングは非常に広範囲（例えば、いくつかの用途では５０マイル（８０，５キロメートル）または８０マイル（１２８．７キロメートル））であってもよく、任意の特定の設定および／または登録済みのＡＥＤのクラスに適切であるように、著しくより焦点が絞られていてもよい（例えば、数マイル以下（１．６×数キロメートル以下））。いくつかの実施形態では、追加のまたは他のフィルタリングを使用して、潜在的に利用可能な１組のＡＥＤを特定することができる。

ステップ２７４において、状態クエリまたは「チェックイン」メッセージが、特定されたＡＥＤの各々に、またはそのような任意の所望の一部のＡＥＤに送信される（ブロック２７４）。これは、ＡＥＤの「ピンギング」または「ポーリング」として参照されることもある。ピンギングされたＡＥＤは各々、現在の位置および動作状態を提供する「現在の状態」メッセージで応答する（ステップ２７８）。これにより、ＡＥＤレスポンスサーバは、特定されたＡＥＤに関する最新情報を得て、デバイスとの通信が可能であることが効果的に確認される。送信される特定の現在の状態情報は、幅広く変化し得るが、好ましくは、少なくともデバイスの現在の位置および動作状態を含む。報告される動作状態は、ＡＥＤによって実行された最新の状態チェックの結果を含み得る。このような状態レポートは、非常に単純なもの（例えば、動作可能／動作不能）であってもよく、またはバッテリーの充電レベル、パッドの有効期限、最近のセルフテスト結果などのより詳細な情報を含むものであってもよい。元の要求（「チェックイン」メッセージ）および応答（現在の状態メッセージ）において転送されるデータの量は非常に小さいため、非常に迅速にやり取りすることができることを理解されたい。メッセージは、例えば、ＳＭＳメッセージを含む、ＡＥＤによってサポートされている様々な通信プロトコルのいずれかを使用して送信され得る。

いくつかの実施形態では、状態クエリを受信するＡＥＤ（ブロック２７５）は、状態クエリが受信される第１の通信チャネルとは異なる第２の通信チャネルを介してＡＥＤレスポンスネットワークサーバ２０との接続を確立することによって、クエリに応答する（ブロック２７６）。次に、現在の状態メッセージがこの第２の通信チャネルを介して送信される（ブロック２７８）。いくつかの実施形態では、第１および第２の通信チャネルは、異なる通信プロトコルを使用するが、これは必要条件ではない。例えば、状態クエリは、メッセージングテクノロジ（例えば、ＳＭＳ）を使用して送受信され得るが、接続は、ＩＰプロトコル（例えば、ＴＣＰ／ＩＰ）などの別の通信プロトコルを使用して確立され得る。参照により本明細書に組み込まれる、２０１９年９月３日に出願された米国仮出願第６２／８９５，０７１号にさらに詳細に記載されているように、セキュリティの観点から、そのような別個のチャネルアプローチにはいくつかの重要な利点がある。別個のチャネルアプローチは特に良好に機能し、いくつかの明確な利点があるが、他の実施形態では必要とされない。

ＡＥＤレスポンスネットワークサーバは、ピンギングされたＡＥＤから現在の状態メッセージを受信すると（ブロック２７９）、インシデントの近隣のＡＥＤの現在の位置および動作状態を含む更新されたＡＥＤマップを効果的に作成する。

いくつかの実施形態では、いくらか類似したアプローチを使用して、登録済みのボランティアレスポンダをポーリングして、現在の位置を決定／確認し、それらのデバイスが通信できることを確認することができる（そのような位置特定サービスがボランティアレスポンダによる同意を得ている場合）。代替的に、ボランティアが他のタイプの位置特定サービスに同意している場合、サーバは、他の適切な方法でボランティアの位置を追跡または決定することができる。例えば、ほとんどのスマートフォンは、位置特定サービスをサポートしており、ユーザは、各アプリごとに位置情報共有の望ましいレベルを設定することが可能である。ボランティアが自身の位置をＡＥＤレスポンダネットワークと常に共有することに同意している場合、ＡＥＤサーバは、ボランティアの現在の位置に直ちにアクセスすることができ、そのような状況では、ボランティアのデバイスにピンギングして現在の位置を決定する必要はない。同様に、ボランティアが偶然にＡＥＤアプリを開いており、ＡＥＤアプリの使用中に位置情報を共有することに同意している場合、サーバは、ボランティアレスポンダの位置を知り得る。他の状況では、ＡＥＤレスポンダネットワークサーバが、ボランティアの現在の位置を特定する実用的な方法を有していない場合がある。そのような状況では、登録済みの、予想される、または最後に知った地域を使用して、ボランティアレスポンダの可能性のある位置を決定してもよい。使用される位置特定アプローチに関係なく、サーバは、近隣のＡＥＤの場所および状態の確認と並行して、近隣のレスポンダの位置を決定してもよい。

位置および動作状態情報が手元にある状態で、サーバ２０は、ブロック２８０によって表されるように、どの接続されたＡＥＤおよび／またはボランティアレスポンダに近隣の救急インシデントメッセージを送信するかを決定する。「近隣の」インシデントを通知するために特定のデバイス／レスポンダを選択するために使用される特定のプロトコルは、様々な要因および特定の実施形態の認知された必要性に基づいて幅広く変化し得る。例えば、いくつかの実施形態では、近隣救急インシデントメッセージが、インシデントの「近隣」と見なされる全てのボランティア／デバイスに送信され得る。「近隣」と見なされるものの詳細は、大きく変化し得る。一例として、いくつかの実施形態では、近隣救急インシデントメッセージは、インシデントの指定された半径内にある任意のボランティア／デバイスに送信され得る。そのような場合、指定された半径は、通知に応答するレスポンダが、有効と考えられる時間内にインシデントに直ちに到達することができるように設定されることが好ましい。いくつかの実施形態では、指定された半径内にボランティアまたは接続された除細動器が存在していないことが分かっている場合、インシデントから第２の（より長い）距離内にある限り、最も近い既知のボランティア／接続された除細動器（単数または複数）に通知が送信され得る。当然ながら、指定された半径は、インシデントの通知がレスポンダまたはＡＥＤのどちら宛のものであるか、ＡＥＤがモバイルＡＥＤまたは常設ＡＥＤであるかどうか、ボランティアレスポンダがＡＥＤを所有することになっているか、所有していることが分かっているか、または所有していると見られているか、または様々な他の要因に基づいて異なり得る。

好ましくは、潜在的に利用可能なＡＥＤの最初の特定に使用される任意の距離（ブロック２７２）は、アラートされるべきＡＥＤの選択に使用される任意の距離（ブロック２８０）よりも大きい。これにより、ＡＥＤの確実なプールからの選択が保証されるとともに、初期の領域内に十分に適格なＡＥＤが存在しないか、または十分に適格なＡＥＤでない場合に、ＡＥＤに通知される地理的領域を即座に拡大する柔軟性が提供される。

インシデントアラートの送信先の選択は、インシデントからの距離に加えて（またはその代わりに）、いくつかの要因およびランキングに基づいて行うことができる。例えば、潜在的なレスポンダが現場に到着するのに要する時間を推定し、アラートの送信先を決定する際にその知識を利用することが望ましい場合がある。このような推定値は、レスポンダの予想移動速度（例えば、歩いたり、走ったり、または車に乗っている可能性が高いか）、現場まで歩いたり、走ったり、運転したりする速度などの要因に加えて、レスポンダがインシデントに到達するために移動する必要があると思われる実際の移動距離（または経路）の推定値に基づくことができる。

多くの場合、潜在的なレスポンダ／ＡＥＤがインシデントに到達するために移動する必要があり得る経路は、インシデントまでの直線距離（半径）とは全く異なり得る。例えば、都市では、レスポンダは、アクセスできない建物または区画を通り抜けるのではなく、歩道、道路、または通路に沿って移動する必要がある場合がある。地方では、川またはその他の障害物により、レスポンダがインシデントに直行できない場合がある。従って、状況によっては、レスポンダからの半径／直線距離を単に使用するのではなく、各レスポンダがインシデントに到達するために移動する必要があると思われる距離（または経路）の推定値が、距離の決定に使用され得る。いくつかのそのようなアプローチは、参照により本明細書に組み込まれる米国仮出願第６２／８３４，１３７号に記載されている。

あまりにも多くのボランティアレスポンダに通知を送信することは逆効果であるといういくつかの証拠がある。これは、アラート疲労（ａｌｅｒｔ ｆａｔｉｇｕｅ）に部分的に起因するものと考えられている。従って、一般のレスポンダが、自分が５番目のボランティアレスポンダであることを確認するためにのみインシデントに応答し、自分の救援が実際には必要とされていない場合、一般のレスポンダは、その後のインシデントアラートに迅速に応答する可能性が低くなり得る。従って、いくつかの実施形態では、複数の潜在的なレスポンダがインシデントの範囲内に存在する場合、特定のインシデントについて最初に通知される特定のレスポンダの一部を選択することが望ましいか、または好ましい。つまり、最初のインシデントアラートは、選択した１組のレスポンダおよび／またはＡＥＤにのみ送信される。これらのレスポンダの１人または複数が対応するために要求を受け入れる場合、インシデントに対してそれ以上のインシデントアラートは必要とされない。あるいは、最初に通知されたレスポンダがインシデントを受け入れない（またはレスポンダが不足している）場合、適切と判断された場合には、第２の組などに通知を送信することができる。そのような第２の組は、所望の通知プロトコルに従って、近隣の全てのレスポンダまたは別の一部のレスポンダであり得る。

考慮することができる別の基準は、ボランティアレスポンダのインシデント対応履歴である。例えば、レスポンダが以前のインシデントについて通知を受けた場合、レスポンダは以前の通知（単数または複数）に対して対応したか、またはしなかったかどうかである。対応した場合、レスポンダはどれくらい迅速に応答したか。一般に、他の要因が同じである場合、以前のアラートに対応していないか、または対応する頻度が低い人よりも、全ての以前のアラートに迅速対応した人にアラートを送信する方がより望ましい。別の要因は、レスポンダが以前に救急シナリオでＡＥＤを正常に使用したかどうかである。いくつかの研究では、ＡＥＤで人を蘇生させた経験のある一般のレスポンダは、実際の心停止の状況での経験がない人よりも、統計的に成功する結果が高いことが示唆されており、実際の救急時にＡＥＤを使用した経験のない訓練を受けた医療従事者の結果を上回ることさえあるため、この情報は有用である。

インシデントアラートを送信するＡＥＤの決定は、一般的に類似した様々な基準に加えて、様々な異なるより多くのＡＥＤ固有の基準に基づいて行うことができる。例えば、移動経路の距離およびインシデント対応履歴などの要因が、ＡＥＤの選択にも同様に関係する可能性がある。インシデント対応履歴の関連性は、ＡＥＤの使用について数人の訓練を受けた学校事務所に設置されているＡＥＤと、建物の交通量の少ないロビーに設置されているＡＥＤを比較することによって、評価することができる。さらに、選択したＡＥＤ状態情報をＡＥＤの選択において使用することもできる。例えば、ＡＥＤレスポンスネットワークサーバが潜在的に利用可能なＡＥＤに関する状態情報を有している場合、サーバは、ＡＥＤが適切なインシデント通知ターゲットであるかどうかを判定する際に、その情報を使用することができる。例えば、ＡＥＤが動作不能である場合、そのＡＥＤは考慮から除外される。ＡＥＤのバッテリー残量が少ないか、または電極パッドが古いが使用可能である可能性が高い場合には、ＡＥＤの優先度レベルを下げるか、または他の実行可能な選択肢がある場合には、考慮から除外され得る。

いくつかの実施形態では、機械学習を利用して、特定のＡＥＤおよびボランティアレスポンダを選択してインシデントを通知するために使用されるＡＩベースのボランティアレスポンダ／ＡＥＤ選択エンジンを訓練することができる。機械学習アプローチの利点は、選択モデルを定期的に更新してパフォーマンスを向上することができることである。時間の経過とともに、機械学習は、肯定的な結果に最大の影響を与えると判定した要因を本質的に重み付けし、それによって時間の経過とともに選択エンジンのパフォーマンスを向上させる。

いくつかの特定の要因が説明されているが、特定のインシデントアラートを誰および／またはどのデバイス（単数または複数）に送信するべきかを決定する際にどのような特定の要因を考慮すべきかに関する決定、およびこれらの要因および他の要因の相対的な重み付けに関する決定は、全て、特定のシステムの設計目標を満たすように幅広く変化させることができることは明らかである。例として、参照により本明細書に組み込まれる米国仮出願第６２／８３４，１３７号には、上記で参照されたもののいくつかおよび他のものをより詳細に含む、様々なレスポンダＡＥＤの選択基準が記載されている。

図２Ｄに戻ると、サーバは、通知のために選択された各ＡＥＤ（ブロック２８２）および通知のために選択された各ボランティアレスポンダに近隣のインシデントメッセージを送信する。チェックイン状態クエリに応答してＡＥＤがＡＥＤネットワークサーバ２０との接続を開いた実施形態では（ブロック２７６）、その通信チャネルを介して近隣のインシデントメッセージが送信される。近隣のインシデントメッセージがＡＥＤによって受信されると（ブロック２８３）、図２Ａに関して上記で説明したように、ＡＥＤは、近隣のインシデントアラートを生成する（ブロック２８５）。アラートは、好ましくは、音声アラートコンポーネントと、ＡＥＤに関連付けられたディスプレイ上に表示される視覚アラートコンポーネントの両方を含む。視覚的アラートは、好ましくは、選択されたときに誰かがＡＥＤをピックアップし、インシデントに対応していることを示したことをサーバに通知するインシデント受け入れボタンなどのＧＵＩウィジェットを含むカード／フレーム／ペイン等を含む。インシデント受け入れボタンまたは他のＧＵＩウィジェットに関連付けられた特定のテキストまたはグラフィックは幅広く存在し得るが、インシデントが受け入れられると（決定ブロック２８７）、インシデント受け入れメッセージがＡＥＤサーバに送信される（ブロック２８８、２８９）。例として、以下に説明するいくつかの特定のインタフェースにおいて、図４Ｂの「救援可能」ボタン４１３および図５Ａの「救急事態への案内」ボタン５０３は、適切なインシデント受け入れボタンの好適な例である。

インシデントが受け入れられると、ＡＥＤレスポンスネットワークサーバは、必要に応じてＡＥＤと通信して、ボランティアをインシデントに誘導し、適切に応答する（ブロック２９０、２９１）。例として、図５Ａ〜図５Ｈは、近隣のインシデントアラートに応答してＡＥＤをピックアップしたレスポンダに指示するのに適したアプリフローおよびユーザインタフェースを示す代表的なカードのシーケンスを示す。

ＡＥＤネットワークサーバは、好ましくは、インシデントの進行を監視し、支援または追加の支援が不要になった場合にＡＥＤアラートを終了することとなる。サーバがレスポンダ（または追加のレスポンダ）が不要になったと判定すると（ブロック２９３）、サーバは、個々のアラートに対する応答していないＡＥＤにメッセージを送信する（ブロック２９５）。ＡＥＤがアラートキャンセルメッセージを受信すると（ブロック２９６）、ＡＥＤはアラートをキャンセルする（ブロック２９７）。

ネットワークサーバが近隣のインシデントアラートをキャンセルする原因となる様々なトリガが存在する。例えば、支援の要求を開始する責務がある救急コール２５は、救急医療従事者（例えば、ＥＭＴ、救急医療隊員、救急車）が現場に到着したこと、または、他の除細動器が現場に持ち込まれたこと、または、ＡＥＤが不要である（またはもはや不要である）と他の方法で判定されたことを知った場合に、要求を肯定的にキャンセルし得る。同様に、アプリを使用してＡＥＤ支援の要求を開始したインシデントにおけるバイスタンダーが、同様の状況で要求をキャンセルする場合がある。他のシナリオでは、ＡＥＤネットワークサーバ自体が、様々な理由のいずれかでアラートのキャンセルを決定する場合がある。例えば、上記のように、指定された数のＡＥＤおよび／またはボランティアがインシデントに応答していることを示した後、対応しないデバイスによって生成されたアラートをキャンセルすることが望ましい。

別の例では、対応するボランティアは、ＡＥＤディスプレイまたはボランティアレスポンダのアプリの「到着した」ボタンなどの適切なＧＵＩウィジェットを選択することによって、ＡＥＤとともに現場に到着したことを示すことができる。除細動器が現場に到着したこと（または、望ましいと思われる場合、複数の除細動器やボランティアが現場に到着したこと）がＡＥＤネットワークサーバに通知されると、ＡＥＤネットワークサーバは、アラートキャンセルメッセージを他のアラート状態のＡＥＤに送信することができる。必要に応じて、追加のＡＥＤが不要な場合でも、追加のボランティアの救援を要求することができるように、ＡＥＤアラートキャンセルの決定をボランティアアラートのキャンセルとは別に行うことができる。

別の例では、ＡＥＤは、ＡＥＤが展開されたときにＡＥＤサーバに通知するように構成され得る。このような状況では、ＡＥＤネットワークサーバは、対応するＡＥＤがインシデントの場所において展開されていると判定されたときに、アラートキャンセルメッセージを送信するように構成することができる。このような通知は、例えば、（１）ＡＥＤ上の「電源オン」ボタンを起動したこと、（２）電極パッドの収納位置からの引き出し、またはパッドカートリッジのＡＥＤからの引き出し、（３）患者へのパッドの装着、（４）心調律等の検出のいずれかに基づく様々な異なる動作のいずれかによってトリガすることができる。任意選択的に、そのような通知は、ＡＥＤの場所を含むことができる。

いくつかの実施形態では、近隣のインシデントアラートに応答してピックアップされた任意のＡＥＤは、その位置をＡＥＤサーバ２０に定期的に送信し得る。これは、サーバがユーザに適切な指示を提供するのに有用である。そのような位置の更新が利用可能である場合、ＡＥＤサーバは、ＡＥＤがいつ現場に到着したかを決定し、少なくとも部分的に、そのような情報をアラートキャンセルメッセージのベースとすることができる。

ボランティアレスポンダに送信される近隣のインシデントメッセージは、ＡＥＤに関して上記で説明したアプローチと一般的に同様の方法で処理され得る。図４Ａ〜図４Ｈは、登録済みのレスポンダを近隣のインシデントに誘導するのに適したアプリフローおよびユーザインタフェースを示す代表的なカードのシーケンスを示す。

近隣のインシデントメッセージは、様々な異なるテクノロジのいずれかを使用してボランティアレスポンダに送信され得る。一般に、ボランティアレスポンダは、携帯電話またはその他のモバイル通信デバイス上にＡＥＤアプリまたはＡＥＤレスポンダアプリを有していることになっている。最近のほとんどの携帯電話には、ユーザに通知をプッシュするために使用することができる通知サービスがある。アップル（Ａｐｐｌｅ（登録商標）デバイスにはアップルプッシュ通知サービス（ＡＰＮ）が組み込まれ、アンドロイド（Ａｎｄｒｏｉｄ（登録商標））デバイスには通知サービスが含まれる。これらの各サービスを使用して、アプリのＵＩ以外にボランティアのデバイス上に表示される通知をボランティアレスポンダにプッシュすることができる。通知は、ＡＥＤアプリを開くか、通知から直接動作を実行するように構成することができる。例えば、いくつかの実施形態では、通知または通知内の特定のボタンをタップすることによって、ユーザが通知から直接的にインシデントを受け入れることができるように、通知内のメッセージを構成することができる。代替的に、図４Ａの通知４０２などの通知は、ボランティアが通知をタップしたときにＡＥＤアプリを開くように構成され得、インシデントおよび／またはインシデント受け入れボタン４１３に関する詳細は、図４Ｂに示されるようにアプリにおいて提示され得る。

上記の説明では、状態クエリは、潜在的に利用可能な１組のＡＥＤが特定された後に送信されるものとして説明されている。同様に、近隣のインシデントメッセージは、ＡＥＤネットワークサーバがアラート対象のＡＥＤを特定した後に送信されるものとして説明されている。これらは必ずしも線形的に連続したステップである必要はないことを理解されたい。例えば、必要に応じて、サーバは、潜在的な候補が全て特定されているかどうかに関係なく、デバイスが候補として特定されるとすぐに、任意の選択されたＡＥＤに状態クエリまたは近隣のインシデントメッセージを送信することができる。そのため、ネットワークの遅延およびデバイスの設定などの要因により、状態クエリが送信されてから応答的な状態レポートが受信されるまでに遅延が発生する場合があり、デバイスによって応答時間が異なり得る（場合によっては大幅に異なり得る）ことが予想されることを理解されたい。従って、必要に応じて、インシデントアラートを送信するデバイスの選択は、ＡＥＤネットワークサーバで利用可能な情報に基づくことができ、かつ近隣のインシデントメッセージを他のＡＥＤに送信することによって、かつ／または新たな情報を受け取ったときに他のＡＥＤに送信されたアラートを適切にキャンセルすることによって更新され得る。特定の例では、インシデントの指定された（比較的近い）範囲内にある任意のＡＥＤには、状態レポートの受信または接続の確立の直後に通知される近隣のインシデントメッセージが送信される。

さらに、事前に保存された情報に基づいて、選択したＡＥＤに近隣のインシデントメッセージを送信することが望ましい状況があり得る。この好適な例は、固定位置ＡＥＤとして指定されたＡＥＤが最近状態を更新し、良好な動作状態にあることがわかっている場合である。このような状況では、ＡＥＤがそのようなメッセージを受信して処理する機能を備えている場合（例えば、ＡＥＤが近隣のインシデントメッセージが送信される接続を開始する必要がない場合）、チェックインまたは状態クエリを最初に送信することなく、近隣のインシデントメッセージをＡＥＤに直ちに送信することが望ましい場合がある。代替的に、そのような近隣のインシデントメッセージは、接続が必要とされる場合に接続を確立すると直ちに送信することができる。

次に図３Ａ〜図３Ｇを参照して、潜在的な心停止の現場から近隣の公衆レスポンダに救援を要求することを可能にする代表的なユーザインタフェースを説明する。これらの図は、心臓異常の目撃者が除細動器が必要である可能性があるが、インシデントの場所にないと判定した状況に適した一連のカードを示す。説明されているフローは、目撃者が携帯電話または他の直ちに利用可能なモバイル通信デバイスにＡＥＤアプリ（または他の適用可能な救急アプリ）をインストールしていることを想定している。

最初に、ユーザ（例えば、目撃者、バイスタンダー他）は、適切に起動するモバイルデバイス上でＡＥＤアプリを起動させる。いくつかの実施形態では、起動時に現れる最初のカード３１０は、図３Ａに示されるマップなどのＡＥＤロケーションマップ３１２であり得る。グーグルマップ、トムトム（ＴｏｍＴｏｍ）（例えば、アップルマップで使用される）、マップクエストなどのように、公衆に利用可能な様々なモバイルマッピングサービスのいずれかをロケーションマップ３１２のプラットフォームとして使用することができる。ＡＥＤロケーションマップ３１２は、ユーザの現在の位置を示すロケーション識別子３１６と、システムに登録されているか、さもなければ知られている近隣の公衆ＡＥＤの位置を示すマーカー３１８とを有する。図示の実施形態では、ＡＥＤマップは、近隣のボランティアレスポンダへの救援の通報として機能する「ＡＥＤにアラートする」バナー３１４を含む。他の実施形態では、開始カードまたはビューは変化し得、ＡＥＤにアラートする機能は他の方法でアクセスされ得る。

ＡＥＤにアラートするバナー３１４を選択すると、アプリは救急アラートモードに入り、図３Ｂに示すように、確認ペイン３２０が表示（または拡大）されて、これが緊急事態であることを確認するようにユーザに要求する。この確認は、ユーザが本当にアラートの送信を望んでいることを確認するための検証チェックとして機能する。図示の実施形態では、アラートを発行したいという要望は、「緊急事態の確認」ボタン３２１を選択することによって確認することができる。しかしながら、他の実施形態では、多種多様な他のＧＵＩ入力機構を使用して、アラートを発行する意図を確認することができることを理解されたい。緊急事態の確認ボタン３２１を選択すると、図３Ｃに示すように、位置確認ペイン３２５が表示される。位置確認ペインは、ユーザ（従って緊急事態）の検出された位置を表示するダイアログボックスを含み、ユーザは、表示された住所を確認（または修正）し、例えば、建物の階、および／またはオフィスやアパートのユニット番号など、レスポンダが必要とする可能性のあるその他の位置情報を入力するように要求される。ペイン３２５はまた、ユーザが位置を確認したときに選択される「位置確認」ボタン３２８を含む。

図示の実施形態では、ユーザが位置確認ボタン３２８を選択するとアラートが起動して、図３Ｄから分かるように、「アラートコミュニティ」ペイン３３０が表示されて、アラートがコミュニティにブロードキャストされたことをユーザに通知する。最初に説明される実施形態では、コミュニティは、登録済みのボランティアレスポンダと、システムによってインシデントに近いと認識され、従って、タイムリーにインシデントに対応できる可能性が最も高い任意のアラート可能なＡＥＤとを含む。

いくつかの実施形態では、アプリ内でユーザによって行われた選択の各々は、サーバが潜在的な心停止インシデントアクションの可視性を有するように、ＡＥＤレスポンスネットワークサーバ２０に送信される。サーバは、インシデントの場所の確認を受信すると、インシデントに近い登録済みのボランティアレスポンダに近隣の救急通知を送信し、そのようなアラートを受信して対応することが可能な近隣のＡＥＤに救急アラートを送信する。ＡＥＤレスポンスネットワークサーバは、様々な選択基準と選択アルゴリズムとを使用して、どのボランティアレスポンダおよび公衆アクセスＡＥＤが通知されるべきであるかを決定することができる。例えば、いくつかの実施形態では、インシデントの指定された半径内のレスポンダおよびＡＥＤが候補として特定される（例えば、徒歩２分以内など）。指定された範囲内にボランティアレスポンダがいないか、非常に少ない（例えば、１人のみ）場合は、現実的にインシデントの現場に到達することが可能であり得る潜在的なボランティアレスポンダ（または追加の潜在的なボランティアレスポンダ）を特定するために、範囲をいくらか拡大することができる。同様のアプローチを使用して、潜在的な公衆アクセスＡＥＤにアラートを送信することができる。

いくつかの実施形態では、ＡＥＤレスポンスネットワークサーバ２０は、ボランティアネットワークへの通知と並行して、適切な従来の救急サービスにインシデントを通知するように構成される。

アラートが生成された後、図３Ｅから分かるように、表示は、ホーム画面（例えば、マップカード３１２）に戻ることができ、画面上にユーザに有用であり得る様々な機能が表示され得る。例えば、図３Ｅに示される実施形態は、ライブアップデートダイアログボックス３４１、ＣＰＲガイドボタン３４３、救急サービスへの連絡機能３４５、および終了ボタン３４７を含む。ライブアップデートダイアログボックス３４１は、アラートの状態を提供し、少なくとも救援が到着するまで、必要に応じて更新され得る。例えば、図３Ｅに示すビューでは、ライブアップデートダイアログボックス内の通知により、アラートした潜在的なレスポンダおよび／またはＡＥＤの数がユーザに通知され、ＣＰＲを開始する方向などの適切な提案が提供される。いくつかの実施形態では、ライブアップデートダイアログボックスは、レスポンダ（または何人）が（もし存在すれば）ＡＥＤとともにインシデントに向かっていることを示したことを示すために適宜更新される。いくつかの実施形態では、マップ３１２は、例えば、図３Ｆに見られるように、そのようなレスポンダ３４８のおおよその位置および／またはレスポンダ３４８がインシデントに向かって移動するときの進行を表示するように構成され得る。

ＣＰＲガイドボタン３４３または他の適切なＧＵＩインタフェースは、ＣＰＲガイドへのリンクを提供する。ＣＰＲガイドが起動すると、ＣＰＲの実行方法に関するグラフィカルおよび音声の指示が提供される。救急サービスへの連絡機能３４５は、ユーザによって選択されたときに救急サービス（例えば、米国における９１１）への通報を開始するボタンまたは他のＧＵＩインタフェースの形をとり得る。一般的に、ユーザがこの時点に到着するかなり前に救急サービスに連絡していることが予想されるが、アプリ内から救急サービスに連絡する機能は、ユーザがアプリを終了する必要なしに救急サービスに連絡することができるため有用である。終了ボタン３４７は、救急アラートモードを終了するため、および／またはアプリの他の機能にアクセスするための機構を提供する。いくつかの実施形態では、終了ボタン３４７を押すと、救急機能を終了するために選択された終了確認ボタンを有する終了確認ペインが生じる。

いくつかの実施形態では、アプリはまた、いくつかの限定的なアプリ内メッセージング機能をサポートするように構成されている。具体的には、アプリは、必要に応じて、救急アラートを生成した人にレスポンダがメッセージを送信することができるように構成されている。いくつかの実施形態では、アラートの開始者にメッセージを送ることができる唯一の人は、近隣の救急アラートに対応していることを肯定的に示した人（例えば、ボランティアレスポンダ）である。他の実施形態では、ＥＭＳレスポンダは、追加的または代替的に、アラートを生成した人にメッセージを送ってもよい。一般に、アラートを生成した人の気を散らさないように、特にその人が例えばＣＰＲを実行するなどして、インシデントに対応しているときは、そのようなメッセージを最小限に抑えることが望ましいと考えられている。しかしながら、例えば、レスポンダがその場所に到着したが建物の中に入ることができない場合、建物内の特定の場所に関するより具体的な道順が必要な場合など、メッセージを送信する機能が非常に有用である場合がある。代表的なメッセージングインタフェースを図３Ｆおよび３Ｇに示す。

図３Ｆにおいて、以下で詳細に説明するように、レスポンダが進行中であることを示している、ライブアップデートダイアログボックス３４１に表示されるメッセージは、自身のエリアでアラートの通知を受け取ったボランティアレスポンダがアラートを受信し、かつ手元にあるＡＥＤとともにインシデントに向かっていることを確認すると生成され得るメッセージである。図３Ｆはまた、アクティブなレスポンダがアラートジェネレータにメッセージを送信したことを示すメッセージ通知バナー３５１を示している。メッセージバナーを選択すると、図３Ｇに最もよく示されているように、メッセージを表示するメッセージダイアログボックス３５３が開く。当然ながら、他の様々なＧＵＩ構造を使用して、受信したメッセージにアクセスし、かつ／または表示することができる。

図４Ａ〜図４Ｈは、ＡＥＤの効果を得る可能性のある近隣の心臓異常を登録済みのレスポンダに通知して、インシデントに対するレスポンダの応答をガイドするのに適した、代表的なアプリフローおよびユーザインタフェースを示す一連のカードである。図２および図３を参照して上記で説明したように、心臓異常の目撃者または他の適切なソース（例えば、救急サービス）が、ＡＥＤが必要であることを示すプッシュ通知インシデントアラートを発行すると、ＡＥＤレスポンスネットワークサーバ２０は、インシデントの指定された有用な範囲内に存在すると思われる登録済みのボランティアレスポンダに近隣救急アラートを発行する。

図４Ａは、各通知された潜在的レスポンダの携帯電話またはそのような通知を受信するように設定された他のデバイスの表示画面上に表示される代表的な通知４０２を示す。いくつかの実施形態では、音声アラートおよび／または振動が、表示されたアラートとともに生成されて、ボランティアレスポンダの注意を通知に引き付けるのに有用となるようにする。通常、ユーザは、適切な通知設定を介して、近隣救急アラートに応答して生成される音声の種類を選択することができる。

通知４０２を選択すると、レスポンダのデバイスにインストールされている除細動器アプリが開くか、必要に応じてフォアグラウンドに移動する。図４Ｂに示される実施形態では、ベースＡＥＤマップ３１２の上にダイアログボックス４１０が表示される。ダイアログボックス４１０は、ＡＥＤを必要とする緊急事態が近隣にあることを説明し、ボランティアレスポンダが救援することができるかどうかを尋ねる。レスポンダが救援することができることを示すために、通知済みのレスポンダによって選択され得る「救援する意思がある」ボタン４１３または他のＧＵＩインタフェースが提供される。代わりに、レスポンダが支援することができない場合、キャンセルボタン４１６または他の適切なＧＵＩインタフェースを選択することによって、レスポンダは応答フローを終了することができる。アラートが生成されての経過時間を示すために、タイミングインジケータ４１７を任意選択的に提供することができる。

レスポンダが救援することができることを示した場合、マップ３１２は、インシデントの場所を示すインシデントマーカー４１９を示すように更新され得る。ダイアログボックス４１０内のメッセージは、例えば、最も近い公衆に利用可能なＡＥＤへの道順を提供するために、適切に更新され得る。前に説明したように、マップ３１２は、任意の近隣に登録済みのＡＥＤ３１８の位置を示している。さらに、図４Ｄで最もよく分かるように、最も近いＡＥＤ３１８への道順４１８がマップ３１２に表示され得る。いくつかの実施形態では、ユーザは、そのＡＥＤに対応するアイコン３１８を選択することによって、任意の登録済みの公衆アクセスＡＥＤの位置に関する詳細（および他の関連情報）を取得することができる。

ユーザがＡＥＤを所持していることを示すことができる機構も提供されている。図示の実施形態では、その機構は、「ＡＥＤを所持している」ボタン４２４または他の適切なＧＵＩインタフェースの形をとる。レスポンダがＡＥＤを手元に有している場合、レスポンダは、ＡＥＤを所持していることを示すために、ＡＥＤを所持しているボタン４２４を選択する。その時点で、図４Ｅに示すように、インシデントへの道順が提供されてもよい。いくつかの状況では、レスポンダは自己所有のＡＥＤを持っているか、または最も近いＡＥＤの場所をすでに知っている場合がある。そのような状況では、「ＡＥＤを所有している」ボタン４２４を選択して、インシデントへの道順をすぐに確認し得る。

図４Ｅは、インシデントへの道順を示す代表的なユーザインタフェースを示す。この状態では、ユーザインタフェースは、「到着した」ボタン４２５、またはユーザが現場に到着したことをサーバに示すことを可能にする他のＧＵＩインタフェースを含み得る。いくつかの実施形態では、「到着した」ボタンは、レスポンダがインシデントの指定された範囲内に存在することをアプリが検出した場合にのみ表示される。

プロセス全体を通して、ダイアログボックス４１０で提供されるメッセージは、その時点での対応状態に関連するメッセージを表示するように更新され得る。例えば、マップ３１２が最も近い利用可能なＡＥＤへの道順を表示しているとき、ダイアログボックス４１０は、図４Ｄで最もよく分かるように、その行動を示すように更新され得る。マップ３１２が緊急事態への道順を表示しているとき、ダイアログボックス４１０内のメッセージは、図４Ｅから分かるように、その行動を示すように更新され得る。

いくつかの実施形態では、メッセージボタン４２７は、図４Ｆから分かるように、レスポンダが緊急事態の開始者に直接メッセージを送ることを可能にするために提供され得る。メッセージングが許可される特定の状況は、任意の対応システムの設計目標に基づいて変更され得る。例えば、いくつかの実施形態では、直接メッセージングは、レスポンダがインシデントに対応していることを示した後、いつでも許可され得る。しかしながら、他の状況では、救援の要求の開始者がＣＰＲの実施またはそれ以外に傷病者への対応から気を取られてしまう可能性を減らすために、ボランティアレスポンダからのメッセージングの可用性をより厳密に制限することが望ましい場合がある。従って、例えば、いくつかの実施形態では、メッセージング機能は、レスポンダが傷病者の所与の距離内に存在するか、または他の指定されたしきい値内に存在する場合にのみ起動され得る。

図４Ｆに示されるようなメッセージングボタン４２７が選択されると、レスポンダが救援を求める通報の開始者に直接メッセージを送ることを可能にするメッセージングインタフェースが表示される。様々な従来のメッセージングウィジェットのいずれかを使用して、メッセージング機能を提供することができる。１つの代表的なメッセージングインタフェース４４０が図４Ｇに示されている。

レスポンダが到着すると、終了機構を選択することによって、任意の時間に緊急事態を終了することができる。図４Ｆから分かるように、終了機構は、終了ボタン４３１または他の適切なＧＵＩインタフェースの形をとることができる。

いくつかの状況では、救援の要求の開始者は、ボランティアレスポンダが到着する前（または到着した後）に支援の要求をキャンセルすることがある。これは、救急医療サービスまたは別のボランティアレスポンダの到着が原因である可能性がある。救援の要求がキャンセルされた場合、他のレスポンダは、例えば、図４Ｈから分かるように、ダイアログボックス４１０内の適切なメッセージを介してキャンセルについて通知され得る。

図４Ａ〜図４Ｈは、救援が必要な近隣の救急インシデントをボランティアレスポンダに通知し、受け入れているボランティア（単数または複数）を現場に案内するのに適したアプリフローを示している。いくつかの実施形態では、救急インシデントアラートは、宣言された救急事態の近隣に物理的に配置されている接続済みの除細動器に直接送信され得る。

次に、図５Ａ−図５Ｈを参照して、公衆レスポンダネットワークの一部であり、かつインシデントの近隣に位置する公衆アクセスＡＥＤの観点から、代表的なアプリフローおよび近隣救急アラートに対する対応について説明する。この実施形態では、救急インシデントアラート除細動器の救援要求がＡＥＤレスポンスネットワークサーバ２０によって受信されると、サーバは、インシデントの近隣に位置すると分かっている任意のＡＥＤを特定する。次に、サーバは、インシデントの場所に近くに存在すると分かっているアクセス可能な各除細動器に「近隣救急インシデント」メッセージを送信する。

除細動器が近隣救急インシデントメッセージを受信すると、除細動器にインストールされているアプリがトリガされ、（ａ）近隣の人員（潜在的なレスポンダ）に救急インシデントの存在を通知するか、または救援を要求し、（ｂ）それに対応する人にインシデントの場所を指示すように構成された近隣救急モードに入る。

いくつかの実施形態では、近隣救急インシデントメッセージが受信されると、アプリは、除細動器に、除細動器の近くに偶然居合わせた潜在的なレスポンダが知覚できる警報を発する。除細動器によって発せられる警報は幅広く変化し得る。例えば、いくつかの実施形態では、通知された除細動器は、その表示画面を起動し、近隣の救急インシデントの発生を示す近隣救急メッセージフレームと、レスポンダに除細動器を救急事態の場所に持ち込むように促すプロンプトとを表示する。そのような近隣救急メッセージフレームの１つを図５Ａに示す。警報は、除細動器に注意を引く可能性が高い方法で送達されることが好ましい。いくつかの実施形態では、これは、近隣救急メッセージの点滅、または除細動器の表示画面に注意を引くための他の動作を含むことができる。いくつかの実施形態では、音声アラートが追加的または代替的に提供され得る。例えば、一連のビープ音または他の音を発して除細動器に注意を引き付け、それによって、バイスタンダーに表示されたメッセージを見るように促し、かつ／またはそれ以外の方法で潜在的なレスポンダにインシデントを知らせるようにしてもよい。他の実施形態では、音声アラートは、音声メッセージの形をとることができる。

図５Ａに示される実施形態では、近隣救急メッセージフレーム５０１は、ナビゲーションフレーム５１０へのアクセスを提供するＧＵＩボタン５０３または他のＧＵＩ要素を含む。いくつかの実施形態では、近隣救急メッセージフレーム５０１はまた、救援に関する通報がなされてから経過した時間を表示するタイマー５０６を含み得る。近隣救急メッセージフレームでボタン５０３を選択すると、ナビゲーションフレーム５１０が表示される。ナビゲーションフレーム５１０は、ユーザに救急インシデントへの移動方法を示す。図５Ｂに示される実施形態では、ナビゲーションフレーム５１０は、除細動器の現在位置５１４からインシデント５１６までを示す経路５１３を備えたマップ５１２を含む。ナビゲーションフレーム５１０はまた、救急位置に到着するまで何をすべきかをユーザに通知する指示５１７を表示すダイアログボックス５１５を表示することができる。必要に応じて、指示５１７は、ユーザがインシデントに向かって進むにつれて適切に更新され得る。様々な実施形態において、マップは、例えば、インシデントに到達する方法に関する段階的な指示（図示せず）、インシデントに到達するのに要する時間の推定値５１８、救急事態が宣言されてから経過した時間を表示するタイマー５０６など、関心のある他の情報も同様に表示するように構成され得る。マップがＧＰＳまたは他の位置感知機能を有するいくつかの実施形態では、マップは、また、除細動器の感知された動きとともに移動して、ユーザがインシデントに向かって進行していることを示す位置マーカー（図示せず）を含み得る。

ユーザが現場に到着するか、または現場に非常に接近すると、ナビゲーションフレームディスプレイに表示される情報は、任意選択的に、多少異なる情報を提供し得る「到着」フレーム５２０に移行し得る。例として、図５Ｃに示される実施形態では、マップ５１２は依然として表示されるが、指示５１７は、除細動器の使用を開始する方法を示すために変更され、かつ／または経路５１３は、除細動器が現場に到着したことを示すラベル５２３に置換され得る。

ナビゲーションフレーム５１０および到着フレーム５２０のいずれかまたは両方は、また、ユーザが上記のように救援の要求者にメッセージを送信することを可能にするメッセージング機能（図示せず）を含み得る。これは、元のメッセージに現場に到達するために必要となる可能性のある全ての情報が含まれていない場合に特に有用である。例えば、インシデントが高層ビルで発生した場合、レスポンダは建物のどの階に行くのかを尋ねる必要があるかもしれない。インシデントが施錠された建物で発生した場合、レスポンダは要求者に建物に入れるように依頼する必要があるかもしれない。当然ながら、他の様々なメッセージは、他の特定の状況で有用であるか、または、適切であり得る。

いくつかの実施形態では、ナビゲーションフレーム５１０は、また、除細動器を救急モードに移行させ、除細動器アプリを救急インシデントフローに移行させる「除細動器起動」ボタンまたは他のＧＵＩ要素を有し得る。代替的または追加的に、いくつかの実施形態では、タブを引いて電極パッドにアクセスする、除細動器上の機械的ボタンを押すなど、除細動器に対して動作を実行することによって、救急フローを起動することができる。

いくつかの実施形態では、ダイアログボックス５１５内の指示５１７は、ユーザが他の情報にアクセスすることを可能にするＧＵＩボタンまたは他のＧＵＩ要素を含み得る。例えば、図５Ｃの到着フレーム５２０において、指令５１５は、電極パッドカートリッジタブを引っ張ることが救急シーケンスを開始することを図式的に示すフレーム５３０（図５Ｄ）によって表されるように除細動器を作動させる方法に関するさらなる指示を取得するためにユーザが選択することができるボタン５２６を含む。当然ながら、他の様々な情報（説明またはその他）を同様の方法でユーザがアクセスできるようにすることができる。

除細動器が心臓インシデントの治療に使用される場合、ディスプレイコントローラは近隣救急フローから救急処理フローに移行する。ある段階で、除細動器の救急使用（救急セッション）が終了する。終了は、例えば、セッションを停止するために除細動器自体の電源オン／オフボタンを押すことによって、または画面上に表示された救急終了ＧＵＩ要素を選択することによって、多くの異なる機構を介して開始することができる。救急セッションの終了時に、セッション終了フレームが表示され得る。１つの代表的なセッション終了フレーム５５０が図５Ｅに示されている。いくつかの実施形態では、セッション終了フレームは、除細動器を所有している人に除細動器をそのホームロケーションに戻すように促すプロンプト５５２を含み得る。図５Ｅに示される実施形態では、プロンプトは、ＧＵＩボタン５５４または他のＧＵＩ要素の一部であり、選択されると、リターンマップフレームが表示される。１つの適切なリターンマップフレーム５６０が図５Ｆに示されている。例示的なフレーム５６０は、除細動器のホームロケーション５６４への道順を有するマップ５１２を含む。除細動器が元の場所に戻ると、図５Ｇに示すように、ボタンまたは他の適切な要素を任意選択的に選択して、近隣救急フローを終了することができる。

インシデントにおいて除細動器が実際に使用された場合は、電極パッドを交換する必要があり、他のメンテナンスまたは手当も必要になる場合がある。従って、除細動器がそのホームポジションに戻った後、または他の適切な時間（単数または複数）に、任意の適切な状態通知が表示画面上に表示され得る。図５Ｈは、電極パッドを交換する必要があることを所有者および他の関心のある個人に通知する代表的な状態通知フレーム５７０を示している。図示の実施形態では、パッド交換状態通知は、パッドを交換する方法に関する指示またはチュートリアルなどの有用な情報へのリンク、および／または新たなパッドを注文するための機構へのリンクを有する。

上記の説明では、近隣救急インシデントメッセージは、インシデントに近いと見なされるボランティアレスポンダおよび／または接続された除細動器に送信され得ることが指摘されている。「近隣」と見なされるものの詳細は、幅広く変化し得る。一例として、いくつかの実施形態では、近隣救急インシデントメッセージは、インシデントの指定された半径内にある任意のボランティア／デバイスに送信され得る。そのような場合、指定された半径は、通知に応答するレスポンダが、有効と考えられる時間内にインシデントに直ちに到達することができるように設定されることが好ましい。いくつかの実施形態では、指定された半径内にボランティアまたは接続された除細動器が存在していないことが分かっている場合、インシデントから第２の（より長い）距離内にある限り、最も近い既知のボランティア／接続された除細動器（単数または複数）に通知が送信され得る。

記載された応答システムを可能にするのに適したプログラムされた命令の形式のＡＥＤアプリは、任意のスマートフォン、タブレットコンピュータ、または他のモバイル通信デバイス、および／または他の任意の適切なコンピューティングデバイス上のメモリ内にインストールされ得る。プログラムされた命令は、そのようなデバイスに設けられるプロセッサ（または複数のプロセッサ）によって実行されるように構成され得る。

同様に、記載された除細動器応答システムを可能にするための除細動器コントロールアプリまたは他の適切な除細動器対応ソフトウェアが、除細動器のメモリ内にインストールされ得る。プログラムされた命令は、除細動器プロセッサ（または複数のプロセッサ）または除細動器に常駐する除細動器コントローラによって実行されるように構成され得る。いくつかの実施形態では、除細動器応答システムは、除細動器プロセッサまたはコントローラによって実行されるように、ＡＥＤのメモリにダウンロードされ、ＡＥＤにインストールされるように構成されたダウンロード可能なソフトウェアアプリの一部である。このようなアプリベースのダウンロードおよびインストールプロセスにより、アプリの機能（従って除細動器の機能）をタイムリーかつ信頼性の高い方法で更新する機能が大幅に簡素化される。

いくつかの状況では、専門の第一レスポンダが報告された緊急事態の現場に到着したときに、報告された緊急事態の現場に到着したという事実を通信指令係に報告する場合がある。その他の場合、第一レスポンダ自身が、プライマリＣＡＤシステムに接続された救急派遣製品を使用して救急インシデントの記録を直接更新し得る。救急インシデントの記録が、専門の第一レスポンダが報告された救急インシデントの現場に到着したという情報で更新されると、ＣＡＤシステムは、ＡＥＤレスポンスネットワークサーバ上の救急インシデント記録をこの情報で更新してもよい。その後、サーバは、ネットワーク内のレスポンダおよびＡＥＤに、サービスおよび救急対応の継続的な必要性がなくなったことを報告し得る。

ＡＥＤマップの機能
いくつかの実施形態では、ＡＥＤマップ上で特定されたＡＥＤは、ＡＥＤが実際にその所定の場所にあるという確信を示す方法で、マーク付けされ、強調表示され、または他の方法で識別され得る。例えば、いくつかの実施形態では、複数のカテゴリが特定され得る。いくつかのＡＥＤは、ＧＰＳなどの位置特定機能を備えた接続デバイスである。システムは、そのようなデバイスが実際にその場所（これはいつでも確認できる）を報告しているため、実際にデバイスが存在すると伝える場所に存在しているという高い信頼性を有することができる。いくつかの実施形態では、そのようなＡＥＤは、任意の適切な診断を実行し、その位置をＡＥＤレスポンスネットワークサーバ２０に報告するために、定期的な間隔（例えば、１日１回または他の適切な期間）で起動されるようにすることができる。診断では、ＡＥＤが正常な動作状態にあるかどうかが報告されるため、ＡＥＤの動作状態も分かる。従って、ＡＥＤレスポンスネットワークサーバ２０は、（ａ）ＡＥＤがどこに位置するのか、（ｂ）ＡＥＤが高い信頼度で正常に動作していることの両方を知っており、そのようなユニットを、例えば、ＡＥＤマップ上のＡＥＤを表すアイコン３１８を赤などの第１の色で表示することによって、高い信頼度を示す方法でＡＥＤ上に表示することができる。何らかの理由でＡＥＤが正常に動作していないと判定された場合は、ＡＥＤをＡＥＤマップから削除して、潜在的なユーザが動作不能なＡＥＤを探すように促されないようにすることができる。同様に、その場所を自己確認できない場合は、他の方法でその場所を確認できない限り、ＡＥＤをＡＥＤマップから削除することができる。

第２のレベルの信頼性は、それ自体が位置特定機能を備えた接続デバイスではないが、位置および動作を定期的に検証することができるデバイスに適用され得るる。これを行うための１つの方法は、所有者または管理者に、除細動器アプリを実行する携帯電話または他のモバイルデバイスをＡＥＤユニットと定期的にペアリングして、ユニットとサーバとの間で情報を送信するためのパイプとして機能するように要求することが挙げられる。このようにして、例えば、更新された診断レポートを、報告デバイスが正常に動作していることを確認することができるサーバに伝達することを含んで、様々な情報を転送することができる。このようなデバイスの場合、ＡＥＤの位置は、ペアリングされたデバイスの位置によって決定することができる。当然ながら、そのようなデバイスの動作および位置は、他の適切な方法でも確認することができる。いくつかの実施形態では、比較的最近に動作および位置の両方が検証されたデバイスをＡＥＤマップ上に第２の色（灰色など）で表示して、デバイスが動作可能であることと、指定された位置に存在していることとの両方であるというサーバが有する信頼性のレベルをグラフで示すことができる。

第３のレベルの信頼性は、動作状態をサーバに伝達することができないデバイスに適用され得る。このようなデバイスの位置は、適切な方法で関係者によって報告することができ、このようなデバイスは、ＡＥＤマップ上に第３の色または形式で表示され得る。当然ながら、必要に応じて、他のカテゴリまたは信頼性レベルを想定し、ＡＥＤマップ上で任意の方法で表現することができる。

救急コールセンターの統合
上記の説明のいくつかで提案されているように、ＡＥＤレスポンダネットワークを救急コールセンターと統合することには大きな利点があり、そのようなシステムは過去に一般的に提案されている。しかしながら、実際には、このようなシステムの実施には大きな障壁がある。実用的な障壁の１つは、多種多様な団体によって運営または監視されている救急派遣センターが多数あることである。従って、組織、プロセス、および／または契約方法において標準化されていない。例えば、異なるコールセンターは、異なる通報処理プロセス、異なるイベントコーディングを利用することができ、かつ／または異なる方法でイベントデータを分類および構造化することができる。さらに、異なるコールセンターは、異なるＣＡＤシステムを使用し得、異なるコールセンターが外部で利用可能なＡＰＩは標準化されていない。

図１Ｂで提案されているアーキテクチャは、これらの障壁の多くを克服するのに特に適している。具体的には、現在、接続されたデバイス２９から救急サービスにデータを送信するためのリンクを提供するためのインタフェースを提供するラピッドＳＯＳなどの救急サービスインタフェースが設けられている。このようなインタフェースは、すでにかなりの割合の救急派遣センターと統合されている（または統合の過程にある）。図１Ｂの実施形態では、ＡＥＤネットワークサーバ２０は、コールセンター統合プロセスを大幅に簡素化する救急サービスインタフェース２８を介して救急コールセンター２５と通信する。

いくつかの実施形態では、ＣＡＤシステムのユーザインタフェースは、選択時にＡＥＤネットワーク起動メッセージを救急サービスインタフェース２８に送信する、ＡＥＤネットワーク起動ＧＵＩウィジェットを含むように変更される。次に、救急サービスインタフェース２８は、ＡＥＤネットワーク起動メッセージ（ＡＥＤ支援の要求として機能する）をＡＥＤレスポンダネットワークサーバ２０に転送する。いくつかの実施形態では、ＡＥＤネットワーク起動ウィジェットは、ＣＡＤシステムのインシデントレポート画面上に表示されるＧＵＩボタンの形をとる。しかしながら、ウィジェットは、プルダウンメニューなどを含む多種多様な異なるＧＵＩ機構を使用して実施することができ、任意の適切なＵＩ画面から表示またはアクセスすることができることを理解されたい。

ＡＥＤネットワーク起動メッセージは様々な形式をとることができるが、通常、少なくともインシデントの場所（例えば、ＧＰＳ座標、住所、その他の適切な位置情報）を含む。好ましくは、メッセージは、また、救急オペレータによって入力され得るメモを含み得る。メモには、インシデントに関連する詳細が示されている場合がある。例えば、メモは、追加の位置情報（例えば、傷病者が３階の３４０号室にいる）、インシデントに関する詳細（例えば、落下した電線に注意）、傷病者または傷病者の状態に関する情報、または適切と思われるその他の情報を含み得る。いくつかの実施形態では、ＡＥＤ起動メッセージは、関連があると思われる任意の数の他のフィールドを有し得る。

救急サービスインタフェース２８は、ＣＡＤシステムからＡＥＤネットワーク起動メッセージを受信すると、メッセージをＡＥＤネットワークサーバ２０に転送し、それによってＡＥＤレスポンスネットワークを起動する。これは、受信したメッセージを単に転送するか、関連情報を含む新たなメッセージを作成することによって実現することができる。

説明されているアーキテクチャにより、救急オペレータに、レスポンダネットワーク自体の詳細を気にすることなく、（例えば、ＣＡＤ表示画面上のボタンを選択することによって）ＡＥＤレスポンダネットワークを簡単に起動する機能が提供される。図示の実施形態では、全てのデバイス管理、追跡、検証、選択、および通知は、コールセンターとは独立して、ＡＥＤレスポンスサーバ（単数または複数）２０によって処理される。多くの状況においてインシデントの結果を改善する可能性がある従来の救急医療サービスよりも、ボランティアレスポンダが除細動器とともに心停止インシデントの現場に迅速に到着することができる多く状況があることは明らかである。

救急オペレータにＡＥＤレスポンダネットワークを簡単に起動する機能を提供することで、特定の状況においてさらに大きな影響を与えることができる。例えば、いくつかの救急コールセンターは、着信通報を受信して、通報が最適にルーティングされるより具体的なコールセンターを決定するという点で、ルーティングセンターまたはトリアージセンターのように機能する。図６に示すように、１つのそのような例は、９１１着信通報を受信し、緊急事態の処理に最適な救急サービスのタイプ（例えば、消防、医療、警察）を決定し、通報をそのサービスに固有のコールセンター（例えば、消防コール／派遣センター６１、医療コール／派遣センター６２、警察コール／派遣センター６３など）に転送するが、救急サービス自体の派遣を調整する９１１センター２５Ａである。このようなフレームワークはあまり一般的ではないが、実際に存在しており、地方で見られることが多い。

このような「通報転送」は、特に受信サービスの固有のコールセンター（例えば、医療コール／派遣センター）がビジー状態の場合に、応答時間にさらなる遅延をもたらす可能性があることは明らかである。このような遅延は、レスポンダが到着する前に１分が経過するごとに、生存の可能性に悪影響を与える可能性がある心停止の状況では特に問題になり得る。

このような状況では、インシデントが潜在的な心停止インシデントとして分類されると、受信側の９１１センター２５ＡがＡＥＤレスポンダネットワークを起動することができる。これは、医療コール／派遣センター６２による通報への応答／対応に対する待機に関連する遅延を減少させることに有用であり、その理由は、ＡＥＤレスポンダネットワーク内のボランティアに、通報転送とほぼ並行して通知されるため、従来からの救急サービスが到着する前に、ボランティアレスポンダがＡＥＤとともに現場に到着する可能性が高まるからである。さらに、特定の例では、代替の救急サービス（例えば、ＥＭＴサービスを備えた消防署など）がＡＥＤレスポンダネットワークへの参加を選択し得る。このような状況では、代替の救急サービスは、ＡＥＤレスポンダネットワークを介して、近隣の救急心停止インシデントの通知を通常の派遣プロトコルよりも早く実際に受信する。

救急サービスインタフェース２８はまた、ＩＰ通信プロトコルを使用して、ＡＥＤまたはユーザアプリ３５から救急サービスへの情報の転送を可能にするために使用することができる。例えば、除細動器アプリ／ユーザインタフェースまたはユーザアプリ３５のいずれかは、救急オペレータ／通信指令係に連絡するための機構を含むことができる。このような機構の例は、図３Ｅに示す救急サービスへの連絡ボタン３４５である。前に説明したように、ＡＥＤは、ＡＥＤレスポンスネットワークサーバ２０との安全かつ有効な接続を有し得る。ユーザが救急サービスへの連絡ボタンを選択すると、救急サービスへの連絡メッセージがＡＥＤレスポンスネットワークサーバ２０に送信される。メッセージは、デバイスの場所を含み得るか、またはサーバがＡＥＤの場所を追跡するため、サーバによって場所が追加され得る。次に、サーバは、救急サービスに連絡するための要求を救急サービスインタフェース２８に送信し、救急サービスインタフェース２８は、とりわけ、正しい救急コールセンターを特定し、その要求を適切なコールセンターに転送するように設計されている。

インシデントデータは、ほぼ同じ方法で救急医療従事者に転送するためにＡＥＤから救急コールセンターに転送することができる。当技術分野に精通している人々によって理解されるように、除細動器の救急使用中に、除細動器は、対応する救急医療要員に有用であり得る様々なインシデント関連情報を収集する。関連する除細動器の情報は、与えられたショックの数（ある場合）、そのようなショックの特性（例えば、印加電圧、印加波形など）、そのようなショックのタイミング、患者の測定ＥＣＧ（ショックの与える前後の両方）などの情報を含むことができる。そのような情報は医療従事者にとって有益であるかもしれないが、実際問題として、そのような情報を医療従事者に伝えることは非常に困難な場合がある。１つの障害は、ほとんどのＡＥＤには、インシデントの最中または後に、インシデント情報をリアルタイムで電子的に送信する機構がないことである。ＡＥＤがインシデントデータをＡＥＤネットワークサーバに送信する機能を備えている場合でも、サーバは、通常、どのＥＭＴチームがインシデントに対応しているか、および／または患者がどの医療施設（例えば、病院）に搬送され得るかについての可視性を有していない。

対照的に、多くの状況では、コールセンターには、対応する救急要員および／または患者が誘導され得る医療施設の両方にデータまたは電子情報を配信する機構がある。さらに、ラピッドＳＯＳなどの救急サービスインタフェースは、デバイスデータを適切なコールセンターに配信するように設計されている。従って、ＡＥＤレスポンスネットワークサーバ２０、救急サービスインタフェース２８、および適切なコールセンターは、除細動器のインシデントデータを適切な医療従事者に配信するための効果的な仲介手段を共に形成することができる。このような情報は、インシデント中および／またはＡＥＤの使用直後にリアルタイムで配信することができる。

図７は、ネットワークサーバ２０、救急サービスインタフェース２８、コールセンター２５を介した除細動器から医療従事者および／または医療施設への情報の流れを示すフローチャートである。図７に示されるように、除細動器は、関連するインシデントデータをネットワークサーバ２０に転送する（ブロック６５０）。次に、ネットワークサーバは、インシデントデータを救急サービスインタフェース２８に転送する（ブロック６５２）。次に、救急サービスインタフェースは、インシデントデータを適切なコールセンターに転送する（ブロック６５４）。最後に、コールセンターは、インシデントデータを適切な医療従事者および／または医療施設に転送する（ブロック６５６）。

ＡＥＤと救急サービスとの間の通信の仲介手段としてＡＥＤネットワークサーバおよび救急サービスインタフェースを使用することにより、実施の容易さと全体的なセキュリティの両方でいくつかの利点がある。ＡＥＤは、ＡＥＤレスポンスネットワークサーバ２０によって認証された既知のＡＥＤであるため、セキュリティが強化されている。ＡＥＤレスポンスネットワークサーバは、救急サービスインタフェース２８によって既知であり、かつ信頼されている。救急サービスインタフェースは、救急コールセンター２５によって既知であり、かつ信頼されている。コールセンターの観点から、ＡＥＤからＩＰ接続を介して受信した通信は、ホワイトリストに登録できる信頼できるソース（救急サービスインタフェース）から受信されたものである。同様に、救急サービスインタフェース２８の観点から、ＡＥＤからＩＰ接続を介して受信された全てのデータは、信頼できるソース（ＡＥＤレスポンスネットワークサーバ２０、これもホワイトリストに登録できる）から受信されたものである。対照的に、コールセンターがＡＥＤレスポンスネットワークサーバを経由せずにＡＥＤからの接続を受け入れることを許可すると、コールセンターに重大なセキュリティリスクをもたらすことになる。

救急サービスインタフェース２８は、既に多くのコールセンターにとって信頼できるデータプロバイダであるため、記載されたアプローチを実施することが特に容易であり、これにより、ＡＥＤレスポンスネットワーク／コールセンター統合プロセスが大幅に簡素化される。

記載された救急サービスインタフェースの使用法は、現在商業的に利用可能な救急サービスインタフェースとはかなり異なると考えられていることに留意されたい。当初、本発明者らは、本明細書で記載されているような、ＡＥＤレスポンスネットワークを様々な救急コールセンターＣＡＤシステムに接続する既存の救急サービスインタフェースを認識していない。

さらに、いくつかのコールセンターは、ＥＭＳプロバイダ２７にデータ（例えば、電子インシデント記録）を送信するように構成されている。しかしながら、本発明者らは、コールセンターからＥＭＳネットワークの一部ではないリモートデバイス（またはデバイスのリモートネットワーク）へのインシデント情報（例えば、インシデントの場所）の転送を可能にする既存の救急サービスインタフェースを認識していない。むしろ、従来のシステムでは、リモートデバイス２９からのインシデントデータは、ＥＭＳプロバイダ２７にのみ送信される。対照的に、上記のように、図１Ｂに示されたアーキテクチャでは、コールセンター２５は、救急サービスインタフェース２８を介してＡＥＤレスポンダネットワークにメッセージを送信することができる。

その他の機能
本発明のいくつかの実施形態のみが詳細に説明されてきたが、本発明は、本発明の主旨または範囲から逸脱することなく、他の多くの形態で実施され得ることを理解されたい。例えば、図面には、選択機能の実施に適したユーザインタフェースからの様々な特定のスクリーンショットが示されている。しかしながら、表示される特定のレイアウト、テキスト、およびグラフィックスは、特定の実施形態の設計ニーズおよび設定に基づいて幅広く変更され得ることを理解されたい。多くの状況では、ＧＵＩボタンまたはその他のＧＵＩ固有の構成は、情報を入力したり、特定の機能を選択したりするためのユーザインタフェース機構として表示される。記載された機能を実施するために使用される固有のＧＵＩ構成は幅広く変更され得、いくつかの実施形態では、移行および／または更新のいくつかは、レスポンダまたは対応ＡＥＤの位置、他のレスポンダの到着等の検出された情報または受信された情報に基づいて自動的に実施され得る。

上記の説明では、ボランティアレスポンダ、接続されたＡＥＤ、インシデントのバイスタンダーが利用しているＡＥＤアプリなどとの間で多数のアラートおよびメッセージが送受信される。このようなアラートおよび／またはメッセージは、ＳＭＳテキストメッセージ、他のテキストまたは音声メッセージングプロトコル、マルチメディアメッセージングプロトコル（例えば、ＭＭＳ）、インスタントメッセージングまたはアイメッセージ（ｉＭｅｓｓａｇｅ）テクノロジ、ＩＰプロトコル（例えば、ＴＣＰ／ＩＰ）およびそれらに組み込まれた電子メールなどの通信技術、および／または他の適切な通信プロトコルを使用して送信され得る。

ＡＥＤレスポンスネットワークサーバ（単数または複数）と救急サービスサーバまたは救急レスポンスネットワークとの間の通信も、任意の適切な通信プロトコルを使用して行うことができる。

上記の説明の多くは、ＡＥＤとＡＥＤネットワークサーバとの間の通信に関するものである。いくつかのＡＥＤは、ＡＥＤと直接通信できるようにする内蔵された通信ユニットを有する。しかしながら、他の多くの応用では、ＡＥＤ自体が、ＡＥＤネットワークサーバとの通信に適した通信ユニットを有していない場合がある。むしろ、そのような機能を有する別個のインタフェースユニットまたは通信ユニットが設けられてもよい。状況によっては、インタフェースユニットは、モジュラーシステムとして設計されているにもかかわらず、単一のユニットとしてＡＥＤと共に搬送されることができる（および、搬送されるように意図されている）ように、完全に機能するＡＥＤに物理的に取り付けられた全く別個のユニットであってもよい。このような状況では、ＡＥＤ（ベース除細動器ユニットと見なされる場合がある）は、インタフェースユニットの存在の有無にかかわらず、独立して動作することが可能である（および／または動作するように設計された）完全に機能する除細動器であり得る。そのような状況では、説明された通信は、ベース除細動器ユニット自体ではなく、独立したインタフェースユニットまたは通信ユニットとの間で行われ得る。そのようなモジュラーシステムの良好な例は、本明細書に組み込まれた米国特許出願第１６／１４５，６５７号に記載されている。しかしながら、本開示および特許請求の範囲の目的のために、そのようなシステムとの通信は、状況がそのような解釈を排除しない限り、ＡＥＤとの記載された通信の範囲内であると考えられる。

他の応用では、インタフェースまたは通信ユニットは、ドック、キャビネット、またはＡＥＤが格納されているその他の構造の一部であってもよいが、インシデントの現場にＡＥＤとともに持ち込まれることはない。記載されたレスポンダネットワークの通信および機能の多くは、これらのタイプのシステムでも実行することができるが、このようなシステムにおいて通信する機能は、ＡＥＤがその保管場所から取り外されると失われるであろう。しかしながら、そのようなシステムは、ＡＥＤが保管場所に存在するときに、依然としてＡＥＤの場所および状態を通信することが可能であり、記載されている近隣のインシデントアラートを生成することができる。従って、再び、本開示および特許請求の範囲の目的のために、そのようなシステムとの通信は、状況がそのような解釈を排除しない限り、ＡＥＤとの記載された通信の範囲内であると考えられる。

上記のワークフローのいくつかは、特定のステップの順序を示すフローチャートを使用して、少なくとも部分的に説明されている。状況によっては、状況に応じてイベントの順序が重要になることがある。しかしながら、他の場合、本発明の主旨および範囲から逸脱することなく、様々なステップを並べ替えたり、削除したり、他のステップを追加してもよい。

本発明は、主に、除細動器および心停止インシデントに対応する意思のあるボランティアの除細動器レスポンダネットワークの状況で記載されている。しかしながら、同様のアプローチおよびシステムが、他のタイプの医療インシデント、治療および／または装置を含むレスポンダネットワークと組み合わせて使用することができることを理解されたい。例えば、一般に入手可能な特定の薬剤を患者に迅速に届けることで、患者の転帰に有意なプラスの影響を与える可能性がある多くの状況がある。１つの具体的な例としては、重度のアレルギー反応（アナフィラキシー）に苦しむ患者にエピネフリン注射がしばしば推奨されることがある。同様に、いくつかの公衆衛生団体は、オピオイドの過剰摂取に苦しむ患者にナロキソン（または他の同様の薬剤）の公共投与を推奨している。これらの状況の両方において、患者または患者の周囲のバイスタンダーは、必要な薬剤をすぐに入手することができないかもしれないが、これらの薬は比較的広く流通しているため、近隣の他の人がそのような薬を手元に持っているかもしれない。記載されたレスポンダネットワークのアプローチは、除細動器レスポンダネットワークに関して上記したのと同様の方法で、近隣のボランティアレスポンダおよび／または接続されたデバイス（例えば、接続された応急処置キットまたは接続されたエピペンなど）に近隣のインシデントを通知することを可能にするために使用することができる。

別の例では、特定の地域では、有毒による咬傷（例えば、ヘビの咬傷、クモの咬傷など）が懸念されており、抗毒素を迅速に投与することで、生存の可能性が大幅に高まる可能性がある。そのような地域では、レスポンダネットワークを使用して、近隣のボランティアレスポンダおよび／または接続されたデバイスに抗毒素または解毒剤の必要性を通知することができる。当然ながら、少なくとも何人かのボランティアレスポンダがすぐにアクセルすることができ、適切なレスポンダネットワークが有利となるような、医療機器、応急処置キットのコンポーネント、または薬剤などが必要となり得る他の様々な状況がある。デバイスが関係する場合、デバイス自体（例えば、応急処置キット、エピペン、または他の医療機器）が接続され、そのようなデバイスは、記載された除細動器と同様の方法で統合され得る。あるいは、接続されるデバイスは、必要なアイテムを含むか、または潜在的に含む、応急処置キット、抗毒素キット、医薬用品キット、安全キットなどのような、より一般的なアイテムであり得る。記載されている技法は、このような状況でも使用できることは明らかである。従って、本実施形態は、例示的であり、限定的ではないと見なされるべきであり、本発明は、本明細書に与えられた詳細に限定されるべきではなく、添付の特許請求の範囲内および均等物で変更され得る。

ＡＥＤネットワークサーバは、好ましくは、インシデントの進行を監視し、支援または追加の支援が不要になった場合にＡＥＤアラートを終了することとなる。サーバがレスポンダ（または追加のレスポンダ）が不要になったと判定すると（ブロック２９３）、サーバは、個々のアラートをキャンセルするために応答していないＡＥＤにメッセージを送信する（ブロック２９５）。ＡＥＤがアラートキャンセルメッセージを受信すると（ブロック２９６）、ＡＥＤはアラートをキャンセルする（ブロック２９７）。

ネットワークサーバが近隣のインシデントアラートをキャンセルする原因となる様々なトリガが存在する。例えば、支援の要求を開始する責務がある救急コール２５は、救急医療従事者（例えば、ＥＭＴ、救急医療隊員、救急車）が現場に到着したこと、または、他の除細動器が現場に持ち込まれたこと、または、ＡＥＤが不要である（またはもはや不要である）と他の方法で判定されたことを知った場合に、要求を肯定的にキャンセルし得る。同様に、アプリを使用してＡＥＤ支援の要求を開始したインシデントにおけるバイスタンダーが、同様の状況で要求をキャンセルする場合がある。他のシナリオでは、ＡＥＤネットワークサーバ自体が、様々な理由のいずれかでアラートをキャンセルする場合がある。例えば、上記のように、指定された数のＡＥＤおよび／またはボランティアがインシデントに応答していることを示した後、対応しないデバイスによって生成されたアラートをキャンセルすることが望ましい。

Claims (67)

1. 方法であって、
   潜在的な突然の心停止インシデントの場所を特定する除細動器支援の要求を受信するステップと、
   クエリ対象の１つまたは複数の除細動器を特定するステップと、
   前記除細動器支援の要求を受信した後、クエリ対象の前記１つまたは複数の除細動器の各々に状態クエリを送信するステップと、
   少なくとも１つの状態クエリ応答を受信するステップであって、各状態クエリ応答は、クエリを受けた除細動器のうちの関連付けられた応答する１つの除細動器から受信され、かつ関連付けられた応答する除細動器の現在の状態および現在の位置を示す、前記受信するステップと、
   前記少なくとも１つの状態クエリ応答を受信した後、
   （ｉ）少なくとも１つの選択された応答する除細動器に近隣のインシデントメッセージを送信するステップであって、各近隣のインシデントメッセージは、関連付けられた１つの応答する除細動器に、前記近隣のインシデントメッセージの受信に応答して、関連付けられた応答する除細動器が有用であり得る、近隣で発生する潜在的な突然の心停止インシデントがあることを示すための近隣のインシデントアラートを生成させるために設定されたものである、前記近隣のインシデントメッセージを送信するステップと、
   （ｉｉ）少なくとも１人の登録済みのボランティアレスポンダにボランティアインシデントアラートを送信するステップであって、各ボランティアインシデントアラートは、潜在的な突然の心停止インシデントの現場における関連付けられた登録済みのボランティアレスポンダの支援を要求する、前記ボランティアインシデントアラートを送信するステップとのうちの少なくとも１つと、を含む方法。
2. 方法であって、
   潜在的な医療インシデントの場所を特定するボランティア支援の要求を受信するステップと、
   クエリ対象の１つまたは複数の医療デバイスを特定するステップと、
   前記ボランティア支援の要求を受信した後、クエリ対象の前記１つまたは複数のデバイスの各々に状態クエリを送信するステップと、
   少なくとも１つの状態クエリ応答を受信するステップであって、各状態クエリ応答は、クエリを受けたデバイスのうちの関連付けられた応答する１つのデバイスから受信され、かつ関連付けられた応答するデバイスの現在の状態および現在の位置を示す、前記受信するステップと、
   前記少なくとも１つの状態クエリ応答を受信した後、
   （ｉ）少なくとも１つの選択された応答するデバイスに近隣のインシデントメッセージを送信するステップであって、各近隣のインシデントメッセージは、関連付けられた１つの応答するデバイスに、前記近隣のインシデントメッセージの受信に応答して、関連付けられた応答するデバイスが有用であり得る、近隣で発生する潜在的な医療インシデントがあることを示すための近隣のインシデントアラートを生成させるために設定されたものである、前記近隣のインシデントメッセージを送信するステップと、
   （ｉｉ）少なくとも１人の登録済みのボランティアレスポンダにボランティアインシデントアラートを送信するステップであって、各ボランティアインシデントアラートは、潜在的な医療インシデントの現場における関連付けられた登録済みのボランティアレスポンダの支援を要求する、前記ボランティアインシデントアラートを送信するステップとのうちの少なくとも１つと、を含む方法。
3. 前記支援の要求が救急コールセンターから直接的または間接的に受信される、請求項１または２に記載の方法。
4. 前記支援の要求は、複数の異なる救急コールセンターと通信し、かつ他のデバイスからの救急インシデントデータを前記複数の異なる救急コールセンターに送信するように構成された救急サービスインタフェースを介して第１の救急コールセンターから間接的に受信される、請求項１または２に記載の方法。
5. 前記支援の要求が、モバイルコンピューティングデバイス上のアプリから直接的または間接的に受信される、請求項１または２に記載の方法。
6. 各状態クエリおよび近隣のインシデントメッセージは、特定されたデバイス／除細動器の関連付けられた１つに関連付けられた通信ユニットに送信され、
   前記通信ユニットは、特定されたデバイス／除細動器の関連付けられた１つの一部であるか、または特定されたデバイス／除細動器の関連付けられた１つに物理的に取り付けられた独立したインタフェースユニットの一部である、請求項１または２に記載の方法。
7. 前記状態クエリは、前記支援の要求を受信したことに応答して、第１の組のデバイス／除細動器を規定する複数のデバイス／除細動器に送信され、
   前記近隣のインシデントアラートメッセージは、前記第１の組のデバイス／除細動器における選択された一部のデバイス／除細動器に送信される、請求項１または２に記載の方法。
8. 前記選択された一部のデバイス／除細動器は、デバイス／除細動器から状態クエリ応答が受信されたデバイス／除細動器のみを含む、請求項７に記載の方法。
9. 前記第１の組のデバイス／除細動器に含まれるデバイス／除細動器は、デバイス／除細動器の以前の既知の位置に少なくとも部分的に基づく、請求項７に記載の方法。
10. 前記応答するデバイス／除細動器のうちの少なくとも１つが、デバイス／除細動器によって報告された現在の位置に少なくとも部分的に基づいて、選択された一部に含まれない、請求項９に記載の方法。
11. 前記応答するデバイス／除細動器のうちの少なくとも１つが、デバイス／除細動器によって報告された現在の状態に少なくとも部分的に基づいて、選択された一部に含まれない、請求項７に記載の方法。
12. 前記応答するデバイス／除細動器のうちの少なくとも１つが、デバイス／除細動器に関連付けられた以前のインシデント対応履歴に少なくとも部分的に基づいて、選択された一部に含まれるように選択される、請求項７に記載の方法。
13. 選択された一部に含まれる応答するデバイス／除細動器の選択が、潜在的な医療インシデント／突然の心停止インシデントの場所への予測された移動時間に少なくとも部分的に基づく、請求項７に記載の方法。
14. 前記ボランティアインシデントアラートを送信するための登録済みのボランティアレスポンダの選択が、個々のボランティアの以前のインシデント対応履歴に少なくとも部分的に基づく、請求項１または２に記載の方法。
15. 前記ボランティアインシデントアラートが送信される登録済みのボランティアレスポンダの少なくとも１人に対して、応答するデバイス／除細動器の少なくとも１つの位置を特定することをさらに含む、請求項１または２に記載の方法。
16. 前記ボランティアインシデントアラートを送信するための登録済みのボランティアレスポンダの選択が、個々のボランティアの現在の位置または潜在的な突然の心停止インシデントの場所への予測された移動時間のうちの少なくとも１つに少なくとも部分的に基づく、請求項１または２に記載の方法。
17. 請求項１乃至１６のいずれか１項に記載の方法を実行するように構成されたレスポンダネットワークサーバ。
18. 方法であって、
    除細動器に関連付けられた通信ユニットが、救急インシデントの場所を特定する除細動器支援の要求に応答して送信された電子の状態クエリを受信するステップと、
    前記電子の状態クエリの受信に応答して、除細動器の現在の状態および現在の位置を示す現在の状態メッセージを前記通信ユニットから送信するステップと、
    前記現在の状態メッセージを送信した後、前記通信ユニットが、近隣のインシデントメッセージを受信するステップと、
    前記近隣のインシデントメッセージの受信に応答して、除細動器が有用であり得る心臓緊急事態が近隣にあることを示す近隣のインシデントアラートを生成するステップと、を含む方法。
19. 方法であって、
    医療デバイスに関連付けられた通信ユニットが、救急インシデントの場所を特定する支援の要求に応答して送信された電子の状態クエリを受信するステップと、
    前記電子の状態クエリの受信に応答して、医療デバイスの現在の状態および現在の位置を示す現在の状態メッセージを前記通信ユニットから送信するステップと、
    前記現在の状態メッセージを送信した後、前記通信ユニットが、近隣のインシデントメッセージを受信するステップと、
    前記近隣のインシデントメッセージの受信に応答して、除細動器が有用であり得る心臓緊急事態が近隣にあることを示す近隣のインシデントアラートを生成するステップと、を含む方法。
20. 前記通信ユニットは、第１のチャネルを介して前記電子の状態クエリを受信し、前記第１のチャネルとは異なる第２のチャネルを介してサーバとの接続を開くことによって前記電子の状態クエリに応答し、
    前記現在の状態メッセージは、前記第２のチャネルを介して送信され、前記近隣のインシデントメッセージは前記第２のチャネルを介して受信される、請求項１８または１９に記載の方法。
21. 前記第１および第２のチャネルを介した通信のために異なる通信プロトコルが使用される、請求項２０に記載の方法。
22. 前記電子の状態クエリがＳＭＳメッセージである、請求項２１に記載の方法。
23. 前記現在の状態メッセージおよび前記近隣のインシデントメッセージは、ＩＰプロトコルを使用して送信される、請求項２１または２２に記載の方法。
24. 近隣のインシデントアラートが、音声コンポーネントおよび医療デバイス／除細動器または医療デバイス／除細動器に関連するインタフェースデバイス上の表示画面に表示される視覚メッセージのうちの少なくとも１つを含む、請求項１８または１９に記載の方法。
25. 前記視覚メッセージは、医療デバイス／除細動器を使用できる近隣の緊急事態が存在することの表示と、ユーザが救援する意思を示すためにユーザによって選択されるＧＵＩウィジェットとを含む、請求項２４に記載の方法。
26. ユーザが救援する意思を示すＧＵＩウィジェットのユーザの選択に応答して、インシデント受け入れメッセージをレスポンダネットワークサーバに送信するステップをさらに含む、請求項２５に記載の方法。
27. 救急インシデントの場所を前記表示画面に表示するステップをさらに含む、請求項２４に記載の方法。
28. 医療デバイスが、接続された注射デバイスおよび接続された応急処置キットからなる群から選択される、請求項２乃至１７または請求項１９乃至２７のいずれか１項に記載の方法。
29. 患者に除細動ショックを送達するように構成された携帯型除細動器システムであって、前記除細動器システムは、プロセッサ、メモリ、および通信ユニットを含み、前記通信ユニットは、１つまたは複数の外部デバイスからメッセージを受信し、前記メッセージを前記１つまたは複数の外部デバイス、システム、またはサーバに送信するように構成され、前記プロセッサは、前記メモリに格納されたプログラムされた命令を実行して、
    第１の状態レポートをリモートサーバに定期的に送信し、前記第１の状態レポートは、少なくとも前記除細動器システムの機能状態および前記除細動器システムの現在の位置の表示を含み、
    前記リモートサーバから受信した状態クエリに応答して第２の状態レポートを前記リモートサーバに送信し、前記第２の状態レポートは、少なくとも前記除細動器システムの機能状態および前記除細動器システムの現在の位置の表示を含み、
    除細動器が有用であり得る近隣で発生する救急インシデントを示すメッセージの受信に応答して近隣のインシデントアラートを生成させるように構成され、前記近隣のインシデントアラートは、音声アラートおよび表示画面上に表示される視覚メッセージを含む、除細動器システム。
30. 前記視覚メッセージは、ＡＥＤを使用できる近隣の緊急事態が存在することの表示と、ユーザが救援する意思を示すためにユーザによって選択されるＧＵＩウィジェットとを含む、請求項２９に記載の除細動器システム。
31. 前記プログラムされた命令は、ユーザの救援する意思を示すＧＵＩウィジェットの選択後に、救急インシデントの場所を特定するマップを前記表示画面上に表示させるようにさらに構成される、請求項３０に記載の除細動器システム。
32. 前記プログラムされた命令は、除細動器が救急インシデントの場所に持ち込まれたときに、患者に使用するために除細動器を作動させる方法をオペレータに促すようにさらに構成される、請求項３１に記載の除細動器システム。
33. 前記除細動器システムは、ベース除細動器ユニットと、携帯型モジュラー除細動器システムを提供するために前記ベース除細動器ユニット上に搭載され、かつ前記ベース除細動器ユニットに取り外し可能に取り付けられた取り外し可能なインタフェースユニットとを含む携帯型モジュラー除細動器システムであり、前記通信ユニットおよび前記表示画面は、前記インタフェースユニットの一部である、請求項２９に記載の除細動器システム。
34. 複数の異なる救急コールセンターと通信するように構成された救急サービスインタフェースを使用して除細動器支援の要求を処理する方法であって、前記救急サービスインタフェースは、接続されたデバイスからリアルタイムのインシデントデータを受信し、前記救急コールセンターのうちの適切な救急コールセンターに前記リアルタイムのインシデントデータを直接伝達するようにさらに構成され、
    前記救急サービスインタフェースにおいて、最初に選択された１つの救急コールセンターから前記除細動器支援の要求を受信するステップと、前記除細動器支援の要求は、支援が望まれる潜在的な心停止インシデントの場所を含み、
    救急サービス管理インタフェースからインシデントネットワーク通知メッセージをレスポンダネットワークサーバに送信するステップと、を含み、前記インシデントネットワーク通知メッセージは、潜在的な心停止インシデントの場所を含み、前記レスポンダネットワークサーバは、（ａ）１組の除細動器、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定して、潜在的な心停止インシデントを通知するように構成されている、方法。
35. 複数の異なる救急コールセンターと通信するように構成された救急サービスインタフェースを使用してボランティア支援の要求を処理する方法であって、前記救急サービスインタフェースは、接続されたデバイスからリアルタイムのインシデントデータを受信し、前記救急コールセンターのうちの適切な救急コールセンターにリアルタイムのインシデントデータを直接伝達するようにさらに構成され、
    前記救急サービスインタフェースにおいて、最初に選択された１つの救急コールセンターから前記ボランティア支援の要求を受信するステップと、前記ボランティア支援の要求は、支援が望まれるインシデントの場所を含み、
    救急サービス管理インタフェースからインシデントネットワーク通知メッセージをレスポンダネットワークサーバに送信するステップと、を含み、前記インシデントネットワーク通知メッセージは、インシデントの場所を含み、前記レスポンダネットワークサーバは、（ａ）１組の医療デバイス、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定して、インシデントを通知するように構成されている、方法。
36. 前記レスポンダネットワークサーバが、インシデントの通知を受ける１組のデバイス／除細動器を特定するステップと、
    特定された１組の医療デバイス／除細動器内の各デバイス／除細動器に近隣のインシデントメッセージを送信するステップと、をさらに含む、請求項３４または３５に記載の方法。
37. 前記近隣のインシデントメッセージを受信する各デバイス／除細動器において、デバイス／除細動器が有用であり得る心臓緊急事態が近隣に存在することを示す近隣のインシデントアラートを生成するステップをさらに含み、前記近隣のインシデントアラートは、音声アラートおよび視覚アラートのうちの少なくとも１つを含み、前記視覚アラートは、デバイス／除細動器に関連付けられた表示画面上に表示される、請求項３６に記載の方法。
38. 前記特定された１組のデバイス／除細動器におけるデバイス／除細動器の各々は、直近に、その位置および動作状態を前記レスポンダネットワークサーバに提供している、請求項３６に記載の方法。
39. 前記レスポンダネットワークサーバは、前記インシデントネットワーク通知メッセージの受信に応答して、複数のデバイス／除細動器に状態クエリを送信するように構成されており、
    通知される１組のデバイス／除細動器は、前記状態クエリが送信され応答した複数のデバイス／除細動器の一部である、請求項３６に記載の方法。
40. 前記支援の要求を送信した救急コールセンターのうちの最初に選択された１つの救急コールセンターが、それ自体、着信救急通報に応答して救急医療レスポンダ派遣を開始しないが、着信救急通報を救急派遣コールセンターに転送する、請求項３４または３５に記載の方法。
41. 接続されたデバイスからリアルタイムのインシデントデータを受信し、前記リアルタイムのインシデントデータを選択された適切な救急コールセンターに直接伝達するように構成された救急サービスインタフェースであって、前記救急サービスインタフェースは、
    救急コールセンターのうちの最初に選択された１つの救急コールセンターからボランティア支援の要求を受信し、前記ボランティア支援の要求は、支援が望まれるインシデントの場所の特定を含み、
    前記ボランティア支援の要求の受信に応答して、インシデントネットワーク通知メッセージをレスポンダネットワークサーバに送信するように構成されており、前記インシデントネットワーク通知メッセージは、インシデントの場所の特定を含み、前記レスポンダネットワークサーバは、（ａ）１組の医療デバイス、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定して、インシデントを通知するように構成されている、救急サービスインタフェース。
42. 前記救急サービスインタフェースは、選択されたインシデントデータを前記レスポンダネットワークサーバから電子的に受信し、
    前記選択されたインシデントデータを選択された医療従事者または医療施設に電子的に転送することが可能な選択された救急コールセンターに前記選択されたインシデントデータを電子的に送信するようにさらに構成される、請求項４１に記載の救急サービスインタフェース。
43. 前記インシデントが潜在的な心停止インシデントであり、前記１組の医療デバイスが１組の除細動器である、請求項４１または４２に記載の救急サービスインタフェース。
44. 選択されたインシデントデータを医療デバイスから選択された医療従事者または医療施設に送信する方法であって、
    医療デバイスネットワークサーバにおいて、選択されたインシデントデータを前記医療デバイスから電子的に受信するステップと、
    前記選択されたインシデントデータを前記医療デバイスネットワークサーバから、複数の異なる救急コールセンターと通信するように構成された救急サービスインタフェースに電子的に送信するステップと、を含み、前記救急サービスインタフェースは、接続されたデバイスからリアルタイムのインシデントデータを受信し、前記救急コールセンターのうちの適切な救急コールセンターに前記リアルタイムのインシデントデータを直接伝達するようにさらに構成され、前記救急サービスインタフェースは、前記選択されたインシデントデータを前記選択された医療従事者または医療施設に電子的に転送することが可能な選択された救急コールセンターに前記選択されたインシデントデータを電子的に送信するように構成されている、方法。
45. 前記医療デバイスが除細動器であり、前記選択されたインシデントデータが選択された除細動器のインシデントデータであり、前記医療デバイスネットワークサーバが除細動器のネットワークサーバである、請求項４４に記載の方法。
46. 前記選択されたインシデントデータを救急サービスインタフェース医療デバイスネットワークサーバから前記選択された救急コールセンターに電子的に送信するステップと、
    前記選択されたインシデントデータを、前記選択された救急コールセンターから前記選択された医療従事者または施設に電子的に転送するステップと、を含む、請求項４４または４５に記載の方法。
47. 前記選択された除細動器のインシデントデータが少なくとも１つのＥＣＧセグメントを含む、請求項４５に記載の方法。
48. 前記選択された除細動器のインシデントデータが、患者に送達されたショックの数の表示、および各ショックの特性またはタイミングに関する情報を含む、請求項４５に記載の方法。
49. 複数の異なる救急コールセンターと通信するように構成された救急サービスインタフェースを使用してボランティア支援の要求を処理する方法であって、前記救急サービスインタフェースは、接続されたデバイスからリアルタイムのインシデントデータを受信し、前記救急コールセンターのうちの適切な救急コールセンターにリアルタイムのインシデントデータを直接伝達するようにさらに構成され、
    前記救急サービスインタフェースにおいて、最初に選択された１つの救急コールセンターから前記ボランティア支援の要求を受信するステップと、前記ボランティア支援の要求は、支援が望まれるインシデントの場所を含み、
    救急サービス管理インタフェースからインシデントネットワーク通知メッセージをレスポンダネットワークサーバに送信するステップと、を含み、前記インシデントネットワーク通知メッセージは、インシデントの場所を含み、前記レスポンダネットワークサーバは、（ａ）１組の医療デバイス、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定して、インシデントを通知するように構成されている、方法。
50. 前記レスポンダネットワークサーバが、インシデントの通知を受ける１組の医療デバイスを特定し、特定された１組の医療デバイスにおける各医療デバイスに近隣のインシデントメッセージを送信するステップをさらに含む、請求項４９に記載の方法。
51. 前記近隣のインシデントメッセージを受信する各医療デバイスにおいて、前記医療デバイスが有用であり得るインシデントが近隣に存在することを示す近隣のインシデントアラートを生成するステップをさらに含み、前記近隣のインシデントアラートは、音声アラートおよび視覚アラートのうちの少なくとも１つを含み、前記視覚アラートは、前記医療デバイスに関連付けられた表示画面上に表示される、請求項５０に記載の方法。
52. 前記特定された１組の医療デバイスにおける医療デバイスの各々が、直近に、その位置および動作状態をレスポンダネットワークサーバに提供している、請求項５０に記載の方法。
53. 前記レスポンダネットワークサーバは、前記インシデントネットワーク通知メッセージの受信に応答して、複数の医療デバイスに状態クエリを送信するように構成されており、
    通知される１組の医療デバイスは、前記状態クエリが送信され応答した複数の医療デバイスの一部である、請求項５０に記載の方法。
54. 前記ボランティア支援の要求を送信した救急コールセンターのうちの最初に選択された１つの救急コールセンターが、それ自体、着信救急通報に応答して救急医療レスポンダ派遣を開始しないが、着信救急通報を救急派遣コールセンターに転送する、請求項４９に記載の方法。
55. 方法であって、
    救急コールセンターからインシデント記録を受信するステップと、
    前記インシデント記録を自動的に分析して、除細動器が前記インシデント記録によって参照されるインシデントに有用であり得るかどうかを判定するステップと、
    前記除細動器がインシデントに有用であり得ると判定された場合、インシデントアラートが（ｉ）１人以上の登録済みのボランティアレスポンダ、および（ｉｉ）１つまたは複数の自動体外式除細動器のうちの少なくとも一方に電子的に送信されて、少なくとも最初のレスポンダが最初の自動体外式除細動器をインシデントの現場に持ち込むのを促すようにするステップ、とを含む方法。
56. 方法であって、
    救急コールセンターにおいて、通報が、医療支援を必要とし、かつ除細動器の支援の効果を得る可能性のある潜在的な心停止インシデントに対応していると判定するステップと、
    インシデントネットワーク通知メッセージをレスポンダネットワークサーバに送信するステップと、前記インシデントネットワーク通知メッセージは、潜在的な心停止インシデントの場所を含み、前記レスポンダネットワークサーバは、（ａ）１組の除細動器、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定して、潜在的な心停止インシデントを通知するように構成され、
    前記通報を処理して、潜在的な心停止インシデントへの救急医療レスポンダの派遣を手配する医療救急派遣センターに前記通報を転送するステップと、を含み、前記救急コールセンターは、着信救急通報に応答して救急医療レスポンダの派遣を開始しない、方法。
57. コールセンターオペレータによる選択に適したグラフィカルユーザインタフェースウィジェットを有するコンピュータ支援の派遣ユニットであって、前記グラフィカルユーザインタフェースウィジェットの選択により、前記コンピュータ支援の派遣ユニットは、自動体外式除細動器支援の要求を送信し、前記自動体外式除細動器支援の要求は、支援が望まれる潜在的な心停止インシデントの場所の表示を含み、前記自動体外式除細動器支援の要求は、潜在的な心停止インシデントを通知する特定のレスポンダまたは除細動器を特定しない一般的な要求であり、前記自動体外式除細動器支援の要求は、潜在的な心停止インシデントを通知するために、（ａ）１組の除細動器、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定するレスポンダネットワークに送信される、コンピュータ支援の派遣ユニット。
58. 方法であって、
    潜在的な突然の心停止インシデントの場所を特定する除細動器支援の要求を受信するステップと、
    前記潜在的な突然の心停止インシデントを通知する１組の１つまたは複数の除細動器を選択するステップと、
    選択された１組の除細動器における各除細動器に近隣のインシデントメッセージを送信するステップと、を含み、各近隣のインシデントメッセージは、近隣のインシデントメッセージの受信に応答して近隣のインシデントアラートを生成して、関連付けられた応答する除細動器が有用であり得る、近隣で発生する潜在的な突然の心停止インシデントがあることを示すようにさせるために設定されたものであり、
    選択された１組の除細動器に含ませるための除細動器の選択は、（ｉ）除細動器支援の要求の受信後に送信された状態クエリに対する応答、および（ｉｉ）前記除細動器に関連付けられた以前のインシデント対応履歴のうちの少なくとも１つに少なくとも部分的に基づく、方法。
59. 方法であって、
    潜在的な突然の心停止インシデントの場所を特定する除細動器支援の要求を受信するステップと、
    前記潜在的な突然の心停止インシデントを通知する１組の１人以上の登録済みのボランティアレスポンダを選択するステップと、
    選択された１組の登録済みのボランティアレスポンダにおける各ボランティアレスポンダにボランティアのインシデントアラートを送信するステップと、を含み、各ボランティアのインシデントアラートは、潜在的な突然の心停止インシデントの現場における関連付けられた登録済みのボランティアレスポンダの支援を要求し、
    選択された１組のボランティアレスポンダに含ませるためのボランティアレスポンダの選択は、ボランティアレスポンダに関連付けられた以前のインシデント対応履歴に少なくとも部分的に基づく、方法。
60. 複数の除細動器を含む除細動器ネットワークを管理するように構成された除細動器のネットワークサーバであって、前記除細動器のネットワークサーバは、
    除細動器のネットワーク内の複数の異なる除細動器から電子状態レポートを定期的に受信し、各電子状態レポートは、前記複数の除細動器のうちの関連付けられた１つの除細動器の現在の機能状態および関連付けられた除細動器の現在の位置の表示を少なくとも含み、
    前記複数の異なる除細動器から受信した前記電子状態レポートに少なくとも部分的に基づいて、前記複数の異なる除細動器の各々の現在の位置および現在の機能状態を含むデータベースを維持し、
    潜在的な突然の心停止インシデントの場所を特定する除細動器支援の要求を受信し、
    前記除細動器支援の要求の受信に応答して、前記除細動器のネットワークにおける少なくとも１つの除細動器に状態クエリを選択的に送信し、
    前記除細動器ネットワークにおける少なくとも１つの除細動器に送信された前記状態クエリに対する応答を受信した後、（ａ）前記除細動器のネットワークにおける少なくとも１つの選択された除細動器に除細動器のインシデントアラートを送信して、前記少なくとも１つの選択された除細動器に近隣のインシデントアラートを発行するように要求し、指示し、または発行させるようにすること、および（ｂ）潜在的なレスポンダに対する前記除細動器のネットワークにおける少なくとも１つの選択された除細動器の現在の位置を特定することのうちの少なくとも１つを行うように構成されている、除細動器のネットワークサーバ。
61. 前記除細動器のネットワークにおける第１の組の除細動器がモバイル除細動器として指定され、サーバは、前記状態クエリに対する応答を受信した後、近隣のインシデントアラートを１つのモバイルのみに送信する、請求項６０に記載の除細動器のネットワークサーバ。
62. 前記除細動器支援の要求の受信に応答して、第１の組の除細動器を規定する複数の除細動器に状態クエリが送信され、前記複数の除細動器から状態クエリ応答が受信され、
    前記近隣のインシデントアラートメッセージは、第１の組の除細動器の第１の一部に送信され、応答する除細動器のうちの少なくとも１つは、除細動器によって報告された現在の位置に少なくとも部分的に基づいて前記一部に含まれない、請求項６０に記載の除細動器のネットワークサーバ。
63. 応答する除細動器のうちの少なくとも第２の１つは、前記除細動器によって報告された現在の状態に少なくとも部分的に基づいて前記一部に含まれない、請求項６０に記載の除細動器のネットワークサーバ。
64. 方法であって、
    除細動器支援の要求を受信するステップと、支援は、潜在的な突然の心停止インシデントの現場において必要であり、
    インシデントの近隣にあると予想される１つまたは複数の除細動器を特定するステップと、
    特定された１つまたは複数の除細動器のうちの最初に選択された１つの除細動器に状態要求を送信して、前記最初に選択された除細動器に、前記最初に選択された除細動器の動作状態および場所を確認させるステップと、前記状態要求は、自動体外式除細動器支援の要求を受信した後に送信され、
    選択された除細動器の動作状態を確認し、前記選択された除細動器の現在の位置を提供する、前記状態要求に対する応答を受信するステップと、
    前記状態要求に対する応答を受信した後、（ｉ）少なくとも１人の登録済みのボランティアレスポンダにボランティアインシデントアラートを送信して、潜在的な突然の心停止の現場における登録済みのボランティアレスポンダの支援を要求し、前記選択された除細動器の現在の位置を示す登録済みのボランティアレスポンダ情報を送信するステップと、（ｉｉ）近隣のインシデントメッセージを前記選択された除細動器に送信して、前記選択された除細動器に、前記近隣のインシデントメッセージの受信に応答して近隣のインシデントアラートを生成させて、除細動器が有用であり得る近隣で発生する救急インシデントがあることを示すようにするステップとのうちの少なくとも１つを行うことと、を含む方法。
65. 接続されたデバイスからリアルタイムのインシデントデータを受信し、前記リアルタイムのインシデントデータを選択された適切な救急コールセンターに直接伝達するように構成された救急サービスインタフェースであって、前記救急サービスインタフェースは、
    救急コールセンターのうちの最初に選択された１つの救急コールセンターから除細動器支援の要求を受信し、前記除細動器支援の要求は、支援が望まれる潜在的な心停止インシデントの場所の特定を含み、
    前記除細動器支援の要求の受信に応答して、インシデントネットワーク通知メッセージをレスポンダネットワークサーバに送信し、前記インシデントネットワーク通知メッセージは、潜在的な心停止インシデントの場所の特定を含み、前記レスポンダネットワークサーバは、（ａ）１組の除細動器、および（ｂ）１組のボランティアレスポンダのうちの少なくとも一方を特定して、潜在的な心停止インシデントを通知するように構成される、救急サービスインタフェース。
66. 前記救急サービスインタフェースは、選択された除細動器のインシデントデータをレスポンダネットワークサーバから電子的に受信し、前記選択された除細動器のインシデントデータを選択された医療従事者または医療施設に電子的に転送することが可能な選択された救急コールセンターに前記選択された除細動器のインシデントデータを電子的に送信するようにさらに構成される、請求項６５に記載の救急サービスインタフェース。
67. 選択された除細動器のインシデントデータを除細動器から選択された医療従事者または医療施設に送信する方法であって、
    除細動器ネットワークサーバにおいて、前記選択された除細動器のインシデントデータ前記を除細動器から電子的に受信するステップと、
    前記選択された除細動器のインシデントデータを除細動器のネットワークサーバから、複数の異なる救急コールセンターと通信するように構成された救急サービスインタフェースに電子的に送信するステップと、を含み、前記救急サービスインタフェースは、接続されたデバイスからリアルタイムのインシデントデータを受信し、前記救急コールセンターのうちの適切な救急コールセンターに前記リアルタイムのインシデントデータを直接伝達するようにさらに構成され、前記救急サービスインタフェースは、前記選択された除細動器のインシデントデータを前記選択された医療従事者または医療施設に電子的に転送することが可能な選択された救急コールセンターに前記選択された除細動器のインシデントデータを電子的に送信するように構成されている、方法。
    

Images