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: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010
Date: Sun, 15 Aug 2010 19:10:57 +0200
User-agent: KMail/1.13.3 (Linux/2.6.34.1-14-desktop; KDE/4.4.95; i686; ; )

Am Samstag 14 August 2010, 17:56:59 schrieb Jim Busser:
> On 2010-08-14, at 5:15 AM, Luke Kenneth Casson Leighton wrote:
> > On Sat, Aug 14, 2010 at 12:30 AM, Jim Busser <address@hidden> 
wrote:
> >> It is only request_id (not lab_request_id) that is non-NULL, unique so
> >> we just need a way to supply a unique value maybe
> >> 
> >>        CONCATENATE ("gm-", NUM_TO_TEXT (pk_item))
> >>        
> >>        ... or "gm-" could instead be some configurable per-praxis value.
> 
> I am realizing this jumped threads, at the point where – in discussing a
> possible conference demo– you wrote:
> 
>       ... "quick grid" where i am forced to type in the clin.lab_request pk in
> an input box.
> 
> Notice in my above reply
> 
>       request_id (vs lab_request_id)
> 
> which concerned you as to whether it should be the other way around.
> 
> I suggest that the insight that needs give us pause  --- and should
> certainly (once resolved) get onto a wiki page --- is that whether
> 
>       clin.lab_request.request_id
>       clin.lab_request.lab_request_id
> 
> should be "the other way around" rests entirely on we agree to improve, or
> alter, in the table definition/description along with the understanding
> that we need to "cement" on consistent usage.
> 
> It seems inescapable that we want
> 
>       one place to put an immutable GNUmed-generated identifier
> 
>       one place to put a presumably (but who can really know)
>               stable lab-generated identifier
> 
> and for now I maybe would rather not even say, among
> 
>       request_id
>       lab_request_id
> 
> which of them I thought was going to be which! :-)
> 
> Part of what risked confusing things was my recognition --- and my pointing
> out (which I may as well have done) --- that there exist cases where it
> can be possible to know, with reasonable certainty, at the point of
> requesting the tests, what the lab-generated identifier is *going to be*.
> Subject to confirmation by Sebastian/Karsten, it sounds like German labs
> *pre-generate* the lab identifier onto bar codes then-supplied to the
> doctor praxes, and this DOES MAKE IT POSSIBLE to *input* into GNUmed,
> upstream from the lab, the value that we expect the path lab will pass
> back.
> 
> We only must not misconstrue such an "upstream enterable" value to be
> GNUmed-generated, when it is only GNUmed-entered.
> 
> That, to my understanding, is the whole current-state bar-code thing. This
> bar-code thing is not to be confused with a future capacity for someone
> using GNUmed to take an actual GNUmed-generated identifier, hook GNUmed to
> a bar-code printer, and print bar code labels which in a different "health
> world" could see a path lab accepting to pull in, preserve and "route"
> such a value ---along with the test results --- back to the ordering
> provider (and extraneously to "copy-to" recipients).
> 
> I suspect that if the above is correct, and reaches resolution among us,
> then everything else you wondered about is (maybe) totally solvable. Until
> then, not.
> 
The barcode is printed and supplied in batches by the lab. It is not generated 
by GNUmed and it needs to be entered into GNUmed by staff to associate a 
result with a patient. There is currently no way to generate an identifier and 
supply that to the lab. There never will be I suppose. In the hospital I work 
(not GNUmed) we have a different situation. This is not of concern to GNUmed 
however.In the hospital the lab supplies a software where you can order tests 
to be done on a sample. You basically enter an order into their system. When 
you have selected the tests to be performed the barcode printer spits out a 
label which can be attached to the tube.

No physician's offices I know of have that kind of connection to the lab so I 
would not worry about it. I guess for Germany the barcode is as good as it 
gets. For the rest of the world where the lab is totally independent we will 
have to rely on what the lab tells us in terms of info on the patient. Even if 
all records seems to match you still cannot be sure that the lab did not screw 
up. So the only safe bet you have is a signed piece of paper from the lab.

Sebastian



reply via email to

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