gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] what happened to the GNUmed developers ?


From: Syan Tan
Subject: Re: [Gnumed-devel] what happened to the GNUmed developers ?
Date: Tue, 28 Nov 2006 11:03:14 +0800

gnumed schema is pretty ok, and I think it has taken a
quite useful road of being specific about what data it is modelling
/storing, and not too open-ended , like more general examples
I know of, e.g. openehr, corbamed. It makes it much easier
to map legacy data to, as the commercial gp emr vendors in australia
takes much the same approach as gnumed, in that they use 
specific tables for specific domain data types, only the vendors
probably aren't that interested in having correct concepts, just
a storage structure for the kinds of forms they use in their gui.
gnumed lacks the scripting / pseudo-AI prescription decision support
that are available in the commonly used emr systems here. 
Because it uses postgres, I think it is quite scalable, and 
I've imported our own legacy data into gnumed , just to prove 
that it has the potential for being usable in the australian context. 
As far as I know, it is the only free , open-sourced  , gnu licensed
gp medical application that can import australian legacy data;
a problem area might be finding out the source system's schema design
in order to effect a migration to gnumed for those who are currently
using a system. The shame is that you only get reassurance that 
gnumed could be up to the task if you see it successful handle 
large amounts of legacy data, but the most likely people to consider
using gnumed practically , would be people who have not started
computerized medical records , and aren't already locked-in to a 
particular vendor system.   

On Mon Nov 27 12:46 , Karsten Hilbert <address@hidden> sent:

>On Mon, Nov 27, 2006 at 08:53:13PM +1100, Ian Haywood wrote:
>
>> One problem is the high level of orthogonality between German and Australian 
>> requirements (or rather, requirements priorities),
>While this may be true I still secretly consider it a
>Japanes explanation (a Gentleman's excuse for us all for not
>having succeeded better on this ;-)
>
>But, again, it may just be true. And indeed you (Ian) were
>the one who led med to realize that.
>
>> Karsten, being German, has worked on his own priorities,
>No doubt about it.
>
>> My problem has been the internal structural design  (in this I blame as much 
>> my own decisions as anyone else's) which means 100s of lines of Python code 
>> to get even the simplest stuff done
>This is very interesting. Can you please give an example, like:
>
>I want the GUI to do "b". For that I'd have to ... and ... and ... .
>
>I am positive I can tell where there's work involved and
>where it's perhaps just a misconception. BTW, the business
>objects have somewhat reduced their (over)complexity lately
>based on your suggestions.
>
>>, given the amount of time I have 
>> available to code, it's impossible to get any meaningful functionality (from 
>> the AU perspective).
>I am not convinced but, hey, you know the details on your requirements.
>
>> I think Karsten understands this problem,
>Yes.
>
>> but because 
>> his requirements are orders of magnitude simpler
>Nope. Different, perhaps. I have, so far, only be accused of
>having complex requirements (regarding structuring of data,
>that is :-)
>
>> he, undertandably, wants to stick with what we've got.
>Not necessarily. It depends.
>
>> I have some ideas around solutions, however these involve a total code 
>> revolution, particularly in middleware,
>I am really interested in what you think needs to be done,
>in private mail if you prefer.
>
>Karsten
>-- 
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel






reply via email to

[Prev in Thread] Current Thread [Next in Thread]