Emr are comprised of various kinds of data. Visit information ( date/location/insurance info) appears to lend itself to some RDMS. Other kinds of medical infomation, for example lab reviews, x-sun rays, photos, and electronic signatures, are document based and would appear to become a good candidate for any 'document-oriented' database, for example MongoDB.

Typically, binary data could be saved like a BLOB inside a RDBMS. A hybrid approach utilizing a traditional RDBMS together with a 'document-oriented' database would appear like good option for this. Other alternative could be something similar to DB2 purexml.

The best answer might be that 'it depends', however i really wanted to obtain some general feedback/applying for grants this.

Is anybody while using NoSql method for medical records?

** Making clear question ** To clarify: is anybody using nosql databases for example: mongoDB, Cassandra, CouchDB for medical records, inside a production atmosphere?

Possibly the initial NoSQL database was MUMPS, which dates from before Codd devised his rules (i.e. the sixties). Because the title suggests (*M*assachusetts General Hospital *U*tility *M*ulti-*P*rogramming *S*ystem), its original purpose was the storing of medical documents. Apparently MUMPS continues to be being used in certain health care systems along with other conditions. Discover more.

But for the greater recent rash of NoSQL databases I'd be suprised if there have been any implementations - yet. Many of these items continue to be very beta and - being largely free - missing in support. Medical applications are inevitably likely to be very conservative, because individuals could die when the IT system fouls up.

A number of large health care software suppliers apply certain version of MUMPS, certainly a non-SQL database. Epic, Meditech, General electric, and also the VA's VistA all apply certain implementation of MUMPS. MUMPS gives itself well to health care solutions simply due to its performance and scalability.

I understand that some MUMPS implementations (I am thinking particularly of Intersystems Caché) permit you to query the database with SQL, but that needs some thorough technical understanding to map your non-relational data model to relational tables.

Sometimes for any large EMR vendor that utilizes MUMPS and I will tell you it isn't a "fun" experience. What i mean is there aren't great tools that let me create awesome features inside a couple of lines of code (there is no LINQ-To-M insInternet). However I notice that the cost I pay on paper more code to question information is well worth the marketshare.

If you are beginning an EMR business and creating your architecture, you have to think about your ultimate goals. If you are searching to produce a full-fledged EMR that may span multiple areas and areas, you will need a Large amount of features while still keeping track of performance, reliability, and scalability. You'll also require a couple of 1000 designers to obtain your products to promote As soon as possible since with the brand new Health care stimulus, the hospitals are purchasing now.

If you are searching in a niche niche application, where your users list is going to be small , focused, you are able to choose associated with a database technology, searching more for pedaling and rapid development.

I'd suggest the next given that you're searching at multiple options [SQL or NoSQL]. While reading through on magento I discovered http://en.wikipedia.org/wiki/Entity-attribute-value_model making sense if you have a lot of characteristics [posts in day to language] which most is going to be null. Educate yourself the wiki page and note the part that particularly associated with lab reviews.

I'm using NeoDatis ODB that is an item-oriented database (not really a document-oriented like CouchDB or MongoDB). It features a really low memory footprint and supports database file encrytption.

Take a look at IotaPro: http://iota.professional/Home page/ It is dependant on neo4j.

For additional on Global-based databases (for example Mumps and Cache) and just how they can be used a "Universal NoSQL Engine", see http://www.mgateway.com/paperwork/universalNoSQL.pdf