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

Description

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

喘息は、依然として重要かつ費用のかかる公衆衛生上の問題である。世界的に、世界保健機関は、喘息を患う人口は3億人になり得ると推定し、その人口は2025年までに4億人に増えると予測している。合衆国では、喘息は、合衆国の12人に1人におよび、患者数は上昇傾向にあり、年間560億ドルを超える医療利用コストの原因となっている。

新しい薬の開発にもかかわらず、入院および緊急治療室の訪問率は下がっていない。合衆国では毎年、この疾患は、およそ200万人の救急外来訪問、50万件の入院、および5,000人の死亡を引き起こしている。加えて、喘息は、推定で1500万休校日数、および1200万欠勤日数の原因となっている。合衆国の医療保険会社および医療保険雇用主に対する総年間コストは、180億ドルを上回る。

これらの悪化の大部分は、現在利用可能な治療で防ぐことが可能であるが、喘息患者の5人に1人のみがこの疾患を管理している。新たに改正された国の指針は、治療が日々の症状を管理しているかどうか、また生活の質を改善しているかどうかをさらに注意深く監視するように医師に要請している。しかしながら、内科医には、その患者が日々どの程度調子よく過ごしているかを評価する利用可能なツールがほとんどない。患者を監視し、その管理レベルを決定するために、ますます多くの内科医が、周期的な記述式質問票(喘息管理テストなど)を使用し始めた。これらの手段は、患者が症状の頻度、吸入器の利用、および活動レベルを正確に想起して報告すること、ならびに一定の時間期間(通常、2週間から4週間)にわたる制約を必要とする。結果として、これらの質問票は、偏った判断(想起)、症状の異なる解釈、および行動(非アドヒアランス(non-adherence))によってもたらされるエラーが生じやすく、これらの質問票が使用される時点のみの情報を提供する。

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

米国特許出願第12/348,424号 国際出願第PCT/US2014/039014号

http://xgboost.readthedocs.io/en/latest/python/python_api.html

喘息解析システムは、喘息によって生じるレスキューイベントを治療し、監視し、管理するための統合プラットフォームである。喘息解析システムは、喘息解析システムをその喘息の管理に役立てることを許可した患者によって使用される薬剤デバイス(たとえば、吸入器)にアタッチされたセンサからイベント通知を受信することによって、喘息レスキュー薬イベントを追跡する。センサは、定服用量(dose)吸入器または他の薬剤デバイスにアタッチされるかまたはその中に統合されるとき、レスキュー利用イベントの地理的位置、時間、および日付を記録し、その情報を喘息解析システムに通信する。喘息解析システムは、受信イベント(最近の受信イベントと前の受信イベントの両方)をリアルタイムまたはニアリアルタイムで分析し、リスク評価、および疾患を指導し管理するための情報を通知の形で患者および医療提供者に配信する。

リスクスコアは、患者の医療歴、患者の日々の現状、ならびに大気条件および気象条件に関する環境条件を含むパラメータの組合せを用いて決定される。これらのパラメータと患者に関して生成されたリスク評価との間の関係は、機械学習モデル内に埋め込まれる。モデル、および、より一般的に、システムは、パラメータに関する入力値を受信し、リスクを緩和するための正確かつ医療的に関連する治療オプションとともにリスク評価を提供するために、患者のリスクスコアを分類(categorizing)することが可能である。

他のコンテキスト的に関連するパラメータ情報とともに、薬の利用のタイミング、頻度、および位置に関する情報を取り込むことによって、喘息解析システムは、それらの予測イベントに先立って、行動または環境において直ちに適用可能な変更を示唆することによって、将来の喘息レスキュー利用イベントの発生を防ぐのに役立つ。これは、患者およびその医療提供者による喘息治療のよりよい管理を促し、患者が将来これらの位置を回避するかまたは対応することができるように、レスキューイベントを引き起こす特定の位置の認識を改善する。

ある実施形態によれば、患者の喘息関連レスキューイベントのリスクを決定するための方法は、一組の患者に関する過去のレスキュー吸入器利用イベントにアクセスするステップを含む。一組のイベントは、クライアントデバイスもしくはレスキュー吸入器ユニットに関連するアタッチメントから、または各イベントの一部としてレスキュー薬を患者に提供したレスキュー吸入器ユニットから前に受信されている。この方法は、一組のイベントに基づいて、患者固有のベースラインリスクしきい値を決定するステップをやはり含む。トリガ条件に応じて、この方法は、喘息リスクを予測するためのモデルのための一組のパラメータ値にアクセスするステップと、一組の入力値にアクセスするステップとを含む。やはりトリガ条件に応じて、この方法は、パラメータ値、入力値、およびベースラインリスクしきい値を、リスクスコアを決定するための関数に入力するステップを含む。トリガ条件に応じて、この方法は、リスクスコアの詳細を備えた通知をデバイスに送信するステップを含む。

1つまたは複数の実施形態では、この方法は、レスキュー吸入器利用イベントの履歴をクライアントデバイス、アタッチメント、またはレスキュー吸入器ユニットから受信するステップをやはり含む。

1つまたは複数の実施形態では、しきい値は、現在の時刻に先行する時間窓からのイベントを含む前の期間に対して決定される。

1つまたは複数の実施形態では、しきい値は、前の期間内のイベントの総和の割合として決定される。

1つまたは複数の実施形態では、しきい値は周期的に決定される。

1つまたは複数の実施形態では、トリガ条件は、クライアントデバイスの物理的位置のしきい値変更を含む。

1つまたは複数の実施形態では、トリガ条件は、時間間隔の周期的結論を含む。

1つまたは複数の実施形態では、トリガ条件は、複数のパラメータのうちの少なくとも1つの入力値のしきい値変更を含む。

1つまたは複数の実施形態では、トリガ条件は、クライアントデバイス、アタッチメント、または現在のレスキュー吸入器利用イベントの一部としてレスキュー薬を患者に提供したレスキュー吸入器から受信される、現在のイベントの発生を含む。

1つまたは複数の実施形態では、パラメータ値は、ブーストされた勾配モデル(boosted gradient model)を用いて決定される。

1つまたは複数の実施形態では、リスクスコアは、患者がその日にしきい値を超えることになる可能性を表す数値価である。

1つまたは複数の実施形態では、パラメータは、少なくとも1つのイベントデータパラメータおよび少なくとも1つのコンテキストデータパラメータを含む。

1つまたは複数の実施形態では、パラメータは、レスキューイベントの累積患者履歴、夜間に発生するイベントの患者履歴、レスキューユニットを使用した日の累積カウント、疾患タイプ、およびアドヒアランス記録をさらに含む、少なくとも1つの過去の患者パラメータを含む。

1つまたは複数の実施形態では、パラメータは、クライアントデバイスの現在の経度および緯度座標、現在の位置、現在の日付、およびレスキューイベントに対して服用され、処方されたレスキューパフ(rescue puffs)の数の差異をさらに含む、少なくとも1つの現在の患者パラメータを含む。

1つまたは複数の実施形態では、パラメータは、オゾン分子、二酸化窒素分子、二酸化硫黄分子、2.5マイクロメートル以下の粒子物質、1マイクロメートル以下の粒子物質、および大気質指数をさらに含む、少なくとも1つの大気汚染物質パラメータを含む。

1つまたは複数の実施形態では、パラメータは、温度、湿度、風速、風向、現地気圧、および視程をさらに含む、少なくとも1つの気象パラメータを含む。

1つまたは複数の実施形態では、パラメータは、温度、相対湿度、風速パラメータ、二酸化窒素(NO₂)、二酸化硫黄(SO₂)、2.5マイクロメートル以下の粒子物質(PM_2.5)、および1マイクロメートル以下の粒子物質(PM_1.0)のうちの1つまたは複数を含む。

1つまたは複数の実施形態では、パラメータは、レスキュー吸入器利用イベントがレスキュー吸入器ユニットの外部のコンピューティングシステムによって監視される日数を含む。

1つまたは複数の実施形態では、この関数は、所与の日付に対するレスキュー吸入器利用イベントの数がしきい値を超えるかどうかを決定する。

1つまたは複数の実施形態では、リスク通知は、リスクしきい値が決定される第2の時間とは異なる第1の時間に提示される。

1つまたは複数の実施形態では、リスク通知は、トリガ条件に関する情報コンテンツを含む。

1つまたは複数の実施形態では、リスク通知は、イベント、ベースラインリスクしきい値、およびリスクスコアに基づくリスク分類のうちの少なくとも1つに関する情報コンテンツを含む。

1つまたは複数の実施形態では、リスク通知は、レスキューイベントに関する情報コンテンツをさらに含み、情報コンテンツは、前の時間期間と比較したリスク分類の変更の原因となるパラメータのサブセットをさらに含む。

1つまたは複数の実施形態では、リスク通知は、レスキューイベントに関する情報コンテンツをさらに含み、情報コンテンツは、さらなるレスキュー吸入器イベントをどのように防ぐかに関する推奨をさらに含み、推奨は、リスク分類の変更の原因となるパラメータのサブセットに基づく。

一実施形態による、正確なリアルタイム薬剤デバイス使用を監視し、そのデータに対して解析を実行し、喘息レスキューイベントリスク通知を提供するための喘息解析システムを示す図である。 一実施形態による、クライアントデバイス、アプリケーションサーバ、および/またはデータベースサーバのいずれかの中で使用されるコンピューティングデバイスの一例を示すハイレベルブロック図である。 一実施形態による、ユーザが喘息解析システムと対話することを可能にするクライアントアプリケーションのダッシュボードを示す図である。 一実施形態による、クライアントアプリケーションのダッシュボード内に表示される1つの例示的なカードを示す図である。 一実施形態による、薬剤デバイス監視に基づいて喘息リスクベースの通知を提供するための対話図である。 一実施形態による、喘息解析システムによってレスキュー薬イベントを検出するためのフローチャートである。 一実施形態による、喘息リスクスコアモジュール内のモジュールを示すブロック図である。 一実施形態による、喘息リスクスコアモジュールによって実装されるトレーニングモジュールを示すブロック図である。 一実施形態による、トレーニングデータセットを用いてモデルをトレーニングするための方法を示す図である。 一実施形態による、リスク識別のためのしきい値を確立する方法を示す図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。 一実施形態による、喘息リスク分析をテストするために使用されるデータを特徴付けて分析する図である。

図は、単に例示のために、提示される発明の様々な実施形態を示す。本明細書で説明する原理から逸脱せずに、本明細書で示す構造および方法の他の実施形態が採用され得ることを当業者は以下の議論から容易に認識されよう。

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

喘息解析システムは、クライアントコンピューティングデバイス110と、薬剤デバイスセンサ120と、薬剤デバイス160と、アプリケーションサーバ130と、データベースサーバ140と、ネットワーク150とを含む。図1は、喘息解析システム100の構成要素の大部分の単一の事例のみを示すが、実際には、各構成要素の2つ以上が存在し得、追加のまたはより少数の構成要素が使用され得る。

I.A.クライアントデバイスおよびアプリケーション
クライアントデバイス110は、そのユーザの指示で、ネットワーク150を介して喘息解析システム100と対話する。説明および明快のために、少なくとも2つの異なるタイプのユーザを識別することが有用である。患者111は、少なくとも部分的に、サーバ130によって提供される、個人化された喘息レスキューイベントリスク通知、およびその医療提供者112によって作成される喘息管理通知を取得するために喘息解析システム100を使用する、喘息を患うユーザである。そのような通知は、喘息解析システム100が患者111の薬剤デバイス160利用を監視することを可能にするためのユーザの許可と引き換えに提供され得る。下記で説明するように、薬イベントは、薬剤デバイス160およびユーザのクライアントデバイス110に関連付けられたセンサ120によって検出され、センサ120は、次に、アプリケーションサーバ130に報告し、アプリケーションサーバ130は、次に、クライアントデバイス110を通じてユーザに提供されるリスク通知を生成するためのプロセスを開始し得る。

もう1つのタイプのユーザは、この場合も、患者111の特別許可で、患者の喘息管理に関する通知、ならびにアグリゲート喘息コミュニティレスキューイベントデータ、および喘息イベントに関して導出された統計、および他の関連データをやはり受信する、医療提供者112である。その独自のクライアントデバイス110がその子のクライアントデバイス110とは異なる場合にやはり通知を受信することを望む場合がある、患者111の親/保護など、他のタイプのユーザも企図される。

クライアントデバイス110は、コンピュータシステムである。1つの例示的な物理的実装形態について、図2に関して下記でより十分に説明する。クライアントデバイス110は、ネットワーク150を介して喘息解析システム100とワイヤレスに通信するように構成される。ネットワーク150アクセスにより、クライアントデバイス110は、ユーザの地理的位置およびレスキュー薬イベントの時間、ならびに関連する薬剤デバイスセンサ120(本明細書を通して「センサ120」と呼ばれる)から受信される、イベントを説明する情報をシステム100に送信する。

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

アプリケーションサーバ130との通信に加えて、喘息解析システム100にワイヤレスに接続されたクライアントデバイス110は、接続された他のクライアントデバイス110と情報を交換することもできる。たとえば、クライアントソフトウェアアプリケーション115を通して、医療提供者112は、患者111に関する最近のレスキューイベントを説明するリスク悪化通知を受信し、次いで、それに応じて、喘息レスキューイベント後の治療に関する推奨を患者111に送信することができる。同様に、アプリケーション115を通して、患者111は、その医療提供者112および他の患者111と通信することができる。

アプリケーション115は、クライアントデバイス110のスクリーン上に表示され、ユーザがアプリケーション115の動作を制御するためのコマンドを入力することを可能にする、ユーザインターフェース(本明細書で、「ダッシュボード」と呼ばれる)を提供する。ダッシュボードは、それによって医療提供者112および患者111がCOPD解析システム100にアクセスする機構である。たとえば、ダッシュボードは、患者111および提供者112が互いと対話し、喘息レスキューイベントリスク通知を受信し、治療に関するメッセージを交換し、追加のイベントデータおよび非イベントデータを提供および受信することなどを可能にする。アプリケーション115は、ウェブページ、一連のウェブページ、または場合によっては、インターネットブラウザ内でレンダリングするためにコーディングされたコンテンツとしてコーディングされ得る。アプリケーション115は、クライアントデバイス110のネイティブオペレーティングシステム上で動作するように構成された、所有権を主張できるアプリケーションとしてコーディングされてもよい。ダッシュボードについて、図3に関連して下記でより十分に説明する。

ダッシュボードを提供することに加えて、アプリケーション115は、ネットワーク150を通して処理データを送信する前に、クライアントデバイス110のリソースを局所的に用いて喘息レスキューイベントデータに対して何らかのデータ処理を実行することもできる。ネットワーク110を介して送信されたイベントデータは、アプリケーションサーバ130によって受信され、ここで、イベントデータは、データベースサーバ140と連携して記憶し取り出すために分析され処理される。アプリケーションサーバ130は、クライアントアプリケーション115の要求に応じて、直接的に要求を取り出し、データベースシステム130に記憶することができる。

クライアントデバイス110は、ネットワークアダプタ、およびその一例がBluetooth低エネルギー(BTLE: Bluetooth Low Energy)プロトコルである、ワイヤード通信プロトコルまたはワイヤレス通信プロトコルのいずれかを用いて、センサ120と通信する。BTLEは、短距離ワイヤレスネットワーク内の無線リンク上でデータをワイヤレスに送信する、短距離、低出力プロトコル規格である。センサ120およびクライアントデバイス110がBTLEパスキーを用いて互いとペアリングされた後で、センサ120は、薬剤デバイス利用に関する情報をクライアントデバイス110と自動的に同期させて通信する。センサ120がレスキュー薬イベントに先立ってクライアントデバイス110とペアリングされていない場合、そのようなペアリングが発生するまで、情報は局所的に記憶される。ペアリングされるとすぐに、センサ120は、任意の記憶されたイベント記録をクライアントデバイス110に通信する。他の実装形態では、他のタイプのワイヤレス接続が使用される(たとえば、赤外または802.11)。

クライアントデバイス110および薬剤デバイス160は、上記で別個の物理デバイス(それぞれ、スマートフォンおよび吸入器など)として説明されているが、将来、薬剤デバイス160は、デバイス160との単一のハウジング内に統合されたセンサ120のみではなく、クライアントデバイス110の態様も含み得ることが企図される。たとえば、薬剤デバイス160は、可視可聴情報(visual audible information)を提示するための、ディスプレイまたは他の照明要素ならびにスピーカーを含むオーディオビジュアルインターフェースを含み得る。そのような実装形態では、クライアントデバイス110を通して、サーバ130によって直接的に提供される通知のコンテンツを提示する代わりにまたはそれに加えて、薬剤デバイス160自体がそれらを提示し得る。

I.B.薬剤デバイスおよびセンサ
薬剤デバイス160は、抑制された呼吸気流量を経験しているユーザの肺に薬を送達するために使用される医療デバイスである。薬剤デバイス(たとえば、吸入器)は、一般に、ポータブルであり、呼吸発作を治療するときにアクセスしやすくするために手で持ち運ぶことができるほど小さい。一実施形態では、薬は、定量服用量吸入器などの薬剤デバイス160を通して噴霧形態で送達される。定量服用量吸入器は、噴霧薬の加圧型噴射キャニスターと、調節された投薬(dosage)量を送達するための調節弁と、加圧型キャニスターを保持し、薬を送達するためのマウスピースをやはり形成するプラスチックホルダーとを含む。別の実施形態では、薬は、ドライパウダー吸入器などの薬剤デバイス160を通してドライパウダーの形で送達される。ドライパウダー吸入器は、ユーザがドライパウダー薬のストリップをインデックス付けすることを可能にする、歯車機構を格納したデカルトの卵形状(Cartesian ovular shaped)を有し得る。ドライパウダー吸入器の本体は、ドライパウダーをユーザに送達するためのマニフォールドおよびマウスピースをやはり含む。長期管理薬剤デバイス160によって投薬される長期管理薬(controller medications)の例には、ベクロメタゾン、ブデソニド、およびフルチカゾン、ならびにサルメテロールまたはホルモテロールなど、長時間効果のある気管支拡張剤とのそれらの薬の配合物がある。レスキュー薬剤デバイス160によって投薬されるレスキュー薬の例には、アルブテロール、サルブタモール、レバルブテロール、メタプロテレノール、およびテルブタリンがある。

それぞれの患者は、2つ以上の薬剤デバイス160に関連付けられ得る。たとえば、患者は、レスキュー薬を投薬するレスキュー薬剤デバイス160、および長期管理薬を投薬する長期管理薬剤デバイス160を有し得る。同様に、それぞれの患者は、各々が、患者の薬剤デバイス160のうちの1つを用いて作用するように選定された、2つ以上のセンサ120に関連付けられ得る。

概して、センサ120は、薬剤ディスペンサー160の利用を監視する物理的デバイスである。センサ120は、薬ディスペンサーの動作を妨げずに薬剤ディスペンサーに取り外し可能にアタッチされているか、またはセンサ120は、その製造会社によって利用可能にされたような薬剤ディスペンサー160の本来の部分である統合構成部分である。

センサ120は、ワイヤード接続を通して、またはより一般的には、ワイヤレス無線周波数接続を通して、クライアントデバイス110と通信するその独自のネットワークアダプタ(図示せず)を含む。一実施形態では、ネットワークアダプタは、Bluetooth低エネルギー(BTLE)ワイヤレス送信であるが、他の実施形態では、他のタイプのワイヤレス通信が使用され得る(たとえば、赤外、802.11)。

センサ120は、アプリケーションサーバ130とより直接的に通信するように構成されてもよい。たとえば、センサ120のネットワークアダプタが802.11またはLTEなど、ワイヤレス規格を介して通信するように構成されている場合、アダプターは、ワイヤレスルータなどのワイヤレスアクセスポイントとデータを交換することができ、ワイヤレスアクセスポイントは、データのあらゆる交換の際にクライアントデバイス110を必ずしも必要とせずに、アプリケーションサーバ130と通信し得る。これらの2つの通信方法は、相互排他的ではなく、センサ120は、たとえば、イベントデータがアプリケーションサーバ130に到着することを確実にするために、またはアプリケーションサーバ130が、イベントに応じて、何の通知を提供すべきかを決定する間に、クライアントデバイス110に情報を直接的に提供するために、冗長送信を用いて、クライアントデバイス110とアプリケーションサーバ130の両方と通信するように構成され得る。

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

この目標を達成するために、センサ120が構築されるべきいくつかの様々な方法が存在し、部分的に、この構築は、薬剤デバイス160自体の構築に左右されることになる。概して、すべてのセンサ120は、オンボードプロセッサ、永続メモリ、および薬イベント情報を記録し、記憶し、クライアントデバイス110および/またはサーバ130に報告するためにともに機能する、上述のネットワークアダプタを含むことになる。センサ120は、イベントの時間および日付を記録するためのクロックを含んでもよい。

特定のセンサ120構築に関して、機械的服用量カウンタなど、旧来の吸入器は、センサ120を念頭に入れて設計されておらず、したがって、センサ120は、それに応じて構築され得る。いくつかの実装形態は、このように、デバイス160の動き、デバイスのプライミング、デバイスのアクティブ化、ユーザによる吸入などを検出するための、機械センサ、電気センサ、または光センサを含む。対照的に、偏向膜服用量カウンタ(deflectable membrane dose counters)など、現代の吸入器は、センサ120が受信し解釈するように設計されている電気データ信号としてイベント情報を報告し得る電気回路を含み、たとえば、薬剤デバイス160自体が、動き、プライミング、およびアクティブ化をセンサ120に報告することができる。

センサ120および薬剤デバイス160用のハードウェア構成要素およびソフトウェア構成要素、ならびにレスキュー薬イベントを記録するためのそれらの対話に関するより多くの情報は、その両方の全体が参照により本明細書に組み込まれている、2009年1月1日に出願した、米国特許出願第12/348,424号、および2014年5月21日に出願した、国際出願第PCT/US2014/039014号に見出すことができる。

I.C.アプリケーションサーバ
アプリケーションサーバ130は、コンピュータまたはコンピュータのネットワークである。簡素化された例を図2に示すが、一般に、アプリケーションサーバは、たとえば、クライアントデバイス110など、使用される一般的なコンピューティングシステムと比較して、強力なプロセッサ、大容量メモリ、およびより高速なネットワーク構成要素を使用するサーバクラスシステムになる。サーバは、一般に、たとえば、RAID(独立ディスクの冗長アレイ)アレイを使用する、かつ/または上記で企図した喘息通知などのデータの記憶、交換、および送信を請け合う独立したコンテンツ配信ネットワーク(CDN)との関係を確立することによる、大容量2次記憶装置を有する。加えて、コンピューティングシステムは、オペレーティングシステム、たとえば、UNIX(登録商標)オペレーティングシステム、LINUXオペレーティングシステム、またはWINDOWS(登録商標)オペレーティングシステムを含む。オペレーティングシステムは、アプリケーションサーバ130のハードウェアリソースおよびソフトウェアリソースを管理し、様々なサービス、たとえば、プロセス管理、データの入出力、周辺デバイスの管理などをやはり提供する。オペレーティングシステムは、デバイス上に記憶されたファイルを管理するための様々な機能、たとえば、新しいファイルの作成、ファイルの移動またはコピー、リモートシステムへのファイルの転送などを提供する。

アプリケーションサーバ130は、ネットワーク150を通して多くの異なるクライアントデバイス110によって、したがって、概してクラウドベースのシステムとして特徴付けられ得るハイレベルで、喘息解析システム100へのアクセスおよびその使用をサポートするためのソフトウェアアーキテクチャを含む。アプリケーションサーバ130は、概して、患者111および医療提供者112が、レスキュー薬イベントと長期管理薬イベントの両方を含むその薬剤デバイス160に関連付けられたセンサによって記録されるデータを報告し、喘息治療計画において協調し、その状態および地理的位置に関する情報をブラウズして取得し、様々な他の機能を使用するためのプラットフォームを提供する。

概して、アプリケーションサーバ130は、多種多様なデータを処理するように設計される。アプリケーションサーバ130は、着信データの有効性の検査、必要に応じて、データのパースおよびフォーマット、記憶のための処理データのデータベースサーバ140への引渡し、およびデータベースサーバ140が更新されていることの確認を含めて、様々な機能を実行する論理ルーチンを含む。

アプリケーションサーバ130は、少なくとも患者ごとにデータを記憶し管理する。このために、アプリケーションサーバ130は、各ユーザに対する患者プロファイルを作成する。患者プロファイルは、喘息解析システム100の患者111を特徴付けるデータのセットである。患者プロファイルは、年齢、性別、現在のレスキュー薬、現在の長期管理薬、通知の選好、長期管理薬アドヒアランス計画、患者関連医療歴、および患者プロファイルに対するアクセスが許可された非患者ユーザのリストなど、患者に関する識別情報を含み得る。プロファイルは、患者に関するデータ(長期管理薬イベントおよびレスキュー薬イベント)を提出することが許可された1つまたは複数のクライアントデバイス110またはセンサ120を識別する一意のメディアアクセス制御(MAC)アドレスなど、デバイス識別子をさらに指定し得る。

プロファイルは、どの異なるタイプの通知が患者111およびその専用医療提供者112に提供されるか、ならびに、通知が提供される頻度を指定し得る。たとえば、患者111は、医療提供者112がレスキューイベントを示す通知を受信することを許可し得る。患者111は、その患者プロファイルおよびレスキューイベント履歴に対するアクセスがその医療提供者112に提供されることをやはり許可し得る。患者111の患者プロファイルに対するアクセスが医療提供者112に提供される場合、医療提供者は、長期管理薬アドヒアランスまたはレスキュー薬計画を指定し得る。投薬計画は、長期管理薬に対する1日当たりの処方服用量を含み得る。

アプリケーションサーバ130は医療提供者112に関するプロファイルをやはり作成する。医療提供者プロファイルは、診療所の所在地、資格、および免許など、医療提供者112に関する識別情報を含み得る。医療提供者プロファイルはまた、その患者母集団に関する情報を含む。提供者プロファイルは、その提供者の患者のプロファイル、ならびにアグリゲートデモグラフィック情報、レスキューイベントおよび長期管理薬イベントのパターンなど、それらのプロファイルから導出されたファイルのすべてに対するアクセスを含み得る。このデータは、時間期間にわたり(たとえば、毎週、毎月、毎年)地理的エリア(たとえば、近隣、都市)ごとになど、患者プロファイル内に記憶された任意のタイプのデータに従ってさらに再分割され得る。

アプリケーションサーバ130は、アプリケーションサーバ130上で様々なルーチンをトリガするレスキュー薬イベント情報をクライアントデバイス110またはセンサ120から受信する。下記で説明する例示的な実装形態では、データ分析モジュール131は、ルーチンを実行して、喘息イベントデータ、ならびに患者のプロファイルを含む他のデータにアクセスし、そのデータを分析し、その分析の結果を患者111と提供者112の両方に出力する。このプロセスは、概して、喘息リスク分析と呼ばれる。喘息リスク分析は、患者の環境における関連する変化によるレスキューイベントに応じて、かつ下記でさらに論じるいくつかのトリガ条件のうちの1つに応じて、任意の時点で実行されてよい。

他の分析も可能である。たとえば、リスク分析は、個々の、地理的、臨床的、疫学的、人口統計的、または空間的もしくは時間的なベースラインまたは予測もしくは予想される値からの過去の著しい置換に基づく薬使用の空間/時間的クラスタ(または、突然の発生)に基づいて識別するために複数の患者に関するレスキュー薬使用および長期管理薬使用に対して実行され得る。他のタイプの分析は、日々の/毎週のアドヒアランス傾向、経時的なアドヒアランス変化、他の関連母集団(たとえば、すべての患者、特定のレスキュー薬もしくは長期管理薬またはそれらの組合せを受けている患者)に対するアドヒアランス比較、トリガの識別情報(空間的、時間的、環境的)、経時的なレスキュー使用傾向、および他の関連母集団に対するレスキュー使用比較を含み得る。

実行された任意の分析に応じて、アプリケーションサーバ130は、患者111、許可を受けた医療提供者112、および/または患者のプロファイルに対するアクセスが提供された他のユーザに送信するためのプッシュ通知を準備して配信する。通知は、薬レスキューイベントに関与するタイミング、位置、および影響を受けた患者111に関する詳細を提供し得る。通知は、加えて、緊急支援提供者112に配布される緊急支援を要求する苦痛信号または緊急信号を含み得る。通知は、データ分析モジュール131によって実行される喘息リスク分析の結果を含んでもよい。送信され得る通知のタイプおよびそれらが含み得るコンテンツに関するより多くの情報について、下記でさらに説明する。

喘息リスク分析に応じてプッシュ通知を提供することに加えて、通知は、特定の時間間隔において、プル通知として提供されてもよい。加えて、レスキュー薬イベントに応じて実行された喘息リスク分析に応じてではなく、代わりに、更新された通知が保証されるように、喘息リスク分析における基本的な要因のうちの1つの変化に応じて実行されたリスク分析に応じて、いくつかの通知(プッシュであるかプルであるかにかかわらず)がトリガされ得る。たとえば、気象状態が大気汚染の増大が発生しているかまたは差し迫っていることを示す場合、これは、汚染が発生している特定の地理的エリア内に位置するすべての患者に対して喘息リスク分析の実行をトリガし得る。

通知は、クライアントアプリケーションと使用するように具体的に設計されたデータフォーマットで、ネットワーク150を介してクライアントアプリケーション115に提供され、追加または代替として、ショートメッセージサービス(SMS)メッセージ、電子メール、電話呼出、または他の通信媒体を使用して通信される他のデータフォーマットとして提供されてもよい。

I.D.データベースサーバ
データベースサーバ140は、プロファイル、薬イベント、患者の医療歴(たとえば、電子医療記録)など、患者データおよび提供者データに関係するデータを記憶する。患者データおよび提供者データは、セキュリティのために暗号化され、少なくともパスワードで保護され、さもなければ、すべての医療保険の携行と責任に関する法律(HIPAA: Health Insurance Portability and Accountability Act)要件を満たすように保護される。複数の患者からのデータを組み込み(たとえば、レスキュー薬イベントデータをアグリゲートし)、ユーザに提供される任意の分析(たとえば、喘息リスク分析)は、患者のプライバシーを保護するために、個人的な識別情報が除去されるように識別解除される。

データベースサーバ140は、喘息リスク分析において使用される非患者データをやはり記憶する。このデータは、患者が物理的に位置し、汚染物質に曝される可能性がある居住ゾーンまたは商業ゾーンにおける公共空間など、いくつかの地理的領域に関する領域データを含む。このデータは、具体的には、グリーンスペース(多くの木や植物が集中したエリア)に対する患者の近接性を含み得るか、またはそれを取得するために処理され得る。領域データの一例は、温度、風のパターン、湿度、大気質指数など、ジオリフェレンスによる(georeferenced)気象データを含む。別の例は、時間のインスタンスにおける、または実験的に測定された、様々な汚染物質に対する粒子カウントを含む、ジオリフェレンスによる汚染データである。領域データは、温度、湿度、大気質指数など、レスキューイベントの時間および場所に関する現在の気象状態に関する情報を含む。上記のデータの項目はすべて、経時的に変化することがあり、したがって、データ自体が、時間単位でインデックス付けされ得、たとえば、(分単位または時間単位を含めて)時刻単位で、または日、週、月、または季節単位など、より長い期間にわたって、別個のデータポイントが利用可能であり得る。データベースサーバ140は、図1においてアプリケーションサーバ130とは別個のエンティティであるとして示されているが、データベースサーバ140は、あるいは、データベースサーバ140が1つまたは複数の永続記憶装置として実装され、データベース内に記憶されたデータとインターフェースするためのソフトウェアアプリケーションレイヤが他のサーバ130のソフトウェアアプリケーションレイヤの一部分であるように、サーバ130など、別のサーバの一部分であるハードウェア構成要素であってもよい。

データベースサーバ140は、定義されたデータベーススキーマに従ってデータを記憶する。一般に、異なるデータソースにわたるデータ記憶スキーマは、ベースラインとなるデータベース構造の実装差異により、クラウドアプリケーションイベントログおよびログメトリックを含めて、同じタイプのデータを記憶するときですらかなり異なり得る。データベースサーバ140は、構造化データ、非構造化データ、または半構造化データなど、異なるタイプのデータを記憶することもできる。データベースサーバ140内のデータは、ユーザ、ユーザのグループ、および/またはエンティティに関連付けられ得る。データベースサーバ140は、データベースサーバ140によって表されたデータベースオブジェクトを管理し、データベースサーバ140から情報を読み取るか、またはデータベースサーバ140に書き込むための命令を指定するためのクエリ言語(たとえば、リレーショナルデータベース用のSQL、JSON NoSQLデータベースなど)でデータベースクエリに対するサポートを提供する。

以下の図6Aから図6Dの説明に関して、これらの図に関して説明するデータベースのコンテンツは、示したように、アプリケーションサーバ130に物理的に近接し、データベースサーバ140から分離されたデータベース内に記憶され得る。あるいは、それらのデータベースは、データ分析モジュール131内にあるとしてそれらの示す図6A～図6Dの説明とは対照的に、データベースサーバ140の一部であってよい。この変形態およびそれに対する他の変形態は、本明細書の範囲内である。

I.E.ネットワーク
ネットワーク150は、クライアントデバイス110と、センサ120と、アプリケーションサーバ130と、データベースサーバ140との間の様々なワイヤードおよびワイヤレスの通信経路を表す。ネットワーク150は、標準インターネット通信技術および/またはプロトコルを使用する。したがって、ネットワーク150は、Ethernet、IEEE 802.11、サービス総合デジタル網(ISDN: integrated services digital network)、非同期転送モード(ATM)などの技術を使用するリンクを含み得る。同様に、ネットワーク150上で使用されるネットワーキングプロトコルは、送信制御プロトコル/インターネットプロトコル(TCP/IP)、ハイパーテキストトランスポートプロトコル(HTTP)、シンプルメールトランスファープロトコル(SMTP)、ファイルトランスファープロトコル(FTP)などを含み得る。ネットワーク150上で交換されるデータは、ハイパーテキストマークアップ言語(HTML)、拡張マークアップ言語(XML)などを含む技術および/またはフォーマットを使用して表され得る。加えて、すべてのまたはいくつかのリンクは、セキュアソケットレイヤ(SSL)、セキュアHTTP(HTTPS)および/または仮想プライベートネットワーク(VPN)など、従来の暗号技術を用いて暗号化され得る。別の実施形態では、エンティティは、上記で説明したデータ通信技術の代わりに、またはそれに加えて、カスタムおよび/または専用データ通信技術を使用し得る。

II.例示的なコンピューティングデバイス
図2は、一実施形態による、図1からの、クライアントデバイス110、アプリケーションサーバ130、および/またはデータベースサーバ140の一部として使用され得る1つの例示的なコンピュータ200の物理的構成要素を示すハイレベルブロック図である。示すのは、少なくとも1つのプロセッサ205に結合されたチップセット210である。チップセット210に結合されるのは、揮発性メモリ215、ネットワークアダプタ220、入出力(I/O)デバイス225、不揮発性メモリを表す記憶装置230、およびディスプレイ235である。一実施形態では、チップセット210の機能は、メモリコントローラ211およびI/Oコントローラ212によって提供される。別の実施形態では、メモリ215は、チップセット210の代わりに、プロセッサ205に直接的に結合される。いくつかの実施形態では、メモリ215は、DRAM、SRAM、DDR RAM、または他のランダムアクセス固体メモリデバイスなど、高速ランダムアクセスメモリ(RAM)を含む。

記憶装置230は、ハードドライブ、コンパクトディスク読取り専用メモリ(CD-ROM)、DVD、または固体メモリデバイスなど、任意の非一時的コンピュータ可読記憶媒体である。メモリ215は、プロセッサ205によって使用される命令およびデータを保持する。I/O装置225は、タッチ入力面(容量性またはそれ以外)、マウス、トラックボール、もしくは他のタイプのポインティングデバイス、キーボード、または別の形態の入力デバイスであってよい。ディスプレイ235は、コンピュータ200からの画像および他の情報を表示する。ネットワークアダプタ220は、コンピュータ200をネットワーク150に結合させる。

当技術分野で知られているように、コンピュータ200は、図2に示した構成要素とは異なるかつ/またはその他の構成要素を有し得る。加えて、コンピュータ200は、示したいくつかの構成要素に欠けていることもある。一実施形態では、サーバ140として動作するコンピュータ200は、専用I/O装置225、および/またはディスプレイ235に欠けていることがある。その上、記憶装置230は、ローカルであってよく、かつ/または(ストレージエリアネットワーク(SAN)内で実装されるなど)コンピュータ200からリモートであってもよく、一実施形態では、記憶装置230は、CD-ROMデバイスまたはDVDデバイスではない。

概して、クライアントデバイス110において使用されるまさにその物理的構成要素は、サイズ、電力要件、および性能は、アプリケーションサーバ130およびデータベースサーバ140において使用されるサイズ、電力要件、および性能とは異なることになる。たとえば、しばしば、ホームコンピュータ、タブレットコンピュータ、ラップトップコンピュータ、またはスマートフォンになるクライアントデバイス110は、比較的小さな記憶容量および処理電力を含むことになるが、入力デバイスおよびディスプレイを含むことになる。これらの構成要素は、データのユーザ入力、ならびにアプリケーションサーバ130によって提供される通知の受信、表示、およびそれとの対話に好適である。対照的に、アプリケーションサーバ130は、多くの物理的に別個の、局所的にネットワーク接続されたコンピュータを含んでよく、これらは各々、上記で紹介した喘息リスク分析を実行するためのかなりの量の処理電力を有する。一実施形態では、アプリケーションサーバ130の処理電力はAmazon Web Services(商標)などのサービスによって提供される。やはり対照的に、データベースサーバ140は、各々が、アプリケーションサーバに関連するデータを記憶するためのかなりの量の永続的記憶容量を有する、多くの物理的に別個のコンピュータを含み得る。

当技術分野で知られているように、コンピュータ200は、本明細書で説明する機能性を提供するためのコンピュータプログラムモジュールを実行するように適合される。モジュールは、ハードウェア、ファームウェア、および/またはソフトウェアで実装され得る。一実施形態では、プログラムモジュールは、記憶装置230上に記憶され、メモリ215内にロードされ、プロセッサ205によって実行される。

III.ダッシュボード
ダッシュボード、たとえば、図3Aに示すダッシュボード300は、ユーザが喘息解析システム100と対話することを可能にする。ダッシュボード300は、ユーザ対ユーザベースで(たとえば、患者111から提供者112に)またはユーザ対システム/システム対ユーザベースで情報を転送するための手段を提供する。ダッシュボード300は、クライアントデバイス110上でクライアントアプリケーション115を通してアクセスされ、患者と医療提供者の両方が、薬レスキューイベントを監視し、個人化された患者の医療情報を交換し、喘息レスキューイベントリスク通知などの通知を受信するための機構を提供する。患者は、ダッシュボード300を通して他の医療提供者および他の患者と通信して、たとえば、喘息、薬利用、または喘息管理に関する情報を論じ、共有することができる。喘息医療情報を共有する能力は、同様の問題を経験している患者または医療提供者に個人的視点を共有する方法を提供することができる。

ダッシュボード300は、許可された医療提供者112が、喘息患者に関する情報ならびに様々なデモグラフィックセグメントまたは地理セグメント内のコミュニティデータおよび統計を閲覧し、注釈を付け、それと対話し、エクスポートするために患者のリストにアクセスすることをやはり可能にする。ダッシュボード300を使用して、医療提供者は、患者を個々にまたは全体として監視し、その関連する患者母集団が喘息管理指導にどのように対応しているかに関するフィードバックを受信および提供することができる。個々のまたは複数の患者に対するアクセスを有する医療提供者は、通知しきい値を確立し、通知のためのパラメータを設定し、患者のイベント履歴が一定の条件(たとえば、レスキューイベント)に一致するとき通知を受信するための能力を有する。加えて、ダッシュボード300は、喘息解析システム100によって生成される特定のデモグラフィックに対するイベントパターンの定期的な報告を受信し表示することができる。

ダッシュボード300は、表形式データ、グラフィカルな可視化、および分析を含む様々な情報をディスプレイ「カード」310を通してユーザに提示する。ディスプレイカード310は、ポータブルクライアントデバイス110、たとえば、モバイルフォンまたはタブレットに一般的な小さなディスプレイに難なく適した、野球カードに見られる単純な組織スタイルを模擬した「ビットサイズ」の情報を含む。ダッシュボード300は、ユーザが異なるカテゴリーの医療情報をナビゲートすることを可能にするシステムメニュー305をやはり含み得る。

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

提示された情報と対話するために、いくつかのディスプレイカード310aは、入力応答315エリアを含む。たとえば、図3Bに示すディスプレイカード310b内で、患者は、入力応答315エリア内を上下にスクロールして、喘息を管理するために使用される長期管理薬を選択すること、または追加のディスプレイカード310に移動するために「次」を選択することができる。

ダッシュボード300は、カテゴリーに組織され得る、様々な異なるディスプレイカード310を提供することができる。情報カードタイプは、データを表示するカードを含む。情報カードは、たとえば、薬レスキューイベント、統計、および患者データとコミュニティデータの両方を含む地図を表示し得る。情報カードは、イベントディスプレイカード、傾向ディスプレイカード、教育ディスプレイカード、および警告ディスプレイカードにさらに下位分類される。

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

図3Bは、データ分析モジュール131によるリスクスコアの決定に基づいて送信される、通知モジュール645(下記で論じる)によって送信された1つの例示的なディスプレイカード310aを示す。ディスプレイカード310aは、リスクスコアを決定するために使用される入力値から取得された患者情報、たとえば、そのデバイス110によって指定された患者の現在の地理的位置、および環境情報を強調表示する。ディスプレイカード310aは、リスクスコアに基づくリスク分類、この場合、中程度のリスク分類を表し得る「フェア」をやはり含む。

別のイベントカードは、レスキュー利用イベントの位置のマップ、その位置における環境条件、および受信者がレスキュー利用イベントに対するトリガを追加するための入力応答エリア315を含む、1つの例示的な薬利用報告を表示し得る。別のイベント傾向カードは、時間期間に対する総使用回数および毎日の使用回数を含む、前の週に対するレスキューデバイス利用を表示し得る。

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

教育カードは、受信者を教育することを意図した情報を含む。教育カードは、一般的な疾患情報および患者がレスキューイベントのリスクを低減するためのヒントを提供する。いくつかの教育カードは、受信者が、提供された情報が将来のカードに役立たせる際の使用に関連性があるか、またはその利益があるかどうかを指定することを可能にするための入力応答315を必要とし得る。

警告カードは、受信者にイベントのリスクがあること、および/または最近の時間期間にわたってデバイスからデータが受信されていないことを受信者に知らせる重要な情報をユーザに通知する。他の警告は、クライアントデバイス上の設定がデータ同期を妨げている(たとえば、Bluetooth(登録商標)がオフにされている)という警告、または患者の喘息リスクスコアが変更されているという警告を含み得る。

調査カードタイプは、yes/no、複数の選択肢、またはユーザが応答するための自由記入式質問を提示することによって、ユーザ応答を求める。たとえば、医療提供者または喘息解析システム100は、特定の患者に対する疾患制御レベルを決定するために喘息関連の質問表を備えた調査カードを患者111に送信することができる。加えて、調査カードは、患者111が喘息症状を治療するために使用するタイプの長期管理薬を要求し得る。概して、調査カードは、患者の医療歴または患者プロファイル(上記で紹介したような)に欠いている可能性があるデータをアプリケーションサーバ130に提供し、かつ/または潜在的に古い情報に対する更新を提供する。1つまたは複数の調査カードを使用して、患者登録プロセスを完了し、データベースサーバ140内に記憶するための患者プロファイルを作成することができる。たとえば、患者111が最初に喘息解析システム100に登録するとき、アプリケーションサーバ130によって、患者プロファイルを作成するように患者111に催促するプッシュ通知がトリガされることになる。

調査カードの例は、喘息レスキューイベントの結果として患者にいずれかの緊急治療室を訪問させたかどうかを尋ねる調査質問、患者の長期管理薬に関する情報、イベントを制御するために患者がそのレスキュー薬剤療法を何度使用したか、その長期管理薬の日々のスケジュールは何かを含み得る。調査カードは、花粉がトリガであるかどうかなど、患者の喘息トリガについてもやはり尋ねることができる。いくつかの調査カードは、5ポイントリッカート尺度でその全体的な生活の質を評価するように、その睡眠の質を評価するように、過去7日間にアクティブであった能力を評価するようになどを尋ねることができる。他の調査カードは、患者が昨日よりも気分が良いかまたは悪いか、患者がレスキューイベントのために過去12か月の間に緊急治療室または病院に行かなければならなかったかどうかなどを尋ねる。

場合によっては、既存の患者情報と整合しない患者行動またはセンサ報告イベント情報は、患者の状況に関する不明瞭さを解決するために、調査カードの送信をトリガし得る。たとえば、患者が予想カウントを超える喘息イベントを経験している場合、調査カードは、正確な薬が使用されていることを検証するために、患者が現在その薬剤デバイス160上に列挙しているタイプの薬に関する情報を要求することができる。別の例は、長期管理薬使用に関して報告された情報が、患者が1日に1回のみ長期管理薬を使用していることを示すが、そのアドヒアランス計画は、患者が1日に2回その長期管理薬を服用することになっていることを示す場合、システム100は、患者がそのアドヒアランス計画を変更する必要があるかどうかを尋ねる通知を送信し得ることを含む。

場合によっては、既存の患者情報に整合しない患者行動またはセンサ報告イベント情報は、患者の状況に関する不明瞭さを解決するために、調査カードの送信をトリガし得る。たとえば、患者が予想カウントを超える喘息イベントを経験している場合、調査カードは、正確な薬が使用されていることを検証するために、患者が現在その薬剤デバイス160上に列挙している薬のタイプに関する情報を尋ねることができる。別の例として、長期管理薬使用に関して報告された情報が、患者が1日に1回のみ長期管理薬を使用していることを示すが、そのアドヒアランス計画は、患者が1日に2回その長期管理薬を服用することになっていることを示す場合、システム100は、患者がそのアドヒアランス計画を変更する必要があるかどうかを尋ねる通知を送信し得る。

ナビゲーションカードは、ユーザ対話時に、ダッシュボード300の一部である別のスクリーンまたはカードにユーザをリダイレクトし得る、アクション可能なデータまたはメッセージを表す。たとえば、患者が、長期管理薬に関する特定の情報を内科医と共有すること、または長期管理薬に関する特定の薬計画を内科医に要求することを望む場合、情報または長期管理薬アドヒアランス計画への登録の共有を促すために、ナビゲーションカードが使用されることになる。加えて、ナビゲーションカードは、ユーザが薬レスキューイベントに関する情報を更新することを可能にする。

アドヒアランスカードは、異なる時間期間にわたって予定通りにその長期管理薬を継続的に使用することを患者に促すように設計される。アドヒアランスカードは、時間通りの長期管理薬イベントの「ストリーク(streak)」または継続的な実行を示し得る。加えて、調査カードは、互いのしきい値時間期間内のかなりの数のレスキューイベントの記録に応じて、患者の身体的状態について問い合わせてもよい。長期管理薬イベントは、その日の間に様々な期間内に、その医療提供者112によって処方されたように、患者111がその長期管理薬を時間通りに服用したとき、または服用しなかったときを示すためにグラフとして表されてもよい。カードは、長期管理薬に関する日々のスケジュール、およびスケジュールされた服用量が服用されているかどうかを表示するためのインジケータを詳述してもよい。たとえば、赤の「X」は、スケジュールされた服用量が服用されていないことを示してもよく、緑のチェックマークまたは異なるシンボルは、スケジュールされた服用量が服用されていることを示してもよい。

セットアップカードは、センサをクライアントデバイス110に関連付ける際に受信者を導く。セットアップカードは、Bluetoothを用いてクライアントデバイス110とペアリングするようにセンサを導くこと、ペアリングプロセスを開始するように受信者に催促すること、もしくはペアリングのためにセンサデバイスを選択するようにユーザに催促すること、またはセンサがペアリングされていることをユーザに通知することができる。

いくつかの実施形態では、ダッシュボードは、ユーザインターフェースを提示し得る。ユーザインターフェースは、ユーザによる「閲覧タイムライン」入力応答エリア315cの選択に応じて、レスキューイベントのリストを示し得る。リストは、時間期間にわたるレスキュー利用イベントを表示し、日付、時間、パフの数、および位置などの詳細を含む。受信者は、編集対話応答エリアを選択することによって、レスキュー利用イベントを編集すること、および/または追加の詳細を加えることができる。いくつかのインターフェースは、レスキュー利用イベントに関するイベント要約をユーザに提示し得る。イベント要約は、ユーザによるユーザインターフェースの編集対話応答エリアの選択に応じて、ユーザに提示され得る。ダッシュボードから、ユーザは、薬リスト、薬タイプ(レスキュー、長期管理薬など)などの詳細情報、投薬スケジュール、およびセンサを閲覧および編集することもできる。

IV.イベント駆動型喘息リスク通知
図4は、一実施形態による、薬剤デバイス監視に基づいて喘息リスク通知を提供するための対話図を示す。最初のステップとして、患者は、患者プロファイルを開始する(405)ためにダッシュボード300とインターフェースする。患者がその患者プロファイルを完了すると、クライアントデバイス110は、アプリケーションサーバ130が使用し、データベースサーバ140が記憶するための患者プロファイルを送信する。患者の患者プロファイルが開始されると(405)、アプリケーションサーバ130は、患者の薬剤デバイス160に関連付けられたセンサ120によって検出されたレスキュー薬イベントの受信を開始することができる。患者プロファイルの初期化および完了は、患者による薬剤デバイスの第1の使用の間に一回のみ実行される。

センサがレスキュー利用イベントを検出すると(410)、患者デバイス111は、レスキューイベントデータを集めて、イベント情報を記憶する(415)アプリケーションサーバ130に送信する。1つのそのような事例のみを図4に示すが、この検出プロセスおよび記憶プロセスは、概して、レスキュー利用イベントの検出時に、概して、多くの患者に対して何らかの頻度で実行される。しかしながら、この頻度は、リスク分析が実行される頻度とは異なり得る。

次に図5を参照すると、アプリケーションサーバ130は、概して、患者が喘息関連のイベント症状を緩和するためにそのレスキュー薬剤ディスペンサー160を使用するときはいつでもレスキューイベントを受信する。症状の開始時に、特定のデバイス160/センサ120組合せに関してそのようなイベントを捕捉するためのプロセスの一例として、センサ120は、薬ディスペンサー160カバーが開いているかどうかを検出し得る(505)。薬ディスペンサーカバーが開いているとき、センサ120は、ディスペンサー160のプライミングに関連する加速を検出し得る(510)。いくつかのタイプの薬剤ディスペンサーの場合、「プライミング」は、服用量の薬をパッケージングから放出するための機構をアクティブ化することを含む。他のタイプの薬剤ディスペンサーでは、「プライミング」は、薬キャニスターを勢いよく振ることを含む。

プライミング活動が検出された後で、センサ120は、レスキューイベントに関連するデータをセンサ120のアクティブメモリ内に記憶する(515)ように構成される。レスキューイベントデータは、レスキューイベントに関連する時間および日付を記述する情報、薬剤デバイス160のステータスおよび状態(たとえば、バッテリーレベル)、(イベント前後の)薬の残余服用量、セルフテスト結果、およびセンサ120によって測定された、薬剤デバイス160を用いて治療されている患者の生理学的データを含み得る。センサがクライアントデバイス110またはネットワーク150とのネットワーク接続を確立するとすぐに、センサは、いかなる局所的に記憶されたレスキューイベントデータもクライアントデバイス110またはアプリケーションサーバ130に送信する(525)。イベントデータが最初にクライアントデバイス110に送信された場合、クライアントデバイス110は、次いで、クライアントデバイス110がネットワーク150とのネットワーク接続を確立するとすぐに、レスキューイベントデータをアプリケーションサーバ130に送信する(530)。実装形態に応じて、クライアントデバイス110またはセンサ120のいずれかは、イベントが発生した地理的位置をアプリケーションサーバ130に送信されるイベントデータに追加することになる。

次に図4に戻ると、レスキュー利用イベントを検出する(410)とすぐに、イベントデータが集められて記憶される(415)。レスキュー利用イベントデータを受信し、記憶する(415)とすぐに、アプリケーションサーバ130は、レスキュー利用イベントを記述する、患者からのさらなる情報を要求し得る。情報を取得するために、アプリケーションサーバ130は、患者のクライアントデバイス110に送信されることになる、問い合わせられることになる質問を含めて、プッシュ通知を生成する。クライアントデバイス110は、調査タイプカード310としてプッシュ通信を提示し得る。患者は、調査カード310に応じて入力315を提供することによって、要求に応じることができる。あるいは、患者111は、要求に応じないことを選んでもよい。これは容認され、情報内の何らかのギャップは、後のプッシュ通知により、または患者111との面談の後で提供者112による記入時に取得され得る。一実装形態では、要求に応じて追加で要求されたデータを受信できないことは、ステップ425～445で説明する分析の残りを妨げない。

イベントの部分としてまたは別の方法で収集された情報は、イベントのトリガに影響を与えた可能性があるパラメータに関する情報、レスキューイベントの位置、その位置に関する標示(たとえば、仕事、自宅、または学校)、患者にとってのその位置の個人的な重要性を表す等級、および任意の他の関連情報に加えて、その使用がプリエンプティブであった(たとえば、体操に先立って薬が服用された)かどうかを識別し得る(420)。

追加のイベントデータを要求することに加えて、アプリケーションサーバ130は、データベースサーバ140から記憶されたコンテキストデータにアクセスする(425)。概して、コンテキストデータは、イベントデータ以外のデータを指し、このデータは、大気状態、気象状態、過去のレスキュー利用イベントから記録された患者データ、およびレスキュー利用イベントの時点で薬剤デバイスによって直接的に検出されない何らかの他の考慮事項を含むが、これらに限定されない。対照的に、イベントデータは、薬の用量、イベントの時間、イベントの位置、および関連するアドヒアランスデータなど、レスキューイベントに関係し、薬剤デバイスによって報告される任意のパラメータを指す。両方の形態のデータは、時間的に最新の情報ならびに記憶された過去のデータを含み得る。したがって、コンテキストデータを取得する一環として、アプリケーションサーバ130は、患者111に関する過去のレスキュー利用イベントデータにもアクセスする。過去のデータは、あらゆる過去の様々な時間窓にわたる患者の履歴からの過去の長期管理薬イベントデータまたはレスキュー薬イベントデータのすべてを含んでよく、それぞれの過去のイベントは、その後のフォローアップ時に収集されたあらゆるデータとともに、このイベントに関して報告された(410)情報と同じ項目のすべてを含み得る。

しかしながら、図6Aおよび図6Bにおけるように、以下の説明において、場合によっては、コンテキストデータ635および過去のデータ620は、別個に表される。コンテキストデータ635は、現在のイベントまたは患者のクライアントデバイス110の現在の位置に関連する地理的情報および領域情報を指すが、過去のデータ620は、同じまたは異なる患者からの前のレスキュー利用イベントからの地理的情報、領域情報、またはイベント情報を指す。

IV.A.喘息予測モデル概要
図6Aは、一実施形態による、データ分析モジュール131の機能を実行する論理構成要素を示すブロック図である。喘息解析システム100は、トリガ条件の発生時に患者に対するリスク分析を実行する(430)ための、上記で紹介し下記でさらに論じる、システムが収集した様々なデータを分析するデータ分析モジュール131をアプリケーションサーバ130上に含む。これらのリスク分析は、そのレスキュー吸入器の利用を余儀なくさせることになる喘息イベントの発生をできれば回避するために十分適時に患者に送信されるように特に構成された通知を生成するために使用される。

リスク分析を実行するために、数学関数または他のより複雑な論理構造などのモデル640は、予め記憶され、リスク分析の一部として使用される、一組のパラメータ値を決定するために、過去のイベントデータおよび過去のコンテキストデータを使用してトレーニングされる。トレーニングに関しては、下記で、セクションIV.Bにおいて、図6Bに関して論じる。パラメータ値630は、入力値のうちの少なくとも1つに関連付けられる「重み」(または、使用されるモデリング技法に応じて、臨界値もしくは他の同様の量)を記述する。入力値は、モデル640のパラメータの数値価またはカテゴリー値を指し、ここで、入力値は、経時的に患者間で異なり得る。

手短に、ユーザのレスキュー吸入器利用イベント605、620の態様、および他のコンテキストデータ635、620をモデル640の関数に対する入力値およびパラメータ値630に入力し、数値リスクスコアを決定することによってリスク分析が実行される。概して、入力値として使用するために収集されたコンテキストデータは、デバイスまたは他の第三者データ報告に基づいて自動的に収集され得るか、患者および/または提供者によって手動で提供され得るか、またはさもなければ取得され得る。リスクスコアは、イベントデータ605およびコンテキストデータ635を考慮して、患者が喘息レスキュー利用イベントを経験する可能性を特徴付ける、モデル640によって生成される数値価である。リスクスコアは、次いで、その時点でその現在のコンテキストに特定である、ユーザに対するリスク分類を指定するために使用されてよく、それらのいずれかまたは両方が通知モジュール645に提供され得る。

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

モデル640トレーニングプロセスの一環として、モデル使用の間に、モジュール131は、概して、周期ベースで患者に関するベースラインを生成し、ここで、ベースラインは、リスク通知プロセスの他の機能において使用される。これを行うために、イベントデータ605は、ベースライン生成モジュール610によって受信され、ベースラインを生成するために使用され、ベースラインは、次いで、後のためにベースラインデータベース615内に記憶される。ベースラインを生成するこのプロセスは、概して、場合によっては、システム活動をトリガし得る、イベントまたはトリガ条件の発生にかかわらず、指定された頻度で発生する。ベースラインを生成するための方法論については、下記で図6C～図6Dを参照してさらに説明する。

IV.B.モデルトレーニング
モデルトレーニングおよび図6Bおよび図6Cに関して、モデルは、標示された過去のデータに対してトレーニングされ、ここで、前の日に関連する過去のイベントおよび過去のコンテキストデータは、その日が高リスクに関連付けられたか、または低リスクに関連付けられたかの標示された指示に関連付けられる。高リスクまたは低リスクの標示に関するこの決定は、その日に関連するイベントがその日に関するベースラインしきい値を超えるかどうかに基づいて決定される。

図6Bは、一実施形態による、モデルをトレーニングするための論理アーキテクチャを示すブロック図である。モデルをトレーニングするために使用されるデータセットを作成するために、アクセスされた過去のデータは、毎日、アグリゲート/セグメント化され、様々なパラメータに関する入力値が識別される。概して、1日分の情報は1つのトレーニングサンプルに関連付けられる。大気環境データおよび気象データは、米国海洋大気庁(NOAA)および環境保護庁(EPA)の過去のデータセットから取得され得る。

それぞれのトレーニングサンプルに関する標示を作成するために、ベースラインしきい値が毎日確立され、モデル640は、そのデータに関するレスキュー利用イベントの数に基づいて、毎日のベースラインしきい値を超えるかどうかを決定する。ベースラインしきい値の決定に関する完全な説明について、下記でセクションIV.Dにおいて、図6Dに関して論じるが、概して、所与のトレーニングサンプルに関連する標示は、その日が「高リスク」と見なされたかまたは「低リスク」と見なされたかの決定を表す。

図6Cは、一実施形態による、トレーニングデータセット650を用いてモデルをトレーニングするための方法を示す図である。トレーニングサンプル650の入力値(Aによって表される、テーブルのセル)(テーブルの各行)とこれらのサンプルのラベル(C)との間の関係を最も表す(たとえば、図示されていない、各パラメータに関連付けられた)パラメータ値を決定することによってモデル640がトレーニングされる。上記で紹介したように、モデル640は、関数(B)または別のより複雑な論理構造を用いてトレーニングされる。一実施形態では、モデル640は、機械学習技法を用いてトレーニングされ、機械学習技法の例は、線形回帰、ロジスティック回帰、および他の形態の回帰(たとえば、エラスティックネット(elastic net))、決定木(たとえば、ランダムフォレスト、勾配ブースティング)、サポートベクトルマシン、分類器(たとえば、ナイーブベイズ分類器)、ファジーマッチングを含むが、これらに限定されない。勾配ブースティングを用いてトレーニングされる例示的なモデル640については、下記でセクションIV.Eにおいて説明する。

パラメータ値が知られると、パラメータ値、およびモデルによって指定された関数にアクセスし、パラメータに関する入力値を入力してリスクスコアを生成することによって、図6Bで論じたように、モデル640が使用され得る。

IV.C.入力パラメータ
リスクスコア分析内に組み込まれたパラメータは、いくつかのグループ、すなわち、過去の患者パラメータ、現在の患者パラメータ、大気汚染物質パラメータ、および気象パラメータに分類され得る。過去および現在の患者パラメータは、単に「患者パラメータ」としてより大まかに分類され得る。大気汚染および気象変数は、単に「環境条件パラメータ」としてより大まかに分類され得る。パラメータの数値価は、上記で説明したように、入力値の形態で生成される関数に含まれる。さらに、パラメータからモデルのパラメータ値が導出される。

過去の患者の特徴は、一定の時間期間にわたるレスキューイベントの累積患者履歴(pr_7_rscu_sum)、レスキューユニットが使用されている日の累積カウント(norm_day)、疾患タイプ(disease_asthma)、夜間に発生するレスキューイベントの記録、および長期管理薬アドヒアランス記録(pr_sun_adh)を含み得るが、これらに限定されない。レスキューイベントの患者履歴は、いずれかの前のレスキューイベントに関して上述したカテゴリーに関係する任意の関連情報を含み得る。疾患タイプは、患者の喘息の深刻さ、ならびに個人的な治療法を記述する。長期管理薬アドヒアランス記録は、患者のその長期管理薬の使用に関する情報(センサユニット160にやはり関連付けられ得る)を含む。この決定は、利用が処方されたが、実行されなかった場合、利用が処方され、実行された場合、および利用が処方されず、実行された例を観察することによって評価される。

現在の患者の特徴は、現在の緯度(lat)、経度(lon)、およびクライアントデバイス110の座標の位置、ならびに現在の日付(month,day_of_week)を含み得るが、これらに限定されない。現在の緯度および経度は、そこから患者の環境条件に関する情報が決定され得る、患者の地理的位置を決定するために使用される。現在のレスキューイベントデータは、服用されたレスキューパフの数と処方された数との間の差異、ならびにその日にすでに発生した可能性があるあらゆるレスキューイベントのカウントおよびそれらのイベントに関連する情報をやはり含み得る。

大気汚染物質の特徴は、濃度に関する情報(たとえば、アナログ値)、または汚染物質の存在または不在のよりバイナリな指示を含み得る。考慮される汚染物質の例は、オゾン分子(O₃)、二酸化窒素分子(NO₂)、二酸化硫黄分子(SO₂)、サイズ2.5マイクロメートル以下の粒子物質(PM_2.5)、サイズ1.0マイクロメートル以下の粒子物質(PM_1.0)、および大気質指数を含むが、これらに限定されない。具体的な気象特徴は、温度(drybulbfahrenheit)、湿度(relativehumidity)、風速(windspeed)、風向(wind_direction_cat)、現地気圧(stationpressure)、および視程を含み得る。

IV.D.しきい値決定
上記で紹介したように、ベースラインリスクしきい値は、モデルトレーニングとリスクスコア計算の両方において使用される。ベースライン生成モジュール610は、その間に(トレーニングの間またはモデル使用の間のいずれかの標示のために)リスクが計算されている当日に先行する指定された前の時間期間にわたる、または、より一般的に、現在の/最近のレスキュー利用イベントの時間に先行する時間期間の間の、利用イベントの総数に基づいて、ベースラインリスクしきい値を計算する。

一例では、時間期間は、当日および前の7日間のみに、排他的に限られた範囲(したがって、当日のデータは考慮から外される)であるが、他の時間期間を使用してもよい。たとえば、患者プロファイルが最近作成されたことにより、またはこの時間窓の間に利用イベントが追跡されていないことにより、7日分の累積データが存在しない場合、ベースラインは、代わりに、データが利用可能である日数に基づいて計算され得る。

一実施形態では、ベースラインリスクしきい値は、指定された期間にわたる利用イベントの総数の比率(割合)として設定されるが、他の実施形態では、しきい値を決定するために、利用イベントの総数の他の比率を使用してもよい。

図6Dは、一実施形態による、2つの例示的なリスクしきい値決定、およびトレーニングデータセットのトレーニングサンプルに関する標示を決定するためのその使用を示す。第1に、前の7日間からの利用イベントの総数が加算されて記録される。両方の例に対して、この総数は30回のイベントである。第2に、総数の5%に等しい、イベントの数、この場合、1.5回のイベントとして、リスクしきい値が決定される。

トレーニングにおいて、サンプル(イベントおよび一日のイベントに関する他のデータ)が「1」または「0」と標示され、ここで、1は、患者に対する高リスクを示し、0は、低リスクを示す。これは過去のデータであるため、リスクのこの「割当て」は、ユーザに対してより多くのレスキュー利用吸入器イベントが発生したという推定に基づき、患者の状態が悪いほど、その行動を発生させたパラメータの入力値の何らかの複雑な組合せが他の日におけるよりも悪化することを示唆する。したがって、標示シナリオでは、それは、そのモデルが将来回避するために識別しようとしている発生と同じくらい、本質的なリスクではない。

標示を割り当てるために、所与の日のレスキュー吸入器利用イベントの数がしきい値を超える場合、ここでは、過去7日間にわたって集計された30回のイベントの5%を超える場合、1が割り当てられる。そうでなければ、0が割り当てられる。図6Dは、1日に2回のイベントがセンサ160によって報告された場合と、その日に1回のイベントが報告された場合の両方の可能な例を示している。これらの最終的な決定は、モデルが、トレーニングされると、入力値の何の組合せ、どの種類のイベントがリスクイベントを構成し、どの種類が構成しないかを決定することを可能にする。固定数のイベントとは対照的に、前の期間のイベントの一部に基づくしきい値の設定は、しきい値を患者の特定の疾患状態に調整する際に、より高い柔軟性および可変性を可能にする。具体的には、患者のレスキュー吸入器利用が数日にわたって高まった場合、しきい値をこのような形でダイナミックにさせることは、パラメータが患者の状態を悪化させているか(または、していないか)どうかのよりよい識別を可能にする。一実施形態では、ベースラインリスクしきい値は、頻度の高い0による非対称分布で正確に切り取られた(tailed)利用パターンを明らかにし、中位日(median day)を上回るが、7日間の平均を下回る利用イベントを有する日の高リスク分類を確実にするために、14%(7日の履歴からの1日平均を表す)など、何らかのより高いしきい値ではなく、5%に設定される。

IV.E.勾配ブースティングされた決定木の例
一実施形態では、モデル640は、勾配ブースティングモデルである。概して、勾配ブースティングは、弱い予測モデル、一般に、決定木のアンサンブルの使用を必要とする。決定木の場合、それぞれの木は、わずかなパラメータのみに対処する比較的浅い深度の弱い学習器である。モデル640のトレーニング機構は、反復関数勾配降下アルゴリズム(iterative functional gradient descent algorithm)である。すなわち、このアルゴリズムは、負の勾配方向を指す関数(弱い仮説)を反復的に選定することによって、パラメータ空間上で費用関数を最適化する。別の言い方をすれば、トレーニングのそれぞれの反復において、アルゴリズムは、それらの木からの費用関数および前の反復のパラメータ値によって識別されるエラーを最小限に抑えるように、新しい木に対してパラメータを選定する。

1つの特定の実施形態では、アルゴリズムおよびフレームワークのXGBoostセットがモデル640のベースラインとして使用される。1つの例示的なモデルは、max_depth=9、min_child_weight=1、gamma=0、learning_rate=0.1、n_estimators=1000、subsample=0.8、colsample_bytree=0.8、objective=binary:logistic、nthread=4、scale_pos_weight、およびseed=27であるように、XGBoostセットの変数を用いて実行された。XGBoostアルゴリズムに関するさらなる詳細は、http://xgboost.readthedocs.io/en/latest/python/python_api.htmlに見出すことができる。データに対して交差検証が実行された。残りの説明の便宜上、この例は、XGBoost Example Modelと呼ばれる。

IV.F.喘息予測モデル使用
次に図4に戻ると、アプリケーションサーバ130は、トレーニングされたモデルを使用し、喘息リスク分析430を実行して、患者が近い将来に喘息イベントを経験することになるリスクを決定する。このリスクは、数値スコアとして実施されるが、患者が高リスクカテゴリー内であるか、中程度のリスクカテゴリー内であるか、低リスクカテゴリー内であるかなど、リスク分類へと処理されてもよい。この情報は、特に、予測されるイベントを回避するために、患者行動の変化に影響を及ぼすことを試行するために使用され得る。

次に図6Aを参照すると、データ分析モジュール131は、モデルを使用することが可能であるように入力値にアクセスし、ここで、入力値は、いずれかの現在のレスキューイベントデータ605、過去のレスキューイベントデータ605、現在のコンテキストデータ635、過去のコンテキストデータ635、およびパラメータ値630から決定される。モジュール131はまた、十分最新のしきい値がデータベース615内に存在するかどうかに応じて、ベースラインリスクしきい値を決定するか、またはそれにアクセスする。モデル640は、これらの入力を用いて、リスクスコアを決定する。上記で論じたように、モデル640は、患者にとって前の特定の日が高「リスク」であったか否かを示す、1または0の正規化リスク値に基づいてトレーニングされる。モデル640によって生成された数値リスクスコアは、同様に0と1の間で包括的に正規化されることになる。したがって、数値リスクスコアは、現在の入力値が、その患者が高リスクにあることを示すかまたは低リスクにあることを示すかに関して、モデル640の決定を表す。さらに、1/0標示は、患者が本来レスキュー吸入器を使用したかどうかに基づかず、患者が動的しきい値を超えたかどうかに基づき、これは、場合によっては、患者が前の時間期間にわたってその移動窓平均をわずかに超えたかどうかに基づいて設定されることを想起されたい。したがって、同様に、モデルが出力したリスクスコアはまた、レスキュー吸入器利用イベントが単に発生することになるかどうかだけでなく、レスキュー利用イベントが発生することになるか、代わりに、患者が、現在のベースラインリスクしきい値によって識別されるその独自の移動窓平均を超えることが予想される入力値に基づくかどうかを反映する。

モジュール131は、高リスク、中リスク、もしくは低リスク、またはリスクスコアをコンテキストに当てはめる何らかの他の分類としてリスクスコアをさらに分類し得る。一例として、低リスクと見なされるスコアは、0.0から0.1の間の範囲であり、中リスクは0.1から0.8の範囲であり、高リスクは0.8から1.0の範囲である。

IV.G.喘息レスキューイベントリスク通知
通知モジュール645は、分類、リスクスコア、リスクスコアの潜在的な原因、およびこれらの状況下で患者が別のレスキュー利用イベントの発生を防ぐためにとり得る選択肢のうちのいずれか1つまたは複数を含むリスクスコア通知を生成する(435)。上記で論じたように、アプリケーションサーバ130は、患者111、その医療提供者112、および/またはいずれかの他の許可を受けた個人のうちの1つまたは複数に対してリスクスコア通知を生成する(435)。

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

リスク通知は、リスク分類の変更の原因となるパラメータに基づいて、さらなるレスキュー吸入器イベントをどのように防ぐかに関する推奨からなり得る。たとえば、推奨は、より密にアドヒアランススケジュールに従うこと、長期管理薬の服用量または利用を増大させること、その地理的領域を完全に回避すること、または同様の環境条件を有するエリアへの暴露を制限することを含み得る。

加えて、患者111には、前年発生したその薬レスキューイベント位置のすべてのピンポイントを有する地理的マップが提供されてよい。別の例として、患者111には、そのエリアに対する薬レスキューイベントの最近のパターンを示すために、その日またはしきい値時間期間内のいずれかに近くの地理的エリア内に発生したすべての薬レスキューイベントのピンポイントとともに、イベント410が起こった場所を含む地理的マップが提供されてよい。別の例として、患者111の医療提供者112には、提供者112が薬レスキューイベント傾向を識別するのに役立つように、その日または最近の時間期間からその患者111からの薬レスキューイベントデータが提示されてよい。

リスク通知は、実装形態に応じて、トリガ条件に基づき得るか、またはいくつかの他の機構に従ってクライアントデバイスに送信され得る、多くの他の状況で配信されてもよい。たとえば、患者パラメータ(たとえば、患者の低減した長期管理薬アドヒアランス傾向)または環境条件パラメータ(たとえば、低濃度のオゾン、空気中のより大量の汚染物質、またはより高い湿度)の変化により患者の現在の状態が悪化した場合、更新されたリスク通知が患者111に配信される。あるいは、患者の現在の状態が同様の変化により改善される場合、更新されたリスク通知が配信されてもよい。リスク通知は、たとえば、第三者デバイス(たとえば、Google Home(商標)またはAmazon Alexa(商標))からの局所的喘息条件に対する口頭要請により、患者の要求で配信されてもよい。

上記で説明したように、概して、リスク通知は、クライアントデバイス110を通して配信されるが、他の実施形態では、条件が改善または悪化した場合、リスク通知は、SMS通知、電子メール通知、局所喘息条件を備えた埋込み式ウィジェットからの通知、または様々なIFTTTアプレット(https://ifttt.com/)からの通知として配信され得る。

V.実施例
V.A.実施例1
図7Aは、1として標示された日の割合および0として標示された日の割合を示すことによって、トレーニングデータセットを特徴付ける。加えて、グラフは、上記で論じたように5%係数を含むベースラインリスクしきい値と5%係数を含まないベースラインリスクしきい値に基づいて高リスクとして分類された日数の増大を示す。大気環境に対するPropeller Health(商標)の患者吸入器データおよび2012年4月30から2017年4月30日までのNOAAおよびEPAの過去のデータセットからの気象データと一緒に、1日のユーザ(患者)ごとのデータセットを表す。位置情報を欠くユーザの場合、矛盾は、その24時間期間の間のごく最近ログされた位置を用いて満たされる。その24時間期間の間にログされた位置がない場合、その日のデータは、データセットから除去される。総データセットは、5,309名のユーザおよび720,812日のユーザ-日からなり、その15%は、高リスク(すなわち、1)と分類された。低リスク日は、0と分類される。総データセットのうち、5,202名のユーザおよび178,920日のユーザ-日がトレーニングセットに対して選択された。モデルトレーニングを改善するために、トレーニングセットのバランスをとるようにサブサンプリング技法が使用される(たとえば、0および1と標示されたイベントの同数)。テストセットは、3,982名のユーザおよび35,848日のユーザ-日からなり、15%のユーザ-日が高リスクとして分類されている状態でバランスがとられていない状態で残る。

データは、XGBoost Example Modelを使用するとき、%なしのしきい値モデル下での75%の高リスク日と比較して、1回のイベントを有する日の98%が高リスクと分類されたことを示した。精度のこの著しい改善は、デバイスが何らかの所与の高リスクレスキュー利用イベントを認識できない可能性を低減させる。加えて、XGBoost Example Modelは、次に、上記で論じた、個々の患者の日々の利用イベントの正確に切り取られた分布に対する問題に対処する。

V.B.実施例2
図7Bは、レスキュー利用イベントの前の時間期間総和の割合(たとえば、5%)としてベースラインリスクしきい値を設定する理由を説明する。前のモデル(本明細書で、「V1」と呼ばれる)は、AUCスコア、正確な測定値、ならびに感度示度および特異性示度の最適な組合せ(サンプルセットはデータの30,790患者日を有する前のデータに基づいていた)を条件として、イベントの26%を高リスク(すなわち、「1」と標示)として分類した。同様のモデルの他の同様の反復も、20%以上の患者日を高リスクとして分類した。これは、大部分の患者日が高リスクである、調査され、別個に識別された測定値と比較して非現実的である。XGBoost Example Modelに対してトレーニングデータセットを設計するとき、5%のしきい値は、従来決定される、高リスク日の比率(図7aによって示されるように、5%未満)をよりよく表すことが分かった。XGBoost Example Modelをトレーニングするために、5,202名のユーザおよび178,920日のユーザ-日からなるトレーニングデータが構築された。モデルトレーニングを改善するために、トレーニングセットのバランスをとるようにサブサンプリング技法が使用されている(たとえば、0および1と標示されたイベントの同数)。

V.C.実施例3
図7Cは、XGBoost Example Modelに対する同じ性能基準を示す。トレーニングセットおよびテストデータセットは、図7Aで識別された同じデータである。これらの性能基準は、V1モデルの測定値から有効性の低下を示唆しているが、GBoost Example Modelは、V1モデルの欠陥に対処する。特異性の低下の一部は、低リスク日が高リスク日よりも著しく多いことに起因し得る。85%の低リスクイベントと比較して、XGBoost Example Modelのテストセットのイベントの15%のみが高リスクであった。比較的に、V1テストセットは、単に78%の低リスクイベントであった。加えて、XGBoost Example Modelは、V1モデルと比較して、そのリスク分析およびリスク分類の性能の点で追加のパラメータを考慮する。

V.D.実施例4
図7Eは、XGBoost Example Modelによって、高リスク、中リスク、および低リスクとして分類されたテストセットからの日の分布を表示する。低リスクと見なされる日は、54%でテストセットの大部分を構成し、その後に38%で中リスクと見なされる日、および7%で高リスクと見なされる日が続く。このリスクカテゴリー分布は、低リスクおよび中リスクの予測が高リスク予測をはるかに上回る、V1モデルによって生成された分類と大まかに一致する。具体的には、V1モデルにおいて、低リスク予測は、テストセットの49%を占め、中リスク予測は32%を占め、高リスク予測は20%を占める。

V.E.実施例5
図7Fは、上記で説明したXGBoost Example Modelに対するテストデータセットに基づいて、日々のレスキューイベント総数によるリスク予想を表すレスキューイベントの分布を分類する。低リスクとして分類された日のうち、大部分の日は0回のイベントを有するが、日々がより多くのイベントを記録した稀な事例が存在した。中リスクカテゴリー内で、大部分の日は0回のイベントを有し、大部分の日は、1～3回のレスキューイベントおよび3～6回のレスキューイベントを有する。低リスクカテゴリーで分かるように、日々がより多い数のイベントを記録した稀な事例が存在した。高リスクカテゴリー内に、前のカテゴリーと比較して、0回のイベントを有する少数の記録が存在したが、1日に1～3回、3～6回、6～10回、および10回以上のイベントの範囲内により多くの記録が存在した。図7Eのデータと同様に、XGBoost Example Modelからの予測傾向は、V1モデルと同じ一般的な分布をたどり、より多い日数が高リスクと分類された6回以上のイベントを記録した。

V.F.実施例6
図7Gは、XGBoost Example Modelにおけるユーザの大部分にわたるリスクスコア分散を説明する。分析を実行するために、上記で説明した同じテストデータセットが使用された。テストデータセット内で、患者のおよそ10%が確実にCOPDであると診断された。テストセットで考慮された患者はすべて、6日以上に相当する累積データを有した。ユーザのうちの1%のみが日々の90%が高リスクと分類されることを見出し、ユーザの4%のみが日々の90%が中リスクと分類されることを見出し、ユーザの5%のみが日々の90%が低リスクと分類されることを見出した。比較して、ユーザの89%が、単独で90%規模の過半数を示すリスクカテゴリーを1つも有さない、変動するリスクカテゴリーを見出した。変動するリスクカテゴリーの患者数は、パラメータ値がコンテキストデータに関連するか、またはイベントデータに関連するかにかかわらず、このモデルがパラメータ値の変化に非常に敏感であることを示唆している。これは、ユーザの64%が変動するリスクスコアを経験しているV1モデルに対する比較によってさらに証明されるが、これは、V1モデルが明らかにしているパラメータがより少なく、コンテキストデータおよびイベントデータの変化に対する感度がより低かったためである。

V.G.実施例7
図7Dは、XGBoost Example Modelのいくつかのパラメータを図示し、リスク分析決定におけるパラメータの重要性を表す重要度スコアをそれぞれのパラメータに割り当てる。様々なパラメータの重要性の決定は、モデルがそれらのパラメータに関連付けるパラメータ値を決定するモデルのトレーニングの間に完了する。したがって、トレーニングデータセットは、図7A～図7Bを参照して説明した特徴と一致する。モデルパラメータおよびテストデータに基づいて、最も重要なパラメータは過去のパラメータであり、患者がPropeller Health(商標)を使用した日数のスコアは0.08である。最も重要なコンテキストパラメータはSO₂の濃度、風速、温度、PM_1.0、PM_2.5、NO₂濃度、およびO₃濃度であり、これらはすべて0.07のスコアであり、そのすべてがV1モデルによって考慮されなかった。

V.H.実施例8
図7Hは、患者がPropeller Health(商標)システムを使用して監視されている最初の7日にわたるレスキューパフの平均数を記述する。レスキューパフの平均数は、上記で説明したテストデータセットを使用して決定された。改善されたデータセットを考慮すると、プロットは、このとき、Propeller Health(商標)の一般的なレスキュー曲線をより密に模擬しており、V1に対するXGBoost Example Modelの改善を示唆する。さらに、これは、監視が、第1週目の時間期間内でレスキュー吸入器利用において著しい改善をもたらすことを示しており、本明細書で説明する監視および調和的な通知が患者のレスキュー吸入器使用の低減に役立ち得ることを示唆している。

V.I.実施例9
図7Iは、最初の7日のそれぞれの日に高リスクであると見なされたユーザの人数を記述する、平均的な最初の7日間のトレーニングデータセットからのデータをさらに特徴付ける。全体として、毎日、V1モデルと比較して、高リスクユーザの割合の減少を表しており、最初の1週間の間の使用経験全体における改善を示唆している。具体的には、1日目に、VIモデルのユーザの35%と比較して、XGBoost Example Modelテストセットのユーザの27%が高リスクと見なされた。それぞれ、ユーザの37%、38%、31%、31%、30%、および29%が高リスクと分類されたと決定されたVIモデルと比較して、2日目から7日目の間、それぞれ、XGBoost Example Modelユーザの14%、24%、27%、18%、13%、および15%が高リスクと分類された。

VI.利益
患者111および提供者112に提供される喘息レスキューイベントリスク通知は、多くの利益をもたらす。患者は、その喘息レスキューイベントのリスクについてリアルタイムまたはニアリアルタイムで(数秒から数分程度で)知らされ、たとえば、その長期管理薬に対するアドヒアランスを改善することによって、悪条件(たとえば、大気汚染濃度)を有する地理的エリアに近寄らないことによって、その処方された薬療法を追加または改正すること(投薬の調整または抗生物質もしくは全身性副腎皮質ステロイドの導入など)、またはレスキュー薬の使用の最近の急上昇に対処するために医師の予約をスケジュールし、患者にとって緊急治療室および病院訪問の頻度を低減することによって、その発生を防ぐための措置を講じることができる。イベントデータは、患者入力の必要なしに、アプリケーションサーバ130に自動的に報告されるため、医療提供者112または他のエンティティによって手作業で収集されたデータと比較して、イベントデータの精度および品質が改善され、したがって、喘息レスキューイベントのリスクに対する結論の精度がやはり改善される。

加えて、他の患者による手近なレスキュー薬イベントの報告を含めて、アプリケーションサーバ130によって提供される補足通知は、同様の問題を患っている他者に関する追加情報を患者に提供し、患者の意思決定に関連する地域情報を提供することができる。補足通知は、そのアドヒアランス薬の服用を向上させるようにユーザにさらに促しうる。理想的には、そのような通知は、喘息レスキューイベントの発生を防ぎ、したがって、患者が害を受けること、ならびに病院訪問およびそれらに関連するコストを防ぐことになる。

その患者の喘息レスキューイベントリスクのうちの1つまたは複数に対するリスクについて知らされた医療提供者は、その患者の向上を同様に追跡すること、情報を用いてそれぞれの患者に対するその治療療法を改善すること、患者との予約をスケジュールすることなどが可能である。喘息レスキューイベントの高リスクにある患者の場合、通知は、医療提供者が、患者と通信し、患者が医療を求めるように促すための措置に対する呼びかけであり得る。補足通知は、領域的な影響(たとえば、汚染)、患者の長期管理薬アドヒアランスなどに関する情報を提供し得る。

VII.追加の考慮事項
上記の議論は、特に、喘息に焦点を当てているが、本明細書で説明したすべてのシステムおよびプロセスは、概して、COPDおよび慢性呼吸疾患(CRD)に等しく適用可能であり、結果として、COPDおよびCRD、ならびに喘息の治療を支援するためにやはり使用され得る。

本開示の図面および説明は、明快のために、一般的なシステムに見出される多くの他の要素を除外すると同時に、本開示の明確な理解のために関連する要素を示すために簡素化されていることを理解されたい。本開示の実装において他の要素および/またはステップが望ましく、かつ/または必要とされることを当業者は認識されよう。しかしながら、そのような要素およびステップは、当技術分野でよく知られており、それらの要素およびステップは、本開示のよりよい理解を促さないため、そのような要素およびステップに関する議論は本明細書で提供されていない。本明細書の開示は、当業者に知られているそのような要素および方法に対するすべてのそのような改変および変更を対象とする。

上記の説明のいくつかの部分は、情報に対する動作のアルゴリズムおよび記号表現の点で実施形態について説明している。これらのアルゴリズム記述および表現は、その作業の内容を他の当業者に効果的に伝えるためにデータ処理技術の当業者によって一般に使用されている。これらの動作は、関数的、計算的、または論理的に説明されているが、コンピュータプログラムまたは同様の電気回路、マイクロコードなどによって実装され得ることが理解される。さらに、一般性を失わずに、動作のこれらの構成をモジュールと呼ぶことが時には便利であることも証明されている。説明した動作およびその関連するモジュールは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組合せで実施され得る。

本明細書で使用した、「一実施形態」、または「ある実施形態」に対する参照は、本実施形態に関して説明した特定の要素、特徴、構造、または特性が少なくとも1つの実施形態に含まれることを意味する。明細書における様々な個所での「一実施形態では」という句の出現は、必ずしもすべて同じ実施形態を指すとは限らない。

本明細書で使用する「備える(comprises)」、「備えている(comprising)」、「含む(includes)」、「含んでいる(including)」、「有する(has)」、「有している(having)」、またはそれらの任意の他の変種は、非排他的包括を網羅することを意図する。たとえば、要素のリストを含む、プロセス、方法、物品、または装置は、必ずしもそれらの要素だけに限定されず、明示的に列挙されたまたはそのようなプロセス、方法、物品、または装置に固有の他の要素を含み得る。さらに、それに反して明記されない限り、「または(or)」は、包括的なまたは(or)および排他的なまたは(or)を指す。たとえば、条件AまたはBは以下のうちのいずれか1つによって満たされる:Aは真であり(または、存在し)Bは偽である(または、存在しない)、Aは偽であり(または、存在せず)Bは真である(または、存在する)、また、AとBは両方とも真である(または、存在する)。

加えて、「a」または「an」の使用は、本明細書の実施形態の要素および構成要素を説明するために採用される。これは、単に便利のために行われ、本発明の一般的な意味を与えるためである。本明細書は、1つまたは少なくとも1つを含み、別段を意味することが明らかでない限り、単数形は複数形をやはり含むように読み取られるべきである。

特定の実施形態およびアプリケーションについて示し、説明したが、開示した実施形態は、本明細書で開示したまさにその構造および構成要素に限定されないことを理解されたい。当業者に明らかであろう様々な修正、変更、および改変が、添付の特許請求の範囲で定義する趣旨および範囲から逸脱せずに、本明細書で開示した方法および装置の構成、動作、および詳細に行われ得る。

100 喘息解析システム、COPD解析システム、システム
110 クライアントコンピューティングデバイス、クライアントデバイス
111 患者
112 医療提供者、提供者、緊急支援提供者
115 クライアントソフトウェアアプリケーション、アプリケーション、クライアントアプリケーション
120 薬剤デバイスセンサ、センサ
130 アプリケーションサーバ、サーバ
131 データ分析モジュール、モジュール
140 データベースサーバ、サーバ
150 ネットワーク
160 薬剤デバイス、デバイス、長期管理薬剤デバイス、レスキュー薬剤デバイス、薬剤ディスペンサー、レスキュー薬剤ディスペンサー、ディスペンサー、センサユニット
200 コンピュータ
205 プロセッサ
210 チップセット
211 メモリコントローラ
212 I/Oコントローラ
215 揮発性メモリ、メモリ
220 ネットワークアダプタ
225 入出力(I/O)デバイス
230 記憶装置
235 ディスプレイ
300 ダッシュボード
305 システムメニュー
310 カード、ディスプレイカード、調査タイプカード、調査カード
310a ディスプレイカード
310b ディスプレイカード
315 入力応答、入力
315c 入力応答エリア
410 イベント
430 喘息リスク分析
605 レスキュー吸入器利用イベント、イベントデータ、レスキューイベントデータ
610 ベースライン生成モジュール
615 ベースラインデータベース、データベース
620 過去のデータ、レスキュー吸入器利用イベント、コンテキストデータ、
630 パラメータ値
635 コンテキストデータ、
640 モデル
645 通知モジュール
650 トレーニングデータセット、トレーニングサンプル

Claims (24)

1. 患者に関する一組の過去のレスキュー吸入器利用イベントにアクセスするステップであって、前記一組の過去のレスキュー吸入器利用イベントは、レスキュー吸入器ユニットに取り外し可能に取り付けられ、前記レスキュー吸入器ユニットの薬利用を監視するよう構成された薬剤デバイスセンサによって記録され、過去のレスキュー吸入器利用イベントは、前記レスキュー吸入器ユニットが、レスキュー薬を前記患者に投薬したときに記録される、ステップと、
   前記アクセスされた一組の過去のレスキュー吸入器利用イベントに基づいて、前記患者のための患者固有のベースラインリスクしきい値を決定するステップであって、前記患者固有のベースラインリスクしきい値は、当日に先行する時間期間内に生じた前記過去のレスキュー吸入器利用イベントの割合を表す値に基づいて計算される、ステップと、
   トリガ条件に応じて、
   喘息リスクを予測するためのモデルのための一組のパラメータ値にアクセスするステップと、
   前記当日についての一組の入力値にアクセスするステップであって、前記一組の入力値は、少なくとも１つの過去の患者パラメータ、少なくとも１つの環境条件パラメータ、および少なくとも１つの現在の患者パラメータを含む、ステップと、
   前記一組のパラメータ値、前記一組の入力値、および前記患者固有のベースラインリスクしきい値を、前記患者が前記当日の間にレスキュー利用イベントを経験する可能性を表すリスクスコアを決定するための関数に入力するステップであって、前記関数は、
   前記一組の入力値に基づいて前記当日についてのレスキュー利用イベントの予想カウントを決定するように、および、
   前記当日についての前記レスキュー利用イベントの予想カウントと前記患者固有のベースラインリスクしきい値の比較に基づいて前記リスクスコアを決定するように、
   トレーニングされる、ステップと、
   コンピュータ装置上で提示するために、前記リスクスコアと、前記患者に対して増加した投薬を投薬するための更新されたアドヒアランス計画とに基づいて、前記レスキュー吸入器によって投薬されるレスキュー薬の投薬を増加させる推奨を含む通知を生成するステップと、
   前記レスキュー吸入器ユニットが、前記更新されたアドヒアランス計画に従って、前記患者に対して前記増加した投薬でレスキュー薬を投薬するよう作動されたことの確認を前記薬剤デバイスセンサから受信するステップと、
   を含む、方法。
2. 前記一組の過去のレスキュー吸入器利用イベントを前記薬剤デバイスセンサに通信可能に結合されたクライアントデバイス、前記レスキュー吸入器ユニットに結合されたアタッチメント、または前記レスキュー吸入器ユニットから受信するステップ
   をさらに含む、請求項1に記載の方法。
3. 前記患者固有のベースラインリスクしきい値は、前の期間に基づいて決定され、前記前の期間は、前記当日に先行する時間の窓からのイベントを含む、請求項1に記載の方法。
4. 前記患者固有のベースラインリスクしきい値は、前記前の期間中に記録された前記レスキュー利用イベントの総和の割合として決定される、請求項3に記載の方法。
5. 前記患者固有のベースラインリスクしきい値は周期的に決定される、請求項1に記載の方法。
6. 前記トリガ条件は、前記クライアントデバイスの物理的位置のしきい値変更を含む、請求項1に記載の方法。
7. 前記トリガ条件は、時間間隔の周期的終結を含む、請求項1に記載の方法。
8. 前記トリガ条件は、過去の患者パラメータ、環境条件パラメータ、および現在の患者パラメータのうちの少なくとも1つの入力値のしきい値変更を含む、請求項1に記載の方法。
9. 前記トリガ条件は、前記レスキュー吸入器ユニットに取り外し可能に取り付けられた前記薬剤デバイスセンサによって検出される現在のレスキュー吸入器利用イベントを含み、前記レスキュー吸入器ユニットは、前記現在のレスキュー吸入器利用イベントに応じて前記レスキュー薬を前記患者に投薬する、請求項1に記載の方法。
10. 前記一組のパラメータ値の各パラメータ値は、ブーストされた勾配モデルを用いて決定される、請求項1に記載の方法。
11. 前記リスクスコアは、前記患者固有のベースラインリスクしきい値を超える前記当日のレスキュー利用イベントの数を前記患者が経験することになる可能性を表す数値である、請求項1に記載の方法。
12. 前記パラメータは、少なくとも1つの過去の患者パラメータを含み、
    過去の患者パラメータは、
    レスキュー利用イベントの累積患者履歴、
    夜間に発生するレスキュー利用イベントの患者履歴、
    前記患者が前記レスキュー吸入器ユニットを使用する日の累積カウント、
    疾患タイプ、および
    アドヒアランス記録
    をさらに含む、請求項1に記載の方法。
13. 前記パラメータは、少なくとも1つの現在の患者パラメータを含み、
    現在の患者パラメータは、
    前記クライアントデバイスの現在の経度および緯度位置、
    現在の位置、
    現在の日付、および
    前記レスキューイベントに対して服用され、処方されたレスキューパフの数の差異
    をさらに含む、
    請求項1に記載の方法。
14. 前記パラメータは、少なくとも1つの大気汚染物質パラメータを含み、
    前記大気汚染物質パラメータは、
    オゾン分子(O₃)、
    二酸化窒素分子(NO₂)、
    二酸化硫黄分子(SO₂)、
    2.5マイクロメートル以下の粒子物質(PM_2.5)、
    1マイクロメートル以下の粒子物質(PM_1.0)、および
    大気質指数(AQI)
    をさらに含む、
    請求項1に記載の方法。
15. 前記パラメータは、少なくとも1つの気象パラメータを含み、
    前記気象パラメータは、
    温度、
    湿度、
    風速、
    風向、
    現地気圧、および
    視程
    をさらに含む、請求項1に記載の方法。
16. 前記パラメータは、
    温度、
    相対湿度、
    風速パラメータ、
    二酸化窒素(NO₂)、
    二酸化硫黄(SO₂)、
    2.5マイクロメートル以下の粒子物質(PM_2.5)、および
    1マイクロメートル以下の粒子物質(PM_1.0)
    のうち１つ又は複数を含む、請求項1に記載の方法。
17. 前記パラメータは、レスキュー吸入器利用イベントが、前記レスキュー吸入器ユニットに結合されたコンピューティングシステムによって監視される日数を含む、請求項1に記載の方法。
18. 前記関数は、所与の日に対するレスキュー吸入器利用イベントのカウントが前記しきい値を超えるかどうかを決定する、請求項1に記載の方法。
19. 前記リスク通知は、前記患者固有のベースラインリスクしきい値が決定された後において提示される、請求項1に記載の方法。
20. 前記リスク通知は、前記トリガ条件に関する情報コンテンツを含む、請求項1に記載の方法。
21. 前記リスク通知は、
    前記レスキュー利用イベント、
    前記患者固有のベースラインリスクしきい値、および
    前記リスクスコアに基づくリスク分類
    のうちの少なくとも1つに関する情報コンテンツを含む、請求項1に記載の方法。
22. 前記リスク通知は、先行する時間期間と比較したリスク分類の変更の原因となるパラメータのサブセットをさらに含む情報コンテンツをさらに含む、請求項1に記載の方法。
23. 前記リスク通知は、リスク分類の前記変更の原因となるパラメータのサブセットによって生ずる将来のレスキュー吸入器イベントをどのように防ぐかに関する推奨をさらに含む情報コンテンツをさらに含む、請求項1に記載の方法。
24. コンピュータプログラム命令を備えた非一時的コンピュータ可読記憶媒体であって、前記命令は、コンピュータプロセッサによって実行されると、前記プロセッサに、
    患者に関する一組の過去のレスキュー利用イベントにアクセスすることであって、前記一組の過去のレスキュー吸入器利用イベントは、レスキュー吸入器ユニットに取り外し可能に取り付けられ、前記レスキュー吸入器ユニットの薬利用を監視するよう構成された薬剤デバイスセンサによって記録され、過去のレスキュー吸入器利用イベントは、前記レスキュー吸入器ユニットが、レスキュー薬を前記患者に投薬したときに記録される、ことと、
    前記アクセスされた一組の過去のレスキュー吸入器利用イベントに基づいて、前記患者のための患者固有のベースラインリスクしきい値を決定することであって、前記患者固有のベースラインリスクしきい値は、当日に先行する時間期間内に生じた前記過去のレスキュー吸入器利用イベントの割合を表す値に基づいて計算される、ことと、
    トリガ条件に応じて、
    喘息リスクを予測するためのモデルのための一組のパラメータ値にアクセスすることと、
    前記当日についての一組の入力値にアクセスすることであって、前記一組の入力値は、少なくとも１つの過去の患者パラメータ、少なくとも１つの環境条件パラメータ、および少なくとも１つの現在の患者パラメータを含む、ことと、
    前記一組のパラメータ値、前記一組の入力値、および前記患者固有のベースラインリスクしきい値を、前記患者が前記当日の間にレスキュー利用イベントを経験する可能性を表すリスクスコアを決定するための関数に入力することであって、前記関数は、
    前記一組の入力値に基づいて前記当日についてのレスキュー利用イベントの予想カウントを決定するように、および、
    前記当日についての前記レスキュー利用イベントの予想カウントと前記患者固有のベースラインリスクしきい値の比較に基づいて前記リスクスコアを決定するように、
    トレーニングされる、ことと、
    コンピュータ装置上で提示するために、前記リスクスコアと、前記患者に対して増加した投薬を投薬するための更新されたアドヒアランス計画とに基づいて、前記レスキュー吸入器によって投薬されるレスキュー薬の投薬を増加させる推奨を含む通知を生成することと、
    前記レスキュー吸入器ユニットが、前記更新されたアドヒアランス計画に従って、前記患者に対して前記増加した投薬でレスキュー薬を投薬するよう作動されたことの確認を前記薬剤デバイスセンサから受信することと、を行わせる、非一時的コンピュータ可読記憶媒体。

Images