[Mitchell Rawlins]

Yes, using the Java code instead of Tcl for raw routes.  We do use TRXID for nearly all our route determination, though we have a few places where we route based on more than message type, and we use Java procs there.

Eclipse has syntax highlighting, code completion, and can look up standard functions from the Java API.  I also find the Java API to be more consistent than Tcl’s, but that’s probably a personal preference.  It’s also useful to be able to quickly switch to the definition of a function call to see what’s being done.  

Our Tcl procs before were all single body with no function or methods and code reuse was only done by chaining multiple procs together.  This isn’t a restriction of the language, but it was all I saw from the various people and consultants represented in the code base.  Our move to Java helped us shed some of that legacy difficulty, and it makes it very easy to find every piece of processing relating to, say, RXR-2 in VXU messages.  We still switch windows, but we spend less time switching between them and more in the same place.

Maintainability is the big reason not to switch from what you know and do, and I wouldn’t recommend it to everyone for that reason.  But I’ve really liked it, and when I have a choice I’ll pick Java.  Often I won’t have a choice, and that’s okay.

[Mitchell Rawlins]

We converted all our TPS procs to Java UPOC about 2 years ago.  Overall we’ve found improved productivity using Java TPS.

We did not find any enhanced or degraded performance; our measurements of performance indicated the bulk of the processing time and work relates to the recovery database (disk access, etc.).

We use Eclipse IDE and SVN for source editing and version control, which helps us resolve most syntax and basic logic errors before testing.  With strict typing (as opposed to Tcl’s loose typing) we eliminate a lot of uncertainty in our build, particularly when revisiting a proc we haven’t touched in 6-18 months.  

We were able to build some utility classes to allow code re-use.  In Tcl we would simply string multiple procs together, but then we were moving back and forth between the Cloverleaf client and/or NetConfig and the proc editor to see all the processing for a given interface.  With Java (using Eclipse) we’re able to trace everything that happens to a message in the same place without sacrificing code reuse.

One particularly tricky interface required us to put at least 2 minutes delay between messages for the same patient (otherwise the receiving system would re-order adds and deletes).  We ended up using Java collections to create essentially separate “queues” for each patient as they came in (and remove the queue when the last message for a patient was processed to avoid memory leaks).  A Java timer would trigger the upload of messages using the Apache Commons HTTP client libraries to upload to the web server.  It has some imperfections, but the upload is a lot cleaner and more stable than when we used Tcl and curl; we didn’t implement the separate queues until after moving to Java, so I don’t have a comparison there.

Where I have a choice I will always use Java UPOCs over Tcl and Xlate.  The biggest things for me were the strongly typed language and the well supported IDE.

[Mitchell Rawlins]

I took the approach of “don’t ask; tell.”

Epic triggers A31 on patient-specific (essentially No-Add) data, and A08 on visit-specific (any of your over-time) data.  I’ve seen very few workflows that don’t generate both patient and visit specific changes, so we trigger an A08 for nearly every A31.  Right before a merge is where we have the most likelihood of A31s without an A08.  It’s probably easier to fix failed merges than to fix a broken engine.

Our lab folks wanted the A31s, but they couldn’t use them because there’s no visit ID, and that’s a mandatory field in their system.  Visit ID was mandatory, so I blocked A31s and they didn’t notice.

You may not be able to pull that off, but at least during our go-live it was more important to keep messages flowing, even if it required more manual clean-up on the end systems than normal.

I don’t remember us having too much trouble with message volumes during go-live.  It’s important to only route the message types that are needed, and A31s are the biggest ones to worry about.

Good Luck!

[Mitchell Rawlins]

I don’t know that I’ve seen this issue exactly, but there are a few things I might try.

Stop the process, stop and start the host server, then re-start the process.

Update both CLASSPATH and QDXI_CLASSPATH to be equal (or at least point to all the same things that you need for your classes).  I’d probably also doing the re-start process above after refreshing the environment variables.

You could check to make sure your cljava.jar files are still there, and open them up to make sure the appropriate classes are still in there.  Most GUI unzip tools will unzip the jar and let you see the classes inside.

I hope something there helps.  I’m interested to see what you find the issue is.  Good luck!

[Mitchell Rawlins]

It’s a frustrating process.

We interface docs from Epic to 3M CAC.  We were sending from source systems as well, except it didn’t work properly.  CAC needs to work off the billing account number, not the clinical encounter number, but all our other systems (pathology and radiology) need to work on the clinical encounter number to work properly.  It was a pain getting those other downstream systems to track multiple encounter numbers, so we ended up re-tooling and everything now comes straight from Epic.

We don’t do a whole lot in Cloverleaf to get the documents to CAC; it handles messages straight from the print server about as well as it does anything.  The base-64 encoding is a pain.

Picking the right print groups in Epic to determine what to send, and configuring them right, took us a while to get right.  That’s not really an interface thing, but it ended up on our plate here because nobody else could seem to figure it out.

Good luck, and I hope things go better for you than they did for us.

[Mitchell Rawlins]

This may not exactly answer your question, but I’ve done the following sort of thing.

cd $HCIROOT

grep “” */NetConfig

If you get a lot of results the -c switch on grep may be helpful.  If you can’t remember capitalization you could also use the -i switch.

This doesn’t natively work on Windows, but why would you have that many sites on Windows?  Also, you could install cygwin or mingw and get grep that way.

[Mitchell Rawlins]

To split out files I would use pdftk.

The difficulty will be determining which pages belong together; if each page can be stand-alone then we’re done with pdftk’s burst feature.

It has a function to uncompress PDFs, which may allow you to use a lexical analyzer to determine which PDFs belong together.

My first approach would be:

1) split out all the pages into separate files

2) figure out a way to classify each of the separate PDFs.  My first lead here is the uncompress feature of pdftk.  Otherwise I’m going to be doing a lot of Google searches, and finally looking to grab some libraries out of a PDF handler like evince or okular.

3) join up the groups of pages into their own PDFs.

This may not be the best approach, but it’s what I would take if trying to do this sort of thing.

[Mitchell Rawlins]

I agree that escaping on a field-by-field basis is a good general approach.  You might be able to get away with changing the & in MSH-2 to something else (like ` or @); do this on an in-bound Tcl proc.  Cloverleaf won’t interpret & as the subcomponent separator.  You may have to change it back for the downstream systems.  Or they just may assume it’s an ampersand and ignore MSH-2.  

The safest bet is to have a Tcl proc explicitly escape all the ampersands you know are good and leave the rest.  It’s not the only way, though.

[Mitchell Rawlins]

We did a similar HIS rebuild, and we started with all-new sites.  Many of the thread-specific Tcl procs we pulled forward don’t work right anyway.  A lot of times it’s been easier to re-write those procs than to fix them.  For really generic procs worked great without tweaking.

I would definitely go that route if I ever do it again.

[Mitchell Rawlins]

It’s an HL7 wildcard raw (with UPoC).  If Xlate looks at additional metadata fields that aren’t re-set then that could cause trouble.  

One option I considered was creating a new message, copying the content from the old, killing the old, and re-submitting the new.  There would likely be a performance hit doing it that way, and I’m not sure it’s worth the effort at that point.  It seems that as long as SOURCECONN is set right that the raw works okay.  Some of the other route types may require DESTCONN to be re-set, though I’m not sure what to.

[Mitchell Rawlins]

That’s really quite bizarre.  I’ve been running tests most of the afternoon and haven’t had trouble.  We’re on 5.8.4 right now, for what it’s worth.

I’ve currently got a proc that I use for troubleshooting that outputs a bunch of the metadata fields.  For one message, I get this in the outbound: (before the OVER proc)

Code:

XLTTHREAD:
SKIPXLT: 0
CLASS: engine
STATE: 10
DESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
SOURCECONN: ib_epic_adt
ORIGDESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
ORIGSOURCECONN: ib_epic_adt
com.quovadx.cloverleaf.upoc.MessageMetadata@8a0d5d
driverctl:
DATAFMT:

And this on the inbound (after the OVER proc)

Code:

XLTTHREAD:
SKIPXLT: 0
CLASS: protocol
STATE: 1
DESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
SOURCECONN: xt_radord
ORIGDESTCONN: xt_radord:vm-engine-d2:10700:epic_rad::xt_radord
ORIGSOURCECONN: ib_epic_adt
com.quovadx.cloverleaf.upoc.MessageMetadata@173831b
driverctl:
DATAFMT:

There really won’t be a Tcl equivalent to the com.quovadx line, but otherwise all these should be accessible in Tcl.  It goes through TrxID normal for us.

Your code looks good as near as I can tell; I may plug it into our test system and give it a whirl to see if it really works any different than the Java proc.

[Mitchell Rawlins]

Quote:

Site 1 Inbound —> destination (inter-site thread to Site 2 OutboundA)

       ( so that the transaction is sent directly to the OutboundA thread in Site 2.)

versus:

Site 1 Inbound —> Site 1 outbound (localhost) .. | .. Site 2 Inbound —> Site 2 OutboundA

       (which is how site-to-site is accomplished without the new intersite option)

It is possible using a fairly small upoc to get the second scenario to work.  I’ve posted code at <a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=5615&highlight=intersite+routing&#8221; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=5615&highlight=intersite+routing.  It may not be the best approach, but at least it doesn’t require as strict a naming convention as other solutions that have been posted.

[Mitchell Rawlins]

I found something that seems to work.  In my proc to  OVER the message, I first set the SOURCECONN metadata to the thread name in the destination site.  I’m using a Java UPoC for this.

Code:

public class Resubmit extends TPS {

public DispositionList process(CloverEnv cloverenv, String context, String mode,
Message msgobj) throws CloverleafException {
DispositionList dl = new DispositionList();
if(msgobj == null){
return dl;
}
msgobj.metadata.set(”SOURCECONN”,cloverenv.getThreadName());
dl.add(DispositionList.OVER,msgobj);
return dl;
}
}

The Tcl equivalent using msgmetaset should be just as straightforward.

The thread name could be hard-coded in, or passed as a parameter, with different pros and cons for each option.  I initially tried setting the SOURCECONN equal to the previous DESTCONN (because presumably that’s where we are now); this didn’t behave well with the inter-site messages.

[Mitchell Rawlins]

I came up with a nearly identical approach to inter-site routing on our systems, and hit the same snag.

[Mitchell Rawlins]

I’m curious if there is a difference between the tclIndex files on the two boxes.  If so, I think you copy the one from the working box to the not working.  It’s probably a long shot, but I would check it out.

We haven’t run into that issue on our 5.7.2 or our 5.8.4 boxes, but we’re not on 5.8.5 yet.  If it’s a version-dependent issue it’s probably worth checking which files were changed in rev5; that may give you some idea on where else to look.

[Author]

Replies