[Gnumed-devel] Jims SOAP comments + Dr Messages+ Time Elapsed

[Richard Terry]

On Sat, 13 Nov 2004 04:23 am, J Busser wrote:
> Maybe what we want/need in the GUI in order to handle key needs
> *within* an encounter, are:
>
> re) what the patient was *expected" to want
> - this is just the "reason for encounter" (RFE)?
====================================
Yes, reason I elected Patient History was less text (not as wide on the GUI) 
but I guess one could use RFE.
===================================
>
> re) what the patient *actually* wanted
> - still just the RFE assuming we can revise, and append to it within
> the encounter
========================================
This is an interesting comment.

Dr: 'What can I do for you today'
Patient:' I've got this chest pain I"m worried about'
One of the things I often say to be patient is 'What do you want to get out of 
this consultation'.
Dr 'What really worries you about this cheset pain? 'What do you want to get 
out of this consultation'.

Patient:'Well, my uncle chest found out he had lung cancer, so I wan't to make 
sure I don't have it'.

Without the last piece of information, we can go through the consult - come to 
the end say with reaassurance that there is nothing serious, yet have not 
addressed the patients true reason for the encounter.

One of the things that interests me about medical records is actually 
research. The more we sub-split out such reasons the more interseting the 
potential research, but the more difficult for doc's to put in the info!!
=============================================
>
> re) what the doctor *planned* to do
> - must be able to see (and interact with) the scratch pad; a
> patient-specific to-do list, if it exists (and however it is
> populated)
>
> re) what the doctor *actually* does
> - the Plan including reference to education delivered within the
> encounter, instructions including any changes to the medication list,
> and any new actions / work generated including new prescriptions,
> requests, referrals, communications
>
> So is the GUI then determined by:
>
> 1. what we need to get patient-specific work done "inside" an
> encounter (the above), balanced against
> 2. what we still want to be able to see, and maybe interact with,
> that is *not* related to the encounter itself (maybe not even to that
> particular patient) even while we sit working with the patient
>
> I suggest to shift the focus of discussion temporarily to 2, because
> it is potentially briefer, and might have impact on 1, and then come
> back to 1.
>
> Could we agree that at the very *minimum* we must, while inside an
> encounter, preserve screen space to contain and keep in view a few
> things we must " juggle":

Jim can you email and elaborate separately on this. Love to go into it in 
detail right now am really pressed for time - (surgery starting soon), and 
trying to get through all my emails before starting (no mail at address@hidden)

>
> - for the active (current) patient, it could be the need to attend to
> things not strictly related to the encounter (maybe the to-do items
> or needs suggested by decision support if these are not fully evident
> inside the "encounter" module)

These are fully evident if someone would adopt my screen dumps (I re-attatch 
them again!!!!!!). The beauty of this GUI design is that whilst working on 
your SOAP stuff - the scratch pad, past meds, due/overdues and missing 
immunizations are hitting you in the eye. As a particulary nasty gui-hack- 
I've used the gimp in a couple of seconds to overlay my current preferred 
wxPython design ontop of my running-at-the-moment-patients-waiting VB Client! 
This should do everything you desired above.

>
> - and beyond current patient issues:
> -- to be aware how we are doing for time, at minimum to easily see
> the current time and at what time we have our next appointment,
> optionally time progress feedback like visit-elapsed vs

Great Idea - easy and takes up little space - I'll at it to the gui in 
wxPython later and post the result.

> visit-allocated time or thermometer [add to the version 2-3 to-do
> list?]
> -- a way for important notifications to not only jump up ("Dr X is on
> on line 2, shall I ask them to hold?") but to keep/assign a place for
> these items, after being acknowledged, to stay in view, even if it is
> only a small space, maybe softly blinking, until fully dismissed?

Another great idea - in fact - note in the gimp-hack - the missing 
immunisations showing - this in fact blinks on and off in my vb client. There 
is no reason why this immunisation method cannot be transferred to the 
overdues on the right, and any messages urgent for the doctor to see could be 
blinked in its place.

Thanks for the fabulous comments and ideas.

Regards

Richard

>
> If the above enough to decide, I can wiki it so we do not lose sight,
> and then we can identify more how to best capture within encounters
> what patients want, and what we do.
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

251gnumed_SOAP.png
Description: PNG image

composite_wxPython_DrsDesk.png
Description: PNG image