特表 2023-519672 患者エンカウンタ記録を生成するシステム及び方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-05-12

(54)【発明の名称】患者エンカウンタ記録を生成するシステム及び方法

(51)【国際特許分類】

   G16H 10/60 20180101AFI20230502BHJP

   G16H 50/20 20180101ALI20230502BHJP

【ＦＩ】

G16H10/60

G16H50/20

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022558108

(86)(22)【出願日】2021-03-30

(85)【翻訳文提出日】2022-11-15

(86)【国際出願番号】 US2021024833

(87)【国際公開番号】W WO2021202490

(87)【国際公開日】2021-10-07

(31)【優先権主張番号】63/002,678

(32)【優先日】2020-03-31

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

(31)【優先権主張番号】63/111,234

(32)【優先日】2020-11-09

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】504242032

【氏名又は名称】ゾール メディカル コーポレイション

【氏名又は名称原語表記】ＺＯＬＬ Ｍｅｄｉｃａｌ Ｃｏｒｐｏｒａｔｉｏｎ

(74)【代理人】

【識別番号】110000877

【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所

(72)【発明者】

【氏名】ホワイト、エリジャー エー．

(72)【発明者】

【氏名】ドーソン、アダム ティー．

(72)【発明者】

【氏名】ジャロス、デイヴィッド エー．

(72)【発明者】

【氏名】フリーマン、ゲリー エー．

(72)【発明者】

【氏名】オー、メイ チ マリア

(72)【発明者】

【氏名】バーナバス、クリストファー

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA22

(57)【要約】

患者エンカウンタに関与した複数のデバイスからの医療データを集約するためのシステムが提供される。システムは、医療デバイスインタフェースを介して、各医療デバイスの識別子を取得し、１又は複数の識別子を含む関連付け情報を生成し、関連付け情報をサーバに送信するモバイルコンピューティングデバイスを備える。サーバは、医療デバイスから１又は複数の医療デバイスケースファイルを受信して格納し、モバイルコンピューティングデバイスから関連付け情報を受信し、１又は複数の医療デバイスケースファイルを互いに関連付け、後続の処理のために１又は複数の医療デバイスケースファイルからのケースデータを含む統合データソースエンカウンタ構造体を生成する。

【特許請求の範囲】

【請求項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】

前記医療デバイスインタフェースは、カメラを含み、前記複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの１又は複数を含む、請求項５１に記載のモバイルコンピューティングデバイス。

【請求項68】

前記複数の医療デバイスの前記複数の識別子は、１又は複数の一意デバイス識別子に対応する、請求項５１に記載のモバイルコンピューティングデバイス。

【請求項69】

前記少なくとも１つのプロセッサは、前記エンカウンタの１又は複数のログエントリを生成するようにさらに構成されている、請求項５１に記載のモバイルコンピューティングデバイス。

【請求項70】

前記少なくとも１つのプロセッサは、前記少なくとも１つの医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体に含めるために、前記１又は複数のログエントリを前記サーバに送信するように構成されている、請求項６９に記載のモバイルコンピューティングデバイス。

【請求項71】

前記モバイルコンピューティングデバイスは、前記サーバから遠隔にある、請求項５１に記載のモバイルコンピューティングデバイス。

【請求項72】

患者と緊急ヘルスケア提供者との間のエンカウンタからのケースデータを集約するためのコンピュータ実装プロセスであって、前記コンピュータ実装プロセスは、
ユーザインタフェースを介して、前記エンカウンタに関与した複数の医療デバイスの複数の識別子の複数の表現を取得するように入力を受信する段階と、
前記複数の識別子の前記取得された複数の表現をコンピュータのメモリに格納する段階と、
前記複数の識別子を含む関連付け情報を生成する段階と、
前記エンカウンタ中に前記複数の医療デバイスによって生成された少なくとも１つの医療デバイスケースファイルからの前記ケースデータを関連付けて集約するために、前記コンピュータのネットワークインタフェースを介して、前記関連付け情報をサーバに送信する段階と
を備えるコンピュータ実装プロセス。

【請求項73】

前記ネットワークインタフェースを介して、前記少なくとも１つの医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信する段階と、
前記ユーザインタフェースを介して、前記統合データソースエンカウンタ構造体の少なくとも一部をレンダリングする段階と
をさらに備える、請求項７２に記載のコンピュータ実装プロセス。

【請求項74】

前記統合データソースエンカウンタ構造体を受信する段階は、患者情報以外の情報を受信する段階を含む、請求項７３に記載のコンピュータ実装プロセス。

【請求項75】

前記ケースデータの前記少なくとも一部をレンダリングする段階は、ＥＣＧデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの１又は複数を含む生理学データをレンダリングする段階を含む、請求項７３に記載のコンピュータ実装プロセス。

【請求項76】

前記ケースデータの前記少なくとも一部をレンダリングする段階は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの１又は複数を含む処置データをレンダリングする段階を含む、請求項７３に記載のコンピュータ実装プロセス。

【請求項77】

前記ケースデータの前記少なくとも一部をレンダリングする段階は、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの１又は複数を含むパフォーマンスデータをレンダリングする段階を含む、請求項７３に記載のコンピュータ実装プロセス。

【請求項78】

前記ケースデータの前記少なくとも一部をレンダリングする段階は、保護された健康情報をレンダリングする段階を含む、請求項７３に記載のコンピュータ実装プロセス。

【請求項79】

前記関連付け情報を送信する段階は、患者情報を送信する段階を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項80】

前記患者情報を送信する段階は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの１又は複数を送信する段階を含む、請求項７９に記載のコンピュータ実装プロセス。

【請求項81】

前記関連付け情報を送信する段階は、前記少なくとも１つの医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を送信する段階を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項82】

前記関連付け情報を送信する段階は、前記複数の医療デバイスの前記複数の識別子の前記複数の表現が取得されたときを示すタイムスタンプ情報を送信する段階を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項83】

前記関連付け情報を送信する段階は、前記複数の医療デバイスの前記複数の識別子の前記複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含む、請求項８２に記載のコンピュータ実装プロセス。

【請求項84】

前記関連付け情報を送信する段階は、前記複数の医療デバイスの前記複数の識別子の前記複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項85】

前記関連付け情報を送信する段階は、前記エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項86】

前記関連付け情報を送信する段階は、前記少なくとも１つの医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体にアクセスするためのトークンを送信する段階を含み、前記コンピュータ実装プロセスは、前記ネットワークインタフェースを介して、前記トークンを緊急対応センタ内のコンピューティングデバイスに送信する段階をさらに備える、請求項７２に記載のコンピュータ実装プロセス。

【請求項87】

前記複数の表現を取得するように入力を受信する段階は、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも１つを介して入力を受信する段階を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項88】

前記複数の表現を取得するように入力を受信する段階は、カメラを介して入力を受信する段階を含み、前記複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの１又は複数を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項89】

前記複数の識別子の前記複数の表現を取得するように入力を受信する段階は、複数の一意医療デバイス識別子の複数の表現を取得するように入力を受信する段階を含む、請求項７２に記載のコンピュータ実装プロセス。

【請求項90】

前記エンカウンタの１又は複数のログエントリを生成する段階をさらに備える、請求項７２に記載のコンピュータ実装プロセス。

【請求項91】

前記少なくとも１つの医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体に含めるために、前記１又は複数のログエントリを前記サーバに送信する段階をさらに備える、請求項９０に記載のコンピュータ実装プロセス。

【請求項92】

プロセッサに、請求項７２～９１のいずれか一項に記載のコンピュータ実装プロセスを実行させるためのコンピュータプログラム。

【請求項93】

請求項９２に記載のコンピュータプログラムを格納する非一時的コンピュータ可読記憶媒体を備えるモバイルコンピューティングデバイスであって、前記サーバから遠隔にある、モバイルコンピューティングデバイス。

【請求項94】

前記ＥＣＧデータは、１２リードＥＣＧデータレポートを含む、請求項２６に記載のシステム。

【請求項95】

前記１２リードＥＣＧデータレポートは、電気波形と、前記電気波形のうちの１又は複数の解釈とを含む、請求項９４に記載のシステム。

【請求項96】

前記複数の医療デバイスは、前記サーバから前記ケースデータの要求を受信することなく、前記取得されたケースデータを１又は複数の医療デバイスケースファイルとして前記サーバに自動的に送信するように構成されている、請求項１に記載のシステム。

【請求項97】

前記ＥＣＧデータは、１２リードＥＣＧデータレポートを含む、請求項４７に記載の関連付けサーバ。

【請求項98】

前記１２リードＥＣＧデータレポートは、電気波形と、前記電気波形のうちの１又は複数の解釈とを含む、請求項９７に記載の関連付けサーバ。

【請求項99】

前記少なくとも１つのプロセッサは、前記複数の医療デバイスケースファイルの要求を送信することなく、前記複数の医療デバイスケースファイルを前記複数の医療デバイスから自動的に受信するように構成されている、請求項３０に記載の関連付けサーバ。

【請求項100】

医療データレポートを送信するためのシステムであって、前記システムは、
医療デバイスであって、
患者から医療データを取得し、
前記取得された医療データの一部に少なくとも基づいて医療レポートを生成し、
前記医療レポートの要求を前記医療デバイスに送信することなく、前記医療レポートを自動的に受信するように構成されているローカルコンピューティングデバイスに、前記医療レポートを送信する
ように構成されている、医療デバイス
を備え、
前記医療デバイス又は前記ローカルコンピューティングデバイスのうちの一方又は両方が、通信ネットワークを介して前記医療レポートを１又は複数のリモートコンピューティングデバイスに送信するようにさらに構成されており、前記１又は複数のリモートコンピューティングデバイスは、前記医療レポートに関連付けられている医療データにアクセスして表示するように構成されている、システム。

【請求項101】

前記医療レポートは、１２リードＥＣＧレポートを含む、請求項１００に記載のシステム。

【請求項102】

前記１２リードＥＣＧレポートは、統合データソースエンカウンタ構造体の１つのレポートである、請求項１０１に記載のシステム。

【請求項103】

前記１２リードＥＣＧレポートは、電気波形と、前記電気波形のうちの１又は複数の解釈とを含む、請求項１０１に記載のシステム。

【請求項104】

前記医療デバイスは、無線ローカルエリアネットワークを使用して、前記医療レポートを前記ローカルコンピューティングデバイスに送信するように構成されている、請求項１００に記載のシステム。

【請求項105】

前記医療デバイスは、パーソナルエリアネットワークを使用して、前記医療レポートを前記ローカルコンピューティングデバイスに送信するように構成されている、請求項１００に記載のシステム。

【請求項106】

前記医療デバイス又は前記ローカルコンピューティングデバイスは、セルラネットワークを使用して、前記医療レポートを前記１又は複数のリモートコンピューティングデバイスに送信するように構成されている、請求項１００に記載のシステム。

【請求項107】

前記医療レポートは、前記医療デバイスによって前記ローカルコンピューティングデバイスに送信される前に暗号化される、請求項１００に記載のシステム。

【請求項108】

前記ローカルコンピューティングデバイスは、前記医療デバイスから通信を受けることをオプトアウトするように構成されている、請求項１００に記載のシステム。

【請求項109】

前記医療デバイスは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、又はウェアラブル除細動器を含む、請求項１００に記載のシステム。

【請求項110】

前記１又は複数のリモートコンピューティングデバイスは、受信された医療レポートのリストを表示するように構成されている、請求項１００に記載のシステム。

【請求項111】

前記１又は複数のリモートコンピューティングデバイスは、前記医療レポートに関連付けられているタイムスタンプに基づいて、前記受信された医療レポートのリストをフィルタするように構成されている、請求項１１０に記載のシステム。

【請求項112】

医療データレポートを受信及び送信するように構成されているモバイルコンピューティングデバイスであって、前記モバイルコンピューティングデバイスは、
メモリと、
ユーザインタフェースと、
ネットワークインタフェースと、
前記ユーザインタフェース、前記ネットワークインタフェース、及び前記メモリと通信可能に結合されている少なくとも１つのプロセッサであって、前記少なくとも１つのプロセッサは、
医療レポートの要求を医療デバイスに送信することなく、前記医療デバイスから送信された前記医療レポートを自動的に受信し
前記ユーザインタフェースを介して、前記医療レポートへのアクセスを提供し、
前記医療レポートを１又は複数のリモートコンピューティングデバイスに送信する
ように構成されている、少なくとも１つのプロセッサと
を備えるモバイルコンピューティングデバイス。

【請求項113】

前記医療レポートは、１２リードＥＣＧレポートを含む、請求項１１２に記載のモバイルコンピューティングデバイス。

【請求項114】

前記１２リードＥＣＧレポートは、統合データソースエンカウンタ構造体の１つのレポートである、請求項１１３に記載のモバイルコンピューティングデバイス。

【請求項115】

前記１２リードＥＣＧレポートは、電気波形と、前記電気波形のうちの１又は複数の解釈とを含む、請求項１１３に記載のモバイルコンピューティングデバイス。

【請求項116】

前記医療レポートは、無線ローカルエリアネットワークを介して自動的に受信される、請求項１１２に記載のモバイルコンピューティングデバイス。

【請求項117】

前記医療レポートは、パーソナルエリアネットワークを介して自動的に受信される、請求項１１２に記載のモバイルコンピューティングデバイス。

【請求項118】

前記少なくとも１つのプロセッサは、セルラネットワークを使用して、前記医療レポートを前記１又は複数のリモートコンピューティングデバイスに送信するように構成されている、請求項１１２に記載のモバイルコンピューティングデバイス。

【請求項119】

前記医療レポートは、受信される前に暗号化される、請求項１１２に記載のモバイルコンピューティングデバイス。

【請求項120】

前記少なくとも１つのプロセッサは、前記ユーザインタフェースを介して、前記医療デバイスから通信を受けることをオプトアウトするように構成されている、請求項１１２に記載のモバイルコンピューティングデバイス。

【請求項121】

前記医療デバイスは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、又はウェアラブル除細動器を含む、請求項１１２に記載のモバイルコンピューティングデバイス。

【請求項122】

医療データレポートを受信及び送信するためのコンピュータ実装プロセスであって、前記コンピュータ実装プロセスは、
医療レポートの要求を医療デバイスに送信することなく前記医療デバイスから送信された前記医療レポートを自動的に受信する段階と、
ユーザインタフェースを介して、前記医療レポートへのアクセスを提供する段階と、
前記医療レポートを１又は複数のリモートコンピューティングデバイスに送信する段階と
を備えるコンピュータ実装プロセス。

【請求項123】

ディスプレイを介して、前記医療レポートに関連付けられている１又は複数の波形を表示する段階をさらに備える、請求項１２２に記載のコンピュータ実装プロセス。

【請求項124】

前記医療レポートは、１２リードＥＣＧレポートを含む、請求項１２２に記載のコンピュータ実装プロセス。

【請求項125】

前記１２リードＥＣＧレポートは、統合データソースエンカウンタ構造体の１つのレポートである、請求項１２４に記載のコンピュータ実装プロセス。

【請求項126】

前記１２リードＥＣＧレポートは、電気波形と、前記電気波形のうちの１又は複数の解釈とを含む、請求項１２４に記載のコンピュータ実装プロセス。

【請求項127】

前記自動的に受信する段階は、無線ローカルエリアネットワークを介して、前記医療レポートを自動的に受信する段階を含む、請求項１２２に記載のコンピュータ実装プロセス。

【請求項128】

前記自動的に受信する段階は、パーソナルエリアネットワークを介して、前記医療レポートを自動的に受信する段階を含む、請求項１２２に記載のコンピュータ実装プロセス。

【請求項129】

前記送信する段階は、セルラネットワークを使用して、前記医療レポートを前記１又は複数のリモートコンピューティングデバイスに送信する段階を含む、請求項１２２に記載のコンピュータ実装プロセス。

【請求項130】

前記医療レポートを受信する段階の後で、前記医療レポートを復号する段階をさらに備える、請求項１２２に記載のコンピュータ実装プロセス。

【請求項131】

前記ユーザインタフェースを介して、ユーザからの入力を受信する段階と、前記入力に応答して、任意のさらなる医療レポートを前記自動的に受信することを停止する段階とをさらに備える、請求項１２２に記載のコンピュータ実装プロセス。

【請求項132】

プロセッサに、請求項１２２～１３１のいずれか一項に記載のコンピュータ実装プロセスを実行させるためのコンピュータプログラム。

【請求項133】

請求項１３２に記載のコンピュータプログラムを格納する非一時的コンピュータ可読記憶媒体を備えるモバイルコンピューティングデバイス。

【発明の詳細な説明】

【背景技術】

【0001】

緊急ケア提供者は、彼らが遭遇する患者を処置するために様々な特殊医療デバイスを利用する。これらの特殊医療デバイスとしては、とりわけ、除細動器、人工呼吸器、及び自動化蘇生デバイスを挙げることができる。除細動器は、心室細動又は無脈性心室頻拍等のショック適応心臓不整脈を起こした患者を処置するために使用できる。人工呼吸器は、補助がないと呼吸が困難であるか又は呼吸ができない患者に酸素を供給するために使用できる。いくつかの自動化蘇生デバイスは、突然の心停止を起こした患者に、特にそのような患者が継続的な処置のために他のロケーションに移動される必要がある場合に、心肺蘇生法（ＣＰＲ）胸骨圧迫を実行できる。

【0002】

医療デバイスケースファイルは、上で説明したもの等のコンピュータ化医療デバイスで患者を処置したことの副産物として生じる。医療デバイスケースファイルは、患者エンカウンタ中の医療デバイス操作、患者エンカウンタ中に送達された処置、及び患者エンカウンタ中に医療デバイスによって測定された患者パラメータの値をドキュメント化することができる。医療デバイスケースファイルは、患者の疾患を把握するとともに患者アウトカムを最終的に改善するために、患者エンカウンタ中又はその後にヘルスケア提供者によってレビューされ得る。

【発明の概要】

【0003】

少なくとも１つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタに関与した複数のデバイスからの医療データを集約するシステムが提供される。システムは、それぞれが１又は複数の識別子を有する複数の医療デバイスを含む。複数の医療デバイスのそれぞれは、患者と緊急ヘルスケア提供者との間のエンカウンタに関係するケースデータを取得し、取得されたケースデータを１又は複数の医療デバイスケースファイルとしてサーバに送信するように構成されている。システムは、医療デバイスインタフェース及びユーザインタフェースを有するモバイルコンピューティングデバイスをさらに備える。モバイルコンピューティングデバイスは、医療デバイスインタフェースを介して、複数の医療デバイスの各医療デバイスの１又は複数の識別子の１又は複数の表現を取得し、１又は複数の識別子を含む関連付け情報を生成し、関連付け情報をサーバに送信するように構成されている。サーバは、１又は複数の医療デバイスケースファイルを関連付けるための命令を実行するように少なくとも１つのプロセッサ及びメモリを含む。サーバは、複数の医療デバイス及びモバイルコンピューティングデバイスと通信可能に結合されるように構成されている。サーバは、複数の医療デバイスから１又は複数の医療デバイスケースファイルを受信して格納し、モバイルコンピューティングデバイスから関連付け情報を受信し、１又は複数の医療デバイスケースファイルを互いに関係付けるように関連付け情報に少なくとも部分的に基づいて少なくとも１つの検索基準を生成し、生成された少なくとも１つの検索基準に基づいて関係付けられた１又は複数の医療デバイスケースファイルを識別し、関係付けられた１又は複数の医療デバイスケースファイルからのケースデータを含む統合データソースエンカウンタ構造体を生成するように１又は複数の医療デバイスケースファイルを集約し、患者と緊急ヘルスケア提供者との間のエンカウンタのレビューのために統合データソースエンカウンタ構造体を受信側コンピューティングデバイスに送信するようにさらに構成されている。

【0004】

システムにおいて、受信側コンピューティングデバイスは、モバイルコンピューティングデバイスを含むことができる。モバイルコンピューティングデバイスは、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングするようにさらに構成することができる。統合データソースエンカウンタ構造体は、患者情報以外の情報を含むことができる。

【0005】

システムにおいて、受信側コンピューティングデバイスは、複数の医療デバイスのうちの少なくとも１つの医療デバイスを含むことができる。受信側コンピューティングデバイスは、緊急対応センタ内のコンピューティングデバイスを含むことができる。関連付け情報は、統合データソースエンカウンタ構造体にアクセスするためのトークンを含むことができる。サーバは、緊急対応センタ内のコンピューティングデバイスからトークンを受信するようにさらに構成することができる。システムにおいて、送信することは、トークンの受信に応答して、統合データソースエンカウンタ構造体をコンピューティングデバイスに自動的に送信することを含むことができる。モバイルコンピューティングデバイスは、トークンを緊急対応センタ内のコンピューティングデバイスに送信するように構成することができる。

【0006】

システムにおいて、１又は複数の医療デバイスケースファイルを送信することは、取得されたケースデータの１又は複数のストリームを１又は複数の医療デバイスケースファイルに送信することを含むことができる。統合データソースエンカウンタ構造体は、１又は複数の医療デバイスケースファイルからの取得されたケースデータの１又は複数のストリームを含むことができる。

【0007】

システムは、少なくとも１つのユーザインタフェースを含むコンピューティングデバイスをさらに備えることができる。コンピューティングデバイスは、統合データソースエンカウンタ構造体を受信し、エンカウンタに続いて、少なくとも１つのユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングするように構成することができる。システムにおいて、複数の医療デバイスは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、及びウェアラブル除細動器のうちの１又は複数を含むことができる。

【0008】

システムにおいて、関連付け情報は、患者情報を含むことができる。患者情報は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの１又は複数を含むことができる。関連付け情報は、１又は複数の医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの１又は複数の識別子の１又は複数の表現が取得されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの１又は複数の識別子の１又は複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、各医療デバイスの１又は複数の識別子の１又は複数の表現が取得されたときのモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。

【0009】

システムにおいて、医療デバイスインタフェースは、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも１つを含むことができる。医療デバイスインタフェースは、カメラを備えることができ、１又は複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの１又は複数を含むことができる。

【0010】

システムにおいて、各医療デバイスの１又は複数の識別子は、１又は複数の一意デバイス識別子に対応する。モバイルコンピューティングデバイスは、エンカウンタの１又は複数のログエントリを生成するようにさらに構成することができる。モバイルコンピューティングデバイスは、統合データソースエンカウンタ構造体に含めるために、１又は複数のログエントリをサーバに送信するように構成することができる。サーバは、モバイルコンピューティングデバイスから遠隔にあることができる。

【0011】

システムにおいて、取得されたケースデータは、１２リードＥＣＧデータ等のＥＣＧデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの１又は複数を含む生理学データを含むことができる。取得されたケースデータは、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの１又は複数を含む処置データを含むことができる。取得されたケースデータは、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの１又は複数を含むパフォーマンスデータを含むことができる。取得されたケースデータは、保護された健康情報を含むことができる。

【0012】

少なくとも１つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタからの医療データを集約するための関連付けサーバが提供される。サーバは、メモリと、ネットワークインタフェースと、メモリ及びネットワークインタフェースと通信可能に結合されている少なくとも１つのプロセッサとを備える。メモリは、患者と緊急ヘルスケア提供者との間のエンカウンタ中に記録された複数の医療デバイスケースファイルからのケースデータを格納するように構成されている少なくとも１つのデータベースを格納する。少なくとも１つのプロセッサは、ネットワークインタフェースを介して、エンカウンタ中に患者を処置するために使用された複数の医療デバイスから複数の医療デバイスケースファイルを受信し、複数の医療デバイスケースファイルからのケースデータを少なくとも１つのデータベースに格納し、ネットワークインタフェースを介して、モバイルコンピューティングデバイスから関連付け情報を受信し、関連付け情報は、複数の医療デバイスの各医療デバイスの少なくとも１つの識別子を含み、複数の医療デバイスケースファイルを互いに関係付けるように関連付け情報に少なくとも部分的に基づいて少なくとも１つの検索基準を生成し、生成された少なくとも１つの検索基準に基づいて、関係付けられた複数の医療デバイスケースファイルを識別し、少なくとも１つのデータベースからの複数の医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を生成するように、関係付けられた複数の医療デバイスケースファイルを集約し、患者と緊急ヘルスケア提供者との間のエンカウンタのレビューのために統合データソースエンカウンタ構造体を受信側コンピューティングデバイスに送信するように構成されている。

【0013】

関連付けサーバにおいて、統合データソースエンカウンタ構造体を送信することは、統合データソースエンカウンタ構造体をモバイルコンピューティングデバイスに送信することを含むことができる。統合データソースエンカウンタ構造体は、患者情報以外の情報を含むことができる。統合データソースエンカウンタ構造体を送信することは、統合データソースエンカウンタ構造体を複数の医療デバイスのうちの少なくとも１つの医療デバイスに送信することを含むことができる。統合データソースエンカウンタ構造体を送信することは、統合データソースエンカウンタ構造体を緊急対応センタ内のコンピューティングデバイスに送信することを含むことができる。

【0014】

関連付けサーバにおいて、関連付け情報は、統合データソースエンカウンタ構造体にアクセスするためのトークンを含むことができ、少なくとも１つのプロセッサは、緊急対応センタ内のコンピューティングデバイスからトークンを受信するようにさらに構成することができる。送信することは、トークンの受信に応答して、統合データソースエンカウンタ構造体をコンピューティングデバイスに自動的に送信することを含むことができる。複数の医療デバイスケースファイルを受信することは、複数の医療デバイスからのケースデータの複数のストリームを受信することを含むことができる。統合データソースエンカウンタ構造体は、複数の医療デバイスからのケースデータの複数のストリームを含むことができる。

【0015】

関連付けサーバにおいて、関連付け情報は、患者情報を含むことができる。患者情報は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの１又は複数を含むことができる。関連付け情報は、複数の医療デバイスケースファイルの少なくとも一部が記録されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの少なくとも１つの識別子の１又は複数の表現が取得されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの少なくとも１つの識別子の１又は複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、各医療デバイスの少なくとも１つの識別子の１又は複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。各医療デバイスの１又は複数の識別子は、１又は複数の一意デバイス識別子に対応することができる。

【0016】

関連付けサーバは、モバイルコンピューティングデバイスから遠隔にあることができる。関連付けサーバにおいて、ケースデータは、ＥＣＧデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの１又は複数を含む生理学データを含むことができる。ケースデータは、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの１又は複数を含む処置データを含むことができる。ケースデータは、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの１又は複数を含むパフォーマンスデータを含むことができる。ケースデータは、保護された健康情報を含むことができる。

【0017】

少なくとも１つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタからのケースデータを集約するためのモバイルコンピューティングデバイスが提供される。モバイルコンピューティングデバイスは、メモリと、エンカウンタに関するユーザ入力を受信するように構成されているユーザインタフェースと、医療デバイスの識別子の表現を取得するように構成されている医療デバイスインタフェースと、ネットワークインタフェースと、ユーザインタフェース、医療デバイスインタフェース、ネットワークインタフェース、及びメモリと通信可能に結合されている少なくとも１つのプロセッサとを備える。少なくとも１つのプロセッサは、ユーザインタフェースを介して、エンカウンタに関与した複数の医療デバイスの複数の識別子の複数の表現を取得するように入力を受信し、取得された複数の識別子の複数の表現をメモリに格納し、複数の識別子を含む関連付け情報を生成し、エンカウンタ中に複数の医療デバイスによって生成された少なくとも１つの医療デバイスケースファイルからのケースデータを関連付けて集約するために、関連付け情報をサーバに送信するように構成されている。

【0018】

モバイルコンピューティングデバイスにおいて、少なくとも１つのプロセッサは、ネットワークインタフェースを介して、少なくとも１つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信し、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングするようにさらに構成することができる。統合データソースエンカウンタ構造体は、患者情報以外の情報を含むことができる。ケースデータの一部は、１２リードＥＣＧデータ等のＥＣＧデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの１又は複数を含む生理学データを含むことができる。ケースデータの一部は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの１又は複数を含む処置データを含むことができる。ケースデータの一部は、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの１又は複数を含むパフォーマンスデータを含むことができる。ケースデータの一部は、保護された健康情報を含むことができる。

【0019】

モバイルコンピューティングデバイスにおいて、関連付け情報は、患者情報を含むことができる。患者情報は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの１又は複数を含むことができる。関連付け情報は、少なくとも１つの医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、複数の医療デバイスの複数の識別子の複数の表現が取得されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、少なくとも１つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体にアクセスするためのトークンを含むことができ、少なくとも１つのプロセッサは、トークンを緊急対応センタ内のコンピューティングデバイスに送信するように構成することができる。

【0020】

モバイルコンピューティングデバイスにおいて、医療デバイスインタフェースは、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも１つを含むことができる。医療デバイスインタフェースは、カメラを備えることができ、複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの１又は複数を含むことができる。複数の医療デバイスの複数の識別子は、１又は複数の一意デバイス識別子に対応することができる。少なくとも１つのプロセッサは、エンカウンタの１又は複数のログエントリを生成するようにさらに構成することができる。少なくとも１つのプロセッサは、少なくとも１つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体に含めるために、１又は複数のログエントリをサーバに送信するように構成することができる。モバイルコンピューティングデバイスは、サーバから遠隔にあることができる。

【0021】

少なくとも１つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタからのケースデータを集約するためのコンピュータ実装プロセスが提供される。コンピュータ実装プロセスは、ユーザインタフェースを介して、エンカウンタに関与した複数の医療デバイスの複数の識別子の複数の表現を取得するように入力を受信する段階と、複数の識別子の取得された複数の表現をコンピュータのメモリに格納する段階と、複数の識別子を含む関連付け情報を生成する段階と、コンピュータのネットワークインタフェースを介して、エンカウンタ中に複数の医療デバイスによって生成された少なくとも１つの医療デバイスケースファイルからのケースデータを関連付けて集約するために、関連付け情報をサーバに送信する段階とを備える。

【0022】

コンピュータ実装プロセスは、ネットワークインタフェースを介して、少なくとも１つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信する段階と、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングする段階とをさらに備えることができる。コンピュータ実装プロセスにおいて、統合データソースエンカウンタ構造体を受信する段階は、患者情報以外の情報を受信する段階を含むことができる。
コンピュータ実装プロセスは、ネットワークインタフェースを介して、少なくとも１つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信する段階と、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングする段階とをさらに備えることができる。

【0023】

コンピュータ実装プロセスにおいて、統合データソースエンカウンタ構造体を受信する段階は、患者情報以外の情報を受信する段階を含むことができる。ケースデータの少なくとも一部をレンダリングする段階は、１２リードＥＣＧデータ等のＥＣＧデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの１又は複数を含む生理学データをレンダリングする段階を含むことができる。ケースデータの少なくとも一部をレンダリングする段階は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの１又は複数を含む処置データをレンダリングする段階を含むことができる。ケースデータの少なくとも一部をレンダリングする段階は、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの１又は複数を含むパフォーマンスデータをレンダリングする段階を含むことができる。ケースデータの少なくとも一部をレンダリングすることは、保護された健康情報をレンダリングすることを含むことができる。

【0024】

コンピュータ実装プロセスにおいて、関連付け情報を送信する段階は、患者情報を送信する段階を含むことができる。患者情報を送信する段階は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの１又は複数を送信する段階を含むことができる。関連付け情報を送信する段階は、少なくとも１つの医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を送信する段階を含むことができる。関連付け情報を送信する段階は、複数の医療デバイスの複数の識別子の複数の表現が取得されたときを示すタイムスタンプ情報を送信する段階を含むことができる。関連付け情報を送信する段階は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含むことができる。関連付け情報を送信する段階は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含むことができる。関連付け情報を送信する段階は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含むことができる。関連付け情報を送信する段階は、少なくとも１つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体にアクセスするためのトークンを送信する段階を含むことができ、コンピュータ実装プロセスは、ネットワークインタフェースを介して、トークンを緊急対応センタ内のコンピューティングデバイスに送信する段階をさらに備える。

【0025】

コンピュータ実装プロセスにおいて、複数の表現を取得するように入力を受信する段階は、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも１つを介して入力を受信する段階を含むことができる。複数の表現を取得するように入力を受信する段階は、カメラを介して入力を受信する段階を含むことができ、複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの１又は複数を含む。複数の識別子の複数の表現を取得するように入力を受信する段階は、複数の一意医療デバイス識別子の複数の表現を取得するように入力を受信する段階を含むことができる。

【0026】

コンピュータ実装プロセスは、エンカウンタの１又は複数のログエントリを生成する段階をさらに備えることができる。
コンピュータ実装プロセスは、少なくとも１つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体に含めるために、１又は複数のログエントリをサーバに送信する段階をさらに備えることができる。

【0027】

少なくとも１つの例において、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は、上で説明されたコンピュータ実装プロセスを実行するように構成されている命令を記憶する。いくつかの例において、非一時的コンピュータ可読記憶媒体は、コンピュータ実装プロセスにおいて参照されるサーバから遠隔にあるモバイルコンピューティングデバイスに組み込まれる。

【図面の簡単な説明】

【0028】

以下、縮尺通りに描かれることが意図されていない添付図面を参照しながら、本開示の様々な態様が議論される。これらの図は、様々な例の図示及びさらなる理解を提供するために含まれており、本明細書に組み込まれるとともに本明細書の一部を構成するが、本開示の範囲を限定することは意図されていない。図面は、明細書の残りとともに、記載され且つ特許請求されている態様及び例の原理及び作用を説明する役割を果たす。図では、様々な図に示されている各同一又は略同一の構成要素は、類似の数字によって表されている。明確さのために、全ての構成要素が全ての図においてラベル付けされていない場合がある。特定の図における各構成要素の数は、単に一例であり、他の数の各又は任意の構成要素を使用することができる。

【0029】

【図1】本明細書に開示されている少なくとも１つの例に従った医療記録システムの概略ブロック図である。

【0030】

【図2】本明細書に開示されている少なくとも１つの例に従った関連付け情報の１つの例の記録レイアウト図である。

【0031】

【図3A】本明細書に開示されている少なくとも１つの例に従った、ヘルスケア提供者が様々な医療デバイスから医療デバイス識別子の表現を取得する緊急医療シーンを示す図である。

【図3B】本明細書に開示されている少なくとも１つの例に従った、ヘルスケア提供者が様々な医療デバイスから医療デバイス識別子の表現を取得する緊急医療シーンを示す図である。

【0032】

【図3C】複数の医療デバイスから医療デバイスケースファイルデータストアへの医療デバイスケースファイル及びデータの流れを示すデータフロー図である。

【0033】

【図3D】図３Ｃの医療デバイスケースファイルデータストアから統合データソースエンカウンタ構造体へのケースデータの処理及び流れを示すデータフロー図である。

【0034】

【図4】本明細書に開示されている少なくとも１つの例に従ったケースファイル集約プロセスを示すフロー図である。

【0035】

【図5A】本明細書に開示されている少なくとも１つの例に従った、患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。

【0036】

【図5B】関連付け情報に含まれている医療デバイス識別子と合致する医療デバイス識別子を含む医療デバイスケースファイルを識別する例示的な実装に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。

【0037】

【図5C】関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義されたターゲット時間範囲内のケース開始時間及びケース終了時間を含む医療デバイスケースファイルを識別する例示的な実装に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。

【0038】

【図5D】（ａ）関連付け情報に含まれている医療デバイス識別子に合致する医療デバイス識別子と、（ｂ）関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義されたターゲット時間範囲内のケース開始時間及びケース終了時間とを含む医療デバイスケースファイルを識別する例示的な実装に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。

【0039】

【図6】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。

【0040】

【図7】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。

【0041】

【図8】本明細書に開示されている少なくとも１つの例に従った、医療デバイス、チャート化デバイス、及び患者エンカウンタデータソース統合サービスによって実行される集約プロセスのフロー図である。

【0042】

【図9】本明細書に開示されている少なくとも１つの例に従った、１又は複数の医療デバイスケースファイルの確認を要求するためにｅＰＣＲアプリケーションによって提供されるユーザインタフェーススクリーンのビューである。

【0043】

【図10】本明細書に開示されている少なくとも１つの例に従ったチャート化デバイス及び患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。

【0044】

【図11】本明細書に開示されている少なくとも１つの例に従ったチャート化デバイス及び患者エンカウンタデータソース統合サービスによって実行されるユーザ確認を伴う集約プロセスのフロー図である。

【0045】

【図12】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。

【0046】

【図13】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。

【0047】

【図14】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。

【0048】

【図15】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル関連付けプロセスのフロー図である。

【0049】

【図16】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。

【0050】

【図17】本明細書に開示されている少なくとも１つの例に従った患者エンカウンタデータソース統合サービスによって実行される集約されたデータ共有プロセスのフロー図である。

【0051】

【図18】本明細書に開示されている少なくとも１つの例が実施され得るコンピューティングデバイス及び医療デバイスのコンポーネントの例の概略ブロック図である。

【0052】

【図19】本明細書に開示されている少なくとも１つの例に従ったデータ記録を送信するための医療環境の概略ブロック図である。

【0053】

【図20】本明細書に開示されている少なくとも１つの例に従ったデータ記録を送信するための別の医療環境の概略ブロック図である。

【0054】

【図21】本明細書に開示されている少なくとも１つの例に従ったデータ記録を送信するための別の医療環境の概略ブロック図である。

【0055】

【図22】本明細書に開示されている少なくとも１つの例に従ったローカルデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。

【0056】

【図23A】本明細書に開示されている少なくとも１つの例に従ったリモートデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。

【図23B】本明細書に開示されている少なくとも１つの例に従ったリモートデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。

【図24】本明細書に開示されている少なくとも１つの例に従ったリモートデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。

【0057】

【図25】本明細書に開示されている少なくとも１つの例に従ったローカルデバイスとリモートデバイスとの間のデータ記録送信のフロー図である。

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

【0058】

医療緊急エンカウンタの過程中に生成された医療デバイスケースファイルは、異なるソースから生成された様々な形式で出現し、患者処置の情報を与えることができる豊富な医療データを含み、任意の所与の患者エンカウンタに関するより完全な視点をヘルスケア提供者に提供することによって患者アウトカムを改善する。しかしながら、医療デバイスケースファイルの利便性、アクセシビリティ、及び最終的な使用に対する実用上の制限が、特に緊急医療サービスの分野内に存在する。本開示の実施形態によれば、ヘルスケア提供者は、患者エンカウンタが発生している間及び／又はエンカウンタが終了した後に、同じ患者エンカウンタに関連付けられている複数のデバイス（例えば、除細動器／モニタ、人工呼吸器、ドキュメント化デバイス等）をソースとする医療データ（又は他の関係するデータ）を組み込んだ統合データ構造体へのアクセスを得ることが可能であってよい。エンカウンタの統合データ構造体へのデータのこのリアルタイム集約は、ヘルスケア提供者が、患者のためのケアの総合的な状態を評価し、適切な調整を行うために特に有利であり得る。様々な実施形態において、より具体的には、ヘルスケア提供者は、患者エンカウンタのシーンで使用された複数のデバイスを効果的に一緒に関連付けるためにモバイルコンピューティングデバイスを使用し得る。これらの関連付けは、このデバイス関連付けを使用して、複数のデバイスソースからの受信された医療データを一緒に集約する統合データ構造体を生成するために、データソース統合サービスを実行しているサーバであって、複数のデバイスからの医療データを受信もしているサーバに送信されてよい。統合データ構造体は、ケースエンカウンタが進むにつれて、時間とともに継続的にアップデートされ、ヘルスケア提供者のモバイルコンピューティングデバイス及び／又は別のリモートコンピューティングデバイスに（例えば、テレメディシン、テレヘルスの目的で）さらに送信されてよい。

【0059】

例えば、救急車内における緊急医療サービス（ＥＭＳ）ヘルスケア提供者のうちの１人のクルーが、緊急医療状態（例えば、心停止、外傷、呼吸窮迫、薬剤オーバードーズ等）を起こした患者を処置すること及び患者を病院に輸送することを要請された例示的なシナリオを検討する。この緊急エンカウンタの過程中、ヘルスケア提供者によって提供される処置は、１又は複数のコンピュータ化医療デバイスを介して実施される場合がある。これらの医療デバイスは、ケースファイルを、エンカウンタ内の重要なイベント及びエンカウンタに関する他の関係する情報をドキュメント化するケースデータを含むオープンデータ構造体（例えば、リアルタイムでのストリーミング及び／又はケース後レビューのために）として記録してローカルに格納することができる。リアルタイムストリーミング及び／又はケース後レビューのためのこのケースデータは、エンカウンタ中に医療デバイスがアクセス可能なセンサによって取得された患者の生理学パラメータ、エンカウンタ中に医療デバイスによって制御可能な治療デバイスを介して患者に実施された処置に関するデータ、ＥＭＳヘルスケア提供者のパフォーマンスに関するデータ、保護された健康情報（ＰＨＩ）、及びエンカウンタ内の重要なマイルストーンに関するデータ（例えば、コード／イベントマーカ）を含むことができる。リアルタイムストリーミング及び／又はケース後レビューのためのケースデータ内に格納される生理学パラメータの例は、心拍数、心電図（ＥＣＧ）トレース、血圧データ、カプノグラフィックデータ、温度、血液酸素データ等を含む。リアルタイムストリーミング及び／又はケース後レビューのためのケースデータ内に格納された処置データの例は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データを含む。ケースデータ内に格納されたパフォーマンスデータの例としては、とりわけ、胸骨圧迫パフォーマンスデータ、換気パフォーマンスデータ、及びタイムリー薬剤注入情報が挙げられる。この例示的なシナリオが明らかにするように、患者エンカウンタに関与した様々な医療デバイスによって、多種多様な価値のあるケースデータを生成することができる。しかしながら、医療データを含む医療デバイスケースファイルは、複数のデバイスにわたって散在しており、関係するヘルスケア提供者による即時アクセスのための編成を欠いているので、特に患者エンカウンタが展開する際にリアルタイムで、このケースデータにアクセスすることは、ＥＭＳ及び他のヘルスケア提供者にとって実際的ではない可能性がある。

【0060】

いくつかの医療デバイスは、それらが一元化ストレージロケーション（例えば、サーバ）に生成する医療デバイスケースファイル（例えば、リアルタイムストリーミングフォーマットのデータ構造体）を送信可能であるが、特定の患者エンカウンタをドキュメント化する医療デバイスケースファイル間にリンケージを確立することは、特にエンカウンタが発生している間又はエンカウンタの直後では、厄介である可能性である。異なる程度の開放性及び相互運用性で使用されている多種多様なコンピュータ化医療デバイスが存在する。また、いくつかのＥＭＳエージェンシに関して、継続的にアップデートされる医療デバイスケースファイルの数は、比較的短い時間窓内であっても多い場合がある。例えば、主要なメトロポリタンエリアにおけるＥＭＳエージェンシは、１０～２０又はそれよりも多い同時の患者エンカウンタとともに展開される、１００程度の除細動器を有する場合がある。

【0061】

いくつかの患者エンカウンタに関連付けられている生死に関わる重要性及びストレスのレベルを前提とすると、医療デバイスケースファイル（患者エンカウンタ中のケース中レビューのために継続的にストリーミングしているデータ構造体を含み得る）間に即時のリアルタイムリンクを確立することは、特にケースエンカウンタ中に、ヘルスケア提供者の総合的な体験及び最終的には患者ケアの質を向上させるための強力な方法であり得る。したがって、本明細書に開示されている例のうちの少なくともいくつかは、ヘルスケア提供者が、同じ患者に処置を提供するために使用された複数の医療デバイスのそれぞれを一緒にローカルに関連付けるために患者エンカウンタデバイス関連付けアプリケーションとともに構成されたモバイルコンピューティングデバイスを使用し、結果として、サーバベースの患者エンカウンタデータソース統合サービスとの通信時に、複数の医療デバイスのそれぞれから生成された特定の患者に関係する医療データの全て又は少なくとも一部を含む統合データソースエンカウンタ構造体を生成することを可能にする。様々な実施形態に関して本明細書において議論されているように、統合データソースエンカウンタ構造体は、全て同じ患者エンカウンタに対応する、異なるデバイスソースから生成された医療データを同時に統合する集約されたデータ構造体を含んでよい。これにより、ヘルスケア提供者が、リアルタイムストリーミング状況において及び／又はケース後レビュー中に患者エンカウンタに関連付けられている複数のデバイスから生じた関係するデータを閲覧することが可能になる。

【0062】

以下でさらに詳細に説明されるように、緊急シーンにいるヘルスケア提供者は、モバイルコンピューティングデバイスを使用して、複数の医療デバイスから生成されたデータを効果的に関連付けてよく、この関連付けられたデータは、続いて、エンカウンタ構造体を生成するように構成されているサービスを実行するサーバに送信されると、単一の統合データソースエンカウンタ構造体にして統合することができる。こうして、複数の医療デバイスからのデータを集約する統合患者エンカウンタ構造体を、緊急イベントの過程にわたって及び／又はケース後レビューのために、そのシーンにいるヘルスケア提供者及び／又は遠隔に位置するヘルスケア提供者に利用可能にすることができる。一例として、ヘルスケア提供者は、彼／彼女のモバイルコンピューティングデバイスを使用して、そのシーンにおいて使用された／そのシーンに位置した複数の医療デバイスのそれぞれの識別子又はそれらの表現を取得してよい。患者エンカウンタデバイス関連付けアプリケーションを実行するモバイルデバイスは、次に、識別情報を使用して複数の医療デバイスのそれぞれを一緒に関連付け、関連付け情報を、リモートロケーションに位置する１又は複数のコンピューティングデバイスとすることができる、エンカウンタデータソース統合サービスを実行するサーバシステムに送信してよい。この関連付け情報は、患者エンカウンタを一意に識別するトークン、医療デバイスの識別子、患者エンカウンタに関連付けられているタイムスタンプ情報、患者エンカウンタの地理的ロケーションを識別するジオロケーション情報、及び潜在的には患者エンカウンタに関連付けられている他の情報等の様々な情報要素を含むことができる。サーバシステムは、緊急シーンに位置するとともに患者エンカウンタに関連付けられている医療デバイスのそれぞれから、医療デバイスケースファイル（リアルタイムに継続的にアップデートされてよい）を別個に受信してよい。サーバシステムは、患者エンカウンタに関連付けられていない他のソースから生成された他の医療デバイスケースファイルを図らずも受信してもよい。モバイルコンピューティングデバイスのエンカウンタデバイス関連付けアプリケーションによってアップロードされた関連付け情報をリンクする生成された検索基準に基づいて、サーバシステムは、医療ケースファイル／情報のレポジトリの中を検索し、特定の患者エンカウンタに関連付けられている関係付けられた医療デバイスケースファイルを識別してよい。サーバは、識別された関係付けられた医療デバイスケースファイルから、例えば、緊急シーンにいるヘルスケア提供者及び／又は別の関係するヘルスケア提供者（例えば、テレメディシンを介して応対可能な臨床医）による関係するデータ／イベントの即時のレビューのための単一の統合データソースエンカウンタ構造体を生成してよい。したがって、統合データソースエンカウンタ構造体は、例えば、モバイルコンピューティングデバイスのユーザインタフェース、医療デバイスのうちの１つのユーザインタフェース、又はシーンから遠隔にあるコンピューティングデバイスのユーザインタフェースを介して、レビュー可能であり得る。したがって、ヘルスケア提供者は、サーバ又は複数の医療デバイスのそれぞれのいずれかにおける患者エンカウンタに関連付けられている医療データを要求又は別様に見つける必要がない。むしろ、関係する医療データは、適切な医療デバイスとそれらの関係するケースファイルデータとを効果的に一緒にリンクするために彼／彼女のモバイルデバイスを使用する際に、ヘルスケア提供者に即時に利用可能にされ得る。

【0063】

図１は、いくつかの例に従って、患者エンカウンタデータソース統合サービス１３０と、モバイルコンピューティングデバイス１０４のそれぞれの患者エンカウンタデバイス関連付けアプリケーション１５０Ａ及び１５０Ｂの一部としてのデバイス関連付け生成器１４２Ａ及び１４２Ｂとを備えるとともにこれらを実施する医療記録システム１００を示している。システム１００は、本開示の例によれば、複数の異なる医療デバイス１０２Ａ～１０２Ｎからのケースファイルを互いに関連付けて、患者エンカウンタの統合データソース構造体を生成することができる。これらの集約された医療記録は、患者エンカウンタをドキュメント化するだけでなく、患者アウトカムを改善するために必要とされる情報をヘルスケア提供者に提供もする。図１に示されているように、医療記録システム１００は、ネットワーク１１２を介して互いに結合されている、１又は複数の医療デバイス１０２Ａ～１０２Ｎと、１又は複数のモバイルコンピューティングデバイス１０４Ａ～１０４Ｃと、リモートコンピューティングデバイス１０６と、１又は複数のサーバ１０８とを備える。医療デバイス１０２Ａ～１０２Ｎのそれぞれは、患者エンカウンタ中に患者１１６に結合するようにさらに構成されている１又は複数の患者インタフェースデバイス１９０Ａ～１９０Ｎに結合するように構成されている。参照しやすさのために、医療デバイス１０２Ａ～１０２Ｎ、モバイルコンピューティングデバイス１０４Ａ～１０４Ｃ、患者エンカウンタデバイス関連付けアプリケーション１５０Ａ～１５０Ｂ、及び患者インタフェースデバイス１９０Ａ～１９０Ｎのそれぞれは、本明細書において、まとめて医療デバイス１０２、モバイルコンピューティングデバイス１０４、及び患者インタフェースデバイス１９０と称されてよい。これらの集合体の個々のメンバは、医療デバイス１０２、モバイルコンピューティングデバイス１０４、患者エンカウンタデバイス関連付けアプリケーション１５０、及び患者インタフェースデバイス１９０と総称されてもよい。

【0064】

システム１００は、モバイルコンピューティングデバイス１０４及び医療デバイス１０２から遠隔に位置してよいサーバ１０８をさらに備える。例えば、サーバ１０８は、電力及びネットワーク接続をサーバ１０８に提供するデータセンタに収容されてよい。図１に示されているように、サーバ１０８は、医療デバイスケースアプリケーションプログラミングインタフェース（ＡＰＩ）１２６、ｅＰＣＲ ＡＰＩ１２８、患者エンカウンタデータソース統合サービス１３０、医療デバイスケースデータストア１３２、患者チャート化データストア１３４、基準データストア１３６、イベントログＡＰＩ１４４、及びイベントログデータストア１４６のうちの１又は複数をホストするように構成することができる。リモートコンピューティングデバイス１０６は、健康記録データストア１１０をホストするように構成することができ、これは、患者の医療記録のために医療データを受信して格納することができる。少なくとも１つの例において、サーバ１０８の関連付けサーバは、患者エンカウンタデータソース統合サービス１３０をホストする。

【0065】

システム１００の少なくとも一部は、ケースデータを識別するために関連付け情報の複数の態様を利用することが有利である。本開示の実施形態において、モバイルコンピューティングデバイス１０４は、関連付け情報を生成するために関連付け生成器を含む患者エンカウンタデバイス関連付けアプリケーション１５０を有してよい。したがって、読み手の理解を補助するために、関連付け情報と、関連付け情報を発生させる医療記録システム１００の一部との説明が、患者エンカウンタデータソース統合サービス１３０及びシステム１００の他の部分によって実行されるデータソース統合プロセスの説明の前に提供される。

【0066】

いくつかの例において、関連付け情報は、２又は２よりも多い医療デバイスケースファイルが特定の患者エンカウンタ内に生成されたか否かを決定するのに有用なデータの任意の要素を含む。したがって、多種多様なデータを、様々な例において関連付け情報として特徴付けることができる。例えば、いくつかの例において、関連付け情報は、ケースファイルを生成した医療デバイス１０２の１又は複数の識別子、患者エンカウンタ中に処置された患者に関する情報（例えば、患者名又は患者の他の識別子、年齢、性別、体重、身長、及び／又は既往歴）、患者エンカウンタ中に記録されたタイムスタンプ情報（例えば、医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ及び／又は医療デバイス１０２の１又は複数の識別子が取得されたときを示すタイムスタンプ）、患者エンカウンタ中に記録されたジオロケーション情報（例えば、モバイルコンピューティングデバイス１０４が医療デバイス１０２の１又は複数の識別子を取得した地理的ロケーションを識別するジオタグ）、及び／又は患者エンカウンタ中のモバイルコンピューティングデバイス１０４の患者エンカウンタデバイス関連付けアプリケーション１５０によるトークン（例えば、ユニバーサル一意識別子（ＵＵＩＤ）又は患者エンカウンタを一意に識別するデータ）を含むことができる。関連付け情報は、以下でさらに詳細に議論される、イベントログデータ及び／又はチャート化データの一部も含むことができる。

【0067】

関連付け情報は、多種多様なソースから発生することができる。例えば、いくつかの例において、それぞれのエンカウンタデバイス関連付けアプリケーション１５０の関連付け生成器１４２Ａ及び１４２Ｂは、要求を受けると関連付け情報を生成するように構成されている。いくつかの例において、要求は、システム１００によってホストされている他のプロセス（例えば、ｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０）から受信されるシステムメッセージ内に埋め込むことができる。これらの例において、関連付け生成器１４２Ａ及び１４２Ｂは、関連付け情報の要求された要素（例えば、特定の患者エンカウンタを識別するトークン）を生成し、関連付け情報の要求された要素を要求側プロセスに戻すように構成されている。いくつかの例において、関連付け情報の要求は、モバイルコンピューティングデバイス１０４のユーザインタフェースから受信された入力とすることもできる。これらの例において、関連付け生成器１４２Ａ及び１４２Ｂは、要求された関連付け情報を生成し、後続の処理のために関連付け情報をローカルに格納するように構成されている。代替的に又は加えて、いくつかの例において、ｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０は、それらのエンカウンタドキュメント化プロセスの実行を介して関連付け情報を生成するように構成されている。ｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０によって生成された関連付け情報の例は、本明細書において議論されているようにｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０によって収集される他のタイプの情報の中でも、患者人口統計学情報及び／又は生理学情報を含むことができる。

【0068】

図２は、関連付け生成器１４２Ａ及び１４２Ｂが個々に又はｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０と連携して生成するように構成されている関連付け情報の記録の１つの例を示している。図２に示されているように、関連付け情報記録は、エンカウンタＩＤフィールド２０２と、第１の医療デバイスＩＤフィールド２０４と、第１のタイムスタンプフィールド２０６と、第２の医療デバイスＩＤフィールド２０８と、第２のタイムスタンプフィールド２１０とを含む。この例において、エンカウンタＩＤフィールド２０２は、トークン（ここではＵＵＩＤ）を格納するように構成されており、第１の医療デバイスＩＤフィールド２０４及び第２の医療デバイスＩＤフィールド及び２０８は、医療デバイスシリアルナンバを格納するように構成されており、第１のタイムスタンプフィールド及び第２のタイムスタンプフィールド２０６及び２１０は、同じ患者エンカウンタに関係するケースファイルを一緒に関連付けるのに使用されてよいタイムスタンプを格納するように構成されている。図２を考慮すれば理解されるように、関連付け情報記録２００は、第１の医療デバイス及び第２の医療デバイス並びにそれらのそれぞれのタイムスタンプを、エンカウンタＩＤ２０２によって一意に識別される患者エンカウンタに関係付ける。さらに、以下で詳細に説明されるように、関連付け情報記録２００内の各＜医療デバイスＩＤ，タイムスタンプ＞値ペアは、エンカウンタＩＤ２０２によって識別される患者エンカウンタ中に生成された医療デバイスケースファイルを高い信頼度で識別するのに必要な情報を、患者エンカウンタデータソース統合サービス１３０に提供する。

【0069】

図１に戻ると、いくつかの例において、患者エンカウンタデータソース統合サービス１３０は、関連付け情報をモニタするとともにこれを受信するように構成されている。例えば、いくつかの例において、患者エンカウンタデータソース統合サービス１３０は、ネットワーク１１２を介して受信されるインバウンド関連付け情報についてチャート化データストア１３４及び／又はイベントログデータストア１４６をモニタするように構成されている。代替的に又は加えて、患者エンカウンタデータソース統合サービス１３０は、ネットワーク１１２を介して受信される関連付け情報を含むｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４からのメッセージを受信するように構成することができる。それにもかかわらず、インバウンド関連付け情報は、例えば、モバイルコンピューティングデバイス１０４によって生成され送信された１又は複数の新たな又は修正されたｅＰＣＲ又はイベントログをソースとすることができる。代替的に又は加えて、インバウンド関連付け情報は、例えば、関連付け生成器１４２Ａ及び／又は１４２Ｂのうちの１つによって送信される別個のメッセージをソースとすることができる。現実的な使用シナリオの状況内でのこれらのプログラムの動作は、以下でより詳細に説明される。

【0070】

インバウンド関連付け情報をハンドリングするために、患者エンカウンタデータソース統合サービス１３０は、インバウンド関連付け情報に関連付けられている患者エンカウンタ中に生成された１又は複数のケースファイルから発生したケースデータストア１３２内のケースデータを識別することを試みる１又は複数のプロセスを実行するように構成されている。これらのプロセスの例は、図４～図１７を参照して以下で詳細に説明される。患者エンカウンタデータソース統合サービス１３０は、インバウンド関連付け情報に関連付けられている患者エンカウンタ中に生成されたケースデータを識別することに応答して、いくつかのアクションのうちの１又は複数を取るように構成することができる。これらのアクションは、ケースデータを含む集約された医療データを生成すること及び／又はケースデータをチャート化データ及び／又はイベントログデータと組み合わせること、集約された医療データを（例えば、チャート化データストア１３４及び／又はイベントログデータストアに）格納すること、統合データソースエンカウンタ構造体の形式の集約された医療データ若しくはその一部を含むメッセージを送信すること、及び／又はケースデータ若しくはケースデータの識別子を含むメッセージを送信することを含んでよい。これらのメッセージは、ネットワーク１１２と、ｅＰＣＲ ＡＰＩ１２８、イベントログＡＰＩ１４４、及びケースＡＰＩ１２６のうちの１又は複数とを介して、モバイルコンピューティングデバイス１０４、医療デバイス１０２、及び／又はリモートコンピューティングデバイス１０６に（例えば、健康記録データストア１１０における格納のために）送信することができる。対応するケースデータを識別することに応答して患者エンカウンタデータソース統合サービス１３０が取るように構成されてよいこれらのアクション及び他のアクションは、図４～図１７を参照して以下でも詳細に説明される。
［ＥＭＳ例］

【0071】

いくつかの例において、例えばＥＭＳ技術者であってよいヘルスケア提供者１１８Ａは、患者１１６をモニタする及び／又は処置するために、医療デバイス１０２のうちの１又は複数に結合された患者インタフェースデバイス１９０Ａ～１９０Ｎ（例えば、生理学センサ、ＥＣＧセンサ、ＳｐＯ２センサ、カプノグラフィセンサ、血圧センサ等）を患者１１６に取り付けることができる。この処置は、医療デバイス１０２が関与してよく、イベント及び他の情報等の特定の態様は、モバイルコンピューティングデバイス１０４のうちの１つのｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０を介してヘルスケア提供者１１８Ａによってドキュメント化されてよい。

【0072】

本明細書において議論されるように、図３Ａ～図３Ｃにより具体的に示されているもの等の複数の異なるタイプの医療デバイス１０２を用いてよい。例えば、本明細書において議論されるように、除細動器／モニタ３０２Ｂは、数例を挙げると、患者情報（例えば、名前、性別、サイズ、体重、年齢、身長、病歴等）、生理学情報（例えば、とりわけ、ＥＣＧ波形、レビューのためにマークされた／注記された特定の注目に値するイベントの前及び／又は後のＥＣＧスナップショット、心拍数、酸素飽和度データ、ＣＯ２データ、血圧データ）、処置情報（例えば、薬剤注入、電気治療イベント、胸骨圧迫の開始、換気の開始）、及びヘルスケア提供者パフォーマンス情報（例えば、平均胸骨圧迫深さ、平均胸骨圧迫回数、深さ／回数に関するターゲットに入る胸骨圧迫のパーセンテージ、平均放出速度、プレショックＣＰＲポーズ、ポストショックＣＰＲポーズ、換気の一回換気量データ、分時換気量データ、換気回数データ、薬剤注入タイミング等）を含む、様々な異なるタイプのデータを収集してよい。ＥＣＧ波形及び／又はＥＣＧスナップショットは、標準的な１２リードレポートを生成するために、患者の身体に結合された１０又はそれよりも多い電極を使用して捕捉されてよい。除細動器／モニタ３０２Ｂによって収集された情報の一部又は全ては、取得されたら、定期的な間隔でアップデートされてよい医療デバイスケースファイルとして、ネットワークを介して１又は複数のサーバに（例えば、図１のサーバ１０８及びネットワーク１１２に、継続的に、定期的に、及び／又はケース後に）アップロードされてよい。各医療デバイスケースファイルは、識別情報、例えば、ケースファイルの発生元であるデバイスの識別子、患者エンカウンタの開始、終了、時間の長さに関係するタイムスタンプデータ、及び／又は患者エンカウンタ中のデバイスのジオロケーション情報を有することができる。適切な除細動器／モニタの一例は、ゾールメディカルコーポレーションによって提供されるＸ Ｓｅｒｉｅｓ（登録商標）除細動器／モニタであるが、他の好適な除細動器／モニタデバイスを本開示に従って使用してもよい。

【0073】

図３Ａに示されているように、患者エンカウンタに関係する他のケースファイルとの集約のためにサーバ１０８に継続的なリアルタイムデータを送信しているそのシーンに位置する他の医療デバイスは、例えば、人工呼吸器３０２Ｃ、自動化胸骨圧迫器３０２Ａ、及び／又は他の医療デバイスを含んでよい。例えば、人工呼吸器３０２Ｃは、患者情報（例えば、名前、性別、サイズ、体重、年齢、身長、病歴等）、生理学情報（例えば、とりわけ、心拍数、酸素飽和度データ、ＣＯ２データ）、処置情報（例えば、吸入中酸素濃度、最大吸気圧設定、一回換気量、分時換気量、換気回数）、及び／又は他の関係する情報を含む様々なタイプのデータを収集し、それを取得するとサーバ１０８に（継続的に、定期的に、及び／又はケース後に）送信してよい。様々な例において、人工呼吸器３０２Ｃは、ゾールメディカルコーポレーションによって提供されるＺ Ｖｅｎｔ（登録商標）人工呼吸器に類似する機能を有してよいが、他の人工呼吸器を用いてもよい。自動化胸骨圧迫器３０２Ａは、患者情報、生理学情報、胸骨圧迫設定（例えば、深さ、レート、デューティサイクル等）及び／又は他の関係する情報等の処置情報を含む特定のタイプのデータを取得すると、それを（継続的に、定期的に、及び／又はケース後に）送信してもよい。特定の例において、自動化胸骨圧迫器３０２Ａは、ゾールメディカルコーポレーションによって提供されるＡｕｔｏＰｕｌｓｅ（登録商標）胸骨圧迫デバイスの機能に類似する機能を有してよいが、他の好適な胸骨圧迫デバイスを使用してもよい。除細動器／モニタ３０２Ｂと同様に、このようなデバイスは、収集された情報の一部又は全てを、それぞれそれらの独自の識別情報を伴う医療デバイスケースファイルとしてサーバ１０８に送信してよい。結果として、特定の医療緊急事態に関係する情報は、グループ化され、一緒に集約されてよく、関連付けを開始したオリジナルヘルスケア提供者は、シーンにいるか又はシーンから遠隔にいるかのいずれかの他の適切な人員とともに、情報に対するリアルタイムアクセスを有する。

【0074】

図３Ａに示されているように、緊急医療イベント中、ヘルスケア提供者１１８Ａは、単一の患者（例えば、図１の患者１１６）に対して、自動化胸骨圧迫器３０２Ａ、除細動器／モニタ３０２Ｂ、及び人工呼吸器３０２Ｃを使用する。本明細書において議論されるように、自動化胸骨圧迫器３０２Ａは、用手圧迫を与えることをヘルスケア提供者に要求することなく、指定された圧迫深さ及び回数パラメータに従って患者に胸骨圧迫を実施するために使用されてよい。除細動器／モニタ３０２Ｂは、例えば、患者が生命を脅かす不整脈を起こしたか否かを評価する際に除細動電極及び／又は生理学情報を収集するため及び患者をモニタするための他の患者センサを介して患者に接続されてよい。人工呼吸器３０２Ｃは、挿管チューブ又はマスクを通して患者に酸素を提供してよい。これらの医療デバイス３０２Ａ、３０２Ｂ、３０２Ｃのそれぞれは、患者エンカウンタに関係するデータを収集するように構成されており、さらなる処理のために、このデータをサーバ１０８上に格納されたケースファイルの大型中央レポジトリにアップロードしてよい。

【0075】

患者エンカウンタのシーンにいるヘルスケア提供者１１８Ａは、ドキュメント化ツールを通して、注目に値するイベントのログエントリを生成する、及び／又は、ｅＰＣＲのためのチャート化ツールを介して患者情報を入力する等、彼らのそれぞれのモバイルコンピューティングデバイスをさらに使用して、他の情報を生成してよい。そのような記録も、他の医療デバイスケースファイルとともにサーバ１０８の中央レポジトリにアップロードされてよい。通常、別のユーザは、ケースファイルのこのレポジトリを取捨選択して、さらなる閲覧のために様々なファイルからの情報を互いに合致させる必要があるが、本開示の例は、リアルタイムに、患者エンカウンタ中及び／又は後に閲覧するために、特定の患者エンカウンタに関係するケースファイルを、関連付けるか又は別様に一緒にリンクさせて、単一の記録に集約させることを可能にする。

【0076】

例えば、図３Ａに示されているように、シーンにいるヘルスケア提供者１１８Ａは、エンカウンタデバイス関連付けアプリケーション（例えば、図１の患者エンカウンタデバイス関連付けアプリケーション１５０）を実行するモバイルコンピューティングデバイス１０４Ｂを使用して、患者エンカウンタのケースファイルを総合するためにサーバ１０８によって使用されてよい関連付け情報を生成する。例えば、ヘルスケア提供者１１８Ａは、患者エンカウンタ前、中、又は後に、モバイルコンピューティングデバイス１０４Ｂとともに含まれる医療デバイスインタフェースを使用して、各医療デバイスの表現を取得するために医療デバイスから医療デバイスに移動することができる。例えば、ヘルスケア提供者１１８Ａは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ｂの一部であるカメラを使用して、除細動器／モニタ３０２Ｂに付けられている第１のクイックレスポンス（ＱＲ）コードをスキャン（例えば、そのイメージを取得）することができる。又は、ヘルスケア提供者１１８Ａは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ｂに含まれている近距離通信（ＮＦＣ）リーダを、除細動器／モニタ３０２Ｂに付けられている又はその内に収容されているＮＦＣタグに近接するように位置付けて、除細動器／モニタ３０２Ｂを識別する磁気シグネチャを取得することができる。次に、ヘルスケア提供者１１８Ａは、自動化胸骨圧迫器３０２Ａまで移動して、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ｂとインタラクトして、自動化胸骨圧迫器３０２Ａに付けられたクイックレスポンス（ＱＲ）コードをスキャンすることができる。又は、ヘルスケア提供者１１８Ａは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ｂに含まれているＮＦＣリーダを、自動化胸骨圧迫器３０２Ａに付けられている又はその内に収容されているＮＦＣタグに近接するように位置付けて、自動化胸骨圧迫器３０２Ａを識別する磁気シグネチャを取得することができる。最後に、図３Ａに示されているように、ヘルスケア提供者１１８Ａは、人工呼吸器３０２Ｃまで移動して、人工呼吸器３０２Ｃを識別する磁気シグネチャを取得するために、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ｂに含まれているＮＦＣリーダを、人工呼吸器３０２Ｃに付けられている又はその内に収容されているＮＦＣタグに近接するように位置付けることができる。ＮＦＣタグの代わりに、ヘルスケア提供者１１８Ａは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ｂを使用して、人工呼吸器３０２Ｃに付けられているクイックレスポンス（ＱＲ）コードをスキャンすることができる。上で説明したイメージ及び磁気シグネチャの取得は、いくつかの緊急患者エンカウンタでは時間が最も重要であるため、設計上迅速で軽量であることに留意すべきである。これらの状況において、ヘルスケア提供者１１８Ａは、患者エンカウンタに関与する各医療デバイスとロバストな双方向の完全に認証されたネットワーク通信セッションを確立することが可能でなくても又はその意思がなくてもよい。さらに、これらの軽量通信メカニズムは、医療デバイスに、それらが提供する一方向通信及び制限された機能に起因して、医療デバイスをハックするために利用することができない点でさらなるセキュリティを提供する。

【0077】

代替的に又は加えて、図１と組み合わせて参照される図３Ａによって示されているいくつかの例において、ヘルスケア提供者１１８Ａは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ｂを使用して、イベントログアプリケーション１４０、ｅＰＣＲアプリケーション１２２、又は関連付け生成器１４２Ａ及び１４２Ｂのいずれかのうちの任意のものによって提供されるユーザインタフェースに適切な入力を供給することによって医療デバイスの識別子の表現を取得することができる。様々な例において、これらのプログラムのそれぞれは、医療デバイスの識別子の表現を取得する要求を示す入力を受信し、識別子の表現をスキャンする又は別様に取得するように医療デバイスインタフェースを制御することによって、そのような要求に応答するように構成されている。このようにスキャンされたＱＲコード（登録商標）（又は取得された関係する識別タグ）は、この特定の患者エンカウンタを識別するトークン及び表現が取得された時間を示すタイムスタンプとともに、関連付け情報に格納することができる。関連付け情報に格納することができる他の情報として、各表現の取得時におけるモバイルコンピューティングデバイス１０４Ｂのジオロケーションを示すジオタグが挙げられる。関連付け情報が完成した後、その作成を担当するプログラムは、関連付け情報をローカルに（例えば、ローカルイベントログデータ、チャート化データ内に、又は別個の関連付け情報として）格納し、及び／又は、適切なインタフェース（例えば、ｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４）を介して、関連付け情報を別個の関連付け情報として又はチャート化データ及び／又はイベントログデータに関連付けて及び／又はそれらに埋め込んでサーバ１０８に送信することができる。医療デバイスの表現は、患者エンカウンタ中、又はいくつかの場合では患者エンカウンタの前若しくは後であっても、任意の時間に取得することができることに留意すべきである。いくつかの例において、ユーザは、特定の患者エンカウンタに関係するケースファイルを関連付けるために、関連付け情報を生成して適切なサーバに送信するように、モバイルコンピューティングデバイス１０４Ｂに確認を提供する。

【0078】

いくつかの例において、表現を取得し、これらを、医療デバイス３０２Ａ～３０２Ｃを識別するデータに変換し、ユーザ確認を受信した後、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルデバイス１０４Ｂは、関連付け情報を（例えば、図２に示されているように）生成し、ネットワーク１１２を介して関連付け情報をサーバ１０８に送信する。いくつかの例において、モバイルコンピューティングデバイス１０４Ｂは、リアルタイムで、ネットワーク１１２を介してサーバ１０８から、医療デバイス３０２Ａ～３０２Ｃによってそれらの患者１１６の処置中に生成された医療デバイスケースファイルからの情報を含む統合データソースエンカウンタ構造体を受信することができる。これらの例において、エンカウンタデータソース統合サービスを提供するサーバ１０８は、関連付け情報の受信に応答して、統合データソースエンカウンタ構造体を自動的に生成し送信するように構成されている。

【0079】

さらに、図３Ａに示されているように、サーバ１０８は、ヘルスケア提供者１１８Ｂがヘルスケア提供者１１８Ａにサポートを提供することを可能にするために、患者１１６の受け入れの準備するために、及び／又はテレメディシンの目的で、統合データソースエンカウンタ構造体をモバイルコンピューティングデバイス１０４Ｃに送信するように構成することができる。いくつかの例において、エンカウンタレビューアプリケーション１４８は、サーバ１０８から統合データソースエンカウンタ構造体を受信し、モバイルコンピューティングデバイス１０４Ｃのユーザインタフェースを介して、統合データソースエンカウンタ構造体をヘルスケア提供者１１８Ｂに提供するように構成されている。少なくともいくつかの例において、エンカウンタレビューアプリケーション１４８は、ゾールメディカルコーポレーションによって提供されるＲｅｓｃｕｅＮｅｔ（登録商標）コードレビューを含むことができる。いくつかの実施形態において、エンカウンタレビューアプリケーション１４８は、関連付け情報を生成することと統合データソースエンカウンタ構造体の集約されたデータをレビューすることとの両方のために同じソフトウェアアプリケーションが使用されてよいという点で、エンカウンタデバイス関連付けアプリケーションと一致してよい。

【0080】

さらに、本開示の例は、緊急事態中の異なる時点で患者に適用された医療デバイスから生成されたデータが集約されることを可能にし得る。図３Ｂは、緊急エンカウンタが３つの別個のフェーズ３１５Ａ、３１５Ｂ及び３１５Ｃにセグメント化された一例を示している。フェーズ３１５Ａにおいて、患者（例えば、患者１１６）は、現在病院におらず、突然の心停止等の医療緊急事態を起こしている。このような状況において、大群の適切な医療デバイスが即時に存在することは稀である。事実、医療経験が非常に乏しい居合わせた人物３００のみが救護に携わることができる可能性がより高い。居合わせた人物３００は、例えば、付近のウォールキャビネットに保管されているパブリックアクセス自動体外式除細動器（ＡＥＤ）３０２Ｄを見つけ、緊急医療サービス（ＥＭＳ）に電話をかける冷静沈着さを有し得る。居合わせた人物３００は、次に、除細動電極パッドを患者に適用して、ＡＥＤによって提供されるステップバイステップの指示に従って、ＣＰＲを実施してよく、ＡＥＤの例としては、ゾールメディカルコーポレーションによって提供されるＡＥＤ Ｐｌｕｓ（登録商標）又はＺＯＬＬ ＡＥＤ３（登録商標）パブリックアクセスＡＥＤが挙げられ得る。いくつかの例において、ＡＥＤ３０２Ｄは、患者のＥＣＧ波形、与えられた除細動ショックの数、除細動ショックに関連付けられているＥＣＧスナップショット、及び胸骨圧迫パフォーマンス情報等のデータを収集してよく、本明細書においてさらに説明するように、そのような情報を関連付け能力を有するサーバ１０８にアップロードしてよい。

【0081】

本明細書において説明されている例によれば、フェーズ３１５ＢにおいてＥＭＳが到着すると、ヘルスケア提供者１１８Ａは、モバイルコンピューティングデバイス１０４を介してその中に格納されているケースデータにアクセスしようとして、患者エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４を使用して、ＡＥＤ３０２Ｄの識別子の表現を迅速に取得（例えば、ＱＲコード識別子をスキャン、ＮＦＣ又は無線周波数識別（ＲＦＩＤ）タグ識別子を取得）することができる。さらに、より多くの医学訓練を受けているヘルスケア提供者１１８Ａは、より高度なケア及び生理学モニタリングのために、血圧センサ及びＳｐＯ２センサ等の他のセンサとともに、プロフェッショナルグレード除細動器／モニタ３０２Ｂを使用して、ＥＣＧ電極（例えば、１２リード、３リード）を取り付けてよい。到着すると、より高度な除細動器／モニタ３０２Ｂは、例えば、とりわけ、心拍数、患者のＥＣＧ波形、与えられた除細動ショックの数、除細動ショックに関連付けられているＥＣＧスナップショット、血圧読み取り値／傾向、酸素飽和度読み取り値／傾向、薬剤注入、胸骨圧迫及び換気パフォーマンス情報等のデータも収集してよい。そのような情報は、データが患者エンカウンタ中に時間とともにアップデートされるのと同時に、継続的及び／又は定期的に、関連付け能力を有する適切なサーバ１０８にアップロードされてよい。本開示の態様によれば、ヘルスケア提供者１１８Ａは、エンカウンタデータソース統合サービスが２つのデバイス並びに関係する患者及び処置情報を含む対応するケースファイル／データを特定の緊急イベントに関連付けるために、エンカウンタデバイス関連付けアプリケーションを実行するモバイルコンピューティングデバイス１０４を使用して、ＡＥＤ３０２Ｄ及び除細動器／モニタ３０２Ｂの識別子（例えば、スキャンされたＱＲ／バーコード、ＮＦＣ接続又はＲＦＩＤを介した取得）を取得してよい。

【0082】

フェーズ３１５Ｃにおいて、ＥＭＳは、患者が即時の病院ケアを要求すると決定してよく、したがって、病院に向かう途中でのケアのための自動化胸骨圧迫器３０２Ａ及び人工呼吸器ユニット３０２Ｃをさらに装備した救急車を介した輸送を開始してよい。本明細書において議論されるように、様々な例において、自動化胸骨圧迫器３０２Ａは、予め指定されたパラメータに従って胸骨圧迫を提供してよく、人工呼吸器ユニット３０２Ｃは、患者の酸素飽和度及び心拍数レベルをモニタし、例えば、ユーザ補助を伴って自動化換気を実施してよい。ヘルスケア提供者１１８Ａは、エンカウンタデータソース統合サービスが、追加の２つのデバイス並びに患者情報及び処置情報を含むそれぞれのケースファイルをこの特定の緊急イベントに関連付けることが可能であるように、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス１０４Ａをさらに使用して、自動化胸骨圧迫器３０２Ａ及び人工呼吸器３０２Ｃ識別子（例えば、スキャンされたＱＲ／バーコード、ＮＦＣ接続を介した取得）を取得してよい。ヘルスケア提供者１１８Ａは、モバイルデバイス１０４を使用して、特定の緊急患者／イベントに関する４つの別個のデバイスによって生成された情報を一緒に関連付けることをエンカウンタデータソース統合サービスにさらに要求してよく、関連付け能力を有するサーバ１０８は、アップロードされたケースファイルから提供される医療データを統合データソースエンカウンタ構造体に集約することができる。結果として得られる統合データソースエンカウンタ構造体は、次に、居合わせた人物３００によって及びＥＭＳによって、またさらには、緊急事態においてさらにより多くの医療デバイスを使用し得る病院（この例では具体的に説明されない）によって処置された患者１１６に関する関係データの全てを含んでよい。様々な例において、この統合データソースエンカウンタ構造体は、リアルタイム及び／又はケース後レビューのために、患者の近傍又は遠隔のいずれかに位置する適切なヘルスケア提供者に送信することができる。以下でさらに説明される図３Ｃ及び図３Ｄは、これらの例のうちのいくつかにおけるデータの例示的なフローを示している。

【0083】

より具体的には、図３Ｃは、いくつかの例の送信及び格納アクティビティを示すデータフロー図である。図３Ｃに示されているように、医療デバイス３０２Ａ～３０２Ｄは、それぞれのケースファイル３０４Ａ～３０４Ｄをそれぞれ生成してよく、これは、患者エンカウンタの過程を通して継続的及び／又は定期的にアップデートされてよい。ケースファイル３０４Ａ～３０４Ｄのそれぞれは、例えば、図３Ａ及び図３Ｂに示されているように、患者１１６とのエンカウンタ中にその関連付けられた医療デバイスによって生成されたケースデータを含む。例えば、ケースファイル３０４Ａは、自動胸骨圧迫器３０２Ａによって記録されたケースデータを格納する。ケースファイル３０４Ａは、自動胸骨圧迫器３０２Ａの識別子、自動胸骨圧迫器３０２Ａによって検出されたイベント、これらのイベントに関する詳細、及び各イベントが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図３Ｃに示されているように、自動胸骨圧迫器３０２Ａが検出しケースファイル３０４Ａに記録するイベントのタイプは、開始／電源オンイベント、終了／電源オフイベント、及び自動化圧迫設定の構成を含む。自動化圧迫設定は、他の設定の中でも、深さ、レート、及びデューティサイクルを含むことができる。様々な実施形態において、デバイス３０２Ａは、データを取得するとケースファイル３０４Ａを継続的にアップデートし、これは、患者エンカウンタデータソース統合サービスを実行しているサーバにさらにアップロードされる。

【0084】

図３Ｃを引き続き参照すると、ケースファイル３０４Ｂは、除細動器／モニタ３０２Ｂによって記録されたケースデータを格納し、これは、患者エンカウンタの過程を通して継続的及び／又は定期的にアップデートされてよい。ケースファイル３０４Ｂは、除細動器／モニタ３０２Ｂの識別子、除細動器／モニタ３０２Ｂによって検出されたイベント及びパラメータ、これらのイベント及びパラメータに関する詳細、並びに各イベント又はパラメータが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図３Ｃに示されているように、除細動器／モニタ３０２Ｂが検出してケースファイル３０４Ｂに記録するイベント及びパラメータのタイプは、開始／電源オンイベント、終了／電源オフイベント、患者の血圧の測定（観血及び非観血）、患者のパルスオキシメトリ（瞬間的及び傾向）、患者の呼気終末二酸化炭素読み取り値（瞬間的及び傾向）、治療パッド取り付けイベント、患者に取り付けられた治療パッドに関する情報、患者に送達された電気治療ショックを記述する情報、患者に送達された用手ＣＰＲ圧迫を記述するデータ、患者に実施された用手換気を記述するデータ、電気治療ショック付近で（例えば、その前後１０秒以内に）記録された患者の心臓活動を記述するＥＣＧスナップショット、除細動器／モニタ３０２Ｂの動作のモード（自動又は手動）、電気治療ショック送達とは独立して記録された患者のＥＣＧ情報、患者のカプノグラフィ情報、及び治療パッド取り外しイベントを含む。ＥＣＧ情報及び／又はＥＣＧスナップショットは、除細動器／モニタ３０２Ｂに関連付けられている１２リードＥＣＧレポートを生成するために使用されてよい。したがって、患者記録（例えば、ケースファイル３０４Ｂを含む）は、１２リードＥＣＧレポートを含んでよい。血圧測定は、収縮期及び／又は拡張期とすることができる。治療パッドに関する情報は、治療パッドの作り、モデル、タイプ、及びインピーダンスを含むことができる。電気治療ショックを記述する情報は、送達されたジュール数及び遭遇したインピーダンスを含むことができる。用手圧迫を記述するデータは、平均深さ及び平均回数を含むことができる。用手換気を記述するデータは、平均一回換気量及び平均換気回数を含むことができる。様々な実施形態において、デバイス３０２Ｂは、データを取得するとケースファイル３０４Ｂを継続的にアップデートし、これは、患者エンカウンタデータソース統合サービスを実行しているサーバにさらにアップロードされる。

【0085】

図３Ｃを引き続き参照すると、ケースファイル３０４Ｃは、人工呼吸器３０２Ｃによって記録されたケースデータを格納し、これは、患者エンカウンタの過程を通して継続的及び／又は定期的にアップデートされてよい。ケースファイル３０４Ｃは、人工呼吸器３０２Ｃの識別子、人工呼吸器３０２Ｃによって検出されたイベント及びパラメータ、これらのイベント及びパラメータに関する詳細、並びに各イベント又はパラメータが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図３Ｃに示されているように、人工呼吸器３０２Ｃが検出してケースファイル３０４Ｃに記録するイベント及びパラメータのタイプは、開始／電源オンイベント、終了／電源オフイベント、人工呼吸器設定の構成、患者のパルスオキシメトリ（瞬間的及び傾向）、患者の呼気終末二酸化炭素読み取り値（瞬間的及び傾向）、及び患者のカプノグラフィ情報を含む。換気設定は、一回換気量、レート、最大吸気圧、最大呼気終末陽圧、及び吸入中酸素濃度を含むことができる。様々な実施形態において、デバイス３０２Ｃは、データを取得するとケースファイル３０４Ｃを継続的にアップデートし、これは、患者エンカウンタデータソース統合サービスを実行するサーバにさらにアップロードされる。

【0086】

ケースファイル３０４Ｄは、ＡＥＤ３０２Ｄによって記録されたケースデータを格納する。ケースファイル３０４Ｄは、ＡＥＤ３０２Ｄの識別子、ＡＥＤ３０２Ｄによって検出されたイベント及びパラメータ、これらのイベント及びパラメータに関する詳細、並びに各イベント又はパラメータが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図３Ｃに示されているように、ＡＥＤ３０２Ｄが検出してケースファイル３０４Ｄに記録するイベント及びパラメータのタイプは、開始／電源オンイベント、終了／電源オフイベント、治療パッド取り付け及び取り外しイベント、患者に取り付けられた治療パッドに関する情報、患者に送達された電気治療ショックを記述する情報を含む。電気治療ショックを記述する情報は、送達されたジュール数及び遭遇したインピーダンスを含むことができる。

【0087】

組み合わせで、ケースファイル３０４Ａ～３０４Ｄは、患者エンカウンタ中に患者１１６が受けたケアの時系列。ケースファイル３０４Ａ～３０４Ｄに格納されたケースデータは、単に図示の目的で提供されており、本明細書において説明された例は、このタイプ又は任意の他のタイプのケースデータに限定されない。

【0088】

いくつかの例において、ケースファイル３０４Ａ～３０４Ｄのそれぞれは、パースされて、ケースデータストア（例えば、図１のケースデータストア１３２）にインポートされる。このパース及びインポートのプロセスは、様々なケースファイル３０４Ａ～３０４Ｄ間のフォーマット及びコンテンツにおける多くの差異を考慮し、ケースファイルに含まれているケースデータ、及び／又はケースファイルそれら自体のコピーをケースデータストアに格納する。図３Ｃに示されているように、ケースファイル及び／又はケースデータは、任意の様々なデータタイプ、モデル、及びフォーマットに従って格納することができる。また、図３Ｃに示されているように、ケースデータストアは、ケースファイル及び様々な他の医療デバイス３０６からのデータを格納することができる。ケースファイル及びデータのこの標準化された一元化ソースは、多くの利点を提供し、ケースデータストアの包含は、単一の患者エンカウンタから発生したケースファイル及びデータ等の特定の共通の関心を伴うケースファイル及びデータを効率的に検索し見つけるためのメカニズムの必要性も生じさせる。

【0089】

図３Ｄは、いくつかの例の関連付け、統合／集約、及びレポートアクティビティを示すデータフロー図である。図３Ｄに示されているように、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）は、特定の患者エンカウンタ中に生成されたケースデータストア３１１内に格納されたケースファイル及びデータを検索して見つけるために関連付け情報を利用するように構成することができる。ケースデータストア３１１は、図１のケースデータストア１３２の１つの非限定的な例である。図３Ｄに示されているように、ケースデータストア３１１は、ケースデータストア３１１にインポートされ格納されたケースファイルをリストするテーブル３０７を含む。このテーブルは、ケースファイルを発生させた医療デバイスの識別子、医療デバイスケースファイルでのタイムスタンプ情報、ケースファイルの一意の識別子、及びバイナリラージオブジェクト（ｂｌｏｂ）として格納されたケースファイルのコピーを格納する。ケースデータストア３１１は、容易で迅速な標準化されたアクセスのために、ケースファイルからパースされたケースデータを格納するさらなるテーブルも含む。テーブル３０９は、１つの例に係る、自動化胸骨圧迫器によって使用された構成設定を格納するようなテーブルの１つの例を示している。他のテーブルレイアウト及び総合的なデータベーススキーマを本明細書に開示されている様々な例とともに使用することができ、これはケースデータを編成する特定のアプローチに限定されない。

【0090】

図３Ｄに示されているように、患者エンカウンタデータソース統合サービスは、関連付け情報３０１を受信してパースするように構成されている。これらの例において、患者エンカウンタデータソース統合サービスは、パースされた関連付け情報（例えば、デバイス識別子及びタイムスタンプ）を使用して、ケースデータストア１３２内で、関連付け情報に対応するとともにそれによって識別される患者エンカウンタに関与した医療デバイスを検索して識別するようにさらに構成することができる。患者エンカウンタデータソース統合サービスは、識別された医療デバイスによって生成されたケースファイルを互いに関連付け、様々な関連付けられたケースファイルからのケースデータ及び／又はケースファイルそれら自体のコピーを含む統合データソースエンカウンタ構造体３０８を生成するようにさらに構成することができる。患者エンカウンタデータソース統合サービス１３０の動作の詳細は以下でさらに提供されるが、図３Ｄに示されているように、いくつかの例において生成された統合データソースエンカウンタ構造体３０８は、各関連付けられたケースファイルからのケースデータの少なくとも一部を含む。この統合データソースエンカウンタ構造体を使用して、ヘルスケア提供者１１８Ｃ等のヘルスケア提供者は、例えば、患者１１６が居合わせた人物３００によって処置されている間に実施されたショック、患者１１６がシーンでヘルスケア提供者１１８Ａによって処置されている間に実施されたショック、及び病院に向かう途中で患者１１６に与えられた他の処置をレビューすることができる。

【0091】

図３Ａ～図３Ｄは、概して、モバイルデバイスを使用して、複数の医療デバイスを識別し、これらの複数のデバイスから、統合ケースデータレポートにして組み合わせることができるデータを受信するいくつかの例を示している。しかしながら、他の事前に生成されたデータ記録及び／又はデータレポートが、患者１１６とともにシーンに存在する任意のモバイルコンピューティングデバイスによって、及び、病院にいるヘルスケアプロフェッショナルによって使用されるもの等の任意のリモートモバイルコンピューティングデバイスによって受信されてよいことが理解されるべきである。そのような事前に生成されたデータ記録の例として、除細動器／モニタ３０２Ｂによって生成されてよい１２リードＥＣＧレポートが挙げられる。一般に、１２リードＥＣＧレポートは、患者の身体上に配置されている１２のリードからの電気的測定に基づく患者の心臓内の電気伝導のピクチャを提供する。１２のリードのうちの６つは、患者の腕及び／又は脚上に配置されるので、「四肢リード」とみなされる。他の６のリードは、胴体（前胸部）上に配置されるので、「前胸部リード」とみなされる。

【0092】

１２リードＥＣＧレポートは、患者上の１２のリードのそれぞれから収集された電気波形を含んでよい。いくつかの例において、１２リードＥＣＧレポートは、ユーザに高速かつ簡便な分析を提供するために、波形の１又は複数の解釈も含む。これらの１又は複数の解釈は、異なる波形の中からのパターン認識を伴ってよく、これは、波形の特定の部分が或る形態の心損傷を示唆する異常パターンを有する場合、アラート又はインジケータを生成してよい。いくつかの例において、１２リードＥＣＧレポートは、上で説明したように、統合ケースデータレポートの一部である。

【0093】

図１９～図２１は、救急車１９０２等の特定のロケーションにおいて使用される医療デバイスとリモートコンピューティングデバイス１９１４との間での患者データの通信を伴う例示的な医療環境を示している。データ転送は、本明細書においてより詳細に議論されるように、ローカルコンピューティングデバイス１９０６及びリモートコンピューティングデバイス１９１４の両方にインストールされたソフトウェアアプリケーションによって容易にされてよい。ソフトウェアアプリケーションのための例示的なユーザインタフェーススクリーンが、図２２～図２４を参照しながら議論される。

【0094】

図１９は、１又は複数の医療デバイスとローカルコンピューティングデバイス１９０６との間の患者データの無線ローカルエリアネットワーク（例えば、ＷＩＦＩ）通信、及び、リモートコンピューティングデバイス１９１４とのデータ通信も伴う１つの例示的な医療環境１９００を示している。任意の数のリモートコンピューティングデバイス１９１４が、ネットワーク１９１２を介して医療関連データを受信してよい。図示された例において、ｎのリモートコンピューティングデバイス（１９１４－１～１９１４－ｎとラベル付けされている）が識別され、それぞれリモートデータ収集アプリケーション１９１６－１～１９１６－ｎを有している。患者が位置し得る現場に戻ると、ローカルデータ収集アプリケーション１９０８を有するローカルコンピューティングデバイス１９０６は、１又は複数のローカル医療デバイスからデータを収集するために使用される。図示された例において、除細動器／モニタ１９０４は、患者の生理学的状態をモニタするようにセットアップされている。モニタリングは、１２リード測定からＥＣＧデータを収集することを含む、様々なタイプのデータの収集を伴うことができる。適切な除細動器／モニタの一例は、ゾールメディカルコーポレーションによって提供されるＸ Ｓｅｒｉｅｓ（登録商標）除細動器／モニタであるが、他の好適な除細動器／モニタデバイスを本開示に従って使用してもよい。

【0095】

ローカルコンピューティングデバイス１９０６又はリモートコンピューティングデバイス１９１４のうちの任意のものは、タブレット、スマートフォン、ウェアラブルデバイス、及び／又は他のモバイルコンピューティングデバイス、及び／又は、本明細書において説明されたアプリケーションを実行するとともに近距離若しくは長距離無線ネットワークを介して他の通信デバイスと無線で通信することができるモバイルデバイスの組み合わせを含むことができる。ローカルコンピューティングデバイス及び／又はリモートコンピューティングデバイス１９１４は、モバイルコンピューティングデバイス１０４Ａ～１０４Ｃに関して上で説明したものと同じコンポーネントを有してよい。いくつかの例において、ローカルコンピューティングデバイス１９０６は、救急車１９０２内で又は患者のいる任意のロケーションで患者を支援する救急隊員又は他の同様の第一対応者によって使用されるタブレット又はスマートフォンを表す。いくつかの例において、リモートコンピューティングデバイス１９１４は、病院又は診療所等のリモートロケーションで医療プロフェッショナルによって使用される、テーブル、スマートフォン、又はＰＣを表す。

【0096】

除細動器／モニタ１９０４によって収集されたデータは、ローカルユーザ及びリモートユーザの両方に有意義な情報を提供するために、記録又はレポートとしてフォーマット化されてよい。いくつかの例において、除細動器／モニタ１９０４は、１２リード装置から収集された波形及び／又は波形の分析を提供するために、１２リードＥＣＧレポートを生成する。図示された医療環境１９００において、このレポートは、無線通信プロトコルを介してローカル無線ルータ１９１０に送信される。ローカルデータ収集ａｐｐ１９０８がインストールされた任意の他のローカルコンピューティングデバイスは、１２リードＥＣＧレポートを受信するためにルータ１９１０と無線で通信してもよい。いくつかの例において、１２リードＥＣＧレポートは、医療データの機密性を確実にするために暗号化され、モバイルコンピューティングデバイス１９０６においてローカルデータ収集ａｐｐ１９０８又はスタンドアロン復号ソフトウェアを使用して復号される。１２リードＥＣＧレポートは、受信されると、ローカルコンピューティングデバイス１９０６上で閲覧されてよい。いくつかの例において、ローカルデータ収集ａｐｐ１９０８は、ネットワーク１９１２を介した１又は複数のリモートコンピューティングデバイス１９１４への１２リードＥＣＧレポートの転送も容易にする。例えば、１２リードＥＣＧレポートは、まず、無線通信プロトコルを介してルータ１９１０に又はローカルコンピューティングデバイス１９０６の近傍にある任意の他のルータに送信され、次に、ルータ１９１０からネットワーク１９１２を介してリモートコンピューティングデバイス１９１４に送信されてよい。

【0097】

いくつかの例において、ルータ１９１０は、認可されたデバイスのみがルータ１９１０と接続し、除細動器／モニタ１９０４によって生成されたデータレポートを受信することができることを確実にするために、パスワード保護される。例えば、ローカルコンピューティングデバイス１９０６がデータレポートを受信するためにルータ１９１０と通信するには、まず、ルータ１９０４との無線接続を確立するように必須のパスワードを提供しなければならない。パスワードは、一度入力されると、ローカルコンピューティングデバイス１９０６がルータ１９１０の範囲内にある場合にルータ１９１０と接続を確立するために再び入力される必要がないように、将来のエンゲージメントのために記憶されてよい。

【0098】

上での説明は、１２リードＥＣＧレポートの取得及び送信を主に議論したが、任意の測定された患者パラメータを、除細動器／モニタ１９０４によって取得し、ローカルコンピューティングデバイス１９０６に送信することができることが理解されるべきである。さらに、いくつかの例において、任意の他の測定された患者パラメータを、１又は複数のレポート又は記録に編成することができる。他の測定された患者パラメータのいくつかの例としては、レスピレーション／呼吸数、心拍／脈拍数、血液酸素（ＳｐＯ_２）飽和度、メトヘモグロビン（ＳｐＭＥＴ）飽和度、カルボキシヘモグロビン（ＳｐＣＯ）飽和度、呼気終末ＣＯ_２（ＥＴＣＯ_２）値、吸入中二酸化炭素濃度（ＦｉＣＯ_２）値、温度、及び観血又は非観血血圧が挙げられる。送信データは、測定されたデータに基づく特定の関連イベントの波形スナップショットを含んでよい。

【0099】

いくつかの例において、除細動器／モニタ１９０４によって生成されたデータレポート又は記録は、生成されると、ローカルコンピューティングデバイス１９０６に自動的に送信される。換言すれば、そのデータを送信する前に、それについて要求が受信されるのを待つことはない。したがって、ローカルデータ収集ａｐｐ１９０８がインストールされた任意のローカルコンピューティングデバイスは、ユーザに要求される任意のインタラクションを伴わずに、除細動器／モニタ１９０４によって生成された任意の送信されたデータレポート又は記録を受信する。いくつかの例において、ユーザは、ローカルデータ収集ａｐｐ１９０８を使用して、データレポート又は記録の受信をオプトアウトしてよい。

【0100】

いくつかの例において、ネットワーク１９１２は、ルータ１９１０及びリモートコンピューティングデバイス１９１４がそれを通してデータを送信、受信、及び／又は交換することができる１又は複数の通信ネットワークを含むことができる。様々な実装において、ネットワーク１９１２は、セルラ通信ネットワーク及び／又はコンピュータネットワークを含むことができる。いくつかの例において、ネットワーク１９１２は、無線ネットワーク及び／又は有線接続を含み、これをサポートする。例えば、これらの例において、ネットワーク１９１２は、とりわけ、ＧＳＭ（登録商標）、ＣＭＤＡ、ＵＳＢ、ＢＬＵＥＴＯＯＴＨ（登録商標）、ＣＡＮ、ＺｉｇＢｅｅ（登録商標）、無線イーサネット、イーサネット（登録商標）、及びＴＣＰ／ＩＰ等の１又は複数のネットワーキング規格をサポートしてよい。ネットワーク１９１２は、ローカルエリアネットワーク等のプライベートネットワーク及びインターネット等のパブリックネットワークの両方を含んでよい。いくつかの例において、ネットワーク１９１２は、１つのエンドポイントから別のエンドポイントへのパケットのルーティングに関与する１又は複数の中間デバイスを含んでよいことに留意すべきである。しかしながら、他の例において、ネットワーク１９１２は、それぞれ他方と直接ネットワーク接続している２つのみのエンドポイントを伴うことができる。いくつかの例において、ネットワーク１９１２は、ルータ１９１０から１又は複数のリモートコンピューティングデバイス１９１４に転送される医療データ、記録、又はレポートのための中間チェックポイントとして動作してよい１又は複数のサーバデバイスを含む。例えば、特定の患者に関係するＥＣＧ医療レポートは、セキュアドメインにおいてホストされているサーバによって受信されてよい。サーバは、受信された医療レポートを、患者に関して以前に格納された他のデータを含む所与の患者のためのより大きな医療記録の一部として格納してよい。サーバは、受信されたＥＣＧ医療レポート又はより大きな医療記録のいずれかを、１又は複数のリモートコンピューティングデバイス１９１４の任意のものに渡してよい。

【0101】

いくつかの例において、リモートコンピューティングデバイス１９１４は、ネットワーク１９１２を介して医療データ、記録、及び／又はレポートを受信するためにリモートデータ収集ａｐｐ１９１６を含む。リモートデータ収集ａｐｐ１９１６は、ローカルデータ収集ａｐｐ１９０８に関して上で説明したものと同じ機能の多くを含んでよい。例えば、リモートデータ収集ａｐｐ１９１６は、除細動器／モニタ１９０４から測定された医療データを、ユーザに要求されるインタラクションを最小限に留めて又はそれ無しにユーザに表示することができるレポート又は記録として受信してよい。いくつかの例において、リモートデータ収集ａｐｐ１９１６は、新たなデータレポートが受信されたときはいつでも、ユーザにアラート又は通知を提供してよい。アラートは、データレポートの決定された特性に応じて変化してよい。例えば、新たな１２リードＥＣＧデータレポートが受信されたとき、アラートは、ユーザによる即時の注意を要求する波形のうちの１又は複数において検出されたトラブル発生パターンを示すために、増加した音量又は異なるトーンを有してよい。トラブル発生パターンは、検出された波形を、或る形態の心損傷又は異常を表すことが知られている予め定められた波形と比較する、１又は複数のパターン検出アルゴリズムを使用して検出されてよい。

【0102】

いくつかの例において、リモートデータ収集ａｐｐ１９１６は、１又は複数の異なる患者に関する複数のデータレポートの格納を容易にし、ユーザが格納されたデータレポートのうちの任意のものにアクセスすることを可能にする。データレポートのうちの１又は複数は、選択されると、リモートコンピューティングデバイス１９１４のうちの任意のものに関連付けられているディスプレイ上に示されてよい。例えば、１２リードＥＣＧデータレポートは、定期的に生成され、作成の時間に基づいてタイムスタンプが付与されてよい。これらのレポートのそれぞれは、リモートデータ収集ａｐｐ１９１６によって収集され、ユーザが閲覧のために特定の１２リードＥＣＧデータレポートを選択するためにリスト化されてよい。リスト化は、１２リードＥＣＧデータレポートのそれぞれに関連付けられているタイムスタンプに基づいてソート又は編成されてよい。

【0103】

いくつかの例において、除細動器／モニタ１９０４は、１又は複数の１２リードＥＣＧレポートを含むケースファイル３０４Ｂ等のケースファイルを生成する。フルケースファイルは、次にローカルデータ収集ａｐｐ１９０８によって受信されて、最終的にリモートデータ収集ａｐｐ１９１６に送信されてよい。いくつかの例において、除細動器／モニタ１９０４によって生成された１又は複数の１２リードＥＣＧデータレポートは、例えば、図５を参照しながら説明されたような統合データソースエンカウンタ構造体の一部である。

【0104】

図２０は、１又は複数の医療デバイスとローカルコンピューティングデバイス１９０６との間の患者データのローカルパーソナルエリアネットワーク（例えば、ＢＬＵＥＴＯＯＴＨネットワーク）通信、及び、リモートコンピューティングデバイス１９１４とのデータ通信も伴う別の例示的な医療環境２０００を示している。ローカルデータ収集アプリケーション１９０８を有するローカルコンピューティングデバイス１９０６は、除細動器／モニタ１９０４等の１又は複数のローカル医療デバイスからデータを収集するために使用される。

【0105】

医療環境２０００は、図１９を参照しながら説明された医療環境１９００と類似しているが、１つの相違点は、医療データレポートが除細動器／モニタ１９０４とローカルコンピューティングデバイス１９０６との間で及びローカルコンピューティングデバイス１９０６とリモートコンピューティングデバイス１９１４との間で転送される方法にある。医療環境２０００において、除細動器／モニタ１９０４によって測定／生成された医療データ、レポート、及び／又は記録は、セキュアパーソナルエリアネットワーク接続を介してローカルコンピューティングデバイス１９０６に転送される。いくつかの例において、除細動器／モニタ１９０４は、１２リード装置から収集された波形及び／又は波形の分析を提供するために、１２リードＥＣＧレポートを生成する。ローカルデータ収集ａｐｐ１９０８がインストールされた任意の他のローカルコンピューティングデバイスが、１２リードＥＣＧレポートを受信するためにパーソナルエリアネットワークを介して無線で通信してもよい。いくつかの例において、除細動器／モニタ１９０４によって生成されたデータレポート又は記録は、生成されると、ローカルコンピューティングデバイス１９０６に自動的に送信される。換言すれば、そのデータを送信する前に、それについて要求が受信されるのを待つことはない。いくつかの例において、１２リードＥＣＧレポートは、医療データの機密性を確実にするために暗号化され、ローカルコンピューティングデバイス１９０６においてローカルデータ収集ａｐｐ１９０８又はスタンドアロン復号ソフトウェアを使用して復号される。１２リードＥＣＧレポートは、受信されると、ローカルコンピューティングデバイス１９０６上で閲覧されてよい。いくつかの例において、まず、ローカルコンピューティングデバイス１９０６と除細動器／モニタ１９０４との間のペアリングプロセスが、パーソナルエリアネットワーク接続を確立するために実行されなければならない。このペアリングプロセスは、除細動器／モニタ１９０４上でローカルコンピューティングデバイス１９０６との接続を手動で承諾することを伴ってよい。

【0106】

いくつかの例において、ローカルデータ収集ａｐｐ１９０８は、ネットワーク１９１２を介した１又は複数のリモートコンピューティングデバイス１９１４への１２リードＥＣＧレポートの転送も容易にする。このデータ転送は、ローカルコンピューティングデバイス１９０６とネットワーク１９１２との間のセルラ通信等の長距離無線通信を使用して発生してよい。

【0107】

図２１は、ネットワーク２１０２を介した１又は複数の医療デバイスとリモートコンピューティングデバイス１９１４との間の直接通信を伴う別の例示的な医療環境２１００を示している。例示的な医療環境１９００及び２０００と異なり、医療環境２１００は、除細動器／モニタ１９０４によって測定／生成された医療データ、記録、又はレポートの転送において、除細動器／モニタ１９０４に対してローカルなコンピューティングデバイスを伴わない。

【0108】

いくつかの例において、除細動器／モニタ１９０４は、ネットワーク２１０２を介してリモートコンピューティングデバイス１９１４に医療データを転送するために、近距離及び長距離通信のうちの一方又は両方を使用する。例示的な狭域通信は、ＢＬＵＥＴＯＯＴＨ又はＷＩＦＩを含み、例示的な長距離技術は、セルラ通信を含む。

【0109】

いくつかの例において、ネットワーク２１０２は、ネットワーク１９１２に関して上で説明したものと同じ特徴を共有する。図示された例において、ネットワーク２１０２は、少なくとも、第１のサーバ２１０４及び第２のサーバ２１０６を含む。いくつかの例において、第１のサーバ２１０４は、除細動器／モニタ１９０４から医療データ、記録、及び／又はレポートを受信し、データを収集して編成するための或る種のゲートウェイを提供するように構成されている。いくつかの例において、第１のサーバ２１０４は、セキュアネットワーク上でホストされる。第１のサーバ２１０４は、受信された医療データ、記録、及び／又はレポートを第２のサーバ２１０６に渡してよく、第２のサーバ２１０６は、受信されたデータ、記録、及び／又はレポートをリモートコンピューティングデバイス１９１４に広める。いくつかの例において、第１のサーバ２１０４は、異なる病院ネットワークによって操作される複数の異なる医療デバイスから医療データを受信するように構成されている一元化データサーバであってよく、第２のサーバ２１０６は、特定の病院ネットワーク上でホストされ、受信された医療データ、記録、及び／又はレポートを特定の病院ネットワークの一部であるリモートコンピューティングデバイス１９１４に送信するように設計されたサーバであってよい。

【0110】

いくつかの例において、第１のサーバ２１０４は、受信された医療データ、記録、及び／又はレポートを、第１のサーバ２１０４内に格納された電子メール配信リストに送信する。配信リストは、特定の除細動器／モニタ１９０４に関連付けられているデータを受信することになる特定の電子メールアドレスを追加又は削除するようにアップデート及び修正されてよい。いくつかの例において、配信リスト内の個々の電子メールアドレスは、特定のタイプのデータレポートのみを受信する（１２リードＥＣＧレポートのみを受信する等）又は特定の時間フレーム中に生成されたデータレポートのみを受信するように構成されてよい。いくつかの例において、異なる配信リストは、１又は複数の関連付けられたアカウントコードを有するように生成されてよい。アカウントコードのそれぞれは、１又は複数の除細動器デバイスに又は特定の病院ネットワークに関係付けられてよい。

【0111】

上で説明した例示的な医療環境において、１２リードＥＣＧレポート等の医療レポートは、除細動器／モニタ１９０４によって生成される。しかしながら、いくつかの例において、医療データは、除細動器／モニタ１９０４によって収集され、ローカルコンピューティングデバイス１９０６に転送され、ローカルコンピューティングデバイス１９０６は、受信されたデータに基づいて医療レポートを生成する。医療レポートは、ローカルデータ収集ａｐｐ１９０８を使用して生成されてよい。いくつかの他の例において、医療レポートは、医療データを除細動器／モニタ１９０４から直接又はローカルコンピューティングデバイス１９０６からのいずれかで受信した後、１又は複数のリモートコンピューティングデバイス１９１４のうちの任意のものによって生成される。医療レポートは、リモートデータ収集ａｐｐ１９１６を使用して生成されてよい。

【0112】

図２２は、ローカルデータ収集ａｐｐ１９０８の一部である例示的なユーザインタフェーススクリーン２２００を示している。ユーザインタフェーススクリーン２２００は、任意のタイプのディスプレイデバイス上でユーザに提示されてよく、ユーザが例えばタッチインタフェースを介して除細動器／モニタ１９０４から収集されているデータとインタラクトすることを可能にする。さらに、ユーザインタフェーススクリーン２２００は、除細動器／モニタ１９０４から収集されたＥＣＧ記録等のデータ記録を閲覧するための例示的なインタフェースを提示する。ユーザインタフェーススクリーン２２００上の様々な領域及び／又はグラフィカルオブジェクトの相対的なサイズ及び配置は、特定の図示された例とは異なってよいことが理解されるべきである。いくつかの例において、ユーザインタフェーススクリーン２２００は、新たに取得されたデータレポートを即時に提示する目的で専用インタフェースを提供する。データレポートは、受信されるとスクリーン上に現れ、さらに多くのレポートが受信されると、リスト化された順番で現れる。いくつかの例において、受信されたデータレポートのリストは、スクロール、ソート、又はフィルタすることができる。

【0113】

ユーザインタフェーススクリーン２２００は、データをそこから受信している所与の医療デバイスに関する情報を表示する。例えば、領域２２０２は、除細動器／モニタ１９０４等の所与の医療デバイスに関する名前、シリアルナンバ、及び／又はユニットＩＤのような詳細を含んでよい。ユーザインタフェーススクリーン２２００は、いくつかの例において、ローカルコンピューティングデバイス１９０６の近傍にある異なる医療デバイスを切り替えるためにタブを含んでよい。したがって、領域２２０２は、データが表示されている現在の医療デバイスに関する記述的詳細を含んでよい。いくつかの例において、ステータスインジケータ２２０４は、領域２２０２において示されている医療デバイスとの接続の確立が成功しているか否かを示すために提供される。

【0114】

いくつかの例において、ユーザインタフェーススクリーン２２００は、医療デバイスからのさらなるデータについてのいかなるポーリングも停止するために使用されるボタン２２０６を含む。例えば、所与の医療デバイスとの接続を確立するときのデフォルト設定は、医療デバイスからの新たなデータについて継続的にチェックし、所与の医療デバイスから送信されている任意の新たなデータを受信するようになっている。ボタン２２０６は、本質的には、ユーザが、所与の医療デバイスから任意のさらなる医療データ、記録、又はレポートを受信することをオプトアウトすることを可能にする。

【0115】

いくつかの例において、ユーザインタフェーススクリーン２２００は、所与の医療デバイスから受信されたデータレポート２２０８を含む。いくつかの例において、データレポートのリストは、それらが受信されたときからの時系列で提供されてよい。いくつかの例において、データレポートのリストは、レポート内の時間、名前、又はユーザ定義特徴によってソートされてよい。図示された例において見られるように、表示されたデータレポートは、レポートが生成された日付及び時間、レポートを生成した医療デバイスに関連付けられているシリアルナンバ、及び医療デバイスのユニットＩＤ等のいくつかの記述的詳細を含んでよい。いくつかの例において、ユーザは、さらに詳細にレポートを閲覧するために、表示されたデータレポート２２０８をクリック又はタッチしてよい。

【0116】

いくつかの例において、所与の医療デバイスによって生成されたアーカイブされたデータレポートにアクセスするために、履歴ボタン２２１０が設けられてよい。アーカイブされたレポートは、患者によって又はデータ収集の所与の期間によって編成されてよい。例えば、１２リードＥＣＧ医療レポートは、それらが収集された日又は週によって編成されてよい。

【0117】

図２３Ａは、リモートデータ収集ａｐｐ１９１６の一部である例示的なユーザインタフェーススクリーン２３００を示している。ユーザインタフェーススクリーン２３００は、任意のタイプのディスプレイデバイス上でユーザに提示されてよく、ユーザが例えばタッチインタフェースを介して除細動器／モニタ１９０４から収集されているデータとインタラクトすることを可能にする。さらに、ユーザインタフェーススクリーン２３００は、除細動器／モニタ１９０４から収集された１２リードＥＣＧ記録等のデータ記録を閲覧するための例示的なインタフェースを提示する。ユーザインタフェーススクリーン２３００上の様々な領域及び／又はグラフィカルオブジェクトの相対的なサイズ及び配置は、特定の図示された例とは異なってよいことが理解されるべきである。

【0118】

ユーザインタフェーススクリーン２３００は、いくつかの例によれば、所与の医療デバイスから収集された複数の受信されたデータレポートにアクセスするためのコントロール２３０２Ａ～２３０２Ｅを含む。５つの１２リードＥＣＧデータレポートが示されているが、任意の数のデータレポートをリスト化してスクロールすることができる。本明細書における議論のしやすさのために、データレポートにアクセスするためのコントロール２３０２Ａ～２３０２Ｅのいずれも、より一般的なラベル２３０２で識別され得る。リスト化されたデータレポートのそれぞれは、レポートが生成された日付及び時間、レポートを生成した医療デバイスに関連付けられているシリアルナンバ、及び医療デバイスのユニットＩＤ等のいくつかの記述的詳細を含んでよい。いくつかの例において、コントロール２３０２は、それらの対応するデータレポートを受信した時系列でリスト化されてよい。いくつかの例において、コントロール２３０２は、ソートボタン２３０４をアクティベートすることによって、それらの対応するレポート内の時間、名前、又はユーザ定義特徴によってソート及び／又はフィルタされてよい。いくつかの他の例において、コントロール２３０２は、それらの対応するレポートを生成した医療デバイスに基づいて、所与の患者又は任意の他のユーザ定義基準に基づいて、ソート及び／又はフィルタされてよい。

【0119】

いくつかの例において、データレポートは、任意の数の異なる医療デバイスから到来する。したがって、レポートは、これらを生成したデバイスに応じて異なるタイプのデータを含むことができる。例えば、データレポートの一部は、除細動器／モニタ（除細動器／モニタ３０２Ｂ等）からのものであってよく、一部のデータレポートは、人工呼吸器（人工呼吸器３０２Ｃ等）からのものであってよく、一部のデータレポートは、自動化胸骨圧迫器（自動化胸骨圧迫器３０２Ａ等）からのものであってよい。図２３Ｂは、リモートデータ収集ａｐｐ１９１６の一部である別の例示的なユーザインタフェーススクリーン２３０１を示している。ユーザインタフェーススクリーン２３０１は、同じ患者エンカウンタに関連付けられている異なる医療デバイスから収集されたデータレポートを閲覧するためのコントロール２３０３Ａ～２３０３Ｅを伴う例示的なインタフェースを提示する。異なる医療デバイスから受信されたそのようなデータレポートは、（図２３Ｂに示されているように）別個にリスト化されてよく、又は、（例えば、図３Ｄにおいて説明したような患者エンカウンタデータソース統合サービス１３０を使用して）統合データソースエンカウンタ構造体にして組み合わされてよく、統合データソースエンカウンタ構造体のうちの異なるものが、代わりにリスト化される。図示された例において、データレポートは、図３Ｂ及び図３Ｃを参照しながら説明したように、医療デバイス３０２Ａ～３０２Ｄから異なる時点で受信されている。

【0120】

図２４は、リモートデータ収集ａｐｐ１９１６の一部である別の例示的なユーザインタフェーススクリーン２４００を示している。ユーザインタフェーススクリーン２４００は、例えば、ユーザインタフェーススクリーン２３００から選択された後の、所与のデータレポート２３０２の例示的なビューを提供する。所与のデータレポート２３０２の選択により、レポートの詳細をユーザに示すためにビューが変化してよい。ユーザインタフェーススクリーン２４００の図示された例において、１２リードＥＣＧレポートが選択されており、レポートの詳細が示されている。

【0121】

いくつかの例において、ユーザインタフェーススクリーン２４００は、医療レポートに関連付けられている患者に関する様々な詳細を含む患者詳細領域２４０２を含む。例において見られるように、患者の詳細は、患者の名前、患者ＩＤ、年齢、及び性別を含んでよい。患者の心拍数、ＰＲ間隔、ＱＲＳ時間、ＱＴ／ＱＴｃ、及びＰ－Ｒ－Ｔ軸等の、医療デバイスから突き止められたさらなる医療詳細も提供されてよい。いくつかの例において、患者詳細領域２４０２は、患者とともにシーンにいるローカルデータ収集ａｐｐ１９０８のユーザから等、別のケア提供者から医療レポートに追加されたノートも含む。

【0122】

いくつかの例において、ユーザインタフェーススクリーン２４００は、１２リードＥＣＧ測定の様々なリードからの特定の波形を表示する。例えば、Ｖ１～Ｖ６、Ｉ、ＩＩ、ＩＩＩ、ａＶＲ、ａＶＬ、及びａＶＦリードのそれぞれから収集された波形が表示されてよい。データは、図２４に示されているようにランドスケープビューで提示されてよい。

【0123】

いくつかの例において、医療環境１９００、２０００又は２１００のうちの任意のものからのデバイスは、ＥＣＧ記録又は統合データソースエンカウンタ構造体等の医療データ記録を送信及び受信する様々なプロセスを実行するように構成されている。図２５は、例えば、医療デバイス（例えば、図１９の除細動器／モニタ１９０４）、１又は複数のローカルコンピューティングデバイス（例えば、図１９のローカルコンピューティングデバイス１９０６）、及び１又は複数のリモートコンピューティングデバイス（例えば、図１９のリモートコンピューティングデバイス１９１４）によって実行されるデータ記録送信プロセス２５００を示している。いくつかの例において、図２５における１又は複数のローカルコンピューティングデバイスに帰属する動作は、１又は複数のローカルコンピューティングデバイスによってホストされている１又は複数のローカルデータ収集ａｐｐ（例えば、図１９のローカルデータ収集ａｐｐ１９０８）によって実行される。

【0124】

データ記録送信プロセス２５００は、いくつかの例に従えば、医療デバイスを使用して患者からデータを収集する段階２５０２で開始する。データは、図１及び図１８を参照しながら説明したように、１又は複数の患者インタフェースデバイス（例えば、生理学センサ、ＥＣＧセンサ、ＳｐＯ２センサ、カプノグラフィセンサ、血圧センサ等）を介して収集されてよい。いくつかの例において、患者インタフェースデバイスは、患者の１２リードＥＣＧを収集するための１２リードＥＣＧセンサを含む。

【0125】

患者データを収集した後、医療デバイスは、１２リードＥＣＧレポート等の１又は複数のデータレポートを生成する（２５０４）。
１２リードＥＣＧレポートは、患者上の１２のリードのそれぞれから収集された電気波形を含んでよい。いくつかの例において、１２リードＥＣＧレポートは、ユーザに高速かつ簡便な分析を提供するために、波形の１又は複数の解釈も含む。これらの１又は複数の解釈は、異なる波形の中からのパターン認識を伴ってよく、これは、波形の特定の部分が或る形態の心損傷を示唆する異常パターンを有する場合、アラート又はインジケータを生成してよい。いくつかの例において、１又は複数のデータレポートは、１２リードＥＣＧデータを含む、ケースファイル３０４Ｂ等の、少なくとも１つのケースファイルを含む。ケースファイルは、統合データソースエンカウンタ構造体の１つのケースファイルであってよい。したがって、データレポートは、複数の医療デバイスから生成されて、図３Ｃ及び図３Ｄを参照しながら概ね議論したように、統合データソースエンカウンタ構造体を生成するように組み合わされてよい。

【0126】

医療デバイスは、１又は複数のデータレポート（１又は複数のケースファイル又は統合データソースエンカウンタ構造体に含まれてよい）を１又は複数のローカルコンピューティングデバイスに送信する（２５０６）。いくつかの例において、医療デバイスによって生成されたデータレポート又は記録は、生成されると、１又は複数のローカルコンピューティングデバイスに自動的に送信（プッシュ）される。換言すれば、そのデータを送信する前に、それについて要求（例えば、ポール）が受信されるのを待つことはない。したがって、例えば、ローカルデータ収集ａｐｐを介してデータを受信するように構成されている任意のローカルコンピューティングデバイスは、ユーザに要求される任意のインタラクションを伴わずに、医療デバイスによって生成された任意の送信されたデータレポート又は記録を自動的に受信する（２５０８）。いくつかの例において、ユーザは、ローカルデータ収集ａｐｐを使用してデータレポート又は記録を受信することをオプトアウトしてよい。例えば、ローカルデータ収集ａｐｐは、所与の医療デバイスからの又は任意の医療デバイスからの任意のさらなるデータレポートを自動的に受信することを停止するユーザからの入力を受信することができる。医療デバイスは、ＷＩＦＩ、ＢＬＵＥＴＯＯＴＨ、又はセルラ等の任意の既知の無線通信インタフェースを使用して１又は複数のデータレポートを送信してよい。いくつかの例において、受信された１又は複数のデータレポートは、ローカルコンピューティングデバイスによって復号される。

【0127】

１又は複数のローカルコンピューティングデバイスのうちの任意のものは、１又は複数の受信されたデータレポートへのアクセスを提供する（２５１０）ことができる。いくつかの例において、１又は複数の受信されたデータレポートへのアクセスは、１又は複数の統合データソースエンカウンタ構造体のコンテンツの閲覧を含む。このアクセスは、受信されたレポートのリストを、それらがそこから受信された医療デバイスとともに表示することを含んでよい。表示されたリストは、任意の受信されたデータレポートを用いて、それらが受信されときに、自動的にアップデートされてよい。レポートのリストは、受信された時間、レポートが生成された時間、レポートを送信した医療デバイス、又は医療レポートに存在する特定のパラメータによって等、様々な基準を使用してソートされてよい。いくつかの例によれば、データレポートのうちの少なくとも１つは、１２リードＥＣＧレポートである。ローカルコンピューティングデバイスを介して１又は複数の受信されたデータレポートを提供するためのユーザインタフェーススクリーンの一例が、図２２に示されている。

【0128】

また、ローカルコンピューティングデバイスは、１又は複数の受信されたデータレポートのうちの任意のものを１又は複数のリモートコンピューティングデバイスに送信する（２５１２）ようにも構成されている。このデータ送信は、医療環境１９００又は２０００に概ね示されているように任意の数の無線経路を介して発生してよい。いくつかの例において、１又は複数の受信されたデータレポートは、図１９からのネットワーク１９１２等のネットワークを介したセルラ通信を介して、ローカルコンピューティングデバイスによって直接送信される。いくつかの例において、１又は複数の受信されたデータレポートは、ローカルコンピューティングデバイスの範囲内にあるルータを介してネットワークを横断して送信される。使用される送信技術にかかわらず、１又は複数のリモートコンピューティングデバイスは、少なくとも１つの１２リードＥＣＧレポートを含んでよい１又は複数のデータレポートを受信する（２５１４）。

【0129】

１又は複数のリモートコンピューティングデバイスは、１又は複数のデータレポートへのアクセスを提供する（２５１６）ように構成されている。いくつかの例において、１又は複数の受信されたデータレポートへのアクセスは、１又は複数の統合データソースエンカウンタ構造体のコンテンツを閲覧することを含む。１又は複数のリモートコンピューティングデバイスは、受信されたレポートのリストを、それらがそこから受信された医療デバイス又はローカルコンピューティングデバイスとともに表示してよい。レポートのリストは、受信された時間、レポートが生成された時間、レポートを送信した医療デバイス、又は医療レポートに存在する特定のパラメータによって等、様々な基準を使用してソートされてよい。いくつかの例によって、データレポートのうちの少なくとも１つは、１２リードＥＣＧレポートである。リモートコンピューティングデバイスを介して１又は複数の受信されたデータレポートを提供するための例示的なユーザインタフェーススクリーンが、図２３及び図２４に示されている。

【0130】

図１に戻ると、いくつかの例において、ヘルスケア提供者１１８Ａ及び１１８Ｂは、例えば、モバイルコンピューティングデバイス１０４上で実行されているオペレーティングシステム及び／又は患者エンカウンタデバイス関連付けアプリケーション１５０に対して認証されていることによって、モバイルコンピューティングデバイス１０４にそれぞれ関連付けることができる。図１に示されているように、いくつかの例において、モバイルコンピューティングデバイス１０４は、医療デバイス１０２に通信可能に結合されるように構成されてよいが、本開示のいくつかの例において、モバイルコンピューティングデバイス１０４は、必ずしも医療デバイス１０２と直接通信する必要はなく、むしろ、モバイルコンピューティングデバイス１０４及び医療デバイス１０２は、ネットワーク１１２を通して別個にサーバ１０８と通信する。

【0131】

いくつかの例において、モバイルコンピューティングデバイス１０４Ａは、ｅＰＣＲ及び／又は他の記録及び／又は患者１１６の状態及び／又は患者１１６に適用された処置についてのノートを生成するためにヘルスケア提供者１１８Ａによって使用されるデバイスとしてよい。同様に、いくつかの例において、モバイルコンピューティングデバイス１０４Ｂは、容易で直感的な方式でコードの重要な情報のドキュメント化を可能にする、ゾールメディカルコーポレーションによって提供されるＲｅｓｃｕｅＮｅｔ（登録商標）ＣｏｄｅＷｒｉｔｅｒドキュメント化モバイルアプリケーション等の、患者１１６に適用された特定の処置手順（例えば、心停止コードの実行）をドキュメント化するイベントログを生成するためにヘルスケア提供者１１８Ａによって使用されるデバイスであってよい。図１において、ｅＰＣＲアプリケーション１２２及びイベントログアプリケーション１４０は、別個のモバイルコンピューティングデバイス１０４によってホストされているが、本明細書に開示されている例は、この構成に限定されない。例えば、いくつかの例において、単一のモバイルコンピューティングデバイス１０４は、ｅＰＣＲアプリケーション１２２及びイベントログアプリケーション１４０の両方をホストする。

【0132】

いくつかの例において、イベントログアプリケーション１４０は、イベントを容易、迅速、簡便、かつ正確に記録し、場合によっては緊急医療処置中に遭遇されたさらなるイベント詳細を特定するように調整されたユーザインタフェーススクリーンのセットを提供するように構成されている。これらのインタフェーススクリーンは、例えば、イベントログアプリケーション１４０を実行しているモバイルコンピューティングデバイス１０４のタッチスクリーンを介して提供することができる。

【0133】

より具体的には、いくつかの例において、イベントログアプリケーション１４０は、一般に緊急医療処置中に遭遇されるイベントでラベル付けされ且つそれに関連付けられているコントロールを含むスクリーンを提供するように構成されている。例えば、ＣＰＲ、エピネフリン（ＥＰＩ）、及び／又は電気治療ショックの実施等のイベントが、コードブルーの実行中に一般に遭遇され、コードブルーのドキュメント化に向けた例は、これらのイベントの記録に専用のコントロールを有する。これらのプロセスの多くは、特定のイベントの発生をドキュメント化する日付／タイムスタンプが付与されたエントリをイベントログ内に格納することで完結する。イベントログは、患者エンカウンタの過程中に患者に与えられた処置及び／又は発生したイベントをさらにドキュメント化する。

【0134】

いくつかの例において、イベントログアプリケーション１４０は、コントロールに関連付けられているプロセスを実行することによってコントロールを選択する入力に応答するようにさらに構成されている。例えば、いくつかの例において、ＣＰＲ、ＥＰＩ、及びショックの実施に関連付けられているコントロールは、コントロールに関連付けられているプロセスの実行を介してリセット及び／又は増加されるタイマ及び／又はカウンタを含む。さらに、これらのプロセスは、そのコントロールが最後に選択されてから閾値量の時間が経過した後で通知を提供することができる。例えば、イベントログアプリケーション１４０は、ＣＰＲ胸骨圧迫が開始してから２分が経過した後又はＣＰＲがポーズしてから１０秒が経過した後に、ＣＰＲコントロールを介して、通知（例えば、アイコンの点滅、色変化、テキストによる促し）を提供することができる。胸骨圧迫の、予め定められた期間後、通常は２分後のこの通知は、ＣＰＲの間隔が過ぎていること、及び、患者に電気治療（例えば、除細動ショック）又は１又は複数の陽圧換気呼吸を加えるための短いポーズが必要か否かを決定するために、ＥＣＧ分析の期間等の患者の処置における別のフェーズが要求され得ることをユーザにリマインドする。（例えば、ＥＣＧ分析及び／又は換気のための）このポーズを過ぎたら、次に、胸骨圧迫を即時再開すべきである。したがって、胸骨圧迫における１０秒のポーズ後の通知は、胸骨圧迫を再開すべきであることをユーザにリマインドするために適切なものであり得る。同様に、いくつかの例において、イベントログアプリケーション１４０は、ＥＰＩコントロールを介して、ＥＰＩが最後に実施されてから３分経過した後に通知を提供することができる。そのような通知は、ＥＰＩの後続の投与が実施されるべきであることをユーザにリマインドするために適切なものであり得る。これらの通知は、コントロールを点滅させること、強調させること、色変化させること、テキストによる促し、及び／又は別の視覚的インジケーションを提供することを含むことができる。又は、いくつかの場合において、可聴及び／又はハプティック通知が、モバイルコンピューティングデバイスによって提供されてよい。

【0135】

いくつかの例において、特定の状況における処置ドキュメント化をさらに容易にするために、イベントログアプリケーション１４０は、ヘルスケア提供者がイベントログアプリケーション１４０のドキュメント化モードを成人モード又は小児モードのいずれかに変更することを可能にするコントロールを提供するように構成されている。成人モードで動作している間、イベントログアプリケーション１４０は、成人を処置しているときに遭遇するイベントに関するイベントをマークするログエントリを容易にするために、特定のスクリーン及びコントロールの特徴を変える。例えば、成人に対してのみ利用可能なＣＰＲへのアプローチに関連付けられラベル付けされたコントロールは、イベントログアプリケーション１４０が成人モードで動作している間にのみ可視である。反対に、小児モードで動作している間、イベントログアプリケーション１４０は、小児を処置しているときに遭遇するイベントに関するイベントをマークするログエントリを容易にするために、特定のスクリーン及びコントロールの特徴を変える。例えば、小児に対してのみ利用可能なＣＰＲへのアプローチに関連付けられているコントロールは、イベントログアプリケーション１４０が小児モードで動作している間にのみ可視である。

【0136】

特定の例において、イベントログアプリケーション１４０は、患者の緊急処置の前、中、及び後に、様々な情報を表示するためのコントロールを伴って構成されている。例えば、いくつかの例において、関係する情報を取得するために適切な接続が形成されると、イベントログアプリケーション１４０は、患者情報スクリーンを介してヘルスケア提供者に患者識別情報を表示するように構成されている。さらに、少なくとも１つの例において、イベントログアプリケーション１４０は、ＣＰＲクオリティメトリック（例えば、ターゲット深さ内に入る胸骨圧迫のパーセンテージ、ターゲット回数内に入る圧迫のパーセンテージ、圧迫の平均深さ、圧迫の平均回数等の胸骨圧迫メトリック等）を、ユーザインタフェースのスクリーンを介してヘルスケア提供者に表示するように構成されている。さらに、いくつかの例において、イベントログアプリケーション１４０は、ＭＥＷＳファクタを受信し、ＭＥＷＳファクタに基づいて計算されたＭＥＷＳスコアを表示するためのコントロールを伴うスクリーンを提供するように構成されている。さらに、これらのスクリーンは、例えば、迅速な応答又はコードチームをモバイルコンピューティングデバイスのロケーションに呼び出すことによって、コントロールを選択する入力に応答するコントロールを含んでよい。

【0137】

ｅＰＣＲアプリケーション１２２は、ｅＰＣＲ生成に関するコンテンツを含む、視覚的コンテンツ、音声コンテンツ、ハプティックコンテンツ、及び／又はタクタイルコンテンツをレンダリングすることができる。こうして、ｅＰＣＲアプリケーション１２２は、入力を受信する又は出力を提供することができ、それにより、ユーザがモバイルコンピューティングデバイス１０４とインタラクトすることを可能にする。ｅＰＣＲアプリケーション１２２は、タッチスクリーン、音声認識、及びスキャナを含むがこれらに限定されない様々なメカニズムを介して、チャート化データを受信するように構成することができる。例えば、患者は、彼／彼女の名前を言うことがあり、ｅＰＣＲアプリケーション１２２は、患者名を捕捉して、それをチャート化データの一部として格納することができる。ｅＰＣＲアプリケーション１２２は、カメラ／スキャナを含むことができ、これを通して、患者の運転免許が取得／スキャンされてよく、名前、住所、年齢等の患者についての関係する情報をチャート化データとして格納することができる。ヘルスケア提供者１１８Ａは、ｅＰＣＲアプリケーション１２２を介して患者１１６を検査したときのデータ又は所見をディクテートしてよい。そのようなディクテーションは、いくつかの例によれば、チャート化データとして捕捉し保存することができる。特定の例において、ｅＰＣＲアプリケーション１２２は、図１８の入力デバイス４４４及び／又は出力デバイス４３０を利用する。

【0138】

いくつかの例において、モバイルコンピューティングデバイス１０４によって実施されるｅＰＣＲアプリケーション１２２は、タッチスクリーン及び／又はフラットパネルＰＣ又はいくつかの他のユーザインタフェースハードウェア並びにハードウェアを駆動するように構成されているソフトウェアスタックと相互運用することができる。ｅＰＣＲアプリケーション１２２の一部は、Ａｎｄｒｏｉｄ（登録商標）アプリケーション、Ａｐｐｌｅ（登録商標）アプリケーション、又は他のネイティブアプリケーションとしてモバイルコンピューティングデバイス１０４のメモリに格納し、ヘルスケア提供者１１８とインタラクトするようにプロセッサによって実行することができる。代替的に又は加えて、モバイルコンピューティングデバイス１０４のメモリは、１又は複数のウェブサーバから、ｅＰＣＲアプリケーション１２２の一部を受信してレンダリングするように構成されているブラウザ又はいくつかの他の実行環境を格納してよい。

【0139】

いくつかの例において、ｅＰＣＲアプリケーション１２２は、チャート化データストア１３４に格納されることになるチャート化データを生成することができる。例えば、ｅＰＣＲアプリケーション１２２は、本開示の例によれば、他のデバイスから収集された及び／又はそこに送信された情報の異なるサブセット及び／又は表示モードをユーザが選択することを可能にする、グラフィカルユーザインタフェースを含むことができる。１つの例において、ｅＰＣＲアプリケーション１２２は、特定の時間において患者に与えられた薬剤の投与量、ＣＰＲ圧迫深さ、又は他の処置パラメータをノートするために使用することができる。ｅＰＣＲアプリケーション１２２は、本開示の例によれば、患者についての経歴情報及び／又は人口統計学情報及び／又は履歴情報、例えば、患者の名前、識別番号、身長、体重、及び／又は病歴を記録するために使用することもできる。ｅＰＣＲアプリケーション１２２を介して受信されたチャート化データのタイプは、患者生理学パラメータ、ドキュメント化されたイベント等も含むことができる。チャート化データは、患者情報（例えば、名前、年齢、性別、体重、及び／又は他の識別情報及び／又は人口統計学情報）、医療イベント固有情報（例えば、要求されるサービスのタイプ、性質）、及び／又は臨床情報（例えば、患者評価、患者血圧）を含むことができるが、これらに限定されない。チャート化データは、ｅＰＣＲからのデータに加えて、患者ケア記録からの任意のデータ、内科医のチャートからのデータ、電子健康記録からのデータ、１又は複数の健康情報交換からのデータ、病院チャートからのデータをさらに含むことができる。

【0140】

いくつかの例において、関連付け生成器１４２Ａ及び１４２Ｂのそれぞれは、医療デバイス１２０のうちの１又は複数を特定の患者エンカウンタに関連付ける情報を生成する要求を処理するように構成されている。いくつかの例において、各関連付け生成器１４２Ａ及び１４２Ｂは、関連付け情報を生成する要求を受信するように構成されているソフトウェアインタフェース（例えば、ＡＰＩ）を露呈し実装する。これらの例において、ｅＰＣＲアプリケーション１２２及びイベントログアプリケーション１４０は、関連付けを生成する要求を生成し、ローカルにホストされている関連付け生成器１４２Ａ又は１４２Ｂに要求を通信するようにそれぞれ構成されている。ｅＰＣＲアプリケーション１２２及びイベントログアプリケーション１４０は、例えば、ヘルスケア提供者１１８Ａからの入力の受信に応答して、要求を生成するように構成されてよい。この入力は、患者エンカウンタの開始、患者エンカウンタの終了、又は単純に患者エンカウンタが進行中であることを示してよい。代替的に又は加えて、いくつかの例において、各関連付け生成器１４２Ａ及び１４２Ｂは、関連付け情報を生成する要求を受信するように構成されているユーザインタフェースを実装する。このユーザインタフェースは、患者エンカウンタの開始、患者エンカウンタが進行中であること及び／又は患者エンカウンタが完了したことを指定する入力を受信するように構成されているコントロールを含むことができる。さらに、ユーザインタフェースは、本明細書において議論されているように、医療デバイスの識別子の表現の取得を開始する及び／又は関連付け情報の他の要素を受信する入力を受信するように構成されているコントロールを含むことができる。さらに、ユーザインタフェースは、関連付け情報の格納及びサーバ１０８への送信を開始する入力を受信するように構成されているコントロールを含むことができる。

【0141】

図１を続けて参照すると、モバイルコンピューティングデバイス１０４は、いくつかの例によれば、デバイスの組み合わせを含むことができる。例えば、モバイルコンピューティングデバイス１０４は、プロセッサによって操作されたデータを格納するように構成されているメモリと結合されたプロセッサをそれぞれ含むことができる。モバイルコンピューティングデバイス１０４のそれぞれは、本開示の例によれば、クロックを有してよく、これは、ヘルスケア提供者１１８Ａが処置又は観察の時刻を手動で入力する必要（又は、処置が実施された長時間後に、チャート化の目的で処置の時刻の推測を試みる必要）を防止するために、ネットワークリソース又は人工衛星等の外部時刻ソースと同期することができる。モバイルコンピューティングデバイス１０４のそれぞれは、１又は複数のシステム、医療デバイス、及び／又は、医療デバイス１０２のような他のデバイスから及び／又はそれらにデータを受信及び／又は送信するように構成されているネットワークインタフェースを含むことができる。いくつかの例において、モバイルコンピューティングデバイス１０４のそれぞれは、医療デバイス１０２等の他のデバイスからデータを集約する又は別様に受信する別のデバイス又はシステム（例えば、リモートコンピューティングデバイス１０６、別のモバイルコンピューティングデバイス１０４、及び／又はサーバ１０８）と通信するために、これらのシステム、医療デバイス、及び／又はネットワークインタフェースを利用することができる。代替的に又は加えて、モバイルコンピューティングデバイス１０４のそれぞれは、データ入力デバイス並びに診断及び／又は治療医療デバイスを含むローカルネットワークを確立すること又は以前に確立されたローカルネットワークに参加することによって、医療デバイス１０２等のデバイスと通信することができる。このローカルネットワークは、１人又は複数人の患者の処置時にその現場においてアドホックな方式で確立することができ、２又は２よりも多い近傍に位置するデバイスを含むことができる。

【0142】

様々な実装において、モバイルコンピューティングデバイス１０４のそれぞれは、本開示の例によれば、デバイスの有用性をさらに向上するために、また、視覚的及び用手的注意を他のデバイスに別個に移すことをヘルスケア提供者１１８Ａに通常要求する特定のタスクを実行することをヘルスケア提供者１１８Ａにとってより容易にするために、他のデバイス（例えば、医療デバイス１０２及び他のモバイルコンピューティングデバイス１０４）からデータを受信、編成、格納、共有、配信、及び表示することができる。換言すれば、モバイルコンピューティングデバイス１０４のそれぞれは、本開示の例によれば、さもなければ分散され編成されない場合がある情報を一元化、編成、及び共有することができる。しかしながら、ロバストな双方向の完全に認証されたネットワーク接続は、確立及び維持にかなりのコンピューティングリソース及び時間を要求する可能性があることに留意すべきである。結果として、少なくともいくつかの例は、これらの種類のネットワーク接続を回避する。

【0143】

特定の例において、モバイルコンピューティングデバイス１０４のそれぞれは、サーバ１０８から受信された情報を他のデバイスと共有することができる。例えば、１つの例において、モバイルコンピューティングデバイス１０４Ａは、サーバ１０８から情報を受信することができ、そのような情報を医療デバイス１０２Ａと共有（例えば、ローカルネットワークを介して送信）することができる。代替的に又は加えて、医療デバイス１０２Ｎが患者１１６のＥＣＧ読み取り値を取得する場合、又は、医療デバイス１０２Ｎが、（投薬、胸骨圧迫、換気、除細動ショック等のような）処置を実施する場合、ＥＣＧ及び／又は処置を記述する情報は、モバイルコンピューティングデバイス１０４Ｂを介して又は直接、他のデバイス（例えば、リモートコンピューティングデバイス１０６、モバイルコンピューティングデバイス１０４Ａ、及び／又はサーバ１０８）と、その中に維持されている患者記録内に格納するために共有されてよい。別の例において、モバイルコンピューティングデバイス１０４のそれぞれは、健康記録データストア１１０から、医療記録、既知の医療状態、及び経歴情報等の患者情報を受信し、この情報を医療デバイス１０２のうちの１又は複数と共有するように構成することができる。この経歴情報は、モバイルコンピューティングデバイス１０４において維持されている及び／又は生成された患者記録（例えば、ｅＰＣＲ）に挿入することができる。

【0144】

モバイルコンピューティングデバイス１０４が、それが通信可能に結合されている他のデバイスから及び／又は入力を介してヘルスケア提供者（例えば、ヘルスケア提供者１１８Ａ又は１１８Ｂのいずれか）から更新された情報を受信したとき、モバイルコンピューティングデバイス１０４は、その更新された情報をサーバ１０８に送信することができる。したがって、１又は複数のデバイス（例えば医療デバイス１０２）からの情報は、モバイルコンピューティングデバイス１０４においてローカルに（例えば、メモリ４２１に）及び／又はサーバ１０８において（例えば、メモリ５２１、イベントログデータストア１４６に、及び／又はチャート化データストア１３４に）格納されてよい。モバイルコンピューティングデバイス１０４からのデータ（及び、存在する場合、モバイルコンピューティングデバイス１０４と通信可能に結合されてよい他のデバイスからのデータ）を、サーバ１０８によって受信して、以下でさらに説明されるように、イベントログＡＰＩ１４４、ｅＰＣＲ ＡＰＩ１２８、及び／又はケースＡＰＩ１２６を介して、イベントログデータストア１４６、チャート化データストア１３４、及び／又はケースデータストア１３２に格納することができる。また、リモートコンピューティングデバイス１０６は、これらのインタフェースを介して、格納された情報にアクセスして、格納された情報を健康記録データストア１１０に追加することもできる。

【0145】

本開示のいくつかの例によれば、モバイルコンピューティングデバイス１０４のそれぞれは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、及び／又はウェアラブル除細動器を含む１又は複数の医療デバイス１０２に（例えば、自動的に又は手動で又は選択的に）通信可能に結合することができる。これらの例において、そのように結合された任意のモバイルコンピューティングデバイス１０４は、１又は複数の医療デバイスによって生成された患者モニタリング情報を受信して表示することができる。そのようなモバイルコンピューティングデバイス１０４は、モバイルコンピューティングデバイス１０４が、患者１１６についての追加情報を索出するために、（例えば、ネットワーク１１２を横断して）外部データベース（例えば、健康記録データストア１１０）に対してクエリすることを可能にするように、１又は複数の医療デバイスから患者を識別する保護された健康情報を受信するように構成することもできる。このモバイルコンピューティングデバイス１０４は、本開示の例によれば、同様の方式で植え込み型除細動器（「ＩＣＤ」）と接続するように構成することもできる。

【0146】

特定の例において、モバイルコンピューティングデバイス１０４のそれぞれは、タブレット、スマートフォン、ウェアラブルデバイス、及び／又は他のモバイルコンピューティングデバイス、及び／又は、サーバ若しくはクラウドインタフェース、例えば、サーバ１０８とのインタフェースを介して、本明細書において説明されているイベントログ及び患者チャート化システム機能にアクセスすることができるモバイルデバイスの組み合わせとすることができる。本開示のいくつかの例によれば、モバイルコンピューティングデバイス１０４は、タブレットに通信可能に結合されて、患者１１６に何が行われたのか及びそれが行われたときを示すためにタップされることができるタッチスクリーン又は音声認識データ入力インタフェーススクリーン等のインタラクティブデータ入力インタフェースを伴うＡｐｐｌｅ（登録商標）ｉＰｈｏｎｅ（登録商標）又はｉＰａｄ（登録商標）等のリストバンド及び／又はスマートフォンを含むことができる。さらに、本開示のいくつかの例によれば、モバイルコンピューティングデバイス１０４は、患者をモニタし、患者を処置し、かつ患者の状態及び／又は患者１１６に適用された処置についての記録及び／又はノートを生成するように単一のデバイスを構成することができるように、医療デバイス１０２と統合することができる。これらの例において、ｅＰＣＲアプリケーション１２２は、組み合わせ医療／コンピューティングデバイス内に埋め込むことができる。モバイルコンピューティングデバイス１０４のいくつかのコンポーネントのさらなる説明は、以下で図１８を参照しながらさらに詳細に提供される。

【0147】

様々な実装において、医療デバイス１０２は、本開示の例によれば、患者処置デバイス、又は患者モニタリング及び／又は患者処置能力を有する他の種類のデバイスを含むことができる。例えば、医療デバイス１０２は、除細動器を含むことができ、患者に治療的電気ショックを送達するように構成することができる。いくつかの例において、医療デバイス１０２は、換気、レスピレータの操作、ＣＰＲの実行、及び／又は薬剤又は他の薬物の投与等の他のタイプの処置を送達することができる。

【0148】

より具体的には、医療デバイス１０２のうちの１又は複数は、本開示の例によれば、例えば、心拍数をモニタするために及び／又は心電図（ＥＣＧ）を生成するために患者１１６に取り付けられるように構成された電極及び／又はセンサ等の患者インタフェースデバイス１９０を有する除細動器であることができる。医療デバイス１０２のそれぞれは、本開示の例によれば、クロックを有することができ、これは、ヘルスケア提供者１１８Ａが処置又は観察の時刻を手動で入力する必要（又は、処置の時刻の推測を試みる必要）を防止するために、ネットワークリソース又は人工衛星等の外部時刻ソースと同期することができる。医療デバイス１０２とモバイルコンピューティングデバイス１０４との間の精密クロック同期は、以下でさらに説明されるように、特にタイムスタンプが少なくとも１つの検索基準において使用される場合に、医療デバイスケースファイルを特定の患者エンカウンタに関連付ける際に特に役立つことができる。したがって、少なくともいくつかの例において、各医療デバイス１０２及びモバイルコンピューティングデバイス１０４は、ローカルクロックを伴うタイミング回路を含む。タイミング回路は、ローカルクロックをそれぞれ含むことができ、タイミング回路は、タイミング回路のローカルクロック間のばらつきを特定して修正するように互いに通信することができる。いくつかの例において、タイミング回路のうちの１つは、「マスタ」タイミング回路として動作することができ、他のタイミング回路のそれぞれは、マスタタイミング回路におけるローカルクロックと同期する「スレーブ」タイミング回路として動作することができる。いくつかの場合において、これらのタイミング回路は、医療デバイス１０２及びモバイルコンピューティングデバイス１０４がサブマイクロ秒レベルの同期を実現することを可能にすることができる。他の場合において、これらのタイミング回路は、処理回路が１～１００マイクロ秒の範囲（例えば、１～１０マイクロ秒）又はそれ未満内の同期を実現することを可能にすることができる。少なくとも１つの例において、医療デバイス１２０及びモバイルコンピューティングデバイス１０４は、マスタタイミング回路とスレーブタイミング回路との間のタイミングを調整するためにタイミングプロトコルを利用する。そのようなタイミングプロトコルの例として、ＩＥＥＥ１５８８又は精密時間プロトコル（ＰＴＰ）、ネットワークタイムプロトコル（ＮＴＰ）、クロックサンプリング相互ネットワーク同期（ＣＳ－ＭＮＳ）アルゴリズム、基準ブロードキャスト同期（ＲＢＳ）アルゴリズム、基準ブロードキャストインフラストラクチャ同期（ＲＢＩＳ）アルゴリズム、及び全地球測位システム（ＧＰＳ）を挙げることができる。ネットワーク化計測及び制御システムの精密クロック同期プロトコルのためのＩＥＥＥ１５８８－２００８規格は、参照によってその全体が本明細書に組み込まれる。ＩＥＥＥ１５８８プロトコルは、Ｊｏｎｅｓ，Ｍｉｋｅ、「Ｇｅｔ ｉｎ Ｓｙｎｃ！：ＩＥＥＥ １５８８ｖ２ Ｔｒａｎｓｐａｒｅｎｔ Ｃｌｏｃｋ Ｂｅｎｅｆｉｔｓ ｆｏｒ Ｉｎｄｕｓｔｒｉａｌ Ｃｏｎｔｒｏｌ Ｄｉｓｔｒｉｂｕｔｅｄ Ｎｅｔｗｏｒｋｓ」、Ｍｉｃｒｅｌ，Ｉｎｃ．（２０１２年３月２２日）において、及びＷｕ，Ｊｉａｎｇ及びＰｅｌｏｑｕｉｎ，Ｒｏｂｅｒｔ、「Ｓｙｎｃｈｒｏｎｉｚｉｎｇ Ｄｅｖｉｃｅ Ｃｌｏｃｋｓ Ｕｓｉｎｇ ＩＥＥＥ １５８８ ａｎｄ Ｂｌａｃｋｆｉｎ Ｅｍｂｅｄｄｅｄ Ｐｒｏｃｅｓｓｏｒｓ」、Ａｎａｌｏｇ Ｄｉａｌｏｇｕｅ ４３－１１（２００９年１１月）からもさらに詳細に説明され、それらの両方は、参照によってその全体が本明細書に組み込まれる。

【0149】

また、医療デバイス１０２のそれぞれは、他の患者パラメータを検出するセンサ及び／又は導出若しくは計算するプロセッサ等の患者インタフェースデバイス１９０を含む及び／又はそれに結合することもできる。いくつかの例において、医療デバイス１０２のうちの１又は複数は、本開示の例によれば、血圧、温度、呼吸数、血中酸素レベル、呼気終末二酸化炭素レベル、肺機能、血糖値及び／又は体重をモニタ、検出、処置、及び／又は導出若しくは計算するように患者インタフェースデバイス１９０と相互運用するように構成されている。医療デバイス１０２及び患者インタフェースデバイス１９０のさらなる例は、図１８を参照しながら以下でさらに説明される。

【0150】

いくつかの例において、関連付け情報の生成を通して医療デバイス１０２によって生成された医療デバイスケースファイルへの容易なアクセスを開始するために、ヘルスケア提供者１１８Ａは、医療デバイスの識別子の表現を取得するためにモバイルコンピューティングデバイス１０４内に存在する医療デバイスインタフェースを使用することができる。この医療デバイスインタフェースは、例えば、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、無線ネットワークコネクタ、又は関係する識別情報を収集するのに適切な別のセンサを含むことができる。特に、特定の例において、これらの医療デバイスインタフェースは、医療デバイスとの時間のかかる通信又は認証セッションを確立することなく表現を取得する。例えば、いくつかの例において、医療デバイスインタフェースは、カメラを含み、ＱＲコード、バーコード、又は医療デバイス上で視認可能なデバイス識別子を単純にスキャンする。加えて又は代替的に、いくつかの例において、医療デバイスインタフェースは、医療デバイスに付けられているＮＦＣタグ又は無線周波数識別（ＲＦＩＤ）タグを読み取る。使用される具体的な技術にかかわらず、識別子の表現を取得することへのこの軽量アプローチは、関連付け情報を生成し、最終的には、容易かつ直感的な方式で患者エンカウンタの統合データソースエンカウンタ構造体にアクセスすることが可能であるために要求されるヘルスケア提供者１１８Ａの時間を最小限に抑える。少なくともいくつかの例において、医療デバイスの識別子は、各医療デバイスを一意に識別することに留意すべきである。

【0151】

図１を続けて参照すると、（例えば、患者処置の終結及び／又は病院の緊急救命室（ＥＲ）等のヘルスケア施設への患者１１６の移送を介した）患者エンカウンタの完了時及び／又は患者エンカウンタ中、ヘルスケア提供者１１８Ａは、緊急対応センタ内のＥＲアテンド又は他のヘルスケア提供者１１８Ｂに患者エンカウンタの統合データソースエンカウンタ構造体を提供することを望む場合がある、及び／又は、医療緊急事態中に統合データソースエンカウンタ構造体への即時アクセスを得ることを望む場合がある。いくつかの状況において、統合データソースエンカウンタ構造体は、（例えば、患者の状態が危機的である場合及び／又はイベント中に）迅速に提供されなければならない。そのため、いくつかの例において、モバイルコンピューティングデバイス１０４Ｂは、例えば、モバイルコンピューティングデバイス１０４の医療デバイスインタフェースを使用して、迅速な軽量通信技術を介して、（例えば、イベントログアプリケーション１４０の実行を介して）関連付け情報をモバイルコンピューティングデバイス１０４Ｃに送信するように構成されている。例えば、１つの例において、イベントログアプリケーションは、モバイルコンピューティングデバイス１０４Ｂのユーザインタフェースを介して、トークンの視覚表現をレンダリングするように構成されている。この例において、モバイルコンピューティングデバイス１０４Ｃは、（例えば、エンカウンタレビューアプリケーション１４８の実行を介して）トークンの表現を取得し、インタフェース１２６及び１２８のうちの１又は複数を介して患者エンカウンタの統合データソースエンカウンタ構造体の要求を送信するように構成されている。エンカウンタレビューアプリケーション１４８は、それについて統合データソースエンカウンタ構造体が検索される患者エンカウンタを一意に識別するために、要求内にトークンを含むことができる。この例の説明が完了するが、エンカウンタレビューアプリケーション１４８は、応答を受信し、ユーザインタフェースを介して、ヘルスケア提供者１１８Ｂに統合データソースエンカウンタ構造体を提供するように構成されている。又は、本明細書においてさらに議論されるように、サーバ１０８は、イベント中におけるヘルスケア提供者の利益のために、統合データソースエンカウンタ構造体をそのシーンに位置するモバイルコンピューティングデバイス１０４のうちの１又は複数に戻すように送信する場合がある。

【0152】

本開示の例によれば、サーバ１０８は、モバイルコンピューティングデバイス１０４からイベントログデータ及び／又は患者チャート化データを受信し、そのデータを（例えば、イベントログＡＰＩ１４４及び／又はｅＰＣＲ ＡＰＩ１２８の操作を介して）認証されたタイムスタンプ及びその情報を特定のモバイルコンピューティングデバイス１０４と関連付ける識別子とともに、イベントログデータストア１４６及び／又はチャート化データストア１３４に格納することができる。このようにして、複数のデバイスからのデータは、様々なユーザによってアクセスすることができる。

【0153】

いくつかの例において、ネットワーク１１２は、医療デバイス１０２、モバイルコンピューティングデバイス１０４、リモートコンピューティングデバイス１０６、及びサーバ１０８がそれを通してデータを送信、受信、及び／又は交換することができる１又は複数の通信ネットワークを含むことができる。様々な実装において、ネットワーク１１２は、セルラ通信ネットワーク及び／又はコンピュータネットワークを含むことができる。いくつかの例において、ネットワーク１１２は、無線ネットワーク及び／又は有線接続を含み、これをサポートする。例えば、これらの例において、ネットワーク１１２は、とりわけ、ＧＳＭ、ＣＭＤＡ、ＵＳＢ、ＢＬＵＥＴＯＯＴＨ、ＣＡＮ、ＺｉｇＢｅｅ（登録商標）、無線イーサネット、イーサネット、及びＴＣＰ／ＩＰ等の１又は複数のネットワーキング規格をサポートしてよい。ネットワーク１１２は、ローカルエリアネットワーク等のプライベートネットワーク及びインターネット等のパブリックネットワークの両方を含んでよい。いくつかの例において、ネットワーク１１２は、１つのエンドポイントから別のエンドポイントへのパケットのルーティングに関与する１又は複数の中間デバイスを含んでよいことに留意すべきである。しかしながら、他の例において、ネットワーク１１２は、それぞれ他方と直接ネットワーク接続している２つのみのエンドポイントを伴うことができる。

【0154】

サーバ１０８は、ケースＡＰＩ１２６、ｅＰＣＲ ＡＰＩ１２８、イベントログＡＰＩ１４４、患者エンカウンタデータソース統合サービス１３０、ケースデータストア１３２、イベントログデータストア１４６、基準データストア１３６、及びチャート化データストア１３４を実施するように構成されている１又は複数の物理的及び／又は仮想サーバコンピュータを含むことができる。したがって、サーバ１０８は、１又は複数のアプリケーションサーバ、ウェブサーバ、及び／又はデータベースサーバを含むことができる。サーバ１０８は、ネットワーク１１２を介して、リモートコンピューティングデバイス１０６、医療デバイス１０２、及びモバイルコンピューティングデバイス１０４と通信することができる。サーバ１０８は、唯一のテナントとして編成をサポートするように構成されている企業サーバ及び／又は複数のテナントとして複数の編成をサポートするように構成されているクラウドサーバを含むことができる。

【0155】

サーバ１０８は、互いに通信可能に結合されてよい１又は複数のクラウドにおいて実装されてよい。例えば、１又は複数のサーバを含む単一のクラウドは、図１の要素１２６、１２８、１３０、１３２、１３４、１３６、１４４及び１４６を含んでよい。代替的には、要素１２６及び１３２は、第１のクラウドにおいて実装されてよく、要素１３０及び１３６は、第２のクラウドにおいて実装されてよく、要素１２８及び１３４は、第３のクラウドにおいて実装されてよく、要素１４４及び１４６は、第４のクラウドにおいて実装されてよい。さらなる代替例として、要素１３０及び１３６は、同じクラウドにおいて要素１２６及び１３２として実装されてよく、又は、同じクラウドにおいて要素１４４及び１４６として実装されてよく、又は、同じクラウドにおいて要素１２８及び１３４として実施されてよい。さらに別の代替例として、要素１２６、１２８、１３２、１３４、１４４及び１４６は、第１のクラウドにおいて実装されてよく、要素１３０及び１３６は、第２のクラウドにおいて実装されてよい。

【0156】

患者エンカウンタデータソース統合サービス１３０と医療デバイスケースデータストア１３２との間の、図１に示されている通信リンク１８８ａは、任意選択のリンクである。同様に、患者エンカウンタデータソース統合サービス１３０とイベントログデータストア１４６との間の、図１に示されている通信リンク１８８ｂもまた、任意選択のリンクである。同様に、患者エンカウンタデータソース統合サービス１３０とチャート化データストア１３４との間の、図１に示されている通信リンク１８８ｃもまた、任意選択のリンクである。一実装において、患者エンカウンタデータソース統合サービス１３０は、セキュリティの目的で、これらのデータストアと直接通信しなくてもよい。特定の実装において、患者エンカウンタデータソース統合サービス１３０は、複数のデータフォーマットに精通（ｃｏｎｖｅｒｓａｎｔ）しており、このようなデバイスによって提供されるリソースに対するゲートキーパとしての役割を果たすことができるパブリックＡＰＩを介して、医療デバイス１０２及びモバイルコンピューティングデバイス１０４のコンポーネントとインタラクト可能である。例えば、医療デバイスケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６は、第１のエンティティによって所有されるか又は第１のエンティティ、第２のエンティティ、及び第３のエンティティによって別個に所有されてよい。患者エンカウンタデータソース統合サービス１３０は、第４のエンティティによって所有されてよい。こうして、ＡＰＩ（１２６、１２８、及び／又は１４４）は、データストア１３２、１３４及び１４６に対するアクセスに関してこれらの様々なエンティティ間のセキュリティを提供し得る。

【0157】

これらの及び／又は他の理由で、特定の実装において、患者エンカウンタデータソース統合サービス１３０は、図１に示されている破線１８８ａ、１８８ｂ、及び１８８ｃで示されているように、医療デバイスケースデータストア１３２、チャート化データストア１３４、及び／又はイベントログデータストア１４６と直接通信しないことが好ましい場合がある。このような場合において、患者エンカウンタデータソース統合サービス１３０は、医療デバイスケースデータストア１３２に格納されている情報の要求をケースＡＰＩ１２６に送信してよい。同様に、患者エンカウンタデータソース統合サービス１３０は、イベントログデータストア１４６に格納されている情報の要求をイベントログＡＰＩ１４４に送信してよい。同様に、患者エンカウンタデータソース統合サービス１３０は、チャート化データストア１３４に格納されている情報の要求をｅＰＣＲ ＡＰＩ１２８に送信してよい。これらの要求のうちの任意のものは、適切なセキュリティクレデンシャルを含んでよい。セキュリティクレデンシャルに基づいて、ケースＡＰＩ１２６、ｅＰＣＲ ＡＰＩ１２８、及び／又はイベントログＡＰＩ１４４は、情報の要求に対して許可又は拒否のいずれかをしてよい。それぞれのインタフェースが情報の要求を許可する場合、インタフェースは、適切なデータストアから要求された情報を索出する。患者エンカウンタデータソース統合サービス１３０は、患者エンカウンタデータソース統合サービス１３０によって識別された１又は複数の基準に従って１又は複数のデータマージ操作を実行してよい。患者エンカウンタデータソース統合サービス１３０が１又は複数のデータのマージ操作を完了したとき、患者エンカウンタデータソース統合サービス１３０は、医療デバイスケースデータストア１３２に格納するために、マージされたファイル（例えば、患者チャート化データにマージされた医療デバイスデータを含むファイル）をケースＡＰＩ１２６に戻してよい。

【0158】

いくつかの例において、サーバ１０８は、ケースＡＰＩ１２６、ｅＰＣＲ ＡＰＩ１２８、及び／又はイベントログＡＰＩ１４４を介して、医療デバイス１０２、モバイルコンピューティングデバイス１０４、及びリモートコンピューティングデバイス１０６等のリモートデバイスとデータを交換することができる。これらのインタフェースは、本明細書において説明されたｅＰＣＲアプリケーション１２２、イベントログアプリケーション１４０、及びエンカウンタレビューアプリケーション１４８等のリモートデバイスによって実施される処理が発したコマンドを受信し、処理し、それに応答するように構成されている。インタフェース１２６、１２８及び１４４は、様々な相互運用性規格及びアーキテクチャスタイルを使用して実施されてよい。例えば、１つの例において、インタフェース１２６、１２８及び１４４は、レプレゼンテーショナルステートトランスファ（ＲＥＳＴ）アーキテクチャスタイルを使用して実施されるウェブサービスインタフェースである。この例において、インタフェース１２６、１２８及び１４４は、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法及び／又は拡張可能マークアップ言語とともにハイパーテキストトランスファープロトコル（ＨＴＴＰ）を使用してクライアントプロセスと通信する。いくつかの例において、ＨＴＴＰ通信の一部は、セキュリティを高めるために暗号化することができる。代替的に又は加えて、いくつかの例において、インタフェース１２６、１２８及び１４４は、特定のユニフォームリソースロケータに対するＨＴＴＰポストに、ケースデータ、イベントログデータ、チャート化データを記述するデータで応答する、．ＮＥＴウェブインタフェースとして実装される。代替的に又は加えて、いくつかの例において、インタフェース１２６、１２８及び１４４は、送信制御プロトコルソケットを介してアクセス可能なシンプルなファイル転送プロトコルコマンド及び／又はプロプライエタリアプリケーションプロトコルを使用して実装される。このように、本明細書において説明されるインタフェース１２６、１２８及び１４４は、特定の実装に限定されない。

【0159】

いくつかの例において、インタフェース１２６、１２８及び１４４は、信頼できるシステムパフォーマンスを可能にするために複数のエンドポイントを含む。例えば、少なくとも１つの例において、インタフェース１２６、１２８及び１４４のそれぞれは、ケースデータストア１３２、チャート化データストア１３４、又はイベントログデータストア１４６に以前に格納されたデータの要求を受信して処理するための１又は複数の第１のエンドポイントと、ケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６内に新たなデータを格納する要求を受信して処理するための１又は複数の第２のエンドポイントとを含む。この構成は、ケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６に既に格納されているデータの要求に、最小限の遅延で迅速にサーブすることができることを確実にすることができる。ｅＰＣＲ、ケースファイル、又はイベントログをアップロードする；ｅＰＣＲ、ケースファイル、又はイベントログをパースする；結果として得られるチャート化データ、ケースデータ、又はイベントログデータをケースデータストア１３２、チャート化データストア１３４、又はイベントログデータストア１４６に格納する要求は、より多くの処理時間及びリソースを要求する可能性があるので、この分岐アーキテクチャが役立つことができる。

【0160】

いくつかの例において、インタフェース１２６、１２８及び１４４は、新たに受信されたケースデータ、チャート化データ、イベントログデータ、及び関連付け情報の患者エンカウンタデータソース統合サービス１３０を通知する（及び／又は含む）メッセージを患者エンカウンタデータソース統合サービス１３０に送信するように構成されている。メッセージが新たなデータの存在を患者エンカウンタデータソース統合サービス１３０に単に通知する場合、メッセージは、ケースデータストア１３２、チャート化データストア１３４、及び／又はイベントログデータストアから新たなデータを索出するために患者エンカウンタデータソース統合サービス１３０によって利用することができる新たなデータの１又は複数の識別子を含むことができるが、新たなデータの識別子を含むことは必須ではない。特定の例において、ケースＡＰＩ１２６は、医療デバイス１０２からケースファイルを受信し、ケースファイルを処理し、処理の結果を示すメッセージを医療デバイス１０２に送信するように構成されている。この処理は、その中に格納されているケースデータの値を索出するためにケースファイルをパースすることと、ケースデータをケースデータストア１３２に格納することとを含むことができる。同様に、いくつかの例において、ｅＰＣＲ ＡＰＩ１２８は、モバイルコンピューティングデバイス１０４からｅＰＣＲを受信し、ｅＰＣＲを処理し、処理の結果を示すメッセージをモバイルコンピューティングデバイス１０４に送信するように構成されている。この処理は、その中に格納されているチャート化データの値を索出するためにｅＰＣＲをパースすることと、チャート化データ及び／又はｅＰＣＲをチャート化データストア１３４に格納することとを含むことができる。同様に、いくつかの例において、イベントログＡＰＩ１４４は、モバイルコンピューティングデバイス１０４からイベントログを受信し、イベントログを処理し、処理の結果を示すメッセージをモバイルコンピューティングデバイス１０４に送信するように構成されている。この処理は、その中に格納されているイベントログデータの値を索出するためにイベントログをパースすることと、イベントログデータ及び／又はイベントログをイベントログデータストア１４６に格納することとを含むことができる。ｅＰＣＲ及び／又はイベントログは、集約されたケースデータを生成するために患者エンカウンタデータソース統合サービス１３０によって参照することができる関連付け情報を含むことができることに留意すべきである。

【0161】

いくつかの例において、インタフェース１２６及び１２８は、エンカウンタレビューアプリケーション１４８から集約されたケースデータの要求を受信するようにさらに構成されている。その要求は、集約されたデータが要求される患者エンカウンタを一意に識別するトークンを含むことができる。これらの要求の受信に応答して、インタフェース１２６及び１２８は、本明細書において説明される処理を使用して集約されたケースデータを準備及び／又は識別するとともに、集約されたケースデータをエンカウンタレビューアプリケーション１４８に戻すために、患者エンカウンタデータソース統合サービス１３０と相互運用するように構成されている。患者エンカウンタデータソース統合サービスが集約されたケースデータを事前に（例えば、エンカウンタレビューアプリケーション１４８からの要求の受信にいくらかの時間先んじて、関連付け情報の受信に応答して）準備している場合、患者エンカウンタデータソース統合サービス１３０は、トークンを使用して、集約されたデータをそのストレージから単純にフェッチして、集約されたデータをエンカウンタレビューアプリケーション１４８に送信することができる。

【0162】

図１を引き続き参照すると、チャート化データストア１３４は、例えば、データベース（例えば、リレーショナルデータベース）によって実施し、非一時的記憶媒体に記憶することができる。一実装において、チャート化データストア１３４は、複数のｅＰＣＲから導出されたチャート化データを格納する複数の記録を含む。少なくとも１つの例において、チャート化データストア１３４は、ｅＰＣＲテーブル及びｅＰＣＲフィールドテーブルを含むリレーショナルデータベーステーブルのセットに編成される。この例において、ｅＰＣＲテーブルは、チャート化データストア１３４内の患者エンカウンタをドキュメント化するｅＰＣＲをそれぞれ記述するデータの行を含む。こうして、ｅＰＣＲテーブルにおける各行は、ｅＰＣＲの一意の識別子、ｅＰＣＲが生成されたときを示すタイムスタンプ、及びｅＰＣＲによってドキュメント化された患者エンカウンタを記述するメタデータ（例えば、患者を一意に識別する患者識別情報、患者エンカウンタに関与したヘルスケア提供者、ｅＰＣＲがクローズドエンドした理由及びアウトカム、患者エンカウンタの解決に使用された医療デバイス及びサプライの一意の識別子、患者エンカウンタ中に発生した総合的な問題、及び／又はｅＰＣＲに関連付けられている派遣されたＥＭＳイベントのタイプ）を格納するように構成されているフィールドを含むことができる。

【0163】

この例を引き続き参照すると、ｅＰＣＲフィールドテーブルは、ｅＰＣＲ内に格納されたフィールドをそれぞれ記述するデータの行を含む。こうして、ｅＰＣＲフィールドテーブルにおける各行は、そのフィールドが属するｅＰＣＲの一意の識別子を格納するように構成されているフィールド、ｅＰＣＲに関連付けられているフィールドの中のフィールドを一意に識別するフィールド、フィールドに値が入力されたときを示す日付／タイムスタンプ、値のソース（例えば、特定の医療デバイス又は特定のコンピューティングデバイス）の一意の識別子、及び、（タイプ識別子又はテキスト情報を介して）フィールドに関連付けられている１又は複数の値を識別するフィールドを含む。特に、各ｅＰＣＲは、特定のデータタイプの入力をそれぞれ要求する大量のフィールドを有することができる。例えば、いくつかの例示的なｅＰＣＲは、１００のフィールド、２００のフィールド、４００のフィールド、６００のフィールド、又はそれよりも多くのフィールドを有してよい。この数のフィールドは、義務付けられてよく、したがって、各ｅＰＣＲが完全であることが重要である。したがって、いくつかの例において、チャート化データストア１３４及び／又はｅＰＣＲアプリケーション１２２等の他のコンポーネントは、ｅＰＣＲアプリケーションのユーザによるｅＰＣＲフィールドの修正／削除を防止するように構成されている。いくつかの例において、ｅＰＣＲは、チャート化データストア１３４への送信のためにファイルにシリアル化することができることに留意すべきである。これらの例において、チャート化データストア１３４は、ｅＰＣＲファイルそれら自体の完全な別個のコピーを（例えば、ラージバイナリオブジェクトとして）格納することができる。

【0164】

図１を引き続き参照すると、ケースデータストア１３２は、例えば、データベース（例えば、リレーショナルデータベース）によって実装され、非一時的記憶媒体に記憶することができる。一実装において、ケースデータストア１３２は、エンカウンタ中に患者を処置するために使用された複数の医療デバイスからのケースファイルから導出されたケースデータを格納する複数の記録を含む。また、いくつかの例において、ケースデータストア１３２は、ケースファイルそれら自体の完全なコピー（例えば、ラージバイナリオブジェクトとして）格納することができる。ケースデータストア１３２に格納されているケースデータは、医療デバイスの観点から患者エンカウンタをドキュメント化することができる。したがって、患者エンカウンタ中に医療デバイスによって生成されたケースデータは、医療デバイスの識別子、エンカウンタ中に医療デバイスによって記録された患者の生理学パラメータ値、エンカウンタ中に医療デバイスによって患者に提供された処置の特性、エンカウンタ中にヘルスケア提供者によって取られたアクション、及びこの情報のうちの任意のものが記録されたときをドキュメント化したタイムスタンプを含むことができる。例えば、医療デバイスが除細動器である場合、ケースデータは、他の情報の中でも、患者のＥＣＧデータ等の患者生理学パラメータ、並びに、除細動器によって患者に送達された治療的ショックの特性、ＣＰＲ（例えば、胸骨圧迫及び／又は換気）パフォーマンスデータ、並びに、除細動器の出力が上げられたとき及びこの情報が記録されたときを反映するタイムスタンプを含むことができる。

【0165】

イベントログデータストア１４６は、例えば、データベース（例えば、リレーショナルデータベース）によって実装され、非一時的記憶媒体に記憶することができる。１つの例において、イベントログデータストアは、タイムスタンプが付与されたイベントをそれぞれ指定する複数の記録を含む。イベントログデータストア１４６は、多種多様なイベントを格納するように構成されている。これらのイベントの例としては、他のイベントの中でも、ＣＰＲ実施、治療的電気パルスの送達、薬物の提供、特定のＥＣＧリズムの発生、自己心拍再開（ＲＯＳＣ）、患者バイタル情報、患者に実施された処置（例えば、挿管チューブの配置）、医療デバイス電源オン、保護された健康情報（例えば、患者を識別する情報）の入力、ヘルスケア提供者への医療デバイスプロンプトの提供、処置（例えば、患者の胸骨に位置するセンサから生成された加速度信号を介して検知された胸骨圧迫、患者の気道に沿って位置するセンサから生成された流量／圧力信号を介して検知された換気）の提供、特定のＥＣＧリズム（例えば、心室細動、心室頻拍、心停止、無脈性電気活動、洞調律等）の発生、患者への治療的電気パルスの送達、及び投薬の実施が挙げられる。

【0166】

基準データストア１３６は、例えば、データベース（例えば、リレーショナルデータベース）によって実装され、非一時的記憶媒体に記憶することができる。１つの例において、基準データストア１３６は、関連付け情報の要素と、ケースデータ、イベントログデータ、及び／又はチャート化データのパラメータとの間の関係をそれぞれ指定する複数の記録を含む。この例において、複数の記録のそれぞれは、この関係を基準データストア１３６内の他の関係に対してランク付けする情報も含む。このランク付けは、図１５及び図１６を参照しながら以下でさらに説明されるように、反復検索プロセス中に患者エンカウンタデータソース統合サービスによってアクセスすることができる。

【0167】

基準データストア１３６は、統合記録内のどのデータがｅＰＣＲチャート化データファイルから発生し、統合記録内のどのデータが医療デバイスケースファイルから発生したかを追跡する監査証跡を任意で維持する。特定の実施形態において、コンフリクトするデータが存在する場合、直近に取得されたデータがより古いデータに優先することができる。コンフリクトするデータが存在する他の実施形態において、この構成情報は、どのデータが優先する（例えば、保持される）か及びどのデータが格下げされる（例えば、破棄される）かを決定するデータソースの階層を指定するために使用することができる。

【0168】

１つの実装において、監査証跡は、各ファイルを処理した結果の指示とともに、患者エンカウンタデータソース統合サービス１３０によって処理された各ファイルの参照番号を含む。例えば、医療デバイスケースファイルは、（ｉ）別の医療デバイスケースファイルとマージされている又は（ｉｉ）ｅＰＣＲチャート化データファイルとマージされていると示され得る。複数のオリジナル医療デバイスケースファイルがマージされ、結果として得られたマージされたファイルが続いて患者エンカウンタデータソース統合サービス１３０によって処理される場合、オリジナルファイルを識別する監査ファイル内の情報を使用して、患者エンカウンタデータソース統合サービス１３０が、（ｉ）オリジナルファイルが既に処理されている場合にはマージされたファイルを無視し、（ｉｉ）（例えば、マージされたファイルの残りが既に統合されている場合には）ｅＰＣＲチャート化データファイルとの統合のためにマージされたファイルの一部のみを選択する、又は、（ｉｉｉ）マージされたファイルを、ｅＰＣＲ ＡＰＩ１２８が冗長情報を除去するために使用することができる冗長性情報を伴うｅＰＣＲチャート化データファイルと統合することを可能にすることができる。

【0169】

ケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６は、様々な物理及び／又は論理構造に従って編成することができる。少なくとも１つの例において、ケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６は、高度に正規化されたスキーマを有するリレーショナルデータベース内に実装され、オラクル又はＳＱＬ－ＳＥＲＶＥＲ等の構造化クエリ言語（ＳＱＬ）エンジンを介してアクセス可能である。このスキーマは、いくつかの実装において、ケースデータストア１３２、チャート化データストア１３４、及び／又はイベントログデータストア１４６が複数のテナントのためのデータを収容することを可能にする列及びデータを含むことができる。さらに、上で提供された説明は、ケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６をリレーショナルデータベースとして示しているが、本明細書において説明される例は、特定の物理形態に限定されない。他のデータベースとしては、オペレーティングシステムによって維持される、シリアル化されたプロプライエタリデータ構造体を含むフラットファイル、階層型データベース、ｘｍｌファイル、ＮｏＳＱＬデータベース、ドキュメント指向データベース等が挙げられ得る。このように、本明細書において説明されているケースデータストア１３２及びチャート化データストア１３４は、特定の実装に限定されない。

【0170】

ケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６は、モバイルコンピューティングデバイス１０４及び／又は医療デバイス１０２から受信された情報を、その情報の後の使用を可能にするように、リモートデバイスよりも長い期間セキュアに格納することができる。例えば、モバイルコンピューティングデバイス１０４は、モバイルコンピューティングデバイス１０４への直接のユーザ入力を介して保護された健康情報（例えば、名前、住所、及び／又は社会保障番号等の患者識別情報）を受信してよく、次に、患者１１６に関与する過去の記録についてチャート化データストア１３４又はイベントログデータストア１４６に対してクエリするために、保護された健康情報の一部又は全てをサーバ１０８に搬送してよい。一実装において、モバイルコンピューティングデバイス１０４は、医療施設、保険会社、医療請求サービス、金融記録サービス、及び／又は健康情報交換によって提供されるもの等の様々なデータベースからの患者記録及び／又は情報にアクセスするために、ネットワーク１１２を介して、患者識別情報の一部又は全てを他のサーバに搬送することができる。他の例において、モバイルコンピューティングデバイス１０４は、限定されないが、有線若しくは無線通信及び／又はメッセージを含む他の方法で情報を受信するように構成することができる。

【0171】

ネットワーク１１２を介してアクセスされるサーバ１０８及び／又は他のサーバは、次に、現在の緊急エンカウンタでヘルスケア提供者１１８Ａを支援するために、任意のそのような記録又はそのような記録の一部を（例えば、イベントログスクリーン、患者チャート化スクリーン、又は既往歴スクリーンに表示するために）モバイルコンピューティングデバイス１０４に戻すように転送することができる。同様に、そのような過去のエンカウンタ情報は、本開示の例によれば、ヘルスケア提供者１１８Ｂ等の他のユーザによってアクセスされてもよい。

【0172】

リモートコンピューティングデバイス１０６は、健康記録データストア１１０を実装するように構成されている１又は複数の物理的及び／又は仮想コンピュータを含むことができる。健康記録データストア１１０は、患者医療歴を記述する記録を含むことができる。これらの記録は、エンカウンタの前の病歴、エンカウンタにつながる兆候、エンカウンタ中に識別された任意の診断、エンカウンタの結果として処方された処置、及び処置からもたらされたアウトカム等の、様々な患者情報を含むことができる。少なくとも１つの例において、リモートコンピューティングデバイス１０６及び健康記録データストア１１０は、全州健康データ交換規格、地域健康データ交換規格、ＨＬ７メッセージ規格、及び米国処方薬プログラム協会（ＮＣＰＤＰ）スクリプト規格等の健康データ交換規格をサポートする１又は複数のインタフェースを露呈するように構成されている健康情報交換（ＨＩＥ）としてまとめて動作する。健康記録データストア１１０は、１つの組織によって、又は病院、診療所、医院、及び薬局等の他の組織若しくはネットワーク若しくは第三者のソースによって生成されたデータを含むことができることに留意すべきである。
［関連付けプロセス］

【0173】

いくつかの例において、システム１００は、複数の医療デバイスケースファイルからのケースデータを集約する様々な処理を実行するように構成されている。例えば、図４は、モバイルコンピューティングデバイス（例えば、図１のモバイルコンピューティングデバイス１０４）、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）、ケースインタフェース（例えば、図１のケースＡＰＩ１２６）、及び１又は複数の医療デバイス（例えば、図１の医療デバイス１０２）によって実行される集約プロセス４００を示している。

【0174】

集約プロセス４００は、モバイルコンピューティングデバイスが新たな患者エンカウンタの開始を示す入力を受信すること（４０２）で開始する。例えば、モバイルコンピューティングデバイスは、患者エンカウンタに関与した異なる医療デバイスによって生成されたデータを関連付けるため等の関連付け情報の生成を要求する入力、新たなｅＰＣＲの作成を要求する入力、又は新たなイベントログの作成を要求する入力を受信してよい。入力の受信に応答して、モバイルコンピューティングデバイスは、（例えば、図１の関連付け生成器１４２Ａ又は１４２Ｂの実行を介して）新たな患者エンカウンタを表すトークンを生成する（４０４）。例えば、関連付け生成器１４２は、ＵＵＩＤを生成し、このＵＵＩＤをローカルメモリ内にトークンとして格納することができる。患者エンカウンタ中の或る時点において、モバイルコンピューティングデバイスは、患者エンカウンタ中に患者（例えば、図１の患者１１６）を処置するために使用された１又は複数の医療デバイスの１又は複数の第１の識別子の１又は複数の表現を取得する（４０６）。例えば、モバイルコンピューティングデバイスは、医療デバイスを識別するＱＲコードのイメージ又は（例えば、ＮＦＣを介して）識別タグを取得することができる。次に、モバイルコンピューティングデバイスは、（例えば、図１のｅＰＣＲ ＡＰＩ１２８又はイベントログＡＰＩ１４４等のｅＰＣＲインタフェース又はイベントログインタフェースを介して）トークン及び１又は複数の第１の識別子を含む関連付け情報を指定する１又は複数のメッセージを患者エンカウンタデータソース統合サービスに送信する（４０８）。

【0175】

集約プロセス４００の別の部分として、医療デバイスは、患者エンカウンタ中に患者についてのケースファイルを記録する（４１９）。例えば、医療デバイスは、患者のタイムスタンプが付与された生理学データ、患者人口統計学データ、及び／又はヘルスケア提供者パフォーマンスデータを取得し、このケースデータを医療デバイスの１又は複数の第２の識別子と関連付けてローカルメモリに格納してよい。医療デバイスは、ケースファイル及び医療デバイスの１又は複数の第２の識別子を含むメッセージをケースインタフェースに送信する（４２２）。ケースインタフェースは、ケースファイル及び１又は複数の第２の識別子を含むメッセージを受信し（４２４）、これらのケースファイルを処理（例えば、パース）して、ケースデータを生成する（４２６）。次に、ケースインタフェースは、患者エンカウンタデータソース統合サービスによる後続の処理のために、ケースデータを第２の識別子と関連付けてケースデータストア（例えば、図１のケースデータストア１３２）内に格納する（４２８）。

【0176】

集約プロセス４００を続けると、患者エンカウンタデータソース統合サービスは、関連付け情報を指定するメッセージを受信する（４１０）。患者エンカウンタデータソース統合サービスは、（例えば、図６、図７、及び図１２～図１６を参照しながら以下で詳細に説明されるもの等の、１又は複数の関連付けプロセスの実行を介して）医療デバイスの第１の識別子に対応する第２の識別子と関連付けてケースデータストアに格納されているケースデータを識別する（４１２）。対応する医療デバイス識別子は、患者エンカウンタについてのケースファイルの識別に役立つが、対応する医療デバイス識別子は、単独では、患者エンカウンタに関与したケースファイルのみを確実に識別するのに不十分であり得ることに留意すべきである。したがって、いくつかの例は、以下でさらに議論されるように、タイムスタンプ及び／又はジオタグ等の追加の基準を利用する。患者エンカウンタデータソース統合サービスは、識別されたケースデータから集約されたケースデータを生成し（４１４）、（例えば、ｅＰＣＲインタフェース及びイベントログインタフェースのうちの一方又は両方を介して）集約されたケースデータをモバイルコンピューティングデバイスに送信する（４１４）。この集約されたケースデータは、全て同じ患者エンカウンタに関連付けられている、識別されたケースデータ、チャート化データ、及び／又はイベントログデータを含むことができる。

【0177】

集約／統合プロセス４００を続けると、モバイルコンピューティングデバイスは、集約されたデータを受信し（４１６）、例えばローカルアプリケーション（例えば、ｅＰＣＲアプリケーション１２２、イベントログアプリケーション１４０、及び／又はエンカウンタレビューアプリケーション１４８）の実行を介して、集約されたデータをレンダリングする（４１８）。いくつかの例において、モバイルコンピューティングデバイスは、患者エンカウンタにリンクされた複数の医療デバイスによって生成されたケースファイルのための関連付け情報のソースであるので、同じモバイルコンピューティングデバイスが、さもなければ認証若しくは他の不便な方策を伴い得る不便な行為であり得る他のデバイスへの別個のアクセスをヘルスケア提供者に要求することなく、要求によって又は自動的に、集約されたデータを受信してよい。

【0178】

いくつかの例において、集約されたケースデータは、また、モバイルコンピューティングデバイス１０４Ａ以外のコンピューティングデバイス（例えば、モバイルコンピューティングデバイス１０４Ｃ又は別のコンピューティングデバイス）に送信され（４１４）、例えば医療ケースレビューステーション、リモートテレメディシンデバイス等におけるユーザインタフェースディスプレイ上にレンダリング（４２９）されてよいことに留意すべきである。例えば、集約されたケースデータは、シーンから遠隔にいる臨床医がすぐその場にいるヘルスケア提供者にガイダンス又は命令を与えることができるように、彼／彼女に利用可能とされてよい。代替的に又は加えて、集約されたケースデータは、ケース後分析及びレビューのために、医療イベントが終了した後にユーザによってアクセスされてよい。

【0179】

集約プロセス４００のいくつかの例において、操作４２２内で、医療デバイスは、ケースファイルをリアルタイムでケースインタフェースにストリーミングすることにも留意すべきである。これらの例において、ケースインタフェース及び患者エンカウンタデータソース統合サービスは、また、ライブの患者エンカウンタの一部としてストリーミングされているケースデータを識別するようにリアルタイムで動作し、ストリーミングされているケースデータを集約し、リアルタイムレンダリングのために集約されたケースデータをモバイルコンピューティングデバイスに送信する。したがって、集約されたケースデータは、患者エンカウンタ中の全ての注目すべき出来事の高いレベルの視点を実現可能であるように、医療実践者がシーンに位置する様々なデバイスによって生成されたライブ情報を受信可能であるようにリアルタイム方式でアップデートされてよい。

【0180】

いくつかの例において、患者エンカウンタデータソース統合サービス１３０は、複数のケースファイル（例えば、シーンに位置する医療デバイスによって生成された）を識別し、互いに関連付け、いくつかの実装において、患者エンカウンタをドキュメント化するｅＰＣＲ及び／又はイベントログと関連付けるように構成されている。上で議論したように、ケースファイル、ｅＰＣＲ、及びイベントログからの医療データは、それぞれ、ケースファイル、ｅＰＣＲ、及びイベントログのコピーとともに、ケースデータストア１３２、チャート化データストア１３４、及びイベントログデータストア１４６内に格納することができる。いくつかの実装において、ケースファイル、ｅＰＣＲ、及びイベントログ間の関連付けを、データストア１３２、１３４及び１４６内に格納することもできる。図５Ａは、これらの及び他の実装における患者エンカウンタデータソース統合サービス１３０によって実行される集約プロセス５００ａの１つの例を示している。

【0181】

図５Ａに示されているように、プロセス５００ａは、患者エンカウンタデータソース統合サービスが、医療デバイスから識別情報を取得し、続いて医療デバイスから発生したデータのリンクを提供するために関連付け情報を生成したシーンに位置するモバイルコンピューティングデバイス１０４から、関連付け情報を受信すること（５０２ａ）で開始する。いくつかの例において、医療デバイスデータを関連付けるためにモバイルコンピューティングデバイスを使用するヘルスケア提供者は、医療デバイス間の関連付け情報を生成するために及び関係する対応するケースファイルを一緒に関連付ける要求をサーバに送信するために、モバイルデバイス上で入力を与えてよい。患者エンカウンタデータソース統合サービスは、関連付け情報を含むインタフェース（例えば、図１のケースＡＰＩ１２６、ｅＰＣＲ ＡＰＩ１２８、及び／又はイベントログＡＰＩ１４４）から生成されたメッセージを受信することができる（５０２ａ）。代替的に又は加えて、いくつかの例において、患者エンカウンタデータソース統合サービスは、データストア（例えば、図１のチャート化データストア１３４及び／又はイベントログデータストア１４６）から関連付け情報を受信することができる（５０２）。これらの例において、患者エンカウンタデータソース統合サービスは、インタフェースからのメッセージに含まれているチャート化データ又はイベントログデータの識別子を利用して、チャート化データ又はイベントログデータ内に含まれている関連付け情報を要求して受信することができる（５０２ａ）。代替的に又は加えて、これらの例において、患者エンカウンタデータソース統合サービスは、新たなチャート化データ又はイベントログデータが要求された最後の時間をマークするために患者エンカウンタデータソース統合サービスによって維持されている予め定められたタイムスタンプの後でチャート化データストアに追加されたチャート化データ又はイベントログデータストアに追加されたイベントログデータを要求して受信することができる（５０２ａ）。

【0182】

プロセス５００ａを続けると、患者エンカウンタデータソース統合サービスは、関連付け情報に基づいて少なくとも１つの検索基準を生成する（５０４ａ）。いくつかの例において、少なくとも１つの検索基準は、関連付け情報に含まれている複数の医療デバイスの識別子及び関連付け情報の少なくとも１つの要素と医療デバイスケースファイルに関連付けられている少なくとも１つのパラメータとの間の少なくとも１つの予め定められた関係を指定する。予め定められた関係は、例によって異なることができる。例えば、いくつかの例において、予め定められた関係は、少なくとも１つの要素と少なくとも１つのパラメータとの間の等価性とすることができる。等価性の予め定められた関係は、少なくとも１つの要素と少なくとも１つのパラメータとが、精確に合致させる又は満たすことができる数値又はストリングを有する場合に、特に有用とすることができる。代替的に又は加えて、予め定められた関係は、少なくとも１つの要素と少なくとも１つのパラメータとの間の近接性又は類似性とすることができる。近接性又は類似性に基づく予め定められた関係は、少なくとも１つの要素と少なくとも１つのパラメータとが、タイムスタンプ、異なる時点で若しくは異なるデバイスによって取得された生理学測定値、又は不正確に（例えば、閾値近接性又は類似性を満たすことによって）しか合致させる若しくは満たすことができない他の値を有する場合に、特に有用とすることができる。代替的に又は加えて、予め定められた関係は、複数の要素とパラメータとの間の等価性、近接性、及び／又は類似性の組み合わせとすることができる。例えば、１つの例において、予め定められた関係は、ケースファイルに記録されたケース開始時間及びケース終了時間と関連付け情報との間の重複範囲、並びに、ケースファイルからの患者生体識別子と関連付け情報との間の等価性、並びに、ケースファイルからのヘルスケア提供者生体識別子と関連付け情報との間の等価性のうちの少なくとも１つを要求する。いくつかの実装において、ケースファイルに記録されているケース開始時間及び終了時間と関連付け情報との間の重複範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。例えば、関連付け情報が１０：００ａｍのケース開始時間及び１０：１５ａｍのケース終了時間を示す場合、ターゲット時間範囲は、９：５５ａｍ～１０：２０ａｍ、９：５５ａｍ～１０：１６ａｍ、９：５９ａｍ～１０：２０ａｍ、１０：０１ａｍ～１０：１５ａｍ、１０：００ａｍ～１０：１４ａｍ、又は任意の他の好適な範囲であってよい。こうして、ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでないことが理解される。通常、異なる医療デバイス間のクロックは、互いに正確に同期されていない場合がある。いくつかの実施形態において、ケース開始時間／終了時間は、医療デバイスケースファイルと関連付け情報との間で正確に合致する。

【0183】

いくつかの例において、少なくとも１つの予め定められた関係は、患者エンカウンタデータソース統合サービスのハードコーディング部分である。これらの例において、患者エンカウンタデータソース統合サービスは、関連付け情報内の少なくとも１つの要素を識別するとともにその少なくとも１つの要素を予め定められた関係と関連付けることによって、少なくとも１つの検索基準を生成する（５０４ａ）。例えば、予め定められた関係が近接しており、ケースファイルのパラメータが関連付け情報の要素の範囲内にあることを要求し、その要素が、エンカウンタをドキュメント化するケースが開始したときを示すタイムスタンプである場合、患者エンカウンタデータソース統合サービスは、関連付け情報内のタイムスタンプを識別するとともに、検索５０６ａにおけるその後の使用のために、そのタイムスタンプをケース開始時間の範囲と関連付けることによって、少なくとも１つの検索基準を生成する（５０４ａ）。そのような範囲は、患者エンカウンタデータソース統合サービス及び／又は予め定められた値によって計算された動的値とすることができることに留意すべきである。例えば、範囲は、関連付け情報からのケース開始時間とケア移行時間との間の計算された範囲を含むことができる。代替的に又は加えて、ケース開始時間の予め定められた範囲は、例えば、０～１分、０～２分、０～５分、及び１～１０分の間とすることができる。任意の所与の予め定められた関係は、これらの範囲を、同一のイベント（例えば、ケース開始時間）を示す要素と時間パラメータとの間、又は、異なるイベント（例えば、ケース開始時間及び処置時間又は移行時間）を示す要素と時間パラメータとの間に適用することができる。

【0184】

いくつかの例において、少なくとも１つの予め定められた関係は、ソフトコーディングされ、基準データストア（例えば、図１の基準データストア１３６）内に格納される。これらの例において、患者エンカウンタデータソース統合サービスは、上で説明された関連付け情報内で、予め定められた関係によって指定される少なくとも１つの要素を識別する前に、基準データストアから好ましい予め定められた関係を識別することによって、少なくとも１つの検索基準を生成することができる（５０４ａ）。例えば、いくつかの例において、プロセス５００ａの現在のインスタンスによってまだ使用されていない最高ランクの予め定められた関係を発見することによって、患者エンカウンタデータソース統合サービスは、好ましい予め定められた関係を識別することができる。

【0185】

少なくとも１つの要素及び少なくとも１つのパラメータのそれぞれは、単一の要素若しくはパラメータ又は複数の要素若しくはパラメータとすることができることに留意すべきである。例えば、いくつかの例において、少なくとも１つの要素は、ｅＰＣＲ又はイベントログが開かれた時間を示すタイムスタンプであり、少なくとも１つのパラメータは、ケースファイルが開始された時間を示すタイムスタンプである。他の例において、少なくとも１つの要素は、複数の要素を含み、少なくとも１つのパラメータは、複数のパラメータを含む。これらの例のいくつかにおいて、複数の要素は、ｅＰＣＲ又はイベントログがサーバ１０８にアップロードされた時間を示すタイムスタンプ及びｅＰＣＲ又はイベントログを生成したモバイルコンピューティングデバイスの識別子を含み、複数のパラメータは、ケースファイルがサーバ１０８にアップロードされた時間を示すタイムスタンプ及びケースファイルを生成した医療デバイスの識別子を含む。関連付け情報の他の要素は、チャート化データにおいて指定された、患者識別子、ヘルスケア提供者識別子、医療デバイス識別子、患者の移送を示すタイムスタンプ、患者処置情報、患者医療情報、患者人口統計学情報、及び生理学測定値を含むことができる。ケースファイルに関連付けられている他のパラメータは、ケースファイルにおいて指定された医療デバイスによって取得された、患者識別子、ヘルスケア提供者識別子、医療デバイス識別子、患者の移送を示すタイムスタンプ、患者処置情報、患者医療情報、患者人口統計学情報、及び生理学測定値を含むことができる。患者識別子は、生体情報（例えば、顔認識情報、指紋情報、網膜スキャン情報等）を含むことができる。医療デバイス識別子は、ｅＰＣＲに手動で入力された識別子、医療デバイスのメモリから索出された識別子、医療デバイスによってモバイルコンピューティングデバイスに電子的に送信された識別子、及び／又は医療デバイスに関連付けられているバー若しくはクイックレスポンスコードからスキャンされた識別子を含むことができる。生理学測定値は、他の生理学データの中でも、血圧、体温、呼吸数、心拍数、及び心電図（ＥＣＧ）データを含むことができる。

【0186】

プロセス５００ａを続けると、患者エンカウンタデータソース統合サービスは、少なくとも１つの検索基準に合致する又はそれを満たすケースファイルについてケースデータを検索する（５０６ａ）。この検索（５０６ａ）中、患者エンカウンタデータソース統合サービスは、少なくとも１つの検索基準に基づいて関連付け情報と関連付けるためにケースファイルを識別することができる（５０８ａ）。例えば、患者エンカウンタデータソース統合サービスは、ケースデータに格納されている、ケースファイルに関連付けられているパラメータが、少なくとも１つの検索基準において格納されている関連付け情報の要素と予め定められた関係を満たす場合、ケースファイルを対応するケースファイルとして識別することができる（５０８ａ）。

【0187】

患者エンカウンタデータソース統合サービスが対応するケースデータの関連付けを識別する（５０８ａ）場合、患者エンカウンタデータソース統合サービスは、後続の処理のために、複数の医療デバイスケースファイルからの（リアルタイムでストリーミングされていてもよい）ケースデータを含む統合データソースエンカウンタ構造体を格納し（５１０ａ）、プロセス５００ａは終了する。統合データソースエンカウンタ構造体は、例えば、複数の医療デバイスケースファイル、複数の医療デバイスケースファイルから生成されたケースデータ、及び／又は、関連付け情報を含む若しくはそれに関連付けられているチャート化データ及び／又はイベントログデータのうちの１又は複数の、コピー又はそれに対するポインタを含むことができる。上で説明したように、関連付け情報は、関連付け情報とチャート化データ及び／又はイベントログデータとの両方を生成するために使用されたモバイルデバイスの識別子を介して、チャート化データ及び／又はイベントログデータに関連付けることができる。さらに、いくつかの例において、統合データソースエンカウンタ構造体は、関連付けられた複数の医療デバイスケースファイルからインポートされたケースデータを含む補完ｅＰＣＲ又はイベントログを含むことができる。統合データソースエンカウンタ構造体は、例えば、チャート化データストア、イベントログデータストア、及び／又はケースデータストアに格納することができる。

【0188】

図５Ｂは、患者エンカウンタデータソース統合サービス１３０によって実行される、関連付け情報に含まれている医療デバイス識別子と合致する（例えば、正確に又は厳密に合致する）医療デバイス識別子を含む１又は複数の医療デバイスケースファイルを識別する統合プロセス５００ｂの一例を示している。

【0189】

図５Ｂに示されているように、プロセス５００ｂは、患者エンカウンタデータソース統合サービス１３０が、モバイルコンピューティングデバイス１０４によってアップロードされた関連付け情報を受信すること（５０２ｂ）で開始する。患者エンカウンタデータソース統合サービス１３０は、図５Ａを参照しながら上で説明したプロセス５００ａ内で、受信する（５０２ａ）ために患者エンカウンタデータソース統合サービス１３０によって実行されるもの等のアクションを実行することによって、プロセス５００ｂ内で受信することができる（５０２ｂ）。

【0190】

患者エンカウンタデータソース統合サービス１３０は、関連付け情報に含まれている医療デバイス識別子が、１又は複数の医療デバイスケースファイルに含まれている医療デバイス識別子と合致する（例えば、正確に又は厳密に合致する）ことを指定する少なくとも１つの検索基準を生成する（５０４ｂ）。医療デバイス識別子は、例えば、ＲＦＩＤタグ、バーコード、又はＱＲコードからの情報を含んでよい。医療デバイス識別子は、ｅＰＣＲに手動で入力された識別子、医療デバイスのメモリから索出された識別子、医療デバイスによってチャート化デバイスに電子的に送信された識別子、及び／又は医療デバイスに関連付けられているバー若しくはＱＲコードからスキャンされた識別子を含むことができる。

【0191】

プロセス５００ｂを続けると、患者エンカウンタデータソース統合サービス１３０は、少なくとも１つの検索基準を満たすケースファイルを検索する（５０６ｂ）。特に、患者エンカウンタデータソース統合サービス１３０は、関連付け情報に含まれている医療デバイス識別子と合致する（例えば、正確に又は厳密に合致する）医療デバイス識別子を含む医療デバイスケースファイルについて検索する。患者エンカウンタデータソース統合サービス１３０が、少なくとも１つの検索基準に基づいて医療デバイス識別子を含む１又は複数のケースファイルを識別する（５０８ｂ）場合、患者エンカウンタデータソース統合サービス１３０は、ケースデータを含む統合データソースエンカウンタ構造体を格納し（５１０ｂ）、プロセス５００ｂが終了する。患者エンカウンタデータソース統合サービス１３０は、図５Ａを参照しながら上で説明したプロセス５００ａ内で、格納する（５１０ａ）ために患者エンカウンタデータソース統合サービス１３０によって実行されるもの等のアクションを実行することによって、プロセス５００ｂ内で格納することができる（５１０ｂ）。

【0192】

患者エンカウンタデータソース統合サービス１３０によって実行される統合プロセスの別の例は、関連付け情報に含まれているケース開始時間及び／又はケース終了時間に合致する（例えば、正確に又は厳密に合致する）ケース開始時間及び／又はケース終了時間を含む医療デバイスケースファイルを識別する。本明細書において使用されるとき、医療デバイスケースファイルからのケース開始時間及び／又は終了時間が関連付け情報に含まれているケース開始時間及び／又は終了時間と合致することは、ターゲット時間範囲内の時間を含むことができる。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。例えば、関連付け情報が１０：００ａｍのケース開始時間及び１０：１５ａｍのケース終了時間を示す場合、ターゲット時間範囲は、９：５５ａｍ～１０：２０ａｍ、９：５５ａｍ～１０：１６ａｍ、９：５９ａｍ～１０：２０ａｍ、１０：０１ａｍ～１０：１５ａｍ、１０：００ａｍ～１０：１４ａｍ、又は任意の他の好適な範囲であってよい。こうして、ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでないことが理解される。通常、異なる医療デバイス間のクロックは、互いに正確に同期されていない場合がある。いくつかの実施形態において、ケース開始時間／終了時間は、医療デバイスケースファイルと関連付け情報との間で正確に合致する。例示的なプロセスにおいて、患者エンカウンタデータソース統合サービス１３０は、チャート化データに含まれているケース開始時間及び／又はケース終了時間が、医療デバイスケースファイルに含まれているケース開始時間及び／又はケース終了時間と合致する（例えば、正確に又は厳密に合致する）ことを指定する少なくとも１つの検索基準を生成する。例えば、１つの実装において、関連付け情報に含まれているケース開始時間は、所与の医療デバイスケースファイルに含まれているケース開始時間と合致する。別の実装において、関連付け情報に含まれているケース終了時間は、所与の医療デバイスケースファイルに含まれているケース終了時間と合致する。別の実装において、（ａ）関連付け情報に含まれているケース開始時間が、所与の医療デバイスケースファイルに含まれているケース開始時間と合致し、（ｂ）関連付け情報に含まれているケース終了時間が、所与の医療デバイスケースファイルに含まれているケース終了時間と合致する。患者エンカウンタデータソース統合サービス１３０は、次に、少なくとも１つの検索基準を満たす１又は複数のケースファイルについてケースデータを検索する。特に、患者エンカウンタデータソース統合サービス１３０は、関連付け情報に含まれているケース開始時間及び／又はケース終了時間と合致するケース開始時間及び／又はケース終了時間を含む１又は複数の医療デバイスケースファイルについて検索する。患者エンカウンタデータソース統合サービス１３０が、少なくとも１つの検索基準に基づいて関連付け情報と関連付けるために１又は複数のケースファイルを識別する場合、患者エンカウンタデータソース統合サービス１３０は、例えば、図５Ａを参照しながら上で説明したプロセス５００ａ内で格納する（５１０ａ）ために患者エンカウンタデータソース統合サービス１３０によって実行されるもの等のアクションを実行することによって、統合データソースエンカウンタ構造体を格納する。

【0193】

図５Ｃは、患者エンカウンタデータソース統合サービス１３０によって実行される、関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義された「ターゲット時間範囲」内にあるケース開始時間及び／又はケース終了時間を含む１又は複数の医療デバイスケースファイルを識別する、統合プロセス５００ｃの一例を示している。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。例えば、関連付け情報が１０：００ａｍのケース開始時間及び１０：１５ａｍのケース終了時間を示す場合、ターゲット時間範囲は、９：５５ａｍ～１０：２０ａｍ、９：５５ａｍ～１０：１６ａｍ、９：５９ａｍ～１０：２０ａｍ、１０：０１ａｍ～１０：１５ａｍ、１０：００ａｍ～１０：１４ａｍ、又は任意の他の好適な範囲であってよい。こうして、ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでないことが理解される。

【0194】

図５Ｃに示されているように、プロセス５００ｃは、患者エンカウンタデータソース統合サービス１３０が、モバイルコンピューティングデバイス１０４によってアップロードされた関連付け情報を受信すること（５０２ｃ）で開始する。患者エンカウンタデータソース統合サービス１３０は、図５Ａを参照しながら上で説明したプロセス５００ａ内で、受信する（５０２ａ）ために患者エンカウンタデータソース統合サービス１３０によって実行されるもの等のアクションを実行することによって、プロセス５００ｃ内で受信することができる（５０２ｃ）。

【0195】

患者エンカウンタデータソース統合サービス１３０は、１又は複数の医療デバイスケースファイルに含まれているケース開始時間及びケース終了時間がターゲット時間範囲内にあることを指定する少なくとも１つの検索基準を生成する（５０４ｃ）。上で述べられたように、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義される。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。

【0196】

プロセス５００ｃを続けると、患者エンカウンタデータソース統合サービス１３０は、少なくとも１つの検索基準を満たす１又は複数のケースファイルについて検索する（５０６ｃ）。特に、患者エンカウンタデータソース統合サービス１３０は、指定されたターゲット時間範囲内にあるケース開始時間及びケース終了時間を含む１又は複数の医療デバイスケースファイルについて検索する。例えば、１つの実装において、患者エンカウンタデータソース統合サービス１３０は、関連付け情報内にある関係するタイムスタンプに基づいてターゲット時間範囲を定義することによって、少なくとも１つの検索基準を生成する（５０４ｃ）。別の実装において、患者エンカウンタデータソース統合サービス１３０は、関連付け情報内の関係するタイムスタンプに基づいてターゲット時間範囲を定義するとともに、ターゲット範囲の開始時間及び／又はターゲット範囲の終了時間に好適な閾値近接性を適用することによって、少なくとも１つの検索基準を生成する（５０４ｃ）。このように、ターゲット時間範囲は、必ずしも関連付け情報に含まれている開始時間及び終了時間によって定義されない。患者エンカウンタデータソース統合サービス１３０が少なくとも１つの検索基準に基づいて関連付け情報と関連付けるために１又は複数のケースファイルを識別する（５０８ｃ）場合、患者エンカウンタデータソース統合サービス１３０は、統合データソースエンカウンタ構造体を格納し（５１０ｃ）、プロセス５００ｃが終了する。患者エンカウンタデータソース統合サービス１３０は、図５Ａを参照しながら上で説明したプロセス５００ａ内で、格納する（５１０ａ）ために患者エンカウンタデータソース統合サービス１３０によって実行されるもの等のアクションを実行することによって、プロセス５００ｃ内で格納することができる（５１０ｃ）。

【0197】

図５Ｄは、患者エンカウンタデータソース統合サービス１３０によって実行される、（ａ）関連付け情報に含まれている医療デバイス識別子に合致する（例えば、正確に又は厳密に合致する）医療デバイス識別子と、（ｂ）関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義される「ターゲット時間範囲」内にあるケース開始時間及びケース終了時間とを含む１又は複数の医療デバイスケースファイルを識別する、統合プロセス５００ｄの一例を示している。上で述べたように、いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、図５Ａ～図５Ｃ関して前に議論したように、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでない。

【0198】

図５Ｄに示されているように、プロセス５００ｄは、患者エンカウンタデータソース統合サービス１３０が、モバイルコンピューティングデバイス１０４によってアップロードされた関連付け情報を受信すること（５０２ｄ）で開始する。患者エンカウンタデータソース統合サービス１３０は、図５Ａを参照しながら上で説明したプロセス５００ａ内で、受信する（５０２ａ）ために患者エンカウンタデータソース統合サービス１３０によって実行されるもの等のアクションを実行することによって、プロセス５００ｄ内で受信することができる（５０２ｄ）。

【0199】

患者エンカウンタデータソース統合サービス１３０は、（ａ）関連付け情報に含まれている医療デバイス識別子が、１又は複数の医療デバイスケースファイルに含まれている医療デバイス識別子と合致する（例えば、正確に又は厳密に合致する）ことと、（ｂ）１又は複数の医療デバイスケースファイルに含まれているケース開始時間及びケース終了時間が、ターゲット時間範囲内にあることとを指定する少なくとも１つの検索基準を生成する（５０４ｄ）。上で述べたように、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義される。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。

【0200】

プロセス５００ｄを続けると、患者エンカウンタデータソース統合サービス１３０は、少なくとも１つの検索基準を満たす１又は複数のケースファイルについて検索する（５０６ｄ）。特に、患者エンカウンタデータソース統合サービス１３０は、（ａ）関連付け情報に含まれている医療デバイス識別子と合致する（例えば、正確に又は厳密に合致する）医療デバイス識別子と、（ｂ）指定された時間範囲内にあるケース開始時間及びケース終了時間とを含む１又は複数の医療デバイスケースファイルについて検索する。患者エンカウンタデータソース統合サービス１３０が少なくとも１つの検索基準に基づいて関連付け情報と関連付けるためにケースファイルを識別する（５０８ｄ）場合、患者エンカウンタデータソース統合サービス１３０は、統合データソースエンカウンタ構造体を格納し（５１０ｄ）、プロセス５００ｄが終了する。患者エンカウンタデータソース統合サービス１３０は、図５Ａを参照しながら上で説明したプロセス５００ａ内で、格納する（５１０ａ）ために患者エンカウンタデータソース統合サービス１３０によって実行されるもの等のアクションを実行することによって、プロセス５００ｄ内で格納することができる（５１０ｄ）。

【0201】

上で述べたように、検索基準は、医療デバイスケースファイル間の少なくとも１つの関係を指定し、統合データソースエンカウンタ構造体に統合されることになるデータを有する医療デバイスケースファイルのうちの１又は複数の識別を可能にする。図５Ｂ～図５Ｄは、例示的なファイル統合プロセスを示しており、そのそれぞれは、１又は複数の医療デバイスケースファイルについて検索して識別するために１又は複数の検索基準を使用する。これらの及び他の実装において、以下のうちの１又は複数を含む他の検索基準を使用することができる：（ｉ）医療デバイスケースファイルに含まれているケース開始時間が関連付け情報に含まれているケース開始時間の閾値近接性内にあることを指定する検索基準、（ｉｉ）医療デバイスケースファイルに含まれているケース終了時間が関連付け情報に含まれているケース終了時間の閾値近接性内にあることを指定する検索基準、（ｉｉｉ）医療デバイスケースファイルに含まれているケース開始時間及び終了時間が両方ともターゲット時間範囲内にあることを指定する検索基準、ここで、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する、並びに、（ｉｖ）医療デバイスケースファイルに含まれているケース開始時間及び終了時間が両方ともターゲット時間範囲内にあることを指定する検索基準、ここで、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間の前の指定された期間で開始し、関連付け情報に含まれているケース終了時間の後の指定された期間で終了する。検索基準が、関連付け情報に含まれているタイムスタンプを医療デバイスケースファイルに含まれているタイムスタンプと比較することに依存する実装において、関連付け情報内のタイムスタンプ及び医療デバイスケースファイル内のタイムスタンプが基づく異なる時刻系を考慮するように、任意選択の調整を含めることができる。そのような異なる時刻系は、異なるタイムゾーンの使用又は日光節約時間の使用の結果であり得る。

【0202】

図５Ｂ、図５Ｃ及び図５Ｄにおいて説明された様々な検索基準及び方法は、様々な機器構成及び能力に依存し得る。これらの構成及び能力は、ケース開始時間、ケース終了時間、及び／又は医療デバイス識別子が統合データソースエンカウンタ構造体に記録される方式を決定してよい。例えば、これらの値は、自動的に記録されるか又は手動で入力若しくはトリガされてよい。さらに、これらの構成及び能力は、ケース開始時間、ケース終了時間、及び／又は医療デバイス識別子のうちの１又は複数が検索基準として利用可能であるか否かを決定してよい。例えば、ケース開始時間、ケース終了時間、及び／又は医療デバイス識別子のうちの１又は複数を自動的に記録又は誘発する能力を欠くシステムにおいて、これらの値のうちの１又は複数は、検索基準としての使用に利用不可能であってよい。最後に、これらの構成及び能力は、ケース開始時間、ケース終了時間、及び／又は医療デバイス識別子の、検索基準としての相対的信頼性又は精度を決定してよい。例えば、自動的に記録された値は、手動で入力された値よりも正確で信頼できるとされてよい。

【0203】

関連付け情報は、ケース開始時間及びケース終了時間を含んでよい。これらの時間は、例えば、患者チャート化ファイル又はイベントログに自動的に記録されてよい。一実装において、これらの時間は、モバイルコンピューティングデバイス１０４上の時刻に対応してよい。例えば、ケース開始時間は、患者チャート化アプリケーション又はイベントログアプリケーションが新たなチャート化ファイルを開いて開始する時刻であってよく、ケース終了時間は、患者チャート化アプリケーション又はイベントログアプリケーションがチャート化ファイルを閉じる時刻であってよい。別の例として、患者チャート化アプリケーション又はイベントログアプリケーションは、コンピュータ支援ディスパッチ（ＣＡＤ）又は他のディスパッチサーバ若しくはデバイスからモバイルコンピューティングデバイス１０４に送信されたケース開始時間を受信し、この時間を患者チャート化ファイル又はイベントログに記録してよく、これは、関連付け情報の一部として含まれてよい。このケース開始時間は、このケースがＥＭＳクルーにアサインされたときの、ＣＡＤ又はディスパッチサーバ若しくはデバイスにおける時刻に対応してよい。さらなる例として、この時間は、ＥＭＳクルーがＣＡＤ又は他のディスパッチサーバ若しくはデバイスからのケースアサインメントを承諾したモバイルコンピューティングデバイス１０４上での時刻に対応してよい。このシナリオにおいて、モバイルコンピューティングデバイス１０４は、ケースアサインメントを表示し、ユーザに承諾を促し、承諾時間を患者チャート化ファイル又はイベントログにおけるケース開始時間として自動的に記録してよい。いくつかの実施形態において、ケース開始時間は、ユーザが医療イベントに関連付けられている医療デバイスのうちの１又は複数でケースファイルをアクティベート及び／又は開始した時間に対応してよい。さらに別の例として、モバイルコンピューティングデバイス１０４は、患者輸送先において（例えば、ＷＩＦＩ若しくはＢＬＵＥＴＯＯＴＨ又は輸送先において開始された他の通信結合に基づいて）時間を受信し、この受信された時間をケース終了時間として自動的に記録してよい。またさらなる例として、モバイルコンピューティングデバイス１０４は、チャート化データストア１３４に及び／又はリモートコンピューティングデバイス１０６（例えば、病院サーバ又は患者輸送先における他のコンピューティングデバイス）にケースファイルを送信してよく、モバイルコンピューティングデバイス１０４は、この送信の時間をケース終了時間として記録してよい。

【0204】

一実装において、モバイルコンピューティングデバイス１０４は、モバイルコンピューティングデバイス１０４上のジオフェンシングアプリケーションからケース開始時間及び／又はケース終了時間を受信して自動的に記録してよい。例えば、ジオフェンシングアプリケーションは、モバイルコンピューティングデバイス１０４がＥＭＳエージェンシロケーションの周囲の又は患者のロケーションの周囲のジオフェンスを横切ることに基づいて、ケース開始時間をモバイルコンピューティングデバイス１０４に提供してよい。別の例として、ジオフェンシングアプリケーションは、モバイルコンピューティングデバイス１０４が患者のロケーションの周囲又は患者輸送先（例えば、病院、医院、透析センタ、精神病センタ、又は他のケア提供者ロケーション）の周囲のジオフェンスを横切ることに基づいて、ケース終了時間をモバイルコンピューティングデバイス１０４に提供してよい。同様に、モバイルコンピューティングデバイス１０４は、モバイルコンピューティングデバイス１０４の１又は複数のＧＰＳ座標に基づいて、ケース開始時間及び／又はケース終了時間を受信して自動的に記録してよい。

【0205】

いくつかの実装において、ケース開始時間は、処置の時間（例えば、除細動ショック、薬剤、又は他の治療が医療デバイスによって患者に送達された時間）であってよい。医療デバイスは、デバイスが治療を提供した時間を（例えば、タイムスタンプが付与されたイベントマーカとして）記録もする。こうして、「ケース開始時間」間の相関は、関連付け情報内に及び医療デバイスケースファイル内に記録されている治療送達時間の間の相関を含んでよい。関連付け情報は、医療デバイスからこの情報を（例えば、送信された情報として）受信してよい、又は、この情報を関連付け情報への入力を介して受信してよい。

【0206】

一実装において、モバイルコンピューティングデバイス１０４は、ｅＰＣＲアプリケーション１２２又はイベントログアプリケーション１４０においてケース開始時間及び／又はケース終了時間を入力又は確認することをユーザに促してよい。モバイルコンピューティングデバイス１０４は、このユーザが入力した又は確認した時間を関連付け情報に記録してよい。この場合、記録時間は、ユーザによって確認されたモバイルコンピューティングデバイス１０４上の時刻であってよい、又は、腕時計若しくはモバイルコンピューティングデバイス１０４とは別個の他の時間ソースから収集され、ユーザによって関連付け情報に入力された時間であってよい。

【0207】

本明細書において議論されるようなケース時間及び関連付け情報に対する他の入力について、これらの入力は、（例えば、キーボードを介した）手動入力、（例えば、マイクロフォン及びモバイルコンピューティングデバイス１０４における音声認識機能を介した）音声入力、拡張現実デバイスを介して捕捉された入力、及び／又は、モバイルコンピューティングデバイス１０４若しくはサーバ１０８のいずれかと通信するウェアラブルデバイスにおいて捕捉された入力であってよい。

【0208】

いくつかのシナリオにおいて、ケース終了時間は、ＥＭＳのケアからの患者の実際の解放から遅れてもよい。例えば、ＥＭＳクルーは、患者を病院に輸送し、患者を病院に送り出し、次に、患者チャートの完成に進んでよい。この遅れ時間は、ＥＭＳクルーが、患者ケア中に、患者ケアから患者チャート化のタスクに注意を移す時間がないので患者チャート化を完成させる時間がない場合に、運用上必然であり得る。こうして、モバイルコンピューティングデバイス１０４と医療デバイス１０２Ａ～１０２Ｎとの間に、これらのデバイス間でファイルを転送するのに十分な帯域幅及び信号強度を伴う通信結合が存在する場合であっても、関連付け情報は、イベント後の或る時間まで完成されない場合があるので、ファイル関連付けは、依然としてクラウド上で発生する必要があり得る。この時間において、関係する医療デバイスは、再配置されるか又は電源オフされてよい。さらに、いくつかの場合において、プライバシー及びデータ保護の理由で、ケア提供者は、医療デバイスからモバイルコンピューティングデバイスへのファイル転送を手動で開始又は確認しなければならない。ケア提供者がこの転送を開始するのを忘れた場合、ファイル関連付けは、デバイスツーデバイス転送に基づいてではなく、依然としてクラウドにおいて発生することができる。さらに、医療デバイス、患者チャート化アプリケーション、及び／又はイベントログアプリケーションは、異なるベンダからのものであってよく、ファイルフォーマットに関して互いに互換性がなくてもよい。したがって、利用可能な通信チャネルがあっても、適切なソフトウェア開発キット（ＳＤＫ）が存在しない場合、これらのデバイス間のファイル転送は、可能でない場合があり、本明細書において説明されるようにクラウドにおけるファイル関連付けを要求し得る。

【0209】

ケース終了時間は、関連付け情報の完了又はユーザによって入力された時間に対応してよい。様々な実装において、関連付け情報内のケース開始時間は、ケア提供者が患者シーンに到着した時間（例えば、「患者側時間」）であってよく、ケース終了時間は、患者がＥＭＳのケアから解放された時間（例えば、「患者ケア移行時間」）であってよい。ケア提供者が患者シーンに到着した時間は、医療デバイスを患者に対する使用のために展開及び／又はアクティベートすることができる最も早い時間であり得る。したがって、この時間は、関係するケース開始時間であってよい。同様に患者ケアがＥＭＳから離れるように移送される時間は、医療デバイスを患者から取り外す及び／又はディアクティベートすることができる最も遅い時刻である。いくつかの実施形態において、ケース終了時間は、ユーザが医療イベントに関連付けられている医療デバイスのうちの１又は複数で現在のケースファイルをディアクティベート及び／又は閉じる時間に対応してよい。通常、病院等の輸送先に到着すると、患者は、ＥＭＳエージェンシに属する医療デバイスから、病院に属する医療デバイスへと移行される。

【0210】

患者のケア中、ＥＭＳクルーは、患者を１又は複数の医療デバイスに結合してよい。医療デバイスは、ケース開始時間又はケース終了時間を、電源オン若しくは電源オフ時間として、又は、患者インタフェースデバイスが患者に結合された若しくは患者から取り外された時間として自動的に記録してよい。医療デバイスは、患者からの生理学信号の存在若しくは不存在に基づいて、又は、患者接続（例えば、患者への電極のペアの適切な取り付けに基づく閉回路）を示すセンサ信号に基づいて、又は、患者インタフェースデバイスがパッケージから取り出されている若しくは別様に展開されていることを示すセンサ信号に基づいて、この結合又は取り外しを認識してよい。一実装において、医療デバイス及びモバイルコンピューティングデバイスは、通信可能に結合してよく、１又は複数の両方のデバイスは、通信の開始に関連付けられている時間に基づいて、ケース開始時間及び／又はケース終了時間を記録してよい。一実装において、医療デバイスは、ケース開始時間又はケース終了時間のユーザ入力又は確認を要求してよい。

【0211】

一実装において、医療デバイス１０２Ａ～１０２Ｎは、デバイス識別子を医療デバイスケースファイルに自動的に記録してよい。例えば、このデバイス識別子は、医療デバイスケースファイルとともにメタデータとして含まれている、特定の医療デバイスに対しての一意のコード（例えば、シリアルナンバ及び／又は型番及び／又は他の識別情報）であってよい。一実装において、医療デバイス１０２Ａ～１０２Ｎは、モバイルコンピューティングデバイス１０４と通信可能に結合し、医療デバイス識別子をモバイルコンピューティングデバイス１０４に送信してよい。モバイルコンピューティングデバイス１０４は、この識別子を関連付け情報に自動的に記録してよい。一実装において、医療デバイス１０２Ａ～１０２Ｎは、医療デバイス識別子を、外側ハウジング上に、例えば付けられたタグ若しくはステッカー上に、又は、エンボス加工若しくはエングレーブ加工されたコードとして、含んでよい。ケア提供者は、このコードを視覚的に検査し、このコードをｅＰＣＲアプリケーション１２２又はイベントログアプリケーション１４０において手動で入力してよい。代替的には、ケア提供者は、カメラ又は他の視覚的記録デバイスを使用してこのコードを捕捉し、捕捉されたコードを関連付け情報における記録のためにモバイルコンピューティングデバイス１０４に送信してよい。別のオプションとして、医療デバイス識別子は、バーコード又はＱＲコードであってよく、ケア提供者は、スキャナを使用してこのコードを捕捉し、捕捉されたコードを関連付け情報における記録のためにモバイルコンピューティングデバイス１０４に送信してよい。一実装において、モバイルコンピューティングデバイス１０４は、カメラ及び／又はスキャナを含んでよい。さらなるオプションとして、ケア提供者は、コードを読んで音声化してよく、モバイルコンピューティングデバイス１０４は、可聴情報を捕捉して、このコードを関連付け情報に自動的に記録するように構成されているマイクロフォンを含んでよい。一実装において、特定の医療デバイスは、特定のＥＭＳクルー及び／又はＥＭＳ車両に関連付けられてよい。このような一実装において、ケア提供者は、クルー又は車両の識別を関連付け情報に提供してよく、モバイルコンピューティングデバイス１０４は、クルー又は車両の識別に基づいて、医療デバイス識別子を関連付け情報と関連付けるために、ルックアップテーブル又は他のリファレンスを参照してよい。

【0212】

モバイルコンピューティングデバイス１０４及び医療デバイス１０２Ａ～１０２Ｎ上の時間記録の様々な可能なモードを前提とすると、関連付け情報及び医療デバイスケースファイル内の時間の間の任意の相関又は合致の信頼性及び精度は、各デバイスがこれらの時間をどのように記録しているかに応じて異なる程度に変化し得る。同様に、モバイルコンピューティングデバイス１０４による医療デバイス識別子の捕捉及び記録の様々な可能なモードは、関連付け情報内の及び医療デバイスケースファイル内の情報間の任意の相関又は合致の信頼性及び精度を決定し得る。したがって、システムは、ファイル関連付けの検索基準として、図５Ｂ、図５Ｃ及び図５Ｄに例示されているように、これらの基準のうちの一方若しくは他方又は両方を使用してよい。

【0213】

これらの基準の両方の使用は、除細動器、自動化圧迫デバイス、人工呼吸器等のような１若しくは少数の医療デバイスのみを所有する及び／又は（例えば、２つの同時の緊急事態又はスケジュールされた輸送のために）同時に展開されている１若しくは少数の医療デバイスのみを有する小規模ＥＭＳエージェンシにとって、必要でなくてよい。この場合、時間は、医療デバイスケースファイル及び関連付け情報を関連付けるのに十分であり得る。しかしながら、主要なメトロポリタンエリアにおけるエージェンシ等の大規模ＥＭＳエージェンシについて、エージェンシは、１００～２００の医療デバイスを所有する場合があり、１０～２０の同時展開を有し得る。この場合、時間は不十分であり得、ファイル関連付けの精度のために時間とともに医療デバイス識別子が必要とされ得る。この状況は、特に、患者の間で時間が実質的に重複し、医療デバイス識別子のタイムリーな記録に関して現場で混乱が発生し得る、多数傷病者状況に当てはまり得る。したがって、この場合、検索基準は、信頼できる正確なファイル関連付けのためのいくつかのパラメータを要求し得る。複数又は多数傷病者状況は、モバイルコンピューティングデバイス１０４と医療デバイス１０２Ａ～１０２Ｎとの間に、これらのデバイス間でファイルを転送するのに十分な帯域幅及び信号強度を有しない通信結合が存在しない場合であっても、クラウドにおけるファイル関連付けの発生が必要とされ得る状況の別の例も提供する。例えば、ＷＩＦＩ又はセルラ等の長距離通信結合が利用不可能である場合（例えば、屋内空間、パーキングガレージ、アーバンキャニオン、リモートロケーション等において）、デバイスは、ＢＬＵＥＴＯＯＴＨ等の近距離接続を介してのみ通信可能であり得る。しかしながら、互いの近距離通信距離内にある複数のデバイスは、医療デバイスとモバイルコンピューティングデバイスとの間でのファイルの自動転送を可能にする検出能力に干渉し得る。

【0214】

図６は、いくつかの実装における、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）によって実行される関連付けプロセス６００の１つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び／又は呼び出し側プロセス（例えば、図１のｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４）からの要求に応答して、プロセス６００を実行するように構成することができる。

【0215】

図６に示されているように、プロセス６００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（６０２）ことで開始する。この関連付け情報は、呼び出し側プロセスからのメッセージに含まれているか、又は、周期タイマの満了に応答して患者エンカウンタデータソース統合サービスによって処理されるチャート化データ若しくはイベントログデータとともに格納されてよい。関連付け情報を受信した（６０２）後、患者エンカウンタデータソース統合サービスは、関連付け情報に基づいて少なくとも１つの検索基準を生成し（６０４）、少なくとも１つの検索基準と合致する若しくはそれを満たす１又は複数のケースファイルについて、ケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを検索する（６０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索する（５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス６００内で受信し（６０２）、生成し（６０４）、検索する（６０６）ことができる。

【0216】

次に、患者エンカウンタデータソース統合サービスは、少なくとも１つの対応するケースファイルが検索（６０６）によって識別されたか否かを決定する（６０８）。患者エンカウンタデータソース統合サービスが、少なくとも１つの対応するケースファイルが発見されなかったと決定する（６０８）場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを生成して呼び出し側プロセスに戻し（６１２）、プロセス６００が終了する。患者エンカウンタデータソース統合サービスが、少なくとも１つの対応するケースファイルが発見されたと決定する（６０８）場合、患者エンカウンタデータソース統合サービスは、その少なくとも１つの対応するケースファイル又はその少なくとも１つの識別子を含むメッセージを呼び出し側プロセスに戻し（６１０）、プロセス６００が終了する。

【0217】

図７は、いくつかの実装における、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）によって実行される関連付けプロセス７００の１つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び／又は呼び出し側プロセス（例えば、図１のｅＰＣＲ ＡＰＩ１２８）からの要求に応答して、プロセス７００を実行するように構成することができる。

【0218】

図７に示されているように、プロセス７００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（７０２）ことで開始する。この関連付け情報は、呼び出し側プロセスからのメッセージに含まれているか、又は、周期タイマの満了に応答して患者エンカウンタデータソース統合サービスによって処理されるチャート化データ若しくはイベントログデータとともに格納されてよい。関連付け情報を受信した（７０２）後、患者エンカウンタデータソース統合サービスは、関連付け情報に基づいて少なくとも１つの検索基準を生成し（７０４）、少なくとも１つの検索基準と合致する若しくはそれを満たす１又は複数のケースファイルについて、ケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを検索する（７０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索する（５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス７００内で受信し（７０２）、生成し（７０４）、検索する（７０６）ことができる。

【0219】

次に、患者エンカウンタデータソース統合サービスは、少なくとも１つの対応するケースファイルが検索（７０６）によって識別されたか否かを決定する（７０８）。患者エンカウンタデータソース統合サービスが、少なくとも１つの合致が発見されなかったと決定する（７０８）場合、患者エンカウンタデータソース統合サービスは、タイマ（例えば、上で説明したイベントトリガ周期タイマ）をリセットし（７１４）、対応するケースファイルが発見されなかったことを示す戻りメッセージを呼び出し側プロセスに送信する（７１６）。患者エンカウンタデータソース統合サービスが、少なくとも１つの対応するケースファイルが発見されたと決定する（７０８）場合、患者エンカウンタデータソース統合サービスは、その少なくとも１つの対応するケースファイル又はその少なくとも１つの識別子を呼び出し側プロセスに戻し（７１０）、処理７００が終了する。

【0220】

図８は、いくつかの実装において、複数の医療デバイス、患者エンカウンタデータソース統合サービス、及びモバイルコンピューティングデバイス（例えば、図１の医療デバイス１０２、患者エンカウンタデータソース統合サービス１３０、及びモバイルコンピューティングデバイス１０４）によって実行される集約プロセス８００の１つの例を示している。図８に示されているように、破線の境界でレンダリングされた操作は、いくつかの例において存在しない場合がある。

【0221】

プロセス８００内で、モバイルコンピューティングデバイスは、要求メッセージを患者エンカウンタデータソース統合サービスに送信する（８０２）。この要求メッセージは、複数の医療デバイスケースファイルからのケースデータ（例えば、医療デバイスケースファイル又はその一部）を互いに関連付ける要求を含むことができる。要求メッセージは、少なくとも１つの検索基準を開発するために使用されることになる関連付け情報及び／又はそのような関連付け情報の識別子（例えば、図１のチャート化データストア１３４及び／又はイベントログデータストア１４６等のチャート化データストア及び／又はイベントログデータストア内の関連付け情報を包含するチャート化データ及び／又はイベントログデータの識別子）を含むことができる。いくつかの例において、モバイルコンピューティングデバイスは、サーバ（例えば、図１のサーバ１０８のうちのサーバ）によって実装されるｅＰＣＲインタフェース及び／又はイベントログインタフェース（例えば、図１のｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４）への１又は複数のメッセージを介して、要求メッセージ及び／又は関連付け情報を患者エンカウンタデータソース統合サービスに送信することができる。代替的に又は加えて、モバイルコンピューティングデバイスは、要求メッセージを送信する（８０２）ことの一部として、ｅＰＣＲインタフェース及び／又はイベントログインタフェースを介して、チャート化データストア及び／又はイベントログデータストア内に関連付け情報を格納することができる。

【0222】

プロセス８００を続けると、患者エンカウンタデータソース統合サービスは、ｅＰＣＲインタフェース及び／又はイベントログインタフェース又はチャート化データストア及び／又はイベントログデータストアから関連付け情報を受信する（８０４）。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成する（８０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成する（５０４）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス８００内で受信し（８０４）、生成する（８０６）ことができる。

【0223】

図８に示されているように、医療デバイスは、１又は複数の要求メッセージを、サーバ（例えば、図１のサーバ１０８のうちのサーバ）によって実装されるケースインタフェース（例えば、ケースＡＰＩ１２６）に送信する（８０８）。要求メッセージは、複数のケースファイルをケースデータストア（例えば、図１のケースデータストア１３２）にインポートする１又は複数の要求を含むことができる。要求メッセージは、ケースファイルがインポートされることを含むことができる。要求メッセージを受信したことに応答して、ケースインタフェースは、ケースファイルを受信し、ケースファイルからケースデータを索出するためにケースファイルをパースし、ケースデータ及び／又はケースファイルをケースデータストアに格納し、要求メッセージを処理した結果を示す１又は複数の応答メッセージを医療デバイスに送信することができる。

【0224】

プロセス８００を続けると、患者エンカウンタデータソース統合サービスは、インポートされたケースファイルに関連付けられているケースデータを少なくとも１つの検索基準を満たすものとして識別する（８１０）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で識別する（５０８）際に患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス８００内で識別する（８１０）ことができる。患者エンカウンタデータソース統合サービスは、ケースファイルを識別する（８１０）ことの一部として、ケースファイルの１又は複数の識別子及び／又はケースファイルを記述する他のメタデータを含む確認要求をさらに生成して、モバイルコンピューティングデバイスに送信することができる。ケースファイルの１又は複数の識別子は、例えば、ケースファイルが医療デバイスによって生成されたときを示す１又は複数のタイムスタンプ、及びケースファイルを生成した医療デバイスの識別子を含むことができる。

【0225】

プロセス８００を引き続き参照すると、モバイルコンピューティングデバイスは、患者エンカウンタデータソース統合サービスからケースファイルの識別子及び／又は他のメタデータを含む確認要求を受信し（８１２）、ユーザに（例えば図１のヘルスケア提供者１１８Ａ）に、ケースファイルが同じ患者エンカウンタを記述しているか否かを確認するよう促す。いくつかの例において、モバイルコンピューティングデバイスは、識別子を使用して、ｅＰＣＲアプリケーション及び／又はイベントログアプリケーション（例えば、図１のｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０）を介してユーザを促す。図９は、ｅＰＣＲアプリケーション及び／又はイベントログアプリケーションが確認要求を受信したことに応答してレンダリングするように構成されているユーザインタフェーススクリーン９００の１つの例を示している。図９に示されているように、スクリーン９００は、ケースコントロールの列９０２及び９０４と、確認コントロール９０６の列と、提出コントロール９０８とを含む。ケースコントロール９０２及び９０４は、確認要求において識別されるケースファイルの識別子及びそれに関する情報を表示するように構成されている。より具体的には、ケースコントロール９０２のそれぞれは、ケース開始時間を表示するように構成されており、ケースコントロール９０４のそれぞれは、ケースファイルを生成した医療デバイスの識別子を表示するように構成されている。確認コントロール９０６は、確認コントロール９０６が存在する行によって識別されるケースファイルが、他のケースファイルに関連付けられること（例えば、同じ患者エンカウンタ中にそれぞれ生成されたこと）を確認したのか確認していないのかを示す入力を受けるように構成されている。提出コントロール９０８は、所望のようにユーザがケースファイルを確認したこと又は確認していないことを示す入力を受けるように構成されている。

【0226】

プロセス８００に戻ると、ｅＰＣＲアプリケーション及び／又はイベントログアプリケーションは、ケースファイルを確認する入力（例えば、提出コントロール９０８の選択）を受け、ｅＰＣＲアプリケーション及び／又はイベントログアプリケーションは、（例えば、ｅＰＣＲインタフェース及び／又はイベントログインタフェースを介して）患者エンカウンタデータソース統合サービスに確認応答を送信する（８１４）。患者エンカウンタデータソース統合サービスは、確認応答を受信する（８１６）。

【0227】

いくつかの例において、患者エンカウンタデータソース統合サービスは、関連付けられたケースファイルからのケースデータを統合データソースエンカウンタ構造体内の集約されたケースデータに集約する（８１８）。例えば、いくつかの例において、患者エンカウンタデータソース統合サービスは、関連付けられたケースファイルから発生したケースデータストアに格納されているケースデータの記録の全て又はその一部の間の関連付けを確立することによって、ケースデータを集約されたケースデータに集約する（８１８）。さらに、患者エンカウンタデータソース統合サービスは、例えば、集約されたケースデータの少なくとも一部を統合データソースエンカウンタ構造体の一部としてｅＰＣＲ及び／又はイベントログにインポートすることによって、集約されたケースデータ又はその一部をチャート化データ及び／又はイベントログデータと統合することができる。この集約は、補完ｅＰＣＲ及び／又は補完イベントログを生成する。また、患者エンカウンタデータソース統合サービスは、例えば、集約されたケースデータの少なくとも一部を１又は複数のケースファイルにインポートすることによって、集約されたケースデータ又はその一部を関連付けられたケースファイルの１又は複数のケースファイルと統合することができる。この集約は、補完ケースファイルを生成する。

【0228】

プロセス８００を続けると、患者エンカウンタデータソース統合サービスは、集約されたケースデータを格納する及び／又は医療デバイス及び／又はモバイルコンピューティングデバイスに送信する（８１９）。例えば、いくつかの例において、患者エンカウンタデータソース統合サービスは、補完ケースファイルをケースデータストアに格納する及び／又は補完ケースファイルを医療デバイスに送信する（８１９）。代替的に又は加えて、いくつかの例において、患者エンカウンタデータソース統合サービスは、補完ｅＰＣＲ及び／又は補完イベントログをチャート化データストアに格納する及び／又は補完ｅＰＣＲ及び／又は補完イベントログをモバイルコンピューティングデバイスに送信する（８１９）。

【0229】

患者エンカウンタデータソース統合サービスが補完ケースファイルを医療デバイスに送信する（８１９）場合、医療デバイスは、補完ケースファイルを受信し（８２２）、補完ケースファイルを送信する及び／又はローカルに格納する（８２４）。患者エンカウンタデータソース統合サービスが補完ｅＰＣＲ及び／又は補完イベントログをモバイルコンピューティングデバイスに送信する（８１９）場合、モバイルデバイスは、補完ｅＰＣＲ及び／又は補完イベントログを受信し（８２６）。補完ｅＰＣＲ及び／又は補完イベントログを送信する及び／又はローカルに格納する（８２８）。

【0230】

図１０は、いくつかの実装における、患者エンカウンタデータソース統合サービス及びモバイルコンピューティングデバイス（例えば、図１の患者エンカウンタデータソース統合サービス１３０及びモバイルコンピューティングデバイス１０４）によって実行される集約プロセス１０００の１つの例を示している。

【0231】

図１０に示されているように、プロセス１０００は、患者エンカウンタデータソース統合サービスが、モバイルコンピューティングデバイスから関連付け情報を受信すること（１００２）で開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成し（１００４）、少なくとも１つの検索基準に合致する若しくはそれを満たす複数の医療デバイスケースファイルについてケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを検索し（１００６）、少なくとも１つの検索基準に基づいて、医療デバイスケースファイルを互い及び特定の患者エンカウンタに関連付けられているものとして識別する（１００８）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索し（５０６）、識別する（５０８）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１０００内で受信し（１００２）、生成し（１００４）、検索し（１００６）、識別する（１００８）ことができる。

【0232】

次に、患者エンカウンタデータソース統合サービスは、識別されたケースファイルの識別子をモバイルコンピューティングデバイスに送信する（１０１０）。これらの識別子は、ケースファイルが医療デバイスによって生成されたときを示すタイムスタンプを含むことができる。いくつかの例において、患者エンカウンタデータソース統合サービスは、タイムスタンプを、モバイルデバイスによってホストされているｅＰＣＲアプリケーション及び／又はイベントログアプリケーション（例えば、図１のｅＰＣＲアプリケーション１２２及び／又はイベントログアプリケーション１４０）に送信する（１０１０）。特定の例において、モバイルコンピューティングデバイスは、患者エンカウンタデータソース統合サービスからケースファイルの識別子を受信し、ユーザ（例えば、図１のヘルスケア提供者１１８Ａ）に、ケースファイルが同じ患者エンカウンタを記述しているか否かを確認するよう促す。いくつかの例において、モバイルコンピューティングデバイスは、ｅＰＣＲアプリケーション及び／又はイベントログアプリケーションを介してユーザを促す。ｅＰＣＲアプリケーション及び／又はイベントログアプリケーションがケースファイルを確認する入力を受ける場合、ｅＰＣＲアプリケーション及び／又はイベントログアプリケーションは、（例えば、図１のｅＰＣＲインタフェース１２６及び／又はイベントログＡＰＩ１４４等のｅＰＣＲインタフェース及び／又はイベントログインタフェースを介して）確認メッセージを患者エンカウンタデータソース統合サービスに送信する。

【0233】

プロセス１０００を続けると、患者エンカウンタデータソース統合サービスは、患者モバイルコンピューティングデバイスから確認メッセージを受信し（１０１２）、確認されたケースファイルからのケースデータを含む統合データソースエンカウンタ構造体（患者エンカウンタ中に医療デバイスからリアルタイムでストリーミングされていてよい）を格納し（１０１４）、プロセス１０００が終了する。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で統合データソースエンカウンタ構造体を格納する（５１０）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１０００内で統合データソースエンカウンタ構造体を格納することができる（１０１４）。

【0234】

図１１は、いくつかの実装において、患者エンカウンタデータソース統合サービス、並びに、モバイルコンピューティングデバイスによってホストされているｅＰＣＲアプリケーション、イベントログアプリケーション、及び／又はデバイス関連付けアプリケーション（例えば、図１の患者エンカウンタデータソース統合サービス１３０、ｅＰＣＲアプリケーション１２２、イベントログアプリケーション１４０、及び／又は患者エンカウンタデバイス関連付けアプリケーション１５０、及びモバイルコンピューティングデバイス１０４）によって実行される集約プロセス１１００の１つの例を示している。

【0235】

図１１に示されているように、プロセス１１００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（１１０２）ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成し（１１０４）、少なくとも１つの検索基準に合致する若しくはそれを満たす複数の医療デバイスケースファイルについてケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを検索する（１１０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索する（５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１１００内で受信し（１１０２）、生成し（１１０４）、検索する（１１０６）ことができる。

【0236】

次に、患者エンカウンタデータソース統合サービスは、検索の結果として少なくとも１つの検索基準に合致する若しくはそれを満たす１又は複数のケースファイルの識別が得られたか否かを決定する（１１０８）。患者エンカウンタデータソース統合サービスが、対応するケースファイルが識別されなかったと決定する（１１０８）場合、プロセス１１００が終了する。患者エンカウンタデータソース統合サービスが、１又は複数の対応するケースファイルが識別されたと決定する（１１０８）場合、患者エンカウンタデータソース統合サービスは、対応するケースファイルを記述するメタデータを生成する（１１１０）。このメタデータは、他の識別子の中でも、対応するケースファイルが医療デバイスによって生成されたときを示すタイムスタンプ等の対応するケースファイルの識別子、対応するケースファイルを生成した医療デバイスの識別子、及び／又は、ケースファイルの作成中に医療デバイスと結合された１又は複数のモバイルコンピューティングデバイスの識別子を含むことができる。

【0237】

プロセス１１００を続けると、患者エンカウンタデータソース統合サービスは、ネットワーク（例えば、図１のネットワーク１１２）を介して、メタデータをｅＰＣＲアプリケーション、イベントログアプリケーション、及び／又はデバイス関連付けアプリケーションに送信する（１１１２）。いくつかの例において、患者エンカウンタデータソース統合サービスは、１又は複数のインタフェースコール（例えば、図１のｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４によってサポートされるコール）によって生成されたメッセージを介して、メタデータを送信する。これらのメッセージは、確認要求を含むことができる。

【0238】

ｅＰＣＲアプリケーション、イベントログアプリケーション、及び／又はデバイス関連付けアプリケーションは、メタデータを受信し（１１１４）、メタデータに記述された各ケースファイルのためのプロンプトをレンダリングする（１１１６）。例えば、ｅＰＣＲアプリケーション、イベントログアプリケーション、及び／又はデバイス関連付けアプリケーションは、その関連付けられたプロンプト内の各ケースファイルのためのタイムスタンプ及び／又は医療デバイス識別子をレンダリングすることができる。１又は複数のプロンプトのそれぞれは、その関連付けられたケースファイルが、関連付け情報に関連付けられているエンカウンタ中に患者（例えば、図１の患者１１６）に結合された医療デバイスの操作を記述していることを確認する入力を受けるように構成することができる。ケースファイルを確認する入力を受けたことに応答して、ｅＰＣＲアプリケーション、イベントログアプリケーション、及び／又はデバイス関連付けアプリケーションは、（例えば、ｅＰＣＲインタフェース及び／又はイベントログインタフェースを介して）確認応答を患者エンカウンタデータソース統合サービスに送信する（１１１８）。確認応答は、各確認されたケースファイルの識別子を含むことができる。

【0239】

次に、患者エンカウンタデータソース統合サービスは、確認応答を受信（１１２０）し、その中に格納されているケースファイルの識別子を索出するために確認応答をパースする。患者エンカウンタデータソース統合サービスは、ケースファイルを統合データソースエンカウンタ構造体にアタッチする及び／又は埋め込む（１１２２）。この統合データソースエンカウンタ構造体は、ｅＰＣＲ及び／又はイベントログにアタッチする及び／又は埋め込むことができる。ケースファイルは、全体的に又は部分的に埋め込む及び／又はアタッチすることができる。ケースファイルが埋め込まれる場合、ケースファイル内に格納されたケースデータは、ｅＰＣＲのフィールド及び／又はイベントログのフィールドに格納することができる。

【0240】

プロセス１１００を続けると、患者エンカウンタデータソース統合サービスは、ｅＰＣＲ、イベントログ、及び／又はアタッチされた／埋め込まれたケースデータを含む統合データソースエンカウンタ構造体をｅＰＣＲアプリケーション、イベントログアプリケーション、及び／又はデバイス関連付けアプリケーションに送信する（１１２４）。ｅＰＣＲアプリケーション、イベントログアプリケーション、及び／又はデバイス関連付けアプリケーションは、アタッチされた／埋め込まれたケースデータを伴うｅＰＣＲ、アタッチされた／埋め込まれたケースデータを伴うイベントログ、及び／又は統合データソースエンカウンタ構造体を受信し（１１２６）、ヘルスケア提供者によるレビュー及び操作のために、ｅＰＣＲ、イベントログ及び／又は統合データソースエンカウンタ構造体をレンダリングする（１１２８）。

【0241】

図１２は、いくつかの実装における、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）によって実行される関連付けプロセス１２００の１つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び／又は呼び出し側プロセス（例えば、図１のｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４）からの要求に応答して、プロセス１２００を実行するように構成することができる。

【0242】

図１２に示されているように、プロセス１２００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（１２０２）ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成し（１２０４）、少なくとも１つの検索基準に合致する若しくはそれを満たす複数の医療デバイスケースファイルについてケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを検索する（１２０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索する（５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１２００内で受信し（１２０２）、生成し（１２０４）、検索する（１２０６）ことができる。しかしながら、プロセス１２００内で、患者エンカウンタデータソース統合サービスは、関連付け情報から医療デバイス識別子のリストを指定する少なくとも１つの検索基準を生成し（１２０４）、それらの１つは、ケースファイルが対応するケースファイルであるために、ケースファイルに関連付けられている医療デバイス識別子に等しくなければならない。患者エンカウンタデータソース統合サービスは、ケースファイルを関連付けるために、この検索基準を使用して検索する（１２０６）。

【0243】

次に、患者エンカウンタデータソース統合サービスは、少なくとも１つの対応するケースファイルが検索（１２０６）によって識別されたか否かを決定する（１２０８）。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する（１２０８）場合、患者エンカウンタデータソース統合サービスは、対応するケースファイルが発見されなかったことを示すエラーメッセージを生成して呼び出し側プロセスに戻し（１２１０）、プロセス１２００が終了する。患者エンカウンタデータソース統合サービスが、少なくとも１つの対応するケースファイルが発見されたと決定する（１２０８）場合、患者エンカウンタデータソース統合サービスは、その少なくとも１つの対応するケースファイル又はその少なくとも１つの識別子を生成して呼び出し側プロセスに戻し（１２１２）、処理１２００が終了する。

【0244】

図１３は、いくつかの実装における、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）によって実行される関連付けプロセス１３００の１つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び／又は呼び出し側プロセス（例えば、図１のｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４）からの要求に応答して、プロセス１３００を実行するように構成することができる。

【0245】

図１３に示されているように、プロセス１３００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（１３０２）ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成し（１３０４）、少なくとも１つの検索基準に合致する又はそれを満たす医療デバイスケースファイルについてケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを検索する（１３０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索する（５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１３００内で受信し（１３０２）、生成し（１３０４）、検索する（１３０６）ことができる。しかしながら、プロセス１３００内で、患者エンカウンタデータソース統合サービスは、関連付け情報から医療デバイス識別子及びタイムスタンプのペアのリストを指定する少なくとも１つの検索基準を生成し（１３０４）、これらの１つは、ケースファイルが対応するケースファイルであるために、ケースファイルに関連付けられている医療デバイス識別子及びタイムスタンプのペアと等しくなければならない。患者エンカウンタデータソース統合サービスは、ケースファイルを関連付けるために、この検索基準を使用して検索する（１３０６）。

【0246】

次に、患者エンカウンタデータソース統合サービスは、１又は複数の対応するケースファイルが検索（１３０６）によって識別されたか否かを決定する（１３０８）。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する（１３０８）場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを生成して呼び出し側プロセスに戻し（１３１０）、プロセス１３００が終了する。患者エンカウンタデータソース統合サービスが、少なくとも１つの対応するケースファイルが発見されたと決定する（１３０８）場合、患者エンカウンタデータソース統合サービスは、その少なくとも１つの対応するケースファイル又はその少なくとも１つの識別子を生成して呼び出し側プロセスに戻し（１３１２）、処理１３００が終了する。

【0247】

図１４は、いくつかの実装における、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）によって実行される関連付けプロセス１４００の１つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び／又は呼び出し側プロセス（例えば、図１のｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４）からの要求に応答して、プロセス１４００を実行するように構成することができる。

【0248】

図１４に示されているように、プロセス１４００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（１４０２）ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成し（１４０４）、少なくとも１つの検索基準に合致する又はそれを満たす医療デバイスケースファイルについてケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを検索する（１４０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索する（５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１４００内で受信し（１４０２）、生成し（１４０４）、検索する（１４０６）ことができる。しかしながら、プロセス１４００内で、患者エンカウンタデータソース統合サービスは、関連付け情報から医療デバイス識別子及びタイムスタンプのペアのリストを指定する少なくとも１つの検索基準を生成する（１４０４）。少なくとも１つの検索基準において、予め定められた関係は、対応するケースファイルが、リストからの医療デバイス識別子に等しい医療デバイス識別子に関連付けられることと、対応するケースファイルが、リストからの医療デバイス識別子とペアにされたタイムスタンプの予め定められた範囲内にあるタイムスタンプを有することとを要求する。患者エンカウンタデータソース統合サービスは、ケースファイルを関連付けるために、この検索基準を使用して検索する（１４０６）。

【0249】

次に、患者エンカウンタデータソース統合サービスは、１又は複数の対応するケースファイルが検索（１４０６）によって識別されたか否かを決定する（１４０８）。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する（１４０８）場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを生成して呼び出し側プロセスに戻し（１４１０）、プロセス１４００が終了する。患者エンカウンタデータソース統合サービスが、少なくとも１つの対応するケースファイルが発見されたと決定する（１４０８）場合、患者エンカウンタデータソース統合サービスは、その少なくとも１つの対応するケースファイル又はその少なくとも１つの識別子を生成して呼び出し側プロセスに戻し（１４１２）、処理１４００が終了する。

【0250】

図１５は、いくつかの実装における、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）によって実行される関連付けプロセス１５００の１つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び／又は呼び出し側プロセス（例えば、図１のｅＰＣＲ ＡＰＩ１２８及び／又はイベントログＡＰＩ１４４）からの要求に応答して、プロセス１５００を実行するように構成することができる。図１５に示されているように、破線の境界でレンダリングされた操作は、いくつかの例において存在しない場合がある。

【0251】

図１５に示されているように、プロセス１５００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（１５０２）ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成し（１５０４）、少なくとも１つの検索基準に合致する又はそれを満たす医療デバイスケースファイルについてケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータをフィルタリングする（１５０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で受信し（５０２）、生成し（５０４）、検索する（５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１５００内で受信し（１５０２）、生成し（１５０４）、フィルタリングする（１５０６）ことができる。しかしながら、プロセス１５００内で、患者エンカウンタデータソース統合サービスは、初期検索基準を使用してケースデータストアを（例えば、クエリを介して）フィルタリングすることによって、ケースファイルについてケースデータを検索し（１５０６）し、そうすることで、複数の候補ケースファイルを識別する。いくつかの例において、フィルタによって用いられる初期検索基準は、関連付け情報の要素（例えば、タイムスタンプ）がケースファイルに関連付けられているパラメータの範囲内に入らなければならないことを指定する。

【0252】

次に、患者エンカウンタデータソース統合サービスは、少なくとも１つの補完検索基準を生成する（１５０８）。いくつかの例において、少なくとも１つの補完検索基準は、関連付け情報の少なくとも１つの補完要素と候補ケースファイルに関連付けられている少なくとも１つの補完パラメータとの間の少なくとも１つの補完的な予め定められた関係を指定する。例えば、少なくとも１つの補完的な関係がハードコーディングされている場合、患者エンカウンタデータソース統合サービスは、関連付け情報からの少なくとも１つの補完要素を識別するとともに、少なくとも１つの補完要素を少なくとも１つの補完的な関係と関連付けることによって、少なくとも１つの補完検索基準を生成する（１５０８）。代替的に又は加えて、少なくとも１つの補完的な関係がソフトコーディングされている場合、患者エンカウンタデータソース統合サービスは、まず、基準データストア（例えば、図１の基準データストア１３６）内でランク付けすることで次に好ましい予め定められた関係を識別するとともに、次に、次に好ましい予め定められた関係において指定されたものとして関連付け情報の少なくとも１つの補完要素を識別し、その少なくとも１つの補完要素を少なくとも１つの補完的な関係と関連付けることによって、少なくとも１つの補完検索基準を生成する（１５０８）。少なくとも１つの例において、少なくとも１つの補完要素は、ジオタグを含み、予め定められた関係は、対応するケースファイルが、関連付け情報からのジオタグの予め定められた範囲内にあるジオタグに関連付けられることを指定する。

【0253】

プロセス１５００を続けると、患者エンカウンタデータソース統合サービスは、少なくとも１つの補完検索基準に合致する又はそれを満たす医療デバイスケースファイルについて候補ケースデータを検索する（１５１０）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図５を参照しながら上で説明したプロセス５００内で検索する（５０６）際に患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１５００内で検索する（１５１０）ことができる。しかしながら、プロセス１５００内で、患者エンカウンタデータソース統合サービスは、その検索１５１０を候補ケースファイルからのケースデータに制限することができる。例えば、患者エンカウンタデータソース統合サービスは、ケースデータに格納されている、候補ケースファイルに関連付けられている補完パラメータが、少なくとも１つの補完検索基準に格納されている関連付け情報の補完要素と補完的な関係を満たす場合、その候補ケースファイルを対応するケースファイルとして識別することができる。

【0254】

次に、患者エンカウンタデータソース統合サービスは、少なくとも１つの対応するケースファイルが発見されたか否かを決定する（１５１２）。患者エンカウンタデータソース統合サービスが、少なくとも１つの対応するケースファイルが発見されたと決定する（１５１２）場合、患者エンカウンタデータソース統合サービスは、その対応するケースファイル又はその識別子を生成して呼び出し側プロセスに戻し（１５１４）、プロセス１５００が終了する。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する（１５１２）場合、患者エンカウンタデータソース統合サービスは、カウンタを反復し、カウンタがプロセス１５００の単一のインスタンスにおいて許容される検索反復の数に対する構成可能な制約に違反したか否かを決定する（１５１６）。患者エンカウンタデータソース統合サービスが、カウンタが制約に違反していないと決定する（１５１６）場合、患者エンカウンタデータソース統合サービスは、別の補完検索基準を生成し（１５０８）、プロセス１５００が続く。患者エンカウンタデータソース統合サービスが、カウンタが制約に違反したと決定する（１５１６）場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを呼び出し側プロセスに戻し（１５１８）、プロセス１５００が終了する。

【0255】

図１６は、いくつかの実装における、患者エンカウンタデータソース統合サービス（例えば、図１の患者エンカウンタデータソース統合サービス１３０）によって実行される関連付けプロセス１６００の１つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び／又は呼び出し側プロセス（例えば、図１のｅＰＣＲインタフェース１６８及び／又はイベントログＡＰＩ１４４）からの要求に応答して、プロセス１６００を実行するように構成することができる。図１６に示されているように、破線の境界でレンダリングされた操作は、いくつかの例において存在しない場合がある。

【0256】

図１６に示されているように、プロセス１６００は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する（１６０２）ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも１つの検索基準を生成し（１６０４）、複数の候補ケースファイルを識別するために少なくとも１つの検索基準を使用して、ケースデータストア（例えば、図１のケースデータストア１３２）に格納されているケースデータを（例えば、クエリを介して）フィルタリングする（１６０６）。いくつかの例において、患者エンカウンタデータソース統合サービスは、図１５を参照しながら上で説明したプロセス１５００内で受信し（１５０２）、生成し（１５０４）、フィルタリングする（１５０６）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１６００内で受信し（１６０２）、生成し（１６０４）、フィルタリングする（１６０６）ことができる。しかしながら、プロセス１６００内で、フィルタによって用いられる初期検索基準は、関連付け情報の要素と、非医療的な、医療デバイスケースファイルに関連付けられているパラメータとの間の等価性を指定する初期の予め定められた関係を含む。これらの非医療要素及びパラメータは、ケース開始時間、医療デバイス識別子、及び／又は患者識別子を含むことができる。

【0257】

次に、患者エンカウンタデータソース統合サービスは、少なくとも１つの補完検索基準を生成する（１６０８）。この例において、少なくとも１つの補完検索基準は、関連付け情報内の少なくとも１つの医療要素が、ケースファイル内の少なくとも１つの医療パラメータと医学的に一貫し且つこれを示すことを指定する。これらの例において、少なくとも１つの医療要素は、患者の訴え、医師の所見、投薬、バイタルサイン、生理学測定値、患者に与えられた処置、胸痛の兆候、ＳＴ上昇を伴うＥＣＧ、及び／又はＳＴＥＭＩ診断を含むことができる。さらに、これらの例において、少なくとも１つの医療パラメータは、生理学測定値のタイプ、生理学測定値の値、医療処置（例えば、除細動ショック）、及びアラームを含むことができる。

【0258】

プロセス１６００を続けると、患者エンカウンタデータソース統合サービスは、候補ケースデータを検索し（１６１０）、少なくとも１つの対応するケースファイルが発見されたか否かを決定し（１６１２）、対応するケースファイルが発見された場合、その対応するケースファイル又はその識別子を呼び出し側プロセスに戻す（１６１４）。対応するケースファイルが発見されなかった場合、患者エンカウンタデータソース統合サービスは、検索限界を超えたか否かを決定し（１６１６）、検索限界を超えた場合、対応するケースファイルが無いことを示すエラーメッセージを呼び出し側プロセスに戻し（１６１８）、検索限界を超えていない場合、少なくとも１つの補完検索基準を生成する（１６０８）ように戻す。いくつかの例において、患者エンカウンタデータソース統合サービスは、図１５を参照しながら上で説明されたプロセス１５００内で検索し（１５１０）、決定し（１５１２）、戻し（１５１４）、決定し（１５１６）、戻す（１５１８）ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス１６００内で検索し（１６１０）、決定し（１６１２）、戻し（１６１４）、決定し（１６１６）、戻す（１６１８）ことができる。

【0259】

上で説明したように、プロセス１６００は、関連付け情報内の少なくとも１つの医療要素が、ケースファイル内の少なくとも１つの医療パラメータと医学的に一貫し且つそれを示すことを指定する少なくとも１つの補完検索基準を生成する（１６０８）。この例において、少なくとも１つの予め定められた関係は、関連付け情報がケースデータ「と医学的に一貫し且つそれを示す」ことを指定する。この予め定められた関係は、複雑であり、一般に利用可能な比較操作を使用して評価するのが困難である。したがって、この例において、患者エンカウンタデータソース統合サービスは、関連付け情報とケースデータとを比較する１又は複数の特殊ヒューリスティックプロセス、統計プロセス、及び／又は機械学習プロセスを実行することによって、検索する（１６１０）間に予め定められた関係を評価する。表１は、いくつかの例による、関連付け情報と、「それと医学的に一貫し且つそれを示す」という予め定められた関係を満たすケースデータとを提供する。

【0260】

【表1】

表１

【0261】

より具体的には、表１に示されているように、列Ａ及びＢは、列Ｃ及びＤにリストされている一次医療デバイスケースデータ及び二次医療デバイスケースデータと医学的に一貫し且つそれを示す関連付け情報の一次要素及び二次要素をリストしている。いくつかの例において、患者エンカウンタデータソース統合サービスは、検索（１６１０）の間に発見された任意の対応するケースデータが、関連付け情報の一次要素及び二次要素と医学的に一貫し且つそれを示さなければならないことを指定する補完検索基準を生成することができる（１６０８）。代替的に、いくつかの例において、患者エンカウンタデータソース統合サービスは、検索（１６１０）の間に発見された任意の対応するケースデータが、関連付け情報の一次要素と医学的に一貫し且つそれを示さなければならないことを指定する第１の補完検索基準を生成することができる（１６０８）。検索（１６１０）中に第１の補完検索基準に対応するケースデータが発見されなかった場合、患者エンカウンタデータソース統合サービスは、検索中に発見された任意の対応するケースデータが、関連付け情報の二次要素と医学的に一貫し且つそれを示さなければならないと指定する第２の補完検索基準を生成することができる（１６０８）。

【0262】

いくつかの例において、システム１００は、様々な医療デバイスケースファイル共有プロセスを実行するように構成されている。図１７は、例えば、モバイルコンピューティングデバイス（例えば、図１のモバイルコンピューティングデバイス１０４Ａ）と、コンピューティングデバイス（例えば、図１のモバイルコンピューティングデバイス１０４Ｂ）と、患者エンカウンタデータソース統合サービスとを伴う共有プロセス１７００を示している。

【0263】

共有プロセス１７００は、モバイルコンピューティングデバイスが、ヘルスケア提供者（例えば、図１のヘルスケア提供者１１８Ａ）を認可されたユーザとして認証する（１７０２）ことで開始する。モバイルコンピューティングデバイスは、モバイルコンピューティングデバイスが患者エンカウンタからの集約されたケースデータをコンピューティングデバイスと共有することを要求するユーザからの入力を受ける（１７０４）。例えば、イベントログアプリケーション及び／又はｅＰＣＲアプリケーション（例えば、図１のイベントログアプリケーション１４０及び／又はｅＰＣＲアプリケーション１２２）が入力を受けることができる。入力を受けたことに応答して、モバイルコンピューティングデバイスは、患者エンカウンタを識別するトークンをコンピューティングデバイスに送信する（１７２４）。例えば、モバイルコンピューティングデバイスは、ユーザインタフェースを介してトークンの視覚表現を表示してよく、及び／又は、ＮＦＣを介してトークンを表現するデータを送信してよい。

【0264】

共有プロセス１７００を続けると、コンピューティングデバイスは、（例えば、カメラで視覚イメージをスキャンすることによって）トークンを受信し（１７０６）、トークンによって識別された患者エンカウンタについての集約されたケースデータの要求を患者エンカウンタデータソース統合サービスに送信する（１７０８）。例えば、エンカウンタレビューアプリケーション（例えば、図１のエンカウンタレビューアプリケーション１４８）が要求を送信することができる。

【0265】

共有プロセス１７００の別の部分として、患者エンカウンタデータソース統合サービスは、以前に実行された集約プロセス（例えば、図４の集約プロセス４００）の一部として、トークンによって識別される患者エンカウンタについての集約されたケースデータを、トークンと関連付けて格納する（１７１０）。患者エンカウンタデータソース統合サービスは、コンピューティングデバイスから集約されたケースデータの要求を受信する（１７１２）。患者エンカウンタデータソース統合サービスは、トークンを使用して、集約されたケースデータを識別し（１７１４）、集約されたケースデータを索出し（１７１６）、集約されたケースデータをコンピューティングデバイスに送信する（１７１８）。

【0266】

共有プロセス１７００を続けると、コンピューティングデバイスは、集約されたケースデータを受信し（１７２０）、集約されたケースデータの受信に応答して自動的に集約されたケースデータをレンダリングする。例えば、エンカウンタレビューアプリケーションは、集約されたデータを含むイベントログをレンダリングすることができる。

【0267】

図１８を参照すると、コンピューティングデバイス及び医療デバイスのコンポーネントの例のブロック図が概略的に示されている。

【0268】

医療デバイス１０２は、プロセッサ２２０と、メモリ２２１と、１又は複数の出力デバイス２３０と、１又は複数のユーザ入力デバイス２４４と、通信インタフェース２４５とを含むことができる。通信インタフェース２４５は、様々なトランスミッタ及び／又はレシーバのうちの任意のものを含むことができる。例えば、いくつかの例において、通信インタフェース２４５は、ＮＦＣタグ、ＲＦＩＤタグ、バーコード、及びＱＲコードのうちの１又は複数を含む。

【0269】

様々な実装において、医療デバイス１０２は、除細動器、患者モニタ、除細動器／モニタ、自動化圧迫デバイス、治療冷却デバイス、体外式膜型人工肺（ＥＣＭＯ）デバイス、換気デバイス、それらの組み合わせ、又は、患者に治療を提供するように１又は複数の治療送達コンポーネントに結合するように構成されている別のタイプの医療デバイスとすることができる。一実装において、医療デバイス１０２は、単一のハウジング２８０内の統合治療送達／モニタリングデバイスとすることができる。単一のハウジング２８０は、患者インタフェースデバイス信号プロセッサ２５６及び／又は治療送達制御モジュール２５５を少なくとも部分的に囲むことができる。

【0270】

患者インタフェースデバイス１９０は、１又は複数の治療送達コンポーネント２６１ａ及び／又は１又は複数のセンサデバイス２６１ｂを含むことができる。医療デバイス１０２は、１又は複数の治療送達コンポーネント２６１ａに結合するように構成することができる。医療デバイス１０２と１又は複数の治療送達コンポーネントとは、組み合わせで、患者（例えば、図１の患者１１６）に治療処置を提供することができる。一実装において、医療デバイス１０２は、治療送達コンポーネント２６１ａを含む又は組み込むことができる。治療送達コンポーネント２６１ａは、患者に治療を送達するように構成されており、患者に結合するように構成することができる。例えば、治療送達コンポーネント２６１ａは、除細動電極及び／又はペーシング電極を含む電気治療電極、胸骨圧迫デバイス（例えば、１又は複数のベルト又はピストン）、換気デバイス（例えば、マスク及び／又はチューブ）、薬剤送達デバイス等のうちの１又は複数を含むことができる。医療デバイス１０２は、患者に医学的治療を提供すべく、１又は複数の治療送達コンポーネント２６１ａを含むことができる及び／又は１又は複数の治療送達コンポーネント２６１ａに結合するように構成することができる。治療送達コンポーネント２６１ａは、患者に結合するように構成することができる。例えば、ヘルスケア提供者（例えば、ヘルスケア提供者１１８）は、患者に電極を取り付けてよく、医療デバイス１０２（例えば、除細動器又は除細動器／患者モニタ）は、除細動電極を介して患者に電気治療を提供してよい。これらの例は本開示を限定するものではなく、他のタイプの医療デバイス、治療送達コンポーネント、センサ、及び治療が本開示の範囲内にある。

【0271】

医療デバイス１０２は、例えば、医学的治療を送達可能な治療医療デバイスとすることができる。例えば、医学的治療は、電気治療（例えば、除細動、心臓ペーシング、同期カルディオバージョン、横隔膜又は横隔神経刺激）とすることができ、医療デバイス１０２は、除細動器、除細動器／モニタ、及び／又は、電気治療を提供するように構成されている別の医療デバイスとすることができる。別の例として、医学的治療は、心停止の処置のための胸骨圧迫治療とすることができ、第１の医療デバイス１０２は、ベルト式胸骨圧迫デバイス又はピストン式胸骨圧迫デバイス等の機械的胸骨圧迫デバイスとすることができる。他の例として、医学的治療は、換気治療、治療冷却又は他の体温管理、観血式血行力学的支援治療（例えば、体外式膜型人工肺（ＥＣＭＯ））等とすることができ、医療デバイス１０２は、それぞれの治療を提供するように構成されているデバイスとすることができる。一実装において、医療デバイス１０２は、これらの例のうちの１又は複数の組み合わせとすることができる。治療医療デバイスは、１又は複数のセンサを介した患者モニタリング能力を含むことができる。これらのタイプの医学的治療及びデバイスは、単に例であり、本開示を限定するものではない。

【0272】

医療デバイス１０２は、患者に結合するように構成することができる１又は複数のセンサ２６１ｂを含む、組み込む、及び／又はそれに結合するように構成することができる。センサ２６１ｂは、センサデータを示す信号を医療デバイス１０２に提供するように構成されている。センサ２６１ｂは、患者に結合するように構成することができる。例えば、センサ２６１ｂは、心臓検知電極、胸骨圧迫センサ、及び／又は換気センサを含むことができる。１又は複数のセンサ２６１ｂは、患者の生理学パラメータを示す信号を生成することができる。例えば、生理学パラメータは、少なくとも１つのバイタルサイン、ＥＣＧ、血圧、心拍数、パルス酸素レベル、呼吸数、心音、肺音、呼吸音、呼気ＣＯ２、筋肉酸素飽和度（ＳＭＯ２）、動脈血酸素飽和度（ＳｐＯ２）、脳血流、脳波図（ＥＥＧ）信号、脳酸素レベル、組織ｐＨ、組織流体レベル、超音波イメージを介して特定された物理的パラメータ、近赤外線反射スペクトロスコピー、ニューモグラフィ及び／又はカルジオグラフィを介して特定されたパラメータ等のうちの１又は複数を含むことができる。加えて又は代替的に、１又は複数のセンサ２６１ｂは、胸骨圧迫パラメータ、換気パラメータ、薬剤送達パラメータ、流体送達パラメータ等を示す信号を生成することができる。

【0273】

患者への治療の送達に加えて、治療送達コンポーネント２６１ａは、センサを含み、センサに結合され、及び／又はセンサとして機能し、センサデータ（例えば、第２のセンサデータ）を示す信号を医療デバイス１０２に提供することができる。例えば、除細動電極は、心臓検知電極及び電気治療送達デバイスして構成することができ、経胸壁インピーダンス、心電図（ＥＣＧ）、心拍数及び／又は他の生理学パラメータを示す信号を提供することができる。別の例として、治療冷却デバイスは、静脈内冷却デバイスとすることができる。このような冷却デバイスは、冷却治療を送達し、患者の体温を検知するように構成されている治療送達コンポーネントとしての静脈内（ＩＶ）デバイスを含むことができる。例えば、ＩＶデバイスは、温度制御された生理食塩水の循環を介して患者の体温を調整するように構成されている生理食塩水バルーンを備えるカテーテルすることができる。さらに、カテーテルは、患者の体温を検知するように構成されている温度プローブを含むことができる。さらなる例として、ＩＶデバイスは、薬剤送達及び／又は流体管理を介して治療を提供することができる。また、ＩＶデバイスは、血液サンプリング及び／又は静脈圧モニタリング（例えば、中心静脈圧（ＣＶＰ）モニタリング）を介して患者をモニタリングする及び／又はそのモニタリングを可能にすることができる。

【0274】

医療デバイス１０２は、（例えば、治療送達コンポーネント２６１ａ及び／又はセンサ２６１ｂから）センサ信号を受信するように、また、患者データを決定して収集するために、センサ信号を処理するように構成することができる。患者データは、患者のステータス及び／又は状態を特徴付けることができる患者データ（例えば、ＥＣＧ、心拍数、呼吸数、温度、パルスオキシメトリ、非観血ヘモグロビンパラメータ、カプノグラフィ、酸素飽和度（ＳｐＯ２）、呼気終末二酸化炭素（ＥｔＣＯ２）、観血血圧（ＩＢＰ）、非観血血圧（ＮＩＢＰ）、組織ｐＨ、組織酸素化、近赤外線分光法（ＮＩＲＳ）測定値等のような生理学データ）を含むことができる。加えて又は代替的に、患者データは、治療の送達を特徴付けることができ（例えば、圧迫深さ、圧迫回数等のような胸骨圧迫データ）、及び／又は、患者データは、患者を処置するために使用された医療機器のステータス及び／又は状態を特徴付けることができる（例えば、ショック時間、ショック持続時間、電極の取り付け、電源オン等のようなデバイスデータ）。

【0275】

医療デバイス１０２の２２０、２２１、２３０、２４４、２４５、及び２５５のコンポーネントは、双方向通信のために互いに（直接及び／又は間接的に）通信可能に結合されている。

【0276】

図１８では別個のエンティティとして示されているが、医療デバイス１０２のコンポーネントのうちの１又は複数は、組み合わせて１又は複数の別個のコンポーネントにすることができ、及び／又は、プロセッサ２２０の一部とすることができる。プロセッサ２２０及びメモリ２２１は、本明細書において説明した機能を実行するために関連付けられる回路を含む及び／又はそれに結合することができる。

【0277】

一実装において、医療デバイス１０２は、医学的治療を患者に送達するように構成されている治療医療デバイスとすることができる。こうして、医療デバイス１０２は、治療送達制御モジュール２５５を任意に含むことができる。例えば、治療送達制御モジュール２５５は、ペーシングパルス又は除細動パルスのための電気エネルギーを貯蔵するように構成されている１又は複数のキャパシタを含む電気治療送達回路とすることができる。電気治療送達回路は、抵抗器、追加のキャパシタ、リレー及び／又はスイッチ、Ｈブリッジ（例えば、複数の絶縁ゲートバイポーラトランジスタ又はＩＧＢＴを含む）等の電気的ブリッジ、電圧測定コンポーネント、及び／又は電流測定コンポーネントをさらに含むことができる。別の例として、治療送達制御モジュール２５５は、機械的圧迫デバイスを制御するように構成されている圧迫デバイス電気機械コントローラとすることができる。さらなる例として、治療送達制御モジュール２５５は、薬剤送達、体温管理、換気、及び／又は他のタイプの治療送達を制御するように構成されている電気機械コントローラとすることができる。代替的には、医療デバイス１０２のいくつかの例は、患者１１６に医学的治療を送達するように構成されていなくてもよいが、患者モニタリング及び／又は診断ケアを提供するように構成することができる。図１８に示されているように、いくつかの例において、治療送達制御モジュール２５５は、通信リンク１１８０を介して、モバイルコンピューティングデバイス１０４（例えば、患者モバイルコンピューティングデバイス）とメッセージを交換する。これらのメッセージは、患者に提供された治療を記述する患者データ又は医療デバイス１０２上に格納されている他の患者データを含むことができる。この患者データは、派遣されたＥＭＳイベントをドキュメント化したｅＰＣＲを生成する際にｅＰＣＲアプリケーションによって使用することができる。１つの実施形態において、通信リンク１１８０は、ＢＬＵＥＴＯＯＴＨ及び／又は近距離通信技術を使用して実施される。

【0278】

特定の実装において、本明細書において患者エンカウンタデータソース統合サービス１３０に関連付けられているものとして説明したファイル合致及びマージ機能は、代替的には、医療デバイス１０２及び／又はモバイルコンピューティングデバイス１０４において呼び出される。そのような実装においては、この機能をサポートするために、医療デバイス１０２とモバイルコンピューティングデバイス１０４との間の通信リンク１１８０を使用することができ、したがって、サーバ１０８への接続が利用不可能であるときでも、医療デバイスケースファイルが関連するチャート化データと統合されることが可能である。通信リンク１１８０が制限されているアプリケーションにおいて、例えば、制限された帯域幅又は制限された持続時間に起因して、ファイル合致及びマージ機能は、任意に、デバイス識別子を比較する検索基準等の１又は複数の指定された検索基準に制限される。このことは、患者処置及びＥＭＳインタラクションのために制限されたリソースを確保するために、通信リンク１１８０によって提供される帯域幅を絞ることが望まれるアプリケーションにおいて、特に有用であり得る。

【0279】

通信リンク１１８０を介して共有される情報は、セキュリティを高めるために及び／又はＰＨＩを保護するために任意に制限される。これは、例えば、医療デバイス１０２及びモバイルコンピューティングデバイス１０４を、通信リンク１１８０を使用して公開情報（例えば、デバイス識別子）のみを通信するように構成することによって実現することができる。ＰＨＩが医療デバイス１０２とモバイルコンピューティングデバイス１０４との間で共有されることになる実装において、通信は、より強力な認証を実施することができる信頼できるクラウドサービスを介してルーティングすることができる。特定の実施形態において、サーバ１０８は、そのような信頼できるクラウドサービスを提供する。サーバ１０８を介して通信をルーティングすることは、医療デバイス１０２及びモバイルコンピューティングデバイス１０４が異なるフォーマットでデータを生成する場合、及び／又は、通信デバイスのうちの１又は複数がローカルネットワークにおいて通信するように構成されてない場合等、他の理由でも好ましい場合がある。

【0280】

医療デバイス１０２は、１又は複数の患者インタフェースデバイス１９０を組み込む及び／又はそれに結合するように構成することができる。患者インタフェースデバイス１９０は、１又は複数の治療送達コンポーネント２６１ａ及び１又は複数のセンサ２６１ｂを含むことができる。１又は複数の治療送達コンポーネント２６１ａ及び１又は複数のセンサ２６１ｂは、有線及び／又は無線接続を介して、１又は複数の信号を医療デバイス１０２に提供することができる。

【0281】

１又は複数の治療送達コンポーネント２６１ａは、電気治療電極（例えば、電気治療電極２６６ａ）、換気デバイス（例えば、換気デバイス２６６ｂ）、静脈内デバイス（例えば、静脈内デバイス２６６ｃ）、圧迫デバイス（例えば、圧迫デバイス２６６ｄ）等を含むことができる。例えば、電気治療電極は、除細動電極、ペーシング電極、及び／又はそれらの組み合わせを含むことができる。換気デバイスは、チューブ、マスク、腹部及び／又は胸骨圧迫器（例えば、ベルト、胸甲呼吸器等）等、並びにそれらの組み合わせを含むことができる。静脈内デバイスは、薬剤送達デバイス、流体送達デバイス、及びそれらの組み合わせを含むことができる。圧迫デバイスは、腹部圧迫器、胸骨圧迫器、ベルト、ピストン、及びそれらの組み合わせ等の機械的圧迫デバイスを含むことができる。様々な実装において、治療送達コンポーネント２６１ａは、センサデータを提供する及び／又はセンサに結合される及び／又はセンサを組み込むように構成することができる。例えば、電気治療電極は、経胸壁インピーダンス、ＥＣＧ、心拍数等のようなセンサデータを提供することができる。さらに、電気治療電極は、胸骨圧迫センサを含む及び／又はそれに結合することができる。別の例として、換気デバイスは、フローセンサ、ガス種センサ（例えば、酸素センサ、二酸化炭素センサ等）等に結合する及び／又はそれらを組み込むことができる。さらなる例として、静脈内デバイスは、温度センサ、フローセンサ、血圧センサ等に結合する及び／又はそれらを組み込むことができる。また別の例として、圧迫デバイスは、胸骨圧迫センサ、患者位置センサ等に結合する及び／又はそれらを組み込むことができる。治療送達制御モジュール２５５は、治療送達コンポーネント２６１ａに結合し、これを制御するように構成することができる。

【0282】

様々な実装において、センサ２６１ｂは、例えば、心電図（ＥＣＧ）、血圧、心拍数、パルス酸素レベル、呼吸数、心音、肺音、呼吸音、呼気ＣＯ２、筋肉酸素飽和度（ＳＭＯ２）、動脈血酸素飽和度（ＳｐＯ２）、脳血流、脳波図（ＥＥＧ）信号、脳酸素レベル、組織ｐＨ、組織流体レベル、超音波、ラリンゴスコピー、及び／又は他の医療撮像技法、近赤外線反射スペクトロスコピー、ニューモグラフィ、カルジオグラフィを介したイメージ及び／又はビデオ、及び／又は患者の動きを含むがこれらに限定されないセンサデータを提供するように構成されている１又は複数のセンサデバイスを含むことができる。イメージ及び／又はビデオは、二次元又は３次元とすることができる。

【0283】

センサ２６１ｂは、検知電極（例えば、検知電極２６２）、換気センサ（例えば、換気センサ２６４）、温度センサ（例えば、温度センサ２６７）、胸骨圧迫センサ（例えば、胸骨圧迫センサ２６８）等を含むことができる。例えば、検知電極は、心臓検知電極を含むことができる。心臓検知電極は、例えば患者のＥＣＧ情報を測定するために、患者の電気生理学における変化を測定するように構成されている導電及び／又は容量結合電極とすることができる。一実装において、検知電極は、患者の経胸壁インピーダンス及び／又は心拍数を測定するように構成することができる。換気センサは、肺活量測定センサ、フローセンサ、圧力センサ、例えば、パルスオキシメトリセンサ、酸素化センサ（例えば、筋肉酸素化／ｐＨ）、Ｏ２ガスセンサ、及びカプノグラフィセンサのうちの１又は複数等の酸素及び／又は二酸化炭素センサ、並びにそれらの組み合わせを含むことができる。温度センサは、赤外線温度計、接触温度計、リモート温度計、液晶温度計、サーモカップル、サーミスタ等を含むことができ、患者の体温を内部及び／又は外部から測定することができる。胸骨圧迫センサは、例えば、１又は複数の加速度計、１又は複数の力センサ、１又は複数の磁気センサ、１又は複数の速度センサ、１又は複数の変位センサ等を含む１又は複数のモーションセンサを含むことができる。胸骨圧迫センサは、例えば、圧迫パック、スマートフォン、ハンドヘルドデバイス、ウェアラブルデバイス等とすることができるが、これに限定されない。胸骨圧迫センサは、救助者及び／又は自動化胸骨圧迫デバイス（例えば、ベルトシステムピストンシステム等）によって伝えられる胸部の動きを検出するように構成することができる。胸骨圧迫センサは、変位データを含む胸骨圧迫データ、速度データ、解放速度データ、加速度データ、圧迫回数データ、滞留時間データ、ホールド時間データ、血流データ、血圧データ等を示す信号を提供することができる。一実装において、検知電極及び／又は電気治療電極は、胸骨圧迫センサを含む又はそれに結合するように構成することができる。

【0284】

図１８を引き続き参照すると、モバイルコンピューティングデバイス１０４のコンポーネントの例が概略的に示されている。一実装において、モバイルコンピューティングデバイス１０４は、モバイルコンピューティングデバイスとして構成することができる。
モバイルコンピューティングデバイス１０４は、プロセッサ４２０と、メモリ４２１と、１又は複数の出力デバイス４３０と、１又は複数のユーザ入力デバイス４４４と、通信インタフェース４４５とを含むことができる。図１８は、リモートコンピューティングデバイス１０６のコンポーネントの例も概略的に示している。図１８に示されているように、リモートコンピューティングデバイス１０６は、プロセッサ３２０と、メモリ３２１と、１又は複数の出力デバイス３３０と、１又は複数のユーザ入力デバイス３４４と、通信インタフェース３４５とを含むことができる。図１８は、さらに、サーバ１０８のコンポーネントの例を概略的に示している。図１８に示されているように、サーバ１０８は、プロセッサ５２０と、メモリ５２１と、１又は複数の出力デバイス５３０と、１又は複数のユーザ入力デバイス５４４と、通信インタフェース５４５とを含むことができる。

【0285】

モバイルコンピューティングデバイス１０４（例えば、モバイルコンピューティングデバイス）及びリモートコンピューティングデバイス１０６のそれぞれは、デスクトップ、ノートブック、モバイル、ポータブル、又は他のタイプのコンピューティングシステム等のコンピュータシステムとすることができる。これらのデバイス１０４及び１０６のそれぞれは、サーバを含む、及び／又は、モニタ及び／又は他の接続されたユーザインタフェースデバイスを介して、サーバにアクセスすることができる。サーバとして説明したが、サーバ１０８は、例えば、デスクトップ、ノートブック、モバイル、ポータブル、又は他のタイプのコンピューティングシステムを含む別のタイプのコンピューティングシステムとすることができる。

【0286】

図１８に示されているように、デバイス１０４及び１０６のそれぞれは、サーバ１０８及び医療デバイス１０２とともに、その中に含まれているプロセッサ、メモリ、出力デバイス、入力デバイス、及び通信インタフェースを通信可能に結合するバス又は他の相互接続機構を含む。バスは、例えば、使用されるストレージデバイスに応じて、ＰＣＩ／ＰＣＩ－Ｘ又はＳＣＳＩベースのシステムバスを含むことができる。

【0287】

プロセッサ２２０、３２０、４２０及び５２０は、限定されないが、Ｉｎｔｅｌ（登録商標）Ｉｔａｎｉｕｍ（登録商標）若しくはＩｔａｎｉｕｍ ２（登録商標）プロセッサ、又は、ＡＭＤ（登録商標）Ｏｐｔｅｒｏｎ（登録商標）若しくはＡｔｈｌｏｎ ＭＰ（登録商標）プロセッサ、又は、Ｍｏｔｏｒｏｌａ （登録商標）ラインのプロセッサ等のプロセッサをそれぞれ含むことができる。通信インタフェース２４５、３４５、４４５及び５４５は、それぞれ、例えば、モデムベースのダイヤルアップ接続とともに使用されるＲＳ－２３２ポート、１０／１００イーサネットポート、又は銅若しくはファイバを使用したギガビットポートのうちの任意のものとすることができる。通信インタフェース２４５、３４５、４４５及び５４５は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、又は、医療デバイス１０２、モバイルコンピューティングデバイス１０４、リモートコンピューティングデバイス１０６、及び／又はサーバ１０８が接続し得る任意のネットワーク等のネットワークに応じて選択されてよい。メモリ２２１、３２１、４２１及び５２１は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、フラッシュメモリ、及び／又は別のダイナミック揮発性及び／又は不揮発性ストレージデバイスとすることができる。メモリ２２１、３２１、４２１及び５２１は、情報及び命令を記憶するために使用することができる。例えば、Ａｄａｐｔｅｃ（登録商標）ファミリのＳＣＳＩドライブ等のハードディスク、光ディスク、ＲＡＩＤ等のディスクのアレイ（例えば、ＡｄａｐｔｅｃファミリーのＲＡＩＤドライブ）、又は任意の他の大容量ストレージデバイスが使用されてよい。上で説明したコンポーネントは、可能性のいくつかのタイプを例示することが意図されている。前述の例は、決して本開示の範囲を限定すべきでない。メモリ２２１、３２１、４２１及び５２１は、例えば、外部ハードドライブ、フロッピドライブ、フラッシュドライブ、ＩＯＭＥＧＡ（登録商標）Ｚｉｐドライブ、コンパクトディスク－リードオンリメモリ（ＣＤ－ＲＯＭ）、コンパクトディスク－リライタブル（ＣＤ－ＲＷ）、又はデジタルビデオディスク－リードオンリメモリ（ＤＶＤ－ＲＯＭ）等のリムーバブルストレージ媒体をさらに含むことができる。

【0288】

図１８を引き続き参照すると、サーバ１０８は、例えば、１又は複数のストレージサーバ及び１又は複数のアプリケーションサーバを含むことができる。いくつかの例において、サーバ１０８は、リモートコンピューティングデバイス１０６とメッセージ１１７０を交換するように構成されている。これらのメッセージは、上で説明したようなチャート及び／又はケースデータを含むことができる。いくつかの例において、サーバ１０８は、ｅＰＣＲ ＡＰＩ１２８を介してモバイルコンピューティングデバイス１０４とメッセージ１１６０を交換するように構成されている。これらのメッセージは、モバイルコンピューティングデバイス１０４によって生成されたｅＰＣＲを記述するデータを含むことができる。いくつかの例において、サーバ１０８は、医療デバイス１０２とメッセージ１１９０を交換するように構成されている。これらのメッセージは、医療デバイスを介して処置されている患者（例えば、図１の患者１１６）及び／又は医療デバイス１０２によって送達されている処置を記述するデータを含むことができる。

【0289】

本開示のいくつかの例は、様々な段階を含み、それらのいくつかは、ハードウェアコンポーネントによって実行することができ、又は、マシン実行可能命令に具現化することができる。これらのマシン実行可能命令は、非一時的データ記憶媒体上に記憶することができ、これらの命令を用いてプログラムされた汎用又は特定用途向けプロセッサにこれらの段階を実行させるために使用することができる。非一時的データ記憶媒体は、オペレーティングシステムをさらに記憶することができ、マシン実行可能命令は、ｅＰＣＲアプリケーション１２２等の１又は複数のソフトウェアアプリケーション又はプログラム内に含むことができる。これらのプログラムは、本明細書に開示されている特徴及びそれらが実行する方法を実施することができる。代替的には、これらの段階は、１つのデバイス上にある及び／又は複数のデバイス及び／又はプロセッサにわたって分散された、ハードウェア、ソフトウェア、及び／又はファームウェアの組み合わせによって実行することができる。さらに、本開示のいくつかの例は、１又は複数のコンピュータシステム、メインフレーム（例えば、ＩＢＭ ｚＳｅｒｉｅｓ等のＩＢＭメインフレーム、Ｕｎｉｓｙｓ ＣｌｅａｒＰａｔｈメインフレーム、ＨＰ Ｉｎｔｅｇｒｉｔｙ ＮｏｎＳｔｏｐサーバ、ＮＥＣ Ｅｘｐｒｅｓｓシリーズ、及び他のもの）、又はクライアント－サーバタイプシステム上で少なくとも部分的に（例えば、１又は複数のモジュール）実行又は実施することができる。さらに、本開示の例の特定のハードウェアの態様は、これらのシステムのうちの１若しくは複数又はその一部を組み込むことができる。

【0290】

このように少なくとも１つの例のいくつかの態様が説明されたので、様々な変更、修正及び改善が当業者にはすぐに思い浮かぶであろうことが理解されるべきである。例えば、本明細書において開示されている例は、他の状況においても使用できる。そのような変更形態、修正形態、及び改善形態は、本開示の一部であることが意図され、本明細書において議論された例の範囲内に入ることが意図されている。したがって、前述の説明及び図面は、単に例としてものである。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図3D】

【図4】

【図5A】

【図5B】

【図5C】

【図5D】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23A】

【図23B】

【図24】

【図25】

【国際調査報告】