RE: MySQL and HIPAA Compliance?
Now see, if I gave that away, I wouldn't have interested you, now would I? As with all databases, you need to collect some kind of identifying information. That's what the "save 1 or 2 tables" statement was about. Take this simple system for example. Table 1 ... UserID UserNameFirst_Name Last_Name 1 logmeon J.R.Bullington Table 2 ... ID1 UserID SitePassword 1 1 145 12345 Table 3 ... SiteID SiteNameSiteLoc 145 HomeSomePlace USA And so on and so forth... Out of the information above, let's "print" some... If I printed 2 and 3, what could you do with it? Nothing, since the FK is not the same as PK. Now, we database people know what we could do, but not the layman. If I printed 1 and 3, what could you do with it? Nothing, no references... If I printed 1 and 2, a little more could be done, because you have username and password, but the rest of the data is unrecognizable. Now here is the real fun... Take away the table names, add 5000 records to each table, and shuffle them. That's the typical database size in a medium-sized clinic. Since you wouldn't actually print all 5000 records onto paper, you would only print what you wanted to see, how could you figure it out? Rhetorical question as you couldn't without the database schema in hand to relate back to. Only 1 table out of the ubound(Table(x)) that I could have created (only 3 shown) have personally identifiable data in them. No one but the administrator and/or data entry person(s) has/ve access to that one table. Hence... HIPAA compliance. Welcome to my world... J.R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 1:46 PM To: J.R. Bullington Cc: mysql@lists.mysql.com Subject: Re: MySQL and HIPAA Compliance? >> 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] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL and HIPAA Compliance?
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]
Re: MySQL and HIPAA Compliance?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Matthews wrote: [snip] > For example, besides containing regulations concerning techology for > software that deals with artifacts that fall under HIPPA (but does not > mandate _which_ technology to use), there are regulations about > _physical_ security (i.e. who has access to the file cabinet, the server > room, the fax machine, etc), administrative safeguards, as well as > codifcation standards (ICD9's and the like, as well as other > "Portability" issues, which is one of the "P"s in HIPPA) and any number [snip] Sorry, that should've been _the_ "P" in _HIPAA_ ;) Finally managed to dig up the technology requirements from H&HS at http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/nprm/sec14.asp And of course, given these, a solution built on top of MySQL _can_ be HIPAA-compliant (given that you meet the non-technology-related regulations as well, which are probably harder to deal with). Of course, these requirements apply to the system as a _whole_, but MySQL by itself also meets the requirements. > Requirement > -- > Access control (The following implementation feature must be implemented: > Procedure for emergency access. In addition, at least one of the following > three implementation features must be implemented: Context-based access, > Role-based access, User-based access. The use of Encryption is optional). There's emergency-based access, as well as user-based access in MySQL. One can also, if they so desire use encryption. > Audit controls You can enable MySQL to create audit logs, with recording every query issued by any user the time at which that query happened. > Authorization control (At least one of the listed implementation features > must be implemented). > > > Role-based access. > User-based access. MySQL has User-based access. > Data Authentication (HIPAA's definition is "The corroboration that data has > not been altered or destroyed in an unauthorized manner. Examples of how data > corroboration may be assured include the use of a check sum, double keying, a > message authentication code, or digital signature.") MySQL has cryptographic hashing functionality which meets this requirement. > Entity authentication (The following implementation features must be > implemented: Automatic logoff, Unique user identification. In addition, at > least one of the other listed implementation features must be implemented). > > > Automatic logoff. > Biometric. > Password. > PIN. > Telephone callback. > Token. > Unique user identification. MySQL has automatic log-off capabilities (connection timeouts), as well as unique user identification, and has passwords. -Mark - -- Mark Matthews MySQL AB, Software Development Manager - Connectivity www.mysql.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC86TDtvXNTca6JD8RAsvJAJ9Mhl9tiXFzpoZmocmVRmXXrxUClQCfZH2D wXzjU3u4oAhicyenewPE2Z8= =QGJH -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: MySQL and HIPAA Compliance?
I just completed designing a site for a dentist that had to be HIPAA compliant. To see how I structured it take a look at www.brianwilliamsdds.com. Keith D. Holler Owner/Senior Network Engineer AZCAPPY Network Services www.azcappy.com 623-931-0809 623-321-8177 Fax -Original Message- From: J.R. Bullington [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 10:29 AM To: mysql@lists.mysql.com Subject: RE: MySQL and HIPAA Compliance? What a great discussion thread! Gary, I currently use MySQL as part of a HIPAA compliant system for the integration of web-based apps with Patient Care information. HIPAA (Health Information Portability and Accountability Act) is a set of standards set by the US Government to protect people's private health information. Although created in 1996, only recently (April 2005) has it started to really affect the way that health care organizations really needed to worry about it's IT implications. So, let's get to quick and dirty bottom of this: Is MySQL compliant -- NO. Neither is any other RDBMS on the market today. 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. You are correct that the Electronic Data Interchange (EDI) and application layers are responsible for the encryption of the data. As long as the data is in a locked, windowless, office (hopefully a server room) with adequate security features (like physical security) and the system is locked with passwords and has virus protection, then the data is HIPAA compliant. What HIPAA was truly designed for was not the storage of data but the PORTABILITY of data. How is the data accessed and who sees it? Data needs to be accessed over a secure connection, either via SSL or other encryption standards (AES, WEP, TLS, etc.) and must have a strong password (minimum 8 characters, alphanumeric, and special characters) in order to decrypt it. That being said, only certain individuals are even allowed to access that data, set up via Active Directory, directory shares, or by access lists. With the web based applications that I use, you must either be inside the network or access it via a 128-bit encrypted VPN. Not only does the data transmission need to be encrypted, but it also needs to be adequately logged as to who sees it, what they were looking at, how long they were there, and what their purpose was. 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. Now, I am just a computer jockey with ump-teen years experience under my belt, so don't take what I have written here to be law. However, being the in healthcare field and designing databases with HIPAA compliance in mind has been a huge help. There are lots of sites out there with much more information than I have in my head, so I would seek those out as well. One site, http://www.wpc-edi.com/hipaa/ has all the data that you need straight from the ass's (oops, horse's) mouth of the US Gov't. I have helped in the authoring of a few papers on HIPAA compliance and computers in the healthcare industry that, if this would be of interest to anyone, are available. Please email me directly, as putting them on the list would be unwanted propaganda. I hope this sparks some more discussion from 'the group'. Sincerely, J.R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 12:56 PM To: mysql@lists.mysql.com Subject: MySQL and HIPAA Compliance? Hi, I'm taking a database class and we are given open ended discussion questions each week. The question this week is: "Will MySQL take away market share from popular DBMSs? Will your comments change if you are told that MySQL is not HIPPAA compliant?" I have been using MySQL for well over 3 years, and other databases for well over 10 years (professionally, as a coderbout time I took a class eh?) and I do think I have an informed opinion for the first part. I'm weak in the area of HIPAA compliance though. I know it basically centers around privacy. I know it covers things like adequate logging, encrypted connections, etc, but it also seems to include a lot of EDI interoperability. Now that seems to be something that should be handled at an application level and MySQL shouldn't be penalized because of this. >From the searching I have done, it appears that MSSQL for example >offers this mandatory feature via their Biztalk server (to handle all the EDI) There are all manner of sites that will discuss HIPAA compliance for a fee. Is anyone here familiar with this that
RE: MySQL and HIPAA Compliance?
What a great discussion thread! Gary, I currently use MySQL as part of a HIPAA compliant system for the integration of web-based apps with Patient Care information. HIPAA (Health Information Portability and Accountability Act) is a set of standards set by the US Government to protect people's private health information. Although created in 1996, only recently (April 2005) has it started to really affect the way that health care organizations really needed to worry about it's IT implications. So, let's get to quick and dirty bottom of this: Is MySQL compliant -- NO. Neither is any other RDBMS on the market today. 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. You are correct that the Electronic Data Interchange (EDI) and application layers are responsible for the encryption of the data. As long as the data is in a locked, windowless, office (hopefully a server room) with adequate security features (like physical security) and the system is locked with passwords and has virus protection, then the data is HIPAA compliant. What HIPAA was truly designed for was not the storage of data but the PORTABILITY of data. How is the data accessed and who sees it? Data needs to be accessed over a secure connection, either via SSL or other encryption standards (AES, WEP, TLS, etc.) and must have a strong password (minimum 8 characters, alphanumeric, and special characters) in order to decrypt it. That being said, only certain individuals are even allowed to access that data, set up via Active Directory, directory shares, or by access lists. With the web based applications that I use, you must either be inside the network or access it via a 128-bit encrypted VPN. Not only does the data transmission need to be encrypted, but it also needs to be adequately logged as to who sees it, what they were looking at, how long they were there, and what their purpose was. 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. Now, I am just a computer jockey with ump-teen years experience under my belt, so don't take what I have written here to be law. However, being the in healthcare field and designing databases with HIPAA compliance in mind has been a huge help. There are lots of sites out there with much more information than I have in my head, so I would seek those out as well. One site, http://www.wpc-edi.com/hipaa/ has all the data that you need straight from the ass's (oops, horse's) mouth of the US Gov't. I have helped in the authoring of a few papers on HIPAA compliance and computers in the healthcare industry that, if this would be of interest to anyone, are available. Please email me directly, as putting them on the list would be unwanted propaganda. I hope this sparks some more discussion from 'the group'. Sincerely, J.R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 12:56 PM To: mysql@lists.mysql.com Subject: MySQL and HIPAA Compliance? Hi, I'm taking a database class and we are given open ended discussion questions each week. The question this week is: "Will MySQL take away market share from popular DBMSs? Will your comments change if you are told that MySQL is not HIPPAA compliant?" I have been using MySQL for well over 3 years, and other databases for well over 10 years (professionally, as a coderbout time I took a class eh?) and I do think I have an informed opinion for the first part. I'm weak in the area of HIPAA compliance though. I know it basically centers around privacy. I know it covers things like adequate logging, encrypted connections, etc, but it also seems to include a lot of EDI interoperability. Now that seems to be something that should be handled at an application level and MySQL shouldn't be penalized because of this. >From the searching I have done, it appears that MSSQL for example offers this mandatory feature via their Biztalk server (to handle all the EDI) There are all manner of sites that will discuss HIPAA compliance for a fee. Is anyone here familiar with this that could provide a reference or a simple summary. It seems an interesting and important topic that I thought the list might be interested. Regards, Gary Huntress -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL and HIPAA Compliance?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Hi, > > I'm taking a database class and we are given open ended discussion questions > each week. The question this week is: > > "Will MySQL take away market share from popular DBMSs? Will your comments > change if you are told that MySQL is not HIPPAA compliant?" I'm not a HIPPA consultant, nor a lawyer, but have worked in the healthcare industry in the past (before I joined MySQL), so I have _some _ experience, but don't take this as a legal consultation ;) As far as I know, a _Database_Product_ can't be declared HIPPA-compliant, although features _in_ a database can help ease the route to compliance. Medical Records Software in combination with an organization and its processes have to be compliant (and it's based on process just as much as product). For example, besides containing regulations concerning techology for software that deals with artifacts that fall under HIPPA (but does not mandate _which_ technology to use), there are regulations about _physical_ security (i.e. who has access to the file cabinet, the server room, the fax machine, etc), administrative safeguards, as well as codifcation standards (ICD9's and the like, as well as other "Portability" issues, which is one of the "P"s in HIPPA) and any number of regulations that are outside the scope of database and/or middleware software. > > I have been using MySQL for well over 3 years, and other databases for well > over 10 years (professionally, as a coderbout time I took a class eh?) > and I do think I have an informed opinion for the first part. > > I'm weak in the area of HIPAA compliance though. I know it basically centers > around privacy. I know it covers things like adequate logging, encrypted > connections, etc, but it also seems to include a lot of EDI interoperability. > Now that seems to be something that should be handled at an application > level and MySQL shouldn't be penalized because of this. From the searching > I have done, it appears that MSSQL for example offers this mandatory feature > via their Biztalk server (to handle all the EDI) > > There are all manner of sites that will discuss HIPAA compliance for a fee. > Is anyone here familiar with this that could provide a reference or a simple > summary. It seems an interesting and important topic that I thought the list > might be interested. Try Health and Human Service's Website http://aspe.hhs.gov/admnsimp/bannertx.htm -Mark - -- Mark Matthews MySQL AB, Software Development Manager - Connectivity www.mysql.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC852RtvXNTca6JD8RApRyAKCr7GD00dQ/E/we7uH44eoWKPUuQQCff7O5 fODyR4aoEm4A2JVYSSM+84o= =6Aup -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
