IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ レシプロカル ラボ コーポレイションの特許一覧

特表2023-545018治療デバイス離脱の予測のためのシステム及び方法
<>
  • 特表-治療デバイス離脱の予測のためのシステム及び方法 図1
  • 特表-治療デバイス離脱の予測のためのシステム及び方法 図2
  • 特表-治療デバイス離脱の予測のためのシステム及び方法 図3
  • 特表-治療デバイス離脱の予測のためのシステム及び方法 図4
  • 特表-治療デバイス離脱の予測のためのシステム及び方法 図5
  • 特表-治療デバイス離脱の予測のためのシステム及び方法 図6
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-10-26
(54)【発明の名称】治療デバイス離脱の予測のためのシステム及び方法
(51)【国際特許分類】
   G16H 20/13 20180101AFI20231019BHJP
【FI】
G16H20/13
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023520348
(86)(22)【出願日】2021-10-01
(85)【翻訳文提出日】2023-05-26
(86)【国際出願番号】 US2021053156
(87)【国際公開番号】W WO2022072818
(87)【国際公開日】2022-04-07
(31)【優先権主張番号】63/086,924
(32)【優先日】2020-10-02
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】522043611
【氏名又は名称】レシプロカル ラボ コーポレイション
(74)【代理人】
【識別番号】110001519
【氏名又は名称】弁理士法人太陽国際特許事務所
(72)【発明者】
【氏名】ヒロンズ、ニコラス、ジョン
(72)【発明者】
【氏名】ドゥーリトル、ルーク、マイケル
【テーマコード(参考)】
5L099
【Fターム(参考)】
5L099AA25
(57)【要約】
患者による治療デバイスの使用に関する離脱を予測するためのシステム及び方法が開示される。通信インターフェースが、患者に薬剤を送達する治療デバイスの操作に関するイベントデータを収集する。患者のイベントデータ及び臨床データが保存される。離脱分析モジュールは、イベントデータ及び臨床データを入力し、機械学習モデルを適用して、入力されたイベントデータ及び臨床データから、所定の期間にわたる患者の離脱の可能性を決定する。機械学習モデルは、治療デバイスを使用している患者の集団からのイベントデータ及び臨床データの入力を有する機械学習パイプラインから訓練されて、患者離脱の少なくとも1つのトリガーを決定する。離脱の可能性が、閾値を超えているかどうかが決定される。離脱の可能性が閾値を超えている場合、患者に関するアクションがトリガーされる。
【特許請求の範囲】
【請求項1】
患者による治療デバイスの使用に関する離脱を予測するためのシステムであって、前記システムは、
前記患者に薬剤を送達する前記治療デバイスの動作を監視することに関するイベントデータを収集するための通信インターフェースと、
前記患者の前記イベントデータ及び臨床データを保存するための記憶装置と、
離脱分析モジュールであって、
前記イベントデータ及び前記臨床データを入力することと、
機械学習モデルを適用して、入力された前記イベントデータ及び前記臨床データから、所定の期間にわたる前記患者の離脱の可能性を決定することであって、前記機械学習モデルは、前記治療デバイスを使用している患者の集団からのイベントデータ及び臨床データの入力を有する機械学習パイプラインから訓練されて、患者離脱の少なくとも1つのトリガーを決定する、ことと、
前記離脱の可能性が、閾値を超えているかどうかを決定することと、
前記離脱の可能性が前記閾値を超えている場合、前記患者に関するアクションをトリガーすることと、を行うように動作可能である、離脱分析モジュールと、
を備えるシステム。
【請求項2】
前記治療デバイスはレスキュー吸入器又はコントロール吸入器である、請求項1に記載のシステム。
【請求項3】
前記通信インターフェースは前記患者のモバイルデバイスと通信し、前記治療デバイスと通信するセンサが、前記モバイルデバイスにより実行されるアプリケーションと同期されてイベントデータを提供する、請求項1又は2に記載のシステム。
【請求項4】
前記機械学習パイプラインは、前記患者の集団に関する顧客サービスデータから訓練される、請求項1~3のいずれか一項に記載のシステム。
【請求項5】
前記アクションは、患者アラート、医療提供者アラート、又は治療デバイス製造業者アラートのうちの1つである、請求項1~4のいずれか一項に記載のシステム。
【請求項6】
前記機械学習パイプラインは、決定された前記離脱の可能性、処理された前記臨床データ及び前記イベントデータの値、及び前記値が、決定された前記離脱の可能性にどのように影響するかの定量化された影響、を含む予測エンドポイントを伴って応答する、請求項1~5のいずれか一項に記載のシステム。
【請求項7】
患者によって操作される治療デバイスの離脱を決定する方法であって、前記方法は、
前記患者の臨床データを収集することと、
前記治療デバイスの動作を監視することに関するイベントデータを、通信インターフェースを介して収集することと、
機械学習モデルを適用して、入力された前記イベントデータ及び前記臨床データから、所定の期間にわたる前記患者の離脱の可能性を決定することであって、前記機械学習モデルは、前記治療デバイスを使用している患者の集団からのイベントデータ及び臨床データの入力を有する機械学習パイプラインから訓練されて、患者離脱の少なくとも1つのトリガーを決定する、ことと、
前記離脱の可能性が、閾値を超えているかどうかを決定することと、
前記離脱の可能性が前記閾値を超えている場合、前記患者に関するアクションをトリガーすることと、を含む方法。
【請求項8】
前記治療デバイスはレスキュー吸入器又はコントロール吸入器である、請求項7に記載の方法。
【請求項9】
前記通信インターフェースを介して前記患者のモバイルデバイスと通信することと、
前記治療デバイスと通信するセンサを、前記モバイルデバイスにより実行されるアプリケーションと同期させて、前記イベントデータを提供することと、を更に含む、請求項7又は8に記載の方法。
【請求項10】
前記機械学習パイプラインは、前記患者の集団に関する顧客サービスデータから訓練される、請求項7~9のいずれか一項に記載の方法。
【請求項11】
前記アクションは、患者アラート、医療提供者アラート、又は治療デバイス製造業者アラートのうちの1つである、請求項7~10のいずれか一項に記載の方法。
【請求項12】
前記機械学習パイプラインは、決定された前記離脱の可能性、処理された前記臨床データ及び前記イベントデータの値、及び前記値が、決定された前記離脱の可能性にどのように影響するかの定量化された影響、を含む予測エンドポイントを伴って応答する、請求項7~11のいずれか一項に記載の方法。
【請求項13】
治療デバイスを操作する患者の離脱を予測するための機械学習モデルを訓練するパイプライン方法であって、前記方法は、
患者の集団からデータ入力を収集することであって、前記データ入力は、前記治療デバイスの動作を監視することに関する臨床データ及びイベントデータを含む、ことと、
前記データ入力をキュレートしデータテーブルを生成することと、
前記データテーブルから前記機械学習モデルを訓練し、離脱に影響を及ぼす複数の入力要因を重み付けし、離脱の可能性を決定する際の前記入力要因の影響を決定して、予測エンドポイントを生成することと、
訓練済みの前記機械学習モデルを保存することと、を含む、パイプライン方法。
【請求項14】
前記治療デバイスとの対話が不十分な患者に関するデータを除外するように、前処理モジュールを介して前記データテーブルを改良することと、
訓練モジュールへの入力用にデータを変換することと、を更に含む、請求項13に記載の方法。
【請求項15】
前記データ入力は、前記患者の集団によって操作されるモバイルデバイスからのデータと、前記モバイルデバイスにおいて実行されるアプリケーションからのデータであって、前記アプリケーションは前記治療デバイスとインターフェースしている、データと、顧客サービスデータと、を含む、請求項13又は14に記載の方法。
【請求項16】
保存された前記モデルは、予測エンドポイントモジュールによって実行されて、単一の患者に関する前記離脱の可能性の予測が、前記単一の患者による前記治療デバイスの臨床データ及びイベントデータに基づいて提供される、請求項13~15のいずれか一項に記載の方法。
【請求項17】
治療デバイスを操作する患者の離脱を予測する機械学習モデルを訓練する機械学習パイプラインシステムであって、
患者の集団からデータ入力を収集するデータ入力インターフェースであって、前記データ入力は、前記治療デバイスの動作に関する臨床データ及びイベントデータを含む、データ入力インターフェースと、
前記データ入力をキュレートしデータテーブルを生成するキュレーションモジュールと、
前記データテーブルから前記機械学習モデルを訓練し、離脱に影響を及ぼす複数の入力要因を重み付けし、離脱の可能性を決定する際の前記入力要因の影響を決定して、予測エンドポイントを生成する、訓練モジュールと、
訓練済みの前記機械学習モデルを保存する記憶装置と、を含むシステム。
【請求項18】
前記治療デバイスとの対話が不十分な患者に関するデータを除外するように前記データテーブルを改良し、前記訓練モジュールへの入力のためにデータを変換する、前処理モジュールを更に備える、請求項17に記載のシステム。
【請求項19】
前記データ入力は、前記患者の集団によって操作されるモバイルデバイスからのデータと、前記モバイルデバイスにおいて実行されるアプリケーションからのデータであって、前記アプリケーションは前記治療デバイスとインターフェースしている、データと、顧客サービスデータと、を含む、請求項17又は18に記載のシステム。
【請求項20】
保存された前記モデルは、予測エンドポイントモジュールによって実行されて、単一の患者に関する前記離脱の可能性の予測が、前記単一の患者による前記治療デバイスの臨床データ及びイベントデータに基づいて提供される、請求項17~19のいずれか一項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2020年10月2日に出願された米国仮特許出願第63/086,924号の利益及び優先権を主張し、その全体が参照により本明細書に組み込まれる。
【0002】
本開示は、全般的には医療デバイスを実行するアプリケーションへのアドヒアランスを改善する方法に関し、より具体的には、薬剤デバイスのユーザの離脱(churn)に影響を及ぼす要因を決定及び予測することに関する。
【背景技術】
【0003】
喘息及び慢性閉塞性肺疾患(COPD)などの呼吸器疾患は、依然として重大で費用を要する公衆衛生上の問題である。例えば、米国では、2200万人以上の人が喘息に罹患している。世界全体では、世界保健機関は、喘息を有する人口は3億人であり得ると推定しており、2025年までには4億人に増加するであろうと予測している。同様に、米国疾病管理予防センターによる最近の研究では、COPDが米国における死因の第3位に挙げられており、1,300万人近くがCOPDによる肺機能障害を有し得ると推定されている。
【0004】
新しい薬剤が開発されているにもかかわらず、入院及び救急外来受診率は減っていない。米国では毎年、喘息により、約200万人が救急来院し、500,000人が入院し、5,000人が死亡している。加えて、喘息は、推定1,500万日の学校欠席、1,200万日の欠勤の原因となっている。米国の医療保険会社及び雇用者にかかる総年間コストは、180億ドルを超える。COPDにより、毎年、約715,000人が入院し、134,000人が死亡している。加えて、COPDによる国へのコストは、最近、約499億ドルになると予想されており、これには、直接的な医療費の295億ドル、間接的な罹患コストの80億ドル、及び間接的な死亡コストの124億ドルが含まれる。
【0005】
喘息増悪の大半は、現在利用可能な治療で防止できるが、喘息患者の5人に1人しか病気をコントロールしていない。そのような治療は、多くの場合、喘息状態の引き金となる状態を特定し、薬剤などの治療を適切に施すことに依存している。患者が薬剤を自己服薬するための1つの機構が吸入器である。呼吸器症状が生じた場合、患者は吸入器からのパフを介して薬剤を服薬することができる。
【0006】
同様に、COPD患者は多くの場合、いつどこで症状が生じても症状を直ちに緩和させるために、吸入薬剤を携帯している。患者がこれらの薬剤を使用する頻度及び場所は、疾患がどれほど良好に管理及び治療されているかを示す重要な指標である。現在、吸入器は、吸入器の使用に関する情報を集めるための組み込みセンサ又は付属センサのいずれかを含む場合がある。次いで、この情報は、アドヒアランスを判断するために中央サーバーに送信されてもよい。
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、多くの患者は、吸入器とセンサの組合せの正しい使用を遵守しておらず、その結果、離脱率(churn rate)が高くなる。アドヒアランスの欠如は、患者が呼吸器疾患に対する治療を適切に受けていないことを意味する。多くのデジタルヘルスアプリケーション及びデバイスは、他の消費者向けアプリケーション及びデバイスに比べて、高い離脱率を被っている。支払者、提供者、及び医療専門家は、現在、吸入器などの治療デバイスに関連して、ユーザがすぐにでも離脱しそうなときを知り、予測し、介入するために、限定された能力しか持っていない。アドヒアランスの欠如及び高い離脱率は、そのような治療の費用対効果、及び吸入器の使用を追跡し、知る能力を低下させる。
【0008】
治療デバイスに対する高い離脱率を低減させるための分析を可能にするシステムへの必要性が存在する。治療デバイスを使用する患者について離脱の可能性を決定する要因を決定するために様々なデータを収集するシステムへの必要性が存在する。離脱の危険性が高い患者を決定して、その患者に対して予防措置及び治療を提供するシステムへの更なる必要性が存在する。
【課題を解決するための手段】
【0009】
開示される分析システムは、アドヒアランスを増加させるように予測モデルを訓練及び展開するために、患者の行動及び静的データのキュレーションを可能にする。この分析により、治療デバイスを使用する患者の離脱の分析が可能になる。
【0010】
開示される一例は、患者による治療デバイスの使用に関する離脱を予測するためのシステム及び方法である。システムは、治療デバイスの動作を監視することに関するイベントデータを収集するための通信インターフェースを含む。記憶装置が、患者のイベントデータ及び臨床データを記憶する。離脱分析モジュールは、イベントデータ及び臨床データを入力し、機械学習モデルを適用して、入力されたイベントデータ及び臨床データから、所定の期間にわたる患者の離脱の可能性を決定する。機械学習モデルは、治療デバイスを使用している患者の集団からのイベントデータ及び臨床データの入力を有する機械学習パイプラインから訓練されて、患者離脱の少なくとも1つのトリガーを決定する。分析モジュールは、離脱の可能性が、閾値を超えているかどうかを決定する。離脱の可能性が閾値を超えている場合、モジュールは、患者に関するアクションをトリガーする。
【0011】
例示的なシステムの更なる実装形態は、治療デバイスがレスキュー吸入器又はコントロール吸入器(control inhaler)である実施形態である。別の実装形態では、通信インターフェースは患者のモバイルデバイスと通信する。治療デバイスと通信するセンサが、モバイルデバイスにより実行されるアプリケーションと同期されて、イベントデータが提供される。別の実装形態では、機械学習パイプラインは、患者の集団に関する顧客サービスデータから訓練される。別の実装形態では、アクションは、患者アラート、医療提供者アラート、又は治療デバイス製造業者アラートのうちの1つである。別の実装形態では、機械学習パイプラインが、決定された離脱の可能性、処理された臨床データ及びイベントデータの値、及びこの値が、決定された離脱の可能性にどのように影響するかの定量化された影響、を含む予測エンドポイントを伴って応答する。
【0012】
別の開示される例は、患者によって操作される治療デバイスの離脱を決定する方法である。患者の臨床データが収集される。治療デバイスの動作を監視することに関するイベントデータが、通信インターフェースを介して収集される。機械学習モデルが適用されて、入力されたイベントデータ及び臨床データから、所定の期間にわたる患者の離脱の可能性が決定される。機械学習モデルは、治療デバイスを使用している患者の集団からのイベントデータ及び臨床データの入力を有する機械学習パイプラインから訓練されて、患者離脱の少なくとも1つのトリガーを決定する。離脱の可能性が閾値を超えているかどうかが決定される。離脱の可能性が閾値を超えている場合、患者に関するアクションがトリガーされる。
【0013】
例示的な方法の更なる実装形態は、治療デバイスがレスキュー吸入器又はコントロール吸入器である実施形態である。別の実装形態では、例示的な方法は、通信インターフェースを介して患者のモバイルデバイスと通信することと、治療デバイスと通信するセンサを、モバイルデバイスにより実行されるアプリケーションと同期させて、イベントデータを提供することと、を含む。別の実装形態では、機械学習パイプラインは、患者の集団に関する顧客サービスデータから訓練される。別の実装形態では、アクションは、患者アラート、医療提供者アラート、又は治療デバイス製造業者アラートのうちの1つである。別の実装形態では、機械学習パイプラインが、決定された離脱の可能性、処理された臨床データ及びイベントデータの値、及びこの値が、決定された離脱の可能性にどのように影響するかの定量化された影響、を含む予測エンドポイントを伴って応答する。
【0014】
別の開示される例は、治療デバイスを操作する患者の離脱を予測するための機械学習モデルを訓練するパイプライン方法である。データ入力は、患者の集団から収集される。データ入力は、治療デバイスの動作を監視することに関する臨床データ及びイベントデータを含む。データ入力は、データテーブルを生成するためにキュレートされる。機械学習モデルは、データテーブルから訓練されて、離脱に影響を及ぼす複数の入力要因を重み付けし、離脱の可能性を決定する際の入力要因の影響を決定して、予測エンドポイントを生成する。訓練済み機械学習モデルは保存される。
【0015】
例示的な方法の更なる実装形態は、前処理モジュールを介して、治療デバイスとの対話が不十分な患者に関するデータを除外するようにデータテーブルを改良すること、を含み、訓練モジュールへの入力用にデータを変換することは、治療デバイスがレスキュー吸入器又はコントロール吸入器である実施形態である。別の実装形態では、データ入力が、患者の集団によって操作されるモバイルデバイスからのデータと、モバイルデバイスにおいて実行されるアプリケーションからのデータであって、アプリケーションは治療デバイスとインターフェースしている、データと、顧客サービスデータと、を含む。別の実装形態では、保存されたモデルが予測エンドポイントモジュールによって実行されて、単一の患者に関する離脱の可能性の予測が、単一の患者による治療デバイスの臨床データ及びイベントデータに基づいて提供される。
【0016】
別の開示される例は、治療デバイスを操作する患者の離脱を予測する機械学習モデルを訓練する機械学習パイプラインシステムである。データ入力インターフェースが、患者の集団からデータ入力を収集する。データ入力は、治療デバイスの動作を監視することに関する臨床データ及びイベントデータを含む。キュレーションモジュールが、データ入力をキュレートしデータテーブルを生成する。訓練モジュールが、データテーブルから機械学習モデルを訓練し、離脱に影響を及ぼす複数の入力要因を重み付けし、離脱の可能性を決定する際の入力要因の影響を決定して、予測エンドポイントを生成する。記憶装置が、訓練済み機械学習モデルを記憶する。
【0017】
例示的な機械学習パイプラインシステムの更なる実装形態は、治療デバイスとの対話が不十分な患者に関するデータを除外するようにデータテーブルを改良し、訓練モジュールへの入力用にデータを変換する、前処理モジュールを含む実施形態であって、治療デバイスはレスキュー吸入器又はコントロール吸入器である、実施形態である。別の実装形態では、データ入力が、患者の集団によって操作されるモバイルデバイスからのデータと、モバイルデバイスにおいて実行されるアプリケーションからのデータであって、アプリケーションは治療デバイスとインターフェースしている、データと、顧客サービスデータと、を含む。別の実装形態では、保存されたモデルが予測エンドポイントモジュールによって実行されて、単一の患者に関する離脱の可能性の予測が、単一の患者による治療デバイスの臨床データ及びイベントデータに基づいて提供される。
【0018】
上記の概要は、本開示の各実施形態又はあらゆる態様を示すことは意図していない。むしろ、前述の概要は、本明細書に記載される新規な態様及び特徴のいくつかの例を提供するに過ぎない。本開示の上記の特徴及び利点、並びに他の特徴及び利点が、添付図面及び添付の特許請求の範囲と併せて、本発明を実施するための代表的な実施形態及びモードに関する以下の詳細な説明から、容易に明らかになるであろう。
【0019】
本開示は、以下の例示的な実施形態から、そして一緒に添付図面を参照して、よりよく理解されるであろう。
【図面の簡単な説明】
【0020】
図1】治療デバイスを使用している患者の離脱の予測を提供するための離脱分析システムを示す。
図2】クライアントデバイス、アプリケーションサーバー、及び/又はデータベースサーバーのいずれかとして使用されるコンピューティングデバイスの一例を示す高レベルブロック図である。
図3】例示的な機械学習パイプラインのブロック図である。
図4図3の例示的な機械学習パイプラインによって生成されたキュレーションされたデータテーブルの一例である。
図5図3の機械学習パイプラインのモデル訓練及び開発モジュールのブロック図である。
図6図3の機械学習パイプラインによって生成されたサービスエンドポイントである。
【発明を実施するための形態】
【0021】
本開示は、様々な修正形態及び代替形態の余地がある。いくつかの代表的な実施形態が、図面では例示として示されており、本明細書にて詳細に説明される。しかしながら、本発明は、開示された特定の形に限定することは意図していないことを理解すべきである。むしろ、本開示は、添付の特許請求の範囲にて定義される本発明の趣旨及び範囲に含まれる全ての修正形態、均等物、及び代替形態を包含するものである。
【0022】
本発明は、多くの異なる形で具現化できる。代表的な実施形態が図面に示され、本明細書にて詳細に説明される。本開示は、本開示の原理の一例又は例示であり、本開示の広範な態様を、示される実施形態に限定することを意図するものではない。その限りにおいて、例えば、「要約書」、「発明の概要」、及び「発明の詳細な説明」にて開示されているが、「特許請求の範囲」では明示的に述べられていない要素及び限定事項は、単独で又は集合的に、含意により、推論により、又はそれ以外の方法で、「特許請求の範囲」に組み込まれるべきではない。「発明を実施するための形態」の目的のために、特段の断りがない限り、単数形は複数形を含み、複数形は単数形を含み、用語「含む」は、「含むが限定されない」を意味する。更には、「約」、「ほぼ」、「実質的に」、「近似的に」などの近似を示す用語は、本明細書では、例えば、「において」、「の近く」、「ほぼそれにおいて」、又は「その3~5%以内」、又は「許容可能な製造公差以内」、又はそれらの任意の論理的な組合せ、を意味するために使用できる。
【0023】
本開示は、薬剤吸入器などの治療デバイスの離脱に対する関連データを収集するシステムに関する。離脱率に関する要因は、機械学習パイプラインを介して集められたデータから決定される。
【0024】
離脱分析の利点の1つは治療デバイスが改善されることである。なぜなら、分析により、製品チーム及びエンジニアリングチームが将来の離脱に関連する状況及び行動に対処する機能を設計することが可能になるからである。別の利点は、離脱に関連する特定された要因を、個々の患者に関する、よりパーソナライズされたコミュニケーション、コンテンツ、及び機能に適用して、離脱率を低減させることができることである。ユーザが、次の所定時間、例えば30日間に離脱する確率、及びその確率に影響及ぼす要因、を予測する能力により、影響を受けやすい患者との積極的なコミュニケーションが可能になる。これにより、問題を事前に解決すること、又は行動変化に対する特定のインセンティブを提供することが可能になり、より高い定着率、したがって良好な長期的な臨床転帰につながる。吸入器などの個人用治療デバイスへのより良好なアドヒアランスは、12か月にわたって救急外来受診及び入院を大幅に減らすことができる。したがって、このサービスにより患者の定着率を改善することにより、医療の利用が低減される可能性が非常に高くなる。この分析により、アドヒアランスの大幅な改善が可能になる。したがって、患者を定着させることが、製薬パートナーにとって、薬剤の補充量を増加させることにつながる。これらの薬剤は、臨床転帰を改善することが証明されている。
【0025】
図1は、一実施形態による、正確でリアルタイムの薬剤デバイスイベントを監視することに基づいてデータを収集し、そのデータに対して分析を実施し、一般患者集団に対する、特定の治療デバイスの高い離脱の兆候の識別に基づいて出力を提供するための、離脱分析システム100を示す。
【0026】
分析システム100は、クライアントコンピューティングデバイス110、薬剤デバイスセンサ120、薬剤デバイス160、アプリケーションサーバー130、データベースサーバー140、及びネットワーク150を含む。図1は、分析システム100の大部分の構成要素について単一のインスタンスのみを示しているが、実際には、各構成要素は2つ以上存在してもよいし、追加の又はより少ない構成要素が使用されてもよい。
【0027】
クライアントデバイス110は、それらのユーザの要請により、ネットワーク150を介して分析システム100と対話する。説明及び明確化のため、少なくとも2つの異なるタイプのユーザを識別することが有用である。患者111は、喘息又はCOPDなどの呼吸器疾患を患うユーザであり、この例では、患者は、呼吸器疾患分析システム100を使用して、少なくとも部分的に、サーバー130によって提供されるパーソナライズされたレスキューイベントリスク通知、及び患者の医療提供者112によって作成される管理通知を取得する。そのような通知は、患者111の薬剤デバイス160の使用を呼吸器疾患分析システム100が監視することを可能にするユーザの許可と引き換えに提供され得る。以下で説明するように、投薬イベントは、薬剤デバイス160及びユーザのクライアントデバイス110に関連付けられたセンサ120によって検出され、このイベントは、次にアプリケーションサーバー130に報告される。この実施例では、患者111は患者集団を表し、この集団に対して、グループ内の各患者について個々のデータが取得される。別のタイプのユーザが、呼吸器疾患の症状を制御するために、コントロール投薬のための薬剤デバイス160を使用し得る。
【0028】
クライアントデバイス110はコンピュータシステムである。例示的な物理的実装形態が、図2を参照して以下でより完全に説明される。クライアントデバイス110は、ネットワーク150を介して、呼吸器疾患分析システム100と無線通信するように構成されている。ネットワーク150へのアクセスにより、クライアントデバイス110は、システム100に、ユーザの地理的場所及びレスキュー又はコントロール投薬イベントの時間、並びに関連付けられた薬剤デバイスセンサ120(全体を通して「センサ120」と称する)から受信したイベントを記述する情報を送信する。
【0029】
ユーザ場所及びイベント時間に関して、クライアントデバイス110は、それが接続されているセルラー又は無線ネットワーク150に関する情報を使用して、レスキューイベント又はコントロールイベントの地理的場所及び時間を決定することができる。例えば、クライアントデバイス110の現在の地理的場所は、ネットワーク150接続を提供しているソフトウェアスタックに直接問い合わせることにより決定できる。代わりに、地理的場所情報は、ネットワーク150を介してアクセス可能になる外部ウェブサービス(図1には示されず)に対してpingを実行することにより取得されてもよい。イベントの時間は、イベントデータの一部としてセンサ120によって提供され得る、又はクライアントデバイスのネイティブオペレーティングシステムの一部として利用可能な適切なソフトウェアルーチンに対してクエリを実行することによりイベントデータに追加され得る。
【0030】
アプリケーション115は、クライアントデバイス110の画面上に表示され、ユーザがアプリケーション115の動作を制御するためにコマンドを入力することを可能にする、ユーザインターフェース(本明細書では「ダッシュボード」と呼ぶ)を提供する。ダッシュボードは、医療提供者112及び患者111が、システム100によって管理されるリソースにアクセスする機構である。例えば、ダッシュボードは、患者111及び提供者112が、互いに対話すること、喘息レスキューイベントリスク通知を受信すること、治療についてメッセージを交換すること、追加のイベント及び非イベントデータを提供及び受信することなどを行うことを可能にする。アプリケーション115は、ウェブページ、一連のウェブページ、又はインターネットブラウザ内でレンダリングされるように他の方法でコーディングされたコンテンツとして、コーディングされてもよい。アプリケーション115はまた、クライアントデバイス110のネイティブオペレーティングシステム上で動作するように構成されたプロプライエタリアプリケーションとしてコーディングされてもよい。
【0031】
ダッシュボードを提供することに加えて、アプリケーション115はまた、クライアントデバイス110のリソースを使用して、ローカルでレスキュー又はコントロールイベントデータに何らかのデータ処理を実施した後、処理されたデータをネットワーク150を介して送信してもよい。したがって、この実施例では、アプリケーション115は、薬剤デバイス160の動作に関連して、センサ120からのイベントデータの通信を可能にする。ネットワーク150を介して送信されたイベントデータは、アプリケーションサーバー130によって受信され、そこで、データベースサーバー140と連携して、記憶及び取出しのために分析及び処理される。アプリケーションサーバー130は、クライアントアプリケーション115の必要に応じて、データベースサーバー140に取出し及び記憶要求を導いてもよい。説明されるように、この分析は、複数の患者111からのイベントデータを含むように拡張されてもよい。
【0032】
クライアントデバイス110は、ネットワークアダプタ、及び有線又は無線通信プロトコルのいずれか、を使用してセンサ120と通信し、その一例はBluetooth(登録商標) Low Energy(BTLE)プロトコルである。BTLEは、短距離無線ネットワークにおける無線リンクを介してデータを無線で送信する、短距離、低出力のプロトコル規格である。センサ120及びクライアントデバイス110がBTLEパスキーを使用して互いにペアリングされた後、センサ120は、自動的に同期し、薬剤デバイスの使用に関する情報をクライアントデバイス110に通信する。センサ120が、レスキュー投薬イベントより前にクライアントデバイス110とペアリングされていない場合、情報は、そのようなペアリングが行われるまでローカルに記憶される。ペアリング時に、センサ120は、保存された任意のイベント記録をクライアントデバイス110に通信する。他の実装形態では、他のタイプの無線接続が使用される(例えば、赤外線又はIEEE 802.11)。
【0033】
クライアントデバイス110及び薬剤デバイス160を別個の物理デバイス(例えば、それぞれ、スマートフォン及び吸入器)として上記で説明しているが、将来は、薬剤デバイス160は、単一ハウジング内にデバイス160とともに一体化されたセンサ120だけでなく、クライアントデバイス110の態様も含んでよいと考えられる。例えば、薬剤デバイス160は、視聴覚情報を提示するための、ディスプレイ又は他の照明要素、並びにスピーカを含む、視聴覚インターフェースを含んでもよい。そのような実装形態では、薬剤デバイス160自体が、サーバー130によって提供される通知のコンテンツを、クライアントデバイス110を介して提示する代わりに又はそれに加えて、直接提示してもよい。
【0034】
例示的な薬剤デバイス160は、呼吸器疾患のレスキューイベントを体験しているユーザの肺に薬剤を送達するために使用される医療デバイスである。喘息及びCOPDに対して、様々な薬剤が使用される。喘息及びCOPDのレスキュー及び制御のために、様々な薬剤が使用できる。薬剤デバイス(例えば、吸入器)は、典型的には、呼吸器症状を治療する際にアクセスしやすいように携帯式であり手で持ち運べるほど小さい。一実施形態では、医薬品は、定量吸入器などの薬剤デバイス160を介してエアロゾルの形態で送達される。定量吸入器は、エアロゾル医薬品の加圧噴射キャニスタと、既定された医薬品の用量を送達するための絞り弁と、加圧キャニスタを保持し、また医薬品を送達するためのマウスピースを形成する、プラスチックホルダと、を含んだ。別の実施形態では、医薬品は、乾燥粉末吸入器などの薬剤デバイス160を介して、乾燥粉末の形態で送達される。乾燥粉末吸入器は、ホイール及び歯車機構を収納するデカルトの卵形(Cartesian ovular shaped)の本体を有して、ユーザが乾燥粉末薬剤のストリップを割り送りすることを可能にしてもよい。乾燥粉末吸入器の本体はまた、乾燥粉末をユーザに送達するためのマニホールド及びマウスピースを含む。この実施例では、薬剤デバイスが使用されているが、離脱分析は、ユーザがデバイスを定期的に使用することが必要な任意の個人用治療デバイスに使用されてもよいことを理解されたい。更に、上記の例は呼吸器障害に関するものであるが、本明細書に記載される原理は、他のタイプの病気の治療計画に適用されてもよい。
【0035】
各患者は、複数の薬剤デバイス160に関連付けられてもよい。例えば、患者は、レスキュー薬剤を分配するレスキュー薬剤デバイス160と、コントローラ薬剤を分配するコントローラ薬剤デバイス160とを有してもよい。同様に、各患者は、2つ以上のセンサ120に関連付けられてもよく、各センサは、患者の薬剤デバイス160のうちの1つとともに動作するように選択されてもよい。
【0036】
一般に、センサ120は、薬剤ディスペンサ160の使用を監視する物理デバイスである。センサ120は、薬剤ディスペンサの動作を妨げることなく薬剤ディスペンサに取り外し可能に取り付けることができるか、又は、センサ120は、薬剤ディスペンサ160の製造業者によって利用可能にされる、薬剤ディスペンサ160の固有の部品である、一体化された構成要素であるか、のいずれかである。
【0037】
センサ120は、有線接続、又はより典型的には無線高周波接続のいずれかを介して、クライアントデバイス110と通信する、センサ自体のネットワークアダプタ(図示せず)を含む。一実施形態では、ネットワークアダプタは、Bluetooth(登録商標) Low Energy(BTLE)無線送信機であるが、他の実施形態では、他のタイプの無線通信が使用されてもよい(例えば、赤外線、IEEE 802.11)。
【0038】
センサ120はまた、アプリケーションサーバー130とより直接的に通信するように構成されていてもよい。例えば、センサ120のネットワークアダプタが、IEEE 802.11又はLTEなどの無線標準規格により通信するように構成されている場合、アダプタは、無線ルータなどの無線アクセスポイントとデータを交換してもよく、無線ルータは次に、データの全ての交換において必ずしもクライアントデバイス110を伴うことなく、アプリケーションサーバー130と通信してもよい。通信のこれらの2つの方法は、相互排他的ではなく、センサ120は、例えば冗長送信を使用して、クライアントデバイス110及びアプリケーションサーバー130の両方と通信して、イベントデータがアプリケーションサーバー130に届くことを確実にするように、又は、アプリケーションサーバー130がイベントに応答してどの通知を提供するかを決定している間に、クライアントデバイス110に情報を直接提供するように構成されていてもよい。
【0039】
上記で紹介したように、センサ120は、薬剤デバイス160の使用についてのデータを取り込む。具体的には、各センサ120は、レスキュー投薬イベント、すなわち、患者111によるレスキュー薬剤デバイス160の使用の時間及び地理的場所を取り込む。各センサ120は、リアルタイムで、又はネットワーク接続が実現されると直ぐに、患者111又は医療提供者112からの入力なしに自動的にイベントデータを送信する。投薬イベント情報は、分析、喘息レスキューイベント通知の生成で使用するために、及び離脱を決定する目的で、複数の患者にわたるイベントデータの集計分析で使用するために、アプリケーションサーバー130に送られる。
【0040】
この目標を達成するために、センサ120を構築する複数の異なる方法があり、この構造は、部分的に薬剤デバイス160自体の構造に依存することになる。一般的に、全てのセンサ120は、上述したオンボードプロセッサ、永続メモリ、及びネットワークアダプタを含むことになり、これらが一緒に機能して、投薬イベント情報をクライアントデバイス110及び/又はサーバー130に記録、保存、及び報告する。センサ120はまた、イベントの時刻及び日付を記録するための時計を含んでもよい。
【0041】
特定のセンサ120構造について、機械式投与量計数器などの従来の吸入器は、センサ120を念頭に置いて設計されておらず、したがってセンサ120は、それに応じて構築されていてもよい。このようにして、いくつかの実装形態は、デバイス160の移動、デバイスのプライミング、デバイスの作動、ユーザによる吸入などを検出するための機械センサ、電気センサ、又は光学センサを含む。対照的に、屈曲可能メンブレン(deflectable membrane)投与量計数器などの最近の吸入器は、電気回路を含み、電気回路は、センサ120が受信し解釈するように設計されている電気データ信号として、イベント情報を報告してもよく、例えば、薬剤デバイス160自体が、移動、プライミング、及び作動をセンサ120に報告してもよい。
【0042】
センサ120及び薬剤デバイス160のためのハードウェア及びソフトウェア構成要素、並びにレスキュー投薬イベントを記録するためのそれらの間の対話、に関する更なる情報が、2009年1月1日に出願された米国特許出願第12/348,424号、及び2014年5月21日に出願された国際出願第PCT/US2014/039014号に見出すことができ、それら両方とも、その全体が本明細書に参照により組み込まれる。
【0043】
アプリケーションサーバー130は、コンピュータ又はコンピュータのネットワークである。図2では簡略化された例が示されているが、典型的には、アプリケーションサーバーは、例えばクライアントデバイス110として使用される典型的なコンピューティングシステムと比較して、強力なプロセッサ、大容量メモリ、及びより速いネットワーク構成要素を使用するサーバークラスシステムとなる。サーバーは、典型的には、例えば、RAID(独立ディスク冗長アレイ)アレイを使用する、及び/又は、上記で考えた喘息通知などのデータを保存、交換、及び送信するように契約された独立したコンテンツ配信ネットワーク(CDN)との関係を確立することによる、大規模二次記憶装置を有する。加えて、コンピューティングシステムは、オペレーティングシステム、例えば、UNIX(登録商標)オペレーティングシステム、LINUX(登録商標)オペレーティングシステム、又はWINDOWS(登録商標)オペレーティングシステムを含む。オペレーティングシステムは、アプリケーションサーバー130のハードウェア及びソフトウェアリソースを管理し、また様々なサービス、例えば、プロセス管理、データの入力/出力、周辺デバイスの管理なども提供する。オペレーティングシステムは、デバイス上に記憶されたファイルを管理するための様々な機能、例えば、新しいファイルの作成、ファイルの移動又はコピー、リモートシステムへのファイルの転送などを提供する。
【0044】
アプリケーションサーバー130は、ネットワーク150を介した多くの異なるクライアントデバイス110による分析システム100のアクセス及び使用をサポートするためのソフトウェアアーキテクチャを含み、したがってハイレベルでは、一般的にクラウドベースのシステムとして特徴付けることができる。アプリケーションサーバー130は、一般に、患者111及び医療提供者112が、レスキュー投薬イベント及びコントローラ投薬イベントの両方を含む、彼らの薬剤デバイス160に関連付けられたセンサによって記録されたデータを報告し、呼吸器疾患治療計画において協力し、彼らの状態及び地理的場所に関する情報を閲覧及び取得し、様々な他の機能を利用する、ためのプラットフォームを提供する。
【0045】
一般的に、アプリケーションサーバー130は、多種多様なデータを扱うように設計されている。アプリケーションサーバー130は、入ってくるデータの妥当性をチェックすること、必要に応じてデータをパースしフォーマットすること、処理されたデータを記憶させるためにデータベースサーバー140に渡すこと、及びデータベースサーバー140が更新されたことを確認することを含む、様々な機能を実施する論理ルーチンを含む。
【0046】
アプリケーションサーバー130は、データを少なくとも部分的に患者ごとに記憶し管理する。この目的のため、アプリケーションサーバー130は、各ユーザに対して患者プロファイルを作成する。患者プロファイルは、呼吸器疾患分析システム100の患者111を特徴付けるデータのセットである。患者プロファイルは、年齢、性別、現在のレスキュー薬剤、現在のコントローラ薬剤、通知選好、コントローラ投薬アドヒアランス計画、関連する病歴、及び患者プロファイルにアクセスする権限が与えられた非患者ユーザのリストなどの、患者についての識別情報を含んでもよい。プロファイルは、更に、患者のためのデータ(例えば、コントローラ及びレスキュー投薬イベントなど)をサブミットする権限が与えられた1つ以上のクライアントデバイス110又はセンサ120を識別する、一意のメディアアクセス制御(MAC)アドレスなどのデバイス識別子を指定してもよい。
【0047】
プロファイルは、患者111及び患者の個人的医療提供者112に、異なるタイプの通知のうちのどれが提供されるか、並びに通知が提供される頻度を指定してもよい。例えば、患者111は、医療提供者112に、レスキューイベントを示す通知を受信する権限を与えてもよい。患者111はまた、患者の医療提供者112に、患者プロファイル及びレスキューイベント履歴にアクセスする権限を与えてもよい。医療提供者112が、患者111の患者プロファイルへのアクセスを与えられる場合、医療提供者は、対応するCOPD又は喘息状態に関するコントローラアドヒアランス又はレスキュー投薬計画を指定してもよい。投薬計画は、コントローラ薬剤の一日あたりの規定の投薬回数を含んでもよい。
【0048】
アプリケーションサーバー130はまた、医療提供者112のプロファイルを作成する。医療提供者プロファイルは、事業所の場所、資格証明書、及び認定資格など、医療提供者112についての識別情報を含んでもよい。医療提供者プロファイルはまた、医療提供者の患者集団についての情報を含む。提供者プロファイルは、その提供者の患者のプロファイルの全部、並びに集計人口統計学的情報、レスキュー及びコントローラ投薬イベントパターンなど、それらのプロファイルから導出されたデータへのアクセスを含んでもよい。このデータは、患者プロファイルに保存された任意のタイプのデータに従って、例えば、地理的エリア(例えば、近隣、都市)によって、又は時間間隔(例えば、週単位、月単位、年単位)によって、更に細分化されてもよい。
【0049】
アプリケーションサーバー130は、クライアントデバイス110又はセンサ120からレスキュー投薬イベント情報を受信し、アプリケーションサーバー130上の様々なルーチンをトリガーする。以下で説明する例示的な実装形態では、データ分析モジュール131は、ルーチンを実行して、イベントデータ、同期データ、並びに患者のプロファイルを含む他のデータにアクセスし、データを分析し、その分析の結果を患者111及び医療提供者112の両方に出力する。このプロセスは、一般に離脱リスク(churn risk)分析と呼ばれる。この実施例では、離脱リスク分析は、吸入器160などの治療デバイスの使用に関連して実施される。代わりに、離脱リスクは、特定の患者又は患者のサブグループに対して実施されてもよい。
【0050】
他のタイプの分析は、日/週ごとのアドヒアランス傾向、経時的なアドヒアランス変化、他の関連する母集団(例えば、全患者、特定のレスキュー薬剤又はコントローラ薬剤又はそれらの組合せを投与されている患者)とのアドヒアランス比較、(空間的、時間的、環境的)トリガーの識別、経時的なレスキュー使用傾向、及び他の関連する母集団とのレスキュー使用比較、を含んでもよい。
【0051】
実施された任意の分析に応答して、アプリケーションサーバー130は、患者111、許可を受けた医療提供者112、及び/又は患者のプロファイルへのアクセスを与えられた他のユーザに送るプッシュ通知を準備し送達する。通知は、投薬レスキューイベントに関連するタイミング、場所、及び罹患患者111についての詳細を提供することができる。通知は、加えて、緊急支援提供者112に配信される、緊急支援を要求する遭難又は緊急信号を更に含んでもよい。通知はまた、データ分析モジュール131によって実施された離脱分析の結果を含んでもよい。送信され得る通知のタイプ及び通知が含み得る内容に関する更なる情報について、以下で更に説明する。
【0052】
喘息又はCOPDの増悪リスク分析に応答してプッシュ通知を提供することに加えて、通知は、特定の時間間隔でプル通知として提供されてもよい。加えて、(プッシュであろうと、プルであろうと)いくつかの通知は、レスキュー投薬イベントに応答して行われる喘息又はCOPD増悪リスク分析に応答してではなく、代わりに、通知の更新が保証されるように、喘息又はCOPD増悪リスク分析における根本的要因のうちの1つが変化したことに応答して実施されるリスク分析に応答してトリガーされてもよい。例えば、気象条件が、大気汚染の増加が発生している、又は発生しそうであることを示す場合、これが、汚染が発生している特定の地理的エリアに位置する全患者に対して喘息増悪リスク分析の実行をトリガーしてもよい。
【0053】
通知は、ネットワーク150を介してクライアントアプリケーション115に、クライアントアプリケーションでの使用に特に設計されたデータフォーマットで提供され、加えて又は代わりに、ショートメッセージサービス(SMS)メッセージ、電子メール、電話通話として、又は他の通信媒体を使用して通信される他のデータフォーマットで提供されてもよい。
【0054】
データベースサーバー140は、プロファイル、投薬イベント、患者の病歴(例えば、電子医療記録)など、患者及び提供者データの関連データを保存する。患者及び提供者データは、セキュリティのために暗号化され、少なくともパスワード保護され、そうでない場合は、医療保険の相互運用性と説明責任に関する法律(Health Insurance Portability and Accountability Act(HIPAA))の要件の全てを満たすように保護される。複数の患者からのデータ(例えば、集計されたレスキュー投薬イベントデータ)を組み込み、ユーザに提供される任意の分析(例えば、喘息リスク分析)は、患者のプライバシーを保護するために、個人識別情報が除去されるように匿名化される。データベースサーバー140はまた、医療提供者112からの患者に関する顧客サービス情報、例えば、照会、支援の要請など、を含んでもよい。
【0055】
データベースサーバー140はまた、非患者データを記憶してもよい。このデータは、患者が物理的に位置し、汚染物質に露出される可能性がある住宅地区又は商業地区の公共空間などのいくつかの地理的領域に関する地域データを含む。このデータは、とりわけ、緑地(集中した数の樹木及び植物を含むエリア)への患者の近接度を含んでもよく、又はそれを取得するよう処理されてもよい。地域データの一例は、気温、風のパターン、湿度、空気質指標など、ジオリファレンスされた気象データを含む。別の例は、ある時点での、又は経験的に測定された、様々な汚染物質の微粒子カウントを含む、ジオリファレンスされた汚染データである。地域データは、気温、湿度、及び空気質指標など、レスキューイベントの時間及び場所に関する現在の気象条件についての情報を含む。上記のデータの項目の全ては、時間とともに変化する可能性があり、そのためデータ自体は、時間によってインデックス付けされてもよく、例えば、別個のデータポイントが、時刻によって(分単位又は時間単位を含む)、又は日、週、月、若しくはシーズン単位などの、より長い期間にわたって、利用可能であってもよい。図1では、データベースサーバー140が、アプリケーションサーバー130とは別個のエンティティであるように示されているが、データベースサーバー140は、代わりに、サーバー130などの別のサーバーの一部であるハードウェア構成要素であってもよく、データベースサーバー140が、1つ以上の永続記憶装置として実装され、データベース内に記憶されたデータとインターフェースするためのソフトウェアアプリケーション層が、そうした別のサーバー130の一部であるようになっていてもよい。
【0056】
データベースサーバー140は、定義されたデータベーススキーマに従ってデータを記憶する。典型的には、異なるデータソースにわたるデータ保存スキーマは、基礎となるデータベース構造の実装の違いに起因して、クラウドアプリケーションイベントログ及びログメトリクスを含む同じタイプのデータを保存するときであっても著しく変化する。データベースサーバー140はまた、構造化データ、非構造化データ、又は半構造化データなど、異なるタイプのデータを記憶し得る。データベースサーバー140内のデータは、患者、患者のグループ、及び/又はエンティティと関連付けられてもよい。データベースサーバー140は、データベースサーバー140によって表されるデータベースオブジェクトを管理し、データベースサーバー140からの情報を読み取り、又はデータベースサーバー140に書き込むための命令を指定する問い合わせ言語(例えば、リレーショナルデータベース用のSQL、JSON NoSQLデータベースなど)にてデータベースクエリへのサポートを提供する。
【0057】
ネットワーク150は、クライアントデバイス110、センサ120、アプリケーションサーバー130、及びデータベースサーバー140の間の様々な有線及び無線通信経路を表す。ネットワーク150は、標準的なインターネット通信技術及び/又はプロトコルを使用する。したがって、ネットワーク150は、イーサネット(登録商標)、IEEE 802.11、サービス総合デジタル網(ISDN)、非同期転送モード(ATM)などの技術を使用するリンクを含むことができる。同様に、ネットワーク150で使用されるネットワーキングプロトコルは、伝送制御プロトコル/インターネットプロトコル(TCP/IP)、ハイパーテキスト転送プロトコル(HTTP)、簡易メール転送プロトコル(SMTP)、ファイル転送プロトコル(FTP)などを含むことができる。ネットワーク150を通じて交換されるデータは、ハイパーテキストマークアップ言語(HTML)、拡張マークアップ言語(XML)などを含む技術及び/又はフォーマットを使用して表すことができる。加えて、リンクの全部又は一部は、セキュアソケットレイヤ(SSL)、セキュアHTTP(HTTPS)、及び/又はバーチャルプライベートネットワーク(VPN)などの従来の暗号化技術を使用して暗号化することができる。別の実施形態では、エンティティは、上述した技術の代わりに又はそれに加えて、カスタム及び/又は専用のデータ通信技術を使用することができる。
【0058】
図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)を含む。
【0059】
記憶装置230は、ハードドライブ、コンパクトディスク読み取り専用メモリ(CD-ROM)、DVD、又はソリッドステートメモリデバイスなどの任意の非一時的コンピュータ可読記憶媒体である。メモリ215は、プロセッサ205によって使用される命令及びデータを保持する。I/Oデバイス225は、タッチ入力面(容量性又はその他)、マウス、トラックボール、若しくは他のタイプのポインティングデバイス、キーボード、又は別の形態の入力デバイスであってもよい。ディスプレイ235は、コンピュータ200からの画像及び他の情報を表示する。ネットワークアダプタ220は、コンピュータ200をネットワーク150に結合させる。
【0060】
当技術分野で知られているように、コンピュータ200は、図2に示すものとは異なる及び/又は他の構成要素を有することができる。加えて、コンピュータ200は、図示されている特定の構成要素を欠いてもよい。一実施形態では、サーバー140として機能するコンピュータ200は、専用のI/Oデバイス225及び/又はディスプレイ218を欠いてもよい。更には、記憶装置230は、(ストレージエリアネットワーク(SAN)内で具現化されるような)、コンピュータ200からローカル及び/又はリモートとすることができ、一実施形態では、記憶装置230はCD-ROM装置又はDVD装置ではない。
【0061】
一般に、クライアントデバイス110で使用される厳密な物理構成要素は、アプリケーションサーバー130及びデータベースサーバー140で使用されるものとは、サイズ、電力要件、及び性能が異なる。例えば、ホームコンピュータ、タブレットコンピュータ、ラップトップコンピュータ、又はスマートフォンであることが多いクライアントデバイス110は、比較的小さい記憶容量及び処理能力を有するが、入力デバイス及びディスプレイを含む。これらの構成要素は、データのユーザ入力、並びにアプリケーションサーバー130によって提供される通知の受信、表示、及びそれら通知との対話に好適である。対照的に、アプリケーションサーバー130は、物理的に分離されローカルネットワーク化された多数のコンピュータを含んでもよく、各コンピュータが、上記で紹介した離脱リスク分析を実行するための相当量の処理能力を有する。一実施形態では、アプリケーションサーバー130の処理能力は、Amazon Web Services(商標)などのサービスによって提供される。また、対照的に、データベースサーバー140は、物理的に分離された多数のコンピュータを含んでもよく、各コンピュータが、アプリケーションサーバーに関連付けられたデータを保存するための相当量の永続記憶容量を有する。
【0062】
当技術分野で知られているように、コンピュータ200は、本明細書で説明する機能を提供するためのコンピュータプログラムモジュールを実行するように適合されている。モジュールは、ハードウェア、ファームウェア、及び/又はソフトウェアで実装できる。一実施形態では、プログラムモジュールは記憶装置230に記憶され、メモリ215に読み込まれ、プロセッサ205によって実行される。
【0063】
特定のデバイス160/センサ120の組合せに対して、そのようなイベントを捕捉するプロセスの一例として、症状の開始時に、センサ120は、薬剤ディスペンサ160のカバーが開いているかどうかを検出してもよい。薬剤ディスペンサのカバーが開いているとき、センサ120は、ディスペンサ160のプライミングに関連付けられた加速を検出することができる。一部のタイプの薬剤ディスペンサでは、「プライミング」は、パッケージから薬剤の用量を放出する機構を作動させることを含む。他のタイプの薬剤ディスペンサでは、「プライミング」は、薬剤キャニスタを素早く振ることを含む。
【0064】
プライミングアクションが検出された後、センサ120は、レスキュー又はコントロールイベントに関連付けられたデータをセンサ120のアクティブメモリに保存するように構成されている。レスキュー又はコントロールイベントデータは、レスキューイベントに関連付けられた時刻及び日付、薬剤デバイス160のステータス又は状態(例えば、バッテリーレベル)、(イベントの前又は後の)残っている投薬回数、セルフテスト結果、及びセンサ120によって測定された、薬剤デバイス160で治療されている患者の生理学的データ、を記述する情報を含んでもよい。センサがクライアントデバイス110又はネットワーク150のいずれかとのネットワーク接続を確立すると直ぐに、センサは、ローカルに保存されたレスキュー又はコントロールイベントデータをクライアントデバイス110又はアプリケーションサーバー130に送信する。最初にイベントデータがクライアントデバイス110に送信された場合、クライアントデバイス110は、次いで、クライアントデバイス110がネットワーク150とのネットワーク接続を確立すると直ぐに、レスキュー又はコントロールイベントデータをアプリケーションサーバー130に送信する。実装形態に応じて、クライアントデバイス110又はセンサ120のいずれかが、イベントが発生した地理的場所を、アプリケーションサーバー130に送信されるイベントデータに追加する。
【0065】
レスキュー使用イベントデータを受信し保存したとき、アプリケーションサーバー130は、レスキュー又はコントロール使用イベントを説明する、患者からの更なる情報を要求してもよい。情報を取得するために、アプリケーションサーバー130は、患者のクライアントデバイス110に送信される、尋ねられる質問を含むプッシュ通知を生成する。患者は、アプリケーションに応答して入力を提供することにより、要求に応答してもよい。代わりに、患者111は、要求に応答しないことを選択してもよい。これは許容される。情報における何らかのギャップは、その後のプッシュ通知を介して、又は患者111との面会後に提供者112が入力した時点で取得されてもよい。一実装形態では、要求に応じて追加的に要求されたデータを受信できなくても、残りの分析が止まることはない。
【0066】
追加のイベントデータを要求することに加えて、アプリケーションサーバー130は、データベースサーバー140から保存されたコンテキストデータにアクセスする。一般に、コンテキストデータは、イベントデータ以外のデータを指し、これには、大気条件、気象条件、空気質条件、花粉データ、過去のレスキュー使用イベントから記録された患者データ、及びレスキュー使用イベント時に薬剤デバイスによって直接検出されない任意の他の考慮事項が含まれるが、これらに限定されない。対照的に、イベントデータは、レスキューイベントに関連し薬剤デバイスによって報告される任意のパラメータ、例えば、投薬量、イベントの時間、イベントの場所、及び関連するアドヒアランスデータを指す。どちらの形式のデータも、時間的に現在の情報、並びに保存された履歴データを含んでもよい。したがって、コンテキストデータを取得することの一部として、アプリケーションサーバー130は、患者111のレスキュー使用イベントデータの履歴にもアクセスする。この履歴データは、過去の様々な時間枠にわたる患者の履歴からの、過去のコントローラ又はレスキュー投薬イベントデータからのデータの全てを含むことができ、各履歴イベントは、このイベントに対して報告されたものと同じ情報項目の全てを、その後のフォローアップで収集された任意のデータとともに含んでもよい。
【0067】
通常の経過中、データベース140は、レスキュー使用イベントに関するデータを、それが発生した際に受信し、一次患者データストア及び一般患者集団データストアを更新して、一次患者及び患者集団における全ての患者についての最近の現在のレスキュー使用イベントに関連付けられたコンテキストデータを反映させる。データストアが新しいレスキュー使用イベントで更新される頻度は、患者の状況、コントローラ薬剤への患者のアドヒアランスレジメン、環境条件、などを含むがこれらに限定されない多くの要因に応じて変動し得る。処方されたコントローラ投薬療法に対する患者のアドヒアランスは、患者がコントローラ吸入器ユニットを使用する1日あたりの頻度と、患者がコントローラ吸入器ユニットを使用するように指示された1日あたりの頻度との比較であり、これは、コントローラ吸入器ユニットの使用に基づいて測定されてもよい。
【0068】
本システムは、異なるインターフェースを含むポータブルコンピューティングデバイス110上で実行されるアプリケーション115を含む。吸入器160の動作に関する主観的な患者データを集めるために、データ収集調査が表示されてもよい。システムは、患者により入力された調査データを保存する。
【0069】
一実施例では、治療デバイス又は患者に対する離脱を予測するプロセスは、一次患者のコンテキストデータ、報告された患者転帰、及び他の関連データの分析に基づいて、図1の分析システム100のデータ分析モジュール131によって行われる。分析システム100は、アプリケーションサーバー130上に、上記で紹介され以下で更に議論されるシステムによって収集される様々なデータを分析するデータ分析モジュール131を含んで、患者又はデバイスの離脱率を予測する。
【0070】
この実施例では、データ分析モジュール131に基づく分析システムは、AWS Glue抽出、変換、及びロードサービスを介して、Sparkデータ処理エンジンを使用して、センサ、電話、アプリケーション、医療提供者又はデバイス製造者の連絡先に関するサービスデータ、及び臨床/静的な患者データからの、数億個の別個のデータポイントをキュレートして、患者の包括的なビューを毎日のレベルで作成する。
【0071】
例示的な予測モデリングの目的のために、離脱イベントは、センサがモバイルデバイス110のアプリケーション115と同期していない、したがってセンサ120がアプリケーション115と通信していない、連続する30日間(又はそれ以上)の最初の日として定義される。これは、アプリケーションからセンサデータを受信できていないため、患者が薬剤ディスペンサ160を使用していないことを示すイベントデータと見なすことができる。同期により、センサ120は、薬剤吸入器160の使用に関する追加のデータを収集することが可能になる。連続日数の異なる長さが選択されてもよい。この例示的な分析システムの目標は、次の30日以内に離脱イベントが発生する確率を予測することである。30日以外の他の期間を使用して確率を予測してもよい。
【0072】
上述したように、離脱確率閾値を任意のレベルに設定して、テキストメッセージ、電子メール、又はプッシュ通知などのアクションをトリガーさせてもよい。このような閾値は、確率スコアがその閾値を超えたときはいつでもアクションをトリガーすることになる。トリガーの精度は、離脱イベントが発生する前の過去30日間にトリガーが少なくとも1回作成されたイベントの割合として定義される離脱イベントリコールと、次の30日間にイベントがあったトリガーの割合として定義されるトリガー/アラート精度との観点で特徴付けることができる。例えば、この実施例における予測エンジンは、75%を超える離脱イベントリコール、及び30%を超えるトリガー/アラート精度を有する。
【0073】
この実施例では、機械学習の生成は、好ましくはベストプラクティスを含む。これらのプラクティスは、再現性/分析を可能にするための、データ、モデル、及びコードの完全なバージョン管理を含む。別のベストプラクティスは、再現性/分析を可能にするための、豊富なジョブ、モデル、変数、及びサンプルメタデータである。パフォーマンスの監視は、本実施例では、抽出、変換、ロード(ETL)Glueサービスによって生成されるGlueテーブルから容易に利用可能である。再訓練、再調整、及び変数変更は、通常のリリースサイクルの一部である。
【0074】
この実施例における機械学習モデルは、過去30日間にわたって患者に存在する特徴又は行動を明らかにするだけでなく、個々の行動が離脱の確率にどのような影響を与えるかも明らかにする、モデル非依存(この場合、勾配ブースティングツリー)解釈可能性に関する最新技術であるShapley加法説明法(Shapley additive explanations)を使用する。これらの説明法は、集団全体にわたって集合的に、及び患者の毎日のレベルの両方で、行動の影響をよりよく理解することを手助けし得る。例示的なサービスにおけるテクノロジスタックが(データに加えて)、将来の機械学習パイプラインに使用されてもよい。
【0075】
データは、データソースの幅、分析の深さ、及び様々なシナリオへのモジュール性を含む。この実施例では、ソースの幅に関して、分析システム100からの数十億のデータポイントが、患者1日あたり50個を超える変数にキュレートされ、次いで更に前処理されて、過去30日間を要約する500個を超える前処理済み行動変数になる。例えば、キュレートされる変数は「今日のアプリの起動数」であってもよい。前処理される変数は、「週ごとの平均アプリ起動数の変化」であってもよい。
【0076】
深さに関して、予測エンドポイントからの主要な応答には、次の30日間での離脱の確率、前処理済み入力変数、及びこれらの前処理済み入力変数の影響、が含まれる。モジュール性に関して、データソース、パイプライン、及びサービス自体がそれぞれ、複数の使用ケースをサポートする。データソースは、因果分析(データサイエンス)及び行動ダッシュボード(データ分析)を含む。機械学習パイプラインは、極めて限定されたコード変更で、アプリケーションの使用又はアドヒアランスなどの任意の行動を予測できる。サービスには、顧客/患者サービスワークフロー、条件付きマーケティングコンテンツ、パーソナライズされた製品特徴、及び通知が含まれる。
【0077】
図3は、機械学習パイプライン300の一例を示す。機械学習パイプラインは、一組のデータ入力310、データキュレーションモジュール312、前処理モジュール314、モデル訓練/開発モジュール316、予測エンドポイントモジュール318、及び予測クロンモジュール320を含む。出力は、入力/出力テーブル330及びサービスエンドポイント332を含む。この実施例では、データ入力310は、センサデータ入力340、アプリケーション収集データ入力342、臨床データ入力344、モバイルデバイスデータ入力346、及び顧客サービスデータ入力348を含む。この実施例では、データキュレーションモジュール312、予測クロンモジュール320、並びに出力330及び332が、Glue ETLの一部である。この実施例では、前処理モジュール314、モデル訓練/開発モジュール316、予測エンドポイントモジュール318、及び予測クロン320が、SageMakerサービスの一部である。
【0078】
データキュレーションモジュール312は、異なるソースからのデータのキュレーションを可能にする。そのようなソースは、プロダクトバックエンド、サードパーティー製品分析サービス、サードパーティー顧客体験サービス、データレイク内の既存のテーブル、及びデータウェアハウス内の既存のテーブルを含んでもよいが、これらに限定されない。これらのソースは、並列処理、例えば、Apache Spark及びAWS Glue、を伴う、複数の抽出-変換-ロード(ETL)ジョブを使用してキュレートされてもよい。最終ETLジョブは、異なるソースからの全てのデータを単一のテーブルに変換する。このテーブルでは、各行が、1人の患者の1日を表し、各列が、患者-日に関するメタデータ(例えば、ユーザID又は日付フィールドなど)、又はその日の患者の特定の特徴若しくは行動を要約するデータポイントのいずれかを表す。
【0079】
この実施例では、データキュレーションモジュール312への入力データは、ユーザID及び日付、並びにデータ入力310を含む。この実施例では、センサデータ入力340は、アプリケーションによって収集された、薬剤吸入器160又はセンサ120のいずれかからのイベントデータから導出される。センサデータポイントの例には、レスキューセンサが最初にアプリケーション115と同期してからの日数、コントローラセンサが最初にアプリケーション114と同期してからの日数、同期の回数、同期の再試行回数、コントローラ用量の投薬回数、コントローラアドヒアランス(処方用量の服薬割合)、レスキューの使用回数、及びその日が離脱イベントを含んでいたかどうか(その後の使用及び同期パターンに基づく)、が含まれる。
【0080】
アプリケーションデータ入力342は、アプリケーション115からの、イベントデータと、患者から収集された主観的データとの更なる分析である。この実施例では、このような入力には、アプリケーションが最初に起動されてからの日数、アプリケーションが起動された回数、アプリケーションの起動時間、トリガーの追加、トレンドタブの閲覧、吸入器所在検索機能の使用のような、様々な機能との対話の回数、様々な機能との対話の継続時間、アプリケーション内フィードバックへの応答数、受信したプッシュ通知の数、開かれたプッシュ通知の数、が含まれてもよい。
【0081】
モバイルデバイスデータ入力346は、患者の時間、場所、及び移動などの、モバイルデバイスから導出されたデータである。この実施例では、データ入力346は、オペレーティングシステム(すなわち、Android(登録商標)、iOS、どのバージョンか)、電話モデル、Bluetooth(登録商標)が有効化されたアプリケーションハートビートのパーセント、ロケーションが有効化されたアプリケーションハートビートのパーセント、及び場所のばらつき、を含んでもよい。
【0082】
臨床データ入力344及び顧客サービスデータ入力348は、例示的なデータベース140内の患者関連の健康記録及びサービス記録から導出されてもよい。この実施例では、臨床データ入力は、疾患、疾患の状態、処方薬、用量、及びCAT又はACTスコアなどの臨床メトリクスを含んでもよい。この実施例では、顧客サービスデータ入力は、提供者112とのユーザ対話データ、提供者によってユーザに送信された電子メールの数、ユーザによって開かれた電子メールの数、及び例えば、電話、メール、テキスト、チャットを介してユーザがサポートチームと対話した回数、を含んでもよい。
【0083】
図4は、例示的なデータキュレーションモジュール312によって生成された、キュレートされたデータテーブルの一例である。データテーブルは、各行にユーザID及び日付を含む。各列は、特定のユーザID及び日付について記録された様々なイベントを含む。例えば、最初の行は、ユーザIDと日付及びアプリケーションが起動された回数(4)、アプリケーションが起動された時間(300秒)、レスキュー吸入器の薬剤センサの同期回数(8)、コントローラ吸入器の最初の同期からの日数(10)、及び今日が離脱イベントを表しているかどうか(真であれば1、偽であれば0、この場合は0)、を含む。
【0084】
図3の前処理モジュール314は、データキュレーションモジュール312からの最終テーブルを消費し、訓練、交差検証、及び一般的開発のために、機械学習モデルによって直接使用できるように、データを更に前処理する。この前処理は、1)製品又はサービスと十分に対話していないユーザ(例えば、ユーザがセンサを同期させていない又はアプリを起動していない)の除外;2)日付フィールドからの時間変数の推論(例えば、年、月、曜日);3)機械学習モデルで解釈できるバイナリアレイへのカテゴリー変数のワンホットエンコーディング;4)関連する唯一のデータポイントが現在の値であるモデル入力テーブルへの特定の変数のコピー(例えば、最初のセンサ同期からの日数、曜日、モバイルプラットフォーム);5)定められたトレーリングウィンドウ(例えば、30日間)にわたる動的行動(dynamic behavior)を要約する入力変数の作成;6)事前定義されたフォワードウィンドウ(例えば、30日間)に基づくバイナリ目標変数の作成、及び離脱イベント(センサが同期されない連続する少なくとも30日間の最初として定義される)が、そのウィンドウ内で発生するかどうか;及び、7)規則に従った、ユーザ-日の除外を含むが、これらに限定されない。
【0085】
動的行動を要約する入力値の作成は、a)1日、2日、3日、7日、14日、及び30日の組合せに対する移動平均の差;b)1日、2日、3日、7日、14日、及び30日の組合せに対する移動標準偏差の差;c)1日、2日、3日、7日、及び14日の組合せに対する逐次平均(sequential average)の差(例えば、過去7日間とその前の7日間との差);d)1日、2日、3日、7日、及び14日の組合せに対する逐次標準偏差(sequential standard deviation)の差;e)2日、3日、7日、14日、及び30日にわたる患者-日あたりの平均値;並びにf)2日、3日、7日、14日、及び30日にわたる患者-日あたりの標準偏差値、を含んでもよいが、これらに限定されない。
【0086】
ユーザ 日を除外するためのルールは、a)ユーザ-日が、そのユーザに対する最後の離脱イベントの後、30日を超えるか、b)トレーリングウィンドウ又はフォワードウィンドウにおいて誤ったデータポイント、例えばnull値又は著しく外れている値、があるか、c)フォワードウィンドウ又はトレーリングウィンドウにおいてユーザIDの変更があるか、を含んでもよいが、これらに限定されない。次いで、前処理モジュール314は、最終的な入力及び出力アレイを、他の関連するメタデータとともに、AWS S3バケットなどのデータストアに保存する。
【0087】
モデル訓練及び開発モジュール316は、前処理モジュール314からのデータを利用し、標準的な機械学習の慣行を実施して、予測モデルを開発する。開発は、1)ユーザ-日サンプルの各々を、ユーザID、日付、又はその両方に基づいて分けられた異なる交差検証フォールドに割り当てること(サンプルのランダムな割り当てではない);2)相関ベース、情報利得ベース、クラスタベースの方法を含むがこれらに限定されないヒューリスティック又はより複雑な方法に基づく変数/機能の選択;3)機械学習モデルの訓練;4)交差検証性能に基づくモデルハイパーパラメータ及び/又はモデルクラスの選択;5)各フォールドに対する訓練時間及び予測性能などの他の関連するジョブデータ及びメタデータの生成、を含み得るが、これらに限定されない。次いで、モデル訓練及び開発モジュール316は、モデルアーチファクトを、AWS S3バケットなどのデータストアに保存する。このモデルアーチファクトは、モデルファイル自体を、全ての関連するジョブ、サンプル及び変数メタデータとともに含む。
【0088】
図5は、モデル訓練及び開発モジュール316のブロック図である。モジュール316は、交差検証フォールド割り当てサブモジュール510を含み、ユーザ-日サンプルの各々は、交差検証の目的で、異なるグループ分けに割り当てられる。サブモジュールの出力は、勾配ブースティングツリー、ランダムフォレストなどのモデルクラスが選択される、モデル選択サブモジュール512と;この実施例では、最大深度、学習率、分割方法、L1又はL2正則化の強度、葉の最大数、及びサブサンプル比率を含むがこれらに限定されないハイパーパラメータが選択されるハイパーパラメータ選択サブモジュール514と;3)相関ベースの方法、情報利得ベースの方法、又はクラスタベースの方法などのフィーチャ選択方法に基づいて候補入力変数が選択されるフィーチャ選択サブモジュール516と、に送られる。選択サブモジュール512、514、及び516の出力は、訓練及び交差検証サブモジュール520に送られる。サブモジュール520の出力は較正サブモジュール522に送られ、較正サブモジュール522は、予測スコアにおける任意の体系的な信頼度の過大評価(overconfidence)又は過小評価(underconfidence)を修正して、そのようなスコアが真の確率スコアを表すことを確実にする。較正サブモジュール522の出力は、モデル説明サブモジュール524に送られ、モデル説明サブモジュール524は、この実施例では、Shapley加算値を使用して、異なるユーザグループ、個々のユーザ、又は個々のユーザ-日について、各入力変数の影響を集合的に分析する。出力は、モデルの作成に伴う全ての関連情報を保存するモデルアーチファクト530のセットである。
【0089】
予測エンドポイントモジュール318は、最終的なキュレートされたテーブルのスキーマに整合し、前処理モジュール314によって定義された同じトレーリングウィンドウにわたってデータを含む、入力を受け入れる。エンドポイントは、モデル訓練開発モジュール316によって生成された前処理コード及びモデルアーチファクトの形態であってもよく、予測クロンジョブによって直接、消費及び使用され得る。エンドポイントはまた、トレーリングウィンドウを介する入力データをエンドポイントにポストできるAPIの形式であってもよく、エンドポイントは、前処理モジュールと同じ方法でデータを前処理し、離脱の予測された確率の作成及び理解に関連する関連データを伴って応答することになる。
【0090】
予測エンドポイントモジュール318が応答する関連データポイントには、1)ユーザID;2)日付;3)定義されたフォワードウィンドウ(例:30日)における離脱イベントの予測確率又は可能性;4)処理された入力変数の値(例えば、当日の値及びトレンド値、すなわち、移動平均と逐次平均、及び標準偏差);5)Shapley加算値などのモデル説明法を使用して推測された、これらの値が予測確率に及ぼす影響の定量化された影響、が含まれるが、これらに限定されない。例示的な予測エンドポイント応答は、図6で見ることができる。パイプラインモジュールの例は、図6の変数に限定されないこと、及び図6に示されていない多くの他の変数が存在してもよいことを理解されたい。
【0091】
予測クロンモジュール320は、事前定義された時間と頻度で(例えば、毎日午前2時に)実行され、キュレートされたテーブルから各ユーザデータを繰り返し処理して、前処理モジュールで定義された行動の直近のトレーリングウィンドウを抽出する。次いで、予測クロンモジュール320は、このデータを使用して予測エンドポイントと対話して、予測確率及び他の関連情報を生成し、この情報をAWS S3バケット又はAWS Glueテーブルなどの1つ以上のデータストアに保存する。
【0092】
例示的な入力/出力テーブル330は、AWS S3バケット又はAWS Glueテーブルであり得る。ストア又はテーブルが異なれば、目的も異なり得る。この実施例では、複数のテーブルが異なる情報を含み、異なった目的のために機能し得、以下のようなものが挙げられるが、これらに限定されない:1)各行が1つのユーザ-日を表すテーブルであって、1つの列がユーザIDを含み、1つの列が前処理された入力応答全体を文字列として含み、1つの列が離脱の確率を含むテーブル;2)各行が特定のユーザ-日についての特定の前処理された入力値を表すテーブルであって、1つの列がユーザIDを含み、1つの列が予測日付を含み、1つの列が前処理された入力変数名を含み、1つの列が値を含むテーブル;及び3)各行が特定のユーザ-日の特定のShapley加算値を表すテーブルであって、1つの列がユーザIDを含み、1つの列が予測の日付を含み、1つの列が前処理された入力変数名を含み、1つの列がその特定の変数-ユーザ-日の組合せについてのShapley加算値を含むテーブル。
【0093】
サービスエンドポイント332は、各ユーザの離脱確率に関する最新情報を、顧客体験製品及びサービス、並びにユーザ体験をカスタマイズするための製品パーソナル化ツールを駆動するマーケティング自動化ツール、を含むがこれらに限定されない、製品又は組織の他の部分が利用できるようにする。サービスエンドポイントは、AWS Athenaなどの別の製品を介して、AWS Glueテーブルに対する直接的なクエリの形態をとってもよい。サービスエンドポイントは、ユーザIDが離脱する確率、ユーザIDの行動及び離脱確率に関する他の関連データ、特定の確率範囲内の全てのユーザID、離脱確率の特定のパーセンタイル範囲内の全てのユーザID、を含むがこれらに限定されない情報に対するエンドユーザのクエリを可能にするAPI層を伴い得る。これらのクエリは、特定のプログラム、地域、疾患、年齢範囲、及び臨床状態を含むがこれらに限定されない、ユーザIDについての他の条件を含み得る。
【0094】
本出願において使用される用語「構成要素」、「モジュール」、「システム」などは、一般に、コンピュータ関連エンティティであって、ハードウェア(例えば、回路)、ハードウェアとソフトウェアの組合せ、ソフトウェア、又は1つ以上の特定の機能を有する演算機(operational machine)に関するエンティティ、のいずれかを指す。例えば、構成要素は、プロセッサ(例えば、デジタル信号プロセッサ)で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、及び/又はコンピュータであってもよいが、これらに限定されない。例示として、コントローラ上で実行されているアプリケーション、並びにコントローラの両方が構成要素であり得る。1つ以上の構成要素が、プロセス及び/又は実行スレッド中に常駐してもよく、また構成要素が、1つのコンピュータにローカライズされてもよく、及び/又は2つ以上のコンピュータ間に分散されてもよい。更に、「デバイス」は、特別に設計されたハードウェア;汎用化ハードウェアであって、ハードウェア上のソフトウェアの実行によって専用化されてハードウェアに特定の機能を実施させることを可能にする、汎用化ハードウェア;コンピュータ可読媒体に記憶されたソフトウェア;又はそれらの組合せ、の形態であり得る。
【0095】
本明細書で使用される専門用語は、特定の実施形態を説明することのみを目的としており、本発明を限定することは意図していない。本明細書で使用する場合、単数形「1つの(a)」、「1つの(an)」、及び「前記(the)」は、文脈が別途明確に示さない限り、複数形も含むことが意図され得る。更に、用語「含む(including)」、「含む(includes)」、「有する(having)」、「有する(has)」、「有する(with)」、又はそれらの変形が、「発明を実施するための形態」及び/又は「特許請求の範囲」のいずれかで使用される限りにおいて、そのような用語は、「備える(comprising)」という用語と同様に包括的であることが意図される。
【0096】
別途定義されない限り、本明細書で使用される全ての用語(専門用語及び科学用語を含む)は、当業者によって一般に理解されるものと同じ意味を有する。更に、一般的に使用される辞書で定義されているような用語は、関連技術の文脈における、それら用語の意味と一致する意味を有すると解釈されるべきであり、本明細書にて明示的に定義されない限り、理想化された又は過度に形式的な意味で解釈されることはない。
【0097】
以下の請求項1~20のいずれか1つ以上からの、1つ以上の要素、又は態様、又はステップ、又はその一部を、他の請求項1~20のいずれか1つ以上からの、1つ以上の要素、又は態様、又はステップ、又はその任意の一部、又はそれらの組合せと組み合わせて、本開示の1つ以上の更なる実装形態及び/又は特許請求の範囲を形成することができる。
【0098】
本発明の様々な実施形態について上記にて説明してきたが、これらは限定ではなく、あくまで一例として提示されたものであることを理解されたい。本発明は、1つ以上の実装形態に関して例示及び説明されているが、当業者であれば、本明細書及び添付の図面を読んで理解することにより、同等の変更及び修正を想到するであろう。加えて、本発明の特定の特徴が、いくつかの実装形態のうちの1つだけに関して開示されている場合があるが、そのような特徴は、任意の所与の用途又は特定の用途にとって望ましく有利であり得る、他の実装形態の1つ以上の他の特徴と組み合わされてもよい。したがって、本発明の幅及び範囲は、上述した実施形態のいずれによっても限定されるべきではない。むしろ、本発明の範囲は、以下の特許請求の範囲及びその均等物によって定義されるべきである。
図1
図2
図3
図4
図5
図6
【国際調査報告】