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

[Luke Kenneth Casson Leighton]

On Sat, Aug 14, 2010 at 8:09 PM, Jim Busser <address@hidden> wrote:
>
> On 2010-08-14, at 10:54 AM, Luke Kenneth Casson Leighton wrote:
>
>> On Sat, Aug 14, 2010 at 4:56 PM, Jim Busser <address@hidden> wrote:
>>> 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.
>>
>> ohh - riiiight.  now i get it.  then under these circumstances,
>> pre-creating the clin.lab_request is possible;
>> clin.lab_request.request_id is definitely the right place to put it.
>
> It is a risky thing that we skipped agreeing or disagreeing on that earlier 
> fundamental premise about which is which...

 no it's not.  the fundamental point is that i believed it was
impossible to know in advance what the ORC003 would be.  you
demonstrated that, in germany, it _is_ the barcode value, it _will_ be
known in advance, so everything is ok: you _can_ in fact pre-create
(effectively) the clin.lab_request, using the request_id field to
store what will be given back to you, guaranteed, in ORC003.

 it's the cases where it is not possible to do that which leave me
concerned (CA).  simply because you simply cannot go creating a
clin.lab_request *unless* you know what that ORC003 field is going to
be, and that's the end of it.

> So... I am scared to ask... did you intend to write 
> clin.lab_request.***lab***_request_id ???

 i wanted to know _if_ i should be writing to clin.lab_request.lab_request_id.

> ... or are you simply saying that despite the pre-generation, by an external 
> path lab, if what *it* intends to use as a lab identifier, and despite that 
> said identifier is going to come back with the test result as a lab-supplied 
> value...
>
> ... that GNUmed should consider it entirely fine to *substitute* the 
> pre-generated tracking id (in place of a GNUmed-generated value)

 no, absolutely not.  not a snowball in hell's chance of this working,
and it is in fact exactly what i have been saying is the problem.  how
the heck would that work, bearing in mind that request_id is (index'd)
with test_lab.  you'd have to create some sort of "fake gnumed lab" to
indicate that the value was a GNUmed-generated value.  but then you'd
have to just hope and pray that that value comes back to you (ORC002
perhaps?)

 i don't like it - at all: it just doesn't work.  and it's why i
suggested having a separate table for gnumed-initiated path-lab
queries.

> While I hate to do it, I must maybe point out yet another confounder. Not all 
> path labs perform all tests. Some test are special, difficult, expensive. So 
> when you (or your blood) shows up at Path Lab A and the request is for 10 
> tests, the Path Lab "accessioning" person inputs
>
> - the German bar code or
> - Canadian Path Lab A's own tracking number
>
> for use as the lab's tracking number. When this lab cannot perform all 10 
> tests (suppose it needs to send one tube of blood over to Path Lab B),
>
> ... Path Lab B applies *its own* tracking number which gets downstream-passed 
> into ORC 003
> ... Path Lab B relocates Path Lab A's tracking number downstream into ORC 004 
> because (relative to Path Lab B) the Path Lab A has taken on the attribute of 
> being the "External Order"

 ok, good - so at least, still, all ORC003s will be unique (not least
because Path Lab B has a separate test lab pk from Path Lab A).

> and so even if the ordering provider *did* for example supply their own, 
> GNUmed-generated internal tracking number (in Canada it would be "external" 
> to Path Lab A) there seems no provision in what is currently available in BC 
> CA to get this back with the results. So with GNUmed already having (in 
> lab_requests table) a pk, the only purpose of another unique internal column 
> is where it can be passed out *and* returned with the lab test result, right?

 ok - right.  now i know what ORC 004 is for.  goood.

 ok: at present, under these circumstances, the Path Lab B results
will simply end up (under the right patient), as just "yet another
clin.lab_request".  ORC 004 is entirely thrown away; the
cross-association between the two is entirely destroyed.

 unless a new field is added to clin.lab_request (e.g.
fk_parent_lab_request), that's the way things will remain: the
cross-association will be destroyed.

 l.