| HIPAA
SECURITY TIPS
Many health care providers are familiar with the privacy
standards under HIPAA, which took effect in April of 2003.
The next major component of HIPAA that must be implemented
is the "security" standards. The security standards
address administrative, physical, and technical safeguards
Covered Entities must put into place to protect patient
health information. They go a step beyond the privacy standards
and get to the actual nuts and bolts of protecting patient
health information.
To assist our health care clients and friends in their implementation
efforts, we recently launched HIPAA Security Tips, a weekly
series of helpful implementation how-to's that will be delivered
free by e-mail. Each tip will cover a specific topic of
a required HIPAA security policy. We'll touch on a different
policy each week right up to the compliance deadline of
April 20, 2005. The following tips are in chronological
order, with the most recent tip first.
HIPAA Security Tips are free and available to anyone.
To subscribe,
send an e-mail to hipaa@icrh.com
with "Subscribe" in the subject line.
#30:
Security Reminders (March 11, 2005)
Covered entities must consider "security reminders"
as part of their security awareness and training programs
under the final HIPAA security rule. (See Tip #29 for more
on security awareness and training programs.) The final
rule provides that a "security reminder" includes
"periodic security updates" but provides no further
guidance on how to meet this requirement.
The security reminder specification is "addressable,"
which means that the covered entity must implement the specification
unless doing so would be inappropriate or unreasonable and
the purpose of the standard cannot be met through a reasonable
alternative measure. It is difficult to imagine how issuing
periodic security updates could be an inappropriate or unreasonable
measure except in the smallest of organizations.
Covered entities should take an expansive view of reminders
and use multiple media and multiple venues to create a "culture"
of security awareness. For example, show users a "security
tip of the day" at the time of logon, or when they
access the organization's intranet. Insert a "Security
Awareness" column in monthly or quarterly newsletters.
Notify users of security incidents by broadcast e-mail,
including an explanation of the remedial actions that have
been taken to prevent a repeat incident. Post interesting
articles on computer security in the mailroom or cafeteria/breakroom.
None of these approaches are particularly time consuming,
and used together can communicate strongly to IS users the
importance of good security practices.
Do not confuse "periodic security updates" in
relation to security and awareness training with "periodic
security updates" in relation to software patches and
revisions. Keeping software current is critical to an effective
security program, but that is not the purpose of the security
reminder specification.
#29:
Security Awareness and Training (March 4, 2005)
The final HIPAA Security Rule includes a "security
awareness and training" standard requiring covered
entities to train all personnel, including management, on
security topics and policies. The training requirement applies
regardless of the size of the organization.
Training must be given to all individuals with access to
electronic Protected Health Information, even, for example,
per diems and temporary employees. Keep in mind, however,
that training for any given employee is only required
as is reasonable and appropriate for the employee to carry
out his or her job function. Consider a segmented or modular
training program with different components required "as
needed" for the job function. This will also provide
a ready means for additional training when employees change
job functions, and/or targeted remedial training as necessary.
Remember that the Security Rule requires training to be
completed by April 21, 2005. If a covered entity has merely
developed a training program by that date, but has not yet
conducted the training, the covered entity is not in compliance
with the rule.
#28:
Applications and Data Criticality Analysis (February 25,
2005)
The Security Rule requires covered entities to assess the
"criticality" of specific "applications and
data" in support of its other contingency plan components.
This is an addressable requirement under the contingency
plan standard. (See Tips 8, 9 and 10 for more information
on contingency plans.) Covered entities must perform this
assessment unless doing so would be inappropriate or unreasonable
and the purpose of the standard cannot be met through a
reasonable alternative measure.
Criticality refers simply to the importance of the application
(program) or data (information) to the covered entity's
specific business functions. One result of an applications
and data criticality analysis is a prioritized list of programs
and information to be recovered or restored in the event
of system failure.
The importance of different programs and information will
vary widely from covered entity to covered entity depending
on many different circumstances. In a multi-facility medical
group practice, for example, the availability of scheduling
information and electronic medical records may be of highest
priority so that if one facility is damaged patients may
be easily rescheduled and seen at other locations. In a
small group or solo office that keeps health records primarily
on paper, electronic billing information may be the most
important information to recover, since it will provide
necessary cash flow during restoration. An ambulance provider
would have little immediate need for past medical records,
but would have a great need for information and computer
programs supporting scheduling and dispatching.
Keep in mind that "criticality" is a function
of time. Electronic medical records, for example, are very
important in short to mid-term timeframes. Once applicable
records retention requirements have been met, however, such
records quickly lose their importance. Data criticality
analysis should take data aging into consideration when
prioritizing recovery and restoration efforts.
#27:
Unique User Identification (February 18, 2005)
Covered Entities must implement a "unique user identification"
standard for use of the Covered Entities' information systems.
Unique user identification is a "required" specification
under the Access Control standard and must be implemented
by all Covered Entities.
As the name implies, unique user identification refers to
the use of a unique name or number to identify and track
specific individuals using the information system. Use of
a unique name or number is an aid in verifying the identity
of the person using the system. An effective unique user
identification policy will ensure that system activity can
be traced to a specific individual.
Policies concerning unique user identification should not
overlook ongoing maintenance of user identification data.
User identifications that do not correlate with active workforce
members (such as those of former employees) present an increased
risk for abuse. Consider setting automated system monitors
to disable user identifications that remain inactive for
certain periods of time (30 days, for example). The policies
may also address temporary disabling for employees leaving
the office for extended periods, such as medical/family
leave or vacations.
#26:
Security Incident Response and Reporting (February 14, 2005)
Covered entities must implement policies and procedures
to address security incident response and reporting. (See
Tip #6 for a general discussion of security incidents.)
Security incident response and reporting is a "required"
specification and includes the obligation to (1) identify
and respond to known and suspected security incidents, (2)
mitigate the harmful effects of security incidents, and
(3) document security incidents and their outcomes.
Security incident response and reporting policies should
require immediate reporting of security incidents to the
Security Officer (or a designee for reporting purposes).
Because they require specific actions under important circumstances,
reporting policies should be clear and simple and easy to
remember, with multiple methods for reporting. A clear definition
of "security incident" is essential to avoid both
over- and under-reporting by employees. Avoid the temptation
to front-load the investigation process by requiring lengthy
forms and processes, which will deter reporting in the first
place.
The Security Rule does not specifically require reporting
of security incidents to outside entities. Depending on
the incident, however, such a requirement may be imposed
by other Federal laws, state law, or contractual obligations
with other entities (particularly if your entity is a business
associate of another covered entity). Security incident
reporting procedures should include procedures for determining
when reports to outside entities are desirable or required
and should dovetail with existing mandatory reporting policies.
#25:
Business Associates (February 4, 2005)
In the HIPAA Privacy implementation effort, compliance with
the business associate* requirements was by far and away
the most significant hurdle for Covered Entities to get
over. Some Covered Entities, in fact, have yet to attain
compliance despite the two years that have passed since
the Privacy Rule took effect.
Fortunately, the Security Rule requirements for business
associates are not particularly complex. They essentially
involve adding four specific paragraphs to existing business
associate contracts, which can usually be accomplished in
a simple addendum or amendment.
Covered Entities may take advantage of this opportunity
to revisit business associate arrangements by (1) renegotiating
terms of existing business associate contracts which are
not advantageous to the Covered Entity; and (2) more importantly,
finalizing business associate relationships with those entities
that balked at recognizing their business associate status
on the first go-round.
Many Covered Entities have been content to allow business
associates to continue providing services without insisting
on compliance with HIPAA business associate standards (i.e.
signing a business associate agreement). Such a practice
is doubly dangerous. Turning a blind eye not only exposes
the Covered Entity to regulatory violations in its own right,
it may also make the Covered Entity responsible for violations
committed by an errant business associate.
* A business associate is a person or organization that
performs or assists with a function, for or on behalf of
a covered entity, involving the use or disclosure of individually
identifiable health information.
#24:
Documentation (January 28, 2005)
Like the Privacy Rule, the Security Rule requires covered
entities to maintain documentation of the policies and procedures
implementing the requirements of the rule. Documentation
may be maintained in written or electronic form and must
be retained for six years from the date of creation or the
date it was last in effect, whichever is later. Covered
entities must also maintain a written record of all actions,
activities or assessments specifically required by the Security
Rule to be documented.
Unlike
the Privacy Rule, which requires entities to review their
policies and procedures whenever there is a change in law,
the Security Rule places an affirmative obligation on entities
to review documentation periodically and to update as needed
in response to environmental or operational changes. Thus
an office relocation, system upgrade, or departmental reorganization
may trigger a re-analysis of compliance with the security
standards, even though the standards themselves may not
have changed.
Policies and procedures must be readily available to those
responsible for implementing them. Covered entities should
take advantage of the rule's flexibility and consider a
paperless manual system for easy distribution and updating.
Paperless manuals can be accessed over the internet, intranet
or CD ROM. Note, however, that business associate agreements
can (and often do) impose the requirement to maintain written
documentation in hard copy format. These contractual obligations
are not overridden by the HIPAA regulations.
#23:
Policies and Procedures (January 21, 2005)
Covered entities of all sizes must devise and implement
"reasonable and appropriate" policies and procedures
to comply with the standards and specifications of the HIPAA
Security Rule. This requirement is flexible and scalable,
taking into consideration the wide range of facilities and
businesses covered by the rule, but is nonetheless mandatory.
The expectation is that larger and more sophisticated entities
will implement extensive and thorough policies for protecting
electronic health information and procedures enforcing the
policy. Even small entities, however, must have comprehensive
policies and procedures in place.
In determining the policy that will best protect electronic
health information, and the procedure to best implement
the policy, the Covered Entity must consider (1) the size,
complexity and capability of the entity; (2) the existing
technical infrastructure, hardware, and software security
capabilities; (3) the costs of implementing the security
measure, and (4) the probability and "criticality"
of risk to the information. (Criticality is the measure
of the impact on the organization if the information is
unavailable or is corrupted.)
Effective policies and procedures must rest upon a thorough
assessment and understanding of the Covered Entity's information
system. Before drafting policies and procedures, the organization
should inventory and document
* where it stores electronic health information;
* the sources of electronic health information; and
* who has internal and external access to the information
and why.
A careful inventory may lead to unexpected surprises. Faxing
a paper document with health information in it doesn't ordinarily
involve electronic health information---unless the fax machine
happens to capture a digital copy of the sent item. If that
happens, the Covered Entity must consider how that image
can be accessed, by whom, and how it should be protected.
#22:
Effective Use of Legal Counsel (January 14, 2005)
The HIPAA Security Rule is a Federal regulation with potentially
serious consequences for those who do not comply. The rule
also touches on a number of operational areas--such as contracts,
employment issues, incident reporting, etc.--with specific
legal implications. For these reasons, a legal counselor
is essential to any HIPAA Security compliance effort.
At the same time, even large health care organizations are
mindful of their budgetary limitations. Using a lawyer for
work that can be accomplished by consultants or in-house
staff can quickly deplete resources allocated for HIPAA
compliance.
At an absolute minimum, legal counsel should:
* review the risk analysis policy and the risk analysis
itself
* review and comment on policies and procedures regarding
- Access Termination Procedures;
- Security Incident Procedures;
- Evaluation; and
- Disposal and Data Backup and Storage
* review all business associate agreements
* review written training materials, and
* review documentation for any addressable standard or implementation
specification the Covered Entity determines NOT to implement
Ideally, legal counsel would be involved in developing and
drafting the above items as well, and would have general
input into the overall implementation process. Legal issues
have a nasty habit of popping up in unexpected places, and
a lawyer can't spot an issue without first having an opportunity
to see it.
Involve counsel early even if a limited role is envisioned.
A detailed workplan, developed in conjunction with counsel,
can help ensure that the legal bases are covered without
killing your implementation budget. Above all, select a
legal advisor with demonstrated HIPAA familiarity and enough
comfort with information technology to work effectively
with IT staff or an outside IT consultant.
#21:
Access Establishment and Modification (January 7, 2005)
"Access establishment and modification" is the
second specification under the "information access
management" standard. The first specification, access
management (see Tip #20), addresses *what* levels of access
will be provided to members of the workforce. Access establishment
and modification concerns *how* those levels of access are
provided.
This specification is technically an "addressable"
requirement. Covered entities must implement an access establishment
policy unless it is inappropriate or unreasonable and its
purpose cannot be met through a reasonable alternative measure.
Like access management, it is difficult to imagine the circumstances
that would justify avoiding this specification.
The specification, like most of the security standards,
provides little detail on the actual requirements of the
policy. Covered entities should at least ensure their policy
touches on the areas specifically mentioned in the rule:
establishment, documentation, modification, and review of
an individual's right of access to a workstation, transaction,
program, or process.
The point of access establishment is an opportune time to
introduce the covered entity's "acceptable use policy"
(AUP). AUPs are rules for use of the computer system which
typically address issues such as personal e-mailing and
web browsing, downloading software, storing music on the
system, etc. Organizations integrating the AUP into the
access establishment process, however, should ensure that
the AUP is actually read and understood by the user. If
the user's exposure to the AUP is reduced to a "Next"
or "I Agree" button in the setup process, the
AUP is likely to be ignored and, consequently, prove ineffective
as a tool for managing system use and abuse.
To
view HIPAA Tips 1-10 Click Here
To
view HIPAA Tips 11-20 Click Here
|
