[Top][All Lists]

[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: Sat, 02 Dec 2006 00:04:41 +1100

I was able to contribute to a peer education discussion list using
gnumed today; someone mentioned an uncommon condition, and
I was able to locate a similiar case using gnumed , by doing
a search on clin.clin_narrative ilike (case-insensitive like) '%<search
word1>%'  and clin.clin_narrative ilike '%<search word2>%' , 
and then backtracking to the and the dem.names.id_identity.

Very useful  ; probably could do it using out native emr, but
wouldn't have been < 10 seconds , as with gnumed.

On Tue, 2006-11-28 at 13:14 +0100, Karsten Hilbert wrote:
> On Tue, Nov 28, 2006 at 11:03:14AM +0800, Syan Tan wrote:
> > 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,
> It's always a difficult line to walk where to go specific
> (dedicated tables) and where to go general (generic EAV).
> We will have to (and will) expand both approaches where
> needed.
> > gnumed lacks the scripting / pseudo-AI prescription decision support
> > that are available in the commonly used emr systems here. 
> I would think that's something that needs to be solved in a
> layer somewhere above the database. But the storage needs to
> have support for it.
> > 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. 
> Thanks for that. The PG versions that are currently being
> release already contain improvements for the UNION/INHERITS
> case which slowed down some of our queries.
> > As far as I know, it is the only free , open-sourced  , gnu licensed
> > gp medical application that can import australian legacy data;
> Yay !  :-)
> > 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,
> Also, it's only then that you really see the advantage of
> structuring data into episodes, encounters, SOAP, and,
> optionally, health issues (foundational illnesses/past
> history items).
> Karsten

reply via email to

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