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 to and governing acceptable use of their health data. When building a healthcare app, healthcare organizations must place the utmost importance on HIPAA compliance to avoid breaking the law. 

HIPAA compliance should be a priority throughout the planning, implementation and lifetime maintenance of any healthcare app. The constant evolution and increasing complexity of HIPAA demands constant efforts to stay up-to-date. It only makes sense to make your healthcare app as secure as possible from the beginning, rather than rush to upgrade it later. 

(Please note: There are additional compliance considerations beyond HIPAA, such as ADA and GDPR, that require a similar degree of attention.)

To ensure that your app is HIPAA-compliant, adhere to the following guidelines:

#1 Never Store PHI on a Phone

When building a HIPAA-compliant healthcare app, your IT department should carefully heed the rules surrounding Protected Health Information (PHI). The 18 PHI identifiers* refer to identifiable information about a patient, which must be handled safely and securely. Any healthcare app should be programmed to never store PHI on the user’s device. This is because:

1. It is highly risky to store PHI on any phone that does not meet HIPAA security requirements; 99% of phones do not.
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. If the 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 are capable of sending vital information to patients via notifications to their mobile devices. This is convenient and appreciated by patients, but remember that anyone looking at the screen can view a notification. 

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 who didn’t know she was pregnant happened to see the notification? It’s best to always assume that people who should not see a patient’s sensitive information are in the room with them and take precautions accordingly.

An example of a viable notification would read, “You have a new secure message!” The patient can then open and view the message privately at their convenience.

#3 Always Use a HIPAA-Compliant Hosting Service

When considering hosting options for your healthcare app, remember that patient data should always be stored in a HIPAA-compliant cloud service. At Medical Web Experts, we built our HIPAA-compliant MWE Cloud on the industry-leading Amazon’s Web Service (AWS). 

#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. This is absolutely essential for using any third-party software in a healthcare context. Always ask your mobile app developer to sign a BAA before you agree to hire them. Your organization’s lawyer can prepare one for you. If the development company you’re considering is unfamiliar with a BAA or refuses to sign one, walk away.

Conclusion

As you can see, developing a HIPAA-compliant app takes care and expertise. Because many healthcare providers are not also technology experts, it pays to partner with a developer experienced in building apps for the healthcare sector. For more information about developing a healthcare app with expert developers who understand HIPAA compliance, please check out Medical Web Experts 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)