Infusion Pump Integration

[Keith McLeod]

Has any one done infusion pump integration with EPIC?  I am hearing recommendations not to go through Cloverleaf and would like to understand why or why not.  Anyone?

Topic

[Jim Kosloskey]

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…

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Robert Milfajt]

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

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Gordon Koch]

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.

[Keith McLeod]

How many pumps and what kind of message volume is occurring whether on cloverleaf or not?

[Paul Bishop]

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.

Paul Bishop
Carle Foundation Hospital
Urbana, IL

[Keith McLeod]

As a follow on question, do you send any of these messages to any other destination systems? Beside EPIC? Vigilanz?

[Paul Bishop]

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

Paul Bishop
Carle Foundation Hospital
Urbana, IL

[Marc Pleijers]

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.

Marc Pleijers
Senior Integration Consultant
Enovation BV
The Netherlands

[Keith McLeod]

Is the discussion surrounding SMAT on account of the use of disk space?

[Marc Pleijers]

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.

Marc Pleijers
Senior Integration Consultant
Enovation BV
The Netherlands

[Paul Bishop]

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.

Paul Bishop
Carle Foundation Hospital
Urbana, IL

[Robert Milfajt]

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.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Faisal Khan]

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.

[Author]

Replies