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

[Jim Busser]

On 2010-08-13, at 1:46 PM, Luke Kenneth Casson Leighton wrote:

> note that that's ORC 003 - filler_order_number.


but... ORC 003 is only internally-relevant to the lab which *performs* the 
test... it is the performing path lab's *internal* reference number which may 
not have been known and cetainly may not have been captured upstream by the 
ordering provider.


> ORC 004 - placer group number - is in fact entirely ignored.
> *double-checks*.... yep, it's not even stored anywhere, let alone
> checked.  likewise ORC 002 - placer order number - is also ignored.

see my last post re ORC 002 (future use)


> if however you're telling me that ORC003 can be None then we're
> slightly stuffed (that's an understatement, btw), as the whole thing
> grinds to a halt because you'll be unlikely to ever successfully
> identify a lab request.

But.. it should be on 004 that we depend to match up a returning result with 
our original within-praxis-GNUmed-captured request, when one existed.

Your point is well-taken about "can be none" because in BC.CA only *one* of the 
path labs will input and return (with the result) an originating-requestor's 
tracking (external to the lab) ID and only when it staff thinks to do so.

That is why in BC.CA likely I would not bother to myself create GNUmed requests 
until the ORC 002 would be supported, while recognizing that it may --- even 
now --- be worth creating GNUmed lab requests in Germany.

I like the fact that in the absence of matchability, a request would be 
auto-created, since that might quickly assist the clinician to review 
*batteries* of tests already done from which some results might still be 
outstanding, without having to look at all of the detail.

-- Jim