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.

You'll need to generate your own XML schema by importing either an xsd or wsdl. Once you've done that, you'll be able to use the schema in your DTL by selecting the Source or Target class as EnsLib.EDI.XML.Document, with the Document Type set to the name of your imported XML.

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

I'm pretty sure it's because a message header isn't created for an ACK, since (in most cases) it's not sent anywhere. They're tracked in Ens_Util.IOLogObj, and cleaned up from there if selected in the Message Purge task.