Cloverleaf Results to EPIC InterConnect

We send to Interconnect for our encoded PDFs to store on the BLOB server and receive ACKs (and NAKs) back no problem.  We do have special coding in place to check for NAKs and alert us to them in case the routing isn’t setup correctly in Epic.

You might need to get the TS for Interconnect involved to make sure the setup is correct there.

If Wireshark show the ACKs are sent it may be that you are receiving them after the Await Replies timeout.  Check that.   If the thread is set up as send only you would not see the messages as errors.

Mike – I apologize for not getting back with you about the tcl proc.  I forgot to flag the post to get notified of changes.  For the proc, I made a copy of the “cl_check_ack” proc from the supplied recover.tcl procs and modified it for what I needed:

• add an argument for VENDOR which is just a free text that is used on the email body and subject
• add an argument EMAILAD which controls what emails to send it to.
• add in a write of ACKs to a file in the process directory which is the thread name and “_ack” appended to the end.

I uploaded a copy of that tcl.

You then populate the following on the Outbound tab:

• In the “Send OK Procs” put “cl_sendOK_save”(from the recover.tcl procs)
• In the “TPS Inbound Reply”put put “cl_check_ack_email” with the two arguments.  This is the modified cl_check_ack proc described above.
• In the “Timeout Handling…/Reply Type/Procs” put “cl_resend_ob_msg” (from the recover.tcl procs).

This will try sending the message to interconnect three times and if no ack still, it will put the message in the error DB and email the information.

If it is a bad ACK, it will put it in the error DB and email out that it happened along with the ACK that was sent.

As for the setup actually on the Interconnect server, I wasn’t involved with that too much, but I do believe that the Epic TS was involved in the setup.  There are some control files that need to be changed on that server to accept the HL7 and then route it to Epic based on the MSH field defined in PV IC_IN_KEY (system PV definitions) and the table defined in PV IC_IN_TABLE (system PV definitions).  In our hospital, we are also responsible for the Bridges settings.

Hope this helps!

Hello Mike and Paul,

I am now starting a project to send encoded PDFs in MDM (HL7) messages to Epic’s Interconnect from our engine. I am very interested in any issues you encountered, and the basic setup for this in Cloverleaf. I see that this thread started regarding missing ACKs, and am wondering if this is still an issue. Another important point stated is to make sure Interconnect can accommodate the very large base64 encoded messages.

And first off, what is the Thread Protocol used to interface with Interconnect?

Any input is appreciated.

Thank you.

Gordon Koch

HSS

• This reply was modified 3 years, 2 months ago by Gordon Koch.
• This reply was modified 3 years, 2 months ago by Gordon Koch.

So far we have not had any issues with encoded message sizes  going to Interconnect.  We have the Protocol setup as pdl-tcpip so nothing special there.  There was setup that needed to be done within Interconnect to have the connection but I wasn’t involved in that part of it (Interconnect support is done by the Epic DB Admins).  Refer to the Bridges Interface Communication Methods Setup and Support Guide for what is needed there.

There is Epic Bridges setup that needs to be done to route the messages to the correct interface in Bridges from Interconnect.  Look up the information for system PVs IC_IN_KEY and IC_IN_TABLE.  The same support guide mentioned above also explains these.

One thing I did learn recently is that Interconnect can handle an encoded PDF that is split between two OBX segments.  You don’t have to write up code to combine them into one OBX before sending it.

Hope this helps!  Feel free to email me if you have more specific Epic questions.

Thank you Paul for the quick response – very helpful!

We are mostly set on the Bridges side, their documentation is good and we have a great TS. However, we are hosted and Interconnect is a black box to me – no access or control of it.

I am glad to hear that this interface is working well for you, and that is an interesting point about not needing to merge OBX segments.

Just one more basic Cloverleaf question: in the pdl-tcpip setup, are you going out to a URL or IP address? I assume the Port was provided to you, correct?

I ask because I am waiting to hear back from Epic on the basic connectivity setup.

Thank you.

Gordon

• This reply was modified 3 years, 2 months ago by Gordon Koch.

We go out to the IP of the Interconnect server, and we chose the port to use.

Hello All,

I am hoping to re-engage on this subject as we have been live for some time, and it is mostly going well. However, there are two scenarios where we have experienced problems.

Firstly, when an individual message is particularly large (even for encoded PDFs), Interconnect has a problem reading the whole single OBX segment in one try (and generates an error). Has anyone tried to convert a single OBX segment (of these very long encoded sequences) into more than one? I assume Interconnect can read multiple OBXs for a single PDF per a previous post.

Secondly, when multiple PDF messages are sent to Interconnect at roughly the same time, the same apparent resource constraint issue on Interconnect arises. Is there an ideal way to throttle the messages being sent from Cloverleaf?

Thank you.

Hi Gordon,

We’ve never had an issue with Interconnect reading the complete OBX segment so we’ve never had the need to split the OBX value.  We do have one vendor that limits the characters in OBX-5 and will send multiple lines for the PDF report.  Interconnect handles them with no issues.

Regarding multiple PDFs sent to Interconnect, we have not seen that issue.  We currently have nine different systems that can send to Interconnect and send between 500-600 PDF messages to it daily (not too busy).  Most of our PDF reports are sent to our scanning system.  Depending on what the message needs to do in Epic (result an order, file with discrete data, etc) determines which method we use.

It almost sounds like your Interconnect needs to be beefed up some.  I can talk to our Client System group to see what the specs are for our Interconnect if you want, or you might want to contact your TS to see if he has some insights or tools.  I do know our Interconnect servers are virtual so things like cores and memory can be updated on the fly.

Oh yea, regarding throttling messages.  There have been various discussions about doing that on this forum.  We’ve never done that here except for fileset-local threads which have those controls built in.  From what I remember seeing, you don’t want to do something like put a “sleep” in a UPOC because I believe that would pause the whole process, not just the messages in the current thread.  I would look into the Interconnect server first to see if there is maybe an issue there.

Thank you Paul for your responses – very helpful.

I definately agree that we are hitting some resource constraint or limit on Interconnect, but was looking into some short term solution on the Cloverleaf side. Also, we will take a deeper look into Interconnect with Epic, and which is remotely hosted for us.

Lastly, can I contact you directly about your setup? My email is: kochg@hss.edu

Please email if you are available – I will be out of the office next week, but would follow up afterwards at your convenience.

Thanks again.

Gordon Koch

Hospital for Special Surgery – NY, NY

• This reply was modified 2 years, 7 months ago by Gordon Koch.