Menu
▾
▴
hl7api-devel
|
From: Shrock, C. <Sh...@in...> - 2004-12-13 22:23:29
|
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 |
|
From: Tripp, B. <Bry...@uh...> - 2004-12-14 18:31:10
|
Hi Archie,=20 HAPI indeed won't give you what you want if the message doesn't have the core structure that it declares in MSH-9, which is fine (and I think unavoidable), but I agree that it should try to fail in that case. It's hard to tell legal local additions from a structural problem ... the = only way I can think to do this is to fail if the resulting message is = missing required segments. If you can think of a better way please let me know. But are you saying that a PV1 got parsed into an NK1? That would be a = bug that I don't know about. =20 Thanks,=20 Bryan=20 > -----Original Message----- > From: hl7...@li... > [mailto:hl7...@li...]On Behalf Of Archie > Cobbs > Sent: December 13, 2004 5:00 PM > To: hl7...@li... > Subject: [HAPI-devel] ADT^A13 bad parse >=20 >=20 >=20 > 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 .. >=20 > 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?). >=20 > 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. >=20 > 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? >=20 > 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. >=20 > Thanks, > -Archie >=20 > ______________________________________________________________ > ____________ > Archie Cobbs * CTO, Awarix * =20 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 |
|
From: Archie C. <ar...@de...> - 2004-12-14 19:20:46
|
Tripp, Bryan wrote: > HAPI indeed won't give you what you want if the message doesn't have the > core structure that it declares in MSH-9, which is fine (and I think > unavoidable), but I agree that it should try to fail in that case. It's > hard to tell legal local additions from a structural problem ... the only > way I can think to do this is to fail if the resulting message is missing > required segments. If you can think of a better way please let me know. Yes, this definitely seems like a hard problem to get right in every case. In this particular case, the message contained an unexpected (and unknown) segment (PD1). HAPI tries to parse the message anyway, which is good, but I'm not sure I understand how the PD1 segment ended up where it did (after ADT_A13.IN1IN2IN3/IN3) and why it caused NK1, PV1, PV2, OBX, etc to all be skipped and added later in the wrong place. Although getting it "right" is all cases is probably impossible, it seems like the case of an "extra" unexpected segment is probably a common one and maybe the parse recovery strategy should have a special case for it.. ? > But are you saying that a PV1 got parsed into an NK1? That would be a bug > that I don't know about. The PV1 parsed as NK1 was my fault, due to a cut & paste problem when pasting the HL7 into the HAPI tester Swing app (extra line breaks were introduced due to screen wrap). What actually happens is that the PV1 XML tag gets put inside the ADT_A13.IN1IN2IN3 tag, after the NK1 tag (along with OBX, etc.). Sorry for the misinformation. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com * Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. * |
|
From: Tripp, B. <Bry...@uh...> - 2004-12-15 21:10:35
|
Hi Archie,=20 Assuming we're in try-to-parse-everything mode, if a non-Z segment = appears that is not expected anywhere in the message, HAPI will assume it's a = legal local extension and put it at the end of the current group. This = approach can yield unexpected results, but only if there is an error in the = message. If I understand correctly, your suggestion was to look at later versions = of the same message structure and switch versions if it looks like one of = them matches better. I'm not enthusiastic about this, because early adopters (even long after the fact ;) sometimes incorporate segments from later versions into their messages, and because I think that quietly = correcting an error can lead to deeper confusion than either failing, or assuming = there is no error and returning the literal result of the call. =20 Another option would be to decorate a parser with something that guesses message structure and version. I.e. something you would use like this: = new VersionGuessingParserDecorator(new PipeParser()). How does that sound = to you? =20 Bryan=20 > -----Original Message----- > From: hl7...@li... > [mailto:hl7...@li...]On Behalf Of Archie > Cobbs > Sent: December 15, 2004 3:28 PM > To: Tripp, Bryan > Cc: hl7...@li... > Subject: Re: [HAPI-devel] ADT^A13 bad parse >=20 >=20 > Tripp, Bryan wrote: > > That's how HAPI was first implemented actually, and I agree=20 > it's the=20 > > safest. It was changed because there were several complaints from=20 > > people who use non-standard messages, and because the HL7=20 > spec says that=20 > > unexpected segments are to be ignored (presumably so that compliant=20 > > processors don't choke on messages with local additions). =20 > How about=20 > > making this a configurable option in HAPI 0.5, i.e. the=20 > 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 > That would be nice... my question though is whether the heuristic > for option #4 can be improved to handle an unknown non-Z segment > in the middle of a message. What it does now is not quite right. >=20 > Thanks, > -Archie >=20 > ______________________________________________________________ > ____________ > Archie Cobbs * CTO, Awarix * =20 > http://www.awarix.com >=20 >=20 > * > Confidentiality Notice: This e-mail message, including any=20 > attachments, is for the sole use of the intended recipient(s)=20 > and may contain confidential and privileged information. Any=20 > unauthorized review, use, disclosure or distribution is=20 > prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and=20 > destroy all copies of the original message. > * >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > 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 >=20 |
|
From: Archie C. <ar...@de...> - 2004-12-15 21:32:41
|
Tripp, Bryan wrote: > If I understand correctly, your suggestion was to look at later versions of > the same message structure and switch versions if it looks like one of them > matches better. I'm not enthusiastic about this, because early adopters > (even long after the fact ;) sometimes incorporate segments from later > versions into their messages, and because I think that quietly correcting an > error can lead to deeper confusion than either failing, or assuming there is > no error and returning the literal result of the call. Actually I agree with you that trying a later version is not the best idea.. it's the right thing to do sometimes but not always, so it shouldn't be mandatory. > Assuming we're in try-to-parse-everything mode, if a non-Z segment appears > that is not expected anywhere in the message, HAPI will assume it's a legal > local extension and put it at the end of the current group. This approach > can yield unexpected results, but only if there is an error in the message. This would fine with me, but it doesn't seem like this is what HAPI currently does. Instead, at least in the example I saw, it put *all* segements following the unknown segment at the end of the message. In my example, the unkown segment caused the XML tags to get moved like this: ADT_A13/NK1 -> ADT_A13.IN1IN2IN3/NK1 ADT_A13/PV1 -> ADT_A13.IN1IN2IN3/PV1 ADT_A13/OBX -> ADT_A13.IN1IN2IN3/OBX In the actual HL7 message, NK1, PV1, OBX, etc. came after the unknown segment but otherwise in their rightful places. > Another option would be to decorate a parser with something that guesses > message structure and version. I.e. something you would use like this: new > VersionGuessingParserDecorator(new PipeParser()). How does that sound to > you? Something like that would be a better way to handle cases where people wanted to do "guessing".. i.e., you'd have to explicitly ask for it. I'd guess most people will eventually end up asking for it unfortunately :-) Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com * Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. * |
|
From: Tripp, B. <Bry...@uh...> - 2004-12-15 21:57:17
|
Hi Archie,=20 =20 > This would fine with me, but it doesn't seem like this is what HAPI > currently does. Instead, at least in the example I saw, it put *all* > segements following the unknown segment at the end of the=20 > message. In my > example, the unkown segment caused the XML tags to get moved=20 > like this: >=20 > ADT_A13/NK1 -> ADT_A13.IN1IN2IN3/NK1 > ADT_A13/PV1 -> ADT_A13.IN1IN2IN3/PV1 > ADT_A13/OBX -> ADT_A13.IN1IN2IN3/OBX >=20 > In the actual HL7 message, NK1, PV1, OBX, etc. came after the unknown > segment but otherwise in their rightful places. If you have an unexpected segment, it goes at the end of the current = group (or end of the first subgroup reached), which is the only legal option. Then segments after it have to go after it, again the only legal option. HAPI won't re-order them. =20 On second thought, maybe we should add another option to that previous = list, i.e. quietly drop unexpected segments. Would that help in your case, or = did you want access to that PD1? =20 Bryan=20 |
|
From: Archie C. <ar...@de...> - 2004-12-15 22:12:40
|
Tripp, Bryan wrote: >>This would fine with me, but it doesn't seem like this is what HAPI >>currently does. Instead, at least in the example I saw, it put *all* >>segements following the unknown segment at the end of the >>message. In my >>example, the unkown segment caused the XML tags to get moved >>like this: >> >> ADT_A13/NK1 -> ADT_A13.IN1IN2IN3/NK1 >> ADT_A13/PV1 -> ADT_A13.IN1IN2IN3/PV1 >> ADT_A13/OBX -> ADT_A13.IN1IN2IN3/OBX >> >>In the actual HL7 message, NK1, PV1, OBX, etc. came after the unknown >>segment but otherwise in their rightful places. > > If you have an unexpected segment, it goes at the end of the current group > (or end of the first subgroup reached), which is the only legal option. > Then segments after it have to go after it, again the only legal option. > HAPI won't re-order them. What exactly do you mean by "legal"? It seems like the message is already illegal so trying to maintain any further legality is questionable... or else I'm misunderstanding things. I.e., I'm not sure it's worth messing up the legal segments just to make room for an illegal one (from the point of view of the XML output structure). > On second thought, maybe we should add another option to that previous list, > i.e. quietly drop unexpected segments. Would that help in your case, or did > you want access to that PD1? In this particular case dropping it would have been fine, as we don't look at PD1 segements in ADT^A13 messages (yet). Of course in general that may not be true. But the larget point is that ideally an unknown segment shouldn't "mess up" the rest of the message. I guess if the segment is unknown then just plain dropping it is a very reasonable thing to do. It's hard to say what is always right though, my experience with all the quirks of HL7 is limited. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com * Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. * |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X