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 <[EMAIL PROTECTED]> 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 >[email protected] >http://lists.gnu.org/mailman/listinfo/gnumed-devel _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
