[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 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.
- [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/11
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Sebastian Hilbert, 2010/08/11
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, lkcl, 2010/08/11
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/12
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, lkcl, 2010/08/12
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/12
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010,
Luke Kenneth Casson Leighton <=
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/13
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/14
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/14
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/14
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/14