[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: |
Sebastian Hilbert |
Subject: |
Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010 |
Date: |
Sun, 15 Aug 2010 18:11:06 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.34.1-14-desktop; KDE/4.4.95; i686; ; ) |
Am Freitag 13 August 2010, 22:59:18 schrieb Luke Kenneth Casson Leighton:
> 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?
>
Germany is not that much different. The lab will provide barcodes to the
praxis. Someone draws the blood and pots a barcode on the tube. It is up to
the praxis to manually associate the barcode with a patient. The lab will only
return results and the barcode as idetifier. They don't know the patient name.
Sebastian
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, (continued)
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Sebastian Hilbert, 2010/08/15
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Sebastian Hilbert, 2010/08/15
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/15
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Jim Busser, 2010/08/15
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/16
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Karsten Hilbert, 2010/08/17
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Luke Kenneth Casson Leighton, 2010/08/17
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Karsten Hilbert, 2010/08/19
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Sebastian Hilbert, 2010/08/15
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010, Karsten Hilbert, 2010/08/29
- Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010,
Sebastian Hilbert <=
- [Gnumed-devel] German path lab barcodes, Jim Busser, 2010/08/15
- Re: [Gnumed-devel] German path lab barcodes, Karsten Hilbert, 2010/08/17