gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: [Bug 271185] [NEW] Data unsaved on switching patients


From: Karsten Hilbert
Subject: [Gnumed-devel] Re: [Bug 271185] [NEW] Data unsaved on switching patients
Date: Sun, 12 Oct 2008 12:56:01 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

> On Wed, Sep 17, 2008 at 05:09:40AM -0000, Jim Busser wrote:
> 
> > Upon creating a new patient, and Saving a progress note (despite that I
> > was prompted for, and provided, a "summary description" for a new
> > episode AND the episode was displayed as an Active problem in the left
> > of the Progress Notes editor and viewable in the EMR Journal, it was
> > somehow lost after (in the effort to create a new patient) I got
> > prompted again this time by a dialog
> > 
> >         edit encounter detail
> > 
> > for the patient I believed I had already left,
> 
> The user hasn't left the old patient. "In the effort to
> create a new patient" does not equal "after having created a
> new patient and activated that". The prompt occurs *just
> before* the new patient is activated. In the current code
> this is much more evident while previously it could at times
> happen when the new patient was already visible which is
> certainly confusing.
> 
> > and knowing I had made no
> > unsaved additions and figuring I had already saved what was needed, I
> > felt no need to save "again (?)" so I clicked Cancel.
> Well, it asked for *encounter* details.
> 
> > I now gather -- although this felt late to be asked -- that I was being
> > prompted to provide an AOE
> Correct.
> 
> > and as a result that I clicked "Cancel" the
> > whole note was *** lost **** !!!
> I will not believe this until knowing the steps to reproduce
> this behaviour. The note was saved in the backend long
> before the prompt even came up.
> 
> > First of all, I don't understand how it can happen that something not
> > yet committed can show up in the EMR tree and Journal (complete with
> > episode name) after I had clicked Save in the progress note...
> That is not possible.
> 
> > or is the
> > appearance of such things no guarantee that they had been written into
> > the database?
> To the contrary.
> 
> > Second, whatever the answer to the above, it seems a critical bug, no?
> The answer is that this is thought impossible to happen and
> considered as such until steps to reproduce it are provided.
> 
> > If a patient is activated
> > within the time limits of a recent encounter and the user had chosen to
> > continue the encounter, then even if the user only browsed the patient's
> > EMR and initiated no entries, so that there was not even anything in
> > draft form to have to save, any attempt to create a new patient (or, I
> > think, activate a different patient) brings up the prompt again
> > concerning the patient that is being *departed* asking whether to
> > continue the most recent consultation or start a new one.
> Well, the prompt logic does this:
> 
> - check whether or not to display the encounter editor AT ALL (option)
> - if current encounter has neither narrative nor docs: do not show editor
> - if AOE is not empty and duration is not zero: do not show editor
> - if no narrative (but docs) and empty AOE: set AOE to "only docs added" and 
> do not show editor
> - if empty AOE: string together episode description as AOE pre-set
> - show encounter details editor and let user decide what to do
> 
> It does not matter whether a previous encounter was
> continued or a new encounter was created. It all depends on
> the activity during the *whole* encounter.
> 
> > The original
> > purpose of the prompt was to prevent failure to save unsaved changes
> Wrong. That is a different prompt.
> 
> > but
> > it seems to jump up regardless. which is confusing. Also this dialog
> > says "Cancel" which does not cancel the attempted departure,
> Sure, because it is not intended to do that. Neither is it
> possible. It cancels editing the encounter details.
> 
> > it only
> > cancels the capture and saving of anything about the patient whose
> > context is being departed.
> wrong
> 
> > As already commented elsewhere we need a way to input visit Reason, AOE
> > and adjust Encounter type within the patient / encounter.
> 
> Either right-clicking the encounter from the tree or
> actually entering something into the abovementioned prompt
> dialog does exactly that.
> 
> Karsten

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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