TL;DR
HIPAA compliant architecture can be simply deployed using the AWS boilerplate. This post covers some background of both business and technical aspects. The following is a breakdown of the components delivered by AWS. If you’re familiar with these, you may find more interest in part two, which goes into depth on certain areas where the boilerplate falls short, as well as some applicable suggestions to improve them.
HIPAA
The Health Insurance Portability and Accountability Act is a set of five titles. Set by the Clinton administration back in 1996, it deals with all aspects of healthcare, from insurance to tax. This post discusses Title II: “Preventing Health Care Fraud and Abuse,” which regulates how health organizations manage, handle and process private health information. More specifically, we’ll take a close look at the aspects of Title II that deal with IT cloud infrastructure.
HIPAA was expanded in 2009 by the Health Information Technology for Economic and Clinical Health (HITECH) Act. HIPAA and HITECH establish a set of federal standards intended to protect the security and privacy of PHI.
- AWS HIPAA Compliance Whitepaper
Terminology in the text
- HIPAA - Health Insurance Portability and Accountability Act, Title II
- PHI - Protected Health Information (“…wide set of personally identifiable health and health-related data…”)
This post intends to help startups in the health industry to become familiar with HIPAA IT requirements. It discusses building cloud infrastructure to process protected health information (PHI). Both new and experienced teams should find value in it.
Signing AWS Business Associate Addendum
“You can use AWS to run sensitive workloads regulated under the U.S. Health Insurance Portability and Accountability Act (HIPAA). If you plan to include Protected Health Information (as defined by HIPAA) on AWS services, you must first accept the AWS Business Associate Addendum (AWS BAA). You can review, accept, and check the status of your AWS BAA through a self-service portal available in AWS Artifact. Any AWS service can be used with a healthcare application, but only services covered by the AWS BAA can be used to store, process, and transmit Protected Health Information under HIPAA.”
- Healthcare Compliance in the Cloud
Starting out
AWS declares its platform to be a HIPAA-compliant environment, one that provides services that enable healthcare providers to process and store PHI. That being said, AWS as a platform is not responsible for its users, who themselves must ensure that they meet regulations. Not all of the AWS services are “HIPAA eligible,” and the list of eligible services is constantly updated and can be found here.
AWS’s whitepaper on “Architecting for HIPAA in the cloud” dictates a number of important aspects which we’ll break down and address:
• Decoupling protected data from processing / orchestration
• Tracking where data flows using automation
• Have logical boundaries between protected and general workflows
- AWS Architecting for HIPAA in the cloud
Decoupling protected data from processing
In healthcare organizations, databases usually hold PHI. Thus, they need decoupling and the highest security standards around them.
Databases are the holy grail of organizations when it comes to security, as they contain users’ passwords, keys, and other personal information. In the health industry,safeguarding PHI is the primary goal of database security. As such, the information storage has to be set in its own networking subnet. A dedicated security group should be controlling its networking reachability. The combination enforces a single controlled point of access, allowing only specific entities to reach the server and data within.
According to best practices, as described in the AWS Well-Architected guidelines, databases should reside in private subnets (i.e. there’s no public access from the internet. This is ensured by a routing table that directs all outgoing traffic to a NAT gateway). These private subnets should be protected by a security group with two entries in the inbound section:
- Access to the backend applications subnets (also private)
- Access to the VPN security group
Takeaway
Databases should reside in dedicated private subnets. These subnets should only be accessible from backend (private) subnets. A common practice is to allow the VPN and/or bastion host to access them too.
Tracking where data flows using automation
CloudTrail, CloudWatch and Config rules help to track the environment state. A rule breach triggers an alarm to report the changes and what’s required to restore safety.
Have logical boundaries between protected and general workflows
The order of importance of an application’s protected assets starts with its data. Next is the application’s backend that implements the logic. The infrastructure should protect both by isolating them from each other. It should also hide them from public access. By compartmentalizing, only specific protocols and ports allow communication. This enforces a risk-free zone and allows for easy disconnection in case of an emergency.
SAASing out to Heroku
Heroku is one of the major, go-to platforms in the market. It’s a PAAS that provides automated solutions for small teams and organizations. As a user, you get both a fluent deployment process and a HIPAA-compliant infrastructure.
It’s important to say that Heroku itself uses AWS. Availability and scale are not a question when choosing one of the two. The automated, fast, scaleable service attracts customers from all over the industry. Having HIPAA and similar compliance built-in is irresistible for many customers.
Things start to get a bit “heavy” when the team needs to scale out. Whether extra computing power, storage, DB or extra services.
The usual buy-in process includes a short negotiation with the Heroku sales team. More often than not, it leads to small startups paying thousands of dollars a month. Usually, for a system, it could have deployed on its own, and for a fraction of the price.
To be honest, presenting things in a manner of “this amount of money vs much less if you do it on your own” is wrong. People often neglect to consider man-hour and salary costs. The level of services and offerings such as Heroku’s is nothing to underestimate. Yet, does the price make sense? To some, this is a decisive “yes”. Many others only consider the question late in their journey. “Pick up your things and leave” when it comes to cloud infrastructure (or anything for that matter) is not easy. One should always plan forward and consider costs regardless of technology.
Having that said, let’s see: how hard it is to create your own HIPAA compliant infrastructure in the cloud?
I would say: not too difficult
There are a few important decisions to make. A small investment of time and limited effort can produce a long term costs-minded system. Here are a few keep points to keep in mind:
- Know and understand the security concepts and rules to follow
- Think automation, both for productivity and security reasons
- Pick a technology that suits your needs
- Consider possible business-specific effects - whether growing scale, seasonal demand or others
In the next post, we’ll be diving into these key points. Along with technical details of what, how and when.
