Here is the link to documentation https://irisdocs.intersystems.com/healthconnect20191/csp/docbook/DocBook...

Your BPL would look similar to this:

If you're going to write a BPL, a better solution would be to make those sends (<call> elements) synchronous. This way you don't have to guess how long to delay for. Checking Force Sync Send for regular HL7 processes does exactly that.

To clarify, you have one inbound message from a service going to one process/routing rule with two sends in it. You've noticed that sometimes messages get sent not in the same order as they appear in the routing rule. 

If above is correct, try checking Force Sync Send in the process settings.

Generally, you'll likely have to write a BPL and use the delay action if you want to sleep/halt between sends. 

Jeffrey,

That's exactly what we did to offload message archiving to our DR server.

We created another namespace (R/W, non-mirrored) and mapped the following globals from the original namespace with the mirrored R/O database: 
EnsLib.*, EnsLib, EnsHL7.Segment, EnsHL7.Schema, EnsHL7.Description, EnsEDI.*, EnsEDI.X12.Schema, EnsEDI.X12.Description, EnsEDI.Schema, EnsEDI.Description, EnsEDI.ASTM.Schema, EnsEDI.ASTM.Description, Ens.MessageHeaderI, Ens.MessageHeaderD, Ens.MessageBodyI, Ens.MessageBodyD, CacheMsgNames, CacheMsg.

Then, we run the message archiving task in the other namespace without issues.

If you are planning to implement an interface with Kafka, I suggest reading the following:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...
https://community.intersystems.com/post/ensemble-rabbitmq-java-client-qu...

When it comes to specific pain, there are just a lot of pieces to maintain compared to common interfaces, such as HL7, etc.
Also, if you plan to send a large volume of messages, you'll have to do that asynchronously. The problem with that is you may send 100 or even 1000 messages before you realize there is a connection or other problem. You'll have to think of a way to keep track of what messages have been sent successfully and which didn't, and requeue messages that have failed. Of course, if you are not worried about "losing" messages, that's not an issue.

Yes, it's possible to add the send where you want it.

You'll need to change your rule to look similar to this:

The problem with having two or more when blocks back-to-back is that they are bit misleading.   
You may assume that

when "condition 1"
    send
  when "condition 2"
    send

is the same as following pseudo code

if ("condition 1")
    send
  if ("condition 2")
    send 

when, in fact, it works at the following pseudo code

if ("condition 1")
    send
  else if ("condition 2")
    send

This means that when you have consecutive when blocks, one and only one when will be executed.
A workaround is to put each when block into its own rule.

P.S. I would split this routing rule in two separate routers and routing rules: one that sends messages only to EDM and one only to RIS. When you have a large environment, makes maintenance and a whole lot of other things easier in the future.

Thank you for the online course! Very much needed.

The course videos below are not available. Getting an error "No playable video sources found":

WHAT IS FHIR?
FHIR VS. HL7V2, HL7V3, AND CDA
FHIR ARCHITECTURE

Also, it would be nice to get access to the custom code show in "FHIR IN HEALTHSHARE DEMONSTRATION", specifically, "Summit.BPL.V2ToFHIR." I'm sure many developers would like to know how to convert good old HL7v2 messages to FHIR resources using HealthConnect.