HIPAA Compliant Architecture Best Practices

The Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule deals with technical safeguards for your application architecture best practices. It discusses a number of standards such as encryption and access control. While these high-level concepts are included in the Privacy Rule, in general, there are no specifics about how to accomplish these standards. For instance, while encryption can and should be implemented using SSL or TSL, HIPAA does not deal with the exact details of implementing encryption. This makes sense. Technology and security implementations evolve much faster than the government can amend bills, so really it should be in the hands of covered entities to make implementation decisions.

That being said, if you look at the HIPAA implementation guides for different cloud architecture providers, you will realize that it is very much best practice to err on the side of caution, especially when it comes to security controls. This generally results in more expensive servers that require higher maintenance. Security and compliance are not areas you want to skimp on when dealing with HIPAA. Below we will discuss some of the components of security that you’ll want to think about before setting up your HIPAA application to ensure that you remain HIPAA compliant.

HIPAA Cloud Infrastructure

There are many areas of your cloud infrastructure that you will have to take a look at when taking on HIPAA. If you work in DevOps, chances are you are familiar with the concepts below. If you are a backend or full stack engineer, managing servers that deal with HIPAA compliance will be a journey.

SSL & TSL Certificates

Easy enough. Your applications will need SSL certificates. It’s best practice to just disable unencrypted connections when possible. At the least, your unencrypted connections should redirect to encrypted connections. We like to use LetsGo for SSL certificate management. Auto-renewing certificates so that they don’t expire is a nice bonus. These certificates are probably the easiest area of HIPAA-compliant architecture to setup.

Isolated Environments

Again, rather straightforward. Your development environment shouldn’t share resources with your staging environment. Your staging environment should share resources with your production environment. You may choose to run a production VPC that is separate from your staging or development VPC. Ultimately your different environments should not connect to each other or rely on each other in any way. There are many reasons why it is best practice to have different environments be isolated from one another. For example, if you only want to grant access to production data or production servers to a subset of your team, having your development environment and your staging environment separate from your production environment makes setting up access controls safer and easier.

Access Control and Permissions

Long story short, only give access to those that need it. Be extremely aware when you grant someone access to protected health information. We prefer to have a very small number of engineers that have access to production data, servers, or other resources. If you are allowing contractors access to PHI, make sure you’ve signed a Business Associate Agreement with them beforehand. Handling PHI responsibly is absolutely key to remaining HIPAA compliant and not breaching laws or rules.

Read-only Databases

In every application, it is best practice not to connect to a database with written permission. With PostgreSQL, you’ll want to setup a read-only follower database and make sure that any reliance’s on data are connected to that instead of your production application database. Access control for your read-only production databases should be rather strict, with only a very limited number of trusted individuals or services having access to them. This is because these databases almost always contain real user data and, more specifically, private PHI. Limiting who can connect to a database that contains PHI is key for HIPAA safeguards.

Cloud Storage

There are a number of different options for HIPAA-compliant cloud storage. We prefer to use Amazon S3 buckets for various reasons. Ensure that your cloud storage provider is HIPAA compliant. Additionally, make sure to setup strict user permissions. With AWS we like to add another layer of security by only allowing our production application to connect to our production S3 bucket and only exposing expiring asset URLs to users. That way your users never know the path of your resources in S3, and if there’s any issue with an asset its URL is not in the wild.

Here you can also see an overview of Amazon S3 HIPAA compliance.

Network Configuration

Keeping your network safe is key to keeping bad players out of your systems. Keep connections to your HIPAA-compliant architecture secure. Use private VPCs,, public VPCs, and secure and encrypted connections for whitelisted individuals to ensure that no service or human is accessing your servers that shouldn’t be. Be extra cautious with connections to your production servers or databases.

Infrastructure and Application Monitoring

In general, when it comes to HIPAA compliance you should expect to have to pay more attention to your infrastructure and resources. Automated monitoring for your servers, application, and monitoring for your other pieces of your HIPAA-compliant architecture is key. You want to be notified when something goes wrong, and you want information about what the issue is so you can address it as quickly as possible. On AWS, you may use CloudWatch to do this sort of monitoring.

Infrastructure Logs, Application Logs, and Audit Logs

Logs, logs, logs. Monitoring tools are not enough by themselves. When it comes to “who did what”, you will want infrastructure access and activity logs as well as application-level logs. When things go wrong you want to be able to prove that you did what you could to correct them. Logs are crucial to debugging and fixing issues. Again, make sure you have access controls in place so that only the right people have access to production logs. Also, make sure your production system is logging an appropriate level of activity. In general, we prefer not to put phi or patient data into logs but want to keep enough information so that our logs are useful. If you are using AWS services, then AWS CloudTrail might be of help to you in implementing your logs.

Database Backups

As with all systems, you will want automated database backups. We recommend keeping these in secure cloud infrastructure and not on a laptop in your house. Don’t store backups on a machine that is not encrypted or that you can lose. If you do, all of that PHI data could be compromised.

Application-Level Permissions and Security

Security should be built into your development process. Ensure that your codebase has tools for specifying and testing which users have access to which resources, and ensure you only respond to HTTP requests successfully in the right situations. Use code reviews and pull requests to let developers get the eyes of their peers on code that’s being introduced to production. Furthermore, installing security monitoring tools like Code Climate within your continuous integration setup is great for catching common security attack vectors. It doesn’t matter how secure your infrastructure is if you write insecure code.

Write Automated Tests

This should go without saying, but write automated tests for HIPAA applications. Don’t leave it up to developers to keep everything in their brains. Unit or integration rest the different roles, access levels, and permissions within your system to ensure that your application has the right security controls built in.

Use Continuous Deployment

For many, this is another obvious one. But it bears repeating. Take the manual work out of your deployment process. Manual deploys cause issues due to human errors. Automate your deploys using continuous integration and continuous deployment. For new code, make sure all of your tests are running and any lingers, or security checkers run before you merge and release your work.

Make your Business Associates conform to your Standards

If you are working with any other company that has access to PHI within your systems, make them conform to your processes. While a Business Associate Agreement does establish shared responsibility for HIPAA compliance, it is best to ensure that everyone operating within your systems uses the standards that your own team establishes so that you are aware of all of the security concerns that could exist.

For more abounding information about how Business Associate Agreements work on HIPAA and the types of Business Associates. 

Heroku vs AWS for HIPAA

As you can see from the list above, there are quite a few areas to pay attention to and consider when making your application HIPAA-compliant in the cloud. One key decision point that you will have to make in setting things up is whether you want to maintain all of this architecture. AWS has HIPAA-eligible services to help with pretty much everything listed in this article. But, you still have to get to know each of those services and maintain them. An alternative worth considering is using Heroku for HIPAA applications. Using Heroku’s Private Shield is pretty much as simple as using their normal service tiers. The key difference is that you can basically flip a switch to have them manage the items above. It does cost quite a bit more than AWS resources, but it is worth considering in this situation.

And More…

Above are the key elements of HIPAA security that we think of when building out HIPAA-compliant architecture. HIPAA security is something that you never stop thinking about once you determine that you are a covered entity. Thus, this article is intended as a list of best practices to guide you toward HIPAA security, but ultimately you should consult with security professionals on an ongoing basis to make sure your architecture is in check.

Help with HIPAA Compliance

If you need help getting your application up and running on HIPAA-compliant cloud architecture, we would be happy to help. We are experienced in setting up managed cloud providers like AWS, as well as PaaS solutions like Heroku. Contact Flatirons.