Open mHealth is catalyzing a decentralized, innovative community committed to developing sharable mHealth tools with open APIs that allow independently developed software components to be mixed and matched, swapped, and shared like Lego blocks () [
17]. To begin, we developed InfoVis, which is the architectural scaffolding for data analysis and visualization building blocks that the Open mHealth community is creating, combining, evaluating, and adapting.
Open mHealth’s architecture mimics the natural structure of the honeycomb. The foundational framework is a common set of principles and APIs that enable reusable software modules—or individual pieces of the honeycomb—to be built into and upon the underlying structure in a plug-and-play fashion. The architecture enables additional modules to be easily added and pieced together, facilitating the growth of the entire honeycomb and strengthening the overall structure.
The basic types of reusable software components in Open mHealth are data processing units (DPUs) and data visualization units (DVUs). DPUs are the building blocks for extracting relevant features from data streams, whereas DVUs enable the presentation of those features and patterns. Data storage units are components that manage the input and output of data to DPUs and DVUs, and are specific to particular data storage solutions (eg, a Health Insurance Portability and Accountability Act [HIPAA]-compliant cloud storage vendor). For any particular application, the DPUs, DVUs, and data storage units are embedded in a plug-and-play fashion within that application’s running system, which can range from the Android operating system, for example, to full-featured platforms such as that of AT&T [
18].
Each DPU and DVU does one task and can be composed to produce higher-level functions. For example, low-level DPUs can transform time series of on-phone and other sensor measurements (eg, accelerometer) into time series of user states (eg, sitting, walking, or driving). Midlevel DPUs compute clinically relevant metrics (eg, 6-minute walk test) [
19]. Higher-level DPUs process and fuse one or more metrics (eg, activity metrics with self-report data) to come up with health markers for a person’s state (eg, functional status). Such hierarchical analyses that transform lower-level data streams into higher-order markers will reduce the need for self-reports, thus mitigating the challenge of user engagement.
Open mHealth components can be incorporated into applications as libraries or can be invoked using JavaScript object notation over hypertext transfer protocol if they are developed with a Web service wrapper. We encourage component developers to support both library- and Web services-based approaches to accommodate application-specific preferences. All components must follow interoperability specifications that set forth common patterns of implementation and methods for data interchange. These specifications, which are continually being refined and are available at [
20], follow these principles: using modern open source industry standards where possible; using lightweight interoperability standards; using declarative semantics with allowance for multiple bindings to multiple reference standards; and allowing standards to emerge through community patterns of use rather than imposition. For example, the data input to a DVU is at a minimum specified by a payload ID in the Open mHealth namespace (omh). This payload ID will be in the form of a string (eg, omh:serum-sodium) that is intentionally light on required formatting or semantic standards. This is to encourage and facilitate rapid exploration and innovation. As individual components gain traction with the community, external IDs can be used to map the payload ID to external existing health standards using a uniform resource name (URN) to the BioPortal server [
21], an approach that is similar to the Substitutable Medical Apps, Reusable Technologies (SMART) platform [
22] (eg, the URN of Logical Observation Identifiers Names and Codes [LOINC] code [
23] for serum sodium values would be purl.bioontology.org/ontology/LNC/2951-2). Developers may choose to map to zero or more external standards, and all component IDs will be indexed for search functions that will be available in the Open mHealth code repository.
An Illustrative Use Case
An excellent use case that demonstrates the power of our architectural approach is self-care tools for posttraumatic stress disorder (PTSD). PTSD Coach is a mobile app conceived by the US Department of Veterans Affairs and Department of Defense to help PTSD patients manage acute distress symptoms through education, connection with personal and public resources, self-assessment, and personalized, interactive tools rooted in cognitive behavioral principles [
24].
Management of PTSD presents an ideal use case for augmentation with mHealth tools, as many patients who need care may not seek in-person assistance due to stigma, logistical barriers, or lack of problem recognition [
25]. While standard face-to-face treatments for PTSD have been found to be quite effective, mobile apps can provide a convenient, location-independent, anonymous alternative to standard care. Even those individuals who are receiving PTSD care may experience distress in the week that passes between treatment sessions. For them, mHealth can provide just-in-time tools, including crisis management strategies, wherever and whenever they are needed. Primary reliance on mobile devices for Internet access is becoming increasingly common [
26], but existing PTSD Web resources are not optimized for mobile use.
Whether used between clinic visits or for independent self-management, PTSD Coach supports skill acquisition for coping with acute symptoms (eg, guided relaxation or progressive muscle relaxation); self-assessment for improved problem recognition and self-monitoring; and education aimed at increasing knowledge about PTSD and its effective treatments, decreasing stigma, providing messages of normalization, and increasing likelihood of entering care. Links to support, both national and personal, improve the individual’s chances of entering care if it is warranted. Due to data sensitivity concerns, PTSD Coach was built as a stand-alone application for patient self-care with no transmission of data to or from the app for clinician involvement. Open mHealth collaborated with the PTSD Coach team to develop a version called PTSD Explorer that captures and reports user-reported and other data back to a HIPAA-compliant server. PTSD Explorer will be integrated into the Veterans Administration’s electronic health record in a future phase of this project. Open mHealth’s approach to electronic and personal health record integration is not yet defined but will follow principles aligned with the “substitutable apps” approach described by Mandl and Kohane [
27].
To help clinicians make sense of PTSD Explorer patient data for use in direct clinical care, we developed InfoVis data processing and visualization modules, some of which are generically usable across disease conditions. Data input and output formats of each InfoVis unit are specified as part of the DPU or DVU interface. Open mHealth’s modular open approach facilitated rapid exploration and iterative innovation to support participatory design of PTSD Explorer with a team of clinical psychologists and psychiatrists, allowing for quick and easy configuration of new dataviews for various clinicians, cohorts, and conditions and over time.
Our development process for PTSD DPUs and DVUs explicitly involved abstracting common processing functions that would be reusable across multiple disease conditions. For example, one DVU we built for PTSD Explorer displays continuous data over time, which is a disease-independent function that can be chained with other components to yield more complex, disease-specific visualizations (eg, of PTSD Checklist scores or blood glucose values over time). We are now using the DPUs and DVUs built for the PTSD use case to generate patient-facing visualizations of various self-reported measures of chronic pain. Because the Open mHealth community will reuse and adapt these DPUs, DVUs, and their interfaces over time, multiple approaches to processing and visualizing PTSD and pain data will coexist and will be reused or not depending on their effectiveness and value for both disease-independent and disease-specific usage.
Over time, actual usage and demonstrated value of InfoVis components across the range of all Open mHealth projects will drive convergence on common interface and semantic usage standards. DPUs and DVUs will process data from data storage units that access a wide range of third-party data applications and stores. In this modular way, Open mHealth will build a strong, community-sourced open component architecture to complement proprietary innovations to maximize the overall impact of mHealth.