Re: [Gnumed-devel] Results tracking (was: gnumed ideas 0.1 and post-0.1)

[Ian Haywood]

On Thu, Feb 24, 2005 at 09:18:00AM +0100, Karsten Hilbert wrote:
> > Do we actually lose anything by shifting to the structure Ian contemplated?
> Well, for one thing, BLOBs aren't supposed to be in the same
> database as granular lab data.
OK.
I would settle for a single tracking tracking table anywhere (I'm not sure
which service it should be in) linked to documents and results.
For us, having it in documents would be easy, as we won't have any
granular lab data in the near future. (even with HL7), but I don't
want two tracking systems.

My preference would be to put tracking in med_doc (which means taking
it *out* of lab_result), and relying on lab_result.fk_doc for their
tracking. This also provides the normalisation I think lab_result should have
(so granular results can still be aggregrated into their original
report)
This means *zero* changes to the existing documents client code (as we
are only adding columns to med_doc, old code can merrily ignore them)
However it does mean a small change to the LDT importer (to create med_doc
entries so these results can be tracked)
The existing path. viewer will still run using a simple joining
view between lab_result and med_doc.

The reason I wanted the savannah patch manager is putting patch files
into the CVS tree you are patching is seriously strange.
Maintaining forked trees under test_area is even worse, this is a
totally inappropriate use of CVS and causes very severe problems when
you try to sync back to be main tree, as Syan knows ;-)

Ian

pgp25y8xO0fAx.pgp
Description: PGP signature