Health Insurance Portability and Accountability Act (HIPAA) Security Requirements

Any organization that deals with Protected Health Information (PHI), that is any health information that can be linked to an individual user must be handled in such a way as to maintain the integrity and privacy of the information.

There are many safeguards that need to be considered, some administrative and some technical in nature. We’re going to focus on the technical ones here.

Technical Safeguards

The technical safeguards can be broken down into broad categories focusing on Physical Safeguards, Access Control, Transmission Security, Device/Media Controls, and Workstation Security.

When considering technical safeguards it is important to note that many of the safeguards are strictly required and others are addressable. Addressable in this instance does not mean optional, but implies it must be considered and assessed if it is feasible to implement it, if it is determined to be impractical it must be well documented why that conclusion was made.

Access Controls

Access Control safeguards are concerned with keeping track of individual users of the application in order to restrict access to only those people who need to view the PHI. It is required that each user be assigned a unique identifier, and that they must authenticate with the system to prove they are who they claim to be. It is also required that a plan is put in place so that the PHI can still be accessed in an emergency situation.

On an application-by-application basis it must be considered whether automatic log-off from the application is needed, though it is generally considered a best security practice and as such should be implemented.

It must also be considered that the PHI should be encrypted and decrypted as necessary. Since this is in the access control section I assume it refers to the situations where the PHI is at rest on file systems, in databases, and stored on backups. Like the automatic log-off above this is considered a best practice for security so there should be little reason to avoid doing it.

Transmission Security

With regards to Transmission Security the HIPAA only mentions two safeguards; integrity controls, and in transit encryption, both of which are considered addressable. Integrity controls are a means to ensure that attempts to tamper with the records should be detectable for the lifetime of the record. Given that an audit log must be built in to the system (discussed further down) it only makes sense to include appropriate checksums or digital signatures to ensure data access and modification is both logged and verifiable.

As for the in transit encryption if the application is going to communicate on the Internet there aren’t any valid arguments for not encrypting PHI in transit. One could however make an argument that it wouldn’t be needed if the application in question were only to be used internally on a secured network. Given the rarity that a system operates under those conditions and the ease of configuring SSL even under those conditions it would still be advisable to enable in transit encryption.

Audit and Integrity

All applications handling PHI are required to implement mechanisms to facilitate auditing actions taken with regards to the PHI and other actions performed within the information system.

The system should also address a means to ensure that the the PHI has not been altered or destroyed in and unauthorized manner.

Physical Safeguards

The intention of the physical safeguards are to prevent access to the equipment where PHI is stored and as such I won’t go into much detail, it is worth mentioning that if you are making use of a vendors data center you will need to discuss with them if they are HIPAA compliant.

If all of your application data is self hosted you’ll need to consider how emergency access will be managed, who is permitted access to the equipment, and maintenance records for computer equipment and physical security hardware such as walls, doors and locks.

Do note that not all data needs to be maintained in HIPAA compliant facilities, only PHI data needs the extra safety precautions. For instance if you were to serve up front end JavaScript from a CDN you wouldn’t need to give special consideration to what CDN to use or worry about where mobile application binaries are distributed from.

Device and Media Controls

It is required that a procedure be put in place to securely remove PHI from any devices or media that had been used to store it regardless of whether that media will be returning into circulation or destroyed.

When equipment is being moved a verifiable and identical backup of the PHI should be created to safe guard in case of equipment malfunction during movement or migration. At the same time a record should be kept of the movements of and personnel responsible for the any media containing PHI.

Workstation Security

Any workstation that will access PHI must have physical security measures put in place to prevent unauthorized users, and policies need to be established to describe what functions can and how they are to be performed on the workstation.

Mobile Considerations

If one considers a mobile device to be a workstation there must therefore be measures put in place to prevent unauthorized use in the form of device encryption and enforcement of lock screens.

There are other vectors to consider where data could inadvertently leak from the mobile application such as by putting any PHI in a notification that may be displayed even when the lock screen is on.

Remember that in order to interface with any systems that store or transmit Protected Health Information your applications must also adhere to the HIPAA because unlike other legislation there is no safe harbor conditions when dealing with PHI.