|
From: | James Busser |
Subject: | [Gnumed-devel] requests manager logic (was Re: Schema question re labs) |
Date: | Fri, 08 Feb 2008 17:29:44 -0800 |
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 businesslayer, IOW the requests manager logic or right in the importer. At thatlevel 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) UNIQUESo 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?
[Prev in Thread] | Current Thread | [Next in Thread] |