Muliple messages from a TPS script into xlate

[Jason Russell]

This is a complex project where we’re  holding data in various spots while waiting on some ADT demographics. The workflow I’m working on picks up stored message (encoded PDF in HL7), and them sends them to a DMS once we get the demographics back from Epic. It’s two individually functioning parts to a whole.

Inbound is just where we write the HL7 to a file with a keyword, and .HOLD as the extenxion (ORU_R01_<key>_<datetimestamp>.HOLD is the filename). We may get multiple messages (document revisions) from the sender, so as long as they’re more than a second apart, they have unique files.

Another, independent process passes the patient info and the key into Epic, and epic sends out an ADT with the encounter information in it. We take this ADT, search for the key, get the key, then use that key to search the folder for any files containing that key:

set fileList [lsort [glob /folder/ORU_R01_*.HOLD]]

The intention here is to process each of the files so it gets sent to the DMS separately. There are some translations that will happen to the message once we pick it up. The question is, how do we send each of the files to be translated and sent on through the engine as single files.

The disposition list seems to be centered around a single disposition and message header (CONTINUE $mh). Are we creating a list of dispositions and headers, are we sending through manually?

The msg commands seem to be centered around single messages, and I’ve not seen anything that shows how to send multiple messages through the TPS script prior to an xlate.

Topic

[Tim Pancost]

Hey, Jason,

Kinda kludgy, but I would tend to have the proc just move the file(s) from your hold directory to another directory where you have a file-based inbound thread looking that will then pick up the files and route and translate them.  The ADT can continue through it’s routing/translation.  Granted, there is the non-zero chance that if the outbound ADT connection is down, and messages are queuing there, you could have the non-ADT get to the DMS first.  But, then, if they’re separate connections, that’s going to be a possibility in any case.  The only way to absolutely guarantee that the ADT will get there first is if the ADT and the non-ADT are being sent to the same outbound thread to the DMS.

HTH,

TIM

Tim Pancost
Trinity Health

[David Barr]

Tim Pancost wrote:

you could have the non-ADT get to the DMS first

To prevent this you could have your script that moves the files from the hold directory run from the Send OK TPS of the ADT thread.

[Tim Pancost]

Yes, yes, good point!

Tim Pancost
Trinity Health

[Jason Russell]

Thankfully there is pretty much a zero chance. The second process is usually two weeks out from the first (Essentially Company A sends file to us and company B. Company B waits 5 days MINIMUM to make sure there’s no more updates, then processes it and sends us the ADT).

I was definitely hoping for something a bit more elegant, but writing to a place to be picked up is not uncommon in our old engine.

 

[Jim Vilbrandt]

Hi Jason,

Two suggestions:

• If it is possible, do a database query direct in Epic to retrieve the needed data when the documents are generated.
• Write a semaphore (.sem) file containing the encounter details from the ADT events in the directory with your hold files. A file read thread would be configured to only trigger on .sem files. A parse directory TCL would read the contents of each .sem and search for the matching .hold file or files. The file list returned by the parse dir TCL to the engine would be the .hold files. Each file would be treated as a message.

Best regards from Germany, Jim Vilbrandt

[Charlie Bursell]

Read each file into a list.  When the list is complete:

set dispList {“KILL $mh”}
set nmh msgcopy [msgcopy $mh]

foreach fn $files {
msgset $nmh $fn
lappend dispList {“CONTINUE $nmh”}
}

Return $displist

[Jason Russell]

The ultimate issue is we get the documents long before we get the ADT (on the scale of two weeks). It’s an overly complicated process. They’re EMS runsheets, so the transport happens, EMT documents in software by company A. Company A sends the document immediately to us, and then nightly batches the runsheets to company B. Company B then holds the runsheets for a minimum of 5 working days to ensure there are no additional notes. The runsheet is then coded, and a nightly batch sends ADT and DFT. We use the ADT to create the encounter in Epic, then use the ensuing ADT out of epic with the keyword to pick up both the DFT and initial runsheet (ORU), and file them to the encounter. There’s other components but that’s the most basic workflow. When the ADT comes out, there may be 2-4 runsheets (modifications, etc) that are tied to the encounter. The short answer is you can’t query Epic for the encounter since it hasn’t been created yet.

 

[Jason Russell]

Charlie, this may be what I’m looking for, with some potential modification, but some questions:

What is the point of the first msg copy? The original ADT will be in the first $mh, and any additional messages will be from the files themselves, so wouldn’t it be better to:

foreach fileName $fileList {

set fh [open $fileName r]

set newmsg [read $fh]

close $fh

msgset nmh $newmsg

<do some minor work on putting MRN/CSN into message>

lappend displist {CONTINUE $nmh}

}

This will produce a list that is {{CONTINUE <first message raw>} {CONTINUE <second message raw} {…}}

That will push each message individually into the next step (in this case, next step being translation)?

 

In essence the disposition list can be a list of lists (not just a list with two items) that contains the disposition and the message, that would functionally work the same as individual message, so if I were to pull in a file with multiple messages (a batch-style), we could process each message individually, and append the dispList with all of them to be broken apart after the TPS is done, doing other dispositions (KILL, ERROR, etc) on each message.

[Charlie Bursell]

I made a mistake.  The msgcopy should be inside the loop.  msgcopy will give you a new message handle for each message while maintaining the original metadata.

To make it better, if he original message was large, after getting the data from the original message handle you could do something “msgset $mh “.  That way you are not copying the data with each msgcopy, only the metadata.   Note the original message handle is killed since it contains nothing needed after the loop.

 

I hope this makes sense.

[Jason Russell]

Charlie Bursell wrote:

I made a mistake. The msgcopy should be inside the loop. msgcopy will give you a new message handle for each message while maintaining the original metadata. To make it better, if he original message was large, after getting the data from the original message handle you could do something “msgset $mh “. That way you are not copying the data with each msgcopy, only the metadata. Note the original message handle is killed since it contains nothing needed after the loop. I hope this makes sense.

A lot of this nuance is what I’m trying to figure out. I’m assuming my statement prior about different message handles being passed in is correct. msgset puts data into the current message ID, so I don’t think I want that, I think msgcopy will be fine (since the original message is a small ADT), then I can replace the message itself.  The script would be more like:

set fileList [lsort [glob /folder/ORU_R01_*.HOLD]]

foreach fileName $fileList {
set newmh [msgcopy $mh]
set fh [open $fileName r]
set newmsg [read $fh]
close $fh
set newmh $newmsg
lappend dispList “CONTINUE $newmh”
}

I would do msgcreate, but I do want to keep the intial metadata (where it came from, etc). I believe this is ultimately what I’m looking for.

• This reply was modified 3 weeks ago by Jason Russell.

[Author]

Replies