[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: [openhealth] Consolidation Proposal: ClearHealth, Fr

From: Karsten Hilbert
Subject: [Gnumed-devel] Re: [openhealth] Consolidation Proposal: ClearHealth, FreeMED and OpenEMR
Date: Wed, 15 Jun 2005 17:50:05 +0200
User-agent: Mutt/

On Wed, Jun 15, 2005 at 07:28:27AM +1000, Tim.Churches wrote:

> Here is a related question: how do each of these systems (ClearHealth,
> FreeMED, OpenEMR, TORCH, GNUmed) handle the situation in which the same
> patient record is opened (for update) in multiple browser windows (or
> tabs, or multiple clinet sessions in teh case of GNUmed), either on the
> same machine, or on different machines (eg in a clinic with several
> special-purpose rooms, where patients move from one room to the next)?
> In other words, how does each system handle record locking and multiple
> updates?

Our middleware handles exactly that problem. When you attempt
to write to a part of the medical record that is currently
locked by another user (eg a clinical narrative row or a
vaccination entry) the middleware detects this. We use
"transaction isolation level serializable" and "select for
update". If you attempt to write data to a part of the medical
record that was *modified/deleted* by another user *in the
meantime* this is also detected by the middleware.

In both cases the user can be notified. All of a) the original
data, b) the locally modified data, and c) the current data in
the database are available for display/merging/rollback.

Oh, and we have a) test code provoking those cases and b) a
torture test where we can simulate a couple of people doing
continuous changes to the same database object with random
delays built in such that we can detect corner cases. All of
this is in CVS.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]