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

[Jim Busser]

On 2010-08-12, at 2:23 PM, lkcl wrote:

> late so quick reply.
> 
> * i'd like to do a demo even if i have to write in 30 mins a pyjamas-based
> "quick grid" where i am forced to type in the clin.lab_request pk in an
> input box.

Please acknowledge that the German workflow which spawned "lab request" as a 
potential test *driver* is NOT REFLECTIVE of the Canadian (BC.CA) workflow by 
which labs return.

In Canada, the lab request will exist *only* on the *paper* order that was 
generated by the ordering provider WHO MAY OFTEN NOT BE A MEMBER OF THE PRAXIS 
or who may have completed the test order paperwork at the hospital.

So --- except when GNUmed will later generate a pk *together* with a paper 
order that a path lab will accept and even then this only covers a subset of 
the incoming lab test results --- there will exist *no* record in 
clin.lab_request for the incoming labs to match "against".

If and when GNUmed would generate a pk which could be included in the round 
trip to the lab and then returning with the results, this will cover only those 
lab requests generated from inside the praxis and from inside GNUmed. In all 
other cases, 

        ORC 004 Placer Group Number (External Order ID eg:  Requisition number)

will either be null, or it will be a foreign pk originating from some foreign 
praxis and irrelevant to GNUmed.

So I had thought that maybe you were auto-creating a match inside 
clin.lab_request when none seemed to already exist, but figured I should make 
this question and answer explicit :-)

-- Jim