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 -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
