How to remove all r that are not a segement terminator

[Jim]

Hello fellow Clovertechers,

I have a system that  sends random carriage returns in a HL7 message and need to remove them without removing the segment terminators. I can remove all r with the following;

set newmsg [string map {r “”} $msg]

how can I do it without removing the segment terminators?

Thank you,

Jim

Jim

Topic

[Mike Keys]

Jim,

Just in a certain segment? Throughout entire message?

I’d be inclined to write a Tcl pre-proc that would loop through each segment and remove those, since you build the output buffer and can put the r back on the end of the segment.

You’d have to ensure the r is the last character in the segment when splitting the message.

Mike

[Jim]

Mike,

Thank you. The sending system randomly puts the r in the message and can be anywhere. Therefore we have to process the message in whole then put the r back in the correct locations.

We resolved the issue with the following in our script;

set newmsg [string map {“PID” “rPID”} $newmsg]

set newmsg [string map {“OBR” “rOBR”} $newmsg]

set newmsg [string map {“OBX” “rOBX”} $newmsg]

since these are the only segments in the message we should be ok.

Jim

Jim

[Michael Hertel]

We don’t allow bad behavior here.

We have a VMAX results interface which is famous for this. (It just happened yesterday so this is great timing)

We use this code and kill the messages, making them go back, fix the result and resend. Sometimes it takes an attempt or two or three for them to get it right but eventually they do figure it out.

# Kill if extra carriage returns where they shouldn’t be

set msglist [split $msg r]

foreach seg $msglist {

[Jim]

Michael,

Great idea the only problem is it is a known problem in the sending system and there is nobody on the application side to fix the issue. When you look at it on the application side it doesn’t look like there is a problem it only occurs when the system creates the HL7 message. Of course they told us 2 releases ago that it would be fixed in a future release.

Jim

Jim

[Michael Hertel]

The portion of the email alert clues our users as to where the offending c/r is located.

exec echo “Carriage return just before here—-> [string range $seg 0 50]…<—" nn[join [split $msg r] n]

You’re right, they can’t see the c/r but we know it’s there.

It usually happens because of new “canned comments” or where someone entered data incorrectly.

The before “here—->” part helps them figure that out.

Are you saying that you are seeing miscellaneous c/r’s somewhere else in the message than an OBX-5 segment?

[Jim]

Michael,

The problem is that the sending application’s conversion process has bugs in it and they haven’t found them all yet. The code that we wrote works so I am not to concerned. The data is entered into a from and then converted to plain text.

Jim

[Michael Hertel]

Ok, then this is what I’d do:

[Michael Hertel]

While toweling off from my morning shower it occurred to me that I had an error in my code in the last post. I went back and edited it.

There was no need to remove the first character in $seg in the else clause.

[Robert Kersemakers]

Michael, I think your code won’t work if there is more than one rogue r inside a segment, am I correct?

Nasty problem. I totally agree that it should be fixed on the sending application, but we all know how it works in the real world.

I would try something like this:

* Replace all r with a high or low ascii value

Code:

regsub -all {rPID} $msg xff msg
regsub -all {rOBR} $msg xfe msg
etc…

* Remove all leftover r from the message

Code:

regsub -all r $msg “” msg

* replace the high/low ascii value with the proper r

Code:

regsub -all xff $msg {rPID} msg
regsub -all xfe $msg {rOBR} msg
etc…

You will need to know all segments that can be send though, which can be a long list.

Also be aware that the high/low ascii values may already be used by another proc.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Michael Hertel]

Hi Robert, thanks for asking.

It should get all rogue r ‘s

But looking at my code further it would get fouled up on “STUrPID”, “LIrPIDS”

(LIPIDS has bitten me in the past when looking for segment id’s) 🙂

So you would need to define the segment list like MSH| PID| OBR| and compare the range to 0 3 instead.

In any event, I like your solution better.

Jim, please ignore my previous input.

🙂

[Author]

Replies