The definition for OMG^O19 did not change in 2.5 - the first segment in that group is still optional. I don't think this statement in the spec does anything about this - it's just that any new messages structures (introduced in 2.5 and after) may not contain optional segments as first element in a group. But I'll check this with a 'real' HL7 expert.
Christian jkiddo wrote: > > Okay, I get your point - the keywords in the note was "newly defined" ... > I'm just thinking that it's a weird way of maintaining backwards > compatibility - gotta blame that on the specification, this is of course > not HAPI's fault ;) > > If, for instance the OMG^O19 was defined in, say the 2.4 spec (which seems > to be the case) - then of course the semantics and rules defined in 2.4 > would apply to a OMG^O19 message if it was sent with the value of 2.4 in > the MSH-12. > > Now, lets say that a new specification arrived - and we called it 2.5 - > now > if we sent the OMG^O19 again to the same system with the value of 2.4 in > the MSH-12, I would expect the exact same to happen. Now, if I changed the > value of MSH-12 to 2.5 I would expect the 2.5 rules to apply and not the > rules for 2.4, just because the OMG^O19 originally was defined in > 2.4, which evidently seems to be the case. I am of course aware of that > the > receiving system in that case needs to implement multiple version support, > but IMHO that seems to be the most correct way of doing it, or am I > totally > sidetracked? > > > On 19 November 2012 17:19, christian ohr <christian....@icw.de> wrote: > >> >> OMG_O19 is one of the messages which may be hard to parse unambiguously. >> The >> problem lies in the fact that the ORDER_PRIOR group begins with an >> *optional* ORC segment. So, the sequence ORC TQ1 OBR can be parsed in >> both >> ways Søren described it, and there is virtually no means for HAPI to pick >> the "right" possibility. The dummy BLG in fact disambiguates the parsing. >> I guess HAPI parsing happens in a "first match" fashion in that it picks >> the >> first possibility in a depth-first manner (in this case, the nested group >> is >> used instead of the sibling group). >> >> The note stated in the 2.5 spec says that groups defined in later >> versions >> must begin with an non-optional segment, but since OMG_O19 has been >> defined >> in a previous version. this statement does not apply. As such I don't see >> a >> real bug here. >> >> This is certainly unsatisfying and there are certainly a whole number of >> other ambiguities in the HL7 standard as well. >> Instead of disambiguating dummy segments, here's another possibility: if >> your OMG_O19 should never contain ORDER_PRIOR groups, you can define a >> custom message structure along with a custom ModelClassFactory that >> defines >> OMG_O19 *without* this group or with mandatory ORC segment at the >> beginning >> or whatever is necessary to disambiguate parsing such a message in your >> case. >> >> regards >> Christian >> >> >> Well, according to the standard - section 4.4.4, it is stated that the >> BLG >> segment is optional. I think there might be a bug, in that it seems that >> the parser does not respect the rule stated at Page 2-7, section 2.5.2: >> >> "... *As of v 2.5, the first segment in a newly defined segment group >> will >> be required to help ensure that unparsable messages will not be >> inadvertently defined. ...*" >> >> - Which means that a PID segment would have been required if the second >> ORC >> should have belonged to the prior results. >> >> IMHO, this is a bug in HAPI. >> >> Perhaps James Agnew or Christian Ohr would care to comment on this? >> >> >> >> -- >> View this message in context: >> http://old.nabble.com/Handling-HL7-ambiguity-in-OMG-message-tp34600431p34696226.html >> Sent from the hl7api-devel mailing list archive at Nabble.com. >> >> >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Hl7api-devel mailing list >> Hl7api-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/hl7api-devel >> > > > > -- > > Med venlig hilsen / Kind regards > > *Jens Kristian Villadsen* > cand.polyt > > Kantorvænget nr. 161 > 8240 Risskov > Denmark > > Mobile +4523373806 > jenskristianvillad...@gmail.com > jkiddo.dyndns.org > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Hl7api-devel mailing list > Hl7api-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hl7api-devel > > -- View this message in context: http://old.nabble.com/Handling-HL7-ambiguity-in-OMG-message-tp34600431p34700432.html Sent from the hl7api-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Hl7api-devel mailing list Hl7api-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hl7api-devel
