experiences implementing Epic interfaces

[Tony Benitz]

We are mulling the idea of going towards using EPIC for our HIS / EMR.

I am looking for experiences implementing the interfaces.

The Dog and Pony that I went to made it seem very easy, but is it really that easy.

We are a 6 hospital facility currently running two HIS / EMR with outreach and lab equiptment and billing and …. the whole meal deal, did I mention that we use a 3rd party EMPI for all of this as well.

So we have a complex environment and now we want to see would it might be like to add a new HIS / EMR.

Anybody out there have any experiences that they want to share?

Topic

[Jim Kosloskey]

Tony,

I have no experience with EPIC – but I have plenty of experience with a lot of vendors – the one thing I always say trust but verify.

Querying on Clovertech is a good first step but I would also make up a list of very pointed questions; insist the vendor provide you with a good technical resource; ask the questions and consider any obfuscation as an undesirable answer.

Jim Kosloskey

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

[Bob Richardson]

Greetings,

We have 9 hospitals and about 23 clinics and a few medical centers and have been rolling out Epic for the last two plus years.  One BIG factor that you need to worry about: VOLUME!!!  With Epic every time someone clicks, drags and drops, navigates to another dialog you get an HL7 message.  Our volume tripled !! for ADTs of all sorts.  Also: there are batch dumps of 10s of thousands of messages at about midnight to the engine.  Every thread turns red for a few minutes for sure.  So you might want to consider beefing up the platform that Cloverleaf needs to run on:  we have IBM P630s with 4 CPUs – so far we have only spiked a couple of times beyond the 80% CPU usage (that midnight crunch).  And (!) there is only one inbound for ALL ADTs, orders (except for Radiology) which means that you don’t want all of your translate work done in the one inbound process.  Epic interfaces do not shutdown cleanly:  you may get into cycling wars until the FIN-WAITs clear.  All Epic outbounds are server to Cloverleaf; all Epic inbounds from Cloverleaf are client.  And Epic has multiple environments on ONE server:  you need to worry about who is sending what to both your production and test engines.  We were forced to configure on Test at least multiple outbounds to each envirionment; and set on TEST only all Epic inbounds to Cloverleaf as multi-connect (we are running CIS5.3 Rev3).  Then we crafted TCL procedures to set an unused MSH-14 field based on who connected (interpret the IP or domain) in the “cli” file for each multi-connect to know where to route the inbound to the outbound.  For example, TEST or Development or Production to the matching outbound recipients.

Epic will introduce new challenges and headaches for Cloverleaf!!!

Good luck, good hunting!!

[John Mercogliano]

We are in the middle of a 5 year conversion to Epic.  The users love it but with any conversion there are going to be nightmares.  Epic has had to make a number of programming changes to accomidate our workflows and some they have even incorporated into there general release.  But the good thing is they were able to work with use and accomidate our requirements.  We have 6 hospitals and numerous Medical group practices and use a seperate EMPI application.  We use HBOC for our registeration and did not use epics registration package. That that has added a number of headaches that both our cloverleaf team and epic had to program around.  From the interface side, I did not find it any more difficult interfacing with Epic and then any other system but because of epics scope we did have to comeup with unique ways to handle message routing.  I will concur with them not coming down cleanly.  Our epic team has been working with Epic directly to get better monitoring in place so they now when there is a problem.  

Good luck.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Robert Milfajt]

At Northwestern, we have had Epic interfaces since the mid 90’s.  They are among our most reliable interfaces.  Epic is on AIX, but was migrated from Compaq Unix about 5 years ago.  Cloverleaf is on AIX and the interfaces have run on several versions including and up to 3.8.1P.

The interfaces stay connected, they come up and go down as commanded, data is not lost and they are among the fastest of our interfaces to catch up after upgrades or other outages.

Epic interface support is outstanding and again I have no complaints.

My experience spans two organizations, Northwestern Memorial Hospital, where Epic was first implemented, and the Northwestern Medical Faculty Foundation, where the system is currently implemented.

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Dennis Pfeifer]

I’ve worked with EPIC for over 7 years now, and have found them to very competent and always willing to try and help find a solution. My experience is that they have been solution focused, and NOT territorial, such that things ‘must’ be done in Cloverleaf, or that they ‘must’ be done in EPIC. They are agreeable to coming up with solutions that work best.  Our general preference has been to do what we can in Cloverleaf, and that which we can’t is done in EPIC .. i.e. generally state or historical dependencies are handled in EPIC.. e.g. if the current insurance is X, don’t replace with Y .. this can’t be easily done in CL, so it’s done in EPIC .. (I prefer not to create databases in CL .. )

and .. yes they do produce lots of messages on their ADT interfaces.

I refer to EPIC as the BMW of information systems .. they are very good in quality, but generally, very expensive… so .. you get what you pay for ..

.. if you can only afford a Chevy .. you’re not purchasing a BMW.

Dennis

[Highland Dave]

I noticed that the last post was several years ago, does anyone have any recent updates to share?   Epic appears to be very busy with Hospital imstallations.  We are starting our own two-three project.  

The data volume, especially the post on what occurs at midnight concerns me.

There is current development on Adt to TeckSys (SMS?) and DFT back.  TeckSys needs to develop the interface, but against GE Centricity and will be FRL and FTP.  But, we need to possibly adjust some field length values related to Epic so we do not have to create a conversion in a year from  now.  People are questioning what the medical record number (or Epic number) should be, possibly should change from being a length of 8 or 10.  Along with with Hospital Account Number being greater than 10.   The Epic Charge Inbound Tech reference or Adt Outbound Tech reference does not indicate the HL7 field length for PID-3 or PID-18, just that PID-3 has a location of EPT 2060, 2061.

[Lawrence Williams]

We are going live with Epic on December 1st for a few of our clinics and the end of January for one of our hospitals.  Then we have a 3 year roll out for the rest of our facilities (which include 5 hospitals and several clinics).  We currently have a best-of-breed approach for most of our departmental systems that will be mostly replaced by Epic.  

So far it has gone about as good as it could have been expected to go, there are hiccups and there will be more, but I come from a Cerner world in my previous job and I like what I see thus far when comparing Cerner to Epic.   I would agree with Dennis Pfeifer above, Epic is solution focused and is willing to let us handle as much as we want to on Cloverleaf or help us with profile variables and such in Epic if necessary….

Feel free to PM or email me if you’d like for any other insights…. I am also the Data Courier Admin for our site, so I have some knowledge outside the HL7 realm as well for Epic…

[Vince Angulo]

Dave,

We’ve been on Epic for Enterprise Practice Management for just over 10 years, using their MPI, registration, scheduling, reporting and profee billing modules.  We expect to implement hospital ADT and billing sometime in the near couple of years.

I’ve been doing interfaces for 15 years and Epic is the best vendor I’ve worked with.  You can always get an EDI team lead on the phone in a matter of minutes, and to a person, they’re exceptionally knowlegable.

Yes, lots of trigger points in the application, so there are a lot of messages.  Some are configurable by your EDI lead, and we have had some custom flags in some txns that we can kill off using a pre-xlate UPoC.  But it’s still a lot.  I don’t recall a special problem with End Of Day (midnight) jobs, but those are dependent on the workflows for your enterprise, so milage may vary.

I can’t address the use of FTP or batch interfaces — for data exchange like that we use the Chronicles Batch Scheduler or extract from the Clarity reporting database, and the applications team manages those with the Epic Tech Support folks with very little help from our interface team.

Field length values really don’t apply — Epic uses InterSys Cache on the back end, so any string less than 256 is okay without special handling needed for the HL7 interfaces.  

The apps team should be able to set up virtually any # of  identifiers, each with unique edit mask in Epic that can accomodate most any length and formatting your stake holders can think of.  You’ll just need to make sure the outbound HL7 Cloverleaf variant won’t truncate the long ones — I think MRN and Account #’s are 20 out of the box with Cloverleaf, which hasn’t been a problem for us.

Hope this helps.

[Author]

Replies