[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] HL7 Importing Lab Results/Contacts

From: richard terry
Subject: Re: [Gnumed-devel] HL7 Importing Lab Results/Contacts
Date: Thu, 7 Jul 2011 08:20:43 +1000
User-agent: KMail/1.12.4 (Linux/2.6.31-23-generic-pae; KDE/4.3.5; i686; ; )

On Thursday 07 July 2011 01:23:25 you wrote:
> On 2011-07-06, at 2:25 AM, richard terry wrote:
> >> This is partly auto-resolvable from the OBX segment, seq 2 (Value Type),
> >> the two-character codes may be [...]
> I did say *partly* auto-resolvable.
> > [...] Major hospitals here send
> > what should be NM results in FT fields as a 'report, akin to getting a
> > biro and writing the result in the middle of a page of blank paper'. Good
> > luck if you choose to be purist. Unfortunately HL7 parsing is about
> > 'exception' programming in the real world.
> Hopefully, it is understood that even while I am not always happy about the
>  real world, I do fully-enough comprehend it.
> I might have been overly broad, though, when I wrote:
> > In the example Richard supplied, wherein a lab transmits the equivalent
> > of an ASCII print job, this is not actually a deviation from the
> > standard. The lab is "correctly" transmitting textual data in HL7
> > messages.

Pretty sad for the patient though, if the FT result is a PSA, and you try and 
trawl your database for all elevated PSA's  or try and graph them - good luck!
> This is not *necessarily* a deviation…. what do the offending hospitals
>  supply as their
>       LOINC^Hospital lab result name
> in their
>       OBX 003 (Observation Identifier)
Its been quite a while since I 'got my hands dirty' with the hl7 files.

My 'off the top of my head' recollection of this is that they are pretty good 
about suppling the LOINC codes for OBX NM etc, but  in FT used a a pseudo NM 
field to the best of my recollection it is missing, but I'll take a look, maybe 
I'm wrong - however as they may put multiple result lines of different results 
into the same FT segment I doubt they will have a loinc.

I did present a talk at a GP-IT conference a few years ago about the problems 
with HL7 from the various vendors in Australia - it was a diary of my notes 
I'd kept as I was learning how to handle hl7 and my interactions with the 
labs/hospitals -  there were so many problems that I think the audience was 
incredulous/disbeleiving that organisations sending HL7 should do so as badly 
as some - not all - do.

One major eastern seaboard lab here  I've never,(aside from very very rare 
patient data entry errors), ever had a hl7 problem with. Others have sent files 
ranging from no patient id's at all,  to incorrect data ranges for results, to 
missing results in the segments, wrong senders, wrong recipients etc etc 
etc... the list goes on.

The other thing that perpetually worries me about hl7 deciphering is that 
there is huge potential for mistakes in the coding and the medico-legal 
implications of that.

My parser hasn't dumped an error file for quite some time but probably only 
because I've had to build in code to handle the errors I know some labs are 
going to put into their hl7 in the first place!

Anway - I'm not the most logical person in the world - and never trained as a 
programmer - perhaps that is why I struggled so much with it and why my 
solution is not particularly elegant.



> ??
> -- Jim

reply via email to

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