that Ian , Richard Terry , have been given due credit for implementation of
some of the current progress notes and emr tree - notes organization facilities -
such as autocompletion, expanding SOAP entry user interface etc. A spanish medico
who is now doing radiology made a big inroad a year ago by implementing the
emr browser tree , which is something not seen in any of the oz emrs that I have seen.
within the cvs source of gnumed, there is even an importer for one of the common
australian emrs , much along the lines of promed clinical, once known as medibase,
and I noticed promed actually advertises the import facility as being a major feature.
So , instead of completely reinventing the wheel, why not finish the 80% finished one
that has overrun its time budget by about 300%, quite a common occurence in software
development, only it hasn't cost any money ( except the voluntary time given by enthusiasts).
Horst says it is too slow, but I for one have seen a version which was modified
for asynchronous client update, which worked satisfactorily , and did not block
the emr when it was loading large patient records, unlike one of the common emrs
here. I admit that complete reimplementation on ruby in rails is quite possible,
and a working first version could probably be done by one person, using a simplified
schema for a backend , as a while ago, a java tomcat / struts web based clinical frontend
for gnumed existed for one of its older schema incarnations, and that was done within one month.
Perhaps it is just politics, or a degree of bitter-and-twistedness, but the fact is that gnumed
does incorporate many of the features conceived and explained by australian contributors,
and it does work with some australian legacy gp data now, and it does scale enough for
the average workload data store, over a non insignificant period of at least 5 years,
so why not finish this so a demonstrating version of open source emr exists .
On Thu Sep 21 13:20 , Ian Haywood
David Guest wrote:
>
>
> However, the only way we can get buy in, even from the enthusiast's on
> this list, is if we can get to a primitive but usable EHR within a
> defined period of time.
>
> All this is dependent on Ian's acceptance. If he does I have pretty
> well mapped out his next few years.
>
>
Wow, thanks for that, David. Although I am a man of leisure in
comparison to Horst and others,
I'm not sure I have the time (let alone the experience) to do what
some are proposing with my current job. [but then I'm not sure exactly
what's being proposed]. I am locked into
full-time clinical work until Feb 2008.
What I would be happy to do is co-ordinate an effort by listmembers to
formulate exactly what a "primitive but usable
EHR" is and do the design and software architecture, on a
voluntary/informal basis, using the ozdocit wiki.
This process needs to happen no matter what business model is used,
probably can't be done any faster with other models, and can't be
delegated to non-clinicians to any real extent.
Then (IMHO) we have a crack at implementation using deliberately "easy"
options such as Rails, possibly augmented
by contract programmers using donated money. Personally I think this is
quite doable, despite my gnumed experiences, but I'm
an idealist.
If in the meantime official $BIG_DOLLARS appear to use Real Programmers
to do the actual coding work, fine. I am seriously *not* qualified to
play any real role here however.
On question I'm keen to answer (which doesn't have to be answered ab
inito) is whether we should have some form of company set up, mainly so
we can write off our 'investments' (we've been through this before I
know, but never got an answer IIRC)
Ian H
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
