namshub

Does any one who use this accelerator receive repeating obx 5 fields?

I'm trying to understand this field. We use the TX data type for that field
and the specification supports up to 64k of text and is repeatable (well
thats how I read the HL7.org specs).

I noticed though if a "~" is displayed in this field BizTalk generates a
parse failure, which I'm sure is incorrect.

Can anyone prove or disprove this theory with your data?

eric stott

The MSH 2 has a ~ in the element, correct?
If so, that character will need to be escaped by either \Xhh\ where hh is
the hex value for that character, or \R\ which is the repetition separator.
Eric
http://stottcreations.com/blog

dm

Wrong. If MSH-2 lists the tilded '~' as the repeast character, then the
presentation of the OBX-5 is clearly a collection of repeating lines of
text, typically from a transcribed report. A quality HL7 parser will
correctly recognize the repeating properties of this field when presented as
described by Namshub.

I review this newsgroup as one who has used _several_ HL7 interface
products, including Biztalk. I am frequently disappointed when I read about
HL7 features & functionality in the HL7 adapter as described by posters
here.

eric stott

Sorry,
It was my understanding from the post that the ~ was part of the data, and
not a delimiter. And yes, in that case the accelerator is not behaving
correctly.

tom canter - neudesic

Eric Stott,
I have reviewed (yet again) the OBX 5 field and it is the most
confusing and vague field definition I have ever seen.
7.3.2.5 (v2.3.1)
"Definition: This field contains the value observed by the observation
producer. OBX-2-value type contains the data type for this field
according to which observation value is formatted. It is not a
required field because some systems will report only the
normalcy/abnormalcy (OBX-8), especially in product experience
reporting."
"OBX-5-observation value is a general field definition that is
influenced by the data type OBX-3"

Influenced? What the heck does that mean... does the phases of the moon
influence it too?

In addition, if you review the notes in chapter 7 about this field, it
basically says that anything goes... Partial results etc:
"Though two independent diagnostic statements cannot be reported in one
OBX segment, multiple categorical responses are allowed (usually as CE
data types separated by repeat delimiters), so long as they are
fragments (modifiers) that together construct one diagnostic
statement."

You gotta love it "usually as CE data types" but hey, it might be sent
in Semaphore code?

Namshub,
If you have a repeating TX datatype for this field, then I recommend
that you set the field to Repeat (unbounded) and make sure the datatype
is set to TX so that the parser understands it.
Out of curiosity, does the OBX.2 indicate the OBX.5 data type as TX?

The design of the BizTalk Schemas is to allow you to modify them as
necessary to meet your particular needs. This is clearly a case in
which this would be appropriate.

Of course, as a TX datatype, it does have to follow the section 2.9
rules for USE OF ESCAPE SEQUENCES IN TEXT FIELDS.

Thanks for pointing out another hole in my understanding of HL7!
We all learn everyday a little more.

Thanks,
Tom Canter
Neudesic

namshub

To All.....Thanks....

As you are probably all aware suppliers also have difficulty sticking to the
definitions defined by the HL7.org so that doesn't make life any easier.

It turns out in this instance that there was a bug in the suppliers
interface (though they didn't explain what type of bug) my guess would be
that they didn't parse the ~ character.

Yes we are using the TX format although I think it should be a FT format (as
the result value is a textual report with formating as it is a cellular
pathology report)

So what you are saying is the schema has been initially set up wrong, but
can be easily changed which is what I thought. Just surprised no one has
noted this before.