HIPS Series > Overview of Federal and State Data Security Requirements

How to take this course

Most of the training to meet that requirement involves giving practical advice for workers' routine activities -- safety while emailing and Web surfing, protection against malicious software, etc.  That's the reason we cover those topics in the security series courses.

For a few members of the workforce -- such as persons in the compliance or information security department -- it is also helpful to be familiar with the details of legal-regulatory requirements for data security.  That's what this particular course provides. This course is not recommended for -- or generally needed by -- the average user of health information.

Note that this course does not discuss information security requirements of private certification organizations, like JCAHO and NCQA, which are similar in intent, if not in the specifics.

As discussed in detail in the privacy series, a federal floor of data protection requirements is added to existing state laws by HIPAA.  Its new regulations also overlay (but do not replace) those of private certification organizations.

HIPAA's health data regulations are divided into four "Standards" or "Rules" -- for Privacy, Security, Identifiers, and Transactions/Code Sets.

We will summarize the HIPAA Security Rule in this course.  Within the paragraphs, hyperlinks will take you to much more detailed explanations of each component of that Rule.

HIPAA's Privacy Rule applies to protected health information (PHI) in "any form or medium."  By contrast, the Security Rule covers only PHI that is electronically stored or transmitted.

(For a tour of the Privacy Rule, see the Overview of Federal and State Privacy Requirements course.  It gives more background on HIPAA terminology like PHI.)

The Security Rule’s "electronic focus" is true of HIPAA’s Identifier and Transactions/Code Set rules as well.  However, the US Department of Health and Human Services (DHHS), which enforces HIPAA, has indicated it may establish standards to secure health information in non-electronic media in a future rule.

While the "electronic focus" makes it narrower in one important respect, HIPAA’s Security Rule has in other ways a much broader aim than the confidentiality focus of the Privacy Rule.

Although protection against unauthorized use or disclosure remains a core goal here, the Security Rule also aims at assuring the integrity and availability of electronic PHI.

Accordingly, the Security Rule requires that issues such as data backup, disaster recovery and emergency operations be part of the safeguards of a covered entity.

The HIPAA Security Rule's requirements are divided into three "safeguard" categories:

• administrative safeguards such as policies, procedures and organizational structures;
   
• physical safeguards for the buildings and equipment in which health information is used and stored; and
   
• technical safeguards for the computer hardware and software that stores and processes health information.

These three are further divided into "standards" and "implementation specifications" that itemize the required and optional (a.k.a., "addressable") components of each safeguard:

You can get detailed information about each of these by clicking on the links in the table.

5. Reasonable, appropriate effort

The general requirement of the HIPAA Security Rule can be simply stated, if not simply achieved:

Covered entities that "collect, maintain, use or transmit" protected health information (PHI) in electronic form must construct "reasonable and appropriate" administrative, physical and technical safeguards that ensure confidentiality, integrity and availability of that PHI.

Such measures -- which are built around and documented within a comprehensive set of security policies and procedures -- must provide protection against "any reasonably anticipated threats or hazards."  Such "reasonable anticipation," in turn, requires a thorough security self-assessment and strategy.

Construction of reasonable-and-appropriate administrative, physical and technical safeguards can be described as including three major steps for a covered entity:

• "assess potential risks and vulnerabilities" to electronic PHI that it maintains or transmits;
   
• "develop, implement and maintain appropriate security measures" given those anticipated risks; and
   
• document those security measures and keep them current.

Safeguards must also "ensure compliance" with policies and procedures by the covered entity's workforce.  Hence the Security Rule, like the Privacy Rule, has a training requirement.

DHHS has stated that it believes that the mandated security standards fulfill three -- yes, another threesome -- concepts derived from the administrative simplification provisions of HIPAA.  Specifically, the Security Rule requirements are:

• "comprehensive and coordinated," so as to address all aspects of security;
   
• "scalable," and so suitable for covered entities of any size or type, from small practices to large hospitals; and
   
• "technology neutral," to allow for changes as security technologies evolve (i.e., as the cost-effectiveness of particular devices and methods shift).

What is reasonable and appropriate to meet a given set of anticipated risks will change over time, given changes in technologies. 

Risk pattern shifts can be expected to alter what is "suitable" as well. 

And, at any given time, what is reasonable and appropriate will also depend on the size and type of covered entity.  What makes sense for a large health care organization will not fit the needs (or budget) of a small one.

In DHHS' words: "[E]ntities affected by this regulation are so varied in terms of installed technology, size, resources, and relative risk, that it would be impossible to dictate a specific solution or set of solutions that would be usable by all...." (DHHS Final Security Rule commentary, p.11)

What does all that mean in practice? 

Unfortunately, it means that each covered entity must continually evaluate its suite of security provisions against evolving technological capabilities and costs as well as in relation to shifting risks. 

A covered entity must also measure its compliance against the evolving "community standard" set by security provisions at similarly situated health care facilities.  And it must do these assessments systematically, since a security regime only works as well as its weakest parts.

"Reasonableness" and "appropriateness" do not yield once-and-for-all recipes for security that can be applied in cookie-cutter fashion.

What is the standard for how individual security requirements are to be satisfied and which technologies to use?  These are "business decisions that each entity [has] to make ... reviewing and modifying the measures as needed to continue the provision of reasonable and appropriate protections." (DHHS Final Security Rule commentary, p.46, 49)

Does that mean a covered entity can do anything it wants for security, as long as there is a "business justification"? 

No!  What is done -- or, equally critically, not done -- must meet the ever-present standard of "reasonableness and appropriateness" to the satisfaction of DHHS. (If things go quite badly, it may also need to satisfy a judge or jury too.)

While many organizations have proposed elements of a security model, DHHS has stated that it believes the HIPAA Security Rule establishes the only "comprehensive, scalable, and technology-neutral standard" to safeguard electronically maintained or transmitted information. (Final Security Rule commentary, p.45) 

DHHS has promised to issue guidance documents in future, to clarify further the various elements of the Rule.  However, there is relatively little in the way of specifics so far.

In the meantime, covered entities may also rely on the security models and standards of organizations such as ISO, JCAHO, NIST and WEDI for additional guidance about reasonableness and appropriateness.

As with the HIPAA Privacy Rule, the HIPAA Security Rule establishes only a national minimum standard for security of electronic health information.  Covered entities may for various reasons need or want to exceed that minimum.

A state health data protection law remains in force unless it is in conflict, and it may establish a higher benchmark.  So it is always critical to understand what, if anything, the statutes and regulations in your jurisdiction require.  (See next section.)

Private certification organizations' requirements must still be met as well, and these may require stricter information security practices than do federal standards. 

Finally, one's own notions of business necessity may dictate greater protection of the organization's information resources than any of these public or privacy requirements.

We have said very little about state-level health information security requirements thus far, for good reason.  Most states' statutes and regulations do not offer much in the way of detailed guidance.

For example, Florida's statutes require medical records holders to "adopt policies and procedures to ensure the confidentiality and security of medical records consistent with state law."  And, like HIPAA, Florida mandates education: "Employees of records owners shall be trained in these policies, standards, and procedures."  But that's it.

It's a reasonable assumption in most jurisdictions is that meeting HIPAA's security standards will more than suffice for the "local" ones.  Only a few states (like California) have strong enough data protection statutes to exceed the federal requirements, at least potentially.

We began the course by noting that HIPAA’s security regulations also overlay (but do not replace) those of private certification organizations. 

Entities such as JCAHO have long had requirements for information protection; in recent years, those provisions have become more detailed and, arguably, more strict. 

Covered entities must still meet such requirements to be certified, but that may be easy to do if they are already fulfilling all of HIPAA’s requirements.

Unlike HIPAA, most states' statutes make no strong distinction between protections for electronic vs. non-electronic health information.  Neither do private certification requirements.  Indeed, HIPAA's own Privacy Rule makes no such distinction.

Many organizations have obsessed on protections for "ePHI" and given security for non-electronic PHI relatively short shrift.  We believe this to be wrong both legally and ethically.  You really aren't allowed to given non-electronic records a lesser degree of protection.

Covered entities that have already addressed security in a systematic way may find that HIPAA does not require a lot of new work. 

By contrast, the less prepared will probably have a "to do" list that will require many years' work to clear.  The Security Rule, like the Privacy Rule, owes its existence in large part to the perception that state-level and private requirements have not been sufficient motivation for many organizations.

What does it mean for you?  If you have been designated as a HIPAA-required security official for your organization, you will need to understand the Rule in detail.  Otherwise, it is probably more useful to spend your time on security courses that focus on the details of safe practices.  One truth hasn’t changed: Security depends on good individual security behavior.

The good news is that the HIPAA Security Rule is logically structured, and relatively compact, given its goal of generating a complete framework for health information security.

The bad news is that the Rule only sets a general structure.  It is up to each entity to determine the details of (to use those two favorite adjectives) "reasonable and appropriate" arrangements. 

That means that organizations must continually look outward at the practices of similar entities, as well as consult the evolving standards and recommendations of professional organizations. Both for the organization and for the individuals that make up its workforce, security is a process that never ends.

•  •  •  •  •

Help us make this course better -- take the online course evaluation. The quiz for this course is here.

•  •  •  •  •