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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
