I’ve found quite some bugs (no Microsoft, this is not by design, these are bugs) in the HL7 accelerator for BizTalk. I will try and post some solutions for these bugs over here.

First one: The NTE_NotesAndComments segment is not unique. And because HL7 is a flat file with everything on the same level, the definition of the schemas of HL7 version 2.4 is incorrect! This will eventually cause that some or the wrong NTE segments are being mapped.

The problem

In an ORM 2.4 message for instance, the NTE segment can be on different places in the message, but all the NTE segments can have different meanings. Naming the parsed NTE segments the same will cause problems.

The schema below, is the schema Microsoft provides us with. The NTE segments in the different places are all named NTE_NotesAndComments. Since it’s all placed under the rootnode, the BizTalk mapper can’t guess which NTE segment is being mapped and adds an indexer to the xpath.

(Click to enlarge)

If the third NTE_NotesAndComments is being mapped from the schema above, the BizTalk mapper will generate an xpath in the xslt that resembles this, which is not desirable:

/ORM_O01/NTE_NotesAndComments[3]

So if we receive a message, which does not contain the first two NTE segments, but only the third, we’ll have some kind of a problem, wouldn’t we? If the first two aren’t present and BizTalk mapper wants to map the third one, how is it gonna do that? Precisely! It’s not! So we need a way to get rid of this index number.

The solution

The solution is quite simple. Update the name of the elements to be unique. Like below, I’ve changed the not-so-unique NTE_NotesAndComments to a unique name. In the example below with a suffix containing a number (_1, _2 etc):

(Click to enlarge)

Now the NTE segments will be distinguishable and the mapper will not create an index for the xpath being mapped. It will now generate an xslt mapping NTE_NotesAndComments_3, instead of NTE_NotesAndComments[3].