[Top][All Lists]

[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 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))
                req = cr.get_lab_request(req_id=lr.filler_order_number,
            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-{}-{}-{ 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)



reply via email to

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