#wwdh What Works in Digital Health?

Random notes from the “What Works in Digital Health” workshop:

  • Personal Tracking as Health Informatics (paper)
  • There’s no such thing as gaining a pound (paper)
  • Trajectories of depression (paper will soon be here)
  • A wicked problem is a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize.
  • Root cause analysis is a method of problem solving used for identifying the root causes of faults or problems.
  • Action research is either research initiated to solve an immediate problem or a reflective process of progressive problem solving led by individuals working with others in teams or as part of a “community of practice” to improve the way they address issues and solve problems.
  • My slides on Data Science in Digital Health.
  • Beyond Personal Informatics (workshop)
  • Man vs. Smart House: A Cautionary Tale (video)
  • Formative vs. summative assessment (definitions)
  • The tea cup stretch.
  • HANDI “Supporting the Architects of the Digital Health Revolution”
  • The UK dallas project is thinking beyond traditional health and social care to consider how new ideas and technology can be used to improve the way people live.

Notes from @RoyalSocMed #telemed Event

Brief notes and links from Mainstreaming medical apps; reducing NHS costs; improving patient outcomes event at the Royal Society of Medicine.

  • 90% of apps are not used after 6 months. 80% of apps do not generate revenue to support a business. 500 million people will use a health app by 2017, a soon to be $26 billion industry. >80% of surgical trainees use a mobile phone at work. Why do people not use health apps? 37% the sheer number of them is confusing. What would convince you to use a health app? 50+% if the app is free.
  • Depression will be the largest cuse of disability by 2020 (WHO). £105 bn annual cost in UK. 75% of those with a diagnosable mental illness receive no treatment. People with poor mental health die 15-20 years younger.
  • EC green paper on mHealth (April 2014).
  • A study of the content of 47 smoking cessation apps shows an inverse relation between app popularity and behavioural evidence; here is a similar paper for chronic pain management apps; for melanoma diagnostic apps; for opioid conversion apps; a study evaluating the content of cancer apps.
  • The HSCIC is the national provider of information, data and IT systems for commissioners, analysts and clinicians in health and social care.
  • Our Mobile Health reviews and tests medical apps.
  • Orange is into healthcare? @orangehcare. mHealth grand tour trial on real-time feedback and monitoring of glucose levels in diabetics.
  • Phones grow all sorts of bacteria.
  • Seven deadly sins of app development: (1) inequality in app availability vs incidence of disease, (2) lack of expertise; no medical specialty involvement in app development, (3) plagerism- copying information from the web into an app, (4) commercial bias/interests- apps with no consumer reviews, promoting private practice, (5) inaccuracy and errors e.g. in melanoma detection and calculator apps, (6) lack of security & confidentiality, (7) lack of testing, evidence to support effect (e.g., this review, and this paper).
  • Behaviour change COM-B framework (Capability, Opportunity, Motivation); 93 behaviour change techniques have been grouped in this paper.
  • MyHealthApps: patients helping each other find apps that are useful to them.
  • BCN Health App were demo’ing their TCApp for eating disorder management.
  • The Alliance of European Life Sciences Law Firms. What is a medical device? Includes software intended by the manufacturer for diagnosis, prevention, monitoring, treatment or alleviation of disease. Yet “stand alone software for general purposes when used in a healthcare setting is not a medical device.” Yet…
  • “Medical device stand-alone software including apps” UK guidance online. “Mobile Medical Applications” US FDA guidance online.
  • Patient view: compliance = automation + simplicity
  • Big White Wall 27k members, 27% of UK adult population covered in contracts
  • Prof Meddis (Essex): anyone that can command an iPhone can produce their own hearing aide. Here is BioAid.

Extracting Large Datasets from the Google App Engine Datastore

The Google App Engine (GAE) is a very interesting service for quickly deploying web apps or building systems that use Google’s infrastructure. I’ve recently been working on a project that uses the GAE to receive large amounts of data from a mobile app that is part of a feasibility trial with 20 or so participants. Therefore, the two key things that I wanted to accomplish are (a) getting a back-end that receives/processes/stores data up and running as quickly as possible and (b) having a way to extract/download the data for offline analysis. The GAE was perfect for part (a), and the system was set up: the data that rolled in was easily stored in the NDB data store.

Now the headache: getting data out of the system. What ways could this be done?

  • Don’t even try: using a front-end request handler. These are limited to 60-seconds, hardly enough time to read through/format/process a large datastore.
  • In the old days, it was possible to back up data from the developer console. This limits data extraction to admins only, which is not ideal. This post describes how this was done, and worked for me… until the console was upgraded and the ‘Backup’ functionality was removed (does anyone know where it is?).
  • The bulkloader. This post describes how to use it, and I got this working. Simple and command-line based. Hours and hours later, the bulkloader was still trudging along and would then fail, which seemed to happen if my machine momentarily lost it’s WiFi connection. I didn’t see any way to modify how the bulkloader throttles data download; so I’d only really suggest using this method if your data is very small.
  • Using the remote API shell, and paging through the data store entities. I got this working too, and this seemed to be faster than the bulkloader.. but would hit some over quota limits after some time (even though my project has billing enabled). Again, probably ideal for small data, and admin-access only.

What I did in the end was inspired from the post that wanted me to start the backup from the admin dashboard:

  1. I found this post that explains how to transfer data from the data store to BigQuery. What it is actually doing is transferring data from the data store to the cloud storage, and the uploading it from cloud storage into BigQuery.
  2. I wrote a map-reduce job that does the same as the first part of that post. The problem I encountered was that the example and  all the documentation points to using the “FileOutputWriter” in “mapreduce.output_writers” which does not exist anymore (therefore producing ImportErrors). By digging around the code, I found that I could replace it with “GoogleCloudStorageConsistentOutputWriter”
  3. I ran the map-reduce job by hitting the URL with a get request. My code then redirects to the mapreduce status page. The whole thing took approximately 10 hours to complete.
  4. I downloaded the data using gsutil (the -m flag enables multithreaded downloads):
    gsutil -m cp -R gs://my-bucket/my-dir .

2014 in Review

My last year in review ended with “I think that 2014 is going to be a year of prioritising and getting things finished.” I think I (mostly!) managed to do just that, with most of my work this year focusing on one project, Emotion Sense. My #YearInReview:

  • Most of the year was dedicated to analysing our growing Emotion Sense data and our results are now taking shape. Gillian presented our first poster. There is so much more yet to come from this; I hope that my 2015 year in review will have this as its first point.
  • We received a grant from the EPSRC’s Impact Acceleration Follow-On Fund, to help turn Emotion Sense into a commercial product for healthcare measurement, monitoring, and intervention. Emotion Sense has also been accepted as an i-Teams project which will kick off in early 2015.
  • We received funding from the Medical Research Council to test and further refine Q Sense: a smoking cessation intervention that (building from Emotion Sense) uses smartphone sensing to guide quitters on a personalised, data driven journey away from tobacco. Felix presented a poster about the project as well.
  • A paper about group co-location in social networks – lead by Chloë – was published in PLoS ONE (arxiv link).
  • I submitted/published a book chapter on “The Anatomy of Mobile Location-based Recommender Systems” (preprint) for the upcoming second version of the Recommender Systems Handbook.
  • I (finally?) published some old work from my time at UCL on crowdsourcing public transit status updates via a smartphone app (pdf).
  • Advait published the results of his masters project analysing shared bicycle systems around the world in an upcoming special edition of Transportation (Special Issue on Emerging, Passively Generated Datasets for Travel Behavior and Policy Analysis).
  • I gave talks in the SACHI Group (University of St. Andrews), Institute for Public Health and Dept. of Psychiatry (University of Cambridge), the E-Health Unit (University College London), and the Dept of Primary Care and Dept. of Education (University of Oxford), at Health 2.0 London, and at Data Science London’s Healthcare hackathon. Every talk was about smartphones (e.g., these slides).
  • I did less consulting work than last year, but what I am doing is more on track with my other work (… smartphones!).

I guess that the trend should continue: I hope that 2015 is going to have Emotion Sense written all over it.

Random Links from #health2eu

I’m at Health 2.0 Europe: London November 10-11. Brief, brief notes:

The “From Health to Wellness” non-auditorium session (where I presented about Emotion Sense).

Easy M: Experience Sampling with Smartphones

Since launching Emotion Sense, I have received a number of e-mails from people who would like to conduct studies or build apps that collect similar kinds of data:

  • Momentary Survey Responses: answers to questions about the moment that the person is in. How happy are you? How focused are you? Where are you? Or, indeed, any of the other kinds of questions that are typical of the experience sampling method.
  • Smartphone Sensor Data: it is increasingly well-known that smartphones have a variety of sensors that can be used to characterise a person’s behaviour and environment. Here is a paper (pdf) that I wrote about that very topic. What are a participant’s GPS coordinates? What are their calling and texting patterns like? And so on.

The main challenge, however, is building this kind of software. This takes time, money, and a lot of programming/design effort: precious resources that are not widely available. Moreover, it is impossible to ‘use’ the Emotion Sense app for anything other than what it was built to do: collect data about positive/negative mood (via the very specific questions that we have chosen) while taking users who download the app on what we have called a ‘journey of discovery,’ as they unlock feedback screens while they use the app.

In essence, Emotion Sense isn’t useful for others who are interested in doing similar kinds of research. There are two directions that I can take this: (a) building new, specific apps on a case-by-case basis, or (b) building a new, generic app that tries to suit the broad needs behind doing this kind of research. While I am pursuing both of these paths, this post is about the second, (b).

I have spent a few months working on a new app: Easy M. The app essentially takes all of the pieces of the Emotion Sense puzzle (indeed, it also uses the same open-source code) but has reshuffled everything into an app that can suit others’ needs. The idea behind this was to build an app much like the fantastic MyExperience toolkit, which unfortunately is only available for ‘old’ Windows Mobile devices.

The Easy M app is now online on the app store, and we are soon going to launch the first studies that use this tool. The way this works is (hopefully) simple: your users download the app, put in a code for your study, review what it is they are joining (in terms of data collection) and after giving their consent, the app automatically reconfigures itself to do everything you need: ask the questions that you want, and collect the sensor data that you would like to focus on. Once your study has run its course, the app logs your users out of the study and makes sure that any pending data gets sent up to the servers.

The online documentation includes most of the details about what this app can and cannot do. In particular, there is currently no way for you to use the tool without getting in touch with me, so that I can set up the appropriate configuration files for your needs; the data also comes to our servers to then be transferred to you. As I develop the tool, I hope to add many of the missing bits — for now, I’m interested in hearing from you if this is the kind of tool that you would like to use in your research.