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

[Karsten Hilbert]

On Thu, Nov 20, 2008 at 04:09:22PM -0800, Jim Busser wrote:

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

> We suffer a weakness right now in that 
> near-everyone who uses GNUmed uses it (I think) as a single individual. 
Yes, as far as I know.

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

Can you give a concrete example from GP land ?

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

This is nearly infinitely complex. I have been thinking
about this and it would surely be desirable (although it
might also conceptually change things -- would a read-only
chart access ever establish any encounter or not ?). I will
keep thinking and hope someone or me comes up with a good
technical solution.

Also, as long as it is undecided what IS the current
encounter GNUmed cannot take action based on that knowledge.

The first riddle to solve would be to define what a "chart
access" is, technically.

> 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?
correct

And, of course, those fields *are* populated from the status
of the current encounter.

Also, during patient activation the status of an unexpired
encounter IS shown - although you have asked for improved
display thereof. The template for that display currently is:

                msg = _(
                        '%s\n'
                        '\n'
                        "This patient's chart was worked on only recently:\n"
                        '\n'
                        ' %s  %s - %s  (%s)\n'
                        '\n'
                        ' Request: %s\n'
                        ' Outcome: %s\n'
                        '\n'
                        'Do you want to continue that consultation\n'
                        'or do you want to start a new one ?\n'
                ) % (
                        pat_str,
                        encounter['started'].strftime('%x').decode(enc),
                        encounter['started'].strftime('%H:%M'), 
encounter['last_affirmed'].strftime('%H:%M'),
                        encounter['l10n_type'],
                        gmTools.coalesce(encounter['reason_for_encounter'], 
_('none given')),
                        gmTools.coalesce(encounter['assessment_of_encounter'], 
_('none given')),
                )

So this provides the encounter details. You asked whether
the encounter details could be re-used for that. I think
that's a good idea (which needs some extra code, though) and
plan to implement it for 0.4, too.

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

Absolutely, within the new soap (currently-)creator(-only)
widget the displayed details of the current encounter can,
of course, be edited directly (and saved, for which the
"Save: [Encounter]" button exists)

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