rbeckman-nextgen / test-mc6

0 stars 0 forks source link

Setting tmp fields not in ascending order will cause the indicies to be off in the resulting message #609

Open rbeckman-nextgen opened 4 years ago

rbeckman-nextgen commented 4 years ago

Setting tmp fields not in order will cause the indicies to be off in the resulting message

i.e.

Set PID2.4 then set PID2.3 and it will put too many pipes in the message.

Imported Issue. Original Details: Jira Issue Key: MIRTH-625 Reporter: brendanh Created: 2007-11-16T10:49:02.000-0800

rbeckman-nextgen commented 4 years ago

The Mirth XML to ER7 engine uses SAX, a streaming engine. Once we write out a field (say PID.5.3) the parser moves the cursor forward and is unable to backtrack to set an earlier field (i.e. PID.5.1).

A potential solution hold the segment in memory while parsing and not write to stream until End of Segment is reached. This would create much more overhead and slow down the parser, so let's investigate for 2.0 and see if there are better ways to accomplish this.

Imported Comment. Original Details: Author: chrisl Created: 2007-11-20T19:34:19.000-0800

rbeckman-nextgen commented 4 years ago

Or you could keep track of the last field that was updated and if the new field comes before the last one, raise an error. At least the developer would know something didn't work right.

John

Imported Comment. Original Details: Author: jlehew Created: 2007-11-29T08:39:50.000-0800

rbeckman-nextgen commented 4 years ago

Tested with the following JavaScript step and it fails:

createSegment('OBX', tmp);

tmp['OBX']['OBX.4']['OBX.4.1'] = "obx41"; tmp['OBX']['OBX.2']['OBX.2.1'] = "obx21";

Imported Comment. Original Details: Author: jacobb Created: 2008-02-22T13:05:13.000-0800

rbeckman-nextgen commented 4 years ago

MIRTH-1609 was a duplicate of this issue and has more information.

Imported Comment. Original Details: Author: jacobb Created: 2010-11-09T17:12:55.000-0800

rbeckman-nextgen commented 4 years ago

Temporary solution, if you need your code to add fields out of order, etc.: \ \ ` msg = fixHL7NodeOrder(msg);

function fixHL7NodeOrder(node) { // Create output node var newNode = new XML(); // In case the node is an XMLList of multiple siblings, loop through each sibling for each (sibling in node) { // Create new sibling node var newSibling = new XML('<'+sibling.name().toString()+'/>'); // Iterate through each child node for each (child in sibling.children()) // If the child has its own children, then recursively fix the node order of the child if (child.hasComplexContent()) newSibling.appendChild(fixHL7NodeOrder(child)); // If the child doesn't have its own children, then just add the child to the new sibling node else newSibling.appendChild(child); // After recursively fixing all of the child nodes, now we'll fix the current node newNode += sortHL7Node(newSibling); } // Return the fixed node return newNode; }

// Helper function for fixHL7NodeOrder function sortHL7Node(node) { // If the node has no children, then there's nothing to sort if (node.hasSimpleContent()) return node; // Create new output node var newNode = new XML('<'+node.name().toString()+'/>'); // Iterate through each child in the node for each (child in node.children()) { // If the child has a QName, then we can sort on it if (child.name()) { // Get the current "index" of the child. Id est, if the QName is PID.3.1, then the index is 1 curChildIndex = parseInt(child.name().toString().substring(child.name().toString().lastIndexOf('.')+1),10); // Boolean placeholder var inserted = false; // Iterate through each child currently in the NEW node for (var i = 0; i <= newNode.children().length()-1; i++) { // Get the index of the child of the new node loopChildIndex = parseInt(newNode.child(i).name().toString().substring(newNode.child(i).name().toString().lastIndexOf('.')+1),10); // If the child we want to insert has a lower index then the current child of the new node, then we're going to insert the child // right before the current newNode child if (curChildIndex < loopChildIndex) { // Insert the child newNode.insertChildBefore(newNode.children()[i],child); // Set our flag, indicating that an insertion was made inserted = true; // No need to continue iteration break; } } // If no insertion was made, then the index of the child we want to insert is greater than or equal to all of the // indices of the children that have already been inserted in newNode. So, we'll just append the child to the end. if (!inserted) newNode.appendChild(child); } } // Return the sorted HL7 node return newNode; }`

Imported Comment. Original Details: Author: narupley Created: 2011-12-22T08:20:30.000-0800

rbeckman-nextgen commented 4 years ago

Is this on the road map to be fixed? Also, shouldn't this be classified as a bug?

Imported Comment. Original Details: Author: kirbykn2 Created: 2016-04-11T07:16:36.000-0700

rbeckman-nextgen commented 4 years ago

Don't think this was ever fixed. I still have the same issue while building HL7 messages. That is, if we don't assign values to fields in the order of their occurrence in the HL7 message, the message segment goes haywire.

Imported Comment. Original Details: Author: ashishshetty1992 Created: 2018-02-16T09:56:28.000-0800