When we started building the Wellpepper platform four years ago, we thought carefully about how to build for privacy and security best practices as well as HIPAA compliance, since we work with customers in the healthcare industry. We chose to build the system entirely on Amazon Web Services (AWS), and learned a few things in the process about building HIPAA compliant applications on AWS. Hopefully this will be helpful to others considering AWS as the home for their healthcare online service, whether you’re a software company hoping to sell to healthcare systems (as a “Business Associate” in HIPAA terminology) or an internal development team at a health system (a “Covered Entity”).
It’s Not Rocket Science
As you probably already know, the Health Insurance Portability and Accountability Act (HIPAA) is made up of several parts. Usually when IT people talk about “HIPAA compliance”, they are talking about the Title II Security Rule which governs privacy and security practices for electronic protected health information (ePHI).
Many of the requirements in the HIPAA Security Rule are simply best practices for security and data privacy that have been written into law. Things like encrypting traffic travelling over a network. Anyone building good, secure software, should be following these principles anyway. You need to be informed of the requirements, and you need to make sure you establish ongoing practices for maintaining security and privacy, but it’s not rocket science. In fact, your health system (or healthcare customers) may actually have more stringent or additional data security requirements to what is required by HIPAA.
Our experience is that HIPAA isn’t a major departure from what we would have built anyway.
Stay Up To Date
HIPAA was established in 1996, with the final Security Rule being published in 2003. In some cases, the guidance has not kept up with current threats and practices in 2017. If you are developing healthcare software, you should be applying industry best practices in combination with the HIPAA requirements. Your ultimate goal needs to be protecting patient data, not just regulatory compliance. Invest in training yourself and your team and staying current. Some resources we found helpful:
Compliance usually isn’t at the top of an engineering team’s list of fun things, so it’s tempting to look for solutions that can abstract away the responsibility. There are a few online healthcare platform-as-a-service hosters that make claims in this direction. Be wary of these. No service can remove your responsibility for compliance.
We decided that using AWS infrastructure services was the best level of abstraction. This let us build new services, host data, and install 3rd party applications in our VPC with high confidence that we were living up to our promises to protect patient data.
In addition to thinking about your software solution, compliance also covers your business practices and policies for things like training, background checks, and corporate device security – securing your people. These are often overlooked areas that are really important, since security researchers complain that people are the weakest link in the security chain. As with your software design, the application of commonsense practices and good documentation will go a long way.
There is no single group that certifies systems as HIPAA compliant. However, HHS can audit you at any time, whether you’re a covered entity or a business associate. You should do your own internal assessments against the HIPAA Security Rule both when you are building new capabilities, and on an annual basis. Augment this with external third party reviews. You’ll want to be able to show summarized reports of both your internal process and a stamp of approval from an external auditor.
HHS produces a tool called the SRA tool which you might find useful in performing security rule assessments: https://www.healthit.gov/providers-professionals/security-risk-assessment-tool. We used this for a couple years, but now just use an Excel Spreadsheet to evaluate ourselves. Bonus: this is probably what your auditor will want to see.
This Risk Toolkit from the HIPAA Collaborative of Wisconsin is a good starting point, and looks very similar to the spreadsheet we use: http://hipaacow.org/resources/hipaa-cow-documents/risk-toolkit/ (look at the Risk Assessment Template).
Share the Responsibility
AWS certifies a subset of their services for HIPAA compliance. This includes restrictions on how these services are used, and requires that you enter into a Business Associate Agreement (BAA) with AWS. This agreement establishes the legal relationship needed to handle ePHI, and ensures that you’ll be notified in the unlikely event that there is a data breach.
When you sign a BAA, you enter into a shared responsibility model with AWS to protect ePHI. AWS largely covers physical security for their facilities and networks. You can view their SOC audit results on request. You own the security for your applications and anything else from the OS on up. For example, if you use Elastic Compute Cloud (EC2) instances, it’s your responsibility to keep those instances patched.
AWS occasionally adds new services to their HIPAA-certified services, so you’ll want to check occasionally to see if there are new services you might be able to take advantage of.
Draw a Bright Line Around Your ePHI
At any time, you should be able to quickly say exactly which parts of your system (which servers, which network segments, which databases, which services) have or store ePHI. These systems are inside your bright line defense perimeter, are subject to HIPAA regulations including breach notifications. That means if you lose data on one of these systems, you need to notify your patients (or if you are a Business Associate, notify the Covered Entity so that they can notify the patients).
EC2, Simple Storage System (S3), Elastic Load Balancing (ELB), when used in accordance with guidelines can be HIPAA compliant. Make sure you read the guidelines – there are usually certain restrictions on usage in order to be covered. Many of AWS’ platform-as-a-service offerings are currently not offered under the AWS HIPAA umbrella (for example Kinesis and Lambda). You can still use these services, just not with ePHI.
Many modern systems designs make use of 3rd party framworks and SaaS offerings for things like analytics, monitoring, customer support, etc. When you are holding and conveying ePHI, you will need to be careful about which dependencies you take. For example, in one of our recent product updates we were considering using an external web & mobile analytics platform to better understand our traffic patterns. We walked through our use cases and decided that while none of them required us to send any ePHI to the analytics platform, the risk of accidentally sending some piece of protected data was too high. So we came up with a different plan that allowed us to keep PHI within our safe boundary and under our direct control. Many of your decisions will be grey-area tradeoffs like this.
Secure at Rest and Over the Wire
This is often the first question we see on any healthcare IT security review. How do you protect data at rest and over the wire? Use strong SSL certs with robust SSL termination implementations like ELB. If you terminate your own SSL connections, they need to be well patched due to evolving threats like Heartbleed, POODLE, etc. You may choose to do further application-level encryption in addition to SSL, but SSL should usually be sufficient to satisfy the over-the-wire encryption requirements.
For at-rest storage, there are many options (symmetric/asymmetric) that will depend on what you are trying to do. As a baseline, AWS makes it incredibly easy to encrypt data with AES-256 both in S3 or in the Elastic Block Store (EBS) drives attached to your EC2 instances. There’s almost no reason not to use this, even if you are using additional encryption in other layers of your architecture. AES-256 is usually the “right answer” for IT reviews. Don’t use smaller keys, don’t use outdated algorithms, and especially never try to roll your own encryption.
Good guidance in this area is easy to find:
Logging and Auditing
A key HIPAA requirement is being able to track who accessed and changed patient records and verify the validity of a record. Even if you don’t make this available through a user interface, you need to log these actions and be able to produce a report in the case of an audit or a breach. Keeping these logs in encrypted storage in S3 is a good way to do this. You’ll want to restrict who has access to read/write these audit logs as well.
In addition to automatic audit trails generated by your application-level software systems, remember to carefully keep track of business-process events like granting someone access to a system or revoking access. AWS CloudTrail can help track system changes made to AWS resources like servers, S3 buckets, etc.
All healthcare applications will need a way to identify their users and what permissions those users have. HIPAA is not specific about authentication systems beyond being “reasonable and appropriate” (164.308(a)(5)(ii)(D)), but does require that you have good policies in place for this. Here you should follow well-established security best practices.
For starters, you should try not to build your own authentication system. In purpose-built systems, you may be able to integrate into an existing authentication system using oAuth, or SAML (or maybe something more exotic if you’re plugging into some legacy healthcare application). In patient-facing applications, you may be able to integrate with a patient portal for credentials – this is something that will probably show up on your requirements list at some point anyway. If neither of these apply, you may be able to use another identity provider like AWS’ Identity and Access Management (IAM) system to manage user credentials. We briefly tried using consumer-facing oAuth using Facebook, but quickly found that consumers are (rightly) worried about privacy and chose not to use this method.
If you find that you need to build an authentication system, be sure to follow current best practices on things like how to store passwords securely, as well as other tricky areas like password resets.
Since Wellpepper is often deployed standalone before being integrated into other back-end systems, we offer a built-in username + password authentication system. One silver lining to building this ourselves is the ability to build meaningful password complexity rules, especially for patients. Some of the traditional healthcare systems have truly draconian rules that are not only user un-friendly, but actively user-hostile. Thankfully, the best practices in this area are changing. Even the draft NIST password recommendations, updated in August 2016, trade some of the human-unfriendly parts of passwords (multiple character classes) for more easily memorable, but still secure ones (length). Also, consider the difference between health-system password requirements for clinicians with access to thousands of records and those for patients who only access a single record.
Once your users are authenticated, they will need to be authorized to access some set of resources. As with authentication, if you can delegate this responsibility to another established system, this is probably the best approach. If you are adding unique resources with unique access control rules, you will need to make sure that your authorization mechanisms are secure and auditable.
Creating a HIPAA-compliant service doesn’t have to be a big scary problem, but you do want to make sure you have your ducks in a row. If you’re reading this blog post (and hopefully others!), you’re off to a good start. Here are some additional resources that we found handy: