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

[Sebastian Hilbert]

Am Samstag 14 August 2010, 21:09:50 schrieb Jim Busser:
> On 2010-08-14, at 10:54 AM, Luke Kenneth Casson Leighton wrote:
> > On Sat, Aug 14, 2010 at 4:56 PM, Jim Busser <address@hidden> 
wrote:
> >> 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.
> > 
> > ohh - riiiight.  now i get it.  then under these circumstances,
> > pre-creating the clin.lab_request is possible;
> > clin.lab_request.request_id is definitely the right place to put it.
> 
> It is a risky thing that we skipped agreeing or disagreeing on that earlier
> fundamental premise about which is which...
> 
> So... I am scared to ask... did you intend to write
> clin.lab_request.***lab***_request_id ???
> 
> ... or are you simply saying that despite the pre-generation, by an
> external path lab, if what *it* intends to use as a lab identifier, and
> despite that said identifier is going to come back with the test result as
> a lab-supplied value...
> 
> ... that GNUmed should consider it entirely fine to *substitute* the
> pre-generated tracking id (in place of a GNUmed-generated value) into what
> we would rather consider an immutable internal-to-GNUmed identifier of
> this request, in .request_id ?? My worry is that in a multi-lab
> environment, what we are talking about may not always be unique.
> 
> While I hate to do it, I must maybe point out yet another confounder. Not
> all path labs perform all tests. Some test are special, difficult,
> expensive. So when you (or your blood) shows up at Path Lab A and the
> request is for 10 tests, the Path Lab "accessioning" person inputs
> 
> - the German bar code or
> - Canadian Path Lab A's own tracking number
> 
> for use as the lab's tracking number. When this lab cannot perform all 10
> tests (suppose it needs to send one tube of blood over to Path Lab B),
> 
> ... Path Lab B applies *its own* tracking number which gets
> downstream-passed into ORC 003 ... Path Lab B relocates Path Lab A's
> tracking number downstream into ORC 004 because (relative to Path Lab B)
> the Path Lab A has taken on the attribute of being the "External Order"
> 
> and so even if the ordering provider *did* for example supply their own,
> GNUmed-generated internal tracking number (in Canada it would be
> "external" to Path Lab A) there seems no provision in what is currently
> available in BC CA to get this back with the results. So with GNUmed
> already having (in lab_requests table) a pk, the only purpose of another
> unique internal column is where it can be passed out *and* returned with
> the lab test result, right?

These are valid cases and there is simply no way to solve that by software 
unless labs and ordering systems start to communicate. This show that there is 
a need to a widget which will parse hl7 files display them for manual 
matching. If all or parts of the file have been matched deleted what has been 
and present what has not. It all depends on the presentation and information 
given to give staff a chance to match it.

SOm records might only be matchable after one has received a paper copy or has 
called the lab to obtain missing iformation. We do this all the time in the 
hospital.

Sebastian