Pathcopy Populating A Blank Field

[Darren Tomlinson]

i have this copy defined in a translation…

PATHCOPY   0(0).PID.00114(0)   ->   0(0).PID.00114(0)

whenever the field comes in blank, Cloverleaf would populate this field with an M.  Does anyone have any idea why?

i later realized that the use of a PATHCOPY on a subfield was poor syntax, so i changed it to a COPY and it works correctly now.  The reason i tend to use PATHCOPYs is because if a field has subfields, a COPY with only copy the first subfield…i just got in the habit of always using PATHCOPYs.

Also note, i am on 5.3 rev3

Topic

[Daniel Chibaya]

Is the field actually blank or does it have some “hidden” text in there?  Control characters?

[Darren Tomlinson]

i’m not sure exactly what you are asking, but that field comes blank into Cloverleaf in the PID, and an M gets put into it.

[Darren Tomlinson]

i have it doing it again, in a new context…

I have PATHCOPYs on fields in the OBX segment.  the fields that can repeat, but i denote instance 0, also get “M”s put in the fields that are blank.  i am completely perplexed.  

example: PATHCOPY of blank field(s) 0(0).OBX(%s1).00576(0) will get populated with an M but 0(0).OBX(%s1).00577 will not.

i’m guess not many people have ran across this due to the lack of responses.

[Tom Rioux]

Darren,

The “hidden” characters may be control characters (such as a tab or a carriage return) that may be showing up in the message being sent.  One quick way to check this is to do a hex dump on the file:

hcihd filename.bin

When you do a hex dump you will see the Hl7 message on the right and the hex equivalent on the left.  Any control characters will show up as dots in the hex part of the dump.  See example:

56547c5e 33373739 3735320d 4754317c   VT|^3779752.GT1|

The first four columns are the hex equivalent of the last column.  If you notice at the tail end of the 3rd column, there is a “0d” that represents the end of the segment.  

Check your message to see if anything like this is happening in your message.

Hope this helps…

Tom Rioux

[Robert Milfajt]

I agree with Thomas that you probably have an ASCII 13 character imbedded in the field.

Cloverleaf represents this as ^M in textual displays, and the ^ is also the sub-field delimiter, so you think you are getting an M when in actuality you are getting x0d.

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

[John Mercogliano]

All,

  I just ran across this same problem today doing a pathcopy of 1(0).1(%g1).0(0).NTE(%s1) with the NTE segment getting populated with a single M in the first field when the NTE segment did not exist.  It turned out that my iterate was set to list instead of segment.  

 Don’t know if this applies but something to look at.  

 I would have thought that I would have received some type of error because everything else in the dialog box was defined for a segment iterate including the %s1 instead of the %l1.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Darren Tomlinson]

i ran the hex dump on my file.  there is no hidden character.  7c467c7c577c represents |F||W|.  as you can see, there is no hidden character between the F and W.

i double checked the bad iterate variable, but that was not it.  there isnt an iterate at all anywhere in the translation.

[John Mercogliano]

Darren,

  That could be your problem as it appears pathcopy returns M when you use an undefined iterate value.  If you are not using an iterate then you should be able to use a direct reference as in

0(0).OBX(0).00576(0) instead of 0(0).OBX(%s1).00576(0)

But if this is a repeating segment, how are you looping through the segments without an iterate?

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Darren Tomlinson]

there are two instance above where i have this problem…

1) is in the PID that has no iterate

2) is in the OBX with a properly defined iteration variable

[John Hamilton]

I use pathcopy on a regular basis. I have never seen this issue where the source data was not a fault.  

What I would suggest is posting both your translation and the source data.  Or call support.   I would be more the willing to go over your xlate and use your example data to find the issue.  But trying to recreate your problem for me has been problematic.

[John Mercogliano]

Darren,

 First, I am using 5.2 rev 2, so this might be fixed in a future release as they did a lot of work after 5.3 with pathcopy.

 I’ve been able to duplicate your PID pathcopy problem and it does appear to be related to pathcopy not working with a completely null input on a repeating field.  Pathcopy should work down to the field level.

 Being my problem also produced the same result and I would have also been sending a null value to pathcopy at the segment level because of my uninitialized iterate variable(oops), there is a good chance that pathcopy has an overall problem working with a completely null data stream in a repetition.

 Being your second problem also dealt with copying a blank repeating field but the non repeating field worked this appears to hold true.

 I don’t know about everyone else, but at the field level I have always used the copy command.

 Your statement that copy will only copy the first subfield is incorrect.  As long as you define the source and destination the same as pathcopy, at the field level it works the same, minus the null copy problem.

Hope this helps,

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Darren Tomlinson]

John, you are right about the copy command.  i just retested it, and it appears to work.

I know at one point the copy command would not copy subfields for us…and thats when we found using pathcopy as a solution to that problem.

The thing that might have been the problem back then is that we were running 5.3 rev3 on the server, but didnt install the patches on our PCs.  That has since been rectified.  I guess that could have been the issue.  i dont know…

[Alice Kazin]

I have had this issue before.  Generally I check if a required field in the segment is not null before doing the Pathcopy.

[Alice Kazin]

In my case I was pulling ^M (d) from the end of the segment.

[Kevan Riley]

We noticed this problem while we were comparing output from 5.3 against 5.6.  This has been happening to us quite a bit in 5.3 and we never noticed it.  The behavior goes away (is fixed) in 5.6.  I can’t speak to any intermediate versions.

Kevan Riley

[Alice Kazin]

It was happening on 5.4.1 rev1.

[Darren Tomlinson]

i figured out why i thought i needed to us a PATHCOPY to copy all subfields.

For instance, if you were to copy the PID with a PATHCOPY but wanted to null out PID2, if you COPY @null -> 0(0).PID.00105, it will leave the subfields alone and only blank out the first subfield.  Result will be |^subfield2^subfield3|.

whereas if you use a PATHCOPY of @null you will blank out all subfields and be left with ||

[John Mercogliano]

I wrote this xlt proc to null a field because of the purge cache problem with copying a null value with pathcopy in versions I believe earlier then 5.5.  You call this with the field name in the source and destination(i.e. 0(0).PID.00105).  

Pathcopy would be the logical choice if it was not for these two problems.  But luckily with tcl you can code around most of the inconvenient problems 😉

Code:

proc shs_xltNullField {} {
   upvar xlateId       xlateId        
xlateInList   xlateInList    
xlateInTypes  xlateInTypes    
xlateInVals   xlateInVals    
xlateOutList  xlateOutList    
xlateOutTypes xlateOutTypes    
xlateOutVals  xlateOutVals

set xlateOutVals [list]
foreach InVal $xlateInVals {
lappend xlateOutVals {}
}

   return $xlateOutVals
}

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Darren Tomlinson]

i ran into two more problems previously discussed within this thread.

1) i am now getting an a segment of “NTE|M” copied across when there was no NTE segment present.  i did not have an iteration value as John has described earlier in this post because i want to only copy the 0 instance.  when i changed the PATHCOPY of the NTE to separate copies of each individual field, the problem went away.

2) i ran across the COPY not coping all subfields again.  in the one instance i saw today, a copy of a field defined as STRING will not copy subfields if present.  however, if i change that field to COMPOSITE, it gets all subfields.

[Jim Kosloskey]

Darren,

In the second instance (ST Data Type) that Data Type is mal used. Separators of any kind are not to be placed raw in a ST field – period!!

They either need to be escaped or the field used properly or (as you have done) change the Data Type to CM or some other componetized Data Type as a work around.

I see this violation all the time and mostly I try to get the vendor or system owner to stop being so damn lazy and follow the standard. I am not always successful at getting the sending system to change but I am almost always successful in adapting due to the power of Cloverleaf(R).

The second instance you observed is not a fault of PATHCOPY – IMHO it is doing what I would expect.

email: jim.kosloskey@jim-kosloskey.com

[Jim Gibson]

We are in the process of testing for our upgrade from ver 5.3 to 5.6.  We had seen this problem with PATHCOPY.  In 5.6 it has been fixed and you do not get the mystery M segments.  We are just hoping our apps that have been getting these for years won’t mind not getting them.

[John Mercogliano]

Darren,

 Your first problem you described is still a variant of the same problem.  Even though you are hardcoding the repetition value, pathcopy is still working on a a segment defined as repeating. So when it receives a command to copy a null segment you get the M.  I have gotten around this problem by using an if statement on the set id or some other value that is guaranteed to never be null and only calling pathcopy when there is data.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Kevin Crist]

i am having somewhat of a similiar problem. i am trying to copy fields from a vrl to hl7. This is a first for me as i am new to interfacing. when i run the testing tool i get m’s where there should be the | field separator. i am using only a copy statement in the xlate, so far. any advice would be thankful. thanks.

[/img]

[John Mercogliano]

Kevin,

 I have a similar setup and I have no problem with the pipe disappearing.  Are you attempting to copy a constant or a vrl field to 0(0).MSH.00001.[0] when you build the MSH segment?  Unless the downstream system expects something else, you should not need to do anything to field 1 or 2 as cloverleaf will always send the default, at least in 5.2.  I’ve also attempted to copy @null and the testing tool still shows the pipe.  It only changes if I gave it a valid ascii character.  Not sure where else to look but hope this helps.

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Author]

Replies