知財求人 - 知財ポータルサイト「IP Force」
▶ レシプロカル ラボ コーポレイション（ディー／ビー／エー プロペラ― ヘルス）の特許一覧
特表2023-501785患者に対する薬剤デバイス監視に基づいた喘息トリガ条件の特定のためのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-01-19
(54)【発明の名称】患者に対する薬剤デバイス監視に基づいた喘息トリガ条件の特定のためのシステムおよび方法
(51)【国際特許分類】
G16H 20/00 20180101AFI20230112BHJP
A61B 5/00 20060101ALI20230112BHJP
【ＦＩ】
G16H20/00
A61B5/00 102C
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022525810
(86)(22)【出願日】2020-10-23
(85)【翻訳文提出日】2022-06-01
(86)【国際出願番号】 US2020057196
(87)【国際公開番号】W WO2021086757
(87)【国際公開日】2021-05-06
(31)【優先権主張番号】62/928,937
(32)【優先日】2019-10-31
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520039054
【氏名又は名称】レシプロカル ラボ コーポレイション（ディー／ビー／エー プロペラ― ヘルス）
【氏名又は名称原語表記】ＲＥＣＩＰＲＯＣＡＬ ＬＡＢＳ ＣＯＲＰＯＲＡＴＩＯＮ （ｄ／ｂ／ａ ＰＲＯＰＥＬＬＥＲ ＨＥＡＬＴＨ）
【住所又は居所原語表記】６３４ Ｗｅｓｔ Ｍａｉｎ Ｓｔｒｅｅｔ，Ｓｕｉｔｅ １０２，Ｍａｄｉｓｏｎ，ＷＩ ５３７０３，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110001519
【氏名又は名称】弁理士法人太陽国際特許事務所
(72)【発明者】
【氏名】ハイロンズ、ニコラス、ジョン
【テーマコード（参考）】
4C117
5L099
【Ｆターム（参考）】
4C117XA01
4C117XB04
4C117XB11
4C117XD23
4C117XE23
4C117XE24
4C117XE27
4C117XE57
4C117XE60
4C117XE62
4C117XE80
4C117XH16
4C117XJ03
4C117XJ13
4C117XJ32
4C117XJ33
4C117XJ45
4C117XL01
4C117XN05
4C117XP12
4C117XQ13
4C117XQ20
5L099AA25
(57)【要約】
呼吸器疾患のトリガのリスクを一般的患者母集団と比較して決定する方法が開示される。患者母集団へ呼吸薬剤を送達するための薬剤デバイスの起動についてデータが収集される。起動データと、各起動イベントに関連する患者文脈パラメータデータとが保存される。データ分析モジュールは、収集された起動データに基づいて救助イベントの発生を決定し、文脈パラメータと救助イベントとの相関に基づいて文脈パラメータの係数を一次患者のトリガイベントとして決定する。データ分析モジュールは、一次患者の少なくとも１つの文脈パラメータの係数と、患者母集団についてのトリガイベントの係数分布との比較を、患者母集団についての文脈パラメータと救助イベントとの相関に基づいて提供する。
【選択図】図１
【選択図】図１
【特許請求の範囲】
【請求項1】
呼吸器疾患をトリガする条件を決定する方法であって、患者母集団中の患者へ呼吸薬剤を送達するための呼吸薬剤デバイスの起動についてデータを収集すること、
前記起動データと、前記患者母集団についての各起動イベントに関連する患者文脈パラメータデータとを保存すること、
前記患者母集団中の一次患者について一定期間にわたって前記起動データおよび前記文脈パラメータデータへアクセスすること、
前記収集された起動データに基づいて、救助イベントの発生を決定すること、
前記文脈パラメータと前記救助イベントとの相関に基づいて、少なくとも１つの文脈パラメータの係数を前記一次患者のトリガイベントとして決定すること、および
前記一次患者の前記少なくとも１つの文脈パラメータの係数と、前記患者母集団についての前記トリガイベントの係数分布との比較を、前記患者母集団についての前記文脈パラメータと前記救助イベントとの相関に基づいて提供すること、
を含む方法。
【請求項2】
前記係数を前記文脈パラメータデータに部分的に基づいて決定し、前記救助イベントの発生を前記一次患者の文脈パラメータの前記患者母集団の一次患者に類似する少なくとも１人の二次患者の前記収集された起動データに基づいて決定することをさらに含む、請求項１に記載の方法。
【請求項3】
前記係数の決定を少なくとも１つのハイパーパラメータによって最適化された前記収集された起動データに関連した前記文脈パラメータの回帰分析に基づいて行うことをさらに含む、請求項１または請求項２に記載の方法。
【請求項4】
収集された起動データおよび文脈データについて前記回帰分析を第１の所定の期間後に行うことをさらに含む、請求項３に記載の方法。
【請求項5】
前記患者母集団中の患者それぞれについて前記患者母集団の係数の選択を前記第１の所定の期間後に行われる前記回帰分析に基づいて行うことをさらに含む、請求項４に記載の方法。
【請求項6】
前記少なくとも１つのハイパーパラメータの調整を前記患者母集団についての前記収集された文脈パラメータデータに基づいて第２の所定の期間にわたって行うことをさらに含む、請求項３に記載の方法。
【請求項7】
前記呼吸器疾患は、喘息である、請求項１～６のうちいずれか一項に記載の方法。
【請求項8】
前記少なくとも１つの文脈パラメータは、大気汚染物質条件または気象条件のうち１つを含む、請求項１～７のうちいずれか一項に記載の方法。
【請求項9】
前記汚染物質条件は、空気質指数、オゾン分子（Ｏ３）、二酸化窒素分子（ＮＯ２）、二酸化硫黄分子（ＳＯ２）、２．５マイクロメータ以下の粒子状物質（ＰＭ２．５）または１０マイクロメータ以下の粒子状物質（ＰＭ１０）のうち１つである、請求項８に記載の方法。
【請求項10】
前記気象条件は、温度、湿度、風速、風向、現地気圧および視程のうち１つである、請求項８に記載の方法。
【請求項11】
前記決定されたトリガ条件を含む複数のトリガ条件を決定すること、前記複数のトリガ条件それぞれについて係数を割り当てること、および
前記係数と、前記患者母集団からの前記複数のトリガ条件それぞれについての係数分布とを比較すること、
をさらに含む、請求項１～１０のうちいずれか一項に記載の方法。
【請求項12】
前記一次患者の係数が前記患者母集団の係数分布の一定のパーセンタイル内にあるかに基づいて、選択されたトリガ条件を前記複数のトリガ条件から表示することをさらに含む、請求項１１に記載の方法。
【請求項13】
前記一次患者の全体的リスク要素と相関付けられた記述的ラベルを割り当てることをさらに含む、請求項１２に記載の方法。
【請求項14】
前記記述的ラベルを前記一次患者に表示することをさらに含む、請求項１３に記載の方法。
【請求項15】
前記係数が前記患者母集団の係数の高パーセンタイル分布内にある場合に前記一次患者に警告することをさらに含む、請求項１～１４のうちいずれか一項に記載の方法。
【請求項16】
システムであって、１つ以上のプロセッサを含む制御システム、および
機械可読命令が保存されたメモリを含み、
前記制御システムは、前記メモリへ連結され、請求項１～１５のうちいずれか一項に記載の方法は、前記メモリ中の前記機械実行可能命令が前記制御システムの前記１つ以上のプロセッサのうち少なくとも１つによって実行された際に実行される、システム。
【請求項17】
１つ以上の指摘をユーザへ通信させるシステムであって、前記システムは、請求項１～１５のうちいずれか一項に記載の方法を実行するように構成された制御システムを含む、システム。
【請求項18】
命令を含むコンピュータプログラム製品であって、前記命令は、コンピュータによって実行されると、請求項１～１５のうちいずれか一項に記載の方法を前記コンピュータに実行させる、コンピュータプログラム製品。
【請求項19】
前記コンピュータプログラム製品は、非一時的なコンピュータ可読媒体である、請求項１８に記載のコンピュータプログラム製品。
【請求項20】
一次患者の呼吸器疾患のトリガイベントを評価する方法であって、治療デバイスの起動からの使用度データを通信インターフェースからの患者母集団から収集すること、
前記通信インターフェースからの前記患者母集団に対応する文脈パラメータデータを収集すること、
前記収集された使用度データおよび文脈パラメータデータを保存デバイス中に保存すること、
トリガイベントの係数を前記患者母集団の各患者についての前記文脈パラメータおよび使用度データから決定すること、
前記一次患者の前記トリガイベントの係数を、前記一次患者の前記文脈データおよび使用度データに関連するデータに基づいて決定すること、および
前記一次患者の係数の比較を前記患者母集団の係数分布に関連して提供すること、
を含む、方法。
【請求項21】
前記一次患者の文脈パラメータの前記患者母集団の一次患者に類似する少なくとも１人の二次患者の起動データを収集することをさらに含み、前記係数は、前記文脈パラメータデータおよび前記少なくとも１人の二次患者に基づいた救助イベントの発生に部分的に基づいて決定される、請求項２０に記載の方法。
【請求項22】
前記係数は、少なくとも１つのハイパーパラメータによって最適化された前記収集された起動データに関連した前記文脈パラメータの回帰分析に基づいて決定される、請求項２０または請求項２１に記載の方法。
【請求項23】
前記回帰分析は、収集された起動データおよび文脈データについて第１の所定の期間後に行われる、請求項２２に記載の方法。
【請求項24】
前記患者母集団の係数は、前記患者母集団中の各患者について前記第１の所定の期間後に行われた回帰分析に基づいて選択される、請求項２３に記載の方法。
【請求項25】
前記少なくとも１つのハイパーパラメータは、前記患者母集団についての前記収集された文脈パラメータデータに基づいて第２の所定の期間にわたって調整される、請求項２３に記載の方法。
【請求項26】
前記呼吸器疾患は、喘息である、請求項２０～２５のうちいずれか一項に記載の方法。
【請求項27】
前記少なくとも１つの文脈パラメータは、大気汚染物質条件または気象条件のうち１つを含む、請求項２０～２６のうちいずれか一項に記載の方法。
【請求項28】
前記汚染物質条件は、空気質指数、オゾン分子（Ｏ３）、二酸化窒素分子（ＮＯ２）、二酸化硫黄分子（ＳＯ２）、２．５マイクロメータ以下の粒子状物質（ＰＭ２．５）、１０マイクロメータ以下の粒子状物質（ＰＭ１０）のうち１つである、請求項２０～２７のうちいずれか一項に記載の方法。
【請求項29】
前記気象条件は、温度、湿度、風速、風向、現地気圧および視程のうち１つである、請求項２８に記載の方法。
【請求項30】
前記決定されたトリガ条件を含む複数のトリガ条件を決定すること、前記複数のトリガ条件それぞれについて係数を割り当てること、および
前記係数と、前記患者母集団からの前記複数のトリガ条件それぞれについての係数分布とを比較すること、
をさらに含む、請求項２０～２９のうちいずれか一項に記載の方法。
【請求項31】
前記一次患者の係数が前記患者母集団の係数分布の一定のパーセンタイル内にあるかに基づいて、選択されたトリガ条件を前記複数のトリガ条件から表示することをさらに含む、請求項３０に記載の方法。
【請求項32】
前記一次患者の全体的リスク要素と相関付けられた記述的ラベルを割り当てることをさらに含む、請求項３１に記載の方法。
【請求項33】
前記記述的ラベルを前記一次患者に表示することをさらに含む、請求項３２に記載の方法。
【請求項34】
前記記述的ラベルおよび選択されたトリガ条件を表示することは、モバイルデバイスのディスプレイ上において行われる、請求項３３に記載の方法。
【請求項35】
前記係数が前記患者母集団の係数の高パーセンタイル分布内にある場合に前記一次患者に警告することをさらに含む、請求項２０～３４のうちいずれか一項に記載の方法。
【請求項36】
呼吸器疾患をトリガする条件を決定するシステムであって、患者母集団中の患者へ呼吸薬剤を送達するための呼吸薬剤デバイスの起動についてデータを収集する通信インターフェース、
前記起動データと、前記患者母集団についての各起動イベントに関連する患者文脈パラメータデータとを保存する保存デバイス、
前記患者母集団中の一次患者について一定期間にわたって前記起動データおよび前記文脈パラメータデータへアクセスし、前記収集された起動データに基づいて救助イベントの発生を決定し、前記文脈パラメータと前記救助イベントとの相関に基づいて少なくとも１つの文脈パラメータの係数を前記一次患者のトリガイベントとして決定するように動作可能なデータ分析モジュール、を含み、
前記データ分析モジュールは、前記一次患者の前記少なくとも１つの文脈パラメータの係数と、前記患者母集団についての前記トリガイベントの係数分布との比較を、前記患者母集団についての前記文脈パラメータと前記救助イベントとの相関に基づいて提供するように動作可能である、システム。
【請求項37】
前記データ分析モジュールは、前記決定されたトリガ条件を含む複数のトリガ条件を決定すること、
前記複数のトリガ条件それぞれについて係数を割り当てること、および
前記係数と、前記患者母集団からの前記複数のトリガ条件それぞれについての係数分布とを比較すること、
を行うようにさらに動作可能である、請求項３６に記載のシステム。
【請求項38】
出力アプリケーションをさらに含み、前記出力アプリケーションは、前記一次患者の係数が前記患者母集団の係数分布の一定のパーセンタイル内にあるかに基づいて、選択されたトリガ条件を前記複数のトリガ条件から表示する、請求項３７に記載のシステム。
【請求項39】
前記記述的ラベルを前記一次患者に表示するディスプレイをさらに含む、請求項３６～３８のうちいずれか一項に記載のシステム。
【請求項40】
前記データ分析モジュールへ連結されたモバイルデバイスをさらに含む、請求項３６～３９のうちいずれか一項に記載のシステム。【発明の詳細な説明】
【技術分野】
【0001】
優先権の主張
本出願は、２０１９年１０月３１日に出願された米国仮特許出願第６２／９２８，９３７号の恩恵と優先権を主張する。本明細書中、同文献全体が本明細書に参照により組み込まれる。
本出願は、２０１９年１０月３１日に出願された米国仮特許出願第６２／９２８，９３７号の恩恵と優先権を主張する。本明細書中、同文献全体が本明細書に参照により組み込まれる。
【0002】
技術分野
本開示は、呼吸器疾患の可能性のある患者の治療を向上させる方法に主に関し、より詳細には、患者の喘息に関連する救助イベントの原因を一般的患者母集団の罹病性に相対して決定することに関する。
本開示は、呼吸器疾患の可能性のある患者の治療を向上させる方法に主に関し、より詳細には、患者の喘息に関連する救助イベントの原因を一般的患者母集団の罹病性に相対して決定することに関する。
【背景技術】
【0003】
喘息は、今でも有意かつ高コストの公衆衛生問題となっている。米国においては、２千２百万人を超える人が、この疾患を有している。世界保健機関の推定によると、世界規模での喘息人口は３億人であり得、２０２５年までに４億人に上昇すると予測されている。
【0004】
新規薬剤は開発されているものの、入院件数および緊急治療室来訪件数は低減していない。米国における各年において、この疾患に起因する救急部門訪問はおよそ２百万件、入院件数はおよそ５００，０００、死亡件数はおよそ５，０００である。加えて、喘息に起因すると推測される学校欠席日数は１，５００万日、欠勤日数は１，２００万日になる。米国の医療保険会社および従業員にかかる年間コストの合計は、１８０億米ドルを超えている。
【0005】
これらの病勢悪化の大部分は、現在利用可能である治療を用いれば回避可能であるものの、この疾患を管理できているのは、喘息患者５人のうち１人だけである。このような治療の場合、呼吸状態のトリガ条件（例えば、喘息）を特定することと、治療（例えば、薬剤）を適切に行うこととに依存することが多い。患者による薬剤の自己投与のための１つの機構として、吸入器がある。トリガイベントが発生すると、患者は、吸入器からのパフを介して薬剤投与を行い得る。
【0006】
新規改訂された国のガイドラインにより、治療により毎日の症状がコントロールされているかおよび生活の質が改善しているかについてより詳細に監視することが、医師に求められている。患者および患者の状態の監視のために、ますます多くの医師が、書面による質問表（例えば、喘息対照試験）の定期的使用を開始している。これらの方式の場合、患者が自身の症状、症状の頻度、吸入器の使用度および活動レベルならびに一定期間（通常は２～４週間）にわたる制限を正確に思い出して報告する必要がある。そのため、これらの質問表の場合、バイアス（思い出し）、症状の解釈の違いおよび挙動（ノンアドヒアランス）に起因してエラーが発生し、情報を提供できるのは使用された時のみである。
【0007】
最近の１つのアプローチにおいて、トリガイベントの決定は、個々の患者の結果に基づいた統計分析を通じて行われている。このようなトリガイベントは、典型的には薬剤の吸入器からのパフと関連付けられる。このようなイベントおよびよってパフが発生し得る時期の分析が、試行されている。しかし、パフの予測は、ノイズが極めて多く、エラー発生も多い問題である。このような分析を困難にする要因として、以下のいくつかの問題がある。第１に、理想的条件下においても高エラー率が発生する。候補となる「トリガ」変数は、多数存在する。これらは、相関していることが多い。変数を特定の閾値を超えるかまたは特定の閾値未満であるか（例えば、「８０を超える温度」、「９０を超える温度」）に基づいてバケット中に振り分けた場合、さらに多くの変数が発生し得、相関付けられ得る。特に相関し合う治療変数に対して複数の仮説検定を行った場合、当該相関がランダムな機会に起因するものであったとしても、変数に対する「有意の」関係が偽陽性になる可能性が大きく高まる。
【0008】
イベント発生の頻度が低い（例えば、３０％未満）の場合であっても、高エラー率が発生する。イベントは、当該日にパフが有ったかまたはパフカウントが一定の基準線を超えていたかであり得る。シミュレーションによれば、患者が実際に経験するイベントの率が低い場合、逐次確率比検定の偽陽性率および偽陰性率双方が高くなり得る。これらの要素を調節および相関付けることは、実際の設定においては困難である。
【0009】
第２に、現行の統計分析方法の場合、一次患者からのデータに主に依存しているため、トリガ条件を特定するまでに非実際的なほど長い時間を要する。環境トリガに対する感受性が高いか否かを「発見」するのには、変数と結果との間の関係が極めて強くない限り、極めて長時間がかかり得る。例えば、温度が８０度を超えている場合に１人の患者について基準線を超えた増加が５０％よりも高い率で発生している状況のシミュレーションにおいて、１８ヶ月分のデータ後にも試験においてこの関係を特定できない場合が多くある。これは、特定のイベントの低頻度を適切に制御するためには、トリガ条件の特定を確認するための期間がさらに長くなるという事実によってさらに悪化する。
【0010】
第３に、現在および今後の規制への患者の適合のために、有用である可能性のあるトリガ情報を通信させることは困難である。統計予測における統計的有意性および確実性表現などの問題を患者へ説明することは困難である。このアプローチにおけるエラーも、規制へのコンプライアンスに影響し得る。
【0011】
統計有意性の理解は、困難を伴う。複数の相関し合う変数に対してこのような有意性を決定することには、さらなる困難を伴う。統計有意性を連続的に決定することは、さらに困難である。これらの問題を調節しつつ、トリガ条件についての実際的な識見を現在において合理的な時間枠内にアプリケーションを介して患者に通信することは、ほとんど不可能である。
【0012】
一次患者の環境データからのトリガイベントの決定を、大きな患者母集団からのトリガイベント確率の分布との比較によって行うことが可能なシステムが必要とされている。トリガイベント分析提供を比較的短期間に行う必要性もある。統計に基づいたトリガ分析を患者にとって分かり易い形態で提供することも、求められている。
【発明の概要】
【0013】
開示の呼吸器疾患監視システムによれば、トリガ条件をより高精度に予測し、そのような条件を患者へ通信させる方法およびシステムが提供される。システムは、治療デバイス（例えば、吸入器）からのセンサデータと、患者の人口統計学データおよび生理学的データと、呼吸器疾患を有する患者母集団に関連する環境データとを収集する。データは収集され、各行のデータは患者１日あたりの医療費であり、各列内に環境露出および吸入器使用度が記載されるように分類される。分析により、確率論提唱者の統計の収集が患者母集団中の各他の薬剤吸入器患者と比較された相対感度に対して行われる。その結果得られた分析は、他の患者との比較に基づくため、社会的、動的かつ統合的なものとなる。そのため、その結果得られた分析は、患者として理解し易いものとなる。
【0014】
１つの開示例として、呼吸器疾患をトリガする条件を決定するシステムがある。通信インターフェースは、患者母集団中の患者へ呼吸薬剤を送達するための呼吸薬剤デバイスの起動についてデータを収集する。保存デバイスは、起動データと、患者母集団についての各起動イベントに関連する患者文脈パラメータデータとを保存する。データ分析モジュールは、患者母集団中の一次患者について一定期間にわたって起動データおよび文脈パラメータデータへアクセスするように動作可能である。データ分析モジュールは、収集された起動データに基づいて救助イベントの発生を決定し、文脈パラメータと救助イベントとの相関に基づいて少なくとも１つの文脈パラメータの係数を一次患者のトリガイベントとして決定する。データ分析モジュールは、一次患者の少なくとも１つの文脈パラメータの係数と、患者母集団についてのトリガイベントの係数分布との比較を、患者母集団についての文脈パラメータと救助イベントとの相関に基づいて提供する。
【0015】
開示例のシステムの別の実装形態において、係数の決定は、文脈パラメータデータと、一次患者の文脈パラメータの患者母集団の一次患者に類似する少なくとも１人の二次患者の収集された起動データに基づいた救助イベントの発生とに部分的に基づいて行われる。別の実装形態において、係数は、少なくとも１つのハイパーパラメータによって最適化された収集された起動データに関連した文脈パラメータの回帰分析に基づいて決定される。別の実装形態において、回帰分析は、収集された起動データおよび文脈データについて第１の所定の期間後に行われる。別の実装形態において、患者母集団の係数は、患者母集団中の患者それぞれについて第１の所定の期間後に行われた回帰分析に基づいて選択される。別の実装形態において、少なくとも１つのハイパーパラメータは、患者母集団についての収集された文脈パラメータデータに基づいて第２の所定の期間にわたって調整される。別の実装形態において、呼吸器疾患は、喘息である。別の実装形態において、少なくとも１つの文脈パラメータは、大気汚染物質条件または気象条件のうち１つを含む。別の実装形態において、汚染物質条件は、空気質指数、オゾン分子（Ｏ３）、二酸化窒素分子（ＮＯ２）、二酸化硫黄分子（ＳＯ２）、２．５マイクロメータ以下の粒子状物質（ＰＭ２．５）、１０マイクロメータ以下の粒子状物質（ＰＭ１０）のうち１つである。別の実装形態において、気象条件は、温度、湿度、風速、風向、現地気圧および視程のうち１つである。別の実装形態において、データ分析モジュールは、決定されたトリガ条件を含む複数のトリガ条件を決定する。データ分析モジュールは、複数のトリガ条件それぞれについて係数を割り当てる。データ分析モジュールは、係数と、患者母集団からの複数のトリガ条件それぞれについての係数分布とを比較する。別の実装形態において、システムは、出力アプリケーションを含む。この出力アプリケーションは、一次患者の係数が患者母集団の係数分布の一定のパーセンタイル内にあるかに基づいて、選択されたトリガ条件を複数のトリガ条件から表示する。別の実装形態において、出力アプリケーションは、一次患者の全体的リスク要素と相関付けられた記述的ラベルを割り当てる。別の実装形態において、システムは、記述的ラベルを一次患者に表示するディスプレイを含む。別の実装形態において、システムは、データ分析モジュールへ連結されたモバイルデバイスを含む。別の実装形態において、データ分析モジュールは、係数が患者母集団の係数の高パーセンタイル分布内にある場合に一次患者に警告する。
【0016】
別の開示例は、一次患者の呼吸器疾患のトリガイベントを評価する方法である。治療デバイスの起動からの使用度データは、通信インターフェースからの患者母集団から収集される。患者母集団に対応する文脈パラメータデータは、通信インターフェースから収集される。収集された使用度データおよび文脈パラメータデータは、保存デバイス内に保存される。トリガイベントの係数は、患者母集団の各患者について文脈パラメータおよび使用度データから決定される。一次患者のトリガイベントの係数は、一次患者の文脈データおよび使用度データに関連するデータに基づいて決定される。一次患者の係数の比較は、患者母集団の係数分布に関連して提供される。
【0017】
開示例の方法の別の実装形態において、起動データは、一次患者の文脈パラメータの患者母集団の一次患者に類似する少なくとも１人の二次患者について収集される。係数は、文脈パラメータデータおよび少なくとも１人の二次患者に基づいた救助イベントの発生に部分的に基づいて決定される。別の実装形態において、係数は、少なくとも１つのハイパーパラメータによって最適化された収集された起動データに関連した文脈パラメータの回帰分析に基づいて決定される。別の実装形態において、回帰分析は、収集された起動データおよび文脈データについて第１の所定の期間後に行われる。別の実装形態において、患者母集団の係数は、患者母集団中の各患者について第１の所定の期間後に行われた回帰分析に基づいて選択される。別の実装形態において、少なくとも１つのハイパーパラメータは、患者母集団についての収集された文脈パラメータデータに基づいて第２の所定の期間にわたって調整される。別の実装形態において、呼吸器疾患は、喘息である。別の実装形態において、少なくとも１つの文脈パラメータは、大気汚染物質条件または気象条件のうち１つを含む。別の実装形態において、汚染物質条件は、空気質指数、オゾン分子（Ｏ３）、二酸化窒素分子（ＮＯ２）、二酸化硫黄分子（ＳＯ２）、２．５マイクロメータ以下の粒子状物質（ＰＭ２．５）または１０マイクロメータ以下の粒子状物質（ＰＭ１０）のうち１つである。別の実装形態において、気象条件は、温度、湿度、風速、風向、現地気圧および視程のうち１つである。別の実装形態において、方法は、決定されたトリガ条件を含む複数のトリガ条件を決定することを含む。本方法は、複数のトリガ条件それぞれについて係数を割り当てることを含む。本方法は、係数と、患者母集団からの複数のトリガ条件それぞれについての係数分布とを比較することを含む。別の実装形態において、方法は、一次患者の係数が患者母集団の係数分布の一定のパーセンタイル内にあるかに基づいて、選択されたトリガ条件を複数のトリガ条件から表示することを含む。別の実装形態において、方法は、一次患者の全体的リスク要素と相関付けられた記述的ラベルを割り当てることを含む。別の実装形態において、方法は、記述的ラベルを一次患者に表示することを含む。別の実装形態において、記述的ラベルおよび選択されたトリガ条件の表示は、モバイルデバイスのディスプレイ上において行われる。別の実装形態において、方法は、係数が患者母集団の係数の高パーセンタイル分布内にある場合に一次患者に警告することを含む。
【0018】
上記の要旨は、本開示の各実施形態または各態様を示すことを意図していない。すなわち、上記の要旨は、本明細書中に記載の新規の態様および特徴のうちいくつかの例を示すものに過ぎない。上記の特徴および利点ならび本開示の他の特徴および利点は、本発明の実行のための代表的な実施形態および態様の以下の詳細な説明を添付の図面および添付の特許請求の範囲と共に読めば、容易に明らかになる。
【0019】
例示的実施形態に関する以降の説明を添付図面と併せて参照することにより、本開示に対する理解が深まるであろう。
【図面の簡単な説明】
【0020】
【図1】高精度のリアルタイムの薬剤デバイス使用度を監視し、当該データに対して分析を行い、救助イベントリスク通知を提供するための呼吸器疾患分析システムを示す。
【図2】クライアントデバイス、アプリケーションサーバおよび／またはデータベースサーバとして内部において用いられるコンピューティングデバイスの一例を示す高レベルブロック図である。
【図3A】ユーザと喘息分析システムとの対話を可能にするクライアントアプリケーションのダッシュボードを示す。
【図3B】クライアントアプリケーションのダッシュボード内に表示された例示的カードを示す。
【図4】一次患者について喘息分析システムによって救助薬イベントを検出するためのフローチャートである。
【図5】一次患者係数を患者母集団からの係数分布と比較して生成するデータ分析モジュール内のモジュールを示すブロック図である。
【図7】一般的患者母集団からのデータ分布との比較に基づいて選択された一次患者データの提示を示す患者アプリケーションのインターフェースの画面イメージである。
【図8】一実施形態による、個々の患者についてトリガを特定ことと、当該トリガについて一般的患者母集団と比較してラベルを生成することとのフローチャートである。
【発明を実施するための形態】
【0021】
本開示には、種々の変形および代替形態がある。図面に例示したいくつかの代表的な実施形態について、本明細書において以下に詳述する。ただし本発明は、開示された特定の形態に限定されることを意図してはいないものと理解すべきであり、本開示はむしろ、添付の請求項によって定義された本発明の精神および範囲内にあるすべての変形、均等物、および代替物を網羅するものである。
【0022】
本発明は、数多くの異なる形態で具現化することできる。代表的な実施形態を図面に示しており、本明細書において以下に詳述する。本開示は、本開示の原理の一例または例示であり、本開示の広範な態様を、例示された実施形態に限定することを意図するものではない。そのため、例えば「要約」、「発明の概要」、「発明を実施するための形態」の各節で開示されていても、請求項に明記されていない要素や制限は、単独でも集合的にも、暗示、推論、または他の方法によって請求項に組み込むべきでない。本明細書中では、特に断りがない限り、単数形は複数形を含み、その逆もある。「～を含む」という語は、「～を含むがそれ（ら）に限定されない」を意味する。さらに、本明細書においては、「概ね」、「略」、「実質的に」、「約」といった近似を表す語を、例えば、「ちょうど」、「付近」、「前後」、「～の３～５％以内」、「許容可能な製造公差の範囲内」、またはそれらの任意の論理的な組み合わせを意味する目的で使用することできる。
【0023】
本開示は、大きな母集団データを一次患者との比較のために収集して、喘息などの呼吸障害についてトリガ通知を提示するシステムに関連する。本システムは、センサデータを治療デバイス（例えば、吸入器）から収集して、呼吸イベントのアドヒアランスおよび潜在的トリガを吸入器の使用度データに基づいて決定する。収集されたデータは、患者の人口統計学データおよび生理学的データならびに関連環境データと組み合わされる。分析により、確率論提唱者の統計を（患者母集団中のその他全ての薬剤吸入器患者と比較されるトリガイベントとして）環境パラメータの相対感度に対して収集する。その結果得られた分析は、社会的、動的かつ統合的なものである。なぜならば、この分析により、トリガ条件と、一般的患者母集団中の他の患者に影響する条件とが比較されるからである。よって、１つ以上のトリガ条件に関連して得られた分析は、患者にとって理解し易いものとなる。
【0024】
本システムが認識していることとして、現在の患者における喘息のトリガとなるものの詳細についての絶対的知識は存在しないことと、（特に日々のデータが極めて限定されていることに鑑みて）任意の潜在的トリガ条件の確実性を決定することはできないこととがある。本開示のシステムにおいて採用されているのは、この初期の不確実性と、条件／トリガイベント間の関係がデータ収集の進行と共に変化するという予想とである。本開示の方法により、分析の早期段階において一定の識見の提供を連続的に行うことが可能になり、その際に正確な知見を必要とすることは全く無い。
【0025】
プラットフォーム上の固定マイルストーンにおいて（例えば、３０日毎）、患者母集団中の各患者について日々の履歴全体に対して回帰分析を行う。各文脈パラメータ（例えば、温度、湿度、粒子数および大気汚染）の係数が決定される。各係数は、患者母集団中のその他全ての患者のパーセンタイルとして上記マイルストーンまでランクが付けられる。係数のランクが十分に高い場合、母集団中の他の患者と比較して環境パラメータに対する当該患者の感度が平均よりも上である旨が当該患者へ通知され得る。将来において条件変化が発生する場合、ユーザに通知がされ得、トリガ条件の予測出力が調節され得る。
【0026】
図１に示す呼吸器疾患分析システム１００は、一実施形態により、高精度のリアルタイムの薬剤デバイスイベントを監視し、データ分析を行い、一次患者についての一般的患者母集団に関連したトリガ特定に基づいた呼吸器疾患リスク通知を提供する。このような呼吸器疾患は、喘息救助イベントであり得、吸入器を通じた迅速な薬剤治療を通じて対処可能であり得る。
【0027】
呼吸器疾患分析システムは、クライアントコンピューティングデバイス１１０と、薬剤デバイスセンサ１２０と、薬剤デバイス１６０と、アプリケーションサーバ１３０と、データベースサーバ１４０と、ネットワーク１５０とを含む。図１中、呼吸器疾患分析システム１００の構成要素のうち大部分の単一のインスタンスを示しているが、実際は各構成要素は１つよりも多数の数で存在し得、より多数またはより小数の構成要素が用いられ得る。
【0028】
クライアントデバイス１１０は、ユーザからの要請が有った場合に、呼吸器疾患分析システム１００との対話をネットワーク１５０を介して行う。説明および明確さのために、少なくとも２つの異なる種類のユーザを特定すると有用である。患者１１１は、喘息を患っているユーザであり、本例において、呼吸器疾患分析システム１００を少なくとも部分的に用いて、サーバ１３０から提供される個別化された喘息救助イベントリスク通知と、ヘルスケアプロバイダ１１２によって生成された喘息管理通知とを入手する。このような通知は、ユーザの許可と引き換えに提供され得、これにより、患者１１１の薬剤デバイス１６０の使用度の呼吸器疾患分析システム１００による監視を可能にする。以下に述べるように、薬剤イベントは、薬剤デバイス１６０およびユーザのクライアントデバイス１００と関連付けられたセンサ１２０によって検出され、その後センサ１２０によりアプリケーションサーバ１３０へ報告が行き、その後、アプリケーションサーバ１３０は、リスク通知を生成するプロセスを開始し得る。リスク通知は、クライアントデバイス１１０を通じてユーザへ提供される。本例において、患者１１１は、患者母集団を示す。患者母集団について、母集団中の各患者について個々のデータがとられる。患者母集団についての全体的統計が、本明細書中に記載のようなトリガイベント分析のために用いられる。
【0029】
別の種類のユーザとして、ヘルスケアプロバイダ１１２がある。ヘルスケアプロバイダ１１２は、同様に患者１１１による許可に基づいて、患者の喘息管理についての通知と、集合喘息コミュニティ救助イベントデータならびに喘息イベントおよび他の関連データについての導出統計とを受信する。他の種類のユーザも企図される（例えば、患者１１１の親／保護者のうち、自身のクライアントデバイス１１０が子供のものと別個である場合に通知を受信することを望む者）。
【0030】
クライアントデバイス１１０は、コンピュータシステムである。例示的な物理的実装形態について、以下において図２についてより詳細に説明する。クライアントデバイス１１０は、呼吸器疾患分析システム１００との無線通信をネットワーク１５０を介して行うように構成される。ネットワーク１５０へのアクセスにより、クライアントデバイス１１０は、ユーザの地理的位置および救助薬イベントの時間と、関連付けられた薬剤デバイスセンサ１２０（全体において「センサ１２０」と呼ぶ）から受信された当該イベントを記述する情報とをシステム１００へ送信する。
【0031】
ユーザ位置およびイベント時間について、クライアントデバイス１１０は、接続先であるセルラーまたは無線ネットワーク１５０についての情報の利用を通じて、地理的位置および救助イベント時間を決定し得る。例えば、クライアントデバイス１１０の現在の地理的位置は、ネットワーク１５０への接続を提供するソフトウェアスタックへの直接的問い合わせにより、決定され得る。あるいは、地理的位置情報は、ネットワーク１５０を介してアクセス可能とされる外部ウェブサービス（図１中図示せず）へのピングによって入手され得る。イベント時間は、イベントデータの一部としてセンサ１２０から提供してもよいし、あるいは、クライアントデバイスのネイティブオペレーティングシステムの一部として利用可能な適切なソフトウェアルーチンへの問い合わせによってイベントデータへ追加してもよい。
【0032】
アプリケーションサーバ１３０との通信に加えて、呼吸器疾患分析システム１００へ無線接続されたクライアントデバイス１１０は、他の接続されたクライアントデバイス１１０とも情報交換し得る。例えば、クライアントソフトウェアアプリケーション１１５を通じて、ヘルスケアプロバイダ１１２は、患者１１１についての最近の救助イベントを記述する病勢悪化リスク通知を受信し得、その後、これに応答して、喘息後の救助イベント治療のために推奨事項を患者１１１へ送信し得る。同様に、アプリケーション１１５を通じて、患者１１１は、自身のヘルスケアプロバイダ１１２および他の患者１１１と通信し得る。
【0033】
アプリケーション１１５は、ユーザインターフェース（本明細書中「ダッシュボード」と呼ぶ）を提供する。このダッシュボードは、クライアントデバイス１１０の画面上に表示され、アプリケーション１１５の動作制御のためのコマンドをユーザが入力することを可能にする。ダッシュボードは、ヘルスケアプロバイダ１１２および患者１１１による呼吸器疾患分析システム１００へのアクセスを可能にする機構である。例えば、ダッシュボードにより可能になることとして、患者１１１およびプロバイダ１１２が相互に対話すること、喘息救助イベントリスク通知を受信すること、治療についてのメッセージを交換すること、さらなるイベントおよび非イベントデータを提供および受信することなどがある。アプリケーション１１５は、１つのウェブページ、一連のウェブページ、またはインターネットブラウザ内にレンダリングされるように他の様態でコードされたコンテンツとしてコードされ得る。アプリケーション１１５は、クライアントデバイス１１０のネイティブオペレーティングシステム上において動作するように構成されたプロプラエタリアプリケーションとしてコードされてもよい。ダッシュボードについて、以下において図３Ａ～図３Ｂに関連してさらに詳細に説明する。
【0034】
ダッシュボードの提供に加えて、アプリケーション１１５は、クライアントデバイス１１０のリソースを用いて喘息救助イベントデータに対する何らかのデータ処理もローカルに行い得、その後、処理されたデータをネットワーク１５０を通じて送信し得る。ネットワーク１１０を通じて送信されたイベントデータは、アプリケーションサーバ１３０によって受信される。アプリケーションサーバ１３０において、このデータは、（データベースサーバ１４０に関連して保存および検索が可能となるように）分析および処理される。アプリケーションサーバ１３０は、クライアントアプリケーション１１５による要求に応じて、検索および保存リクエストをデータベースシステム１３０へ方向付け得る。以下に述べるように、この分析は、複数の患者１１１からのイベントデータを含むように拡張され得る。
【0035】
クライアントデバイス１１０は、センサ１２０との通信をネットワークアダプタおよび有線通信プロトコルまたは無線通信プロトコルを用いて行う。このようなプロトコルの一例として、ＢＴＬＥ（Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ）プロトコルがある。ＢＴＬＥは、短範囲型の低出力プロトコル規格であり、データ送信を短範囲無線ネットワーク内の無線リンクを介して無線的に行う。センサ１２０およびクライアントデバイス１１０の相互ペアリングがＢＴＬＥパスキーにより行われた後、センサ１２０は、薬剤デバイス使用度に関連する情報を自動同期させ、剛性クライアントデバイス１１０へ通信させる。救助薬イベント前にセンサ１２０およびクライアントデバイス１１０のペアリングが完了していない場合、情報は、当該ペアリングが行われるまでローカルに保存される。ペアリング後、センサ１２０は、保存されているイベント記録を全てクライアントデバイス１１０へ通信させる。他の実装形態において、他の種類の無線接続が用いられる（例えば、赤外線またはＩＥＥＥ８０２．１１）。
【0036】
クライアントデバイス１１０および薬剤デバイス１６０は、上記において別個の物理的デバイス（例えば、それぞれスマートフォンおよび吸入器）として記載しているが、将来においては、薬剤デバイス１６０は、デバイス１６０と共に単一のハウジング内に一体化されたセンサ１２０だけでなく、クライアントデバイス１１０の態様も含み得ることが企図される。例えば、薬剤デバイス１６０は、視聴覚情報提示のためにディスプレイまたは他の照明素子およびスピーカを含む視聴覚インターフェースを含み得る。このような実装形態において、薬剤デバイス１６０自身は、サーバ１３０から提供される通知コンテンツを（クライアントデバイス１１０を通じた提示の代わりにまたはクライアントデバイス１１０を通じた提示に加えて）直接提示し得る。
【0037】
薬剤デバイス１６０は、医療デバイスであり、呼吸気流の制限が発生しているユーザの肺への薬剤送達のために用いられる。薬剤デバイス（例えば、吸入器）は典型的にはポータブル型であり、手で携行することが可能なくらいに小型であるため、呼吸発作治療時においてアクセスし易い。一実施形態において、薬剤は、薬剤デバイス１６０（例えば、定量用量吸入器）を通じてエアロゾル状に送達される。定量用量吸入器に含まれるものとして、エアロゾル薬剤の加圧噴射剤用キャニスターと、調整された薬剤用量送達のための定量弁と、プラスチックホルダーとがある。このプラスチックホルダーは、加圧されたキャニスターを保持し、薬剤送達のためのマウスピースも形成する。別の実施形態において、薬剤は、乾燥粉末形態で薬剤デバイス１６０（乾燥粉末吸入器）を通じて送達される。乾燥粉末吸入器に設けられ得るデカルト楕円形状本体において収容される歯車機構により、ユーザが乾燥粉末薬剤の細長片を通じた索引付け（index）を行うことが可能になる。乾燥粉末吸入器の本体には、ユーザへの乾燥粉末送達のためのマニホルドおよびマウスピースも含まれる。管理薬デバイス１６０から分配される管理薬の例を挙げると、ベクロメタソン、ブデソニドおよびフルチカゾンならびにこれらの薬剤と長時間作用型の気管支拡張剤（例えば、サルメテロールまたはホルモテロール）との組み合わせがある。救助薬デバイス１６０から分配される救助薬の例を挙げると、アルブテロール、サルブタモール、レブアルブテロール、メタプロテレノールおよびテルブタリンがある。
【0038】
各患者は、１つよりも多くの薬剤デバイス１６０と関連付けられ得る。例えば、患者は、救助薬を分配する救助薬デバイス１６０と、管理薬を分配する管理薬デバイス１６０とを有し得る。同様に、各患者は、患者の薬剤デバイス１６０のうち１つと共に動作するようにそれぞれ選択された１つよりも多くのセンサ１２０と関連付けられ得る。
【0039】
一般的に、センサ１２０は物理的デバイスであり、薬剤分配器１６０の使用度を監視する。センサ１２０は、（薬剤分配器の動作を妨害すること無く）薬剤分配器へ取り外し可能に取り付け可能にしてもよいし、あるいは、センサ１２０を一体型構成要素として、薬剤分配器１６０のネイティブ部分として製造業者によって利用可能としてもよい。
【0040】
センサ１２０は、自身のネットワークアダプタ（図示せず）を含む。このネットワークアダプタは、クライアントデバイス１１０との通信を有線接続を通じてまたはより典型的には無線ラジオ周波数接続を通じて行う。一実施形態において、ネットワークアダプタは、ＢＴＬＥ（Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ）無線送信器であるが、他の実施形態において、他の種類の無線通信が用いられ得る（例えば、赤外線、ＩＥＥＥ８０２．１１）。
【0041】
センサ１２０を、アプリケーションサーバ１３０とより直接的に通信するように構成してもよい。例えば、センサ１２０のネットワークアダプタが無線規格（例えば、ＩＥＥＥ８０２．１１またはＬＴＥ）を介して通信するように構成されている場合、当該アダプタは、無線アクセスポイント（例えば、無線ルータ）とデータ交換し得、その後、無線アクセスポイントは、アプリケーションサーバ１３０との通信を（必ずしもデータ交換時に毎回クライアントデバイス１１０を必要とすること無く）行い得る。これら２つの通信方法は、相互に排他的ではなく、センサ１２０は、例えばイベントデータがアプリケーションサーバ１３０に確実に到達するようにまたは（アプリケーションサーバ１３０がイベントに応答して提供すべき通知の詳細を決定している間に）情報をクライアントデバイス１１０へ直接提供するように冗長伝送を用いてクライアントデバイス１１０およびアプリケーションサーバ１３０双方と通信するように構成され得る。
【0042】
上記したように、センサ１２０は、薬剤デバイス１６０の使用度についてのデータをキャプチャする。詳細には、各センサ１２０は、救助薬イベントの時間および地理的位置（すなわち、患者１１１による救助薬デバイス１６０の使用度）をキャプチャする。各センサ１２０は、イベントデータの送信を、（リアルタイムにまたはネットワーク接続が達成され次第）患者１１１またはヘルスケアプロバイダ１１２からの入力無しに自動的に行う。薬剤イベント情報は、アプリケーションサーバ１３０へ送信されて、分析、喘息救助イベント通知の生成、および複数の患者にわたるイベントデータの集計分析に用いられる。
【0043】
この目的の達成のために、センサ１２０を構築する複数の異なる方法があり、センサ１２０の構造は、薬剤デバイス１６０そのものの構造に部分的に依存する。一般的に、全センサ１２０は、オンボードプロセッサと、永続メモリと、上記したネットワークアダプタとを含む。これらは、協働してクライアントデバイス１１０および／またはサーバ１３０に対して薬剤イベント情報の記録、保存および報告を行う。センサ１２０は、イベントの時間および日付を記録する時計も含み得る。
【0044】
特定のセンサ１２０の構造について、従来の吸入器（例えば、機械的な用量カウンター）は、考慮によりセンサ１２０と共に設計されないため、センサ１２０は相応に構築され得る。このような様態のいくつかの実装形態を挙げると、機械センサ、電気センサまたは光学センサがあり、デバイス１６０の動き、デバイスのプライミング、デバイスの起動、ユーザによる吸入などを検出する。対照的に、現行の吸入器（例えば、変形可能膜用量カウンター）に含まれるのは電気回路であり、この電気回路は、イベント情報を電気データ信号として報告し得る。センサ１２０は、この電気データ信号を受信および解釈するように設計され、例えば薬剤デバイス１６０そのものは、動き、プライミングおよび起動をセンサ１２０へ報告し得る。
【0045】
センサ１２０および薬剤デバイス１６０のハードウェア構成要素およびソフトウェア構成要素についてのより詳細な情報と、救助薬イベントの記録のための構成要素間の対話とについては、米国特許出願第１２／３４８，４２４号（出願日：２００９年１月１日）および国際出願第ＰＣＴ／ＵＳ２０１４／０３９０１４（出願日：２０１４年５月２１日）に記載がある。本明細書中、これらの文献双方の全体を参考のため援用する。
【0046】
アプリケーションサーバ１３０は、コンピュータであるかまたはコンピュータのネットワークである。図２中には略図例を図示しているが、典型的にはアプリケーションサーバはサーバクラスシステムであり、（使用される典型的なコンピューティングシステムと比較して）高性能のプロセッサ、大型のメモリ、およびより高速のネットワーク構成要素を（例えばクライアントデバイス１１０として）用いる。サーバは典型的には、大型の二次記憶装置を有する。この二次記憶装置は、例えばＲＡＩＤ（独立ディスクの冗長アレイ）アレイを用いかつ／またはデータ（例えば、上記に企図された喘息通知）の保存、交換および送信することを請け負う独立コンテンツ送達ネットワーク（ＣＤＮ）を確立させる。さらに、コンピューティングシステムは、オペレーティングシステムを含む（例えば、ＵＮＩＸ（登録商標）オペレーティングシステム、ＬＩＮＵＸ（登録商標）オペレーティングシステム、またはＷＩＮＤＯＷＳ（登録商標）オペレーティングシステム）。オペレーティングシステムは、アプリケーションサーバ１３０のハードウェアおよびソフトウェアリソースを管理し、多様なサービスも提供する（例えば、プロセス管理、データの入力／出力、周辺デバイスの管理）。オペレーティングシステムは、デバイス上に保存されたファイルの管理のための多様な機能を提供する（例えば、新規ファイルの生成、ファイルの移動またはコピー、リモートシステムへのファイルの転送）。
【0047】
アプリケーションサーバ１３０は、喘息分析システム１００のアクセスおよび使用を（ネットワーク１５０を通じた多数の異なるクライアントデバイス１１０により）サポートするソフトウェアアーキテクチャを含むため、高レベルにおいてクラウドベースのシステムとして一般的に特徴付けられ得る。アプリケーションサーバ１３０は、一般的に患者１１１およびヘルスケアプロバイダ１１２のためのプラットフォームを提供する。このプラットフォームを通じて、患者１１１およびヘルスケアプロバイダ１１２は、薬剤デバイス１６０と関連付けられたセンサによって記録されたデータ（救助薬イベントおよび管理薬イベント双方を含む）を報告し、喘息治療計画について協働し、自身の条件および地理的位置についての情報を閲覧および入手し、他の多様な機能を利用する。
【0048】
一般的に、アプリケーションサーバ１３０は、多様なデータを取り扱うように設計される。アプリケーションサーバ１３０は、論理ルーチンを含む。この論理ルーチンは、多様な機能を行う（例えば、入来データの有効性をチェックすること、必要な場合においてデータをパージングおよびフォーマッティングすること、処理されたデータを保存のためのデータベースサーバ１４０へ送信すること、およびデータベースサーバ１４０が更新されたことを確認すること）。
【0049】
アプリケーションサーバ１３０は、少なくとも部分的に各患者についてデータを保存および管理する。この目的のため、アプリケーションサーバ１３０は、各ユーザについて患者プロファイルを生成する。患者プロファイルは、呼吸器疾患分析システム１００の患者１１１を特徴付ける１組のデータである。患者プロファイルは、患者についての識別情報を含み得る（例えば、年齢、性別、現在の救助薬、現在の管理薬、通知選好、管理薬アドヒアランス計画、関連医療履歴、および患者プロファイルへのアクセス権限を付与された非患者ユーザのリスト）。プロファイルは、デバイス識別子をさらに指定し得る（例えば、患者についてのデータ（例えば、コントローライベントおよび救助薬イベント）を提出する権限を付与された１つ以上のクライアントデバイス１１０またはセンサ１２０を特定する一意のメディアアクセス制御（ＭＡＣ）アドレス）。
【0050】
プロファイルは、患者１１１および患者個人のヘルスケアプロバイダ１１２へ提供される異なる種類の通知と、通知を提供する頻度とを指定し得る。例えば、患者１１１は、救助イベントを示す通知を受信する権限をヘルスケアプロバイダ１１２に付与し得る。患者１１１は、患者個人の患者プロファイルおよび救助イベント履歴へのアクセス権限も、ヘルスケアプロバイダ１１２へ付与し得る。ヘルスケアプロバイダ１１２は、患者１１１の患者プロファイルへのアクセスを付与されると、当該ヘルスケアプロバイダは、コントローラアドヒアランスまたは救助薬計画を指定し得る。薬剤計画は、管理薬について処方された１日あたりの用量数を含み得る。
【0051】
アプリケーションサーバ１３０は、ヘルスケアプロバイダ１１２のプロファイルも生成する。ヘルスケアプロバイダプロファイルは、ヘルスケアプロバイダ１１２についての識別情報を含み得る（例えば、オフィス位置、資格情報および証明書）。ヘルスケアプロバイダプロファイルは、患者母集団についての情報も含む。プロバイダプロファイルは、当該プロバイダの患者のプロファイル全てへのアクセスと、これらのプロファイルから導出されたデータ（例えば、集合人口統計学情報、救助および管理薬イベントパターン）とを含み得る。このデータは、患者プロファイル中に保存された任意の種類のデータに応じて（例えば、地理的領域（例えば、近隣、都市別に）および期間別に（例えば、週、月または年））さらに再分割され得る。
【0052】
アプリケーションサーバ１３０は、救助薬イベント情報をクライアントデバイス１１０またはセンサ１２０から受信して、アプリケーションサーバ１３０上の多様なルーチンをトリガさせる。以下に述べる例示的実装形態において、データ分析モジュール１３１は、呼吸器疾患イベントデータおよび他のデータ（患者プロファイルを含む）へアクセスするためのルーチンを実行し、このデータを分析し、分析結果を患者１１１およびプロバイダ１１２双方へ出力する。このプロセスは、一般的に呼吸器疾患リスク分析と呼ばれる。本例において、リスク分析は、患者１１１について喘息に関連して行われる。喘息リスク分析は、患者の環境の関連変化に起因する救助イベントに応答しておよび以下にさらに述べる複数のトリガ条件のうちいずれか１つに応答して任意の時点において行われ得る。
【0053】
他の分析も可能である。例えば、リスク分析を複数の患者の救助および管理薬の使用について行うと、個人の基準線、地理的基準線、臨床的基準線、疫学的基準線、人口統計学的基準線または空間的時間的基準線あるいは予測される値または予期される値からの履歴的に有意の順列に基づいて、薬剤使用の空間的／時間的クラスター（またはアウトブレイク）に基づいた特定が行われ得る。他の種類の分析を挙げると、日々の／週のアドヒアランストレンド、アドヒアランスの経時変化、他の関連母集団とのアドヒアランスの比較（例えば、全患者、特定の救助薬または管理薬あるいはこれらの組み合わせの患者、トリガの特定（空間的、時間的、環境）、救助利用の経時的トレンド、および他の関連母集団との救助利用の比較がある。
【0054】
任意の分析の実行に応答して、アプリケーションサーバ１３０は、プッシュ通知を準備して、患者１１１、権限付与されたヘルスケアプロバイダ１１２、および／または患者プロファイルへのアクセスを提供した他のユーザへ送信する。通知により、薬剤救助イベントにおいて必要とされるタイミング、位置、および影響を受ける患者（単数または複数）１１１についての詳細が得られ得る。通知は、緊急支援プロバイダ１１２へ分配される緊急支援をリクエストする苦痛信号または緊急信号をさらに含み得る。通知は、データ分析モジュール１３１によって行われる喘息リスク分析の結果も含み得る。送信され得る通知の種類についてのさらなる情報と、これらに含まれ得るコンテンツとについて、以下にさらに説明する。
【0055】
喘息リスク分析に応答するプッシュ通知の提供に加えて、通知をプル通知として特定の時間間隔と共に提供してもよい。さらに、いくつかの通知のトリガを（プッシュまたはプルに関わらず）救助薬イベントに応答して行われる喘息リスク分析に応答して行う代わりに、喘息リスク分析において変化していく潜在的要素のうち１つに応答して行われるリスク分析に応答して行うと、通知更新が保証される。例えば、大気汚染の増大が発生中であるかまたは発生しそうであることが気象条件から判明した場合、当該汚染が発生している特定の地理領域内にいる患者全てについての喘息リスク分析の実行がトリガされ得る。
【0056】
ネットワーク１５０を通じてクライアントアプリケーション１１５へ提供される通知のデータフォーマットは、クライアントアプリケーションと共に使用されるように具体的に設計され、追加的にまたは代替的にショートメッセージサービス（ＳＭＳ）メッセージ、ｅメール、電話の呼び出し音として提供してもよいし、あるいは他の通信媒体を用いて通信する他のデータフォーマットとしてもよい。
【0057】
データベースサーバ１４０は、患者およびプロバイダデータ関連データを保存する（例えば、プロファイル、薬剤イベント、患者医療履歴（例えば、電子医療記録））。患者およびプロバイダのデータは、セキュリティのために暗号化され、少なくともパスワード保護されかつ他の様態で医療保険移動説明責任法（ＨＩＰＡＡ）の要件全てを満たすようにセキュアにされる。複数の患者からのデータ（例えば、集合救助薬イベントデータ）を用いた任意の分析（例えば、喘息リスク分析）がユーザへ提供され、患者のプライバシー保護のために匿名化により個人特定情報が除去される。
【0058】
データベースサーバ１４０は、喘息リスク分析において用いられる非患者データも保存する。このデータには、（患者が物理的に存在し、汚染物質に晒される可能性のある）複数の地理領域（例えば、住居ゾーンまたは商業ゾーン内の公共空間）についての地域データが含まれる。このデータは、緑地への患者の近接（樹木および植物が集中している領域）を明確に含み得るかまたはそのような近接が得られるように処理され得る。地域データの一例を挙げると、ジオリファレンスされた天候データがある（例えば、温度、風パターン、湿度、空気質指数）。別の例として、ジオリファレンスされた汚染データがある（例えば、ある時期におけるまたは経験的に測定された多様な汚染物質の粒子数）。この地域データは、救助イベントの時間および場所についての現在の気象条件についての情報を含む（例えば、温度、湿度、空気質指数）。上記データのアイテムは全て経時的に変化し得るため、データそのものが、時間別に索引付けされ得る。例えば別個のデータポイントを時刻別に（例えば、分または時間単位で）利用可能にしてもよいし、あるいはより長期の期間にわたって（例えば、日、週、月または季節毎に）利用可能にしてもよい。図１に示すデータベースサーバ１４０をアプリケーションサーバ１３０と完全に別のものとして図示しているが、データベースサーバ１４０をサーバ１３０などの別のサーバの一部であるハードウェア構成要素としてもよく、その場合、データベースサーバ１４０は、１つ以上の永続的保存デバイスとして実行され、データベース中に保存されたデータとのインターフェースをとるソフトウェアアプリケーション層は、他のサーバ１３０の一部となる。
【0059】
データベースサーバ１４０は、データ保存を定義されたデータベーススキーマに従って行う。典型的には、異なるデータソースにわたるデータ保存スキーマは、潜在的データベース構造の実装の違いに起因して、（同種のデータ（例えば、クラウドアプリケーションイベントログおよびログメトリック）を保存する場合であっても）有意に変化する。データベースサーバ１４０は、異なる種類のデータも保存し得る（例えば、構造化データ、非構造化データ、または半構造化データ）。データベースサーバ１４０中のデータは、患者、患者グループおよび／またはエンティティと関連付けられ得る。データベースサーバ１４０から、データベースサーバ１４０によって示されるデータベースオブジェクトの管理のための命令、データベースサーバ１４０からの情報読み出しのための命令、またはデータベースサーバ１４０への書き込みのための命令を指定するための問合わせ言語（例えば、関係データベース用のＳＱＬ、ＪＳＯＮ ＮｏＳＱＬデータベース）で書かれたデータベース問い合わせへのサポートが得られる。
【0060】
ネットワーク１５０は、クライアント１１０デバイス、センサ１２０、アプリケーションサーバ１３０およびデータベースサーバ１４０間の多様な有線経路および無線通信経路を示す。ネットワーク１５０は、標準的なインターネット通信技術および／またはプロトコルを用いる。よって、ネットワーク１５０は、イーサネット（登録商標）、ＩＥＥＥ８０２．１１、統合サービスディジタル通信網（ＩＳＤＮ）、非同期転送モード（ＡＴＭ）などの技術を用いたリンクを含み得る。同様に、ネットワーク１５０上において用いられるネットワーキングプロトコルは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、簡易メール転送プロトコル（ＳＭＴＰ）、ファイル転送プロトコル（ＦＴＰ）などを含み得る。ネットワーク１５０を介して交換されるデータは、技術および／またはフォーマット（例えば、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ））を用いて表現され得る。加えて、全てまたはいくつかのリンクの暗号化が、従来の暗号化技術を用いて行われ得る（例えば、セキュアソケット層（ＳＳＬ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）および／または仮想私設ネットワーク（ＶＰＮ））。別の実施形態において、エンティティは、上記したものの代替としてまたは上記したものに加えてカスタムデータ通信技術および／または専用データ通信技術を用い得る。
【0061】
図２は、一実施形態による例示的コンピュータ２００の物理的構成要素を示す高レベルブロック図である。このコンピュータ２００は、図１からのクライアントデバイス１１０、アプリケーションサーバ１３０、および／またはデータベースサーバ１４０の一部として用いられ得る。図示されているのは、少なくとも１つのプロセッサ２０５へ連結されたチップセット２１０である。チップセット２１０へ連結されているのは、揮発性メモリ２１５、ネットワークアダプタ２２０、入力／出力（Ｉ／Ｏ）デバイス（単数または複数）２２５、不揮発性メモリを示す保存デバイス２３０、およびディスプレイ２３５である。一実施形態において、チップセット２１０の機能は、メモリコントローラ２１１およびＩ／Ｏコントローラ２１２によって提供される。別の実施形態において、メモリ２１５は、チップセット２１０ではなくプロセッサ２０５へ直接連結される。いくつかの実施形態において、メモリ２１５は、高速ランダムアクセスメモリ（ＲＡＭ）を含む（例えば、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭまたは他のランダムアクセスソリッドステートメモリデバイス）。
【0062】
保存デバイス２３０は、任意の非一時的なコンピュータ可読記憶媒体である（例えば、ハードドライブ、コンパクトディスク読み出し専用メモリ（ＣＤ－ＲＯＭ）、ＤＶＤ、またはソリッドステートメモリデバイス）。メモリ２１５は、プロセッサ２０５によって用いられる命令およびデータを保持する。Ｉ／Ｏデバイス２２５は、タッチ入力面（容量性または他の様態）、マウス、トラックボール、または他の種類のポインティングデバイス、キーボード、あるいは別の形態の入力デバイスであり得る。ディスプレイ２３５は、コンピュータ２００からの画像および他の情報を表示する。ネットワークアダプタ２２０により、コンピュータ２００がネットワーク１５０へ連結される。
【0063】
当該分野において公知のように、コンピュータ２００は、図２に示すものと異なる構成要素および／または他の構成要素を有し得る。加えて、コンピュータ２００は、特定の図示の構成要素を含まない場合がある。一実施形態において、コンピュータ２００がサーバ１４０として機能する場合、専用Ｉ／Ｏデバイス２２５および／またはディスプレイ２１８を含まない場合がある。さらに、保存デバイス２３０は、コンピュータ２００に対してローカルおよび／またはリモートであり得（例えば、保存領域ネットワーク（ＳＡＮ）内において具現化されたもの）、一実施形態において、保存デバイス２３０は、ＣＤ－ＲＯＭデバイスまたはＤＶＤデバイスではない。
【0064】
一般的に、クライアントデバイス１１０において用いられる物理的構成要素は、厳密にはアプリケーションサーバ１３０およびデータベースサーバ１４０とはサイズ、電力要求および性能が異なる。例えば、クライアントデバイス１１０（これは、家庭用コンピュータ、タブレットコンピュータ、ラップトップコンピュータまたはスマートフォンであることが多い）は、比較的小さな保存用量および処理能力を含むが、入力デバイスおよびディスプレイを含む。これらの構成要素は、データのユーザ入力および受信、表示、ならびにアプリケーションサーバ１３０から提供された通知との対話に適している。対照的に、アプリケーションサーバ１３０は、多数の物理的に別個のローカルにネットワークされたコンピュータを含み得る。これらのコンピュータはそれぞれ、上記した喘息リスク分析の実行のために有意の量の処理能力を有する。一実施形態において、アプリケーションサーバ１３０の処理能力は、Ａｍａｚｏｎウェブサービス（商標）などのサービスによって提供される。また、対照的に、データベースサーバ１４０は、多数の物理的に別個のコンピュータを含み得る。これらのコンピュータはそれぞれ、アプリケーションサーバと関連付けられたデータを保存するための有意の量の永続的保存能力を有する。
【0065】
当該分野において公知のように、コンピュータ２００は、本明細書中に記載の機能を提供するコンピュータプログラムモジュールを実行するように適合される。モジュールは、ハードウェア、ファームウェア、および／またはソフトウェア内において実行され得る。一実施形態において、プログラムモジュールは、保存デバイス２３０上に保存され、メモリ２１５内へロードされ、プロセッサ２０５によって実行される。
【0066】
ダッシュボード（例えば、図３Ａに示すダッシュボード３００）により、ユーザと呼吸器疾患分析システム１００との間の対話が可能になる。ダッシュボード３００により、ユーザ間（例えば、患者１１１からプロバイダ１１２）またはユーザ／システム間／システム／ユーザ間における情報転送手段が得られる。ダッシュボード３００は、クライアントデバイス１１０上のクライアントアプリケーション１１５を通じてアクセスされ、また、患者およびヘルスケアプロバイダ双方による薬剤救助イベントの監視、個別化された患者ヘルスケア情報の交換、および喘息救助イベントリスク通知などの通知の受信を可能にする機構を提供する。患者は、例えば喘息、薬剤使用度または喘息管理についての情報の議論および共有のために、他のヘルスケアプロバイダおよび他の患者との通信をダッシュボード３００を通じて行い得る。喘息ヘルスケア情報の共有が可能となることにより、類似の問題を抱えている患者またはヘルスケアケアプロバイダに対し、個々の考え方を共有するための方法が提供される。
【0067】
ダッシュボード３００により、多様な人口統計学セグメントまたは地理的セグメントにおける喘息患者およびコミュニティデータおよび統計についての情報の視認、注釈付与、更新、対話およびエクスポートできる患者のリストへの権限付与されたヘルスケアプロバイダ１１２がアクセスすることも可能になる。ダッシュボード３００を用いて、ヘルスケアプロバイダは、患者を個々にまたは集合的に監視し、ヘルスケアプロバイダの関連付けられた患者母集団が喘息管理ガイダンスにどのように反応しているかについてのフィードバックを受信および提供することができる。個々の患者または複数の患者へのアクセスを有するヘルスケアプロバイダは、通知閾値の確立、通知についてのパラメータ設定、および患者のイベント履歴が特定の条件（例えば、救助イベント）と整合した場合の通知受信を行うことができる。さらに、ダッシュボード３００は、以下に述べるように、喘息分析システム１００によって生成された特定の人口統計のイベントパターンについての一般的患者母集団に関連した定期報告を受信および表示し得る。
【0068】
ユーザに対し、ダッシュボード３００は、表示「カード」３１０を通じて多様な情報を提示する（例えば、表形式のデータ、グラフィカル視覚化および分析）。表示カード３１０は、より小型のディスプレイ（典型例としてポータブル型クライアントデバイス１１０）（例えば、携帯電話またはタブレット）に快適に適合され、野球カードにおいて見受けられる単純な構成形態を模倣した「バイトサイズ」の情報ピースを含む。ダッシュボード３００は、システムメニュー３０５も含み得る。システムメニュー３０５により、異なるカテゴリーのヘルスケア情報をユーザがナビゲートすることが可能になる。
【0069】
アプリケーションサーバ１３０から提供される通知は、表示カード３１０に関連する。一般的に、通知は、アプリケーション１１５を通じてユーザへ提示されるべき情報だけでなく、通知のコンテンツの表示に用いられる表示カード３１０を指定するパラメータも含む。アプリケーションサーバ１３０からプッシュ／プルされた情報は全て、１つ以上のカードと関連付けられ得る。例えば、喘息リスク分析の結果に基づいて、通知が患者へプッシュされ得る。ダッシュボード３００は、この通知を処理し、この通知中の情報の提示に用いられるカードを決定する。例を継続して、通知の受信者は、アプリケーションサーバ１３０からデータをプルしたいとのリクエストを生成し得る。アプリケーションサーバ１３０は、リクエストされたデータを別の通知中に入れて提供し、その後、ダッシュボード３００は、リクエストされた情報が表示される表示カード３１０を決定する。
【0070】
提示された情報との対話のために、いくつかの表示カード３１０ａは、入力応答３１５の領域を含む。例えば、図３Ｂに示す表示カード３１０ｂ内において、患者は、入力応答３１５の領域内においてスクロールアップまたはスクロールダウンして喘息管理に用いられる管理薬を選択するか、または、「次」を選択してさらなる表示カード３１０へ移動する。
【0071】
ダッシュボード３００は、複数のカテゴリーに分類され得る多様な異なる表示カード３１０を提供し得る。情報カード種類は、データを表示するカードを含む。情報カードは、例えば、薬剤救助イベント、統計、および患者データおよびコミュニティデータ双方を含むマップを表示する。情報カードは、イベントカード、トレンドカード、教育カードおよび警告表示カードにさらに細かくカテゴリー分類される。
【0072】
イベントカードは、救助薬イベントに関連するデータを含む（例えば、特定の患者についての薬剤救助イベントの履歴リスト、または特定のプロバイダのために地図上に重畳された患者救助イベントデータ）。例えば、図３Ｂに示す表示カード３１０ａはイベントカードであり、特定の地理領域内における喘息救助イベントを経験している患者をハイライト表示する。別のイベントカードは、例示的な薬剤使用度報告を表示し得る（例えば、救助利用イベントの位置の地図、当該位置における環境条件、および救助利用イベントについてのトリガを受信者が付加するための入力応答領域３１５）。別のイベントトレンドカードは、前週の救助デバイス使用度を表示し得る（例えば、当該期間における合計使用回数および各日の使用回数）。
【0073】
トレンドカードは、受信者にとって分かり易いように設計されたグラフまたはチャートを用いて提示された統計情報を含む。トレンドカードの例を挙げると、多様な期間にわたる喘息救助イベントのプロット、時刻トレンド、１週間のうちの数日間のトレンドおよびトリガトレンドがある。本例において、トレンドカードにより、一般的患者母集団からのデータのコンテクスト中の特定の呼吸データを一次患者が理解することが可能になる。
【0074】
教育カードは、受信者の教育目的のための情報を含む。教育カードから、一般的疾患情報と、救助イベントのリスクを低減させるための患者向けのヒントが得られる。いくつかの教育カードの場合、提供された情報が将来のカードとして用いられる場合に関連するかまたは興味深いかを受信者が指定することを可能にする入力応答３１５が必要になり得る。
【0075】
警告カードにより、重要情報（例えば、イベントの危険性がある旨および／または最近の一定期間においてデバイスからのデータ受信が無い旨受信者に通知すること）がユーザに通知される。他の警告を挙げると、クライアントデバイス上の設定に起因してデータ同期ができなくなっている（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）がオフになっている）旨または患者の喘息リスクスコアが変化した旨の警告がある。
【0076】
検査カード種類は、「はい／いいえ」、複数の選択、またはユーザからの応答を求める自由回答質問の提示によりユーザ応答を要求する。例えば、ヘルスケアプロバイダまたは喘息分析システム１００は、検査カードを喘息関連質問表と共に患者１１１へ送信して、特定の患者の疾患管理レベルを決定し得る。さらに、検査カードは、喘息症状の治療のために患者１１１によって用いられる管理薬の種類をリクエストし得る。一般的に、検査カードは、（上記したように）患者の医療履歴または患者プロファイルに記載されていない場合があるデータをアプリケーションサーバ１３０へ提供し、かつ／または、利用に不適なほど古くなっている可能性のある情報に対する更新を提供する。患者登録プロセスの完了およびデータベースサーバ１４０中に保存される患者プロファイルの生成のために、１つ以上の検査カードが用いられ得る。例えば、患者１１１が先ず呼吸器疾患分析システム１００に登録する際、プッシュ通知がアプリケーションサーバ１３０によってトリガされて、患者１１１による患者プロファイルの生成をプロンプトする。
【0077】
検査カードの例を挙げると、喘息救助イベントの結果患者が緊急治療室を１回でも訪問したか否かについて訊く検査質問、患者の管理薬についての情報、患者がイベント管理のために自身の救助薬を使用した回数、および患者の管理薬の日々のスケジュールがある。検査カードは、患者に特有の喘息トリガについての質問も含み得る（例えば、花粉がトリガになるか）。いくつかの検査カードにおいては、５ポイント型のライカートスケールに基づいて一般的な生活の質を評価するよう患者に要求する場合もあり、患者の睡眠の質の評価、直近７日間における活動性の評価などをしてもらう。他の検査カードにおいて、昨日と比較して体調は良いか悪いか、直近１２ヶ月間において救助イベントに起因して緊急治療室または病院を訪れたかなどが患者に訊かれる。
【0078】
いくつかの場合において、患者挙動またはセンサ報告型のイベント情報と既存の患者情報との間に矛盾が有る場合、患者の状況についての不明点の解明のために、検査カードの送信がトリガされ得る。例えば、患者が経験している喘息イベント数が予測よりも多い場合、正しい薬剤が使用されているかを確認するために、検査カードにより、患者の薬剤デバイス１６０上のリスト上に現在記載されている薬剤の種類についての情報がリクエストされ得る。別の例において、管理薬使用について記録された情報中の記載では当該患者の１日あたりの当該管理薬の使用は１回だけであるが患者アドヒアランス計画中には管理薬を１日２回使用すべきであるはずの旨が記載されている場合、システム１００は、アドヒアランス計画を変更する必要があるか否かについて患者に訊く通知を送信し得る。
【0079】
いくつかの場合において、患者挙動またはセンサ報告型のイベント情報と既存の患者情報との間に矛盾が有る場合、患者の状況についての不明点の解明のために、検査カードの送信がトリガされ得る。例えば、患者が経験している喘息イベント数が予測よりも多い場合、正しい薬剤が使用されているかを確認するために、検査カードにより、患者の薬剤デバイス１６０上のリスト上に現在記載されている薬剤の種類についての情報がリクエストされ得る。別の例として、管理薬使用について記録された情報中の記載では当該患者の１日あたりの当該管理薬の使用は１回だけであるが患者アドヒアランス計画中には管理薬を１日２回使用すべきであるはずの旨が記載されている場合、システム１００は、アドヒアランス計画を変更する必要があるか否かについて患者に訊く通知を送信し得る。
【0080】
ナビゲーションカードによって示される実行可能なデータまたはメッセージは、ユーザ対話時において、ダッシュボード３００の一部である別の画面またはカードへユーザをリダイレクトし得る。例えば、患者が医師と情報を共有することを望むかかまたは管理薬について特定の薬剤計画を医師にリクエストした場合、ナビゲーションカードを用いれば、コントローラアドヒアランス計画中の情報または登録の共有が促進される。さらに、ナビゲーションカードにより、ユーザが薬剤救助イベント関連の情報を更新することが可能になる。
【0081】
アドヒアランスカードは、患者が自身の管理薬を異なる期間にわたってスケジュール通りに継続使用することを奨励するように設計される。アドヒアランスカードは、連続発生でない場合であっても、（相対的な実績向上である）「連続発生」または時間通りの管理薬イベントの継続的実行を示し得る。さらに、検査カードは、有意の数の救助イベントが期間閾値以内に相互に記録されたのに応答して、患者の物理的状態について問い合わせし得る。管理薬イベントは、日中の多様な期間において患者１１１が（自身のヘルスケアプロバイダ１１２の処方通りに）自身の管理薬を時間通りに飲んだかおよび飲んでいなかったかを示すグラフとして示され得る。カードは、管理薬についての日々のスケジュールと、スケジュール通りの用量が飲まれたかを示すインジケータとの詳細も示し得る。例えば、赤色の「Ｘ」は、スケジュールされた用量が飲まれていない旨を示し得るが、緑色のチェックマークまたは異なる記号は、スケジュールされた用量が飲まれた旨を示し得る。
【0082】
セットアップカードにより、センサと、クライアントデバイス１１０との関連付けについて受信者がガイドされる。セットアップカードは、センサとクライアントデバイス１１０との間のＢｌｕｅｔｏｏｔｈ（登録商標）を用いたペアリングをガイドし得、ペアリングプロセスを開始するよう受信者をプロンプトし得るか、ペアリングの相手となるセンサデバイスを選択するようユーザをプロンプトし得るか、または、センサのペアリングが完了した旨をユーザに通知し得る。
【0083】
いくつかの実施形態において、ダッシュボードは、ユーザインターフェースを示し得る。ユーザインターフェースは、ユーザが「タイムラインを見る」入力応答領域３１５ｃを選択したのに応答して、救助イベントのリストを示し得る。このリストは、一定期間にわたる救助利用イベントを表示し、詳細（例えば、日付、時間、パフ数および位置）を含む。受信者は、救助利用イベントの編集および／または対話応答領域の編集を選択することによるさらなる詳細の追加を行い得る。いくつかのインターフェースは、救助利用イベントについてのイベント概要をユーザへ提示し得る。イベント概要は、ユーザがユーザインターフェースの対話応答領域の編集を選択したのに応答して、ユーザへ提示され得る。ダッシュボードから、ユーザは、薬剤リスト、詳細情報（例えば、薬剤種類（例えば、救助、コントローラ）、用量スケジュールおよびセンサ）の視認および編集も行い得る。
【0084】
喘息リスク通知の初期化のために、患者は、ダッシュボード３００とのインターフェースをとって、患者プロファイルを初期化する。患者が自身の患者プロファイルを完了させた後、クライアントデバイス１１０は、患者プロファイルをアプリケーションサーバ１３０による使用およびデータベースサーバ１４０による保存のために送信する。患者の患者プロファイルの初期化後、アプリケーションサーバ１３０は、患者の薬剤デバイス１６０と関連付けられたセンサ１２０によって検出された救助薬イベントの受信を開始し得る。患者プロファイルのこの初期化プロセスは、患者の薬剤デバイスの初回使用時のみに行われる。以下に述べるように、当該患者が特に弱い条件が、一般的患者母集団と比較して発見された場合に通知を自動的に生成してもよい。
【0085】
センサが救助利用イベントを検出すると、患者デバイス１１１は、救助イベントデータを収集し、アプリケーションサーバ１３０へ送信し、ここでイベント情報が保存される（４１５）。いくつかの実施形態において、この検出および保存プロセスは、救助利用イベントの検出の際には必ず繰り返し行われる。しかし、この頻度は、リスク分析の実行頻度とは異なり得る。
【0086】
図４は、薬剤デバイス監視に基づいて喘息リスク通知を提供する例示的プロセスの対話図である。説明するように、薬剤デバイス監視からのデータ収集により、大規模母集団に基づいたイベント警告が患者（例えば、図１中の患者１１１）へ提供される。初期のステップとして、患者は、図３Ａ中のダッシュボード３００とインターフェースをとって、患者プロファイルを初期化する（４０５）。患者が自身の患者プロファイルを完了させた後、クライアントデバイス１１０は、患者プロファイルをアプリケーションサーバ１３０による使用およびデータベースサーバ１４０による保存のために送信する。患者プロファイルの初期化（４０５）後、アプリケーションサーバ１３０は、患者の薬剤デバイス１６０と関連付けられたセンサ１２０によって検出された救助薬イベントを受信し得る。患者プロファイルの初期化および完了は、薬剤デバイス１６０の初回使用時のみに行われる。
【0087】
アプリケーションサーバ１３０は一般的には、呼吸器疾患（例えば、喘息関連イベント症状）の軽減のために患者が自身の救助薬分配器１６０を使用するたびに、救助イベントを受信する。特定のデバイス１６０／センサ１２０の組み合わせについてこのようなイベントをキャプチャするプロセスの一例として、症状の開始時に、センサ１２０は、薬剤分配器１６０のカバーが開いているかを検出し得る。薬剤分配器カバーが開いている場合、センサ１２０は、分配器１６０のプライミングに関連する加速を検出し得る。いくつかの種類の薬剤分配器の場合、「プライミング」は、一回分の用量の薬剤をパッケージングから放出させる機構を起動することを含む。他の種類の薬剤分配器において、「プライミング」は、薬剤キャニスターを素早く振ることを含む。
【0088】
プライミング作動の検出後、センサ１２０は、センサ１２０のアクティブメモリ中の救助イベントと関連付けられたデータを保存する（４１５）ように構成される。救助イベントデータは、救助イベントに関連する時間および日付、薬剤デバイス１６０のステータスまたは状態（例えば、バッテリーレベル）、（イベント前またはイベント後の）残りの用量数、自己試験結果、および薬剤デバイス１６０による治療を受けている患者の、センサ１２０によって測定されるような生理学的データを説明する情報を含み得る。センサがクライアントデバイス１１０またはネットワーク１５０とのネットワーク接続を確立させ次第、センサは、ローカル保存された救助イベントデータ全てをクライアントデバイス１１０またはアプリケーションサーバ１３０へ送信する。イベントデータが先ずクライアントデバイス１１０へ送信された場合、クライアントデバイス１１０は、クライアントデバイス１１０によりネットワーク１５０とのネットワーク接続が確立され次第、救助イベントデータをアプリケーションサーバ１３０へ送信する。実装形態に応じて、クライアントデバイス１１０またはセンサ１２０は、イベントの発生場所である地理的位置を、アプリケーションサーバ１３０へ送信されるイベントデータに追加する。
【0089】
救助利用イベントデータが受信および保存されると、アプリケーションサーバ１３０は、救助利用イベントを記述するさらなる情報を患者へリクエストし得る。情報の入手のために、アプリケーションサーバ１３０は、プッシュ通知を生成する。このプッシュ通知は、患者のクライアントデバイス１１０へ送信される予定の質問を含む。クライアントデバイス１１０は、プッシュ通知を検査種別カード３１０として提示し得る。患者は、リクエストへの応答を、検査カード３１０に対する入力３１５の提供によって行い得る。あるいは、患者１１１は、リクエストに応答しないことを選択し得る。これは許容可能であり、情報に隔たりがある場合、その後のプッシュ通知を通じて入手してもよいし、あるいはプロバイダ１１２が患者１１１と会った後に入力してもよい。１つの実装形態において、さらにリクエストされたデータがリクエストに応答して受信されなかった場合も、ステップ４２５～４４５における分析の残り部分は妨げられない。
【0090】
イベントの一部としてまたは他の様態で収集された情報に基づいて、喘息分析システムは、トリガ条件を検出する（４２０）。トリガ条件は、イベントのトリガ発生、救助イベントの位置、位置のラベル（例えば、仕事、自宅または学校）、患者にとっての当該位置の個人的重要度を示す評価、使用は先制的であったか（例えば、運動前の薬剤服用）において役割を有するパラメータに関連する情報を他の任意の関連情報に加えて示し得る。
【0091】
さらなるイベントデータのリクエストに加えて、アプリケーションサーバ１３０は、データベースサーバ１４０からの保存された文脈データへアクセスする（４２５）。一般的に、文脈データは、イベントデータ以外のデータを指し、例を以下に非限定的に挙げる：大気条件、気象条件、空気質条件、花粉データ、過去の救助利用イベントから記録された患者データ、および救助利用イベント時において薬剤デバイスによって直接検出されなかった他の任意の検討事項。対照的に、イベントデータは、救助イベントに関連しかつ薬剤デバイスから報告される任意のパラメータを指す（例えば、薬剤用量、イベントの時間、イベントの位置、および関連アドヒアランスデータ）。双方の形態のデータは、現時点の情報および保存された履歴データを含み得る。よって、文脈データの入手の一部として、アプリケーションサーバ１３０は、患者１１１の救助利用イベント履歴データにもアクセスする。この履歴データは、過去の多様な時間窓にわたる患者の履歴からの任意の過去のコントローラまたは救助薬イベントデータからのデータ全てを含み得、各履歴イベントは、当該イベントについて報告された（４１０）ような情報の同一アイテム全てと、その後のフォローアップにおいて収集された任意のデータとを含み得る。
【0092】
トリガ条件データが収集され、トリガイベントが決定され（４２０）、文脈データ４２５が入手された後、ルーチンは、喘息リスク分析４３０を行う。以下に述べるように、このリスク分析４３０は、一次患者と、収集された文脈データからとられた特定の選択されたパラメータそれぞれについての一般的患者母集団との双方に関連して行われる。以下に述べるように、特定の選択された文脈データパラメータは、一次患者および一般的患者母集団双方についての文脈データおよびトリガイベントの分析に基づいたトリガ条件として指定される。本例において、トリガイベントは、文脈データ中の特定の環境データに関連する。次に、ルーチンは、リスクスコア通知４３５を生成する。これらのリスクスコア通知は、以下に述べるように、環境パラメータの平均的リスクに関連して生成される。次に、ルーチンは、リスク指標通知をクライアントデバイス１１０上のアプリケーションへ送信して、図３Ｂに示すように結果を患者に表示する（４４０）。リスク指標は、当該条件の係数のパーセンタイルであり得る。例えば、リスク指標は、以下に述べるように環境変数のバケットに関連し得る。ルーチンにより、リスクスコア通知もプロバイダ１１２のためにクライアントデバイス１１０へ送信される（４４５）。リスクスコアも、患者１１１へ送信され得る。
【0093】
しかし、いくつかの場合において、文脈データおよび履歴データは、別個に表される。文脈データは、現在のイベントまたは患者のクライアントデバイス１１０の現在の位置に関連する地理的および地域情報を指すために用いられ得る一方、履歴データは、同じ患者または異なる患者からの以前の救助利用イベントからの地理的地域およびイベント情報を指すために用いられ得る。
【0094】
複数の喘息救助吸入器使用度イベントを個別に考えた場合、救助イベントの特定の要因についての識見はほとんど得られないものの、これらのイベントは、救助イベント間の相関の特定において有用なデータを含む。例えば、単一の救助イベントのみを分析した場合、喘息イベント文脈環境データからは、当該救助イベントの原因となった特定の条件の詳細を明確に得ることはできない可能性がある。しかし、その単一のイベントは、当該イベント時に特定の条件が存在していたことを少なくとも示す。一般的患者母集団からのいくつかの他の関連するかまたは類似するイベントからの文脈データに加えて個々のイベントの文脈データを考慮すると、データ分析モジュール１３１は、一次患者が影響を受けやすいトリガまたは影響を受けやすくないトリガを高レベルの確実性を以て特定し得る。これらのトリガ感度スコアは、一次患者および一般的患者母集団に関連してさらなるデータが収集される度に、回帰分析によって連続的に精緻化される。トリガ感度スコアは、患者母集団の生感度スコアの分布に関連して作製され、パーセンタイルとして計算される。
【0095】
通常の展開においては、データベース１４０は、救助利用イベントに関するデータを当該救助利用イベントの発生と共に受信し、一次患者データ記憶部および一般的患者母集団データ記憶部を更新して、一次患者および患者母集団中の全患者直近の現在の救助利用イベントと関連付けられた文脈データを反映する。データ記憶部が新規救助利用イベントと共に更新される頻度は、複数の要素に応じて異なり得る（例を非限定的に挙げると、患者の状況、管理薬に対する患者のアドヒアランス投薬計画、環境条件がある）。処方された管理薬投薬計画に対する患者のアドヒアランスとは、１日あたりに患者がコントローラ吸入器ユニットを使用する頻度と、患者がコントローラ吸入器ユニットを使用するよう指示されている１日あたりの頻度との間の比較であり、コントローラ吸入器ユニットの使用度に基づいて測定され得る。
【0096】
一例において、患者についてトリガを決定するプロセスは、一次患者文脈データの分析と患者母集団からのトリガ発生データとの間の比較に基づいて、図１中の分析システム１００のデータ分析モジュール１３１によって実行される。図５は、一例による、データ分析モジュール１３１の機能を行う論理構成要素を示すブロック図である。分析システム１００は、アプリケーションサーバ１３０上においてデータ分析モジュール１３１を含む。データ分析モジュール１３１は、システムによって収集された多様なデータ（これについては、上記および以下にさらに説明する）を分析して、救助吸入器使用度イベントが発生するリスクのある一次患者についてトリガを特定する。これらのトリガ分析は、通知の生成に用いられる。これらの通知は、救助吸入器の使用が必要となる呼吸イベント（例えば、喘息またはＣＯＰＤイベント）の発生をできれば回避または予期するために、一次患者に対して十分にタイムリーな様態で送信されるように明確に構成される。
【0097】
データ分析エンジン１３１は、データベース１４０からの入力を日々の患者使用度データ５１０の形態で含む。以下に述べるように、日々の患者使用度データ５１０は、一次患者データ記憶部および二次患者データ記憶部を含む。データ分析エンジン１３１は、離散化モジュール５２０、患者類似性モジュール５３０、回帰モジュール５４０、相対的ランク付けモジュール５６０、コンテンツ供給モジュール５７０および予測調節モジュール５８０を含む。一次患者についての各トリガ条件の評価のために、異なる係数５５０が回帰モジュール５４０から出力される。
【0098】
日々の患者データ５１０は、一次患者および患者母集団（例えば、図１中の患者１１１）双方から収集された使用度および文脈のデータである。データは、治療デバイス（例えば、図１中の薬剤デバイス１６０）からの使用度データを含み得る。文脈データは、独立データベースまたは他のセンサから入手され得る。さらなる関連データ（例えば、天候、汚染物質、土地使用、他の環境データ）および活動データが、他の患者センサまたは他の発生元から収集され得る。上記したように、収集されたデータは、データベース（例えば、図１中のデータベース１４０）中に保存される。
【0099】
救助吸入器使用度イベントについてデータ分析エンジン１３１によって行われる患者特有のトリガの分析は、患者母集団の患者データに基づく（例えば、文脈データ、人口統計学データおよび臨床的データ）。本明細書中述べるように、モジュール１３１によりトリガ決定が行われている患者のことを「一次患者」と呼び、１組の類似の患者のうち他の患者それぞれを「二次患者」と呼ぶ。一次患者および二次患者は全て、一般的患者母集団の一員である。データベース１４０の一次患者データ記憶部に含まれる文脈情報は、患者が救助吸入器（例えば、図１中の薬剤デバイス１６０）と関連付けられている旨を毎日記述する。一次患者データは、一次患者およびその薬剤投薬計画の医療条件を記述する人口統計学データおよび臨床的データも含む。同様に、データベース１４０の二次患者データ記憶部は、一組のうちのその他の患者についての人口統計学データ、臨床的データ、および文脈データを保存する。この１組の類似の患者は、複数の方法に従って決定され得る。一例として、１組の他の患者の利用は、同一ネットワーク１５０（例えば、３Ｇ携帯電話タワールータ、ローカルインターネットサービスプロバイダ）を介して接続された救助吸入器を使用している患者によって決定され得、これにより、患者が地理的にグループ分けされる。例えば、ネットワーク１５０と通信している救助吸入器を使用している患者が１００人である場合、一次患者記憶部は、（その時点においてトリガが決定されている）１人のユーザと関連付けられたデータを保存し、二次患者データ記憶部は、残りの９９人と関連付けられたデータを保存する。他の方法において、他の基準が用いられ得る（例えば、文脈データ、人口統計学データまたは臨床的データに基づいたもの（特定の例を以下に示す））。一次患者データおよび二次患者データは一般的には、同じ情報を含む（例えば、文脈データ、人口統計学データおよび患者データ）。
【0100】
文脈データは、１つ以上の救助イベントが実際に発生した数日間と、救助利用イベントが発生しなかった数日間とを記述する。データベース１４０中の一次患者データ記憶部は、ユーザがセンサ１２０を薬剤デバイス１６０と共に用いた最初の１ヶ月にわたるユーザの挙動の記録も含み得る。文脈データの例を非限定的に挙げると、大気汚染物質条件（例えば、オゾン分子（Ｏ３）、二酸化窒素分子（ＮＯ２）、二酸化硫黄分子（ＳＯ２）、２．５マイクロメータ以下の粒子状物質（ＰＭ２．５）、粒子状物質、１０マイクロメータ以下の粒子状物質（ＰＭ１０）、および空気質指数）、ならびに気象条件（例えば、温度、湿度、風速、風向、現地気圧および視程）がある。各文脈条件は、救助吸入器使用度イベントに貢献するかまたは刺激を付与する潜在的トリガ条件も示す。一般的に、文脈データはの収集は、デバイスまたは他のサードパーティデータ報告に基づいて自動的に行ってもよいし、患者および／またはプロバイダが手動で行ってもよいし、あるいは他の方法で入手してもよい。救助吸入器使用度イベントおよび他の文脈データの特定は、センサ１２０、クライアントデバイス１１０および／または薬剤デバイス１６０が地理領域の境界内に物理的に配置されている間にイベントが一時的に発生した場所に基づいて行ってもよい。
【0101】
人口統計学データは、各患者を記述する（例を非限定的に挙げると、各ユーザの性別、性別および基本位置）。基本位置は、患者がほとんどの時間を過ごす地理領域を指す（例えば、自宅住所またはオフィス住所）。地理領域のサイズは、患者の救助吸入器使用度の頻度および患者のリスクレベルに応じて変化し得る（例えば、５００フィートの面積、緯度／経度の座標、郵便番号、市境）。人口統計学データは、センサ１２０の使用のセットアップ時に患者によってＧＵＩ３００を通じて手動入力してもよいし、あるいは、ヘルスケアプロバイダが自身のシステムとの関連付けのために提供してもよい。
【0102】
患者データは、臨床的情報も含み得る（例えば、薬剤種類、処方量、処方データ、服用された薬剤用量、患者が救助薬を服用する１日あたりの頻度と、救助薬を服用するよう処方により指示されている頻度とを比較するアドヒアランス投薬計画）。患者データは一般的にはヘルスケアプロバイダによって入力されるが、患者が手動入力してもよい。
【0103】
個々の一次患者は、特定のトリガ条件よる影響を他の患者よりも受け易い場合がある。本明細書中に記載のように、トリガは、測定可能な量（例えば、文脈データからの環境条件）を指す。この測定可能な量は、独立して用いられるか、または、患者の条件を悪化させることにより救助吸入器使用度イベントを発生させる１つまたは他のトリガと組み合わされる。例えば、高レベルの湿度を含む条件下において、ある患者は、喘息救助利用イベントのリスクが別の患者よりも高い場合がある。よって、データ分析エンジン１３１は、各患者に関連するトリガと、一般的患者母集団における分布に関連する各トリガについての患者にとっての相対的リスクとを決定する（ただし、存在する場合）。よって、トリガの係数は、一次患者にとってのトリガの絶対的リスクを示す。全患者の分布のクオンタイルとしての係数である相対的リスクも決定される。
【0104】
本例において、離散化モジュール５２０は、連続する環境文脈変数データを離散変数バケットに変換する。このプロセスにより、各種の地域からの環境データが異なるバケットにグループ分けされる。本例において、「領域」とは、収集されたデータの種類、データフォーマットおよび他の要素の便宜上、ある国における患者である。これらのバケットは、異なる技術によって生成され得る（例えば、一定範囲のパラメータ範囲にわたる同じサイズのバケットの生成または特定のピーク閾値の生成）。ピーク閾値は、ドメイン知識から決定してもよいし、あるいは、患者が全体的に経験している変数のパーセンタイルとして決定してもよい。例えば、第９０パーセンタイル以上がオゾン向けのバケットとして選択され得、０．０７ｐｐｍの値に下降し得る。これにより、複数の領域における回帰を異なる環境条件と比較し、極端な条件による影響に集中して、一次患者がトリガ条件による影響を受け易いかを決定することがより容易になる。罹病性の決定のために、他のデータが用いられ得る。例えば、土地使用および他の位置データ（例えば、患者に関連する建物環境）が分析され得る。患者によって行われる活動も、装着された健康モニタから用いられ得る。
【0105】
例えば、変数を連続的に保持すると、南カリフォルニアに居住している者について極めて高い係数が温度トリガイベントに関連して得られ得る。しかし、この領域内の温度は、６５～７５度の範囲内でしか変化しない。得られた係数を、温度が３０～１００度の範囲内において変化し得るニューヨークシティ内にいる者の係数と比較するのは困難である。変数の離散化プロセスを用いれば、この問題に対応できる。すなわち、患者が極端な条件に晒されていないとき、当該条件を示す離散変数列は、全て０ｓであり、この変数は、回帰から有効に排除されて、係数は０になる。特定のトリガ条件を経験したユーザのみが、当該条件と関連付けられたリスクを示す係数を生成するため、当該条件を経験した他の患者との類似したもの同士の比較が可能になる。変数が連続している場合、これは不可能である。
【0106】
図６Ａは、離散化モジュール５２０による温度などの環境パラメータの離散化プロセスの図である。例示的な連続する環境変数６１０（例えば、８５度の温度）が、収集された日々の患者データから決定される。１組の離散化規則６１２が、バケット生成のために適用される。本例において、温度に関連する離散化規則により、１組の温度範囲６１４が得られる。離散変数ルーチン６１６により、得られた温度データ（８５度）が適用可能な規則に従って分類される。本例において、ルーチン６１６により、得られたデータを分類する一連のバケット６１８が生成される。例えば、８５度の温度データが１を介して７５度および８０度を超えるバケットへ付加される一方、他のバケットは、当該データがこれらのバケット内に分類されないことを示すゼロを有する。
【0107】
患者類似性モジュール５３０は、初めてシステムに参加する際に患者の静特性をとり、これらの特性に基づいて最も類似する患者を特定する。変数に対してスケーリングおよび重み付けが行われ得、類似性測定は、ガウスラジアルに基づいた関数、逆ユークリッド距離、コサイン距離または他の任意の適切なカーネルまたは類似性測定を含み得る。十分な一次患者データが収集されているいくつかの例において、一次患者データのみを含む集合データセットが用いられ得る。十分な一次患者データにより、一次患者が各トリガ条件からの影響を受け易いかまたは受け易くないかをデータ分析モジュール１３１が（当該患者のデータのみに基づいて高レベルの確実性と共に）特定することが可能になる。しかし、特定を高レベルの確実性と共に行うためには、一次患者が救助吸入器使用度を長期間（例えば、数ヶ月～数年）にわたって使用することで得られる大量のデータが必要になる。そのため、データ分析モジュール１３１が相対的に新しい患者についてのトリガ条件を確信的に特定するために必要な時間を短縮させるために、患者類似性モジュール５３０は、これらの決定をより高い確実性と共に行うために、一次患者と人口統計学的に、文脈的にかつ臨床的に類似する二次患者からのデータを供給して、集合データセットを補足する。そのため、これらの場合において、一次患者および二次患者双方からのデータを含む集合データが用いられる。一次患者からのデータ収集が初めて行われる際、二次患者からのデータの使用が必要になり得る。一次患者から収集されるデータが多いほど、二次患者データの使用は少量になる。一般的に、一次患者に「十分に類似する」患者が存在する場合、二次患者データが用いられる。二次患者データの重み付けは、一次患者からのデータ収集が多くなるほど、概してスケールバックされる。
【0108】
図６Ｂは、患者類似性モジュール５３０の詳細図である。患者類似性モジュール５４０は、スケーリングサブモジュール６３０、フィーチャ重み付けサブモジュール６３２および類似性サブモジュール６３４を含む。類似性サブモジュール６３４は、Ｋ個の最も近接する患者重み６３６を出力する。これらの患者重み６３６は、一次患者に最も類似する二次患者を構成する。１組の患者記録６３８が、スケーリングサブモジュール６３０へ入力される。これらの患者記録は、異なる種類のデータを含む。本例において、データは、患者ＩＤ、性別、地理的位置、薬剤および用量を含み得る。異なる種類のデータはそれぞれ、スケーリングサブモジュール６３０によってスケーリングされる変数である。１組の重みが、フィーチャ重み付けサブモジュール６３２から異なる種類のデータそれぞれへ付加される。類似性サブモジュール６３４により、二次からの類似性がこの重み付けに基づいて決定される。類似性サブモジュール６３４の出力は、Ｋ個の最も近接する患者重みであり、一次患者に最も類似しているものとして決定された二次患者のデータセットの数である。Ｋ個の類似する二次患者のこれらのデータセットは、二次患者データ記憶部内に保存された後、図５中の回帰モジュール５４０への入力のために一次患者からのデータと共に集計される。上記したように、二次患者データは、一次患者からのデータが不足している場合に用いられ得る。
【0109】
回帰モジュール５４０は、設定期間にわたって一次患者から収集されたデータに対して回帰分析を行って、一次患者についてトリガ条件を提供する。データ収集量が増えるにつれて、さらなる回帰分析が定期的な間隔で回帰モジュール５４０によって行われるため、分析精度がトリガ条件に関連して向上する。回帰モジュール５４０は、一次患者のリスクスコアの統計分析をトリガ条件それぞれに関連して行う。より詳細には、回帰モジュール５４０は、トリガ条件のリスクスコアの有意性、確実性、および大きさを決定し得る。
【0110】
図６Ｃは、回帰モジュール５４０の構成要素のブロック図である。回帰モジュール５３０は、一次患者入力６５０および二次患者入力６５２を含む。一次患者入力６５０は日々のデータであり、一次患者から指定された時間Ｔまで収集される。二次患者入力６５２は、一次患者に十分に類似しているものとして患者類似性モジュール５３０から決定された患者から収集されたデータである。患者類似性重みモジュール６５４は、図６Ｂ中の患者類似性モジュール５３０からの患者類似性重み付け６３６および最適なハイパーパラメータ６５６を二次患者入力６５２からのデータに付加する。一次患者６５０からのデータおよび二次患者６５４からの重み付けデータは、重み付けされた訓練データモジュール６５８内へ入力される。重み付けされた訓練データモジュール６５８から、患者データ入力６５０および６５２から収集された各種のデータへの重みが窓化モジュール６６０へ提供される。窓化サブモジュール６６０により、重み付けされた訓練データモジュール６５８からのデータの種類それぞれが、訓練サブモジュール６６２へ制限される。窓化は、当該種類のデータについての時間パラメータ、現在の条件、または過去の条件を含み得る。例えば、窓化は、現在のオゾンレベルまたは過去の２日間、３日間または４日間の平均および最大オゾンレベルの計算のために用いられ得る。最適なハイパーパラメータ６５６は、母集団調整サブモジュール６６４の出力から導出される。例えば、ハイパーパラメータ６５６は、以下を含み得る：含まれるべき類似する患者の数、用いられる重み付けスキーム、「振り返る」ための窓のサイズ、および回帰時に用いられる正規化／ペナルティサイズ。最適なハイパーパラメータ６５６は、重みモジュール６５４、窓化サブモジュール６６０および訓練サブモジュール６６２に設けられる。訓練サブモジュール６６２から、変数係数６６６が出力される。変数係数６６６は、呼吸イベントをトリガし得る特定の一次患者についての環境パラメータそれぞれの相対値である。
【0111】
本例において、母集団調整サブモジュール６６４は、最適なハイパーパラメータ６５６を捜索する。これらのハイパーパラメータの例を非限定的に挙げると、変数集計／概要のためのトレーリング窓サイズ（trailing window size）、類似の患者の数（存在する場合）、類似の患者に対するサンプル重み付けスキーム（存在する場合）、および訓練サブモジュール６６２そのものにおいて用いられるモデルのハイパーパラメータ（例えば、正規化／ペナルティ項）。最適なハイパーパラメータは、クロス検証プロセス時におけるアウトオブサンプルデータの平均エラーが最小になるようなプロセス全体の「設定」である。このようなハイパーパラメータは、（訓練プロセスにおいて用いられないデータの適切性を決定するために）データセットのパーセンテージについて異なるモデルを訓練することにより、最適化され得る。例えば、過去２日間、３日間または４日間からのデータを分析して、２日間、３日間または４日間が最適なハイパーパラメータであるかが決定され得る。
【0112】
母集団調整サブモジュール６６４は、ハイパーパラメータの種類に応じて異なる方法で最適なハイパーパラメータを特定し得る。例えば、回帰ベースのハイパーパラメータのための最適なハイパーパラメータ（例えば、トレーリング窓サイズおよび正規化）が、時系列ｋ倍クロス検証として知られるプロセスによって特定され得る。これを行うためには、時系列の各個々を異なる連続する時間区分に区分分けし、個々の患者モデルを第１の区分について訓練し、第２の区分についての性能を評価し、第１の区分および第２の区分について訓練し、第３の区分についての性能を評価することが必要になる。このプロセスは、最終区分まで繰り返される。この最終区分のポイントにおいて、アウトオブサンプル性能が、全ユーザの時間区分全てについて平均化される。平均アウトオブサンプルエラーが最小になるハイパーパラメータが、選択される。二次患者識別ハイパーパラメータ（例えば、含められるべき類似の患者の数およびこれらの類似の患者について用いられるべき重み付けスキーム）については、これらの二次患者識別ハイパーパラメータの特定は、異なる数の類似の患者および異なる重み付けスキームをサンプリングし、その結果得られた二次患者データセットにわたって単一のモデルを訓練し、その後一次患者データについて（定義上は二次患者データのアウトオブサンプルである）モデル性能を評価することにより行われ得る。これは、各患者について繰り返され、母集団全体にわたって平均エラーが最小になるハイパーパラメータが選択される。
【0113】
訓練サブモジュール６６２は、回帰分析を重み付けされた訓練モジュール６５８からの（重み付けされた）訓練データに対して行って、一次患者について変数係数６６６を生成する。訓練サブモジュール６６２は、累積期間にわたる各患者に対する環境変数の影響を分離させるように、個々の患者リスク、季節性および時間を制御する。
【0114】
母集団調整サブモジュール６６４は、訓練サブモジュール６６２よりも有意に小さなケーデンス（cadence）において実行され得るため、演算リソースの節減に繋がる。例えば、訓練サブモジュール６６２は、各一次患者から収集されたデータについて３０日毎に実行され得るが、母集団調整サブモジュール６６４は、追加された新規データを取り入れたハイパーパラメータの最適化のために、患者母集団全体からのデータについて９０日毎に実行され得る。
【0115】
出力された変数係数６６６は、頻度論的統計の（frequentist）標準誤差法、ベイジアン法またはブートストラップ法に基づいた点推定または分布であり得る。例えば、５０を下回る温度の係数は、０．２の点推定または（記載の方法のうちいずれかから生成された）正規分布であり得、平均は０．３であり、標準偏差は０．１である。
【0116】
図５中の相対的ランク付けモジュール５６０からは、一次患者のパラメータそれぞれの係数の相対的ランキングが一般的患者母集団中の係数の分布に関連して出力される。図６Ｄは、相対的ランク付けモジュール５６０の構成要素を示す。相対的ランク付けモジュール５５０は、回帰モジュール５４０からの環境パラメータそれぞれの係数６７０を受容する。これらの係数はそれぞれ、時間Ｔまで変数（Ｖ）に関連する。例えば、変数は、母集団中の各患者の最初の３０日間にわたる５０を下回る温度の係数であり得る。ランク付けサブモジュール６７２は、回帰モジュール５４０によって計算された各係数の点推定または分布をとり、係数値を患者の例示的変数Ｖについての履歴母集団の残り部分に相対するパーセンタイル６７４として時間Ｔまでランク付けする。係数データベース６７６からは、患者母集団全体の対応する係数値分布がランク付けサブモジュール６７２へ供給される。次に、ランク付けサブモジュール６７２によって決定されたパーセンタイルまたはパーセンタイル範囲６７４が、閾値サブモジュール６７８内へ送られる。閾値値は、臨床的および製品関連性に応じて異なり得る。閾値サブモジュール６７８は、一次患者の係数と、例示的変数Ｖについての患者母集団全体の係数分布の閾値との間の時間Ｔまでの比較に基づいて、ラベル出力６８０を異なるラベルオプション（例を非限定的に挙げると、「平均を上回らない」、「平均を上回る」、または「平均を有意に上回る」）から生成する。もちろん、他の記述的ラベル（例えば、低い、適正、および高い）が用いられ得る。本例においては３層の記述的ラベルを用いているが、本例において、より多数またはより少数の層の記述的ラベルおよび対応する範囲が用いられ得る。
【0117】
コンテンツ供給モジュール５７０は、例えば図３Ａに示すように、出力ラベル６８０を患者によるアクセスが可能なアプリケーションへ相対的ランク付けモジュール５６０から提供する。ラベルは、患者に対して患者の相対感度を通知するコンテンツと、個人用コンテンツ（例えば、患者が感度値分布の上方パーセンタイル内に入る条件についての進行中の追跡および警告）とをアプリケーション全体において生成するために用いられ得る。
【0118】
コンテンツ供給モジュール５７０は、現在の累積期間からの変数ラベルと、前回のより短い期間との比較も行い得、これにより、相対感度変化を特定する。感度ラベルが変化した際、他のコンテンツも提供され得る。
【0119】
一次患者についての関連トリガ条件またはイベント全てを反映する全体的リスク値の特徴付けにおいてラベルを採用し得るラベルデータ６８０も、予測調節モジュール５８０へ出力される。相対感度ラベルは、一次患者についての個別化された予測の調節に用いられ得る。例えば、患者が高パーセンタイルの感度を有する条件が予測される場合、個別化された予測により、個別化された予測出力の悪化と、「適正」という用語とが表示され得る。例えば、温度に対する感度について一次患者が患者母集団分布においてより高いパーセンタイル内にある場合、より保守的かつより高リスクを示す用語である「適正」が、一次患者について図３Ａ中のアプリケーションインターフェース上への表示として（「良い」という用語が一般的に用いられる場合であっても）選択され得る。さらに、患者の平均感度が有意に高い条件が予測される場合、個別化された予測により、「悪い」というラベルが（潜在的リスクスコアが０～１であるのと関係無く）表示され得る。このようにして、患者は、呼吸イベントまたは疾患のリスクの程度を非統計的文脈において理解し得る。
【0120】
一般的患者母集団についての一次患者の係数と係数値分布との比較を用いて、図３Ａ～図３Ｂ中のアプリケーションの異なる機能が調節され得る。例えば、新規トリガが発見された旨の警告が、患者に対して生成され得る。例えば、このような警告は、ほとんどの患者に対しては生成されないが、上記ルーチンにより、一次患者が特定のパラメータに対して高い罹病性を有する旨が決定され得、これにより、一次患者に対して上記警告が生成される。
【0121】
患者がトリガに対して高感度である旨がデータ分析モジュール１３１によって決定された後、通知が生成され得る。この通知は、ラベル付けされたトリガのリストと、未だ分析されているトリガのリストと、トリガを特徴付けている情報と、相対的リスクスコアと、一般的患者母集団についてのトリガ発生に関連した当該トリガの比較と、トリガが存在する際に別の救助利用イベントの発生を回避するために患者がとり得るオプションとを含み得る。この通知は、上記したようなダッシュボード３００を通じてクライアントデバイス１１０へ送達されるカードの形態をとり得る。この通知は、他のデバイス（例えば、ヘルスケアプロバイダのクライアントデバイス１１０）にも提供され得る。
【0122】
図７に示すインターフェース７００は、予測調節モジュール６２２によって決定されたように一次患者に合わせて個別調整されたラベルに基づく変数を示す。インターフェース７００は、一次患者によって操作されるモバイルデバイス上のアプリケーションによって生成され得る。インターフェース７００は、当該日の関連文脈パラメータ値に基づいた呼吸状態評価７１０のトリガについての全般的可能性を含む。上記したように、全般的可能性は、一次患者の喘息などの呼吸器疾患のリスク要素に対応するラベルとして表示される。
【0123】
加えて、インターフェース７００は、一次患者について予測よりも高い係数に基づいて選択された特定の文脈パラメータを含む。本例において、空気質、温度、湿度、２．５マイクロメータ以下の粒子状物質（ＰＭ）およびオゾン（Ｏ３）の文脈パラメータが一次患者について高リスクパラメータとして分析されている。よって、ディスプレイ７００は、空気質フィールド７２０、温度フィールド７２２、湿度フィールド７２４、ＰＭ２．５フィールド７２６およびオゾンフィールド７２８を含む。これらのフィールド（例えば、空気質フィールド７２０）はそれぞれ、パラメータ（例えば、空気質）の記述７３０と、数値７３２と、数値の相対量を示すグラフ７３４と、記述的ラベル７３６とを含む。これらのフィールド７２０～７２８は、一次患者についての高パーセンタイルの患者係数と上記したような係数母集団の分布との比較に基づいて選択される。
【0124】
係数値の分布は、使用度データを収集するデバイスを使用している呼吸器疾患の可能性のある患者の全体的母集団から決定され、回帰分析のためのデータ収集において類似の期間を有する。上記したように、第１のＴ日後、回帰が実行され、係数が生成される。各係数と、母集団において少なくともＴ日目に到達した患者全員とが比較されるが、この係数分布は、Ｔ日目までこれらの患者全員のデータについての回帰から生成されるだけである。そのため、比較用の患者母集団がデバイスを一次患者よりも有意に長時間使用している場合であっても、比較は、一次患者と全く同期間のみにおいて行われる。
【0125】
しかし、一般的患者母集団は、上記手順においてより小さなサブセットまで狭範囲化され得る。例えば、一般的患者母集団は、全患者の全体母集団を要素（例えば、使用される薬剤、初期の疾患重篤度、または特定の呼吸器疾病を経験している患者のみ）によってフィルタリングすることによって決定され得る。例えば、呼吸障害の初期の疾患重篤度は、喘息対照試験（ＡＣＴ）スコアまたはＣＯＰＤ評価（ＣＡＴ）スコア）によって測定され得る。一般的母集団の狭範囲化は、特定の環境条件についての係数が０である患者全員を排除するように行ってもよいし、あるいは、期間Ｔ内において当該環境条件を経験したことが無い患者を特定する他の任意のインジケータを用いて行ってもよい。
【0126】
図８中のフロー図は、一般的母集団に関連して一次患者データに基づいてイベントをラベル付けするためにデータを収集分析せよとの例示的機械可読命令を示す。本例において、機械可読命令は、以下によって実行されるアルゴリズムを含む：（ａ）プロセッサ；（ｂ）コントローラ；および／または（ｃ）１つ以上の他の適切な処理デバイス（単数または複数）。アルゴリズムは、有形媒体（例えば、フラッシュメモリ、ＣＤ－ＲＯＭ、フロッピー（登録商標）ディスク、ハードドライブ、デジタルビデオ（バーサタイル）ディスク（ＤＶＤ）または他のメモリデバイス）上に保存されたソフトウェア中に埋設され得る。しかし、当業者であれば、アルゴリズム全体および／またはその一部を、プロセッサ以外のデバイスによって実行しかつ／またはファームウェアまたは専用ハードウェア中に周知の様態で埋設してもよい（例えば、これは、特定用途向け集積回路［ＡＳＩＣ］、プログラマブル論理デバイス［ＰＬＤ］、フィールドプログラマブル論理デバイス［ＦＰＬＤ］、フィールドプログラマブルゲートアレイ［ＦＰＧＡ］、個別論理によって実行され得る）ことを理解する。例えば、インターフェースの構成要素のうちいずれかまたは全てを、ソフトウェア、ハードウェアおよび／またはファームウェアによって実行することができる。また、フローチャートによって示される機械可読命令のうちいくつかまたは全てを手動で実行してもよい。さらに、例示的なアルゴリズムについて図８中に示すフローチャートを参照して述べているが、当業者であれば、例示的な機械可読命令を実行するための他の多数の方法も用いられ得ることを容易に理解する。例えば、ブロックを実行する順序を変更しかつおよび／または記載のブロックのうちいくつかを変更、除去または組み合わせてもよい。
【0127】
図８中のルーチンは、データ分析モジュール１３１によって実行される。データ分析モジュール１３１は、患者母集団中の全患者に関連する文脈データを収集する（８００）。データ分析モジュール１３１は、薬剤分配デバイス（例えば、吸入器（８０２））を用いた決定に基づいて起動データも収集する。ルーチンは、一次患者についての更新期間に到達したかを決定する（８０４）。本例において、一次患者の回帰分析期間は、収集データについて３０日毎である。一次患者について期間が到達している場合、収集されたデータ全てについて回帰分析を行って、一次患者の係数をトリガイベントに関連して更新する（８０６）。回帰分析は、上記したような最適なＫ値に基づいた一次患者に類似する二次患者を含み得る。
【0128】
一次患者の係数の入手後、一次患者の係数を、患者母集団全体についての係数分布と比較する（８０８）。次に、ルーチンにおいて、一次患者についての全体的リスク要素が決定される（８１０）。次に、ルーチンにおいて、一次患者のリスク要素に基づいてラベルを選択し、患者母集団の係数分布との比較に基づいてラベル選択を調節する（８１２）。ルーチンにおいて、一次患者が一般的母集団の係数分布と比較して高パーセンタイル内にある係数に関連して表示されるパラメータも選択される（８１４）。
【0129】
図１のシステムにおける常時監視は、喘息、ＣＯＰＤ、嚢胞性線維症、気管支拡張症など様々な呼吸障害に用いられ得る。ただし、上記の原則は、かかる用途に限定されないものと理解すべきである。
【0130】
本出願で使用される「構成要素」、「モジュール」、「システム」などの用語は、ハードウェア（例えば、回路）、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または１つ以上の具体的な機能を有する動作機械に関するエンティティのいずれかであるコンピュータ関連エンティティを概して指す。例えば、構成要素は、プロセッサ（例えば、デジタル信号プロセッサ）上で実行される処理、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであり得るが、これらに限定されない。例示目的のため、コントローラ上において実行されるアプリケーションおよびコントローラのどちらも、構成要素であり得る。１つ以上の構成要素が、プロセスおよび／またはスレッド実行中に常駐し得、１つの構成要素が、１つのコンピュータ上に局所配置されかつ／または２つ以上のコンピュータ間に分散され得る。さらに、「デバイス」は、特別に設計されたハードウェア、具体的な機能の実行を可能にするソフトウェアの実行によって特殊化された被汎用化ハードウェア、コンピュータ可読媒体に記憶されたソフトウェア、またはこれらの組み合わせの形態をとることができる。
【0131】
以下の請求項１～４０のうちいずれかの一項以上からの１つ以上の要素または態様またはステップあるいはその一部（単数または複数）をその他の請求項１～４０のいずれかの１つ以上あるいはその組み合わせからの１つ以上の要素または態様またはステップあるいはその一部（単数または複数）と組み合わせることにより、本開示の１つ以上のさらなる実装形態および／または請求項を形成することができ得る。
【0132】
本開示について１つ以上の特定の実施形態または実装形態を参照して説明してきたが、当業者であれば、本開示の意図および範囲から逸脱すること無く多数の変更が可能であり得ることを認識する。これらの実装形態およびその明確な変更例はそれぞれ、本開示の意図および範囲に収まるものとして企図される。本開示の態様に従ったさらなる実装形態において、本明細書中に記載の実装形態のいずれかからの任意の数の特徴が組み合わされ得ることも企図される。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6A】
【図6B】
【図6C】
【図6D】
【図7】
【図8】
【国際調査報告】