Annual Check-up: mHealth Apps are Still in Critical Condition – Part II: Limited Functionality for mHealth App Features

Michael Scranton

Michael Scranton

Posted on August 01, 2017

For background on the mHealth app study, and the utilization of apps in hospitals and health systems , please be sure to read Part I of this series: Healthcare App Development Market is Not Meeting Patient Needs.

Why Hasn’t Hospital App Development Been Able to Overcome this Major Hurdle?

Perhaps one of the most important findings from our research is that similar functionalities can vary greatly from one health system to the next; hospital app development is not consistent across all health systems. This means, for instance, that an appointment request feature in Health System A could be markedly different from that of Health System B. The different workflows, designs and integrations to Electronic Health Record (EHR) or Revenue Cycle Management (RCM) systems produce unique user experiences for each app. These differences are not minute and can be easily observed by everyday users. Even the set of features provided by each app is vastly different from the next.

Across all of the branded mHealth applications evaluated, we identified four distinct categories of app features used by healthcare and hospital app development companies:

    • In-app (integrated) – native in-app features that connect to push and/or pull data from other health IT systems within the mobile app
    • In-app (not integrated) – native in-app features delivered in the app itself that do not require integration
    • Linked out – features that take the user out of the app to a separate application
    • Browser-embedded – hybrids of integrated and linked out, features that do not take the user out of the app but do open a browser window to connect to a different system

In App Features: Integrated and Not Integrated

mHealth App
In-app features, both integrated and not, are typically considered to be best practices in mobile app development. Both types of functionalities maintain a consistent look and feel and keep the user in the app when completing all potential activities. The reason these are considered best practices is that the user is able to go through the full functionality of the mobile app without changes to layout and design, nor needing to provide additional log-in credentials (other than what would be required in the app itself).
The most recognized consumer apps in the world – including Uber, Airbnb, and Starbucks – implement in-app features for their users. The familiarity that users have with these kinds of apps forms certain expectations with regards to the experience they expect with any mobile app. Health systems that are able to align with these expectations are in a better position to see positive patient engagement results from their mHealth apps in the age of the healthcare consumer.
An example of an mHealth innovator that is bringing a mainstream user experience to mHealth app development is Universe mHealth. Below are several screenshots showing in app integrated features with a next-generation user experience.



However, even with in-app features, many health systems still fail to provide the level of functionality patients expect. This is generally because integrated in-app features are hard to develop, requiring the use of modern APIs that support the real-time push/pull of data – something that most modern EHR and RCM systems are just now starting to implement. Even if an API exists, these integrated features take more time to develop, as the development required to consume an API is significant.
In many cases, for instance, where an appointment request or self-scheduling form should have existed, health systems opted for simply providing a list of phone numbers to call to make an appointment. These shortcuts and incomplete workflows are limiting the value branded mHealth apps are delivering to patients, and reflect poorly on the hospital app development company.

Linked Out Features

Linked Out Features
Linked out features point users to outside apps in order to complete the workflow. Common linked out features include medical records, bill pay, web check-in, telemedicine and appointment scheduling.
While the convenience of simply pointing a user to another app is extremely efficient for hospital app developers, the user experience is almost non-existent. In order for users to complete desired workflows, they must have the app to which they are being redirected installed, and need to start a new workflow from scratch in the new app. If they do not have the app they are being redirected to download and install the app. Not only does this type of feature add unnecessary steps to the workflow, but it also takes users away from the app itself, forcing the user to toggle between apps, and more than likely limiting the usage of the health system or hospital’s app.
This type of feature limits the ability of health systems to leverage their mHealth applications for branding purposes and presents an abrupt change in workflow, as well as a drastic break in look-and-feel for the patient. While from an implementation standpoint this course of action is much easier, the overall value created through the app is minimal for both internal stakeholders and patient users.
 


Screen Shot of mHealth App

The Problem with Linked Out Features: User Authentication and PHI

mHealth App Security
For HIPAA-Compliant mobile apps that contain PHI, app-integrated and browser-embedded features are the most common means of feature delivery. For these features, user authentication is paramount to preserving information security.
The most common means of providing user authentication is still a strong password – including at least one capital letter, one number and one symbol with a minimum of eight characters – that often must be entered for each session in the app.
While this type of password is highly secure, it can quickly become burdensome to users to remember it for each login, especially when the app will not be used on a daily basis. And while it’s arguably sensible to choose increased information security over ease of access for the user – especially when severe fines can accompany any malfeasance with regards to ePHI – it is noteworthy that mHealth applications have yet to make use of more user-friendly forms of user authentication. Fingerprint ID and 4-digit pins or auto-generated keys sent to the user outside of the application can authenticate their identity, without the need for a password that most would never remember.

Browser Embedded Features

Man using mHealth App

Browser embedded features provide hospital app development companies with a simple way to deliver functionality in their mHealth apps by leveraging existing web-based applications without having to navigate the technical and regulatory complexities of creating app integrated features.
While this shortcut can be cheaper to develop, the user experience is often severely limited. In many cases, it is necessary to zoom in on the screen to be able to enter any login credentials, read texts or properly interact with the features of the system that is being shown. What’s more, the layout and design of web-based applications tends to be noticeably different from mobile apps. This creates inconsistencies in the application and can impact brand equity. The costs associated with negative user experience, or simply a lost conversion, can quickly outweigh the development savings for this type of functionality.
Healthcare organizations can address some of the user experience issues by implementing Single Sign On (SSO) functionality – submitting user login credentials between applications without requiring the user to re-enter the information manually. Nonetheless, the other inherent to browser embedded features limitations, like inconsistent UI/UX and the need to zoom in, persist. SSO also brings forward a variety of security concerns as it’s difficult to strike a balance between ease of use and security, due to the challenges of managing user sessions in external browsers.
Screen Shot of mHealth App bill pay

Overall, our app functionality analysis suggests that the limited workflows and relatively low number of instances of integrated in-app features significantly reduce the overall value of hospital apps for patients.
In Parts III and IV of this series we will address our findings regarding misleading app store descriptions of application features, as well as whether the most common functionalities requested by patients in digital health platforms* are being implemented.
*According to Accenture’s “Losing Patience: Why Healthcare Providers Need to Up Their Mobile Game” paper from 2015.


You are reading Part II: Limited Functionality for mHealth App Features of  the series “Annual Check-up: mHealth Apps are Still in Critical Condition.” Read the other parts here:
Part I: Healthcare App Development Market is Not Meeting Patient Needs
Part III: Misleading Functionality Descriptions in App Stores
Part IV: Core Features Are Still Missing from mHealth Apps for Hospitals and Health Systems
Part V: Summary Report of Health System App Development Progress


Michael Scranton

Michael Scranton

As Director of Business Development, Michael is passionate about helping healthcare systems successfully transition to value-based care.

Related Posts

Posted on July 06, 2020 by Jared Mauskopf

Many healthcare organizations are seeking a means to develop their own healthcare or patient engagement solution, to positively impact patients’ health, and streamline clinical processes. Patients perform many of their…Read more


healthcare app

Posted on March 31, 2020 by kwatson

Amidst the outbreak of coronavirus disease (COVID-19) that was first reported in Wuhan, China, on December 31, 2019, people all over the world are turning to coronavirus apps to help…Read more


Newsletter
Subscribe to Our Newsletter

Get promotions and current business tips. Sign up for our newsletter today.