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

[James Busser]

On 8-Aug-08, at 2:51 PM, Karsten Hilbert wrote:
> On Fri, Aug 08, 2008 at 06:13:30PM -0300, Rogerio Luz wrote:
>
> > - the impossibility to edit anything after it is done but BEFORE I  
> > close the
> > consult
> I expect this to be improved in 0.4 which will let you edit
> the current encounter (your own notes in it, that is).



On 8-Aug-08, at 4:02 PM, Jerzy Luszawski wrote:
> For now - it is almost unusable for me and my friends

> Karsten - would be it much work if you were to change it?



Both of the above are important considerations. Can the challenges be  
broken down for better understanding?

Currently, encounter information alterable only while it is in  
memory, correct?

Perhaps it is a concern that as soon as any data is written into the  
backend database, the data may become immediately accessible to other  
providers and that if a decision were made on information that  
instants later got changed, it may be important for the person who  
made the decision (based on information which had changed) to  
reconstruct what had happened, which GNUmed does not yet assist?

The ability of providers to see information prematurely places them  
at risk of making a decision on information regarded by the creator  
as only at a "draft" (unverified) state of clinical reliability.

So maybe the first question is whether we need a control step  
interposed, in which something would only *normally* become visible  
after it has been signed, but could *optionally* be made visible if  
the interested provider would unfilter the default.

Do we have agreement that it must at least always be very clear, to  
every provider when viewing information, if notes/entries cannot yet  
be regarded as "signed", even to the extent of hiding unsigned  
entries but with the option to unhide them?

Overlapping the above is the concept of "limbo" entries which AFAIK  
has not yet been agreed, and therefore not yet incorporated into the  
schema design nor software:
        http://lists.gnu.org/archive/html/gnumed-devel/2003-01/msg00133.html

If I understand the above correctly, the limbo flag would subvert the  
audit system until such time as set to unlimbo after which control by  
the audit system becomes non-optional (not possible)?

In the meantime, pending any agreement and deployment of limbo  
support, is the obstacle to editing (auditing) any belief that the  
ability to audit must be accompanied by the ability to view the audit  
trail, which would take extra time to develop?