With the increasing focus on consumerism in healthcare, patients expect to get more control over their health data and take an active role across all care journey points from the initial examination to treatment and follow-ups. Mobile health applications are one of the tools being used to engage patients now that they have evolved from the toy-like calculators on the early days of mHealth to more fully functional and connected health advisors or chronic care assistants.

These apps collect and process massive amounts of patient data on a variety of behaviors including nutrition habits, night sleep patterns, women’s cycle intricacies, and even overall health improvement or deterioration trends. But just like what has happened with EHRs, mHealth apps may also be the target for patient data theft. Security and privacy concerns have made the industry cautious about adopting the applications on major clinical levels, across health systems or networks.

Mobile health apps – security and privacy concerns

These concerns are not baseless. According to 2018 Global Study on Application Security, conducted by the Ponemon Institute, the majority of companies take the reactive approach and don’t invest in protecting their products up until the actual breach occurs.

However, the healthcare industry has learned from past mistakes and has taken steps towards safeguarding sensitive data beforehand. For instance, Cybersecurity Ventures forecasts global healthcare spending more than $65B on cybersecurity between 2017 and 2020.

While other industries may wait up until the hackers hit them, providers and healthcare software developers do not have that luxury. Breaches of health data security and privacy are too important. To back them up, we’ve aggregated some bite-size guidelines on the ways to overcome the major health app security concerns.

Ensuring Regulatory Compliance

Prior to unleashing the power of a mHealth app, vendors and providers should absolutely make sure their new solution is compliant with the set of must-have rules in their region. In some cases, an app should pass through the certification procedure in order to process particular types of data (e.g., patient-generated health data) or offer certain functions (e.g., connecting to smart wearables or medical devices).

To understand the pool of policies an app needs to follow to become safe, private, and secure, we offer the following checklist. The app most likely needs to get certified and/or tested for its compliance with the healthcare data privacy and security rules if it stores or operates such data as:

• Patient and/or their caregiver’s contact info
• Social security number, demographics and income details
• Medical history
• Insurance-related data, current claims, and claims history
• Scheduled, missed, or upcoming appointments, office visits, and follow-ups
• Prescription history, e-prescriptions

If there is a match, the vendors should research the standards for the region they want to market the app, for example, HIPAA and HITECH for the U.S.

Knowing Where to Look for Threats

To prepare for a strike, both vendors and providers should know the various types of attackers and how they can access the protected data. Each type’s characteristics are hinting at how to secure the mHealth app and put it out of their reach.

We’ll focus on three of them: hackers, social engineers, and man-in-the-middle (MITM) attackers.

Hackers

Hackers are technical experts that use their expertise to inspect the software, find bugs, loopholes or exploits, and take control over the application or access certain pieces of private information.

Hackers can wear multiple “hats” (black, white, grey, red, and blue), meaning some of them will try a server overload attack, some will come for credit card data, and some will definitely want all patients’ personal information to sell it later on the dark web. How to fight them? Actually, it’s pretty simple – vendors should find the app’s vulnerabilities themselves and close the security gaps.

Social Engineers

A social engineer actually hacks people, not the software itself, with the help of psychology. Social engineers can manipulate individuals by tricking them into spilling sensitive data. In real-world interactions, “human hacking” can take significant time for the attacker to research the background of a victim, gain his or her trust, and then obtain the needed information.

In mHealth apps, social engineers can act faster using such approaches as phishing, spear phishing, or scareware. They can target either particular patients or the app itself. In the first case, they try to get the user’s credentials from the user, while in the second case they impersonate the user and reach out to the app’s tech support to change the creds. One of the ways to fight social engineers is to enable multifactor authentication in your app to verify each user’s identity in a few different authorization procedures (e.g., a fingerprint and a unique code sent in an SMS).

Man-in-the-middle (MITM) Attackers

The MITM attackers are the grey cardinals of hacking. They intercept the data transactions by impersonating both inbound and outbound sources and acquiring the information they were exchanging. In mHealth apps, the MITM attacks can exploit the transmissions of funds or protected health information data.

To ensure that the app is protected from MITM attacks, vendors need to implement the secure transfer of sensitive information as well as enable continuous updates of their current cryptographic protocol versions (such as TLS).

Concentrating Security Testing Efforts

Speaking of the vulnerabilities, bugs, and loopholes the malicious actors can use to their benefit, vendors need to find them first to secure the mHealth app. Here’s our check-first list of typical app vulnerabilities to consider when testing an app’s security:

• Client-side injection happens when the malicious code leaks from the app into the user’s mobile device. Finding this issue requires defining whether the user/app supplied data is validated during the input.
• Insecure data storage means the mHealth app fails to restrict the access to patient data via insecure encoding or file permissions.
• Unintended data leakage occurs when sensitive data is stored in a location where it can be accessed by other apps on the same device or by the attacker with a physical access to the device.

Secure State of Mind

mHealth apps are reshaping the way healthcare engages with healthcare consumers. They help patients stay visible to their providers even in-between care cycles and across different facilities within one network. And there are a plethora of apps that collect and make visible many different types of sensitive patient-reported or collected health data.

Providers and vendors should be aware of what patient data security threats are out there and know how to safeguard sensitive information beforehand. Using our hints and tips, we hope that mHealth evangelists will set their sights on important data safety aspects, cover their vulnerabilities, and ensure that their products are adopted on a wider scale without any doubts about security and privacy.