Synchronous processing?

This topic has 12 replies, 7 voices, and was last updated 10 years, 1 month ago by Terry Kellum.

Creator

Topic
June 4, 2015 at 2:17 pm #54710
Mike Strout
Participant
I have an inbound order thread that has two destinations, an ADT thread and an order thread, both on the threads going to the same downstream system. I need to send the ADT to create the patient BEFORE the order message arrives.

What is the best way to accomplish this sort of synchronous processing where the message won’t be sent to the second thread until/unless it is successfully ack’ed by the first thread?
Creator

Topic

Viewing 11 reply threads

Author

Replies
- June 4, 2015 at 3:46 pm #82660
  Jim Kosloskey
  Participant
  Most systems can do a ‘mini-reg’ when receiving an order before the patient is created via ADT. Many times I need to specifically request the receiving system do that as they are not configured out of the box to do a mini-reg and frequently the field people do not know such a thing exists.
  
  If that is the case, then you should not need to do anything.
  
  email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.
- June 4, 2015 at 4:11 pm #82661
  Mike Strout
  Participant
  Unfortunately, in this case, all we get from the source system in an ORM_O01 that contains all the patient demographic and payer info in addition to the order-specific segments. The target system can’t create a patient from an ORM message, so I need to send them an A08 based on the ORM. Only after I received the ACK for the ADT_A08 can I send the ORM.
  
  I was hopeful that chaining might work, but upon further investigation, it doesn’t look like it because it would transform the ORM to an ADT, but I couldn’t flip it back to an ORM because the order segments wouldn’t exist in the intermediate message.
  
  I could always throw the ORM message into a DB and then use a tcl proc in the Send OK Procs field on the outbound tab to pull the message and send it, but that seems like an inelegant solution.
- June 4, 2015 at 6:17 pm #82662
  David Barr
  Participant
  Rather than using a separate database, why not throw the ORM message into the message metadata for the ADT message? Then the Send OK proc could get the message from the metadata without having to go to an external database.
- June 4, 2015 at 7:15 pm #82663
  Mike Strout
  Participant
  David,
  
  Thanks for the cool idea. I haven’t written to meta data like this before. I would be interested in hearing how it is done.
  
  After talking with Jim by phone, we think that if the order arrives before the ADT message, Cerner should be able to do a mini registration and pend the order. When the ADT comes through, the complete registration would happen and then the order would be released inside Cerner. The only question is whether my Cerner interface resource will be able to make this happen. If not, your solution seems like a winner.
- June 4, 2015 at 8:17 pm #82664
  David Barr
  Participant
  ~~Mike Strout wrote:~~
  
  David,
  
  Thanks for the cool idea. I haven’t written to meta data like this before. I would be interested in hearing how it is done.
  
  Something like this in a TPS proc:
  
  Code: set msg [msgget $mh] set userdata [msgmetaget $mh USERDATA] keylset userdata ORIG_ORM $msg msgmetaset $mh USERDATA $userdata # code to change msg from ORM to ADT goes here msgset $mh $msg
- June 5, 2015 at 12:32 pm #82665
  Mike Strout
  Participant
  This is definitely a more elegant solution. The only thing that would be better is if I could pull the message from the USERDATA, create a new message and send it to a new inbound thread. That way I could use a standard Xlate to do the conversion from ORM to ADT.
  
  I suppose I could just write the ORM from USERDATA to a file that is watched by an inbound thread. The thread picks it up, writes it to the SMAT, and sends it through the normal message processing.
  
  It would be nice though to do all this in memory instead of having to deal with disk write and read.
- June 5, 2015 at 1:49 pm #82666
  Peter Heggie
  Participant
  Could you create an ADT message from the ORM message, by building the ADT message in the ORM translate and do a SEND of the ADT message, followed by an implied SEND of the ORM message at the end of the translate?
  
  Would the variant allow that, and would Cloverleaf preserve the order of messages such that the SENT ADT message goes to the outbound thread first, followed by the ORM message?
  
  The outbound thread always single-threads the message delivery, requiring ACKs before the next message is sent, so I’m thinking that the outbound part of the process should be ok.
  
  Perhaps this reliance on Cloverleaf processing in order is not correct?
  
  Peter Heggie
  PeterHeggie@crouse.org
- June 5, 2015 at 1:54 pm #82667
  Anonymous
  Mike, I have not configured Cerner ESI for this specific scenario, but I think it should be pretty straight forward. It
- June 5, 2015 at 2:20 pm #82668
  Mike Strout
  Participant
  Peter and David,
  
  Thanks for your thoughts. I think you are both right that this shouldn’t necessarily be a Cloverleaf challenge. In a perfect world, downstream systems should always pend orders until the patient is created and then release the pended order. But as we all know, this crazy IT world in which we live is far from perfect.
  
  I will definitely be talking with my Cerner interface person about Add Ensure or orders and encounters, keeping in mind the challenges with clusters and load balancing. That said, I think the solution David and I were spit-balling would be handy to keep in mind when synchronous message flow is a requirement.
  
  Thanks all,
- June 5, 2015 at 3:30 pm #82669
  David Barr
  Participant
  ~~Mike Strout wrote:~~
  
  This is definitely a more elegant solution. The only thing that would be better is if I could pull the message from the USERDATA, create a new message and send it to a new inbound thread. That way I could use a standard Xlate to do the conversion from ORM to ADT.
  
  Just use the code that I posted in a pre-xlate TPS, and don’t modify the message in the TPS. As long as you store a copy in the metadata, it should make it through the Xlate with the original metadata intact.
- June 6, 2015 at 12:36 am #82670
  Charlie Bursell
  Participant
  In my previous life, before retirement 😀 I ran into this a few times.
  
  In one case a vendor could not accept an order scheduled more than 30 days in advance – go figure.
  
  It was a simple solution to store the order in a sqlite database and then, at the appropriate time, send it on.
  
  I would set up up a separate thread to send orders. Set up a fileset local thread and when the ACK comes in, kick the data to the fileset directory which then pulls the message from the database, deletes it and sends it.
  
  As with anything some maintenance is required, remember Murphy was an optimist. I always time-stamped the database entries. Then after a certain time, say once a day, I would run a routine which looked for entries in the database over a certain age. If there, create an error message or whatever. Easily done with a scheduled thread.
  
  FYI. Cloverleaf is designed to be a “store and forward” engine with no knowledge of what came before or after. Speed is of the essence.
- June 8, 2015 at 1:12 pm #82671
  Terry Kellum
  Participant
  I had this same problem once. I used a TCL script to place the ORM into an SQLite database with a timestamp. The original message was processed as an A08 in Translate. I had another TPS on a thread pointed at the outbound that would use the “Timed” stanza to check the timestamps in the database every 30 seconds. If an order qualified as greater than 30 seconds old, the script would generate the ORM and send it.
Author

Replies

Viewing 11 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.