We are looking at building a results feed from a vital signs system, and although it is not built yet, we are thinking that we will not to send every result, mostly because our EMR cannot handle such high volume. The EMR is not built to be a continuous feed display/capture tool. All of the results sent into it are stored in the patients clinical record.
I have not put much thought into it yet but am thinking about building a little piece of code that only passes a subset of readings, perhaps every 5 minutes or more. We need clinical staff buy-in for that methodology, because we don’t know if important outlier data could be discarded if they only presented in-between the interval we use. This could be a show-stopper for the feed.
As far as your original question, I don’t think the issue is Cloverleaf – it is incredibly fast, even if using the Recovery DB. Perhaps with clinical data, you are not allowed to run without the Recovery DB enabled, but you could ask the question. And since the pending messages are on the OB thread, the likelihood is much greater that the issue is the EMR. I assume the OB thread is tcp/ip, that you are using Auto-Reconnect and not using Close After Write?
Maybe you could create another interface pair of threads that fits in-between your translation interface and the connection to the EMR, just for the purpose of having another place where the pending messages would build up. It could be in a different process or even a different site, so that a large volume of messages does not impact performance in other processes or sites.
.
