The field definitions are properties of the *.Record class, so you could perform a property query against %Dictionary.Properties using the *.Record class as the parent.

SELECT Name
FROM %Dictionary.PropertyDefinition
WHERE parent = 'OSUMC.RecordMap.Patient.Record' AND Name >='A' AND Name <= 'z'
ORDER BY SequenceNumber ASC

That would get you the field names in the same order as the data and exclude any percent properties.

Sorry Scott, nothing so straightforward as that 😉

When you create a RecordMap, you usually create up to 3 classes, depending on whether or not you're using a Batch Class.

So you'll have something like:

  • OSUMC.RecordMap.Patient (the "template")
  • OSUMC.RecordMap.Patient.Record (the actual record class)
  • OSUMC.RecordMap.Patient.Batch (if you're using batch class)

If the RecordMap is the source object in your DTL, it should be an instance of OSUMC.RecordMap.Patient.Record and will be the first argument in the method below.

You'll need to create an instance of OSUMC.RecordMap.Patient with %New(), and pass it as the second argument.

Class HICG.Util.RecordMap [ Abstract ]
{
ClassMethod GetRecordAsString(pRec As %Persistent, pTmpl As %RegisteredObject) As %String
{
    Set tStream = ##class(%Stream.TmpCharacter).%New()
    Set tIOStream = ##class(%IO.MetaCharacterStream).%New(tStream)
    Set tSC = pTmpl.PutObject(tIOStream,pRec)
    If $$$ISOK(tSC)
    {
        Do tStream.Rewind()
        Return tStream.Read(tStream.Size)
    }
    // Empty string if PutObject fails *shrug*
    Return ""
}
}

In the DTL:

The value in tRecStr should be the formatted record.

Or you could write a custom Business Process to do it. Here's an example with inadequate error processing (😉) that should give you some ideas:

/// Business Process to Modify the MSH:7 field
Class HICG.Sample.SetMSHDate Extends Ens.BusinessProcess [ ClassType = persistent ]
{
/// Downstream processes or operations to send messages to
Property TargetConfigNames As %String(MAXLEN = 1000);

Parameter SETTINGS = "TargetConfigNames:Basic:selector?multiSelect=1&context={Ens.ContextSearch/ProductionItems?targets=1&productionName=@productionId}";

/// Clone, modify and send the message downstream
Method OnRequest(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status
{
  Set tClone = pRequest.%ConstructClone()
  Set tCurDtTm = ##class(Ens.Rule.FunctionSet).CurrentDateTime("%Y%m%d%H%M%S")
  Do tClone.SetValueAt(tCurDtTm,"MSH:7")
  Do tClone.%Save()
  For i=1:1:$LENGTH(..TargetConfigNames,",") 
  {
    Set tSC = ..SendRequestAsync($PIECE(..TargetConfigNames,",",i),tClone,0)
    Return:$$$ISERR(tSC) tSC
  }
  Return $$$OK
}

/// Return an array of connections for drawing lines on the config diagram
ClassMethod OnGetConnections(Output pArray As %String, pItem As Ens.Config.Item)
{
    Do ##super(.pArray,pItem)
    If pItem.GetModifiedSetting("TargetConfigNames",.tValue) {
        For i=1:1:$LENGTH(tValue,",") { Set tOne=$ZSTRIP($P(tValue,",",i),"<>W")  Continue:""=tOne  Set pArray(tOne)="" }
    }
}
}

The reason you need to clone the inbound message is that Start-of-Session messages are immutable. You must clone them, modify the clone and send it.

The code block action in a DTL is for writing arbitrary ObjectScript, not Javascript. It's commonly used for for data manipulation that can't be satisfied by the methods available in the FunctionSet; for example, extracting and decoding a base64-encoded PDF from an OBX:5.5 field and writing it to a file. It can also be used to interact with globals to maintain state between invocations of the DTL, or perform a database lookup, or even write values to the default device that will display in the Test tool. Very useful for debugging.

I would not recommend using it for operations that could potentially block. There's no built-in mechanism for setting a timeout so use a BPL for those cases.

I came across this article when troubleshooting a connectivity issue with %Net.SSH.Session and needing to use a public/private key pair for authentication. For those that also end up here because they're unable to establish a session with an ssh-rsa key:

The SHA1 signing algorithm has been deprecated for a few years and is now disabled in the latest versions of many Linux flavors. That affects ssh-rsa, as it uses SHA1. You can enable SHA1 via /etc/crypto-policies/config on RHEL 9, but you probably shouldn't.

Fortunately, ed25519 is supported and can be used with %Net.SSH.Session. The default format for both the public and private keys works; no need to create the private key in PEM format (and you likely can't anyway since ssh-keygen ignores the -m directive with ed25519).

$ ssh-keygen -t ed25519

The WRC recommended I try signing the key with ed25519, and that works without having to re-enable SHA1.

$ ssh-keygen -t ed25519

copy the id_ed25519.pub file from the .ssh directory to authorized_keys in the remote host's .ssh directory and make sure the permissions are set to 400 for ~/.ssh and the files within.

So ... after trying a LOT of different options, I finally uncovered the issue. The version of %Net.SSH.Session() in the HealthConnect release I'm working with (2023.1.2) requires ssh-rsa to be enabled on the remote server. And ssh-rsa requires the deprecated SHA1 algorithm which is disabled on RHEL 9.

The workaround is to issue the following command as root:

[root ~]# update-crypto-policies --set DEFAULT:SHA1

I'm hoping there's an update that eliminates the need to do this; the WRC has been notified.

Was there a resolution for this issue? I'm encountering the exact same error on RedHat Linux 9. I've verified that the public and private keys are in the correct formats and that the permissions are properly set for the files and directories. But AuthenticateWithKeyPair() generates the same error.

The same key pair work properly to initiate a ssh/scp/sftp session in the Linux shell. They're in the .ssh directory under the irisusr account, which is the account under which HealthConnect runs, $ZV IRIS for UNIX (Red Hat Enterprise Linux 9 for x86-64) 2023.1.2 (Build 450U) Mon Oct 16 2023 11:29:24 EDT.

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

And @Robert Cemper'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 ... ?