Data unsaved on switching patients

Bug #271185 reported by Jim Busser
2
Affects Status Importance Assigned to Milestone
GNUmed
Fix Released
High
ncq

Bug Description

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, 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.

I now gather -- although this felt late to be asked -- that I was being prompted to provide an AOE and as a result that I clicked "Cancel" the whole note was *** lost **** !!!

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... or is the appearance of such things no guarantee that they had been written into the database?

Second, whatever the answer to the above, it seems a critical bug, no?

Third, we may as well fix this annoying work flow about the AOE. Even without data loss the behaviour is annoying. 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. The original purpose of the prompt was to prevent failure to save unsaved changes but it seems to jump up regardless. which is confusing. Also this dialog says "Cancel" which does not cancel the attempted departure, it only cancels the capture and saving of anything about the patient whose context is being departed.

As already commented elsewhere we need a way to input visit Reason, AOE and adjust Encounter type within the patient / encounter.

Jim Busser (jbusser)
Changed in gnumed:
importance: Undecided → High
Revision history for this message
ncq (karsten-hilbert) wrote : Re: [Bug 271185] [NEW] Data unsaved on switching patients
Download full text (4.1 KiB)

> 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 enco...

Read more...

Revision history for this message
ncq (karsten-hilbert) wrote :

1) the perceived bug "loss of data"

That seems to have come from the confusing workflow. Any similar actual data loss has
never been reported by any of our long term users.

2) the confusing workflow

This is believed to have been fixed. Please re-test with 0.4.

Changed in gnumed:
assignee: nobody → karsten-hilbert
status: New → Fix Committed
ncq (karsten-hilbert)
Changed in gnumed:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.