5 Pitfalls Mobile App Developers Face When it Comes to HIPAA Compliance

The Health Insurance Portability and Accountability Act was signed into law by Bill Clinton on August 21st, 1996. To put this in its technological context, HIPAA predates the first iPhone by 10 years, the first iPad by nearly 14 years, and came into effect just 1 year after commercial ISPs started providing broader access to the consumer Internet.

At this point in time, anything close to mobile apps was still beyond the imaginations of even the most outlandish sci fi writers. It’s safe to assume that there will be myriad challenges trying to apply a nearly 20-year old law to new and rapidly changing technology.

Consumers use of the Internet are in constant flux. Some commentators believe that mobile apps (not just phones, but the apps themselves) will eventually eclipse the internet as we know it. A 2012 comScore study corroborates this view, reporting that more mobile subscribers used apps than browsed the web on their devices: 51.1% vs. 49.8% respectively.

In theory the healthcare industry and mobile apps are a perfect match. Mobile apps can help doctors work more efficiently and bring down the cost of health care. Moreover, mobile apps can help improve patient satisfaction and enable them to better understand their care.

Hopefully, this will encourage patients to assert control and take greater daily responsibility for their health. It’s no wonder then that there are already more than 40,000 mobile health (or mHealth) apps currently available in various mobile AppStores, with new ones being launched every day.

However, there are some obvious dangers surrounding the protection of personal information in this brave new world of mobile applications that need to be considered: the smartphones that run them can be (and frequently are) lost and are popular targets for theft. Also, due to the very nature of mobile phones and apps, it very easy to improperly publicize private information.

In that context, it’s important that mobile app developers understand some of the critical pitfalls that they need to avoid, particularly as they apply to whether an application needs to be HIPAA compliant or not.

1. Not Considering How the App Will Be Used

It’s important to consider whether or not your app will be used to store or transmit protected health information, regardless of how you’ve designed it or anticipate it being used. Even if you’ve designed your app to collect or use anonymous data that doesn’t fall under HIPAA by itself, if a user chooses to use your app to store or transmit PHI then you are subject to HIPAA compliance requirements. Edge case or not, as soon as PHI is on the device your app falls under HIPAA.

If your application has the chance to be used to store and transmit PHI it’s a safer bet to be HIPAA compliant to protect yourself from inadvertently violating HIPAA guidelines.

2. Allowing Protected Health Information in the App

Protected health information, or PHI, is information that could be used to identify an individual and that relates to their physical or mental health, any healthcare services they have received and any information regarding the payment for such services.

The fact that an individual has received services from a covered entity is itself PHI. Likewise, the name or address of an individual, although publicly available, is also PHI when it’s on a covered entity’s computer simply because its presence suggests that the individual is or was a patient.

PHI can also include what would otherwise be anonymous information. This includes a date of service i.e. anything more specific than a year.

If you store, collect, manage, or transmit any protected health information then your app needs to be HIPAA compliant.

3. Not Protecting Data at All Times

The very premise of the HIPAA is to protect sensitive information, so it is paramount that you consider how you will communicate with subscribers once they are using your app.

Consider email. Emails are usually not compliant with HIPAA as they often lack the ability to encrypt their contents. Therefore sending information that may contain PHI via email is a HIPAA violation. Because many applications use email as a communication source with users, it’s important to understand what can and can’t be included in those communications.

If you are sending email communications that include or might include protected health information from your mobile app you should send those emails via a HIPAA compliant email service provider.

In order to secure data on an iPhone, users must use a passcode to lock the handset when not in use. As a mobile app developer you can’t control whether a user enables this functionality; but you can recommend that users who install your app enable the feature. An easy way to do this is suggest that the user turns on the passcode lock setting in your welcome email to new account holders.

In order to be compliant with HIPAA, apps have to encrypt their database, which means if your app is not compliant you will not be able to search and interact with their database. This greatly limits the functionality of your application.

You can use a service like TrueVault to provide the HIPAA compliant and secure “digital handshake” between data stored in a covered entity's database and your app’s database. If the covered entity doesn’t provide access to their data, you can ask them to consider implementing TrueVault to make that a possibility.

4. Misusing Mobile Push Notifications

As we have said before, mobile phones are particularly insecure devices and the native push notifications that are used by many applications to notify users of updates and changes run the risk of violating the privacy regulations outlined in HIPAA.

If you’re using notifications in your mobile app, it’s critical that you do not include any PHI in any push notifications from your app as they can appear and be publicly visible even when a phone is locked.

This goes beyond just mobile push notifications. Any time you’re making an automated, outbound push message (whether it be mobile, email, or automated calling) the same rules apply. Make sure you evaluate all communication touch points for potential PHI/HIPAA issues.

5. Not Checking if the App is Actually Classified as a Medical Device

It is possible, based on the features and functionality that you include in your application that it may actually be classified as a medical device. It’s important to look up FDA regulations and check whether your app will be considered to be a medical device. If it does fall under those definitions it may require FDA approval which brings with it a whole host of further regulations.

Don’t launch your app until you’ve determined whether or not you are safely outside the FDA’s medical device classification.

Depending on how they are used and advertised, mobile apps that handle PHI are liable to fall under the jurisdiction of several federal regulations, not just HIPAA. While we’ve outlined some of the biggest pitfalls, mobile app developers should be aware that that these are only a small portion of the issues that should be taken into consideration when developing a mobile app for the healthcare industry.

In many instances application developers can avoid some of the biggest pitfalls by working with companies that provide HIPAA compliant services that power the application. For instance, HIPAA compliant hosting providers like Amazon AWS can handle the physical safeguard requirements of HIPAA. TrueVault manages the technical and physical safeguards associated with the transmission and storage of protected health information. By using services such as these mobile application developers can avoid the red tape and headaches associated with building compliant apps from scratch.

Developers should take time to examine the potential compliance issues from sites like Health and Human Services and the FDA to understand the laws and regulations that apply to apps. In addition to this, it’s probably a good idea to consult an attorney before launching a new venture or app, due to the above regulatory complexity which can be exacerbated by the unique nature of the functionality of your application.