Cloverleaf site design for Epic

[Gina Borden]

Just wondering if anyone would care to share how you have your Cloverleaf sites defined for Epic interfaces.

The current design we have for Cloverleaf from our EMR has:

ADT site – which routes out all ADT

Orders site – which routes out all Orders

Results sites – which routes out all Outbound results, and a separate process for Inbound Results

Epic is a lot more complex it appears, we’re currently looking at 85 plus ports to/from Epic itself.

Just trying to land on a good design in Cloverleaf.

Thanks in advance!

• This topic was modified 3 weeks, 3 days ago by Gina Borden.

Topic

[Grace Huynh]

We are a fairly large organization with 3 hospitals + hundreds of clinics.  Our sites are organized by Epic functions:

asap
beacon
beaker
charges
cardiology
diet
endo
him
lab
materials
miscellaneous
miscellaneous adt (peers who don’t fall into the other categories but receive ADT only)
pharm
radiology
stork

We also have grand parent sites that feed parent sites that then feed down to the sites listed above if they need ADT.

Hope that helps!

Grace Huynh
gnguyen1@uw.edu
UW Medicine, Seattle, WA

[Gina Borden]

Thank you!

[Paul Bishop]

Hi Gina,

We have a similar setup to Grace.  We have eight hospitals and multiple clinics.

We have three ADT interfaces out of Epic.
– One is strictly for clinical use so doesn’t have the hospital admissions, transfers, and discharges – just the registration and patient level updates.  The messages come in on one site and then route to 4 other sites to downstream systems.
– The second one has everything the clinical one has, plus all the hospital admissions, transfer and discharges.  The messages come in on one site and then are routed to three “hub” sites, which then distribute the messages out over 13 other sites.  We did it this way because Epic LOVES its ADT messages – about an average of 310K a day.
– The third one is a scaled down version of the second ADT interface by using different profile variables to eliminate some of the messages

For Cupid interfaces (Cardiology) we have the Orders/Results out of Epic come into one site and then Orders are routed to a Cupid orders site and results are routed to a Cupid results site and from there are routed to the downstream systems.  Incoming results to Epic are in the same initial site.

For Radiant interfaces (Radiology), it is similar to Cupid: Orders/Results out of Epic into one site and then split into separate Radiant orders and Radiant results to then be routed to downstream systems.  Incoming results to Epic are in the same initial site.

Lab orders (we are currently NOT on Beaker) come in on one site and most are routed within that site.  The exception is the lab orders which are routed to a site that strictly handles both orders to the lab system and results from the lab system.  A lot of the smaller Epic interfaces are connected in this same site (Optime, Diet orders, Education orders, Provider updates, Supplies, etc).  We really need to split this up more because that site currently has 30+ processes.  We are also in the starting stages of switching to Beaker (2-year plan) so this will be changing for us.

Outgoing Cadence messages (SIU) are sent into one site and then routed into six other sites which then route to downstream systems.  Incoming appointments are also sent from this site.

Device interfaces (four of them) into Epic are split between four different sites because of the sheer volume of messages.  We also configured Epic to NOT send acknowledgements for these interfaces.

For the bigger downstream systems that have multiple interfaces, we created separate sites and routed the messages to the appropriate interface.  This was mainly done to make it easier for maintenance on those systems and for when those systems have downtimes.

You probably already know this, but build an HL7 variant specifically for each Epic interface and store them in a master site.  An order/result message out of Epic for Cupid can be defined vastly different from one for Radiant.  This also allows you to create the custom Z-segments as you need for each interface.

We currently run on a AIX Power-10 server.

Hope this helps.  If you want to talk in more detail, let me know and we can connect.

• This reply was modified 3 weeks, 3 days ago by Paul Bishop.

Paul Bishop
Carle Foundation Hospital
Urbana, IL

[Gina Borden]

Thank you so much!  This is great information!

[Vince Angulo]

Gina,

We have a similar site configuration to yours; the only difference is that the analyst that does web service connections uses a separate site for those processes.

We’re a medium-sized pediatric integrated delivery system with 1 acute care hospital, 2 ASCs, 3 urgent care and 6 diagnostic centers, and 20 gen peds physician practices.

We have connections for 65 end-to-end interfaces, using about 100 of our unlimited thread license. Six total sites and their general contents:

• Hospital ADT, BAR, and DFT
• Physician Office Reg/SIU
• Orders (Nursing orders to bolt-on downstreams – audiology, nutrition, EEG, and the like.)
• Results (Reference labs, general transcription, PHR eLR)
• Ancillary clinicals (Mainly Pharmacy, Rad-PACS-Transcription, Blood Bank)
• Web Services (Continuity of care)
• Master (Reusable tps and xltp scripts)

We try to be conscious of Infor best practices for things like # of threads per site…so, that drives our set up.

Current staff is 2 -1/2 FTEs for interfaces.

I’ll be following this topic with interest as we are transitioning from Epic Physician Practice Reg/Cerner EMR to an “All Epic”, “Epic First” vision. Dropping Hospital ADT and billing in favor of Epic HAR as well as adopting any Epic integrated solution that can replace our bolt-on solutions.

We are also simultaneously changing from locally hosted Cloverleaf on AIX Power 10 to Cloverleaf “SaaS in the cloud”.

We kick off this spring with a projected Epic ‘big bang’ go-live in Fall 2027. For this project, we will be increasing to 3 FTEs + 2 temp consultants. The temp consultants will support existing interfaces, with the original 3 focusing on building new interfaces to meet the project vision.  When we’re fully on Epic the temps will be let go.

[Jason Russell]

We are a rural hospital system with 4 hospitals, hundreds of clinics, etc. We have a prefix on our sites to determine if they’re ‘development’, ‘test’, or ‘production’. Beyond that standard shorthand with a number (if the sites need to be split later):

apps1 (ungrouped apps) , cardio1, coding1, CSN1 – CSN is ADT, some have evolved into other functionalitly. 1 has additional HAR/second ADT, 3 has general orders (lots of combined feeds), 4 and 5 are both general ADT, devpat (devices), devres (mainly capsule items, high volume feeds), doc1 (MDMs, document ORUs), ems1 (Dealing with a complex set up for our ambulance charging interfaces), epicadt (the main ADT in, supplies all the other sites with general ADT), lab1 (about to split), rad1, rx1, sched1, sftp (SFTPs that picks up or feeds other interfaces), toepic (general results back into epic), split1 (site dedicated to splitting identical feeds, this was a legacy thing our former lead made us do), too1 (another site that deals primarily with our DMS).

When I look and think about that list and there’s some changes that I want to make, as we’ve just 100% gotten onto cloverleaf (just finished a 3 year migration from eGate — Don’t ask).

[Author]

Replies