Anyone using NoSQL databases for medical record storage?

Question

Electronic Medical records are composed of different types of data. Visit information ( date/location/insurance info) seems to lend itself to a RDMS. Other types of medical infomation, such as lab reports, x-rays, photos, and electronic signatures, are document based and would seem to be a good candidate for a 'document-oriented' database, such as MongoDB.

Traditionally, binary data would be stored as a BLOB in a RDBMS. A hybrid approach using a traditional RDBMS along with a 'document-oriented' database would seem like good alternative to this. Other alternative would be something like DB2 purexml.

The ultimate answer could be that 'it depends', but I really just wanted to get some general feedback/ideas on this.

Is anyone using the NoSql approach for medical records?

** Clarifying question ** To clarify: is anyone using nosql databases such as: mongoDB, Cassandra, CouchDB for medical records, in a production environment?

Answer 1

I'd suggest the following given that you are looking at multiple options [SQL or NoSQL]. While reading up on magento I came across http://en.wikipedia.org/wiki/Entity-attribute-value_model which makes sense when you have a large number of attributes [columns in day to language] of which most will be null. Read up the wiki page and note the part that specifically related to lab reports.

Answer 2

Perhaps the original NoSQL database was MUMPS, which dates from before Codd devised his rules (i.e. the 1960s). As the name implies (*M*assachusetts General Hospital *U*tility *M*ulti-*P*rogramming *S*ystem), its original purpose was the storing of medical documents. Apparently MUMPS is still in use in some healthcare systems and other environments. Find out more.

But as for the more recent rash of NoSQL databases I would be suprised if there were any implementations - yet. Most of these products are still extremely beta and - being largely open source - lacking in support. Medical apps are inevitably going to be extremely conservative, because people could die if the IT system fouls up.

Answer 3

A handful of large healthcare software vendors use some version of MUMPS, definitely a non-SQL database. Epic, Meditech, GE, and the VA's VistA all use some implementation of MUMPS. MUMPS lends itself well to healthcare solutions in part because of its performance and scalability.

I know that some MUMPS implementations (I'm thinking specifically of Intersystems Caché) allow you to query the database with SQL, but that requires some in depth technical knowledge to map your non-relational data model to relational tables.

I work for a large EMR vendor that uses MUMPS and I can tell you it's not a "fun" experience. By that I mean that there aren't great tools that allow me to whip up awesome features in a few lines of code (there's no LINQ-To-M in .NET). But I recognize that the price I pay in writing more code to query data is worth the marketshare.

If you're starting an EMR business and designing your architecture, you need to think of your ultimate goals. If you're looking to create a full-fledged EMR that can span multiple areas and specialties, you'll need a LOT of features while still keeping an eye on performance, reliability, and scalability. You'll also need a few thousand developers to get your product to market ASAP because with the new Healthcare stimulus, the hospitals are buying now.

If you're looking at a specialty niche application, where your user base will be small and focused, you can take your pick of any database technology, looking more for tooling and rapid development.

Answer 4

I am using NeoDatis ODB which is an object-oriented database (not a document-oriented like CouchDB or MongoDB). It has a very low memory footprint and supports database file encrytption.