mlp_tcp.pdl Modification needed

[Ronald Ortiz]

Because of the way it’s written, it only considers the following a truly encapsulated message:

Code:

<0xb>
.
.
.
<0x1c><0xd>

From time to time, we get something like this, which causes Cloverleaf to never process the message:

Code:

<0xb>
.
<0x1c>
.
<0x1c><0xd>

Cloverleaf basically ignores this and does not process the message.  In the meantime, the sending system continues to send until it gets the ACK/NACK that it needs to proceed…and messages just queue up on the sending side.  

How can this PDL be tweaked to ignore that <0x1c> and continue until it finds it’s true pair of <0x1c><0xd>?

Topic

[Robert Milfajt]

I’m not 100% sure if this will break things, but you might be able to create your own version of mlp_tcp.pdl (move it to site directory), and change the following:

define phrase basic-msg;
[code]define phrase basic-msg;

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Ronald Ortiz]

Robert Milfajt wrote:

I’m not 100% sure if this will break things, but you might be able to create your own version of mlp_tcp.pdl (move it to site directory), and change the following:

define phrase basic-msg;
[code]define phrase basic-msg;

[Robert Milfajt]

Sorry, ID10T error, try this:

Code:

define phrase basic-msg;
   ;
   field data = variable-array( any );
   ; ;
end phrase;

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Ronald Ortiz]

Robert Milfajt wrote:

Sorry, ID10T error, try this:
define phrase basic-msg;
[code]define phrase basic-msg;

[Robert Milfajt]

I’m out of ideas, because it would seem to get this to work you either need to create your own custom PDL and figure out how to define this, or to have the vendor stop sending x1c in the data.

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Ronald Ortiz]

Robert Milfajt wrote:

I’m out of ideas, because it would seem to get this to work you either need to create your own custom PDL and figure out how to define this, or to have the vendor stop sending x1c in the data.

Bob

I was playing around with the protocol: tcpip

and I got it to accept the message and continue to flow downstream, but I then run into two more problems.  

1) The message cuts off/truncates at the 1C mark.  So you only get part of the message.

2) Now you have the same problem but on  your outbound message.  The receiving side won’t process the message because it’s not properly encapsulated.  But even if you do tweak it to encapsulate, you only have half the message due to the truncation.  

The ideal would be for Allscripts to fix it at the point where the physician does the copy/paste, but I seriously doubt Allscripts will put in a fix for that.

[Jim Kosloskey]

Is this a report type format like RTF or PDF?

If so AllScripts should be sending this as base64 encoded.

If you are getting the inbound protocol to read it, maybe you can base64 encode it in a Tcl proc (of course anything following on would also need to be able to decode it, etc.).

Personally I would be concerned I would get by this and then find other nasty stuff in future messages since the vendor seems to be incompetent.

If it were me I think I would try to get together with my management and try to apply a little wall-to-wall counseling with AllScripts   😯

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

[Ronald Ortiz]

Jim Kosloskey wrote:

Is this a report type format like RTF or PDF?

If so AllScripts should be sending this as base64 encoded.

If you are getting the inbound protocol to read it, maybe you can base64 encode it in a Tcl proc (of course anything following on would also need to be able to decode it, etc.).

Personally I would be concerned I would get by this and then find other nasty stuff in future messages since the vendor seems to be incompetent.

If it were me I think I would try to get together with my management and try to apply a little wall-to-wall counseling with AllScripts

[Author]

Replies