Nadrek (7/30/2010)
Katherine Fraser (7/30/2010)
....an application to audit any PHI access. That is, any time a stored procedure returns PHI to the application, I'll have to enter a log record showing what data was seen, by whom and when.I'll be using Service Broker to log the accesses, sending encrypted messages, and storing it in a database encrypted with TDE...
How is that going to work when a DBA or developer or process is doing bulk historical reporting, or investigating/troubleshooting to find patterns (selecting millions of rows to let a human spot patterns)?
It won't. This solution is just intended to log PHI accesses from the application and the application can only retrieve data via stored procedures. So I'll put the audit code inside the procs to capture what's being returned. Our report procs are capped at 65k rows so I'm hoping that will be manageable. And summary reports don't include PHI since it is detail data like patient name, address or medical record number.
You are correct in pointing out that we aren't auditing what direct database users are viewing. I'm not sure what would be a good method for that given, as you noted, the large number of rows that could be returned. For now we acknowledge that people who have direct database access can see all PHI. But that set of users is very limited and their access is audited, albeit at a much less granular level that does not include the individual queries that were run or their results.
------------------------------------------------------
Katherine