On Mon, Aug 14, 2006 at 08:54:14PM +0800, Syan Tan wrote: > adhoc solutions in au schema, > images and rtf files in doc_obj > medication list in clin_med, and scripts in formatted clin_narrative > sounds ok, good, be sure to attach item_types to the clin_narrative scripts such that the scripts can be searched for when the need arises, you'll have to invent clin_item_types for that (we'll add them from within the au part of the bootstrapper)
> re the letters, they will end up as doc_obj, > so they probably won't interfere with whatever > form system gnumed uses, yes > although, > back importing into the original database might be > a problem, as non-rtf gnumed generated referrals would > need to be converted to rtf, or simpler, snapshotted as > an image and returned as a image document ( non editable ). for example, yes > Actually, the doc_obj and doc_type problem is a little harder, > as the document table has a detail where secretaries have hand > typed perhaps the origin of the document, e.g specialist name, > this would need to be looked up in a au stored specialist table > and then the specialist type attempted to be inferred; One might want to set up an explicit mapping table au.specialist2type. One could also use a dummy type and put the detail into blobs.doc_med.comment. > this may not always possible, so what to do when this fails, > (an au specific dummy doc type inserted as a doc type ?) Sure, with is_user = True. 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
