Re: [Gnumed-devel] q about schema

[Karsten Hilbert]

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