When you try to use BTAHL7 to receive and to process an HL7 v2.5.1 message, the parsing stage fails, and you receive an error message that resembles the following:
Event Type: Error
Event Source: BizTalk Accelerator for HL7
Event Category: None
Event ID: 4100
Date: <Date>
Time: <Time>
User: N/A
Computer: <Computer>
Description:
Validation error in header during parsing
Error # 1
Segment Id: MSH
Sequence Number: 1
Field Number: 7
Error Number: 102
Error Description: Data type error
Encoding System: HL7nnnn
Note This issue is caused by the MSH 7 Date/Time of Message field. This field contains a
DateTime data type value. However, this value is generated incorrectly as a
String data type value.
Issue 2Slow performance occurs when you process HL7 messages on a receive location that uses the Minimal Lower Layer Protocol (MLLP) adapter.
After you apply this hotfix, a new "Use Direct Synchronous HL7 ACK" setting is available in the MLLP Transport Properties configuration page. The setting improves performance in a Two Way receive port & location if the following conditions are true:
- The receive port is a two-way receive port, and the "Use Direct Synchronous HL7 ACK" option is set to "True" in the MLLP Receive port configuration.
Note If the receive port is a one-way port and this option is enabled, there is no performance improvement. - BizTalk HL7 DASM is used to generate the ACK.
Note You can achieve this by using the default BTAHL72XReceivePipeline or the BTAHHL7.HL72fDasm that is included with BizTalk HL7 Accelerator.
The “Route ACK to Send pipeline on request-response receive port” setting of the Source party must be in the HL7 Configuration explorer, and the Acknowledgement Type must be set to a value that is not "None."
Be aware that in the other scenarios where the ACK is not generated by the BizTalk HL7 DASM (for example, the ACK is given by the downstream system and is given to the send adapter which in turn is submitted to EPM, and which in turn is routed to the receive port and also to the upstream system or another disassembler is used) there is no performance improvement. The HL7 ACK will still be routed back to the upstream system successfully.
This change enables BizTalk to receive more messages. This expedes processing on the send side for send ports that are subscribed to the receive port. Also, when the "Use Direct Synchronous HL7 ACK" option is changed, you must restart the host instance to see the behavior change by using the "BizTalk:Messaging:Documents received/Sec" Performance Monitor Counter.
Issue 3Additional support for the following acknowledgement codes is enabled on two-way MLLP send ports.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
973909 FIX: Event IDs 5812, 5743, and 5754 are logged when you use BizTalk 2009 Accelerator for HL7 (BTAHL7)
Issue 4When you change the
XPN_0_0Surname field in the
ORU^R01 schema, and then you use the schema to submit a message that does not contain a value in the
PID_6 field, you receive a validation error message.
When you change the value of the
minOccurs attribute from
0 to
1 for the
PID_6 and
XPN_0_0_Surname fields in the
ORU^R01 schema, you expect the following behavior to occur:
- If an ORU_R01 incoming message does not have a value in the PID_6 field, the message is valid.
- If an ORU_R01 incoming message has a value in any of the PID_6 subfields, and the XPN_0_0_Surname field is present, the message is valid.
- If an ORU_R01 incoming message has a value in any of the PID_6 subfields, and the ORU_R01 incoming message has no value in the XPN_0_0_Surname field, the message is not valid.
Note This expected behavior meets federal guidelines.
Issue 5ACK processing fails because of a mismatch between the
MessageType schema, the
DocSpecType schema, and the
SchemaStrongName schema. When this issue occurs, an error that resembles the following is logged in the xlang/s engine event log:
Uncaught exception (see the 'inner exception' below) has suspended an instance of service'<Service Instance Name>' .
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: <Instance ID>
Shape name:
ShapeId:
Exception thrown from: segment -1, progress -1
Inner exception: Received unexpected message type '<Message Type>, BTAHL7V2XCommon, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6f98b98dc03f2db5' does not match expected type '<Message Type>, BTAHL7V2XCommon, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6f98b98dc03f2db5'.
Exception type: UnexpectedMessageTypeException
Source: Microsoft.XLANGs.Engine
Target Site: Void _verifyPublisherSchema()
Issue 6The value of the
minOccurs attribute is changed from
0 to
1 in the following schemas to meet federal guidelines:
<xs:complexType name="EI">
<xs:element minOccurs="0" name="EI_2_UniversalId" type="ST_L199" />
<xs:element minOccurs="0" name="EI_3_UniversalIdType" type="ID_301" />
<xs:complexType name="CX">
<xs:element minOccurs="0" name="CX_3_AssigningAuthority">
<xs:element minOccurs="0" name="CX_4_IdentifierTypeCode" type="ID_203" />
This hotfix enables the Minimal Lower Layer Protocol (MLLP) adapters to handle multiple connections to same MLLP port.