[John Harvey]

Hi, I am running version 5.4 on windows server 2003.  It’s deffinitely the Meditech side crashing.  Part of my problem is that Quovadx isn’t recognizing that.  It stays up and eventually locks the port when the Meditech job automatically restarts after the crash.  That’s making it hard to troubleshoot this.  I’d like to use QDX to troubleshooot, I know there are a lot of TCL tools available to trace this kind of stuff, but I’ve never had to use them..

[John Harvey]

it turns out the person testing on the vendor side just rebooted without turning off the services first.  Soon as he shut down the services, Quovadx did what it was supposed to and came back on clean when the services were restarted…thanks guys!

[John Harvey]

Thanks, I appriciate it.  looking forward it really seems like this is my best and cleanest option.  I’m just glad it’s limited to 18!

[John Harvey]

I have the ADT 2.4 inbound thread to recieve data.

I have another inbound tread attached to convert the data

I have a third thread set up to recieve the converted data (dump file)

I don’t see the data converting and passing it on to the third thread?

Where am I breaking down?  Both threads 2 and 3 are set up with a file protocol…

[John Harvey]

Thanks for the explanation, sometimes the simplest thoughts lead to the obvious solutions.  

From what you said, I traced back to when I first started seeing this, which is when I added some custom Z segments.  I believe I had the variant conflicting with the COPY operation I had set up in the xlate configuration.  I verified the Z segments (which repeat) were accurately set up in both 2.1 and 2.4 variants (which didn’t seem to work when I originally set this up) and then removed the operation to copy the z segmetns from one version to the other (which I set up because the variants didn’t seem to be handling the Z segments).  

The tag message didn’t appear this time and the Z segmetns are where they should be.  Thanks for the help everyone!

[John Harvey]

That’s why I’m curious about this.  All the segments are in order according to my variant and the data I need to see in 2.1 is where it should be. Would this be because the source message (2.4) contains many, many segments that are being dropped by the 2.1 variant?  Such as IN1 in betwen PV1 and NK1, ROL all over the place, and OBX, DRG, etc?  I didn’t add these extra segs to the variant because the original 2.1 won’t use them and they shouldn’t be there anyway.  The 2.1 variant is set up exactly the way Meditech sends 2.1 data…as is the 2.4…

Thanks for your input!

[John Harvey]

I’m actually not concerned about the IN1 segment ignored error.  The version of 2.1 I’m converting to won’t include that IN1 segment and it needs to be dropped.  I’m concerned about the

in reply to: an interesting testing error #62770

[John Harvey]

is it possible the Mismatched IR tag is a result of version field numbers being different?  For instance, in version 2.4, PID field 3 = 0(0).PID.00106(0).[0], in version 2.1, PID field 3 = 0(0).PID.00034.  I’m sure there are various differences in field numbering throughout.  All the data appears correct as I convert the message, so I’m really wondering if this message is something I should be concerned with, where maybe it’s a concequence of the different versions?

[John Harvey]

so you suggest I test the variant?  What error should I get if the segments are off?  I ran the test, first testing the 2.4 variant with a 2.4 message from the source system, tested the 2.4 to 2.1 exlate, then tested the 2.1 variant using the rusult message of the conversion xlate.  I didn’t get any errors from either variant, but I still get the mismatched IR tags message from the xlate…

[John Harvey]

I answered my own question after not even 5 minutes of trial and error!  All I needed to do was, while in Pathcopy,  make the sourse look like this: 4(0).[{ZCD}](0) (where ZCD is in the appropriate brackets), and then do the same thing for the destination.

If nothing else, I hope this info comes in handy for someone else…thanks!

😀

[John Harvey]

Thanks Robert, that was my original thought, but our Meditech ADT version 2.2 feed (actually 2.1) does not supply all of the segments the recieving system needs (it’s for a billing system).  I asked if we could just have an individual 2.4 feed by itself, but apperantly Meditech won’t let us do that.  Therefore, we are forced to upgrade our current 2.1 to 2.4 to get from Meditech all of the segments the recieving billing system needs (it’s not so much a vendor as it is another hospital within our network I found out).

I’ve have a pretty good handle on the conversion so far, but like you said, I’m sure I’m going to run into some unforseen complications!

[John Harvey]

Ok, I believe I understand the concept there.  I can let the A08’s pass as raw data under it’s own route (which is all I want it to do) and have a second route to handle the A40’s conversion?  I believe I’ll be able to set this up right once I actually get a successful translation configuration built for the A40 to an A18.  I’m combining different tecniques and have failed every time so far.  I can’t seem to get all the data to move from point A to point B.  

What’s happening, no matter my experiments, my xlt build is stripping out fields with nil data, therefore, important fields like MSH|10 end up at MSH|4 and the vendor chokes on the message.

I’m going to have to play around more I guess!

[John Harvey]

Yes, Hi… I see I confused things here.  OK then, I’ve attached a document with screen shots.  The first image is for the A40 to A18 conversion, the second handles A08.  In the case of the A08 (which is the bulk of the data crossing, not A18…those are rare…sorry!), I am still seeing this in the log file over and over:

10/11/2007 12:55:29

[xlt :rout:ERR /0:   comm_xlate] No routes defined for TrxId ‘ADT_A08’

These messages are bogging down my log file and so I don’t know how to make them stop. I expect to see a similar message when an A40 gets converted…

[John Harvey]

OK thanks all, I’m still not sure I got it right, however.  To clarify, this particular interface needs to send A08 as is and translate an A40 to an A18.  These are the only message types created.

I have created an xlate to bulk copy an A08 as is.

I created a second to convert an A40 to an A18.

for the most part, only A18’s cross.  So now, with two xlates created and attached to the route messages tab, I am still seeing this message (and I’m sure a similar one will be created when an A18 is encountered):

10/10/2007 15:06:23

[xlt :rout:ERR /0:   comm_xlate] No routes defined for TrxId ‘ADT_A08’

is this normal behavior, or am I still doing something wrong?

Thanks again to everyone helping out!!

😛

[John Harvey]

Thanks for your input.  

My trx ID Determination format is set at hl7 version 2.3 with no variant.  Should I create an A18 variant and apply it here?

[Author]

Replies