gnumed-devel
[Top][All Lists]
Advanced

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

Re: Fwd: Re: [Gnumed-devel] GNUmed brochures (was When will GNUmed be re


From: Karsten Hilbert
Subject: Re: Fwd: Re: [Gnumed-devel] GNUmed brochures (was When will GNUmed be ready)
Date: Sat, 17 Dec 2005 10:10:27 +0100
User-agent: Mutt/1.5.11

On Sat, Dec 17, 2005 at 03:11:53PM +0800, Richard Hosking wrote:

> I find the code in Gnumed almost totally impenetrable
Richard, is there anything you would urgently need to be
documented for the code to become less impenetrable ? I can
document pretty much anything if you come up with what hints
you'd need.

> and I doubt I could add much 
> of value to the coding without fairly intensive direction.
No problem there. If I looked at KDE core code or the linux
kernel or BSD filesystem drivers I'd be totally lost, too.
Please do ask for help and directions right here on the
list. I'll be happy to answer any questions re
backend/client you may have. Only thing I'd ask for in
return is that you document in the Wiki what you learn from
it.

> I would not see Gnumed as a viable alternative in Australia in it's 
> current form
Definitely not, neither so here in Germany. Also,
"alternative" so much speaks of "competition". I don't see
competing as any of my interests. Hence my current goal
isn't replacement. It's cooperation which will undoubtedly
lead to replacement eventually whether I like it or not.

> - it needs accounting, a front desk module and prescribing.
Yep, pick any of them and start researching, planning,
proposing and coding.

> It will be difficult to produce the functionality of alternatives, so it 
> will have to offer something new to compete
Structured documentation is the big plus but most Drs don't
care to my experience.

> A proper robust database design
We are not too bad on that side I hope.

> and internet/network scalability are 
> other (major!) pluses, but most Drs would not necessarily see this as a 
> great advantage.
I agree.

> I think perhaps coding should stop and the "evaluation" part of the 
> cycle should be looked at
Coding for 0.2 doesn't need to stop for evaluation to start.
Just start evaluating and document what you find.

> - what do we (and other users) want?
We *know* what (some) users want:

- first we needed something that did demographics in a basic
  way and implemented what we are here for - a sane
  structured way of capturing clinical information of any
  kind -- we have that, it's called Release 0.1

- second we want to move the only reference installation of
  legacy GNUmed code onto mainline GNUmed code -- this is
  what 0.2 does - it merges the old document archive code
  into the current code base

- thirdly we have someone with a strong use case -- he needs
  to be able to handle lab data for a clinic -- so that's
  what 0.3 is planning to do

> Does the current software achieve this?
So far we are good in milestones.

> If not, what are the priorities and who will do the work?
I will, apparently no one else is interested in coding. The
priorities are as laid down in the Wiki in the RoadMap.

> By "management" of the project I would think we mean tracking this 
> process, and to certain extent directing (and assisting if necessary) 
> those interested to do certain tasks in a coordinated way
Please do start today doing so ! I'd love to see that burden
taken off me and/or Sebastian.

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]