Health apps are handling a lot of sensitive data. Many ask users to register, providing information like date of birth, or provide detailed past medical histories. And while many of these apps aren’t actually subject to HIPAA requirements, responsible developers will do their best to protect the data in health apps. A recent guide can help health app developers take a more systematic approach to doing that.

By a Spanish group, this piece reviews the different challenges mobile apps face in securing health data. While many websites have mastered the challenge of HIPAA requirements for protected health information (PHI), most mobile apps have not. It rightly critiques the industry. Any mHealth mobile app developer can gain something by reviewing the tables in this article in particular.

My favorite table is Table 1: Ten vulnerabilities in mobile health apps. It details potential weaknesses such as

  • Weak Server Side Controls expose the server to simple hacks,
  • Insecure Data Storage exposes lost/stolen devices, but good data encryption can protect,
  • Insufficient Transport Layer Protection exposes client-server interactions over https, but to counteract, the setup needs SSL (https) with a certificate-authority-issued certificate,
  • Unintended Data Leakage through lack of hardware standards/knowledge on mobile devices,
  • Poor Authorization and Authentication because passwords are authenticated locally on the device, not through an authentication server,
  • Broken Cryptography through self-developed encryption algorithms or obsolete practices,
  • Client Side Injection function like server-side injections (see above) and are exemplified by SQL injections,
  • Security Decisions Via Untrusted Inputs (look up Inter Process Communication that facilitates the sharing of limited memory space on a device)
  • Improper Session Handling through improper cookie management with the device can leave a criminal with access to dangerous information,
  • and Lack of Binary Protections leave reverse engineering opportunities to decode an app, change it slightly, and resell it.

There is nothing new here because security concerns remain fairly constant. What is good is that this is a very thorough summary of what is needed in the industry in order to protect patients’ health information. I found myself doing mental checklisting as I read – “my app does this,” or “it could use a little improvement here.” That activity is what this article is designed for.

Perhaps some group should come together and provide a service that handles the security conventions all at once. These issues are not novel. They are basically the same in each application. But dealing with issues as dense as cryptography can be daunting, particularly for the new programmer. There are third-party services that can provide some help. We’ve previously covered a University of Arizona project to provide security audits for health apps. Another service, TrueVault, offers outsourcing of data storage for health apps that access the cloud as well as some security standardization for data transmission.

HIPAA maintains that the developer think through the issues thoroughly and implement your conclusion properly. This relatively short guide (13 pages) handles the basics of these issues at a high-level. Further research would be required into implementing its recommendations in your particular app.

I remember doing rounds in medical school and wondering about the strength of the software I was using. I knew no one else around me was. As I re-entered the world of development, I vowed to write strong software. It distinguishes me as a healthcare developer. I saw and remembered the need; now I implement the solutions. Will the app community follow?