JP6887065B2 - 薬剤デバイスで使用するためのレイテンシの減少したワイヤレス通信 - Google Patents

Description

本開示は、一般に、薬剤使用を検出するための、クライアントデバイスと薬剤デバイスセンサとの通信を改善する方法に関し、より詳細には、そのようなデバイス間のping間のレイテンシが減少したワイヤレス通信に関する。

喘息は、依然として重大でコストの大きい公衆衛生問題である。世界的に、世界保健機関は、喘息患者数は3億人であると推定し、2025までに4億人に増加するであろうと予測する。米国では、喘息は、米国の12人に1人に影響を及ぼし、罹患率は上昇しつつあり、医療利用費は毎年560億ドル以上となっている。

新しい薬剤の開発にかかわらず、入院および救急外来受診率は減っていない。米国では毎年、この病気により約200万人が救急来院し、500,000人が入院し、5,000人が死亡する。さらに、喘息は、推定1,500万日の学校欠席、1,200万日の欠勤の原因となっている。米国の保険会社および雇用者にかかる総年間コストは、180億ドルを超える。

これらの悪化の大半は、現在利用可能な治療で防ぐことができるが、喘息患者の5人に1人しか、病気をコントロールしていない。新たに改訂された国のガイドラインは、治療が日々の症状をコントロールし、生活の質を向上させているかどうかをより綿密に監視するよう医者に促している。しかしながら医師には、患者が日々いかによくなっているかを評価するために利用できるツールがほとんどない。ますます多くの医師が、患者を監視し、患者のコントロールレベルを決定するために、定期的な、書面による質問表(喘息管理テストなど)を使用し始めた。これらの手段は患者に、ある期間(通常2〜4週間)にわたる症状の頻度、吸入器の使用、ならびに活動レベルおよび制限を、正確に思い出して報告することを要求する。結果として、これらの質問表は、バイアス(記憶力)、症状の異なる解釈、および行動(ノンアドヒアランス(non-adherence))によって導入される誤差の影響を受け、それらが使用される時点の情報を提供するにすぎない。

より一般的には、医療用吸入器などの薬剤デバイスは、患者が気流の妨げなどの呼吸器症状を管理することを可能にするコルチコステロイドを投与する。患者が薬剤デバイスを使用するとき、投薬イベントのインスタンスを記録し、記録されたインスタンスを医師に送ることができると、医師によって患者をより良く監視することが可能になる。吸入器などの、そのような薬剤デバイスに取り付けられた薬剤デバイスセンサが、薬剤投与のインスタンスを記録し、記録されたインスタンスをサーバに送信するのに役立つことができるが、そのようなイベントは一般に、報告されるとしても、それらの発生時間よりもかなり後に行われる。場合によっては、そのようなイベントは、数日とまではいかなくても、数時間も後に報告され、これは問題である。

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

本開示は、クライアントデバイスによるワイヤレス接続によって薬剤デバイスセンサ上の複数のパラメータを更新するためのコンピュータ実装方法を説明する。一実施形態では、薬剤デバイスは、ユーザによる吸入によって薬剤投与を行うために使用される医療用吸入器である。クライアントデバイスは、薬剤デバイスセンサのための複数のパラメータを、クライアントデバイスに記憶する。クライアントデバイスは、クライアントデバイス上の複数のパラメータのうちの1つまたは複数のパラメータを更新する。クライアントデバイスは、薬剤デバイスセンサから複数の周期的チャープ(periodic chirp)を受信し、クライアントデバイスは、チャープを受信した薬剤デバイスセンサとワイヤレス接続を確立することができる。チャープは、クライアントデバイスとのワイヤレス接続を確立する準備ができていることを示す、短い継続時間の間ブロードキャストされるスモールパケットのデータである。チャープを受信した後、クライアントデバイスは、薬剤デバイスセンサとクライアントデバイスとの間でワイヤレス接続を形成する。またワイヤレス接続によって、クライアントデバイスは、複数のパラメータのうちの更新された1つまたは複数のパラメータを薬剤デバイスセンサに送信する。薬剤デバイスセンサによる電力使用は、薬剤デバイスセンサがクライアントデバイスにブロードキャストするチャープの周期によってある程度左右される。一実施形態では、ワイヤレス通信は、Bluetooth接続であり、特にBluetooth Low Energyプロトコルを利用する。コンピュータ実装方法のこの実施形態は、接続レイテンシにおける効率の改善をもたらす。Bluetooth Low Energyブロードキャスティングを利用すると、小さい低エネルギーのパケットのデータを、クライアントデバイスとのペアリングに薬剤デバイスセンサを利用できることを詳述するチャープとして送ることが可能になる。チャープあたりの電力使用量の減少は、チャーピング間隔を縮小することを可能にし、それによって、クライアントデバイスによって薬剤デバイスセンサとの通信が試みられるとき、待ち時間が減る。

薬剤デバイスセンサとクライアントデバイスとの間のより頻繁な通信は、薬剤デバイスセンサに対していくつかの機能の実現可能性を高める。上記で説明したように、ワイヤレス接続を用いたチャーピング間隔のレイテンシが減少すると、薬剤デバイスセンサへのパラメータ更新の転送を速めることが可能になる。他のシナリオでは、ワイヤレス接続を用いたチャーピング間隔のレイテンシが減少すると、クライアントがクライアントデバイスを介して薬剤デバイスセンサの位置を特定する機能に役立つ。同様に、薬剤デバイスセンサレコードのオフローディングは、レイテンシの減少で改善する。これらの追加機能は、コンピューティング資源の割振りを開放し、電力消費量を減らし、したがって薬剤デバイスセンサのバッテリ寿命を延ばす。これらの追加機能はまた、クライアントデバイスを介して薬剤デバイスセンサに接続する際にレイテンシが減少してユーザエクスペリエンスを高める。

一実施形態による、正確な、リアルタイムの薬剤デバイス使用を監視し、そのデータに関して分析を行い、薬剤デバイスイベントに基づいて通知を提供するための分析システムを示す図である。 一実施形態による、クライアントデバイス、アプリケーションサーバ、および/またはデータベースサーバとして使用される例示的なコンピューティングデバイスを示すハイレベルブロック図である。 一実施形態による、ユーザから喘息分析システムへ入力および/または出力を提供するクライアントアプリケーションのグラフィカルユーザインターフェースの図である。 一実施形態による、薬剤デバイスセンサからクライアントデバイスへの送信イベントとともにチャーピング間隔を示すタイムラインのセットの図である。 一実施形態による、薬剤デバイスセンサおよびクライアントデバイスのBluetoothモードを説明するフローチャートである。 一実施形態による、ワイヤレス接続を形成するより前に、クライアントデバイスに周期的にチャープすることにより薬剤デバイスセンサのパラメータを更新することを説明するフローチャートである。 一実施形態による、ワイヤレス接続を形成するより前に、クライアントデバイスに周期的にpingを実行することにより薬剤デバイスセンサの位置を特定することを説明するフローチャートである。 一実施形態による、ワイヤレス接続により薬剤デバイスセンサからクライアントデバイスに、記録されたイベントを送信することを説明するフローチャートである。

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

I.システム環境
図1は、一実施形態による、正確な、リアルタイムの薬剤デバイス使用を監視し、そのデータに関して分析を行い、それらのイベントについて情報を提供するための分析システム100を示す。

分析システムは、クライアントコンピューティングデバイス110(本明細書では単に「クライアント110」と呼ぶ)と、薬剤デバイスセンサ120(本明細書では単に「センサ120」と呼ぶ)と、薬剤デバイス160と、アプリケーションサーバ130と、データベースサーバ140と、ネットワーク150とを含む。図1は、分析システム100の構成要素の大部分の単一の事例しか示していないが、実際には各構成要素の2つ以上が存在する場合があり、図示した構成要素とともに、追加の構成要素またはより少ない構成要素が使用される場合がある。

I.A.クライアントおよびアプリケーション
クライアント110は、それらのユーザの強い要請により、ネットワーク150を介して分析システム100と対話する。説明および明快のために、少なくとも2つの異なるタイプのユーザを識別することが有用である。患者111は、センサ120によるレコードに基づいてサーバ130によって提供される個別のリスク通知を取得するために少なくとも部分的に分析システム100を利用する、医学的問題を抱えているユーザである。センサ120によって記録されたレコードは、1つまたは複数の薬剤デバイス160(たとえば、薬剤のタイプごとに1つ)による、レスキューおよびコントローラ薬剤投与をそれぞれ含む、レスキューおよびコントローライベントを含んでもよい。そのような通知は、分析システム100が患者111の薬剤デバイス160使用を監視することを可能にするユーザの許可と引き換えに行うことができる。以下で説明するように、投薬イベントは、薬剤デバイス160およびユーザのクライアント110と関連付けられたセンサ120によって検出され、クライアント110は次にアプリケーションサーバ130に報告し、アプリケーションサーバ130は次に、分析システム100によって決定されたユーザの医学的状態に関して通知を生成するプロセスを開始することができ、通知は、クライアント110を介してユーザに提供され得る。

別のタイプのユーザは、医療提供者112であり、医療提供者112は、この場合もやはり患者111の特別な許可を有し、同じく患者の薬剤管理に関する通知を受信する。いくつかの事例では、薬剤デバイスは、薬剤を与えるための医療用吸入器であり、喘息、慢性閉塞性肺疾患、慢性副鼻腔炎、アレルギー、別の呼吸の問題などをコントロールするためにいくつかの薬剤が使用される。患者111は、薬剤使用イベントデータおよび薬剤投与に関連するレスキューイベントに関する派生統計および他の関連データを巡って、通知がコミュニティと共有されるための許可を表明してもよい。患者111の親/保護者など、自身のクライアント110が子供のものとは異なる場合に、同様に通知を受け取ることを希望することがある、他のタイプのユーザもまた考えられる。

クライアント110は、コンピュータシステムである。例示的な物理的実装については、図2に関して以下でより十分に説明する。クライアント110は、ネットワーク150を介して分析システム100とワイヤレスに通信するように構成される。ネットワーク150アクセスがあると、クライアント110は、ユーザの地理的位置およびレスキュー投薬イベントの時間、ならびに関連センサ120から受信したイベントを説明する情報を、分析システム100に送信する。

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

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

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

ダッシュボードを提供することに加えて、アプリケーション115はまた、クライアント110の資源を使用してローカルで、レスキューイベントデータにいくつかのデータ処理を行った後、ネットワーク150を介して処理されたデータを送ってもよい。ネットワーク110を介して送られたイベントデータは、アプリケーションサーバ130によって受信され、そこで分析され、データベースサーバ140とともに記憶および検索されるように処理される。アプリケーションサーバ130は、クライアントアプリケーション115の必要に応じてデータベースシステム130に検索および記憶要求を宛ててもよい。

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

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

I.B.薬剤デバイスおよびセンサ
薬剤デバイス160は、呼吸気流の妨げを感じているユーザの肺に薬剤を届けるために使用される医療デバイスである。薬剤デバイス(たとえば、吸入器)は、一般に持ち運びでき、呼吸発作の治療時に利用しやすいように手で運べるほど小さい。一実施形態では、薬は、定量吸入器などの薬剤デバイス160を通して、エアロゾルの形態で届けられる。定量吸入器は、エアロゾル薬剤の圧縮高圧ガスキャニスタ(pressured propellant canister)と、調整された適用量を届けるための絞り弁と、加圧キャニスタを収納し、また薬を届けるためのマウスピースを形成するプラスチックホルダとを含む。別の実施形態では、薬は、乾燥粉末吸入器などの薬剤デバイス160を通して、乾燥粉末の形態で届けられる。乾燥粉末吸入器は、ユーザが乾燥粉末薬剤のストリップにより割出しすることを可能にする、ホイールおよび歯車機構を収納するデカルトの卵形の本体を有してもよい。乾燥粉末吸入器の本体はまた、乾燥粉末をユーザに届けるために、多岐管と、マウスピースとを含む。単回投与吸入器は、一度に薬剤の単回投与を機能的に行う乾燥粉末吸入器と同様に動作してもよい。コントローラ薬剤デバイス160によって投与されるコントローラ薬剤の例には、ベクロメタゾン、ブデソニド、およびフルチカゾン、ならびにそれらの薬剤と、サルメテロールまたはホルモテロールなどの長時間作用型気管支拡張薬の組合せが含まれる。レスキュー薬剤デバイス160によって投与されるレスキュー薬剤の例には、アルブテロール、サルブタモール、レブアルブテロール、メタプロテレノール、およびテルブタリンが含まれる。

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

一般に、センサ120は、薬剤ディスペンサ160の使用を監視する物理デバイスである。センサ120は、薬剤ディスペンサの動作を妨げることなく薬剤ディスペンサに取り外し可能に取り付けることができるか、センサ120は、薬剤ディスペンサ160の製造業者によって利用可能にされる、薬剤ディスペンサ160のネイティブパーツである内蔵構成要素である。

センサ120は、有線接続によって、またはより一般的にワイヤレス無線周波数接続によってクライアント110と通信する、センサ自体のネットワークアダプタ(図示せず)を含む。一実施形態では、ネットワークアダプタは、Bluetooth Low Energy (BTLE)ワイヤレス送信機であるが、他の実施形態では、他のタイプのワイヤレス通信が使用されてもよい(たとえば、赤外線、802.11)。クライアント110の一実施形態と通信する医療用吸入器へのセンサとしてのセンサ120の一実施形態について、図2〜図5とともにさらに説明する。

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

上記で紹介したように、センサ120は、薬剤デバイス160の使用についてのデータを取り込む。詳細には、各センサ120は、レスキュー投薬イベント、すなわち、患者111によるレスキュー薬剤デバイス160の使用の時間および地理的位置を取り込む。各センサ120は、リアルタイムで、またはワイヤレス接続が実現されるとすぐに、患者111または医療提供者112からの入力なしに自動的にイベントデータを送信する。投薬イベント情報は、分析、レスキューイベント通知の生成に使用するために、および複数の患者にわたるイベントデータの集計分析に使用するために、アプリケーションサーバ130に送られる。

この目的を果たすために、センサ120が構成されるいくつかの異なる方法があり、部分的に構成は、薬剤デバイス160の構成によって決まる。一般的に、すべてのセンサ120は、クライアント110および/またはサーバ130への投薬イベント情報を記録し、保存し、報告するために一緒に機能する、上述のオンボードプロセッサ、永続メモリ、およびネットワークアダプタを含む。センサ120はまた、イベントの日時を記録するためのクロック、および/またはセンサ120の全地球測位システム(GPS)座標を記録するためのGPS受信機を含んでもよい。

特定のセンサ120構成について、機械的投与量計数器などの従来の吸入器は、センサ120を念頭に置いて設計されず、したがってセンサ120は、適宜に構成されてもよい。このようにしていくつかの実装形態は、デバイス160の移動、デバイスのプライミング、デバイスの作動、ユーザによる吸入などを検出するために、機械センサ、電気センサ、または光学センサを含む。対照的に、屈曲可能な膜の(deflectable membrane)投与量計数器など、最新の吸入器は電気回路を含み、電気回路は、センサ120が受信し、解釈するように設計された電気データ信号としてイベント情報を報告してもよく、たとえば、薬剤デバイス160自体が、移動、プライミング、および作動をセンサ120に報告してもよい。

センサ120は、薬剤デバイス160による薬剤投与イベントの記録で使用するために組み込まれるパラメータを記憶してもよい。パラメータは、薬剤デバイス160のコンピューティングアーキテクチャによって実行される設定または特定の命令セットを制御するソフトウェア、ファームウェア、またはハードウェアデータである。例示的なパラメータは、限定はしないが、(i)薬剤投与リマインダ時間、遅延時間、または他の同様の設定、(ii)場合によっては特定のデバイス機能と関連して、薬剤デバイスのオーディオスピーカ上で再生するための個別のオーディオ着信音、(iii)センサ120機能の動作を制御するためのソフトウェア命令、(iv)検知および出力コンポーネント用の較正および構成値、(v)一意のデバイス識別子、認証キー、および暗号化キーを含む。センサ120のパラメータの一部または全部が、クライアント110に記憶されてもよい。クライアント110は、パラメータが更新されると、センサ120と通信し、クライアント110は、センサ120内に記憶し、センサ120で使用するために、更新されたパラメータを送信することができる。

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

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

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

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

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

プロファイルは、患者111および患者の個人的医療提供者112にどの異なるタイプの通知が提供されるか、ならびに通知が提供される頻度を明記してもよい。たとえば、患者111は、医療提供者112にレスキューイベントを示す通知を受信する権限を与えてもよい。患者111はまた、患者の医療提供者112が患者のプロファイルおよびレスキューイベント履歴にアクセスできるよう権限を与えてもよい。医療提供者112が患者111の患者プロファイルへのアクセスを与えられる場合、医療提供者は、コントローラアドヒアランスまたはレスキュー投薬計画を明記してもよい。投薬計画は、コントローラ薬剤の一日当たりの規定の投与回数を含んでもよい。

アプリケーションサーバ130はまた、医療提供者112のプロファイルを作成する。医療提供者プロファイルは、診療所の位置、資格、および免許など、医療提供者112についての識別情報を含んでもよい。医療提供者プロファイルはまた、医療提供者の患者集団についての情報を含む。提供者プロファイルは、その提供者の患者のプロファイルの全部、ならびに集計人口統計学的情報、レスキューおよびコントローラ投薬イベントパターンなど、それらのプロファイルからの派生データへのアクセスを含んでもよい。このデータは、地理的エリア(たとえば、近隣、都市)によって、または時間期間(たとえば、週単位、月単位、年単位)によってなど、患者プロファイルに記憶されたデータの任意のタイプに従ってさらに再分割されてもよい。

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

他の分析もまた可能である。たとえば、個人的、地理的、臨床的、疫学的、人口統計学的、または空間もしくは時間的ベースライン、または予測値もしくは期待値からの歴史的に重要な変更に基づき、薬剤使用の空間的/時間的クラスタ(またはアウトブレイク)に基づいて識別するために、複数の患者に対するレスキューおよびコントローラ薬剤使用について、リスク分析が行われてもよい。他のタイプの分析は、日/週ごとのアドヒアランス傾向、時間にわたるアドヒアランス変化、他の適切な母集団(たとえば、全患者、特定のレスキュー薬剤またはコントローラ薬剤またはそれらの組合せに関する患者)とのアドヒアランス比較、トリガ(空間的、時間的、環境的)の識別、時間にわたるレスキュー使用傾向、および他の適切な母集団とのレスキュー使用比較を含んでもよい。

分析の実行に応答して、アプリケーションサーバ130は、患者111、許可を受けた医療提供者112、および/または患者のプロファイルへのアクセスを与えられた他のユーザに送るプッシュ通知を準備し、配信する。通知は、投薬レスキューイベントに含まれるタイミング、位置、および罹患患者111について詳細を提供することができる。通知は、緊急支援提供者112に配信される、緊急支援を要求する遭難または緊急信号をさらに含んでもよい。通知はまた、データ分析モジュール131によって行われた喘息リスク分析の結果を含んでもよい。送られ得る通知のタイプおよび通知が含み得る内容に関するさらなる情報について、以下でさらに説明する。

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

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

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

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

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

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

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

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

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

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

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

III.ダッシュボード
ダッシュボード、たとえば図3に示すダッシュボード300は、ユーザが分析システム100と対話することを可能にする。ダッシュボード300は、ユーザ間(たとえば、患者111から医療提供者112)またはユーザからシステム/システムからユーザに基づいて、情報を転送する手段を提供する。ダッシュボード300は、クライアント110上のクライアントアプリケーション115によりアクセスされ、患者と医療提供者の両方が、投薬レスキューイベントを監視し、個別の患者医療情報を交換し、レスキューイベントリスク通知などの通知を受信するための機構を提供する。患者111は、たとえば、呼吸問題、薬剤の使用、または呼吸問題管理に関する情報を検討し、共有するために、ダッシュボード300を介して他の医療提供者112および他の患者111と通信してもよい。医療情報を共有することができると、同様の問題を経験している患者または医療提供者に、個々の見解を共有する方法が与えられ得る。

ダッシュボード300はまた、権限が与えられた医療提供者112が、患者についての情報、およびコミュニティデータ、および様々な人口統計または地理的セグメントの統計値を閲覧し、注釈を付け、更新し、相互に作用し、エクスポートするために、患者のリストにアクセスすることを可能にする。ダッシュボード300を使用すると、医療提供者は、医療提供者の関連する患者集団が呼吸問題管理ガイダンスにどのように反応しているかについてフィードバックを受信し、提供するために、患者111を個々にまたは全体として監視することができる。個々のまたは複数の患者111にアクセスできる医療提供者112は、通知しきい値を確立し、通知のためのパラメータを設定し、患者111のイベント履歴がいくつかの条件(たとえば、レスキューイベント)に一致するとき、通知を受信する能力を有する。さらに、ダッシュボード300は、分析システム100によって生成された特定の人口統計に対するイベントパターンの定期報告を受信し、表示することができる。

ダッシュボード300は、ディスプレイ「カード」310を介して、表形式データ、グラフによる可視化、および分析を含む様々な情報をユーザに提示する。ディスプレイカード310は、携帯型クライアント110、たとえば携帯電話またはタブレットに特有のより小さいディスプレイに適合しており、ベースボールカードに見られる単純化した構成スタイルによく似ている「一口サイズ(bite size)」の情報を含む。ダッシュボード300はまた、ユーザが異なるカテゴリの医療情報を検索することを可能にするシステムメニュー305を含んでもよい。

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

ダッシュボード300は、様々な異なるディスプレイカード310を提供してもよく、ディスプレイカード310は、カテゴリに整理されてもよい。情報カードタイプは、データを表示するカードを含む。情報カードは、たとえば、投薬レスキューイベント、統計値、および患者データとコミュニティデータの両方を含むマップを表示してもよい。情報カードは、さらにイベントカード、トレンドカード、教育カード、およびアラート表示カードに下位分類される。

イベントカードは、特定の患者についての履歴投薬レスキューイベントのリスト、または特定の提供者についての地理的マップ上に重ね合わせられた患者レスキューイベントデータなど、レスキュー投薬イベントに関係するデータを含む。

IV.クライアント/デバイス通信におけるチャーピング間隔
図4は、一実施形態による、薬剤デバイスセンサ120(センサ120)からクライアントデバイス110(クライアント110)への送信イベントとともにチャーピング間隔におけるレイテンシの減少を示す例示的なタイムラインのセットである。

第1のタイムライン410は、例示的な時間分解能を示す。イベントタイムライン420は、センサ120による記録されたイベントのインスタンスを表す。イベントは、センサ120によって記録された薬剤デバイス160による薬剤投与であってもよい。センサ120はイベントを記録するが、センサ120は、記録されたイベントを送信するための接続を確立するために、クライアント110と通信しなければならない。これは、所与の時点でクライアント110とセンサ120との間に接続が存在しないと仮定されるためであり、これはセンサ120から電力を不必要に消費し、さらにセンサ120は、所与の時点で、クライアント110の物理的範囲外にある場合があって、接続が形成できないからである。代わりに、クライアント110は、センサ120によるチャープを待った後に、接続を開始し、それによって、センサ120が、記録されたイベントをクライアント110に送信し得る接続を提供する。センサ120によるチャープは、クライアント110とのワイヤレス接続を確立する準備ができていることをブロードキャストする。

第1の接続タイムライン430および第2の接続タイムライン440は、それぞれ第1の間隔および第2の間隔を持つ周期的チャーピングを示し、第2の間隔は、第1の間隔のそれよりも小さい。

第1のタイムライン410は、均等に離間した時間期間を示す。たとえば、複数の目盛りのうちの1000と標示された第1の目盛りが、10:00 AMを表し、各目盛りがさらなる分を表す。この例は、数分程度の時間分解能を示すが、センサ120のチャーピング間隔は、以下でさらに説明するように、この時間分解能に限定されない。

イベントタイムライン420は、センサ120による記録されたイベントがクライアント110に送信されるインスタンスを示す。この例示的なイベントタイムライン420では、センサ120は、記録されたイベントの合計3つのインスタンス、すなわちイベント1、イベント2、およびイベント3を有する。イベント1は、10:03.50 AMに発生し、イベント2は、10:06.25に発生し、イベント3は、10:07.50に発生する。

第1の接続タイムライン430は、5分おきにクライアント110と確立されるワイヤレス接続を提供するセンサ120の周期的チャーピングを示す。第1のチャーピング間隔は、2つの隣接するチャープの開始間にdcとして示されている。周期的チャーピングの各チャープは、0.5分の持続時間を有する。イベント1が記録されるときから、チャープ後に形成される接続の間のイベント1の送信までが、イベント1と関連する第1の待ち時間(ΔT1)として示される。同様に、イベント2およびイベント3とそれぞれ関連する第2の待ち時間(ΔT2)および第3の待ち時間(ΔT3)がある。この例では、ΔT1は1.5分、ΔT2は3.75分、ΔT3は2.5分である。クライアント110は、イベント3でセンサ120に対するクライアント110の記憶済みパラメータを更新した後に、イベント2をセンサ120に送信する。したがって、センサ120が短い時間期間内に複数のイベントを記録する環境では、センサ120は、クライアント110に送信されるべき記録されたイベントのキューを有する。

第2の接続タイムライン440は、1分おきにクライアント110と確立されるBluetooth接続を提供するセンサ120の周期的チャーピングを示す。第2のチャーピング間隔は、dc'として示される。周期的チャーピングの各チャープは、0.5分の持続時間を有する。イベント1が記録されるときから、チャープ後に形成される接続の間イベント1の送信までが、改善された第1の待ち時間(ΔT1')として示される。同様に、イベント2およびイベント3、それぞれの改善された第2の待ち時間(ΔT2')および改善された第3の待ち時間(ΔT3')がある。この例では、ΔT1'は0.5分、ΔT2'は0分、ΔT3'は0.5分である。第1の接続タイムライン430からの待ち時間と比較して、イベント1では1分、イベント2では3.75分、イベント3では2分の改善があり、平均してレイテンシが2分平均減少となる。第1の接続タイムライン430との別の相違点は、第2の接続タイムライン440が、各記録されたイベント更新を、センサ120による別のイベントの記録の前に送信することである。一般的に、イベントを記録することと、記録したイベントをクライアント110に送ることとの間のレイテンシの減少を全体的に改善する。これはまた、クライアント110への送信の前に複数のイベントが記録される場合、キューの量を減らす。キューの量のこの減少は、センサ120のコンピューティングメモリを解放する。しかしながら、チャーピング間隔の減少とともに、ある持続時間にわたるチャーピングの増加に起因する電力の増加という、別の考慮すべき要素が生じる。

電力可能性(power feasibility)を維持しながらチャーピング間隔を減らすことを促すのは、Bluetooth Low Energy(商標)(BTLE)などの低エネルギー使用のワイヤレス規格、または処理電力を減らすことを可能にする、ANT Wirelessによる ANT(商標)もしくは ANT+(商標)、近距離無線通信(NFC)、Wi-Fiなどの、別の同様の規格を用いてチャーピングを行うことである。そのような実装形態では、センサ120は、チャープがスモールパケットであることをブロードキャストし、接続に利用可能であると自身をアドバタイズする。いくつかの実施形態では、スモールパケットは、少なくとも一般アクセスプロファイル(Generic Access Profile:GAP)と、デバイス情報とを含む。GAPは、一意のメディアアクセス制御(MAC)アドレス(たとえば、Propeller XX:XX:XX、ここでXX:XX:XXは、MACアドレスの最後の3オクテットである)など、センサ120識別子でセンサ120名を記述する。

デバイス情報は、ファームウェアリビジョン番号、モデル番号など、デバイスを説明するのに役立つ、多くの一般的に必要とされる特性を含んでもよい。たとえば、大量の異なるセンサ120は、各センサ120が他のセンサ120と区別するための特定のモデル番号を有するように、すべてクライアント110と対になり得る。スモールパケットは、単一のチャープを送信するために、センサ120から約0.01〜0.50ワットのバッテリ電力を消費することがある。これは、チャープあたり少なくとも1ワットを必要とする、Bluetooth(商標)など先行電力標準の典型的な電力消費と比較される。図4に示すような、より低電力のチャーピングは、電力消費に関して実現可能な方法で、センサ120とクライアント110との間の通信における待ち時間を大きく減らすことを可能にする。

チャーピング間隔は、分、秒(s)、センチ秒(cs)、またはミリ秒(ms)の単位とすることができる。たとえば、チャーピング間隔は、1ms、5ms、1cs、5cs、10cs、50cs、1s、5s、10s、30s、または1分とすることができる。一般的に、チャーピング間隔は、一定に維持されるが、センサ120は、各一日のうちの様々な部分の間のように、変化する環境に合わせて使用する複数のチャーピング間隔を有してもよい。たとえば、昼間のチャーピング間隔は、ミリ秒単位であってもよいが、夜間のチャーピング間隔は、分または秒単位であってもよい。場合によっては、チャーピング間隔は、一日のうちの様々な部分の間の投薬イベントの可能性に基づいて調整されることがある。別の実装形態では、チャーピング間隔は、クライアント110からセンサ120にパラメータ更新を送信する際にレイテンシを減らすのに役立つ。したがって、夜間にチャーピング間隔をより長くすることは、ユーザが夜にパラメータ更新を送信する可能性が低いと仮定する。

これらの概念は、より高い頻度のまたはより低い頻度のチャーピングが有益であるときについて、他の考えられる想定に広げることができる。たとえば、チャーピング間隔は、天気、花粉、汚染、場所、または他の情報に基づくなどにより、投薬イベントが発生すると予測される可能性が高いときはいつでも、より短くなるように設定され、したがって、投薬イベントが発生すると予測される可能性が低いときはいつでも、より長くなるように設定されてもよい。様々な要因に基づいてリスク通知を予測することの詳細は、参照により本明細書に組み込まれる、米国特許出願第15/724,968号に見つけることができる。より一般的には、チャーピング間隔は、これらの要因のいずれかに基づいて動的であってもよく、または本明細書で説明するように、センサ120のパラメータを更新することによって更新されてもよい。

センサ120とクライアント110との間のより頻繁なチャーピングによって実現される、ワイヤレス接続形成時のレイテンシの削減ができると、センサ120のいくつかの機能の実行可能性が増大する。一実施形態では、より頻繁なチャーピングによって実現される、ワイヤレス接続形成時のレイテンシの削減は、報告されるイベント、更新されるパラメータ、および/または薬剤デバイス位置特定プロトコルの潜在的なキューまたはバックログを減らす。薬剤デバイス位置特定に関して、より頻繁なチャーピングによって実現される、ワイヤレス接続形成時のレイテンシの削減は、クライアントがクライアント110により薬剤デバイスの位置を特定する機能を実現する。これらの追加機能は、処理リソースの割振りを開放し、電力消費量を減らし、したがって、センサ120による処理能力のより効率的な使用を可能にする。これらの追加機能はまた、センサ120との対話でのレイテンシが減少してユーザエクスペリエンスを高める。

チャーピングの応用について、図5〜図8に関してより詳細に説明する。

図5は、一実施形態による、薬剤デバイスセンサ120(センサ120)、クライアントデバイス110(クライアント110)、およびワイヤレス接続モードを説明するフローチャートである。上記のように、センサ120は、単回投与吸入器、または定量吸入器(MDI)などの吸入器型薬剤デバイス160に関連した付属装置として使用されてもよい。センサ120は、薬剤デバイス160による薬剤投与などのイベントを記録する。クライアント110は、センサ120と通信するためにアプリケーション115を実行する。他の機能の中でも、アプリケーション115は、パラメータ更新を通信するために、またはセンサ120から位置情報を要求するために、クライアント110を使用するように構成される。これらの例について、図6〜図8に関してさらに説明する。センサ120は、図4で説明したものと同様のワイヤレスチャーピングモード510と、ワイヤレス接続モード520とを有する。クライアント110は、ワイヤレスブロードキャスティングモード530と、ワイヤレス接続モード540とを有する。センサ120またはクライアント110は、2つのデバイス間でデータ転送の機会が生じるとき、ワイヤレスモード間で送信することができる。図5では、様々なワイヤレスモードのセンサ120およびクライアント110は、Bluetooth Low Energyプロトコルを利用するが、他の実施形態では、低エネルギーのワイヤレス通信規格が実装される場合がある。

センサ120のBluetooth Low Energyチャーピングモード510は、クライアント110に接続可用性を通知するために、低エネルギーパケットで周期的にブロードキャストまたはチャープ570する。このより低電力のチャーピングモード510は、一実施形態により、図4に明示するようなものであってよい。

クライアント110のBluetooth Low Energyブロードキャスティングモード530は、センサ120からチャープ570を受信する。クライアント110のBluetooth Low Energyブロードキャスティングモード530では、クライアント110は、センサ120から周期的にチャープ570を受信する。クライアント110がセンサ120に転送するデータを有するとき、クライアント110は、接続要求575を送信する。

センサ120のBluetooth Low Energy接続モード520およびクライアント110のBluetooth Low Energy接続モード540は、2つのデバイスのBluetooth Low Energy接続を可能にする。センサ120およびクライアント110は、それぞれそれらの対応する低電力接続モード520および540によって接続され、2つのデバイスは、より大きいデータパケットを双方向に転送することができる。図1とともに述べたように、データ転送の前に2つのデバイスを接続することは、パスワード交換または認証プロセスを含むことができる。図6〜図8でさらに説明するように、センサ120は、記録されたイベント、位置情報、および任意の他の情報をクライアント110に送信し580、クライアント110は、パラメータ更新または位置要求をセンサ120に送信する585。

センサ120は、電力使用を効率的に割り振るために、それのBluetooth Low Energyチャーピング510と、それのBluetooth Low Energy接続モード520との間で切り替える。実際には、センサ120は、全体的な電力使用を少なくするために、時間の大部分でBluetooth Low Energyチャーピングモード510のままである。センサ120がイベントを記録するとき、センサ120は、図8とともにさらに説明する、記録されたイベントをオフロードするためにクライアント110との接続を確立するために、それのBluetooth Low Energy接続モード520に切り替える550ことができる。記録されたイベントがクライアント110にオフロードされると、センサ120は、それのBluetooth Low Energyチャーピングモード510に戻る555ことができる。同様にして、センサ120は、クライアント110から接続要求575を受信する場合があり、それによりセンサ120は、それのBluetooth Low Energy接続モード520に切り替える550。それのBluetooth Low Energy接続モード520において、センサ120は、要求された情報585を送信することができる。クライアント110によって要求されたタスクが完了すると、センサ120は、それのBluetooth Low Energyチャーピングモード510に戻る555ことができる。

相補的な方法で、クライアント110は、電力使用を効率的に割り振るために、それのBluetooth Low Energyブロードキャスティングモード530と、それのBluetooth Low Energy接続モード540との間で切り替える。センサ120がオフロードするイベントを記録したとき、Bluetooth Low Energyブロードキャスティングモード530から、クライアント110は、それのBluetooth Low Energy接続モード540に切り替える565ことができる。同様に、クライアント110がセンサ120との接続を要求する場合、クライアント110は、さらなる要求またはパラメータ更新をセンサ120に送信するために、同じくそれのBluetooth Low Energy接続モード540に切り替える565ことができる。送信および受信が完了すると、クライアント110は、それのBluetooth Low Energyブロードキャスティングモード530に戻る565ことができる。

図6は、一実施形態による、ワイヤレス接続を形成するより前に、クライアントデバイス110に周期的にチャープすることにより薬剤デバイスセンサ120のパラメータ600を更新することを説明するフローチャートである。図4および図5で言及した薬剤デバイスセンサ120(図中では「センサ」と呼ぶ)は、クライアントデバイス110(図中では「クライアント」と呼ぶ)に周期的にチャープする610ためにBluetooth Low Energyを利用してもよい。周期的チャープは、図4および図5でチャーピングとして説明したものと同様である。クライアント110は、周期的チャーピングを受信すると、クライアント110は、接続を開始するために応答してもよい。

クライアント110は、センサ120に送信されることになるパラメータ更新の少なくとも1つのセットがあるか否かを決定する620。そうである場合、クライアント110は、センサ120とのBluetooth接続を開始する625。センサ120およびクライアント110が、Bluetooth Low Energyのために、場合によっては認証方式を使用して接続された後、クライアント110は、パラメータ更新の少なくとも1つのセットをセンサ120に送信する630。センサ120は、パラメータ更新のセットを受信する635。

パラメータ更新の1つまたは複数のセットを受信すると、センサ120は、パラメータ更新の1つまたは複数のセットに従って、それのパラメータを更新する640。次いで、センサ120は、センサ120上の更新されたパラメータの確認を送信する645。クライアント110は、確認を受信し660、パラメータ更新のセットをクリアしてもよい。最後に、クライアント110は、Bluetooth接続を終了し665、したがってセンサ120を、図5とともに説明したように、Bluetooth Low Energyチャーピングモード510などのチャーピングに戻す。

クライアント110は、センサ120のための様々なパラメータを更新することができる。例には、限定はしないが、ファームウェア更新、およびクライアント固有の更新が含まれる。更新のためのパラメータのソースは、パラメータのタイプに関係していてもよい。たとえば、ファームウェア更新は、一般に、更新を提供するサーバからクライアント110によって受信される。クライアント110は、いくつかのタイプのクライアント固有のパラメータの更新をユーザに促してもよい。いくつかの実施形態では、クライアント110は、ディスプレイカード310がユーザにパラメータ更新を促すことができるように、図3のダッシュボード300を表示するモバイルデバイス上のアプリケーション115であることがある。クライアント110のユーザは、ダッシュボードの入力応答315に応答を入力することができる。更新されたパラメータは、次いで、センサ120への送信の前に、クライアント110でログ記録され得る。一例では、ユーザが、カスタム着信音または薬剤使用リマインダなど、センサ120によって遂行される様々なタスクのために通知を設定してもよい。

図7は、一実施形態による、ワイヤレス接続を形成するより前に、ワイヤレス接続によりクライアントデバイス110に周期的にチャープすることによって薬剤デバイスセンサ120の位置を特定するためのプロセスを説明するフローチャートである。図4および図5で言及した薬剤デバイスセンサ120(図中では「センサ」と呼ぶ)は、クライアントデバイス110(図5〜図8では単に「クライアント」と呼ぶ)に周期的にチャープする710ためにBluetooth Low Energyを利用する。周期的チャープは、図4および図5でチャーピングとして説明したものと同様である。クライアント110は、周期的チャーピングを受信すると、クライアント110は、接続を開始するために応答してもよい。クライアント110は、センサ120の位置を特定するための開始された要求があるか否かを決定する720。この説明では、開始された要求は、クライアント110上に記憶された「Find My Inhaler」プロトコルの一部であり、開始されると、「Find My Inhaler」プロトコルは、クライアント110とセンサ120との間で以下のステップを実行する。センサ120の位置を特定するための開始された要求がある場合、クライアント110は、センサ120とのBluetooth接続を開始する725。センサ120およびクライアント110が互いに接続された後、クライアント110は、センサ120の位置情報の要求を送信する730。センサ120は、センサ120の位置情報の要求を受信する735。

センサ120の位置情報の要求を受信すると、センサ120は、それの位置情報を決定する740。たとえば、センサ120は、センサ120が位置情報の要求を受信するとき、センサ120がそれのGPS座標を日付および時間とともに記録することができるように、GPS受信機を含んでもよい。位置情報の要求を受信すると、センサ120は追加として、センサ120の位置を特定する際に物理的近傍のユーザに役立つように、センサ120上のラウドスピーカまたは同様のオーディオ再生ユニットから、オーディオチューンを再生してもよい。センサ120は、決定された位置情報をクライアント110に送信する745。クライアント110は、位置情報を受信し750、たとえば、ダッシュボード300を介して、位置情報をユーザに提供する755。クライアント110は、Bluetooth接続を終了し760、したがってセンサ120を、図5とともに説明したように、Bluetooth Low Energyチャーピングモード510などのチャーピングに戻す。

図8は、一実施形態による、ワイヤレス接続により薬剤デバイスセンサ120(センサ120)からクライアントデバイス110(クライアント110)に、記録された事象を送信するためのフローチャート800である。薬剤使用イベントを記録したセンサ120は、クライアント110とのペアリングを要求する。クライアント110との接続の要求は、調整されるチャーピング間隔をより小さくして、周期的にチャープされてもよい。クライアント110が接続の要求とともにチャープを受信すると、クライアント110は、ワイヤレス接続を形成し810てもよい。センサ120とクライアント110との間でワイヤレス接続を形成する810と、センサ120は、保留中のイベントレコードをクライアント110に送信する815。クライアント110は、イベントレコードを受信する820。クライアント110は、新しいイベントレコードまたはnullイベントレコードがあるかどうかを決定する825。ない場合、クライアント110は、センサ120からの新しいイベントレコードを待つ。ある場合、クライアント110は、イベントレコードをセンサ120にエコーバックし830、クライアント110は、イベントレコードがnullイベントレコードであるかどうかを決定する845。nullイベントレコードは、送信されるさらなる保留中のイベントレコードがないことを表す。センサ120は、エコーを受信し、エコーが送信されたイベントレコードに一致するかどうかを決定する835。一致しない場合、センサ120は、保留中のイベントレコードを再送信する815。一致する場合、センサ120は、次のイベントレコードまたはnullイベントレコードをフェッチする840。センサ120は、フェッチされた次のイベントレコードまたはフェッチされたnullレコードを送信する815。クライアント110が、受信されたイベントレコードがnullであるかどうかを決定する845と、そうである場合、クライアント110は、送信を終了する860。そうでない場合、クライアント110は、別のイベントレコードを待つ。接続を終了して、センサ120は、図5とともに説明したように、Bluetooth Low Energyチャーピングモード510などのチャーピングに戻る。

VII.追加の考慮事項
上記の説明は、特に喘息に焦点を合わせているが、本明細書で説明するすべてのシステムおよびプロセスは、慢性閉塞性肺疾患(COPD)および慢性呼吸器疾患(CRD)に広く適用可能であり、結果としてCOPDおよびCRD、ならびに喘息の治療に役立つように使用することもできる。

本開示の図および説明は、本開示の明確な理解を目指して、関連のある要素を説明するために簡略化されており、明快のために、典型的なシステムにおいて見られる多くの他の要素を省いていることを理解されたい。本開示を実施する際に、他の要素および/またはステップが望ましいおよび/または必要とされることを、当業者には認識されよう。しかしながら、そのような要素およびステップは当技術分野でよく知られているので、またそれらは本開示のより良い理解の助けとならないので、そのような要素およびステップの説明は、本明細書では行わない。本明細書の開示は、当業者に知られている要素および方法に対する変形形態および変更形態すべてを対象とする。

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

本明細書で使用する「1つの実施形態」または「一実施形態」への言及は、その実施形態に関連して説明する特定の要素、機能、構造、または特徴が、少なくとも1つの実施形態に含まれることを意味する。本明細書の様々な箇所での「一実施形態では」という語句の出現は、必ずしもすべて同じ実施形態を指しているとは限らない。

本明細書で使用する「備える」、「備えている」、「含む」、「含んでいる」、「有する」、「有している」、またはそれらの他の様々な変形は、非排他的含有を含めるよう意図されている。たとえば、要素のリストを含むプロセス、方法、物品、または装置は、必ずしもそれらの要素のみに限定されるとは限らず、明示的に列記されない、またはそのようなプロセス、方法、物品、もしくは装置に固有の、他の要素を含む場合がある。さらに、それとは反対に明示的に記述がない限り、「または」は包含的またはを指し、排他的またはではない。たとえば、条件AまたはBは、以下のうちのいずれか1つによって満たされる。Aは真であり(または存在し)、かつBは偽である(または存在しない)、Aは偽であり(または存在せず)、かつBは真である、およびAとBの両方が真である(または存在する)。

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

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

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 入力応答

Claims (20)

1. クライアントデバイスへのワイヤレス接続により、医療用吸入器センサ上のパラメータを更新するためのコンピュータ実装方法であって、
   前記クライアントデバイス上に前記医療用吸入器センサの複数のパラメータを記憶するステップであって、前記医療用吸入器センサが、患者と関連する医療用吸入器と物理的に結合される、記憶するステップと、
   前記複数のパラメータのうちの1つまたは複数のパラメータを更新するステップと、
   前記クライアントデバイスで、前記医療用吸入器センサから複数のpingを受信するステップであって、前記pingが、前記pingの連続したものを分けるping間隔で周期的に受信される、受信するステップと、
   前記クライアントデバイスで前記pingの1つを受信したことに応答して、前記クライアントデバイスを用いて、前記医療用吸入器センサと前記クライアントデバイスとの間で前記ワイヤレス接続を形成するステップと、
   前記ワイヤレス接続により、前記更新されたパラメータを前記医療用吸入器センサに送信するステップと、
   前記更新されたパラメータの受信を確認する、前記医療用吸入器センサからの応答、および第1のイベントレコードを受信するステップであって、前記第1のイベントレコードが、前記医療用吸入器センサによって記録された前記医療用吸入器による薬剤投与の第1のインスタンスを記述する、受信するステップと、
   前記第1のイベントレコードのエコーを前記医療用吸入器センサに送信するステップと、
   前記クライアントデバイスで、第2のイベントレコードを受信するステップと、
   前記第2のイベントレコードがnullイベントレコードであるかどうかを決定するステップと、
   前記第2のイベントレコードがnullイベントレコードであるとの決定に応答して、前記ワイヤレス接続を終了するステップと
   を含む、コンピュータ実装方法。
2. 前記ワイヤレス接続が、Bluetooth Low Energy接続である、請求項1に記載のコンピュータ実装方法。
3. 前記ping間隔が、1秒〜60秒である、請求項1に記載のコンピュータ実装方法。
4. 前記ping間隔が、1秒〜15秒である、請求項1に記載のコンピュータ実装方法。
5. 前記ping間隔が、10センチ秒〜100センチ秒である、請求項1に記載のコンピュータ実装方法。
6. 前記ping間隔が、10ミリ秒〜100ミリ秒である、請求項1に記載のコンピュータ実装方法。
7. 前記複数のパラメータのうちの1つまたは複数のパラメータを更新するステップが自動である、請求項1に記載のコンピュータ実装方法。
8. 前記複数のパラメータのうちの1つまたは複数のパラメータを更新するステップが、
   前記クライアントデバイスのグラフィカルユーザインターフェースを介して表示するために、前記1つまたは複数のパラメータを更新するオプションを提供するステップと、
   前記グラフィカルユーザインターフェースを介してユーザからの入力として、前記更新された1つまたは複数のパラメータを受信するステップと
   を含む、請求項1に記載のコンピュータ実装方法。
9. ユーザが、患者、患者の家族、および患者の医療提供者から成る群から選択される、請求項8に記載のコンピュータ実装方法。
10. 前記1つまたは複数の更新されたパラメータのうちの1つの更新されたパラメータが、前記医療用吸入器センサのオーディオデバイスにより再生するための着信音を含む、請求項8に記載のコンピュータ実装方法。
11. 前記パラメータのうちの1つまたは複数を更新するステップが、
    前記クライアントデバイスを用いて、前記医療用吸入器センサのためのパラメータ更新を記憶するサーバとの接続を形成するステップと、
    前記更新された1つまたは複数のパラメータを前記サーバから受信するステップと
    を含む、請求項1に記載のコンピュータ実装方法。
12. 前記応答が、前記医療用吸入器センサの地理座標を含む、請求項1に記載のコンピュータ実装方法。
13. クライアントデバイスへのワイヤレス接続により、医療用吸入器センサ上のイベントレコードを送信するためのコンピュータ実装方法であって、
    医療用吸入器に取り付けられた前記医療用吸入器センサによって、前記医療用吸入器からの薬剤投与の第1のインスタンスを一連のイベントレコードの第1のイベントレコードとして記録するステップと、
    前記クライアントデバイスにpingを送信するステップであって、前記pingが前記クライアントデバイスとの前記ワイヤレス接続を形成するよう要求する、送信するステップと、
    前記送信されたpingに応答して前記クライアントデバイスから接続要求を受信するステップと、
    前記受信された接続要求に応答して、前記クライアントデバイスとの前記ワイヤレス接続を形成するステップと、
    前記クライアントデバイスへの前記第1のイベントレコードを、前記クライアントデバイスに送信するステップと、
    前記第1のイベントレコードの前記クライアントデバイスからのエコーを、前記クライアントデバイスから受信するステップと、
    前記エコーが前記第1のイベントレコードに一致するかどうかを決定するステップと、
    前記エコーが前記第1のイベントレコードに一致するとの決定に応答して、次のイベントレコードが前記一連のイベントレコードに存在するかどうかを決定するステップと、
    前記次のイベントレコードが存在しないとの決定に応答して、前記クライアントデバイスにnullイベントレコードを送信するステップと
    を含む、コンピュータ実装方法。
14. 各イベントレコードが、薬剤投与の前記インスタンスの時間、前記医療用吸入器センサのバッテリ寿命、記録されたイベントのタイプ、温度、および薬剤投与の前記インスタンスの数値識別子から成る群から選択される情報を含む、請求項13に記載のコンピュータ実装方法。
15. 前記ワイヤレス接続が、Bluetooth接続である、請求項13に記載のコンピュータ実装方法。
16. クライアントデバイスへのpingの送信が、前記第1のイベントレコードの記録の直後に行われる、請求項13に記載のコンピュータ実装方法。
17. 前記医療用吸入器センサによって、前記医療用吸入器からの薬剤投与の第2のインスタンスを、第2のイベントレコードとして記録するステップであって、前記第2のイベントレコードが、前記一連のイベントレコードにおける前記次のイベントレコードである、記録するステップと、
    前記次のイベントレコードが存在するとの決定に応答して、前記クライアントデバイスに前記第2のイベントレコードを送信するステップと
    をさらに含む、請求項13に記載のコンピュータ実装方法。
18. クライアントデバイスへのワイヤレス接続により、医療用吸入器センサ上のパラメータを更新するための命令を含む、非一時的コンピュータ可読記憶媒体であって、前記命令が、プロセッサによって実行されると、前記プロセッサに、
    前記クライアントデバイス上に前記医療用吸入器センサの複数のパラメータを記憶するステップであって、前記医療用吸入器センサが、患者と関連する医療用吸入器と物理的に結合される、記憶するステップと、
    前記複数のパラメータのうちの1つまたは複数のパラメータを更新するステップと、
    前記クライアントデバイスで、前記医療用吸入器センサから複数のpingを受信するステップであって、前記pingが、前記pingの連続したものを分けるping間隔で周期的に受信される、受信するステップと、
    前記クライアントデバイスで前記pingの1つを受信したことに応答して、前記クライアントデバイスを用いて、前記医療用吸入器センサと前記クライアントデバイスとの間で前記ワイヤレス接続を形成するステップと、
    前記ワイヤレス接続により、前記更新されたパラメータを前記医療用吸入器センサに送信するステップと、
    前記更新されたパラメータの受信を確認する、前記医療用吸入器センサからの応答、および第1のイベントレコードを受信するステップであって、前記第1のイベントレコードが、前記医療用吸入器センサによって記録された前記医療用吸入器による薬剤投与の第1のインスタンスを記述する、受信するステップと、
    前記第1のイベントレコードのエコーを前記医療用吸入器センサに送信するステップと、
    前記クライアントデバイスで、第2のイベントレコードを受信するステップと、
    前記第2のイベントレコードがnullイベントレコードであるかどうかを決定するステップと、
    前記第2のイベントレコードがnullイベントレコードであるとの決定に応答して、前記ワイヤレス接続を終了するステップと
    を含むステップを行わせる、記憶媒体。
19. 前記複数のパラメータのうちの1つまたは複数のパラメータを更新するステップが自動である、請求項18に記載の記憶媒体。
20. 前記複数のパラメータのうちの1つまたは複数のパラメータを更新するステップが、
    前記クライアントデバイスのグラフィカルユーザインターフェースを介して表示するために、前記1つまたは複数のパラメータを更新するオプションを提供するステップと、
    前記グラフィカルユーザインターフェースを介してユーザからの入力として、前記更新された1つまたは複数のパラメータを受信するステップと
    を含む、請求項18に記載の記憶媒体。

Images