removing period from middle initial

[Ariba Jones]

I need to remove the period from the physician’s middle initial in an MFN^M02 message.

Field STF-3.3 has the physician’s middle initial, but with a period.  The receiving system wants to have this punctuation mark removed.  

I have a tcl proc used in an xlate that removes the dashes from the patient’s ssn.  I thought I would be able to edit that tcl proc to fit this situation.  I made the change to my ssn tcl proc and attached it appropriately (with a new name) in my new xlate for this interface.  When I run my xlate in the Testing Tool, it does not appear to work.  I still see the period in the STF-3.3 field in the output.

Can anyone tell me what I am doing wrong here?  Is there another approach I should take?

Here is my ssn tcl that is working fine in both test and production.

proc ssn_nodash {} {

           upvar xlateInVals inVals xlateOutVals outVals

           regsub -all — “-” $inVals “” outVals

}

Here is my physician tcl proc (a modified version of the ssn tcl proc):

proc doc_nodash {} {

           upvar xlateInVals inVals xlateOutVals outVals

           regsub -all — “.” $inVals “” outVals

           

}

 

Thanks in advance.

Ariba Jones

Topic

[Max Drown (Infor)]

The easiest way to do this, in my opinion, is right in the xlate.

Code:

regsub -all — {-} [lindex $xlateInVals 0] {} tmp; set xlateOutVals [list $tmp]

This is just one way to do it. I’m sure there are other good ways to do it, too. For example, Charlie would recommend using string map.

-- Max Drown (Infor)

[Charlie Bursell]

You are right about that Max.  I thought I taught you better.   🙂  If you are removing periods with a regexp, you have to escape and it gets unreadable.  Also, as I have told you many time whne given a choice and either will work, use the string command!

If I wanted to removes periods and dashes I would:

set xlateOutVals

]]

But you do whatever puffs you up  😆

[Jim Kosloskey]

Ariba,

If the period is always at the right end:

set var [string trimright $var “.”]

If the period is always on the left end:

set var [string trimleft $var “.”]

If it could be on either end and you just want to get rid of it:

set var [string trim $var “.”]

This is very efficient and easy to understand.

Or you could write an argument driven proc that builds the string trim command dynamically based on the arguments to do a right or left or both trim with any specified set of characters like we have here.

Then when you want to trim that pesky $ off of the end of a field (doesn’t matter which end or both) you just reuse the same proc.

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

[Bala Pisupati]

You can also put the following in your tcl

regsub {.} $inVals “” outVals

[Ariba Jones]

Thanks for this input.  I actually was initially told that I needed to remove the period from the physician’s middle initial in the message.  I did try Bala’s suggestion because it was quick and I needed to get this tested quickly.  It did work.

Today I am being told that I need to remove all non-alpha characters from the physician’s name field (which includes the last name, first name, middle initial).  

Is there a way to remove all non-alpha characters from the name field (last name^first name^middle initial)?  This is still regarding the MFN message in fields STF-3.1, STF-3.2, and STF-3.3.

Ariba

[Charlie Bursell]

Get the whole field in then

 

regsub -all — {[^x20-x126]} $var {} var

Will remove any non_Ascii Characters

[Ariba Jones]

Charlie,

What do you mean by…. “Get the whole field in”?

Also, are you saying to replace the regsub statement in my tcl with the one you have indicated?

Currently, my tcl script has this statement in it:

regsub {.} $inVals “” outVals

Do I replace that with…..

regsub -all — {[^x20-x126]} $var {} var

?

Thanks,

Ariba

[Charlie Bursell]

You said you needed to remove all non-ascii characters.

Copy the whole field including the subfields like:

             COPY

             IN 0(0).PV1.#8            (Not correct field)

             OUT 0(0).PV1.#8

Then in the pre:

set var [lindex $xlatenVals 0]

regsub -all — {[^x20-x126]} $var {} var

set xlateOutVals

[Ariba Jones]

OK, Charlie.  I will try this and let you know what happens.

Thanks so much!

Ariba

[Ariba Jones]

Charlie,

I have finally been able to get back to my work on this.

I get an error message in the Testing Tool when trying to test with this code.  What am I missing?

This is the error message I receive:

errorInfo:

can’t read “xlatenVals”: no such variable

   while executing

“lindex $xlatenVals 0”

   (procedure “doc_noperiod” line 5)

   invoked from within

“doc_noperiod”

I copied my entire field in the xlate as well.

Thanks,

Ariba

[Charlie Bursell]

I fat-figered and misspelled xlateInVals

soory  😳

[Ariba Jones]

Charlie,  

I get this error now.

errorInfo:

can’t read “xlateInVals”: no such variable

   while executing

“lindex $xlateInVals 0”

   (procedure “doc_noperiod” line 5)

   invoked from within

“doc_noperiod”

Here is my tcl.

proc doc_noperiod {} {

            set var [lindex $xlateInVals 0]

#            upvar xlateInVals inVals xlateOutVals outVals            

           regsub -all — {[^x20-x126]} $var {} var

           set xlateOutVals

           

}

Thanks,

Ariba

[Charlie Bursell]

I assumed you were using an xlate proc.  This is not an xlate proc.

Where are you trying to put the proc?  Perhaps you need to ask the list for guidance on how to do Xlate procedures?

[Ariba Jones]

I attach this proc to the Pre: Tcl field of my COPY statement in my xlate.  Is this not what you call a xlate proc?

So, here is what I have in my xlate…..

ITERATE

 COMMENT

 COPY

NOTE:I use the ITERATE since this field repeats.

My ITERATE has…

 Type: field

 Basis: 1(0).STF.00673

 Variable: %f1

My COPY has…

 Input/Output

     Pre:   Tcl: doc_noperiod    (this is my tcl proc)

 Source: 1(0).STF.00673(%f1)

 Destination: 1(0).STF.00673(%f1)

[Tim Gobbel]

I think that in an Xlate pre or post you only put in the code section from the tcl proc not the whole thing so try putting just:

          set var [lindex $xlateInVals 0]

#            upvar xlateInVals inVals xlateOutVals outVals            

          regsub -all — {[^x20-x126]} $var {} var

          set xlateOutVals

in the pre xlate section.  HTH!

[Gary Atkinson]

Un comment the upvar.  Then just place the proc name in the pre-proc section.  Or as Tim said just put the tcl code in the pre-proc section without the upvar.

[Ariba Jones]

Thanks, Tim and Gary.  I will try both of these suggestions, actually.  I’ll let you know if it works.

Ariba

[Ariba Jones]

Tim and Gary,

I am at a complete loss now!!!

I have tried the two scenarios that you have given and neither works.

Here is what I have done…  In my xlate I have setup my ITERATE (since the field I am working with repeats) to have each component of the field listed for checking.  There are three components of the field that I want to remove non-alpha characters from.  This is what I have setup for each of those components of the field.

ITERATE

COPY

  Source:   1(0).STF.00673(%f1).[0]

  Destination:  1(0).STF.00673(%f1).[0]

  Input/Output Pre Tcl:  

                               set var [lindex $xlateInVals 0]

                               regsub -all — {[^x20-x126]} $var {} var

                               set xlateOutVals

 

COPY

  Source:   1(0).STF.00673(%f1).[1]

  Destination:  1(0).STF.00673(%f1).[1]

  Input/Output Pre Tcl:  

                                regsub -all — {.} [lindex $xlateInVals 0] {} tmp

                                set xlateOutVals

                             

COPY

  Source:   1(0).STF.00673(%f1).[2]

  Destination:  1(0).STF.00673(%f1).[2]

  Input/Output Pre Tcl:  

                                regsub -all — {.} [lindex $xlateInVals 0] {} tmp

                                set xlateOutVals

The last two COPY statements (.[1] and .[2]) work, but not the first one (.[0]).  It seems as though when I put in the code for non-alpha characters ( [^x20-x126]) that it doesn’t work.  The last two COPY statements are checking to remove any periods in the component, which works.  I don’t know what else to try here.

Is something wrong with the way I am trying to specify the non-alpha characters code?

Thanks,

Ariba

[Tim Gobbel]

Sorry, I have not had the need to use regsub and therefore can not advise on that.  There are a lot of regsub gurus out there and I have seen a lot of posts about it.  Maybe a search would turn up something.  Thanx!

[Tom Rioux]

Ariba,

Try changing your regsub to the following:

regsub -all — {[^[:alpha:]]} $var {} var

This remove any special characters and leave only alpha characters.

Hope this helps…

Tom Rioux

[Tom Rioux]

Ariba,

Another option that may save you from having to use three entries in your xlate:

Provided the following will always be true:

1(0).STF.00673(%f1).[0] is equal to “LAST NAME”

1(0).STF.00673(%f1).[1] is equal to “FIRST NAME”

1(0).STF.00673(%f1).[2] is equal to “MIDDLE NAME”

Then you can simply use one entry:

COPY

 Source:        1(0).STF.00673(%f1)

 Destination:  1(0).STF.00673(%f1)

 Input/Output Pre Tcl:  

                    set var $xlateInVals

                    regsub -all — {[^[:alpha:][:space:]]} $var {} newvar

                    set xlateOutVals $newvar

Since the xlateInVals is a list, when you do the regsub, if you just specify “alpha” then the regsub command will also remove the spaces thereby rendering it not a list anymore.  By putting in the “[:space:]” it keeps the variable as a list and your “newvar” variable will be returned as a list, putting the last, first, and middle names in their proper places in the destination field.

One caveat however, if your name will ever have spaces in it (like a first name of “Billy Bob”, then it is better not to use this method and stick with the first one I showed you.

Hope this helps…

Tom Rioux

[Ariba Jones]

Hi Tom,

I tried your first suggestion and that works like a charm!  

Thanks so much for your input.

Tim and Gary- Thank you for all of your input as well!  I really appreciate it.

Ariba

[Bala Pisupati]

Can anyone of you tell me how I can put regsub to replace an ampersand in Xlate at the field level.

I wote a tcl that does it for me but I was wondering if I can put it directly on Xlate.

regsub -all {&} $checkfield ” and ” val1

[John Mercogliano]

Bala,

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Tom Rioux]

Why don’t you use a string map command.  Charlie had a fine example of it earlier in this post.

set xlateOutVals

]]

Hope this works for you…..

[Bala Pisupati]

Thanks for the quick replies but neither of them worked sorry  🙁 .

As far as using tcl instead of on the XLATE. I am trying to see if I can get the same result without using the tcl. Thanks for the remarks though.

[Jim Kosloskey]

Bala,

Perhaps the problem is when referencing a field that contains a sub-component separator erroneously (the standard sub-component separator is &) in the Xlate, the field stops providing data at the sub-component separator and treats it like a subcomponent separator.

Thus the xlateInVals never ‘sees’ the &.

Like this |this is plain wrong & stupid| <– Let's say this is field ….PID#3.

I think a tcl callout in an Xlate would see ‘this is plain wrong ‘ not ‘this is plain wrong & stupid’ the field stops at the subcomponent separator. Thus your proc might work correctly if it received the entire field – but I don’t think it does.

Can this still be done in an Xlate?

Kind of.

If you absolutely know the field where the & will exist and you know how many there can be, you can use sub-component notation to pick up the pieces and CONCAT them back together.

Example (assume field above):

CONCAT

   …PID#3.[0].[0]

   …PID#3.[0].[1]                …PID#3.[0]

The in references with the two items enclosed in square brackets ([0].[0] and [0].[1]) point to the first sub-component of the first component of the PID-3 field and the second sub-component of the first component of the PID-3 field (because there is only one & in the example string, there are only two sub-components).

If there were 2 & in the sample string, then there would be 3 sub-components and you would need at least 3 entries in the CONCAT to get everything.

This is one of the reasons trying to do this in the Xlate is difficult.

Now – on my soap box – HL/7 provides a solution for this issue. The source system should escape any and al MSH-1 and MSH-2 components that might exist in a field erroneously in the prescribed standard fashion – period!! The issue becomes a non-issue if vendors and system developers simply followed the standard.

I am off my soap box now.

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

[Tom Rioux]

Since the ampersand is an HL7 reserved character, you won’t be able to use your code as a code fragment within an xlate.  If you have a field that contains and ampersand, it will show up in your xlateInVals as a list.  For instance:

“LAB RESULTS & RAD RESULTS COMPLETED”

The xlateInVals value for this would be:

{LAB RESULTS} {RAD RESULTS COMPLETED}

It would be best to do this in an inbound TPS or prexlate proc before it ever hits the xlate.  Then you can use the string map command like Charlie suggests.  Much simpler.

Hope this helps…

Tom Rioux

[Author]

Replies