How to Make a HIPAA-Compliant Healthcare App

The Health Insurance Portability and Accountability Act (HIPAA) was enacted to protect patients’ privacy by limiting access and governing acceptable use of their health data. To abide by HIPAA law when building a healthcare app, it is essential that healthcare organizations place the utmost importance on HIPAA compliance. Maintaining HIPAA compliance requires diligence early on in the initial planning stages of the app, as well as throughout the lifespan of a healthcare app. HIPAA is constantly evolving (in the direction of greater complexity), therefore a constant effort is required to avoid violation.

There are also other compliance considerations, such as ADA and GDPR that are not a focus of this article, but require a similar degree of attention.  

#1 Never Store PHI on a Phone

When building a HIPAA-compliant healthcare app, an organization’s IT department needs to always take into consideration Protected Health Information (PHI). The 18 PHI identifiers* all relate to identifiable information about a patient and it is crucial that healthcare apps handle this data in a safe and secure manner. A healthcare app must be programmed not to store PHI on the device. Apps should never store data on the device for two reasons:

1. Unless the patient’s phone meets HIPAA security requirements, which 99% of the population’s phones won’t, it’s a high risk to do so.

2. Glitches and mistakes happen. If the app ever accidentally sends something to the wrong patient, that incorrect data cannot be recalled if it is saved to the user’s phone (whereas if data is pulled from the source EMR/PM system in real-time and not saved on the device, it can be recalled). 

#2 Never Include PHI in a Notification

Healthcare apps have the ability and great responsibility of sending patients vital information via notifications to their mobile device. There are strict guidelines when sending a push notification, SMS, or email to a patient. A notification should never mention any sensitive or specific information. For example, a notification should never read, “Reminder: Your obstetrics appointment is tomorrow.” What if a patient’s coworker didn’t know she was pregnant and they happened to see the notification? There are many implications for notifications containing private or sensitive patient information. An example of a viable notification would read, “You have a new secure message!” This allows for the patient to recognize the notification from the healthcare provider and privately view the information at their convenience.

#3 Always Use a HIPAA-Compliant Hosting Service

When considering hosting for your healthcare app, remember to consider HIPAA once again. Patient data must always be hosted in a HIPAA-compliant cloud service. As an example, at Medical Web Experts we use Amazon’s HIPAA-compliant cloud as the foundation of our HIPAA-compliant cloud hosting service – the MWE Cloud.

#4 Always Get a BAA

The Business Associate Agreement (BAA) establishes that a web design or application development company will share the responsibility for all patient information that is received by them or handled by the app they build. Always ask your mobile app developer to sign a BAA before you agree to hire them. Your organization’s lawyer can prepare a BAA for you. If the development company you’re considering is unfamiliar with what a BAA is or refuses to sign one, walk away.

For more information about the development of a healthcare app by expert developers that understand HIPAA compliance, please check out our site today.

*18 PHI Identifiers

1. Names
2. All geographical subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes.
3. All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death, and more.
4. Phone numbers
5. Fax numbers
6. Electronic mail addresses
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 Universal Resource Locators (URLs)
15. Internet Protocol (IP) address numbers
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 this does not mean the unique code assigned by the investigator to code the data)