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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
