Re: [Gnumed-devel] downstream provisions for invalid HL7, plus time zones

[Jim Busser]

On 2010-08-11, at 2:53 AM, lkcl wrote:

> ... so an HL7Message XML file is received, it contains a top-level
> root node named <HL7Messages>, and contains individual <Message> nodes. 
> each <Message> node contains HL7v2.  what's been said here is that if there
> is the outside chance of a syntax error in an individual HL7v2 message, the
> remaining syntactically-correct individual HL7v2 messages are still
> accepted.
> 
> in other words, the individual HL7v2 messages are treated as completely
> independent.

Not sure... see below

> this doeees have one slight coding wrinkle needed, to deal with it: the
> MessageFormat and the revision number are still needed, in order to be able
> to re-interpret the individual messages at a later date:
> 
> <?xml >
> <HL7Messages MessageFormat="ORUR01" version="2.3">
>    <Messsage> <!CDATA[[MSH.....]
>    </Message>
> </HL7Messages>

the above file would typically contain
- the messageformat that is to apply in-common to all messages within the file
- any *one* message pertains only to a single individual, but could have
        - multiple ORCs
                - within which there could be multiple OBRs
- there could be more than one message per patient, for example each from a 
different lab

But where an individual message would have been determined to be "syntactically 
bad/illegal" we would not retain it past the error review stage, would we? I 
mean, the praxis would ask its IT for help about this message, which was 
imported into "_unmatched" but which generated an error, and upon contacting 
the lab to "fix" their upstream problem and to "resend", we just delete the bad 
original (well, we mark it to go into "unmatchable") such that the newly coming 
in "valid" message is treated as "fresh"?

> so it would be necessary to "break down" the XML file containing multiple
> messages into *multiple* XML files each containing one message each, each
> containing the exact same MessageFormat and version number, in order to not
> lose vital information about the format of the HL7v2 data.  information
> which HL7v2 itself is *not* capable of storing.

I have to defer to your judgement but only question if the issue needs more 
thinking as far as whether the added complexity is needed?

-- Jim