HIPAA, HITECH, and HITRUST - It’s HI Time to Make Sense of it All

Organizations in the health care sector and those that work with it often hear about HIPAA, HITECH, and HITRUST compliance but may not understand what they all are and what they have to do with each other. This post will help clear this up by explaining the similarities and differences between each of these frameworks.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a law originally passed in 1996 with five titles, each covering a different topic:

When most organizations ask about HIPAA compliance (especially organizations reaching out to security consulting firms like TrustedSec), they are specifically concerned with HIPAA Title II. While the main purpose of Title II is to define the standards for electronic transactions, it also mandates security and privacy requirements for those electronic transactions.

The law resulting from HIPAA only provides vague outlines of its requirements and instructs the Department of Health and Human Services (HHS) to create detailed regulations to better define the requirements. To support Title II, HHS has produced regulations including:

• The Administrative Rule at 45 Code of Federal Regulations (CFR) Part 162 that documents the standard transaction formats and when they are required
• The Security Rule at 45 CFR Part 164 Subpart C that defines how the electronic transactions covered by the Administrative Rule must be protected
• The Privacy Rule at 45 CFR Part 164 Subpart E that defines what organizations can do with the information contained in the transactions covered by the Administrative Rule

HITECH

HIPAA was amended by another law, the Health Information Technology for Economic and Clinical Health (HITECH) Act, which is contained in Title XIII of the American Recovery and Reinvestment Act of 2009. The main purpose of HITECH was to establish financial incentives for the use of electronic health records (EHRs), but HITECH also expanded the HIPAA security and privacy requirements and added breach notification requirements.

The original regulations HHS created to support HIPAA were adjusted by the Omnibus Rule in 2013 to align with the new requirements of HITECH. This included changes to the Security Rule and Privacy Rule, and also the introduction of the Breach Notification Rule at 45 CFR Part 164 Subpart D.

Various other smaller regulation changes have occurred since. Major changes to the HIPAA Security Rule regulations were proposed in December 2024 and are working their way through the regulatory process at the time of this blog publication, along with a variety of other changes.

HITECH should not be thought of as a separate compliance obligation since it amended the existing laws that resulted from HIPAA, and the regulations created to support HIPAA have been amended to align with HITECH. Effectively all HIPAA compliance is now HIPAA/HITECH compliance, but most organizations will just call this “HIPAA compliance”.

HITRUST

HITRUST refers to the HITRUST Common Security Framework (CSF). Unlike HIPAA and HITECH, HITRUST is not a law or regulation. The HITRUST CSF was created by a private for-profit company, also called HITRUST, that publishes and certifies consulting firms to help clients align and certify compliance with the HITRUST CSF. Its association with HIPAA and HITECH is due to heavy marketing targeting the health care sector and may also be partially due to the similar (some might say confusingly similar) naming.

It is somewhat common for health care organizations to ask their Business Associates to maintain HITRUST certification. However, HIPAA, HITECH, and their supporting regulations do not require HITRUST or any other certification. Like most laws and regulations, HIPAA, HITECH, and the supporting regulations are expected to be followed as written under the threat of government penalties as defined in the regulations themselves. A HITRUST requirement is a negotiable private contractual issue between an organization and its partners that is in addition to—and unrelated to—compliance obligations imposed by HIPAA, HITECH, and their supporting regulations.

Some health care organizations may be asking their Business Associates for HITRUST certification as a proxy indicator of HIPAA Security Rule compliance. While the HITRUST CSF is a perfectly reasonable security framework that can be useful both within and outside of the health care sector, HITRUST certification is not an automatic indicator that an organization is HIPAA compliant, as explained below. Organizations must ensure their understanding of the scope and applicability of their partners’ HITRUST certifications before relying on certification as an indicator of HIPAA compliance.

HITRUST as a HIPAA Compliance Proxy

The HITRUST CSF establishes various Control Specifications, each of which broadly describes a security best practice that often overlaps with, but is not specific to, any particular requirements in HIPAA or other compliance frameworks. Most of the Control Specifications are too vague to be used to meet the detailed requirements of HIPAA or any other regulatory framework. Using a single Control Specification as an example, Control Reference 03.b Performing Risk Assessments states:

“Risk Assessments shall be performed to identify and quantify risks.”

While this Control Specification overlaps with the HIPAA Security Rule Risk Assessment requirement at 45 CFR 164.308(a)(1)(ii)(A), it lacks much of the detail contained within the HIPAA version of the requirement. For example, under the HIPAA Security Rule, the Risk Assessment must specifically cover risks to Electronic Protected Health Information (ePHI), and certain aspects that the Risk Assessment must cover are defined as follows:

“Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.”

In an attempt to address this issue, the HITRUST Control Specifications are mapped to various compliance frameworks, including the HIPAA Security, Breach Notification, and Privacy Rules. Where applicable, the Control Specifications contain more detailed Implementation Requirements that should align with each of the mapped frameworks. For example, the HIPAA Implementation Requirement for Control Specification 03.b used as an example above states:

“Risk assessments (analysis) used to determine whether a breach of unsecured Protected Health Information (PHI) as these terms are defined by the Secretary of Health and Human Services is reportable to the Secretary must demonstrate there is a low probability of compromise (LoProCo) rather than a significant risk of harm. The methodology, at a minimum, address the following factors: the nature of the PHI involved, including the types of identifiers involved and the likelihood of re-identification; the unauthorized person who used the PHI or to whom the disclosure was made; whether the PHI was actually acquired or viewed; the extent to which the risk to the PHI has been mitigated; and other factors/guidance promulgated by the Secretary.”

While this Implementation Requirement is much more descriptive than the Control Specification it accompanies, it is still very different from the HIPAA Security Rule requirement to perform a risk analysis. The Implementation Requirement seems more focused on breaches of unsecured PHI and does not address the HIPAA requirement to analyze the risks to the confidentiality, integrity, and availability of all ePHI, whether that ePHI has been involved in a breach. As a result, an organization could perform this HITRUST Implementation Requirement as written and still not meet the HIPAA Risk Analysis requirement that supports.

There is also a risk that organizations with HITRUST certification have not implemented the HIPAA Implementation Requirements at all. Organizations that implement HITRUST are free to define the scope of their program and choose which of the Implementation Requirements they want to implement within that scope. While it would make sense for an organization subject to HIPAA compliance to implement the HIPAA-related Implementation Requirements, it is not strictly required for certification. For this reason, an organization could hold a HITRUST certification without implementing any HIPAA-aligned controls. This presents obvious problems for organizations that uncritically rely on HITRUST certification as a proxy indicator of HIPAA compliance.

Achieving HIPAA Compliance

TrustedSec has years of experience helping organizations meet HIPAA security and privacy compliance requirements. Please reach out with any questions on this topic or if your organization needs assistance with its HIPAA Compliance program.

Organizations with questions about how the HIPAA Security, Privacy, and Breach Rules apply should stay tuned as we will be publishing multiple blog posts soon to explore these topics in more depth.