Re: [Gnumed-devel] document control

[Ian Haywood]

On Sun, Oct 10, 2004 at 07:19:19PM +0200, Karsten Hilbert wrote:
> > I have added some columns to gmBlobs.doc_med for
> > document control -- keeping track of who's
> > seen what, what need's to be sent, etc.
> I wonder if those should be in doc_med or some table
> *linking* to doc_med - certainly haven't looked at it yet,
> though.
> 
> However, this needs to be discussed and decided *BEFORE*
> changing (it can be changed if there is good reason !)
> because we have LIVE INSTALLATIONS of this out there.
This is why I have left the gmMeasurements stuff well alone.
Presumably you are not updating the database schema straight from CVS. 
Do we need stable and devel braches in CVS?
> I would certainly not intermingle the "live" messaging tables
> that are being watched with the "permanent storage" tables of
> the data. One reason is that consistently dumping a "permanent
> storage" table is far easier than a live, always-changing
> documents table that is under constant watch.
The permanent storage table is changing also, which is why we reply on
the hot backup support of postgres, in any case, we will want to back up
the messaging tables too, surely?
> IOW, if the path results *appear* to be a document - store them
> in the document tables. If the appear to be values put them in
> the measurements tables.
> 
> Eg. a document present *information* while values present
> *data*.
Indeed, however, wouldn't you store the original LDT transmission in
doc_obj?, so it's both a document and a set of logical values.

Also, not all path. can be broken down into logical values, such 
as histological reports, and 90% of the path. reports here in AU,
which are presented as free ASCII text as Jim commented. Plus radiology,
consultant reports, and so on.

These need to have the same control mechanism as exists in
gmMeasurements for keeping track of what's pending, what needs review
etc. Why have 2 control mechanisms?

Ian

pgpoURYZPcWfv.pgp
Description: PGP signature