What is HIPAA?
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 is legislation that is designed to make it easier for U.S. workers to retain health insurance coverage when they change or lose their jobs. The legislation also encourages electronic health records (EHR) be kept to improve the efficiency and quality of the U.S. healthcare system through better information sharing.
As software designers, there are certain engineering considerations we need to be aware of when designing for HIPAA. In this blog, I’ll take you through Apexon’s 10-step best practice guide for HIPAA design.
Along with increasing the use of EHR, HIPAA includes provisions to protect the security and privacy of protected health information (PHI). This information includes a very wide set of personally identifiable health and health-related data, including insurance and billing information, diagnosis data, clinical care data and lab work such as images and test results.
The HIPAA rules apply to covered entities, which include hospitals, medical services providers, employer sponsored health plans, research facilities and insurance companies – the latter deal directly with patients and patient data, and are a key part of the U.S. healthcare ecosystem.
The HIPAA requirement to protect PHI also extends to business associates. For a more in-depth overview of HIPAA compliance, there is additional information from AWS here.
What is BAA?
Under the HIPAA regulations, cloud service providers (CSPs) such as AWS are considered business associates.
The Business Associate Addendum (BAA) is an AWS contract that is required under HIPAA rules to ensure that AWS appropriately safeguards PHI. The BAA also serves to clarify and limit, as appropriate, the permissible uses and disclosures of PHI by AWS, based on not only the relationship between AWS and our customers but also the activities or services being performed by AWS.
BAA compliance is not simply a case of signing the agreement. Rather, it involves an active approach to adopting policies to ensure HIPAA compliance and any misconfigurations in the cloud could mean that a company is non-compliant.
AWS has published extensive FAQs on HIPAA and BAA, available here – Part 1 and Part 2.
HIPAA compliance: a step-by-step guide
As you might expect, there are defined steps that a company must go through to ensure HIPAA compliance.
These steps are set out below, but it is important to remember that HIPAA compliance is not Amazon’s responsibility. Rather, it operates on a shared responsibility model, which means that while AWS is responsible for some aspects of compliance and security, the end user takes responsibility for others.
(Typical Architecture for HIPAA)
Taking that into account, the 10-step process is as follows:
This applies across all examples.
This applies across all examples.
In the given solution, PHI resides on Amazon Elasticsearch, DynamoDB & S3. Services used for data storage are HIPAA eligible services.
All services which are used to store data and process data reside within the same private subnet of a single VPC. PHI stored in data storage is encrypted with native AWS encryption capabilities like server-side encryption and AWS Key Management Service.
When it comes to the source of the PHI and data storage, there should also be processes to assess configurations, review changes in configurations, assess inventory, etc. In the given example, this is achieved via the following services:
Personal Health Information needs to be secured both at rest and in transit. To secure data at rest, a native AWS encryption capability like server-side encryption and AWS Key Management Service are used. To secure data in transit, SSL is used.
PHI and business critical data should be protected by following security policies and best practices. In the example given, the following services are used to implement security policies and best practices:
Logging, auditing and monitoring make up the most important step on the road to HIPAA-compliant design.
A centralized logging solution is enabled in the given solution. A separate event and incident management process is in place to achieve operational excellence. Tools like AWS CloudWatch, AWS CloudTrail, AWS Config, AWS Config Rules, AWS S3 Access Logs, VPC Flow Logs are used to track, monitor, analyze and audit events.
If these tools identify an event which is analyzed and qualified as an incident, that “qualifying event” will raise an incident and trigger the incident management process. The incident management process should have a well-defined response for each and every type of incident with a specifically identified owner and resolution.
These incidents are communicated via email to the designated owner when an incident is generated and when it is closed. This ensures responses to high priority and business critical incidents are effective and prompt. Certain types of incident are defined with an automated mitigation response to reduce errors caused by manual processes, and to ensure prompt and consistent responses.
Each and every type of incident is defined with its own escalation path including what triggers escalation and the procedures for escalation.
For HIPAA design, only authenticated users should be granted any access to Personal Health Information.
Authentication should be done through proven authentication systems such as SAML or OAuth. In our given solution, it is achieved by Amazon Cognito. The authentication process can be further strengthened by using multi-factor authentication (MFA).
From an AWS cloud perspective, IAM is used for authentication.
The root user of the AWS account is used only to create the first administrator IAM user. All the different users of the AWS account are given their separate IAM credentials with MFA and the principle of least privilege enabled. None of the services in this solution uses static AWS access keys for programmatic access. These services are assigned roles to access other services.
Access control is also an important part of designing for HIPAA.
Any designated user should be given access to only required data/content. Different roles should be defined in the system and they should be given access with principle of least privilege.
Data back-up and recovery is an important topic in case of any disaster.
A data back-up and recovery strategy should be defined based on business needs. For example, the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) should be derived based on business need.
In our given solution, automated back-up is in place to periodically back up all business-critical data. The frequency of this periodic back-up is based on RPO and refers to amount of data at risk. In the event of disaster, automated monitoring systems identify disaster and start automated recovery or fallback.
To ensure the seamless operation of any system, performance monitoring is important. AWS CloudWatch provides many service-specific metrics to monitor performance.
The same approach has been taken in our example for performance monitoring. To select the right amount of compute power or storage, or the right database or network, the following five design principles should be followed:
Here is a list of eligible services from AWS.
Got a HIPAA compliance design challenge? We’d love to help you solve it. Let us know using the form below.