Re: [Gnumed-devel] further testing / bugs

[Karsten Hilbert]

On Mon, Aug 08, 2005 at 09:12:29PM +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.
> So you say that you already planned to merge them, don't you :).
Absolutely. Richard's design (among others) is much better
and I'd like to eventually work towards it. For 0.1 it
appeared, however, way to integrated to allow us to "finish"
"on time".

> > However, the tree lists *all* the health issues/episodes
> > while the active problem list only includes those that are
> > considered, well, active problems.
> Which means that one displays a subset of the other -
> which IMHO could well be handled by a filter ("Display
> active" vs. "Display all").
Not only that. The true story goes much deeper.

The *real* shortcoming of the current EMR browser is that it
allows display of the clinical data for one single encounter
only at any one time !  However, we would want data from
several encounters displayed at once *filtered* by, say,
episode or health issue.

The second shortcoming is that it's hierarchy is fixed. It's
useful to study a patient's history *by affliction*. It is
NOT suited to study patient history by *care given over
time*. The latter is at least as much needed as the first.

The *real* reason for the current EMR tree browser to exist
is to have *something* that a) allows for *reasonably* well
structured browsing of the EMR and b) clearly demonstrates
how it can be useful to document in encounters/episodes AT
ALL.

I think within the constraints of 0.1 it's well worth its
shortcomings. The plausible promise Tim spoke of.

> > > 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.
> Well, that's something I didn't find in the docs.
Hehe :-)  It ain't particularly documented yet. It will be
in 0.2 where it is going to be an officially supported
feature.

> The german docs (as far as I remember) describe the
> requirements part of the specs. IMHO they do not describe
> how you plan to implement them in Gnumed in detail.
True.

> > > so I couldn't find any explanation why we must have these
> > > two plugins where one would be sufficent.
> > Zen.  May I ask back what makes you think that "one would be
> > sufficient" ?
> Well, you sort of confessed that you already thought about merging them.
I did. Nevertheless merging them is less trivial than
you might think.

> There is overlapping functionality in two plugins, so better integrate them.
Cars don't have the gas pedal right inside the tachometer
either so the above is not a sufficient(ly thought through)
reason.

> > > 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,
> ... which seems to be different from the design we are following right now, 
> at least the design of his modules do no resemble EMR-tree/progress notes.
Well, the top panel is pretty much taken from his design.
Also the past history item entry widgets stems from his
design (more importantly its code is structured
*conceptually along his design). I agree it is an imperfect
and ugly implementation thereof.

> I was thinking in something like a listing of requirements and the way you 
> want to implement them.
> E.g. "need to have a list of health issues and episodes" -> "use a tree-like 
> structure""
Oh, I see.

> 1. Requirements (module-wise or even unordered list).
> These should not contain any tech-speak, just plain english
> descriptions of what a medical doctor wants to see/do.
Those already exist on the web.

> 2. Design document: How we are going to implement the requirements in Gnumed. 
> Here we have to 
> a) group requirements to find out what modules should hold which 
> items/functionality. 
> b) describe every module and its planned front-end functionality (which item 
> we want to implement in which form (button,list, tree, entry field ...), 
> style, place, ... Here non-functional prototypes and screenshots thereof are 
> a good idea.
> c) if necessary describe back-end/middleware functionality needed for b)
I agree this would be very useful. It took GNUmed nearly 5
years to reach a releasable, working state. I hear you
say about "*we* want to implement" ?

I have three day jobs. And I have a life, too.

> (BTW, Scott Berkun's "The art of project management" is a sometime 
> enlightening book)
I wish I had time to read it or even apply it. Notice how I
have previously asked on the list for help with precisely
such matters.

BTW, anyone bothered to work on

 http://salaam.homeunix.com/twiki/bin/view/Gnumed/RoadMap

?

> So what I'm missing is something like that:
> ...
Sounds all good and fair. How about we start putting
together such a thing for 0.2 right now ?

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