This is something that could be added to Couchdb weekly. Taken from the [email protected]
Begin forwarded message: > From: Albin Stigö <[email protected]> > Subject: Re: healthcare projects running on couched? > Date: 25 March 2014 at 11:54:33 AM SAST > To: "[email protected]" <[email protected]> > Reply-To: [email protected] > > 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
