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

[James Busser]

On 11-Aug-08, at 1:24 AM, Jerzy Luszawski wrote:

> The more likely scenario is that a patient comes in, the  
> consultation starts,
> then the patient is sent to, say, ECG or x-ray, in this time next  
> patients
> come in, then the first one returns, and the natural way would be to
> continue "paused" consultation. Of course you can have each  
> procedure as
> separate encounter: first part of the consultation, lab, radiology,  
> final
> part of thnue consultation,but this will make it difficult to  
> analyse all
> data as a whole, to generate a report from the consultation, and to  
> prepare
> billing data. This is my point of view. Other may have different  
> needs and
> different formal requirements to meet.

On the question of "caching" information prior to "finalizing" a  
note, we do not have any method presently available, other than to  
actually *write* the data into the back end.

As mentioned, only after an editing widget is written will it be  
possible to edit the note in order to "finalize" it, if it was not  
*already* final.

Even once an editing widget would be available, the first "writing"  
would serve a dual function of "caching" as well as serving as the  
"possible / assumed final". Only after a note would be edited would  
the note become "relatively more final". Since any note will have the  
capability to be corrected at a later date, we can never know that a  
note will never change, however that is no matter. All that is  
important to the person making the clinical decision is the state of  
the information at the time that the decision is being made.

What *appears* needed seems to be a workflow tool in which to  
distinguish, and be able to make selectively available, those notes  
that we knew were incomplete, from those notes that we believed  
complete.

This is sounding a lot like "you have unsigned lab results"

It sounds like people are arguing two levels of "save", one being  
"cache / keep this information" and the other being called by some  
"explicit save" by which they seem to mean "I am satisfied that this  
is now in a form that can stand as a record of this encounter". To  
me, this means the same as "sign" so we are potentially, in a multi- 
threaded (multi-issue) encounter, talking about

- Clear     vs     Save     vs      Save and Sign
        <the in-focus> issue SOAP note elements in this encounter, versus

- Clear     vs     Save     vs      Save and Sign
        <all> issue SOAP note elements in this encounter