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.

When you say "SMTP Key," are you referring to a User ID and Password? If yes, then create a Credentials entry in the production's namespace via the Management Console's Interoperability | Configure | Credentials menu item and supply the name of the credentials entry as the Credentials property in the User.Mail class.

If there's some other form of authentication required, I'm not sure what to tell you; %Net.SMTP supports only user id/password as far as I know.

The organization doesn't have an Exchange server or GSuite domain? Both can function as SMTP relays, and work with the InterSystems %Net.SMTP class.

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):

Do you actually want the logic to check for the specific fields in the service itself? A Business Process with a rule can do this, and would be a bit more "analyst friendly."

Here's a very bare-bones method to send email from within a custom Business Service:

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" ];

Method Send(pToAddress As %String, pSubject As %String, pBody As %String = "") As %Status
{
    Set tEmail = ##class(%Net.SMTP).%New()
    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)
}

}

You can set the properties in the class to represent default values for your organization. Otherwise, you would call it like so:

	Set tMail=##class(User.Mail).%New()
	Set tMail.MailServer = "smtpserver.mydomain.com"
	Set tMail.FromAddress = "healthshare@mydomain.com"
	Set tMail.EmailCreds = "SMTPServer"
	Set tSC = tMail.Send("user@mydomain.com","This Thing Happened","And Here's what it is")

You will need to obtain access to an SMTP relay host; HealthShare does not supply one. There will also be adjustments required for the class if encryption is required, and if you need to supply credentials for authentication to the SMTP server, you will need to create a Credentials entry in the Management Console and supply its name for the EmailCreds property.

Is there more to this than just disabling the web application? That simply causes the "Open" button in the Business Rules List or Business Process to display an authentication page, which does not allow one to log on. Until the new rules editor is sorted, it would be nice not  to require extra steps each time a rule needs editing.

EDIT: Oops ... disabled the wrong service (/api/interop-editors). Disabling the right service (/ui/interop/rule-editor) does the job.

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