[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] q about schema
Re: [Gnumed-devel] q about schema
Mon, 14 Aug 2006 20:54:14 +0800
adhoc solutions in au schema,
images and rtf files in doc_obj
medication list in clin_med, and scripts in formatted clin_narrative
re the letters, they will end up as doc_obj,
so they probably won't interfere with whatever
form system gnumed uses, 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 ).
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;
this may not always possible, so what to do when this fails,
(an au specific dummy doc type inserted as a doc type ?)
On Mon Aug 14 14:24 , Karsten Hilbert <address@hidden> sent:
>BTW, I think it's a really good test for our schema to try
>and import data from a working scheme into it such that we
>learn where it fails or is lacking.
>On Mon, Aug 14, 2006 at 07:26:17AM +0800, Syan Tan wrote:
>> What is the preferred way of blob import ?
>> - I noticed that blob.med_doc looks obligatory,
>to get an idea of the concepts behind it.
>doc_med is the main table holding a document as such
>doc_obj is the table holding parts of a document such as
>"pages", "objects", etc
>IOW, a document can consist of several separate pages of
>even different file formats.
>Create a blobs.doc_med row and attach as many blobs.doc_obj
>rows as needed. Voila, there's your document.
>> and that there needs to be a
>> reference to blob type as well,
>yes, but doc_type is configurable, even from within the GNUmed GUI
>Please take care to properly set the is_user field (default
>is True). This will ensure proper handling on database
>upgrades. IOW, doc_types with is_user=True will be left
>alone by the upgrade script (are considered local) and will,
>for example, never be deleted by anything we release. That
>way we can ensure we never destroy or garble user data at a
>> and also a link to a patient ( ? also not null)
>yes, each document MUST belong to a patient
>> and reviewer.
>That's a design decision. Each document must be "targetted"
>at one provider within the practice who is to be responsible
>for actioning on the document. When storing outgoing letters
>as blobs one might set the reviewer as the doc writing the
>letter and also automatically mark the document as reviewed.
>> - the import type I was thinking of has a specialist table , with name,
>> address, and specialty _type , where specialty_type is sometimes duplicated
>> to mispelling or different phrase
>> (e.g. general physician/physician/general medicine ).
>You might want to add some tables to the "au" schema.
>> - I was thinking of using the specialty table to proliferate the doc_types,
>> then the docs can be imported , since this should be an automated step,
>> perhaps an ability to merge doctypes via gnumed application could be done
>> later ;
>We will want to be able to do that anyways. It's on the TODO
>> otherwise, can the med_docs have optional doc_type , or an unassigned
>I'd rather not.
>> Also , the import source has 2+1 tables for medication and scripts. There is
>> drug_no field that is supposed to uniquely identify the medication, but
>> there is
>> denormalization here as well , so that when the medication is printed, it's
name and presentation is
>> stored in 2 text fields in the script table.
>I don't think that's such a bad idea -- if done properly.
>It's useful because a copy of the script with denormalized
>data can usefully be inspected at any later time without the
>drug database having to be around.
>I think we should eventually do it that way: Store a copy of
>the script in the forms table. The copy will contain the
>denorm'ed drug name as well as a FK to the drug row. The
>drug row, however, isn't a row directly in the reference
>database but rather a copied row in a fully normalized local
>table. The latter approach was suggested by Hilmar.
>> I suppose I'm asking where to store medication and scripts
>We don't really have good tables for that yet.
>Medication as in "current patient medication" is supposed to
>be stored in clin_medication. Scripts should eventually end
>up in form_data. As an ad hoc solution I'd suggest using
>clin_medication and putting the script into clin_narrative
>rows. For the latter I'd add some formatting delimiters to
>the script content such that it can be reparsed. Also I
>would suggest attaching appropriate clin_item_types to be
>able to filter out those rows later on.
>> and whether an external drug schema can be used , and how to do this.
>you might as well add some tables to the AU schema as needed
>> Another type is the letter type, which raises the question of RTF readers /
>> or writers.
>> Is there a way of storing the type of letter document with gnumed,
>yes, blobs.doc_med :-)
>> and have some sort
>> of mimetype/x-application etc... where say Abiword is fired up ?
>The current middleware deals with such things. It uses
>file(1), extract(1) (see libextractor) as well as its own
>store of mime type detection codes to find out the mime type
>of a file exported for viewing. IOW, when an archived RTF
>file is selected for viewing it is exported into a file, the
>mime type detected and a viewer for it is started. If your
>OS is configured to call Abiword on RTF files that is what
>will be started. It works precisely the same way as for mail
>attachements. This is, in fact, true for each single doc_obj
>row *per* doc_med row such that different parts of one and
>the same document can be of different mime types.
>> this might lead to a problem with templates though , as I gather the default
>> template type for gnumed was to be postscript.
>Ah, never mind. I don't think we've enough experience yet as
>to fix ourselves onto postscript.
>> A more basic step is , how to store letters against patients, and any special
>> requirements (e.g. mandatory linking to a specialist provider ? )
>Can you be more specific here on this ?
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
>Gnumed-devel mailing list