Re: Question about HIPAA Compliance in application development

[Chris Schmidt <chrisisbeef () gmail com>]

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

Sounds like contextual access control to me - someone wrote a pretty good blog about that once :)

I do however, agree on the bad medicine point - just like in diagnosing software bugs, often something seemingly 
unrelated to the problem you are addressing is either a contributing factor or the root of the problem itself! This is 
why engineers should be the ones writing the standards instead of standards authors. :)

Sent from my iPwn

On Apr 26, 2011, at 12:19 PM, James Manico <jim () 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 <rklists () 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
> > 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
> > _______________________________________________
>
> _______________________________________________
> 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
> _______________________________________________
_______________________________________________
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
_______________________________________________