opensesamizer wrote on Friday, May 22, 2015:
Open-EMR is built off of SQL database. Is Open-EMR compatible with nosql databases (GT.M, CouchDB, MongoDb, etc)?
yehster wrote on Friday, May 22, 2015:
No, it is not compatible with other databases. OpenEMR only works with MySQL or MariaDB. Other relational databases such as Postgres or SQL Server don’t work either.
There is a provision to use CouchDB for some data storage (storing documents in CouchDB instead of on the filesystem). However a relational database is still required for everything else.
What is the reason for wanting to use something else? Maybe there is a solution.
opensesamizer wrote on Friday, May 22, 2015:
Every time there is a new variable, it seems like a new table needs to be made. Is there an advantage in using a non-relational database like GT.M in terms of performance, no need for tables and the ACID database properties that is important for health data: https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html?
mdsupport wrote on Friday, May 22, 2015:
Are you asking a philosophical question about choice of databases or is there a specific variable you are trying to add that requires new table?
tmccormi wrote on Wednesday, May 27, 2015:
NoSQL databases have a place (which I’ve been thinking about a lot) in Medical data storage. Core, static data and data that needs to be reported on in some statistical way are best handled in a relational database (or similar). But it seems to me that Medical forms are essentially “write once” and would benefit from flexible key/value pair storage that allows for things to change over time without having to account for (or convert) past data formats/content. You can store all versions of the form in the same data record. I flexible rendering tool to (like we use with LBF) would allow for this to work very well.
–Tony
mdsupport wrote on Wednesday, May 27, 2015:
Philosophically, many forms (like vitals) that are observations lend to something like CouchDB which will allow updates but keep the revision history automatically. However, you can derive benefit from these databases only if you unload some processing logic / rules to the DB. For a project that stays away from even database views, it is going to be a significant strategic change.
@getinmybelly, as mentioned earlier, there is a optional component that uses CouchDB like file systtem to store documents. Unfortunately it uses almost none of the flexibility offered by couch. We currently use alternate implementation of CouchDB to hold interface objects that are not handled by standard project.
bradymiller wrote on Wednesday, May 27, 2015:
Hi,
To have an example from a performance standpoint. What would happen if the vitals form was stored in couchdb in performance terms of the the rules engine reporting. For example, if needing to search through several thousand patients for blood pressure reporting, would this be slower (or faster or same) than in mysql?
-brady
OpenEMR
mdsupport wrote on Wednesday, May 27, 2015:
Couch views can be constructed to be proxy for table indexes that make access comparable to RDB - views use same btree mechanism. By its nature, these are separate approaches to data management so depending on the bias one can claim ‘mySQL/Couch can do that’.
Consider MU reporting. Currently a process gathers related values in memory/temporary tables and performs summary calculations. In noSQL world, one would store the related data that forms basis of MU reporting in noSQL document. Off the cuff, that would probably mean a single document per encounter with all MU relevant items included from various forms and tables. In addition you can attach javascript logic to these records so only transformed values are indexed. Then to perform the summary calculations, the logic would be - get documents for 2014 xxx.a reporting and summarize. The documents also serve as a snapshot in case of audits since they should (or are not expected to) be changed online.