If the message doesn't qualify for any of the conditions, it won't be delivered anywhere and will be purged at the end of the retention period you've set for the Ens.Util.Tasks.Purge task. Do you need to delete it immediately?

For starters, I think this:

request.GetValueAt("RGSgrp(1).AIGgrp(context.AIGitr).AIG:3)")'=""

Should actually be this:

request.GetValueAt("RGSgrp(1).AIGgrp("_context.AIGitr_").AIG:3)")'=""

Let's see what happens after you fix that.

With IRIS 2025.1.1 on Windows, I cannot reproduce your issue. Both sets of instructions execute normally. 

VS Code Version: 1.105.1 (user setup)
Commit: 7d842fb85a0275a4a8e4d7e040d2625abbf7f084
Date: 2025-10-14T22:33:36.618Z
Electron: 37.6.0
ElectronBuildId: 12502201
Chromium: 138.0.7204.251
Node.js: 22.19.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.19045

ISC ObjectScript Extension 3.2.1-beta.1

ISC Server Manager 3.10.6-beta.3

ISC Language Server 2.8.0

You are correct in that ReplyCodeAction E* does not evaluate the contents of the ACK message MSA segment; it only looks at the IRIS error code and text.

For your specific example, though, I'm wondering why you're not simply setting a condition to exclude invalid messages in the Routing Rule?

A foreach (possibly multiple foreaches) is what you need. Getting the iterators right is the issue. You're iterating over the AISgrp in the first RGSgrp of the source message and placing them in target RGSGroups with the same iteration count of the source AISgrp. Here's an example based on the 2.3.1:SIU_S12 schema structure that should do what you want, and also handles repetitions of the AIL, AIP and AIG groups:

What account is Caché running under? You'll need to review Windows Services to find the Caché service controller (I don't remember the exact name). It's probably running under the Local System account; you'll need to change it to log on with your own credentials if you want it to use your account's environment.

Instead of ..Contains() as the outer method, use:

..RegexMatch(..ToUpper(source.{PIDgrpgrp(k1).ORCgrp(k2).OBXgrp(2).OBX:ObservationValue()}),"NOT DETECTED|NEGATIVE")

The rule parser/compiler doesn't handle calls to methods/classmethods unless they extend Ens.Rule.FunctionSet, and it doesn't recognize the ##class() keyword. If your class does extend Ens.Rule.FunctionSet, you should be able to use just the Methodname as shown below:

<assign property="PropertyName" value="SomeMethod(args)" />

While @David.M's response will provide a query, it will likely not include the HL7 message-derived values. For example, a search that includes the HL7 field values you've listed will return null for their values when executed via the SQL menu or SQL shell.

That said, I created a tool (originally for use with HL7 Spy to extract HL7 messages from Ensemble/Health Connect) that has some features that may help get you what you want. See this thread for an example of its use.

The Matches() method in the DTL and Routing Rule function list does not use regex syntax; it uses COS "?" pattern matching. The pattern you'd need for your specific example is "1A2N" for 1 alpha character followed by 2 digits.

There's also a ..RegexMatch() method for the DTL and Routing Rule editors in most modern versions of IRIS. That accepts most pcre regex patterns.

It's been my experience that the contents of the ACK message are not evaluated by any of the ReplyCodeActions. If you need to specifically suspend messages that are NAK'ed with this value in MSA:3, you'll need to create a custom operation and associated adapter (likely extending EnsLib.HL7.Operation.TCPOperation and EnsLib.HL7.Adapter.TCPOutboundAdapter respectively) that implements the NAK/Suspend logic.

Include the setting in the SETTINGS string, but prefix it with a dash (-) character:

Parameter SETTINGS = "-Whatever,DSN:Basic:selector?context={Ens.ContextSearch/DSNs},..."

EDIT: Was apparently typing that while you were reading the documentation 😁

And for competeness' sake, the actual documentation:

Adding and Removing Settings