Open mHealth Architecture Framing

The Problem

In mHealth, the hourglass is currently broken (the hourglass metaphor refers to the shape of the structure of the Internet technology stack. Read more here on the internet’s hour glass architecture here). We at Open mHealth aim to fix the hourglass by making mHealth open.

In the traditional mHealth technology landscape, the narrow waist of the hourglass (Internet Protocol) does not exist. Technologies abound for many different purposes, but they mostly reside in siloed stacks without the shared waist and without a shared architecture.

With Open mHealth, we would like to evolve the waist. In our early technical discussions with our small but vibrant community of mHealth collaborators, we realized two things:

1. Attempting to describe an all-encompassing ontology for health data was laborious and contentious.
2. Our stakeholders wished for something open that provided utility in the mHealth domain, but were also faced with the reality of existing closed systems that already provided utility.

How do we extend that utility? Well, we let everybody play.

In evolving the narrow waist of the hourglass, we are framing the problem in this way:

• Software tools for consuming and presenting mHealth data reside at the top of the hourglass, data resides at the waist, and data capture devices (hardware or software) reside at the bottom.
• The (organic, bottom-up) data protocol is what will allow devices and systems to interoperate in the Open mHealth software ecosystem.

We will evolve our data protocol over time and with input from our community.

How on Earth Are You Going To Do This?

Good question.

Firstly, we have decided on JSON/HTTPs for data structure and protocol. Secondly, we have begun work on a small ontology for metadata that any Open mHealth request must contain. Thirdly, we have identified use cases. Yes, use cases.

• Utilize ohmage (http://www.ohmage.org), an existing Open mHealth technology stack, as a reference implementation for a Veteran’s Administration (VA) pilot for veterans suffering from PTSD. The VA currently has an iOS app called PTSD Coach where all data resides on the iOS device. We will port the iOS client to talk to an ohmage server and presto we will have PTSDExplorer.
• With the above, we will also evolve a prototype of a standalone Open mHealth system.
• If you are interested in working with us to connect this application or another to your favorite existing stack and helping to drive common modules and interfaces, please let us know.
• We hope to very soon spawn two additional driving use cases: one around activity patterns and a second around another application domain such as asthma.
• In doing the work, we will focus on transparency by sharing working documents, code repositories, and technical specs. If you are interested in our project and share the vision that an Open mHealth software ecosystem will be beneficial to patients, clinicians, researchers, and the entire global healthcare system itself, we want you involved.

In a time when the cost of care is only going up, the average person’s income is going down, and the use of mobile devices is exploding, there is immense opportunity here for a system re-think where patients interact with clinicians or researchers via mobile devices to support quantitative studies and the efficacy of care.

Are you skeptical? Good. We want your input.

Getting to the Point

For the Open mHealth software architecture, we have identified three main abstractions.

1. DVU – Data Visualization Unit
2. DPU – Data Processing Unit
3. CU – Cache Unit

A DVU resides in client software, a web browser on a mobile phone or PC. DVUs must be implemented in HTML5 and Javascript with a standard interface so they can be plugged into an arbitrary application without too much fuss. DVUs talk to DPUs through a client communication interface (e.g., jQuery AJAX calls).

DVUs communicate with DPUs through the ubiquitous Internet cloud utilizing JSON over HTTP. A DVU communicates with aDPU through a pre-defined JSON data format. Payloads are dependent on DPU specifications and Open mHealth metadata standards.
A DPU resides in server software. DPUs are not bound by authentication. They simply receive data payloads, perform processing work on the data (smoothing, feature-extraction, data aggregation) and return that data to the caller. A DPU can be composed with other DPUs in a chain of work. DPUs identify data payloads using GUIDs.
A CU serves as a temporary cache for large data payloads. In some cases data payloads may be so large that it would be prudent for a DVU to store data in a cache and point a DPU to the location of that data. A CU is a way to optimize browsing through data frames.

This Sounds Awesome. When Are You Going to Have Something to Show Me?

Here is our current plan.

1. Determine requirements from PTSD Explorer analysis and visualization use cases. [in-progress]
2. Build analysis modules and visualizations from (1) into ohmage using GWT.
3. Use (2) to derive a more generalized Javascript/HTML5 architecture.
4. Perform tasks (2) and (3) in semi-parallel where ohmage is the concrete implementation and then we have a standalone demo of a more generalized set of visualizations that will be applicable to the larger Open mHealth community.
5. With ohmage, we are building DVUs using GWT. DPUs are developed using a combination of R and Java.

Our current DVU list includes:

• Static: (1) Multi-variate graphs that compare symptom x with behavior y to investigate correlations on a time series or as a scatter plot. (2) Time-series analysis in single-variate. (3) Aggregates of total engagement, median, mean, and standard deviation.
• Dynamic: (1) Drag and drop variates into a graph; (2) Zoomable on time-axis
• Exportable: (1) Raw data export

Our planned DPU list focuses on user statistics:

• Time series summary statistics
• Summary statistics correlations
• Trend and anomaly identification
• Activity classification
• And longer term, integration with external data sources

Timeline

• Determine whether the current DPU and DVU sets match up with the requirements of PTSD Explorer. [week of 10/10/2011]
• Engage a DPU developer. [done]
• Engage DVU developer or team. [in-progress, finished by the end of 11/2011 or earlier]
• Create PTSD Explorer to ohmage bridge. [ongoing, initial integration complete by early 11/2011]
• Start building standalone Open mHealth reference implementation. [starts on 12/1/2011]
• Have a complete working system to test out with pilot users and clinicians by 03/01/12

Questions?

Contact josh@openmhealth.org.