[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] q about schema
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] q about schema |
Date: |
Mon, 14 Aug 2006 15:24:05 +0200 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
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