Headed to RSA in San Francisco? May 6-9 | Join us!

7 HITRUST Regulatory Factors to Consider for Healthcare

This article is Part One of a Four-part Series on the HITRUST Framework

Part One: 7 HITRUST Regulatory Factors to Consider for Healthcare 
Part Two: 7 HITRUST Regulatory Factors to Consider for Federal Compliance 
Part Three: 5 HITRUST Regulatory Factors to Consider for International and State-level Privacy Compliance
Part Four: 4 Miscellaneous HITRUST Regulatory Factors to Consider

When you think of HITRUST, you probably think of healthcare. After all, HITRUST was originally created as the “Health Information Trust Alliance.” However, over the past few years HITRUST has evolved to serve as an industry-agnostic common security framework – such that any company in any industry can now pursue a HITRUST CSF certification.

At its core, HITRUST is based on best practices from ISO/IEC 27001 and 27002, as well as more than 40 additional security and privacy regulations and standards, such as PCI, NIST and HIPAA. HITRUST considers these standards and regulations to be its authoritative sources.

In addition to these authoritative sources that serve as the foundation of HITRUST, there are also more than 20 regulatory factors that an organization could consider individually based on specific industry requirement – these are optional inclusions to an assessment.

Whether your organization is pursuing its first HITRUST certification or is returning for a recertification, it can be tricky to parse close to two dozen regulatory factors to determine if they should be included in an assessment. In this post, we will explore seven regulatory factors related to the healthcare industry. Future articles will focus on federal compliance, state and international privacy regulations, and the remaining miscellaneous regulations.


First Introduced in HITRUST 1.0 September 2009 as a baseline of the hitrust requirements, but under HITRUST 9.2 – January 2019, HIPAA became an optional regulatory factor

The Healthcare Information Portability and Assurance Act (HIPAA) was enacted by President Clinton in 1996, making it one of the oldest and most influential information security and privacy regulations in the United States. In fact, HIPAA serves as a precursor to HITRUST, since HITRUST was conceived as a certifiable standard for HIPAA compliance. However, as HITRUST has transitioned from a specific healthcare-related standard into a more industry-agnostic framework, the HIPAA regulations were moved into separate optional regulatory factors.

HIPAA requirements focus on the Security Rule, Privacy Rule and Breach Notification. Several healthcare providers and insurance companies require their business partners to demonstrate HIPAA compliance as a pre-requisite to working together, and the HITRUST CSF is a certifiable and widely accepted framework to demonstrate HIPAA compliance.

The A-LIGN Bottom Line: Any organization that processes, stores or exchanges healthcare data should include HIPAA in its HITRUST assessment.

CMS Minimum Security Requirements (High)

First Introduced in HITRUST 3.0 – December 2010

The Centers for Medicare & Medicaid Services (CMS) Information Security and Privacy Acceptable Risk Safeguards (ARS) sets forth a set of guidelines for its contractors known as the CMS Minimum Security Requirements (CMSR). These requirements share a common heritage with HITRUST, since the CMS requirements are based on NIST (among others) and regulated by HIPAA, which both serve as authoritative sources for HITRUST. The purpose of the CMSR is to protect Medicare & Medicaid information and information services, including CMS Sensitive Information.

Systems Security Levels (Low/Moderate/High) are defined within the appendix of the ARS manual. The Moderate and High impact levels require an independent Security Assessment; therefore, HITRUST has incorporated CMSR (High) as one of the optional regulatory factors to be included in a HITRUST assessment.

The A-LIGN Bottom Line: CMS contractors may be required to demonstrate compliance, but any organization that handles Medicare or Medicaid data should be advised to include CMSR High in its HITRUST assessment.

MARS-E Requirements

First Introduced in HITRUST 7.0 – January 2015

The Centers for Medicare & Medicaid Services (CMS) introduced its Minimum Acceptable Risk Standards for Exchanges (MARS-E) to address patient protection mandates and the Affordable Care Act. MARS-E applies to all “Administering Entities,” which are defined as state or federal exchanges and marketplaces, state Medicaid agencies, Children’s Health Insurance Program (CHIP) agencies, or state agencies administering the Basic Health Program. The purpose of MARS-E is to comply with the security and privacy standards and hitrust requirements of the Affordable Care Act.

The A-LIGN Bottom Line: MARS-E is primarily focused on the exchange of healthcare information related to Medicare and Medicaid. Whereas CMSR should be considered by any organization that handles this sort of healthcare information, MARS-E is more directly focused on the exchange of this information.

Joint Commission Accreditation (formerly JCAHO)

First Introduced in HITRUST 2.2 – September 2010

The Joint Commission Accreditation is a non-profit organization that accredits more than 22,000 healthcare programs across the United States. Many state governments recognize Joint Commission Accreditation as a licensing condition to receive Medicare and Medicaid reimbursements. In fact, from 1965 until 2010, the Joint Commission Accreditation was a legally recognized authority for hospital accreditation; however, the Medicare Improvements for Patients and Providers Act of 2008 (MIPPA) eliminated that distinction. Following that reversal, the Joint Commission Accreditation became subject to the requirements of CMS accreditation.

The A-LIGN Bottom Line: Joint Commission Accreditation is an optional accreditation that does not need to be included in a HITRUST assessment, unless an organization is contractually obligated. Additionally, Joint Commission Accreditation is much broader in scope than just cybersecurity and privacy, so including it in a HITRUST assessment could dramatically increase the scope of work.

EHNAC Accreditation

First Introduced in HITRUST 9.0 – September 2017

The Electronic Healthcare Network Accreditation Commission (EHNAC) is similar to the Joint Commission Accreditation because it is also a non-profit organization, but whereas the Joint Commission is focused on accrediting healthcare providers, EHNAC is focused on accrediting health information exchanges and other electronic health services, such as payments and prescriptions. EHNAC develops standards for health information exchanges, and it serves as the accrediting body for these standards.

The A-LIGN Bottom Line: Pursuing EHNAC Accreditation is an extraneous activity, unless an organization is contractually obligated. Organizations involved with health information exchanges may find EHNAC Accreditation worthwhile, but would typically pursue it independently of a HITRUST assessment.

Texas Health & Safety Code, Section 181 (TX HB 300)

First Introduced in HITRUST 5.0 – January 2013

The Texas House Bill 300 (TX HB 300) is a state-level healthcare regulation that is considered to be a more stringent version of HIPAA compliance, and section 181 deals specifically with Medical Records Privacy for residents of Texas. One of the primary differences between TX HB 300 and HIPAA is that TX HB 300 casts a much wider net in defining its covered entities. TX HB 300 includes any individual that possesses protected health information (PHI), even the academics, accountants, and lawyers that are precluded from HIPAA compliance. TX HB 300 introduces new standards for the handling of electronic health records (EHR), and it requires extensive, periodic employee training.

The A-LIGN Bottom Line: Any Organization (note extended definition of covered entity) that assembles, collects, analyzes, uses, evaluates, stores, or transmits PHI for a Texas resident should consider including this regulatory factor.

HITRUST De-ID Framework Requirement

First Introduced in HITRUST 8.0 – February 2016

The HITRUST De-Identification Framework was developed to provide a program and methodology for anonymizing data so that it can be used for the purpose of comparative effectiveness research (CER), Health Economics and Outcomes Research (HEOR), early detection of disease outbreaks, reduction of medical errors, and so forth.

The A-LIGN Bottom Line: Organizations should balance the risk vs the reward of de-identifying protected healthcare information, since the penalty for errors can be significant. As a result, most organizations avoid the process of transacting anonymized healthcare data. But for those organizations that are willing to take the risk, the HITRUST De-ID Framework Requirement is a worthwhile inclusion to a HITRUST CSF Assessment.

The A-LIGN Bottom Line: Organizations should balance the risk vs the reward of de-identifying protected healthcare information, since the penalty for errors can be significant. As a result, most organizations avoid the process of transacting anonymized healthcare data. But for those organizations that are willing to take the risk, the HITRUST De-ID Framework Requirement is a worthwhile inclusion to a HITRUST CSF Assessment.

Implement a Strategic Approach to HITRUST Compliance

The standardization of compliance regulations and the consolidation of audits are both tenets of a strategic compliance program. Adding the correct regulatory factors to a HITRUST assessment is a great way to start realizing the benefits of strategic compliance vs. handling each assessment individually. In fact, even the HITRUST mission statement seems to resonate with a strategic approach to compliance: One Framework, One Assessment, Globally.

UP NEXT: Federal Regulatory Factors – Part 2 of 4

Download our HITRUST checklist now!