gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: Gnumed-devel Digest, Vol 3, Issue 29


From: sjtan
Subject: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 3, Issue 29
Date: 25 Feb 2003 00:12:37 +1100

> 
> > The pessimistic approach is single write locking. 
> > Scenario is :
> > 1. one doctor opens a patient record, and gets a timestamped write lock.
> It shouldn't, with PostgreSQL.
You are assuming that a 2 tier system is always better than an N-tier
system. I take Horst's point that a 2 tier system retains the power of
SQL queries. 

> 
> > 2. another doctor tries to edit the same record and detects an active
> > write lock and is denied access.
> MVCC

What is the scope of transactions? 
For instance, is it at each page viewing change? What if there are 2
clinicians entering data and the scope of the transaction boundary is
patient wide, so that one clinician finishes his entry and then is
informed his update is aborted because MVCC detects that there is a
read-write write-read or write-write conflict.
  The cost of only using  MVCC is that you are not allowed to lose
transaction state on the client side; you are not allowed disconnected
or mobile operation, I think. 

> 
> > 5. another doctor which tries to access a record with a questionable
> > write lock is asked whether he should override the write lock. If yes,
> > then the write locked is lost.
> This is not available server-side and would thus have to be
> implemented on the client. Which is undesirable, particularly
> for locks.
> 
> > 6. The original writing doctor re-starts his client, which immediately
> > checks it still has write lock; because it has been retired, the client
> > regrettfully informs the doctor his session was lost.
> The restarted client would have to save elaborate connection
> state information to make sure it is working against the same
> set of databases as last time around.
> 
I don't understand that phrase 'same set of databases'. How does the set
of databases in use change ? 
The cPickling of Demographics was an experiment in having some client
side persistence. 
  A freeze and startup of a computer during a demographics entry
would not lose much if, the demographics record is sql inserted at the
start, and after each field is entered an sql update occurs, a
transaction would be one detail of the demographics. On restart, to
retrieve the same patient automatically, only the id of the patient
needs to be stored in a file. However, in this case, if the network
is congested, the entry into demographics will be slowed as each
field update must go across the network.

Another scenario is that there is a network failure or server failure,
during the day, but fortunately, the day's scheduled patient records
have been cached on the clients. Doctor's continue to see the patients,
but now everyone is forced to have only exclusive read-write access at
the patient record level. When the network is restarted, hopefully on
the same day and in a few hours, the entered data is batch entered onto
the server from every client, and since no one shares a patient record,
no conflicts can occur.  A similiar scenario could occur for mobile
computing. When a client is connected to the server, then MVCC applies.
When a client is disconnected, it uses the local cache, and other people
trying to access the patient record must be told someone has primary
update rights who is not connected and a restricted  level of access is
in force, or only read only access is allowed.
 

> I don't see this scenario happen in real life.
>
if you have MVCC( or transactions) at the table row level, (e.g
conflicts only occur if someone is editing the same drug or past history
item), you would probably have some sort of polling or callback to occur
so the changes made by one doctor around the same consultation time,
would be seen on the other doctor's screen.But you could also have
checking out for exclusive access or default exclusive access if the
application can know who is the primary updater. Other people are
allowed concurrent access , if the primary updater is not disconnected.
The system can know someone is disconnected or connected by polling as
mentioned before, or more complicated, callback.
Using postgresql doesn't mean you can't have local caching, you just 
have a more flexible consistency scheme.

        A real life scenario is mobile computing, and network or server
failure.    
 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Mon, 24 Feb 2003 10:57:56 +0100
> From: Karsten Hilbert <address@hidden>
> To: GNUmed list <address@hidden>
> Subject: Re: [Gnumed-devel] unsafe operations
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 5
> 
> Please keep posting to the gnu.org list.
> 
> > Is the meaning usafe for the patient, or medical legally unsafe for the
> > practitioner?
> Both.
> 
> > An example of usafe for the patient:
> 
> > - patient has obsolete address or phone number, and is uncontactable
> > after an abnormal result comes back.
> 
> 1) the patient has left, the result comes back, is associated
> with the patient's demographics which turn out to be wrong.
> This can happen if the patient changes place of residence
> without dutifully reporting that to his doctor. Unlikely,
> particularly since the patient will have left a forward-order
> with his erstwhile post office.
> 
The computer system can't enforce staff to check patient details are
current. It's probably not a computer problem. 

> 2) the request has left, the patient changes his demographics
> at the front desk and leaves, the result comes back and is
> associated with the updated demographics. Nothing goes wrong
> here.

> 
> 3) the result comes back while the patient is still changing
> his demographics at the front desk. the result is associated
> with the patient (and only on demand with his demographics
> [as, of course, in scenario 1 and 2]). Now either I notice the
> result and call the front desk to ask whether Mrs. Smith is
> still here so I can tell her about it in which case a change of
> demographics does not matter. Or she has now left in which
> case the new demographics will have been committed and any
> letters will go to the right place.
> 
> The only window for inconsistency would be if an incoming
> result triggers automatic notification of the patient while
> said patient is updating his demographics at the front desk.

> Here MVCC may send the letter to the wrong address.
> 
> > A system could contribute to this
> > problem if  a clinician or para-clinician enters a change in demographic
> > details , and believes the system has recorded the change , when in fact
> > it hasn't.
> This is a bug.
> 
> > - a clinician works part-time , or is away on holidays, and an urgent
> > abnormal result arrives electronically . The system could contribute to
> > the problem if  the sender of the message thinks the system has received
> > the message and recorded it , when in fact it hasn't. The system could
> > contribute to the problem if it advertises the ability to alert other
> > other parties , when it doesn't.
> Two more bugs. The second bug constitutes vaporware.
> 
> > - a system is supposed to keep a record of clinician entries , and no
> > lost updates should be allowed , especially in an environment where
> > there is more than one clinician involved in the management.
> 
> > No clinician should assume a system records all observations if in
> > fact it doesn't, especially in an environment where there is off-site record
> > keeping,
> I must admit I fail to understand the meaning in this that
> goes beyond the obvious. I particularly don't understand the
> connection with off-site record keeping.
> I'm thinking of someone who relies too much on the computer records,
and justifies not reading hand-written records because everyone is
supposed to come back and make entries into the computer system.

> > however one would like the system to record all data
> > aknowledged as recorded.
> 
> > There should also be no dirty reads, where
> > another clinician reads updates which later are aborted because of
> > system failure.
> Uhm, huh ??
> 
> What I read from the database has been committed. It can only
> vanish through direct deletion (which we disallow by
> update-only triggers) or disk drive hardware failure (which we
> better guard against with RAID and backups).
> 
I'm trying to work out why you think local caching won't work. I'm
assuming it violates ACID in some way; local caching might violate
durability of updates, if no extra-ordinary exclusive locking is
allowed.

> > - if each field of the record system is allowed to insert into the
> > database as it changes, then transaction boundaries have to be
> > maintained.
> They are to be maintained. Anything else clearly is a bug.
> 
> > A record system which commits only at the end of an entry
> > session can still be compatible with client restarts , assuming that a
> > transaction start and end  only occurs at the end of a session.
> > Exclusive read-write locks , also prevent someone else reading obsolete
> > information whilst a record is being made during a long session. 
> Well, one could also argue that information only becomes
> obsolete the moment it is known to be obsolete. The
> non-obvious part in this statement: This happens at different
> times for different clients. She who enters the new
> information knows of it earlier than she who uses the
> still-current data in the database. Tough luck. In cases where
> incoming results are crucial the clinician(s) will poll for
> their arrival due to medical diligence anyways.
> 
> >     On the other hand, read only access could be allowed for others who
> > have not opened the clinical record for writing, as long as it was made
> > clear  to the reader that someone else has it open, and updates are
> > pending and occur only  when the record is 'returned'.
> I do not believe in the scenario "me have the record now and will
> return it all new tomorrow evening".
> 
> > Demographic information could have a separate transaction boundary to 
> > clinical information, which would allow e.g. the front desk to update
> > the record whilst the clinician is updating the clinical record.
> Uhm, aren't we aiming for BEGIN..COMMIT/ROLLBACK cycles much
> smaller than this ?
> 
> > However, if any action that depends on demographic information is
> > attempted, the clinician could be blocked from doing that action until a
> > pending update to demographics occurs.
> Like what ?
> 
> > If a clinician executes an action
> > that depends on demographic information, and another staff updates  the
> > demographic information LATER within a reasonable time after the
> > demographic-dependent action, then all system users should be alerted to
> I guess not.
> 
> > If this is detected after the patient leaves, then several remedial
> > actions could be taken: 
> > in case of referral or test ordering,
> You mean, like, me referring a patient to, say, to neurology
> assessment AFTER the patient left ?? Surely I would have
> talked this over with the patient and told him to wait for the
> referral note at the front desk. If the patient then leaves
> without it (that DOES happen) -- tough luck. I jot down a
> short blurb to that effect in my notes.
> 
> > Failure and re-start of clients shouldn't be such a problem if
> > transactions don't start at the start of a consultation , but start and
> > begin when the consultation is ending, and the clinician is mindful that
> Uh, no. My patients regularly forget what I told them when to
> come back on the way to the front desk (about 10 meters through
> 2 doors). If so the staff looks up what I wrote down in the
> notes. I may not have finished entering other things.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 

Ok , now I think the issue is , can this system have flexible
transaction boundaries ?
If no, transactions are row or field level, then everyone HAS to be
connected to have a useful client and have to tolerate congested
networks, but there is no  need for local caching for client's freezing
and manually restarting. The client only needs to remember what state
the ui is in ( which page and which patient it was looking at), 
and everything is reloaded from the server like a good thin client does.
So no cPickling needed , (not at this stage anyway)?



 
> ------------------------------
> 
> Date: Mon, 24 Feb 2003 11:23:10 +0100
> From: Karsten Hilbert <address@hidden>
> To: GNUmed list <address@hidden>
> Subject: Re: [Fwd: Re: [Gnumed-devel] I hope this gets through]
> Message-ID: <address@hidden>
> In-Reply-To: <address@hidden>
> References: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 6
> 
> Syan,
> 
> please post to the gnu.org list.
> 
> >     handler_editarea_impl contains the actual extra behaviour, such
> > as popping up lists based on the terms entered.
> How about trying to improve the phrase wheel widget ?
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> ------------------------------
> 
> Date: Mon, 24 Feb 2003 11:18:14 +0100
> From: Karsten Hilbert <address@hidden>
> To: GNUmed list <address@hidden>
> Subject: [Gnumed-devel] first clinical part - social history
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 7
> 
> Richard and I have agreed to start developing and testing the
> waters for a clinical module. We sort of settled on Social
> History as this requires hardly any outside preconditions.
> We'll work ourselves up from there.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

I gather the handler collaboration is still unpopular,
because it seems to only update non-persistent dictionary objects
stored in lists. What about the multi -level undo feature? 

 I think people are wanting something like:

the clear button inserts a new empty row into a corresponding
table (or view). Each lost focus of each text element causes
an update of the corresponding field in the table row. 
Pressing ok may change a 'active' field in the row, or move
that row from a temporary table to the actual table.
Pressing the clear button either leaves the row's field
forever inactive, or that row is deleted from the table.

All the lists are regularly polling with select statements
to get the particular list for the patient, so any cocurrent
entries from other users are detected. 

Double clicking the a row in a list view, moves the key 
into the editarea , which then sql selects the data and
loads the editarea.

To be able to cancel changes made between loading an editarea
and pressing the clear button, the editarea needs to
remember the original data that was loaded when double-clicking
on the list,  so that cancelling changes by
clearing data which has a key to an active row in the table
means sql updating that row with the original stored old field values
to cancel out all the changes made as each field lost focus.













reply via email to

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