Re: [Gnumed-devel] encounter edit before final save

[Jerzy Luszawski]

I spent a while considering encounter editing. That's what came to my mind:

ENCOUNTER CONCEPT (as I understand it):
1. During an encouter user can enter various data, what makes necessary to 
switch panels (notebook tabs) without closing the encounter. (it works 
already)
2. "Progress note" (SOAP) is the main type of entry in the encounter and there 
should be a way to edit it during any moment of encounter. (for now - only 
unless you  click "save")
3. Until the end of encounter its data should not be visible to anyone except 
the author. If the doctor didn't finish the encounter the data should be 
considered as not complete = not reliable. 
4. At the end of encounter physician should be able to preview all entered 
data before commiting changes to database, This way there is no need for 
auditing until encounter closing.
5. There should be a way to "continue" (=reopen for editing) encounter after 
closing it. This would trigger auditing and all changes would be written to 
history tables.

All this would require enclosing all encounter in one DB transaction. 
The important will be the ability to preview all data before actual write. 
After all, we should be able to create comprehensive report from a single 
encounter.

CHANGING ENCOUNTER DATA:
Possibility #1 (GUI) - current state: temporary values for progress note panel 
are stored *only* in front-end, and  preserved when user changes a panel 
(notebook tab). Data are stored in the database only after explicit "Save" 
command. Then nobody can change it. 
advantages:
+no temporary, unsigned records in database
+no data transfer between front-end and back-end
+currently there are panels where data entered in text fields are preserved 
(e.g. "Attach documents" panel - you can fill in the fields and not click 
anything, then switch to another panel and back - fields contents is 
preserved)
disadvantages:
-panel (notebook) looses its autonomy, panel state ("dirty") must be handled 
at higher level - GUI main level. This will require many events captured to 
trigger a dialog "save/discard entered data", eg. selecting new patient, 
encounter manipulation in EMR tree view, etc.
-data are lost in case of GUI crash (this was an argument for "limbo" records)

Possibility #2 (limbo): data are written to database as "limbo" records. These 
records are visible and editable *only* for the author. (see my previous post 
for some explanation why *only*)
disadvantages:
+flexibility - user can enter anything he wants, and check it later before 
signing-off
+possibility to edit data after logging-off and logging-in again 
(cross-session editing)
+reduction of stored audit entries (mentioned in old mail thread)
disadvantages:
- hard to force signing-off the data, must wait for next log-in of the author
-records may be left in "limbo" state forever

Posiibillity #3 (auditing): data are written to database, available to 
everyone, changes are allowed and audited, changed field carries a flag 
like 'has_history', and this history can be displayed on demand.
advantages:
+data are available immediately for all
+ability to see the history of changes may be itself valuable
+does not change current data entry method
disadvantages:
-possibly large auditing tables, storing every change, even typo corrections

The 3rd possibility is what I expected Gnumed to have when I started 
evaluating it, and I like it this way. I understand that data consistency has 
greatest priority, but then comfort of use is right behind. Blocking of data 
change is necessary as long as we have no auditing, but we have auditing 
(haven't we?).

Waiting for comments
Jerzy Luszawski