How to Build HIPAA Compliant Applications on AWS

If you’re a developer creating applications or software that includes healthcare data or related information, you’ll want to make sure that you understand the key legal regulations governing this area. In this post, we’ll take a close look at HIPAA and HITECH regulations, and we’ll show you how to use Amazon Web Services to create HIPAA compliant applications.

What are HIPAA and HITECH?

Advancements in science and technology and overall increasing digitalization has driven the need for standardized practices for securing the safety and security of IT applications and solutions that collect, share, or store healthcare data.

In the U.S., some legislation has been put in place to do just that.

HIPAA. The Health Insurance Portability and Accountability Act (HIPAA) was enacted by the U.S. Congress in 1996. It required the adoption of national standards for “electronic health care transactions and code sets, unique health identifiers, and security.”

HIPAA is divided into 5 titles, and for the purposes of this post, we’ll focus on HIPAA’s Title II: Administrative Simplification. Within Title II, several provisions are included that set national standards for protecting individually identifiable health information.

Its Privacy Rule “protects all individually identifiable health information” (also known as PHI) and covers three entities that conduct electronic healthcare transactions: health plans, health care clearinghouses, and health care providers. This also includes those who transact payment or operations and anyone that has access to patient information.

According to the Privacy Rule under Title II, PHI, or Protected Health Information, is health information that could identify an individual that is “held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper or oral.” HIPAA defines this as information and demographic data that relates to:

  • the individual’s past, present or future physical or mental health or condition,
  • the provision of health care to the individual, or
  • the past, present, or future payment for the provision of health care to the individual,
  • and that identifies the individual or for which there is a reasonable basis to believe it can be used to identify the individual. Individually identifiable health information includes many common identifiers (e.g., name, address, birth date, Social Security Number). 

Also within Title II, the Security Rule sets additional standards for how the covered entities handle and transfer PHI. It requires that the entities must:

  • Ensure the confidentiality, integrity, and availability of all e-PHI they create, receive, maintain or transmit;
  • Identify and protect against reasonably anticipated threats to the security or integrity of the information;
  • Protect against reasonably anticipated, impermissible uses or disclosures; and
  • Ensure compliance by their workforce.
HIPAA components (NIST SP-800-66)
HIPAA components (NIST SP-800-66)

HITECH. In addition to stimulating the adoption and use of health information technology, the Health Information Technology for Economic and Clinical Health Act (HITECH) strengthens the enforcement of HIPAA rules. HITECH was signed into law on February 17, 2009. According to the U.S. Department of Health and Human Services, “Subtitle D of the HITECH Act addresses the privacy and security concerns associated with the electronic transmission of health information, in part, through several provisions that strengthen the civil and criminal enforcement of the HIPAA rules.“

HIPAA resources 

Will you be collecting any PHI in your app? (In addition to the information referenced above, this also includes things like scheduled medical appointments or any related imagery.)

If so, will you be sharing any data with any of the covered entities—medical professionals and hospitals, but also insurance companies? Is it even remotely possible that any of these entities could have access to this information?

These are just a few of the questions that developers should consider to understand whether their application falls under HIPAA regulatory compliance.

The U.S. Department of Health and Human Services website provides several resources for developers. An interactive tool created by the Federal Trade Commission helps developers understand which (if any) rules apply to their work. It asks a series of questions about the app’s functions, what kind of data it will collect, and what it provides to the end user.

Another resource is a platform developed by the Department of Health and Human Services’ Office for Civil Rights that allows developers to ask questions and includes a range of scenarios to help users the understand the rules that apply.

HIPAA compliance in Europe

European health care service providers will generally not be affected by HIPAA obligations if they are not active on the U.S. market. However, since their data processing activities are subject to similar obligations under general European law (including the Privacy Directive), and since the underlying trends of modernization and evolution toward electronic health files are the same, the U.S. Department of Health & Human Services safeguards can be useful as an initial yardstick for measuring Risk Management and Risk Assessment strategies put in place by European health care service providers, specifically with regard to the processing of electronic health information.

Using AWS to create HIPAA compliant applications

Amazon Web Services enables you to process, maintain, and store protected health information according to HIPAA and HITECH compliance requirements. AWS services and data centers have multiple layers of operational and physical security to help ensure the integrity and safety of customer data.

As we mentioned earlier, any application that works with protected health information must HIPAA compliant.

Before you start building your infrastructure and storing any PHI data on your AWS infrastructure, you are required to sign the Business Associate Agreement (BAA) with AWS. This contract will serve to clarify and limit, as appropriate, the permissible uses and disclosures of protected health information.

HIPAA rules generally require that covered entities and business associates enter into contracts to ensure the proper safeguarding of PHI. Under the HIPAA, a “business associate” is a person or entity who performs functions or activities on behalf of, or provides certain services to, a covered entity and isn’t employed by the covered entity. According to this definition, the cloud provider, i.e. Amazon Web Services, is a ” business associate” while the healthcare company or the company that developed the healthcare application is the “covered entity.”

Thanks to the AWS Shared Responsibility Model, AWS ensures that the services marked as HIPAA eligible are HIPAA compliant. AWS aligns their HIPAA management program with FedRAMP and NIST 800-53, which have higher standards than HIPAA.

AWS Shared Responsibility Model
AWS Shared Responsibility Model

After you’ve signed the BAA with AWS, your AWS account will be marked as a HIPAA account, which means that PHI data is processed and stored on that account. All of the conditions that you need to fulfill in order to become HIPAA compliant are listed in the BAA contract. After signing the BAA, you will be notified by AWS in the event of a security breach that exposes PHI.

If you’re selling your application as a SaaS solution, then your clients don’t have to sign the BAA contract with AWS. BAA is transferable, which means that your clients sign the BAA with you where they have the role of the covered entity.

Once you’ve signed the BAA, your next step is to create infrastructure and transfer PHI to AWS (to the AWS account you listed in the BAA agreement). When creating your infrastructure, you’ll want to take note of the following requirements:

  • Information that is being transported must ALWAYS be encrypted.
  • PHI is backed up and is recoverable.
  • The information is only accessible by Authorized Personnel.
  • The information is not tampered with or altered.
  • Information can be permanently disposed of when no longer needed

To fulfill these requirements, you must be aware that all AWS services are at your disposal, but you can only process, store, and transmit PHI using the HIPAA-eligible services defined in the AWS BAA.

HIPAA eligible services in AWS

AWS follows a standards-based risk management program to ensure that the HIPAA-eligible services specifically support the security, control, and administrative processes required under HIPAA.

The HIPAA Security Rule includes addressable implementation specifications for the encryption of PHI in transmission (“in-transit”) and in storage (“at-rest”). Although this is an addressable implementation specification in HIPAA, AWS requires customers to encrypt PHI stored in or transmitted using HIPAA-eligible services in accordance with guidance from the Secretary of Health and Human Services (HHS).

The following AWS services are HIPAA-eligible:

  • Amazon DynamoDb
  • Amazon Elastic Block Store (Amazon EBS)
  • Amazon Elastic Compute Cloud (Amazon EC2)
  • Elastic Load Balancer
  • Amazon Elastic MapReduce (Amazon EMR)
  • Amazon Glacier
  • Amazon Redshift
  • Amazon Relational Database Service (Amazon RDS) for MySQL
  • Amazon RDS for Oracle
  • Amazon RDS for PostgreSQL
  • Amazon Aurora (MySQL-compatible version)
  • Amazon Simple Storage Service (Amazon S3)
  • AWS Import/Export Snowball

Also, keep in mind that the Amazon EC2 instances you use to process, store or transmit PHI are run on Dedicated Instances (dedicated hosts are also acceptable for BAA eligibility), which are instances that run in an Amazon VPC on hardware dedicated to a single customer. Dedicated Instances are physically isolated at the host hardware level from instances that are not Dedicated Instances and from instances that belong to other AWS accounts.

  • Set the tenancy attribute of an Amazon VPC to “dedicated” so that all instances launched into the Amazon VPC will run as Dedicated Instances
  • Set the placement tenancy attribute of an Auto-Scaling Launch Configuration for instances launched into an Amazon VPC
  • Set the tenancy attribute of an instance launched into an Amazon VPC

Amazon Virtual Private Cloud offers a set of network security features that are well-aligned for architecting HIPAA compliance. You do not have to use a dedicated Amazon VPC configuration to make your architecture HIPAA compliant.

The authentication and authorization mechanisms that you define for your HIPAA-eligible system must be documented as part of a System Security Plan (SSP). This documentation contains all of the roles and responsibilities in detail along with a configuration control process that specifies initiation, approval, change, and acceptance processes for all change requests.

However, AWS Identity and Access Management (AWS IAM) service offers the granular policies required to achieve the necessary controls under HIPAA. As you develop your authentication and authorization procedures, be sure to review and follow IAM Best Practices.

For encryption of PHI data, you can use AWS KMS. Master keys in AWS KMS can be used to encrypt/decrypt data encryption keys used to encrypt PHI in your applications or in AWS services that are integrated with AWS KMS.

AWS KMS can be used in conjunction with a HIPAA account, but PHI may only be processed, stored, or transmitted in HIPAA-eligible services.

KMS does not need to be a HIPAA-eligible service so long as it is used to generate and manage keys for applications running in other HIPAA-eligible services.

To meet audit controls required by HIPAA, you can use AWS Config. AWS Config is a fully managed service that provides you with AWS resource inventory, configuration history, and configuration change notifications to enable security and governance.
With AWS Config, you can discover existing and deleted AWS resources, determine your overall compliance against rules, and dive into configuration details of a resource at any point in time.

In order to have full control of data access, AWS Cloud Trail is a great solution. AWS Cloud Trail tracks all API calls from AWS services.

You will also need to monitor and maintain the logs of your AWS resources to keep a record of system access to PHI, and you will need to run analytics that could serve as part of your HIPAA Security Risk Assessment. You can use AWS CloudWatch for this. However, because CloudWatch isn’t a HIPAA-eligible service, your log files cannot contain PHI data.

Protection of patient data demands more careful data backup and restoring. Most AWS services have a built-in mechanism for backup and restoring to the last stable state. Options such as  EC2 AMI, creating snapshots for Amazon EBS, RDS, and Redshift should fulfill most of the backup requirements. It goes without saying that your backups must be encrypted.

As long as only HIPAA-eligible services are used to store, process, or transmit PHI, you may be able to use orchestration services such as AWS CloudFormation, AWS Elastic Beanstalk, Amazon EC2 Container Service (Amazon ECS), and AWS OpsWorks to assist with HIPAA compliance and security by automating activities that safeguard PHI.

If your healthcare application stores PHI data on S3 bucket, you can use S3 event notification with Lambda functions. Even though Lambda isn’t a HIPAA eligible service, you can use it as long as it isn’t storing, processing, or transmitting PHI.

HIPAA compliant applications: Wrap-up

Creating a HIPAA compliant AWS architecture is just the start of your journey. Maintaining HIPAA compliance is an ongoing process. You shouldn’t avoid using non-eligible services just because they are non-eligible. You can use them as long as they’re not used for storing, processing, and transmitting PHI. AWS will surely continue to add new HIPAA-eligible services, and it’s up to the user to keep up by continuously improving your own infrastructure.

Cloud Academy