JP2022542375A - 薬剤デバイス監視に基づくプリエンプティブな喘息リスク通知 - Google Patents

Abstract

喘息分析システムは、予測されるレスキュー使用イベントの前に喘息リスク通知を提供して、患者の行動の変化に影響を与えるのを助け、それらのイベントの発生を防止する。レスキュー投薬イベント、環境条件の変化、およびその他の状況に関連する情報は、患者の薬剤デバイスに関連付けられたセンサによって検出され、他のソースからそれぞれ収集されて、患者のリスクスコアを決定するための基礎を提供する。このデータは、喘息イベントに対する患者のリスクの重症度を判断するために分析され、それに応じて通知を送信するために使用される。

Description

本開示は、一般に、吸入器を使用する患者に対する治療を改善する方法に関し、より具体的には、喘息関連のレスキューイベントの患者のリスクを決定することに関連する。

喘息は、依然として重要かつ費用のかかる公衆衛生上の問題である。世界的に、世界保健機関は、喘息を患う人口が３億人であり得ると推定し、２０２５年までに４億人に増加すると予測している。米国では、喘息は、１２人に１人が罹患しており、患者数は上昇しており、医療利用コストが年間５６０億ドルを超える原因となっている。

新薬の開発にもかかわらず、入院および緊急治療室への訪問率は低下していない。米国では毎年、この病気は、約２００万人の救急外来訪問、５０万人の入院、および５，０００人の死亡を引き起こしている。加えて、喘息は、推定で１，５００万の学校の欠席日数、および１，２００万の欠勤日数の原因となっている。米国の健康保険会社と雇用主に対する年間総コストは、１８０億ドルを超えている。

これらの悪化の大部分は、現在利用可能な治療法で防ぐことができる。しかしながら、喘息患者の５人に１人だけが、この病気を抑制している。新たに改訂された国のガイドラインは、治療が毎日の症状を抑制し、生活の質を改善しているかどうかをより注意深く監視するように医師に求めている。しかしながら、医師は、彼らの患者が日々どの程度よく過ごしているかを評価するために利用可能なツールをほとんど持っていない。ますます多くの医師が、定期的な記述式質問票（喘息コントロールテストなど）を使用して、患者を監視し、彼らのコントロールのレベルを判断し始めている。これらの手段は、患者に症状の頻度、吸入器の使用、並びに活動レベルおよび制限を一定期間（通常は２～４週間）にわたって正確に思い出して報告することを要求する。結果として、これらの質問票は、偏見（想起）、症状のさまざまな解釈、および行動（非アドヒアランス）によってもたらされるエラーの影響を受けやすく、それらが使用される時点での情報を提供するだけである。

より一般的には、吸入器などの薬剤デバイスは、抑制された気流などの呼吸器症状を患者が管理することを可能にする。喘息、慢性閉塞性肺疾患（ＣＯＰＤ）、および嚢胞性線維症の患者など、多くの呼吸器疾患患者は、大気環境、気象、土地利用など、環境的なトリガおよび要因に関連する症状を有する。どの環境的なトリガおよび要因が彼らの症状に影響を与えるかを知っている患者は、患者が彼らの症状をよりよく管理し、緊急医療を必要とする機会を低減することを可能にする。しかしながら、特定の患者または患者のグループは、複数のトリガおよび要因に対して敏感であり得る。数十、数百、またはそれ以上のトリガおよび要因のうちのどれに患者が敏感であるかを知り、症状の管理に使用するためにそれらのトリガおよび要因を監視することは、複雑なタスクであり、多くの患者および提供者にとって現在実行可能ではない。

喘息分析システムは、喘息に起因するレスキューイベントを治療、監視、および管理するための統合プラットフォームである。喘息分析システムは、彼らの喘息の管理を支援するために喘息分析システムを承認した患者によって使用される薬剤デバイス（たとえば、吸入器）に取り付けられたセンサからイベント通知を受信することにより、喘息レスキュー薬イベントを追跡する。センサは、定量吸入器または他の薬剤デバイスに取り付けられているかまたは組み込まれている場合、レスキュー使用イベントの地理的位置、時刻、および日付を記録し、その情報を喘息分析システムに伝達する。喘息分析システムは、受信したイベント（最新および以前に受信したイベントの両方）をリアルタイムまたはほぼリアルタイムで分析し、リスク評価および疾患を指導し、かつ管理するための情報を通知の形で患者および医療提供者へ配信する。

患者固有のリスクスコアは、患者の医療歴、患者の日々の現況、ならびに大気および気象条件に関連する環境条件を含むパラメータの組み合わせを使用して決定される。これらのパラメータと患者に対して生成されたリスク評価との間の関係は、機械学習モデルに具現化される。モデル、およびより一般的にはシステムは、パラメータに対する入力値を受け取り、患者が毎日服用する薬剤パフの数を予測することができる。システムは、予測に基づいて患者固有のリスクスコアをさらに決定し、リスクスコアを分類して、リスクを軽減するための正確かつ医療的に関連する治療オプションとともにリスク評価を提供し得る。

薬剤の使用のタイミング、頻度、および場所に関する情報を、状況に応じて関連する他のパラメータ情報とともに取り込むことにより、喘息分析システムは、行動または環境の即時適用可能な変更をそれらの予測されたイベントの前に提案することにより、将来の喘息レスキュー使用イベントの発生を防ぐのに役立つ。これにより、患者および彼らの医療提供者による喘息治療のよりよい管理が容易になり、レスキューイベントを引き起こす特定の場所の認識が向上するため、患者は将来これらの場所を回避または適応し得るようになる。

図１は、一実施形態による、正確なリアルタイムの薬剤デバイスの使用を監視し、そのデータに対して分析を実行し、喘息レスキューイベントリスク通知を提供するための喘息分析システムを示す図である。 図２は、一実施形態による、クライアントデバイス、アプリケーションサーバ、および／またはデータベースサーバのいずれかとして使用されるコンピューティングデバイスの例を示す高レベルブロック図である。 図３Ａは、一実施形態による、ユーザが喘息分析システムと対話することを可能にするクライアントアプリケーションのダッシュボードを示す図である。 図３Ｂは、一実施形態による、クライアントアプリケーションのダッシュボード内に表示される例示的なカードを示す図である。 図４は、一実施形態による、薬剤デバイスの監視に基づく喘息リスクベースの通知を提供するための相互作用図である。 図５は、一実施形態による、喘息分析システムによるレスキュー投薬イベントを検出するためのフローチャートである。 図６は、一実施形態による、喘息リスクモジュール内のモジュールを示すブロック図である。 図７は、一実施形態による、データ分析モジュール１３１の構成要素を使用して患者の喘息リスクを決定するためのプロセスを示す図である。 図８は、一実施形態による、トレーニングデータセットを使用してモデルをトレーニングするための方法を示す図である。 図９Ａは、一実施形態による、非線形モデルによって生成された出力の視覚化を示す図である。 図９Ｂは、一実施形態による、非線形モデルによって生成された出力の視覚化を示す図である。 図１０Ａは、一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴づけ、分析する図である。 図１０Ｂは、一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴づけ、分析する図である。

これらの図は、例示のみを目的として、本発明の様々な実施形態を示している。当業者は、本明細書で説明される構造および方法の代替的な実施形態が、本明細書で説明される原理から逸脱することなく採用され得ることを以下の説明から容易に認識するであろう。

Ｉ．システム環境
図１は、一実施形態による、正確なリアルタイムの薬剤デバイスの使用を監視し、そのデータに対して分析を実行し、喘息レスキューイベントリスク通知を提供するための喘息分析システム１００を示す。

喘息分析システムは、クライアントコンピューティングデバイス１１０、薬剤デバイスセンサ１２０、薬剤デバイス１６０、アプリケーションサーバ１３０、データベースサーバ１４０、およびネットワーク１５０を含む。図１は、喘息分析システム１００のほとんどの構成要素の単一のインスタンスのみを示しているが、実際には、各構成要素のうちの２つ以上が存在し得、追加またはより少ない構成要素が使用され得る。

Ｉ．Ａ．クライアントデバイスおよびアプリケーション
クライアントデバイス１１０は、それらのユーザの要請により、ネットワーク１５０を介して喘息分析システム１００と相互作用する。説明および明確さのために、少なくとも２つの異なるタイプのユーザを識別することが役立つ。患者１１１は、喘息を患っているユーザであり、喘息分析システム１００を少なくとも部分的に利用して、サーバ１３０によって提供されるパーソナライズ化された喘息レスキューイベントリスク通知および医療提供者１１２によって作成される喘息管理通知を取得する。そのような通知は、喘息分析システム１００が患者の１１１薬剤デバイス１６０の使用を監視することを可能にするユーザの許可と引き換えに提供することができる。以下で説明するように、投薬イベントは、薬剤デバイス１６０およびユーザのクライアントデバイス１００に関連付けられたセンサ１２０によって検出され、次に、アプリケーションサーバ１３０に報告し、次に、クライアントデバイス１１０を介してユーザに提供されるリスク通知を生成するプロセスを開始することができる。

別のタイプのユーザは、やはり患者１１１の明示的な許可とともに、患者の喘息管理に関する通知、ならびに集約された喘息コミュニティレスキューイベントデータおよび喘息イベントおよび他の関連データに関する導出された統計も受け取る医療提供者１１２である。自分のクライアントデバイス１１０が自分の子供のものとは異なる場合に通知を受け取りたいと思うかもしれない患者１１１の親／保護者など、他のタイプのユーザも企図される。

クライアントデバイス１１０は、コンピュータシステムである。例示的な物理的実装は、図２に関して以下により完全に説明される。クライアントデバイス１１０は、ネットワーク１５０を介して喘息分析システム１００と無線通信するように構成される。ネットワーク１５０にアクセスすると、クライアントデバイス１１０は、ユーザの地理的位置およびレスキュー薬剤イベントの時刻、ならびに関連する薬剤デバイスセンサ１２０（全体を通して「センサ１２０」と呼ばれる）から受信したイベントを説明する情報をアプリケーションサーバ１３０に送信する。

ユーザ位置およびイベント時間に関して、クライアントデバイス１１０は、それが接続されているセルラーまたはワイヤレスネットワーク１５０に関する情報の使用を通じて、レスキューイベントの地理的位置および時間を決定し得る。例えば、クライアントデバイス１１０の現在の地理的位置は、ネットワーク１５０接続を提供するソフトウェアスタックに直接問い合わせることによって決定され得る。あるいは、地理的位置情報は、ネットワーク１５０を介してアクセス可能にされた外部ウェブサービス（図１には示されていない）にピン（ｐｉｎｇ）することによって取得され得る。イベントの時間は、イベントデータの一部としてセンサ１２０によって提供されるか、またはクライアントデバイスのネイティブオペレーティングシステムの一部として利用可能な適切なソフトウェアルーチンに問い合わせることによってイベントデータに追加されることができる。

アプリケーションサーバ１３０と通信することに加えて、アプリケーションサーバ１３０に無線で接続されたクライアントデバイス１１０はまた、他の接続されたクライアントデバイス１１０と情報を交換し得る。例えば、クライアントソフトウェアアプリケーション１１５を介して、医療提供者１１２は、患者１１１に関する最近のレスキューイベントを説明するリスク悪化通知を受信し、次いで、それに応じて、喘息後のレスキューイベント治療のために患者１１１に推奨事項を送信し得る。同様に、アプリケーション１１５を介して、患者１１１は、彼らの医療提供者１１２および他の患者１１１と通信し得る。

アプリケーション１１５は、クライアントデバイス１１０の画面上に表示され、ユーザがアプリケーション１１５の動作を制御するためのコマンドを入力することを可能にするユーザインターフェース（ここでは「ダッシュボード」と呼ばれる）を提供する。ダッシュボードは、医療提供者１１２および患者１１１がＣＯＰＤ分析システム１００にアクセスするためのメカニズムである。たとえば、ダッシュボードは、患者１１１および提供者１１２が相互に対話し、喘息レスキューイベントのリスク通知を受信し、治療に関するメッセージを交換し、追加のイベントおよび非イベントデータなどを提供および受信することができる。アプリケーション１１５は、１つのウェブページ、一連のウェブページ、またはそうでなければインターネットブラウザ内でレンダリングするようにコード化されたコンテンツとしてコード化され得る。アプリケーション１１５はまた、クライアントデバイス１１０のネイティブオペレーティングシステム上で動作するように構成されたプロプライエタリアプリケーションとしてコード化され得る。ダッシュボードは、図３と併せて以下でより完全に説明される。

ダッシュボードを提供することに加えて、アプリケーション１１５はまた、ネットワーク１５０を介して処理されたデータを送信する前に、クライアントデバイス１１０のリソースを使用してローカルで喘息レスキューイベントデータに対していくつかのデータ処理を実行し得る。ネットワーク１１０を介して送信されたイベントデータは、アプリケーションサーバ１３０によって受信され、そこで、データベースサーバ１４０と連携して、格納および検索のために分析および処理される。アプリケーションサーバ１３０は、クライアントアプリケーション１１５によって要求されると、検索および格納要求をデータベースシステム１３０に向け得る。

クライアントデバイス１１０は、ネットワークアダプタおよび有線または無線通信プロトコルのいずれかを使用してセンサ１２０と通信し、その一例は、ブルートゥース低エネルギー（ＢＴＬＥ）プロトコルである。ＢＴＬＥは、短距離ワイヤレスネットワークの無線リンクを介してワイヤレスでデータを送信する、短距離で低電力のプロトコル標準である。センサ１２０およびクライアントデバイス１１０ がＢＴＬＥパスキーを使用して互いにペアリングされた 後、センサ１２０は、薬剤デバイスの使用に関する情報をクライアントデバイス１１０と自動的に同期させ、通信する。レスキュー投薬イベントの前にセンサ１２０がクライアントデバイス１１０とペアリングされていない場合、そのようなペアリングが発生するまで、情報はセンサ１２０によってローカルに格納される。ペアリングすると、センサ１２０は、格納されたイベントレコードをクライアントデバイス１１０に通信する。他の実装では、他のタイプのワイヤレス接続が使用される（たとえば、赤外線または８０２．１１）。

クライアントデバイス１１０および薬剤デバイス１６０は、別個の物理的デバイス（それぞれ、スマートフォンおよび吸入器など）であるとして上記で説明されているが、薬剤デバイス１６０は、デバイス１６０と共に単一のハウジングに統合されたセンサ１２０だけでなく、クライアントデバイス１１０の態様も含み得る。例えば、薬剤デバイス１６０は、ディスプレイまたは他の照明要素を含む視聴覚インターフェース、ならびに視覚的可聴情報を提示するためのスピーカーを含み得る。そのような実装において、薬剤デバイス１６０自体が、クライアントデバイス１１０を介してそれらを提示する代わりに、またはそれに加えて、サーバ１３０によって提供される通知の内容を直接提示し得る。

Ｉ．Ｂ．薬剤デバイスおよびセンサ
薬剤デバイス１６０は、抑制された呼吸気流を経験しているユーザの肺に薬剤を送達するために使用される医療デバイスである。薬剤デバイス（吸入器など）は典型的に、携帯可能であり、呼吸器の発作を治療する際のアクセスを容易にするために手で持ち運べるほど小さい。一実施形態では、薬剤は、定量吸入器などの薬剤デバイス１６０を介してエアロゾル形態で送達される。定量吸入器は、エアロゾル薬の加圧推進剤キャニスター、調整された薬剤の投与量を送達するための計量バルブ、および加圧キャニスターを保持し、薬剤を送達するためのマウスピースを形成するプラスチックホルダーを含む。別の実施形態では、薬剤は、乾燥粉末吸入器などの薬剤デバイス１６０を介して乾燥粉末の形態で送達される。乾燥粉末吸入器は、ユーザが一片の乾燥粉末薬剤を介してインデックスを作成できるようにするホイールおよびギアのメカニズムを収容するデカルトの卵形の本体を備えている場合がある。乾燥粉末吸入器の本体は、ユーザに乾燥粉末を送達するためのマニホールドおよびマウスピースも含む。コントローラ薬剤デバイス１６０によって投薬されるコントローラ薬剤の例は、ベクロメタゾン、ブデソニド、およびフルチカゾン、ならびにこれらの薬剤とサルメテロールまたはホルモテロールなどの長時間作用型気管支拡張薬との組み合わせを含む。レスキュー薬剤デバイス１６０によって投薬されるレスキュー薬剤の例は、アルブテロール、サルブタモール、レバルブテロール、メタプロテレノール、およびテルブタリンを含む。

各患者は、複数の薬剤デバイス１６０に関連付けられ得る。例えば、患者は、レスキュー薬剤を投薬するレスキュー薬剤デバイス１６０、およびコントローラ薬剤を投薬するコントローラ薬剤デバイス１６０を有し得る。同様に、各患者は、それぞれが患者の薬剤デバイス１６０の１つで動作するように選択された２つ以上のセンサ１２０に関連付けられ得る。

一般に、センサ１２０は、薬剤ディスペンサー１６０の使用を監視する物理的デバイスである。センサ１２０は、薬剤ディスペンサーの動作を妨げることなく薬剤ディスペンサーに取り外し可能に取り付け可能であるか、またはセンサ１２０は、その製造業者によって利用可能にされた薬剤ディスペンサー１６０の本来の部分である統合された構成要素である。

センサ１２０は、有線接続を介して、またはより典型的には無線周波数接続を介してクライアントデバイス１１０と通信するそれ自体のネットワークアダプタ（図示せず）を含む。一実施形態では、ネットワークアダプタは、ブルートゥース低エネルギー（ＢＴＬＥ）無線送信機である。しかしながら、他の実施形態では、他のタイプの無線通信が使用され得る（例えば、赤外線、８０２．１１）。

センサ１２０はまた、アプリケーションサーバ１３０とより直接的に通信するように構成され得る。例えば、センサ１２０のネットワークアダプタが、８０２．１１またはＬＴＥなどの無線標準を介して通信するように構成されている場合、アダプタは、無線ルータなどの無線アクセスポイントとデータを交換し得、無線ルータは、次に、データのすべての交換に必ずしもクライアントデバイス１１０を関与させることなく、アプリケーションサーバ１３０と通信し得る。これらの２つの通信方法は相互に排他的ではなく、センサ１２０は、例えば、イベントデータがアプリケーションサーバ１３０に確実に到着するように、冗長送信を使用してクライアントデバイス１１０およびアプリケーションサーバ１３０の両方と通信するように、または、アプリケーションサーバ１３０がイベントに応答して提供する通知を決定している間に、クライアントデバイス１１０に直接情報を提供するように構成され得る。

上で紹介したように、センサ１２０は、薬剤デバイス１６０の使用に関するデータをキャプチャする。具体的には、各センサ１２０は、患者１１１による、レスキュー投薬イベントの時間および地理的位置、すなわち、レスキュー薬剤デバイス１６０の使用をキャプチャする。各センサ１２０は、リアルタイムで、またはネットワーク接続が達成されるとすぐに、患者１１１または医療提供者１１２からの入力なしに自動的にイベントデータを送信する。薬剤イベント情報は、分析、喘息レスキューイベント通知の生成、および複数の患者にわたるイベントデータの集約分析で使用するために、アプリケーションサーバ１３０に送信される。

この目標を達成するために、センサ１２０を構築するためのいくつかの異なる方法があり、部分的に、構築は、薬剤デバイス自体１６０の構築に依存するであろう。一般に、すべてのセンサ１２０は、オンボードプロセッサ、永続メモリ、および上記のネットワークアダプタを含み、これらは共に、投薬イベント情報を記録し、格納し、クライアントデバイス１１０および／またはサーバ１３０に報告するように機能する。センサ１２０はまた、イベントの日時を記録するための時計を含み得る。

特定のセンサ１２０の構造に関して、機械的用量カウンタなどの従来の吸入器は、センサ１２０を念頭に置いて設計されておらず、したがって、センサ１２０は、それに応じて構築され得る。この方法のいくつかの実装形態は、デバイス１６０の動き、デバイスのプライミング（ｐｒｉｍｉｎｇ）、デバイスの起動（ａｃｔｉｖａｔｉｏｎ）、ユーザによる吸入などを検出するための機械的、電気的、または光学的センサを含む。対照的に、偏向可能な膜線量カウンタ（ｄｅｆｌｅｃｔａｂｌｅ ｍｅｍｂｒａｎｅ ｄｏｓｅ ｃｏｕｎｔｅｒ）などの最新の吸入器は、センサ１２０が受信および解釈するように設計された電気データ信号としてイベント情報を報告し得る電気回路を含む。例えば、薬剤デバイス１６０自体が、動き、プライミング、および起動をセンサ１２０に報告し得る。一実施形態では、センサは、薬剤デバイスの動き、例えば、薬剤が投薬されていることを示す薬剤カバーの開口部を検出する。代替の実施形態では、センサは、薬剤が投薬される位置へのキャニスターの動きを検出し得る。薬剤デバイスが起動されたことを示すそのような動きを検出した後、センサは、薬剤デバイスが薬剤を投薬したこと、および薬剤を投薬した時間を報告し得る。

センサ１２０および薬剤デバイス１６０のハードウェアおよびソフトウェアコンポーネント、ならびにレスキュー投薬イベントを記録するためのそれらの間の相互作用に関する詳細は、２００９年１月１日に出願された米国特許出願第１２／３４８，４２４号、および２０１４年５月２１日に出願された国際出願ＰＣＴ／ＵＳ２０１４／０３９０１４号に記載されており、これらは両方とも、参照によりその全体が本明細書に組み込まれる。

Ｉ．Ｃ．アプリケーションサーバ
アプリケーションサーバ１３０は、コンピュータまたはコンピュータのネットワークである。簡略化された例が図２に示されているが、典型的には、アプリケーションサーバ１３０は、例えば、クライアントデバイス１１０として使用される典型的なコンピューティングシステムと比較して、強力なプロセッサ、大容量メモリ、およびより高速なネットワークコンポーネントを使用するサーバクラスシステムである。サーバは典型的に、例えばＲＡＩＤ（独立ディスクの冗長アレイ）アレイを使用し、および／または、上記で検討した喘息通知などのデータの保存、交換、および送信を請け負った独立コンテンツ配信ネットワーク（ＣＤＮ）との関係を確立することにより、大容量のセカンダリストレージを有する。さらに、コンピューティングシステムは、オペレーティングシステム、例えば、ＵＮＩＸオペレーティングシステム、ＬＩＮＵＸオペレーティングシステム、またはＷＩＮＤＯＷＳオペレーティングシステムを含む。オペレーティングシステムは、アプリケーションサーバ１３０のハードウェアおよびソフトウェアリソースを管理し、また、プロセス管理、データの入出力、周辺デバイスの管理などの様々なサービスを提供する。オペレーティングシステムは、デバイスに格納されているファイルを管理するためのさまざまな機能、例えば、新しいファイルの作成、ファイルの移動またはコピー、リモートシステムへのファイルの転送などを提供する。

アプリケーションサーバ１３０は、ネットワーク１５０を介した多くの異なるクライアントデバイス１１０による喘息分析システム１００へのアクセスおよび使用をサポートするためのソフトウェアアーキテクチャを含み、したがって、高レベルでは、一般に、クラウドベースのシステムとして特徴付けることができる。アプリケーションサーバ１３０は、一般に、患者１１１および医療提供者１１２のためのプラットフォームを提供し、レスキュー投薬およびコントローラ投薬イベントの両方を含む、彼らの薬剤デバイス１６０に関連するセンサによって記録されたデータを報告し、喘息治療計画について協力し、彼らの状態および地理的位置に関連する情報を閲覧および取得し、並びに他のさまざまな機能を利用する。

一般に、アプリケーションサーバ１３０は、多種多様なデータを処理するように設計されている。アプリケーションサーバ１３０は、着信データの有効性のチェック、必要に応じてデータの解析およびフォーマット、格納のために処理されたデータをデータベースサーバ１４０に渡すこと、およびデータベースサーバ１４０が更新されたことの確認を含む様々な機能を実行する論理ルーチンを含む。

アプリケーションサーバ１３０は、患者ごとに少なくとも部分的にデータを格納および管理する。この目的に向けて、アプリケーションサーバ１３０は、各ユーザの患者プロファイルを作成する。患者プロファイルは、喘息分析システム１００の患者１１１を特徴付けるデータのセットである。患者プロファイルは、年齢、性別、現在のレスキュー薬剤、現在のコントローラ薬剤、通知設定、コントローラ薬剤アドヒアランス計画、患者関連の病歴、患者プロファイルにアクセスを許可された非患者ユーザのリストなど、患者に関する識別情報を含み得る。プロファイルは、患者のデータ（コントローラおよびレスキュー投薬イベントなど）を提出することを許可された１つまたは複数のクライアントデバイス１１０またはセンサ１２０を識別する一意のメディアアクセス制御（ＭＡＣ）アドレスなどのデバイス識別子をさらに指定し得る。

プロファイルは、どの異なるタイプの通知が患者１１１およびその個人の医療提供者１１２に提供されるか、ならびに通知が提供される頻度を指定し得る。例えば、患者１１１は、医療提供者１１２がレスキューイベントを示す通知を受信することを許可し得る。患者１１１はまた、彼らの医療提供者１１２が彼らの患者プロファイルおよびレスキューイベント履歴へのアクセスを与えられることを許可し得る。医療提供者１１２が患者１１１の患者プロファイルへのアクセスを提供される場合、医療提供者は、コントローラの順守またはレスキュー投薬計画を指定し得る。投薬計画は、コントローラ投薬のための１日あたりの処方された用量数を含み得る。

アプリケーションサーバ１３０はまた、医療提供者１１２のプロファイルを作成する。医療提供者プロファイルは、オフィスの場所、資格および証明書など、医療提供者１１２に関する識別情報を含み得る。医療提供者プロファイルはまた、彼らの患者集団に関する情報を含む。提供者プロファイルは、その提供者の患者のすべてのプロファイルへのアクセス、ならびに集まった人口統計情報、レスキューおよびコントローラ投薬イベントパターンなどの彼らのプロファイルから派生したデータを含み得る。このデータは、地理的領域（例えば、近隣、都市）ごとに、期間（例えば、毎週、毎月、毎年）ごとになど、患者プロファイルに格納されている任意のタイプのデータに従ってさらに細分化され得る。

アプリケーションサーバ１３０は、アプリケーションサーバ１３０上で様々なルーチンをトリガする、クライアントデバイス１１０またはセンサ１２０からレスキュー投薬イベント情報を受信する。以下に説明される例示的な実装では、データ分析モジュール１３１は、喘息イベントデータおよび患者のプロファイルを含む他のデータにアクセスし、データを分析し、その分析の結果を患者１１１および提供者１１２の双方に出力するルーチンを実行する。このプロセスは一般的に、喘息リスク分析と呼ばれる。喘息リスク分析は、レスキューイベントに応じて、患者の環境の関連する変化に応じて、および以下でさらに説明するいくつかのトリガ条件のいずれかに応じて、任意の時点で実行され得る。

他の分析も可能である。例えば、リスク分析は、個人、地理的、臨床的、疫学的、人口統計学的、もしくは空間的または時間的なベースラインまたは予測値または期待値から歴史的に重要な並び替えに基づく薬剤使用の空間的／時間的クラスタ（または発生）に基づいて識別するために、複数の患者のレスキューおよびコントローラ薬剤使用に対して実行され得る。他のタイプの分析は、毎日／毎週のアドヒアランス傾向、経時的なアドヒアランスの変化、他の関連する集団（例えば、すべての患者、特定のレスキュー薬剤またはコントローラ薬剤またはそれらの組み合わせの患者に対する比較、トリガの識別（空間的、時間的、環境）、経時的なレスキュー使用の傾向、および他の関連する集団とのレスキュー使用の比較を含み得る。

実行された分析に応答して、アプリケーションサーバ１３０は、プッシュ通知を準備して配信し、患者１１１、許可された医療提供者１１２、および／または患者プロファイルへのアクセスを提供された他のユーザに送信する。通知は、投薬レスキューイベントに関与するタイミング、場所、および影響を受けた患者１１１に関する詳細を提供することができる。通知は、緊急支援提供者１１２に配信される緊急支援を要求する苦痛または緊急信号をさらに含み得る。通知はまた、データ分析モジュール１３１によって実行された喘息リスク分析の結果を含み得る。送信され得る通知の種類とそれに含まれ得るコンテンツに関する詳細については、以下でさらに説明する。

喘息リスク分析に応じてプッシュ通知を提供することに加えて、通知は、特定の時間間隔でプル通知として提供される場合もある。さらに、一部の通知（プッシュまたはプル）は、レスキュー投薬イベントに応答して実行される喘息リスク分析に応答してではなく、喘息の根本的な要因の１つが変化することに応答して実行されるリスク分析に応答してトリガされ得、更新された通知が保証される。例えば、気象条件が、大気汚染の増加が発生している、または差し迫っていることを示している場合、これは、汚染が発生している特定の地理的領域にいるすべての患者に対する喘息リスク分析の実行をトリガし得る。

通知は、クライアントアプリケーションでの使用のために特別に設計されたデータ形式でネットワーク１５０を介してクライアントアプリケーション１１５に提供され、さらにまたは代わりに、ショートメッセージサービス（ＳＭＳ）メッセージ、電子メール、電話呼び出し、または他の通信媒体を使用して通信される他のデータ形式で提供され得る。
Ｉ．Ｄ．データベースサーバ
データベースサーバ１４０は、プロファイル、投薬イベント、患者の病歴（例えば、電子医療記録）などの患者および提供者データ関連データを格納する。患者および提供者データは、セキュリティのために暗号化されており、少なくともパスワードで保護されているか、その他の方法ですべての医療保険の相互運用性と責任に関する法律（ＨＩＰＡＡ）の要件を満たすように保護されている。複数の患者からのデータ（例えば、集まったレスキュー投薬イベントデータ）を組み込み、ユーザに提供される分析（例えば、喘息リスク分析）は匿名化され、患者のプライバシーを保護するために個人を特定する情報が削除される。

データベースサーバ１４０はまた、喘息リスク分析で使用される非患者データを格納する。このデータは、患者が物理的に位置し、汚染物質にさらされる可能性のある住宅または商業ゾーンの公共スペースなど、多くの地理的地域に関する地域データを含む。このデータは、特に、患者が緑地（樹木や植物が集中している領域）に近接していることを取得するために含むか、処理される場合がある。地域データの一例は、気温、風のパターン、湿度、空気質指数などの地理参照された気象データを含む。別の例は、ある時点での、または経験的に測定されたさまざまな汚染物質の粒子数を含む、地理参照された汚染データである。地域データは、気温、湿度、空気質指数など、レスキューイベントの時間と場所の現在の気象条件に関する情報を含む。上記のデータのすべての項目は、時間の経過とともに変化する可能性があり、そのため、データ自体は時間でインデックス付けされる場合があり、例えば、個別のデータポイントが、時刻（分または時間を含む）ごとに、もしくは日、週、月、または季節ごとのようなより長い期間にわたって利用できる場合がある。データベースサーバ１４０は、アプリケーションサーバ１３０とは別のエンティティであるとして図１に示されているが、データベースサーバ１４０は、代わりに、サーバ１３０などの別のサーバの一部であるハードウェアコンポーネントであり得、その結果、データベースサーバ１４０は、他のサーバ１３０の一部であるデータベースの格納されたデータとインターフェースするためのソフトウェアアプリケーション層を備えた１つまたは複数の永続ストレージデバイスとして実装される。

データベースサーバ１４０は、定義されたデータベーススキーマに従ってデータを格納する。典型的に、さまざまなデータソース間でのデータストレージスキーマは、クラウドアプリケーションイベントログやログメトリックなどの同じタイプのデータを保存する場合でも、基盤となるデータベース構造の実装の違いにより、大幅に異なる。データベースサーバ１４０はまた、構造化データ、非構造化データ、または半構造化データなどの異なるタイプのデータを格納し得る。データベースサーバ１４０内のデータは、ユーザ、ユーザのグループ、および／またはエンティティに関連付けられ得る。データベースサーバ１４０は、データベースサーバ１４０によって表されるデータベースオブジェクトを管理し、データベースサーバ１４０から情報を読み取り、またはデータベースサーバ１４０に書き込むための命令を指定するクエリ言語（例えば、リレーショナルデータベース用のＳＱＬ、ＪＳＯＮ ＮｏＳＱＬデータベースなど）でのデータベースクエリのサポートを提供する。

以下の図６Ａ～６Ｄの説明に関して、これらの図面に関して説明されたデータベースの内容は、図示されたように、アプリケーションサーバ１３０に物理的に近接し、データベースサーバ１４０から分離されたデータベースに格納され得る。あるいは、それらのデータベースは、データ分析モジュール１３１内にあるものとしてそれらを示す図６Ａ～６Ｄの説明とは対照的に、データベースサーバ１４０の一部であり得る。これおよびその他のバリエーションは、この説明の範囲内にある。

Ｉ．Ｅ．ネットワーク
ネットワーク１５０は、クライアント１１０デバイス、センサ１２０、アプリケーションサーバ１３０、およびデータベースサーバ１４０の間の様々な有線および無線通信経路を表す。ネットワーク１５０は、標準のインターネット通信技術および／またはプロトコルを使用する。したがって、ネットワーク１５０は、イーサネット、ＩＥＥＥ ８０２．１１、統合サービスデジタルネットワーク（ＩＳＤＮ）、非同期転送モード（ＡＴＭ）などの技術を使用するリンクを含むことができる。同様に、ネットワーク１５０で使用されるネットワーキングプロトコルは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）、シンプルメール転送プロトコル（ＳＭＴＰ）、ファイル転送プロトコル（ＦＴＰ）などを含むことができる。ネットワーク１５０を介して交換されるデータは、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）などを含む技術および／またはフォーマットを使用して表されることができる。さらに、すべてまたは一部のリンクは、セキュアソケットレイヤ（ＳＳＬ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）、および／または仮想プライベートネットワーク（ＶＰＮｓ）などの従来の暗号化技術を使用して暗号化されることができる。別の実施形態では、エンティティは、上記の技術の代わりに、またはそれに加えて、カスタムおよび／または専用のデータ通信技術を使用することができる。

ＩＩ．例示的なコンピューティングデバイス
図２は、一実施形態による、図１からのクライアントデバイス１１０、アプリケーションサーバ１３０、および／またはデータベースサーバ１４０の一部として使用され得る例示的なコンピュータ２００の物理的構成要素を示す高レベルブロック図である。図示されているのは、少なくとも１つのプロセッサ２０５に結合されたチップセット２１０である。チップセット２１０に結合されているのは、揮発性メモリ２１５、ネットワークアダプタ２２０、入力／出力（Ｉ／Ｏ）デバイス２２５、不揮発性メモリを表すストレージデバイス２３０、およびディスプレイ２３５である。一実施形態では、チップセット２１０の機能は、メモリコントローラ２１１およびＩ／Ｏコントローラ２１２によって提供される。別の実施形態では、メモリ２１５は、チップセット２１０の代わりにプロセッサ２０５に直接結合される。いくつかの実施形態では、メモリ２１５は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭまたは他のランダムアクセスソリッドステートメモリデバイスなどの高速ランダムアクセスメモリ（ＲＡＭ）を含む。

ストレージデバイス２３０は、ハードドライブまたはソリッドステートメモリデバイスなどの任意の非一時的なコンピュータ可読記憶媒体である。メモリ２１５は、プロセッサ２０５によって使用される命令およびデータを保持する。Ｉ／Ｏデバイス２２５は、タッチ入力面（容量性またはその他）、マウス、トラックボール、または他のタイプのポインティングデバイス、キーボード、または別の形式の入力デバイスであり得る。ディスプレイ２３５は、コンピュータ２００からの画像および他の情報を表示する。ネットワークアダプタ２２０は、コンピュータ２００をネットワーク１５０に結合する。

当技術分野で知られているように、コンピュータ２００は、図２に示されているものとは異なるおよび／または他の構成要素を有することができる。さらに、コンピュータ２００は、特定の図示された構成要素を欠く可能性がある。一実施形態では、サーバ１４０として機能するコンピュータ２００は、専用のＩ／Ｏデバイス２２５、および／またはディスプレイ２１８を欠いてもよい。さらに、ストレージデバイス２３０は、コンピュータ２００からローカルおよび／またはリモートであり得る（記憶領域ネットワーク（ＳＡＮ）内に具現化されるなど）。

一般に、クライアントデバイス１１０で使用される正確な物理コンポーネントは、サイズ、電力要件、および性能が、アプリケーションサーバ１３０およびデータベースサーバ１４０で使用されるものとは異なるだろう。例えば、クライアントデバイス１１０は、多くの場合、家庭用コンピュータ、タブレットコンピュータ、ラップトップコンピュータ、またはスマートフォンであり、比較的小さな記憶容量および処理能力を含むが、入力デバイスおよびディスプレイを含む。これらのコンポーネントは、データのユーザ入力、並びにアプリケーションサーバ１３０によって提供される通知の受信、表示、および対話に適している。対照的に、アプリケーションサーバ１３０は、上で紹介した喘息リスク分析を実行するためのかなりの量の処理能力をそれぞれが有する、物理的に分離され、ローカルにネットワーク化された多くのコンピュータを含み得る。一実施形態では、アプリケーションサーバ１３０の処理能力は、アマゾンウェブサービス（登録商標）などのサービスによって提供される。また対照的に、データベースサーバ１４０は、アプリケーションサーバに関連するデータを格納するためのかなりの量の永続的な記憶容量をそれぞれが有する多くの物理的に別個のコンピュータを含み得る。

当技術分野で知られているように、コンピュータ２００は、本明細書で説明される機能を提供するためのコンピュータプログラムモジュールを実行するように適合されている。モジュールはハードウェア、ファームウェア、および／またはソフトウェアで実装されることができる。一実施形態では、プログラムモジュールは、ストレージデバイス２３０に格納され、メモリ２１５にロードされ、プロセッサ２０５によって実行される。

ＩＩＩ．ダッシュボード
ダッシュボード、例えば図３Ａに示されるダッシュボード３００は、ユーザが喘息分析システム１００と対話することを可能にする。ダッシュボード３００は、ユーザからユーザ（例えば、患者１１１から提供者１１２）またはユーザからシステム／システムからユーザベースで情報を転送する手段を提供する。ダッシュボード３００は、クライアントデバイス１１０上のクライアントアプリケーション１１５を介してアクセスされ、患者および医療提供者の双方が薬剤レスキューイベントを監視し、パーソナライズ化された患者医療情報を交換し、喘息レスキューイベントリスク通知などの通知を受信するためのメカニズムを提供する。患者は、例えば、喘息、薬剤使用、または喘息管理に関する情報について話し合い、共有するために、ダッシュボード３００を介して他の医療提供者および他の患者と通信し得る。喘息の医療情報を共有する機能は、同様の問題を経験している患者または医療提供者に、個々の視点を共有する方法を提供し得る。

ダッシュボード３００はまた、許可された医療提供者１１２が患者のリストにアクセスして、喘息患者およびコミュニティデータおよび統計に関する情報を様々な人口統計または地理的セグメントで表示、注釈付け、更新、対話、およびエクスポートすることを可能にする。ダッシュボード３００を使用して、医療提供者は、患者を個別にまたは集合的に監視し、彼らの関連する患者集団が喘息管理ガイダンスにどのように反応しているかについてのフィードバックを受け取り、提供することができる。個々の患者または複数の患者にアクセスできる医療提供者は、通知のしきい値を設定し、通知のパラメータを設定し、患者のイベント履歴が特定の条件（レスキューイベントなど）に一致したときに通知を受信することができる。さらに、ダッシュボード３００は、喘息分析システム１００によって生成された特定の人口統計のイベントパターンの定期的なレポートを受信して表示することができる。

ダッシュボード３００は、表形式のデータ、グラフィカルな視覚化、および分析を含む様々な情報を、ディスプレイ「カード」３１０を介してユーザに提示する。ディスプレイカード３１０は、例えば携帯電話またはタブレットなどの携帯型クライアントデバイス１１０に典型的な小型ディスプレイに適合しており、野球カードに見られる単純な組織スタイルを模倣する「一口サイズ」の情報を含む。ダッシュボード３００はまた、ユーザが医療情報の異なるカテゴリを通してナビゲートすることを可能にするシステムメニュー３０５を含み得る。

アプリケーションサーバ１３０によって提供される通知は、ディスプレイカード３１０に関連している。一般に、通知は、アプリケーション１１５を介してユーザに提示される情報だけでなく、通知の内容を表示するためにどのディスプレイカード３１０が使用されるかを指定するためのパラメータも含む。アプリケーションサーバ１３０からプッシュ／プルされた情報は、１つまたは複数のカードに関連付けられ得る。例えば、喘息リスク分析の結果に基づいて、通知を患者にプッシュすることができる。ダッシュボード３００は、通知を処理し、通知に情報を提示するために使用するカードを決定する。例を続けると、通知の受信者は、アプリケーションサーバ１３０からデータをプルするように要求し得る。アプリケーションサーバ１３０は、要求されたデータを別の通知で提供し、ダッシュボード３００は、次に、要求された情報を表示するディスプレイカード３１０を決定する。

提示された情報と対話するために、いくつかのディスプレイカード３１０ａは、入力応答３１５領域を含む。例えば、図３Ｂに示されるディスプレイカード３１０ｂでは、患者は、入力応答３１５領域を上下にスクロールして、喘息を管理するために使用されるコントローラ薬剤を選択するか、または「次」を選択して追加のディスプレイカード３１０に移動し得る。

ダッシュボード３００は、カテゴリに編成され得る様々な異なるディスプレイカード３１０を提供し得る。情報カードタイプは、データを表示するカードを含む。情報カードは、たとえば、投薬レスキューイベント、統計、並びに患者データおよびコミュニティデータの両方を含むマップを表示し得る。情報カードはさらに、イベント、トレンド、教育、およびアラート表示カードに細分類される。

イベントカードは、特定の患者の過去の投薬レスキューイベントのリストなどのレスキュー投薬イベントに関連するデータ、または特定の提供者の地理的マップにオーバーレイされた患者レスキューイベントデータを含む。

図３Ｂは、データ分析モジュール１３１によるリスクスコアの決定に基づいて送信される、通知モジュール６４５（以下で説明される）によって送信される例示的なディスプレイカード３１０ａを示す。ディスプレイカード３１０ａは、リスクスコアを決定するために使用される入力値から得られた患者情報、例えば、デバイス１１０によって指定された患者の現在の地理的位置、および環境情報を強調表示する。ディスプレイカード３１０ａはまた、リスクスコアに基づくリスク分類、この場合、中程度のリスク分類を表し得る「普通（ｆａｉｒ）」を含む。

別のイベントカードは、レスキュー使用イベントの場所のマップ、その場所の環境条件、および受信者がレスキュー使用イベントのトリガを追加するための入力応答領域３１５を含む、例示的な薬剤使用レポートを表示し得る。別のイベントトレンドカードは、その期間の合計使用回数と各日の使用回数を含む、前週のレスキューデバイス使用状況を表示し得る。

トレンドカードは、受信者による明確な理解のために設計されたグラフまたはチャートを使用して提示された統計情報を含む。トレンドカードの例は、さまざまな期間にわたる喘息レスキューイベントのプロット、時刻の傾向、曜日の傾向、およびトリガの傾向を含む。

教育カードは、受信者を教育するための情報を含む。教育カードは、患者がレスキューイベントの彼らのリスクを減らすための一般的な病気の情報およびヒントを提供する。一部の教育カードは、提供された情報が将来のカードを提供する際に使用するのに関連するかまたは興味深いかを受信者が指定できるようにするために、入力応答３１５を必要とする場合がある。

アラートカードは、イベントのリスクがあること、および／または最近の期間にデバイスからデータが受信されていないことを受信者に知らせることを含む重要な情報をユーザに通知する。その他のアラートは、クライアントデバイスの設定がデータ同期を妨げている（例えば、Ｂｌｕｅｔｏｏｔｈがオフになっている）、または患者の喘息リスクスコアが変化したというアラートを含む場合がある。

調査カードタイプは、ユーザに「はい／いいえ」、複数選択、または自由形式の質問を提示することにより、ユーザの回答を求める。例えば、医療提供者または喘息分析システム１００は、特定の患者の疾患制御のレベルを決定するために、喘息関連の質問票と共に調査カードを患者１１１に送信し得る。さらに、調査カードは、患者１１１が喘息の症状を治療するために使用するコントローラ薬剤のタイプを要求し得る。一般に、調査カードは、アプリケーションサーバ１３０に、患者の病歴または患者プロファイル（上記で紹介したように）から欠落している可能性のあるデータを提供し、および／または潜在的に古い情報への更新を提供する。１つまたは複数の調査カードを使用して、患者登録プロセスを完了し、データベースサーバ１４０に格納するための患者プロファイルを作成し得る。たとえば、患者１１１が最初に喘息分析システム１００に登録すると、プッシュ通知がアプリケーションサーバ１３０によってトリガされ、患者１１１に患者プロファイルの作成を促す。

調査カードの例は、喘息のレスキューイベントの結果として患者が緊急治療室を訪れたかどうか、患者のコントローラ投薬に関する情報、患者が救急薬を使用してイベントを制御した回数、および彼らのコントローラ投薬の毎日のスケジュールは何であるかを尋ねる調査質問を含み得る。調査カードは、花粉がトリガであるかどうかなど、患者の喘息のトリガについて尋ね得る。一部の調査カードは、患者の一般的な生活の質を５ポイントのリッカート尺度で評価したり、患者の睡眠の質を評価したり、患者の過去７日間の活動能力を評価したりするように患者に尋ね得る。他の調査カードは、患者が昨日より気分が良いか悪いか、患者がレスキューイベントのために過去１２か月間に救急治療室または病院に行かなければならなかったかどうかなどを尋ねる。

場合によっては、既存の患者情報と矛盾する患者の行動またはセンサによって報告されたイベント情報が、患者の状況に関するあいまいさを解決するために調査カードの送信をトリガすることがある。例えば、患者が予想よりも多い数の喘息イベントを経験している場合、調査カードは、正しい薬剤が使用されていることを確認するために、患者が彼らの薬剤デバイス１６０に現在リストしている薬剤のタイプに関する情報を要求し得る。別の例は、コントローラ薬剤の使用に関する報告された情報が、患者がコントローラ薬剤を１日に１回しか使用していないことを示しているが、彼らの遵守計画は彼らがコントローラ薬剤を１日に２回服用することになっていることを示している場合、システム１００は、患者が彼らの遵守計画を変更する必要があるかどうかを尋ねる通知を送信することができることを含む。

場合によっては、既存の患者情報と矛盾する患者の行動またはセンサによって報告されたイベント情報が、患者の状況に関するあいまいさを解決するために調査カードの送信をトリガすることがある。例えば、患者が予想よりも多い数の喘息イベントを経験している場合、調査カードは、正しい薬剤が使用されていることを確認するために、患者が彼らの薬剤デバイス１６０に現在リストしている薬剤のタイプに関する情報を要求し得る。別の例として、コントローラ薬剤の使用に関する報告された情報が、患者がコントローラ薬剤を１日に１回しか使用していないことを示しているが、遵守計画がコントローラ薬剤を１日に２回服用することになっていることを示している場合、システム１００は、患者が彼らの遵守計画を変更する必要があるかどうかを尋ねる通知を送信することができる。

ナビゲーションカードは、ユーザ対話の際に、ダッシュボード３００の一部である別の画面またはカードにユーザをリダイレクトし得る実用的なデータまたはメッセージを表す。たとえば、患者が医師と情報を共有したり、コントローラ薬剤に関する特定の投薬計画を要求したりする場合、ナビゲーションカードは、情報の共有またはコントローラ遵守計画への登録を容易にするために使用されるだろう。さらに、ナビゲーションカードは、ユーザが投薬レスキューイベントに関する情報を更新することを可能にする。

アドヒアランスカードは、患者にさまざまな期間にわたってスケジュールどおりにコントローラ薬剤を継続的に使用することを促すように設計されている。アドヒアランスカードは、時間通りのコントローラ投薬イベントの「ストリーク（ｓｔｒｅａｋ）」または継続的な実行を示し得る。さらに、調査カードは、互いの閾値期間内にかなりの数のレスキューイベントを記録することに応答して、患者の身体的状態について問い合わせ得る。コントローラ投薬イベントは、患者１１１が、医療提供者１１２によって処方されたように、１日のさまざまな期間中にコントローラ投薬を時間どおりに行ったときと行わなかったときとを示すグラフとして表され得る。カードはまた、コントローラ投薬の毎日のスケジュール、およびスケジュールされた用量が服用されたかどうかを表示するためのインジケーターを詳細に記載し得る。たとえば、赤い「Ｘ」は、予定された服用が行われていないことを示している場合があるが、緑のチェックマークまたは別の記号は、予定された服用が行われていることを示している場合がある。

セットアップカードは、センサをクライアントデバイス１１０に関連付ける際に受信者をガイドする。セットアップカードは、ブルートゥースを使用してセンサをクライアントデバイス１１０にペアリングするように案内し、受信者にペアリングプロセスを開始するように促し、またはユーザにペアリングするセンサデバイスを選択するように促し、もしくはセンサがペアリングされたことをユーザに通知し得る。

いくつかの実施形態では、ダッシュボードは、ユーザインターフェースを提示し得る。ユーザインターフェースは、「タイムラインの表示（Ｖｉｅｗ Ｔｉｍｅｌｉｎｅ）」入力応答領域３１５ｃのユーザの選択に応答して、レスキューイベントのリストを示し得る。このリストは、一定期間のレスキュー使用イベントを表示し、日付、時刻、パフの数、場所などの詳細を含む。受信者は、編集対話応答領域を選択することにより、レスキュー使用イベントを編集し、および／またはさらなる詳細を追加し得る。一部のインターフェースは、レスキュー使用イベントのイベント要約をユーザに提示し得る。イベント要約は、ユーザがユーザインターフェースの編集対話応答領域を選択したことに応答して、ユーザに提示され得る。ダッシュボードから、ユーザはまた、投薬タイプ（レスキュー、コントローラなど）、投薬スケジュール、およびセンサなどの詳細を記述した投薬リストを表示および編集し得る。

ＩＶ．イベント駆動型喘息リスク通知
図４は、一実施形態による、薬剤デバイスの監視に基づく喘息リスク通知を提供するための対話図を示す。最初のステップとして、患者はダッシュボード３００とインターフェースして、患者プロファイルを初期化する４０５。患者が彼らの患者プロファイルを完了すると、クライアントデバイス１１０は、アプリケーションサーバ１３０による使用、およびデータベースサーバ１４０による格納のために、患者プロファイルを送信する。患者の患者プロファイルが初期化されると４０５、アプリケーションサーバ１３０は、患者の薬剤デバイス１６０に関連付けられたセンサ１２０によって検出されたレスキュー薬剤イベントの受信を開始し得る。患者プロファイルの初期化と完了は、患者が最初に薬剤デバイスを使用するときに１回だけ実行される。

センサがレスキュー使用イベントを検出すると４１０、クライアントデバイス１１０は、レスキューイベントデータを収集してアプリケーションサーバ１３０に送信し、そこでイベント情報が格納される４１５。図４にはそのような例が１つだけ示されているが、この検出および格納プロセスは、一般にレスキュー使用イベントが検出されると、一般に多くの患者に対してある程度の頻度で実行される。しかしながら、この頻度は、リスク分析が実行される頻度とは異なり得る。

ここで図５を参照すると、アプリケーションサーバ１３０は一般に、喘息関連のイベント症状を軽減するために、患者が彼らのレスキュー薬剤ディスペンサー１６０を使用するときはいつでも、レスキューイベントを受信する。特定のデバイス１６０／センサ１２０の組み合わせについてそのようなイベントをキャプチャするためのプロセスの例として、症状の開始時に、センサ１２０は、薬剤ディスペンサー１６０のカバーが開いているかどうかを検出し得る５０５。薬剤ディスペンサーカバーが開かれると、センサ１２０は、ディスペンサー１６０のプライミングに関連する加速度を検出し得る５１０。一部のタイプの薬剤ディスペンサーの場合、「プライミング」は、パッケージから薬剤の投与量を放出するメカニズムを起動することを含む。他のタイプの薬剤ディスペンサーでは、「プライミング」は、薬剤キャニスターの急速な振とう（ｓｈａｋｉｎｇ）を含む。

プライミング動作が検出された後、センサ１２０は、レスキューイベントに関連するデータをセンサ１２０のアクティブメモリに格納するように構成される５１５。レスキューイベントデータは、レスキューイベントに関連する日時、薬剤デバイス１６０のステータスまたは状態（例えば、電池レベル）、残りの薬剤の投与回数（イベントの前または後）、セルフテスト結果、およびセンサ１２０によって測定された、薬剤デバイス１６０で治療されている患者の生理学的データを説明する情報を含み得る。センサがクライアントデバイス１１０またはネットワーク１５０のいずれかとのネットワーク接続を確立するとき、センサは、ローカルに格納されたレスキューイベントデータをクライアントデバイス１１０またはアプリケーションサーバ１３０に送信する５２５。イベントデータが最初にクライアントデバイス１１０に送信された場合、クライアントデバイス１１０は、次に、クライアントデバイス１１０がネットワーク１５０とのネットワーク接続を確立するときに、レスキューイベントデータをアプリケーションサーバ１３０に送信する５３０。実装に応じて、クライアントデバイス１１０またはセンサ１２０のいずれかが、イベントが発生した地理的位置を、アプリケーションサーバ１３０に送信されるイベントデータに追加する。

ここで図４に戻り、レスキュー使用イベントを検出すると４１０、イベントデータが収集されて保存される４１５。レスキュー使用イベントデータを受信して格納すると４１５、アプリケーションサーバ１３０は、レスキュー使用イベントを説明する患者からのさらなる情報を要求し得る。情報を取得するために、アプリケーションサーバ１３０は、患者のクライアントデバイス１１０に送信される、尋ねられるべき質問を含むプッシュ通知を生成する。クライアントデバイス１１０は、プッシュ通知を調査タイプカード３１０として提示し得る。患者は、調査カード３１０に応答して入力３１５を提供することによって要求に応答し得る。あるいは、患者１１１は、要求に応答しないことを選択し得る。これは許容され、情報のギャップは、後のプッシュ通知を通じて、または患者１１１との会議後に提供者１１２が入力したときに取得され得る。一実施形態では、要求に応答して追加的に要求されたデータを受信できないことは、ステップ４２５～４４５で説明される分析の残りを保持しない。

イベントの一部として、またはその他の方法で収集された情報に基づいて、喘息分析システムはトリガ状態を検出する４２０。トリガ条件は、イベントのトリガに役割を果たした可能性のあるパラメータ、レスキューイベントの場所、場所のラベル（例えば、職場、自宅、または学）、患者にとってその場所の個人的な重要性を示す評価、および任意の他の関連情報に加えて、使用がプリエンプティブ（たとえば、運動前に服用した薬剤）であったかどうかに関する情報を指す。トリガ条件の例は、限定されないが、クライアントデバイスの場所の変更、レスキュー吸入器使用イベントを記録するための期間の結論、少なくとも１つの患者パラメータ、天気パラメータ、および大気汚染物質パラメータの値の変更、並びにレスキュー薬剤を投薬するレスキュー吸入器ユニットの発生／検出を含む。

追加のイベントデータを要求することに加えて、アプリケーションサーバ１３０は、データベースサーバ１４０から格納されたコンテキストデータにアクセスする４２５。一般に、コンテキストデータは、イベントデータ以外のデータを指し、限定されないが、これは、大気条件、気象条件、過去のレスキュー使用イベントから記録された患者データ、およびレスキュー使用イベントの時間に薬剤デバイスによって直接検出されていない任意の他の考慮を含む。対照的に、イベントデータは、投薬量、イベントの時間、イベントの場所、および関連するアドヒアランスデータなど、レスキューイベントに関連し、薬剤デバイスによって報告される任意のパラメータを指す。どちらの形式のデータも、時間的に最新の情報、並びに保存された履歴データを含み得る。したがって、コンテキストデータを取得する一環として、アプリケーションサーバ１３０は、患者１１１の過去のレスキュー使用イベントデータにもアクセスする。この履歴データは、過去のコントローラからのすべてのデータ、または過去のさまざまな時間枠にわたる患者の履歴からのレスキュー投薬イベントデータを含むことができ、各履歴イベントは、このイベントについて報告されたものと同じ情報項目のすべてを、その後のフォローアップ時に収集されたデータと共に含み得る４１０。

しかしながら、図６などの以下の説明では、場合によっては、コンテキストデータ６３５および履歴データ６２０が別々に表されていることに留意されたい。コンテキストデータ６３５は、患者のクライアントデバイス１１０の現在のイベントまたは現在の場所に関連する地理的および地域的情報を参照し、一方、履歴データ６２０は、同じまたは異なる患者から以前のレスキュー使用イベントからの地理的、地域的、およびイベント情報を参照する。

ＩＶ．Ａ．喘息予測モデルの概要
図６は、一実施形態による、データ分析モジュール１３１の機能を実行する論理コンポーネントを示すブロック図である。喘息分析システム１００は、アプリケーションサーバ１３０上に、上で紹介され、以下でさらに議論される、システムによって収集された様々なデータを分析するデータ分析モジュール１３１を含み、トリガ状態の発生時に患者に対してリスク分析を実行する４３０。これらのリスク分析は、レスキュー吸入器の使用を必要とする喘息イベントの発生を減らすために、十分にタイムリーに患者に送信されるように特別に構成された通知を生成するために使用される。図６の図示の実施形態では、データ分析モジュール１３１は、履歴データストア６２０、パラメータ値ストア６３０、モデル６４０、パーソナライズ化されたリスクモジュール６５０、分類モジュール６６０、通知モジュール６７０、および解釈モジュール６８０を含む。他の実施形態では、データ分析モジュール１３１は、より多くのまたはより少ないモジュールを含み得る。特定のモジュールによって実行されていると示されている機能は、代わりに他のモジュールまたはコンポーネントによって実行される場合がある。

リスク分析は、トリガ条件によってトリガされる場合があり、トリガ条件自体は、自動的にスケジュールされたり、手動で設定されたり、および／または特定のイベントまたはコンテキスト情報に応じて発生したりする場合がある。トリガ条件の例は、これらには限定されないが、入力値の変更、ユーザの場所の変更、レスキューイベントの発生の結果、または時間間隔の終了を含む。

リスク分析を実行するために、数学関数または他のより複雑な論理構造などのモデル６４０は、履歴イベントデータおよび履歴コンテキストデータを使用してトレーニングされ、事前に格納され、リスク分析の一部として使用されるパラメータ値のセットを決定する。パラメータ値６３０は、入力値の少なくとも１つに関連する「重み」（または使用されるモデリング技術に応じて、臨界値または他の同様の量）を表す。入力値は、モデル６４０のパラメータの数値またはカテゴリ値を参照し、入力値は、時間の経過とともに患者間で変化する。

簡単に言えば、リスク分析は、モデル６４０の関数への入力値およびパラメータ値６３０として、ユーザのレスキュー吸入器使用イベント６０５、６２０および他のコンテキストデータ６３５、６２０の態様を入力することによって実行され、数値リスクスコアを決定する。例えば、モデル６４０は、入力として、気象データ、汚染物質データ、患者データ、社会データ、および構築された環境データの組み合わせを受け取り、出力として、患者によって摂取された薬剤パフの数の予測を生成する。一般に、入力値として使用するために収集されたコンテキストデータ（つまり、気象データ、汚染物質データ、患者データ、社会データ、および構築された環境データ）は、デバイスまたはその他のサードパーティのデータレポートに基づいて自動的に収集され、患者および／または提供者によって手動で提供され、またはその他の方法で取得され得る。

予想されるパフの数（例えば、レスキュー吸入器ユニットによって分配される薬剤の量）は、モデル６４０によって生成される数値であり、イベントデータ６０５およびコンテキストデータ６３５が与えられた場合に患者が当日経験する予想される薬剤使用レスキューイベントの数を特徴付ける。薬剤パフを服用している患者の記録は、レスキュー薬剤使用イベントを経験している患者を表している。多数のパフの予測は、予想されるレスキュー使用イベントの数の増加と相関するため、パフの数の予測は、特定の日の患者の喘息リスク評価の代表として解釈され得る。代替の実施形態では、モデルは代わりに、患者の母集団全体に対して決定された閾値を超える予想される数のパフ（例えば、予測される数のレスキュー吸入器使用イベント）を患者が経験する確率を生成し得る。患者の母集団は、彼らの薬剤使用の近接性または類似性に基づいて特定され得る。

いくつかの実装形態では、トレーニングされたモデル６４０からの情報および／またはユーザのための特定の入力および予測は、解釈モジュール６８０に伝達される。解釈モジュール６８０は、モデル６４０の内部動作をさらに視覚化するために様々な処理技術を実行する。これらの手法は、これらに限定されないが、母集団レベルでの蓄積された局所効果と順列（ｐｅｒｍｕｔａｔｉｏｎ）ベースの特徴の重要性、もしくはサンプルレベルまたは個々の患者レベルでのシャープレイ加法説明を含む。したがって、解釈モジュール６８０は、通知モジュール６７０によって生成される通知の内容として患者または提供者に追加の洞察を提供し、個々の患者について、または個々の患者の当日について、個々の環境変数が患者集団全体にわたるレスキュー吸入器使用にどのように影響するかの視覚的な説明を提供し得る。図９Ａは、特徴重要性の視覚化の例を示し、図９Ｂは、いくつかの実施形態による、個々の可変効果の視覚化の例を示している。

モデルによって生成された予測は、患者固有のリスクスコアを計算するために、パーソナライズ化リスクモジュール６５０によって受け取られる。いくつかの実施形態では、患者固有のリスクスコアは、モデル６４０によって生成された生の予測と、その患者のために生成された最近の過去のベースラインとの比較に基づいて決定される。過去のベースラインは、一定期間にわたるパフの代表的な分布を決定するためにさまざまな手法を使用して計算され得る。過去のベースラインが計算される期間は、モデル６４０が予想されるパフ数を予測した当日の前の連続した日のセットであり得る。別の実施形態では、パフの毎日の予測数の代わりに、患者の過去のベースラインは、前の期間にわたる患者の毎日記録された薬物使用に基づいて計算され得る。

一実施形態では、パーソナライズ化リスクモジュール６５０は、当日のモデルの出力（すなわち、当日の予測されたパフ数）を、前の日々の期間のパフ数の過去の予測のパーセンタイルとして比較する。実際には、各履歴予測にはある程度の誤差があるが、その誤差は本質的にほぼ対称であるため、現在の予測は履歴予測の分布全体と比較され、患者のリスクスコアを正確に特徴付け得る。

代替の実施形態では、パーソナライズ化リスクモジュール６５０は、前の期間にわたる毎日の実際の過去のパフの標準偏差を計算することによって、過去のベースラインを決定する。例えば、パーソナライズ化リスクモジュール６５０は、過去３０日間の平均パフを差し引き、その差を標準偏差で割ることによって、ｚスコアを計算する。パーソナライズ化リスクモジュール６５０は、追加の計算技術、例えば、シグモイド関数を適用して、患者固有のリスクスコア（すなわち、過去のベースラインと予測されるパフ数との比較）を０から１の間の値として特徴付け得る。

別の代替の実施形態では、パーソナライズ化リスクモジュール６５０は、ブートストラップ法を使用して過去のベースラインを決定する。モジュールは最初に、１日あたりの過去のパフのベースライン期間からの置換を伴う、繰り返されるランダムサンプルに基づいてサンプル平均の分布を計算し、次に、この分布のパーセンタイルとして予想されるパフの数を計算する。

パーソナライズ化リスクモジュール６５０によって生成された患者固有のリスクスコアは、分類モジュール６６０によって受け取られる。分類モジュール６６０は、患者固有のリスクスコアをある範囲のリスクスコア、例えば、「良好」、「普通」、または「不良」に分類する。いくつかの実施形態では、モデル６４０は、２日間の比較を、用量の数を比較する分数またはリスクスコアの履歴を比較するパーセンタイルとして特徴づける。たとえば、「良好」分類は、０～３の範囲の患者固有のリスクスコアに適用され、「普通」分類は、３～９の範囲の患者固有のリスクスコアに適用され、「不良」分類は、９＋の範囲の患者固有のリスクスコアに適用され得る。

特定の実装では、モデル６４０は、特定の地理的領域の空気品質が喘息関連イベントのリスクにおいて患者に重大なリスクをもたらすことを示す大気汚染物質データを受け取る。このような大気汚染物質データのインスタンスは、サードパーティの空気品質分析提供者または米国海洋大気庁（ＮＯＡＡ）によって提供されるインデックスまたはルックアップテーブルを使用して特定され得る。そのような場合、モデル６４０は、ルールベースの処理技術の組み合わせを実装して、影響を受ける地理的領域内のすべてのリスクのある患者に「不良」分類で通知を生成し、伝達する。

別の実装では、分類モジュール６６０は、所与の日の患者の実際のパフカウントを、パーソナライズ化リスクモジュール６５０によって生成された閾値累積パフカウントと比較する。実際のパフカウントは、吸入器ユニットがパフを投与するために使用されたことを示す、患者のレスキュー使用吸入器ユニットに結合されたセンサから受信する定期的な信号に基づいて記録され得る。実際のパフカウントが閾値を満たすか超える場合、分類モジュール６６０は、その日の残りのリスクスコアの実際の数値に関係なく、患者固有のリスクスコアを「不良」として分類する。そのような閾値は、前の期間にわたって患者について記録されたレスキュー使用イベントの履歴データに基づいて決定され得る。たとえば、特定のユーザの特定の日の特定の時間に、１日のパフの予想数は１．２である可能性があり、これは患者固有のリスクスコアの０．２に相当する可能性がある。リスクスコアが０．２の日は通常「良好」に分類されるが、実際のパフカウントの４が３パフのしきい値を超えるため、その日は代わりに「不良」に分類される。

ＩＶ．Ｂ．喘息リスク分析の実装
図６Ｂは、一実施形態による、データ分析モジュール１３１の構成要素を使用して患者の喘息リスクを決定するためのプロセスを示す。データ分析モジュール１３１に格納されたモデル、例えばモデル６４０は、入力として、気象データ、汚染物質データ、患者データ、社会データ、および構築された環境データの組み合わせを受け取る７１０。モデルは、出力として、受け取ったコンテキストパラメータ（つまり、気象データ、汚染物質データ、患者データ、社会データ、および構築された環境データ）に対応する１日に患者が服用した薬剤パフの数の予測を生成するようにトレーニングされる。モデル６４０を使用して、データ分析モジュール１３１は、患者が所与の日に行うだろうと予測されるパフの数を生成する７２０。したがって、予測されるパフの数が多いということは、患者が喘息使用イベントをレスキューする可能性が高くなることを示している可能性がある。モデルの出力は、予測されるパフの数が母集団ベースのしきい値、たとえば、モデルがトレーニングされたデータセットに含まれるユーザの母集団のデータに基づいて決定されたしきい値を超えたかどうかを表すバイナリ値（つまり、「０」または「１」）でもあり得る。

データ分析モジュール１３１は、患者の喘息関連の履歴に基づいて過去のベースラインを決定する７３０。例えば、モジュール１３１は、前の週の予測の価値など、一連の前の日々についてモデルによって生成されたパフ予測に基づいて、過去のベースラインを決定し得る。あるいは、モジュール１３１は、前の期間にわたる患者の実際の薬剤使用（すなわち、患者がそれらの薬剤デバイスを使用した頻度）に基づいて、過去のベースラインを決定し得る。

データ分析モジュール１３１は、当日の予測されたパフの数を過去のベースラインと比較することによって、患者固有のリスクスコアを決定する７４０。いくつかの実施形態では、患者固有のリスクスコアは、０から１の間の範囲の数値である。患者固有のリスクスコアは数値であるが、リスクカテゴリに分類されてもよい。データ分析モジュール１３１は、患者固有のリスクスコアを０から１の間の閾値範囲のセットとさらに比較して、患者固有のリスクスコアを「良好」、「普通」、または「不良」のいずれかに分類し得る７５０。分類は、データ分析モジュール１３１によって、彼らのクライアントデバイスを介して受信された通知として患者に伝達される７６０。彼らの喘息リスクスコアの分類に加えて、通知は、彼らの喘息リスクを改善するための患者向けのオプションの概要を示す推奨事項も含む。

ＩＶ．Ｃ．モデルトレーニング
モデルトレーニングおよび図６Ａおよび６Ｂに関して、モデルは、履歴データに基づいてラベル付けされた前の日々のトレーニングデータセットでトレーニングされ、各前の日は、前の日の間に記録された履歴イベントデータおよび履歴コンテキストデータに基づくラベルに関連付けられる。一実施形態では、トレーニングデータセットの前の日に割り当てられたラベルは、前の日に患者について記録されたパフの実際の数の指示を表す。上記のように、モデル６４０のトレーニング中に、特定の日のパフ予測を決定する際の各パラメータの相対的な重要性を表すコンテキストパラメータ値ごとに、重みが決定される。一実施形態では、パラメータに割り当てられる重みは、０から１の間の範囲の数値であり、０に近い重みは、重要度の低いコンテキストパラメータに割り当てられ、１に近い重みは、より重要なコンテキストパラメータに割り当てられる。所与のテスト日のモデル６４０の実施中に、モデル６４０（トレーニング中に各パラメータに割り当てられた重みを含む）はアクセスされる。各コンテキストパラメータについて、データ分析モジュール１３１は、所与のデータのコンテキストパラメータを特徴付ける測定値にアクセスする。入力値とも呼ばれる、アクセスされた各測定値は、トレーニングされたモデル６４０に入力される。

モデル６４０をトレーニングするために使用されるトレーニングデータセットを作成するために、データ分析モジュール１３１は、アクセスされた履歴データを当日の前の期間（「トレーリングウィンドウ（ｔｒａｉｌｉｎｇ ｗｉｎｄｏｗ）」とも呼ばれる）に集約またはセグメント化し、モデル６４０の様々なコンテキストパラメータの入力値を識別する。前の日々のセットに加えて、トレーリングウィンドウは、当日の環境パラメータも含み得る。たとえば、患者固有のリスクスコアが８日目の午前１０時に計算される場合、トレーリングウィンドウは、環境データ、コントローラ使用情報、１～７日目に関連するレスキュー使用情報、および午前１２：００から午前９：５９までの間の８日目を通して累積的に記録された環境データを含み得る。別の実装では、トレーリングウィンドウは、環境データ、コントローラ使用情報、１～７日目に関連するレスキュー使用情報、および８日目の午前１０時に記録された現在の環境情報を含み得る。例えば、空気の品質や気象データなどの環境情報は、米国海洋大気庁（ＮＯＡＡ）および環境保護庁（ＥＰＡ）の履歴データセットから取得され得る。

別の実施形態では、トレーニングデータセットの各日にバイナリラベル（例えば、「１」または「０」）が割り当てられ、その日に記録されたパフの数が閾値を上回っているか下回っているかを示す。そのような実施形態では、閾値は、特定の患者ではなく、患者の母集団全体に対して設定されるパフの固定数である。上記のように、１つの例示的な実装形態では、閾値は、トレーニングデータセットの各患者について記録されたパフの数の平均として決定される。したがって、バイナリラベルを有する入力を受け取るモデルは、患者が母集団ベースのレスキューパフのしきい値数を超える数のレスキューパフを経験する確率を出力する。

母集団ベースのしきい値は、予測されるパフの数が決定される当日の前の指定された前の期間、もしくは現在または最新のレスキュー使用イベントの時刻の前の期間の間に患者の母集団について記録されたパフの総数に基づいて決定され得る。一実施形態では、閾値は、指定された期間にわたる使用イベントの総数の一部（パーセンテージ）である。しかしながら、他の実施形態では、使用イベントの総数の他の関数を使用して、閾値を決定し得る。

図８は、一実施形態による、トレーニングデータセットを使用してモデル６４０をトレーニングするための方法を示す図である。モデル６４０は、トレーニングサンプル６５０（表の各行）の入力値（表Ａのセル）とそれらのサンプルのラベル（Ｃ）との間の関係を最もよく表すパラメータ値６３０（例えば、各パラメータに関連付けられ、示されていない）を決定することによってトレーニングされる。上で紹介したように、モデル６４０は、ある関数（Ｂ）または別のより複雑な論理構造を使用してトレーニングされる。一実施形態では、モデル６４０は、機械学習技術を使用してトレーニングされ、その例は、限定されないが、線形、ロジスティック、および他の形態の回帰（例えば、弾性ネット）、決定ツリー（例えば、ランダムフォレスト、勾配ブースティング）、サポートベクターマシン、分類器（たとえば、ナイーブベイズ分類器）、ファジーマッチング、およびニューラルネットワークシーケンスモデル（たとえば、長短期記憶リカレントニューラルネットワークおよび時間畳み込みネットワーク）を含む。長短期記憶ネットワークを使用してトレーニングされた例示的なモデル６４０を以下に説明する。

パラメータ値がわかると、モデル６４０は、パラメータ値およびモデルによって指定された関数にアクセスし、パラメータの入力値を入力して、所与の日の患者の予想されるパフの数を生成することによって使用され得る。バイナリラベルが割り当てられた日で構成されるトレーニングデータセットでモデルがトレーニングされる実施形態では、モデル６４０は、パラメータ値およびモデルによって指定された関数にアクセスし、パラメータの入力値を入力して、患者が特定の日にしきい値を超える数のパフを経験する確率を生成することによって使用され得る。

図８の図示の実施形態では、トレーニングデータセット（Ａ）は、直前の７日間の環境および患者のパラメータと、現在の８日目の環境パラメータを記述するデータを含む。８日間のそれぞれの各パラメータは、機械学習モデル（Ｂ）への個別の入力である。したがって、トレーニングセット中の各日、モデル（Ｂ）はラベル（Ｃ）が割り当てられた数値を出力する。特定の日のモデルの出力に割り当てられたラベル（Ｃ）は、予測されるパフの数（つまり、図８に示す２つのパフ）を指定する実際のラベル、もしくは予測されるパフの数が使用回数の閾値を上回っているかまたは下回っているかの確率を指定するバイナリラベルである場合がある。さらに、当技術分野の技術を有する者にとって、図８に示されるパラメータは、潜在的なパラメータの範囲を制限することなく例示的であることを意図していることは明らかであろう。

ＩＶ．Ｄ．入力パラメータ
リスクスコア分析に組み込まれるパラメータは、過去の患者パラメータ、現在の患者パラメータ、大気汚染物質パラメータ、気象パラメータ、およびコンテキストパラメータのいくつかのグループに分類できる。過去および現在の患者パラメータは、より広く、単に「患者パラメータ」として分類され得る。大気汚染物質と気象変数は、より大まかに「環境条件パラメータ」として分類され得る。パラメータの数値は、上記のように、入力値の形式で生成された関数に考慮される。さらに、パラメータから、モデル６４０のパラメータ値が導き出される。

過去の患者の特徴は、これらに限定されないが、一定期間にわたるレスキューイベントの累積患者履歴、レスキューユニットが使用された日の累積カウント、喘息やＣＯＰＤなどの疾患タイプ、夜間に発生したレスキューイベントの記録、およびコントローラ薬剤遵守記録を含み得る。レスキューイベントの患者履歴は、以前のレスキューイベントに関する上記のカテゴリに関連する情報を含み得る。疾患のタイプは、患者の喘息の重症度と彼らの個人的な治療計画を表す。コントローラ薬剤遵守記録は、患者による彼らのコントローラ薬剤の使用についての情報を含む（センサユニット１６０に関連付けられている場合もある）。この決定は、使用法が規定されているが実行されていない場合、使用法が規定されて実行された場合、および使用法が規定されていないが実行された場合を観察することによって評価される。

現在の患者の特徴は、これらに限定されないが、クライアントデバイス１１０の座標の現在の緯度、経度、および位置、ならびに現在の日付を含み得る。現在の緯度と経度は、患者の地理的位置を決定するために使用され、そこから患者の環境条件に関する情報を決定することができる。現在のレスキューイベントデータは、行われたレスキューパフの数と規定された数の差、並びにその日にすでに発生した可能性のあるレスキューイベントのカウント、およびそれらのイベントに関連する情報も含み得る。現在のレスキューイベントデータは、レスキュー使用イベントに関連付けられたタイムスタンプを示す時間データ、たとえば、月、曜日、またはレスキュー使用イベントが発生した日の時間も含み得る。

大気汚染物質の特徴は、濃度に関する情報（たとえば、アナログ値）、または地上、大気中、あるいはその両方の組み合わせでの汚染物質の有無の２値指示を含み得る。考慮される汚染物質の例は、これらに限定されないが、一酸化炭素、オゾン分子、二酸化窒素分子、二酸化硫黄分子、サイズ２．５マイクロメートル以下の粒子状物質、サイズ１０マイクロメートル以下の粒子状物質、および空気品質指数を含む。特定の気象特徴は、気温、湿度、風速、風向、観測所の気圧、視認性を含み得る。

コンテキストパラメータは、患者、患者の生活条件、または環境に関する社会的情報を示す。コンテキストパラメータの例は、これらに限定されないが、社会経済的要因、人口統計学的要因、構築環境要因、土地利用要因、および行動上の健康要因を含む。

いくつかの実施形態では、コンテキストパラメータはまた、患者の行動の傾向または共通性に基づく領域について、社会的傾向およびユーザ行動データ、例えば喘息検索をキャプチャする社会的データを含む。たとえば、ユーザの大部分が喘息治療に関連するＧｏｏｇｌｅ検索または代替のインターネットベースの検索を実行する地域は、喘息レスキュー使用イベントのリスクがより高いことに関連している。別の例として、特定の期間における吸入器レスキューユニットの売上高の急激な増加に関連する地域は、喘息レスキュー使用イベントのリスクがより高いことに関連している可能性がある。したがって、所与の時間におけるある領域のそのような社会的データ（すなわち、社会的傾向およびユーザ行動データ）をモデル６４０に入力して、その時間中に発生する１日の予測されるパフの数を決定し得る。喘息分析システム１００によって記録されるとき、いくつかのパラメータ、例えば、大気汚染物質パラメータ、気象パラメータ、および患者パラメータは、パラメータが記録された日の時間的詳細を示すタイムスタンプに関連付けられる。一実施形態では、タイムスタンプは、パラメータを示す特定の詳細、例えば、時刻、曜日、およびそのタイムスタンプ中に記録された他のパラメータとの関係を含む。代替の実装では、各パラメータは、他のタイムスタンプの間に記録されたパラメータと比較して、パラメータが記録された時間を示す連続したタイムスタンプに関連付けられ得る。

前述のすべての大気汚染物質の特徴、気象の特徴、および現在の患者の特徴のうち、モデル６５０は、患者のリスクスコアを決定するときに考慮されるべき特定の特徴を選択し得る。特定の特徴を組み合わせて、より大きな予測値を提供する集約特徴にし得る。例えば、緯度および経度のデータは、クライアントデバイス１１０の気候地域、州、または都市を示す情報として解釈され得る。他の実施形態では、クライアントデバイス１１０の現在の位置を、関心のあるポイントの位置（すなわち、ユーザまたは医療提供者に関連すると決定された位置または領域）と比較して、現在の位置から関心のあるポイントに移動するために必要な距離を決定し得る。モデル６５０によって選択された特徴の特定の組み合わせは、トレーニング期間中に調整されるか、または期間にわたって繰り返し更新され得る。

ＩＶ．Ｅ．長短期記憶（ＬＳＴＭ）ネットワークの例
レスキュー使用イベントのリスクは、現在のコンテキストデータに依存するだけでなく、以前に発生したコンテキストデータにある程度関連する可能性があるため、モデル６４０のいくつかの実施形態はそのような時間的要素を反映する。そのような一実施形態では、モデル６４０は、長短期記憶（ＬＳＴＭ）ネットワークである。リカレントニューラルネットワークのサブクラスである長短期記憶ネットワークは、入力データ配列の各タイムステップを順次処理するＬＳＴＭセルを使用することにより、上記のデータの時間的性質を考慮に入れることができる。ＬＳＴＭセル自体は、さまざまな方法で対話して２つの中間出力ベクトル、非表示状態およびセル状態、を生成するために多数の隠しレイヤーまたは「ゲート」を含む。最終的なリスクスコアの生成に関連する潜在情報を永続化するように設計されたこれらの２つの中間出力ベクトルは、入力データの次のタイムステップとともにセルに入力される。入力データの最後のタイムステップの後、セルの最終的な隠し状態が次いで、ＬＳＴＭネットワークの残りの部分に出力され、これは、出力として最終的なリスクスコアを生成する１つ以上のレイヤーで構成される。

ネットワーク内の各レイヤーはノードを含み、各ノードは前のレイヤーの入力データまたは中間出力のいずれかで関数を実行する。この関数は典型的に、トレーニング可能な重みおよび非線形活性化関数を使用した乗算を含む。適切なコスト関数で勾配降下法のバリエーションを使用すると、各バッチサンプルの後に重みを適宜更新するために、エラーがネットワークを介しておよびセルの各タイムステップを介して伝播される可能性がある。

例示的なモデルは、ベクトルサイズ１２８の隠し状態およびセル状態を含み、７日間の時間データ、過去のコンテキストデータ、および過去の患者データが、密な層の後に０．３のドロップアウト率で渡される。サンプルモデルは、学習率＝０．００１、ｂｅｔａ＿１＝０．９、およびｂｅｔａ＿２＝０．９９９であるＡｄａｍオプティマイザを使用して、バイナリクロスエントロピーコスト関数でトレーニングすることができる。別の実施形態では、モデルの最適なアーキテクチャは、モデルが新しい時間データを受信するたびに定期的に更新される。このようなアーキテクチャおよびハイパーパラメータの更新は、Ａｍａｚｏｎ Ｗｅｂ ＳｅｒｖｉｃｅｓのＳａｇｅＭａｋｅｒ製品によって実装されたベイズ最適化ツールを使用して実行され得る。

モデル６４０がＬＳＴＭである実施形態では、データ分析モジュール１３１は、ある期間にわたって記録された患者データにアクセスする。アクセスされた患者データは、個々のタイムステップにさらにソートし得、各タイムステップはレスキュー吸入器の使用イベントを表す。データ分析モジュール１３１は、各レスキュー吸入器使用イベントの患者データ（少なくとも患者パラメータ、気象パラメータ、大気汚染物質パラメータを含む）を特徴ベクトル（以下、パラメータベクトルと呼ぶ）にエンコードする。パラメータベクトルの特徴値はそれぞれ、レスキュー吸入器使用イベント時に記録された患者パラメータ、気象パラメータ、または大気汚染物質パラメータの値を表す。レスキュー吸入器使用イベントが検出された時間は、以後「タイムステップ」と呼ばれることがある。いくつかの実施形態では、レスキュー吸入器使用イベントが検出される各インスタンスの間に、毎日または毎時のタイムスタンプが記録され得る。

各パラメータベクトルは、別個のタイムステップで測定されたパラメータ値のエンコードされた表現であるため、データ分析モジュール６４０は、各パラメータベクトルをモデルに繰り返し入力する。モデル６４０は、タイムステップにわたって記録されたパラメータ値をエンコードするパラメータベクトルおよび前のタイムステップについて決定された中間出力ベクトルに基づいて、ある期間にわたって発生する各タイムステップの中間出力ベクトルを繰り返し更新する。例示的な例として、第１のタイムステップＴ１において、モデル６４０は、Ｔ１で記録されたパラメータ値を表すパラメータベクトルＰ１を入力として受け取り、中間出力ベクトルＩ１を出力する。第２のタイムステップＴ２において、モデル６４０は、Ｔ２で記録されたパラメータ値を表すパラメータベクトルＰ２および中間出力ベクトルＩ１を入力として受け取り、更新された中間出力ベクトルＩ２を出力する。したがって、モデル６４０は、現在のタイムステップに先行するタイムステップのパラメータベクトルを繰り返し受信して、現在のタイムステップに至る期間にわたって発生するレスキュー吸入器使用イベントに関連するパラメータ値のシーケンスの潜在的表現を提供する最終出力ベクトルを生成する（たとえば、現在の出力ベクトル）。現在の出力ベクトルは、現在のタイムステップでの患者のリスクスコアを決定するために、パーソナライズ化されたリスクモジュール６５０に入力される。

ＩＶ．Ｆ．喘息レスキューイベントリスク通知
通知モジュール６４５は、分類、患者固有のリスクスコア、予測されるパフの数、リスクスコアおよび予測されるパフの数の潜在的な原因、ならびに患者がこれらの状況下で別のレスキュー使用イベントの発生を防ぐために取ることができるオプションのいずれか１つまたは複数を含むリスクスコア通知を生成する４３５。上で論じたように、アプリケーションサーバ１３０は、患者１１１、彼らの医療提供者１１２、および／または他の許可された個人のうちの１つまたは複数に対してリスクスコア通知を生成する４３５。

リスク通知は、リスクスコア、分類、およびモデル６４０の任意のパラメータからの任意の入力値を含む、多種多様な情報コンテンツを含み得る。

リスク通知は、リスク分類の変更の原因となるパラメータに基づいて、将来のレスキュー吸入器イベントを防止する方法に関する推奨事項で構成されている場合もある。たとえば、推奨事項は、遵守スケジュールをより厳密に守る、コントローラ薬剤の投与量または使用量を増やす、その地理的地域を完全に回避する、または同様の環境条件の地域への曝露を制限することを含む場合がある。

さらに、患者１１１には、昨年発生したすべての投薬レスキューイベントの場所のピンポイントを含む地理的マップが提供される場合がある。別の例として、患者１１１には、イベント４１０が発生した場所と、その日またはしきい値期間内に近くの地理的領域で発生したすべての投薬レスキューイベントのピンポイントを含む地理的マップが提供され、その地域の投薬レスキューイベントの最近のパターンを示し得る。別の例として、患者１１１の医療提供者１１２は、提供者１１２が薬物レスキューイベントの傾向を特定するのを助けるために、その日または最近の期間から患者１１１からの薬物レスキューイベントデータを提示され得る。

リスク通知は、実装に応じてトリガ条件に基づく可能性がある、または他のメカニズムに従ってクライアントデバイスに送信される可能性がある他の多くの状況でも配信される可能性がある。たとえば、患者のパラメータの変化（たとえば、低下した患者コントローラ薬剤遵守）または環境状態のパラメータ（たとえば、低濃度のオゾン、空気中の汚染物質の量の増加、または湿度の上昇）によって患者の現在の状態が悪化した場合、更新されたリスク通知が患者１１１に配信される。上記のように、別の実装では、患者固有のリスクスコアが増加したとき、またはリスクスコアが例えば「普通」から「不良」に再分類されたときに、リスク通知が患者に提示され得る。追加の実装では、患者固有のリスクスコアまたは分類の通知が医療提供者に提示されて、人員配置、医療用品を通知するか、または診療所または患者のグループの病状を説明し得る。あるいは、同様の変化により患者の現在の状態が改善した場合、更新されたリスク通知が配信される場合もある。リスク通知は、たとえば、サードパーティのデバイス（例えば、ＧｏｏｇｌｅＨｏｍｅ（登録商標）やＡｍａｚｏｎＡｌｅｘａ（登録商標））からの局所喘息状態の口頭での要求により、患者の要求に応じて配信される場合もある。

上記のように、一般にリスク通知はクライアントデバイス１１０を介して配信されるが、他の実施形態では、状態が改善または悪化した場合、リスク通知が、ＳＭＳ通知、電子メール通知、局所喘息状態を有する埋め込み可能ウィジェットからの通知、またはさまざまなＩＦＴＴＴアプレット（ｈｔｔｐｓ：／／ｉｆｔｔｔ．ｃｏｍ／）からの通知として配信され得る。

Ｖ．例
Ｖ．Ａ．例１
図７Ａは、目に見えない、前向きなテストセットでの受信者動作特性曲線の例を示している。ＬＳＴＭネットワークを実装するベースラインモデル６５０は、受信者動作特性曲線の下の０．９０の領域を達成し、それによってＬＳＴＭ実装モデルの有効性を確認した。

Ｖ．Ｂ．例２
図７Ｂは、見えない前向きなテストセットの適合率－再現率曲線の例を示している。ＬＳＴＭネットワークを実装するベースラインモデル６５０は、受信者動作特性曲線の下の０．７２の領域を達成し、それによってＬＳＴＭ実装モデルの有効性を確認した。

ＶＩ．利点
患者１１１および提供者１１２に提供される喘息レスキューイベントリスク通知は、多くの利点を伝える。患者は、喘息レスキューイベントのリスクをリアルタイムまたはほぼリアルタイム（数秒から数分程度）で通知され、たとえば、コントローラ投薬への順守を改善すること、悪条件（例、大気汚染濃度）のある地域から離れること、処方された投薬計画を追加または変更すること（投与量の調整、もしくは抗生物質または全身性コルチコステロイドの導入など）、またはレスキュー薬剤の使用における最近の急増に対処するために医師との約束をスケジュールすることで、患者の緊急治療室や病院への訪問の頻度を減らすことによって、その発生を防ぐための措置を講じることができる。イベントデータは、患者の入力を必要とせずにアプリケーションサーバ１３０に自動的に報告されるので、イベントデータの精度および品質は、医療提供者１１２または他のエンティティによって手動で収集されたデータと比較して改善され、したがって、喘息レスキューイベントのリスクに関する結果も改善される。

さらに、他の患者による近くのレスキュー投薬イベントの報告を含む、アプリケーションサーバ１３０によって提供されるフォローアップ通知は、同様の問題に苦しんでいる他の人に関する追加情報を患者に提供し、患者の意思決定に関する地域情報を提供することができる。フォローアップ通知は、服薬遵守の進捗に関してユーザをさらに励ますことができる。理想的には、そのような通知は、喘息レスキューイベントの発生を防ぎ、したがって患者への危害、ならびに病院への訪問およびそれらに関連する費用を防ぐだろう。

１つまたは複数の患者の喘息レスキューイベントのリスクを知らされた医療提供者は、同様に患者の進捗を追跡し、その情報を使用して各患者の治療計画を更新したり、患者との予約をスケジュールしたりできる。喘息レスキューイベントのリスクが高い患者の場合、通知は、医療提供者が患者と連絡を取り、治療を求めるように彼らを促すための行動の呼びかけである可能性がある。フォローアップ通知は、地域の影響（例えば、汚染）、患者コントローラ服薬遵守などに関する情報を提供し得る。

ＶＩＩ．追加の検討事項
上記の説明は特に喘息に焦点を当てているが、本明細書で説明するすべてのシステムおよびプロセスは、慢性閉塞性肺疾患（ＣＯＰＤ）および慢性呼吸器疾患（ＣＲＤ）に等しく適用可能であり、その結果、喘息と同様に、ＣＯＰＤおよびＣＲＤの治療を支援するためにも使用できる。

本開示の図および説明は、明確にするために、典型的なシステムに見られる他の多くの要素を排除しながら、本開示の明確な理解に関連する要素を説明するために簡略化されていることを理解されたい。当業者は、本開示を実施する際に他の要素および／またはステップが望ましいおよび／または必要であることを認識し得る。しかしながら、かかる要素もしくはステップは、当技術分野では周知であるため、および本開示のより良い理解を容易にしないため、かかる要素およびステップの議論を本明細書では提供しない。本明細書の開示は、当業者に知られているそのような要素および方法に対するそのようなすべての変形および修正を対象とする。

上記説明のある部分は、情報に対する演算のアルゴリズムおよび記号表現の観点から、実施形態を説明している。これらのアルゴリズムの説明および表現は、データ処理技術における当業者によって一般的に用いられ、彼らの仕事の趣旨を効果的に他の当業者に伝える。これらの演算は、機能的、計算的、または論理的に説明されている一方で、コンピュータプログラム、または等価電気回路、マイクロコードなどによって実装されると理解される。さらに、普遍性を消失することなく、時にはこれらの演算の配置をモジュールと称すると便利であることが分かる。説明される演算およびそれらに関連するモジュールは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせで具現化されてよい。

本明細書で用いられるように、「一実施形態」、または「実施形態」への参照は、この実施形態に関連して説明される具体的な要素、特性、構造、または特徴が少なくとも１つの実施形態において含まれることを意味する。本明細書におけるさまざまな場所において、「一実施形態において」という表現の説明は、必ずしもすべてが同一の実施形態を参照しているわけではない。

本明細書で用いられるように、「備える」、「備えている」、「含む」、「含んでいる」、「有する」、「有している」、またはそれらの任意の他の変形例は、非排他的な包含を含むことが意図されている。例えば、要素のリストを備えるプロセス、方法、条項、もしくは装置は、必ずしもそれらの要素のみに限定されるのではなく、そのようなプロセス、方法、条項、もしくは装置に明示的に記載されていない、または内在する他の要素を含む場合がある。さらに、そうではないと明示的に述べられていない限り、「または」は、包括的な「または」を参照し、排他的な「または」を参照しない。例えば、条件ＡまたはＢは、以下のいずれか１つによって満たされ、Ａは真（または存在する）でありかつＢは偽（または存在しない）であり、Ａは偽（または存在しない）でありかつＢは真（または存在する）であり、ならびにＡおよびＢの両方が真（または存在する）である。

さらに、「ａ」または「ａｎ」の使用は、本明細書における実施形態の要素およびコンポーネントを説明するために採用される。これは、単に便宜上、および本発明の一般的な意味を付与するために行われているに過ぎない。本説明は、１つまたは少なくとも１つを含み、また、そうでないことを意味することが明らかでない限り、単数形が複数形を含むように読まれるべきである。

特定の実施形態およびアプリケーションが例示され、且つ説明されてきたが、開示される実施形態は、本明細書で開示される厳密な構造およびコンポーネントに限定されないことを理解されたい。当業者にとって明らかになることとなるさまざまな修正、変化、および変形は、添付の特許請求の範囲において定義される趣旨および範囲から逸脱せずに、本明細書で開示される方法および装置の配置、動作および詳細において行われ得る。

Claims (21)

1. 患者について、ある期間にわたって発生するタイムステップに対応するパラメータベクトルのシーケンスにアクセスすることであって、前記シーケンスの各パラメータベクトルは、レスキュー吸入器使用イベント中の薬剤デバイスセンサによって記録された、少なくとも１つの患者パラメータ、気象パラメータ、および大気汚染物質パラメータを記述する値のセットを含み、前記薬剤デバイスセンサは、レスキュー吸入器ユニットに取り外し可能に取り付けられ、前記レスキュー吸入器ユニットが前記患者にレスキュー薬剤を投薬するときに前記レスキュー吸入器ユニットの薬剤使用を監視するように構成されていることと、
   機械学習モデルにパラメータベクトルの前記シーケンスを入力することにより、前記ある期間に発生するレスキュー吸入器使用イベントに関連するパラメータ値の前記シーケンスの潜在表現を提供する現在の出力ベクトルを生成することであって、前記機械学習モデルは、
   対応するパラメータベクトルに基づいて前記ある期間に発生する各タイムステップの出力ベクトルを繰り返し更新し、現在のタイムステップの前記パラメータベクトルに基づいて前記現在のタイムスタンプでの前記現在の出力ベクトルを生成し、出力ベクトルは、前記現在のタイムステップの直前のタイムステップに対して計算され、
   前記現在の出力ベクトルに基づいて、前記現在のタイムステップのレスキュー吸入器使用イベントの予測数を決定する、ようにトレーニングされていることと、
   薬剤使用イベントの前記予測された数を関数に入力し、前記現在のタイムステップのリスクスコアを決定することと、
   前記患者によって操作されたクライアントデバイスに、前記現在のタイムステップに対して決定された前記リスクスコアを示すリスク通知を送信することと
   を含む方法。
2. 過去の期間にわたる前記患者による薬剤使用の毎日の記録に基づいて過去のベースラインを決定することと、
   レスキュー吸入器使用イベントの前記予測数を関数に入力することであって、前記関数は、前記現在のタイムステップのレスキュー吸入器使用イベントの前記予測数を前記過去のベースラインと比較することと、
   前記比較に基づいて前記現在のタイムステップの前記リスクスコアを決定することと
   をさらに含む、請求項１に記載の方法。
3. 過去の期間に発生した記録されたレスキュー吸入器使用イベントの標準偏差に基づいて、過去のベースラインを決定することと、
   レスキュー吸入器使用イベントの前記予測数を前記関数に入力することであって、前記関数は、前記現在のタイムステップのレスキュー吸入器使用イベントの前記予測数を前記過去のベースラインと比較することと、
   前記比較に基づいて前記現在のタイムステップの前記リスクスコアを決定することと
   をさらに含む、請求項１に記載の方法。
4. 前記クライアントデバイス、薬剤デバイスセンサ、またはレスキュー吸入器ユニットから、前記ある期間に発生したレスキュー吸入器使用イベントの記録を受信することをさらに含む、請求項１に記載の方法。
5. 前記現在の出力ベクトルを前記関数に入力して、トリガ条件に応じた前記現在のタイムステップのリスクスコアを決定することであって、前記トリガ条件は、
   前記クライアントデバイスの物理的な場所の変更、
   前記ある期間の終了、
   少なくとも１つの患者パラメータ、気象パラメータ、および大気汚染物質パラメータの値の変更、および、
   前記レスキュー吸入器ユニットが前記現在のタイムステップ中に前記患者にレスキュー薬剤を投薬するときに検出される、前記現在のタイムステップ中のレスキュー吸入器使用イベントの発生
   のうちの１つまたは複数であることをさらに含む、請求項１に記載の方法。
6. 前記機械学習モデルが長短期記憶ニューラルネットワークである、請求項１に記載の方法。
7. 前記リスクスコアは、前記患者が前記現在のタイムステップ中にレスキュー吸入器使用イベントを経験する可能性を表す数値である、請求項１に記載の方法。
8. 前記値のセットが、少なくとも１つのイベントデータパラメータおよび少なくとも１つのコンテキストデータパラメータをさらに含む、請求項１に記載の方法。
9. 前記値のセットが、
   レスキューイベントの累積的な患者の病歴、
   夜間に発生するイベントの患者の病歴、
   前記レスキューユニットを使用した日の累積カウント、
   疾患のタイプ、および、
   遵守記録をさらに含む、
   少なくとも１つの過去の患者パラメータの１つまたは複数を含む、請求項１に記載の方法。
10. 前記値のセットが、
    前記クライアントデバイスの現在の緯度および経度の座標、
    現在の場所、
    現在の日付、および、
    前記レスキューイベントのために行われ、規定されたレスキューパフの数の違いをさらに含む、
    少なくとも１つの現在の患者パラメータの１つまたは複数を含む、請求項１に記載の方法。
11. 前記値のセットが、
    オゾン分子（Ｏ₃）、
    一酸化炭素分子（ＣＯ）、
    二酸化窒素分子（ＮＯ₂）、
    二酸化硫黄分子（ＳＯ₂）、
    ２．５マイクロメートル以下の粒子状物質（ＰＭ_2.5）、
    １マイクロメートル以下の粒子状物質（ＰＭ_1.0）、および、
    空気品質指標（ＡＱＩ）をさらに含む、
    少なくとも１つの大気汚染物質パラメータの１つまたは複数を含む、請求項１に記載の方法。
12. 前記値のセットが、
    温度、
    湿度、
    風速、
    風向、
    観測所の気圧、および、
    視認性をさらに含む、
    少なくとも１つの気象パラメータの１つまたは複数を含む、請求項１に記載の方法。
13. 前記値のセットが、
    地理的地域の社会的パラメータ、および、
    地理的地域の行動パラメータ
    の１つまたは複数を含む、請求項１に記載の方法。
14. 前記値のセットが、前記レスキュー吸入器ユニットの外部のコンピューティングシステムによってレスキュー吸入器使用イベントが監視される日数を含む、請求項１に記載の方法。
15. 前記関数は、所与の日のレスキュー吸入器使用イベントの数が閾値を超えたかどうかを決定する、請求項１に記載の方法。
16. 前記リスク通知は、前記リスクスコアが決定される前記現在のタイムステップに続くタイムステップで提示される、請求項１に記載の方法。
17. 前記リスク通知は、トリガ条件に関する情報内容を含む、請求項１に記載の方法。
18. 前記リスク通知が、
    前記ある期間に発生したレスキュー吸入器使用イベントの記録、
    前記リスクスコアが比較された閾値、および、
    前記リスクスコアに基づくリスク分類
    の少なくとも１つに関する情報内容を含む、請求項１に記載の方法。
19. 前記リスク通知が、前記レスキュー吸入器使用イベントに関する情報内容をさらに含み、前記情報内容が、前の期間と比較されるリスク分類の変化に関与する患者パラメータ、気象パラメータ、および大気汚染物質パラメータのサブセットをさらに含む、請求項１に記載の方法。
20. 前記リスク通知は、前記レスキュー吸入器使用イベントに関する情報内容をさらに含み、前記情報内容は、リスク分類の前記変化に関与する患者パラメータ、気象パラメータ、および大気汚染物質パラメータの前記サブセットに基づいて、将来のレスキュー吸入器使用イベントを防止する方法に関する推奨事項をさらに含む、請求項１に記載の方法。
21. 非一時的なコンピュータ可読記憶媒体であって、コンピュータプロセッサによって実行されると、
    患者について、ある期間にわたって発生するタイムステップに対応するパラメータベクトルのシーケンスにアクセスすることであって、前記シーケンスの各パラメータベクトルは、レスキュー吸入器使用イベント中の薬剤デバイスセンサによって記録された、少なくとも１つの患者パラメータ、気象パラメータ、および大気汚染物質パラメータを記述する値のセットを含み、前記薬剤デバイスセンサは、レスキュー吸入器ユニットに取り外し可能に取り付けられ、前記レスキュー吸入器ユニットが前記患者にレスキュー薬剤を投薬するときに前記レスキュー吸入器ユニットの薬剤使用を監視するように構成されていることと、
    機械学習モデルにパラメータベクトルの前記シーケンスを入力することにより、前記ある期間に発生するレスキュー吸入器使用イベントに関連するパラメータ値の前記シーケンスの潜在表現を提供する現在の出力ベクトルを生成することであって、前記機械学習モデルは、
    対応するパラメータベクトルに基づいて前記ある期間に発生する各タイムステップの出力ベクトルを繰り返し更新し、現在のタイムステップの前記パラメータベクトルに基づいて前記現在のタイムスタンプでの前記現在の出力ベクトルを生成し、出力ベクトルは、前記現在のタイムステップの直前のタイムステップに対して計算され、
    前記現在の出力ベクトルに基づいて、前記現在のタイムステップのレスキュー吸入器使用イベントの予測数を決定する、ようにトレーニングされていることと、
    薬剤使用イベントの前記予測された数を関数に入力し、前記現在のタイムステップのリスクスコアを決定することと、
    前記患者によって操作されたクライアントデバイスに、前記現在のタイムステップに対して決定された前記リスクスコアを示すリスク通知を送信することと
    をプロセッサに行わせるコンピュータプログラム命令を含む、非一時的なコンピュータ可読記憶媒体。

Images