Menu
▾
▴
RE: RE: [HAPI-devel] ADT^A13 bad parse
|
From: Tripp, B. <Bry...@uh...> - 2004-12-14 19:52:57
|
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 |
