Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010

[Jim Busser]

On 2010-08-14, at 5:15 AM, Luke Kenneth Casson Leighton wrote:

> On Sat, Aug 14, 2010 at 12:30 AM, Jim Busser <address@hidden> wrote:
>> It is only request_id (not lab_request_id) that is non-NULL, unique so we 
>> just need a way to supply a unique value maybe
>> 
>>        CONCATENATE ("gm-", NUM_TO_TEXT (pk_item))
>> 
>>        ... or "gm-" could instead be some configurable per-praxis value.

I am realizing this jumped threads, at the point where – in discussing a 
possible conference demo– you wrote:

        ... "quick grid" where i am forced to type in the clin.lab_request pk 
in an input box.

Notice in my above reply

        request_id (vs lab_request_id)

which concerned you as to whether it should be the other way around.

I suggest that the insight that needs give us pause  --- and should certainly 
(once resolved) get onto a wiki page --- is that whether

        clin.lab_request.request_id
        clin.lab_request.lab_request_id

should be "the other way around" rests entirely on we agree to improve, or 
alter, in the table definition/description along with the understanding that we 
need to "cement" on consistent usage.

It seems inescapable that we want

        one place to put an immutable GNUmed-generated identifier

        one place to put a presumably (but who can really know)
                stable lab-generated identifier

and for now I maybe would rather not even say, among

        request_id
        lab_request_id

which of them I thought was going to be which! :-)

Part of what risked confusing things was my recognition --- and my pointing out 
(which I may as well have done) --- that there exist cases where it can be 
possible to know, with reasonable certainty, at the point of requesting the 
tests, what the lab-generated identifier is *going to be*. Subject to 
confirmation by Sebastian/Karsten, it sounds like German labs *pre-generate* 
the lab identifier onto bar codes then-supplied to the doctor praxes, and this 
DOES MAKE IT POSSIBLE to *input* into GNUmed, upstream from the lab, the value 
that we expect the path lab will pass back.

We only must not misconstrue such an "upstream enterable" value to be 
GNUmed-generated, when it is only GNUmed-entered. 

That, to my understanding, is the whole current-state bar-code thing. This 
bar-code thing is not to be confused with a future capacity for someone using 
GNUmed to take an actual GNUmed-generated identifier, hook GNUmed to a bar-code 
printer, and print bar code labels which in a different "health world" could 
see a path lab accepting to pull in, preserve and "route" such a value ---along 
with the test results --- back to the ordering provider (and extraneously to 
"copy-to" recipients).

I suspect that if the above is correct, and reaches resolution among us, then 
everything else you wondered about is (maybe) totally solvable. Until then, not.

:-)

-- Jim