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

[lkcl]

Jim Busser wrote:
> 
> Got this back, in answer to these questions, from the main path lab
> results provider for my region of BC.CA:
> 
> Begin forwarded message:
> 
>> Generally if there is some invalidity in messages, it's only one, not the
>> entire batch, so you may want to import everything but the 'bad' message. 
>> We have no issue with resetting one accession once the 'badness' is
>> resolved.
>> 
>> As to the concept of inserting time zones, we haven't plans on doing so -
>> we don't get the information from the labs that send to us, which are all
>> in the same time zone as Excelleris; our assumption is that anyone
>> accessing the Excelleris report would understand that the reported on
>> dates and the MSH line date (message creation date) would be interpreted
>> as our time zone.
> 
> 
> So as per Luke's suggestion, it would seem sensible that ---  in the case
> of one or more syntactically "bad" messages --- the remainder in the file
> can and should be processed, since it is possible to later be sent
> "non-bad" messages without having to receive the originally "good" ones
> all over again.
> 

 ok, not sure i _did_ suggest that (out loud, anyway) so will go with it
anyway :) 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.

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>

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.

in this way, the data integrity can be preserved and the messages processed
in a timely fashion even in the face of data errors.


Jim Busser wrote:
> 
> As to time zones, should the script
> - be hard-code for a time zone
> - assume it should take its timezone from the server that is running the
> script
> - take a "time zone" value from a per-praxis script configuration table?
> 
> 

the code i've written simply takes the timezone as an optional argument: it
assumes current local timezone if not given:

    if tzone is None:
        tz = gmDateTime.gmCurrentLocalTimezone # force a timezone

in most cases, therefore, i believe the issue can be ignored.  however,
given that there exists the possibility that i would be testing in the UK
against an HTTP server in sayy.... germany or canada, it becomes necessary
to add some flexibility.  hard-coding the timezone is therefore ruled out on
that basis: the rest, well, we'll see what's needed when it comes to it.


l.

-- 
View this message in context: 
http://old.nabble.com/downstream-provisions-for-invalid-HL7%2C-plus-time-zones-tp29402809p29406686.html
Sent from the GnuMed - Dev mailing list archive at Nabble.com.