New post
AllAccepted answers
Jeffrey Drumm · Jul 4

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

Jeffrey Drumm · Jun 12

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.

Jeffrey Drumm · May 26

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

Jeffrey Drumm · May 20

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.

Jeffrey Drumm · Mar 12

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

Jeffrey Drumm · Dec 10, 2023

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