Hi,

Using out-of-the-box classes in the EnsLib.HL7 package, you can either completely ignore responses, either process them synchronously. More complex scenarios involving multiple responses (ack/nack) are supported (see Important HL7 Scenarios | Routing HL7 Version 2 Messages in Productions | InterSystems IRIS for Health 2023.1
), but I think they do not match your supplier requirements.

According to the standard, when sending multiple HL7 v2.x messages over MLLP/TCP, the sender (initiating module) must wait for a response before sending the next message. This is described in  "Health Level Seven Implementation Support Guide", Appendix C, section  C.6.4, item 5. : 

It is assumed that an initiating module may connect and perform more than one message transaction before disconnecting, but it may not have more than one outstanding message waiting for a response.  In other words, the initiating task must wait for the response to a given message before sending another message.

This vendor requirement to receive multiple messages before sending responses is thus non-standard. It would require the sender to keep track of sent messages with a pending response, handle asynchronous replies and retry errored messages.

While this is possible by writing custom adapter/operation extending the out-of-the-box classes in EnsLib.HL7 package, it would add a lot of complexity and has IMHO, little added value compared to the usual synchronous implementation.

For a simple message transformation flow example, I would go for record map :

• you get readymade service (EnsLib.RecordMap.Service.FileService) and operation (EnsLib.RecordMap.Operation.FileOperation) in the library to read and write CSV files and
• a mecanism that generates an appropriate message class based on a declarative definition (see Using the Record Mapper | Developing Productions | InterSystems IRIS Data Platform 2022)

So you can focus on DTL and the whole flow can be done from the administration portal, look ma, no code  ;-)

Hi,

Assuming your question is about HL7 (or EDI) message serialization.

The DTL is meant for parsing and transforming the message into another one.
Serialization occurs when you output the message using the corresponding instance methods.

For an instance of the EnsLib.HL7.Message class, methods that output the message such as OutputToFile() are using instance properties to determine what separators to use : .Separators, .SegmentTerminator.

Also, business operations (extending EnsLib.HL7.Operation.Standard) expose a setting (Separators) that let you configure what separators to use.