Hi Larry & all, This seems like a tremedous effort. One I'm glad to know nothing about, but it reminds me of a problem where I used to work whose solution may be applicable.
The purchase order database ran on a classified mainframe. Some folks without security clearance needed access to the purchase orders they placed. Every night the unclassified part of the classified database was downloaded to an unclassified version of the database on an unclassified VAX that everyone had access to. It wasn't long before everyone wanted to use the unclassified version because it had all the information they wanted and had easier access. This seems applicable to this problem. Since collected, unidentifiable data used for statistics on wouldn't need to be quite so real time an "unclassified database" that is loaded from the classified database would remove the ability to spy. It wouldn't remove the necessity to log people who see the "classified data", but it would sure lower the volume of accesses and the need to have many levels of access to the "classified data." Dave Billing Tall Tree Business Solutions ----- Original Message ----- From: "Lawrence Lustig" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, January 30, 2003 3:29 PM Subject: [RBASE-L] - Re: OT: HIPAA debriefing and resources > > > 1) Patients will always have a right to see who has > > accessed their file. > > That means that the R:Base/R:Tango application > > should keep a log of > > every time a user views confidential information. > > (right before the EDIT > > USING or BROWSE command, e.g., have an INSERT > > command into > > the log table.) And there should be a way to report > > all access of a > > given individual's records. > > This seems like an enormous amount of work to retrofit > into existing systems, and even more work to make sure > that _every_ time someone accesses data a record is > made. Also, you can't allow anyone to have access to > the R> prompt since BROWSE, etc commands could be > issued that would result in data being shown. > > What would really work well is a SELECT trigger, so > that everytime a row was accessed you could fire some > code. You would need some way to find out what > columns are in the output set, because some SELECTs > would be "innocent" but some would need to be logged > (for instance, a group by ZipCode with no identifying > information would not need to be logged, a group by > PatientID would be). > > All you'd need to do is implement a set of robust > SELECT triggers for those tables containing > identifying information. > > I don't know of any database that actually implement > SELECT triggers (although the concept sounds vaguely > familiar, so maybe someone does have it) but any > database that did would be particularly well suited to > HIPAA-subject applications. > > > I'm also planning to nag RBTI a little on a > > long-standing request for a > > new R:Base command: > > > > UNLOAD DATA FOR tableView AS FORMATTED USING column > > x y, > > column2 x y, etc. > > > > It would be the outgoing counterpart to the existing > > LOAD ... AS > > FORMATTED command. > > Although it would be nicely symetrical to have an > UNLOAD matching the LOAD, am I mistaken in thinking > you can do this in a single command already by > concatenating a bunch of LJS(CTXT(ColName)) > expressions in a SELECT statement? > -- > Larry > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com >
