Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Are the fast, document-based NoSQL solutions--MongoDB, Cassandra, CouchDB, etc--appropriate for PHI data? They have performance advantages compared to RDBMS for sure, but in general appears less mature.

I started designing a system based on MongoDB, but reading about the recent controversies in Reddit and Hacker News surrounding allegations of data loss with MongoDB gave me pause...

The controversy claimed MongoDB (appears to be one of the most popular NoSQLs) actually lost data. The implication is that with the many years of experience with RDBMSs, MySQL or PostgreQL are safer bets.

With the higher technical and regulatory requirements in healthcare, how much confidence can I really place on MongoDB?

Has anyone had success with using these database solutions in projects requiring HIPAA compliance?

share|improve this question

migrated from healthcareit.stackexchange.com May 4 '12 at 0:16

This question came from our site for healthcare IT professionals and solution providers.

4 Answers 4

up vote 10 down vote accepted

I don't see why it would be a problem. Actually, I'd say the largest part of healthcare IT runs on a NoSQL solution called MUMPS. You'd just have to be careful how it was implemented, but the argument for using a NoSQL solution actually makes a lot of sense in healthcare. You can read more about MUMPS and it possibly being replaced by the above NoSQL solutions you mention: http://www.emrandhipaa.com/emr-and-hipaa/2011/10/18/analysis-of-mumps-in-healthcare-emr/

I'm sure many would love for MUMPS to be gone and one of the solutions you described be put in place. Although, up until now I can't say I've seen anyone do it yet.

share|improve this answer
    
Thank you. From the comments in the link you provided, it would seem the Axial Project was developing an open source HIT platform. I'm not able to find the status of this project however. –  Ming-Chih Kao Nov 7 '11 at 10:23
    
Other than the video embedded in the link above, I couldn't find the status of it either. Although, the video seems to indicate they're still around, but might have shifted to a little different model. –  techguy Nov 7 '11 at 18:39

To add to @linda's answer, the database is just another layer in the stack of components that create an application. The security of that system is based upon the combination of all components.

Bottom line:

MongoDB, MySQL, Postgres, etc... They are all just ways of organizing bits for storage/retrieval. There are not necessarily more security flaws in one or the other simply because one is relational and another is object-oriented.

If you are implementing a new EMR or migrating, Be sure to talk to your IT guys about project specifics before making any CXO decisions! I've experienced too many tales of management making large sweeping and disastrous decisions without IT Input.

For HIPAA compliance, all pt info needs to be encrypted 'in transit' and 'at rest'. - Source

Also, i believe Epic also uses Cache in some of their products, as well. It's an object database.

share|improve this answer
    
The controversy I cited claimed MongoDB (appears to be one of the most popular NoSQLs) actually lost data. The implication is that with the many years of experience with RDBMSs, MySQL or PostgreQL are safer bets. With the higher technical and regulatory requirements in healthcare, How much confidence can I really place on MongoDB? I assume the HIT crowd has done formal assessments of this technology. –  Ming-Chih Kao Nov 8 '11 at 19:36
2  
Of the programmers I talk to (and it seems that your citation author would agree) say that it us MUCH harder to screw up in a relational database compared to a noSQL database. Unless you have a strong pre-existing system or a strong team who knows noSQL to the core, I think it is hard to argue that t the lower risk option is relational. But people can screw up no matter what tools you give them. –  Nicholas Orlowski Nov 8 '11 at 19:52
    
I like your comment in general, but disagree with the assertion that all patient info needs to be encrypted. Encryption is a safeguard so that if there is a breach, the data is not compromised and it's not necessarily a notifiable event. It's a good idea, certainly, but it is not expressly required by the regulation and there are costs to it. The best defense is preventing breaches in the first place. Source –  Lynn Nov 10 '11 at 15:55

It's not so much about which tool you use to store the data, but rather how you secure that data. I don't see any reason why a NoSQL solution couldn't be secured to an appropriate level, just as a RDBMS solution could be done in a way that was completely insecure.

Things to consider in securing the data (this is by no means an exhaustive list):

  • Access to the server (physical and netsecurity)
  • Access to the data on the server (access rights)
  • Encryption (I've seen debates over whether it's necessary to encrypt the data)
share|improve this answer

There is an effort, (by a friend) to develop a layer for PHI handling over MongoDB called RESTCat that might be appropriate for what you are specifically trying to do.

MondoDB is probably not as stable as MySQL et all, but MUMPS is probably more stable by several decades than any currently available SQL system.

Look at Cache (proprietary) or GTM (open source on Linux)

Those who favor MUMPS argue that healthcare data is more hierarchical than tabular (lots of many to many relationships) which makes it stronger in healthcare. Given MUMPS dominance in Health IT this is hard to argue with.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.