RE: [HAPI-devel] ADT^A13 bad parse

[Shrock, C. <Sh...@in...>]

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. 

Cheers,
Court

-----Original Message-----
From: Archie Cobbs [mailto:ar...@de...] 
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
information 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. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Hl7api-devel mailing list
Hl7...@li...
https://lists.sourceforge.net/lists/listinfo/hl7api-devel