Crazy Mismatched IR Tags issue

[Mike Strout]

I am troubleshooting an Xlate that started as a pretty standard ADT 2.3 to 2.2 translation. I noticed during some testing that one of the messages is throwing a Mismatched IR Tag error. When I troubleshoot these, I usually just disable more and more of the Xlate and retest until the error stops happening and then re-enable a line at a time until I identify the offending line. In this case, it was the PV1 segment.

I was doing a PATHCOPY from 1(0).PV1(0) to 0(0).PV1(0), but the paths were correct. I noticed that the source had 52 fields and the target only had 50. To try to step around this, I decided to try a simple copy from…

1(0).PV1(0).#1(0).[0] to 0(0).PV1(0).#1(0).[0] (set ID to set ID)

No luck. Thinking it may be a corrupted Xlate, I decided to create a new one and make it as amazingly simple as possible. Here it is…

prologue

   xlt_infile: hl7 2.3 Epic_v23 ADT_BASIC

   who: stroutm

   date: August 31, 2015 12:01:12 PM CDT

   xlt_outfile: hl7 2.2 cerner_v22 ADT_A01

   type: xlt

   version: 7.0

end_prologue

{ { OP COPY }

   { ERR 0 }

   { IN {{1(0).PV1(0).#1(0).[0]}} }

   { OUT {{0(0).PV1(0).#1(0).[0]}} }

}

I verified that PV1-1 in both the source and target formats are identical, using the same field ID, type and length. When I run this Xlate in the testing tool, I still get the following…

MESSAGE 1

[0:TEST] Mismatched IR Tags

[0:TEST] Data fetch warning: Mismatched IR Tags

0(0).MSH(0)  :  >|^~&|||||||ADT^A01||P|2.2< 0(0).EVN(0)  :  >|A01< 0(0).PID(0)  :  >< 0(0).PV1(0)  :  >< I don’t know why the other segments are being sent, but I assume it is a “feature” of Cloverleaf. I also don’t understand why this simple single field Xlate could cause a Mismatched IR Tags error. At this point, I figured it had to be a problem with the source message. I started deleting one segment off the end at a time and testing until the error stopped. I finally found that if any of the IN1 segment existed in the message, I would get the IR Tag error. As soon as it was deleted, the message translated cleanly. However, PV1-1 still didn’t copy into the target message. I looked closely at the 2.3 variant and the 2.2 variant. The 2.3 for an A09 had IN1 and IN2 segments in it. The 2.2 didn’t. This shouldn’t matter though as Cloverleaf typically just ignores the segments that aren’t in the target message, and if this was a problem, why didn’t freak out about the IN1, but not about the ZPV segment that existed in the 2.3, but not the 2.2? Any why is PV1-1 still not copying into the target message? I did find that if I change the message type to anything other than an A09, the xlate works perfectly. I dug into the A09 format both within the app and in UltraEdit and found nothing noteworthy or different than any of the other formats. Any thoughts?

Topic

[Jim Kosloskey]

Mike,

Can you publish your 2 variants (a screen shot from the HL/7 Configurator would be great)?

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Robert Kersemakers]

Hi Mike,

As Jim suggests: have a look at the variants, or show them here.

I had a quick look at 2.2/2.3 ADT messages and nowhere do I see a PV1 segment coming from group 1(0). So your inbound field

Code:

1(0).PV1(0).#1(0).[0]

looks weird. Shouldn’t that be

Code:

0(0).PV1(0).#1(0).[0]

?

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Mike Strout]

Well, Robert got me looking in a new direction and I figured it out, though I don’t know how it ever worked.

In our translates, we typically configure the input and output message formats for ADT_BASIC or ADT_A01, even though other message types will be flowing through the translate. It would be crazy to have to create a translate for each ADT message type.

Lo and behold, in the standard 2.3 ADT_BASIC format, the path to PV1-1 is 1(0).PV1(0).#1(0) because PV1 is in a repeatable group. However, in the 2.3 ADT_A09 format, the path is 0(0).PV1(0).#1(0).

I will try to explain some more curiousities with some screen captures.

http://i.imgbox.com/KnmV7pO0.jpg" />

In this capture, I have the source set to 1(0).PV1(0).#1(0). An A08 correctly populates PV1-1. An A09 throws a mismatch error.

http://i.imgbox.com/5l8JKCNx.jpg" />

In this capture, I have the source set to 0(0).PV1(0).#1(0).  An A08 does not populate PV1-1, but it doesn’t throw an error. An A09 correctly populates PV1-1.

http://i.imgbox.com/oysqLAB3.jpg" />

In this capture, I have the formats set to A09 so you can see the difference between it and the ADT_BASIC above. When the A09 formats are explicitly specified, I experience the same results as above.

For the record, here is the test message…

MSH|^~&|||||20150901141922|676|ADT^A09|37827|T|2.3|||||||||

EVN|A09|20150901141922||ADT_EVENT|012623^COLWELL^MELISSA^^^^^^TMF^^^^^MFHT|20150827085700|

PID|1|100011162^^^MRN^MRN|100011162^^^MRN^MRN||CCH^INPATIENT^CATH||19530827|M||W|23 URBAN COWBOY ROAD^^TYLER^TX^75701^USA^P^^SMITH|SMITH|(903)595-5555^P^PH^^^903^5955555||ENG|M|UNK|400000012621|000-00-0000|||NOT HISPANIC||||||||N||

PD1|||MOTHER FRANCES HOSPITAL^^10100|006220^ESFANDIARI^NEDA^^^^^^PROV^^^^PROV||||||||||||||

PV1|1|CCH – INPATI|CCB1^0408^01^20100^R^^^^^^TMFDEPID|3|||002581^PATEL^SUHEL^^^^^^PROV^^^^PROV|006220^ESFANDIARI^NEDA^^^^^^PROV^^^^PROV||CRD|OPCU^^^10100^^^^^^^TMFDEPID|||L|||002581^PATEL^SUHEL^^^^^^PROV^^^^PROV||400000012621|MNGC||||||||||||||||||||||^^^20100^^^^^^^|^^^^^^^^^^|20150827085700||||||10002953||||

PV2||D||||||20150827||||HOSP ENC|||||||||n|N|||||||||||||||||||||||||||

ZPV|||||||||||20150827085700|||||||||||

GT1|1|1001|CCH^INPATIENT^CATH^||23 URBAN COWBOY ROAD^^TYLER^TX^75701^USA^^^SMITH|(903)595-5555^^^^^903^5955555||19530827|M|P/F|SLF|000-00-0000||||WALGREENS|^^^TX^^USA|||Part|||||||||||||||||||||||||||||

IN1|1|AHC^AETNA US HEALTHCARE PPO|60054|AETNA MANAGED CARE|PO BOX 981106^^EL PASO^TX^79998-1106^||(888)632-3862^^^^^888^6323862|456456||||20140101||||CCH^INPATIENT^CATH^|Self|19530827|23 URBAN COWBOY ROAD^^TYLER^TX^75701^USA^^^SMITH|||1*1|||||||||||||747|56485415641||||||Part|M|^^^TX^^USA|||BOTH||

My questions as a result of this are as follows…

1. Shouldn’t my translate always use the ADT_BASIC format, no matter what message type is sent through it? It seems like A09s are being treated differently.

2. When looking at the message above, wouldn’t both 1(0).PV1(0).#1(0) and 0(0).PV1(0).#1(0) be equal to 1, no matter what message type it is? As long as there aren’t any repeating segments in the message, either should be correct in my book.

3. Why do I get a mismatch error for an A09 and a path of 1(0).PV1(0).#1(0), but for a A08 with a path of 0(0).PV1(0).#1(0) I get no error, only an empty field?

4. To fix this, should I just sync up the ADT_A09 message format to match the grouping of the ADT_BASIC? If so, it sounds like lots of testing is in my future.

[Jim Kosloskey]

Mike,

Just one of many reasons we don’t buy into the ‘normalize’ theory for ADT or any other message type.

We really do not find it that much of an issue to maintain multiple Xlates – as a matter of fact over-all we find it to be advantageous.

Consequently as long as we make sure the variants we have defined match the actual data we will receive/build we rarely have any issues when we want to make a ‘minor’ or other change.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Karen May]

Hi Mike..

Typically per the HL7 2.3 standard;  A01, A04, A05, A08, A13, A14 have the same structure.  A09, A10 & A11 use a slightly different structure, as do the A02, A03.

The format is structured according to the type of transaction being processed.  ie; IN1 segments are not needed to transfer a patient from one bed to another with an A02.  They are needed when changing a patient type from Out to IN or vice versa.  

Of course, the standard is just that.  A standard.  Every vendor has their own interpretation and will structure accordingly.  That’s why Cloverleaf gives you the ability to create multiple variants with custom modifications.

Hope that helps..

[Robert Kersemakers]

I use a ‘generic’ xlate and dito variant as much as possible. I rather change one xlate than 15 xlates, especially when the changes are tricky and lengthy.

So I have a generic variant ‘ADT’ that has all the segments of the messages that need to be handled. Some segments, like MRG, had to be added as an optional segment in order to handle certain messages.

In this thread https://usspvlclovertch2.infor.com/viewtopic.php?t=859 Charlie also explains how to do it. You need to use a variant that covers ALL messages. He also says (and I have never done that myself) to copy the generic variant over the existing ADT_A01, ADT_A02 etc variant.

I think this is because you can use the generic variant for the xlate, but when Cloverleaf needs to parse a message for other things (determine trxid, validation) it will use the specific variant.

And maybe (still guessing here) in an xlate the specific variant is used for validation as well. So if the generic variant and the specific variant don’t match, you will get an error.

Does this make sense?

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Author]

Replies