Mirth Connect中OBR段字段移位函数出现XML标签冗余问题的解决咨询

Got it, let's tackle this issue where your OBR field shift is pulling in XML tags instead of just the field values. The root cause here is that when you use toString() on the XML node (obr['OBR.' + j].toString()), you're grabbing the entire XML structure of that field, not just the actual HL7 value. Here are three solid solutions to fix this:

Solution 1: Use Mirth's Built-in getElementValue() Method #

Mirth has a dedicated function to extract the raw text value from HL7 message nodes, which automatically strips out XML tags and handles HL7 component separators correctly.

function testFunction(){
    for (var i = 0; i < msg['OBR'].length(); i++){
        var obr = msg['OBR'][i];
        var totalFields = obr.children().length();
        
        // Process fields in reverse to avoid overwriting data prematurely
        for (var j = totalFields; j >= 24; j--){
            // Get the pure text value without XML tags
            var currentValue = getElementValue(obr['OBR.' + j]);
            // Assign to the next field
            obr['OBR.' + (j + 1)] = currentValue;
            // Clear the original field
            obr['OBR.' + j] = '';
        }
    }
}

Why this works: getElementValue() recursively pulls all text content from the node, including concatenating sub-components with the HL7 ^ separator. For example, it'll turn <OBR.4><OBR.4.1>73030P</OBR.4.1><OBR.4.2>CR SHOULDER...</OBR.4.2></OBR.4> into the correct HL7 value 73030P^CR SHOULDER COMPLETE PROFESSIONAL READ.

Solution 2: Manually Extract Component Values (For Fine Control) #

If you need more control over how sub-components are handled, you can write a helper function to iterate through each component and build the field value yourself.

// Helper function to build HL7 field value from components
function getHL7FieldValue(fieldNode) {
    var componentValues = [];
    var components = fieldNode.children();
    
    for (var k = 0; k < components.length; k++) {
        // Get text from each sub-component
        componentValues.push(components[k].toString());
    }
    
    // Join with HL7 component separator
    return componentValues.join('^');
}

function testFunction(){
    for (var i = 0; i < msg['OBR'].length(); i++){
        var obr = msg['OBR'][i];
        var totalFields = obr.children().length();
        
        for (var j = totalFields; j >= 24; j--){
            var fieldNode = obr['OBR.' + j];
            var currentValue = getHL7FieldValue(fieldNode);
            
            obr['OBR.' + (j + 1)] = currentValue;
            obr['OBR.' + j] = '';
        }
    }
}

Use case: This is useful if you need to modify component values before shifting, or if you want to handle empty components differently.

Solution 3: Use Mirth's HL7Message API (Most Reliable for HL7) #

For a more robust approach that works directly with HL7 message structure (instead of XML nodes), use Mirth's HL7Message object. This avoids XML-related issues entirely.

function testFunction(){
    // Convert the DOM message to an HL7Message object
    var hl7Msg = new HL7Message(msg);
    var obrSegments = hl7Msg.getSegments('OBR');
    
    for (var i = 0; i < obrSegments.length; i++){
        var obr = obrSegments[i];
        var totalFields = obr.getFieldCount();
        
        // Shift fields from highest index down to 24
        for (var j = totalFields; j >= 24; j--){
            // Get the field value (handles components automatically)
            var currentValue = obr.getField(j);
            // Set the value to the next field
            obr.setField(j + 1, currentValue);
            // Clear the original field
            obr.setField(j, '');
        }
    }
    
    // Convert the modified HL7Message back to the DOM msg object
    msg = hl7Msg.getDOM();
}

Why this is best: The HL7Message API is designed specifically for HL7v2 messages, so it understands field indices, components, separators, and repeats natively. This reduces the chance of edge cases (like repeating fields or empty components) breaking your shift logic.

Key Note: Always Process Fields in Reverse #

Notice all solutions use a reverse loop (j = totalFields; j >=24; j--). This is critical—if you process fields from 24 upwards, you'll overwrite the next field's value before you can shift it, leading to data loss.

Testing this with your sample OBR segment should result in the expected output: OBR.24 is empty, OBR.25 contains just F, and no XML tags are included in any shifted fields.

内容的提问来源于stack exchange，提问作者B. Smith