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).

I experienced a similar issue when configuring the MSSQL ODBC driver for IRIS. It appears as though the default odbcgateway.so is 32 bit, and I was able to get it working through the following steps:

  1. Change the working directory to Caché's /<install-dir>/bin
  2. Copy odbcgateway.so to odbcgateway32.so
  3. Copy odbcgatewayur64.so to odbcgateway.so

The NTE segment is commonly used for plain-text "notes" containing descriptive data that doesn't conform to the structured format used for most other data in HL7 messages. It could certainly be used for the storage of base64-encoded binary data, and the likely candidate for that would be the NTE:3 Comment field.

If the base64 content is less than ~3.5MB in size, it can be assigned directly to that field in a DTL or using the SetValueAt() method of the message object (Note: the HL7 specification does not define a maximum length for the Comment field, but there are considerations for IRIS storage that need to be handled appropriately). If larger than 3.5MB, it must be stored using the StoreFieldStreamRaw() method of the EnsLib.HL7.Message object (there is also a StoreFieldStreamBase64() method but it's not applicable if your data is already in base64 format). If you must use the StoreFieldStreamRaw() method, note that it must be the last method called against the NTE segment as it makes the segment immutable.

The recipient of the ORL_O22 message must be informed of this atypical use of the NTE segment so that it can be handled appropriately.

You can use the "*" shorthand for obtaining a count of the number of repeating segments (or fields, or groups) in a when clause. Anything greater than 0 evaluates to "true," so adding a Not() around the expression negates that:

Note: The original reply had Document.DocTypeName rather than Document.Name as the first part of the condition expression. The DocTypeName property refers to the message structure, not the actual message trigger event. That's in the Name property.

You're logging on to the sftp server as user test_user, but attempting to write a file to C:/user/testuser/desktop/orders/. Are you sure that's the correct path for that user? My suspicion is that it's a local permissions issue and not a problem with Caché's sftp support.

I'm not a Solarwinds user/expert; does it have anything useful in its log(s)?