There are an estimated 15,000 medical apps presently on the market and is expected to grow 25% per year according to one study. There are issues which are common in the development of these apps and other categories of apps. However, some technical and non-technical issues are unique to the sector. As someone who does not design apps, I will offer a perspective which covers topics raised by different stakeholders concerning medical app development which might be of interest.
1. The motivation for the app development is misguided. Regardless of the elegance, ease of use, enjoyable experience, or other appeal of a health app, if it does not address a specific problem, it will not be considered useful and subsequently not adhered to. Just monitoring a physiologic parameter, a person’s mood, or collecting data because an app is able to do so is a recipe for failure. People searching for health apps (and health information in general) are likely doing it because of a health problem. Data must be collected and filtered in a way that it translates a message to the end-user, whether that be a patient or clinician.
2. Lack of clinician involvement. I am not saying here that clinicians need to be CEOs of mHealth companies. What I am alluding to is the lack of clinicians’ input at all in the development of many of the technologies. Technologies do not operate in a vacuum. There are processes that the technology fits into which might very well need to be totally redesigned around the technology (this is a good thing, for many processes need changed). These processes may range from someone’s personal schedule to instituting hospital case managers who advise patients on mobile apps. The app cannot be dropped on the lap of a CIO or clinician and be expected to be successful. Connectivity of mHealth tools will be an important aspect of stage 3 of Meaningful Use adoption. This connectivity will necessitate workflow of data and messaging between patient and clinician. It is imperative, therefore, to have clinician input into the design of the technology.
3. Poor attention to usability. Achieving the final construction of an app must include an in-depth consideration of the experience a user with the need for the app has. According to a guide to evaluating usability of medical apps by HIMSS, usability may be defined as “the effectiveness, efficiency and satisfaction with which specific users can achieve a specific set of tasks in a particular environment.” I chaired a session at the most recent mHealth Summit on the topic of “What goes into making an extraordinary mHealth app?” which can be found at the bottom of this link. There are great presentations discussing app design and user experience.
4. Not knowing the healthcare landscape. Knowing the healthcare landscape is critical to determining a strategy of adoption. What are the available technologies that address this app’s goal? How can this improve or add to them? Can the technology be used by multiple stakeholders? Might it be best to partner with another company to distribute or co-market my tool? Is my technology more valuable when incorporated into another offering (partnering with another technology)? Is this tool something the payer, provider, or patient would use/purchase (which provides the best/easiest path to sale/adoption)?
5. Not building to regulatory specifications. It doesn’t matter how much wow factor the app has, if it doesn’t meet regulatory requirements [re: security, HIPAA, FDA (if necessary)], it will need to be reworked as a significant cost. New proposed regulations regarding handling of data from apps might affect development as well and these should be followed in the news closely. Of course the FDA final guidance document is anxiously being awaited. Aside from regulations, developers might want to look at Happtique’s draft standards for their app certification program. The final standards are forthcoming.
In summary, building code is a small part of developing a health app if one wants to be successful. It should be seen as a process with many layers requiring attention. Selling an app does not translate to adoption. Selling a good app improves its chances dramatically.
Good commentary. Four years ago the mobile app rage was akin to the dot.com frenzy — until folks realized it had the same amount of misguided hype. I read a recent study revealing some interesting stats such as, on average if someone uses mobile apps, they have approximately downloaded 12 but only use 2 to 3. With 5 million apps currently and growing without any real barrier to entry, and 150 K of them medical apps, the probability of exposure is mind-numbingly small and the probability of regular use even smaller. Worse is the limitation of screen size but worst of all is that apps are very limited in terms of delivering much more than content (again the dot.com effect). As such, apps have fallen (like dot.coms again) to the advertising revenue model-meaning the info is “free” but not necessarily reliable.
I am a supporter of apps as a solution but I believe the promise is a long way from being realized. We are likely to see a dot.com like bubble in the app market until high speed analytics integrates successfully with apps so they become more than just obnoxious freeway billboards.
I agree, Michael. There will be a bubble, then a stabilization with many quality apps. The comparison with dot coms is appropriate, in my opinion. This industry is going to be a critical portion of healthcare. The adoption barriers, successes, and contributions to society with mimic that experienced by the
Internet. I believe that mHealth is tied to healthcare IT in the same manner: http://davidleescher.com/2011/10/27/mhealth-and-healthcare-it/.
Thank you for your thoughtful comments, Sudan and Kathleen.
My comments on yet another helpful, useful blog:
1. You would think that this is common sense but it doesn’t seem to be. I agree with you 100%. I just cannot believe some of the apps that are gaining popularity.
2. Again….of course I agree. I do think that building a team is so important in this arena. mHealth is trying to address complicated problems and it needs input from many different areas of experience and expertise. How about technologists that don’t include the patient in the conversation?
3. Thank you for the link. I believe if you get the UI nailed it is at least 50% of the work. If you don’t get the UI nailed you have no app. No matter how pretty, if people cannot use it, the app is useless. I think this may be the number one thing that app developers don’t get.
4. I am guilty of this one and have paid the price. The healthcare landscape is a complicated and rocky road.
5. I feel that the industry needs regulatory requirements. I believe that if you show us the rules we will try to comply. At this point the “rules” are not set down in a meaningful way. We stay guessing and it creates huge anxiety. And by the way the entity that needs to know the rules most is not the developer but the hospital IT.
And finally David thank you for shining a light on the rocky road so that we are not breaking our ankles. As usual you ROCK.
I agree completely on all five point (and you indirectly demonstrate a particularly sophisticated understanding of design, its value, and its context). From a design perspective these pitfalls boil down to the failure of traditional product development.
Traditionally product development involves engineering and marketing. Someone to make the widget, and someone to find buyers for that widget. This is both insufficient and incomplete.
Disciplines are guided and blinded by the particular sets of questions that their methods are optimized to answer. Engineer asks questions of feasibility. Marketing asks questions of viability. Neither ask questions of usefulness — and neither have the methods to ask the question appropriately (marketing’s reliance on focus groups and voice-of-the-customer are perfect examples). This is where design comes in. Design asks questions of usefulness, usability and desirability and has the methods to so.
An illustration of an integrated new product development model:
http://www.spireinnovation.com/gifs/inpd.gif
But in healthcare even including design isn’t enough. The domain is so large, so complicated, so diverse that even when your engineers, marketers, and designers have deep healthcare experience, you still need clinical. Mere feedback is insufficient. Clinical experience must be part of your solution’s DNA.
So as a designer having focused on healthcare for the past 7 years now, I can say that these are common pitfalls that trap even folks with the best of intentions. I can also say that letting healthcare experienced designers and clinical lead early solution definition will help your avoid nearly all of them.
I appreciate your expert perspective as a developer, John. It sounds like you understand how healthcare differs. I liked the illustration very much.
Pingback: Five Pitfalls of Designing a Medical App - The Doctor Weighs In | The Doctor Weighs In