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?
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
