| 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.
#20:
Access Authorization (December 30, 2004)
Covered entities must implement policies and procedures
for granting access to electronic protected health information.
This requirement is an addressable specification under the
"Information Access Management" standard (see
Tip #19). Covered entities must implement this requirement
unless it is an inappropriate or unreasonable requirement
and cannot be met through an alternative measure.
Access management is a fundamental tenet of information
security. In addition, as noted last week, HIPAA security
policies must be consistent with HIPAA privacy standards,
including the minimum necessary rule. Other than among the
smallest covered entities, it is difficult to envision circumstances
that would justify passing over this specification.
The access authorization specification requires covered
entities to answer the question, "What level of access
will be provided to different members of the workforce?"
Access can be tied to a number of different things - - the
user's "role" (scheduler/receptionist, transcriptionist,
administrator); the physicial point of access (a workstation
in a lab); a function (coding, billing, CQI); or a specific
person (John, Jane), among others. The final security rule
provides a great deal of flexibility to covered entities
to in defining appropriate access levels.
Covered entities using role-based access should carefully
consider the scope of their defined roles. Efficiency and
convenience suggest fewer defined roles, with broader access
rights for each role. The minimum necessary rule, in contrast,
demands that covered entities define roles as narrowly as
possible.
#19:
Information Access Management (December 23, 2004)
All Covered Entities must implement policies and procedures
for authorizing access to electronic health information
consistent with the HIPAA privacy standards. This required
standard is a crossover provision that grafts the principles
of the HIPAA privacy rule onto the security rule's architecture.
The primary influence from the privacy standards will of
course be the minimum necessary rule. Under the minimum
necessary rule, use or disclosure of protected health information
(other than for treatment purposes) is limited to the minimum
information necessary to accomplish the purpose for which
the disclosure is made.
In the Security realm, the minimum necessary rule plays
out in two ways. Covered Entities must limit access to electronic
health information to those individuals who need access
to carry out their job functions. At the same time, Covered
Entities must limit the information available to the minimum
amount necessary for accomplishing that specific function.
In other words, the minimum necessary individuals have access
to the minimum necessary information to do their jobs.
Mid-size organizations will have the most difficulty with
this standard. Smaller organizations will find it easier
to avoid a complex access scheme due to overlapping job
duties. Larger organizations will be more likely to have
naturally segregated access rights at the same time they
segemented their business functions. Nevertheless, both
small and large Covered Entities should approach information
access management as if for the first time, and should not
rely on existing access practices simply because they are
already in place. It is probable, if not a certainty, that
existing access rights are more generous than the minimum
necessary rule would permit.
#18:
Encryption - Part II (December 17, 2004)
Last week's tip dealt with encryption of data "at rest."
A separate standard in the HIPAA Security Rules requires
covered entities to consider encryption of data in transmission
as well.
The transmission encryption requirement is part of the transmission
security standard and is "addressable." Covered
entities must implement the requirement unless they have
determined that it would be unreasonable to do so and that
the standard cannot reasonably be met through an alternative
method or technology.
As with most of the standards, proper implementation will
require a thorough understanding of the data flows into,
out of, and within the covered entity. A single covered
entity with multiple facilities may, for example, require
encryption if the facilities are linked using a public infrastructure.
The nature of encryption requires cooperation between the
sending and receiving entities. Covered entities transmitting
health information to third parties should reduce that cooperation
to writing to ensure that the obligations of both parties
to protect the data are clear.
#17: Encryption - Part I (December
10, 2004)
One of the most commonly asked questions is whether the
HIPAA Security Rules "require" encryption of electronic
health information. The stock answer is no; a better answer
may be "not exactly."
The final Security Rule requires Covered Entities to "implement
a mechanism to encrypt and decrypt electronic health information"
stored (at rest) on the system. (A separate requirement,
which will be discussed next week, relates to information
"in transit.") This encryption specification is
an "addressable" component of the access control
standard, and must be implemented *unless* doing so would
be inappropriate or unreasonable and the effect of implementation
cannot reasonably be achieved through an alternative measure.
Covered entities must understand encryption before deciding
not to employ it. An appropriate determination of whether
to use encryption must consider the "likely contribution"
of encryption to protecting electronic health information.
It is impossible to assess the likely contribution without
understanding the technology itself. For a decent primer
on encryption, see http://download.pgp.com/pdfs/whitepapers/PGP-Ex_Brief_Encryption_Primer_041130_F.pdf
Covered entities should also consider that encryption, in
addition to being a formidable access control, can operate
as an effective method for authentication and integrity
verification as well. This could be a benefit to smaller
organizations looking to cover a few bases with just one
solution.
(Please note - PGP is an encryption vendor. The white paper
link is provided for educational purposes only. We have
no affiliation with PGP and are not recommending or endorsing
their products by including this link. Viewers will need
Acrobat Reader to view the white paper.)
#16:
Workstation Use (December 3, 2004)
Covered Entities must develop
and implement policies concerning use of workstations that
can access electronic health information. The policies must
specify:
* the proper functions to be performed at each workstation
* the manner in which those functions are to be performed
* the physical attributes of the surroundings of a specific
workstation or class of workstations
Workstation use policies are required under the HIPAA Security
Rule and must be implemented by all covered entities.
Covered Entities should pay particular attention to how
"workstation" is defined and used in their policies.
Workstation is defined in the Security Rule as "an
electronic computing device, for example, a laptop or desktop
computer, or any other device that performs similar functions,
and electronic media stored in its immediate environment."
Current guidance from the National Institution of Standards
and Technology suggests that this definition includes dumb
terminals, PDAs, and other wireless devices. These may or
may not occur to an administrator as "workstations"
at first blush.
Commentary to the final Security Rule indicates that the
workstation definition was derived from currently accepted
definitions in industry publications such as ISO 7498-2
and ASTM E1762-95. While the industry generally tends to
distinguish between "workstations" and other types
of devices based on factors such as local computing power
and storage capacity and the ability to operate independent
of a network, Covered Entities may fare better by simply
determining whether the device permits user access to electronic
health information. If so, it should probably be covered
by the entity's workstation use policy regardless of whether
it's a genuine "workstation."
#15:
Required v. Addressable (November 24, 2004)
HIPAA Security Standards and related implementation specifications
are of two types: "required" and "addressable."
A handy chart of all the standards and their designation
as required or addressable was published as "Appendix
A" to the final Security Rule. (A link to the rule
on CMS's website appears at the end of this tip.)
Addressable does not mean "optional." The Security
Rule describes the process Covered Entities must go through
when considering how to approach an addressable standard.
If an addressable standard or implementation specification
is "reasonable and appropriate," the Covered Entity
must implement the standard. Whether a standard is reasonable
and appropriate will depend on many factors including, among
others:
* the Covered Entity's risk analysis
* the Covered Entity's risk mitigation strategy
* existing security measures, and
* the cost of implementing the standard
Cost alone will almost never be a determinative factor,
but should be considered in light of the probability of
a security incident and the severity of the damage from
such an incident.
If the standard is unreasonable or inappropriate based on
this analysis, the Covered Entity must consider whether
an alternative measure exists that meets the same intent
of the standard. If the alternative measure is reasonable
and appropriate, the alternative measure must be implemented.
If no alternative measure exists, or if implementation of
the alternative measure would likewise be unreasonable or
inappropriate, the Covered Entity may avoid implementing
the standard.
Each step of this process must be documented.
Appendix A to the final Security Rule, as mentioned above,
is available here:
http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/03-3877.pdf
Acrobat Reader is required to view this document. Scroll
to Federal Register page 8380.
#14: Access Control And Validation
Procedures (November 16, 2004)
Covered Entities must implement procedures to control and
validate access to facilities based on role or function.
The procedure must include visitor control. Access control
and validation is an "addressable" requirement
under the Facility Access Controls standard. Covered Entities
must implement the specification unless it is inappropriate
or unreasonable and cannot be met through an alternative
measure.
"Access controls" include more than locks and
keycards. Physical barriers such as walls and fences should
be assessed if they are relied upon to control access to
the facility (or specific rooms within the facility). A
room for storing health information may be locked, but is
not secure if the walls to the room don't extend above the
false ceiling, allowing someone to enter the room with relative
ease.
As a general practice, access control procedures should
be designed with internal controls built in. That means
employing a system of checks and balances to ensure that
one person acting alone cannot thwart facility security
measures. In a facility employing keycards, for example,
the individual responsible for coding the cards should not
be the same person as the one reviewing access logs. With
effective internal controls, inappropriate access would
require the cooperation of two or more individuals, making
such an event less likely.
#13: Facility Security Plan
(November 3, 2004)
Covered Entities must
implement policies to safeguard their facility and their
equipment from unauthorized physical access, tampering,
and theft. The "facility security plan" is an
addressable implementation specification under the Facility
Access Controls standard. Covered Entities must implement
the specification unless it is inappropriate or unreasonable
and cannot be met through an alternative measure.
When developing a facility security plan, Covered Entities
should address protection of health information in both
electronic and paper media. Although the Security Rule itself
applies only to electronic health information, the Privacy
Rules mandate "appropriate physical safeguards"
to protect the privacy of health information -- both electronically
and on paper.
The facility security plan is not simply a static description
of security measures. The plan should include policies and
procedures to deal with reasonably anticipated events, such
as reporting and removing unauthorized individuals. Reliance
on third parties to provide any component of physical security
should be considered in the plan as well. For example, an
ambulatory surgery center located in one suite of a medical
office building should document its consideration of security
provided by the building owner -- if any. Conversely, a
hybrid entity (an organization whose "Covered Entity"
functions form a discrete component) need only develop a
facility security plan for the component of its operations
housing health information.
#12:
Risk Analysis (October 26, 2004)
The Security Rule requires Covered Entities to conduct an
accurate and thorough assessment of the potential risks
and vulnerabilities to the confidentiality, integrity, and
availability of electronic health information held by the
Covered Entity. Risk analysis is a required specification
of the Security Management Process standard and is mandatory
for all Covered Entities.
The risk analysis specification is packed with defined terms
which are essential to understanding the scope of the requirement:
• "Confidentiality" means that information
is not made available or disclosed to unauthorized persons
or processes.
• "Integrity" means that information has
not been altered or destroyed in an unauthorized manner.
• "Availability" means that information
is accessible and useable upon demand by authorized persons.
Risk analysis asks Covered Entities to answer the basic
questions of, "What could go wrong with my system?"
"How likely is it that this will happen?" "What
controls are already in place to prevent this?" "What
will be the damage if it happens anyway?" In a thorough
risk analysis, Covered Entities will assess threats ranging
from disgruntled former employees to international terrorist
plots.
Fortunately for the Security Officer, a team approach to
risk analysis is almost always in order. A thorough risk
assessment requires knowledge of the system architecture,
identification of potential threats to the system, correct
classification of the likelihood of the threat and the potential
losses if the threat should come to pass, and the recommended
controls to cost-effectively mitigate the risk. Few individuals
have the ability to singlehandedly conduct a credible risk
analysis.
Covered entities should remember that risk analysis is not
a one-time event. Both the Privacy Standards and good business
practices require Covered Entities to reassess risks from
time to time. With that in mind, one of the first tasks
of the risk analysis team might be to develop a policy on
risk analysis, including triggering events for assessment
or reassessment and the default timeframes for regular,
periodic reviews.
#11: Data Disposal (October
19, 2004)
The Security Standards
require Covered Entities to have a policy addressing the
"final disposition" of electronic health information
and the hardware or electronic media on which it is stored.
This specification is part of the "device and media
controls" standard and is a required item for all Covered
Entitites.
Truly disposing of electronic information isn't as easy
as one might think. Covered Entities should understand the
difference between preventing recovery of data by ordinary
access methods (clearing) and preventing recovery by laboratory
methods (purging). Basically, "clearing" involves
using the deleting functions built into the PC operating
system. Purging techniques range from sophisticated disc
overwriting (embodied in Department of Defense standard
5220.22-M) to degaussing (using a magnetic field to return
the medium to its initial state) to outright destruction
of the medium.
The determination of the appropriate disposal technique
will be driven primarily by the Covered Entity's risk analysis
- - what are the risks of an unauthorized recovery and what
are the costs of preventing that risk? Data recovery equipment
is cheap and increasingly user friendly, and the costs of
an unauthorized recovery can be substantial. Unless discarded
hardware is going straight to the county landfill with no
stops along the way, some kind of purging method will usually
be in order.
Disposal is the final phase in the IT system life cycle.
Although the manufacturing industry suggests three years
as a replacement cycle for PCs, in recent years that has
tended to lengthen towards four to five years. Even so,
this suggests that PCs will be replaced before the expiration
of applicable state and federal medical record retention
periods. Accordingly, data disposal must be coordinated
with the Covered Entity's compliance document retention
schedule to ensure that necessary records are not destroyed
prematurely.
To
view HIPAA Tips 1-10 Click Here
|
