While I love this idea (and have voted for it!) I think it would be ideal to generalize it into the concept of themes. I've elaborated on my reasoning in a comment on the idea @Yone Moreno Jiménez  posted in the Ideas Portal.

I'm wondering if it should be its own Idea, though ... but I don't want to "split the vote" if it interferes with Yone getting his accessibility issue addressed.

Also, one might be tempted to simply kill the ^Ens.Queue global.

Don't.

^Ens.Queue is used for other housekeeping tasks, and while killing it will absolutely remove all messages from visibility in the queue viewer, it won't change the message headers for those items from queued status to something else (like aborted or discarded). And it will very likely break other things that you really don't want to break.

Here's a short method you can place in a utility class that does what you want:

ClassMethod AbortAll() As %Status
{
    Set tSC = $$$OK
    Set tQry = ##class(%SQL.Statement).%New()
    Set tSC = tQry.%PrepareClassQuery("Ens.Queue","Enumerate")
    If $$$ISOK(tSC)
    {
        Set tRS = tQry.%Execute()
        While tRS.%Next()
        {
            Set tQueue = tRS.%Get("Name")
            Write !, "Aborting Queue "_tQueue
            Do ##class(Ens.Queue).AbortQueue(tQueue)
        }
    }
    Return tSC
}

Are the Cerner custom schemas shown in your SearchTable based on InterSystems-supplied schemas? Is it possible that you need to specify "fully qualified" paths to the values you wish to index, for example:

Class XXXX.HL7.RAD.SearchTable Extends EnsLib.HL7.SearchTable
{

XData SearchSpec [ XMLNamespace = "http://www.intersystems.com/EnsSearchTable" ]
{
<Items>
    <Item DocType="InteleRAD_2.5.1:ORU_R01" PropName="AccessionNo" >{PIDgrpgrp(1).ORCgrp(1).OBR:PlacerOrderNumber.EntityIdentifier}</Item>
    <Item DocType="2.5.1:ORU_R01" PropName="AccessionNo" >{PIDgrpgrp(1).ORCgrp(1).OBR:PlacerOrderNumber.EntityIdentifier}</Item>
    <Item DocType="2.5.1:ORM_O01" PropName="AccessionNo" >{PIDgrpgrp(1).ORCgrp(1).OBR:PlacerOrderNumber.EntityIdentifier}</Item>
</Items>
}

In a routing rule, temporary variables must be declared in the rule's general tab:

And in the rule proper, they must be prefixed with an "@" symbol wherever they're referenced:

The foreach as you've designed it will only set the values for tSendAbnormal and tSendNormal based on the contents of the last OBX segment in the message, since it keeps looping until it either hits the last segment or you've triggered a return based on a condition.

What, exactly, are your criteria for sending a message to the "Normal" transformation vs. the "Abnormal?" In a result message, some observations (OBX segments) may have abnormal flags while others won't. Would such a message qualify for both transformations?

An error that would cause a suspended message should appear in the operation's error log. That would also have the session ID and a link to a trace of the message.

You could also query via SQL for a message header that starts with the string "Resent" in the Description field; that's the resent copy of the message but it will include the original message ID following the word "Resent." It will have the same session ID as the source message and both will show up in the trace.

A sample query:

SELECT ID, MessageBodyId, TargetConfigName, TimeCreated, Description
  FROM Ens.MessageHeader
  WHERE
    ID >= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated >='2025-06-25 10:45:00.000' ORDER BY TimeCreated ASC)
    AND 
        ID <= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated <='2025-06-26 00:00:00.000' ORDER BY TimeCreated DESC)
    AND 
        TargetConfigName = 'To_Downstream_System'
    AND 
        Description LIKE 'Resent%'

I'm assuming you mean one target field, since a segment in HL7 starts with a segment identifier like PID or PV1 and contains a string of fields separated by field delimiters (normally the "|" character).

If, for example, you want to copy the  Patient First Name and Last Name separated by a space character into a single field, you could do this:

The underscore character is the concatenation operator in IRIS, so the example is taking:

source.{PIDgrpgrp(1).PIDgrp.PID:PatientName(1).GivenName}, Concatenating it with a space character followed by source.{PIDgrpgrp(1).PIDgrp.PID:PatientName(1).FamilyName}, then storing it in target.{PIDgrpgrp(1).PIDgrp.PID:PatientName(1)}. This effectively replaces the entire field with just the patient's first and last name.

My example uses the HL7 2.5.1 schema; your field paths may be different based on the version of HL7 you're using.

OK, I'm pretty sure I found the problem.

Studio's default compiler flags are "cbk" and VS Code's were set to "cuk." I changed VS Code to match and it appears the issue is resolved.

EDIT: Weirdly, the tooltip text is not updated ...

EDIT 2: If the first line of the comment in the source contains HTML tags, the tooltip reverts to some earlier iteration of the comment (no idea where it's finding that). However, the popup is correct. Removing the tag(s) from the first line causes the tooltip to display the specified comment.

So ... if you want your tooltip to match the first comment line, make sure it has no HTML tags!

In VS Code, if I make a change to a comment in the class, compile, then look at the INT code via View Other, the change is not reflected in the INT code. It doesn't matter whether the text is added to the same comment line or a new line.

Source:

INT:

Interestingly, I can force the comment to update the popup if I remove the property from the class SETTINGS parameter, compile, re-add it, and compile again.

I continue to have issues with this functionality. While I did get my comments to show up as popup help text, I cannot edit them in the source and have those changes reflected in the popups.

I'll mention that I've been using VS Code for the development of this custom operation ...

Digging a bit deeper, I used IRIS Studio to open the class and look at the generated INT code. Interestingly, even though the code was compiled before opening it in Studio, the INT code did not reflect the change to the comment. When I recompiled in IRIS Studio, the INT code's popup text was updated as it should have been.

This appears to be a VS Code issue ... ?