> >> Maybe this means we need, in clin.test_type > >> > >> fk_lab_section > >> fk_test_profile > > Will put it on the TODO even for the first iteration. > > Just realized we have no table in which to keep the above... One could always just make it a lab_section and test_profile and storing plain text instead of keys right in clin.test_type. Might actually make sense.
> we have > clin.test_org however that is meant to hold single records per > organization whereas each test_org will have multiple lab sections > (HAEM, MICRO, CHEM etc), and each section will offer multiple kinds > of test_panel Well, for one thing we aren't interested in modelling the internal structure of arbitrary labs but rather to keep information that is of clinical value to us. What clinical value does "lab section" have, at the end of the day ? I don't see much of any. test_panel is, maybe, another story. > I am thinking we should reserve the word/concept "profile" for > internal GNUmed EMR concepts/usage Yes, agree. Maybe put this somewhere on a "Lab Concepts" page/section ? > and when working with test_org > arbitrary sets of tests to work-in the term "test panel" which we > could in fact maintain inside clin.test_type rather than as a foreign > key (you hinted at this before). Yep. > Where / how would we manage > fk_lab_section Not. I fail to see clinical value. Karsten -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
