Hi Nico,=20
=20
That's how HAPI was first implemented actually, and I agree it's the =
safest.
It was changed because there were several complaints from people who use
non-standard messages, and because the HL7 spec says that unexpected
segments are to be ignored (presumably so that compliant processors =
don't
choke on messages with local additions). How about making this a
configurable option in HAPI 0.5, i.e. the options would be:=20
=20
1) Fail if there are any unexpected segments
2) Fail if there are any unexpected non-Z segments=20
3) Fail if any required segments are missing=20
4) Try to parse everything =20
=20
Bryan=20
-----Original Message-----
From: hl7...@li...
[mailto:hl7...@li...]On Behalf Of
ni...@sk...
Sent: December 14, 2004 2:10 PM
To: Sh...@in...; hl7...@li...
Subject: RE: RE: [HAPI-devel] ADT^A13 bad parse
Hi,
=20
My opinion on this is that HAPI should be able to detect non-standard
segments in a message structure (eg the PD1 segment that is not allowed =
in
2.2 ADT) an stop parsing when these kind of errors are encountered.
=20
If customisation is required Z-segments, or custom messagestructures =
should
be used. Hapi should not block processing of course when a Z-segment is
encountered.
=20
I think that this makes sense because if you don't follow "the rules" =
one
day you'll come accross an application which has to process your =
"modified"
message that won't be able to process your message and reject the =
message.
=20
Best Regards
=20
Nico
_____ =20
I have run into the same thing. After digging further, I have realized =
that
at my company, the HL7 specification has been modified at will in many
different places. The result is that I must create my own modified model
implementation to match the structure of the messages that I end up =
seeing.=20
Cheers,
Court
-----Original Message-----
From: Archie Cobbs [mailto:ar...@de...]=20
Sent: Monday, December 13, 2004 2:00 PM
To: hl7...@li...
Subject: [HAPI-devel] ADT^A13 bad parse
We received an ADT^A13 message that has "2.2" in the MSH.12 field, but
contained these segments: MSH EVN PID PD1 NK1 PV1 PV2 OBX AL1 DG1 DG1 =
GT1
IN1 IN2 ..
Note that the ability to include the "PD1" segment was added in 2.3. So
technically this is a bogus message because it says "2.2" but has a PD1
segment (right?).
In any case, HAPI happily parses this message but the resulting XML =
contains
inform! ation in the wrong places, etc. For example, the PV1.3 =
information
ends up in ADT_A13.IN1IN2IN3/NK1/NK1.40.
So although it's nice that HAPI handles this message at all, it seems =
like
it doesn't do so very gracefully. Is this the intended behavior?
Could HAPI be configured to try a later version of the spec if the =
message
doesn't parse correctly, instead of putting things in the wrong field? =
It
seems like in practice the MSH.12 field is sometimes just more of a hint
than reality.
Thanks,
-Archie
_________________________________________________________________________=
_
Archie Cobbs * CTO, Awarix * http://www.awarix.com
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
|
