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

[Jim Busser]

On 2011-07-06, at 5:45 AM, Karsten Hilbert wrote:

> Well, what Richard was stressing is that while the HL7 we've
> seen so far may suggest a particular solution he's seen
> enough HL7 to believe it won't be so.

I think it is important that we correctly understand (agree on) the 
implications of "any particular solution" whose success depends on

- what the sending lab supplies by way of data and
- the particular implementation of the HL7 via which it is being provided

The consequences:

1. if you import data whose supplier and HL7 implementation *conform* to the 
expectations, relative happiness should ensue

2. if you import data whose supplier and HL7 implementation *deviate* from the 
expectations (despite the data being syntactically valid), the praxis may be 
quite unhappy and so can only choose whether or not the unhappiness is better 
than the alternatives of (a) not importing or (b) writing another / custom 
importer.

Hopefully we are not abusing this to mean

        a particular solution which works for one data source cannot be used 
whatsoever

and it only means

        do not apply a particular solution to every source…
        apply a particular solution *only* to sources that are (adequately) 
compatible ! ! 

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. Richard is merely 
(understandably) frustrated, same as me, that a lab chooses to transmit in a 
least-possibly-useful form. "Why", we ask, "do they not invest the time and 
money to upgrade their systems, or to contract-out some interface-writers to 
parse their outgoing results for the benefit of providers and their patients?… …

This EXACTLY DESCRIBED the situation with many local hospitals, at least up 
until about two years ago. Before then, these hospital labs "offered" to 
transmit page dumps padded (at least) by a few headers to aid patient matching. 
In the intervening two years, these labs swallowed the cost of contracting-out 
their data delivery to include conversion into atomic, granular (numeric) data. 
In the meantime, when one is "stuck" with brainless text dumps… you can

(i) take upon yourself the extra work of parsing them …

        (listen… listen… can you hear the crickets chirping?) or

(ii) accept the limitations of what is supplied. In other words, tolerate a 
lab's brainless provision of text dumps, and accept -- into one's EMR -- a 
"document" which is a text representation of an old-fashioned page report.

It could be worse. Worse would be to receive actual paper (via mail or 
courier), or a fax, and to have to print it or – in either case (if desiring to 
capture it into the EMR) – to have to scan it into a TIFF or PDF and then 
import *that*. The end result of *that* would be the extra trouble to get the 
blob *into* the EMR and the inflated storage requirement.

End-result: I would much rather accept the limitations of a text stream, which 
I could at least route into "documents" of description

        "brainless lab page report"

however, thanks for pointing out the need to build, into the HL7 importer code, 
a check for whether GNUmed recognizes the

        MSH 003 Sending Application ID
        MSH 004 Sending Facility 

as "approved" to be processed by the particular importer code.

-- Jim