How to Build HIPAA-Compliant Applications on AWS

Unfortunately, solving risks of electronic patient data is not always a top priority and many organizations don’t pay enough attention in order to meet these standards. And this is happening even nowadays when healthcare data breaches are on the rise. In 2024, more than 134 million individuals were affected by healthcare data breaches. Most of these incidents resulted from hacking or IT events, including ransomware, phishing, and network intrusions. Others involved improper disposal, loss, theft, or unauthorized disclosure of patient records.

The compromised data often came from network servers, cloud storage, email systems, and portable devices. Each of these breaches must be reported under HIPAA requirements, and organizations that fail to comply may face hefty fines and potential lawsuits.

Today it’s more important than ever for healthcare organizations to be proactive and think about how to implement HIPAA.

What is HIPAA?

HIPAA stands for Health Insurance Portability and Accountability Act. It is the official compliance document that establishes the standards a healthcare organization has to meet in order to better protect patient privacy. Every health information system under HIPAA must be appropriately designed to follow these rules in order to ensure the proper level of data protection.

HIPAA requires four things of any organization that handles patient medical records in any way:

• You must have safeguards in place to protect patient health information.
• You must limit using and sharing of health information to the minimum that is required for your purpose.
• You must have agreements with any contracted service providers that handle your medical records – agreements that ensure they are in compliance with all HIPAA regulations.
• You must have policies and procedures that limit access and you must provide training to your staff regarding protection of both hard copy and electronic Protected Health Information (ePHI).

And those security measures must be paramount for the following entities:

• Any organization that is using digital storage and is transferring patient information.
• Any organization that is utilizing digital monitoring devices by which patient information is being transmitted.
• Any organization that receives patient information.

If you are considering any healthcare application development or modernization, you must ensure that the technology is in place that meets all HIPAA standards. The best way to accomplish this is to have a HIPAA compliance checklist that both you and a development team you select can use as your app is built.

Is AWS Cloud HIPAA Compliant?

Yes, AWS is HIPAA compliant and can be used to build cloud-based systems that process, store and transmit ePHI. But just using AWS services doesn’t make your solution HIPAA compliant directly. When your AWS-based system deals with ePHI, you must adhere to the AWS HIPAA security requirements and regulations.

The AWS HIPAA compliance is rather how well we know how to implement it in AWS than just use services offered by the platform. The AWS helps to build high-load systems that process vast amounts of ePHI in accordance with HIPAA. But first of all, you need to accept the AWS Business Associate Addendum (AWS BAA).

HIPAA Compliance Requirements Overview

We can say that HIPAA is an uncommon law: it makes a lot of recommendations “addressable” and only a few “required” items. What makes it more challenging is that in order to meet HIPAA compliance, EMR software development teams must take into account several aspects of the rules and evaluate if they can be within compliance, and, at the same time, empower the customers (hospitals, doctors, etc.) to meet their needs.

Basically to state that your healthcare solution is HIPAA compliant you need to follow HIPAA checklist including:

1. HIPAA Security Rules
2. HIPAA Privacy Rules
3. HIPAA Breach Notification Rules
4. HIPAA Enforcement Rules

If you are a technical guy who is developing an EMR/EHR system you will need to focus on the Physical and Technical Safeguards that are described in the HIPAA Security Rule Standards. These two safeguards contain the majority of your TODO list.

Effectively every safeguard of HIPAA is “required” unless there is a justifiable reason not to implement the safeguard or an appropriate alternative to the safeguard is implemented that achieves the same objective.

The HIPAA Security Rule outlines specific regulations that must be applied in order to prevent breaches in the process of the creation, sharing, storage, and disposal of ePHI. And what’s important this rule applies to any system that has access (create, read, write, or modify) to the confidential patient data.

How to Implement HIPAA-Compliant Architecture on AWS

There are a large number of steps that should be done in order to turn your healthtech solution into a HIPAA compliant one. The scope of your work will depend upon the features you are going to develop within your solution and the way private health information is transmitted and presented. At Romexsoft, we apply the following steps to ensure every solution we build meets HIPAA compliance requirements.

Sign a Business Partner Agreement with AWS

In accordance with HIPAA regulations, any company that wants to do business that falls under HIPAA compliance has to be prepared to sign a business associate contract with its customers.

For organizations who deal with ePHI, and as a result, must comply with HIPAA regulations, Amazon a AWS Business Associate Agreements for HIPAA-eligible Services to confirm that AWS properly protects ePHI. It includes the unique (“HIPAA-eligible”) AWS services and introduces the AWS Shared Responsibility Model where security and compliance are a shared responsibility of Amazon and customers. You can manage BAA directly in your account via the AWS Artifact in the AWS Management Console.

Identify Your HIPAA Responsibilities on AWS

In the AWS Cloud, security is shared between Amazon and customers. This means that Amazon is responsible for managing the infrastructure components and physical security of the AWS data centers and customers are responsible for other aspects (e.g. security and configuration of AWS services). With all this in mind, the only way to make sure that you are keeping up your end of the bargain is to understand which parts of the model you are responsible for. Many companies believe that if they host an application on AWS, it’s Amazon’s ultimately responsible for ensuring compliance. But it’s NOT quite true.

Amazon is responsible for “Security of the AWS Cloud”: maintaining and protecting its global infrastructure which is used by AWS service. It manages the physical security of the following areas:

• Computing
• Storage
• Databases
• Networking
• Region
• Availability Zone
• Edge location

Customer’s responsibility is “Security in the AWS Cloud”:for the security of their chosen AWS services. Customers manage security in the following areas:

• Platforms
• Applications
• Identity and access management tools and processes (IAM)
• Operating systems
• Networking traffic protection
• Firewall configurations
• Client and Server side encryption

As you can see from the above, AWS provides you with the infrastructure to build cloud-based healthtech solutions in accordance with HIPAA, but it’s completely your responsibility for choosing and properly configuring services that ensure the security and integrity of ePHI.

Implement “Access Control” Requirements

This goes without saying, but let’s just say that providing public, unauthorized access to ePHI (directly or indirectly) is a violation of HIPAA rules. HIPAA requires central identity management and necessitates the close control of access to data. To implement access control you need to focus on two fundamental HIPAA requirements:

• One is assigning a unique user identifier (can be name or number) for identifying and tracking user identity. This is a fundamental aspect of any login and authentication method.
• The other is establishing procedures for gaining access to electronic health information.

And these requirements can be performed using Role Based Access Control, User Based Access Control etc.

Use Role Based Access Control and User Based Access Control

Role Based Access Control (RBAC) can be implemented in cases when you can strictly divide users into groups with a certain role and give each group appropriate access rights. Additionally to RBAC, we can implement a more flexible access management mechanism – User Based Access Control (UBAC).

UBAC represents a list of privileges that can be assigned to a user and determines if the certain user has access to some piece of patient’s information, as well as what operations are allowed to do with that information. What’s more, your implementation can control access to the specific entity or specific URL in case of a web-based SaaS security solution .

In order to implement a simple UBAC, you need to have at least two tables (which could be named ‘privileges’ and ‘user_privileges’). These tables can be created in relation/non-relation databases or any other storage that is used.

Quick tip: The “privileges” – is a table where the specific privileges will be stored. The minimum of needed fields in ‘privileges’ table are:

• privilege_id – ID of privilege;
• privilege_access_to – contains the name of entity/method or URL that should be under privileged access.

Another table is “user_privileges”. In this table, the privileges given to an appropriate user will be stored. This table can have the following fields:

• user_id;
• privilege_id.

Here is an example of the possible implementation:

“Privileges” table

“User_privileges” table

The mentioned above example describes the case when the user #1 is granted the privilege to create, edit and delete appointments and user #2 can only view it. And the scheme described is the simplest way to ensure a User Based Access Control feature in your software.

Create and use IAM roles instead of the root account

When a new AWS account is being set-up, it’s important to enable MFA for your root account, create an Admin role, and lock away the root account token in a high secure box (or better yet don’t create a token for your root account at all). The decision not to use the root account improves overall security because every user is restricted by IAM policies. So, if the account keys are inadvertently shared or stolen, the damage is limited to some degree and can be quickly disabled.

Grant least privileges

More privileges than necessary opens the door for human errors and introduces the need for more complex audits. In healthcare organizations IAM users often need access to only a small portion of the AWS environment. IAM policies greatly simplify an investigation of who has access to what resources.
Best practice is to grant least privilege – and then grant more privileges in each specific case, if necessary.

Rotate credentials regularly

Any credentials that remain active for too long increases the risk of being compromised. AWS recommends that it’s best practice to regularly rotate all credentials, API access keys, and passwords. AWS outlines a manual process using the AWS CLI to create a second set of credentials, programmatically create and distribute the access keys.

Implement “Person or Entity Authentication” Requirements

The authentication and authorization component is critical for every healthcare system that aims to meet HIPAA requirements in AWS. Such systems should have bulletproof rules that will identify the application’s persons or entities and determine what they can do in it.

When developing person and entity authentication procedures for AWS-based systems, it’s important to remember that IAM is mainly focused on managing access to your AWS services and resources. In most cases, in addition to IAM, you will most likely need to set up an additional level of authentication and authorization control in your healthcare application.

To achieve this, you can use existing and proven authentication protocols, such as SAML 2.0 or OAuth. You can also add a simple way to sign-up, sign-in, and access control to your web or mobile application by using Amazon Cognito service.

It’s under discussion whether the system must provide the strongest person or entity verification. The objective of the Person or Entity Authentication specification is to implement procedures to verify that a person is authorized to access the ePHI. These procedures can be implemented with the following four verification features proposed by HHS:

1. “biometric” identification system;
2. “password” system;
3. “personal identification number” (PIN);
4. “telephone callback” or a “token” system that uses a physical device for user authentication.

While HHS does not prescribe exact methods, this flexibility allows covered entities and business associates to choose what fits their systems best, though that freedom comes with responsibility. The selected method must still minimize risks and meet compliance standards.

Password System

To implement password authentication you should ensure that the password entered by user meets the following guidelines:

• The password should be complex utilizing a combination of letters, numbers, and special characters and be between six and 10 characters or more so that it couldn’t be easily guessed.
• The password should never be based on the login name, actual name or any dictionary name.
• The password should be changed at least every six months or whenever the password becomes known to the other person. And current or previous passwords could not be reused.

The above guidelines can be implemented on different levels of your system. For example, the validation process of whether the password meets the requirements can be implemented on the register screen. The logic will validate the entered password and won’t pass users with unsecured passwords.

In addition, you can implement functionality that will control the password expiration. This logic will prevent users from logging in with an expired password and force them to change it. For example, user’s record in DB will have “password_expired_on” field. And when the date in password_expired_on will be greater or equal than the current date user will be prompted to change the current password.

Multi-Factor Authentication

In fact, when considering authentication solutions it is important to weigh the criticality and sensitivity of the protected information. Using a simultaneous combination of authentication mechanisms (called multifactor authentication) can help you mitigate the risks of bypassing authentication controls.

An example of this approach can be the request of a fingerprint scan (biometric) with the further entering of a password. With this approach, a compromised password would be rendered useless since a fingerprint is required and a forged fingerprint alone would not achieve an attacker’s goals in case the password wasn’t right. Although this approach provides a high authentication level, at the same time you should care about the compliance of the level of assurance with the associated financial and performance costs.

Adopt Data Backup and Disaster Recovery

Every entity that falls under HIPAA regulations must have developed an emergency plan on how to protect ePHI data in case of a disaster. To avoid losing private and critical patients’ information you have to ensure that the ePHIs which are collected, stored, and used within your system are backuped and the backup and recovery processes are configured properly. Most AWS services allow you to configure backup and recovery processes, so you can restore the last stable state of ePHI if some information is lost. By using features such as EC2 AMI snapshots (in the Amazon EBS, Amazon RDS, and Amazon Redshift services) you will be able to meet most of the data backup requirements.

Amazon S3 is HIPAA compliant and is the most popular option for securely managing scalable and durable backups of your data. With Amazon S3 you have several options on how to ensure the privacy and security of ePHI records. Amazon S3 provides client-side encryption to protect data in transit and additional server-side encryption to protect your data at rest.
Disaster recovery is a set of tools and procedures that aim to protect an organization’s data and critical IT infrastructure in times of disaster. This is usually one of the most expensive HIPAA requirements to comply with. In AWS you can use global infrastructures (regions and multiple Availability Zones) to build fault-tolerant solutions that are highly resilient in case of network failures, system downtime and natural or human-induced disaster.

Encryption and Decryption of PHI in AWS

In accordance with the HIPAA compliance guidelines, ePHI must be encrypted both in transmission (“in transit”) and in storage (“at rest”). While HIPAA addresses the security and privacy of ePHI as a policy and procedural approach with no strict parameters, AWS requires customers to encrypt transmitted and stored ePHI records using HIPAA-eligible services
AWS offers a wide range of features and services to make key management and encryption of ePHI easy to manage including the AWS Key Management Service.

Here are few recommendations that will help you implement encryption:

• In order to protect ePHI and prevent a data breach, it’s a good practice to store the confidential data in a secure environment with the proper physical and network security.
• If a mobile device needs to store confidential information, file/folder level encryption and full disk encryption are acceptable to keep data safe.
• Don’t store the password to the PGP or S/MIME key in your system.
• Recommend your system visitors to enter the password and use cookies to keep the password from page to page.
• If you store ePHI in a MySQL database you should ensure that the password to that database isn’t stored in your system.
• If you need to implement even more security stages you can encrypt the data before saving it in the database.

Data can be encrypted with a single security key access or with separate keys for encryption and decryption (symmetric and asymmetric data encryption) and the level of security can be adjusted as appropriate based on the sensitivity of the data.

Disposal as a Requirement

“Disposal” means that the data can be permanently disposed of when needed. Yet, you will have to consider all the places where data can be backuped and archived, and you will need to ensure that all of those backups will expire and disappear.

Every place where the information is stored should be backuped and the copy of your data should be saved.

Of course, it helps if the data is encrypted in the backup. But if the backup is there and the keys to open the data exist, then it is not really “disposed of”. It is up to you to ensure that the hard drives containing ePHI are properly disposed of when you are no longer using them and determine how far you need to go to ensure data disposal in order to be HIPAA compliant.

Implement the “Transmission Security” Requirements

As detailed in the AWS BAA, you must encrypt all ePHI in transit. To secure data during transit, you should always use Secure Socket Layer (SSL) endpoints for all services.
Using SSL certificates with very strong SSL termination policies can help you protect your stored ePHI. You need to have an SSL certificate installed to encrypt the traffic between the client and the server. You can use AWS Certificate Manager (ACM) to create an SSL certificate.

What’s more, use of SSL can meet HIPAA’s data transmission security requirements in terms of communication between the end user and your web solution. However, your SSL configuration must be strong enough to prevent encryption methods that are “too weak”.

Quick note: If you need to transfer patient data to and from payers or other medical organizations don’t use public FTP (File Transfer Protocol). For this purpose, the SFTP protocol can be used.

And don’t forget that with expected increase in the use of electronic transactions in healthcare, such as e-prescribing, and electronic communications via email, messaging between a physician and a patient, most covered entities will have a need in encryption implementation.

Implement Audit Logging & Monitoring Controls

Auditing and monitoring controls are a Technical Safeguard that must be addressed when architecting for HIPAA compliance on AWS using technical controls by anyone who wishes to store, process, or transmit electronic patient data.

To meet these requirements in AWS, you need to launch AWS CloudTrail that allows you immediately begin recording all AWS API calls. You can also enable CloudTrail log file validation. If log file scanning is enabled, any changes made to the log file itself after its delivery to the S3 bucket will be identifiable. It’s important to launch the AWS Config service that gives you the tool to audit and inventory the AWS resources, evaluate the configurations of history and change notifications.

Organizations covered by HIPAA are required to track, log and store (over a period of time) all operations with ePHI records and establish clear policies and processes for regularly reviewing and analyzing those logs. Monitoring and reviewing audit trails should occur as close to real time as possible.

Also, what you need to remember is that outcomes of the covered entity’s risk analysis will be based on how the covered entity sets its policies and procedures. If a security incident occurs, failure to exercise this audit control standard may be the proof of an inquiry that a covered entity had the capability to know what was occurring but failed to exercise corrective action timely.

To implement even the minimum “Audit Controls,” you can maintain a dedicated log file or create a database table to record all actions (create, edit, delete, view) involving ePHI. For example, an actions_log table may include:

• user_id – ID of the user who performed the action;
• entity_name – name of the entity (table in case of DB) on which the action is performed;
• record_id – identifier of the modified record;
• action_type – type of an action (create, edit, delete or view);
• action_time – the timestamp when action has been performed.

In AWS, you can extend this functionality using AWS CloudWatch service that allows you to collect and monitor the activities on your AWS resources (e.g. Amazon EC2, Amazon RDS, Elastic Load Balancer (ELB) instances, and Amazon EBS volumes). Also you can use CloudWatch agent that enables you to develop and publish your own metrics to get specific information from your resources.

When using these logging and monitoring tools you should definitely be sure that logs do not actually store any ePHI. You should carefully check everything that is logged. For example, in most situations if a username and/or IP address is coming in the logs, would be considered as a violation of HIPAA rules. Therefore, you will need to catch such specific cases to make sure that private information is not mentioned in the logs. If in some cases you still need to have private information in logs, you will need to encrypt it before sending it to AWS CloudTrail.

Implement Automatic Logoff

As you might know, automatic logoff implementation will require the authorized user to re-enter a password to gain access to electronic protected health information. This feature will terminate a login session after a predetermined period of inactivity which should ensure that access is still secured in cases when someone walks away from a computer or system.

As it is an addressable specification, timeout and logoff features will depend on the size of a covered entity and the degree of access to electronic information system devices. As a benchmark, you may establish a 10-minute timeout period before the logoff capability locks the device and makes information inaccessible. In case your device is in the high-traffic area, you might need to set a timeout of 2 to 3 minutes. And devices in protected areas with controlled, limited access, such as a lab or an isolated office, could have longer timeout periods.

How to implement automatic logoff? Well, each platform has a specific way to implement this feature. For example, if you build a Java based application that will run inside the Tomcat container you can just add few lines of code in your web.xml configuration:

<session-config>
<session-timeout>30</session-timeout>
</session-config>

Note: Timeout settings will be suggested by the risk analysis based on the size of facility, location, and accessibility of EMR system devices. The covered entity should pay particular attention to the growing use of handheld devices that can be moved from one part of a covered entity to another as it affects its timeout strategy.

AWS HIPAA Compliance Checklist

We covered the detailed plan on how to adopt HIPAA with AWS. And the best way to accomplish this smoothly is to have a HIPAA compliance checklist that both you and a development team you select can use as your software is built.

Technical Security

• Control access through usernames and PIN codes.
• Establish e-controls such as two-factor authentication to decide how access is granted.
• Use predictive risk analysis mechanisms to assign various risk levels and permission rights based on past usage history.
• Encrypt all data according to National Institute of Standards and Technology (NIST) standards.
• Implement methods to encrypt and decrypt data as it is transmitted.
• Install SSL certificate and dedicated IP address to encrypt traffic in transit.
• Ensure the IT solution cannot be accessed without SSL.
• Ensure ePHI is never publicly available; users must log in to access content.
• Incorporate audit controls to record who accessed data, when, and for what purpose.
• Enable automatic logout for unattended devices.
• Implement workstation security to prevent unauthorized access to computers that handle ePHI.
• Ensure good backups of the application and its content.
• Encrypt patient information using a key available only to authorized individuals.
• Integrate audit trails that record data access and modifications.

Physical Security

• Monitor individuals who have physical access to data storage areas and require authentication and authorization.
• Control access to workstations that handle ePHI.
• Remove ePHI from mobile devices when they will no longer be used.
• Maintain an inventory of all hardware containing ePHI and document secure removal procedures when discarded.
• Adopt mobile device policies regulating the storage and removal of protected health information.
• Ensure access to environments storing ePHI is restricted and secure.

Administrative Security

• Conduct an annual HIPAA security risk analysis.
• Perform regular risk assessments to identify and remediate vulnerabilities.
• Develop, adopt, and implement privacy and security policies and procedures.
• Clearly define roles and responsibilities for HIPAA compliance.
• Ensure users with access to ePHI are properly granted or revoked access by HIPAA administrators.
• Provide users access only to ePHI necessary for their job role.
• Require user authentication such as passwords or PIN numbers.
• Develop emergency plans to protect data and ensure backup restoration capability.
• Train employees to identify potential cyber-attacks and maintain training records.
• Prevent unauthorized access both physically and digitally.
• Engage a trusted provider to remotely monitor and maintain network and device security.

Data Encryption and Privacy

• Govern the use and disclosure of electronic patient health information.
• Ensure patients can access or obtain copies of their health records.
• Protect individual patient identifiers.
• Keep development teams current with all HIPAA privacy rule updates.
• Ensure policies and procedures comply with HIPAA requirements.
• Convert all data to ciphertext unreadable without a security key.
• Encrypt data in storage and transmission.
• Apply encryption to networks to prevent unauthorized access.
• Maintain encryption so data remains unreadable if a device is lost or stolen.

HIPAA Breach Notification and Enforcement

• Report small security breaches to the Health and Human Services Office of Civil Rights.
• Report larger breaches (impacting more than 500 patients) to the media.
• Notify affected patients and outline mitigation steps.
• Include breach details, current damage level, and measures taken to prevent further impact.
• If breaches occur due to software vulnerabilities, developers share accountability, though the entity remains responsible.
• Define procedures for investigations and penalties following ePHI breaches.
• Evaluate breaches for avoidability.
• Treat ignorance of HIPAA and software bugs as avoidable, carrying higher penalties and fines.

Secure Messaging

• Use secure messaging systems with encryption keys for authorized communication.
• Encrypt patient-related emails and store them in encrypted form for six years.
• Establish email policies governing mobile devices and communication security.
• Implement web content filters to prevent phishing and malicious access attempts.
• Use anti-malware, intrusion prevention, and file integrity monitoring tools.

Governance, Policy, and Business Continuity

• Develop and document privacy and security policies.
• Outline procedures to follow when a breach occurs.
• Adopt mobile device policies for handling protected health information.
• Establish and maintain risk management policies and procedures.
• Maintain regular backups of applications and content.
• Include a disaster recovery plan in HIPAA risk mitigation.

Summarizing all of the above, we can say that the number of healthcare organizations that use AWS to ensure a high level of delivered healthcare services are growing every day. AWS has made significant efforts to align itself with the HIPAA to promise its customers that storing, maintenance and processing ePHI can be performed without errors or possibilities of vulnerabilities. This way you can be sure of HIPAA compliance while using AWS.

Romexsoft’s team has extensive experience in implementing HIPAA for healthcare software. We are ready to guide you through the design and development of HIPAA-compliant healthcare software and get the most out of the elasticity, efficiency, and resilience of the AWS cloud.