Re: [Gnumed-devel] further testing / bugs

[Hilmar Berger]

On Sun, 7 Aug 2005 20:35:45 +0200
Karsten Hilbert <address@hidden> wrote:

> 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.
So you say that you already planned to merge them, don't you :).


> 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").

> > 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.

> > 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.
Well, Richards design documents apply to Richards ideas but seem to be 
different from what is implemented in the EMR-tree/Progress notes.
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.

> > 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. There 
is overlapping functionality in two plugins, so better integrate them. 

> > 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. 
> 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.
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""

> > 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 ?
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.
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)

(BTW, Scott Berkun's "The art of project management" is a sometime enlightening 
book)

So what I'm missing is something like that:

Requirements:
- need to see a list of a) health issues b) episodes (connected to a) c) 
encounters...
- need to add new health issues, episodes, encounters
- need to del ....
- want to browse data connected to a,b,c,...
- want to enter new progress notes
- want to have an uptodate display, i.e. if other docs change patient, these 
changes should be reflected 

Design: 
- vertical split widget: left list of a,b,c; right medical data
- use tree widget to order a,b,c
- right-clicking tree elements for adding, deleting etc. items
- ....
- if possible: screenshot

Hilmar


--