[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] basic test types - Sample type prefixes
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] basic test types - Sample type prefixes |
Date: |
Mon, 11 Oct 2004 23:17:39 +0200 |
User-agent: |
Mutt/1.3.22.1i |
> >Complicating matters - but at some point something we may want to
> >factor into design - is that the labs often use a different set of
> >codes by which to ORDER tests as opposed to codes by which to REPORT
> >results. Among other reasons, a single order code can designate
> >multiple tests whereas that single code would be a clumsy way by which
> >to manipulate/search results. Also there are some tests which although
> >you may order a single test (for example serum iron saturation), I
> >think the lab must do a pair of tests (transferrin and iron) and even
> >if that is wrong there are other situations where they must do a
> >"ghost test" (my term) in order to generate a result.
>
> so what are you trying to say ?
Likely Jim is thinking of matching incoming to outgoing. Which
I happen to think is not very feasible today.
> (i.e. there is a functional dependency between result to order code), so
> I need 2 tables , not 1 , for test_type. (test_type_order,
> test_type_result)
It might well suffice in the real world to just have a text
field listing requested tests right in the test_request table.
> Are you wanting to
> put version fields in the both tables ( to accomodate for lab fashion
> trends)?
There already is a version field there.
> What about just posting a change as
> tablename1(attributes) -1- relationship-name -*-
> tablename2(attributes). Please include in gnumed schema, sir.
I think Jim was trying to get our ideas on whether this is
relevant at all.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346