The Health Information Technology for Economic and Clinical Health Act (HITECH) was signed into law in 2009, and amended the existing Health Insurance Portability and Accountability Act (HIPAA). The HITECH Act was meant to ensure that healthcare organizations of all sizes were adhering to new guidelines and best practices surrounding information security.

To help improve the security of healthcare data and Protected Health Information (PHI), some provisions of the HITECH Act require covered entities to conduct risk assessments, adopt the use of multi-factor authentication methods, protect electronic health records with encryption, and develop incident response plans.

What is HIPAA?

HIPAA is a set of federal regulations, passed in 1996 and 2003, that impose health data privacy requirements on covered entities.  The main objective of HIPAA was to make it easier for patients to obtain health insurance while protecting their personal health information (PHI). 

A covered entity is a healthcare provider or business that creates or receives PHI.  Examples include hospitals, doctor’s offices, insurance companies, pharmacy chains, and other medical companies.  For covered entities to receive any form of federal funding, they must comply with these rules.

But if you’re reading this, chances are you already know all that.  HIPAA has been a part of the medical community’s vocabulary for over 25 years.  However, the HITECH Act is less well-known, but its directives are of equal importance to any business in the healthcare industry.

The HITECH Act Implementation

HIPAA’s privacy and security protections were updated in 2009 with the passage of The Health Information Technology for Economic and Clinical Health (HITECH) Act.  All healthcare entities, including both covered entities and business associates, will be required to comply with new enforcement rules and standards that stem from the implementation of HITECH.  The HHS Security Rule (modified by HITECH) provides significant penalties against any entity that suffers a breach involving unsecured protected health information (PHI).  Since 2014, all healthcare providers and organizations must ensure their security programs are up to par or face possible fines or other sanctions.

Although HITECH has been in full swing for around eight years, many medical practices, clinics, and even hospitals have not fully implemented sufficient policies, controls, and procedures to comply with the Act.  

The HHS Office of Civil Rights (OCR) is responsible for enforcing HIPAA’s Privacy Rule, which focuses on four key elements: limiting access (via a need-to-know policy), employing robust authentication mechanisms for electronic systems using multi-factor authentication tools such as smart cards or biometrics, restricting physical access to areas where data is stored or created, and establishing administrative safeguards that require documented evidence that all individuals designated with key roles are carrying out their responsibilities correctly.

But it’s not just the healthcare facility or medical practice that’s required to comply with the Act.  HITECH also requires compliance by any “Business Associate” of the facility.   These individuals or companies are defined as those who create, receive, maintain, or transmit PHI on behalf of a covered entity.  They can include third-party vendors such as IT service providers and shredding companies. 

Business associates could also be an organization that assists a covered entity in making disclosures (if permitted under HIPAA) for treatment, payment, or health care operations activities.  It is incumbent upon the facility or practice to ensure that the Business Associate complies with the Act.

So what exactly is in the HITECH Act?  The full text of the Act is about 54 pages, and the HIPAA Omnibus Rule (which merged HIPAA and HITECH into one) is a whopping 563 pages!  That’s almost as long as the first two Harry Potter books combined.  Luckily, we’ve distilled all the legal jargon down to something that’s much more palatable.  In general, there are five “Rules” that pertain to the HITECH Act that must be considered when discussing IT and information security for the healthcare industry.  They are:

1.  The HIPAA Privacy Rule

2.  The HIPAA Security Rule

3.  The HIPAA Omnibus Rule

4.  The Breach Notification Rule

5.  The Enforcement Rule

We’ll go over each rule and what it entails below.

The HIPAA Privacy Rule

Simply put, the Privacy Rule sets forth regulations that dictate how PHI is used and disclosed by covered entities and business associates.  It is similar in function to how a company’s privacy policy discloses how any information you share with the company is used. 

Unlike most companies, however, covered entities must keep vigorous records on how PHI is used, to whom it is disclosed and why, and must appoint a “Privacy Officer” to keep track of all that information, along with records of training their employees on documented policies and procedures as they related to patient privacy.

But how does this tie into the HITECH Act?  Since the vast majority of patient data is now in electronic form, it is vital for covered entities to understand how their business associates (especially those who are responsible for the maintenance and operation of electronic systems containing patient data) are using and disclosing PHI.

Although most HIPAA Privacy Rule violations occur at an entity’s main office or facility, they often result from business associates improperly using or disclosing PHI at remote locations, such as home offices or leased workspaces.

The HIPAA Security Rule

While the Privacy Rule concentrates on PHI in general, the Security Rule zooms in slightly and deals with electronic PHI (ePHI).  With the proliferation of mobile devices and an increasing reliance on online resources, the Security Rule addresses the risks posed in this digital age.

What is ePHI, exactly?

ePHI is any PHI stored on an electronic device.  The Security Rule states that data on those devices must be protected in two instances: in transit and at rest.  In simplest terms, it means that you must adequately protect the data when it’s being sent from one system to another (in transit), whether that’s intra-office or inter-entity (i.e., a doctor sending a patient record to a treatment center or hospital).  It also means that you must protect the data when it’s stored in your organization (at rest), be that a desktop computer, a server, the cloud, or some other means of digital data storage.

The Safeguards

The Security Rule sets forth three primary “safeguards” that covered entities, and their business associates must adhere to in order to be in compliance.  They are Technical Safeguards, Physical Safeguards, and Administrative Safeguards.  Here, the “meat” of HITECH compliance requirements is found.

Technical Safeguards

There are five key areas that covered entities must develop rigorous policies and procedures when it comes to technical safeguards: Access Controls, Person or Entity Authentication, Audit Controls, Integrity, and Transmission Security

Access Controls.  The Technical Safeguards state that you must ensure that ePHI can only be accessed by authorized users.  The most well-known best practice to ensure access is appropriately controlled is IAM (Identity & Access Management).  By employing a comprehensive IAM process, covered entities can ensure that the proper access is granted to each employee that is relevant to their job.

Person or Entity Authentication.  Whereas access controls deal with “authorization” (is User A authorized to access this information), Person or Entity Authentication deals with ensuring that User A is the individual actually accessing the information.  There are multiple ways we can authenticate to systems, the most common being passwords and PIN numbers.  Two-factor authentication mechanisms such as push notifications to a registered mobile device are also means of authenticating a user.

Audit Controls.  These controls must be in place to allow the covered entity to monitor, record, and examine all activity as it relates to ePHI.  Most covered entities that have ePHI also have an Electronic Health Record (EHR) system.  EHRs have myriad features available that allow the covered entity to easily achieve compliance with the audit controls directive.  A robust audit controls practice will assist in conducting required risk assessments and periodically reviewing system/data access.

Integrity.  Maintaining the integrity of the ePHI (which means ensuring the data is not destroyed or altered in a way that is not compliant with HIPAA) in your organization is important for a few reasons.  First, disposing of ePHI isn’t as simple as just clicking “delete.”  When disposing of computer hard drives that contained ePHI, you must destroy the drive in such a way that would make it impossible to retrieve any data from it.

Transmission Security.  As the name suggests, transmission security deals with the security of ePHI while it is in transit.  HITECH sets forth encryption standards both for in-transit and at-rest data.  The encryption should render all ePHI data “unusable, unreadable, or indecipherable.”

Physical Safeguards

Like the Technical Safeguards, Physical Safeguards have standards as it relates to the physical access to ePHI and PHI in general.  They are Facilities Access Controls, Workstation Use, Workstation Security, and Device & Media Controls.

Facilities Access Controls.  This control deals with proper procedures and control mechanisms that limit access to the location(s) where ePHI is stored.  It is further broken out into four distinct implementation specifications.  

Contingency operations require that the entity has in place sufficient security measures to access locations where ePHI is stored during a disaster or other event that requires emergency restoration of ePHI data. 

The Facility Security Plan dictates that entities must document the use of physical access controls to ensure that only authorized individuals have access to the facilities and equipment that contain ePHI. 

The Access Control & Validation Procedures are procedures that are designed to validate that the individual(s) accessing the facilities have a legitimate business need to do so and have the appropriate level of access. 

Finally, Maintenance Records require the documentation of all repairs and modifications made to the secure facility when those repairs/modifications modify an aspect of security.  For example, if you have a door lock that is secured by entering a PIN and that door lock needs to be replaced, the entity must document the date, reason for repair/modification, and the approving individual.

Workstation Use.  It is important that employees of the entity be aware of the approved uses for their workstations and devices. These uses should be documented and updated as needed, to ensure only approved tasks are performed on their workstations.  Organizations commonly have an “Acceptable Use Policy” which generally addresses what constitutes proper use of a workstation or device that has access to ePHI.

Workstation Security.  This control dovetails into the workstation use control but focuses on how the workstation or device is physically secured.  Ensuring workstations cannot be physically accessed by unauthorized individuals, or securing a laptop in a locked drawer or cabinet when not in use are good examples of implementation of workstation security.

Device and Media Controls.   This control focuses on ePHI stored on portable devices such as tablets, flash drives, or other portable media storage devices. There are four implementation specifications that focus on these device controls: disposal, media reuse, accountability, and data backup and storage.

Disposal,  as the name implies, dictates that the entity should implement policies related to how removable media is disposed of once it has reached its end of life.  It also includes disposal procedures for workstations, laptops, and other devices once they have reached end of life.

Media Reuse,  also known as equipment re-use, refers to safeguards necessary to ensure data residing on one removable device is not copied/transferred to another removable device before being completely erased from the original device.

Accountability ensures that when a workstation or removable device is lost (or stolen), it can be immediately identified using methods such as login tracking.  

The last implementation specification in regard to device controls is Data Backup & Storage,  which requires entities put in place both hardware and software mechanisms for backing up data.

Administrative Safeguards

The Administrative Safeguards are designed to address the policies and procedures that govern the acquisition, management, and dissemination of ePHI.  These safeguards comprise more than 50% of the HIPAA Security requirements.  A comprehensive, well-architected policies and procedures repertoire is vital to the proper execution of an entity’s security program.

There are nine Administrative Safeguards in total:

1. The Security Management Process
2. Assigned Security Responsibility
3. Workforce Security
4. Information Access Management
5. Security Awareness and Training
6. Security Incident Procedures
7. Contingency Planning
8. Evaluation
9. Business Associate Contracts and Other Arrangements

Due to its voluminous content that permeates across all other Privacy Rule implementation specifications throughout Subpart C & D (Security & Transaction Data Requirements), we will not be discussing these controls in detail at present; however, their importance cannot be overstated – be sure you properly understand them!

The Security Management Process.  This safeguard deals with the prevention, detection, containment, and correction procedures in place for security violations.  It includes risk analysis & management, sanction policy (for individuals who fail to comply with established security policies and procedures), and information system activity review (i.e., review audit logs, access reports, and other security incident tracking reports to determine the inappropriate use or disclosure of ePHI.

Assigned Security Responsibility.  This safeguard requires that the entity name a Security Official who is responsible for the development and implementation of all policies and procedures that are in place to ensure compliance with the Security Rule.

Workforce Security.  This safeguard requires the identification of individuals who require access to ePHI to carry out their duties.  In addition, for each role in the organization, it requires the identification of exactly what ePHI is needed and when it is needed.  There are three addressable implementation specifications: Authorization and/or Supervision, Workforce Clearance Procedures, and Termination Procedures.

Information Access Management.  This safeguard should complement, and be tightly integrated with, the policies and procedures set forth to comply with the Privacy Rule’s minimum necessary requirements. 

There are three implementation specifications: Isolating Health Care Clearinghouse Functions (only applicable if a health care clearinghouse is part of a larger organization), Access Authorization, and Access Establishment and Modification.  If these sound familiar, you’ve obviously been paying attention.  These specifications dovetail into the Technical Safeguards discussed previously.

Security Awareness and Training.  This safeguard dictates the training and awareness that every employee of the entity must be aware of.  There are four implementation specifications: Security Reminders, Protection from Malicious Software, Log-in Monitoring, and Password Management. 

The safeguard states that all new employees must undergo security training, and it recommends that periodic retraining of staff be performed to ensure your workforce is up-to-date on not only your organization’s policies and procedures, but any updates or changes to the Security Rule in general.

Security Incident Procedures.  This safeguard deals with ensuring the entity has in place proper procedures for handling security incidents in the organization.  The Security Rule defines a security incident as, “the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.”

Security incident procedures must address how to identify security incidents and provide that the incident be reported to the appropriate person or persons.  There is one implementation specification, Response and Reporting.  This specification states that procedures should be in place that dictates how an employee is to respond to an incident, such as preservation of evidence, incident mitigation, and documentation requirements.

Contingency Planning.  The contingency plan (also referred to in the IT industry as a “business continuity plan” or “business resumption plan”) should state how the organization responds to an emergency such as a power outage, natural disaster, or other events that disrupt critical business operations. 

There are five implementation specifications: Data Backup Plan, Disaster Recovery Plan, Emergency Mode Operation Plan, Testing and Revision Procedures, and Applications and Data Criticality Analysis.

Evaluation.  The purpose of the evaluation is to establish a process for covered entities to review and maintain reasonable and appropriate security measures to comply with the Security Rule.  Policies and procedures must be reviewed on a regular basis (annually or semi-annually) to ensure they are up-to-date and congruent with how the entity operates.  It’s also critical that the organization evaluate both technical and non-technical aspects of the security program.

Business Associate (BA) Contracts and Other Arrangements.  The final safeguard deals with BAs who create, receive, maintain, or transmit ePHI.  An example of a BA, in this case, would be the software provider of your EHR system.  It sets forth requirements for contracts that must be in place between the entity and the BA that provides assurances that the BA will adhere to all applicable requirements to safeguard ePHI.

The HIPAA Omnibus Rule

The HIPAA Omnibus Rule was implemented to merge the existing 1996 HIPAA law with the HITECH Act.  In addition, however, the Omnibus strengthened the protection of PHI and ePHI.  It enhanced many of the Rules we’ve already covered, and implemented stringent penalties for non-compliance with the requirements set forth. 

It further required Business Associates and their subcontractors liable for their own HIPAA compliance.  In essence, the Omnibus gave HIPAA some “teeth.”  In addition, Omnibus modified the Breach Notification Rule to state that any unauthorized use or sharing of PHI (whether physical or electronic) should be presumed to be a breach. 

The HIPAA Breach Notification Rule

In response to growing cyberattacks and other forms of data breaches impacting businesses in all industries—including healthcare organizations—this rule was written with an eye toward improving individual rights with regard to medical information privacy.

What is a breach?

The Breach Notification Rule defines a breach as “an impermissible use or disclosure under the Privacy Rule that compromises the security or privacy of the protected health information.”  If the entity or BA can demonstrate that there is a low probability of the PHI being compromised, it may not qualify as a breach.  A risk assessment that factors in the following is necessary:

1. The nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification;
2. The unauthorized person who used the protected health information or to whom the disclosure was made;
3. Whether the protected health information was actually acquired or viewed; and
4. The extent to which the risk to the protected health information has been mitigated.

There are three exceptions to the definition of “breach.”  If any one of these applies, then a breach has not occurred:

1. Unintentional acquisition, access, or use of PHI by a workforce member or person acting under the authority of an entity or BA if made in good faith within the scope of authority.
2. Inadvertent disclosure of PHI by a person authorized to access PHI at an entity or BA to another person authorized to access PHI at the covered entity or business associate, or organized health care arrangement in which the covered entity participates.  For example, Employee A discloses certain PHI to Employee B regarding a patient.  Employee B is authorized to access PHI but did not have a business need-to-know about the patient’s PHI.
3. The entity or BA has a good faith belief that the unauthorized person to whom the impermissible disclosure was made would not have been able to retain the information.  An example would be if an individual was mistakenly given a physical copy of another patient’s PHI instead of their own, but the mistake was caught before the individual left the medical office.  In this case, there is a reasonable assumption that the individual would not have been able to retain the information, since they immediately noticed that the file was not theirs and notified the workforce member.

Unsecured PHI

Entities and BAs only have to provide the required notifications if the breach resulted in access to PHI that was unsecured/unencrypted.  Specifically, the Rule states that unsecured PHI is “that which has not been rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology.”  Therefore, if a breach occurred, but the entity or BA can demonstrate that all of the files that were affected by the breach were properly encrypted, notification is not necessary.

Breach Notification Requirements

Following a breach of unsecured PHI, entities must provide notification to affected individuals, the Secretary of Health & Human Services, and, in some cases, to the media. 

Individual notifications must be made by first-class mail (and, secondarily, by email, if appropriate) no later than 60 days following the discovery of the breach. 

Notification to the Secretary must be made no later than 60 days following the discovery of the breach if the breach affects more than 500 individuals.  If the breach affects fewer than 500 individuals, the entity may make a notification to the Secretary on an annual basis, no later than 60 days after the end of the calendar year in which the breach occurred.

For breaches affecting more than 500 individuals, entities are required to provide notice to prominent media outlets serving the State or jurisdiction.  This must be done no later than 60 days following the discovery of a breach.

Business Associate Notification

If a BA experiences a breach, they are required to disclose this to the covered entity no later than 60 days following the discovery of the breach.

The HIPAA Enforcement Rule

One of the most prominent changes in HIPAA as a result of HITECH and the Omnibus Rule was the establishment of an enforcement arm through the US Department of Health & Human Services’ Office of Civil Rights (OCR).  OCR has been tasked with enforcing HIPAA privacy, security, breach notification, and transaction/code set standards.

All covered entities are required to comply with these standards through annual certifications of compliance. Failure to do so can lead to fines or even litigation from OCR against your business. Although OCR primarily investigates individual complaints against an organization, they also conduct compliance reviews to determine compliance with HIPAA standards.

The Importance of Compliance

Significant fines are attached to any finding by OCR that an organization is not in compliance with any aspect of the Rules.  Fines can vary greatly, from tens of thousands of dollars to millions of dollars.  In 2018, the largest fine ever incurred for a HIPAA violation was Anthem, Inc., which was hit with a $16 million fine in relation to the breach of approximately 78.8 million records in 2015. 

For many organizations, the fines, the reputational hit, and any ensuing litigation by affected individuals are enough to shutter their operations.  That is why every covered entity, no matter how big or small, must have a robust set of controls, policies, and procedures in place to guard against any potential breach.

How Axeleos Can Help

If you’ve made it to the end of this article, we applaud you.  Despite its length, this article only touches the surface of everything involved in achieving an acceptable security posture as it relates to HIPAA, the HITECH Act, and the Omnibus Rule.

At Axeleos, we take the security of PHI very seriously, and our HIPAA security experts can help your organization achieve compliance with everything that was discussed in this article and more. 

We offer several engagements of varying scope to help your organization navigate the requirements set forth by HIPAA. 

Don’t let a breach or a compliance review by OCR cause your organization and your patients to suffer damages.  Contact us today, and let us talk about how we can help you secure your practice.