JPWO2021202490A5 - - Google Patents

Download PDF

Info

Publication number
JPWO2021202490A5
JPWO2021202490A5 JP2022558108A JP2022558108A JPWO2021202490A5 JP WO2021202490 A5 JPWO2021202490 A5 JP WO2021202490A5 JP 2022558108 A JP2022558108 A JP 2022558108A JP 2022558108 A JP2022558108 A JP 2022558108A JP WO2021202490 A5 JPWO2021202490 A5 JP WO2021202490A5
Authority
JP
Japan
Prior art keywords
data
case
patient
computing device
encounter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022558108A
Other languages
English (en)
Other versions
JP2023519672A (ja
Publication date
Application filed filed Critical
Priority claimed from PCT/US2021/024833 external-priority patent/WO2021202490A1/en
Publication of JP2023519672A publication Critical patent/JP2023519672A/ja
Publication of JPWO2021202490A5 publication Critical patent/JPWO2021202490A5/ja
Pending legal-status Critical Current

Links

Description

緊急ケア提供者は、彼らが遭遇する患者を処置するために様々な特殊医療デバイスを利用する。これらの特殊医療デバイスとしては、とりわけ、除細動器、人工呼吸器、及び自動化蘇生デバイスを挙げることができる。除細動器は、心室細動又は無脈性心室頻拍等のショック適応心臓不整脈を起こした患者を処置するために使用できる。人工呼吸器は、補助がないと呼吸が困難であるか又は呼吸ができない患者に酸素を供給するために使用できる。いくつかの自動化蘇生デバイスは、突然の心停止を起こした患者に、特にそのような患者が継続的な処置のために他のロケーションに移動される必要がある場合に、心肺蘇生法(CPR)胸骨圧迫を実行できる。
医療デバイスケースファイルは、上で説明したもの等のコンピュータ化医療デバイスで患者を処置したことの副産物として生じる。医療デバイスケースファイルは、患者エンカウンタ中の医療デバイス操作、患者エンカウンタ中に送達された処置、及び患者エンカウンタ中に医療デバイスによって測定された患者パラメータの値をドキュメント化することができる。医療デバイスケースファイルは、患者の疾患を把握するとともに患者アウトカムを最終的に改善するために、患者エンカウンタ中又はその後にヘルスケア提供者によってレビューされ得る。
少なくとも1つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタに関与した複数のデバイスからの医療データを集約するシステムが提供される。システムは、それぞれが1又は複数の識別子を有する複数の医療デバイスを含む。複数の医療デバイスのそれぞれは、患者と緊急ヘルスケア提供者との間のエンカウンタに関係するケースデータを取得し、取得されたケースデータを1又は複数の医療デバイスケースファイルとしてサーバに送信するように構成されている。システムは、医療デバイスインタフェース及びユーザインタフェースを有するモバイルコンピューティングデバイスをさらに備える。モバイルコンピューティングデバイスは、医療デバイスインタフェースを介して、複数の医療デバイスの各医療デバイスの1又は複数の識別子の1又は複数の表現を取得し、1又は複数の識別子を含む関連付け情報を生成し、関連付け情報をサーバに送信するように構成されている。サーバは、1又は複数の医療デバイスケースファイルを関連付けるための命令を実行するように少なくとも1つのプロセッサ及びメモリを含む。サーバは、複数の医療デバイス及びモバイルコンピューティングデバイスと通信可能に結合されるように構成されている。サーバは、複数の医療デバイスから1又は複数の医療デバイスケースファイルを受信して格納し、モバイルコンピューティングデバイスから関連付け情報を受信し、1又は複数の医療デバイスケースファイルを互いに関係付けるように関連付け情報に少なくとも部分的に基づいて少なくとも1つの検索基準を生成し、生成された少なくとも1つの検索基準に基づいて関係付けられた1又は複数の医療デバイスケースファイルを識別し、関係付けられた1又は複数の医療デバイスケースファイルからのケースデータを含む統合データソースエンカウンタ構造体を生成するように1又は複数の医療デバイスケースファイルを集約し、患者と緊急ヘルスケア提供者との間のエンカウンタのレビューのために統合データソースエンカウンタ構造体を受信側コンピューティングデバイスに送信するようにさらに構成されている。
システムにおいて、受信側コンピューティングデバイスは、モバイルコンピューティングデバイスを含むことができる。モバイルコンピューティングデバイスは、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングするようにさらに構成することができる。統合データソースエンカウンタ構造体は、患者情報以外の情報を含むことができる。
システムにおいて、受信側コンピューティングデバイスは、複数の医療デバイスのうちの少なくとも1つの医療デバイスを含むことができる。受信側コンピューティングデバイスは、緊急対応センタ内のコンピューティングデバイスを含むことができる。関連付け情報は、統合データソースエンカウンタ構造体にアクセスするためのトークンを含むことができる。サーバは、緊急対応センタ内のコンピューティングデバイスからトークンを受信するようにさらに構成することができる。システムにおいて、送信することは、トークンの受信に応答して、統合データソースエンカウンタ構造体をコンピューティングデバイスに自動的に送信することを含むことができる。モバイルコンピューティングデバイスは、トークンを緊急対応センタ内のコンピューティングデバイスに送信するように構成することができる。
システムにおいて、1又は複数の医療デバイスケースファイルを送信することは、取得されたケースデータの1又は複数のストリームを1又は複数の医療デバイスケースファイルに送信することを含むことができる。統合データソースエンカウンタ構造体は、1又は複数の医療デバイスケースファイルからの取得されたケースデータの1又は複数のストリームを含むことができる。
システムは、少なくとも1つのユーザインタフェースを含むコンピューティングデバイスをさらに備えることができる。コンピューティングデバイスは、統合データソースエンカウンタ構造体を受信し、エンカウンタに続いて、少なくとも1つのユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングするように構成することができる。システムにおいて、複数の医療デバイスは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、及びウェアラブル除細動器のうちの1又は複数を含むことができる。
システムにおいて、関連付け情報は、患者情報を含むことができる。患者情報は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの1又は複数を含むことができる。関連付け情報は、1又は複数の医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの1又は複数の識別子の1又は複数の表現が取得されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの1又は複数の識別子の1又は複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、各医療デバイスの1又は複数の識別子の1又は複数の表現が取得されたときのモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。
システムにおいて、医療デバイスインタフェースは、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも1つを含むことができる。医療デバイスインタフェースは、カメラを備えることができ、1又は複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの1又は複数を含むことができる。
システムにおいて、各医療デバイスの1又は複数の識別子は、1又は複数の一意デバイス識別子に対応する。モバイルコンピューティングデバイスは、エンカウンタの1又は複数のログエントリを生成するようにさらに構成することができる。モバイルコンピューティングデバイスは、統合データソースエンカウンタ構造体に含めるために、1又は複数のログエントリをサーバに送信するように構成することができる。サーバは、モバイルコンピューティングデバイスから遠隔にあることができる。
システムにおいて、取得されたケースデータは、12リードECGデータ等のECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データを含むことができる。取得されたケースデータは、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの1又は複数を含む処置データを含むことができる。取得されたケースデータは、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの1又は複数を含むパフォーマンスデータを含むことができる。取得されたケースデータは、保護された健康情報を含むことができる。
少なくとも1つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタからの医療データを集約するための関連付けサーバが提供される。サーバは、メモリと、ネットワークインタフェースと、メモリ及びネットワークインタフェースと通信可能に結合されている少なくとも1つのプロセッサとを備える。メモリは、患者と緊急ヘルスケア提供者との間のエンカウンタ中に記録された複数の医療デバイスケースファイルからのケースデータを格納するように構成されている少なくとも1つのデータベースを格納する。少なくとも1つのプロセッサは、ネットワークインタフェースを介して、エンカウンタ中に患者を処置するために使用された複数の医療デバイスから複数の医療デバイスケースファイルを受信し、複数の医療デバイスケースファイルからのケースデータを少なくとも1つのデータベースに格納し、ネットワークインタフェースを介して、モバイルコンピューティングデバイスから関連付け情報を受信し、関連付け情報は、複数の医療デバイスの各医療デバイスの少なくとも1つの識別子を含み、複数の医療デバイスケースファイルを互いに関係付けるように関連付け情報に少なくとも部分的に基づいて少なくとも1つの検索基準を生成し、生成された少なくとも1つの検索基準に基づいて、関係付けられた複数の医療デバイスケースファイルを識別し、少なくとも1つのデータベースからの複数の医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を生成するように、関係付けられた複数の医療デバイスケースファイルを集約し、患者と緊急ヘルスケア提供者との間のエンカウンタのレビューのために統合データソースエンカウンタ構造体を受信側コンピューティングデバイスに送信するように構成されている。
関連付けサーバにおいて、統合データソースエンカウンタ構造体を送信することは、統合データソースエンカウンタ構造体をモバイルコンピューティングデバイスに送信することを含むことができる。統合データソースエンカウンタ構造体は、患者情報以外の情報を含むことができる。統合データソースエンカウンタ構造体を送信することは、統合データソースエンカウンタ構造体を複数の医療デバイスのうちの少なくとも1つの医療デバイスに送信することを含むことができる。統合データソースエンカウンタ構造体を送信することは、統合データソースエンカウンタ構造体を緊急対応センタ内のコンピューティングデバイスに送信することを含むことができる。
関連付けサーバにおいて、関連付け情報は、統合データソースエンカウンタ構造体にアクセスするためのトークンを含むことができ、少なくとも1つのプロセッサは、緊急対応センタ内のコンピューティングデバイスからトークンを受信するようにさらに構成することができる。送信することは、トークンの受信に応答して、統合データソースエンカウンタ構造体をコンピューティングデバイスに自動的に送信することを含むことができる。複数の医療デバイスケースファイルを受信することは、複数の医療デバイスからのケースデータの複数のストリームを受信することを含むことができる。統合データソースエンカウンタ構造体は、複数の医療デバイスからのケースデータの複数のストリームを含むことができる。
関連付けサーバにおいて、関連付け情報は、患者情報を含むことができる。患者情報は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの1又は複数を含むことができる。関連付け情報は、複数の医療デバイスケースファイルの少なくとも一部が記録されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの少なくとも1つの識別子の1又は複数の表現が取得されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、各医療デバイスの少なくとも1つの識別子の1又は複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、各医療デバイスの少なくとも1つの識別子の1又は複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。各医療デバイスの1又は複数の識別子は、1又は複数の一意デバイス識別子に対応することができる。
関連付けサーバは、モバイルコンピューティングデバイスから遠隔にあることができる。関連付けサーバにおいて、ケースデータは、ECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データを含むことができる。ケースデータは、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの1又は複数を含む処置データを含むことができる。ケースデータは、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの1又は複数を含むパフォーマンスデータを含むことができる。ケースデータは、保護された健康情報を含むことができる。
少なくとも1つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタからのケースデータを集約するためのモバイルコンピューティングデバイスが提供される。モバイルコンピューティングデバイスは、メモリと、エンカウンタに関するユーザ入力を受信するように構成されているユーザインタフェースと、医療デバイスの識別子の表現を取得するように構成されている医療デバイスインタフェースと、ネットワークインタフェースと、ユーザインタフェース、医療デバイスインタフェース、ネットワークインタフェース、及びメモリと通信可能に結合されている少なくとも1つのプロセッサとを備える。少なくとも1つのプロセッサは、ユーザインタフェースを介して、エンカウンタに関与した複数の医療デバイスの複数の識別子の複数の表現を取得するように入力を受信し、取得された複数の識別子の複数の表現をメモリに格納し、複数の識別子を含む関連付け情報を生成し、エンカウンタ中に複数の医療デバイスによって生成された少なくとも1つの医療デバイスケースファイルからのケースデータを関連付けて集約するために、関連付け情報をサーバに送信するように構成されている。
モバイルコンピューティングデバイスにおいて、少なくとも1つのプロセッサは、ネットワークインタフェースを介して、少なくとも1つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信し、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングするようにさらに構成することができる。統合データソースエンカウンタ構造体は、患者情報以外の情報を含むことができる。ケースデータの一部は、12リードECGデータ等のECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データを含むことができる。ケースデータの一部は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの1又は複数を含む処置データを含むことができる。ケースデータの一部は、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの1又は複数を含むパフォーマンスデータを含むことができる。ケースデータの一部は、保護された健康情報を含むことができる。
モバイルコンピューティングデバイスにおいて、関連付け情報は、患者情報を含むことができる。患者情報は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの1又は複数を含むことができる。関連付け情報は、少なくとも1つの医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、複数の医療デバイスの複数の識別子の複数の表現が取得されたときを示すタイムスタンプ情報を含むことができる。関連付け情報は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含むことができる。関連付け情報は、少なくとも1つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体にアクセスするためのトークンを含むことができ、少なくとも1つのプロセッサは、トークンを緊急対応センタ内のコンピューティングデバイスに送信するように構成することができる。
モバイルコンピューティングデバイスにおいて、医療デバイスインタフェースは、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも1つを含むことができる。医療デバイスインタフェースは、カメラを備えることができ、複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの1又は複数を含むことができる。複数の医療デバイスの複数の識別子は、1又は複数の一意デバイス識別子に対応することができる。少なくとも1つのプロセッサは、エンカウンタの1又は複数のログエントリを生成するようにさらに構成することができる。少なくとも1つのプロセッサは、少なくとも1つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体に含めるために、1又は複数のログエントリをサーバに送信するように構成することができる。モバイルコンピューティングデバイスは、サーバから遠隔にあることができる。
少なくとも1つの例において、患者と緊急ヘルスケア提供者との間のエンカウンタからのケースデータを集約するためのコンピュータ実装プロセスが提供される。コンピュータ実装プロセスは、ユーザインタフェースを介して、エンカウンタに関与した複数の医療デバイスの複数の識別子の複数の表現を取得するように入力を受信する段階と、複数の識別子の取得された複数の表現をコンピュータのメモリに格納する段階と、複数の識別子を含む関連付け情報を生成する段階と、コンピュータのネットワークインタフェースを介して、エンカウンタ中に複数の医療デバイスによって生成された少なくとも1つの医療デバイスケースファイルからのケースデータを関連付けて集約するために、関連付け情報をサーバに送信する段階とを備える。
コンピュータ実装プロセスは、ネットワークインタフェースを介して、少なくとも1つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信する段階と、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングする段階とをさらに備えることができる。コンピュータ実装プロセスにおいて、統合データソースエンカウンタ構造体を受信する段階は、患者情報以外の情報を受信する段階を含むことができる。
コンピュータ実装プロセスは、ネットワークインタフェースを介して、少なくとも1つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信する段階と、ユーザインタフェースを介して、統合データソースエンカウンタ構造体の少なくとも一部をレンダリングする段階とをさらに備えることができる。
コンピュータ実装プロセスにおいて、統合データソースエンカウンタ構造体を受信する段階は、患者情報以外の情報を受信する段階を含むことができる。ケースデータの少なくとも一部をレンダリングする段階は、12リードECGデータ等のECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データをレンダリングする段階を含むことができる。ケースデータの少なくとも一部をレンダリングする段階は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの1又は複数を含む処置データをレンダリングする段階を含むことができる。ケースデータの少なくとも一部をレンダリングする段階は、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの1又は複数を含むパフォーマンスデータをレンダリングする段階を含むことができる。ケースデータの少なくとも一部をレンダリングすることは、保護された健康情報をレンダリングすることを含むことができる。
コンピュータ実装プロセスにおいて、関連付け情報を送信する段階は、患者情報を送信する段階を含むことができる。患者情報を送信する段階は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの1又は複数を送信する段階を含むことができる。関連付け情報を送信する段階は、少なくとも1つの医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を送信する段階を含むことができる。関連付け情報を送信する段階は、複数の医療デバイスの複数の識別子の複数の表現が取得されたときを示すタイムスタンプ情報を送信する段階を含むことができる。関連付け情報を送信する段階は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含むことができる。関連付け情報を送信する段階は、複数の医療デバイスの複数の識別子の複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含むことができる。関連付け情報を送信する段階は、エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含むことができる。関連付け情報を送信する段階は、少なくとも1つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体にアクセスするためのトークンを送信する段階を含むことができ、コンピュータ実装プロセスは、ネットワークインタフェースを介して、トークンを緊急対応センタ内のコンピューティングデバイスに送信する段階をさらに備える。
コンピュータ実装プロセスにおいて、複数の表現を取得するように入力を受信する段階は、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも1つを介して入力を受信する段階を含むことができる。複数の表現を取得するように入力を受信する段階は、カメラを介して入力を受信する段階を含むことができ、複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの1又は複数を含む。複数の識別子の複数の表現を取得するように入力を受信する段階は、複数の一意医療デバイス識別子の複数の表現を取得するように入力を受信する段階を含むことができる。
コンピュータ実装プロセスは、エンカウンタの1又は複数のログエントリを生成する段階をさらに備えることができる。
コンピュータ実装プロセスは、少なくとも1つの医療デバイスケースファイルからのケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体に含めるために、1又は複数のログエントリをサーバに送信する段階をさらに備えることができる。
少なくとも1つの例において、非一時的コンピュータ可読記憶媒体が提供される。非一時的コンピュータ可読記憶媒体は、上で説明されたコンピュータ実装プロセスを実行するように構成されている命令を記憶する。いくつかの例において、非一時的コンピュータ可読記憶媒体は、コンピュータ実装プロセスにおいて参照されるサーバから遠隔にあるモバイルコンピューティングデバイスに組み込まれる。
以下、縮尺通りに描かれることが意図されていない添付図面を参照しながら、本開示の様々な態様が議論される。これらの図は、様々な例の図示及びさらなる理解を提供するために含まれており、本明細書に組み込まれるとともに本明細書の一部を構成するが、本開示の範囲を限定することは意図されていない。図面は、明細書の残りとともに、記載され且つ特許請求されている態様及び例の原理及び作用を説明する役割を果たす。図では、様々な図に示されている各同一又は略同一の構成要素は、類似の数字によって表されている。明確さのために、全ての構成要素が全ての図においてラベル付けされていない場合がある。特定の図における各構成要素の数は、単に一例であり、他の数の各又は任意の構成要素を使用することができる。
本明細書に開示されている少なくとも1つの例に従った医療記録システムの概略ブロック図である。
本明細書に開示されている少なくとも1つの例に従った関連付け情報の1つの例の記録レイアウト図である。
本明細書に開示されている少なくとも1つの例に従った、ヘルスケア提供者が様々な医療デバイスから医療デバイス識別子の表現を取得する緊急医療シーンを示す図である。 本明細書に開示されている少なくとも1つの例に従った、ヘルスケア提供者が様々な医療デバイスから医療デバイス識別子の表現を取得する緊急医療シーンを示す図である。
複数の医療デバイスから医療デバイスケースファイルデータストアへの医療デバイスケースファイル及びデータの流れを示すデータフロー図である。
図3Cの医療デバイスケースファイルデータストアから統合データソースエンカウンタ構造体へのケースデータの処理及び流れを示すデータフロー図である。
本明細書に開示されている少なくとも1つの例に従ったケースファイル集約プロセスを示すフロー図である。
本明細書に開示されている少なくとも1つの例に従った、患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。
関連付け情報に含まれている医療デバイス識別子と合致する医療デバイス識別子を含む医療デバイスケースファイルを識別する例示的な実装に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。
関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義されたターゲット時間範囲内のケース開始時間及びケース終了時間を含む医療デバイスケースファイルを識別する例示的な実装に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。
(a)関連付け情報に含まれている医療デバイス識別子に合致する医療デバイス識別子と、(b)関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義されたターゲット時間範囲内のケース開始時間及びケース終了時間とを含む医療デバイスケースファイルを識別する例示的な実装に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った、医療デバイス、チャート化デバイス、及び患者エンカウンタデータソース統合サービスによって実行される集約プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った、1又は複数の医療デバイスケースファイルの確認を要求するためにePCRアプリケーションによって提供されるユーザインタフェーススクリーンのビューである。
本明細書に開示されている少なくとも1つの例に従ったチャート化デバイス及び患者エンカウンタデータソース統合サービスによって実行されるケースファイル集約プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従ったチャート化デバイス及び患者エンカウンタデータソース統合サービスによって実行されるユーザ確認を伴う集約プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイル関連付けプロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行されるケースファイルデータソース統合プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例に従った患者エンカウンタデータソース統合サービスによって実行される集約されたデータ共有プロセスのフロー図である。
本明細書に開示されている少なくとも1つの例が実施され得るコンピューティングデバイス及び医療デバイスのコンポーネントの例の概略ブロック図である。
本明細書に開示されている少なくとも1つの例に従ったデータ記録を送信するための医療環境の概略ブロック図である。
本明細書に開示されている少なくとも1つの例に従ったデータ記録を送信するための別の医療環境の概略ブロック図である。
本明細書に開示されている少なくとも1つの例に従ったデータ記録を送信するための別の医療環境の概略ブロック図である。
本明細書に開示されている少なくとも1つの例に従ったローカルデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。
本明細書に開示されている少なくとも1つの例に従ったリモートデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。 本明細書に開示されている少なくとも1つの例に従ったリモートデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。 本明細書に開示されている少なくとも1つの例に従ったリモートデータ収集アプリケーションによって提供されるユーザインタフェーススクリーンのビューである。
本明細書に開示されている少なくとも1つの例に従ったローカルデバイスとリモートデバイスとの間のデータ記録送信のフロー図である。
医療緊急エンカウンタの過程中に生成された医療デバイスケースファイルは、異なるソースから生成された様々な形式で出現し、患者処置の情報を与えることができる豊富な医療データを含み、任意の所与の患者エンカウンタに関するより完全な視点をヘルスケア提供者に提供することによって患者アウトカムを改善する。しかしながら、医療デバイスケースファイルの利便性、アクセシビリティ、及び最終的な使用に対する実用上の制限が、特に緊急医療サービスの分野内に存在する。本開示の実施形態によれば、ヘルスケア提供者は、患者エンカウンタが発生している間及び/又はエンカウンタが終了した後に、同じ患者エンカウンタに関連付けられている複数のデバイス(例えば、除細動器/モニタ、人工呼吸器、ドキュメント化デバイス等)をソースとする医療データ(又は他の関係するデータ)を組み込んだ統合データ構造体へのアクセスを得ることが可能であってよい。エンカウンタの統合データ構造体へのデータのこのリアルタイム集約は、ヘルスケア提供者が、患者のためのケアの総合的な状態を評価し、適切な調整を行うために特に有利であり得る。様々な実施形態において、より具体的には、ヘルスケア提供者は、患者エンカウンタのシーンで使用された複数のデバイスを効果的に一緒に関連付けるためにモバイルコンピューティングデバイスを使用し得る。これらの関連付けは、このデバイス関連付けを使用して、複数のデバイスソースからの受信された医療データを一緒に集約する統合データ構造体を生成するために、データソース統合サービスを実行しているサーバであって、複数のデバイスからの医療データを受信もしているサーバに送信されてよい。統合データ構造体は、ケースエンカウンタが進むにつれて、時間とともに継続的にアップデートされ、ヘルスケア提供者のモバイルコンピューティングデバイス及び/又は別のリモートコンピューティングデバイスに(例えば、テレメディシン、テレヘルスの目的で)さらに送信されてよい。
例えば、救急車内における緊急医療サービス(EMS)ヘルスケア提供者のうちの1人のクルーが、緊急医療状態(例えば、心停止、外傷、呼吸窮迫、薬剤オーバードーズ等)を起こした患者を処置すること及び患者を病院に輸送することを要請された例示的なシナリオを検討する。この緊急エンカウンタの過程中、ヘルスケア提供者によって提供される処置は、1又は複数のコンピュータ化医療デバイスを介して実施される場合がある。これらの医療デバイスは、ケースファイルを、エンカウンタ内の重要なイベント及びエンカウンタに関する他の関係する情報をドキュメント化するケースデータを含むオープンデータ構造体(例えば、リアルタイムでのストリーミング及び/又はケース後レビューのために)として記録してローカルに格納することができる。リアルタイムストリーミング及び/又はケース後レビューのためのこのケースデータは、エンカウンタ中に医療デバイスがアクセス可能なセンサによって取得された患者の生理学パラメータ、エンカウンタ中に医療デバイスによって制御可能な治療デバイスを介して患者に実施された処置に関するデータ、EMSヘルスケア提供者のパフォーマンスに関するデータ、保護された健康情報(PHI)、及びエンカウンタ内の重要なマイルストーンに関するデータ(例えば、コード/イベントマーカ)を含むことができる。リアルタイムストリーミング及び/又はケース後レビューのためのケースデータ内に格納される生理学パラメータの例は、心拍数、心電図(ECG)トレース、血圧データ、カプノグラフィックデータ、温度、血液酸素データ等を含む。リアルタイムストリーミング及び/又はケース後レビューのためのケースデータ内に格納された処置データの例は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データを含む。ケースデータ内に格納されたパフォーマンスデータの例としては、とりわけ、胸骨圧迫パフォーマンスデータ、換気パフォーマンスデータ、及びタイムリー薬剤注入情報が挙げられる。この例示的なシナリオが明らかにするように、患者エンカウンタに関与した様々な医療デバイスによって、多種多様な価値のあるケースデータを生成することができる。しかしながら、医療データを含む医療デバイスケースファイルは、複数のデバイスにわたって散在しており、関係するヘルスケア提供者による即時アクセスのための編成を欠いているので、特に患者エンカウンタが展開する際にリアルタイムで、このケースデータにアクセスすることは、EMS及び他のヘルスケア提供者にとって実際的ではない可能性がある。
いくつかの医療デバイスは、それらが一元化ストレージロケーション(例えば、サーバ)に生成する医療デバイスケースファイル(例えば、リアルタイムストリーミングフォーマットのデータ構造体)を送信可能であるが、特定の患者エンカウンタをドキュメント化する医療デバイスケースファイル間にリンケージを確立することは、特にエンカウンタが発生している間又はエンカウンタの直後では、厄介である可能性である。異なる程度の開放性及び相互運用性で使用されている多種多様なコンピュータ化医療デバイスが存在する。また、いくつかのEMSエージェンシに関して、継続的にアップデートされる医療デバイスケースファイルの数は、比較的短い時間窓内であっても多い場合がある。例えば、主要なメトロポリタンエリアにおけるEMSエージェンシは、10~20又はそれよりも多い同時の患者エンカウンタとともに展開される、100程度の除細動器を有する場合がある。
いくつかの患者エンカウンタに関連付けられている生死に関わる重要性及びストレスのレベルを前提とすると、医療デバイスケースファイル(患者エンカウンタ中のケース中レビューのために継続的にストリーミングしているデータ構造体を含み得る)間に即時のリアルタイムリンクを確立することは、特にケースエンカウンタ中に、ヘルスケア提供者の総合的な体験及び最終的には患者ケアの質を向上させるための強力な方法であり得る。したがって、本明細書に開示されている例のうちの少なくともいくつかは、ヘルスケア提供者が、同じ患者に処置を提供するために使用された複数の医療デバイスのそれぞれを一緒にローカルに関連付けるために患者エンカウンタデバイス関連付けアプリケーションとともに構成されたモバイルコンピューティングデバイスを使用し、結果として、サーバベースの患者エンカウンタデータソース統合サービスとの通信時に、複数の医療デバイスのそれぞれから生成された特定の患者に関係する医療データの全て又は少なくとも一部を含む統合データソースエンカウンタ構造体を生成することを可能にする。様々な実施形態に関して本明細書において議論されているように、統合データソースエンカウンタ構造体は、全て同じ患者エンカウンタに対応する、異なるデバイスソースから生成された医療データを同時に統合する集約されたデータ構造体を含んでよい。これにより、ヘルスケア提供者が、リアルタイムストリーミング状況において及び/又はケース後レビュー中に患者エンカウンタに関連付けられている複数のデバイスから生じた関係するデータを閲覧することが可能になる。
以下でさらに詳細に説明されるように、緊急シーンにいるヘルスケア提供者は、モバイルコンピューティングデバイスを使用して、複数の医療デバイスから生成されたデータを効果的に関連付けてよく、この関連付けられたデータは、続いて、エンカウンタ構造体を生成するように構成されているサービスを実行するサーバに送信されると、単一の統合データソースエンカウンタ構造体にして統合することができる。こうして、複数の医療デバイスからのデータを集約する統合患者エンカウンタ構造体を、緊急イベントの過程にわたって及び/又はケース後レビューのために、そのシーンにいるヘルスケア提供者及び/又は遠隔に位置するヘルスケア提供者に利用可能にすることができる。一例として、ヘルスケア提供者は、彼/彼女のモバイルコンピューティングデバイスを使用して、そのシーンにおいて使用された/そのシーンに位置した複数の医療デバイスのそれぞれの識別子又はそれらの表現を取得してよい。患者エンカウンタデバイス関連付けアプリケーションを実行するモバイルデバイスは、次に、識別情報を使用して複数の医療デバイスのそれぞれを一緒に関連付け、関連付け情報を、リモートロケーションに位置する1又は複数のコンピューティングデバイスとすることができる、エンカウンタデータソース統合サービスを実行するサーバシステムに送信してよい。この関連付け情報は、患者エンカウンタを一意に識別するトークン、医療デバイスの識別子、患者エンカウンタに関連付けられているタイムスタンプ情報、患者エンカウンタの地理的ロケーションを識別するジオロケーション情報、及び潜在的には患者エンカウンタに関連付けられている他の情報等の様々な情報要素を含むことができる。サーバシステムは、緊急シーンに位置するとともに患者エンカウンタに関連付けられている医療デバイスのそれぞれから、医療デバイスケースファイル(リアルタイムに継続的にアップデートされてよい)を別個に受信してよい。サーバシステムは、患者エンカウンタに関連付けられていない他のソースから生成された他の医療デバイスケースファイルを図らずも受信してもよい。モバイルコンピューティングデバイスのエンカウンタデバイス関連付けアプリケーションによってアップロードされた関連付け情報をリンクする生成された検索基準に基づいて、サーバシステムは、医療ケースファイル/情報のレポジトリの中を検索し、特定の患者エンカウンタに関連付けられている関係付けられた医療デバイスケースファイルを識別してよい。サーバは、識別された関係付けられた医療デバイスケースファイルから、例えば、緊急シーンにいるヘルスケア提供者及び/又は別の関係するヘルスケア提供者(例えば、テレメディシンを介して応対可能な臨床医)による関係するデータ/イベントの即時のレビューのための単一の統合データソースエンカウンタ構造体を生成してよい。したがって、統合データソースエンカウンタ構造体は、例えば、モバイルコンピューティングデバイスのユーザインタフェース、医療デバイスのうちの1つのユーザインタフェース、又はシーンから遠隔にあるコンピューティングデバイスのユーザインタフェースを介して、レビュー可能であり得る。したがって、ヘルスケア提供者は、サーバ又は複数の医療デバイスのそれぞれのいずれかにおける患者エンカウンタに関連付けられている医療データを要求又は別様に見つける必要がない。むしろ、関係する医療データは、適切な医療デバイスとそれらの関係するケースファイルデータとを効果的に一緒にリンクするために彼/彼女のモバイルデバイスを使用する際に、ヘルスケア提供者に即時に利用可能にされ得る。
図1は、いくつかの例に従って、患者エンカウンタデータソース統合サービス130と、モバイルコンピューティングデバイス104のそれぞれの患者エンカウンタデバイス関連付けアプリケーション150A及び150Bの一部としてのデバイス関連付け生成器142A及び142Bとを備えるとともにこれらを実施する医療記録システム100を示している。システム100は、本開示の例によれば、複数の異なる医療デバイス102A~102Nからのケースファイルを互いに関連付けて、患者エンカウンタの統合データソース構造体を生成することができる。これらの集約された医療記録は、患者エンカウンタをドキュメント化するだけでなく、患者アウトカムを改善するために必要とされる情報をヘルスケア提供者に提供もする。図1に示されているように、医療記録システム100は、ネットワーク112を介して互いに結合されている、1又は複数の医療デバイス102A~102Nと、1又は複数のモバイルコンピューティングデバイス104A~104Cと、リモートコンピューティングデバイス106と、1又は複数のサーバ108とを備える。医療デバイス102A~102Nのそれぞれは、患者エンカウンタ中に患者116に結合するようにさらに構成されている1又は複数の患者インタフェースデバイス190A~190Nに結合するように構成されている。参照しやすさのために、医療デバイス102A~102N、モバイルコンピューティングデバイス104A~104C、患者エンカウンタデバイス関連付けアプリケーション150A~150B、及び患者インタフェースデバイス190A~190Nのそれぞれは、本明細書において、まとめて医療デバイス102、モバイルコンピューティングデバイス104、及び患者インタフェースデバイス190と称されてよい。これらの集合体の個々のメンバは、医療デバイス102、モバイルコンピューティングデバイス104、患者エンカウンタデバイス関連付けアプリケーション150、及び患者インタフェースデバイス190と総称されてもよい。
システム100は、モバイルコンピューティングデバイス104及び医療デバイス102から遠隔に位置してよいサーバ108をさらに備える。例えば、サーバ108は、電力及びネットワーク接続をサーバ108に提供するデータセンタに収容されてよい。図1に示されているように、サーバ108は、医療デバイスケースアプリケーションプログラミングインタフェース(API)126、ePCR API128、患者エンカウンタデータソース統合サービス130、医療デバイスケースデータストア132、患者チャート化データストア134、基準データストア136、イベントログAPI144、及びイベントログデータストア146のうちの1又は複数をホストするように構成することができる。リモートコンピューティングデバイス106は、健康記録データストア110をホストするように構成することができ、これは、患者の医療記録のために医療データを受信して格納することができる。少なくとも1つの例において、サーバ108の関連付けサーバは、患者エンカウンタデータソース統合サービス130をホストする。
システム100の少なくとも一部は、ケースデータを識別するために関連付け情報の複数の態様を利用することが有利である。本開示の実施形態において、モバイルコンピューティングデバイス104は、関連付け情報を生成するために関連付け生成器を含む患者エンカウンタデバイス関連付けアプリケーション150を有してよい。したがって、読み手の理解を補助するために、関連付け情報と、関連付け情報を発生させる医療記録システム100の一部との説明が、患者エンカウンタデータソース統合サービス130及びシステム100の他の部分によって実行されるデータソース統合プロセスの説明の前に提供される。
いくつかの例において、関連付け情報は、2又は2よりも多い医療デバイスケースファイルが特定の患者エンカウンタ内に生成されたか否かを決定するのに有用なデータの任意の要素を含む。したがって、多種多様なデータを、様々な例において関連付け情報として特徴付けることができる。例えば、いくつかの例において、関連付け情報は、ケースファイルを生成した医療デバイス102の1又は複数の識別子、患者エンカウンタ中に処置された患者に関する情報(例えば、患者名又は患者の他の識別子、年齢、性別、体重、身長、及び/又は既往歴)、患者エンカウンタ中に記録されたタイムスタンプ情報(例えば、医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ及び/又は医療デバイス102の1又は複数の識別子が取得されたときを示すタイムスタンプ)、患者エンカウンタ中に記録されたジオロケーション情報(例えば、モバイルコンピューティングデバイス104が医療デバイス102の1又は複数の識別子を取得した地理的ロケーションを識別するジオタグ)、及び/又は患者エンカウンタ中のモバイルコンピューティングデバイス104の患者エンカウンタデバイス関連付けアプリケーション150によるトークン(例えば、ユニバーサル一意識別子(UUID)又は患者エンカウンタを一意に識別するデータ)を含むことができる。関連付け情報は、以下でさらに詳細に議論される、イベントログデータ及び/又はチャート化データの一部も含むことができる。
関連付け情報は、多種多様なソースから発生することができる。例えば、いくつかの例において、それぞれのエンカウンタデバイス関連付けアプリケーション150の関連付け生成器142A及び142Bは、要求を受けると関連付け情報を生成するように構成されている。いくつかの例において、要求は、システム100によってホストされている他のプロセス(例えば、ePCRアプリケーション122及び/又はイベントログアプリケーション140)から受信されるシステムメッセージ内に埋め込むことができる。これらの例において、関連付け生成器142A及び142Bは、関連付け情報の要求された要素(例えば、特定の患者エンカウンタを識別するトークン)を生成し、関連付け情報の要求された要素を要求側プロセスに戻すように構成されている。いくつかの例において、関連付け情報の要求は、モバイルコンピューティングデバイス104のユーザインタフェースから受信された入力とすることもできる。これらの例において、関連付け生成器142A及び142Bは、要求された関連付け情報を生成し、後続の処理のために関連付け情報をローカルに格納するように構成されている。代替的に又は加えて、いくつかの例において、ePCRアプリケーション122及び/又はイベントログアプリケーション140は、それらのエンカウンタドキュメント化プロセスの実行を介して関連付け情報を生成するように構成されている。ePCRアプリケーション122及び/又はイベントログアプリケーション140によって生成された関連付け情報の例は、本明細書において議論されているようにePCRアプリケーション122及び/又はイベントログアプリケーション140によって収集される他のタイプの情報の中でも、患者人口統計学情報及び/又は生理学情報を含むことができる。
図2は、関連付け生成器142A及び142Bが個々に又はePCRアプリケーション122及び/又はイベントログアプリケーション140と連携して生成するように構成されている関連付け情報の記録の1つの例を示している。図2に示されているように、関連付け情報記録は、エンカウンタIDフィールド202と、第1の医療デバイスIDフィールド204と、第1のタイムスタンプフィールド206と、第2の医療デバイスIDフィールド208と、第2のタイムスタンプフィールド210とを含む。この例において、エンカウンタIDフィールド202は、トークン(ここではUUID)を格納するように構成されており、第1の医療デバイスIDフィールド204及び第2の医療デバイスIDフィールド及び208は、医療デバイスシリアルナンバを格納するように構成されており、第1のタイムスタンプフィールド及び第2のタイムスタンプフィールド206及び210は、同じ患者エンカウンタに関係するケースファイルを一緒に関連付けるのに使用されてよいタイムスタンプを格納するように構成されている。図2を考慮すれば理解されるように、関連付け情報記録200は、第1の医療デバイス及び第2の医療デバイス並びにそれらのそれぞれのタイムスタンプを、エンカウンタID202によって一意に識別される患者エンカウンタに関係付ける。さらに、以下で詳細に説明されるように、関連付け情報記録200内の各<医療デバイスID,タイムスタンプ>値ペアは、エンカウンタID202によって識別される患者エンカウンタ中に生成された医療デバイスケースファイルを高い信頼度で識別するのに必要な情報を、患者エンカウンタデータソース統合サービス130に提供する。
図1に戻ると、いくつかの例において、患者エンカウンタデータソース統合サービス130は、関連付け情報をモニタするとともにこれを受信するように構成されている。例えば、いくつかの例において、患者エンカウンタデータソース統合サービス130は、ネットワーク112を介して受信されるインバウンド関連付け情報についてチャート化データストア134及び/又はイベントログデータストア146をモニタするように構成されている。代替的に又は加えて、患者エンカウンタデータソース統合サービス130は、ネットワーク112を介して受信される関連付け情報を含むePCR API128及び/又はイベントログAPI144からのメッセージを受信するように構成することができる。それにもかかわらず、インバウンド関連付け情報は、例えば、モバイルコンピューティングデバイス104によって生成され送信された1又は複数の新たな又は修正されたePCR又はイベントログをソースとすることができる。代替的に又は加えて、インバウンド関連付け情報は、例えば、関連付け生成器142A及び/又は142Bのうちの1つによって送信される別個のメッセージをソースとすることができる。現実的な使用シナリオの状況内でのこれらのプログラムの動作は、以下でより詳細に説明される。
インバウンド関連付け情報をハンドリングするために、患者エンカウンタデータソース統合サービス130は、インバウンド関連付け情報に関連付けられている患者エンカウンタ中に生成された1又は複数のケースファイルから発生したケースデータストア132内のケースデータを識別することを試みる1又は複数のプロセスを実行するように構成されている。これらのプロセスの例は、図4~図17を参照して以下で詳細に説明される。患者エンカウンタデータソース統合サービス130は、インバウンド関連付け情報に関連付けられている患者エンカウンタ中に生成されたケースデータを識別することに応答して、いくつかのアクションのうちの1又は複数を取るように構成することができる。これらのアクションは、ケースデータを含む集約された医療データを生成すること及び/又はケースデータをチャート化データ及び/又はイベントログデータと組み合わせること、集約された医療データを(例えば、チャート化データストア134及び/又はイベントログデータストアに)格納すること、統合データソースエンカウンタ構造体の形式の集約された医療データ若しくはその一部を含むメッセージを送信すること、及び/又はケースデータ若しくはケースデータの識別子を含むメッセージを送信することを含んでよい。これらのメッセージは、ネットワーク112と、ePCR API128、イベントログAPI144、及びケースAPI126のうちの1又は複数とを介して、モバイルコンピューティングデバイス104、医療デバイス102、及び/又はリモートコンピューティングデバイス106に(例えば、健康記録データストア110における格納のために)送信することができる。対応するケースデータを識別することに応答して患者エンカウンタデータソース統合サービス130が取るように構成されてよいこれらのアクション及び他のアクションは、図4~図17を参照して以下でも詳細に説明される。
[EMS例]
いくつかの例において、例えばEMS技術者であってよいヘルスケア提供者118Aは、患者116をモニタする及び/又は処置するために、医療デバイス102のうちの1又は複数に結合された患者インタフェースデバイス190A~190N(例えば、生理学センサ、ECGセンサ、SpO2センサ、カプノグラフィセンサ、血圧センサ等)を患者116に取り付けることができる。この処置は、医療デバイス102が関与してよく、イベント及び他の情報等の特定の態様は、モバイルコンピューティングデバイス104のうちの1つのePCRアプリケーション122及び/又はイベントログアプリケーション140を介してヘルスケア提供者118Aによってドキュメント化されてよい。
本明細書において議論されるように、図3A~図3Cにより具体的に示されているもの等の複数の異なるタイプの医療デバイス102を用いてよい。例えば、本明細書において議論されるように、除細動器/モニタ302Bは、数例を挙げると、患者情報(例えば、名前、性別、サイズ、体重、年齢、身長、病歴等)、生理学情報(例えば、とりわけ、ECG波形、レビューのためにマークされた/注記された特定の注目に値するイベントの前及び/又は後のECGスナップショット、心拍数、酸素飽和度データ、CO2データ、血圧データ)、処置情報(例えば、薬剤注入、電気治療イベント、胸骨圧迫の開始、換気の開始)、及びヘルスケア提供者パフォーマンス情報(例えば、平均胸骨圧迫深さ、平均胸骨圧迫回数、深さ/回数に関するターゲットに入る胸骨圧迫のパーセンテージ、平均放出速度、プレショックCPRポーズ、ポストショックCPRポーズ、換気の一回換気量データ、分時換気量データ、換気回数データ、薬剤注入タイミング等)を含む、様々な異なるタイプのデータを収集してよい。ECG波形及び/又はECGスナップショットは、標準的な12リードレポートを生成するために、患者の身体に結合された10又はそれよりも多い電極を使用して捕捉されてよい。除細動器/モニタ302Bによって収集された情報の一部又は全ては、取得されたら、定期的な間隔でアップデートされてよい医療デバイスケースファイルとして、ネットワークを介して1又は複数のサーバに(例えば、図1のサーバ108及びネットワーク112に、継続的に、定期的に、及び/又はケース後に)アップロードされてよい。各医療デバイスケースファイルは、識別情報、例えば、ケースファイルの発生元であるデバイスの識別子、患者エンカウンタの開始、終了、時間の長さに関係するタイムスタンプデータ、及び/又は患者エンカウンタ中のデバイスのジオロケーション情報を有することができる。適切な除細動器/モニタの一例は、ゾールメディカルコーポレーションによって提供されるX Series(登録商標)除細動器/モニタであるが、他の好適な除細動器/モニタデバイスを本開示に従って使用してもよい。
図3Aに示されているように、患者エンカウンタに関係する他のケースファイルとの集約のためにサーバ108に継続的なリアルタイムデータを送信しているそのシーンに位置する他の医療デバイスは、例えば、人工呼吸器302C、自動化胸骨圧迫器302A、及び/又は他の医療デバイスを含んでよい。例えば、人工呼吸器302Cは、患者情報(例えば、名前、性別、サイズ、体重、年齢、身長、病歴等)、生理学情報(例えば、とりわけ、心拍数、酸素飽和度データ、CO2データ)、処置情報(例えば、吸入中酸素濃度、最大吸気圧設定、一回換気量、分時換気量、換気回数)、及び/又は他の関係する情報を含む様々なタイプのデータを収集し、それを取得するとサーバ108に(継続的に、定期的に、及び/又はケース後に)送信してよい。様々な例において、人工呼吸器302Cは、ゾールメディカルコーポレーションによって提供されるZ Vent(登録商標)人工呼吸器に類似する機能を有してよいが、他の人工呼吸器を用いてもよい。自動化胸骨圧迫器302Aは、患者情報、生理学情報、胸骨圧迫設定(例えば、深さ、レート、デューティサイクル等)及び/又は他の関係する情報等の処置情報を含む特定のタイプのデータを取得すると、それを(継続的に、定期的に、及び/又はケース後に)送信してもよい。特定の例において、自動化胸骨圧迫器302Aは、ゾールメディカルコーポレーションによって提供されるAutoPulse(登録商標)胸骨圧迫デバイスの機能に類似する機能を有してよいが、他の好適な胸骨圧迫デバイスを使用してもよい。除細動器/モニタ302Bと同様に、このようなデバイスは、収集された情報の一部又は全てを、それぞれそれらの独自の識別情報を伴う医療デバイスケースファイルとしてサーバ108に送信してよい。結果として、特定の医療緊急事態に関係する情報は、グループ化され、一緒に集約されてよく、関連付けを開始したオリジナルヘルスケア提供者は、シーンにいるか又はシーンから遠隔にいるかのいずれかの他の適切な人員とともに、情報に対するリアルタイムアクセスを有する。
図3Aに示されているように、緊急医療イベント中、ヘルスケア提供者118Aは、単一の患者(例えば、図1の患者116)に対して、自動化胸骨圧迫器302A、除細動器/モニタ302B、及び人工呼吸器302Cを使用する。本明細書において議論されるように、自動化胸骨圧迫器302Aは、用手圧迫を与えることをヘルスケア提供者に要求することなく、指定された圧迫深さ及び回数パラメータに従って患者に胸骨圧迫を実施するために使用されてよい。除細動器/モニタ302Bは、例えば、患者が生命を脅かす不整脈を起こしたか否かを評価する際に除細動電極及び/又は生理学情報を収集するため及び患者をモニタするための他の患者センサを介して患者に接続されてよい。人工呼吸器302Cは、挿管チューブ又はマスクを通して患者に酸素を提供してよい。これらの医療デバイス302A、302B、302Cのそれぞれは、患者エンカウンタに関係するデータを収集するように構成されており、さらなる処理のために、このデータをサーバ108上に格納されたケースファイルの大型中央レポジトリにアップロードしてよい。
患者エンカウンタのシーンにいるヘルスケア提供者118Aは、ドキュメント化ツールを通して、注目に値するイベントのログエントリを生成する、及び/又は、ePCRのためのチャート化ツールを介して患者情報を入力する等、彼らのそれぞれのモバイルコンピューティングデバイスをさらに使用して、他の情報を生成してよい。そのような記録も、他の医療デバイスケースファイルとともにサーバ108の中央レポジトリにアップロードされてよい。通常、別のユーザは、ケースファイルのこのレポジトリを取捨選択して、さらなる閲覧のために様々なファイルからの情報を互いに合致させる必要があるが、本開示の例は、リアルタイムに、患者エンカウンタ中及び/又は後に閲覧するために、特定の患者エンカウンタに関係するケースファイルを、関連付けるか又は別様に一緒にリンクさせて、単一の記録に集約させることを可能にする。
例えば、図3Aに示されているように、シーンにいるヘルスケア提供者118Aは、エンカウンタデバイス関連付けアプリケーション(例えば、図1の患者エンカウンタデバイス関連付けアプリケーション150)を実行するモバイルコンピューティングデバイス104Bを使用して、患者エンカウンタのケースファイルを総合するためにサーバ108によって使用されてよい関連付け情報を生成する。例えば、ヘルスケア提供者118Aは、患者エンカウンタ前、中、又は後に、モバイルコンピューティングデバイス104Bとともに含まれる医療デバイスインタフェースを使用して、各医療デバイスの表現を取得するために医療デバイスから医療デバイスに移動することができる。例えば、ヘルスケア提供者118Aは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Bの一部であるカメラを使用して、除細動器/モニタ302Bに付けられている第1のクイックレスポンス(QR)コードをスキャン(例えば、そのイメージを取得)することができる。又は、ヘルスケア提供者118Aは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Bに含まれている近距離通信(NFC)リーダを、除細動器/モニタ302Bに付けられている又はその内に収容されているNFCタグに近接するように位置付けて、除細動器/モニタ302Bを識別する磁気シグネチャを取得することができる。次に、ヘルスケア提供者118Aは、自動化胸骨圧迫器302Aまで移動して、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Bとインタラクトして、自動化胸骨圧迫器302Aに付けられたクイックレスポンス(QR)コードをスキャンすることができる。又は、ヘルスケア提供者118Aは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Bに含まれているNFCリーダを、自動化胸骨圧迫器302Aに付けられている又はその内に収容されているNFCタグに近接するように位置付けて、自動化胸骨圧迫器302Aを識別する磁気シグネチャを取得することができる。最後に、図3Aに示されているように、ヘルスケア提供者118Aは、人工呼吸器302Cまで移動して、人工呼吸器302Cを識別する磁気シグネチャを取得するために、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Bに含まれているNFCリーダを、人工呼吸器302Cに付けられている又はその内に収容されているNFCタグに近接するように位置付けることができる。NFCタグの代わりに、ヘルスケア提供者118Aは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Bを使用して、人工呼吸器302Cに付けられているクイックレスポンス(QR)コードをスキャンすることができる。上で説明したイメージ及び磁気シグネチャの取得は、いくつかの緊急患者エンカウンタでは時間が最も重要であるため、設計上迅速で軽量であることに留意すべきである。これらの状況において、ヘルスケア提供者118Aは、患者エンカウンタに関与する各医療デバイスとロバストな双方向の完全に認証されたネットワーク通信セッションを確立することが可能でなくても又はその意思がなくてもよい。さらに、これらの軽量通信メカニズムは、医療デバイスに、それらが提供する一方向通信及び制限された機能に起因して、医療デバイスをハックするために利用することができない点でさらなるセキュリティを提供する。
代替的に又は加えて、図1と組み合わせて参照される図3Aによって示されているいくつかの例において、ヘルスケア提供者118Aは、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Bを使用して、イベントログアプリケーション140、ePCRアプリケーション122、又は関連付け生成器142A及び142Bのいずれかのうちの任意のものによって提供されるユーザインタフェースに適切な入力を供給することによって医療デバイスの識別子の表現を取得することができる。様々な例において、これらのプログラムのそれぞれは、医療デバイスの識別子の表現を取得する要求を示す入力を受信し、識別子の表現をスキャンする又は別様に取得するように医療デバイスインタフェースを制御することによって、そのような要求に応答するように構成されている。このようにスキャンされたQRコード(登録商標)(又は取得された関係する識別タグ)は、この特定の患者エンカウンタを識別するトークン及び表現が取得された時間を示すタイムスタンプとともに、関連付け情報に格納することができる。関連付け情報に格納することができる他の情報として、各表現の取得時におけるモバイルコンピューティングデバイス104Bのジオロケーションを示すジオタグが挙げられる。関連付け情報が完成した後、その作成を担当するプログラムは、関連付け情報をローカルに(例えば、ローカルイベントログデータ、チャート化データ内に、又は別個の関連付け情報として)格納し、及び/又は、適切なインタフェース(例えば、ePCR API128及び/又はイベントログAPI144)を介して、関連付け情報を別個の関連付け情報として又はチャート化データ及び/又はイベントログデータに関連付けて及び/又はそれらに埋め込んでサーバ108に送信することができる。医療デバイスの表現は、患者エンカウンタ中、又はいくつかの場合では患者エンカウンタの前若しくは後であっても、任意の時間に取得することができることに留意すべきである。いくつかの例において、ユーザは、特定の患者エンカウンタに関係するケースファイルを関連付けるために、関連付け情報を生成して適切なサーバに送信するように、モバイルコンピューティングデバイス104Bに確認を提供する。
いくつかの例において、表現を取得し、これらを、医療デバイス302A~302Cを識別するデータに変換し、ユーザ確認を受信した後、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルデバイス104Bは、関連付け情報を(例えば、図2に示されているように)生成し、ネットワーク112を介して関連付け情報をサーバ108に送信する。いくつかの例において、モバイルコンピューティングデバイス104Bは、リアルタイムで、ネットワーク112を介してサーバ108から、医療デバイス302A~302Cによってそれらの患者116の処置中に生成された医療デバイスケースファイルからの情報を含む統合データソースエンカウンタ構造体を受信することができる。これらの例において、エンカウンタデータソース統合サービスを提供するサーバ108は、関連付け情報の受信に応答して、統合データソースエンカウンタ構造体を自動的に生成し送信するように構成されている。
さらに、図3Aに示されているように、サーバ108は、ヘルスケア提供者118Bがヘルスケア提供者118Aにサポートを提供することを可能にするために、患者116の受け入れの準備するために、及び/又はテレメディシンの目的で、統合データソースエンカウンタ構造体をモバイルコンピューティングデバイス104Cに送信するように構成することができる。いくつかの例において、エンカウンタレビューアプリケーション148は、サーバ108から統合データソースエンカウンタ構造体を受信し、モバイルコンピューティングデバイス104Cのユーザインタフェースを介して、統合データソースエンカウンタ構造体をヘルスケア提供者118Bに提供するように構成されている。少なくともいくつかの例において、エンカウンタレビューアプリケーション148は、ゾールメディカルコーポレーションによって提供されるRescueNet(登録商標)コードレビューを含むことができる。いくつかの実施形態において、エンカウンタレビューアプリケーション148は、関連付け情報を生成することと統合データソースエンカウンタ構造体の集約されたデータをレビューすることとの両方のために同じソフトウェアアプリケーションが使用されてよいという点で、エンカウンタデバイス関連付けアプリケーションと一致してよい。
さらに、本開示の例は、緊急事態中の異なる時点で患者に適用された医療デバイスから生成されたデータが集約されることを可能にし得る。図3Bは、緊急エンカウンタが3つの別個のフェーズ315A、315B及び315Cにセグメント化された一例を示している。フェーズ315Aにおいて、患者(例えば、患者116)は、現在病院におらず、突然の心停止等の医療緊急事態を起こしている。このような状況において、大群の適切な医療デバイスが即時に存在することは稀である。事実、医療経験が非常に乏しい居合わせた人物300のみが救護に携わることができる可能性がより高い。居合わせた人物300は、例えば、付近のウォールキャビネットに保管されているパブリックアクセス自動体外式除細動器(AED)302Dを見つけ、緊急医療サービス(EMS)に電話をかける冷静沈着さを有し得る。居合わせた人物300は、次に、除細動電極パッドを患者に適用して、AEDによって提供されるステップバイステップの指示に従って、CPRを実施してよく、AEDの例としては、ゾールメディカルコーポレーションによって提供されるAED Plus(登録商標)又はZOLL AED3(登録商標)パブリックアクセスAEDが挙げられ得る。いくつかの例において、AED302Dは、患者のECG波形、与えられた除細動ショックの数、除細動ショックに関連付けられているECGスナップショット、及び胸骨圧迫パフォーマンス情報等のデータを収集してよく、本明細書においてさらに説明するように、そのような情報を関連付け能力を有するサーバ108にアップロードしてよい。
本明細書において説明されている例によれば、フェーズ315BにおいてEMSが到着すると、ヘルスケア提供者118Aは、モバイルコンピューティングデバイス104を介してその中に格納されているケースデータにアクセスしようとして、患者エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104を使用して、AED302Dの識別子の表現を迅速に取得(例えば、QRコード識別子をスキャン、NFC又は無線周波数識別(RFID)タグ識別子を取得)することができる。さらに、より多くの医学訓練を受けているヘルスケア提供者118Aは、より高度なケア及び生理学モニタリングのために、血圧センサ及びSpO2センサ等の他のセンサとともに、プロフェッショナルグレード除細動器/モニタ302Bを使用して、ECG電極(例えば、12リード、3リード)を取り付けてよい。到着すると、より高度な除細動器/モニタ302Bは、例えば、とりわけ、心拍数、患者のECG波形、与えられた除細動ショックの数、除細動ショックに関連付けられているECGスナップショット、血圧読み取り値/傾向、酸素飽和度読み取り値/傾向、薬剤注入、胸骨圧迫及び換気パフォーマンス情報等のデータも収集してよい。そのような情報は、データが患者エンカウンタ中に時間とともにアップデートされるのと同時に、継続的及び/又は定期的に、関連付け能力を有する適切なサーバ108にアップロードされてよい。本開示の態様によれば、ヘルスケア提供者118Aは、エンカウンタデータソース統合サービスが2つのデバイス並びに関係する患者及び処置情報を含む対応するケースファイル/データを特定の緊急イベントに関連付けるために、エンカウンタデバイス関連付けアプリケーションを実行するモバイルコンピューティングデバイス104を使用して、AED302D及び除細動器/モニタ302Bの識別子(例えば、スキャンされたQR/バーコード、NFC接続又はRFIDを介した取得)を取得してよい。
フェーズ315Cにおいて、EMSは、患者が即時の病院ケアを要求すると決定してよく、したがって、病院に向かう途中でのケアのための自動化胸骨圧迫器302A及び人工呼吸器ユニット302Cをさらに装備した救急車を介した輸送を開始してよい。本明細書において議論されるように、様々な例において、自動化胸骨圧迫器302Aは、予め指定されたパラメータに従って胸骨圧迫を提供してよく、人工呼吸器ユニット302Cは、患者の酸素飽和度及び心拍数レベルをモニタし、例えば、ユーザ補助を伴って自動化換気を実施してよい。ヘルスケア提供者118Aは、エンカウンタデータソース統合サービスが、追加の2つのデバイス並びに患者情報及び処置情報を含むそれぞれのケースファイルをこの特定の緊急イベントに関連付けることが可能であるように、エンカウンタデバイス関連付けアプリケーションを実行しているモバイルコンピューティングデバイス104Aをさらに使用して、自動化胸骨圧迫器302A及び人工呼吸器302C識別子(例えば、スキャンされたQR/バーコード、NFC接続を介した取得)を取得してよい。ヘルスケア提供者118Aは、モバイルデバイス104を使用して、特定の緊急患者/イベントに関する4つの別個のデバイスによって生成された情報を一緒に関連付けることをエンカウンタデータソース統合サービスにさらに要求してよく、関連付け能力を有するサーバ108は、アップロードされたケースファイルから提供される医療データを統合データソースエンカウンタ構造体に集約することができる。結果として得られる統合データソースエンカウンタ構造体は、次に、居合わせた人物300によって及びEMSによって、またさらには、緊急事態においてさらにより多くの医療デバイスを使用し得る病院(この例では具体的に説明されない)によって処置された患者116に関する関係データの全てを含んでよい。様々な例において、この統合データソースエンカウンタ構造体は、リアルタイム及び/又はケース後レビューのために、患者の近傍又は遠隔のいずれかに位置する適切なヘルスケア提供者に送信することができる。以下でさらに説明される図3C及び図3Dは、これらの例のうちのいくつかにおけるデータの例示的なフローを示している。
より具体的には、図3Cは、いくつかの例の送信及び格納アクティビティを示すデータフロー図である。図3Cに示されているように、医療デバイス302A~302Dは、それぞれのケースファイル304A~304Dをそれぞれ生成してよく、これは、患者エンカウンタの過程を通して継続的及び/又は定期的にアップデートされてよい。ケースファイル304A~304Dのそれぞれは、例えば、図3A及び図3Bに示されているように、患者116とのエンカウンタ中にその関連付けられた医療デバイスによって生成されたケースデータを含む。例えば、ケースファイル304Aは、自動胸骨圧迫器302Aによって記録されたケースデータを格納する。ケースファイル304Aは、自動胸骨圧迫器302Aの識別子、自動胸骨圧迫器302Aによって検出されたイベント、これらのイベントに関する詳細、及び各イベントが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図3Cに示されているように、自動胸骨圧迫器302Aが検出しケースファイル304Aに記録するイベントのタイプは、開始/電源オンイベント、終了/電源オフイベント、及び自動化圧迫設定の構成を含む。自動化圧迫設定は、他の設定の中でも、深さ、レート、及びデューティサイクルを含むことができる。様々な実施形態において、デバイス302Aは、データを取得するとケースファイル304Aを継続的にアップデートし、これは、患者エンカウンタデータソース統合サービスを実行しているサーバにさらにアップロードされる。
図3Cを引き続き参照すると、ケースファイル304Bは、除細動器/モニタ302Bによって記録されたケースデータを格納し、これは、患者エンカウンタの過程を通して継続的及び/又は定期的にアップデートされてよい。ケースファイル304Bは、除細動器/モニタ302Bの識別子、除細動器/モニタ302Bによって検出されたイベント及びパラメータ、これらのイベント及びパラメータに関する詳細、並びに各イベント又はパラメータが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図3Cに示されているように、除細動器/モニタ302Bが検出してケースファイル304Bに記録するイベント及びパラメータのタイプは、開始/電源オンイベント、終了/電源オフイベント、患者の血圧の測定(観血及び非観血)、患者のパルスオキシメトリ(瞬間的及び傾向)、患者の呼気終末二酸化炭素読み取り値(瞬間的及び傾向)、治療パッド取り付けイベント、患者に取り付けられた治療パッドに関する情報、患者に送達された電気治療ショックを記述する情報、患者に送達された用手CPR圧迫を記述するデータ、患者に実施された用手換気を記述するデータ、電気治療ショック付近で(例えば、その前後10秒以内に)記録された患者の心臓活動を記述するECGスナップショット、除細動器/モニタ302Bの動作のモード(自動又は手動)、電気治療ショック送達とは独立して記録された患者のECG情報、患者のカプノグラフィ情報、及び治療パッド取り外しイベントを含む。ECG情報及び/又はECGスナップショットは、除細動器/モニタ302Bに関連付けられている12リードECGレポートを生成するために使用されてよい。したがって、患者記録(例えば、ケースファイル304Bを含む)は、12リードECGレポートを含んでよい。血圧測定は、収縮期及び/又は拡張期とすることができる。治療パッドに関する情報は、治療パッドの作り、モデル、タイプ、及びインピーダンスを含むことができる。電気治療ショックを記述する情報は、送達されたジュール数及び遭遇したインピーダンスを含むことができる。用手圧迫を記述するデータは、平均深さ及び平均回数を含むことができる。用手換気を記述するデータは、平均一回換気量及び平均換気回数を含むことができる。様々な実施形態において、デバイス302Bは、データを取得するとケースファイル304Bを継続的にアップデートし、これは、患者エンカウンタデータソース統合サービスを実行しているサーバにさらにアップロードされる。
図3Cを引き続き参照すると、ケースファイル304Cは、人工呼吸器302Cによって記録されたケースデータを格納し、これは、患者エンカウンタの過程を通して継続的及び/又は定期的にアップデートされてよい。ケースファイル304Cは、人工呼吸器302Cの識別子、人工呼吸器302Cによって検出されたイベント及びパラメータ、これらのイベント及びパラメータに関する詳細、並びに各イベント又はパラメータが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図3Cに示されているように、人工呼吸器302Cが検出してケースファイル304Cに記録するイベント及びパラメータのタイプは、開始/電源オンイベント、終了/電源オフイベント、人工呼吸器設定の構成、患者のパルスオキシメトリ(瞬間的及び傾向)、患者の呼気終末二酸化炭素読み取り値(瞬間的及び傾向)、及び患者のカプノグラフィ情報を含む。換気設定は、一回換気量、レート、最大吸気圧、最大呼気終末陽圧、及び吸入中酸素濃度を含むことができる。様々な実施形態において、デバイス302Cは、データを取得するとケースファイル304Cを継続的にアップデートし、これは、患者エンカウンタデータソース統合サービスを実行するサーバにさらにアップロードされる。
ケースファイル304Dは、AED302Dによって記録されたケースデータを格納する。ケースファイル304Dは、AED302Dの識別子、AED302Dによって検出されたイベント及びパラメータ、これらのイベント及びパラメータに関する詳細、並びに各イベント又はパラメータが検出された時間を示すタイムスタンプをドキュメント化するケースデータ記録を含む。図3Cに示されているように、AED302Dが検出してケースファイル304Dに記録するイベント及びパラメータのタイプは、開始/電源オンイベント、終了/電源オフイベント、治療パッド取り付け及び取り外しイベント、患者に取り付けられた治療パッドに関する情報、患者に送達された電気治療ショックを記述する情報を含む。電気治療ショックを記述する情報は、送達されたジュール数及び遭遇したインピーダンスを含むことができる。
組み合わせで、ケースファイル304A~304Dは、患者エンカウンタ中に患者116が受けたケアの時系列。ケースファイル304A~304Dに格納されたケースデータは、単に図示の目的で提供されており、本明細書において説明された例は、このタイプ又は任意の他のタイプのケースデータに限定されない。
いくつかの例において、ケースファイル304A~304Dのそれぞれは、パースされて、ケースデータストア(例えば、図1のケースデータストア132)にインポートされる。このパース及びインポートのプロセスは、様々なケースファイル304A~304D間のフォーマット及びコンテンツにおける多くの差異を考慮し、ケースファイルに含まれているケースデータ、及び/又はケースファイルそれら自体のコピーをケースデータストアに格納する。図3Cに示されているように、ケースファイル及び/又はケースデータは、任意の様々なデータタイプ、モデル、及びフォーマットに従って格納することができる。また、図3Cに示されているように、ケースデータストアは、ケースファイル及び様々な他の医療デバイス306からのデータを格納することができる。ケースファイル及びデータのこの標準化された一元化ソースは、多くの利点を提供し、ケースデータストアの包含は、単一の患者エンカウンタから発生したケースファイル及びデータ等の特定の共通の関心を伴うケースファイル及びデータを効率的に検索し見つけるためのメカニズムの必要性も生じさせる。
図3Dは、いくつかの例の関連付け、統合/集約、及びレポートアクティビティを示すデータフロー図である。図3Dに示されているように、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)は、特定の患者エンカウンタ中に生成されたケースデータストア311内に格納されたケースファイル及びデータを検索して見つけるために関連付け情報を利用するように構成することができる。ケースデータストア311は、図1のケースデータストア132の1つの非限定的な例である。図3Dに示されているように、ケースデータストア311は、ケースデータストア311にインポートされ格納されたケースファイルをリストするテーブル307を含む。このテーブルは、ケースファイルを発生させた医療デバイスの識別子、医療デバイスケースファイルでのタイムスタンプ情報、ケースファイルの一意の識別子、及びバイナリラージオブジェクト(blob)として格納されたケースファイルのコピーを格納する。ケースデータストア311は、容易で迅速な標準化されたアクセスのために、ケースファイルからパースされたケースデータを格納するさらなるテーブルも含む。テーブル309は、1つの例に係る、自動化胸骨圧迫器によって使用された構成設定を格納するようなテーブルの1つの例を示している。他のテーブルレイアウト及び総合的なデータベーススキーマを本明細書に開示されている様々な例とともに使用することができ、これはケースデータを編成する特定のアプローチに限定されない。
図3Dに示されているように、患者エンカウンタデータソース統合サービスは、関連付け情報301を受信してパースするように構成されている。これらの例において、患者エンカウンタデータソース統合サービスは、パースされた関連付け情報(例えば、デバイス識別子及びタイムスタンプ)を使用して、ケースデータストア132内で、関連付け情報に対応するとともにそれによって識別される患者エンカウンタに関与した医療デバイスを検索して識別するようにさらに構成することができる。患者エンカウンタデータソース統合サービスは、識別された医療デバイスによって生成されたケースファイルを互いに関連付け、様々な関連付けられたケースファイルからのケースデータ及び/又はケースファイルそれら自体のコピーを含む統合データソースエンカウンタ構造体308を生成するようにさらに構成することができる。患者エンカウンタデータソース統合サービス130の動作の詳細は以下でさらに提供されるが、図3Dに示されているように、いくつかの例において生成された統合データソースエンカウンタ構造体308は、各関連付けられたケースファイルからのケースデータの少なくとも一部を含む。この統合データソースエンカウンタ構造体を使用して、ヘルスケア提供者118C等のヘルスケア提供者は、例えば、患者116が居合わせた人物300によって処置されている間に実施されたショック、患者116がシーンでヘルスケア提供者118Aによって処置されている間に実施されたショック、及び病院に向かう途中で患者116に与えられた他の処置をレビューすることができる。
図3A~図3Dは、概して、モバイルデバイスを使用して、複数の医療デバイスを識別し、これらの複数のデバイスから、統合ケースデータレポートにして組み合わせることができるデータを受信するいくつかの例を示している。しかしながら、他の事前に生成されたデータ記録及び/又はデータレポートが、患者116とともにシーンに存在する任意のモバイルコンピューティングデバイスによって、及び、病院にいるヘルスケアプロフェッショナルによって使用されるもの等の任意のリモートモバイルコンピューティングデバイスによって受信されてよいことが理解されるべきである。そのような事前に生成されたデータ記録の例として、除細動器/モニタ302Bによって生成されてよい12リードECGレポートが挙げられる。一般に、12リードECGレポートは、患者の身体上に配置されている12のリードからの電気的測定に基づく患者の心臓内の電気伝導のピクチャを提供する。12のリードのうちの6つは、患者の腕及び/又は脚上に配置されるので、「四肢リード」とみなされる。他の6のリードは、胴体(前胸部)上に配置されるので、「前胸部リード」とみなされる。
12リードECGレポートは、患者上の12のリードのそれぞれから収集された電気波形を含んでよい。いくつかの例において、12リードECGレポートは、ユーザに高速かつ簡便な分析を提供するために、波形の1又は複数の解釈も含む。これらの1又は複数の解釈は、異なる波形の中からのパターン認識を伴ってよく、これは、波形の特定の部分が或る形態の心損傷を示唆する異常パターンを有する場合、アラート又はインジケータを生成してよい。いくつかの例において、12リードECGレポートは、上で説明したように、統合ケースデータレポートの一部である。
図19~図21は、救急車1902等の特定のロケーションにおいて使用される医療デバイスとリモートコンピューティングデバイス1914との間での患者データの通信を伴う例示的な医療環境を示している。データ転送は、本明細書においてより詳細に議論されるように、ローカルコンピューティングデバイス1906及びリモートコンピューティングデバイス1914の両方にインストールされたソフトウェアアプリケーションによって容易にされてよい。ソフトウェアアプリケーションのための例示的なユーザインタフェーススクリーンが、図22~図24を参照しながら議論される。
図19は、1又は複数の医療デバイスとローカルコンピューティングデバイス1906との間の患者データの無線ローカルエリアネットワーク(例えば、WIFI)通信、及び、リモートコンピューティングデバイス1914とのデータ通信も伴う1つの例示的な医療環境1900を示している。任意の数のリモートコンピューティングデバイス1914が、ネットワーク1912を介して医療関連データを受信してよい。図示された例において、nのリモートコンピューティングデバイス(1914-1~1914-nとラベル付けされている)が識別され、それぞれリモートデータ収集アプリケーション1916-1~1916-nを有している。患者が位置し得る現場に戻ると、ローカルデータ収集アプリケーション1908を有するローカルコンピューティングデバイス1906は、1又は複数のローカル医療デバイスからデータを収集するために使用される。図示された例において、除細動器/モニタ1904は、患者の生理学的状態をモニタするようにセットアップされている。モニタリングは、12リード測定からECGデータを収集することを含む、様々なタイプのデータの収集を伴うことができる。適切な除細動器/モニタの一例は、ゾールメディカルコーポレーションによって提供されるX Series(登録商標)除細動器/モニタであるが、他の好適な除細動器/モニタデバイスを本開示に従って使用してもよい。
ローカルコンピューティングデバイス1906又はリモートコンピューティングデバイス1914のうちの任意のものは、タブレット、スマートフォン、ウェアラブルデバイス、及び/又は他のモバイルコンピューティングデバイス、及び/又は、本明細書において説明されたアプリケーションを実行するとともに近距離若しくは長距離無線ネットワークを介して他の通信デバイスと無線で通信することができるモバイルデバイスの組み合わせを含むことができる。ローカルコンピューティングデバイス及び/又はリモートコンピューティングデバイス1914は、モバイルコンピューティングデバイス104A~104Cに関して上で説明したものと同じコンポーネントを有してよい。いくつかの例において、ローカルコンピューティングデバイス1906は、救急車1902内で又は患者のいる任意のロケーションで患者を支援する救急隊員又は他の同様の第一対応者によって使用されるタブレット又はスマートフォンを表す。いくつかの例において、リモートコンピューティングデバイス1914は、病院又は診療所等のリモートロケーションで医療プロフェッショナルによって使用される、テーブル、スマートフォン、又はPCを表す。
除細動器/モニタ1904によって収集されたデータは、ローカルユーザ及びリモートユーザの両方に有意義な情報を提供するために、記録又はレポートとしてフォーマット化されてよい。いくつかの例において、除細動器/モニタ1904は、12リード装置から収集された波形及び/又は波形の分析を提供するために、12リードECGレポートを生成する。図示された医療環境1900において、このレポートは、無線通信プロトコルを介してローカル無線ルータ1910に送信される。ローカルデータ収集app1908がインストールされた任意の他のローカルコンピューティングデバイスは、12リードECGレポートを受信するためにルータ1910と無線で通信してもよい。いくつかの例において、12リードECGレポートは、医療データの機密性を確実にするために暗号化され、モバイルコンピューティングデバイス1906においてローカルデータ収集app1908又はスタンドアロン復号ソフトウェアを使用して復号される。12リードECGレポートは、受信されると、ローカルコンピューティングデバイス1906上で閲覧されてよい。いくつかの例において、ローカルデータ収集app1908は、ネットワーク1912を介した1又は複数のリモートコンピューティングデバイス1914への12リードECGレポートの転送も容易にする。例えば、12リードECGレポートは、まず、無線通信プロトコルを介してルータ1910に又はローカルコンピューティングデバイス1906の近傍にある任意の他のルータに送信され、次に、ルータ1910からネットワーク1912を介してリモートコンピューティングデバイス1914に送信されてよい。
いくつかの例において、ルータ1910は、認可されたデバイスのみがルータ1910と接続し、除細動器/モニタ1904によって生成されたデータレポートを受信することができることを確実にするために、パスワード保護される。例えば、ローカルコンピューティングデバイス1906がデータレポートを受信するためにルータ1910と通信するには、まず、ルータ1904との無線接続を確立するように必須のパスワードを提供しなければならない。パスワードは、一度入力されると、ローカルコンピューティングデバイス1906がルータ1910の範囲内にある場合にルータ1910と接続を確立するために再び入力される必要がないように、将来のエンゲージメントのために記憶されてよい。
上での説明は、12リードECGレポートの取得及び送信を主に議論したが、任意の測定された患者パラメータを、除細動器/モニタ1904によって取得し、ローカルコンピューティングデバイス1906に送信することができることが理解されるべきである。さらに、いくつかの例において、任意の他の測定された患者パラメータを、1又は複数のレポート又は記録に編成することができる。他の測定された患者パラメータのいくつかの例としては、レスピレーション/呼吸数、心拍/脈拍数、血液酸素(SpO)飽和度、メトヘモグロビン(SpMET)飽和度、カルボキシヘモグロビン(SpCO)飽和度、呼気終末CO(ETCO)値、吸入中二酸化炭素濃度(FiCO)値、温度、及び観血又は非観血血圧が挙げられる。送信データは、測定されたデータに基づく特定の関連イベントの波形スナップショットを含んでよい。
いくつかの例において、除細動器/モニタ1904によって生成されたデータレポート又は記録は、生成されると、ローカルコンピューティングデバイス1906に自動的に送信される。換言すれば、そのデータを送信する前に、それについて要求が受信されるのを待つことはない。したがって、ローカルデータ収集app1908がインストールされた任意のローカルコンピューティングデバイスは、ユーザに要求される任意のインタラクションを伴わずに、除細動器/モニタ1904によって生成された任意の送信されたデータレポート又は記録を受信する。いくつかの例において、ユーザは、ローカルデータ収集app1908を使用して、データレポート又は記録の受信をオプトアウトしてよい。
いくつかの例において、ネットワーク1912は、ルータ1910及びリモートコンピューティングデバイス1914がそれを通してデータを送信、受信、及び/又は交換することができる1又は複数の通信ネットワークを含むことができる。様々な実装において、ネットワーク1912は、セルラ通信ネットワーク及び/又はコンピュータネットワークを含むことができる。いくつかの例において、ネットワーク1912は、無線ネットワーク及び/又は有線接続を含み、これをサポートする。例えば、これらの例において、ネットワーク1912は、とりわけ、GSM(登録商標)、CMDA、USB、BLUETOOTH(登録商標)、CAN、ZigBee(登録商標)、無線イーサネット、イーサネット(登録商標)、及びTCP/IP等の1又は複数のネットワーキング規格をサポートしてよい。ネットワーク1912は、ローカルエリアネットワーク等のプライベートネットワーク及びインターネット等のパブリックネットワークの両方を含んでよい。いくつかの例において、ネットワーク1912は、1つのエンドポイントから別のエンドポイントへのパケットのルーティングに関与する1又は複数の中間デバイスを含んでよいことに留意すべきである。しかしながら、他の例において、ネットワーク1912は、それぞれ他方と直接ネットワーク接続している2つのみのエンドポイントを伴うことができる。いくつかの例において、ネットワーク1912は、ルータ1910から1又は複数のリモートコンピューティングデバイス1914に転送される医療データ、記録、又はレポートのための中間チェックポイントとして動作してよい1又は複数のサーバデバイスを含む。例えば、特定の患者に関係するECG医療レポートは、セキュアドメインにおいてホストされているサーバによって受信されてよい。サーバは、受信された医療レポートを、患者に関して以前に格納された他のデータを含む所与の患者のためのより大きな医療記録の一部として格納してよい。サーバは、受信されたECG医療レポート又はより大きな医療記録のいずれかを、1又は複数のリモートコンピューティングデバイス1914の任意のものに渡してよい。
いくつかの例において、リモートコンピューティングデバイス1914は、ネットワーク1912を介して医療データ、記録、及び/又はレポートを受信するためにリモートデータ収集app1916を含む。リモートデータ収集app1916は、ローカルデータ収集app1908に関して上で説明したものと同じ機能の多くを含んでよい。例えば、リモートデータ収集app1916は、除細動器/モニタ1904から測定された医療データを、ユーザに要求されるインタラクションを最小限に留めて又はそれ無しにユーザに表示することができるレポート又は記録として受信してよい。いくつかの例において、リモートデータ収集app1916は、新たなデータレポートが受信されたときはいつでも、ユーザにアラート又は通知を提供してよい。アラートは、データレポートの決定された特性に応じて変化してよい。例えば、新たな12リードECGデータレポートが受信されたとき、アラートは、ユーザによる即時の注意を要求する波形のうちの1又は複数において検出されたトラブル発生パターンを示すために、増加した音量又は異なるトーンを有してよい。トラブル発生パターンは、検出された波形を、或る形態の心損傷又は異常を表すことが知られている予め定められた波形と比較する、1又は複数のパターン検出アルゴリズムを使用して検出されてよい。
いくつかの例において、リモートデータ収集app1916は、1又は複数の異なる患者に関する複数のデータレポートの格納を容易にし、ユーザが格納されたデータレポートのうちの任意のものにアクセスすることを可能にする。データレポートのうちの1又は複数は、選択されると、リモートコンピューティングデバイス1914のうちの任意のものに関連付けられているディスプレイ上に示されてよい。例えば、12リードECGデータレポートは、定期的に生成され、作成の時間に基づいてタイムスタンプが付与されてよい。これらのレポートのそれぞれは、リモートデータ収集app1916によって収集され、ユーザが閲覧のために特定の12リードECGデータレポートを選択するためにリスト化されてよい。リスト化は、12リードECGデータレポートのそれぞれに関連付けられているタイムスタンプに基づいてソート又は編成されてよい。
いくつかの例において、除細動器/モニタ1904は、1又は複数の12リードECGレポートを含むケースファイル304B等のケースファイルを生成する。フルケースファイルは、次にローカルデータ収集app1908によって受信されて、最終的にリモートデータ収集app1916に送信されてよい。いくつかの例において、除細動器/モニタ1904によって生成された1又は複数の12リードECGデータレポートは、例えば、図5を参照しながら説明されたような統合データソースエンカウンタ構造体の一部である。
図20は、1又は複数の医療デバイスとローカルコンピューティングデバイス1906との間の患者データのローカルパーソナルエリアネットワーク(例えば、BLUETOOTHネットワーク)通信、及び、リモートコンピューティングデバイス1914とのデータ通信も伴う別の例示的な医療環境2000を示している。ローカルデータ収集アプリケーション1908を有するローカルコンピューティングデバイス1906は、除細動器/モニタ1904等の1又は複数のローカル医療デバイスからデータを収集するために使用される。
医療環境2000は、図19を参照しながら説明された医療環境1900と類似しているが、1つの相違点は、医療データレポートが除細動器/モニタ1904とローカルコンピューティングデバイス1906との間で及びローカルコンピューティングデバイス1906とリモートコンピューティングデバイス1914との間で転送される方法にある。医療環境2000において、除細動器/モニタ1904によって測定/生成された医療データ、レポート、及び/又は記録は、セキュアパーソナルエリアネットワーク接続を介してローカルコンピューティングデバイス1906に転送される。いくつかの例において、除細動器/モニタ1904は、12リード装置から収集された波形及び/又は波形の分析を提供するために、12リードECGレポートを生成する。ローカルデータ収集app1908がインストールされた任意の他のローカルコンピューティングデバイスが、12リードECGレポートを受信するためにパーソナルエリアネットワークを介して無線で通信してもよい。いくつかの例において、除細動器/モニタ1904によって生成されたデータレポート又は記録は、生成されると、ローカルコンピューティングデバイス1906に自動的に送信される。換言すれば、そのデータを送信する前に、それについて要求が受信されるのを待つことはない。いくつかの例において、12リードECGレポートは、医療データの機密性を確実にするために暗号化され、ローカルコンピューティングデバイス1906においてローカルデータ収集app1908又はスタンドアロン復号ソフトウェアを使用して復号される。12リードECGレポートは、受信されると、ローカルコンピューティングデバイス1906上で閲覧されてよい。いくつかの例において、まず、ローカルコンピューティングデバイス1906と除細動器/モニタ1904との間のペアリングプロセスが、パーソナルエリアネットワーク接続を確立するために実行されなければならない。このペアリングプロセスは、除細動器/モニタ1904上でローカルコンピューティングデバイス1906との接続を手動で承諾することを伴ってよい。
いくつかの例において、ローカルデータ収集app1908は、ネットワーク1912を介した1又は複数のリモートコンピューティングデバイス1914への12リードECGレポートの転送も容易にする。このデータ転送は、ローカルコンピューティングデバイス1906とネットワーク1912との間のセルラ通信等の長距離無線通信を使用して発生してよい。
図21は、ネットワーク2102を介した1又は複数の医療デバイスとリモートコンピューティングデバイス1914との間の直接通信を伴う別の例示的な医療環境2100を示している。例示的な医療環境1900及び2000と異なり、医療環境2100は、除細動器/モニタ1904によって測定/生成された医療データ、記録、又はレポートの転送において、除細動器/モニタ1904に対してローカルなコンピューティングデバイスを伴わない。
いくつかの例において、除細動器/モニタ1904は、ネットワーク2102を介してリモートコンピューティングデバイス1914に医療データを転送するために、近距離及び長距離通信のうちの一方又は両方を使用する。例示的な狭域通信は、BLUETOOTH又はWIFIを含み、例示的な長距離技術は、セルラ通信を含む。
いくつかの例において、ネットワーク2102は、ネットワーク1912に関して上で説明したものと同じ特徴を共有する。図示された例において、ネットワーク2102は、少なくとも、第1のサーバ2104及び第2のサーバ2106を含む。いくつかの例において、第1のサーバ2104は、除細動器/モニタ1904から医療データ、記録、及び/又はレポートを受信し、データを収集して編成するための或る種のゲートウェイを提供するように構成されている。いくつかの例において、第1のサーバ2104は、セキュアネットワーク上でホストされる。第1のサーバ2104は、受信された医療データ、記録、及び/又はレポートを第2のサーバ2106に渡してよく、第2のサーバ2106は、受信されたデータ、記録、及び/又はレポートをリモートコンピューティングデバイス1914に広める。いくつかの例において、第1のサーバ2104は、異なる病院ネットワークによって操作される複数の異なる医療デバイスから医療データを受信するように構成されている一元化データサーバであってよく、第2のサーバ2106は、特定の病院ネットワーク上でホストされ、受信された医療データ、記録、及び/又はレポートを特定の病院ネットワークの一部であるリモートコンピューティングデバイス1914に送信するように設計されたサーバであってよい。
いくつかの例において、第1のサーバ2104は、受信された医療データ、記録、及び/又はレポートを、第1のサーバ2104内に格納された電子メール配信リストに送信する。配信リストは、特定の除細動器/モニタ1904に関連付けられているデータを受信することになる特定の電子メールアドレスを追加又は削除するようにアップデート及び修正されてよい。いくつかの例において、配信リスト内の個々の電子メールアドレスは、特定のタイプのデータレポートのみを受信する(12リードECGレポートのみを受信する等)又は特定の時間フレーム中に生成されたデータレポートのみを受信するように構成されてよい。いくつかの例において、異なる配信リストは、1又は複数の関連付けられたアカウントコードを有するように生成されてよい。アカウントコードのそれぞれは、1又は複数の除細動器デバイスに又は特定の病院ネットワークに関係付けられてよい。
上で説明した例示的な医療環境において、12リードECGレポート等の医療レポートは、除細動器/モニタ1904によって生成される。しかしながら、いくつかの例において、医療データは、除細動器/モニタ1904によって収集され、ローカルコンピューティングデバイス1906に転送され、ローカルコンピューティングデバイス1906は、受信されたデータに基づいて医療レポートを生成する。医療レポートは、ローカルデータ収集app1908を使用して生成されてよい。いくつかの他の例において、医療レポートは、医療データを除細動器/モニタ1904から直接又はローカルコンピューティングデバイス1906からのいずれかで受信した後、1又は複数のリモートコンピューティングデバイス1914のうちの任意のものによって生成される。医療レポートは、リモートデータ収集app1916を使用して生成されてよい。
図22は、ローカルデータ収集app1908の一部である例示的なユーザインタフェーススクリーン2200を示している。ユーザインタフェーススクリーン2200は、任意のタイプのディスプレイデバイス上でユーザに提示されてよく、ユーザが例えばタッチインタフェースを介して除細動器/モニタ1904から収集されているデータとインタラクトすることを可能にする。さらに、ユーザインタフェーススクリーン2200は、除細動器/モニタ1904から収集されたECG記録等のデータ記録を閲覧するための例示的なインタフェースを提示する。ユーザインタフェーススクリーン2200上の様々な領域及び/又はグラフィカルオブジェクトの相対的なサイズ及び配置は、特定の図示された例とは異なってよいことが理解されるべきである。いくつかの例において、ユーザインタフェーススクリーン2200は、新たに取得されたデータレポートを即時に提示する目的で専用インタフェースを提供する。データレポートは、受信されるとスクリーン上に現れ、さらに多くのレポートが受信されると、リスト化された順番で現れる。いくつかの例において、受信されたデータレポートのリストは、スクロール、ソート、又はフィルタすることができる。
ユーザインタフェーススクリーン2200は、データをそこから受信している所与の医療デバイスに関する情報を表示する。例えば、領域2202は、除細動器/モニタ1904等の所与の医療デバイスに関する名前、シリアルナンバ、及び/又はユニットIDのような詳細を含んでよい。ユーザインタフェーススクリーン2200は、いくつかの例において、ローカルコンピューティングデバイス1906の近傍にある異なる医療デバイスを切り替えるためにタブを含んでよい。したがって、領域2202は、データが表示されている現在の医療デバイスに関する記述的詳細を含んでよい。いくつかの例において、ステータスインジケータ2204は、領域2202において示されている医療デバイスとの接続の確立が成功しているか否かを示すために提供される。
いくつかの例において、ユーザインタフェーススクリーン2200は、医療デバイスからのさらなるデータについてのいかなるポーリングも停止するために使用されるボタン2206を含む。例えば、所与の医療デバイスとの接続を確立するときのデフォルト設定は、医療デバイスからの新たなデータについて継続的にチェックし、所与の医療デバイスから送信されている任意の新たなデータを受信するようになっている。ボタン2206は、本質的には、ユーザが、所与の医療デバイスから任意のさらなる医療データ、記録、又はレポートを受信することをオプトアウトすることを可能にする。
いくつかの例において、ユーザインタフェーススクリーン2200は、所与の医療デバイスから受信されたデータレポート2208を含む。いくつかの例において、データレポートのリストは、それらが受信されたときからの時系列で提供されてよい。いくつかの例において、データレポートのリストは、レポート内の時間、名前、又はユーザ定義特徴によってソートされてよい。図示された例において見られるように、表示されたデータレポートは、レポートが生成された日付及び時間、レポートを生成した医療デバイスに関連付けられているシリアルナンバ、及び医療デバイスのユニットID等のいくつかの記述的詳細を含んでよい。いくつかの例において、ユーザは、さらに詳細にレポートを閲覧するために、表示されたデータレポート2208をクリック又はタッチしてよい。
いくつかの例において、所与の医療デバイスによって生成されたアーカイブされたデータレポートにアクセスするために、履歴ボタン2210が設けられてよい。アーカイブされたレポートは、患者によって又はデータ収集の所与の期間によって編成されてよい。例えば、12リードECG医療レポートは、それらが収集された日又は週によって編成されてよい。
図23Aは、リモートデータ収集app1916の一部である例示的なユーザインタフェーススクリーン2300を示している。ユーザインタフェーススクリーン2300は、任意のタイプのディスプレイデバイス上でユーザに提示されてよく、ユーザが例えばタッチインタフェースを介して除細動器/モニタ1904から収集されているデータとインタラクトすることを可能にする。さらに、ユーザインタフェーススクリーン2300は、除細動器/モニタ1904から収集された12リードECG記録等のデータ記録を閲覧するための例示的なインタフェースを提示する。ユーザインタフェーススクリーン2300上の様々な領域及び/又はグラフィカルオブジェクトの相対的なサイズ及び配置は、特定の図示された例とは異なってよいことが理解されるべきである。
ユーザインタフェーススクリーン2300は、いくつかの例によれば、所与の医療デバイスから収集された複数の受信されたデータレポートにアクセスするためのコントロール2302A~2302Eを含む。5つの12リードECGデータレポートが示されているが、任意の数のデータレポートをリスト化してスクロールすることができる。本明細書における議論のしやすさのために、データレポートにアクセスするためのコントロール2302A~2302Eのいずれも、より一般的なラベル2302で識別され得る。リスト化されたデータレポートのそれぞれは、レポートが生成された日付及び時間、レポートを生成した医療デバイスに関連付けられているシリアルナンバ、及び医療デバイスのユニットID等のいくつかの記述的詳細を含んでよい。いくつかの例において、コントロール2302は、それらの対応するデータレポートを受信した時系列でリスト化されてよい。いくつかの例において、コントロール2302は、ソートボタン2304をアクティベートすることによって、それらの対応するレポート内の時間、名前、又はユーザ定義特徴によってソート及び/又はフィルタされてよい。いくつかの他の例において、コントロール2302は、それらの対応するレポートを生成した医療デバイスに基づいて、所与の患者又は任意の他のユーザ定義基準に基づいて、ソート及び/又はフィルタされてよい。
いくつかの例において、データレポートは、任意の数の異なる医療デバイスから到来する。したがって、レポートは、これらを生成したデバイスに応じて異なるタイプのデータを含むことができる。例えば、データレポートの一部は、除細動器/モニタ(除細動器/モニタ302B等)からのものであってよく、一部のデータレポートは、人工呼吸器(人工呼吸器302C等)からのものであってよく、一部のデータレポートは、自動化胸骨圧迫器(自動化胸骨圧迫器302A等)からのものであってよい。図23Bは、リモートデータ収集app1916の一部である別の例示的なユーザインタフェーススクリーン2301を示している。ユーザインタフェーススクリーン2301は、同じ患者エンカウンタに関連付けられている異なる医療デバイスから収集されたデータレポートを閲覧するためのコントロール2303A~2303Eを伴う例示的なインタフェースを提示する。異なる医療デバイスから受信されたそのようなデータレポートは、(図23Bに示されているように)別個にリスト化されてよく、又は、(例えば、図3Dにおいて説明したような患者エンカウンタデータソース統合サービス130を使用して)統合データソースエンカウンタ構造体にして組み合わされてよく、統合データソースエンカウンタ構造体のうちの異なるものが、代わりにリスト化される。図示された例において、データレポートは、図3B及び図3Cを参照しながら説明したように、医療デバイス302A~302Dから異なる時点で受信されている。
図24は、リモートデータ収集app1916の一部である別の例示的なユーザインタフェーススクリーン2400を示している。ユーザインタフェーススクリーン2400は、例えば、ユーザインタフェーススクリーン2300から選択された後の、所与のデータレポート2302の例示的なビューを提供する。所与のデータレポート2302の選択により、レポートの詳細をユーザに示すためにビューが変化してよい。ユーザインタフェーススクリーン2400の図示された例において、12リードECGレポートが選択されており、レポートの詳細が示されている。
いくつかの例において、ユーザインタフェーススクリーン2400は、医療レポートに関連付けられている患者に関する様々な詳細を含む患者詳細領域2402を含む。例において見られるように、患者の詳細は、患者の名前、患者ID、年齢、及び性別を含んでよい。患者の心拍数、PR間隔、QRS時間、QT/QTc、及びP-R-T軸等の、医療デバイスから突き止められたさらなる医療詳細も提供されてよい。いくつかの例において、患者詳細領域2402は、患者とともにシーンにいるローカルデータ収集app1908のユーザから等、別のケア提供者から医療レポートに追加されたノートも含む。
いくつかの例において、ユーザインタフェーススクリーン2400は、12リードECG測定の様々なリードからの特定の波形を表示する。例えば、V1~V6、I、II、III、aVR、aVL、及びaVFリードのそれぞれから収集された波形が表示されてよい。データは、図24に示されているようにランドスケープビューで提示されてよい。
いくつかの例において、医療環境1900、2000又は2100のうちの任意のものからのデバイスは、ECG記録又は統合データソースエンカウンタ構造体等の医療データ記録を送信及び受信する様々なプロセスを実行するように構成されている。図25は、例えば、医療デバイス(例えば、図19の除細動器/モニタ1904)、1又は複数のローカルコンピューティングデバイス(例えば、図19のローカルコンピューティングデバイス1906)、及び1又は複数のリモートコンピューティングデバイス(例えば、図19のリモートコンピューティングデバイス1914)によって実行されるデータ記録送信プロセス2500を示している。いくつかの例において、図25における1又は複数のローカルコンピューティングデバイスに帰属する動作は、1又は複数のローカルコンピューティングデバイスによってホストされている1又は複数のローカルデータ収集app(例えば、図19のローカルデータ収集app1908)によって実行される。
データ記録送信プロセス2500は、いくつかの例に従えば、医療デバイスを使用して患者からデータを収集する段階2502で開始する。データは、図1及び図18を参照しながら説明したように、1又は複数の患者インタフェースデバイス(例えば、生理学センサ、ECGセンサ、SpO2センサ、カプノグラフィセンサ、血圧センサ等)を介して収集されてよい。いくつかの例において、患者インタフェースデバイスは、患者の12リードECGを収集するための12リードECGセンサを含む。
患者データを収集した後、医療デバイスは、12リードECGレポート等の1又は複数のデータレポートを生成する(2504)。
12リードECGレポートは、患者上の12のリードのそれぞれから収集された電気波形を含んでよい。いくつかの例において、12リードECGレポートは、ユーザに高速かつ簡便な分析を提供するために、波形の1又は複数の解釈も含む。これらの1又は複数の解釈は、異なる波形の中からのパターン認識を伴ってよく、これは、波形の特定の部分が或る形態の心損傷を示唆する異常パターンを有する場合、アラート又はインジケータを生成してよい。いくつかの例において、1又は複数のデータレポートは、12リードECGデータを含む、ケースファイル304B等の、少なくとも1つのケースファイルを含む。ケースファイルは、統合データソースエンカウンタ構造体の1つのケースファイルであってよい。したがって、データレポートは、複数の医療デバイスから生成されて、図3C及び図3Dを参照しながら概ね議論したように、統合データソースエンカウンタ構造体を生成するように組み合わされてよい。
医療デバイスは、1又は複数のデータレポート(1又は複数のケースファイル又は統合データソースエンカウンタ構造体に含まれてよい)を1又は複数のローカルコンピューティングデバイスに送信する(2506)。いくつかの例において、医療デバイスによって生成されたデータレポート又は記録は、生成されると、1又は複数のローカルコンピューティングデバイスに自動的に送信(プッシュ)される。換言すれば、そのデータを送信する前に、それについて要求(例えば、ポール)が受信されるのを待つことはない。したがって、例えば、ローカルデータ収集appを介してデータを受信するように構成されている任意のローカルコンピューティングデバイスは、ユーザに要求される任意のインタラクションを伴わずに、医療デバイスによって生成された任意の送信されたデータレポート又は記録を自動的に受信する(2508)。いくつかの例において、ユーザは、ローカルデータ収集appを使用してデータレポート又は記録を受信することをオプトアウトしてよい。例えば、ローカルデータ収集appは、所与の医療デバイスからの又は任意の医療デバイスからの任意のさらなるデータレポートを自動的に受信することを停止するユーザからの入力を受信することができる。医療デバイスは、WIFI、BLUETOOTH、又はセルラ等の任意の既知の無線通信インタフェースを使用して1又は複数のデータレポートを送信してよい。いくつかの例において、受信された1又は複数のデータレポートは、ローカルコンピューティングデバイスによって復号される。
1又は複数のローカルコンピューティングデバイスのうちの任意のものは、1又は複数の受信されたデータレポートへのアクセスを提供する(2510)ことができる。いくつかの例において、1又は複数の受信されたデータレポートへのアクセスは、1又は複数の統合データソースエンカウンタ構造体のコンテンツの閲覧を含む。このアクセスは、受信されたレポートのリストを、それらがそこから受信された医療デバイスとともに表示することを含んでよい。表示されたリストは、任意の受信されたデータレポートを用いて、それらが受信されときに、自動的にアップデートされてよい。レポートのリストは、受信された時間、レポートが生成された時間、レポートを送信した医療デバイス、又は医療レポートに存在する特定のパラメータによって等、様々な基準を使用してソートされてよい。いくつかの例によれば、データレポートのうちの少なくとも1つは、12リードECGレポートである。ローカルコンピューティングデバイスを介して1又は複数の受信されたデータレポートを提供するためのユーザインタフェーススクリーンの一例が、図22に示されている。
また、ローカルコンピューティングデバイスは、1又は複数の受信されたデータレポートのうちの任意のものを1又は複数のリモートコンピューティングデバイスに送信する(2512)ようにも構成されている。このデータ送信は、医療環境1900又は2000に概ね示されているように任意の数の無線経路を介して発生してよい。いくつかの例において、1又は複数の受信されたデータレポートは、図19からのネットワーク1912等のネットワークを介したセルラ通信を介して、ローカルコンピューティングデバイスによって直接送信される。いくつかの例において、1又は複数の受信されたデータレポートは、ローカルコンピューティングデバイスの範囲内にあるルータを介してネットワークを横断して送信される。使用される送信技術にかかわらず、1又は複数のリモートコンピューティングデバイスは、少なくとも1つの12リードECGレポートを含んでよい1又は複数のデータレポートを受信する(2514)。
1又は複数のリモートコンピューティングデバイスは、1又は複数のデータレポートへのアクセスを提供する(2516)ように構成されている。いくつかの例において、1又は複数の受信されたデータレポートへのアクセスは、1又は複数の統合データソースエンカウンタ構造体のコンテンツを閲覧することを含む。1又は複数のリモートコンピューティングデバイスは、受信されたレポートのリストを、それらがそこから受信された医療デバイス又はローカルコンピューティングデバイスとともに表示してよい。レポートのリストは、受信された時間、レポートが生成された時間、レポートを送信した医療デバイス、又は医療レポートに存在する特定のパラメータによって等、様々な基準を使用してソートされてよい。いくつかの例によって、データレポートのうちの少なくとも1つは、12リードECGレポートである。リモートコンピューティングデバイスを介して1又は複数の受信されたデータレポートを提供するための例示的なユーザインタフェーススクリーンが、図23及び図24に示されている。
図1に戻ると、いくつかの例において、ヘルスケア提供者118A及び118Bは、例えば、モバイルコンピューティングデバイス104上で実行されているオペレーティングシステム及び/又は患者エンカウンタデバイス関連付けアプリケーション150に対して認証されていることによって、モバイルコンピューティングデバイス104にそれぞれ関連付けることができる。図1に示されているように、いくつかの例において、モバイルコンピューティングデバイス104は、医療デバイス102に通信可能に結合されるように構成されてよいが、本開示のいくつかの例において、モバイルコンピューティングデバイス104は、必ずしも医療デバイス102と直接通信する必要はなく、むしろ、モバイルコンピューティングデバイス104及び医療デバイス102は、ネットワーク112を通して別個にサーバ108と通信する。
いくつかの例において、モバイルコンピューティングデバイス104Aは、ePCR及び/又は他の記録及び/又は患者116の状態及び/又は患者116に適用された処置についてのノートを生成するためにヘルスケア提供者118Aによって使用されるデバイスとしてよい。同様に、いくつかの例において、モバイルコンピューティングデバイス104Bは、容易で直感的な方式でコードの重要な情報のドキュメント化を可能にする、ゾールメディカルコーポレーションによって提供されるRescueNet(登録商標)CodeWriterドキュメント化モバイルアプリケーション等の、患者116に適用された特定の処置手順(例えば、心停止コードの実行)をドキュメント化するイベントログを生成するためにヘルスケア提供者118Aによって使用されるデバイスであってよい。図1において、ePCRアプリケーション122及びイベントログアプリケーション140は、別個のモバイルコンピューティングデバイス104によってホストされているが、本明細書に開示されている例は、この構成に限定されない。例えば、いくつかの例において、単一のモバイルコンピューティングデバイス104は、ePCRアプリケーション122及びイベントログアプリケーション140の両方をホストする。
いくつかの例において、イベントログアプリケーション140は、イベントを容易、迅速、簡便、かつ正確に記録し、場合によっては緊急医療処置中に遭遇されたさらなるイベント詳細を特定するように調整されたユーザインタフェーススクリーンのセットを提供するように構成されている。これらのインタフェーススクリーンは、例えば、イベントログアプリケーション140を実行しているモバイルコンピューティングデバイス104のタッチスクリーンを介して提供することができる。
より具体的には、いくつかの例において、イベントログアプリケーション140は、一般に緊急医療処置中に遭遇されるイベントでラベル付けされ且つそれに関連付けられているコントロールを含むスクリーンを提供するように構成されている。例えば、CPR、エピネフリン(EPI)、及び/又は電気治療ショックの実施等のイベントが、コードブルーの実行中に一般に遭遇され、コードブルーのドキュメント化に向けた例は、これらのイベントの記録に専用のコントロールを有する。これらのプロセスの多くは、特定のイベントの発生をドキュメント化する日付/タイムスタンプが付与されたエントリをイベントログ内に格納することで完結する。イベントログは、患者エンカウンタの過程中に患者に与えられた処置及び/又は発生したイベントをさらにドキュメント化する。
いくつかの例において、イベントログアプリケーション140は、コントロールに関連付けられているプロセスを実行することによってコントロールを選択する入力に応答するようにさらに構成されている。例えば、いくつかの例において、CPR、EPI、及びショックの実施に関連付けられているコントロールは、コントロールに関連付けられているプロセスの実行を介してリセット及び/又は増加されるタイマ及び/又はカウンタを含む。さらに、これらのプロセスは、そのコントロールが最後に選択されてから閾値量の時間が経過した後で通知を提供することができる。例えば、イベントログアプリケーション140は、CPR胸骨圧迫が開始してから2分が経過した後又はCPRがポーズしてから10秒が経過した後に、CPRコントロールを介して、通知(例えば、アイコンの点滅、色変化、テキストによる促し)を提供することができる。胸骨圧迫の、予め定められた期間後、通常は2分後のこの通知は、CPRの間隔が過ぎていること、及び、患者に電気治療(例えば、除細動ショック)又は1又は複数の陽圧換気呼吸を加えるための短いポーズが必要か否かを決定するために、ECG分析の期間等の患者の処置における別のフェーズが要求され得ることをユーザにリマインドする。(例えば、ECG分析及び/又は換気のための)このポーズを過ぎたら、次に、胸骨圧迫を即時再開すべきである。したがって、胸骨圧迫における10秒のポーズ後の通知は、胸骨圧迫を再開すべきであることをユーザにリマインドするために適切なものであり得る。同様に、いくつかの例において、イベントログアプリケーション140は、EPIコントロールを介して、EPIが最後に実施されてから3分経過した後に通知を提供することができる。そのような通知は、EPIの後続の投与が実施されるべきであることをユーザにリマインドするために適切なものであり得る。これらの通知は、コントロールを点滅させること、強調させること、色変化させること、テキストによる促し、及び/又は別の視覚的インジケーションを提供することを含むことができる。又は、いくつかの場合において、可聴及び/又はハプティック通知が、モバイルコンピューティングデバイスによって提供されてよい。
いくつかの例において、特定の状況における処置ドキュメント化をさらに容易にするために、イベントログアプリケーション140は、ヘルスケア提供者がイベントログアプリケーション140のドキュメント化モードを成人モード又は小児モードのいずれかに変更することを可能にするコントロールを提供するように構成されている。成人モードで動作している間、イベントログアプリケーション140は、成人を処置しているときに遭遇するイベントに関するイベントをマークするログエントリを容易にするために、特定のスクリーン及びコントロールの特徴を変える。例えば、成人に対してのみ利用可能なCPRへのアプローチに関連付けられラベル付けされたコントロールは、イベントログアプリケーション140が成人モードで動作している間にのみ可視である。反対に、小児モードで動作している間、イベントログアプリケーション140は、小児を処置しているときに遭遇するイベントに関するイベントをマークするログエントリを容易にするために、特定のスクリーン及びコントロールの特徴を変える。例えば、小児に対してのみ利用可能なCPRへのアプローチに関連付けられているコントロールは、イベントログアプリケーション140が小児モードで動作している間にのみ可視である。
特定の例において、イベントログアプリケーション140は、患者の緊急処置の前、中、及び後に、様々な情報を表示するためのコントロールを伴って構成されている。例えば、いくつかの例において、関係する情報を取得するために適切な接続が形成されると、イベントログアプリケーション140は、患者情報スクリーンを介してヘルスケア提供者に患者識別情報を表示するように構成されている。さらに、少なくとも1つの例において、イベントログアプリケーション140は、CPRクオリティメトリック(例えば、ターゲット深さ内に入る胸骨圧迫のパーセンテージ、ターゲット回数内に入る圧迫のパーセンテージ、圧迫の平均深さ、圧迫の平均回数等の胸骨圧迫メトリック等)を、ユーザインタフェースのスクリーンを介してヘルスケア提供者に表示するように構成されている。さらに、いくつかの例において、イベントログアプリケーション140は、MEWSファクタを受信し、MEWSファクタに基づいて計算されたMEWSスコアを表示するためのコントロールを伴うスクリーンを提供するように構成されている。さらに、これらのスクリーンは、例えば、迅速な応答又はコードチームをモバイルコンピューティングデバイスのロケーションに呼び出すことによって、コントロールを選択する入力に応答するコントロールを含んでよい。
ePCRアプリケーション122は、ePCR生成に関するコンテンツを含む、視覚的コンテンツ、音声コンテンツ、ハプティックコンテンツ、及び/又はタクタイルコンテンツをレンダリングすることができる。こうして、ePCRアプリケーション122は、入力を受信する又は出力を提供することができ、それにより、ユーザがモバイルコンピューティングデバイス104とインタラクトすることを可能にする。ePCRアプリケーション122は、タッチスクリーン、音声認識、及びスキャナを含むがこれらに限定されない様々なメカニズムを介して、チャート化データを受信するように構成することができる。例えば、患者は、彼/彼女の名前を言うことがあり、ePCRアプリケーション122は、患者名を捕捉して、それをチャート化データの一部として格納することができる。ePCRアプリケーション122は、カメラ/スキャナを含むことができ、これを通して、患者の運転免許が取得/スキャンされてよく、名前、住所、年齢等の患者についての関係する情報をチャート化データとして格納することができる。ヘルスケア提供者118Aは、ePCRアプリケーション122を介して患者116を検査したときのデータ又は所見をディクテートしてよい。そのようなディクテーションは、いくつかの例によれば、チャート化データとして捕捉し保存することができる。特定の例において、ePCRアプリケーション122は、図18の入力デバイス444及び/又は出力デバイス430を利用する。
いくつかの例において、モバイルコンピューティングデバイス104によって実施されるePCRアプリケーション122は、タッチスクリーン及び/又はフラットパネルPC又はいくつかの他のユーザインタフェースハードウェア並びにハードウェアを駆動するように構成されているソフトウェアスタックと相互運用することができる。ePCRアプリケーション122の一部は、Android(登録商標)アプリケーション、Apple(登録商標)アプリケーション、又は他のネイティブアプリケーションとしてモバイルコンピューティングデバイス104のメモリに格納し、ヘルスケア提供者118とインタラクトするようにプロセッサによって実行することができる。代替的に又は加えて、モバイルコンピューティングデバイス104のメモリは、1又は複数のウェブサーバから、ePCRアプリケーション122の一部を受信してレンダリングするように構成されているブラウザ又はいくつかの他の実行環境を格納してよい。
いくつかの例において、ePCRアプリケーション122は、チャート化データストア134に格納されることになるチャート化データを生成することができる。例えば、ePCRアプリケーション122は、本開示の例によれば、他のデバイスから収集された及び/又はそこに送信された情報の異なるサブセット及び/又は表示モードをユーザが選択することを可能にする、グラフィカルユーザインタフェースを含むことができる。1つの例において、ePCRアプリケーション122は、特定の時間において患者に与えられた薬剤の投与量、CPR圧迫深さ、又は他の処置パラメータをノートするために使用することができる。ePCRアプリケーション122は、本開示の例によれば、患者についての経歴情報及び/又は人口統計学情報及び/又は履歴情報、例えば、患者の名前、識別番号、身長、体重、及び/又は病歴を記録するために使用することもできる。ePCRアプリケーション122を介して受信されたチャート化データのタイプは、患者生理学パラメータ、ドキュメント化されたイベント等も含むことができる。チャート化データは、患者情報(例えば、名前、年齢、性別、体重、及び/又は他の識別情報及び/又は人口統計学情報)、医療イベント固有情報(例えば、要求されるサービスのタイプ、性質)、及び/又は臨床情報(例えば、患者評価、患者血圧)を含むことができるが、これらに限定されない。チャート化データは、ePCRからのデータに加えて、患者ケア記録からの任意のデータ、内科医のチャートからのデータ、電子健康記録からのデータ、1又は複数の健康情報交換からのデータ、病院チャートからのデータをさらに含むことができる。
いくつかの例において、関連付け生成器142A及び142Bのそれぞれは、医療デバイス120のうちの1又は複数を特定の患者エンカウンタに関連付ける情報を生成する要求を処理するように構成されている。いくつかの例において、各関連付け生成器142A及び142Bは、関連付け情報を生成する要求を受信するように構成されているソフトウェアインタフェース(例えば、API)を露呈し実装する。これらの例において、ePCRアプリケーション122及びイベントログアプリケーション140は、関連付けを生成する要求を生成し、ローカルにホストされている関連付け生成器142A又は142Bに要求を通信するようにそれぞれ構成されている。ePCRアプリケーション122及びイベントログアプリケーション140は、例えば、ヘルスケア提供者118Aからの入力の受信に応答して、要求を生成するように構成されてよい。この入力は、患者エンカウンタの開始、患者エンカウンタの終了、又は単純に患者エンカウンタが進行中であることを示してよい。代替的に又は加えて、いくつかの例において、各関連付け生成器142A及び142Bは、関連付け情報を生成する要求を受信するように構成されているユーザインタフェースを実装する。このユーザインタフェースは、患者エンカウンタの開始、患者エンカウンタが進行中であること及び/又は患者エンカウンタが完了したことを指定する入力を受信するように構成されているコントロールを含むことができる。さらに、ユーザインタフェースは、本明細書において議論されているように、医療デバイスの識別子の表現の取得を開始する及び/又は関連付け情報の他の要素を受信する入力を受信するように構成されているコントロールを含むことができる。さらに、ユーザインタフェースは、関連付け情報の格納及びサーバ108への送信を開始する入力を受信するように構成されているコントロールを含むことができる。
図1を続けて参照すると、モバイルコンピューティングデバイス104は、いくつかの例によれば、デバイスの組み合わせを含むことができる。例えば、モバイルコンピューティングデバイス104は、プロセッサによって操作されたデータを格納するように構成されているメモリと結合されたプロセッサをそれぞれ含むことができる。モバイルコンピューティングデバイス104のそれぞれは、本開示の例によれば、クロックを有してよく、これは、ヘルスケア提供者118Aが処置又は観察の時刻を手動で入力する必要(又は、処置が実施された長時間後に、チャート化の目的で処置の時刻の推測を試みる必要)を防止するために、ネットワークリソース又は人工衛星等の外部時刻ソースと同期することができる。モバイルコンピューティングデバイス104のそれぞれは、1又は複数のシステム、医療デバイス、及び/又は、医療デバイス102のような他のデバイスから及び/又はそれらにデータを受信及び/又は送信するように構成されているネットワークインタフェースを含むことができる。いくつかの例において、モバイルコンピューティングデバイス104のそれぞれは、医療デバイス102等の他のデバイスからデータを集約する又は別様に受信する別のデバイス又はシステム(例えば、リモートコンピューティングデバイス106、別のモバイルコンピューティングデバイス104、及び/又はサーバ108)と通信するために、これらのシステム、医療デバイス、及び/又はネットワークインタフェースを利用することができる。代替的に又は加えて、モバイルコンピューティングデバイス104のそれぞれは、データ入力デバイス並びに診断及び/又は治療医療デバイスを含むローカルネットワークを確立すること又は以前に確立されたローカルネットワークに参加することによって、医療デバイス102等のデバイスと通信することができる。このローカルネットワークは、1人又は複数人の患者の処置時にその現場においてアドホックな方式で確立することができ、2又は2よりも多い近傍に位置するデバイスを含むことができる。
様々な実装において、モバイルコンピューティングデバイス104のそれぞれは、本開示の例によれば、デバイスの有用性をさらに向上するために、また、視覚的及び用手的注意を他のデバイスに別個に移すことをヘルスケア提供者118Aに通常要求する特定のタスクを実行することをヘルスケア提供者118Aにとってより容易にするために、他のデバイス(例えば、医療デバイス102及び他のモバイルコンピューティングデバイス104)からデータを受信、編成、格納、共有、配信、及び表示することができる。換言すれば、モバイルコンピューティングデバイス104のそれぞれは、本開示の例によれば、さもなければ分散され編成されない場合がある情報を一元化、編成、及び共有することができる。しかしながら、ロバストな双方向の完全に認証されたネットワーク接続は、確立及び維持にかなりのコンピューティングリソース及び時間を要求する可能性があることに留意すべきである。結果として、少なくともいくつかの例は、これらの種類のネットワーク接続を回避する。
特定の例において、モバイルコンピューティングデバイス104のそれぞれは、サーバ108から受信された情報を他のデバイスと共有することができる。例えば、1つの例において、モバイルコンピューティングデバイス104Aは、サーバ108から情報を受信することができ、そのような情報を医療デバイス102Aと共有(例えば、ローカルネットワークを介して送信)することができる。代替的に又は加えて、医療デバイス102Nが患者116のECG読み取り値を取得する場合、又は、医療デバイス102Nが、(投薬、胸骨圧迫、換気、除細動ショック等のような)処置を実施する場合、ECG及び/又は処置を記述する情報は、モバイルコンピューティングデバイス104Bを介して又は直接、他のデバイス(例えば、リモートコンピューティングデバイス106、モバイルコンピューティングデバイス104A、及び/又はサーバ108)と、その中に維持されている患者記録内に格納するために共有されてよい。別の例において、モバイルコンピューティングデバイス104のそれぞれは、健康記録データストア110から、医療記録、既知の医療状態、及び経歴情報等の患者情報を受信し、この情報を医療デバイス102のうちの1又は複数と共有するように構成することができる。この経歴情報は、モバイルコンピューティングデバイス104において維持されている及び/又は生成された患者記録(例えば、ePCR)に挿入することができる。
モバイルコンピューティングデバイス104が、それが通信可能に結合されている他のデバイスから及び/又は入力を介してヘルスケア提供者(例えば、ヘルスケア提供者118A又は118Bのいずれか)から更新された情報を受信したとき、モバイルコンピューティングデバイス104は、その更新された情報をサーバ108に送信することができる。したがって、1又は複数のデバイス(例えば医療デバイス102)からの情報は、モバイルコンピューティングデバイス104においてローカルに(例えば、メモリ421に)及び/又はサーバ108において(例えば、メモリ521、イベントログデータストア146に、及び/又はチャート化データストア134に)格納されてよい。モバイルコンピューティングデバイス104からのデータ(及び、存在する場合、モバイルコンピューティングデバイス104と通信可能に結合されてよい他のデバイスからのデータ)を、サーバ108によって受信して、以下でさらに説明されるように、イベントログAPI144、ePCR API128、及び/又はケースAPI126を介して、イベントログデータストア146、チャート化データストア134、及び/又はケースデータストア132に格納することができる。また、リモートコンピューティングデバイス106は、これらのインタフェースを介して、格納された情報にアクセスして、格納された情報を健康記録データストア110に追加することもできる。
本開示のいくつかの例によれば、モバイルコンピューティングデバイス104のそれぞれは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、及び/又はウェアラブル除細動器を含む1又は複数の医療デバイス102に(例えば、自動的に又は手動で又は選択的に)通信可能に結合することができる。これらの例において、そのように結合された任意のモバイルコンピューティングデバイス104は、1又は複数の医療デバイスによって生成された患者モニタリング情報を受信して表示することができる。そのようなモバイルコンピューティングデバイス104は、モバイルコンピューティングデバイス104が、患者116についての追加情報を索出するために、(例えば、ネットワーク112を横断して)外部データベース(例えば、健康記録データストア110)に対してクエリすることを可能にするように、1又は複数の医療デバイスから患者を識別する保護された健康情報を受信するように構成することもできる。このモバイルコンピューティングデバイス104は、本開示の例によれば、同様の方式で植え込み型除細動器(「ICD」)と接続するように構成することもできる。
特定の例において、モバイルコンピューティングデバイス104のそれぞれは、タブレット、スマートフォン、ウェアラブルデバイス、及び/又は他のモバイルコンピューティングデバイス、及び/又は、サーバ若しくはクラウドインタフェース、例えば、サーバ108とのインタフェースを介して、本明細書において説明されているイベントログ及び患者チャート化システム機能にアクセスすることができるモバイルデバイスの組み合わせとすることができる。本開示のいくつかの例によれば、モバイルコンピューティングデバイス104は、タブレットに通信可能に結合されて、患者116に何が行われたのか及びそれが行われたときを示すためにタップされることができるタッチスクリーン又は音声認識データ入力インタフェーススクリーン等のインタラクティブデータ入力インタフェースを伴うApple(登録商標)iPhone(登録商標)又はiPad(登録商標)等のリストバンド及び/又はスマートフォンを含むことができる。さらに、本開示のいくつかの例によれば、モバイルコンピューティングデバイス104は、患者をモニタし、患者を処置し、かつ患者の状態及び/又は患者116に適用された処置についての記録及び/又はノートを生成するように単一のデバイスを構成することができるように、医療デバイス102と統合することができる。これらの例において、ePCRアプリケーション122は、組み合わせ医療/コンピューティングデバイス内に埋め込むことができる。モバイルコンピューティングデバイス104のいくつかのコンポーネントのさらなる説明は、以下で図18を参照しながらさらに詳細に提供される。
様々な実装において、医療デバイス102は、本開示の例によれば、患者処置デバイス、又は患者モニタリング及び/又は患者処置能力を有する他の種類のデバイスを含むことができる。例えば、医療デバイス102は、除細動器を含むことができ、患者に治療的電気ショックを送達するように構成することができる。いくつかの例において、医療デバイス102は、換気、レスピレータの操作、CPRの実行、及び/又は薬剤又は他の薬物の投与等の他のタイプの処置を送達することができる。
より具体的には、医療デバイス102のうちの1又は複数は、本開示の例によれば、例えば、心拍数をモニタするために及び/又は心電図(ECG)を生成するために患者116に取り付けられるように構成された電極及び/又はセンサ等の患者インタフェースデバイス190を有する除細動器であることができる。医療デバイス102のそれぞれは、本開示の例によれば、クロックを有することができ、これは、ヘルスケア提供者118Aが処置又は観察の時刻を手動で入力する必要(又は、処置の時刻の推測を試みる必要)を防止するために、ネットワークリソース又は人工衛星等の外部時刻ソースと同期することができる。医療デバイス102とモバイルコンピューティングデバイス104との間の精密クロック同期は、以下でさらに説明されるように、特にタイムスタンプが少なくとも1つの検索基準において使用される場合に、医療デバイスケースファイルを特定の患者エンカウンタに関連付ける際に特に役立つことができる。したがって、少なくともいくつかの例において、各医療デバイス102及びモバイルコンピューティングデバイス104は、ローカルクロックを伴うタイミング回路を含む。タイミング回路は、ローカルクロックをそれぞれ含むことができ、タイミング回路は、タイミング回路のローカルクロック間のばらつきを特定して修正するように互いに通信することができる。いくつかの例において、タイミング回路のうちの1つは、「マスタ」タイミング回路として動作することができ、他のタイミング回路のそれぞれは、マスタタイミング回路におけるローカルクロックと同期する「スレーブ」タイミング回路として動作することができる。いくつかの場合において、これらのタイミング回路は、医療デバイス102及びモバイルコンピューティングデバイス104がサブマイクロ秒レベルの同期を実現することを可能にすることができる。他の場合において、これらのタイミング回路は、処理回路が1~100マイクロ秒の範囲(例えば、1~10マイクロ秒)又はそれ未満内の同期を実現することを可能にすることができる。少なくとも1つの例において、医療デバイス120及びモバイルコンピューティングデバイス104は、マスタタイミング回路とスレーブタイミング回路との間のタイミングを調整するためにタイミングプロトコルを利用する。そのようなタイミングプロトコルの例として、IEEE1588又は精密時間プロトコル(PTP)、ネットワークタイムプロトコル(NTP)、クロックサンプリング相互ネットワーク同期(CS-MNS)アルゴリズム、基準ブロードキャスト同期(RBS)アルゴリズム、基準ブロードキャストインフラストラクチャ同期(RBIS)アルゴリズム、及び全地球測位システム(GPS)を挙げることができる。ネットワーク化計測及び制御システムの精密クロック同期プロトコルのためのIEEE1588-2008規格は、参照によってその全体が本明細書に組み込まれる。IEEE1588プロトコルは、Jones,Mike、「Get in Sync!:IEEE 1588v2 Transparent Clock Benefits for Industrial Control Distributed Networks」、Micrel,Inc.(2012年3月22日)において、及びWu,Jiang及びPeloquin,Robert、「Synchronizing Device Clocks Using IEEE 1588 and Blackfin Embedded Processors」、Analog Dialogue 43-11(2009年11月)からもさらに詳細に説明され、それらの両方は、参照によってその全体が本明細書に組み込まれる。
また、医療デバイス102のそれぞれは、他の患者パラメータを検出するセンサ及び/又は導出若しくは計算するプロセッサ等の患者インタフェースデバイス190を含む及び/又はそれに結合することもできる。いくつかの例において、医療デバイス102のうちの1又は複数は、本開示の例によれば、血圧、温度、呼吸数、血中酸素レベル、呼気終末二酸化炭素レベル、肺機能、血糖値及び/又は体重をモニタ、検出、処置、及び/又は導出若しくは計算するように患者インタフェースデバイス190と相互運用するように構成されている。医療デバイス102及び患者インタフェースデバイス190のさらなる例は、図18を参照しながら以下でさらに説明される。
いくつかの例において、関連付け情報の生成を通して医療デバイス102によって生成された医療デバイスケースファイルへの容易なアクセスを開始するために、ヘルスケア提供者118Aは、医療デバイスの識別子の表現を取得するためにモバイルコンピューティングデバイス104内に存在する医療デバイスインタフェースを使用することができる。この医療デバイスインタフェースは、例えば、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、無線ネットワークコネクタ、又は関係する識別情報を収集するのに適切な別のセンサを含むことができる。特に、特定の例において、これらの医療デバイスインタフェースは、医療デバイスとの時間のかかる通信又は認証セッションを確立することなく表現を取得する。例えば、いくつかの例において、医療デバイスインタフェースは、カメラを含み、QRコード、バーコード、又は医療デバイス上で視認可能なデバイス識別子を単純にスキャンする。加えて又は代替的に、いくつかの例において、医療デバイスインタフェースは、医療デバイスに付けられているNFCタグ又は無線周波数識別(RFID)タグを読み取る。使用される具体的な技術にかかわらず、識別子の表現を取得することへのこの軽量アプローチは、関連付け情報を生成し、最終的には、容易かつ直感的な方式で患者エンカウンタの統合データソースエンカウンタ構造体にアクセスすることが可能であるために要求されるヘルスケア提供者118Aの時間を最小限に抑える。少なくともいくつかの例において、医療デバイスの識別子は、各医療デバイスを一意に識別することに留意すべきである。
図1を続けて参照すると、(例えば、患者処置の終結及び/又は病院の緊急救命室(ER)等のヘルスケア施設への患者116の移送を介した)患者エンカウンタの完了時及び/又は患者エンカウンタ中、ヘルスケア提供者118Aは、緊急対応センタ内のERアテンド又は他のヘルスケア提供者118Bに患者エンカウンタの統合データソースエンカウンタ構造体を提供することを望む場合がある、及び/又は、医療緊急事態中に統合データソースエンカウンタ構造体への即時アクセスを得ることを望む場合がある。いくつかの状況において、統合データソースエンカウンタ構造体は、(例えば、患者の状態が危機的である場合及び/又はイベント中に)迅速に提供されなければならない。そのため、いくつかの例において、モバイルコンピューティングデバイス104Bは、例えば、モバイルコンピューティングデバイス104の医療デバイスインタフェースを使用して、迅速な軽量通信技術を介して、(例えば、イベントログアプリケーション140の実行を介して)関連付け情報をモバイルコンピューティングデバイス104Cに送信するように構成されている。例えば、1つの例において、イベントログアプリケーションは、モバイルコンピューティングデバイス104Bのユーザインタフェースを介して、トークンの視覚表現をレンダリングするように構成されている。この例において、モバイルコンピューティングデバイス104Cは、(例えば、エンカウンタレビューアプリケーション148の実行を介して)トークンの表現を取得し、インタフェース126及び128のうちの1又は複数を介して患者エンカウンタの統合データソースエンカウンタ構造体の要求を送信するように構成されている。エンカウンタレビューアプリケーション148は、それについて統合データソースエンカウンタ構造体が検索される患者エンカウンタを一意に識別するために、要求内にトークンを含むことができる。この例の説明が完了するが、エンカウンタレビューアプリケーション148は、応答を受信し、ユーザインタフェースを介して、ヘルスケア提供者118Bに統合データソースエンカウンタ構造体を提供するように構成されている。又は、本明細書においてさらに議論されるように、サーバ108は、イベント中におけるヘルスケア提供者の利益のために、統合データソースエンカウンタ構造体をそのシーンに位置するモバイルコンピューティングデバイス104のうちの1又は複数に戻すように送信する場合がある。
本開示の例によれば、サーバ108は、モバイルコンピューティングデバイス104からイベントログデータ及び/又は患者チャート化データを受信し、そのデータを(例えば、イベントログAPI144及び/又はePCR API128の操作を介して)認証されたタイムスタンプ及びその情報を特定のモバイルコンピューティングデバイス104と関連付ける識別子とともに、イベントログデータストア146及び/又はチャート化データストア134に格納することができる。このようにして、複数のデバイスからのデータは、様々なユーザによってアクセスすることができる。
いくつかの例において、ネットワーク112は、医療デバイス102、モバイルコンピューティングデバイス104、リモートコンピューティングデバイス106、及びサーバ108がそれを通してデータを送信、受信、及び/又は交換することができる1又は複数の通信ネットワークを含むことができる。様々な実装において、ネットワーク112は、セルラ通信ネットワーク及び/又はコンピュータネットワークを含むことができる。いくつかの例において、ネットワーク112は、無線ネットワーク及び/又は有線接続を含み、これをサポートする。例えば、これらの例において、ネットワーク112は、とりわけ、GSM、CMDA、USB、BLUETOOTH、CAN、ZigBee(登録商標)、無線イーサネット、イーサネット、及びTCP/IP等の1又は複数のネットワーキング規格をサポートしてよい。ネットワーク112は、ローカルエリアネットワーク等のプライベートネットワーク及びインターネット等のパブリックネットワークの両方を含んでよい。いくつかの例において、ネットワーク112は、1つのエンドポイントから別のエンドポイントへのパケットのルーティングに関与する1又は複数の中間デバイスを含んでよいことに留意すべきである。しかしながら、他の例において、ネットワーク112は、それぞれ他方と直接ネットワーク接続している2つのみのエンドポイントを伴うことができる。
サーバ108は、ケースAPI126、ePCR API128、イベントログAPI144、患者エンカウンタデータソース統合サービス130、ケースデータストア132、イベントログデータストア146、基準データストア136、及びチャート化データストア134を実施するように構成されている1又は複数の物理的及び/又は仮想サーバコンピュータを含むことができる。したがって、サーバ108は、1又は複数のアプリケーションサーバ、ウェブサーバ、及び/又はデータベースサーバを含むことができる。サーバ108は、ネットワーク112を介して、リモートコンピューティングデバイス106、医療デバイス102、及びモバイルコンピューティングデバイス104と通信することができる。サーバ108は、唯一のテナントとして編成をサポートするように構成されている企業サーバ及び/又は複数のテナントとして複数の編成をサポートするように構成されているクラウドサーバを含むことができる。
サーバ108は、互いに通信可能に結合されてよい1又は複数のクラウドにおいて実装されてよい。例えば、1又は複数のサーバを含む単一のクラウドは、図1の要素126、128、130、132、134、136、144及び146を含んでよい。代替的には、要素126及び132は、第1のクラウドにおいて実装されてよく、要素130及び136は、第2のクラウドにおいて実装されてよく、要素128及び134は、第3のクラウドにおいて実装されてよく、要素144及び146は、第4のクラウドにおいて実装されてよい。さらなる代替例として、要素130及び136は、同じクラウドにおいて要素126及び132として実装されてよく、又は、同じクラウドにおいて要素144及び146として実装されてよく、又は、同じクラウドにおいて要素128及び134として実施されてよい。さらに別の代替例として、要素126、128、132、134、144及び146は、第1のクラウドにおいて実装されてよく、要素130及び136は、第2のクラウドにおいて実装されてよい。
患者エンカウンタデータソース統合サービス130と医療デバイスケースデータストア132との間の、図1に示されている通信リンク188aは、任意選択のリンクである。同様に、患者エンカウンタデータソース統合サービス130とイベントログデータストア146との間の、図1に示されている通信リンク188bもまた、任意選択のリンクである。同様に、患者エンカウンタデータソース統合サービス130とチャート化データストア134との間の、図1に示されている通信リンク188cもまた、任意選択のリンクである。一実装において、患者エンカウンタデータソース統合サービス130は、セキュリティの目的で、これらのデータストアと直接通信しなくてもよい。特定の実装において、患者エンカウンタデータソース統合サービス130は、複数のデータフォーマットに精通(conversant)しており、このようなデバイスによって提供されるリソースに対するゲートキーパとしての役割を果たすことができるパブリックAPIを介して、医療デバイス102及びモバイルコンピューティングデバイス104のコンポーネントとインタラクト可能である。例えば、医療デバイスケースデータストア132、チャート化データストア134、及びイベントログデータストア146は、第1のエンティティによって所有されるか又は第1のエンティティ、第2のエンティティ、及び第3のエンティティによって別個に所有されてよい。患者エンカウンタデータソース統合サービス130は、第4のエンティティによって所有されてよい。こうして、API(126、128、及び/又は144)は、データストア132、134及び146に対するアクセスに関してこれらの様々なエンティティ間のセキュリティを提供し得る。
これらの及び/又は他の理由で、特定の実装において、患者エンカウンタデータソース統合サービス130は、図1に示されている破線188a、188b、及び188cで示されているように、医療デバイスケースデータストア132、チャート化データストア134、及び/又はイベントログデータストア146と直接通信しないことが好ましい場合がある。このような場合において、患者エンカウンタデータソース統合サービス130は、医療デバイスケースデータストア132に格納されている情報の要求をケースAPI126に送信してよい。同様に、患者エンカウンタデータソース統合サービス130は、イベントログデータストア146に格納されている情報の要求をイベントログAPI144に送信してよい。同様に、患者エンカウンタデータソース統合サービス130は、チャート化データストア134に格納されている情報の要求をePCR API128に送信してよい。これらの要求のうちの任意のものは、適切なセキュリティクレデンシャルを含んでよい。セキュリティクレデンシャルに基づいて、ケースAPI126、ePCR API128、及び/又はイベントログAPI144は、情報の要求に対して許可又は拒否のいずれかをしてよい。それぞれのインタフェースが情報の要求を許可する場合、インタフェースは、適切なデータストアから要求された情報を索出する。患者エンカウンタデータソース統合サービス130は、患者エンカウンタデータソース統合サービス130によって識別された1又は複数の基準に従って1又は複数のデータマージ操作を実行してよい。患者エンカウンタデータソース統合サービス130が1又は複数のデータのマージ操作を完了したとき、患者エンカウンタデータソース統合サービス130は、医療デバイスケースデータストア132に格納するために、マージされたファイル(例えば、患者チャート化データにマージされた医療デバイスデータを含むファイル)をケースAPI126に戻してよい。
いくつかの例において、サーバ108は、ケースAPI126、ePCR API128、及び/又はイベントログAPI144を介して、医療デバイス102、モバイルコンピューティングデバイス104、及びリモートコンピューティングデバイス106等のリモートデバイスとデータを交換することができる。これらのインタフェースは、本明細書において説明されたePCRアプリケーション122、イベントログアプリケーション140、及びエンカウンタレビューアプリケーション148等のリモートデバイスによって実施される処理が発したコマンドを受信し、処理し、それに応答するように構成されている。インタフェース126、128及び144は、様々な相互運用性規格及びアーキテクチャスタイルを使用して実施されてよい。例えば、1つの例において、インタフェース126、128及び144は、レプレゼンテーショナルステートトランスファ(REST)アーキテクチャスタイルを使用して実施されるウェブサービスインタフェースである。この例において、インタフェース126、128及び144は、JavaScript(登録商標)オブジェクト表記法及び/又は拡張可能マークアップ言語とともにハイパーテキストトランスファープロトコル(HTTP)を使用してクライアントプロセスと通信する。いくつかの例において、HTTP通信の一部は、セキュリティを高めるために暗号化することができる。代替的に又は加えて、いくつかの例において、インタフェース126、128及び144は、特定のユニフォームリソースロケータに対するHTTPポストに、ケースデータ、イベントログデータ、チャート化データを記述するデータで応答する、.NETウェブインタフェースとして実装される。代替的に又は加えて、いくつかの例において、インタフェース126、128及び144は、送信制御プロトコルソケットを介してアクセス可能なシンプルなファイル転送プロトコルコマンド及び/又はプロプライエタリアプリケーションプロトコルを使用して実装される。このように、本明細書において説明されるインタフェース126、128及び144は、特定の実装に限定されない。
いくつかの例において、インタフェース126、128及び144は、信頼できるシステムパフォーマンスを可能にするために複数のエンドポイントを含む。例えば、少なくとも1つの例において、インタフェース126、128及び144のそれぞれは、ケースデータストア132、チャート化データストア134、又はイベントログデータストア146に以前に格納されたデータの要求を受信して処理するための1又は複数の第1のエンドポイントと、ケースデータストア132、チャート化データストア134、及びイベントログデータストア146内に新たなデータを格納する要求を受信して処理するための1又は複数の第2のエンドポイントとを含む。この構成は、ケースデータストア132、チャート化データストア134、及びイベントログデータストア146に既に格納されているデータの要求に、最小限の遅延で迅速にサーブすることができることを確実にすることができる。ePCR、ケースファイル、又はイベントログをアップロードする;ePCR、ケースファイル、又はイベントログをパースする;結果として得られるチャート化データ、ケースデータ、又はイベントログデータをケースデータストア132、チャート化データストア134、又はイベントログデータストア146に格納する要求は、より多くの処理時間及びリソースを要求する可能性があるので、この分岐アーキテクチャが役立つことができる。
いくつかの例において、インタフェース126、128及び144は、新たに受信されたケースデータ、チャート化データ、イベントログデータ、及び関連付け情報の患者エンカウンタデータソース統合サービス130を通知する(及び/又は含む)メッセージを患者エンカウンタデータソース統合サービス130に送信するように構成されている。メッセージが新たなデータの存在を患者エンカウンタデータソース統合サービス130に単に通知する場合、メッセージは、ケースデータストア132、チャート化データストア134、及び/又はイベントログデータストアから新たなデータを索出するために患者エンカウンタデータソース統合サービス130によって利用することができる新たなデータの1又は複数の識別子を含むことができるが、新たなデータの識別子を含むことは必須ではない。特定の例において、ケースAPI126は、医療デバイス102からケースファイルを受信し、ケースファイルを処理し、処理の結果を示すメッセージを医療デバイス102に送信するように構成されている。この処理は、その中に格納されているケースデータの値を索出するためにケースファイルをパースすることと、ケースデータをケースデータストア132に格納することとを含むことができる。同様に、いくつかの例において、ePCR API128は、モバイルコンピューティングデバイス104からePCRを受信し、ePCRを処理し、処理の結果を示すメッセージをモバイルコンピューティングデバイス104に送信するように構成されている。この処理は、その中に格納されているチャート化データの値を索出するためにePCRをパースすることと、チャート化データ及び/又はePCRをチャート化データストア134に格納することとを含むことができる。同様に、いくつかの例において、イベントログAPI144は、モバイルコンピューティングデバイス104からイベントログを受信し、イベントログを処理し、処理の結果を示すメッセージをモバイルコンピューティングデバイス104に送信するように構成されている。この処理は、その中に格納されているイベントログデータの値を索出するためにイベントログをパースすることと、イベントログデータ及び/又はイベントログをイベントログデータストア146に格納することとを含むことができる。ePCR及び/又はイベントログは、集約されたケースデータを生成するために患者エンカウンタデータソース統合サービス130によって参照することができる関連付け情報を含むことができることに留意すべきである。
いくつかの例において、インタフェース126及び128は、エンカウンタレビューアプリケーション148から集約されたケースデータの要求を受信するようにさらに構成されている。その要求は、集約されたデータが要求される患者エンカウンタを一意に識別するトークンを含むことができる。これらの要求の受信に応答して、インタフェース126及び128は、本明細書において説明される処理を使用して集約されたケースデータを準備及び/又は識別するとともに、集約されたケースデータをエンカウンタレビューアプリケーション148に戻すために、患者エンカウンタデータソース統合サービス130と相互運用するように構成されている。患者エンカウンタデータソース統合サービスが集約されたケースデータを事前に(例えば、エンカウンタレビューアプリケーション148からの要求の受信にいくらかの時間先んじて、関連付け情報の受信に応答して)準備している場合、患者エンカウンタデータソース統合サービス130は、トークンを使用して、集約されたデータをそのストレージから単純にフェッチして、集約されたデータをエンカウンタレビューアプリケーション148に送信することができる。
図1を引き続き参照すると、チャート化データストア134は、例えば、データベース(例えば、リレーショナルデータベース)によって実施し、非一時的記憶媒体に記憶することができる。一実装において、チャート化データストア134は、複数のePCRから導出されたチャート化データを格納する複数の記録を含む。少なくとも1つの例において、チャート化データストア134は、ePCRテーブル及びePCRフィールドテーブルを含むリレーショナルデータベーステーブルのセットに編成される。この例において、ePCRテーブルは、チャート化データストア134内の患者エンカウンタをドキュメント化するePCRをそれぞれ記述するデータの行を含む。こうして、ePCRテーブルにおける各行は、ePCRの一意の識別子、ePCRが生成されたときを示すタイムスタンプ、及びePCRによってドキュメント化された患者エンカウンタを記述するメタデータ(例えば、患者を一意に識別する患者識別情報、患者エンカウンタに関与したヘルスケア提供者、ePCRがクローズドエンドした理由及びアウトカム、患者エンカウンタの解決に使用された医療デバイス及びサプライの一意の識別子、患者エンカウンタ中に発生した総合的な問題、及び/又はePCRに関連付けられている派遣されたEMSイベントのタイプ)を格納するように構成されているフィールドを含むことができる。
この例を引き続き参照すると、ePCRフィールドテーブルは、ePCR内に格納されたフィールドをそれぞれ記述するデータの行を含む。こうして、ePCRフィールドテーブルにおける各行は、そのフィールドが属するePCRの一意の識別子を格納するように構成されているフィールド、ePCRに関連付けられているフィールドの中のフィールドを一意に識別するフィールド、フィールドに値が入力されたときを示す日付/タイムスタンプ、値のソース(例えば、特定の医療デバイス又は特定のコンピューティングデバイス)の一意の識別子、及び、(タイプ識別子又はテキスト情報を介して)フィールドに関連付けられている1又は複数の値を識別するフィールドを含む。特に、各ePCRは、特定のデータタイプの入力をそれぞれ要求する大量のフィールドを有することができる。例えば、いくつかの例示的なePCRは、100のフィールド、200のフィールド、400のフィールド、600のフィールド、又はそれよりも多くのフィールドを有してよい。この数のフィールドは、義務付けられてよく、したがって、各ePCRが完全であることが重要である。したがって、いくつかの例において、チャート化データストア134及び/又はePCRアプリケーション122等の他のコンポーネントは、ePCRアプリケーションのユーザによるePCRフィールドの修正/削除を防止するように構成されている。いくつかの例において、ePCRは、チャート化データストア134への送信のためにファイルにシリアル化することができることに留意すべきである。これらの例において、チャート化データストア134は、ePCRファイルそれら自体の完全な別個のコピーを(例えば、ラージバイナリオブジェクトとして)格納することができる。
図1を引き続き参照すると、ケースデータストア132は、例えば、データベース(例えば、リレーショナルデータベース)によって実装され、非一時的記憶媒体に記憶することができる。一実装において、ケースデータストア132は、エンカウンタ中に患者を処置するために使用された複数の医療デバイスからのケースファイルから導出されたケースデータを格納する複数の記録を含む。また、いくつかの例において、ケースデータストア132は、ケースファイルそれら自体の完全なコピー(例えば、ラージバイナリオブジェクトとして)格納することができる。ケースデータストア132に格納されているケースデータは、医療デバイスの観点から患者エンカウンタをドキュメント化することができる。したがって、患者エンカウンタ中に医療デバイスによって生成されたケースデータは、医療デバイスの識別子、エンカウンタ中に医療デバイスによって記録された患者の生理学パラメータ値、エンカウンタ中に医療デバイスによって患者に提供された処置の特性、エンカウンタ中にヘルスケア提供者によって取られたアクション、及びこの情報のうちの任意のものが記録されたときをドキュメント化したタイムスタンプを含むことができる。例えば、医療デバイスが除細動器である場合、ケースデータは、他の情報の中でも、患者のECGデータ等の患者生理学パラメータ、並びに、除細動器によって患者に送達された治療的ショックの特性、CPR(例えば、胸骨圧迫及び/又は換気)パフォーマンスデータ、並びに、除細動器の出力が上げられたとき及びこの情報が記録されたときを反映するタイムスタンプを含むことができる。
イベントログデータストア146は、例えば、データベース(例えば、リレーショナルデータベース)によって実装され、非一時的記憶媒体に記憶することができる。1つの例において、イベントログデータストアは、タイムスタンプが付与されたイベントをそれぞれ指定する複数の記録を含む。イベントログデータストア146は、多種多様なイベントを格納するように構成されている。これらのイベントの例としては、他のイベントの中でも、CPR実施、治療的電気パルスの送達、薬物の提供、特定のECGリズムの発生、自己心拍再開(ROSC)、患者バイタル情報、患者に実施された処置(例えば、挿管チューブの配置)、医療デバイス電源オン、保護された健康情報(例えば、患者を識別する情報)の入力、ヘルスケア提供者への医療デバイスプロンプトの提供、処置(例えば、患者の胸骨に位置するセンサから生成された加速度信号を介して検知された胸骨圧迫、患者の気道に沿って位置するセンサから生成された流量/圧力信号を介して検知された換気)の提供、特定のECGリズム(例えば、心室細動、心室頻拍、心停止、無脈性電気活動、洞調律等)の発生、患者への治療的電気パルスの送達、及び投薬の実施が挙げられる。
基準データストア136は、例えば、データベース(例えば、リレーショナルデータベース)によって実装され、非一時的記憶媒体に記憶することができる。1つの例において、基準データストア136は、関連付け情報の要素と、ケースデータ、イベントログデータ、及び/又はチャート化データのパラメータとの間の関係をそれぞれ指定する複数の記録を含む。この例において、複数の記録のそれぞれは、この関係を基準データストア136内の他の関係に対してランク付けする情報も含む。このランク付けは、図15及び図16を参照しながら以下でさらに説明されるように、反復検索プロセス中に患者エンカウンタデータソース統合サービスによってアクセスすることができる。
基準データストア136は、統合記録内のどのデータがePCRチャート化データファイルから発生し、統合記録内のどのデータが医療デバイスケースファイルから発生したかを追跡する監査証跡を任意で維持する。特定の実施形態において、コンフリクトするデータが存在する場合、直近に取得されたデータがより古いデータに優先することができる。コンフリクトするデータが存在する他の実施形態において、この構成情報は、どのデータが優先する(例えば、保持される)か及びどのデータが格下げされる(例えば、破棄される)かを決定するデータソースの階層を指定するために使用することができる。
1つの実装において、監査証跡は、各ファイルを処理した結果の指示とともに、患者エンカウンタデータソース統合サービス130によって処理された各ファイルの参照番号を含む。例えば、医療デバイスケースファイルは、(i)別の医療デバイスケースファイルとマージされている又は(ii)ePCRチャート化データファイルとマージされていると示され得る。複数のオリジナル医療デバイスケースファイルがマージされ、結果として得られたマージされたファイルが続いて患者エンカウンタデータソース統合サービス130によって処理される場合、オリジナルファイルを識別する監査ファイル内の情報を使用して、患者エンカウンタデータソース統合サービス130が、(i)オリジナルファイルが既に処理されている場合にはマージされたファイルを無視し、(ii)(例えば、マージされたファイルの残りが既に統合されている場合には)ePCRチャート化データファイルとの統合のためにマージされたファイルの一部のみを選択する、又は、(iii)マージされたファイルを、ePCR API128が冗長情報を除去するために使用することができる冗長性情報を伴うePCRチャート化データファイルと統合することを可能にすることができる。
ケースデータストア132、チャート化データストア134、及びイベントログデータストア146は、様々な物理及び/又は論理構造に従って編成することができる。少なくとも1つの例において、ケースデータストア132、チャート化データストア134、及びイベントログデータストア146は、高度に正規化されたスキーマを有するリレーショナルデータベース内に実装され、オラクル又はSQL-SERVER等の構造化クエリ言語(SQL)エンジンを介してアクセス可能である。このスキーマは、いくつかの実装において、ケースデータストア132、チャート化データストア134、及び/又はイベントログデータストア146が複数のテナントのためのデータを収容することを可能にする列及びデータを含むことができる。さらに、上で提供された説明は、ケースデータストア132、チャート化データストア134、及びイベントログデータストア146をリレーショナルデータベースとして示しているが、本明細書において説明される例は、特定の物理形態に限定されない。他のデータベースとしては、オペレーティングシステムによって維持される、シリアル化されたプロプライエタリデータ構造体を含むフラットファイル、階層型データベース、xmlファイル、NoSQLデータベース、ドキュメント指向データベース等が挙げられ得る。このように、本明細書において説明されているケースデータストア132及びチャート化データストア134は、特定の実装に限定されない。
ケースデータストア132、チャート化データストア134、及びイベントログデータストア146は、モバイルコンピューティングデバイス104及び/又は医療デバイス102から受信された情報を、その情報の後の使用を可能にするように、リモートデバイスよりも長い期間セキュアに格納することができる。例えば、モバイルコンピューティングデバイス104は、モバイルコンピューティングデバイス104への直接のユーザ入力を介して保護された健康情報(例えば、名前、住所、及び/又は社会保障番号等の患者識別情報)を受信してよく、次に、患者116に関与する過去の記録についてチャート化データストア134又はイベントログデータストア146に対してクエリするために、保護された健康情報の一部又は全てをサーバ108に搬送してよい。一実装において、モバイルコンピューティングデバイス104は、医療施設、保険会社、医療請求サービス、金融記録サービス、及び/又は健康情報交換によって提供されるもの等の様々なデータベースからの患者記録及び/又は情報にアクセスするために、ネットワーク112を介して、患者識別情報の一部又は全てを他のサーバに搬送することができる。他の例において、モバイルコンピューティングデバイス104は、限定されないが、有線若しくは無線通信及び/又はメッセージを含む他の方法で情報を受信するように構成することができる。
ネットワーク112を介してアクセスされるサーバ108及び/又は他のサーバは、次に、現在の緊急エンカウンタでヘルスケア提供者118Aを支援するために、任意のそのような記録又はそのような記録の一部を(例えば、イベントログスクリーン、患者チャート化スクリーン、又は既往歴スクリーンに表示するために)モバイルコンピューティングデバイス104に戻すように転送することができる。同様に、そのような過去のエンカウンタ情報は、本開示の例によれば、ヘルスケア提供者118B等の他のユーザによってアクセスされてもよい。
リモートコンピューティングデバイス106は、健康記録データストア110を実装するように構成されている1又は複数の物理的及び/又は仮想コンピュータを含むことができる。健康記録データストア110は、患者医療歴を記述する記録を含むことができる。これらの記録は、エンカウンタの前の病歴、エンカウンタにつながる兆候、エンカウンタ中に識別された任意の診断、エンカウンタの結果として処方された処置、及び処置からもたらされたアウトカム等の、様々な患者情報を含むことができる。少なくとも1つの例において、リモートコンピューティングデバイス106及び健康記録データストア110は、全州健康データ交換規格、地域健康データ交換規格、HL7メッセージ規格、及び米国処方薬プログラム協会(NCPDP)スクリプト規格等の健康データ交換規格をサポートする1又は複数のインタフェースを露呈するように構成されている健康情報交換(HIE)としてまとめて動作する。健康記録データストア110は、1つの組織によって、又は病院、診療所、医院、及び薬局等の他の組織若しくはネットワーク若しくは第三者のソースによって生成されたデータを含むことができることに留意すべきである。
[関連付けプロセス]
いくつかの例において、システム100は、複数の医療デバイスケースファイルからのケースデータを集約する様々な処理を実行するように構成されている。例えば、図4は、モバイルコンピューティングデバイス(例えば、図1のモバイルコンピューティングデバイス104)、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)、ケースインタフェース(例えば、図1のケースAPI126)、及び1又は複数の医療デバイス(例えば、図1の医療デバイス102)によって実行される集約プロセス400を示している。
集約プロセス400は、モバイルコンピューティングデバイスが新たな患者エンカウンタの開始を示す入力を受信すること(402)で開始する。例えば、モバイルコンピューティングデバイスは、患者エンカウンタに関与した異なる医療デバイスによって生成されたデータを関連付けるため等の関連付け情報の生成を要求する入力、新たなePCRの作成を要求する入力、又は新たなイベントログの作成を要求する入力を受信してよい。入力の受信に応答して、モバイルコンピューティングデバイスは、(例えば、図1の関連付け生成器142A又は142Bの実行を介して)新たな患者エンカウンタを表すトークンを生成する(404)。例えば、関連付け生成器142は、UUIDを生成し、このUUIDをローカルメモリ内にトークンとして格納することができる。患者エンカウンタ中の或る時点において、モバイルコンピューティングデバイスは、患者エンカウンタ中に患者(例えば、図1の患者116)を処置するために使用された1又は複数の医療デバイスの1又は複数の第1の識別子の1又は複数の表現を取得する(406)。例えば、モバイルコンピューティングデバイスは、医療デバイスを識別するQRコードのイメージ又は(例えば、NFCを介して)識別タグを取得することができる。次に、モバイルコンピューティングデバイスは、(例えば、図1のePCR API128又はイベントログAPI144等のePCRインタフェース又はイベントログインタフェースを介して)トークン及び1又は複数の第1の識別子を含む関連付け情報を指定する1又は複数のメッセージを患者エンカウンタデータソース統合サービスに送信する(408)。
集約プロセス400の別の部分として、医療デバイスは、患者エンカウンタ中に患者についてのケースファイルを記録する(419)。例えば、医療デバイスは、患者のタイムスタンプが付与された生理学データ、患者人口統計学データ、及び/又はヘルスケア提供者パフォーマンスデータを取得し、このケースデータを医療デバイスの1又は複数の第2の識別子と関連付けてローカルメモリに格納してよい。医療デバイスは、ケースファイル及び医療デバイスの1又は複数の第2の識別子を含むメッセージをケースインタフェースに送信する(422)。ケースインタフェースは、ケースファイル及び1又は複数の第2の識別子を含むメッセージを受信し(424)、これらのケースファイルを処理(例えば、パース)して、ケースデータを生成する(426)。次に、ケースインタフェースは、患者エンカウンタデータソース統合サービスによる後続の処理のために、ケースデータを第2の識別子と関連付けてケースデータストア(例えば、図1のケースデータストア132)内に格納する(428)。
集約プロセス400を続けると、患者エンカウンタデータソース統合サービスは、関連付け情報を指定するメッセージを受信する(410)。患者エンカウンタデータソース統合サービスは、(例えば、図6、図7、及び図12~図16を参照しながら以下で詳細に説明されるもの等の、1又は複数の関連付けプロセスの実行を介して)医療デバイスの第1の識別子に対応する第2の識別子と関連付けてケースデータストアに格納されているケースデータを識別する(412)。対応する医療デバイス識別子は、患者エンカウンタについてのケースファイルの識別に役立つが、対応する医療デバイス識別子は、単独では、患者エンカウンタに関与したケースファイルのみを確実に識別するのに不十分であり得ることに留意すべきである。したがって、いくつかの例は、以下でさらに議論されるように、タイムスタンプ及び/又はジオタグ等の追加の基準を利用する。患者エンカウンタデータソース統合サービスは、識別されたケースデータから集約されたケースデータを生成し(414)、(例えば、ePCRインタフェース及びイベントログインタフェースのうちの一方又は両方を介して)集約されたケースデータをモバイルコンピューティングデバイスに送信する(414)。この集約されたケースデータは、全て同じ患者エンカウンタに関連付けられている、識別されたケースデータ、チャート化データ、及び/又はイベントログデータを含むことができる。
集約/統合プロセス400を続けると、モバイルコンピューティングデバイスは、集約されたデータを受信し(416)、例えばローカルアプリケーション(例えば、ePCRアプリケーション122、イベントログアプリケーション140、及び/又はエンカウンタレビューアプリケーション148)の実行を介して、集約されたデータをレンダリングする(418)。いくつかの例において、モバイルコンピューティングデバイスは、患者エンカウンタにリンクされた複数の医療デバイスによって生成されたケースファイルのための関連付け情報のソースであるので、同じモバイルコンピューティングデバイスが、さもなければ認証若しくは他の不便な方策を伴い得る不便な行為であり得る他のデバイスへの別個のアクセスをヘルスケア提供者に要求することなく、要求によって又は自動的に、集約されたデータを受信してよい。
いくつかの例において、集約されたケースデータは、また、モバイルコンピューティングデバイス104A以外のコンピューティングデバイス(例えば、モバイルコンピューティングデバイス104C又は別のコンピューティングデバイス)に送信され(414)、例えば医療ケースレビューステーション、リモートテレメディシンデバイス等におけるユーザインタフェースディスプレイ上にレンダリング(429)されてよいことに留意すべきである。例えば、集約されたケースデータは、シーンから遠隔にいる臨床医がすぐその場にいるヘルスケア提供者にガイダンス又は命令を与えることができるように、彼/彼女に利用可能とされてよい。代替的に又は加えて、集約されたケースデータは、ケース後分析及びレビューのために、医療イベントが終了した後にユーザによってアクセスされてよい。
集約プロセス400のいくつかの例において、操作422内で、医療デバイスは、ケースファイルをリアルタイムでケースインタフェースにストリーミングすることにも留意すべきである。これらの例において、ケースインタフェース及び患者エンカウンタデータソース統合サービスは、また、ライブの患者エンカウンタの一部としてストリーミングされているケースデータを識別するようにリアルタイムで動作し、ストリーミングされているケースデータを集約し、リアルタイムレンダリングのために集約されたケースデータをモバイルコンピューティングデバイスに送信する。したがって、集約されたケースデータは、患者エンカウンタ中の全ての注目すべき出来事の高いレベルの視点を実現可能であるように、医療実践者がシーンに位置する様々なデバイスによって生成されたライブ情報を受信可能であるようにリアルタイム方式でアップデートされてよい。
いくつかの例において、患者エンカウンタデータソース統合サービス130は、複数のケースファイル(例えば、シーンに位置する医療デバイスによって生成された)を識別し、互いに関連付け、いくつかの実装において、患者エンカウンタをドキュメント化するePCR及び/又はイベントログと関連付けるように構成されている。上で議論したように、ケースファイル、ePCR、及びイベントログからの医療データは、それぞれ、ケースファイル、ePCR、及びイベントログのコピーとともに、ケースデータストア132、チャート化データストア134、及びイベントログデータストア146内に格納することができる。いくつかの実装において、ケースファイル、ePCR、及びイベントログ間の関連付けを、データストア132、134及び146内に格納することもできる。図5Aは、これらの及び他の実装における患者エンカウンタデータソース統合サービス130によって実行される集約プロセス500aの1つの例を示している。
図5Aに示されているように、プロセス500aは、患者エンカウンタデータソース統合サービスが、医療デバイスから識別情報を取得し、続いて医療デバイスから発生したデータのリンクを提供するために関連付け情報を生成したシーンに位置するモバイルコンピューティングデバイス104から、関連付け情報を受信すること(502a)で開始する。いくつかの例において、医療デバイスデータを関連付けるためにモバイルコンピューティングデバイスを使用するヘルスケア提供者は、医療デバイス間の関連付け情報を生成するために及び関係する対応するケースファイルを一緒に関連付ける要求をサーバに送信するために、モバイルデバイス上で入力を与えてよい。患者エンカウンタデータソース統合サービスは、関連付け情報を含むインタフェース(例えば、図1のケースAPI126、ePCR API128、及び/又はイベントログAPI144)から生成されたメッセージを受信することができる(502a)。代替的に又は加えて、いくつかの例において、患者エンカウンタデータソース統合サービスは、データストア(例えば、図1のチャート化データストア134及び/又はイベントログデータストア146)から関連付け情報を受信することができる(502)。これらの例において、患者エンカウンタデータソース統合サービスは、インタフェースからのメッセージに含まれているチャート化データ又はイベントログデータの識別子を利用して、チャート化データ又はイベントログデータ内に含まれている関連付け情報を要求して受信することができる(502a)。代替的に又は加えて、これらの例において、患者エンカウンタデータソース統合サービスは、新たなチャート化データ又はイベントログデータが要求された最後の時間をマークするために患者エンカウンタデータソース統合サービスによって維持されている予め定められたタイムスタンプの後でチャート化データストアに追加されたチャート化データ又はイベントログデータストアに追加されたイベントログデータを要求して受信することができる(502a)。
プロセス500aを続けると、患者エンカウンタデータソース統合サービスは、関連付け情報に基づいて少なくとも1つの検索基準を生成する(504a)。いくつかの例において、少なくとも1つの検索基準は、関連付け情報に含まれている複数の医療デバイスの識別子及び関連付け情報の少なくとも1つの要素と医療デバイスケースファイルに関連付けられている少なくとも1つのパラメータとの間の少なくとも1つの予め定められた関係を指定する。予め定められた関係は、例によって異なることができる。例えば、いくつかの例において、予め定められた関係は、少なくとも1つの要素と少なくとも1つのパラメータとの間の等価性とすることができる。等価性の予め定められた関係は、少なくとも1つの要素と少なくとも1つのパラメータとが、精確に合致させる又は満たすことができる数値又はストリングを有する場合に、特に有用とすることができる。代替的に又は加えて、予め定められた関係は、少なくとも1つの要素と少なくとも1つのパラメータとの間の近接性又は類似性とすることができる。近接性又は類似性に基づく予め定められた関係は、少なくとも1つの要素と少なくとも1つのパラメータとが、タイムスタンプ、異なる時点で若しくは異なるデバイスによって取得された生理学測定値、又は不正確に(例えば、閾値近接性又は類似性を満たすことによって)しか合致させる若しくは満たすことができない他の値を有する場合に、特に有用とすることができる。代替的に又は加えて、予め定められた関係は、複数の要素とパラメータとの間の等価性、近接性、及び/又は類似性の組み合わせとすることができる。例えば、1つの例において、予め定められた関係は、ケースファイルに記録されたケース開始時間及びケース終了時間と関連付け情報との間の重複範囲、並びに、ケースファイルからの患者生体識別子と関連付け情報との間の等価性、並びに、ケースファイルからのヘルスケア提供者生体識別子と関連付け情報との間の等価性のうちの少なくとも1つを要求する。いくつかの実装において、ケースファイルに記録されているケース開始時間及び終了時間と関連付け情報との間の重複範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。例えば、関連付け情報が10:00amのケース開始時間及び10:15amのケース終了時間を示す場合、ターゲット時間範囲は、9:55am~10:20am、9:55am~10:16am、9:59am~10:20am、10:01am~10:15am、10:00am~10:14am、又は任意の他の好適な範囲であってよい。こうして、ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでないことが理解される。通常、異なる医療デバイス間のクロックは、互いに正確に同期されていない場合がある。いくつかの実施形態において、ケース開始時間/終了時間は、医療デバイスケースファイルと関連付け情報との間で正確に合致する。
いくつかの例において、少なくとも1つの予め定められた関係は、患者エンカウンタデータソース統合サービスのハードコーディング部分である。これらの例において、患者エンカウンタデータソース統合サービスは、関連付け情報内の少なくとも1つの要素を識別するとともにその少なくとも1つの要素を予め定められた関係と関連付けることによって、少なくとも1つの検索基準を生成する(504a)。例えば、予め定められた関係が近接しており、ケースファイルのパラメータが関連付け情報の要素の範囲内にあることを要求し、その要素が、エンカウンタをドキュメント化するケースが開始したときを示すタイムスタンプである場合、患者エンカウンタデータソース統合サービスは、関連付け情報内のタイムスタンプを識別するとともに、検索506aにおけるその後の使用のために、そのタイムスタンプをケース開始時間の範囲と関連付けることによって、少なくとも1つの検索基準を生成する(504a)。そのような範囲は、患者エンカウンタデータソース統合サービス及び/又は予め定められた値によって計算された動的値とすることができることに留意すべきである。例えば、範囲は、関連付け情報からのケース開始時間とケア移行時間との間の計算された範囲を含むことができる。代替的に又は加えて、ケース開始時間の予め定められた範囲は、例えば、0~1分、0~2分、0~5分、及び1~10分の間とすることができる。任意の所与の予め定められた関係は、これらの範囲を、同一のイベント(例えば、ケース開始時間)を示す要素と時間パラメータとの間、又は、異なるイベント(例えば、ケース開始時間及び処置時間又は移行時間)を示す要素と時間パラメータとの間に適用することができる。
いくつかの例において、少なくとも1つの予め定められた関係は、ソフトコーディングされ、基準データストア(例えば、図1の基準データストア136)内に格納される。これらの例において、患者エンカウンタデータソース統合サービスは、上で説明された関連付け情報内で、予め定められた関係によって指定される少なくとも1つの要素を識別する前に、基準データストアから好ましい予め定められた関係を識別することによって、少なくとも1つの検索基準を生成することができる(504a)。例えば、いくつかの例において、プロセス500aの現在のインスタンスによってまだ使用されていない最高ランクの予め定められた関係を発見することによって、患者エンカウンタデータソース統合サービスは、好ましい予め定められた関係を識別することができる。
少なくとも1つの要素及び少なくとも1つのパラメータのそれぞれは、単一の要素若しくはパラメータ又は複数の要素若しくはパラメータとすることができることに留意すべきである。例えば、いくつかの例において、少なくとも1つの要素は、ePCR又はイベントログが開かれた時間を示すタイムスタンプであり、少なくとも1つのパラメータは、ケースファイルが開始された時間を示すタイムスタンプである。他の例において、少なくとも1つの要素は、複数の要素を含み、少なくとも1つのパラメータは、複数のパラメータを含む。これらの例のいくつかにおいて、複数の要素は、ePCR又はイベントログがサーバ108にアップロードされた時間を示すタイムスタンプ及びePCR又はイベントログを生成したモバイルコンピューティングデバイスの識別子を含み、複数のパラメータは、ケースファイルがサーバ108にアップロードされた時間を示すタイムスタンプ及びケースファイルを生成した医療デバイスの識別子を含む。関連付け情報の他の要素は、チャート化データにおいて指定された、患者識別子、ヘルスケア提供者識別子、医療デバイス識別子、患者の移送を示すタイムスタンプ、患者処置情報、患者医療情報、患者人口統計学情報、及び生理学測定値を含むことができる。ケースファイルに関連付けられている他のパラメータは、ケースファイルにおいて指定された医療デバイスによって取得された、患者識別子、ヘルスケア提供者識別子、医療デバイス識別子、患者の移送を示すタイムスタンプ、患者処置情報、患者医療情報、患者人口統計学情報、及び生理学測定値を含むことができる。患者識別子は、生体情報(例えば、顔認識情報、指紋情報、網膜スキャン情報等)を含むことができる。医療デバイス識別子は、ePCRに手動で入力された識別子、医療デバイスのメモリから索出された識別子、医療デバイスによってモバイルコンピューティングデバイスに電子的に送信された識別子、及び/又は医療デバイスに関連付けられているバー若しくはクイックレスポンスコードからスキャンされた識別子を含むことができる。生理学測定値は、他の生理学データの中でも、血圧、体温、呼吸数、心拍数、及び心電図(ECG)データを含むことができる。
プロセス500aを続けると、患者エンカウンタデータソース統合サービスは、少なくとも1つの検索基準に合致する又はそれを満たすケースファイルについてケースデータを検索する(506a)。この検索(506a)中、患者エンカウンタデータソース統合サービスは、少なくとも1つの検索基準に基づいて関連付け情報と関連付けるためにケースファイルを識別することができる(508a)。例えば、患者エンカウンタデータソース統合サービスは、ケースデータに格納されている、ケースファイルに関連付けられているパラメータが、少なくとも1つの検索基準において格納されている関連付け情報の要素と予め定められた関係を満たす場合、ケースファイルを対応するケースファイルとして識別することができる(508a)。
患者エンカウンタデータソース統合サービスが対応するケースデータの関連付けを識別する(508a)場合、患者エンカウンタデータソース統合サービスは、後続の処理のために、複数の医療デバイスケースファイルからの(リアルタイムでストリーミングされていてもよい)ケースデータを含む統合データソースエンカウンタ構造体を格納し(510a)、プロセス500aは終了する。統合データソースエンカウンタ構造体は、例えば、複数の医療デバイスケースファイル、複数の医療デバイスケースファイルから生成されたケースデータ、及び/又は、関連付け情報を含む若しくはそれに関連付けられているチャート化データ及び/又はイベントログデータのうちの1又は複数の、コピー又はそれに対するポインタを含むことができる。上で説明したように、関連付け情報は、関連付け情報とチャート化データ及び/又はイベントログデータとの両方を生成するために使用されたモバイルデバイスの識別子を介して、チャート化データ及び/又はイベントログデータに関連付けることができる。さらに、いくつかの例において、統合データソースエンカウンタ構造体は、関連付けられた複数の医療デバイスケースファイルからインポートされたケースデータを含む補完ePCR又はイベントログを含むことができる。統合データソースエンカウンタ構造体は、例えば、チャート化データストア、イベントログデータストア、及び/又はケースデータストアに格納することができる。
図5Bは、患者エンカウンタデータソース統合サービス130によって実行される、関連付け情報に含まれている医療デバイス識別子と合致する(例えば、正確に又は厳密に合致する)医療デバイス識別子を含む1又は複数の医療デバイスケースファイルを識別する統合プロセス500bの一例を示している。
図5Bに示されているように、プロセス500bは、患者エンカウンタデータソース統合サービス130が、モバイルコンピューティングデバイス104によってアップロードされた関連付け情報を受信すること(502b)で開始する。患者エンカウンタデータソース統合サービス130は、図5Aを参照しながら上で説明したプロセス500a内で、受信する(502a)ために患者エンカウンタデータソース統合サービス130によって実行されるもの等のアクションを実行することによって、プロセス500b内で受信することができる(502b)。
患者エンカウンタデータソース統合サービス130は、関連付け情報に含まれている医療デバイス識別子が、1又は複数の医療デバイスケースファイルに含まれている医療デバイス識別子と合致する(例えば、正確に又は厳密に合致する)ことを指定する少なくとも1つの検索基準を生成する(504b)。医療デバイス識別子は、例えば、RFIDタグ、バーコード、又はQRコードからの情報を含んでよい。医療デバイス識別子は、ePCRに手動で入力された識別子、医療デバイスのメモリから索出された識別子、医療デバイスによってチャート化デバイスに電子的に送信された識別子、及び/又は医療デバイスに関連付けられているバー若しくはQRコードからスキャンされた識別子を含むことができる。
プロセス500bを続けると、患者エンカウンタデータソース統合サービス130は、少なくとも1つの検索基準を満たすケースファイルを検索する(506b)。特に、患者エンカウンタデータソース統合サービス130は、関連付け情報に含まれている医療デバイス識別子と合致する(例えば、正確に又は厳密に合致する)医療デバイス識別子を含む医療デバイスケースファイルについて検索する。患者エンカウンタデータソース統合サービス130が、少なくとも1つの検索基準に基づいて医療デバイス識別子を含む1又は複数のケースファイルを識別する(508b)場合、患者エンカウンタデータソース統合サービス130は、ケースデータを含む統合データソースエンカウンタ構造体を格納し(510b)、プロセス500bが終了する。患者エンカウンタデータソース統合サービス130は、図5Aを参照しながら上で説明したプロセス500a内で、格納する(510a)ために患者エンカウンタデータソース統合サービス130によって実行されるもの等のアクションを実行することによって、プロセス500b内で格納することができる(510b)。
患者エンカウンタデータソース統合サービス130によって実行される統合プロセスの別の例は、関連付け情報に含まれているケース開始時間及び/又はケース終了時間に合致する(例えば、正確に又は厳密に合致する)ケース開始時間及び/又はケース終了時間を含む医療デバイスケースファイルを識別する。本明細書において使用されるとき、医療デバイスケースファイルからのケース開始時間及び/又は終了時間が関連付け情報に含まれているケース開始時間及び/又は終了時間と合致することは、ターゲット時間範囲内の時間を含むことができる。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。例えば、関連付け情報が10:00amのケース開始時間及び10:15amのケース終了時間を示す場合、ターゲット時間範囲は、9:55am~10:20am、9:55am~10:16am、9:59am~10:20am、10:01am~10:15am、10:00am~10:14am、又は任意の他の好適な範囲であってよい。こうして、ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでないことが理解される。通常、異なる医療デバイス間のクロックは、互いに正確に同期されていない場合がある。いくつかの実施形態において、ケース開始時間/終了時間は、医療デバイスケースファイルと関連付け情報との間で正確に合致する。例示的なプロセスにおいて、患者エンカウンタデータソース統合サービス130は、チャート化データに含まれているケース開始時間及び/又はケース終了時間が、医療デバイスケースファイルに含まれているケース開始時間及び/又はケース終了時間と合致する(例えば、正確に又は厳密に合致する)ことを指定する少なくとも1つの検索基準を生成する。例えば、1つの実装において、関連付け情報に含まれているケース開始時間は、所与の医療デバイスケースファイルに含まれているケース開始時間と合致する。別の実装において、関連付け情報に含まれているケース終了時間は、所与の医療デバイスケースファイルに含まれているケース終了時間と合致する。別の実装において、(a)関連付け情報に含まれているケース開始時間が、所与の医療デバイスケースファイルに含まれているケース開始時間と合致し、(b)関連付け情報に含まれているケース終了時間が、所与の医療デバイスケースファイルに含まれているケース終了時間と合致する。患者エンカウンタデータソース統合サービス130は、次に、少なくとも1つの検索基準を満たす1又は複数のケースファイルについてケースデータを検索する。特に、患者エンカウンタデータソース統合サービス130は、関連付け情報に含まれているケース開始時間及び/又はケース終了時間と合致するケース開始時間及び/又はケース終了時間を含む1又は複数の医療デバイスケースファイルについて検索する。患者エンカウンタデータソース統合サービス130が、少なくとも1つの検索基準に基づいて関連付け情報と関連付けるために1又は複数のケースファイルを識別する場合、患者エンカウンタデータソース統合サービス130は、例えば、図5Aを参照しながら上で説明したプロセス500a内で格納する(510a)ために患者エンカウンタデータソース統合サービス130によって実行されるもの等のアクションを実行することによって、統合データソースエンカウンタ構造体を格納する。
図5Cは、患者エンカウンタデータソース統合サービス130によって実行される、関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義された「ターゲット時間範囲」内にあるケース開始時間及び/又はケース終了時間を含む1又は複数の医療デバイスケースファイルを識別する、統合プロセス500cの一例を示している。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。例えば、関連付け情報が10:00amのケース開始時間及び10:15amのケース終了時間を示す場合、ターゲット時間範囲は、9:55am~10:20am、9:55am~10:16am、9:59am~10:20am、10:01am~10:15am、10:00am~10:14am、又は任意の他の好適な範囲であってよい。こうして、ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでないことが理解される。
図5Cに示されているように、プロセス500cは、患者エンカウンタデータソース統合サービス130が、モバイルコンピューティングデバイス104によってアップロードされた関連付け情報を受信すること(502c)で開始する。患者エンカウンタデータソース統合サービス130は、図5Aを参照しながら上で説明したプロセス500a内で、受信する(502a)ために患者エンカウンタデータソース統合サービス130によって実行されるもの等のアクションを実行することによって、プロセス500c内で受信することができる(502c)。
患者エンカウンタデータソース統合サービス130は、1又は複数の医療デバイスケースファイルに含まれているケース開始時間及びケース終了時間がターゲット時間範囲内にあることを指定する少なくとも1つの検索基準を生成する(504c)。上で述べられたように、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義される。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。
プロセス500cを続けると、患者エンカウンタデータソース統合サービス130は、少なくとも1つの検索基準を満たす1又は複数のケースファイルについて検索する(506c)。特に、患者エンカウンタデータソース統合サービス130は、指定されたターゲット時間範囲内にあるケース開始時間及びケース終了時間を含む1又は複数の医療デバイスケースファイルについて検索する。例えば、1つの実装において、患者エンカウンタデータソース統合サービス130は、関連付け情報内にある関係するタイムスタンプに基づいてターゲット時間範囲を定義することによって、少なくとも1つの検索基準を生成する(504c)。別の実装において、患者エンカウンタデータソース統合サービス130は、関連付け情報内の関係するタイムスタンプに基づいてターゲット時間範囲を定義するとともに、ターゲット範囲の開始時間及び/又はターゲット範囲の終了時間に好適な閾値近接性を適用することによって、少なくとも1つの検索基準を生成する(504c)。このように、ターゲット時間範囲は、必ずしも関連付け情報に含まれている開始時間及び終了時間によって定義されない。患者エンカウンタデータソース統合サービス130が少なくとも1つの検索基準に基づいて関連付け情報と関連付けるために1又は複数のケースファイルを識別する(508c)場合、患者エンカウンタデータソース統合サービス130は、統合データソースエンカウンタ構造体を格納し(510c)、プロセス500cが終了する。患者エンカウンタデータソース統合サービス130は、図5Aを参照しながら上で説明したプロセス500a内で、格納する(510a)ために患者エンカウンタデータソース統合サービス130によって実行されるもの等のアクションを実行することによって、プロセス500c内で格納することができる(510c)。
図5Dは、患者エンカウンタデータソース統合サービス130によって実行される、(a)関連付け情報に含まれている医療デバイス識別子に合致する(例えば、正確に又は厳密に合致する)医療デバイス識別子と、(b)関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義される「ターゲット時間範囲」内にあるケース開始時間及びケース終了時間とを含む1又は複数の医療デバイスケースファイルを識別する、統合プロセス500dの一例を示している。上で述べたように、いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。こうして、ターゲット時間範囲は、図5A~図5C関して前に議論したように、関連付け情報に含まれているそれぞれのケース開始時間及び終了時間の閾値近接性内にあるターゲット範囲の開始時間及び終了時間によって定義されてよい。ターゲット範囲の開始時間と関連付け情報ケース開始時間との間の差は、ターゲット範囲の終了時間と関連付け情報ケース終了時間との間の差と必ずしも同じでない。
図5Dに示されているように、プロセス500dは、患者エンカウンタデータソース統合サービス130が、モバイルコンピューティングデバイス104によってアップロードされた関連付け情報を受信すること(502d)で開始する。患者エンカウンタデータソース統合サービス130は、図5Aを参照しながら上で説明したプロセス500a内で、受信する(502a)ために患者エンカウンタデータソース統合サービス130によって実行されるもの等のアクションを実行することによって、プロセス500d内で受信することができる(502d)。
患者エンカウンタデータソース統合サービス130は、(a)関連付け情報に含まれている医療デバイス識別子が、1又は複数の医療デバイスケースファイルに含まれている医療デバイス識別子と合致する(例えば、正確に又は厳密に合致する)ことと、(b)1又は複数の医療デバイスケースファイルに含まれているケース開始時間及びケース終了時間が、ターゲット時間範囲内にあることとを指定する少なくとも1つの検索基準を生成する(504d)。上で述べたように、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間及び終了時間に基づいて定義される。いくつかの実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する。他の実装において、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間のわずかに前又はわずかに後に開始し、関連付け情報に含まれているケース終了時間のわずかに前又はわずかに後に終了する。
プロセス500dを続けると、患者エンカウンタデータソース統合サービス130は、少なくとも1つの検索基準を満たす1又は複数のケースファイルについて検索する(506d)。特に、患者エンカウンタデータソース統合サービス130は、(a)関連付け情報に含まれている医療デバイス識別子と合致する(例えば、正確に又は厳密に合致する)医療デバイス識別子と、(b)指定された時間範囲内にあるケース開始時間及びケース終了時間とを含む1又は複数の医療デバイスケースファイルについて検索する。患者エンカウンタデータソース統合サービス130が少なくとも1つの検索基準に基づいて関連付け情報と関連付けるためにケースファイルを識別する(508d)場合、患者エンカウンタデータソース統合サービス130は、統合データソースエンカウンタ構造体を格納し(510d)、プロセス500dが終了する。患者エンカウンタデータソース統合サービス130は、図5Aを参照しながら上で説明したプロセス500a内で、格納する(510a)ために患者エンカウンタデータソース統合サービス130によって実行されるもの等のアクションを実行することによって、プロセス500d内で格納することができる(510d)。
上で述べたように、検索基準は、医療デバイスケースファイル間の少なくとも1つの関係を指定し、統合データソースエンカウンタ構造体に統合されることになるデータを有する医療デバイスケースファイルのうちの1又は複数の識別を可能にする。図5B~図5Dは、例示的なファイル統合プロセスを示しており、そのそれぞれは、1又は複数の医療デバイスケースファイルについて検索して識別するために1又は複数の検索基準を使用する。これらの及び他の実装において、以下のうちの1又は複数を含む他の検索基準を使用することができる:(i)医療デバイスケースファイルに含まれているケース開始時間が関連付け情報に含まれているケース開始時間の閾値近接性内にあることを指定する検索基準、(ii)医療デバイスケースファイルに含まれているケース終了時間が関連付け情報に含まれているケース終了時間の閾値近接性内にあることを指定する検索基準、(iii)医療デバイスケースファイルに含まれているケース開始時間及び終了時間が両方ともターゲット時間範囲内にあることを指定する検索基準、ここで、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間で開始し、関連付け情報に含まれているケース終了時間で終了する、並びに、(iv)医療デバイスケースファイルに含まれているケース開始時間及び終了時間が両方ともターゲット時間範囲内にあることを指定する検索基準、ここで、ターゲット時間範囲は、関連付け情報に含まれているケース開始時間の前の指定された期間で開始し、関連付け情報に含まれているケース終了時間の後の指定された期間で終了する。検索基準が、関連付け情報に含まれているタイムスタンプを医療デバイスケースファイルに含まれているタイムスタンプと比較することに依存する実装において、関連付け情報内のタイムスタンプ及び医療デバイスケースファイル内のタイムスタンプが基づく異なる時刻系を考慮するように、任意選択の調整を含めることができる。そのような異なる時刻系は、異なるタイムゾーンの使用又は日光節約時間の使用の結果であり得る。
図5B、図5C及び図5Dにおいて説明された様々な検索基準及び方法は、様々な機器構成及び能力に依存し得る。これらの構成及び能力は、ケース開始時間、ケース終了時間、及び/又は医療デバイス識別子が統合データソースエンカウンタ構造体に記録される方式を決定してよい。例えば、これらの値は、自動的に記録されるか又は手動で入力若しくはトリガされてよい。さらに、これらの構成及び能力は、ケース開始時間、ケース終了時間、及び/又は医療デバイス識別子のうちの1又は複数が検索基準として利用可能であるか否かを決定してよい。例えば、ケース開始時間、ケース終了時間、及び/又は医療デバイス識別子のうちの1又は複数を自動的に記録又は誘発する能力を欠くシステムにおいて、これらの値のうちの1又は複数は、検索基準としての使用に利用不可能であってよい。最後に、これらの構成及び能力は、ケース開始時間、ケース終了時間、及び/又は医療デバイス識別子の、検索基準としての相対的信頼性又は精度を決定してよい。例えば、自動的に記録された値は、手動で入力された値よりも正確で信頼できるとされてよい。
関連付け情報は、ケース開始時間及びケース終了時間を含んでよい。これらの時間は、例えば、患者チャート化ファイル又はイベントログに自動的に記録されてよい。一実装において、これらの時間は、モバイルコンピューティングデバイス104上の時刻に対応してよい。例えば、ケース開始時間は、患者チャート化アプリケーション又はイベントログアプリケーションが新たなチャート化ファイルを開いて開始する時刻であってよく、ケース終了時間は、患者チャート化アプリケーション又はイベントログアプリケーションがチャート化ファイルを閉じる時刻であってよい。別の例として、患者チャート化アプリケーション又はイベントログアプリケーションは、コンピュータ支援ディスパッチ(CAD)又は他のディスパッチサーバ若しくはデバイスからモバイルコンピューティングデバイス104に送信されたケース開始時間を受信し、この時間を患者チャート化ファイル又はイベントログに記録してよく、これは、関連付け情報の一部として含まれてよい。このケース開始時間は、このケースがEMSクルーにアサインされたときの、CAD又はディスパッチサーバ若しくはデバイスにおける時刻に対応してよい。さらなる例として、この時間は、EMSクルーがCAD又は他のディスパッチサーバ若しくはデバイスからのケースアサインメントを承諾したモバイルコンピューティングデバイス104上での時刻に対応してよい。このシナリオにおいて、モバイルコンピューティングデバイス104は、ケースアサインメントを表示し、ユーザに承諾を促し、承諾時間を患者チャート化ファイル又はイベントログにおけるケース開始時間として自動的に記録してよい。いくつかの実施形態において、ケース開始時間は、ユーザが医療イベントに関連付けられている医療デバイスのうちの1又は複数でケースファイルをアクティベート及び/又は開始した時間に対応してよい。さらに別の例として、モバイルコンピューティングデバイス104は、患者輸送先において(例えば、WIFI若しくはBLUETOOTH又は輸送先において開始された他の通信結合に基づいて)時間を受信し、この受信された時間をケース終了時間として自動的に記録してよい。またさらなる例として、モバイルコンピューティングデバイス104は、チャート化データストア134に及び/又はリモートコンピューティングデバイス106(例えば、病院サーバ又は患者輸送先における他のコンピューティングデバイス)にケースファイルを送信してよく、モバイルコンピューティングデバイス104は、この送信の時間をケース終了時間として記録してよい。
一実装において、モバイルコンピューティングデバイス104は、モバイルコンピューティングデバイス104上のジオフェンシングアプリケーションからケース開始時間及び/又はケース終了時間を受信して自動的に記録してよい。例えば、ジオフェンシングアプリケーションは、モバイルコンピューティングデバイス104がEMSエージェンシロケーションの周囲の又は患者のロケーションの周囲のジオフェンスを横切ることに基づいて、ケース開始時間をモバイルコンピューティングデバイス104に提供してよい。別の例として、ジオフェンシングアプリケーションは、モバイルコンピューティングデバイス104が患者のロケーションの周囲又は患者輸送先(例えば、病院、医院、透析センタ、精神病センタ、又は他のケア提供者ロケーション)の周囲のジオフェンスを横切ることに基づいて、ケース終了時間をモバイルコンピューティングデバイス104に提供してよい。同様に、モバイルコンピューティングデバイス104は、モバイルコンピューティングデバイス104の1又は複数のGPS座標に基づいて、ケース開始時間及び/又はケース終了時間を受信して自動的に記録してよい。
いくつかの実装において、ケース開始時間は、処置の時間(例えば、除細動ショック、薬剤、又は他の治療が医療デバイスによって患者に送達された時間)であってよい。医療デバイスは、デバイスが治療を提供した時間を(例えば、タイムスタンプが付与されたイベントマーカとして)記録もする。こうして、「ケース開始時間」間の相関は、関連付け情報内に及び医療デバイスケースファイル内に記録されている治療送達時間の間の相関を含んでよい。関連付け情報は、医療デバイスからこの情報を(例えば、送信された情報として)受信してよい、又は、この情報を関連付け情報への入力を介して受信してよい。
一実装において、モバイルコンピューティングデバイス104は、ePCRアプリケーション122又はイベントログアプリケーション140においてケース開始時間及び/又はケース終了時間を入力又は確認することをユーザに促してよい。モバイルコンピューティングデバイス104は、このユーザが入力した又は確認した時間を関連付け情報に記録してよい。この場合、記録時間は、ユーザによって確認されたモバイルコンピューティングデバイス104上の時刻であってよい、又は、腕時計若しくはモバイルコンピューティングデバイス104とは別個の他の時間ソースから収集され、ユーザによって関連付け情報に入力された時間であってよい。
本明細書において議論されるようなケース時間及び関連付け情報に対する他の入力について、これらの入力は、(例えば、キーボードを介した)手動入力、(例えば、マイクロフォン及びモバイルコンピューティングデバイス104における音声認識機能を介した)音声入力、拡張現実デバイスを介して捕捉された入力、及び/又は、モバイルコンピューティングデバイス104若しくはサーバ108のいずれかと通信するウェアラブルデバイスにおいて捕捉された入力であってよい。
いくつかのシナリオにおいて、ケース終了時間は、EMSのケアからの患者の実際の解放から遅れてもよい。例えば、EMSクルーは、患者を病院に輸送し、患者を病院に送り出し、次に、患者チャートの完成に進んでよい。この遅れ時間は、EMSクルーが、患者ケア中に、患者ケアから患者チャート化のタスクに注意を移す時間がないので患者チャート化を完成させる時間がない場合に、運用上必然であり得る。こうして、モバイルコンピューティングデバイス104と医療デバイス102A~102Nとの間に、これらのデバイス間でファイルを転送するのに十分な帯域幅及び信号強度を伴う通信結合が存在する場合であっても、関連付け情報は、イベント後の或る時間まで完成されない場合があるので、ファイル関連付けは、依然としてクラウド上で発生する必要があり得る。この時間において、関係する医療デバイスは、再配置されるか又は電源オフされてよい。さらに、いくつかの場合において、プライバシー及びデータ保護の理由で、ケア提供者は、医療デバイスからモバイルコンピューティングデバイスへのファイル転送を手動で開始又は確認しなければならない。ケア提供者がこの転送を開始するのを忘れた場合、ファイル関連付けは、デバイスツーデバイス転送に基づいてではなく、依然としてクラウドにおいて発生することができる。さらに、医療デバイス、患者チャート化アプリケーション、及び/又はイベントログアプリケーションは、異なるベンダからのものであってよく、ファイルフォーマットに関して互いに互換性がなくてもよい。したがって、利用可能な通信チャネルがあっても、適切なソフトウェア開発キット(SDK)が存在しない場合、これらのデバイス間のファイル転送は、可能でない場合があり、本明細書において説明されるようにクラウドにおけるファイル関連付けを要求し得る。
ケース終了時間は、関連付け情報の完了又はユーザによって入力された時間に対応してよい。様々な実装において、関連付け情報内のケース開始時間は、ケア提供者が患者シーンに到着した時間(例えば、「患者側時間」)であってよく、ケース終了時間は、患者がEMSのケアから解放された時間(例えば、「患者ケア移行時間」)であってよい。ケア提供者が患者シーンに到着した時間は、医療デバイスを患者に対する使用のために展開及び/又はアクティベートすることができる最も早い時間であり得る。したがって、この時間は、関係するケース開始時間であってよい。同様に患者ケアがEMSから離れるように移送される時間は、医療デバイスを患者から取り外す及び/又はディアクティベートすることができる最も遅い時刻である。いくつかの実施形態において、ケース終了時間は、ユーザが医療イベントに関連付けられている医療デバイスのうちの1又は複数で現在のケースファイルをディアクティベート及び/又は閉じる時間に対応してよい。通常、病院等の輸送先に到着すると、患者は、EMSエージェンシに属する医療デバイスから、病院に属する医療デバイスへと移行される。
患者のケア中、EMSクルーは、患者を1又は複数の医療デバイスに結合してよい。医療デバイスは、ケース開始時間又はケース終了時間を、電源オン若しくは電源オフ時間として、又は、患者インタフェースデバイスが患者に結合された若しくは患者から取り外された時間として自動的に記録してよい。医療デバイスは、患者からの生理学信号の存在若しくは不存在に基づいて、又は、患者接続(例えば、患者への電極のペアの適切な取り付けに基づく閉回路)を示すセンサ信号に基づいて、又は、患者インタフェースデバイスがパッケージから取り出されている若しくは別様に展開されていることを示すセンサ信号に基づいて、この結合又は取り外しを認識してよい。一実装において、医療デバイス及びモバイルコンピューティングデバイスは、通信可能に結合してよく、1又は複数の両方のデバイスは、通信の開始に関連付けられている時間に基づいて、ケース開始時間及び/又はケース終了時間を記録してよい。一実装において、医療デバイスは、ケース開始時間又はケース終了時間のユーザ入力又は確認を要求してよい。
一実装において、医療デバイス102A~102Nは、デバイス識別子を医療デバイスケースファイルに自動的に記録してよい。例えば、このデバイス識別子は、医療デバイスケースファイルとともにメタデータとして含まれている、特定の医療デバイスに対しての一意のコード(例えば、シリアルナンバ及び/又は型番及び/又は他の識別情報)であってよい。一実装において、医療デバイス102A~102Nは、モバイルコンピューティングデバイス104と通信可能に結合し、医療デバイス識別子をモバイルコンピューティングデバイス104に送信してよい。モバイルコンピューティングデバイス104は、この識別子を関連付け情報に自動的に記録してよい。一実装において、医療デバイス102A~102Nは、医療デバイス識別子を、外側ハウジング上に、例えば付けられたタグ若しくはステッカー上に、又は、エンボス加工若しくはエングレーブ加工されたコードとして、含んでよい。ケア提供者は、このコードを視覚的に検査し、このコードをePCRアプリケーション122又はイベントログアプリケーション140において手動で入力してよい。代替的には、ケア提供者は、カメラ又は他の視覚的記録デバイスを使用してこのコードを捕捉し、捕捉されたコードを関連付け情報における記録のためにモバイルコンピューティングデバイス104に送信してよい。別のオプションとして、医療デバイス識別子は、バーコード又はQRコードであってよく、ケア提供者は、スキャナを使用してこのコードを捕捉し、捕捉されたコードを関連付け情報における記録のためにモバイルコンピューティングデバイス104に送信してよい。一実装において、モバイルコンピューティングデバイス104は、カメラ及び/又はスキャナを含んでよい。さらなるオプションとして、ケア提供者は、コードを読んで音声化してよく、モバイルコンピューティングデバイス104は、可聴情報を捕捉して、このコードを関連付け情報に自動的に記録するように構成されているマイクロフォンを含んでよい。一実装において、特定の医療デバイスは、特定のEMSクルー及び/又はEMS車両に関連付けられてよい。このような一実装において、ケア提供者は、クルー又は車両の識別を関連付け情報に提供してよく、モバイルコンピューティングデバイス104は、クルー又は車両の識別に基づいて、医療デバイス識別子を関連付け情報と関連付けるために、ルックアップテーブル又は他のリファレンスを参照してよい。
モバイルコンピューティングデバイス104及び医療デバイス102A~102N上の時間記録の様々な可能なモードを前提とすると、関連付け情報及び医療デバイスケースファイル内の時間の間の任意の相関又は合致の信頼性及び精度は、各デバイスがこれらの時間をどのように記録しているかに応じて異なる程度に変化し得る。同様に、モバイルコンピューティングデバイス104による医療デバイス識別子の捕捉及び記録の様々な可能なモードは、関連付け情報内の及び医療デバイスケースファイル内の情報間の任意の相関又は合致の信頼性及び精度を決定し得る。したがって、システムは、ファイル関連付けの検索基準として、図5B、図5C及び図5Dに例示されているように、これらの基準のうちの一方若しくは他方又は両方を使用してよい。
これらの基準の両方の使用は、除細動器、自動化圧迫デバイス、人工呼吸器等のような1若しくは少数の医療デバイスのみを所有する及び/又は(例えば、2つの同時の緊急事態又はスケジュールされた輸送のために)同時に展開されている1若しくは少数の医療デバイスのみを有する小規模EMSエージェンシにとって、必要でなくてよい。この場合、時間は、医療デバイスケースファイル及び関連付け情報を関連付けるのに十分であり得る。しかしながら、主要なメトロポリタンエリアにおけるエージェンシ等の大規模EMSエージェンシについて、エージェンシは、100~200の医療デバイスを所有する場合があり、10~20の同時展開を有し得る。この場合、時間は不十分であり得、ファイル関連付けの精度のために時間とともに医療デバイス識別子が必要とされ得る。この状況は、特に、患者の間で時間が実質的に重複し、医療デバイス識別子のタイムリーな記録に関して現場で混乱が発生し得る、多数傷病者状況に当てはまり得る。したがって、この場合、検索基準は、信頼できる正確なファイル関連付けのためのいくつかのパラメータを要求し得る。複数又は多数傷病者状況は、モバイルコンピューティングデバイス104と医療デバイス102A~102Nとの間に、これらのデバイス間でファイルを転送するのに十分な帯域幅及び信号強度を有しない通信結合が存在しない場合であっても、クラウドにおけるファイル関連付けの発生が必要とされ得る状況の別の例も提供する。例えば、WIFI又はセルラ等の長距離通信結合が利用不可能である場合(例えば、屋内空間、パーキングガレージ、アーバンキャニオン、リモートロケーション等において)、デバイスは、BLUETOOTH等の近距離接続を介してのみ通信可能であり得る。しかしながら、互いの近距離通信距離内にある複数のデバイスは、医療デバイスとモバイルコンピューティングデバイスとの間でのファイルの自動転送を可能にする検出能力に干渉し得る。
図6は、いくつかの実装における、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)によって実行される関連付けプロセス600の1つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び/又は呼び出し側プロセス(例えば、図1のePCR API128及び/又はイベントログAPI144)からの要求に応答して、プロセス600を実行するように構成することができる。
図6に示されているように、プロセス600は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(602)ことで開始する。この関連付け情報は、呼び出し側プロセスからのメッセージに含まれているか、又は、周期タイマの満了に応答して患者エンカウンタデータソース統合サービスによって処理されるチャート化データ若しくはイベントログデータとともに格納されてよい。関連付け情報を受信した(602)後、患者エンカウンタデータソース統合サービスは、関連付け情報に基づいて少なくとも1つの検索基準を生成し(604)、少なくとも1つの検索基準と合致する若しくはそれを満たす1又は複数のケースファイルについて、ケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを検索する(606)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索する(506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス600内で受信し(602)、生成し(604)、検索する(606)ことができる。
次に、患者エンカウンタデータソース統合サービスは、少なくとも1つの対応するケースファイルが検索(606)によって識別されたか否かを決定する(608)。患者エンカウンタデータソース統合サービスが、少なくとも1つの対応するケースファイルが発見されなかったと決定する(608)場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを生成して呼び出し側プロセスに戻し(612)、プロセス600が終了する。患者エンカウンタデータソース統合サービスが、少なくとも1つの対応するケースファイルが発見されたと決定する(608)場合、患者エンカウンタデータソース統合サービスは、その少なくとも1つの対応するケースファイル又はその少なくとも1つの識別子を含むメッセージを呼び出し側プロセスに戻し(610)、プロセス600が終了する。
図7は、いくつかの実装における、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)によって実行される関連付けプロセス700の1つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び/又は呼び出し側プロセス(例えば、図1のePCR API128)からの要求に応答して、プロセス700を実行するように構成することができる。
図7に示されているように、プロセス700は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(702)ことで開始する。この関連付け情報は、呼び出し側プロセスからのメッセージに含まれているか、又は、周期タイマの満了に応答して患者エンカウンタデータソース統合サービスによって処理されるチャート化データ若しくはイベントログデータとともに格納されてよい。関連付け情報を受信した(702)後、患者エンカウンタデータソース統合サービスは、関連付け情報に基づいて少なくとも1つの検索基準を生成し(704)、少なくとも1つの検索基準と合致する若しくはそれを満たす1又は複数のケースファイルについて、ケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを検索する(706)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索する(506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス700内で受信し(702)、生成し(704)、検索する(706)ことができる。
次に、患者エンカウンタデータソース統合サービスは、少なくとも1つの対応するケースファイルが検索(706)によって識別されたか否かを決定する(708)。患者エンカウンタデータソース統合サービスが、少なくとも1つの合致が発見されなかったと決定する(708)場合、患者エンカウンタデータソース統合サービスは、タイマ(例えば、上で説明したイベントトリガ周期タイマ)をリセットし(714)、対応するケースファイルが発見されなかったことを示す戻りメッセージを呼び出し側プロセスに送信する(716)。患者エンカウンタデータソース統合サービスが、少なくとも1つの対応するケースファイルが発見されたと決定する(708)場合、患者エンカウンタデータソース統合サービスは、その少なくとも1つの対応するケースファイル又はその少なくとも1つの識別子を呼び出し側プロセスに戻し(710)、処理700が終了する。
図8は、いくつかの実装において、複数の医療デバイス、患者エンカウンタデータソース統合サービス、及びモバイルコンピューティングデバイス(例えば、図1の医療デバイス102、患者エンカウンタデータソース統合サービス130、及びモバイルコンピューティングデバイス104)によって実行される集約プロセス800の1つの例を示している。図8に示されているように、破線の境界でレンダリングされた操作は、いくつかの例において存在しない場合がある。
プロセス800内で、モバイルコンピューティングデバイスは、要求メッセージを患者エンカウンタデータソース統合サービスに送信する(802)。この要求メッセージは、複数の医療デバイスケースファイルからのケースデータ(例えば、医療デバイスケースファイル又はその一部)を互いに関連付ける要求を含むことができる。要求メッセージは、少なくとも1つの検索基準を開発するために使用されることになる関連付け情報及び/又はそのような関連付け情報の識別子(例えば、図1のチャート化データストア134及び/又はイベントログデータストア146等のチャート化データストア及び/又はイベントログデータストア内の関連付け情報を包含するチャート化データ及び/又はイベントログデータの識別子)を含むことができる。いくつかの例において、モバイルコンピューティングデバイスは、サーバ(例えば、図1のサーバ108のうちのサーバ)によって実装されるePCRインタフェース及び/又はイベントログインタフェース(例えば、図1のePCR API128及び/又はイベントログAPI144)への1又は複数のメッセージを介して、要求メッセージ及び/又は関連付け情報を患者エンカウンタデータソース統合サービスに送信することができる。代替的に又は加えて、モバイルコンピューティングデバイスは、要求メッセージを送信する(802)ことの一部として、ePCRインタフェース及び/又はイベントログインタフェースを介して、チャート化データストア及び/又はイベントログデータストア内に関連付け情報を格納することができる。
プロセス800を続けると、患者エンカウンタデータソース統合サービスは、ePCRインタフェース及び/又はイベントログインタフェース又はチャート化データストア及び/又はイベントログデータストアから関連付け情報を受信する(804)。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成する(806)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成する(504)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス800内で受信し(804)、生成する(806)ことができる。
図8に示されているように、医療デバイスは、1又は複数の要求メッセージを、サーバ(例えば、図1のサーバ108のうちのサーバ)によって実装されるケースインタフェース(例えば、ケースAPI126)に送信する(808)。要求メッセージは、複数のケースファイルをケースデータストア(例えば、図1のケースデータストア132)にインポートする1又は複数の要求を含むことができる。要求メッセージは、ケースファイルがインポートされることを含むことができる。要求メッセージを受信したことに応答して、ケースインタフェースは、ケースファイルを受信し、ケースファイルからケースデータを索出するためにケースファイルをパースし、ケースデータ及び/又はケースファイルをケースデータストアに格納し、要求メッセージを処理した結果を示す1又は複数の応答メッセージを医療デバイスに送信することができる。
プロセス800を続けると、患者エンカウンタデータソース統合サービスは、インポートされたケースファイルに関連付けられているケースデータを少なくとも1つの検索基準を満たすものとして識別する(810)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で識別する(508)際に患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス800内で識別する(810)ことができる。患者エンカウンタデータソース統合サービスは、ケースファイルを識別する(810)ことの一部として、ケースファイルの1又は複数の識別子及び/又はケースファイルを記述する他のメタデータを含む確認要求をさらに生成して、モバイルコンピューティングデバイスに送信することができる。ケースファイルの1又は複数の識別子は、例えば、ケースファイルが医療デバイスによって生成されたときを示す1又は複数のタイムスタンプ、及びケースファイルを生成した医療デバイスの識別子を含むことができる。
プロセス800を引き続き参照すると、モバイルコンピューティングデバイスは、患者エンカウンタデータソース統合サービスからケースファイルの識別子及び/又は他のメタデータを含む確認要求を受信し(812)、ユーザに(例えば図1のヘルスケア提供者118A)に、ケースファイルが同じ患者エンカウンタを記述しているか否かを確認するよう促す。いくつかの例において、モバイルコンピューティングデバイスは、識別子を使用して、ePCRアプリケーション及び/又はイベントログアプリケーション(例えば、図1のePCRアプリケーション122及び/又はイベントログアプリケーション140)を介してユーザを促す。図9は、ePCRアプリケーション及び/又はイベントログアプリケーションが確認要求を受信したことに応答してレンダリングするように構成されているユーザインタフェーススクリーン900の1つの例を示している。図9に示されているように、スクリーン900は、ケースコントロールの列902及び904と、確認コントロール906の列と、提出コントロール908とを含む。ケースコントロール902及び904は、確認要求において識別されるケースファイルの識別子及びそれに関する情報を表示するように構成されている。より具体的には、ケースコントロール902のそれぞれは、ケース開始時間を表示するように構成されており、ケースコントロール904のそれぞれは、ケースファイルを生成した医療デバイスの識別子を表示するように構成されている。確認コントロール906は、確認コントロール906が存在する行によって識別されるケースファイルが、他のケースファイルに関連付けられること(例えば、同じ患者エンカウンタ中にそれぞれ生成されたこと)を確認したのか確認していないのかを示す入力を受けるように構成されている。提出コントロール908は、所望のようにユーザがケースファイルを確認したこと又は確認していないことを示す入力を受けるように構成されている。
プロセス800に戻ると、ePCRアプリケーション及び/又はイベントログアプリケーションは、ケースファイルを確認する入力(例えば、提出コントロール908の選択)を受け、ePCRアプリケーション及び/又はイベントログアプリケーションは、(例えば、ePCRインタフェース及び/又はイベントログインタフェースを介して)患者エンカウンタデータソース統合サービスに確認応答を送信する(814)。患者エンカウンタデータソース統合サービスは、確認応答を受信する(816)。
いくつかの例において、患者エンカウンタデータソース統合サービスは、関連付けられたケースファイルからのケースデータを統合データソースエンカウンタ構造体内の集約されたケースデータに集約する(818)。例えば、いくつかの例において、患者エンカウンタデータソース統合サービスは、関連付けられたケースファイルから発生したケースデータストアに格納されているケースデータの記録の全て又はその一部の間の関連付けを確立することによって、ケースデータを集約されたケースデータに集約する(818)。さらに、患者エンカウンタデータソース統合サービスは、例えば、集約されたケースデータの少なくとも一部を統合データソースエンカウンタ構造体の一部としてePCR及び/又はイベントログにインポートすることによって、集約されたケースデータ又はその一部をチャート化データ及び/又はイベントログデータと統合することができる。この集約は、補完ePCR及び/又は補完イベントログを生成する。また、患者エンカウンタデータソース統合サービスは、例えば、集約されたケースデータの少なくとも一部を1又は複数のケースファイルにインポートすることによって、集約されたケースデータ又はその一部を関連付けられたケースファイルの1又は複数のケースファイルと統合することができる。この集約は、補完ケースファイルを生成する。
プロセス800を続けると、患者エンカウンタデータソース統合サービスは、集約されたケースデータを格納する及び/又は医療デバイス及び/又はモバイルコンピューティングデバイスに送信する(819)。例えば、いくつかの例において、患者エンカウンタデータソース統合サービスは、補完ケースファイルをケースデータストアに格納する及び/又は補完ケースファイルを医療デバイスに送信する(819)。代替的に又は加えて、いくつかの例において、患者エンカウンタデータソース統合サービスは、補完ePCR及び/又は補完イベントログをチャート化データストアに格納する及び/又は補完ePCR及び/又は補完イベントログをモバイルコンピューティングデバイスに送信する(819)。
患者エンカウンタデータソース統合サービスが補完ケースファイルを医療デバイスに送信する(819)場合、医療デバイスは、補完ケースファイルを受信し(822)、補完ケースファイルを送信する及び/又はローカルに格納する(824)。患者エンカウンタデータソース統合サービスが補完ePCR及び/又は補完イベントログをモバイルコンピューティングデバイスに送信する(819)場合、モバイルデバイスは、補完ePCR及び/又は補完イベントログを受信し(826)。補完ePCR及び/又は補完イベントログを送信する及び/又はローカルに格納する(828)。
図10は、いくつかの実装における、患者エンカウンタデータソース統合サービス及びモバイルコンピューティングデバイス(例えば、図1の患者エンカウンタデータソース統合サービス130及びモバイルコンピューティングデバイス104)によって実行される集約プロセス1000の1つの例を示している。
図10に示されているように、プロセス1000は、患者エンカウンタデータソース統合サービスが、モバイルコンピューティングデバイスから関連付け情報を受信すること(1002)で開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成し(1004)、少なくとも1つの検索基準に合致する若しくはそれを満たす複数の医療デバイスケースファイルについてケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを検索し(1006)、少なくとも1つの検索基準に基づいて、医療デバイスケースファイルを互い及び特定の患者エンカウンタに関連付けられているものとして識別する(1008)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索し(506)、識別する(508)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1000内で受信し(1002)、生成し(1004)、検索し(1006)、識別する(1008)ことができる。
次に、患者エンカウンタデータソース統合サービスは、識別されたケースファイルの識別子をモバイルコンピューティングデバイスに送信する(1010)。これらの識別子は、ケースファイルが医療デバイスによって生成されたときを示すタイムスタンプを含むことができる。いくつかの例において、患者エンカウンタデータソース統合サービスは、タイムスタンプを、モバイルデバイスによってホストされているePCRアプリケーション及び/又はイベントログアプリケーション(例えば、図1のePCRアプリケーション122及び/又はイベントログアプリケーション140)に送信する(1010)。特定の例において、モバイルコンピューティングデバイスは、患者エンカウンタデータソース統合サービスからケースファイルの識別子を受信し、ユーザ(例えば、図1のヘルスケア提供者118A)に、ケースファイルが同じ患者エンカウンタを記述しているか否かを確認するよう促す。いくつかの例において、モバイルコンピューティングデバイスは、ePCRアプリケーション及び/又はイベントログアプリケーションを介してユーザを促す。ePCRアプリケーション及び/又はイベントログアプリケーションがケースファイルを確認する入力を受ける場合、ePCRアプリケーション及び/又はイベントログアプリケーションは、(例えば、図1のePCRインタフェース126及び/又はイベントログAPI144等のePCRインタフェース及び/又はイベントログインタフェースを介して)確認メッセージを患者エンカウンタデータソース統合サービスに送信する。
プロセス1000を続けると、患者エンカウンタデータソース統合サービスは、患者モバイルコンピューティングデバイスから確認メッセージを受信し(1012)、確認されたケースファイルからのケースデータを含む統合データソースエンカウンタ構造体(患者エンカウンタ中に医療デバイスからリアルタイムでストリーミングされていてよい)を格納し(1014)、プロセス1000が終了する。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で統合データソースエンカウンタ構造体を格納する(510)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1000内で統合データソースエンカウンタ構造体を格納することができる(1014)。
図11は、いくつかの実装において、患者エンカウンタデータソース統合サービス、並びに、モバイルコンピューティングデバイスによってホストされているePCRアプリケーション、イベントログアプリケーション、及び/又はデバイス関連付けアプリケーション(例えば、図1の患者エンカウンタデータソース統合サービス130、ePCRアプリケーション122、イベントログアプリケーション140、及び/又は患者エンカウンタデバイス関連付けアプリケーション150、及びモバイルコンピューティングデバイス104)によって実行される集約プロセス1100の1つの例を示している。
図11に示されているように、プロセス1100は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(1102)ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成し(1104)、少なくとも1つの検索基準に合致する若しくはそれを満たす複数の医療デバイスケースファイルについてケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを検索する(1106)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索する(506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1100内で受信し(1102)、生成し(1104)、検索する(1106)ことができる。
次に、患者エンカウンタデータソース統合サービスは、検索の結果として少なくとも1つの検索基準に合致する若しくはそれを満たす1又は複数のケースファイルの識別が得られたか否かを決定する(1108)。患者エンカウンタデータソース統合サービスが、対応するケースファイルが識別されなかったと決定する(1108)場合、プロセス1100が終了する。患者エンカウンタデータソース統合サービスが、1又は複数の対応するケースファイルが識別されたと決定する(1108)場合、患者エンカウンタデータソース統合サービスは、対応するケースファイルを記述するメタデータを生成する(1110)。このメタデータは、他の識別子の中でも、対応するケースファイルが医療デバイスによって生成されたときを示すタイムスタンプ等の対応するケースファイルの識別子、対応するケースファイルを生成した医療デバイスの識別子、及び/又は、ケースファイルの作成中に医療デバイスと結合された1又は複数のモバイルコンピューティングデバイスの識別子を含むことができる。
プロセス1100を続けると、患者エンカウンタデータソース統合サービスは、ネットワーク(例えば、図1のネットワーク112)を介して、メタデータをePCRアプリケーション、イベントログアプリケーション、及び/又はデバイス関連付けアプリケーションに送信する(1112)。いくつかの例において、患者エンカウンタデータソース統合サービスは、1又は複数のインタフェースコール(例えば、図1のePCR API128及び/又はイベントログAPI144によってサポートされるコール)によって生成されたメッセージを介して、メタデータを送信する。これらのメッセージは、確認要求を含むことができる。
ePCRアプリケーション、イベントログアプリケーション、及び/又はデバイス関連付けアプリケーションは、メタデータを受信し(1114)、メタデータに記述された各ケースファイルのためのプロンプトをレンダリングする(1116)。例えば、ePCRアプリケーション、イベントログアプリケーション、及び/又はデバイス関連付けアプリケーションは、その関連付けられたプロンプト内の各ケースファイルのためのタイムスタンプ及び/又は医療デバイス識別子をレンダリングすることができる。1又は複数のプロンプトのそれぞれは、その関連付けられたケースファイルが、関連付け情報に関連付けられているエンカウンタ中に患者(例えば、図1の患者116)に結合された医療デバイスの操作を記述していることを確認する入力を受けるように構成することができる。ケースファイルを確認する入力を受けたことに応答して、ePCRアプリケーション、イベントログアプリケーション、及び/又はデバイス関連付けアプリケーションは、(例えば、ePCRインタフェース及び/又はイベントログインタフェースを介して)確認応答を患者エンカウンタデータソース統合サービスに送信する(1118)。確認応答は、各確認されたケースファイルの識別子を含むことができる。
次に、患者エンカウンタデータソース統合サービスは、確認応答を受信(1120)し、その中に格納されているケースファイルの識別子を索出するために確認応答をパースする。患者エンカウンタデータソース統合サービスは、ケースファイルを統合データソースエンカウンタ構造体にアタッチする及び/又は埋め込む(1122)。この統合データソースエンカウンタ構造体は、ePCR及び/又はイベントログにアタッチする及び/又は埋め込むことができる。ケースファイルは、全体的に又は部分的に埋め込む及び/又はアタッチすることができる。ケースファイルが埋め込まれる場合、ケースファイル内に格納されたケースデータは、ePCRのフィールド及び/又はイベントログのフィールドに格納することができる。
プロセス1100を続けると、患者エンカウンタデータソース統合サービスは、ePCR、イベントログ、及び/又はアタッチされた/埋め込まれたケースデータを含む統合データソースエンカウンタ構造体をePCRアプリケーション、イベントログアプリケーション、及び/又はデバイス関連付けアプリケーションに送信する(1124)。ePCRアプリケーション、イベントログアプリケーション、及び/又はデバイス関連付けアプリケーションは、アタッチされた/埋め込まれたケースデータを伴うePCR、アタッチされた/埋め込まれたケースデータを伴うイベントログ、及び/又は統合データソースエンカウンタ構造体を受信し(1126)、ヘルスケア提供者によるレビュー及び操作のために、ePCR、イベントログ及び/又は統合データソースエンカウンタ構造体をレンダリングする(1128)。
図12は、いくつかの実装における、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)によって実行される関連付けプロセス1200の1つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び/又は呼び出し側プロセス(例えば、図1のePCR API128及び/又はイベントログAPI144)からの要求に応答して、プロセス1200を実行するように構成することができる。
図12に示されているように、プロセス1200は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(1202)ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成し(1204)、少なくとも1つの検索基準に合致する若しくはそれを満たす複数の医療デバイスケースファイルについてケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを検索する(1206)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索する(506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1200内で受信し(1202)、生成し(1204)、検索する(1206)ことができる。しかしながら、プロセス1200内で、患者エンカウンタデータソース統合サービスは、関連付け情報から医療デバイス識別子のリストを指定する少なくとも1つの検索基準を生成し(1204)、それらの1つは、ケースファイルが対応するケースファイルであるために、ケースファイルに関連付けられている医療デバイス識別子に等しくなければならない。患者エンカウンタデータソース統合サービスは、ケースファイルを関連付けるために、この検索基準を使用して検索する(1206)。
次に、患者エンカウンタデータソース統合サービスは、少なくとも1つの対応するケースファイルが検索(1206)によって識別されたか否かを決定する(1208)。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する(1208)場合、患者エンカウンタデータソース統合サービスは、対応するケースファイルが発見されなかったことを示すエラーメッセージを生成して呼び出し側プロセスに戻し(1210)、プロセス1200が終了する。患者エンカウンタデータソース統合サービスが、少なくとも1つの対応するケースファイルが発見されたと決定する(1208)場合、患者エンカウンタデータソース統合サービスは、その少なくとも1つの対応するケースファイル又はその少なくとも1つの識別子を生成して呼び出し側プロセスに戻し(1212)、処理1200が終了する。
図13は、いくつかの実装における、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)によって実行される関連付けプロセス1300の1つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び/又は呼び出し側プロセス(例えば、図1のePCR API128及び/又はイベントログAPI144)からの要求に応答して、プロセス1300を実行するように構成することができる。
図13に示されているように、プロセス1300は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(1302)ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成し(1304)、少なくとも1つの検索基準に合致する又はそれを満たす医療デバイスケースファイルについてケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを検索する(1306)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索する(506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1300内で受信し(1302)、生成し(1304)、検索する(1306)ことができる。しかしながら、プロセス1300内で、患者エンカウンタデータソース統合サービスは、関連付け情報から医療デバイス識別子及びタイムスタンプのペアのリストを指定する少なくとも1つの検索基準を生成し(1304)、これらの1つは、ケースファイルが対応するケースファイルであるために、ケースファイルに関連付けられている医療デバイス識別子及びタイムスタンプのペアと等しくなければならない。患者エンカウンタデータソース統合サービスは、ケースファイルを関連付けるために、この検索基準を使用して検索する(1306)。
次に、患者エンカウンタデータソース統合サービスは、1又は複数の対応するケースファイルが検索(1306)によって識別されたか否かを決定する(1308)。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する(1308)場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを生成して呼び出し側プロセスに戻し(1310)、プロセス1300が終了する。患者エンカウンタデータソース統合サービスが、少なくとも1つの対応するケースファイルが発見されたと決定する(1308)場合、患者エンカウンタデータソース統合サービスは、その少なくとも1つの対応するケースファイル又はその少なくとも1つの識別子を生成して呼び出し側プロセスに戻し(1312)、処理1300が終了する。
図14は、いくつかの実装における、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)によって実行される関連付けプロセス1400の1つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び/又は呼び出し側プロセス(例えば、図1のePCR API128及び/又はイベントログAPI144)からの要求に応答して、プロセス1400を実行するように構成することができる。
図14に示されているように、プロセス1400は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(1402)ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成し(1404)、少なくとも1つの検索基準に合致する又はそれを満たす医療デバイスケースファイルについてケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを検索する(1406)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索する(506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1400内で受信し(1402)、生成し(1404)、検索する(1406)ことができる。しかしながら、プロセス1400内で、患者エンカウンタデータソース統合サービスは、関連付け情報から医療デバイス識別子及びタイムスタンプのペアのリストを指定する少なくとも1つの検索基準を生成する(1404)。少なくとも1つの検索基準において、予め定められた関係は、対応するケースファイルが、リストからの医療デバイス識別子に等しい医療デバイス識別子に関連付けられることと、対応するケースファイルが、リストからの医療デバイス識別子とペアにされたタイムスタンプの予め定められた範囲内にあるタイムスタンプを有することとを要求する。患者エンカウンタデータソース統合サービスは、ケースファイルを関連付けるために、この検索基準を使用して検索する(1406)。
次に、患者エンカウンタデータソース統合サービスは、1又は複数の対応するケースファイルが検索(1406)によって識別されたか否かを決定する(1408)。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する(1408)場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを生成して呼び出し側プロセスに戻し(1410)、プロセス1400が終了する。患者エンカウンタデータソース統合サービスが、少なくとも1つの対応するケースファイルが発見されたと決定する(1408)場合、患者エンカウンタデータソース統合サービスは、その少なくとも1つの対応するケースファイル又はその少なくとも1つの識別子を生成して呼び出し側プロセスに戻し(1412)、処理1400が終了する。
図15は、いくつかの実装における、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)によって実行される関連付けプロセス1500の1つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び/又は呼び出し側プロセス(例えば、図1のePCR API128及び/又はイベントログAPI144)からの要求に応答して、プロセス1500を実行するように構成することができる。図15に示されているように、破線の境界でレンダリングされた操作は、いくつかの例において存在しない場合がある。
図15に示されているように、プロセス1500は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(1502)ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成し(1504)、少なくとも1つの検索基準に合致する又はそれを満たす医療デバイスケースファイルについてケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータをフィルタリングする(1506)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で受信し(502)、生成し(504)、検索する(506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1500内で受信し(1502)、生成し(1504)、フィルタリングする(1506)ことができる。しかしながら、プロセス1500内で、患者エンカウンタデータソース統合サービスは、初期検索基準を使用してケースデータストアを(例えば、クエリを介して)フィルタリングすることによって、ケースファイルについてケースデータを検索し(1506)し、そうすることで、複数の候補ケースファイルを識別する。いくつかの例において、フィルタによって用いられる初期検索基準は、関連付け情報の要素(例えば、タイムスタンプ)がケースファイルに関連付けられているパラメータの範囲内に入らなければならないことを指定する。
次に、患者エンカウンタデータソース統合サービスは、少なくとも1つの補完検索基準を生成する(1508)。いくつかの例において、少なくとも1つの補完検索基準は、関連付け情報の少なくとも1つの補完要素と候補ケースファイルに関連付けられている少なくとも1つの補完パラメータとの間の少なくとも1つの補完的な予め定められた関係を指定する。例えば、少なくとも1つの補完的な関係がハードコーディングされている場合、患者エンカウンタデータソース統合サービスは、関連付け情報からの少なくとも1つの補完要素を識別するとともに、少なくとも1つの補完要素を少なくとも1つの補完的な関係と関連付けることによって、少なくとも1つの補完検索基準を生成する(1508)。代替的に又は加えて、少なくとも1つの補完的な関係がソフトコーディングされている場合、患者エンカウンタデータソース統合サービスは、まず、基準データストア(例えば、図1の基準データストア136)内でランク付けすることで次に好ましい予め定められた関係を識別するとともに、次に、次に好ましい予め定められた関係において指定されたものとして関連付け情報の少なくとも1つの補完要素を識別し、その少なくとも1つの補完要素を少なくとも1つの補完的な関係と関連付けることによって、少なくとも1つの補完検索基準を生成する(1508)。少なくとも1つの例において、少なくとも1つの補完要素は、ジオタグを含み、予め定められた関係は、対応するケースファイルが、関連付け情報からのジオタグの予め定められた範囲内にあるジオタグに関連付けられることを指定する。
プロセス1500を続けると、患者エンカウンタデータソース統合サービスは、少なくとも1つの補完検索基準に合致する又はそれを満たす医療デバイスケースファイルについて候補ケースデータを検索する(1510)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図5を参照しながら上で説明したプロセス500内で検索する(506)際に患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1500内で検索する(1510)ことができる。しかしながら、プロセス1500内で、患者エンカウンタデータソース統合サービスは、その検索1510を候補ケースファイルからのケースデータに制限することができる。例えば、患者エンカウンタデータソース統合サービスは、ケースデータに格納されている、候補ケースファイルに関連付けられている補完パラメータが、少なくとも1つの補完検索基準に格納されている関連付け情報の補完要素と補完的な関係を満たす場合、その候補ケースファイルを対応するケースファイルとして識別することができる。
次に、患者エンカウンタデータソース統合サービスは、少なくとも1つの対応するケースファイルが発見されたか否かを決定する(1512)。患者エンカウンタデータソース統合サービスが、少なくとも1つの対応するケースファイルが発見されたと決定する(1512)場合、患者エンカウンタデータソース統合サービスは、その対応するケースファイル又はその識別子を生成して呼び出し側プロセスに戻し(1514)、プロセス1500が終了する。患者エンカウンタデータソース統合サービスが、対応するケースファイルが発見されなかったと決定する(1512)場合、患者エンカウンタデータソース統合サービスは、カウンタを反復し、カウンタがプロセス1500の単一のインスタンスにおいて許容される検索反復の数に対する構成可能な制約に違反したか否かを決定する(1516)。患者エンカウンタデータソース統合サービスが、カウンタが制約に違反していないと決定する(1516)場合、患者エンカウンタデータソース統合サービスは、別の補完検索基準を生成し(1508)、プロセス1500が続く。患者エンカウンタデータソース統合サービスが、カウンタが制約に違反したと決定する(1516)場合、患者エンカウンタデータソース統合サービスは、エラーメッセージを呼び出し側プロセスに戻し(1518)、プロセス1500が終了する。
図16は、いくつかの実装における、患者エンカウンタデータソース統合サービス(例えば、図1の患者エンカウンタデータソース統合サービス130)によって実行される関連付けプロセス1600の1つの例を示している。患者エンカウンタデータソース統合サービスは、周期タイマの満了等のイベント及び/又は呼び出し側プロセス(例えば、図1のePCRインタフェース168及び/又はイベントログAPI144)からの要求に応答して、プロセス1600を実行するように構成することができる。図16に示されているように、破線の境界でレンダリングされた操作は、いくつかの例において存在しない場合がある。
図16に示されているように、プロセス1600は、患者エンカウンタデータソース統合サービスが関連付け情報を受信する(1602)ことで開始する。このアクションに続いて、患者エンカウンタデータソース統合サービスが、関連付け情報に基づいて少なくとも1つの検索基準を生成し(1604)、複数の候補ケースファイルを識別するために少なくとも1つの検索基準を使用して、ケースデータストア(例えば、図1のケースデータストア132)に格納されているケースデータを(例えば、クエリを介して)フィルタリングする(1606)。いくつかの例において、患者エンカウンタデータソース統合サービスは、図15を参照しながら上で説明したプロセス1500内で受信し(1502)、生成し(1504)、フィルタリングする(1506)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1600内で受信し(1602)、生成し(1604)、フィルタリングする(1606)ことができる。しかしながら、プロセス1600内で、フィルタによって用いられる初期検索基準は、関連付け情報の要素と、非医療的な、医療デバイスケースファイルに関連付けられているパラメータとの間の等価性を指定する初期の予め定められた関係を含む。これらの非医療要素及びパラメータは、ケース開始時間、医療デバイス識別子、及び/又は患者識別子を含むことができる。
次に、患者エンカウンタデータソース統合サービスは、少なくとも1つの補完検索基準を生成する(1608)。この例において、少なくとも1つの補完検索基準は、関連付け情報内の少なくとも1つの医療要素が、ケースファイル内の少なくとも1つの医療パラメータと医学的に一貫し且つこれを示すことを指定する。これらの例において、少なくとも1つの医療要素は、患者の訴え、医師の所見、投薬、バイタルサイン、生理学測定値、患者に与えられた処置、胸痛の兆候、ST上昇を伴うECG、及び/又はSTEMI診断を含むことができる。さらに、これらの例において、少なくとも1つの医療パラメータは、生理学測定値のタイプ、生理学測定値の値、医療処置(例えば、除細動ショック)、及びアラームを含むことができる。
プロセス1600を続けると、患者エンカウンタデータソース統合サービスは、候補ケースデータを検索し(1610)、少なくとも1つの対応するケースファイルが発見されたか否かを決定し(1612)、対応するケースファイルが発見された場合、その対応するケースファイル又はその識別子を呼び出し側プロセスに戻す(1614)。対応するケースファイルが発見されなかった場合、患者エンカウンタデータソース統合サービスは、検索限界を超えたか否かを決定し(1616)、検索限界を超えた場合、対応するケースファイルが無いことを示すエラーメッセージを呼び出し側プロセスに戻し(1618)、検索限界を超えていない場合、少なくとも1つの補完検索基準を生成する(1608)ように戻す。いくつかの例において、患者エンカウンタデータソース統合サービスは、図15を参照しながら上で説明されたプロセス1500内で検索し(1510)、決定し(1512)、戻し(1514)、決定し(1516)、戻す(1518)ために患者エンカウンタデータソース統合サービスによって実行されるもの等のアクションを実行することによって、プロセス1600内で検索し(1610)、決定し(1612)、戻し(1614)、決定し(1616)、戻す(1618)ことができる。
上で説明したように、プロセス1600は、関連付け情報内の少なくとも1つの医療要素が、ケースファイル内の少なくとも1つの医療パラメータと医学的に一貫し且つそれを示すことを指定する少なくとも1つの補完検索基準を生成する(1608)。この例において、少なくとも1つの予め定められた関係は、関連付け情報がケースデータ「と医学的に一貫し且つそれを示す」ことを指定する。この予め定められた関係は、複雑であり、一般に利用可能な比較操作を使用して評価するのが困難である。したがって、この例において、患者エンカウンタデータソース統合サービスは、関連付け情報とケースデータとを比較する1又は複数の特殊ヒューリスティックプロセス、統計プロセス、及び/又は機械学習プロセスを実行することによって、検索する(1610)間に予め定められた関係を評価する。表1は、いくつかの例による、関連付け情報と、「それと医学的に一貫し且つそれを示す」という予め定められた関係を満たすケースデータとを提供する。
表1
より具体的には、表1に示されているように、列A及びBは、列C及びDにリストされている一次医療デバイスケースデータ及び二次医療デバイスケースデータと医学的に一貫し且つそれを示す関連付け情報の一次要素及び二次要素をリストしている。いくつかの例において、患者エンカウンタデータソース統合サービスは、検索(1610)の間に発見された任意の対応するケースデータが、関連付け情報の一次要素及び二次要素と医学的に一貫し且つそれを示さなければならないことを指定する補完検索基準を生成することができる(1608)。代替的に、いくつかの例において、患者エンカウンタデータソース統合サービスは、検索(1610)の間に発見された任意の対応するケースデータが、関連付け情報の一次要素と医学的に一貫し且つそれを示さなければならないことを指定する第1の補完検索基準を生成することができる(1608)。検索(1610)中に第1の補完検索基準に対応するケースデータが発見されなかった場合、患者エンカウンタデータソース統合サービスは、検索中に発見された任意の対応するケースデータが、関連付け情報の二次要素と医学的に一貫し且つそれを示さなければならないと指定する第2の補完検索基準を生成することができる(1608)。
いくつかの例において、システム100は、様々な医療デバイスケースファイル共有プロセスを実行するように構成されている。図17は、例えば、モバイルコンピューティングデバイス(例えば、図1のモバイルコンピューティングデバイス104A)と、コンピューティングデバイス(例えば、図1のモバイルコンピューティングデバイス104B)と、患者エンカウンタデータソース統合サービスとを伴う共有プロセス1700を示している。
共有プロセス1700は、モバイルコンピューティングデバイスが、ヘルスケア提供者(例えば、図1のヘルスケア提供者118A)を認可されたユーザとして認証する(1702)ことで開始する。モバイルコンピューティングデバイスは、モバイルコンピューティングデバイスが患者エンカウンタからの集約されたケースデータをコンピューティングデバイスと共有することを要求するユーザからの入力を受ける(1704)。例えば、イベントログアプリケーション及び/又はePCRアプリケーション(例えば、図1のイベントログアプリケーション140及び/又はePCRアプリケーション122)が入力を受けることができる。入力を受けたことに応答して、モバイルコンピューティングデバイスは、患者エンカウンタを識別するトークンをコンピューティングデバイスに送信する(1724)。例えば、モバイルコンピューティングデバイスは、ユーザインタフェースを介してトークンの視覚表現を表示してよく、及び/又は、NFCを介してトークンを表現するデータを送信してよい。
共有プロセス1700を続けると、コンピューティングデバイスは、(例えば、カメラで視覚イメージをスキャンすることによって)トークンを受信し(1706)、トークンによって識別された患者エンカウンタについての集約されたケースデータの要求を患者エンカウンタデータソース統合サービスに送信する(1708)。例えば、エンカウンタレビューアプリケーション(例えば、図1のエンカウンタレビューアプリケーション148)が要求を送信することができる。
共有プロセス1700の別の部分として、患者エンカウンタデータソース統合サービスは、以前に実行された集約プロセス(例えば、図4の集約プロセス400)の一部として、トークンによって識別される患者エンカウンタについての集約されたケースデータを、トークンと関連付けて格納する(1710)。患者エンカウンタデータソース統合サービスは、コンピューティングデバイスから集約されたケースデータの要求を受信する(1712)。患者エンカウンタデータソース統合サービスは、トークンを使用して、集約されたケースデータを識別し(1714)、集約されたケースデータを索出し(1716)、集約されたケースデータをコンピューティングデバイスに送信する(1718)。
共有プロセス1700を続けると、コンピューティングデバイスは、集約されたケースデータを受信し(1720)、集約されたケースデータの受信に応答して自動的に集約されたケースデータをレンダリングする。例えば、エンカウンタレビューアプリケーションは、集約されたデータを含むイベントログをレンダリングすることができる。
図18を参照すると、コンピューティングデバイス及び医療デバイスのコンポーネントの例のブロック図が概略的に示されている。
医療デバイス102は、プロセッサ220と、メモリ221と、1又は複数の出力デバイス230と、1又は複数のユーザ入力デバイス244と、通信インタフェース245とを含むことができる。通信インタフェース245は、様々なトランスミッタ及び/又はレシーバのうちの任意のものを含むことができる。例えば、いくつかの例において、通信インタフェース245は、NFCタグ、RFIDタグ、バーコード、及びQRコードのうちの1又は複数を含む。
様々な実装において、医療デバイス102は、除細動器、患者モニタ、除細動器/モニタ、自動化圧迫デバイス、治療冷却デバイス、体外式膜型人工肺(ECMO)デバイス、換気デバイス、それらの組み合わせ、又は、患者に治療を提供するように1又は複数の治療送達コンポーネントに結合するように構成されている別のタイプの医療デバイスとすることができる。一実装において、医療デバイス102は、単一のハウジング280内の統合治療送達/モニタリングデバイスとすることができる。単一のハウジング280は、患者インタフェースデバイス信号プロセッサ256及び/又は治療送達制御モジュール255を少なくとも部分的に囲むことができる。
患者インタフェースデバイス190は、1又は複数の治療送達コンポーネント261a及び/又は1又は複数のセンサデバイス261bを含むことができる。医療デバイス102は、1又は複数の治療送達コンポーネント261aに結合するように構成することができる。医療デバイス102と1又は複数の治療送達コンポーネントとは、組み合わせで、患者(例えば、図1の患者116)に治療処置を提供することができる。一実装において、医療デバイス102は、治療送達コンポーネント261aを含む又は組み込むことができる。治療送達コンポーネント261aは、患者に治療を送達するように構成されており、患者に結合するように構成することができる。例えば、治療送達コンポーネント261aは、除細動電極及び/又はペーシング電極を含む電気治療電極、胸骨圧迫デバイス(例えば、1又は複数のベルト又はピストン)、換気デバイス(例えば、マスク及び/又はチューブ)、薬剤送達デバイス等のうちの1又は複数を含むことができる。医療デバイス102は、患者に医学的治療を提供すべく、1又は複数の治療送達コンポーネント261aを含むことができる及び/又は1又は複数の治療送達コンポーネント261aに結合するように構成することができる。治療送達コンポーネント261aは、患者に結合するように構成することができる。例えば、ヘルスケア提供者(例えば、ヘルスケア提供者118)は、患者に電極を取り付けてよく、医療デバイス102(例えば、除細動器又は除細動器/患者モニタ)は、除細動電極を介して患者に電気治療を提供してよい。これらの例は本開示を限定するものではなく、他のタイプの医療デバイス、治療送達コンポーネント、センサ、及び治療が本開示の範囲内にある。
医療デバイス102は、例えば、医学的治療を送達可能な治療医療デバイスとすることができる。例えば、医学的治療は、電気治療(例えば、除細動、心臓ペーシング、同期カルディオバージョン、横隔膜又は横隔神経刺激)とすることができ、医療デバイス102は、除細動器、除細動器/モニタ、及び/又は、電気治療を提供するように構成されている別の医療デバイスとすることができる。別の例として、医学的治療は、心停止の処置のための胸骨圧迫治療とすることができ、第1の医療デバイス102は、ベルト式胸骨圧迫デバイス又はピストン式胸骨圧迫デバイス等の機械的胸骨圧迫デバイスとすることができる。他の例として、医学的治療は、換気治療、治療冷却又は他の体温管理、観血式血行力学的支援治療(例えば、体外式膜型人工肺(ECMO))等とすることができ、医療デバイス102は、それぞれの治療を提供するように構成されているデバイスとすることができる。一実装において、医療デバイス102は、これらの例のうちの1又は複数の組み合わせとすることができる。治療医療デバイスは、1又は複数のセンサを介した患者モニタリング能力を含むことができる。これらのタイプの医学的治療及びデバイスは、単に例であり、本開示を限定するものではない。
医療デバイス102は、患者に結合するように構成することができる1又は複数のセンサ261bを含む、組み込む、及び/又はそれに結合するように構成することができる。センサ261bは、センサデータを示す信号を医療デバイス102に提供するように構成されている。センサ261bは、患者に結合するように構成することができる。例えば、センサ261bは、心臓検知電極、胸骨圧迫センサ、及び/又は換気センサを含むことができる。1又は複数のセンサ261bは、患者の生理学パラメータを示す信号を生成することができる。例えば、生理学パラメータは、少なくとも1つのバイタルサイン、ECG、血圧、心拍数、パルス酸素レベル、呼吸数、心音、肺音、呼吸音、呼気CO2、筋肉酸素飽和度(SMO2)、動脈血酸素飽和度(SpO2)、脳血流、脳波図(EEG)信号、脳酸素レベル、組織pH、組織流体レベル、超音波イメージを介して特定された物理的パラメータ、近赤外線反射スペクトロスコピー、ニューモグラフィ及び/又はカルジオグラフィを介して特定されたパラメータ等のうちの1又は複数を含むことができる。加えて又は代替的に、1又は複数のセンサ261bは、胸骨圧迫パラメータ、換気パラメータ、薬剤送達パラメータ、流体送達パラメータ等を示す信号を生成することができる。
患者への治療の送達に加えて、治療送達コンポーネント261aは、センサを含み、センサに結合され、及び/又はセンサとして機能し、センサデータ(例えば、第2のセンサデータ)を示す信号を医療デバイス102に提供することができる。例えば、除細動電極は、心臓検知電極及び電気治療送達デバイスして構成することができ、経胸壁インピーダンス、心電図(ECG)、心拍数及び/又は他の生理学パラメータを示す信号を提供することができる。別の例として、治療冷却デバイスは、静脈内冷却デバイスとすることができる。このような冷却デバイスは、冷却治療を送達し、患者の体温を検知するように構成されている治療送達コンポーネントとしての静脈内(IV)デバイスを含むことができる。例えば、IVデバイスは、温度制御された生理食塩水の循環を介して患者の体温を調整するように構成されている生理食塩水バルーンを備えるカテーテルすることができる。さらに、カテーテルは、患者の体温を検知するように構成されている温度プローブを含むことができる。さらなる例として、IVデバイスは、薬剤送達及び/又は流体管理を介して治療を提供することができる。また、IVデバイスは、血液サンプリング及び/又は静脈圧モニタリング(例えば、中心静脈圧(CVP)モニタリング)を介して患者をモニタリングする及び/又はそのモニタリングを可能にすることができる。
医療デバイス102は、(例えば、治療送達コンポーネント261a及び/又はセンサ261bから)センサ信号を受信するように、また、患者データを決定して収集するために、センサ信号を処理するように構成することができる。患者データは、患者のステータス及び/又は状態を特徴付けることができる患者データ(例えば、ECG、心拍数、呼吸数、温度、パルスオキシメトリ、非観血ヘモグロビンパラメータ、カプノグラフィ、酸素飽和度(SpO2)、呼気終末二酸化炭素(EtCO2)、観血血圧(IBP)、非観血血圧(NIBP)、組織pH、組織酸素化、近赤外線分光法(NIRS)測定値等のような生理学データ)を含むことができる。加えて又は代替的に、患者データは、治療の送達を特徴付けることができ(例えば、圧迫深さ、圧迫回数等のような胸骨圧迫データ)、及び/又は、患者データは、患者を処置するために使用された医療機器のステータス及び/又は状態を特徴付けることができる(例えば、ショック時間、ショック持続時間、電極の取り付け、電源オン等のようなデバイスデータ)。
医療デバイス102の220、221、230、244、245、及び255のコンポーネントは、双方向通信のために互いに(直接及び/又は間接的に)通信可能に結合されている。
図18では別個のエンティティとして示されているが、医療デバイス102のコンポーネントのうちの1又は複数は、組み合わせて1又は複数の別個のコンポーネントにすることができ、及び/又は、プロセッサ220の一部とすることができる。プロセッサ220及びメモリ221は、本明細書において説明した機能を実行するために関連付けられる回路を含む及び/又はそれに結合することができる。
一実装において、医療デバイス102は、医学的治療を患者に送達するように構成されている治療医療デバイスとすることができる。こうして、医療デバイス102は、治療送達制御モジュール255を任意に含むことができる。例えば、治療送達制御モジュール255は、ペーシングパルス又は除細動パルスのための電気エネルギーを貯蔵するように構成されている1又は複数のキャパシタを含む電気治療送達回路とすることができる。電気治療送達回路は、抵抗器、追加のキャパシタ、リレー及び/又はスイッチ、Hブリッジ(例えば、複数の絶縁ゲートバイポーラトランジスタ又はIGBTを含む)等の電気的ブリッジ、電圧測定コンポーネント、及び/又は電流測定コンポーネントをさらに含むことができる。別の例として、治療送達制御モジュール255は、機械的圧迫デバイスを制御するように構成されている圧迫デバイス電気機械コントローラとすることができる。さらなる例として、治療送達制御モジュール255は、薬剤送達、体温管理、換気、及び/又は他のタイプの治療送達を制御するように構成されている電気機械コントローラとすることができる。代替的には、医療デバイス102のいくつかの例は、患者116に医学的治療を送達するように構成されていなくてもよいが、患者モニタリング及び/又は診断ケアを提供するように構成することができる。図18に示されているように、いくつかの例において、治療送達制御モジュール255は、通信リンク1180を介して、モバイルコンピューティングデバイス104(例えば、患者モバイルコンピューティングデバイス)とメッセージを交換する。これらのメッセージは、患者に提供された治療を記述する患者データ又は医療デバイス102上に格納されている他の患者データを含むことができる。この患者データは、派遣されたEMSイベントをドキュメント化したePCRを生成する際にePCRアプリケーションによって使用することができる。1つの実施形態において、通信リンク1180は、BLUETOOTH及び/又は近距離通信技術を使用して実施される。
特定の実装において、本明細書において患者エンカウンタデータソース統合サービス130に関連付けられているものとして説明したファイル合致及びマージ機能は、代替的には、医療デバイス102及び/又はモバイルコンピューティングデバイス104において呼び出される。そのような実装においては、この機能をサポートするために、医療デバイス102とモバイルコンピューティングデバイス104との間の通信リンク1180を使用することができ、したがって、サーバ108への接続が利用不可能であるときでも、医療デバイスケースファイルが関連するチャート化データと統合されることが可能である。通信リンク1180が制限されているアプリケーションにおいて、例えば、制限された帯域幅又は制限された持続時間に起因して、ファイル合致及びマージ機能は、任意に、デバイス識別子を比較する検索基準等の1又は複数の指定された検索基準に制限される。このことは、患者処置及びEMSインタラクションのために制限されたリソースを確保するために、通信リンク1180によって提供される帯域幅を絞ることが望まれるアプリケーションにおいて、特に有用であり得る。
通信リンク1180を介して共有される情報は、セキュリティを高めるために及び/又はPHIを保護するために任意に制限される。これは、例えば、医療デバイス102及びモバイルコンピューティングデバイス104を、通信リンク1180を使用して公開情報(例えば、デバイス識別子)のみを通信するように構成することによって実現することができる。PHIが医療デバイス102とモバイルコンピューティングデバイス104との間で共有されることになる実装において、通信は、より強力な認証を実施することができる信頼できるクラウドサービスを介してルーティングすることができる。特定の実施形態において、サーバ108は、そのような信頼できるクラウドサービスを提供する。サーバ108を介して通信をルーティングすることは、医療デバイス102及びモバイルコンピューティングデバイス104が異なるフォーマットでデータを生成する場合、及び/又は、通信デバイスのうちの1又は複数がローカルネットワークにおいて通信するように構成されてない場合等、他の理由でも好ましい場合がある。
医療デバイス102は、1又は複数の患者インタフェースデバイス190を組み込む及び/又はそれに結合するように構成することができる。患者インタフェースデバイス190は、1又は複数の治療送達コンポーネント261a及び1又は複数のセンサ261bを含むことができる。1又は複数の治療送達コンポーネント261a及び1又は複数のセンサ261bは、有線及び/又は無線接続を介して、1又は複数の信号を医療デバイス102に提供することができる。
1又は複数の治療送達コンポーネント261aは、電気治療電極(例えば、電気治療電極266a)、換気デバイス(例えば、換気デバイス266b)、静脈内デバイス(例えば、静脈内デバイス266c)、圧迫デバイス(例えば、圧迫デバイス266d)等を含むことができる。例えば、電気治療電極は、除細動電極、ペーシング電極、及び/又はそれらの組み合わせを含むことができる。換気デバイスは、チューブ、マスク、腹部及び/又は胸骨圧迫器(例えば、ベルト、胸甲呼吸器等)等、並びにそれらの組み合わせを含むことができる。静脈内デバイスは、薬剤送達デバイス、流体送達デバイス、及びそれらの組み合わせを含むことができる。圧迫デバイスは、腹部圧迫器、胸骨圧迫器、ベルト、ピストン、及びそれらの組み合わせ等の機械的圧迫デバイスを含むことができる。様々な実装において、治療送達コンポーネント261aは、センサデータを提供する及び/又はセンサに結合される及び/又はセンサを組み込むように構成することができる。例えば、電気治療電極は、経胸壁インピーダンス、ECG、心拍数等のようなセンサデータを提供することができる。さらに、電気治療電極は、胸骨圧迫センサを含む及び/又はそれに結合することができる。別の例として、換気デバイスは、フローセンサ、ガス種センサ(例えば、酸素センサ、二酸化炭素センサ等)等に結合する及び/又はそれらを組み込むことができる。さらなる例として、静脈内デバイスは、温度センサ、フローセンサ、血圧センサ等に結合する及び/又はそれらを組み込むことができる。また別の例として、圧迫デバイスは、胸骨圧迫センサ、患者位置センサ等に結合する及び/又はそれらを組み込むことができる。治療送達制御モジュール255は、治療送達コンポーネント261aに結合し、これを制御するように構成することができる。
様々な実装において、センサ261bは、例えば、心電図(ECG)、血圧、心拍数、パルス酸素レベル、呼吸数、心音、肺音、呼吸音、呼気CO2、筋肉酸素飽和度(SMO2)、動脈血酸素飽和度(SpO2)、脳血流、脳波図(EEG)信号、脳酸素レベル、組織pH、組織流体レベル、超音波、ラリンゴスコピー、及び/又は他の医療撮像技法、近赤外線反射スペクトロスコピー、ニューモグラフィ、カルジオグラフィを介したイメージ及び/又はビデオ、及び/又は患者の動きを含むがこれらに限定されないセンサデータを提供するように構成されている1又は複数のセンサデバイスを含むことができる。イメージ及び/又はビデオは、二次元又は3次元とすることができる。
センサ261bは、検知電極(例えば、検知電極262)、換気センサ(例えば、換気センサ264)、温度センサ(例えば、温度センサ267)、胸骨圧迫センサ(例えば、胸骨圧迫センサ268)等を含むことができる。例えば、検知電極は、心臓検知電極を含むことができる。心臓検知電極は、例えば患者のECG情報を測定するために、患者の電気生理学における変化を測定するように構成されている導電及び/又は容量結合電極とすることができる。一実装において、検知電極は、患者の経胸壁インピーダンス及び/又は心拍数を測定するように構成することができる。換気センサは、肺活量測定センサ、フローセンサ、圧力センサ、例えば、パルスオキシメトリセンサ、酸素化センサ(例えば、筋肉酸素化/pH)、O2ガスセンサ、及びカプノグラフィセンサのうちの1又は複数等の酸素及び/又は二酸化炭素センサ、並びにそれらの組み合わせを含むことができる。温度センサは、赤外線温度計、接触温度計、リモート温度計、液晶温度計、サーモカップル、サーミスタ等を含むことができ、患者の体温を内部及び/又は外部から測定することができる。胸骨圧迫センサは、例えば、1又は複数の加速度計、1又は複数の力センサ、1又は複数の磁気センサ、1又は複数の速度センサ、1又は複数の変位センサ等を含む1又は複数のモーションセンサを含むことができる。胸骨圧迫センサは、例えば、圧迫パック、スマートフォン、ハンドヘルドデバイス、ウェアラブルデバイス等とすることができるが、これに限定されない。胸骨圧迫センサは、救助者及び/又は自動化胸骨圧迫デバイス(例えば、ベルトシステムピストンシステム等)によって伝えられる胸部の動きを検出するように構成することができる。胸骨圧迫センサは、変位データを含む胸骨圧迫データ、速度データ、解放速度データ、加速度データ、圧迫回数データ、滞留時間データ、ホールド時間データ、血流データ、血圧データ等を示す信号を提供することができる。一実装において、検知電極及び/又は電気治療電極は、胸骨圧迫センサを含む又はそれに結合するように構成することができる。
図18を引き続き参照すると、モバイルコンピューティングデバイス104のコンポーネントの例が概略的に示されている。一実装において、モバイルコンピューティングデバイス104は、モバイルコンピューティングデバイスとして構成することができる。
モバイルコンピューティングデバイス104は、プロセッサ420と、メモリ421と、1又は複数の出力デバイス430と、1又は複数のユーザ入力デバイス444と、通信インタフェース445とを含むことができる。図18は、リモートコンピューティングデバイス106のコンポーネントの例も概略的に示している。図18に示されているように、リモートコンピューティングデバイス106は、プロセッサ320と、メモリ321と、1又は複数の出力デバイス330と、1又は複数のユーザ入力デバイス344と、通信インタフェース345とを含むことができる。図18は、さらに、サーバ108のコンポーネントの例を概略的に示している。図18に示されているように、サーバ108は、プロセッサ520と、メモリ521と、1又は複数の出力デバイス530と、1又は複数のユーザ入力デバイス544と、通信インタフェース545とを含むことができる。
モバイルコンピューティングデバイス104(例えば、モバイルコンピューティングデバイス)及びリモートコンピューティングデバイス106のそれぞれは、デスクトップ、ノートブック、モバイル、ポータブル、又は他のタイプのコンピューティングシステム等のコンピュータシステムとすることができる。これらのデバイス104及び106のそれぞれは、サーバを含む、及び/又は、モニタ及び/又は他の接続されたユーザインタフェースデバイスを介して、サーバにアクセスすることができる。サーバとして説明したが、サーバ108は、例えば、デスクトップ、ノートブック、モバイル、ポータブル、又は他のタイプのコンピューティングシステムを含む別のタイプのコンピューティングシステムとすることができる。
図18に示されているように、デバイス104及び106のそれぞれは、サーバ108及び医療デバイス102とともに、その中に含まれているプロセッサ、メモリ、出力デバイス、入力デバイス、及び通信インタフェースを通信可能に結合するバス又は他の相互接続機構を含む。バスは、例えば、使用されるストレージデバイスに応じて、PCI/PCI-X又はSCSIベースのシステムバスを含むことができる。
プロセッサ220、320、420及び520は、限定されないが、Intel(登録商標)Itanium(登録商標)若しくはItanium 2(登録商標)プロセッサ、又は、AMD(登録商標)Opteron(登録商標)若しくはAthlon MP(登録商標)プロセッサ、又は、Motorola (登録商標)ラインのプロセッサ等のプロセッサをそれぞれ含むことができる。通信インタフェース245、345、445及び545は、それぞれ、例えば、モデムベースのダイヤルアップ接続とともに使用されるRS-232ポート、10/100イーサネットポート、又は銅若しくはファイバを使用したギガビットポートのうちの任意のものとすることができる。通信インタフェース245、345、445及び545は、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、又は、医療デバイス102、モバイルコンピューティングデバイス104、リモートコンピューティングデバイス106、及び/又はサーバ108が接続し得る任意のネットワーク等のネットワークに応じて選択されてよい。メモリ221、321、421及び521は、ランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、フラッシュメモリ、及び/又は別のダイナミック揮発性及び/又は不揮発性ストレージデバイスとすることができる。メモリ221、321、421及び521は、情報及び命令を記憶するために使用することができる。例えば、Adaptec(登録商標)ファミリのSCSIドライブ等のハードディスク、光ディスク、RAID等のディスクのアレイ(例えば、AdaptecファミリーのRAIDドライブ)、又は任意の他の大容量ストレージデバイスが使用されてよい。上で説明したコンポーネントは、可能性のいくつかのタイプを例示することが意図されている。前述の例は、決して本開示の範囲を限定すべきでない。メモリ221、321、421及び521は、例えば、外部ハードドライブ、フロッピドライブ、フラッシュドライブ、IOMEGA(登録商標)Zipドライブ、コンパクトディスク-リードオンリメモリ(CD-ROM)、コンパクトディスク-リライタブル(CD-RW)、又はデジタルビデオディスク-リードオンリメモリ(DVD-ROM)等のリムーバブルストレージ媒体をさらに含むことができる。
図18を引き続き参照すると、サーバ108は、例えば、1又は複数のストレージサーバ及び1又は複数のアプリケーションサーバを含むことができる。いくつかの例において、サーバ108は、リモートコンピューティングデバイス106とメッセージ1170を交換するように構成されている。これらのメッセージは、上で説明したようなチャート及び/又はケースデータを含むことができる。いくつかの例において、サーバ108は、ePCR API128を介してモバイルコンピューティングデバイス104とメッセージ1160を交換するように構成されている。これらのメッセージは、モバイルコンピューティングデバイス104によって生成されたePCRを記述するデータを含むことができる。いくつかの例において、サーバ108は、医療デバイス102とメッセージ1190を交換するように構成されている。これらのメッセージは、医療デバイスを介して処置されている患者(例えば、図1の患者116)及び/又は医療デバイス102によって送達されている処置を記述するデータを含むことができる。
本開示のいくつかの例は、様々な段階を含み、それらのいくつかは、ハードウェアコンポーネントによって実行することができ、又は、マシン実行可能命令に具現化することができる。これらのマシン実行可能命令は、非一時的データ記憶媒体上に記憶することができ、これらの命令を用いてプログラムされた汎用又は特定用途向けプロセッサにこれらの段階を実行させるために使用することができる。非一時的データ記憶媒体は、オペレーティングシステムをさらに記憶することができ、マシン実行可能命令は、ePCRアプリケーション122等の1又は複数のソフトウェアアプリケーション又はプログラム内に含むことができる。これらのプログラムは、本明細書に開示されている特徴及びそれらが実行する方法を実施することができる。代替的には、これらの段階は、1つのデバイス上にある及び/又は複数のデバイス及び/又はプロセッサにわたって分散された、ハードウェア、ソフトウェア、及び/又はファームウェアの組み合わせによって実行することができる。さらに、本開示のいくつかの例は、1又は複数のコンピュータシステム、メインフレーム(例えば、IBM zSeries等のIBMメインフレーム、Unisys ClearPathメインフレーム、HP Integrity NonStopサーバ、NEC Expressシリーズ、及び他のもの)、又はクライアント-サーバタイプシステム上で少なくとも部分的に(例えば、1又は複数のモジュール)実行又は実施することができる。さらに、本開示の例の特定のハードウェアの態様は、これらのシステムのうちの1若しくは複数又はその一部を組み込むことができる。
このように少なくとも1つの例のいくつかの態様が説明されたので、様々な変更、修正及び改善が当業者にはすぐに思い浮かぶであろうことが理解されるべきである。例えば、本明細書において開示されている例は、他の状況においても使用できる。そのような変更形態、修正形態、及び改善形態は、本開示の一部であることが意図され、本明細書において議論された例の範囲内に入ることが意図されている。したがって、前述の説明及び図面は、単に例としてものである。
以下の条項は、本明細書に開示されるように、患者エンカウンタ記録を生成するシステム及び方法を提供する。
(条項1)
患者と緊急ヘルスケア提供者との間のエンカウンタに関与した複数のデバイスからの医療データを集約するシステムであって、前記システムは、
それぞれが1又は複数の識別子を有する複数の医療デバイスであって、
前記患者と前記緊急ヘルスケア提供者との間の前記エンカウンタに関係するケースデータを取得し、
前記取得されたケースデータを1又は複数の医療デバイスケースファイルとしてサーバに送信する
ように構成されている、複数の医療デバイスと、
医療デバイスインタフェース及びユーザインタフェースを有するモバイルコンピューティングデバイスであって、前記モバイルコンピューティングデバイスは、
前記医療デバイスインタフェースを介して、前記複数の医療デバイスの各医療デバイスの前記1又は複数の識別子の1又は複数の表現を取得し、
前記1又は複数の識別子を含む関連付け情報を生成し、
前記関連付け情報を前記サーバに送信する
ように構成されている、モバイルコンピューティングデバイスと、
前記1又は複数の医療デバイスケースファイルを関連付けるための命令を実行するように少なくとも1つのプロセッサ及びメモリを有する前記サーバであって、前記サーバは、前記複数の医療デバイス及び前記モバイルコンピューティングデバイスと通信可能に結合されるように構成されており、前記サーバは、
前記複数の医療デバイスから前記1又は複数の医療デバイスケースファイルを受信して格納し、
前記モバイルコンピューティングデバイスから前記関連付け情報を受信し、
前記1又は複数の医療デバイスケースファイルを互いに関係付けるように前記関連付け情報に少なくとも部分的に基づいて少なくとも1つの検索基準を生成し、
前記生成された少なくとも1つの検索基準に基づいて、前記関係付けられた1又は複数の医療デバイスケースファイルを識別し、
前記関係付けられた1又は複数の医療デバイスケースファイルからケースデータを含む統合データソースエンカウンタ構造体を生成するように、前記1又は複数の医療デバイスケースファイルを集約し、
前記患者と前記緊急ヘルスケア提供者との間の前記エンカウンタのレビューのために前記統合データソースエンカウンタ構造体を受信側コンピューティングデバイスに送信する
ようにさらに構成されている、サーバと
を備えるシステム。
(条項2)
前記取得されたケースデータは、ECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データを含む、条項1に記載のシステム。
(条項3)
患者と緊急ヘルスケア提供者との間のエンカウンタからの医療データを集約するための関連付けサーバであって、前記サーバは、
前記患者と前記緊急ヘルスケア提供者との間の前記エンカウンタ中に記録された複数の医療デバイスケースファイルからのケースデータを格納するように構成されている少なくとも1つのデータベースを格納するメモリと、
ネットワークインタフェースと、
前記メモリ及び前記ネットワークインタフェースと通信可能に結合されている少なくとも1つのプロセッサであって、前記少なくとも1つのプロセッサは、
前記ネットワークインタフェースを介して、前記エンカウンタ中に前記患者を処置するために使用された複数の医療デバイスからの前記複数の医療デバイスケースファイルを受信し、
前記複数の医療デバイスケースファイルからの前記ケースデータを前記少なくとも1つのデータベースに格納し、
前記ネットワークインタフェースを介して、モバイルコンピューティングデバイスから関連付け情報を受信し、前記関連付け情報は、前記複数の医療デバイスの各医療デバイスの少なくとも1つの識別子を含み、
前記複数の医療デバイスケースファイルを互いに関係付けるように前記関連付け情報に少なくとも部分的に基づいて少なくとも1つの検索基準を生成し、
前記生成された少なくとも1つの検索基準に基づいて、前記関係付けられた複数の医療デバイスケースファイルを識別し、
前記少なくとも1つのデータベースからの前記複数の医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を生成するように前記関係付けられた複数の医療デバイスケースファイルを集約し、
前記患者と前記緊急ヘルスケア提供者との間の前記エンカウンタのレビューのために前記統合データソースエンカウンタ構造体を受信側コンピューティングデバイスに送信する
ように構成されている、少なくとも1つのプロセッサと
を備える関連付けサーバ。
(条項4)
前記ケースデータは、ECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データを含む、条項3に記載の関連付けサーバ。
(条項5)
患者と緊急ヘルスケア提供者との間のエンカウンタからのケースデータを集約するためのコンピュータ実装プロセスであって、前記コンピュータ実装プロセスは、
ユーザインタフェースを介して、前記エンカウンタに関与した複数の医療デバイスの複数の識別子の複数の表現を取得するように入力を受信する段階と、
前記複数の識別子の前記取得された複数の表現をコンピュータのメモリに格納する段階と、
前記複数の識別子を含む関連付け情報を生成する段階と、
前記エンカウンタ中に前記複数の医療デバイスによって生成された少なくとも1つの医療デバイスケースファイルからの前記ケースデータを関連付けて集約するために、前記コンピュータのネットワークインタフェースを介して、前記関連付け情報をサーバに送信する段階と
を備えるコンピュータ実装プロセス。
(条項6)
前記ネットワークインタフェースを介して、前記少なくとも1つの医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体を受信する段階と、
前記ユーザインタフェースを介して、前記統合データソースエンカウンタ構造体の少なくとも一部をレンダリングする段階と
をさらに備える、条項5に記載のコンピュータ実装プロセス。
(条項7)
前記統合データソースエンカウンタ構造体を受信する段階は、患者情報以外の情報を受信する段階を含む、条項6に記載のコンピュータ実装プロセス。
(条項8)
前記ケースデータの前記少なくとも一部をレンダリングする段階は、ECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データをレンダリングする段階を含む、条項6に記載のコンピュータ実装プロセス。
(条項9)
前記ケースデータの前記少なくとも一部をレンダリングする段階は、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの1又は複数を含む処置データをレンダリングする段階を含む、条項6に記載のコンピュータ実装プロセス。
(条項10)
前記ケースデータの前記少なくとも一部をレンダリングする段階は、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの1又は複数を含むパフォーマンスデータをレンダリングする段階を含む、条項6に記載のコンピュータ実装プロセス。
(条項11)
前記ケースデータの前記少なくとも一部をレンダリングする段階は、保護された健康情報をレンダリングする段階を含む、条項6に記載のコンピュータ実装プロセス。
(条項12)
前記関連付け情報を送信する段階は、患者情報を送信する段階を含む、条項5に記載のコンピュータ実装プロセス。
(条項13)
前記患者情報を送信する段階は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの1又は複数を送信する段階を含む、条項12に記載のコンピュータ実装プロセス。
(条項14)
前記関連付け情報を送信する段階は、前記少なくとも1つの医療デバイスケースファイルの少なくとも一部が生成されたときを示すタイムスタンプ情報を送信する段階を含む、条項5に記載のコンピュータ実装プロセス。
(条項15)
前記関連付け情報を送信する段階は、前記複数の医療デバイスの前記複数の識別子の前記複数の表現が取得されたときを示すタイムスタンプ情報を送信する段階を含む、条項5に記載のコンピュータ実装プロセス。
(条項16)
前記関連付け情報を送信する段階は、前記複数の医療デバイスの前記複数の識別子の前記複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含む、条項15に記載のコンピュータ実装プロセス。
(条項17)
前記関連付け情報を送信する段階は、前記複数の医療デバイスの前記複数の識別子の前記複数の表現が取得されときにモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含む、条項5に記載のコンピュータ実装プロセス。
(条項18)
前記関連付け情報を送信する段階は、前記エンカウンタ中にモバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を送信する段階を含む、条項5に記載のコンピュータ実装プロセス。
(条項19)
前記関連付け情報を送信する段階は、前記少なくとも1つの医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体にアクセスするためのトークンを送信する段階を含み、前記コンピュータ実装プロセスは、前記ネットワークインタフェースを介して、前記トークンを緊急対応センタ内のコンピューティングデバイスに送信する段階をさらに備える、条項5に記載のコンピュータ実装プロセス。
(条項20)
前記複数の表現を取得するように入力を受信する段階は、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも1つを介して入力を受信する段階を含む、条項5に記載のコンピュータ実装プロセス。
(条項21)
前記複数の表現を取得するように入力を受信する段階は、カメラを介して入力を受信する段階を含み、前記複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの1又は複数を含む、条項5に記載のコンピュータ実装プロセス。
(条項22)
前記複数の識別子の前記複数の表現を取得するように入力を受信する段階は、複数の一意医療デバイス識別子の複数の表現を取得するように入力を受信する段階を含む、条項5に記載のコンピュータ実装プロセス。
(条項23)
前記エンカウンタの1又は複数のログエントリを生成する段階をさらに備える、条項5に記載のコンピュータ実装プロセス。
(条項24)
前記少なくとも1つの医療デバイスケースファイルからの前記ケースデータの少なくとも一部を含む統合データソースエンカウンタ構造体に含めるために、前記1又は複数のログエントリを前記サーバに送信する段階をさらに備える、条項23に記載のコンピュータ実装プロセス。
(条項25)
プロセッサに、条項5~24のいずれか一項に記載のコンピュータ実装プロセスを実行させるためのコンピュータプログラム。
(条項26)
条項25に記載のコンピュータプログラムを格納する非一時的コンピュータ可読記憶媒体を備えるモバイルコンピューティングデバイスであって、前記サーバから遠隔にある、モバイルコンピューティングデバイス。
(条項27)
前記ECGデータは、12リードECGデータレポートを含む、条項2に記載のシステム。
(条項28)
前記12リードECGデータレポートは、電気波形と、前記電気波形のうちの1又は複数の解釈とを含む、条項27に記載のシステム。
(条項29)
前記複数の医療デバイスは、前記サーバから前記ケースデータの要求を受信することなく、前記取得されたケースデータを1又は複数の医療デバイスケースファイルとして前記サーバに自動的に送信するように構成されている、条項1に記載のシステム。
(条項30)
前記ECGデータは、12リードECGデータレポートを含む、条項4に記載の関連付けサーバ。
(条項31)
前記12リードECGデータレポートは、電気波形と、前記電気波形のうちの1又は複数の解釈とを含む、条項30に記載の関連付けサーバ。
(条項32)
前記少なくとも1つのプロセッサは、前記複数の医療デバイスケースファイルの要求を送信することなく、前記複数の医療デバイスケースファイルを前記複数の医療デバイスから自動的に受信するように構成されている、条項3に記載の関連付けサーバ。
(条項33)
医療データレポートを送信するためのシステムであって、前記システムは、
医療デバイスであって、
患者から医療データを取得し、
前記取得された医療データの一部に少なくとも基づいて医療レポートを生成し、
前記医療レポートの要求を前記医療デバイスに送信することなく、前記医療レポートを自動的に受信するように構成されているローカルコンピューティングデバイスに、前記医療レポートを送信する
ように構成されている、医療デバイス
を備え、
前記医療デバイス又は前記ローカルコンピューティングデバイスのうちの一方又は両方が、通信ネットワークを介して前記医療レポートを1又は複数のリモートコンピューティングデバイスに送信するようにさらに構成されており、前記1又は複数のリモートコンピューティングデバイスは、前記医療レポートに関連付けられている医療データにアクセスして表示するように構成されている、システム。
(条項34)
前記医療レポートは、12リードECGレポートを含む、条項33に記載のシステム。
(条項35)
前記12リードECGレポートは、統合データソースエンカウンタ構造体の1つのレポートである、条項34に記載のシステム。
(条項36)
前記12リードECGレポートは、電気波形と、前記電気波形のうちの1又は複数の解釈とを含む、条項34に記載のシステム。
(条項37)
前記医療デバイスは、無線ローカルエリアネットワークを使用して、前記医療レポートを前記ローカルコンピューティングデバイスに送信するように構成されている、条項33に記載のシステム。
(条項38)
前記医療デバイスは、パーソナルエリアネットワークを使用して、前記医療レポートを前記ローカルコンピューティングデバイスに送信するように構成されている、条項33に記載のシステム。
(条項39)
前記医療デバイス又は前記ローカルコンピューティングデバイスは、セルラネットワークを使用して、前記医療レポートを前記1又は複数のリモートコンピューティングデバイスに送信するように構成されている、条項33に記載のシステム。
(条項40)
前記医療レポートは、前記医療デバイスによって前記ローカルコンピューティングデバイスに送信される前に暗号化される、条項33に記載のシステム。
(条項41)
前記ローカルコンピューティングデバイスは、前記医療デバイスから通信を受けることをオプトアウトするように構成されている、条項33に記載のシステム。
(条項42)
前記医療デバイスは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、又はウェアラブル除細動器を含む、条項33に記載のシステム。
(条項43)
前記1又は複数のリモートコンピューティングデバイスは、受信された医療レポートのリストを表示するように構成されている、条項33に記載のシステム。
(条項44)
前記1又は複数のリモートコンピューティングデバイスは、前記医療レポートに関連付けられているタイムスタンプに基づいて、前記受信された医療レポートのリストをフィルタするように構成されている、条項43に記載のシステム。
(条項45)
医療データレポートを受信及び送信するように構成されているモバイルコンピューティングデバイスであって、前記モバイルコンピューティングデバイスは、
メモリと、
ユーザインタフェースと、
ネットワークインタフェースと、
前記ユーザインタフェース、前記ネットワークインタフェース、及び前記メモリと通信可能に結合されている少なくとも1つのプロセッサであって、前記少なくとも1つのプロセッサは、
医療レポートの要求を医療デバイスに送信することなく、前記医療デバイスから送信された前記医療レポートを自動的に受信し
前記ユーザインタフェースを介して、前記医療レポートへのアクセスを提供し、
前記医療レポートを1又は複数のリモートコンピューティングデバイスに送信する
ように構成されている、少なくとも1つのプロセッサと
を備えるモバイルコンピューティングデバイス。
(条項46)
前記医療レポートは、12リードECGレポートを含む、条項45に記載のモバイルコンピューティングデバイス。
(条項47)
前記12リードECGレポートは、統合データソースエンカウンタ構造体の1つのレポートである、条項46に記載のモバイルコンピューティングデバイス。
(条項48)
前記12リードECGレポートは、電気波形と、前記電気波形のうちの1又は複数の解釈とを含む、条項46に記載のモバイルコンピューティングデバイス。
(条項49)
前記医療レポートは、無線ローカルエリアネットワークを介して自動的に受信される、条項45に記載のモバイルコンピューティングデバイス。
(条項50)
前記医療レポートは、パーソナルエリアネットワークを介して自動的に受信される、条項45に記載のモバイルコンピューティングデバイス。
(条項51)
前記少なくとも1つのプロセッサは、セルラネットワークを使用して、前記医療レポートを前記1又は複数のリモートコンピューティングデバイスに送信するように構成されている、条項45に記載のモバイルコンピューティングデバイス。
(条項52)
前記医療レポートは、受信される前に暗号化される、条項45に記載のモバイルコンピューティングデバイス。
(条項53)
前記少なくとも1つのプロセッサは、前記ユーザインタフェースを介して、前記医療デバイスから通信を受けることをオプトアウトするように構成されている、条項45に記載のモバイルコンピューティングデバイス。
(条項54)
前記医療デバイスは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、又はウェアラブル除細動器を含む、条項45に記載のモバイルコンピューティングデバイス。
(条項55)
医療データレポートを受信及び送信するためのコンピュータ実装プロセスであって、前記コンピュータ実装プロセスは、
医療レポートの要求を医療デバイスに送信することなく前記医療デバイスから送信された前記医療レポートを自動的に受信する段階と、
ユーザインタフェースを介して、前記医療レポートへのアクセスを提供する段階と、
前記医療レポートを1又は複数のリモートコンピューティングデバイスに送信する段階と
を備えるコンピュータ実装プロセス。
(条項56)
ディスプレイを介して、前記医療レポートに関連付けられている1又は複数の波形を表示する段階をさらに備える、条項55に記載のコンピュータ実装プロセス。
(条項57)
前記医療レポートは、12リードECGレポートを含む、条項55に記載のコンピュータ実装プロセス。
(条項58)
前記12リードECGレポートは、統合データソースエンカウンタ構造体の1つのレポートである、条項57に記載のコンピュータ実装プロセス。
(条項59)
前記12リードECGレポートは、電気波形と、前記電気波形のうちの1又は複数の解釈とを含む、条項57に記載のコンピュータ実装プロセス。
(条項60)
前記自動的に受信する段階は、無線ローカルエリアネットワークを介して、前記医療レポートを自動的に受信する段階を含む、条項55に記載のコンピュータ実装プロセス。
(条項61)
前記自動的に受信する段階は、パーソナルエリアネットワークを介して、前記医療レポートを自動的に受信する段階を含む、条項55に記載のコンピュータ実装プロセス。
(条項62)
前記送信する段階は、セルラネットワークを使用して、前記医療レポートを前記1又は複数のリモートコンピューティングデバイスに送信する段階を含む、条項55に記載のコンピュータ実装プロセス。
(条項63)
前記医療レポートを受信する段階の後で、前記医療レポートを復号する段階をさらに備える、条項55に記載のコンピュータ実装プロセス。
(条項64)
前記ユーザインタフェースを介して、ユーザからの入力を受信する段階と、前記入力に応答して、任意のさらなる医療レポートを前記自動的に受信することを停止する段階とをさらに備える、条項55に記載のコンピュータ実装プロセス。
(条項65)
プロセッサに、条項55~64のいずれか一項に記載のコンピュータ実装プロセスを実行させるためのコンピュータプログラム。
(条項66)
条項65に記載のコンピュータプログラムを格納する非一時的コンピュータ可読記憶媒体を備えるモバイルコンピューティングデバイス。

Claims (29)

  1. 患者と緊急ヘルスケア提供者との間のエンカウンタに関与した複数のデバイスからの医療データを集約するシステムであって、前記システムは、
    それぞれが1又は複数の識別子を有する複数の医療デバイスであって、
    前記患者と前記緊急ヘルスケア提供者との間の前記エンカウンタに関係するケースデータを取得し、
    前記取得されたケースデータを1又は複数の医療デバイスケースファイルとしてサーバに送信する
    ように構成されている、複数の医療デバイスと、
    医療デバイスインタフェース及びユーザインタフェースを有するモバイルコンピューティングデバイスであって、前記モバイルコンピューティングデバイスは、
    前記医療デバイスインタフェースを介して、前記複数の医療デバイスの各医療デバイスの前記1又は複数の識別子の1又は複数の表現を取得し、
    前記1又は複数の識別子を含む関連付け情報を生成し、
    前記関連付け情報を前記サーバに送信する
    ように構成されている、モバイルコンピューティングデバイスと、
    前記1又は複数の医療デバイスケースファイルを関連付けるための命令を実行するように少なくとも1つのプロセッサ及びメモリを有する前記サーバであって、前記サーバは、前記複数の医療デバイス及び前記モバイルコンピューティングデバイスと通信可能に結合されるように構成されており、前記サーバは、
    前記複数の医療デバイスから前記1又は複数の医療デバイスケースファイルを受信して格納し、
    前記モバイルコンピューティングデバイスから前記関連付け情報を受信し、
    前記1又は複数の医療デバイスケースファイルを互いに関係付けるように前記関連付け情報に少なくとも部分的に基づいて少なくとも1つの検索基準を生成し、
    前記生成された少なくとも1つの検索基準に基づいて、前記関係付けられた1又は複数の医療デバイスケースファイルを識別し、
    前記関係付けられた1又は複数の医療デバイスケースファイルからケースデータを含む統合データソースエンカウンタ構造体を生成するように、前記1又は複数の医療デバイスケースファイルを集約し、
    前記患者と前記緊急ヘルスケア提供者との間の前記エンカウンタのレビューのために前記統合データソースエンカウンタ構造体を受信側コンピューティングデバイスに送信する
    ようにさらに構成されている、サーバと
    を備えるシステム。
  2. 前記受信側コンピューティングデバイスは、前記モバイルコンピューティングデバイスを含む、請求項1に記載のシステム。
  3. 前記モバイルコンピューティングデバイスは、前記ユーザインタフェースを介して前記統合データソースエンカウンタ構造体の少なくとも一部をレンダリングするようにさらに構成されている、請求項2に記載のシステム。
  4. 前記統合データソースエンカウンタ構造体は、患者情報以外の情報を含む、請求項1に記載のシステム。
  5. 前記受信側コンピューティングデバイスは、前記複数の医療デバイスのうちの少なくとも1つの医療デバイスを含む、請求項1に記載のシステム。
  6. 前記受信側コンピューティングデバイスは、緊急対応センタ内のコンピューティングデバイスを含む、請求項1に記載のシステム。
  7. 前記関連付け情報は、前記統合データソースエンカウンタ構造体にアクセスするためのトークンを含み、前記サーバは、前記緊急対応センタ内の前記コンピューティングデバイスから前記トークンを受信するようにさらに構成されており、送信することは、前記トークンの受信に応答して前記統合データソースエンカウンタ構造体を前記コンピューティングデバイスに自動的に送信することを含む、請求項6に記載のシステム。
  8. 前記モバイルコンピューティングデバイスは、前記緊急対応センタ内の前記コンピューティングデバイスに前記トークンを送信するように構成されている、請求項7に記載のシステム。
  9. 前記1又は複数の医療デバイスケースファイルを送信することは、前記取得されたケースデータの1又は複数のストリームを前記1又は複数の医療デバイスケースファイルに送信することを含む、請求項1に記載のシステム。
  10. 前記統合データソースエンカウンタ構造体は、前記1又は複数の医療デバイスケースファイルからの前記取得されたケースデータの前記1又は複数のストリームを含む、請求項9に記載のシステム。
  11. 少なくとも1つのユーザインタフェースを含むコンピューティングデバイスであって、
    前記統合データソースエンカウンタ構造体を受信し、
    前記エンカウンタに続いて、前記少なくとも1つのユーザインタフェースを介して前記統合データソースエンカウンタ構造体の少なくとも一部をレンダリングする
    ように構成されている、コンピューティングデバイスをさらに備える、請求項1に記載のシステム。
  12. 前記複数の医療デバイスは、除細動器、患者モニタ、自動体外式除細動器、人工呼吸器、自動化胸骨圧迫デバイス、及びウェアラブル除細動器のうちの1又は複数を含む、請求項1に記載のシステム。
  13. 前記関連付け情報は、患者情報を含む、請求項1に記載のシステム。
  14. 前記患者情報は、患者名、患者識別子、年齢、性別、体重、身長、及び既往歴のうちの1又は複数を含む、請求項13に記載のシステム。
  15. 前記関連付け情報は、前記1又は複数の医療デバイスケースファイルのうちの少なくとも一部が生成されたときを示すタイムスタンプ情報を含む、請求項1に記載のシステム。
  16. 前記関連付け情報は、各医療デバイスの前記1又は複数の識別子の前記1又は複数の表現が取得されたときを示すタイムスタンプ情報を含む、請求項1に記載のシステム。
  17. 前記関連付け情報は、各医療デバイスの前記1又は複数の識別子の前記1又は複数の表現が取得されときに前記モバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含む、請求項16に記載のシステム。
  18. 前記関連付け情報は、各医療デバイスの前記1又は複数の識別子の前記1又は複数の表現が取得されたときに前記モバイルコンピューティングデバイスが位置していた場所を示すジオロケーション情報を含む、請求項1に記載のシステム。
  19. 前記関連付け情報は、前記モバイルコンピューティングデバイスが前記エンカウンタ中に位置していた場所を示すジオロケーション情報を含む、請求項1に記載のシステム。
  20. 前記医療デバイスインタフェースは、カメラ、近距離通信センサ、無線周波数識別センサ、ユニバーサルシリアルバスコネクタ、赤外線センサ、パーソナルエリアネットワークセンサ、近接検出器、ジオロケーション検出器、及び無線ネットワークコネクタのうちの少なくとも1つを含む、請求項1に記載のシステム。
  21. 前記医療デバイスインタフェースは、カメラを含み、前記1又は複数の識別子は、クイックレスポンスコード、バーコード、及びデバイス識別子のうちの1又は複数を含む、請求項1に記載のシステム。
  22. 各医療デバイスの前記1又は複数の識別子は、1又は複数の一意デバイス識別子に対応する、請求項1に記載のシステム。
  23. 前記モバイルコンピューティングデバイスは、前記エンカウンタの1又は複数のログエントリを生成するようにさらに構成されている、請求項1に記載のシステム。
  24. 前記モバイルコンピューティングデバイスは、前記統合データソースエンカウンタ構造体に含めるために、前記1又は複数のログエントリを前記サーバに送信するように構成されている、請求項23に記載のシステム。
  25. 前記サーバは、前記モバイルコンピューティングデバイスから遠隔にある、請求項1に記載のシステム。
  26. 前記取得されたケースデータは、ECGデータ、酸素飽和度データ、カプノグラフィックデータ、及び血圧データのうちの1又は複数を含む生理学データを含む、請求項1に記載のシステム。
  27. 前記取得されたケースデータは、除細動データ、薬剤注入データ、胸骨圧迫データ、及び換気データのうちの1又は複数を含む処置データを含む、請求項1に記載のシステム。
  28. 前記取得されたケースデータは、胸骨圧迫パフォーマンスデータ及び換気パフォーマンスデータのうちの1又は複数を含むパフォーマンスデータを含む、請求項1に記載のシステム。
  29. 前記取得されたケースデータは、保護された健康情報を含む、請求項1に記載のシステム。
JP2022558108A 2020-03-31 2021-03-30 患者エンカウンタ記録を生成するシステム及び方法 Pending JP2023519672A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202063002678P 2020-03-31 2020-03-31
US63/002,678 2020-03-31
US202063111234P 2020-11-09 2020-11-09
US63/111,234 2020-11-09
PCT/US2021/024833 WO2021202490A1 (en) 2020-03-31 2021-03-30 Systems and methods of producing patient encounter records

Publications (2)

Publication Number Publication Date
JP2023519672A JP2023519672A (ja) 2023-05-12
JPWO2021202490A5 true JPWO2021202490A5 (ja) 2024-03-26

Family

ID=75660309

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022558108A Pending JP2023519672A (ja) 2020-03-31 2021-03-30 患者エンカウンタ記録を生成するシステム及び方法

Country Status (6)

Country Link
US (1) US20210304881A1 (ja)
EP (1) EP4128256A1 (ja)
JP (1) JP2023519672A (ja)
CN (1) CN115867975A (ja)
AU (1) AU2021245840A1 (ja)
WO (1) WO2021202490A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3937428A1 (en) * 2020-07-06 2022-01-12 Roche Diagnostics GmbH Filtering data from an analytical device
US12119094B2 (en) * 2021-08-05 2024-10-15 GE Precision Healthcare LLC Systems and methods for connecting devices to electronic medical records
WO2023014992A1 (en) * 2021-08-06 2023-02-09 AndorHealth, LLC Virtual care systems and methods
US20240120047A1 (en) * 2022-10-05 2024-04-11 Vector Remote Care, LLC System and method for remote medical data sensing and analysis
US20240148994A1 (en) * 2022-11-03 2024-05-09 Resmed Digital Health Inc. Methods and systems for transferring access to patient data between organizations
EP4404209A1 (en) * 2023-01-17 2024-07-24 Stryker Corporation Enhanced recording of rescue events
CN116825265A (zh) * 2023-08-29 2023-09-29 先临三维科技股份有限公司 就诊记录处理方法、装置、电子设备及存储介质
CN117116410B (zh) * 2023-10-24 2023-12-29 慧创科仪(北京)科技有限公司 一种用于近红外脑功能成像设备的医学报告生成装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8515547B2 (en) * 2007-08-31 2013-08-20 Cardiac Pacemakers, Inc. Wireless patient communicator for use in a life critical network
EP3543920B1 (en) * 2010-04-09 2023-09-13 ZOLL Medical Corporation Systems and methods for ems device communications interface
US9495511B2 (en) * 2011-03-01 2016-11-15 Covidien Lp Remote monitoring systems and methods for medical devices
US20130191161A1 (en) * 2012-01-24 2013-07-25 Vimedicus, Inc. Patient data input and access system that enhances patient care
WO2014105592A1 (en) * 2012-12-28 2014-07-03 Volcano Corporation Devices, systems, and methods for handling data in the context of invasive, multi-modality medical systems
CA2904669A1 (en) * 2013-03-13 2014-10-02 Board Of Regents Of The University Of Texas System System and method for a patient dashboard
US10109377B2 (en) * 2013-12-03 2018-10-23 Cura Technologies Inc. System and method for facilitating delivery of patient-care
US9706376B2 (en) * 2015-05-15 2017-07-11 Avaya Inc. Navigational aid for emergency response personnel
CN109561942A (zh) * 2016-07-11 2019-04-02 柯惠Lp公司 使用屏蔽容器来考虑在临床程序期间所使用的应答器标记物体的方法和设备
WO2018218162A1 (en) * 2017-05-26 2018-11-29 Tiatech Usa, Inc. Telemedicine systems
WO2019055121A1 (en) * 2017-09-13 2019-03-21 Battelle Memorial Institute HEALTH MONITORING DEVICE THAT CAN BE USED
WO2021236839A1 (en) * 2020-05-22 2021-11-25 HeartCloud, Inc. Methods and systems for securely communicating over networks, in real time, and utilizing biometric data

Similar Documents

Publication Publication Date Title
US20210304881A1 (en) Systems and methods of producing patient encounter records
US20220157418A1 (en) Systems and methods for documenting emergency care
US12053276B2 (en) Biometric identification in medical devices
JP7355826B2 (ja) プラットフォーム非依存のリアルタイム医療データ表示システム
US20200206517A1 (en) Systems and methods for ems device communications interface
US20120191476A1 (en) Systems and methods for collection, organization and display of ems information
AU2010276325B2 (en) Systems and methods for collection, organization and display of EMS information
US11315667B2 (en) Patient healthcare record templates
US20160180037A9 (en) Decision support tool for use with a medical monitor-defibrillator
US20210369113A1 (en) Acute Care Eco System Integrating Customized Devices of Personalized Care With Networked Population Based Management
US12073928B2 (en) Handling of age transmitted data in medical device system
CN105210065A (zh) 用于向用户提供医疗护理算法的系统和方法
US20220310219A1 (en) Medical record digest
US20210304860A1 (en) Systems and methods of integrating medical device case files with corresponding patient care records
US20220020491A1 (en) Systems and methods for ems device communications interface
JPWO2021202490A5 (ja)
US20240257959A1 (en) Aligning timestamps of data collected by multiple devices at medical scene
CN108010565A (zh) 一种医疗信息记录方法及装置
Migliorelli et al. A Cloud-Based Healthcare Infrastructure for Neonatal Intensive-Care Units
WO2023219985A1 (en) Systems and methods for ems encounter records
Prokopiou Android home monitor system for post cardiosurgery patients