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.
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.
Before moving forward, we want to clarify several key terms that are commonplace throughout the HIPAA document:
The core of HIPAA consists of the following four elements (with the first two outlining the actual requirements):
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.
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.
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.
For information to be classified as ePHI, it has to:
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.
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:
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.
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.
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.