[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 -> med_doc.date [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.
Ian
pgpLnhg84o60F.pgp
Description: PGP signature