- This topic has 8 replies, 3 voices, and was last updated 4 years, 4 months ago by
.
-
Topic
-
I know there is another HTTP thread similar to this, but I did not want to hijack that thread because my situation is slightly different.
Our current state is simple
Epic sends vaccination messages to the state immunization site. That’s it. No Cloverleaf involvement.
Our future state requires a change to that because we perform vaccinations at multiple facilities and the state now wants each facility to use a different username/password to their web portal.
My concern, other than I’ve never done any web connection in Cloverleaf, other than in class is this…
In my engine, if I have a connection thread to accept the vaccination messages from Epic, say
epic_chirp_v_in
That thread would then filter and route each vaccination message to a distinct outbound webservice connection to Chirp depending on what facility it is for, say
chirp_<fac 1>_v_out
chirp_<fac 2>_v_out
…
chirp_<fac n>_v_outIn turn, each message we send to each webservice connection to Chirp would then be ACK’d or NAK’d by Chirp. And that is the ACK/NAK that we would need to get back to Epic, so Epic users can resolve any errors (NAKs) in a work queue like they do today.
And that is the issue because when Epic sends out the vaccination message to Cloverleaf it will expect an ACK/NAK back to move onto the next message. Typically, the Cloverleaf thread would send Epic the HL7 ACK/NAK back to Epic, but in this situation that ACK/NAK means nothing because the message hasn’t even reached Chirp yet.
So at that point, do we hold the epic outbound connection up (not sure how), do not send the ACK/NAK, but let the vaccination message go through the Cloverleaf routing to the appropriate outbound webservice, then wait for the ACK/NAK from Chirp. When Cloverleaf gets that ACK/NAK from Chirp, we would then need to figure out of it’s possible to route that ACK/NAK through a different connection and get that back to Epic, so if it is a NAK, Epic can add the error to the workqueue for someone to look at, then move onto the next message.
I know that was a lot, hopefully it made sense. Thank you for you time.
Mike
-
Replies
-
-
First, does Epic have to do the exchange synchronously (that is wait for the final acknowledgment before sending next message) or can it be configured to do this asynchronously (receive a message receipt acknowledgment on one connection and then send the next message) and then receive the application acknowledgment on another thread? Does Chirp do an asynchronous exchange? If you can get Epic configured to do an Asynchronous exchange that would be the best world.
Second if it must be synchronous, do the acknowledgement messages from the state actually contain anything besides a positive acknowledgment?
Third, you can just not send an acknowledgment at the IB thread (Epic will wait), and route the acknowledgments from the Outbound threads back to the IB thread (which then will be received by Epic and it will send the next message). This end-to-end acknowledgment scenario will introduce a delay in message flow.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Thanks Jim,
I’m trying to get confirmation from my Epic resource regarding the synchronous vs asynchronous.
As for the state acknowledgments, I’m also trying to get example of those, since they are currently captured in Epic and not displayed.
…So not much at this point, just wanted to acknowledge and thank you for the reply.
-
Another thought came to mind.
I don’t know the CAA-WS addon but is it necessary to have separate connections to the state? Could the login/password be provided when each message is ready to be presented?
That at least would simplify the architecture to one thread in and one thread out with all messages routed to one destination.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
We are working on a similar interface with CHIRP right now and we keep a table in cloverleaf that maps the location to their username and password. This like Jim mentioned will allow us to keep the architecture of the interface simple.
Are you sending VXU or QBP? As far as ACKS/NAKS for VXU I will warn you that CHIRP always sends AE, even if the message is successful. If the message is not successful there will be additional error fields with more detail explaining what the issue is. Below is an example of a “ACK” from CHIRP for a successful message.
MSH|^~\&|CHIRP^^|CHIRP^^|VAC^^|^^|20200528153020-0400||ACK^V04^ACK|7740168425.101180521|T|2.5.1|||NE|NE|
MSA|AE|2|
ERR|||0^Message accepted^HL70357|I||||Patient with 1 vaccination accepted into vaccination staging table| -
Well that is a bummer. You would think a government agency could follow the standard better than that.
Something I am curious about in your example MSA-2 has the value 2. What that is supposed to be is the Control ID of the message sent which caused this acknowledgment (from 2.5 doc):
2.1.1.0 MSA-2 Message Control ID (ST) 00010
Definition: This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended.
Is that field really populated with the Control Id of the sent message? If not and the sending system can accomplish asynchronous exchange, this could cause an issue matching the acknowledgment to the original message for error handling on the source system.
Even with synchronous exchange matching acknowledgments to original message could be challenging.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
I was just informed yesterday that Epic, our HIS, can do this now with multiple connections, so we do not have to go through Cloverleaf. It’s a bit disappointing as I really wanted to get a webservice interface “under my belt”, but realistically, this wasn’t the best time to do it, since this all has to be done by the end of June, and this would be pretty tight figuring everything out by the end of June.
I was also thinking that since every connection goes to the same URL, and just the username/password changes that there should be a way to dynamically change that based on a message.
@Michael Sierra, I’d be interested in seeing what you came up with, if you able to share; if not, I understand as well. From your other thread, you doing all this via tcl script and not using the web service thread protocol?
Thanks,
Mike
-
Yes we are using a TCL script for the VXU messages. We were trying to use the HTTP protocol thread but couldn’t get it to work.
But as for the QBP we are taking a similar approach to you. We are going to try and create separate epic Interfaces for each organization. We still plan to route the messages through cloverleaf at some point but are using this method as a workaround around until we can get everything figured out.
-
- You must be logged in to reply to this topic.
