Re: [Gnumed-devel] q about schema

[Syan Tan]

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, 
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,
>Yes.
>
>Please read
>
> http://wiki.gnumed.de/bin/view/Gnumed/DocumentManagementConcepts
>
>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
>client side.
>
>> 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 
>> due
>> 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, 
>> so
>> then the docs can be imported , since this should be an automated step,
>Sounds reasonable.
>
>> 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
>list.
>
>> otherwise, can the med_docs have optional doc_type , or an unassigned 
>> doc_type?
>I'd rather not.
>
>> Also , the import source has 2+1 tables for medication and scripts. There is 
>> a
>> 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 / 
>> and
>> 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 ?
>
>Karsten
>-- 
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel