Calm for Cancer プロトタイプモバイルアプリの開発

この STTR は 3 つの目的で構成され、それぞれが連続した順序で実施され、最終的な結果として、有効性テスト (フェーズ 2) と消費者へのダイレクト マーケティング (フェーズ 3) の準備が整った癌に特化した瞑想アプリのプロトタイプが作成されます。

目的 1: IDEAS フレームワークを使用して、研究者は、a) 現在の Calm プラットフォームに関する情報に基づいた諮問委員会 (N=20) からの視点と、b) がんに特化した瞑想アプリのプロトタイプを設計するための社会的認知理論からの戦略を統合します。 IDEAS ステージ INTEGRATE の意味は、より深いニーズ、価値観、動機を明らかにし、主要な利害関係者 (つまり、患者と医療提供者) を関与させ、行動理論を使用して、より関連性が高く、対象集団に受け入れられるソリューションを鼓舞することです。 手順: 諮問委員会は、情報に通じたがん患者、生存者 (n=10; それぞれ 5 人) および医療提供者 (n=10; 医師、腫瘍学看護師、がんケア コーディネーター、がんセンターの統合プログラムの責任者など) で構成されます。営利パートナー;サポートレターを参照してください)。 諮問委員会のメンバーは、UT Health San Antonio の Mays Cancer Center、MD Anderson、アリゾナ州スコッツデールとニューヨーク州ロチェスターの Mayo Clinic、アリゾナ大学、Wake Forest, Leukemia and Lymphoma Society、および American Cancer Society とのパートナーシップから選出されています。 . 患者/サバイバーと医療提供者の両方が諮問委員会に含まれています。医療提供者は、患者が症状を自己管理するためのモバイル ツールを推奨する上で重要な役割を果たしており、医療提供者は多くの場合、アプリの設計に関連する関与していない利害関係者であり、アプリをスケーラブルな介入に統合するには、患者/サバイバーとプロバイダーの両方。 選択基準は、がん患者とサバイバーの経験を優先しますが、さまざまな立場（医療、補助、および直接）で奉仕する人々の好み、消極的な点、明示された障壁、明示されていない障壁、および行動の選択を見たり聞いたりするメンバーも含まれます対面瞑想オプションの提供）。

諮問委員会は次のことを求められます: (1) Calm アプリを 7 日間、1 日 10 分以上使用してそのコンテンツと機能を探索する (2) (a) 使用した時間と時間を非公式に記録するCalm、(b) アプリのオプションに対する反応と、特定の選択をする動機となったもの、(c) ガイド付き瞑想中の経験、(d) プロトタイプに含めるがん患者の人生経験についてのアイデア、(e) への反応SCT からの戦略に関連するプロンプト (たとえば、アプリのコンテンツまたは機能は、他のがん患者またはプロバイダーからの社会的モデリングの感覚をどのようにサポートするか? 目標設定と報酬を適切に組み込むにはどうすればよいでしょうか?)、(f) がん患者または生存者でない場合は、治療または奉仕する人々の視点を熟考し、(3) 仮想フォーカス グループに参加して、情報に基づいた有意義な情報を提供します。プロトタイプの特定の入力。 フォーカス グループは、開発中の製品やアイデアに対する反応を評価することを目的としており、業界やマーケティングにおいて長い歴史があります。 コロナウイルス 2019 を考慮して、仮想フォーカス グループは、インターネット ベースの定性調査のベスト プラクティス ガイドラインに基づいて実施されます。 Calm の 1 人の開発者がフォーカス グループの意見を聞き、実用的なガイダンスを提供し、プロトタイプ デザイン (目的 2) のターゲット ニーズを満たします。 研究者は、Bowen の実現可能性フレームワークを使用して、設計の特定のドメイン (受容性、需要、実用性、適応、および統合) を調査します (例は、制限のない経験的および癌に関連する内容の調査です)。 調査員は、このインフォームド ユーザー段階により、諮問委員会がユーザーではなくアドバイザーとなる次の設計および評価段階を指示する能力が強化されると考えています。 これらの情報に基づいたユーザー フォーカス グループは、コンテンツと機能のリストを開発し、言及の数と重要性を強調して優先順位を付けることにより、目的 2 のデザイン段階を指揮します。 目標 1 のマイルストーン: プロトタイプの設計と継続的なエンゲージメントの促進に使用する 10 ～ 12 の主要なコンテンツと機能の問題のリストに優先順位を付けます。

目的 2: IDEAS フレームワークを使用して、研究者はがんに特化した瞑想アプリのプロトタイプを設計します。 IDEAS フレームワークは、プロトタイピングが客観的により強力な最終製品につながることを示唆しています。 このプロセスには、最も頻繁な要求の理解、目標と非目標の決定、およびユーザーが特定の機能と対話する方法を書き出すことが含まれます。 調査員は目的 1 の調査結果を使用して、サーバー側のアプリケーション プログラミング インターフェイス (API) と iOS 用アプリを迅速に開発します。 実現可能性フォーカス グループからのテーマとフィードバック (例: 受け入れ、需要、実用性などを育む方法) を使用して、現在の Calm デザイン、API、およびアプリを拡張し、アプリのコンテンツ、レイアウト、および機能を拡張します。特定のがん関連の長期的なニーズに対応します。

設計: 最初のステップは、ユーザー エクスペリエンス、ユーザー インターフェイス フロー、モバイル アプリの画面をモックアップすることです。これは、フォーカス グループの価値観とユーザー要件に適合します。 調査員は、潜在的なフローと解決策のワイヤーフレームを模倣して作成します。 設計はフィードバックに基づいて繰り返されます。 調査担当者が明確なワイヤーフレームと仕様を取得したら、忠実度の高いビルド モックアップを作成します。

API とモバイル アプリケーションの開発: 調査員は、Calm の API を拡張してインタラクティブなプロトタイプを構築します。 API は、モバイル アプリケーション (フロントエンド) とサーバー上で実行されているソフトウェア (バックエンド) の間の通信を容易にする Web インターフェイスです。 これにより、サーバー上でリモートで実行されている他のソフトウェア サブルーチンを利用して、アプリの機能を拡張できます。 API は REST ベースで、Node.js と呼ばれる Web フレームワークと Postgres データベースを使用して JavaScript で開発されます。 現在の Calm システムは、Kubernetes を使用してデプロイされ、Terraform でプロビジョニングされ、Amazon Web Services でホストされています。 サーバーとクライアント間のすべての API 通信は、安全な通信のために HTTPS (Hypertext Transfer Protocol Secure) を介して行われます。 サーバーは、何を、どこに、いつ、どのように情報を表示するかのロジックを処理します。 これにより、フロントエンド チームはより迅速に動き、複雑なビジネス ロジックを複製するのではなく、ユーザー エクスペリエンス、ユーザー インターフェイス、美しいアニメーションに集中できるようになります。 調査担当者は、ユーザー アプリを更新することなく、サーバー上でのコンテンツの表示方法を自動的に変更するために非常に迅速に行動できます。 API は、認証、ID 管理、コンテンツ、セッション履歴、サブスクリプション、AB テストの登録、アセット、調査と投票、オンボーディング フロー、およびシーンを処理します。 調査員は、仮想プライベート クラウド内にデプロイされ、一般にはアクセスできない管理エンドポイントも持っています。 これらのルートは、シーンとプログラムのアップロード、ユーザー管理、管理者のアクティビティ ログとメモ、およびデバッグをサポートする内部ツールを強化します。 したがって、既存のCalmアプリのすべての側面、瞑想のトラックとコンテンツから特定のビジュアルと選択パス、さらにはアプリの内部構造の仕組みまで、Aim 1の推奨事項に適応させることができます. API の変更を指定した後、調査担当者は API コードとフロントエンド アプリを変更して、API と対話します。 これにより、Aim 3 で使用されるがん患者と生存者を特に対象とするプロトタイプ アプリが作成されます。 すべてのデータは暗号化され、患者はパスワードを使用してアプリにアクセスします。 セキュリティとコンプライアンスの基準は、HIPAA のポリシーと手順を含め、医療機関のビジネス アソシエートとしての要件を満たします。

目的 3: 研究者は IDEAS フレームワークを使用して、がん患者/サバイバーのサンプル (N=30) を使用して、がんに特化した瞑想アプリのプロトタイプの実現可能性を評価 (ベータ テスト) します。 治験責任医師は、さまざまながんの種類と病期、人種/民族、地方/都市の地理的環境、および性別をもつがん患者/生存者をソーシャル メディアを通じて募集します。 研究者は、がん患者/サバイバーから、がんに特化した Calm アプリの開発を支援する 100 通の支援の手紙を受け取りました。 調査によると、実現可能性を確立し、技術的な問題を検出するには、5 ～ 10 人の参加者で十分であることが示唆されています。 サンプルサイズは有効性を確立するためのものではなく、実現可能性の複数の要素です。 研究者は、さまざまながん関連の経験を確実にするために、より多くの数を含めました. ベータ テストの参加者は、プロトタイプを 4 週間 (無料アクセス) 1 日 10 分以上使用するよう求められますが、新しい有料メンバーが既存のプロトタイプを使用する方法を模倣して、好きなだけ使用することが推奨されます落ち着くアプリ。 参加 (完了した瞑想、時刻、時間の長さ、使用されたコンポーネント) は、4 週間にわたって追跡されます (Calm によって提供されます)。 4 週間という期間は有効性を確立するためのものではありませんが、実現可能性をテストするための適切な時期です。 受容性、需要、および実用性を判断するために、参加者は、REDCapを使用した介入直後の最終的な全体的な研究満足度アンケートに加えて、毎週の満足度アンケートに回答するよう求められます。 4 週間のベータ テストの後、満足度アンケートに加えて、研究者は、Bowen の実現可能性モデルを使用して、受容性、需要、実用性、適応、および可能性を最適化するための統合を決定するために、参加者に半構造化インタビューに自発的に参加するよう依頼します。摂取、関与、および推奨レベルでの継続使用 (つまり、少なくとも 10 分/日)。 インタビューのテーマと調査結果は諮問委員会と共有され、調査結果を有効性テスト (フェーズ 2) のアプリ関連の推奨事項 (必要に応じてさらに修正) に変換するために使用されます。 このアプローチは、モバイルアプリの設計および開発に関する他の研究で使用されている方法と似ています。 COVID-19 のため、調査官は、インターネットベースの定性調査のベスト プラクティス ガイドラインに基づいて、仮想的にインタビューを実施します。