couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Fwd: healthcare projects running on couched?
Date Tue, 25 Mar 2014 10:13:45 GMT
This is something that could be added to Couchdb weekly. Taken from the user@couchdb.apache.org

Begin forwarded message:

> From: Albin Stigö <albin.stigo@gmail.com>
> Subject: Re: healthcare projects running on couched?
> Date: 25 March 2014 at 11:54:33 AM SAST
> To: "user@couchdb.apache.org" <user@couchdb.apache.org>
> Reply-To: user@couchdb.apache.org
> 
> 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 <jens@couchbase.com> wrote:
>> 
>> On Mar 24, 2014, at 10:10 AM, אורן שני <orenshani7@gmail.com> 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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message