[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.
Regards
Richard
>
> ??
>
> -- Jim
>