特許 7422662 患者呼吸器疾患データとのインタラクションのための動的グラフィカルユーザインターフェース

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-01-18

(45)【発行日】2024-01-26

(54)【発明の名称】患者呼吸器疾患データとのインタラクションのための動的グラフィカルユーザインターフェース

(51)【国際特許分類】

   G16H 20/10 20180101AFI20240119BHJP

   A61M 15/00 20060101ALI20240119BHJP

   G06F 3/0481 20220101ALI20240119BHJP

【ＦＩ】

G16H20/10

A61M15/00 Z

G06F3/0481

【請求項の数】 20

(21)【出願番号】P 2020533779

(86)(22)【出願日】2018-12-11

(65)【公表番号】

(43)【公表日】2021-02-25

(86)【国際出願番号】 US2018064979

(87)【国際公開番号】W WO2019125827

(87)【国際公開日】2019-06-27

【審査請求日】2021-12-06

(31)【優先権主張番号】15/847,382

(32)【優先日】2017-12-19

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】520119552

【氏名又は名称】リシプロカル・ラボズ・コーポレイション（ディービーエー・プロペラ・ヘルス）

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】メレディス・エー・バレット

(72)【発明者】

【氏名】マイク・ローマイヤー

(72)【発明者】

【氏名】シャノン・エム・ハミルトン

(72)【発明者】

【氏名】マイケル・ジェイ・タフリ

(72)【発明者】

【氏名】ドミトリー・ストゥパコフ

(72)【発明者】

【氏名】クリストファー・ホッグ

(72)【発明者】

【氏名】ジョン・デイビッド・ヴァン・シックル

【審査官】今井 悠太

(56)【参考文献】

【文献】特開２００５－２５８８５４（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０１０９４９３（ＵＳ，Ａ１）

【文献】国際公開第２０１４／０９７４６６（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１６Ｈ １０／００－８０／００

Ａ６１Ｍ １５／００

Ｇ０６Ｆ ３／０４８１

(57)【特許請求の範囲】

【請求項1】

ヘルスケア提供者に関連付けられたコンピューティングデバイスの少なくとも１つのプロセッサが、前記ヘルスケア提供者に関連付けられた前記コンピューティングデバイスのディスプレイ上に患者情報を表示するための方法であって、
複数の患者タイプを識別する第1のグラフィカル要素を前記ヘルスケア提供者に表示するステップであって、前記複数の患者タイプの各々は、異なる疾患およびその疾患を有する1人または複数の患者に関連付けられる、ステップと、
前記患者タイプのうちの喘息患者タイプを選択することに応答して、前記第1のグラフィカル要素と同時に第2のグラフィカル要素を表示するステップであって、前記第2のグラフィカル要素は、喘息をもつ一人または複数の患者に対する患者喘息監視情報を含む、ステップとを含み、
前記患者喘息監視情報は、
時間ウィンドウにわたる前記一人または複数の患者の各患者についてのレスキュー吸入器使用の報告であって、前記レスキュー吸入器使用の報告は、前記レスキュー吸入器使用の報告の各レスキュー吸入器使用イベントが生じた地理的位置の前記患者に関連付けられた前記レスキュー吸入器のアクティブ化を監視するために、レスキュー吸入器に取り付けられた第1のセンサーによってリモートサーバへ報告され、前記第1のセンサーは、各レスキュー吸入器使用イベントが生じた前記地理的位置を記録し、前記リモートサーバは、前記第1のセンサーに一意のデバイス識別子に基づいて前記レスキュー吸入器使用イベントの報告を認識する、前記レスキュー吸入器使用の報告と、
時間ウィンドウにわたる前記一人または複数の患者の各患者についてのコントローラ吸入器使用の報告であって、前記コントローラ吸入器使用の前記報告は、前記コントローラ吸入器使用の前記報告の各コントローラ吸入器使用イベントが生じた地理的位置の前記患者に関連付けられた前記コントローラ吸入器のアクティブ化を監視するために、コントローラ吸入器に取り付けられた第2のセンサーによって前記リモートサーバへ報告され、前記第2のセンサーは、各コントローラ吸入器使用イベントが生じた前記地理的位置を記録し、前記リモートサーバは、前記第2のセンサーに一意のデバイス識別子に基づいて前記コントローラ吸入器使用イベントの報告を認識する、前記コントローラ吸入器使用の前記報告と、
を含み、
喘息をもつ前記一人または複数の患者のうちの各患者に対する患者喘息監視情報を選択する前記第2のグラフィカル要素への入力を受け取るステップと、
前記入力を受け取ったことに応答して、前記第2のグラフィカル要素と第3のグラフィカル要素を少なくとも部分的に重ね合わせるステップとをさらに含み、前記第3のグラフィカル要素は、前記選択された患者に関連付けられたレスキュー吸入器に取り付けられた第1のセンサーによって報告されるレスキュー吸入器使用イベントの履歴、および前記選択された患者に関連付けられたコントローラ吸入器に取り付けられた第2のセンサーによって報告されるコントローラ吸入器使用イベントの履歴を視覚的に示す、
方法。

【請求項2】

前記喘息患者タイプは、ユーザ入力によって選択され、前記ユーザ入力は、以下のこと、すなわち、
前記患者タイプを表すグラフィカル要素の上でホバリングすること、
前記患者タイプを表すグラフィカル要素をホールドすること、または
前記患者タイプを表すグラフィカル要素を1回もしくは複数回タッチすることのうちの、1つまたは複数を含む、
請求項1に記載の方法。

【請求項3】

前記第1のグラフィカル要素は、前記ヘルスケア提供者が治療を行う複数の患者の、各患者タイプを識別し、前記複数の患者タイプは、
慢性閉塞性肺疾患(COPD)患者タイプ、および
センサー非アクティブ患者タイプをさらに含む、
請求項1に記載の方法。

【請求項4】

前記COPD患者タイプの選択に応答して、代替の第2のグラフィカル要素が表示され、前記代替の第2のグラフィカル要素は、COPDをもつ一人または複数の患者に対する患者COPD監視情報を含み、前記患者COPD監視情報は、
前記COPDをもつ一人または複数の患者の各患者について、
ある時間ウィンドウにわたって報告されたレスキュー吸入器使用イベントの回数をレスキュー吸入器使用イベントのしきい値の回数と比較することによって決定されるレスキューベースライン評価、
前記時間ウィンドウにわたるレスキュー吸入器使用の報告、および
前記時間ウィンドウにわたるコントローラ吸入器使用の報告を含む、
請求項3に記載の方法。

【請求項5】

前記COPD患者タイプの選択に応答して、代替の第2のグラフィカル要素が表示され、前記代替の第2のグラフィカル要素は、COPDをもつ一人または複数の患者に対する患者COPD監視情報を含み、前記患者COPD監視情報は、
前記COPDをもつ一人または複数の患者の各患者について、
前記患者に関連付けられたレスキュー吸入器に結合された第1のセンサーと関連付けられた第1のコンピューティングデバイスの直近の同期を示す記録、および
前記患者に関連付けられたコントローラ吸入器に結合された第2のセンサーと関連付けられた第2のコンピューティングデバイスの直近の同期を示す記録を含む、
請求項3に記載の方法。

【請求項6】

前記センサー非アクティブ患者タイプの選択に応答して、代替の第2のグラフィカル要素が表示され、前記センサー非アクティブ患者タイプは、非アクティブセンサーに関連付けられた一人または複数の患者に対する監視情報を含み、前記監視情報は、
非アクティブセンサーに関連付けられた前記一人または複数の患者の各患者について、
前記患者に関連付けられた第1のコンピューティングデバイスが前記患者に関連付けられたレスキュー吸入器と最後に同期されてからの時間期間、および
前記患者に関連付けられた第2のコンピューティングデバイスがコントローラ吸入器と最後に同期されてからの時間期間を含む
請求項3に記載の方法。

【請求項7】

前記センサー非アクティブ患者タイプの選択に応答して、代替の第2のグラフィカル要素が表示され、前記センサー非アクティブ患者タイプは、非アクティブに関連付けられた一人または複数の患者に対する監視情報を含み、
非アクティブに関連付けられた前記一人または複数の患者の各患者について、
レスキュー吸入器使用イベントの記録からの時間期間が第1のしきい値時間期間を超過することの記録、および
コントローラ吸入器使用イベントの記録からの時間期間が第2のしきい値時間期間を超過することの記録を含む、
請求項3に記載の方法。

【請求項8】

前記第2のグラフィカル要素は、前記リモートサーバにおいて決定される喘息コントロールスコアをさらに含み、前記喘息コントロールスコアは、前記レスキュー吸入器のアクティブ化を監視するために前記レスキュー吸入器に取り付けられた前記第1のセンサーによって報告されるレスキュー吸入器使用データ、および前記コントローラ吸入器のアクティブ化を監視するために前記コントローラ吸入器に取り付けられた前記第2のセンサーによって報告されるコントローラ吸入器使用データに基づく、請求項1に記載の方法。

【請求項9】

前記第2のグラフィカル要素は、前記レスキュー吸入器に取り付けられた前記第1のセンサーとの第1のコンピューティングデバイスの直近の同期を示す記録をさらに含む、請求項1に記載の方法。

【請求項10】

前記第2のグラフィカル要素は、前記コントローラ吸入器に取り付けられた前記第2のセンサーと第2のコンピューティングデバイスの直近の同期を示す記録をさらに含む、請求項1に記載の方法。

【請求項11】

前記第2のグラフィカル要素は、前記一人または複数の患者の各患者と前記ヘルスケア提供者との間の直近の連絡を示す記録をさらに含む、請求項1に記載の方法。

【請求項12】

レスキュー吸入器使用の前記報告は、日ごとに前記時間ウィンドウにわたって表され、前記時間ウィンドウ中の各日は、その日に検出されたレスキュー吸入器使用イベントの回数を示す、請求項1に記載の方法。

【請求項13】

コントローラ吸入器使用の前記報告は、前記一人または複数の患者の各患者についての充填可能グラフィカルインジケータとして表され、前記充填可能グラフィカルインジケータは、前記時間ウィンドウにわたる前記患者のアドヒアランス格付けの尺度に基づいて決定される統計値を表示する、請求項1に記載の方法。

【請求項14】

レスキュー吸入器使用イベントの前記履歴、およびコントローラ吸入器使用イベントの前記履歴は、前記第3のグラフィカル要素内で同時に表示される、請求項1に記載の方法。

【請求項15】

前記第3のグラフィカル要素は、
前記時間ウィンドウを調整するためのスライドグラフィカルインジケータをさらに含み、前記時間ウィンドウを調整することは、前記第3のグラフィカル要素の中に表示されるレスキュー吸入器使用イベントの数およびコントローラ吸入器使用イベントの数を変更する、
請求項1に記載の方法。

【請求項16】

前記時間ウィンドウを調整するステップは、
一定の時間の前に報告されたイベントを含むように前記時間ウィンドウを拡大するステップ、または
一定の時間の後に報告されたイベントまで前記時間ウィンドウを縮小するステップを含む、
請求項15に記載の方法。

【請求項17】

レスキュー薬剤使用の前記履歴およびコントローラ薬剤使用の前記履歴は、ヒストグラムのシーケンスとして表示され、前記ヒストグラムのシーケンスの各ヒストグラムは、前記時間ウィンドウ中の１日の間に報告されたイベントの回数を表す、請求項1に記載の方法。

【請求項18】

前記第3のグラフィカル要素への入力を受け取るステップであって、前記入力は、
報告済みレスキュー吸入器使用イベントを伴う単一の日、または
報告済みコントローラ吸入器使用イベントを伴う単一の日
を選択する、ステップと、
前記第3のグラフィカル要素への前記入力の受取りに応答して、前記第3のグラフィカル要素上に第4のグラフィカル要素を少なくとも部分的に重ね合わせるステップであって、前記第4のグラフィカル要素は、前記選択された単一の日に関する追加情報を視覚的に示す、ステップと
をさらに含む、請求項1に記載の方法。

【請求項19】

前記入力は、報告されたレスキュー吸入器使用イベントがある単一の日を選択し、前記追加情報は、
前記報告されたレスキュー吸入器使用イベントの日付、
前記報告されたレスキュー吸入器使用イベント中に投与されたレスキュー薬剤、
前記報告されたレスキュー吸入器使用イベントの時間、および
前記投与されたレスキュー薬剤の投与量を含む、
請求項18に記載の方法。

【請求項20】

前記入力は、報告されたコントローラ吸入器使用イベントがある単一の日を選択し、前記追加情報は、
前記コントローラ吸入器使用イベントが報告された週、
前記報告されたコントローラ吸入器使用イベントの間に投与されたコントローラ薬剤、
推奨されるコントローラ薬剤分量の日ごとの記録、および
前記選択された患者によって行われたコントローラ薬剤分量の日ごとの記録を含む、
請求項18に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般に、コンピューティングデバイス上での表示用のグラフィカルユーザインターフェースに関し、より詳細には、ヘルスケア提供者が患者データを見るためのグラフィカルユーザインターフェースに関する。

【背景技術】

【0002】

吸入器などの薬剤デバイスは、狭窄された空気流などの呼吸症状を患者が管理することを可能とする。喘息、慢性閉塞性肺疾患(COPD:chronic obstructive pulmonary disorder)、および嚢胞性線維症の病人などの、多くの呼吸器疾患患者は、大気質、天候、土地利用などの環境的な誘因および要因に関係する症状を有する。特定の患者または患者のグループは、複数の誘因および要因への敏感性を有することがある。数十、数百、またはもっと多くの誘因および要因のうちのどれに患者が敏感であるのかを知ること、ならびに症状を管理する際の使用のためにそれらの誘因および要因を監視することは、複雑な作業であり、多くの患者および提供者にとって現在のところ実現可能でない。

【0003】

さらに、各個人の呼吸器疾患は、それ自体、重大かつコストがかかる公衆衛生問題である。ほんの一例として喘息を取り上げると、世界保健機関は、喘息を有する世界的な人口が3億人であり得ると推定し、その人口が2025年までに4億人に増えると予測する。米国では、喘息は、米国の中の12人に1人の個人に影響を及ぼし、流行が上昇傾向にあり、毎年560億ドルを超える健康管理利用コストをもたらす。新たな薬物療法の開発にもかかわらず、入院および救急室来診の割合は低下していない。米国では毎年、その疾患は、ほぼ200万件の救急部門来診、50万件の入院、および5千件の死亡を引き起こす。加えて、喘息は、推定される1500万日の学校の日々および1200万日の仕事の日々が失われる原因である。米国の健康保険業者および雇用主への全年間コストは、180億ドルよりも多額である。

【0004】

これらの悪化の大部分は、現在利用可能な治療を用いて防止され得るが、5人に1人の喘息患者しか疾患をコントロールしていない。新たに改訂された国のガイドラインは、治療が毎日の症状をコントロールしており生活の質を改善しているかどうかを、より注意深く監視するように医者に勧告している。

【0005】

しかしながら、内科医は、自分の患者がその日その日にどのくらい調子よくいっているのかを評価するための、利用可能なツールをほとんど有していない。ますます多くの内科医が、患者を監視するとともにコントロールの患者のレベルを決定するために、(喘息コントロールテスト(ACT:Asthma Control Test)などの)定期的な書面によるアンケートを使用し始めている。これらの道具は、一定の時間期間(通常、2～4週間)にわたる症状の頻度、吸入器使用、ならびに活動レベルおよび活動制約を正確に思い出し報告することを患者に求める。その結果、これらのアンケートは、バイアス(想起)によって持ち込まれる誤り、症状の異なる解釈、および挙動(ノンアドヒアランス)に左右され、それらが使用される時における情報を提供するにすぎない。より一般的には、患者評価および患者監視は、すべての他の呼吸器疾患において使用される場合も困難である。

【先行技術文献】

【特許文献】

【0006】

【文献】米国特許出願第12/348,424号

【文献】国際出願第PCT/US2014/039014号

【文献】米国特許出願第15/724,968号

【発明の概要】

【課題を解決するための手段】

【0007】

呼吸器疾患分析システムは、多くの患者の呼吸器疾患を治療、監視、および管理するための、統合プラットフォームである。そのような疾患の例は、限定はしないが、喘息、COPD、および嚢胞性線維症を含む。分析システムは、自分の疾患を管理する助けとなる権限を分析システムに付与している患者によって使用される薬剤デバイス(たとえば、吸入器)に取り付けられたセンサーからイベント通知を受信することによって、呼吸器レスキューおよびコントローラ投薬イベントを追跡する。センサーは、定量吸入器または他の薬剤デバイスに取り付けられているかまたはそれらの中に組み込まれているとき、使用イベントの時間および日付を記録し、その情報を分析システムに通信する。分析システムは、受信されたイベント(直近のイベントと前に受信したイベントの両方)をリアルタイムまたはほぼリアルタイムで分析し、リスク評価、コントローラアドヒアランスリマインダ、ならびに患者および患者のヘルスケア提供者への通知の形で疾患を案内および管理するための他の情報を配信することが可能である。

【0008】

表示されるグラフィカルユーザインターフェースにより、患者およびケア提供者などのユーザが、様々な疾患および病状に苦しむ1人の人物または人々のグループの疾患管理習慣を容易に監視することが可能になる。ケア提供者によって使用されるとき、アプリケーションは、一般的な患者概要を詳述するユーザからの入力、ならびにレスキュー使用イベントのアドヒアランス習慣および記録などのより特有の患者薬剤詳細に応じて、グラフィカルユーザインターフェースの異なる表示を生成する。患者ユーザに対して、アプリケーションは、リスク分析から疾患管理提言までにわたる様々な通知を表示する。

【0009】

疾患分析システムは、書面によるアンケートに関連付けられるユーザバイアスを除去することによって、患者が監視することに関連付けられる既存の問題を軽減する。代わりに、センサーのシステムが、患者がさらされている危険の量を評価するとともに患者のレスキュー投薬習慣を測るための重要な情報を、自動的に記録および強調する。さらに、システムは、患者の日常の投薬習慣およびリスクイベントへの提供者の即時の洞察を可能にするので、提供者と患者との間の相互のやり取りは、患者がアポイントメントを予定に入れることに左右されない。

【図面の簡単な説明】

【0010】

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

【図2】一実施形態による、クライアントデバイス、アプリケーションサーバ、および/またはデータベースサーバのいずれかにおいて使用される、コンピューティングデバイスの一例を示す高レベルブロック図である。

【図3】一実施形態による、ユーザが分析システムと相互にやり取りを行うことを可能にするクライアントアプリケーションのダッシュボードを示す図である。

【図4A】一実施形態による、ケア提供者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図4B】一実施形態による、ケア提供者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図4C】一実施形態による、ケア提供者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図4D】一実施形態による、ケア提供者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図4E】一実施形態による、ケア提供者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図4F】一実施形態による、ケア提供者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図4G】一実施形態による、ケア提供者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5A】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5B】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5C】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5D】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5E】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5F】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5G】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5H】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5I】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5J】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5K】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5L】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【図5M】一実施形態による、患者に関連付けられるコンピューティングデバイスのディスプレイ上に提示されるグラフィカルユーザインターフェースのグラフィカル要素を表す図である。

【発明を実施するための形態】

【0011】

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

【0012】

I.システム環境
図1は、一実施形態による、正確かつリアルタイムな薬剤デバイスイベントを監視し、そのデータに対して分析を行い、かつグラフィカルユーザインターフェースを通じてユーザに分析を提示するための分析システム100を示す。

【0013】

分析システムは、クライアントコンピューティングデバイス110、薬剤デバイスセンサー120、薬剤デバイス160、アプリケーションサーバ130、データベースサーバ140、およびネットワーク150を含む。図1は、分析システム100の構成要素のうちの大部分の単一のインスタンスしか示さないが、実際には各構成要素の2つ以上が存在してもよく、追加的な、または、より少数の構成要素が使用されてもよい。

【0014】

I.A.クライアントデバイスおよびアプリケーション
クライアントデバイス110は、ユーザの命令を受けて、ネットワーク150を介して分析システム100と相互にやり取りを行う。説明および明確性のため、少なくとも2つの異なるタイプのユーザを識別することが有用である。患者111は、呼吸器疾患に悩まされるユーザであって、自分の疾患の管理および追跡についての情報をサーバ130から取得するために、少なくとも部分的に分析システム100を利用するユーザである。概して、この情報交換を可能にするために、ユーザは、患者111の薬剤デバイス160の使用を監視するための許可を分析システム100に与える。以下説明するように、薬剤デバイス160およびユーザのクライアントデバイス110に関連付けられたセンサー120によって、投薬イベントが検出され、ユーザのクライアントデバイス110は、アプリケーションサーバ130に報告し、アプリケーションサーバ130は、患者に情報を戻して提供することができる。1つの例示的なプロセスでは、サーバ130は、関連付けられたクライアントデバイス110を通じて患者に提供される通知を生成する。

【0015】

別のタイプのユーザはヘルスケア提供者112であり、ヘルスケア提供者112は、やはり患者111の明示的な許可とともに、自分の患者の呼吸器疾患管理に関する情報も受け取る。この情報は、個々の患者データとセンサー120によって報告される集約された薬剤使用イベントデータの両方、ならびに外部データ、およびこれらの異なるタイプのデータの任意の組合せに関する導出された統計値を含みうる。しばしば、提供者112は、数人の患者111の1次医療内科医であり、および/または、患者111に対する専門の内科医である。患者111の親/保護者などの他のタイプのユーザも考えられ、そうした親/保護者は、自分自身のクライアントデバイス110が自分の子供のクライアントデバイスとは異なる場合にも、やはり情報を報告することを望むことがある。

【0016】

クライアントデバイス110はコンピュータシステムである。例示的な物理実装形態について、以下、図2を参照して、より完全に説明する。クライアントデバイス110は、ネットワーク150を介して分析システム100とワイヤレス通信するよう構成される。ネットワーク150アクセスを用いて、クライアントデバイス110は、ユーザの地理的位置および投薬イベントの時間、ならびに関連付けられた薬剤デバイスセンサー120(全体にわたって「センサー120」と呼ぶ)から受信されるようなイベントを記述する情報を、システム100へ送信する。

【0017】

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

【0018】

アプリケーションサーバ130と通信することに加え、分析システム100にワイヤレス接続されたクライアントデバイス110はまた、他の接続済みのクライアントデバイス110と情報を交換し得る。たとえば、クライアントソフトウェアアプリケーション115を通じて、ヘルスケア提供者112には、1人または複数の患者111の疾患状態についての情報を提供するグラフィカルユーザインターフェースが提供され得る。ヘルスケア提供者112は、その情報に反応し、治療、または疾患管理を改善するための挙動の調整のために、アプリケーション115を使用して患者111に推奨を送りうる。同様に、アプリケーション115を通じて、患者111は、自分のヘルスケア提供者112、および許可に応じて他の患者111と通信しうる。

【0019】

アプリケーション115は、クライアントデバイス110のスクリーン上に表示され、かつユーザがアプリケーション115の動作を制御するためにコマンドを入力することを可能にする、ユーザインターフェース(本明細書では「ダッシュボード」と呼ぶ)を提供する。ダッシュボードは、ヘルスケア提供者112および患者111がそれによって分析システム100にアクセスするメカニズムである。たとえば、ダッシュボードにより、患者111および提供者112が、互いにやり取りを行うこと、通知を見ること、治療および治療計画についてのメッセージを交換すること、イベントデータおよびすべての他の非イベントデータを提供するとともに受け取ることなどが可能になる。アプリケーション115は、インターネットブラウザ内でレンダリングするための、ウェブページ、一連のウェブページ、または別の方法でコーディングされたコンテンツとしてコーディングされてよい。アプリケーション115はまた、クライアントデバイス110のネイティブなオペレーティングシステム上で動作するように構成されたプロプライエタリなアプリケーションとしてコーディングされうる。例示的なダッシュボードは、以下、図3を参照して、より完全に説明される。ヘルスケア提供者特有のダッシュボードの実施形態は、以下、図4を参照して説明される。

【0020】

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

【0021】

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

【0022】

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

【0023】

I.B.薬剤デバイスおよびセンサー
薬剤デバイス160は、狭窄された呼吸空気流を経験しているユーザの肺に薬剤を送達するために使用される医療デバイスである。薬剤デバイス(たとえば、吸入器)は、通常、呼吸発作を治療するときのアクセシビリティを簡単にするために、手で運ばれるのに十分ポータブルかつ小型である。一実施形態では、薬剤は、定量吸入器などの薬剤デバイス160を通じてエアロゾル形態で送達される。定量吸入器は、エアロゾル薬剤の加圧式推進用キャニスター、統制された薬剤投与量を送達するための計量バルブ、および加圧式キャニスターを保持するとともに薬剤の送達用のマウスピースも形成するプラスチックホルダーを含む。別の実施形態では、薬剤は、乾燥粉末吸入器などの薬剤デバイス160を通じて乾燥粉末形態で送達される。乾燥粉末吸入器は、ユーザがストリップ状の乾燥粉末薬剤を通過して割り出しすることを可能にする車輪と歯車との機構を収容する、カルテシアン胚珠型(Cartesian ovular shaped)の本体を有してよい。乾燥粉末吸入器の本体はまた、乾燥粉末をユーザに送達するためのマニホルドおよびマウスピースを含む。コントローラ薬剤デバイス160によって投与されるコントローラ薬剤の例は、ベクロメタゾン(beclomethasone)、ブデソニド(budesonide)、およびフルチカゾン(fluticasone)、ならびにサルメテロール(salmeterol)またはホルモテロール(formoterol)などの長時間作用型の気管支拡張薬とのそれらの薬剤の組合せを含む。レスキュー薬剤デバイス160によって投与されるレスキュー薬剤の例は、アルブテロール(albuterol)、サルブタモール(salbutamol)、レブアルブテロール(levalbuterol)、メタプロテレノール(metaproterenol)、およびテルブタリン(terbutaline)を含む。

【0024】

各患者111は、2つ以上の薬剤デバイス160に関連付けられうる。たとえば、患者111は、レスキュー薬剤を投与するレスキュー薬剤デバイス160、およびコントローラ薬剤を投与するコントローラ薬剤デバイス160を有してよい。同様に、各患者は、各々が患者の薬剤デバイス160のうちの1つとともに動作するように選ばれた、2つ以上のセンサー120に関連付けられうる。

【0025】

一般に、センサー120は、薬剤ディスペンサ160の使用を監視する物理デバイスである。センサー120は、薬剤ディスペンサの動作を妨げることなく着脱自在に薬剤ディスペンサに取り付け可能であるか、またはセンサー120は、その製造業者によって利用可能にされるような薬剤ディスペンサ160のネイティブな部分である統合された構成要素であるかのいずれかである。

【0026】

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

【0027】

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

【0028】

上記で紹介したように、センサー120は、薬剤デバイス160の使用についてのデータを獲得する。詳細には、各センサー120は、投薬イベントの時間および地理的位置、すなわち、患者111によるレスキュー薬剤デバイス160の使用を獲得する。各センサー120は、患者111またはヘルスケア提供者112からの入力を伴わずに自動的に、リアルタイムで、またはネットワーク接続が達成されるとすぐに、イベントデータを送信する。分析における使用、ヘルスケア提供者へのダッシュボードの提示、通知の生成、および他の目的のために、投薬イベント情報がアプリケーションサーバ130に送られる。

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

アプリケーションサーバ130は、ネットワーク150を通じて多くの異なるクライアントデバイス110によってアクセスをサポートするとともに分析システム100を使用するためのソフトウェアアーキテクチャを含み、したがって、高レベルでは、一般に、クラウドベースシステムとして特徴づけることができる。アプリケーションサーバ130は、一般に、患者111およびヘルスケア提供者112が、レスキュー投薬イベントとコントローラ投薬イベントの両方を含む、患者111の薬剤デバイス160に関連付けられたセンサーによって記録されたデータを報告し、喘息治療計画において協力し、患者111の条件および地理的位置に関する情報を閲覧および取得し、かつ様々な他の機能を利用するための、プラットフォームを提供する。

【0034】

一般に、アプリケーションサーバ130は、多種多様なデータを処理するように設計される。アプリケーションサーバ130は、入ってくるデータの有効性をチェックすること、必要な場合にデータを構文解析およびフォーマットすること、処理済みのデータを記憶のためにデータベースサーバ140に渡すこと、ならびにデータベースサーバ140が更新されているのを確認することを含む、様々な機能を実行する論理ルーチンを含む。

【0035】

アプリケーションサーバ130は、少なくとも部分的には患者ごとに、データを記憶および管理する。この目的に向けて、アプリケーションサーバ130は、ユーザごとに患者プロファイルを作成する。患者プロファイルとは、分析システム100の患者111を特徴づける1組のデータである。患者プロファイルは、年齢、性別、疾患タイプ、アカウント作成日、プロキシデバイス、現在のレスキュー薬剤、現在のコントローラ薬剤、通知選好、コントローラ投薬アドヒアランス計画、患者関連の医療履歴、および患者プロファイルにアクセスする権限が付与された、患者でないユーザのリストなどの、患者についての識別情報を含みうる。プロファイルは、患者のための(コントローラ投薬イベントおよびレスキュー投薬イベントなどの)データをサブミットする権限が付与された1つまたは複数のクライアントデバイス110またはセンサー120を識別する、一意のメディアアクセス制御(MAC)アドレスなどのデバイス識別子をさらに指定してよい。

【0036】

プロファイルは、異なるどのタイプの通知が患者111および患者111の個人用ヘルスケア提供者112に提供されるのか、ならびに通知が提供される頻度を、指定しうる。たとえば、患者111は、レスキューイベントを示す通知を受け取る権限をヘルスケア提供者112に付与しうる。患者111はまた、それらの患者プロファイルおよびレスキューイベント履歴へのアクセスが与えられる権限を自分のヘルスケア提供者112に付与しうる。患者111の患者プロファイルへのアクセスがヘルスケア提供者112に提供される場合、ヘルスケア提供者は、コントローラアドヒアランスまたはレスキュー投薬計画を指定し得る。投薬計画は、コントローラ薬剤に対する日ごとの規定された数の分量を含みうる。

【0037】

アプリケーションサーバ130はまた、ヘルスケア提供者112に対するプロファイルを作成する。ヘルスケア提供者プロファイルは、オフィスの場所、資格、および証明などの、ヘルスケア提供者112についての識別情報を含みうる。ヘルスケア提供者プロファイルはまた、ヘルスケア提供者の患者集団についての情報を含む。提供者プロファイルは、その提供者の患者のプロファイルのすべてへのアクセス、ならびに集約人口統計学的情報、レスキュー投薬イベントパターン、およびコントローラ投薬イベントパターンなどの、それらのプロファイルからの導出されたデータを含みうる。このデータは、時間期間単位(たとえば、週単位、月単位、年単位)にわたって地理的エリア単位(たとえば、近所、町)などで、患者プロファイルの中に記憶された任意のタイプのデータに従ってさらに細分されうる。

【0038】

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

【0039】

多くのタイプの分析が可能である。例は、喘息、COPD、または他の呼吸器疾患リスク分析を含み、ここで、リスクとは、たとえば、将来の発作または危険にさらす他のイベントのリスクであり得る。別の例として、個人の、地理的な、臨床的な、疫学的な、人口統計学的な、または空間的もしくは時間的な、ベースライン、あるいは予測または予期される値からの履歴的に有意な並べ替えに基づく、薬剤使用の空間クラスタ/時間クラスタ(すなわち、突発的な発生)に基づいて、複数の患者が識別すべきレスキュー投薬イベントデータおよびコントローラ投薬イベントデータを使用してリスク分析が実行され得る。他のタイプの分析は、日単位/週単位のアドヒアランス傾向、経時的なアドヒアランス変化、他の関連する集団(たとえば、すべての患者、特定のレスキュー薬剤もしくはコントローラ薬剤またはそれらの組合せにおける患者)とのアドヒアランス比較、(空間的、時間的、環境的)誘因の識別、経時的なレスキュー使用傾向、および他の関連する集団とのレスキュー使用比較を含みうる。

【0040】

任意の分析の実行に応答して、アプリケーションサーバ130は、患者111、権限が付与されたヘルスケア提供者112、および/または患者のプロファイルへのアクセスが提供された他のユーザへ送るべき情報を、準備および配信する。情報は、ヘルスケア提供者による使用のために設計されたユーザインターフェース(本明細書では提供者GUIと呼ぶ)などのダッシュボードの形態で、ならびにクライアントデバイス上のダッシュボードの一部として提示されるプッシュ通知の形態で、提示されてよい。通知および提供者GUIは、投薬レスキューイベントに関与するタイミング、位置、および影響を受ける患者111についての詳細を提供することができ、詳細は救急支援を要求する遭難信号または救急信号を含みうる。詳細はまた、データ分析モジュール131によって実行された分析の結果を含みうる。特に送られてよい通知のタイプおよび通知が含みうる内容に関するより多くの情報は、以下、図5A～図5Mを参照しつつさらに説明される。

【0041】

リスク分析に応答してプッシュ通知を提供することに加えて、通知はまた、特定の時間区間において、プル通知として提供されてよい。さらに、いくつかの通知は(プッシュであろうとプルであろうと)、レスキュー投薬イベントに応答して実行されるリスク分析に応答してではなく、代わりにリスク分析におけるその下にある要因のうちの1つの変化に応答して実行されるリスク分析に応答してトリガされてよく、その結果、更新済みの通知が保証される。たとえば、大気汚染の増加が発生しつつあるかまたは今にも起ころうとしていることを天候条件が示す場合、このことは、汚染が発生しつつある特定の地理的エリアに位置するすべての患者に対してリスク分析の実行をトリガし得る。

【0042】

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

【0043】

I.D.データベースサーバ
データベースサーバ140は、プロファイル、投薬イベント、および患者医療履歴(たとえば、電子医療記録)などの、患者および提供者データ関連のデータを記憶する。患者および提供者データは、医療保険の相互運用性と説明責任に関する法律(HIPAA:Health Insurance Portability and Accountability Act)のすべての要件を満たすように、セキュリティのために暗号化され、少なくともパスワード保護され、かつそれ以外でセキュアにされる。複数の患者からのデータ(たとえば、集約レスキュー投薬イベントデータ)を組み込むとともにユーザに提供されるいかなる分析(たとえば、喘息リスク分析)も、患者のプライバシーを保護するために個人識別情報が除去されるように、デアイデンティファイ(de-identify)される。

【0044】

データベースサーバ140はまた、非患者データを記憶する。このデータは、患者が物理的に位置するとともに汚染物質にさらされうる居住ゾーンまたは商業ゾーンの中の公共空間などのいくつかの地理的領域についての領域データを含む。このデータは、詳細には、緑地(密集した数の樹木および植物を含むエリア)までの患者の近接度を含んでよく、またはそれを取得するように処理されてもよい。領域データの一例は、温度、風パターン、湿度、大気汚染指数などの、ジオリファレンスされた(georeferenced)天候データを含む。別の例は、時間のインスタンスにおける、または経験的に測定された、様々な汚染物質に対する粒子のカウントを含む、ジオリファレンスされた汚染データである。領域データは、温度、湿度、大気汚染指数などの、レスキューイベントの時間および場所に対する現在の天候条件についての情報を含む。上記のデータの項目のすべては経時的に変化することがあり、したがって、データ自体は時間によってインデックスが付けられてよく、たとえば、時刻によって(分または時間によって、を含む)、または日、週、月、もしくは季節によってなどのもっと長い期間にわたって、別個のデータ点が利用可能であり得る。

【0045】

データベースサーバ140は、アプリケーションサーバ130とは別個のエンティティであるものとして図1に示されるが、データベースサーバ140は、あるいは、データベースサーバ140が1つまたは複数の永続的記憶装置として実装されるように、サーバ130などの別のサーバの一部であるハードウェア構成要素であってよく、データベースの中の記憶されたデータとインターフェースするためのソフトウェアアプリケーションレイヤは、そうした他のサーバ130の一部である。

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

III.ダッシュボード
ダッシュボード、たとえば、図3に示すダッシュボード300は、ユーザが分析システム100と相互にやり取りを行うことを可能にする。ダッシュボード300は、ユーザからユーザに(たとえば、患者111から提供者112に)、またはユーザからシステムに/システムからユーザに、情報を転送するための手段を提供する。ダッシュボード300は、クライアントデバイス110上のクライアントアプリケーション115を通じてアクセスされ、患者とヘルスケア提供者の両方が、投薬レスキューイベントを監視し、個人化された患者健康管理情報を交換し、かつ通知を受け取るためのメカニズムを提供する。一実装形態では、患者は、ダッシュボード300を通じて他のヘルスケア提供者および他の患者と通信しないことがある。代替実装形態では、たとえば、患者の疾患、薬剤使用、および疾患管理についての情報を説明および共有するために、そのような通信が可能にされる。健康管理情報を共有するための能力は、同じ問題に遭遇する患者またはヘルスケア提供者に、個々の観点を共有するための方法を与え得る。

【0054】

ダッシュボード300はまた、権限が付与されたヘルスケア提供者112が、患者データおよび地域社会データ、ならびに様々な人口統計または地理的セグメントにおける統計値についての情報を閲覧し、それに注釈を付け、それを更新し、それとインタラクションを行い、かつそれをエクスポートするために、患者のリストにアクセスすることを可能にする。ダッシュボード300を使用すると、ヘルスケア提供者は、自分たちの関連付けられた患者集団がどのように管理案内に応答しているのかについてのフィードバック(たとえば、順守リマインダ)を受け取るとともに提供するために、患者を個別にまたは集約して監視することが可能である。個々のまたは複数の患者へのアクセスを有するヘルスケア提供者は、通知しきい値を確立し、通知に対するパラメータを設定し、かつ(たとえば、患者がレスキューイベントを有することに応じて)患者のイベント履歴がいくつかの条件に整合するときに通知を受け取ることが可能である。さらに、ダッシュボード300は、分析システム100によって生成される特定の人口統計に対するイベントパターンの定期的な報告を受信および表示することができる。

【0055】

ダッシュボード300は、表データ、グラフィカル視覚化、および分析を含む様々な情報を、グラフィカルユーザインターフェースの一部を形成する様々なグラフィックディスプレイ要素310を通じてユーザに提示する。提示された情報とインタラクションを行うために、いくつかの表示要素310aは入力応答315エリアを含む。たとえば、図5Aに示す表示要素310bにおいて、患者は、喘息を管理するために使用されるコントローラ薬剤を選択するために、または「次へ」を選択して追加の表示要素310に移動するために、入力応答315エリアの中で上方スクロールまたは下方スクロールし得る。

【0056】

いくつかの事例では、これらの要素は、通常は患者に提示される情報に対する、「カード」と呼ばれる。しばしば、カードは、特にポータブルクライアントデバイス110、たとえば、モバイルフォンまたはタブレットによくある、より小型のディスプレイに好適であり、ベースボールカードの中に見出される単純化した団体称号を模した情報の「一口サイズ」の断片を含む。ダッシュボード300はまた、ユーザが様々なカテゴリーの健康管理情報を通じてナビゲートすることを可能にする、システムメニュー305を含みうる。ダッシュボード300の他の実装形態は、デスクトップコンピューティングデバイスまたはラップトップコンピューティングデバイスによくある、より大型のディスプレイ上での消費に対して特に好適であり得る。これらのダッシュボード300の中に、通常、スクリーン上で同時に視認できる複数の異なる表示要素がある。提供者UI用のこれらの様々な表示要素の提示、位置、およびインタラクションは、詳細には、以下、図4を参照して説明される。

【0057】

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

【0058】

IV.提供者側グラフィックス表示
IV.A.概要
提供者GUI/提供者ダッシュボード300は、インタラクティブなグラフィカル要素を使用してヘルスケア提供者112に様々な情報をグラフィカルに提示する。以下のセクションは、図5に示す例示的な表示要素に関連して、いくつかの可能なグラフィカル要素を説明する。

【0059】

グラフィカル要素とのインタラクションは、様々な方法で行われうる。たとえば、提供者GUIは、自分の関連付けられたクライアントデバイスを通じた提供者112からのユーザインタラクション(たとえば、選択)の受取りに応答して情報を提供し得る。システムがユーザ入力を受け取り得る多種多様な方法があり、その例は、限定はしないが、ポインタデバイスまたは指を用いてグラフィカル要素の上でホバリングすること、ある長さの時間にわたってグラフィカル要素をホールドすること、グラフィカル要素を1回または複数回タッチまたはクリックすることを含む。さらに、情報は、ダッシュボードが提示できる情報の構成要素であるいくつかの断片の変化に応答して提示され得る。情報の提供

【0060】

開かれたことに応じて、アプリケーション115は、様々なインタラクティブな要素を有するナビゲーションメニューを含むダッシュボード300を生成し得る。これらは、特定の患者111に関する他のグラフィカル要素を通じて、ヘルスケア提供者112が情報を識別し得るとともにヘルスケア提供者112に情報が提示され得るように、検索ツールを含みうる。ナビゲーションメニューはまた、新たな提供者112に対する識別、または、たとえば、カードを通じて、やはりシステムが患者111に提供する通知を含む、通知メニューを含みうる。最後に、セキュリティのために、ナビゲーションメニューは、パスワードを更新することを含む、提供者のプロファイル設定を統制すること、ならびにアプリケーション115およびダッシュボード300のログインおよびログアウトのための、メニューを含みうる。

【0061】

IV.B.患者タイプ表示
患者タイプ表示401は、監視するための権限付与を提供者112が有する患者111をカテゴリー化する、患者タイプの視覚メニューを含む。例示的な患者タイプは、喘息に苦しむ患者401a、COPDに苦しむ患者401b、嚢胞性線維症を有する患者(図示せず)、および任意の他の呼吸器疾患を有する患者を含みうるが、これらに限定されない。さらに、メニューの中の別個のエントリは、上記の疾患のうちのいずれかを有するがそのセンサーが非アクティブである患者401cを含みうる。非アクティブの定義は、セクションIV.Cにおいて以下、さらに説明される。

【0062】

患者タイプ表示401から任意の1つの患者タイプを選択することは、そのステータスに関係する情報と一緒にその疾患/デバイスステータスを伴う、患者のリストを詳述する患者概要表示402を、アプリケーション115に生成させる。図4Aは、一実施形態による例示的な患者タイプ表示401を示し、いくつかの実施形態では、患者タイプ表示401は、ナビゲーションメニューからの患者リストオプションの選択時に、提供者112に表示され得る。あるいは、それはログイン時に示されるデフォルトスクリーンであってもよい。

【0063】

IV.C.患者概要表示
患者概要表示402の表示される内容は、選択される患者タイプに応じて異なる。

【0064】

図4Bは、一実施形態による、喘息患者タイプに対する例示的な患者概要表示402を示す。喘息患者タイプ401aの選択の受取りは、氏名によって編成された患者のリストを含む患者概要表示をアプリケーション115に表示させ、患者のリストは、患者ごとに、それらの喘息の患者の管理に関係する情報の以下の項目、すなわち、喘息コントロールスコア402a、レスキュー吸入器使用の報告402b、コントローラ吸入器使用の報告402c、患者のレスキュー薬剤デバイス160に関連付けられた、関連付けられたレスキュー投薬センサーへの患者のクライアントデバイス110の直近の同期の記録402d、患者のコントローラ薬剤デバイス160に関連付けられたコントローラセンサーへの同じかまたは異なるクライアントデバイス110の直近の同期の記録(図示せず)、および患者111と提供者112との間の直近の連絡の記録402eのうちの、1つまたは複数を含む。これらの項目の各々について、このセクションの中の以下の段落において説明する。

【0065】

喘息コントロールスコア402aとは、規定された期間時間(たとえば、7日間、1か月間)にわたって患者が自分の喘息をコントロール下に有する程度の推定値を表す、導出された格付けである。格付けは、システム100にリンクされた患者の薬剤デバイスに関連付けられたセンサー120によって報告されるような、患者のレスキュー吸入器使用データおよびコントローラ吸入器使用データに基づいて決定される数値スコア(たとえば、1が低く10が高い1～10の格付け)として計算されてよくかつ/または表されてうる。喘息コントロールスコア402aはまた、同じグラフィカル要素内で提示される多くの患者のステータスを評価するとき、視覚的に表すのにもっと簡単であり、かつ提供者112にとってより有用な、記述的な格付け(たとえば、極めて不良、良好でない、または良好)に、計算または変換されてよい。喘息コントロールスコア402aの計算に関するさらなる詳細が、米国特許出願第15/724,968号に関して説明され、その内容が参照により本明細書に組み込まれる。

【0066】

レスキュー吸入器使用の報告402bは、監視期間とも呼ばれる規定された時間期間にわたる各日に対して、別個のインジケータを用いて日ごとにグラフィカルに表されてよい。監視期間は、喘息コントロールスコア402aを決定するために使用される時間期間と同じであっても異なってもよい。一実施形態では、レスキュー吸入器使用の報告402bは、その日の間に遭遇したレスキューイベントの合計回数のカウントとともに、期間内の各日を示すグラフィックスとして表される。加えて、報告402bは、その期間中に遭遇したレスキューイベントの回数の累積カウントを含みうる。

【0067】

アドヒアランス尺度とも呼ばれるコントローラ吸入器使用の報告402cは、いくつかの実施形態では、アドヒアランス尺度を示すプリントされた文字と一緒に、同じかまたは異なる監視期間にわたって患者のアドヒアランスを視覚的に示すグラフィカルインジケータとして表されてよい。アドヒアランス尺度は、患者111または提供者112によって確立されるコントローラ投薬計画に基づいて決定される。一実施形態では、アドヒアランス尺度は、確立されたコントローラ投薬計画によって規定された分量の数と比較した、患者によって摂取されたコントローラ薬剤分量の量の比を表すが、他の実施形態では、アドヒアランス尺度は、摂取および計画されたコントローラ薬剤分量についての情報を組み込むいくつかの他の関数に従って決定されてよい。アドヒアランス格付け統計値402cおよび充填可能グラフィックスインジケータは互いに関係があり、たとえば、アドヒアランス格付けが64%の患者のための充填可能グラフィカルインジケータは、64%しか充填されないことになる。提示されるアドヒアランス尺度およびグラフィカル要素は、患者による過度のコントローラ吸入器使用に起因して100%を上回るアドヒアランス尺度を記録するように構成され得る。この事例における充填可能インジケータは、その最大まで充填され得るか、またはさもなければアドヒアランスの100%を上回る使用を示すようにグラフィカルに変更され得る。

【0068】

アドヒアランス同期記録402dは、クライアント110デバイスとレスキュー薬剤デバイス160に関連付けられたレスキューセンサー120との間で接続(たとえば、BTLE)が確立された直近の時間を記述する日付として視覚的に表される。同期自体は、一般に自動的に行われ、システム100にアクセスするクライアントデバイス110と通信するか、またはそうしたクライアントデバイス110を通じて通信する、システムのユーザによるアクションに応答して、肯定的に行われることもある。場合によっては、同期は、トリガ条件の変更、または検出されたレスキュー使用イベントに応答して行われる。レスキューセンサーを患者のクライアントデバイス110に同期させないことは、機能不全のセンサーに起因し得るか、またはセンサーとの接続が存在しないかもしくは弱い接続に起因し得る。レスキュー同期記録402dと同様に、クライアントデバイス110とコントローラ薬剤デバイス160に関連付けられたコントローラセンサー120との間で接続が確立された直近の時間を記述する日付として、コントローラアドヒアランス同期記録(図示せず)も視覚的に表されうる。上記で説明した同じ同期考慮事項が、コントローラアドヒアランス同期記録に適用される。

【0069】

患者111と提供者112との間の直近の連絡の記録402eは、患者および/または提供者の通信記録(たとえば、電話記録、本人自身による記録、および/または電子医療記録(EMR:electronic medical record))に基づいて同様に更新される。直近の連絡402eはまた、たとえば、患者111によって送られるかまたは応答されるカードの形態で、システム100を通じて容易にされた、患者111および提供者112のクライアントデバイス110の間で交換される通知または他の通信に基づいて更新されてよく、ここで、カードは、ダッシュボード300を使用して処理されるアクションを通じて提供者112によって取られる手動のアクションに基づいて送られる。

【0070】

患者のプライバシー、およびHIPAA規制との整合性を保全する手段として、患者概要表示402は、ユーザ入力に応答して患者氏名のリストを隠すことができるボタン402fを含む。さらに、情報402a～402eの項目へのユーザ入力は、選択された情報に基づいて患者をソートする。たとえば、喘息コントロールスコア402aの選択に応答して、患者のリストはスコアの昇順で再編成され得る。さらに、いくつかの実装形態では、提供者は、ブックマーク機能402gを使用して、患者リストからの特定の患者をブックマークし得る。

【0071】

図4Cは、一実施形態による、COPD患者タイプに対する別の患者概要表示403を示す。COPD患者タイプ401bの選択の受取りは、氏名によって編成された患者のリストを含む患者概要表示をアプリケーション115に生成させ、患者のリストは、患者ごとに、それらのCOPDのそれらの患者の管理に関係する情報の以下の項目、すなわち、レスキューベースライン評価403a、レスキュー吸入器使用の報告403b、コントローラ吸入器使用の報告403c、関連付けられたレスキューセンサー120への患者のクライアントデバイス110の直近の同期の記録403d、患者リストの患者ごとに患者のコントローラ薬剤デバイスに関連付けられたコントローラセンサーへの同じかまたは異なるクライアントデバイス110の直近の同期の記録(図示せず)、および患者111と提供者112との間の直近の連絡の記録403eのうちの、1つまたは複数を含む。これらの項目の各々について、このセクションの以下の段落において説明する。

【0072】

一実施形態では、レスキューベースライン評価403aは、(1)ベースライン時間期間にわたって決定される、日単位のレスキューイベントの平均回数と、(2)現在の日に対するレスキューイベントのカウントとの間の比較に基づいて、決定される。前に説明した監視期間と同様に、患者、提供者、システムによって、または権限が付与された第三者によって、ベースライン時間期間が確立され得る。他の実施形態では、前の実施形態において識別されたものと類似の情報の項目を使用する任意の他の関数に従って、レスキューベースラインが決定され得る。レスキューベースライン403aは、レスキュー使用イベントが患者のセンサー120またはクライアントデバイス110によってシステムに報告されるときはいつでも、自動的に更新し得る。

【0073】

レスキュー吸入器使用の報告403bは、監視期間とも呼ばれる規定された時間期間にわたる各日に対して、別個のインジケータを用いて日ごとにグラフィカルに表されてよい。監視期間は、喘息コントロールスコア402aを決定するために使用される時間期間と同じであっても異なってもよい。一実施形態では、レスキュー吸入器使用の報告402bは、その日の間に遭遇したレスキューイベントの合計回数のカウントとともに、期間内の各日を示すグラフィックスとして表される。加えて、報告402bは、その期間中に遭遇したレスキューイベントの回数の累積カウントを含みうる。

【0074】

レスキュー吸入器使用の報告403bは、喘息患者概要表示に関して上記で説明した表現と同様に、日ごとにグラフィカルに記述されてよく表されてよい。さらに、いくつかの実施形態では、別個のインジケータは、所与の日に対してレスキューイベントの回数を特徴づけるために色分けされてよい。たとえば、図4Cに示すようなCOPD患者概要表示の表現は、任意の回数(0回を含む)のレスキューイベントを記録する日々を表すために、グラフィカルに差異化されたインジケータを使用し、ここで、異なるグラフィックスは、異なる回数のレスキューイベントを表すために使用される。イベントがない日々(またはあるいは、イベントがある日々)もまた、特に示されうる。

【0075】

上記に列挙されたような、COPD患者タイプ401bに関連付けられる残りの患者データは、喘息患者タイプ401aに関するそれらの記述と一致する方法で記述され表される。

【0076】

センサー非アクティブ患者タイプ401cの選択の受取りは、列挙された患者ごとに、以下の要因、すなわち、患者のクライアントデバイスが患者の対応するセンサー(レスキューセンサー、コントローラセンサー、またはそれ以外のいずれか)のうちの1つと最後に同期されてからの時間期間、イベントの直近の記録からの時間期間のうちの、1つまたは複数を含む患者のリストの異なる患者概要表示をアプリケーション115に生成させる。このリストの中に含めるためにどの患者が関連するのかを決定するためのしきい値は、実装形態によって異なってよく、静的または動的に設定されてよく、さらにシステム事業者、患者、提供者、または権限が付与された第三者によって設定されてもよい。いかなる所与の患者も、彼らのコントローラセンサーが同期されているにもかかわらず彼らのレスキューセンサー120が同期されない場合は列挙されてよく、逆も同様である。患者および患者の関連付けられたデバイスが、このリストの中に含めるための上記の要因のうちの複数を満たす場合、第2のグラフィカル要素は、患者111またはセンサー120からの情報の直近の報告に関連する要因を、どれが時間的に直近であるのかに応じて選択的に表示し得る。

【0077】

IV.D.患者疾患管理表示
上記で説明したように、アプリケーション115は、クライアントデバイス110から受け取られる患者タイプ401aの選択に応答して、患者情報を有する患者概要表示402を表示する。患者概要表示402がこの患者関連情報を表示している間、患者概要表示402およびアプリケーション115は、より一般的には、患者概要表示402が表示している列挙された患者のうちの1人の患者に関する選択入力を受け取るように構成される。

【0078】

選択に応答して、アプリケーション115は、報告済みレスキュー薬剤使用イベントの履歴404aおよびコントローラ薬剤使用イベントの履歴404bのうちの1つまたは複数を視覚的に示す患者疾患管理表示404を表示する。図4Dは、一実施形態による、喘息患者タイプを有する例示的な患者に対する例示的な患者疾患管理表示404を示す。患者疾患管理表示404は、患者概要表示402に少なくとも部分的に重なり合うように、アプリケーション115によって表示されてよい。報告済みレスキュー薬剤使用イベントの履歴404aおよびコントローラ薬剤使用イベントの履歴404bは、少なくとも別個のグラフィカルな、時間の関数としてレスキューイベントまたはコントローライベントの回数を図解する非テキスト要素として表示される。これらのグラフィカルイベント履歴は、互いに同時に表示されてよい。グラフィカル履歴はまた、互いに重なってもよい(図示せず)。図4Dの例示的な実施形態では、履歴はヒストグラムとして表示されるが、代替実装形態では、ラインプロットなどの、任意の類似のデータプロットメカニズムが使用されてよい。

【0079】

さらに、患者疾患管理表示404は、ユーザ入力を受け取り、ユーザ入力に応答して、グラフィカルイベント履歴のうちの一方または両方の時間フレームを調整するように構成された選択可能要素404cを含む。図4Dの図示の例示的な実施形態では、選択可能要素404cは、スライドグラフィカルインジケータとして表される。グラフィカル履歴の時間フレームの調整は、所与の時点を越えるイベントを含むように日付の範囲を拡大することによって、または所与の時点を越えるイベントを除外するように日付の範囲を縮小することによって実施され得る。これらのうちのいずれも、時間における前方および/または後方を相応に考慮してイベントの日付を変更することによって達成され得る。考慮される日付の拡大または縮小は、いくつかの「中央」の日付に関して対称であってよく、または選択可能要素は、入力が日付範囲をカスタム構成することを可能にする部分要素を含みうる。グラフィカルイベント履歴内で、個々のバーは、特定の日におけるレスキューイベントの回数または患者111のアドヒアランス格付けを示す。

【0080】

IV.E.患者日単位レスキュー表示
患者疾患管理表示がグラフィカルイベント履歴を表示している間、アプリケーション115は、報告済みレスキュー薬剤使用イベントのグラフィカル履歴404aまたはコントローラ薬剤使用イベントのグラフィカル履歴404bから、単一の日に関する選択入力を受け取るように構成される。選択に応答して、アプリケーション115は、選択されたグラフィカルイベント履歴に関係する患者日単位表示を生成する。レスキュー薬剤使用の履歴からの単一の日の選択は、アプリケーション115が患者日単位レスキュー表示405aを表示する結果となるが、コントローラ薬剤使用イベントの履歴404bからの単一の日の選択は、患者週単位コントローラ表示405bをアプリケーション115に表示させる。患者日単位表示は、患者疾患管理表示404に少なくとも部分的に重なり合ってもよい。いくつかの実施形態では、患者日単位表示へのユーザ入力の受取りに応答して、アプリケーション115は、完全でない場合には著しく患者疾患管理表示402に重なり合う患者日単位表示404を生成してよい。患者日単位表示は、患者のレスキュー投薬傾向またはコントローラ投薬傾向に関する言語的情報を含むテキストボックスとして表示されるが、代替実施形態では、任意の類似の提示フォーマットが使用されてよい。この段落は特に日単位の閲覧を説明するが、実際には、入力は、閲覧が半日、数時間などの、他の時間期間もカバーするという結果になることがある。

【0081】

患者日単位レスキュー表示は、以下のもの、すなわち、レスキューイベント中に使用されたレスキュー薬剤の名称、その薬剤の投与量および投与量が費用勘定につけられた時間、ならびにレスキューイベントがレスキューセンサー120によって検出されたのかそれともユーザによって手動で記録されたのかのうちの、1つまたは複数を含む。たとえば、図4Dの図示の実施形態では、患者日単位レスキュー表示405aは、2回のイベント中にアルブテロールが使用されたこと、およびイベントごとに1パフ(puff)の投与量が使用されたことを報告する。

【0082】

患者日単位レスキュー表示406の代替実施形態が図4Eに示される。図4Dにおいて提示される情報に加えて、患者日単位レスキュー表示はまた、任意の誘発条件または患者によって経験された症状に関する情報406aを提示してよい。誘発条件は、環境的(たとえば、大気汚染指数、湿度、温度、風速など)または習慣的(たとえば、消失したコントローラ薬剤分量)であってよい。誘発条件および症状に加えて、患者日単位レスキュー表示は、レスキュー薬剤使用イベントの位置を詳述する地理的マップ406bを含みうる。いくつかの実施形態では、地理的マップ406bは、ユーザ入力を受け取り、ユーザ入力に応答して、マップに対する視覚的な詳細のレベルを増分的に調整するように構成された、第2の選択可能要素を含みうる。

【0083】

図4Eによって示される実施形態では、選択可能要素は2つのボタンとして表される。調整は、もっと高レベルの情報(たとえば、都市名、周囲の地形)を含むように、マップ上の所与の点を越えて視野を拡大すること、またはもっと低レベルの情報(たとえば、街路名、特定の住所)を含むように、視野を最小化することによって、実施され得る。地理的マップ406bのための拡大および最小化メカニズムは、図4Dにおいて表示された選択可能要素404cに関して以前に説明したものと一致する。

【0084】

IV.F.患者週単位コントローラ表示
患者日単位レスキュー表示と同様に、コントローラ薬剤使用の履歴からの単一の日または日々の範囲の選択の受取りに応答して、アプリケーション115は、患者疾患管理表示に少なくとも部分的に重なり合う患者週単位コントローラ表示を表示する。患者週単位コントローラ表示は、以下のもの、すなわち、選択された日付の間に使用されたコントローラ薬剤の名称、および選択された日付の間の日ごとの、摂取された薬剤分量対推奨される薬剤分量の記録のうちの、1つまたは複数を含む。たとえば、図4Dに示す実施形態では、患者週単位コントローラ表示は、推奨される2分量のうちの1分量のデュレラ(Dulera)を患者が月曜日に摂取したことを報告する。

【0085】

患者週単位コントローラ表示407の他の見え方が図4Fに示される。図4Dにおいて提供された情報に加えて、代替の第4のグラフィカル要素407は、薬剤デバイスに関する詳細407a(たとえば、同期されたクライアントデバイス、患者のための投与量予定表、および投薬に対する推奨される投与量)を含みうる。さらに、第4のグラフィカル要素407は、摂取された薬剤、および薬剤が摂取された時間などの、日々のコントローラ投薬活動に関するさらなる詳細407bを含みうる。

【0086】

IV.G.患者概要表示
患者疾患管理表示404はまた、図4Gに示すように、ユーザ入力に応答して患者概要傾向表示を見せるスクロール可能要素を含みうる。患者概要傾向表示は、以下のもの、すなわち、患者ステータスタブ408a、患者センサー情報タブ408b、および30日間患者傾向タブ408cのうちの、1つまたは複数を含む。いくつかの実装形態では、これらのタブは、追加情報を見せるかまたは隠すことによって、ユーザ選択に応答して選択可能であってよい。30日間患者傾向タブ408cは、患者のレスキューイベントがいつ発生するのかのパーセンテージによる内訳(たとえば、午前、午後、夕方、または夜間)、および日ごとの患者のレスキュー使用のパーセンテージによる内訳に関する詳細を含みうる。他の実装形態では、このデータは、グラフィカルもしくは視覚的に表されてよく、または追加の傾向詳細を含みうる。

【0087】

V.患者側グラフィックス表示
ダッシュボード300に関して前に説明したように、いくつかの実施形態では、患者111のクライアントデバイス110には、カテゴリーに編成され得る様々な異なる表示カードのうちのいずれか1つを使用して、環境条件、投薬計画、または患者111の個人的な健康に関する通知が送られてよい。

【0088】

情報カードタイプは、データを表示するカードを含む。情報カードは、たとえば、投薬レスキューイベント、統計値、および患者データと地域社会データの両方を含むマップを表示し得る。情報カードは、さらにイベントカード、傾向カード、教育カード、および警告表示カードにサブカテゴリー化される。

【0089】

イベントカードは、特定の患者に対する履歴投薬レスキューイベントのリスト、または特定の提供者に対する地理的マップ上に重なり合う患者レスキューイベントデータなどの、レスキュー投薬イベントに関するデータを含む。たとえば、図5Aに示す表示カード510aは、特定の地理的エリアの中で喘息レスキューイベントに遭遇する患者を強調するイベントカードである。図5Gに示す表示カード510qは、例示的な薬剤使用報告を表示するイベントカードである。例示的な薬剤使用報告は、レスキュー使用イベントの位置のマップ、その位置における環境条件、および受領者がレスキュー使用イベントに対する誘因を追加するための入力応答エリア315を含む。

【0090】

傾向カードは、受領者による明瞭な理解のために設計されたグラフまたはチャートを使用して提示される統計情報を含む。図5Cは、両方とも様々な時間期間にわたる、喘息レスキューイベント510cおよび喘息コントローラ投薬アドヒアランス510dをプロットする2つの異なる例示的な傾向カードを示す。図5Lは、4つの異なる例示的な傾向カードを示す。カード510aaは時刻傾向を表示し、カード510bbは症状傾向を表示し、カード510ccは曜日傾向を表示し、カード510ddは誘因傾向を表示する。

【0091】

教育カードは、受領者を教育することが意図される情報を含む。図5Jおよび図5Kは、一般的な疾患情報を提供する教育カード510wおよび510x、ならびに受領者にチップを与える教育カード510yおよび510zを示す。教育カードは、提供された情報が将来のカードを供給する際の使用にとって重要であるかまたは興味深いかどうかを受領者が指定することを可能にするための入力応答315を含みうる。

【0092】

警告カードは、重要な情報をユーザに通知する。図5Fのカード510oおよび510pは、イベントに対するリスクが受領者にあることを彼らに知らせるための警告カード510o、および直近の時間期間にわたってデバイスからデータが受信されていないことを受領者に知らせるための警告カード510pである。図5Mは、例示的な警告カードを示す。カード510eeはカード510oと類似であり、カード510ffはカード510pと類似である。カード510ggは、特定の分量の投薬がデバイスによって記録されていないことを受領者に知らせる。他の警告は、クライアントデバイス上での設定が同期を妨げている(たとえば、BLUETOOTH(登録商標)がオフにされている)、または患者の喘息コントロールテストスコアが変化しているという警告を含みうる。

【0093】

調査カードタイプは、ユーザが応答すべき、yes/no、複数の選択肢、または形式がもっと自由な質問を提示することによって、ユーザ応答を要請する。たとえば、ヘルスケア提供者または分析システム100は、特定の患者に対する疾患コントロールのレベルを決定するために、COPD、喘息、または他のアンケートを伴う調査カードを患者111へ送ってよい。追加の例として、図5Aに図示した表示カード510bに示すように、調査カードは、喘息症状を治療するために患者111が使用するコントローラ薬剤のタイプを要求し得る。概して、調査カードは、(上記で紹介したような)患者の医療履歴もしくは患者プロファイルから消失しつつある場合があるデータをアプリケーションサーバ130に提供し、かつ/またはおそらく古くなった情報の最新版を提供する。概して、1つまたは複数の調査カードは、患者登録プロセスを完了し、データベースサーバ140の中に記憶するための患者プロファイルを作成するために使用され得る。具体例として、患者111が最初に分析システム100に登録すると、患者プロファイルを作成することを患者111に促すプッシュ通知が、アプリケーションサーバ130によってトリガされる。調査カードの例が図5Dおよび図5Eに示され、それらは、患者が喘息悪化の結果として救急室来診を行っているかどうか、患者のコントローラ薬剤が何であるのか(510f)、イベントをコントロールするために患者が患者のレスキュー投薬を何回使用したのか(510g)、および患者のコントローラ投薬日単位予定がどのようになっているのか(510h)を尋ねる、調査質問を示す。調査カードはまた、花粉が誘因であるかどうかなどの患者喘息誘因について尋ねてよい(510e)。他の調査カードは、患者の一般的な生活の質を5点リッカート尺度において格付けすること、患者の眠りの質を格付けすること、直近の7日間にわたって活動的であるための患者の能力を格付けすることなどを、患者に依頼する。他の調査カードは、患者が昨日よりも気分がよいのかそれとも悪いのか、患者が直近の12か月間に悪化のために救急室または病院へ行かなければならなかったかどうかなどを尋ねる。

【0094】

いくつかの事例では、既存の患者情報と矛盾する患者挙動またはセンサー報告のイベント情報は、患者の環境に関するあいまいさを解決するために調査カードを送ることをトリガし得る。たとえば、患者が予想よりも大きいカウントの喘息イベントに遭遇している場合、調査カードは、正しい薬剤が使用されていることを確認するために、患者の薬剤デバイス160上で列挙されるような、患者が現在使用している薬剤のタイプについての情報を要求してよい。別の例として、コントローラ薬剤使用についての報告された情報が、患者が日ごとに1回しかコントローラ薬剤を使用していないことを示すが、患者のアドヒアランス計画が、患者が自分のコントローラ薬剤を日ごとに2回摂取しているものと思われていることを示す場合、システム100は、患者が自分のアドヒアランス計画を変更する必要があるかどうかを尋ねる通知を送ることができる。

【0095】

ナビゲーションカードは、ユーザインタラクション時に、ダッシュボード300の一部である別のスクリーンまたはカードにユーザを向け直してよい、アクション可能なデータまたはメッセージを表す。たとえば、患者が、情報を共有することを希望するか、またはコントローラ薬剤に対して特定の投薬計画を内科医とともに要求する場合、ナビゲーションカードは、情報の共有またはコントローラアドヒアランス計画への登録を容易にするために使用されることになる。さらに、ナビゲーションカードは、投薬レスキューイベントを取り巻く情報をユーザが更新することを可能にする。

【0096】

アドヒアランスカードは、様々な時間期間にわたって予定通りに自分のコントローラ薬剤を継続的に使用することを患者に奨励するように設計される。図5B、図5C、および図5Fは、例示的なアドヒアランスカードを示す。カード510iは、「ストリーク(streak)」、すなわち時間通りのコントローラ投薬イベントの継続的な連続の一例を示し、カード510kは、ストリークが達成されていない場合でも集約時のより良好な実行を示し、カード510lは、喘息症状のない経験した日数に関して、改善された患者健康を提示する。カード510jは、互いのしきい値時間期間(たとえば、24時間)内での際立った回数の(たとえば、2回の)レスキュー投薬イベントの記録に応答して、患者の身体的状態に関して質問する調査カードである。カード510mは、患者111のヘルスケア提供者112によって規定されるような、その日の間の様々な期間中に、患者111が自分のコントローラ薬剤を時間通りに摂取したときおよび摂取しなかったときを示すグラフとして、コントローラ投薬イベントを示す。カード510nは、コントローラ薬剤に対する日単位の予定、および予定された分量が摂取されているかどうかを表示するためのインジケータを示す。カード510nの例では、インジケータは、予定された分量が摂取されていないことを示す赤色の「X」である。緑色のチェックマークまたは別のシンボルは、予定された分量が摂取されていることを示すために使用され得る。

【0097】

セットアップカードは、センサーをクライアントデバイス110と関連付ける際に受領者を案内する。図5Iは、BLUETOOTHを使用してセンサーをクライアントデバイス110にペアリングするための例示的なセットアップカードを示す。カード510sは、ペアリングプロセスを開始することを受領者に促す。カード510tは、ペアリングのためのセンサーデバイスを選択することをユーザに促す。カード510uおよび510vは、センサーがペアリングされていることをユーザに通知する。

【0098】

図3の一実装形態では、ダッシュボード300の中に提示される例示的なユーザインターフェースは、投薬リストを示す。リストは、投薬タイプ(レスキュー投薬、コントローラ投薬など)、投与量予定表、およびセンサーなどの、投薬情報を含む。受領者は、薬剤および投薬情報を追加、編集、および削除するために、リストとインタラクションを行い得る。

【0099】

VI.追加の考慮事項
本開示の図面および説明が、明快のために、典型的なシステムの中に見出される多くの他の要素を排除しながら、本開示の明瞭な理解にとって重要な要素を示すために簡略化されていることを理解されたい。当業者は、本開示を実施する際に他の要素および/またはステップが望ましく、かつ/または必要とされることを認識し得る。しかしながら、そのような要素およびステップは当技術分野でよく知られているので、またそれらは本開示のよりよい理解を容易にはしないので、そのような要素およびステップの説明は本明細書では提供しない。本明細書での開示は、当業者に知られているそのような要素および方法へのすべてのそのような変形および修正を対象とする。

【0100】

上記の説明のいくつかの部分は、情報における動作のアルゴリズムおよび記号表現によって実施形態を説明する。これらのアルゴリズム的な説明および表現は、他の当業者の作業の要旨を効果的に彼らに伝えるために、データ処理における当業者によって普通に使用される。これらの動作は、機能的、計算的、または論理的に説明されるが、コンピュータプログラムまたは均等な電気回路、マイクロコードなどによって実施されるものと理解される。

【0101】

本明細書で説明したステップ、動作、またはプロセスのうちのいずれかは、1つまたは複数のハードウェアモジュールまたはソフトウェアモジュールを用いて、単独で、または他のデバイスと組み合わせて、実行または実装され得る。一実施形態では、ソフトウェアモジュールは、説明したステップ、動作、またはプロセスのうちのいずれかまたはすべてを実行するためにコンピュータプロセッサによって実行され得るコンピュータプログラムコードを含む、コンピュータ可読非一時的媒体を含むコンピュータプログラム製品を用いて実装される。

【0102】

本発明の実施形態はまた、本明細書で説明したコンピューティングプロセスによって生み出される製品に関係することがある。そのような製品は、コンピューティングプロセスから得られる情報を含んでよく、ここで、情報は、非一時的な有形コンピュータ可読記憶媒体上に記憶され、本明細書で説明したコンピュータプログラム製品または他のデータの組合せの任意の実施形態を含みうる。

【0103】

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

【0104】

本明細書で使用するとき、「備える」、「備えること」、「含む」、「含むこと」、「有する」、「有すること」という用語、またはそれらの任意の他の変形は、非排他的な包含をカバーするものとする。たとえば、要素の列挙を含むプロセス、方法、項目、または装置は、必ずしもそれらの要素のみに限定されるとは限らず、明確に列挙されないか、またはそのようなプロセス、方法、項目、もしくは装置に固有の、他の要素を含みうる。さらに、それとは反対に明確に述べられない限り、「または」は、排他的な「または」ではなく包含的な「または」を指す。たとえば、条件AまたはBは、以下のこと、すなわち、Aが真であり(または、存在し)かつBが偽である(または、存在しない)、Aが偽であり(または、存在しない)かつBが真である(または、存在する)、およびAとBの両方が真である(または、存在する)のうちの、いずれか1つによって満たされる。

【0105】

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

【0106】

特定の実施形態および適用例が図示および説明されているが、開示する実施形態が、本明細書で開示する厳密な構成および構成要素に限定されないことを理解されたい。当業者に明らかとなる様々な修正、変更、および変形が、添付の特許請求の範囲の中で定義される趣旨および範囲から逸脱することなく、本明細書で開示する方法および装置の構成、動作、および詳細に加えられてよい。

【符号の説明】

【0107】

100 分析システム
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 グラフィックディスプレイ要素
315 入力応答
401 患者タイプ表示
402、403 患者概要表示
404 患者疾患管理表示
406 患者日単位レスキュー表示
407 患者週単位コントローラ表示
510 カード

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図4C】

【図4D】

【図4E】

【図4F】

【図4G】

【図5A】

【図5B】

【図5C】

【図5D】

【図5E】

【図5F】

【図5G】

【図5H】

【図5I】

【図5J】

【図5K】

【図5L】

【図5M】