[Gnumed-devel] Re: [openhealth] Consolidation Proposal: ClearHealth, FreeMED and OpenEMR

[Tim.Churches]

Karsten Hilbert wrote:
> 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?
> GNUmed:
> 
> 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.

Yup, all of the foregoing is exactly the approach that is need. We also
provided for this in our middleware, but have not enabled it NetEpi Case
Manager because we have not had time to build a user interface to allow
the user to resolve such issues. It's not enough to tell them "Nope,
can't save your record because someone else has edited it in the
meantime." - the application needs to provide the user with an interface
 for comparing those edits by the other party with their own and
deciding how to merge the two sets of edits. Building a generalised,
easy-to-use interface to do that in a Web app is not trivial, so we put
it on the To-Do list. Also, we don't expect that simultaneous edits of a
record/object will be a common occurence in typical use of NetEpi, but
we have no doubt that it will occur sometimes. In a clinical situation,
I expect it would occur often.

Tim C