Timing of Two Threads

[Phil Jordan]

Using a single inbound thread to receive MDM messages for transcription,

I need to send that message on a thread to Epic.  Additionally, will use another outbound

thread to translate the MDM to an A31, and send to Epic.

The issue is that the  A31 must always arrive at Epic before the MDM.  Is there a way to

script TCL, so that all  MDM messages are held for 15 seconds before transmitting to

Epic?

Thanks, Phil

• This topic was modified 4 years, 8 months ago by Phil Jordan.

Topic

[Jim Kosloskey]

Can Epic receive these on a single thread?

If so, you can use Xlate Chaining to make sure the A31 goes out first. That should do the trick.

One of the issues with what you describe (2 OB threads) is what happens if the A31 or both threads go down. How would you assure when brought back up the A31s arrive ahead of the MDMs?

Moreover, I think the only way to do the delay via Tcl is by using a sleep – but that sleeps the entire process.

If 2 threads have to be used Xlate Chaining and re-routing might provide assurance the A31 are routed first but the same downtime issues arise.

Another option may be to place the transactions into a ‘suspense’ file (using the Xlate Chaining to assure order). Then delivering out of that file (numfile type Fileset Local I suspect could be used – some extra threads –  or an DB like Sql Lite).

Others may have additional suggestions.

 

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

[Todd Hamilton]

Phil, an interesting challenge.  Here are my thoughts:

• I like Jim’s idea of a DB cache approach and I agree that you need to be careful about sleeping on each message for 15 seconds.
• You may want to take a second look at why you need to have Epic receive the A31 before the MDM.  Could it really be true that the transcription system “knows” more about the patient’s demographics than Epic?  If you are trying to simply satisfy Epic’s Inbound MDM interface patient validation rules you might be able to solve the problem another way.  Probably a legit need but worth a mild second look.
• No matter what solution you come up with, create an Epic work queue and resolution steps to handle those timing errors.  Then outsource managing the WorkQueue to the HIM team 😉
• Be careful about implementing a 15-second delay rule.  The MDM interface vendors I’ve worked in the past go down often (on their side).  If you put a global 15-second delay on every MDM then when the interface goes down you will have to wait a long time for the queue to clear. Not a deal-breaker just something to keep in mind as you develop.
• Here is what I would try if you wanted to do a more realtime/trigger approach. Use the A31 HL7 Acknowledgment reply message as the trigger to send the MDM. Assuming Epic uses one MDM inbound and one ADT/Demographics/A31 inbound:

1. Receive the MDM from Transcription system
2. Store the MDM for later transmission to an SQLite DB. Parse out the HL7 message ID for a later query.
3. Build and Send the A31 to Epic
4. Receive the HL7 Ack message from Epic after successful transmission of the A31
5. Route the A31 ACK to a thread
6. Use the A31 Ack message ID as the key to retrieve the previously saved MDM
7. Send the MDM

todd.hamilton.omaha@gmail.com
(402) 660-2787

[Phil Jordan]

Hi Jim,

Thanks for the information.  As it turns out, each message has to come in on its own port.  Great idea and will keep it in mind,

Regards, Phil

[Phil Jordan]

Hi Todd,

Thanks for the information.  Will see what is can do with it.

Regards, Phil

 

[Author]

Replies