An option that can be performed without Studio, also nice! (You do need VS Code though)

And @Robert.Cemper1003's solution can be performed exclusively via the Management Console, which is also a great alternative.

I'm guessing that the WebSocket Terminal would also provide IRIS command shell access without an ssh session but I haven't played with that yet.

I wrote a quick classmethod in my custom FunctionSet class to test your observation and found that I can use the full mnemonic property path name, for example:

ClassMethod GetControlID(pMsg As EnsLib.HL7.Message) As %String
{
    // Also works with "MSH:10"
    Return pMsg.GetValueAt("MSH:MessageControlID")
}

Example from a rule (I used Document, but HL7 also works):

And the resulting trace from the Visual Trace:

I'm thinking that your inbound messages might not have the DocCategory (ex. "2.3.1") and DocName (ex. "ADT_A01") properties set ... ?

@Enrico.Parisi's observation is the most likely reason for the failure. You can obtain the credentials (assuming you've set them up in Interoperability | Configure | Credentials) with
 

Set tCreds = ##class(Ens.Config.Credentials).%OpenId(..Adapter.Credentials,,.tSC)
Return:$$$ISERR(tSC) tSC

The tCreds.Username and tCreds.Password properties are available on success.

Odd. I just ran your exact query on IRIS for Health 2023.3 and it executed successfully.

The error message suggests that a macro isn't defined, specifically $$$vaDataSegName, which is found in EnsHL7.inc (among others). Since you're working specifically with HL7 messages I suspect that include file is not available to the namespace in which you're running the query.

Looking through the HL7 2.5 OML_O21 structure as supplied by InterSystems, you'll find that there's a nested PIDgrpgrp() under ORCgrp().OBRgrp() that has a subordinate ORCgrp(). It looks like the parse is attempting to match on the required OBR segment in the nested PIDgrpgrp().ORCgrp().

You have a couple of options ... both of which require a custom schema to match your message. The first is to make the OBR segment in the PIDGrpgrp().ORCgrp() optional; the second is to remove the PIDgrpgrp() grouping entirely in the custom schema.

EDIT: The first option doesn't work since the ORC matches on the optional ORC segment in the nested PIDgrpgrp.ORCgrp(), which makes it attempt to match on the required PIDgrpgrp.ORCgrp().OBXgrp().

This is what DTLs are for. The example below shows a scenario using HL7 2.5.1's ORU_R01 message structure, where each OBX segment may be followed by one or more NTE segments. The OBX Set ID, Value Type and Observation Value fields are populated; the first by the value of tObxCounter, the second by the string "TX" and the third by the contents of the Note field. The highlighted area demonstrates the updating of newly added OBX segments with the contents of corresponding NTE segments.

OnGetConnections() should return an array in the first (Output) argument, indexed by the names of the target process(es) and/or operation(s). The second argument is the production item object passed by the invocation of the method from the web ui.

Here's an example that scans the business process settings for any setting that ends with "ConfigName" or "ConfigNames" and sets the pArray argument appropriately:

ClassMethod OnGetConnections(Output pArray As %String, pItem As Ens.Config.Item)
{
    #dim tSetting As Ens.Config.Setting
    Do ##super(.pArray,pItem)
    For l=1:1:pItem.Settings.Count()
    {
        Set tSetting = pItem.Settings.GetAt(l)
        If ($LOCATE(tSetting.Name,"ConfigNames?$") && pItem.GetModifiedSetting(tSetting.Name,.tValue))
        {
            For i=1:1:$L(tValue,",") 
            {
                Set tOne=$ZStrip($P(tValue,",",i),"<>W")
                Continue:""=tOne
                Set pArray(tOne)=""
            }
        }
    }
}

Adjust the match string in the $LOCATE() function if you're using custom setting name(s) for the target(s).