Re: [Gnumed-devel] Storage and and representation (formatting?) of past history items

[James Busser]

> > a control ... expand all child items to X level.
> > ...at the level of the top-most item (the patient name which  
> > doubles as
> > the EMR menu) ... offer "Open all to..." and then a submenu "issue  
> > level
> > / episode level / encounter level". At successively more-deeply  
> > nested
> > levels of the tree (for example at the level of any one health  
> > issue) the
> > menu item would just say "Open to..." instead of "Open all to..."  
> > and the
> > options would be fewer.
>
> That is not a bad idea at all. I earmarked it for 0.2.9.
> ... what you might be arguing for is
> a "clinically_relevant" indicator at the episode level which
> defaults to false (because I don't want to see the umpteenth
> episode of lumbar pain or flu). With this the user can
> indicate that an episode remains relevant even if closed at
> a later time ?

I suggest that this contextual menu also include:

        Active (and/or relevant) problems <--- this would be the default
        All problems <-- would include the {inactive and not relevant} problems

and that the "not relevant" problems be de-emphasized... visually,  
would that be achieved by _italics_ (I say visually, despite knowing  
that normally _italics_ is used for emphasis?)

I cannot imagine anyone wishing to keep the wider setting (All  
problems) as they move to the next patient. It should be considered  
temporary and "revert" with the next patient search / activation to

        Active (and/or relevant) problems

> > This suggests to me that we may need a control
> > that will at least expand all child items to their first level.
> This can indeed be useful. What you might be arguing for is
> a "clinically_relevant" indicator at the episode level which
> defaults to false (because I don't want to see the umpteenth
> episode of lumbar pain or flu). With this the user can
> indicate that an episode remains relevant even if closed at
> a later time ?

Yes. Extraneous to free-standing episodes, but of interest to health  
issues, is the consideration of any interaction in levels of  
relevance. I think it is ok to let the episode have a relevance that  
is not linked to the parent issue relevance. In other words, making  
or keeping a new episode relevant does not force the issue to be made  
relevant:

- the episode (even if irrelevant) would --- during the time that it  
was Active --- force any parent issue to be kept in view in the EMR  
tree.
- the episode (when irrelevant to the long-term) would, upon closure,  
permit the immediate disappearance of any parent issue if the parent  
issue was also not relevant
- the episode may be marked relevant even for those problems (issues)  
not believed relevant to ongoing care *but* which may later have to  
be reconsidered, or at least reviewed... here, it would be helpful to  
filter-out trivial episodes while being able (via e.g. control-click)  
to temporarily display all episodes (even irrelevant) within the  
condition, in case it was mis-tagged or later became relevant.

> > Could/should such a control "live" in the right-click (control-click)
> > contextual menus that are already offered in the EMR tree?
> I'd think the "initial plugin" after a patient search such
> be much more tailored to quickly informing about the
> patient. It shouldn't be the EMR tree browser in the first
> place. But that widget hasn't been written yet :-)

Wish :-)