Today, we will try to understand in general what HIPAA is and how we can comply with this standard in the software and infrastructure scope. Even though this is a standard, its technical requirements could be clearer in places, and implementation may vary from project to project so we won't go into the details here.
Backstory
I had extensive experience with planning infrastructure to comply with standards and legal regulations. One of my projects fell under HIPAA-regulated entities but closed before taking off. In another project, I developed infrastructure from scratch to comply with Payment Card Industry Data Security Standard (PCI DSS), and it got certified. We won't delve into this intricate, extensive story right now. However, similarities in both cases significantly hindered productivity and quality during audit preparations.
General points
So, before we discuss HIPAA, let's briefly analyze these points:
- The absence of a lawyer in the initial team formation is a common thing. Often, their involvement is delayed until the final stages, and their attention is primarily focused on administrative and procedural aspects, leaving the technical aspects solely in the hands of the engineers. While this approach may initially satisfy the stakeholders, having a lawyer with a technical background in the team from the beginning will significantly enhance the level of preparation and boost the auditing outcomes.
- Deferred security is often an issue in many projects, not just those that need to comply with specific standards. Implementing certain security measures may require a complete rewrite of the application, service, product, or infrastructure. This, in its turn, can cause significant delays in preparing for and completing an audit.
Although these things may seem obvious, they often only become a priority right before an audit. It is advisable to incorporate compliance measures into the architecture from the design stage onwards and consider hiring a consultant who can explain the requirements and implement them technically. This approach can save significant time and money.
HIPAA
First, let’s understand what HIPAA is. The Health Insurance Portability and Accountability Act is a federal law passed in the United States in 1996. It was created to establish guidelines for safeguarding personal health information, also known as Protected Health Information (PHI). With the proliferation of health apps and the emergence of machine learning, there is a constant influx of new online doctors and therapists offering their services for various health concerns. Thanks to HIPAA, our health information is protected from any leaks and unethical individuals. In such a scenario, patients have control over their information.
HIPAA contains regulations that oversee the utilization, transmission, and disclosure of PHI by healthcare providers, insurance companies, and other entities involved in managing this data. The statute mandates that organizations implement measures to safeguard the privacy, accuracy, and accessibility of PHI, including electronic PHI (ePHI).
HIPAA provides individuals with specific rights regarding their data, such as the ability to access their medical records, request corrections to those records, and receive a record of the disclosure of their PHI.
In brief, HIPAA has significantly streamlined the exchange of medical information among specialized entities while bolstering the safeguarding of privacy.
ePHI
It's evident that the focus is on safeguarding personal medical data. ePHI is simply PHI that is in electronic form. There are 18 types of information protected under HIPAA, including:
- Full name.
- Addresses.
- Dates.
- License plate.
- Phone numbers.
- Social security numbers and other tax identifiers.
- Any account number.
- Biometric data, for example, fingerprints, voiceprints, eye retinas, irises, or facial images.
- Email addresses, IP addresses, or URLs associated with the patient.
An example of protected health information (PHI) would include the following details:
- Patient medical records. Any electronic records that contain patient identification information, medical history, results of diagnostic tests, and treatment plans.
- Covered incidents. Digital records that include names, diagnoses, and treatment procedures.
- Prescriptions. Electronic records that include the names of patients, the names and doses of medications, and schedules for refilling them.
- Billing and payment information. Digital records of bills, invoices, and payment information containing names, insurance information, and payment history.
- Digital copies of laboratory reports and images that may include diagnostic tests, reports, and images containing identifiable patient information, as well as results and diagnostic information.
- Study data records. Contain patient identification information, study findings, and a history of studies.
- Records of physician appointments and scheduling. Records that include information that can identify a patient, such as their name, the time of their visit, and a doctor or provider's name.
- History of emails and other correspondence. Copies of emails or messages from other platforms that contain medical information.
The list is generally accurate but may not be comprehensive or detailed enough for a specific service or application. Additionally, certain data may become classified as PHI or no longer be considered PHI during the course of the service, depending on the presence of identifiers and the ability to track individuals. In these cases, seeking legal counsel could be helpful.
We talked about HIPAA and the information it aims to protect. Moving forward, we are approaching the topic of Cloud Service Providers, abbreviated as CSP. Every major CSP operates on a relationship model that divides security responsibilities between providers and clients. This model, referred to as shared responsibility, outlines which security measures are the responsibility of CSP and which fall under the client's responsibility.
The exact distribution of responsibility may differ between services. In particular, we discuss service delivery models such as SaaS, PaaS, IaaS, and CSP. Typically, shared responsibility follows this general framework:
- CSP duties involve securing the basic cloud infrastructure, which includes physical elements in the data center, network tools, and the hypervisor that administers the virtual machines. Additionally, the CSP must ensure its cloud services are available, dependable, and capable of scaling.
- As a cloud service customer, you are responsible for ensuring the security of the applications, data, and user access to your cloud services. This entails a range of tasks, including but not limited to establishing firewalls, encrypting sensitive data, managing user access, and configuring intrusion detection and prevention systems.
To put it simply, the CSP is responsible for securing the cloud infrastructure, while the client is responsible for safeguarding its applications and data.
Familiarizing with this concept is vital to utilize cloud services correctly and to avoid misleading assumptions that the cloud is inherently secure regardless of the actions taken.
In the context of HIPAA, shared responsibility is crucial because the regulations enforce restrictions on using services to process and store ePHI. Such services must be HIPAA-compliant or HIPAA-eligible, but using them alone doesn’t ensure your product is also HIPAA-сompliant.
HIPAA-eligible Services
Each CSP has an extensive list of services that comply with HIPAA regulations. These HIPAA-eligible services adhere to various HIPAA security requirements and standards that dictate the handling of ePHI.
It is essential to recognize that not all CSPs or cloud-based services adhere to HIPAA regulations. For instance, if you are a healthcare provider using a cloud service that does not comply with HIPAA regarding ePHI storage and processing, you risk violating HIPAA regulations and may face penalties for non-compliance. Thus, it is vital to scrutinize any CSP or cloud-based service before using it for handling or storing ePHI.
As we previously stated, being HIPAA-eligible does not necessarily mean that your system or product is fully HIPAA-compliant. Utilizing these services on their own will not automatically ensure HIPAA compliance. It involves shared responsibility, meaning that you must properly set up and operate the service yourself.
BAA
We are nearing the end and still haven't gotten to the technical aspects. Another essential legal component needed for HIPAA is a concept called BAA, which stands for business associate agreement. As previously noted, this agreement is signed between us and CSP, ensuring that CSP properly safeguards and stores ePHI while ensuring this data's availability and integrity. This guarantee is provided in the form of a written contract.
BAA also details circumstances in which CSP can access, use, or disclose PHI when it’s necessary. Additionally, the BAA outlines the conditions under which the agreement can be terminated.
To put it briefly, the BAA is a legal contract that outlines the obligations and standards for how CSP handles ePHI on your behalf. Ultimately, this information will be stored on their physical infrastructure and is necessary to ensure HIPAA compliance.
Technical implementation
Now we are approaching the technical implementation stage. The HIPAA Security Rule includes guidelines for safeguarding the confidentiality, integrity, and availability of ePHI. Both healthcare organizations and their business partners, including CSPs, must adhere to these standards and implement administrative, physical, and technical security measures to secure ePHI.
As it has become evident, we are primarily concerned with the Security Rule as the implementation of the corresponding HIPAA infrastructure and product relies on the security measures outlined therein. Those familiar with HIPAA, know that the Security Rule lacks explicit directives, checklists, and specific criteria, with many security measures described as appropriate or reasonable.
Certainly, such an approach is justified. It is impractical to account for every possible scenario, while it is more visionary to establish a general direction to aim for. You must determine the best-suited methods and strategies for each situation and period, as technological advancements constantly introduce new security standards and encryption protocols. Furthermore, this standard prioritizes risk management. Risk registers, assessments, responses, and contingency plans may influence a technical implementation.
There are several measures necessary in any case:
- Encryption in-transit (and at-rest)
- Access and authentication control
- Data integrity
- Audit control
- Infrastructure as code or IaC (optional).
Encryption in-transit & at-rest
Ensuring the protection of ePHI during transmission is essential to comply with HIPAA regulations. Despite having a private network (VPC) in the cloud, it is still imperative to implement encryption measures. Therefore, employing TLS on all endpoints of every service involved in ePHI transfer is necessary. In our view, relying on non-encrypted connections is inefficient, and it is simpler to make encryption the default in all cases. This means that for HTTP endpoints and balancers, you should either disable non-SSL connections or redirect them to HTTPS. Encryption must also be used for object stores, databases, queuing services, and other additional services and integrations. If you use Kubernetes to deploy, scale, and manage containerized applications, you can implement a service mesh to encrypt communication between applications within a cluster.
Kubernetes, an open-source container orchestration system, has become a go-to solution for managing and scaling containerized applications. However, setting up and configuring Kubernetes on AWS can be a daunting and time-consuming task. Learn more about it in our article.
It is advisable to utilize encrypted tunnels, such as VPN and IPSec, to guarantee data safeguarding. This is especially important when providing employees access to internal services that deal with ePHI or BAs that need integration.
Data-at-rest encryption is not currently required under HIPAA regulations, but it is suggested as an added security measure based on potential risks. Sensitive information could potentially be saved on network drives, object storage (also spread out across the network), and other types of storage that we lack physical control over, posing a risk. In our opinion, enabling encryption-at-rest should also be a default setting, regardless of HIPAA or other security standards. AES256 is the preferred protocol here.
Thus, at a minimum, to protect data during transmission and storage, we need the following:
- All external endpoints must have SSL security, and plain HTTP cannot be used.
- Internal communication between applications and services must also be encrypted.
- The same applies to email communication containing ePHI.
- Connections to databases, object stores, queuing services, and similar systems must be encrypted, and insecure connections should be disabled.
- Use secure tunnels if needed to link up external integrations or grant staff access to internal services.
- All block storage devices in your cloud, object stores, and other storage systems should be encrypted by default using appropriate settings and policies.
Access сontrol
One of the vital elements of the ePHI Security Rule is controlling ePHI access, which is instrumental in ensuring that protected information can only be accessed, read, or altered by authorized individuals. Access to system components, resources, and information is regulated through authentication and authorization.
With authentication, we verify the identity of an individual, device, or application via a login and password, as well as additional measures such as multi-factor authentication, biometric data, certificates, and other methods. When it comes to authorization, we utilize approaches such as RBAC, ACLs, and IAM to determine the authorized level of access for the authenticated user.
By implementing appropriate access controls, teams and organizations can effectively enforce the principle of least privilege. This principle ensures that individuals are granted only the minimum set of permissions necessary to complete their required tasks, thereby minimizing the risk of unauthorized access or data leakage.
At the network level, it is also essential to adhere to the principle of least privileges. This means that all services and infrastructure resources should run on private subnets, except for public load balancers. Access between services and applications within the private network should be restricted using security groups, NACLs, firewalls, and network policies.
Data integrity
As ePHI is the most important aspect of HIPAA, it must make every effort to guarantee the accuracy and correctness of this data. While strong access control, event auditing, and encryption can help with this issue, several additional steps must be taken.
- Creating a data backup and recovery plan is extremely important as it ensures that if data becomes corrupted, the information can be returned to its prior state, and any unauthorized changes or deletions can be restored. Automation of this process is recommended and must be coupled with strict access control and encryption. In addition, regular training sessions must be conducted to ensure competent data recovery. Subsequently, the effectiveness of the backup system can be affirmed after a successful restore.
- Along with encryption, checksums, and digital signatures can provide validation and ensure the integrity of data. This allows for tracing the authenticity of the data or any modifications made to it. Blockchain technologies can also be utilized for this purpose.
- Another approach that can enhance data integrity is versioning. It aids in maintaining a record of modifications and facilitates the capability to revert data to previous versions in the event of unauthorized alterations or data corruption.
Audit control
This component of the Security Rule is equally essential. It serves as a procedural and software mechanism for recording and verifying actions in information systems containing or using ePHI. It aids organizations in tracking ePHI usage, detecting potential security incidents, and providing valuable insight for investigations or audits.
Auditing is a crucial component not only in HIPAA but also in most security standards. Without it, a certificate of compliance cannot be obtained. Its absence indicates an uncontrolled and reckless operation, which is unacceptable. Auditing also requires access control, data integrity, retention, and monitoring. Therefore, in large infrastructures, this component is separated and developed independently.
The audit involves collecting logs, activities, and events related to actions on ePHI, such as user access, data modification or deletion, and various system and service events. Network activity and activity within infrastructure accounts are also logged, as data may be accessed through means other than user applications.
Now CSPs offer a large set of tools for monitoring all events and access to resources and data, as well as service logs and VPC flow logs.
Moreover, IDS systems may need to monitor hosts or nodes for unauthorized alterations to configuration files, libraries, or program code, which can also potentially compromise ePHI security.
After collecting and providing all necessary information, the next step is establishing an event analysis, reporting, modeling, and monitoring system. Depending on the number of sources, architecture, and size, you can either utilize the services provided by a CSP or set up your own SEIM to collect all events from all sources for further management.
Our task will also include ensuring the integrity of this data throughout its entire storage period through methods such as versioning, access control, encryption, and backup.
Infrastructure as code
Although the HIPAA Security Rule does not explicitly require IaC, its implementation can enhance control over changes and significantly decrease the likelihood of configuration errors. Additionally, utilizing IaC tools and templates can aid in implementing necessary rules and policies, ensuring that all infrastructure resources are provisioned and configured consistently that adheres to established security standards. Ultimately, these measures decrease the likelihood of errors or discrepancies in settings that could create security vulnerabilities.
IaC enables IT teams to manage infrastructure resources as code. This provides version control and auditing capabilities for all changes made to the environment. Such tracking, validation, and management of infrastructure configurations are crucial requirements of the Security Rule.
Also, IaC allows for testing changes in the infrastructure configuration before deployment to the production environment. This enables identifying and resolving potential security issues before their actual occurrence. And as this is as code, it can be integrated into CI/CD for automated testing and code integration, minimizing the impact of human error.
Final words
Although HIPAA compliance is straightforward, implementing it can be a highly technical and monotonous task. It is wise to seek the assistance of knowledgeable individuals, as the consequences of non-compliance can result in significant penalties.
If you have any further questions regarding HIPAA compliance, please contact Mad Devs. We have the expertise to assist you in adhering to HIPAA/HITECH security standards for the storage of PHI, whether your workloads are in one of our private clouds or a public cloud like AWS. Our services include managing audit trails and reporting, allowing your in-house IT team to focus more on strategic aspects of your business.
