[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Project Management (Again)
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] Project Management (Again) |
Date: |
Sat, 03 Dec 2005 15:55:39 +1100 |
User-agent: |
Debian Thunderbird 1.0.7 (X11/20051017) |
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.