Written by

Sr Application Development Analyst at The Ohio State University Wexner Medical Center
Question Scott Roth · Jan 13, 2024

Accessing EnsLib.HL7.Message Header properties within a DTL

Within a DTL is it possible to access and update the Message Header properties of an EnsLib.HL7.Message?

Currently we have multiple EMR Services for each environment sending to 1 Business Process to Normalize the data, then it is sent to another Business Process to route the data. 

Since the SourceConfigName changes with every send to a Business Process, I am looking for a way to maintain the SourceConfigName of the SessionID so I know how to direct the message. Whether I pull the SourceConfigName into a field not being used in the HL7 Message, or I set another Header or Body property to the Original SourceConfigName that I can use in the routing process.

Thanks

Scott

Product version: IRIS 2022.1

Comments

Justin Owens · Jan 13, 2024

I think you should be able to use something like “%PrimaryRequestHeader.SourceConfigName” to access values in the header. I have done it in a rule but haven't tried it in a DTL but I assume it will work the same way.

Update: %PrimaryRequestHeader is defined in Ens.BusinessProcess so I'm not sure you can reference it that way in the DTL.

0
Enrico Parisi · Jan 13, 2024

With "Message Header" you refer to MSH segment or Ens.MessageHeader?

Ens.MessageHeader properties cannot should not be modified.

0
Sean Connelly · Jan 14, 2024

Hi Scott,

Probably best to avoid modifying the Ens.MessageHeader properties, doing so might affect trace logging and potentially lead to unexpected side effects.

Here are a few alternative ideas....

  1. Modify the MSH Segment: In the normalization process, tweak the sender or receiver field in the MSH segment to include a unique identifier that corresponds to the source service name. Then use the MSH to route the message.
     
  2. Use a Utility Method: Develop a utility method within a class that inherits from Ens.Util.FunctionSet. This method would read the source config name from the first message header in the session. You can then use this method in your router logic as it will be automagically included.
     
  3. Separate Normalization Processes: A config only option would be to create a normalization process for each service and then use that process name in the router logic.
0
Scott Roth  Jan 14, 2024 to Sean Connelly

Is there a way to query the original SourceConfig through the process id?

0
Enrico Parisi  Jan 14, 2024 to Sean Connelly
  1. Use a Utility Method: Develop a utility method within a class that inherits from Ens.Util.FunctionSet. This method would read the source config name from the first message header in the session. You can then use this method in your router logic as it will be automagically included.  

Custom utility functions used in DTL and Rules are defined in a class extending/inherits from Ens.Rule.FunctionSet, not Ens.Util.FunctionSet.

As documented here.

0
Robert Barbiaux · Jan 14, 2024

You can pass the value to the DTL using the transformation auxiliary parameter, as described in the documentation : Working with Rules | Developing Business Rules | InterSystems IRIS for Health 2023.3.
To pass the source configuration name : 

0
Enrico Parisi · Jan 14, 2024

OK, I think I understand the question! 😊

Suppose you want to put the "source" HL7 Message SourceConfigName in MSH:Security:

<assign value='##class(Ens.MessageHeader).%OpenId($$$JobCurrentHeaderId).SourceConfigName' property='target.{MSH:Security}' action='set' />

In case you what to get the first message source config name:

<assign value='##class(Ens.MessageHeader).%OpenId($$$JobSessionId).SourceConfigName' property='target.{MSH:Security}' action='set' />

0