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

[Tim Cook]

On Tue, 2005-06-14 at 14:28, 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, 

NOTE: I can only speak for TORCH 1.x I have no idea now what the
developers of TORCH 2.x are doing in the 1.5 years since I worked on it.

This situation is impossible in TORCH 1.x because the patient record
window in the browser carries the DOM ID of the patient record ID. 
Therefore only one open window for that record can exist on the machine
for any one browser profile (normal operation).  Multiple browser
profiles open equate to multiple machines (see below).

However, this behaviour was not true of IE (all the time)  This was only
one of the many issues that led me to state that Internet Explorer was
not supported as a client application for FreePM/TORCH.

> 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?

TORCH uses an object database so there isn't the concept of record
locking. With that said, there are multiple methods in play to prevent
data from being overwritten or lost in an update process.  First and
foremost is that from a design process the objects are very granular.
Secondly, because it is a stateless environment, whenever an object is
updated, it's previous state is compared to what is on disk to see if it
changed during the stateless period.  If it did then the commit fails
with an error and reloads the disk version.  You say WOW! I could lose
lots of data because everything I typed in is gone and must be
reentered.  

Well, this might be true but for these things.  As stated before each
object is very granular so only a small amount of data is contained in
one object.  Everytime an object is updated.  What really happens is
that a copy is created and saved with the new data. From the users view
point the data was updated.  The old version is flagged as having been
replaced but it is still very much available and the changes can
actually be rolled back.  Lastly, TORCH is designed so that for most
workflows in most clinics no two people would be required to be working
on the same data items ESPECIALLY at the same time.  

What you actually see on a screen is an aggregate of many objects.  My
primary reason for wanting to go to TORCH 2.x was that the design wasn't
granular enough for my tastes.  I hope the TORCH 2 team follows through
with that goal.

> 
> And a further question for the Web-based systems (ClearHealth,
> FreeMED,
> OpenEMR, TORCH): how do you ensure that the browser state is
> consistent
> with the database state if/when the user uses/abuses the browser
> navigation features (such as the browser back button or the browser
> history feature)? Do you maintain browser/database state consistency
> with all common browsers (we have found Opera to be particularly
> problematic in this respect).
> 

The only real solution I could come up with here is simply user
education.  The user has to understand the consequences of these
actions.  The best you can do here is to have the server force reloads
when the user goes back and then forward again (this is the most
dangerous thing to your data quality).  It certainly increases the
complexity of caching policies and slows the application down a bit but
there isn't much else you can do.  

Inside the actual EMR window I turned off the buttons and the right
click capability using javascript. But crafty users can still get around
these safeguards too.

TORCH 1.x isn't perfect, nor is it bullet proof.  But I do believe that
serious data integrity issues have been addressed and with proper
training and implementation the risk factors are manageable.

Regards,

  * -- 
    Tim Cook
    Key ID 0203DEEC @ http://www.keyserver.net & http://keyserver.mine.nu
    Get the key from: 
http://24.85.34.168:28080/Nikki_and_Tim/twcook_publickey.txt/file_view

signature.asc
Description: This is a digitally signed message part