As part of my work out of IdeaLab and building secure and federally compliant digital health companies and products, I get asked several times about HIPAA compliance and ways to achieve it. These questions are from different viewpoints and use cases such as investments, enterprise usage, insurance, technology-related etc.
At its heart, HIPAA is about giving the right of the protection of the privacy and security of patients identifiable information. There is a lot of stuff which has been written about it in different blogs and news site but I wanted to put together a simple checklist which deals with some things that every company can take in order to work towards HIPAA compliance. This list is also applicable to digital health and Healthcare IT startups which are now sprouting across the country. Vendors who deal with healthcare companies and data can also use this list as a starting point. HIPAA compliance is not just necessary from the standpoint of compliance (and marketing as companies tend to use it for), but also a good way to avoid expensive data breaches. Here are examples of some ways healthcare data is breached: http://www.artilient.com/10-ways-that-healthcare-data-gets-breached/
As a disclaimer (and as required of me by my legal team), I am not providing legal or security advice. I am sharing some of my own experiences as part of building digital health products and companies out of IdeaLab. This list is by no means a complete checklist and I would like to welcome other experts to contribute to this list and share their experiences as well. Please always consult your legal and security advisory team also before implementing any changes.
1. Hosting: All your databases should be hosted with companies which offer a Business Associate Agreement (BAA). Your databases may contain potentially sensitive data (such as confidential Protected Health Information or patient data) and thus it is important to use a premium service which offers a BAA.
Here are some examples of companies which offer a BAA to healthcare companies which meet specific criteria:
I personally like to use AWS for our products and companies out of SeedHIT for the ease of use, pay-what-you-use and DIY tools it offers to its users.
2. SSL encryption: Obtaining an SSL certificate from a reputable provider ensures that there is secure transmission going on between the browser session of your users and your servers. Strong encryption can reduce the chances of your data communication being overheard by an unauthorized person during transmission.
A padlock icon and “https” in the address bar indicates that SSL encryption in transit is taking place.
There are several levels of SSL available starting with 128-bits. For HIPAA compliance, use a minimum of 256-bit SSL. You can upgrade to as much as 2048-bits if you would like (or your enterprise clients insist upon).
Some vendors for SSL certificates include:
Symantec (formerly VeriSign): http://www.symantec.com/verisign/ssl-certificates
For those who are interested in more detailed reading about how encryption applies to medical providers, I thought this article from the American Medical Association was very useful: http://www.ama-assn.org/resources/doc/psa/hipaa-phi-encryption.pdf
3. Encryption at Rest: This requires that all your databases and file systems as well as servers and disks are encrypted. This reduces the likelihood of PHI being accessed by unauthorized persons in the event of hacking or theft.
Here are some companies whose products can be used:
Truecrypt: http://www.truecrypt.org/ (Open source)
Microsoft Encrypting File System: http://windows.microsoft.com/en-US/windows7/What-is-Encrypting-File-System-EFS
4. Audit trail program: Ensure that all actions and interactions of all your users are tracked along with their timestamp. Also, al
l processes happening within the system need to be tracked. From the user standpoint, think about it as: WHO did WHAT, WHEN was it done and WHY was it done.
This is useful in the event of any audits that might be needed as part of data breaches and determine
5. Data retention rules: Ensure that all your data is archived after last use for a minimum of 7 years and available upon request by an authorized person or entity. In the event that the data belong to the PHI of a child younger than 18 years old, then ensure that the data is available for at least 7 more years after the child turns 18 (adult) and after last use. To be on the safe side, consider retaining all data for 25 years after last use. Of course, there is a significant cost factor to this.
Here’s a comprehensive report from US HHS: http://www.hhs.gov/ocr/privacy/hipaa/enforcement/examples/disposalfaqs.pdf
6. Session timeouts: Ensure that a client session times out and logs the users off automatically after 3-minutes of non-activity. This helps with non-authorized access to PHI. When the user wants to re-use the system, he/she will be required to log back in with full credentials.
Subscribe to latest posts
7. BAA with vendors: Any time you use a vendor such as programmers or consulting companies, make sure you execute a BAA. When it comes to vendors touching live PHI (such as production support and SysAdmins) should be doing so from within the continental United States.
8. Have secure backups done of your data: Make sure you take back-ups of all your data and databases. Of course, all storage of these back-ups should be done with HIPAA-compliant storage companies only which offer BAA’’s (as mentioned in #1 above). Ideally you want to back-up your data in a vendor and location which is different from your primary data storage. Also, all back-ups just like primary data should be encrypted.
This is required for disaster recovery and emergency operations.
9. Restrict access to right people/ unique user identification: Establish the right policies and procedures to ensure that only people who should be accessing certain aspects of your application and / or tPHI are able to do so. This access should also be tracked using an identifiable number or user name which is unique to the specific person. This identifiable information should be contained in the Audit Trail (#4 above). As an eg., a user’s email ID could be used to create a user name in order to grant that user access to your application and any PHI, if required.
Also, there should be a way to establish access to PHI in the event of emergencies such as natural disasters and technical crashes.
For more details, check out: http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf
10. 2-factor authentication: In order to establish an additional layer of verification on the users access PHI within your system, establish a second authentication layer on top of the username and password asked as part of the login information. This could be implemented in several ways such as:
— Asking for information such as pet’s name
— Calling or texting the mobile number associated with your account
— Using a security token for a 2nd randomly generated password
This ensures that in the event the user did not follow proper protocol for their login, a 2nd level authentication will hopefully be able to prevent unauthorized access.
For more details, check out: http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/remoteuse.pdf
BONUS (10 + 1)
11. Using secure email: Ensure that all data and PHI being used in any communication remains on a HIPAA-compliant server. This relates to #3 above. Thus, it is important to use a company which provides such an email service. I personally use SafeDr for this (Disclosure: SeedHIT has developed and owns SafeDr).
I would love to hear other safeguards that you have implemented in your company which either stored PHI or has access to it as a vendor. Here’s the complete list of HIPAA tecnical safeguards too for your reading pleasure: http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf