特表2024-521116デバイスの使用量および患者の人口統計に基づくコンプライアンス予測のためのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-05-28
(54)【発明の名称】デバイスの使用量および患者の人口統計に基づくコンプライアンス予測のためのシステムおよび方法
(51)【国際特許分類】
G16H 20/00 20180101AFI20240521BHJP
【ＦＩ】
G16H20/00
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023571942
(86)(22)【出願日】2022-05-20
(85)【翻訳文提出日】2023-12-22
(86)【国際出願番号】 US2022030360
(87)【国際公開番号】W WO2022246267
(87)【国際公開日】2022-11-24
(31)【優先権主張番号】63/191,235
(32)【優先日】2021-05-20
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＰＹＴＨＯＮ
(71)【出願人】
【識別番号】521191403
【氏名又は名称】レズメド インコーポレイテッド
(74)【代理人】
【識別番号】110001519
【氏名又は名称】弁理士法人太陽国際特許事務所
(72)【発明者】
【氏名】ディトマー、グラント、ヒルトン
(72)【発明者】
【氏名】エルナンデス、ライアン、マシュー
(72)【発明者】
【氏名】シュクラ、プラカル
(72)【発明者】
【氏名】ゴシャル、コーシク
(72)【発明者】
【氏名】ラグァヴァン、バドリ
(72)【発明者】
【氏名】デイ、サウラヴ
(72)【発明者】
【氏名】クカン、ヤコヴ
(72)【発明者】
【氏名】ステファーソン、マイケル
(72)【発明者】
【氏名】ン、アレックス
(72)【発明者】
【氏名】カーペンター、ジェイソン
(72)【発明者】
【氏名】フィードラー、アレックス
(72)【発明者】
【氏名】メイナード、ジョン
(72)【発明者】
【氏名】スンデルジ、タミーズ
(72)【発明者】
【氏名】モータ、ヴィヴェック
(72)【発明者】
【氏名】ヘイズ、ジョッシュ
(72)【発明者】
【氏名】チェン、ジャスティン
(72)【発明者】
【氏名】ヒトフ、サム
(72)【発明者】
【氏名】ホー、ルビー
(72)【発明者】
【氏名】ホフラー、ティム
(72)【発明者】
【氏名】コーリ、アマル
(72)【発明者】
【氏名】ウー、スンヒ
(72)【発明者】
【氏名】マイエル、イアン
(72)【発明者】
【氏名】ベイカー、スタンリー
(72)【発明者】
【氏名】ガオ、グローリア
【テーマコード（参考）】
5L099
【Ｆターム（参考）】
5L099AA21
(57)【要約】
呼吸圧療法デバイスを治療レジメンで使用するためのコンプライアンス予測を提供するシステムおよび方法が開示される。このシステムは、送信機を有する呼吸圧療法デバイスと、患者に呼吸療法を提供する空気コントローラスとを含む。呼吸圧療法デバイスは、作動データを収集し、収集した作動データを送信する。患者の人口統計データを収集する。治療レジメンに対する予測コンプライアンスは、コンプライアンス予測出力を有する機械学習コンプライアンス予測モデルに、作動データおよび人口統計データを入力することに基づいて決定される。機械学習モデルは、呼吸圧療法デバイスを使用する患者集団の作動データと人口統計データに基づいて訓練される。
【特許請求の範囲】
【請求項1】
呼吸療法レジメンに対する患者のコンプライアンスを予測する方法であって、呼吸圧療法デバイスから作動データを収集するステップと、
患者の人口統計データを収集するステップと、
コンプライアンス予測出力を有する機械学習コンプライアンス予測モデルに作動データおよび人口統計データを入力して治療のコンプライアンスを予測するステップであって、前記機械学習モデルは、前記呼吸圧療法デバイスを使用する患者集団の前記作動データおよび前記人口統計データから訓練される、ステップと、を含む方法。
【請求項2】
前記患者に関連する医療提供者によって操作されるユーザデバイスに前記コンプライアンスデータを送信するステップをさらに含む、請求項１に記載の方法。
【請求項3】
前記患者によって操作されるユーザデバイスに前記コンプライアンスデータを送信するステップをさらに含む、請求項１～２のいずれか１項に記載の方法。
【請求項4】
前記コンプライアンス予測に基づいて、前記ユーザデバイスを介して前記患者に動機を与えるステップをさらに含む、請求項３に記載の方法。
【請求項5】
前記患者集団の複数の分類に基づいて前記患者を分類するステップをさらに含む、請求項１～４のいずれか１項に記載の方法。
【請求項6】
前記機械学習コンプライアンス予測モデルは、前記患者の分類に基づく出力を含む、請求項５に記載の方法。
【請求項7】
前記機械学習コンプライアンス予測モデルは、所定の期間を有する治療レジメンの毎日の予測を出力する、請求項１～６のいずれか１項に記載の方法。
【請求項8】
前記コンプライアンス予測に応答して、前記呼吸圧療法デバイスと通信して、前記患者に対する呼吸療法を変更するステップをさらに含む、請求項１～７のいずれか１項に記載の方法。
【請求項9】
前記呼吸圧療法デバイスは、加圧空気を前記患者に供給するためのモータ、ブロワ、およびマスクを含み、収集された作動データは、流量センサ、空気圧センサ、およびモータ速度トランスデューサからのデータを含む、請求項１～８のいずれか１項に記載の方法。
【請求項10】
前記呼吸圧療法デバイスは、気道陽圧（ＰＡＰ）デバイス、非侵襲的換気（ＮＩＶ）デバイス、または適応支援換気（ＡＳＶ）デバイスのうちの１つである、請求項９に記載の方法。
【請求項11】
健康モニタから生理学的データを収集するステップをさらに含み、収集された生理学的データは、予測を決定するために前記機械学習コンプライアンス予測モデルに入力される、請求項１～１０のいずれか１項に記載の方法。
【請求項12】
前記健康モニタは少なくとも１つのセンサを含み、前記少なくとも１つのセンサは、オーディオセンサ、心拍数センサ、呼吸センサ、ＥＣＧセンサ、光電脈波検査（ＰＰＧ）センサ、赤外線センサ、活動センサ、無線周波数センサ、ソナーセンサ、光学センサ、ドップラーレーダーモーションセンサ、温度計、インピーダンスセンサ、圧電センサ、光電センサまたはひずみゲージセンサのうちの１つからなる群から選択される、請求項１１に記載の方法。
【請求項13】
ユーザデバイスを介して収集された作動データを受信するステップと、ネットワークを介してデータを送信するステップと、をさらに含む、請求項１～１２のいずれか１項に記載の方法。
【請求項14】
前記機械学習コンプライアンス予測モデルは、予測を決定する際に、前記患者に関連する環境データを分析する、請求項１～１３のいずれか１項に記載の方法。
【請求項15】
前記機械学習コンプライアンス予測モデルは、予測を決定する際に、前記患者に関連する人口統計データを分析する、請求項１～１４のいずれか１項に記載の方法。
【請求項16】
使用量データおよび人口統計データのタイプ毎にｓｈａｐ値を提供するステップをさらに含む、請求項１～１５のいずれか１項に記載の方法。
【請求項17】
収集された作動データは、使用持続時間、リークデータ、ＡＨＩ、およびマスクタイプを導出するために使用される、請求項１～１６のいずれか１項に記載の方法。
【請求項18】
前記人口統計データは、患者の年齢および性別を含む、請求項１～１７のいずれか１項に記載の方法。
【請求項19】
調査から患者入力データを収集するステップをさらに含み、前記機械学習コンプライアンス予測モデルは、予測を決定する際に前記患者入力データを分析する、請求項１～１８のいずれか１項に記載の方法。
【請求項20】
患者のコンプライアンス予測を表示すステップをさらに含む、請求項１～１９のいずれか１項に記載の方法。
【請求項21】
コンプライアンス予測は、治療期間を示すカレンダに表示される、請求項２０に記載の方法。
【請求項22】
前記カレンダは、過去のコンプライアンス日数を示す、請求項２１に記載の方法。
【請求項23】
前記カレンダは、コンプライアンス予測に基づいて、予想されるコンプライアンス期間の終了を示す、請求項２１に記載の方法。
【請求項24】
患者との最後の接触の試みに関する情報を表示すステップをさらに含む、請求項１９～２３のいずれか１項に記載の方法。
【請求項25】
前記表示は、前記患者の連絡データを含む、請求項２４に記載の方法。
【請求項26】
コンピュータによって実行されると、請求項１～２５のいずれか１項に記載の方法をコンピュータに実行させる命令を含むコンピュータプログラム製品。
【請求項27】
前記コンピュータプログラム製品は、非一時的なコンピュータ読み取り可能な媒体である、請求項２６に記載のコンピュータプログラム製品。
【請求項28】
呼吸療法レジメンに対する患者のコンプライアンスを予測するためのシステムであって、送信機および空気コントローラスを含む患者に気流ベースの呼吸療法を提供するための呼吸圧療法デバイスであって、作動データを収集し、収集された作動データを送信する、呼吸圧療法デバイスと、
前記患者に関連する人口統計データを記憶する患者データベースと、
前記呼吸圧療法デバイスから収集された作動データを受信し、前記データベースから人口統計データを受信するネットワークと、
前記ネットワークに結合されたコンプライアンス分析エンジンであって、前記コンプライアンス分析エンジンは、収集された作動データおよび人口統計データを、作動データおよび人口統計データと、その結果として得られたコンプライアンスとを含む大規模な患者集団データセットで訓練されたコンプライアンス予測モデルに入力し、コンプライアンス予測モデルは、前記呼吸圧療法デバイスの使用に対するする患者のコンプライアンス予測を出力する、コンプライアンス分析エンジンと、を含む、システム。
【請求項29】
前記コンプライアンス分析エンジンに結合されたネットワークインターフェースをさらに含み、前記ネットワークインターフェースは、前記患者に関連する医療提供者によって操作されるユーザデバイスにコンプライアンスデータを送信する、請求項２８に記載のシステム。
【請求項30】
前記コンプライアンス分析エンジンに結合されたネットワークインターフェースをさらに含み、前記ネットワークインターフェースは、前記患者によって操作されるユーザデバイスにコンプライアンスデータを送信する、請求項２８～２９のいずれか１項に記載のシステム。
【請求項31】
前記ユーザデバイスは、前記コンプライアンス予測に基づいて前記患者に動機を与えるように構成されている、請求項３０に記載のシステム。
【請求項32】
前記コンプライアンス分析エンジンは、患者集団の複数の分類に基づいて患者を分類する、請求項２８～３１のいずれか１項に記載のシステム。
【請求項33】
前記機械学習コンプライアンス予測モデルは、前記患者の分類に基づく出力を含む、請求項３２に記載のシステム。
【請求項34】
前記機械学習コンプライアンス予測モデルは、所定の期間を有する治療レジメンの毎日の予測を出力する、請求項２８～３３のいずれか１項に記載のシステム。
【請求項35】
前記コンプライアンス分析エンジンは、前記コンプライアンス予測に応答して、呼吸圧療法デバイスと通信して、患者に対する呼吸療法を変更するように構成されている、請求項２８～３４のいずれか１項に記載のシステム。
【請求項36】
前記呼吸圧療法デバイスは、患者に加圧空気を供給するためのモータ、ブロア、およびマスクを含み、収集された作動データは、流量センサ、空気圧センサ、およびモータ速度トランスデューサからのデータを含む、請求項２８～３５のいずれか１項に記載のシステム。
【請求項37】
前記呼吸圧療法デバイスは、気道陽圧（ＰＡＰ）デバイス、非侵襲的換気（ＮＩＶ）デバイス、または適応支援換気（ＡＳＶ）デバイスのうちの１つである、請求項３６に記載のシステム。
【請求項38】
健康モニタをさらに含み、前記コンプライアンス分析エンジンは、健康モニタから生理学的データを収集するように構成され、収集された生理学的データは、予測を決定するために前記機械学習コンプライアンス予測モデルに入力される、請求項２８～３７のいずれか１項に記載のシステム。
【請求項39】
前記健康モニタは少なくとも１つのセンサを含み、前記少なくとも１つのセンサは、オーディオセンサ、心拍数センサ、呼吸センサ、ＥＣＧセンサ、光電脈波検査（ＰＰＧ）センサ、赤外線センサ、活動センサ、無線周波数センサ、ソナーセンサ、光学センサ、ドップラーレーダーモーションセンサ、温度計、インピーダンスセンサ、圧電センサ、光電センサ、またはひずみゲージセンサのうちの１つからなる群から選択される、請求項３８に記載のシステム。
【請求項40】
収集された作動データを受信し、ネットワークを介して前記データを送信するように構成されたユーザデバイスをさらに含む、請求項２８～３９のいずれか１項に記載のシステム。
【請求項41】
前記機械学習コンプライアンス予測モデルは、予測を決定する際に、前記患者に関連する環境データを分析する、請求項２８～４０のいずれか１項に記載のシステム。
【請求項42】
前記機械学習コンプライアンス予測モデルは、前記予測を決定する際に、前記患者に関連する人口統計データを分析する、請求項２８～４１のいずれか１項に記載のシステム。
【請求項43】
前記機械学習コンプライアンス予測モデルは、使用量データおよび人口統計データのタイプごとにｓｈａｐ値を提供する、請求項２８～４２のいずれか１項に記載のシステム。
【請求項44】
収集された作動データは、使用持続時間、リークデータ、ＡＨＩ、およびマスクタイプを導出するために使用される、請求項２８～４３のいずれか１項に記載のシステム。
【請求項45】
前記人口統計データは、患者の年齢および性別を含む、請求項２８～４４のいずれか１項に記載のシステム。
【請求項46】
前記コンプライアンス分析エンジンは、調査から患者入力データを収集し、前記機械学習コンプライアンス予測モデルは、予測を決定する際に前記患者入力データを分析する、請求項２８～４５のいずれか１項に記載のシステム。
【請求項47】
前記コンプライアンス分析エンジンに結合されたディスプレイをさらに含み、前記ディスプレイは、患者のコンプライアンス予測を表示す、請求項２８～４６のいずれか１項に記載のシステム。
【請求項48】
前記コンプライアンス予測は、治療期間を示すカレンダに表示される、請求項４７に記載のシステム。
【請求項49】
前記カレンダは、過去のコンプライアンス日数を示す、請求項４８に記載のシステム。
【請求項50】
前記カレンダは、コンプライアンス予測に基づいて、予想されるコンプライアンス期間の終了を示す、請求項４８に記載のシステム。
【請求項51】
ディスプレイは、患者との最後の接触の試みに関する情報を表示す、請求項４７～５０のいずれか１項に記載のシステム。
【請求項52】
前記ディスプレイは、前記患者の連絡データを含む、請求項５１に記載のシステム。
【請求項53】
呼吸療法レジメンに対する患者のコンプライアンスの予測を出力するためのコンプライアンス予測モデルを訓練する方法であって、呼吸圧療法デバイスを使用する各患者集団から作動データを収集するステップと、
前記患者集団から人口統計データを収集するステップと、
前記作動データに基づいて前記患者集団からコンプライアンスデータを決定するステップと、
前記収集された作動データおよび人口統計データに基づいて、入力特徴セットを選択するステップと、
前記入力特徴セットの中から選択された収集された作動データおよび人口統計データと、対応するコンプライアンスデータとを用いて、コンプライアンス予測モデルを訓練し、コンプライアンス予測を出力するステップと、を含む、方法。
【請求項54】
入力特徴セットの１つとして患者集団に関連する環境データを収集するステップをさらに含む、請求項５３に記載の方法。
【請求項55】
前記コンプライアンス予測モデルを訓練して、前記入力特徴セットのそれぞれについてｓｈａｐ値を提供するステップをさらに含む、請求項５３～５４のいずれか１項に記載の方法。
【請求項56】
前記入力特徴セットは、継続時間、リークデータ、ＡＨＩ、およびマスクタイプを含む、請求項５３～５５のいずれか１項に記載の方法。
【請求項57】
前記人口統計データは、年齢および性別を含む、請求項５３～５６のいずれか１項に記載の方法。
【請求項58】
前記入力特徴セットの１つとして調査から患者入力データを収集するステップをさらに含む、請求項５３～５７のいずれか１項に記載の方法。【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本開示は、２０２１年５月２０日に出願された米国仮特許出願第６３／１９１，２３５号の優先権および利益を主張する。当該出願の内容は、その全体が参照により本明細書に組み込まれている。
本開示は、概して健康データシステムに関し、より具体的には、呼吸圧療法デバイスから収集されたデータおよび患者関連データのコンプライアンス予測を提供するシステムに関する。
本開示は、２０２１年５月２０日に出願された米国仮特許出願第６３／１９１，２３５号の優先権および利益を主張する。当該出願の内容は、その全体が参照により本明細書に組み込まれている。
本開示は、概して健康データシステムに関し、より具体的には、呼吸圧療法デバイスから収集されたデータおよび患者関連データのコンプライアンス予測を提供するシステムに関する。
【背景技術】
【0002】
慢性病は世界中の死亡や障害の主な原因となっている。２０２０年までに、彼らの寄与は全死亡者数の７３％、世界の疾病負担の６０％に上昇すると予想されている。医療費の高騰につながっている。慢性疾患は医療コストの主な原動力となっており、米国の１ドル当たりの支出額の９０パーセントを占めている。このコストは高齢化と関係している。２０１５年には世界の８人に１人が６０歳以上であった。２０３０年には、６人に１人が６０歳以上になると推定されている。
【0003】
慢性疾患に苦しむ多くの患者は、長期酸素療法（ＬＴＯＴ）の一環として酸素補給を必要としている。現在、ＬＴＯＴを受けている患者の大多数は、慢性閉塞性肺疾患（ＣＯＰＤ）という一般的なカテゴリーで診断されていた。この一般的な診断には、慢性気管支炎、肺気腫、関連する肺疾患などの一般的な疾患が含まれる。他の患者、例えば、高い活動レベルを維持する必要がある肥満患者、嚢胞性線維症の患者、または気管支肺異形成の乳児なども酸素補給を必要とする場合がある。
【0004】
このような患者の多くは呼吸圧療法デバイスを利用して呼吸または睡眠障害の治療を支援している。例えば、ＣＰＡＰデバイスは、睡眠中に空気の通路を確保するために必要なときに空気圧を供給する。このようなデバイスは、一連の呼吸器疾患の治療に有用である。呼吸器疾患の例には、周期性四肢運動障害（ＰＬＭＤ）、レストレスレッグ症候群（ＲＬＳ）、睡眠時呼吸障害（ＳＤＢ）、閉塞性睡眠時無呼吸症候群（ＯＳＡ）、呼吸努力関連覚醒（ＲＥＲＡ）、中枢性睡眠時無呼吸症候群（ＣＳＡ）、チェーン・ストークス呼吸（ＣＳＲ）、呼吸不全、肥満性過換気症候群（ＯＨＳ）、慢性閉塞性肺疾患（ＣＯＰＤ）、神経筋疾患（ＮＭＤ）、胸壁疾患が挙げられる。これらの疾患は通常、呼吸療法システムを用いて治療される。特定の障害は、無呼吸、呼吸低下、過呼吸などの特定の現象を特徴とする場合がある。
【0005】
ＣＰＡＰ療法デバイスの動作は、軟口蓋と舌を前方に押して中咽頭後壁から遠ざけるなど、空気圧副木として機能し、上気道の閉塞を防ぐ継続的な気道陽圧に依存している。しかし、ＣＰＡＰ療法デバイスによる睡眠時無呼吸の治療は、一般に自発的なものであるため、患者は、そのような治療を提供するために使用されるデバイスが不快である、使いにくい、高価である、または見栄えが悪いと判断した場合には、治療に従わないことを選択することができる。
【0006】
ユーザのコンプライアンスが困難であるため、このようなＣＰＡＰデバイスは、ユーザ操作中にある作動データを送信するように構成されている。このデータは、呼吸療法を処方された患者が「従順」になったかどうか、例えば、患者が１つまたは複数の「従順な規則」に従って呼吸圧療法デバイスを使用したかどうかを判定することを可能にする。ＣＰＡＰ治療のコンプライアンス規則の一例は、コンプライアンス規則とみなされるために、患者は、９０（９０）日間連続して３０（３０）日間のうち少なくとも２１（２１）日間、毎晩少なくとも４時間、呼吸圧療法デバイスを使用する必要があることである。患者のコンプライアンスを決定するために、医療提供者などの呼吸圧療法デバイスの提供者は、呼吸圧療法デバイスを用いた患者の治療を記述するデータを手動で入手することができる。提供者は、所定の期間における使用量を計算し、コンプライアンス規則と比較することができる。医療提供者がコンプライアンス規則に従って患者が呼吸圧療法デバイスを使用したことを決定すると、医療提供者は、患者がコンプライアンスであることを支払者などの第三者に通知することができる。
【0007】
患者は通常、ＣＰＡＰデバイスを最初に受け取るときに定期的に使用するが、デバイスを継続的に一貫して使用することはできないため、患者は従順であるとみなされる。これらの不従順患者のうち、１７．７％はコンプライアンスに達してから５日以内に出現していた。現在、患者デバイスのデータは、患者がコンプライアンス違反になるリスクがある場合の判断に有効に活用できていない。既存のコンプライアンスプロセスは、患者デバイスのデータに基づく規則が中心となって「問題後の修復」を行う方法であるためである。これらの規則は静的であり、時間の経過とともに学習されず、パーソナライゼーションが制限されており、アクショングループを使用する場合でも手動の構成と管理が必要である。また、現在のプロセスでは、優先順位がなく、問題ごとに平等にグループ分けされているため、多数の患者の分析にまで拡張することはできない。その結果、医療提供者やその他のエージェントは、将来どの患者がコンプライアンスに違反する可能性があるかについて、主観的な予測を迫られることになる。このような予測は、さまざまな関係者の異なる判断に基づいて変化する可能性があり、そのような関係者はそのような予測に関連するデータを知らないか、またはそのようなデータを持っていないため、信頼できない。
【0008】
コンプライアンスを高めるために、睡眠呼吸障害や共病状態の罹患率が高い高齢者向けに技術的な解決策を提供する動きがある。このようなソリューションには、スマートフォンアプリケーション、持続気道陽圧（ＣＰＡＰ）使用量アプリケーション、ウェアラブル活動モニタ、医療モノのインターネット（ＩｏＭＴ）、人工知能（ＡＩ）、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、４Ｇ、５Ｇなどの通信テクノロジーが含まれる場合がある。
【0009】
しかし、現在の慢性疾患管理治療および関連する補助アプリケーションは、ユーザが定期的にそれらと対話しなければならず、不正確な情報をアプリケーションに提供する可能性があるため、結果が悪い傾向がある。これは、特定の回答が保険または介護の価格／費用または利用可能性を変える可能性があるとユーザが考えている場合に特に当てはまる。それ以外の場合、ユーザは自分の病状が悪化しているのか、他の症状よりもどのような症状が重要なのか、まったく判断できない。
【0010】
コンプライアンスの傾向があるが、最終的にコンプライアンスに達していない患者の大集団が存在し、これらの患者の多くはコンプライアンスに非常に近い。医療提供者はリソースや時間が限られているため、コンプライアンス違反に近づいている可能性があるが、コーチングやアウトリーチ、デバイス設定の調整などの追加リソースに積極的に対応し、コンプライアンスを達成する患者を優先する必要がある。したがって、患者が非準拠になる可能性の高さに基づいて、リソース、設定の調整、およびその他の介入に迅速かつ効率的に優先順位を付けることが有利である。したがって、呼吸圧療法デバイスを使用する患者のコンプライアンスを予測できるシステムが必要である。
【発明の概要】
【0011】
開示されている例は、呼吸療法レジメンに対する患者のコンプライアンスを予測する方法である。呼吸圧療法デバイスから作動データを収集する。患者の人口統計データを収集する。コンプライアンス予測出力を有する機械学習コンプライアンス予測モデルに作動データおよび人口統計データを入力して治療のコンプライアンスを予測する。呼吸圧療法デバイスを使用する患者集団の作動データおよび人口統計データに基づいて機械学習モデルを訓練する。
【0012】
例示的な方法の更なる実施形態では、患者に関連する医療提供者によって操作されるユーザデバイスにコンプライアンスデータを送信するステップをさらに含む。別の実施形態では、例示的な方法において、患者によって操作されるユーザデバイスにコンプライアンスデータを送信するステップを含む。別の実施形態では、例示的な方法において、コンプライアンス予測に基づいてユーザデバイスを介して患者に動機を与えるステップを含む。別の実施形態では、例示的な方法において、患者集団の複数の分類に基づいて患者を分類するステップを含む。別の実施形態では、機械学習コンプライアンス予測モデルは患者分類に基づく出力を含む。別の実施形態では、機械学習コンプライアンス予測モデルは、所定の期間を有する治療レジメンの毎日の予測を出力する。別の実施形態では、例示的な方法において、コンプライアンス予測に応答して呼吸圧療法デバイスと通信して患者の呼吸療法を変更するステップを含む。別の実施形態では、呼吸圧療法デバイスであって、患者に加圧空気を供給するために、モータ、ブロワ、およびマスクを含む。収集された作動データは、流量センサ、空気圧センサ、モータ速度トランスデューサからのデータを含む。別の実施形態では、呼吸圧療法デバイスは、気道陽圧（ＰＡＰ）デバイス、非侵襲的換気（ＮＩＶ）デバイス、または適応支援換気（ＡＳＶ）デバイスのうちの１つである。別の実施形態では、例示的な方法において、健康モニタから生理学的データを収集するステップを含む。収集された生理学的データは、予測を決定するために前記機械学習コンプライアンス予測モデルに入力される。別の実施形態では、健康モニタは少なくとも１つのセンサを含み、少なくとも１つのセンサは、オーディオセンサ、心拍数センサ、呼吸センサ、ＥＣＧセンサ、光電脈波検査（ＰＰＧ）センサ、赤外線センサ、活動センサ、無線周波数センサ、ソナーセンサ、光学センサ、ドップラーレーダーモーションセンサ、温度計、インピーダンスセンサ、圧電センサ、光学センサ、またはひずみゲージセンサのうちの１つからなる群から選択される。別の実施形態では、例示的な方法において、ユーザデバイスを介して収集された作動データを受信し、ネットワークを介してデータを送信するステップを含む。別の実施形態では、機械学習コンプライアンス予測モデルは、予測を決定する際に患者に関連する環境データを分析する。別の実施形態では、機械学習コンプライアンス予測モデルは、予測を決定する際に患者に関連する人口統計データを分析する。別の実施形態では、例示的な方法において、使用量データおよび人口統計データのタイプ毎のｓｈａｐ値を提供する。別の実施形態では、収集された作動データは、使用持続時間、リークデータ、ＡＨＩ、およびマスクタイプを導出するために使用される。別の実施形態では、人口統計は、年齢および性別を含む。別の実施形態では、例示的な方法において、調査から患者入力データを収集するステップを含む。機械学習コンプライアンス予測モデルは、予測を決定する際に患者の入力データを分析する。別の実施形態では、患者のコンプライアンス予測を表示すステップを含む方法である。別の実施形態では、コンプライアンス予測は、治療期間を示すカレンダに表示される。別の実施形態では、カレンダは、過去のコンプライアンス日数を示す。別の実施形態では、カレンダは、コンプライアンス予測に基づいて、予想されるコンプライアンス期間の終了を示す。別の実施形態では、患者との最後の接触の試みに関する情報を表示すステップを含む方法である。別の実施形態では、ディスプレイは、患者の連絡データを含む。
【0013】
別の開示された例は、コンピュータによって実行されると、上記方法をコンピュータに実行させる命令を含むコンピュータプログラム製品である。コンピュータプログラム製品の別の実施形態では、コンピュータプログラム製品は非一時的なコンピュータ読み取り可能な媒体である。
【0014】
もう１つの開示された例は、呼吸療法レジメンに対する患者のコンプライアンスを予測するシステムである。このシステムは、送信機および空気コントローラスを含み、気流ベースの呼吸療法を患者に提供するための呼吸圧療法デバイスを含む。呼吸圧療法デバイスは、作動データを収集し、収集された作動データを送信する。患者データベースは、患者に関連する人口統計データを記憶する。ネットワークは、呼吸圧療法デバイスから収集された作動データを受信し、データベースから人口統計データを受信する。コンプライアンス分析エンジンは、ネットワークに結合される。コンプライアンス分析エンジンは、収集された作動データおよび人口統計データを、作動データおよび人口統計データと、その結果として得られたコンプライアンスを含む大規模な患者集団データセットで訓練されたコンプライアンス予測モデルに入力する。コンプライアンス予測モデルは、呼吸圧療法デバイスを用いた患者のコンプライアンス予測を出力する。
【0015】
例示的なシステムのさらなる実施形態では、コンプライアンス分析エンジンに結合されたネットワークインターフェースを含む。ネットワークインターフェースは、患者に関連する医療提供者によって操作されるユーザデバイスにコンプライアンスデータを送信する。例示的なシステムの別の実施形態では、コンプライアンス分析エンジンに結合されたネットワークインターフェースを含む。ネットワークインターフェースは、患者によって操作されるユーザデバイスにコンプライアンスデータを送信する。別の実施形態では、ユーザデバイスは、コンプライアンス予測に基づいて患者に動機を与えるように構成されている。別の実施形態では、コンプライアンス分析エンジンは、患者集団の複数の分類に基づいて患者を分類する。別の実施形態では、機械学習コンプライアンス予測モデルは患者分類に基づく出力を含む。別の実施形態では、機械学習コンプライアンス予測モデルは、所定の期間を有する治療レジメンの毎日の予測を出力する。別の実施形態では、コンプライアンス分析エンジンは、コンプライアンス予測に応答して、呼吸圧療法デバイスと通信して患者の呼吸療法を変更するように構成されている。別の実施形態では、呼吸圧療法デバイスは、患者に加圧空気を供給するために、モータ、ブロワ、およびマスクを含む。収集された作動データは、流量センサ、空気圧センサ、モータ速度トランスデューサからのデータを含む。別の実施形態では、呼吸圧療法デバイスは、気道陽圧（ＰＡＰ）デバイス、非侵襲的換気（ＮＩＶ）デバイス、または適応支援換気（ＡＳＶ）デバイスのうちの１つであることである。別の実施形態では、システムは健康モニタを含む。コンプライアンス分析エンジンは、健康モニタから生理学的データを収集するように構成されている。収集された生理学的データは、予測を決定するために前記機械学習コンプライアンス予測モデルに入力される。別の実施形態では、健康モニタは少なくとも１つのセンサを含み、少なくとも１つのセンサは、オーディオセンサ、心拍数センサ、呼吸センサ、ＥＣＧセンサ、光電脈波検査（ＰＰＧ）センサ、赤外線センサ、活動センサ、無線周波数センサ、ソナーセンサ、光学センサ、ドップラーレーダーモーションセンサ、温度計、インピーダンスセンサ、圧電センサ、光学センサ、またはひずみゲージセンサのうちの１つからなる群から選択される。別の実施形態では、システムは、収集された作動データを受信し、ネットワークを介してデータを送信するように構成されたユーザデバイスを含む。別の実施形態では、機械学習コンプライアンス予測モデルは、予測を決定する際に患者に関連する環境データを分析する。別の実施形態では、機械学習コンプライアンス予測モデルは、予測を決定する際に患者に関連する人口統計データを分析する。別の実施形態では、機械学習コンプライアンス予測モデルは、使用量データおよび人口統計データのタイプ毎にｓｈａｐ値を提供する。別の実施形態では、収集された作動データは、使用持続時間、リークデータ、ＡＨＩ、およびマスクタイプを導出するために使用される。別の実施形態では、人口統計データは、患者の年齢および性別を含む。別の実施形態では、コンプライアンス分析エンジンは、調査から患者入力データを収集する。機械学習コンプライアンス予測モデルは、予測を決定する際に患者の入力データを分析する。別の実施形態では、システムは、コンプライアンス分析エンジンに結合されたディスプレイを含む。ディスプレイは患者のコンプライアンス予測を表示す。別の実施形態では、コンプライアンス予測は、治療期間を示すカレンダに表示される。別の実施形態では、カレンダは、過去のコンプライアンス日数を示す。別の実施形態では、カレンダは、コンプライアンス予測に基づいて、予想されるコンプライアンス周期の終了を示す。別の実施形態では、ディスプレイは、患者との最後の接触の試みに関する情報を示す。別の実施形態では、ディスプレイは、患者の連絡データを含む。
【0016】
別の開示された例は、呼吸療法レジメンに対する患者のコンプライアンスの予測を出力するコンプライアンス予測モデルを訓練する方法である。呼吸圧療法デバイスを使用する各患者集団から作動データを収集する。患者集団から人口統計データを収集する。作動データに基づいて患者集団からコンプライアンスデータを決定する。収集された作動データおよび人口統計データに基づいて、入力特徴セットを選択する。入力特徴セットで選択された収集された作動データおよび人口統計データと対応するコンプライアンスデータとを用いて、コンプライアンス予測モデルを訓練して、コンプライアンス予測を出力する。
【0017】
例示的な方法の更なる実施形態では、入力特徴セットの１つとして患者の集団に関する環境データを収集するステップを含む。別の実施形態では、例示的な方法は、入力特徴セットの各々についてコンプライアンス予測モデルを訓練し、ｓｈａｐ値を提供するステップを含む。別の実施形態では、入力特徴セットは、使用持続時間、リークデータ、ＡＨＩ、およびマスクタイプを含む。別の実施形態では、人口統計は、年齢および性別を含む。別の実施形態では、方法は、入力特徴セットの１つとして調査から患者入力データを収集するステップを含む。
【0018】
上記の概要は、本開示の各実施形態または各態様を表すことを意図するものではない。もしろ、上記の概要は、本明細書に記載された複数の新規な態様および特徴の例を提供するにすぎない。本開示の上記の特徴および利点、ならびに他の特徴および利点は、添付の図面および添付の特許請求の範囲と併せて、本発明を実施するための代表的な実施形態およびモードに関する以下の詳細な説明から容易に明らかになる。
本発明は、添付の図面を参照しながら、以下の例示的な実施形態の説明からよりよく理解される。
本発明は、添付の図面を参照しながら、以下の例示的な実施形態の説明からよりよく理解される。
【図面の簡単な説明】
【0019】
【図1】患者が使用する呼吸圧療法デバイスからデータを収集する健康分析システムの一例のブロック図である。
【図2A】本技術の一形態による呼吸圧療法デバイスを示す。
【図2B】本技術の一形態による呼吸圧療法デバイスの空気圧経路の概略図である。
【図2C】本技術の一形態による呼吸圧療法デバイスの電気構成要素の概略図である。
【図3】コンプライアンス予測のための機械学習モデルのトレーニングを可能にするデータ収集システムの例である。
【図4A】コンプライアンス予測のための機械学習モデルをトレーニングするためのデータの収集のブロック図である。
【図4B】コンプライアンス予測のための機械学習モデルのフロー図である。
【図6A】予測システムからの予測データを使用してアプリケーションによって生成されるインターフェースの画像例である。
【図7A】１日から９０日までの期間におけるコンプライアンスのコンプライアンス予測結果を示すコンプライアンスグラフの一例である。
【図7B】４日から９０日の期間におけるコンプライアンスのコンプライアンス予測結果を示すコンプライアンスグラフの一例である。
【図8A】アプリケーションにより生成される代替患者情報インターフェースの画面イメージである。
【図8B】患者詳細ウィンドウから表示されるカレンダ機能付き予測データを用いてアプリケーションによって生成される代替インターフェースの画面イメージである。
【図8C】患者詳細ウィンドウから表示される治療図の画面イメージである。
【図8D】患者詳細ウィンドウから表示される患者イベントのタイムラインの画面イメージである。
【図9A】患者記録ポップアップの画面イメージである。
【図9B】患者レビューポップアップの画面イメージである。
【図10】コンプライアンス予測を決定するために使用される患者データを収集するプロセスのフローチャートである。
【発明を実施するための形態】
【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】
ＥＭＲサーバ３１４は、システムの患者に固有の電子カルテ（ＥＭＲ）と、患者１１０と同様の疾患を有するより大きな患者集団との両方に共通の電子カルテ（ＥＭＲ）とを含む。電子カルテは時に電子健康記録（ＥＨＲ）とも呼ばれ、通常は患者の病歴を含み、以前の状況、治療、合併症と現在の状態を含む。ＥＭＲサーバ３１４は、例えば、患者が以前に治療を受けた病院に配置することができる。ＥＭＲサーバ３１４は、データサーバ３１２から受信したクエリに応答してＥＭＲデータをデータサーバ３１２に送信するように構成される。
【0084】
この例では、ＨＣＰサーバ３１６は、患者の呼吸療法を担当する医療提供者または在宅医療提供者（個人的なヘルスケア専門家または組織であってもよい）に関連している。ＨＣＰは、ＤＭＥまたはＨＭＥ（国内／家庭用医療機器プロバイダ）とも呼ばれる。ＨＣＰサーバ３１６は、プロセス３３２をホストすることができる。ＨＣＰサーバプロセス３３２の１つの機能は、データサーバ３１２から受信したクエリに応答して、患者に関連するデータをデータサーバ３１２に送信することである。
【0085】
いくつかの実施形態では、データサーバ３１２は、ＨＣＰサーバ３１６と通信して、ＨＣＰのエージェント（例えば、看護師）への通知または動作アドバイスをトリガするか、または様々なタイプのレポートをサポートするように構成される。実行されたアクションの詳細は、参加データの一部としてデータサーバ３１２によって記憶される。ＨＣＰサーバ３１６は、分析エンジン１４０およびモバイルデバイス１３２上のアプリケーションと通信するＨＣＰサーバプロセス３３２をホストする。
【0086】
例えば、ＨＣＰサーバプロセス３３２は、治療の最初の９０日のうちの連続する３０日間のうちの７０％の夜間に少なくとも４時間装置を使用するなど、コンプライアンス期間中に必要な使用を指定するコンプライアンス規則に従って、ＲＰＴデバイス１２２の使用に基づいてコンプライアンス分析を提供することができる。概要データ後処理は、使用時間を規則に準拠した最小継続時間と比較することにより、最新の期間が規則に準拠したセッションであるかどうかを判定することができる。この後処理の結果を「コンプライアンスデータ」と呼びます。医療提供者は、このコンプライアンスデータを使用して、ＲＰＴデバイス１２２および他のメカニズムを含むことができる治療をカスタマイズすることができる。支払人などの他の参加者は、コンプライアンスデータを使用して、患者に対する補償が可能であるか否かを判断することができる。したがって、この例では、プロセス３３２は、ユーザデバイス１７０または医療提供者に関連するワークステーションを介してアクセス可能な診断、コンプライアンス、および治療管理アプリケーションの一部とすることができる。コンプライアンスおよび治療管理アプリケーションの例としては、ＡｉｒＶｉｅｗ（登録商標）アプリケーションが挙げられる。あるいは、コンプライアンス予測は、コンプライアンス予測に応答して患者の呼吸療法を変更するためにＲＰＴデバイス１２２と通信するために使用されてもよい。
【0087】
データサーバ３１２、ＥＭＲサーバ３１４、およびＨＣＰサーバ３１６内のデータは、一般に、システム内の患者に関連する機密データであることを理解されたい。通常、患者は機密データを相手に送信するために許可を与える必要がある。サーバ３１２、３１４、および３１８が異なるエンティティによって動作する場合、サーバ３１２、３１４、および３１８の間でデータを送信するには、そのような許可が必要になることがある。
【0088】
この例では、機械学習エンジン１８０は、機械学習モデルによるコンプライアンス予測を提供するためにデータサーバ３１２によって実行される。プロセス３２２は、一般的な患者集団において、ＲＰＴデバイス１２２のような呼吸療法デバイスを使用する患者を追跡し、コンプライアンスデータを提供する。追加データは、患者人口統計データおよび環境などのコンテキストデータを含むことができる。コンプライアンスデータはユーザ人口統計データと組み合わされ、機械学習モデルを訓練して他の患者のコンプライアンスデータを予測することができる。
【0089】
図４Ａは、機械学習エンジン１８０の機械学習コンプライアンス予測モデルの訓練および利用プロセスを示す。患者の一般集団４００は、様々な入力データのセット４１０を生成する。この例では、入力データ４１０は、年齢などの人口統計情報、ＲＰＴデバイス１２２などの療法デバイスの使用からの作動データ、ＲＰＴデバイス１２２の使用量データ、およびコンプライアンスに関連する他の関連データを含むことができる。入力データ４１０は、一般患者集団４００のコンプライアンス結果も含む。大規模データセット４１０から機械学習モデル４２０を訓練して、コンプライアンスデータに関連する予測において十分な信頼性を提供する。訓練されると、機械学習モデル４２０は、コンプライアンス予測４４０を生成するために、患者１１０などの個々の患者からの入力４３０を受け入れることができる。
【0090】
機械学習モデルが訓練されると、それは、ユーザにコンプライアンス予測を提供するために、サーバ３１２などのサーバによって実行されることができる。図４Ｂは、訓練されたコンプライアンス予測モデル４２０を使用するプロセスを示す。モデル４２０には、患者から収集された患者情報、およびＲＰＴからの使用および作動データなどの他の関連データが入力される。次いで、コンプライアンス予測４４０は、訓練されたコンプライアンス予測モデル４２０によって出力される。
【0091】
図５Ａは、予測出力データを提供するために機械学習モデル４２０のデータを収集するフローチャート５００である。使用量データは、図１の患者１１０のような患者に関連するＲＰＴデバイス１２２のようなＲＰＴデバイスによって生成される。この例では、ＡｉｒＶｉｅｗ（登録商標）アプリケーションなどの診断、コンプライアンスおよび治療管理アプリケーション５１０を実行する医療提供者システムは、ＲＰＴデバイス１２２から使用量データを収集する。ＭｙＡｉｒ（登録商標）などの個人患者情報アプリケーション５２０は、図１のユーザデバイス１３２などのユーザデバイス上で患者に表示すために、収集された作動データをＲＰＴデバイス１２２から受信することができる。アプリケーション５１０、５２０で収集されたデータは、患者管理情報システム５３０で複製される。機械学習エンジン５４０は、データベース５４２から選択されたデータにアクセスする。コンプライアンス管理ＡＰＩ ５５０は、機械学習ルーチン５４０からの出力を受け取り、予測データを提供する。
【0092】
この例では、アプリケーション５１０は、マシンクラウドサービスモジュール５１２、マシンデータサービスモジュール５１４、およびアプリケーション５１６を含む。マシンクラウドサービス５１２は、図１のネットワーク１３６を介してＲＰＴデバイス１２２などのＲＰＴデバイスからデータを受信するためのＡＰＩを含む。マシンデータサービス５１４は、マシンクラウドサービス５１２が受信した全てのＲＡＷデバイスデータを記憶したデータベースを管理する。アプリケーション５１６は、図１のユーザデバイス１７０のように、医療提供者によって操作されるユーザデバイスと統合される。アプリケーション５１６は、患者の診断、患者のコンプライアンス分析、および患者の治療管理などの様々な目的のために、機械データサービス５１４からのデータのサブセットにアクセスする。
【0093】
患者管理情報システム５３０は、識別データストア５３２と、仮名データストア５３４と、完全匿名化データストア５３６とを含む。識別されたまたはオリジナルのデータベース５３２は、アプリケーション５１６によってアクセスされたデータベースおよびアプリケーション５２０によってアクセスされたデータベースに関連付けられたデータベースの複製である。仮名化ルーチンを使用して、識別されたデータリポジトリ５３２からのデータを処理して、名前およびアドレスのような保護された健康情報（ＰＨＩ）識別子を曖昧にし、データソースを結合してデータリポジトリ５３４を形成する。識別解除されたデータは、Ｈａｄｏｏｐ ＵｐｓｅｒｔｓおよびＩｎｃｒｅｍｅｎｔａｌｓ（ＨＵＤＩ）ＰＨＩバケット５３８に記憶され、コンプライアンス管理アプリケーションなどのアプリケーションにデータを引き込む効率を向上させる。これにより、同じ患者が２つのデータソース内で識別され、データリポジトリ５３４内で結合される。最後に、匿名化されたデータストア５３６を作成するために、別のプロセスを使用して、仮名化されたＰＨＩを完全に除去する。仮名を削除するＰＨＩは、データのプライバシーを保護することでセキュリティも向上する。
【0094】
この例では、機械学習エンジン５４０は、ＲｅｓＭｅｄによって開発されたインテリジェントヘルスシグナル（ＩＨＳ）システムである。機械学習エンジン５４０は、アプリケーション５１０および５２０から受信した患者固有データの形式で匿名化データリポジトリ５３６から匿名化データを受信するデータベース５４２を含む。例えば、診断、コンプライアンスおよび治療管理アプリケーション５１０は、名前および住所、ならびに装置の使用などの基本的な患者情報を提供し、パーソナルアプリケーション５２０は、年齢、性別およびマスクの選択などの患者に関するより多くの属性、ならびに特別なデータを提供する。この例では、パーソナルアプリケーション５２０は、ＲｅｓＭｅｄに固有のＡｉｒＶｉｅｗデータを提供する。機械学習エンジン５４０は、診断、コンプライアンスおよび治療管理アプリケーションからの入力および個人アプリケーション５２０からの患者特定データから患者コンテキスト検索の結果を受け取り、データベース５４２に記憶された患者予測を出力するコンプライアンス予測モデル４２０を含む。コンプライアンス管理アプリケーション５５０は、機械学習モデル４２０にアクセスし、患者管理情報システム５３０から受信した予測および患者識別データをコンプライアンスデータベース５５２に記憶する。コンプライアンス管理アプリケーション５５０は、機械学習エンジン５４０からコンプライアンス予測および他の匿名化データ、例えば保護された健康情報（ＰＨＩ）を受信し、元のデータベース５３２からＰＨＩデータを再導入する。コンプライアンス管理アプリケーション５５０は、コンプライアンスデータベース５５２から患者データを抽出し、医療提供者ユーザに提示すユーザアプリケーションによってアクセスすることができる。この例では、コンプライアンス管理アプリケーション５５０は、診断、コンプライアンスおよび治療管理アプリケーション５１０または診断、コンプライアンスおよび治療管理アプリケーション５１０のモジュールによってアクセス可能な別個の構成要素とすることができる。コンプライアンス管理アプリケーション５５０は、フィルタリングされたデータ、分類されたデータ、連絡患者に関連する情報などの使用量データを患者管理情報システム５３０に送り返すことができる。これにより、機械学習モデル４２０を更新するための潜在的なデータ量が増加し、介入を中心とした将来のモデルの構築が可能となり、患者コンプライアンスを予測するシステムの能力の全体的な精度が向上する。
【0095】
したがって、この例では、システム５００は、患者管理情報システム５３０に基づく識別された患者データと、機械学習エンジン５４０によって実行される患者コンテキスト探索（コンプライアンス違反リスクの計算を含む）からの機械学習モデル出力データとを組み合わせる。この例では、システム５００は、ＡＷＳなどのクラウドサービスを使用して、必要に応じてユーザにスケーラビリティを提供するように適合されていてもよい。
【0096】
この例では、機械学習モデル４２０は、特定の治療日の所定の患者が医療保険および医療補助サービスセンター（ＣＭＳ）コンプライアンス定義に到達する確率を予測する９０日コンプライアンス予測モデルに基づいている。具体的には、コンプライアンスとは、患者が治療の最初の９０日間、窓口期間の３０日間、連続２１日間、少なくとも４時間、装置を不連続に使用することと定義される。患者が最初の９０日以内に少なくとも１回この基準を満たせば、コンプライアンスを達成し、「コンプライアンス」と表示される。患者が基準を満たしていない場合は「苦情なし」と表示される。例示的なコンプライアンス予測モデルは、患者の治療の最初の９０日の間に患者を毎日予測するために使用される。このモデルの出力は、患者や他の参加者（医療機関など）のためのダウンストリームアプリケーションで利用可能である。
【0097】
予測は「分類」問題と呼ばれるが、これは一種の教師付き学習である。機械学習モデル４２０は、患者集団４００からの履歴データ、および治療の最初の９０日の間に生じたコンプライアンスなどに基づいて訓練される。そして、このモデルは新たな患者データに基づいて予測を行う。この例では、機械学習モデル４２０は、（０）に適合しないか（１）に適合するという２値結果を予測しようとする。予測の形式は、０と１の間の確率である。したがって、０．７３という予測値は、次のように解釈される。「この時点で、患者Ｘの７３％がコンプライアンスに到達する可能性があると考えている。」
【0098】
一般に「特徴」と呼ばれる入力データは、インテリジェントヘルス信号（ＩＨＳ）機械学習ルーチン５４０内の患者コンテキストサービス（ＰＣＳ）データベース５４２から得られる。この例では、ＰＣＳデータベース５４２は、患者データシステム５３０によって記憶された非ＰＨＩデータレイク内のＭｙＡｉｒ（登録商標）およびＡｉｒＶｉｅｗ（登録商標）テーブルからそのデータを取得する。データは、ＭＯＳＡＩＱのような任意の適切なデータベースフォーマットにフォーマットすることができる。保護された健康情報の非ＰＨＩデータ（年齢、性別、電子メールアドレスなど）がデータソースから削除されました。ＩＨＳルーチン５４０は、データレイク５３６から生データを取り出し、追加の前処理ステップの必要性を低減し、訓練モデル４２０の効率を高めるために、生データを再フォーマットする。ＩＨＳルーチン５４０は、データをＰＣＳデータベース５４２に保存する前に、データに対して動作を実行する。例としては、過去３日間の平均デバイス使用量を取得し、それを新機能として保存することが挙げられる。ＰＣＳシステムは、機械学習モデルが予測しようとする「目標」も生成する。コンプライアンス予測モデルの目標は、患者がコンプライアンスを達成しているか否かを構成する。例えば、ＣＭＳコンプライアンスの定義に基づく目標は、治療の最初の９０日のうち連続して３０日間、７０％の夜に少なくとも４時間、この装置を毎晩使用するように定義される。目標予測入力を形成する患者コンテキストサービスデータベース５４２内のいくつかの特徴は、ベースラインＡＨＩ、期間、性別、マスクタイプ記述、治療の調査原因、使用手段（例えば、３、７、１４、および２８日の手段）を含む。
【0099】
コンプライアンス予測モデルは、患者データシステム５３０内のコンプライアンスを満たすすべての患者の予測を出力する。この患者のサブセットは、データベースまたはデータレイク５３６から直接取得される。例えば、最初の９０日または治療中のすべての患者をデータレイク５３６から選択することができる。９０日間にわたって、機械学習モデルが日々、こうした新たな患者のコンプライアンスを新たに予測している。患者が治療を受ける時間が長くなるにつれて、患者は機械学習モデルに組み入れることができる使用量データの特徴をより多く生成することになる。例えば、患者がｎ日間の治療を受けた場合、その患者の有効な特徴は、過去ｎ日間の使用量の集計である。
【0100】
この例では、機械学習モデル４２０は、履歴データ特性および基本的な事実コンプライアンス目標を用いて訓練される。特性データとターゲットは、モデルを訓練するために使用される。内部では、モデルは特徴からターゲットへの関数マッピングをモデル係数として記憶する。モデルがより多くの例を見るようになると、モデルはその内部係数を更新して「学習」する。モデルが訓練されると、新しい入力特徴はコンプライアンスモデルの入力となり、コンプライアンスモデルは予測値を返す。この例でモデリングに使用されている技術スタックはｓｋｌｅａｒｎである。これはＰｙｔｈｏｎで最も一般的に使用されている機械学習パッケージである。モデルタイプを変更できる。したがって、論理回帰、ランダムフォレストなど、さまざまなタイプのモデルが存在する可能性がある。これらのモデル間の唯一の違いは、モデルマッピング関数の内部構造である。基本的に、コンプライアンスを予測できるモデルの種類はすべて同じ機能を実行する。
【0101】
コンプライアンス予測モデルが訓練されると、コンプライアンス予測モデルは、新しい患者データに基づいて予測を出力することができる。この例では、ｓｈａｐ値と呼ばれる付加的なワークピースがコンプライアンス予測モデルの予測とともに予測される。Ｓｈａｐはモデルの説明可能性のための機械学習ツールである。ｓｈａｐ値は、各特性が出力予測にどの程度寄与するかを示す。これにより、モデルのユーザは、例えば、「この人物は、過去７日間のマスクリークが少ないので、予測コンプライアンスが高い」（ここでは「ｍａｓｋ＿ｌｅａｋ＿７＿ｄａｙｓ」が特徴）といった結果を解釈することができるようになる（ここでは「ｍａｓｋ＿ｌｅａｋ＿７＿ｄａｙｓ」が特徴である）。この例では、コンプライアンス予測モデルの特徴は、年齢および性別のような人口統計データ、ベースラインＡＨＩのような患者応答データ、図１のユーザデバイス１３２によって実行されるアプリケーション操作の調査によって得られる治療の原因のような患者入力データ、および継続時間のような使用量データ、ならびにコンプライアンス分析エンジン１４０によって図１のＲＰＴデバイス１２２から収集された作動データから導き出される３、７、１４および２８日の平均値を超える使用量データを含むことができる。サンプル調査は、治療の原因、治療に対する反応、および主観的感覚に関連する問題を質問するために、ユーザデバイス１３２上のパーソナルアプリケーションによって提供され得る。そのため、調査では「どのくらい眠いと思いるか？」や「治療はどうなっているか？」といった質問をすることができる。これらの質問に対する回答をコンプライアンス予測モデルに追加することで、今後の訓練を改善することができる。
【0102】
図５Ｂは、コンプライアンスアプリケーション５５０が患者情報システム５３０および機械学習エンジン１８０から特性データを収集するプロセスの詳細な概略図である。コンプライアンスアプリケーション５５０は、患者情報システム５３０からの患者に関するデータを結合する抽出、変換およびロード（ＥＴＬ）モジュール５５４を含む。他のＥＬＴモジュール５５６は、機械学習エンジン５４０の機械学習データベース５４２から出力予測値を受信する。ＥＴＬモジュール５５４、５５６は、結果出力データをコンプライアンスアプリケーションデータベース５５２に送信する。ＡＰＩ５５８は、データベースにアクセスして、患者データおよび適切なコンプライアンス予測データを管理アプリケーション５１０などのアプリケーションに提供する。
【0103】
予測コンプライアンスデータは、将来のコンプライアンスを改善し、資源利用の効率を高め、呼吸器疾患の治療を増加させるために、いくつかの有益な方法によりシステム１００内で使用することができる。例えば、コンプライアンスデータは、ユーザデバイス１３２上の患者に通知して、患者をさらに刺激するか、またはコンプライアンス確率の低下の可能性を警告するために提供されてもよい。例えば、不一致の予測がある閾値レベルに達した場合、ユーザデバイス１３２上のアプリケーションは、インセンティブメディアを再生するための規則のセットを有することができる。定期的に、機械学習モデルの訓練は、機械学習モデルの精度を向上させるために、新しい患者データおよびコンプライアンス結果で更新されることができる。
【0104】
一組の患者のコンプライアンスデータを医療提供者に提供することができ、医療提供者は、非コンプライアンスの確率に基づいて患者を優先順位付けすることができる。コンプライアンス予測データは、医療提供者の主観的な判断を排除した客観的な予測である。潜在的なコンプライアンス違反の原因となる特定の特徴を医療提供者に通知として提供することができ、これらの特徴に対処するための戦略を設計することができる。不コンプライアンスの確率、および９０日間の移動中に不コンプライアンスが発生する時期は、医療提供者による介入の最適な形態、および患者に対する介入の最適な時期を決定するために使用され得る。規則エンジンは、ＲＰＴデバイス１２２の動作ルーチンの一部として動作して、非コンプライアンス予測を容易にする動作または使用特性を解決するためにＲＰＴデバイス１２２の動作を調整することができる。
【0105】
図６Ａは、図５ＢのコンプライアンスＡＰＩ５５８からの予測および患者データに基づいて医療提供者によってアクセス可能な診断、コンプライアンスおよび治療管理アプリケーションによって生成された例示的なインターフェース６００である。例示的なインターフェース６００は、医療提供者によって使用されるユーザデバイス１７０のようなユーザデバイスのワークステーションのディスプレイ上に生成することができる。例示的なインターフェース６００は、機械学習モデルからの関連予測データを医療提供者に有用な形式で提示すことを可能にする。
【0106】
この例では、インターフェース６００は、医療提供者に関連付けられた患者のリストを含む患者概要ウィンドウ６０２を含む。ウィンドウ６０２にリストされた各患者を選択することができ、選択された患者について詳細な患者データウィンドウ６０４を表示すことができる。概要ウィンドウ６０２に表示される患者は、検索タブ６１０、患者詳細タブ６１２、治療日数タブ６１４、コンプライアンス日数タブ６１６、コンプライアンスタブ６１８、およびその他タブ６２０のうちの１つを選択することによってフィルタリングされ得る。デフォルト表示では、患者概要ウィンドウ６０２にすべての患者が一覧表示される。リストされた各患者は、順序付けキーフィールド６２２を選択することにより順序付けされることができる。この例では、最も低いコンプライアンス予測を有する患者は、ウィンドウ６０２内のリストの最上部に表示される。コンプライアンス予測は、図５Ａの機械学習モデル５４４によって出力されたコンプライアンス予測から導出される。
【0107】
この例では、患者概要ウィンドウ６０２内の各リストは、コンプライアンススコア６３０、名前フィールド６３２、治療日フィールド６３４、完了コンプライアンス日フィールド６３６、およびコンプライアンス傾向グラフ６３８を含む。コンプライアンススコア６３０は、特定の患者データとデータを用いた機械学習モデルに基づくコンプライアンス予測出力である。治療日フィールド６３４は、９０日の治療タイムラインにおける患者の日付を示す。コンプライアンス完了日フィールド６３６は、患者がＲＰＴデバイス１２２を使用してコンプライアンスを完了することができる日数を示す。トレンドグラフ６３８は、コンプライアンスの予測が増加しているか減少しているかを示している。
【0108】
詳細患者データウィンドウ６０４は、患者情報フィールド６４０、コンプライアンス予測フィールド６４２、関連因子フィールド６４４、コンプライアンス概要フィールド６４６、コンプライアンス予測グラフ６４８、使用量グラフ６５０、ＡＨＩスコアグラフ６５２、およびリークグラフ６５４を含む。患者情報欄６４０には、患者名、生年月日、ＩＤ番号、個人申請の登録状況、電話番号、電子メールなどの患者情報が表示される。コンプライアンス予測フィールド６４２は、機械学習モデルによって決定されたコンプライアンスの予測パーセンテージを示す。
【0109】
上位予測係数フィールド６４４は、データ特性に基づくｓｈａｐ値が、コンプライアンス予測スコアの計算に最も影響を及ぼす入力データを示す。この例では、最も重要な５つの要因を示すことができる。この数値は、医療提供者によって調整されたり、デフォルトの数値に設定されたりすることができる。各因子は、図１のシステム１００によって収集された患者データおよび使用量データから決定される値を示す。各要素には対応するグラフがあり、緑はコンプライアンス予測へのポジティブな貢献を示し、赤はコンプライアンス予測へのネガティブな貢献を示す。この例では、プラス要因は患者の年齢と２８日間の平均使用量である。負の要因は、性別、使用の平均継続時間、および図１のユーザデバイス１３２のようなユーザデバイス上のアプリケーションインターフェース上での調査に応答して患者によって決定される複数の要因である。
【0110】
コンプライアンス概要フィールド６４６は、コンプライアンス概要に関連するバックグラウンド情報を含む。この例では、コンプライアンス概要フィールド６４６は、ＲＰＴデバイス１２２があるしきい値レベル（例えば４時間）を超えて使用された日数、患者が９０日のタイムラインにいた日数、９０日を完了するまでの残り日数、およびコンプライアンス見通しを含む。コンプライアンスアウトルックは、患者がコンプライアンスメントを達成するために必要なしきい値を超える使用日数を示す。
【0111】
コンプライアンス予測グラフ６４８は、過去３週間などの期間にわたって患者に決定されたコンプライアンス予測をプロットする。使用量グラフ６５０は、過去３週間のＲＰＴデバイス１２２の使用量データと、１回の使用時間をまとめたものである。リークグラフ６５４は、過去３週間にプロットされたＲＰＴデバイス１２２から収集された、図１のインターフェース１２４からのリークデータをプロットしている。
【0112】
無呼吸低呼吸指数（ＡＨＩ）スコアグラフ６５２は、過去３週間の間に決定されたＡＨＩスコアを示す。無呼吸低呼吸指数は、睡眠中の睡眠時無呼吸の重症度を示す指数である。ＡＨＩは、睡眠セッション中にユーザが経験した無呼吸および／または呼吸不足イベントの数を、睡眠セッション中の睡眠時間の合計数で除算することによって計算される。例えば、このイベントは、少なくとも１０秒間続く無呼吸であってもよい。この一時停止は、ＲＰＴデバイス１２２内のセンサまたはウェアラブルデバイス上の他のセンサによって決定されることができる。５未満のＡＨＩは正常であると考えられる。５以上１５未満のＡＨＩは、軽度の睡眠時無呼吸の指標と考えられる。１５以上３０未満のＡＨＩは、中等度の睡眠時無呼吸の指標と考えられる。３０以上のＡＨＩは、重篤な睡眠時無呼吸の徴候と考えられる。小児では、ＡＨＩが１を超えると異常とされる。ＡＨＩが正常な場合、またはＡＨＩが正常または軽微な場合、睡眠時無呼吸は「制御されている」と考えることができる。ＡＨＩはまた、閉塞性睡眠時無呼吸の重症度を示すために、酸素脱飽和レベルと組み合わせて使用することができる。
【0113】
図６Ｂは、特定の検索タブ６１０が選択された場合のインターフェース６００を示す。特定の検索タブ６１０により、ポップアップウィンドウ６６０が表示される。ポップアップウィンドウ６６０は、ユーザが電話番号、名前、姓、ＩＤおよび位置の特定の値を入力することを可能にする検索入力フィールド６６２を含む。複数の検索エントリフィールド６６２のうちの１つが入力されると、検索ボタン６６４を選択することができ、検索基準を満たす患者を患者概要ウィンドウ６０２に表示すことができる。電子メールなどの他のフィールドを検索用に提示すこともできる。
【0114】
図６Ｃは、患者詳細タブ６１２が選択されたときのインターフェース６００を示す。患者詳細タブ６１２は、ポップアップウィンドウ６６６を表示す。ポップアップウィンドウ６６６は、性別選択フィールド６６８、年齢スライド６７０、患者アプリケーション使用フィールド６７２、および再確認ステータスフィールド６７４を含むフィルタ制御を有する。性別フィールド６６８は、特定の性別の患者を選択することを可能にする。年齢スライド６７０は、スライダによって設定された特定の年齢の間で患者を選択することを可能にする。患者アプリケーション使用フィールド６７２およびステータスフィールドは、ＭｙＡｉｒ（登録商標）のような患者アプリケーションを使用する患者および医療提供者によってレビューされていない患者を選択することを可能にする。複数のフィルタのうちの１つが適用されると、適用ボタン６７６を選択することができ、フィルタ基準を満たす患者を患者概要ウィンドウ６０２に表示すことができる。
【0115】
図６Ｄは、治療中の日数タブ６１４が選択されたときのインターフェース６００を示す。治療中の日数タブ６１４により、ポップアップウィンドウ６８０が表示される。ポップアップウィンドウ６８０は、治療日数の範囲をユーザが設定することができる治療日数スライダを有する。治療範囲内の日数が選択されると、適用ボタン６８２が選択され、治療基準内の日数範囲内の患者を患者集計ウィンドウ６０２に表示すことができる。
【0116】
図６Ｅは、コンプライアンスの日数タブ６１６が選択されたときのインターフェース６００を示す。コンプライアンスタブ６１６により、ポップアップウィンドウ６８４が表示される。ポップアップウィンドウ６８６は、ユーザが治療日数の範囲を設定することを可能にするコンプライアンス日数スライダを有する。コンプライアンス範囲内日数が選択されると、適用ボタン６８６が選択され、コンプライアンス範囲内日数を満たす患者が患者集計ウィンドウ６０２に表示される。
【0117】
図６Ｆは、コンプライアンスタブ６１８が選択されたときのインターフェース６００を示す。コンプライアンスタブ６１８により、ポップアップウィンドウ６８８が表示される。ポップアップウィンドウ６８８は、ユーザが許容予測値の範囲を設定できる許容予測スライダを有する。コンプライアンス予測値の範囲が選択されると、アプリケーションボタン６８６が選択され、予測されたコンプライアンス範囲を満たす患者を患者概要ウィンドウ６０２に表示すことができる。
【0118】
図６Ｇは、データタブ６２０の使用量が選択された場合のインターフェース６００を示す。使用量データタブ６２０により、ポップアップウィンドウ６９２が表示される。ポップアップウィンドウ６９２は、マスクリークのパーセンテージ、ＡＨＩスコアの値、および時間単位の継続時間をフィルタとして選択することを可能にする一連のスライダ６９４を有する。マスクリーク、ＡＨＩおよび使用継続時間のいずれかまたはすべての適用範囲がスライダ６９４上で選択されると、適用ボタン６９６が選択され、選択された値を満たす患者が患者概要ウィンドウ６０２に表示され得る。
【0119】
図７Ａ～図７Ｂは、医療提供者による介入の機会を示しているが、そうでなければ、この機会は、いつ介入を行うかを決定する従来の方法に対して明らかではない。コンプライアンス確率が平均ＭＬ予測から著しく低下するたびにチャンスが発生する。例えば、最終的なコンプライアンスのより重要な決定要因であることが機械学習モデルによって理解されているので、第１週目の欠席治療日に割り当てられた重みは、治療の第２週目よりも高くなる。介入のタイミングを決定する既存の方法は、この重み付け機能を有していない。このようにして、特定されたこれらの患者に対して、呼吸器疾患の治療だけでなく、治療コンプライアンスを改善することができる。
【0120】
図７Ａは、１日コンプライアンスの欠如を予測する例示的な９０日コンプライアンス予測モデルのグラフ７００を示す。この例では、グラフ７００は、９０日のコンプライアンス期間におけるＲＰＴデバイスの使用時間をプロットしている。この例では、１日の使用時間が４時間であることが、コンプライアンスの５０％を超えるしきい値となっている。グラフ７００は、実際使用量のプロット７１０と、機械学習コンプライアンス予測モデルの出力のプロット７２０とを含む。
【0121】
実際の使用量のプロット７１０は、患者が最初２６日間連続してＲＰＴデバイスを使用しているが、多くの日が４時間閾値に達していないことを示している。２７日目は、ＲＰＴデバイスを使用していない最初の日である。３０日目と３３日目の２回の使用があり、コンプライアンスまで１日しか使用できなかったが、３４日目以降は残りの数日間は使用できなかった。
【0122】
機械学習プロット７２０は、９０日の期間にわたって毎日決定される異なる予測によって決定される。機械学習プロット７２０は、患者の人口統計や傾向などの他の入力要因を考慮しているため、日常使用量プロット７１０に比べてノイズが著しく小さい）。図６Ａに示すように、ｓｈａｐ値によって決定される主な特徴が決定され、表示される。通常、日常使用量は、コンプライアント確率の主要な決定要因であるが、それが唯一の決定要因ではないので、プロット７２０は、使用量プロット７１０よりもノイズが小さい。機械学習プロット７２０は予測であるので、医療提供者の介入機会の検出を可能にする。例えば、１２～１３日目には１０％（６５％～５５％）、２７日目には２０％（６９％～４９％）、３２日目には１４％（４３％～２９％）、３４～３６日目の間には１７％（３５％～１８％）となっている。低下が予測される期間は、医療提供者がコンプライアンスを改善しようとするために患者に介入することを可能にする。代替的に、従来は、コンプライアンスが著しく低下していることを判定し、自動的に患者アプリケーションによって患者を刺激することを試みることができる。
【0123】
図７Ｂは、４日間コンプライアンスの欠如を予測する例示的な９０日間コンプライアンス予測モデルのグラフ７５０を示す。この例では、グラフ７５０は、９０日のコンプライアンス期間におけるＲＰＴデバイスの使用時間をプロットしている。グラフ７５０は、実際の使用量のプロット７６０と、機械学習コンプライアンス予測モデルの出力のプロット７７０とを含む。
【0124】
実際の使用量のプロット７７０は、患者が１日目から２２日目までにＲＰＴデバイスを頻繁に使用し、そのうち２日間は使用していないことを示している。したがって、患者はコンプライアンスから４日しか離れていなかった。しかし、２３～３６日目の間、１４日連続で使用されなかった。３７～４５日目には、患者が７日間のコンプライアンスしか持たないように、頻繁かつ高い使用量があった。その後、４６～４９日目の不使用持続時間および４９日目の最終日の使用持続時間が続く
【0125】
機械学習プロット７７０は、９０日の期間にわたって毎日決定される異なる予測によって決定される。機械学習プロット７７０は予測であるので、医療提供者の介入機会の検出を可能にする。例えば、６日目には３５％（８２％～４７％）、１８日目には１８％（８６％～６８％）、２３～２４日目には４０％（８７％～４７％）、４７～４８日目には１０％（５９％～３８％）、５０日目には３７％（５４％～１７％）となっている。
【0126】
図８Ａは、図５ＢのコンプライアンスＡＰＩ５５８からの予測および患者データに基づいて、医療提供者によってアクセス可能な診断、コンプライアンスおよび治療管理アプリケーションによって生成された別の例示的なインターフェース８００である。例示的なインターフェース８００は、医療提供者のオペレータによって使用されるユーザデバイス１７０のようなユーザデバイスのワークステーションのディスプレイ上に生成することができる。図６Ａ～６Ｇのインターフェース６００と同様に、例示的なインターフェース８００は、機械学習モデルからの関連予測データを医療提供者に有用な形式で提示すことを可能にする。
【0127】
上記の例示的なインターフェース６００と同様に、インターフェース８００は、医療提供者に関連する患者のリストを含む患者概要ウィンドウ８０２を含む。ウィンドウ８０２は、図６Ａを参照して説明したウィンドウ６０２と同様の情報を有する。ウィンドウ８０２にリストされた各患者が選択され、選択された患者のために詳細な患者データウィンドウが表示されてもよい。概要ウィンドウ８０２に表示される患者は、検索タブ８１０、患者詳細タブ８１２、ユーザタブ８１４、ロケーションタブ８１６、設定からの日数タブ８１８、コンプライアンスタブ８２０、連絡先タブ８２２、およびその他タブ８２４のうちの１つを選択することによってフィルタリングされ得る。検索タブ８１０、患者詳細タブ８１２、設定からの日数タブ８１８、およびコンプライアンスタブ８２０は、図６Ａの対応するタブ６１０、６１２、６１６、６１８と同様の機能を有する。ユーザタブ８１４を選択することにより、オペレータは、特定の臨床ユーザ（自分自身を含む）によって管理されている患者へのフィルタダウンを行うことができる。ロケーションタブ８１６により、オペレータは、医療提供者または他のエンティティによって操作される異なる物理的な位置にサービスされる患者を下方向にフィルタリングすることができる。
【0128】
連絡先タブ８２２は、提供者のうちの誰かが患者に最後に連絡したことに基づいて患者を検索するフィルタを表示すウィンドウを表示すことを可能にする。この例では、連絡を試みると、操作者は、アプリケーションを介して連絡した患者を記録する。この例では、ウィンドウは、連絡ボタンのセットのうちの１つを選択することによって患者をフィルタリングすることを可能にする。連絡ボタンは、全患者を表示すための全患者ボタンを含む。もう１つの「連絡なし」ボタンを使用すると、医療サービス提供者組織の誰からも連絡を受けたことのない患者のリストを表示できる。「連絡」ボタンを選択すると、オペレータはスライダを使用して日付範囲を選択できる。すると、「連絡」ボタンには、スライドで指定した日付範囲内で連絡を取った患者が表示される。日付範囲の開始日は現在の日付である。スライダを３０＋に移動すると、３０日前に連絡があったすべての患者が一覧表示される。
【0129】
デフォルト表示では、患者概要ウィンドウ８０２にすべての患者が一覧表示される。リストされた各患者は、フィールド８２６による並べ替えを選択することによって順序付けすることができる。この例では、コンプライアンス予測が最も低い患者がウィンドウ８０２のリストの先頭に表示される。コンプライアンス予測は、図５Ａの機械学習モデル５４４によって出力されたコンプライアンス予測から導出される。患者は、最高のコンプライアンス予測のほか、設定からの日数、コンプライアンスまでの日数、連絡からの日数、フォローアップまでの日数だけでなく、最高から最低まで、または最低から最高までの日数など、他の基準によって並べ替えることもできる。
【0130】
この例では、患者概要ウィンドウ８０２内の各リストは、現在のコンプライアンス予測、名前フィールド、治療中の日数フィールド、および完了コンプライアンスの日数フィールドを含み、これらは、図６Ａのインターフェース６００内の対応するものと同じである。
【0131】
図８Ｂは、コンプライアンスタブ８２０が選択されたときのインターフェース８００を示す。コンプライアンスタブ８２０は、図６Ａに示すものと同様のコンプライアンススライダを表示し、ユーザが特定の患者のコンプライアンスおよび使用関連情報を参照できるようにする。フィルタリングされた患者概要ウィンドウ８３０にリストされた任意の患者、例えば選択されたリスト８３２を強調表示すことができる。患者リストが選択されると、リストは、患者と最後に連絡を取ってからの連絡タイプおよび時間を示す記号を含む。この例では、記号は、電話メッセージ、電子メールメッセージ、または患者への実際に完了したコールを表す。
【0132】
患者リスト８３２などの特定の患者リストが選択されると、患者概要ウィンドウ８３４がインターフェース８００上に表示される。患者概要ウィンドウ８３４は、患者情報フィールド８４０と、コンプライアンスオプション８４２、治療オプション８４４、およびタイムラインオプション８４６を含む患者データオプションのセットとを含む。
【0133】
この例では、患者情報フィールド８４０には、生年月日、患者ＩＤ、設定日、ステータス、電話番号、電子メールが表示されている。患者情報フィールドはまた、連絡済みとしてマークされたボタン８４８を含む。連絡済みとしてマークボタン８４８は、患者連絡窓口を開始する。この例では、オペレータは、患者との特定の接触を記録する異なる接触オプションを選択することができる。このオプションは、患者を電話で連絡しているようにマークする被呼オプションを含むことができる、患者の留守番ボイスメールとしてマークされた留守番ボイスメール、また、［Ｅメール送信済み］オプションを選択すると、患者がＥメールで連絡していることをマークできる。特定のオプションが選択されると、選択リスト８４２上の連絡先フィールドが更新される。また、オペレータは、患者との連絡履歴および連絡方法を示す患者との連絡履歴を見ることができる。連絡窓口は、オペレータがリストされた患者に自動的に連絡することを可能にする様々なアプリケーションに直接リンクすることもできる。例えば、オートダイヤルＡＰＩは、電話データを利用して患者に電話をかけたり、電子メールアプリケーションが電子メールを書いたりすることができる。
【0134】
この例では、コンプライアンス予測フィールド８５０を表示すコンプライアンスオプション８４２が選択されている。コンプライアンス予測フィールド８５０は、本明細書に記載されたプロセスに従って決定されたＣＭＳコンプライアンス規則に基づいて、リストされた患者が治療の最初の９０日以内にコンプライアンスになる可能性の結果計算をリストするコンプライアンス予測８５２を含む。この例では、コンプライアンス予測フィールド８５２はまた、図６Ａの予測因子フィールド６４４と同様のフィールドであるコンプライアンス予測領域８５４とは何かを含む。したがって、コンプライアンス予測領域８５４が何であるかは、コンプライアンス予測にプラスまたはマイナスの影響を与える要因を示すグラフを示している。コンプライアンス予測領域８５４はまた、３０日間などの特定の期間における予測履歴グラフを示す。
【0135】
コンプライアンス予測フィールド８５０は、コンプライアンス概要フィールド８５６、コンプライアンス展望セクション８５８、カレンダ８６０、コンプライアンスグラフ８６２、および使用量グラフ８６４も含む。コンプライアンス概要フィールド８５６は、コンプライアンス概要に関連するバックグラウンド情報を含む。この例では、コンプライアンス概要フィールド８５６は、ＲＰＴデバイス１２２がセットアップされた日数、９０日間の治療が完了した残り日数、およびセットアップ後に４時間を超えてＲＰＴデバイス１２２が使用された日数および日数のパーセンテージを含む。
【0136】
コンプライアンスアウトルックセクション４５８は、患者が欠席した日数と、患者がコンプライアンスに達するまでの日数と日付を示すテーブルを一覧表示す。コンプライアンスアウトルックセクション８５８およびカレンダ８６０は、患者がＣＭＳ規則に従ってコンプライアンスの使用を１日以上逃すと、コンプライアンスを達成するための患者の能力に影響を及ぼす可能性のある様々なシナリオをオペレータに理解させる。
【0137】
カレンダ８６０は、１つの灰色の陰影に予測された３０日間のウィンドウを有する日と、別の灰色の陰影に患者データの最後の更新を有する後に予測された３０日間のウィンドウを有する日とを含む２か月間のウィンドウを示す。患者が治療に従った日ごとに三角形が表示されている。アスタリスクは、コンプライアンスが達成される予定日を示す。もちろん、他のインジケータおよび形状は、コンプライアンス時間を表示すためにカレンダ８６０とともに使用されてもよい。
【0138】
オペレータは、コンプライアンスアウトルック部８５８の行をクリックすることにより、カレンダ８６０上で予測される３０日間のコンプライアンスウィンドウシナリオを見ることができる。３０日間のコンプライアンス窓口の移動に伴い、患者がデバイスを使用しなければ、コンプライアンスの達成に必要な総日数が増加する。たとえば、コンプライアンスアウトルックセクション８５８で２行目が選択されている場合、カレンダには異なる影の日が表示され、星印は２日間移動する。
【0139】
コンプライアンスグラフ８６２は、最初の９０日間についてプロットされたコンプライアンスの割合の履歴グラフであり、特定のアウトリーチイベントが患者コンプライアンスにどのように影響するかをユーザが見ることを可能にする。コンプライアンスグラフ８６２は、特定の日におけるコンプライアンスの予測パーセントを示すプロットを含む。電話メッセージ、電子メール、または成功した電話会話などの連絡イベントは、図上の連絡記号８７０によって特定される。各接触のタイプは、患者と接触しようとするタイプを示す特定の記号を有する。現在の３０日間は、影付きセクション８７２によって強調表示される。
【0140】
使用量グラフ８６４は、使用量が発生した時間に関してプロットされた、治療の最初の９０日間の使用量を表す棒グラフを含む。バー８７４の中には、４時間を超える使用持続時間を示すものもあり、緑色に着色されていてもよい。他のバー８７６は、４時間未満の使用持続時間を示し、赤色に着色されていてもよい。使用しない日は中空バー８７８で設計することができる。断片化された使用量グラフ８６４により、ユーザは、セッションを迅速に表示し、マスクオン／オフイベントのカウントを表示して、患者の会話にさらなるコンテキストを提供することができる。
【0141】
図８Ｃは、コンプライアンスタブ８２０がアクティブ化され、リスト８３２などの選択されたリストが選択されたときのインターフェース８００を示す。この例では、治療オプション８４４が、表示された患者概要ウィンドウ８３４で選択されている。治療オプション８４４が選択されると、無呼吸低呼吸指数（ＡＨＩ）スコアグラフ８８０およびリークグラフ８８２が、選択された患者のリスト８３２に表示される。この例では、ＡＨＩグラフ８８０は、図６Ａのスコアグラフ６５２に類似しており、過去３週間の間に決定されたＡＨＩスコアを示している。リークグラフ８８２は、選択された患者について、過去３週間の間にＲＰＴデバイス１２２から収集された図１のインターフェース１２４からのブリードデータをプロットする。
【0142】
図８Ｄは、コンプライアンスタブ８２０がアクティブ化され、リスト８３２などの選択されたリストが選択されたときのインターフェース８００を示す。この例では、タイムラインオプション８４６は、表示された患者概要ウィンドウ８３４内で選択されている。タイムラインオプション８４６が選択されると、選択された患者に関連するイベントのタイムライン８９０が表示される。タイムライン８９０は、日付、コンプライアンスサイクルの開始後の日数、患者との連絡、フォローアップリマインダ、およびボタン８４８にマークされた注釈によってリストされたイベントを含む。
【0143】
図９Ａは、ボタン８４８としてマークされたときに表示される連絡オプションの１つを選択することによって表示される連絡およびフォローアップポップアップ９００を示す。この例では、オプションには、被呼側オプション、左ボイスメールオプション、および電子メールオプションがある。この例では、ポップアップウィンドウ９００は、呼び出されたオプションを選択することによってアクティブ化される。ポップアップウィンドウ９００は、マスクの快適性およびフィット性、リークの問題、コンプライアンスを満たすのに必要な日数、および患者と通信するための再教育などの一般的な注釈を有するチェックボックスを含む注釈セクション９１０を有する。その他のフィールドでは、その他のメモを入力できる。選択された日数後の患者のフォローアップを示すために選択可能なフォローアップフィールド９１２が表示される。フォローアップフィールド９１２は、フォローアップされた特定の日付のリストと、フォローアップされた日付を示すカレンダ９２０とを含む。フォローアップメモフィールド９２２により、ユーザはフォローアップのための追加メモを入力することができる。保存ボタン９３０により、ユーザはウィンドウ９３０からフォローアップデータを保存することができる。
【0144】
図９Ｂは、ボタン８４８内でレビュー済みとしてマークされたオプションを選択することによって表示されるレビュー済み患者ウィンドウ９５０を示す。ポップアップウィンドウ９５０は、コンプライアンスを満たすのに必要な日数、最近のマスク交換、連絡するには早すぎるなど、検査対象の患者に関する共通のメモを記載したチェックボックスを含むメモセクション９５２を有する。その他のフィールドでは、その他のメモを入力できる。フォローアップフィールド９５４が表示され、これを選択すると、選択された日数後の患者のフォローアップを示すことができる。保存ボタン９５６により、ユーザはウィンドウ９５０から患者が検査したデータを保存することができる。
【0145】
図１０は、システム１００によって実行されるデータ収集および予測ルーチンのフローチャートを示す。図１０のフローチャートは、図１の患者１１０の健康状態を決定するために使用されるデータを収集するために、コンプライアンス分析エンジン１４０の機械読み取り可能な命令によって実施され得る例示的なルーチンを表す。この例では、機械読み取り可能な命令は、（ａ）プロセッサ、（ｂ）コントローラ、および／または（ｃ）１つまたは複数の他の適切な処理デバイス（複数可）によって実行されるアルゴリズムを含む。アルゴリズムは、フラッシュメモリ、ＣＤ－ＲＯＭ、フロッピー（登録商標）ディスク、ハードディスクドライブ、ソリッドステートドライブ、デジタルビデオ（多機能）ディスク（ＤＶＤ）、または他のメモリデバイスなどの有形媒体上に記憶されたソフトウェアに具現化することができる。しかしながら、アルゴリズム全体および／またはその部分は、プロセッサ以外のデバイスによって代替的に実行され、および／または、公知の方法でファームウェアまたは専用ハードウェアに含まれてもよいことは、当業者には容易に理解されるであろう（例えば、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、フィールドプログラマブル論理デバイス（ＦＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理などによって実装されてもよい）。例えば、インターフェースの任意またはすべての構成要素は、ソフトウェア、ハードウェア、および／またはファームウェアによって実装されてもよい。さらに、フローチャートによって表される機械読み取り可能な命令の一部または全てを手動で実装することができる。さらに、例示的なアルゴリズムが図１０に示されたフローチャートを参照して説明されているが、例示的な機械読み取り可能な命令を実装する他の多くの方法が代替的に使用されてもよいことは、当業者であれば容易に理解されるであろう。例えば、ブロックの実行順序を変更することができ、および／または、記載されたブロックのいくつかを変更、削除、または結合することができる。
【0146】
システムは、最初に、ＲＰＴデバイス１２２（９００）から収集された作動データを監視する。この例では、コンプライアンス分析エンジン１４０は、ＲＰＴデバイス１２２上のセンサから作動データを収集し、タイムスタンプおよび患者識別情報を割り当てる。作動データは、図１のネットワーク１３６を介してコンプライアンス分析エンジン１４０に送信される（１００２）。コンプライアンス分析エンジン１４０は、収集された作動データからある入力特徴を導出する（１００４）。これらの入力特徴には、使用持続時間、リークデータ、およびマスクタイプが含まれる。入力特徴は、図４Ａ（１００６）の機械学習データベース４５２に記憶される。コンプライアンス分析エンジン１４０は、図１の外部データベース１６０から、年齢および性別などの患者人口統計に関連する入力特徴を導出する（１００８）。次に、入力特徴を機械学習モデルに入力する（１０１０）。
【0147】
出力コンプライアンス予測を記憶する（１０１２）。各入力特徴についてｓｈａｐ値を決定する（１０１４）。データベース１６０からの結果予測および患者情報は、システム１００内の他のアプリケーションへの送信のためにＡＰＩによって出力される（１０１６）。
【0148】
本明細書で使用されるように、用語「構成要素」、「モジュール」、「システム」などは、一般に、コンピュータに関連するエンティティ、ハードウェア（例えば、回路）、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または１つまたは複数の特定の機能を有する動作機械に関連するエンティティを意味する。例えば、構成要素は、プロセッサ（例えば、デジタル信号プロセッサ）上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであってもよいが、これらに限定されるものではない。たとえば、コントローラ上で実行されるアプリケーションとコントローラの両方を構成要素にすることができる。１つまたは複数の構成要素は、実行中のプロセスおよび／またはスレッド内に存在することができ、構成要素は、１つのコンピュータ上でローカライズされ、および／または、２つ以上のコンピュータ間で分散されることができる。さらに、「デバイス」は、特別に設計されたハードウェアの形で現れることができる。ハードウェアが特定の機能を実行することを可能にするソフトウェアを実行することによって特化された汎用ハードウェア、コンピュータ読み取り可能な媒体に記憶されたソフトウェアまたはその組み合わせ。
【0149】
本明細書で使用される用語は、特定の実施形態を説明する目的でのみ使用され、本発明を限定することを意図していない。本明細書で使用されるように、単数形「１つ（ａ）」、「一（ａｎ）」および「前記（ｔｈｅ）」は、文脈上別段の指示がない限り、複素数形も含む。さらに、用語「含む」、「含む」、「有する」、またはそれらの変形が、詳細な説明および／または特許請求の範囲において使用される場合、これらの用語は、用語「含む」と同様の方法で含まれることが意図される。
【0150】
別段の定義がない限り、本明細書で使用されるすべての用語（技術用語および科学用語を含む）は、当業者が一般に理解するものと同じ意味を有する。さらに、用語、例えば、一般的な辞書で定義されている用語は、その分野の文脈での意味と一致する意味を有するものとして解釈されるべきであり、ここで明示的に定義されない限り、理想的または過度に正式な意味で解釈されることはない。
【0151】
以下の請求項１～５８のうちのいずれか１つまたは複数からの１つまたは複数の要素、態様またはステップ、またはその任意の部分（複数可）を、他の請求項１～５８またはその組み合わせからの１つまたは複数の要素、態様またはステップ、またはその任意の部分と組み合わせて、本開示の１つまたは複数の追加の実施形態および／または請求項を形成することができる。
【0152】
以上、本発明の様々な実施形態について説明したが、これらは限定ではなく例としてのみ提示されることが理解されるべきである。本発明は１つまたは複数の実施形態について図示および説明されているが、本明細書および添付図面を読み理解することに基づいて、同等の変更および修正が生じるか、または当業者が既に知っている。さらに、本発明の特定の特徴は、いくつかの実施形態のうちの１つにのみ開示されているかもしれないが、この特徴は、他の実施形態の１つまたは複数の他の特徴と組み合わせることができ、これは、任意の所与または特定のアプリケーションにとって望ましい。したがって、本発明の範囲および範囲は、上記の実施形態のいずれによっても限定されるべきではない。むしろ、本発明の範囲は、以下の請求項およびその均等物に基づいて定義されるべきである。
【図1】
【図2A】
【図2B】
【図2C】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6A】
【図6B】
【図6C】
【図6D】
【図6E】
【図6F】
【図6G】
【図7A】
【図7B】
【図8A】
【図8B】
【図8C】
【図8D】
【図9A】
【図9B】
【図10】
【国際調査報告】