[Ryan Boone]

Thanks, Jim!

Yep, I missed the List Full Directory checkbox, and the file size is included:

{file1 {{LENGTH 4567} {MTIME 1416347174}}} {file2 {{LENGTH 322} {MTIME 1716347174}}} {file3 {{LENGTH 8888} {MTIME 1416347999}}}

Ryan

[Ryan Boone]

Using the directory parse TCL in fileset-local works. However, when there are over 100k messages in the inbound directory, it can take a while for the thread to scan (list) the directory contents, and the sheer number of filenames is a lot to read into the script and sort (especially if you have longer filenames). To remedy this, configure the directory parse script to read 500 kbytes  (or whatever is reasonable), sort the filenames, then remove the last one in the list (because it won’t be a full filename after reading in a specific number of kbytes). The thread will pick up that file on the next scan. Then set the scan interval to a lower value (like 5) — as the thread will not scan the directory while it’s reading data anyway, but once it’s finished processing you don’t want to waste time before the next scan is executed.

Adding a sequence number to MSH-13 and validating messages as they are read into the fileset-local inbound thread indicates the messages are in order, and none are missed.

 

 

[Ryan Boone]

Thanks again, Jeff. 4 million records would definitely be enough and then some (running on AIX). Some of our ADTs are quite large but it sounds like there’s a lot of room there for a large volume. I can always test to get a message count / size comparison. We do have TCL-based SQL interfaces as well, so that’s where we’ll start.

 

Regards,

Ryan

[Ryan Boone]

Thanks, Jeff.

How many messages did you queue in the SQLite database at the most? That is something we are considering but would need to volume test it.

We did write individual messages to file, but at the pace of the messages being written, regardless of whether they were written/retrieved by alpha/numeric or timestamp, the order was not always guaranteed. That did allow us to regulate the volume successfully, and was generally okay for ADT, but for SIU message pairs sent from Epic discovered they could be retrieved by the fileset-local out of order.

[Ryan Boone]

Jim Kosloskey wrote:

So if the issue is some receiving system cannot keep up with the pace so that an interruption in connection takes you over the cliff. Has it been determined the receiving system has done everything that can be done to improve their performance so they can keep up? Do they need to receive all the messages (maybe if you can reduce the load they can keep up)?

Thanks, Jim.

Yes, we have several “send everything” interfaces, so ADT for multiple hospitals queue up quickly. One receiving system is having difficulty keeping up. But the larger issue is that it only takes a few hours for messages to queue to rdb-busting volumes if an external system is down or if we experience VPN issues. It would be nice to have true “disk-based queuing” capability once the threshold reaches a certain level, then back to normal under that level. The solution may be to load-balance using dedicated AIPs.

[Ryan Boone]

Hi Jim,

 

“If I were to have many systems which do not stay up and they will not resolve the issue, I would lump them together in their own site and inform the system owners their interfaces will be slow and potentially backed up and it is not the fault of Cloverleaf. If they resolve their system such that it is reliable then they can be moved to a site with the ‘good kids’. This does not resolve the issue with the Recovery DB but it focuses the pain on those system that do not play right.”

 

Yes, in theory this would be good. But the larger issue is that we have such high volume that it’s not entirely the fault of the OB systems that the interfaces queue up so quickly. And then, if we have VPN issues, that also is not the fault of the external system. So I’m wondering if there is a strategy (preferably automated) to handle such volume without causing a process and/or site crash that would then proliferate the backups to other sites or to the sending system — precluding writing the files to disk to be picked up by another thread since that does not guarantee FIFO.

[Ryan Boone]

2 newer versions of sqlite-jdbc.jar had been added to the /clgui/lib directory, which caused the issue. Removed them and cycled the host server and the resend works again.

[Ryan Boone]

Max Drown wrote:

If in doubt, try it!! Setup a test xlate and send messages of different types through and see what happens.

Choosing the message type for new xlates or reconfiguring existing xlates simply determines what part of the variant is show in the xlate, but it does not determine how the message is parsed. For HL7, the message will be parsed based on the value in MSH.09.02. If your paths are different for different types, then you can reconfigure the xlate to see the paths for each different type. But, like Charlie said, its much easier to make every time look the same using optional and repeating components.

Thanks, Max — I did test it, and it works fine in a controlled situation for all of the event types tested. My main concern is whether this goes against best practices since I’m essentially taking a vendor spec and creating a customized variant that melds all of the event types together as one long list of optional segments. On the other hand, I suppose if it gets too unwieldy during the build process it wouldn’t take much to split them out.

[Ryan Boone]

Would Charlie’s advice below from several years ago still be optimal for a STAR-to-Epic / eGate-to-Cloverleaf ADT migration? It seems that Cloverleaf, to an extent, enforces the event-type definition. But provided there isn’t a morass of conditionals based on event-type in an all-in-one Xlate scenario, is this still the best way to go?

Thanks for any recommendations.

Charlie Bursell wrote:

Not only can you do it, I highly encourage it.

[Ryan Boone]

Russ Ross wrote:

I had to implement a work around for time zone displayed in the IDE when I got legacy Cloverleaf 5.6 IDE working under Win7.

Here are the steps outlined to navigate the IDE menus to what change I made for CST time zone:

IDE -> options -> advanced tab -> set JVM arguments to:

[Ryan Boone]

Thanks! I was able to get this to compile without errors.

Levy Lazarre wrote:

Ryan,

The full set of HL7 Version 2.x XSDs can be downloaded as a .zip file from the following site:

Code:

http://wiki.open-esb.java.net/Wiki.jsp?page=HL7

Then you could take an ADT_A01 HL7 message, for example, and translate it to XML using the A01 xsd provided.

I hope this helps.

[Ryan Boone]

How would I convert PDF to Postscript via Cloverleaf?

[Ryan Boone]

Thank you for your help Jim, with resolving both of my questions above (regarding the previous Xlate I was using and the current one).

[Ryan Boone]

Jim,

I apologize — we do have the Rev 2 patch, so I typed the wrong version.

I found another, similar Xlate with variants that I had created from scratch in 5.7.2. Now I am not receiving the same errors in the test tool. The Xlate that generated the errors had a previously created, reused variant on outbound, and although it looks identical to me, I’m not longer getting the same errors. However, while it no longer indicates that the PV1 is invalid and that the ORC/OBR pairs are out of order, now the Xlate simply isn’t iterating them properly:

1(0).1(0).0(0).ORC(0)  :  >|CN<

1(0).1(0).0(0).OBR(0)  :  >|1||1001938|142^XR-KNEE 4 VIEWS INJURY|||20100609151236|||||||||99999^NOAH||||||20100609151838|||F||^^^20100609144800||||FALL/PAIN|1234|~121055<

1(0).1(1).0(0).ORC(0)  :  >|RE<

1(0).1(1).0(0).OBR(0)  :  >|2||1001937|4^XR-ANKLE 3V|||20100609151236|||||||||99999^NOAH||||||20100609151838|||F||^^^20100609144800||||FALL/PAIN|121055|~1234<

I’m iterating on the group 1(0).1(0).0 with %g1 as the variable. What is the simple thing that I’m missing here? 🙂

Thanks,

Ryan Boone

[Ryan Boone]

I would like a copy as well, please, if it’s not too late. Thank you!

boonec@spectrumlab.org

[Author]

Replies