HIPAA Archives

February 2003

HIPAA@LIST.UVM.EDU

Options: Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Peter Harrington <[log in to unmask]>
Reply To:
Hipaa Project <[log in to unmask]>
Date:
Thu, 13 Feb 2003 14:37:31 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (116 lines)
The reviews are already rolling in, and the official version isn't even
published yet.

----- Original Message -----
From: "Christiansen, John (SEA)" <[log in to unmask]>
To: "Health Information and Technology List" <[log in to unmask]>
Sent: Thursday, February 13, 2003 2:08 PM
Subject: [hit] Preliminary Impressions of the Final Security Rule


> Overall, I think I like it.
>
> HHS seems to have done a pretty good job of integrating it with the
Privacy
> Rule, conceptually, in use of terminology, and in terms of reorganizing
the
> codification (which won't really become helpful until it they are together
> in the Code of Federal Regulations). A number of redundancies have been
> eliminated, as have some unclear concepts and terms.
>
> There is what seems to be a useful new structure to the rules, which are
now
> organized according to "standard" (which states a requirement in
generalized
> terms) and "implementation specifications" (which identify what you do to
> meet a standard). Implementation specifications are then broken down into
> "required" and "addressable" specifications.
>
> A "required" specification is just what is says: Implement as stated.  For
> example, risk analysis and risk management are required; so is security
> incident (now a defined term) response. (Note: the final rule continues
the
> "technology-neutral" stance of the draft, so there are no required
> technology specifications)
>
>   An "addressable" specification, on the other hand, is one where you must
> make a decision: Address the specification specifically, implement an
> alternative which covers the same general concept identified in the
> standard, do a combination of both, or do nothing.  The decision what to
do,
> however, must be reasonable based upon a risk assessment, and if an
> alternative solution is adopted or the decision is to do nothing, the
basis
> for the decision must be documented. Thus, for example, the access
> authorization standard is implemented by addressable standards, allowing
it
> to be "scaled" to the organization.
>
> This approach was implicit in the draft rule, but it was not clear how it
> applied or whether it applied to all standards. I think it will prove a
> helpful clarification.
>
> The general areas which must be addressed remain the same; covered
entities
> (the term is now used in the rule) must address standards in the areas of
> administrative, physical and technical safeguards. However, a number of
> redundancies have been eliminated, and several useful definitions have
been
> added or clarified. For example, chain of trust agreement requirements
have
> been folded into business associate contracting.
>
> One point worth noting is that the draft rule required a risk assessment
as
> the starting point for security determinations, but did not particularly
> emphasize it. It seems to me that there is more emphasis on risk
assessment
> in the final rule, in that it is tied expressly in as the basis for making
> "addressable specification" choices.
>
> This is very much a process-oriented rule; I don't see safe harbors, but I
> do see a framework requiring informed, reasonable, appropriate and
> documented decision-making. The preamble repeatedly emphasizes that this
> shouldn't pose substantial financial or administrative hardship, assuming
> you've been reasonable about security already - but I'm not sure how valid
> that assumption always is.
>
> Finally, it's now official: electronic signatures are on a separate track,
> though apparently a rule is going to be published.
>
> John R. Christiansen
> Preston | Gates | Ellis LLP
> PLEASE NOTE OUR NEW ADDRESS AND PHONE NUMBERS EFFECTIVE TUESDAY, JANUARY
21:
> 925 Fourth Avenue, Suite 2900
> Seattle, Washington 98104
> *Direct: 206.370.8118 *Cell: 206.683.9125
> * [log in to unmask]
> Notice: Internet e-mail is inherently insecure. Unencrypted e-mail may be
> accessible to unauthorized viewers, content may be modified or corrupted,
> and headers or signatures may incorrectly identify the sender. If you wish
> to confirm this message or the identity of the sender, please contact me
> using a communications channel other than a "reply" to this e-mail. Secure
> electronic messaging is available and recommended for confidential or
> sensitive communications.
>
>
> --------------------------------------------------
> Sponsored by Practical Guidance on HIPAA Preemption of State Laws:
Analytical Framework and Preemption Methodology
> Go to <http://www.healthlawyers.org/pdeml.cfm?i=24781> An essential
publication from American Health Lawyers Association
> --------------------------------------------------
> Listserve hosted by American Health Lawyers Association,
<http://www.healthlawyers.org>.
> E-mail [log in to unmask] for assistance.
> For rules and disclaimers, go to
<http://www.healthlawyers.org/listserves/rules>.
> For information about other listserves, go to
<http://www.healthlawyers.org/listserves>.
> ---
> You are currently subscribed to hit as: [log in to unmask]
> To unsubscribe go to <http://www.healthlawyers.org/listserves/manager>
> Or send a blank email to [log in to unmask]
>

ATOM RSS1 RSS2