Yeah, it really looks like some of these are boiling down to the auditor's
discretion.  I realize there are a lot of ways to "ensure data integrity"
(thanks for a good summary Kevin). I was hoping to learn which specific ways
people have used to pass HIPAA compliance in the past, but it doesn't look
like there's any clear answer here.

On Tue, Apr 26, 2011 at 2:19 PM, James Manico <j...@manico.net> wrote:

> Rohit,
>
> The most cost-effective way to handle these requirements is to get your
> HIPPA auditor drunk nightly.
>
> I'm being partially serious here because these and other HIPPA requirements
> are:
>
> (1) Technically ambiguous
> (2) Often in conflict with other HIPPA requirements
> (3) Impossible to achieve cost effectively
>
> For example, there are HIPPA access control requirements that demand that
> you only give doctors access to transmit patient data in a minimal way; only
> transmitting data needed for a diagnosis. Good luck coding that. It's also
> bad medicine.
>
> And now, let me leave you with a few lyrics from the Bon Jovi song "bad
> medicine". He was singing about medical software, I'm fairly sure:
>
> "I ain't got a fever got a permanent disease
> And it'll take more than a doctor to prescribe a remedy
> And I got lots of money but it isn't what I need
> Gonna take more than a shot to get this poison outta me
> And I got all the symptoms, count 'em 1, 2, 3"
>
> ;)
> Jim Manico
>
> On Apr 26, 2011, at 2:35 AM, Rohit Sethi <rkli...@gmail.com> wrote:
>
> Hi all,
>
> Has anyone had to deal with the following HIPAA compliance requirements
> within a custom application before:
>
>
>
> §164.312(c)(2)
>
> Implement electronic mechanisms to corroborate that electronic protected
> health information has not been altered or destroyed in an unauthorized
> manner.
>
>
>
> §164.312(e)(2)(i)
>
> Implement security measures to ensure that electronically transmitted
> electronic protected health information is not improperly modified without
> detection until disposed of.
>
>
> How have you actually implemented these controls in applications? Have you
> used a third party tool to do this? Does §164.312(c)(2) simply boil down to
> sufficient access control?
>
> --
> Rohit Sethi
> SD Elements
> <http://www.sdelements.com>http://www.sdelements.com
> twitter: rksethi
>
>  _______________________________________________
> Secure Coding mailing list (SC-L) <SC-L@securecoding.org>
> SC-L@securecoding.org
> List information, subscriptions, etc -
> <http://krvw.com/mailman/listinfo/sc-l>
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - <http://www.securecoding.org/list/charter.php>
> http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: <http://twitter.com/KRvW_Associates>
> http://twitter.com/KRvW_Associates
> _______________________________________________
>
>


-- 
Rohit Sethi
SD Elements
http://www.sdelements.com
twitter: rksethi
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________

Reply via email to