Accept ‘basic tcp’ messages instead of MLLP

[Matthijs Lipperts]

Hi all,

As a relative newbie here, please excuse me if this is a questions that has already been answered. A quick search did not yield any answers.

We are trying to connect our new infusion pumps to our patient data management system. The pumps, however, send out messages that do not fulfill the MLLP protocol, and therefore cloverleaf doesn’t accept the message (no more phrases to try…). Of course I think the manufacturer should adhere to ‘modern’ protocols, but their R&D is very sluggish. We are a little pressed for time, so I am looking at alternatives.

In Mirth I have managed to accept the messages by setting the ‘basic TCP’ protocol instead of MLLP, but in cloverleaf we are not succeeding. Our IT-dept is not very keen on implementing another broker for just one application, so they are pressing me/us to find a way using cloverleaf

We are now using protocol tcpip, with data type ASCII, justification left, length = 8. Then we get the error “length decode failed”.

Is there a way to have cloverleaf accept the message without knowing the exact length?

Any help is appreciated!

Thanks, Matthijs

 

 

Topic

[Jim Kosloskey]

So, did you start with a PDL? If so, the log should show the message in hex and you can determine exactly what the sending system is sending.

The message is probably encapsulated in some fashion. Apparently, it is not length encoded. But with the hex dump you can see. It might be as simple as start/stop hex codes at beginning and end.

Whatever the encapsulation it is likely a PDL will suffice.

 

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

[Matthijs Lipperts]

Hi Jim,

 

Thanks for your input. It took a while, but yes, we did start out with a pdl. And I got the hex dump. The raw message has no start byte (starts with <4d53>, and ends with <0a00>). We defined a pdl loosely based on the mlp-pdl, as follows:

define phrase basic-msg;

field data = variable-array( not( <lf> ) );

<lf><null>

end phrase;

but no luck here. Is there anything I’m missing here?

Thanks again!

[Jim Kosloskey]

Could those 2 leading characters be the length of the message (inclusive or exclusive)? The length would include the oaoo at the end if that is the case.

 

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

[Matthijs Lipperts]

Nope, the leading characters are ascii for MS (message starts with MSH etc). So it’s just a case of missing start byte (and a completely different stop byte then the 1c0d which is mllp-standard).

So the message reads:

data

<lf><null>

and should be:

<vt>

data

<fs><cr>

I’m in contact with the developer of the pumps/docking to change their output, but I’m afraid this can take quite a while…

[Charlie Bursell]

When you say null, do you mean an empty space or the hex digits X00?

It could make a difference.  Is this running on Window or Unix/Linux?

[Robert Kersemakers]

Hi Mathijs,

Have you tried using the ‘Encapsulated’ option within the tcpip protocol? Instead of MLLP or MLLP2 choose USER and here you can define your own start/end characters.

Maybe the default setting for USER (no start and end=\n) could work. Or try no start and end=\n\x00.

Hope this helps.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Author]

Replies