[Gnumed-devel] requests manager logic (was Re: Schema question re labs)

[James Busser]

Continuing the challenge where the lab that will do the test may not  
be known in advance, and/or where any request_id that is generated in  
the doctor's praxis may not be externally transportable and  
returnable with the result...

On 8-Feb-08, at 1:42 AM, Karsten Hilbert wrote:

> > In Canada and other places where the request_id could be free to be
> > decided by the requesting praxis, there is presently no mechanism to
> > be able to manage what should go in here.
> It needs to be added or rather, on the appropriate Wiki page, that's
> what I meant by "reuse demographics widget to enter lab request ID".
> I would suggest defining an external ID type for that purpose which
> is then taught to the importer to use.


It presently turns out that in my province of British Columbia  
(holding 4.4. million of Canada's 33 million people, I recognize  
Germany has ~ 82 million) it is *not possible* to pass a request_id  
through to the lab and to have it reliably returned, at least not in  
the HL7 fields ORC 004 or OBR 002.

The closest approximation would be to place, onto a paper  
requisition, a "patient chart number" which may not be unique if  
tests were ordered by someone outside of GNUmed and the result copied  
to GNUmed (say a specialist ordered a test on your patient and copied  
you the result, it could be that the specialist had put their own  
chart number on the form). Also, it is manually transcribed. Also, I  
do not have confirmation that all lab systems will process (include)  
it. Also, the broker returns this chart number in an HL7  
"PID" (patient id) field, so to use it to carry the request_id would  
be using it for a different purpose than it was designed, which is  
always risky.

So I think that the easiest way for Canada is, when any tests had  
been recorded into GNUmed's clin.lab_request, to capture the  
requesting doctor... when lab results return, they will be able to  
match to the requesting doctor as well as to the patient (and status  
is_pending) without relying on any request_id which for my use case  
may as well be null.

> Well, the request ID is an arbitrary business entity opaque to the
> persistence mechanism. Thus it would be generated in the business
> layer, IOW the requests manager logic or right in the importer. At  
> that
> level it would be made configurable just like any other options we
> have in GNUmed.


But request_id  (combined with fk_test_org) us defined in the schema  
to have to be UNIQUE#1 NOT NULL.

In mine and other locales where the test_org cannot be known or can  
change (because the patient can take their requisition anywhere and  
have their blood or urine taken in any lab), any default for  
fk_test_org would have to be able to be changed later. Therefore, in  
locales like mine, if fk_test_org is forced to be NOT NULL, then it  
will have to be able to be changed without violating the current  
constraint if I understand it correctly:

        (fk_test_org + request_id)      UNIQUE

So in the first GNUmed lab iteration (0.2.9.0?) where I want to be  
able to receive results into GNUmed without having created requests  
in lab_requests, it won't matter, however the requests manager logic  
will need to be able to be configured to provide a unique value for  
request_id?