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

[Karsten Hilbert]

For the record: the first iteration will have little in the way of
request handling and tracking. It will need to have association of
patients with request IDs and matching of incoming results against
those IDs if available.

> 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.
No problem. Simply don't use requests and match incoming results by
other identifiers such as demographics.

> 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...
I wouldn't try making things more complicated than they need to be.
Practice will show (unless you already know the numbers) how often
this ...

> when lab results return, they will be able to  
> match to the requesting doctor as well as to the patient

... will be needed.

> (and status  
> is_pending) without relying on any request_id which for my use case  
> may as well be null.
I figured as much and happily concluded that a first iteration may
need to do little if anything in that regard and still be useful
to you.

> > 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) is defined in the schema  
> to have to be UNIQUE#1 NOT NULL.
Why, sure, this is us asserting: Our intent in devising
the schema was to concurrently have unique requests per lab.

The database then makes sure we honor that assertion. The assertion
may prove to be wrong or less-than-useful but at least the database
makes us rethink it should that become apparent.

> 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
Oh, NULLs are always considered unique from each other:

NULL != NULL

> 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?
No. If matching is done w/o regard to any request ID -- if that's what
your use case requires -- GNUmed needn't care about requests at all.
If that's your use case - fine, even in the long run. Only if you decide
you *want* to track results via requests GNUmed will need to offer
that (I mean it makes sense but it ain't mandatory for the base operation
of the lab handling code).

Shall we do away with request_id handling entirely for the first
iteration? I'd be fine with that.

Karsten
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail