(57)【要約】  本明細書は、レスキューイベントおよび悪化が発生するのを防ぐ目的で、患者に知らせ、行動変化に影響を及ぼすために、地理的領域に対するリスク通知を提供する。地理的領域に対するリスク分析は、地理的領域内で呼吸イベントを経験する可能性がある患者の母集団から集められたデータに基づく。レスキュー薬イベント、レスキュー薬イベントに関連する環境条件、および他のコンテキスト的に関連する情報は、患者の母集団の薬剤デバイスに関連するセンサーによって検出され、リスクスコアを決定するための基礎を提供するために、それぞれ、他のソースから集められる。このデータは、地理的領域内で発生する呼吸イベントのリスクの深刻さを決定し、それに応じて、その地理的領域内の患者に通知を送信するために分析される。
2021525417.tif 000002
【特許請求の範囲】
【請求項１】
地理的領域内の患者の母集団に発生した過去のレスキュー吸入器利用イベントのセットにアクセスするステップであって、各イベントが、クライアントデバイス、およびレスキュー吸入器ユニットに関連するアタッチメントのうちの1つから、または前記レスキュー吸入器ユニットから前に受信され、各レスキュー吸入器ユニットが、前記イベントの各々の一部としてレスキュー薬を前記地理的領域内の前記患者のうちの1人に提供した、アクセスするステップと、
イベントの前記セットに基づいて、領域固有のベースラインリスクしきい値を決定するステップと、
トリガ条件に応じて、
前記領域に対する喘息リスクを予測するためのモデルに対するパラメータ値のセットにアクセスするステップと、
入力値のセットにアクセスするステップと、
前記パラメータ値、前記入力値、および前記ベースラインリスクしきい値を、前記領域に対するリスクスコアを判定するための関数内に入力するステップと、
前記リスクスコアに基づいて、前記クライアントデバイスのうちの少なくとも1つに通知を送信するステップと
を含む、方法。
【請求項２】
前記過去のレスキュー吸入器利用イベントを前記クライアントデバイス、前記アタッチメント、または前記レスキュー吸入器ユニットから受信するステップ
をさらに含む、請求項1に記載の方法。
【請求項３】
前記しきい値が、前の期間に関して決定され、前記前の期間が、現在の時刻に先行する時間の窓からのイベントを含む、請求項1に記載の方法。
【請求項４】
前記しきい値が、前記前の期間内の前記イベントの総和の割合として決定される、請求項3に記載の方法。
【請求項５】
前記しきい値が周期的に決定される、請求項1に記載の方法。
【請求項６】
前記トリガ条件が、前記クライアントデバイスの物理的位置内のしきい値変更を含む、請求項1に記載の方法。
【請求項７】
前記トリガ条件が、時間間隔の周期的結論を含む、請求項1に記載の方法。
【請求項８】
前記トリガ条件が、複数のパラメータのうちの少なくとも1つの前記入力値内のしきい値変更を含む、請求項1に記載の方法。
【請求項９】
前記パラメータ値が、ブーストされた勾配モデルを使用して決定される、請求項1に記載の方法。
【請求項１０】
前記リスクスコアが、前記地理的領域内のユーザまたは前記領域がその日に前記しきい値を超えることになる可能性を表す数値価である、請求項1に記載の方法。
【請求項１１】
前記パラメータが、少なくとも1つのコンテキストデータパラメータを含む、請求項1に記載の方法。
【請求項１２】
前記パラメータが、
前記クライアントデバイスの現在の緯度および経度座標、
地理的領域、
現在の日付、
前記患者に対して服用され、処方されたコントローラパフの数における差異、および
前記レスキューイベントに対して服用されたレスキューパフのカウント
をさらに含む、少なくとも1つの現在の領域パラメータ
のうちの1つまたは複数を含む、請求項1に記載の方法。
【請求項１３】
前記パラメータが、
オゾン分子(O3)の濃度、
二酸化窒素分子(NO2)の濃度、
二酸化硫黄分子(SO2)の濃度、
一酸化炭素分子(CO)の濃度、
二酸化炭素分子(CO2)の濃度、
2.5マイクロメートル以下の粒子物質(PM2.5)、
1マイクロメートル以下の粒子物質(PM1.0)、および
大気質指数(AQI)
をさらに含む、少なくとも1つの大気汚染物質パラメータ
のうちの1つまたは複数を含む、請求項1に記載の方法。
【請求項１４】
前記パラメータが、
温度、
湿度、
風速、
風向、
現地気圧、
降水量、
雷雨、および
視程
をさらに含む、少なくとも1つの気象パラメータ
のうちの1つまたは複数を含む、請求項1に記載の方法。
【請求項１５】
前記パラメータが、
温度、
相対湿度、
風速、
二酸化窒素(NO2)、
二酸化硫黄(SO2)、
2.5マイクロメートル以下の粒子物質(PM2.5)、および
1マイクロメートル以下の粒子物質(PM1.0)
を含む、請求項1に記載の方法。
【請求項１６】
前記リスク通知が、前記リスクしきい値が決定される第2の時間とは異なる第1の時間に提示される、請求項1に記載の方法。
【請求項１７】
前記リスク通知が、前記トリガ条件に関する情報コンテンツを含む、請求項1に記載の方法。
【請求項１８】
前記リスク通知が、
前記トリガイベント、
前記ベースライン領域リスクしきい値、および
前記領域リスクスコアに基づくリスク類別
のうちの少なくとも1つに関する
情報コンテンツを含む、請求項1に記載の方法。
【請求項１９】
前記リスク通知が、前記レスキューイベントに関する情報コンテンツをさらに含み、前記情報コンテンツが、前の時間期間と比較したリスク類別の変更の原因となるパラメータのサブセットをさらに含む、請求項1に記載の方法。
【請求項２０】
前記リスク通知が、前記レスキューイベントに関する情報コンテンツをさらに含み、前記情報コンテンツが、将来のレスキュー吸入器イベントをどのように防ぐかに関する推奨をさらに含み、前記推奨が、リスク類別内の前記変更の原因となるパラメータのサブセットに基づく、請求項1に記載の方法。
【請求項２１】
コンピュータプログラム命令を備えた非一時的コンピュータ可読記憶媒体であって、前記命令が、コンピュータプロセッサによって実行されると、前記プロセッサに、
地理的領域内で患者の母集団に発生した過去のレスキュー吸入器利用イベントのセットにアクセスすることであって、各イベントが、クライアントデバイス、およびレスキュー吸入器ユニットに関連するアタッチメントのうちの1つから、または前記レスキュー吸入器ユニットから前に受信され、各レスキュー吸入器ユニットが、前記イベントの各々の一部としてレスキュー薬を前記地理的領域内の前記患者のうちの1人に提供した、アクセスすることと、
イベントの前記セットに基づいて、領域固有のベースラインリスクしきい値を決定することと、
トリガ条件に応じて、
前記領域に対する喘息リスクを予測するためのモデルに対するパラメータ値のセットにアクセスすることと、
入力値のセットにアクセスすることと、
前記パラメータ値、前記入力値、および前記ベースラインリスクしきい値を、前記領域に対するリスクスコアを決定するための関数内に入力することと、
前記リスクスコアに基づいて、通知を前記クライアントデバイスに送信することと
を行わせる、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に、呼吸器疾患を治療するための吸入器に関するアタッチメントに関し、また地理ベースの呼吸器疾患推定モデルに関する。
【背景技術】
【０００２】
喘息は、依然として重要かつ費用のかかる公衆衛生上の問題である。世界的に、世界保健機関は、喘息を患う人口は3億人になり得ると推定し、その人口は2025年までに4億人に増えると予測している。合衆国では、喘息は、合衆国の12人に1人に及び、患者数は上昇傾向にあり、年間820億ドルを超える直接および間接コストの原因となっている。
【０００３】
新しい薬の開発にもかかわらず、入院および緊急治療室の訪問率は下がっていない。合衆国では毎年、この疾患は、およそ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
【発明の概要】
【課題を解決するための手段】
【０００８】
解析システムは、喘息、またはCOPDなどの他の呼吸器疾患によって生じるレスキューイベントを治療し、監視し、管理するための統合プラットフォームである。一例として喘息を使用すると、解析システムは、解析システムをその喘息の管理に役立てることを許可した患者の母集団によって使用される薬剤デバイス(たとえば、吸入器)にアタッチされたセンサーからイベント通知を受信することによって、地理的領域内で発生する喘息レスキュー薬イベントを追跡する。センサーは、定服用量吸入器または他の薬剤デバイスにアタッチされるかまたはその中に統合されるとき、レスキュー利用イベントの地理的位置、時間、および日付を記録し、その情報を解析システムに通信する。解析システムは、受信イベント(最近の受信イベントと前の受信イベントの両方)をリアルタイムまたはニアリアルタイムで分析し、リスク評価、および疾患を指導し管理するための情報を通知の形で患者、介護人、医療提供者、および一般の人々に配信する。
【０００９】
地理的領域に対するリスクスコアは、患者の母集団から受信されたレスキューイベントの記録、および大気条件、気象条件、大気質条件に関する環境条件を含むパラメータと、その地理的領域に対する構築環境条件に関する環境条件の組合せを使用して決定される。これらのパラメータとその地理的領域に対して生成されたリスク評価との間の関係は、機械学習モデル内で実施される。モデル、および、より一般的に、システムは、パラメータに関する入力値を受信し、リスクを緩和するための、その地理的領域内の患者に対する正確かつ医療的に関連する治療オプションとともにリスク評価を提供するために、領域のリスクスコアを類別する(categorizing)ことが可能である。
【００１０】
他のコンテキスト的に関連するパラメータ情報とともに、薬の利用のタイミング、頻度、および位置に関する情報を取り込むことによって、解析システムは、それらの予測イベントに先立って、行動において直ちに適用可能な変更を示唆することによって、将来の喘息レスキュー利用イベントの発生を防ぐのに役立つ。これは、患者およびその医療提供者による喘息治療のよりよい管理を促し、患者が将来これらの位置を回避するかまたは対応することができるように、レスキューイベントを引き起こす特定の位置の認識を改善する。
【００１１】
地理的領域に対するリスク分析を記述する情報は、呼吸器疾患を患っている患者が異なる地理的領域に対して情報に基づく生活様式の選択を行うことを可能にする。たとえば、不動産を検索するとき、高い呼吸器症状リスクを有する地理的領域を除外する能力は、患者がその健康を改善するために情報に基づく選択を行うことを可能にする。同様に、旅行するとき、地域に関するリスクの事前知識は、患者が必要な予防措置を整えることを可能にする。結果として、地理的領域に対するリスク分析は、その位置がどこであれ、その呼吸イベントのリスクを低減するために必要な予測知識を患者、介護人、提供者、および一般の人々に提供する。
【００１２】
ある実施形態によれば、地理的領域に対する呼吸関連レスキューイベントのリスクを決定するための方法は、患者の母集団に対する過去のレスキュー吸入器利用イベントのセットにアクセスするステップを含む。各イベントは、クライアントデバイス、またはレスキュー吸入器ユニットに関連するアタッチメントから、または、各イベントの一部としてレスキュー薬を地理的領域内の患者のうちの1人に提供したレスキュー吸入器ユニットから前に受信されている。この方法はまた、イベントのセットに基づいて、領域固有のベースラインリスクしきい値を決定するステップを含む。トリガ条件に応じて、この方法は、その領域に対する喘息リスクを予測するモデルに対するパラメータ値のセットにアクセスするステップと、入力値のセットにアクセスするステップとを含む。また、トリガ条件に応じて、この方法は、パラメータ値、入力値、およびベースラインリスクしきい値を、領域に対するリスクスコアを決定するための関数内に入力するステップを含む。トリガ条件に応じて、この方法は、クライアントデバイスのうちの少なくとも1つにリスクスコアの詳細を備えた通知を送信するステップを含む。
【００１３】
1つまたは複数の実施形態では、この方法は、レスキュー吸入器利用イベントの履歴をクライアントデバイス、アタッチメント、またはレスキュー吸入器ユニットから受信するステップをやはり含む。
【００１４】
1つまたは複数の実施形態では、しきい値は、現在の時刻に先行する時間窓からのイベントを含む前の期間、また毎月または数年にわたり季節ごとになど、同様の時間期間にわたる比較に対して決定される。
【００１５】
1つまたは複数の実施形態では、しきい値は、前の期間内のイベントの総和の割合として決定される。
【００１６】
1つまたは複数の実施形態では、しきい値は周期的に決定される。
【００１７】
1つまたは複数の実施形態では、トリガ条件は、クライアントデバイスの物理的位置内のしきい値変更を含む。
【００１８】
1つまたは複数の実施形態では、トリガ条件は、時間間隔の周期的結論を含む。
【００１９】
1つまたは複数の実施形態では、トリガ条件は、複数のパラメータのうちの少なくとも1つの入力値内のしきい値変更を含む。
【００２０】
1つまたは複数の実施形態では、パラメータ値は、機械学習モデルを使用して決定される。
【００２１】
1つまたは複数の実施形態では、リスクスコアは、患者がその日にしきい値を超えることになる可能性を表す数値価である。
【００２２】
1つまたは複数の実施形態では、パラメータは、少なくとも1つのコンテキストデータパラメータを含む。
【００２３】
1つまたは複数の実施形態では、パラメータは、クライアントデバイスの現在の緯度および経度座標、現在の位置、現在の日付、患者に対して服用され、処方されたコントローラパフ(controller puffs)の数の差異、およびレスキューイベントに対して服用されたレスキューパフ(rescue puffs)のカウントをさらに含む、少なくとも1つの現在のパラメータを含む。
【００２４】
1つまたは複数の実施形態では、パラメータは、オゾンの濃度測定値、二酸化窒素の濃度測定値、二酸化硫黄の濃度測定値、一酸化炭素の濃度測定値、二酸化炭素の濃度測定値、2.5マイクロメートル以下の粒子物質、1マイクロメートル以下の粒子物質、他の大気汚染物質、および大気質指数をさらに含むが、これらに限定されない、少なくとも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つに応じて、任意の時点で実行されてよい。
【００６０】
他の分析も可能である。具体的には、喘息に関して実行され得る分析は、COPDに関して実行される分析と同様であってよい。したがって、アプリケーションサーバは、本明細書で説明する喘息リスク分析と同様の方法でCOPDリスク分析を実行し得る。この概念は、本明細書で説明するセンサー120によって追跡される他の呼吸器疾患にも拡張され得る。
【００６１】
より大まかに、(たとえば、喘息、COPD、または他の呼吸器疾患に対する)リスク分析は個々の、地理的、臨床的、疫学的、人口統計的、または空間的もしくは時間的なベースラインまたは予測もしくは予想される値からの過去の著しい置換に基づく薬使用の空間的/時間クラスタ(または、突然の発生)に基づいて識別するために複数の患者に関するレスキュー薬使用および長期管理薬使用に対して実行され得る。他のタイプの分析は、日々の/毎週のアドヒアランス傾向、経時的なアドヒアランス変化、他の関連母集団(たとえば、すべての患者、特定のレスキュー薬もしくは長期管理薬またはそれらの組合せを受けている患者)に対するアドヒアランス比較、トリガの識別情報(空間的、時間的、環境的)、経時的なレスキュー使用傾向、および他の関連母集団に対するレスキュー使用比較、ならびに個々のレスキュー傾向と同様のユーザまたは地理的に同じ場所に位置するユーザのより大きな母集団との関係を含み得る。
【００６２】
実行された任意の分析に応じて、アプリケーションサーバ130は、患者111、許可を受けた医療提供者112、および/または患者のプロファイルに対するアクセスが提供された他のユーザに送信するためのプッシュ通知を準備して配信するように構成される。通知は、薬レスキューイベントに関与するタイミング、位置、および影響を受けた患者111に関する詳細を提供し得る。通知は、加えて、緊急支援提供者112に配布される緊急支援を要求する苦痛信号または緊急信号を含み得る。通知は、データ分析モジュール131によって実行されるリスク分析の結果を含んでもよい。送信され得る通知のタイプおよびそれらが含み得るコンテンツに関するより多くの情報について、下記でさらに説明する。
【００６３】
リスク分析に応じてプッシュ通知を提供することに加えて、リスク分析からの情報は、ウェブサイト、クライアントデバイス110アプリケーション、または他のサーバによって提供されたデータプラットフォームを通してなど、他の方法で提供されてもよい。1つの特定の例では、リスク分析からの情報は、特定の時間間隔において、プル通知として提供されてもよい。加えて、レスキュー薬イベントに応じて実行されたリスク分析に応じてではなく、代わりに、更新された通知が保証されるように、リスク分析における基本的な要因のうちの1つの(たとえば、単位だけまたは割合だけしきい値を超える)変化に応じて実行されたリスク分析に応じて、いくつかの通知(プッシュであるかプルであるかにかかわらず)がトリガされ得る。たとえば、大気質状態が大気汚染の増大が発生しているかまたは差し迫っていることを指示する場合、これは、たとえば、クライアントデバイス110、センサー120、および/または薬剤デバイス160位置報告に基づいて判定されるように、汚染が発生している特定の地理的エリア内に現在位置するすべての患者に対してリスク分析の実行をトリガし得る。
【００６４】
通知は、クライアントアプリケーションと使用するように具体的に設計されたデータフォーマットで、ネットワーク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は、多くの物理的に別個の、局所的にネットワーク接続されたコンピュータを含んでよく、これらは各々、上記で紹介した喘息リスク分析を実行するためのかなりの量の処理電力を有する。一実施形態では、Amazon Web Services(商標)などのサービスによって提供されるアプリケーションサーバ130の処理電力。やはり対照的に、データベースサーバ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は、一実施形態による、薬剤デバイス監視に基づいて喘息リスク通知を提供するための対話図を示す。上記で紹介したように、このプロセスは、その一例がCOPDである、何らかの他のタイプの呼吸器疾患に対するリスク通知の提供に等しく適用可能である。最初のステップとして、患者は、患者プロファイルを開始する(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上に含む。これらのリスク分析は、そのレスキュー吸入器の利用を余儀なくさせることになる、喘息イベントまたはCOPDイベントなど、呼吸イベントの発生をできれば回避するために十分適時に患者に送信されるように特に構成された通知を生成するために使用される。
【０１０４】
リスク分析を実行するために、数学関数または他のより複雑な論理構造などのモデル640は、予め記憶され、リスク分析の一部として使用される、パラメータ値のセットを決定するために、過去のイベントデータおよび過去のコンテキストデータを使用してトレーニングされる。トレーニングに関しては、下記で、セクションIV.Bにおいて、図6Bに関して論じる。パラメータ値630は、入力値のうちの少なくとも1つに関連付けられる「重み」(または、使用されるモデリング技法に応じて、臨界値もしくは他の同様の量)を記述する。入力値は、モデル640のパラメータの数値価またはカテゴリー値を指し、ここで、入力値は、経時的に患者間で異なり得る。
【０１０５】
一実施形態では、リスク分析は、ユーザ単位ではなく、地理的領域単位でデータを入力することによって実行される。この実装形態では、地理的領域は、500フィートエリア、緯度/経度、人口調査標準地域、郵便番号、市の境界線、州の単位など、何らかの基準に従ってセグメント化される。センサー120、クライアントデバイス110、および/または薬剤デバイス160が地理的領域の境界内に物理的に位置した間にイベントが一時的に発生した場合、レスキュー吸入器利用イベント605、および他のコンテキストデータ635が識別される。このデータは、次いで、地理的領域に対する数値リスクスコアを判定するために、モデル640の関数およびパラメータ値630に対する入力値として使用される。いくつかの実施形態では、上記で説明した入力は、ユーザの数、地理的領域の人口密度、および/または地理的領域内でユーザによって費やされる時間量に基づいて正規化される。
【０１０６】
上記のように、入力値として使用するために集められるコンテキストデータは、デバイスまたは他の第三者データ報告に基づいて自動的に収集され得るか、患者の母集団および/または提供者によって手動で提供され得るか、またはさもなければ、取得され得る。この場合、モデル640によって生成されるリスクスコアは、イベントデータ605およびコンテキストデータ635を考慮して、地理的領域が任意のユーザ(または、より一般的に、人物)に喘息(または、他の疾患タイプの)レスキュー利用イベントを経験させることになる可能性を特徴付ける。リスクスコアは、次いで、その時点でその地理的領域に対する現在のコンテキストに特定である、地理的領域に対するリスク類別を指定するために使用されてよく、それらのいずれかまたは両方が通知モジュール645、または、ダッシュボード300など、より一般的なGUIインターフェースを介して、または外部ウェブサイトを通して提供され得る。
【０１０７】
代替実施形態では、リスク分析は、ユーザに対する数値リスクスコアを決定するために、モデル640の関数に対する入力値およびパラメータ値630として、ユーザのレスキュー吸入器利用イベント605および他のコンテキストデータ635の態様を入力することによって実行される。概して、入力値として使用するために集められたコンテキストデータは、デバイスまたは他の第三者データ報告に基づいて自動的に収集され得るか、患者および/または提供者によって手動で提供され得るか、またはさもなければ取得され得る。リスクスコアは、モデル640によって生成される数値価であり、イベントデータ605およびコンテキストデータ635を考慮して、患者が喘息(または、他の疾患タイプの)レスキュー利用イベントを経験する可能性を特徴付ける。リスクスコアは、次いで、その時点でその現在のコンテキストに特定である、ユーザに対するリスク類別を指定するために使用されてよく、それらのいずれかまたは両方が通知モジュール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.入力パラメータ
リスクスコア分析内に組み込まれたパラメータは、いくつかのグループ、すなわち、過去の領域パラメータまたは患者パラメータ、現在の領域パラメータまたは患者パラメータ、大気汚染物質パラメータ、気象パラメータ、およびコンテキストパラメータに類別され得る。過去および現在の領域パラメータおよび患者パラメータは、この実装に基づいて、単に「領域パラメータ」または「患者パラメータ」としてより大まかに類別され得る。大気汚染物質および気象変数は、単に「環境条件パラメータ」としてより大まかに類別され得る。パラメータの数値価は、上記で説明したように、入力値の形態で生成される関数に含まれる。さらに、パラメータからモデルのパラメータ値が導出される。新しいパラメータは、反復モデル開発を通して追加され得る。
【０１１６】
過去の領域の特徴は、一定の時間期間にわたるレスキューイベントの累積領域(または、region)履歴(pr_7_rscu_sum)、領域内でレスキューユニットが使用されている日の累積カウント(norm_day)、領域内の疾患タイプ(disease_asthma)、その領域内で夜間に発生するレスキューイベントの記録、領域的な長期管理薬アドヒランス記録(pr_sun_adh)、または患者報告結果を含み得るが、これらに限定されない。領域データは、所与の領域内の患者に関するデータのアグリゲートに基づいて決定され得る。たとえば、領域に対するレスキューイベントの履歴は、その領域内のすべての患者または患者のサブセットに対するレスキューイベントのコンパイルであり得る。レスキューユニットが使用されている日の累積カウントは、その間にその領域内の患者がレスキューユニットを使用した日の平均であり得る。
【０１１７】
いくつかのパラメータは、患者固有であり、地理的領域リスク分析において使用されない。例は、患者の喘息の深刻さ、ならびに個人的な治療法を含む。同様に、長期管理薬アドヒランス記録は、その長期管理薬の母集団の各患者の使用に関する情報(センサーユニット160にやはり関連し得る)を含み、パラメータとしてやはり使用され得る。この種の特徴の決定は、利用が処方されたが、実行されなかった例、利用が処方され、実行された例、および利用が処方されず、実行された例を観察することによって実行される。
【０１１８】
現在の患者の特徴は、現在の緯度(lat)、経度(lon)、およびクライアントデバイス110の座標の位置、ならびに現在の日付(month,day_of_week)を含み得るが、これらに限定されない。現在の緯度および経度は、そこから患者の環境条件に関する情報が決定され得る、患者の地理的位置を決定するために使用される。現在の薬イベントデータは、服用されたコントローラパフの数と患者に処方された数の差異、ならびにその日にすでに発生した可能性があるあらゆるレスキューイベントのカウント、および、そのレスキューイベントに対して服用されたレスキューパフのカウントなど、それらのイベントに関連する情報をやはり含み得る。これらの現在の患者の特徴の基礎となる特徴はどれも、地理的領域の特徴を決定するためにやはり使用され得る。少なくとも部分的に、この情報は、どの領域内でどのイベントが発生したかを知らせ、その結果、特定のパラメータ(たとえば、その地理的領域内のある時間期間にわたるレスキューイベントの履歴)が決定され得る。
【０１１９】
大気汚染物質の特徴は、濃度に関する情報(たとえば、アナログ値)、または汚染物質の存在または不在のよりバイナリな指示を含み得る。考慮される汚染物質の例は、オゾン分子(o3)、二酸化窒素分子(no2)、二酸化硫黄分子(so2)、一酸化炭素(co)、二酸化炭素(co2)、サイズ2.5マイクロメートル以下の粒子物質(pm2.5)、サイズ10マイクロメートル以下の粒子物質(pm10)、花粉カウント、他の大気汚染物質、および大気質指数を含むが、これらに限定されない。いくつかの実施形態では、大気汚染物質パラメータ値は、環境保護庁および他の第三者データベンダーによって、たとえば、時間単位で回復されたデータから周期的にアクセスされる。したがって、センサー120は、心拍を毎時間受信し、更新された大気汚染物質パラメータ値にアクセスするように呼吸器疾患リスク分析モジュールに催促し得る。
【０１２０】
特定の気象特徴は、温度(drybulbfahrenheit)、湿度(relativeumidity)、風速(windspeed)、風向(wind_direction_cat)、現地気圧(stationpressure)、気象タイプ、露点、視程、降水量、および雷雨を含み得る。大気汚染物質パラメータの記述と同様に、気象パラメータは、第三者サーバ、たとえば、NOAAから周期的にアクセスされ得る。
【０１２１】
コンテキストパラメータは、患者、その生活状態、またはその環境に関する社会的情報を記述する。コンテキストパラメータの例は、社会経済学的要因、人口統計的要因、構築環境要因、土地使用要因、および行動保健要因を含むが、これらに限定されない。領域に関する人口統計的パラメータは、社会的脆弱性指数(SVI)、人種/民族性ごとに分類された領域の構成、年齢、1人当たりの収入、平均世帯規模、および教育水準を含むが、これらに限定されない。SVIは、アメリカ疾病管理予防センターによって開発された包括的な数値基準であり、合衆国におけるあらゆる人口調査標準地域の相対的脆弱性を指示する。SVIは、失業者数、社会的少数者の状況、および身体障害を含む、15個の社会的要因に基づいて、各地域をランク付けする。したがって、領域パラメータ615内に含まれるとき、SVIに割り当てられたパラメータは、地理的標示が位置する人口調査標準地域のランキングである。構築環境パラメータは、合衆国地質調査所など、第三者サーバから周期的にアクセスされる、土地使用タイプ、不浸透面、地表温度、緑の多さ(greenness)(NDVI)、林冠、属性の特性(property characteristics)、産業排出用地、危険物貯蔵所、交通量および道路網に対する近接性、領域内のインフルエンザの活性、および山火事に曝されるリスクを含むが、これらに限定されない、地理的領域に対する測定値を記述する。
【０１２２】
いくつかの実施形態では、コンテキストパラメータは、患者行動における傾向または共通する特徴に基づく領域に対する、社会動向を捕捉するソーシャルデータ、たとえば、喘息検索をやはり含む。たとえば、ユーザの大部分が喘息治療に関してGoogle検索または代替インターネットベース検索を実行する領域が、より高い喘息レスキュー利用イベントリスクに関連付けられる。別の例として、所与の時間期間にわたる吸入器レスキューユニット販売の急激な上昇に関連する領域は、より高い喘息レスキュー利用イベントリスクに関連付けられ得る。したがって、所与の時間期間に対する領域的なリスクスコアを決定するとき、その時間期間に対する領域における社会動向およびユーザ行動が考慮され得る。
【０１２３】
IV.D.しきい値決定
上記で紹介したように、ベースラインリスクしきい値は、モデルトレーニングとリスクスコア計算の両方において使用される。ベースライン生成モジュール610は、その間に(トレーニングの間またはモデル使用の間のいずれかの標示のために)リスクが計算されている当日に先行する指定された前の時間期間にわたる、または、より一般的に、現在の/最近のレスキュー利用イベントの時間に先行する時間期間の間の、利用イベントの総数に基づいて、ベースラインリスクしきい値を計算する。
【０１２４】
一例では、時間期間は、排他的に、当日およびその前の7日に制限された範囲であるが(したがって、考慮から当日のデータを除外する)、14日、ひと月、ある季節、毎年、または複数年にわたることを含むが、これらに限定されない、他の時間期間が使用されてもよい。たとえば、最近作成された領域(または、患者)に関するリスクプロファイル、またはこの時間窓の間に利用イベントが追跡されていないことにより、7日に満たないデータが累積された場合、ベースラインは、代わりに、データが利用可能な日数に基づいて計算されてよい。
【０１２５】
一実施形態では、ベースラインリスクしきい値は、指定された時間期間にわたる領域内の患者の母集団に対する利用イベントの総数の比(割合)として設定される。領域に関するベースラインリスクしきい値は、各領域に関するアグリゲート値、環境的なコンテキストパラメータを患者の母集団に基づいて決定することによって決定され得る。たとえば、ベースライン生成モジュール610は、領域内の患者の母集団に基づいて各入力パラメータに対する平均値を決定し得る。代替として、ベースライン生成モジュール610は、領域内の利用イベントの総数に基づいて入力値を決定し得る。
【０１２６】
いくつかの実装形態では、患者の母集団に対して決定されたベースラインは、同じ領域または比較可能な領域内の別の患者の母集団に対して比較可能であり得るか、または正規化され得る。ベースライン生成器610は、患者を、領域内のその位置に基づく患者(たとえば、共有領域内のすべての患者)、患者パラメータに基づく患者(たとえば、同様の疾患タイプまたはアドヒランス記録を有する患者)、またはそれらの組合せに基づく患者の母集団にグループ化し得る。したがって、患者の母集団の変化がその母集団に対して決定されたベースラインリスクしきい値と比較されるとき、その比較は、母集団の偏った判断を取り除くが、これは、変化とベースラインリスクしきい値は両方とも、同じユーザ母集団を特徴付けるためである。いくつかの実装形態では、各ベースラインリスクしきい値は、たとえば、近隣の地理的領域または国にわたって広がる他の地理的領域内の別の患者の母集団に対して正規化され得る。そのような実施形態では、ベースライン生成器は、他の地理的領域に対する全体的なパーセンタイルとして計算され得る。
【０１２７】
別の実施形態では、ベースライン生成器610は、異なる時間期間の間に領域に対して記録された臨床データの比較に基づいて、領域に関するベースラインリスクしきい値を決定し得る。たとえば、治療、レスキュー利用イベント、および所与の月の間に記録された領域に対する他の患者パラメータを記述する臨床データは、前年の同じ月の間に同じ領域に対して記録された臨床データに基づいて決定されたベースラインリスクしきい値と比較され得る。そのような実装形態では、ベースラインリスクしきい値に対する比較は、臨床データの現在のセットおよび臨床データのベースラインセットが少なくとも時間的条件および環境条件の点で比較可能であることを確実にし、それによって領域全体に対する患者パラメータの変化を特徴付ける。代替実施形態では、所与の時間期間の間の所与の領域に関する臨床データは、最近の、または具体的には年間データではない場合、少なくとも比較可能な時間期間の臨床データに基づいて決定されたベースラインリスクしきい値と比較される。
【０１２８】
図6Dは、一実施形態による、2つの例示的なリスクしきい値決定、およびトレーニングデータセットのトレーニングサンプルに関する標示を決定するためのその使用を示す。第1に、指定された時間期間、たとえば、2019年に発生するある月の間の領域内のユーザの母集団に対する利用イベントの総数が加算されて記憶される。第1および第2の例の場合、この総数は、それぞれ、120回のイベントおよび70回のイベントである。第2に、同じ時間期間の間のユーザの同様の母集団に対するレスキュー利用イベントの数としてベースラインリスクしきい値が決定される。別の実施形態では、比較可能な時間期間、たとえば、2018年に発生する同じ月の間のユーザの同じ母集団に対するレスキュー利用イベントの数としてベースラインリスクしきい値が決定される。示した実施形態では、ベースラインリスクしきい値は、90回のイベントであると決定されている。
【０１２９】
トレーニングにおいて、サンプル(イベントおよび1日のイベントに関する他のデータ)が「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、scale_pos_weight、およびseed=27であるように、XGBoostセットの変数を用いて実行された。XGBoostアルゴリズムに関するさらなる詳細は、http://xgboost.readthedocs.io/en/latest/python/python_api.htmlに見出すことができる。データに対して交差検証が実行された。残りの説明の便宜上、この例は、XGBoost Example Modelと呼ばれる。
【０１３３】
他の実施形態では、モデル640は、上記の説明と整合するアルゴリズムおよびフレームワークの異なるセットを実装し得る。
【０１３４】
IV.F.予測モデル使用
次に図4に戻ると、アプリケーションサーバ130は、トレーニングされたモデルを使用し、喘息リスク分析430を実行して、患者が近い将来に喘息イベントを経験することになるリスクを決定する。この場合も、これらのプロセスは、他の疾患(たとえば、COPD)に等しく適用可能であり、患者ではなく地理的領域に対して実行され得る。このリスクは、数値スコアとして実施されるが、患者が高リスクカテゴリー内であるか、中程度のリスクカテゴリー内であるか、低リスクカテゴリー内であるかなど、リスク類別へと処理されてもよい。この情報は、特に、予測されるイベントを回避するために、患者行動の変化に影響を及ぼすことを試行するために使用され得る。
【０１３５】
次に図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の範囲である。
【０１３７】
地理的エリア実装形態は、患者固有の実装形態とは異なり、地理的領域内に位置する患者の母集団に基づいてトレーニングされる。これらのデータは、ユーザの数、地理的領域の人口密度、および/または地理的領域内でユーザによって費やされた時間量に基づいて正規化され得る。しかしながら、上記のように、データ分析モジュール131は、地理的領域に対するいずれかの現在のコンテキストデータ635、地理的領域に対する過去のコンテキストデータ635、および地理的領域に対するパラメータ値630から決定された入力値にアクセスすることによって、地理的領域に対するリスクスコアを生成する。アクセスされた入力を超えて、データ分析モジュール131は、地理的領域に対するリスクスコアを決定するために上記で説明したように機能する。たとえば、データ分析モジュール131は、領域に特定のリスク条件のセットを特徴付けるために、領域に対する過去のコンテキストデータ635を使用してトレーニングされる。その領域に対するリスクスコアを決定するために、現在のコンテキストデータ635が過去のデータと比較される。使用中、ユーザは、提供されたGUIにアクセスして、特定の緯度および経度座標または郵便番号を検索し、位置に関連する呼吸イベントの一般的なリスクを見抜くことができる。
【０１３８】
IV.G.レスキューイベントリスク通知
通知モジュール645は、類別、リスクスコア、リスクスコアの潜在的な原因、およびこれらの状況下で患者が別のレスキュー利用イベントの発生を防ぐためにとり得る選択肢のうちのいずれか1つまたは複数を含むリスクスコア通知を生成する(435)。上記で論じたように、アプリケーションサーバ130は、地理的領域、患者111、その医療提供者112、および/またはいずれかの他の許可を受けた個人のうちの1つまたは複数に対してリスクスコア通知を生成する(435)。
【０１３９】
リスク通知は、リスクスコア、類別、およびモデル640のパラメータのうちのいずれかからの入力値のうちのいずれかを含む、多種多様な情報コンテンツを含み得る。
【０１４０】
リスク通知は、リスク類別の変更の原因となるパラメータに基づいて、さらなるレスキュー吸入器イベントをどのように防ぐかに関する推奨からなり得る。たとえば、推奨は、より密にアドヒアランススケジュールに従うこと、長期管理薬の服用量または利用を増大させること、その地理的領域を完全に回避すること、または同様の環境条件を有するエリアへの暴露を制限することを含み得る。
【０１４１】
加えて、ユーザには、前年発生したその薬レスキューイベント位置のすべてのピンポイントを有する地理的マップが提供されてよい。別の例として、ユーザには、そのエリアに対する薬レスキューイベントの最近のパターンを指示するために、その日またはしきい値時間期間内のいずれかに近くの地理的エリア内に発生したすべての薬レスキューイベントのピンポイントとともに、イベント410が起こった場所を含む地理的マップが提供されてよい。別の例として、患者111の医療提供者112には、提供者112が薬レスキューイベント傾向を識別するのに役立つように、その日または最近の時間期間からその患者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モデルと比較して、そのリスク分析およびリスク類別の性能の点で追加のパラメータを考慮する。
【０１４８】
加えて、トレーニングデータ内に含まれた各レスキューイベントの地理的位置に基づいて、トレーニングデータセットが組織される。トレーニングデータセットの各レスキューイベントに対して記録されたパラメータに基づいて、XGBoost Example Modelは、地理的領域が高リスク領域(1と標示)と見なされるか否か、または低リスク領域(0と標示)と見なされるか否かを予測する。トレーニングされると、XGBoost Example Modelは、0.64のAUCスコア、かつ0.60の精度、感度、および特異性でそのような予測を行うことが可能であった。
【０１４９】
V.D.実施例4
図7Dは、XGBoost Example Modelによって、高リスク、中リスク、および低リスクとして類別されたテストセットからの領域の分布を表示する。中リスクと見なされる領域は、52%でテストセットの大部分を構成し、その後に46%で低リスクと見なされる領域、および2%で高リスクと見なされる領域が続く。このリスクカテゴリー分布は、低リスクおよび中リスクの予測が高リスク予測をはるかに上回る、V1モデルによって生成された類別と大まかに一致する。具体的には、V1モデルにおいて、低リスク予測は、テストセットの49%を占め、中リスク予測は32%を占め、高リスク予測は20%を占める。図7Eは、複数の地理的領域にわたるリスクスコアの分布を用いた合衆国のグラフィック表現を表示する。合衆国内の領域の大部分は、低リスクと類別され、その後に中リスクと類別される少数の領域、および高リスクと類別されるより少数の領域が続く。
【０１５０】
V.E.実施例5
図7Dは、XGBoost Example Modelのいくつかのパラメータを図示し、リスク分析決定におけるパラメータの重要性を表す重要度スコアをそれぞれのパラメータに割り当てる。様々なパラメータの重要性の決定は、モデルがそれらのパラメータに関連付けるパラメータ値を決定するモデルのトレーニングの間に完了する。したがって、トレーニングデータセットは、図7A〜図7Bを参照して説明した特徴と一致する。この例の場合、識別されたモデルパラメータおよびテストデータに基づいて、最も重要なパラメータは、0.16のスコアを有する乾球温度であり、最も重要でないパラメータは、0.023のスコアを有する風向である。最も重要な大気汚染物質パラメータは、オゾン分子濃度、および.1095のスコアの、1マイクロメートル以下の粒子物質濃度である。
【０１５１】
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  トレーニングデータセット、トレーニングサンプル
【図１】
2021525417.tif 000003
【図２】
2021525417.tif 000004
【図３Ａ】
2021525417.tif 000005
【図３Ｂ】
2021525417.tif 000006
【図４】
2021525417.tif 000007
【図５】
2021525417.tif 000008
【図６Ａ】
2021525417.tif 000009
【図６Ｂ】
2021525417.tif 000010
【図６Ｃ】
2021525417.tif 000011
【図６Ｄ】
2021525417.tif 000012
【図７Ａ】
2021525417.tif 000013
【図７Ｂ】
2021525417.tif 000014
【図７Ｃ】
2021525417.tif 000015
【図７Ｄ】
2021525417.tif 000016
【図７Ｅ】
2021525417.tif 000017
【図７Ｆ】
2021525417.tif 000018
【国際調査報告】
2021525417.tif 000019