The ISCAgent is available through the online distribution link at the WRC site, in the "InterSystems Components" category. The oldest version available is 2018.1, but it may work for you.

I'd suggest using some other directory than /tmp as the root of the source path. And I would also recommend installing it as root rather than a user with some elevated privileges. You'll be specifying the account under which it will actually run later, during the install.

Add a code rule at the end of the DTL that contains:

 Write "<pre>"_target.RawContent_"</pre><hr>"

Run the DTL Test and the raw message output will show above the HTML-formatted message.

Disable the rule when you're satisfied with what you're getting.

The NTE segment is commonly used for plain-text "notes" containing descriptive data that doesn't conform to the structured format used for most other data in HL7 messages. It could certainly be used for the storage of base64-encoded binary data, and the likely candidate for that would be the NTE:3 Comment field.

If the base64 content is less than ~3.5MB in size, it can be assigned directly to that field in a DTL or using the SetValueAt() method of the message object (Note: the HL7 specification does not define a maximum length for the Comment field, but there are considerations for IRIS storage that need to be handled appropriately). If larger than 3.5MB, it must be stored using the StoreFieldStreamRaw() method of the EnsLib.HL7.Message object (there is also a StoreFieldStreamBase64() method but it's not applicable if your data is already in base64 format). If you must use the StoreFieldStreamRaw() method, note that it must be the last method called against the NTE segment as it makes the segment immutable.

The recipient of the ORL_O22 message must be informed of this atypical use of the NTE segment so that it can be handled appropriately.

You can use the "*" shorthand for obtaining a count of the number of repeating segments (or fields, or groups) in a when clause. Anything greater than 0 evaluates to "true," so adding a Not() around the expression negates that:

Note: The original reply had Document.DocTypeName rather than Document.Name as the first part of the condition expression. The DocTypeName property refers to the message structure, not the actual message trigger event. That's in the Name property.

If the server you're connecting to is reasonably up-to-date on security patches, it's very likely that you will be unable to connect from Caché 2016.1 unless you can get the administrator of that system to enable some older (and less secure) cypher suites.

If the content of the field that contains the base64-encoded PDF is greater than the maximum string size in IRIS, it will be stored as a stream.

I've written a custom function that will extract the full content of a message containing such a value; it was originally created to support fetching large HL7 messages in HL7 Spy. You can download it here: http://www.hl7spy.com/downloads/HICG_HL7.xml. I've been asked to add it to the OEX repository, but I just haven't gotten around to that yet ...

I'm not sure how the SQL Editor in the management console will handle a query that uses that function, though. It will likely cause some interesting behavior 😉

The specific SQL function in that class is HICG.GetBigMsg(<messagebodyid>).

I"m assuming you're talking about HL7 here ...

InterSystems does a bit of magic in the background to display the Message Body fields in the message viewer, and it's not immediately available to you. However, I've written a custom SQL function that fetches the field at the supplied path (you'll need supply the path as its defined by the Schema/DocType of the message).

Example:

SELECT TOP 100 head.ID As ID,
        {fn RIGHT(%EXTERNAL(head.TimeCreated),999 )} As TimeCreated,
        head.SessionId As Session,
        head.Status As Status,
        head.SourceConfigName As Source,
        head.TargetConfigName As Target,
        HICG.GetMsg(head.MessageBodyId,'MSH:9') As MessageType
    FROM
        %IGNOREINDEX Ens.MessageHeader.SessionId Ens.MessageHeader head
    WHERE
        head.SessionId = head.%ID
        AND head.MessageBodyClassname = 'EnsLib.HL7.Message'
        AND head.SourceConfigName = 'SourceBusinessHostName'
    ORDER BY
        head.ID Desc

You can download the class here: http://www.hl7spy.com/downloads/HICG_HL7.xml

I don't know of any other attributes, and increasing logging may turn up something but hasn't proved useful in my experience.

If your servers are reporting occasional disconnect errors, that's not necessarily a network issue, or even something to worry about. The mirror members may report disconnections due to things like snapshots/backups where one or more hosts are momentarily suspended by the hypervisor in a virtualized environment, or updates to the OS that might stop/start services as part of the update process. It's important to remember, though, that the arbiter is designed to operate optimally in a low-latency, same network, same data center scenario. If your mirrored hosts are spread across a WAN, you're asking for errors.

You can explicitly exclude '%' schemas with the pattern "\%*" in the Exclude list:

As part of the encryption negotiation process, there's an exchange of supported cypher suites between the client and server. If there's no match, no connection can be established. No need to force a specific cypher site; all available should be presented by the client during connection negotiation.

If upgrading to a current version of HealthShare/Health Connect is not an option, you could script the transfers outside of the production (batch/powershell/Python/Perl script running under Windows' Scheduler or called from ObjectScript in a Scheduled Task via $ZF(-100) ) and then use a File service/operation to pick them up for processing or drop them off for delivery.

I had previously posted a comment with a solution here, but received a request to turn it into a question/article. You can find it at this link.

I've worked with a number of integration solutions over the last few decades and not a single one of them would work with this vendor's perverse interpretation of HL7 communications out-of-the-box.

Health Connect / HealthShare can accommodate pretty much anything if you're willing to dip your toes into ObjectScript and write custom services and operations. But the OOB classes won't handle the vendor's requirements without subclassing/extending.

Acknowledgements

There are certainly variances in the types of acknowledgements received and even cases where acknowledgements are received out-of-band (Sunrise Clinical Manager, I'm looking at you). I've even seen implementations where multiple HL7 messages are sent, streamed in a batch, with envelope characters wrapped around the whole batch rather than the individual messages. In that case no ACK was expected. I wrote a custom service to handle that one.

Fundamentally, Health Connect is a request/response messaging system and violating that design presents some interesting challenges. Receiving the ACKs back asynchronously over the same connection is theoretically possible, but I wouldn't encourage the vendor to work that way ... every single future customer will be problematic for them.

Message Control IDs

I've never seen an engine that increments the message control ID automatically, although it's something that can be coded/customized in multiple solutions. The message control ID is defined by the sending application, not the middleware; setting the MSH:10 in the engine is usually an extraordinary measure.

HL7.org defines it as such:

This field contains a number or other identifier that uniquely identifies the message.

If the same message was re-sent with a different MSH:10 value, it would not be uniquely identified. In my opinion, at least.

Depends on your platform (although that may have changed since the last time I configured an LDAP setup).

With Caché/IRIS running on *nix variants, the only option is STARTTLS, which is encrypted but uses the "standard" port 389. With Windows, I believe "LDAP over SSL" (aka LDAPS) is also an option, on port 686 by default.

Both will require that whatever certificate is served is valid for the load balancer. This is usually accomplished via a certificate Subject Alternative Name value.

Not with this code, no. I interpreted your original request literally, assuming that you wanted to send the email directly from within a custom service.

If you wish to have an Email operation in the production that handles the delivery of messages from routing rules, that's a bit more work to create, but in the end more versatile and easier to support.

If you don't care about having an operation, you could create a class that extends Ens.Rule.FunctionSet that wraps the original class in such a  way that you can send email from a rule:
 

Class User.Util.FunctionSet Extends Ens.Rule.FunctionSet
{
ClassMethod SendEmail(pToAddr As %String, pSubject As %String, pMessageBody As %String) As %Status
{
	Set tMail=##class(User.Mail).%New()
	Set tSC = tMail.Send(pToAddr, pSubject, pMessageBody)
}
}

You could then call it from a rule (the assign simply lets you call it and optionally do something with the returned status):

The RecordMap services have options for handling errors:

I'm not sure whether they do actual datatype validation on fields in the RecordMap (wouldn't make much sense to let you specify datatypes without supporting validation though).

But if your extra field didn't trigger some sort of warning or error in the Event Log 🤷‍♂️

@Eduard Lebedyuk is correct (yeah, he's always correct 😁), you can't use a variable for the target in a business rule.

You can do this in a custom BP (COS or Python) or a BPL-based BP, though. The BPL <call> action specifically supports a context variable as a destination:

The variable would be assigned the name of the BH to send to prior to invoking the call.

It's not clear from your post whether you're using any of the healthcare-related variants of the InterSystems suite.

If you're using HealthShare, Health Connect or IRIS for Health, support is included for receiving HL7 messages and storing them via multiple mechanisms. TCP/IP MLLP, HTTP, and file based services are all supported natively.

When configuring a Business Service to receive HL7 messages via TCP/IP MLLP, you would select the EnsLib.HL7.Service.TCPService class and configure the Message Schema Category to "2.5" or "2.5.1" depending on your specific HL7 version. You would also need to configure the port on which to receive the messages, the target Business Process or Operation to act on them, and possibly a few other settings.

Messages received through that service will then be inserted into the Interoperability message store, regardless of HL7 message type; message headers are created to provide tracking/status information and the messages are databased.

If your need is to index and retrieve those messages based on content (patient name, account number, gender, etc), there are additional steps to fetch the specific data elements needed from the messages themselves and populate associated fields in a database structure that addresses those needs. That's something you would need to design; you would populate it using interoperability production components tailored to your filtering requirements and database design.

Can you try the code I posted above, substituting appropriate paths/filenames in the calls to the LinkToFile() methods? Any file will do for the in stream, as long as file/directory permissions permit. This at least would tell us whether the issue is with the key file or the JWT you're attempting to encrypt.

I've tried this on I4H 2023.1 and Health Connect 2021.1.2 and the RSASHASign() method has not failed to generate a signature unless the key was passphrase-protected or not readable (due to file ownership/permissions) by the process opening it.