With Day 1 of mHealth wrapped up, I’d like to share my thoughts on some underlying themes and takeaways from the sessions and presentations I was able to catch. Specifically, I was able to attend sessions on shaping care coordination with mobile tech, chronic disease management, and wearable tech and fitness devices, as well as a few short presentations at the NIH pavilion.
Following his talk on mobile clinical decision support tools, Robert Furberg mentioned the need for a reconciliation between the speed of technological developments, and seemingly glacial speed of science to adequately and appropriately adopt such develops. While there is a growing recognition for the need for tech integrations such as that mHealth seeks to promote, the scientific and healthcare communities are not always adhering to set guidelines, standards, and best practices in science and medicine when adopting new technology.
Today I was reminded of the impact mobile technology can, will, and is already having on health improvement, healthcare delivery, and healthcare costs (and the list goes on). From mobile tool kits utilizing tablets for administering patient questionnaires, reminders, and messages, to gaming approaches to health interventions, each presentation discussed how mobile can bring solutions to issues that were once too complex to efficiently and effectively address. The reason this is possible is because mobile is where a majority of us have consolidated several everyday tasks, including one of the most natural tasks: communicating. And where we communicate is where we exchange information (i.e., data). In fact researchers from a variety of disciplines are facing the same reality (several of which we discuss in our new book as it relates to survey research).
So if we’re all in a agreement that a trend toward mobile solutions is a necessary one, what are some of the more immediate hurdles we face that are keeping us from getting to a world where, as one speaker put it, “mHealth is as taken for granted as the internet is today?” Well, in my opinion, a more ubiquitous mHealth means seamless integration as both an experience and a process.
Personally, given my work with creating and developing applications for data collection that utilize Facebook’s API, I was happy to hear the term “user-centered design” and “APIs” in some of today’s presentations. Specifically as it relates to mobile applications, I feel these are where the experience (user-centered design) and process (APIs) seams exists:
User-centered design: How can information be collected and utilized in ways that promote things such as application use, response rates, and decrease things like application fatigue? At the NIH pavilion in the Exhibit Hall (a cool way of adding on short presentations and demos BTW! It’s not candy or trinkets, but a giveaway that will last a lifetime – knowledge!), there was an underlying theme I noticed in the short 10 minute presentations – user experience (UX). Seamless integration into the mobile experience is critical to service delivery and the collection of data, which means objectives such as message delivery for behavioral interventions (e.g., smoking cessation, exercise, or diet monitoring) can potentially hit on all cylinders except UX, and produce results that are ineffective. So if your application isn’t gaining any traction, consider how the end-user feels. And remember, superb functionality for a researcher does not always mean a superb app for the user!
In his presentation, Furberg noted that the decision support tool was well received by its users, and that to optimize effectiveness of such apps, researchers and developers should also concern themselves with APIs (application programming interfaces).
APIs: Why are APIs important? Understanding API structures can mean the difference between optimizing systems communication and having a smooth transfer and utilization of data for all stakeholders, and a clunky system everyone complains about. When platforms can effectively speak with one another, researchers can efficiently and effectively obtain the information needed. This goes for any process that receives, disseminates, and utilizes data. This could be a survey instrument collecting and sending data to a server, which then goes to a case management system where it is analyzed in ways that improve survey delivery, and in turn, data quality. It could also be a mobile app intended to collect patient data to successfully implement guidelines for physicians as they care for a patient, and having that data shared with administrators, and possibly even researchers for longitudinal tracking.
That’s all for Day 1 – I look forward to hearing and seeing what mHealth has in store for Days 2 and 3!