HL7 accelerator error: Schema not found (after upg

Question

On a dev machine, we upgraded a BizTalk 2010 server to BizTalk 2013. We are sending HL72 messaves from another machine to this one and getting a schema not found error:

Alternate Error Number: 301 Alternate Error Description: Schema http://microsoft.com/HealthCare/HL7/2X#ORU_R01_23_GLO_DEF not found Alternate Encoding System: HL7-BTA

The message specifies "LAB" as the sending application, and we have a party called "LAB" which specifies "http://mycompany/myapplication/HL7/2X/2.3/ORU/v1" as the schema namespace, so we can't figure out why it's looking for the ORU R01 2.3 schema in the default microsoft namespace.

Our message looks as follows:

MSH|^~\&|LAB|ABC|LAB||201311071138||ORU^R01|D2863329|D|2.3|
PID|1|A00003766|XX00014202|9191610101|Ihhendrickson^Plis||19691202|M|||8423 Panko Pvt^^Here^BC^XXX XXX||111-1111|||||xx0055355x3|9x9x6x0x0x|
PV1|1|R|TRAKBHLB||||93190^Plisihd^xxxxxx^^^Dr^^xxxxxx|||||||||||RCR||BC|||||||||||||||||||xxxxx||REG|||201207261453|
ORC|RE|PT80755100.0010|||CM|N|||201311071138|^xxxxxx^Linda^^^^^xxxx||93190^xxxx^Aaron^^^Dr^^xxxx|xxx|
OBR|1|PT0711:T00001R100.0010|PT0711:T00001R|100.0010^Group \T\ Screen^00050252^34532-2^Blood Type \T\ Indirect Antibody Screen^pCLOCD|R|201311071004|201311071004|||G|||PLIS Testing|201311071004|T|93190^Plisihd^xxx^^^Dr^^Pxxxxx||00050252|||xxx|201311071004||BBK|F|||93190^xxx^Aaron^^^Dr^^xxxx|
NTE|1||Date required: 20131107|
NTE|2||Any previous transfusions? Unknown|
NTE|3||Specify any underlying blood disorders: U|
NTE|4||Has consent for blood products been obtained? Yes|
OBX|1|ST|150.0100^Patient Blood Group^00050252^882-1^Blood Type \T\ Indirect Antibody Screen^pCLOCD||OPOS^O Rh Pos|||||A~S|F|||201311071137|xx^xx^L|IH001^^Blood Group^Patient Blood Group^150.0100|
OBX|2|ST|200.0100^Ab Screen Gel^00050252^XBC1931-6^Blood Type \T\ Indirect Antibody Screen^pCLOCD||NEGATIVE^NEGATIVE|||||A~S|F|||201311071138|xx^xx^L|IH001^^Ab Scr Gel^Antibody Screen Gel^200.0100|
ZDR||xxx^xxxx^Aaron^^^Dr^^^^^^^^^ATP|
ZPR||

Anyone have ideas we should try?

Answer 1

There are know issues with doing a BizTalk 2010 to BizTalk 2013 in-place upgrade, possibly it is due to one of the below. It would be best not to do in in place upgrade, but rather do a clean install and migrate applications.

1. In Place upgrade of BizTalk 2010 to BizTalk 2013 does not update the Microsoft.BizTalk.GlobalPropertySchemas
2. Upgrading BizTalk Server 2010 to 2013 – need to provision permissions on BizTalkMgmtDb.bts_dynamic_sendport_handlers table
3. Upgrading to BizTalk 2013–Could not load file or assembly "’Microsoft.BizTalk.Interop.SSOClient

Answer 2

For send ports, the HL7 2.X Assembler component is supposed to use the MSH 5 field value to determine the party to use. The pipeline configuration on your send port should have an option to enable partial name resolution (EnablePartialNameResolutionForReceivingApplication), which—when turned on—may help.

In receive locations, the HL7 2X Disassembler component should use MSH 3 for party resolution. The receive location's BTAHL72XReceivePipeline configuration has settings called EnablePartialNameResolutionForSendingApplication and EnablePartialNameResolutionForReceivingApplication for you to turn on.

Older versions of BizTalk required a hotfix to make those settings work, but that should no longer be necessary. From that page, the description of the settings are:

For the send pipeline, the BTAHL7 2.X assembler contains the following property:

Property name: Enable Partial Name Resolution For Receiving Application 
Default value: False 
Description for the property:
First check party with name MSH5.1 + MSH5.2 + MSH5.3. If not found, check party with name MSH5.1 + MSH5.2. If not found, check with name MSH5.1. 

For the receive pipeline, the BTAHL7 2.X disassembler contains the following properties:

Property name: Enable Partial Name Resolution For Receiving Application 
Default value: False 
Description for the property:
First check party with name MSH5.1 + MSH5.2 + MSH5.3. If not found, check party with name MSH5.1 + MSH5.2. If not found, check with name MSH5.1.
Property name: Enable Partial Name Resolution For Sending Application 
Default value: False 
Description for the property:
First check party with name MSH3.1 + MSH3.2 + MSH3.3. If not found, check party with name MSH3.1 + MSH3.2. If not found, check with name MSH3.1.

If that does not help, then there is one other thing to try for send ports only: In the party configuration, try assigning the party to your send port, as described in step three here. That's one way to try to force it to use the proper party. That will not help with receive locations, though.