There are a lot of things unique about healthcare as an industry. One of the most vexing is HIPAA, the Health Insurance Portability and Accountability Act. Now, I’m no lawyer, I will not attempt to parse out what HIPAA’s PHI protections mean. Indeed, the act is intentionally vague as it leaves it up to the IT world as to how to protect confidentiality and security of patient information.

What I do want to address are the things that need to be thought about when designing a HIPAA-compliant piece of software. There may be other things that would need to be addressed as well, such as who as has access to data and how it is shared. This list is just a minimum.

From a security perspective, the main idea behind security is to throw up as many barriers as possible to a cyber-attacker. Acting along multiple fronts (especially transmission and encryption) is demanded by HIPAA to protect PHI.

Learning to do this takes a lot of time and few clinicians will be doing this solo. But nonetheless, it’s helpful to at least understand the language and some basic tenets so that you can “talk the talk” when you’re working with developers.


At a minimum, HIPAA compliance means that in 99% of cases, PHI needs to be stored in an encrypted form. One option to do this is to encrypt the entire hard drive. On mobile apps, this can be easy (as in iOS) or painful (as in Android, which can take tens of minutes for the user). Android devices can also have internal and external/removable hard drives; therefore, on Android, the developer should forbid writing to any external hard drives that could easily be removed by a bad player.

If hard drive encryption is not possible or if additional layers of protection are desired (which is always good), encrypting the data values can achieve the same effect. Indeed, in some setups, the developer can encrypt the entire database used by the app. Writing encryption code is difficult; it’s best to use an established library that does 95% of the work for you. To find one, a quick Google search for AES, RSA, or SHA combined with the name of the language you’re developing in will pop up some examples.

To encrypt, the software must use a key to transform the data into hard-to-hack gibberish. Then storing the key safely becomes of paramount concern. iOS uses a Keychain that has been shown over time to have good security. Android devices use something called a KeyStore (OS > 4.3). Its security credentials have increased with time and seems to be fairly reliable at the present. KeyStores are difficult to program with, however, and lack a good number of freely accessible guides.

In part 2 of this series, we’ll look at how medical apps exchange data with other systems and what that means for data security.