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
