Computing Community Consortium Blog

The goal of the Computing Community Consortium (CCC) is to catalyze the computing research community to debate longer range, more audacious research challenges; to build consensus around research visions; to evolve the most promising visions toward clearly defined initiatives; and to work with the funding organizations to move challenges and visions toward funding initiatives. The purpose of this blog is to provide a more immediate, online mechanism for dissemination of visioning concepts and community discussion/debate about them.


Toward an Open mHealth Ecosystem

April 26th, 2011 / in research horizons, workshop reports / by Erwin Gianchandani

Ida Sim, Associate Professor & Director of the Center for Clinical & Translational Informatics (CCTI), UCSF (image courtesy UCSF)Deborah Estrin, Professor of Computer Science & Director of the Center for Embedded Networked Sensing (CENS), UCLAThe following is a special contribution to this blog by Deborah Estrin, Professor of Computer Science and Founding Director of the NSF-funded Center for Embedded Networked Sensing (CENS) at UCLA, and Ida Sim, Associate Professor and Director of the Center for Clinical and Translational Informatics (CCTI) at UCSF.  Estrin and Sim co-organized an Open mHealth Summit April 14-15 in Washington, DC.

Mobile health (mHealth) has the potential to transform the nature and reach of health care activities; however an increasing concern is that proliferating independent mHealth apps are emerging highly siloed with limited data sharing and limited interoperability. Such a stovepipe approach threatens to fundamentally limit the power and potential of mHealth.

On April 14th and 15th, a group of ~45 experts from diverse areas in health sciences and information technologies met to discuss how to bring about an open mHealth ecosystem. With support from the Computing Community Consortium, California Health Care Foundation, and Robert Wood Johnson Foundation, the group was hosted at the Kaiser Family Foundation’s Barbara Jordan Conference Center in Washington, DC. Discussion centered on an open mHealth architecture in which an ecosystem of re-usable, substitutable modules of basic mHealth functionality would interoperate through defined interfaces adapted from existing systems and data exchange standards. A distinguishing feature of the group’s vision is to build the architecture to expressly support and promote evidence-based approaches to care delivery, and to catalyze the scale, coherence, and effectiveness of mHealth that the world needs.

The group met with the common goals of

  • facilitating integration and reuse of mHealth components and data across applications and across the spectrum of clinical care, public health, clinical research, and health promotion;
  • supporting both commercial and non-profit innovation while balancing public and commercial interests;
  • promoting development, incorporation, and evaluation of evidence-based methods; and
  • reducing rather than exacerbating health disparities.

The open mHealth patient data flow (image courtesy openmhealth.org).

After discussing the overall health drivers and approaches in plenary, we spent most of our time in two subgroups to discuss the technical and governance issues, respectively. The technical subgroup’s overarching objective is to build and, through experience, iteratively refine an open mHealth architecture with standard interfaces and a corresponding open source reference implementation of substitutable modules. The governance subgroup focused on the need to build and sustain an open mHealth development community with collaborative governance and stewardship, through a public-private partnership.

Technical approach

The technical subgroup had 7 running code and real users efforts represented. We used three usage scenarios to ground discussion: postpartum weight loss, depression in veterans, and teen asthma-trigger mapping. We agreed that an essential component of the openmHealth architecture is the “narrow waist” of the hourglass architecture. In this waist will reside common data format standards, initial common semantics for interoperation, and common privacy and sharing controls. Above the waist will reside a core set of analysis and data management modules, which are substitutable with open or commercial versions. The architecture will be held together by a set of well-defined interfaces that allow modules and applications to be flexibly mixed and matched. We agreed that to seed this architecture, the open reference implementation would  begin with the most important modules, using both already available components, as well as newly constructed modules and the corresponding interfaces between them.

We came away with four key findings:

  1. We largely agree on common data flows and tools:
    1. flows: capture (automated data streams, smart self report, detailed analytics)–> storage–> analysis–> dashboards/feedback
    2. tools: scripting/personalization, privacy/sharing, ehr/phr integration (identity management and access control);
  2. We have several (but not all) production level modules, but no one end to end production level system analysis and vis (dashboard UI authoring, ML based analysis libraries, integrating with external data), end-user feedback, engagement, social tie in, goal setting, privacy/sharing, multi device-platform resource management and user management;
  3. The greatest as yet unbuilt needs are in analysis and user interaction design components; and
  4. The prototypes we have can be used to drive initial specification of: APIs, Data formats, and other core components of the architecture. In addition, we discussed the importance of adopting a ‘Noah’s ark principle’ in which we would pursue two options instead of a single option for key components (data stores, driving applications, activity classifiers, etc.) in order to build in some level of generalizability, interoperability and minimize dependence.

The technical group also felt it was critical that the modules and the interfaces be built in tight iteration with real-life mHealth projects to ensure that needed functionality is provided. Therefore the group discussed building 2-3 pilot applications based on an integrated end-to-end system leveraging both existing and to-be-developed software. The pilots will be selected to exemplify key functional capabilities that the architecture must support. In the longer term we hope that the open ecosystem activity will foster mHealth development efforts that have greater interoperation and semantic coherence, while still supporting proprietary commercial innovation with respect to the internal operation of particular modules, as well as turnkey system development and deployment.

The applications that will be used as drivers and ultimately that will be the greatest beneficiaries of mHealth were identified as having 3 core functional dimensions:

  1. Behavior Change: many apps in the consumer/patient space involve some aspect of behavior change, including goal setting, feedback on day to day behavior, and tailoring and adaptation over time of goal setting and self-monitoring;
  2. Efficacy Assessment and Adherence Promotion: a potential “killer app” for mHealth is improving therapeutic efficacy by leveraging mobile-enabled high temporal resolution data on patient-reported symptoms and side effects, especially if combined with improved adherence to interventions; and
  3. Personal Strategies: self-care often requires identification of individualized factors or behaviors that make a disease better or worse, where what others have learned can be shared to help individuals more quickly discover personalized triggers and effective methods.

Governance approach

The openmHealth architecture is not just a technical innovation, but also a social innovation that contributes to a wider public good. A collaborative governance mechanism was discussed in some depth to provide ongoing worldwide stewardship of the openmHealth community. Topics included: Community building, Setting the health priorities for the reference architecture, Securing funding, Developing a robust community to develop and use the shared infrastructure, and overseeing issues associated with privacy, data sharing, standards, and IP.  The governance group concluded that to catalyze the vision, the Consortium needs to develop and maintain technical and social infrastructure for sharing and learning within mHealth, i.e.: (a) build high-quality core reference implementation of the open architecture with libraries of sharable interfaces to external resources; as well as (b) build a social infrastructure to nurture and sustain the developer and learning communities. A priority is to define more rapid and person-centered methods for evaluating which mHealth and clinical strategies are effective, and to build these methods into the architecture.

Guiding principles

Across the technical and governance subgroups we articulated shared principles/values to guide the work going forward:

  1. self at the center, scaling from individual to society (emergent benefits) trustworthy, safe, fair, open, transparent, balance of sharing and privacy promotes health equity and community engagement holistic view of individual including social context (e.g., family loved ones); and
  2. norms of engagement/values including all of above plus preferentially promotes sharing values community learning through both formal and informal methods self-organizing and self-governing promotes both commercial and non profit innovation.

Next steps

In his invited concluding remarks, Dr. Chuck Friedman, Chief Scientific Officer of the Office of the National Coordinator for Health Information Technology, emphasized that our openmHealth vision and approach are fully aligned with current national health IT policy, from moving the focus of health IT from the system to the patient, to fostering innovation through open approaches and adoption of health IT technology as stated in the draft ONC Strategic Plan. Dr. Friedman called openmHealth the “right play” at the “right time,” and expressed his full support and optimism for the project.

openmhealth.orgThe meeting ended with agreement on important next steps that could continue in the immediate term based on volunteered efforts, and that longer term efforts would be contingent on collaborative success in committing and funding resources. Near term next steps include a nonprofit through which to coordinate the consortium, identifying the fiscal sponsor, securing seed funding, getting the message out to target audiences, evangelizing during this window of opportunity, converging on initial target driver applications, and starting the process of system integration and gap filling across existing software project collaborators.

Were you at the Open mHealth Summit?  Do you have thoughts on the technical and governance approaches summarized here?  Comment in the space below!



Toward an Open mHealth Ecosystem

6 comments

  1. Dan Keller says:

    An essential step in the transition to the empowerment of consumers/patients to participate in their own care decisions is taking ownership of their health data.  Open mHealth can be a catalyst in this transition.  Kudos!