Accessing EnsLib.HL7.Message Header properties within a DTL

Question

Question

Scott Roth · Jan 13

#Business Rules #DTL #HL7 #Ensemble #Health Connect #InterSystems IRIS for Health

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

Discussion (7)3

Log in or sign up to continue

Justin Owens · Jan 13

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 0

Enrico Parisi · Jan 14

OK, I think I understand the question! 😊

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

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

1 0

score 0 · Answer 1 · 2024-01-13T21:25:34-05:00

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

Ens.MessageHeader properties ~~cannot~~ should not be modified.

score 0 · Answer 2 · 2024-01-14T05:43:24-05:00

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

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

score 0 · Answer 3 · 2024-01-14T08:41:09-05:00

Scott Roth · Jan 14

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

0 0

score 0 · Answer 4 · 2024-01-14T10:55:06-05:00

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.

score 0 · Answer 5 · 2024-01-14T10:03:03-05:00

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 :

in the business rule, before the send action, add an assign action to set RuleActionUserData to %PrimaryRequestHeader.SourceConfigName
in the DTL, use aux.RuleActionUserData to access the value (see https://docs.intersystems.com/irisforhealth20233/csp/docbook/DocBook.UI....)