The medical field today is transitioning toward integrating patient-generated health data (PGHD) into clinical care to increase shared decision-making, coordination of care, patient safety, and clinical outcomes [1]. PGHD are central to this mission and are defined as data recorded or created by the patient or caregivers used to address health concerns. Examples include a longitudinal view of symptoms of patient status between clinic visits captured via an app or information related to daily adherence to treatment plans [1]. This may include a daily step count captured from a smartphone, medication surveys administered on the smartphone, and sleep quality data measured via a wearable sensor. Given the ability of smartphones and wearables to collect a myriad of continuous multimodal data relevant to care, such as heart rate, sleep, steps, and more, tools and systems to harness and use this vast amount of automatically generated PGHD are a health care priority. One challenge that remains toward this goal is the lack of technical infrastructure and organizational capability to handle the intake of accurate and valid PGHD from patient-owned consumer devices. Such standards and tools supporting the effective and compatible integration of PGHD are needed to enhance clinical insight and support research and data analysis before PGHD can actually impact routine care.

The need for apps that can not only capture but also use and integrate PGHD is clear. The use of commercially available wearable technology for the acquisition of PGHD has seen a recent uptick owing to the effects of the COVID-19 pandemic and growing demand for telehealth services [2,3]. Today, over 80% of Americans own a smartphone device [4] and over 20% own a wearable device [5], reinforcing the potential of PGHD to improve clinical outcomes. For example, the Apple Watch today retails at US $350 with onboard nonmedical grade electrocardiography and oxygen saturation sensors that continuously measure and record data. Modern smartphones are also equipped with numerous sensors that generate a high volume of potentially clinically significant PGHD that could enable a better real-time understanding of cognition, mobility, sociability, and more through techniques, such as digital phenotyping and ecologic momentary assessment.

Digital phenotyping [6] is the construction of an individual-level phenotype using data collected from smartphones or wearable devices actively via user interaction (eg, surveys), or passively without user input (eg, sensors, such as an accelerometer). Although there are many digital phenotyping tools and systems used in health care and research contexts, a recent review identified nearly 50 of them [7], and few offer an integrated and standardized approach to analyze and respond to clinically actionable patient-generated data. Existing tools are primarily closed systems or consist of only a single app with little flexibility or customizability [7]. In a recent review, 85% of existing solutions supported active and passive sensing but only 33% supported clinical assessment, 30% supported predictive modeling of patient data, and 24% supported app-delivered interventions [7]. Furthermore, only 35% of the existing solutions showed a patient- or clinician-facing user interface [7]. However, the combination of all these features is necessary to meet the diverse needs of research and care delivery. A search outside the research literature and instead, across mental health smartphone apps in commercial marketplaces reported that only 1.1% supported sensors [8], suggesting that many research tools do not translate into accessible tools for patient or clinician use. Although diverse functionality and innovation continue to exist across the entire app space, we have argued that there is a need for multiple uses of the same app, instead of using multiple apps in a fragmented manner, toward better supporting clinical research, integration, and implementation [9].

Creating PGHD tools that use sensor and digital phenotyping tools in a more patient- and health system–centric manner is a common goal, but it remains challenging to achieve. Despite the prevalence of existing electronic medical record standards and tools, a 2019 review on the integration of PGHD into clinical practice, “integration [...] was extremely limited, and decision support capabilities were for the most part basic” [10]. The most widely adopted medical record standards initiative that can be used to link PGHD to medical records is Fast Healthcare Interoperability Resources (FHIR), led by the Health Level 7 organization [11], which is now adopted by many major health care systems and industry partners, including Apple, Google, Amazon, Microsoft, and others [12]. Its companion projects SMART (Specific, Measurable, Achievable, Realistic, and Timely) [13] and SMART Markers [14] build on FHIR and enable integration of third-party modules into medical record systems, including patient mobile devices and sensors.

However, the FHIR ecosystem alone does not address a number of concerns specific to the integration of PGHD into clinical systems. FHIR and the current data interoperability standard (United States Core Data for Interoperability) [15] were not developed for continuous high-velocity data, and its implementation in the health care ecosystem today is primarily read-only, although its data gathering and write-back ability continues to evolve. For example, the FHIR core does not allow for semantic equivalence of data that can be used to automate data matching or harmonization. As a result, it is not possible to work with both cognitive assessment scores and mobility or sociability metrics using the same analysis pipeline. This increases the effort required and time taken to work with PGHD, as clinicians or researchers must first preprocess data of different semantic types individually before being able to work with a data set as a whole. Although R4 extensions, such as the mCODE core cancer model [16] are becoming a new way to expand FHIR’s supported vocabulary, they are still early in evolution and adoption. Today, the inability to standardize terminologies across interconnected systems, such as through a data dictionary, impedes effective export and analysis of different types of data from different data sources using the FHIR ecosystem [17,18]. These challenges preclude the adoption of FHIR as a PGHD-first standard for clinical and research use cases.

Thus, there remains a need for a flexible, interoperable, and extensible platform that enables the effective use of PGHD through widely accepted standards for both clinical and research needs. In this paper, we present a potential solution for the robust and effective acquisition and integration of PGHD into research and clinical care with tangible examples and open-source code.

To integrate PGHD into research and clinical care needs, our team has designed and developed the Learn, Assess, Manage, and Prevent (LAMP) platform that encompasses a robust set of protocols, standards, tools, and apps. Our team initially developed the mindLAMP smartphone app [19] as part of the initial version of the LAMP platform. In this paper, we review a rearchitected and redeveloped platform comprising new frontend, backend, and analysis components to support PGHD, patient-centric care, and actionable digital phenotyping. This new platform, distinct from its predecessor, includes features such as customizable and schedulable activities, sensor data collection and analysis, messaging support with the care team, and more, available across modern web browsers and smartphone operating systems. The design and development of the platform was approached from both a patient- and clinician-focused approach as well as a semantic standards–based approach.

The LAMP platform was designed and developed with continuous feedback from patients with serious mental illnesses and clinicians. Through a patient advisory panel, focus groups [20-22], clinical use, and feedback from a global consortium of users, mindLAMP has been co-designed iteratively with updates reflecting expanding ideas for its role. User input informed the adaptability, flexibility, and customizability of the LAMP platform, which resulted in a new user interface compared with the previous version, as shown in Figure 1. We established a formal system to enable anyone to suggest improvements, report bugs, and assess new features to ensure that all could partake in the iterative design rounds. This process also influenced aspects of the user experience, such as making mindLAMP available in multiple languages (English, Spanish, and Hindi) and designing to ensure easy addition of more. Key examples of patient feedback and the design outcomes they influenced are provided in Table 1.

In addition to a patient- and clinician-centric design approach, the LAMP platform was also architected with a semantic standards–based approach, considering technical best practices for future proofing and security or compliance across health care systems. The open standards listed in Table 2 were chosen specifically to foster an open ecosystem around the platform. For example, the platform’s programming interface adopts a repository model to store and configure patient-facing instruments, each with its own embedded user interface. These embedded user interfaces were developed using common and widely adopted web standards indicated in Table 2 (HTML5.0, Cascading Style Sheets 3.0, and ECMAScript 6). As a patient begins an interaction session, this embedded code is securely sandboxed by the mindLAMP user interface both within the smartphone app and the patient-facing web dashboard. In addition to providing a standard schematic of all structured documents encountered and processed in the LAMP platform using OpenAPI [23], the JSON Schema [24] data markup standard is used to provide developers of these interactive patient-facing instrument configurability and extensibility. With little required skill or upfront effort, developers can use the platform’s software development kit to create instruments with completely customizable user experiences that are then tuned and customized by clinicians for individual patients or by research coordinators for studies spanning many patients.

The LAMP platform is a customizable clinical care management and neuropsychiatric research platform designed around PGHD, as detailed in Figure 3. It comprises numerous essential features, such as customizable clinician-defined activities (eg, surveys, breathing exercises, journaling, and cognitive tests), collection and analysis of mobile and wearable sensor data, push notification scheduling, care team–centric conversations, just-in-time adaptive interventions, prebuilt featurization, visualization, or analysis pipelines, and a companion integrated development environment (IDE). The LAMP platform is available for use across any modern desktop web browser as well as recent versions of iPhone operating system and Android through the mindLAMP app available on the Apple and Google app stores, as shown in Figure 4. The backend is deployable using enterprise-standard orchestration tools (Docker and Kubernetes [31]) and has already been deployed across several health care systems and is used today by patients, clinicians, and researchers. The companion Cortex data analysis toolkit integrates tightly across the platform to provide a unified processing pipeline for secondary active and passive data features (measurable behavioral characteristics extracted from raw data), interactive visualizations, and the generation of targeted and automated adaptive interventions. The IDE is bundled with support for the widely adopted Python, R, and JavaScript programming languages and built atop Jupyter Notebooks and Visual Studio Code for collaborative data analysis.

The LAMP platform is designed to be customizable to fit a wide range of use cases and requirements, eliminating the need for multiple apps hosting only a set of fixed, immutable content as well as the research concern of proprietary data formats and closed-source commercial analysis software. It also securely enables data interoperability and extensibility, avoiding the issue of data silos without external access of collected data for clinicians or patients. It integrates into existing hospital organization structure and is not limited to the sandbox on an individual’s smartphone, allowing the caregivers and patients to coexist on the same platform. These features combined allow the LAMP platform to engage the care team through interactive clinical decision support with adaptive responses to incoming PGHD. Where a self-contained app must focus on solving individual problems for specific stakeholders, the LAMP platform focuses on broader challenges around linking people with data and data to teams of interconnected stakeholders, from patients and clinicians and family members and the care team to administrators and research coordinators. For these reasons, the LAMP platform supports digital phenotyping+, the plus symbol indicates the ability to return and share PGHD with the individuals from which it is collected in a secure and ethical manner and the ability to integrate that data into a machine learning pipeline or other clinical decision support algorithms.

The rearchitected LAMP platform addresses the integration of PGHD into existing systems through a simplified extensible programming interface (application programming interface [API]) and an internal data representation that interlinks raw data and metadata with descriptive schema. The Cortex data analysis toolkit obviates the need for custom preprocessing or harmonization of disparate sources of data and removes barriers between the real-time collection of PGHD and subsequent featurization, analysis, or visualization. We present the process results and examples below but do not offer a hypothesis in line with other papers exploring informatics systems created for use in clinical care and research.

To enable robust data analysis, adaptive interventions, and interoperability with a broad range of health care systems and services, the platform’s data repository and programming interface are based upon a concise semantic FHIR-compatible API. The platform’s API provides both predefined and pluggable schematics for patient-facing instruments, such as surveys and cognitive tests as well as for mobile and wearable sensors. The platform’s backend validates and harmonizes patient data upon receipt, retaining lossless FHIR compatibility in the process. The platform provides a facility to query and transform data into FHIR-compatible bundle and resource types, in addition to other domain-specific tabular or structured data formats. Table 2 lists the clinical, regulatory, and software standards implemented and supported by the LAMP platform.

The LAMP platform’s internal data representation provides a simplified abstraction around PGHD in comparison with FHIR. Fundamentally, FHIR adapts a message and document-based exchange programming interface atop the representational exchange state transfer web standard protocol. The FHIR data structures (Figure 5) consist of over 90 modules for clinical use, insurance, billing, and other use based on the concept of resources, with each resource containing some raw data, metadata, a schema identifier, and a human-readable representation of the raw data. The schema identifier is used to reference how the data should be interpreted by a compatible system or machine. As the raw data contained within 2 resources of the same schema type may differ (eg, the use of the observation data type to represent both blood pressure and depression assessments results), data processing cannot be standardized across different data types. By organizing and accessing PGHD separately from generalized repositories of data, such as electronic health record systems using the FHIR API, common and shared analysis methods and processing tools that are standardized across such various data types can be used by clinicians and researchers.

The LAMP platform declares only 12 core PGHD-centric resources (Figure 5) that remain focused on clinical and research use. The Researcher and Study resource types group together sets of participants as well as the activities and sensors they are able to interact with or collect data from. Upon data collection, ActivityEvent and SensorEvent describe and link the recorded data to its metadata and any specific customized parameters. The Credential resource provides security access controls to any of the aforementioned resources, and the Tag resource provides support for integration, extensibility, and backward compatibility. The semantic context of any recorded data and metadata is described by ActivitySpec, SensorSpec, and TagSpec.

Understanding the need for seamless integration into existing health care systems, software, and services, the platform exposes its internal data representation through the LAMP protocol, a programming interface that enables integration with third-party services. For example, integration with Google Fit wearable devices that also implement this same push-based model, is possible by signing up on the Fitbit developer portal and connecting the data output of the Fitbit programming interface to the data input in the programming interface provided by the LAMP platform. In another example of seamless integration, clinicians and researchers can use automated scripts to synchronize data between the mindLAMP app and their existing record-keeping systems. Data can be proactively fetched and stored securely, and users of the platform are notified of any or all data from a particular patient using subscriptions, regardless of whether the data were generated by the mindLAMP app or a third-party data source.

The extensibility and flexibility of patient-facing instruments in the LAMP platform rely on the unique data structure and functionality provided by the LAMP protocol as shown in Figure 2. Each activity with which patients are able to interact is defined and encapsulated in an activity specification that contains the program code written using web-compatible standards, along with descriptors of the required input configuration and output data. When a patient begins an interactive session with any activity, session-wide metadata regarding who, what, and when are recorded. Each tap of the screen within the activity is then automatically validated and converted into a standardized data format called a temporal slice. When the user completes the interactive session, all the temporal slices are packaged into chronologically ordered events indexed under the patient’s identifier as a stream of continuously generated data. The data analyst is then able to query these data at any desired temporal resolution (eg, 1 millisecond, 1 day, and 1 year) and filter by the type of activity (eg, mood survey, anxiety survey, trails-making test, and meditation). The query can be mutated using transformation logic executed by the backend and subscribed such that newly uploaded data matching the query is reported in real time to the data analyst. This query framework can be used to better understand how participants use and engage with the activities available to them as part of the study, for example, by extracting a real-time metric of duration spent meditating in the app per participant.

As depicted in Figure 4, the flow of activity specifications to configured activities to their generated PGHD facilitates patient interaction with any kind of interactive web media, from static text for tips, to video content for learning modules, or audio content for breathing exercises. Instruments and their data can be monitored and maintained organization-wide for compliance and conformance. Multimedia Appendix 1 lists the sources of active and passive data currently available within the mindLAMP app and their data sources and types. This novel data organization and structure supported by the platform enables unification and harmonization of these different data types, with both backward compatibility to data types from legacy systems and future compatibility for data types for systems that are not yet available.

The same pipeline operates on both active and passive data, unifying the conceptual model for PGHD processing and obviating the need for individual analyses tied to custom code for specific sensor types across various devices. Sensor data are therefore subject to additional harmonization to account for the various differences in functionality and recording between Apple and Android devices. For example, accelerometer measurements taken on Apple devices are measured in units of gravity (G) with a frame of reference experiencing −1 G in the downward-facing axis, whereas measurements on Android are measured in meters per second square (m/s²) without a frame of reference provided. As the platform automatically applies this harmonization step, the data analysis code does not require an intrinsic understanding of the source of the data. Samples of sensor data after harmonization are shown in Figure 6. Furthermore, in addition to raw sensors on smartphones or wearable devices, processed Apple HealthKit and Google Fit sensor data, such as activity recognition or heart rate variability, are available to the LAMP platform.

The Cortex data analysis toolkit further simplifies the extraction of passive data features as listed in Multimedia Appendix 1, with an example shown in Figure 7. Cortex provides prebuilt, parallelized and vectorized workflows in Python for PGHD extraction and featurization that operate across large data sets to generate interactive visualizations for the mindLAMP dashboard using the Vega visualization grammar (as listed in Table 2). It obviates the need to work directly with the LAMP protocol, allowing data scientists to reason about live actionable structured data entirely as data frames within their programming environment of choice. Through the vectorization of array operations and parallelization of function calls, Cortex is able to target high performance and cost-effectiveness, while maintaining data security and policy compliance. A sample execution plan for a particular analysis involving the GPS data is shown in Figure 8. The modular nature of PGHD captured by mindLAMP allows for personalization and creation of new digital biomarkers and analysis without the need for additional coding. Furthermore, the companion IDE manager abstracts away log-in and security issues by securely injecting an authenticated connection to the server into Cortex and the resulting analysis notebooks.

Research and clinical needs in digital medicine are evolving to use PGHD approaches to understand patient behavior and symptomatology [3]. To this end, by optimizing the system architecture for data throughput and substantial database write-loads, the LAMP platform supports high-performance data collection and real-time data analysis to enable, for example, larger machine learning models or just-in-time adaptive interventions that can leverage PGHD into actionable insights for patients and clinicians alike.

Among the various approaches to data collection adopted in digital medicine, the pull-based model [13,14] shown in Figure 9, requires patients to activate a request and upload data from their mobile devices. This request can be scheduled and authorized. An example of the pull-based model is that during a clinical encounter, the clinician would use a portal to request data collection from the patient’s device for a period of 1 day; the patient would then have to approve this request in their smartphone app before data collection can begin. During the next clinical encounter, the clinician would be able to interpret the data in potentially meaningful ways.

The LAMP platform, however, adopts a push-based model shown in Figure 9, where, in contrast, clinicians or research coordinators configure and schedule activities for patients to use and sensors from which measurements should be passively recorded ahead of time. The patients’ devices receive a configuration request that activates data collection in the background. As it is collected, the data are uploaded (pushed) to the back end periodically, available for processing and clinical insight ahead of time. This push-based approach reduces latency from collection of PGHD to the usability of that PGHD, for example, as real-time alerts in the context of research studies (Figures 10 and 11), or toward clinical decision-making with custom rules and alerts. It is important that clinicians or research coordinators communicate clearly and establish consent with the patient or subject about the various types of data being collected and the frequency of the data push.

The data collection processes are executed both actively during patient interactions with the mindLAMP app as well as passively while the app or mobile device is not in use. These data are securely uploaded to the organization’s backend systems and can be used immediately upon receipt for data analysis and logic to select interventions to display to the patient. Using push notifications sent to the mobile device, the platform promotes a high level of engagement with patients without explicitly requiring approval for data upload. Once a research study or clinic is configured, its documenting configuration can be exported and reimported by other LAMP-compatible systems or interfaces. This allows reproducibility in both clinics and research studies, for example, by attaching the configuration file to a research manuscript or clinical protocol.

The LAMP platform is built and maintained collaboratively as an open platform to address the needs of many and integrate tools and resources to streamline workflows. In contrast to commercially available apps and services, the mindLAMP app may be used by organizations independently of our team through the deployment of a secure self-hosted backend. It can be customized and adapted without requiring specialized coding and deployment efforts, although others have also taken advantage of the extensibility of the platform to design and develop unique cognitive tests for their organization’s needs. Common data processing and analysis needs across clinical and research workflows are encapsulated by the platform and the Cortex data analysis toolkit to minimize the time between patient onboarding and affecting or assessing patient outcomes.

The LAMP platform is highly configurable to suit many needs across a broad range of both clinical and research use cases and strategies. Consortium partners are encouraged to share their use case and LAMP configurations. As shown in Textbox 1, there were many different potential configurations and use patterns across consortium members.

To aid these joint research and clinical efforts, the LAMP consortium was founded to connect partners using the LAMP platform. The design and development of the platform occurs in an open-source, collaborative environment that many have taken advantage of to suggest features, report bugs, add documentation, and improve the overall quality and efficacy of the LAMP platform. Through its flexibility and interoperability, the platform encourages integration and cross talk between clinical and research contexts, and to this end, supports the implementation of a digital clinic [33] and the creation of a digital navigator role [35].

The consortium further integrates directly into the development and feedback cycle using a community forum and bug tracking system, both available publicly. The community forum serves as a centralized resource for multiple teams or organizations to work with one another to assist with data analysis or troubleshooting and provide feedback about the LAMP platform. In addition, collaborators actively engage in making modifications to the source code (hosted through the public source code repository hosting service GitHub), make any suggested modifications or bug fixes, and then request that these changes be merged upstream into the distribution of the LAMP platform that is used by all. To learn more about the LAMP platform or help contribute, one can join the consortium or visit the open-source repository [36].

Through the incorporation of patient- and clinician-centric feedback as well as a standards-based approach, the LAMP platform is designed to address important needs around the effective and compatible integration of PGHD into existing clinical systems for research and clinical care. It offers a flexible and comprehensive set of tools and solutions that can be configured and stitched together to function in a wide range of use cases, as used by members of the LAMP consortium. Its simplified programming interfaces are designed to securely handle a high throughput of PGHD as well as its companion metadata. With the integration of the Cortex data analysis toolkit, machine learning feature extraction, data processing, interactive visualization, and other essential tasks are simplified and coordinated seamlessly at low cost and high efficiency. In addressing technical challenges, the LAMP platform enables research and clinical teams to rapidly convert PGHD from widely accessible consumer smartphones and wearable devices into actionable clinical insights.