THE HITECH ACT
The Health Information Technology for Economic and Clinical Health Act (HITECH Act or "The Act") is part of the American Recovery and Reinvestment Act of 2009 (ARRA). ARRA contains incentives related to health care information technology in general (e.g. creation of a national health care infrastructure) and contains specific incentives designed to accelerate the adoption of electronic health record (EHR) systems among providers.
Because this legislation anticipates a massive expansion in the exchange of electronic protected health information (ePHI), the HITECH Act also widens the scope of privacy and security protections available under HIPAA; it increases the potential legal liability for non-compliance; and it provides for more enforcement.
The following discussion will highlight some of the HITECH Act's key provisions, but only those that are HIPAA centric. For example, financial incentives (i.e. the actual numbers) for EHR adoption under Medicare and Medicaid have been widely dissected online and are not covered here (some of the websites that contain specific financial incentive information may be located in the Appendix). Consistent with the objectives of this guide, the intent is to provide an overview so that providers can obtain a "big picture" view of legislation likely to impact their practices in significant ways going forward.
Many of the HITECH Act's requirements become effective 12 months from the date of enactment, but there are other effective dates that operate on a different schedule. We will not cover the various effective dates because other resources available on the Internet capture this information in detail (see the Appendix).
We have decided not to use specific statutory references in this section for several reasons: 1) this section is intended as an overview; and 2) HHS will be forthcoming with additional guidance and therefore detailed analysis is best deferred until more clarity emerges.
HIPAA Survival Guide Note: HITECH Act Text
If your looking for the actual text from the HITECH Act, click here: HITECH Act Text.
Enforcement
As mentioned previously, and more or less widely known within the heath care industry, the consensus view is that HIPAA has not been rigorously enforced in the past. Time will tell how the enforcement regime will change post the HITECH Act, but certainly the Act contains language that implies lax enforcement may be ancient history. Under HITECH, mandatory penalties will be imposed for "willful neglect." Obviously what "willful neglect" means will be determined on a case-by-case basis, but speaking in the parlance of this guide, we believe that a provider with "no story" regarding compliance (or so minimal a story as to portray a cavalier attitude toward compliance) will likely be at significant risk.
Civil penalties for willful neglect are increased under the HITECH Act. These penalties can extend up to $250,000, with repeat/uncorrected violations extending up to $1.5 million. Legislators appear to be sending a clear message that "we are not in Kansas" anymore. Furthermore, under certain conditions HIPAA's civil and criminal penalties now extend to business associates. Like HIPAA, the HITECH Act does not allow an individual to bring a cause of action against a provider. However, it does allow a state attorney general to bring an action on behalf of his or her residents. Finally, HHS is now required to conduct periodic audits of covered entities and business associates.
Clearly, the legislative intent is to provide for "enhanced enforcement." To what degree enforcement actually increases on the ground is yet to be determined, but the HITECH Act significantly ups the ante for non-compliance.
Notification of Breach
The HITECH Act now imposes data breach notification requirements for unauthorized uses and disclosures of "unsecured PHI." These notification requirements are similar to many state data breach laws related to personally identifiable financial information (e.g. banking and credit card data). HHS is required to define what "unsecured PHI" means within 60 days of enactment. If it fails to do so then the HITECH definition will control. Under the HITECH Act "unsecured PHI" essentially means "unencrypted PHI."
In general, the Act requires that patients be notified of any unsecured breach. If a breach impacts 500 patients or more then HHS must also be notified. Notification will trigger posting the breaching entity's name on HHS' website. Under certain conditions local media will also need to be notified. Furthermore, notification is triggered whether the unsecured breach occurred externally or internally. The notification provision is yet another example of the weight privacy and security concerns are given under the Act.
Electronic Health Record Access
In the case where a provider has implemented an EHR system, the Act provides individuals with a right to obtain their PHI in an electronic format (i.e. ePHI). An individual can also designate that a third party be the recipient of the ePHI. The Act provides that only a fee equal to the labor cost can be charged for an electronic request.
Presumably, all that needs to be done on a provider's part is to click on a few screens and transmit the necessary records, the reality is that even providers that already have an EHR system in place may not have this capability readily available. However, given the Health 2.0 consumer led movement, you can expect that electronic records will be requested significantly more often than their paper counterparts.
Any provider expecting to participate in the HITECH Act's incentives should be prepared to deliver on these requests or risk a finding that their use does not qualify as "meaningful use." Lack of meaningful use may bar incentive payments, depending on how HHS ultimately defines this term. To be clear, the Act has nothing to say regarding a link between requests of ePHI and meaningful use, this is simply a plausible inference on our part.
Business Associates and Business Associate Agreements
The HITECH Act now applies certain HIPAA provisions directly to business associates. Formerly, privacy and security requirements were imposed on business associates via contractual agreements with covered entities. As we have noted elsewhere in this guide, we suspect that many small providers do not have the requisite contracts (aka Business Associate Agreements) in place. In some cases Business Associate Agreements (contracts) exist but may not meet all the requirements of the rules. Under the lax enforcement regime of the past, lack of contractual agreements has apparently not proved problematic for the provider community as a whole. This may soon change.
Under the HITECH Act, business associates are now directly "on the compliance hook" since they are required to comply with the safeguards contained in the HIPAA Security Rule (SR). The HITECH Act does not speak directly to the rationale, but even casual observers understand that a potentially massive expansion in the exchange of ePHI increases the privacy and security concerns of all stakeholders. Most, if not all, software vendors providing EHR systems will clearly qualify as business associates. Requiring vendors to comply directly ensures that more provider/vendor dialog will occur regarding the necessary Business Associate Agreements (contracts), and regarding other compliance issues of mutual interest. The vendors themselves will insist on it.
The "fun" for business associates does not stop with HIPAA Security Rule compliance and contractual agreements. The Act requires business associates to report security breaches to covered entities consistent with the notification requirements. Also, they are now subject to civil and criminal penalties under HIPAA if certain conditions exist, as mentioned in the introduction of this section. Finally, the business associate requirements listed above are illustrative and not exhaustive. There are additional business associate requirements that may be imposed depending on how the relationship with the provider is defined.
The bottom line is that business associates and providers will share more joint responsibilities than they have previously. Large providers, with the help of counsel and other specialized staff, will not likely be surprised by these changes. However, for many small providers the HITECH Act may be the first real introduction to the business associate concept-yet one more regulatory requirement that will require serious attention.
Other Requirements
The HITECH Act contains additional requirements (e.g. marketing communications, restrictions and accounting) that modify HIPAA in important ways. We simply choose not to cover these because they are even more arcane than the requirements previously listed, but that should not imply that we consider them any less important.
Concluding Comments on the HITECH Act
First we need to emphasize that coverage of the HITECH Act as provided in this guide includes only a small subset of the Act's content that may be relevant to providers. Other resources in the Appendix point to where additional detailed information can be found. One of the principal reasons for writing this guide was to highlight that the Act now makes HIPAA more directly relevant to providers (financially and otherwise), from a practical perspective, than it may have been in the past.
Why? Because under the HITECH Act there are significant taxpayer dollars appropriated in the form of incentive funding that directly target a provider's adoption of an EHR system. Regulators, patients and other stakeholders are certain to demand more transparency and accountability. If a provider wants to receive the benefit of incentives, or at a minimum wants to avoid any subsequent penalties, then they appear to have little choice, other than to increase their literacy regarding HIPAA's Privacy and Security Rules and the new provisions of the Act.
Small providers may benefit enormously if they can find creative ways to pool resources to respond to these challenges.
21st Cures Act: What is this? The Cures is starting (a decade later) to realize the HITECH Act's vision for EHR interoperability. It provides the following:
The Cures Act is designed to advance interoperability; support the access, exchange, and use of electronic health information (EHI); and address occurrences of information blocking. IT promotes innovation in health care technology to deliver better health information, more conveniently, to patients and clinicians, while promoting transparency, generally to provide patients better insight into their PHI. Substantively it is primarily focused on interoperability between EHRs, HIEs, and health information networks of “certified health IT” and addressing occurrences of information blocking. Interoperability between these organizations has been the “holy grail” of health care technology since the promulgation of the HITECH Act in 2009 and the setting of requirements for EHRs to meet the “meaningful use” criteria, thereby becoming certified and receiving the statutory financial incentives of certification.
The Cures Act is in essence a set of technical regulatory requirements the certified health IT vendors must meet to maintain certification.The HITECH Act amended the Public Health Service Act (PHSA) and created ‘‘Title XXX—Health Information Technology and Quality’’ (Title XXX) to improve health care quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange. Under the HITECH Act, section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a program or programs for the voluntary certification of health IT. Specifically, section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under this subtitle (i.e., certification criteria adopted by the Secretary under section 3004 of the PHSA).
For example, the Cures Act establishes application programming interface (API) requirements, including for patients’ access to their PHI without special effort. The API approach also supports health care providers’ independence to choose the ‘‘provider-facing’’ third-party services they want to use to interact with the certified API technology they have acquired. It also determines whether information blocking has occurred by identifying reasonable and necessary activities that would not constitute information blocking. Many of these activities focus on improving patient and health care provider access to PHI. Certification criterion focuses on supporting two types of API-enabled services: (1) Services for which a single patient’s data is the focus and (2) services for which multiple patients’ data are the focus. The API certification criterion requires the use of the Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) standard Release 4 and references several standards and implementation specifications adopted in § 170.213 and § 170.215 to support standardization and interoperability.
Adoption of the United States Core Data for Interoperability (USCDI) as a Standard which replaces ‘‘Common Clinical Data Set’’ (CCDS) standard. For example, this standard defines which data elements an EHR vendor supports, for exchange with other entities, to claim that it is “interoperable” and presumably continues to publish certified health IT. The USCDI standard would establish a set of data classes and constituent data elements required to support interoperability nationwide. The Cures Act finalized an update to the electronic prescribing National Council for Prescription Drug Programs (NCPDP) SCRIPT standard in 45 CFR 170.205(b) from NCPDP SCRIPT standard version 10.6 to NCPDP SCRIPT standard version 2017071 for the electronic prescribing certification criterion (§ 170.315(b)(3)).
The Cures Act established Conditions and Maintenance of Certification requirements for health IT developers based on the Conditions and Maintenance of Certification requirements outlined in section 4002 of the Cures Act. These initial requirements for health IT developers and their certified Health IT Module(s) as well as ongoing requirements that must be met by both health IT developers and their certified Health IT Module(s). For example, one of the requirements of a certified health IT vendor is that it not take any action that constitutes information blocking as defined in section 3022(a) of the Public Health Service Act (PHSA).
For example, the Cures Act establishes application programming interface (API) requirements, including for patients’ access to their PHI without special effort. The API approach also supports health care providers’ independence to choose the ‘‘provider-facing’’ third-party services they want to use to interact with the certified API technology they have acquired. It also determines whether information blocking has occurred by identifying reasonable and necessary activities that would not constitute information blocking. Many of these activities focus on improving patient and health care provider access to PHI.
Download a FREE copy of the HIPAA Survival Guide 4th Edition.