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

[syan tan]

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 identity.pk 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