On Fri, Aug 05, 2005 at 01:29:19PM -0400, J.R. Bullington wrote:
> The way that data is stored is not at the issue. It's the way that data is
> collected that is at the heart of the RDBMS part of HIPAA.
I once interned for a major vendor of HIPAA-compliant hospital IT
solutions, doing software quality assurance on their internal
products. I was responsible for testing two of the most
HIPAA-relevant pieces of inftastructure in the whole architechture:
1) User authentication: HIPPA compliance requires that someone be
explicity authorized to view data before they can view it. We had a
reasonably sophisticated token system that was implemented for every
API. In addition to a function's parameters, it also needed it's
security token. That security token was based on the user that had
logged in and what they were attempting to view.
Security tokens would be assigned to users and stored in an isolated
database (we had Oracle, MS SQL, and DB2 modules, though there's no reason
MySQL couldn't be supported). A security administrator would
use a tool to assign the proper permissions to their users. This
would literally define what APIs the user had access to (similar to
Java's security policy, but with a database backend and even finer
grained control).
2) Audit logging: Every time an authenticated user retrieved some
piece of data, we had to create an audit record that could prove they
did it. This is the "Accountability" part of HIPAA.
An auditing administrator would configure the auditing properties,
which gets stored in another isolated database. Anytime an
authenticated user does something that the auditing administrator has
decided is significant - boom, a record gets written to record the
fact.
You'll notice that in both cases, the HIPPA-ness is implemented on a
higher level than the actual database. Like JR said, as long as the
server is secured, there's no problem with that implementation.
Having said that, we all laughed at the idea of running our software
in a production environment on anything but a DB2 mainframe. These
two pieces are quite a heavy load on the databases - just imagine how
many audit records can be generated at a large busy hospital!
We had a test load that could easily bog down our database servers. Of
course it was contrived, and our testing budget prevented us from
having serious hardware to test with, but it always boggled my mind to
think of all the audit records that would be stored somewhere (and
probably never looked at ::-).
> Now the systems that I designed/use were designed with HIPAA in mind, so,
> save 1 or 2 tables, everything is in integers. Printing out an entire table
> of data and leaving it in the cafeteria is not an issue as you would see
> nothing but numbers. Without having the database schema in hand to reference
> what all the numbers mean, you won't be able to determine anything.
That's a clever idea! But didn't you have to store personal
information at somepoint? I guess you could do a clever encoding
scheme to map a name and address to a very large integer, but that
seems... not much better. How did you handle that issue?
--
Ross Vandegrift
[EMAIL PROTECTED]
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
