| 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.
#10: Emergency Mode Operations (October
12, 2004)
Covered Entities must develop a plan to ensure that critical
business processes for the protection of electronic health
information continue while the Covered Entity is operating
in emergency mode. The "emergency mode operations"
plan is the third required component of the "contingency
plan" standard and is mandatory for all covered entities.
(See related Tip#8: Data Backup and #9 Disaster Recovery.)
"Emergency mode operations" is the period between
recovery (the onset of restoration activity) and reconstitution
(when the emergency has abated and system functions return
to normal). The emergency mode operations plan requires
Covered Entities to imagine how operations might be carried
out in the event of certain disasters, and then devise effective
security rules to protect electronic health information
during those operations.
Although good business practice suggests a plan for the
continuation of all critical business operations, the HIPAA
emergency mode operations plan requirement concerns itself
only with those that relate to the protection of electronic
health information. This requirement reflects a policy decision
that the security of electronic patient health information
must not be compromised even under the direst of circumstances.
Covered Entities should not confuse the security contingency
plan requirement with the "contingency plan" related
to electronic transactions. That plan was limited to the
narrow scenario of a disruption in operations due to failure
to comply with the transactional standards, the deadline
for which was October 16, 2003. The security contingency
plan should cover a much broader array of potential disruptions.
#9:
Disaster Recovery (October
5, 2004)
HIPAA requires covered entities to establish procedures
for recovering data lost in catastrophic events such as
fire, vandalism, or natural disasters like floods and hurricanes.
Disaster recovery is another required component of the "contingency
plan" standard, which is a mandatory standard for all
covered entities. (See related Tip#8: Data Backup.)
The structure of each covered entity's disaster recovery
plan will be driven mostly by its tolerance (or lack of
tolerance) for unavailability of the system. The size of
the organization is not necessarily a determining factor.
A small office serving a highly critical function (for example,
a dispatching call center) may need aggressive backup schedules
and system redundancies to avoid even minute disruptions
in service, while a larger division with more system resources
may be able to tolerate a down period of multiple days or
even weeks.
The disaster recovery plan should proceed in a logical and
sequential fashion. In the restoration of a network, for
example, network servers should be restored first before
turning efforts to workstations and peripherals such as
printers and scanners. But don't count on your technology
experts to know whether the printers in claims processing
are more important than the databases in QI. With complex
systems, appropriately prioritizing the steps of the disaster
recovery plan will require close coordination between operations
and IT managers.
#8:
Data Backup and Storage (September 28, 2004)
Data backup requirements appear in two places in the HIPAA
security rule. One instance occurs in the "media controls"
standard, and requires a plan for backing up health information
data before moving computer equipment on which the data
reside (such as during an office renovation or relocation).
That requirement is "addressable," which means
the Covered Entity must implement the standard unless it
is inappropriate or unreasonable and cannot be met through
an alternative measure.
The second instance is within the "contingency plan"
standard, and unlike the media controls/data backup standard,
this one is mandatory. All Covered Entities must establish
procedures to create and maintain retrievable exact copies
of electronic health information stored on their computer
systems.
A range of options are available to back up data, ranging
from copying files to diskettes to uploading files--via
the internet--to an offsite/online storage provider. The
most appropriate choice will depend both on budgetary limitations
and an assessment of the potential risks and vulnerabilities
associated with loss of the data. Having no backup and recovery
plan, however, is not an option.
Covered Entities should also consider the need to backup
the software necessary to read the data. Backed up data
must be "retrievable," and that standard is arguably
not met if there is no software on hand to make sense of
the data. This is more likely to be the case when the necessary
software is proprietary and/or not widely or readily available.
#7:
Data Integrity (September 21, 2004)
Covered entities must implement policies and procedures
to protect the "integrity" of electronic protected
health information. At first glance this standard may seem
prohibitively vague. Within the context of HIPAA security,
however, "integrity" has the fairly narrow and
specific meaning that data has not been altered or destroyed
in an unauthorized manner. This meaning is consistent with
generally accepted principles of information security.
Covered entities should consider data integrity in two modes:
data residing on the system (or at rest) and data in transmission.
Protecting the data in both modes requires separate analyses
of risks and vulnerabilities. Data residing on the system
may be safeguarded by appropriate access controls and the
use of an off-the-shelf data integrity checker. Data in
transmission may require encryption or error-checking technology
to prevent unauthorized alteration or destruction during
transfer.
The data integrity standard is "addressable,"
which means that covered entities must implement the standard
unless it is inappropriate or unreasonable and cannot be
met through an alternative measure. Off-the-shelf and shareware
products containing integrity controls are widely available,
however, making this standard achievable even for single-computer
healthcare providers.
#6:
Security Incidents (September 14, 2004)
The HIPAA security standards require covered entities to
implement policies and procedures addressing "security
incidents." A security incident is the attempted or
successful access, use, disclosure, modification, or destruction
of information on a system without appropriate authorization.
An incident need not involve "protected health information"
(PHI) to qualify as a security incident. Denial of service
attacks, worm and virus infections, and unsuccessful efforts
to bypass security controls are all security incidents regardless
of whether they damage or destroy PHI.
The implementation specification for the security incident
standard touches on three main points: identification and
response to the security incident; mitigation of harmful
effects; and documentation of security incidents and their
outcomes.
To capitalize on the occurrence of security incidents, incorporate
post-incident review and analysis into the response. Study
previous incidents internally to improve security controls
and practices. In larger organizations, incidents and incident
response can be tracked and trended; information thus obtained
can be folded back into the overall risk assessment, improving
the selection and implementation of additional controls.
Healthcare organizations are already familiar with such
a process - - borrow a page from the QI committee to structure
post-incident evaluation, or consider incorporating security
incident reviews into established QI processes.
#5:
Password Management (September 7, 2004)
Covered entities must implement procedures for creating,
changing, and safeguarding user passwords. Password management
is an "addressable" requirement, which means the
Covered Entity must implement the standard unless it is
inappropriate or unreasonable and cannot be met through
an alternative measure. For all but the smallest health
care providers, password management is a reasonable standard
and must be implemented. Password management is part of
the "administrative safeguards" required by HIPAA.
Passwords are generally the least expensive authentication
technique but are also the most vulnerable. People tend
to choose passwords that are "easy to remember"
- - which is only a step away from "easy to guess."
Random password generation produces better passwords, but
tends to result in forgotten passwords or - - worse - -
passwords written on post-its stuck next to the computer.
Passwords are also generally easy to circumvent.
Covered entities should minimize reliance on passwords to
the extent possible. When passwords are unavoidable, establish
basic rules for creating and using passwords touching on
topics such as required attributes (minimum length, mix
of characters and numbers, avoiding recognizable words),
frequency of changing passwords, and the do's and don't's
of password protection (no post-its next to the computer).
#4:
Automatic Logoff (August 31, 2004)
Covered Entities must implement electronic procedures that
terminate an electronic session after a predetermined period
of inactivity - - known as an "automatic logoff."
Automatic logoff is an "addressable" requirement,
which means the Covered Entity must implement the standard
unless it is inappropriate or unreasonable and cannot be
met through an alternative measure. For all but the smallest
health care providers, an automatic logoff standard is reasonable
and must be implemented. This standard is part of the "technical
safeguards" required by HIPAA.
The amount of time that should trigger an automatic logoff
will vary widely depending on a number of circumstances.
Access points located in public or semi-public areas may
require stricter timeframes, while terminals in private
offices may need less restrictive timeframes. Administrators
should also consider the sensitivity of the data protected
by the logoff process in relation to the anticipated inconvenience
to the user of relogging in after short periods of inactivity.
Consider combining the logoff process with a half-step such
as a locked screen saver. A terminal accessed periodically
but on a time sensitive basis (such as one located in an
emergency department) might benefit from a screen saver
that locks after two minutes but does not logoff fully until
thirty minutes of inactivity have elapsed. A nurse returning
to the terminal after a brief period could pick up where
he or she left off by entering a password, while unusually
long periods would require reauthentication through the
full login process.
#3:
Login Monitoring - Network Security (August 24, 2004)
HIPAA requires Covered Entities to implement procedures
for monitoring network log-ins and reporting discrepancies
for review. One example of a discrepancy is a high number
of failed log-in attempts in a short period of time, which
can signal an attempt to hack into a system. These events
are easy to monitor using automated software or custom scripts,
or by manually reviewing system event logs (if the network
is small).
Discrepancies may be lurking in successful logins as well,
and these are more difficult to spot. Employee Jones' login
on a Wednesday may not be unusual unless you knew that Jones
was out of the office that week. Successful logins are harder
to monitor because the required information - - in this
example, Jones' vacation - - may not even be on the system.
One approach to monitoring successful logins is to have
employees validate their previous login each time they log
on. This approach uses the best available information -
- the employee - - to validate the prior login. It also
partially automates the process, and provides effective
oversight without increasing the burden on administrative
staff. It might be possible to link network event logs with
employee calendars, schedules, and sign-in sheets, but fully
automated monitoring will always be limited by the quality
and completeness of information residing on the system.
#2:
Termination Procedures (August 17, 2004)
Covered Entities must implement procedures for terminating
access to protected health information when the employment
of a workforce member ends. This is an "addressable"
requirement, which means the Covered Entity must implement
it unless it is an inappropriate or unreasonable standard
and cannot be met through an alternative measure. For all
but the smallest health care providers, the termination
procedures standard is reasonable and must be implemented.
Keep in mind that "workforce" under HIPAA is much
broader than the traditional notion of "employees."
Besides employees, workforce include volunteers, trainees
and other individuals under the direct control of the Covered
Entity - - regardless of whether the Covered Entity pays
them. For example, a temp employed by the temp agency but
under control of the Covered Entity is part of the workforce
and their departure must be handled like the departure of
any other employee.
Covered entities should examine their existing termination
procedures to ensure that all aspects of PHI access are
addressed. Consider developing a comprehensive checklist
of items that must be completed whenever someone leaves
the "workforce" - - including volunteers and long-term
consultants that might not be thought of as employees. All
login IDs should be disabled, keys and access cards returned,
passwords changed as needed. The timeframes for completing
these tasks may be different when employees are terminated
involuntarily.
#1:
Security Officer (August 10, 2004)
To comply with the HIPAA security standards, each Covered
Entity must identify a "security official" responsible
for developing and implementing HIPAA security policies.
A Covered Entity under HIPAA is any health care provider,
health plan, or health care clearinghouse engaged in electronic
transactions involving protected health information. Virtually
all health care providers are Covered Entities.
The security official will need a good working knowledge
of the HIPAA security standards and how your organization
will implement them. Identifying the security official early
on and involving that person directly in the implementation
process is an easy and effective way to build that working
knowledge.
The privacy standards required the designation of a privacy
official, and it may be a good fit to have the same individual
serving as both the privacy and security official. Keep
in mind, however, that the security standards are primarily
about the physical and technical security of electronic
records. A security official may need more technical knowledge
than a privacy officer to effectively perform the job. If
your privacy officer doesn't have a strong IT background,
consider keeping the roles separate.
To
Top |
