I agree - As far as I know the OMG^O19 did not change in 2.5. I just find
it troublesome that new 'global rules' such as the ones in section 2.5.2
does not apply for all messages, but only newly defined. I guess I'll just
have to live with that.
2012/11/20 christian ohr <christian....@icw.de>
>
> 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
>
--
Med venlig hilsen / Kind regards
Jens Kristian Villadsen
cand.polyt
Systemudvikler / System developer
IM (Skype): j.kidd.o
Cetrea A/S, Denmark
phone : +45 38 40 05 81
address: Brendstrupgårdsvej 21F, DK-8200 Aarhus N.
e-mail : j...@cetrea.com
w^3 : http://www.cetrea.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
