Re: [Gnumed-devel] need-to-know change to backend

[Richard Terry]

See my comments below:

On Sun, 14 Nov 2004 12:23 pm, Karsten Hilbert wrote:
> Jim,
>
> I like the way you are spelling out the things that have been
> inherent in our discussion. This leads to greater clarity (and
> is a helpful consultation tool, too - paraphrasing the
> patient's communications to establish rapport).
>
> > I am just thinking that during the process of history taking, it is
> > important to keep somewhere on screen the past history (well, the
> > *pertinent* portions of the past history)
>
> Ah, got you.

Not possible with the constraints of real-estate. You need to trade of utility 
with getting screens to crammed: For a rather extreme example of what happens 
when you try and fit everything into the one screen area see the tkpf EMR 
project screenshots:

http://tkfp.sourceforge.net/index.php?type=Screenshots&cat=8

I find in clinically practice one does not often refer to past history in 
current consultations. When one does I either flick to my past history 
section, or the summary screen.

Using the central area of the screen one can easily overly the whole area with 
the PH or progress notes at the click of a toolbar button.

Regards

Richard


> One way to do that would be with the tree control: open the
> portions of the EMR you need in view. It's a bit like a
> chronological dump of the EMR that Richard recently posted as
> PNG - except that it is active in that one can a) hide
> portions or levels of the tree that aren't wanted to be seen
> at the moment.
>
> Another possibility would be to have a simple scrollable view
> of what plain text (later HTML) Carlos' EMR exporter produces.
>
> > i.e. the problem list which
> > AFAICT we are taking to be a view over issues and episodes,
> > selectable by is_active and clinically_relevant
>
> Yet another (more selective) option would be to display just
> the list of problems above the (single) SOAP widget with
> problems numbered so in the SOAP widget portions can be
> attributed to the pertinent problem (or a new one created by a
> shortcut).
>
> > Even if the doctor decides it is too early to commit a link to a
> > suspected cause, awareness of the possibility can guide tests and/or
> > a trial of therapy.
>
> Surely so.
>
> > Also needed to guide the visit are the ability to see (or easily
> > bring into view, this is part of the debate needed) some of the
> > things I recently listed i.e. the scratchpad, any to-do list,
> > medications which may expire or need to be changed, as-yet unactioned
> > abnormal labs as well as (external to the current patient) other
> > high-priority, time-sensitive tasks the doctor must get done.
>
> No question about that. Richard has that all figured out (at
> least one version thereof) in his design.
>
> Karsten