JP6697401B2 - 呼吸器治療デバイスの遠隔診断 - Google Patents

Description

［関連出願の相互参照］
本出願は、２０１４年５月２７日に出願されたオーストラリア仮出願第２０１４９０１９９７号の利益を主張し、この全体開示を参照として本明細書に含む。

［発明の分野］
１．１（１）技術の分野
本発明の技術は、呼吸器関連疾患の検出、診断、治療、予防および改善に関連して使用され得る医療機器に関する。

１．２（２）関連技術の説明
１．２．１ 人呼吸器系とその疾患
身体の呼吸器系は、ガス交換を促進する。鼻と口は、患者の気道の入口を形成する。

気道は一連の気管支を含み、これらの気管支は、肺内に深く入り込むほど狭く、短くなり、数が増える。肺の主要機能は、ガス交換であり、酸素を空気から静脈血中に移動させ、二酸化炭素を外に出すことができる。気管は、左右の気管支に分かれ、さらに最終的に終末細気管支に分かれる。気管支は、導管の気道を作り、ガス交換には関与しない。気道のさらなる分岐は、呼吸細気管支となり、最終的に肺胞になる。肺の胞状領域は、ガス交換が行われる場所であり、呼吸領域と呼ばれる。Ｊｏｈｎ Ｂ． Ｗｅｓｔ著「呼吸生理学」Ｌｉｐｐｉｎｃｏｔｔ Ｗｉｌｌｉａｍｓ ＆ Ｗｉｌｋｉｎｓ、第９版、２０１１年発行を参照する。

広範囲な呼吸器疾患が存在する。呼吸器疾患の一部の例としては、閉塞性睡眠時無呼吸（ＯＳＡ）、チェーン−ストークス呼吸（ＣＳＲ）、肥満過呼吸症候群（ＯＨＳ）、慢性閉塞性肺疾患（ＣＯＰＤ）、神経筋疾患（ＮＭＤ）または胸壁疾患を挙げることができる。

そうでない場合、健康な個体は、システムおよびデバイスを利用して呼吸器疾患の発症を防ぐことができる。

１．２．２ 治療
経鼻持続的気道陽圧（ＣＰＡＰ）治療法は、閉塞性睡眠時無呼吸症（ＯＳＡ）の治療に使用されてきた。この仮説は、持続的気道陽圧が空気圧の副木として作用し、軟口蓋および舌を前に押し出し、後口咽頭壁から離れるようにすることによって、上気道の閉塞を防ぐことができるということである。

非侵襲性換気（ＮＩＶ）は、患者が十分な呼吸を行うことおよび／または体内の酸素レベルを適切に維持することを支援するために、呼吸作業の一部またはすべてを行って、上気道を通して患者に換気補助を提供する。換気補助は、患者のインターフェースを介して提供される。ＮＩＶは、ＣＳＲ、ＯＨＳ、ＣＯＰＤ、ＭＤおよび胸壁障害の治療に使用されてきた。

侵襲性換気（ＩＶ）は、もはや自ら効果的に呼吸できない患者に換気補助を提供し、気管切開チューブを使用して提供される。

人工呼吸器は、患者に注入された呼吸のタイミングおよび圧力を制御し、患者が行う呼吸をモニタリングすることができる。患者の制御およびモニタリング方法は、通常、従量式の方法および従圧式の方法を含む。従量式の方法は、特に、圧力制御従量式換気（ＰＲＶＣ）、従量換気（ＶＶ）および従量式調節連続強制換気（ＶＣ?ＣＭＶ）技法を含むことができる。従圧式の方法は、特に、補助調節（ＡＣ）、同期的間欠的強制換気（ＳＩＭＶ）、調節機械換気（ＣＭＶ）、圧力補助換気（ＰＳＶ）、持続的気道陽圧（ＣＰＡＰ）または呼吸終末陽圧（ＰＥＥＰ）技法を含む。

１．２．３ システム
治療システムは、呼吸圧力治療デバイス（ＲＰＴデバイス）、空気回路、加湿器、患者インターフェースおよびデータ管理を含むことができる。

１．２．４ 患者インターフェース
患者インターフェースは、例えば、呼吸できるガスの流れを提供することによって、呼吸デバイスをユーザにインターフェースするのに使用できる。呼吸できる空気の流れは、鼻および／または口へのマスク、口へのチューブまたはユーザの気管への気管切開チューブを介して提供され得る。適用される治療法に応じて患者インターフェースは、治療を行うための周囲圧力で十分な変化時の圧力、例えば、約１０ｃｍＨ_２Ｏの陽圧で、ガスの供給を促進するために、例えば、患者の顔領域にシールを形成することができる。酸素の送達などの他の治療法の場合、患者インターフェースは、約１０ｃｍＨ_２Ｏの陽圧で、ガスの気道への供給を促進するのに十分なシールを含まないことができる。

患者インタフェースのデザインにはいろいろな難問がある。顔面は複雑な３次元の形状をしている。鼻のサイズと形は個人でかなり異なる。頭部には骨、軟骨と軟組織があり、顔面の異なる領域は機械的な力に対して異なる反応をする。顎または下顎は頭蓋のほかの骨に関連して動くことができる。頭全体が呼吸治療の過程で動くことができる。

これらの難問のために、マスクに応じて閉塞性であり、審美的に好ましくなく、コストが高く、装着が不十分であり、使用困難の１つまたはそれ以上の問題に悩み、長期間使用すると摩耗するとかまたは患者がシステムに不慣れだと不愉快である。例えば、飛行士専用にデザインされたマスク、個人の保護装置（例えば、フィルターマスク）の一部としてデザインされたマスク、ＳＣＵＢＡマスク、または麻酔薬投与のためのマスクは、本来の適用には耐えるが、長期間、例えば、数時間着用するのは好ましくないほど不愉快である。この不快感は、治療に対する患者のコンプライアンスの低下につながる。睡眠中にマスクを着用しなければならない場合は、特にそうである。

患者が治療に従う限り、ＣＰＡＰ治療は、特定の呼吸器疾患の治療に特に効果的である。マスクが不愉快であるか使用困難であれば、患者は治療に従わないかもしれない。患者は自分のマスクを定期的に洗浄するようしばしば推奨されているので、マスクの洗浄が困難であれば（例えば、組立または分解が困難）、患者は自分のマスクを洗浄しないかもしれず、これは患者のコンプライアンスに影響する。

その他の適用（例えば、飛行士）のためのマスクを睡眠呼吸障害に使用するのは適切でないかもしれないが、睡眠呼吸障害に使用するようデザインされたマスクはその他の適用に適しているかもしれない。

これらの理由により、睡眠中の鼻ＣＰＡＰの送達のための患者インタフェースは独特な分野である。

１．２．４．１ シール形成部
患者インタフェースは、シール形成部を含むことができる。これは、患者の顔面と直接接触するので、シール形成部の形状と構成とは、患者インタフェースの有効性と快適さに直接影響を与えることができる。

患者インタフェースは、シール形成部分が使用中の顔面の何処と係合するがデザイン意図によって、一部特徴付けられる。患者インタフェースの１つの形態において、シール形成部は、左と右のそれぞれの鼻孔に当たる２つのサブ部分を有することができる。患者インタフェースの１つの形態において、シール形成部分は使用中に両方の鼻孔を囲む単一の要素であり得る。このような単一の要素は、例えば、顔面の上唇領域と鼻梁領域を覆うようにデザインすることができる。患者インタフェースの１つの形態において、シール形成部分は、例えば、顔面の下唇領域上にシールを形成するなど、使用中の口の領域を囲む要素からなり得る。患者インタフェースの１つの形態において、シール形成部分は、使用中の両方の鼻孔と口の部分を囲む単一の要素からなり得る。患者インタフェースのこれらの異なるタイプは、それらの製造者が付けた種々の名称で知られており、鼻マスク、顔全体マスク、鼻枕、鼻噴霧および口腔鼻マスクが含まれる。

患者の顔の１領域で効果的なシール形成部分は、患者の顔の形状、構造、ばらつきおよび敏感な部分が異なるので、別の領域には適していないことがある。例えば、患者の額を覆う水中メガネのシールを患者の鼻に使用するには適当でない。

さまざまな異なる顔の形状およびサイズに適し、快適で効果的な１つのデザインのように、大量生産用として特定のシール形成部をデザインすることができる。患者の顔の形状と大量生産された患者のインタフェースのシール形成部の間に不整合（ｍｉｓｍａｔｃｈ）がある程度に、１つまたは全てを充足させてシールを形成しなければならない。

シール形成部分の１つのタイプは、患者インタフェースの周辺附近に伸び、シール形成部分が患者の顔に係合しようとしており、力が患者インタフェースに加えられた時に患者の顔に対してシールするように意図されている。シール形成部分は、空気または液体で満たされたクッション、またはゴムなどのエラストマーでできた弾性シール要素の成形または形成面を含むことができる。このタイプのシール形成部では、適合（ｆｉｔ）が適切でない場合、シール形成部分と顔との間に間隔が存在し、シールを達成するために顔に対して患者インタフェースに追加の力を加える必要がある。

シール形成部のもう１つタイプは、マスクの周辺近辺に位置した薄い材料からできたフラップシールを含み、マスク内に陽圧がかかると患者の顔に対抗してセルフシーリングを行う。シール形成部分の以前のタイプのように、顔面とマスクとの間の整合（ｍａｔｃｈ）が良好でないと、シールを形成するのに追加の力が必要になるかまたはマスクから漏れが生じる。さらに、シール形成部分の形状が患者のそれに整合しない場合、使用中にしわが生じたり曲がることがあり、漏れが発生する。

シール形成部分のもう１つのタイプは、例えば、鼻孔への挿入のような摩擦嵌合要素を含むことができる。

シール形成部分のもう１つの形態は、接着剤を使用してシールを達成することができる。顔面に接着剤を絶えず適用し、これを除去するのが不便と感じる患者もいる。

ＲｅｓＭｅｄ Ｌｉｍｉｔｅｄに譲渡された以下の特許出願に、さまざまな患者インタフェース・シール形成部の技術が開示されている：ＷＯ １９９８／００４，３１０； ＷＯ ２００６／０７４，５１３； ＷＯ ２０１０／１３５，７８５。

鼻枕の１つの形態がＰｕｒｉｔａｎ Ｂｅｎｎｅｔが製造するＡｄａｍ Ｃｉｒｃｕｉｔに見出される。また他の鼻枕または鼻噴霧は、Ｐｕｒｉｔａｎ−Ｂｅｎｎｅｔ Ｃｏｒｐｏｒａｔｉｏｎに譲渡された米国特許第４，７８２，８３２号（Ｔｒｉｍｂｌｅ外）の主題である。

ＲｅｓＭｅｄ Ｌｉｍｉｔｅｄは、鼻枕を導入する以下の製品を製造した：ＳＷＩＦＴ 鼻枕マスク、ＳＷＩＦＴ ＩＩ鼻枕マスク、ＳＷＩＦＴ ＬＴ鼻枕マスク、ＳＷＩＦＴ ＦＸ鼻枕マスクおよびＬＩＢＥＲＴＹフルフェース・マスク。ＲｅｓＭｅｄに譲渡された以下の特許出願に、鼻枕マスクの例を説明している。国際特許出願ＷＯ ２００４／０７３，７７８（特に、ＲｅｓＭｅｄ ＳＷＩＦＴ鼻枕の特徴を記載）、米国特許出願第２００９／００４４８０８号（特に、ＲｅｓＭｅｄ ＳＷＩＦＴ ＬＴ鼻枕の特徴を記載）；国際特許出願ＷＯ ２００５／０６３，３２８とＷＯ ２００６／１３０，９０３（特に、ＲｅｓＭｅｄ ＬＩＢＥＲＴＹフルフェース・マスクの特徴を記載）；国際特許出願ＷＯ ２００９／０５２，５６０（特に、ＲｅｓＭｅｄ ＳＷＩＦＴ ＦＸ鼻枕の特徴を記載）。

１．２．４．２ 位置決めと安定化
陽圧空気治療に使用する患者インタフェースのシール形成部は、シールを崩壊しようとする空気圧の相応した力の影響を受ける。このように、シール形成部を位置決めし、顔面の適当な部分とシーリングの関係を保持するために種々な技術が使用されてきた。

１つの技術は、接着剤の使用である。例えば、米国特許出願公開第ＵＳ２０１０／００００５３４号を参照する。

また他の技術は、１つまたはそれ以上のストラップおよび／または安定化装着帯域の使用である。このような装着帯域の大部分は、１つまたはそれ以上の不適合、かさばる、不快さおよび使用がぎこちないの問題に悩まされる。

１．２．５ 呼吸圧力治療（ＲＰＴ）デバイス
睡眠呼吸障害の治療に使用する１つの既知のＲＰＴデバイスは、ＲｅｓＭｅｄが製造したＳ９ Ｓｌｅｅｐ Ｔｈｅｒａｐｙ Ｓｙｓｔｅｍである。ＲＰＴデバイスのまた他の例は、人工呼吸器である。成人および小児用の人工呼吸器のＲｅｓＭｅｄ Ｓｔｅｌｌａ^ＴＭシリーズのような人工呼吸器は、これらの限定されないが、ＮＭＤ、ＯＨＳおよびＣＯＰＤのような多数の状態を治療するために、広範囲な患者に、侵襲性および非侵襲性依存性呼吸に対する支持を提供することができる。ＲＰＴデバイスは、また、流れ発生器としても知られている。

ＲｅｓＭｅｄ Ｅｌｉｓｅｅ^ＴＭ１５０人工呼吸器とＲｅｓＭｅｄ ＶＳＩＩＩ^ＴＭ人工呼吸器とは、多数の状態を治療するために、成人または小児患者に適した、侵襲性および非侵襲性依存性換気に対する支持を提供することができる。これらの人工呼吸器は、単一肢または二重肢の回路に容量および大気の換気モードを提供する。

ＲＰＴデバイスは、一般的に、モータ駆動の送風機または圧縮ガスリザーバのような圧力発生器を備え、患者の気道に空気の流れを供給するように構成される。いくつかの場合では、空気の流れを陽圧で患者の気道に供給することができる。ＲＰＴデバイスの出口は、前述したように、患者のインタフェースに空気回路を介して接続される。

ＲＰＴデバイスは、また一般的に、入口フィルター、様々なセンサおよびマイクロプロセッサーベースのコントローラを備えている。送風機は、サーボ制御モータ、渦巻きおよびインペラを備えている。いくつかの場合では、モータのブレーキは、モータおよびインペラの慣性を克服するために、送風機の速度をさらに急速に低下させるように実現することができる。ブレーキングにより、送風機が、慣性にもかかわらず、呼気と同期化に合うようにより低圧の条件をさらに急速に達成できるようになる。いくつかの場合では、圧力発生器は、さらに、モータ速度制御に対する代替手段として、患者に運ばれる圧力を変化させるための手段として、発生された空気を大気に排出可能な弁を備えるこどができる。センサは、例えば、圧力トランスデューサまたはこれに類するものとともに、特に、モータ速度、質量流量および出口の圧力を測定する。コントローラは、一体化したデータ抽出および表示機能の有無にかかわらず、データ記憶容量を含むことができる。

１．２．６ 加湿器
加湿せずに呼吸可能な気体の流れを患者の気道に伝えることは、気道の乾燥を引き起こすことができる。医療加湿器は、必要なときに、一般的に、患者が（例えば、病院で）眠っているまたは休んでいるときに、周囲の空気に関連して、呼吸可能な気体の流れの湿度および／または温度を増加させるのに使用される。結果的に、医療加湿器は、ベッドサイドの配置に対して小さいことが好ましく、患者の周囲を加湿および／または加熱せずに、患者に伝えられる呼吸可能な気体の流れを加湿ならびに／あるいは加熱するように構成されるのが好ましい。例えば、部屋ベースのシステム（例えば、サウナ、空気調節器、蒸発冷却器）もまた、患者に吸入される空気を加湿および／または加熱できるが、これらのシステムは、部屋全体を加湿および／または加熱することによって行うため、居住者に対する不快感を引き起こすことができる。

流れ発生器またはＲＰＴデバイスおよび患者インターフェースを有する加湿器の使用は、鼻の粘膜の乾燥を最小化し、患者の気道の快適さを増加させる、加湿された空気を生成する。寒冷な気候に加えて、患者インターフェース中および患者インターフェース周囲の顔面領域に通常適用される温暖な空気は、冷たい空気よりさらに快適である。

呼吸用加湿器は、多くの形態で利用可能であり、空気回路を介して呼吸デバイスに結合される独立型デバイスであってもよく、関連呼吸デバイスと一体化されるとか、関連呼吸デバイスに直接結合されるように構成される。既知の受動加湿器は、多少救済をもたらすことがあるが、一般的に、熱加湿器は、患者が快適になるように、十分な湿度および温度を空気に提供するために使用され得る。一般的に、加湿器は、数百ミリリットル（ｍｌ）の容量を有するウォーターリザーバーまたはウォータータブ、リザーバー中の水を加熱する熱要素、加湿のレベルを変化させ得るコントロール、流れ発生器またはＲＰＴデバイスから空気を受け取る空気入口、および、患者インターフェースに加湿された空気を伝える空気回路に接続されるように適合化された空気出口を備える。

加熱パスオーバー型加湿は、ＲＰＴデバイスとともに使用される１つの一般的な形態の加湿である。このような加湿器では、加熱要素は、ウォータータブ下にあり、ウォータータブと温熱的に接触するヒータープレートに組み込まれ得る。したがって、熱は、伝導により主にヒータープレートからウォーターリザーバーに送達される。ＲＰＴデバイスからの空気の流れは、加熱された水をウォータータブにパスオーバーし、結果的に、空気の流れにより含まれる水蒸気となる。ＲｅｓＭｅｄ Ｈ４ｉ^ＴＭおよびＨ５ｉ^ＴＭ加湿器は、ＲｅｓＭｅｄ Ｓ８およびＳ９ ＣＰＡＰデバイスと組み合わせでそれぞれ使用されるこのような加熱パスオーバー型加湿器の例である。

バブルまたはディフューザー加湿器、ジェット加湿器またはウィッキング加湿器のような、他の加湿器も使用され得る。バブルまたはディフューザー加湿器では、空気は水面下に伝導され、表面にバブルが戻ることを可能にする。ジェット加湿器は、水の噴霧を生成し、整流デバイスまたはフィルターは、加湿器から離れる前に粒子が除去または蒸発するように使用され得る。ウィッキング加湿器は、キャピラリー作用により水を吸収するために、スポンジまたは紙のような、水吸収物質を使用する。水吸収物質は、空気の流れに含まれることになる吸収物質中の水の蒸発を可能にする空気の流れ経路の少なくとも一部の中、または、こうした経路の隣に位置する。

加湿の代替的な形態は、大きな表面領域にわたって空気の流れを第１の方向に向かわせ、加熱された水を大きな表面領域に対して第２の反対方向に供給するＣｏｕｎｔｅｒＳｔｒｅａｍ^ＴＭ技術を使用するＲｅｓＭｅｄ ＨｕｍｉＣａｒｅ^ＴＭＤ９００により提供される。ＲｅｓＭｅｄ ＨｕｍｉＣａｒｅ^ＴＭＤ９００加湿器は、侵襲性および非侵襲性のさまざまな人工呼吸器とともに使用され得る。

２ 技術の簡単な説明
本開示の態様は、複数の患者デバイスと関連して遠隔診断を行うコンピュータ実行方法を提供する。前記方法は、複数の患者デバイスから診断データを受信して格納するステップを含み、ここで、前記診断データは、前記複数の患者デバイスのうち、少なくとも一つと関連する障害（ｆａｕｌｔ）の存在を識別する。前記方法は、また、第１の患者デバイスに関する診断データの第１の部分に対する質疑（又はクエリ）を受信するステップ、および前記診断データの第１の部分に基づいて障害の存在を識別するステップを含むことができる。さらに、前記方法は、受信された質疑に応答して診断データの第１の部分または障害の識別された存在を送信するステップを含むことができ、ここで、前記診断データの第１の部分は、第１の患者デバイスと関連した障害の存在を識別する。前記方法は、更に、前記第１の患者デバイスに送信されるサービスデータの識別情報を受信するステップを含むことができ、ここで、前記サービスデータの少なくとも一部は、一つまたは複数の識別された障害を対処する。次いで、前記識別されたサービスデータは、第１の患者デバイスに送信され得る。

医療デバイスの診断モニタリングのための方法は、また一つまたは複数のプロセッサーによって複数の患者デバイスから診断データを受信するステップとして、前記診断データは、前記複数の患者デバイスのうち、少なくとも一つと関連する一つまたは複数の障害を識別するものであるステップ；前記受信された診断データを前記一つまたは複数のプロセッサーによって格納するステップ；一つまたは複数のプロセッサーによって、診断データの第１の部分と関連した障害の存在を識別するステップ；前記一つがまたは複数のプロセッサーによって、前記診断データの前記第１の部分および前記複数の患者デバイスのうち、少なくとも一つと関連した識別された障害のうち、少なくとも一つを遠隔コンピューティングデバイスに送信するステップ；および前記診断データの前記第１の部分および前記一つまたは複数の識別された障害のうち、少なくとも一つに基づいて識別されたサービスデータを前記一つまたは複数のプロセッサーよって前記複数の患者デバイスのうち、少なくとも一つに送信するステップを含む方法を含むことができる。本方法は、診断データの少なくとも第１の部分を一つまたは複数のプロセッサーによって遠隔コンピューティングデバイスに送信することに応答して、複数の患者デバイスのうち、少なくとも一つに送信されるサービスデータの識別を受信するステップを更に含むことができ、ここで、前記サービスデータの少なくとも一部は、前記一つまたは複数の識別された障害に対処する。本開示内容の全体にわたって使用される「障害の存在の表示」という表現は、障害が特定のデバイスで発生する可能性が高いという表示だけでなく、障害は現在すべてのデバイスにも存在するということに注意しなければならない。

一態様によれば、第１の患者デバイスは、呼吸圧力治療デバイスを備える。また、診断データは、トリガイベントの発生に基づいて受信されることができ、患者デバイスの治療設定から構成され得る。また、診断データは、患者デバイスと関連して発生した操作および障害のログを含むことができる。

開示された方法は、また、サービスデータが成功的に送信されたという表示を第１の患者デバイスから受信するステップ、および第１のサービスデータの実行を示すために診断データをアップデートするステップを含むことができる。

一つの態様によれば、障害の存在は、障害が発生した第１の患者デバイスの一つまたは複数の構成要素に基づいて識別され得る。また、質疑は、前記複数の患者デバイスに対する診断データの要求を更に含むことができ、前記診断データの第１の部分の送信することは、前記複数の患者デバイスに対する診断データを送信することを含むことができる。

また他の開示された方法は、患者デバイスの動作に関する診断データを収集する患者デバイスを含むことができ、ここで、前記診断データは、患者デバイスと関連して発生された障害の存在を識別する。患者デバイスは、また、診断データがネットワークを介して送信されるトリガイベントが発生したか否かを判定することができる。トリガイベントが発生した場合、患者デバイスは、ネットワークを介して診断データを送信することができます。患者デバイスは、また、識別されたエラーを処理し、受信されたサービスデータに従って一つまたは複数の動作を行うサービスデータを受信することができる。

一態様によれば、前記トリガイベントは、診断データが送信される前に充足される複数の条件に基づくことができる。トリガイベントは、また、あらかじめ決定された期間の間に患者デバイスを使用することを終えた患者に基づくことができる。トリガイベントは、また、診断データが送信されるスケジュールに基づくことができる。

前記サービスデータは、第１の部分および第２の部分を含むことができ、患者デバイスの第１の構成要素は、サービスデータの第１の部分に従って動作し、第２の構成要素は、サービスデータの第２の部分に従って動作する。一態様によれば、診断データの少なくとも一部は、患者の無呼吸指数、呼吸低下指数および無呼吸−呼吸低下指数のうち、少なくとも一つに関連し得る。

他の態様において、前記サービスデータは、患者デバイスの一つまたは複数の設定を調整するための命令を含むことができ、前記診断データは、障害が発生した時間に患者デバイスの一つまたは複数の設定を識別することができる。識別された障害は、遠隔コンピューティングデバイス上に表示するためのアイコンとして提供されることができ、アイコンは、発生した障害のタイプに基づいて変化する可変的な外観を有することができる。また、識別された障害を送信するステップは、遠隔コンピューティングデバイス上に表示するための使用アイコンを提供するステップを含むことができ、使用アイコンは、患者デバイスが使用された程度を示す。

本開示は、また、本明細書に説明された方法を行うように構成された一つまたは複数のコンピューティングデバイスを含むシステムを提供する。

３ 図面の様々な視点の簡単な説明
本発明の技術は、添付された図面の図で例として示しているが、限定されるものではなく、添付された図面の図で同一の参照符号は、同一の要素を示す。

［３．１ 治療システム］ 本発明の技術によるシステムを示す。患者インターフェース３０００を装着した患者１０００は、鼻枕の形態で、ＲＰＴデバイス４０００から陽圧で空気の供給を受け取る。ＲＰＴデバイスからの空気は、加湿器５０００で加湿され、空気回路４１７０に沿って患者１０００にパスされる。 患者インターフェース３０００を装着した患者１０００を含むシステムを示し、経鼻マスク形態で、ＲＰＴデバイス４０００から陽圧で空気の供給を受け取る。ＲＰＴデバイスからの空気は、加湿器５０００で加湿され、空気回路４１７０に沿って患者１０００にパスされる。 患者インターフェース３０００を装着した患者１０００を含むシステムを示し、フルフェースマスクの形態で、ＲＰＴデバイスから陽圧で空気の供給を受け取る。ＲＰＴデバイスからの空気は、加湿器５０００で加湿され、空気回路４１７０に沿って患者１０００にパスされる。 ［３．２ 治療］＜３．２．１ 呼吸器系＞ 鼻腔および口腔、喉頭、声帯、食道、気管、気管支、肺、肺胞嚢、心臓、および横隔膜を含む人呼吸器系の概要を示す。 鼻腔、鼻骨、側鼻軟骨、大鼻翼軟骨、鼻孔、上唇、下唇、喉頭、硬口蓋、軟口蓋、中咽頭、舌、喉頭蓋、声帯、食道、および気管を含む人の上気道の概要を示す。 ＜３．２．２ 顔解剖学＞ 上唇、上赤唇、下赤唇、下唇、口幅、 目頭部分（Endocanthion）、鼻翼、鼻唇溝、および口角点（Cheilion）を含む、識別された表面解剖学のいくつかの特徴を有する顔の正面図である。 ［３．３ 患者インターフェース］ 先行技術に公知された患者インターフェースの一例を示す。 ［３．４ 呼吸圧力治療（ＲＰＴ）デバイス］ 本発明の技術の一つの形態によるＲＰＴデバイスを示す。 本発明の技術の一つの形態によるＲＰＴデバイスの空気圧回への概路図を示す。上流および下流方向を示す。 本発明の技術の一つの形態によるＲＰＴデバイスの電気構成要素の概路図を示す。 ［３．５ 加湿器］ 本発明の技術の一つの形態による加湿器を示す。 ［３．６ 呼吸波形］ 睡眠中の人体の通常的な呼吸波形モデルを示し、横軸は時間であり、縦軸は呼吸の流量である。パラメータ値は変化できる一方、通常の呼吸は以下の近似値を有することができる：一回換気量（Ｖｔ）０．５Ｌ、吸息時間（Ｔｉ）１．６ｓ、ピーク吸入気流（Ｑｐｅａｋ）０．４Ｌ／ｓ、呼息時間（Ｔｅ）２．４ｓ、ピーク呼気流（Ｑｐｅａｋ）?０．５Ｌ／ｓ。呼吸の総持続時間（Ｔｔｏｔ）は約４ｓである。人は通常、１分間に約１５回（ＢＰＭ）の速度で呼吸し、換気量（Ｖｅｎｔ）は約７．５Ｌ／ｓである。通常のデューティーサイクルである、Ｔｉ対Ｔｔｏｔ比は約４０％である。 ［３．７ 診断システム］ 患者デバイスをモニタリングおよびサービスするのに使用され得る例示的な通信システム７００を示す。各患者デバイス７２０は、ＲＰＴ４０００、加湿器５０００および患者インターフェース３０００を含むことができる。 本開示の態様に従って表示され得るウェブページを示す。 開示された方法に関連して本明細書に開示された患者デバイスによって実行され得る動作のフローチャート１３００を示す。 本明細書に開示されたサーバーなどのコンピューティングデバイスによって実行され得る動作に対するフローチャート１４００を示す。

４．本発明の技術の実施例の詳細な説明
本発明の技術をさらに詳細に説明する前に、本発明の技術が本明細書で説明されている特定の例に限定されず、変更可能であることを理解すべきである。さらに、本開示において使用される用語は、本明細書で説明されている特定の例のみを説明することを目的としており、制限的なことを意図しないことを理解すべきである。

４．１ 治療システム
一形態において、本発明の技術は、呼吸器疾患を治療するためのデバイスを含む。前記デバイスは、患者インターフェース３０００に至る空気送出チューブを経て患者１０００に加圧空気を供給するための流れ発生デバイスまたは送風機を含むことができる。

４．２ 治療法
一形態において、本発明の技術は、患者１０００の気道の入口に陽圧を印加するステップを含む呼吸器疾患を治療するための方法を含む。

４．２．１ ＯＳＡに対する経鼻ＣＰＡＰ
一形態において、本発明の技術は、患者に経鼻持続気道陽圧を適用することにより、患者の閉塞性睡眠時無呼吸（ＯＳＡ）を治療する方法を含む。

４．３ 患者インターフェース３０００
本発明の技術の一態様に従う非侵襲性患者インターフェース３０００は、以下の機能的側面として、シール形成構造３１００、プレナムチャンバ３２００、位置決めおよび安定化構造３３００、換気口３４００、および空気回路４１７０に接続するための接続ポート３６００を備える。いくつかの形態では、機能的側面は、一つまたは複数の物理的構成要素により提供され得る。いくつかの形態では、一つの物理的構成要素は、一つまたは複数の機能的側面を提供することができる。使用時に、シール形成構造３１００は、陽圧で気道へ空気の供給を促進するために、患者の気道の入口を取り囲むように構成される。

４．３．１ シール形成構造３１００
本発明の技術の一形態において、シール形成構造３１００は、シール形成面を提供し、さらにクッション機能を提供することができる。

本発明の技術によるシール形成構造３１００は、シリコーンのような柔らかくて、柔軟性且つ弾力性のある材料から構成することができる。

一形態において、シール形成構造３１００は、シール用フランジと支持フランジを含む。好ましくは、シール用フランジは、プレナムチャンバ３２００の周辺部３２１０の周りに延びる約１ｍｍ未満、例えば、約０．２５ｍｍ〜約０．４５ｍｍの厚さを有する比較的薄い部材を含む。支持フランジは、シール用フランジより相対的により厚いことができる。支持フランジは、シール用フランジとプレナムチャンバ３２００の周縁エッジの間に配置され、周辺部３２１０の少なくとも一部の周りに延びている。支持フランジは、バネ状の要素であるか、またはそれを含み、使用中にシール用フランジを支持して座屈を起こすのを防止する。使用中に、シール用フランジは、プレナムチャンバ３２００におけるシステム圧力に容易に対応することができ、その底面に作用して顔にしっかりと係合するよう促す。

一形態において、非浸湿性患者インターフェース３０００のシール形成部は、一対の鼻噴霧または鼻枕を含み、それぞれの鼻噴霧または鼻枕は、患者の鼻のそれぞれの鼻孔とシールを形成するように構築されて配置される。

本発明の技術の態様による鼻枕は次を含む：戴頭円錐、少なくともその一部が患者の鼻の下側の底面にシールを形成する、脚、戴頭円錐の底面の柔軟な部分と戴頭円錐を脚に接続する。さらに、本発明の技術の鼻枕が接続される構造は、脚の基部に隣接した柔軟な領域を含む。柔軟な領域は一致して作用して自在継手構造の役目をし、戴頭円錐と鼻枕が接続されている構造の変位と角度の両方の相対運動に対応する。例えば、戴頭円錐は、脚が接続される構造に向けて軸方向に変位させることができる。

１つの形態において、非侵襲性シール形成部３０００は、使用中に患者の顔の上唇（これがｌｉｐ ｓｕｐｅｒｉｏｒである）上にシールを形成するシール形成部を含む。

１つの形態において、非侵襲性患者インタフェース３０００は、使用中に患者の顔の顎の部分にシールを形成するシール形成部を含む。

４．３．２ プレナムチャンバ３２００
好ましくは、プレナムチャンバ３２００は、使用中にシールが形成される領域における平均的な人の顔の表面輪郭に補完になるように形成された周辺部３２１０を有している。使用中には、プレナムチャンバ３２００の周縁エッジは、顔の隣接する表面に近接するよう位置決めされる。顔との実際の接触は、シール形成構造３１００によって行われる。好ましくは、シール形成構造３１００は、使用中にプレナムチャンバ３２００の全体周辺部３２１０に延びる。

一形態において、プレナムチャンバ３２００は、プレナムチャンバ３２００が鼻腔マスク（例えば、図１ｂに示される）の一部である患者の鼻孔を取り囲み、および／またはこれらと流体連通され得る。また他の形態において、プレナムチャンバ３２００は、プレナムチャンバ３２００がフルフェースマスク（ｆｕｌｌ ｆａｃｅ ｍａｓｋ）（例えば、図１ｃに示される）の一部である患者の鼻孔および口を取り囲み、および／またはこれらと流体連通され得る。また他の形態において、プレナムチャンバ３２００は、プレナムチャンバ３２００が鼻枕（例えば、図２９に示される）の一部である患者の胸壁のうち、一つまたは複数と係合および／または流体連通することができる。

４．３．３ 位置決めおよび安定化構造３３００
好ましくは、本発明の技術の患者インターフェース３０００のシール形成構造３１００は、位置決めと安定化構造３３００によって使用中はシーリング位置に保持される。

４．４ ＲＰＴデバイス４０００
本発明の技術の態様を実施するのに適合できる例示的なＲＰＴデバイス４０００は、機械的および空気的構成要素４１００、電気構成要素４２００を含むことができ、本明細書の全般にわたって記載された一つまたは複数の制御方法論またはアルゴリズムを行うようにプログラム化され得る。ＲＰＴデバイスは、外部ハウジング４０１０を有し、好ましくは、外部ハウジング４０１０の上部４０１２および外部ハウジング４０１０の下部４０１４の２つの部分に形成される。代替的な形態では、外部ハウジング４０１０は、一つまたは複数のパネル４０１５を含むことができる。好ましくは、ＲＰＴデバイス４０００は、前記ＲＰＴデバイス４０００の一つまたは複数の内部構成要素を支持するシャーシ４０１６を含む。一形態では、空気圧ブロック４０２０は、シャーシ４０１６によって支持されるか、またはシャーシ４０１６の一部として形成される。ＲＰＴデバイス４０００は、ハンドル４０１８を含むことができる。

ＲＰＴデバイス４０００の空気圧経路は、空気入口フィルター４１１２、入口マフラー４１２２、陽圧で空気を供給することができる制御可能な圧力デバイス４１４０（好ましくは、送風機４１４２）および出口マフラー４１２４を含むのが好ましい。一つまたは複数のセンサ４２７２および流量センサ４２７４は、空気圧経路に含まれる。

好ましい空気圧ブロック４０２０は、外部ハウジング４０１０内に配置される空気圧経路の一部を含む。

ＲＰＴデバイス４０００は、好ましくは、電力供給装置４２１０、一つまたは複数の入力デバイス４２２０、中央コントローラ４２３０、治療デバイスコントローラ４２４０および／または前述のコントローラのいずれか一つ、圧力デバイス４１４０、一つまたは複数の保護回路４２５０、メモリ４２６０、トランスデューサ４２７０、データ通信インターフェース４２８０および一つまたは複数の出力デバイス４２９０を備える。電気構成要素４２００は、単一のプリント回路板アセンブリ（ＰＣＢＡ）４２０２上に設置され得る。代替的な形態では、ＲＰＴデバイス４０００は、一つまたは複数のＰＣＢＡ４２０２を含むことができる。

一つまたは複数のプロセッサを含むことができるＲＰＴ装置４０００の中央コントローラ４２３０は、好ましくは、前処理モジュール、治療エンジンモジュール、圧力制御モジュールおよびさらに好ましくは、障害状態モジュールを含む一つまたは複数のアルゴリズムモジュールを実行するようにプログラム化され得る。これは、本明細書の全般にわたって記述される一つまたは複数の換気制御方法で構成され得る換気制御モジュールを更に含むことができる。

４．４．１ ＲＰＴデバイスの機械的および空気圧構成要素４１００
４．４．１．１ 空気フィルター（複数）４１１０
本発明の技術の一形態によるＲＰＴデバイスは、空気フィルター４１１０、または一つまたは複数の空気フィルター４１１０を含むことができる。

一形態において、空気入口フィルター４１１２は、送風機４１４２の空気圧経路上流の先頭に位置している。図４ｂを参照する。

一形態において、例えば、抗菌フィルターのような出口空気フィルター４１１４は、空気ブロックの出口４０２０と患者インターフェース３０００との間に配置している。図４ｂを参照する。

４．４．１．２ マフラー４１２０
本発明の技術の一形態において、入口マフラー４１２２は、送風機４１４２の空気圧経路の上流に配置される。図４ｂを参照する。

本発明の技術の一形態において、出口マフラー４１２４は、 送風機４１４２と患者インターフェース３０００との間の空気圧経路内に配置される。図４ｂを参照する。

４．４．１．３ 圧力デバイス４１４０
本発明の技術の好ましい一形態において、陽圧の空気の流れを発生するための圧力デバイス４１４０は、制御可能な送風機４１４２である。例えば、送風機は、一つまたは複数のインペラーが渦巻室内に収納されたブラシレスＤＣモータ４１４４を含むことができる。送風機は、好ましくは、空気の供給を、例えば、約１２０ リットル／分の速度で、約４ｃｍＨ_２Ｏから約２０ｃｍＨ_２Ｏ、または他の形態においては約３０ｃｍＨ_２Ｏまでの範囲の陽圧により送達することができる。

圧力デバイス４１４０は、治療デバイスコントローラ４２４０の制御下にある。

４．４．１．４ トランスデューサ４２７０
本発明の技術の一形態において、一つまたは複数のトランスデューサ４２７０は、圧力デバイス４１４０の上流に配置される。一つまたは複数のトランスデューサ４２７０は、空気圧経路内のその地点の空気の特性を測定するように製作され、配置される。

本発明の技術の一形態において、一つまたは複数のトランスデューサ４２７０は、圧力デバイス４１４０の下流および空気回路４１７０の上流に配置される。一つまたは複数のトランスデューサ４２７０は、空気圧経路内のその地点の空気の特性を測定するように製作され、配置される。

本発明の技術の一形態において、一つまたは複数のトランスデューサ４２７０は、患者インターフェース３０００の近くに配置される。

４．４．１．５ アンチスピルバック弁４１６０
本発明の技術の一形態において、アンチスピルバック弁は、加湿器５０００と空気圧ブロック４０２０との間に配置される。アンチスピルバック弁は、水が加湿器５０００から上流に、例えば、モータ４１４４に流れる危険性を低減するように製作され、配置される。

４．４．１．６ 空気回路４１７０
本発明の技術の一形態による空気回路４１７０は、空気圧ブロック４０２０と患者インターフェース３０００との間に空気の流れを可能にするように製作され、配置構成される。

４．４．１．７ 酸素送達
本発明の技術の一形態において、補給酸素４１８０は、空気圧経路内のある地点に送達される。

本発明の技術の一形態において、補給酸素４１８０は、空気圧ブロック４０２０の上流に送達される。

本発明の技術の一形態において、補給酸素４１８０は、空気回路４１７０に送達される。

本発明の技術の一形態において、補給酸素４１８０は、患者インターフェース３０００に供給される。

４．４．２ ＲＰＴデバイス電気構成要素４２００
４．４．２．１ 電力供給装置４２１０
本発明の技術の一形態において、電力供給装置４２１０は、ＲＰＴデバイス４０００の外部ハウジング４０１０の内部にある。本発明の技術の他の形態において、電力供給装置４２１０は、ＲＰＴデバイス４０００の外部ハウジング４０１０の外部にある。

本発明の技術の一形態において、電力供給装置４２１０は、電力をＲＰＴデバイス４０００のみに供給する。本発明の技術の他の形態において、電力供給装置４２１０は、電力をＲＰＴデバイス４０００と加湿器５０００との両方に供給する。電源供給デバイスは、また、本明細書の全般にわたって記載されたように、換気配列のために、アクチュエータ、コントローラおよび／またはセンサに電力を選択的に供給することができる。

４．４．２．２ 入力デバイス４２２０
本発明の技術の一形態において、ＲＰＴデバイス４０００は、作業者が前記デバイスと交流できるように、ボタン、スイッチまたはダイヤルの形態の一つまたは複数の入力デバイス４２２０を含む。これらは、換気配列のようなＲＰＴデバイスの構成要素の動作設定を入力するために実施され得る。ボタン、スイッチまたはダイヤルは、物理的デバイスであるかまたはタッチスクリーンを介してアクセス可能なソフトウェアデバイスであることができる。これらのボタン、スイッチまたはダイヤルは、一形態では、外部ハウジング４０１０に物理的に接続されるかまたは他の形態では、中央コントローラ４２３０に電気的に接続される受信機と無線方式で通信することができる。

一形態において、入力デバイス４２２０は、作業者が値および／またはメニューオプションを選択できるように製作され、配置され得る。

４．４．２．３ 中央コントローラ４２３０
本発明の技術の一形態において、中央コントローラ４２３０は、入力デバイス４２２０から入力信号（など）を受信し、出力信号（など）を出力デバイス４２９０および／または治療デバイスコントローラ４２４０に提供するように構成された専用電子回路である。

一形態において、中央コントローラ４２３０は、アプリケーション特定集積回路である。また他の形態において、中央コントローラ４２３０は、別の電子構成要素を含む。

本発明の技術のまた他の形態において、中央コントローラ４２３０は、 ｘ８６のＩＮＴＥＬプロセッサーなどのＲＰＴデバイス４０００を制御するのに適したプロセッサーである。

本発明の技術の他の形態によるＲＰＴデバイス４０００を制御するのに適したプロセッサー４２３０は、ＡＲＭ ＨｏｌｄｉｎｇｓのＡＲＭ Ｃｏｒｔｅｘ−Ｍプロセッサーに基づいたプロセッサーを含む。例えば、ＳＴ ＭＩＣＲＯＥＬＥＣＴＲＯＮＩＣＳのＳＴＭ３２シリーズマイクロコントローラが使用され得る。

本発明の技術の他の代替的形態によるＲＰＴデバイス４０００を制御するのに適した他のプロセッサーは、ファミリＡＲＭ９−ベース３２ビットＲＩＳＣ ＣＰＵから選択されたメンバーを含む。例えば、ＳＴ ＭＩＣＲＯＥＬＥＣＴＲＯＮＩＣＳのＳＴＲ９シリーズマイクロコントローラが使用され得る。

本発明の技術の特定代替形態において、１６ビットＲＩＳＣ ＣＰＵは、 ＲＰＴデバイス４０００に対するプロセッサーとして使用され得る。例えば、ＴＥＸＡＳ ＩＮＳＴＲＵＭＥＮＴＳで製造したマイクロコントローラのＭＳＰ４３０ ファミリからのプロセッサーが使用され得る。

プロセッサーは、一つまたは複数のトランスデューサ４２７０、および一つまたは複数の入力デバイス４２２０から入力信号を受信するように構成される。

プロセッサーは、出力信号を出力デバイス４２９０、治療デバイスコントローラ４２４０、データ通信インターフェース４２８０、および加湿器コントローラ５２５０のうちの一つまたは複数に提供するように構成される。

本発明の技術のいくつかの形態において、中央コントローラ４２３０のプロセッサー、または複数のそのようなプロセッサーは、メモリ４２６０などの非一時的な（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）コンピュータ可読記憶媒体に格納されるコンピュータプログラムとして表現される一つまたは複数のアルゴリズム４３００などの、本明細書で説明されている一つまたは複数の方法を具現するように構成される。一部の場合には、既に説明されているように、そのようなプロセッサーは、ＲＰＴデバイス４０００に統合することができる。しかし、本発明の技術のいくつかの形態におおいて、プロセッサーは、呼吸器処置の実施を直接的に制御することなく本明細書で説明されている方法のいずれかを行うことなどを目的として、ＲＰＴデバイス４０００の空気圧構成要素から個別的に実行され得る。例えば、そのようなプロセッサーは、本明細書で説明されているセンサのいずれかなどから格納されているデータの解釈によって換気デバイスに対する制御設定またはその他の呼吸器関連イベントを決定することを目的として本明細書で説明されている方法のうちのいずれかを行うことができる。同様に、このようなプロセッサは、本明細書に記載されている換気デバイスの動作を制御するために、本明細書に記載されている任意の方法のうちのいずれかを実行することができる。

４．４．２．４ クロック４２３２
好ましくは、ＲＰＴデバイス４０００は、プロセッサーに接続されているクロック４２３２を含む。

４．４．２．５ 治療デバイスコントローラ４２４０
本発明の技術の一形態において、治療デバイスコントローラ４２４０は、中央コンドロ−ルロ４２３０のプロセッサーによって実行されるアルゴリズム４３００の一部を形成する圧力制御モジュール４３３０である。

本発明の技術の一形態において、治療デバイスコントローラ４２４０は、専用モータ制御集積回路である。例えば、ＯＮＳＥＭＩで製造したＭＣ３３０３５ブラシレスＤＣモータコントローラが使用される。

４．４．２．６ 保護回路４２５０
好ましくは、本発明の技術によるＲＰＴデバイス４０００は、一つまたは複数の保護回路４２５０を含む。

保護回路４２５０の一形態は、電気保護回路である。

本発明の技術による保護回路４２５０の一形態は、温度、または圧力安全回路である。

４．４．２．７ メモリ４２６０
本発明の技術の一形態によれば、ＲＰＴデバイス４０００は、メモリ４２６０、好ましくは不揮発性メモリを含む。いくつかの形態において、メモリ４２６０は、電池式スタティックＲＡＭを含むことができる。いくつかの形態において、メモリ４２６０は、揮発性ＲＡＭを含むことができる。

好ましくは、メモリ４２６０は、ＰＣＢＡ４２０２上に配置される。メモリ４２６０は、ＥＥＰＲＯＭまたはＮＡＮＤフラッシュの形態であり得る。

追加的に、または代替的に、ＲＰＴデバイス４０００は、移動可能な形態のメモリ４２６０、例えば、セキュアデジタルＳＤ規格に従って製作されたメモリカードを含む。

本発明の技術の一形態において、メモリ４２６０は、非一時的なコンピュータ可読記憶媒体として作動し、この媒体に、一つまたは複数のアルゴリズム４３００などの、本明細書で説明されている一つまたは複数の方法を表現するコンピュータプログラム命令が格納される。

４．４．２．８ トランスデューサ４２７０
トランスデューサは、デバイスの内部にあるか、ＲＰＴデバイスの外部にあり得る。外部トランスデューサは、例えば、患者インターフェース上で、例えば、空気送達回路上に配置されるか、またはその一部を形成することができる。外部トランスデューサは、データをＲＰＴデバイスに送信または転送するドップラーレーダー移動センサなどの非接触センサの形態のものであり得る。

４．４．２．８．１ 流量
本発明の技術による流量トランスデューサ４２７４は、差圧トランスデューサ、例えば、ＳＥＮＳＩＲＩＯＮ社のＳＤＰ６００シリーズ差圧トレンスデユーサに基づくものであり得る。差圧トランスデューサは、空気圧回路と流体連通し、圧力トランスデューサのそれぞれの一つは流れ制限要素内の各第１および第２の地点に接続される。

使用中に、流量トランスデューサ４２７４からの全流量Ｑｔを表す信号が、プロセッサーによって受信される。

４．４．２．８．２ 圧力
本発明の技術による圧力トランスデューサ４２７２は、空気圧回路と流体連通するように配置される。好適な圧力トランスデューサの一例は、ＨＯＮＥＹＷＥＬＬ ＡＳＤＸシリーズセンサである。代替的に好適な圧力トランスデューサは、ＧＥＮＥＲＡＬ ＥＬＥＣＴＲＩＣ社のＮＰＡシリーズセンサである。

使用中に、圧力トランスデューサ４２７２は、中央コントローラプロセッサーによって受信される。一形態において、圧力トランスデューサ４２７２からの信号は、中央コントローラ４２３０によって受信される前にフィルター処理される。

４．４．２．８．３ モータ速度
本発明の技術の一形態において、モータ速度信号４２７６が生成される。モータ速度信号４２７６は、好ましくは、治療デバイスコントローラ４２４０によって送られる。モータ速度は、例えば、ホール効果センサなどの、速度センサによって発生され得る。

４．４．２．９ データ通信システム４２８０
本発明の技術の好ましい一形態において、データ通信インターフェース４２８０が備えられ、中央コントローラプロセッサーに接続される。データ通信インターフェース４２８０は、好ましくは、遠隔外部通信ネットワーク４２８２に接続可能である。データ通信インターフェース４２８０は、好ましくは、ローカル外部通信ネットワーク４２８４に接続可能である。好ましくは、遠隔通信ネットワーク４２８２は、遠隔外部デバイス４２８６に接続可能である。好ましくは、ローカル外部通信ネットワーク４２８４は、ローカル外部デバイス４２８８に接続可能である。

一形態において、データ通信インターフェース４２８０は、中央コントローラ４２３０の一部である。他の形態において、データ通信インターフェース４２８０は、中央コントローラプロセッサーから分離している集積回路である。

一形態において、遠隔外部通信ネットワーク４２８２は、インターネットである。データ通信インターフェース４２８０は、有線通信（例えば、Ｅｔｈｅｒｎｅｔ、または光ファイバーを介する）または無線プロトコルを使用してインターネットに接続することができる。

一形態において、ローカル外部通信ネットワーク４２８４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの一つまたは複数の通信規格、または消費者向けの赤外線プロトコルを利用する。

一形態において、遠隔外部デバイス４２８６は、一つまたは複数のコンピュータ、例えば、ネットワークコンピュータのクラスタである。一形態において、遠隔外部デバイス４２８６は、物理的コンピュータではなく、仮想コンピュータであり得る。いずれの場合にも、そのような遠隔外部デバイス４２８６は、臨床医などの適切な権限を有した作業者によるアクセスが可能であり得る。

好ましくは、ローカル外部デバイス４２８８は、パーソナルコンピュータ、携帯電話、タブレット、または遠隔制御である。

４．４．２．１０ オプションのディスプレイ、警報を含む出力デバイス
本発明の技術による出力デバイス４２９０は、視覚的ユニット、聴覚的ユニット、および触覚的ユニットのうちの一つまたは複数の形態を取ることができる。視覚的ディスプレイは、液晶ディスプレイ（ＬＣＤ）または発光ダイオード（ＬＥＤ）ディスプレイであり得る。

４．４．２．１０．１ ディスプレイドライバ４２９２
ディスプレイドライバ４２９２は、入力として、ディスプレイ４２９４上に表示するために意図される文字、記号、または画像を受け取り、それらをディスプレイ４２９４にそれらの文字、記号、または画像を表示させる命令に変換する。

４．４．２．１０．２ ディスプレイ４２９４
ディスプレイ４２９４は、ディスプレイドライバ４２９２から受信された命令に応答して文字、記号、または画像を視覚的に表示するように構成される。例えば、ディスプレイ４２９４は、８つのセグメントディスプレイであることができ、この場合に、ディスプレイドライバ４２９２は、数字「０」などの各文字、または記号を８つの論理信号に変換し、この論理信号は、８つの各セグメントが特定の文字、または記号を表示するために活性化することができるか否かを示す。

４．５ 通信および診断システム
図７は、本開示の態様など実施され得る例示的なシステム７００を示す。このような例は、本開示の範囲または本明細書に説明された特徴の有用性を制限するものと見なされるべきではない。この例において、システム７００は、サーバー７１０、患者デバイス７２０、格納システム７５０だけでなく、コンピューティングデバイス７６０を含み、この例で臨床医またはデバイスサポートサービス担当者と関連され得る。これらのデバイスは、それぞれネットワーク４２８２を介して通信することができる。システム７００は、任意のサイズのネットワークにスケールすることができる。例えば、３つの患者デバイス７２０のみが示されたが、システム７００は、任意の数の患者デバイスを含むことができる。

各患者デバイス７２０は、ＲＰＴ４０００、加湿器５０００および患者インターフェース３０００を含む一つまたは複数のデバイスを含むことができる。また、それぞれの患者デバイス７２０は、遠隔位置で、および異なる患者によって操作され得る。コントローラプロセッサー４２３０およびメモリ４２６０のみが患者デバイス７２０に示されているが、各患者デバイスは、ＲＰＴ４０００、加湿器５０００および患者インターフェース３０００と関連して前述の構成要素のいずれかを含むことができる。また、患者デバイス７２０が４２８２を介して直接通信するものと示されているが、それぞれの患者デバイスは、外部コンピューティングデバイスを介してネットワーク４２８２上で通信することもできる。例えば、患者デバイス７２０は、ネットワーク４２８２を介してデータを送信するパーソナルコンピュータと通信することができる。

サーバー７１０は、一つまたは複数のプロセッサー７１２、メモリ７１４を含むことができ、汎用コンピューティングデバイスに通常的に存在する他の構成要素と組み込まれることができる。サーバー７１０のメモリ７１４は、プロセッサー７１２によって実行され得る命令７１５を含むプロセッサー７１２によってアクセス可能な情報を格納することができる。メモリ７１４は、また、プロセッサー７１２によって検索、操作または格納され得るデータ７１８を含むことができる。メモリは、プロセッサーによってアクセス可能な情報を格納することができる任意の非一時的タイプであり得る。命令７１５は、プロセッサー７１２によって直接的または間接的に実行される命令などを含むことができる。これと関連して、「命令」、「アプリケーション」、「ステップ」および「プログラム」という用語は、本明細書で相互交換可能に使用され得る。命令の機能、方法およびルーチンは、以下でより詳細に説明する。

診断データ７１８のようなデータは、命令７１５に従ってプロセッサー７１２によって検索、格納または修正され得る。例えば、本明細書に記載された主題が任意の特定のデータ構造によって制限されないが、データは、コンピュータレジストに格納されることができ、すなわち、多くの他のフィールドとレコード、または ＸＭＬ文書を有するテーブルとしてリレーショナルデータベースに格納され得る。診断データ７１８は、また、数字、説明テキスト、専用コード、ポインタ、他のネットワーク位置などの他のメモリに格納されたデータに対する参照のような関連情報を識別するか計算するのに十分な任意の情報であり得る。一つまたは複数のプロセッサー７１２は、ＣＰＵのような従来のプロセッサーなどを含むことができるか、またはＡＳＩＣのようなハードウェアベース構成要素であり得る。

図７は、サーバー７１０、コンピューティングデバイス７６０および患者デバイス７２０のプロセッサー、メモリおよび他の要素をそれぞれ一つのブロック内にあるように機能的に示しているが、各デバイスの様々な構成要素は、異なる物理的ハウジング内に格納され得る。例えば、メモリ７１４は、サーバー７１０のハウジングと異なるハウジングに配置されたハードドライブまたは他の格納媒体であり得る。同様に、格納システム７５０は、サーバー７１０の一部であるかまたはサーバー７１０のうちの一つまたは複数と一体に内蔵され得る。また、プロセッサー７１２は、複数のプロセッサーを含むことができ、その一部または全部は、サーバー７１０のハウジングとは異なるハウジングに配置される。したがって、プロセッサー、コンピュータ、コンピューティングデバイスまたはメモリに対する言及は、並列で作動するか作動しないプロセッサー、コンピュータ、コンピューティングデバイスまたはメモリの集合体に対する言及を含むものとして理解されるだろう。一部の機能などが単一のプロセッサーを有する単一のコンピューティングデバイス上で発生するものとして本明細書で説明されたが、本開示の様々な態様などは、ネットワーク４２８２を介して通信するもののように互いに情報を通信する複数のコンピューティングデバイスによって具現され得る。

多くの場合に、患者デバイス７２０は、無線通信を使用してネットワーク４２８２と通信することが好ましい。しかし、本明細書に記載されたネットワーク４２８２および介在ノードは、ネットワークがインターネット、ワールドワイドウェブ、特定のイントラネット、広域ネットワーク、ローカルネットワーク、または携帯電話ネットワークの一部となることができるように、様々なプロトコルおよびシステムを使用して相互接続され得る。ネットワークは、イーサネット（登録商標）、Ｗｉ−Ｆｉ、ＨＴＴＰおよびブルートゥース（登録商標）のような標準的な通信プロトコル、一つまたは複数の会社が独占的に使用するプロトコルおよび前述の様々な組み合わせを利用することができる。前述のように、情報が送信または受信されるときに所定の利点が得られるが、本明細書に記載された主題の他の態様は、情報の特定送信方式に制限されない。

サーバー７１０は、ネットワーク４２８２を介して格納システム７５０、コンピューティングデバイス７６０および患者デバイス７２０と通信できる一つまたは複数の通信サーバーを含むことができる。以下により詳細に説明するように、サーバー７１０は、ネットワーク４２８２を介して患者デバイス７２０から診断データ７２８を受信することができる。受信された診断データ７２８に応答して、サーバー７１０は、また、サービスデータ７１６を患者デバイス７２０に送信することができる。

コンピューティングデバイス７６０は、サーバー７１０と同様に、前述したような一つまたは複数のプロセッサー７６２、メモリ７６４および命令を備えて構成され得る。それぞれのコンピューティングデバイスは、臨床医またはデバイスサポートサービス担当者によって使用されるように意図されたパーソナルコンピューティングデバイスであることができ、中央処理デバイス（ＣＰＵ）、データおよび命令を格納するメモリ（例えば、ＲＡＭおよび内部ハードドライブ）、ディスプレイ ７６６（例えば、スクリーン、タッチスクリーン、プロジェクタ、テレビ、または情報を表示するように操作できる他のデバイスを有するモニタ）のようなディスプレイ、およびユーザ入力デバイス７６８（例えば、マウス、キーボード、タッチスクリーンまたはマイクロフォン）と関連して通常使用されるすべての構成要素を備える。

本開示の態様にしたがってネットワーク４２８２を介して転送されたデータの一部は、気密の患者情報を含むだろう。したがって、システム７００は、送信されたデータに対する不正アクセスを防止するためのセキュリティ対策を実施することができる。一態様において、システム７００のデバイスなどの間の接続は、ＶＰＮ接続の形態を取ることができる。また、データ送信は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）プロトコルを基盤とすることができる。ネットワーク４２８２を介して送信されたデータは、また、個人キー基盤構造を使用して暗号化され得る。以下のシステム側面では、一つまたは複数のウェブページを介してデータを表示することができるが、これらのウェブページは、保護されたネットワークに関連して示すことができるので、承認されたコンピューティングデバイスおよびユーザだけウェブページにアクセスできる。

４．６ 例示的な方法
前述したように、図７に示した各患者デバイス７２０は、ＲＰＴ４０００、加湿器５０００および患者インターフェース３０００を含む一つまたは複数のデバイスを含むことができる。本明細書に記載された動作を行うことにおいて、患者デバイス７２０は、ソフトウェアまたはファームウェアを含むことができる命令セット７２６を実施することができる。図４ｃに関連して前述のように、ＲＰＴ４０００は、湿度コントローラ５２９０および治療デバイスコントローラ４２４０のような複数のコントローラだけでなく、他のハードウェア構成要素を含むことができる。患者デバイス７２０の作動中に、一つまたは複数の構成要素に関連して障害が発生することができる。本明細書に記載されたシステムおよび方法に示したように、これらの障害は、遠隔で識別され、しばしばサービスされ得る。開示されたシステムは、サービス担当者に患者デバイス７２０に関するリアルタイムの通知および診断データを受信することが可能であるので、患者が自分の患者デバイス７２０に問題を報告する前に潜在的な問題を識別することができる。問題が患者に報告された場合、開示されたシステムは、ウェブページまたは患者デバイスダッシュボード上のエラーアイコンおよび警告メッセージの表示を介して障害の可視的表示をサービス担当者に提供し、手術患者デバイスと関連した詳細データの関連報告書を提供する。このような方式で、サービス担当者は、患者の報告された問題がデバイスと関連があるか否かを迅速に判定することができる。

各患者デバイス７２０は、診断データ７２８を生成して格納することができる。診断データ７２８は、発生したか発生する可能性のある障害に関するデータを含み、患者デバイス７２０の動作に関連する任意のデータを含むことができる。一態様において、命令セット７２６は、患者デバイス７２０の様々な構成要素が正しく作動するか否かを判断するために、患者デバイス７２０の包括的検査を実行するための命令を含むことができる。例えば、包括的な検査は、電源、患者インターフェース３０００に提供された空気圧だけでなく、患者デバイス７２０の一つまたは複数の構成要素の温度を検査することを伴うことができる。

一つの態様によれば、障害は、加湿に関連した障害、加熱された管、電源供給装置、送風機などのような実施される構成要素および作動に基づいて分類され得る。一例において、特定の障害は、患者がデバイスの使用を中断することを要求するか否かに基づいて分類され得る。特に、患者デバイス７２０は、検出された障害が患者にデバイスの使用を中断することを要求するカテゴリーであるか否かを決定することができ、そうであれば、患者への治療を終了する。患者デバイス７２０は、また、患者にエラーメッセージを表示することができる。エラーメッセージは、発生したか発生する可能性のある障害を記述する場合がある。

診断データ７２８は、患者デバイス内の特定の障害の識別に制限されないが、また、デバイスの一般的な動作および使用に関連され得る。特に、患者デバイス７２０は、使用時間、使用中に提供された空気圧、使用中に発生した空気漏れおよび治療中に使用された治療設定を識別することを含み、患者デバイス７２０の患者の使用に対するログを生成することができる。このような治療設定には、自動または手動調整のために設定することができる様々な気候制御が含まれ得る。例えば、ユーザは、患者デバイス７２０の湿度、温度および呼気圧力レベルを設定することができる。患者は、また、患者デバイス７２０を「スマートスタート」および「スマートストップ」設定に設定することができ、患者インターフェース３０００を着用した患者に対する治療を開始し、患者インターフェース３０００を脱いだ患者に対する治療を自動的に中断するだろう。

診断データは、また、治療中の患者の状態に関連することができる。例えば、診断データ７２８は、患者の無呼吸指数、呼吸低下指数および無呼吸−呼吸低下指数、障害データ、患者使用量、漏れデータ、治療および快適設定および注文デバイス活動および障害ログを計算するのに使用され得るデータを含むことができる。患者デバイス７２０に対する周囲条件も診断データとして収集して格納することができる。例えば、患者デバイスのセンサは、患者デバイス周辺の温度および湿度に関連するデータを収集するのに使用され得る。このような追加データを収集して報告された問題をより包括的に診断するのに役に立つことができる。これは、モニタリング対象のデバイスが動作する環境をより完全に把握できるためである。例えば、患者が治療が予期せず開始または中断されたと報告すれば、漏れに対する情報と、圧力治療デバイスの「スマートスタート／ストップ」機能が有効になる事実に関する情報がこの問題を説明することができる。したがって、患者問題を解決することは、デバイスにハードウェア障害があるか否かを決定することよりもはるかに重要である。報告された問題は、全く問題にならないことがあり、患者の側では認知された問題であり得る。

一例において、診断データ７２８を収集して患者デバイス７２０によって実行されたイベントまたは動作のログとして提示することができる。ログは、障害が発生したときに、インスタンスを識別することができ、障害が発生したか発生する可能性がある。圧力処理デバイスの様々な構成要素における可能性のある障害の表示として動作パラメータをどのように使用できるかに対する詳細事項は、公開されたＰＣＴ出願ＷＯ２００００２７４５７に記載されている。ログは、イベントおよび動作のリストだけでなく、各イベントが発生した日付および時間を含むことができる。

一態様によれば、患者デバイス７２０は、収集された診断データ７２８をサーバー７１０およびコンピューティングデバイス７６０などの一つまたは複数の外部デバイスに送信することができる。診断データ７２８の送信は、一日または一週間に一回または所定のトリガリングイベントの発生に基づくことができる。このようなトリガリングイベントのうち、一つは、障害の発生の可能性があるので、障害が検出され次第に診断データ７２８が送信される。障害に直接関連するデータに加えて、患者デバイスは、治療処置情報およびデバイス設定を含む他の診断データ７２８を送信することもできる。

トリガリングイベントは、また、患者が患者デバイス７２０の使用を中断した以後の所定の時間に基づくことができる。例えば、命令セット７２６は、患者が患者デバイス７２０の使用を中断した後、１時間内に診断データ７２８を送信すべきであることを示すことができる。この例において、患者が患者デバイス７２０の使用を中断したが、１時間内に患者がそれを再び使用すると、診断データ７２８は送信されないだろう。代わりに、患者デバイス７２０は、患者の患者デバイス７２０の使用が診断データ７２８を送信する前に１時間の指定された時間の間に停止するまで待機するだろう。診断データ７２８を送信する前に所定の時間を待機することにより、命令セット７２６は、患者が患者インターフェース３０００を調整するか簡単に取り除くなど、治療への短い中断に起因する使用データの不要な送信を防止することができる。診断データ７２８の送信をトリガするのに使用される所定の期間は、特定の命令セット７２６が特定の患者デバイスによって実施されるように構成することができる。

また他の例において、命令セット７２６は、患者が患者デバイス７２０で治療を受けた時間量に基づいてトリガリングイベントを指定することができる。この時間は、また、ネットワーク４２８２を介して送信されるデータの量を制限することと、診断データの適時性を達成することとの間にバランスをとるように命令セット７２６内に構成することができる。命令セット７２６は、また、所定の時間の間に治療が行われなかった場合に、患者デバイス７２０に診断データ７２８を送信させる。例えば、患者デバイス７２０は、患者デバイス７２０が２４時間のような所定の時間に使用されなかったことを示す診断データ７２８をサーバー７１０に送信することができる。

患者デバイス７２０から診断データ７２８を受信すると、サーバー７１０は、診断データ７１８として受信されたデータを格納することができる。サーバー７１０における格納された診断データは、コンピューティングデバイス７６０によってアクセスされ、したがって、サービス担当者などのコンピューティングデバイスのユーザが各患者デバイスの状態をモニタリングすることができる。したがって、診断データ７１８は、特定の患者デバイス７２０および特定の患者と診断データ７１８を連関させる方式でサーバー７１０に格納され得る。このような方式で、サービス担当者は、特定の患者デバイス７２０に対する問題点を容易に検出することができる。

患者デバイス７２０に格納された診断／故障データ７２８は、即時のレビューを可能にするために必要な時に提供され得る。例えば、患者デバイス７２０のユーザが患者デバイス７２０の作動に問題があるので、患者デバイス７２０のユーザがサービス担当者に電話をかけると、診断データ７２８の即時検討が必要となることがある。この場合、サービス担当者は、コンピューティングデバイス７６０を使用して、ユーザによって検出されるか報告された障害に関する任意の診断データ７２８を含み、特定の期間にわたって収集されたすべての診断データ７２８のような、患者デバイス７２０から特定の診断データの即時送信を要求する。

一態様において、サーバー７１０は、通信サーバーおよびウェブサーバーを含む異なるタイプのサーバーを含むことができる。この例において、コンピューティングデバイス７６０は、ウェブサーバーに診断データ７２８を要求することができ、ウェブサーバーは、その要求を通信サーバーに送信する。次いで、通信サーバーは、患者デバイス７２０から診断データ７２８を要求して受信することができる。要求に応答して、患者デバイス７２０は、動作および障害のログとして診断データ７２８を送信することができる。その後、受信されたログは、ウェブサーバーから通信サーバーに送信されることができ、通信サーバーは、コンピューティングデバイス７６０によってアクセスされ得る。

前述のように、サービス担当者または臨床医のようなコンピューティングデバイス７６０のユーザは、サーバー７１０に格納された診断データ７１８にアクセスすることができる。アクセスされた診断データ７１８は、ウェブサイトまたは他のネットワークを介してコンピューティングデバイス７６０に提示され得る。一態様において、コンピューティングデバイス７６０のユーザは、患者情報に基づいて特定の診断データ７１８を検索することができる。

図８は、患者の名前に基づく診断データの検索に関連して表示され得るウェブページのスクリーンショット８００を示す。スクリーンショット８００は、一つまたは複数の患者に対する検索質疑を入力するのに使用されうる検索フィールド８０２を含む。検索フィールドは、患者の名前、生年月日、識別番号などを含む患者の特定の属性を検索するように設定され得る。図８に示したように、「Ｄｏｅ」という名前を有する患者に対する検索が行われた。その結果、提案されたシステムで臨床医は、患者のリストを見ることができるだけでなく、ハードウェア障害などの障害を有したデバイスがあるか否かも一目で分かる。また、このシステムは、患者をフィルターリングし、臨床医が要求することに応じて、障害があるか障害のない患者のみ表示することができる。このような方法では、臨床医は電話を待つのではなく、問題のあるデバイスを有した患者を積極的に管理することができる。

検索の結果は、コラム見出し８０４〜８１２の下に示されている。検索質疑を満足する各患者の名前は、コラム見出し８０６の下に示す。また、患者が使用している任意のデバイスは、コラム見出し８１２の下に識別された患者の同じ行内で識別され得る。スクリーンショット８００における患者デバイスの識別は、患者によって使用される各デバイスに対するモデル番号を提供するが、コラム見出し８１２は、デバイスの製造社およびデバイスのシリアル番号の識別を含み、デバイスに対する追加情報を含むことができる。コラム見出し８０８の下で、障害を経験したか、または障害が発生する可能性のある任意の患者デバイスに対してアイコン８１４を表示することができる。例えば、Ｊｏｈｎ ＤｏｅのモデルＳ１０ Ｎｅｗｐｏｒｔデバイスに障害が発生したことを示すアイコン「Ｊｏｈｎ Ｄｏｅ」の隣にアイコン８１４が表示される。前述のように、この障害の決定は、Ｊｏｈｎ Ｄｏｅの患者デバイス７２０から送信された診断データに基づいてサーバー７１０によって行われることができる。アイコン８１４は、任意の数のフォームを取ることができ、発生した障害のタイプに基づいて変更することができる。例えば、アイコン８１４は、患者デバイスのどの構成要素が障害を経験したか、障害によって患者デバイスが動作を停止したか、および患者が障害を報告したか否かに応じて可変的な外観を有することができる。このようにして、サービス担当者は、問題の性質を迅速に把握し、どのような追加措置を考慮すべきかを決定することができる。サービス担当者は、また、アイコン８１４と共に提供される任意の報告書だけでなく、アイコン８１４の外観を使用して患者によって報告された問題がデバイスに関連しているか否かを決定することができる。例えば、非デバイス関連の問題には、環境問題または患者関連の問題によって発生する問題が含まれ得る。

障害の識別に加えて、スクリーンショット８００に示されたウェブページは、また、各患者のデバイスに関連した他の診断データを表示することができる。例えば、コラム見出し８０４の下のアイコンは、患者のデバイスが現在ネットワークに接続されているか否かを示す。特に、アイコン８１６は、Ｊｏｈｎ Ｄｏｅのデバイスが現在ネットワークに接続されていることを示すが、アイコン８１８は、 Ｒｏｂｅｒｔ Ｄｏｅのデバイスが現在ネットワークに接続されていないことを示す。コラム見出し８１０の下に列挙された日付は、患者が患者デバイスを最後に使用した日付を示す。一態様によれば、コンピューティングデバイス７６０のユーザーは、図８に示したウェブページディスプレイをカスタマイズして、各患者デバイスに対する追加情報を表示することができる。

図９のスクリーンショット９００から分かるように、ウェブページは、ポップアップウィンドウを介して特定の患者デバイスに対する追加的な診断データを提供することができる。例えば、ユーザがアイコン８１４上にカーソル９０４を動かすときに、ポップアップウィンドウ９０２が現れる。ポップアップウィンドウは、患者に関する追加情報だけでなく、障害が検出された特定の患者デバイスを識別することができる。例えば、ポップアップウィンドウ９０２は、患者ＩＤ、９８７−６５４−３２１によって患者Ｊｏｈｎ Ｄｏｅを識別し、シリアル番号１２３４５６７８９によって患者デバイスを識別する。ポップ−ウィンドウ９０２は、また、患者デバイスに対して検出された障害に関する情報を表示することができる。特に、 警告アイコン９０６は、デバイス１２３４５６７８９の送風機に関連して障害が発生したことを示す一方、チェックアイコン９０８は、デバイスの電源供給に関連して障害が検出されなかったことを示す。一態様によれば、ユーザは、障害を示す特定のデータ、障害が最初に検出された日付および時間、および患者デバイスの現在の設定を含む検出された障害に関する追加の詳細事項を受信するために、警告アイコン９０６を選択することができる。障害は、機能領域の任意の構成要素、サブシステムおよび送風機（フロージェネレータ）のような議論された例に関連することができ、電源供給デバイスは、システム機能を説明するための例に過ぎないという点に留意されたい。

図１０は、診断データがユーザに表示され得る他の方法を示す。スクリーンショット１０００から分かるように、ウェブページは、患者リストではなく、デバイスリストに関連して診断データを表示することができる。特に、患者のデバイス情報は、患者の特定の識別なしに提示されて、サービス担当者に対する患者のプライバシーを維持することができる。例えば、患者デバイスの診断データは、シリアル番号のようなデバイス識別子に基づいてアクセスすることができる。コラム１００２の下に、特定の患者デバイスをそのシリアル番号で列挙することができ、すべての障害表示は、コラム１００４に提供される。追加の診断データが他のコラムに表示され得る。例えば、コラム見出し１００６の下に表示されたグラフィックは、過去１０日間の各患者デバイスの使用を示す。特に、各使用アイコン１０１０〜１０１８は、患者デバイス９８７６５４３２１が特定の日の過程の間に使用された程度を示す。空の使用アイコン１０１０は、患者デバイス９８７６５４３２１が５月１日に使用されなかったことを示す。対照的に、使用アイコン１０１２は、患者が５月６日に６時間のような少なくとも所定の時間量の間に患者デバイスを使用したことを示す。部分的に陰影された使用アイコン１０１４は、患者デバイスが ５月２日に使用されたが、デバイスは、所定量の時間の間に使用されなかったことを示す。使用アイコン１０１０〜１０１８は、また、患者デバイスが使用された方法を示すことができる。例えば、使用アイコン１０１６に表示された「Ｌ」は、５月４日に患者の治療中に空気漏れが感知されたことを示すことができる。また、アイコン１０１８に表示された「Ｍ」は、デバイスが現在モニタリングされているか、または診断データがその日にまだ受信されなかったことを示すことができる。図９のアイコン８１４に関連して前述したように、ユーザは、カーソルを移動させるかアイコン１０２０を選択することによって、アイコン１０２０によって表示された障害に関連する追加の情報を得ることができる。一態様において、ユーザは、特定の日に関連して患者デバイス９８７６５４３２１に対する診断データだけでなく、障害が発生した時点に、一つまたは複数の患者デバイス構成要素の設定に関連した診断データのログを受信するために、使用アイコン１０１０〜１０１８のうち、一つを選択することができる。例えば、診断データは、自動気候制御設定が障害時間に患者デバイスの障害または湿度レベル設定時に、活性化されたが否かを識別することができる。ログには、指定された時間の間に発生したすべての操作および障害を含むことができる。

一態様によれば、患者の在宅看護提供者（ＨＣＰ）または関連するサービス担当者は、特定の患者デバイス７２０のトラブルシューティングを行うために、図７のシステム７００を使用することができる。患者が患者デバイス７７２０に問題を経験した場合、ＨＣＰは、コンピューティングデバイス７６０を使用して特定の患者デバイス７２０に対するサーバー７１０に格納された診断データ７１８にアクセスすることができる。患者デバイス７２０に対する識別番号、例えば、シリアル番号を入力すると、サーバー７１０は、コンピューティングデバイス７６０にも図１１のスクリーンショット１１００に示したウェブページのようなトラブルシューティングウェブページを提供することができる。このウェブページには、選択したデバイスに対して障害が感知されたか否かを示すメッセージが明確に表示される場合がある。例えば、スクリーンショット１１００のウェブページは、障害が発生したことを示す障害メッセージ１１０２を表示する。このメッセージは、障害の性格を示すだけでなく、障害を処理する方法に対する指針を提供することができる。特に、図７に戻って、サーバー７１０は、検出された障害が遠隔で対処することができるか否かを決定することができる。そうであれば、障害メッセージは、障害に対する支援を求める際に使用される電話番号またはウェブページリンクを提供することができる。代替的に、障害が遠隔で対処することができないと判定された場合、メッセージは、障害を解決するために患者が患者デバイスをサービスセンターに運ばなければならないことを示すことができる。サーバー７１０に格納された診断データ７１８が障害が発生したことを示さない場合、障害が検出されなかったことを示すメッセージがウェブページ上に提供され得る。障害が遠隔で対処することができるか否かを決定することは、少なくとも部分的には、患者デバイス７２０に対する障害が特定の形態のハードウェア故障に基づくことを診断データ７１８が示すか否かに基づくことができるが、これは、ハードウェア故障に基づくいくつかの障害がサービスセンターで解決する必要があるからである。このような場合、トラブルシューティングが直ちに終了することができ、患者は、サービスのために患者デバイスを持ち込むように指示されることがある。

代替的に、マスク適合などのいくつかのハードウェア問題は、トラブルシューティングウェブページを介してＨＣＰまたは患者に命令を提供することによって、遠隔で対処することもできる。また、障害が不適切な患者デバイス設定に基づくか、または障害が患者デバイスのソフトウェアまたはファームウェアに基づく場合、障害は、サーバー７１０によって遠隔で対処することができる。例えば、患者デバイス７２０のソフトウェアにおける障害は、患者デバイス７２０に送信される命令セット７２６のアップデートによって対処することができる。したがって、サーバー７１０は、命令セット７２６のアップデートをネットワーク４２８２を介して患者デバイス７２０に送信することによって、トラブルシューティングを行うことができる。

障害メッセージ１１０２に加えて、図１１に示したトラブルシューテングウェッブページは、デバイスのモデル番号およびシリアル番号を含み、患者デバイス７２０に関する様々な情報を表示することができる。トラブルシューテングウェッブページには、呼吸圧力緩和、スマートスタート／ストップ、気候制御オプション、加湿設定、加熱管温度設定などのデバイスの現在の設定も表示されることもできる。 トラブルシューテングウェッブページには、障害が発生した時刻またはその付近の時刻で患者の室内温度および湿度のような環境診断データを表示することができる。また、ラブルシューテングウェッブページは、スクリーンショット１１００に表示された５日間の使用アイコン１１０４などの使用データを表示することができる。前述したように、この使用データは、患者が患者デバイスを使用した時間量、空気漏れが検出された程度だけでなく、患者の無呼吸−呼吸低下指数に関連したデータを示すことができる。患者デバイスの周辺条件は、トラブルシューテングウェッブページにも表示され得る。加湿器５０００のタイプおよび患者インターフェース３０００のタイプのような患者が使用する様々な構成要素の識別情報は、トラブルシューテングウェッブページでも確認することができる。この情報は、障害を対処する方法を決定するために、ＨＣＰによって使用され得る。例えば、空気漏れに関連した障害は、患者が使用するマスクのタイプに応じて異なる方法で対処することができる。図１１に示したように、患者デバイス７２０に対する最近の漏れ情報と共に、使用されるマスクのタイプに関するトラブルシューテングウェッブページ上に情報が提供され得る。マスク情報は、治療の予期しない停止または乏しいマスク適合に関するインジケータとして使用されることができ、患者デバイス７２０と共に使用されるマスクのデザイン、サイズおよびブランドの識別を含むことができる。

トラブルシューテングウェッブページ、すなわち、ＨＣＰを使用して障害を引き起こした原因を識別し、問題に対処するために患者デバイス７２０の設定を調整することができる。一様態において、ＨＣＰは、トラブルシューテングウェッブページに直接調整を入力することによって、患者の治療および患者デバイス７２０の設定を調整することができる。例えば、ＨＣＰは、図１１のトラブルシューテングウェッブページを使用して、デバイス１２３４５６７８９の湿度レベルをレベル５からレベル３に調整することができる。トラブルシューテングウェッブページの湿度レベルを変更することは、図７に示したサーバー７１０によって受信され得る。次に、サーバー７１０は、患者デバイス７２０に湿度変更命令を送信することができる。患者デバイス７２０は、受信された命令に応答してその湿度レベルを変更することができる

一態様によれば、サーバー７１０は、動作および障害の診断ログの形態で診断データ７１８をコンピューティングデバイス７６０に送信することができる。一例において、コンピューティングデバイス７６０のユーザーは、一つまたは複数の患者デバイス７２０に対するサーバー７１０から診断ログを要求することができる。この要求は、ログに含まれる診断データのタイプを特定することができる。例えば、ユーザーは、コンピューティングデバイス７６０を介して特定の患者デバイスに対して発生したすべての障害に対する診断ログを要求することができる。代替的に、ユーザーは、加湿器５０００のような特定の構成要素または構成要素セットに関連したすべての診断データのログを要求することができる。このような方式で、コンピューティングデバイスのユーザーは、患者デバイス７２０に関連して発生した問題に対処するのに使用され得る特定の情報セットが提供され得る。

図１２のスクリーンショット１２００は、コンピューティングデバイス上に表示され得る例示的な診断ログを示す。この例において、コンピューティングデバイスは、シリアル番号１２３４５６７８９を有する患者デバイスで過去２４時間の間に発生したすべての活動および障害のログを要求した。コラム見出し１２０４の下で識別された日付と時間は、発生された各障害の日付と時間を示す一方、コラム見出し１２０６にある情報は、エントリが活動または障害に関連するが否かを指定する。コラム見出し１２０８に提供されるように、エラーコードは、各障害に対して識別され得る。これを介してサービス担当者は、発生した特定のタイプの障害を識別することができる。また、各ログエントリは、コラム見出し１２１０の下に提供される説明を含むことができる。ログエントリの説明は、ユーザーがデバイスのマスクを着用するとか離すことのような、発生された活動を識別するか、または発生された障害に対する情報を提供することができる。

一態様によれば、ユーザーに提示された診断ログは、ユーザー入力に基づいて拡張されるかフィルターリングされ得る。例えば、図１２に示した診断ログは、長期間にわたって、例えば、最後の３０日間にわたって、デバイス１２３４５６７８９に対して発生した活動および障害を含むように拡張され得る。診断ログは、特定のタイプの活動のみを示すか患者デバイスで発生した障害のみを表示するようにフィルターリングすることもできる。このような方式で、ユーザーは、患者デバイスをサービスするのに必要な情報に容易にアクセスすることができる。

一態様によれば、図７のサーバー７１０は、障害が患者デバイス７２０のうちの一つで検出される直ちに障害表示をコンピューティングデバイス７６０に送信することができる。したがって、診断データに対する要求を待たずに、サーバー７１０は、患者デバイス７２０に対する診断データが障害が発生したことを示す直ちにコンピューティングデバイス７６０に通知をプッシュすることができる。この通知は、ＳＭＳメッセージ、電子メールまたは他の形式のプッシュ通知として発生することができる。このようにして、ＨＣＰまたはサービス担当者は、患者デバイス７２０の問題点を直ちに通知受けることができる。一例において、プッシュ通知は、患者の治療に否定的な影響を及ぼすことができる障害を有する特定のタイプの障害に対してのみ提供されるだろう。したがって、患者デバイス７２０から障害の表示を受信すると、サーバー７１０は、識別された障害がプッシュ通知がコンピューティングデバイス７６０に送信されるべきか否かを決定することができる。

図１３は、前述したシステムの患者デバイスによって実行され得るフローチャート１３００である。ブロック１３０２において、患者デバイスは、命令セットにしたがって診断データを収集する。前述したように、診断データは、患者デバイスに関連して発生する動作および障害だけでなく、患者デバイスに対する設定の識別を含むことができる。診断データを収集する間に、患者デバイスは、トリガリングイベントが発生したか否かを決定する（ブロック１３０４）。一応、トリガリングイベントが識別されると、患者デバイスは、診断データをサーバーに送信するなど、 ネットワークを介して診断データの少なくとも一部を送信することができる（ブロック１３０６）。前述したように、トリガリングイベントは、患者によって実行される動作または患者デバイスによって実行される操作に基づくことができる。例えば、トリガリングイベントは、患者が所定の期間の間に患者デバイスを使用することを中断したという決定に基づくことができる。トリガリングイベントは、また、サーバーのような外部デバイスから診断データに対する要求を受信することを含むことができる。要求またはトリガーイベントは、患者デバイスが収集された診断データの特定の部分を送信することを要求することができる。例えば、患者デバイスは、最後の送信以後に収集されたすべての診断データを送信することができる。

患者デバイスは、また、サービスデータが受信されたか否かを決定することができる（ブロック１３０８）。サービスデータは、識別された障害に対処するために、遠隔サービスによって提供される情報を含むことができる。例えば、サービスデータは、患者デバイスのソフトウェアまたはファームウェアに対するアップデートまたは一つまたは複数の患者デバイス設定に対するアップデートを含むことができる。サービスデータが受信されない場合、患者デバイスは、診断データを収集し続け、ブロック１３０２および１３０４にしたがってトリガリングイベントが発生したか否かを決定することができる。しかし、サービスデータが受信された場合、患者デバイスは、受信されたサービスデータにしたがってアップデートすることができる（ブロック１３１０）。アップデートは、新しい命令セットを追加するか、現在の命令セットを変更するか、患者デバイスの設定を変更することを含むことができる。その後、患者デバイスは、アップデート命令を含むことができる現在の命令セットにしたがって診断データを収集し（ブロック１３０２）、診断データを送信する（ブロック１３０６）。

図１４は、システム７００のサーバー７１０を含む開示されたシステムのコンピューティングデバイスによって実行され得るフローチャート１４００を示す。ブロック１４０２において、サーバーは、一つまたは複数の患者デバイスに関連した診断データに対する質疑を受信することができる。例えば、前述したように、サーバー７１０は、特定の患者デバイスまたは患者デバイスなどのセットに関連してデータを求めるコンピューティングデバイス７６０から質疑を受信することができる。この質疑は、コンピューティングデバイス７６０のユーザーによって提供される一つまたは複数の基準を満たすすべての患者デバイスの識別を要求することができる。この基準は、一部の定義された障害を経験したデバイスを含む、患者デバイスの任意の数の態様または特徴に基づくことができる。このような方式で、コンピューティングデバイス７６０のユーザーは、可能であれば、患者が問題を言及するかユーザーに問題を通知する前に、障害が発生した直後に障害を認知することができる。サーバーは、受信された質疑に応答して診断データにアクセスすることができ（ブロック１４０４）、障害が一つまたは複数の患者デバイスに関連して発生したか否かを決定することができる（ブロック１４０６）。

サーバーは、一つまたは複数の患者デバイスに対して発生された任意の障害の識別を含み、一つまたは複数の患者デバイスに対する診断データを送信することによって質疑に応答することができる（ブロック１４０８）。診断データの送信は、図８〜図１２に示したウェッブページのような一つまたは複数のウェッブページにわたって起こることができる。前述したように、ウェッブページは、一つまたは複数の患者デバイスに対して発生された特定の障害だけでなく、それぞれの識別された障害に関連してとらなければならない潜在的な動作を識別することができる。

次に、サーバーは、一つまたは複数の患者デバイスに送信されるサービスデータに対する要求を受信することができる（ブロック１４１０）。送信されたサービスデータは、患者デバイス命令セットに対する一つまたは複数のデバイス設定またはアップデートで調整するための命令の形態を取ることができる。例えば、患者デバイスの導管内に識別された凝縮障害に対処する場合に、コンピューティングデバイス７６０のユーザーは、患者デバイスにサービスデータとして送信される特定の設定変更を選択して、患者デバイスの加湿器によって提供される加湿レベルを調整することができる。ブロック１４１０の要求を受信すると、サーバーは、サービスデータにアクセスするか、そうでなければ生成し（ブロック１４１２）、受信された要求で識別された患者デバイスにサービスデータを送信することができる（ブロック１４１４）。サーバーは、また、サービスデータの送信が成功的であったか否かを決定することができる（ブロック１４１６）。例えば、サーバーは、各患者デバイスからエラー通知またはサービスデータが成功的に具現されたというメッセージを受信することができる。サービスデータの送信にエラーが発生すると、サーバーは、エラーが発生した各患者デバイスに対してサービスデータを再び送信することができる（ブロック１４１４）。しかし、送信が成功的なら、サーバーは、格納された診断データを修正して一つまたは複数の患者デバイスが送信されたサービスデータを実行したことを表示することができる（ブロック１４１８）。

図１３および図１４に示した動作は、それぞれ単一デバイスによって実行され得るが、動作は、代替的に、一つまたは複数のデバイスによって実行され得る。例えば、患者デバイスは、無線ネットワークを介してパーソナルコンピュータと通信することができ、したがって、パーソナルコンピュータは、前述した一つまたは複数の動作を実行することができる。図１４および図９に関連して参照されるサーバーは、図１４および図９の実施例は、また、複数のサーバーを含むことができ、各サーバーは、前述した動作のうち、一つまたは複数を実行する。フローチャート１３００および１４００から様々な動作などが追加または除去され得る。例えば、本開示によるシステムは、ブロック１４１２〜ブロック１４１８に記載された手続きを実行せず、フローチャート１４００に関連した方法を実行することができる。また、様々な動作などがフローチャート１３００および１４００に示したものと同一の順序で実行される必要はない。

４．７ 用語解説
本発明の技術の特定の形態において、以下の定義のうちの一つまたは複数が適用され得る。本発明の技術の他の形態では、代替的な定義が適用され得る。

４．７．１ 一般的な事項
空気：空気は、呼吸可能な気体、例えば、酸素補給を有する空気を含むと解釈される。

持続的気道陽圧（ＣＰＡＰ）：ＣＰＡＰ処置は、大気に対して連続的に陽圧であり、好ましくは、患者の呼吸サイクルを介してほぼ一定した圧力で気道の入口への空気または呼吸可能な気体を供給することを意味する。いくつかの形態において、気道の入口における圧力は、単一呼吸サイクル内で数センチメートルの水によって変化し、例えば、吸気中に高く、呼気中に低い。いくつかの形態において、気道の入口における圧力は、呼気中はわずかに高く、吸気中はわずかに低いだろう。いくつかの形態において、患者の様々な呼吸サイクルの間に圧力が変化し、例えば、患者の一部上気道閉塞の指示が検出されるのに対応して増加し、一部上気道閉塞の徴候がないときは減少する。

４．７．２ 材料
シリコーンまたはシリコーンエラストマー：合成ゴム。本明細書において、シリコーンが参照される場合、これは、液体シリコーンゴム（ＬＳＲ）または圧縮形成シリコーンゴム（ＣＭＳＲ）を指す。商業的に販売されているＬＳＲの一形態は、Ｄｏｗ Ｃｏｒｎｉｎｇで製造したＳＩＬＡＳＴＩＣ（この商標で販売されている製品の範囲に含まれ）である。ＬＳＲのまた他の製造社は、Ｗａｃｋｅｒである。別に、反対として明示されない限り、ＬＳＲの好ましい形態は、ＡＳＴＭ Ｄ２２４０を使用して測定時に、約３５〜約４５の範囲内のショアＡ（またはタイプ Ａ）圧入硬度を有する。

ポリカーボネート：ビスフェノール−Ａ カーボネートの典型的に透明な熱可塑性重合体。

４．７．３ 患者インターフェースの諸側面
窒息防止弁（ＡＡＶ）：大気圧に対してフェイルセーフ（failsafe manner）に開くことによって患者が過度なＣＯ_２を再呼吸する危険を減らす、マスクシステムの構成要素または部分構成要素。

屈曲部：角度にわたって方向を変化させるための、流れまたは空気の軸方向を誘導する導管。一形態において、この角度は、約９０度であり得る。また他の形態において、この角度は、９０度未満であり得る。導管は、ほぼ円形の断面を有することができる。他の形態において、導管は、楕円形または矩形の断面を有することができる。

フレーム：フレームは、ヘッドギアとの２つ以上の接続点の間で張力の負荷を担うマスク構造を意味すると解釈される。マスクフレームは、マスク内の非気密耐荷重性構造（non-airtight load bearing structure）であってもよい。しかし、いくつかの形態のマスクフレームは、また、気密であってもよい。

ヘッドギア：ヘッドギアは、頭部に対して使用するために設計された位置決めおよび安定化構造の一形態を意味すると解釈される。一実施例において、ヘッドギアは、呼吸治療を送達するために患者インターフェースを患者の顔上の定位置に配置および維持するように構成された一つまたは複数の支柱、タイ（ｔｉｅ）および補強材の集合を備える。いくつかのタイは、発泡体および布地の積層複合材のように、柔軟な、可撓性で、弾性の材料から形成される。

膜：膜は、好ましくは、実質的に屈曲に対する耐性を有しないが、伸張に対する耐性を有する、典型的に薄い要素を意味すると解釈される。

プレナムチャンバ：患者インターフェースプレナムチャンバは、フルフェイスマスク（例：鼻および口マスク）、鼻マスクまたは鼻枕のようなある容積の空間を囲む壁を有する患者インターフェースの一部を意味すると解釈され、前記容積部は、患者による使用時に大気圧以上に加圧された空気を内部に有する。シェルは、患者インターフェースプレナムチャンバの壁の一部を形成することができる。一つの形態において、患者の顔の領域は、クッションまたはシールのようなプレナムチャンバの壁のうち、一つに接する。

シール：名詞形（「ａ ｓｅａｌ」）は、２つの表面の界面を通る空気の流れに意図的に抵抗する構造または障壁を意味すると解釈される。動詞形（「ｔｏ ｓｅａｌ」）は、空気の流れに抵抗することを意味すると解釈される。

シェル：シェルは、屈曲、引張および圧縮剛性を有する湾曲構造、例えば、マスクの湾曲構造壁を形成するマスクの部分を意味すると解釈される。好ましくは、その全体寸法と比較して、シェルは相対的に薄い。いくつかの形態において、シェルはファセット状になっていてもよい。好ましくは、そのような壁は、気密性があるが、いくつかの形態において、それらは気密性がなくてもよい。

補強材：補強材は、少なくとも１つの方向において別の構成要素の屈曲耐性を増大させるように設計された構造的構成要素を意味すると解釈される。

支柱：支柱は、少なくとも１つの方向において別の構成要素の圧縮耐性を増大させるように設計された構造的構成要素を意味すると解釈される。

スイベル：（名詞）例えば、低トルク下で、例えば、独立的に、共通の軸を中心として回転するように構成されている構成要素のサブアセンブリ。一形態において、スイベルは、少なくとも３６０度の角度、回転するように構成されている。他の形態において、スイベルは、３６０度未満の角度、回転するように構成されている。空気導管の文脈において使用される場合、例えば、構成要素のサブアセンブリは、一致した対の円筒形導管を含む。好ましくは、使用中、スイベルから空気が漏れる流れはほとんどまたは全くない。

タイ（Ｔｉｅ）：タイは、張力に抵抗するように設計された構造的構成要素であると解釈される。

換気口：（名詞）マスクの内部からの空気の漏れの速度を慎重に制御することを可能にする構造、または、吐き出された二酸化炭素（ＣＯ_２）の流出および酸素（Ｏ_２）の供給を可能にするための、外気に対する導管。

４．８ その他の備考
本特許明細書の開示の一部は、著作権保護の対象となる資料を含む。特許商標庁の特許包袋または記録において明らかにするために、著作権所有者は、特許文書または特許開示のいずれかによるファクシミリ複製に対しても異論を唱えないが、その他の面では、どんなものであれ、すべての著作権を保有している。

文脈上、別に明らかに示していない限り、値の範囲が与えられている場合、下限の単位の１０分の１までの、その範囲の上限と下限との間にある介在する値が、 本発明の技術内に包含されることと理解される。独立的に介在する範囲内に含まれることができ、これらの介在する範囲の上限および下限も記載している範囲内の任意の具体的に除外される限度の対象となり、同様に、本発明の技術内に含まれる。記載されている範囲が一方または両方の限界値を含む場合、これらの含まれている限界値のうちの一方または両方を除外した範囲も本発明の技術に含まれる。

さらに、一つまたは複数の値が本明細書において本発明の技術の一部として実施されるものとして記載される場合、そのような値は、別途の言及がない限り近似値であってもよく、そのような値は、実際の技術的な実施がそれを許容するがまたは必要とする限り、任意の適切な有効数字に利用され得ると理解されなければならない。

別に定義されない限り、本明細書において使用するすべての技術用語および科学用語は、本発明の技術が属する技術分野の当業者によって一般に理解されている意味と同じ意味を有する。本明細書に記載されているものと同様または均等な任意の方法および材料を、本発明の技術の実施または実験において同じく使用することができるが、本明細書には、限られた数の例示的な方法および材料しか記載されていない。

特定の材料が使用するのに好ましく、または、構成要素を構成するための一実施例であると確認される場合、同様の特性を有する自明の代替的な材料が代替用として使用され得る。さらに、他に明示されない限り、本明細書に記載された任意のおよびすべての構成要素は、製造することができると理解され、したがって、一体にまたは別々に製造することができる。

本明細書および添付の特許請求の範囲において使用されているものとしての、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、別途文脈が明確に示していない限り、それらの複数の均等物を含むことに留意しなければならない。

本明細書において言及されるすべての刊行物は、それらの刊行物が対象とする方法および／または材料を開示および記載するために、参照として本明細書に組み込まれる。本明細書において記述される刊行物は、本出願の出願日よりも前に、それらの開示のために単独で提供されている。本明細書におけるいかなる記載も、本発明の技術が、先行する発明によってそのような刊行物に先行する資格（ａｄｍｉｓｓｉｏｎ）がないことを認めるものとして解釈されるべきではない。さらに、記載されている刊行日は、実際の刊行日とは異なる場合があり、これは個別に確認する必要がある場合がある。

さらに、本開示を解釈する上で、すべての用語は、文脈と一致する最も広い合理的な方法で解釈されるべきである。特に、「含む（ｃｏｍｐｒｉｓｅｓ）」および「含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、要素、構成要素、またはステップを非排他的に指しているものとして解釈されるべきであり、参照される要素、構成要素、またはステップが、明示的には参照されていない他の要素、構成要素、またはステップと共に存在し、または共に利用されるか、またはそれらと組み合わされてもよいことを示している。

詳細な説明において使用される主題の見出しは、読者が参照するのを容易にするためにのみ含まれており、特許請求の範囲の開示全体を通じて見出される主題を限定するように使用されるべきではない。主題の見出しは、特許請求の範囲または特許請求の範囲の限定事項を解釈するのに使用されるべきではない。

本発明における技術を、特定の実施形態を参照して説明したが、これらの実施形態は、本発明の技術の原理および応用の例示に過ぎないことを理解されたい。いくつかの事例において、用語および記号は、本発明の技術を実施するのに必要ではない特定の詳細を暗示する場合がある。例えば、「第１の」および「第２の」という用語が使用される場合があるが、別途明記されていない限り、それらは、任意の順序を示すように意図されず、別個の要素の間で区別するために利用され得る。さらに、方法における工程が、ある順序で記載または図示されている場合があるが、そのような順序は必須ではない。そのような順序は変更されてもよく、および／またはそれらの態様は同時に、またはさらには同期して実行されてもよいことを、当業者は認識しよう。

したがって、本発明の技術の精神および範囲から逸脱することなく、例示的な実施形態に対して多数の変更をなすことができること、および、他の構成を考え出すことができることを理解されたい。
なお、特願２０１６−５６９７５１における平成２９年１月２６日提出の手続補正書に記載の特許請求の範囲は以下のとおりである。
［請求項１］
医療デバイスの診断モニタリングのための方法であって、
一つまたは複数のプロセッサーによって、患者デバイスから診断データを受信するステップであって、前記診断データは前記患者デバイス内の障害の存在を識別するものである、ステップと、
前記一つまたは複数のプロセッサーによって、受信された前記診断データを格納するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分に基づいて障害の存在を識別するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分と、前記患者デバイスの識別された障害との少なくともいずれかを遠隔コンピューティングデバイスに送信するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分と識別された障害との少なくともいずれかに基づいて識別されたサービスデータを前記患者デバイスに送信するステップと
を含む方法。
［請求項２］
前記一つまたは複数のプロセッサーによって、診断データの第１の部分の少なくとも一つを前記遠隔コンピューティングデバイスに送信することに応じて、前記患者デバイスに送信されることになる前記サービスデータの識別を受信するステップであって、前記サービスデータの少なくとも一部は前記患者デバイスの特定された障害を解決するものである、ステップを更に含む請求項１に記載の方法。
［請求項３］
前記患者デバイスが、呼吸圧力治療デバイスを含む、請求項１または２に記載の方法。
［請求項４］
前記診断データが、トリガリングイベントの発生に基づいて受信される、請求項１〜３のいずれか一項に記載の方法。
［請求項５］
任意の患者が障害のあるデバイスを有しているか否かを示すデータを前記遠隔コンピューティングデバイスに送信するステップを更に含む請求項１〜４のいずれか一項に記載の方法。
［請求項６］
前記診断データが更に、患者の無呼吸指数、呼吸低下指数又は無呼吸−呼吸低下指数と、治療設定と、快適設定と、障害データと、患者使用量と、漏れデータと、周囲湿度データと、治療および快適設定と、デバイス動作と、前記患者デバイスの障害ログとのうちの少なくとも一つを含む、請求項１〜５のいずれか一項に記載の方法。
［請求項７］
前記一つまたは複数のプロセッサーによって、前記サービスデータが正常に送信されたことの表示を前記患者デバイスから受信するステップと、
前記一つまたは複数のプロセッサーによって、前記サービスデータの実行を示すために前記診断データをアップデートするステップと
を更に含む請求項１〜６のいずれか一項に記載の方法。
［請求項８］
前記障害の存在は、障害が発生した患者デバイスの構成要素、サブシステムまたは機能領域に基づいて識別される、請求項１〜７のいずれか一項に記載の方法。
［請求項９］
前記診断データの第１の部分を送信することが、遠隔コンピューティングデバイスへのプッシュ通知を含み、識別された障害がプッシュ通知が提供されるタイプのものであるという決定に基づいて前記プッシュ通知が送信される、請求項１〜８のいずれか一項に記載の方法。
［請求項１０］
前記サービスデータが、前記患者デバイスの一つまたは複数の設定を調整するための命令を含む、請求項１〜９のいずれか一項に記載の方法。
［請求項１１］
前記診断データが、障害が発生した時点で前記患者デバイスの一つまたは複数の設定を識別する、請求項１〜１０のいずれか一項に記載の方法。
［請求項１２］
前記識別された障害を送信することが、前記遠隔コンピューティングデバイス上にディスプレイ用アイコンを提供することを含む、請求項１〜１１のいずれか一項に記載の方法。
［請求項１３］
前記アイコンが、発生された障害のタイプに基づいて変化する可変的な外観を有する、請求項１２に記載の方法。
［請求項１４］
前記識別された障害を送信することが更に、前記遠隔コンピューティングデバイス上にディスプレイ用使用量アイコンを提供することを含み、前記使用量アイコンは、患者デバイスが使用された程度を示す、請求項１〜１３のいずれか一項に記載の方法。
［請求項１５］
前記診断データは、前記診断デバイスと共に使用されるマスクタイプの漏れ情報と識別とを含む、請求項１〜１４のいずれか一項に記載の方法。
［請求項１６］
前記診断データが、前記患者デバイスの患者デバイス識別子によってアクセス可能である、請求項１〜１５のいずれか一項に記載の方法。
［請求項１７］
前記識別された障害を送信することが、デバイス関連障害が発生したか否かの可視的な表示をディスプレイのために提供することを更に含む、請求項１〜１６のいずれか一項に記載の方法。
［請求項１８］
医療デバイスの診断モニタリングのための方法であって、
一つまたは複数のプロセッサーによって、患者デバイスの動作に関する診断データを収集し、前記診断データが前記患者デバイスに関連した障害の存在を識別するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データがネットワークを介して送信されるトリガリングイベントが発生したことを決定するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データを、前記ネットワークを介して送信するステップであって、前記診断データの少なくとも第１の部分は、前記障害の存在がコンピューティングデバイスによって識別可能であるように構成される、ステップと、
識別された障害に対処するサービスデータを前記一つまたは複数のプロセッサーによって受信するステップと、
前記一つまたは複数のプロセッサーによって、受信されたサービスデータにしたがって一つまたは複数の動作を実行するステップと
を含む方法。
［請求項１９］
前記患者デバイスが、呼吸圧力治療デバイスを含む、請求項１８に記載の方法。
［請求項２０］
前記トリガリングイベントが、前記診断データが送信される前に満たされる一つまたは複数の条件に基づく、請求項１８または１９に記載の方法。
［請求項２１］
前記トリガリングイベントは、所定の期間の間に前記患者デバイスを使用することを終えた患者に基づくか、または前記診断データが送信されるスケジュールに基づく、請求項１８〜２０のいずれか一項に記載の方法。
［請求項２２］
前記サービスデータは第１の部分および第２の部分を含み、両部分は、前記患者デバイスの別々の構成要素に関連する、請求項１８〜２１のいずれか一項に記載の方法。
［請求項２３］
任意の患者が障害のあるデバイスを有しているか否かを示すデータを前記遠隔コンピューティングデバイスに送信するステップを更に含む請求項１８〜２２のいずれか一項に記載の方法。
［請求項２４］
前記診断データの少なくとも一部が、患者の無呼吸指数と、呼吸低下指数と、無呼吸−呼吸低下指数と、障害データと、患者使用量と、漏れデータと、周囲湿度データと、治療および快適設定と、注文デバイス活動と、障害ログとのうちの少なくとも一つに関係する、請求項１８〜２３のいずれか一項に記載の方法。
［請求項２５］
一つまたは複数のコンピューティングデバイスを含む医療デバイスの診断モニタリングのためのシステムであって、
前記一つまたは複数のコンピューティングデバイスが、
複数の患者デバイスから診断データを受信し、前記診断データが前記複数の患者デバイスのうちの少なくとも一つにおける障害の存在を識別し、
前記診断データを格納し、
前記診断データの第１の部分に基づいて、第１の患者デバイスにおける障害の存在を識別し、
前記診断データの第１の部分と、識別された前記障害とのうちの少なくともいずれかを送信し、
前記診断データの第１の部分または識別された障害に基づいて識別されたサービスデータを前記第１の患者デバイスに送信する、システム。
［請求項２６］
前記システムが、遠隔デバイスからのクエリに応じて、前記診断データの第１の部分または前記識別された障害を送信する、請求項２５に記載のシステム。
［請求項２７］
前記システムが更に、前記患者デバイスに送信されることになる前記サービスデータの識別を受信するものであり、前記サービスデータの少なくとも一部が識別された障害に対処するものである、請求項２５または２６に記載のシステム。
［請求項２８］
前記第１の患者デバイスが呼吸圧力治療デバイスを含む、請求項２５〜２７のいずれか一項に記載のシステム。
［請求項２９］
前記診断データが、トリガリングイベントの発生に基づいて受信される、請求項２５〜２８のいずれか一項に記載のシステム。
［請求項３０］
前記診断データが、患者の無呼吸指数と、呼吸低下指数と、無呼吸−呼吸低下指数と、障害データと、患者使用量と、漏れデータと、周囲湿度データと、治療および快適設定と、注文デバイス活動と、障害ログとのうちの少なくとも一つを含む、請求項２５〜２９のいずれか一項に記載のシステム。
［請求項３１］
前記一つまたは複数のコンピューティングデバイスが更に、
前記サービスデータが正常に送信されたという表示を第１の患者デバイスから受信し、
前記第１の患者デバイスによってサービスデータの実行を示すために、診断データをアップデートする、請求項２５〜３０のいずれか一項に記載のシステム。
［請求項３２］
前記システムは、任意の患者が障害のあるデバイスを有しているか否かを示すデータを遠隔コンピューティングデバイスに送信する、請求項２５〜３１のいずれか一項に記載のシステム。
［請求項３３］
前記診断データが、患者の無呼吸指数、呼吸低下指数または無呼吸−呼吸低下指数と、治療設定と、快適設定と、障害データと、患者使用量と、漏れデータと、周囲湿度データと、治療および快適設定と、注文デバイス活動と、患者デバイスの障害ログとのうちの少なくとも一つを含む、請求項２５〜３２のいずれか一項に記載のシステム。
［請求項３４］
前記障害の存在が、前記第１の患者デバイスの構成要素、サブシステムまたは機能領域において識別される、請求項２５〜３３のいずれか一項に記載のシステム。
［請求項３５］
前記診断データの第１の部分の送信が遠隔コンピューティングデバイスへのプッシュ通知を含み、識別された障害がプッシュ通知が提供されるタイプのものであるという決定に基づいて前記プッシュ通知が送信される、請求項２５〜３４のいずれか一項に記載のシステム。
［請求項３６］
前記サービスデータが、前記第１の患者デバイスの一つまたは複数の設定を調整するための命令を含む、請求項２５〜３５のいずれか一項に記載のシステム。
［請求項３７］
前記診断データが、障害が発生した時点で第１の患者デバイスの一つまたは複数の設定を識別する、請求項２５〜３６のいずれか一項に記載のシステム。
［請求項３８］
前記識別された障害を送信することが、遠隔コンピューティングデバイス上にディスプレイ用アイコンを提供することを含む、請求項２５〜３７のいずれか一項に記載のシステム。
［請求項３９］
前記アイコンが、発生した障害のタイプに基づいて変化する可変的な外観を有する、請求項３８に記載のシステム。
［請求項４０］
前記識別された障害を送信することが更に、遠隔コンピューティングデバイス上にディスプレイ用使用量アイコンを提供することを含み、前記使用量アイコンは、第１の患者デバイスが使用された程度を示す、請求項２５〜３９のいずれか一項に記載のシステム。
［請求項４１］
前記診断データは、前記診断デバイスと共に使用されるマスクタイプの漏れ情報と識別とを含む、請求項２５〜４０のいずれか一項に記載の方法。
［請求項４２］
前記診断データが、前記患者デバイスの患者デバイス識別子によってアクセス可能である、請求項２５〜４１のいずれか一項に記載のシステム。
［請求項４３］
前記識別された障害を送信することが更に、デバイス関連障害が発生したか否かの可視的な表示をディスプレイするために提供することを含む、請求項２５〜４２のいずれか一項に記載のシステム。
また、特願２０１６−５６９７５１における平成３０年５月２８日提出の手続補正書に記載の特許請求の範囲は以下のとおりである。
［請求項１］
医療デバイスの診断モニタリングのための方法であって、
一つまたは複数のプロセッサーによって、患者デバイスから診断データを受信するステップであって、前記診断データは前記患者デバイス内の障害の存在を識別するものである、ステップと、
前記一つまたは複数のプロセッサーによって、受信された前記診断データを格納するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分に基づいて障害の存在を識別するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分と、前記患者デバイスの識別された障害との少なくともいずれかを遠隔コンピューティングデバイスに送信するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分と識別された障害との少なくともいずれかに基づいて識別されたサービスデータを前記患者デバイスに送信するステップと
を含む方法。
［請求項２］
前記一つまたは複数のプロセッサーによって、診断データの第１の部分の少なくとも一つを前記遠隔コンピューティングデバイスに送信することに応じて、前記患者デバイスに送信されることになる前記サービスデータの識別を受信するステップであって、前記サービスデータの少なくとも一部は前記患者デバイスの特定された障害を解決するものである、ステップを更に含む請求項１に記載の方法。
［請求項３］
前記患者デバイスが、呼吸圧力治療デバイスを含む、請求項１または２に記載の方法。
［請求項４］
前記診断データが、トリガリングイベントの発生に基づいて受信される、請求項１〜３のいずれか一項に記載の方法。
［請求項５］
任意の患者が障害のあるデバイスを有しているか否かを示すデータを前記遠隔コンピューティングデバイスに送信するステップを更に含む請求項１〜４のいずれか一項に記載の方法。
［請求項６］
前記診断データが更に、患者の無呼吸指数、呼吸低下指数又は無呼吸−呼吸低下指数と、治療設定と、快適設定と、障害データと、患者使用量と、漏れデータと、周囲湿度データと、治療および快適設定と、デバイス動作と、前記患者デバイスの障害ログとのうちの少なくとも一つを含む、請求項１〜５のいずれか一項に記載の方法。
［請求項７］
前記一つまたは複数のプロセッサーによって、前記サービスデータが正常に送信されたことの表示を前記患者デバイスから受信するステップと、
前記一つまたは複数のプロセッサーによって、前記サービスデータの実行を示すために前記診断データをアップデートするステップと
を更に含む請求項１〜６のいずれか一項に記載の方法。
［請求項８］
前記障害の存在は、障害が発生した患者デバイスの構成要素、サブシステムまたは機能領域に基づいて識別される、請求項１〜７のいずれか一項に記載の方法。
［請求項９］
前記診断データの第１の部分を送信することが、遠隔コンピューティングデバイスへのプッシュ通知を含み、識別された障害がプッシュ通知が提供されるタイプのものであるという決定に基づいて前記プッシュ通知が送信される、請求項１〜８のいずれか一項に記載の方法。
［請求項１０］
前記サービスデータが、前記患者デバイスの一つまたは複数の設定を調整するための命令を含む、請求項１〜９のいずれか一項に記載の方法。
［請求項１１］
前記診断データが、障害が発生した時点で前記患者デバイスの一つまたは複数の設定を識別する、請求項１〜１０のいずれか一項に記載の方法。
［請求項１２］
前記識別された障害を送信することが、前記遠隔コンピューティングデバイス上にディスプレイ用アイコンを提供することを含む、請求項１〜１１のいずれか一項に記載の方法。
［請求項１３］
前記アイコンが、発生された障害のタイプに基づいて変化する可変的な外観を有する、請求項１２に記載の方法。
［請求項１４］
前記識別された障害を送信することが更に、前記遠隔コンピューティングデバイス上にディスプレイ用使用量アイコンを提供することを含み、前記使用量アイコンは、患者デバイスが使用された程度を示す、請求項１〜１３のいずれか一項に記載の方法。
［請求項１５］
前記診断データは、前記診断デバイスと共に使用されるマスクタイプの漏れ情報と識別とを含む、請求項１〜１４のいずれか一項に記載の方法。
［請求項１６］
前記診断データが、前記患者デバイスの患者デバイス識別子によってアクセス可能である、請求項１〜１５のいずれか一項に記載の方法。
［請求項１７］
前記識別された障害を送信することが、デバイス関連障害が発生したか否かの可視的な表示をディスプレイのために提供することを更に含む、請求項１〜１６のいずれか一項に記載の方法。
［請求項１８］
医療デバイスの診断モニタリングのための方法であって、
一つまたは複数のプロセッサーによって、患者デバイスの動作に関する診断データを収集し、前記診断データが前記患者デバイスに関連した障害の存在を識別するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データがネットワークを介して送信されるトリガリングイベントが発生したことを決定するステップと、
前記一つまたは複数のプロセッサーによって、前記診断データを、前記ネットワークを介して送信するステップであって、前記診断データの少なくとも第１の部分は、前記障害の存在がコンピューティングデバイスによって識別可能であるように構成される、ステップと、
識別された障害に対処するサービスデータを前記一つまたは複数のプロセッサーによって受信するステップと、
前記一つまたは複数のプロセッサーによって、受信されたサービスデータにしたがって一つまたは複数の動作を実行するステップと
を含む方法。
［請求項１９］
前記トリガリングイベントが、前記診断データが送信される前に満たされる一つまたは複数の条件に基づく、請求項１８に記載の方法。
［請求項２０］
前記トリガリングイベントは、所定の期間の間に前記患者デバイスを使用することを終えた患者に基づくか、または前記診断データが送信されるスケジュールに基づく、請求項１８または１９に記載の方法。
［請求項２１］
前記サービスデータは第１の部分および第２の部分を含み、両部分は、前記患者デバイスの別々の構成要素に関連する、請求項１８〜２０のいずれか一項に記載の方法。
［請求項２２］
前記診断データの少なくとも一部が、患者の無呼吸指数と、呼吸低下指数と、無呼吸−呼吸低下指数と、障害データと、患者使用量と、漏れデータと、周囲湿度データと、治療および快適設定と、注文デバイス活動と、障害ログとのうちの少なくとも一つに関係する、請求項１８〜２１のいずれか一項に記載の方法。

引用符号のリスト
システム ７００
サーバー ７１０
プロセッサー ７１２
メモリ ７１４
命令 ７１５
サービスデータ ７１６
診断データ ７１８
患者デバイス ７２０
命令セット ７２６
診断データ ７２８
格納システム ７５０
コンピューティングデバイス ７６０
プロセッサー ７６２
メモリ ７６４
ディスプレイ ７６６
ユーザー入力デバイス ７６８
スクリーンショット ８００
検索フィールド ８０２
コラム見出し ８０４〜８１２
アイコン ８１４〜８１８
スクリーンショット ９００
ウィンドウ ９０２
カーソル ９０４
警告アイコン ９０６
チェックアイコン ９０８
患者 １０００
スクリーンショット １０００
コラム １００２
コラム １００４
コラム見出し １００６
空の使用アイコン １０１０
アイコン １０１２〜１０２０
スクリーンショット １１００
障害メッセージ １１０２
使用アイコン １１０４
スクリーンショット １２００
コラム見出し １２０４〜１２１０
患者インターフェース ３０００
シール形成構造 ３１００
プレナムチャンバ ３２００
周辺部 ３２１０
換気口 ３４００
接続ポート ３６００
ＲＰＴデバイス ４０００
外部ハウジング ４０１０
外部ハウジングの上部 ４０１２
外部ハウジングの下部 ４０１４
パネル ４０１５
シャーシ ４０１６
ハンドル ４０１８
空気圧ブロック ４０２０
空気圧構成要素 ４１００
空気フィルター ４１１０
空気入口フィルター ４１１２
出口空気フィルター ４１１４
マフラー ４１２０
入口マフラー ４１２２
出口マフラー ４１２４
圧力デバイス ４１４０
制御可能な圧力デバイス ４１４０
送風機 ４１４２
制御可能な送風機 ４１４２
ブラシレスＤＣモータ ４１４４
バック弁 ４１６０
空気回路 ４１７０
補給酸素 ４１８０
電気構成要素 ４２００
ＲＰＴデバイス電気構成要素 ４２００
ＰＣＢＡ ４２０２
電力供給装置 ４２１０
入力デバイス ４２２０
中央コントローラ ４２３０
クロック ４２３２
治療デバイスコントローラ ４２４０
保護回路 ４２５０
メモリ ４２６０
トランスデューサ ４２７０
圧力トランスデューサ ４２７２
圧力センサ ４２７１
モータ速度信号 ４２７６
データ通信インターフェース ４２８０
遠隔外部通信ネットワーク ４２８２
ローカル外部通信ネットワーク ４２８４
遠隔外部デバイス ４２８６
ローカル外部デバイス ４２８８
出力デバイス ４２９０
ディスプレイドライバ ４２９２
ディスプレイ ４２９４
圧力制御モジュール ４３３０
加湿器 ５０００
加湿器コントローラ ５２５０
湿度コントローラ ５２９０
患者デバイス ７７２０

Claims (17)

1. 医療デバイスの診断モニタリングのための方法であって、
   一つまたは複数のプロセッサーによって、患者デバイスから診断データを受信するステップであって、前記診断データは前記患者デバイス内の障害の存在を識別するものである、ステップと、
   前記一つまたは複数のプロセッサーによって、受信された前記診断データを格納するステップと、
   前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分に基づいて障害の存在を識別するステップと、
   前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分と、前記患者デバイスの識別された障害との少なくともいずれかを遠隔コンピューティングデバイスに送信するステップと、
   所定の時間が経過すると、前記一つまたは複数のプロセッサーによって、前記診断データの第１の部分と識別された障害との少なくともいずれかに基づいて識別されたサービスデータを前記患者デバイスに送信するステップであって、前記所定の時間において前記患者デバイスは患者により使用されないものである、ステップと
   を含む方法。
2. 前記一つまたは複数のプロセッサーによって、診断データの第１の部分の少なくとも一つを前記遠隔コンピューティングデバイスに送信することに応じて、前記患者デバイスに送信されることになる前記サービスデータの識別を受信するステップであって、前記サービスデータの少なくとも一部は前記患者デバイスの特定された障害を解決するものである、ステップを更に含む請求項１に記載の方法。
3. 前記患者デバイスが、呼吸圧力治療デバイスを含む、請求項１または２に記載の方法。
4. 前記診断データが、トリガリングイベントの発生に基づいて受信される、請求項１〜３のいずれか一項に記載の方法。
5. 任意の患者が障害のあるデバイスを有しているか否かを示すデータを前記遠隔コンピューティングデバイスに送信するステップを更に含む請求項１〜４のいずれか一項に記載の方法。
6. 前記診断データが更に、患者の無呼吸指数、呼吸低下指数又は無呼吸−呼吸低下指数と、治療設定と、快適設定と、障害データと、患者使用量と、漏れデータと、周囲湿度データと、治療および快適設定と、デバイス動作と、前記患者デバイスの障害ログとのうちの少なくとも一つを含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記一つまたは複数のプロセッサーによって、前記サービスデータが正常に送信されたことの表示を前記患者デバイスから受信するステップと、
   前記一つまたは複数のプロセッサーによって、前記サービスデータの実行を示すために前記診断データをアップデートするステップと
   を更に含む請求項１〜６のいずれか一項に記載の方法。
8. 前記障害の存在は、障害が発生した患者デバイスの構成要素、サブシステムまたは機能領域に基づいて識別される、請求項１〜７のいずれか一項に記載の方法。
9. 前記診断データの第１の部分を送信することが、遠隔コンピューティングデバイスへのプッシュ通知を含み、識別された障害がプッシュ通知が提供されるタイプのものであるという決定に基づいて前記プッシュ通知が送信される、請求項１〜８のいずれか一項に記載の方法。
10. 前記サービスデータが、前記患者デバイスの一つまたは複数の設定を調整するための命令を含む、請求項１〜９のいずれか一項に記載の方法。
11. 前記診断データが、障害が発生した時点で前記患者デバイスの一つまたは複数の設定を識別する、請求項１〜１０のいずれか一項に記載の方法。
12. 前記識別された障害を送信することが、前記遠隔コンピューティングデバイス上にディスプレイ用アイコンを提供することを含む、請求項１〜１１のいずれか一項に記載の方法。
13. 前記アイコンが、発生された障害のタイプに基づいて変化する可変的な外観を有する、請求項１２に記載の方法。
14. 前記識別された障害を送信することが更に、前記遠隔コンピューティングデバイス上にディスプレイ用使用量アイコンを提供することを含み、前記使用量アイコンは、患者デバイスが使用された程度を示す、請求項１〜１３のいずれか一項に記載の方法。
15. 前記診断データは、前記診断デバイスと共に使用されるマスクタイプの漏れ情報と識別とを含む、請求項１〜１４のいずれか一項に記載の方法。
16. 前記診断データが、前記患者デバイスの患者デバイス識別子によってアクセス可能である、請求項１〜１５のいずれか一項に記載の方法。
17. 前記識別された障害を送信することが、デバイス関連障害が発生したか否かの可視的な表示をディスプレイのために提供することを更に含む、請求項１〜１６のいずれか一項に記載の方法。