OBX5 in an ORU message is supposed to be the data type specified in OBX2. In our implementation there are 13 possible data types. The accelerator segment schema,for OBX5, specifies a "varies" complex data type that is really an ST data type. Any OBX5 message containing a compound datatype fails validation - probably because it has unescaped reserved characters.

Has anyone found a way to use the accelerator to properly validate the OBX5 construct,for multiple possible datatypes?

I tried to implement multiple OBX5 datatypes by modifying the segments xsd as follows

<xs:element minOccurs="0" maxOccurs="1" name="OBX_5_ObservationValue">
        <xs:complexType>
         <xs:choice>
          <xs:element name="CWE_Type" type="ns0:CWE"/>
          <xs:element name="NM_Type" type="ns0:NM"/>
          <xs:element name="SN_Type" type="ns0:SN"/>
          <xs:element name="DT_Type" type="ns0:DT"/>
          <xs:element name="ST_Type" type="ns0:ST"/>
         </xs:choice>
        </xs:complexType>
   </xs:element> 

Visual Studio "thinks" this is valid. It also generates an instance with a OBX5 CWE data type.

The BizTalk HL7 Accelerator fails the message for the following

XmlSchemaSequence not found under element OBX_5_ObservationValue

Complex node with path OBX_ObservationResult\OBX_5_ObservationValue has an invalid child count of 0

 Bob 

Bob, see if this thread is helpful as the error for body parsing is same. But this thread also mention an error related to the filed 11 of MSH segment.

Thanks. But it doesn't appear to be the same.

My basic question is how does the HL7 accelerator parse a field that,correctly, has different data types from message to message. OBX5 is the only example I know. There may be others.

I was getting the error from my attempt at a workaround I developed because I think that the accelerator can't correclty parse a field with different data types from message to message.

It depends on how your partner implements the HL7 protocol.

I do text transforms at the pipeline, to translat messages between BizTalk HL7 and the partner dialect. You can probably add a pipeline component after the HL7 assembler that translates your components from encoded ST to whatever structure you need.

I changed the datatype into the base CE datatype, that way providers can send CE, NM, or ST datatypes without schema validation failure.

 

I'm needing to do other semantic data validations (ex. all data for patients under 18 contains guardian data), so I just validate that this field is consistent in that custom validation code.

 

I do not think you can do these kinds of validations with the DASM alone.

Our problem is on the receiver (DASM) side.

We are receiving valid HL7 messages. The DASM can't properly parse and validate them.

I understand that, Gensa. My previous post explains how to get around it.

Bon,

Thanks. Unfortunately we need to also deal with the CWE and DT data types. These are compound data types.

I will change the base data type to CWE and see if it doesn't fail the simple data types.

I think that the DASM can't properly process these constructs. It needs to in order to claim that the Accelerator can process HL7 compliant messages.

 

Bob

Yeah, CWE would work too. CE is the most complex we needed for our purposes.

 

And I agree that its inability to process OBX5 makes the DASM advertise falsely its capabilities. 

• Edited by Bon Franklin Thursday, October 20, 2011 7:39 PM

Yeah, CWE would work too. CE is the most complex we needed for our purposes.

 

And I agree that its inability to process OBX5 makes the DASM advertise falsely its capabilities. 

• Edited by Bon Franklin Thursday, October 20, 2011 7:39 PM

Yeah, CWE would work too. CE is the most complex we needed for our purposes.

 

And I agree that its inability to process OBX5 makes the DASM advertise falsely its capabilities. 

• Edited by Bon Franklin Thursday, October 20, 2011 7:39 PM

Hi Bob,

I am having similar issue, OBX-5 is coming as a complex type and simple type in the same message(ORU^R01), so i changed the OBX_5 to CE, it now passes the validation etc on the receive side but fails in the send pipeline with following error:

Error happened in body during serialization

Error # 1

Segment Id: OBX_ObservationResult

Sequence Number: 1

Field Number: 5

Error Number: 207

Error Description: Application internal error

Encoding System: HL7nnnn

Alternate Error Number: Z100

Alternate Error Description: A text node with value '1.7' was found inside a complex element. It can only occur within a simple element

Alternate Encoding System: HL7-BTA

 

Error # 2

Segment Id: OBX_ObservationResult

Sequence Number: 1

Error Number: 207

Error Description: Application internal error

Encoding System: HL7nnnn

Alternate Error Number: Z100

Alternate Error Description: The element 'OBX_5_ObservationValue' has an invalid structure

Alternate Encoding System: HL7-BTA

Has anyone else got this error? I am stuck and not sure whats the bext way to deal with this error?

Hi Bob, this was some time ago but do you recall finding a solution for this?  I am trying to parse a HL7 message with potentially multiple types specified in the OBX2 field which should tell the HL7 dissassembler which type to use to parse the message.

Any help much appreciated.

Dino