Mirth Community

Mirth Community (http://www.mirthcorp.com/community/forums/index.php)
-   Support (http://www.mirthcorp.com/community/forums/forumdisplay.php?f=6)
-   -   Mirth inserts fields out of order if they don't already exist in the XML object (http://www.mirthcorp.com/community/forums/showthread.php?t=6401)

narupley 12-20-2011 08:47 AM

Mirth inserts fields out of order if they don't already exist in the XML object
 
1 Attachment(s)
Say we have the following transformer in a channel:

Code:

msg.MSH['MSH.19'] = 'English';
msg.MSH['MSH.11'] = 'P';
msg.MSH['MSH.12'] = '2.3';

If we send the following message to the channel:

MSH|^~\&|||||||ADT^A01|||

then we get the following encoded output:

MSH|^~\&|||||||ADT^A01||P|2.3|||||||English

as expected.

However, if we send the following message:

MSH|^~\&|||||||ADT^A01|

then we get:

MSH|^~\&|||||||ADT^A01||||||||||English|P|2.3

which is certainly not expected. This is because in the second case, the children <MSH.11> and <MSH.12> under the <MSH> node don't yet exist. Because we initialized MSH.11 and MSH.12 after MSH.19, they appear after MSH.19 in the XML tree. Well, that makes perfect sense to me. What doesn't make sense is why Mirth doesn't convert the XML correctly back into HL7. If we have the following XML:

Code:

<HL7Message>
    <MSH>
          <MSH.1>|</MSH.1>
          <MSH.2>^~\&amp;</MSH.2>
          <MSH.9>
              <MSH.9.1>ADT</MSH.9.1>
              <MSH.9.2>A01</MSH.9.2>
          </MSH.9>
    </MSH>
</HL7Message>

then Mirth knows that even though <MSH.9> comes right after <MSH.2>, it's not really the next field in the message; Mirth needs to pad some extra field separators in there. However, if some XML children are out of order, then Mirth apparently doesn't know where to put them, and so things get jumbled up.

I went ahead and wrote the following subroutine, which (in my opinion) should probably have been included in the default logic for the HL7 serializer in SerializerFactory.

Code:

function fixHL7NodeOrder(parent,node) {
        for each (child in node.children())
                if (child.hasComplexContent())
                        fixHL7NodeOrder(node,child);
        if (parent != node)
                parent.children()[node.childIndex()] = sortHL7Node(node);
}

function sortHL7Node(node) {
        if (node.hasSimpleContent())
                return node;
        var newNode = new XML('<'+node.name().toString()+'/>');
        for each (child in node.children()) {
                if (child.name()) {
                        curChildIndex = parseInt(child.name().toString().substring(child.name().toString().lastIndexOf('.')+1),10);
                        var inserted = false;
                        for (var i = 0; i <= newNode.children().length()-1; i++) {
                                loopChildIndex = parseInt(newNode.child(i).name().toString().substring(newNode.child(i).name().toString().lastIndexOf('.')+1),10);
                                if (curChildIndex < loopChildIndex) {
                                        newNode.insertChildBefore(newNode.children()[i],child);
                                        inserted = true;
                                        break;
                                }
                        }
                        if (!inserted)
                                newNode.appendChild(child);
                }
        }
        return newNode;
}

So now, let's consider the following transformer:

Code:

msg.MSH['MSH.19'] = 'English';
msg.MSH['MSH.11'] = 'P';
msg.MSH['MSH.12'] = '2.3';
fixHL7NodeOrder(msg,msg.MSH);

When we send the following message:

MSH|^~\&|||||||ADT^A01|

then we get:

MSH|^~\&|||||||ADT^A01||P|2.3|||||||English

as expected. Hope this helps.....

jacobb 12-20-2011 10:01 AM

Thanks for your input and solution. This is a known issue:
http://www.mirthcorp.com/community/i...owse/MIRTH-625

Fixing this issue makes the current parser much slower, but we are looking into a better solution for the next major release. The solution now is to make sure fields exist before you add new ones, or set values to non-existent fields in ascending order.

TheVulcanJedi 06-22-2015 11:17 AM

Fields out of order if they don't already exist
 
Quote:

Originally Posted by jacobb (Post 22526)
Thanks for your input and solution. This is a known issue:
http://www.mirthcorp.com/community/i...owse/MIRTH-625

Fixing this issue makes the current parser much slower, but we are looking into a better solution for the next major release. The solution now is to make sure fields exist before you add new ones, or set values to non-existent fields in ascending order.

We just ran into this issue last week and spent several hours wrangling with it on version 3.1.1.7461. I can see that it has been known since 2007. Although the workaround is straightforward enough, is any fix for it on the horizon? This would likely prevent some needless suffering by others in future and might also prevent a less experienced evaluator of Mirth from giving up on the product prematurely.

ashishshetty1992 05-22-2018 03:04 PM

It looks like this problem persists.

siddharth 05-22-2018 09:01 PM

What issue are you facing ashish? Could you please elaborate.

agermano 05-24-2018 10:06 AM

It is still an issue. I came across this a couple months ago. The simple workaround is to not add stuff out of order.

narupley 05-24-2018 10:11 AM

Yep... it's actually a tricky, non-trivial problem to solve because our parser streams the XML via SAX. If it encounters, say, <PID.3> and then <PID.5>, it will assume that PID.4 is not valued and add an extra pipe character in there.

In the meantime I did write a code template a while back to help out with this: https://www.mirthcorp.com/community/...4606#post24606

bburkhart 06-06-2019 12:20 PM

EDIT: My apologies, I was looking at the wrong comment on the post shared above (https://www.mirthcorp.com/community/...4606#post24606). I'm trying the solution recommended there!

I'm struggling with this issue right now. I'm re-creating an existing outbound ORU interface from another engine in Mirth, and creating multiple OBX segments giving me a hard time. I made a function in my source transformer to create and increment an OBX segment and to populate the fields that will be the same. I call that, then add fields like OBX-5. But then OBX-5 is at the end, and both the Mirth serializer and the function shared in the link above create the HL7 with OBX-5 at the end.

Has anyone come up with any creative solutions to this issue? Or will I need to repeat multiple lines of code each time I need to create another OBX, rather than use my function?


All times are GMT -8. The time now is 06:17 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Mirth Corporation