开发 Calm for Cancer 原型移动应用程序

该 STTR 包括三个目标，每个目标都按顺序进行，最终结果是针对癌症的冥想应用程序原型，可用于功效测试（第 2 阶段）和直接向消费​​者营销（第 3 阶段）。

目标 1：使用 IDEAS 框架，研究人员将整合 a) 知情咨询委员会 (N=20) 关于当前 Calm 平台的观点和 b) 社会认知理论的策略，以设计针对癌症的冥想应用程序原型。 IDEAS 阶段 INTEGRATE 的意义是揭示更深层次的需求、价值观和动机，让关键利益相关者（即患者和提供者）参与进来，并使用行为理论来激发目标人群更相关和更可接受的解决方案。 程序：咨询委员会将由知情的癌症患者、幸存者（n=10；每人 5 人）和医疗保健提供者（n=10；医生、肿瘤科护士、癌症护理协调员、癌症中心综合项目主任，以及非-营利性合作伙伴；见支持信）。 咨询委员会成员来自与 UT Health San Antonio 的 Mays 癌症中心、MD Anderson、亚利桑那州斯科茨代尔和纽约州罗切斯特的梅奥诊所、​​亚利桑那大学、维克森林、白血病和淋巴瘤协会以及美国癌症协会的合作伙伴关系. 患者/幸存者和提供者都包括在咨询委员会中，因为提供者在向患者推荐移动工具以自我管理他们的症状方面发挥着关键作用，提供者通常是与应用程序设计相关的利益相关者，并且将应用程序集成到可扩展的干预措施中需要支持患者/幸存者和提供者。 选择标准优先考虑癌症患者和幸存者的经历，但也包括看到和听到他们以各种能力（医疗、辅助和直接提供面对面的冥想选项）。

咨询委员会将被要求：(1) 每天至少使用 Calm 应用程序 10 分钟，持续 7 天，以探索其内容和功能，(2) 记录 (a) 一天中的时间和使用时间冷静，(b) 对应用程序选项的反应以及是什么促使他们做出某些选择，(c) 他们在引导冥想期间的经历，以及 (d) 关于癌症患者生活经历的想法以包含在原型中，(e) 对以下内容的反应与来自 SCT 的策略相关的提示（例如，应用程序的内容或功能可能以何种方式支持来自其他癌症患者或提供者的社交建模感？ 如何适当地结合目标设定和奖励？）和（f）如果不是癌症患者或幸存者，反思他们治疗或服务的人的观点，以及（3）参与虚拟焦点小组以提供知情，有意义的和原型的特定输入。 当目标是评估对正在开发的产品或想法的反应时，焦点小组在工业和营销领域有着悠久的历史。 考虑到 2019 年冠状病毒，虚拟焦点小组将根据基于互联网的定性研究的最佳实践指南进行。 Calm 的一名开发人员将听取焦点小组的意见，以获得实用指导并满足原型设计中的目标需求（目标 2）。 研究人员将使用 Bowen 的可行性框架来探索特定的设计领域（可接受性、需求、实用性、适应性和整合性）（例如开放式体验和癌症参考内容探索）。 调查人员认为，这个知情用户阶段将加强咨询委员会指导以下设计和评估阶段的能力，他们将成为顾问而不是用户。 这些知情用户焦点小组将指导目标 2 的设计阶段，方法是制定内容和功能列表，并按提及次数和强调的重要性进行优先排序。 目标 1 的里程碑：优先列出 10-12 个关键内容和功能问题，用于设计原型和促进持续参与。

目标 2：使用 IDEAS 框架，研究人员将设计一个针对癌症的冥想应用程序原型。 IDEAS 框架表明原型设计会导致客观上更强大的最终产品。 该过程包括了解最频繁的请求、确定目标和非目标，以及写出用户应如何与特定功能交互。 调查人员将使用 Aim 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（安全超文本传输​​协议）进行，以实现安全通信。 服务器将处理信息显示内容、位置、时间和方式的逻辑。 这将使前端团队能够更快地行动，专注于用户体验、用户界面和漂亮的动画，而不是重复复杂的业务逻辑。 调查人员可以非常迅速地采取行动，自动更改内容在服务器上的显示方式，而无需更新用户应用程序。 API 处理身份验证、身份管理、内容、会话历史记录、订阅、AB 测试注册、资产、调查和民意调查、入职流程和场景。 调查人员还有部署在虚拟私有云内且不可公开访问的管理端点。 这些路由为支持场景和程序上传、用户管理、管理活动日志和注释以及调试的内部工具提供支持。 因此，现有 Calm 应用程序的所有方面，从冥想轨道和内容到特定的视觉和选择路径，甚至应用程序的内部结构工作都可以根据目标 1 的建议进行调整。 在指定 API 更改后，调查人员将更改 API 代码和前端应用程序以与 API 对话。 这导致原型应用程序专门针对癌症患者和幸存者，用于目标 3。 所有数据都将被加密，患者将使用密码访问该应用程序。 安全和合规标准将满足作为医疗保健提供商的业务伙伴的要求，包括 HIPAA 政策和程序。

目标 3：使用 IDEAS 框架，研究人员将使用癌症患者/幸存者样本 (N=30) 评估（即 Beta 测试）癌症特定冥想应用程序原型的可行性。 研究人员将通过社交媒体招募具有不同癌症类型和阶段、种族/民族、农村/城市地理环境和性别的癌症患者/幸存者。 研究人员收到了 100 封来自癌症患者/幸存者的支持信，支持开发针对癌症的 Calm 应用程序。 研究表明 5-10 名参与者足以确定可行性并发现技术困难。 样本量不是为了确定疗效，而是确定可行性的多个组成部分。 研究人员包括了更多的人，以确保有各种与癌症相关的经历。 Beta 测试参与者将被要求使用原型四个星期（免费访问），每天至少 10 分钟，但将被鼓励尽可能多地使用它，模仿新付费会员如何使用现有的平静的应用程序。 参与情况（完成的冥想、一天中的时间、时间长度、使用的组件）将在四个星期内被跟踪（由 Calm 提供）。 4 周的时间不是为了确定疗效，而是测试可行性的适当时间。 为了确定可接受性、需求和实用性，除了在干预后立即使用 REDCap 完成最终的整体研究满意度问卷外，还将要求参与者完成每周满意度问卷。 在为期 4 周的 Beta 测试之后，除了满意度调查问卷之外，调查人员还将要求参与者自愿进行半结构化访谈，以确定使用 Bowen 的可行性模型、可接受性、需求、实用性、适应性和整合性来优化潜力以推荐水平（即至少 10 分钟/天）接受、参与和持续使用。 采访的主题和调查结果将与咨询委员会分享，并用于将调查结果转化为与应用程序相关的建议（即，必要时进一步修订）以进行功效测试（第 2 阶段）。 这种方法类似于其他设计和开发移动应用程序的研究中使用的方法。 由于 COVID-19，调查人员将根据基于互联网的定性研究的最佳实践指南进行虚拟访谈。