Re: [Gnumed-devel] improved soap notes creator screenshot

[James Busser]

On 19-Nov-08, at 3:53 PM, Karsten Hilbert wrote:

> The display of "recent notes" is now actually dynamic
> depending on the episode for which a progress note is
> currently created. The displayed recent notes contain soap
> lines from the current and the previous encounter, if any.
>
> Note that recency is only determined by chronological
> sequentiality. There is no inherent "timeout" as to what is
> "recent". Should "recent" actually be "latest" or "last" or
> something to that effect ? If so, what ?

Before I try to answer the above, can we review what it is that we  
would like redesigned in notes?

I seem to recall, as an important needed improvement, the need to  
make more visually accessible the state -- and the detail -- of the  
most recent and current encounter. We suffer a weakness right now in  
that near-everyone who uses GNUmed uses it (I think) as a single  
individual. In practice, when a patient is selected whose last  
encounter was not beyond its expiry, the requesting user cannot know  
whether or not the unexpired encounter ought to be extended since the  
unexpired encounter could be something new and unrelated to their  
last contact with the patient.

In place of making the user decide, can the question of what to do  
with the unexpired encounter be postponed, such that the software  
simply takes note that the patient's record is (thus far) only being  
"read", until the user would do something that would require a  
"write"? Only then, for example if the user were to add or alter  
demographic information, or attach or sign imported documents or  
labs, or create progress notes, that the question would need to be  
answered?

To assist the user in this, can the status of a patient's most recent  
encounter be more easily shown? I am thinking that in the case where  
the most recent encounter is unexpired, its information can be  
displayed populating the fields Encounter (in Praxis), <datetime>  
until <datetime>, Request (the reason for the encounter) and the  
Summary field which -- do I gather correctly -- is the AOE? Providing  
this information would help the user better determine whether this is  
an encounter that they wish to extend, or end (by "Saving"?) in order  
to start a new one.

If the above makes sense, would the values for the Encounter type and  
the Request/Reason (RFE) and the Summary (AOE) be able to be updated  
by the user, which I guess would be our first, partial implementation  
of future-auditable-editing?