The healthcare sector is ripe with opportunities for mobile apps to transform the way we manage our health. Rising healthcare costs, aging populations and transformative federal guidelines are driving a shift toward more efficient, technology-supported healthcare delivery. The global market for mobile health apps is in hyper-growth, though still at an early stage of maturity. Dealing with highly sensitive patient data, cybersecurity is arguably one of the biggest risk factors that mobile health (mHealth) vendors must grapple with. In 2016, healthcare was the second-most hacked sector, accounting for 34.5 percent of all U.S. reported data breaches.

Many aspiring mHealth vendors are unsure of whether and how HIPAA compliance needs to be included in their cybersecurity plan. HIPAA compliance and cybersecurity concerns must be addressed in the early stages of defining one’s app in order to avoid delays in the development and release process. Those developing healthcare apps must take it upon themselves to address these issues, as there is no government agency or private enterprise that issues a certificate saying that an app is “HIPAA Compliant.” Rather, a cybersecurity plan must be devised, implemented, and documented, so that if a data breach or randomized government audit were to occur, costly fines could be avoided with proof that HIPAA-protected patient information was properly handled.

Does my app need to be HIPAA compliant?

The road to becoming HIPAA compliant is neither easy, nor cheap. It’s estimated that small entities spend between $4,000 and $12,000 establishing HIPAA compliance, while large entities spend upwards of $50,000. The high sticker price associated with HIPAA compliance pales in comparison to the fines associated with data breaches, which are capped at $1.5 million per violation per year.

The first factor those developing healthcare apps need to determine is whether their app falls under the regulation of HIPAA. Federal requirements of HIPAA compliance are determined by two key questions:

  1. Who uses the app?
  2. What type of data does the app manage?

Who uses the app?

The healthcare industry is an extensive network of differing players including patients, providers, insurance companies, and administrators. If your app involves physicians, hospitals, health plans, clinics, medical billing services – pretty much any entity involved in the provision or payment of health services – it will most likely need to comply with HIPAA regulations. However, an app for patients to manage a medication schedule on their own, for example, would not be covered, as it does not involve a covered entity.

Any app that shares information with a covered entity must be HIPAA compliant.

Covered entities, as defined by the HIPAA Security Rule, include:

  • Health plans
  • Healthcare providers
  • Healthcare clearinghouses

What type of data does the app manage?

The second criteria for HIPAA coverage is whether the app shares certain sensitive information referred to as Protected Health Information (PHI). PHI is defined as any information found in a patient’s medical record that could be used to identify that individual and that was created, used, or disclosed in the course of obtaining a healthcare service such as a diagnosis or treatment.

Information becomes PHI only when a personal identifier such as a patient’s name, social security number, or fingerprint is connected with medical records such as blood test results, prescription information, or billing data.

Identifiable information + Medical data = Protected Health Information (PHI)

If an app stores or shares PHI, it must comply with HIPAA regulations.

The U.S. Department of Health and Human Services list the following 18 classes of personal identifiers that constitute PHI (when combined with health data):

  1. Names
  2. All geographical subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes
  3. Dates directly related to an individual, including birth date, admission date, discharge date, date of death
  4. Phone numbers
  5. Fax numbers
  6. Emails
  7. Social Security numbers
  8. Medical record numbers
  9. Health plan beneficiary numbers
  10. Account numbers
  11. Certificate/license numbers
  12. Vehicle identifiers and serial numbers, including license plate numbers
  13. Device identifiers and serial numbers
  14. Web URLs
  15. IP addresses
  16. Biometric identifiers, including finger and voice prints
  17. Full face photographic images and any comparable images
  18. Any other unique identifying number, characteristic, or code.

Note: If a patient discloses data voluntarily, such as the number of daily steps or sleep patterns, this is considered Consumer Health Information since it was not collected through a health care service, and is not considered PHI.


My app needs to be HIPAA compliant. Now what?

If your app meets either of these criteria, you’ll want to adhere to the HIPAA Technical Safeguards which govern the technology and procedures for storing and sharing PHI. These safeguards do not require specific technology solutions, but rather establish standards designed to protect patients’ PHI. To remain compliant with HIPAA regulations, app developers must consider the following guidelines:

Secure the data.

Encryption is the foundation of data security and is a requirement for HIPAA compliance. PHI should be encrypted from end-to-end across each stage of data transmission – at rest while on a user’s device, in transit between parties, and while housed on independently secured servers. A minimum of 256-bit encryption is standard.

A common misconception is that encryption is enough to satisfy HIPAA requirements, but encryption is one of many conditions. Data storage must also be managed at a higher standard. Multiple servers will be necessary for storage so that personally identifiable information (such as the list of 18 examples above) and any patient medical records will never be stored in the same place. This separation prevents attackers from combining the data and identifying the patient if they gain access to one part of a system. Other data security features may include the auto-deletion of secure messages after 24 hours to remove any PHI on the device and continuous vulnerability monitoring of data storage. Be aware that these additional layers of security in remaining HIPAA compliant often result in higher-than-normal server costs.

Control user access.

The HIPAA Security Series requires that only authorized persons be able to access PHI through the use of access controls. Access controls require unique user identification that enables authorized users to access the minimum necessary information needed to perform job functions. These controls may include passwords, PINs, or biometrics such as fingerprints, voice command, or facial recognition. Other access controls may include emergency access procedures, automatic logoffs, auto-lock in case of forgotten username/password, and the ability to remotely wipe the app from any user’s device.

Secure your internal processes.

Moving beyond technology, HIPAA requires that any entity managing PHI have secure processes in place. One such requirement is the inclusion of internal data integrity policies that ensure PHI is not altered or destroyed. HIPAA-covered entities must additionally have PHI stored on databases that can be audited upon request at a moment’s notice. Further, employee training is essential when dealing with PHI. Employee error or negligence is one of the leading causes of healthcare data breaches. With training, employees can deepen their expertise in data security and PHI handling.

Beware third party integrations.

HIPAA compliant apps are only as secure as their weakest link. Third parties, subcontractors, and business associates are a top cause for healthcare data breaches, resulting in over four million exposed records in 2016 alone. When working with third party apps, ensure that they share or store PHI following the same HIPAA regulations and never assume that they are as vigilant as you are.


If you’ve made it to the end of this post then the odds are high that your app will need to become HIPAA compliant. To stay HIPAA compliant your organization will also need to conduct a risk assessment every one to three years. Remember, your app will not receive a certificate or badge for following HIPAA regulations. Your satisfactory completion of risk assessments and audits is your certificate. The U.S. Department of Health & Human Services (HHS) and Office of the National Coordinator for Health Information Technology (ONC) has a risk assessment tool to help guide you through this process. This checklist on developing mobile health apps can also assist you through the HIPAA compliant app development process.

Has your understanding of HIPAA compliance changed after reading this post? Do you still have looming questions regarding your app’s position? Share your thoughts or questions in the comments!