特表 2023-524275 生物製剤に適した患者サブグループを識別するシステム及び方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-06-09

(54)【発明の名称】生物製剤に適した患者サブグループを識別するシステム及び方法

(51)【国際特許分類】

   G16H 20/13 20180101AFI20230602BHJP

【ＦＩ】

G16H20/13

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022566728

(86)(22)【出願日】2021-04-30

(85)【翻訳文提出日】2022-12-20

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

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

(87)【国際公開日】2021-11-04

(31)【優先権主張番号】63/018,695

(32)【優先日】2020-05-01

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】522043611

【氏名又は名称】レシプロカル ラボ コーポレイション

(74)【代理人】

【識別番号】110001519

【氏名又は名称】弁理士法人太陽国際特許事務所

(72)【発明者】

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

(72)【発明者】

【氏名】スラヴィンスキー、サード、ジョーセフ

(72)【発明者】

【氏名】バレット、メレディス、アン

(72)【発明者】

【氏名】ゴンダリア、ラフル、バイラル

(72)【発明者】

【氏名】ケイ、リアン

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

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】

前記コンピュータプログラム製品は、非一時的なコンピュータ可読媒体である、請求項２７に記載のコンピュータプログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０２０年５月１日出願の米国仮出願第６３／０１８，６９５号の優先権及び利益を主張するものであり、その開示全体を本明細書に参照として援用する。

【0002】

本開示は、一般に、潜在的な呼吸器疾患を有する患者の治療を改善する方法、より具体的には、生物製剤治療のための適切な患者サブグループを決定する方法に関する。

【背景技術】

【0003】

喘息などの呼吸器疾患は、依然として重要であり、かつコストのかかる公衆衛生上の問題である。例えば、米国において、２，２００万人以上が喘息にかかっている。世界中で、世界保健機関は、喘息患者の人口が２億３，５００万人であると推定しており、将来的に増加すると予測している。同様に、疾病管理予防センターによる最近の研究において、ＣＯＰＤは、米国の死因の第３位に挙げられており、推定１，５００万人近くが、肺機能の障害を誘発するＣＯＰＤを有し得る（Ａ．Ｇ．Ｗｈｅａｔｏｎ、Ｔ．Ｊ．Ｃｕｎｎｉｎｇｈａｍ、Ｅ．Ｓ．Ｆｏｒｄ、Ｊ．Ｂ．Ｃｒｏｆｔ、「慢性閉塞性肺疾患を有する成人における雇用及び活動制限－米国、２０１３年」、ＭＭＷＲ Ｍｏｒｂ． Ｍｏｒｔａｌ Ｗｋｌｙ． Ｒｅｐ．、２０１５、６４（１１）、ｐ．２９０－２９５）。

【0004】

新薬の開発にもかかわらず、入院率及び緊急治療室の入室率は低下していない。米国では毎年、喘息により約２００万人が救急外来を受診し、５０万人が入院し、５，０００人が死亡している。また、喘息は、推定して５２０万日の学校欠席、及び８７０万日の欠勤の原因となっている（Ｔ．Ｎｕｒｍａｇａｍｂｅｔｏｖ、Ｒ．Ｋｕｗａｈａｒａ、Ｐ．Ｇａｒｂｅ、「米国における喘息の経済的負担、２００８－２０１３」、Ａｎｎ． Ａｍ． Ｔｈｏｒａｃ． Ｓｏｃ．、２０１８、１５（３）、ｐ．３４８－３５６）。米国の健康保険会社及び雇用主の総年間コストは、８２０億米ドルを超える（同上）。ＣＯＰＤにより、年間、約７１５，０００人が入院し、１３４，０００人が死亡している。加えて、ＣＯＰＤに対する国家のコストは、最近、直接的な医療費の２９５億米ドル、間接的な罹患コストの８０億米ドル、及び間接的な死亡費用の１２４億米ドルを含む、約４９９億米ドルと予測されている。

【0005】

喘息の悪化の多くは、現在利用可能な治療で予防され得るが、喘息患者の５人に１人しか病気をコントロールできていない。このような治療は、喘息状態のトリガ条件を識別し、薬剤などの治療を適切に行うことに頼っていることが多い。患者が薬剤を自己投与するためのメカニズムの１つは、吸入器である。トリガ事象が発生したとき、患者は、吸入器からのパフを介して薬剤を投与し得る。

【0006】

改訂された国内ガイドラインは、喘息に対して処方された治療が、日常の症状をコントロールし、生活の質を改善しているかどうかをより綿密に監視するように医師に求めている。医療提供者は、しかしながら、患者が日常的にどの程度うまくやっているかを評価するためのツールの可用性によって制限されている。ますます多くの内科医が、患者を監視し、コントロールのレベルを判断するために、定期的な書面による質問事項（例えば、喘息コントロール試験（ＡＣＴ））を使用し始めている。これらの器具では、患者は、症状の頻度、薬剤デバイス（例えば、吸入器）の使用、並びに活動レベル及び制限を、一定期間、通常は２～４週間にわたって、正確に思い出して報告する必要がある。その結果、呼吸器疾患の管理に関する収集された情報は、バイアス（例えば、誤った記憶）、症状の異なる解釈、及び行動（例えば、非遵守）によってもたらされる誤差を受け、データの有用性が限られたものとなるように、データ収集の頻度が非常に制限される。

【0007】

標準的なレスキュー吸入薬剤が特定の呼吸器疾患に無効性であり得る場合がまれにある。刺激的な新しい治療の１つは、重度の呼吸器疾患、特に喘息の治療に対して、呼吸空間での生物製剤の使用である。生物製剤は、生物源において製造、抽出、又は半合成された医薬品である。「生物製剤」という用語は、本明細書において、生物学に基づいた治療又は療法を指すのに使用され、そのため、生物学に基づいた医療品、又は医薬品を包含する。生物製剤の処方に関する課題は、それらが高価であり、投与治療のために、自己投与又は介護提供者への訪問のいずれかを必要とすることである。血中及び喀痰中の好酸球数などの多くの要因に依存するため、どのタイプの効果的な生物製剤が投与され得るかを評価することも困難である。したがって、医療従事者は、生物製剤を正しい患者集団に投与するという課題に直面している。

【0008】

生物製剤を投与する患者グループの効率的な選択を可能にするシステムが必要とされている。効率的な生物製剤適用に対する患者のサブグループの承認を識別及び支援するために、喘息のコントローラ及びレスキュー薬剤の使用に基づくデータの収集を可能にするシステムがさらに必要とされている。患者が生物製剤を投与されている間、レスキュー薬剤の使用、及びコントローラ薬剤の遵守を介する症状の監視も必要とされている。

【発明の概要】

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

【0009】

開示された一例は、呼吸器疾患の増強治療の適合性を決定するためのシステムである。システムは、呼吸薬剤デバイスの使用データを収集してコントローラ又はレスキュー呼吸薬剤を患者に送達するための通信インターフェースを含む。システムは、収集された使用データを格納するための記憶デバイスを含む。データ分析モジュールは、収集された使用データに基づいて、患者が呼吸薬剤デバイスの使用において遵守の第１の閾値レベルを超えているかどうかを判断するように動作可能である。モジュールは、収集された使用データに基づいて、患者が第２の閾値レベルを超えてレスキュー呼吸薬剤を使用しているかどうかを判断する。モジュールは、患者が第１の閾値及び第２の閾値を超えている場合、増強治療を勧告する通知を提供する。

【0010】

例示的なシステムのさらなる実装形態は、呼吸器疾患が喘息である場合である。別の実装形態は、増強治療が生物学に基づいた治療又は療法の処方である場合である。別の実装形態は、第１の閾値が、少なくとも約７０％、７５％、８０％、又は８５％の遵守など、少なくとも約６５％の遵守の遵守率である場合である。一実装形態において、第１の閾値は、少なくとも約７５％の遵守率である。別の実装形態は、第２の閾値が、１週間にわたって少なくとも約２２回又は２８回のレスキュー薬剤の使用など、１週間にわたって少なくとも約１５回のレスキュー薬剤の使用である場合である。一実装形態において、第２の閾値は、１週間にわたって少なくとも約２８回のレスキュー薬剤の使用である。別の実装形態は、システムがモバイルコンピューティングデバイスを含み、モバイルコンピューティングデバイスが記憶デバイス及び通信インターフェースと通信している場合である。別の実装形態は、モバイルコンピューティングデバイスが、患者の増強治療の適用を支援するアプリケーションを含む場合である。別の実装形態は、通知が、患者、介護者、又は医療提供者のうちの１者に電子的に提供される場合である。別の実装形態は、システムが、モバイルコンピューティングデバイスと通信している増強治療モジュールエンジンを含む場合である。増強治療モジュールは、患者による増強治療の使用を追跡するように動作可能である。別の実装形態は、増強治療モジュールが、患者に対して追加の増強治療を指図するように動作可能である場合である。別の実装形態は、増強治療が、注射可能な生物製剤の処方である場合である。アプリケーションは、少なくとも１つの注射技術について患者を指導するためのインターフェースを含む。別の実装形態は、インターフェースが生物製剤の注射領域を記録するインターフェースを含む場合である。別の実装形態は、システムが、患者を監視するための健康モニタを含む場合である。データ分析モジュールは、健康モニタからデータを収集して、増強治療に対する患者の反応を決定する。

【0011】

別の開示された例は、患者が呼吸器疾患の増強治療を受けるべきかどうかを判断する方法である。コントローラ又はレスキュー呼吸薬剤を患者に送達するための呼吸薬剤デバイスの使用データは、通信インターフェースを介して収集される。使用データは記憶デバイスに送信される。使用データは、データ分析モジュールにアクセス可能な記憶デバイスに格納される。呼吸薬剤デバイスの使用において、患者が遵守の第１の閾値レベルを超えているかどうかが、収集された使用データに基づいて判断される。患者が、第２の閾値レベルを超えてレスキュー呼吸薬剤を使用しているかどうかが、収集された使用データに基づいて判断される。患者が第１の閾値及び第２の閾値を超えている場合、増強治療を勧告する通知が提供される。

【0012】

例示的な方法のさらなる実装形態は、呼吸器疾患が喘息である場合である。別の実装形態は、増強治療が生物学に基づいた治療又は療法の処方である場合である。別の実装形態は、第１の閾値が、少なくとも約７０％、７５％、８０％、又は８５％の遵守など、少なくとも約６５％の遵守の遵守率である場合である。一実装形態において、第１の閾値は、少なくとも約７５％の遵守率である。別の実装形態は、第２の閾値が、１週間にわたって少なくとも約２２回又は２８回のレスキュー薬剤の使用など、１週間にわたって少なくとも約１５回のレスキュー薬剤の使用である場合である。一実装形態において、第２の閾値は、１週間にわたって少なくとも約２８回のレスキュー薬剤の使用である。別の実装形態は、方法が、記憶デバイス及び通信インターフェースを有するモバイルコンピューティングデバイスへの通信を確立することを含む場合である。別の実装形態は、モバイルコンピューティングデバイスが、患者の増強治療の適用を支援するアプリケーションを含む場合である。別の実装形態は、通知が、患者、介護者、又は医療提供者のうちの１者に電子的に提供される場合である。別の実装形態は、方法が、患者による増強治療の使用を追跡することを含む場合である。別の実装形態は、増強治療モジュールが、患者に対して追加の増強治療を指図するように動作可能である場合である。別の実装形態は、増強治療が、注射可能な生物製剤の処方である場合である。アプリケーションは、少なくとも１つの注射技術について患者を指導するためのインターフェースを含む。別の実装形態は、インターフェースが生物製剤の注射領域を記録するインターフェースを含む場合である。別の実装形態は、方法が、患者を監視するための健康モニタを介して患者を監視することを含む場合である。方法は、健康モニタからデータを収集して、増強治療に対する患者の反応を決定することも含む。

【0013】

上記の概要は、本開示の各実施形態又は全ての態様を表すことを意図するものではない。むしろ、前述の概要は、本明細書に記載された新規の態様及び特徴のいくつかの例を提供するに過ぎない。本開示の上記の特徴及び利点、並びに他の特徴及び利点は、添付の図面及び添付の特許請求の範囲と関連する際に、本発明を実施するための代表的な実施形態及びモードの以下の詳細な説明から容易に明らかであろう。

【0014】

本開示は、添付の図面を共に参照して、例示的な実施形態の以下の説明からよりよく理解されるであろう。

【図面の簡単な説明】

【0015】

【図1】正確なリアルタイムの薬剤デバイスの使用を監視し、そのデータに対する分析を実行し、増強治療の対象となり得る患者の分析を提供するための呼吸器疾患分析システムを示している。

【図2】クライアントデバイス、アプリケーションサーバ、及び／又はデータベースサーバのいずれかとして使用されるコンピューティングデバイスの例を示すハイレベルブロック図である。

【図3】生物製剤のためのサブグループを決定するための患者グループのグラフである。

【図4】増強治療の承認のために収集されたデータから作成され得る例示的なフォームの画面画像を示している。

【図5】患者が生物製剤の注射を報告するための例示的なアプリケーションによって生成された画面画像を示している。

【図6A】電子薬剤モニタを使用して所与の患者集団からの転帰を実証するために使用され得る、患者集団転帰グラフの画面画像を示している。

【図6B】電子薬剤モニタを使用した患者集団のレスキューパフに関連付けられた遵守の表である。

【図7】薬剤データの収集に基づいた患者サブグループの選択のプロセスフロー図である。

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

【0016】

本開示は、様々な修正及び代替形態が可能である。いくつかの代表的な実施形態は、例として図面に示され、本明細書で詳細に説明される。しかしながら、本発明は、開示された特定の形態に限定されることを意図していないことを理解されたい。むしろ、本開示は、添付の特許請求の範囲によって定義される本発明の精神及び範囲内にあるすべての修正、均等物、及び代替を包含するものである。

【0017】

本発明は、多くの異なる形態で具現され得る。代表的な実施形態は、図面に示され、本明細書で詳細に説明されよう。本開示は、本開示の原理の例又は例示であり、本開示の広範な態様を示される実施形態に限定することを意図するものではない。その分、例えば、要約書、発明の概要、及び発明を実施するための形態、のセクションで開示されているが、特許請求の範囲に明示的に記載されていない要素及び制限は、黙示、推論、又はその他の方法で、単独で、又はまとめて、請求の範囲に組み込まれるべきではない。本詳細な説明の目的のために、特に断りのない限り、単数形は複数形を含み、その逆も同様である。また、「含む」という単語は、「限定なく含む」を意味する。さらに、「約」、「ほとんど」、「実質的に」、「おおよそ」などの近似の単語は、本明細書において、「～に」、「～付近に」、若しくは「～のほぼ付近に」、又は、例えば、「～の３～５％以内」若しくは「許容し得る製造公差内」、又はそれらの任意の論理的組み合わせを意味するように使用され得る。

【0018】

本開示は、レスキュー吸入器の使用及びコントローラ薬剤遵守の個人レベルのパターンに関するデータを収集するシステムに関する。データは、生物製剤治療を使用した潜在的関与のために、喘息などの呼吸器疾患の患者のサブグループを識別して説明するように使用されてよい。このような患者のサブグループは、レスキュー薬剤より他のさらなる治療が必要な患者や、処方された生物製剤治療を一番遵守しそうな患者を含む。

【0019】

図１は、正確なリアルタイムの薬剤デバイス事象を監視し、そのデータに対して分析を実行し、一般患者集団に関連する一次患者に対するトリガの識別に基づいて呼吸器疾患悪化リスク通知を提供するための、一実施形態に記載の呼吸器疾患分析システム１００を示す。このような呼吸器疾患は、吸入器による薬剤の迅速な治療を通して対処され得る喘息事象であってよい。

【0020】

呼吸器疾患分析システムは、クライアントコンピューティングデバイス１１０、薬剤デバイスセンサ１２０、薬剤デバイス１６０、アプリケーションサーバ１３０、データベースサーバ１４０、及びネットワーク１５０を含む。医療提供者サーバ１７０及び医薬品供給サーバ１８０などの他のサーバは、ネットワーク１５０に結合されてよい。図１は、呼吸器疾患分析システム１００のほとんどのコンポーネントが単一の場合のみを示しているが、実際には、２つ以上の各コンポーネントが存在してよく、追加の又はより少数のコンポーネントが使用されてよい。

【0021】

クライアントデバイス１１０は、それらのユーザの要請を受けて、ネットワーク１５０を介して呼吸器疾患分析システム１００と対話する。説明及び明確化の目的のために、少なくとも２つの異なるタイプのユーザを識別するのに有用である。患者１１１は、呼吸器疾患分析システム１００を少なくとも部分的に利用して、サーバ１３０によって提供される個人化されたレスキュー事象リスクの通知と、この例においては医療提供者１１２によって作成された管理通知とを取得する、喘息などの呼吸器疾患を患っているユーザである。患者１１１は、追加の又は代替のユーザである介護者によって支援されてよい。介護者は、患者１１１と同じ通知を受信する（図１には図示せず）、又は患者の代理として通知を受信する自己のアプリケーション１１５及びクライアントデバイス１１０を有してよい（例えば、自己のクライアントデバイス１１０が彼らの子供のものと異なる事象において通知を受信することを望み得る、患者１１１の親／保護者）。このような通知は、呼吸器疾患分析システム１００が、患者１１１の薬剤デバイス１６０の使用を監視するのを可能にするために、ユーザの許可と引き換えに提供され得る。以下に説明されるように、薬剤事象は、薬剤デバイス１６０及びユーザのクライアントデバイス１１０に関連付けられたセンサ１２０によって検出され、次に、アプリケーションサーバ１３０に報告され、次に、クライアントデバイス１１０を通してユーザに提供されるリスク通知を生成するプロセスが開始され得る。この例において、患者１１１は、グループ内の各患者について個々のデータが取得される患者集団を表す。

【0022】

別のタイプのユーザは、また患者１１１の明示的な許可を得て、患者の喘息管理に関する通知も、集計された喘息コミュニティのレスキュー事象データ並びに喘息事象及び他の関連データに関する派生した統計も受信する、医療提供者１１２である。他のタイプのユーザが考えられてもよい。

【0023】

クライアントデバイス１１０は、スマートフォン、タブレット、又はラップトップなどの携帯用コンピューティングデバイスであり得るコンピュータシステムである。クライアントデバイス１１０は、テレビ（例えば、スマートな接続されたテレビ）又はスピーカシステム（例えば、スマートな接続されたスピーカ）であってもよい。例示的な物理的実装形態が、図２に関して以下により完全に記載される。クライアントデバイス１１０は、ネットワーク１５０を介して呼吸器疾患分析システム１００と無線通信するように構成されている。ネットワーク１５０にアクセスすると、クライアントデバイス１１０は、薬剤使用事象の時間も、関連する薬剤デバイスセンサ１２０（全体を通して「センサ１２０」という）から受信した事象を記載する情報も、システム１００に送信する。ユーザの地理的位置は、呼吸器疾患分析システム１００に送信されてもよい。

【0024】

ユーザの位置及び事象の時間に関して、クライアントデバイス１１０は、それが接続されているセル方式又は無線ネットワーク１５０に関する情報を使用して、レスキュー事象の地理的位置及び時間を判断し得る。例えば、クライアントデバイス１１０の現在の地理的位置は、ネットワーク１５０接続を提供するソフトウェアスタックに直接問い合わせることによって判断されてよい。代わりに、地理的位置情報は、ネットワーク１５０を介してアクセス可能にされた外部ウェブサービス（図１には示さず）にｐｉｎｇを実行することによって取得されてよい。事象の時間は、事象データの一部としてセンサ１２０によって提供され得る、又はクライアントデバイスのネイティブオペレーティングシステムの一部として利用可能な適切なソフトウェアルーチンに問い合わせることによって事象データに追加され得る。

【0025】

アプリケーションサーバ１３０との通信に加えて、呼吸器疾患分析システム１００に無線接続されたクライアントデバイス１１０は、他の接続されたクライアントデバイス１１０と情報を交換してもよい。例えば、クライアントソフトウェアアプリケーション１１５を通して、医療提供者１１２又は介護者は、患者１１１に関する最近のレスキュー事象を記載するリスク悪化通知を受信し、それに応答して、喘息レスキュー事象後の治療のために勧告を患者１１１に送信し得る。同様に、アプリケーション１１５を通して、患者１１１は、医療提供者１１２及び他の患者１１１、又は介護者と通信し得る。

【0026】

アプリケーション１１５は、クライアントデバイス１１０の画面上に表示され、ユーザがコマンドを入力してアプリケーション１１５の動作を制御できるようにするユーザインターフェース（本明細書では、「ダッシュボード」という）を提供する。ダッシュボードは、医療提供者１１２、介護者、及び患者１１１が呼吸器疾患分析システム１００にアクセスするメカニズムである。例えば、ダッシュボードは、患者１１１、介護者、及び提供者１１２が、互いに対話し、喘息レスキュー事象リスク通知を受信し、治療に関するメッセージを交換し、追加の事象及び非事象データを提供及び受信することなどを可能にする。アプリケーション１１５は、ウェブページ、一連のウェブページ、又はコンテンツとしてコード化されてよく、別な方法では、インターネットブラウザ内でレンダリングするようにコード化されてもよい。アプリケーション１１５は、クライアントデバイス１１０のネイティブオペレーティングシステム上で動作するように構成された専用のアプリケーションとしてコード化されてもよい。

【0027】

ダッシュボードの提供に加えて、アプリケーション１１５は、処理されたデータをネットワーク１５０を通して送信する前に、クライアントデバイス１１０のリソースを使用して、喘息レスキュー事象データに対して何らかのデータ処理を局所的に実行してもよい。ネットワーク１５０を通して送信された事象データは、データベースサーバ１４０と連携して格納及び検索のために分析及び処理されるアプリケーションサーバ１３０によって受信される。アプリケーションサーバ１３０は、クライアントアプリケーション１１５により要求される場合、検索及び格納要求をデータベースサーバ１４０に指示し得る。説明されるように、この分析は、複数の患者１１１からの事象データを含むように拡張されてよい。

【0028】

クライアントデバイス１１０は、ネットワークアダプタと、有線又は無線通信プロトコルのいずれか、例としてＢｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＴＬＥ）プロトコル、とを使用してセンサ１２０と通信する。ＢＴＬＥは、短距離無線ネットワークのラジオリンクにわたって、無線でデータを送信する、短距離で低電力のプロトコル規格である。センサ１２０及びクライアントデバイス１１０がＢＴＬＥパスキーを使用して互いにペアリングされた後、センサ１２０は、クライアントデバイス１１０と薬剤デバイスの使用に関する情報を自動的に同期して通信する。センサ１２０が、レスキュー薬剤事象の前にクライアントデバイス１１０とペアリングされていない場合、情報は、このようなペアリングが行われるまで局所的に格納される。ペアリングすると、センサ１２０は、格納された事象記録をクライアントデバイス１１０に通信する。他の実装形態において、他のタイプの無線接続が使用される（例えば、赤外線又はＩＥＥＥ８０２．１１）。

【0029】

クライアントデバイス１１０及び薬剤デバイス１６０は、別個の物理デバイス（それぞれ、スマートフォン及び吸入器など）として上述されているが、将来的には、薬剤デバイス１６０は、薬剤デバイス１６０と共に単一のハウジングに一体化されたセンサ１２０だけでなく、クライアントデバイス１１０の態様も含み得ると考えられる。例えば、薬剤デバイス１６０は、視覚可聴情報を提示するために、スピーカだけでなく、ディスプレイ又は他の照明素子を含む視聴覚インターフェースを含んでよい。このような実装形態において、薬剤デバイス１６０自体は、クライアントデバイス１１０を通してそれらを提示する代わりに、又はそれらに加えて、サーバ１３０によって提供される通知のコンテンツを直接提示し得る。

【0030】

薬剤デバイス１６０は、呼吸器疾患のレスキュー事象を経験しているユーザの肺に薬剤を送達するために使用される医療デバイスである。喘息には様々な薬剤が使われる。様々な薬剤は、喘息のレスキュー及びコントロールのためにも使用されてよい。薬剤デバイス（例えば、吸入器）は、典型的に、呼吸器発作を治療する際のアクセスし易さのため、携帯可能で、手で持ち運ぶのに十分なほど小型である。一実施形態において、薬剤は、定量吸入器などの薬剤デバイス１６０を通してエアロゾル形態で送達される。定量吸入器には、エアロゾル薬剤の加圧推進剤キャニスタ、調整された薬の投与量を送達するための計量バルブ、及び、加圧キャニスタを保持し、また薬剤送達用のマウスピースを形成するプラスチックホルダが含まれていた。別の実施形態において、薬剤は、乾燥粉末吸入器などの薬剤デバイス１６０を通して乾燥粉末形態で送達される。乾燥粉末吸入器は、ユーザが乾燥粉末薬剤のストリップを通してインデックス付けすることを可能にする、ホイール及びギア機構を収容するデカルト卵形の本体を有してよい。乾燥粉末吸入器の本体は、乾燥粉末をユーザに送達するためのマニホールド及びマウスピースも含む。コントローラ薬剤デバイス１６０によって払い出されるコントローラ薬剤の例としては、ジプロピオン酸ベクロメタゾン、ジプロピオン酸ベクロメタゾンＨＦＡブデソニド、シクレソニド、フルニソリド、フランカルボン酸フルチカゾン、プロピオン酸フルチカゾン、モメタゾン、フランカルボン酸モメタゾンＨＦＡ１００又は２００ｍｃｇ、及びトリアムシノロンアセトニド、並びに、これらの薬剤とサルメテロール又はホルモテロールなどの長時間作用型の気管支拡張剤との組み合わせが挙げられる。他の薬剤は、硫酸アルブテロール、フマル酸ホルモテロール、キシナホ酸サルメテロール、酒石酸アルホルモテロール、オロダテロールなどの長時間作用型のベータ刺激薬（ＬＡＢＡ）が含まれてよい。長時間作用型のベータ刺激薬は、ホルモテロールと組み合わせたブデソニド；フランカルボン酸フルチカゾン、ウメクリジニウム、及びビランテロール；プロピオン酸フルチカゾン及びサルメテロール；フランカルボン酸フルチカゾン１００ｍｃｇ及びビランテロール２５ｍｃｇ；グリコピロレート／フマル酸ホルモテロール；インダカテロール／グリコピロレート；ホルモテロールと組み合わせたモメタゾン；チオトロピウム２．５ｍｃｇ及びオロダテロール２．５ｍｃｇ；並びにウメクリジニウム及びビランテロールなどの組み合わせも含まれてよい。レスキュー薬剤デバイス１６０によって払い出されるレスキュー薬剤の例としては、硫酸アルブテロール、硫酸アルブテロールＨＦＡ、硫酸アルブテロール吸入及び噴霧溶液、サルブタモール、レバルブテロールＨＣｌ、メタプロテレノール、及びテルブタリンが挙げられる。

【0031】

各患者は、２つ以上の薬剤デバイス１６０に関連付けられてよい。例えば、患者は、レスキュー薬剤を払い出すレスキュー薬剤デバイス１６０と、コントローラ薬剤を払い出すコントローラ薬剤デバイス１６０とを有してよい。同様に、各患者は、患者の薬剤デバイス１６０のうちの１つと各々が動作するように選択された、２つ以上のセンサ１２０に関連付けられてもよい。

【0032】

一般に、センサ１２０は、薬剤デバイス１６０の使用を監視する物理デバイスである。センサ１２０は、薬剤デバイスの動作を妨げることなく薬剤デバイスに取り外し可能に着脱可能であるか、又はセンサ１２０は、その製造業者によって利用可能にされた薬剤デバイス１６０の本来の部分である統合されたコンポーネントである。

【0033】

センサ１２０は、有線接続を通して、又はより典型的には無線ラジオ周波数接続を通してクライアントデバイス１１０と通信する自己のネットワークアダプタ（図示せず）を含む。一実施形態において、ネットワークアダプタは、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＴＬＥ）無線送信機であるが、他の実施形態において、他のタイプの無線通信（例えば、赤外線、ＩＥＥＥ８０２．１１）が使用されてもよい。

【0034】

センサ１２０は、収集されたデータを送信するためにアプリケーションサーバ１３０とより直接的に通信するように構成されてもよい。例えば、センサ１２０のネットワークアダプタが、ＩＥＥＥ８０２．１１又はＬＴＥなどの無線規格を介して通信するように構成されている場合、アダプタは、無線ルータなどの無線アクセスポイントとデータを交換し得、次に、データを交換するごとにクライアントデバイス１１０を必ずしも関与させる必要なく、アプリケーションサーバ１３０と通信し得る。これらの２つの通信方法は相互に排他的ではなく、センサ１２０は、例えば、冗長伝送を使用して、アプリケーションサーバ１３０が事象に応答してどういう通知を提供するかを判断している間に、事象データがアプリケーションサーバ１３０に確実に到着するようにするために、又は情報をクライアントデバイス１１０に直接送信するために、クライアントデバイス１１０及びアプリケーションサーバ１３０の両方と通信するように構成されてよい。

【0035】

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

【0036】

この目標を達成するために、センサ１２０を構成するための多くの異なる方法があり、部分的に、構成は、薬剤デバイス１６０自体の構成に依存する。一般に、すべてのセンサ１２０は、オンボードプロセッサ、永続的メモリ、及び上述のネットワークアダプタを含み、これらは一緒になって、クライアントデバイス１１０及び／又はサーバ１３０に薬剤事象情報を記録、格納、及び報告するように機能する。センサ１２０は、事象の日時を記録するための時計も含んでよい。

【0037】

センサ１２０の特定の構成に関して、機械的用量カウンタなどの従来の吸入器は、センサ１２０を考慮して設計されていないため、センサ１２０はそれに応じて構成されてよい。この形式におけるいくつかの実装形態は、デバイス１６０の動き、デバイスのプライミング、デバイスの起動、ユーザによる吸入などを検出するための機械的、電気的、又は光学的センサを含む。対照的に、偏向可能な膜を備えた用量カウンタなどの最新の吸入器は、センサ１２０が受信及び解釈するように設計された電気データ信号として事象情報を報告し得る電気回路を含み、例えば、薬剤デバイス１６０自体は、動き、プライミング、及び起動をセンサ１２０に報告し得る。

【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】

本発明の様々な実施形態が上述されたが、これらは例示として提示されたものであり、限定するものではないことを理解されたい。本発明は、１つ以上の実装形態に関して図示及び記載されたが、本明細書及び添付の図面を読んで理解することにより、同等の変更及び修正が当業者に生じるか、又は知られるであろう。また、本発明の特定な特徴が、いくつかの実装形態のうちの１つだけに関して開示されたかもしれないが、このような特徴は、所与の又は特定の用途にとって望まれ、有利であり得るように、他の実装形態の１つ以上の他の特徴と組み合わされてよい。したがって、本発明の広さ及び範囲は、上記の実施形態のいずれによっても限定されるべきではない。むしろ、本発明の範囲は、以下の特許請求の範囲及びその均等物に従って定義されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【国際調査報告】