Are you attempting to do this in a routing rule foreach or a DTL?

You're much better off working with a Business Process/BPL for this sort of thing. You would:

  • Create a context variable for the FT1 segment counter (ex. FT1counter)
  • use that as the key in a Foreach action, with request.{FT1()} as the property.
  • In the loop:
    • Add a Transform action to use a DTL to map the required PID/PV1/etc. fields to the record map, specifying the current FT1 segment values using source.{FT1(context.FT1counter):Fieldname} to select the current segment's fields.
    • Add a Call action for invoking the operation in the same loop, and you're done.
  • Save, add it to your production, and point the service at it.

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.

There have been updates to openssh within the last few years that retired older, less secure cypher suites. It's possible that 2017.2 may be old enough to be incompatible with newer versions of the ssh (which sftp relies upon) libraries.

Check with the vendor/customer at the other end of the connection to see if they've made recent changes to their version of ssh.

export flags the variable to be available in child processes, but only affects the current account in an interactive shell.

jeff@ourawai03:~/tmp$ a="hey"
jeff@ourawai03:~/tmp$ echo $a
hey
jeff@ourawai03:~/tmp$ bash
jeff@ourawai03:~/tmp$ echo $a

jeff@ourawai03:~/tmp$ exit
exit
jeff@ourawai03:~/tmp$ export a="hey"
jeff@ourawai03:~/tmp$ bash
jeff@ourawai03:~/tmp$ echo $a
hey

As others have mentioned, Size can be something of a "squishy" terrm depending on a variety of factors.

There's no single property that will work for all message classes; you do need to know the class and make sure it has a "Size" (or in the case of  EnsLib.HL7.Message) "FullSize" property. And you can certainly add it as a search criteria in the Message Viewer:

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.

As I mentioned in my original post, my code was very bare-bones. While it supports authentication, it does not have any encryption features enabled.

You may also need to enable TLS/SSL and possibly STARTTLS in %Net.SMTP. It's also likely that you'll have to specify an alternate port; the default is 25.

Updated to support TLS/STARTTLS and alternate port:

Class User.Mail Extends %RegisteredObject
{

Property MailServer As %String [ InitialExpression = "hostname.domainname" ];
Property FromAddress As %String [ InitialExpression = "fromaddress@domainname" ];
Property EmailCreds As %String [ InitialExpression = "SMTPServer" ];
// May have to change value to 587 or 465 if STARTTLS required
Property SMTPPort As %Integer [ InitialExpression = 25 ];
// The TLS/SSL client configuration will need to be added in
// Management Console: System Administration | Security
Property SSLConfig As %String [ InitialExpression = "TLSClient"];
// Set to 0 if STARTTLS is not necessary
Property UseSTARTTLS As %Boolean [ IniitalExpression = 1 ];
Method Send(pToAddress As %String, pSubject As %String, pBody As %String = "") As %Status
{
    Set tEmail = ##class(%Net.SMTP).%New()
    Set tEmail.port = ..SMTPPort
    Set tEmail.SSLConfiguration = ..SSLConfig
    // STARTTLS: 1 for yes, 0 or omit the following line for no
    Set tEmail.UseSTARTTLS = ..UseSTARTTLS
    If pEmailCreds '= ""
    {
        #dim tCred As Ens.Config.Credentials
        Set tSC = ##class(Ens.Config.Credentials).GetCredentialsObj(.tCred,$CLASSNAME(),"Ens.Config.Credentials",..EmailCreds)
        Return:$$$ISERR(tSC) tSC
        Set tAuth = ##class(%Net.Authenticator).%New()
        Set tAuth.UserName = tCred.Username
        Set tAuth.Password = tCred.PasswordGet()
        Set tEmail.authenticator = tAuth
    }
    Set tEmail.smtpserver = ..MailServer
    Set tEmail.timezone="LOCAL"
    Set tMsg = ##class(%Net.MailMessage).%New()
    Set tMsg.From = ..FromAddress
    Do tMsg.To.Insert(pToAddress)
    Set tMsg.Subject = pSubject
    Set tMsg.Charset = "utf-8"
    Do tMsg.TextData.Write(pBody)
    Return tEmail.Send(tMsg)
}

}

Link to the %Net.SMTP documentation

If you're still having issues authenticating, you will need to reach out to your SMTP provider.