Failing DFT message

[Kumar Ananth]

I have DFT messages coming from a vendor into CL and going out to LIS. The DFT messages are failing and can’t seems to find why. Below is an example from the log file.

  seg 1 >MSH|^~&|IMPAC|017||017|201309172002||DFT^P03|20130917200254464861|P|2.3||||||8859/1<   seg 2 >EVN|P03|20130917200006<   seg 3 >PID|1||XXXXXX|XXXXXX|XXXXX^XXXXX^^^||########|X|XXXXX, XXXXXX|X|XXXXX^^XXXXXXX^XX^XXXXX-X

XXX^USA||(###)###-####||XX|X|X||XXXXXXXX|||<   seg 4 >PV1||O|XX^^||||###^XXXXXX^XXXXX^X||~~|||||||||||||||||||||||||||||||||||201308291635||||||<   seg 5 >FT1|1|469910||201309171553||CH|467-6063|XXXXXXXXXXXXXXX||1||||||^XXXXXX||O|162.3^^I9|#

##^XXXXX^XXXXX^X|||||77470|<   seg 6 >< [msg :RecP:WARN/0:fhw_cerner_xlate:09/17/2013 20:06:12] [0.0.597530142] unknown segment ‘ EV’ — ignored. [msg :RecP:WARN/0:fhw_cerner_xlate:09/17/2013 20:06:12] [0.0.597530142] unknown segment ‘ PI’ — ignored. [msg :RecP:WARN/0:fhw_cerner_xlate:09/17/2013 20:06:12] [0.0.597530142] unknown segment ‘ PV’ — ignored. [msg :RecP:WARN/0:fhw_cerner_xlate:09/17/2013 20:06:12] [0.0.597530142] unknown segment ‘ FT’ — ignored. [xpm :xlt :WARN/0:fhw_cerner_xlate:09/17/2013 20:06:12] Warning during PathCopy: unknown segment ‘ EV’ — ignored. unknown segment ‘ PI’ — ignored. unknown segment ‘ PV’ — ignored. unknown segment ‘ FT’ — ignored. CMD before removing dash: {} CDM   seg 1 >MSH|^~&|XXXXXXX|017||017|201309172002||DFT^P03|20130917200254464861|P|2.3<   seg 2 >PID<   seg 3 >FT1||777|||20130917||{}^^CDM|||||||||||||||||XXXX<   seg 4 >< If the vendor does a manual export and push the messages, it will process fine. The MSH stops with HL7 version field. But, when the vendor sets the process to automatic (charges gets picked up and pushed out at 8;00PM nightly) it comes with extra value MSH-18(“8859/1” from below example). I’m not sure if this MSH-18 or something that’s not visible from automated process is causing the xlate or something else throw below errors. I tried taking the messages and running it thru the xlate in testing tool and can’t seem to reproduce the error messages in the log file. Anyway to find if any invisible odd/extra charater(s) getting sent or what’s causing the message to fail with below error messages?

Topic

[Boris Perov]

Kumar,

Can you post the whole message?

[Jim Kosloskey]

Kumar,

You do not indicate what protocol is used.

If this is MLP, then turn up the EO Config so you can see the hex representation. If it is a file type protocol, then use something like hcihd from the command line to look at the file in hex.

What you are looking for is something that is not the same as your protocol setting and for that matter the Xlate is needing.

Perhaps erroneous cr or lf characters or something like that.

I think once you get a look at the data in hex you will have a better idea.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Ed Mastascusa]

Hi Kumar –

I think you can infer from the line feed in the “unknown segment” messages (the 3 chars between the ‘ ‘s ) that in the bad message there is a line feed char after each segment delimiter. That out of order segment message takes the first 3 chars after the segment delimiter as the next “segment header” (as it should)

Turning up the engine output as was previously suggested can definitely prove or disprove that.

If the vendor can’t fix the issue you can do something pre-xlate in a tps proc.

[Keith McLeod]

If you have the message in SMAT, view it with detail level 0.

[Kumar Ananth]

Thankyou all for the reply. Keith McLeod was right on the money. I still had the smat file. So, loaded the smat file with detail level zero and I see the hex values between segments. When the vendor is doing manual push the messages are getting sent properly with hex value for CR between segments. But, on the automatic sweep, the vendor is sending CR and Line feed(0A) between segments.

[Keith McLeod]

You can also turn up the engine noise by setting the eo_config to enable_all or create your own ‘enable_pdl’ as an alias with ‘ENABLE  pdl * * *’ on your inbound thread(or at least on the process).  This will allow you to see the hex values in the process log.  Here you can also see the incorrect characters.  Hope this helps…

When they send segment terminator as CRNL, it really signifies the end of the message.  So the engine perceives only the MSH segment as a message and all of the segments as failed messages becaause they don’t have an MSH segment.

[Author]

Replies