Syan Tan wrote: > > since gnumed is more than half built, largely by karsten, may be > backpeddling to requirements documentation > > is too early in the spiral ; the first cycle of the spiral process isn't > quite finished ( or the second ) , and I think > > requirements documentation can go into the next cycle. despite some > people hating the most popular emr in oz, For a reason! The worse we can do without a plan will still be better,no need to 'emulate'
> are "reinventing the wheel" ; no one has a copyright on tabs, lists, > popup menus etc If the GUI looks too similar, the hydrogen cyanide company *will* come after you. > - wrt to a unified clin_medications , only if everyone wants one ; > otherwise why not reinvent it several times depending on locality? > > it would be a lot quicker , and Karsten doesn't mind, ( he just won't > use it , and can market his own later, if he wishes). I suppose so. > - with respect to a clone, instead of mass transfering from one emr to > another, > you could write a frontend that calls an intermediate backend that calls > gnumed backend , and one that reads/updates > the original backend ( the file format doesn't seem to be too difficult > ). This way, you could maintain the original backend > , reverting to it with the updated data if needed, wean people onto > gnumed, and leech the data into a gnumed database. 99.9% of the reason why we are all here is so we don't have to use that database. Writing to those files is a path best avoided (and again, proably a quick route to court when hydrogen cyanide find out) Far better to process it in one go and convert into SQL commands which are then run into gnumed. Ian P.S. _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
