Announcement

Collapse
No announcement yet.

Mirth inserts fields out of order if they don't already exist in the XML object

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mirth inserts fields out of order if they don't already exist in the XML object

    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.....
    Attached Files
    Last edited by narupley; 12-22-2011, 07:16 AM. Reason: Found and fixed a small bug...
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


    - How do I foo?
    - You just bar.

  • #2
    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.
    Jacob Brauer
    Director, Software Development
    NextGen Healthcare

    sigpic

    Comment


    • #3
      Fields out of order if they don't already exist

      Originally posted by jacobb View Post
      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.

      Comment


      • #4
        It looks like this problem persists.

        Comment


        • #5
          What issue are you facing ashish? Could you please elaborate.
          HL7v2.7 Certified Control Specialist!

          Comment


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

            Comment


            • #7
              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
              Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

              Nicholas Rupley
              Work: 949-237-6069
              Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


              - How do I foo?
              - You just bar.

              Comment


              • #8
                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?
                Last edited by bburkhart; 06-06-2019, 12:28 PM.

                Comment

                Working...
                X