See for yourself – run a scan on your code right now

Telehealth and the technologies that enable remote care continue to become more popular. For example, in January 2023, telehealth utilization grew by 7% and accounted for 5.5% of all medical claims. Doctors and healthcare delivery organizations (HDOs) need to monitor and track patient progress, especially for people with chronic illnesses like cardiac disease, respiratory problems, hypertension, and diabetes. As technology evolves, its ability to improve patient care means that the mHealth market is projected to reach $861.4 billion by 2030, a CAGR of 40.2 percent. 

However, for eHealth apps to enable better patient care, developers should understand the different types of sensitive data they manage and how to protect it. 

What is an mHealth app?

Mobile health (mHealth) apps are software that healthcare professionals use to help patients manage medical care. MHealth solutions can be used to:

  • Provide education and awareness
  • Assist with diagnostic and treatment support
  • Collect data remotely
  • Monitor patient health remotely
  • Support chronic disease management
  • Support patients’ ability to take medications on time

While consumers may use health apps for personal behavior and activity monitoring, mHealth includes any solutions that medical and public health professionals use to communicate and deliver health information via:

  • Mobile phone
  • Table
  • Personal digital assistant
  • Wireless infrastructure

What types of ePHI and PII do mHealth apps collect?

The first step to understanding the potential data privacy and security impact of your mHealth app lies in defining the difference between electronic Protected Health Information (ePHI) and personally identifiable information (PII). 


Since medical professionals use mHealth apps to communicate with patients, the apps often include electronic Protected Health Information (ePHI). Under the Health Insurance Portability and Accountability Act (HIPAA), ePHI is any information that identifies a person in connection with their:

  • Past, present, or future physical or mental health conditions.
  • Healthcare received.
  • Past, present, or future payment for healthcare provided.

The Department of Health and Human Services (HHS) lists the following 18 categories of ePHI:

  • Names
  • Physical addresses
  • Dates, including birth date, admission date, discharge date, death date
  • Telephone number
  • Vehicle identifiers and serial numbers, including license plates
  • Fax numbers
  • Device identifiers and serial numbers
  • Email addresses
  • URLs
  • Social security numbers
  • IP addresses
  • Medical record numbers
  • Biometric identifiers, like fingerprints
  • Health plan beneficiary numbers
  • Full-face photographs and any comparable images
  • Account numbers
  • Certificate or license numbers
  • Any other unique identifying number, characteristic, or code, except those specifically allowed


PII is a broader category that includes HIPAA-regulated ePHI as well as other data points that can be connected to a person, including:

  • Gender
  • Religion
  • Place of birth
  • Race
  • Employment information

An mHealth app might collect, store, transmit, or process intake information like a patient’s race or current employer. While this data wouldn’t fall under HIPAA protections, it’s still PII whose integrity, confidentiality, and availability you need to protect. 

Giving Your mHealth App a Digital Vaccination

Just like vaccines act as a way to take proactive control over physical health, taking a “secure by design and default” approach to app development enables you to take preventative control over your mHealth app’s digital health. 

Use trusted third-parties

Using third-party libraries and components is a best practice, but you need to make sure that you choose well-vetted and maintained ones. Some considerations include:

  • How many maintainers are on the project
  • How experienced the maintainers are
  • How many times other people have used the repository 
  • How frequently the maintainers update it
  • Whether it has appropriate changelog or release note documentation

Identify and track all components and dependencies across supply chain

Just like you use third-party components, the repositories you choose may also incorporate third-party code, effectively turning it into fourth-party components for your mHealth app. TO mitigate these risks, you should generate a Software Bill of Materials (SBOM) that identifies all components. Additionally, you should identify all dependencies across your source code, including:

  • User inputs
  • Log files
  • Databases
  • Custom code
  • Open-source libraries
  • Software Development Kits (SDKs)
  • Application Programming Interfaces (APIs)
  • Microservices

Scan for vulnerabilities

With automated vulnerability scans, you can identify and remediate potential security weaknesses across your source code. Further, by focusing on the vulnerabilities within your code that attackers can exploit, you can prioritize your activities efficiently and produce secure code faster.

Identify business logic flaws

Unlike typical coding errors, business logic flaws leak data because they arise from overlooked scenarios or incorrect assumptions about how people use the application. To identify and remediate business logic flaws, you should:

  • Chart data movement across modules
  • Identify control paths that drive program execution
  • Review the impact that code frameworks and interdependencies create
  • Understand how business protocols and multi-stage processes impact data

Qwiet AI: Helping Keep mHealth Apps Healthy

With Qwiet AI’s preZero platform, you can scan millions of lines of code in minutes for visibility into all components, dependencies, and reachable vulnerabilities. Our platform quickly returns accurate and detailed findings while significantly reducing false positives. With our Code Property Graph (CPG), you gain a holistic view of your code, including data flows across the application, to quickly determine reachability and risk impact.

Our appsec experts can work with your team to understand applications and their intended functionality to help you identify potential business logic flaws and implement custom policies to monitor them.

Take our preZero platform for a free spin to see how Qwiet AI can help you secure your mHealth app. 


About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit:


See for yourself – run a scan on your code right now