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

[Jim Busser]

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...

So... I am scared to ask... did you intend to write 
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) into what we 
would rather consider an immutable internal-to-GNUmed identifier of this 
request, in .request_id ?? My worry is that in a multi-lab environment, what we 
are talking about may not always be unique.

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"

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?

-- Jim