Thanks for all the replies, it seems couchdb is already used in many medical systems around the globe. I took the liberty to provide a summery.
The reasons I think couchdb is an interesting fit are; from my developer point of view: 1. Relative ease of delpoyment, clean implementation, proven platform (erlang). Relativley simple configuration. 2. Easy synchronization let's you work without a single point of failure, spotty connections, in p2p configuration. Easy backups. 3. Ready for mobile (did I mention spotty connectinos in the hospital basement?) 4. Attachments (there are always scans, photos etc) 5. Changes streams provide easy notifications when something changed, new test results arrived etc. This is very convenient. Regarding conflict management, this is both and issue and a none issue. It has happened to me some times as a physician that I have experienced "conflicts" and that my changes were just overwritten by someone else (gasp). If there's a conflict both version always need to be saved. In medical records you never really delete or change anything, you make additions. Like a ledger. >From my physician point of view (and what I know my colleagues think): 1. It should just work, right away. When I push the button it should be saved. Physicians are used to eventual consistency because we dictate a lot and it was previously transcribed my secretaries so it didn't appear right away anyway. But we could be sure it would. No locks. NO LOCKS!!! 2. Maximize uptime (by using a p2p you have a redundant system) 3. When new data arrives the screen should updated automatically. --Albin Links provided in earlier replies: http://www.4medica.com Are aware of couchdb but we don't know to what extent they use it. http://www.commcarehq.org/home/ Their backend is couchdb. http://www.mobiusmed.com/ Use it as a backing store for at least two products. http://neurofoundation.in Use it as their backend for their EMR system. https://iilab.org Not sure how they use couchdb. On Tue, Mar 25, 2014 at 12:47 AM, Jens Alfke <[email protected]> wrote: > > On Mar 24, 2014, at 10:10 AM, אורן שני <[email protected]> wrote: > >> How abiut couchDB's conflict resoloution mechanism vs SQL DB's using locks. >> Do you think that is a major concideration? > > You can’t use locking in a widely-distributed system, or one client > forgetting to release a lock would block everyone else (either forever or > until the lease runs out.) It also makes offline updates impossible. > > I’ve heard of relational-db-based systems that do replication, but they don’t > attempt to propagate locks. Instead they do conflict resolution during > replication the same way CouchDB does. > > —Jens
