Health IT and Electronic Health Activate your FREE membership today |  Log-in

Community Blog

Aug 21 2013   10:18AM GMT

Avoid making your mobile health app a PR disaster



Posted by: adelvecchio
mhealth apps, Mobile applications, Patient portals

th_1375478863_landman2Guest post by Zachary Landman, M.D., chief medical officer, DoctorBase

It’s quite clear that patients and physicians alike are demanding mobile access. “A mandate has been issued and progressive vendors are reacting,” reports Doug Brown, managing partner of Black Book Market Research, in response to a growing body of evidence suggesting fast paced growth in the mobile application industry. No matter what metrics are cited, whether it is a 500% increase in mobile healthcare applications by the end of 2014 to predictions of 500 million mobile healthcare users by the end of 2015, the market is growing extremely rapidly. In fact, the federal government just released the Research and Markets mHealth trends report that shows the industry is poised for a compound annual growth rate of 61% by 2017, ultimately reaching a value of $26 billion.

While rushing to address patient and physician concerns, numerous healthcare vendors have delivered patient portal applications that are poorly adopted and receive scandalous reviews. This has damaged their brand and caused irreversible harm.

John Sung Kim, CEO at DoctorBase, which specializes in mobile portals and patient engagement, notes that “many healthcare provider organizations, being new to the world of smartphone apps, don’t fully comprehend the amount of marketing, testing and UI [user interface]/UX [user experience] that needs to go into the successful rollout of any business-related app.”

Take, for example, two large industry titans who recently unveiled their mobile portal applications in the iTunes store. Without delving into the specifics of each application, four main themes of failed portal application rollout are evident.

Branding – The name of the healthcare portal may appear to be an insignificant aspect of the overall development. However, when 63% of users find the apps they later install by searching the App Store for a specific app, naming becomes of the utmost importance.  For example, a large West coast healthcare vendor recently released an app that goes by an acronym that is also a commonly searched term on urbandictionary.com, where it means vigorous intercourse — probably not the best way to engage the next generation of patients.  Furthermore, the app is being aggressively marketed in digital and print media as the acronym.

The app’s logo in the iTunes store simply displays the acronym, which would be fine, except that when patients go to search the acronym, no results populate. This is because in the iTunes store, the app is listed under its full name. As you can imagine, it is a PR nightmare. After significant development and marketing expenditures, the app has had poor patient adoption and an (unfriendly) viral campaign regarding its name — not the best way to kick start your mobile platform. The most effective ways to sell your product is to be simple. You should instill a sense of trust, health, and empowerment in your customers, and your product should be easily searchable.

Usability –Frequently, mobile applications are too difficult to routinely use. While security is important, complex and lengthy registration requirements requiring novel usernames and passwords not only lead to fewer single-use registrations, but they lead to far fewer re-engagements as patients misplace or forget their credentials. Health vendors, physician groups, and any other group marketing healthcare apps looking to steer patients toward mobile communication should clearly direct patients to the portal or download link on the welcome page. That should be followed by a seamless registration process that permits integration with previously created social media sites such as Facebook, etc. The longer and more difficult it is to register the first time, the less likely it is that patients will revisit.

Functionality – The key to any mobile portal or application is its substance. How and, more importantly, why patients access your portal is a fundamental question. Communication is a key issue that I hear about time and time again from patients. Medical records and lab results are nice features that are rarely used. Without context and guidance, they’re meaningless, anxiety provoking or worse. Patients want to communicate with their physician, physician’s extender, and the office.

Appointments, questions, and advice are all fundamental aspects of true portal functionality. However, true functionality also implies adoption by the provider team and a system of closed loop communication that confirms patients received the information and services they desire. Before rolling out a patient-focused app, significant time and energy should be spent educating the healthcare teams responsible for how mobile messaging will improve their care and save time and money.

Reliability – This is simple. Rolling out apps prior to sufficient end user testing only leads to disasters. Develop. Test. Beta Test. Run it on multiple platforms. Use target audiences. Limit questionable features at the outset. Users are incredibly skilled at finding flaws and breaking your product. Users are the “Jedi” of mobile app crashers. Regardless of the number of tests or how many iterations of testers were used, they will somehow use “the force” to find flaws in engineering and coding. And as we all know, a crashed app will lead to angry users and a tarnished brand. Patients correlate errors in IT with errors in medical records, electronic communication, and substandard care.

While there is no magic bullet for effective mobile app creation or marketing, following certain principles will help avoid common and damaging pitfalls. Use commonly searched and appropriately spelled words for improved app store searchability, limit user registration to fewer than three clicks (four at the most) to limit the amount of end user activation energy. The development timeline should be geared toward a multiplatform user experience, and you should ensure that it’s safe, secure, and reliable.

Zachary Landman, M.D., is the chief medical officer for DoctorBase, a developer of scalable mobile health solutions, patient portals and patient engagement software. He earned his medical degree from UCSF School of Medicine. As a resident surgeon at Harvard Orthopaedics, he covered Massachusetts General Hospital, Brigham and Women’s Hospital and Beth Israel Deaconess Medical Center.

Comment on this Post

Leave a comment:

rp85  |   Aug 21, 2013  12:02 PM (GMT)

Excellent and insightful article.  It’s sad that a number of pervasive and prominent professions and service industries, such as medicine and law, so grossly lag behind the technological advancements made by other industries, such as finance.  Moreover, the access and intimacy that mobile applications stand poised to facilitate in the field of medicine carry with them a special capacity to improve the experience of the end user vis-a-vis other industries; see, supra.  I’m glad there is a talented mind out there approaching the problem from a practical and creative perspective.


 

KevinBeaver  |   Oct 6, 2013  5:54 PM (GMT)

Great info Zachary.

I wanted to remind everyone to not forget about the importance of
testing the security of their mobile apps as well. As I explain in the
following post, this is a *huge* oversight that’s creating unnecessary
security risks and compliance gaps:

http://securityonwheels.blogspot.com/2013/02/mobile-app-security-assessments.html

I can hear it now: “We’re HIPAA compliant…except for those mobile apps
that process/store PHI that no one in IT, security, or development
bothered to test for security flaws.” #oops

That said, now that our imperial federal government is 
going to regulate certain medical/healthcare-related apps, I’m sure
everything will be fine.


 

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: