"1C" causes no-match

[Daniel Lee]

We have an inbound document interface into Cloverleaf that receives MDM documents from a foreign interface engine.  It appears that sometimes user

Topic

[Dan Loch]

Daniel,

The same thing is happening on our engine.

Have you any solution yet?

Dan

[Charlie Bursell]

I have written such things in the past but they become very convoluted.  So it is possible to do in PDL

I would try it first with encapsulated mode under the TCP/IP protocol.  I have not tested it yet but I think it would work

[Charlie Bursell]

I just tested it on my box.  I defined IB Protocol as TCPIP/Encapsulated and selected MLLP.  I then sent an HL7 message via PDL from another thread with an embedded HEX 1C.  I received entire message including the HEX 1C

So if you use this you may want to add a simple string map command to remove any embedded HEX 1C characters

[Ronald Ortiz]

Charlie Bursell wrote:

I just tested it on my box.

[Darcy Kemp]

Hi, We are running 5.7.3 and don’t see an option for Encapsulated mode for TCP/IP.   How does one define it?  Thank you.

[Russ Ross]

Another approach to work around the problem could be to negotiate with vendor to see if they can do straight TCP/IP length encoded connection then whatever is sent will make it to Cloverleaf.

Once on Cloverleaf the undesired character can be stripped like Charlie already mentioned.

Russ Ross
RussRoss318@gmail.com

[Charlie Bursell]

The obvious question is why are you still on 5.7?

The best solution would be to have your vendor read the HL7 standard with emphasis on communication protocols.  He would see that he, not you, should take care of the bogus charactor.

[Darcy Kemp]

I have been in this particular position just 6 months.  In that time I have re-worked old xlates, tcls, and formats, to eliminate numerous standing issues, and resolved department issues.   I have move the engine from a non compliant to compliant Op sys and gone from 5.7 to 5.7.3.  Thanks Charlie..believe me…. I am working on it…  🙂

[Author]

Replies