Open mHealth-mHealth Summit Presentation
•Transferir como PPT, PDF•
5 gostaram•2,386 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Open mHealth-mHealth Summit Presentation
Semelhante a Open mHealth-mHealth Summit Presentation (20)
Último
Último (20)
Open mHealth-mHealth Summit Presentation
- 1. IDA SIM, CO-FOUNDER DEBORAH ESTRIN, CO-FOUNDER DAVID HADDAD, PROGRAM MANAGER December 5, 2011 #openmhealth Sponsored by the Robert Wood Johnson Foundation and the California Health Care Foundation A project of the Tides Center
- 4. data driven feedback loops
- 5. 2
- 6. without better sensemaking to drive these feedback loops…
- 7. Plateau of Diminished Promise
- 10. open infovis for sensemaking
- 12. infovis architecture INFOVIS IS A SET OF TOOLS FOR ANALYSIS AND VISUALIZATION OF INFORMATION ARCHITECTURE IMPLIES SYSTEMIC, STRUCTURAL, AND ORDERLY PRINCIPLES TO MAKE SOMETHING WORK (SAUL WURMAN) BY DRIVING THE INFOVIS ARCHITECTURE THROUGH CONCRETE APPLICATIONS WE ’RE ABLE TO CATALYZE RAPID EVOLUTION, VALIDATION, AND SHARING OF SENSEMAKING TECHNIQUES
- 18. why open ? 3
- 21. rephrasing ‘does it work?’ (Complexes of) Exposures Outcome strength of association? individual population Increased breastfeeding Text4Baby
- 22. ‘ does it work on average?’ 50 people population 100 people PTSD Coach PTSD symptoms PTSD symptoms 50 people Usual care
- 23. ‘ does it work for me?’ N-of-1 study design PTSD sx PTSD Coach Usual care Usual care PTSD Coach PTSD Coach Usual care PTSD sx individual me
- 25. flipping direction of research inference population
- 31. mission of open mHealth 5
- 32. 1. catalytic convener 2. scale 3. flip the direction of research inference
- 35. users
- 36. developers
- 38. moving forward
- 39. what is open mHealth doing?
- 40. building
- 42. timeline
- 43. get involved
Notas do Editor
- Thank you very much for coming to our session. HASHTAG for the session is #OPENMHEALTH
- I'm sure most of you have seen this Gartner Hype Cycle graph before. Where would you say mHealth is right now? Raise your hand. Here (just before or at the peak)? Here (after the peak)? Or here (in the trough)? Yes, we will go through the Trough of Disillusionament, but the real question is where this will all end up. What will be mHealth's plateau of productivity?
- Let's start with a very high level view of mHealth. mHealth applications are sources of passive and actively collected data, which must be visualized and interpreted, and integrated into daily life and clinical care. It is the mHealth data that are the nuggets of value here...
- ...data to drive what we have identified as three essential feedback loops to improve health outcomes.
- First is data to provide feedback on self-care. How is this medication working for me? Is my stress better now that I'm sleeping more? A second feedback loop is to clinical care. For clinicians like me, I want to know how my patients are doing: Is Mrs. Lee's depression improving? Perhaps I might want to intervene in her own feedback loop with advice, a dosage change, or some other action. Finally, data can act as research evidence, driving a loop of knowledge to tell us what works and what doesn't in different contexts, which in turn will propagate back to these other feedback loops. But these feedback loops are not happening as well or as fast we need . mHealth data is really a new kind of data that we've never gotten our hands on before: large volume, real-time, self-reported data collected with high frequency. This data tends to have lots of bias, noise, and gaps, so it's hard to make SENSE of it, to extract relevant features and patterns to drive the feedback loops. As an ecosystem, mHealth is struggling to develop and disseminate tools and techniques for sensemaking of mHealth data.
- ...and without better sensemaking to drive the 3 essential feedback loops
- we are likely to end up not at the fabled plateau of productivity, but rather at a plateau of diminished promise. This opportunity gap is what OpenmHealth is about . We seek to tip the mHealth ecosystem to this trajectory, rather than this one. How are we going to do that?
- ･ Today, mHealth apps are being built independently, with little sharing of data, methods, or learning. We believe that this siloed mHealth ecosystem is a barrier to the promise of mHealth . We believe that what is needed is to borrow the Internet ’s approach of open modular sharing and learning. ･ The Internet has what is called an hourglass architecture, from which it derived much of its success. There is a common protocol that acts as a simple point of commonality at the narrow waist. This allows innovation to flourish through open interfaces, or APIs, both above and below the waist. ･ Open mHealth aims to catalyze the mHealth ecosystem from a siloed architecture to an hourglass architecture, by developing shared components and open APIs at the narrow waist. This should in crease the scale and effectiveness of mHealth sensemaking for self-care, clinical care, and research evidence, and ultimately to improve health outcomes.
- I will now hand the floor over to Deborah to introduce our architecture, and talk about our InfoVis components for sensemaking. I will come back to describe our plans for a personal evidence architecture to tie sensemaking to generating research evidence.and David will finish up describing our project activities and how you can get involved.
- no shortage of good ‘apps for that’ need progress top of hourglass...“Sense making” -- tools and techniques for extracting and evaluating data to drive feedback loops (patient self-care, clinical care, research. ) Goal: vibrant decentralized community of openmhealth users and contributors (tech and health innovator sectors) Note: This is not about agreeing on interoperability standards, we dont have to all agree, rather its about creating and sharing pluggable software/algorithms.
- no shortage of good ‘apps for that’ need progress top of hourglass...“Sense making” -- tools and techniques for extracting and evaluating data to drive feedback loops (patient self-care, clinical care, research. ) Goal: vibrant decentralized community of openmhealth users and contributors (tech and health innovator sectors)
- Infovis shorthand for sensemaking software modules--data analysis and presentation techniques--reusable, combinable, across mhealth apps Decentralized innovative community needs architecture so independently developed software modules can be mixed and matched--and minimal interface definitions that all can depend on Architecture : small set of common principles/practices by which these modules are described and interfaced to one another. Architecture is why we have the internet we do Need to drive architecture development w/ real use case of patient-facing mHealth--PTSD w/ VA
- Photo: VA and DOD. Adapted from Julia Hoffman (VA), et al. Julia Hoffman et al. PTSD Coach, personal tool to manage and mitigate symptoms. Stigma and logistical challenges of seeking help. Full week between sessions to self-manage. Skills for between-session and independent self-management: self-assess variations in condition; develop portable skills to address acute symptoms Developed 2010 and on app store mid 2011
- PTSD Coach implemented as a stand alone application for patient self-care. PTSD explorer brings data to clinician to support treatment process PTSD explorer plumbs application to capture data on tool participation, symptom self reports, support types, coping and medications---data are byproducts of use Building Infovis data processing modules that extract features from data for clinician -- trends, correlations over time, across parameters, with noisy gappy data Enable iterative innovation for clinician. Not data exploration during your patients all too short session but facilitated flexible config of dataviews for clinician, cohort, condition Enable continuous iterative improvement itself informed by analytics....why should websites be more scientific and data driven than clinical practice?
- same process, arch, tools for many patient facing mhealth applications overall architecture elements: The third party data applications and stores -- mHealth applications store and manage data, -- this is where ptsd coach and explorer sit data processing units (DPUs) building blocks for extracting relevant features from data streams, Data Visualization building blocks for creating presentations of data, Infographics that might be created specially to tailor the look of the user interface, and a local cache for performance. Goal-- support distributed community building applications with best available software components. not a data repository, not hosting the data, not THE common software platform running on mobile devices openmhealth community members will integrate software modules into their own platforms. **complementing and integrating with their own "secret sauce" components. modularity facilitates adapted, modified, personalized data views as clinical practice evolves All about economy of scale--jointly advance general purpose components--advance in function, accessibility, usability, affordability the way our web tools have , rather than at the pace of traditional siloed clinical tool
- Josh Selsky chief software architect; informal community advising; initial core developer team jeroen ooms and mark schwartz Modularity--each DPU does one task...compose for higher functions. rough consensus and running code not a priori standard setting---define DPUs data input and output formats as part of the DPU interface. well-documented interfaces allow chaining DPUs to create higher level, correlated features -- F(g(h))....for example, noisy gappy data
- data visualization can be modularized and reused across applications combine to create specific interactive, configurable data views -- zoomable timelines, maps not trying to be mhealth service or portal…DVUs embeddable in third party mhealth applications Modules that you can integrate into your platform...use to build your repository... monetized innovation happening above these reusable components…resulting volume of visible innovation much greater. built quickly, efficiently w/ other open standard tools -- HTML5 and Javascript
- Sensemaking, fine…modularity, fine….why is it so important that we do this open? Goal -- vibrant decentralized community of users...benefit from open architecture...therefore contribute to it. Openmhealth allows individual innovators to avoid wasting resources reinventing the wheel; spend resources on innovations above (new apps, biomarkers, treatments, interventions) and below (wireless health devices) -- net innovation of market enhanced. Pays not to fork--john mattison of kp: discipline makes institution in better shape to adopt external innovations over time. Weber on open source....recommended by karl brown and retweeted by me. components reused by community grow in validity, robustness , efficiency, interoperability--original creators benefit--the reason to not fork.....holds the community together Open has great potential to catalyze innovation and shared learning fueled by evidence generation.
- To advance science and practice of mHealth, the sensemaking has to be brought to bear on scientific questions in scientific way- As science advances the feedback loops will be powered by the resulting evidence and models. Pass it over to Ida to talk about the Personal evidence architecture that will help to close and enhance these loops…
- ･ When we say we want to advance the "science and practice" of mHealth, one of the biggest questions we need to answer is whether something "works" or not. ･ For example, does Text4Baby work?
- ･ When we say we want to advance the "science and practice" of mHealth, one of the biggest questions we need to answer is whether something "works" or not. ･ For example, does Text4Baby work? That's an imprecise question though. It should be rephrased as a statistical question, about the strength of association between being "exposed" to Text4 Baby and some outcome we care about, like increased breastfeeding. ･ We can be interested whether Text4Baby works at the population level (in teen moms) or whether it works for an individual (does it work for me ).
- ･ Most of the time in clinical research, for example in a randomized controlled trial, we're asking questions at the population level. ･ So to see if PTSD Coach works, we randomize say 100 people to PTSD Coach or to usual care and see on average if PTSD Coach works. ･ The problem though is that none of us are average – even if PTSD Coach works on average to reduce PTSD symptoms, it might not work *** for me***, or conversely it might not work for the average person but may work great for me.
- ･ The only formal method for answering "does it work for me " is the N-of-1 study design. ･ In which there's only 1 person, 1 "n" in the study. So I would be randomized first to PTSD Coach, then usual care, and back and forth a few cycles, assessing my PTSD symptoms along the way. ･ This method is not widely known and is statistically complicated, but offers the kind of personal evidence we need to drive systematic but personalized learning across mHealth
- O Our Personal Evidence Architecture aims to make it easier to answer questions scientifically, starting with individual-level questions . Patients and clinicians will be able to define a question, set up a study using say an n-of-1 study template, run the study as an app, and on the backend, it will use InfoVis to do the data analysis and feedback as you heard Deborah describe earlier.
- * And once we have evidence from many individual n-of-1 studies, we can essentially flip the traditional direction of research inference on its head, aggregating individual-level evidence to get at population-level evidence, rather than the other way around
- ･ We are focusing now on building out N-of-1 scripting and analysis, and identifying a small library of high-value shared measures. We're looking at some of the measures in NIH's PROMIS project, for example, but there will also be a need to develop and validate measures specifically for the mHealth context, in which self-report data can be collected several times a day rather than once every 3 months like in many traditional measures. ･ For aggregating evidence, we are exploring a shared set of context meta-data tags, to capture the context about the variable and about how the data was collected, for example the OS and version used, the app version, etc. Context meta-data is critical to ensure that data and evidence can make sense together as well as separately
- That's a quick tour of our InfoVis and Personal Evidence Architecture work. Now David will tell you about our other project activities and how you can get involved.
- We want to pinch the siloed mHealth applications at the waist to create a scalable, open architecture.
- We have some successful open source predecessors in our midst. that play an important function in advancing health IT. From OpenMRS’s medical record system to ODK’s data collection tools, each play an important function and role in this advancement.
- Today OpenmHealth is needed to advance mHealth by increasing the speed, innovation, exploration, and effectiveness of mHealth sensemaking.
- Open mHealth’s mission is to tip the current mHealth ecosystem to achieve greater openness, integration and evidence in order to improve individual and public health.
- We’re going to do this by: Catalytically convening an open community to design, develop, test, generate evidence and share their learnings from using the Open mHealth architecture. Allowing innovators and entrepreneurs to focus on their unique market offerings while increasing the validity, robustness and effeciency of shared components and methods. We want mHealth to scale by saving the mHealth community time and $$. Flipping the direction of research inference on its head by generating population-level evidence from personal evidence.
- Open mHealth is a 501.3c that just began its work on September 1, 2011. We’re able to achieve our mission through funding from RWJF’s Pioneer Portfolio and the California Healthcare Foundation. We’re honored to be hosted by the Tides Center.
- In order to achieve our mission, we are using an integrated approach to bring together developers and health innovators to develop code and drive more use cases along the open mHealth architecture.
- Photo: Tapping the Table Board, Fosdem ’ 09, Free and Open Source Software Developers’ European Software Meeting 2009. Creative Commons License These developers we’re referring to include those that work for small startups, technical architects, hackers, and those from the open source community.
- Photo: UN Foundation, 2011 Health innovators are those health experts that understand the problem. They own the problem. They might be a clinician, researcher, institution or patient group that has an app or project and want to use the OMH architecture.
- These user groups do not suppose that other user groups are not important. Focusing on one group will not benefit OMH or the mHealth space. There’s no benefit to health innovators alone if there’s no one to build solutions for them. Likewise, there’s no benefit to developers if there’s no one to assist in knowledge sharing on specific health subject matters. The intersection of these user groups is critical for anything meaningful to happen in mHealth. We want to break the barriers between developers and health innovators by building an active and productive community.
- Technical contributors and users of Infovis modules and other aspects of architecture. INFOVIS EVIDENCE BUSINESS MODEL
- We’re going to start monthly Google+ meetups for those interested in discussing the Open mHealth architecture, projects, etc. Go to our website, www.openmhealth.org for email updates about this and other related Open mHealth news.