How to Ensure HIPAA Compliant Software Development

With the popularity of health-oriented software and applications growing at a rocket pace (over 40,000 of those found on AppStore), it is becoming increasingly important to understand what standards these apps must comply with, and who is responsible for making them compliant. This article is a detailed guideline for both clients and developers planning to build health-related software.

HIPAA overview

The Health Insurance Portability and Accountability Act, or HIPAA for short, is a set of provisions regulating security and privacy for electronic protected health information (ePHI) of any kind stored on any device and used for any healthcare purposes. The initial act was issued in 1996 primarily to facilitate the transfer of patients’ insurance information. A major update called the Omnibus Rule, followed in 2003. It clarified and added a lot of terminology and provisions, included new procedures, and generally made HIPAA more specific and universally applicable in the healthcare world. Since HIPAA is such a complicated phenomenon, we will briefly look at its structure next.

Short Glossary

Before moving forward, we want to clarify several key terms that are commonplace throughout the HIPAA document:

• ePHI – any kind of information contained in a medical record that can be used to uniquely identify the patient, and that was obtained as a result of a medical procedure. Some common examples of ePHI include bills for healthcare services, MRI scans, lab test results, appointment notifications, etc. The data that cannot be specifically attributed to a particular individual is not considered an ePHI, e.g. total distance covered in a particular week (smartwatch readings) or heart rate monitor data that are not tied to a user account or email address.
• Covered entity – an organization that provides treatment, payment or operations services in the healthcare industry. This includes doctors and dental offices, insurance companies, health plans, pharmacies, hospitals, etc.
• Business Associate – any third party that does business with a covered entity and has some sort of access to ePHI. These can be as diverse as translators, auditors, lawyers, consultants, shredding companies, companies servicing medical equipment, data storage companies, etc.

HIPAA Structure

The core of HIPAA consists of the following four elements (with the first two outlining the actual requirements):

• Privacy Rule – concerned with who is entitled to use and share the ePHI, how it can be used, and to what extent.
• Security Rule – states the standards for storage, transmission, and protection of health information (includes Physical, Technical, and Administrative sectors).
• Enforcement Rule – describes the procedure for the investigation of breaches, the implementation of a penalty system and possible legal action in case of a breach.
• Breach Notification Rule – defines the ways and parties to be notified and frequency of notification that have occurred.

What Should Developers Focus On?

Developers of HIPAA compliant software primarily focus on the Physical and Technical aspects of the Security Rule. The specific criteria are discussed in the next two sections.

1. Technical Safeguards

Technical safeguards define a set of requirements that the technical infrastructure must adhere to during any operations on the ePHI. To ensure compliance with HIPAA security the software must strictly follow this checklist:

Access control
A mechanism for encryption and decryption of the ePHI must be implemented.
Any person attempting to log in to the area/application storing ePHI must go through an authentication procedure.
A contingency plan to get access to ePHI in case of emergency has to be developed.
Unique access credentials must be assigned to each authorized entity.
An automatic logoff procedure has to be set up to guarantee termination of the user session after a specific period of time.

Secure transfer
A reliable encryption algorithm must be applied to ePHI prior to any relocation.
An appropriate security policy must be introduced in order to ensure that no ePHI is corrupted or wrongly modified during transmission.

Auditing
A robust mechanism for collecting information about all actions performed with ePHI (access, modification, transmission, etc.), allowing easy monitoring and analysis must be developed.
A mechanism to ensure that ePHI is not deleted or modified without proper permission has to be devised.

2. Physical Safeguards

The purpose of physical safeguards is to regulate access to the location where ePHI is stored (be it local server, cloud, or third party service).

Physical access
A security plan to protect the facility from any unauthorized access, data corruption, or theft has to be prepared.
A set of procedures validating and controlling a person’s access to the premises must be developed.
A backup plan defining procedures for accessing the premises, and data recovery in case of emergency must be put together.
Any modifications, changes, maintenance procedures for the physical facility must be carefully documented.

Storage control
A procedure for tracking the final location of the ePHI and disposal process for the hardware on which it is stored must be developed.
The process for complete removal of ePHI from any device that is intended to be re-used must be designed.
Tracking of each person responsible for the movement of the ePHI must be set up.
An accurate and complete copy of the target ePHI must be created before any relocation.

Workstations
Physical access control to all workstations must be provided to only allow authorized users.
A list of functions that can be performed with ePHI and how these functions are performed must be determined.

What Is Considered As Protected Health Information?

For information to be classified as ePHI, it has to:

• be stored, recorded, or transferred to a covered entity
• be personally identifiable

Who Must Be HIPAA Compliant?

If the company is involved in managing, using, storing, or transferring electronic protected health information (ePHI), it must be HIPAA compliant. Failure to do so leads to huge fines. So, the company has to clearly decide upfront if it is critical for their business to “touch” ePHI, or if they can make do without it.

What Should Developers Do?

As you can see from the list of items above, HIPAA compliant software development is not a trivial task. Therefore, the decision to pursue this endeavour should be carefully thought through. There are three possible paths to take:

1. Decide not to deal with ePHI at all. No ePHI, no HIPAA compliance necessary. No HIPAA compliance, no problems.
2. Develop HIPAA compliant software yourself. Some requirements are pretty straightforward and are implemented in many software solutions regardless of their intended use.
3. Delegate the challenge of becoming HIPAA compliant to a competent third party. Usually, they guarantee compliance to all standards, because this is what they specialize in.

HIPAA penalty system

To further underline the importance of choosing the right track from the three choices above, we want to talk about the consequences of doing something wrong – fines and penalties.
Failure to comply with a HIPAA provision can cost a fortune! The price tag of a single violation ranges from $100 to $50,000. The maximum fine for violations of one provision is $1,5 million! The figure is proportional to the number of people affected by the breach, and the extent of the neglect.
To keep our bank account intact, we need to be aware of the typical situations or conditions that can lead to breaches and take actions accordingly.

Sources of breaches

• No or poor encryption – you want the ePHI to be encrypted at all times with an advanced encryption algorithm. If the device holding ePHI is lost or stolen, encryption is the only measure to prevent the criminal from accessing and using the data.
• Portable devices – in the age of mobility, access to ePHI is becoming available from all sorts of devices (laptops, tablets, smartphones). These are, however, prone to lose or theft, so it would be smart to store the data in a protected cloud or server, but not on the device itself.
• Human factor – employees are often the weakest link in a security system. Breaches can result from simple human error, negligence or stupidity, but either way, they have to be pre-empted with regular training and fool-proof software.
• Third parties – business associates “starred” in over two-thirds of all breaches. Since for the most part, these were not healthcare professionals, they may have easily underestimated the importance and sensitivity of the data they had in their hands, so choosing business partners carefully and instructing them properly is critical.

Key Concepts to Take Into Consideration

• A common make vs buy dilemma is applicable to building HIPAA compliant software as well. Even though implementing some safeguards may be a routine task for a programmer, other provisions may be more convoluted and require exponentially more resources. In such cases, the outsourcing option is worth evaluating.
• Sometimes it may be difficult to recognize that your software is using ePHI, and consequently, that HIPAA compliance is required. It is difficult to predict for all the possible uses (many of them unintended) that the app may have.
• HIPAA compliant hosting is a crucial part of having an overall HIPAA compliant software solution, so pick your host wisely.
• Not all of the data that your application works with must be stored on a HIPAA compliant host. It’s only the ePHI that is picky about that. Other data can use a cheaper conventional form of hosting.
• You cannot go too far with security, so in addition to protection measures provided by the hosting company, be sure to guarantee protection on network and application levels as well.
• Be redundant. While it may sound counterintuitive at first glance, this may prove a life-saving (and business-saving) decision in the future. The critical nodes of your system (such as web server and database server) must have a backup.

Mobiles & Wearables

Even the most portable devices now have the power to carry advanced software and perform all sorts of operations after a few taps. As the functionality is expanding at lightning speed, and no strict regulations exist, it is important to think about possible complications that may pop up when using such sensitive data as ePHI.

• As mentioned in the previous section, it is often hard to envision how the user will use your app. Think twice about any possibilities for the data stored in your app to be classified as ePHI.
• Communication. A lot of apps allow you to set up automatic email or push notifications. These are rarely secure by default, so either carefully analyzes what data can be sent over such a channel, or set up a reliable encryption algorithm.
• If your app requests data from a covered entity server, it must be HIPAA compliant. The same is true for any other type of integration with another business associate or covered entity.
• Although software developers can do little in the case of physical loss of a mobile device, some steps can still be taken. Recommend users who install your app to enable a lock screen with a passcode. Another thing you may only recommend doing is to take advantage of remote deletion functionality on the device – this may enable the user to remove ePHI from the lost/stolen gadget using their laptop, for example.
• More and more wearables are behaving partly as medical assistants or coaches. Check with the FDA to see what the classification criteria for medical devices are and whether your app meets any of them.

Wrapping Up

Developing a HIPAA compliant software application is definitely a challenge. It resembles putting together a 3000-piece puzzle – a lot of pieces are involved, and many of them are interrelated. The price of each mistake is high, so thoughtful planning, in-depth analysis, and flawless execution are of paramount importance. This article puts you in the picture of what is required and what the options are. We also recommend reading a case on this topic and looking at the case study on our blog.