On Thu, May 26, 2005 at 11:36:35PM +0200, Hilmar Berger wrote: > I tried to figure out what has to be done before 0.1 by > looking at the TODO file, but couldn't find out which tasks are > before and which post 0.1 - we will have to update this file > once we will have decided on the functionality we want to > provide. The TODO *file* in CVS is basically *all* post-0.1. The Wiki has the TODO for pre-0.1.
> I looked at the modules that will go in 0.1 - and I am still > not quite sure what we will show Well, that is a list of functionality. It doesn't spell out how it's being done. The status quo of "Release 0.1" is how it's going to be done if you ask me. > and if these modules (Manual, > EMR-tree, EMR-journal, Setup, Patient Details and Progress > Notes) are in a presentable state. You can find that out by running the Release condidate. > Manual: > This is quite outdated. Should we update it before the > release of 0.1 or rather link to the wiki ? Or even provide a > local copy of the wiki in the release package ? Yes either way. > EMR-tree / EMR- journal: These plugins show the same > information, just the structure is different. Wouldn't it make > sense to combine both in one plugin ? Not now anymore IMO. > Patient Details: This seems to do nothing but display patient > data (i.e. Add/Del-Buttons do nothing). On the other hand you > can register new patients from the menu bar. Why this > separation ? because it's a different kind of task > Why not connect the code that adds a new patient > to the Patient Details page ?? the patient details page that used to be there isn't loaded in the Release configuration anymore, we load Carlos' notebook version now > Progress Notes: Since the entry field below the notebook > label seems to be for entering the Episode Name, I suggest to > put a label there that says "Episode name:". Correct, that's a TODO. > My impression is that we need to review the feature list > first. I'am *not* suggesting to add new functionality or more > modules. I just had the feeling that the way the functionality > is implemented right now might not attract many persons. Even > if 0.1 is just a first release, it should show the *concepts* > of the software. What Gnumed shows right now is less than > showing even a consistent concept (duplicated functionality > etc.). We've had at least two years for doing so. No one has done it. There is not any duplicated functionality that I can see. What we've got now i a working candidate of acceptable consistency. I should like to know about grave problems right away. But 0.1 needs to be out very soon. > IMHO the users should get an idea of what Gnumed might be > like - and this impression should be positive. We've had enough time to let users know what it might be like. Our task of today is to give them GNUmed in a way that it IS like. Which doesn't mean it has to *stay* that way at all. > So, here are my suggestions: > - fix the specs for 0.1 so that it shows how a potential user > might work with gnumed. This includes a consistent concept and > workflow Feel free to make specific suggestions. Notice how the manual in the Wiki does list how a potential user might work with GNUmed. It is also quite apparent you have not worked in a medical practice in the community. I have. And I have using GNUmed (at it's current potential) - with real life data and not fooling around. > - fix and subsequently freeze the data model (backend) Feel free to suggest things that need fixing. What deficiencies do you see that are relevant ot 0.1 ? > - fix middleware/user interface Feel free to suggest or preferably act on specific things that need fixing. What makes you think they need fixing ? > - write a basic user guide describing the concept and typical workflow within > gnumed feel free to go ahead Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
