Mobile health digital applications are discrete programs or platforms that are usually designed with one goal, whether it be for the maintenance of health, the utilization of a diagnostic method, or the achievement of a therapeutic goal. Ultimately, these apps (I will call them apps for the remainder of this article for convention) will change the way healthcare is both viewed (pun intended) and, I wouldn’t say delivered because of the one way connotation of the word, but experienced. However, the technology as it is being developed now is very disjointed and not intuitive with regards to clinical workflow or patient management (I will, for the remainder of this article, be referring to people with chronic diseases or post-hospital discharge, not people seeking help with wellness). I believe that mHealth technologies need to learn from the growing pains being experienced now in the EHR business. People in mHealth should be following developments in the EHR space because many of the pain points being felt there are the same for mHealth. Slowness to adopt (even in the face of government mandates and incentives), and interoperability are the key ones. Technology compatibility with workflow is one of the biggest issues preventing easy adoption. What follows is my ‘wish list’ as both a former clinician and mHealth evangelist that I think would catapult the technology from a convenience to a ‘can’t live without’ level.

1. Mobile health apps should, as best as can be accomplished, exist on the same technical platforms. This will facilitate interoperability and convenience for the provider, payer, and patient. The interoperability will need to take place both among the various apps (presumably patients will be utilizing more than one at a time for a given clinical condition) and between the apps and the EHR. This type of cooperation can take place via existing standards or those to be proposed via organizations such as HIMSS or the IHE.
2. Diagnosis or goal-based batch loading and programming of apps. This is a follow-up to the previous suggestion. Once a diagnosis or post-hospital discharge plan of treatment is established, one-touch programming allows the predetermined (this can be established by protocols developed by specialty societies or automatically be done based on a combination of predictive informatics and/or specialty society guidelines (see http://davidleescher.com/2011/09/30/can-moneyball-become-moneycare-how-predictive-informatics-can-make-mhealth-a-success/). All the apps are populated with the patient’s demographics (and, if requested, that of the caregiver) simultaneously. This batch prescribing is done via the patient’s EHR either in the office or in the hospital or other medical facility pre-discharge, and shared with all providers in the ACO if it exists, or by the social worker in all pertinent facilities (rehabilitation, assisted living, pharmacy, primary care provider, etc). If there is a conflict among the apps with regards to scheduling, compliance issues of one which would affect another, interactions, patient progress, it will be transmitted automatically among the various diagnosis-related apps. They will remain on the same ‘page’, that of the patient’s clinical progress. The patient may be observed in this manner by providers remotely, preventing office visits and hopefully hospital admissions and ER visits. Moreover, it will allow for a more coordinated care than is presently observed (personal experience as a physician).
3. Superimposition (for lack of a better technical term by a non-techie) of apps. What do I mean by this? Imagine an mHealth app superimposed on ‘Google maps.’ A patient or caregiver can automatically get directions from the doctor’s office to the pharmacy or rehab facility. Sensor technology from different apps obtained simultaneously and recorded on one graph, spread sheet, or report, overlapping. What about the timing of a medication (done with a medication adherence app) with a change in respiration determined by another app, signaling a possible adverse reaction? This kind of interaction among apps gives a greater depth and meaning to the data obtained.
4. Incorporation of mHealth technology with implantable medical devices or organs. Sure there exists remote monitoring of implantable defibrillators and pacemakers to monitor device system function integrity and heart rhythms. But what about pressure sensors in hip replacements to detect faults before they occur? What about microbiosensors to detect inflammation in transplanted organs? Or staples or sutures with sensors to detect leakage? I’m quite sure these things are being contemplated, but the idea is to make mHealth technology work within medical practice and flow. These are things to make what providers do easier, not necessarily invent new wheels. The new wheel research is certainly needed, but it’s easier to reshape the wheel with new technology (especially in this business and regulatory environment) than invent a new one.

These are just some not so random thoughts I had when attending a technology trade group conference listening to how the government of PA is reshaping its IT model. I’ve learned that medicine can always learn from other sectors about the use of technology. Let’s go get ‘em!