How to Maintain HIPAA Compliance in Software Development for Web and Mobile Apps

With more and more software applications being developed for the medical and health industries, from modern online pharmacies like PillPack and divvyDOSE to Amazon Alexa’s new health care skills, developers are starting to have to take a hard look at the Health Insurance Portability and Accountability Act (HIPAA) when developing web, mobile, or other software applications.

For developers, staying on top of what is required to maintain HIPAA compliance can be incredibly overwhelming. The plethora of outdated and vague guidelines makes it all the more agonizing.

When we first started building HIPAA-compliant apps, we were stunned by the apparent scarcity of information available from the software development perspective.

After having spent countless hours building HIPAA-compliant internal software and consumer-facing web and mobile apps for clients like divvyDOSE, SmartScripts, and Transparent Health Marketplace, as well as other data-sensitive clients like Emulate, Barry's Bootcamp, Zingfit, and ConveYour, we’re confident that the information below will be a helpful starting point for anyone attempting to develop software that requires HIPAA compliance.

A Brief History of HIPAA

HIPAA first came about in 1996 as an all-encompassing reform to the health insurance industry. The bill has a whole section dedicated to the communication and protection of private and sensitive medical data. If you aren’t familiar with what the software development and tech industry was like back in 1996, here are a few facts to give you an idea:

• Google was still just a research project at Stanford and was known as “BackRub”

• Ebay.com had just been launched

• Pokémon was introduced to the world

• Only about 100,000 websites existed (compared to about 1.8 billion today)

A Brief Overview of HIPAA Compliance

There are two different components of HIPAA that you should be familiar with: the Security Rule and the Privacy Rule.

The Security Rule deals specifically with electronic information and has set forth guidelines on how to secure protected health information, known as PHI, which is basically any individually identifiable medical information that is transmitted across any medium. The Security Rule breaks down PHI protection into three different categories:

• Physical – protections for actual physical devices

• Technical – protections in regards to the information itself

• Administrative – policies and procedures that help protect against a breach

While HIPAA’s guidelines can be quite ambiguous, the gist is that you’re supposed to “protect against any reasonably anticipated threats or hazards to the security or integrity of such information” by, among many other things, “implementing a mechanism to encrypt and decrypt electronic protected health information.” This is obviously far from clear. Luckily, there are industry standards for HIPAA-compliant encryption used by the major cloud platforms (Amazon, Google, and Microsoft) that provide a great foundation.

The Privacy Rule attempts to determine who's responsible for making sure PHI-related data is handled correctly. Any company or entity that deals with the transmission or storage of PHI—not just health care providers or hospitals—may be liable.

The Privacy Rule divides entities into two categories:

• Business Associate – Any person who collects, stores, transmits, or maintains protected information on behalf of a Covered Entity. If a person or organization does not provide a service or function that involves the use of PHI, or has very limited access to PHI, then they might not be considered a Business Associate.

• Covered Entities – Health care providers, health care clearinghouses, and health plans who transmit any health information electronically in connection with transactions for which the Department of Health and Human Services (HHS) has adopted standards.

As a developer, you would be considered a Business Associate, which means you would have to sign a Business Associate Agreement (BAA) with the Covered Entity.

The Privacy Rule also mandates that Covered Entities provide their users/patients with a Notice of Privacy Practices, informing them on how their PHI is protected. The regulations laid out by the Privacy Rule are intended to increase awareness of PHI and how it’s used, as well as to give more control to patients/users over who has access to their PHI.

HIPAA Compliance Tips for Developers

Please note that adhering to the points below is in no way a guarantee that your application will be completely compliant. It may be best to seek out an expert HIPAA compliance consultant.

Offload Security to Experts

By using existing HIPAA-compliant tools, you can offload a lot of your security concerns. The burden of expertise on HIPAA compliance should not be solely on you as a developer. Ideally, you’d be able to work with a HIPAA compliance expert who would guide the security decisions for the application.

You’ll also want to find out what other regulations you might need to take into consideration. There are tools available to help with that, such as this guide provided by the FTC.

Avoid Handling Data Whenever Necessary

Try to minimize the data you are storing, accessing, or displaying to only what is absolutely necessary. If you don’t need patients’ addresses, then don’t ask for them. Any personal information used in your application should have a clear purpose.

If you plan to use cloud storage, be mindful that the transmission of data to and from the cloud has to be secure. A BAA is also required in these kinds of situations.

Don’t forget about geolocation data. HIPAA defines geographically identifiable information as any information that narrows a person’s location to a location smaller than a state. Geolocation can take a seemingly harmless and insignificant piece of patient data and turn it into a massive liability.

Transmit and Store Data Securely

With so many HIPAA-compliant protocols and tools available to you today, there’s really no excuse for not making use of them. If data is encrypted locally, stick with known protocols that have withstood the test of time. Don’t try to reinvent the wheel, especially when it comes to security.

If your application sends text messages, be mindful that MMS and SMS are not encrypted protocols, so avoid these when transmitting PHI. Also, push notifications are generally a vulnerable means of communicating with your users. If your application is using these communication methods, be sure that PHI is never displayed, as it’s just too easy for someone other than the intended recipient to see these notifications.

Maintain Application Security

Consider all the different places in which your application is storing data. Backups and log files are often lacking when it comes to security. If the app is consumer-facing, it should feature a local session timeout which forces re-authentication.

Plenty of guidelines for best practices are available online, including OWASP’s list of top 10 mobile risks.

Test Application Security

The last thing you can do to be sure your application is secure and HIPAA compliant is conduct security testing. There are plenty of tools available for you to do this yourself. If you aren’t a security expert, though, then it is in your best interest to seek out a third-party professional to perform penetration testing on your application. Be sure to inform them that the application they’re testing needs to maintain HIPAA compliance.

Protect Yourself with Insurance

If you’ve landed a project that requires HIPAA compliance, you probably have the extra cash to protect yourself with an insurance policy. For about $2,000/year (the price will vary based on the income of your business and some other factors), you can get a $1 million policy. To get insured, talk to an insurance broker.

The policy you’re looking for is called Errors & Omissions insurance (E&O). The thing to be aware of with E&O insurance is that they are Claims Made policies. This means that if you stop coverage you will no longer be able to make a claim, unless you buy what’s called a “tail” or “the extended reporting,” which is essentially just renewing your existing policy.

Maintaining historical coverage is important because it’s possible that years after you last touched PHI, an investigation could determine you to be a liable party in a data breach.

Wrap-up

The guidelines set forth by HIPAA can seem convoluted and overwhelming, but by following the points outlined above, you’ll be well on your way to building a HIPAA-compliant software application.