LISTSERV mailing list manager LISTSERV 16.5

Help for HIPAA Archives


HIPAA Archives

HIPAA Archives


HIPAA@LIST.UVM.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

HIPAA Home

HIPAA Home

HIPAA  February 2003

HIPAA February 2003

Subject:

Fw: [hit] Preliminary Impressions of the Final Security Rule

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:

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]
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2004
February 2003
January 2003
December 2002
November 2002
October 2002, Week 1
October 2002
September 2002

ATOM RSS1 RSS2



LIST.UVM.EDU

CataList Email List Search Powered by the LISTSERV Email List Manager