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
pgp1JEhA1NSns.pgp
Description: PGP signature
_______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
