EPIC integration with Cloverleaf

[Peter Heggie]

About ten years ago, I posted to this group, looking for information and advice on an upcoming transition to a (then) new EMR called Soarian. We received some great responses including a long phone call where many aspects of Soarian (OpenLink) integration were discussed. By the way, all of the advice and experience shared was very useful and saved us a lot of work.

Here we go again. We will soon be starting a project to move from Soarian to EPIC. I’m looking for advice, or even a few sentences about the experience. All the usual topics will be welcomed. If you want to share, but want to do it offline, that is great also.

Would also love to hear people’s take on EPIC Connect vs. EPIC Direct. Has anyone gone the Direct route and then later taken on other hospitals where they come in as Connect customers?

Peter

Peter Heggie
PeterHeggie@crouse.org

Topic

[Peter Heggie]

adding email

Peter Heggie
PeterHeggie@crouse.org

[Jason Russell]

We’ve been with Epic since 2017 (live, started the project in 2016). There are a few key points about Epic and LOTS of decision making that will happen (both at your level and much higher than your level).

• No Epic integration is the same. There will be different teams that do different things.
• You will have some modules that others don’t and vice versa, just depends on what your organization decides to spend on.
• Epic has a lot of solutions (That cost money) that make many integrations much easier.
• From what I can tell, neither Epic Connect or Epic Direct is tied into ‘integrations’, meaning Cloverleaf will have little to nothing to do with those.
• Direct Messaging is handled through Care Everywhere.
• Epic Connect is also a MyChart feature and I’m thinking of the correct item, it’s sending data from facilities through Epic. No “integrations” done.

If I’m thinking of the wrong things, feel free to correct me. Epic has MANY different modules with MANY different names.

So a super basic high-level item with epic, ALL of their master records have an 3 letter ID that tells you what they do. AIPs are your interfaces. AIK is the Interface Kind which determines how your interface functions. EPT is the patient master record, things like that. There are hundreds of these, most you’ll never touch.

From an “integrations” standpoint (HL7, FHIR, etc) you will be working with Bridges, which is their primary connections for HL7 and X12. These are the interfaces that will connect to Cloverleaf and back. You will be no real coding in Epic, just setting profile variables (PV’s) on your interfaces (AIPs) to make the interface “do things”. There are custom codes that they do (Programming points) but they are incredibly basic and will normally be handled by your TS (technical service) person.

Some “epic funny business” that I’ve seen from our implementation specifically. Epic has a hard time differentiating between A31 (person level) and A08 (visit level) messages. While this is fine most of the time, there are some systems that don’t want visit information in their A31s, and need visit information in their A08’s, and Epic just doesn’t do that sometimes. Again, most of the time it doesn’t matter, but for some systems it may, so you may have to check for those.

Develop everything at a minimum of HL7 2.5+. Epic doesn’t really have a “Version ID” and they use a lot of bits and pieces from various HL7 standards. To save yourself a lot of effort, skip 2.3.1 completely and just jump to 2.5, if that is even a consideration. It will make your structures a lot easier to manage.

Something new, typically most of your interfaces will be outgoing data (ADT, Orders, scheduling, etc) and sometimes a response (Results, documents, etc).  However, they’ve been moving to a weird hybrid of bidirectional interfaces where they will send a message and expect a response on that outgoing interface, except they actually jump those replies to an actual inbound interface to route back into epic. Brush up on your ACK levels (Commit vs Application) and “extended acknowledgement” using MSH 15/16 to determine IF and HOW they want replies. You’ll run into this when you start doing device integrations and potentially with state-level integrations IF you go the HL7 route and not SOAP over HTTPs. We’re in NC and … NC is behind in that so it may not be an issue.

In the 7 years we’ve been on Epic, I’ve noticed a trend where Epic is trying to do EVERYTHING. They do a LOT of FHIR integrations, but they give a few for free then start charging for it. They are pretty convenient, but it’s going to be a $$$ issue. They’re now starting to implement their “not an engine” Space Bridge where they can do basic filtering and whatnot, so I fully expect there to be a lot of expansion on that in the future. Not sure how far they’ll go with it, but considering how they’ve been so far, it wouldn’t surprise me if they tried to replace conventional interface engines.

Epic is a pretty big deal with a pretty big company. There’s a LOT of moving parts in Epic and a lot of times things get lost in the aether. There’s a lot of other minor things that we’ve come across that may or may not be applicable in your situtation (Physician IDs (Use NPI!), having a HAR ADT and CSN ADT depending on your needs, etc). It’s a big project, but Mama Epic will be with you every step of the way. They will have loads of people on their side helping you implement this and guide you, but a lot of their ‘guidance’ will be keeping you in the Epic fold as much as possible.

Good luck!

[Peter Heggie]

This is great detail – thank you. Our current financials/ADT interface from our EMR is 2.7, so I think we are good there. But our clinical interfaces – orders, results – are 2.4, so we may have a lot of work to do with clinical interfaces.

Is a TS person an EPIC employee? I’m wondering where the line is, between what we would do and what they would do.

Right now, with Cerner/Oracle, we have Cloverleaf connecting to Openlink. We don’t do any programming in Openlink. On rare occasions, maybe five or six times in the last eight years, we have had Cerner make changes to Openlink. But 99.9% of the time, we do everything in Cloverleaf, when it comes to translation and transformation of interface data to and from ancillary systems. As far as doing everything in Cloverleaf, does that remain the same? And there is a potential for less interfaces if some of our modalities are part of the EPIC component set?

The ACK work sounds interesting; we only do the immediate, “message received” ACK for the most part, except for a state registry interface, which sends us application ACKs.

Peter

Peter Heggie
PeterHeggie@crouse.org

[Jason Russell]

TS is an Epic Employee. Basically your direct contact that is an “expert” in your area (Being bridges). You will do the day-to-day (port changes, starting/stopping, basic troubleshooting, setting up and getting details from vendors, etc), and they will do more complex stuff that requires deeper dives into other parts of Epic. They have access to what other facilities do (their ticketing system, Sherlock, they can see non-phi items for other hospitals). If you can’t figure out the issue, they normally can, though sometimes it takes times. They also reach out to the actual Epic Devs on really complex issues (we’ve hit that a few times).

You’ll basically continue doing the same thing you’re doing now, except you do have a bit more control in Epic, setting PV’s to determine how your specific interface in Epic works. As part of your implementation, you will be sent to take the Bridges class (do it in person, I will admit their campus is amazing), and get certified. you’re not supposed to work in Epic (on the back end) unless you’re certified. When I did the class, it was two days, and some of those certificates (Cogito, Beaker, Willow, etc) can 1-2 weeks or more.

Honestly, your state query (the one we’re fighting with now is the vaccine query) should really be FHIR or SOAP/HTTPS which really simplifies things, but it depends on the state itself. Like I said NC is behind the curve with this technology, so your mileage may vary, but it seems you already have some experience in that.

I’ll be more than happy to answer any question I can based on my experience.

[Peter Heggie]

Can EPIC take in lab results in an older version of HL7? Our current lab vendor sends us results in v2.3. So not all data is discrete and not all meta-data is discrete. Does that mean documents like CCDAs, sent through Care Everywhere, could not be ingested in other EMRs, because some of the data is textual, not discrete?

Peter Heggie
PeterHeggie@crouse.org

[Jason Russell]

Epic is pretty flexible on how it gets data and displays data. I’m not sure if they can process textual data to discrete fields, but it wouldn’t surprise me if they did. That will be handled by your Beaker analyst and their TS. Typically if you want it to fill discrete elements you’ll have to mark it as such. I can’t say much in the way of CCDAs, we don’t touch those at all. Those are handled by different groups (Grand Central or HIMs I believe). Once of the decisions that were made is that our Bridges group would not handle any FHIR or “API hooks” as some refer to them as. Most data imports are going to be handled by non-bridges folk (Usually the group where the data is going to go). Things sent to and picked up by SFTP are not handled by the interface group (excepting facilitating the transmission of said SFTPs in many cases).

You may find that the reach and some of the things that you were doing in your current set up may no longer be your responsibility in Epic.

 

[Author]

Replies