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
