[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: James Busser
Subject: [Gnumed-devel] requests manager logic (was Re: Schema question re labs)
Date: Fri, 08 Feb 2008 17:29:44 -0800

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 ( 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]