Back in February of 2009, the Obama Administration put the HITECH act into law, primarily as a means to update HIPAA which was started in 1996, and needed to be updated. But what is HITECH and how does it affect HIPAA?
HITECH stands for the Health Information Technology for Economic and Clinical Health Act.
It is a part of The American Recovery and Reinvestment Act of 2009 (ARRA) and was created to define and promote the use of electronic health records (EHRs) and Protected Health Information (PHI) by healthcare providers.
It was also created to help clarify (and improve!) the Health Information Portability and Accountability Act (HIPAA).
In 1996, Congress introduced the Health Insurance Portability and Accountability Act (HIPAA). This legislation was created to address two factors:
Although the The American Recovery and Reinvestment Act was primarily a stimulus bill meant to jumpstart the post-recession American economy, a portion of the bill was meant to address the failures of HIPAA.
This subsection was known as the Health Information Technology for Economic and Clinical Health (HITECH) Act.
The goals of HITECH include:
It's mainly the healthcare industry that are affected by these new regulations, but many related organizations are affected as well. In general, there are many organizations in various industries that need help with regulatory compliance, as data privacy laws keep changing and expanding.
But let's take a look at all of the pieces that make up the HIPAA and HITECH puzzle, starting with a definition of some of the related acronyms!
What’s included in an Electronic Health Record (EHR)?
An EHR typically includes:
PHI includes, but is not limited to:
Examples of PHI might include a medical record, a lab report, or a hospital bill because these documents contain enough information to connect a patient's name with protected health data.
PHI does not include:
An example of information that might seem like but is not technically PHI would be information collected by a consumer IoT/smartwatch device, such as blood pressure or heart rate data because that info isn’t shared with a covered entity.
So many acronyms, right?
That’s the downside, but the upside is HITECH helps ensure that notifications are sent to affected individuals when health information gets compromised and enforces tougher penalties for HIPAA compliance by incentivizing EHR handlers to comply with HIPAA.
HITECH also created the HIPAA WALL OF SHAME (you don’t want to be on this), and greater clarity for HIPAA compliance (spoiler alert: it’s still on the ambiguous side but more clear than before).
In a nutshell, HITECH establishes a concrete framework for the compliance goals of HIPAA by promoting the use of secure, portable EHRs (which contain PHI) using three stages of meaningful use and security.
These rules have some nuance depending on the organization and type of healthcare business.
For example, covered professionals and hospitals must meet 15 core objectives, 5 out of 10 “menu” objectives and 6 Clinical Quality Measures (called CQMs for short).
Providers are excused from meeting inapplicable standards. For example, physical therapists don’t write prescriptions so they’re excluded from compliance to e-prescriptions.
The core objectives of Stage 1 are focused on generally deploying and securing EHRs.
This stage is focused on using EHRs in more meaningful, sophisticated ways, such as being able to:
Electronic security is the first goal for Stage 2 HITECH compliance, such as encryption, regular risk analysis, and automated security updates.
HITECH’s Stage 3 is still under development and continues to evolve, but HITECH, as a whole, requires providers be HIPAA certified under the standards of the Omnibus Rule, which provides:
HITECH has also strengthened the HIPAA breach notification rule and expanded HIPAA compliance requirements to cover any business partners who use, store or process PHI.
That means billing companies, consultants, and IT technicians working on computers that store EHR are all responsible for the same security and privacy standards.
We know this is a lot of information!
Couple these requirement to PCI-DSS (for payment processing compliance) and it’s not hard to understand why a compliance and security program doesn’t work a la carte.
A good program requires a unified strategy that addresses your organization’s compliance requirements all together.
Which is appropriate because it’s everyone’s job and not just a few of us!
Check out our case study page to see how we've helped organizations of all sizes across many industries achieve and maintain regulatory compliance, including HITECH, HIPAA and more.