(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-14
(54)【発明の名称】モジュラデジタル治療システム、コンピュータ実施方法
(51)【国際特許分類】
G16H 20/10 20180101AFI20240206BHJP
【ＦＩ】
G16H20/10
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023547089
(86)(22)【出願日】2022-01-28
(85)【翻訳文提出日】2023-09-28
(86)【国際出願番号】 GB2022050233
(87)【国際公開番号】W WO2022167781
(87)【国際公開日】2022-08-11
(31)【優先権主張番号】63/145,077
(32)【優先日】2021-02-03
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＡＮＤＲＯＩＤ
２．ＱＲコード
３．ｉＯＳ
(71)【出願人】
【識別番号】521478430
【氏名又は名称】クローズド ループ メディスン リミテッド
【氏名又は名称原語表記】ＣＬＯＳＥＤ ＬＯＯＰ ＭＥＤＩＣＩＮＥ ＬＴＤ
【住所又は居所原語表記】Ｂａｂｒａｈａｍ Ｒｅｓｅａｒｃｈ Ｃａｍｐｕｓ，Ｂａｂｒａｈａｍ，Ｃａｍｂｒｉｄｇｅ，ＣＢ２２ ３ＡＴ，Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ
(74)【代理人】
【識別番号】100103894
【弁理士】
【氏名又は名称】家入 健
(72)【発明者】
【氏名】コックス デビッド
(72)【発明者】
【氏名】シドル ジェームス マシュー
(72)【発明者】
【氏名】カマー ジャクブ
【テーマコード（参考）】
5L099
【Ｆターム（参考）】
5L099AA25
(57)【要約】
デジタル治療システムであって、コアパッケージと、治療パッケージと、を備え、コアパッケージが、治療パッケージから分割されたソフトウェアであり、コアパッケージが、治療パッケージから治療構成を受信し、かつ治療構成に基づいて、１つ以上の患者治療療法を構成するように適合されている、デジタル治療システム。
【選択図】図２
【選択図】図２
【特許請求の範囲】
【請求項1】
デジタル療法システムであって、コアパッケージと、
治療パッケージと、を備え、
前記コアパッケージは、前記治療パッケージから分割されたソフトウェアであり、
前記コアパッケージが、
前記治療パッケージから治療構成を受信し、かつ
前記治療構成に基づいて、１つ以上の患者治療療法を構成するように適合されている、デジタル治療システム。
【請求項2】
複数のソフトウェアモジュールを備え、前記コアパッケージが、コアプラットフォームを備え、前記複数のソフトウェアモジュールが、前記コアプラットフォーム上で動作するように構成されている、請求項１に記載のデジタル治療システム。
【請求項3】
前記複数のソフトウェアモジュールの各々が、１つ以上の関連付けられたモジュール性能特性を有するソフトウェアの分離されたパーティションである、請求項２に記載のデジタル治療システム。
【請求項4】
前記１つ以上の関連付けられたモジュール性能特性が、前記モジュールによって提供されるモジュール機能性、
前記デジタル治療システムの前記モジュール及び／又は１つ以上の他のモジュールによって必要とされるモジュール性能制約、
前記モジュールとの間で受け渡しされるデータ又は情報に関するインバウンド情報制約及びアウトバウンド情報制約、並びに
前記１つ以上の他のモジュール及び／又は前記デジタル治療システムが、前記それぞれの他のモジュール又はデジタル治療システムの性能制約との前記モジュールの互換性を判定することを可能にするための記述的特性のうちのいずれかを含む、請求項３に記載のデジタル治療システム。
【請求項5】
前記複数のソフトウェアモジュールが、前記コアパッケージ内の１つ以上のコアモジュール、及び／又は
前記治療パッケージ内の１つ以上の治療モジュールを含む、請求項２～４のいずれか一項に記載のデジタル治療システム。
【請求項6】
前記１つ以上のコアモジュールが、非医療機能を実行するための１つ以上の非医療モジュールを含む、請求項５に記載のデジタル治療システム。
【請求項7】
前記１つ以上のコアモジュールが、前記１つ以上の患者治療療法に関連する機能を実行するための１つ以上の医療モジュールを含む、請求項５又は６に記載のデジタル治療システム。
【請求項8】
前記複数のソフトウェアモジュールの各々が、モジュールインターフェースを前記コアプラットフォームに登録するように構成されており、前記モジュールインターフェースは、前記モジュールが前記デジタル治療システムの他の部分に提供することができるサービス及び／又はデータを含むエクスポートされた器具を示す、請求項２～７のいずれか一項に記載のデジタル治療システム。
【請求項9】
前記コアプラットフォームが、第１のモジュールからの器具要求を、第２のモジュールの前記登録されたモジュールインターフェースによって示される１つ以上のエクスポートされた器具と一致させるように構成されている、請求項８に記載のデジタル治療システム。
【請求項10】
前記第１のモジュールは、前記一致した器具に関する１つ以上の制約を示す関連付けられた契約仕様とともに、前記コアプラットフォームに器具要求を提供するように構成されており、前記コアプラットフォームは、前記契約仕様に基づいて、前記第１のモジュールからの前記器具要求を一致させるように構成されている、請求項９に記載のデジタル治療システム。
【請求項11】
前記コアプラットフォームが、前記第２のモジュールとの通信のために前記第１のモジュールに基準インターフェースを提供するように更に構成されている、請求項９又は１０に記載のデジタル治療システム。
【請求項12】
前記基準インターフェースが、前記第１のモジュールと前記第２のモジュールとの間の直接インターフェースと、
前記第１のモジュールと前記第２のモジュールとの間の中間部を含む間接インターフェースと、を含む、請求項１１に記載のデジタル治療システム。
【請求項13】
前記コアパッケージが、患者データを受信し、かつ前記患者データに基づいて前記１つ以上の患者治療療法を構成するように更に適合されている、請求項１～１２のいずれか一項に記載のデジタル治療システム。
【請求項14】
前記患者データが、生体認証データ、生理学的データ、行動データ、処方データ、医療記録データ、所望の転帰データ、及び患者フィードバックデータのうちの１つ以上を含む、請求項１３に記載のデジタル治療システム。
【請求項15】
前記コアパッケージが、患者入力、関連付けられたデバイスからの読み取り値、及びローカルデバイス又はネットワークデバイス上に記憶された患者記録データのうちの１つ以上から前記患者データを受信するように構成されている、請求項１３又は１４に記載のデジタル治療システム。
【請求項16】
前記コアパッケージが、非患者データを受信し、かつ前記非患者データに基づいて前記１つ以上の患者治療療法を構成するように適合されている、請求項１～１５のいずれか一項に記載のデジタル治療システム。
【請求項17】
前記非患者データが、環境データ、規制データ、及び薬物データのうちの１つ以上を含む、請求項１６に記載のデジタル治療システム。
【請求項18】
前記コアパッケージが、前記治療パッケージから前記治療構成を受信し、かつ前記１つ以上の患者治療を構成するための治療コンフィギュレータを備える、請求項１～１７のいずれか一項に記載のデジタル治療システム。
【請求項19】
前記治療構成が、１つ以上の治療命令を含み、前記１つ以上の治療命令が、１つ以上の治療決定、
前記１つ以上の患者治療療法を構成するために必要な前記コアパッケージの１つ以上のモジュールの表示、
前記コアプラットフォームに登録するための１つ以上の治療モジュールの表示、及び
前記１つ以上の患者治療療法を構成するために治療エンジンによって必要とされる患者データの表示のうちの少なくとも１つを含む、請求項１～１８のいずれか一項に記載のデジタル治療システム。
【請求項20】
前記治療コンフィギュレータが、１つ以上のアルゴリズムを使用して、前記１つ以上の治療決定を処理するように構成された治療エンジンを備える、請求項１９に記載のデジタル治療システム。
【請求項21】
前記１つ以上のアルゴリズムのうちの少なくとも１つが、前記コアパッケージに関連付けられている、請求項２０に記載のデジタル治療システム。
【請求項22】
前記１つ以上のアルゴリズムのうちの少なくとも１つが、前記治療パッケージに関連付けられている、請求項２０又は２１に記載のデジタル治療システム。
【請求項23】
前記治療コンフィギュレータが、前記１つ以上の患者治療療法を構成するときに、１つ以上のセーフガードを適用するように構成された安全モジュールを備える、請求項１～２２のいずれか一項に記載のデジタル治療システム。
【請求項24】
前記安全モジュールが、前記１つ以上の患者治療療法を構成するための１つ以上の固有のセーフガードを含む、請求項２３に記載のデジタル治療システム。
【請求項25】
前記安全モジュールが、薬物データを含む薬物データベースにアクセスし、かつ
前記薬物データに基づいて、１つ以上の固有の薬物セーフガードを判定するように構成されている、請求項２４に記載のデジタル治療システム。
【請求項26】
前記薬物データが、薬物投与量制限、薬物相互作用データ、及び人口統計に依存する薬物投与量データのうちの１つ以上を含む、請求項２５に記載のデジタル治療システム。
【請求項27】
前記治療構成が、前記１つ以上の患者治療療法を構成するための１つ以上の治療特異的セーフガードを含む、請求項２３～２６のいずれか一項に記載のデジタル治療システム。
【請求項28】
前記１つ以上のセーフガードが、対応するソフトウェアモジュールの契約仕様に関連付けられている、請求項２３～２７のいずれか一項に記載のデジタル治療システム。
【請求項29】
前記コアパッケージから分割された１つ以上の更なる治療パッケージソフトウェアを更に備え、各治療パッケージが、それぞれの治療構成を含み、前記コアパッケージが、前記それぞれの治療パッケージから各治療構成を受信し、かつ前記治療構成に基づいて、１つ以上のそれぞれの患者治療療法を構成するように適合されている、請求項１～２８のいずれか一項に記載のデジタル治療システム。
【請求項30】
前糖尿病と、糖尿病と、循環器疾患と、軽度認知障害（ＭＣＩ）、アルツハイマー病及びパーキンソン病などの神経変性疾患と、心房細動と、注意欠陥多動性障害（ＡＤＨＤ）と、潰瘍性大腸炎、エリテマトーデス、クローン病、セリアック病、橋本甲状腺炎、双極性障害などの自己免疫疾患と、運動障害及びアテトーゼなどの脳性麻痺と、慢性移植片対宿主病と、肝炎と、慢性腎臓病と、変形性関節症及び関節リウマチなどの関節炎及び慢性骨関節疾患と、がんと、肥満と、喘息と、副鼻腔炎と、嚢胞性線維症と、結核と、慢性閉塞性気道疾患と、気管支炎と、細気管支炎と、肺線維症と、慢性疼痛症候群を含む疼痛と、うつ病と、摂食障害と、多嚢胞性卵巣症候群と、てんかんと、線維筋痛症と、ＨＩＶ／ＡＩＤＳなどのウイルス性疾患と、ハンチントン病と、低血圧と、高血圧と、アレルギー性鼻炎と、多発性硬化症と、慢性疲労症候群を含む疲労状態と、不眠症と、ナルコレプシーと、骨粗鬆症と、歯周病と、体位性頻脈症候群と、鎌状赤血球貧血及び他のヘモグロビン障害と、睡眠時無呼吸と、甲状腺疾患と、胃食道逆流症を含む逆流症と、嘔吐と、過敏性腸症候群（ＩＢＳ）と、炎症性腸疾患（ＩＢＤ）と、消化性潰瘍と、急性蕁麻疹と、アトピー性皮膚炎と、接触性皮膚炎と、脂漏性皮膚炎と、片頭痛、群発性頭痛、及び緊張型頭痛を含む頭痛と、薬物依存症、特にオピエート依存性、コカイン、アルコール、若しくはニコチン依存症などの依存症、及びそれらの慢性的な使用と、血栓塞栓性疾患と、脱毛と、ホルモン補充療法と、精神病、不安神経症、及びうつ病などの精神障害と、成長ホルモン欠乏症、甲状腺機能低下症を含む内分泌機能障害と、凝固第５因子の欠乏若しくは低レベルの白血球若しくは赤血球を含む血液学的障害と、自閉症スペクトラム障害（ＡＳＤ）、スミス・マゲニス症候群及びＡＤＨＤを含む神経発達遅延（ＮＤＤ）障害と、ＲＥＭ及びＮＲＥＭ睡眠時随伴症及び悪夢障害を含む睡眠時随伴症と、むずむず脚症候群及び周期性四肢運動障害などの睡眠運動障害、概日リズム障害（交代勤務及び／若しくは時差ぼけによって引き起こされる障害を含む）と、舞踏病及びチック症とのうちのいずれかを含む、１つ以上のそれぞれの疾患又は状態を治療するための１つ以上の治療パッケージを備える、請求項１～２９のいずれか一項に記載のデジタル治療システム。
【請求項31】
前記１つ以上の患者治療療法が、１つ以上のデジタル治療療法を含む、請求項１～３０のいずれか一項に記載のデジタル治療システム。
【請求項32】
前記１つ以上のデジタル治療療法が、投与レジメンの表示を含む薬理学的療法、及び
非薬理学的療法のうちの少なくとも１つを含む、請求項３１に記載のデジタル治療システム。
【請求項33】
デジタル治療システムにおいてデジタル療法を構成するコンピュータ実施方法であって、前記デジタル治療システムのコアパッケージにおいて、前記コアパッケージから分割された治療パッケージソフトウェアから治療構成を受信することと、
前記治療構成に基づいて、１つ以上のデジタル療法を構成することと、を含む、コンピュータ実施方法。
【請求項34】
前記１つ以上のデジタル療法を構成することが、前記デジタル療法で使用するために、１つ以上のソフトウェアモジュールを、前記コアパッケージのコアプラットフォームに登録し、かつ前記コアプラットフォームを用いて構成することを含み、前記複数のソフトウェアモジュールの各々が、関連付けられたモジュール性能特性を有するソフトウェアの分離されたパーティションである、請求項３３に記載の方法。
【請求項35】
１つ以上のソフトウェアモジュールを前記コアプラットフォームに登録することが、前記１つ以上のソフトウェアモジュールの前記各々のモジュールインターフェースを前記コアプラットフォームに登録することを含み、前記モジュールインターフェースが、前記モジュールが、前記デジタル治療システムの他の部分に提供することができるサービス及び／又はデータを含むエクスポートされた器具を示す、請求項３４に記載の方法。
【請求項36】
１つ以上のソフトウェアモジュールを前記コアプラットフォームに登録することが、第１のモジュールからの器具要求を、第２のモジュールの前記登録されたモジュールインターフェースによって示される１つ以上のエクスポートされた器具と一致させることを更に含む、請求項３５に記載の方法。
【請求項37】
１つ以上のソフトウェアモジュールを前記コアプラットフォームに登録することが、前記第１のモジュールの契約仕様に基づいて、前記第１のモジュールからの前記器具要求を一致させることを更に含む、請求項３６に記載の方法。
【請求項38】
前記１つ以上のソフトウェアモジュールが、前記コアパッケージ内の１つ以上のコアモジュール、及び／又は
前記治療パッケージ内の１つ以上の治療モジュールを含む、請求項３３～３７のいずれか一項に記載の方法。
【請求項39】
前記１つ以上のデジタル療法を構成することが、前記１つ以上のデジタル療法で使用するためのデータを取得することと、
前記データに基づいて、１つ以上の治療決定を処理することと、を更に含む、請求項３２～３８のいずれか一項に記載の方法。
【請求項40】
デジタル治療システムであって、患者療法に関する治療パッケージと、
コアプラットフォームを備えるコアパッケージであって、前記患者療法を構成するように適合されている、コアパッケージと、
複数のソフトウェアモジュールであって、
前記コアパッケージ内の１つ以上のコアモジュール、及び／又は
前記治療パッケージ内の１つ以上の治療モジュールを含む、複数のソフトウェアモジュールと、を備え、
前記コアプラットフォームは、前記コアパッケージが、前記治療パッケージから分割されたソフトウェアであるように、前記複数のソフトウェアモジュールを統合するように構成されている、デジタル治療システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、デジタル療法、特にモジュラデジタル治療システム及びその動作を提供する際に使用するのに好適な方法及びシステムに関する。
【背景技術】
【0002】
患者は、デジタル治療薬（ＤＴｘ）を介して１つ以上の疾患又は状態の治療を受け得る。ＤＴｘは、それ自体がヒトの医療専門家の関与なしに、患者に治療上の利益を伝えることができるソフトウェアを含む。したがって、ＤＴｘは、効果的に「薬としてのソフトウェア」の使用である。治療薬として、ＤＴｘは、医薬品規制からの規制承認を必要とすることができる。ソフトウェアとして、ＤＴｘはＦＤＡ（２００ ＣＦＲ ８０）及びＥＵ＆ＵＫ（Ｒｅｇｕｌａｔｉｏｎ（ＥＵ）２０１７／７４５）で定義されている医療機器の定義にも該当する。
【0003】
規制側は、主に「医療デバイスとしてのソフトウェア」（ＳａＭＤ）の３つの側面に関与している。
・用途
・有効性
・安全性
・用途
・有効性
・安全性
【0004】
用途は、ＳａＭＤの製造元によって定義されることが多い。有効性と安全性は、通常、高価で実施に時間がかかる臨床試験を通して証明されている。
【0005】
最新のソフトウェア４２６
は、できるだけ早い段階でソフトウェアをリリースし、次いで現実世界でのエンドユーザによる使用状況とフィードバックを考慮しながら、漸進的な改善を迅速に繰り返す開発パラダイムである。
は、できるだけ早い段階でソフトウェアをリリースし、次いで現実世界でのエンドユーザによる使用状況とフィードバックを考慮しながら、漸進的な改善を迅速に繰り返す開発パラダイムである。
【0006】
これは、規制承認を得ることに関連付けられた負担（コストと時間）を考慮すると、製造元は臨床試験に入るとＳａＭＤを反復することを望まないため、ＳａＭＤとは相反する。しかしながら、これは、現実世界で使用されているＳａＭＤを観察し、それに応じてそれを改善する能力を排除し得る。
【0007】
規制上の負担はまた、ＳａＭＤパッケージの修正を避けるために、ＳａＭＤが所与の治療又は療法のための最新の知見、研究又はガイドラインを取り入れることを妨げる可能性がある。この問題は、それぞれの疾患又は状態に対する連携療法（複数の療法）を含むＤＴｘ又はＳａＭＤについて悪化し得る。例えば、ＤＴｘは、認知行動療法（ＣＢＴ）又は運動レジメンなどの非薬理学的療法と組み合わせた薬理学的療法のための投与レジメンを含み得る。この問題は、複数の疾患又は状態を治療するように構成されたＳａＭＤベースのデジタル治療システムの場合、更に悪化し得る。
【0008】
上記を考慮して、ＳａＭＤの使用に関する新たな進展、並びに１つ以上の特定の療法に関する知識及びガイダンスの変化に基づいて、過度に負担をかけることなく規制要件に準拠した方法で、更新及び改善できるデジタル療法を提供するためのシステム及び方法が必要である。
【発明の概要】
【0009】
本開示の第１の態様によれば、デジタル療法システムであって、
コアパッケージと、
治療パッケージと、
治療パッケージからコアパッケージをソフトウェア分割するように配置されたインターフェースと、を備え、
コアパッケージが、
治療パッケージから治療構成を受信し、かつ
治療構成に基づいて、１つ以上の患者治療療法を構成するように適合されている、デジタル治療システムが提供される。
コアパッケージと、
治療パッケージと、
治療パッケージからコアパッケージをソフトウェア分割するように配置されたインターフェースと、を備え、
コアパッケージが、
治療パッケージから治療構成を受信し、かつ
治療構成に基づいて、１つ以上の患者治療療法を構成するように適合されている、デジタル治療システムが提供される。
【0010】
治療パッケージからコアパッケージをソフトウェアで分割することにより、２つの部分を規制順守のために独立してアセスメントすることができる。その結果、２つの部分はまた、他方への影響が規則に従って許容範囲内であれば、独立して更新されることもある。デジタル治療システムを２つ（又はそれ以上）の部分に分離することにより、それらの規制上の負担及び／又は予想される反復の頻度に依存するソフトウェアコンポーネント又はモジュールの分離が許容される。
【0011】
システムは、コアパッケージ内の汎用コンポーネント及び治療パッケージ内の治療特異的コンポーネントを提供するように分割することができる。このようにして、コアパッケージは、治療ごとにコアパッケージの再承認を必要とせずに、複数の治療パッケージと一緒に又は独立して使用することができる。
【0012】
開示されたデジタル治療システムは、以下の利点のうちの１つ以上を提供し得る。
ユーザの場合：
・システムは、異なる治療をサポートしながら、一貫したユーザインターフェースエクスペリエンスを提供することができる
・システムは、いくつかの異なる治療を同時に実行し得る
・システムは、複数の治療（例えば、２つの治療は両方とも血圧読み取り値を必要とし得る）から生じるアクションの要求を管理し、合理化することができる。このシステムは、データ要件を合理化し、患者への単一の通知を発行し、その測定結果を複数の治療に中継することができる。
・システムは、１つの治療から次の治療へのユーザパーソナライズの連続性を提供し得る
システムプロバイダの場合：
・機能性の分離により、新規／更新された治療又は機能性の規制上の負担を軽減することができる
・高規制精査の対象とならないコンポーネントの容易な／より頻繁な反復を可能にする
ユーザの場合：
・システムは、異なる治療をサポートしながら、一貫したユーザインターフェースエクスペリエンスを提供することができる
・システムは、いくつかの異なる治療を同時に実行し得る
・システムは、複数の治療（例えば、２つの治療は両方とも血圧読み取り値を必要とし得る）から生じるアクションの要求を管理し、合理化することができる。このシステムは、データ要件を合理化し、患者への単一の通知を発行し、その測定結果を複数の治療に中継することができる。
・システムは、１つの治療から次の治療へのユーザパーソナライズの連続性を提供し得る
システムプロバイダの場合：
・機能性の分離により、新規／更新された治療又は機能性の規制上の負担を軽減することができる
・高規制精査の対象とならないコンポーネントの容易な／より頻繁な反復を可能にする
【0013】
デジタル治療システムは、ＳａＭＤであり得、１つ以上のデジタル療法を提供し得る。
【0014】
開示は、様々な改変及び代替形態に従うことが可能であるが、それらの詳細は、例として図面に示されており、詳細に説明される。しかしながら、記載された特定の実施形態を超える他の実施形態も同様に可能であることを理解されたい。添付の特許請求の範囲の趣旨及び範囲内に入る全ての改変、等価物、及び代替実施形態も同様にカバーされる。
【0015】
上記考察は、現在又は将来の特許請求の範囲セットの範囲内のあらゆる例示的な実施形態又はあらゆる実装態様を表すことを意図したものではない。以下の図及び「発明を実施するための形態」はまた、様々な例示的な実施形態を例示する。様々な例示的な実施形態は、添付の図面に関連して、以下の詳細な説明を考慮して、より完全に理解され得る。
【0016】
本開示の第２の態様によれば、デジタル治療システムであって、
患者療法に関する治療パッケージと、
コアプラットフォームを備えるコアパッケージであって、患者療法を構成するように適合されている、コアパッケージと、
複数のソフトウェアモジュールであって、
コアパッケージ内の１つ以上のコアモジュール、及び／又は
治療パッケージ内の１つ以上の治療モジュールを含む、複数のソフトウェアモジュールと、を備え、
コアプラットフォームは、コアパッケージが、治療パッケージから分割されたソフトウェアであるように、複数のソフトウェアモジュールを統合するように構成されている、デジタル治療システムが提供される。
患者療法に関する治療パッケージと、
コアプラットフォームを備えるコアパッケージであって、患者療法を構成するように適合されている、コアパッケージと、
複数のソフトウェアモジュールであって、
コアパッケージ内の１つ以上のコアモジュール、及び／又は
治療パッケージ内の１つ以上の治療モジュールを含む、複数のソフトウェアモジュールと、を備え、
コアプラットフォームは、コアパッケージが、治療パッケージから分割されたソフトウェアであるように、複数のソフトウェアモジュールを統合するように構成されている、デジタル治療システムが提供される。
【0017】
コアプラットフォームは、図４に関連して以下に説明されるように、器具の登録及びマッチングプロセスを実施することによって、複数のソフトウェアモジュールを（安全に）統合し得る。コアプラットフォームは、ソフトウェアパーティションを提供するために、複数のソフトウェアモジュール間の通信を制御し得る。
【0018】
１つ以上の実施例では、コンピュータ上で実行されるときに、コンピュータに、本明細書に開示される回路、コントローラ、コンバータ、又はデバイスを含む、任意の装置を構成させる、又は本明細書に開示される任意の方法を実行させる、コンピュータプログラムが提供され得る。コンピュータプログラムは、ソフトウェア実装であり得、コンピュータは、非限定的な例として、デジタル信号プロセッサ、マイクロコントローラ、及び読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、又は電子的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）における実装を含む任意の適切なハードウェアとみなされ得る。ソフトウェアは、アセンブリプログラムであり得る。
【0019】
コンピュータプログラムは、ディスク又はメモリデバイスなどの物理的なコンピュータ可読媒体であり得るコンピュータ可読媒体上に提供され得、又は一時的な信号として具現化され得る。そのような一時的な信号は、インターネットダウンロードを含むネットワークダウンロードであり得る。コンピューティングシステムによって実行されたときに、コンピューティングシステムに本明細書に開示された任意の方法を実行させる、コンピュータ実行可能命令を記憶する１つ以上の非一時的コンピュータ可読記憶媒体が提供され得る。
【図面の簡単な説明】
【0020】
添付の図面を参照して、１つ以上の実施形態を例としてのみ説明する。
【図1】本発明の実施形態による、デジタル治療システムを例解する。
【図2】本発明の実施形態による、別のデジタル治療システムを例解する。
【図3】本開示の実施形態による、更なるデジタル治療システムを例解する。
【図4】本開示の実施形態による、デジタル治療システムで使用するための認定及び契約仕様プロセスを例解する。
【図5】本開示の実施形態による、デジタル治療システムとのユーザ相互作用のためのエンドツーエンドプロセスを例解する。
【発明を実施するための形態】
【0021】
第１の態様によるデジタル治療システムは、患者治療療法を構成するために、１つ以上の治療パッケージから分割されたコアパッケージソフトウェアを定義する。治療パッケージからコアパッケージをソフトウェアで分割することにより、２つの部分を規制順守のために独立してアセスメントすることができる。デジタル治療システムを２つ以上の部分に分離することにより、それらの規制上の負担及び／又は予想される反復の頻度に依存するソフトウェアコンポーネント又はモジュールの分離が許容される。
【0022】
デジタル治療システムを分割するソフトウェアは、予想されるレベルの規制の精査及び／又は更新の頻度に応じて、コアパッケージ又は治療パッケージ内のコンポーネントを位置付けることを含むことができる。例えば、機械学習アルゴリズムは、厳密な規制精査の対象となる可能性があり、（事前に合意されたモデルの改善の範囲外で）定期的に更新された場合、高いコストと承認の遅延を招く可能性がある。
【0023】
コアパッケージは、複数の治療パッケージで使用することができる。その結果、コアパッケージは幅広い治療に共通の能力を提供することができ、新しい治療が開発されたときにコアパッケージを再評価することが有利に回避される。
【0024】
１実施例では、治療パッケージは、高規制負担コンポーネントを包含し得る。本明細書に記載されるように、高規制負担コンポーネントは、特に高リスクの医療デバイスソフトウェアを包含し、規制精査を必要とするものであり得る。例えば、高規制負担コンポーネントは、１つ以上の臨床試験を必要とし得、かつ／又は１つ以上の更なる臨床試験の対象となることなく更新されない場合がある。治療パッケージを安定させることで、高負担のコストをできるだけ少なくすることができ、理想的には１回のみである。次いで、コアパッケージは、例えば非医療コンポーネントなど、高規制精査を受けないコンポーネントを包含することができる。有利なことに、いくつかの非医療コンポーネントは、ＤＴｘの 用途、期待される有効性、又は証明された安全性を許容範囲内に維持しながら、組み合わせ（及び最終的には患者）の利益のために迅速に反復することができる。
【0025】
別の実施例では、コアパッケージは、高規制負担コンポーネントを包含し、一度又は数回のみ規制承認を受ける場合がある。その後、コアパッケージは、更なる臨床試験を受けることなく、１つ以上の新しい治療パッケージ及び改善された治療パッケージが開発されたときに、有利にインターフェースすることができる。新しい治療パッケージは、独自の独立した規制アセスメントの対象となり得る。いくつかの実施例では、治療パッケージはまた、高規制負担コンポーネントを含み得る。しかしながら、治療パッケージは、コアパッケージ又は他の承認された治療パッケージの完全な再アセスメントを必要とすることなく、独立してアセスメントすることができる。
【0026】
更なる実施例では、コアパッケージ及び／又は治療パッケージ自体は、規制精査及び更新頻度の要件が異なるモジュールに更に細分化され得る。
【0027】
図１は、本開示の実施形態による、デジタル治療システム１００の概略図を示す。
【0028】
デジタル治療システム１００は、コアパッケージ１０２と、治療パッケージ１０４と総称される、複数の個別の治療パッケージ１０４－１、１０４－２、１０４－３とを備える。コアパッケージ１０２は、複数の治療パッケージ１０４から分割された（又は分離された）ソフトウェアである。言い換えれば、コアパッケージ１０２及び治療パッケージ１０４は、別個の、識別可能なパッケージ、又はコードのブロックであり、デジタル治療システム１００内に独立して包含されている。この実施例では、コアパッケージ１０２は、治療コンフィギュレータ１０６を備える。各治療パッケージ１０４－１、１０４－２、１０４－３は、それぞれの治療構成１０８－１、１０８－２、１０８－３を備える。治療コンフィギュレータ１０６は、それぞれの治療パッケージ１０４から治療構成１０８を受信し、治療構成１０８に基づいて１つ以上の患者療法１１１を構成することができる。
【0029】
デジタル治療システム１００は、コアパッケージ１０２及び１つ以上の治療パッケージ１０４という２つの部分に細分化される。２つの部分は、インターフェース１１７を介して通信することができる。コアパッケージ１０２は、１つ以上の治療パッケージ１０４に共通の機能のセットを提供することができる。このようにして、コアパッケージ１０２は、異なるデジタル治療法がそれらの用途を満たすことを可能にすることができる。デジタル治療システム１００は、医療デバイスとみなされ得、安全性に重要な治療を送達し得る。
【0030】
治療システム１００をコアパッケージ１０２及び１つ以上の処理パッケージ１０４という２つの部分に分離することによって、２つの部分は、独立した規制アセスメントを受けることができる。２つの部分はまた、独立して更新され得る。
【0031】
コアパッケージ１０２と別個の治療パッケージ１０４の概念は、コアパッケージ１０２が携帯型ゲームコンソールを表し、治療パッケージ１０４が個別のゲームカートリッジを表す携帯型ゲーム機に喩えることができる。
【0032】
治療パッケージ１０４は、特定の治療をユーザが利用可能にすることができるように、治療ソフトウェア、アプリケーション構成、及び関連資産をコアパッケージ１０２及びシステム１００で利用できるようにするために使用される送達メカニズムとしてみなされ得る。
【0033】
治療パッケージ１０４は、
・治療に必要な特定の治療モジュールの定義
・治療を送達するために必要な特定の治療モジュールの実行可能コード
・治療の一部として行われる臨床ワークフロー及び決定を定義する治療記述子
・コアパッケージ１０２又はシステム１００の他の部分のモジュールを構成するために使用されるアプリケーション構成を含み得る。
・治療に必要な特定の治療モジュールの定義
・治療を送達するために必要な特定の治療モジュールの実行可能コード
・治療の一部として行われる臨床ワークフロー及び決定を定義する治療記述子
・コアパッケージ１０２又はシステム１００の他の部分のモジュールを構成するために使用されるアプリケーション構成を含み得る。
【0034】
治療パッケージ１０４のコンポーネントに関する更なる詳細が、以下に提供される。
【0035】
コアパッケージ１０２は、治療パッケージ１０４に共有能力を提供することができる。これらの共有能力には、データ管理、処方チェック、及びサードパーティのデバイス統合を含めることができる。能力は、以下でより詳細に説明される、治療コンフィギュレータ１０６による治療コンフィギュレータ１０８の実行など、治療送達により密接に関与する能力を更に含み得る。
【0036】
コアパッケージは、（治療構成によって示されるように）治療に関連付けられたいくつかの動作を実行することによって、１つ以上のデジタル治療療法１１１を構成することができる。例えば、コアパッケージは、データを取得し、治療決定を処理し、アルゴリズムを実行し、患者又は医療提供者に通知し、ユーザ認証を実行し、１つ以上のデジタル治療療法１１１を構成する一部として順守をモニタリングし得る。
【0037】
いくつかの実施例では、コアパッケージ１０２は、コアプラットフォーム上で動作する複数のコアモジュールを有するコアプラットフォームを備え得る。コアプラットフォームは、コアモジュールによって機能性を提供することができるベースシステム層を提供するプラットフォームアプリケーション又はアプリケーションフレームワークを備え得る。各コアモジュールは、１つ以上の性能特性を有するソフトウェアの別個のパーティションであり得る。これらの性能特性は、モジュールによって提供されるモジュール機能性、正しくかつ安全に動作するためにデジタル治療システム（又は他のモジュール）のモジュールによって必要とされるモジュール性能制約、モジュールとの間で受け渡しされるデータ又は情報に対するインバウンド情報制約及びアウトバウンド情報制約、並びに１つ以上の他のモジュール及び／又はデジタル治療システムがモジュールとそれぞれの他のモジュール又はデジタル治療システム全体の性能制約との互換性を判定することを可能にするための記述的特性のうちのいずれかを含み得る。これらの性能特性は、図３及び図４に関連して以下で更に考察される。
【0038】
コアモジュールは、２つ以上の治療パッケージに機能性を提供する共通モジュールであり得る。
【0039】
コアモジュールは、デジタル治療を送達するための医療デバイス機能を提供する医療コアモジュールを備え得る。例えば、通知モジュールは、薬物の服用又は療法タスクの実行などのアクションを実行するようにユーザに通知又は命令することが、治療の一部を含み得るため、医療コアモジュールとみなされ得る。
【0040】
コアモジュールは、非医療デバイス機能を提供する非医療コアモジュールを備え得る。例えば、ユーザアカウントを認証することは、実際の療法の送達に関連しないため、認証モジュールは、非医療コアモジュールとみなされ得る。
【0041】
コアモジュールは、対応する治療パッケージからのアクセスを介して多くの治療に組み込むことができるため、共通のモジュールとみなされ得る。いくつかの実施例では、コアモジュールは、「棚から取り出される」ことができ、医療デバイスシステムに含まれることができるＩＥＣ６２３０４準拠のソフトウェアユニットを備え得る。
【0042】
各治療パッケージ１０４はまた、治療特異的治療モジュールの形態での１つ以上のモジュールを備え得る。コアモジュールと同様に、治療モジュールはまた、１つ以上の性能特性を有するソフトウェアの分離されたパーティションを備え得る。コアパッケージ１０２は、コアプラットフォーム上で治療モジュールを実行し得る。
【0043】
デジタル治療システムをモジュールの形態で実装することにより、システム部分の独立した更新及び／又は規制承認が可能になる。すなわち、プラットフォーム、各コアモジュール、及び各治療パッケージ／治療モジュールは、独立して更新及び／又は承認され得る。このようにして、デジタル治療システム１００は、規制上の負担に応じて分割することができる。表１は、各パーティションが医療用であるか非医療用であるか、更新の頻度であるか及びインターフェースの安定性であるかを示す、システム１００の例示的な分割を例解する。
表１
【表1】
【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】
第６のステップ５９４では、システムは、ユーザに対して治療をパーソナライズし得る。システムは、受信データ及び／又はユーザとアプリケーションとの相互作用を通じて生成されたデータに基づいて、初期のパーソナライズ及び／又は継続中の最適化を実行し得る。上に概説されたように、治療のパーソナライズは、治療記述子における命令の結果として、モジュールの行動を修正することができるアプリケーション構成における指示を通じて、かつ／又は独立して開始することができる治療モジュール特異的プロセスを通じて、実行され得る。患者データは、パーソナライズに影響を与え得る。
【図1】
【図2】
【図3】
【図4】
【図5】
【国際調査報告】