An Introduction to HITECH / HIPAA Risk Management Frameworks (part 2)
As discussed in the sidebar of this issue of the newsletter, an analytical framework is a process/method for "attacking" a particular problem space. In the case of HITECH / HIPAA risk management, the problem space is sufficiently wide in scope that no one framework will do it justice. Other than the Organizational Framework, there is no real order in which these frameworks should be rolled out. All of the frameworks must be attacked in order to mitigate a finding of willful neglect and to otherwise ensure compliance under HITECH's transformational regulatory scheme.
However, as we have often discussed in previous issues of the newsletter, there is
simply no way all the frameworks can be implemented in their entirety as one
"big bang" project (i.e. as a one time event). Historically, big bang
projects that attempt to solve wicked problems fail miserably for many reasons
including: 1) the problem is not understood well enough until you attempt to
solve it; 2) each stakeholder group will have a different view of the problem
space; and 3) there is usually not enough time and resources to even attempt a
big bang solution (it is akin to defying the law of gravity, even if the other wicked problem challenges were readily
surmountable, which they are clearly not).
In short, building an effective HITECH / HIPAA compliance
story can only be accomplished iteratively over time (e.g. Warren Buffet cannot
learn to speak fluent French in one week, no matter how much money he
throws at the problem). However, while an iterative approach to solving a
wicked problem is consistent with the laws of physics, it does beg the question
"what can practically be done within a given time
period and within budget?"
The answer to this question will vary
for each organization, but one thing seems clear, pieces of each framework will
have to be implemented in order to create the appropriate foundation going
forward and, needless to say, to avoid HHS fines and/or embarrassing/costly PHI data breaches. Although the definition of a
strong foundation may vary with the size of the organization (HHS' expectations
likely will as well), its importance cannot be underestimated. It is likely to
determine whether a "good compliance story" is ever obtained, let
alone the aspirational goal of full compliance.
The frameworks are intended as roadmaps and not as cookbook solutions. They are foundational to the H2 Compliance Scorecardsm that we have announced in this issue of the newsletter. The frameworks comprise a system of determining current compliance status and providing guidance over time as to the gaps. They are designed as a mechanism for attacking the "low hanging fruit" and to provide visible/demonstrable evidence that a covered entity or business associate is serious regarding HITECH / HIPAA compliance.
The organizational framework is arguably the most mission critical of the frameworks. Unless the board of directors ("BOD") and the executive management set the right tone and allocate the necessary resources, the cultural changes required to implement the frameworks will never be realized, and the organization's HITECH/HIPAA/EHR implementation is likely to be yet another EHR disaster.
There are a significant number of
stakeholders that must participate in both in an EHR implementation and in getting everyone on
board with a HITECH/HIPAA compliance strategy. The game has
changed too radically to simply turn either one of these efforts over to your
IT group, or to the compliance and/or legal staff. Too much is at stake. This is now a boardroom issue. Only time will tell
which boards and management teams recognize that this paper tiger is now an electronic beast.
In particular, the BOD and management
team must understand, at a level of literacy that few now possess, the
organizing principle captured in the HITECH concept of meaningful use. At the end of the
day, as discussed in this post, meaningful use is a much bigger concept
than compliance (i.e. avoiding fines and getting paid your EHR incentives),
rather it is part and parcel of
marketplace innovation that will define the delivery of health care in the 21st
century.
The Legal Framework
The legal framework encompasses both traditional legal work (e.g. compliance counseling/mentoring, contract drafting and review, etc.) and under HITECH, a certain quasi-technical role as well. Why the latter? Because HITECH mandates implementation of HIPAA's Security Rule for those covered entities and business associates "transacting in" electronic protected health information ("ePHI"). The Security Rule is, for all intents and purposes, a codified technical specification (in its broadest sense) and will require technology literate counsel to provide the necessary legal interpretation and to assist other stakeholders in practical implementations.
The legal team (i.e. more than likely a combination of inside/outside counsel) will also be heavily involved in drafting/monitoring business associate contracts as per the HITECH requirements. With HITECH's potential to significantly increase the "number of cooks in the compliance condition" the legal team should not underestimate the business associate related burden. Furthermore, legal must play a guidance and oversight role in all the other frameworks.
Our HITECH framework, while broad in
scope, does not attempt an all things to all providers approach. To get a an
overview of HITECH and Meaningful Use click on our recent slides
from the World Health Care Congress Leadership Summit on HITECH and
HIPAA Compliance.
What we propose to do in this framework
is to focus on HITECH's core themes, with meaningful use being
one example. This framework attempts to provide a broad and deep fundamental
understanding of the Act, without (hopefully) losing sight of the forest for
the trees. In short, many of the other frameworks could be entirely subsumed
within this one, but we have purposely decided
to break what we believe to be the mission critical components of the Act (and
its impact) into separate discrete frameworks that are more
readily understood as a coherent subset, and therefore more readily actionable
from an implementation perspective.
Therefore, the intent of the framework is to set the stage for all the others. It could have been listed first but then we do not really believe in linearity as a methodology for solving wicked problems. At some point however, all stakeholders will benefit from seeing the problem space at 100K feet. This is the framework that does that. The reality is that providers will select any number of starting points before realizing that a big picture view is necessary.
The Breach Notification Framework
The breach notification framework should be one that becomes near and dear to the heart of covered entities and business associates. It should be noted that the breach notification requirements are only triggered when unsecured PHI has been compromised in a manner not allowed for under HITECH. The notification requirements are controlled by Section 13402 and by the recent guidance provided by HHS in this PDF. HHS' Interim Final Rule on breach notification went into effect on September 23, 2009. The newly added regulations (i.e. CFR 164 Subpart D) can be found here.
We advise clients that they should assume that a breach of unsecured PHI will occur and prepare accordingly. There is simply too much PHI that will continue to exist in a form (i.e. unencrypted and not disposed of properly) to allow the HITECH safe harbor (generally available if PHI is in a form that is unusable, unreadable or indecipherable) to be universally applicable. The breach notification requirements are highly technical, triggered under certain conditions, and controlled via stringent timeframes. This framework will develop a set of tools that will allow an organization to be rapid response ready.
The HIPAA Security Rule Framework
The security rule ("SR") framework is all about risk management. The foundational components of this frameworks is what we have been exploring during the last two issues of the newsletter. In terms of actual regulatory text the SR only spans approximately eight (8 ) pages, which is the good news. The bad news is the SR is highly technical in nature. For all intents and purposes this rule is the codification of certain information technology standards and best practices.
Covered entities and business associates "transacting in" ePHI are required to implement the SR. These requirements have implications both inside and outside the organization. A covered entity ("CE") is required to monitor a business associate ("BA") for a material breach of the SR and vice versa. Given HITECH's propensity to significantly increase the number of cooks in the compliance kitchen, this requirement of reciprocal monitoring is daunting, in and of itself. Our SR framework focuses on attacking the low hanging fruit and laying a strong foundation for subsequent iterations.
The HIPAA Privacy Rule Framework
The privacy rule ("PR") framework deals with permissible uses and disclosures of PHI. When providers think of HIPAA what they almost always have had in mind in the past is the PR. The PR is contained in Subpart E (Privacy of Individually Identifiable Information) of CFR §164. Subpart E extends from §164.500 through §164.534. These sections span approximately 40 pages of regulatory text. The effective compliance date of the PR was April 14, 2003. Therefore, providers have been "living" with the PR for about six (6) years.
Despite the fact that the PR has been around for six years, we find that it is still often not well understood. The reason for this appears quite clear, many providers have simply ignored HIPAA in the past, due to its lax enforcement. However, as we have consistently argued in the newsletter (and elsewhere) there is a new sheriff in town, and she's not quite as nice as the old one. This has less to do with which party is currently in power and everything to do with globalization. Just as securing online banking transactions is a business requirement (i.e. politically agnostic) for the financial sector, the same holds true for securing PHI within the health care industry. The marketplace simply will no longer tolerate lax enforcement. This framework provides a cost effective way for covered entities (and now via contract, business associates) to ensure PR compliance.
The audit framework prepares covered entities and business associates for external audits by proposing that organizations adopt their own internal audits. Section 13411 of the HITECH Act's Subtitle D requires that HHS conduct mandatory audits (emphasis added). Now that tax payer dollars are at risk vis-a-vis the inappropriate payment of EHR incentives for non-compliant covered entities, you can rest assured that HHS will be active in its enforcement, despite the fact that a precise audit mechanism has yet to be worked out. Many of the critical requirements of both the PR and the SR have systemic self-monitoring steps built in.
In short, the rules themselves mandate a self-audit requirement, although they do not come out an say that in so many words. This makes sense since it is quite clear that as a general compliance principle you can't manage what you don't measure. If you choose not to implement a self-audit program then you are increasing the odds that you will likely be found in the "no story willful neglect zone." This is not a place your organization wants to find itself in, the reputation damage is likely to far exceed the stiff compliance penalties (i.e. bad news travels fast on the Internet and patients are paying attention). Furthermore, a quality self audit program involves people, process and platform and cannot be achieved without focusing on all three. Our audit framework focuses on preparing your organization for external audits by helping you implement the necessary self-audit best practices mandated by the rules using a cost effective iterative approach. Simply put, our audit framework helps ensure that your organization has the visible, demonstrable evidence required to avoid a finding of willful neglect.
The technology framework is a recognition that without the use of enabling technologies it will simply be next to impossible to build a good compliance story. This goes much further than the technology required for an EHR Implementation. It may include encryption technologies of various kinds, authentication and authorization technologies (sometimes called identity management technologies), messaging and collaboration technologies, disaster recovery technologies, and so forth.
All of these technologies have
compliance "touch points" that require implementation of various
aspects of the statutes and regulations. These touch points should be addressed
upfront as part of the planning and implementation process and not in hindsight
as an after thought. Our technology framework
reviews these touch points and ensures that the touch points have been
adequately addressed from a regulatory perspective.
