[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] downstream provisions for invalid HL7, plus time zon
From: |
Luke Kenneth Casson Leighton |
Subject: |
Re: [Gnumed-devel] downstream provisions for invalid HL7, plus time zones |
Date: |
Wed, 11 Aug 2010 16:23:04 +0100 |
On Wed, Aug 11, 2010 at 3:50 PM, Jim Busser <address@hidden> wrote:
>> 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?
ah - it would appear then that i misunderstood. one HL7Message could
conceivably contain <Messages> each of which is for a different
patient, in which the ORCs etc in that <Message> are specifically and
exclusively for that patient.
so it is up to you.
if there are instances where you'd prefer that an entire _batch_ of
patients' <Messages> not be delayed by one silly syntax error, then,
yes, the complexity (which isn't actually that much) can be justified.
if however the delay to an entire batch of patients' <Messages> is
tolerable, then the scenario you describe - moving the entire XML
message to "unmatchable" or even deleting it - would be the thing to
do.
l.
Re: [Gnumed-devel] downstream provisions for invalid HL7, plus time zones, Karsten Hilbert, 2010/08/12