Re: [Gnumed-devel] Schema question about clin.lnk_result2lab_req

[Karsten Hilbert]

>       
> http://salaam.homeunix.com/~ncq/gnumed/schema/devel/gnumed-schema.html#clin.table.lnk-result2lab-req
> 
> this table makes it possible to link foreign keys
Note: makes it *possible*

>       clin.test_result.pk
>       clin.lab_request.pk
> 
> Which I agree could facilitate navigation between a list of tests  
> that one had *requested* for a patient, and the (multiple) results  
> that may have eventually come in.
That's the intent.

> However in the case where (copies) of results were received without  
> them having been ordered within the praxis, we may need to support  
> results in the results table without there having been a record in  
> GNUmed of these tests having been requested....
That's the reason why it's *possible* but not *mandatory* the create
the link.

> unless we are saying  
> that we would wish the request to be created retroactively by the  
> import, perhaps to capture who is was (externally) who had ordered  
> such tests. Is there a position on this?
I should think it advantageous to add this information where available
but not possible in all cases.

> As I think about it, in the case of receiving copies directed to us  
> by an outside physician (or by ourselves from medical work outside  
> the praxis) I realize that in receiving such tests there would not  
> yet exist any encounter or episode in GNUmed to which to attach them  
Well, the encounter is generated by the very act of importing the
data (importing is an interaction with the health record of the patient)
for which an appropriate encounter type may need to be created (say,
"automated data import" or some such).

As for the episode - I'd advise to use an unattributed episode "lab data"
to which such things get auto-attached -- unless the episode can be taken
from the lab request -- which is the very reason for the foreign key
in *that* table ;-)

(So, it may even be useful in some cases to *split* requests into
several per-episode requests - but that's food for later iterations.)

I am fine with the importer spawing requests, too, if that's sensibly
doable from the incoming data.

> So unless the NOT NULL constraint is removed, there may be no choice  
> but to have to spawn clin.lab_requests from the incoming data when no  
> request existed against which to match the incoming data.
No. One simply doesn't create a row in the linking table ;-)

> Maybe that  
> is OK because as soon as the org and the patient were identifiable in  
> the incoming stream, the request could be created and simply marked  
> according to whether that request (initiated elsewhere) still had  
> anything pending, or did not.
If possible, yes.

> I suppose the episode/encounter could be free-standing and marked not  
> relevant so that we would not have too many of these, and I suppose  
> the doctor could attach the unsolicited request to a particular  
> health issue if for example a specialist sharing care with you had  
> ordered tests on your patient.
Correct.

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