Re: [Gnumed-devel] Why is it I still can't reliably run gnuMed

[Karsten Hilbert]

On Mon, Aug 29, 2005 at 09:31:58AM +1000, Richard wrote:

> Before anyone says get again RTFM, I've intermittently tried to RTFM and 
> still 
> can't get it to work. I think it must be around both the fact that I run 
> wxPython2.6 and the unicode problem.
Most likely, yes.

> As I previously mentioned I'm more than happy to help point out where the 2.4 
> code is out of sync with 2.6 and help adjust this
good

> base again now because of error messages. When I did get it running I 
> couldn't enter patients through the add patient interface because of date 
> format problems so I gave up.
A bug in which has been fixed in the meantime and awaits
your testing again.

> I wonder if anyone is prepared to spend the time to help with this?
Yes.

> The above is partly true. The editing area is in reality no more than half a 
> dozen or more lines sitting on top of each other like lines on a page - ie 
> the physical design is not the feature.
Ah, good, I understood that much.

> The actual placement of the wigit 
> within an overall design per se is not the feature,
Good to know.

> although having a 
> consistent data input design would be unique amongst medical problems.
I agree. I always really liked the "structured" layout of
your design in which the edit area (not matter what it
currently edits) always lives in the same place. I for one
plan to eventually implement it that way.

> The distinguishing feature in reality of the editing area  is (and this has 
> not been implemented in gnuMEd) its functionality across all sections of 
> medical data input, as well described at www.gnumed.net/rterry/Index.htm.
I am not sure I fully understand. Are you saying that the
application of the same technique for creating an entry area
(the edit area, that is) is the distinguishing feature ? Eg
uniformity in "data entry dialogs" so the user knows what to
expect ?

> When 
> combined with the phrase wheel and it's learning abilities it adds up to an 
> easy to learn and quick to use system.
> 
> Unfortunately this has not been implemented in gnuMed.
I am not sure which part has not been implemented ? The
phrasewheels certainly *are* and they are working, too, as
has been demonstrated at the German conference. If I
interpret your message from one paragraph above correctly -
then you are right - uniformly applying the "edit area" has
not been implemented yet. The main reason being that that
would mean implementing the entirety of your integrated
design which proved too much work for the time being. I am
rehashing my argument here.

> with me - the gnuMEd core members have made all the classic mistakes of 
> program design - having no management structure, and not designing 
> functionality first, and back-end second.
That's interesting. I wonder what the heck OpenEHR is doing.
They better stop this useless modelling exercise right now
and rather whip up a good interface ? You got to be kidding,
Richard.

For one thing, designing the backend without regard for any
particular interface has allowed Syan to develop an
ever-so-rough PHP frontend - without requiring a single bit
of backend change (he found some bugs, though).

> What bits of the editing area and 
> latterly the SOAP editor (which Ian designed at my behest) have been 
> implemented, their functionality is much much worse than a couple of simple 
> free-text text boxes - ie good design has been degraded by a poor 
> implementation of a concept.
I hope you will comment again when you are able to actually
run the client you are commenting on. Until then I'll
refrain from replying.

> >From a programmatic point of view, because the editing area concept is 
> >generic 
> across all areas of data-input, if the underlying database has been designed 
> in concordance with this concept, then all the subroutines to call/display 
> data should also be the same
Bullshit. The middleware unifies access to the backend
(which, btw, also IS quite generically possible due to the
clin_root_item table). Also, the way the edit area code
stands right now it IS fairly generic. One doesn't design
the database to allow for uniform access. That's what
middleware is for. A database is designed for Good(tm)
storage of data. Nothing but.

> I've watched a  dozen or so medical software packages evolve in Australia 
> over 
> the last 20 years - all have gone down the path that gnuMed could have 
> avoided, but chose not to. Ie, they have had no overall functional design, 
> but have had one person's concept of what should be 'bolted' onto a basic 
> design screen. The end result of this process always will be problematic.
We have the design (yours). But we don't have the man power
to implement it as fast as some might wish.

We have yet to encounter any serious technical flaw
preventing us from proceeding as we wish. That time will
certainly come as it comes with ANY project. Designing the
data model first is precisely intended to not have one
design screen and bolt things onto that defining tables and
fields as you go.

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