gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010


From: Luke Kenneth Casson Leighton
Subject: Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010
Date: Fri, 13 Aug 2010 21:59:18 +0100

On Fri, Aug 13, 2010 at 12:17 AM, Jim Busser <address@hidden> wrote:
> If and when GNUmed would generate a pk which could be included in the round 
> trip to the lab and then returning with the results, this will cover only 
> those lab requests generated from inside the praxis and from inside GNUmed. 
> In all other cases,
>
>        ORC 004 Placer Group Number (External Order ID eg:  Requisition number)

 is it the intention to have lab requests "initiated" by gnumed,
perhaps even by generating an HL7 message to be automatically to the
lab?  i assume clin.lab_request.pk would eventually end up in the ORC
004 in a response, under these circumstances?  if so then it really
ought to be part of the code _now_, notes made to that effect:

 something like:

     if lr.placer_group_number:
         req = gmPathLab.cLabRequest(pk=int(lr.placer_group_number))
     else:
            try:
                req = cr.get_lab_request(req_id=lr.filler_order_number,
                                         lab=test_org_pk)
            except ValueError:
                req = None

 with of course a check to make sure it actually exists.  with perhaps
some sanity "prefix" on the front to ensure that it's definitely a lab
request expected!  perhaps even encoding the fk_patient in, as well.
even something like...
GM-{clin.encounter.pk}-{dem.identity.pk}-{clin.lab_request.pk) would
be "ok, yep, that's almost certainly going to be for this patient".
perhaps even a praxis-unique identification prefix rather than just
"GM-" (is there any serial number generated for each gnumed install?
hmmm, what if that changes by mistake, now you can't identify the
expected incoming observational reports, hm, perhaps not a hot idea,
unless it's generated at the time and then stored in clin.lab_request)

thoughts?

l.



reply via email to

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