gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] further testing / bugs


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] further testing / bugs
Date: Sun, 7 Aug 2005 20:35:45 +0200
User-agent: Mutt/1.5.9i

On Sun, Aug 07, 2005 at 02:03:56PM +0200, Hilmar Berger wrote:

> Last but not least I still fail to understand why there
> are two almost similiar plugins (EMR-tree, progress notes)
> that both show a list or tree of health issues/episodes and
> offer different functionality.
Well on the surface the answer is that - guess what - they
provide different functionality - just as you say. That begs
the question why this functionality needs to be in two
different plugins. The answer to that is that no one got
around to eventually merge them.

Initially Carlos' EMR browser included ADD functionality.
The complexity got out of hand. We ditched ADD for the time
being. We then moved to Richards notebook idea instead of
the sash idea for adding progress notes. That brought the
complexity down to a manageable scope. We didn't re-merge
the concepts due to not getting around to it. However, the
plan for the progress note input plugin includes "make the
active problem list a proper tree" at which point merging
just may become more obvious.

However, the tree lists *all* the health issues/episodes
while the active problem list only includes those that are
considered, well, active problems.

> For instance to add a new
> health issue ...  you have to go to the EMR-browser
Wrong. You can simply do it from within the progress note
input with the help of an active keyword. Simply type "ea:"
(or "phx" for those non-German speaking people). Those
keywords will eventually be configurable. Config support is
there it just lacks glue.

> or to reorganize the assignation of episodes to
> health issues you have to go to the EMR-browser
Well, if you want to reorganize the EMR you most likely want
to see the entire EMR and not just the active problems thereof.

> but if you want to add a new episode you must use the
> "progress notes" plugin.
We simply decided to not waste time on convenient but
redundant functionality yet. However, stubs for adding that
to the EMR browser tree episode context menu are there
already.

> I don't find this design very intuitive.
Feel free to help 0.2 to succeed in much improving upon it.

> What is even worse that there seems to be no design document
> in the wiki or anywhere else
There are quite detailed design documents written by
Richard. There are even more on the web, even in German.

> so I couldn't find any explanation why we must have these
> two plugins where one would be sufficent.
There is not explanation because there is no definite
reason. The reason is that it Just Is. In that sense it's
Zen.  May I ask back what makes you think that "one would be
sufficient" ?

> In addition, I can't find any design concepts for the rest
> of the medical functionality gnumed claims to offer in the
> future.
Richard wrote a detailed description of his design. However,
there are no documents discussing why things should be the
way they are or how they should be *AND WHY*. Likely such
documents would be fairly first-of-their-kind. Up to now we
(I) have drawn upon a) actual experience from daily practice
and b) the things that we *dis*like in our daily dealings
with existing software.

> There are screenshots that describe Richards
> "unified entry area" concept which seems to be deprecated or
> at least has almost no relation to what is functional right
> now.
Actually, the past history item input widget is generated
using the very same code that can generate edit areas. A
vaccination edit area is functional but did not make it into
0.1.

I must admit that I misunderstood the distinguishing feature
of the edit area concept for a long time. Maybe I still am.
Maybe Richard can correct me on the following:

The advantage of the edit area not so much lies in the
widget itself but rather in it's consistent *placement*
within Richard's general design and it's *fairly*
consistent line-by-line layout. Over and above that it's
just a strict application of principles such as input
validation, coloring and phrasewheel use.

> So, what are the design concepts for some of the existing
> and most of the missing parts ?
What level of design concept are you talking about ? Can you
give an example of what you would expect in such a document ?

Pick *one* function point and I'll happily discuss *my*
ideas of how it should work and why. We could then distill
that into a design document.

Thanks a lot for the bug reports BTW !

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]