mlp_tcp.pdl – not( <fs> )?

[Daniel Lee]

I’m looking at the mlp_tcp.pdl and see the following code:

Code:

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

What does the (not( )) do?  Does this ensure that isn’t anywhere in the message data?

I have a transcription interface that is receiving transcription in Spanish and it seems like it processes the packets fine until it gets to a packet that has a “1c” in it.  Then for some reason the engine tries to match phrases when the sending system isn’t done sending all the packets for the hl7 message yet.  Is it because the transcription has a 1c in it and the mlp_pdl says the data can’t have an ?

If this is the case is there any problems with me modifying the mlp_pdl to remove that constraint so it looks like this:

Code:

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

Topic

[Jim Kosloskey]

Dan,

If the sending system is imbedding a 1c in the middle of the message content, it is not following the HL/7 standard for that encapsulation technique.

In my opinion, the proper resolution is for the sending system to correct their system. It may be that when they get to a certain point prior to the end of an especially long message, they mistakenly add the 1c in anticipation they are at the end.

I am not sure of the ramifications should you make the change you are suggesting. However, if you are still keen on making that change, I suggest you make a copy and place it in the site level pdls directory with a different name so no one gets confused.

Jim Kosloskey

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

[Daniel Lee]

Thanks Jim.  I did a little research and looked up the ascii chart for Spanish characters and found that the sending system is not following ascii for these special characters.  It is sending out a 1c for the “a” with a ‘ over it.  I looked at some other special Spanish characters in the HL7 message and found that they are all wrong as well.  I just went back to the vendor and pointed this out so we’ll see what they say.

[Daniel Lee]

For future reference, is there any way to get the pdl to bail on reading into the data buffer on seeing both the <1c> <0d> instead of just the <1c>?

Something like this:

field data = variable-array( not( ) );

I tried the above and it doesn’t compile.  I’ve also tried , and it compiles but doesn’t work.

[Scott Folley]

The way that I understand it, the comma separated idea would compile as an or condition.  This would not work for what you are trying to do because it is going to bail as soon as it sees one or the other.  Because the pdl is doing a character by character comparison there would not likely be any way to prevent this.  I suspect that the is used because it is a character that would be extremely rare to see in a normal data feed.  What you may need to do in cases where this format will not work is to go to a length encoded scheme.  If you do that, you could trim the control characters in the inbound-TPS or come to an agreement with the originating vendor not to include the control characters at the beginning and end of the message (there would be no purpose to the control characters because your criteria for a message would be the length).  There is a significant decrease in overhead for a length encoded connection as well.  Much of the difficulties in using length encoding comes from the fact that there is more agreement necessary on the front end between the sender and receiver but it sounds like you are having to work through those agreements anyways.

[Author]

Replies