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

[Karsten Hilbert]

On Mon, Aug 11, 2008 at 10:44:34AM +0200, Jerzy Luszawski wrote:

> 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")
That will be improved.

> 3. Until the end of encounter its data should not be visible to anyone except 
> the author.
I don't think that's realistic:

- patient comes into exam room
- I take history
- patient is transferred to X ray, blood
  sampling, vitals monitoring
- after a while I go to the monitoring room
- I then of course want to see the history I took
  earlier and add vitals values and other findings
  within the same encounter

The encounter continues while I change machines, GNUmed
instances, shifts, nurses, ...

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

Being able to preview what is saved is entirely independant
of being able to create a comprehensive report.

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

> disadvantages:
> -panel (notebook) looses its autonomy, panel state ("dirty") must be handled 
> at higher level - GUI main level.
Wrong. The panel listens for signals.

> 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.
Wrong. It listens to signals. All signals to be listened to
are registered in one place per panel. It also listens to
signals from the backend regarding changes from elsewhere.

> -data are lost in case of GUI crash (this was an argument for "limbo" records)
well, yeah, but not necessarily

In many cases one can press "Continue" and try to save data.

> 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*)
> advantages:
> +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)

cross-session editing is possible with the above scenario,
too, even concurrent-session editing

> disadvantages:
> -records may be left in "limbo" state forever
This is something I should like to avoid at all costs.

> Posiibillity #3 (auditing): data are written to database, available to 
> everyone, changes are allowed and audited, changed field carries a flag 
> like 'has_history',
That flag is already there. It is called row_version. It is
just not passed through all the way to the GUI yet (except
for test results).

> and this history can be displayed on demand.
This needs some code to get written.

> 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

a) if large auditing tables area a concern they can be
   fanned out to other table spaces, they could also be dumped
   and cleaned out

b) it can be quite difficult to make the distinction between typo
   correction and semantic change

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