Infusion Pump Integration

I have not done this but I would think you might need to consider turning SMAT off.

I would consider placing this integration in its own site so that it has its own Recovery DB. And this is all I would consider putting in that site unless monitoring and analysis shows more load could be handled.

I would find out the estimated peak arrival rate (I would suspect could be high) and construct a test using fileset protocol so I could simulate the peak arrival rate as closely as possible. During the testing I would have as much monitoring turned on as I could to evaluate the throughput.

Given an appropriate architecture and sized platform, I don’t see why this could not be handled by Cloverleaf.

Just some of my thoughts. As I said I have not done this…

We are, Alaris, and we do not use Cloverleaf.  In fact Epic recommends that these be point to point interfaces.

We have all our devices going to a middleware product and then through the engine before Epic. At Jim stated, it should be isolated in its own site, and be careful about the SMATs.

For our setup, Epic actually wanted us to go through the engine before Bridges (Epic). I am curious as to why they recommended differently.

We have infusion pumps up and running in production and going through Cloverleaf.  We do not use SMAT (for anything) so that wasn’t an issue.  From what I understood, Epic did not think that the ACK could be passed back and forth between the two systems (Hospira) and that nobody else with the Cloverleaf engine was able to make it work.  They strongly recommended that it not go through the engine.  We assured them that we could route the acknowledgements between the systems and did in fact make it work.

Volume wise – we send out about 1000 orders, receive about the same amount of verifications, and process about 100,000 documentation messages per day.  We do have these connections on their own site and so far really haven’t had any problems related to the engine.

We use AIX for our engine.

No, we only route between the Hospira server (which is a local server behind our firewall) and Epic.

We have connected multiple Capsule Tech Datacaptors with Epic for several hospitals.

We use a seperate site for it without SMAT.

Largest configuration is one hospital with more than 200 Datacaptors sending data every 2-3 seconds in HL7 ORU messages. And that results in 10-15 million messages a day. Cloverleaf has no problem with it.

we decided not to use SMAT first of all for the disk space, 10-15 million messages a day uses quite some space.

And the hospital also stated that they don’t need those messages in SMAT archives in Cloverleaf anyway.

We’ve never used SMAT since using cloverleaf starting with I think version 3.8 (before me starting).  We do write out any incoming messages to a raw file and cycle/archive that file around midnight each night.  Those files can then be used to run reports, resend, etc.

I agree with the commentary on not using SMAT due to disk space, but for another reasons as well.  For those device interfaces we have between various middleware vendors, iSirona, GE, iBus and Philips, we do not keep SMAT files for those for two reasons.  The obvious disk space issues, but the other reason is that most device data is only good in the moment and Epic keeps logs (which we keep for only 1 day).  If something failed from last week, chances are there are more recent results from yesterday or today which are more relevant.  However, if you have the disk space and are willing to use it, I see no reason why it’s a bad idea to store it.

Keith, I’m heading down the same path with Infusion pumps, and I’m interested to know how it worked out for you. Most of my device interfaces were very easy from cloverleaf prospective. I don’t use SMATs for devices in PRD environment mainly because messages expire in seconds or minutes,  but for test sites I do and I only keep them for a day.