Building a HIPAA compliant service..

What is HIPAA?

Health Insurance Portability and Accountability Act of 1996(HIPAA), is a law which provides standard to handle patient data and protected health information (PHI). HIPAA regulations are divided into several rules like- Privacy, Security, Transaction & Codes, Identifiers, Enforcement, Breach Notification, Omnibus final rule.

HIPAA Security rules provides guidance to protect individually identifiable health information which a system creates, receives, maintains, or transmits in electronic form. This information is called “electronic protected health information” (e-PHI). The Security Rule does not apply to PHI transmitted orally or in writing.

Any service which deals with medical data of a person, needs to be HIPAA compliant. The service needs to follow HIPAA guidance, at various layer from the frontend to the persistence storage.

In this article, I will be covering the HIPAA security rules and steps needed for a service to be HIPAA compliant. This is based on my experience in building scalable and resilient HIPAA complaint service at Walmart. Most of these practices are followed to build HIPAA compliant services at Walmart.

What are the HIPAA Compliance requirements?

A service intending to be HIPAA compliant will need to adhere to certain standards in order to be HIPAA compliant. These standards can be broadly categorized into 4 areas.

1. Integrity

The whole idea of this rule is to make sure that data or information is not compromised or destroyed in an unauthorized manner. Integrity of data can be compromised by accidental or intentional changes. Due to technical issues like Hard Disk crash data can be lost. Similarly data integrity issues can arise by intentional or unintentional incorrect data modification.

In order to avoid data integrity issues, systems must follow the below principles.

· Authentication

Any person who needs to access ePHI data be it a customer or a developer must be authenticated. Authentication needs to be followed at frontend, backend, database and server layer.

From the frontend (web pages, native or hybrid mobile apps) before accessing any ePHI info, the user should be asked to verify his identity. For users who are not logged in, only non ePHI information should be presented.

In the backend systems, calls requesting for ePHI info should be verified for authentication headers. In case the authentication token is expired or compromised an appropriate authentication failure request should be sent in the response.

At Server/database layer only authorized user should be allowed to access data. The server and database access should be controlled by centralized AD or a security group, so that only verified users can access data. Shared accounts should be avoided, as these can be misused by developers. Ideally developers should be provided read-only access, so that they don’t accidentally modify or delete any data. Modification of data should be done by a process or an application.

A password-based authentication can sometimes be compromised, so ideally, we should have a secondary authentication like KBA/PIN or a Multi factor authentication. This will provide additional security to the system.

· High Availability of Services

We should try to avoid any downtime of services, which will lead to a loss of access to ePHI data. We should have multiple instances of the service is running across multiple nodes, so that even if one node goes down, other nodes can serve the request. A multi data center setup is preferred, as it will ensure service availability even if there is a data center disaster. All dependent databases/caching layers should be designed for High Availability.

In order to avoid any unwanted loss of data, ePHI data should be replicated across multiple replicas. Multi geography DC setup of the replicated data will ensure, the data is not lost in case of a natural calamity at one geography.

2. Access Control

Access control fundamentally deals with providing the minimum required information to the right user. Any data which does not belong to a particular user, should not be provided to him at any point of time. Similarly, developers and admins should have access to only minimum necessary subset of data.

As a first step we should create different privilege groups, which broadly covers all the use cases of an application and then selectively place users in those groups. By default, users should be placed on a group which has minimum rights on the application. Necessary due diligence should be done while placing a user, in a highly privileged group.

Access control must be in place for both frontend and backend. At the frontend different user experience can be created based on the role of a user. From the backend side APIs should only be accessed based on the role of a user. At the database layer view-based access control can be provided, to restrict everybody accessing all data.

HIPAA also mandates, below specifications for adhering to Access Control standards.

· Unique User Identification

Any user who accesses the ePHI information should be uniquely identifiable. We can use the user-id, email-id, customer-id or any predefined identifier for this purpose. Unique Identifier helps track all actions performed by the user in a particular session.

If the request spans across multiple micro services, and distributed tracing is enabled, in that case there should be a mapping between the distributed tracing id and the unique identifier for the user.

· Emergency Access Procedure

In case of an emergency or an unforeseen outage the system a contingency plan must be in place to provide the ePHI information. Disaster recovery plans for each component must be in place, in order to avoid system unavailability. If this requires a manual intervention, then only required users should be provided access to perform those tasks.

· Automatic Logoff

Any user who logs into the application, should have a default inactive session timeout. If the user is inactive for that duration, user should be forced to perform an authentication on the subsequent calls. Both frontend and backend systems should adhere to this rule.

· Encryption and Decryption

The ePHI data should be encrypted during transit and also during persistence.

For the encryption during transit https protocol should be used. SSL Offloading should not be done at Load Balancer layer. If it is done, then the data should be re-encrypted from the load balancer to the app server.

During persistence, if the database provides a way to encrypt data before writing to storage, that should be enabled. This will ensure data is encrypted even at the backup disks and no unauthorized user can read ePHI data.

If database does not provide an inbuilt encryption feature, then the same can be achieved through application layer encryption. Data can be encrypted before writing to the database and can be decrypted before presenting to the user. The encryption key of encryption algorithm should be changed after a certain period.

While writing logs any ePHI data should either be masked or encrypted. Even at the REST API URIs, if any ePHI information is preset, then that should be encrypted, so that it cannot be read while data transmission.

· Data Retention

HIPAA requires data retention for at least 6-7 years from the date of creation or last accessed, whichever happens to be latter.

The data in the database should be persisted with inbuilt encryption. Even application access logs and system audit logs should be retained in order to identify users whose data has been compromised.

If there are multiple HIPAA complaint services, we can think of building a dedicated system, which maintains the access and audit logs. At Walmart we have a centralized system, which retains all the application access and system audit logs. This helps us in monitoring and identifying compromised users’ info in case of a HIPAA breach.

3. Audit Control

Audit control requires system to have an audit report which will be helpful in analyzing system activity in case of a HIPAA breach. Audit/System log should be captured for all application servers, database, caching layer or any other components used in a HIPAA complaint service.

In order to achieve this, we can decide on a strategy of replicating audit logs to a centralized log server at a regular interval. Even certain application access logs should be replicated to a log server. Then various reporting and monitoring jobs can run on this centralized data on a regular interval. In case of a HIPAA breach, this data can be used to track the users who were accessing the system during that time, also we can find out the users whose data was compromised.

4. Transmission Security

Any ePHI data transmitted over network should be safeguarded from unauthorized interception of information.

Any emails or files which contains ePHI information should be encrypted before sending to clients. Https should be used to connect from client to server. If the body of the email or the attachment has ePHI information, that should be encrypted before sending the email.

Many of the public email providers are not HIPAA compliant, so while sending HIPAA data over email, only a provider which is HIPAA compliant should be chosen.