When I first started developing HIPAA compliant software I had been developing custom software for 9 years. But I had never had to develop a HIPAA compliant solution. Like a lot things in life I figured, no biggie, I'll do some research and figure this out.

Boy was I in for a surprise how nebulous the law is and how wide the varieties of interpretations were.

What came out of all that research turned out to be our guiding principles.
Something I came to call the Pillars of HIPAA. It serves as a pretty decent introduction into the basics of securing HIPAA data.

Eight of these were developed pretty early on. Five more were added over the course of the next six years.

When we went for HITRUST Certification, we were positioned pretty well with just these pillars. Yes, the Certification required us to codify a more formal IT Policy. And in no way am I saying these pillars are the equivalent of HITRUST Certification. But I do believe the 105-page IT Policy that ensued doesn't do that much more than these 13 pillars below did to secure data in a HIPAA compliant system.

1. Encryption in Transit - all data is encrypted and transferred using a 128-bit SSL secure connection.
2. All access is controlled by an individual username and password for every employee.
3. Every page view and action is logged - including date, time and IP address.
4. PHI is always hidden unless an employee purposely chooses to see it, in which case a special entry is logged.
5. All PHI is stored in the database in an encryption at rest state - i.e. a social security number of XXX-XX-XXXX would be encrypted and stored as WhvNDTdXAPJYzWajhkXegzfX...
6. All PHI (which is already encrypted) is stored in a separate table from other identifying information. As an example, names and addresses are stored in a separate location than Social Security numbers and Medicaid IDs.
7. Permissions for all employees are set on an individual level using the Principle of Least Privilege - access to information is reviewed and granted on an individual level.
8. All member related data is not accessible outside of our internal network without the use of 2-Form Authentication via Google Authenticator and a proprietary key. This conforms to algorithms specified in RFC 6238 and RFC 4226.
9. All reports are generated with minimal information needed.
10. The server can only be accessed via SSH/SCP - since FTP connections are unencrypted, they are not allowed on the server - SSH/SCP is more secure than FTP and SFTP.
11. SSH/SCP access is only granted via security keys (no passwords) - thus preventing brute force attack attempts - this method is much more secure than a traditional username and password method.
12. Our firewall only opens the following ports: 80/HTTP, 443/HTTPS, 22/SSH to the outside
13. All versions of Linux, PHP, Apache and MySQL are long term stable (Ubuntu 18.04.x LTS / PHP 7.2.x / Apache 2.4.x / MySQL 5.7.x).

After going through HITRUST Certification for one of our Customer's systems, I would add the following four as well.

14. Force logoff system after 15 minutes of inactivity
15. Include warning messages on all systems (Web or SSH sessions) that informs an individual they are entering a system with PHI and their actions are monitored
16. Implement a DLP solution for Email that includes the ability to send secure
17. Implement annual third party penetration testing and risk assessment