[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] document control

From: Ian Haywood
Subject: [Gnumed-devel] document control
Date: Sun, 10 Oct 2004 03:39:58 -0400
User-agent: Mutt/1.3.28i

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.

The idea is to have messaging daemons on the server which watch this
table, and transmit/receive documents as required.

I've notices this duplicates some of the work in gmMeasurements.sql
for path. results. However path results are documents too, IMHO
we should fold this into a single framework.

I would propose 
test_result.reviewed_by_clinician -> med_doc.fk_queue (incoming doc 
moves to the archive queue when reviewed)
test_result.fk_reviewer -> med_doc.fk_reviewer
lab_result.request_id -> med_doc.ext_id [outgoing doc]
lab_result.lab_request_id -> med_doc.ext_id [incoming doc]
lab_result.fk_requestor -> med_doc.local_id
lab_result.fk_test_org -> med_doc.remote_id
lab_result.is_pending -> med_doc.fk_queue (outgoing doc moves 
to archive queue when we get a reply)
lab_result.results_reported_when -> [on incoming doc]
lab_results.lab_rxd_when -> med_doc.request_rxd_when
lab_results.request_status -> med_doc.report_status [on incoming docs,
which are linked by common reply_to value]
lnk_result2lab_req -> med_doc.reply_to

It is possible to emulate the gmMeasurement tables using views,
althoughthis may be slow.


Attachment: pgpLnhg84o60F.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]